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

>From: "Jonathan Bromley" <jonathan.bromley@doulos.com>

>> But there is still no way to determine whether a new evaluation
>> of the unique/priority construct is associated with a particular
>> previous violation in the same constructs.  In addition to the
>> loop situation, there can be tasks/functions called from multiple
>> places.
>
>Forgive me if I'm being dense, but I really don't follow
>this argument.  My point about permitting this sort of 
>behaviour only in an RTL-style always_? construct was to
>ensure that it was associated with a static process.
>If the violations/passes could be associated with the 
>static process, then it is presumably not too hard to
>delete ALL stored violations/passes associated with
>that process as soon as it is re-activated after 
>quiescing at the end of its always_?. 

I was talking about Doug's suggestion, which seemed to be just
delaying the reporting of the violation and discarding any reports
that were superceded.  I did not assume that he was combining this
with a process-activation-based mechanism for discarding the
violations.  That does seem like a possibility that has promise.


Steven Sharp
sharp@cadence.com


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