PPTX

Report
Virtex-5 FPGA HDL Coding Techniques
Part 1
Intro to VHDL or
Intro to Verilog
3
days
FPGA and ASIC Technology
Comparison
Curriculum
Path
FPGA vs. ASIC Design
Flow
ASIC to FPGA
Coding
Conversion
Virtex-5 FPGA
Coding Techniques
Spartan-3 FPGA
Coding Techniques
Fundamentals of
FPGA Design
Designing for
Performance
for
1
day
2
days
Advanced FPGA
Implementation
ASIC Design
2
days
Welcome
This training will help you build efficient Virtex®-5 FPGA designs
that have an efficient size and run at high speed
We will show you how to avoid some of the most common design
mistakes
This content is essential if you have never coded a design for the
Virtex-5 FPGA or are converting an ASIC design
Objectives
After completing this module, you will be able to:
Optimize ASIC code for implementation in a Virtex-5 FPGA
Build a checklist of tips for optimizing your code for the Virtex-5
FPGA
Introduction
There is no single “perfect” way to create a design
– Different synthesis options and implementation
options will lead to different results
• One method will NOT work best in all cases
– The coding techniques described here are strongly recommended
because they have the biggest impact on device utilization and speed
There are however guidelines that usually lead
to improved results
Tactics to Meet Timing
As always, use as many of the dedicated resources as
possible (SRLs, DSP48s, and block RAMs)
Different tactics must be used when your device is full
– Timing does not matter if your design does not fit in the
device
– The tactics that will be discussed generally work best in
designs that are not full
One of the most effective ways to reduce power in
FPGAs is to reduce the number of resources
– One of the side benefits of these techniques is that they will
allow you to improve performance and reduce power
Limiting Virtex-5 FPGA Resources
Build a design that uses fewer “limiting” resources
– Fewer registers
• Many designs run out of registers before other components (especially if the
design is heavily pipelined)
• Registers are most often the limiting resource in Virtex-5 designs
– Fewer LUTs
• The LUT6 is 40 percent more efficient than a LUT4
 But this does not yield performance benefits for every design
