4-19-16 Back to Basics Cdc v3

Clock Domain Crossing Back-to-Basics

Mark Silvestri April 12, 2016

CONFIDENTIAL INFORMATION The following material is confidential information of Synopsys and is being disclosed to you pursuant to a non-disclosure agreement between you or your employer and Synopsys. The material being disclosed may only be used as permitted under such non-disclosure agreement.

IMPORTANT NOTICE In the event information in this presentation reflects Synopsys’ future plans, such plans are as of the date of this presentation and are subject to change. Synopsys is not obligated to develop the software with the features and functionality discussed in these materials. In any event, Synopsys’ products may be offered and purchased only pursuant to an authorized quote and purchase order or a mutually agreed upon written contract.

© 2016 Synopsys, Inc.

2

Agenda


3

•

Clock Domain Crossing Problem

•

Essential Technologies

•

Additional Topics & Wrap-up

Principles of Synchronous Design D0

Logic

Ck2

Ck1

Input to combination logic changes upon SOURCE clock edge

D1

C0

Combo logic creates GLITCHES GLITCHES SETTLE before edge of

Ck1 D0

SYNCHRONOUS clock D1 captures stable data assuming setup/hold time is met - Clock domains are SYNCHRONOUS

C0

What if D1 is clocked by an ASYNCHRONOUS clock where setup/hold time is not guaranteed?

D1

Asynchronous designs NOT safe and will fail: MTBF = 1/(Fclk * Fdata * X) © 2016 Synopsys, Inc.

4

Ck2

CDC – Typical Approaches and Their Limitations • Static Timing Analysis (STA) only checks synchronous logic – STA designed for synchronous modules/blocks – STA can report ALL async crossings, but cannot differentiate between good/bad CDC’s – Paths crossing clock domains are set to false paths and ignored – Happens late in the design cycle at netlist level

• Functional simulation incomplete – Blackbox testing is too cumbersome and not exhaustive – Whitebox testing requires you to write assertions – Requires test benches for all the crossings – Is very reliant on luck (since simulation is not exhaustive), and will only detect a small subset of errors – Detected late in the design cycle

Clea rly, existing © 2016 Synopsys, Inc.

5

techniq ues are inadequate for CDC

Types of CDC Problems Problem #1 Metastability

Problem #2 Convergence (correlation / coherency / reconvergence) Problem #3 Functional problems (data loss, data hold, gray encoding) Other CDC Issues Reset synchronization & assumption verification


6

• How do you ensure that you have isolated metastability across clock domains so it does not affect design functionality?

• How do you ensure that a group of converging synchronized control signals are in sync at a particular clock cycle?

• How do you ensure that data from one clock domain is held long enough to be captured by the other clock domain? (Fast to slow clock data transfers)

• How do you ensure that an asynchronous set/reset is properly synchronized for a set of flops, and the reset is asynchronously asserted and synchronously de-asserted? • How do you ensure that y our clocks, set_case_analysis, quasi_static, waivers, incomplete formal checks are accurate?

Problem #1: Metastability clk_B samples “A” while it is changing

A

D

A

F1

clk_A

B

F2 clk_B

intermediate voltage value can cause incorrect value downstream

clk_A A clk_B B

VOH VOL

initially metastable

may remain metastable

• Output “B” becomes metastable whenever input “A” violates setup & hold time • Why is this an issue? – The output of flop F2 is unpredictable – This may lead to chip failures

• How can SpyGlass Help? – Identifies cases where synchronization is missing in the destination domain © 2016 Synopsys, Inc.

7

intermediate voltage value fanning out

Problem #1: Metastability Control (Qualifier) Crossings clk_A A F2 F1 F2 F3 clk_B Known value B is safe for can NEVER be C eliminated! downstream clk_BNOTE: Metastability A

D

clk_A

Solution:

B

C

