NguyenNgocHoang_GrayCounter

8/3/2019 NguyenNgocHoang_GrayCounter

1/31

VIETNAM NATIONAL UNIVERSITY, HANOI

UNIVERSITY OF ENGINEERING AND

TECHNOLOGY

DESIGNING A 4-BIT GRAYASYNCHRONOUS COUNTER

by

Nguyen Ngoc Hoang

Digital IC Design

Project

in the

Electronics and Telecommunication

University of Engineering and Technology

December 2011
http://www2.uet.vnu.edu.vn/uet/http://www2.uet.vnu.edu.vn/uet/http://www2.uet.vnu.edu.vn/uet/http://[email protected]/http://uet.vnu.edu.vn/fet/http://uet.vnu.edu.vn/fet/http://uet.vnu.edu.vn/fet/http://uet.vnu.edu.vn/fet/http://[email protected]/http://www2.uet.vnu.edu.vn/uet/http://www2.uet.vnu.edu.vn/uet/http://www2.uet.vnu.edu.vn/uet/


2/31

Contents

List of Figures iii

List of Tables iv

Abbreviations v

1 Gray code 1

1.1 What is Gray code? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Why use Gray code? . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Binary to Gray encoding . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Specification 3

2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Modeling 5

3.1 Graycounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Top-level design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Behavioral simulation 9

4.1 Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Test vector generation . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3 Behavioral simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 User constraints 12

5.1 PERIOD constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 125.2 Pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.2.1 Slide Switches . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.2.1.1 Locations and Labels . . . . . . . . . . . . . . . . . 13

5.2.1.2 Operation . . . . . . . . . . . . . . . . . . . . . . . 13

5.2.1.3 UCF Location Constraint . . . . . . . . . . . . . . 14

5.2.2 Discrete LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.2.1 Location and Labels . . . . . . . . . . . . . . . . . 14

5.2.2.2 Operation . . . . . . . . . . . . . . . . . . . . . . . 15

5.2.2.3 UCF Location Constraint . . . . . . . . . . . . . . 15

5.2.3 Clock Source . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i


3/31

Contents ii

5.2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 15

5.2.3.2 Clock Connection . . . . . . . . . . . . . . . . . . . 16

5.2.3.3 UCF Constraint . . . . . . . . . . . . . . . . . . . 17

6 Synthesis and Implementation 186.1 Xilinx Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.1 Synthesis with Xilinx XST . . . . . . . . . . . . . . . . . . . 18

6.1.2 Translate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.3 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.4 Place and Route . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1.5 Bit-file generation . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2 Synthesizing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.1 Synthesis Tool Functionality . . . . . . . . . . . . . . . . . . 19

6.2.2 Generating Post-Synthesis Simulation Model . . . . . . . . . 19

6.3 Translating Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3.1 Translate Process Functionality . . . . . . . . . . . . . . . . 20

6.3.2 Translate Process File Types . . . . . . . . . . . . . . . . . . 20

6.4 Mapping the Design . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.4.1 MAP Process Functionality . . . . . . . . . . . . . . . . . . 21

6.4.2 MAP Process File Types . . . . . . . . . . . . . . . . . . . . 21

6.5 Placing and Routing the Design . . . . . . . . . . . . . . . . . . . . 22

6.5.1 Place and Route Process Functionality . . . . . . . . . . . . 22

6.5.2 PAR Process File Types . . . . . . . . . . . . . . . . . . . . 23

6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


4/31

List of Figures

1.1 Gray code and binary code . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Gray counter top level . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.1 Behavioral simulation with enable = 1, direction = 0, reset = 0 10

4.2 Behavioral simulation with direction = 1 . . . . . . . . . . . . . . 104.3 Behavioral simulation with reset = 0 . . . . . . . . . . . . . . . . . 11

4.4 Behavioral simulation reset = 1, direction = 1 . . . . . . . . . . . 11

4.5 Behavioral simulation with enable down to 0 . . . . . . . . . . . . . 11

4.6 Behavioral simulation with enable return 1 . . . . . . . . . . . . . 11

5.1 Four slide switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.2 Eight Discrete LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.3 Avaiable clock input . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1 Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 Post-Translate Simulation . . . . . . . . . . . . . . . . . . . . . . . 216.3 Post-Map Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.4 Place and Route Simulation . . . . . . . . . . . . . . . . . . . . . . 23

iii


5/31

List of Tables

5.1 Clock inputs and Associated Global Buffers and DCMs . . . . . . . 17

