Synchronization: Why care?

Synchronization in Digital
Digital Abstraction depends on all
Logic Circuits signals in a system having a valid logic
state
Ryan Donohue Therefore, Digital Abstraction depends
Rdonohue@yahoo.com on reliable synchronization of external
events

The Real World Metastability

When asynchronous events enter your
Real World does not respect the Digital synchronous system, they can cause bistables
Abstraction! to go into metastable states
Inputs from the Real World are usually
Every real life bistable (such as a D-latch) has
$
asynchronous to your system clock
a metastable state
Vout
$ Inputs that come from other CLK VTC of
series inverters
'1' state

synchronous systems are based 8 PORT

on a different system clock, which Gigabit
D
Vin Vout
Q
VTC of
Ethernet
is typically asynchronous to your
metastable feedback
Switch state

system clock 0
Vin Q
D 1 Vout
CLK
'0' state Vin

1
Quick Metastability Review
'0' state
FF in 'normal' states
Mean Time Between Failures
'1' state '0' state '1' state For a FF we can compute its MTBF,
which is a figure of merit related to
metastability.
FF in metastable state

Once a FF goes metastable (due to a setup tr resolution time (time since clock edge)
time violation, say) we can_t say when it will (tr/t)
MTBF(tr) = e
f sampling clock frequency
assume a valid logic level or what level it Tofa
a asynchronous event frequency
t and To FF parameters
might eventually assume
The only thing we know is that the probability For a typical .25um
of a FF coming out of a metastable state ASIC library FF
For f = 100MHz, MTBF = 20.1 days
increases exponentially with time tr = 2.3ns
t = 0.31ns
a = 1MHz
To = 9.6as

Synchronizer Requirements Single signal Synchronizer

Traditional synchronizer
Synchronizers must be designed to $ SIG is asynchronous, and META might go
metastable from time to time
reduce the chances system failure due $ However, as long as META resolves before the
to metastability next clock period SIG1 should have valid logic
levels
Synchronizer requirements $ Place FFs close together to allow maximum time
$ Reliable [high MTBF] for META to reslove
CLK
$ Low latency [works as quickly as possible] SIG META SIG1
D Q D Q SIG
$ Low power/area impact META

CLK SIG1

2
Single Synchronizer analysis Flip Flop design is important?
MTBF of this system is roughly: Dynamic FFs not suitable for synchronizers
(tr/t) (t /t) For a typical .25um
since they have no regeneration
MTBF(tr) = e x e r
ASIC library FF
Tofa Tof CLK CLK f
tr = 2.3ns For f = 100MHz, D Q
MTBF = 9.57x1010 years t = 0.31ns a = 1MHz f f
Age of Earth = 5x109 years To = 9.6as
D Q
f

Can increase MTBF by adding more series

stages CMOS Dynamic FF TSFF (Svenson)

SIG
D Q
META
D Q
SIG1
D Q
SIG2
Special _SYNC_ FFs should be used for the
primary synchronizer if available
CLK

SYNC Flip Flop Synchronization Pitfall

SYNC Flip Flops are available in some ASIC
libraries Never synchronize the same signal in multiple
$ Better MTBF characteristics due to high gain in the places! Inconsistency will result!
feedback path
$ Very large (5x regular FF) and very high power D Q D Q
SIG1

SYNC
Vout VTC of
'1' state
SYNC FF
series inverters
CLK
SIG META SIG1 VTC of SIG
D Q D Q regular FF
SYNC series inverters SIG2
D Q D Q
SYNC
CLK

'0' state Vin CLK

3
Bus Synchronization Handshaking is the Answer
Need a single point of synchronization for the
Obvious approach is to use single signal entire bus
synchronizers on each bit CLK

WRONG! SIG[1:0]