• Can only be isolated to increase MTBF Although B is indeterminate… • Multi-flop sync cells creates N clock cycles of uncertainty C is a known value • Side effect is data-coherency/re-convergence issues

• Add additional flops in the destination domain to isolate metastable signal – Number of flops dependent on destination frequency

• Replace destination flop with special synchronizer cell – Enables specialized cells that are best suited for isolating metastability – Enables synchronizers to be easily recognized for special handling by backend teams © 2016 Synopsys, Inc.

8

Problem #2: Coherency X Typically, a FIFO address bus prior to crossing over to another clock domain

X

X1

Y

Y1

clk_A

X2

X3

Y2

X4

Y3

Y clk_A Y4

X1 Y1 X2 Y2

clk_B

clk_B

Why is this an issue? • Variable latency in crossings

X3

• Metastability may introduce cycles of uncertainty

Y3

• Either or both could cause invalid value in destination domain

X4

Data out of sync in this cycle

Y4 If you samp le your data here,

– clk_B domain captures invalid state of “10”

you’ll get incorrect data

• Common cause of chip failures

Src

• Also known as re-convergence

Dest X4:Y4


9

X:Y

00

11 00

11 00

11 11 11 10 11

Problem #2: Coherency X Y clk_A

Solution: • Gray encode source signals – Each source toggles exclusive of others

X1 Y1

• Must verify that source signals can never change in same destination clock cycle

X2 Y2 Gray Encoder:

X

X1

Y

Y1

X2

X3

X4

clk_B X3

ensures only a single bit as changes address bus counts up or down

clk_A

Y2

Y3

Y3

Y4

X4 Y4

clk_B

Src

X:Y

Dest X4:Y4 © 2016 Synopsys, Inc.

10

00

01 00

01 01 01 01 00 00 01

Problem #3: Functional Problems Data Loss • Why is this an issue? – Signal in faster domain (clk_A) may not be held long enough to be captured in slower domain (clk_B) – Transfer may fail, resulting in lower reliability or critical failure

D clk_A

F1

A

F2

B

F3

C

clk_A (fast clock)

A clk_B

clk_B

(slow clock)

• Solution: Use pulse extender or other FSM control – Ensures good margin between stable source data and destination clock edge A

F1 D

C

F3

clk_B

clk_A (Fast clock)

A clk_B

clk_A © 2016 Synopsys, Inc.

B

F2

simple 2-cycle extender 11

(Slow clock)

Problem #1: Metastability Data Crossings D

G

D’

Q

F2 clk_A

clk_B

Control crossing qualifies Data crossing

clk_A D clk_B Q D’ Source data D stable when qualifier Q active

Solution: Use a control crossing to “qualify” the data crossing – Ensures all data bits get transferred on the same destination clock edge – Gating logic ‘G’ must not compromise integrity of qualifier ‘Q’ – Source data ‘D’ must remain stable when qualifier ‘Q’ enables transfer


12

All bits transfer on the same destination edge

Agenda


13

•


•


•

Additional Topics & Wrap-up

Protocol Independent CDC Recognition The following picture represents ALL clock domain crossings (fifo, handshake, mux, enable, etc.) • First, identify all qualifier (multi-flop) crossings • Then, for non-qualifier crossings, identify qualifier(s) in fanin of destination flop Data

Address

Destination

Enabling Logic

Data Crossing Asynchronous sources feeding to same destination, like data/address and others

Qualifier Control Crossing Synchronized control signal from the same asynchronous source domain © 2016 Synopsys, Inc.

14

Other signals from asynchronous source which are static or from the DESTINATION DOMAIN

Differentiation of Control and Data crossings • CONTROL crossing – Synchronized by multi-flop

or sync-cell

or constrained-qualifier

– Transfers control signal(s) across a clock domain – May qualify a DATA crossing – Synchronized CONTR

OL cross ing is synonymous with qualifier

