IMPROVEMENT OF THE ORTHOGONAL CODE CONVOLUTION

CAPABILITIES USING FPGA IMPLEMENTATION

When data is stored, compressed, or communicated through a media such as cable or air,

sources of noise and other parameters such as EMI, crosstalk, and distance can considerably

affect the reliability of these data. Error detection and correction techniques are therefore

required. Some of those techniques can only detect errors, such as the Cyclic Redundancy

Check; others are designed to detect as well as correct errors, such as Salomon Codes.

However, the existing techniques are not able to achieve high efficiency and to meet

bandwidth requirements, especially with the increase in the quantity of data transmitted.

Orthogonal Code is one of the codes that can detect errors and correct corrupted data.

CYCLIC REDUNDANCY CHECK

The CRC check is used to detect errors in a message. Two implementations are shown:

• Table driven CRC calculation

• Loop driven CRC calculation

This application describes the implementation of the CRC-16 polynomial. However, there are

several formats for the implementation of CRC such as CRC-CCITT, CRC-32 or other

polynomials. CRC is a common method for detecting errors in transmitted messages or stored

data. The CRC is a very powerful, but easily implemented technique to obtain data reliability.

THEORY OF OPERATION

The theory of a CRC calculation is straight forward. The data is treated by the CRC algorithm

as a binary number. This number is divided by another binary number called the polynomial.

The rest of the division is the CRC checksum, which is appended to the transmitted message.

The receiver divides the message (including the calculated CRC), by the same polynomial the

transmitter used. If the result of this division is zero, then the transmission was successful.

However, if the result is not equal to zero, an error occurred during the transmission. The

CRC-16 polynomial is shown in Equation 1. The polynomial can be translated into a binary

value, because the divisor is viewed as a polynomial with binary coefficients. For example,

the CRC-16 polynomial translates to 1000000000000101b. All coefficients, like x2 or x15,

are represented by a logical 1 in the binary value. The division uses the Modulo-2 arithmetic.

Modulo-2 calculation is simply realized by XOR’ing two numbers.

EQUATION 1: THE CRC-16 POLYNOMIAL

EXAMPLE 1: MODULO-2 CALCULATION

Example Calculation

In this example calculation, the message is two bytes long. In general, the message can have

any length in bytes. Before we can start calculating the CRC value 1, the message has to be

augmented by n-bits, where n is the length of the polynomial. The CRC-16 polynomial has a

length of 16-bits, therefore, 16-bits have to be augmented to the original message. In this

example calculation, the polynomial has a length of 3-bits, therefore, the message has to be

extended by three zeros at the end. An example calculation for a CRC is shown in Example 1.

The reverse calculation is shown in Example 2.

EXAMPLE 2: CALCULATION FOR GENERATING A CRC

EXAMPLE 3: CHECKING A MESSAGE FOR A CRC ERROR

Figure1: HARDWARE CRC-16 GENERATOR

Figure2: LOOP DRIVEN CRC IMPLEMENTATION

HARDWARE IMPLEMENTATION

The CRC calculation is realized with a shift register and XOR gates. Figure 1 shows a CRC

generator for the CRC-16 polynomial. Each bit of the data is shifted into the CRC shift

register (Flip-Flops) after being XOR’ed with the CRC’s most significant bit.

SOFTWARE IMPLEMENTATIONS

There are two different techniques for implementing a CRC in software. One is a loop driven

implementation and the other is a table driven implementation. The loop driven

implementation works like the calculation shown in Figure 2. The data is fed through a shift

register. If a one pops out at the MSB, the content is XORed with the polynomial. In the

other, the registers are shifted by one position to the left. Another method to calculate a CRC

is to use pre-calculated values and XOR them to the shift register.

ADVANTAGES OF CRC Vs SIMPLE SUM TECHNIQUES

The CRC generation has many advantages over simple sum techniques or parity check. CRC

error correction allows detection of:

1. Single bit errors

2. Double bit errors

3. Bundled bit errors (bits next to each other)

A parity bit check detects only single bit errors. The CRC error correction is mostly used

where large data packages are transmitted, for example, in local area networks such as

Ethernet.

REED–SOLOMON ERROR CORRECTION

In coding theory, Reed–Solomon (RS) codes are non-binary cyclic error-correcting codes

invented by Irving S. Reed and Gustave Solomon. They described a systematic way of

building codes that could detect and correct multiple random symbol errors. By adding t

check symbols to the data, an RS code can detect any combination of up to t erroneous

symbols, and correct up to ⌊t/2⌋ symbols. As an erasure code, it can correct up to t known

erasures, or it can detect and correct combinations of errors and erasures. Furthermore, RS

codes are suitable as multiple-burst bit-error correcting codes, since a sequence of b+1

consecutive bit errors can affect at most two symbols of size b. The choice of t is up to the

designer of the code, and may be selected within wide limits.

In Reed-Solomon coding, source symbols are viewed as coefficients of a polynomial p(x)

over a finite field. The original idea was to create n code symbols from k source symbols by

oversampling p(x) at n > k distinct points, transmit the sampled points, and use interpolation

techniques at the receiver to recover the original message. That is not how RS codes are used

today. Instead, RS codes are viewed as cyclic BCH codes, where encoding symbols are

derived from the coefficients of a polynomial constructed by multiplying p(x) with a cyclic

generator polynomial. This gives rise to an efficient decoding algorithm, which was

discovered by Elwyn Berlekamp and James Massey, and is known as the Berlekamp-Massey

decoding algorithm.

Reed-Solomon codes have since found important applications from deep-space

communication to consumer electronics. They are prominently used in consumer electronics

such as CDs, DVDs, Blu-ray Discs, in data transmission technologies such as DSL &

WiMAX, in broadcast systems such as DVB and ATSC, and in computer applications such as

RAID 6 systems.

ORTHOGONAL CODES

Orthogonal codes are binary valued and they have equal number of 1’s and 0’s. An n-bit

orthogonal code has n/2 1’s and n/2 0’s; i.e., there are n/2 positions where 1’s and 0’s differ.

Therefore, all orthogonal codes will generate zero parity bits. The concept is illustrated by

means of an 8- bit orthogonal code as shown in Fig.3. It has 8-orthogonal codes and 8-

antipodal codes for a total of 16-biorthogonal codes. Antipodal codes are just the inverse of

orthogonal codes; they are also orthogonal among themselves.

Fig. 2. Illustrations of the proposed concept. An 8-bit orthogonal code has 8 orthogonal codes

and 8-antipodal codes for a total of 16 bi-orthogonal codes. All orthogonal and antipodal

codes generate zero parity.

Since there is an equal number of 1’s and 0’s, each orthogonal code will generate a zero

parity bit. Therefore, each antipodal code will also generate a zero parity bit. A notable

distinction in this method is that the transmitter does not have to send the parity bit since the

parity bit is known to be always zero. Therefore, if there is a transmission error, the receiver

will be able to detect it by generating a parity bit at the receiving end. Before transmission a

k-bit data set is mapped into a unique n-bit. For example, a 4-bit data set is represented by a

unique 8-bit orthogonal code which is transmitted without the parity bit.

When received, the data are decoded based on code correlation. It can be done by setting a

