Subject: Re: Enumerated Types Proposals
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Mar 29 2002 - 21:15:03 PST
I agree with both points of view regarding X and Z values with enumerated
types. Overall, however, I think it is better to leave them as 2-state
types, similar to bit or int. That is more in keeping with abstract
modeling styles, and better for simulation efficiency. The default
assignment to logic X for synthesis can be achieved by assigning a literal
value of X, instead of storing the X in an enumerated type. It would not
be hard to add 4-state enumerated types in SystemVerilog 3.1 if the need
becomes apparent. It would be difficult remove them later, if we started
with 4-state enumerated types.
Other than 4-state enumerated types, I like all the rest of Cliff's
proposals. Bit and part selects are essential. Sized types is a great
feature. Specifying unique values for each enumerated type in the list
allows many types of FSMs to be modeled, though at that point, why not just
use parameters instead of creating enumerated types?
Stu
At 02:09 PM 3/29/2002, Peter Flake wrote:
>Hi, Cliff,
>
>Thanks for the clarifications.
>
>I am afraid I completely disagree with your X and Z assignment proposal.
>To me, this destroys the concept of an enumeration, which is a set of
>named alternatives, and replaces it with a set of constant values. How
>are values containing X or Z to be incremented?
>Your proposal implies that X or Z can overlap 0 or 1. How can an
>exhaustive case on such an enumeration be synthesizable?
>
>The range and part-select proposals add convenience rather than any
>functionality which cannot be achieved with other SystemVerilog
>constructs, so I do not object to them.
>
>Peter.
>At 04:39 PM 3/28/02 -0800, Clifford E. Cummings wrote:
>>Hi, All - (proposals also attached as Enumeration_proposals_20020328.pdf)
>>
>>This email contains seven proposals to clarify and enhance SystemVerilog
>>enumerated types. See details below.
>>
>>Section 3.6 - Paragraph #1 Clarification Proposal
>>Section 3.6 - Paragraph #2 Clarification Proposal
>>Section 3.6 - Proposal to add a new paragraph #3 for clarification
>>Section 3.6 - Example #3 Clarification Proposal
>>Section 3.6 - Enumeration Range Proposal
>>Section 3.6 - Part-Select of Enumerated Variable Proposal
>>Section 3.6 - X & Z-Assignment of Enumerated Variable Proposal
>>
>>Regards - Cliff Cummings
>>
>>----------
>>Draft 4, Section 3.6 - page 8
>>Section 3.6 - Paragraph #1 Clarification Proposal
>>PROPOSAL: expand the first paragraph as follows:
>>An enumerated type has one of a set of named values. In the following
>>example, "light1" and "light2" are defined to be variables of the
>>anonymous (unnamed) enumerated type that includes the three members:
>>"red", "yellow" and "green."
>>
>>----------
>>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
>>
>>----------
>>Draft 4, Section 3.6 - page 8
>>Section 3.6 - Proposal to add a new paragraph #3 for clarification
>>PROPOSAL: add a new paragraph and example after second example as follows:
>>It shall be illegal to explicitly or implicitly assign the same integer
>>to more than one named value.
>>enum (a=0, b=7, c, d=8) alphabet; // c must be 8 and d is 8 - syntax error
>>
>>----------
>>Draft 4, Section 3.6 - page 9
>>Section 3.6 - Example #3 Clarification Proposal
>>PROPOSAL: for the third existing example of section 3.6, change the
>>comment to:
>>// silver=4'h4, gold=4'h5 (all are 4 bits wide)
>>enum {bronze=4'h3, silver, gold} medal4;
>>
>>----------
>>Draft 4, Section 3.6 - page 9
>>Section 3.6 - Enumeration Range Proposal
>>PROPOSAL: permit enum to have a range to set a common size.
>>Proposed wording: Add the following before the paragraph starting with
>>"The type name can be given ...," just before the typedef example.
>>
>>Adding a constant range to the enum declaration can be used to set the
>>size of the type. If any of the enum members are defined with a different
>>sized constant, this shall be a syntax error.
>>// Error in the bronze and gold member declarations
>>enum [3:0] {bronze=5'h13, silver, gold=3'h5} medal4;
>>// Correct declaration - bronze and gold sizes are redundant
>>enum [3:0] {bronze=4'h13, silver, gold=4'h5} medal4;
>>
>>----------
>>Draft 4, Section 3.6 - page 9
>>Section 3.6 - Part-Select of Enumerated Variable Proposal
>>PROPOSAL: Add the ability to index, bit-select and part-select enumerated
>>types:
>>Proposed wording: Add the following before the paragraph starting with
>>"The type name can be given ...," just before the typedef example.
>>
>>Enumerated types declared with a range shall permit bit-selection or
>>part-selection access to the bits of the enumerated variables.
>>// state and next both have the range [1:0]
>>enum [1:0] { S0=2'b00, S1=2'b01, S2=2'b11 } state, next;
>>
>>assign out1 = state[1]; // the out1 output is tied to bit[1] of the state
>>variable
>>
>>Reason: Some of the most efficient FSM designs utilize a technique called
>>"output encoded FSMs" where one or more of the state bits are explicitly
>>mapped to output bits. This creates registered outputs without any
>>additional logic. Fast and small.
>>
>>----------
>>One of the following proposals are required to make enumerated types
>>usable for efficient FSM synthesis.
>>Draft 4, Section 3.6 - pages 8-9
>>Section 3.6 - X & Z-Assignment of Enumerated Variable Proposal
>>2nd paragraph states:
>>"The values can be cast to integer types, and increment from an initial
>>value of 0. This can be over-ridden."
>>
>>PROPOSAL-A: add this as the last paragraph in section 3.6
>>The values of enumerated types can also be cast to all X's ('x) or all
>>Z's ('z).
>>enum { S0=2'b00, S1=2'b01, S2=2'b11, XX='x } state, next;
>>
>>-OR-
>>
>>PROPOSAL-B: add this as the last paragraph in section 3.6
>>Any enumerated type can be assigned a value of all X's ('x) or all Z's ('z).
>>enum { S0=2'b00, S1=2'b01, S2=2'b11 } state, next;
>>
>>always @(posedge clk or posedge reset)
>> if (reset) state <= S0;
>> else state <= next;
>>
>>always @* begin
>> next = 2'bx; // (SystemVerilog) next = 'x
>> found_101 = 0;
>> case (state)
>> S0: if ( serial) next = S2;
>> else next = S0;
>> S2: if (!serial) next = S1;
>> else next = S0;
>> S1: begin
>> next = S0;
>> if (serial) found_101 = 1;
>> end
>> endcase
>>end
>>
>>REASON: Efficient FSM coding style uses a default assignment of all X's
>>to the next state variable for two very good reasons:
>>
>>(1) it helps debug the FSM design. By making an all X's assignment to
>>the next variable before entering the case statement, if the designer
>>forgot to add one of the state transition assignments (for example,
>>delete the else statement for the S2 case item) it will become very
>>obvious during simulation that the RTL code is missing a state transition
>>(the simulation will suddenly go to all X's (bleed-red in the waveform
>>viewer) precisely when the missing transition occurred). This helps to
>>quickly identify defects in the RTL code.
>>
>>(2) it helps the synthesis tool optimize the design. X-assignments
>>are treated as "don't-cares" for synthesis purposes, so the synthesis
>>tool will optimize away the unused state encodings. Without
>>x-assignments, we would require the very ugly a problematic (* synthesis,
>>full_case *) attribute to accomplish the same synthesis-goal.
>>
>>In the absence of the ability to make X-assignments to enumerated types,
>>I would counsel students to ignore enumerated types for abstract FSM
>>design because it will be easier to debug the FSM using parameters and
>>X-assignments, to control state assignments and to enable synthesis
>>optimization. This is a glaring hole in VHDL FSM design using enumerated
>>types (trading off waveform enumerations for debug-ease and synthesis
>>optimization).
>>
>>The following example demonstrates the use of the X-assignment.
>>parameter S0=2'b00,
>> S1=2'b01,
>> S2=2'b11;
>>
>>reg [1:0] state, next;
>>
>>always @(posedge clk or posedge reset)
>> if (reset) state <= S0;
>> else state <= next;
>>
>>always @* begin
>> next = 2'bx; // (SystemVerilog) next = 'x
>> found_101 = 0;
>> case (state)
>> S0: if ( serial) next = S2;
>> else next = S0;
>> S2: if (!serial) next = S1;
>> else next = S0;
>> S1: begin
>> next = S0;
>> if (serial) found_101 = 1;
>> end
>> endcase
>>end
>>
>>
>>
>>
>>
>>
>>
>>//*****************************************************************//
>>// 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 : Fri Mar 29 2002 - 21:11:35 PST