VHDL Issue Number: 0140 Classification: Language Clarification Language Version: VHDL-87 Summary: What use are LINKAGE ports? Related Issues: None. Relevant LRM Sections: 4.3.3, 4.3.1.2, 3.2.1.1, 1.1.1.2 Key Words and Phrases: Linkage ports Current Status: Analyzed 1076-1993 Disposition: Superseded (ISAC Issues Outstanding) Disposition Rationale: Superseded By: 1058 ----------------------- Date Submitted: 1989/06/21 Author of Submission: Ken Scott Author's Affiliation: Vantage Analysis Systems, Inc. Author's Post Address: 42840 Christy St., Suite 201 Fremont, CA 94538 Author's Phone Number: (415) 659-0901 Author's Fax Number: Author's Net Address: N/A ----------------------- Date Analyzed: 1991/03/21 Author of Analysis: Alex Zamfirescu Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/05/13 19:34:42 $ Description of Problem ---------------------- Review this passage from Section 4.3.3 of the LRM: * LINKAGE. The value of the interface object may be read or updated, but only by appearing as an actual corresponding to an interface object of mode LINKAGE. No other reading or updating is permitted. What use are LINKAGE ports if you cannot explicitly read them or write them? Proposed Resolution ------------------- A note should be added to this section explaining the usefulness of LINKAGE ports. VASG-ISAC Analysis & Rationale ------------------------------ The semantic for linkage ports is defined by the LRM as follows: LRM 1.1.1.2 Ports: For a formal port of mode linkage, the associated actual may be a port of any mode. LRM 3.2.1.1 Index Constraints and Discrete Ranges: * 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, and the index ranges are obtained from this constrained subtype; otherwise, the index ranges are obtained from the object or value denoted by the actual designator. * 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, and the index ranges are obtained from this by the actual designator. For an interface object of mode INOUT or LINKAGE, the index ranges determined by the first rule must be identical to the index ranges determined by the second rule. LRM 4.3.1.2 Signal Declaration: A signal may have one or more SOURCES. For a signal of a scalar type, each source is either a driver (see Section 9.2.1) or an OUT, INOUT, BUFFER or LINKAGE port of a component instance with which thesignal is associated. LRM 4.3.1.2 Signal Declaration: If a subelement of a resolved signal of composite type is associated as an actual in a port map clause (either in a component instantiation statement or in a binding indication), and the corresponding formal is of mode OUT, INOUT, BUFFER, or LINKAGE, then every scalar subelement of that signal must be associated exactly once with such a formal in the same port map clause, and the collection of the corresponding formal parts taken together constitute one source of the signal. LRM 4.3.3 Interface Declarations: It is an error if a default expression appears in an interface declaration and the mode is LINKAGE or the corresponding type mark denotes a file type. The value of an object is said to be READ when one of the following conditions is satisfied: * When the object is evaluated, and also (indirectly) when the object is associated with an interface object of the modes IN, INOUT, or LINKAGE. The value of an object is said to be UPDATED when one of the following conditions is satisfied: * When it appears as the target of an assignment statement, and also (indirectly) when the object is associated with an interface object of the modes OUT, BUFFER, INOUT, or LINKAGE. An interface object has one of the following modes: * LINKAGE. The value of the interface object may be read or updated, but only by appearing as an actual corresponding to an interface object of mode LINKAGE. No other reading or updating is permitted. LRM 4.3.3.2 Association Lists: If the mode of the formal is IN, INOUT, or LINKAGE, and the actual is not OPEN, then the type of the actual (after applying the type conversion function, if present in the actual part) must be the same as the type of the corresponding formal. Similarly, if the mode of the formal is OUT, INOUT, BUFFER, or LINKAGE, and the actual is not open, then the type of the formal (after applying the type conversion function, if present in the formal part) must be the same as the corresponding actual. LRM 12.6.1 Propagation of Signal Values: No effective value is specified for out and linkage ports, since these ports may not be read. There are also some clarifications in the APPENDIX B GLOSSARY: Mode. The mode of a port or parameter specifies the direction of information flow through the port or parameter. Modes are in, out, inout, buffer, or linkage. ( 4.3.3) Update. The value of a signal is said to be updated when the signal appears as the target of an assignment statement, (indirectly) when it is associated with an interface object of mode out, buffer, inout, or linkage, or when one of its subelements is updated. ( 4.3.3) First, the LRM semantic for linkage ports contains a contradiction. Let x be a port of mode linkage that is associated as an actual with another formal port y of mode linkage. This is permitted by LRM 1.1.1.2 (Ports): ... For a formal port of mode linkage, the associated actual may be a port of any mode. Then by LRM 4.3.3 (Interface Declarations): * The value of the interface object may be read or updated, but only by appearing as an actual corresponding to an interface object of mode LINKAGE. No other reading or updating is permitted. we can infer that port x may be read, which is in contradiction with LRM 12.6.1 (Propagation of Signal Values): No effective value is specified for out and linkage ports, since these ports may not be read. Second, the LRM semantic for linkage ports permits the description of hierarchical networks of ports of mode linkage. Only the top side of the network can be associated with a signal. The propagation through these networks apparently follows the rules of normal ports if there are no multiple sources (although there is no rule for the direction of propagation). With multiple sources the direction dilemma becomes more complicated, since in some branches only up propagation is possible, while in other values propagate down. The proposed resolution referring to the usefulness of LINKAGE ports is based mostly on the fact that the LRM has left open the updating semantic for linkage ports at the leaf level and some rules for the propagation. This lack of specification has been used by some vendors who have utilized linkage ports to add extra semantics to their VHDL tools. For example, MCC Switch Level cells use linkage ports. Another potential application is mixed-mode simulation. In conclusion, the LRM semantic for linkage ports is wrong and incomplete. There are two missing parts, (a) propagation semantic, and (b) leaf cell updating semantic with (a) required and (b) expected (not necessarily needed). VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Do not add a note explaining the usefulness of LINKAGE ports. Instead, recommend caution when using linkage ports since if they might work on some implementation that implementation has made choices that prevent portability and are outside of the VHDL LRM. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Here are some possibilities: 1. Discard LINKAGE ports. Use LINKAGE key-word with other semantic. 2. Do not discard LINKAGE ports. Instead, clarify the contradiction. Add semantic for propagation and leaf port update. Add standard interface with the analog ports. Use linkage leaf ports as fuzzifier/defuzzifier ports to the analog world.