• DATA crossing – Can be scalar or vector signals – Always qualified by a CONTROL crossing – A synchronized DATA crossing will always contain a synchronized CONTROL crossing

NOTE: If the CONTROL crossing is unsynchronized, then the DATA crossing will also be unsynchronized


15

Selectable Allowed Synchronization Schemes • SpyGlass automatically recognizes a number of synchronization schemes – User can disable a scheme if it is not allowed


Conventional multi-flop synchronization scheme (Control)

Synchronizing cell synchronization scheme (Control)

Delay signals synchronization scheme (Control or Data)

AND gate synchronization scheme (Data)

Recirculation MUX synchronization scheme (Data)

MUX-select sync (without Recirculation) Synchronization scheme (Data)

Glitch protection cell

Clock-gating cell

Qualifier synchronization

Handshake

synchronization scheme(Data) MUX lock synchronization scheme (Data)

synchronization scheme (Data) Pattern synchronization scheme (Data)

scheme (Data) FIFO synchronization scheme (Data)

synchronization scheme (Data For Request and Control for Acknowledge)

16

Synchronized enable synchronization scheme (Data)

Conventional Multi-Flop Synchronization Scheme

• Applies to CONTROL crossings • Assumes Conventional Multi-Flop sync scheme is enabled (default) • CONTROL crossings can be: – RTL multi-flops (auto detected) – Liberty cells (requires sync_cell constraint) – Single flops (requires sync_cell constraint)

• All DATA crossings contain at least one CONTROL crossing


17

Recirculation Mux Synchronization Scheme

• Applies to DATA crossings • Assumes Recirculation Mux sync scheme is enabled (default) • Automatically recognized

NOTE: It contains a control crossing


18

AND Gate Synchronization Scheme

• Applies to DATA crossings • Assumes AND Gate sync scheme is enabled (default) • AND gate can be AND/OR/NAND/NOR • XOR nor complex AOI allowed (unless AND gate does gating)

NOTE: It contains a control crossing


19

Differentiated Reasons for Unsynchronized Crossings


20

Destination instance is driving multiple paths • Applies to CONTROL crossings • Metastable signal fans out to other logic instead of remaining isolated by synchronizer flop


21

Qualifier merges with another source before gating logic • Applies to DATA crossings  ENABLE synchronization variation • Unstable ‘SrcSignal’ can cause glitch at gate ‘G1’ for otherwise qualified destination flop ‘EN’


22

Qualifier merges with another source before gating logic • Applies to DATA crossings  AND synchronization variation • Unstable ‘SrcSignal’ can cause glitch at gate ‘G1’ for otherwise valid qualifier gate ‘G2’


23

Convergence in CONTROL Crossings Sources converge BEFORE synchronizer possible GLITCH problem A X

Sources converge AFTER synchronizers possible COHERENCY problem

B Y

Z

• When is this not a problem? – Sources do not change in same clock cycle



exclusive (gray-encoded)

– Sources are known not to be correlated



unrelated


24

Impact of Glitches • DATA crossings –Problem –Remedy

 

unisolated metastability valid qualifier gating logic DF

C

ZF

Q

• CONTROL crossings –Problem –Remedy © 2016 Synopsys, Inc.

25

destination captures unintended pulse  must fix OR define assumptions 

Design Constraints for CDC Verification • Primary assumptions – Clocks, asynchronous resets, case-analysis values, blackbox-pin-clock relationships, input-port-clock relationships, clock-to-clock relationships

• Other assumptions – Static signals, synchronous resets, signal types, exclusive sources, qualifiers, synchronizer cells, CDC false paths, …

• SpyGlass auto-extracts constraint candidates for those assumptions shown – SpyGlass Design Constraints format (SGDC) – Requires review and “finalizing” by designer – Some order-of-extraction dependencies – Not meaningful to extract input-port-clock relationships or static signals until clocks and case-analysis values are finalized

