RE: [sv-ac] Re: [sv-bc] 2005: Deferred assertions (new proposal at http://www.verilog.org/mantis/view.php?id=2005)

 > Can the discussion about using an event expression be expanded ? Does
it really mean that when a deferred 
 >  assertion is executed delayed from a clocked event, its checking is
suppressed ? This would seem to give a false
 > sense of security if logic is used a different clock domain. [ False
security since the user sees an assertion in there but
 >  it does nothing because the wrong clock is being used.]  On the
other side, concurrent assertions would be
 >  evaluating assertions in the wrong clock domain and report (most
likely) a failure.
 
Yes, this is the compromise we are making.  There is obviously a level
of responsibility required for the user; these must be used carefully.  
 
Here's an idea that might fix your concern though:  rather than dropping
the assertion if the event did not occur, keep the assertion failure
queued, only flushing it if the procedural block is re-entered.  That
way the situation you mention would be avoided:  if the event eventually
does occur, and the process did not run again, the failure is not lost.
If the process is run again, we can probably dismiss the previous
execution as a glitch anyway.  For example:
 
always @(a) begin: blk1
    ...
        assert @(posdege clk2) b != c;
   ...
 
If event 'a' occurs on a different clock, and the assertion fails, the
failure is saved.  Then when clk2 eventually has an edge, if blk1 was
not executed again, the previous failure is reported.  I think this
makes sense-- presumably if the process was not re-executed, the values
that caused the assertion failure are still in effect at the later
clock.
 
Of course, I'll wait to see what DougW puts in his edits before making a
change...
 

 >  What happens to the delayed assertion, inside a function, if called
from multiple processes ? Does it evaluate 
 > and report failures correctly for each process ?   
 
Yes, executions in multiple processes are independent.  So the deferred
assertion may get multiple failures reported, resulting from different
process contexts.  Naturally, for such an assertion, the user should
include an action block that reports enough info to identify the failing
situation; maybe we should add an example illustrating this to the
proposal.
 
 
>  It would seem that maybe concurrent assertions should be
>  supported in functions if one is going to support deferred assertions
in functions. 
 
This was actually our original proposal!    At our SV-AC F2F it got
ripped to shreds, as defining concurrent assertions in arbitrary
procedural contexts leads to many difficulties.  Basically it is very
hard to identify an 'instance' of a concurrent assertion that may be
executed multiple times and multiple ways within procedural code.  (Your
question above about multiple processes hints at this difficulty.)   We
were attempting to define it in reference to instances created by
synthesis, but as synthesis has no clear definition in the SV LRM, this
opens a huge mess.  
 
The current proposal is an attempt at a compromise that will accomplish
most of the original goals (allowing glitch-protected procedural asserts
that can be prevented from firing at known-to-be-bad time steps) while
still defining something that is essentially an immediate assertion.
 




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