threshold midway between two orthogonal codes. This is given by the following equation

(1)

Where n is the code length and dth is the threshold, which is midway between two orthogonal

codes. Therefore, for the 8-bit orthogonal code (Fig. 4), we have dth = 8/4 = 2.

Fig. 4. Illustration of Encoding and Decoding.

(2)

From the equ(2), t is the number of errors that can be corrected by means of an n-bit

orthogonal code. For example, a single error-correcting orthogonal code can be constructed

by means of an 8-bit orthogonal code (n = 8). Similarly, a three-error correcting orthogonal

code can be constructed by means of a 16-bit orthogonal code (n = 16), and so on. Table-1

below shows a few orthogonal codes and the corresponding error correcting capabilities:

n t

8 1

16 3

32 7

64 15

TABLE I- Orthogonal Codes and the Corresponding Chip Error Control Capabilities.

DESIGN METHODOLOGY

Since there is an equal number of 1’s and 0’s, each orthogonal code will generate a zero

parity bit. If the data has been corrupted during the transmission the receiver can detect errors

by generating the parity bit for the received code and if it is not zero then the data is

corrupted. However the parity bit doesn’t change for an even number of errors, hence the

receiver can only detect errors 2n /2 combinations of the received code. Therefore detection

percentage is 50% . Our approach is not to use the parity generation method to detect the

errors, but a simple technique based on the comparison between the received code and all the

orthogonal code combinations stored in a look up table. The technique which involves a

i) Transmitter and

ii) Receiver.

TRANSMITTER

The transmitter includes two blocks: an encoder and a shift register. The encoder encodes a k-

bit data set to n=2k-1 bits of the orthogonal code and the shift register transforms this code to

a serial data in order to be transmitted as shown in Fig.5. For example, 4-bit data is encoded

to 8-bit (23) orthogonal code according to the lookup table shown in Fig.4. The generated

orthogonal code is then transmitted serially using a shift register with the rising edge of the

clock.

Fig. 5. Block diagram of the transmitter.

For an example it the transmitter transmit the input data value “0110” labeled as ‘data’. This

data has been encoded to the associated orthogonal code “00111100” labeled ‘ortho’. The

signal ‘EN’ is used to enable the transmission of the serial bits ‘txcode’ of the orthogonal

code with every rising edge of the clock.

SHIFT REGISTERS

Shift Registers consists of a number of single bit "D-Type Data Latches" connected together

in a chain arrangement so that the output from one data latch becomes the input of the next

latch and so on, thereby moving the stored data serially from either the left or the right

direction. The number of individual Data Latches used to make up Shift Registers are

determined by the number of bits to be stored with the most common being 8-bits wide. Shift

Registers are mainly used to store data and to convert data from either a serial to parallel or

parallel to serial format with all the latches being driven by a common clock (Clk) signal

making them Synchronous devices. They are generally provided with a Clear or Reset

connection so that they can be "SET" or "RESET" as required.

Generally, Shift Registers operate in one of four different modes:

Serial-in to Parallel-out (SIPO)

Serial-in to Serial-out (SISO)

Parallel-in to Parallel-out (PIPO)

Parallel-in to Serial-out (PISO)

SERIAL-IN TO PARALLEL-OUT

4-bit Serial-in to Parallel-out (SIPO) Shift Register

Lets assume that all the flip-flops (FFA to FFD) have just been RESET (CLEAR input) and

that all the outputs QA to QD are at logic level "0" ie, no parallel data output. If a logic "1" is

connected to the DATA input pin of FFA then on the first clock pulse the output of FFA and

the resulting QA will be set HIGH to logic "1" with all the other outputs remaining LOW at

logic "0". Assume now that the DATA input pin of FFA has returned LOW to logic "0". The

next clock pulse will change the output of FFA to logic "0" and the output of FFB and QB

HIGH to logic "1". The logic "1" has now moved or been "Shifted" one place along the

register to the right. When the third clock pulse arrives this logic "1" value moves to the

output of FFC (QC) and so on until the arrival of the fifth clock pulse which sets all the

outputs QA to QD back again to logic level "0" because the input has remained at a constant

logic level "0".

Clock Pulse No QA QB QC QD

0 0 0 0 0

1 1 0 0 0

2 0 1 0 0

3 0 0 1 0

4 0 0 0 1

5 0 0 0 0

The effect of each clock pulse is to shift the DATA contents of each stage one place to the

right, and this is shown in the following table until the complete DATA is stored, which can

now be read directly from the outputs of QA to QD. Then the DATA has been converted

from a Serial Data signal to a Parallel Data word.

SERIAL-IN TO SERIAL-OUT

This Shift Register is very similar to the one above except where as the data was read directly

in a parallel form from the outputs QA to QD, this time the DATA is allowed to flow straight

through the register. Since there is only one output the DATA leaves the shift register one bit

at a time in a serial pattern and hence the name Serial-in to Serial-Out Shift Register.

4-bit Serial-in to Serial-out (SISO) Shift Register

This type of Shift Register also acts as a temporary storage device or as a time delay device,

with the amount of time delay being controlled by the number of stages in the register, 4, 8,

16 etc or by varying the application of the clock pulses. Commonly available IC's include the

74HC595 8-bit Serial-in/Serial-out Shift Register with 3-state outputs.

PARALLEL-IN TO SERIAL-OUT

Parallel-in to Serial-out Shift Registers act in the opposite way to the Serial-in to Parallel-out

one above. The DATA is applied in parallel form to the parallel input pins PA to PD of the

register and is then read out sequentially from the register one bit at a time from PA to PD on

each clock cycle in a serial format.

4-bit Parallel-in to Serial-out (PISO) Shift Register

As this type of Shift Register converts parallel data, such as an 8-bit data word into serial data

it can be used to multiplex many different input lines into a single serial DATA stream which

can be sent directly to a computer or transmitted over a communications line. Commonly

available IC's include the 74HC165 8-bit Parallel-in/Serial-out Shift Registers.

PARALLEL-IN TO PARALLEL-OUT

Parallel-in to Parallel-out Shift Registers also act as a temporary storage device or as a time

delay device. The DATA is presented in a parallel format to the parallel input pins PA to PD

and then shifts it to the corresponding output pins QA to QD when the registers are clocked.

4-bit Parallel-in/Parallel-out (PIPO) Shift Register

As with the Serial-in to Serial-out shift register, this type of register also acts as a temporary

storage device or as a time delay device, with the amount of time delay being varied by the

frequency of the clock pulses.

Today, high speed bi-directional universal type Shift Registers such as the TTL 74LS194,

74LS195 or the CMOS 4035 are available as a 4-bit multi-function devices that can be used

in serial-serial, shift left, shift right, serial-parallel, parallel-serial, and as a parallel-parallel

Data Registers, hence the name "Universal".

RECEIVER

The received code is processed through the sequential steps, as shown in Fig.4. The incoming

serial bits are converted into n-bit parallel codes. The received code is compared with all the

codes in the lookup table for error detection. This is done by counting the number of ones in

the signal resulting from ‘XOR’ operation between the received code and each combination

of the orthogonal codes in the lookup table. A counter is used to count the number of ones in

the resulting nbit signal and also searches for the minimum count. However a value rather

