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

>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 concept of the process "evaluating" seems to assume that all
processes behave like continuous assignments: waking up, evaluating,
and suspending to wake up in the same place and execute the same code
next time.  But in fact, processes are not constrained to behave that
way.  They can suspend and wake up in a different place each time and
execute completely different code each time.  How do you define
"evaluating" for the arbitrary case?

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

As with fork..join_none in functions, there are problems because
functions can be called from constructs that may require subprocesses
to implement, but which are not formally recognized as processes by
the LRM.  That leaves their behavior ill-defined under your process-based
proposal.  The issue was avoided with fork..join_none by making it an
error to execute the fork..join_none from any of these constructs.  Would
you propose the same restriction for unique/priority?  Note that trying
to define what a process is for these situations may get into contentious
issues based on how different tools have implemented them.

Internal delays would seem to get into the same issue raised above with
the definition of "evaluating".  If a process waits for an internal #0
delay and then continues executing, is this a new "evaluation"?


Steven Sharp
sharp@cadence.com


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