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

Usually tasks do not return values, functions do. Are there exceptions
(my memory is a little fuzzy at the moment...)?

 

Shalom

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Kulshrestha, Manisha
Sent: Friday, November 03, 2006 7:56 PM
To: john.havlicek@freescale.com; sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] new mantis item and proposal #1641

 

Hi,

 

I agree that we need to clarify that these tasks are allowed anywhere
$display is allowed that includes match items. So, now the usage of
these tasks can be devided in two contexts: assertion (that includes
action block of concurrent and immediate assertions, match item and
boolean expression of concurrent and immediate assertions) and
sequential code. 

 

To keep things simple for the users, any direct or indirect call from
assertion context should print out assertion specific information. 

 

Here is an example:

 

task myTask()

   if (cond1)

      $error("failed");

   else

      $error("failed2");

endtask

 

assert property (p) else myTask(); 

 

always @(posedge clk)

    if (bad_cond)

       myTask();

 

Here the error printed by myTask() will print assertion information when
this task is called from action block. The error printed will print
information as per sequential code rules when called from always block.

 

To be able to use these tasks in boolean expressions, they need to
return values. We can add it in the proposal that these tasks return bit
type and the return value is 0 for $error and $fatal and it is 1 for
$warning and $info.

 

Now, since we are allowing usage of these tasks indirectly in assertion
action block (through task/fn calls), how do we determine the severity
of the assertions ?

 

Looks like this issue was discussed in the last meeting and some
questions were raised about usage in boolean expression and match items.
If everyone thinks that it is not clear how these will behave in match
item and boolean expression, we can update the proposal to make it
illegal in those contexts.

 

Please send your feedback.

 

Thanks.

Manisha

 

 

 

________________________________

From: owner-sv-ac@server.eda.org on behalf of John Havlicek
Sent: Tue 10/31/2006 5:05 AM
To: sv-ac@server.eda-stds.org
Subject: Re: [sv-ac] new mantis item and proposal #1641

Hi Manisha:

> 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.

This is fine with me.  I have just sent a response to Doug Warmke's
mail suggesting that we drop the idea of having severity tasks that
are match items influence the sequence or property evaluation.

We may need to find a clearer way to say that the severity tasks
are allowed anywhere that other tasks are allowed -- I'm not sure
whether the phrase "sequential code" covers every situation that
is intended.  E.g., it wasn't clear to me that sequence match items
are included under sequential code.

> 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.

In my mail I suggested that for the case of a unified error
handling subroutine, it will be more useful if the action block
rules for the reporting are used than the sequential code rules. 

This point of view argues for using the action block rules of 1641
whenever the severity task is called directly or indirectly
from an assertion action block or sequence match item.

On the other hand, I can see the decision of which rule to use
becoming complex.  E.g., if the severity task is called after some
time delay or after some additional checking of error conditions, then
it may be preferable to use the sequential code rules from 1641.

Another possibility is to give the user a way (similar to %m) to
capture the assertion reporting information that would be printed
according to the action block rule and manage the incorporation of
this information.  This new mechanism could be made available only
within the action block or in the actual argument expressions to
a sequence match item. 

This new mechanism could allow a simpler rule about what the tool
prints and also provide the user the ability to get all the
information in various more complex cases.

Best regards,

John H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Tue, 24 Oct 2006 10:14:44 -0700
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: [sv-ac] new mantis item and proposal #1641
> Thread-Index: Acb3ZZCRqccrAjllQhq+ddevy/4YswAKHVO/
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> X-OriginalArrivalTime: 24 Oct 2006 17:14:46.0128 (UTC)
FILETIME=[E7668F00:01C6F78F]
>
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C6F78F.E687E95D
> Content-Type: text/plain;
>       charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> 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
> =20
> 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.
> >=20
> > 3. Another topic is the use of severity tasks as subroutine calls
> >    attached to sequences.  I think we should consider whether=3D20
> >    the result of the assertion evaluation should be sensitive
to=3D20
> >    something like a $error called as a subroutine attached to=3D20
> >    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=20
> evaluation.
>
> One of the lingering areas of untidiness is error reporting with=20
> 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=20
> 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 |->=20
>      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=20
> $display does not execute.
>
> There are hacks to overcome this difficulty, like
>
>    r |->=20
>      if (bad_condition) (1, $display(...<local variables>...)) ##0 0
>      else p1
>
> It might be nicer to be able to write
>
>    r |->=20
>      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=20
> write
>
>    r |->=20
>      if (bad_condition) $error(...<local variables>...)
>      else p1
>
> This last version of the code looks the most intuitive to me.
>
> Best regards,
>
> John H.