Basic HDL Coding Tech

7/27/2019 Basic HDL Coding Tech

1/27

Basic HDL Coding

Techniques

2008 Xilinx, Inc. All Rights ReservedBasic HDL Coding Techniques - A -2

Objectives

After completing this module, you will be able to:

Specify Xilinx resources that may need to be instantiated

Identify some basic design guidelines that successful FPGA designers follow

Select a proper HDL coding style for fast, efficient circuits, including:

Combinatorial functions

Register functions

State machines

Note: The guidelines in this module are not specific to any particular synthesistool or Xilinx FPGA family


2/27


Outline

Achieving Breakthrough Performance

Basic Design Guidelines

Coding for Combinatorial Logic

Register Inference

Finite State Machine Design

Pipelining

Summary


Breakthrough Performance

Three steps to achieve breakthrough performance1. Utilize embedded (dedicated) resources

Dedicated resources are faster than a LUT/flip-flopimplementation and consume less power

Typically built with the CORE Generator tool andinstantiated

DSP48, FIFO, block RAM, ISERDES, OSERDES,PowerPC processor, EMAC, and MGT, for example

2. Write code for performance Use synchronous design methodology

Ensure the code is written optimally for critical paths

Pipeline

3. Drive your synthesis tool Try different optimization techniques

Add critical timing constraints in syn thesis

Preserve hierarchy

Apply full and correct constraints

Use High effort

Performance Meter

Virtex-5 FPGAVirtexVirtex--5 FPGA5 FPGA


3/27


Use Embedded Blocks

XtremeDSP SolutionSlice

Smart RAM FIFO

PowerPC Processor

Embedded block timing is correct by construction

Not dependent on programmable routing

Offers as much as 3x the performance

of soft implementations

Uses less power

Examples

FIFO at 500 MHz

DSP slices at 500 MHz

PowerPC processor at

702 DMIPS


Timing Closure


4/27


Outline




Register Inference


Pipelining

Summary


Instantiation versus

Inference

Instantiate a component when you must dictate exactly which resource is

needed

The synthesis tool is unable to infer the resource

The synthesis tool fails to infer the resource

Xilinx recommends inference whenever possible

Inference makes your code more portable

Xilinx recommends using the CORE Generator software to create

functions such as Arithmetic Logic Units (ALUs), fast multipliers, and

Finite Impulse Response (FIR) filters for instantiation

Xilinx recommends using the Architecture Wizard utility to create DCM,

PLL, and BUFG instantiations


5/27


FPGA Resources

Can be inferred by all synthesis

tools

Shift register LUT (SRL16/

SRLC16)

F5, F6, F7, and F8 multiplexers

Carry logic

MULT_AND

Multipliers and counters using the

DSP48

Global clock buffers (BUFG)

SelectIO (single-ended) interface

I/O registers (single data rate)

Input DDR registers

Can be inferred by some synthesis

tools

Memories

Global clock buffers (BUFGCE,

BUFGMUX, BUFGDLL)

Some complex DSP functions

Cannot be inferred by any synthesis

tools

SelectIO (differential) interface

Output DDR registers

DCM / PLL

Local clock buffers (BUFIO, BUFR)


Suggested Instantiation

Xilinx recommends that you instantiate the following elements

Memory resources

Block RAMs specifically (use the CORE Generator software to build large

memories)

SelectIO interface resources

Clocking resources

DCM, PMCD (use the Architecture Wizard)

IBUFG, BUFGMUX, BUFGCE

BUFIO, BUFR


6/27


Why does Xilinx suggestthis?

Easier to port your HDLto other and newertechnologies

Fewer synthesisconstraints andattributes to pass on

Keeping most of theattributes and constraints in the Xilinx User Constraints File (UCF) keeps itsimpleone file contains critical information

Create a separate hierarchical block for instantiating these resources Above the top-level block, create a Xilinx wrapper with instantiations specific

to Xilinx

Top-Level

Block

Top-Level

Block

BUFGDCMIBUFG

Xilinx wrapper top_xlnx

IBUF _SSTL2_I

OBUF _GTL

OBUF _GTL

OBUF _GTL

STARTUP

Suggested Instantiation


Hierarchy Management

Synplify, Precision, and XST software

The basic settings are

Flatten the design: Allows total combinatorial optimization across all

boundaries

Maintain hierarchy: Preserves hierarchy without allowing optimization of

combinatorial logic across boundaries

If you have followed the synchronous design guidelines, use the setting

-maintain hierarchy

If you have not followed the synchronous design guidelines, use thesetting -flatten the design

Your synthesis tool may have additional settings

Refer to your synthesis documentation for details on these settings


7/27


Hierarchy Preservation

Benefits

Easily locate problems in the code based on the hierarchical instance

names contained within static timing analysis reports

Enables floorplanning and incremental design flow

The primary advantage of flattening is to optimize combinatorial logic

across hierarchical boundaries

If the outputs of leaf-level blocks are registered, there is generally no need

to flatten


Outline




Register Inference


Pipelining

Summary


8/27


Multiplexers

Multiplexers are generated from IF and CASE statements

IF/THEN statements generate priority encoders

