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

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.