VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY

DESIGNING A 4-BIT GRAY ASYNCHRONOUS COUNTER

by Nguyen Ngoc Hoang

Digital IC Design Project in the Electronics and Telecommunication University of Engineering and Technology

December 2011

Contents
List of Figures List of Tables Abbreviations 1 Gray code 1.1 What is Gray code? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Why use Gray code? . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Binary to Gray encoding . . . . . . . . . . . . . . . . . . . . . . . . 2 Specication 2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Modeling 3.1 Graycounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Top-level design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii iv v 1 1 1 2 3 3 5 5 6 7

4 Behavioral simulation 9 4.1 Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Test vector generation . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Behavioral simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5 User constraints 5.1 PERIOD constraints . . . . . . . . . . . . 5.2 Pin assignment . . . . . . . . . . . . . . . 5.2.1 Slide Switches . . . . . . . . . . . . 5.2.1.1 Locations and Labels . . . 5.2.1.2 Operation . . . . . . . . . 5.2.1.3 UCF Location Constraint 5.2.2 Discrete LEDs . . . . . . . . . . . . 5.2.2.1 Location and Labels . . . 5.2.2.2 Operation . . . . . . . . . 5.2.2.3 UCF Location Constraint 5.2.3 Clock Source . . . . . . . . . . . . i 12 12 13 13 13 13 14 14 14 15 15 15

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Contents 5.2.3.1 5.2.3.2 5.2.3.3

ii Overview . . . . . . . . . . . . . . . . . . . . . . . 15 Clock Connection . . . . . . . . . . . . . . . . . . . 16 UCF Constraint . . . . . . . . . . . . . . . . . . . 17 18 18 18 18 18 19 19 19 19 19 20 20 20 21 21 21 22 22 23 23

6 Synthesis and Implementation 6.1 Xilinx Flow Overview . . . . . . . . . . . . . . . . . 6.1.1 Synthesis with Xilinx XST . . . . . . . . . . 6.1.2 Translate . . . . . . . . . . . . . . . . . . . 6.1.3 Map . . . . . . . . . . . . . . . . . . . . . . 6.1.4 Place and Route . . . . . . . . . . . . . . . 6.1.5 Bit-le generation . . . . . . . . . . . . . . . 6.2 Synthesizing Design . . . . . . . . . . . . . . . . . . 6.2.1 Synthesis Tool Functionality . . . . . . . . . 6.2.2 Generating Post-Synthesis Simulation Model 6.3 Translating Design . . . . . . . . . . . . . . . . . . 6.3.1 Translate Process Functionality . . . . . . . 6.3.2 Translate Process File Types . . . . . . . . . 6.4 Mapping the Design . . . . . . . . . . . . . . . . . 6.4.1 MAP Process Functionality . . . . . . . . . 6.4.2 MAP Process File Types . . . . . . . . . . . 6.5 Placing and Routing the Design . . . . . . . . . . . 6.5.1 Place and Route Process Functionality . . . 6.5.2 PAR Process File Types . . . . . . . . . . . 6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

List of Figures
1.1 2.1 4.1 4.2 4.3 4.4 4.5 4.6 5.1 5.2 5.3 6.1 6.2 6.3 6.4 Gray code and binary code . . . . . . . . . . . . . . . . . . . . . . . Gray counter top level . . . . . . . . . . . . . . . . . . . . . . . . . Behavioral Behavioral Behavioral Behavioral Behavioral Behavioral simulation simulation simulation simulation simulation simulation with enable = 1, direction = 0, reset = 0 with direction = 1 . . . . . . . . . . . . . . with reset = 0 . . . . . . . . . . . . . . . . . reset = 1, direction = 1 . . . . . . . . . . . with enable down to 0 . . . . . . . . . . . . . with enable return 1 . . . . . . . . . . . . . 2 4 10 10 11 11 11 11

Four slide switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Eight Discrete LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Avaiable clock input . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Post-Synthesis Simulation . Post-Translate Simulation . Post-Map Simulation . . . . Place and Route Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 21 22 23

iii

List of Tables
5.1 Clock inputs and Associated Global Buers and DCMs . . . . . . . 17

iv

Abbreviations
FPGA VHDL VHSIC CBL IOB Field Programmable Gate Array VHSIC Harware Discription Language Very High Speed Integrated Circuit Combinational Logic Blocks Input Output Block

Chapter 1 Gray code

1.1

What is Gray code?

The reected binary code, also known as Gray code, is a binary numeral system that uses a dierent method of incrementing from one number to the next.

