VHDL Issue Number: 0004 Classification: Language Definition Problem Language Version: VHDL-87 Summary: It is unclear how to determine the resolution function applicable to a signal under certain circumstances. Related Issues: None. Relevant LRM Sections: 4.2, 4.3.1.2 Key Words and Phrases: Resolution functions, subtype indications Current Status: ISAC-Approved 1076-1993 Disposition: Superseded (ISAC Issues Outstanding) Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1989/02/03 Author of Submission: Paul Menchini Author's Affiliation: CAD Language Systems, Inc. Author's Post Address: P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: (919) 361-1913 Author's Fax Number: Author's Net Address: mench@clsi.com ----------------------- Date Analyzed: 1991/01/15 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/07/26 17:26:19 $ Description of Problem ---------------------- Section 4.3.1.2 (on Page 4-5) of the LRM defines a resolved signal in the following manner: "If the name of a resolution function appears in the declaration of a signal, or in the declaration of the subtype used to declare the signal, then that resolution function is associated with the signal. Such a signal is called a *resolved signal*." Moreover, Section 4.2, Paragraph 4 (on Page 4-3) defines the meaning of a subtype indication including a resolution function: "If a subtype indication includes a resolution function name, then any signal declared to be of that subtype will be resolved, if necessary, by the named function (see Section 2.4). A resolution function name has no effect on the declaration of objects other than signals or on the declarations of files, aliases, attributes, or other subtypes." The determination of the resolution function of a resolved signal is clear in most cases. Consider the following examples: -- Example 1: function F (V: Bit_Vector) return Bit; subtype Wired_Bit is F Bit; subtype Local_Bit is Wired_Bit; signal S1: Wired_Bit; signal S2: F Bit; signal S3: Local_Bit; In this example, S1 and S2 clearly are resolved signals. It also seems clear that S3 is not a resolved signal, since there is neither a resolution function appearing in the declaration of S3, nor in the declaration of the subtype used to declare S3 (Local_Bit). Even though the LRM is clear, is the situation with respect to S3 desirable? Subtypes, in both VHDL and ADA, are used to supply additional constraints on the type mark. Provided that one considers the imposition of a resolution function a constraint, the declaration of Local_Bit in Example 1 seems to *remove* a constraint from Wired_Bit. By way of analogy, see the next example: -- Example 2: subtype Byte is Integer range -128 to 127; subtype Char is Byte; Clearly, Char'Low = Byte'Low and Char'High = Byte'High, and Char'Low /= Integer'Low and Char'High /= Byte'High. Resolution functions should be "passed through" in similar fashion. There is also an ambiguity in the LRM with respect to resolution functions. It is best illustrated with another example: -- Example 3: function F (V: Bit_Vector) return Bit; function G (V: Bit_Vector) return Bit; subtype Wired_Bit is F Bit; signal S: G Wired_Bit; In Example 3, which resolution, F or G, is used to resolve the value of S? Note that this ambiguity exists no matter what interpretation is selected for S3 of Example 1; however, if my suggested interpretation is accepted, the effects of this ambiguity are more pervasive. Proposed Resolution ------------------- I suggest that my interpretation of S3 in Example 1 be adopted, and that the ambiguity of Example 3 be resolved in favor of the function G. To implement, I suggest that the defintion of a resolved signal in Section 4.3.1.2 be changed to the following: "If the name of a resolution function appears in the declaration of a signal, or in the declaration of the subtype used to declare the signal, or (recursively) in the definition of any subtype used to declare the subtype, then the first resolution function encountered, when examining the declarations in this order, is associated with the signal. "A signal that has a resolution function associated with it is called a *resolved signal*." VASG-ISAC Analysis & Rationale ------------------------------ As is pointed out above, there are two issues here. We treat these individually as follows. The first issue concerns whether or not S3 in Example 1 is a resolved signal. As suggested above, the LRM seems to make it clear that S3 is not a resolved signal. The key here is the phrase "... or other subtypes" in the quoted sentence from LRM 4.2. It should be observed that some have suggested the sentence from LRM 4.2: "If a subtype indication does not include a constraint, the subtype is the same as that denoted by the type mark." indicates that Local_Bit and Wired_Bit are the "same" subtype and hence both should either imply or not imply a resolution function. However, this would lead to the situation where whether or not the resolution function was "passed through" would depend on the existence of a constraint, and this seems like an unacceptable interpretation. Hence we prefer the line of reasoning that suggests that S3 is not a resolved signal. The submitter of this IR questions whether this is "desirable". This is clearly subjective and depends on whether it is natural to think of the resolution-function property of a subtype like a constraint. Without taking a position on this, we observe that there seems to be little support in the present LRM for treating the resolution-function property of a subtype like a constraint, and therefore, we suggest that S3 in Example 1 be considered a nonresolved signal. The second issue deals with Example 3 where it is clear that S is a resolved signal but it seems ambiguous which resolution function resolves S. There seem to be three choices: make this case an error, use F, or use G. Using F seems counterintuitive given the presense of G at the site of the declaration of S (i.e., the appearance of F is "further removed" from the declaration of the signal in question). There is no suggestion in the LRM that this case should be treated as an error so we prefer the interpretation that S is resolved by G. This interpretation is also more consistent with the recommendation on the previous issue that the resolution-function property of a subtype not be treated like a constraint. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Signal S3 in Example 1 is not a resolved signal. That is, the resolution-function property of a subtype does not behave like a subtype constraint (and does not "pass through" from one subtype declaration to the next). Signal S in Example 3 is a resolved signal that is resolved with G. That is, the applicable resolution function can be "overridden" at the point of the signal declaration. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Consider whether the resolution-function property should be a distinct kind of subtype characteristic or whether the semantics of subtype resolution-function properties should correspond to subtype constraint semantics.