Meridian CDC.A Training

Meridian CDC 2016.
A Training
©Copyright 2016 Real Intent Inc., Proprietary and Confidential

Real Intent Products
Accelerate RTL sign-off of electronic designs by 3X
Differentiation: Capacity, Accuracy and Debug

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 2
Agenda
• CDC Introduction
• Running Meridian CDC
• Environment Setup
• Structural Checks
• Policies & Debug Flow
• Formal Checks

CDC Introduction

Legend: CDC Terminology
6
3
1
clk2 4
clk1
clk2
5
2
1. Transmit flop
2. Transmit clock clk1 (asynchronous to clk2)
3. Receive flop
4. Double flop synchronizer on the receive side
5. Receive clock clk2 (asynchronous to clk1)
6. Vertical dashed line indicates an asynchronous clock crossing boundary

CDC Verification Is Difficult
D Q clk
When input changes within setup/hold
D window, the output of the flop becomes
clk metastable: could settle into either 0 or 1
Q
 CDC bugs are a result of bad implementation, timing, and logic

 Hard to detect and diagnose (with simulation or in the lab)
 Frequent chip failures in the field – expensive to fix
Analysis is difficult
 Very high number of CDC crossings
 Variety of ways of implementing the crossings
 Need to model metastability

Understanding CDC Issues
For designs with asynchronous clock domains, an unavoidable situation is
that the CDC signal violates the setup/hold window of the receiving clock,
resulting in metastability
Transmit Flop Receive Flop

D Q
CDC Signal
D Q
Metastability
• Unpredictable results
clk1 clk2 • Unpredictable delay
Metastability-related failures can be intermittent and hard to find,

resulting in expensive chip re-spins when found late in the design cycle.
Need an effective CDC strategy to avoid metastability-related failures early!

Examples of Potential Fatal CDC Errors
Loss of Data
Without protection, the output of the

Data
receiving flop could have a different
clk1 clk2 value from the transmitting flop owing
to metastability, resulting in loss of data
Controls Losing Correlation

Because of the metastability effect, the
outputs of the two synchronizer paths
clk2 could have different values, resulting in
clk1 loss of correlation
clk2

Examples of Potential Fatal CDC Errors
Data Corruption
Data
Without control-signal synchronization,
clk1 clk2 metastability could propagate
downstream, resulting in data corruption
Control
clk1 clk2
Glitch Propagation
A timing glitch could be captured in
clk1 the receiving domain, resulting in a
clk3 downstream design failure
clk2

Common Synchronization Scheme
Handshake Protocols
Data
Control
Control crossing must: Data crossing needs to

1. Be synchronized be stable for more
2. Have only one signal transition for buses (gray-coded) than 1 receiving clock
3. Be free of hazards & glitches cycle prior to being
4. Be stable for more than 1 receiving clock cycle latched

CDC Verification: Where and What
 Verify CDC Protocols Block
<n>
 Ensure synchronizers are built correctly
 Verify FIFO and handshake protocols
 Use structural & formal analysis
Block A
 Verify Block and Full Chip


Block B
Enforce CDC protocol usage
 Identify all control and data crossings
Block C
 Check for correctness of complex structures
 Verify downstream logic is robust against Block <n>
metastability Block D
 Use structural analysis and simulation
Gate Level
 Verify Gate-Level Netlist D
Q
D
Q
 Ensure no CDC issues in implementation

(such as no glitch introduced during synthesis)
 Use structural analysis

Challenges in CDC Sign-off
Report is too NOISY
“The CDC report was 30,000 lines long; it was
impossible to go through all the messages…”
WAIVERs to reduce NOISE Design is too BIG

“Accidentally waived a violation with “Our design is too large to run CDC at
regex, which waived a real crossing; it the top level, so we reverted to
was hard to examine all violations manual review of crossings between
because of many false violations…” blocks…”
Tool MISSED a Crossing INCORRECT Design Reuse

“The tool missed a crossing so we “The code has worked in the past, so
didn’t know we had an issue…” we waived this…”

Components of CDC Verification
Meridian CDC Verification

Structural Analysis Formal Analysis
Clock Issues Pulse Width Issues
Reset Issues Data Stability Issues
Structural Issues Gray Code Issues
Control, Data, & INTERFACE Glitch Issues

Running Meridian CDC

Flow Overview
Design
Fix
Correct Refine Refines
DESIGN Intuitive Design SETUP Intuitive ENV CDC Intuitive CDC

Setup Debug Sign-off Analysis Debug Sign-off Analysis Debug Sign-off
DESIGN Analysis SETUP Analysis CDC Analysis
 Review Lint report  Automatic clock inference  Fastest run time, highest capacity
 Library setup  Help refine environment to ensure  Complete coverage with least noise
high quality CDC analysis  Intuitive associations on CDC
 Concise schematic view for root interface crossings
cause analysis  Formally verify CDC interfaces
 Intuitive debugging environment  Intuitive debugging environment

