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

We've certainly seen FSMs written with enum-valued states.
I don't know whether they're "trending" or not.
But the 'X initialization aspect does not directly affect synthesis.
It's a matter of concern to simulators, if they are going to
track how the first valid state of the machine emerges.

We don't synthesize implicit initializations at time 0.
Instead we (try to) statically detect uses of uninitialized nets.
Type-safety of enums opens up the possibility of optimizations that re-encode the enum state values.
Some of this is old practice, and some is still blue-sky.
So far the SV language hasn't unlocked any new opportunities here.

On 3/21/2014 2:59 PM, Steven Sharp wrote:
> 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.