REQ
SIG[0] SIG1[0]
D Q D Q ACK
SYNC
CLK
SIG 2
CLK
SIG[0]
REQ
SIG[1] DQ DQ
SIG[1] SIG1[1] Hand Hand
SIG1[0] CLK2
D Q D Q shaking shaking
SYNC FSM
SIG1[1] ACK FSM
Q D Q D
CLK1
CLK

CLK1 CLK2

Handshaking Rules Alternate Handshaking Scheme

Sender outputs data and THEN asserts REQ Previous example is known as 4-phase
handshaking
Receiver latches data and THEN asserts ACK
2-phase (or edge based) handshaking is also
Sender deasserts REQ, will not reassert it suitable
until ACK deasserts
$ Sender outputs data and THEN changes state of
Receiver sees REQ deasserted, deasserts ACK REQ, will not change state of REQ again until after
when ready to continue ACK changes state.
$ Receiver latches data. Once receiver is ready for
more it changes state of ACK.
CLK
SIG[1:0] 2-phase requires one bit of state be kept on
REQ
each side of transaction. Used when FFs are
ACK inexpensive and reliable reset is available.

4
High Bandwidth solutions Abstract FIFO design
Handshaking works great, but reduces Ideal dual port FIFO writes with one
bandwidth at the clock crossing clock, reads with another
interface because each piece of data FIFO storage provides buffering to help
has many cycles of series handshaking. rate match load/unload frequency
Correctly designed FIFOs can increase Flow control needed in case FIFO gets
bandwidth across the interface and still totally full or totally empty
maintain reliable communication DATA_IN DATA_OUT

FULL EMPTY

CLK1 CLK2

FIFO in detail FIFO pointer control

FIFO of any significant
size is implemented using Dual Port
FIFO is managed as a FFh

an on-chip SRAM
SRAM
circular buffer using FEh

pointers.
PORT1 PORT 2

SRAM must be dual- FULL WR_PTR RD_PTR EMPTY

ported for our design

DATA_IN FIFO
WRITE
WR_DATA RD_DATA FIFO
READ
DATA_OUT
First write will occur at WRITE

[have two independent

LOGIC LOGIC address 00h. Next write PNTR
n bits of data
n bits of data

ports] CLK1 CLK2 will occur at 01h. n bits of data

n bits of data

We will use a write After writing at FFh, next READ

n bits of data
n bits of data

pointer to determine the write will wrap to 00h. PNTR

01h
00h
write address, and a read Reads work the same way.
pointer to determine the First read will occur at
read address address 00h.

5
FIFO pointers and flow control FIFO in detail
Generation of FULL and EMPTY signals. We have a problem!
$ FIFO is FULL when write pointer catches read
pointer Dual Port
SRAM
always @(posedge clk1)
FULL <= (WR_PNTR == RD_PNTR) && ((OLD_WR_PNTR + 1 == RD_PNTR) || FULL) PORT1 PORT 2

$ FIFO is empty when read pointer catches write

pointer FULL
DATA_IN FIFO
WR_PTR
WR_DATA
RD_PTR
RD_DATA FIFO
EMPTY
DATA_OUT

always @(posedge clk2) WRITE READ

EMPTY <= (WR_PNTR == RD_PNTR) && ((OLD_RD_PNTR + 1 == WR_PNTR) || EMPTY) LOGIC LOGIC
Write pointer and read pointer must never
pass each other. CLK1 CLK2

$ Write passing read overwrites unread data To generate FULL/EMPTY conditions the write
$ Read passing write re-reads invalid data logic needs to see the read pointer and the read
logic needs to see the write pointer!

Pointer Synchronization Pointer Synchronizer

module bin2gray (bin,gray);
Pointer is stored in gray code.
Our pointers change in a very specific way parameter SIZE = 4;

(when they change, they increment by 1) A standard single bit input [SIZE-1:0] bin;
output [SIZE-1:0] gray;

Applying a traditional two stage FF synchronizer on

synchronizer is used on each reg [SIZE-1:0] gray;

bit of PTR_OUT. At most one