Flow Steps

Meridian CDC Invocation
• Interactive mode (Tcl interface):

• meridian
• Script mode (recommended):

• meridian -i run.ctl
• At PMC, use make flow

Getting Help in Meridian CDC
• User Guide and Reference Manuals

• meridian -doc will open browser and load HTML docs
• meridian -help for command-line options
• Inside Meridian CDC shell

• help to get all Meridian commands
• help <command> to get command options
• help <MsgId> to get information about a message
• help <CategoryName> to get information about result
categories (type list_categories to see the valid list)

Design Setup (make create_env)

Front-End Options
• For files containing SystemVerilog

• Use analyze -sv
For example: analyze -sv -f files.list
• Works for most cases
• Use more than one analyze statement
• One analyze statement for Verilog (-v95, -v2k)
• One analyze statement for SystemVerilog (-sv|-sverilog, -sv05, -sv09)
• One or more analyze statements for VHDL
• Variables you might need
• ri_incdef_accumulate
• ri_vy_lib_accumulate
• ri_vhdl_map_work_to_target_library

Gate-Level Support
• Same Meridian CDC interface for gate-level support
• Library needs special attention

• Simulation library typically contains unsynthesizable constructs
• Use synthesis .lib library, if available
• Use read_liberty command to convert .lib to .v first

Meridian CDC Output
• meridian_project
• Stores generated design database, rules, and other metadata
• Used for debug in GUI/CLI using iDebug
• Used for incremental analysis
• meridian.log
• Contains Meridian CDC run log, warning or error messages

Environment Setup

Environment Setup (make create_env)
• Generate initial environment

from SDC, design, or existing
ENV
• Can source Tcl constraints
directly as well
• See SDC_ENV_LINT in
iDebug

Meridian CDC Environment File
• Automatically Generated and Enhanced

• From SDC [Tcl]
• Output environment contains translated SDC, as well as additional reset spec
and other auto-detected environment setup
• Import create_clock, create_generated_clock, set_case_analysis,
set_input_delay, set_output_delay, set_clock_groups, & set_false_path
• read_sdc design.sdc
• analyze_intent -output_env top.env
• From design
• Output .env contains auto-detected environment setup
• From existing ENV

• Output .env contains existing specs and auto-detected environment setup
• read_env design.env
Sample Environment File
• Define clock, reset spec

• Set design mode
create_waveform -period 10 -transitions {0 5} {CLK1}
create_clock -waveform {CLK1} {wb_clk}
create_reset -interval 10 -waveform {CLK1} {wb_rst}
create_input -waveform {CLK1} {wb_data_i[31:0]}
set_constant -value 1’b0 {test_mode}
#suggested clock muxing

#set_constant -value 1’b0 {clk_mux}

Creating Clock
create_waveform -period 10 -transitions {0 5} {CLK1} asynchronous

create_clock -waveform {CLK2} {mk_clk}

create_clock -waveform {CLK1} {wb_clk} synchronous
create_clock -waveform {CLK1} {fm_clk}
create_waveform -period 10 -transitions {0 5} {CLK1} synchronous

create_derived_waveform -parent {CLK1} -divide_by 3 {S_CLK2}

create_clock -waveform {S_CLK2} {smk_clk}

Useful Environment Commands
• set_constant
• Used to set a constant value for a signal
set_constant -value 1’b1 {async_mode}
• Typically used to set mode bits, mux selects, and so on
• set_stable_value
• Used to indicate that a signal value will remain stable once set
set_stable_value {proc_cfg1}
• Used for configuration registers, special function registers, and so on
• These signals treated accordingly for CDC

Intent Analysis (make setup_check)

Environment Cleanup
• After initial ENV creation (either from SDC or design),

further iterations needed to clean up environment
• analyze_intent does setup checks with ENV specs
• Setup checks only
• read_env top.env
• analyze_intent -disable_auto_intent_generation
• Setup checks and ENV augmentation
• read_env top.env
• analyze_intent -output_env top_new.env

Setup Checks
• Setup rules appear under the MCDC_SETUP_CHECKS rule group
• Rules are classified in the following categories
• ERROR – Important setup violations
• WARNING – Remaining setup violations
• REVIEW – Confirm this matches setup intent
• INFO – Not rule violations; just informational messages to aid debug
• Recommended order of debug
• ERROR > WARNING > REVIEW
• Glance at INFO category

Setup Checks
Severity Rule Name Severity Rule Name

S_NOCLK S_GENCLK
S_MULTCLK WARNING S_UNKNOWN_CLKPOL
S_CLK_OFF_SUB_TREE S_CONF_ENV
S_NORST
Severity Rule Name
ERROR
S_RST_INV CLOCK_GROUPS
S_INPUT_NO_WAVE REVIEW
BLACK_BOX
S_CLK_GATE_NO_WAVE
Severity Rule Name
S_NET_NO_WAVE
I_CONSTANT
INFO
I_RST_SIGNAL

