• Aucun résultat trouvé

One-Hot Encoding

Dans le document Programmable VHDL (Page 170-174)

One-hot encoding is a technique that uses an n-bit-wide vector (i.e., n flip-flops) to represent a state machine with n different states. Each state has its own flip-flop, and only one flip-flop of the vector-the one corresponding to vector-the current state-will be "hot" (hold a 'I') at any given time. Decoding vector-the current state is as simple as finding the flip-flop containing a 'I', and changing states is as simple as changing the contents of the flip-flop for the new state from a '0' to a 'I' and the flip-flop for the old state from a 'I' to a '0'.

The primary advantage of one-hot-encoded state machines is that the number of gates required to decode state information for outputs and for next-state transitions is usually much less than the number of gates required for those purposes when the states are encoded in other fashions. This difference in complexity becomes more apparent as the number of states becomes larger: We'll use

157

158

an example to illustrate this point: Consider a state machine with 18 states that are encoded with 2 methods, sequential and one-hot, as shown below.

State Sequential One-Hot

stateO 00000 000000000000000001

state 1 00001 000000000000000010

state2 00010 000000000000000100

state3 00011 000000000000001000

state4 00100 000000000000010000

state5 00101 000000000000100000

state6 00110 000000000001000000

state7 00111 000000000010000000

state8 01000 000000000100000000

state9 01001 000000001000000000

state 10 01010 000000010000000000 state 11 01011 000000100000000000 state 12 01100 000001000000000000 state 13 01101 000010000000000000 state 14 01110 000100000000000000 state 15 01111 001000000000000000 state 16 10000 010000000000000000 state 17 10001 100000000000000000

Eighteen registers are required for one-hot encoding, whereas only five registers are required for the sequential encodiag. With one-hot, only one register is asserted at a time. To continue our example, suppose that Figure 5-10 represents a portion of the state flow diagram that depicts all possible transitions to state 15.

The code fragment that represents this state flow is case current_state is

when state2 =>

if cond1 = '1' then next_state <= state15i else ...

when state15 =>

if ...

elsif cond3 else ...

'0' then next state <= state15i

when state17 =>

if ...

elsif cond2 else ...

cond3

Figure 5-10 State flow diagram

'1' then next state <= state15;

The IF-THEN constructs would be completed, of course, to specify the state transitions for conditions not shown in the state flow diagram above, but the code is suitable for our purpose of differentiating sequential and one-hot coding effects on state-transition logic.

We examine the next-state logic for sequential encoding first. The sequential encoding for state15 is

"01111". We refer to the state vector as s, so s4 is 0; s3' s2' s}1 and So are alII for statel5. Using the state flow diagram of Figure 5-10, we can write an equation that represents the conditions in which Sj

is asserted due to a transition to statel5. In the equation, each state must be decoded (e.g., state2 as

"00010", state17 as "10001 ", and state15 as "01111 ").

Si,15 = ~ .

S; . S; .

sl .

Sa·

condl

+

S 4 .

S; . S; .

~

.

So . cond2

+ ~ . S3 . S2 . Sl . So . cond3

Although this equation defines Sj for transitions to statel5, this equation is not sufficient to specify so' sl' s2' and s3' Take So for example: The equation for sU5 above only covers the cases in which So is asserted due to transitions to statel5. The state So is asserted due to transitions to eight other states (all of the odd states). The logic equation associated with transitions to each of the other eight states may be of similar complexity to the equation for Sj,15 above. To obtain the complete equation for Sj'

each of the S j,x equations (where x is an integer from 0 to 17, representing the 18 states) must be summed. You can imagine that the logic for So can be quite complex, even for a relatively simple state flow diagram, simply because So is 1 for nine states. The sequential encoding will create five complex equations for Sj.

Compare the amount oflogic required to implement So> s}1 s2' s3' and s4 for a sequentially encoded state machine to the logic required for a one-hot coded state machine in which the decoding logic for state 15 is shown below. A state vector t is used so as not to confuse the equation with that of S

above. The vector t is 15 bits wide.

159

160

t15 = t2· condl

+

t17 . cond2

+

t15 . cond3

The equation for t15 can be derived easily from the state flow diagram. Figure 5-12 shows the logic implementation for transitions to state15. Whereas the sequential encoding requires five complex

condl cond3

cond2

D Q

state2

J---1D

Q

state 15

D Q

state17

Figure 5-11 State transition logic for one-hot coded state machines is simple.

equations for the next-state logic, the one-hot encoding requires eighteen simple equations.

Depending on the target logic device architecture, a one-hot coded state machine may require significantly fewer device resources for implementation of the design. Simple next-state logic may also require fewer levels of logic between the state registers: allowing for higher frequency of operation.

One-hot encoding is not always the best solution, however, mainly because it requires more flip-flops than a sequentially encoded state machine. In general, one-hot encoding is most useful when the architecture of the programmable logic device you want to use has relatively many registers and relatively little combinational logic between each register. For example, one-hot encoding is most useful for state machines implemented in FPGAs, which generally have much higher flip-flop densities than CPLDs, but which also have fewer gates per flip-flop. One-hot encoding may be the best choice even for CPLDs if the number of states and input conditions are such that the next-state logic for an encoded machine requires multiple passes through the logic array.

Up to now, we have discussed only what one-hot encoding is and the motivation for using it but not how to code one-hot state machines. Fortunately, using one-hot encoding requires little or no change to the source code but depends on the synthesis software tool you are using. Many synthesis tools allow you to use an enumerated type and specify the state encoding with an attribute, directive, command line switch, or GUI option. For example, we are using the Warp synthesis software to implement our memory controller as a one-hot state machine, so we can simply apply a state encoding attribute as shown below. The remaining code is the same as that of Listing 5-2:

type StateType is (idle, decision, readl, read2, read3, read4, write);

attribute state_encoding of StateType:type is one_hat_one;

signal current_state, next_state : StateType;

Generating outputs for one-hot encoded state machines is similar to generating outputs for machines in which the outputs are decoded from the state registers. The decoding is quite simple of course, because the states are just single bits, not an entire vector. This logic consists of an OR gate because Moore machines have outputs that are functions of the state and all states in a one-hot coded state machine are represented by one bit. The output decoding adds a level of combinational logic and the associated delay, just as it did before when the state bits were encoded. In an FPGA, the delay associated with the OR gate is typically acceptable and is an improvement upon decoding the outputs from an entire state vector. In a CPLD, the OR gate requires a second pass through the logic array, which means that the outputs will be available in tC02 time. The outputs can also be generated using parallel decoding registers, as was described earlier. This will eliminate the level of combinational logic and associated delay.

If any outputs are asserted in one state only, then these outputs are automatically encoded within the state bits. For example, we (write enable) is asserted only during the state write, expressed as

we <= '1' when present_state = write else '0';

There is a flip-flop directly associated with the state write, so we will be the value of that flip-flop.

Consequently, we will be available at the device pins or for intemallogic without the additional delay associated with decoding.

Dans le document Programmable VHDL (Page 170-174)