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

Hi Erik,

Here is a pathological case for you:  Suppose you have the following:


    always begin
	a = b;
	assert_deferred assert1 (...);
	c = d;
	@(b or d or f);
	e = f;
	assert_deferred assert2 (...);
	g = h;
    end

If we define the assertion cancellation point of the always block as the top
as you propose, then assert2 would never be reported.  The execution flow will
always wrap around to the top of the block, and assert2 will be cancelled.

You won't see this in synthesizable code, but you might see variations of this
in test bench code.

Tom

Seligman, Erik wrote On 10/16/07 08:04 AM,:
> 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?
> 

-- 
------------------
Thomas J. Thatcher
Sun Microsystems
------------------

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