than zero shows an error in the received code. The orthogonal code in the lookup table which

is associated with the minimum count is the closest match for the corrupted received code.

The matched orthogonal code in the lookup table is the corrected code, which is then decoded

to k-bit data. The receiver is able to correct up to (n/4)-1 bits in the received impaired code.

However, if the minimum count is associated with more than one combination of orthogonal

code then a signal, REQ, goes high.

Fig. 4. Block diagram of the receiver

Upon reception, the incoming serial data is converted into 8-bit parallel code ‘rxcode’.

Counter is used to count the number of 1’s after XOR operation between the received code

and all combinations of orthogonal code in the lookup table. ‘Count’ gives the minimum

count of one’s among them. The orthogonal code ‘ortho’ associated with the minimum count

is the closest match for the received code, which is then decoded to the final data given by

signal ‘data’. Three different cases result from this simulation. In the first case, the received

code has a match in the lookup table.

For example, if the received code is rxcode= “00111100”, count=’0’ and hence the received

code is not corrupted. The code is then decoded to the corresponding final data “0110”. In the

second case, the received code has no match in the lookup table.

If the received code is rxcode=“00110100”, the value of minimum count is ’1’, which reveals

an error. The corresponding orthogonal code is ortho= “00111100” which is the closest match

for the received code given by the minimum count, and the decoded final data is “0110”. In

this case the single bit error is detected and corrected by the receiver.

In the third case, there is more than one possibility of closest match in the lookup table.If, the

received code is rxcode= “00110000”. The value of minimum count is associated with more

than one orthogonal code and thus it is not possible to determine the closest match in the

lookup table for the received code. Then the signal labelled ‘REQ’ goes high, which is a

request for a retransmission.

COUNTERS

In digital logic and computing, a counter is a device which stores (and sometimes displays)

the number of times a particular event or process has occurred, often in relationship to a clock

signal. In practice, there are two types of counters:

Up counters, which increase (increment) in value

Down counters, which decrease (decrement) in value

Toggle flip-flop. Output is not shown. Red=1, blue=0

In electronics, counters can be implemented quite easily using register-type circuits such as

the flip-flop, and a wide variety of designs exist, e.g:

Asynchronous (ripple) counter – changing state bits are used as clocks to subsequent state

flip-flops

Synchronous counter – all state bits change under control of a single clock

Decade counter – counts through ten states per stage

Up–down counter – counts both up and down, under command of a control input

Ring counter – formed by a shift register with feedback connection in a ring

Johnson counter – a twisted ring counter

Cascaded counter

Each is useful for different applications. Usually, counter circuits are digital in nature, and

count in natural binary. Many types of counter circuit are available as digital building blocks,

for example a number of chips in the 4000 series implement different counters.

Occasionally there are advantages to using a counting sequence other than the natural binary

sequence -- such as the binary coded decimal counter, a linear feedback shift register counter,

or a Gray-code counter.

Counters are useful for digital clocks and timers, and in oven timers, VCR clocks, etc.[1]

ASYNCHRONOUS (RIPPLE) COUNTER

Asynchronous counter created from JK flip-flops

An asynchronous (ripple) counter is a single D-type flip-flop, with its D (data) input fed from

its own inverted output. This circuit can store one bit, and hence can count from zero to one

before it overflows (starts over from 0). This counter will increment once for every clock

cycle and takes two clock cycles to overflow, so every cycle it will alternate between a

transition from 0 to 1 and a transition from 1 to 0. Notice that this creates a new clock with a

50% duty cycle at exactly half the frequency of the input clock. If this output is then used as

the clock signal for a similarly arranged D flip-flop (remembering to invert the output to the

input), you will get another 1 bit counter that counts half as fast. Putting them together yields

a two bit counter:

Cycle Q1 Q0 (Q1:Q0)dec

0 0 0 0

1 0 1 1

2 1 0 2

3 1 1 3

4 0 0 0

You can continue to add additional flip-flops, always inverting the output to its own input,

and using the output from the previous flip-flop as the clock signal. The result is called a

ripple counter, which can count to 2n-1 where n is the number of bits (flip-flop stages) in the

counter. Ripple counters suffer from unstable outputs as the overflows "ripple" from stage to

stage, but they do find frequent application as dividers for clock signals, where the

instantaneous count is unimportant, but the division ratio overall is. (To clarify this, a 1-bit

counter is exactly equivalent to a divide by two circuit; the output frequency is exactly half

that of the input when fed with a regular train of clock pulses).

The use of flip-flop outputs as clocks leads to timing skew between the count data bits,

making this ripple technique incompatible with normal synchronous circuit design styles.

SYNCHRONOUS COUNTER

A 4-bit synchronous counter using J-K flip-flops

Wdware-based counters are of this type.

A simple way of implementing the logic for each bit of an ascending counter (which is what

is depicted in the image to the right) is for each bit to toggle when all of the less significant

bits are at a logic high state. For example, bit 1 toggles when bit 0 is logic high; bit 2 toggles

when both bit 1 and bit 0 are logic high; bit 3 toggles when bit 2, bit 1 and bit 0 are all high;

and so on.

Synchronous counters can also be implemented with hardware finite state machines, which

are more complex but allow for smoother, more stable transitions.

Please note that the counter shown will have an error once it reaches 1110.

RING COUNTER

A ring counter is a shift register (a cascade connection of flip-flops) with the output of the

last one connected to the input of the first, that is, in a ring. Typically a pattern consisting of a

single 1 bit is circulated, so the state repeats every N clock cycles if N flip-flops are used. It

can be used as a cycle counter of N states.

JOHNSON COUNTER

A Johnson counter (or switchtail ring counter, twisted-ring counter, walking-ring counter, or

Moebius counter) is a modified ring counter, where the output from the last stage is inverted

and fed back as input to the first stage.[2][3][4] A pattern of bits equal in length to twice the

length of the shift register thus circulates indefinitely. These counters find specialist

applications, including those similar to the decade counter, digital to analog conversion, etc.

DECADE COUNTER

A decade counter is one that counts in decimal digits, rather than binary. A decimal counter

may have each digit binary encoded (that is, it may count in binary-coded decimal, as the

7490 integrated circuit did) or other binary encodings (such as the bi-quinary encoding of the

7490 integrated circuit). Alternatively, it may have a "fully decoded" or one-hot output code

in which each output goes high in turn; the 4017 was such a circuit. The latter type of circuit

finds applications in multiplexers and demultiplexers, or wherever a scanning type of

behavior is useful. Similar counters with different numbers of outputs are also common.

The decade counter is also known as a mod-10 counter.

UP–DOWN COUNTER

A counter that can change state in either direction, under control an up–down selector input,

is known as an up–down counter. When the selector is in the up state, the counter increments

its value; when the selector is in the down state, the counter decrements the count.

NEED FOR TESTING

As the density of VLSI products increases, their testing becomes more difficult and costly.

Generating test patterns has shifted from a deterministic approach, in which a testing pattern

is generated automatically based on a fault model and an algorithm, to a random selection of

test signals. While in real estate the refrain is “Location!” the comparable advice in IC design

should be “Testing! Testing! Testing!”. No matter whether deterministic or random

