VHDL Issue Number: 0022 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Some non-globally static expressions are evaluable during model elaboration. Related Issues: 0082 Relevant LRM Sections: 7.4, 12.1-12.4 Key Words and Phrases: Globally Static Expression, Elaboration, Evaluation Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: This IR was part of LCS15 with solved many problems with static expressions. The new definition of a static expression is one that matches the notion of "evaluable during model elaboration". Superseded By: N/A ----------------------- Date Submitted: 1989/02/23 Author of Submission: Paul Menchini Author's Affiliation: CAD Language Systems, Inc. Author's Post Address: P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: (919) 361-1913 Author's Fax Number: Author's Net Address: mench@clsi.com ----------------------- Date Analyzed: 1989/10/23 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.7 $ Date Last Revised: $Date: 1995/05/13 19:34:42 $ Description of Problem ---------------------- The LRM states in Section 12.3: "In certain cases, the elaboration of a declarative item involves the evaluation of expressions that appear within the declarative item. The value of any object denoted by a primary in such an expression must be defined at the time the expression is evaluated." The LRM states in Section 7.4: "Certain forms of expression can be evaluated as soon as the design hierarchy in which they appear is elaborated; such an expression is said to be *globally static* ...." Later in Section 7.4, a decision procedure for determining whether or not a given expression is globally static is presented. This decision procedure excludes references to index and slice names, calls to user-defined functions, and to type conversions. (It also excludes calls to Std.Standard.Now.) Thus it would seem that expressions appearing within statically elaborated declarative items must be globally static expressions when those expressions must be evaluated during elaboration. (Examples of such expressions are the value expression of a constant, or the initial value expression of a signal or variable.) However, the LRM makes no such requirement. Moreover, references to index and slice names, calls to user-defined functions, to Std.Standard.Now, and to type conversions are all resolvable (under certain circumstances) during static elaboration. Allowing a call to Std.Standard.Now as a globally static primary is problematic. While it is possible to define a return value for this function call during static elaboration, its use as a globally static primary is questionable, since the value of the expression is then dependent on the time of its evaluation. Moreover, calling a user-defined function which in turn (directly or indirectly) calls Std.Standard.Now makes the value of the expression calling the user-defined function dependent on the time of its evaluation. Proposed Resolution ------------------- Allow a reference to an index name to be a globally static primary when the prefix denotes an object of a globally static subtype and when the index expressions are globally static expressions. Allow a reference to a slice name to be a globally static primary when the prefix denotes an object of a globally static subtype and when the discrete range is a globally static range. Allow a call to a user-defined function to be a globally static primary when the actuals to the function are globally static expressions (but see below). Allow a type conversion to be a globally static primary when the type mark denotes a globally static subtype and the expression is a globally static expression. Define the evaluation of Std.Standard.Now during static elaboration to be an elaboration error. VASG-ISAC Analysis & Rationale ------------------------------ The problems noted above are valid. The language is currently not consistent in that non-globally static expressions must be and are evaluated during static elaboration. However, with one exception (see Issue Report 0082) the LRM imperfections have the effect of overly restricting globally static expressions. As of the time of this writing, the ISAC has seen only one "real- world" example where the descriptive power of VHDL was restricted by these problems. (The example was easily rewritten to avoid the restrictions.) As any changes made here are likely to profoundly affect VHDL, the ISAC recommends that the LRM not be reinterpreted according to the above recommendations, but that, in a future round of standardization, the whole issue be carefully re-examined. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Accept the LRM as it is: Globally static expressions are (with the exception of the problem reported in Issue Report 0082) a subset of those expressions which may be evaluated during static elaboration. See Issue Report 0082 for the ISAC recommendation on this one case. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Carefully re-examine the definition of globally static expressions to include only those expressions which may be evaluated during static elaboration and that subsequently do not change value (i.e., calls to Std.Standard.Now must be excluded). An alternative method of excluding references to Std.Standard.Now is to make it something other than a function. Making it a signal has certain appeal, but either Std.Standard.Now'Stable, etc. must be defined or prohibited. Careful consideration also then needs to be given to the meaning or appropriateness of "wait on Std.Standard.Now;". Several proposals are under development that introduce other objects into VHDL; e.g., limited forms of global variables. Depending on the nature of these new objects, the current time could be referenced via one of these objects.