$
always @(bin)
each bit of a binary pointer could cause a wildly gray = (bin >> 1) ^ bin;

invalid pointer value to be produced bit changes per cycle! endmodule

$ Gray coding the pointer value means at most one We can still do binary math to module gray2bin (gray,bin);

bit will change per cycle _ we can only be _off by increment the pointer. parameter SIZE = 4;

one_ input [SIZE-1:0] gray;

output [SIZE-1:0] bin;
Binary Gray CLK reg [SIZE-1:0] bin;
000 000
001 001 BIN[2:0] 011 100 integer i;
1
010 011
011 010
BIN_S[2:0] 011 XXX 100 bin2gray
D Q PTR_OUT always @(gray)
100 110 GRAY[2:0] 110 for (i=0; i<SIZE; i=i+1)
010 gray2bin
101 111 bin[i] = ^(gray >> i);
110 101 GRAY_S[2:0] 010 110 or 010 110 CLK
111 100 endmodule

6
Pointer Synchronizer pitfall Answer to pitfall
PTR_IN PTR_OUT
Write and read pointers need to be registered bin2gray
D
SYNC
Q D Q gray2bin

in gray code as shown on previous slide.

CLK
Don_t be tempted to cheat and register Combinational logic frequently contains
pointers in binary. What_s wrong with the hazards at the output (non fully covered
synchronizer shown below? Karnaugh map)
Avoid this problem by using a registered
PTR_IN
D Q D Q
PTR_OUT value of PTR_IN
bin2gray gray2bin CLK
SYNC
PTR_IN[2:0] 011 100
CLK PTR_IN_G[2:0] 010 110
LOGIC HAZARD (unknown value)

Pointer math pitfall Final Synchronizer FIFO

When our pointer synchronizer goes Dual Port
SRAM
metastable our new pointer value may not be PORT1 PORT2

updated until one cycle later. FULL WR_PTR RD_PTR EMPTY

We need to be conservative when generating DATA_IN FIFO

WRITE
WR_DATA RD_DATA FIFO
READ
DATA_OUT

FULL and EMPTY signals to reflect this. LOGIC SYNC LOGIC

CLK2

$ Typically FULL = 1 when WRITE catches READ. CLK1 SYNC CLK2

We need FULL = 1 when WRITE catches READ-1. CLK1

$ Typically EMPTY = 1 when READ catches WRITE. Works for any phase/frequency relationship
We need EMPTY = 1 when READ catches WRITE-1. between CLK1 and CLK2

7
Mesosynchronous Designs Mesosynchronous Tradeoffs
When two systems of bounded frequency Benefits to mesosynchronous designs
need communicate, open loop $ Less synchronization circuitry
synchronization circuits can be used (no ACK) $ Synchronizer might have lower latency vs. full 4-
CLK phase handshaking
SIG[1:0]
Costs of mesosynchronous designs
REQ
$ Synchronizer only works at certain frequency
2
ratios (may hamper bringup/debug)
SIG

REQ

Hand CLK2
DQ DQ
Hand Assume:
$ Intolerant of spec mistakes (maybe that unload
shaking
FSM
shaking
FSM CLK2 = CLK1 +- 5% frequency was supposed to be +- 50%!)

CLK1 CLK2

Words to the wise Conclusions

Be wary of synchronizer schemes designed by
others
$ Synopsys Designware DW04_sync multi-bit
synchronizer DOES NOT WORK as a synchronizer
$ Synthesizers might use dynamic FFs as
synchronizers _ they don_t know the difference.
$ Auto-placement tools must be told to place
Synchronizers are important. Synchronization
failure is deadly and difficult to debug
Synchronization requires careful design. Most
CAD and logic tools CANNOT catch bad
synchronizer designs.
Design of synchronizer depends on

synchronizer FF pairs close together performance level needed. Basic

BE PARANOID synchronizer of back-to-back FFs is the core
design all others are based on.