( ESNUG 250 Item 5 ) -------------------------------------------- [9/6/96]
Subject: ( ESNUG 248 #5 249 #6 ) FSM Treatment Doesn't Seem Coherent
> As for your question of increasing performance, my first post still holds
> about one-hot and gray codes. For one hot, your mealy or moore output
> should be the state, and since there is one flip flop per state, you
> should not need wide combinatorial decodes to get valid state transitions.
> Take your circuit into the FSM compiler and perform a one-hot synthesis
> --that should give you the fastest output.
From: peer@iis.fhg.de (Dieter Peer)
I did some more evaluation on my design, and - for your information - I got
much worse results using one-hot. Best results in terms of speed I got
using some specific 4- or 5-bit state assignments. The reason is that my
ASIC lib has maximum 4 input gates (6 for complex gates). In order to
decode an 8-bit state, Synopsys seems to not only use the ones of its
state flip-flops but also some of the zeros.
I only partially agree. As long as the FSM is a straightforward counter or
shift register, you are right. But in a FSM usually there are lot of
non-incremental transitions needed, depending on the inputs (like 3->6,
7->1, 8->8 etc.). So the resulting netlist for that FSM would never be a
shift register or counter.
> Now, let's say you changed the order of the machine from ABCDEFGH to
> HACFGEBD, the machine would no longer transition in the order of a shift
> register, resulting in a differenct circuit.
I do not agree. It still IS a shiftreg in your terminology, just the ORDER
of the flipflops changes the same way as you swap the colums of the
assignment order from ABCDEFGH to anything.
John, I am still waiting for an explanation, why identical state coding with
variations of the ORDER of state-vector-assignment for a FSM produces
different synthesis results using synopsys software. Due to Synopsys
information it is probably related to a starting point problem in
synthesis. But this would mean, that for state machines using (e.g. one-hot
coding) it is worth trying different variations of one-hots, as some of
these are very-hot and others only one-warm.
- Dieter Peer
Fraunhofer-Gesellschaft
---- ---- ---- ---- ---- ---- ---- ----
From: "M. Arnold" <marnix@hydra.et.tudelft.nl>
Hi John,
In ESNUG 249, Ted Boydston and Dieter Peer are, at one point, talking
about "grey" and "gray" codes. I was taught that the only correct
spelling is "Gray", after Frank Gray who first patended their use in
1953 (F. Gray, "Pulse Code Communication", U.S. Patent 2 632 058,
March 17, 1953). Just my nitpicking $.02. :^)
- Marnix Arnold
Delft University of Technology
---- ---- ---- ---- ---- ---- ---- ----
Dieter Peer wrote: (in ESNUG 248 Item 5)
> I understand that I get quite different results when using different
> state assignments. Do you know an explanation, why the results also
> differ, if I change only the ORDER of my state vectors? Could I
> perhaps also get better or worse results, if I would change the order
> of my entity ports in the VHDL description from alphabetically to
> (whatever)?
From: Martin Radetzki <radetzki@offis.uni-oldenburg.de>
Dear John,
The mapping between states and code bits is often defined by a code matrix,
where the rows correspond to the states and the columns to the code bits.
In the literature it is stated that "permuting of columns does not affect
the cost of a realization, because it is equivalent to relabeling flip-flop
variables." [Michel, Lauther, Duzy (Eds.); The Synthesis Approach to Digital
System Design; Kluwer 1992].
So I think, Dieter is right to expect Synopsys to produce equivalent logic.
But as I have read (sorry, can't find the source), they calculate random
generator seed values from the Verilog/VHDL code in order to ensure "same
code, same logic" when applying random strategies. This might be an
explanation for the differences in synthesis results when changing the
ENUM_ENCODING attribute or the order of entity ports in the source code.
- Martin Radetzki
OFFIS Research Institute
[ Editor's Note: Martin, you read about how Synopsys generates "random"
seeds based on source code back in 3/3/93 in ESNUG 180 ! - John ]
|
|
