RE: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches

>From: Seligman, Erik [mailto:erik.seligman@intel.com] 

>But isn't the first non-event-control statement in a procedural block
>still something that is well defined?  Is a procedure truly an amorphous
>loop that can be 'rotated' so randomly by a compiler that we have no way
>to define this first statement?

The problem is that the only execution where the first statement in
the block is guaranteed to be the first one executed is the initial
one at time zero.

After that, the first statement executed on a wakeup is going to be
the one after the event or delay control at which it suspended.  That
may not be the first non-event-control statement in the block.  The
loop is not being 'rotated' by the compiler; it is being 'rotated'
by the user when they decide where to insert an event control.  And
it can only even be regarded as a 'rotation' if they insert a single
unconditional event control.

Gord's proposal focuses on the wakeup, which has a closer correspondence
to the start of execution of the block than anything based on physical
position in the block.

A minor nitpick: an event control is not technically a separate statement.
It is syntactically a prefix attached to a statement.

A bigger nitpick:

  always
    begin
      @(a,b)
        c = a + b;
    end

The "first non-event-control statement" in this block is the begin-end
statement.  But that probably is not what you had in mind.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.