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

Seligman, Erik wrote:
>  
> 
> 
>> Consider the following (abusive situation):
>>      initial begin
>>        // assert something false  (1)
>>        #0;
>>        // assert something false  (2)
>>        #1;
>>        // assert something false  (3)
>>     end
> 
>> In my approach, the process becomes active at time 0.  Any deferred
> assertions (none) are flushed.  We then "schedule" assert 1 for the
> observed region and do the #0.  The process becomes active *again* at
> time 0.  Pending assertions -- i.e. assertion 1 -- are flushed.
> 
> If we are asserting something, then after an explicit #0 delay asserting
> something else, why should the first assertion be considered a glitch?
> Isn't it likely that these are two different checks of two different
> conditions?

Yup.  And again, this is why I am only claiming that this makes
sense at all for *combinational* situations.


I am making a very explicit tradeoff.  In order to get a
clear behavior for all *combinational* loops, I am prepared
to have "glitch free" assertions be lost if the process
has such non-combinational glitch behavior.  If the user
wants assertion 1 in the above to be reported, the user
should be using a truly immediate assertion.

I would leave it to lint tools or similar to warn users if
they use a "glitch free" assertion in a non-combinational
situation or, inversely, if they use an immediate assertion
in a combinational scenario.

If the semantics of either type of assertion is clear and concise
and *it is possible* to reasonably describe correct combinational
behavior in all forms, I think that we're done.  I'm personally
not so worried about what happens when a user picks the wrong
assertion form since that is a matter of education.  I am worried
about making the rules clear and unsurprising in terms of the
scheduling relationships.

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