1. Basic HDL Coding Techniques
Part 2

2. Welcome
If you are new to FPGA design, this module will help you build good HDL code that is optimized for an FPGA
These design techniques promote fast and efficient FPGA designs

3. After completing this module, you will able to:
Identify some basic design guidelines that successful FPGA designers follow
Select a proper HDL coding style for fast, efficient finite state machines
Easily pipeline your design
Note: The guidelines in this module are not specific to any particular synthesis tool or Xilinx FPGA family.

4. State Machine Design Put the next-state logic in one CASE statement
The state register can also be included here or in a separate process block or always block
Put the state machine outputs in a separate process or always block
Prevents resource sharing, which can hurt performance
Inputs to FSM S2 S1 S3
State
Machine
Module S5 S4
HDL Code
Next-state logic
Finite State Machines (FSMs) are faster when they are in separate processes because the combinatorial logic does not share resources; hence, logic can be combined into a single Look-Up Table (LUT).
State register
State machine outputs

5. The Perfect State Machine
The perfect state machine has…
Inputs: Input signals and state jumps
Outputs: Output states, control signals, and enable signals to the rest of the design
NO arithmetic logic, datapaths, or combinatorial functions inside the state machine
Current State Feedback to Drive State Jumps
State
Jumps
Only!
Next State
Output State and Enables
State Register
Input Signals

6. State Machine Encoding
Use enumerated types to define state vectors (VHDL)
Most synthesis tools have commands to extract and re-encode state machines described in this way
Use one-hot encoding for high-performance state machines
Uses more registers, but simplifies next-state logic
Examine trade-offs: Gray and Johnson encoding styles can also improve performance
Refer to the documentation of your synthesis tool to determine how your synthesis tool chooses the default encoding scheme
Register state machine outputs for higher performance
One-hot: The advantage of using one-hot encoding in Xilinx FPGAs is that the next-state decoding logic can be simplified to logic equations with six inputs or fewer, which can fit into a single LUT. This maximizes the performance of the state machine.
Many synthesis tools automatically choose one-hot encoding for state machines when you target a Xilinx FPGA, so check your synthesis tools documentation.

7. Benefits of FSM Encoding
Binary
Smallest (fewest registers)
Complex FSM tends to build multiple levels of logic (slow)
Synthesis tools usually map to this encoding when FSM has eight or fewer states
One-hot
Largest (more registers), but simplifies next-state logic (fast)
Synthesis tools usually map this when FSM has between 8 and 16 states
Always evaluate undefined states (you may need to cover your undefined states)
Gray and Johnson
Efficient size and can have good speed
Which is best?
Depends on the number of states, inputs to the FSM, complexity of transitions
How do you determine which is best?
Build your FSM and then synthesize it for each encoding and compare size and speed
By choosing an enumerated type for your FSM, you can easily experiment with each of these encoding techniques.
You also can simulate with binary encoding (easy to read) and then re-synthesize with a different encoding before implementation.

8. State Machine Example (Verilog)
module STATE(signal_a, signal_b, clock, reset, usually_one, usually_zero);
input signal_a, signal_b, clock, reset;
output usually_one, usually_zero;
reg [4:0] current_state, next_state;
parameter s0 = 0, s1 = 1, s2 = 2, s3 = 3, s4 = 4;
clock or posedge reset)
begin
if (reset)
current_state <= s0;
end
else
current_state <= next state;
This is an example of a simple state machine. Note that the outputs are not defined in this always block.
The first always block is the synchronous portion of the state machine. On a reset, the state machine returns to s0. Otherwise, the next state is loaded on each clock edge.
Outputs are not defined here (good)
Placed in a separate always block
Asynchronous reset (bad)

9. State Machine Example (Verilog)
(current_state or signal_a or signal_b)
begin
case (current_state)
s0: if (signal_a)
next_state = s0;
else
next_state = s1;
s1: if (signal_a && ~signal_b)
next_state = s4;
next_state = s2;
s2: next_state = s4;
s3: next_state = s3;
s4: next_state = s0;
default: next_state = ‘bx;
endcase
end
endmodule
This always block shows the next-state logic.
The state machine output logic is not shown here, but it would use a CASE statement similar to this one to determine the values of the outputs usually_one and usually_zero based on the current state (and perhaps signal_a and signal_b).
Use a default statement as part of your next state assignments (good)

