Subject: Re: Enumerated Types Proposals - Responding to Stu's comments
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Sun Mar 31 2002 - 08:24:04 PST
At 09:15 PM 3/29/02 -0800, Stu wrote:
>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.
If keeping 2-state is the issue, would it be possible to still assign
either 'x or 'z within the enumeration declaration and have them treated
like integers? A leading "1" indicates that the variable is either all X's
(100...0000) or all Z's (100...0001)? All other enumerated integers would
have a leading 0?
>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.
Not true. Once an enumeration has been declared, all assignments to state
and next must be made from this strongly defined subset of enumerated names.
One of my proposals was to either permit X-assignment within the enumerated
set or to permit X-assignment to the enumerated variables in the code (as
you have suggested). I can live with either one.
>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?
Because an engineer would want to start the design in an abstract way
(unassigned enumerated types) and then convert to concrete state
assignments later (by adding the encodings to the enumerated state names as
opposed to deleting the enumeration declaration and replacing it with
parameters).
Playing with enumerated types (as proposed) has shown me that VHDL
enumerated types weren't such a great feature after all. If I can't get
X-assignment to enumerated state names, I might as well just use parameters
from the start; otherwise, I will have to use the ugly and dangerous
"full_case" directive to achieve the same synthesis efficiencies I can get
with parameterized FSM design today.
First, the new SystemVerilog FSM syntax, now enum limitations. It's
beginning to look like the Verilog FSM design style has been and continues
to be the preferred FSM syntax. Aarrgh!
Regards - Cliff
>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 //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Sun Mar 31 2002 - 08:26:09 PST