generation of testing patterns is used, the testing pattern applied to the VLSI chips can no

longer cover all possible defects. Consider the manufacturing processes for VLSI chips as

shown in Fig. 16. Two kinds of cost can incur with the test process: the cost of testing and the

cost of accepting an imperfect chip. The first cost is a function of the time spent on testing or,

equivalently, the number of test patterns applied to the chip. The cost will add to the cost of

the chips themselves. The second cost represents the fact that, when a defective chip has been

passed as good, its failure may become very costly after being embedded in its application.

An optimal testing strategy should trade off both costs and determine an adequate test length

(in terms of testing period or number of test patterns).

Figure 6: Chip Manufacturing and testing flow

Apart from the cost, two factors need to be considered when determining the test lengths. The

first is the production yield, which is the probability that a product is functionally correct at

the end of the manufacturing process. If the yield is high, we may not need to test extensively

since most chips tested will be “good,” and vice versa. The other factor to be considered is

the coverage function of the test process. The coverage function is defined as the probability

of detecting a defective chip given that it has been tested for a particular duration or a given

number of test patterns. If we assume that all possible defects can be detected by the test

process, the coverage function of the test process can be regarded as a probability distribution

function of the detection time given the chip under test is bad. Thus, by investigating the

density function or probability mass function, we should be able to calculate the marginal

gain in detection if the test continues. In general, the coverage function of a test process can

be obtained through theoretical analysis or experiments on simulated fault models. With a

given production yield, the fault coverage requirement to attain a specified defect level,

which is defined as the probability of having a “bad” chip among all chips passed by a test

process

While most problems in VLSI design has been reduced to algorithm in readily available

software, the responsibilities for various levels of testing and testing methodology can be

significant burden on the designer.

The yield of a particular IC was the number of good die divided by the total number of

die per wafer. Due to the complexity of the manufacturing process not all die on a wafer

correctly operate. Small imperfections in starting material, processing steps, or in

photomasking may result in bridged connections or missing features. It is the aim of a

test procedure to determine which die are good and should be used in end systems.

Testing a die can occur:

At the wafer level

At the packaged level

At the board level

At the system level

In the field

By detecting a malfunctioning chip at an earlier level, the manufacturing cost may be

kept low. For instance, the approximate cost to a company of detecting a fault at the

above level is:

Wafer $0.01- $.1

Packaged-chip $0.10-$1

Board $1-$10

System $10-$100

Field $100-$1000

Obviously, if faults can be detected at the wafer level, the cost of manufacturing is kept

the lowest. In some circumstances, the cost to develop adequate tests at the wafer level,

mixed signal requirements or speed considerations may require that further testing be

done at the packaged-chip level or the board level. A component vendor can only test the

wafer or chip level. Special systems, such as satellite-borne electronics, might be tested

exhaustively at the system level.

Tests may fall into two main categories. The first set of tests verifies that the chip

performs its intended function; that is, that it performs a digital filtering function, acts as

a microprocessor, or communicates using a particular protocol. In other words, these tests

assert that all the gates in the chip, acting in concert, achieve a desired function. These

tests are usually used early in the design cycle to verify the functionality of the circuit.

These will be called functionality tests. The second set of tests verifies that every gate

and register in the chip functions correctly. These tests are used after the chip is

manufactured to verify that the silicon in intact. They will be called manufacturing tests.

In many cases these two sets of tests may be one and the same, although the natural flow

of design usually has a designer considering function before manufacturing concerns.

MANUFACTURING TEST PRINCIPLES

A critical factor in all LSI and VLSI [2] design is the need to incorporate methods of

testing circuits. This task should proceed concurrently with any architectural

considerations and not be left until fabricated parts are available.

Figure 7(a) shows a combinational circuit with n-inputs. To test this circuit exhaustively

a sequence of 2^n inputs must be applied and observed to fully exercise the circuit. This

combinational circuit is converted to a sequential circuit with addition of m-storage

registers, as shown in figure 3(b) the state of the circuit is determined by the inputs and

the previous state. A minimum of 2^ (n+m) test vectors must be applied to exhaustively

test the circuit. Clearly, this is an important area of design that has to be well understood.

n n

2^n inputs required to exhaustively test circuit (a)

CombinationalLogic

Register

n n

m m

Clk

2^(n+m) inputs required to exhaustively test circuitFor n=25 m=50 1micro seconds/test, the test time is oner 1 billion years

(b)Figure 7. The combinational explosion in test vectors

OPTIMAL TESTING

With the increased complexity of VLSI circuits, testing has become more costly and time-

consuming. The design of a testing strategy, which is specified by the testing period based on

the coverage function of the testing algorithm, involves trading off the cost of testing and the

penalty of passing a bad chip as good. The optimal testing period is first derived, assuming

the production yield is known. Since the yield may not be known a priori, an optimal

sequential testing strategy which estimates the yield based on ongoing testing results, which

in turn determines the optimal testing period, is developed next. Finally, the optimal

sequential testing strategy for batches in which N chips are tested simultaneously is

presented. The results are of use whether the yield stays constant or varies from one

manufacturing run to another.

TESTING PRINCIPLES

Importance of Testing

According to the Moores law the scale of the IC’s doubles for every 18 months. In 1980’s the

term Very Large Scale Integration (VLSI) was used for chips having more than 100,000 of

transistors. In general, the micro processors produced in 1994 has 3 million transistors and in

present computers there are many millions of transistors and are likely to be increased for

future needs. This vast increase of transistors has reduced the size of chip; this is known as

feature size. As the reduction in feature size increases the number of manufacturing defects in

CombinationalLogic

the IC. Performance, area, power, testing are some of the important attributes of complex

VLSI systems.

Testing of the circuit should be done as early as possible in the design cycle with efficient test

generation patterns which reduce the cost of testing without the compromise of fault

coverage. Many test pattern generation methods used for thisurpose are Random Pattern

Testing, Pseudorandom Testing and Pseudo-Exhaustive Testing have been developed, aiming

to reduce the test pattern length.

Testing is used not only to find the fault-free devices, Printed Circuit Boards (PCBs) and

systems but also to improve production yield at the various stages of manufacturing by

analyzing the cause of defects when faults are encountered. In some systems, periodic testing

is performed to ensure fault-free system operation and to initiate repair procedures when

faults are detected. A fault in a circuit causes the circuit to fail. A failure is the deviation of

the circuit from its original behaviour.

Testing Categories

Testing may fall into different categories depending on the intended goal. Some categories

are explained.

Functional testing

Applying the test vectors to the circuit under test and analysing the output responses of the

circuit to determine the functionality of the circuit. Here the internal structures need not to be

known.

Structural testing

The testing based on the circuit structural information and the set of fault models used. The

structural test tries to find physical defects of the circuit by propagating faults to the output.

This approach is called structural testing.

The selection of fault model used depends on the fault coverage and fault detection

efficiency. Improving the fault coverage can be easier and less expensive than improving the

manufacturing yield. Therefore generating the test stimuli with high fault coverage is very

important. Fault models are needed for fault simulation as well as test generation.

Different physical faults in a circuit namely, Stuck-at-faults (stuck-at-one, stuck-at-zero),

Transistor faults, Open and short circuit fault, bridging faults etc.