Use a CASE statement to generate complex encoding

There are several issues to consider with a multiplexer

Delay and size

Affected by the number of inputs and number of nested clauses to an IF/THEN

or CASE statement

Unintended latches or clock enables

Generated when IF/THEN or CASE statements do not cover all conditions

Review your synthesis tool warnings

Check by looking at the component with a schematic viewer


IF/THEN Statement Answer

Priority Encoder

Most critical input listed first

Lease critical input listed last

do_c

do_e

cond_ccond_b

do_b

cond_a

do_a

crit_sig

do_d

oput1

0

1

0

1

01

0

IF (crit_sig) THEN oput


9/27


Avoid Nested IF and IF/ELSE

Statements

Nested IF or IF/THEN/ELSE statements form priority encoders

CASE statements do not have priority

If nested IF statements are necessary, put critical input signals on the

first IF statement

The critical signal ends up in the last logic stage


CASE Statements

CASE statements in a combinatorial process (VHDL) or always

statement (Verilog)

Latches are inferred if outputs are not defined in all branches

Use default assignments before the CASE statement to prevent latches

CASE statements in a sequential process (VHDL) or always statement

(Verilog)

Clock enables are inferred if outputs are not defined in all branches

This is not wrong, but might generate a long clock enable equation

Use default assignments before CASE statement to prevent clock enables


10/27


CASE Statements

Register the select inputs if possible (pipelining)

Can reduce the number of logic levels between flip-flops

Consider using one-hot select inputs

Eliminating the select decoding can improve performance

Determine how your synthesis tool synthesizes the order of the select

lines

If there is a critical select input, this input should be included last in the

logic for fastest performance


CASE Statement This Verilog code describes a 6:1

multiplexer with binary-encoded

select inputs

This synthesized to 3 LUTs and 2

F5 muxes

Longest path = 1 LUT + 2 F5

The advantage of using the dont

care for the default, is that the

synthesizer will have more flexibility

to create a smaller, faster circuit

How could the code be changed

to use one-hot select inputs?

module case_binary (clock, sel, data_out, in_a,

in_b, in_d, in_c, in_e, in_f) ;

input clock ;input [2:0] sel ;

input in_a, in_b, in_c, in_d, in_e, in_f ;output data_out ;

reg data_out;

always @(posedge clock)begin

case (sel)

3'b000 : data_out


11/27


CASE Statement

This is the same code with one-hot

select inputs

This synthesized to 8 LUTs and 1

F5 mux

Longest path = 2 LUTs + 1 F5

This yields no benefit for 6-1 mux,

but when you get larger the benefit

is significant

module case_onehot (clock, sel, data_out, in_a,in_b, in_d, in_c, in_e, in_f) ;

input clock ;

input [5:0] sel ;input in_a, in_b, in_c, in_d, in_e, in_f ;

output data_out ;

reg data_out;

always @(posedge clock)begin

case (sel)

6'b000001 : data_out


12/27


Synchronous Design

Rewards

Always make your design synchronous Recommended for all FPGAs

Failure to use synchronous design can potentially Waste device resources

Not using a synchronous element will not save silicon and it wastes money

Waste performance Reduces capability of end products; higher speed grades cost more

Lead to difficult design process Difficult timing specifications and tool-effort levels

Cause long-term reliability issues Probability, race conditions, temperature, and process effects

Synchronous designs have Few clocks

Synchronous resets No gated clocks; instead, clock enables

KenChapman

(XilinxUK) 2003


Outline




Register Inference


Pipelining

Summary


13/27


Inferred Register Examples

always @(posedge CLOCK)

Q = D_IN;

always @(posedge CLOCK

or posedge RESET)

if (RESET)

Q = 0;

else

Q = D_IN;

always @(posedge CLOCK or

posedge PRESET)

if (PRESET)

Q = 1;

else

Q = D_IN;

always @(posedge CLOCK)

if (RESET)

Q = 0;

elseQ = D_IN;

Ex 1 D Flip-Flop

Ex 3. D Flip-Flop with Asynch Reset

Ex 2. D Flip-Flop with Asynch Preset

Ex 4. D Flip-Flop with Synch Reset


Clock Enables

Coding style will determine if clock enables are used

VHDLFF_AR_CE: process(ENABLE,CLK)

begin

if (CLKevent and CLK = 1) then

if (ENABLE = 1) then

Q


14/27


Outline




Register Inference


Pipelining

Summary


State Machine Design

S1

S5 S4

S3

S2

State

Machine

Module

Inputs to FSM

Next-state logic

State register

State machine outputs

HDL Code

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


15/27


The Perfect State Machine

The perfect state machine has

Inputs: Input signals and state jumps

Outputs: Output states and control and enable signals to the rest of the

design

NO arithmetic logic, datapaths, or combinatorial functions inside the state

machine

State

JumpsOnly!Input Signals

Next State

Current State Feedback to Drive State Jumps

StateReg

ister

Output State and Enables


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


16/27


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


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;

always @(posedge clock or posedge reset)beginif (reset)begincurrent_state


17/27



(Verilog)always @ (current_state or signal_a or signal_b)begincase (current_state)s0: if (signal_a)