Virtex-5 FPGA Registers
Why are registers sometimes a scarce resource?
– The Virtex-5 FPGA has ~30 percent fewer registers for a given logic or
array size compared to the Virtex-4 FPGA
• The 4VLX80 device has 71,680 slice flip-flops versus 51,840 for a 5VLX85
device
• So you should NOT need to pipeline as much!
– Be aware of control signal limitations (this will be covered later)
– Lack of use (inference) of SRLs, block RAMs, and DSP slice resources
– Replication of registers (logic replication)
• Careful use of synthesis options that may increase your design size is important
Introduction to Control Sets
A control signal is
–
–
–
–
–
–
Clock Enable / Gate Enable
Write Enable
Set / Preset
Reset / Clear
Clock / Gate
Slice: WE, CE, SR, REV, CLK
A control set is
– A group of enable, set, reset,
and clock
• This includes Vcc / Gnd when
they are not used
Unique control sets are
– The number of groups of unique control signals that your design has
Tip: The implementation tools cannot group flip-flops into the same slice if
they do not share the same control signals
What Creates Control Signals?
Control signals are the signals that are connected to the actual
control ports on the register
Inference code
– Clocks and asynchronous set/resets always become control signals
• They cannot be moved to the datapath
– Clock enables and synchronous set/resets sometimes become control
signals (this is decided by the synthesis tool)
• These control signals can be moved to the datapath
– How will a global asynchronous reset and a local reset inferred on a single
register be implemented?
• Asynchronous reset gets the port on the register
• Synchronous reset gets a LUT input
Tip: Clock enables and synchronous sets and resets can be moved to the
datapath
What Creates Control Signals?
Instantiation of primitives and cores
– Gate-level connection of UNISIM and core primitives dictates control signal
usage
Synthesis optimization
– Synthesis may choose to build a control signal for logic optimization
Physical synthesis
– Can change control sets from original specifications
– Global or logic optimization may choose to build a control signal for logic
optimization
Tip: The instantiations of cores you make should share the same control
signals you infer to minimize the number of control sets
Why Be Concerned?
Four registers per slice; all share the
same control signals
– If the number of registers in the control
set do not divide cleanly by four, some
registers must go unused
This is of concern for designs that
have several very low fanout control
signals
A design with a large number of control
sets potentially can show lower
utilization
of registers (but not always)
Tip: Try to build in byte-wide widths for the highest device utilization
What Designs Are Okay?
Designs with plenty of flip-flops to spare
– Designs with low flip-flop-to-LUT ratios
• These are generally slow or lightly pipelined designs or ASIC prototypes
– Designs with lots of room in a particular device
Designs with a small number of control sets are preferable
– The key is to evaluate slices and CLBs that have wasted registers
– Try to build designs with common control signals (plan)
Designs with datapaths divisible by four are not affected even if
they have a high number of control sets
– Such as byte-wide enables or data control registers, for example
Active-Low Control Signals
Problem: Active-low control signals can produce sub-optimal
results
Why?
– Control ports on Virtex-5 FPGA registers are active-high
– Hierarchical design methods
This results in…
– Poorer utilization
• More LUTs
• Less dense slice packing
• More routing resources necessary
– Longer run times
• Prohibits hierarchical design flows
• More difficult timing
– Worse timing and power
Tip: Use active-high signals for CEs, sets, and resets
Use Active-High Control Signals
Flip-Flop
The inverters
cannot be
combined into
the same slice
This consumes
more power and
makes timing
difficult
Hierarchical design methods can proliferate LUT usage
on active-low control signals
Why Synchronous Resets?
Each DSP48E has ~250 registers; none have asynchronous
reset
The DSP slice is more versatile than most realize
– The XC5V50 device has ~12,000 DSP slice registers
– The XC5V330 device has ~48,000 DSP slice registers
– Can be used for multipliers, add/sub, MACC, counters (with
programmable terminal count), comparators, shifters, multiplexer,
pattern match, and many other logic functions
Many design that run out of slices are not fully utilizing the
DSP48E
– Synthesis tools will infer the DSP48E for multipliers, but they are not
smart enough to infer other functions
• Can control synthesis use with attributes, but NOT if an asynchronous reset
is used
Tip: Use sync reset when using the DSP slice resources
Why Synchronous Resets?
Block RAMs obtain minimum clock-to-output time by using the output
registers
– Output registers only have synchronous resets
Unused block RAMs can be used for many alternative purposes
– ROMs, large LUTs, complex logic, state machines, deep-shift registers, etc.
Using unused block RAMs for other purposes can free up hundreds of flipflops
– Using the block RAM in dual-port mode allows for greater utilization of this
resource
Many designs that run out of slices are not fully utilizing the block RAM
resources
– Synthesis tools are not yet smart enough to infer less obvious functions
Tip: Use sync reset when using the block RAM resources
Why Synchronous Resets?
Synthesis could choose to move low-fanout synchronous resets
from a control signal to the datapath to free up more registers
– Synthesis tools can do this, but it may depend on synthesis settings (may
not be on by default)
– The Xilinx implementation tools cannot change what is synthesized
This could allow packing of this register into a slice previously
not possible
– Can improve timing as well as register density
S
D
Low
Fanout
Why Synchronous Resets?
Synchronous resets are automatically timed
– Do not need any special timing constraints
– Do not need special switches or setting to analyze timing
Synchronous resets are inherently more predictable
– Less susceptible to accidentally missing timing, runt pulses, or other
phenomenon from upsetting logical functionality
– Less prone to a race condition
• Release of an asynchronous signal may not always have predictable results
Tip: Synchronous resets enable your design to need
minimal testing
Caveats to Synchronous Resets
Synchronous resets may make timing more difficult, the design
larger, and result in longer run times
Why?
– The implementation tools automatically time synchronous reset paths
– This can result in
• More timing paths to analyze and meet timing
 On average ~five percent increase in the number of timing paths