Test Pattern Generation Methods

Test patterns are used for testing the circuit. The most commonly used test pattern generation

methods are discussed below.

Exhaustive Testing

There are several testing approaches; the most naive method is the Exhaustive Testing. It

feeds the circuit with all the 2^n (n number of inputs) and checks the response of the circuit.

Exhaustive testing provides complete fault coverage and very easily implemented for

combinational circuits. The problem is with sequential circuits as this circuit consists of

storage elements and the numbers of test patterns required are more.

Pseudo Exhaustive Testing

This method is a slight modification of Exhaustive testing allows us to test the circuit without

the use of 2^n test patterns. The circuit is divided into several possibly overlapping cones,

which are logic elements that influence individual outputs of the circuit. Then, all the cones

are separately tested exhaustively, and hereby also the whole circuit is completely tested. The

only fault not covered by this model is bridging faults between elements belonging to

different non-overlapping cones. If such an efficient decomposition is possible, the circuit can

be tested with much less than 2^n test patterns.

Pseudo Random Testing

In Pseudo random Testing the test patterns are generated by a Pseudo Random Pattern

Generator (PRPG) and apply them to the circuit’s input pin. The difference between the

Exhaustive and this method is the test pattern length. If the PRPG structure and seed are

properly chosen, only few test patterns (less than 2^n) are necessary to completely test the

circuit.

In pseudo-random testing methods the pseudo-random code words generated by a PRPG are

being transformed by some additional logic (combinational or sequential) in order to reach

better fault coverage. Such methods are the reseeding-based techniques, weighted testing, bit-

fixing, bit-flipping, and others. These methods are often being referenced as a mixed-mode

BIST.

Reseeding:

In this method the LFSR is seeded with more than one seeds during the test, this seeds are

stored in the Read Only Memory (ROM). The seeds are smaller than the test pattern

generators and more than one test patterns are derived from one seed. By doing this the

memory requirements are reduced. If a standard LFSR is used as a test pattern generator, it is

not always possible to find the seed producing the required test patterns. A solution to this

problem is to use a Multi polynomial LFSR (MP LFSR), where the feedback network can be

adjusted. Both the seeds and polynomials are stored in a ROM memory and for each LFSR

seed also a unique LFSR polynomial are selected. The structure of such a TPG is shown in

Figure 18.

Figure 8. Multi polynomial BIST

This idea has been extended where the folding counter, which is a programmable counter, is

used as a PRPG. Here the number of folding seeds to be stored in ROM is even more

minimized.

In spite of all these techniques reducing memory overhead, implementation of a ROM on a

chip is still very area demanding and thus the ROM memory should be completely eliminated

in BIST.

Weighted Pattern BIST

In this method two problems have to be solved: first, the weight sets have to be computed and

then how to generate the weighted signals. Many weight set methods have been proposed and

it was shown that multiple weights sets are necessary to produce patterns with sufficient fault

coverage. These multiple weight sets have to be stored on a chip, thus this method increases

the area overhead. Several methods reducing the area overhead are proposed one of them is

Generator of Unequiprobable Random Tests (GURT). The area overhead is reduced to

minimum; however it is restricted to only one weight set.

Testability Analysis:

Testability is the processes of performing the main test of operations of controlling the

internal signals from the primary inputs and observing the internal output at the primary

output.

Many testability analysis techniques have been proposed the most important one is Sandia

Controllability/observability Analysis Program (SCOAP). This method performs the

testability analysis by performing the observability/controllability calculations of each signal.

Observability:

The observability of a particular internal circuit node is the degree to which one can observe

that node at the outputs of an integrated circuit. This measure is of importance when a

designer/tester desires to measure the output of a gate within a larger circuit to check that it

operates correctly.

Controllability:

The controllability of an internal circuit node within a chip is measure of the case of setting

the node to 1 or 0 states. This measure is of importance when assessing the degree of

difficulty of testing a particular signal within a circuit. A node with little controllability might

require many hundreds or thousands of cycles to get it to the right state. It is very big task to

generate a test sequence to set a number of poorly controllable nodes into the right state. A

well designed circuit should have the entire node easily observable and controllable.

VLSI TESTING PROBLEMS

In VLSI circuits faults can occur at anytime at design, process, package, and field. Faults can

occur at any place in the circuit.

The major problems detected so far in VLSI testing are as follows

1) Test generation problem

2) The Input Combinatorial Problem

3) The Gate to I/O Pin Ratio Problem

Test Generation Problem

The testability of a circuit can be increased with Design for testability (DFT) techniques.

Testing of a circuit involves the generation of test patterns for the circuit, application of this

test patterns to the circuit and the analysis of output response of the circuit . Generation of

test patterns for a combinational circuit is an easy task; the problem is with sequential circuits

because of the presence of storage elements.

The Input Combinatorial Problem

The number of test vectors required to test combinational and sequential circuits has

increased to a greater degree as we move from MSI (Medium-Scale-Integrated) to Very

Large Scale Integrated circuits (VLSI).

The Gate I/O Pin Ratio:

With the advances in System on Chip (SOC) technology, the number of transistors on the

IC’s has increased to a greater extent causing the size to be reduced. As the reduction in size

and increase in gate count caused difficulties in testing the internal nodes of the circuit as

they are difficult to be controlled and observed. The controllabilities and observabilities

become the critical issues.

The solution to the VLSI testing problems can be given by the insertion of an additional

circuit in the IC with Design for Testability features known as Built in Self Test.

Built in Self Test

The recent advances in deep submicron IC process technology and core based IC design

technology will lead to a wide spread use of logic BIST in the industry.

Built in Self Test (BIST) is a Design for Testability (DFT) technique that allows the circuit to

test itself and decide whether the output is correct or not by using its own test patterns

generated by the internal circuitry. The logic BIST offers a number of advantages compared

with the external tester. The problem with the external tester is that they are several times

slower than the IC internal circuitry and they are costly. The advantages of using BIST are,

relieves the tester memory accessibility problem, can be run efficiently on a very low cost

tester, problem of low accessibility and observability of internal nodes (known as test

complexity). Many of the electronic systems now are implemented using embedded cores;

BIST is the suitable method for testing complex core based systems.

The single stuck fault (SSF) model continues to be the most commonly used fault model for

digital system testing. The present new nanometre CMOS technologies require various other

models than single stuck model (SSF) for testing. Multiple test generation techniques that

targets a specific fault types are introduced which are very costly. An alternative solution for

this problem is the use of single on chip test pattern generator for generating test sequences

for conventional (stuck-at) and non-conventional (delay, bridging, stuck-open) fault types.

The general Built in Self Test structure consists of three main parts as shown in fig below 19.

Fig 9. Built in Self Test Structure

During the test the test patterns generated and are feed to the CUT and the response is

checked at the output response evaluator.

The three types of test pattern generation for BIST are deterministic, mixed mode and pseudo

random. Among them pseudo random is the practical solution as this approach is not related

to specific faults. These pseudo random sequences are generated by using Linear Feedback

Shift Registers (LFSR).

BIST solves the problems of VLSI testing by providing the circuit under test with a Linear

Feedback Shift Register (LFSR) and Multiple Input Shift Register (MISR).

