VHDL Issue Number: 1040 Classification: Language Deficiencies and Modeling Problems Language Version: VHDL-93 Summary: Resolved composite signals are difficult to associate. Related Issues: Supersedes 0216 Relevant LRM Sections: 3.2.1.1 Key Words and Phrases: Association, resolution, type conversion, composite signals Current Status: ISAC-Approved 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1991/03/20 Author of Submission: Paul Menchini Author's Affiliation: Menchini & Associates Author's Post Address: 2 Davis Drive P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: 919.990.9506 Author's Fax Number: 919.990.9507 Author's Net Address: mench@mercury.interpath.net ----------------------- Date Analyzed: 1997/07/21 Author of Analysis: Peter Ashenden Revision Number: $Revision: 1.6 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- There are two approaches to declaring a package of logic types involving multiple kinds of signal resolution (e.g., wired and, wired or, and wired x): 1. Declare a single resolution function and a logic data type having a rich set of values. This method is consistent with most simulators having a single, built-in resolution function and a multi-valued state- strength or interval logic model. The IEEE Logic Modeling Group has also developed their standard model using this method. 2. Declare multiple resolution functions and a simpler data type. This method is how the VHDL Design Exchange Group has developed their standard logic model. This issue report covers problems encountered when using the second method. The basic approach taken is to declare an unresolved scalar type, an unresolved vector type, and the necessary resolution functions: type Logic4 is ('X', '0', '1', 'Z'); type Vector4 is array (Natural range <>) of Logic4; function WiredX (V: Vector4) return Logic4; function WiredAnd (V: Vector4) return Logic4; function WiredOr (V: Vector4) return Logic4; Then, the resolved scalar types can be described as subtypes of the unresolved scalar type: subtype DotX is WiredX Logic4; subtype DotAnd is WiredAnd Logic4; subtype DotOr is WiredOr Logic4; Unfortunately, the resolved vector types cannot be declared analogously: type VV4 is array (Natural range <>) of Vector4; -- illegal! function WiredVectorX (V: VV4) return Vector4; function WiredVectorAnd (V: VV4) return Vector4; function WiredVectorOr (V: VV4) return Vector4; subtype BusX is WiredVectorX Vector4; subtype BusAnd is WiredVectorAnd Vector4; subtype BusOr is WiredVectorOr Vector4; The type VV4 is illegal because of the second sentence of the first item of paragraph 5 in Section 3.2.1.1 (on page 3-11): The same requirement [that the subtype indication must define a constrained array subtype] exists for the subtype indication of an element declaration, if the type of the record element is an array type; and for the element subtype indication of an array type definition, if the type of the array element is itself an array type. Because of this restriction, the resolved vector types are instead declared as different types: type BusX is array (Natural range <>) of DotX; type BusAnd is array (Natural range <>) of DotAnd; type BusOr is array (Natural range <>) of DotOr; It is the fact that the resolved vector types are different VHDL types that causes modeling problems. Specifically, signals of the resolved scalar types can be freely associated with ports of other resolved scalar types, since the resolved scalar types are VHDL subtypes of the same (unresolved) type. But signals of the resolved vector types cannot be freely associated with ports of the other resolved vector types. The LRM allows type conversion functions to be used in association elements. However, the LRM also requires that such type conversion functions accept and return a constrained array type. (This restriction is stated in the two items in paragraph 6 of Section 3.2.1.1, on page 3-12: * For an interface object of mode IN, INOUT, or LINKAGE, if the actual part includes a type conversion function, then the result type of that function must be a constrained array subtype.... * For an interface object of mode OUT, BUFFER, INOUT, or LINKAGE, if the formal part includes a type conversion function, then the parameter subtype of that function must be a constrained array subtype.... These restrictions disallow the following functions from being used as type conversion functions in the port maps of component instances: function cvBusX (V: BusAnd) return BusX; function cvBusX (V: BusOr ) return BusX; function cvBusAnd (V: BusX ) return BusAnd; function cvBusAnd (V: BusOr ) return BusAnd; function cvBusOr (V: BusX ) return BusOr; function cvBusOr (V: BusAnd) return BusOr; (Such function declarations and their associated bodies are legal, but cannot be used as type conversion functions.) Only three remedies exist: 1. Abandon the use of multiple resolution functions as a modeling paradigm. This remedy defeats the whole abstraction mechanism provided by the multiple-resolution function approach. 2. Have each modeler declare the appropriate constrained subtypes of the resolved vector types, then create and use the appropriate type conversion functions operating on these constrained subtypes. This approach is cumbersome and diminishes the utility of this modeling paradigm. 3. Have modelers effect the association via intermediate signals: Create an intermediate signal of the same type as the port; an (unconstrained) type conversion function or expression can be used when driving the intermediate signal to or from the signal that was to be originally associated with the port. This remedy is perhaps worst of all: By introducing extra signals, the model is made both more obscure and less efficient. Proposed Resolution ------------------- Relax at least one of the following restrictions: 1. The restriction in the second sentence of the first item in paragraph 5 of Section 3.2.1.1 that requires the subtype indication of record and array elements to be constrained. 2. The restriction in both items in paragraph 6 of Section 3.2.1.1 that requires the result or return type of type conversion functions to be constrained under certain circumstances. Note that relaxing the first restriction will require additional syntax to supply constraints to the "inner" array types. However, neither significantly complicate the semantics of VHDL. VASG-ISAC Analysis & Rationale ------------------------------ NOTE to whoever analyzes this IR: The Description of Problem section is wrong in asserting that the LRM requires the parameter and return subtype of conver- sion functions to be constrained. The quoted paragraphs are qualified by their preceding paragraph. (They apply only when the something else is not already constrained.) According to 4.3.2.2: - For a type conversion in the formal part of an association element, the base type of the type mark must be the base type of the actual, and the formal and the actual must be related types. - For a type conversion in the actual part of an association element, the base type of the type mark must be the base type of the formal, and the formal and the actual must be related types. - For a conversion function in the formal part of an association element, the parameter type must be the type of the formal. - For a conversion function in the actual part of an association element, the result type must be the type of the formal. These rules allow use of a type conversion whose type mark is an unconstrained type, or a conversion function with an unconstrained parameter type in a formal part, or a conversion function with an unconstrained result type in an actual part. However, the sections (partially) quoted by the issue author further restricts use of type conversions and conversion functions in the cases specified in 3.2.1.1 lines 410-413. These are the cases in which a formal object of unconstrained array type is associated in whole. The restrictions do not apply in other cases. The reason for the restriction is to ensure that enough information is provided to allow the index ranges of the formal object to be inferred. In the cases where the restrictions do not apply (such as for constrained formals), the index ranges of the formal are inferred by other means (specified in 3.2.1.1 lines 366-409). For the author's example, this means that the conversion functions cvBusX, etc, can be used in port maps of component instances whose formal ports are constrained. Consider first a conversion function with unconstrained result type used in the actual part for an unconstrained formal, or a conversion function with unconstrained parameter type used in the formal part for an unconstrained formal. In general a conversion function may perform any computation. The type of the parameter need not be related to the type of the result. Even if the two types are related, the size of the result may not be the same as the size of the parameter value. Thus, the lack of constraints in the conversion function parameter or result leaves no basis for inferring the index ranges for the formal. The restrictions of 3.2.1.1 414-423 must apply. For the author's example, this means that the conversion functions cvBusX, etc, cannot be used in port maps of component instances whose formal ports are unconstrained. However, the modeling deficiency can be overcome with use of generic constants. For example, a component: component c is port ( a : in BusAnd; b : out BusAnd ); end component c; could be rewritten as: component c is generic ( a_length, b_length : natural ); port ( a : in BusAnd(0 to a_length - 1); b : out BusAnd(0 to b_length - 1) ); end component c; This could then be instantiated as: signal s1 : BusX( ... ); signal s2 : BusX( ... ); c1 : component c generic map ( a_length => s1'length, b_length => s2'length ) port map ( a => cvBusAnd(s1), cvBusX(b) => s2 ); Next, consider the case of a type conversion with unconstrained type mark in either the actual part or formal part for an unconstrained formal. In this case, the index ranges of the formal could be taken from the index ranges of the actual by converting the bounds of the actual to the index types of the formal (see also 7.3.5 512-514 & 520-523). This would require revision of 3.2.1.1 lines 413-423. Such a change would not affect existing correct models, but would require changes to analyzers. For the author's example, this would mean that the conversion functions could be replaced by type conversions between types BusX, BusAnd and BusOr. For example, the component c above (without generics) would be instantiated as: c1 : component c port map ( a => BusAnd(s1), BusX(b) => s2 ); The problem with this change is that it would complicate the LRM specification for use of type conversions and conversion functions in association elements. It would require introduction of language to describe the particular case in which a type conversion to or from an unconstrained type can be used in the association of an unconstrained formal, and the rules for inferring the bounds for the formal. This additional language would make the LRM significantly more difficult to understand and interpret. Furthermore, introduction of the special-case rules would imply additional checking in analyzers. In the interest of relative simplicity of the language definition and language analysis, this change is rejected. The author's proposed resolution 1, to remove the restriction that the subtype indication of elements of composite types, would require significant changes to the language, including syntax changes. The author recognizes the need for such changes, but makes no concrete proposal. Given the scale of these changes compared to the change described above, the author's proposed resolution 1 is rejected. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change.