Re: [sv-ac] Errata 269: Asynchronicity of disable iff in relation to the sampling clock

Hi Bassam;

You suggestion is that the order will be used to specify a synchronous or
asynchronous reset (disable.) E.g.

// Asynchronous reset.
assert property ( disable iff (reset) @(posedge clk)
    an_expression)
    else $error("bad a");

// Synchronous reset.
assert property ( @(posedge clk) disable iff (reset)
   an_expression)
   else $error("bad a");

Is the order of the two elements (disable statement and clock specification)
too implicit, thereby causing user grief simply because they wrote the wrong
order, or added the disable statement "in the wrong place"?

Maybe a more explicit way to show an asynchronous vs a synchronous disable would be
better. I came up with the use of an edge specifier to denote asynchronous disables.
E.g.

// Asynchronous reset.
assert property ( @(posedge clk) disable iff (posedge reset)
    an_expression)
    else $error("bad a");

// Synchronous reset.
assert property ( @(posedge clk) disable iff (reset)
    an_expression)
    else $error("bad a");

This more closely matches expectations of users who write inferred register blocks.

always @(posedge clk or negedge rst_n) // <<< Asynchronous reset.
   if (!rst_n)
     begin
     <reset state>
     end
   else
     begin
     <update state>
     end

vs.

always @(posedge clk) // <<< No edge on reset, thus Synchronous.
   if (!rst_n)
     begin
     <reset state>
     end
   else
     begin
     <update state>
     end

     Adam Krolnik
     Verification Mgr.
     LSI Logic Corp.
     Plano TX. 75074
     Co-author "Assertion-Based Design"
Received on Tue Oct 26 12:51:47 2004