Re: [sv-bc] Re: [sv-ac] checker: Clarification on functions & side effects

From: ben cohen <hdlcohen_at_.....>
Date: Fri Oct 02 2009 - 08:57:26 PDT
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