Hi John, I agree that we should not covert these system tasks to system functions. Now the question comes how to support them in the boolean expressions. One solution is that user himself writes wrapper functions and returns 0/1 depending on what he wants to do. Here is an example: function myerror_function(int i, int j); $error("myassertion failed. Values of local vars is %d %d", i, j); return 0; endfunction; The user will use this myerror..() function in the boolean expression and get the same effect. Another option is that we state it that a top level $error call in boolean expression will be replaced by '(1, $error) ##0 0'. For e.g. r |-> if (bad_cond) $error() will be replaced by r |-> if (bad_cond) (1, $error()) ##0 0 Any other suggestions are welcome. Manisha -----Original Message----- From: owner-sv-ac@server.eda.org on behalf of John Havlicek Sent: Wed 11/8/2006 4:38 AM To: sv-ac@server.eda-stds.org Subject: Re: [sv-ac] new mantis item and proposal #1641 Hi Manisha: I think we should follow the suggestion from you and Doug that a severity task called as a sequence match item does not influence the outcome of the assertion evaluation attampt. I believe that there was no disagreement on this point when it was discussed. I also would like to be able to write a severity task call as a property expression for the reasons I have indicated before: it gives a nice was to code both a failure condition and to pass the local variables to the severity task. E.g., with severity tasks as match items, one can write property foo; <local var declarations> sequence_with_local_vars |=> if (bad_condition) (1, $error(<local vars>)) ##0 0 else p1 ; endproperty If $error is understood to have value 0 as property expression, then we can write this more simply as property foo; <local var declarations> sequence_with_local_vars |=> if (bad_condition) $error(<local vars>) else p1 ; endproperty I don't think it is necessary to try to define severity tasks as functions. I am not suggesting general use of severity tasks in boolean expressions or in other contexts where functions can be used. I am only suggesting that the severity tasks be allowed to stand as property expressions and to define their values as property expression to be 0 (i.e., false) for $error and $fatal and 1 (i.e., true) for $warning and $info. Best regards, John H. > X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f > X-ExtLoop1: 1 > X-IronPort-AV: i="4.09,400,1157353200"; > d="scan'208,217"; a="142874551:sNHT60973808" > X-MimeOLE: Produced By Microsoft Exchange V6.5 > Content-class: urn:content-classes:message > Date: Wed, 8 Nov 2006 08:59:43 +0200 > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Topic: [sv-ac] new mantis item and proposal #1641 > thread-index: Acb87WQ8gkTbsSwPSLKxbLvj8YDjCgCgB9CiAFNE5cAARGbxnABNyjng > From: "Bresticker, Shalom" <shalom.bresticker@intel.com> > X-OriginalArrivalTime: 08 Nov 2006 06:59:55.0229 (UTC) FILETIME=[7EE858D0:01C70303] > X-Virus-Status: Clean > Sender: owner-sv-ac@eda.org > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C70303.7EB54C1F > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > But then I think they cannot be used as tasks unless you explicitly cast > them to void type. > > =20 > > Shalom > > =20 > > ________________________________ > > From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]=20 > Sent: Monday, November 06, 2006 7:52 PM > To: Bresticker, Shalom; john.havlicek@freescale.com; > sv-ac@server.eda-stds.org > Subject: RE: [sv-ac] new mantis item and proposal #1641 > > =20 > > Yes, that is correct. If we want these tasks to return values, they need > to be converted into System Functions. > > Manisha > > > -----Original Message----- > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] > Sent: Sun 11/5/2006 1:14 AM > To: Kulshrestha, Manisha; john.havlicek@freescale.com; > sv-ac@server.eda-stds.org > Subject: 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=3D[E7668F00:01C6F78F] > > > > This is a multi-part message in MIME format. > > > > ------_=3D_NextPart_001_01C6F78F.E687E95D > > Content-Type: text/plain; > > charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > Hi John, > > > > I also like your last example as that seems to be inline with how =3D > > currently property evaluations happen. The intent of the proposal 1641 > =3D > > is to allow these tasks anywhere including the subroutine calls > attached =3D > > to a sequence but I think the subroutine calls should not change the = > =3D > > overall evaluation of the property. One thing we need to clarify is > that =3D > > an $error call inside a subroutine should print out assertion specific > =3D > > info or it should get treated like any sequential code. The same =3D > > question comes up when there are tasks/function calls inside action = > =3D > > 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 =3D > > $error behave like action block call or sequential code call ? Or it > can =3D > > 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 > > =3D20 > > 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 > =3D > > use > > > it as part of evaluation. Could you please elaborate on this. > > >=3D20 > > > 3. Another topic is the use of severity tasks as subroutine calls > > > attached to sequences. I think we should consider whether=3D3D20 > > > the result of the assertion evaluation should be sensitive > to=3D3D20 > > > something like a $error called as a subroutine attached to=3D3D20 > > > 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=3D20 > > evaluation. > > > > One of the lingering areas of untidiness is error reporting with=3D20 > > 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=3D20 > > 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 |->=3D20 > > 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=3D20 > > $display does not execute. > > > > There are hacks to overcome this difficulty, like > > > > r |->=3D20 > > if (bad_condition) (1, $display(...<local variables>...)) ##0 0 > > else p1 > > > > It might be nicer to be able to write > > > > r |->=3D20 > > 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=3D20 > > write > > > > r |->=3D20 > > if (bad_condition) $error(...<local variables>...) > > else p1 > > > > This last version of the code looks the most intuitive to me. > > > > Best regards, > > > > John H. > > > > > ------_=_NextPart_001_01C70303.7EB54C1F > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > <head> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = > charset=3Dus-ascii"> > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> > <!--[if !mso]> > <style> > v\:* {behavior:url(#default#VML);} > o\:* {behavior:url(#default#VML);} > w\:* {behavior:url(#default#VML);} > .shape {behavior:url(#default#VML);} > </style> > <![endif]--> > <title>RE: [sv-ac] new mantis item and proposal #1641</title> > <o:SmartTagType = > namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" > name=3D"PersonName"/> > <!--[if !mso]> > <style> > st1\:*{behavior:url(#default#ieooui) } > </style> > <![endif]--> > <style> > <!-- > /* Font Definitions */ > @font-face > {font-family:Tahoma; > panose-1:2 11 6 4 3 5 4 4 2 4;} > @font-face > {font-family:TimesNewRoman; > panose-1:0 0 0 0 0 0 0 0 0 0;} > /* Style Definitions */ > p.MsoNormal, li.MsoNormal, div.MsoNormal > {margin:0in; > margin-bottom:.0001pt; > font-size:12.0pt; > font-family:"Times New Roman";} > a:link, span.MsoHyperlink > {color:blue; > text-decoration:underline;} > a:visited, span.MsoHyperlinkFollowed > {color:blue; > text-decoration:underline;} > p > {mso-margin-top-alt:auto; > margin-right:0in; > mso-margin-bottom-alt:auto; > margin-left:0in; > font-size:12.0pt; > font-family:"Times New Roman";} > p.Style2, li.Style2, div.Style2 > {margin:0in; > margin-bottom:.0001pt; > text-autospace:none; > font-size:14.0pt; > font-family:TimesNewRoman; > color:black;} > span.EmailStyle19 > {mso-style-type:personal-reply; > font-family:Arial; > color:blue; > font-weight:normal; > font-style:normal; > text-decoration:none none;} > @page Section1 > {size:8.5in 11.0in; > margin:1.0in 1.25in 1.0in 1.25in;} > div.Section1 > {page:Section1;} > --> > </style> > <!--[if gte mso 9]><xml> > <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> > </xml><![endif]--><!--[if gte mso 9]><xml> > <o:shapelayout v:ext=3D"edit"> > <o:idmap v:ext=3D"edit" data=3D"1" /> > </o:shapelayout></xml><![endif]--> > </head> > > <body lang=3DEN-US link=3Dblue vlink=3Dblue> > > <div class=3DSection1> > > <p class=3DMsoNormal><font size=3D4 color=3Dblue face=3DArial><span = > style=3D'font-size: > 14.0pt;font-family:Arial;color:blue'>But then I think they cannot be = > used as > tasks unless you explicitly cast them to void = > type.<o:p></o:p></span></font></p> > > <p class=3DMsoNormal><font size=3D4 color=3Dblue face=3DArial><span = > style=3D'font-size: > 14.0pt;font-family:Arial;color:blue'><o:p> </o:p></span></font></p> > > <p class=3DMsoNormal><font size=3D4 color=3Dblue face=3DArial><span = > style=3D'font-size: > 14.0pt;font-family:Arial;color:blue'>Shalom<o:p></o:p></span></font></p> > > <p class=3DMsoNormal><font size=3D4 color=3Dblue face=3DArial><span = > style=3D'font-size: > 14.0pt;font-family:Arial;color:blue'><o:p> </o:p></span></font></p> > > <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = > 0in 4.0pt'> > > <div> > > <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font = > size=3D3 > face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> > > <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> > > </span></font></div> > > <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span = > style=3D'font-size:10.0pt; > font-family:Tahoma;font-weight:bold'>From:</span></font></b><font = > size=3D2 > face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> = > Kulshrestha, > Manisha [mailto:Manisha_Kulshrestha@mentor.com] <br> > <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, November = > 06, 2006 > 7:52 PM<br> > <b><span style=3D'font-weight:bold'>To:</span></b> Bresticker, Shalom; = > <st1:PersonName > w:st=3D"on">john.havlicek@freescale.com</st1:PersonName>; = > sv-ac@server.eda-stds.org<br> > <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [sv-ac] new = > mantis > item and proposal #1641</span></font><o:p></o:p></p> > > </div> > > <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = > style=3D'font-size: > 12.0pt'><o:p> </o:p></span></font></p> > > <p style=3D'margin-bottom:12.0pt'><font size=3D2 face=3D"Times New = > Roman"><span > style=3D'font-size:10.0pt'>Yes, that is correct. If we want these tasks = > to return > values, they need to be converted into System Functions.<br> > <br> > Manisha<br> > <br> > <br> > -----Original Message-----<br> > From: Bresticker, Shalom [<a = > href=3D"mailto:shalom.bresticker@intel.com">mailto:shalom.bresticker@inte= > l.com</a>]<br> > Sent: Sun 11/5/2006 1:14 AM<br> > To: Kulshrestha, Manisha; <st1:PersonName = > w:st=3D"on">john.havlicek@freescale.com</st1:PersonName>; > sv-ac@server.eda-stds.org<br> > Subject: RE: [sv-ac] new mantis item and proposal #1641<br> > <br> > Usually tasks do not return values, functions do. Are there = > exceptions<br> > (my memory is a little fuzzy at the moment...)?<br> > <br> > <br> > <br> > Shalom<br> > <br> > <br> > <br> > ________________________________<br> > <br> > From: owner-sv-ac@server.eda.org [<a = > href=3D"mailto:owner-sv-ac@server.eda.org">mailto:owner-sv-ac@server.eda.= > org</a>] > On<br> > Behalf Of Kulshrestha, Manisha<br> > Sent: Friday, November 03, 2006 7:56 PM<br> > To: <st1:PersonName = > w:st=3D"on">john.havlicek@freescale.com</st1:PersonName>; > sv-ac@server.eda-stds.org<br> > Subject: RE: [sv-ac] new mantis item and proposal #1641<br> > <br> > <br> > <br> > Hi,<br> > <br> > <br> > <br> > I agree that we need to clarify that these tasks are allowed = > anywhere<br> > $display is allowed that includes match items. So, now the usage of<br> > these tasks can be devided in two contexts: assertion (that includes<br> > action block of concurrent and immediate assertions, match item and<br> > boolean expression of concurrent and immediate assertions) and<br> > sequential code.<br> > <br> > <br> > <br> > To keep things simple for the users, any direct or indirect call = > from<br> > assertion context should print out assertion specific information.<br> > <br> > <br> > <br> > Here is an example:<br> > <br> > <br> > <br> > task myTask()<br> > <br> > if (cond1)<br> > <br> > $error("failed");<br> > <br> > else<br> > <br> > $error("failed2");<br> > <br> > endtask<br> > <br> > <br> > <br> > assert property (p) else myTask();<br> > <br> > <br> > <br> > always @(posedge clk)<br> > <br> > if (bad_cond)<br> > <br> > myTask();<br> > <br> > <br> > <br> > Here the error printed by myTask() will print assertion information = > when<br> > this task is called from action block. The error printed will print<br> > information as per sequential code rules when called from always = > block.<br> > <br> > <br> > <br> > To be able to use these tasks in boolean expressions, they need to<br> > return values. We can add it in the proposal that these tasks return = > bit<br> > type and the return value is 0 for $error and $fatal and it is 1 for<br> > $warning and $info.<br> > <br> > <br> > <br> > Now, since we are allowing usage of these tasks indirectly in = > assertion<br> > action block (through task/fn calls), how do we determine the = > severity<br> > of the assertions ?<br> > <br> > <br> > <br> > Looks like this issue was discussed in the last meeting and some<br> > questions were raised about usage in boolean expression and match = > items.<br> > If everyone thinks that it is not clear how these will behave in = > match<br> > item and boolean expression, we can update the proposal to make it<br> > illegal in those contexts.<br> > <br> > <br> > <br> > Please send your feedback.<br> > <br> > <br> > <br> > Thanks.<br> > <br> > Manisha<br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > ________________________________<br> > <br> > From: owner-sv-ac@server.eda.org on behalf of John Havlicek<br> > Sent: Tue 10/31/2006 5:05 AM<br> > To: sv-ac@server.eda-stds.org<br> > Subject: Re: [sv-ac] new mantis item and proposal #1641<br> > <br> > Hi Manisha:<br> > <br> > > The intent of the proposal 1641 is to allow these tasks = > anywhere<br> > > including the subroutine calls attached to a sequence but I think = > the<br> > > subroutine calls should not change the overall evaluation of = > the<br> > > property.<br> > <br> > This is fine with me. I have just sent a response to Doug = > Warmke's<br> > mail suggesting that we drop the idea of having severity tasks that<br> > are match items influence the sequence or property evaluation.<br> > <br> > We may need to find a clearer way to say that the severity tasks<br> > are allowed anywhere that other tasks are allowed -- I'm not sure<br> > whether the phrase "sequential code" covers every situation = > that<br> > is intended. E.g., it wasn't clear to me that sequence match = > items<br> > are included under sequential code.<br> > <br> > > One thing we need to clarify is that an $error call inside a<br> > > subroutine should print out assertion specific info or it should = > get<br> > > treated like any sequential code.<br> > <br> > In my mail I suggested that for the case of a unified error<br> > handling subroutine, it will be more useful if the action block<br> > rules for the reporting are used than the sequential code rules.<br> > <br> > This point of view argues for using the action block rules of 1641<br> > whenever the severity task is called directly or indirectly<br> > from an assertion action block or sequence match item.<br> > <br> > On the other hand, I can see the decision of which rule to use<br> > becoming complex. E.g., if the severity task is called after = > some<br> > time delay or after some additional checking of error conditions, = > then<br> > it may be preferable to use the sequential code rules from 1641.<br> > <br> > Another possibility is to give the user a way (similar to %m) to<br> > capture the assertion reporting information that would be printed<br> > according to the action block rule and manage the incorporation of<br> > this information. This new mechanism could be made available = > only<br> > within the action block or in the actual argument expressions to<br> > a sequence match item.<br> > <br> > This new mechanism could allow a simpler rule about what the tool<br> > prints and also provide the user the ability to get all the<br> > information in various more complex cases.<br> > <br> > Best regards,<br> > <br> > John H.<br> > <br> > > X-MimeOLE: Produced By Microsoft Exchange V6.5<br> > > Content-class: urn:content-classes:message<br> > > Date: Tue, 24 Oct 2006 10:14:44 -0700<br> > > X-MS-Has-Attach:<br> > > X-MS-TNEF-Correlator:<br> > > Thread-Topic: [sv-ac] new mantis item and proposal #1641<br> > > Thread-Index: Acb3ZZCRqccrAjllQhq+ddevy/4YswAKHVO/<br> > > From: "Kulshrestha, Manisha" > <Manisha_Kulshrestha@mentor.com><br> > > X-OriginalArrivalTime: 24 Oct 2006 17:14:46.0128 (UTC)<br> > FILETIME=3D[E7668F00:01C6F78F]<br> > ><br> > > This is a multi-part message in MIME format.<br> > ><br> > > ------_=3D_NextPart_001_01C6F78F.E687E95D<br> > > Content-Type: text/plain;<br> > > = > charset=3D"iso-8859-1"<br> > > Content-Transfer-Encoding: quoted-printable<br> > ><br> > > Hi John,<br> > ><br> > > I also like your last example as that seems to be inline with how = > =3D<br> > > currently property evaluations happen. The intent of the proposal = > 1641<br> > =3D<br> > > is to allow these tasks anywhere including the subroutine calls<br> > attached =3D<br> > > to a sequence but I think the subroutine calls should not change = > the =3D<br> > > overall evaluation of the property. One thing we need to clarify = > is<br> > that =3D<br> > > an $error call inside a subroutine should print out assertion = > specific<br> > =3D<br> > > info or it should get treated like any sequential code. The same = > =3D<br> > > question comes up when there are tasks/function calls inside action = > =3D<br> > > block which have these severity tasks in them.<br> > ><br> > > Here are some examples to consider (Probably my syntax is not<br> > correct):<br> > ><br> > > assert property (foo) else myfunc();<br> > ><br> > > function myfunc()<br> > > if (cond)<br> > > $error(..);<br> > > endfunction<br> > ><br> > > Since this function can be called from sequential code also, = > should<br> > the =3D<br> > > $error behave like action block call or sequential code call ? Or = > it<br> > can =3D<br> > > be sensitive to the fact if myfunc was called from assertion ?<br> > ><br> > ><br> > > Thanks.<br> > > Manisha<br> > ><br> > ><br> > > -----Original Message-----<br> > > From: owner-sv-ac@server.eda.org on behalf of John Havlicek<br> > > Sent: Tue 10/24/2006 5:11 AM<br> > > To: sv-ac@server.eda-stds.org<br> > > Subject: Re: [sv-ac] new mantis item and proposal #1641<br> > > =3D20<br> > > Hi Manisha:<br> > ><br> > > > I do not quite understand your point 3. In what situations you = > think<br> > > > someone may call $error as a match item subroutine ? Also, how = > do we<br> > =3D<br> > > use<br> > > > it as part of evaluation. Could you please elaborate on = > this.<br> > > >=3D20<br> > > > 3. Another topic is the use of severity tasks as subroutine = > calls<br> > > > attached to sequences. I think we = > should > consider whether=3D3D20<br> > > > the result of the assertion evaluation = > should be > sensitive<br> > to=3D3D20<br> > > > something like a $error called as a = > subroutine > attached to=3D3D20<br> > > > a sequnce.<br> > ><br> > > My understanding of the current proposal is that the severity = > tasks<br> > > are allowed in sequential code and in assertion action blocks, = > so<br> > > attaching a severity task as a match item is not allowed.<br> > ><br> > > However, I think we should consider whether to allow this and, if = > so,<br> > > whether execution of a severity task should impact the = > assertion=3D20<br> > > evaluation.<br> > ><br> > > One of the lingering areas of untidiness is error reporting = > with=3D20<br> > > local variables. Since the action blocks execute once per = > attempt,<br> > > we have said for a long time that local variables cannot be = > referenced<br> > > in an action block.<br> > ><br> > > Local variables can be passed to subroutines that are match = > items.<br> > ><br> > > However, as we discovered back in the SV 3.1a effort, it can = > be=3D20<br> > > tricky to write a property so that it fails according to the = > semantics<br> > > and so that the subroutine match item also executes. For = > example<br> > ><br> > > r |->=3D20<br> > > if (bad_condition) (0, = > $display(...<local > variables>...))<br> > > else p1<br> > ><br> > > doesn't work. The "0" is intended to cause the = > failure of > the<br> > > property, but the failing of the evaluation of "0" means = > that > the=3D20<br> > > $display does not execute.<br> > ><br> > > There are hacks to overcome this difficulty, like<br> > ><br> > > r |->=3D20<br> > > if (bad_condition) (1, = > $display(...<local > variables>...)) ##0 0<br> > > else p1<br> > ><br> > > It might be nicer to be able to write<br> > ><br> > > r |->=3D20<br> > > if (bad_condition) (1, = > $error(...<local > variables>...))<br> > > else p1<br> > ><br> > > and have the $error cause the property to fail.<br> > ><br> > > Or it might be even better to say that a severity task can = > stand<br> > > as a property with constant truth value -- $fatal and $error = > evaluate<br> > > to false, while $info and $warning evaluate to true. Then = > one<br> > could=3D20<br> > > write<br> > ><br> > > r |->=3D20<br> > > if (bad_condition) = > $error(...<local > variables>...)<br> > > else p1<br> > ><br> > > This last version of the code looks the most intuitive to me.<br> > ><br> > > Best regards,<br> > ><br> > > John H.<br> > <br> > </span></font><o:p></o:p></p> > > </div> > > </div> > > </body> > > </html> > > ------_=_NextPart_001_01C70303.7EB54C1F--Received on Thu Nov 9 10:34:01 2006
This archive was generated by hypermail 2.1.8 : Thu Nov 09 2006 - 10:35:10 PST