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

I would like to add some observations from the perspective of a design
engineer who also does verification, SV trainer and consultant.

Many companies have been using enumerated types for design and synthesis
since the Accellera 3.x versions of SystemVerilog -- which is more than 10
years ago.  

The stronger type checking of assignments to enumerated variables is highly
desirable and is expected by design engineers.  The paper Don Mills and I
presented at DVCon shows an example of a state machine modeled using
traditional Verilog-2001 with seven bugs that compile and elaborate, and
must be detected and debugged in simulation.  The enumerated type rules turn
all 7 bugs into syntax errors.  All major simulators and synthesis compilers
flag these errors, as they should.  In the past couple of years, a high
percentage of my training has been to engineers transitioning from VHDL to
SystemVerilog.  They are thrilled with the stronger typing of enumerated
variables.

Having a 4-state enumerated types default to an uninitialized value of X is
both consistent with other SV 4-state types and desirable for RTL models.
As with all 4-state types, X can be an important indication that reset or
some other form of initialization has not taken place in that portion of the
RTL circuit.  Starting time 0 with an X can also critical for preventing
combinational logic blocks from locking up if always_comb is not used (and
possibly even if it is used).

What does catch some engineers by surprise is that operations involving
enumerated labels are loosely typed.  Every engineer I have discussed this
with in training classes quickly decides that the language rules are
correct, and operations involving enumerated  labels should be loosely
typed, just like operations involving any other constant.  

I would be vehemently opposed if the current rules regarding enumerated
types were relaxed or changed in anyway, and I think most design engineers
would agree.  The one exception is to fix the errata in the LRM Shalom noted
in this e-mail thread that says the strong type checking applies to
relational operators on enumerated labels.  This errata is something I
discussed with Shalom last year, and I thought he had filed a Mantis item
about it.  All simulators and synthesis compilers I have checked ignore that
errata.

Stu
~~~~~~~~~~~~~~~~~~~~ 
Stuart Sutherland
Sutherland HDL, Inc.
+1-503-692-0898

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven
Sharp
Sent: Friday, March 21, 2014 1:00 PM
To: Greg Jaxon; SV_BC List
Subject: 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.



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