• SpyGlass also use SDC directly if it is available – create_clock, create_generated_clock, set_case_analysis, set_clock_groups, … – Designer must still provide remaining assumptions – asynchronous resets, static signals, … © 2016 Synopsys, Inc.

26

Constraint Correctness and Completeness • SpyGlass verifies correctness and completeness of design constraints – Clock propagates to every flop clock pin – Each clock pin receives one and only one clock domain

– Reset propagates to every flop async pin – Active value of reset actually clears/presets flop

– All clock muxes constrained to propagate a single clock – All input ports fully constrained – Domain conflicts identified and all clock-to-clock relationships understood – Each pin of blackbox cells has related clock – No library cells are missing required definitions – Constraint conflicts identified


27

Constraint-Directed “Waiving” 

Do not waive CDC violations •

Only “hides” unsynchronized crossings

•

Data crossing requires a GOOD control crossing

•

Unsynchronized crossings are not checked functionally for Data Hold, Data Loss, Coherency or Glitch

• •

Does not provide design intent information necessary to close verification If CONTROL crossing is UN-synchronized, related DATA crossing will be un-synchronized

Use Constraints to share design intent (resolve synchronization problems ) set_case_analysis – Use to ensure

quasi_static – Use to describe

reset -sync – Use to identify

only one clock or correct mode of operation

signals that mode won’t toggle during operational

synchronous design intent resets based upon

qualifier – Use when synchronization signal_type -type control – Use for occurs outside of block/IP or within a vector (data) qualifiers merging with blackbox data path cdc_attribute – Use to define relationship of converging sources – exclusive or unrelated © 2016 Synopsys, Inc.

28

sync_cell – Use for hard macro synchronizers or approved synchronizer module

cdc_false_path – Use if sync scheme is externally or software controlled (for example, clocks are off during changing). There are other rules that will honor this constraint and remove other potential violations

Functional Clock Domain Crossing Verification • Why is functional verification needed? – Good synchronization structure may not operate as intended to transfer data from source to destination – Example – Good structure at right will not prevent metastability if D changes when EN is active

– Only functional verification can ensure correctness

D

Q EN

Ck1

• Pre-requisites for Functional Verification – Good synchronization structures – All structural CDC issues must be resolved

• MUST-RUN functional checks – Data hold check – data-enable sequencing for DATA crossings (Ac_datahold01) – Data loss check – fast-to-slow width extension for CONTROL crossings (Ac_cdc01) – Coherency check – signals converging after synchronizers are gray-encoded (Ac_conv02) – Glitch check – signals converging before synchronizers are gray-encoded (Ac_glitch03)


29

Ck2

Data Hold and our Protocol Independent example • Structural verification, alone, *CANNOT* guarantee … – Data remains stable when qualifier enables transfer – Tool-detected qualifier is designer-intended qualifier Data

Address

Destination

Enabling Logic

Active

Qualifier


30

Example – Unintended Qualifier • Good synchronization structure, but … D

Appears to be qualifier, but actually a sync reset… crossing not really synchronized

Ck1

Ck2 Q

• Data hold check ensures that when Q is asserted, D remains stable! – A synchronous reset, or any signal not intended to qualify a DATA crossing, will not be able to satisfy this requirement under all conditions and will be flagged by rule Ac_datahold01


31

Data Loss • Situations where there can be data loss include … – Faster source clock, slower destination clock – Same-period source and destination clocks Data crosses from faster to slower clock domain

There is a high probability of data loss

clk_fast q_data

clk_slow output Data loss

Solution: extend source data for at least a full cycle of the destination clock


32

Functional Violation – Data Hold

Structural Functional

Formal

Simulation

Data is changing

high Enables are high


33

Hybrid CDC – Auto-generated SVA for Dynamic Verification • SVAs generated for CDC assumptions & protocols • Design signals (clock, resets, tx_reg) are automatically inferred and connected to SVA assertions • Supports all simulators


34

Structural Functional

Formal

Simulation