The advantage of Gray code is that only one bit changes state from one position to another.

1.2

Why use Gray code?

Gray code is the most popular Absolute encoder output type because it can be prevent cetain data errors which can ocur with natural binary during state changes. For example, in a highly capacitive circuit, a natural binary state changes from 0011 to 0100 could cause the counter to see 0111. This sort of error is not possible with Gray code so that data is more reliable.

Chapter 1. Gray code

Figure 1.1: Gray code and binary code

1.3

Binary to Gray encoding

When we have a code of binary type, Gray code will be otained by using three xor gates to obtain 4-bit gray code from natural binary code with the following equation: G0 = A0 A1 G1 = A1 A2 G2 = A2 A3 G3 = A3 (1.1) (1.2) (1.3) (1.4)

Chapter 2 Specication

2.1

Functionality

The aim of 4-bit gray counter is that counting the gray code in sequence of 16 states. There are 4 control input signals perform the operation of counter as follow:

Enable signal decides whether counting process is started or stopped. The countings direction (upward or downward) is depended on the value of direction signal (0 or 1). The state of counter will be reset when the asynchronous reset signal is active low, counting value must be return to 0000. Clock signal used for synchronization circuit.

Chapter 2. Specication

Figure 2.1: Gray counter top level

Chapter 3 Modeling
In this project, VHDL language to be used to model the design. The behavioral of graycounter is illustrated in section 3.1. Because the output will be presented by LEDs, the delay component should be created help easier observe and verify the correctness of design. The operation of delay component is shown in section 3.2. Finally, section 3.3 shows the connection between ports of graycounter and delay component.

3.1

Graycounter

library IEEE ; use IEEE . STD_LO GIC_1164 . ALL ; use IEEE . S T D _ L O G I C _ U N S I G N E D . ALL ;

ENTITY graycounter IS PORT ( clk : in rst_n : in direction en_in : in STD_LOGIC ; STD_LOGIC ; : in STD_LOGIC ;

STD_LOGIC ; S TD _ L O G I C _ V E C T O R (7 downto 0));

leds_out : out END graycounter ;

ARCHITECTURE structure OF graycounter IS SIGNAL binary_cnt : ST D _ L O G I C _ V E C T O R (3 DOWNTO 0); SIGNAL leds_out_s : ST D _ L O G I C _ V E C T O R (7 DOWNTO 0); BEGIN

Chapter 3. Modeling
PROCESS ( clk , rst_n ) BEGIN IF rst_n = 0 then binary_cnt <= " 0000 " ; leds_out_s <= " 00000000 " ; ELSIF rising_edge ( clk ) then IF en_in = 1 then IF direction = 0 then binary_cnt <= binary_cnt + 1; ELSE binary_cnt <= binary_cnt - 1; END if ;