next_state = s0;else

next_state = s1;s1: if (signal_a && ~signal_b)

next_state = s4;elsenext_state = s2;

s2: next_state = s4;s3: next_state = s3;s4: next_state = s0;default: next_state = bx;endcase

endend

endmodule


Binary Encoding

(Verilog)reg [3:0] current_state, next_state;

parameter state1 = 2b00, state2 = 2b01,

state3 = 2b10, state4 = 2b11;

always @ (current_state)

case (current_state)

state1 : next_state = state2;




endcase

always @ (posedge clock)

current_state = next_state;


18/27


One-Hot Encoding

(Verilog)reg [4:0] current_state,next_state;

parameter state1 = 4b0001, state2 = 4b0010,state3 = 4b0100, state4 = 4b1000;

always @ (current_state)

case (current_state)





endcase

always @ (posedge clock)

current_state = next_state;



(VHDL)library IEEE;use IEEE.std_logic_1164.all;

entity STATE isport (

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 istype STATE_TYPE is (s0,s1, s2, s3);signal current_state, next_state: STATE_TYPE;signal usually_zero_comb, usually_one_comb : STD_LOGIC;begin


19/27



(VHDL)COMB_STATE_MACHINE: process(current_state, signal a , signal b)beginnext_state


20/27


Unspecified Encoding

(VHDL)entity EXAMPLE isport( 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( CLOCKevent and CLOCK = 1) thencase STATE iswhen S1 =>X


21/27


Outline




Register Inference


Pipelining

Summary


Pipelining Concept

D QfMAX =

n MHz

fMAX

2n MHz

two logic levels

one

level

one

level

D Q

D Q D Q D Q


22/27


Pipelining

Three situations in which to pipeline

Register the outputs of each lower leaf-level output

Typically done after timing analysis

Can easily be done for purely combinatorial components

Register I/O

Usually done by the designer from the beginning

Register high-fanout secondary control signals (Set, Reset, CEs)


Performance by Design

KenChapman

(XilinxUK) 2003

Code A

Code B

Two levels of logic (connections

dominate)

May require higher speed grade,

adding cost

Switch

Enable

reg_data

reg_enable

data_inD Q

CE

D Q

D Q

Switch

Enablereg_datadata_in

D Q

D Q

CE

D Q

D Q

High fanout

One level of logic

Maximum time for routing of

high fanout net Flip-flop adds nothing to the

cost

High fanout

Tip: Remember that the LUT output feeds the D input to the flip-flop


23/27


Performance by Design

(Verilog)

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 A Code B

always @(posedge clk)

begin

if (switch && enable)

reg_data


24/27


Outline




Register Inference


Pipelining

Summary


Apply Your Knowledge

What is the approach presented here for obtaining breakthrough

performance?

Compare CASE and IF/THEN statements when creating multiplexers

What problem occurs with nested CASE and IF/THEN statements?


25/27


Answers

What is the approach presented here for obtaining breakthroughperformance?

Three steps to achieve breakthrough performance

1. Utilize embedded (dedicated) resources

Performance by construction

DSP48, FIFO, block RAM, ISERDES, OSERDES, PowerPC processor,EMAC, and MGT, for example

2. Write code for performance

Pipeline

Xilinx FPGAs have abundant registers: one register per LUT

3. Drive your synthesis tool

Apply full and correct constraints Utilize optional settings

Use High effort


Answers

Compare CASE and IF/THEN statements when creating multiplexers

Both types of statements produce multiplexers

CASE statements produce smaller/faster circuits in general

IF/THEN statements are more flexible but create a priority encoder

IF/THEN statements may be faster for late arriving signals

What problem occurs with nested CASE and IF/THEN statements?

Nested CASE and IF/THEN statements can generate long delays due to

cascaded functions


26/27


Summary

Use as much of the dedicated hardware resources as possible to ensure

optimum speed and device utilization

Plan on instantiating clocking and memory resources

Try to use the Core Generator tool to create optimized components that

target dedicated FPGA resources (BRAM, DSP48, and FIFO)

Maintain your design hierarchy to make debugging, simulation, and

report generation easier

CASE and IF/THEN statements produce different types of multiplexers

CASE statements tend to build logic in parallel while IF/THEN statements

tend to build priority encoders

Avoid nested CASE and IF/THEN statements


Summary

You should always build a synchronous design for your FPGA

Inferring many types of flip-flops from HDL code is possible

Synchronous sets/resets are preferred

When coding a state machine, separate the next-state logic from statemachine output equations

Evaluate whether you need to use binary, one-hot, or Gray encoding

style for your FSM

This will yield a smaller and/or faster FSM

Pipeline data paths to improve speed


27/27


Where Can I Learn More?

Synthesis & Simulation Design Guide

www.xilinx.com/support Documentation Search forSynthesis &

Simulation Design Guide

User guides

www.xilinx.com/support Documentation Search forUser Guides

XST User Guide

www.xilinx.com/support Documentation Search forXST

This guide has example inferences of many architectural resources

ISE online help

Start Xilinx ISE 10.1i Documentation Software Manuals

Documents

Basic HDL Coding Tech