VHDL Issue Number: 2013 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Exact subtype "matching" for port associations Relevant_LRM_Sections: 12.2.4 12.5 Related_Issues: Key_Words_and_Phrases: port association subtype range direction bounds Authors_Name: Stephen Bailey Authors_Phone_Number: 303-588-2001 Authors_Fax_Number: 303-652-1578 Authors_Email_Address: stephen@srbailey.com Authors_Affiliation: Synopsys Inc. Authors_Address1: 6664 Cherokee Ct Authors_Address2: Niwot, CO 80503 Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 14 May 2001 Date Analyzed: 02 December 2004 Author of Analysis: Chuck Swart Revision Number: 5 Date Last Revised: 20 July 2005 Description of Problem ---------------------- The '93 LRM added the following text in the 3rd paragraph of 12.2.4 (relative to '87): "If an actual signal is associated with a port of any mode, and if the type of the formal is a scalar type, the it is an error if (after applying any conversion function or type conversion expression present in the actual part) the bounds and direction of the subtype denoted by the subtype indication of the formal are not identical to the bounds and direction of the subtype denoted by the subtype indication of the actual." (The 2nd sentence of the paragraph is NOT part of this IR.) This new restriction requires exact "subtype matching" of bounds and direction for scalars in port associations. However, this restriction does not exist for subprogram parameter associations. Why are the 2 treated differently? Also, I find the restriction to be overbearing (overly restrictive) and believe the LRM should revert back to '87 and strike this "new" restriction from the next language version. The restriction makes it difficult to write code for a reusable component that takes an integer-typed port and performs operations on it as users of that component who wish to constrain the range of their integer values (to ensure minimum bit-size for synthesis or other reasons) must use type conversions in the port maps. While this can be viewed as a trivial thing, one of the frequent complaints about VHDL is the all of the "excessive" typing the language requires. (Excessive is definitely in the eye of the beholder, but it is a relevant point.) It is unclear to me that the advantage the user gains is worth the trouble of extra typing (and worse, dealing with what they may consider an obscure error message -- obscure not because the vendor has a terrible message, but because of language "idiosyncrasies" -- again in the eye of the beholder). Proposed Resolution ------------------- I believe all associations should be treated equally. If there are valid reasons for enforcing strict subtype conformance of port associations, then those reasons almost assuredly apply to parameter associations. As noted previously, I think the new restriction is overly restrictive. Therefore, I believe the consistency principle should be applied but in favor of eliminating the restriction for port associations. VASG-ISAC Analysis & Rationale ------------------------------ The submitter claims that the scalar restriction "does not exist for subprogram parameter associations." He is not completely correct. Scalar restrictions are not present for constants or variables, because copy-in copy-out semantics make range checks easy to implement. However, for subprogram signal parameters, Section 2.1.1.2, paragraph seven, states: "If an actual signal is associated with a signal parameter of any mode, and if the type of the formal is a scalar type, then it is an error if the bounds and direction of the subtype denoted by the subtype indication of the formal are not identical to the bounds and direction of the subtype denoted by the subtype indication of the actual." Other relevant LRM sections are: Section 12.6.2 paragraph 12? "For a scalar signal S, both the driving and effective values must belong to the subtype of the signal." Section 12.6.2 paragraph 13? "In order to update a signal during a given simulation cycle, the kernel process first determines the driving and effective values of that signal. The kernel process then updates the variable containing the current value of the signal with the newly determined effective value, as follows: a) If S is a signal of some type that is not an array type, the effective value of S is used to update the current value of S. A check is made that the effective value of S belongs to the subtype of S. An error occurs if this subtype check fails." Note that the LRM states when the subtype check on the effective value is done. It does not state when the subtype check on the driving value is done. Also note that in a signal assignment statement there is no requirement that all waveform values belong to the subtype of the target signal, although perhaps such a requirement should exist. The basic problem with signal parameters in subprograms is that changes both in read and written values can occur at times outside of the control of the subprogram, because of driving values that can occur during wait statements in the subprogram, and because of signal assignments that are made within the subprogram, but that mature after leaving the subprogram. Consequently, copy-in copy-out semantics are inadequate for signal parameters in subprograms. For a discussion of the problems of scalar signal parameters in which the subtypes of the formal and the actual differ, see IR0034 "The meaning of the constraint on a scalar signal parameter is unclear" and also VHDL93 LCS-0041(2) "Run-time constraint/subtype checks". In these documents at least five different solutions for dealing with this problem are proposed. The ISAC agrees that the existing requirements for scalar ports (and perhaps scalar signal parameters) are overly restrictive. Possible Solutions for Port Associations in Port Maps. We define subtype S1 to be "compatible" with subtype S2 if they have the same base type and if the range constraint of S1 is compatible with subtype S2. (See Section 3.1.) Basically, S1 is compatible with S2 if its range is contained within the range of S2. Solution 1. Allow different directions. No significant problems will arise if we require that the bounds match (taking into consideration null ranges) but no longer require that directions match. Solution 2. Allow Broadening/narrowing of subtypes. Allow scalar subtypes that do not have the same bounds if a) the mode of the formal is IN and the subtype of the actual is compatible with the subtype of the formal, or b) the mode of the formal is OUT and the subtype of the formal is compatible with the subtype of the actual. The checks for this would, in general, be done at elaboration time, but no new simulation checks would be required. Solution 3. Allow arbitrary subtypes. Allow the formal and actual to have non-compatible subtypes. This would, in general, require additional range checks during simulation as values were propagated through nets. Essentially, there would be one check each time a driving value changed and a check when an effective value is determined. Also, elaboration time optimizations could be performed to remove redundant checks. Solution 2 gives the greatest benefit for a reasonable effort. Also, in those cases where solution 2 is not powerful enough, type conversions can be used in the port association. Possible Solutions for Signal Associations in Subprogram Calls. Solution 1 and Solution 2 from above are viable. Solution 3 would require very expensive checks during simulation. For example, consider an IN mode signal parameter to a procedure which contains WAIT statements. Various possibilities are A. Perform a range check every time the parameter is read. B. Perform a range check every time the procedure returns from a WAIT. C. Modify range information on the actual signal when entering and leaving the subprogram. All of these solutions difficult to implement and will result in slower simulation. It seems that solution 2 gives the greatest benefit for a reasonable effort. Note, however, that checking the broadening of subtypes for subprogram parameters can require simulation time checks, since non-static subtypes can be involved. Consequently, the ISAC recommends that solution 2 be adopted. In addition, it should be required that in a scalar signal assignment, all waveform values must belong to the subtype of the target. This seems both intuitive and reasonable. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- The current rules are consistent, if restrictive. No changes to the existing LRM are needed. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Specific LRM changes: Clause 2.1.1.2 Signal parameter The paragraph reading "If an actual signal is associated with a signal parameter of any mode, and if the type of the formal is a scalar type..." Should be replaced by: "If an actual signal is associated with a signal parameter of mode IN or INOUT, and if the type of the formal is a scalar type, then it is an error if the subtype of the actual is not compatible with the subtype of the formal." "Similarly, if an actual signal is associated with a signal parameter of mode OUT or INOUT, and if the type of the actual is a scalar type, then it is an error if the subtype of the formal is not compatible with the subtype of the actual." Clause 3.1 Scalar types. After the paragraph defining compatibility between a range constraint and a subtype, add the following: "A subtype S1 is "compatible" with a subtype S2 if the range constraint associated with S1 is compatible with S2." Clause 8.4.1 Updating a projected output waveform Add to the end of the paragraph starting "For the execution of a signal assignment statement whose target is of a scalar type..." "It is also an error if the value of any value expression in the waveform does not belong to the subtype of the target." Clause 12.2.4. The port map aspect Replace the paragraph beginning "If an actual signal is associated with a port of any mode..." with the following: "If an actual signal is associated with a port of mode IN or INOUT (or BUFFER), and if the type of the formal is a scalar type, then it is an error if (after applying any conversion function or type conversion expression present in the actual part) the subtype of the actual is not compatible with the subtype of the formal.If an actual expression is associated with a formal port (of mode IN)..." "Similarly, if an actual signal is associated with a port of mode OUT, INOUT or BUFFER, and if the type of the actual is a scalar type, then it is an error if (after applying any conversion function or type conversion expression present in the formal part) the subtype of the formal is not compatible with the subtype of the actual." The paragraph reading: "If an actual signal or expression ... then it is an error if the rules of the preceding three paragraphs do not apply..." should be replaced by: "If an actual signal or expression...then it is an error if the rules of the preceding four paragraphs do not apply..." -------------END OF IR----------------