Subject: Re: Enumerated Types Proposals
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Mon Apr 08 2002 - 13:46:47 PDT
Declaring the enum to be a specific data type is a simple way to solve the
2-state vs. 4-state issue. I like it. However, it also opens a door we
may, or may not, want open. Does this mean we should allow enumerated real
types? Should we allow signed logic and unsigned int enumerated
types? What about enumerated packed arrays? I don't know if/where the
line should be drawn on allowing typed enumerated types.
Would it solve the X and one-hot encoding requirements if the rule were simply:
- An enumerated type without a size is of type int (2-state)
- An enumerated type with a vector width is of type logic (4-state)
Stu
At 12:39 PM 4/8/2002, Clifford E. Cummings wrote:
>Peter -
>
>I really like the enum [data_type] proposal but would like to suggest one
>small change. I don't want to be required to make the explicit logic
>declaration when the context is clearly 4-state.
>
>Proposed wording?
>In the absence of a data type declaration and if no values are assigned,
>the default data type shall be int. If only binary values are assigned to
>the enum names, the default data type shall be int, If no data type is
>assigned and the enumerated names have assigned values that include x's
>and z's, the default data type shall be logic. This means that an
>enumeration that defaults to a data type of int because the enum names
>were either unassigned or were originally assigned binary values will
>default to a data type of logic, after the design is recompiled, if
>x-assignments or z-assignments are added to the enumeration when the
>design file is modified. Any other data type requires an explicit data
>type declaration.
>
>We still need to comment on what should happen if an unassigned enum name
>follows an enum name with x or z assignments. Is this a syntax error or do
>names S1 and S2 take on consistent defined values?
>
>// IDLE=2'b00, XX=2'bx, S1=??, S2=??
>enum {IDLE, XX='x, S1, S2} state, next;
>
>Otherwise, I really do like this proposal.
>
>Regards - Cliff
>
>
>At 12:05 PM 4/8/02 +0100, you wrote:
>>Kevin,
>>
>>If a value is not specified, then the following from Cliff should apply:
>>
>>Draft 4, Section 3.6 - page 8
>>Section 3.6 - Paragraph #2 Clarification Proposal
>>PROPOSAL: modify the second paragraph as follows:
>>The named values can be cast to integer types, and increment from an
>>initial value of 0. This can be over-ridden. If integers are assigned to
>>some but not all of the named values, unassigned named values are
>>implicitly assigned an increment of the previous explicitly or implicitly
>>assigned integer.
>>enum {bronze=3, silver, gold} medal; // silver=4, gold=5
>>enum (a=3, b=7, c) alphabet; // c=8
>>
>>Peter.
>>
>>At 10:30 AM 4/5/02 -0800, Kevin Cameron wrote:
>>>
>>>
>>>Peter Flake wrote:
>>>> Cliff,
>>>>
>>>>We have considered your proposals, and we have a counter-proposal which
>>>>we think should satisfy your requirements.
>>>>
>>>>We propose an optional data type with the enum. The default data type
>>>>is int
>>>>
>>>>enum [data_type] { enum_member {, enum_member} }
>>>>
>>>>The data type is limited to integer data types, 2 state or 4 state. The
>>>>4 state data types can have constant values containing X or Z.
>>>>For example:
>>>>enum logic [1:0] { S0=2'b00, S1=2'b01, S2=2'b11, XX='x } state, next;
>>>>
>>>>Peter.
>>>What values get assigned if a value (or part of it) is not specified?
>>>
>>>Maybe want a default:
>>>
>>> enum [data_type] [ = <default value>] { enum_member {, enum_member} }
>>>
>>> e.g.:
>>> enum logic [1:0] = 2'b00 { S0=1'b0, S1=1'b1, S2=2'b11, XX=2'bxx }
>>> state, next;
>>>
>>> which extends as:
>>> enum logic [2:0] = 3'b100 { S0=1'b0, S1=1'b1, S2=2'b11, XX=2'bxx,
>>> BAD } state, next;
>>>// BAD takes default ==3'b100
>>>
>>>Note: since enums in C always allocate specific numbers (regardless of
>>>the compiler)
>>>mixing code from different compilers does not cause a problem (wrt
>>>enums). The
>>>same should (IMO) be true for SystemVerilog enums.
>>>
>>>Kev.
>
>//*****************************************************************//
>// Cliff Cummings Phone: 503-641-8446 //
>// Sunburst Design, Inc. FAX: 503-641-8486 //
>// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
>// PMB 501 Web: www.sunburst-design.com //
>// Beaverton, OR 97005 //
>// //
>// Expert Verilog, Synthesis and Verification Training //
>//*****************************************************************//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 13:45:04 PDT