VHDL Issue Number: 0021 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Non-locally-static universal expressions must be restricted. Related Issues: Relevant LRM Sections: 7.5 Key Words and Phrases: Locally static expressions, universal expressions Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Section 7.5 was updated. Superseded By: N/A ----------------------- Date Submitted: 1989/02/10 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #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/06/15 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/05/13 21:53:48 $ Description of Problem ---------------------- It would be a significant burden to support universal arithmetic at elaboration time. The intention of LRM 7.5 is to prevent this. However, "static" appears in this paragraph where "locally static" should appear. Proposed Resolution ------------------- We assume "static expression" and "non-static universal expression" in the last two paragraphs of LRM 7.5 are replaced with "locally static expression" and "non-locally-static universal expression", respectively. VASG-ISAC Analysis & Rationale ------------------------------ Section 7.5 of the VHDL LRM, which states in part ... if a universal expression is a static expression, then the evaluation must be exact. was adopted nearly intact from Section 4.10 of the Ada LRM. The only changes were to remove references to Ada concepts not appearing in VHDL, such as exceptions and objects in package SYSTEM. Ada defines only one kind of static expression, the kind that is compile-time computable (see Section 4.9 of the Ada LRM). However, VHDL defines two; one that is analysis-time computable ("locally static expressions") and another that is computable during model elaboration ("globally static expressions")-- see Section 7.4 of the VHDL LRM. VHDL further defines the term "static expression" to encompass both locally static expressions and globally static expressions. Therefore, the VHDL LRM requires exact evaluation of universal expressions during analysis and during model elaboration, while the Ada LRM requires exact evaluation of universal expressions only during compilation. This is the crux of the author's issue. The issue author wishes to make VHDL conform to Ada by substituting the term "locally static" for the occurrence of "static" in Paragraph 3 of Section 7.5 of the VHDL LRM, and by substituting "non-locally static" for "non-static" in Paragraph 4 of the same section. The author states that exact evaluation during model elaboration is "a significant burden." This statement is not self-evident--the same code used in an analyzer to perform exact expression evaluation can presumably be used in a model elaborator to perform the same task. Nevertheless, because of the lack of named numbers (see Section 3.2.2 of the Ada LRM) in VHDL, there are comparatively few ways to generate universal expressions in VHDL that are globally static but not locally static. Thus, in the short-term, there seems to be little harm in adopting the issue author's recommendation. However, the VASG may wish to revisit this issue in the long-run. Not only is it unclear how burdensome is the exact evaluation of globally static universal expressions, but the LRM language appears to suffer several defects. Specifically, the LRM uses, but does not define the term "exact." It seems clear that for expressions of type universal_integer, "exact" implies that no overflow can occur. The meaning of "exact" is not clear in the case of expressions of type universal_real. Does it mean that no overflow during evaluation can occur? Does it mean that no underflow can occur during evaluation? Does it mean that the evaluation must proceed with infinite precision? Or does it mean that two or all three of these properties must hold during evaluation? Moreover, the LRM uses the term "accuracy." Mathematically, "precision" defines the number of digits carried in a calculation, while "accuracy" defines the number of those that are correct. The precision of a computer-based calculation is a function of the underlying representations of numbers, while the accuracy is a function of the algorithms employed. It seems that the VHDL LRM (and, by extension, the Ada LRM) mean "precision" when the term "accuracy" is employed (and "precise" when "accurate" is used). The VASG should certainly discuss this issue during the next pass on the language. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Adopt the issue author's recommendations. Specifically, Paragraphs 3 and 4 of Section 7.5 of the VHDL LRM should be read as follows: The accuracy of the evaluation of a universal expression of type universal_real is at least as good as that of the most accurate predefined floating point type supported by the implementation, apart from universal_real itself. Furthermore, if a universal expression is a locally static expression, then the evaluation must be exact. For the evaluation of an operation of a non-locally static universal expression, the following rules apply. If the result is of type universal_integer, then the values of the operands and the result must lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself. If the result is of type universal_real, then the values of the operands and the result must lie within the range of the floating point type with the widest range provided by the implementation, excluding type universal_real itself. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revisit the whole issue. If the exact evaluation of globally static expressions is not deemed unduly burdensome, require their exact evaluation. Define the term "exact" for all universal expressions. Determine whether the terms "precision" and "precise" are to be used instead of the terms "accuracy" and "accurate"; define whichever terms are then used.