10. Binary Encoding (Verilog)
reg [3:0] current_state, next_state;
parameter state1 = 2’b00, state2 = 2’b01,
state3 = 2’b10, state4 = 2’b11;
(current_state)
case (current_state)
state1 : next_state = state2;
state2 : next_state = state3;
state3 : next_state = state4;
state4 : next_state = state1;
endcase
(posedge clock)
current_state = next_state;
Test different FSM encodings yourself (good)
Don’t always trust your synthesis tool to choose the best encoding
The previous example used integers to represent the states. You may also use a PARAMETER statement to explicitly define the state values. This example shows a binary encoded state machine.

11. One-Hot Encoding (Verilog)
reg [4:0] current_state,next_state;
parameter state1 = 4’b0001, state2 = 4’b0010,
state3 = 4’b0100, state4 = 4’b1000;
(current_state)
case (current_state)
state1 : next_state = state2;
state2 : next_state = state3;
state3 : next_state = state4;
state4 : next_state = state1;
endcase
(posedge clock)
current_state = next_state;
This PARAMETER statement is defining a one-hot encoded state machine.
Encoding is easily changed

12. State Machine Example (VHDL)
library IEEE;
use IEEE.std_logic_1164.all;
entity STATE is
port (
signal a, signal b: in STD_LOGIC;
clock, reset: in STD_LOGIC;
usually_zero, usually_one: out STD_LOGIC );
end STATE;
architecture STATE_arch of STATE is
type STATE_TYPE is (s0,s1, s2, s3);
signal current_state, next_state: STATE_TYPE;
signal usually_zero_comb, usually_one_comb : STD_LOGIC;
begin
This is an example of a simple state machine.

13. State Machine Example (VHDL)
COMB_STATE_MACHINE: process(current_state, signal a, signal b)
begin
next_state <= s0;
usually_zero_comb <= '0';
usually_one_comb <= '1'; -- set default to one and reset to zero when necessary
case current_state is
when s0 =>
next_state <= s1;
if signal a = '1' then
end if;
when s1 =>
next_state <= s2;
if signal a='1' AND signal b = '0' then
next_state <= s3;
usually_zero_comb <= '1';
when s2 =>
when s3 =>
usually_one_comb <= '0';
when others =>
end case;
end process;
Default state is used to define output values (good)
This process contains the next-state logic and the state machine output logic.
You could also separate the state machine outputs into their own process, which is recommended for larger and more complex state machines.

