[sv-ac] Re: Checker output arguments so far

Itt is not allowed. Dmitry answered my question on this. It's a proposal
to avoid the lo the declaration of variiables local the the checker, and
then doing a continuous assign to the output.
Ben

On 7/20/10, Prabhakar, Anupam <anupam_prabhakar@mentor.com> wrote:
>
> I need some clarifications here. Is ‘output rand’ allowed in the current
> version of the LRM. If yes can you point me to the section that I can take
> a look. I basically want to understand how the random values will be set -
> like where will the constraints be and who calls randomize().
>
>
>
> Anupam
>
>
>
> *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> *Sent:* Tuesday, July 20, 2010 5:55 AM
>
> *To:* Eduard Cerny; ben@systemverilog.us; Havlicek John-R8AAAU; Bisht,
> Laurence S; Prabhakar, Anupam; thomas.thatcher@Oracle.com
> *Cc:* Kulshrestha, Manisha
> *Subject:* RE: Checker output arguments so far
>
>
>
> Hi Ed,
>
>
>
> Sure, continuous assignments are necessary to allow decent usage of output
> checker arguments, but they are a subject of a separate Mantis item 3034:
> Allow continuous and blocking assignments in checkers.
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> *From:* Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> *Sent:* Tuesday, July 20, 2010 3:50 PM
> *To:* Korchemny, Dmitry; Eduard Cerny; ben@systemverilog.us; Havlicek
> John-R8AAAU; Bisht, Laurence S; Prabhakar, Anupam;
> thomas.thatcher@Oracle.com
> *Cc:* Kulshrestha, Manisha
> *Subject:* RE: Checker output arguments so far
>
>
>
> Hi Dmitry,
>
>
>
> I agree with doing minimal changes first, cont assign I think is necessary.
> Ports are already quite different than anything else…
>
>
>
> best
>
> ed
>
>
>
>
>
> *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> *Sent:* Tuesday, July 20, 2010 2:27 AM
> *To:* Eduard Cerny; ben@systemverilog.us; Havlicek John-R8AAAU; Bisht,
> Laurence S; Prabhakar, Anupam; thomas.thatcher@Oracle.com
> *Cc:* Kulshrestha, Manisha
> *Subject:* RE: Checker output arguments so far
>
>
>
> Hi Ed,
>
>
>
> I think that having shadow variables imposes unnecessary burden both on the
> user and on the simulator. Compare the following implementations:
>
>
>
> checker GenMutex (output rand bit a, b, input event clk = $inferred_clock,
> untyped rst = $inferred_reset);
>
> m1: assume property (@clk disable iff rst $onehot0({a, b});
>
> endchecker
>
>
>
> with
>
>
>
> checker GenMutex (output bit a, b, input event clk = $inferred_clock,
> untyped rst = $inferred_reset);
>
> bit a1, a2;
>
> m1: assume property (@clk disable iff rst $onehot0({a1,
> b1});
>
> assign a = a1;
>
> assign b = b1;
>
> endchecker
>
>
>
> (I assume here that we defined continuous assignments in checkers).
>
>
>
> However, I agree that it is always preferable to introduce a minimal change
> first. Without defining continuous or blocking assignments in checkers it
> leaves us still the following use case:
>
>
>
> - Checkers as building blocks for assertion modeling
>
>
> - No explicit initialization of checker variables (bit variables are
> initialized with 0, logical with X, etc.)
>
>
>
> Therefore we can start with the minimal possible enhancement first.
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> *From:* Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> *Sent:* Monday, July 19, 2010 5:00 PM
> *To:* Korchemny, Dmitry; ben@systemverilog.us; Havlicek John-R8AAAU;
> Bisht, Laurence S; Prabhakar, Anupam; Eduard Cerny;
> thomas.thatcher@Oracle.com
> *Cc:* Kulshrestha, Manisha
> *Subject:* RE: Checker output arguments so far
>
>
>
> Hi Dmitry,
>
>
>
> I am missing something – why do you need output rand? So that you do not
> need cont assigns? I think that it would be cleaner to have the assignment
> and not output rand.
>
>
>
> ed
>
>
>
>
>
> *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> *Sent:* Monday, July 19, 2010 3:33 AM
> *To:* ben@systemverilog.us; Havlicek John-R8AAAU; Bisht, Laurence S;
> Prabhakar, Anupam; Eduard Cerny; thomas.thatcher@Oracle.com
> *Cc:* Kulshrestha, Manisha
> *Subject:* Checker output arguments so far
>
>
>
> Hi all,
>
>
>
> I would like to summarize the status of “Checker output arguments”
> enhancements.
>
>
>
> We identified the following use cases for checker output arguments:
>
> · Returning assertion status to a module
>
> · Checkers as building blocks for assertion modeling
>
> · Checkers as generators
>
>
>
> Elaboration of these use cases leads us to several problems to be
> addressed:
>
> · Checker variable initialization in initial procedures
>
> · Introducing blocking assignment of checker variables
>
> · Relaxing SAR (Single Assignment Rule)
>
> · Simulation/synthesis mismatch when returning assertion status as
> a variable
>
>
>
> When introducing blocking assignments in checkers the following problems
> may require elaboration:
>
> · Checker argument sampling
>
> · Introducing more checker procedures, e.g., always_comb
>
> · Introducing continuous assignments in checker
>
> · Introducing “checker nets”
>
>
>
> Addressing all the problems listed above at once will lead us too far. We
> can narrow our problem and address it directly, while addressing other
> issues separately.
>
>
>
> The following reduced use cases can be addressed by introducing output
> arguments in checkers without having to elaborate anything else:
>
> · Checkers as building blocks for assertion modeling
>
> o No explicit initialization of checker variables (bit variables are
> initialized with 0, logical with X, etc.)
>
> · Checkers as generators
>
> o When the output value is the direct result of constraint resolution
> imposed by assumptions.
>
>
>
> Thus, the reduced proposal for checker output arguments should support:
>
> · Modification of checker declaration syntax by introducing *
> output* and *output rand*.
>
> · Extension of the rewriting algorithm to checker output arguments
> (essentially we don’t have an explicit rewriting algorithm for checkers
> right now, this should be addressed together with Mantis 3117)
>
> · Updating LRM – explanation and examples.
>
>
>
> Checker variable assignment may be treated as a separate task.
>
>
>
> What do you think?
>
>
>
> Thanks,
>
> Dmitry
>
> ---------------------------------------------------------------------
>
> 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.
>
> ---------------------------------------------------------------------
>
> 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.