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

Seligman, Erik wrote:
> 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?

Yes.  The scheduling sequence here is:
    assert1
    event control
    assert2
    assert1
    event control
    assert2
    assert1
    event control
etc.

This is a pure sequential iteration just like a "forever" loop.
In fact an "always" is really just "initial forever".

So in this case, if the event control glitches, you'll get
an "assert2 assert1" evaluation in each glitch iteration.
The only time assert1 is seen independently is the initial
entry to the always at time 0 and that is explicit in the code.

Gord.

> 
> 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.
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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