• More replication of design resources
• With some synthesis tools this will use fewer SRLs, block RAM, DSP48s, and
other dedicated hardware
Changing to Synchronous Resets
All new code should use synchronous resets when a reset is
necessary
For existing code, you have three choices
– Leave alone
• Acknowledge the possible drawbacks of asynchronous resets
– Use synthesis switch
Synplify:
syn_clean_reset
XST:
-async_to_sync YES
• Not the same as changing to synchronous reset but can help
– Manually (or use a script) to change the asynchronous reset to
synchronous
– Removing the top-level reset port does not get the same result
• Remove the reset from your code
No Resets is Best
Resets
Why No Resets at All?
Using synchronous logic frees up additional logic
Designs in which the resets were removed resulted in an
average of 3 ½ percent fewer registers
Synthesis can realize this additional logic automatically
Tip: This makes it easier for the mapper to group this register with
registers of a different control set
Why No Resets at All?
Synthesis can infer SRL-based shift registers
– But only if no resets are used (otherwise flip-flops are wasted)
– Or, the synthesis tool can emulate the reset (not what you want)
The SRL is also useful for synchronous FIFOs, non-binary
counters, terminal count logic, pattern generators, and
reconfigurable LUTs
Tip: NO reset saves a lot of flip-flops
Why No Resets at All?
Routing can be considered one of the most valuable resources
Resets compete for the same resources as the rest of the active
signals of the design
– Including timing-critical paths
– More available routing gives the tools a better chance to meet your timing
objectives
Tip: NO reset
saves routing and
improves design
speed
Why No Resets at All?
Even more block RAM inference
Why?
– Virtex-5 FPGA RAMs
• RAM enable has precedence over reset
– Virtex-5 FPGA registers
• Reset has priority over the clock enable
– Coding for this functionality makes no sense
– With no reset, the enable precedence has no consequence
Tip: NO reset gets more block RAMs
Why No Resets at All?
Designs without resets have fewer timing paths
– By an average of 18 percent fewer timing paths
Results in less run time
Improved performance
Less memory necessary during PAR
Tip: NO reset builds a faster design and saves run time
How Do I Get By?
Some designs can get away without any resets but many designs
need some resets
– Very few designs require resets on all registers
• Most ASICs require a described reset on every register.
• Implement this with the built-in Global Set/Reset (GSR)
Suggestion
– Be selective when you code resets (FSMs, I/O, and flushing data)
• Only place resets that have impact on functionality
How Do I Get By?
Initialize all registers in VHDL / Verilog code
– This should be done whether using a reset or not
VHDL:
signal my_regsiter : std_logic_vector (7 downto 0) := (others <= ‘0’);
Verilog:
reg [7:0] my_register = 8’h00;
Perform RTL simulation of the design
– If it functions during simulation, it should function on the FPGA
Summary
If your design barely fits, Xilinx recommends reducing the size of
your design before trying to gain timing closure
– Most of these tips reduce design size
Try to minimize the number of control sets your design uses
Asynchronous resets can inhibit optimization of general logic
(can force additional LUT inputs to be used)
Synchronous resets allow synthesis tools to convert a control
signal reset to the datapath
Avoid the use of global resets
– Initialize all registers from your HDL
– If you have to, use the Startup_Virtex5 primitive to access the GSR net
Summary (continued)
Xilinx recommends NOT using the synthesis option to convert
asynchronous resets to synchronous
Avoid resets on SRLs (no reset functionality)
Avoid asynchronous resets on block RAMs (the block RAM’s
output register only supports a synchronous reset)
Avoid asynchronous resets on DSP slice resources (their flipflops only support a synchronous reset)
Be aware of the difference between coding for a block RAM’s
control signal precedence and a flip-flop’s precedence
Use active-high control signals
If you can design out your global reset, you will save a lot of
routing and build a faster design
Where Can I Learn More?
Xilinx Online Documents
– support.xilinx.com
• To search for an Application Note or White Paper, click the Documentation tab
and enter the document number (WP231 or XAPP215) in the search window
• White papers for reference
 WP231 – HDL Coding Practices to Accelerate Design Performance
 WP248 – Retargeting Guidelines for Virtex-5 FPGAs
 WP275 – Get your Priorities Right – Make your Design Up to 50%
Smaller
• User guides for reference
 UG193 - Virtex-5 FPGA XtremeDSP Design Considerations
