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

Hi John,

I also like your last example as that seems to be inline with how currently property evaluations happen. The intent of the proposal 1641 is to allow these tasks anywhere including the subroutine calls attached to a sequence but I think the subroutine calls should not change the overall evaluation of the property. One thing we need to clarify is that an $error call inside a subroutine should print out assertion specific info or it should get treated like any sequential code. The same question comes up when there are tasks/function calls inside action block which have these severity tasks in them.

Here are some examples to consider (Probably my syntax is not correct):

assert property (foo) else myfunc();

function myfunc()
  if (cond)
    $error(..);
endfunction

Since this function can be called from sequential code also, should the $error behave like action block call or sequential code call ? Or it can be sensitive to the fact if myfunc was called from assertion ?


Thanks.
Manisha


-----Original Message-----
From: owner-sv-ac@server.eda.org on behalf of John Havlicek
Sent: Tue 10/24/2006 5:11 AM
To: sv-ac@server.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.