LFSR produces the test generator patterns required to test the circuit under test. MISR is

used to produce the parallel data into a single signature.

Types of Shift Register:

Shift registers can have a combination of serial and parallel inputs and outputs, including

Serial in Parallel-out (SIPO) and Parallel-in Serial-out (PISO) types. There are also types that

have both serial and parallel input and types with serial and parallel output. There are also

bidirectional shift registers which allow you to vary the direction of the shift register. The

serial input and outputs of a register can also be connected together to create a circular shift

register. One could also create multi-dimensional shift registers, which can perform more

complex computation.

LINEAR FEEDBACK SHIFT REGISTERS

A linear feedback shift register (LFSR) is a shift register whose input bit is a linear function

of its previous state. Thus it is a shift register whose input bit is driven by the exclusive-or

(xor) of some bits. These selected bits are called taps and the list of this taps is called tap

sequences. The initial value of the LFSR is called the seed, and because the operation of the

register is deterministic, the sequence of values produced by the register is completely

determined by its current (or previous) state. Likewise, because the register has a finite

number of possible states, it must eventually enter a repeating cycle. However, an LFSR with

a well chosen feedback function can produce a sequence of bits which appears random and

which has a Likewise, because the register has a finite number of possible states, it must

eventually enter a repeating cycle. However, an LFSR with a well chosen feedback function

can produce a sequence of bits which appears random and which has a very long cycle. The

feedback function has several names: XOR, odd parity, sum modulo 2. In all this the function

is simple: 1) add the selected bit valves, 2) If the sum is odd the output is one, otherwise the

output is zero.

Applications of LFSRs include generating pseudo-random numbers, pseudo noise sequences,

fast digital counters, and whitening sequences. Both hardware and software implementations

of LFSRs are common.

Tap Sequence

The contents of the shift register, bits tapped for the function, output of the feedback function

together describes the state of the LFSR. With each shift in the shift register the output of the

feedback function changes causing a change in the state of the LFSR.

The state space of an LFSR is the list of all the states the LFSR can be in for a particular tap

sequence and a particular starting valve. Any tap sequence will give up atleast two state

spaces for an LFSR. The tap sequences that give up only two state spaces are called maximal

length tap sequences.

The state of an LFSR that is n bits long can be any one of 2^ n valves. The largest state space

possible for such a LFSR is 2^n-1. LFSR’s can have multiple maximal length tap sequences.

Describing one maximal length sequence will automatically lead to another. If a maximal

length tap sequence is [n, A, B, C], another maximal length tap sequence will be [n, n-C, n-B,

n-A].

Multiple Input Shift Register

The LFSR produces a large amount of data when applied this input to the circuit under test

produces large data to test. Testing the data in this form requires large amount of pins at the

output. This can be reduced by the use of Multiple Input Single Register (MISR). MISR

compresses the data into a single signature. Therefore this is the only valve that is to be

compared and evaluated. MISR reduces the gates I/O pin ratio problem.

FPGA Field Programmable Gate Array

Field-programmable gate array (FPGA) technology continues to gain momentum, and the

worldwide FPGA market is expected to grow from $1.9 billion in 2005 to $2.75 billion by

2010. Since its invention by Xilinx in 1984, FPGAs have gone from being simple glue logic

chips to actually replacing custom application-specific integrated circuits (ASICs) and

processors for signal processing and control applications

What is an FPGA?

At the highest level, FPGAs are reprogrammable silicon chips. Using prebuilt logic blocks

and programmable routing resources, you can configure these chips to implement custom

hardware functionality without ever having to pick up a breadboard or soldering iron. You

develop digital computing tasks in software and compile them down to a configuration file or

bitstream that contains information on how the components should be wired together. In

addition, FPGAs are completely reconfigurable and instantly take on a brand new

“personality” when you recompile a different configuration of circuitry. In the past, FPGA

technology was only available to engineers with a deep understanding of digital hardware

design. The rise of high-level design tools, however, is changing the rules of FPGA

programming, with new technologies that convert graphical block diagrams or even C code

into digital hardware circuitry.

FPGA chip adoption across all industries is driven by the fact that FPGAs combine the best

parts of ASICs and processor-based systems. FPGAs provide hardware-timed speed and

reliability, but they do not require high volumes to justify the large upfront expense of custom

ASIC design. Reprogrammable silicon also has the same flexibility of software running on a

processor-based system, but it is not limited by the number of processing cores available.

Unlike processors, FPGAs are truly parallel in nature so different processing operations do

not have to compete for the same resources. Each independent processing task is assigned to

a dedicated section of the chip, and can function autonomously without any influence from

other logic blocks. As a result, the performance of one part of the application is not affected

when additional processing is added.

Benefits of FPGA Technology

1. Performance

2. Time to Market

3. Cost

4. Reliability

5. Long-Term Maintenance

Performance – Taking advantage of hardware parallelism, FPGAs exceed the computing

power of digital signal processors (DSPs) by breaking the paradigm of sequential execution

and accomplishing more per clock cycle. BDTI, a noted analyst and benchmarking firm,

released benchmarks showing how FPGAs can deliver many times the processing power per

dollar of a DSP solution in some applications. Controlling inputs and outputs (I/O) at the

hardware level provides faster response times and specialized functionality to closely match

application requirements.

Time to market – FPGA technology offers flexibility and rapid prototyping capabilities in

the face of increased time-to-market concerns. You can test an idea or concept and verify it in

hardware without going through the long fabrication process of custom ASIC design. You

can then implement incremental changes and iterate on an FPGA design within hours instead

of weeks. Commercial off-the-shelf (COTS) hardware is also available with different types of

I/O already connected to a user-programmable FPGA chip. The growing availability of high-

level software tools decrease the learning curve with layers of abstraction and often include

valuable IP cores (prebuilt functions) for advanced control and signal processing.

Cost – The nonrecurring engineering (NRE) expense of custom ASIC design far exceeds that

of FPGA-based hardware solutions. The large initial investment in ASICs is easy to justify

for OEMs shipping thousands of chips per year, but many end users need custom hardware

functionality for the tens to hundreds of systems in development. The very nature of

programmable silicon means that there is no cost for fabrication or long lead times for

assembly. As system requirements often change over time, the cost of making incremental

changes to FPGA designs are quite negligible when compared to the large expense of

respinning an ASIC.

Reliability – While software tools provide the programming environment, FPGA circuitry is

truly a “hard” implementation of program execution. Processor-based systems often involve

several layers of abstraction to help schedule tasks and share resources among multiple

processes. The driver layer controls hardware resources and the operating system manages

memory and processor bandwidth. For any given processor core, only one instruction can

execute at a time, and processor-based systems are continually at risk of time-critical tasks

pre-empting one another. FPGAs, which do not use operating systems, minimize reliability

concerns with true parallel execution and deterministic hardware dedicated to every task.

Long-term maintenance – As mentioned earlier, FPGA chips are field-upgradable and do

not require the time and expense involved with ASIC redesign. Digital communication

protocols, for example, have specifications that can change over time, and ASIC-based

interfaces may cause maintenance and forward compatibility challenges. Being

reconfigurable, FPGA chips are able to keep up with future modifications that might be

