Subject: RE: FSM Enhancement Goals and Thoughts
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Dec 12 2001 - 16:17:16 PST
At 05:53 PM 12/11/01 -0800, Michael McNamara wrote:
>Michael McNamara writes:
> >
> > Clifford E. Cummings writes:
> > > Hi, All
> > > PROPOSALS
> > >
> > > enum - works great as is.
> > >
> > > If we do want a separate state type, I suggest:
> > >
> > > enum_state - to at least get away from the commonly used identifier
> name of
> > > "state."
> > >
> > > NEW! Add an enumeration type that would benefit onehot logic. This
> would be
> > > a true enhancement over both Verilog and VHDL. Add either:
> > >
> > > enum_onehot
> > > enum_state_onehot
> >
> > Also useful in hardware design in general (not necessarily for FSMs)
> > for fault tolerant systems are gray codes -> where a change in a
> > single bit always gets you to a known state; and avoids the
> > transistion from state 3'b100 -> 3'b010 inadvertantly appearing to be
> > appearing to be decoded as a walk through something like:
> > 3'b100 -> 3'b000 -> 3'b010
> >
> > Instead of adding yet another keyword (enum_gray), I'd propose we use
> > our attribute:
> >
> > enum my_state [
> > IDLE, READ1, READ2, WRITE1, WRITE2, WRITE3
> > ] (* enum_encoding={onehot|onecold|gray|increment|decrement}*) ;
>
>We could even allow 'grey' for Simon and Peter...
Nice of you to be so considerate of the Royals and Lords. Not a common
attitude among colonists! ;-)
> > That why we allow more encodings than we can today imagine, and we
> > don't take away anymore namespace.
We should probably coordinate this with the IEEE Verilog Synthesis
Interoperability Committee, of which a few of us are also members.
Attributes make sense to pass intention to another tool and all of the
styles that Mac listed above are worthy of consideration. The one point
that I want to make is that any encoding can be done manually using
enumerated types and work well for both simulation and waveform display,
except onehot (and possibly onecold).
If an engineer makes enumerated state assignments with binary codes, the
synthesis tool should do a comparable job whether the design is synthesized
with or without (* synthesis, fsm_style = binary *) attribute. Similarly
enumerated gray code assignments should synthesize to a design comparable
to adding (* synthesis fsm_style = gray *). 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).
For the above reasons, still think SystemVerilog would benefit from an
enum_onehot enumeration type, something that does not exist in any other
language that I know of.
Adding attributes should probably be left to the Verilog Synthesis Group
but we are certainly open to suggestions. It just so happens that we are
finalizing standard synthesis attributes at this time, and suggestions are
welcome, if they are also well documented (the committee is adverse to
suggestions of adding synthesis attributes that are not accompanied by full
proposals including descriptions that should be added to the standard).
We are currently talking to synthesis vendors about their standard
attributes and asking which should be included in the standard.
Based on the above discussion, it might make sense to change the proposed
(* synthesis fsm_style = ... *) attribute to the more general (* synthesis
enum_style = ... *) attribute. The latter could address more than just FSM
designs and might be more flexible when enumerated types are added to
SystemVerilog.
Again, the issue with enumerated types with efficient onehot designs is,
the enumerations are an index into a variable, not the actual encoding of
the variable itself. The index values themselves can be assigned with
enumerated types, but then there is no current method to monitor a design
variable to determine which enumerated name to display in a waveform
viewer. When I create a self-checking testbench for my synthesis FSM labs,
I currently have to test and display onehot states in a slightly different
way than I do binary or gray encodings. This requires a switch to be set on
the command line because I have no way of knowing if the designer used the
efficient onehot coding style or a regular state encoding.
Regards - Cliff
> > >
> > > Waveform viewers would now treat the onehot enumeration as an index as
> > > opposed to an actual encoding.
> > >
> > > Probably would also require:
> > >
> > > case_onehot(state)
> > > IDLE: ... ->> S0; // treated the same as:
> > > // case(1'b1)
> > > // state[IDLE]: ... next[S0] = 1'b1;
> > >
> > > Using something like the above syntax would make the transition from
> > > binary to one hot as simple as changing "enum" to "enum_onehot" and
> "case"
> > > to "case_onehot." And the waveform viewer will now look at which
> index bits
> > > are hot to determine which statename to display.
> > >
> > > Note: state machines are not the only hardware that use onehot
> codes. Wide
> > > fast multiplexers are often coded using onehot selects wired to
> tristate
> > > drivers that drive a common bus. Control logic is often coded as
> either
> > > encoded or onehot, for the latter each control bit does not have to
> first
> > > be decoded.
> > >
> > > Just some additional thoughts on goals and techniques.
> > >
> > > 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 : Wed Dec 12 2001 - 16:17:58 PST