VHDL Issue Number: 2041 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Association of members is too restricted Relevant_LRM_Sections: 4.3.2.2 Related_Issues: Key_Words_and_Phrases: port association Authors_Name: Craig Howland Authors_Phone_Number: (973) 386-8572 Authors_Fax_Number: Authors_Email_Address: Craig.Howland@lucent.com Authors_Affiliation: Lucent Technologies Authors_Address1: 67 Whippany Rd Authors_Address2: Whippany, NJ 07981-0903 Authors_Address3: U.S.A Current Status: Forwarded Superseded By: ------------------------ Date Submitted: 18 August 2004 Date Analyzed: 21 September 2004 Author of Analysis: Chuck Swart Revision Number: 4 Date Last Revised: 28 January 2005 Description of Problem ---------------------- Section 4.3.2.2 "Association Lists" puts three restrictions on associations which don't make sense. (At least not that I have been able to figure out.) 1) most seriously: "It is an error if an actual of OPEN is associated with a formal that is associated individually." This is stupid. It prevents something like the following: component x is port ( clock: in std_logic; count: out std_logic_vector(32 downto 0)); ... signal use_count: std_logic_vector(31 downto 0); ... counter: x port map ( clock => clk, count(use_count'range) => use_count, count(32) => OPEN); The reason for calling it "stupid" is that it is fine to ignore outputs whenever you want to if the port is not an aggregate, so why shouldn't it be OK if the object is has been grouped as an aggregate to make coding better? (One could declare 33 individual count outputs--count32, count31, etc.--for x, but that would be ridiculous.) The next two are much smaller complaints related to the last part of the sentence: "Furthermore, every scalar subelement of the explicitly declared interface object must be associated exactly once with an actual (or subelement thereof) in the same association list, and all such associations must appear in a contiguous sequence within that association list." 2) Why should the subelements need to be with each other? The example above would comply, but the following small change would not: counter: x port map ( count(use_count'range) => use_count, clock => clk, count(32) => OPEN); 3) Why must there be an association for each member? If the ports had been count32...count0, it is allowed to leave out count32, so why should count(32) be required to be present? (It is a good warning, just as leaving count32 out would be, but it is not an error.) Proposed Resolution ------------------- In general, the rules for object members addressed individually should be the same as if they had been declared as separate ports. Declaring composites is a mechanism designed to make for cleaner, more-readable code, and putting rules on the addressing of members that don't apply to scalars does not make sense as it removes some of the utility of the aggregate mechanism. Related to the first problem, I think that part of the problem is the supporting sentence: "An actual of OPEN counts as the single association allowed for the corresponding formal, but does not supply a constant, signal, or variable (as is appropriate to the object class of the formal) to the formal." When an individual association is made, there is no single association for the member; there must be multiple associations. The OPEN should only apply to the members to which is is assigned. Additionally, the OPEN should be allowed be applied as an automatically-sized vector, such that the following would be allowed (slightly different from the example in the description): component x is port ( clock: in std_logic; count: out std_logic_vector(32 downto 0)); ... signal use_count: std_logic_vector(15 downto 0); ... counter: x port map ( clock => clk, count(use_count'range) => use_count, count(32 downto use_count'high+1) => OPEN); (This latter suggestion might be the original intent of the restriction. Making the example in the problem description valid is most important. The OPEN for a variable sub-range is less so.) VASG-ISAC Analysis & Rationale ------------------------------ Note that section 1.1.1.2 also contains related restrictions: "It is an error if some of the subelements of a composite formal port are connected and others are either unconnected or unassociated." The current LRM is clear and consistent on the issues which have been raised. Therefore, since there is no compelling reason to change the existing interpretation of the LRM, the ISAC recommends that this issue be forwarded as a language enhancement to the Modeling and Productivity group. Here are some considerations: 1.The major technical problem with OPEN/unassociated subelement association deals with input ports. The single declaration of the port would have to have a default expression whose evaluation would produce a composite. Some members of this composite would then be used for values of OPEN or unassociated members: values corresponding to associated members would have to be discarded. The LRM does not have any similar "partial evaluation" situations. Certain situations are difficult to resolve. For example, suppose that the port declaration is an unconstrained bit_vector with initial value "0000". Subelement association is done to subelements 1,2,3,4,6. How is value 5 determined? Also, there may be problems with OPEN/unassociated subelements when the port type is a resolved composite type. In addition consider the case of a constrained port with default value (OTHERS => func1) where func1 is an impure function. Is this function called once for every element or once per unassociated element? The later seems the most reasonable from a language design perspective, but that might be unintuitive to the designer. It might be reasonable to forbid OPEN/unassociated subelement association for input ports, but to allow them for other modes. This would avoid the "partial evaluation" situation described above. 2.There may be problems with OPEN/unassociated subelements when the port type is a resolved composite type. The fundamental problem is that an open port does not provide a source for the associated port. One possible way to resolve this is to view an OPEN port as an association of an implicitly declared, anonymous signal whose initial value is the default value.This implicit signal is never updated. 3. Allowing unassociated members might lead to undetected errors, when the designer forgets to indicate an association. However, its not clear that this is more likely with subelement association than with scalar ports or with association in the whole, and we currently allow unassociated ports in both of these cases. 4.Similarly, allowing non-contiguous associations might cause the designer to miss an existing association when updating code. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- There is no compelling reason to change the current LRM specification. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- For future versions of the language, the submitter's requests should be considered. -------------END OF IR----------------