VHDL Issue Number: 1062 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Can a resolution function return an unconstrained array? Related Issues: 0239 Relevant LRM Sections: 2.4, 12.6.2 Key Words and Phrases: resolution function, unconstrained array Current Status: ISAC-Approved ----------------------- Date Submitted: 1991/03/22 Author of Submission: Chuck Swart Author's Affiliation: Mentor Graphics Corporation Author's Post Address: 8500 S.W. Creekside Place Beaverton, OR 97005-7191 Author's Phone Number: (503) 626-7000 Author's Fax Number: Author's Net Address: cswart@mentor.com ----------------------- Date Analyzed: 1995/04/10 Author of Analysis: Clive R. Charlwood Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/06/20 22:56:36 $ Description of Problem ---------------------- Can a resolution function return an unconstrained array? For example, is the following legal VHDL code? entity E is end E; ARchitecture A of E is type T is array (natural range <>) of Bit_Vector (1 to 5); function F (A: T) return Bit_Vector is begin return A(A'left); end F; signal S : F Bit_Vector (1 to 5); signal S1: F Bit_Vector (1 to 10); begin end A; In section 2.4 the LRM requires that "The type of the return value of the function must also be that of the signal." It does not require that the subtypes match. Section 12.6.2 states: "For a scalar signal S, both the driving and effective values must belong to the subtype of the signal. For a composite signal R, an implicit subtype conversion is performed to the subtype of R; for each element of R, there must be a matching element in both the driving and the resolved value, and vice versa." It seems that the above code is technically legal. However, allowing unconstrained parameters as return types to resolution functions gives the user no real benefits and prevents tools from early error detection. If unconstrained arrays are allowed then the test required by section 12.6.1 can only be performed at simulation time. If the return value is required to be constrained then the test (for arrays) can always be performed at elaboration time and can often be done during analysis. Proposed Resolution ------------------- Require that the declared return value of the function have a subtype which is convertible to that of the signal. It is unreasonable that the return value have the same subtype as the signal since that requirement could force the use of different resolution functions for buses of the same type and size but with different index ranges. VASG-ISAC Analysis & Rationale ------------------------------ The second paragraph in section 2.4 (page 27, line 339) has a number of problems. It states: "A resolution function must be a pure function (see 2.1); moreover, it must have a single input parameter of class *constant* that is a one dimensional, unconstrained array whose element type is that of the resolved signal. The type of the return value of the function must also be that of the signal. Errors occur at the place of the subtype indication containing the resolution function name if any of these checks fail (see 4.2)." 1) It is not clear whether "element type" and "The type of the return value" refer to base type or subtype. We feel that these should both be read (and changed in a future version of the language) as BASE type. We feel that making this an exact subtype match would be overly restrictive. in particular 1) a scalar signal might be of a smaller range than the one associated with the resolution function, and 2) an array may have different indices but the same size (Note: section 12.6.2 specifies that subtype conversion would take place in this case). 2) Both the "value of the return type" and the "element type" are compared to the (resolved) signal. No signal exists if the resolution function is used in a subtype indication. The ISAC also felt that it is better to flag errors during analysis instead of waiting for elaboration or simulation. Finally, we fell that the language would be easier to implement efficiently if the return type were required to be constrained. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- 1) Read the LRM as if both uses of the term type discussed above actually said BASE TYPE. 2) Change the sentence "The type of the return value of the function must also be that of the signal." to "The return type of the function must be the type of the typemark in the subtype indication that contains the resolution function name" Both declarations are legal and should analyze without error. However, under certain conditions an error will be generated during either initialization or at run time. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- This paragraph needs to be recrafted to: 1) Explicitly use the term BASE TYPE in both cases 2) Change the LRM to require that the declared return value of the function have a subtype which is constrained and convertible to that of the signal. (Note: This will break certain existing resultion functions. However, the change will be flagged by the analyzer and can then be easily corrected).