Structured Use Model – SpyGlass GuideWare Flow Auto-extract clocks & reset

Goals Existing SDC

• Verify setup of clocks & resets

• Verify metastability synchronization • Verify asynchronous resets • Verify boundary conditions

• Verify data integrity of synchronized crossings


35

Rules

cdc_setup • Auto-extract clocks, resets • Auto-extract blackbox setups

Clock_info01 Reset_info01 SetupClock01

cdc_setup_check • All clock, reset pins constrained • All clock muxes constrained • Auto-extract input-clock relationships • All input domains constrained cdc/clock_reset_integrity

Clock_info03a Clock_info05/b Setup_port01

cdc_verify_struct ( structural checks) Ac_unsync01/02 Ac_sync01/02 • Synchronization is clean Ar_asyncdeassert01 • Async resets properly de-asserted • Auto-extract static candidates • Identify convergences • Identify glitches

Clock_sync05/06 Setup_quasi_static01 Ac_conv01/02/03 Ac_glitch03

cdc_verify (functional checks) • Verify data-enable sequencing • Verify no data loss • Verify data coherency • Verify no glitches

Ac_cdc01a Ac_datahold01a Ac_conv02/04/05 Ac_glitch03

V i o l a t i o n s a r e f i x e d in t h i s o r d e r

Agenda •


•


•


36

Additional Topics & Wrap-up •

Hierarchical CDC

• •

Reset Domain Crossings Wrap up

Comparison of So C CDC Flows Flat Flow

SOC Constraints FULL FLAT Synthesized Design

Optionally Reuse Block Level Constraints and Waivers

Bottom-up Flow

Abstract Flow

BLOCK ConstraintsBLOCK ConstraintsBLOCK Constraints Synthesized Synthesized Design Synthesized Design Design

SOC Constraints

Reports/GUI

Synthesized Design (blocks replaced with abstracts)

Abstracted Block Abstracted Block Abstracted Block(s)

Reports/GUI


37

Abstracted Block(s) Abstracted Block(s) Abstracted Block(s)

Reports/GUI

Flows for CDC SoC Analysis • FLAT FLOW – Entire design is verified when SoC is put together – Constraints are defined for the top, design is fully elaborated and run flat with all crossings (intra block and inter block) analyzed. – ip_block constraint can filter intra block CDC violations only.

– Optionally SoC top level run “re-uses” block level constraints – in effect applying CDC intent for blocks that have been previously analyzed (set_case_analysis, quasi_static, qualifier) – Eliminates re-visiting CDC false violations

– Debug usually done by SoC integrator with help from IP owners. – Optionally run bottom up CDC verification by block level IP owners and signed off.

• ABSTRACT FLOW

– Design uses abstract model for block instead of RTL. – IP CDC verification done by block owners and abstract models signed off

– Speeds up run time and reduces memory – Reduced number of top level violations as only top level issues are flagged – SOC integrator validates constraints and gives feedback on blocks where constraints mismatched

– No need to re-use block level waivers or constraints © 2016 Synopsys, Inc.

38

Abstract Flow Block Constraint Gen

Block Constraint

SDC (Opt)

Block RTL

Block CDC Verification

Abstract Model Defines ports • domains • synchronizers visible • connectivity to IOs • Generated clocks, resets

Top Constraint Gen

SoC constraint

SoC RTL

Block Constraint Validation

Top CDC verification © 2016 Synopsys, Inc.

39

SDC (Opt)

Creating Abstract Views – Output Ports • Constraints generated automatically based on block-level connectivity and propagated constraints – abstract_port, clock, set_case_analysis and quasi_static constraints can be generated

