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

From: Korchemny, Dmitry <dmitry.korchemny@intel.com>
Date: Wed Aug 31 2011 - 10:21:43 PDT

Hi Ben,

Please, see below.

Thanks,
Dmitry

From: ben cohen [mailto:hdlcohen@gmail.com]
Sent: Wednesday, August 31, 2011 17:25
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: 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

[Korchemny, Dmitry] Yes, this should be legal. The statement you cite is copied from LRM 2009.

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
[Korchemny, Dmitry] This issue was raised by Anupam, and here is an example when confusion is possible:

checker (data);
                assign data = '1; // Or any other kind of assignment
endchecker

If we take the text of the LRM formally, it is not written anywhere that this is illegal.

On Wed, Aug 31, 2011 at 6:21 AM, Korchemny, Dmitry <dmitry.korchemny@intel.com<mailto: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.
---------------------------------------------------------------------
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.
Received on Wed Aug 31 10:22:16 2011

This archive was generated by hypermail 2.1.8 : Wed Aug 31 2011 - 10:22:23 PDT