Re: [sv-ac] My estimation for errata list

Ben Cohen: Here are my estimations
*0002947:* Module variables from within function or task not sampled, LRM
and practice contradictory,
             *Medium, important.*
             * Behavior in checker would be different than behavior in a
module.
             * Behavior is common among most (if not all vendors)
             * Need to clarify this behavior in LRM
             example:
                module m;
                   logic a, b, c, clk;
                   function f; return b==1'b1; endfunction : f
                   ap_p: assert property(@ (posedge clk) a |-> f()); //
variable b is not sampled.
                endmodule : m

*0002891*: 17.3.1 Clarification on procedural concurrent assertions upon
instantiation of checker
               *trivial, *It's a clarification. Low importance.

*0002858*: Clarify the rules for assigning a value to a non-checker variable
from within a checker
               reference email subject: * **Can **checker** assign **value**
 **to** **variable** outside its boundary?* *dec010*
Actually, 17.7.1 states *"It shall be illegal to reference a checker
variable using its hierarchical name in assignments*
This issue should be moved to the allowance of outputs in checkers. Fro
previous email:
"The reason why all checker arguments are input is not the desire to
disallow changing external variables in a checker, but it is a temporary
limitation. The checkers may serve as building blocks for formal
verification, and for this purpose the output checker arguments would be
very useful. For example,

checker check1(bit a, event clk); // Contains assertions
                bit b;
                check2 c(a, b, clk);
                assert property (@clk a |=> b);
endchecker

checker check2(bit a, event clk, output bit b); // Performs modeling
                always @clk
                                b <= a;
endchecker

We didn't allow output arguments in checkers because of the tight time
schedule."
  *Trivial *in that we can cancel this one per 17.7.1. However, we need to
consider the case of outputs in checkers.

*0002825*: 16.16 Disable iff: checkers not included in list of default
extensions
Trivial: clarification

*0002810*: Checker instantiation in an always or initial procedure
*Low*: We're all in agreement of the concept.

*0002754*: P1800-2009 : Can clock change in conditional branch of 'if'
operator
*Low*. We're all in agreement of the concept

0002752: P1800-2009 Checker: Clarification on use of automatic variables in
"blocks"
Medium, May need some discussions, but should go relatively fast.

Ben Cohen

On Sun, Apr 18, 2010 at 6:39 AM, Korchemny, Dmitry <
dmitry.korchemny@intel.com> wrote:

> Hi all,
>
>
>
> Here are my estimations for the errata list assigned to me:
>
> · 3036 Explicitly allow unpacked data types for arguments of
> assertion system functions: *Low*, *Important*
>
> · 2556 Explicit package scope indication is not allowed for
> checkers:* Low*, *Important*
>
> · 2732 Clarify timing diagram in Figure 16-4?Future value change:
> *Trivial*, *Nice*
>
> · 2476 Need clarification about system functions $onehot, etc: *
> Low*, *Nice*
>
> · 1502 Decision point definition: *High*, *Leave*
>
> · 1551 Make disable iff sampled: *Medium*, *Leave*. I think this
> issue should be addressed when discussing checker argument sampling.
>
>
>
> 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.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.