14. State Machine Example (VHDL)
SYNCH_STATE_MACHINE: process(clock, reset)
begin
if (reset = '1') then
current_state <= s0;
usually_zero <= '0';
usually_one <= '1';
elsif (clock'event and clock = '1') then
current_state <= next_state;
usually_zero <= usually_zero_comb;
usually_one <= usually_one_comb;
end if;
end process;
end STATE_arch;
This is the synchronous portion of the state machine. On a reset, the state machine returns to s0. Otherwise the next state is loaded on each clock edge.
Notice that the state machine outputs are also registered in this process. If the state machine outputs were purely combinatorial, they would not be included here.
Asynchronous reset (bad, unreliable)

15. Unspecified Encoding (VHDL)
entity EXAMPLE is
port( A,B,C,D,E, CLOCK: in std_logic; X,Y,Z: out std_logic);
end EXAMPLE;
architecture XILINX of EXAMPLE is
type STATE_LIST is (S1, S2, S3, S4, S5, S6, S7);
signal STATE: STATE_LIST;
begin
P1: process( CLOCK ) begin
if( CLOCK’event and CLOCK = ‘1’) then
case STATE is
when S1 =>
X <= ‘0’; Y <= ‘1’; Z <= ‘1’;
if( A = ‘1’ ) then
STATE <= S2;
else
STATE <= S1;
Most synthesis tools will implement an “unspecified encoding” as a binary encoded state machine. The synthesis tool assigns state values starting with the leftmost value in the list. In this example, S1 = 000, S2 = 001, … and S7 = 110.
Undefined encoding (bad, probably inefficient)

16. One-Hot Encoding (VHDL)
architecture one-hot_arch of one-hot is
subtype state_type is std_logic_vector(5 downto 0);
signal current_state, next_state: state_type;
constant s0 : state_type := "000001";
constant s0_bit : integer := 0;
constant s1_bit : integer := 1;
constant s2_bit : integer := 2;
constant s3_bit : integer := 3;
constant s4a_bit : integer := 4;
constant s4b_bit : integer := 5;
signal usually_zero_comb, usually_one_comb : std_logic;
begin
comb_state_machine: process(current_state, signal a, signal b, signal c, signal d)
next_state <= state_type'(others => '0');
if current_state(s0_bit) = '1' then
if signal a = '1' then
next_state(s0_bit) <= '1';
else
next_state(s1_bit) <= '1';
end if;
if current_state(s1_bit) = '1' then
next_state(s4a_bit) <= '1';
end;
OHE a little harder in VHDL (recommend using your synthesis tools attribute, if possible)
Most synthesis tools have options to compile state machines as binary or one-hot. If your synthesis tool has this option, use the “Unspecified Encoding” example along with this synthesis option to create a one-hot state machine.
Some synthesis tools also allow for an attribute of “one-hot” on a user-defined type. This is another way to get a one-hot state machine without resorting to the more cumbersome syntax shown here.

17. Pipelining Concept fMAX = n MHz fMAX  2n MHz two logic levelsD Q D Q
one level
one level
fMAX 
2n MHz D Q D Q D Q
Inserting flip-flops into a datapath is called pipelining.
Pipelining increases performance by reducing the number of logic levels (LUTs) between flip-flops.
All Xilinx FPGA device families support pipelining. The basic slice structure is a logic level (six-input LUT) followed by a flip-flop.
Adding a pipeline stage, as shown in this example, will not exactly double fMAX. The flip-flop that is added to the circuit has an input setup time and a clock-to-Q time that make the pipelined circuit run at less than double the original frequency.
You will see a more detailed example of increasing performance by pipelining later in this section.

18. Pipelining Three situations in which to pipeline Register I/O
Usually done by the designer from the beginning
Register the outputs of each lower leaf-level output
Typically done after timing analysis
Can easily be done for purely combinatorial components
Register high-fanout secondary control signals (Set, Reset, CEs)
These are just the most obvious suggestions. For every design, there may be more tricks or other clever things that can improve performance.
Pipelining is the one thing that helps the most, and for most systems today, pipelining is always an option because bandwidth is what defines the system, not the latency. Latency can be important, but if it is, it is usually the latency in a different order of magnitude than the one that is caused by pipelining.
FPGAs have lots of registers, so re-timing and clever use of arithmetic functions can yield tremendous performance. If designers need to balance the latency among different paths in the system, the SRLs can be used to compensate efficiently for delay differences.

19. Performance by Design Code A Code B Switch High fanoutQ
Code A
High fanout
One level of logic, but the routing can be prohibitive
May require higher speed grade, adding cost D Q
Enable
data_in CE
reg_data D Q
Switch
Code B D Q
reg_enable
One level of logic
Maximum time for routing of high fanout net
Flip-flop adds nothing to the cost
Data_in must also be registered D Q
High fanout D Q
Enable
In ‘Code B’ the ‘reg_data’ is enabled one clock cycle later, so it would be important to ensure that the ‘data_in’ is still valid. This may require the user to balance the latency on the input path for data_in in Code B. Recall that the data will be available one cycle later than Code A.
Adding the pipeline flip-flop really costs nothing because it comes with the LUT. Again, you increase gate count and increase performance without adding to the cost.
In practice, the coding style leads to preparing clock enables one cycle in advance of when they are required. Note that the addition of the register adds some latency that you will have to plan for as well. CE
reg_data D Q D Q
data_in
Ken Chapman
(Xilinx UK) 2003

20. Performance by Design (Verilog)
These two pieces of code are not functionally identical
Code B (on the right) forms a pipeline stage for the circuit and improves its speed, Code A does NOT
In each case
reg_data and data_in are 16-bit buses
switch and enable are outputs from flip-flops
Code A
Code B
clk)
begin
if (switch && enable)
reg_data <= data_in;
end
clk)
begin
if (set_in && enable_in)
reg_enable <= 1'b1;
else
reg_enable <= 1'b0;
if (reg_enable)
reg_data <= data_in;
end
The code on the left performs a decode as part of the enable. The code on the right performs the decode separately to form a registered signal, which is then used to enable a bank of registers.
Real designs may have a far more complicated set of rules for loading this register. It usually increases the levels of logic and the delay. Here is an example:
If address=X”1B3D” then
reg_data <= processor_output
End if;

