Part 1

Basic HDL Coding Techniques

Objectives

After completing this module, you will be able to:

Specify FPGA 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

Breakthrough Performance

Three steps to achieve breakthrough performance1. Utilize dedicated resources

• Dedicated resources are faster than a LUT/flip-flop implementation and consume less power

• Typically built with the CORE Generator tool and instantiated

• DSP48E, FIFO, block RAM, ISERDES, OSERDES, EMAC, and MGT, for example

2. Write code for performance• Use synchronous design methodology• Ensure the code is written optimally for critical paths• Pipeline when necessary

3. Drive your synthesis tool• Try different optimization techniques • Add critical timing constraints in synthesis• Preserve hierarchy• Apply full and correct constraints• Use High effort

Performance Meter

Virtex™-6 FPGAVirtex™-6 FPGA

Use Dedicated Blocks

Dedicated block timing is correct by construction– Not dependent on

programmable routing– Uses less power

Offers as much as 3x the performance of soft implementations– Examples

• Block RAM and FIFO at 600 MHz

• DSP48E at 600 MHz

Phy Interface

RxStats Mx

RxStats Mx

TxStats Mx

TxStats Mx

EMAC Core

EMAC Core

Host Interface

Host Interface

Statistics Interface

Clie

nt In

terf

ace

Host BusDCR Bus

Processor

Interface

Processor

Interface

Smart RAM FIFO

FIFO

Dual-Port BRAM

Dual-Port BRAM

EMAC Core

DSP48E Slice

Timing Closure

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 clock buffer instantiations

FPGA Resources

Can be inferred by all synthesis tools– Shift register LUT (SRL16E/

SRLC32E)– F7 and F8 multiplexers– Carry logic– Multipliers and counters using

the DSP48E– 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 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, PLL (use the Architecture Wizard)• IBUFG, BUFGMUX_CTRL, BUFGCE• BUFIO, BUFR

Suggested Instantiation

Why does Xilinx suggest this?– Easier to port your HDL

to other and newer technologies

– Fewer synthesis constraints and attributes to pass on

• Keeping most of the attributes and constraints in the Xilinx User Constraints File (UCF) keeps it simple—one 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– Instead use VHDL configuration statements or put wrappers around each

instantiation• This maintains hierarchy and makes it easy to swap instantiations

Top-Level Block

Top-Level Block

BUFGDCMIBUFG

Xilinx “wrapper” top_xlnx

IBUF

OBUF

OBUF

OBUF

STARTUP

Hierarchy Management

Synplify and XST softwareThe 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 (recommended)

If you have followed the synchronous design guidelines, use the setting -maintain hierarchyIf you have not followed the synchronous design guidelines, use the setting -flatten the design.– Consider using the “keep” attribute to preserve nodes for testing

Your synthesis tool may have additional settings– Refer to your synthesis documentation for details on these settings

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

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

Priority Encoder– Most critical input listed first– Least critical input listed last

do_cdo_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 <= do_d ;

ELSIF cond_a THEN oput <= do_a;

ELSIF cond_b THEN oput <= do_b;

ELSIF cond_c THEN oput <= do_c;

ELSE oput <= do_e;

END IF;

Avoid Nested IF and IF/ELSE

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

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 uses fewer LUTs, but

requires multiple LUTs in series on the timing critical path

The advantage of using the “don’t 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 <= in_a; 3'b001 : data_out <= in_b; 3'b010 : data_out <= in_c; 3'b011 : data_out <= in_d; 3'b100 : data_out <= in_e; 3'b101 : data_out <= in_f; default : data_out <= 1'bx; endcaseendendmodule

CASE Statement

This is the same code with one-hot select inputs– This used more LUTs, but requires

fewer logic levels on the timing critical path

– This yields a greater benefit when the mux is larger

Enumerated types allow you to quickly test different encoding– …and makes simulation more

readable

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 <= in_a; 6'b000010 : data_out <= in_b; 6'b000100 : data_out <= in_c; 6'b0010 00: data_out <= in_d; 6'b010000 : data_out <= in_e; 6'b100000 : data_out <= in_f; default : data_out <= 1'bx; endcaseendendmodule

Other Basic Performance Tips

Avoid high-level loop constructs– Synthesis tools may not produce optimal results