Additional Online Training
– www.xilinx.com/training
Virtex-5 FPGA HDL Coding Techniques
Part 2
Intro to VHDL or
Intro to Verilog
3
days
FPGA and ASIC Technology
Comparison
Curriculum
Path
FPGA vs. ASIC Design
Flow
ASIC to FPGA
Coding
Conversion
Virtex-5 FPGA
Coding Techniques
Spartan-3 FPGA
Coding Techniques
Fundamentals of
FPGA Design
Designing for
Performance
for
1
day
2
days
Advanced FPGA
Implementation
ASIC Design
2
days
Welcome
This training will help you build efficient Virtex®-5 FPGA designs
that have an efficient size and run at high speed
We will show you how to avoid some of the most common design
mistakes
This content is essential if you have never coded a design for the
Virtex-5 FPGA or are converting an ASIC design
Objectives
After completing this module, you will be able to:
Optimize ASIC code for implementation in a Virtex-5 FPGA
Build a checklist of tips for optimizing your code for the Virtex-5
FPGA
Clock Enable
Control the use of clock enables from the code
– Code them only when needed
– If a low-fanout CE is necessary, use synthesis attributes to control the use
of control signals at the signal or module level
• Do not use global switches to turn off the use of CEs
 Results in an average of 25-percent LUT increase
