VHDL Issue Number: 0066 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Certain OPEN associations and unassociated formals are not defined. Related Issues: Relevant LRM Sections: 4.3.3, 4.3.3.2, 5.2.1.2, 7.3.3, 12.5 Key Words and Phrases: OPEN, formal, unassociated, default expression Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Sections 1.1.1.1, 1.1.1.2, 4.3.2, 4.3.2.2 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/11 Author of Analysis: Paul J. Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/05/13 19:34:42 $ Description of Problem ---------------------- 1. The LRM does not disallow using OPEN in parameter associations and generic associations, but it does not say what this means. 2. The LRM is unclear about whether a port may be unassociated. The last paragraph before the note in LRM 4.3.3.2 suggests this is illegal but falls short of declaring it illegal. The last paragraph before the note in LRM 5.2.1.2 implies that an unassociated formal port is legal but does not say what it means. 3. The LRM appears to allow parameters of modes other than IN to include a default expression, but it does not say what this would mean (see LRM 4.3.3). It is likely this is a mistake in the LRM update from the ballot response. 4. It is not clear if defaults on formal parameters get evaluated if they are not unassociated. LRM 7.3.3 and 8.5 say that the defaults are not evaluated if they are associated. LRM 12.5 (Item 2) implies that the defaults are always evaluated. Proposed Resolution ------------------- 1. An OPEN association for a formal generic or formal parameter is equivalent to the generic or parameter being unassociated, i.e., the formal generic or formal parameter must be of mode IN and it must have a default expression. This applies to signal parameters as well as constant and variable parameters. 2. An unassociated formal port is legal. It is equivalent to the formal port being unconnected; i.e., equivalent to associating it with OPEN. 3. It is illegal to have a non-IN, non-signal interface element that has a default expression. It is illegal to have a non-IN signal parameter that has a default expression. 4. Defaults on subprogram formal parameters only get evaluated if they are unassociated. VASG-ISAC Analysis & Rationale ------------------------------ Each item in the Description of Problem and Proposed Resolution sections is considered separately here: 1. The LRM thrice states that parameters may be unassociated under certain conditions (cf. Paragraph 12 of Section 4.3.3.2 (page 4-12), Paragraph 2 of Section 7.3.3 (page 7-12), and Paragraph 3 of Section 8.5 (page 8-7)). The LRM contains no references to associating formal parameters with OPEN. Paragraph 12 of Section 4.3.3.2 (page 4.12) also states the conditions under which formal generics may be left unconnected in an association list. Paragraph 7 of Section 5.2.1.2 defines the term "unassociated formal". Since the entire section applies to both ports and generics, it would seem that generics can be unassociated. The semantics of such unassociated formals is not described in this section. Paragraph 5 of Section 5.2.2 (page 5-6) states that formal generics otherwise unassociated via the default binding rules are to be associated with OPEN as the actual designator. This paragraph thus implies that formal generics of binding indications are allowed to be associated with OPEN. The formal generics of binding indications appear to be no different than other formal generics; thus, the LRM probably allows all formal generics to be associated with OPEN. Paragraph 2 of Section 9.6 (page 9-11) states that each local generic (and port) of a component instance must be associated "exactly once." This paragraph thus seems to require that OPEN be used when no other association for a generic (or port) in a component instance is desired. However, Paragraph 1 of Section 12.2.2 (page 12-2) implies that generic map clauses need not associate each generic as it defines implicit association elements for those formals that do not have an explicit association element. Moreover, it does not define the semantics of association with OPEN. (Note that this section deals only with the generic maps of blocks statements; however, the LRM defines block statements equivalent to all component instances, which include all binding indications. Thus, this paragraph applies to all generic map clauses.) Thus, the LRM appears to allow both unassociated generics and association of generics with OPEN. Moreover, it seems to treat these cases as semantically identical. Given this analysis, item 1 of the issue author's proposed resolution seems appropriate. The ISAC examined disallowing unassociated formals in some or all cases, but no satisfactory formulation of this proposal was developed. 2. Paragraph 6 of Section 1.1.1.2 (page 1-4) discusses connected ports (those that are associated with an actual port or signal) and unconnected ports (those that are associated with OPEN). It does not discuss any other cases; i.e., unassociated ports. It therefore seems to imply that all ports must be associated. Paragraph 12 of Section 4.3.3.2 (page 4-12) discusses the conditions under which formal parameters and formal generics may be left unassociated. It is silent concerning formal ports, hence the issue author's comment that this passage suggests that unassociated ports are illegal. However, Paragraph 7 of Section 5.2.1.2 defines the term "unassociated formal". Since the entire section applies to both ports and generics, it would seem that ports can be unassociated. The semantics of such unassociated ports is not described in this section, as the issue author notes. In addition, Paragraph 6 of Section 5.2.2 (page 5-6) states that formal ports otherwise unassociated via the default binding rules are to be associated with OPEN as the actual designator. This paragraph thus implies that formal ports of binding indications otherwise unassociated are to be associated with OPEN. The formal ports of binding indications appear to be no different than other formal ports; thus, the LRM seems to indicate the semantics of unassociated ports is identical to unconnected ports (those associated with OPEN). Paragraph 2 of Section 9.6 (page 9-11) states that each local port (and generic) must be associated "exactly once." This statement seems to require that OPEN be used when no other association for a port (or generic) is desired. Paragraph 1 of Section 12.2.4 (page 12-2) omits language parallel to Paragraph 1 of Section 12.2.2 regarding the elaboration semantics of unassociated ports. This omission may be interpreted as a requirment that ports must be associated, at least with open. Another interpretation is that the semantics of unassociated ports and unconnected ports is identical, so that only one case need be considered. And the second and third bulleted paragraphs at the top of page 12-11 discuss connected and unconnected ports, but not unassociated ports, again either requiring that all ports be connected or using the assumption that unassociated ports are semantically identical to unconnected ports. Thus the LRM is unclear as to whether ports may be unassociated. It seems to allow it in some places, and defines unassociated ports (in at least one case) to be equivalent to associations with OPEN. In other places, case analyses omit the unassociated case, seemingly requiring that all ports be associated. However, in light of the equivalence, this omission of the case may also be a result of using the equivalence to reduce the number of required cases. Given this analysis, item 2 of the issue author's proposed resolution is appropriate, at least in the short-term. 3. The problem description discusses only parameters; however, the proposed resolution discusses all types of interface elements. Accordingly, this analysis covers all interface elements. a. Formal ports and their association (or lack of association) are covered in Sections 1.1.1.2, 4.3.3, and 12.2.4. Paragraph 6 of Section 1.1.1.2 (on page 1-4) indicates that a formal port may be unconnected only if its declaration includes a default expression. Paragraph 6 of Section 4.3.3 (on page 4-9) discusses interface signals, which include formal ports and formal signal parameters; it states that "the default expression defines the default value(s) associated with the interface signal or its subelements." It goes on to state that an implicit default value applies in the absence of the explicit default value. The final sentence states that "The implicit value is used to determine the initial contents of drivers...." but is silent on the explicit value, if present. It is reasonable to assume that this sentence is intended to apply to either the implicit or explicit value. Moreover, since formal signal parameters have no drivers except those associated with the actual to which they are associated (cf. paragraph 2 of Section 2.1.1.2 on page 2-3), it is further resonable to assume that this paragraph applies only to interface signals that denote formal ports and not to those that denote formal signal parameters. Paragraph 3 of Section 12.2.4 (on page 12-2) discusses the use of the default expression to provide "the value of the port" for ports of mode in without an applicable association element. It thus seems to cover one of the cases omitted from the latter two sentences of paragraph 6 of Section 4.3.3. Thus, it seems that the LRM clearly allows formal ports of all modes except LINKAGE (which is explicitly disallowed by Paragraph 5 of Section 4.3.3 on page 4-9) to have default expressions, and therefore to allow them to be unassociated or associated with OPEN. b. The association or lack of association of formal generics are covered in Sections 1.1.1.1, 4.3.3.2, and 12.2.1. Paragraph 3 of Section 1.1.1.1 (on page 1-3) indicates that a formal generic may be unconnected only "if a default expression is specified for that generic." Paragraph 12 of Section 4.3.3.2 provides that association lists for a formal generic need not include an association element for that generic if the formal has a default expression. Paragraph 2 of Section 12.2.1 (on page 12-2) states that the value of the default expression of a generic is used in the event that a generic map clause does not contain an association element for the generic. It seems clear that formal (and local) generics are allowed default expressions, whose value is used to supply the value in the absence of an association element for a given instance of the generic. c. Formal parameters and their association (or lack of association) are discussed in Sections 2.1.1ff (Formal Parameters), 4.3.3ff (Interface Declarations), 7.3.3 (Function Calls), and 8.5 (Procedure Call Statement). Section 2.1.1 contains no particular semantic restrictions on the appearance of a default expression on a formal. Section 4.3.3 states only that LINKAGE ports and ports of a file type may not have default expressions. Moreover, Paragraph 12 of Section 4.3.3.2 (on page 4-12) states that formal parameters of mode in need not be associated in a given association element if the formal has a default expression. However, both Sections 7.3.3 and 8.5 state that For each formal parameter ..., a ... call must specify exactly one corresponding actual parameter. This actual parameter is specified either explicitly, by an association element in the association list, or in the absence of such an association element, by a default expression (see Section 4.3.3). Thus, since the default expression can only supply a constant and (because of paragraph 5 of Section 2.1.1) only constant formal parameters may be associated with a constant actual parameter, it seems that default expressions are meaningful only on constant parameters, which must be of mode in. The remaining cases must be considered: It would seem that the default expression on a formal signal parameter of mode in could be used as the value to be read if no actual signal is associated with the formal, but what is the meaning of reading the attributes of the formal parameter under these circumstances? There seems to be no way to ascribe meaning to this case, so the ISAC recommends that this case be disallowed. Moreover, since a formal signal parameter is akin to an alias for the actual to which it is associated (cf. paragraph 2 of Section 2.1.1.2 on page 2-3), it seems that the only meaningful association of a formal signal parameter is with an actual signal (i.e., associating a formal signal parameter with OPEN or leaving it unassociated is meaningless). Thus, any default expression associated with a formal signal parameter of any mode can never be used, and the ISAC recommends that this case, too, be disallowed. Formal variable parameters of mode in can make use of a default expression as the value to read if no association is supplied. But what of formal variable parameters of modes out and inout? The in case of inout is identical to in mode formal variable parameters, and the out case of inout is identical to the out mode formal variable parameter, so we need only consider out mode formal variable parameters. Here it would seem that the default expression could be used to supply a value, but to where? All other default expressions are used to supply values when the corresponding formal is unassociated; the default expression on an out mode formal variable could be used only if the formal was associated. There seems to be no LRM support for this interpretation; accordingly, the ISAC recommends that this case also be diallowed. The recommendations can best be summarized in the following table: +-------+-------+-------+-------+-------+ | in | out | inout | buf. | link. | +-----------------------+-------+-------+-------+-------+-------+ | signal port | A | A | A | A | X | +-----------------------+-------+-------+-------+-------+-------+ | constant generic | A | X | X | X | X | +-----------------------+-------+-------+-------+-------+-------+ | signal parameter | * | * | * | X | X | +-----------------------+-------+-------+-------+-------+-------+ | variable parameter | Y | * | * | X | X | +-----------------------+-------+-------+-------+-------+-------+ | constant parameter | A | X | X | X | X | +-----------------------+-------+-------+-------+-------+-------+ where the rows are the various kinds of formals and the columns represent the various modes of those formals. 'X' denotes a combination where the presence of a default expression is clearly disallowed by the LRM (or a formal of that mode is disallowed by the LRM). 'A' denotes a combination where the presence of a default expression is clearly allowed by the LRM; in these cases, the default expression is used to supply the value of the formal when it is read and there is no applicable association element. '*' represents a combination where the presence of a default expression is not clearly allowed or disallowed by the LRM, or the meaning is not clearly defined by the LRM. Additionally, the ISAC recommends that these cases be disallowed. Finally, 'Y' represents a combination where the presence of a default expression is not clearly allowed or disallowed by the LRM, or the meaning is not clearly defined by the LRM. Additionally, the ISAC recommends that these cases be allowed, and that the expression be used as in the 'A' cases. 4. The LRM is silent on the evaluation times of expressions, except that it defines locally static expressions and globally static expressions, which are generally understood to be respectively Analysis-time evaluations and static-model-elaboration-time expressions. Section 12 (with imperfections as noted above) defines when the values are used, but not whether the expressions get evaluated if their value is not used. This situation is analogous to if False then I := 1/0; end if; Are any VHDL tools allowed or compelled to report this error? This is a difficult issue, for if the answer is "no tools are allowed to report an error", consider if False then I := entity; end if; Here, it seems clear that this fragment contains an error. The only consensus the ISAC can reach on this issue is to allow but not compel tools to evaluate the default expressions of formals even when the value of the default expression is not used. Similarly, conforming implementations are allowed, but not compelled, to evaluate non-static expressions before execution, even if they would never be dynamically evaluated. Note that this statement implies that any errors that would be detected during evaluation need not appear unless the expression is actually evaluated. However, whenever an expression is evaluated, any errors of evaluation must be reported. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Interpret the LRM in the areas discussed in this report as follows: 1. Adopt the interpretation of item 1 of the proposed resolution. 2. Adopt the interpretation of item 2 of the proposed resolution. 3. Adopt the interpretation of item 3 of the proposed resolution, with the exception that formal signal parameters of mode in are not allowed to have a default expression in their declaration. This exception implies that they must be associated in every applicable association list. 4. Assume that default expressions on all formals need only be evaluated if a corresponding association list does not include an association element for the formal; however, the expression can be evaluated even if every corresponding association list contains an association element for the formal. 5. Assume that non-static expressions may also be "pre-evaluated." 6. Assume that errors uncovered during the evaluation of an expression are reported, whether the value of the expression is used or not. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Codify the preceding recommendations into the new LRM. Note that 5 may be difficult to include unless a future LRM discusses more formally evaluation time and errors. Also, per the analysis above: 1. Rewrite paragraph 6 of Section 4.3.3 to make it clear that it applies only to interface signals that denote formal ports and not to those that denote formal signal parameters. 2. Rewrite the last sentence of paragraph 6 of Section 4.3.3 to read: The value, whether implicitly or explicitly provided, is used to determine the initial contents of drivers, if any, of the interface signal, as specified for signal declarations." (The "if any" parenthetical comment is moved to clearly associate it with "drivers" rather than with "interface signal", as it is in 1076-1987.)