Gordon, There is value in the *KISS* (*Keep It Simple* and *Straightforward*) Principles (used the sanitized definition here :) ). *<** is it legal for a simulator to avoid evaluating an assertion at a point at which an evaluation would normally be activated? > * I don't know - that needs discussions. The best guidelines is most likely to just keep it simple. In checkers, using the KISS principles, the best guidelines are to not allow side effects in functions and in action blocks. Functions can only return values and be used on the RHS of any assignment, and $display, $info, ... in functions can only be used to report messages and values of variables. Similarly, action blocks in checkers should only be used to report messages or values of variables. Basically, anything that is passive, and is not involved with or affect the timing machinery of the simulator is OK. Ben Cohen ben@SystemVerilog.us On Fri, Oct 2, 2009 at 9:12 AM, Vreugdenhil, Gordon < gordon_vreugdenhil@mentor.com> wrote: > Ben, based on your definition, is it legal for a simulator to avoid > evaluating an assertion at a point at which an evaluation would normally be > activated? Doing so would be legal of there are no "observable" effects but > while output doesn't change the sim state, it can be seen. Additionally, > theoretically one could see sim state effects with apropriate use of stream > redirection and other file io operations. If we're going to try to more > formally open this up, I do want to be careful how the precedent is set > since a closely related aspect is systf use in constant functions and I'd be > very worried about opening that up. > > Gordon=========== > Gord Vreugdenhil > gordonv@model.com > > On Oct 2, 2009, at 10:57 AM, "ben cohen" <hdlcohen@gmail.com> wrote: > > Erik, Below are my comments + example of a clarification + a new question > on side effects > -- > Having dealt with the IEEE on permissions, it is a very simple process to > obtain permission and should be no issue. > We basically have to ask permission to reprint a very small portion (<0.1%) > of the IEEE 1800 draft document for the purpose of clarification. Link: <http://ieee.org/web/publications/rights/index.html> > http://ieee.org/web/publications/rights/index.html > <http://ieee.org/web/publications/rights/index.html>In the document, > there will be something like this in the front page: > *(Indicate material) reprinted with permission from IEEE Std. [number and > year of publication of standard]*, IEEE P1800/D9-prelim Standard for > SystemVerilog Unified Hardware Design,Specification, and Verification > Language, Copyright [year]*, by IEEE. The IEEE disclaims any responsibility > or liability resulting from the placement and use in the described manner. > * > Also, the copyrighted work (the quotes) can be identified with something > like > [IEEE 1800] quote ... > > Jonathan addressed an "Interpretations" document. That is a good idea, > What are the politics involved in this? > On who should maintain this, I suggest Stuart Sutherland since he is > maintaining the IEEE 1800 document. > We would ask Stuart to add what we agree upon in this one > document, published as PDF. The entries will be > in section order (i.e., 16.2 before 16.7, ... before 17.5..). > > Steven also makes a good point on having a question directed up through > DASC might be useful to establish where the > boundaries are. > Below is my input on functions, side effects, and the $display -- more > controversies... > *[IEEE 1800] 17.8 Functions in checkers: Functions shall be automatic (or > preserve no state information) and have no side effects* > *CLARIFICATION: A side effect of a function is an action that can > change the simulation state. Thus, a function is considered side effect > free if 1) it does not make an assignment to a non-local variable, and 2) > the re-evaluation of the function at any arbitrary point* > always returns the same value. For example: > checker c(logic a, b); > int w=0; > function int f(int a); > int b; > b=a+1; // legal, assignment to local variable > w++; // Illegal, assignment to a non-local variable > return b; > > *Is $display is a side effect?* A $display that does not affect the state > of the simulator is a system function without side effect. > A call to $display could be considered to have > a side effect. For example: > module test; > int ii = 0; > initial begin > $display("ii=%0d", ++ii); // The +ii is a side effect. > end > endmodule > Thus, if the $display call does not change the simulator, it is considered > side effect free. > > *Can severity level system functions have side effects in a checker?* Specifically, > an action block can have side effects. > Is this legal in a checker? For example: > checker c(...); > logic a; > ap_P: assert property(...) else a<= 1'b1; // Is " a <= 1'b1" a side > effect? > *[IEEE 1800] 17.7.1 Checker variable assignments: Single Assignment Rule > (SAR): it shall be illegal to use the same bit of a checker variable in > several assignment-like contexts * > One possible answer: NO, because of 17.7.1 > Another possible answer: Yes, as long as the SAR rule is not violated. > Ben Cohen > > *"an assignment of a variable (free variable of the checker or a module).* > *A function can (in a checker) only return a value. * > > > > On Fri, Oct 2, 2009 at 6:57 AM, Seligman, Erik < <erik.seligman@intel.com> > erik.seligman@intel.com> wrote: > >> Ben brings up an important point here—as we have seen in his many >> emails, the current LRM leaves some ambiguities, and areas that probably >> need more explanation than is directly in the LRM. >> >> The official way to record these issues is with the Mantis system; but >> IMHO, a database search is kind of a clunky mechanism for these kinds of >> clarifications. >> >> >> >> Is there any objection to us creating a public SV errata/commentary wiki, >> where we could organize these things in a quickly acceesible way? Such a >> page would be unofficial, but might be quite useful. (I’d prefer to make >> such a page public rather than requiring users to signup & login, to >> maximize it’s usefulness, but am wondering if there are legal complications >> due to the fact that the IEEE std is proprietary.) >> >> >> ------------------------------ >> >> * 3) Given that the LRM is pretty much fixed, is there a mechanism to >> clarify issues such as this? Perhaps mantises? * >> >> >> > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 2 11:16:42 2009
This archive was generated by hypermail 2.1.8 : Fri Oct 02 2009 - 11:19:29 PDT