iv


6/31

Abbreviations

FPGA Field Programmable Gate Array

VHDL VHSIC Harware Discription Language

VHSIC Very High Speed Integrated Circuit

CBL Combinational Logic Blocks

IOB Input Output Block

v


7/31

Chapter 1

Gray code

1.1 What is Gray code?

The reflected binary code, also known as Gray code, is a binary numeral system

that uses a different method of incrementing from one number to the next.

The advantage of Gray code is that only one bit changes state from one posi-

tion 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.

1


8/31

Chapter 1. Gray code 2

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 (1.1)

G1 = A1 A2 (1.2)

G2 = A2 A3 (1.3)

G3 = A3 (1.4)


9/31

Chapter 2

Specification

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.

3


10/31

Chapter 2. Specification 4

Figure 2.1: Gray counter top level


11/31

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

l i b r ar y I E EE ;

u s e I E EE . S T D _ L O G I C _1 1 6 4 . A L L ;

u s e I E EE . S T D _ L O G I C _ UN S I G N E D . A LL ;

E N T I TY g r a y c ou n t e r I S

P OR T ( c lk : i n S TD _L OG IC ;

r st _n : i n S TD _L OG IC ;

d ir ec ti on : in S TD _L OG IC ;

e n_ in : i n S TD _L OG IC ;

l e ds _ ou t : o ut S T D_ L O GI C _V E CT O R ( 7 d o wn t o 0 ) );

E N D g r a y co u n t e r ;

A R C H I TE C T U RE s t r u ct u r e O F g r a y co u n t e r I S

S I G NA L b i n a r y_ c n t : S T D _ L OG I C _ V E CT O R ( 3 D O W NT O 0 ) ;

S I G NA L l e d s _ ou t _ s : S T D _ L OG I C _ V E CT O R ( 7 D O W NT O 0 ) ;

B E G I N

5


12/31

Chapter 3. Modeling 6

P R O C ES S ( c lk , r s t _n )

BEGIN

I F r s t_ n = 0 t he n

b i n a ry _ c n t < = " 0 0 0 0 " ;

l e d s _o u t _ s < = " 0 0 0 0 0 0 0 0 " ;

E L S IF r i s i ng _ e d g e ( c lk ) t h en

I F e n_ i n = 1 t h en

I F d i r e ct i o n = 0 t h e n

b i na r y_ c nt < = b i na r y_ c nt + 1 ;

ELSE

b i na r y_ c nt < = b i na r y_ c nt - 1 ;

E ND i f ;

