Virtex-6 and Spartan-6 HDL Coding Techniques
Xilinx Training
Welcome
If you are new to FPGA design, this module will help you code
properly for Spartan-6 and Virtex-6 register resources
These design techniques promote fast and efficient FPGA
designs
Page 2
Objectives
After completing this module you will be able to…
Code your register resources so your design will have fewer
control sets and run at a higher system speed
Avoid the most common coding mistakes that reduce device
utilization and system speed
Anticipate how your design will map to the register resources
Page 3
Introduction
There is no single “perfect” way to create a design
– The coding techniques described here are strongly
recommended because they reduce the device utilization and
this enables the implementation tools to obtain a better place
and route solution
• A better PAR solution gets better system speed
There are however guidelines that usually lead
to improved results
Page 4
Tactics to Meet Timing
Use as many of the dedicated resources as possible
(SRLs, DSP slices, and block RAMs)
– Clever use of unused dedicated resources can improve
system speed, reduce power, and improve device utilization
(for example, using block RAM for a FSM)
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 LUTs and FFs
– One of the side benefits of these techniques is that they will
allow you to improve performance and reduce power
– Try turning off the Logic Replication synthesis option
Page 5
Limiting FPGA Resources
Spartan-6, and Virtex-6 devices use a 6-input LUT, which allows
you to pack more logic into your LUT
– However, synthesis tools cannot remove added pipeline registers, so if
your design is migrating you will have to recode your design
Build a design that uses 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 Spartan-6 and Virtex-6,
so try to use as much of the SRLs, RAM, and DSP slice resources as
possible
Page 6
FPGA Registers
Why are registers sometimes a scarce resource?
– Control signal limitations that limit grouping of slice resources (this will
be covered later)
– Coding for active high control signals
• Active low is not recommended for FPGAs
• Active low control signals do not save power
– Inappropriate replication of registers (logic replication)
• Careful use of synthesis options that may increase your design size is
important
Page 7
Control Signal Usage is a Concern
Eight registers per slice; all share the same
control signals
– If the number of registers in the control set do not
divide cleanly by eight, some registers may go
unused
– This will depend on the remaining registers in the
design being grouped into the same slice, which is
determined by the remaining registers use of control
signals
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 device utilization
(but not always)
Designs with a small number of control sets
are preferable
– The key is to evaluate slices and CLBs that have
wasted registers
Page 8
Flip-Flop Details
Each flip-flop has four control ports
FF
– D – data input
– CK – clock
– CE – clock enable (Active High)
– SR – async/sync set/reset (Active High)
• Either Set or Reset can be implemented (not both)
All eight flip-flops share the same control signals
– CK – clock
– CE – Clock Enable
– SR – Set/Reset
Page 9
D
CE
CK
Q
SR
Software
Software intelligently packs logic
Design
FPGA
Slice
LUT
LUT
LUT
LUT
Related logic and flip-flops are coded
Software places the logic and flip-flop in the same slice
Software packs slices for optimum performance
Page 10
Flip-Flops – Control Signals
Different flip-flop configurations
– If coded registers do not map cleanly to Virtex-6/Spartan-6 FPGA flipflops, the software tools will automatically implement the missing
functionality by using additional slice resources
– Can increase overall LUT utilization
Case
CE active Low
Design
D
CE
CK
Q
FPGA
D
CE
Q
D
CK
Both Synchronous Set and
Reset are used
D
CK
Q
Sset
SReset
D
D
Sset
SReset
Software uses logic to map extra control functions
Page 11
SR
CK
Q
Control Set Reduction
Flip-flops with different control sets cannot be packed into the
same slice
Software can be instructed to reduce the number of control sets
by mapping control logic to LUT resources
– This results in higher LUT utilization, but a lower overall slice utilization
Page 12
Design
FPGA
Q
D
CK
Q
D
Q
CK
Sset
D
Sset
D
CK
Q
D
Q
CK
SReset
D
SReset
D
CK
Q
1 Slice
3 Slices
D
CK
LUT – Combining
Design
LUT6_2
LUT5
f1
LUT5
f2
Two 5-input functions with common inputs


FPGA
Two 5-input functions maps to two LUTs
Both LUTs share the same input signals
LUT5
f1
LUT5
f2
LUTs are combined into the same slice

