VHDL Issue Number: 0186 Classification: Language Definition Problem Language Version: VHDL-87 Summary: VPI Issue 10 -- Entity class type vs. subtype Related Issues: 0193 Relevant LRM Sections: 3.1.2 paragraph 2 Key Words and Phrases: Anonymous Type Current Status: Analyzed 1076-1993 Disposition: Superseded (ISAC Issues Outstanding) Disposition Rationale: N/A Superseded By: 1047 ----------------------- Date Submitted: 1991/03/15 Author of Submission: J. R. Armstrong Author's Affiliation: Virginia Polytechnic Institute and State University Author's Post Address: Bradley Department of Electrical Engineering Virginia Polytechnic Institute and State University Blacksburg, VA 24061 Author's Phone Number: (703) 231-4723 Author's Fax Number: Author's Net Address: JRA@VTVM1.CC.VT.EDU ----------------------- Date Analyzed: 1991/12/03 Author of Analysis: Clive Charlwood Revision Number: $Revision: 1.11 $ Date Last Revised: $Date: 1995/08/03 21:04:57 $ Description of Problem ---------------------- Should the entity_class of "a", which is declared as a "type", in the attribute_specification of the following test be "type" or "subtype"? Test File: ch05/s01/01020101.vhd Comment: The LRM would indicate that "a" is a "type", yet "a" is a constrained integer so it would also seem that "a" is a subtype. -- ##51001211221FF51001225100123********************************************** --+ File: [SUITE.CH05.S01]01020101.VHD -- --+ Copyright: (c) 1987, 1988 by CAD Language Systems, Inc. All rights reserve -- --+ LRM_version: IEEE Std. 1076-1987 -- --+ Subsets: -- --+ Description: -- --+ Test_point - (050100_010201) In the attribute specification, the reserved -- word attribute must be followed by an attribute designator and the reserve -- word of. -- --+ Test_objective (1)- Test that the attribute specification satisfies the -- given syntax diagram. -- --+ References : Secondary LRM Coverage: 050100_010202, 050100_010203 -- --+ Instructions: None -- --+ Keywords: attribute specification, design unit -- --+ Test_Results: Expect_success. Output_checked. -- --+ Test_type: Syntactic -- --+ History: Created /CLSI 08-30-88 -- Modified RA/Vtech 04-15-89 -- Corrected CHC/Vtech 12-20-89 -- Modified CHC/Vtech 5-4-90 -- --+ Comments: CLSI-FILE : [000000.SPECS.ATTR]16 -- Zycad claimed that this should be an expect failure test -- because 'a' is a subtype and thus the entity class of the -- attribute specification should be 'subtype', not 'type'. -- It will be sent to VASG for the clarification. -- --**************************************************************************** package p16 is type a is range 1 to 10; attribute arbitrary: integer; attribute arbitrary of a : type is 5; -- No_Failure_here end; Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ LRM section 3.1.2 paragraph 2 specifies that: An integer 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 integer 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. From this section, it is clear that the example above creates a subtype named "a" and an anonymous type that is the base type of this subtype. It should also be noted that the range of the anonymous type is, although guaranteed to "contain" the range of the subtype, not guaranteed to be identical to it. The language was designed this way to allow make the manipulation of integer values easier. Since an implementation is allowed to make each of the anonymous types have the same range the internal representation for all integer types could be identical. This does not cause problems for most uses of integer. However, in a several (relatively minor) places a user will get unexpected results. 1) The predefined attributes 'LEFT, 'RIGHT, 'LOW, 'HIGH for the "anonymous" type are not guaranteed to be the range this specified in the type declaration. They are instead implementation dependent. Therefore, the following code MAY generate assertion errors on some implementations: process type a is range 5 to 10; begin assert 5 = a'base'left; -- Potential Error assert a'left = a'base'left; -- Potential Error assert 10 = a'base'left; -- Potential Error assert a'right = a'base'left; -- Potential Error wait; end process; 2) It is not possible to attribute the "anonymous" type. (see the test case above). process type a is range 1 to 10; attribute arbitrary: integer; attribute arbitrary of a : type is 5; -- Unexpected Error attribute arbitrary of a : subtype is 5; -- Correct begin wait; end process; VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Since the LRM is clear, no changes need to be made in the interpretation. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- When the language is modified for future revisions the designers should consider cleaning up these points. One way to do this would be to "special case" the semantics for the examples above to do "what the user expects". This does make the definition of both predefined and user defined attributes more complicated. This may not be desirable.