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

That's an interesting one!

So here's a question for the gurus:  does reaching the 'end' and going
back to the 'begin' constitute a rescheduling?  In other words, would
the flush-on-rescheduling alg rescue assert2 below?

On the other hand, I think we have a problem here in that with
flush-on-rescheduling, we lose assert1.


-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Tuesday, October 16, 2007 11:02 AM
To: Seligman, Erik
Cc: Brad Pierce; sv-ac@server.eda.org; sv-bc@server.eda-stds.org
Subject: 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.

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