necessary. As a product or system matures, you can make functional enhancements without

spending time redesigning hardware or modifying the board layout.

Figure 9.FPGA DESIGN FLOW

Choosing an FPGA

When examining the specifications of an FPGA chip, note that they are often divided into

configurable logic blocks like slices or logic cells, fixed function logic such as multipliers,

and memory resources like embedded block RAM. There are many other FPGA chip

components, but these are typically the most important when selecting and comparing FPGAs

for a particular application.

Table 2. FPGA Resource Specifications for Various Families

Table 2 shows resource specifications used to compare FPGA chips within various Xilinx

families. The number of gates has traditionally been a way to compare the size of FPGA

chips to ASIC technology, but it does not truly describe the number of individual components

inside an FPGA. This is one of the reasons that Xilinx did not specify the number of

equivalent system gates for the new Virtex-5 family.

IMPLEMENTATION

The simulation has been performed using ModelSim software. The simulation results were

verified for most of the combinations of 8-bit orthogonal code. ISE Xillinx software have

been used for Synthesis.

MODELSIM TUTORIAL

I. Starting ModelSim1. Start ModelSim

 

Virtex-II

1000

Virtex-II

3000

Spartan-3

1000

Spartan-3

2000

Virtex-5

LX30

Virtex-5

LX50

Virtex-5

LX85

Virtex-5

LX110

Gates 1 million 3 million 1 million 2 million ----- ----- ----- -----

Flip-Flops 10,240 28,672 15,360 40,960 19,200 28,800 51,840 69,120

LUTs 10,240 28,672 15,360 40,960 19,200 28,800 51,840 69,120

Multipliers 40 96 24 40 32 48 48 64

Block

RAM (kb)720 1,728 432 720 1,152 1,728 3,456 4,608

Start Programs ModelSim ModelSim

2. After starting ModelSim, Welcome to ModelSim 5.7g dialog show up.

Fig. 1 Welcome Screen

II. Setting up the ProjectThe first thing to do is to create a project. Projects ease the interaction with ModelSim and are

useful for organizing files and simulation settings.

1. Create a new project by clicking on jumpstart (see figure 1) on the welcome to ModelSim

dialog, and then on create a project. We can also create a new project without the help of the

dialog window by selecting: file new project from the main window

2. A “create project” window pops up (see fig 2). Select a suitable name for the project; set the

project location to d:/temp as shown above, and leave the default library name to work. Hit ok.

Fig 2. Create project dialog

3. After hitting ok, an add items to the project dialog pops out (see fig 3).

Fig 3. Add items to the project dialog

Three options to add files to the project:

Create new VHDL files (from scratch) and then add them to the project, or

Add already existing files to the project, or

Do a combination of the two operations by combining the two above operations.

The following will illustrate the method of adding new files to the project, which has been just

created.

Creating a VHDL File from Scratch

1. From the “add items to the project” dialog click on create a new file.

2. A create project file dialog pops out. Select an appropriate file name for the file which is to be

added; choose VHDL as the add file as type option and top level as the folder option (see fig 4).

Fig 4. Create project file” dialog

3. On the workspace section of the main window (see fig 5), double-click on the file just created

(dff.vhd in our case).

Fig 5. ModelSim’s main window

4. Type in code in the new window. For example, consider a simple D flip-flop code.

entity DFF is

port (D, CLK: in bit;

Q: out bit; QN: out bit := '1');

end DFF;

architecture SIMPLE of DFF is

begin

process (CLK)

begin

if CLK = '1' then

Q <= D after 10 ns;

QN <= not D after 10 ns;

end if;

end process;

end SIMPLE

5. Type (simply paste) the above code in the new window.

6. Save your code (File Save).

Adding Files to the Project

1. Select File Add to Project Existing File…

2. An “add file to Project” dialog pops up. Select the file to be added to the project. Make sure to

select VHDL from “the Add file as type” menu. Hit ok.

Fig 6. Add file to Project window

3. You should now see the file that you have just added in the workspace section of ModelSim’s

Main window.

III. Compiling / Debugging Project Files

1. Select Compile Compile All.

2. The compilation result is shown on the main window. A red message indicates that there is an

error in the code. Steps 3 through 7 will illustrate how to correct this error.

Fig 7. The error is indicated in red on the main window

3. Double-click on the error (shown in Red) on the main window. This will open a new

window that describes the nature of the error. Let the error message is as follows:

4. Double-click on the Error message. The error is highlighted in the source window:

Fig 8. The error is highlighted in the source window

5. Correct the above error by adding the semicolon after the “end SIMPLE” statement. Hit

save, and then recompile the file again. Repeat steps 1-5 until the code compiles with no

errors.

IV. Simulating the Design

This section covers the basics for simulating a design using ModelSim.

1. Click on the Library tab of the main window and then click on the (+) sign next to the work

library. See the name of the entity of the code that has just compiled “DFF”. (See Fig 9)

Fig9: ModelSim’s Main Window

2. Double-click on dff to load the file. This should open a third tab “sim” in the main window.

3. Now select view All Windows from the main window to open all ModelSim windows.

4. Locate the signals window and select the signals that are to be monitored for simulation purposes.

Let all signals are selected for this example.

Library Tab

Fig 10: “The Signals Window”

5. Drag the above signals using the left button of the mouse into the wave window or use: add

wave Selected signals.

6. Do the same as in step 5 with the list window (i.e. drag selected signals into the list window, or

use add list Selected signals).

7. Now, the design is ready to simulate. For this purpose, some commands have to be typed from the

main window of the simulator.

8. On the main window type in: force clk 0 0 ns, 1 10 ns -repeat 20 ns and then hit enter.

This statement forces the clock to take the value of 0 at 0ns, 1 at 10 ns and to repeat the forcing of

these values every 20 ns.

Fig 11: “Input the commands to the simulator as shown above”

9. Next, type run 40 ns on the main window and then hit enter. This will run the simulation for 40

ns. See the changes in the both the wave and list windows.

10. Next, change the value of D to 1 by typing: force d 1 and then hit enter. The change in d will take

place at 40 ns (the current time)

11. Again, type run 40 ns on the main window to simulate the code for another 40ns.

12. Now, select the wave window, and click on “zoom full” (see below). Simulation should look as

follows.

Fig 9: “the Wave window”

The above waveform shows that q follows d 10 Ns after the rising edge of the clock. The same result

is confirmed using the list window.

V. Printing the Results:

Printing the list window:

1. In order to print the list window, select File write list Tabular from the list

window and then save it as simulation.lst

2. Start Notepad and open the file that is saved above. Proceed to printing it.

Printing the wave window:

Printing from the wave window is simple. Select: File Print from the wave window.

Xilinx ISE Tutorial

This tutorial takes through the process of creating, synthesizing, simulating, implementing, and

downloading a simple VHDL design using the XILINX Project Navigator.

Starting the Project Navigator

Start Programs Xilinx Project Navigator

Creating a ProjectNext, create a new project by selecting File New Project. The following “New Project” window

appears

Zoom Full

Fig 1: New Project Wizard Dialog Box

Select an appropriate project name, an appropriate project location, and then set the top-level module

type to hdl. Click next when finished. A new window (see figure 2) appears prompting for device and

