Date: Mon Mar 14 2011 - 14:09:33 PDT
Hello back Manisha,
You are right ( I meant $assertkill(0) ), I always get confused between 1 and 0.
You understand my request correctly. It would be nice if we can discuss it in next sv-ac meeting.
Thanks,
Laurence
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Monday, March 14, 2011 6:41 AM
To: Bisht, Laurence S
Cc: sv-ac@eda.org
Subject: RE: mantis 3295: assertion control tasks
Hi Laurance,
The argument 'levels' helps in handling this case. If the value of levels is '1', it will only affect 'A (it does not affect any of the modules instantiated by A). Similarly if the value is '2', it affects direct instantiations of A but will not affect 'X' as 'X' is one level below the hierarchy. So, the user will have to use different $assertkill commands to selectively kill the assertions in the hierarchy.
Now, are you saying that you are looking for a way to exclude certain modules in the hierarchy in the same command ? If that is the case then this needs to be looked into as we have not discussed this yet.
Manisha
________________________________
From: Bisht, Laurence S [mailto:laurence.s.bisht@intel.com]
Sent: Sunday, March 13, 2011 8:10 PM
To: Kulshrestha, Manisha
Cc: sv-ac@eda.org
Subject: RE: mantis 3295: assertion control tasks
Hello back Manisha,
One useful scenario is to invert the control.
Which means: suppose you have some hierarchy in which at some point you would like to choose some module A, enable all assertions in A and its sub-modules and disable all other assertions in the hierarchy.
Example:
[cid:image001.png@01CBE29B.AE8DADC0]
The request is to be able at some point to kill the properties in A without effect on X, please note that $assertkill(A, 1) will not do the job because it will kill the properties in X, even if you do afterwards $asserton(X).
Do you think that it is possible also to support this kind of control?
Thanks,
Laurence
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Tuesday, March 08, 2011 10:52 AM
To: Bresticker, Shalom; sv-ac@eda.org
Subject: [sv-ac] RE: mantis 3295: assertion control tasks
Hello Shalom,
I have incorporated your comments in the latest proposal uploaded. I have also made all the arguments after first one optional to keep the typing minimal for simple cases. Currently the text does not make it clear that arguments are not constants and they can be variables. Does it need to be stated or it is obvious if there is no restriction specified ?
Thanks.
Manisha
________________________________
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Monday, March 07, 2011 7:18 PM
To: Kulshrestha, Manisha; sv-ac@eda.org
Subject: RE: mantis 3295: assertion control tasks
Hi,
1. The proposal extensively describes argument values in a hex format, as 0x1, etc., with the "0x" prefix. This is not Verilog syntax. There is also no reason that the values need to be in hex format. They do not even need to be constants. They could be variable expressions, and the value used at run-time.
2. The proposal says, "When invoked with no arguments, the system task shall apply to all assertions." The sentence is not new, but now it applies to $assertcontrol. I don't see that a default control type is specified if there are no arguments.
3. "When the task is specified with arguments, the second and third arguments for tasks $assertcontrolon, $assertcontroloff and $assertcontrolkill shall be integer values and valid values for these arguments and their effects are explained in tables 20-6 and 20-7." Tasks of such names are not defined. Shouldn't it be simply "$assertcontrol"?
4. "- $asserton[(levels[, list])] == $assertcontrol[(1, 0x7, 0x7, levels [,list])]
- $assertoff[(levels[, list])] == $assertcontrol[(2, 0x7, 0x7, levels [,list])]
- $assertkill[(levels[, list])] == $assertcontrol[(3, 0x7, 0x7, levels [,list])]"
There should be no square brackets around the $assertcontrol arguments here.
5. In the example at the bottom of page 3, use "logic" instead of "reg". The comment describe time in terms of ns, but the delays do not contain any time unit specification.
Regards,
Shalom
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Monday, March 07, 2011 11:45 AM
To: Kulshrestha, Manisha; sv-ac@eda.org
Subject: [sv-ac] mantis 3295: assertion control tasks
Hi,
I have uploaded a new proposal based on our latest discussion and feedback from sv-bc. I have not incorparated attribute lookup as I found the following in the LRM section 3.13:
h) The attribute name space is enclosed by the (* and *) constructs attached to a language element (see 5.12). An attribute name can be defined and used only in the attribute name space. Any other type of name cannot be defined in this name space.
Based on this, it may not be valid to lookup these attributes at other places in the design.
Thanks.
Manisha
________________________________
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Wednesday, February 23, 2011 5:26 PM
To: sv-ac@eda.org
Subject: [sv-ac] FW: [sv-bc] RE: question about new enum types in standard package
Hi,
Based on the discussion here, looks like defining enums in std package is not going to work (due to name collision and also bitwise ORing may not work). I am planning to keep integer values for now for the arguments.
About the severity discussion yesterday, that is also kind of new thing. Currently LRM only provides a way to define attributes and leaves it to the tools how to interpret them or how to use them. So, I am a bit skeptical about using attributes in one of the arguments. Usually tools can provide this support instead of language providing all the features. What do you think ?
Thanks.
Manisha
________________________________
From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Wednesday, February 23, 2011 2:00 AM
To: Kulshrestha, Manisha
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] RE: question about new enum types in standard package
If I were paid to be a language designer (I'm not), I'd be tempted to suggest keyword type modifiers for enum such as:
onehot enum {RED,YELLOW,GREEN}; // RED=1, YELLOW=2, GREEN=4, only those values are legal
subset enum {dt_assert, dt_cover, dt_assume}; // similar, but all 3-bit values are legal
This last definition by example skirts one other objection to your std enum proposal:
"assert" "cover" and "assume" are already keywords, so they'd be rejected as tags unless you ("\assert ") escape them.
It also suggests more overloadings of the {}s, which are already carrying a lot of syntactic baggage.
OTOH, "Notation is a tool of Thought" (Ken Iverson 1979); you're doing an ordinary programming chore and
the language notation isn't helping much...
Greg Jaxon
On 2/22/2011 1:47 PM, Greg Jaxon wrote:
Also the desire to "bitwise-or" together multiple enum values isn't consistent with strong typing of enum,
even if you've chosen a one-hot encoding for their values. Rather this sounds like a static class
implementing a small finite set.
Greg Jaxon
On 2/22/2011 12:00 PM, Bresticker, Shalom wrote:
It would be better to define a way that will prevent any collisions.
Shalom
-----Original Message-----
From: Gran, Alex [mailto:alex_gran@mentor.com]
Sent: Tuesday, February 22, 2011 7:51 PM
To: Kulshrestha, Manisha; Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org>
Cc: sv-ac@eda.org<mailto:sv-ac@eda.org>
Subject: RE: [sv-bc] RE: question about new enum types in standard
package
Mantis 1820 would help some in preventing name collisions between the
std enums and user design.
http://www.eda-twiki.org/svdb/view.php?id=1820
-----Original Message-----
From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Tuesday, February 22, 2011 9:21 AM
To: Bresticker, Shalom; sv-bc@eda.org<mailto:sv-bc@eda.org>
Cc: sv-ac@eda.org<mailto:sv-ac@eda.org>
Subject: [sv-bc] RE: question about new enum types in standard package
Hi Shalom,
I am not sure if I add these enums to std package, will it preclude
users from using them. we do not want to preclude them that is the
reason we thought about putting them in std package. But I guess, if
std
package is imported, then all the enums will be directly visible and
they will be precluded. Is that right ?
Manisha
-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Tuesday, February 22, 2011 7:44 PM
To: Kulshrestha, Manisha; sv-bc@eda.org<mailto:sv-bc@eda.org>
Cc: sv-ac >> "sv-ac@eda.org"<mailto:sv-ac@eda.org>
Subject: RE: question about new enum types in standard package
Hi,
I looked over the current system task definitions.
I think that today non-numeric arguments are done as strings, such as
"r" or "rb" as file descriptor types in Table 21-7.
Would such enum definitions turn "on", "off", "kill" into keywords or
into predefined enum value names that would preclude users from using
them in their own enum declarations or parameter declarations or signal
names?
Regards,
Shalom
-----Original Message-----
From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Tuesday, February 22, 2011 10:00 AM
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] question about new enum types in standard package
SV-BC,
In sv-ac, we are discussing about adding new system tasks which would
have difference arguments. Here is an example:
$assertcontrol(level, control_type, directive_type, ...);
Here control_type can be either on/off/kill. Similarly directive_type
can be assert, cover or assume. We want to define some enums to
represent these values so that users do not need to pass integer
values. Instead the users can use one of these enums (or even pass OR
of multiple of them).
Is there a precedent for such a thing ? Is standard package defined
in
Annex G right place to insert these new enum types ?
Thanks.
Manisha
---------------------------------------------------------------------
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. --------------------------------------------------------------------- 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<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. --------------------------------------------------------------------- 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.
