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

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Tue Feb 22 2011 - 10:00:17 PST

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 10:01:48 2011

This archive was generated by hypermail 2.1.8 : Tue Feb 22 2011 - 10:01:54 PST