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

Dmitry,Thanks.  The simulator I used must have then adopted the SV'10 use of
$info because that model ($info in a function) ran OK.
And that was without any SV'10 flags.  Of course, that could have been a bug
that is no longer a bug in SV'10.
On the $display, that would be one of those ambiguous thing.
I suggest that we need to write a mantis that states something like the
following.  I don't know if this is true, but Mantises may be used by tool
vendors as justification for implementing certain features, as they clarify
issues (such as Mantis 0002891).
Suggested Mantis:
"A checker can include a $display wherever it is normally allowed to provide
textual information about values of the design.
Users may also use the severity system tasks (e.g., $info) instead of the
$display".
Let me know if you want me to do that.
Ben



On Thu, Oct 1, 2009 at 8:10 AM, Korchemny, Dmitry <
dmitry.korchemny@intel.com> wrote:

>  Hi Ben,
>
>
>
> I cannot say for sure whether it is a violation of the LRM, as there is no
> exact definition (at least I could not find it). I don’t see a difference
> between $display and $info, as both of them print a message. In regular
> functions it is legal to use $info now, but for SV05 $info was defined for
> assertions only.
>
>
>
> Regards,
>
> Dmitry
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Thursday, October 01, 2009 4:56 PM
> *To:* Korchemny, Dmitry
> *Cc:* Srinivasan Venkataramanan; sv-ac@server.eda.org; Seligman, Erik;
> sv-bc@server.eda.org
>
> *Subject:* 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.
>
>
>
> ---------------------------------------------------------------------
> 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.