LUTs that share common inputs will be
packed into the same slice
Related logic packed into single LUT
Page 13
connections
Shared Inputs
LUTs with common input signals
SRL – Combining
SRLs with common input signals
Design
FPGA
LUT6_2
SRL16
SRL16
SRL16
LUT5
SRL16
Two SRL16 on a bus with common
inputs

Two SRL16 are used

Both SRL16 share the
same input signals
LUTs are combined into the same Slice

LUTs that share common inputs
will be packed into the same
slice
Related SRL packed into single LUT
Page 14
connections
LUT5
Introduction to Control Sets
A control signal is
–
–
–
–
–
Clock Enable / Gate Enable
Write Enable
Set / Reset
Preset / Clear
Clock / Gate
A control set is
– A group of enable, set, reset,
and clock
Unique control sets are
– The number of groups of unique control signals in your design
The implementation tools cannot group flip-flops
into the same slice if they do not share the same
control signals
– However the tools can pack FFs into the slice if the control
signals all come from the same set (next slide)
Page 15
Question
Can these FFs be placed into the same slice (are they a part
of the same control set)? (Note…all control signals drive
the control port of the FF)
– Case 1
• FF1: CE, Set, Reset
• FF2: Set, Reset
• FF3: Reset
– Case 2
• FF1: CE, Set, Reset
• FF2: Set2, Reset
– Case 3
• FF1: CE, Set, Reset
• FF2: Set, not Reset
Page 16
Answer
– Case 1…
•
•
•
•
FF1: CE, Set, Reset
FF2: Set, Reset
FF3: Reset
Yes! The tools can pack FFs into the slice if the control signals all come from the
same set.
– Case 2…
• FF1: CE, Set, Reset
• FF2: Set2, Reset
• No, two different sets cannot be grouped into the same slice. Same is true for CEs
and the other control signals.
– Case 3…
• FF1: CE, Set, Reset
• FF2: Set, not Reset
• Maybe, if the Reset is synchronous then your synthesis tool should be able to drive
the reset to a LUT input and invert the reset signal.
– Note…if the control signal can be implemented as a LUT input (synchronous
set, synchronous reset, or CE) then the tools have more flexibility to group
those FFs into the same slice.
Page 17
Control Port Usage Rules
Control signals are the signals that are connected to the actual control
ports on the register
Clocks and asynchronous set/resets always become connected to FF
control ports
– They cannot be moved to the datapath
Clock enables and synchronous set/resets sometimes become
connected to FF control ports (this is decided by the synthesis
tool)
– These control signals can be moved to the datapath (to a LUT input)
Asynchronous sets/resets have priority access to the control ports over
synchronous sets/resets
– For example…If a global asynchronous reset and a local reset are inferred on a
single register…
• The asynchronous reset gets the port on the register
• The synchronous reset gets a LUT input
• There is no coding style or synthesis option that allows users to control when a LUT will be
used for this purpose
Tip: Clock enables and synchronous sets and resets can be moved to the datapath (via a LUT input)
Page 18
Control Signals Problems
Instantiation of primitives and cores
– Gate-level connection of UNISIM and core primitives dictates control signal
usage
– Be aware that some IP does not necessarily follow these guidelines
Synthesis optimization
– Synthesis may choose to build a control signal for logic optimization
Physical synthesis, design hierarchy, and incremental design
practices
– Can change control sets from the original specifications (be careful)
– Global or logic optimization may choose to build a control signal for logic
optimization
Tip: The cores you instantiate should share the same control signals you
infer. This will minimize the number of control sets in your design.
Page 19
Active-Low Control Signals
Problem: Active-low control signals can produce sub-optimal
results
Why?
– Control ports on registers are active-high
– Hierarchical design and design re-use can propagate bad design
practices
This results in…
– Poor device utilization
•
•
•
•
More LUTs
Less dense slice packing
More routing resources necessary
This requires additional inverters at all lower leaf levels
– Longer run times
• Prohibits hierarchical design flows (like incremental design)
• More difficult timing
– Worse timing and power
Tip: Use active-high signals for CEs, sets, and resets
Page 20
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
Page 21
Design Tips
 Suggestions for faster and smaller designs
– Use synchronous Set/Reset whenever possible
– Use active-high CE and Set/Reset (no local inverter
for secondary control signals)
FF1
D
CE
CK
SR
– Try to build your design with as few control signals
as possible
●●●
 Rules to recognize
