3 items: 1) If in the checker we use $info instead of $display, that would comply with the LRM. Wouldn't that be an option around this issue? 2) Dmitry wrote "I cannot say for sure whether it is a violation of the LRM, as there is no exact definition (at least I could not find it). I don’t see a difference between $display and $info, as both of them print a message. In regular functions it is legal to use $info now, but for SV05 $info was defined for assertions only." There seem to be from this particular thread that a side effect is something that modifies the values of variables. However, because there is ambiguity over what is a side effect, I believe that a vendor can get away form being sited for violating the LRM, particularly if the $display is used simply to display text and variable values, without modifying variables of the checker or variables of the design. 3) Given that the LRM is pretty much fixed, is there a mechanism to clarify issues such as this? Perhaps mantises? Ben Cohen On Thu, Oct 1, 2009 at 7:02 PM, Srinivasan Venkataramanan <svenka3@gmail.com > wrote: > Hi Gord, Thanks for your detailed insight into the potential impact of > such usage models. I do appreciate that EDA vendors need to worry about all > possible use models before accepting a clause for the benefit of end users > (eventually). However if we do not allow simple $display usage, it becomes > extremely hard to use/deploy/develop code based on such features. Especially > I have great interest in the checker..endchecker as IMHO it can > significantly impact the ABV usage in the industry. For instance the whole > OVL can now be coded using checker..endchecker (barring tool availability in > short term). But any code is as good as how well it can be debugged, and we > as HW designers/verificaiton engineers rely heavily on $display. So > preventing them for some corner case use models (such as i++, ++i within > $display itself) is a significant step back holding its effective usage - we > already heard that from Abhishek whom I personally know has been developing > code on checker..endchecker for more than 6 months now. > > So please have a re-think on this restriction - common usage should be > allowed to benefit the new feature deployment, maybe with restrictions. > Atleast let's not call a tool non-LRM compliant if it already supports > $display inside checker..endchecker. > > Thanks > Srini > > On Thu, Oct 1, 2009 at 9:40 PM, Gordon Vreugdenhil <gordonv@model.com>wrote: > >> >> >> I agree that the LRM hasn't really been careful enough about >> all of the implications of this difference and should be >> in the future. At this point, I would not consider allowing >> or disallowing such $display or $info calls to be something >> that one could say is definitely legal or illegal. If you >> care about long-term compliance of specific code, I would >> avoid using such routines. >> >> Gord. >> >> ben cohen wrote: >> >>> Dmitry, <calling $display is a side effect, and therefore $display cannot >>> appear in this context in checkers> >>> 1) Since the LRM is not specific on this, in that it does not >>> specifically exclude the $display, particularly for simple stuff, if a >>> vendor implements the $displays in the simulator, *would that be a violation >>> of the LRM*? 2) Couldn't $info be used instead? If $info works, so should >>> $display >>> I tried the following code in a simulator that runs SV05, and it worked >>> OK. function logic t; $info("test i=%b", i); return 1; endfunction : t 3) >>> On the next version of the LRM, we definitely need a dictionary for the >>> definition of terms. Thanks, Ben >>> On Thu, Oct 1, 2009 at 6:40 AM, Korchemny, Dmitry < >>> dmitry.korchemny@intel.com <mailto:dmitry.korchemny@intel.com>> wrote: >>> >>> Hi Srini, >>> >>> >>> We are talking about functions called in the RHS in the checker >>> variable assignment. Obviously a void function cannot appear there >>> directly, and we can talk only about the case when this void >>> function is called from another function entering the RHS of the >>> checker variable assignment. >>> >>> >>> The problem here is that though the term “side effect” is used in >>> the LRM several times, there is no exact definition of this term. >>> According to my understanding, calling $display is a side effect, >>> and therefore $display cannot appear in this context in checkers. I >>> agree that conventional usage of $display in checkers would not harm >>> (unless you use auto-increment operations there, etc.), but this >>> needs refinement of the “side effect” term. I believe that this >>> activity belongs to SV-BC. >>> >>> >>> I definitely agree with the benefit of direct usage of procedural >>> control statements in checkers, and we can elaborate this issue if >>> it becomes part of the next PAR. >>> >>> >>> Regards, >>> >>> Dmitry >>> >>> >>> *From:* Srinivasan Venkataramanan [mailto:svenka3@gmail.com >>> <mailto:svenka3@gmail.com>] >>> *Sent:* Thursday, October 01, 2009 2:53 AM >>> *To:* Korchemny, Dmitry >>> *Cc:* ben@systemverilog.us <mailto:ben@systemverilog.us>; >>> sv-ac@server.eda.org <mailto:sv-ac@server.eda.org>; Seligman, Erik >>> *Subject:* Re: [sv-ac] checker: Clarification on functions & side >>> effects >>> >>> >>> Dmitry, >>> >>> Can you please explain why you believe a simple VOID function is >>> illegal/meaningless in checker? Especially referring to an earlier >>> issue raised by Ben/Abhishek on $display, I can think of >>> "debug-only" functions being used in checker, a skeleton code below, >>> simply added a "display function" that may potentially be reused for >>> few cases. One may find WA by putting $display inline etc. but my >>> point is why exclude a void function that someone may find it useful >>> later on? >>> >>> >>> I also have questions on if.else, case usage in checker, will raise >>> it little later - once this LRM work is done from SV-AC side. I >>> understand the rationale of preventing them as of today is from its >>> origin in Formal World, but now that it is becoming lot more widely >>> accessible, it may be good to relook at the target usage. >>> >>> >>> Thanks >>> >>> Srini >>> >>> www.cvcblr.com <http://www.cvcblr.com> >>> >>> >>> function bit next_window (bit win);c >>> >>> if (reset || win && end_flag == 1'b1) >>> >>> return 1'b0; >>> >>> if (!win && start_flag == 1'b1) >>> >>> return 1'b1; >>> >>> >>> // DEBUG code >>> >>> dbg_it(); >>> >>> return win; >>> >>> endfunction >>> >>> >>> function void dbg_it(); >>> >>> // Can generalize it some extent by passing a large array, number >>> of inputs etc. >>> >>> $display ("reset %0b end_flag %0b win %0b", >>> reset, end_flag, win); >>> >>> endfunction : dbg_it >>> >>> >>> always @(clock) >>> >>> window <= next_window(window); >>> >>> >>> >>> >>> On Thu, Oct 1, 2009 at 1:10 AM, Korchemny, Dmitry >>> <dmitry.korchemny@intel.com <mailto:dmitry.korchemny@intel.com>> >>> wrote: >>> >>> Hi Ben, >>> >>> >>> Yes, assignment of a variable that does not belong to the function >>> (i.e., neither its local variable, no argument) is illegal. But if a >>> is a local variable in the function then a++ is legal. >>> >>> >>> It also turns out that void functions are illegal (or at least, >>> meaningless) in checkers. >>> >>> >>> Regards, >>> >>> Dmitry >>> >>> >>> *From:* owner-sv-ac@server.eda.org >>> <mailto:owner-sv-ac@server.eda.org> >>> [mailto:owner-sv-ac@server.eda.org >>> <mailto:owner-sv-ac@server.eda.org>] *On Behalf Of *ben cohen >>> *Sent:* Wednesday, September 30, 2009 7:27 PM >>> *To:* sv-ac@server.eda.org <mailto:sv-ac@server.eda.org>; Seligman, >>> Erik >>> *Subject:* [sv-ac] checker: Clarification on functions & side effects >>> >>> >>> LRM states that >>> *Functions shall be automatic (or preserve no state information) and >>> have no side effects, * >>> >>> >>> *_1) What is a side effect?_* To me a side effect is an assignment >>> of a variable (free variable of the checker or a module). >>> >>> A function can (in a checker) only return a value. Thus the >>> following is illegal: >>> *checker t_chk(...); * >>> >>> * logic a, x, y;* >>> >>> * function void inc_a; * >>> >>> * a ++; // same as a=a+1 // illegal blocking assignment? * >>> >>> * // a <= a+1; // Illegal also, cannot change value of a >>> variable* >>> >>> * endfunction : a_to_1* >>> >>> * ap_test: assert property(@ (posedge clk) (x, inc_a()) |-> y) ;* >>> >>> *endchecker : t_chk* >>> >>> -- >>> *_2) Can _**_functions be of type void in a checker? _* >>> >>> Since a void function must have a side effect, such as assigning >>> a value to a variable, I believe that they are illegal. >>> Function with return type of void cannot be used in/as an expression. >>> >>> >>> >>> * * >>> >>> >>> >>> -- This message has been scanned for viruses and >>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>> and is >>> believed to be clean. >>> >>> --------------------------------------------------------------------- >>> >>> Intel Israel (74) Limited >>> >>> >>> This e-mail and any attachments may contain confidential material for >>> >>> the sole use of the intended recipient(s). Any review or distribution >>> >>> by others is strictly prohibited. If you are not the intended >>> >>> recipient, please contact the sender and delete all copies. >>> >>> >>> -- This message has been scanned for viruses and >>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>> and is >>> believed to be clean. >>> >>> >>> --------------------------------------------------------------------- >>> Intel Israel (74) Limited >>> >>> This e-mail and any attachments may contain confidential material for >>> the sole use of the intended recipient(s). Any review or distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and >>> is >>> believed to be clean. >>> >> >> -- >> -------------------------------------------------------------------- >> Gordon Vreugdenhil 503-685-0808 >> Model Technology (Mentor Graphics) gordonv@model.com >> >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Oct 1 19:54:54 2009
This archive was generated by hypermail 2.1.8 : Thu Oct 01 2009 - 19:57:42 PDT