Design of Asynchronous FIFO using Verilog HDL

ABSTRACT

An improved improved technique technique for fifo design design is to perform asynchronous asynchronous comparisons between the fifo write and read pointers that are generated in clock  domai domains ns and and asyn asynch chro rono nous us to each each othe other. r. The The asyn asynch chron ronou ouss fifo fifo point pointer  er  comparison technique uses fewer synchronization flip-flops to build the fifo. This method requires requires additional additional techniques techniques to correctly correctly synthesize synthesize and analyze analyze the design, which are detailed in this paper. To increase the speed of the fifo, this design uses combined binary/ray counters that take advantage of the builtin binary ripple carry logic. This fifo design is used to implement the A!"A A#" $ompliant !emory $ontroller. This means, Advanced !icrocontroller  "us Architecture compliant !icrocontroller .The !$ is designed for system memory control with the main memory consisting of o f %&A! and &'!.

1

CHAPTER-1 INTRODUCTION

1.1

INTRODUCTION: An asynchronous fifo refers to a fifo design where data values are written sequentially into a fifo buffer using one clock domain, and the data values are sequentially read from the same fifo buffer using another clock domain, where the two clock domains are asynchronous to each other. 'ne common technique for designing an asynchronousfifois to use ray code pointers that 2

are synchronized into the opposite clock domain before generating synchronous fifo full or empty status signals. An interesting and different approach to fifo full and empty generation is to do an asynchronous comparison of the pointers and then asynchronously set the full or empty status bits.

