VHDL Issue Number: 0040 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Attribute specifications are not well defined. Related Issues: Relevant LRM Sections: 5.1 Key Words and Phrases: Attribute specifications, declarative part, declarative region Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: As specified by this IR attribute specifications have been changed to make them declarative part based. 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/06/13 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.7 $ Date Last Revised: $Date: 1995/05/13 19:34:42 $ Description of Problem ---------------------- There are three separate problems here. First, the paragraph from LRM 5.1 beginning "An attribute specification with the ..." mistakenly disallows block ... attribute x of all:signal is 0; begin block ... attribute x of all:signal is 0; begin ... end block; end block; The paragraph should either deal with occurrences "immediately within" a declarative region or it should deal with declarative parts. Second, the paragraph from that section beginning "An attribute specification for an attribute ..." is inconsistent with previous paragraphs since the former is based on declarative parts and the latter is based on declarative regions. Finally, one cannot put an attribute on an interface object since these items are not declared in a declarative part. Disconnection specifications have the same problems as attribute specifications. Proposed Resolution ------------------- These matters were discussed with CLSI. At that time their intent was to base LRM 5.1 entirely on declarative parts, not declarative regions. Accordingly, we will implement this. Interface objects are treated as a special case. For the purpose of the attribute specifications rules, they are assumed to be declared in the declarative part associated with the entity or subprogram. These same interpretations hold for disconnection specifications. VASG-ISAC Analysis & Rationale ------------------------------ User-defined attributes exist in VHDL for the purpose of annotating named entities with static information. They are primarily intended to convey technology- and tool-specific information and to provide a mechanism for back- annotation of designs. Unlike generics, which can pass information only into a model, attributes were intended to convey limited amounts of static information out of a model; for example, the drive capabilities or capacitance of a port. Thus, interface declarations must be attributable. However, a strict interpretation of LRM section 5.1 does not allow this, as interface declarations are not introduced in a declarative part. The ISAC considered two possible approaches to fixing this problem: 1. Allow attribute specifications to be declarative region-based, as considered by the issue author. 2. Allow the interface objects of an entity, subprogram, or block to be attributed within the declarative part of the entity, subprogram or block to which they belong. Approach 1 does not work, mostly because of problems encountered when considering the need to attribute entities declared in an entity interface or package from within a corresponding architecture or package body, respectively. This issue is discussed below. Approach 2 is a straightforward extension of the current approach. Note that this approach does not allow the generics or ports of a component declaration to be attributed, since there is no declarative part associates with a component declaration. However, this does not appear to be a serious limitation, since the local generics and ports of a component declaration are only "place holders." During the discussion of this issue, it was noted and agreed that many of the statements made in the paragraphs following the "Note:" heading in Section 5.1 are not in fact consequences of the LRM rules delineated in the section. These statements should be incorporated into the body of the section. The major issue discussed by the ISAC is whether or not one can attribute an item declared in an entity (or package) from within a corresponding architecture (or package body). This capability may be very useful for synthesis, timing models, delay loading calculations, etc. Allowing this capability causes three problems: 1. It is difficult to cleanly define. It seems appropriate to disallow, for example, an attribute specification within a block from applying to a visible entity declared outside of the block. It is not apparent how to allow the desired properties without introducing this or other undesirable properties. 2. Such a capability would greatly (and negatively) affect at least some implementations. A straightforward approach to the implementation of specifications is to decorate the named entity with the information contained in the specification. However, when the entity appears in one design unit and the applicable specification appears in another, many problems result. One cannot analyze the specification without modifying the library unit containing the entity, which can lead to potential circular chains of dependence. Moreover, multiple architectures corresponding to a given entity interface cannot each supply a different value to the attribute of some interface-resident entity. Finally, there is no LRM requirement that, if one architecture attributes some interface-resident entity, then all must, which seems desirable. 3. Interface objects are visible by selection, but selected names do not provide this visibility. Thus, if P is a formal parameter of a function F and F is directly visible, "F.P" does not denote the formal. Hence, "F.P'A" does not denote the attribute A of P. Given these problems and given the potential for better annotation facilities in the 1076-1992 version--out-mode generics are one possibility--the ISAC decided to disallow in 1076-1987 the capability to attribute from within a secondary unit entities declared in the corresponding primary unit. Finally, the last paragraph of Section 5.1 (under "Note:" [sic]) is felt by the ISAC to be not particularly meaningful and in need of rephrasing. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- 1. Attribute (and disconnection) specifications are declarative-part based, subject to the exceptions described below. 2. Interface objects declared in entity interfaces, subprogram bodies, and block statements may be attributed by attribute specifications appearing in the declarative part of the corresponding entity interface, subprogram body, or block statement. Such attributes are then not visible from outside of the respective design entity, subprogram body, or block statement. 3. It is not possible to use an attribute specification in an architecture or package body to supply the value for an attribute of an entity declared in the corresponding entity interface or package interface. 4. Treat the first four paragraphs appearing in the "Note:" section of LRM Section 5.1 as part of the main body of the Section; i.e., they are not notes but LRM rules. 5. Disregard the last paragraph appearing in the "Note:" section of LRM Section 5.1. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Section 5.1 should be rewritten to ensure that attribute declarations are declarative-part based. The second introductory paragraph to Chapter 5 is full of references to declarative regions; it should be similarly rewritten. (Section 5.3 may need similar edits.) Section 5.1 (and, as needed other sections) should be rewritten to clearly state the validity of, and (if valid) the effect of 1. independent subelement attribution of composite entities, including if and how they may be read at other than the level at which they were attributed; e.g., constant C1: Bit_Vector := "0000"; constant C2: Bit_Vector := "1111"; attribute A: integer; attribute A of C1(0): constant is 0; attribute A of C1(1): constant is 1; attribute A of C1(2): constant is 2; attribute A of C1(3): constant is 3; attribute A of C2: constant is 42; -- Consider "C1'A". Is it legal? If so, what is its type? -- What is its value? What about C2(1)'A? (Note: 1076-1987's syntax allows only identifiers, "all" or "others" as the entity names in attribute specifications, but the effect of the above example can be achieved with aliases.) Similar problems exist when attributing slices and when reading the attributes of slices. 2. attribution of interface objects, the visibility of the resultant attributes, and the form of name used to denote these attributes; and 3. attribution of an entity in a primary unit from a corresponding secondary unit, and the visibility of the resultant attribute. The "Note:" section of Section 5.1 should be cleaned up, transferring those statements that are not notes to the main body of the section and restating the final note, which is confusing or meaningless. Out-mode generics or some similar mechanism should be considered as a mechanism for passing constant information out of a design entity.