RE: [sv-ac] Definition of $assertoff(0) // needs clarification?

Hi,

After reading the discussion in the Verification Guild, I understand the issue.

21.7.1.2 says, "Setting the first argument to 0 causes a dump of all variables in the specified module and in all module instances below the specified module."

That can be read to imply that a module must be specified with a 0 value for levels, or at least that 0 will not have an effect if a module is not specified.

If someone has actually understood the LRM that way, then the LRM should be rewritten to remove the ambiguity.

Shalom


From: Ben Cohen [mailto:hdlcohen@gmail.com]
Sent: Monday, November 05, 2012 15:02
To: Bresticker, Shalom
Cc: sv-ac@eda-stds.org; Korchemny, Dmitry; Eduard Cerny
Subject: Re: [sv-ac] Definition of $assertoff(0) // needs clarification?

Shalom,
I agree with you.  From the link on the discussion of this issue, one vendor misinterpreted. The vendor's documention, which is NOT the lrm states something like, "In the section "Assertion Control System Tasks" where it defines level it (the vendors documentation) says: "Note: The 0 value can be used only if subsequent arguments specify module instances"
So, this is vendor's imposed self restriction that is non-LRM compliant.
Thanks for addressing this.
Ben
On Sun, Nov 4, 2012 at 11:29 PM, Bresticker, Shalom <shalom.bresticker@intel.com<mailto:shalom.bresticker@intel.com>> wrote:
Ben,

The LRM says,

" - levels: This argument specifies the levels of hierarchy, consistent with the corresponding argument
to the $dumpvars system task (see 21.7.1.2). If this argument is not specified, it defaults to 0.
This argument shall be an integer expression."

21.7.1.2 says,

"Setting the first argument to 0 causes a dump of all variables in the specified module and in all module
instances below the specified module."

Am I missing something?

Thanks,
Shalom

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of Ben Cohen
Sent: Monday, November 05, 2012 07:52
To: sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>; Korchemny, Dmitry; Eduard Cerny
Subject: [sv-ac] Definition of $assertoff(0) // needs clarification?

Maybe we need to address this at the next version? This is related to section
20.12 Assertion control system tasks in 1800-2912
 From the post:
"I, too, am starting to believe given the fact $assertoff(0) is not quite clearly defined in the LRM, that it is eventually left to interpretation, and EDA vendors will go on to implement the feature in anyway that they want.

However, it still bodes well intuitiveness should play a role, what I mean is a number "1" for the level (whether it is $dumpvars or $asserton/$assertoff) will imply that module only, whereas a number "0" will imply that module and everything under it... "
Subject: Topic Reply Notification - what is the definition of $assertoff(0)?

http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=20756#20756

--
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.

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