Subject: RE: FSM Enhancement Goals and Thoughts
From: J. Bhasker (jbhasker@cadence.com)
Date: Thu Dec 13 2001 - 11:35:31 PST
It looks like SystemVerilog plans to support enumerated types. I assume that
that user will be able to supply values for enum types as well without
having to use an attribute. This will allow the designer
to have whatever encoding he/she wishes.
enum my_state [ IDLE =4'b0001, READ1=4'b0010, READ2=4'b0100,
WRITE1=4'b1000];
I guess it is ok to have an attribute that specifies some canned encodings,
such as onehot, onecold, etc.
(though not really required).
But as Cliff points out, there is a difference between specifying the values
of an enum type or
indicating that it is onehot. A synthesis tool on looking at the enum type
cannot figure out
that it is onehot without doing some analysis (which tools do not do). The
extra info that the
attribute "onehot" tells the synthesis tool is that the case statement in
"parallel_case".
So in effect if you specify onehot values in an enum type, then specify
"parallel_case" also
to get the same effect as the "onehot" attribute.
- bhasker
--J. Bhasker Cadence Design Systems 7535 Windsor Drive, Suite A200, Allentown, PA 18195 (610) 398-6312, (610) 530-7985(fax), jbhasker@cadence.com
-----Original Message----- From: owner-vlog-synth@eda.org [mailto:owner-vlog-synth@eda.org]On Behalf Of Clifford E. Cummings Sent: Wednesday, December 12, 2001 7:17 PM To: vlog-pp@eda.org Cc: vlog-synth@eda.org Subject: RE: FSM Enhancement Goals and Thoughts
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 : Thu Dec 13 2001 - 11:36:56 PST