design flow information. Fill in these boxes. Click next when finished.

Fig 2: new project wizard device and design flow dialog box

Creating New VHDL files

The new window gives the option to create a new source to add to the project. Click on the New

Source button. In the new window (see Figure 3), select VHDL Module as the file type, and choose a

name for the new file. Check the box Add to project if it is unchecked and then click next.

Figure 3: The create new files window

Then, enter the inputs and outputs of the entity of the file created. Figure 4 shows the wizard

that assists this process.

In the Define VHDL Source window shown in Figure 4:

1. Leave the Entity name as it is.

2. Choose the appropriate Architecture Name for file (i.e. Behavioral, Structural…)

3. Enter the Port names and select their appropriate Direction. For vector types, enter the

appropriate range by selecting the proper values for MSB and LSB. Click next.

Fig 4: Defining Entity port names

Entity inputs and outputs

4-bit vectors

4. A New Source Information window that summarizes the entries pops out. Verify that the

information entered is correct and then press finish. So far, the Project Navigator should have

created the DFF file outline, which consists of the entity and its signals, and an empty

architecture. Then, add code in the architecture part and save the file.

5. Click next on the “Create a new Source” window (Fig 5) to proceed to the next step. The

project Navigator now gives the option of adding existing files to the project. Files can be

added by clicking on Add Source and then selecting the files to be added. Click next and

then click finish.

Fig 5: “Create a New Source” window

For example, let the following code is used:

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Uncomment the following lines to use the declarations that are

-- provided for instantiating Xilinx primitive components.

--library UNISIM;

--use UNISIM.VComponents.all;

entity dff is

Port ( reset : in std_logic;

btnclk : in std_logic;

d : in std_logic_vector(3 downto 0);

q : out std_logic_vector(3 downto 0));

end dff;

architecture Behavioral of dff is

begin

-- A 4-bit register clocked by pressing down a button:

process (reset, btnclk)

begin

if (reset = '1') then

q <= (others => '0');

elsif (rising_edge(btnclk)) then

q <= d;

end if;

end process;

end Behavioral;

Fig 6: A 4-bit Register VHDL code

Checking Syntax and Simulating

Check the Syntax of the code that has just typed. Follow the instructions and on the same time keep

an eye on Figure 9.

First, check that top file is selected (highlighted) under the Sources in Project window, as shown for

“DFF.vhd” in Figure 9. If it is not, then select it by left clicking on it. Next, locate the Processes for

source window on the left of the screen (If the window is not visible, enable it by selecting view

processes). On this window, locate the

synthesize menu and expand it by pressing on the +. Locate the “Check Syntax” command under the

synthesize menu. Left double-click on “Check Syntax” and wait for the software to finish checking

the code.

Fig 9: A green check mark indicates that a process succeeded.

There appears a green check mark if the process completed without warnings (as in Figure 9), a

yellow exclamation mark if there are warnings, and a red x if there are errors in your syntax code.

Observe the messages generated by the software in the process view window (see Figure 9).

The “Processes for Source” is the commands window.

The “Process

view” window

displays messages

A green check

mark indicates

a success.

DFF is the file that is

currently selected.

Correct any errors if any, and then repeat the above step until the check syntax process succeeds. Next

proceed to simulating the design by left double-clicking on “Launch ModelSim Simulator” which is

located under Design Entry Utilities in the Processes for Current Source window. ModelSim

should start, and proceed for simulating the design.

Synthesizing

First, check that the top file is selected (highlighted) under the Sources in Project window, as shown

for “DFF.vhd” in Figure 9. If it is not, then select it by left clicking on it. Next, synthesize the design

by left double-clicking on “Synthesize XST”, located in the Process for Source window. If there are

any errors, fix the errors and re-synthesize the corrected code again.

There are several options for synthesis that can change to optimize the design. Right click on

“Syntehsize XST” and click on properties. The main options that are interested are: Optimization

Goal, Optimization Effort, and FSM Encoding Algorithm. The first two options can be found

under the Synthesis Options tab. By selecting Speed in this option box, Xilinx will try to synthesize

the code to produce faster design. By selecting Area, Xilinx will sacrifice speed and try to build the

smallest design possible. The Optimization Effort option can be set to Normal or High, and tells

Xilinx just how “hard to try” to get a design that is as fast as possible or as small as possible. Clicking

on the HDL Options tab will find the FSM Encoding Algorithm at the top.

If the synthesizer generates any errors, then synthesis will fail and errors have to be fixed in the code

before re-synthesize. If the synthesizer succeeds, then it is still important to check if the synthesizer

has generated any warnings. Check for warnings (and errors) in the synthesis report.

After you have synthesized your design, double left-click on “View Synthesis Report.” The report

should contain a summary of any errors or warnings that were generated. The report should not

contain any latches as these can cause timing problems, when not properly used. If the report contains

latch warnings, then it need to go over your code, and fix these latches, and re-synthesize the code

again.

Note: If you modified your code in this step, then you should re-simulate it to ensure that the proper

functionality is still there.

Assigning I/O Pins

After synthesizing the code, software needs to be informed about where the top entity signals to

be routed. That is, to specify the pin locations for signals feeding in and out of the FPGA chip.

Before proceeding to assign pin locations, implementation constraints file needs to be

created:

Select Project New Source.

The New Source window of Figure 3 should appear.

Select Implementation Constraints file by clicking on it.

Choose a name for the constraints file. Lets choose the name “pins”. Note that the software will add the extension “.ucf” to the constraints file name.

Click next.

Associate the constraints file with the top entity in design. In this case, there is only one single file (Dff), so associate the constraints file with it.

Click next.

Click finish. Now constraints file is created and the pins to the input and output signals are to be assigned.

To specify pin locations:

Locate your constraints file (in our case “pins.ucf”) under the Sources in Project

window and left double-click on it.

After a while, the Xilinx PACE window opens up.

Locate the Design Object List –I/O Pins tab at the bottom of the window. In this

window, specify the I/O device pins that are used to test the design. For this tutorial,

lets use switches SW3-SW0 to feed 4-bit D input, LEDs Ld3-Ld0 to display Q output,

BTN1 to feed the reset signal, and BTN0 to feed button clock.

Now I/O devices that are used to test design are known. Now it needs to find the FPGA

pins to which they are connected. The FPGA pins are those that communicate to the

project navigator as LOC constraints for the implementation.

The pins assignment for all pins in this tutorial is then shown in Table 1. Enter the pin

numbers of Table 1 in the appropriate LOC Column for each I/O (See Figure 10).

Fig 10: Xilinx Constraints Editor

Once the Pin assignment is completed, hit the save button, and then close the Xilinx Pace window.

Implementing the Design

First, check that the top file is selected (highlighted) in the Sources in Project window. If it is not,

then select it by left clicking on it. Next, implement the design by left double-clicking on “Implement

Design”, which is located under the Processes for Source window. Watch the process view window

for any errors or warnings.

Generating a Programming File

After implementing the design, first generate a programming file. Locate “Generate Programming

file” under the Processes for Source window, right-click on it and select properties. A process

properties window should then open up. From this window, generate the programming bit file by

left-double clicking on “Generate Programming File.”

LOC