<<

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 [email protected] 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 asynchronous to your system clock Every real life bistable (such as a D-latch) has a metastable state Vout CLK VTC of '1' state $ Inputs that come from other series inverters synchronous systems are based 8 PORT D Q on a different system clock, which Gigabit Vin Vout Ethernet VTC of metastable is typically asynchronous to your Switch state

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

1 Quick Metastability Review Mean Between Failures

'0' state '1' state '0' state '1' state For a FF we can compute its MTBF, which is a figure of merit related to FF in 'normal' states FF in metastable state metastability. 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) f sampling clock frequency MTBF(t ) = e assume a valid logic level or what level it r a asynchronous event frequency T fa t and T FF parameters might eventually assume o o

The only thing we know is that the probability For a typical .25um ASIC library FF of a FF coming out of a metastable state For f = 100MHz, t = 2.3ns MTBF = 20.1 days increases exponentially with time r a = 1MHz t = 0.31ns To = 9.6as

Synchronizer Requirements Single signal Synchronizer Traditional synchronizer Synchronizers must be designed to $ SIG is asynchronous, and META might go reduce the chances system failure due metastable from time to time $ However, as long as META resolves before the to metastability next clock period SIG1 should have valid logic Synchronizer requirements levels $ 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 since they have no regeneration (tr/t) (tr/t) For a typical .25um MTBF(t ) = e x e r ASIC library FF T fa T f o o CLK CLK f t = 2.3ns Q MTBF = 9.57x1010 years r For f = 100MHz, D t = 0.31ns a = 1MHz f f Age of Earth = 5x109 years T = 9.6as o D Q f Can increase MTBF by adding more series stages CMOS Dynamic FF TSFF (Svenson)

SIG META SIG1 SIG2 D Q D Q D Q 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 SIG1 $ Very large (5x regular FF) and very high power D Q D Q SYNC Vout VTC of SYNC FF '1' state 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] D Q D Q SIG[1] SIG1[1] Hand Hand D Q D Q SIG1[0] CLK2 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 FIFO is managed as a size is implemented using Dual Port FFh SRAM circular buffer using FEh an on-chip SRAM PORT1 PORT 2 pointers. SRAM must be dual- FULL WR_PTR RD_PTR EMPTY DATA_IN FIFO WR_DATA RD_DATA FIFO DATA_OUT First write will occur at WRITE ported for our design WRITE READ n bits of data LOGIC LOGIC PNTR address 00h. Next write n bits of data [have two independent n bits of data CLK1 CLK2 will occur at 01h. ports] n bits of data n bits of data READ After writing at FFh, next n bits of data We will use a write PNTR write will wrap to 00h. 01h pointer to determine the 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 WR_PTR RD_PTR EMPTY DATA_IN FIFO WR_DATA RD_DATA FIFO 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; A standard single bit input [SIZE-1:0] bin; (when they change, they increment by 1) output [SIZE-1:0] gray; synchronizer is used on each reg [SIZE-1:0] gray; $ Applying a traditional two stage FF synchronizer on 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 BIN[2:0] 011 100 001 001 1 integer i; 010 011 BIN_S[2:0] 011 010 011 XXX 100 bin2gray D Q PTR_OUT always @(gray) 100 110 GRAY[2:0] 010 110 gray2bin for (i=0; i> 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 bin2gray D Q D Q gray2bin Write and read pointers need to be registered SYNC 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 PTR_OUT value of PTR_IN D Q D Q 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 metastable our new pointer value may not be SRAM PORT1 PORT2 updated until one cycle later. FULL WR_PTR RD_PTR EMPTY DATA_IN FIFO WR_DATA RD_DATA FIFO DATA_OUT We need to be conservative when generating WRITE READ 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 SIG 2 ratios (may hamper bringup/debug) REQ D Q D Q $ Intolerant of spec mistakes (maybe that unload Hand CLK2 Hand Assume: shaking shaking + FSM FSM CLK2 = CLK1 - 5% frequency was supposed to be +- 50%!)

CLK1 CLK2

Words to the wise Conclusions

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

8