7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 1/12

Asynchronous FIFOs

Honors Discussion #14

EECS150 Spring 2010Chris W. Fletcher

1UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 2/12

Big Picture

• Many weeks ago + 1: Synchronous pipelines

& data transactions

•

Many weeks ago: Asynchronous pipelines& data transactions

• This week: {Synchronous, Asynchronous*} FIFOs

* JohnW covered Synchronous FIFOs, so we’ll stick to two+ clock domains

2UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 3/12

Motivation

• We want to pass data across clock domains

footnote: … with as high a throughput as possible

• Applications

• Rate matching video interfaces• Communicating to off-chip components

• Bulk data transfer/DMA across a chip

• Well, why not use a data/hold register?

3UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 4/12

Why is this hard?

• Metastability

 – The ball getting stuck at the top of the hill

• Incorrect synchronizer outputs

 – The ball falling down the wrong side of the hill* Keep this case in mind throughout the hour 

• Determining full/empty signals on time

Recall:

Ready

Valid

Clock

Synchronizer delay     W

   e     w   a    n    t

 W e  g e t

“Almost full” and “Almost empty”

are used to fix this problem

4

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 5/12

Full & Empty

• Disclaimer: This is the hardest part of Async FIFO design!

• Out loud: Why doesn’t the synchronous FIFO counter work?

•

First-draft solution:Keep 2 counters and synchronize across clock boundaries

(we’ll see what this looks like in several slides)

• Caveat: leads to “pessimistic” full/empty

5UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 6/12

Pessimistic State Signals

• Full goes high exactly when the FIFO fills… but doesn’t learn that the FIFO gets read until several

cycles after the fact (Synchronizer latency)

• Same story for the empty signal

• The good – This guarantees no {over, under} flow

 – Works well when we burst data

(when the FIFO is between full and empty)

• The bad – Works badly when the FIFO is in the full/empty

state most of the time

Why? Every time the FIFO goes full/empty,

we impose the synchronizer delay  6

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 7/12

Proposal #1

• Pulse based inc/dec

• Resources

 – 2n counter FFs

 – 2n pointer FFs

 – 4 synchronizers FFs

•

Does this design work?

Count

Count

Write

Inc

Dec

Dec

Clock Domain A Clock Domain B

Input

Output

Buffer 

Pulse

Synch

Pulse

Synch

Write

Pointer 

!=0

Read

Pointer 

!= Depth

Incr 

Incr 

Inc

Read

1b

1b  No!

7UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 8/12

Proposal #2

Level

Synch

Level

Synch

Level

Synch

Level

Synch

Clock Domain A Clock Domain B

Output

Buffer 

Data

Sync

Data

Sync

Write

Pointer  Read

Pointer 

!=Full

Input

Write

!= Empty

Read

Nb

Nb

Synch Synch

SynchSynch

Handshake

Handshake

Data

• Binary pointers

• Direct comparison

• Resources

 – 2n pointer FFs

 – 2n + 4 synchronizer FFs

• Does this design work?

In Theory,

but can we do better?

8UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 9/12

Gray Code (GC) Primer

• 1 bit edit distance between adjacent words

• Most useful gray codes are powers of 2 long

 – Even gray code sequences are possible, but typically

require more resources to decode – Odd gray code sequences are not possible. Why?

• (Right) An efficient mirror-image gray code scheme

 – Quadrants are colored

•

Notice that the MSBs show the counter’s “quadrant” – Can be used to generate { , almost} {full, empty}

• Con: gray code schemes usually require GCBinary conversions

0000

0001

0011

0010

0110

0111

0101

0100

1100

1101

1111

11101010

1011

1001

1000

0000

9UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 10/12

Proposal #3

Level

Synch

Level

Synch

Level

Synch

Level

Synch

Gray

 

Bin

Gray

 

Bin

Clock Domain A Clock Domain B

Output

Buffer 

Level

Synch

Level

Synch

Write

Pointer  Read

Pointer 

!=Full

Input

Write

!= Empty

Read

Nb

Nb

Gray

 

Bin

Gray

 

Bin

• Gray code pointers

• Direct comparison

• Requires GCBin

• Resources• 2n pointer FFs

• 4n synchronizer FFs

•

GCBin converters

• Does this design work?

 

In Theory 10UCB EECS150 Spring 2010, Honors #14

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 11/12

Binary vs. Gray code (#2 vs. #3)

• #2 can pass arbitrary values over the clock boundary

 – #3 is limited to increments/decrements

• #2 allows for arbitrary FIFO depth

 – #3 is best suited to powers of 2

• #2 can calculate arbitrary “almost {full, empty}”

• #3 can efficiently calculate some “almost {full, empty}”

thresholds (based on counter quandrant)

… but …

• #2 imposes a handshake latency through using data synchronizers

(this is a serious problem for throughput!) 11

7/23/2019 Honors14_1PP

http://slidepdf.com/reader/full/honors141pp 12/12

Acknowledgements & Contributors

Slides developed by Chris Fletcher (4/2010).

This work is partially based on ideas from:

(1) “Simulation and Synthesis Techniques for Asynchronous FIFO Design”

(2) “Simulation and Synthesis Techniques for Asynchronous FIFO Design

with Asynchronous Pointer Comparison”

This work has been used by the following courses: – UC Berkeley CS150 (Spring 2010): Components and Design Techniques for Digital Systems

12UCB EECS150 Spring 2010, Honors #14