– Consider using alternative coding methods for low-fanout clock enables
• This will map the CE as an input to the LUT
VHDL:
if (CE) then
Q <= A;
Verilog:
if (CE)
Q <= A;
VHDL:
Q <= ((not CE) AND A) OR (CE AND Q);
Verilog:
Q <= (~CE & A) | (CE & Q);
Tip: Code low-fanout CEs for a LUT input. This will enable the
flip-flop to be part of a larger control set
Map Report
MAP will report on the number of control sets for a particular
design (Virtex-5 FPGA only)
Running MAP with the -detail switch will give a detailed analysis
of the number of unique control signals (can be a large report)
Low number of members within a control set are of concern
(fewest flip-flops per control set)
Global Clock Enable
To gate entire clock domains for power reduction, use the clockenabled global buffer resource BUGCE
– For applications that only pause the clock on small areas of the design,
use the clock enable pin of the FPGA register
Tip: This will save general routing resources
DSP Slice
Use adder chains instead of adder trees
– Adder trees tend to have varying size
• This usually makes larger adders in the last stages, which increases logic
levels
– The Virtex-5 FPGA uses adder chains which obtain peak performance
and use minimal power
• Requires pipelining
• Adds latency
Adder
Chain
Adder
Tree
Tip: Use adder chains instead of adder trees
Block RAM
Avoid “read before write” mode for fastest performance
– This is easily inferred from your coding style of your memory or by
instantiation from the CORE Generator™ tool
Synplify and other third-party synthesis tools can insert
bypass logic to prevent a possible mismatch error between
your RTL and hardware behavior
– Intended to force RAM outputs to a known value when read and write
operations occur on the same memory cell
– If you know this will never happen you can prevent this logic from being
added and damaging your performance with an attribute
• Attribute syn_ramstyle of mem : signal is “no_rw_check”;
Tip: Infer or instantiate the memory that is most appropriate
I/O Registers
IOB registers provide fixed setup and clock-to-output times
–
Fastest way to capture input data and clock data off the
device
IOB register can make it difficult to meet internal timing
–
Their use can lengthen route delays to internal logic
–
Only use IOB registers when it is necessary to meet I/O
timing
•
It is best to allow your synthesis tool to put registers into
IOBs based on timing constraints (if your tool supports
this).
•
Otherwise complete the following steps…
1) Disable global I/O register usage in your synthesis tool
2) Disable the Map option to pack registers into IOBs (PAR)
3) Selectively move registers into IOB with a UCF attribute
Tip: Only use IOB registers when necessary to meet I/O timing
Design Hierarchy
Register all inputs and outputs to each hierarchical block
– Or at least register the outputs
Place all I/O components at the top level
– This includes I/O registers, DDR, SERDES, and delay elements
– If not, place them in one block of hierarchy
Any logic that needs to be placed in a single resource (such as a
single DSP slice) should be contained in a single hierarchical
block
Any logic that needs the synthesis tool to use resource sharing
should be placed in a single hierarchical block
Manually duplicate registers with high fanout at a hierarchical
boundary
Tip: Following these guidelines ensures that your design is
less likely to interfere with design optimization and
incremental design practices
Synthesis Options
Replicate registers with high fan-out
– This allows high fan-out logic to be moved closer to destinations
– This can be determined from a timing report
– Manual duplication or replication constraints with the synthesis tools
should be applied
Retiming option should be used, especially if design has been
pipelined
– Pipelining is still encouraged, but not as essential
Tip: Duplicate high fan-out logic, pipeline as needed, and if
you pipeline use retiming
Synthesis Options
Overconstraining during synthesis can significantly increase
register use
– Seen as an average increase from 1–5 percent
– Do NOT over-constrain during synthesis
Global optimization can lead to mixed results
– Can achieve ~10 percent flip-flop reduction
• Gives back much of that (and sometimes more) due to control signals
FSM optimization
– Turning off FSM optimization can yield a small flip-flop savings
– One-hot encoding is not as useful
Do NOT use slice or LUT compression switches
– In some cases, latch-thrus are used and consume registers
Tip: Do NOT over-constrain and do NOT use slice or LUT
compression
Synthesis Options Summary
To help meet your timing objectives…
– Turn ON logic replication and retiming
– Turn OFF resource sharing
– Turn ON logic optimization (widening deep data paths)
– Turn OFF FSM optimization
– Do NOT over constrain during synthesis
– Do NOT use slice or LUT compression switches
– These synthesis options make the design larger, but save
FFs and give the PAR algorithms more flexibility to meet
timing
Easiest Designs to Migrate to the
Virtex-5 FPGA
Designs that can utilize the new hard IP
– EMAC, DSP slice, block RAM, PowerPC® 440 processor, and PCI™
technology, for example
Low-power designs that use the dedicated IP
“Slow” designs
– Designs with several LUT levels generally see greater speed due to the
LUT6 and improved routing architecture
Tip: Add as much IP to your design as you can
Toughest Designs to Migrate to the
Virtex-5 FPGA
Structural designs
– Designs that have not been coded properly (as just discussed)
– Designs that have NOT been resynthesized
– Designs that use many old netlists and cores from previous architectures
Some types of DSP designs
Heavily pipelined designs
What is in common?
– They were not optimized!
Tip: Use the coding techniques described in these recorded
modules and you will yield the high speed design you hoped
Common Questions
“Why can’t I code how I want to?”
– You can. As long as it is synthesizable (RTL), Xilinx can build it. This
module highlights some of the lesser known trade-offs of coding styles in
terms of area, power, and performance.
“Shouldn’t the tools be able to make my code optimal?”
– Some coding styles make this more difficult
• While FPGAs are programmable, the underlying dedicated hardware is fixed
Common Questions
“The Virtex-5 FPGA should always be a speed grade faster than
the Virtex-4 FPGA, right?”
– No, this is not always true, particularly for heavily pipelined designs.
“This design easily fit in the Virtex-4 FPGA and now it can’t fit in
the Virtex-5 FPGA. What’s wrong?”
– Check how many control sets your design has. If you have too many, you
may need to evaluate your use of control signals. Also, check that your
cores and use of the dedicated hardware is optimal.
“Why can’t the software just optimize my inverters across a
partition?”
– Remember that partitions are there to preserve hierarchy and parts of your
design. Allowing any tool to selectively remove an option is
counterintuitive.
Summary
Follow our synthesis recommendations…
– Turn ON logic replication and retiming
– Turn OFF resource sharing
– Turn ON logic optimization (widening deep data paths)
– Turn OFF FSM optimization
– Do NOT over constrain during synthesis
– Do NOT use slice or LUT compression switches
Be careful with coding unnecessary clock enables
IOB registers can make it more difficult to meet internal timing
– Follow our directions to use the IOB registers only for IO timing
Follow our guidelines to ensure that your design does not
interfere with design optimization and incremental design
practices
Where Can I Learn More?
Xilinx Online Documents
– support.xilinx.com
• White papers for reference
 WP231 – HDL Coding Practices to Accelerate Design Performance
 WP248 – Retargeting Guidelines for Virtex-5 FPGAs
 WP275 – Get your Priorities Right – Make your Design Up to 50%
Smaller
• User guides for reference
 UG193 - Virtex-5 FPGA XtremeDSP Design Considerations
• Software Manuals (found from the web or the Help menu)
 Constraints Guide
Additional Online Training
– www.xilinx.com/training
Trademark Information
Xilinx is disclosing this Document and Intellectual Property (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.
© 2012 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.

similar documents