– Clocks and asynchronous set/resets always connect
to the control port of the FF
– Asynchronous sets/resets have priority access to the
control ports over synchronous sets/resets
– Clock enables and synchronous set/resets can
become control signals
Page 22
Q
FF8
D
CE
CK
Q
SR
Where Can I Learn More?
Software Manuals
– 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 Education Services courses
– www.xilinx.com/training
• Xilinx tools and architecture courses
• Hardware description language courses
• Basic FPGA architecture, Basic HDL Coding Techniques, and other Free
videos!
Page 23
Virtex-6 and Spartan-6 HDL Coding Techniques
Part 2
Welcome
If you are new to FPGA design, this module will help you
code properly for Spartan-6 and Virtex-6 register
resources
These design techniques promote fast and efficient FPGA
designs
Page 25
After completing this module, you will
Objectives
able to:
After completing this module you will be able to…
Code your design so you can infer more of the dedicated
hardware resources
Avoid the most common coding mistakes which hurt device
utilization
Reduce your dependence on global resets by taking
advantage of the Global Set/Reset net (GSR)
Page 26
Tactics to Meet Timing
Use as many of the dedicated resources as
possible (SRLs, DSP slices, and block RAMs)
– Understanding the features of the resource is essential if you are
going to infer the resource
– This is critical to reducing the number of LUTs and registers in your
FPGA design and increasing the amount of dedicated hardware you
infer
One of the most effective ways to reduce power in
FPGAs is to reduce the number of LUTs and FFs
– One of the side benefits of these techniques is that they will allow
you to improve performance and device utilization
Page 27
DSP Slice Uses a Synchronous Reset
Each DSP slice effectively has more than 250 registers
– None have an asynchronous reset
The DSP slice is more versatile than most realize
– It can be used for multipliers, add/sub, MACC, counters (with
programmable terminal count), comparators, shifters, multiplexer,
pattern match, and many other logic functions
Many designs that run out of slices are not fully utilizing their
DSP slice resources
– Synthesis tools will infer the DSP slice resources 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
Page 28
BRAM Uses a Synchronous Reset
Block RAMs obtain minimum clock-to-output time by
using their output register
– 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 flip-flops
– 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
Page 29
Synchronous Sets/Resets
Synchronous Sets and Resets give the tools more flexibility
– Can improve timing and device utilization
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
and may not be on by default
• XST has a Use Synchronous Reset synthesis option (on by default)
– The Xilinx implementation tools cannot change what is synthesized
This could allow packing of a register into a slice previously
not possible
S
D
Low
Fanout
Page 30
Synchronous Sets/Resets
Synchronous sets/resets make FPGA designs more reliable
Synchronous sets/resets are automatically timed
– Do not need any special timing constraints
– Do not need special switches or setting to analyze timing
– Synchronous reset nets are often the most critical net in a design
Synchronous sets/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 require minimal
testing
Page 31
Caveats to Synchronous Sets/Resets
Synchronous resets increase the number of constrained
paths, 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, DSP slices,
and other dedicated hardware
Page 32
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 critical drawbacks of asynchronous resets
– Use synthesis switch (dangerous!)
Synplify:
syn_clean_reset
XST:
-async_to_sync YES
• Not the same as changing to synchronous reset
• This can make the synthesis result different from the behavioral simulation
– Recommended: manually (or use a script) to change the asynchronous
reset to synchronous
• Removing the top-level reset port does not get the same result as removing
the reset from your code
Page 33
Resets
Two kinds of resets – Global and Local
 Global…usually used to reset after configuration
This is done by default after configuration of the FPGA
and does not need to be coded into the design
−
Access to this net is done with the GSR port from
the Startup component (only necessary if you
wish to perform a global reset s second time)
−
Note…if you are coding in a global reset into your
HDL you are actually coding in a second reset
•
Some ASIC technologies require at most an
initialization when they power up. But FPGAs do not
require a reset.
Local…used as a standard part of some components
behavior
•
FSM, counters, etc
•

Page 34
Getting By
Some designs can get away without any resets but many
designs need some resets
– Very few designs require resets on all registers, but most designers
want a global reset after initialization
• Most ASIC emulation also requires a described reset on every register.
• Implement this global reset with the built-in Global Set/Reset (GSR)
 GSR is good for initializing the values of your synchronous elements (FFs,
Block RAMs)
 Delay of GSR is slow (3 clock cycles after configuration) so use it after
