enhancement/85: repeat event_control grammar ambiguity

From: sharp@cadence.com
Date: Tue Jul 30 2002 - 17:41:28 PDT


Precedence: bulk

>Number: 85
>Category: enhancement
>Originator: sharp@cadence.com
>Description:

Blocking and nonblocking assignments allow an intra-
assignment timing control, which is represented in the
grammar as delay_or_event_control. This can expand to a
repeated event control of the form

  repeat (expression) event_control

See syntax 9-1, 9-2 and A.6.5.

This has the semantic of evaluating expression and then
waiting until event_control has happened that many times
before completing the assignment. This is described in
section 9.7.7, along with a redundant syntax box 9-12
that includes the same syntaxes as 9-1 and 9-2.

Unfortunately, the exact same grammar nonterminal is used
in syntax 9-8 for procedural timing controls, which allows
the use of a repeat count on a normal event control in a
procedural_timing_control_statement. This leads to an
ambiguity in the grammar. The source code:

repeat (5) @(a) b = c;

could be parsed as

delay_or_event_control statement_or_null
repeat (5) @(a) b = c;

or as loop_statement, which expands to

repeat (expression) statement
repeat (5) @(a) b = c;

In other words, is the repeat attached to the event control,
or is it around the entire statement which includes the
event control?

This is not just a benign grammar ambiguity. It makes a
semantic difference what the repeat is attached to. If it
were attached only to the event control, it would wait for
the event to happen the appropriate number of times, then
execute the statement once. If it is attached to the
statement, then the entire statement will be executed that
number of times.

In fact, a repeated event control is only possible as an
intra-assignment timing control. A repeat elsewhere will
be parsed as a loop_statement.



This archive was generated by hypermail 2.1.4 : Thu Oct 10 2002 - 09:24:27 PDT and
sponsored by Boyd Technology, Inc.