There are many ways to do asynchronous fifo design, including many wrong ways. !ost incorrectly implemented fifo designs still function properly ()* of the time. !ost almost-correct fifo designs function properly ((*+ of the time. nfortunately, fifos that work properly ((*+ of the time have design flaws that are usually the most difficult to detect and debug.

3

1.2

ARCHITECTURE:

FIGURE:FIFO partitioning with asn!hrono"s point#r !o$parison %ogi!

1&'Asn!hrono"s FIFO point#rs: n order to understand fifo design, one needs to understand how the fifo pointers work. There are mainly two pointers .

1.

(rit# Point#r:

The write pointer always points to the net word to be written0 therefore, on reset, both pointers are set to zero, which also happens to be the net fifo word location to be written. 'n a fifo-write operation, the memory location that is  pointed to by the write pointer is written, and then the write pointer is incremented to point to the net location to be written.

4

2.

R#a) Point#r:

The read pointer always points to the current fifo word to be read. Again on reset, both pointers are set to zero, the fifo is empty and the read pointer is  pointing to invalid data 1because the fifo is empty and the empty flag is asserted2. As soon as the first data word is written to the fifo, the write pointer  increments, the empty flag is cleared, and the read pointer that is still addressing the contents of the first fifo memory word, immediately drives that first valid word onto the fifo data output port, to be read by the receiver logic. The fact that the read pointer is always pointing to the net fifo word to be read means that the receiver logic does not have to use two clock periods to read the data word. 1.4Gra

Co)# Co"nt#r :

'ne ray code counter style uses a single set of flip-flops as the ray code register with accompanyingray-to binary conversion, binary increment, and  binary-to-ray conversion. A second ray code counter style, the one described in this paper, uses two sets of registers, one a binary counter and a second to capture a binary to-ray converted value. The intent of this ray code counter  is to utilize the binary carry structure, simplify the ray-to-binary conversion0 reduce combinational logic, and increase the upper frequency limit of the ray code counter. The binary counter conditionally increments the binary value, which is passed to both the inputs of the binary counter as the net-binary-count value, and is also passed to the simple binary-to-ray conversion logic, consisting of one 3-input 4'& gate per bit position. The converted binary value is the net ray-count value and drives the ray code register inputs.  FIGURE:D"a% n-*it Gra !o)# !o"nt#r st%#

5

This implementation requires twice the number of flip-flops, but reduces the combinatorial logic and can operate at a higher frequency. n 56A designs, availability of etra flip-flops is rarely a problem since 56As typically contain far more flip-flops than any design will ever use. n 56A designs, reducing the amount

of

combinational

logic

frequently

translates

into

significant

improvements in speed. The ptroutput of the block diagram is an n-bit ray code pointer. The binary-value incremental is conditioned with either an 7if not full8 or 7if  not empty8 test as shown isto insure that the appropriate fifo pointer will not increment during fifo-full or fifo-empty conditions that could lead to overflow or underflow of the fifo buffer .f the logic block that sends data to the fifo reliably stops sending data when a fifo full condition is asserted, the fifo design might be streamlined by removing the full-testing logic from the fifo write  pointer. The fifo pointer itself does not protect the fifo buffer from being overwritten, but additional conditioning logic could be added to the fifo memory buffer to insure that a write9 enable signal could not be activated during a fifo full condition .An additional 7sticky8 status bit, either ovf  1overflow2 or unf 1underflow2, could be added to the pointer design to indicate that an additional fifo write operation occurred during full or an additional fifo read operation occurred during empty to indicate error conditions that could only be cleared during reset. A safe, general purpose fifo design will include the 6

above safeguards at the epense of a slightly larger and perhaps slower  implementation. This is a good idea since a future co-worker might try to copy and reuse the code in another design without understanding all of the important details that were considered for the current design.

1&+Us# o, Gra Co"nt#r: A common approach to fifo counter-pointers, is to use ray code counters. ray codes only allow one bit to change for each clock transition, eliminating the  problem associated with trying to synchronize multiple changing signals on the same clock edge .The first fact to remember about a ray code is that the code distance between any two ad:acent words is :ust ; 1only one bit can change from one ray count to the net2. The second fact to remember about a ray code counter is that most useful ray code counters must have power-of-3 counts in the sequence. t is possible to make a ray code counter that counts an even number of sequences but conversions to and from these sequences is generally not as simple to do as the standard ray code. Also note that there are no oddcount-length ray code sequences so one cannot make a 3possibly going full> situation as shown. ?hen this conditionoccurs, the direction latch is set.

9

FIGURE:FIFO is going ,"%% *#!a"s# th# wptr trai%s th# rptr * on# 2"a)rant

f the write pointer is one quadrant ahead of the read pointer, this indicates a >possibly going empty> situation as shown. ?hen this condition occurs, the directionlatch is cleared.

FIGURE:FIFO )ir#!tion 2"a)rant )#t#!tion !ir!"itr

?hen the fifo is reset the directionlatch is also cleared to indicate that the fifo 7is going empty8 1actually, it is empty when both pointers are reset2. %etting and 10

resetting the direction latch is not timing-critical, and the direction latch eliminates the ambiguity of the address identity decoder. The 4ilin 56A logic to implement the decoding of the two wptr!%"s and the two rptr!%"s is easily implemented as two @-input look-up tables. The second, and more difficult,  problem stems from the asynchronous nature of the write and read clocks. $omparing two counters that are clocked asynchronously can lead to unreliable decoding spikes when either or both counters change multiple bits more or less simultaneously. The solution described in this paper uses a ray count sequence, where only one bit changes from any count to the net. Any decoder  or comparator will then switch only from one valid output to the net one, with no danger of spurious decoding glitches.

,i,o&3:this is the top-level wrapper-module that includes all clock domains. The top module is only used as a wrapper to instantiate all of the otherfifomodules used in the design. f this fifo is used as part of a larger A%$ or 56A design, this top-level wrapper would probably be discarded to permit grouping of the other fifo modules into their respective clock domains for  improved synthesis and static timing analysis.

,i,o$#$&3:this is the fifo memory buffer that is accessed by both the write and read clock domains. This buffer is most likely an instantiated, synchronous dual-port &A!. 'ther memory styles can be adapted to function as the fifo  buffer.

asn!4!$p&3:this is an asynchronous pointer-comparison module that is used to generate signals that control assertion of the asynchronous 7full8 and 7empty8 status bits. This module only contains combinational comparison logic.  o sequential logic is included in this module.

rptr4#$pt&3:this module is mostly synchronous to the read-clock domain and contains the 55' read pointer and empty-flag logic. Assertion of the

11

aempty9n signal 1an input to this module2 is synchronous to the rclk-domain, since aempty9n can only be asserted when the rptrincremented, but de-assertion of the aempty9n signal happens when the wptr increments, which is asynchronous to rclk.

wptr4,"%%&3:this module is mostly synchronous to the write-clock domain and contains the 55' write pointer and full-flag logic. Assertion of the afull9nsignal 1an input to this module2 is synchronous to the wclk-domain, since afull9ncan only be asserted when the wptrincremented 1and wrst9n2, but deassertion of the afull9nsignal happens when the rptrincrements, which is asynchronous to wclk.

2.2

Asn!hrono"s g#n#ration o, ,"%% an) #$pt

n the async9cmp shown is aempty9n and afull9n are the asynchronously decoded signals. The aempty9n signal is asserted on the rising edge of an rclk,  but is de-asserted on the rising edge of a wclk. %imilarly, the afull9n signal is asserted on a wclk and removed on an rclk. The empty signal will be used to stop the net read operation, and the leading edge of aempty9n is properly synchronous with the read clock, but the railing edge needs to be synchronized to the read clock. This is done in a two-stage synchronizer that generates r 9empty. The w9full signal is generated in the symmetrically equivalent way.

12

FIGURE:Asn!hrono"s point#r !o$parison to ass#rt ,"%% an) #$pt

&'R#s#tting th# FIFO: The first 55' event of interest takes place on a fifo-reset operation. ?hen the fifo is reset, four important things happen within the async9cmp module and accompanying full and empty synchronizers of the wptr9full and rptr9empty modules 1the connections between the async9cmp, wptr9full and rptr9empty modules are shown . ;. The reset signal directly clears the wfullflag. The remptyflag is not cleared by a reset. 3. The reset signal clears both fifo pointers, so the pointer comparator asserts that the pointers are equal.