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>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>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 08:59:11 2009
This archive was generated by hypermail 2.1.8 : Fri Oct 02 2009 - 09:00:26 PDT