Subject: Re: FSM Enhancement Goals and Thoughts
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Dec 13 2001 - 09:43:14 PST
Hi, Adam -
This is a good discussion!
At 10:47 AM 12/13/01 -0600, Adam Krolnik wrote:
>Good morning Cliff;
>
>You wrote:
>
> >But a design with enumerated onehot state assignments (such as
> enum >{S0=4'b0001, S1=4'b0010, S2=4'b0100, S3=4'b1000} state;) will not
> >synthesize nearly as efficient as adding (* synthesis fsm_style =
> >onehot *), and per my experience, telling the synthesis tool
> to >synthesize the onehot FSM rarely yields the same efficient results
> >that I achieve when use indexed parameters and case (1'b1).
>
>This is a critique of synthesis tools.
A critique and a reality. When synthesis tools first came out, experienced
engineers feared that their skills could be replicated by a new college
grad with a synthesis tool. We have since discovered that it still takes a
good engineer to achieve the best synthesis results.
It is typically true that an engineer can hand-craft a design better than
any synthesis tool. But in most cases, a synthesis tool can complete the
design quicker than an engineer and the results are typically good enough
(meets timing and area goals) so the design can be released
sooner resulting in earlier revenue generation and typically higher profit
margins for being first to market.
>I do understand that in the real world, the synthesis tools are not
>going to change by the time that you need your design to meet its
>physical metrics and so you will recode to meet the requirements.
>But at the language level, must we also concede this point?
Concede? Perhaps not. Recognize? Yes. My Advanced Verilog Classes are
advanced design classes. I teach design techniques and coding styles that
yield the smallest and fastest designs and how to complete the design quicker.
My experience has been that there are two ways to improve a design (to make
it faster and smaller). (1) Learn all of the tricks of your synthesis tool,
and (2) change the Verilog input code. My experience has been that the
latter makes the biggest difference. If you have a bad coding style, asking
the tool to work harder will make some improvement but not as much as
changing the Verilog code.
>Should it be possible for a tool to receive an attribute (a hint)
>that the encoding should be synthesized as a decoded (one hot) style,
>and the result be the same as if the code explicitly checked a single
>bit?
Yes. And most tools have a onehot button that we are trying to supplant
with a onehot attribute so you don't have to know how to use the onehot
button on every tool you touch.
This is part of the point that Simon was making in our conference call
earlier this week. We want to start abstract and move to the specific as
needed. Asking a tool to implement onehot will satisfy the requirements of
many designs. Defining state encoding and output assignment specifics
squeezes the last bit of performance out of a design. If you don't need to
squeeze the performance, the attribute with more abstract coding style will
be sufficient.
The reason physical compilers are becoming important tool suites is because
after squeezing the last bit of performance out of a synthesis tool, an
optimal placement and routing are often required to squeeze even more out
of the design.
>BTW, there is a trick I have seen people use instead of using the
>case(1'b1) style for inferring one-hot designs.
>
>parameter S0 = 1, S1 = 2, S2 = 4, S3 =8,
> RS0 = 4'b???1, RS1 = 4'b??1?, RS2 = 4'b?1??, RS3 = 4'b1???;
>
>casez(state)
> RS0: ... next_state = S2;
> RS1: ...
> RS2: ... next_state = S1;
>
>endcase
I have seen this trick too. I have never seen the extra RSx parameter
assignments; I have just seen the 1's and ?'s in the casez statement. This
coding style works fine for small state machine designs, but becomes quite
cumbersome for large FSM designs. Imagine all of the ?'s in an FSM design
with 50-80 states. We could argue whether or not an FSM should have more
than X states, but the reality is that I know of engineers that have done
state machines with 200-300 states. These designs would look like pure ?'s!
I discourage this style.
In my 100+ pages of FSM material in my Advanced Verilog class, I teach
styles, techniques and reasons that apply to all FSM designs. I do not
teach the implicit FSM style that is only applicable to a small subset of
FSM designs and I do not teach the above casez techniques that would only
be useful for small FSM designs.
What I like about the "enum" and "enum_onehot" combined with "case" and
"case_onehot" keywords is that any FSM design could start as an abstract
FSM design (per Simon's recommendations) and very easily evolve into a
onehot design with defined state bits with very little effort. Plus a
waveform viewer should be capable of displaying my state information either
way without me, the design engineer, having to make other adjustments to my
code to see state information in my waveform display.
If this capability existed, there would no reason NOT to start with an
abstract FSM design (per Simon's suggestion) because an engineer would have
full confidence that the code could be easily modified as the circumstance
requires.
I think someone also suggested replacing "case" and "case_onehot" with
"transition" and "transition_onehot." I have no problem with this
modification to the proposal or any other modification that would still
achieve the same goals.
> Adam Krolnik
> Verification Mgr.
> LSI Logic Corp.
> Plano TX. 75074
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 : Thu Dec 13 2001 - 09:44:17 PST