l e ds _ ou t _s ( 3 d o wn t o 0 ) < = ( ( 0 & b i na r y_ c nt ( 3 D O WN T O 1 )) X OR b i

l e d s _ ou t _ s ( 7 D O W NT O 4 ) < = b i n a r y _ c nt ;

E ND i f ;

E ND i f ;

E N D P R O C ES S ;

l e d s _o u t < = l e d s _ o u t _ s ;

E N D s t r u c tu r e ;

3.2 Delay

L I B R AR Y i e ee ;

U S E i e ee . s t d _ l o g i c _1 1 6 4 . A L L ;

U S E i e ee . n u m e r i c _ st d . A L L ;

E N T I TY d e l a y_ c n t I S

P OR T (

clk : IN S T D _ LO G I C ;

r st _n : IN S TD _L OG IC ;

e n_ in : IN S TD _L OG IC ;

e n _o u t : O UT S T D_ L OG I C );

E N D E N T I T Y d e l a y_ c n t ;

A R CH I TE C TU R E r tl O F d e la y _c n t I S

S I GN A L d e la y _r e g : U N SI G NE D ( 23 D O WN T O 0 );

B E G I N - - A R C H IT E C T U RE r t l

d e la y _r e g_ p ro c : P R OC E SS ( c lk , r s t_ n ) I S

B E G I N - - P R O C ES S d e l a y_ r e g

I F r st _n = 0 T HE N

d e la y _r e g < = ( O T H E RS = > 0 ) ;

E L S IF r i s i n g_ e d g e ( c lk ) T H E N

I F e n_ in = 1 T HE N

d e l a y_ r e g < = d e l a y_ r e g + t o _ u ns i g n e d ( 1 , d e l ay _ r eg L E N G TH ) ;


13/31


E ND I F ;

E ND I F ;

E N D P R O C ES S d e l a y _r e g _ p r oc ;

e n _o u t < = 1 W H EN d e la y _r e g = ( d e la y _r e g L E NG T H - 1 D O WN T O 0 = > 1 ) E L SE 0 ;

E N D A R C H IT E C T U RE r t l ;

3.3 Top-level design

L I B R AR Y i e ee ;

U S E i e ee . s t d _ l o g i c _1 1 6 4 . A L L ;

E N T I TY t o p _ le v e l I S

P OR T (


rs t_ n : IN S T D _ LO G I C ;

en _i n : IN S T D _ LO G I C ;

u p_ n_ in : IN S TD _L OG IC ;

l e d s _o u t : O U T S T D _ L OG I C _ V EC T O R ( 7 D O W NT O 0 ) ) ;

E N D E N T I T Y t o p _ le v e l ;

A R CH I TE C TU R E r tl O F t o p_ l ev e l I S

C O M P ON E N T d e l a y_ c n t I S

P OR T (


r st _n : IN S TD _L OG IC ;

e n_ in : IN S TD _L OG IC ;

e n _o u t : O UT S T D_ L OG I C );

E N D C O M P ON E N T d e l a y_ c n t ;

C O M P ON E N T g r a y c ou n t e r I S

P OR T (

clk : IN S T D _L O G I C ;

rs t_n : IN S T D _L O G I C ;

d i re c ti o n : I N S T D_ L OG I C ;

en _in : IN S T D _L O G I C ;

l e ds _ ou t : O UT S T D _L O GI C _V E CT O R ( 7 D O WN T O 0 ) );

E N D C O M P ON E N T g r a y c ou n t e r ;

S I G NA L d e l a y _e n _ o ut : S T D _ LO G I C ;

B E G I N - - A R C H IT E C T U RE r t l


14/31


d e l a y_ c n t _ 1 : E N T IT Y w o r k . d e l ay _ c n t

P OR T M AP (

clk = > clk ,

r st _n = > rs t_n ,

e n_ in = > en _in ,

e n _ ou t = > d e l a y _e n _ o u t ) ;

c o u n te r _ 1 : E N T IT Y w o rk . g r a y c o u n te r

P OR T M AP (

clk = > clk ,

rs t_n = > rst_n ,

d i re c ti o n = > u p_ n_ in ,

e n_ in = > d el ay _e n_ ou t ,

l e d s _o u t = > l e d s _o u t ) ;

E N D A R C H IT E C T U RE r t l ;


15/31

Chapter 4

Behavioral simulation

4.1 Testbench

Test bench is not defined by the VHDL Language Reference Manual and has no

formal definition. 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 specification in VHDL

4.2 Test vector generation

As mentioned before, there are three control signals that effect the systems opera-

tion. 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


16/31

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 figure 4.1 to 4.6 corresponding to case 1 to case 6:


17/31

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


18/31

Chapter 5

User constraints

5.1 PERIOD constraints

The PERIOD constraints is a fundamental timing and synthesis constraint. PE-

RIOD constraints:

Define each clock within the design.

Cover all synchronous paths within each clock domain.

Define the duaration of clock.

Can be configured to have different duty cycles.

12


19/31

Chapter 5. User constraints 13

Figure 5.1: Four slide switches

5.2 Pin assignment

5.2.1 Slide Switches

5.2.1.1 Locations and Labels

The Spartan-3E Starter Kit board has four slide switches, as show in figure 5.1.

The slide switches are located in the lower right corner of the board and are la-

beled 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


20/31


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 " LOC = " L13 " | IO ST AN DA RD = L VTTL | P ULL UP ;

N ET " en _i n" L OC = "H 18 " | I OS TA ND AR D = LV TT L | P UL LU P;

N ET " u p _n _i n " L OC = " L 1 4 " | I O ST AN DA RD = L VT TL | P UL LU P ;

5.2.2 Discrete LEDs

5.2.2.1 Location and Labels

The Spartan-3E Starter Kit board has eight individual surface-mount LEDs lo-

cated above the slide switches as show in figure 5.2.

The LEDs are labeled LED7 through LED0 inwhich LED7 is the most LED, LED0

is the right-most LED.


21/31


22/31


Figure 5.3: Avaiable clock input

The board includes an on-board 50 MHz clock oscillator.

Clocks can be supplied off-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 buffer 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.


23/31


Table 5.1: Clock inputs and Associated Global Buffers and DCMs

Clock Input FPGA pin Global Buffer Associated DCMs

CLK50M HZ C 9 GCLK10 DC MX0Y1CLKAU X B

8GCLK

8DC MX

0Y

1CLKSM A A10 GCLK7 DC MX1Y1

5.2.3.3 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 :

N ET " c lk " L OC = " C9 " | I OS TA ND AR D = L VC MO S3 3 ;

N ET " c lk " P E RI O D = 1 0 ns H IG H 4 0 %;


24/31

Chapter 6

Synthesis and Implementation

6.1 Xilinx Flow Overview

6.1.1 Synthesis with Xilinx XST

In this step, HDL design entry will be converted to equivalent boolean equationsaccording to which logic gates are then correspondingly packed into Logic Cells,

LUTs and Flip-flops 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-defined Constraints file, for any inconsis-

tencies.

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


25/31

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 Specification are met.

6.1.5 Bit-file generation

The result of bit-file generation step is bit-stream file that containing configuration

data for target FPGA device.

6.2 Synthesizing Design

6.2.1 Synthesis Tool Functionality

During synthesis, HDL files are translated into gates and optimized for the tar-

get 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 file (.sdf

file) is back-annotated during simulation.(Thus, UNISIM Library primitives, in-

cluded in the synthesis generated netlist, do not have any delay associated with

it). Therefore, expected Post-Synthesis Simulation result is same as Functional

Verification result of HDL Design.

After synthesizing completes successfully by using Generate Post-Synthesis

Simulation Model, synthesis file will be generated in to direction /netgen/syn-

thesis. The simulation of this file have been done and shown in figure 6.1


26/31


Figure 6.1: Post-Synthesis Simulation

6.3 Translating Design

6.3.1 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 specification 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 file as input:

NGC netlist file from Synthesis Process.

UCF constraint file containing timing and layout constraints.

Translate Process uses following file as output:

NGD file, containing logical description of the design, expressed in terms oflower level Xilinx Primitives, with constraint applied to design.


27/31


Figure 6.2: Post-Translate Simulation

BLD Report file shows following error in design or UCF file.

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

ulation Model under Implementation design Translate, translate file will

be generated in to direction /netgen/translate. The simulation of translate file

is shown in figure 6.2.

6.4 Mapping the Design

6.4.1 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 opti-

mizations, and runs a design rule check on theresulting mapped netlist.

6.4.2 MAP Process File Types

MAP Process uses NGD file, created during Translate Process, as Input file.

MAP Process creates following files as output.


28/31


Figure 6.3: Post-Map Simulation

NCD (Native Circuit Description) file containing physical description of de-

sign in terms of the components in the target Xilinx device

PCF (Physical Constraints File) contains constraints specified during design

entry expressed in terms of physical elements.

MRP (MAP Report File) confirms 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 file will be generated in to direction /netgen/map. The simulation

of this file have been done and shown in figure 6.3

6.5 Placing and Routing the Design

6.5.1 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


29/31


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)file

