Gordon, My error on the $info. SystemVerilog is very loose on things like that -- perhaps a dream for the tinkering programmer! Apologies, Ben On Thu, Oct 1, 2009 at 7:58 PM, Vreugdenhil, Gordon < gordon_vreugdenhil@mentor.com> wrote: > Ben, > > I am curious as to whether there is a basis for your implied claim that > $info is more side-effect free than $display. Is there a basis for that? > > There really is no "out of lrm" way of deciding things. Even during the > process decisions can and have changed. So only final approved specs are > really "reliable". > > Srini, > > Note that I have no inherent reason for disallowing either, but **from the > lrm** there is no strong basis either way. On that basis it seems unwise to > write code that relies on either approach if the code is expected to be > valid for a long time. > > Gordon=========== > Gord Vreugdenhil > gordonv@model.com > > On Oct 1, 2009, at 9:47 PM, "ben cohen" <hdlcohen@gmail.com> wrote: > > 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> > 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> >> 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> >>>> dmitry.korchemny@intel.com <mailto: <dmitry.korchemny@intel.com> >>>> 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> >>>> svenka3@gmail.com >>>> <mailto: <svenka3@gmail.com>svenka3@gmail.com>] >>>> *Sent:* Thursday, October 01, 2009 2:53 AM >>>> *To:* Korchemny, Dmitry >>>> *Cc:* <ben@systemverilog.us>ben@systemverilog.us <mailto:<ben@systemverilog.us> >>>> ben@systemverilog.us>; >>>> <sv-ac@server.eda.org>sv-ac@server.eda.org <mailto:<sv-ac@server.eda.org> >>>> 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 >>>> >>>> <http://www.cvcblr.com>www.cvcblr.com < <http://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>dmitry.korchemny@intel.com <mailto:<dmitry.korchemny@intel.com> >>>> 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>owner-sv-ac@server.eda.org >>>> <mailto: <owner-sv-ac@server.eda.org>owner-sv-ac@server.eda.org> >>>> [mailto: <owner-sv-ac@server.eda.org>owner-sv-ac@server.eda.org >>>> <mailto: <owner-sv-ac@server.eda.org>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>sv-ac@server.eda.org <mailto:<sv-ac@server.eda.org> >>>> 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/> >>>> 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/> >>>> 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/> >>>> http://www.mailscanner.info/>, and is >>>> believed to be clean. >>>> >>> >>> -- >>> -------------------------------------------------------------------- >>> Gordon Vreugdenhil 503-685-0808 >>> Model Technology (Mentor Graphics) <gordonv@model.com> >>> 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 20:08:31 2009
This archive was generated by hypermail 2.1.8 : Thu Oct 01 2009 - 20:08:57 PDT