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

Seligman, Erik wrote:
>> One could, however, construct an explicit internal "forever @(...)"
>> loop *within*  a sequential process.  Consider the following:
>>    initial begin
>>       // do some preamble
>>       forever @(a,b,c) begin ... end   // I want this to be
> combinational
>>    end
>> If such code was written explicitly by the user, Erik's approach would
> lose the "combinational glitch suppression" behavior 
>> while my approach would not.
> 
> 
> So, if I'm reading right, you're saying that someone might want this
> glitch suppression not at the true process granularity, but at the level
> of an internal subprocess.  You're right, this would be hard to do.  
> 
> Can you describe in more detail how this example would be handled with
> your alternative method?  

I am making not a syntax or structure based definition, I am making
a definition based on *scheduling* semantics in the core simulation
event scheduler.

What I am saying is that whenever the process *becomes active*,
no matter what the reason, the deferred (unreported) assertions are flushed.

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.
Assertion 2 occurs and we suspend on the #1.  In the observed region
of time 0, assertion 2 is reported.  At time 1 the process awakes,
flushes nothing and schedules assertion 3.  The process then "dies"
(i.e. is never rescheduled). In observed of time 1, assertion 3
is reported.

A combinational internal sub-loop follows directly from this.  Given
    forever @(a,b,c) begin
    end

The process, no matter how we got there, becomes active on
changes to a,b,c and ends up with the correct flushing behavior.

The nice thing is that in the presence of disables or such sub-loops
and other odd situations, I think you pretty much always get the
right behavior *for combinational situations*.


 > Isn't it inherently impossible for the
> compiler to know which granularity you really want the glitch-freedom to
> apply at, unless we provide a mechanism for an explicit user hint?


Yes.  That is why neither approach is perfect.

For the BC issues of unique/priority, I think that it is easier to make
the call to go with my suggestion.  For the general immediate assertions
case, it is somewhat less clear.  However, I would still argue that
as long as we do have a syntactic difference between an immediate assertion
and a "deferred" immediate assertion, that it is perfectly reasonable
to use true immediate assertions in the cases where my approach would
lose assertion reports.  After all, in such scenarios, the designer
is pretty much explicitly taking control of the sequencing and
it seems unreasonable to expect automatic glitch suppression.

Essentially what I am saying is that for any combinational process
(or subprocess) either the two approaches are the same or my
approach handles the glitches.  In non-combinational approaches,
I don't care nearly as much since I think either approach likely
has anomolies since "glitch free" is really targeted at combinational
processes.  True immediate assertions are more appropriate to use
in such scenarios.

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.