VHDL Issue Number: 1096 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Entity aspect poorly defined for incremental binding. Related Issues: Relevant LRM Sections: 1.3.2, 5.2.1, 5.2.2 Key Words and Phrases: incremental binding, binding indication, entity aspect, component configuration Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/08/22 - 1994/09/09 Author of Submission: Daniel S. Barclay Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd. Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-992-3536 Author's Net Address: daniel@compass-da.com ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- There are a number of problems with the definition of constructs used for incremental binding. 1) The optional entity aspect intended for an incremental binding indication is never actually legal. LRM wording defining a component configuration in terms of an equivalent configuration specification does not seem to have been updated properly. 2) The entity aspect in an incremental binding indication is not restricted to be consistent with the entity aspect of the primary binding indication. 3) All rules referrring to the presence of a binding indication are ambiguous. 4) Other wording about incremental binding is not as clear as it could be. [LRM quotes are from the almost-final 1994/06/24 version. The notation {\i word} indicates that the word (or words) is italicized; {\b word} indicates that the word (or words) is in boldface type.] 1) Impossible Optional Entity Aspect Section 5.2.1 defines that, syntactically, the entity aspect of a binding indication is optional. binding_indication ::= [ {\b use} entity_aspect ] [ generic_map_aspect ] [ port_map_aspect ] However, according to other LRM wording, it is never legal to omit the entity aspect. Section 5.2.1 says: When a binding indication is used in a configuration specification, it is an error if the entity aspect is absent. This rules out omitting the entity aspect in a binding indication in a configuration specification. This restriction is fine. Section 1.3.2 says: If the component configuration contains a binding indication (see 5.2.1), then the component configuration implies a configuration specification for the component instances to which it applies. This implicit configuration specification has the same component specification and binding indication as that of the component configuration. This rules out omitting the entity aspect in a binding indication in a component configuration. (If a component configuration's binding indication does not have an entity aspect, then the implicit configuration specification has the same binding indication (that is, one with no entity aspect), and that is an error.) There are no other uses of binding indication in the syntax. Therefore it is never legal to have a binding indication that does not have an entity aspect. This result does not seem to be intended. I believe that the problem is that the quoted paragraph from section 1.3.2 was not updated to reflect the intent. 2) Unrestricted Entity Aspect in Incremental Binding Indication The LRM contains no wording to restrict an entity aspect in an incremental binding indication from contradicting the entity aspect of a corresponding primary binding indication. For example, not LRM wording makes the following example illegal: for inst : comp use entity e; ... for inst: comp use entity f; -- surely an error; but LRM doesn't say so end for; Similarly, the LRM does not address the following: for inst : comp use entity e; ... for inst: comp use entity e(a); -- is this allowed? end for; and: for inst : comp use entity e(a); ... for inst: comp use entity e; -- is this allowed? end for; or for inst: comp use configuration c; -- is this allowed (c is a configuraton -- declaration for entity e)? end for; If the optional entity aspect is present in an incremental binding indication, it should not contradict the original entity aspect. Probably, it should not specify more than the original (unless incrementality is intended here too). Possibly, it should not specify any less than the original. (Remember that it can be omitted entirely). 3) Ambiguous binding indication presence Now that all parts of a binding indication are optional according to the syntax (because entity aspect is now optional), all rules that stated in terms of the presence of a binding indication are ambiguous. ?you? can't tell whether the whole binding indication is present or whether it is present with all parts omitted. Section 1.3.2 defines that the binding indication of a component configuration is syntactically optional: component_configuration ::= {\b for} component_specification [ binding_indication ; ] [ block_configuration ] {\b end for} ; Section 5.2.1 defines that all parts of a binding indication are syntactically optional: binding_indication ::= [ {\b use} entity_aspect ] [ generic_map_aspect ] [ port_map_aspect ] Consider the following component configuration: for CI : C end for; Either this component configuration has no binding indication, or it has a binding indication that has no entity aspect, no generic map aspect, and no port map aspect. But which is it? Is the binding indication present of not? One must be able to answer that question to apply a number of related rules: Section 1.3.2 says: If the component configuration contains a binding indication (see 5.2.1), then the component configuration implies a configuration specification for the component instances to which it applies. Do the example component configuration implies a configuration specification or not? Section 1.3.2 also says: If a given component instance is unbound in the corresponding block, then any explicit component configuration for that instance that does not contain an explicit binding indication will contain an implicit, default binding indication (see 5.2.2). Will it contain an implicit, default binding indication? Section 5.2.1 says: A binding indication appearing in a component configuration need not have an entity aspect under the following condition: The block corresponding to the block configuration in which the given component configuration appears is required to have one or more configuration specifications that together configure all component instances denoted in the given component configuration. Under this circumstance, these binding indications are the {\i primary binding indications}. It is an error if a binding indication appearing in a component configuration does not have an entity aspect and there are no primary binding indications. It is also an error if, under these circumstances, the binding indication has neither a generic map aspect nor a port map aspect. This form of binding indication is the {\i incremental binding indication}, and it is used to {\i rebind incrementally} the ports and generics of the denoted instance(s) under the following conditions: ... Section 5.2.1 also says: If the generic map aspect or port map aspect of a binding indication is not present, then the default rules as described in 5.2.2 apply. Obviously no map aspects are present. But is there a binding indication with omitted map aspects, or is there no binding indication at all? Section 5.2.2 says: These visibility checks are made at the point of the absent explicit binding indication that causes the default binding indication to apply. Are the referenced visibility checks made or not? Section 5.2.2 also says: If an explicit binding indication lacks a generic map aspect, and if the design entity implied by the entity aspect contains formal generics, then the default generic map aspect is assumed within that binding indication. Similarly, if an explicit binding indication lacks a port map aspect, and the design entity implied by the entity aspect contains formal ports, then the default port map aspect is assumed within that binding indication. Are default generic and port map aspects assumed or not? 4) Additional Wording Problems: Section 5.2.1 says: A binding indication appearing in a component configuration need not have an entity aspect under the following condition: The block corresponding to the block configuration in which the given component configuration appears is required to have one or more configuration specifications that together configure all component instances denoted in the given component configuration. ... This is not stated clearly and completely logically. The first sentence states a requirement in terms of a condition to be stated in the second sentence, but the second sentence says "is required" as if it it imposing a requirement. (The requirement is on the _combination_ of the entity aspect's presence and the configuration specifications, at that is not even stated explicitly.) Why not say this more clearly as: A binding indication appearing in a component configuration need not have an entity aspect under the following condition: The block corresponding to the block configuration in which the given component configuration appears has one or more configuration specifications that together configure all component instances denoted in the given component configuration. ... (or possibly the following, if various following text is rewritten appropriately): A binding indication appearing in a component configuration must have an entity aspect unless the block corresponding to the block configuration in which the given component configuration appears has one or more configuration specifications that together configure all component instances denoted in the given component configuration. ... or A binding indication appearing in a component configuration may appear without an entity aspect under the following condition: The block corresponding to the block configuration in which the given component configuration appears has one or more configuration specifications that together configure all component instances denoted in the given component configuration. ... The section 5.2.1 paragraph continues: ... Under this circumstance, these binding indications are the {\i primary binding indications}. It is an error if a binding indication appearing in a component configuration does not have an entity aspect and there are no primary binding indications. It is also an error if, under these circumstances, the binding indication has neither a generic map aspect nor a port map aspect. This form of binding indication is the {\i incremental binding indication}, and it is used to {\i rebind incrementally} the ports and generics of the denoted instance(s) under the following conditions: The wording "this circumstance" is ambiguous. Does it refer to the condition specified in the second sentence or to the condition of there not being an entity aspect? The wording "these circumstances" is similarly ambiguous and confusing. Is the use of "these circumstances" meant to point out something different than "this circumstance" does? Finally, the wording "this form of binding indication" is ambiguous. I assume that this means the form without a binding indication, but coming right after two sentences about error conditions, it isn't perfectly clear. After the wording "under the following conditions", the LRM lists three conditions, but then it specifies an error condition: * It is an error if a formal port appears in the port map aspect of the incremental binding indication and it is a formal port that is associated with an actual other than {\b open} in one of the primary binding indications. This error condition is not a condition under which the binding indication incrementally rebinds the ports and generics; it should be a regular paragraph, not a bulleted paragraph. Proposed Resolution ------------------- 1) for Impossible Optional Entity Aspect: Update the definition in section 1.3.2 of a component configuration in terms of a configuration specification to account for incremental binding. 2) for Unrestricted Entity Aspect in Incremental Binding Indication: Specify appropriate restrictions on the entity aspect of an incremental binding indication. Probably restrict it to specifying the same thing as the primary binding indication's entity aspect. Probably put such restrictions in the latter part of section 5.2.1, which already conditions on the generic and port map aspects of incremental binding indications. 3) for Ambiguous binding indication presence: Define how to know whether a binding indication is present, or reword rules referring to the presence of binding indications to refer to the presence of whichever construct really counts. 4) for Additional Wording Problems: Clarify appropriately. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD