Subject: Re: PROPOSAL: Remove the SystemVerilog State Machine Section - Response to Anders
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Apr 01 2002 - 15:07:07 PST
At 10:48 AM 4/1/02 -0500, Anders Nordstrom wrote:
>Hi Cliff,
>
>Thanks for re-coding the FSMs in soo many ways, it really helps to be able
>to compare them.
Your welcome!
>I don't agree that we should remove the State Machine section from the
>standard.
>What I like about the transition statement is that, that's how I think
>when designing an FSM. I draw a bubble diagram and the main concern is,
>what are the transitions between states.
That is one of two main concerns:
(1) transitions
(2) output assignments (Mealy and Moore outputs). An FSM design without
outputs is pretty useless.
>Using the transition statement, it is clear to all tools that this is an
>FSM and you can have as many as you want in a module without confusing the
>tools.
I see no compelling reason to code more than one FSM per module. There is
no reason today that a synthesis tool could not extract multiple FSM
designs from multiple case statements in one module. Vendors simply have
chosen not to address this infrequent coding style. For
multi-FSM-per-module style, you will need unique state variable names
(enums or regs), such as fsm1_state and fsm2_state. If you put the FSMs
into different modules, you can use the more common "state" variable name
in both modules and still reference them uniquely hierarchically.
>For now, it is useful to be able to specify the coding of the states but
>really, I don't want to do that anyway.
Enumerated types without state assignments is the abstract representation.
For you, and for many designs, this will typically be good enough.
For higher performance designs, the ability to control the state encodings
and the ability to map them to critical outputs can be key to easily
achieving a successful design. That is the beauty of SystemVerilog
enumerated types (start abstract and evolve to completely defined where
applicable without having to change the rest of the code, such as switching
to parameters as Stu previously suggested).
>The only reason I do it is because I know that if I code my FSM one-hot it
>synthesize well. This is a synthesis tool limitation, not a language
>limitation.
Yes and no. There are so many subtleties to FSM design that it is often
easier to communicate intent through the RTL than through a series of
attributes or synthesis switches. Synthesis switches differ from tool to
tool so placing intent in the RTL code is preferable (IMO).
The enum_onehot proposal could help achieve the EXACT same results between
RTL and synthesized designs.
As you know, synthesis tools cannot find THE best answer. The algorithmic
space is too large for even most small designs. Synthesis tools (hopefully)
build good logic in a short amount of time. A skilled engineer will always
be capable of beating a synthesis tool in size and speed. This is rarely
required (the synthesis tool does good enough), on those occasions where
you need to manually tweak the design to achieve the last ounce of
performance, you don't want to have to re-code the design a different way
to achieve the desired results. The case (1'b1) onehot style is somewhat
painful today in that it requires that you make about ten changes to your
original FSM design to achieve the new onehot results. Using the case
(1'b1) style also breaks automatic FSM extraction from most (if not all)
synthesis tools (but it sure builds a great design!)
This can be changed with new capabilities not available in any other HDL or
software language by adding an enum_onehot capability (among others).
>I prefer the style in your example fsm2 and I have a few suggestions.
>Remove the XX state and the state = XX; assignment. It shouldn't be
>necessary to declare it. If a transition is missing in a state, then state
>should be unknown without any special statement required.
Minor mistake in my code. The assignment should be next = XX;
The problem is, some people like to code FSMs using something like: next =
ERROR; or delete the initial next=assignment from in front of the case
statement to further reduce coding effort (if state=IDLE and if the next
state is the IDLE state, no HDL assignment is necessary inside of the case
statement because the next state variable is not required to change).
This also addresses Stu's question. For most FSM designs, asking for
don't-care next=XX assignments helps to optimize the design, because the
synthesis tool can treat some state encodings as don't-cares. The problem
is, with some "mission-critical" designs, such as medical implants or
satellites, you have to worry about, "what if my FSM goes off to an
undefined state?" In those cases, an assignment such as next=ERROR is
reasonable to help get the design put back into a known good state and to
help the rest of the hardware to also transition to that known good state.
I taught this style to one medical implant company. They decided to
implement the pre-synthesis FSM designs with "next='bx" to help easily
debug the design, and then they changed their code to "next=error" for the
actual design, to build in the error correction capabilities required by
the medical implant device.
>Ideally I would like to get rid of the next variable as well. The
>transition statement could be coded: transition (state), however I don't
>know how to re-code: state <= next;
If you do a two always block FSM design, you need "next." If you do a one
always block FSM design, you do not need "next." The following two
constructs are equivalent:
case (state)
... next = <state_to_transition_to>;
transition (state -> next)
... ->> <state_to_transition_to>;
Although I like the "->>" transition syntax (because it looks like a
transition arc), it is really just the same as saying "this arc transitions
to the next state" or "next ="
A good two always block FSM coding style will have a "next =" statement for
every transition arc in the FSM state diagram.
>module fsm2 (output reg found_101,
> input serial, clk, reset);
>
> enum {S0, S1, S2, XX} state, next;
>
> always @(posedge clk or posedge reset)
> if (reset) state <= S0;
> else state <= next;
>
> always_comb begin
> state = XX;
// typo: should have been next = XX;
> found_101 = 1'b0;
> transition (state ->> next)
> S0 : if (!serial) ->> S0;
> else ->> S2;
> S1 : begin
> ->> S0;
> if (serial)
> found_101 = 1'b1;
> end
> S2 : if (!serial) ->> S1;
> else ->> S0;
> endtransition
> end
>endmodule
>
>
>Regards,
>
> Anders
I really want any new FSM syntax to be something worth bragging about, not
just a syntactically equivalent set of keywords that look nice when talking
about FSM designs.
Regards - Cliff
//*****************************************************************//
// 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 : Mon Apr 01 2002 - 15:09:35 PST