Basic HDL Coding Techniques
Part 1
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
performance
1. 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
Virtex™-6 FPGA
Performance Meter
Use Dedicated Blocks
DSP48E Slice
Dedicated block timing is
correct by construction
– Not dependent on
programmable routing
Offers as much as 3x the
performance
of soft implementations
– Examples
• DSP48E at 600 MHz
Statistics
Interface
Smart RAM FIFO
DCR Bus
Host Bus
Rx
Stats
Mx
Proce
ssor
Interfa
ce
Tx
Stats
Mx
EMAC
Core
Host
Interface
EMAC Core
Phy
Interface
• Block RAM and FIFO at
600 MHz
Dual-Port
BRAM
Client Interface
– Uses less power
FIFO
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)
Can be inferred by some
synthesis tools
– Memories
– F7 and F8 multiplexers
– Global clock buffers (BUFGCE,
BUFGMUX, BUFGDLL)
– Carry logic
– Some DSP functions
– Multipliers and counters using
the DSP48E
Cannot be inferred by any
synthesis tools
– Global clock buffers (BUFG)
– SelectIO (differential) interface
– SelectIO™ (single-ended)
interface
– Output DDR registers
– I/O registers (single data rate)
– Input 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
Xilinx “wrapper” top_xlnx
START
UP
OBUF
IBUFG
IBUF
DCM
BUFG
Top-Level
Block
OBUF
OBUF
• 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
Hierarchy Management
Synplify 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 (recommended)
If you have followed the synchronous design guidelines, use the
setting -maintain hierarchy
If 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_e 0
do_c 1
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;
0
do_b
cond_c
1
0
do_a
cond_b
1
0
do_d
cond_a
oput
1
crit_sig
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 binaryencoded
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;
endcase
end
endmodule
CASE Statement
This is the same code with onehot 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;
endcase
end
endmodule
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
Ex 1 D Flip-Flop
always @(posedge CLOCK)
Q = D_IN;
Ex 3. D Flip-Flop with Asynch Reset
always @(posedge CLOCK
or posedge RESET)
if (RESET)
Q = 0;
else
Q = D_IN;
Ex 2. D Flip-Flop with Asynch Preset
always @(posedge CLOCK or
posedge PRESET)
if (PRESET)
Q = 1;
else
Q = D_IN;
Ex 4. D Flip-Flop with Synch Reset
always @(posedge CLOCK)
if (RESET)
Q = 0;
else
Q = D_IN;
Clock Enables
Coding style will determine if clock enables are used
VHDL
Verilog
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
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
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.
Basic HDL Coding Techniques
Part 2
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
State Machine Design
Put the next-state logic in one CASE
statement
– The state register can also be
included here or in a separate
process block or always block
Put the state machine outputs in a
separate process or always block
– Prevents resource sharing, which
can hurt performance
Inputs to FSM
S2
S1
S5
State
Machine
Module
S3
S4
HDL Code
Next-state logic
State register
State machine outputs
The Perfect State Machine
The perfect state machine has…
– Inputs: Input signals and state jumps
– Outputs: Output states, control signals, and enable signals to the rest of
the design
– NO arithmetic logic, datapaths, or combinatorial functions inside the state
machine
Current State Feedback to Drive State Jumps
Next State
State Register
Input Signals
State
Jumps
Only!
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
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)
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)
Binary Encoding (Verilog)
Test different FSM
encodings yourself (good)
– Don’t always trust your
synthesis tool to choose the
best encoding
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;
One-Hot Encoding (Verilog)
reg [4:0]
current_state,next_state;
state1 = 4’b0001, state2 = 4’b0010,
state3 = 4’b0100, state4 = 4’b1000;
always @ (current_state)
parameter
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
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 =>
 Default state is used to
next_state <= s2;
define output values
if signal a='1' AND signal b = '0' then
next_state <= s3;
(good)
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;
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)
Unspecified Encoding (VHDL)
entity EXAMPLE is
port( A,B,C,D,E, CLOCK: in std_logic; X,Y,Z: out
std_logic);
end EXAMPLE;
architecture XILINX of EXAMPLE is
type STATE_LIST is (S1, S2, S3, S4, S5, S6, S7);
signal STATE: STATE_LIST;
begin
P1: process( CLOCK ) begin
if( CLOCK’event and CLOCK = ‘1’) then
case STATE is
when S1 =>
X <= ‘0’; Y <= ‘1’; Z <= ‘1’;
if( A = ‘1’ ) then
STATE <= S2;
else
STATE <= S1;
Undefined encoding (bad, probably inefficient)
One-Hot Encoding (VHDL)
architecture one-hot_arch of one-hot is
subtype state_type is std_logic_vector(5 downto 0);
signal current_state, next_state: state_type;
constant s0 : state_type := "000001";
constant s0_bit : integer := 0;
constant s1_bit : integer := 1;
constant s2_bit : integer := 2;
constant s3_bit : integer := 3;
constant s4a_bit : integer := 4;
constant s4b_bit : integer := 5;
signal usually_zero_comb, usually_one_comb : std_logic;
begin
comb_state_machine: process(current_state, signal a, signal b, signal c, signal d)
begin
next_state <= state_type'(others => '0');
if current_state(s0_bit) = '1' then
if signal a = '1' then
next_state(s0_bit) <= '1';
 OHE a little harder in
else
VHDL (recommend
next_state(s1_bit) <= '1';
end if;
using your synthesis
end if;
tools attribute, if
if current_state(s1_bit) = '1' then
next_state(s4a_bit) <= '1';
possible)
end if;
end;
end;
Pipelining Concept
fMAX =
n MHz
fMAX 
2n MHz
D Q
D Q
one
level
two logic levels
D Q
D Q
one
level
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
DQ
Switch
High fanout
DQ
Enable
data_in
CE
D Q
Code B
•
•
•
•
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
reg_data
DQ
Code A
• One level of logic, but the routing can
be prohibitive
• May require higher speed grade,
adding cost
Switch
DQ
DQ
reg_enable
High fanout
Enable
DQ
data_in
CE
D Q
reg_data
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
Code A
always @(posedge clk)
begin
if (switch && enable)
reg_data <= data_in;
end
In each case
Code B
always @(posedge clk)
begin
if (set_in && enable_in)
reg_enable <= 1'b1;
else
reg_enable <= 1'b0;
– reg_data and data_in are 16-bit buses
– switch and enable are outputs from
flip-flops
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
Code B capture: process (clk)
Code A capture: process (clk)
begin
begin
if clk'event and clk='1' then
if clk'event and clk='1' then
if switch ='1’ and enable=‘1’ then
if switch='1’ and enable=‘1’ then
reg_enable <= ‘1’;
reg_data <= data_in;
else
end if;
reg_enable <= ‘0’;
end if;
end if;
end process;
if reg_enable='1’ then
In each case
reg_data <= data_in;
end if;
– reg_data and data_in are 16-bit buses
end if;
– switch and enable are outputs from flip-flops
end process;
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
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.