Re: [sv-bc] RE: question about new enum types in standard package

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Tue Feb 22 2011 - 12:29:36 PST

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
Cc: 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.org/svdb/view.php?id=1820





-----Original Message-----
From: 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
Cc: 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
Cc: sv-ac >> "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] On Behalf Of
Kulshrestha, Manisha
Sent: Tuesday, February 22, 2011 10:00 AM
To: 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, and is
believed to be clean. Received on Tue Feb 22 12:30:11 2011