abstract_port –ports O1 –clock C2 -related_ports IN1 abstract_port –ports O2 –clock C2 –sync inactive –from C1 –to C2 –names “<>.sync1” abstract_port –ports O3 –clock C2 –sync active –from C1 –to C2 –seq yes –names “<>.sync2” abstract_port – yes ports–related_ports O4 –clock C1 IN2 –combo abstract_port –ports O4 –path_logic combo set_case_analysis -name foo -value 0 abstract_port -ports O5 -related_ports IN5 -path_logic combo © 2016 Synopsys, Inc.

40

Agenda •


•


•


41


Hierarchical CDC

• •


Reset Domain Crossing (RDC) Verification • RDC challenges are similar to CDC • SpyGlass RDC identifies metastability scenarios caused by asynchronous resets – If rst1 is asserted, then the Q output of flop1 is asynchronous to the CLK – 2nd flop can go metastable due to data setup/hold violation caused by async assertion of rst1


42

Synchronized RDC • Reset isolation or qualifier based synchronization • • •

Constraint: qualifier –name q3 –rdc RDC (between q1_reg(purple) and q2_reg(golden)) Ar_resetcross01: Synchronized crossing because qualifier q3 from q3_reg(grey) output will qualify (gate) it

NOTE: Both qualifier flop and destination flop reset and clock must match © 2016 Synopsys, Inc.

43

RDC: Solutions Gating Logic to ensure destination clock not toggling when source reset is active

Reset control logic sequence ensures RDC correctness – Block A is reset before block B – RESET1 is ASSERTED AFTER RESET2 – 2nd flop is forced into reset state to Negate D pin’s Impact

Block the clock to second flop Add a synchronizer Synchronization Flops


44

Agenda •


•


•


45


Hierarchical CDC

• •


Comprehensive CDC Verification for IP & SoC CDC IP Signoff

CDC SoC Signoff

Structural SoC CDC

Structural CDC

Flat

Formal CDC

Hierarchical

Waivers + Abstract models (optional)


46

Hybrid CDC

Hybrid CDC

(SVA into Simulation)

(SVA into Simulation)

Synopsys Static Verification Products Lint

CDC & RDC

De facto industry standard for RTL lint

Comprehensive clock & reset domain verification

Comprehensive SDC verification

Drives correct-by-construction RTL design

Structural, formal & simulation-based

Formal false & multi-cycle path verification

Constraints & Timing Exceptions

Signoff quality & billion+ gate capacity

Power Estimation & Reduction

Power Verification

DFT

RTL Power estimation, exploration and reduction CDC-safe power reduction

UPF-based RTL & netlist power intent verification Power/ground connectivity checks at post-layout

Stuck-at & at-speed test cov analysis at RTL


47

Tight correlation to ATPG (1-2%)

Synopsys RTL Signoff Traditional Design Flow New IPs New IPs New IP

New IPs New IPs Existing IP

New IPs New IPsIP 3rd Party

With Synopsys RTL Signoff New IPs New NewIPs IP

New IPs New IPs IP Existing

New IPs IPs IP rd Party 3New

CDC Power Power Constr Lint SpyGlass RTL Signoff for IPDFT RDC Verif Est/Red TXV

IP Integration

IP Integration CDC Power Power Constr Lint DFT SpyGlass RTL Signoff for SoC RDC Verif Est/Red TXV

Implementation (Synthesis, Place & Route)

Design Effort

Implementation (Synthesis, Place & Route)

Design Effort

• Multiple iterations, divergent process

• Reduced iterations, convergent process

• Significant design effort & schedule risk

• Reduced design effort & schedule risk


48

Thank You

SpyGlass Data Flow GuideWare

RTL / Netlist Files

Other Files (SGDC, SDC, UPF, FSDB, VCD etc…)

Reports

SpyGlass

Waivers

Fix: Change RTL / Design Tech Libraries (.lib, .plib)

Fix: Change Setup

Messages Fix: Add Constraints

Debug DesignSetup © 2016 Synopsys, Inc.

50

GoalSetup

Waive Violation(s)

AnalyzeResults

4-19-16 Back to Basics Cdc v3

Recommend Documents