[sv-ac] RE: [sv-sc] Re: ConcurrentAssertNewProposal

 


> This does have a substantial bearing on whether dealing with the
complexity of deferral is needed.  It is definitely much more complex
> to define deferral in this context than in the simpler context of a
zero-time glitch.  This would really need to be able to describe
> non-zero time "clock period" glitching and the impact of that on
assertion state and which assertions are "killed".  In the deferred
> assertion context this was relatively simple to describe since it was
"all or nothing".  Here, I think it is much more touchy since
>there may be already evaluating instances of the assertion at later
steps that we can't kill; it is only the "pending" ones.

Is it that hard to figure out which instances of an assertion were
triggered in the current time step, and which were triggered in previous
ones?  I don't think we need any concept of non-zero-time glitching:  if
an assertion instance was started in a previous time step & continues
due to sequential expressions, it should not be affected.  Only
zero-time glitching is prevented through the deferral method.  It looks
to me like implementing this should be roughly equivalent to
implementing deferred assertions anyway.

Remember that one of our main motivations here is to enable the creation
of generic assertion (and checker) libraries.  We don't want to have to
require the user to call special-case versions of library elements
depending on whether they are in a clocked or unclocked procedure, so
it's important that we come up with general rules that apply to all
cases.

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