Order and group arithmetic and logical functions and operators– A <= B + C + D + E; should be: A <= (B + C) + (D + E)

Use a synchronous reset– More reliable system control

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

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; else Q = 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

VHDL

FF_AR_CE: process(ENABLE,CLK)begin if (CLK’event and CLK = ‘1’) then if (ENABLE = ‘1’) then Q <= D_IN; end if; end if;end process

Verilog

always @(posedge CLOCK) if (ENABLE) Q = D_IN;

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, DSP48E, and FIFO)

Maintain your design hierarchy to make debugging, simulation, and report generation easier

Summary

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

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

Where Can I Learn More?

Software Manuals– Start Xilinx ISE Design Suite 13.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 and other topics

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.

Trademark Information

Part 2

Basic HDL Coding Techniques

Objectives

After completing this module, you will be 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

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

S1

S5 S4

S3

S2

StateMachineModule

Inputs to FSM

Next-state logic

State register

State machine outputs

HDL Code

State Machine Design

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

StateJumps Only!Input Signals

Next State

Current State Feedback to Drive State JumpsState Register

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

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

statesOne-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

transitionsHow 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) begin if (reset) begin current_state <= s0; end else current_state <= next state; end

Outputs are not defined here (good)– Placed in a separate always block

Asynchronous reset (bad)

State Machine Example (Verilog)

always @ (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; else next_state = s2; s2: next_state = s4; s3: next_state = s3; s4: next_state = s0; default: next_state = ‘bx; endcase end end endmodule

Use a default statement as part of your next state assignments (good)

reg [3:0] current_state, next_state;

parameter state1 = 2’b00, state2 = 2’b01,

state3 = 2’b10, state4 = 2’b11;

always @ (current_state)

case (current_state)

state1 : next_state = state2;

state2 : next_state = state3;

state3 : next_state = state4;

state4 : next_state = state1;

endcase

always @ (posedge clock)

current_state = next_state;

Test different FSM encodings yourself (good)– Don’t always trust your

synthesis tool to choose the best encoding

Binary Encoding (Verilog)

reg [4:0] current_state,next_state;

parameter state1 = 4’b0001, state2 = 4’b0010, state3 = 4’b0100, state4 =

4’b1000;

always @ (current_state)

case (current_state)

state1 : next_state = state2;

state2 : next_state = state3;

state3 : next_state = state4;

state4 : next_state = state1;

endcase

always @ (posedge clock)

current_state = next_state;

Encoding is easily changed

One-Hot Encoding (Verilog)

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

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 next_state <= s0; end if; when s1 => next_state <= s2; if signal a='1' AND signal b = '0' then next_state <= s3; usually_zero_comb <= '1'; end if; when s2 => next_state <= s3; when s3 => usually_one_comb <= '0'; next_state <= s3; when others => next_state <= s0; end case; end process;

Default state is used to define output values (good)

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;

Asynchronous reset (bad, unreliable)

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;

Undefined encoding (bad, probably inefficient)

Unspecified 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) begin 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; end if; if current_state(s1_bit) = '1' then next_state(s4a_bit) <= '1'; end if; end;end;

OHE a little harder in VHDL (recommend using your synthesis tools attribute, if possible)

One-Hot Encoding (VHDL)

Pipelining Concept

D QfMAX = n MHz

fMAX 2n MHz

two logic levels

one level

one level

D Q

D Q D Q D Q

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)

Performance by Design

Code A

Code B

• One level of logic, but the routing can be prohibitive

• May require higher speed grade, adding cost

Switch

Enable

reg_data

reg_enable

data_inD QCE

D Q

D Q

Switch

Enable

reg_datadata_in

D Q

D QCE

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• Data_in must also be registered

High fanout

QD

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

always @(posedge clk)begin if (switch && enable) reg_data <= data_in;end

always @(posedge clk)begin

if (set_in && enable_in) reg_enable <= 1'b1;else reg_enable <= 1'b0;

if (reg_enable) reg_data <= data_in;

end

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

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 if; end process;

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 if; end if; end process;

Code ACode B

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

Where Can I Learn More?

Software Manuals– Start Xilinx ISE Design Suite 13.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 and other topics

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.

Trademark Information