After review, I will forward this to the requirements committee -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 2121 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Allow for vectors to have assigns and opens in the port map Relevant_LRM_Sections Related_Issues Key_Words_and_Phrases Authors_Name Kevin Jennings Authors_Phone_Number 734-737-4268 Authors_Fax_Number Authors_Email_Address Kevin.Jennings@Unisys.com Authors_Affiliation Unisys Authors_Address1 41100 Plymouth Road Authors_Address2 Plymouth, Michigan 48170 USA Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 31 August 2007 Date Analyzed: 12 October 2007 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 12 October 2007 Description of Problem ---------------------- Any chance of changing the rule that requires an entire vector to be assigned in a port map instead of being able to leave some of them open? Something like the following.... U1 : Some_Device port map( Some_Bus(15 downto 0) : > Some_Signal, Some_Bus(31 downto 16) => open); Where I run into this as an issue is generally when I use a VHDL netlist produced by a CAD program as part of a simulation model. If the spec for the physical part indicates that unused pins can (or sometimes 'should be') left open and the PCBA design is not using the entire bus than those unused pins on the physical part will be left with no connection (which is correct per design) but the resulting VHDL model complains when compiled because the 'Some_Bus' pins must either all be assigned or all left open. In certain situations, there are some simple work arounds (mentioned below) but if the language handled the above mentioned port map (which reflects the reality of the desired PCBA design) things would be much cleaner. The model would also not have the situation dependent drawbacks associated with each of the work arounds. - Work around #1: If the PCBA design itself is stable and not changing, then simply edit the VHDL model for the offending schematic pages and move on. - Work around #2: If the PCBA design is still evolving then see if it's possible to get a resistor on to the schematic to drive the 'unused' pins. Kevin Jennings Proposed Resolution ------------------- See what I listed in the description VASG-ISAC Analysis & Rationale ------------------------------ Since VHDL-93 it has been illegal to use subelement association in port maps or generic maps with some elements associated to signals and other elements left OPEN. For brevity, we will call such associations "mixed". This restriction has caused problems for designers. History of the Problem The restriction was put into VHDL-93 in two places. Clause 1.1.1.2 states: "It is an error if some of the subelements of a composite formal port are connected and others are either unconnected or unassociated." This change was made in response to IR 0066. However, no wording in this IR mentions subelement association. In addition Clause 4.3.2.2 states: "It is an error if an actual of OPEN is associated with a formal that is associated individually." This was added in response to a ballot comment written by Jim Vellenga. The ballots are no longer available, so the intended purpose of these changes is somewhat obscure. The ISAC is interested in any additional feedback on the origins of these changes. Some potential problems with relaxing the restriction. 1. The ISAC has not yet found any significant issues with allowing mixed associations for ports of mode OUT except for possible problems involving the default expression as given below. 2.Here is one example involving ports of a constrained subtype: Suppose port P is of mode IN and of type bit_vector( 1 to 3 ) and you supply a port map association of P(1) => S1, P(2) => S2. Currently, you will get an error message, because you haven't associated P(3). However, under the proposed change, this might be legal, but, perhaps, unintended. One solution would be to allow partially unconnected ports, but to disallow partially unassociated ports. For this example, you would have to say specifically P(3)=>OPEN. For ports of mode IN, there are potential problems in determining the value of the port. 3. For mixed associations it makes sense to determine the initial values for the OPEN subelements from the (required) default expression in the port declaration. However, the default expression supplies values for all subelements, and in general, the entire default expression must be evaluated. This evaluation can be quite complicated and expensive, involving impure functions and other complications. The most reasonable interpretation is to determine values for all subelements, then discard values which are covered by explicit associations in the port map. 4a. In some cases involving unconstrained array types, the default expression might not provide the correct values. Consider the following example: port p: IN bit_vector := ( 1 => '1', 2 => '0'); The following association is legal: ...port map( p(3) => '1', p(4) => '0')... --default value not used Port p gets its range from the subelement association and its direction from the declaration of bit_vector. The following association is also legal: ... port map ( p => OPEN ) Port p gets its range, direction and value from the default expression; But what values are assigned in the following mixed case? ... port map ( p(3) => '1', p(4) => OPEN ) Port p gets its range (3 to 4) from the subelement association, but either i)there is no corresponding default value for p(4) or ii) a matching element rule must be applied. This issue becomes more serious for VHDL-200X, which allows unconstrained subelements such as arrays of strings. 4b. port p: IN bit_vector := ( 1 => '1', 2 => '0'); association p(1) => s1, p(2) => s2, p(3) => OPEN, p(4) => s4 Is this legal? If so, what value is assigned to p(3)? 5. The current LRM states that "It is an error if a port of any mode other that IN is unconnected or unassociated and its type is an unconstrained array type." The main reason for this restriction is the difficulty in determining the bounds and direction of an unassociated, unconstrained port. However, we might want to relax this restriction if subelement association is used to assign each subelement to OPEN, because, in that case, the subelement associations determine the bounds of the port. Alternatively, to avoid some complicating cases we might want to disallow both totally and partially unconnected/unassociated ports of unconstrained array type. 6. Effect on incremental binding. OPEN elements in mixed port associations can later be remapped using incremental binding. This might be difficult to implement. 7. Non-compliant tools. The submitter of IR 2121 claims that the mixed association is generated by a particular CAD program. There is a question whether some non-compliant tools should modify their algorithms to generate legal VHDL code, vs. many compliant tools changing their implementation. On the other hand, partially OPEN ports are natural in some realistic hardware situations. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBDReceived on Fri Oct 12 11:37:12 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 11:37:12 PDT