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

One additional detail here that I forgot and was
just reminded about (thanks Tej!).

I had originally proposed "observed" region reporting.  For
the assertions, AC seemed to prefer reporting in the
"postponed" region.  This is only different in cases where
there is a big-loop iteration from re-active back to active
AND a given process encounters a glitch due to that.

My feeling is that such glitches are a bit different than
a "within active" glitch.  In well behaved designs, I would
expect that the set of processes that run before and after
the reactive region should be disjoint so I don't feel
very strongly about this either way.

If anyone has a good rationale for either side, that would
be helpful.  Unless there is a good reason, we should probably
try to end up with the same reporting region as what AC
decides on.

Gord.

Gordon Vreugdenhil wrote:
> 
> There has been considerable discussion regarding how to handle
> unique/priority "assertion" failures in the context of glitches.
> 
> Someone here came up with a different way of thinking about the
> problem that I think clarifies and simplifies things while producing
> behavior that addresses user issues.
> 
> The basic idea is that as a *process* executes, any unique/priority
> failure is determined but NOT reported.  The deferred report is
> associated with the *process* and is reported in the observed region.
> If the process re-evaluates prior to the observed region, all
> pending unique/priority failures are discarded.
> 
> This cleanly handles all scenarios including function and task
> enables, internal delays, etc.  It seems to be pretty easy to
> reason about and completely covers the truly problematic cases
> that have been raised.
> 
> There are a few edge cases involving re-triggering with internal
> process side-effects where one could argue that reports might
> get lost, but those cases would almost always be subject to
> simulator dependent scheduling and other effects that would likely
> lead to ill-behaved designs.
> 
> Given the trade-offs here, we believe that the suggested
> conceptual approach is a simple and effective solution to the
> problems that have been raised.
> 
> If there is general consensus on this in BC, we can move forward
> with writing up a proposal.
> 
> I've also raised this conceptual approach with AC during the
> recent face-to-face in terms of a variation of immediate assertions
> when glitch stability is an issue.  I haven't been tracking their
> decisions since I've been a tad busy lately, but they are aware
> of this as a conceptual approach.
> 
> 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.