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

I agree with Steven that we should make more definitive
choices now; the interaction between implicit and explicit
will be very odd if we retrofit explicit later.


I think this boils down to a degree of control question.
Any choice for implicit control will have scenarios under
which that choice is "clearly" wrong.  We have to decide
whether the usability cost associated with explicit control
is better than having some poor choices otherwise.

Since we will still have immediate assertions and since many
of the "glitch" issues are combinational (or close), I guess
that my personal preference would be to go with implicit
control and say that users will have to live with immediate
assertions otherwise.

Although I'm not terribly comfortable with the precedent we
may be setting with the event versus delay scheduling semantics
that Steven suggested, I wouldn't oppose such an approach
if that is deemed to help in realistic scenarios.

Gord.


Steven Sharp wrote:
>> From: "Seligman, Erik" <erik.seligman@intel.com>
> 
>> I think some ability for explicit control here is a good idea.  But we
>> should probably make it a separate Mantis, just because the basic
>> concept in 2005 is controversial enough that I don't want to
>> unnecessarily complicate things.
>>
>>From today's discussion, it sounds like the flush-on-event-reschedule
>> alg suggested by Steven may be a good way to go.  I'll start working on
>> a revised 2005 proposal on that basis.
> 
> Erik,
> 
> I wasn't suggesting that the explicit flushing control be in addition
> to the implicit flushing.  That would only let you flush extra times,
> not avoid flushing when you don't want to.
> 
> I was suggesting that the explicit flushing control be instead of
> the implicit flushing.  That way you can flush when you want to, and
> avoid flushing when you don't want to.
> 
> Gord suggested that implicit flushing would still be reasonable for
> a few cases like always_comb.  Those don't have problems with multiple
> event controls or delay controls or the position of the event controls,
> because they don't allow anything but the implicit one which is at a
> known position.  The explicit flushing would be used elsewhere.
> 
> I don't know that the explicit flushing is a better way to go than an
> implicit flush-on-event-reschedule mechanism.  But if we wanted to go
> that way, it isn't something that can be "added on" to the implicit
> approach later.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

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