VHDL Issue Number: 0023 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Can secondary units' position numbers be outside the bounds of the physical type? Related Issues: none Relevant LRM Sections: 3.1.3, 3.1.3.1, 14.2 Key Words and Phrases: Physical Type, Secondary Unit, Range Checking Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: VHDL-93 LRM was updated. Superseded By: N/A ----------------------- Date Submitted: 1990/11/01 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: 1991/01/03 Author of Analysis: Alex Zamfirescu Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/02 23:51:22 $ Description of Problem ---------------------- The file RGRCE_03_046_TH_PE_001.VHD in the Intermetrics test suite contains the following physical type definition: type time is range 10 to 20 units fs; -- ERROR: a value must be specified, 1 is not in the base range ps = fs; end units; The test states that the secondary unit declaration is illegal, citing the first note at the end of Section 3.1.3: The above definitions imply that, if 1 is not in the range specified by the physical type definition, then the name of the base unit standing alone is not a legal literal of the physical type. Since the LRM defines a secondary unit declaration with the following production, identifier = physical_literal ; the implication is that a range check is performed at the point of definition of secondary literals. This interpretation is problematic. By way of illustration, consider the following three physical type definitions: 1. type time is range 10 to 20 units fs; ps = 1 fs; end units; This physical type definition is semantically identical to the one in the test case; however, the cited note does not apply. Is it still illegal? 2. type time is range 10 to 20 units fs; ps = 1000 fs; end units; This physical type definition contains a secondary unit whose position number is outside of the bounds of the physical type. The LRM does not disallow this case, but it seems quite close in spirit to the previous two cases. 3. type TIME is range -2147483647 to +2147483647 units fs; -- femtosecond ps = 1000 fs; -- picosecond ns = 1000 ps; -- nanosecond us = 1000 ns; -- microsecond ms = 1000 us; -- millisecond sec = 1000 ms; -- second min = 60 sec; -- minute hr = 60 min; -- hour end units; This physical type is type Std.Standard.Time from Section 14.2, with the range defined to be the minimum permissible range specified in Sections 3.1.3 and 3.1.3.1. Note that the secondary units ms, sec, min, and hr are all outside of the bounds of the specifed range. Since the LRM does not disallow specification of these secondary units, the implication is that these are legal. The proper conclusion is that no range check occurs at the point of secondary unit declaration. Thus, in the absence of another check for the case specified in the cited note (which is not specified anywhere else in Section 3.1.3), all of the physical type declarations presented above should be legal. Since secondary units define only scale factors, this interpretation should not cause any difficulty. Proposed Resolution ------------------- Explicitly allow secondary units to be defined with position numbers outside of the defined range of their corresponding physical type. I suggest the following LRM language, to be added to the end of paragraph 4 (which begins "Each unit declaration ....") of Section 3.1.3: The position numbers of unit names (either the base unit or secondary units) need not lie within the range specified by the range constraint. VASG-ISAC Analysis & Rationale ------------------------------ The LRM 3.1.3 Physical Types (second paragraph) states A physical type definition defines both a type and a subtype of that type. The type is an anonymous type, the range of which is selected by the implementation; this range must be such that it wholly contains the range given in the physical type definition. The subtype is a named subtype of this anonymous base type, where the name of the subtype is that given by the corresponding type declaration and the range of the subtype is the given range. Ideally implementations should use "universal" (unbounded) arithmetic in computing the units' position numbers for a physical type in order to wholly contain the range of any given physical type definition. In fact the proposed intermediate form standard contains a choice of 32 bit, 64 bit, or string representation for the position of the units. However implementing these representations of the units without allowing any constraint errors or numeric errors when elaborating the type are difficult and slow and the LRM was found incomplete in requiring infinite precision. As a compromise the following consensus was reached. In the same way that an implementation may restrict the bounds of a physical type, an implementation will be allowed to restrict the position numbers of the units in a physical type definition. An implementation is required to support position numbers for units of physical types up to 2**31-1. Beyond this limit, an implementation is free to reject a physical type definition. This restriction should not be confused with the one stated in LRM 3.1.3 (paragraph before examples) which refers to the range constraint: An implementation may restrict the bounds of the range constraint of a physical type. However, an implementation must allow the declaration of any physical type whose range is wholly contained within the bounds -2147483647 and +2147483647, inclusive. The following illustrates the relative position of these intervals: UNIT POSITIONS MAY BE HERE_______ | OR HERE | |unit positions v v |greater than _______|_____*______________________________________*_|this________ ^ | | ^limit | \______________ _______________/ |are not portable | V | | actual physical type range | -2147483647 2147483647 \________________________ _____________________/ V minimal range constraint per LRM 3.1.3 Example number 1 in this IR is correct, and example number 2 is also correct. Also the first example in the Description of Problem of this IR is correct (the example that begins after "... physical type definition: " and has a commented ERROR). The third example is legal but not portable in light of the resolution forcing implementations to accept at least 2**31-1 for a physical type unit position number. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Add the following to the end of paragraph 4 (which begins "Each unit declaration ....") of Section 3.1.3 of the LRM: The position numbers of unit names (either the base unit or secondary units) need not lie within the range specified by the range constraint. Add the following to the end of paragraph 45 (which begins "An implementation may restrict....") of Section 3.1.3 of the LRM: An implementation must allow the declaration of any physical type whose unit position numbers are less than 2**31-1. Delete the misleading LRM 3.1.3 note: The above definitions imply that, if 1 is not in the range specified by the physical type definition, then that name of the base unit standing alone is not a legal literal of the physical type. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- These are the possibilities: 1. Require universal arithmetic for position numbers. 2. Require a limit derived from the 64 bit representation. This will make example 3 (and the 1987 std.standard) portable. 3. Require the 64 bits representation just for type time and a 2**31-1 limit for any other physical type. 4. Require 64 bits for time and 2**31-1 limit for any other "discrete physical type", and introduce a concept of a "continual physical type" for which arithmetic is defined in terms of real representations of the units. Require compliance with another IEEE standard for the real computations.