created during MAP Process, as Input File

PAR Process creates following files as output

Placed and Routed NCD Design File.

PCF (Physical Constraints File) contains constraints specified during design

entry expressed in terms of physical elements.

PAR Report File, including summary information of all placementand rout-

ing iterations

After Place and Route completes successfully by using Generate Post-Place

Simulation Model, timesim file will be generated in to direction /netgen/par.

The simulation of this file have been done and shown in figure 6.4

6.6 Conclusion

In conclusion, expected Post-Synthesis Simulation and Post-Translate Simulation

results are the same as Functional Verification 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 file containing logic/routing delay

information are back-annotated to the netlist, simulation waveform result shows


30/31


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

the design.


31/31

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

ware Manuals(v 12.4) December 14, 2010, http://www.xilinx.com/support/

documentation/sw_manuals/xilinx12_4/manuals.pdf
http://www.xilinx.com/support/documentation/boards_and_kits/ug230.pdfhttp://www.xilinx.com/support/documentation/boards_and_kits/ug230.pdfhttp://www.xilinx.com/support/documentation/sw_manuals/xilinx12_4/manuals.pdfhttp://www.xilinx.com/support/documentation/sw_manuals/xilinx12_4/manuals.pdfhttp://www.xilinx.com/support/documentation/sw_manuals/xilinx12_4/manuals.pdfhttp://www.xilinx.com/support/documentation/sw_manuals/xilinx12_4/manuals.pdfhttp://www.xilinx.com/support/documentation/boards_and_kits/ug230.pdfhttp://www.xilinx.com/support/documentation/boards_and_kits/ug230.pdf

Documents

NguyenNgocHoang_GrayCounter