VHDL Issue Number: 0204 Classification: Language Definition Problem Language Version: VHDL-87 Summary: The rules for constructing sensitivity lists neglect actual signal parameters. Related Issues: 0031 Relevant LRM Sections: 7.1, 8.1, 9.3, 9.4, 9.5 Key Words and Phrases: Sensitivity lists, expression primaries, actual signal parameters Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Section 8.1 was revised. Superseded By: N/A ----------------------- Date Submitted: 1991/03/16 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: 1991/03/21 Author of Analysis: Alex Zamfirescu Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/04 01:45:13 $ Description of Problem ---------------------- Consider the following wait statement: wait until F(S); where S is some signal and F is a predicate taking a signal parameter. Is this wait statement equivalent to: wait on S until F(S); as is probably intended, or is it equivalent to: wait; which seems to be implied by the LRM. Consider paragraph 2 of Section 8.1 (on page 8-2), which gives the rules for constructing the sensitivity list of a wait statement when none is explicitly specified: If no sensitivity clause appears, the sensitivity set will contain the signals denoted by the longest static prefix of each signal name that appears as a primary in the condition of the condition clause. Unfortunately, according to the BNF of Section 7.1, a function call is a primary in and of itself. Thus, it would seem that the sensitivity set of the first wait statement is the null set. Therefore, it is equivalent to the final wait statement, not to the middle wait statement. This situation is probably not what was intended. There is similar language defining the wait statements of the processes equivalent to concurrent procedure calls, concurrent assertion statements, and concurrent signal assignment statements. Specifically, paragraph 3 of Section 9.3, on page 9-5, states: If there exists a primary that denotes a signal in the actual part of any association element in the concurrent procedure call, and that signal is associated with a formal parameter of mode in or inout, then the equivalent process statement includes a final wait statement with a sensitivity clause that contains the longest static prefix of each signal name appearing as a primary in an actual part and associated with such a formal parameter; otherwise, the equivalent process statement contains a final wait statement that has no explicit sensitivity clause, condition clause, or timeout clause. Similarly, paragraph 3 of Section 9.4, on page 9-6, states: If there exists a primary that denotes a signal in the boolean expression that defines the condition of the assertion, then the equivalent process statement includes a final wait statement with a sensitivity clause that contains the longest static prefix of each signal name appearing as a primary in that expression; otherwise, the equivalent process statement contains a final wait statement that has no explicit sensitivity clause, condition clause, or timeout clause. Finally, item 4 of paragraph 5 of Section 9.5, on page 9-8, states: If the concurrent signal assignment statement is a guarded assignment, or if there exists a primary that denotes a signal in any expression (other than time expressions) within the concurrent signal assignment statement, then the process statement contains a final wait statement with an explicit sensitivity clause. The sensitivity clause contains the longest static prefix of each signal name (if any) appearing as a primary in one of the above-mentioned expressions. Furthermore, if the concurrent signal assignment statement is a guarded assignment, then the sensitivity clause also contains the simple name GUARD. (The signals identified by these names are called the inputs of the signal assignment statement.) Otherwise, the process statement contains a final wait statement that has no explicit sensitivity clause, condition clause, or timeout clause. (There may not be a problem in this regard with Section 9.5, since it states "in any expression"; however, for completeness, it is included.) Proposed Resolution ------------------- Change the definition of the contents of the sensitivity sets in the above- mentioned contexts to use a recursive rule. The rule should recur on every primary appearing in the expressions as follows: * names: There are several subcases: - simple names: This is a base case. Add the name to the sensitivity set if the name denotes a signal. - operator symbols: This is a base case. No signals are added to the sensitivity set for operator symbols. - selected names: There are two subcases: o selected names: If the prefix denotes a signal (which might be itself another recursive rule) add the signal denoted by the entire selected name to the sensitivity set. o expanded names: If the prefix denotes a package and the suffix denotes a signal, add the signal to the sensitivity set. Otherwise, no signals are added to the sensitivity set for this case. - indexed names: If the prefix denotes a signal, add the prefix to the sensitivity set. Recur on all expressions in the indexed name. - slice names: If the prefix denotes a signal, add the prefix to the sensitivity set. Recur on the discrete range. - attribute names: If the attribute designator denotes a predefined signal attribute, add the signal denoted by the attribute name to the sensitivity set. Otherwise, recur on the prefix. * literals: This is a base case. No signals are added to the sensitivity set for literals. * aggregates: Recur on the (actual) expression of every element association. * function calls: Recur on the actual designator appearing in every association element of the parameter association list. (OPEN is a base case requiring no additions to the sensitivity set.) * qualified expressions: Recur on the expression or aggregate, as appropriate. * type conversions: Recur on the expression. * allocators: This is a base case. No signals are added to the sensitivity set for allocators. * parenthesized expressions: Recur on the expression. * discrete ranges: There are two subcases: - The discrete range is expressed as a discrete subtype indication: Recur on the constraint. - The discrete range is expressed as a range: Recur on the range. * constraints: There are two subcases: - range constraints: Recur on the range. - index constraints: Recur on the discrete ranges. * ranges: There are two subcases: - range attribute names: Recur on the attribute name. - simple_expression direction simple_expression: Recur on the expressions. VASG-ISAC Analysis & Rationale ------------------------------ The proposed resolution requiring changes in the definition of the contents of the sensitivity sets is not a simple clarification or interpretation of some incompletely defined semantic. The rules for constructing the sensitivity list are clear in the LRM. The only contradiction is between what these rules represent and the "presumed intention" of the language designers. Statements like wait on S until F(S); are recommended for the cases where the sensitivity on S is needed. Implementing the proposed resolution will not imply that in the following example wait on CLOCK until F(S); the sensitivity list will contain signal S. Only CLOCK will belong to the sensitivity list in this case because the proposed resolution applies only in the case when no sensitivity clause appears. That will maintain the versatility of the language. The rule for waiting on a null signal should be the same as for a waiting on a signal that can have an event (i.e., if there is a sensitivity clause only the signals in the sensitivity clause will appear in the sensitivity list). This means that if x is a null signal then wait on x until F(S); is equivalent to wait; There are also other cases, like the concurrent signal assignment S1 <= F(S); where the presence of signal S in the sensitivity list might be desirable. Note that the previous example could be implemented using actual rules by S1 <= F(S) when S = S; or S1 <= F(S) when not S'STABLE; In conclusion, (a) the rules of the LRM are clear, and (b) modifying these rules as stated in the Proposed Resolution section will not reduce the power of the language. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The recommendation for 1987 is "Do nothing." VASG-ISAC Recommendation for Future Revisions --------------------------------------------- There are two ways to fix the problem. The first one is an upward compatible solution involving the addition of constructs that will flag signals that are not primaries to be added to the sensitivity list. There is no need to introduce new key words since STABLE, QUIET, EVENT, ACTIVE, or TRANSACTION can be used in defining the special construct. The second way is to use the proposed resolution recursive rules that are applied on every primary appearing in the applicable expressions of wait statements, processes equivalent to concurrent procedure calls, concurrent assertion statements, and concurrent signal assignment statements. This solution might invalidate some models and therefore is not an upward compatible solution.