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

In this case, since the event control is not immediately after the
'always', I would say the 'if' statement begins the procedural block,
fitting the definition of ' first non-event-control statement ' used
below.  Thus the flush point for our glitch-free assertions would be
right before the 'if'.  

Does this cause a problem?
  

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Brad Pierce
Sent: Tuesday, October 16, 2007 7:55 AM
To: sv-ac@server.eda.org
Cc: sv-bc@server.eda-stds.org
Subject: RE: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches

Which event control is first in the following always procedure?

   always if (c) @(posedge clk); else @(negedge clk);

-- Brad

-----Original Message-----
From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Tuesday, October 16, 2007 7:21 AM
To: Brad Pierce; sv-ac@eda.org
Cc: sv-bc@eda-stds.org
Subject: RE: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches


>>I'm not sure I see how this causes a major problem with the "flush 
>>deferred assertions at the top of the block" model we were discussing 
>>before.  Why can't we define the flushing to occur after the event 
>>control at the top of each procedural block?
...
> This assumes that there is an event control at the top of each
procedural block.  The language doesn't require that there be one.
...
> Yes, and there can be multiple event controls scattered throughout the
procedural block, too.

I'm not too worried about providing good support from these new
glitch-free assertions for blocks with lots of event controls inside, as
long as we do something reasonable.

It seems to me that these are nitpicks with the phrasing, rather than
essential problems with the proposal.  Steve's description shows that we
have to describe things carefully since a common procedural block
suspends its execution at the top event control (if there is one) rather
than at the bottom of the block.  

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?

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

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