VHDL Issue Number: 0216 Classification: Language Deficiencies and Modeling Problems Language Version: VHDL-87 Summary: Resolved composite signals are difficult to associate. Related Issues: Superseded By IR 1040 (Andy Tsay) Relevant LRM Sections: 3.2.1.1 Key Words and Phrases: Association, resolution, type conversion, composite signals Current Status: Submitted 1076-1993 Disposition: Superseded (ISAC Issues Outstanding) Disposition Rationale: N/A Superseded By: 1040 ----------------------- Date Submitted: yyyy/mm/dd 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: TBD Author of Analysis: TBD Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/08/04 01:45:13 $ 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 ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD