VHDL Issue Number: 1104 Classification: Language Deficiencies and Modeling Problems Language Version: VHDL-93 Summary: Inconsistent, overly restrictive subtype checks. Related Issues: Relevant LRM Sections: 8.12, 7.3.2.1, 7.3.2.2, 2.1.1.1 Key Words and Phrases: subtype check, matching element check, implicit subtype conversion, return statement Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1995/03/01 Author of Submission: Daniel S. Barclay Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd. Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-992-3536 Author's Net Address: daniel@compass-da.com ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.7 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- Certain constructs have array subtype checks that are overly restrictive and are inconsistent with the less restrictive matching element checks or implicit subtype conversions of other constructs. Of the constructs that assign, associate, or otherwise move array values, most involve implicit array subtype conversions before subtype checks, or use matching element checks instead of exact subtype checks. This appears to be to allow constructions such as: variable v_to : BIT_VECTOR(1 to 3); variable v_downto : BIT_VECTOR(10 down 8); ... v_to := v_down; -- target array subtype (with 1 to 3) can -- differs from expression value subtype -- (with 10 downto 8) and function F(p : BIT_VECTOR(0 to 2)); -- formal parameter subtype has 0 to 2 ... F(v_to); -- actual value subtype (with 1 to 2) can -- differ from formal parameter subtype F(v_downto); The size of the array is important, but the particular bounds and direction are not. However, there are several constructs that require an exact subtype match for which there seems to be no reason. This makes the language harder to use, and causes differences in vendor tools. The restrictive constructs are return statements, element associations of aggregates, and individual subelement association of interface objects. Return statements (restrictive): In section 8.12, in the last non-note paragraph, the first sentence says: For the execution of a return statement, the expression (if any) is first evaluated and a check is made that the value belongs to the result subtype. Clearly, a return statement always involves an exact subtype check, not a matching element check, and never involves an implicit subtype conversion. Aggregate element associations (restrictive): In section 7.3.2.1, the second paragraph says for record aggregates: ... A check is made that the value of each element of the aggregate belongs to the subtype of this element. ... In section 7.3.2.2, the last paragraph says: For the evaluation of an aggregate that is not a null array, a check is made that the index values defined by choices belong to the corresponding index subtypes, and also that the value of each element of the aggregate belongs to the subtype of this element. ... Thus, aggregate element assocations require an exact subtype match also. The other constructs whose execution involves passing values around are not so rigid. When the value is of any array type, either an implicit subtype conversion is performed, or a matching element check is done instead of a subtype check. Variable assignments (flexible): In section 8.5, in the 5th text paragraph, the second sentence says: A check is then made that the value of the expression belongs to the subtype of the variable, except in the case of a variable that is an array (in which case the assignment involves a subtype conversion). Section 8.5.1 says: If the target of an assignment statement is a name denoting an array variable (including a slice), the value assigned to the target is implicitly converted to the subtype of the array variable; ... .... The subtype conversion checks that for each element of the array variable there is a matching element in the array value, and vice versa. ... Thus, for variable assignments of array types, an exact subtype match is not required. Signal assignments (flexible): The note in section 8.4.1 says: 5--No subtype check is performed on the value component of a new transaction when it is added to a driver. Instead, a subtype check that the value component of a transaction belongs to the subtype of the signal driven by the driver is made when the driver takes on that value. See 12.6.1. In section 12.6.1, the eighth-to-last paragraph begins with: For a scalar signal S, both the driving and effective values must belong to the subtype of the signal. However, it continues with: 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. Thus for signal assignments (and related simulation actions) for array types, and exact subtype match is not required. Object initial value expressions (flexible): In section 12.3.1.4, the third paragraph says: It is an error if the value of the expression does not belong to the subtype of the object; if the object is an array object, then an implicit subtype conversion is first performed on the value unless the object is a constant whose subtype indication denotes an unconstrained array type. Thus initialization is similar to assignment: There must be matching elements, but an exact array subtype match is not required. Attribute specifications (flexible): In section 12.3.2.1, the third paragraph says: b) .... It is an error if the value of the expression does not belong to the subtype of the attribute; if the attribute is of an array type, then an implicit subtype conversion is first performed on the value, unless the subtype indication of the attribute denotes an unconstrained array type. and the fifth paragraph says: The assignment of a value to an instance of a given attribute involves a check that the value belongs to the subtype of the designated attribute. For an attribute of a constrained array type, an implicit subtype conversion is first applied as for an assignment statement. No such conversion is necessary for an attribute of an unconstrained array type; the constraints on the value determine the constraints on the attribute. Again, this is a matching element check instead of an exact array subtype check. Association (flexible): In section 12.2.2, the second paragraph says, for generics: It is an error if the value of the actual does not belong to the subtype denoted by the subtype indication of the formal. If the subtype denoted by the subtype indication of the declaration of the formal is a constrained array subtype, then an implicit subtype conversion is performed prior to this check. In section 12.2.3, the fifth paragraph says, for ports: If an actual signal or expression is associated with a formal port, and if the formal is of a constrained array subtype, then it is an error if the actual does not contain a matching element for each element of the formal. In section 2.1.1.1, the fourth paragraph says, for constant and variable parameters of array type: ... it is an error if the value of the associated actual parameter ... does not contain a matching element for each element of the formal. (However, for elements of such parameters, it continues: ... It is also an error if, in either case, the value of each element of the actual array ... does not belong to the element subtype of the formal. If the formal parameter is of mode out or inout, it is also an error if, at the end of the subprogram call, the value of each element of the formal ... does not belong to the element subtype of the actual. This case is restrictive, similar to element associations of aggregates.) In section 2.1.1.2, the eighth paragraph says, for signal parameters: If an actual signal is associated with a formal signal parameter, and if the formal is of a constrained array subtype, then it is an error if the actual does not contain a matching element for each element of the formal. ... (For element of such parameters, it continues as for constant and variable parameters: It is also an error if the mode of the formal is in or inout and if the value of each element of the actual array does not belong to the element subtype of the formal. This case is restrictive too.) Also, in section 7.3.3, the third text paragraph contradicts the section 2.1.1.2 paragraph above: Evaluation of a function call includes evaluation of the actual parameter expressions specified in the call and evaluation of the default expressions associated with formal parameters of the function that do not have actual parameters associated with them. In both cases, the resulting value must belong to the subtype of the associated formal parameter. (The last sentence doesn't allow for only a matching element check, and nothing defines an implicit subtype conversion. Note that this paragraph addresses only constant parameters; it does not address signal parameters and file parameters, for which there are no actual expressions. There are signal or file names, but these are not expressions. This looks like an old error in converting the Ada LRM to VHDL.) Alias declarations (flexible): In section 4.3.3.1, the seventh paragraph says: ... moreover, the subtype denoted by the subtype indication must include a matching element (see 7.2.2) for each element of the object denoted by the name. Section 12.3.1.5 says: The creation of an alias for an array object involves a check that the subtype associated with the alias includes a matching element for each element of the named object. Clearly, element matching is sufficient; an exact subtype match is not required. Case statements (flexible): In section 8.8, the tenth paragraph says: In such a case, each choice appearing in any of the case statement alternatives must be a locally static expression whose value is of the same length as that of the case expression. Clearly, the size of the array, not the exact bounds, is what matters. Type conversions (flexible): In section 7.3.5, the second text paragraph says: If the type mark denotes a subtype, conversion consists of conversion to the target type followed by a check that the result of the conver- sion belongs to the subtype. However, the ninth text paragraph defines the subtype of the result to be constructed to match the type mark's subtype: ... If the type mark denotes a constrained array subtype, then the bounds of the result are those imposed by the type mark. ... Additionally, the twelfth text paragraph says, for array elements: ... If the type mark denotes a constrained array subtype, a check is made that for each element of the operand there is a matching element of the target subtype, and vice versa. ... Thus, type conversions do not require an exact subtype match. Qualified expressions (restrictive, but no problem): In section 7.3.4, the second text paragraph says: The evaluation of a qualified expression evaluates the operand and checks that its value belongs to the subtype denoted by the type mark. This is restrictive, but this does not seem to be inconsistent (the qualified expression is specifically saying what the subtype is to be) or to be a problem with the language (one can use a type conversion when array subtype conversion is desired). Example: Here is an example that should result in an error, but that tools are likely to get wrong: SUBTYPE bv1dt0 IS BIT_VECTOR(1 downto 0); FUNCTION get2bit ( CONSTANT reg : IN BIT_VECTOR(7 DOWNTO 0); CONSTANT rank : IN INTEGER RANGE 0 TO 7 ) RETURN bv1dt0 IS -- Note: descending direction in return subtype BEGIN RETURN reg(rank+1) & reg(rank); -- <<== RUN-TIME ERROR HERE END; ... Do see the error? For concatenation, the result direction is defined to be the direction of the base type. This is ascending for BIT_VECTOR. The return subtype has a descending range. The return statment's expression's value (with an ascending range) does not belong to the return subtype. (Does _your_ tool detect this error? This example was illegal in VHDL-87 also. Though it is by a different path, the concatenation still results in an array subtype with an ascending range.) Conclusion: Therefore (gasp), return statement checks, aggregate element association checks, and individual association element checks are inconsistent. Proposed Resolution ------------------- Remove the inconsistent and overly restrictive exact array subtype checks. For return statements, aggregate element associations, and individual association elements, change the exact array subtype checks to matching element checks. (Do not change qualified expressions; they are not a problem.) Also, fix the contradictory wording in the third text paragraph of section 7.3.3. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD