Re: [sv-ac] Issue of action block in reactive region.

Subject: Re: [sv-ac] Issue of action block in reactive region.
From: Stephen Meier (Stephen.Meier@synopsys.com)
Date: Thu Apr 24 2003 - 16:15:41 PDT

Adam:

Note that the issue you demonstrate was raised and resolve during last meeting and is included in Draft 6 of the LRM

In Sec 17.2:
That is, the expression does not evaluate to a known, non-zero value. The else
statement can also be omitted. The action block is executed immediately after the evaluation of the assert
expression.
So the message would print out non mutex values of a and b.

Note that action block is in reactive region for concurrent assertions and this follows the need to have clear separation between sampled signals and evaluating their results.  We need to wait for the active region to complete before we can see which clocks have occurred.

Adam I hope this clears this issue and we can have your support as you have worked very hard within the comittee to get to this point.

-Steve
----------
At 05:57 PM 4/24/2003 -0500, you wrote:



Hello all;

Based on the issue below, my vote is:

__ yes  _X_ no    Approve sending the LRM (the work performed by SV-AC) to the board for their approval.


Reading cadence's issue paper, I wrote this simple (similar) example:


assert property ( ! a & b)
   else begin
     $display("A and B not mutex, see a %b and b %b.", a, b);
    end


Cadence writes the action_block is executed in the reactive region. This causes
the code in the action block to potentially see different values than the
assertion code. This will make error messages of assertions unuseable when
trying to write out values in the message. E.g.


assert property ( ! a & b)
   else $error("A and B not mutex, see a %b and b %b.", a, b);


It would be terrible to see a message

Error ........

  A and B not mutex, see a 1 and b 0.


And leave the user scratching their head, wondering why the assertion fired
when the values it is showing are legal.


Is this an issue to be addressed as an erratta or a post 3.1 issue? I would
hope that this is not deferred to a 3.2 issue as it will allow implementations
to be produced that clearly have a deficiency.

One could also consider addressing the availability of dynamic variable values
for displaying in an error message. Currently the variable does not exist
out of the property scope.

   THanks.

   Adam Krolnik
   Verification Mgr.
   LSI Logic Corp.
   Plano TX. 75074



Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246

This archive was generated by hypermail 2b28 : Thu Apr 24 2003 - 16:16:59 PDT