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

Gord,

   Your scheme seems like it would remove more of what I'd call "glitch"
failures.  Is it possible to come up with a more precise definition of
"glitch"?   Does it make sense to say that glitches are conditions that
are not stable during a single unit of simulation time?  If this was
sensible, how would your proposal change if the deferred reports were
also associated with a simulation time unit.  The "purging" step would
only eliminate reports marked as coming from the same simulation time
as the "present".   I'm not very familiar with the definition of
"observed region", so perhaps this is accomplishing the same effect
(by reporting the deferred messages whenever the simulation time advances).

Greg

Gordon Vreugdenhil wrote:
> 
> 
> 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.


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