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

Steven Sharp wrote:
>> 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 is what I was trying to get at with the comments that in
some cases, we might get odd behavior.

I think if you read "evaluating" as "becomes active" you get
the idea of what we have in mind.

If a process "becomes active" prior to a deferred unique violation
being reported, that violation is tossed.

One can certainly create situations in which that is bad.  Here is one:

     bit a,b;
     always @(a) begin
        unique case ...   // case 1
        endcase
        @(b);
        unique case ...   // case 2
        endcase
     end
     initial begin
         #10;
         a = 1;
         b <= 1;
     end

In this case the always isn't combinational and includes
assumptions about internal event sequencing.  In this
case any violation of "case 1" is lost since the process
becomes active again at time 10 prior to observed.
Anything comparable with #0, etc. would have the same
kind of issue.

I don't feel too bad about this but then I'm not a designer.

I don't know if there are situations under which a
real design style would lead to losing important assertion
failures.  So far, no users have raised issues which is
why we wanted to bring this up for more general consideration.

As I said originally, given the real problems with glitches
in combinational scenarios, this seems to be a reasonable
tradeoff.  I think that all the combinational and clock
gated processes that we've seen are well-behaved under
the proposed approach.



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


I think that we will have to discuss continuous assigns here (I assume
that is the scenario that you are really worried about).

Most of the unique/priority cases that I've see come from always_comb
and similar and not as often in functions called from continuous
assigns.

Users will have to speak up in this area -- I don't know how crucial
it is to be careful about continuous assignments.  It certainly
will be in the AC "assert" domain, but I don't know about whether
it is as big an issue here.

I would support the same semantics for continuous assigns, but
would certainly consider other alternatives that were well formed.
Would you suggest treating unique/priority violations in the
current immediate manner in such scenarios and differently in
true "process" contexts?  If so, we could see what users think about
that.

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.