RE: [sv-ac] new mantis item and proposal #1641

In 1641, it states:

"The pass and fail statements of an assert statement are executed in the
Reactive region."

Is this true for both immediate assertions and concurrent assertions?

Lisa

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Tuesday, October 24, 2006 8:11 AM
To: sv-ac@eda-stds.org
Subject: Re: [sv-ac] new mantis item and proposal #1641

Hi Manisha:

> I do not quite understand your point 3. In what situations you think
> someone may call $error as a match item subroutine ? Also, how do we
use
> it as part of evaluation. Could you please elaborate on this.
> 
> 3. Another topic is the use of severity tasks as subroutine calls
>    attached to sequences.  I think we should consider whether=20
>    the result of the assertion evaluation should be sensitive to=20
>    something like a $error called as a subroutine attached to=20
>    a sequnce.

My understanding of the current proposal is that the severity tasks
are allowed in sequential code and in assertion action blocks, so
attaching a severity task as a match item is not allowed.

However, I think we should consider whether to allow this and, if so,
whether execution of a severity task should impact the assertion 
evaluation.

One of the lingering areas of untidiness is error reporting with 
local variables.  Since the action blocks execute once per attempt,
we have said for a long time that local variables cannot be referenced
in an action block.

Local variables can be passed to subroutines that are match items.

However, as we discovered back in the SV 3.1a effort, it can be 
tricky to write a property so that it fails according to the semantics
and so that the subroutine match item also executes.  For example

   r |-> 
     if (bad_condition) (0, $display(...<local variables>...))
     else p1

doesn't work.  The "0" is intended to cause the failure of the
property, but the failing of the evaluation of "0" means that the 
$display does not execute.

There are hacks to overcome this difficulty, like

   r |-> 
     if (bad_condition) (1, $display(...<local variables>...)) ##0 0
     else p1

It might be nicer to be able to write

   r |-> 
     if (bad_condition) (1, $error(...<local variables>...))
     else p1

and have the $error cause the property to fail.

Or it might be even better to say that a severity task can stand
as a property with constant truth value -- $fatal and $error evaluate
to false, while $info and $warning evaluate to true.  Then one could 
write

   r |-> 
     if (bad_condition) $error(...<local variables>...)
     else p1

This last version of the code looks the most intuitive to me.

Best regards,

John H.