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 Wed Nov 8 04:38:29 2006
This archive was generated by hypermail 2.1.8 : Wed Nov 08 2006 - 04:38:41 PST