VHDL Issue Number: 0082 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Some globally static expressions are not evaluable during model elaboration. Related Issues: 0022 Relevant LRM Sections: 7.4, 12.1-12.5 Key Words and Phrases: Globally Static Expression, Elaboration, Dynamic Elaboration, Evaluation Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Section 7.4 was updated. Superseded By: N/A ----------------------- Date Submitted: 1988/02/22 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Avenue, Suite 415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1989/10/23 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/03 17:58:26 $ Description of Problem ---------------------- Certain globally static expressions must be evaluated during the elaboration of a design hierarchy but hinge on the dynamic evaluation that does not occur until later. An example of this follows: entity E is generic (I: Integer); end E; architecture A of Work.E is signal S: String (1 to 10); begin process procedure P is constant C: Integer := I + 4; begin S(C) <= '1'; end P; begin end process; end A; The process in the above VHDL has a driver but this driver cannot be determined when the process is elaborated because the driver depends on the constant declaration for C which is not elaborated until the procedure P is called. Proposed Resolution ------------------- For a constant to be a globally static primary, it must not be declared in a subprogram declarative part. For a reference to a user-defined attribute to be a globally static primary, its value must not be defined in a subprogram declarative part. Finally, for a subtype to be globally static, the subtype must not be declared in a subprogram declarative part. VASG-ISAC Analysis & Rationale ------------------------------ The intent behind the definitions of locally and globally static is that a locally (globally) static expression be evaluable during analysis (model elaboration). Moreover, the value of a static expression, whether it be locally or globally static, does not subsequently change. (Issue Report 0059 explores the justification for these statements in detail.) The definitions in LRM Section 7.4 do come quite close to identifying those expressions which have values at the appropriate time. Unfortunately, Section 12.5 specifically says that certain constructs are to be dynamically elaborated, even if all expressions within them are globally (or for that matter, locally) static by the definitions of Section 7.4. The problem described above results because the rules in Section 7.4 do not take the exceptions of Section 12.5 into account. As a consequence, expressions not having values at the expected times are possible, as the above example illustrates. One possible fix would be to interpret the definition of locally and globally static primaries in Section 7.4 as excluding primaries of expressions appearing within the contexts enumerated in Section 12.5. Specifically, interpret paragraph 3 of Section 7.4 to read: "An expression is said to be locally static if and only if every operator in the expression denotes a predefined operator whose operands and result are scalar and every primary in the expression is a *locally static primary*, where a locally static primary is defined to be a primary whose definition is not dynamically elaborated (see Section 12.5) and is one of the following:" Moreover, one would also interpret paragraph 7 of Section 7.4 to read: "An expression is said to be globally static if and only if every operator in the expression denotes a predefined operator and every primary in the expression is a *globally static primary*, where a globally static primary is defined to be a primary whose definition is not dynamically elaborated (see Section 12.5) and is one of the following:" The semantics of the above example would then be as follows. With the current nterpretation of the LRM, the longest static prefix of the target "S(C)" is "S(C)". This is true because "S(C)" is a globally static name; the only expression in the name, "C", is a globally static expression. (This condition holds because C is a constant of a globally static subtype initialized with a globally static expression.) It is necessary to know the longest static prefix of the target of every signal assignment as a driver for the target must be created during model elaboration. However, because of the requirements of Section 12.5, the object denoted by "S(C)" is not known during model elaboration. Therefore, a driver for the target of this signal assignment cannot be built. In contrast, under the suggested interpretation C is not any sort of static expression, as C is a constant appearing in one of the contexts enumerated in Section 12.5. Consequently, the longest static prefix of the target "S(C)" is "S"; this name unambiguously identifies the signal for which a driver may be built. However, the ISAC feels that this proposed change to the language is too great a change given the infrequent circumstances in which the problem occurs. Thus, in the above example, an implementation is to create a single driver for a single character of the signal. The ISAC feels that the meaning is clear and that the implementation burden is not excessive. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Do not change the language or the interpretation of the LRM in response to this issue. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Change the wording of Section 7.4 to explicitly exclude from consideration primaries of expressions appearing within the contexts enumerated in Section 12.5. Adoption of the wording suggested above gives this effect. Extensions to globally static attribute names similar to those proposed for locally static attribute names in Issue Report 0069 should also be considered. Other desirable extensions to the concept of a globally static expression would be to allow globally static index and slice names as globally static primaries.