Clock Domain Synchronization

Embed Size (px)

Citation preview

  • 7/29/2019 Clock Domain Synchronization

    1/16

    Clock Domain Synchronization

    & Synthesis

    Oct 7, 2009

    Doug TiedtLead Digital Engineer, ZMDA Inc.

  • 7/29/2019 Clock Domain Synchronization

    2/16

    What ? Why?What?

    Transferring data between 2 different clock domains.

    Data may be lost or duplicated if transfer is not synchronous to target

    Wh ?

    Consumer devices / PCs have more interfaces every day protocolswith different clock frequencies

    Common situation is a fast processor or controller to slow interface

    Low Power operation clock device at slower speed High Speed operation GHz range

  • 7/29/2019 Clock Domain Synchronization

    3/16

    Concerns Communication between clock domains needs to be designed such

    that information is not missed or duplicated.

    Communication between asynchronous domains needs to bedesigned so that (setup, hold) timing relationships are satisfied.

    Transfer of data must avoid metastabilit in tar et domain

    2 serial flops is rule of thumb (1 in 106 chance / flop)

    May use 3+ flops in critical and/or GHz applications

    D Q D Q

    CLK_FAST CLK_SLOW

  • 7/29/2019 Clock Domain Synchronization

    4/16

    Single Bit SynchronizationTarget clock is faster than Source clock

    D Q D Q D QD QCLK_SLOW CLK_FAST

    Target clock is slower than Source clock (but synchronous)

    D QD Q

    Handshake

    Logic

    CLK_FAST CLK_SLOW

  • 7/29/2019 Clock Domain Synchronization

    5/16

    Bus SynchronizationClock skew between bits in each domain prevents syncing entire bus

    in same manner

    D Q D Q0 0

    D Q

    D Q

    D Q

    D Q

    CLK_BCLK_A 1

    1 0

    0

  • 7/29/2019 Clock Domain Synchronization

    6/16

    Bus Synchronization

    D Q

    D Q

    D Q

    D Q0

    1

    0

    0

    Solutions:

    Create a valid or load bit, and synchronize that across domains

    Perhaps one can guarantee the source domain has been stable &propagation time met before clocking target register?

    D Q D Q

    CLK_BCLK_A 1 1

  • 7/29/2019 Clock Domain Synchronization

    7/16

    Speed Matching FIFO Source and target clock domains are asynchronous and the

    product requirements varies which is faster.

    Source produces a lot of data faster than target can handle it need to buffer data

    Source roduces data much slower than tar et can handle it

    want to buffer data until its worth the targets attention Designer may still need to handle FIFOs empty and full flags

    across domains.

  • 7/29/2019 Clock Domain Synchronization

    8/16

    Clock Tree Synthesis Synthesis typically does daisy chain buffering, need balanced clock

    skew and delay

    CLK_BADLoadsunbalanced

    CLK_GOOD All loadsbalanced

  • 7/29/2019 Clock Domain Synchronization

    9/16

    Clock Tree Synthesis Generally want to minimize clock skew. Might try increasing

    maximum insertion delay allowed to give tool more freedom to

    minimize skew.

    Clock insertion delay less important but does matter for timinganalysis across PVT variation.

    Generated clocks need to be balanced with system clock, henceflops generating clocks need to be on a clock tap earlier in the tree

    Clock gating does the tool trace through non-buffer logic ortreat that gate as a leaf in the clock tree?

    Timed (late or early) clocks not as common anymore(?), wasused for timing fixes and trying to save a cycle point

  • 7/29/2019 Clock Domain Synchronization

    10/16

    What does Clock Tree Synthesis Do?

    Traces through design until coming to a leaf pin (clk, set, rstof flop; specified leaf or excluded pin;

    Removes existing buffers & inverters.

    Balances wire and pin loads

    enera es a opo ogy o es sa s y user cons ra n s. If run after initial layout, it will move gates in netlist with

    PLACED attribute. Clock tree components have FIXEDattribute.

  • 7/29/2019 Clock Domain Synchronization

    11/16

    Synthesis Bottom-Up synthesis still needed for large designs,

    Top-Down works fine with smaller designs (50 100K gates).

    Synthesis scripts need to be developed with cooperation ofdesigners: timing, scan, false paths

    May want to consider clock tree synthesis for large fanout nets

    Good idea to quickly scan netlist:1. Do you see the flops used that you expect?

    2. Were attributes you set carried outdoes the netlist have a ripplecarry adder or a CLA?

    3. Excessive buffering fixing a race path with a long chain of bufferswont work across corner PVT conditions anyway.

  • 7/29/2019 Clock Domain Synchronization

    12/16

    Code Style Matters for Synthesis Some coding styles are not synthesis friendly create false

    dependencies

    Consider instantiating any asynchronous flops or logic the resulting netlist is at the mercy of the tool and the library

    Will probably make RS flop out of synchronous D-flop with an async

    choose?Want to make this flop controllable to improve scan coverage by

    gating off async signal.

    Do you really want a priority encoding scheme in the logic?Yes, sometimes either logical or timing reasonsOther times may actually want a case statement or use assignments

  • 7/29/2019 Clock Domain Synchronization

    13/16

    Code Style Matters for Synthesis For loops are unrolled during synthesis: the expression is

    duplicated as many times as the loop index. Some optimizations

    not done inside a for loop.

    Always block should only contain sensitivity list and registerassignments that are applicable see example

    Good coding practice to keep the sequential and combinationallogic in separate blocks too.

    Use uni-directional busses whenever possible: simplifies logic,timing & false constraints, and synthesis constraints.

  • 7/29/2019 Clock Domain Synchronization

    14/16

    How to Confuse the SynthesizerActual original code:always @(serial_out or scan_mode or pads_high_z_md or out_sel or ss or pdm_c_out)

    beginsda_data_out = serial_out; //default valuessda_open_drain = 1'b0;sda_high_z = 1'b0;

    _

    beginsda_high_z = 1'b1; //sdi input in scan modeendelse if (pads_high_z_md)begin

    sda_high_z = 1'b1; //set pad to high-z if in the pads high-z test modeendelse

  • 7/29/2019 Clock Domain Synchronization

    15/16

    How to confuse the Synthesizerbegin

    case (out_sel)`I2C_MODE :

    beginsda_open_drain = 1'b1; //set pad to open drain in I2C modeend

    `SPI_MODE :begin

    if (ss)begin

    sda_high_z = 1'b1; //if ss is high then set output to high-zendelsebegin

    sda_high_z = 1'b0;end

    end`PDM_MODE :begin

    sda_data_out = pdm_c_out; //send out the capacitive pdmend

    endcase // case(out_sel)end

    end

  • 7/29/2019 Clock Domain Synchronization

    16/16

    How to Confuse the Synthesizer The former verilog code was legal and simulated correctly.

    After synthesis there were false dependencies between this codeand other verilog code pieces within module Probably the result of the synthesizer attempting to optimize

    Incorrect simulation results

    Same code fragment after rewrite://SDA/MISO/PDM_C/SDI pad

    assign sda_data_out = (out_sel == PDM_MODE) ? pdm_c_out : serial_out;

    assign sda_high_z = scan_mode || pads_high_z_md || ((out_sel == SPI_MODE) && ss);

    assign sda_open_drain = (out_sel == I2C_MODE);