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

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> 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]
> *Sent:* Thursday, October 01, 2009 2:53 AM
> *To:* Korchemny, Dmitry
> *Cc:* ben@systemverilog.us; 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
>
>
>
> 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> 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] *On
> Behalf Of *ben cohen
> *Sent:* Wednesday, September 30, 2009 7:27 PM
> *To:* 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, and is
believed to be clean.