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

It would seem that for immediate asserts it is not scheduled, it
executes like an if statement. At least this is what the LRM says. 

ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Lisa Piper
> Sent: Tuesday, October 24, 2006 9:53 AM
> To: sv-ac@eda-stds.org
> Subject: 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.
> 
>