VASG Issue Number: 0154 Comment Author: Laurence Groves Comment Number: ? Comment Date: 1992/06/02 Folks, An issue came up as to whether an attribute declaration or attribute specification may be a declarative item in a package body. Two IRs, IR 40 and IR 154 fell out as relevant to the question. IR 40 has been analyzed and approved by the ISAC (but not by the VASG as a whole) and IR 154 has yet to be analyzed. However, upon reading IR 40 it seems that IR 154 should be closed. IR 154 has the following description and proposed resolution: Description of Problem ---------------------- An attribute specification cannot be a package body declarative item. While an attribute specified in a package body is not accessible outside of the body (by the language) it is accessible by tools. This prohibition seems unnecessary. Proposed Resolution ------------------- Add attribute specification as one of the alternatives under package body declarative item. However, part of IR 40, which deals more generally with attribute specifcation and declaration, states: . . . VASG-ISAC Analysis & Rationale ------------------------------ . . . 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. . . . VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- 1. Attribute (and disconnection) specifications are declarative-part based, subject to the exceptions described below. . . . 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. . . . So it is clear that IR 40 covers the issues raised by IR 154, and I recommend that IR 154 be closed. Another issue, not addressed here, is the affect of LCS 7, which appears to reverse the above position, and allows attribute specification (but not declaration) within a package body. Yours, Larry Groves Synopsys, Inc. larry@Synopsys.COM