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

Hello;

Seligman, Erik wrote:
>
> 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.
>   
We also worked through examples like this...

module    xxx;

    assign #1 ready_now = (...);

endmodule

module top;

xxx m1 (.ready_now, ...)

   always @(*)
     begin
     if (new_in == 2)
       if (ready_now)
         begin
         assert property (@(posedge clk) ...) else $error("A bad thing.");
         ...

The signal 'ready_now' changes in a later timestep compared to the rest 
of the variables. We want to prevent
false failures in logic like this as well. Prior evaluations of the 
assertion need to be stopped and not reported
as a failure.

-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"


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