Potential Impact of
Bad Environment Setup
• Missing crossings
• S_NOCLK, S_MULTCLK, S_UNKNOWN_CLKPOL, S_CONF_ENV,
S_INPUT_NO_WAVE, S_NET_NO_WAVE, S_CLK_OFF_SUB_TREE,
S_RST_INV
• Missing warnings
• S_GENCLK, S_NORST, S_CONF_ENV, S_CLK_OFF_SUB_TREE
• Spurious warnings
• S_GENCLK, S_NORST, S_CONF_ENV, S_CLK_GATE_NO_WAVE

Typical User Actions
• Provide additional environment spec for clock/reset/constant

• Correct environment specification
• Make design fix
• Waive in case the suggested environment behavior is incorrect

S_NOCLK:
Clock trees missing clock spec
create_waveform -period 10 -transitions {0 5} {CLK}
create_clock -waveform {CLK} {T_CLK}
T_CLK
S_CLK
1’b0
D_CLK
Cause: Because of the constant in the T_CLK propagation path and S_CLK not being defined in the
ENV file, Meridian CDC does not know the clock spec on D_CLK; therefore, S_NOCLK is reported on
D_CLK.
Action: Add clock spec for D_CLK or S_CLK using create_waveform and create_clock commands in
the ENV file.

S_MULTCLK:
Nets with multiple clock waveforms
CLK1
CLK2
D_CLK
SEL
Cause: Clock spec is given for CLK1 and CLK2, however SEL is not tied to a constant.
Both clock waveforms are propagated to D_CLK; one arbitrary waveform is chosen for
D_CLK. S_MULTCLK is reported on D_CLK.
Action: Tie SEL to a constant using the set_constant command in the ENV file.

S_NORST:
Reset sub-trees missing reset spec
POR_RST
SOFT_RST
Cause: There is a reset spec for POR_RST; however, there is no reset spec
on SOFT_RST in the environment file; therefore, S_NORST is reported on
SOFT_RST.
Action: Add reset spec for SOFT_RST using the create_reset command in
the ENV file. Use -low to indicate an active-low reset.

BLACK_BOX:
Blackboxed Modules & Large Constructs
• Meridian is reporting blackboxed modules and large constructs in the design
INFO Description
User-defined-module Module exists, but specified using elaborate -black_box
Missing-module Module missing and specified using elaborate -black_box
Unknown-missing-module Module missing and BBOXed using elaborate -auto_black_box
Auto-RAM BBOXed due to being beyond threshold
Auto-large-array BBOXed due to being beyond threshold
Auto-operator BBOXed due to detection of "*", "/", "<<" or ">>" operator
• Blackboxed modules are removed from CDC analysis
• Blackbox outputs must be associated to a clock domain using create_input (see S_NET_NO_WAVE)
• Blackbox inputs may be associated to a clock domain using create_output to allow a minimal check for crossings
• Auto-RAM / Auto-large-array / Auto-operator are replaced with a simple cross-

bar that propagates clock domains from inputs to outputs
• Suggested action:
• Confirm blackboxes and provide model (RTL, netlist, Liberty) if possible
Structural Checks

Structural Analysis (make verify_cdc)

Structural Analysis
• Detect CDC Issues

• Incorrect synchronization
•Missing synchronizers, half-stage synchronizers
• Glitch potential
•Synchronizers, derived clock, gated clock
• Loss of correlation
• Reconvergence of CDC signals, clock signals
• Benefit: To ensure CDC correctness

Analysis Checks
• Analysis rules appear under the MCDC_ANALYSIS_CHECKS rule group
• Rules are classified in the following categories
• ERROR – Important CDC violations
• WARNING – Remaining CDC violations
• REVIEW – Confirm this matches CDC intent
• INFO – Not rule violations; just informational messages to aid debug
• Recommended order of debug
• ERROR > WARNING > REVIEW
• Glance at INFO category

Analysis Checks
Severities Rule Name Severities Rule Name

W_CNTL W_HALF
W_MASYNC W_RST_HALF
WARNING
W_DATA W_REDUNDANT_SYNC
W_ASYNC_RST_FLOPS W_ENCAP
W_INTERFACE
ERROR
W_GLITCH
W_FANOUT
W_RECON_GROUPS
W_G_CLK_GLITCH
W_CLK_RECON

Analysis Checks
Severity Rule Name Severity Rule Name

CLK_GROUPS I_CLK_DOMAINS
BLACK_BOX I_CLK_TREES
INFO
CNTL I_CONSTANT
DATA I_RST_SIGNAL
REVIEW INTERFACE
U_INTERFACE
GRAY_CODE_CHECKS
SYNC_CROSSING
RST_SYNC

W_GLITCH: Synchronizers with
glitch potential on input
• Timing glitch could be captured in the receiving domain, resulting
in downstream design failure
W_GLITCH
x
clk2
clk1
• By default, Meridian CDC assumes that all primary inputs have

glitch potential
Set the following variable to change the default:
set ri_assume_primary_inputs_have_glitch_potential false (default: true)

W_MASYNC: Multiple
asynchronous signals combining
• Meridian CDC reports multiple asynchronous signal combinations in the
following situations
• When signals from two or more clock domains are combined and synchronized into a new clock
domain
• When signals from two or more clock domains are combined to form an output of the module
• To disable checking W_MASYNC on outputs:
set ri_detect_masync_on_outputs false (default: true)
W_MASYNC
clk1 x
clk3
clk2

W_ASYNC_RST_FLOPS: async reset
generated from an async clock domain
W_ASYNC_RST_FLOPS
RST
FF1 FF2 FF3
clka domain clkb domain
Cause: clka and clkb are asynchronous domains to each other. RST, generated from
clka domain, is used in the clkb domain to reset FF1, FF2, and FF3 asynchronously.
Meridian CDC flags FF1, FF2, FF3 as W_ASYNC_RST_FLOPS.
Action: Examine RST signals for the reported flops. Insert a Reset Synchronizer in the
receive clock domain, if needed, else Sign-off after review.

CDC Interface Fundamentals
Data
Control
D D
Q Q
Feedback
• Asynchronous boundary crossing signal that is not feeding a synchronizer is a DATA

• Asynchronous boundary crossing signal that is feeding into a synchronizer is a CNTL
• For safe operation, a DATA signal should be controlled by a synchronized CNTL
• CNTL is fed back (Feedback) to the Tx domain to indicate safe capture of transmit DATA
• Above entire crossing relation is considered an INTERFACE
DATA and Association
• Meridian CDC considers an asynchronous boundary crossing signal

that is not feeding a synchronizer as a DATA signal
Associations
Load-Control
Prop-Control (default off)
Fifo-Control
User
DATA
None
W_DATA Err-Prop
Potential-Sync

DATA: Load-Control
Data
Control
Feedback
Cause: Synchronized control signal controls loading of DATA.
Action: Review and sign off.

DATA: Prop-Control
Data
Control
Feedback
Cause: Synchronized control signal controls propagation of DATA.
Action: Review and understand.

DATA: Fifo-Control
Data In
Data Out
+
Binary to Gray Gray to Binary Empty
== ==
Write Pointer Full
+
Gray to Binary Binary to Gray
CLK1 CLK2
Read Pointer
Cause: Synchronized control signal controls FIFO data.
Action: Review and understand.

DATA: User
User
Tx Data Rx Data
Tx Domain Rx Domain
When you provide a list of modules using the set_user_associated_cells command,

Meridian CDC considers data signals within listed modules as user-associated.
These associations override the associations determined by Meridian CDC.

W_DATA: None
W_DATA : None
Tx Data Rx Data
x
Tx Domain Rx Domain
Cause: Signal Tx Data, from the Transmit domain, crosses over into the Receive clock domain.
This crossing is not controlled by a synchronized control signal or a FIFO.
Meridian CDC reports such a DATA-CNTL association as None.
Action: Examine the logic controlling this interface. Try to find unidentified or misdetected
CNTL signals.

W_DATA: Err-Prop
W_DATA : Err-Prop
Tx Data Rx Data
x
x
Sync Control
Tx Domain Rx Domain
Cause: The synchronizer depth of Sync Control is 1, which can induce

metastability in the data.
Action: Review the identified structural association and make appropriate fixes.

W_DATA: Potential-Sync
W_DATA : Potential-Sync
Rst SyncRst
inb
Tx Domain Rx Domain
Cause: Could potentially be CNTL crossing, but misidentified by Meridian CDC as DATA crossing.
Action: Review the identified structural association. Use reclassification if necessary to

override the default classification.

CNTL and Associations
• Meridian CDC considers an asynchronous boundary signal feeding a
synchronizer as a CONTROL (CNTL) signal
• Synchronizers can be two, three, or more flop stages
Associations Info
Data -
Has-Feedback -
Is-Feedback -
None -
CNTL User -
Blocked -
Has-Err-Feedback -
W_CNTL
Missing-Feedback
Data
Sync-Depth-Err

CNTL: Data
CNTL : Data
Rx Data
Tx Data
Sync Control
Tx Domain Rx domain
Cause: Meridian CDC detected synchronized CNTL signals blocking or controlling DATA signals in the
receive clock domain. Sync Control is controlling a data signal Tx Data. Meridian CDC reports such a
CNTL signal as Data associated.
Action: Ensure that the CNTL signal and DATA signal associations that Meridian CDC reports are correct.

CNTL: Has-Feedback/Is-Feedback
CNTL : Has-Feedback Rx Data
Tx Data
Sync Control
DataReady Control Signal
CNTL : Is-Feedback
Tx domain Rx domain
Cause: Meridian CDC detected synchronized CNTL signal(s) blocking or controlling DATA
signals in the receive domain and this CNTL signal(s) is being fed back to the transmit domain.
Typically, such asynchronous interface structures are used in handshaking protocols.
This CNTL signal is also fed back to the Tx domain. Meridian CDC reports the signal controlling
the data as Has-Feedback and the signal returning to the Tx domain as Is-Feedback.
Action: Ensure that the CNTL signal and the Feedback signal that Meridian CDC
reported is correct.
CNTL: None
CNTL/W_CNTL : None
Tx Control Rx Control
Cause: Meridian CDC detected synchronized CNTL signals that are not blocking or controlling any
DATA signals. Typically, synchronized CNTL signals are expected to be controlling DATA crossings .
A signal from the Transmit domain, Tx Control, crosses over into the Receive domain, and there is
no associated DATA. Set the ri_report_none_as_w_cntl variable to true (default is false) to
include those CNTL signals with association None in the W_CNTL category.
Action: The use of the synchronizer may not be necessary or these signals may need to
be reclassified as DATA crossings.

CNTL: User
CNTL : User
Tx Control Rx Control
When you provide a list of modules using the set_user_associated_cells

command, Meridian CDC considers the specified control signals as user-
associated. A signal from the Transmit domain, Tx Control, crosses over into the
Receive domain. Users have instructed Meridian CDC to report these control
crossings within the listed modules as user-associated.

W_CNTL: Blocked
W_CNTL : Blocked
Rx Data
Tx Data
Sync Control 1’b0
Tx Domain Rx domain
Cause: Meridian CDC detected synchronized CNTL signals that are either blocked by constants
or don’t drive anything. A signal from the Transmit domain, Tx Data, crosses over into the
Receive domain. This crossing is controlled by a synchronized control signal, Sync Control. The
loading of Tx Data into the receive domain flop, Rx Data, is blocked by the signal, Sync Control,
owing to the constant disabling the output of the AND gate. Meridian CDC reports such a DATA-
CNTL association as Blocked.
Action: Examine the CNTL signals to make sure the logic is intended.

W_CNTL: Has-Err-Feedback
Rx Data
Tx Data
Sync Control
DataReady Control Signal
W_CNTL : Has-Err-Feedback
Tx domain Rx domain
Cause: CNTL is associated with some DATA and appears to have a feedback. However, there is
an issue with the feedback such that it will not work as expected.
Action: Fix the Feedback path.

W_CNTL: Data Missing-Feedback
Cause: CNTL is associated with some DATA, but has no feedback. The Info column displays
Missing-Feedback and reports W_CNTL. To disable, set the set ri_check_missing_feedback
variable to false (default is true).
Action: Ensure that the CNTL signal and DATA signal association that Meridian CDC reports is
correct.

W_CNTL: Data Sync-Depth-Err
• Sync-Depth-Err can occur when the following variable is used to

specify minimum synchronizer depth for specific clock domains
• ri_min_synchronizer_depth_<n>_domains
• Ex : set ri_min_synchronizer_depth_3_domains CLK2

INTERFACE Categories
• Rules for enhanced CDC reporting requirements

• INTERFACE (structurally good CDC)
• U_INTERFACE (structurally good user CDC intent)
• W_INTERFACE (unexpected crossings or user intent conflicts)
• Error-Feedback – depth issue in feedback path
• Missing-Feedback-To-Tx – found feedback path to one of Tx-Data or Tx-Cntl, not both
• Objective
• Ability to read in user CDC intent and categorize them for easy sign-off
• Ability to include All Drivers (TxFlops) in the main report that shows entire
CDC interface
• Ability to check entire interface more thoroughly for potential CDC issues
• Replaces existing LOAD_CNTL_DATA_GROUPS,
FIFO_CNTL_DATA_GROUPS, & W_CNTL_DATA_GROUPS

INTERFACE

U_INTERFACE

W_INTERFACE

Useful Association Commands
• Commands to support user configurability for CNTL-DATA

association
• Enable signal-level assignment of CNTL-DATA association
• create_association
• Specify an interface as user-defined, thus classified as U_INTERFACE
• create_association -name <> -data_rx <> [-data_tx <>] -cntl_rx <> [-cntl_fb <>]
[-module <> [-exclude_instances <>] | [-instances <>]] [-comments <>]
• remove_association
• Break an association the tool inferred between specific CNTL & DATA signals
• remove_association -name <> -data_rx <> -cntl_rx <>
[-module <> [-exclude_instances <>] | [-instances <>]] [-comments <>]
• set_cntl_association_depth
Override global depth by setting association depth of specific CNTL signals

Useful Commands
New commands that replace variables allowing for more

control and better error checking
• set_user_cntl_synchronizer [-force] [-non_strict]
Replaces ri_user_sync_cells, ri_force_sync_within_cells,
ri_non_strict_in_cells
• set_user_reset_synchronizer [-force] [-non_strict]
Replaces ri_force_reset_sync_within_cells
• set_user_specified_cells
Replaces ri_user_specified_cells
• set_synchronizer_depth [-min] [-max] [-rst_min] [-rst_max]
Replaces ri_min_synchronizer_depth, ri_max_synchronizer_depth,
ri_min_reset_synchronizer_depth, ri_max_reset_synchronizer_depth

Useful Commands
Commands that improve flow or add new capability

• set_mutex_signals
Specify a group of signals as being mutually exclusive, which sets them to
ToolWaived in W_GLITCH, W_MASYNC, and W_RECON_GROUPS
• verify_cdc_formal
Formal can now be iterated without re-running structural analysis
• get_all_modules
Returns all parameterized names for a given base name
• get_all_instances
Returns all instance names for a given parameterized module name

Useful Commands
set_data_clock_domain supports waveform propagation

over combinatorial CDC qualifier
• Addresses issues with clock domain output on AXI style bus
interfaces and combinational FIFO data out
• Command syntax:
set_data_clock_domain [-module <>] [-pos_phase | -neg_phase]
-derived_from <> { list of signals }
For example: Setting clock domain of dataout to be derived from the

waveform received by rdptr signal
set_data_clock_domain {dataout} -module {fifo_base-16-4}
-derived_from {rdptr[0]}

set_data_clock_domain
module asynchronous_fifo
WR_reg
D Q DOUT
DATA
CK
R
R_reg
REN
Q D
WEN
CK Rclk
Wclk R
Setting clock domain of DOUT to be derived from the waveform received by REN signal
•set_data_clock_domain {DOUT} -module {asynchronous_fifo} -derived_from {REN}

set_data_clock_domain
Original violation
After applying set_data_clock_domain, W_MASYNC is no longer there:

set_data_clock_domain -derived_from {rd_addr_bin[0]} {fifo_rd_data}

Reconvergence – Important Aspects
Info Label Meaning
FifoInterfaceRecon Recon point part of a FIFO interface
InterfaceRecon Recon point part of a load/prop interface
FifoInterfaceReconWithLocalFanout Recon point fans outside interface logic, but
does not interact with outside logic; typical
case for primary outputs
InterfaceReconWithLocalFanout Recon point fans outside interface logic, but
does not interact with outside logic; typical
case for primary outputs
MultipleInterfaceRecon Recon point participates in more than one
interface
InterfaceReconButGlobalCntlDrivers All CNTLs reported as drivers for this recon
point are part of an interface, BUT there are
also other CNTLs that drive this recon: CNTLs
that are typically in other clock domains
GlobalReconNoInterface Recon is truly not part of any interface

Policies & Debug Flow

iDebug Overview
• DB populated with comprehensive CDC analysis data
• Customizable for any customer flow
• Facilitates easy debug and sign-off
• Ordered, on-demand debugging
• Issue status updated as reviewed
• Can return to session later and continue
• Powerful data selection
• Sort/select data interactively
• Design scope-based CDC reporting
• Generate data views to isolate issues of interest
• Allows team debug
• Shared database; changes made can be shared with others
• Multiple designers can review a single database
• Tcl-based Command-Line Interface (CLI)
• Access to design objects and violations
• Users can create custom scripts
Spreadsheet-based View and Edit

Improved Schematics
Old Schematic
• Improved Schematics
• Ultra Fast schematic generation
• Interactive Graphic Fragment
Navigation shows only critical
fragments of the RTL
• Precise to root cause the problem
faster
• No clutter - save debug time
• Integrated waveform viewer, with
interactive signal tracing
New Schematic

Glitch – Improved Schematics and
Debug

Meridian CDC Debug Flow
read_sdc analyze_intent
Setup
Read
(Intent)
SDC File Analysis
Optional
ENV
read_env analyze_intent verify_cdc

Setup
Read Structural CDC
(Intent)
ENV File Analysis Analysis SignOff
Waive False Violation

iDebug Invocation (make debug_cdc)
• GUI mode:
• idebug
• CLI mode (Tcl interface):
• idebug -cli
• Useful options:
• -i <script> # Run script upon opening
• -e <script> # Run script upon exiting
• -project <directory> # Location of project directory
• -design <name> # Name of design top
• -previous <directory> # Append to results rather than overwrite
Getting Help in iDebug
• User Guide and Reference Manuals

• idebug -doc will open browser and load HTML docs
• idebug -help for command-line options
• Inside iDebug shell

• help to get all iDebug commands
• help <command> to get command options

Terminology
• Rule – specific type of violation to be checked

• Rule Instance – Named instance of a specific rule
• Rule Group – mid-level container that holds rule groups of rule
instances
• Policy – top-level container that holds rule groups or rule instances
• RuleContentStatus – status of individual line of given violation
• Status – calculated for whole violation based on RuleContentStatus
of each individual line
• View Criteria – search mechanism for focusing on an area of
interest
• May be applied to Rule Instances, Rule Groups, or Policies to provide a
filtered view
Policies
• Default policies are NEW, TO_BE_FIXED, DEFERRED, &

WAIVED
• Each default policy has a View Criteria based on Status
such that violations move automatically between them
when RuleContentStatus is modified
• All violations start in NEW
• Some commands will mark violations ToolWaived and
move them to WAIVED automatically
• Each policy contains rule groups SDC_ENV_LINT,
MCDC_SETUP_CHECKS, & MCDC_ANALYSIS_CHECKS
Rule Groups
• First level rule groups are Checks (command based)

Checks Check for Command
SDC_ENV_LINT Syntax and semantic issues read_sdc/read_env
MCDC_SETUP_CHECKS Design specification issues analyze_intent
MCDC_ANALYSIS_CHECKS CDC issues verify_cdc
• Second level rule groups are Severities (severity based)

Checks Description
ERROR Critical rules whose violations need to be fixed
WARNING Important rules whose violations need to fixed or waived
REVIEW Rules showing good crossings that need to be verified
INFO Rules containing info useful for debug
Default Policies & Rule Groups
- NEW Policies
- SDC_ENV_LINT
- ERROR Checks
- WARNING - TO_BE_FIXED
- REVIEW - SDC_ENV_LINT
- INFO - ERROR - DEFERRED
- WARNING - SDC_ENV_LINT- WAIVED
- MCDC_SETUP_CHECS
- ERROR - REVIEW - ERROR - SDC_ENV_LINT
- WARNING - INFO - WARNING - ERROR
- REVIEW - MCDC_SETUP_CHECS
- REVIEW - WARNING
- INFO - ERROR - INFO - REVIEW
- WARNING
- MCDC_ANAYSIS_CHECS - MCDC_SETUP_CHECS- INFO
- ERROR - REVIEW - ERROR - MCDC_SETUP_CHECKS
- WARNING - INFO - WARNING - ERROR
- REVIEW - - REVIEW
MCDC_ANAYSIS_CHECS - WARNING
- INFO - ERROR - INFO - REVIEW
- WARNING - MCDC_ANAYSIS_CHECS
- INFO
- REVIEW - ERROR - MCDC_ANAYSIS_CHECKS
- INFO - WARNING - ERROR
Severities - REVIEW - WARNING
- INFO - REVIEW
- INFO
Default Policies & Rule Groups
Policy
Policy Checks
Policy Severities
Policy

Violation Statuses
RuleContentStatus Policy Description

New NEW Default status
ToBeFixed TO_BE_FIXED Violation needs to be fixed
Deferred DEFERRED Violation needs further investigation
Waived WAIVED Violation can be safely ignored
ToolWaived WAIVED Violation “auto-waived” by certain commands

Violation Starts as New

Violation Changed to ToBeFixed

View Criteria
• Search mechanism for focusing on an area of interest

• May be applied to policies, rule groups, rule instances, or
relevant commands to filter the results
• Can be created in View Criteria tab in GUI or via
create_view_criteria command in CLI
• Allows pattern matching and complex expressions

View Criteria
Filtered view of violations

Documentation
Get context-sensitive help
W_GLITCH
rule instance

Meridian CDC Debug Flow
Assign
Analyze Appropriate
Status
Export

Formal Checks

Formal Analysis (make verify_cdc_formal)
START
DESIGN
LIBRARY DESIGN SETUP
OK ? DEBUG
SDC[Tcl]
ENV[Tcl] ENV SETUP
OK ? DEBUG
ENV[Tcl] INTENT ANALYSIS
OK ? DEBUG
POLICIES
(optional) STRUCTURAL ANALYSIS Formal Analysis Sample Script
(to be run using meridian -previous option)
OK ? DEBUG
read_design_db
ASSUMES
(optional) FORMAL ANALYSIS verify_cdc_formal
HERE
source formal_status.tcl
OK ? DEBUG
#set allPolicies {NEW TO_BE_FIXED DEFERRED WAIVED}
#report_policy $allPolicies -output formal.rpt
DONE
Formal Checks
Data Stability Stability of data transfer across asynchronous crossings

Gray Code Only one-bit changes in multi-bit control signal
Pulse Width Control signal wide enough for reliable data transfer
Glitch Logic-generating control signals not prone to glitches

Data Stability Check
Data Stability Formulation
D1 D2
Data
Control
D D
Benefits
Q Q
Glitch-aware
Metastability-aware

Data Stability Check
• Ensure that Tx data is held stable for more than one Rx

clock cycle prior to being latched
• Checks are not run by default

• To enable data stability check, in control file:
• set ri_verify_data_stability true
• To change the length of MCP path:
• set ri_xing_mcp_cycles {num}
• Default is 2
• Generate failing VCD trace when it is possible to sample the data

at the next receiving clock edge

Data Stability Violation Example
Transmitted data is sampled in the receiving domain at the next receiving cycle;
metastability could propagate, resulting in downstream failure

Gray Code Check
• Ensure gray encoding for multi-bit control crossings

(no more than one bit transition per clock cycle)
• Generate failing VCD trace when multiple bits can

change at the same time (for example, 011 to 101)

Gray Code Violation Example
Two bits transition at the same time; not a safe CDC practice

Pulse Width Check
Data
Control
D D
Q Q
CLK1 CLK2
Pulse Width Formulation

Pulse generation logic
Clock frequency ratio

Pulse Width Check
• Check is extremely important for Fast-to-Slow crossings

Equally important for slow-to-fast crossings with feedback,
as the feedback path is a fast-to-slow crossing: Insufficient pulse width on the
feedback path may result in a situation where the acknowledgement of data
transfer is lost.
• Checks for slow-to-fast control crossings are trivially passed
• Generate failing VCD trace when the relevant clock edge does not
come within the pulse (Tx pulse must be larger than the Rx clock
cycle; equal is a failure)

Pulse Width Failure Example
The transmit control pulse is not wider than one receiving clock cycle;
could potentially be missed at the receiving clock domain

Glitch Check
Data
Control
CLK1 CLK2
Error sources:
Bad combinational logic in control path
Bad combinational logic on feedback path
Post-synthesis glitch potential that creates an uncontrolled path
Structural analysis reveals glitch potential; formal analysis finds true glitch situation:
Logic values that cause the generation, propagation, and capture of glitches

Glitch Check
• Ensure control crossings cannot glitch
• Checks are done for W_GLITCH
• Generate failing VCD trace when a glitch is possible

• Two signals changing in the opposite direction
• VCD trace does not show the actual glitch

Formal Glitch Violation Example
Both signals change at the same time, potentially creating a timing glitch;
the glitch can potentially be sampled in the receiving clock domain

Vacuity Checks
• Vacuity is verifying the transmit signals actually toggle

• If transmit signals do not toggle, the check at hand
passes; however, such a pass is really a false pass
because nothing was actually checked on the receive
side
• Vacuity status has its own column next to the
FormalStatus column

Formal Statuses

Running Formal
• Not “push-button”: Different modes and strategies for

maximizing formal results
• Clock segmentation and normalization play a large
factor in run time/complexity
• Additional ENV constraints may be required
• SVA (for SV) or PSL (for VHDL) may be needed
• Pulse Width, Glitch, & Gray Code are generally ‘easy’,
but Data Stability is often ‘difficult’
• Start small!
• Formal Analysis application note available
Thank You!

Meridian CDC.A Training

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Meridian CDC.A Training

Uploaded by

Copyright:

Available Formats

Meridian CDC 2016.

©Copyright 2016 Real Intent Inc., Proprietary and Confidential

Accelerate RTL sign-off of electronic designs by 3X

Differentiation: Capacity, Accuracy and Debug

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 3

©Copyright 2016 Real Intent Inc., Proprietary and Confidential

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 5

 CDC bugs are a result of bad implementation, timing, and logic

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 6

Transmit Flop Receive Flop

Metastability-related failures can be intermittent and hard to find,

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 7

Without protection, the output of the

Controls Losing Correlation

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 8

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 9

Control crossing must: Data crossing needs to

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 10

 Verify Block and Full Chip

 Use structural analysis and simulation

 Ensure no CDC issues in implementation

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 11

WAIVERs to reduce NOISE Design is too BIG

Tool MISSED a Crossing INCORRECT Design Reuse

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 12

Meridian CDC Verification

Clock Issues Pulse Width Issues

Reset Issues Data Stability Issues

Structural Issues Gray Code Issues

Control, Data, & INTERFACE Glitch Issues

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 13

©Copyright 2016 Real Intent Inc., Proprietary and Confidential

Correct Refine Refines

DESIGN Intuitive Design SETUP Intuitive ENV CDC Intuitive CDC

DESIGN Analysis SETUP Analysis CDC Analysis

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 15

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 16

• Interactive mode (Tcl interface):

• Script mode (recommended):

• At PMC, use make flow

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 17

• User Guide and Reference Manuals

• meridian -help for command-line options

• Inside Meridian CDC shell

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 18

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 19

• For files containing SystemVerilog

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 20

• Same Meridian CDC interface for gate-level support

• Library needs special attention

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 21

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 22

©Copyright 2016 Real Intent Inc., Proprietary and Confidential

• Generate initial environment

©Copyright 2016 Real Intent Inc., Proprietary and Confidential 24

• Automatically Generated and Enhanced

• From existing ENV

• Define clock, reset spec

create_clock -waveform {CLK1} {wb_clk}

create_reset -interval 10 -waveform {CLK1} {wb_rst}

create_input -waveform {CLK1} {wb_data_i[31:0]}

set_constant -value 1’b0 {test_mode}

#suggested clock muxing