There are two aspects of "side effects". One is "does it change the simulation state". Clearly for $display and $info the calls do not change the sim state. However, there is another aspect to "side effect" that is important for simulation -- can a simulator re-evaluate something at any arbitrary point and be guaranteed that the user can't "observe" that decision. This definitely relates to some of the elaboration "constant expression" rules and to rules for randomization and assertions. This stronger "pure/unobservable" kind of requirement is very important to allow for simulator implementation and optimization decisions. 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 09:12:29 2009
This archive was generated by hypermail 2.1.8 : Thu Oct 01 2009 - 09:13:35 PDT