VHDL Issue Number: 0059 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Analyzer detection of static expressions containing deferred constants is impossible. Related Issues: 0008, 0022, 0082 Relevant LRM Sections: 7.4, 12, 12.1, 12.3 Key Words and Phrases: Deferred Constant, Full Declaration, Package, Package Body, Locally Static Expression, Globally Static Expression, Elaboration Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Section 7.2 was updated. Superseded By: N/A ----------------------- Date Submitted: 1988/11/19 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/02/23 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/03 16:00:04 $ Description of Problem ---------------------- The Analyzer must be able to determine whether a given expression is static or not. Many contexts require static expressions and the Analyzer has to diagnose errors when these requirements are not followed. A reference to a deferred constant is static if and only if the deferred constant is initialized with a static expression. This initialization occurs in a package body which need not exist when analyzing a unit that references the deferred constant. Proposed Resolution ------------------- There seem to be only two reasonable solutions to this problem. The first is to require that the value of a deferred constant always be given with a static expression. The second is to prohibit references to deferred constants in static expressions. The first of these is probably less restrictive for the user. Hence, we require that a deferred constant be initialized with a static expression. VASG-ISAC Analysis & Rationale ------------------------------ Let us first explore whether a reference to a deferred constant is a locally static primary. It is clear that a reference to a deferred constant is never a locally static primary. A locally static primary is one whose value is known at analysis time. (Paragraph 2 of Section 7.4 states that a locally static expression is an expression whose "value is dependent only upon declarations that are local to the containing design unit, or packages used by that design unit." To this we should add, when the containing design unit is a secondary unit, "the primary unit to which this secondary unit corresponds, or packages used by the primary unit to which this secondary unit corresponds." This addition is necessary as all of the declarations of a primary unit are visible when analyzing a secondary unit corresponding to the primary unit, as are all declarations in packages used by the primary unit.) The whole reason for introducing package bodies during standardization was to remove the dependence of design units on an implementation of the package interface. For example, one could describe a package interface defining a stack package, and define a simple, array-based implementation in its corresponding body. Later, one could replace this implementation with a more robust one based on linked lists. It was the intent of the VASG that one could do so without affecting those design units which depend on the package interface. This intent can only be fulfilled if design units under analysis that depend on a package interface are prohibited access to the corresponding package body. Moreover, as the author correctly states, the package body need not even exist during analysis of a unit depending on the interface. Consequently, an Analyzer can never know the value of a deferred constant; the deferred constant is therefore not a locally static primary. Now, having this analysis in hand, consider the question of whether a deferred constant may be a globally static primary. Paragraph 2 of Section 7.4 states that a globally static expression is one whose value "may be dependent upon declarations that appear in other design units within the hierarchy, or upon the process of elaboration itself." (This wording would be clearer if this part reads "... may only be dependent ....") The crux of the original report is that the corresponding full declaration of a deferred constant may be initialized with an expression that does not meet the tests outlined in Section 7.4 for locally or globally static expressions. However, given the definition of globally static expressions suggested in Issue Report 0022, however, the question is easily resolved. Deferred constants can only appear in a package interface; their completion can only appear in the corresponding body. Since these contexts are elaborated exactly once at the beginning of simulation, the constant has a known value at the start of simulation (once the package body has been elaborated). We know this because paragraph 3 of the prologue of Chapter 12 states that the design hierarchy is (once) elaborated prior to simulation. Paragraph 4 of Section 12.1 defines the elaboration of a design hierarchy as consisting of, in part, the elaboration of packages and their corresponding bodies. It also defines the elaboration of packages and their corresponding package bodies as consisting of the elaboration of their corresponding declarative parts. Section 12.3 defines the elaboration of a declarative part as consisting of the elaboration of each declarative item within the part. Paragraph 2 of this section further states that expression appearing within a declarative item must be evaluated at the time of elaboration, and that "The value of any object denoted by a primary in such an expression must be defined at the time the expression is evaluated." Thus, we see that the deferred constant declaration and its corresponding full declaration are both elaborated exactly once prior to simulation, and that an elaboration error occurs if the value expression of the full declaration cannot be evaluated at the time of its elaboration. Moreover, this value does not change during simulation, because the full declaration is never re-elaborated. Therefore, it meets the requirements of in paragraph 2 of Section 7.4 of the VHDL LRM and with the requirements of Issue Report 0022 for globally static primaries and should be considered one. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Interpret the second sentence of the second paragraph of Section 7.4 to read: "Certain forms of expressions can be evaluated during the analysis of the design unit in which they appear; such an expression is said to be *locally static*." Interpret the third sentence of paragraph 2 of Section 7.4 to read: "Certain forms of expression can be evaluated as soon as the design hierarchy is which they appear is elaborated; such an expression is said to be *globally static*." Always consider a reference to a deferred constant to be a globally static primary. Specifically, interpret item 4 on page 7-16 as reading: "4. a constant explicitly declared by a constant declaration with a globally static subtype and initialized with a globally static expression. 4a. a deferred constant." VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Modify the second and third sentences of paragraph 2 of Section 7.4 as stated above. Modify item 4 on page 7-16 as stated above. Adopt the recommendations of Issue Report 0022 (with the possible exception of the limitation on the invocation of Std.Standard.Now). These recommendations have the effect of making a reference to a deferred constant a globally static primary in all circumstances.