VHDL Issue Number: 0061 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Can aliases be used to attribute a composite subelement? Related Issues: Relevant LRM Sections: 5.1 Key Words and Phrases: Attribute specification, alias, subelement Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: LRM 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: 1990/10/02 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.5 $ Date Last Revised: $Date: 1995/08/03 16:00:27 $ Description of Problem ---------------------- If X is an alias for a subelement of an array or record object, can X appear as an entity designator in an attribute specification? This is allowed syntactically and not explicitly disallowed in the semantic description. However, the intent seems to be to allow user defined attributes on declared entities only and not on subelements thereof. Syntactically, one is prohibited from directly placing a subelement of an array or record object. Similarly, the ALL/OTHERS facility of the attribute specification places attributes on "entities ... declared in the immediately ...". Presumably this does not include the subelements of the declared entities. Proposed Resolution ------------------- The intent of the language designers seems to be to allow user- defined attributes on declared entities on not subelements thereof. It is therefore illegal to use an alias to place a user-defined attribute on a subelement of an array or record object. VASG-ISAC Analysis & Rationale ------------------------------ It does seem clear that the intent of the language is that subelements of composites not be individually attributable. This is reflected in the fact that, e.g., an indexed name is not allowed syntactically as an entity designator in an attribute specification. It seems inconsistent to allow the use of an alias as a back-door way of attributing a subelement. Furthermore, allowing attributes on subelements (using aliases) would require additional language rules to precisely define the semantics (see "VASG-ISAC Recommendation for Future Revisions"). Note that the LRM allows (syntactically) the prefix in an attribute name to be something other than a simple name but is not clear on what this means. For example, consider: attribute Count : Integer; signal R : Bit_Vector(0 to 31); attribute Count of R : signal is 10; ... if R'Count = 10 then ... ... if R(0 to 31)'Count = 10 ... In this code, it seems clear the first if statement is legal and the boolean expression evaluates to true, but the second if statement is not quite so clear. It leads into the issue of whether R is the "same object" as R(0 to 31). While this may be an interesting theoretical question, the reality of the situation seems to be that the benefit to the user of allowing a slice or subelement as a prefix in a user-defined attribute name is (given the above recommendation concerning aliases) pretty-much nil. Hence we suggest disallowing such an attribute name. There is a related language issue that came up in the ISAC discussion on this topic and will be the subject of a new IR. This issue is whether or not one could establish an alias for an implicit GUARD signal or a signal such as S'STABLE(2 NS). The real issue here is whether such signals are objects. There seems to be no problem allowing implicit GUARD signals to be aliased but there may be potential problems with aliasing signals such as S'STABLE(2 NS). One of these potential problems is the lack of a distinction between a defining occurrence and a referencing occurrence for such a signal. In any event, the ISAC has scheduled a new IR for this topic. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- (1) An alias used in an entity specification of an attribute specification must not denote an element or slice of an object. (2) The prefix in a user-defined attribute reference must not denote an element or slice of any object. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Reconsider this issue in light of all known deficiencies concerning attributes and aliases. The remainder of this section is a set of notes put together by an ISAC member on long-term options regarding this matter. These notes are intended to be "food for thought" during the development of future revisions of the language. Let Axy be an alias for a slice or subelement xy of an array or record object X and Awy be an alias for a slice or subelement wy of the same object X. Let's denote the collection of common subelements of xy and wy by y. If y is a subelement of X, then Ay will denote an alias of y. EXAMPLE 1 (array) --------- signal X is STRING (1 to 3); alias Axy: STRING (1 to 2) is X(1 to 2); alias Awy: STRING (1 to 2) is X(2 to 3); alias Ay: CHARACTER is X(2); EXAMPLE 2 (record) --------- type RECORD_TYPE is record f1 : bit; f2 : bit; end record; type RECORD_TOP is record F : bit; G : RECORD_TYPE; end record; signal X is RECORD_TOP; alias Axy: RECORD_TYPE is X.G; alias Awy: BIT is X.G.f1; alias Ay: BIT is X.G.f1; Consider an attribute specification for each of the objects X, Axy, Awy and Ay if defined: attribute Z : TYPE_; --LINE 1 attribute Z of X: signal is CX; --LINE 2 attribute Z of Axy: signal is Cxy; --LINE 3 attribute Z of Awy: signal is Cwy; --LINE 4 attribute Z of Ay: signal is Cy; --LINE 5 where CX, Cxy, Cwy, and Cy are constants of type TYPE_ . WHAT ARE THE CHOICES? All the following choices solve resolve issue 61 1. Consider an error to place an attribute on a subelement of an object. Lines 3 to 5 above are ERRORS. This is the 1987 clarification. It might be to restrictive because the problem does not appear unless more attributes are inherited by one subelement. 2. Associate attributes with names not with objects. Probably a bad idea. 3. If LINE 2 above is missing and y is not an object, (i.e. there are not common subelements) then the code defines attributes only on subelements that are attributed once. It is an error if two attributes are placed on a single element. Another choice would be to block inheritance for subelements where two or more attributes are inherited. 4. If type TYPE_ is a resolved type by an "attribute resolution function" ARF, then X'Z = ARF({CX}) xy'Z = ARF({CX, Cxy}) wy'Z = ARF({CX, Cwy}) y'Z = ARF({CX, Cxy, Cwy, Cy}) otherwise lines 3 to 5 above are ERRORS. 5. A slightly different idea, based also on the concept of resolution functions, is to declare for each attribute, a default value that any attribute will get, for any entity if there is no explicit specification for that entity or its parents. If a subelement inherited more than one attribute, then the type should be resolved by an attribute resolution function and everything is identical to choice 4 above. This stated formally is: If Z is an attribute name, X an entity, ARF a resolution function resolving the type of Z then X'Z = ARF({Ax | Ax is a declared or inherited attribute of X }) Note that this include the case of an empty set in which case the ARF will return its default value. Balancing against this approach is the order invariance problem of actual resolution functions that are defined based on an unconstrained array (VHDL issue number 11). 6. Introduce the set concept into the language. If only one attribute is declared for a subelement return that attribute otherwise return the set of all attributes. New operations are required for processing the elements of a set like for example is_in meaning: (x is_in S) is true iff x is an element of set S. Instead of a set of attributes a list might be considered but probably the most correct would be to define the attribute resolution function on a set of sets of pairs (attribute_value, number_of_apparitions).