leds_out_s (3 downto 0) <= (( 0 & binary_cnt (3 DOWNTO 1)) XOR bi leds_out_s (7 DOWNTO 4) <= binary_cnt ; END if ; END if ; END PROCESS ; leds_out <= leds_out_s ; END structure ;

3.2

Delay

LIBRARY ieee ; USE ieee . std_lo gic_1164 . ALL ; USE ieee . numeric_std . ALL ;

ENTITY delay_cnt IS PORT ( clk rst_n en_in : IN : IN : IN STD_LOGIC ; STD_LOGIC ; STD_LOGIC ;

en_out : OUT STD_LOGIC ); END ENTITY delay_cnt ;

ARCHITECTURE rtl OF delay_cnt IS SIGNAL delay_reg : UNSIGNED (23 DOWNTO 0); BEGIN -- A R C H I T E C T U R E rtl

delay _reg_pr oc : PROCESS ( clk , rst_n ) IS BEGIN -- PROCESS d e l a y _ r e g

IF rst_n = 0 THEN delay_reg <= ( OTHERS = > 0 ); ELSIF rising_edge ( clk ) THEN IF en_in = 1 THEN delay_reg <= delay_reg + to_unsigned (1 , delay_reg LENGTH );

Chapter 3. Modeling
END IF ; END IF ; END PROCESS delay_r eg_proc ; en_out <= 1 WHEN delay_reg = ( delay_reg LENGTH -1 DOWNTO 0 = > 1 ) ELSE 0 ; END ARCHITECTURE rtl ;

3.3

Top-level design

LIBRARY ieee ; USE ieee . std_lo gic_1164 . ALL ;

ENTITY top_level IS

PORT ( clk rst_n en_in up_n_in : IN : IN : IN : IN STD_LOGIC ; STD_LOGIC ; STD_LOGIC ; STD_LOGIC ;

leds_out : OUT S T D _ LO G I C _ V E C T O R (7 DOWNTO 0));

END ENTITY top_level ;

ARCHITECTURE rtl OF top_level IS

COMPONENT delay_cnt IS PORT ( clk rst_n en_in : IN : IN : IN STD_LOGIC ; STD_LOGIC ; STD_LOGIC ;

en_out : OUT STD_LOGIC ); END COMPONENT delay_cnt ;

COMPONENT graycounter IS PORT ( clk rst_n : IN : IN STD_LOGIC ; STD_LOGIC ;

direction : IN STD_LOGIC ; en_in : IN STD_LOGIC ;

leds_out : OUT S T D _ L OG I C _ V E C T O R (7 DOWNTO 0)); END COMPONENT graycounter ;

SIGNAL delay_en_out : STD_LOGIC ; BEGIN -- A R C H I T E C T U R E rtl

Chapter 3. Modeling
delay_cnt_1 : ENTITY work . delay_cnt PORT MAP ( clk rst_n en_in = > clk , = > rst_n , = > en_in ,

en_out = > delay_en_out );

counter_1 : ENTITY work . graycounter PORT MAP ( clk rst_n = > clk , = > rst_n , = > up_n_in ,

direction en_in

= > delay_en_out ,

leds_out = > leds_out ); END ARCHITECTURE rtl ;

Chapter 4 Behavioral simulation

4.1

Testbench

Test bench is not dened by the VHDL Language Reference Manual and has no formal denition. We can know that a test bench is a virtual environment used to verify the correctness or soundness of a design or model. In digital IC design, the test bench is a specication in VHDL

4.2

Test vector generation

As mentioned before, there are three control signals that eect the systems operation. While enable decides whether counting process is continuous or not, direction signal with two stages high or low drives the increase or decrease of output signal. The value of counter will be return to 0000 when reset signal to be asserted. Thus, 6 test vectors are proposed to test all possible case as follow:

Case 1: Enable = 1, direction = 0, reset = 0. Case 2: direction = 1, counter should count with downward direction. Case 3: reset = 0, the value of counter should return to 0000. 9

Chapter 4. Behavioral simulation

10

Figure 4.1: Behavioral simulation with enable = 1, direction = 0, reset = 0

Figure 4.2: Behavioral simulation with direction = 1

Case 4: reset returns to 1, direction returns to 1. Counter continuously counts from 0000 by upward direction Case 5: enable down to 0. The output value should remain the value before enable down to 0. Case 6: enable return 1.counter continuously counts with initial value equal to the value before enable changes.

4.3

Behavioral simulation

Using ISE Project Navigator tool, in the Design Menu we choose Behavioral Simulation. The testbench for this design was set as a top level. In the Process menu choose ISim Simulator, Simulate Behavioral Model, right click and choose Run. The binary counting value will be added to output to observe more clearly. Finally, we get the waveform in gure 4.1 to 4.6 corresponding to case 1 to case 6:

Chapter 4. Behavioral simulation

11

Figure 4.3: Behavioral simulation with reset = 0

Figure 4.4: Behavioral simulation reset = 1, direction = 1

Figure 4.5: Behavioral simulation with enable down to 0

Figure 4.6: Behavioral simulation with enable return 1

Chapter 5 User constraints

5.1

PERIOD constraints

The PERIOD constraints is a fundamental timing and synthesis constraint. PERIOD constraints:

Dene each clock within the design. Cover all synchronous paths within each clock domain. Dene the duaration of clock. Can be congured to have dierent duty cycles.

12

Chapter 5. User constraints

13

Figure 5.1: Four slide switches

5.2
5.2.1
5.2.1.1

Pin assignment
Slide Switches
Locations and Labels

The Spartan-3E Starter Kit board has four slide switches, as show in gure 5.1. The slide switches are located in the lower right corner of the board and are labeled SW3 to SW0 inwhich SW3 is the left-most switch, and SW0 is the right-most switch.

5.2.1.2

Operation

When in the UP or ON position, swith connects the FPGA pin to 3.3V, a logic High. When DOWN or in the OFF position, the switch connects the FPGA pin

Chapter 5. User constraints

14

Figure 5.2: Eight Discrete LEDs

to ground, a logic Low.

5.2.1.3

UCF Location Constraint

In my project, three switches, SW0, SW1 and SW2 are used corresponding to reset, enable and direction signal. UCF constraint for three switches as follow:
NET " rst_n " NET " en_in " NET " up_n_in " LOC = " L13 " | IOSTANDARD = LVTTL | PULLUP ; LOC = " H18 " | IOSTANDARD = LVTTL | PULLUP ; LOC = " L14 " | IOSTANDARD = LVTTL | PULLUP ;

5.2.2
5.2.2.1

Discrete LEDs
Location and Labels

The Spartan-3E Starter Kit board has eight individual surface-mount LEDs located above the slide switches as show in gure 5.2. The LEDs are labeled LED7 through LED0 inwhich LED7 is the most LED, LED0 is the right-most LED.

Chapter 5. User constraints 5.2.2.2 Operation

15

Each LED has one side connected to ground and the other side connected to a pin on the Spartan-3E device via a 390 current limiting resistor. To light an individual LED drive the associated FPGA control signal High.

5.2.2.3

UCF Location Constraint

Because the number of bit in this project is 4, so we will use 8 LEDs from LED0 to LED3. UCF constraint of 4 LEDs is:
NET " leds_out <0 > " LOC = " F12 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <1 > " LOC = " E12 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <2 > " LOC = " E11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <3 > " LOC = " F11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8;

To check the correctness of design, I will add the binary counting value to output, so the UCF constraint of LEDs is:
NET " leds_out <0 > " LOC = " F12 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <1 > " LOC = " E12 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <2 > " LOC = " E11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <3 > " LOC = " F11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <4 > " LOC = " C11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <5 > " LOC = " D11 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET " leds_out <6 > " LOC = " E9 " NET " leds_out <7 > " LOC = " F9 " | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8;

5.2.3
5.2.3.1

Clock Source
Overview

As shown in gure 5.3, the Spartan-3E Starter Kit board supports three primary clock input source, all of which are located below the Xilinx logo, near the Spartan3E logo.

Chapter 5. User constraints

16

Figure 5.3: Avaiable clock input

The board includes an on-board 50 MHz clock oscillator. Clocks can be supplied o-board via an SMA-style connecter. Alternatively, the FPGA can generate clock signal or other high-speed signals on the SMA-style connecter. Optionally install a separate 8-pin DIP-style clock oscillator in the supplied socket.

5.2.3.2

Clock Connection

Each of the clock inputs connect directly to a global buer input in I/O Bank 0, along the top of FPGA. As show in table 6.1, each of clock inputs also optimally connects to an associated DCM.

Chapter 5. User constraints

Table 5.1: Clock inputs and Associated Global Buers and DCMs

17

Clock Input CLK5 0M HZ CLKA U X CLKS M A 5.2.3.3

FPGA pin Global Buer Associated DCMs C9 GCLK10 DCMX 0Y 1 B8 GCLK8 DCMX 0Y 1 A10 GCLK7 DCMX 1Y 1

UCF Constraint

In my project, on-board 50 MHz clock to be used for input source. UCF constraint of on-board 50 MHz clock is :
NET " clk " LOC = " C9 " | IOSTANDARD = LVCMOS33 ; NET " clk " PERIOD = 10 ns HIGH 40%;

Chapter 6 Synthesis and Implementation

6.1
6.1.1

Xilinx Flow Overview

Synthesis with Xilinx XST

In this step, HDL design entry will be converted to equivalent boolean equations according to which logic gates are then correspondingly packed into Logic Cells, LUTs and Flip-ops from Xilinx UNISIM Library.

6.1.2

Translate

Translate step checks the design and ensures that netlist is consistent with chosen architecture. Translate also checks User-dened Constraints le, for any inconsistencies.

6.1.3

Map

This step performs two operation calculating and allocating Physical CBL and IOB Components in Targeted Device, to Logic Element symbols in Netlist that is generated during Translation Process. 18

Chapter 6. Synthesis and Implementation

19

6.1.4

Place and Route

Place and Route process places CLBs into logical position and utilizes the routing resources on target device, to connect logic cell on Xilinx Product such that desired Timing Specication are met.

6.1.5

Bit-le generation

The result of bit-le generation step is bit-stream le that containing conguration data for target FPGA device.

6.2
6.2.1

Synthesizing Design
Synthesis Tool Functionality

During synthesis, HDL les are translated into gates and optimized for the target architecture. Thus, XST Synthesis tool uses designs HDL code generates a supported netlist type (NGC) for Xilinx inplementation tools.

6.2.2

Generating Post-Synthesis Simulation Model

For the generated Post-Synthesis Simulation Model, no standard delay le (.sdf le) is back-annotated during simulation.(Thus, UNISIM Library primitives, included in the synthesis generated netlist, do not have any delay associated with it). Therefore, expected Post-Synthesis Simulation result is same as Functional Verication result of HDL Design. After synthesizing completes successfully by using Generate Post-Synthesis Simulation Model, synthesis le will be generated in to direction /netgen/synthesis. The simulation of this le have been done and shown in gure 6.1

Chapter 6. Synthesis and Implementation

20

Figure 6.1: Post-Synthesis Simulation

6.3
6.3.1

Translating Design
Translate Process Functionality

During translation, the NGDBuild program performs the following functions Converts input design netlists and writes results to a single merged NGD netlist. The merged netlist describes thelogic in the design as well as any location and timing constraints. Performs timing specication and logical design rule checks. Adds constraints from the User Constraints File (UCF) to the merged netlist.

6.3.2

Translate Process File Types

Translate Process uses following le as input: NGC netlist le from Synthesis Process. UCF constraint le containing timing and layout constraints. Translate Process uses following le as output: NGD le, containing logical description of the design, expressed in terms of lower level Xilinx Primitives, with constraint applied to design.

Chapter 6. Synthesis and Implementation

21

Figure 6.2: Post-Translate Simulation

BLD Report le shows following error in design or UCF le. Missing or untranslatable hierarchical blocks Invalid or incomplete timing constraints Output contention, loadless outputs, and sourceless inputs

After translating completes successfully by run Generate Post-Translate Simulation Model under Implementation design Translate, translate le will be generated in to direction /netgen/translate. The simulation of translate le is shown in gure 6.2.

6.4
6.4.1

Mapping the Design

MAP Process Functionality

Allocates CLB and IOB resources for all basic logic elements in the design. Processes all location and timing constraints, performs target device optimizations, and runs a design rule check on theresulting mapped netlist.

6.4.2

MAP Process File Types

MAP Process uses NGD le, created during Translate Process, as Input le. MAP Process creates following les as output.

Chapter 6. Synthesis and Implementation

22

Figure 6.3: Post-Map Simulation

NCD (Native Circuit Description) le containing physical description of design in terms of the components in the target Xilinx device PCF (Physical Constraints File) contains constraints specied during design entry expressed in terms of physical elements. MRP (MAP Report File) conrms the resources used within the device; and describes trimmed and merged logic.Detailed Report also describes exactly where each portion of the design is located in the device.

After mapping completes successfully by using Generate Post-Map Simulation Model, map le will be generated in to direction /netgen/map. The simulation of this le have been done and shown in gure 6.3

6.5
6.5.1

Placing and Routing the Design

Place and Route Process Functionality

During placement, PAR places components into sites based on factors such as constraints, the length of connections,and the available routing resources After placing the design, the router performs a converging procedure for a solution that routes the design to completion and meets timing constraints

Chapter 6. Synthesis and Implementation

23

Figure 6.4: Place and Route Simulation

6.5.2

PAR Process File Types

PAR Process uses Mapped Design (NCD) File and Physical Constraint (PCF)le created during MAP Process, as Input File PAR Process creates following les as output

Placed and Routed NCD Design File. PCF (Physical Constraints File) contains constraints specied during design entry expressed in terms of physical elements. PAR Report File, including summary information of all placementand routing iterations

After Place and Route completes successfully by using Generate Post-Place Simulation Model, timesim le will be generated in to direction /netgen/par. The simulation of this le have been done and shown in gure 6.4

6.6

Conclusion

In conclusion, expected Post-Synthesis Simulation and Post-Translate Simulation results are the same as Functional Verication result of HDL Design by using the same UNISIM library which do not have any delay associated with it. In contrast, Post-Map and Post-Place and Route with SDF le containing logic/routing delay information are back-annotated to the netlist, simulation waveform result shows

Chapter 6. Synthesis and Implementation

24

delay in updating output signal ports after input clock and data are applied to the design.

Bibliography
[1] Spartan-3E FPGA Starter Kit Board User Guide, UG230 (v1.2)January 20, 2011, http://www.xilinx.com/support/documentation/boards_and_ kits/ug230.pdf [2] ISE Design Suite Software Manuals - PDF Collection, ISE Design Suite Software Manuals(v 12.4) December 14, 2010, http://www.xilinx.com/support/ documentation/sw_manuals/xilinx12_4/manuals.pdf

25