Re: [sv-ac] Mantis 3033: Allow procedural control statements is checkers

Dmitry,
Quick questions: *"Unlike modules, interfaces, and programs, checker formal
arguments may not be connected to interfaces. "*
You mean formal arguments cannot be interfaces, however, they can be
connected to interface elements? Is the following legal:
module m;
  x_if x_if1; // some interface instance
  C my_checker(.data(x_if1.data), ...); // LEGAL ??
endmodule

*Checker formal arguments shall not be modified by a checker.*
Sorry, but I am still not clear as to what that really mean. How can inputs
be modified?
You mean by formal? Example;
checker (int data, ..);
   a1: assume property(data <= 16); // so FV can't modify range of values
for data?
endchecker

On Wed, Aug 31, 2011 at 6:21 AM, Korchemny, Dmitry <
dmitry.korchemny@intel.com> wrote:

> Hi all,****
>
> ** **
>
> I uploaded the updated version of Mantis 3033: Allow procedural control
> statements is checkers:
> http://www.eda-stds.org/mantis/file_download.php?file_id=5390&type=bug.
> This version addresses Anupam’s feedback. I added the following sentence:*
> ***
>
> All checker formal arguments are inputs and they are processed in a similar
> way as property formal arguments, but the data types of checker formal
> arguments besides those legal for a property (see 16.13), may also be *string
> *and non-integer types (*shortreal*, *real*, and *realtime*). Unlike
> modules, interfaces, and programs, checker formal arguments may not be
> connected to interfaces. Checker formal arguments shall not be modified by
> a checker.****
>
> ** **
>
> I did not add any clarification to checker variable randomization with
> assumptions, because it is in the LRM already:****
>
> ** **
>
> All non-*const *free checker variables are treated as either active or
> inactive for assume-based****
>
> randomization, in the same way as *rand *variables for class-based
> constrained random generation (see 17.9),****
>
> but without an explicit control facility [such as rand_mode()]. All other
> variables (such as non-free****
>
> checker variables and checker formals) are always treated as inactive. Any
> free checker variables that appear****
>
> on the left-hand side of a checker variable assignment (see 17.7.1) are
> inactive; all other free checker****
>
> variables are active. Free checker variables are active or inactive for
> each singular element of the variable.****
>
> For example, a packed array or structure is active or inactive
> monolithically, whereas the elements of an****
>
> unpacked array or structure are separately active or inactive.****
>
> ** **
>
> 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.