21. Performance by Design (VHDL)
These two pieces of code are not functionally identical
The code on the right forms a pipeline stage for the circuit and improves its speed
In each case
reg_data and data_in are 16-bit buses
switch and enable are outputs from flip-flops
Code B
capture: process (clk)
begin
if clk'event and clk='1' then
if switch ='1’ and enable=‘1’ then
reg_enable <= ‘1’;
else
reg_enable <= ‘0’;
end if;
if reg_enable='1’ then
reg_data <= data_in;
end process;
Code A
capture: process (clk)
begin
if clk'event and clk='1' then
if switch='1’ and enable=‘1’ then
reg_data <= data_in;
end if;
end process;
The code on the left performs a decode as part of the enable. The code on the right performs the decode separately to form a registered signal which is then used to enable a bank of registers.
Real designs may have a far more complicated set of rules for loading this register. It usually increases the levels of logic and the delay.
If address=X”1B3D” then
reg_data <= processor_output
End if;

22. Summary
When coding a state machine, separate the next-state logic from state machine output equations
Evaluate whether you need to use binary, one-hot, Gray, or Johnson encoding style for your FSM
This will yield a smaller and/or faster FSM
Pipeline data paths to improve speed

23. Where Can I Learn More? Software Manuals Xilinx Training
Start  Xilinx ISE Design Suite 12.1  ISE Design Tools  Documentation  Software Manuals
This includes the Synthesis & Simulation Design Guide
This guide has example inferences of many architectural resources
XST User Guide
HDL language constructs and coding recommendations
Software User Guides and software tutorials
Xilinx Training
Xilinx tools and architecture courses
Hardware description language courses
Basic FPGA architecture and other topics (free training videos!)

24. Trademark Information
Xilinx is disclosing this Document and Intellectual Propery (hereinafter “the Design”) to you for use in the development of designs to operate on, or interface with Xilinx FPGAs. Except as stated herein, none of the Design may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx. Any unauthorized use of the Design may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes.
Xilinx does not assume any liability arising out of the application or use of the Design; nor does Xilinx convey any license under its patents, copyrights, or any rights of others. You are responsible for obtaining any rights you may require for your use or implementation of the Design. Xilinx reserves the right to make changes, at any time, to the Design as deemed desirable in the sole discretion of Xilinx. Xilinx assumes no obligation to correct any errors contained herein or to advise you of any correction if such be made. Xilinx will not assume any liability for the accuracy or correctness of any engineering or technical support or assistance provided to you in connection with the Design.
THE DESIGN IS PROVIDED “AS IS" WITH ALL FAULTS, AND THE ENTIRE RISK AS TO ITS FUNCTION AND IMPLEMENTATION IS WITH YOU. YOU ACKNOWLEDGE AND AGREE THAT YOU HAVE NOT RELIED ON ANY ORAL OR WRITTEN INFORMATION OR ADVICE, WHETHER GIVEN BY XILINX, OR ITS AGENTS OR EMPLOYEES. XILINX MAKES NO OTHER WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING THE DESIGN, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NONINFRINGEMENT OF THIRD-PARTY RIGHTS.
IN NO EVENT WILL XILINX BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, EXEMPLARY, SPECIAL, OR INCIDENTAL DAMAGES, INCLUDING ANY LOST DATA AND LOST PROFITS, ARISING FROM OR RELATING TO YOUR USE OF THE DESIGN, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE TOTAL CUMULATIVE LIABILITY OF XILINX IN CONNECTION WITH YOUR USE OF THE DESIGN, WHETHER IN CONTRACT OR TORT OR OTHERWISE, WILL IN NO EVENT EXCEED THE AMOUNT OF FEES PAID BY YOU TO XILINX HEREUNDER FOR USE OF THE DESIGN. YOU ACKNOWLEDGE THAT THE FEES, IF ANY, REFLECT THE ALLOCATION OF RISK SET FORTH IN THIS AGREEMENT AND THAT XILINX WOULD NOT MAKE AVAILABLE THE DESIGN TO YOU WITHOUT THESE LIMITATIONS OF LIABILITY.
The Design is not designed or intended for use in the development of on-line control equipment in hazardous environments requiring fail-safe controls, such as in the operation of nuclear facilities, aircraft navigation or communications systems, air traffic control, life support, or weapons systems (“High-Risk Applications”). Xilinx specifically disclaims any express or implied warranties of fitness for such High-Risk Applications. You represent that use of the Design in such High-Risk Applications is fully at your risk.
© 2009 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc. All other trademarks are the property of their respective owners.