Sometimes even a call to $display could be considered to have a side effect. module test; int ii = 0; initial begin $display("ii=%0d", ++ii); end endmodule Neil On 10/01/09 09:10, Gordon Vreugdenhil wrote: > > 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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Oct 1 18:05:36 2009
This archive was generated by hypermail 2.1.8 : Thu Oct 01 2009 - 18:08:27 PDT