VHDL Issue Number: 0063 Classification: Language Definition Problem Language Version: VHDL-87 Summary: ALL/OTHERS in a disconnection specification not completely defined. Related Issues: 0037, 0040, 0095 Relevant LRM Sections: 5.3, 9.5 Key Words and Phrases: Disconnection specification Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: LRM is clear now. Superseded By: N/A ----------------------- Date Submitted: 1989/02/10 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1990/10/11 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/05/13 19:34:42 $ Description of Problem ---------------------- LRM 9.5 refers to the "applicable disconnection specification". This concept is not defined. Section 5.3 of the LRM makes it clear what is intended in many cases, but other cases, particularly in regard to ALL/OTHERS notation in the context of composite types, are unclear. Proposed Resolution ------------------- The following rules are applied: Rule 1: If S is a composite signal of type CT whose elements are S(1), S(2), ..., S(N) are of type Sub_CT, then disconnect S : CT after ...; is equivalent to disconnect S(1), S(2), ..., S(N) : Sub_CT after ...; Rule 2: For any type T, disconnect all : T after ...; is equivalent to disconnect S1, S2, ... SK : T after ...; where S1, S2, ..., SK are the simple names of all signals declared in the immediately enclosing declarative part to be of type T. Rule 3: For any type T, disconnect others : T after ...; is equivalent to disconnect S1, S2, ... SK : T after ...; where S1, S2, ..., SK are the simple names of all signals declared in the immediately enclosing declarative part to be of type T, provided these signals have not been explicitly named in a previous disconnection specification. To illustrate these rules, given the following definitions: subtype CT is String(1 to 2); subtype Sub_CT is Character; signal S, S1 : CT; signal Sub : Sub_CT; Consider the following examples: (1) disconnect S : CT after ... ; disconnect all : Sub_CT after ... ; -- OK, S and Sub affected, S1 unaffected (2) disconnect S : CT after ... ; disconnect others : Sub_CT after ... ; -- OK, S and Sub affected, S1 unaffected (3) disconnect all : CT after ... ; disconnect SS : Sub_CT after ... ; -- Illegal if SS is "S(1)", legal if SS is "Sub" (4) disconnect all : CT after ... ; disconnect all : Sub_CT after ... ; -- Never an error; S, S1, and Sub affected. (5) disconnect all : CT after ... ; disconnect others : Sub_CT after ... ; -- Never an error; S, S1, and Sub affected. (6) disconnect others : CT after ... ; disconnect SS : Sub_CT after ... ; -- Illegal if SS is "S(1)", legal if SS is "Sub" (7) disconnect others : CT after ... ; disconnect all : Sub_CT after ... ; -- Never an error; S, S1, and Sub affected. (8) disconnect others : CT after ... ; disconnect others : sub_CT after ... ; -- Never an error; S, S1, and Sub affected. (9) disconnect all : Sub_CT after ... ; disconnect S : CT after ... ; -- OK, S and Sub affected, S1 unaffected (10) disconnect others : Sub_CT after ... ; disconnect S : CT after ... ; -- OK, S and Sub affected, S1 unaffected (11) disconnect SS : Sub_CT after ... ; disconnect all : CT after ... ; -- Illegal if SS is "S(1)", legal if SS is "Sub" (12) disconnect all : Sub_CT after ... ; disconnect all : CT after ... ; -- Never an error; S, S1, and Sub affected. (13) disconnect others : Sub_CT after ... ; disconnect all : CT after ... ; -- Never an error; S, S1, and Sub affected. (14) disconnect SS : Sub_CT after ... ; disconnect others : CT after ... ; -- Illegal if SS is "S(1)", legal if SS is "Sub" (15) disconnect all : Sub_CT after ... ; disconnect others : CT after ... ; -- Never an error; S, S1, and Sub affected. (16) disconnect others : Sub_CT after ... ; disconnect others : CT after ... ; -- Never an error; S, S1, and Sub affected. VASG-ISAC Analysis & Rationale ------------------------------ The ISAC considered two fundamental questions regarding the notion of "applicable disconnection specification", as used in Section 5.3: 1. Does the term, "type", as used in Section 5.3, refer to the base type indicated by the type mark in the disconnection specification? Or does it instead refer to the type or subtype denoted by type mark? As an example of this difference, does the disconnection specification disconnect all: Integer after 42 nS; supply disconnection times for any Natural or Positive signals in the declarative part in which both the disconnection specification and the signal appears? 2. Does a disconnection specification apply only to declared signals, or can it also apply to subelements of declared signals? The difference can be illustrated here by considering whether the disconnection specification disconnect all: Bit after 17 nS; applies to the bits of any composite signals with bit subelements declared in the declarative part in which the disconnection specification appears. Regarding the first question, at one point, the ISAC agreed that "type" meant "type mark"--this interpretation has obvious appeal, since "what you see is what you get." However, it was discovered that most analyzers implement the base type approach. Accordingly, the ISAC feels that, in spite of the non- obvious effects of the interpretation, the short-term recommendation is to interpret "type" as "base type" in this section. Regarding the last question, the ISAC is unanimous in considering only declared signals, and no subelements thereof, when determining the signals to which a disconnection specification applies. Using these conclusions, the ISAC then examined the rules proposed above. The latter two are largely correct, except that they need to reflect the "base type" interpretation. The first rule, however, needs some extensive work. The rules, when taken together, should cover all cases. The first rule attempts to cover all composite signals, but only considers the unidimensional array case. Records and multidimensional arrays need to be considered, as do lists of signals. And for completeness, single, scalar signals need to be covered. Moreover, in line with Issue Report 40, disconnection specifications are interpreted as declarative part, rather than declarative region based. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The following language is intended to replace paragraphs 2 (including the three bulleted paragraphs immediately following), 3, and 6 of Section 5.3: Each signal name in a signal list in a guarded signal specification must be a locally static name that denotes a guarded signal. Each guarded signal must be a declared signal, or subelement thereof, whose base type is the same as the base type of the type mark indicated in the guarded signal specification. Each signal must be declared in the declarative part enclosing the disconnection specification. Subject to the above rules, a disconnection specification *applies to* the drivers of a guarded signal S of base type T under the following circumstances: * For a scalar signal S, if an explicit or implicit disconnection specification of the form disconnect S: T after *time*_expression; exists, then this disconnection specification applies to the drivers of S. * If the signal list in an explicit disconnection specification contains more than one signal, the disconnection specification is equivalent to a series of disconnection specifications, one for each signal in the signal list. Each disconnection specification in the series is created as follows: It has, as its single signal name in its signal list, a unique member of the signal list from the original disconnection specification. Its type mark and time expression are the same as those in the original disconnection specification. * For a composite signal S, an explicit or implicit disconnection specification of the form disconnect S: T after *time*_expression; is equivalent to a series of disconnection specifications, one for each scalar subelement of the signal S. Each disconnection specification in the series is created as follows: It has, as its single signal name in its signal list, a unique scalar subelement of S. Its type mark is the base type of the same scalar subelement of S. Its time expression is the same as that of the original disconnection specification. * A disconnection specification of the form disconnect others: T after *time*_expression; is equivalent to a disconnection specification where the reserved word OTHERS is replaced with a signal list comprising the simple names of those guarded signals in the enclosing declarative part whose base type is the same as the base type of T and that do not otherwise have an explicit applicable disconnection specification; the remainder of the disconnection specification is otherwise unchanged. If there are no guarded signals in the enclosing declarative part whose base type is the same as the base type of T and that do not otherwise have an explicit applicable disconnection specification, then the above disconnection specification as no effect. * A disconnection specification of the form disconnect all: T after *time*_expression; is equivalent to a disconnection specification where the reserved word ALL is replaced with a signal list comprising the simple names of those guarded signals in the enclosing declarative part whose base type is the same as the base type of T; the remainder of the disconnection specification is otherwise unchanged. If there are no guarded signals in the enclosing declarative part whose base type is the same as the base type of T, then the above disconnection specification has no effect. If, by the above rules, no disconnection specification applies to the drivers of a guarded, scalar signal S of base type T, then the following default disconnection specification is implicitly assumed: disconnect S: T after 0 nS; A disconnection specification that applies to the drivers of a guarded signal S is the *applicable disconnection specification* for the signal S. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Replace paragraphs 2, 3, and 6 of Section 5.3 with the above language, except that "base type" should be replaced with "type mark." Alternatively, some suggestions have been made to radically alter or entirely eliminate disconnection specifications. These suggestions include: 1. Eliminate the choices all and others from the signal list choices and remove the type mark from the guarded signal specification. The production for disconnection specifications would then appear as: disconnection_specification ::= DISCONNECT *guarded*_signal_list AFTER *time*_expression; signal_list ::= *signal*_name { , *signal*_name } The effect of this change is to remove the ambiguity regarding the type mark altogether, and to force each signal with a non-zero disconnection time to be explicitly named. The type mark is no longer necessary, since if the signal is named, the type mark is redundant (or as we have seen, potentially confusing). 2. Eliminate disconnection specifications and add a disconnection clause to signal declarations and interface signal declarations: signal_declaration ::= SIGNAL identifier_list : subtype_indication [ signal_kind [ disconnection_clause ] ] [ := expression ] ; signal_kind ::= REGISTER | BUS disconnection_clause ::= DISCONNECT AFTER *time*_expression The effect of this change is to directly associate disconnection time information with the declaration of the disconnectable signal. Note that it is harder to disconnect whole classes of signals with this syntax. 3. Eliminate disconnection specifications and allow null waveform elements (the second form of waveform element presented in Section 8.3.1 on page 8.4) in both sequential signal assignment statements (the currently allowed case) and concurrent signal assignment statements. The effect of this change is to directly associate disconnection time with the other parts of the behavioral description.