configuration, but don’t reset again unless you can tolerate the entire design
being reset
Page 35
Global Reset Net
The GSR input is an active-high global set/reset
net that is active at the end of configuration
– It uses a dedicated routing resource for signal
distribution
• Saves general interconnect
– It can also be used to restore the initial state of the
FFs in the FPGA at any time
• The initial state is communicated with an INIT attribute
• It drives the output FFs for each block RAM, but does not
affect the contents of each memory or SRL
– It is connected to all synchronous elements through a
wired OR gate
• This allows a local reset to also drive the FF’s set/reset
port
Page 36
Startup Instantiation (VHDL)
VHDL and Verilog instantiations are available from the Xilinx
Unified Libraries Guide
Library UNISIM;
use UNISIM.vcomponents.all;
-- STARTUP_VIRTEX6: Virtex-6 Configuration Start-Up Sequence Interface
-- Virtex-6
-- Xilinx HDL Libraries Guide, version 12.1
STARTUP_VIRTEX6_inst : STARTUP_VIRTEX6
generic map (PROG_USR=>"FALSE“) -- Activate program event security feature
port map (…
CLK => CLK, -- 1-bit User start-up clock
GSR => GSR, -- 1-bit Active high Global Set/Reset signal
GTS => GTS, -- 1-bit Active high Global 3-State signal
…
);
-- End of STARTUP_VIRTEX6_inst instantiation
Page 37
Inferring an Initialization (XST only)
If you have a reset, you can initialize all registers in VHDL /
Verilog code
SR will cause the flip-flop to be set to the state inferred here
– Inference is supported only for data types std_logic, bit_vector, bit, but
NOT integer
VHDL:
signal my_regsiter : std_logic_vector (7 downto 0) := (others <= ‘0’);
Verilog:
reg [7:0] my_register = 8’h00;
This is helpful for RTL simulation of the design
– If it functions during simulation, it should function on the FPGA
– Note…if you design without a reset in your design, you still get a free
global reset
Page 38
No Reset is Best
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
• This will uses extra resources and take extra clock cycles to set up (not what
you want)
Page 39
No Reset is Best
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
Page 40
Use the GSR
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: Using the GSR saves
routing and improves design
speed
Page 41
Block RAM
Avoid “read before write” mode for fastest performance by
instantiating your memory with 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”;
Page 42
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
to the
control port
Page 43
VHDL:
if (CE=‘1’) then
Q <= A;
Verilog:
if (CE=‘1’)
Q <= A;
VHDL:
Q <= ((not CE) AND A) OR (CE AND Q);
Verilog:
Q <= (~CE & A) | (CE & Q);
This will
map the
CE to a
LUT input
Global Clock Enable
To gate entire clock domains for power reduction, use the
clock-enabled global buffer resource BUGCE or the BUFHCE
– 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
Page 44
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
– Spartan-6 and Virtex-6 FPGAs uses adder chains which obtain peak
performance and use minimal power
• Requires pipelining
• Adds latency
Adder
Tree
Page 45
Adder
Chain
Synthesis Options
Over-constraining 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 the utilization benefits (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
Page 46
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
Page 47
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: Use IOB registers when necessary to meet I/O
timing
Page 48
Summary
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
flip-flops only support a synchronous reset)
IOB registers can make it more difficult to meet internal
timing
– Use IOB registers only for improving IO timing
Xilinx recommends NOT using the synthesis option to
convert asynchronous resets to synchronous
Page 49
Summary
Synthesis tools can move synchronous resets from control
ports to the data path
Avoid the use of global resets
– Initialize all registers from your HDL
– If you need a global reset use the Startup_Virtex6 or the
Startup_Spartan6 primitive to access the GSR net
– If you can remove a global reset, you will save a lot of routing and
build a faster design
Avoid resets on SRLs (no reset functionality)
Page 50
Where Can I Learn More?
Software Manuals
– 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 Education Services courses
– www.xilinx.com/training
• Xilinx tools and architecture courses
• Hardware description language courses
• Basic FPGA architecture, Basic HDL Coding Techniques, and other Free
videos!
Page 51
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.