RE: [sv-bc] enumerated variable used with an equality operator

Your mention of synthesis makes me curious.

One of the reasons for the "schizophrenia" that Gord mentioned is that there are at least two different general uses for enums, which may have different requirements.  There is the software-like use in testbenches, where strong typing is more likely to be desired.  And there is the hardware-like use in designs, for things like state machine states, where overly strong typing is inconvenient.

I originally assumed that the hardware-like uses would be common.  I proposed the initialization of 4-state enums to X for this reason, because initializing state machine states to known values would not correctly model hardware initialization.  This could have led to faulty hardware.  But when I saw very little of this in user designs, I started thinking that I had been wrong about this.

Now I am curious whether you have started seeing more enums used in synthesizable code.  Were they just slower to be adopted by users in synthesizeable code (perhaps due to limited tool support as well as conservativism), but are finally becoming more common?  Or are you just speaking theoretically about what would be possible if users actually did start using them this way?


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon
Sent: Friday, March 21, 2014 3:18 PM
To: SV_BC List
Subject: Re: [sv-bc] enumerated variable used with an equality operator

Compile time static checks can never be as comprehensive as simulation time assertion checks.
The point of strong typing rules is to move the trivial checks as early as possible in the flow - just for convenience.
If simulators would commit to treating enum variables as having implicit (deferred immediate) assertions
that their values stay in the labelled set, then synthesis engines would be safe in relying on those
constraints when simplifying logic, and formal verifiers would be justified in treating out-of-enum-set
input values as dont-care.


On 3/21/2014 2:07 PM, Steven Sharp wrote:
> There are more than these two ways that an enum can get an invalid value.
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Arturo
> Salz
> Sent: Friday, March 21, 2014 10:54 AM
> To: Graham, Paul; sv-bc@eda.org
> Subject: RE: [sv-bc] enumerated variable used with an equality operator
>
> But, all the strong type checking of enumerated values went out the door
> the moment we enabled two things: static casting of arbitrary values
> outside the enumeration range, and initialization of 4-state enumerations
> to 'X, even when that is not an enumeration member.
> I am sympathetic to the stronger checks, but unless we address the above
> two issues, enumerations are cannot be assumed safe.
>
> 	Arturo
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Graham, Paul
> Sent: Friday, March 21, 2014 7:04 AM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] enumerated variable used with an equality operator
>
> Hear, hear!  It is strange to have strict type checking rules just for
> some types, namely enums and unpacked types (I'm thinking only about
> synthesizable types).  Suppose I want an integer type to be type-checked?
> I need to hack it up by declaring it as an enum:
>
>     typedef enum integer {zero, one, two, three, ..., int_max}
> typed_integer;
>
> Or I might be using an enum type just as a quick way to define some named
> values, instead of using a sequence of `defines.  Maybe I don't want all
> the strict type checking baggage on my named integral constants.
>
> Shouldn't type checking be orthogonal to type implementation?  Why not
> have a type attribute, similar to "packed" or "signed", which says that
> this type is not to be mixed with any other type:
>
>     typedef integer typechecked typed_integer;
>
> Now a variable of type typed_integer can't be assigned with or compared to
> a variable of any other type.
>
> Paul
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Vreugdenhil, Gordon
> Sent: Friday, March 21, 2014 9:52 AM
> To: Bresticker, Shalom; Rich, Dave; Neil Korpusik; sv-bc@eda.org
> Subject: Re: [sv-bc] enumerated variable used with an equality operator
>
> I would be Ok with the more lenient interpretation, but I also think it
> would be valid to conclude that relational of a non-enum integral with a
> enum is Ok (ie. does a coercion), but enum-enum relational is not.  
> Given the "stronger" intent of enums, that might be appropriate.   
> Allowing cross-enum behavior everywhere except assignment seems to be
> giving up most of the benefits of a "strong" type so perhaps we should
> just treat then as labelled values of the basetype and forget about the
> stronger type rules completely.
>
> Gord
>
>
>
> On 3/21/2014 2:00 AM, Bresticker, Shalom wrote:
>> If you want this to be illegal, then you would need to define clearly
> and usefully where and how you can use an enum value. It might be too
> difficult and limited to be worthwhile.
>> I agree with Brad. The reference to Mantis 4708 is appropriate. The
> mention of relational operators in the quoted sentence in the LRM is not
> appropriate.
>> In the sentence, "Enumerated variables are type-checked in assignments,
> arguments, and relational operators," if we ignore the mention of
> relational operators, then the type checking refers to the case where an
> enumerated variable is assigned, i.e., on the LHS of an assignment, or as
> the actual argument for an output argument or the formal argument for an
> input argument.
>> Shalom
>>
>>> -----Original Message-----
>>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>>> Rich, Dave
>>> Sent: Friday, March 21, 2014 02:37
>>> To: Neil Korpusik; sv-bc@eda.org
>>> Subject: RE: [sv-bc] enumerated variable used with an equality 
>>> operator
>>>
>>> It should be illegal, but it isn't
>>>
>>> The LRM says:
>>>
>>> Enumerated variables are type-checked in assignments, arguments, and 
>>> relational operators. Enumerated variables are auto-cast into 
>>> integral values, but assignment of arbitrary expressions to an 
>>> enumerated variable requires an explicit cast.
>>>
>>> The LRM does not explain what "type-checked" means, but I take it to 
>>> mean if it can proceed to auto-cast it to an integral expression, it 
>>> will.
>>>
>>> -----Original Message-----
>>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>>> Neil Korpusik
>>> Sent: Thursday, March 20, 2014 5:25 PM
>>> To: sv-bc@eda.org
>>> Subject: [sv-bc] enumerated variable used with an equality operator
>>>
>>> Is the following legal? Should it be?
>>>
>>> Neil
>>>
>>>
>>>
>>> module top();
>>>
>>> typedef enum {A,B,C,D} f_t;
>>> typedef enum {X,Y,Z  } b_t;
>>>
>>> initial begin
>>>     f_t f;
>>>     b_t b;
>>>
>>>     f = A;
>>>     if (f == X) $display("matched");   // legal?
>>> end
>>> endmodule
>> ---------------------------------------------------------------------
>> 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.
>
>



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


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