From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Wed Jul 31 2002 - 22:47:56 PDT
Precedence: bulk
Stefen,
This was classified, apparently by mistake, as an enhancement.
I think it should be reclassified as an erratum.
Shalom
sharp@cadence.com wrote:
> >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.
-- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478"The devil is in the details."
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:27 PDT
and
sponsored by Boyd Technology, Inc.