Questa

Questa® CDC
User Guide
Software Version 10.2b_1

July 2013
Questa® Formal-based Technology
© 1995-2013 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth
in the license agreement provided with the software, except for provisions which are contrary to
applicable mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/trademarks.
Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form

Table of Contents
Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Questa Static Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2
CDC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CDC Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Clock Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Metastability in Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Metastability in Standard RTL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CDC-FX Injected RTL Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Synchronizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Reconvergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Reconvergence Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Verifying Reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Attributes of CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
CDC Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Schemes with Potential CDC Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Complex Crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
FIFO Memory and FIFO Crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Static CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Formal CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
CDC Protocol Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Chapter 3
CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
qcdc Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Batch Mode: qcdc -c -do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
GUI Mode: qcdc cdc.db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Static CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Phase 1. Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Phase 2: Running CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Phase 3: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Dynamic CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Questa CDC User Guide, v10.2b_1 3

July 2013
Table of Contents
CDC Protocol Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

CDC-FX Metastability Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Clock Tree Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Clocks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
User-specified Clock Trees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Inferred Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Modal CDC Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Running CDC Modal Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Running Modal GUI Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Hierarchical CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Block Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Hierarchical CDC Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Variations on the Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
CDC Analysis of FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Phase 1: Compiling the FPGA Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Phase 2: Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Phase 3: Compiling a CDC Model of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Phase 4: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Chapter 4
CDC-FX Metastability Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Specifying Metastability Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Metastability Windows Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Running CDC-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Running Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Simulation Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
CDC-FX PLI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Verilog Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
VHDL Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Metastability Injector Simulation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Assertion Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Chapter 5
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
and_gate_dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
async_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
async_reset_no_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
black_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
bus_custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
bus_custom_sync_no_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
bus_dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
bus_four_latch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
bus_shift_reg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4 Questa CDC User Guide, v10.2b_1

July 2013
Table of Contents
bus_two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
bus_two_dff_phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
clock_no_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
combo_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
custom_sync_no_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
custom_sync_with_crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
fanin_different_clks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
fifo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
fifo_memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
fifo_memory_ptr_mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
fifo_ptr_no_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
forward_simple_dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
four_latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
multi_bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
multi_sync_mux_select. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
mux_lock_dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
no_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
port_constraint_mismatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
pulse_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
redundant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
series_redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
shift_reg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
simple_dmux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
single_source_reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
two_dff_phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Protocol/FX Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Standard Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
cdc_dsel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
cdc_fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
cdc_glitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
cdc_hamming_distance_one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
cdc_handshake_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
cdc_sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
cdc_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
cdc_fx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
cdc_mfx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
GUI Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
CDC Checks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

July 2013
Table of Contents
Index
Third-Party Information
End-User License Agreement

July 2013
List of Examples
Example 3-1. Hierarchical Constraints File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Example 3-2. cdc_hier.Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

July 2013
List of Figures
Figure 2-1. Clock Domains and Clock Dividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 2-2. Asynchronous Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 2-3. Metastable Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2-4. Four Metastability Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output . . . . . . . . . . . . . . . 24
Figure 2-6. Metastability Injector for a CDC Data Bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-7. Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 2-8. Synchronization Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 2-9. Severity and Promotion Attributes of Crossings. . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 2-10. FIFO Memory Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 2-11. FIFO Memory and FIFO Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 2-12. FIFO Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 2-13. CDC Checks Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 2-14. Show Simulation Firings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 2-15. Simulation Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 2-16. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 3-1. Questa CDC GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 3-2. Questa CDC Verification Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 3-3. CDC GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 3-4. Static CDC Verification Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 3-5. Formal Analysis Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 3-6. Simulation with Promoted CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 3-7. Clocks Window in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 3-8. Clock Signal Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 3-9. Clocks Window Showing Modal CDC Results . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 3-10. CDC Checks Window Showing Modal CDC Results . . . . . . . . . . . . . . . . . . . 98
Figure 3-11. Bottom-up Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 3-12. Hierarchical CDC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 3-13. -report_constraints Generates Hierarchical CDC Makefile . . . . . . . . . . . . . . . 108
Figure 3-14. Waiving a Block-level Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 3-15. Top-level CDC Analysis with CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 4-1. Setup and Hold Times for a Register Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 4-2. Metastability Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 4-3. clks_aligned Input to the cdc_fx Checker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 4-4. Metastability Window Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 4-5. CDC Data Flow for Simulation with Metastability . . . . . . . . . . . . . . . . . . . . . . 133
Figure 4-6. Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 4-7. CDC GUI with Merged CDC_FX Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Figure 5-1. Transmit Protocol Checks for Glitches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Figure 5-2. CDC Checks Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

July 2013
List of Tables
Table 1-1. Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 1-2. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 2-1. Signal Synchronization Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 2-2. Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 2-3. Signal/Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Table 2-4. Potential CDC Problem Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 2-5. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 3-1. qcdc Batch Mode Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 3-2. CDC GUI Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table 3-3. CDC Protocol Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Table 3-4. Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 3-5. Resolving Clock Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 3-6. ILMs vs. CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Table 3-7. Control File Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Table 4-1. CDC Schemes and cdc_fx Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table 5-1. CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Table 5-2. Handling Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Table 5-3. Standard Options of a Checker Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

July 2013
List of Tables

July 2013
Chapter 1
Introduction
Welcome to the Questa® Static analysis suite, a collection of functional verification solutions
from Mentor Graphics. The Questa Static analysis suite provides a complete, integrated
functional verification environment for static analysis and verification of your complex HDL
designs.
The Questa Static suite has the following functional verification solution sets:
• Questa AutoCheck, for analyzing violations of various standard design rules and
common coding practices.
• Questa Formal, for static formal analysis of SVA, PSL, OVL and QVL assertions.
• Questa CDC, for clock domain crossing analysis, CDC transfer protocol checking and
CDC-FX metastability effects injection.
These analysis environments, plus the Questa Sim simulator use a common set of front-end
utilities to compile and maintain design and resource libraries. In particular, the Questa
AutoCheck, Formal and CDC analyzers already are compatible with your simulation
environment, if you use the Questa Sim simulator. The Questa Static products analyze
synthesizable logic, so some variance with simulation is common, but this is not unlike the
restrictions for logic synthesis and design emulation.
Each analyzer comes with a GUI debugger environment for organizing, waiving and debugging
verification results. These GUI environments are tightly integrated with their verification
analysis solutions. All have a common look-and-feel, as they are based on a common set of GUI
widgets (which are also used for the Questa Sim GUI environment). In addition to tabs and
windows for organizing source data and running the analyzers, the GUIs have useful analysis
windows, such as language-oriented source code editors, schematic browsers, waveform
viewers, finite-state-machine viewers and assertion thread viewers. Since their use models are
so similar, once you are familiar with the operation of one GUI environment, you can easily
learn how to run the others.

July 2013
Introduction
Questa Static Manuals
Questa Static Manuals

The manual set for the Questa Static analysis suite has the following documents:
• Release Documents
• Questa Static Release Notes — Bugs fixed in the current release and support
information.
• Questa Static Release Highlights — New features; user-visible changes; support
information and installation notes.
• Quick Start Guides
• Questa AutoCheck Quick Start Guide — Tool flows and methodology for Questa
AutoCheck; syntaxes for commands and directives; and autochecks quick reference.
• Questa Formal Quick Start Guide — Tool flows and methodology for Questa
Formal; and syntaxes for commands and directives.
• Questa CDC Quick Start Guide — Tool flows and methodology for Questa CDC;
syntaxes for commands and directives; and CDC schemes quick reference.
• References
• Questa Static Command Reference — Data sheets for the Questa Static Tcl
commands and the top-level shell commands.
• Questa Static Quick Reference — Syntaxes of Tcl and shell commands for all
Questa Static analyzers.
• Questa Static Messages — Quick reference for messages issued by the Questa Static
analyzers.
• Questa Formal Assertions Quick Reference — Quick reference for OVL and QVL
checker libraries; and SVA coding style examples.
• User Guides
• Questa AutoCheck User Guide — Basics and tool flow for AutoCheck operation;
autochecks reference; and GUI reference.
• Questa Formal User Guide — Basics and tool flow for formal analysis and
assertion debug; and GUI reference.
• Questa CDC User Guide — Basics and tool flow for static CDC analysis, dynamic
CDC analysis and simulation with CDC-FX metastability injection; CDC schemes
reference; and GUI reference.

July 2013
Introduction
Notational Conventions
• Tutorials
• Questa Formal Tutorial User Guide — Formal analysis tutorials.
• Questa CDC Tutorial User Guide — Static and dynamic CDC analysis tutorials.
The Questa Static analyzer manuals use the notational conventions illustrated in Table 1-1.
Table 1-1. Notational Conventions

Notation Description Example
italics In syntax statements: oblique font [-depth cycles]
indicates a variable.
In text: oblique font indicates: • Specify the black box
(1) variable as module.
(2) code excerpt • Both tx_sig1 and
(3) term being defined tx_sig2 converge at
rx_sig.
• A port constraint is a
restriction on the
clock domains of
signals...
<italics in angle brackets> Italics in angle brackets are used in Specify the
text to distinguish variables from reconvergence depth: -
literals when necessary to reduce depth <cycles>.
confusion.
<angle brackets> Angle brackets are used in cdc report scheme
alphanumeric messages from the <scheme>
software to indicate variables.
italics underline Oblique underline font in text See the Questa Sim User
indicates the name of another Guide for details of the
document. vlog command.

July 2013
Introduction
This manual uses the conventions illustrated in Table 1-2 for syntax statements.
Table 1-2. Syntax Conventions

Meta-symbol Description Example
... Ellipses indicate a repeatable entry. –values value. . .
=> –values ‘b00 ‘b10 ‘b01
[ ] Square brackets indicate an optional [–module module_pattern]
entry.
{ } Regular braces indicate a required {-set signal value}...
entry (often used with or-bars or => –set sig1 3 –set sig2 4 –set sig5 2
ellipses).
| Or-bars separate choices in [ ] and { } {violation | caution | evaluation}
entries. => violation
_pattern An argument variable with a _pattern netlist constant var_pattern constant
suffix accepts wildcards. => netlist constant mode* 0
{} Bold braces are literals to be typed as –prefix_modules {module…}
they appear. => –prefix_modules {A B C D}
The following replaceable variables in directive syntax statements represent the shown object
types.
signal Single-bit register or wire.

clock_group Explicit name of a clock group (defined with netlist clock
-group <name>) or derived name of a clock group (i.e., a
“root” clock of a clock group specified with netlist clock).
variable Expression that can change value at any time.
constant Expression that evaluates to a statically constant value.
“string” String enclosed in double-quotes.
When specifying a directive from a directive syntax statement, substitute for each meta-variable
an HDL identifier, or an expression enclosed in parentheses, that evaluates to an object of the
corresponding type.

July 2013
Introduction
Online Help
Online Help
Questa Static analyzers have several ways of getting online help:
• Shell command help

Type -help with any shell command for the syntax of that command. For example:
prompt> qcdc -help
Usage: qcdc\
[[-do <script-file>] | [-do "<commands>"]] \
[-od <output-directory>] \
[-l <log-file-name>]
[-db <db-name>]
[-id <CDC_id>]
• Tcl command help

The help Tcl command shows the syntaxes for the Questa Static Tcl commands. This
command lists the Tcl commands relevant to the top-level analyzer command. For
example:
prompt> qcdc -c -do “help”
. . .
# Type help <command> to get information on that command, or try
# one of the following:
# commands All commands and topics
# executables Executable commands
# directives Run session control directives
# settings Run session settings commands
# tcl Tcl commands
prompt> qcdc -c -do “help settings”

. . .
# settings commands:
# clear settings configure license queue
# configure output directory configure simulator
# onerror
# Type help <command-name> for more details
prompt> qcdc -c -do “help configure output directory”

. . .
# Specify run output directory
# Usage: configure output directory <output-dir>

July 2013
Introduction
Online Help
• Hover help
When using the GUIs, placing the cursor over certain items displays pop-up text boxes
called “hover help”. This pop-up information helps you understand the GUI. For
example, hovering over an icon displays a description of the function performed by the
icon (such as zoom in and trace fanin to register or primary port).
Other types of hover help include hovering over a status flag to see the meaning of that
status and hovering over a warning message to see the full details of the message.
• Keyboard Shortcuts
When running a Questa Static analyzer GUI, select a particular window and type Ctrl-/
to display a popup frame showing the keyboard shortcuts applicable to that window.
Ctrl - /
displays
keyboard
shortcuts

July 2013
Introduction
Online Help
• InfoHub
The Questa Static documents are available in HTML and PDF forms from the Questa
Static InfoHub. Use a web browser to open the InfoHub top page:
install_dir/share/doc/infohubs/index.html
1 Scopes
InfoHub
2
Help
3 Search
The side panel (1) selects the groups of documents (scopes) to display in the main
window. The Release Information scope shows the Release Notes and Release
Highlights. The Questa Static scope has the rest of the Questa Static documents. The
InfoHub Help quick link (2) shows how to use Mentor Graphics InfoHub viewers. Use
the Search field (3) to enter search keywords for quick lookup of various topics.

July 2013
Introduction
Mentor Graphics Support
Mentor Graphics Support

Mentor Graphics software support includes software enhancements, technical support, access to
comprehensive online services with SupportNet, and the optional On-Site Mentoring service.
For details, see:
http://www.mentor.com/supportnet/options
If you have questions about this software release, please log in to SupportNet. You may search
thousands of technical solutions, view documentation, or open a Service Request online at:
http://www.mentor.com/supportnet
If your site is under current support and you do not have a SupportNet login, you may easily
register for SupportNet by filling out the short form at:
http://www.mentor.com/supportnet/quickaccess/SelfReg.do
All customer support contact information can be found on our web site at:
http://www.mentor.com/supportnet/support_offices.html

July 2013
Chapter 2
CDC Basics
Most complex designs have more than one clock. Many of these clocks are asynchronous. For
these designs, the logic clocked by each asynchronous clock forms the clock domain for the
clock. Logic entirely inside a clock domain can be verified with the same approach as that for a
single-clock design. However, problems arise from signals that connect logic in different clock
domains. Signals that cross clock domain “boundaries” must be properly synchronized, and
they must obey all relevant transfer protocols. The process of verifying these requirements is
called clock domain crossing (CDC) analysis.
But, even properly synchronized CDC signals that obey protocol rules do not guarantee valid
functionality. If any CDC signal does not hold steady during the setup and hold time of its
receiving register, then the register can become metastable—its output can settle at random to a
value that is different from the RTL simulated value.
In effect, data values that cross clock domains can be advanced or delayed randomly relative to
RTL simulation. If the receiving logic is not specifically designed to tolerate these metastability
effects, then functional errors can occur. Unfortunately, standard simulation cannot accurately
model metastability in a design. An extension to standard functional verification is needed to
model the effects of metastability in a design. The CDC-FX product does just that; CDC-FX
runs standard simulation with metastability injected into the circuit.
This chapter describes the method of verifying CDC signals using the CDC compiler and
CDC-FX metastability injection. This method combines static CDC analysis, inference of
design intent, assertions from an assertion checker library, simulation, and CDC-FX
metastability injection for a complete CDC verification methodology.
Refer to the CDC-FX Metastability Injection Chapter starting on page 127 for additional
information.

July 2013
CDC Basics
CDC Design Issues
CDC Design Issues

CDC verification initially ensures that all appropriate CDC signals have correct synchronization
logic. But, CDC verification really addresses the larger question:
Does my CDC synchronization logic prevent data corruption across clock domains?
Even for a design that has correct synchronizers on all signals, you must consider questions
such as:
• What happens if the CDC signals are changing when the handshake signal indicates they
are stable?
• Does the gray-code logic on a multiple bit bus using 2FF synchronization have a bug?
• Does the input to a data synchronizer change in two successive clock cycles of the
receiving domain?
• What happens when multiple CDC signals are recombined and used together in the
receiving domain?
Problems such as these often do not cause simulations to fail; instead, they commonly manifest
as intermittent post-silicon failures.
To protect against these types of failures (and ensure CDC problems are addressed early in the
design process), you can use the CDC verification methodology that consists of a three-pronged
approach as follows:
• Static CDC analysis with the CDC compiler.

• Assertion-based verification with CDC protocol checkers.
• Metastability effects analysis with CDC-FX metastability injected simulation.

July 2013
CDC Basics
Clock Domains
Clock Domains
A clock domain is a section of a design that has a clock asynchronous to (or which has a
variable phase relationship to) another clock in the design. For example, suppose one clock is
derived from another clock through a clock divider. These two clocks have a constant phase
relationship; therefore, the two sections of the design that use these clocks are really part of the
same clock domain (Figure 2-1A). However, suppose two clocks have frequencies of 50 MHz
and 33 MHz. These clocks’ phase relationships change over time; therefore, they clock two
different clock domains (Figure 2-1B).
Figure 2-1. Clock Domains and Clock Dividers
clock divider clk

A B clk33
clk
clk/2 clk33
clk clk
PLL clk50
clk50
Single Clock Domain Multiple Clock Domains
If the primary inputs to a circuit include multiple clocks, then these asynchronous clocks
determine separate clock domains (Figure 2-2A). If the inputs to a circuit are asynchronous to
the circuit itself, then these asynchronous inputs are in separate clock domains (Figure 2-2B).
Clocks are the clock signals of registers and the enable signals of latches (when properly
identified).
Figure 2-2. Asynchronous Clock Domains
A clk33 B
a
clk33
b
clk50
clk50 clk clk
Asynchronous Clocks Asynchronous Inputs
Clock Groups
All the clocks that are part of the same clock domain constitute a clock group. Hence, clock
groups partition all of the clocks in the design. The clock groups identify the various clock
domains in the design.

July 2013
CDC Basics
Metastability
Metastability
A clock domain crossing (CDC) signal is a signal originating in a clock domain that crosses the
boundary into another domain (whose clock is asynchronous to the original clock) and is then
sampled by a register in that asynchronous clock domain.
When the active edge of a CDC signal’s transmit clock is too close to the active edge of the
receive register’s clock, metastability occurs if data changes within the setup/hold time. With
the TX/RX clock very close, input to the RX register changes within the setup/hold window,
which causes metastability. The register’s output settles to an unpredictable value. Metastability
can occur if the clocks are asynchronous, or if they are synchronous but have unpredictable or
drifting skews. Every type of bi-stable storage element is susceptible to metastability. Logic
subject to metastability must be designed to “tolerate” its effects.
The effects of metastability are unpredictable in hardware as the output signal can settle
randomly to 1 or 0. However, RTL simulation provides predictable results. As a result, RTL
simulation does not accurately model the hardware implementation when metastability is
present. To ensure a circuit design is immune to metastability effects, functional verification
methods must incorporate technology beyond RTL simulation.
To design circuits that tolerate the effects of metastability, you must understand: How registers
in hardware exhibit metastability and how registers function in simulation when the conditions
for metastability are present.
Metastability in Hardware
Registers can go metastable in hardware. Consider the 1-bit CDC signal s that is sampled by the
flip-flop DFF in Figure 2-3 on page 22. Since s comes from a different clock domain, its value
can change at any time with respect to the DFF clock (clk). If the value of s is not held constant
at 0 or 1 during the DFF setup and hold time, then the output (q) might assume an intermediate
voltage for an indeterminate amount of time. Then, q “settles” randomly to either 0 or 1. The
flip-flop is said to be metastable for that interval.
Figure 2-3. Metastable Flip-Flop

setup and hold time
clk
s q
DFF s
clk
q
The following mean-time-between-failure (MTBF) formula predicts how often metastability

occurs:

July 2013
CDC Basics
Metastability
1 f clk = clock frequency

MTBF = ------------------------------------
f clk × f in × t d f in = asynchronous signal frequency
t d = setup/hold window
Metastability in Standard RTL Simulation

Registers cannot go metastable in RTL simulation. RTL simulation handles single-bit registers
predictably as follows:
• If the simulated input switches value before the simulated clock edge, then the simulated
output switches value at the clock edge.
• If the simulated input switches value after the simulated clock edge, then the simulated
output does not switch value.
Therefore, for both setup time and hold time violations, two results are possible as follows:
• The hardware output value matches the value predicted by simulation.

• The hardware value differs from the value predicted by simulation.
Figure 2-4 shows the resulting four metastability scenarios. Comparing hardware with RTL
simulation behavior: When a setup time violation occurs, the hardware transition is delayed
randomly by one cycle. When a hold time violation occurs, the hardware transition is advanced
randomly by one cycle.
Note that metastability models can be generalized for multibit registers by treating them as
aggregate single-bit registers.

July 2013
CDC Basics
Metastability
Figure 2-4. Four Metastability Scenarios

cdc_s q
R
rx_clk
setup time violations hold time violations
hardware rx_clk rx_clk
matches cdc_s
cdc_s
simulation
q (sim) q (sim)
q (hw) q (hw)
Setup time violation where the output Hold time violation where the output
settles to the simulation value. The settles to the simulation value. The
hardware transition is not advanced or hardware transition is not advanced or
delayed. delayed.
hardware rx_clk rx_clk
differs from cdc_s cdc_s
simulation q (sim) q (sim)
q (hw) q (hw)
Setup time violation where the output Hold time violation where the output
settles to the complement of the settles to the complement of the
simulation value. The hardware simulation value. The hardware
transition is delayed by one cycle. transition is advanced by one cycle.
Pseudorandom Delay Insertion

A common method of modeling metastability in standard RTL simulation is to introduce
pseudorandom delays in CDC signals at the synchronizers. For example, Figure 2-5 shows a
two-register synchronizer with a MUX that selects a 3-cycle delayed value (instead of the
normal 2-cycle delayed value) in a pseudorandom manner. End-to-end functional simulation
with these types of pseudorandom delays helps to verify that the design works properly in the
presence of CDC metastability.
Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output

synchronizer
s q1 q2 q3
R1 R2 R3
clk $random()
However, this method has the following limitations:
• It is incomplete, because it only models two of the four possible metastability scenarios.
• It models metastability only across synchronized CDC signals.
• Results are difficult to predict, because metastability is introduced into the simulation at
random.

July 2013
CDC Basics
Metastability
• Synchronization violations are difficult to debug, because the offending metastability

can occur any number of cycles before the cycle in which the simulation check first fails
(and irrelevant metastability can occur along the way).
Clock Jitter
Another method of modeling CDC metastability effects in standard RTL simulation is to jitter
the clocks in simulation and see if end-to-end functional simulation still works when the clock
phase relationships change. This method is good for verifying that the design works properly in
the presence of clock jitter and clock skews. But, this method does not completely model CDC
metastability effects.

July 2013
CDC Basics
Metastability
CDC-FX Injected RTL Simulation

For metastability injected simulation, circuitry for injecting metastability on a CDC signal or
data bus is inserted between the transmitting register and the first register along the path to the
receiver. For a path without a synchronizer, this is the receiving register itself. For a path with a
synchronizer, this is the first register in the synchronizer (Figure 2-6).
Figure 2-6. Metastability Injector for a CDC Data Bus

CDC Bus without a Synchronizer CDC Bus with a Synchronizer
tx_reg rx_reg tx_reg rx_reg
reg
tx_clock rx_clock tx_clock synchronizer rx_clock
tx_reg rx_reg tx_reg rx_reg

cdc_fx cdc_fx
checker checker
reg
clocks clocks
monitor monitor
tx_clock rx_clock tx_clock synchronizer rx_clock
metastability metastability
injector injector
The ccl compiler generates the checker logic for running metastability injected simulation. To
do this, it adds metastability injection logic for each affected CDC signal or bus in the following
two parts:
• CDC clocks monitor logic

Glue logic used to extract load and timing conditions from the circuit.
• cdc_fx checker
Checkers that monitor conditions that might cause metastability on a CDC bus and
injects metastability at the receiver outputs.
The cdc_fx checkers maintain statistics and corner-case counts for the metastability and CDC
effects modeled by the transformed circuit. The cdc_fx checkers have default-off checks
(cdc_fx) that fire in cycles in which metastability might occur (for use on data buses that are
presumed to be synchronized properly).
See “CDC-FX Metastability Injection” on page 127 for additional information.

July 2013
CDC Basics
Synchronizers
Synchronizers
Designers generally assume signals are in-band, which means they have a value of either logic 0
or logic 1. Metastable signals can have values that are neither 0 or 1; therefore, they are
considered out-of-band signals. Out-of-band signals have unexpected effects and propagate
unpredictably. To handle CDC signals, designers fence in potentially metastable logic to ensure
logic beyond the fence only needs to handle in-band signals. The logic inside the fence is called
a synchronizer (see Figure 2-7).
Figure 2-7. Synchronizer

out-of-band value in-band value
cdc_d int_d sync logic
tx_clk rx_clk
Tx Clock Domain synchronizer Rx Clock Domain
Metastability manifests as variable delays in transitions of the outputs of registers driven by

CDC signals. Relative to normal simulation, transitions are randomly delayed or advanced. This
affects every CDC signal. Even if a CDC signal or data bus has a synchronizer, the output of the
synchronizer is subject to variable delays. Logic outside the fence in the receiving domain
might not interpret receive data correctly in the presence of variable delays. Such intolerance of
metastability effects can lead to functional errors in hardware, even when normal simulation
cannot detect the problem.
Designers implement various types of synchronizers as appropriate for particular situations and
design styles. Logic for each synchronizer type assumes a set of preconditions about the logic
connecting the synchronizer and about the function of the circuit during simulation. Rules for
the synchronizer’s connections can be checked during compilation before simulation. Transfer
protocols can only be checked as the circuit operates in simulation. A synchronizer type, along
with its connection rules and transfer protocol, is called a synchronization scheme as shown in
Figure 2-8.
Figure 2-8. Synchronization Scheme

glitch-free CDC signal stable no combo logic
transmit logic* for multiple cycles** in path*
cdc_d int_d sync logic
tx_clk rx_clk
Tx Clock Domain synchronizer Rx Clock Domain
* Connection rules — assumptions that can be checked statically.

** CDC transfer protocol — assumptions that must be checked with simulation or formal analysis.

July 2013
CDC Basics
Synchronizers
Most CDC implementations use one or more synchronizers from a set of popular, well-
characterized synchronization schemes. These structured synchronizers must follow well-
defined connection rules and should obey specific transfer protocols. CDC identifies clock
domains, CDC signals, and structured synchronizers; and it verifies that the structured
synchronizers follow their connection rules. Then, CDC promotes their transfer protocols to
CDC protocol checkers for use with assertion-based simulation and formal verification.
Any clock domain crossing that does not have a structured synchronizer must be synchronized
by custom logic or software. These ad hoc synchronizers prevent receive registers from
sampling CDC signal values when they are changing. Therefore, the receive register outputs can
never go metastable. For example, an ad hoc synchronizer might use custom logic to control its
receive register’s load enable signal, or software might control the loading of a circuit’s
configuration registers.
Control Signal Synchronizers

A typical 2DFF 1-bit synchronizer is shown below. In most technologies, if the first register
(R1) becomes metastable, it almost always settles to 0/1 before the second register (R2) samples
its output (q1). The 2DFF synchronizer is the most commonly used synchronizer for single-bit
CDC connections such as individual control signals. Other structured synchronizers are
available, such as the 4-latch synchronizer (similar to 2DFF) and the pulse synchronizer (2DFF
with a pulse).
Connection Rules
• Logic in cdc_s path must be glitch
Tx Clock 2DFF synchronizer Rx Clock free
Domain Domain
cdc_s int_s q • No combinational logic is allowed in
R1 R2 int_s path
rx_clk
CDC Transfer Protocol
• Transmit clock domain logic must
hold cdc_s stable for at least the
following:
period rx_clk + t setup + t hold + t max_skew
rx_clk
rx_clk
cdc_s
cdc_s
int_s
int_s
q
q

July 2013
CDC Basics
Synchronizers
Data Bus Synchronizers

2DFF synchronizers are used for CDC control signals, but not data buses. The following
synchronizers are used to synchronize multibit CDC data in various logic configurations.
Questa CDC reports all structured synchronizers. For many synchronizer types, it promotes
protocol checkers that verify the CDC transfer protocols in simulation and formal verification.
DMUX Synchronizer
Select control signal from the transmit domain (synchronized by a 2DFF synchronizer) enables
a MUX when the transmit data value is available.
dmux synchronizer CDC Transfer Protocol

• 2DFF synchronizer must obey CDC
q transfer protocol for tx_sel.
cdc_d
• Transmit clock domain logic must
Tx Clock Rx Clock hold cdc_d stable while tx_sel or
rx_sel
Domain Domain rx_sel are asserting.
tx_sel 2DFF
synchronizer
rx_clk
Asynchronous FIFO Synchronizer

Multiclock, multiaccess FIFO queues up transmitted data.
fifo synchronizer rx_addr CDC Transfer Protocol

ren
• FIFO must not overflow or
underflow.
q
• Transitions of tx_addr must have a
rx_d hamming distance of 1.
Tx Clock Rx Clock
• Interval from write to read of any
Domain rx_d_rdy Domain FIFO location must not be less than
the following:
cdc_d
async t setup + t max_propagation_time
tx_addr FIFO
wen
tx_clk rx_clk

July 2013
CDC Basics
Synchronizers
Multibit Data Synchronizer

2DFF synchronizer synchronizes each bit, but only a single transmit bit at a time should change
during any receive clock cycle.
multibit synchronizer CDC Transfer Protocol

Tx Rx
Clock Clock •
Transitions of cdc_d must have a
Domain 2DFF Domain hamming distance of 1.
synchronizer
d[0] • 2DFF synchronizers must obey the
CDC transfer protocol for each
cdc_d bit.
cdc_d 2DFF q
synchronizer
d[1]
2DFF
d[2] synchronizer
rx_clk
Custom Synchronizer
Special-purpose signal or data synchronizer designed, specified, and implemented by the user.
Tx Clock custom synchronizer Rx Clock CDC Transfer Protocol

Domain Domain • User-defined protocol.
cdc_d user-defined q
module
rx_clk
Custom synchronizers can also have clock domain crossings internal to the user-defined
module.
Tx Clock Domain Rx Clock CDC Transfer Protocol

Domain • User-defined protocol.
d user-defined q
module
tx_clk rx_clk
custom synchronizer
with internal crossing

July 2013
CDC Basics
Synchronizers
Ad Hoc Synchronizers
Questa CDC reports CDC signals without structured synchronizers and promotes appropriate
CDC protocol checkers to verify ad hoc synchronization in simulation and formal verification.
Tx ad hoc synchronizer
Rx CDC Transfer Protocol
Clock Clock •
When a changing rx_int is sampled
Domain Domain by rx_clk, rx_int must be stable in
the interval from:
cdc_d rx_int q
active_rx_clk_edge – t setup
to:
active_rx_clk_edge + t hold
rx_clk

July 2013
CDC Basics
Reconvergence
Reconvergence
Reconvergence is the utilization of separately-propagated correlated information. An example
of reconvergence is information crossing clock domain boundaries that is recombined in the
receive logic.
reconverging signals
tx_sig1 rx_sig1
tx_clk rx_clk
tx_sig2 rx_sig2
Tx Clock Domain Rx Clock Domain
The singular problem with reconvergence is:
Can you assure that all of the correlated information used at the destination is
consistent with the information that was transmitted from the source?
CDC signal values might be metastable. Even when proper synchronizers are used, they are
subject to variable delays, which might cause reconverging information to be inconsistent.
Reconvergence occurs in two ways: Local reconvergence — a single item of information

propagates and is reconstituted in the receive logic, and global reconvergence — multiple items
of information propagate and are integrated in the receive logic.
An example of local reconvergence is multibit reconvergence of a CDC data bus. Here, a data
unit splits into pieces, crosses a clock domain boundary and then recombines in the receive
logic. In the following example, a reconverged word value is used as the next state of a finite
state machine. The individual bits of the word are synchronized to the receive clock domain, but
each bit is subject to variable delays. As a result, the next_state input to the FSM can represent a
command that is not consistent with the current state.
Tx Rx
Clock d[0] Clock FSM
Domain synchronizer Domain
S2
cdc_d next_state S1
synchronizer
d[1]
synchronizer S3 S4
d[2] ?
rx_clk

July 2013
CDC Basics
Reconvergence
Another example of local reconvergence is multicycle reconvergence of a CDC signal that

contains sequential information transmitted to receive logic. Here, variable delays in the
propagated signal can disturb correlations between consecutive transitions. In the following
example, the cdc_s pulse is not propagated to the receive logic. To avoid problems with
multicycle reconvergence, either the transmit logic must not transition data too quickly or the
receive logic must tolerate the loss of information in consecutive cycles.
Tx Clock Rx Clock
Domain Domain rx_clk
cdc_s int_s q cdc_s
R1 R2 int_s
rx_clk q
An example of global reconvergence is a set of data items transmitted across a clock domain
boundary through different synchronizers that are combined in the receive clock domain.
Another example of global reconvergence is the transmission of multiple items of information
across a clock domain boundary at different times using the same synchronizer.
Global and local reconvergence problems in CDC circuits are avoided by using proper
synchronizers and good reconvergence schemes. A good implementation ensures information is
always consistent. Either variable delay data cannot be sampled in the receive domain or the
receive domain logic can recover from variable delayed values. In the following example of a
good scheme, an arbiter selects a receive data value when the corresponding asynchronous
FIFO read data value is guaranteed to be ready.
Tx Clock Rx Clock
Domain Domain
rx_0
tx_0 async FIFO rx_out
synchronizer
rx_1
tx_1 async FIFO
synchronizer rdy_0 sel
arbiter rx_rdy
rdy_1
rx_clk
A bad implementation results in unrecoverable errors in simulation or in the hardware

implementation. In the following example of a bad scheme, variable delays can cause the wrong
command to be applied to the data.
Tx Clock Rx Clock
Domain Domain
tx_cmd async FIFO rx_cmd
synchronizer apply
command
to data
tx_data async FIFO rx_data
synchronizer
rx_clk

July 2013
CDC Basics
Reconvergence
Knowing which paths are reconvergent CDC paths is important for assessing reconvergence
issues. But for many multiple-clock architectures, the number of reconvergent CDC paths can
be staggering. To help rank paths for assessment, reconvergent paths can be filtered by several
characteristics.
divergence depth reconvergence depth
synchronizer
synchronizer
synchronizer
Tx Clock Domain RX Clock Domain

single-source reconvergence paths
The reconvergence depth of a group of reconvergent CDC paths is the sequential depth from the
synchronizers to the reconvergence point. Sometimes, heuristic information about the
functional characteristics of the circuit can specify a reconvergence depth limit for problems to
occur. General reconvergent CDC paths can start anywhere in the transmit domain.
Reconvergent paths that start at different points can have reconvergence problems. However,
single-source reconvergence paths—those reconvergent paths that start from the same transmit
domain source—are characteristically vulnerable to reconvergence issues. Analogous to general
reconvergent CDC paths, each group of single-source reconvergence paths has a sequential
distance (called the divergence depth) from the single source to the synchronizers.
Reconvergence Severity
The cdc report crossing -scheme reconvergence command can be specified multiple times to set
“severities” of reconverging paths to levels that are not the same. The following schematic
shows a reconvergence crossing where Path A is assigned reconvergence severity caution and
Paths B/C are assigned reconvergence severity violation.
Caution
Path A synchronizer
Violation
Violation
Path B synchronizer
Violation
Path C synchronizer
Tx Clock Domain RX Clock Domain

July 2013
CDC Basics
Reconvergence
The reported crossing severity is the most severe one (here, violation). The severities of the
individual paths are reported as their reconvergence severities. For example:
cdc report crossing -scheme reconvergence -from shift_reg_sync \

-severity violation
generates the following report:
Violations
=================================================================
Reconvergence of synchronizers. (reconvergence)
-----------------------------------------------------------------
rx_clk : end : dout (.../single_source_reconvergence.v : 5)
(ID:reconvergence_78116)
rx_clk : start : shift_reg_sync (.../single_source_reconvergence.v : 10)
(Synchronizer ID:shift_reg_97221)
(Reconvergence Severity:Violation)
rx_clk : start : two_dff_sync (.../single_source_reconvergence.v : 9)
(Synchronizer ID:two_dff_44733)
(Reconvergence Severity:Caution)
The same process applies to cdc report crossing -scheme single_source_reconvergence. Note
that each single-source reconvergence crossing is also reported as a reconvergence crossing.
Furthermore, crossing severities for reconvergence and single-source reconvergence are
separate. The default single-source reconvergence severity is violation. So if a single-source
crossing reconvergence crossing created the above report, the single-source reconvergence
entry has:
Violations
=================================================================
Single Source Reconvergence of synchronizers.
(single_source_reconvergence)
-----------------------------------------------------------------
rx_clk : end : dout (.../single_source_reconvergence.v : 5)
(ID:single_source_reconvergence_41397)
rx_clk : start : shift_reg_sync (.../single_source_reconvergence.v : 10)
rx_clk : start : two_dff_sync (.../single_source_reconvergence.v : 9)
tx_clk : diverge : ctrl_signal (.../single_source_reconvergence.v : 8)

July 2013
CDC Basics
Reconvergence
Verifying Reconvergence
Simulation alone is not sufficient to verify that a circuit’s hardware implementation tolerates
metastability effects and will operate correctly without reconvergence issues. Normal
simulation does not model metastability robustly and completely misses behavior that can
manifest in the circuit’s hardware implementation. A multi-faceted approach to CDC
verification is necessary for a high degree of confidence that a particular reconvergence scheme
is a good one.
• Static reconvergence analysis.

Questa CDC creates static reconvergence reports showing general and single-source
reconvergence points organized by signature. These reports can uncover reconvergence
scenarios that might be overlooked.
• CDC transfer protocol checking.
Questa CDC identifies structured synchronizers and promotes their CDC transfer
protocols to CDC assertion checkers for use in simulation and formal verification.
• Metastability injected verification.
CDC-FX identifies registers that can become metastable. For each such register, Questa
CDC generates a cdc_fx checker directive for metastability injected simulation. This
checker includes metastability injection and analysis logic.
During simulation, the cdc_fx checker assumes control of the register’s output. It injects
variable delays on bits that transition when transmit and receive clocks are almost
aligned. This causes some outputs to mimic metastable behavior in simulation.
Problems are detected by end-to-end test failures. If the verification environment is
instrumented with assertions, problems also can be detected by assertion failures.

July 2013
CDC Basics
CDC Schemes
CDC Schemes
The CDC compiler analyzes the design netlist and identifies logic involving CDC signals that
matches various pattern templates. Each occurrence of logic that matches a template is called a
clock domain crossing. In general, a crossing is a logic structure that spans two or more clock
domains.
A simple clock domain crossing is a path. For example, you might have a 1-bit CDC signal sig
from clock domain A being synchronized by two in-phase D flip-flops in clock domain B. A
complex clock domain crossing is one that contains other crossings. For example, a MUX
crossing is complex. The MUX crossing itself is a logic structure that spans two clock domains.
Inside the MUX crossing is a MUX select signal structure that is a simple 2DFF crossing.
The CDC compiler identifies clock domain crossings and their synchronization logic. Classes of
crossings with the same functionality are called CDC schemes. For example, the above MUX
select signal path with its synchronization logic is a “two_dff” scheme; the parent data MUX
crossing is an instance of a “dmux” scheme.
CDC Schemes starting on page 144 have the detailed data sheets for the CDC schemes.
Attributes of CDC Schemes

Each CDC crossing detected by the CDC compiler has two attributes: severity and promotion.
You can set these attributes for individual crossings and groups of crossings with the cdc report
crossing and cdc promote crossing directives respectively. Crossings not covered by these
directives default to the severity or promotion attributes for their parent scheme. Use cdc report
scheme and cdc promote scheme to change these settings from the factory defaults (see
Figure 2-9).
Your initial CDC analysis runs are typically spent adjusting the attributes of CDC schemes to
fine-tune the CDC reporting for the target design characteristics. For example, a “combo_logic”
scheme in one part of the design might be acceptable, but it might be a serious concern in
another part of the design.

July 2013
CDC Basics
CDC Schemes
Figure 2-9. Severity and Promotion Attributes of Crossings

Crossing Severity Crossing Promotion
crossing crossing
matches a yes matches a yes

cdc report cdc promote
crossing? crossing?
use use
-severity severity -promotion attribute
no no
crossing’s scheme crossing’s scheme
matches a yes matches a yes

cdc report cdc promote
scheme? scheme?
use use
-severity severity -promotion attribute
no use scheme’s factory no use scheme’s factory

set default set default
Severity
Severity is an indicator of the seriousness of the particular logic pattern for the crossing. It also
reflects the action you are expected to take. The severity levels are:
• Violation
A violation is considered a must-fix problem. For example, an unsynchronized CDC
signal from clock domain A to clock domain B might be a concern, so you might want to
assign severity violations to all of these CDC schemes.
• Caution
A caution is considered a valid crossing, but it has an associated CDC transfer protocol
that should be verified in simulation or by formal verification. Most cautions have
designated CDC protocol checkers that the CDC compiler configures automatically and
“promotes” for assertion-based verification.
• Evaluation
An evaluation is a valid CDC scheme that uses an appropriate synchronizer. The
scheme’s CDC protocol must still be checked.

July 2013
CDC Basics
CDC Schemes
• Proven
A proven scheme is a valid CDC scheme with an associated CDC transfer protocol that
formal CDC analysis has proven cannot be violated. No CDC protocol checkers for the
scheme are “promoted” for assertion-based verification.
• Waived
A waived scheme is a CDC scheme with a CDC transfer protocol that does not require
verification. CDC data for waived schemes are included in the cdc database, but no
CDC protocol checkers for the scheme are “promoted” for assertion-based verification.
Promotion
Whenever possible, CDC creates and configures one or more CDC transfer protocol assertions
for a scheme. Most synchronizers have corresponding protocol assertions. The process of
identifying a CDC scheme and creating its protocol assertion is called checker CDC assertion
promotion. Here, a CDC scheme is deemed OK from a static perspective. The compiler does not
have enough information to determine whether or not a synchronization problem will occur.
The answer depends on the operating environment of the design.
Promoted checkers can be used during simulation to monitor CDC activity and verify proper
synchronization of CDC signals. They are also used in static and dynamic formal verification.
Use the cdc promote directives to turn off CDC checker promotion for specific CDC schemes.
Signals in Unnamed Blocks

By default, CDC protocol checker (and FX checker) promotion is disabled for signals inside IF-
generate blocks (the current Questa implementation does not allow access to these block
names). But if the specified simulator is VCS (i.e. configure simulator vcs), these checkers are
promoted. However, checkers with signals in regular RTL unnamed blocks are not promoted. If
the specified simulator is NC (i.e. configure simulator nc), checkers with signals in implicit
generate blocks are not promoted.
CDC Synchronization Schemes

Most CDC scheme types refer to synchronization logic. Some schemes apply to single-bit CDC
signal synchronization, some apply to multiple-bit data bus synchronization, and some apply to
both.

July 2013
CDC Basics
CDC Schemes
Signals
Signal synchronization schemes identify single-bit CDC signals with various synchronizers. For
example, a two_dff scheme uses two in-phase D flip-flops clocked in the receive domain as a
synchronizer.
tx_sig rx_sig
DFF DFF DFF
tx_clk rx_clk
Table 2-1 shows the signal synchronization scheme types.
Table 2-1. Signal Synchronization Scheme

Default
Scheme Synchronizer Message Severity
async_reset Asynchronous reset scheme. ASYNC RESET evaluation
async_reset_no_sync —none— ASYNC RESET NO SYNC violation
dff_sync_gated_clk Two flip-flops with gated DFF GATED SYNC caution
clock.
four_latch Three or more cascaded FOUR LATCH evaluation
latches. SYNCHRONIZER
no_sync —none— MISSING violation

SYNCHRONIZER
pulse_sync Pulse. PULSE SYNC evaluation
shift_reg Shift register. SHIFT REG evaluation
two_dff Two or more in-phase flip- TWO DFF evaluation
flops. SYNCHRONIZER
two_dff_phase Two out-of-phase flip-flops. TWO DFF caution

SYNCHRONIZER
OPPOSITE POLARITY
custom_sync Single-bit custom CUSTOM evaluation
synchronizer.
custom_sync_no_sync Single-bit custom CUSTOM SYNC DOMAIN violation
synchronizer. MISMATCH
clock_no_sync —none— CLOCK DOMAIN caution

CROSSING AT CLOCK
PIN

July 2013
CDC Basics
CDC Schemes
Data
Data synchronization schemes identify multiple-bit CDC data buses with various synchronizers.
For example, a bus_two_dff scheme uses two in-phase D flip-flops clocked in the receive
domain as a synchronizer.
tx_data gray gray rx_data

encoder DFF DFF DFF decoder
tx_clk rx_clk
Such a synchronizer is typically used for single-bit signals. When used to synchronize data
buses, this synchronization scheme should only be used to synchronize data buses that are grey
coded (i.e., at most, one bit changes per clock cycle).
Table 2-2 shows the data synchronization scheme types.
Table 2-2. Data Synchronization Schemes

Default
bus_dff_sync_gated_clk Two flip-flops with gated BUS DFF GATED SYNC caution
clock.
bus_four_latch Four or more cascaded BUS SYNC evaluation
latches.
bus_shift_reg Shift register. BUS SHIFT REG evaluation
bus_two_dff Two or more in-phase flip- BUS SYNC evaluation
flops.
bus_two_dff_phase Two out-of-phase flip-flops. BUS SYNC caution
multi_bits —none— MULTIPLE BITS violation
bus_custom_sync Multi-bit custom. BUS CUSTOM evaluation
bus_custom_sync_no_s Multi-bit custom. BUS CUSTOM SYNC violation
ync DOMAIN MISMATCH

July 2013
CDC Basics
CDC Schemes
Signal/Data
Signal/data synchronization schemes identify CDC signals and data buses with various
synchronizers. For example, a “DMUX” scheme uses two in-phase D flip-flops clocked in the
receive domain to synchronize the select signal to a MUX that selects the CDC data. The CDC
data can be either a single-bit signal or a multiple-bit data bus.
tx_data MUX rx_data
tx_clk
tx_sel
DFF DFF
rx_sel
tx_clk rx_clk
Table 2-3 shows the signal/data synchronization scheme types.
Table 2-3. Signal/Data Synchronization Schemes

Default
custom_sync_with_crossing Custom. CUSTOM WITH evaluation
CROSSING
simple_dmux Simple MUX enable. SIMPLE_DMUX caution
and_gate_dmux AND-gate enable. AND_GATE_DMUX caution
forward_simple_dmux Forward simple MUX FORWARD_SIMPLE_ caution
enable. DMUX
mux_lock_dmux Mux-lock enables. MUX_LOCK_DMUX caution

dmux MUX enable. DMUX caution
handshake MUX enable with HANDSHAKE evaluation
handshaking.
fifo FIFO. FIFO evaluation
fifo_memory FIFO Memory. FIFO MEMORY caution
fifo_memory_ptr_mismatch FIFO Memory. FIFO POINTER violation
MISMATCH
fifo_ptr_no_sync FIFO Memory. MISSING FIFO violation
POINTER
SYNCHRONIZER
multi_sync_mux_select Multiple synchronizers. MULTIPLE caution
SYNCHRONIZERS AT
DMUX

July 2013
CDC Basics
CDC Schemes
Schemes with Potential CDC Problems

In addition to identifying CDC synchronization schemes, the CDC compiler identifies CDC
schemes that exhibit the potential for error. For example, combinational logic in a CDC path
could cause a valid synchronizer to malfunction.
combinational logic
tx_data rx_data
synchronizer
tx_clk rx_clk
Table 2-4 shows the potential CDC problem scheme types.
Table 2-4. Potential CDC Problem Schemes

Default
black_box Black box in fan-out of a BLACK BOX caution
synchronized signal.
combo_logic Combinational logic on a COMBO LOGIC violation
synchronization path.
fanin_different_clks Fan-in logic from multiple FANIN LOGIC FROM violation
clock domains. DIFFERENT CLOCKS
reconvergence Reconvergent CDC signals. RECONVERGENCE caution

single_source_reconvergence Reconvergent CDC signals SSR violation
from a single source.
redundant CDC signal drives multiple REDUNDANT caution
synchronizers.
port_constraint_mismatch Custom synchronizers PORT CONSTRAINT violation
connected in series. MISMATCH
series_redundant Custom synchronizers SERIES REDUNDANT caution

connected in series.

July 2013
CDC Basics
Complex Crossings
Complex Crossings
A simple crossing has logic in two domains, but the logic that crosses the clock domain
boundary is a single net (signal or bus). The two_dff and bus_two_dff schemes are classes of
simple crossings. A complex crossing also has logic in two (or more) domains, but the logic that
crosses the clock domain boundary is an amalgamation of multiple nets. Reconvergence, FIFO
synchronization and DMUX synchronization are examples of complex crossings. All complex
crossings contain separately reported simple crossings.
FIFO Memory and FIFO Crossings

A FIFO memory crossing (fifo_memory) is a crossing that looks like a FIFO crossing. It has a
dual clock memory with write clock and write address pointer on the Tx side of the crossing and
read clock and read address pointer on the Rx side of the crossing (Figure 2-10).
Figure 2-10. FIFO Memory Scheme

wr_clock
raddr
wr_data
memory
rd_data
waddr rd_clock
FIFO write clock domain FIFO read clock domain
Memories can be:
• Memory (2-D Arrays). Identified as abstract using netlist memory.

• Register/latch file. As specified by cdc fifo.
• Black box memory. As specified by cdc blackbox memory.
A crossing must satisfy the following sequence of qualifications to be classed as a fifo_memory
crossing (Figure 2-11):
1. The crossing involves a memory or a register file.

2. Memory is in the same clock domain as the write data signal to the memory. If not, a
synchronizer is missing between the Tx driver and the memory (no_sync).
3. The write address pointer must be in the same clock domain as the memory write
address input. Similarly, the read address pointer must be in the same clock domain as
the memory read address input. If not, the clock domains of the pointers and data
mismatch or cannot be detected (fifo_memory_ptr_mismatch).

July 2013
CDC Basics
Complex Crossings
Figure 2-11. FIFO Memory and FIFO Detection
Crossing with a TX as no
Memory or Register File Memory? no_sync
MISSING SYNCHRONIZER
Synchronization of Memory Data Input is
Missing
yes
R/W Addrs no
fifo_memory_ptr_mismatch
Valid?
FIFO POINTER MISMATCH
FIFO-style Memory with Mismatching
Data/Pointer Clock Domains
yes
cdc preference no
-fifo_scheme? fifo_memory
FIFO MEMORY SYNCHRONIZER
FIFO-style Memory Synchronization
yes
yes no
fifo R/W Pointers fifo_ptr_no_sync
Synced?
FIFO MISSING FIFO POINTER SYNCHRONIZER
FIFO Synchronization Synchronization of Memory Pointer Input is
Missing
For a FIFO memory crossing to be classified as a FIFO crossing (fifo), the write address pointer
must also synchronize in the Rx domain and the read address pointer must also synchronize in
the Tx domain (Figure 2-12). You can relax these requirements with the -no_write_sync and
-no_read_sync options to cdc preference fifo.
Categorizing FIFO memory crossings between FIFO crossings and FIFO memory crossings
with missing pointer synchronization (fifo_ptr_no_sync) is an unnecessary performance
degrading step in most analysis runs. Doing so is off by default. To turn FIFO detection on:
cdc preference -fifo_scheme

July 2013
CDC Basics
Complex Crossings
Figure 2-12. FIFO Scheme

read addr
synchronizer raddr
wr_clock
wr_data
memory
rd_data
rd_clock
waddr write addr
synchronizer

July 2013
CDC Basics
Static CDC Analysis
Static CDC Analysis

Static CDC analysis performs the following critical functions for CDC verification:
1. Verifies synchronizers.
Static CDC analysis examines the design RTL and uses the user-specified and inferred
clock groups to find the clock trees that determine the clock domains in the design. It
then assigns each register to a clock domain. Static CDC analysis identifies the CDC
signals by finding registers that drive registers from other clock domains and verifying
that correct synchronizers are present on all CDC signals.
2. Identifies CDC schemes.
Static CDC analysis categorizes each CDC logic pattern as one of a set of predefined
CDC schemes. For example, one scheme contains all single-bit CDC signals that are
synchronized by two-register data synchronizers. Another scheme contains all multiple-
bit CDC signals that are not synchronized. Some schemes are identified as violations.
For example, the following figure shows single-bit CDC signals with combinational
logic driving, or within, the synchronizers.
combinational logic
between DFFs
tx_sig rx_sig
DFF DFF DFF
tx_clk rx_clk

combinational logic
drives input to synchronizer
tx_sig rx_sig
DFF DFF DFF
tx_clk rx_clk
You can redefine the statuses used for the different schemes. For example, you can
make latch synchronization a violation.
3. Verifies certain CDC protocols
If CDC formal verification is enabled, static CDC analysis includes static formal
analysis of certain CDC protocols.
4. Promotes CDC protocol checkers.
Static CDC analysis generates CDC protocol checkers for certain CDC schemes based
on their scheme type, transmit clock, transmit signals, receive clock and receive signals.

July 2013
CDC Basics
Static CDC Analysis
CDC checkers are not promoted for crossings that have severity proven or waived or for
filtered crossings. Promoted checkers represent CDC protocols that need assertion-
based analysis by the Questa Formal tools and possibly simulation.
Formal CDC
Formal CDC is an advanced option of static CDC analysis that tries to verify the CDC transfer
protocols of certain CDC schemes using a built-in formal proof engine. Formal CDC analyzes
the fanin logic of these CDC schemes. If formal CDC finds a proof that a CDC scheme’s
protocol cannot be violated, that scheme is reported as a proven scheme. Since the scheme’s
synchronization is valid, no protocol checker is promoted for the scheme. If CDC formal
analysis cannot find a proof that the protocol cannot be violated, the result is inconclusive. So,
the associated protocol checker is promoted for verification by the Questa Formal tools or by
simulation. The proportion of time formal CDC spends analyzing protocols is controlled by the
formal CDC effort level:
low —> medium —> high

The default formal CDC effort level is low. Running static CDC with a higher formal effort
level can result in additional proven CDC schemes. The formal CDC engine is tuned to analyze
two specific types of CDC protocols: signal stability protocols and gray-coding protocols.
Caution
Setting formal CDC effort too high for some designs can significantly degrade
performance.
Signal Stability Protocols

Single-bit CDC signals can be synchronized by various different types of synchronizers.
However, such synchronization must follow a signal stability protocol where each new value of
a transmit signal is held stable long enough for the receiving domain to sample it at least twice.
Formal CDC tries to find proofs for the signal stability protocols by analyzing the transmit
signal pulse widths of the following types of CDC schemes:
• dff_sync_gated_clk
• four_latch
• pulse_sync
• shift_reg
• two_dff
• two_dff_phase

July 2013
CDC Basics
Static CDC Analysis
Gray-Coding Protocols
Multibit CDC signals (i.e., data buses) can be synchronized by synchronizers typically used for
single-bit signals. However, such synchronization must follow a gray-coding protocol where
only one data bit changes at a time. Formal CDC tries to find proofs for the gray-coding
protocols of the following types of CDC schemes:
• bus_dff_sync_gated_clk
• bus_four_latch
• bus_shift_reg
• bus_two_dff
• bus_two_dff_phase
• reconvergence (if enabled by cdc preference -promote_reconvergence).
CDC Protocol Checker Promotion

Assertions are specifications of design behavior. They can be checked during simulation with
assertions and they can act as targets and constraints for formal verification. The CDC transfer
protocol for a CDC synchronization scheme is an assertion. For example, consider a CDC
signal synchronized by a two-register data synchronizer. This synchronization scheme has the
following implied CDC protocol:
• The transmit signal remains stable until the synchronizer’s output register has sampled
the previous value.
This protocol can be checked with the following assertion using simulation with assertions and
formal verification:
• The transmit signal must not change for at least N consecutive transmit-clock cycles,
where N is a function of the transmit-clock and receive-clock frequencies.
If this assertion is violated, then a possible counterexample exists in which metastability on the
CDC signal can cause an incorrect result. In this case, the transmitted data is missed by the
receiver logic. In regular simulation (which is not subject to metastability unless it is a
catastrophic violation of the protocol), the signal reaches its goal and the problem is not
detected. However, when using simulation with assertions, an assertion fires. You can then
examine the conditions under which the failure occurs and correct the design problem.
Specifying Design Intent

A checker is a conglomeration of assertions and a CDC protocol checker is a special type of
checker configured to verify the CDC transfer protocol for a CDC synchronization scheme. A
CDC protocol checker’s assertions completely characterize its associated synchronization

July 2013
CDC Basics
Static CDC Analysis
scheme. If a design cannot violate any of the checker’s assertions, then the design obeys the
associated CDC synchronization scheme.
CDC protocol assertions are available for the common CDC synchronization schemes. Static
CDC analysis identifies the synchronization schemes used for the CDC signals in the design.
Based on this analysis, CDC promotes instances of CDC protocol assertions depending on the
synchronization scheme (although not all schemes have associated promoted assertions). The
promoted checkers validate CDC behavior during assertion-based verification.
See the cdc_checker.rpt for the promoted protocol assertions.
Path and Protocol ID

Each CDC path has a unique path ID—derived from the path parameters—that remains the
same across multiple tool runs. Each CDC check is associated with the unique ID, which is also
used to name the associated promoted protocol checker. This path and protocol ID associates
the CDC checkers in simulation to their corresponding checks in the CDC report, which
simplifies the correlation of the static and protocol checking results. For example:
• cdc.rpt
Multiple-bit signal across clock domain boundary. (multi_bits)
---------------------------------------------------------------
cpu_clk : start : crc_seed[7:1] (/CDC/SRC/demo_top.vhd : 84)
mac_clk : end : crc_1.crc_16 (/CDC/SRC/demo_top.vhd : 565)
(ID:multi_bits_76265)via : crc_1.seed
• cdc_checker.rpt (promoted checker file)

Type/Name : cdc_dsel demo_top.dmux_12402
Checkerware Instance : cdc_demo_top_31c26a68_demo_top_inst_0.U0.U10
Description : Ensures that a signal between two clock
domains, where the transmitter’s data select signal drives the
select input of a data multiplexor in the receiver, is held
stable enough for the signal to be sampled reliably by the
receiver and ensures that the data remains stable while the
data select signal asserts.
Message : <None>
Location : File /home/.../demo_top.v, Line 336
Directive : cdc_dsel
-tx_data tx_mask_d
-tx_clock core_clk_in
-tx_data_select tx_mask_valid
-rx_data mask
-rx_clock mac_clk_in
-tx_min 1
-areset ( ! rst)
-reference dmux_12402
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
Check rx_data_stable : On <Default On>

July 2013
CDC Basics
Simulation
Check tx_data_stable : On <Default On>

Check tx_min : On <Default On>
-tx_data : tx_mask_d
-rx_data : mask
-tx_data_select : tx_mask_valid
-tx_clock : core_clk_in
-tx_reset : 1’b0
-rx_clock : mac_clk_in
-rx_reset : 1’b0
-areset : ( ! rst)
-active : 1’b1
-support : 1’b0
-nv : 1’b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal
• The CDC Checks window of the qcdc viewer.

• The Detail window of the qcdc viewer.
Simulation
To simulate a design with CDC checkers, use assertions in simulation and your standard HDL
simulator. During assertions in simulation, the CDC checkers verify the functionality of the
CDC protocols. A violation of a protocol assertion makes the associated CDC checker fire.
To debug assertion firings, use the qcdc viewer. Use the File >Open >Database command to
load the database from the simulation (cdc_sim.db). A new window, Simulation contains the
simulation results and the CDC Checks window, has two new columns with the simulation
results (Figure 2-13).
Figure 2-13. CDC Checks Simulation Results
To invoke the waveform viewer with the assertion firing from simulation (Figure 2-14) right
click on the Firing in the Transcript window and select Show Firings to display the Firings
window. Select all firings or an individual firing to show the waveform.

July 2013
CDC Basics
Simulation
Figure 2-14. Show Simulation Firings
View the coverage statistics for the simulation from the Design window (Figure 2-15).

July 2013
CDC Basics
Simulation
Figure 2-15. Simulation Coverage

July 2013
CDC Basics
Status Flags
Status Flags
Status flags give you a quick assessment of the results of CDC verification from the CDC GUI.
The flags help you determine which CDC issues to examine first and they highlight additional
problems you should investigate. Figure 2-16 shows a region of a CDC checks tab in the results
pane of the CDC GUI after a CDC verification session, formal verification and simulation with
the promoted CDC checkers. Entries can have Static status, Prove status and Simulation status
as described in Table 2-5.
Figure 2-16. CDC Checks Status Flags
status flags in CDC Checks window
Table 2-5. CDC Checks Status Flags

Flag Description Static Prove Sim
Violation
Crossing’s severity level is violation.
Firing
Crossing’s protocol is violated in simulation.
Proven
Crossing’s protocol cannot be violated.
Evaluation
Crossing’s severity level is evaluation.
Covered
Crossing’s protocol checker’s cover points are covered in
simulation.
Caution
Crossing’s severity level is caution.

July 2013
CDC Basics
Status Flags
Table 2-5. CDC Checks Status Flags (cont.)

Flag Description Static Prove Sim
Inconclusive
Crossing’s protocol is not guaranteed. Formal analysis could
not prove that the protocol cannot be violated.
Evaluated
Crossing’s protocol checker is evaluated in simulation.
Not Promoted
Crossing has no protocol checker automatically generated or
the protocol checker is not promoted because the protocol is
proven valid during static CDC analysis.
Waived
Crossing’s severity level is waived.
Filtered
Crossing is not analyzed because it is marked stable with cdc
signal. These crossings are reported only if filtered reporting is
enabled (with cdc preference -filtered_report).

July 2013
CDC Basics
Status Flags

July 2013
Chapter 3
CDC Analysis
Questa CDC is a static analysis system comprised of a clock model compiler, a CDC analysis
engine and a GUI debug environment (Figure 3-1). These functions run under the analyzer
command qcdc. The CDC analysis flow consists of running qcdc in two phases in different
modes:
1. qcdc in batch mode

Compiles a clock model of the design; runs CDC static analysis and generates a
database file (cdc.db) containing the results. Static CDC analysis infers clock trees,
identifies CDC signals and detects synchronization patterns.
2. qcdc in GUI mode
Displays the CDC GUI with the results from cdc.db. This GUI has design data analysis
windows and CDC verification tools—source code editor, schematics browser and
waveform viewer—for debugging issues found by the analyzer.
This chapter gives a brief description of the qcdc batch command and GUI; and shows the CDC
verification flow.
Figure 3-1. Questa CDC GUI

July 2013
CDC Analysis
qcdc Command
qcdc Command
As shown in Figure 3-2, the Questa Formal verification flow starts with a compiled design
library (see the Compiler Commands chapter of the Questa Static Command Reference). The
analysis portion of the flow has two phases. Each phase runs the qformal command in a
different mode: batch mode and GUI mode.
Figure 3-2. Questa CDC Verification Flow
Compile design libraries

Questa Compilers
design
and Library
files
Management Tools
design libraries
clock model Run CDC analysis

Tcl files qcdc -c -do
cdc.db Batch Mode
CDC Debug
Debug CDC results
qcdc cdc.db Source Code Editor
Schematics Browser
GUI Waveform Viewer
GUI Mode
Batch Mode: qcdc -c -do

With a compiled design, the first phase of CDC analysis is to run the analyzer in batch mode
(Table 3-1).
Table 3-1. qcdc Batch Mode Syntax

qcdc –c –do {do_file | “commands”} [–od output_directory] [–l log_file] [-licq]
–c Run a batch session.

–do {do_file | “commands”} Execute the specified Tcl DO script.
–od output_directory Path name of the initial output directory for the analyzer
session.
–l log_file Name of the top-level session log.
-licq Enable license queueing for the top-level session.
The analyzer executes Tcl commands in the DO file procedurally. The DO script can include
exotic procedural features such as looping and variable substitution and it can perform several
CDC analysis runs in the same session. But a basic qcdc DO file flow has five steps (see the Tcl
Commands chapter of the Questa Static Command Reference).

July 2013
CDC Analysis
qcdc Command
1. Add directives
Use the general-purpose and cdc directives to configure the analysis run.
2. Adjust settings
Use the configure command to change basic settings for subsequent commands.
3. Run CDC analysis
Use the cdc run command to initiate a formal analysis run.
4. Run post-session analysis
Use the cdc utilities to generate reports and related files.
Steps 1 – 3 must be part of the same qcdc session. Step 4 is optional.
GUI Mode: qcdc cdc.db

Running qcdc with the .db file generated from batch mode (Step 3) provides a GUI debug
environment for viewing and debugging CDC analysis results (Figure 3-3).
prompt> qcdc cdc.db
Figure 3-3. CDC GUI

Menus Toolbar Debugging Windows
Design Data
Windows
Results
Windows
The GUI shows formal analysis results in various windows and GUI tools (Table 3-2).

July 2013
CDC Analysis
qcdc Command
Table 3-2. CDC GUI Debug Tools

CDC Policy Checks Window
Shows CDC compilation errors, warnings and infos.

CDC Setup Checks Window
Shows information about the compiled design and its clock domain model.
CDC Checks Window
Shows the results of CDC analysis. Each CDC scheme instance has a status
flag that indicates the status for the CDC instance (see “Status Flags” on
page 54). Right-click on a scheme instance to pop up commands for
displaying various debug windows for inspecting the crossing. Also shows
results merged from simulation and formal verification sessions.

July 2013
CDC Analysis
qcdc Command
Table 3-2. CDC GUI Debug Tools (cont.)

Schematics Viewer
Shows hierarchical schematics for the design. To display the schematics

viewer showing the logic of a CDC instance, right-click on the CDC
instance and run a Show >Schematic command.
Source Code Editor
Provides a dynamic view of the design source code for browsing. Code is
tightly linked to the GUI objects, which helps navigate the source code. For
example, right-click on various window objects to show in a source code
editor: an object’s declaration, an object’s instantiation, an erroneous
construct flagged in the source code, and other types of constructs flagged
in the source code. The source code editor is also linked to the waveform
viewer. As you move the main cursor in the waveform window, the
associated values from the waveform are annotated to the variables in the
source code.

July 2013
CDC Analysis
qcdc Command
Table 3-2. CDC GUI Debug Tools (cont.)

Waveform Viewer
Shows waveforms found by simulation with CDC protocol assertions and

CDC-FX metastability checkers. Only available for databases merged from
simulation sessions. To display a waveform, right-click on a CDC instance
and run Show >Simulation Firings.

July 2013
CDC Analysis
Static CDC Verification Flow

Static CDC verification of a DUT is a 3-phased flow (Figure 3-4):
1. Compile the design.

2. Run CDC analysis.
3. Run GUI debug.
Figure 3-4. Static CDC Verification Flow
Phase 1 vlog/vcom Compile the design data
Phase 2 qcdc -c -do Run analysis session
Phase 3 qcdc cdc.db Run debug session
Static CDC verification identifies the CDC signal paths (crossings) and their associated CDC
schemes. Crossings are ranked by severity, which are set by the cdc report crossing directive, or
default to the severity for the scheme. Typically, several cycles are spent adjusting the scheme
identification attributes and protocol promotion settings. Once you have properly configured
static CDC verification, you can enable the formal CDC analysis engine.
Tip: The following procedure uses the interactive OS shell to run the top-level
commands. This method makes it easier to illustrate the various steps in the procedure.
Typically, a Makefile, or other session management script is used instead. For examples
of the Makefile method of scripting analysis sessions, see the AutoCheck examples in
<install_dir>/share/examples.

July 2013
CDC Analysis
Phase 1. Compiling the Design

Use the compilation utilities to set up, compile and maintain the design libraries (see the
Compiler Commands chapter of the Questa Static Command Reference):
1. Start from a working directory for the project.

For example:
prompt> cd /u/design/cdc
2. Create a working library.

prompt> vlib work
3. Name the working library.

prompt> vmap work work
Copying /u/qstatic10.1/modeltech/../modelsim.ini to modelsim.ini
Modifying modelsim.ini
Note that a copy of the system modelsim.ini file is copied to the run directory and the
local copy is modified to match the arguments of the vmap command.
4. Compile the design files.
Use vcom to compile the VHDL files and vlog to compile the Verilog/SystemVerilog
files. For example:
prompt> vcom -f pci.f
prompt> vlog dut.v
Check the warnings/errors messages and resolve any problems. To see more information
about a message use the verror command.
prompt> verror -full 2155
MSG_IDX_GLBL_VARS_IN_VERILOG
Global declarations are illegal in Verilog 2001 syntax.
Global declarations are only legal in SystemVerilog. To enable

SystemVerilog you can either use the -sv vlog command line switch
or give the source file a .sv extension.
Phase 2: Running CDC Analysis

You run CDC analysis by running qcdc in batch mode (i.e., with the -c -do options). In batch
mode, qcdc runs the DO script specified by the -do argument. A DO script is a Tcl program that
recognizes the Questa Static extension to the standard Tcl commands (see the Questa Static
Command Reference).
The qcdc command uses a Tcl interpreter internally. For example, you can run simple Tcl
snippets with qcdc:

July 2013
CDC Analysis
prompt> qcdc -c -do “exec date”

# Questa Static Verification System
# Version 10.1x linux_x86_64 2012
. . .
# Thu Apr 26 15:31:32 PDT 2012
Although the complete versatility of the Tcl scripting language is available, you need not be
well versed in Tcl to set up and run analysis sessions. The basic flows (and the flows shown in
this manual) are simple sequential scripts with no looping or branching.
The basic analysis session orchestrated by a typical qcdc DO script follows the steps shown in
Figure 3-5.
Figure 3-5. Formal Analysis Session
add directives
adjust settings
run cdc run
1. Add directives.
Directives are Questa Static Tcl commands that configure the subsequent analysis
session. One method groups these commands in a separate DO file:
prompt> cat cdc_directives.do
# Define clocks
netlist clock cpu_clk_in -period 50
netlist clock core_clk_in -period 60
netlist clock mac_clk_in -period 50
# Define constants
netlist constant scan_mode 1’b0
# Add CDC constraints
cdc reconvergence -depth 1 -divergence_depth 1
cdc preference -fifo_scheme -handshake_scheme
netlist blackbox pci_ctrl
Following are some example directive commands:

• netlist clock — Identify clocks’ characteristics (including which clocks belong to the
same clock groups).
• netlist port domain — Override the default clock groups assigned to DUT or
instance ports.
• netlist blackbox — Identify modules/architectures that should be treated as “black
boxes” for CDC analysis.

July 2013
CDC Analysis
• netlist constant — Identify signals that should be considered constant for CDC
analysis.
• netlist memory — Identify large memories that are modeled as single sequential
elements for CDC analysis.
• cdc preference — Set the preferences for static CDC analysis.
• cdc report scheme and cdc report crossing — Set severities for CDC crossings and
schemes.
• cdc promote crossing and cdc promote scheme — Set promotion attributes for CDC
crossings and schemes.
• cdc signal — Override the classification of various signals and assign them certain
CDC properties.
2. Create the top-level DO script.
The script should run the directives, adjust the settings and execute cdc run, which
performs formal analysis.
prompt> cat cdc.do
onerror {exit 1}
do cdc_directives.do
configure error -inferred black_box
cdc run -d dut -report_clock
### cdc run -d dut
exit 0
Notice the Questa Static onerror command. This command configures the session to exit
when one of the Tcl commands encounters an error. For example, you want the session
to end before running a long analysis session whenever a typo or other error occurs
when running a directive. The last exit command is for future functionality, when a
command line interpreter (CLI) is added. It prevents the session from dropping into the
CLI at the end of a successful session.
The do cdc_directives.do command runs the directives script created in step 1 (as if it
were inline). The configure error -inferred black_box command adjusts the error
condition by returning an error whenever clock model compilation processes an inferred
black box (i.e., one without a netlist blackbox directive).
The cdc run -d dut executable runs static CDC analysis. For the initial passes, the
complete CDC analysis run is short-circuited by the -report_clock option. This CDC
analysis run type scans the design data, reports clock domain information and exits
without performing complete CDC analysis.
3. Run a batch CDC session in report clocks mode.
prompt> qcdc -c -do cdc.do -od cdc_results
The -od cdc_results option sets the initial output directory to cdc_results.

July 2013
CDC Analysis
A report clocks run is a short session that lets you adjust clock definitions before
committing to a full CDC analysis run.
4. Check for errors and warnings.
Check the log file (cdc_run.log) for errors and warnings. The Error/Warning Summary
table gives the violation count of each type of error/warning.
Error/Warning Summary
-----------------------------------------------------------
Count Type Message ID Summary
-----------------------------------------------------------
1 Warning hdl-222 Possible dead end CDC paths not reported.
2 Warning hdl-41 Primary port connects to multiple clock domains.
19 Warning hdl-51 Port domain assignment inferred.
1 Warning netlist-82 Found internal reset signals.
Summary: 23 Warnings in cdc
The detailed error/warning messages are in the body of the log.

prompt> egrep “Error|Warning” cdc_run.log
Warning : Possible dead end CDC paths not reported. [hdl-222]
Warning : Found internal reset signals. [netlist-82]
Warning : Port domain assignment inferred....[hdl-51]
Warning : Port domain assignment inferred....[hdl-51]
. . .
Warning : Primary port connects to multiple clock domains...[hdl-41]
Warning : Primary port connects to multiple clock domains...[hdl-41]
5. Check clock domain data.

Check cdc.rpt. This report shows information reported by cdc -report_clock such as
identified clocks, clock groups and port domain mappings. CDC static analysis resource
requirements increase with the number of CDC signals identified in the design.
Unconfigured CDC analysis can identify more CDC signals than the design actually has
(for example because automatic clock grouping identifies more than the actual number
of clock domains).
Review and refine the clock trees to achieve the correct grouping. Adjust and add
directives, then rerun steps 4 and 5. The following clock data should be accurate before
advancing to step 6:
• Clocks are identified correctly — clocks not needed for CDC analysis can be
removed from the clock list.
• Clock groups are identified correctly — clocks can be added and removed from the
different clock groups.
• Ports are assigned to the correct clock domains — clock domains of DUT ports are
inferred, but you can override these assignments. Clock domains of black box
outputs must be identified.
• CDC signals are classified correctly — the type of each CDC signal is inferred, but
you can override these assignments. The CDC signal classification determines

July 2013
CDC Analysis
which synchronization schemes are valid for the signals. For example, a data bus can
use a control signal synchronization scheme if it is grey-coded and a CDC signal that
is known to be stable does not require synchronization.
• Custom synchronizers must be manually identified so CDC analysis can ignore the
signals synchronized by them.
6. Change the DO script to run full CDC analysis.
Once the design is compiled and the clock domains are verified, adjust the CDC session
DO script:
prompt> cat cdc.do
onerror {exit 1}
### cdc run -d dut -report_clock
cdc run -d dut
exit 0
Instead of running the shortened report clocks session, the script now runs full CDC
analysis. This command also generates the database (cdc.db) file read by qcdc in GUI
mode.
7. Run a full CDC analysis session.

Check the log file (cdc_run.log) for errors and warnings.
Phase 3: Running GUI Debug

Use the CDC GUI to analyze the results of CDC analysis.
1. Run qcdc in GUI mode.

Load the database generated by the autocheck analysis session:
prompt> qcdc cdc_results/cdc.db
2. Check static CDC analysis results.

The CDC checks window shows the static CDC analysis results. Each entry represents a
CDC path (i.e., crossing) detected by CDC static analysis. The Type field has a CDC
status flag (see “Status Flags” on page 54) representing the status of the crossing. To
help organize the data, crossings are grouped by basic type (Violation, Caution,
Evaluation, Proven, etc.) and within each of these status groups, the crossings are
grouped by scheme (Two DFF Synchronizer, Combo Logic, etc.).

July 2013
CDC Analysis
For a static CDC session, the basic statuses are:

• Violation
The crossing is not an instance of valid CDC scheme. To remove this violation,
either the logic must be changed or the violation must be waived (for example, when
the CDC circuit is known to be valid).
• Caution
The crossing is an instance of a CDC scheme that might or might not be valid. The
CDC interface protocol can possibly be violated. A protocol checker should be used
to check the interface logic. If the scheme type promotes protocol checkers, one is
automatically created (unless promotion is specifically turned off for the crossing).
• Evaluation
The crossing is an instance of a valid scheme for the CDC signal.
• Proven
The crossing is an instance of a valid scheme for the CDC signal and the CDC
interface protocol cannot be violated.
Static CDC verification results can show proven crossings even when the CDC formal
engine is not enabled. For example, for crossings with clock ratios (TX/RX clock
periods) is < 2 (i.e., the path goes from a domain with a slow clock to one with a fast
clock).
3. Fix violations.
Carefully examine the violations. To debug a violation, view the schematic (select the
crossing and run Show >Schematic) and view the source code for the violation (run
Show >Source). You must rerun a complete static CDC verification flow—including
design compilation—if you change the HDL source.

July 2013
CDC Analysis
4. Adjust static CDC analysis directives as needed.

You typically need to adjust the CDC directives, for example to do the following:
• Change the severity of a crossing, For example, you might want to change all
no_sync crossings into the clk_bo clock domain from violation to evaluation by
adding the following directive:
cdc report crossing -severity violation -scheme no_sync \
-rx_clock clk_bo -message “Crossings to clk_bo are sync’d”
• Mark certain signals used in crossings as stable, so no synchronizer is needed.

cdc signal data* -stable -module myak
• Identify source signals to ignore for CDC analysis.

cdc crossing off -from data* -module myak
The cdc crossing off directive turns off CDC analysis for matching crossings, which
can improve performance. The cdc report crossing directives affect the way results
are grouped, but CDC analysis is still performed on these crossings.
Be sure to re-run the CDC session after each change to the directives.
5. Filter (waive) some static CDC results.
Waiving is the process of filtering selected CDC crossings, that is, identifying them as
OK—at least for the time being. Waived crossings are still analyzed—but they are not
displayed as part of the regular results (violation, caution, evaluation, proven). They are
grouped together in the special waived group.

July 2013
CDC Analysis
To waive crossings: select an individual CDC crossing or group of CDC crossings.

Running a Filter >Selected popup command displays the Filter CDC Checks dialog.
This dialog appears with the currently-filtered items along with the specified CDC
crossing or group. Which specified crossing or group, is determined by the selection and
the particular Filter command used.
Adjust the crossings selected for filtering using this form. Select a filter entry and click
on Modify. You can adjust waiver arguments from the Modify Filter dialog.
To “un-filter” a crossing entry, select any result and run Filter >By Column, which
displays the Filter CDC Checks dialog again. Select the crossing you want to restore and
then use the Delete (or Modify) button.
6. Create waivers.
Waivers are cdc report directives with -severity waived arguments. You can create
waivers from the GUI and save them to a directives file for use with subsequent CDC
analysis sessions. While you waive a crossing or group of crossings (Step 5), you can
generate a corresponding waiver by running the Create Directive command from the
Modify Filter dialog.
Create a waiver directive

July 2013
CDC Analysis
When you OK the dialog, the waiver directive is added to the Directives window.
Waiver directive added
After adding the waivers, save the file: File >Export >Directive File and add this file to
the session run script:
prompt> cat cdc.do
onerror {exit 1}
do cdc_waivers.do
cdc run -d dut
exit 0
Keeping different versions of waiver files helps you organize CDC issues. You can
“filter” out extraneous information as you focus on particular hot spots in your CDC
analysis. Filtering can be a valuable tool for implementing targeting strategies in your
CDC analysis methodology.
7. Add formal protocol assertion verification to the DO script.
prompt> cat cdc.do
onerror {exit 1}
do cdc_waivers.do
cdc run -d dut -formal
exit 0
The -formal option to cdc run turns on this capability. This is a low-level formal
analysis, but it can identify simple proofs of certain promoted CDC protocol assertions.

July 2013
CDC Analysis
8. Re-run CDC analysis.

Check static CDC analysis results.

prompt> qcdc cdc_results/cdc.db
Results are shown in the CDC Checks window. At this point problems should be fixed,
but some violations might still be flagged. For example, a scheme might have severity
violation, but its CDC transfer protocol is expected to be valid.
Since some schemes are marked with waived severity, the Type field has a new group of
entries:
• Waived — The scheme’s severity is manually set to waived.
Schemes with protocols that formal CDC proves are valid are shown with proven status
(formal CDC does not analyze protocols of waived schemes).
9. Create additional CDC attribute profiles to address specific issues.
The default tuning of the CDC attributes provides a balance between performance and
the effort spent to provide a high level of detail. You can adjust the exact balance by
specifying a CDC attribute profile targeted to specific needs. For example, the following
directives file creates a profile that has the minimum compute time and memory
consumption. This profile is useful for very large designs, especially when working
iteratively to fine-tune results at early stages of verification.
# high_performance.do -- High-performance CDC profile
# Turn off reconvergence checking.

cdc reconvergence -check off
# Turn off exact memory modeling for large memories.

netlist memory -abstract mem1 mem2
# Disable generation of CDC protocol assertions

July 2013
CDC Analysis
cdc promote scheme * -off
# Define custom synchronizer modules and identify the clock domains

# of the custom synchronizer module pins.
cdc synchronizer custom cust_2sync
netlist port domain in1 out2 -clock clk1 -module cust_2sync
netlist port domain in2 out1 -clock clk2 -module cust_2sync
# Black box modules that are not required for CDC analysis
netlist blackbox modX
For extremely large designs, use a hierarchical CDC verification flow (see “Hierarchical
CDC Analysis” on page 100).
The following example directives file creates a profile that provides a higher level of
detail in the checking and reporting of CDC data.
# high_accuracy.do -- High-accuracy CDC profile
# Enable divergence checking and set reconvergence checking to a

# greater depth (default is 0). Start with a depth of 1.
cdc perference reconvergence -divergence_depth 1 -depth 1
# Enable reconvergence reporting for paths thru DMUX synchronizers.

cdc preference reconvergence -dmux_as_recon_start
# Enable FIFO and handshake scheme checking:

# Report disabled CDC paths.

cdc preference -filtered_report
# Enable constant propagation through registers with non-constant

# enables
netlist constant propagation -enable
Also, consider the following:

• Define all clock periods using netlist clock and turn on formal CDC analysis with the
cdc run command-line switch -formal. Start with the default -formal_effort (low).
• Turn on reporting of paths to dead-end nodes using the cdc run argument
-process_dead_end.
• Use modal analysis to check all modes of clocking (see “Modal CDC Analysis” on
page 92).

July 2013
CDC Analysis
Dynamic CDC Verification Flow

Dynamic CDC analysis consists of running user-defined simulation tests in your standard
simulation environment, with the added logic created by Questa CDC/Formal tools. This added
logic is derived from CDC protocol assertions, metastability injection logic, or both. To compile
this logic, use the –compile_assertions option to the cdc run command and specify the location
of the DUT in the testbench using the –prefix hierarchy_prefix argument. The results of
simulation with CDC protocol assertions can be merged with the static CDC database.
CDC Protocol Analysis

During static CDC verification, the formal CDC engine proved the CDC protocols are valid for
some schemes with basic protocols. But, the CDC transfer protocols for caution schemes must
be verified explicitly. Some scheme types have general characteristics that are readily verified
by checkers in the Questa CDC assertion library (Table 3-3).
Table 3-3. CDC Protocol Checkers

Checker Type Protocol
cdc_sync Ensures that a clock domain crossing signal from a faster
clock to a slower clock is held stable long enough for the
signal to be sampled reliably by the receiver.
cdc_sample Ensures that receive data between two clock domains remain
stable in the transmit domain for one receive clock cycle
before and one receive clock cycle after it is sampled in the
receive domain. The receive domain samples at least twice
for each transmit signal so that the correct value is sampled.
cdc_dsel Ensures that a signal between two clock domains, where the
transmitter’s data select signal drives the select input of a
data multiplexer in the receiver, is held stable enough for the
signal to be sampled reliably by the receiver and ensures that
the data remains stable while the data select signal asserts.
cdc_handshake_data Ensures that the handshaking protocol between transmitter
and receiver is correctly followed, and ensures that the
transmit data remains stable in the data transfer window.
cdc_hamming_distance_one Ensures that the data crossing from transmit clock to receive
clock domain changes by only one hamming distance and
that it remains stable for a specified tx_min clock cycles.
cdc_fifo Ensures that the write and read pointers of an asynchronous
FIFO change by hamming distance one, and ensures that the
FIFO does not overflow or underflow.
cdc_glitch Ensures that a specified register does not have a glitch in its
input.

July 2013
CDC Analysis
To test and verify the protocols for these schemes, static CDC analysis launched with the the -
compile_assertions argument “promotes” protocol checkers for CDC protocol analysis in
simulation. The CDC checkers are modules that ensure that data crossing clock domain
boundaries are transmitted and received correctly.
Once your test environment is set up to run simulations, you can add assertions for the promoted
CDC protocol checkers to the compiled DUT logic. The -compile_assertions option to the cdc
command compiles the assertions and sets up the arguments needed to run simulation with the
protocol checkers (and FX checkers if enabled), as shown in Figure 3-6.
Figure 3-6. Simulation with Promoted CDC Assertions

design files
vcom/vlog
-work library
Tcl files qcdc -c -do vsim
-f cdc_sim.arg
cdc run -compile_assertions merge
-f cdc_sim_vhdl.arg
cdc_sim.db
vcom/vlog
qcdc cdc.db
GUI
debugging
testbench files
vcom/vlog environment
Results from these simulations with CDC protocol assertions can be merged back into the CDC
GUI for review and debugging.
Running Simulation with CDC Protocol Assertions

The following procedure uses the Questa vsim simulator.
1. Set up the design library and compile the design.

For example:
prompt> vlib work
prompt> vcom dut.vhdl

Specify the -compile_assertions option and the prefix showing the hierarchy path from
the top level testbench to the DUT analyzed by qcdc. For example:

July 2013
CDC Analysis
prompt> cat cdc.do

onerror {exit 1}
do cdc_waivers.do
cdc run -d dut -compile_assertions -prefix tb.dut_inst
exit 0
prompt> qcdc -c -do cdc.do
3. Compile the protocol assertions.

Specify the simulation arguments files generated by cdc run. For example:
prompt> vlog -f cdc_sim.arg
prompt> vcom -f cdc_sim_vhdl.arg
4. Compile the testbench.

prompt> vlog tb.v
5. Run simulation.
Specify the PLI library path for the simulator and the vsim arguments files. For example:
prompt> vsim -c tb -pli install_dir/lib/lib0InLoadMTIPLI.so \
-f cdc_sim.arg.vsim -f cdc_sim.arg.vsimrun \
-do "add log -r /*; run 1000; quit -f"
6. Run the CDC GUI.

Load the cdc.db database generated by cdc run
prompt> qcdc cdc.db
7. Merge the simulation database.

Merge the cdc_sim.db database generated by vsim. Run File >Open >Database and
open cdc_sim.db.
8. Check results of simulation with the CDC protocol assertions.

July 2013
CDC Analysis
The CDC Checks window’s new Protocol field shows the status of the crossings from
simulation with CDC protocol assertions. The Type field shows the merged statuses.
The Protocol field has five types of status flags:
• Firing — Simulation violated the crossing’s protocol. The Firings field
shows the number of firings (number of times the protocol was violated) and First
Firing shows the testbench time of the first violation.
• Unevaluated — Simulation never activated the crossing’s protocol assertion.
• Evaluated (and Not Covered) — Simulation activated the crossing’s
protocol assertion. The Evaluations field shows the number of cycles the protocol
assertion activated. However, simulation did not exercise all the assertion’s cover
points.
• Covered — Simulation covered all of the crossing’s protocol assertion’s
cover points.
• Not Promoted— No protocol checker was promoted for the crossing.
Checkers are not promoted for proven crossings, some schemes that do not support
checker promotion and crossings schemes that have promotion disabled (i.e. cdc
promote crossing -off).
9. Debug protocol assertion firings.
Select the scheme and run Show >Protocol >Simulation Firings. From the Firings
dialog, select the desired firing. In the Load Waveform Database dialog, find the
generated waveform file.

July 2013
CDC Analysis
Use the waveform view, the schematic view and the source code editor to track down
and fix the source of the firings.
10. Check the Simulation window.
Firings ( ) are caused by either protocol violations or incorrect setup. A protocol
violation is a bug: simulation resulted in the protocol assertion failing. Check the
waveform for the firing (Show >Simulation Firings) to see how the failure can be
produced. You should fix the causes of protocol assertion firings or turn off their
promotion.
evaluated but not covered

partially covered
11. Check CDC assertion coverage.

The Simulation window shows the coverage information. In the data sheet
(“Protocol/FX Checkers” on page 243) for the promoted assertion, the Corner Cases
section shows the cover points associated with that assertion. Promoted assertions have
the following types of coverage results:
• Covered ( ) indicates simulation completely exercised the logic driving the
assertion. All associated cover points for the assertion have been hit. Use Show
>Coverage Waveform to see how each cover point is covered.
• Unevaluated ( ) indicates the assertion is not activated in simulation. Either
simulation is not sufficiently robust, or the assertion is not properly connected.
• Evaluated ( ) indicates the assertion did activate. However, not all cover points
are hit. The Coverage % thermometer shows the percentage of the assertion’s cover
points that are covered. Use Show >Coverage to display the coverage metrics for the
individual cover points associated with the assertion.

July 2013
CDC Analysis
CDC-FX Metastability Analysis

Simulation tests used for simulation with CDC protocol assertions can be re-used for CDC-FX
metastability analysis. For these simulations, the compiled design is extended with CDC-FX
metastability injection logic, which causes the simulated design to behave like a hardware
implementation with random metastability effects. End-to-end tests that pass under normal
simulation can fail when simulated with metastability effects, unless the design is “metastability
hardened.”
A clock domain crossing is metastability hardened if transmit values always are held stable
around receive clock edges whenever the active edges of the transmit and receive clocks
“align.” Here, the two clocks are considered aligned if the active transmit clock edge falls in a
“metastability window” around an active receive clock edge. By default, this window is set at
25% before the receive clock edge to 10% after the edge, but the sizes and skews of
metastability windows can be adjusted to accommodate clocking and physical design
characteristics. Crossings that are guaranteed to be stable when active clock edges align, do not
produce metastable values, so these paths are simulated the same in both regular simulation and
simulation with CDC-FX injectors. The injectors on these paths are never activated and
therefore never simulate metastability.
However, clock domain crossings that can legally become metastable also can be considered
metastability hardened. In these cases, the receive logic must account properly for the random
delays and advances that can occur as a result of the metastability effects exhibited by the
crossings and their reconverging logic. For these crossings, CDC-FX simulation randomly
injects metastability by delaying or advancing various value changes that occur when transmit
and receive clocks align in their metastability window.
Simulating the design with random metastability in this way tests that all clock domain
crossings are metastability hardened. If these simulation tests adequately exercise the design to
cover the various possible signal crossing situations, a truly metastability hardened design will
pass—indicating a high level of confidence that the design’s hardware implementation will not
exhibit faults arising from metastability. Alternatively, a well-constructed test suite simulated
with metastability effects will detect unhardened CDC paths and logic by producing end-to-end
test failures. These you debug the same way as with standard simulation by analyzing backward
from the miscompared outputs using your simulation waveforms and debug environment.
Running Simulation with CDC-FX Metastability Injection

1. If needed, add directives for setting metastability windows.
prompt> cat cdc_directives.do
# Define clocks
netlist clock cpu_clk_in -period 50
netlist clock core_clk_in -period 60
netlist clock mac_clk_in -period 50
# Define constants
netlist constant scan_mode 1’b0

July 2013
CDC Analysis
# Add CDC constraints

netlist blackbox pci_ctrl
# Add FX directives
cdcfx timescale 1ps/1ps
cdcfx fx window -start 5000 -stop 1000 \
-rx_clock wr_clk -tx_clock rd_clk
cdcfx fx window -start 6000 -stop 1000 \
-rx_clock rd_clk -tx_clock wr_clk
2. Adjust the cdc run invocation for FX generation.

The same setup used for simulation with CDC protocol assertions can be adapted for
CDC-FX simulation with a minor modification to the cdc run invocation. Add the -fx
argument, which generates the CDC-FX metastability injection logic.
prompt> cat cdc.do
onerror {exit 1}
do cdc_waivers.do
cdc run -d dut -compile_assertions -prefix tb.dut_inst -fx
exit 0
3. Compile and analyze the design.

For example:
prompt> vlib work
prompt> vcom dut.v
prompt> qcdc -c -do cdc.do
prompt> vlog tb.v
4. Run simulation.
For example:
Debug issues in the simulator debug environment as with standard simulations.

5. Run the CDC GUI.
Load the cdc.db database generated by cdc run
prompt> qcdc cdc.db
6. Merge the simulation database.

Merge the cdc_sim.db database generated by vsim. Run File >Open >Database and
open cdc_sim.db.

July 2013
CDC Analysis
7. Check results of simulation with CDC–FX metastability injection.

The CDC Checks window’s new FX field shows the status of the crossings from
simulation with CDC-FX metastability injection. Verify that the partition of Promoted
versus Not Promoted FX checkers is correct.
FX field
8. Check CDC–FX coverage.

The Simulation window shows coverage data. Entries of type cdc_fx are FX checkers.
FX checkers have FX checker

Type cdc_fx Not Covered
To show the coverage breakdown for a cdc_fx checker, select the entry and run Show
>Coverage.

July 2013
CDC Analysis
In this example, the All Bits Metastable cover point shows that 0 out of 8 bits are tested
with metastability injection. Typically, you modify simulation or run additional tests to
ensure complete coverage of the CDC-FX checkers.
Simulator Arguments
Table 3-4 shows additional arguments you can include in your simulator invocation when you
run simulation with CDC protocol checkers and CDC-FX checkers.
Table 3-4. Simulator Arguments

simulator_cmd simulator_args
–f sim_arg_file [+0in_no_checksim_db] [+0in_checker_finish_delay+time]
[+define+prefix_0in=prefix] [+0in_db+file] [+0in_firing_limit+limit]
[+0in_signature_limit+limit] [+0in_no_violation_limit] [+0in_firing_keyword+keyword]
[+0in_licq] [+0in_od+output_dir] [+0in_no_statistics] [+0in_covered_report[+file]]
[+0in_simulation_message_limit+limit] [+0in_no_simulation_messages] [–version]
[+0in_suppress_fx_name{+name}…] [+0in_disable_fx_force] [+0in_random_seed+n]
simulator simulator_args Simulator invocation for the design and testbench, including
HDL simulator arguments.
–f sim_arg_file File (generated by cdc -compile_assertions or ccl) with the
simulator arguments for running simulation with assertions
+0in_no_checksim_db Turns off generation of the .db database created by simulation
with assertions. Default: 0in_checksim.db.
+0in_checker_finish_delay Number of time units to continue simulation with assertions
+time before exiting after a firing (in response to a set_checker_action
-finish directive). Default: 10 time units.
+define+prefix_0in=prefix Changes the hierarchy prefix if needed for the target design
specified using the –d option in cdc/ccl.
+0in_db+file Name of the generated database. Default: 0in_tool.db (tool =
prove | confirm).
+0in_firing_limit+limit Maximum number of firings in the .db database. Default: 10.
+0in_signature_limit+limit Maximum number of signatures per check in the .db database.
Default: 10.
+0in_no_violation_limit Removes the limits on firings per signature and signatures per
check in the .db database.
+0in_firing_keyword Adds keyword to each firing message, so each firing message
+keyword begins with: 0-In keyword Firing
Default: Each firing message begins with: 0-In Firing.
+0in_licq Enables license queuing. Default: tools terminate if required
licenses are in use.
+0in_od+output_dir Directory to store all output files. Default: current directory.

July 2013
CDC Analysis
Table 3-4. Simulator Arguments (cont.)

+0in_no_statistics Turns off statistics computation and reporting during simulation.
+0in_covered_report[+file] Generates a structural coverage report. Default file name:
0in_covered.rpt.
+0in_simulation_message_ Number of firings per signature reported to the simulation log
limit+limit and STDOUT. Default: 1.
+0in_no_simulation_ Turns off reporting checker firing messages to the simulation log
messages and STDOUT.
–version Reports the software release version and copyright information
and exits.
+0in_suppress_fx_name Suppresses CDC-FX metastability injection for the specified
{+name}… registers.
+0in_disable_fx_force Suppresses CDC-FX metastability injection for all registers.
+0in_random_seed+n Sets the seed for random metastability injection.

July 2013
CDC Analysis
Clock Tree Detection

The report-clocks phase of CDC static analysis performs clock tree detection. CDC analysis
finds all signals that clock storage elements and tries to stitch the clocks together to identify the
design’s clock trees. Accurate static CDC analysis requires that clock trees are identified
properly and that clock trees for the same clock domains are grouped together.
Only paths that cross clock domain boundaries are reported as clock domain crossings and are
further analyzed. So, all expected clock domains should match all the separate clock groups. If
two expected clock domains are combined in the same group, no CDC reporting and analysis
occurs for paths between the two (which makes analysis incomplete). Similarly, if what is
expected to be a single clock domain is split into two clock groups, CDC analysis reports paths
between them as clock domain crossings and analyzes them (which adds “noise” to the results
and reduces performance). Having many more groups than expected clock domains might even
slow some GUI operations (such as expanding entries) so much that the GUI becomes unusable
(seems to “hang”).
Clocks Window
The Clocks window (Figure 3-8) in the GUI shows how CDC analysis assumes the clock
groupings specifying the clock domains are defined.
Figure 3-7. Clocks Window in the GUI

July 2013
CDC Analysis
The first level is the clock group classification (the specified type or one of the inferred types,
described in subsequent sections). The second level lists the separate clock groups. The name of
the clock group (cpu_clk_in, mac_clk_in, core_clk_in and check_en in the figure) is the top-
level string. This name can be specified explicitly (using the -group <name> option of the
netlist clock directive) or it can be derived. A derived clock group name is the hierarchical name
of the originator clock in the group. If the group has multiple clock trees (and no explicit clock
group name), the derived group name is the originator clock (root) of one of the clock trees. The
third level lists the clock trees that make up the group. The remaining levels show the various
levels of the clock trees.
The clock groups are color-coded: References to objects in a particular clock group (such as
source code and schematics objects) are displayed in the same color. The Clocks window also
shows the number of register and latch bits clocked in the corresponding domains. The
Expression column shows gating expressions for gated clocks to help debug the CDC setup.
Gated clocks need to be resolved to force their interpretation as nodes in real trees (gated clocks
have multiple “roots”).
User-specified Clock Trees

You manually specify a clock tree by naming the originator clock (root) for the tree in a netlist
clock directive. For example:
netlist clock cpu_clk_in

netlist clock core_clk_in
netlist clock mac_clk_in
These three directives identify three trees with originator clocks cpu_clk_in, core_clk_in and
mac_clk_in. Each clock is a signal referenced hierarchically from the top level of the design.
CDC clock tree detection traces the tree down levels of hierarchy to its “leaf” clocks. For
example, the clock tree for the originator clock core_clk_in is:
core_clk_in
–>core_clk
–>fifo_1_d.wr_clk
–>fifo_1_d.u0.Wclk
–>fifo_0_h.wr_clk
–>fifo_0_h.u0.Wclk
The core_clk_in signal drives core_clk in the top module. The core_clk then drives wr_clk in
fifo_1_d, which drives Wclk in u0, and so on. When the result is unambiguous, tree detection
follows through MUXed and combinational logic. For example, core_clk is defined with this
MUX:
assign cpu_clk = scan_mode ? scan_clk : cpu_clk_in;
The ambiguity is resolved by a netlist constant directive:
netlist constant scan_mode 1'b0

July 2013
CDC Analysis
Clock trees rooted in lower levels of hierarchy can be specified hierarchically or with the
-module option:
netlist clock fifo_1_d.wr_clk
or
netlist clock wr_clk -module generic_fifo
The first directive identifies one clock tree (in the mac.u0 instance).
The second directive identifies a tree per instance of generic_fifo. For example, if fifo_1_d and
fifo_0_h are instances of generic_fifo, the two trees have roots fifo_1_d.wr_clk and
fifo_0_h.wr_clk. All trees defined by the same netlist clock directive are grouped together, so all
of the clocks in the two clock trees are in the same group. If a name for the group is not
specified (i.e., with the -group <name> option), one of the matching root clocks is selected as
the name (for example, clock group fifo_1_d.wr_clk).
A single clock tree can be split by specifying roots in separate directives, for example:
netlist clock core_clk_in

netlist clock fifo_1_d.wr_clk
netlist clock fifo_0_h.wr_clk
Clock Tree Grouping

A clock domain can have a single clock tree or it can have multiple clock trees. For example,
the clock domain might be clocked by several synchronous distributed clock trees. Or, a clock
tree might be “broken” into two pieces by going through a black box, MUX or combinational
logic. Specifying multiple trees in a single directive is one method:
netlist clock cpu_clk_in core_clk_in
Specifying them in two directives (with the -group <name> option) is another:
netlist clock cpu_clk_in

netlist clock core_clk_in -group cpu_clk_in
Or:
netlist clock cpu_clk_in -group master_clk

netlist clock core_clk_in -group master_clk
hdl-77 Warnings
The required argument to a netlist clock directive is a repeatable clock name pattern, for
example:
netlist clock core_clk_in xyzzy xya*

July 2013
CDC Analysis
Any pattern with no matching signal generates an hdl-77 warning:
# Warning : Signal specified for directive has no match.

# Signal 'xyzzy', Module 'demo_top', Directive 'netlist clock',
# File 'qs_files/directives.tcl', Line 5. [hdl-77]
# : Signal will be skipped.
# Expanding Wildcard 'xya*', Module 'demo_top',
# File 'qs_files/directives.tcl', Line '5'
# Warning : Signal specified for directive has no match.
# Signal 'xya*', Module 'demo_top', Directive 'netlist clock',
# File 'qs_files/directives.tcl', Line 5. [hdl-77]
# : Signal will be skipped.
You should fix these directives because a pattern might be mis-typed.
Unused Clocks
After verifying the specified patterns match design signals, clock tree detection checks that the
signals in the tree are real clocks: they actually clock storage elements (register and latch bits).
Those that do not are classified as unused clocks.
Ignored Clock Groups

You can mark clock groups to be ignored. Their associated clock domains are removed from
CDC analysis: No crossings from/to the domains of ignored clock groups are analyzed. To mark
a clock group as ignored use the cdc clock attribute command:
cdc clock attribute -group cpu_clk_in -ignore
The -group argument is the clock group name specified with a netlist clock -group <name>
directive, or an inferred name taken from one of the originator clocks in a tree in the group.
Inferred Clock Trees

Ideally, you define clock groups by specifying the top-level clock ports with individual netlist
clock directives; CDC clock tree detection traces the groups down to the leaf clocks; the entire
design is partitioned into the expected clock domains; CDC analysis works; you are done.
Resolving Inferred Clock Trees

Unfortunately, with complex clocking schemes in designs, this flow is not typical. A design
might have black boxes that originate clocks or that have clock trees pass through. Clock tree
detection splits these trees into separate clock groups. Combinational logic in clock trees and
MUXed clocks complicate the situation further. Grouping split trees helps, but might not be
sufficient. The initial user-specified clock trees typically do not cover all clocks. So, after
performing clock tree detection on the user-specified clock groups, CDC analysis runs clock
tree detection on the remaining clocks.

July 2013
CDC Analysis
The result is a set of clock trees, called inferred clock trees. CDC analysis considers these
individual trees to be individual clock groups. Typically most (if not all) of these trees should be
grouped with some of the user-specified groups or should be grouped together. The process of
creating netlist clock directives that do so is called resolving the inferred clock trees.
Caution
You MUST resolve inferred clock trees before proceeding to full CDC static analysis.
Otherwise, the inferred clocks trees are treated as defining separate clock domains. Much
extra time is wasted analyzing “false” crossings among them and between them and the
user-defined clock groups. In extreme cases, so many innocuous violations are reported
that the GUI seems to slow down to the point of “freezing.”
To help you resolve the inferred clock trees, clock tree detection classifies inferred clock trees
into the following classes: primary, black box, gate MUX, gated combo, undriven and other
(Figure 3-8).
Figure 3-8. Clock Signal Classification

clock signal
user-defined inferred
primary
used
black box
MUX
unused gated
combo
undriven
ignored
other
See Table 3-5 for information about how to resolve each type of inferred clock tree.
Table 3-5. Resolving Clock Trees

Type Class Description Fix
user-defined specified Signal matches a netlist No fix needed. The netlist clock
clock specification and CDC directive is used to identify the clock
analysis finds that it clocks group for the signal.
elements in the design.

July 2013
CDC Analysis
Table 3-5. Resolving Clock Trees (cont.)

unused Signal matches a netlist The netlist clock directive is ignored,
clock specification and CDC so it can be removed safely. But,
analysis finds it in the check that the specification is not mis-
design. But, the signal does typed.
not clock any element.
ignored Signal or group name No fix needed. Clock domain for the
matches a cdc clock group is removed from CDC analysis.
attribute -ignored
specification.
inferred primary Clock tree originates from a Clock tree is considered asynchronous
primary port of the design. to the other clock groups. Use a netlist
clock directive to assign the clock to a
clock group, if necessary.
black box Clock tree originates from Clock tree is considered asynchronous
the output port of a black to the other clock groups. Use a netlist
box. clock directive to assign the clock to a
clock group, if necessary.
gated MUX Clock tree originates from a CDC analysis assumes the clock tree
clock MUX output. The is asynchronous to both driving
MUX switches between two clocks. To handle the inferred gated-
or more asynchronous MUX clock, you can: 1) Use netlist
clocks, controlled by a select clock to group the clock with another
signal. clock group; 2) Use netlist constant
on the MUX select to group the
inferred clock with the remaining
“active” driver; or 3) Use modal
analysis.
gated combo Clock tree is output from CDC analysis assumes the clock tree
combinational logic, (which is asynchronous to all clocks. To
is driven by multiple handle the inferred gated-combo
identified clocks or by no clock, you can: 1) Use netlist clock to
identified clock). group the clock with another clock
group; 2) Use netlist constant on non-
clock signals to force the clock to be
grouped with a driver clock; or 3) Use
modal analysis.
undriven Clock tree originates from Fix the problem that caused the
an undriven wire (for module to be unresolved (i.e. not
example, the output of an compiled). Otherwise, leave the clock
unresolved module). asynchronous or use a netlist clock
directive to assign the clock tree to a
clock group.

July 2013
CDC Analysis
Table 3-5. Resolving Clock Trees (cont.)

other Clock is not in the other Leave the clock asynchronous or use a
classes. netlist clock directive to assign the
clock tree to a clock group.

July 2013
CDC Analysis
Modal CDC Analysis
Modal CDC Analysis

Modal CDC analysis configures the design as a set of operational modes and runs CDC analysis
on each modal version of the design. Modal CDC analysis accomplishes two things:
• Reduces complexity and pessimism

Using a divide-and-conquer approach, CDC analysis is split into smaller pieces. Rather
than have a huge number of violations and cautions for the general design, CDC analysis
returns results in groups relevant to the legal operational modes of the design. Running
regular CDC analysis on such a design returns pessimistic results because the design has
more clock domains. Modal CDC analysis eliminates these pessimistic results.
• Captures the modal nature of the design
An artifact of modal CDC analysis is that a design’s various legal operational modes
become well-defined. Understanding these operational modes helps designers and
verifiers grasp the true nature of the design’s functionality.
The CDC analysis flow for modal CDC analysis is the same as for regular CDC analysis, except
with some additional steps:
• Phase 1: Compiling the design.

This phase is the same for both flows.
• Phase 2: Running CDC analysis
Run CDC report clocks and ensure the clock domain partition is correct. Before running
full CDC analysis, run CDC report modes. This extra step infers the various operational
modes recognized by the analyzer. You can manually adjust the modal setup as with
setting up the clock domains.
Once the clock domains and operational modes are established properly, run full CDC
analysis for each mode. An automatically-generated run script helps you configure and
run this stage of modal CDC analysis.
• Phase 3: Running GUI debug.
This phase also is similar for both flows. However, the GUI has several modal indicators
that are not relevant to non-modal designs and are not visible when viewing regular
CDC analysis results. The results of all the modal CDC runs are combined in a single
database. Therefore, the GUI has an additional separation of results based on the various
operational modes.

July 2013
CDC Analysis
Modal CDC Analysis
Running CDC Modal Analysis

Run report clocks as with regular CDC analysis. Then run report modes and adjust until the
operational modes are correct. Then run modal CDC analysis on each of the various modal
versions of the design.
Report Modes
CDC report modes finds the design’s clock configuration registers and determines the design’s
operational modes by examining the clock multiplexing circuits. Consider the following case:
clkA
MUX X0
clkB
ctrl[0]
ctrl
ctrl[1]
MUX X1
clkC
Assume that clkA, clkB and clkC are asynchronous and X0/X1 are clock signals. Unless X0 or
X1 are grouped with clkA, clockB or clkC, regular CDC analysis considers this circuit as having
5 clock groups. CDC report clocks shows this is the case. When you examine this circuit, you
see that as a non-modal circuit, simplifying CDC analysis by grouping some of these clock
signals is not correct. Yet, regular CDC analysis results are pessimistic.
For cases such as these, you can use modal analysis to remove the pessimism. First, run CDC
report modes by specifying the -report_modes option to the cdc run command. For the above
circuit, CDC report modes finds 4 operational modes and generates the following mode
definitions in a generated Tcl file (cdc_mode_ctrl.tcl):
cdc mode cdc_mode_0 -set {ctrl[0]} 1’b0 -set {ctrl[1]} 1’b0

These modes correspond to the following assignments for X0/X1:
cdc_mode_0: X0 = clkA and X1 = clkB

cdc_mode_1: X0 = clkA and X1 = clkC
cdc_mode_2: X0 = clkB and X1 = clkB
cdc_mode_3: X0 = clkB and X1 = clkC
Each of these modal circuits is less complex than the non-modal circuit. In particular, they have
3 clock domains rather than 5. Results of modal CDC analysis of each modal circuit are less
pessimistic.

July 2013
CDC Analysis
Modal CDC Analysis
Adjusting CDC Modes

If the inferred modes found with the initial CDC report modes run is not accurate and complete,
you can adjust the mode specification by creating user-specified cdc mode directives. You can
make three types of adjustments:
• Skip a particular mode

An inferred mode might not be interesting for CDC analysis. You can identify such a
mode by adding the -ignore argument to its corresponding set mode directive. Do not
edit the cdc_mode_ctrl.tcl file, as this file is overwritten each time you run CDC report
modes. Instead, copy the directive to a directive file called by the CDC report modes
run. For example, if you want to skip analysis of cdc_mode_2 from the above example,
add the following directive (the mode name is changed for readability):
cdc mode clkB_only -set {ctrl[0]} 1’b1 -set {ctrl[1]} 1’b0 -ignore
One important rule: when specifying cdc mode directives to define a particular mode,
the definition must be complete. Every mode possibly configured by the various
combinations of mode control signal values must be specified before the CDC report
modes step is complete. So, if you add the above directive, you must also add the
missing modes:
cdc mode mode0 -set {ctrl[0]} 1’b0 -set {ctrl[1]} 1’b0
• Identify additional modes

Since the initial CDC report modes infers operational modes controlled by MUX selects
of clocks, some modes might be missed. You can specify these modes manually with
user-defined cdc mode directives. For example:
cdc mode fast_mode -set tm 1'b0 -set sel 1'b1
cdc mode scan_load -set tm 1'b1 -set scan_en 1'b1 -ignore
cdc mode scan_test -set tm 1'b1 -set scan_en 1'b0 -ignore
Each -set argument specifies a register, port or black box output and its corresponding
constant value for the mode.
• Identify mode control signals
You can identify signals that contribute to the configuration of the design’s operational
modes with the cdc mode control directive. For example:
cdc mode control config dut/clkgen/ctrl0 dut/clkgen/ctrl1
CDC report modes uses this information to generate the cdc mode directives for the
correct operational modes. When specifying mode control signals this way, you can
mimic the behavior of the -ignore argument. The syntax for the cdc mode control
directive is:

July 2013
CDC Analysis
Modal CDC Analysis
cdc mode control signal… [-values value…]

Only modes for which each specified signal assumes one of the specified values is
analyzed. CDC report modes creates cdc mode directives with -ignore arguments for the
other modes.
After adjusting the CDC modes, you must re-run CDC report modes. Check the Modal Analysis
Information table in cdc.rpt for the complete description of the defined CDC modes. For
example:
Section 8 : Modal Analysis Information

=================================================================
Mode information
-------------------------------------------------------------------------
Mode Type Information
-------------------------------------------------------------------------
mode0 User OK
mode1 User OK
mode2 User OK
mode3 User Ignored mode
mode4 User Ignored mode
-------------------------------------------------------------------------
User Modes
==========
Constants in mode0
-------------------------------------------------------------------------
Signal Value Type
-------------------------------------------------------------------------
scan_mode 1’b1 User
-------------------------------------------------------------------------
Constants in mode1
-------------------------------------------------------------------------
Signal Value Type
-------------------------------------------------------------------------
clk_config 2’b11 User
-------------------------------------------------------------------------
. . .
Constants in mode4 (Ignored)

-------------------------------------------------------------------------
Signal Value Type
-------------------------------------------------------------------------
clk_config 2’b00 User
-------------------------------------------------------------------------
Inferred Modes
==============
None

July 2013
CDC Analysis
Modal CDC Analysis
The Mode Information table shows the status of each detected mode:
OK Mode is user-defined and is complete. If its user-specified cdc mode

directive names a signal that is not an inferred mode control signal, the
analyzer issues an info message:
(Info) hdl-124: User mode signal undetected by mode inferencing.
Try identifying such signals with the cdc mode control directive and re-
running CDC report modes to see if additional modes are inferred.
Ignored Mode is user-defined with the -ignore option to the cdc mode directive.
Modal CDC analysis is not performed on ignored modes.
Duplicate Mode has the same control signal/value pairs as another complete or
incomplete mode. The analyzer issues a warning:
(Warning) hdl-118: Duplicate user mode. Mode ’mode1’ is a duplicate

of Mode ’mode2’.
Remove the extra mode or resolve the incomplete mode.

Missing Mode is inferred and is missing from the user-defined modes. User-defined
modes must be completely specified. If you specify a particular mode with
the cdc mode directive, you must also specify all variations of the
directive—with all of its control signals set to all possible values. The
analyzer warns of missing modes:
(Warning) hdl-119: Missing user mode.
Check cdc_mode_ctrl.tcl for the cdc mode directives for missing modes.
Incomplete Mode is user-defined, but its specification is not complete. The analyzer
warns that a control signal is missing from the directive:
(Warning) hdl-125: Missing user constant for mode. Mode ’mode’,

Signal ’ctrl_signal’.
Add the missing -set signal constant argument (see cdc_mode_ctrl.tcl).
Modal CDC
Once the operational modes are defined, run modal CDC analysis by executing the Tcl script
created by CDC report modes:
prompt> qcdc -c -do outdir/cdc_mode.tcl

July 2013
CDC Analysis
Modal CDC Analysis
After some setup, the core of this script is:
# Invoke CDC for all the modes.

foreach cdc_mode {mode0 mode1 mode2} {
# Run CDC for $cdc_mode
configure output directory ${cdc_od}/$cdc_mode
eval "$cdc_cmd -mode $cdc_mode"
}
The script executes cdc run once for each of the modes. Here, ${cdc_od} is cdc_mode in the
same output directory specified for the CDC report modes run. ${cdc_od} contains a
subdirectory for each analyzed mode (with that mode’s name). In the above example:
cdc_mode/mode0, cdc_mode/mode1 and cdc_mode/mode2.
However, you need not be concerned with these output directories. The cdc.db file created by
the CDC report modes run contains the modal analyses results for all modes collected together.
Parallel Modal Analyses

Running cdc_mode.tcl runs a modal CDC analysis session for each (un-ignored) mode in
sequence. To run these sessions in parallel, you must set up the individual modal analysis runs
manually. You can use separate hosts or set up the flow to run on a host grid.
Two points to remember:
• Specify output directories mapped to the same directories used by cdc_mode.tcl. For
example:
configure output directory outdir/cdc_mode/mode1
Here, outdir is the output directory used by the -report_modes run; cdc_mode is hard
coded; and mode1 is the mode name.
• Specify the -mode argument to the cdc run executable. For example:
cdc run -d dut -mode mode1...
Running Modal GUI Debug

Run GUI debug of modal CDC results by loading the database file generated by the CDC
report modes run:
prompt> qcdc outdir/cdc.db
This database file connects to the individual database files for the separate modal CDC runs
(outdir/cdc_mode/mode1/cdc.db etc.).

July 2013
CDC Analysis
Modal CDC Analysis
Note
View combined modal CDC results from the db file created by CDC report modes. You
can leave this database displayed during the combined modal CDC run. Use File
>Reload >Database to refresh results dynamically as the individual modal analysis
sessions run.
Clocks window (Figure 3-9) and the CDC Checks window (Figure 3-10) show information
grouped by mode.
Figure 3-9. Clocks Window Showing Modal CDC Results
clocks for each mode
Figure 3-10. CDC Checks Window Showing Modal CDC Results
results grouped by mode

July 2013
CDC Analysis
Modal CDC Analysis
The Details window shows the mode when displaying details for crossing.
details window
shows mode
When viewing a schematic from a crossing entry, the context frame in the window footer shows
the mode.
context frame
shows mode

July 2013
CDC Analysis
Hierarchical CDC Analysis

Hierarchical CDC analysis is a methodology that runs CDC static analysis sessions with less
memory. It is the only feasible methodology for analyzing some complex, large designs with
many clock domain crossings. The hierarchical CDC flow is a bottom-up flow that analyzes
selected lower-level blocks individually to resolve CDC problems and then analyzes the top-
level design to resolve inter-block and top-level issues (Figure 3-11).
Figure 3-11. Bottom-up Hierarchical CDC Flow
BLOCK intra-block violation

V
1. Analyze selected blocks
individually. intra-block violation
Debug intra-block issues. V
Generate interface logic intra-block violation
model (ILM) for the block.
V
top-level violation
TOP LEVEL ILM V
2. Analyze top-level
design.
ILM top-level violation
Debug inter-block V ILM
and top-level issues.
ILM
inter-block violation ILM

V
ILM ILM
ILM
CDC interface logic
model of a block
CDC analysis of the hierarchical blocks relies on block-level constraints that specify the
properties of external clocks and externally-clocked signals. Questa CDC supports two separate
flows for specifying these constraints: Top-down constraints are extracted automatically by
analyzing the design from the top level downward. Bottom-up constraints are manually
specified without reference to design information at higher levels. Bottom-up constraints are
useful for modeling IP blocks (which cannot be specified in the context of the full design).

July 2013
CDC Analysis
Note
Hierarchical CDC analysis is static analysis only and does not support promotion of
protocol assertions or generation of CDC-FX injectors.
Prerequisites
Before running hierarchical CDC, set up the design for CDC analysis as you would for flat CDC
analysis.
1. Compile the design files.

2. Set up a top-level directives file.
• Identify the design clocks (netlist clock).
• Identify the clock domains of the primary ports (netlist port domain).
• Identify sources of stable signals (netlist constant and cdc signal -stable) so CDC
analysis can optimize design logic.
• Identify custom synchronizers (cdc synchronizer) and black box modules/entities
(netlist blackbox).
• Set up other CDC preferences.
3. Run cdc run with the -report_clock option.
For example:
prompt> qcdc -od outdir -c -do “\
do directives.tcl ; \
cdc run -d top -report_clock”

Check the CDC logs; fix errors; and resolve warnings. If you change the source code, go
back to step 1.
5. Check cdc.rpt.
Ensure the clock groups and port domains are identified correctly. If not, go back to step
2 and fix.

July 2013
CDC Analysis
Hierarchical CDC Flow

The hierarchical CDC flow is a 3-phase bottom-up verification process as shown in
Figure 3-12.
Figure 3-12. Hierarchical CDC Flow
Phase 1 a) Select blocks: blk1 blk2 blk3 . . .

Set up Blocks b) Create hierarchical constraints for the blocks.
hierarchical constraints
Phase 2 do outdir/cdc_hier_constraints_blk1_ctrl.tcl
Analyze Blocks cdc run -hier_block blk1
. . .
block CDC interface models (ILMs)
Phase 3 cdc run -hier_cache \

outdir/cdc_hier/blk1/qcache \
Analyze Top-level Design outdir/cdc_hier/blk2/qcache \
outdir/cdc_hier/blk3/qcache
Note
Hierarchical CDC is a bottom-up verification process where you perform full static
CDC analysis on selected lower-level blocks first, and then run static CDC analysis on
the top level plus the remaining design logic. Questa CDC does not support a top-down
verification process where you run static CDC analysis on the top level first and then run
static CDC analysis on the lower-level blocks. Hierarchical CDC does however support
both top-down and bottom-up creation of block constraints as described in “Block
Constraints” on page 105.
Phase 1: Set up Blocks

Before running CDC analysis at the block level, select the hierarchical blocks and create
hierarchical CDC constraints for the blocks.
1. Select hierarchical blocks.

Select the blocks you want to analyze individually. Typically they correspond to design
units handled by individual developers or development teams. Candidates are blocks
with many internal CDC boundaries. Since you are trying to reduce the memory used for
CDC analysis, you should select blocks that distribute the CDC logic evenly across the
blocks.
Block instances do not have to be at the top level of the design. But, block instances
cannot have hierarchical references to objects in the top level or to other block instances

July 2013
CDC Analysis
(and vice versa). That is, when you analyze a hierarchical block in phase 2, all of its
hierarchical references must be resolved within the block and when you analyze the top
level in phase 3, all of its hierarchical references must be resolved to objects not in any
block analyzed in phase 2.
2. Create hierarchical constraints for the blocks.
To run CDC analysis for a particular block, you must specify the hierarchical
constraints for the block. These are CDC constraints that the design imposes on the
block. “Block Constraints” on page 105 describes two methods for creating the blocks’
hierarchical constraints.
A block’s CDC constraints are specified as a set of directives in a hierarchical constraints file
associated with the block. Example 3-1 shows a hierarchical constraints file for the sample
block blk2.
Example 3-1. Hierarchical Constraints File
#-----------------------------------------------------------------
# CDC Control File
#-----------------------------------------------------------------
# Block: blk2
# Instances:
# b2_1
# b2_2
# b2_3
# Parameters/Generics:
# sel = 3
cdc preference -promote_reconvergence -formal_add_bus_stability \
cdc preference fifo -no_read_sync
cdc preference handshake -check_mux_recirculation
netlist constant propagation -enable
netlist clock clk -module out1
netlist port domain rst -none -module increment
netlist port domain data_in1 -clock clk -module increment
netlist clock top.clk1 -virtual -module inc_2
netlist port domain data_in -clock top.clk1 -module increment
netlist port domain data_out -clock top.clk2 -module increment
Phase 2: Analyze Blocks

For block-level CDC analysis, run a CDC analysis session for each block. To speed up analysis,
run these sessions on different hosts in parallel. The following steps analyze the blk2 block:
1. Run block-level CDC analysis.

For example:
prompt> qcdc -od outdir/cdc_hier/blk2 -c -do “\
do outdir/cdc_hier_constraints_blk2_ctrl.tcl ; \
cdc run -d top -hier_block blk2”

July 2013
CDC Analysis
To segregate the block-level analysis from that of the other blocks and from the top-
level analysis, the output is directed to a subdirectory of the outdir directory (-od
outdir/blk2). The block constraints file (cdc_hier_constraints_blk2_ctrl.tcl) was
generated in phase 1. The -hier_block argument identifies the block for the block-level
analysis.
2. Run the CDC GUI and verify the CDC analysis.
prompt> qcdc -c -do “outdir/cdc_hier/blk2/cdc.db”
Verify the CDC checks for the block. Violations represent issues within the block. You
can fix problems with the RTL source code, re-run CDC analysis for the block and
iterate. But, changes to the RTL might affect CDC analysis of other blocks or the top
level design, so use caution. If you do change the source code, you must re-generate
block constraints and re-run block analyses for all hierarchical blocks—to ensure the
results are accurate and complete—before you analyze the top-level design.
Run steps 1 and 2 for each hierarchical block.
Phase 3: Analyze the Top Level

Caution
You can run top-level CDC analysis only if the interface RTL of the design and the
blocks match. If you change the interface logic after running block-level analysis, you
must re-run the complete hierarchical CDC flow. You also need to use the same version
of vlog/vcom and Questa Static tools for the complete hierarchical CDC flow.
Top-level CDC analysis builds a model of the top design from the CDC interface models for the
blocks analyzed in phase 2 and from the remaining design logic.
1. Run hierarchical CDC analysis of the top level.

For example:
prompt> qcdc -od outdir/top -c -do “\
do top_directives.tcl ; \
cdc run -d top -hier_cache \
outdir/cdc_hier/blk3/qcache
The -hier_cache option lists cache directories for the hierarchical blocks. The
outdir/blk1, outdir/blk2 and outdir/blk3 directories were specified as the output
directories (-od dir) during the block-level sessions. The name specified for the cache is
qcache. The top-level CDC analysis detects the crossings not covered by the block-level
runs and the crossings into the portal boundaries of the hierarchical blocks.

July 2013
CDC Analysis
2. Run the CDC GUI and verify the CDC analysis results.
prompt> qcdc outdir/cdc_hier/top/cdc.db
Check the results for the design. At this point, the whole design is available to the GUI
for debugging. Results from the block-level sessions are merged into the top-level
results. However within the blocks, only partial netlist information is available (i.e., only
the level of detail retained in the CDC interface models of the blocks).
Block Constraints
You can create the hierarchical CDC block constraints two ways: propagate them from the
bottom up and propagate them from the top down.
• bottom-up constraints
You manually create the constraints for the individual blocks. Later, CDC analysis of
the top level performs consistency checks to verify that the constraints specified at the
top level do not conflict with the constraints propagated up from the lower levels.
• top-down constraints
You first run a special CDC session on the top level (report constraints) , which
generates hierarchical CDC constraints files for the block-level analyses automatically.
After analyzing the blocks and generating the ILMs, run the top level analysis session,
which performs the consistency checks. This checking provides a sanity check that no
logic or constraints are changed during the hierarchical CDC verification process.
Bottom-up Block Constraints

You typically use the bottom-up method for creating block constraints if either of the following
is true:
• You are developing the design bottom up and the top level is not finalized or is
unsynthesizable. You do not have top-level constraints to push down to the lower levels.
• The top level is available, but is too large to process by automatic block-level constraint
generation.
Specify each block’s CDC constraints as a set of directives in a hierarchical constraints file for
the block. To create bottom-up constraints:
1. Manually create a hierarchical CDC constraint file for each block.

Use directives to specify: clocks, clock groups, constants, port domains and stable ports.
2. Run hierarchical CDC analysis of the blocks and their constraints.

July 2013
CDC Analysis
In addition to finding CDC violations at the top level (and in the remaining logic), hierarchical
CDC analysis of the top level performs consistency checks. These checks compare constraints
used for the blocks with the block constraints propagated down from the design-level
constraints.
Because top-level and block-level constraints are created manually, errors and mismatches are
more likely. You must fix these errors and mismatches for hierarchical CDC analysis to be
accurate. The types of constituency checks are:
• Clocks — Clocks connected to the block ports are the same when analyzing the top level
as they were when analyzing the blocks.
• Clock groups — Block-level clock groups are the same when analyzing the top level as
they were when analyzing the blocks.
• Constants — Constants on the block ports are the same when analyzing the top level as
they were when analyzing the blocks.
• Port domains — Domains of the block ports are the same when analyzing the top level
as they were when analyzing the blocks.
• Stable ports — Block ports marked stable at the block level are also marked stable at the
top level.
Top-down Block Constraints

You typically use the top-down method for creating block constraints if both of the following
are true:
• The top level is finalized, is synthesizable and has its top-level constraints defined.
• Automatic block-level constraint generation (cdc run -report_constraints) completes
satisfactorily.
If not, you must use the bottom-up method of creating block constraints. To create top-down
constraints:
1. Run cdc with the -report_constraints option.

This option runs automatic block-level CDC constraint generation, reports the clock
domain data and quits. The arguments to -report_constraints are the design unit names
of the block instances. For example:
cdc run -d top -report_constraints blk1 blk2 blk3
If the same module/entity is instantiated more than once, CDC constraint generation
handles variations in the top-level connectivity and parameters/generics for the different
instances.

July 2013
CDC Analysis
2. Check results.
a. Fix errors and resolve warnings.
b. Check cdc_design.rpt and ensure the clock groups and port domains are identified
correctly.
c. Check the cdc_hier_constraints_*_ctrl.tcl files (if desired). For each block, check
the design unit name, instance name, parameter/generic values and the directives.
Each hierarchical constraints module for a block has two parts:
• Global CDC preferences
Design-level directives can apply to the various blocks as well as the design as a
whole. For example, cdc preference, cdc preference fifo, cdc preference handshake,
netlist constant propagation and cdc reconvergence can apply globally and can
apply to the hierarchical blocks or their sub-blocks (i.e., with the -module option).
Those directives that apply to the block are reproduced in the global CDC
preferences section so you do not need to taylor the design-level preferences to each
block.
• Block specifications
Clock domain analysis of the block’s instances determines the block instances’
clocks and clock domains of the block’s ports. These constraints are specified with
netlist clock and netlist port domain directives. Also, netlist constant and cdc signal
-stable directives are “propagated” to the block instance logic.
3. Run hierarchical CDC analysis of the blocks and their constraints.
Before it performs static CDC analysis of the top level, the CDC analyzer performs
consistency checks of the hierarchical CDC structure. These checks compare the
(actual) block constraints propagated from the top level with those (forecast) constraints
used for the block-level analyses.
If you used the top-down method of creating block constraints, did not change the RTL
source and did not adjust the constraints, then the constraints used at the block levels
should match those used in the top-level analysis. Therefore, consistency checking acts
as a “sanity check” that the hierarchical analysis is not corrupted. Note that if you use
bottom-up constraints, the consistency checks might find various violations because the
constraints are created manually and are therefore prone to error.

July 2013
CDC Analysis
Hierarchical CDC Makefile

The hierarchical CDC flow described in the previous sections shows the steps that run each
phase of the hierarchical CDC analysis procedure. This is a “manual” flow intended to illustrate
the hierarchical verification process. If you generate top-down block constraints by running
CDC report constraints, you can perform phases 2 and 3 automatically (Figure 3-13).
Figure 3-13. -report_constraints Generates Hierarchical CDC Makefile
Phase 1 cdc run -d dut

Generate Block Constraints -report_constraints blk1 blk2 blk3
cdc_hier_blk1_ctrl.tcl
Phase 2
Analyze Blocks make blk1 cdc_hier.Makefile
make blk2
blk1/qcache make blk3
blk2/qcache
blk3/qcache
Phase 3
Analyze Top make dut
Running cdc run with the -report_constraints option generates not only the block constraints,
but also a hierarchical run-control makefile called cdc_hier.Makefile. This makefile is created
so that the session output directory (-od or configure output directory) is specified as the top-
level output directory for the files generated by the scripts.
Note
You also can generate this makefile without performing constraints generation, by
running cdc run with the -report_hier_scripts option.
The makefile has a make target for each hierarchical block. Running the target for a block
performs hierarchical CDC analysis for the block. In the above example:
prompt> make -f outdir/cdc_hier.Makefile blk1

The makefile also has a target for the top level. Running this target performs hierarchical CDC
analysis for the top level. In the above example:
prompt> make -f outdir/cdc_hier.Makefile dut

July 2013
CDC Analysis
Example 3-2. cdc_hier.Makefile
## Hierarchical CDC Makefile

##-----------------------------------------------------
CDC_OD = /home/bobo/cdc_hier
CDC_HIER_CMD = cdc run -d top
CDC_TOP_CMD = cdc run -zdb /home/bobo/cdc_hier/ILM/qcache/DB/zdb_0 -d top
0IN = 0in
BLOCKS = increment out_blk sync_blk
#########################################################################
# Make Targets
#########################################################################
# BLOCK LEVEL RUN: increment
increment:
rm -rf $(CDC_OD)/increment
qcdc -c -do "\
onerror {exit 1}; \
configure output directory $(CDC_OD)/increment; \
do /home/bobo/cdc_hier/cdc_hier_constraints_increment_ctrl.tcl; \
$(CDC_HIER_CMD) \
-hier_instance {{top.inc_1} {top.inc_2} {top.inc_3}} \
-hier_block increment "
# BLOCK LEVEL RUN: out_blk

out_blk:
rm -rf $(CDC_OD)/out_blk
qcdc -c -do "\
onerror {exit 1}; \
configure output directory $(CDC_OD)/out_blk; \
do /home/bobo/cdc_hier/cdc_hier_constraints_out_blk_ctrl.tcl; \
$(CDC_HIER_CMD) \
-hier_instance {{top.out_1} } \
-hier_block out_blk "
# BLOCK LEVEL RUN: sync_blk

sync_blk:
rm -rf $(CDC_OD)/sync_blk
qcdc -c -do "\
onerror {exit 1}; \
configure output directory $(CDC_OD)/sync_blk; \
do /home/bobo/cdc_hier/cdc_hier_constraints_sync_blk_ctrl.tcl; \
$(CDC_HIER_CMD) \
-hier_instance {{top.sync_blk_1} } \
-hier_block sync_blk "
# TOP-LEVEL RUN: top

top:
rm -rf $(CDC_OD)/top
qcdc -c -do "\
onerror {exit 1}; \
configure output directory $(CDC_OD)/top; \
$(CDC_TOP_CMD) -hier_cache \
$(CDC_OD)/increment/qcache \
$(CDC_OD)/out_blk/qcache \
$(CDC_OD)/sync_blk/qcache "

July 2013
CDC Analysis
Waivers
Waivers are instances of clock-domain crossing schemes that are “waived” from reporting.
Waiving scheme instances eliminate the “noise” created by identifying all of the CDC issues
found in the design. By waiving a particular instance of a CDC scheme, you are indicating the
instance is OK (at least for the time being). For example, you might waive an instance of a
missing synchronizer because you know the crossing has no synchronization issues. Each time
you run CDC analysis with waivers identified, only relevant CDC issues are shown in the GUI
CDC Checks window by default, so you do not waste time studying CDC issues that are not
meaningful.
For example, before performing hierarchical CDC analysis, you typically run flat CDC analysis
on the various blocks as they are developed. When you view the results and debug issues, you
typically mark crossings and issues to be waived. These waivers are saved as a CDC control file
from the GUI (sometimes called a waiver file). You can specify this file during later CDC
analysis sessions, to filter out issues already considered.
In a similar way, you can incorporate waivers into the hierarchical CDC flows.
1. After running block-level analysis of a block, run the CDC GUI:

prompt> qcdc outdir/blk1/cdc.db
2. Import the waivers file for the block if you have one: File >Import >Directive File.
Previously-created waivers from the block development stage can be applied to the
hierarchical CDC block-level results.
3. Check the existing specifications for each waived instance of a CDC scheme and add
additional waivers as needed. Since you eventually want to roll the waivers up into top-
level analysis, you must ensure the waivers are properly formed for this purpose. To
waive a CDC scheme instance, select the instance and run Create Directive >Waived.
The Set CDC Report dialog is displayed with information pre-filled (Figure 3-14).
Ensure the following:
• The TX Clock and RX Clock fields are blank. Clock names at the block level do not
match the clock signal names at the top level. When they do not match at the top
level, a warning is reported and the waiver is ignored. So, you must leave these fields
blank.
• The Module field specifies the module/entity name of the block. This field is often
omitted when developing at the block level, but should be specified so the waiver is
recognized at the top level.
• A comment is provided (to document the reason for the waiver).
You can set the other fields as desired. When you apply the dialog, a cdc report -severity
waived directive is added to the Directives window.

July 2013
CDC Analysis
Figure 3-14. Waiving a Block-level Violation
Create Directive >Waived

Remove TX/RX
Clock Names
Pre-filled Dialog
Fields
Add Module
Name
Add Comment
4. Save the waivers to a control file.

Select the waivers directives in the Directives window and run Export from the popup
menu. Select the Selected Directives radio button and specify a name for the CDC
waivers file (for example, waivers_blk1.tcl).
5. Specify the waivers files for the blocks during top-level CDC control file generation:
prompt> qcdc -od outdir -c -do “\
do directives.tcl ; \
do outdir/waivers_blk1.tcl ; \
cdc run -d top -report_constraints blk1 blk2 blk3”
Variations on the Hierarchical CDC Flow

With the basic hierarchical CDC flow, you propagate CDC constraints from the top level to the
blocks, run block-level analyses and then analyze the top-level design. When you load the
results into the CDC GUI, all the CDC checks from the block-level and top-level runs are
merged into the GUI session. Virtually all of the design’s internal logic is available for
debugging operations. So, the basic hierarchical CDC flow produces results and provides a
debug environment just as if you ran the design through flat CDC analysis.

July 2013
CDC Analysis
In addition:
• By “carving up” the analysis problem, memory needed for overall analysis is
significantly reduced.
• Since you can run the various block-level sessions in parallel, end-to-end analysis time
is significantly reduced.
The basic hierarchical CDC flow is based on certain assumptions.
• All instances of each hierarchical CDC block have the same clock domains, port
domains and parameter/generics settings.
• All hierarchical CDC blocks are suitable for block-level CDC analysis.
• You have a top-level design you can use to generate the CDC block constraints.
You can work around these assumptions as described in the following sections.
Heterogeneous Instances of Blocks

Homogeneous instances of a module/entity are instances that have the same configuration (i.e.
the same parameters/generics and connectivity). Heterogeneous instances of a module/entity
are instances that have different configurations. With the basic hierarchical CDC flow described
so far, all instances of each hierarchical CDC block are assumed to be homogeneous.
A variation of the basic hierarchical CDC flow is used to analyze designs whose hierarchical
CDC blocks have heterogeneous instances. When you generate block constraints (phase 1), a
hierarchical constraints file is generated for each specified hierarchical CDC block. For
example:
cdc_hier_constraints_blk1_ctrl.tcl
In this example, all instances of blk1 are homogeneous, all instances of blk2 are homogeneous,
and so on. But, if a block has heterogeneous instances, a hierarchical constraints file is
generated for each homogeneous group of instances of the block. So, if blk1 has two sets of
instances that have different configurations, two hierarchical constraints files are generated:
cdc_hier_constraints_blk1_0_ctrl.tcl
cdc_hier_constraints_blk1_1_ctrl.tcl

July 2013
CDC Analysis
During block-level analysis, each of these instance groups must be analyzed separately. For
example:
prompt> qcdc -od outdir/cdc_hier/blk1_0 -c -do “\

do cdc_hier_constraints_blk1_0_ctrl.tcl \
cdc run -d top -hier_block blk1 -hier_instance top.U1 “
prompt> qcdc -od outdir/cdc_hier/blk1_1 -c -do “\

do cdc_hier_constraints_blk1_1_ctrl.tcl \
cdc run -d top -hier_block blk1 -hier_instance top.U3 “
In this example, blk1 has two heterogeneous groups of instances: (top.U1) and (top.U3). You
must specify the blk1 block with the -hier_block module argument in addition to specifying the
heterogeneous instances with -hier_instance instances arguments. In this example, block-level
analyses of blk1 generate two CDC interface models for use in the top-level analysis:
outdir/cdc_hier/blk1_0/qcache
outdir/cdc_hier/blk1_1/qcache
Tip: The cdc_hier.Makefile script also works for heterogeneous instances of blocks. For
example: make -f cdc_hier.Makefile blk1_0.
When hierarchical blocks are present, cdc.rpt identifies them:
General Design Information

==========================
Number of Black Boxes = 0
Number of Registers = 145
Number of Latches = 0
Number of RAMs = 2
Number of CFM Hierarchical Blocks = 1
Number of ILM Hierarchical Blocks = 1
Number of CDC bits = 82
Detail Design Information

=========================
CFM Hierarchical Blocks:
------------------------
U1 ( blk1 )
ILM Hierarchical Blocks:

------------------------
U2 ( blk2 )

July 2013
CDC Analysis
Control File Models

The basic hierarchical CDC flow uses CDC interface models generated by block-level CDC
analyses (stored in cache directories, for example: cdc_hier/*/qcache). Sometimes, you cannot
generate a CDC interface model for a block (for example, because it has unsynthesizable
constructs). Sometimes you can generate an interface model but it is too large. Sometimes you
simply want to run a quicker top-level analysis as a form of sanity check. Finally, some block
netlists might be eliminated from analysis. In these cases you can swap in a simplified model
called a control file model (CFM) for the top-level analysis session (Figure 3-15).
To generate a control file model during block-level analysis of a block, add the following
hierarchical CDC preference directive to a block-level constraints file:
cdc preference hier -ctrl_file_models
CDC analysis for the block generates both an ILM model and a CFM model (named
cdc_hier_*_ctrl.v). You also can add the directive to the top-level control file in order to
propagate the directive to the block-level analyses via the hierarchical constraints files (during
the report constraints step).
Figure 3-15. Top-level CDC Analysis with CFMs
top-level design ILM top-level violation

V
previously
analyzed blocks
ILM
top-level violation
ILM interface
V
logic model CFM CFM
CFM control
model
file
inter-block violation ILM

ILM
V
ILM
For the blocks that you want to use the control file models, specify the corresponding generated
control files with the -hier_ctrl_file_model option. For example:
0in> cdc -d top -od 0in_hier/top -ctrl top_ctrl.v \

-hier_cache 0in_hier/blk1/0in_cache \
0in_hier/blk2/0in_cache \
-hier_ctrl_file_model blk3 0in_cdc_hier_blk3_ctrl.v

July 2013
CDC Analysis
Here, blk1 and blk2 are modeled as ILMs and blk3 is modeled as a CFM. Never specify both an
ILM and a CFM for the same block. Table 3-6 compares the ILM and CFM models and
Table 3-7 shows the limitations of the control file models.
Table 3-6. ILMs vs. CFMs

Feature Interface Logic Model Control File Model
data structure Internal interface logic model Control file.
saved in a block-level cache.
efficacy Results are equivalent to Some CDC schemes might be
standard (flat) CDC analysis. missed.
user control User can limit the depth of CDC User can edit the control file.
analysis.
granularity Blocks can be modules/entities Blocks can be
and instances. modules/entities, but not
instances.
Table 3-7. Control File Model Limitations

Feature Limitation
non-default parameters Separate parameter sets for different instances of the block are
not supported. CDC analysis uses the default parameter values
for the block.
reconvergence Reconvergence violations starting from or ending in the block are
not reported.
input port fanout Fanout data in the block is discarded, so CDC reports only one
crossing to an input port of the block when multiple crossings
through the port fan out to multiple receivers.
promoted checkers Number of promoted CDC protocol and CDC-FX checkers can
differ between hierarchical and standard analysis.
complex schemes Multibit (data) synchronizers are not supported. DMUX is the
only complex (nested) scheme detected. However, basic schemes
such as control and bit synchronizers are supported.
netlist constant Slices and bits in the block are not supported for netlist constant.
combinational logic If the combinational logic driving a block’s output port includes
across block paths an input port of the block, you should set the port domain of that
input port. If you set the port domain to -ignore, you might miss
top-level crossings involving the combinational logic paths
through the block.

July 2013
CDC Analysis
CDC Analysis of FPGAs

CDC analysis of an FPGA design requires special handling. The standard FPGA source
libraries are designed for simulation and in particular, they are not completely synthesizable.
Synthesizable libraries are needed because CDC analysis (unlike simulation) is based on a
netlist of the design. Building a netlist requires synthesizable code for compiling the design and
for compiling the FPGA source libraries.
Questa CDC/Formal distribution software comes with synthesizable versions of the

unisim/simprim Xilinx and the Altera source libraries in <install_dir>/share/fpga_libs.
Included in the Xilinx and Altera subdirectories of fpga_libs are Makefiles and control files for
running the flows described in the following sections.
Phase 1: Compiling the FPGA Source Libraries

If you have compiled your FPGA source libraries already for Questa simulation, you can use
them for CDC analysis if:
• The libraries’ RTL is synthesizable VHDL, Verilog or SystemVerilog code.

• The libraries were compiled using the versions of Questa vcom/vlog commands that
match those shipped with the Questa CDC/Formal distribution software.
If these statements are true, skip to Phase 2. If not, compile the FPGA source libraries into
resource libraries. First create a directory to hold the compiled FPGA resource libraries:
prompt> mkdir qstatic_libs
Then, set up and compile the FPGA source libraries as illustrated in the following examples. If
FPGA library elements are instantiated in VHDL code, you must compile a resource library for
that. The logical library name for this library has no _ver suffix. If FPGA library elements are
instantiated in Verilog code, you must compile a resource library for that. The logical library
name for this library has a _ver suffix.
Xilinx
• unisim
Used for library elements instantiated in VHDL. Compile the VHDL files containing the
component and package declarations from the standard Xilinx simulation library. Then
compile the synthesizable Verilog models of the library. The vlog -convertallparams
option is needed to convert the Verilog parameters to match the generics types in the
VHDL component definitions.
vlib qstatic_libs/unisim
vmap unisim qstatic_libs/unisim
vcom -work unisim $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd
vcom -work unisim $XILINX/vhdl/src/unisims/unisim_VPKG.vhd
vlog -work unisim -convertallparams \

July 2013
CDC Analysis
install_dir/share/fpga_libs/Xilinx/ISE/xeclib/unisims/*.v
• unisims_ver
Used for library elements instantiated in Verilog. Compile the synthesizable Verilog
models of the Xilinx library.
vlib qstatic_libs/unisims_ver
vmap unisims_ver qstatic_libs/unisims_ver
vlog -work unisims_ver \
install_dir/share/fpga_libs/Xilinx/ISE/xeclib/unisims/*.v
• simprim
component and package declarations from the standard Xilinx simulation library. Then
compile the synthesizable Verilog models of the library. The vlog -convertallparams
option is needed to convert the Verilog parameters to match the generics types in the
VHDL component definitions.
vlib qstatic_libs/simprim
vmap simprim qstatic_libs/simprim
vcom -work simprim $XILINX/vhdl/src/simprims/simprim_Vcomponents.vhd
vcom -work simprim $XILINX/vhdl/src/simprims/simprim_Vpackage.vhd
vlog -work simprim -convertallparams \
install_dir/share/fpga_libs/Xilinx/ISE/xeclib/simprims/*.v
• simprims_ver
models of the Xilinx library.
vlib qstatic_libs/simprims_ver
vmap simprims_ver qstatic_libs/simprims_ver
vlog -work simprims_ver \
install_dir/share/fpga_libs/Xilinx/ISE/xeclib/simprims/*.v
• XilinxCoreLib
Used for library elements instantiated in VHDL. First, run xilinxcorelib_compile.do to
create a filelist (xilinxcorelib_vhdl_analyze_order.f) that specifies the synthesizable
files in the correct compilation order. This script adds $XILINX/vhdl/src/XilinxCoreLib/
to the file names in the source file compile list. Next, compile the VHDL simulation
library files.
vlib qstatic_libs/XilinxCoreLib
vmap XilinxCoreLib qstatic_libs/XilinxCoreLib
vcom -work XilinxCoreLib -f xilinxcorelib_vhdl_analyze_order.f

July 2013
CDC Analysis
• XilinxCoreLib_ver
Used for library elements instantiated in Verilog. Compile the Verilog simulation library
files.
vlib qstatic_libs/XilinxCoreLib_ver
vmap XilinxCoreLib_ver qstatic_libs/XilinxCoreLib_ver
vlog -work XilinxCoreLib_ver $XILINX/verilog/src/XilinxCoreLib/*.v
Altera
If FPGA library elements are instantiated in VHDL code, you must compile a resource library
for that. The logical library name for this library has no _ver suffix. If FPGA library elements
are instantiated in Verilog code, you must compile a resource library for that. The logical library
name for this library has a _ver suffix.
• altera_mf
component and package declarations from the standard Altera simulation library. Then
compile the synthesizable Verilog models of the library. The vlog +incdir argument is
the include directory for the source files.
vlib qstatic_libs/altera_mf
vmap altera_mf qstatic_libs/altera_mf
vcom -work altera_mf \
$QUARTUS_ROOTDIR/eda/sim_lib/altera_mf_components.vhd
vlog -work altera_mf \
install_dir/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \
+incdir+install_dir/share/fpga_libs/Altera/quartus/fv_lib/verilog
• altera_mf_ver
models of the Altera library. The vlog +incdir argument is the include directory for the
source files.
vlib qstatic_libs/altera_mf_ver
vmap altera_mf_ver qstatic_libs/altera_mf_ver
vlog -work altera_mf_ver \
install_dir/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \
+incdir+install_dir/share/fpga_libs/Altera/quartus/fv_lib/verilog

July 2013
CDC Analysis
Logical-physical Library Mappings

The vmap command creates a logical-to-physical library mapping. For example, in the previous
examples, vmap mapped the logical name altera_mf to the physical location
qstatic_libs/altera_mf. The command also updates the modelsim.ini file with the logical-
physical mapping. The command creates a new modelsim.ini file if one does not exist. This
example shows the library mappings for a VHDL-only Xilinx design:
[Library]
unisim = ./qstatic_libs/unisim
XilinxCoreLib = ./qstatic_libs/XilinxCoreLib
work = ./qstatic_libs/work
Phase 2: Compiling the Design

You likely have created one or more filelists that identify the source code files for your design.
The files within each individual library must be compiled in the correct order. Also, different
libraries that depend on each other must be compiled in the correct order. Using filelists from
simulation handles this.
With the filelists (or filelists) for your design, run the design compilation commands. The
following example compiles a VHDL-2002 design into the work library.
vlib qstatic_libs/work
vmap work qstatic_libs/work
vcom -f vhdl_files.list -work work -skipsynthoffregion
The -skipsynthoffregion argument directs the compiler to obey synthesis-off regions. These are
regions of code surrounded by synthesis_off/synthesis_on (or translate_off/translate_on)
pragmas. The compiler parses this code to pick up declarations, but otherwise ignores it. One
reason to use -skipsynthoffregion is to ignore VHDL library and use statements for libraries
needed for simulation only.
Rather than using a filelist to compile files with one invocation, you can set up a script to
compile the file one-by-one:
vcom vhdl_file1.vhd -work work

vcom vhdl_file2.vhd -work work
vcom vhdl_file3.vhd -work work -skipsynthoffregion
The following example shows the compiler invocation for a Verilog design:
vlog -f verilog_files.list -work work +incdir+src/verilog
Phase 3: Compiling a CDC Model of the Design

The target design is the top-level block for CDC analysis. This can be a VHDL entity (or
configuration) or a Verilog module. The -d <design> argument to the cdc run command is a
required argument that identifies the target design.

July 2013
CDC Analysis
Once the FPGA resource libraries and the design library have been compiled, you can compile
the CDC logic model using the cdc run command. Here are two examples:
cdc run -d DUT_top -work work
Compiles the target design DUT_top from work using libraries mapped in ./modelsim.ini
(the default mapping file).
cdc run -d DUT_top -work top_lib -modelsimini LibraryMapping.0in
Compiles the target design DUT_top from top_lib using libraries mapped in
LibraryMapping.0in.
Tip: Running cdc run on a design can take time. Initial qcdc sessions are used only to
refine the clock domain model of the design in preparation for analyzing the CDC logic.
The cdc run command’s -report_clock option short-circuits the complete cdc run analysis
and stops after identifying the clock domain model characteristics. You use this option
initially to ensure that the clocks and clock groups are identified correctly before
performing complete compilation of the CDC logic.
Use the following steps to compile a CDC model of the design.
1. Set up the directive files.

A directives file is a Tcl-based file of Questa Static directives. Directives set up
operating conditions, define clocks, define black boxes, specify custom synchronizers,
modify reported results, create waivers, and so on. You apply significant effort creating
and adjusting the directives files because this is how you fine tune CDC analysis. Here is
an example:
netlist constant scan_mode ’0’
netlist clock CLK_1 -group clk_grp_A -period 4
netlist clock CLK_2 -group clk_grp_A -period 8
netlist clock CLK_3 -group clk_grp_B -period 11
netlist port domain input_port1 -async
netlist port domain input_port2 -clock CLK_1
netlist port domain -output -clock CLK_2
netlist blackbox syncA* cdi_master
cdc preference -black_box_empty_module
In addition to standard CDC directives, the following directives are particularly useful
for CDC analysis of FPGA designs.
netlist constant
Applies a constant value to input ports (and sometimes to internal nodes) so the cdc
compiler can prune irrelevant logic from the design logic and the CDC model. This

July 2013
CDC Analysis
technique makes the memory footprint smaller, improves performance and ensures
only relevant results are returned.
cdc reconvergence
Sets the sequential levels that define how deep paths diverge and reconverge to be
considered instances of reconvergence and single_source_reconvergence schemes.
The deeper the analysis, the greater the decrease in performance. Initially, set the
reconvergence depth to 1 and the divergence depth to 1.
netlist blackbox
Identifies specific modules/entities/architectures as user-defined black boxes. Use
netlist port domain directives to identify the clock domains for the black boxes’
ports (even asynchronous ones) so the logic outside the black box instances can be
analyzed properly. Fanin/fanout logic of ports of user-defined black box instances
that are not assigned port domains is ignored for CDC analysis.
cdc preference -black_box_empty_module
Turns empty modules/entities/architectures into inferred black boxes instead of
treating them as regular models. Some elements in a synthesizable FPGA library are
“stubs” containing only the port declarations. Specifying the
-black_box_empty_module option makes it easier to identify these elements so you
can add netlist port domain directives for their ports.
Tip: Hierarchical paths always appear in the report files with “.” separators (which might
be different from the path separator reported by simulation). Use these exact paths in the
control files as well. When creating control directives that refer to specific signals in the
RTL, cut and paste the exact pathnames from the report files or GUI.
2. Run cdc run in report-clocks mode.

For example:
prompt> qcdc -c -do “ \
onerror {exit 1} ; \
do cdc_directives.do ; \
configure error -inferred black_box ; \
cdc run -report_clock -d DUT_top -work work ; \
exit 0”

July 2013
CDC Analysis
The command performs clock analysis and stops. Check the results:
a. Check cdc_run.log for errors:
Error/Warning Summary
-----------------------------------------------------------
Count Type Message ID Summary
-----------------------------------------------------------
1 Error command-188 Design elaboration failed.
1 Error command-195 Design Elaboration (Child process) returned a
non zero status.
1 Error parser-284 Vopt error.
Each error/warning is explicitly described in cdc.log. Fix any issues, then rerun
design compilation (if the source code changed) and cdc -report_clock.
b. Check the clock groupings in cdc.rpt.
Clock Group Summary for 'demo_top'
==================================
Total Number of Clock Groups : 4
1. User-Specified :(3)
2. Inferred :(0)
2.1 Primary : 0
2.2 Undriven : 0
2.3 Blackbox : 0
2.4 Gated Mux : 0
2.5 Gated Combo : 0
3. Ignored :(1)
=================================================================
1. User-Specified (3)
=================================================================
Group 0(148 Register Bits, 0 Latch Bits)
-----------
mac_clk_in
-----------
core_clk_in
-----------
check_en (unused clock)
check_en_r1 (unused clock)
=================================================================
2. Inferred (0)
=================================================================
2.1 Primary (0)
-----------------------------------------------------------------
None
2.2 Blackbox (0)
-----------------------------------------------------------------
None
2.3 Undriven (0)
-----------------------------------------------------------------
None
2.4 Gated Mux (0)
-----------------------------------------------------------------
None

July 2013
CDC Analysis
2.5 Gated Combo (0)

-----------------------------------------------------------------
None
=================================================================
3. Ignored(1)
=================================================================
-----------
cpu_clk_in
Synchronous clocks should be grouped together. Clocks in different groups are

assumed to be asynchronous and therefore require synchronization on signals that
traverse storage elements in different clock domains. CDC analysis results are not
meaningful until the clocks are set up correctly (see “Clock Tree Detection” on
page 85).
3. Run cdc run.
For example:
prompt> qcdc -c -do “ \
onerror {exit 1} ; \
do cdc_directives.do ; \
configure error -inferred black_box ;\
cdc run -report_clock -d DUT_top -work work ; \
exit 0”
The command performs clock analysis, compiles the CDC model of the design, runs
CDC analysis, generates reports on the results and generates a database file to load into
the CDC GUI for debugging issues found by static CDC analysis. Among the files
generated by cdc:
• cdc.db — .db database of the CDC results for loading into the CDC GUI.
• cdc.rpt — Text report containing CDC results.
• cdc_design.rpt — Text report containing results of clock and design analysis
4. Check the cdc_design.rpt again.
a. Check the port domains:
Port Domain Information
=======================
Port Direction Constraints Clock Domain Type
-------------------------------------------------------------------
clk input Clock Bus {clk[1]} Questa CDC
rst input Reset {clk[1]} Questa CDC
in1 input {clk[0]} User
out1 output {clk[1]} Questa CDC
out2 output {clk[1]} Questa CDC
Check the inferred port domains (clock domains assigned to the ports). By default,
each input port is assigned to the clock domain of its first fan-in register. Any

July 2013
CDC Analysis
primary inputs or outputs that connect to multiple clock domains or are not assigned
to a clock domain are listed. Use netlist port domain directives to make adjustments.
b. Check for black boxes.
Black Boxes:
------------
Module Instance Count File (Line)
-------------------------------------------------------------------
cdi_master 1 /home/cdc/blackbox/cdi_master.v (2)
Internal logic of the black boxes is unknown and in particular, the connectivity
between a black box’s inputs and outputs is unknown. So, black boxes can mask
some CDC problems. Check that the port domains of the user-defined black boxes
(black_box in the report) are all specified.
VITAL models, FPGA library elements that are not synthesizable and design blocks
with unsynthesizable constructs are inferred black boxes (inferred in the report),
unless explicitly specified with netlist blackbox directives. Check the inferred black
boxes in cdc.rpt. If an inferred black box affects CDC results, at least one associated
black box CDC scheme is reported:
Black Box Crossing. (black_box)
-----------------------------------------------------------------
tx_clk: start: tx_sig2 (/u/zin/black_box/dut.v : 25)
<clock N/A>: end: dut.Di2 (/u/zin/dut.v: 40)(ID:black_box_12944)
You can declare the black box as a user-defined black box (with netlist blackbox)
and specify the port domains for the black box’s I/O ports (with netlist port domain).
The following example directives do this for an Altera dual-port RAM block:
netlist blackbox altdpram
netlist port domain wren -clock inclock -module altdpram
netlist port domain data -clock inclock -module altdpram
netlist port domain wraddress -clock inclock -module altdpram
netlist port domain wraddressstall -clock inclock -module altdpram
netlist port domain inclocken -clock inclock -module altdpram
netlist port domain byteena -clock inclock -module altdpram
netlist port domain rden -clock outclock -module altdpram
netlist port domain rdaddress -clock outclock -module altdpram
netlist port domain rdaddressstall -clock outclock -module altdpram
netlist port domain outclocken -clock outclock -module altdpram
netlist port domain q -clock outclock -module altdpram
netlist port domain aclr -async -module altdpram
You might be able to obtain or write synthesizable models of various black boxed
elements. For example, using the Xilinx CoreGen tool: run Project >Project Options;
select the Generation tab; and set Simulation Files: Structural. Structural models are
synthesizable. Be sure to keep the structural models and behavioral models in different
locations to prevent overwriting previously-generated files.

July 2013
CDC Analysis
Phase 4: Running GUI Debug

To run qcdc in GUI mode, specify the CDC results database as the only argument:
prompt> qcdc cdc.db
At this point, debugging CDC issues with the CDC GUI is the same for FPGA-based design as
it is with other designs. As you analyze the CDC results, you will find RTL issues to fix, to
waive and to filter out. You might want to add or change directives in your control file to:
• Adjust clock configurations (netlist clock)

• Set clock domains of I/O ports (netlist port domain)
• Declare custom synchronizers (cdc synchronizer)
• Define characteristics of certain signals in the design (cdc signal)
• Reclassify the results (cdc report)

July 2013
CDC Analysis

July 2013
Chapter 4
CDC-FX Metastability Injection
Metastability injected simulation is an extension to normal RTL simulation that injects random
metastability into the circuit’s behavior. CDC-FX metastability injected simulation is similar to
simulation with assertions. But, it uses special CDC-FX checkers to inject metastability into the
circuit during simulation. These checkers also monitor the metastability logic and report
coverage of metastability effects during simulation.

July 2013
Specifying Metastability Windows

The metastability windows indicate the transmit/receive clock edge relations that determines
when metastability can occur. They are specified to the cdc -compile_assertions command
using the cdcfx metastability window directive. This directive sets the metastability window for
the CDC-FX clocks.
Setup and Hold Periods

Figure 4-1 shows setup and hold time periods around a register’s clock edge along with sample
waveforms for an input to the register(s). The input signal is stable if it is held at a constant 0 or
1 value during the setup and hold periods. The signal is unstable if it changes during these
periods. If the signal input to a register is unstable, then the register can become metastable.
Figure 4-1. Setup and Hold Times for a Register Input

tsetup thold
rx_clk
s stable
s unstable
s unstable
s stable
Metastability Windows
The setup and hold times determine receive clock cycles for which a register can become
metastable—based on the active edge of the receive clock and the value of the signal at the
input port of the register. In hardware, however, this input port switches value after the output
port driving the signal (in the transmit clock domain) switches and the new value propagates to
the input port (in the receive clock domain). This propagation delay (tprop) has the following
physical bounds:
min tprop ≤ tprop ≤ max tprop
Accounting for propagation delay identifies a metastability window relative to each active edge
of the receive clock, as shown in Figure 4-2. A metastability window defined this way assumes
the worst case events as follows:
• CDC signal propagates as slowly as possible (max tprop) and violates the setup time
(tsetup).
• CDC signal propagates as quickly as possible (min tprop) and violates the hold time
(thold).

July 2013
Figure 4-2. Metastability Window

tsetup thold
max tprop
rx_clk
min tprop
start metastability window

stop
start = tsetup - max tprop stop = thold - min tprop
The start value is the number of time units before the active edge of the receive clock that the
metastability window “opens.” The stop value is the number of time units after the active edge
of the receive clock that the metastability window “closes.”
Metastability Windows Usage

Note the following information about metastability windows:
• Except for the default case, the metastability windows are not set automatically by
software. The user sets up metastability windows based on the knowledge of the
hardware technology and characteristics of the design by specifying their start and stop
values. However, the user does not need to specify setup/hold times or propagation
delay ranges.
• Each pair of transmit/receive clocks has its own metastability window (either specified
or default). In particular, a receive clock might have multiple windows.
• If the duration of a metastability window is sufficiently large, then every active edge of
the corresponding transmit clock falls inside the window. In this case, simulation with
metastability injectors randomly inserts metastability effects every clock cycle the
register changes value.
• A common metastability verification methodology is to start with large metastability
windows (for example, the default case). Then, successively narrow the windows and
focus analysis on select CDC paths. This way the user can analyze the worst case
scenario (so no bugs might be missed). Then, after eliminating “false” violations, the
user can identify real problems caused by metastability intolerance.
• Metastability windows are used for metastability injected simulation. They have no
counterpart in hardware. In hardware, a changing CDC signal either does or does not
result in the receive register going metastable, and the hardware value either does or
does not agree with the value used in plain simulation.

July 2013
clks_aligned[65:0]
When the assertion compiler instantiates a cdc_fx checker, it also creates clock monitor logic
that determines when the transmit clock is within the metastability window of the receive clock
(for that transmit clock). Whenever this occurs, the receive register is prone to metastability if
its input value also changes in that receive clock cycle. The clks_aligned output from the clock
monitor is used to pass this information to the cdc_fx checker.
The clks_aligned output is a 66-bit value that is 0 throughout “normal” cycles. When the clock
monitor detects an active transmit clock edge in the corresponding metastability window of the
receive clock edge, one of the clks_aligned bits asserts a pulse that begins at the second active
clock edge and stops at the first subsequent inactive clock edge (see Figure 4-3).
Note the following:
• clks_aligned[0] — 1 if tx_clk is before rx_clk.

• clks_aligned[1] — 1 if tx_clk is after rx_clk.
• clks_aligned[33:2] — metastability window start time.
• clks_aligned[65:34] — metastability window stop time.
Figure 4-3. clks_aligned Input to the cdc_fx Checker
Clocks not aligned.

clks_aligned 0
tx_clk
rx_clk
metastability window
Clocks aligned. Transmit clock edge before (or at) receive clock edge.
clks_aligned[0]
tx_clk
rx_clk
Clocks aligned. Receive clock edge before transmit clock edge.

clks_aligned[1]
tx_clk
rx_clk

July 2013
cdcfx fx window
The cdcfx metastability window directive specifies a metastability window for one or more
receive register clocks. This directive is used by the cdc -compile_assertions command.
cdcfx fx window
-start value -stop value [-tx_clock clock_signal] [-rx_clock clock_signal] [-percent]
Unless the directive include the -percent option, the -start and -stop values specify metastability
using directional time units as follows:
• The -start value is the number of time units before the active receive clock edge that the
associated metastability window opens.
• The -stop value is the number of time units after the active receive clock edge that the
associated metastability window closes.
If -percent is specified, the -start and -stop values instead are percentages of the receive clock
duty cycle.
If the directive specifies -tx_clock and -rx_clock, then the directive applies to cdc_fx checkers
with these clock pairs. If the directive omits -tx_clock and -rx_clock, then the directive applies
to the remaining cdc_fx checkers. It is an error to specify more than one directive without the -
tx_clock and -rx_clock arguments.
If no cdcfx metastability window directive is specified, then the special default case described in
the next section is followed. However, if at least one cdcfx metastability window directive is
specified, then the “default” metastability window configuration has a duration set to 0. In this
case, the cdc_fx checkers not covered by explicit cdcfx metastability window directives never
inject metastability. Their cdc_fx checks never fire.
Note the following:
• The -tx_clock and -rx_clock arguments do not allow wildcards.

• The cdcfx metastability window directive does not support bussed clocks.
Special Default Case

If a cdcfx metastability window directive is not specified for a CDC crossing, then the (default)
metastability window is set as follows (see Figure 4-4):
• The start time is 25% of the receive clock cycle before the receive clock edge.
• The stop time is 10% of the receive clock cycle after the receive clock edge.

July 2013
Figure 4-4. Metastability Window Default

tsetup thold
rx_clk
start = 25% stop = 10%

clock period
default
metastability
window
For example, if rx_clk has period 100 time units, then the default metastability window is the
same as the window set by the following:
cdcfx metastability window

-start 25 –stop 10 -tx_clock tx_clk -rx_clock rx_clk

July 2013
Running CDC-FX
Running CDC-FX
The metastability injectors (cdc_fx checkers and metastability detection logic) are instantiated
from cdc_fx checker directives (Figure 4-5).
Figure 4-5. CDC Data Flow for Simulation with Metastability

CDC-FX control file
(with cdcfx check directives)
cdc -fx
0in_cdc_fx_sim_ctrl.v
edit
design checker
files control
files
ccl
CDC-FX control file

(with cdcfx metastability window directives)
simulation with
metastability
Figure 4-5 also shows that part of the data preparation for the CDC-FX analysis is to set up an
optional CDC-FX control file that contains the cdcfx metastability window directives used to set
the metastability windows for the cdc_fx checkers.
cdcfx check
The cdcfx check directive turns on specified checks in corresponding cdc_fx checker directives
promoted by the cdc -fx command.
cdcfx check
[-scheme scheme] [-tx_clock clock_signal] [-rx_clock clock_signal] [-fx]
[-glitch_swallowed] [-glitch_caught]
By default, the glitch_swallowed and glitch_caught checks are off. The cdc_fx checks are on for
multi_bits, dmux, simple_dmux, multi_sync_mux_select, handshake and no_sync schemes;
cdc_fx checks are off for all other schemes.
Use the cdcfx check directive to force cdc -fx to turn on cdc_fx checkers’ checks. The user must
specify at least one check to turn on (-fx, -glitch_caught, or
-glitch_ swallowed). The -tx_clock option restricts the directive to those cdc_fx checkers with
the specified transmit clock. The -rx_clock option restricts the directive to those cdc_fx checkers
with the specified receive clock. The -scheme option restricts the directive to those cdc_fx
checkers connected to synchronizers of the specified type. The cdcfx check directive does not
support wildcards.

July 2013
Running CDC-FX
CDC-FX Checker Promotion

Table 4-1 shows the CDC schemes that promote cdc_fx checkers.
Table 4-1. CDC Schemes and cdc_fx Checker Promotion
Promote cdc_fx Checkers Do Not Promote cdc_fx Checkers
bus_dff_sync_gated_clk handshake async_reset
bus_four_latch multi_bits async_reset_no_sync
bus_shift_reg multi_sync_mux_select black_box
bus_two_dff no_sync clock_no_sync
bus_two_dff_phase pulse_sync custom_sync
combo_logic shift_reg custom_sync_no_sync
dff_sync_gated_clk simple_dmux custom_sync_with_crossing
dmux two_dff bus_custom_sync
fanin_different_clks two_dff_phase bus_custom_sync_no_sync
four_latch port_constraint_mismatch
reconvergence
redundant
series_redundant
single_source_reconvergence
The following situations can cause a cdc_fx checker not to be promoted, or to be promoted with
partial information:
• Individual signals from multibit registers.

• Signals from registers with different transmit clocks fan into a receive register.
• The tx_reg or rx_reg register is a latch.
• The tx_reg or rx_reg register is not a real register and custom_fx is not on. For example,
it is a memory or FIFO.
• The tx_clk or rx_clk is missing. For example, the transmit register is an asynchronous
input port.
• There are latches between tx_reg and rx_reg.
• Promotions are turned off.
• Clock logic for one of the clocks has a UDP.
• RX logic uses a custom synchronizer.

July 2013
Running Metastability-injected Simulation

Metastability-injected simulation uses the same flow as simulation with protocol checkers. The
-compile_assertions option to the cdc command compiles the metastability injection logic and
sets up the arguments needed to run metastability-injected simulation (Figure 4-6).
Figure 4-6. Metastability-injected Simulation
vcom/vlog
design
files
cdc
-compile_assertions -work library
control vsim
files -f 0in_cdc_sim.arg
-f 0in_cdc_sim_vhdl.arg
merge
vcom/vlog cdc_sim.db
qcdc
GUI
vcom/vlog debugging
testbench environment
files
Results from metastability-injected simulation can be merged back into the CDC GUI for
review and debugging. The following procedure uses the Questa vsim simulator.
1. Set up the design library and compile the design.

For example:
prompt> vlib work
prompt> vcom dut.vhdl

Specify the -compile_assertions and -fx so cdc generates the information used to
compile the metastability injection logic. For example:
cdc -d dut -ctrl dut_ctrl.v -compile_assertions -fx

July 2013
3. Compile the CDC-FX metastability injection logic.

Specify the simulation arguments files generated by cdc. For example:
4. Compile the testbench.

prompt> vlog tb.v
5. Run simulation.
Specify the PLI library path for the simulator and the vsim arguments files. For example:
6. Run the CDC GUI.

Load the cdc_sim.db database generated by vsim. This database contains the merged
data from static CDC analysis and simultion with protocol assertions and CDC_FX
analysis.
prompt> qcdc cdc_sim.db
Simulation Arguments
The user can use simulation arguments to suppress metastability injection during simulation
(for individual CDC signals or all CDC signals) and to set the seed for random metastability
injection. The cdc_fx checkers maintain statistics, but metastability is not injected into
simulation.
+0in_suppress_fx_name+name
To suppress metastability injection during simulation for individual signals, specify them with
simulation arguments of the following form:
+0in_suppress_fx_name{+name}…
Here, name is the cdc_fx checker name. Wildcards can be used in name. For example,
+0in_suppress_fx_name+tx4_*+tx_data
+0in_disable_fx_force
To suppress metastability injection for all individual signals, specify the following argument:
+0in_disable_fx_force

July 2013
Refer to “Verilog Glue Logic Option Impact” on page 138 and “VHDL Glue Logic Option
Impact” on page 139 for additional information.
+0in_random_seed+n
To set the random generator seed for random metastability injection, specify the following
simulation argument:
+0in_random_seed+n
Here, n is a positive (32-bit decimal) integer to use as the seed for the random number
generator. Default: 11449.
CDC-FX PLI Functions

Testbenches can include PLI function calls that dynamically control the operation of the
metastability injectors.
Note that you cannot use $0in_checker_on/$0in_checker_off or any other PLI call at time 0. In
fact, it is recommended that you do not invoke any PLI call before #100 after beginning
simulation.
$0in_always_invert_metastable_signals ();
Inverts signals when they are metastable.
$0in_never_invert_metastable_signals ();
Leaves the cdc_fx checkers active, but disables metastability injection.
$0in_randomly_invert_metastable_signals ();
Randomly injects metastability into CDC signals when they are metastable. This is the default
behavior.

July 2013
Verilog Glue Logic Option Impact

The differences between the following options for Verilog glue logic are described in this
section:
• ZI_NO_CDC_FORCE
• +0in_disable_fx_force
• $0in_never_invert_metastable_signals
The Verilog glue logic is as follows:
initial
begin
ìfdef ZI_NO_CDC_FORCE
èlse
if (!($test$plusargs("0in_disable_fx_force")))
begin
force ìnt_prefix_0in.U1.U12.dout = zin_wire_sg_0; end èndif
end
The options have the following impact.
ZI_NO_CDC_FORCE Option
This option can only be used during compiling the design. It permanently removes the force
statement. For example,
% vlog +define+ZI_NO_CDC_FORCE test.v
or
% vcs +define+ZI_NO_CDC_FORCE test.v
+0in_disable_fx_force Option
This option can only be used during simulation. It disables the force statements for that specific
simulation run. For example,
% vsim tb \
+0in_disable_fx_force \
-f 0in_sim.arg.vsim \
-pli install_dir/lib/lib0InLoadMTIPLI.so
or
% ./simv +0in_disable_fx_force

July 2013
$0in_never_invert_metastable_signals Option
This option does not impact the force statements. It only changes the random number generator
during simulation to always produce 0. Hence, the forced values are supposed to be identical to
the original values.
The glue logic can produce data values different from the original RTL specially for Xs. Hence,
this option can result in change in simulation behavior.
Sometimes a customer uses the $0in_never_invert_metastable_signals option while the chip is

loading the configuration registers. During this phase, the users has external circuitry to ensure
that the different clocks are in sync. Next, the user enables CDC-FX by calling the
$0in_randomly_invert_metastable_signals option. Also, the user has the
$0in_always_invert_metastable_signals option to get better coverage if the number of
metastable cycles is limited in the testbench.
VHDL Glue Logic Option Impact

The differences between the following options for VHDL glue logic are described in this
section:
• ZI_NO_CDC_FORCE
• +0in_disable_fx_force
• $0in_never_invert_metastable_signals
The VHDL glue logic is as follows:
module zi_xmr_wrap;
ìfdef ZI_NO_CDC_FORCE
èlse
zi_cdc_fx_force_sigs_0_entity #(.prefix("/tb/U1")) i1(); èndif
endmodule
The options have the following impact.
ZI_NO_CDC_FORCE Option
Same behavior as Verilog (see “ZI_NO_CDC_FORCE Option” on page 138).
+0in_disable_fx_force Option
No impact for VHDL.
$0in_never_invert_metastable_signals Option
Same behavior as Verilog (see “$0in_never_invert_metastable_signals Option” on page 139).

July 2013
Metastability Injector Simulation Methodology

Metastability injectors in simulation uncover problems that arise from CDC metastability
effects. These problems cannot be detected with basic simulation. Therefore, use the following
methodology:
1. Start with a “clean” design.

o End-to-end tests run completely, without errors.
o If the design is instrumented with assertions, then plain simulation with assertions
does not violate any assertions.
2. Run metastability injected simulation.
3. Use the qcdc database viewer to analyze the results.
o End-to-end test errors indicate receive logic is not tolerant of CDC metastability
effects.
o Assertion failures indicate receive logic is not tolerant of CDC metastability effects.
o The cdc_fx checker coverage shows how completely each metastability injector
covers the range of metastability effects during simulation.
4. If needed, suppress some checkers and rerun metastability injected simulation.
5. Debug any cdc_fx checker firings. The cdc_fx checker has three transfer protocol checks
that by default are turned off.
o The cdc_fx check ensures that the data input to the receive register does not change
in a cycle for which the transmit/receive clock edges align (that is, metastability is
not possible for the corresponding register). The generated cdc_fx directives for the
CDC data buses are automatically included by the tool.
o The glitch_caught check ensures that metastability injection does not catch a glitch
if it is not detected by simulation.
o The glitch_swallowed check ensures that metastability injection does not swallow a
glitch if it is detected by simulation.
Assertion Violations
If metastability injected simulation produces assertion violations (i.e., check firings), then you
can analyze them the same as you do firings from basic simulation with assertions (see
Figure 4-7 on page 141). Use the qcdc viewer to examine details of the check firings and to
display their waveforms. These violations are caused by design defects in the fan-outs of the
receiving registers that make the circuit intolerant of random delays in the transmission of their
driving CDC signals.

July 2013
Figure 4-7. CDC GUI with Merged CDC_FX Results
The cdc_fx checker entries in the .db database provide a variety of information about the
metastability injectors during simulation.
Each cdc_fx checker maintains coverage information about its performance during simulation.
The checker entry in the simulation database (checksim.db) has this information.
The cdc_fx checker’s cdc_fx check fires if the active edge of the transmit clock is in the
metastability window of the receive clock and the transmit data change in this window. These
cycles are candidates for metastability injection. The Metastable Cycles evaluation statistic
increments each cycle this happens. Normally, this is not problematic. The logic in the fan-out
of the receive register is expected to tolerate this situation.
Some design styles have transmitting circuitry that presumes data is stable during cycles when
both clock edges occur in the metastability window. No metastability can occur and the
receiving logic does not need to account for CDC metastability effects. In such cases, you can
use the cdc_fx check to verify the transmit data remains stable when metastability can occur.
Notice in the Checker Report that the -rx_q field identifies the register output from the original
circuit that is replaced in the new circuit (remodeled with the metastability injection logic) with
the rx_q output from the checker. When ccl compiles the design for simulation, each cdc_fx
checker is connected so the output from the transmit register is routed to the cdc_fx checker and
the rx_q output from the checker drives the load from the original receive register.
For most cycles, the transmit data is latched by the checker and passed through to the rx_q
output when the receive clock activates. This mimics the behavior of the original circuit under
normal simulation. But, when the checker determines it should inject metastability, randomly
selected bits of the rx_q output are inverted. The rx_q output reflects a corrupted value
unrelated to the original transmission. This condition emulates data transmission metastability
from crossing clock domains. The circuit must be immune to these effects.

July 2013

July 2013
Chapter 5
Reference
This command reference consists of five sections:
• CDC Schemes
• Control: two_dff, two_dff_phase, four_latch, pulse_sync, shift_reg,
dff_sync_gated_clk, clock_no_sync, custom_sync, custom_sync_no_sync,
async_reset, async_reset_no_sync and no_sync.
• Data: bus_two_dff, bus_two_dff_phase, bus_four_latch, bus_dff_sync_gated_clk,
bus_shift_reg, bus_custom_sync, bus_custom_sync_no_sync and multi_bits.
• Control/data: dmux, simple_dmux, forward_simple_dmux, and_gate_dmux,
mux_lock_dmux multi_sync_mux_select, handshake, fifo, fifo_memory,
fifo_memory_ptr_mismatch,fifo_ptr_no_sync, and custom_sync_with_crossing.
• Potential problems: combo_logic, clock_no_sync, port_constraint_mismatch,
reconvergence, single_source_reconvergence, redundant, series_redundant,
fanin_different_clks and black_box.
• Protocol/FX Checkers
CDC protocol checkers: cdc_dsel, cdc_fifo, cdc_glitch, cdc_hamming_distance_one,
cdc_handshake_data, cdc_sample and cdc_sync. CDC-FX/MFX checkers: cdc_fx and
cdc_mfx.

July 2013
Reference
CDC Schemes
CDC Schemes
CDC analysis identifies logic patterns relevant to CDC verification. Groups of related patterns
identify specific classes of situations called CDC schemes. Each CDC scheme represents a
specific type of CDC synchronizer architecture or a potential CDC issue. This chapter consists
of the data sheets for the various CDC schemes (see Table 5-1). Each data sheet has the
following information:
• General Information — qcdc message, schematic representation, description, and the

following information:
• Crossing Type — signal, data bus, both, or not applicable.
• Default Severity — evaluation, caution, or violation.
• Promoted Checker — CDC checker promoted to check the associated transfer
protocol.
• Examples — examples of directives that change the default behavior.
In addition, some data sheets show the following:
• Potential Problems — information about consequences you should consider.

• Notes — additional information relevant to the scheme.
Table 5-1. CDC Schemes
Default
Type Scheme ID Description Severity
Signal Sync two_dff TWO DFF Two or more in-phase flip- evaluation
SYNCHRONIZER flops.
two_dff_phase TWO DFF Two out-of-phase flip-flops. caution
SYNCHRONIZER
OPPOSITE
POLARITY
four_latch FOUR LATCH Four or more cascaded evaluation
SYNCHRONIZER latches.
pulse_sync PULSE SYNC Pulse. evaluation
shift_reg SHIFT REG Shift register. evaluation
dff_sync_gated_clk DFF GATED SYNC Two flip-flops with gated caution

clock.
async_reset ASYNC RESET Asynchronous reset scheme. evaluation
async_reset_no_sync ASYNC RESET NO Asynchronous reset violation

SYNC scheme.with a missing
synchronizer.
no_sync MISSING Missing synchronizer. violation
SYNCHRONIZER

July 2013
Reference
CDC Schemes
Default
custom_sync CUSTOM Custom control signal evaluation

synchronizer with async
input port domain.
custom_sync_no_sync CUSTOM NO Custom control signal violation
SYNC synchronizer with missing or
mismatching input port
domain.
Data Sync bus_two_dff BUS SYNC Two or more in-phase flip- evaluation
flops.
bus_two_dff_phase BUS SYNC Two out-of-phase flip-flops. caution
bus_four_latch BUS SYNC Four or more cascaded evaluation
latches.
bus_dff_sync_gated_clk BUS DFF GATED Two flip-flops with gated caution
SYNC clock.
bus_shift_reg BUS SHIFT REG Shift register. evaluation
multi_bits MULTIPLE BITS Multiple-bit signal. violation
bus_custom_sync BUS CUSTOM Custom bus synchronizer evaluation

with async input port
domain.
bus_custom_sync_no_sync BUS CUSTOM Custom bus synchronizer evaluation
NO SYNC with missing or mismatching
input port domain.
Signal and dmux DMUX MUX enable. caution
Data Sync
simple_dmux SIMPLE DMUX MUX enable. caution
and_gate_dmux AND GATE DMUX AND gate used for enable. caution
forward_simple_dmux FORWARD MUX between first and caution

SIMPLE DMUX second Rx registers.
multi_sync_mux_select MULTIPLE Multiple MUXes. caution
SYNCHRONIZERS
AT DMUX
handshake HANDSHAKE MUX enable with evaluation
handshaking.
fifo FIFO FIFO. evaluation
fifo_memory FIFO MEMORY FIFO Memory. caution
fifo_memory_ptr_mismatch FIFO POINTER FIFO Memory. violation

MISMATCH
fifo_ptr_no_sync MISSING FIFO FIFO Memory. violation
POINTER
SYNCHRONIZER
custom_sync_with_crossing CUSTOM WITH Custom with internal evaluation
CROSSING crossing.

July 2013
Reference
CDC Schemes
Default
Potential combo_logic COMBO LOGIC Combinational logic on a violation

Problem synchronization path.
reconvergence RECON- Reconvergent CDC signals. caution
VERGENCE
single_source_reconvergence SSR Reconvergent CDC signals violation
from a single source.
redundant REDUNDANT CDC signal drives multiple caution
synchronizers.
series_redundant SERIES Custom synchronizers caution
REDUNDANT connected in series.
fanin_different_clks FANIN LOGIC Fan-in logic from multiple violation
FROM DIFFERENT clock domains.
CLOCKS
clock_no_sync CLOCK DOMAIN Signal that clocks a receive caution
CROSSING AT register is derived from a
CLOCK PIN clock domain crossing.
black_box BLACK BOX Crossing to or from an caution
instance of a black box.

July 2013
Reference
and_gate_dmux
and_gate_dmux
AND_GATE_DMUX: AND-gate DMUX synchronization.
tx_data
rx_data
AND
tx_clk
tx_sel
synchronizer
tx_clk rx_clk
The AND-gate DMUX scheme is a restricted version of the general DMUX scheme. For the
general scheme, the fanin logic of the Rx signal can contain any logic and the synchronized
control signal can use any logic to turn off the Tx signal (not just a MUX). The control signal
can be synchronized by any of the following signal synchronizers: two_dff_phase,
dff_sync_gated_clk, four_latch. shift_reg, two_dff, pulse_sync and custom.
The AND-gate DMUX scheme has the following restrictions:
• Logic between the Tx and Rx signals has an AND gate.

• Tx signal drives one input of the AND gate.
• Tx and Rx drivers are registers.
• Except for the AND gate, no combo logic is between the Tx register and the Rx register.
• No combo logic is between select output from the synchronizer and the AND gate.
Note
The physical design of the select logic (that controls the path from the Tx register to the
Rx registers) must not allow glitches at the input to an Rx register when the Tx register
changes value.
Crossing Type
synchronized control signal and muxed data bus
Default Severity
caution
Promoted Checker
cdc_dsel

July 2013
Reference
and_gate_dmux
Examples
1. Following is an example to turn severity to evaluation:
cdc report scheme and_gate_dmux -severity evaluation
2. Following is an example to turn off promotion:

cdc promote scheme and_gate_dmux -promotion off
3. Example promoted transfer protocol checker for simple_dmux synchronization scheme

(in cdc_checker.rpt):
domains, where the transmitter's data select signal drives
the select input of a data multiplexor in the receiver, is
held stable enough for the signal to be sampled reliably by
the receiver and ensures that the data remains stable while
the data select signal asserts.
Message : <None>
Location : File /home/cdc_static/src/vlog/demo_top.v,
Line 336
-tx_data tx_mask_d
-rx_data mask
-tx_min 1
-areset ( ! rst)
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
-rx_data : mask
-rx_data_select : (mask_pass && tx_mask_valid_r2)
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal

July 2013
Reference
async_reset
async_reset
ASYNC RESET: Signal feeds to the asynchronous reset port of the receiving register.
tx_rst
tx_sig rst rst rx_rst
1'b1 DFF DFF
tx_clk rx_clk
Synchronization using an asynchronous reset is a standard method of synchronizing a 1-bit

signal.
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync (if enabled, see cdc preference).
Examples
1. Following is an example to turn severity to violation.
cdc report scheme async_reset -severity violation
2. ASYNC_RESET scheme that uses an asynchronous reset input to drive the reset pins of
the synchronizer. Synchronizer input is tied high.
always @(posedge rx_clk,negedge
rx domain reset
tx_sig)
if (!tx_sig) begin tx_sig rst rst
s0 <= 1’b0;
s1 <= 1’b0; 1'b1 s1
end
else begin high
s0 <= 1’b1; tx_clk rx_clk
s1 <= s0;
end
Evaluations
==============================================================
Asynchronous reset synchronization. (async_reset)
-----------------------------------------------------------------
tx_clk : start : tx_sig (async_reset1.v : 9)
rx_clk : end : s0 (async_reset1.v : 10) (ID:async_reset_95442)

July 2013
Reference
async_reset
the synchronizer. Synchronizer input is tied low.
always @(posedge rx_clk,negedge rx domain reset
tx_sig)
if (tx_sig) begin tx_sig rx_rst
set set
s0 <= 1’b1; s1
s1 <= 1’b1; 1'b0 s0
end
else begin low
s0 <= 1’b0; tx_clk rx_clk
s1 <= s0;
end
assign rx_rst = s1 | tx_sig;
Evaluations
==============================================================
-----------------------------------------------------------------
rx_clk : end : s0 (async_reset1.v : 10) (ID:async_reset_95442)
4. ASYNC_RESET scheme that uses an asynchronous reset input to drive the D input of
the first DFF in the synchronizer and the reset pins of the Rx domain registers.
rx domain reset
always @(posedge rx_clk) begin
s0 <= tx_sig; tx_sig rx_rst
s1 <= s0; s0 s1
end
assign rx_rst = s1 | tx_sig;
tx_clk rx_clk
Evaluations
==============================================================
Single-bit signal synchronized by DFF synchronizer. (two_dff)
-----------------------------------------------------------------
rx_clk : end : s0 (async_reset3.v : 10) (ID:two_dff_32868)

-----------------------------------------------------------------
rx_clk : end : rx_rst (async_reset3.v : 23) (ID: async_reset_)
the synchronizer, the D input of the first DFF in the synchronizer and the reset pins of
the Rx domain registers.
rx domain reset
always @(posedge rx_clk,negedge tx_sig)
if (! tx_sig) tx_sig rst rst rx_rst
{s1, s0} <= 2’b00; s0 s1
else
{s1, s0} <= {s0, tx_sig};
assign rx_rst = s1 & tx_sig;
tx_clk rx_clk

July 2013
Reference
async_reset
Evaluations
==============================================================
-----------------------------------------------------------------
tx_clk : start : tx_sig async_reset4.v : 9)
rx_clk : end : s0 async_reset4.v : 10) (ID:two_dff_32868)

-----------------------------------------------------------------
tx_clk : start : tx_sig async_reset4.v : 9)
rx_clk : end : s0 async_reset4.v : 10) (ID:async_reset_95442)

July 2013
Reference
async_reset_no_sync
async_reset_no_sync
ASYNC RESET NO SYNC: Signal that feeds to the asynchronous reset port of the receiving
register has no synchronizer.
tx_sig ? rx_sig
DFF
1'b1
tx_clk missing reset rx_clk

synchronizer
tx_sig rx_reset
DFF
1'b1 incorrect reset
synchronizer
tx_clk rx_clk
Synchronization using an asynchronous reset is a standard method of synchronizing a 1-bit

signal, but the receiving register output must drive a control signal synchronizer before driving
receive domain logic.
Crossing Type
1-bit signal
Default Severity
violation
Promoted Checker
none
Examples
1. Following example changes the default severity for the async_reset_no_sync scheme to
evaluation:
cdc report scheme async_reset_no_sync –severity evaluation

July 2013
Reference
async_reset_no_sync
2. Tx signal is used as an unsynchronized reset in the Rx domain.

// Reset triggered by tx_clk rx domain reset
always @(posedge tx_clk)
tx_sig <= rst;
tx_sig din rst rx_sig
// Unsynchronized reset used in
// Rx domain
if (!tx_sig) rx_sig <= 1’b0;
else rx_sig <= din; tx_clk rx_clk
Violations
==============================================================
Asynchronous reset does not have proper synchronization.
(async_reset_no_sync)
-----------------------------------------------------------------
tx_clk : start : tx_sig (test.v : 9)
rx_clk : end : rx_sig (test.v : 9)
(ID:async_reset_no_sync_95911)
3. Tx signal is not properly synchronized as a reset in the Rx domain.

// Reset triggered by tx_clk
improperly synchronized reset rx_reset
always @(posedge tx_clk)
tx_sig <= rst; tx_sig rst rst
// Improperly synchronized reset used 1'b1
// in Rx domain
if (!tx_sig) rx_reset <= 1’b0; tx_clk rx_clk
else rx_reset <= 1’b1;
Violations
==============================================================
Asynchronous reset does not have proper synchronization.
(async_reset_no_sync)
-----------------------------------------------------------------
tx_clk : start : tx_sig (test2.v : 9)
rx_clk : end : rx_reset (test.v : 10)
(ID:async_reset_no_sync_85287)

July 2013
Reference
black_box
black_box
BLACK BOX: Crossing to or from an instance of a black box.
tx_sig
black box
tx_clk rx_clk
A black box is a module/entity that:
• is explicitly declared as a black box (with the netlist blackbox directive) ,

• contains unsupported constructs,
• is an unresolved module and the -auto_blackbox option is specified to cdc run, or
• is an empty module and cdc preference -black_box_empty_module is specified.
Table 5-2 shows how CDC analysis handles black boxes.
Table 5-2. Handling Black Boxes
port domain?
path
black box
Port Domain Specified Port Domain Not Specified

User Specified Black Box no_sync (unless port domain is no crossing
-async)
Inferred Black Box black_box warning black_box warning
port domain?
path
black box
Port Domain Specified Port Domain Not Specified

User Specified Black Box sync check (e.g., no_sync) no crossing
Inferred Black Box sync check (e.g., no_sync) sync check (e.g., no_sync)

July 2013
Reference
black_box
Crossing Type
control signal or data bus
Default Severity
caution
Promoted Checker
none
Examples
1. Following is an example to turn severity to violation:
cdc report scheme black_box –severity violation
2. Following is an example of the paths for a black box crossing (from cdc.rpt):
Cautions
=================================================================
black Box Crossing. (black_box)
-----------------------------------------------------------------
clk1 : start : u0.q (/u/black box/dut.v : 41)
<clock N/A>:end: u1.b(/u/bb/dut.v:12)(ID:black_box_5)
via: u0.q
via: u1.b
<clock N/A>: end : u1.c (/u/bb/dut.v : 12)(ID:black_box_53)
via : u0.q
via : u1.c
Following is a directive that identifies the port domains of the inferred black box:
# Black box ports
netlist port domain b c -clock clk -module black box_module
With this directive, the port domains of the black box ports are identified in cdc.rpt:
Cautions
=================================================================
-----------------------------------------------------------------
clk1 : start : u0.q (/u/bb/dut.v : 41)
clk3: end : u1.b (/u/bb/dut.v : 12)(ID:black_box_52)
via: u0.q
clk3: end : u1.c (/u/bb/dut.v : 12)(ID:black_box_53)
via: u0.q
In this case, the port domain of the driver (u0.q) was set by a netlist port domain
directive:
netlist port domain q -clock clk3

July 2013
Reference
black_box
3. Following example shows an instance (BB) of a module (black_box) that cdc has
inferred to be a black box.
rst
instance of an
din0 reset inferred black box
datain0
dataout dout
tx_clk datain1
BB
din1 datain2 status statout
datain3
din2
din3 clock
rx_clk
By default, the datain inputs are assumed to be in different clock domains. Similarly,
dout and stout are assumed to be in different clock domains. To make static CDC
analysis more accurate and to reduce the clock domain complexity, identify the port
domains of the black box data ports. For example:
#Input port domains
netlist port domain datain0 -async -module black_box
netlist port domain datain1 -async -module black_box
netlist port domain datain2 -clock clock -module black_box
netlist port domain datain3 -clock clock -module black_box
#Outrput port domains

netlist port domain dataout -clock clock -module black_box
netlist port domain status -clock clock -module black_box
Note that these are the port domains (not clock domains) for the data ports. Domains are
identified according to the black box’s clock pins (not external clock signals).
Cautions
============================================================
-----------------------------------------------------------------
rx_clk : start : BB.dataout (black_box.v : 40)
tx_clk : end : dout (black_box.v : 21) (ID:multi_bits_47389)

-----------------------------------------------------------------
tx_clk : start: din1 (black_box.v : 25)
<clock N/A>: end: BB.datain1 (black_box.v :40)(ID:black_box_12944)
Cautions
============================================================
-----------------------------------------------------------------
tx_clk : start : din0 (black_box.v : 24)
<clock N/A>: end: BB.datain0 (black_box.v :40)(ID:black_box_48560)

July 2013
Reference
bus_custom_sync
bus_custom_sync
BUS_CUSTOM: Multiple-bit signal synchronized by custom CDC synchronizer whose input
port is identified as asynchronous.
gray tx_data async rx_data gray
encoder custom decoder
synchronizer
tx_clk rx_clk
Custom synchronizers are instances of modules declared as custom synchronizers with the cdc
synchronizer custom directive. The bus_custom_sync scheme identifies multiple-bit custom
synchronizers where the clock domain crossing is external to the synchronizer itself and the
input port is specified as asynchronous (with netlist port domain).
Crossing Type
data bus
Default Severity
evaluation
Promoted Checker
none
Examples
1. Following is an example to specify the cust_sync module with clock pin clk as a custom
synchronizer:
cdc synchronizer custom cust_sync
netlist port domain d -async -clock clk -module cust_sync
The netlist port domain directive identifies input d as an asynchronous port and directs
CDC analysis to use the clk port to identify the receive clock reported for clock domain
crossings through cust_sync.
2. Following is an example to turn severity to caution:
cdc report scheme bus_custom_sync -severity caution

July 2013
Reference
bus_custom_sync
3. Custom synchronizer for the Tx signal:

// Custom sync instance
syncA S (rx_clk,tx_data,rx_data); tx_data rx_data
din dout
always @(posedge tx_clk) data syncA
tx_data <= data; clk
tx_clk rx_clk
Evaluations
=============================================================
Multiple-bit signal synchronized by Custom CDC Scheme: syncA
(bus_custom_sync)
-----------------------------------------------------------------
tx_clk : start : tx_data (bus_custom_sync.v : 21)
rx_clk : end : S.din (bus_custom_sync.v : 29)
(ID:bus_custom_sync_5359)
Use the cdc synchronizer custom directive to identify custom synchronizer

modules/entities:
cdc synchronizer custom syncA
Custom synchronizers are considered inferred black boxes for CDC analysis, so you
must specify their port information:
netlist port domain -input din -async -clock rx_clk -module syncA
netlist port domain -output dout -clock rx_clock -module syncA
Potential Problem
CDC analysis does not promote a checker for this scheme. You should implement a transfer
protocol checking scheme using one or more checkers.

July 2013
Reference
bus_custom_sync_no_sync
BAD CUSTOM SYNC DOMAIN MISMATCH: Multiple-bit signal synchronized by custom
CDC synchronizer whose input port’s domain is unidentified or does not match the clock
domain of the signal.
unspecified or mismatching
domain
gray tx_data rx_data gray

encoder custom decoder
synchronizer
tx_clk rx_clk
synchronizer custom directive. The bus_custom_sync scheme identifies multiple-bit custom
synchronizer custom directive. The bus_custom_sync_no_sync scheme identifies multiple-bit
custom synchronizers where the port domain of the input port connected to the Tx signal is not
properly specified. The netlist port domain directive sets the port domains of modules. In the
above figure, the custom synchronizer’s input port domain can be:
• -async
Proper port domain specification for custom synchronizers with external crossings. The
circuit is identified as a bus_custom_sync scheme.
• -tx_clock tx_clock
Proper port domain specification for custom synchronizers with internal crossings. The
circuit is identified as a custom_sync_with_crossing scheme.
• -tx_clock other_clock_domain
Badly-connected synchronizer. The circuit is identified as a bus_custom_sync_no_sync
scheme.
• unassigned
Improperly-specified synchronizer. Custom synchronizer data input ports must have
netlist port domain specifications. The circuit is identified as a
bus_custom_sync_no_sync scheme.
Crossing Type
data bus

July 2013
Reference
Default Severity
violation
Promoted Checker
none
Examples
cdc report scheme bus_custom_sync_no_sync -severity caution

syncA S (rx_clk,tx_data,rx_data); tx_data rx_data
din dout
always @(posedge tx_clk) data syncA
tx_data <= data; clk
tx_clk rx_clk
Evaluations
=============================================================
Multiple-bit signal synchronized by Custom CDC scheme does not have
proper synchronizer: syncA (bus_custom_sync_no_sync)
-----------------------------------------------------------------
tx_clk : start : R.q (demo.sv : 21)
rx_clk : end : S.din (demo.sv : 29)
(ID:bus_custom_sync_no_sync_5359)

modules/entities:
cdc synchronizer custom syncA
must specify their port information. To report this crossing as a bus_custom_sync
scheme (evaluation), assign the port domain of the syncA din port to asynchronous:
netlist port domain -input din -async -clock rx_clk -module syncA
netlist port domain -output dout -clock rx_clock -module syncA
Potential Problem

July 2013
Reference
bus_dff_sync_gated_clk
BUS DFF GATED SYNC: Multiple-bit signals synchronized with DFF synchronizer with
gated clock.
tx_data rx_data
DFF DFF
tx_clk en_rx_clk
rx_clk
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal, but
one of the flip-flops is clocked by a gated version of the receive clock.
Crossing Type
multiple-bit data bus
Default Severity
caution
Promoted Checker
cdc_hamming_distance_one (cdc_hamming1)
Examples
cdc report scheme bus_dff_sync_gated_clk -severity evaluation
2. Following is an example to turn off reporting for a particular CDC source signal:
cdc crossing off -from in1 -to r1
3. Bus 2 DFF synchronizer has one FF clocked by a gated version of the Rx clock.:
//gated Rx clock
assign gclk = rx_clk & en; tx_reg sync1 sync2
// 1st flip-flop triggered by

// the gated clock
always @(posedge gclk) tx_clk
gclk en
sync1 <= tx_reg; rx_clk
// 2nd flip-flop triggered by

// the Rx clock
always @(posedge rx_clk)
sync2 <= sync1;

July 2013
Reference
Cautions
=============================================================
Multiple-bits signals synchronized with DFF synchronizer with gated
clock. (bus_dff_sync_gated_clk)
-----------------------------------------------------------------
tx_clk : start : tx_reg (test2.v : 12)
rx_clk : end : sync1 (test2.v :12)
(ID:bus_dff_sync_gated_clk_8918)

July 2013
Reference
bus_four_latch
bus_four_latch
BUS SYNC: Multiple-bit signal synchronized by latch synchronizer.

encoder latch latch latch latch DFF decoder
tx_clk rx_clk
Synchronization using four latches is a standard method of synchronizing a gray-coded data

bus. Here, the latch enables are of alternating polarity.
Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any cycle, so
a four-latch synchronizer (typically used for 1-bit signal crossings) is appropriate if the data
changes only at the frequency of the receiving domain.
Crossing Type
Default Severity
evaluation
Promoted Checker
cdc_hamming_distance_one (cdc_hammimg1)
Examples
cdc report scheme bus_four_latch –severity violation

cdc promote scheme bus_four_latch –promotion off
3. Example promoted transfer protocol checker for four_latch synchronization scheme (in
cdc_checker.rpt):
Type/Name : cdc_hamming_distance_one demo_top.bus_two_dff_62001
Description : Ensures that the data crossing from transmit clock
to receive clock domain changes by only one hamming
distance and that it remains stable for a specified tx_min
clock cycles.
Message : <None>
Location : File /home/cdc/src/vlog/generic_fifo_dc_gray.v,
Line 147
Directive : cdc_hamming1
-tx_var fifo_0_h.rp_gray
-tx_clock mac_clk_in

July 2013
Reference
bus_four_latch
-reference bus_two_dff_62001
-name bus_two_dff_62001
-module demo_top
-inferred
Module : demo_top
Check data_stable : Off <Default Off>
Check hamming_one : On <Default On>
-tx_var : fifo_0_h.rp_gray
-tx_clock : mac_clk_in
-tx_reset : 1'b0
-areset : 1'b0
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : bus_two_dff_62001
Checker Class : CDC
Checker Internal
4. Bus four-latch synchronizer:

always @ (*)
if (rx_clk) begin
sync1 <= tx_sig;// 1st tx_sig rx_sig
latch
sync3 <= sync2; // 3rd
latch tx_clk rx_clk
end
else begin
sync2 <= sync1; // 2nd
latch
rx_sig <= sync3;// 4th
latch
end
Evaluations
=============================================================
Multiple-bit signal synchronized by latch synchronizer
(bus_four_latch)
-----------------------------------------------------------------
tx_clk : start: tx_sig (bus_four_latch.v : 8)
rx_clk: end : sync1 (bus_four_latch.v : 8)
(ID:bus_four_latch_51294)
via : sync1
Potential Problem
Four-latch synchronization of a data bus assumes the bus is gray-coded. Any data buses that
cross clock domains that are not gray-coded should be identified as requiring complete data
synchronization. Any of these crossings synchronized by four-latch synchronizers should be
flagged as violations. To set these schemes to violations, use the cdc report directive.
cdc report crossing -severity violation -scheme bus_four_latch \

-tx_clock clk_a

July 2013
Reference
bus_shift_reg
bus_shift_reg
SHIFT REG: Multiple-bit signal synchronized by shift-register synchronization.
tx_data rx_data
shift register
tx_clk rx_clk
Synchronization using a shift register is a standard method of synchronizing a gray-coded data

bus. Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any
cycle, so a shift register (typically used for 1-bit signal crossings) is appropriate if the data
changes only at the frequency of the receiving domain. This CDC scheme is equivalent to
synchronization with two or more in-phase flip-flops.
Crossing Type
Default Severity
evaluation
Promoted Checker
Examples
cdc report scheme bus_shift_reg –severity violation

cdc promote scheme bus_shift_reg –promotion off
3. Example promoted transfer protocol checker for bus_shift_reg synchronization scheme

Type/Name : cdc_hamming_distance_one dut.bus_shift_reg_86219
Checkerware Instance : cdc_dut_c9d7a0_dut_inst_0.U0.U0
Description : Ensures that the data crossing from transmit
clock to receive clock domain changes by
only one hamming distance and that it
remains stable for a specified tx_min clock
cycles.
Message : <None>
Location : File .../bus_shift_reg.v, Line 11
-tx_var tx_reg
-tx_clock tx_clk
-reference bus_shift_reg_86219

July 2013
Reference
bus_shift_reg
-name bus_shift_reg_86219
-module dut
-inferred
Module : dut
-tx_var : tx_reg
-tx_clock : tx_clk
-tx_reset : 1'b0
-areset : 1'b0
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : bus_shift_reg_86219
Checker Class : CDC
Checker Internal
4. Bus shift register synchronizer:

// 2-level shift register
always @ (posedge rx_clk)
{sync[1], sync[0]} <= {sync[0], tx_data};
sync[0] synchronized data
[1]
tx_data
[0] shift register sync[1]
tx_clk rx_clk
Evaluations
=============================================================
Multiple-bit signal synchronized by shift-register synchronizer
(bus_shift_reg)
-----------------------------------------------------------------
tx_clk : start : tx_data (bus_shift_reg.v : 10)
rx_clk : end : sync[0] (bus_shift_reg.v : 19
(ID:bus_shift_reg_99229)

July 2013
Reference
bus_two_dff
bus_two_dff
BUS SYNC: Multiple-bit signal synchronized by DFF synchronizer.
encoder DFF DFF decoder
tx_clk rx_clk
Synchronization using two flip-flops is a standard method of synchronizing a gray-coded data

bus. Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any
cycle, so a 2DFF synchronizer (typically used for 1-bit signal crossings) is appropriate if the
data changes only at the frequency of the receiving domain.
Crossing Type
Default Severity
evaluation
Promoted Checker
cdc_hamming_distance_one (cdc_hammimg1)
Examples
cdc report scheme bus_two_dff –severity violation

cdc promote scheme bus_two_dff –promotion off
3. Example promoted transfer protocol checker for bus_two_dff synchronization scheme

Type/Name : cdc_hamming_distance_one
demo_top.bus_two_dff_94611
clock to receive clock domain changes by only one
hamming distance and that it remains stable for a
specified tx_min clock cycles.
Message : <None>
Location : File /home/cdc/src/vlog/fifo_dc_gray.v,
Line 147
-tx_var fifo_1_d.rp_gray
-reference bus_two_dff_94611

July 2013
Reference
bus_two_dff
-module demo_top
-inferred
Module : demo_top
-tx_var : fifo_1_d.rp_gray
-tx_reset : 1'b0
-areset : 1'b0
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : bus_two_dff_94611
Checker Class : CDC
Checker Internal
4. Bus 2 DFF synchronizer:

reg [width-1:0] tx_reg, rx_reg;
reg [width-1:0] sync1, sync2; tx_reg sync1 sync2

sync1 <= tx_reg; // 1st FF
sync2 <= sync1; // 2nd FF tx_clk rx_clk
end
Evaluations
=============================================================
Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff)
-----------------------------------------------------------------
tx_clk : start : tx_reg (bus_two_dff.v : 11)
rx_clk : end : sync1 (bus_two_dff.v : 11)
(ID:bus_two_dff_8942)
5. Bus 2 DFF synchronizer with enable. CDC analysis only recognizes this instance as a
bus_two_dff scheme if cdc preference -allow_enable_in_sync is specified.
reg [width-1:0] sync1, sync2; enable
tx_reg EN sync1 EN sync2
if (enable)
begin
sync1 <= tx_reg; // 1st FF tx_clk rx_clk
sync2 <= sync1; // 2nd FF
end
Evaluations
=============================================================
-----------------------------------------------------------------
tx_clk : start : tx_reg (bus_two_dff_en.v : 11)
rx_clk : end : sync1 (bus_two_dff_en.v : 11)
(ID:bus_two_dff_8942)

July 2013
Reference
bus_two_dff
Potential Problem
The 2DFF synchronization of a data bus assumes the bus is gray-coded. Any data buses that
cross clock domains that are not gray-coded should be identified as requiring complete data
synchronization. Any of these crossings synchronized by 2DFF synchronizers should be
flagged as violations. To set these schemes to violations, use the cdc report directives.
cdc report crossing -severity violation -scheme bus_two_dff \

-tx_clock clk_a
Notes
If you use a DFF synchronization scheme that has more than two flip-flops, then you can get
CDC analysis to recognize the scheme by specifying a cdc synchronizer directive.
For example, the following global CDC directive identifies 4 DFF synchronizers as valid
“two_dff” schemes for CDC paths from the tx_clk domain to the rx_clk domain:
cdc synchronizer dff -level 4 -tx_clock tx_clk -rx_clock rx_clk

July 2013
Reference
bus_two_dff_phase
bus_two_dff_phase
BUS SYNC: Multiple-bit signal synchronized by DFF synchronizer and multiple-bit signal
synchronized by DFF of opposite clock polarity.
encoder DFF DFF decoder
tx_clk
rx_clk
Synchronization using two opposite polarity flip-flops reduces the time the signal takes to settle.
When using this synchronization scheme, be sure the MTBF is acceptable.
When used to synchronize a data bus, the bus should be gray-coded (i.e., have hamming
distance 1), which assures that only one bit of data changes in any cycle, and the data should
change only at the frequency of the receiving domain.
Crossing Type
Default Severity
caution
Promoted Checker
Examples
cdc report scheme bus_two_dff_phase –severity evaluation
2. Bus 2 DFF phase synchronizer has one FF clocked by a clock with the opposite polarity
of the Rx clock:
reg [width-1:0] sync1, sync2; tx_reg sync1 sync2
always @(negedge rx_clk)

sync1 <= tx_reg; // 1st FF
tx_clk rx_clk
sync2 <= sync1; // 2nd FF

July 2013
Reference
bus_two_dff_phase
Cautions
=============================================================
Multiple-bits signal synchronized by DFF of opposite clock polarity.
(bus_two_dff_phase)
-----------------------------------------------------------------
tx_clk : start : tx_reg (test.v : 11)
rx_clk : end : sync1 (test.v : 11)
(ID:bus_two_dff_phase_57873)
3. Bus 2 DFF phase synchronizer with enables has one FF clocked by a clock with the
opposite polarity of the Rx clock. CDC analysis only recognizes this instance as a
bus_two_dff_phase scheme if cdc preference -allow_enable_in_sync is specified.
reg [width-1:0] tx_reg, rx_reg; enable
reg [width-1:0] sync1, sync2;
tx_reg EN sync1 EN sync2
if (enable) sync1 <= tx_reg;
if (enable) sync2 <= sync1; tx_clk rx_clk
Cautions
=============================================================
Multiple-bits signal synchronized by DFF of opposite clock polarity.
(bus_two_dff_phase)
-----------------------------------------------------------------
tx_clk : start : tx_reg (test.v : 11)
rx_clk : end : sync1 (test.v : 11)
(ID:bus_two_dff_phase_57873)
Potential Problems
1. Synchronization of a data bus using two opposite polarity DFFs assumes the bus is
gray-coded.

July 2013
Reference
clock_no_sync
clock_no_sync
CLOCK DOMAIN CROSSING AT CLOCK PIN: Signal that clocks a receive register is
derived from a clock domain crossing.
data rx_data
tx_sig DFF
combo
tx_clk rx_clk
Specifying cdc preference -clock_as_rx option directs CDC static analysis to identify clock
domain crossings to a clock pin.
Crossing Type
1-bit signal
Default Severity
caution
Promoted Checker
none
Examples
cdc preference -clock_as_rx
cdc report scheme clock_no_sync –severity violation
2. Register out2 is clocked by either clk2 or !clk2, which is selected by a signal clocked by
clk1. Since the selector is from a different clock domain than the clock, a clock_no_sync
caution is reported if cdc preference -clock_as_rx is specified.
module top(
in2 out2
input in1, in2, clk1, clk2
output reg out2);
reg out1; clk2
always @ (posedge clk1)
out1 = in1;
wire w = out1 ? !clk2 : clk2; in1 out1
always @ (posedge w)
out2 = in2;
clk1
endmodule

July 2013
Reference
clock_no_sync
Cautions
=============================================================
Clock domain crossing at clock pin. (clock_no_sync)
-----------------------------------------------------------------
clk1 : start : out1 (...cdc_clock_no_sync/top.v : 2)
w : end : out2 (.../cdc_clock_no_sync/top.v : 1)
(ID:clock_no_sync_64598)

July 2013
Reference
combo_logic
combo_logic
COMBO LOGIC: Combinational logic before synchronizer.
combinational logic
tx_data rx_data
synchronizer
tx_clk rx_clk
Combinational logic in a synchronization path is a significant problem for synchronized signals,

because the data used to determine an acceptable failure rate on synchronization paths assumes
a single transition on a CDC signal during each clock period. But if combinational logic is
placed on the path, then this assumption is false because of glitch propagation. As a result, the
error rate rises significantly. To address this problem, you should remove all combinational
logic from the logic path.
Static CDC analysis checks for combo logic in every CDC path that has a detected
synchronizer. For some cases, this combinational logic will be constant during normal
operation, so glitches cannot be generated. For example, the combinational logic might consist
of test MUXes or configuration logic. To remove the violation, identify the signal feeding that
logic as a constant value using netlist constant.
Crossing Type
Default Severity
violation
Promoted Checker
cdc_glitch
Examples
1. Following is an example to specify that the MUX select in the combinational logic
feeding a CDC signal is constant 1'b0 (so the crossing can be checked for proper
synchronization):
netlist constant test_sel 1'b0
2. Following is an example to turn severity for the CDC signal en to caution:

cdc report crossing -severity caution -scheme combo_logic \
-from dut.U0.en

July 2013
Reference
combo_logic
3. Combinational logic between the Tx signal and a 2DFF synchronizer:
din
always @ (posedge rx_clk) begin s1 s2
s1 <= tx_sig & din; DFF DFF
tx_sig
s2 <= s1;
end
tx_clk rx_clk
Violations
=============================================================
Combinational logic before synchronizer. (combo_logic)
-----------------------------------------------------------------
tx_clk : start : tx_reg (combo_logic.v : 8)
rx_clk : end : sync1 (combo_logic.v : 8) (ID:combo_logic_57762)
Base Type : TWO DFF SYNCHRONIZER
The report for this violation shows the base type CDC scheme identified by CDC
analysis (TWO DFF SYNCHRONIZER). To remove this violation—and instead report
the crossing as a 2DFF scheme—you can specify that din is stable. That is, it is properly
synchronized in the Rx domain:
cdc signal din -stable

July 2013
Reference
custom_sync
custom_sync
SINGLE-BIT CUSTOM SYNC: Single-bit signal synchronized by custom CDC synchronizer
whose input port is identified as asynchronous.
tx_sig async rx_sig
custom
synchronizer
tx_clk rx_clk
synchronizer custom directive. The custom_sync scheme identifies single-bit custom
Crossing Type
control signal
Default Severity
evaluation
Promoted Checker
none (or cdc_sync/cdc_hamming1 if specified with cdc protocol)
Examples
synchronizer:
The netlist port domain directive identifies d as an asynchronous port and directs CDC
analysis to use the clk port to identify the receive clock reported for clock domain
crossings though cust_sync.
cdc report scheme custom_sync -severity caution

July 2013
Reference
custom_sync

syncA S (rx_clk, tx_sig, rx_sig); din dout
data tx_sig syncA rx_sig
always @(posedge tx_clk) clk
tx_clk rx_clk
tx_sig <= data;
Evaluations
=============================================================
Single-bit signal synchronized by Custom CDC Scheme: syncA
(custom_sync)
-----------------------------------------------------------------
tx_clk : start : tx_sig (custom_sync.v : 21)
rx_clk : end : S.din (custom_sync.v : 29) (ID:custom_sync_5359)

modules/entities:
cdc synchonizer custom syncA
netlist port domain -input din -async -clock clk -module syncA
netlist port domain -output dout -clock clk -module syncA
Potential Problem
CDC analysis does not automatically promote a checker for this scheme. You can provide a
transfer protocol checking scheme using the cdc protocol directive.

July 2013
Reference
custom_sync_no_sync
custom_sync_no_sync
CUSTOM SYNC DOMAIN MISMATCH: Single-bit signal synchronized by custom CDC
synchronizer whose input port domain is not specified or does not match the clock domain of
the signal.
unspecified or mismatching
domain
tx_sig rx_sig
custom
synchronizer
tx_clk rx_clk
synchronizer custom directive. The custom_sync_no_sync scheme identifies single-bit custom
synchronizers where the port domain of the input port connected to the Tx signal is not properly
specified. The netlist port domain directive sets the port domains of modules. In the above
figure, the custom synchronizer’s input port domain can be:
• -async
Proper port domain specification for custom synchronizers with external crossings. The
circuit is identified as a custom_sync scheme.
Proper port domain specification for custom synchronizers with internal crossings. The
circuit is identified as a custom_sync_with_crossing scheme.
• -tx_clock other_clock_domain
Badly-connected synchronizer. The circuit is identified as a custom_sync_no_sync
scheme.
• unassigned
Improperly-specified synchronizer. Custom synchronizer data input ports must have
netlist port domain specifications. The circuit is identified as a custom_sync_no_sync
scheme.
Crossing Type
control signal
Default Severity
violation
Promoted Checker
none (or cdc_sync/cdc_hamming1 if specified with cdc protocol)

July 2013
Reference
custom_sync_no_sync
Examples
synchronizer:
The netlist port domain directive identifies d as an asynchronous port and directs CDC
analysis to use the clk port to identify the receive clock reported for clock domain
crossings though cust_sync.
cdc report scheme custom_sync_no_sync -severity caution

syncA S (rx_clk, tx_sig, rx_sig); din dout
sig tx_sig syncA rx_sig
always @(posedge tx_clk) clk
tx_clk rx_clk
tx_sig <= data;
Violations
=============================================================
Single-bit signal synchronized by Custom CDC scheme does not have
proper synchronizer: syncA (custom_sync_no_sync)
-----------------------------------------------------------------
tx_clk : start : R.q (demo.v : 21)
rx_clk : end : S.din (demo.v : 29)
(ID:custom_sync_no_sync_5359)

modules/entities:
cdc synchonizer custom syncA
must specify their port information. To report this crossing as a bus_custom_sync
scheme (evaluation), assign the port domain of the syncA din port to asynchronous:
netlist port domain -input din -async -clock clk -module syncA
netlist port domain -output dout -clock clk -module syncA
Potential Problem
CDC analysis does not automatically promote a checker for this scheme. You can provide a
transfer protocol checking scheme using the cdc protocol directive.

July 2013
Reference
custom_sync_with_crossing
CUSTOM WITH CROSSING: Custom CDC synchronizer with an internal clock domain
crossing.
custom synchronizer
tx_data rx_data
tx_clk rx_clk
Tx Clock Domain internal crossing Rx Clock Domain
synchronizer custom directive. The custom_sync_with_crossing scheme identifies custom
synchronizers where the clock domain crossing is internal to the synchronizer itself. To identify
this type of custom synchronizer, you must identify a transmit clock port and a receive clock
port using the cdc synchronizer constraint directive for the custom synchronizer module. Every
other signal/data port must be identified with either a transmit variable clock or a receive
variable clock. If a port is identified as an -async port, the synchronizer is reported as a simple
custom_sync scheme.
Crossing Type
Default Severity
evaluation
Promoted Checker
none
Examples
1. Custom synchronizer module with crossing:
SYNC_VX
RST_A RST_B
IN OUT
CLKA CLKB
cdc synchronizer custom SYNC_VX

cdc synchronizer constraint SYNC_VX -ports IN -tx_var CLKA
cdc synchronizer constraint SYNC_VX -ports OUT -tx_var CLKB
netlist port domain RST_A -clock CLKA -module SYNC_VX
netlist port domain RST_B -clock CLKB -module SYNC_VX

July 2013
Reference
2. Custom synchronizer with an internal crossing:

syncC S ( din dout
tx_clk,rx_clk,tx_sig,rx_sig); data tx_sig syncC rx_sig
tclk rclk
always @(posedge tx_clk) tx_clk rx_clk
tx_sig <= data;
Evaluations
=============================================================
Custom synchronization with internal crossing.
(custom_sync_with_crossing)
-----------------------------------------------------------------
tx_clk: start: S.din (test2.v: 35)
rx_clk: end: S.dout (test2.v: 35)(ID:custom_sync_with_crossing_9661)

modules/entities:
cdc synchonizer custom syncC
cdc synchronizer constraint syncC -ports din -tx_var tclk
cdc synchronizer constraint syncC -ports dout -rx_var rclk
Potential Problem

July 2013
Reference
dff_sync_gated_clk
dff_sync_gated_clk
DFF GATED SYNC: DFF synchronizer with gated clock.
tx_sig rx_sig
DFF DFF
tx_clk en_rx_clk
rx_clk
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal.
Crossing Type
1-bit signal
Default Severity
caution
Promoted Checker
cdc_sync
Examples
cdc report scheme dff_sync_gated_clk –severity evaluation
2. Following is an example to turn off reporting for a particular source CDC signal:
cdc crossing off -from in1 -to r1
3. Single-bit signal synchronized by 2DFF synchronizer with a gated clock:

// gated clock expression
assign gclk = rx_clk & clk_en; tx_sig sync1 sync2
DFF DFF
always @(posedge gclk)
sync1 <= tx_sig; // 1st DFF
always @(posedge rx_clk) tx_clk rx_clk
sync2 <= sync1; // 2nd DFF clk_en
Cautions
=============================================================
DFF synchronizer with gated clock. (dff_sync_gated_clk)
-----------------------------------------------------------------
tx_clk: start: tx_reg (test4.v : 9)
rx_clk: end: sync1 (test4.v: 9)(ID:dff_sync_gated_clk_11747)

July 2013
Reference
dmux
dmux
DMUX: DMUX synchronization.
tx_data rx_data
MUX
tx_clk
tx_sel
DFF DFF
rx_sel
tx_clk rx_clk
Synchronization using a DMUX scheme is a standard method of synchronizing a data bus (or a
control signal). The control signal can be synchronized by any of the following signal
synchronizers: bus_dff_sync_gated_clk, bus_four_latch, bus_shift_reg, bus_two_dff,
bus_two_dff_phase or two_dff_phase, dff_sync_gated_clk, four_latch. shift_reg, two_dff,
pulse_sync and custom.
Note
The physical design of the MUX logic (that controls the path from the Tx register to the
changes value.
The DMUX scheme is similar to the SIMPLE_DMUX scheme. A SIMPLE_DMUX scheme is

a strict version of MUX synchronization logic that requires a receive register, a MUX and
feedback from the receiver to the MUX. A DMUX scheme is a generalized version of a MUX
synchronization circuit. The MUXing logic can be any combinational logic and a feedback path
from the Rx domain is not needed.
Crossing Type
synchronized control signal and data bus
Default Severity
caution
Promoted Checker
cdc_sample (if enabled, see cdc preference)

July 2013
Reference
dmux
Examples
cdc report scheme dmux -severity evaluation

cdc promote scheme dmux -promotion off
3. Example promoted transfer protocol checker for DMUX synchronization scheme (in
cdc_checker.rpt):
Message : <None>
Line 336
-tx_data tx_mask_d
-rx_data mask
-tx_min 1
-areset ( ! rst)
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
-rx_data : mask
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal

July 2013
Reference
dmux
4. 4-bit bus synchronized by a DMUX synchronizer:

begin: DMUX rx_data
reg s1, rx_sel; tx_data
s1 <= tx_sel; // 1st DFF 4’b1111
MUX
rx_sel <= s1; // 2nd DFF
if (rx_sel) tx_clk
rx_data <= tx_data; tx_sel s1
else DFF DFF rx_sel
rx_data <= rx_data ^ 4’b1111;
end rx_clk
Cautions
=============================================================
DMUX synchronization. (dmux)
-----------------------------------------------------------------
tx_clk : start : tx_data (dmux.v : 9)
rx_clk : end : rx_data (dmux.v : 6) (ID:dmux_39152)
Synchronizer ID : two_dff_44468
Evaluations
=============================================================
-----------------------------------------------------------------
tx_clk : start : tx_sel (dmux.v : 10)
rx_clk : end : DMUX.s1 (dmux.v : 22) (ID:two_dff_44468)

July 2013
Reference
fanin_different_clks
FANIN LOGIC FROM DIFFERENT CLOCKS: Fan-in logic from multiple clock domains.
sig_a sig_c
synchronizer
clock_a clock_c
Clock Domain A Clock Domain C

sig_b
Clock Domain B
clock_b
Fan-in logic for the input to a synchronizer must be synchronized to a single transmit clock
domain for CDC analysis to properly identify the synchronization scheme. CDC analysis
reports a FANIN LOGIC FROM DIFFERENT CLOCKS scheme if it finds two unsynchronized
signals from different clock domains in the fan-in logic of the input to a synchronizer.
For some cases, the signals from one domain are constant during normal operation. For
example, the fan-in logic from one of the domains might consist of test MUXes or configuration
logic. In some other cases, signals from one domain are marked as stable. How these cases are
handled depends on how many signals are in the fanin of the crossing:
• 2 signals in the fanin of the crossing

• If one signal is stable, it is not an instance of a fanin_different_clks or combo_logic
scheme.
• Otherwise, if one signal matches a cdc crossing off directive, nothing is reported for
the crossing. The other signal is reported as a combo_logic crossing.
• more than 2 signals in the fanin of the crossing
If one signal is stable or matches a cdc crossing off directive:
• If the remaining signals start from the same domain, the crossing is reported as an
instance of a combo_logic scheme.
• If the remaining signals start from more than one domain, the crossing is reported as
an instance of a fanin_different_clks scheme.
• The filtered crossing is an instance of a filtered combo_logic scheme.
To remove the violation, do one of the following:
1. Keep one signal and use netlist constant to identify the remaining signals coming from
that logic as constants. The removed signals do not appear in the CDC report.
2. Keep one signal and use cdc signal to identify the remaining signals coming from that
logic as stable. If you specify cdc preference -filtered_report, the removed signals

July 2013
Reference
appear in the CDC report. The fanin_different_clks scheme is reported as the scheme
detected for the remaining signal. When setting signals stable:
• CDC analysis assumes fan-in logic from a different clock domain is combo logic if
the remaining signals are from the same domain.
• CDC analysis assumes a CDC signal has a valid synchronizer scheme if it is the only
remaining signal after filtering the stable signals. The filtered signals also are
reported as using the scheme.
• Filtered stable signals are reported as instances of the combo_logic scheme
whenever fan-in is still detected after filtering them.
• Stable signals are reported in the CDC report if you specify cdc preference
-filtered_report.
Crossing Type
Default Severity
violation
Promoted Checker
cdc_glitch
Examples
1.
clock domain A
sig_a
sig_b
MUX
synchronizer
clock_a
clock_b
clock domain B
tsel test_sel
clock_test clock domain TEST
The above logic has a fanin_different_clks violation. To remove this violation, set
test_sel in the TEST clock domain to the constant 1'b0:
netlist constant test_sel 1'b0

July 2013
Reference
2. Following is an example of reporting for fan-in logic from different clock domains:
Violations (1)
-------------------------------------------
Fan-in logic from different clock domain (1)
===========================================
Fan-in logic from different clock domain
-------------------------------------------
clk3: end: u1.q(t8.v: 30)
clk1: start: u0.q(t8.v: 30)
via: u0.q
via: u1.d
clk2: u5.q(t8.v: 30)
via: u5.q
via: u1.d
3. Fanin logic from 2 clock domains:
tx1_sig sync0 sync1

always @ (posedge tx1_clk) DFF DFF
tx1_sig <= in1;
always @ (posedge tx2_clk)
tx2_sig <= in2; tx1_clk rx_clk
always @ (posedge rx_clk) begin
sync0 <= tx1_sig | tx2_sig; tx2_sig
sync1 <= sync0;
end
tx2_clk
Fanin logic from multiple clock domains. (fanin_different_clks)

-----------------------------------------------------------------
rx_clk : end : s0 (fanin_different_clks.v : 9)
(ID:fanin_different_clks_84638)
tx1_clk : start : tx1_sig (fanin_different_clks.v : 8)
tx2_clk : start : tx2_sig (fanin_different_clks.v : 8)

July 2013
Reference
fifo
fifo
FIFO: FIFO Synchronization.
read addr
synchronizer raddr
wr_clock
wr_data
memory
rd_data
rd_clock
waddr write addr
synchronizer
By default, memories with read and write clocks are reported as FIFO memories and FIFO-style
memories (see “FIFO Memory and FIFO Crossings” on page 44). Those FIFO-style crossings
that pass the criteria for FIFO memories are identified as belonging to the fifo_memory scheme.
Specifying cdc preference directive -fifo_scheme turns on FIFO detection. Here, static CDC
analysis determines whether or not what is previously a fifo_memory scheme passes the criteria
for being a crossing with true FIFO synchronization.
FIFO synchronization passes data between clock domains without synchronizing the data.
However, to prevent FIFO overflow, transmit logic must know when the FIFO is full and to
prevent FIFO underflow, the receive logic must know when the FIFO is empty. In the FIFO
synchronization scheme, the values of the address pointers are synchronized to the clock
domains of the opposite logic: read address pointer is synchronized to the transmit domain and
the write address pointer is synchronized to the receive domain.
The templates CDC static analysis uses to detect FIFO schemes can be adjusted using the cdc
preference fifo directive.
Crossing Type
data bus
Default Severity
evaluation
Promoted Checkers
• No checker is promoted for the FIFO protocol.
• A cdc_hamming_distance_one checker is promoted for each address synchronizer.

July 2013
Reference
fifo
Examples
cdc report scheme fifo –severity caution
2. Following is a typical FIFO crossing.

write address fifo_empty
synchronizer
rd_clock
waddr_gray waddr raddr_gray
raddr
gray to binary gray to binary
wr_data memory rd_data
fifo_full
wr_clock rd_clock
read address
synchronizer
wr_clock
FIFO write FIFO read
clock domain clock domain
3. In the following CDC report entry, the two synchronizers are the read and the write
pointer synchronizers:
Cautions
=================================================================
FIFO synchronization. (fifo)
-----------------------------------------------------------------
sys_clk : start : inst_m1dsi_al_0.crs_async_fifo_0.data_q
(/ASIC/lib/src/async_fifo_rtl.vhd : 34)
tx_byte_hs_clk : end inst_m1dsi_al_0.crs_async_fifo_0.data2_q
(/ASIC/lib/src/async_fifo_rtl.vhd : 37)
(ID:fifo_85752)
Read Synchronizer ID : bus_two_dff_48297
Write Synchronizer ID : bus_two_dff_55880

July 2013
Reference
fifo
4. RAM-based FIFO synchronizer. CDC analysis only recognizes this instance as a fifo
scheme if cdc preference -fifo_scheme is specified.
reg [2:0] wr_sync1, wr_sync2,
reg [2:0] rd_sync1, rd_sync2;
reg [2:0] Mem [7:0];
full rd_sync2 rd_sync1
always @(posedge wr_clk) begin wr_clk
Mem [wr_addr] <= wr_data;
rd_sync1 <= rd_addr ; wr_data rd_addr
rd_sync2 <= rd_sync1;
full <= memory
wr_addr rd_data
((wr_addr+1)==rd_sync2)?1:0;
end
rd_clk
always @(posedge rd_clk) begin
rd_data <= Mem [rd_addr]; wr_sync1 wr_sync2 empty
wr_sync1 <= wr_addr;
wr_sync2 <= wr_sync1;
empty <=
(rd_addr == wr_sync2)? 1:0;
end
Evaluations
=============================================================
-----------------------------------------------------------------
wr_clk : start : Mem (fifo1.v : 11) (ID:fifo_10640)
rd_clk : end : rd_data (fifo1.v : 6)
Read pointer synchronizer ID : bus_two_dff_18726
Write pointer synchronizer ID : bus_two_dff_646

-----------------------------------------------------------------
rd_clk : start : rd_addr (fifo1.v : 5)
wr_clk : end : rd_sync1 (fifo1.v : 10) (ID:bus_two_dff_18726)
wr_clk : start : wr_addr (fifo1.v : 5)
rd_clk : end : wr_sync1 (fifo1.v : 10) (ID:bus_two_dff_646)
Also, the clock domains of the address pointers are identified explicitly:
netlist port domain wr_addr -clock wr_clk
netlist port domain rd_addr -clock rd_clk

July 2013
Reference
fifo
5. Register-file based FIFO synchronizer. CDC analysis only recognizes this instance as a
fifo scheme if cdc preference -fifo_scheme is specified. Also, to detect the register file:
cdc fifo Mem1 Mem2 Mem3 Mem4
reg [2:0] wr_sync1, wr_sync2,

reg [2:0] rd_sync1, rd_sync2;
full rd_sync2 rd_sync1
always @(posedge wr_clk) begin
case (wr_addr) wr_clk
3’d0: Mem1[0] <= wr_data;
3’d1: Mem1[1] <= wr_data; wr_data rd_addr
3’d3: Mem2[1] <= wr_data; memory
wr_addr rd_data
3’d5: Mem3[1] <= wr_data; rd_clk
wr_sync1 wr_sync2 empty
endcase
rd_sync1 <= rd_addr ;
rd_sync2 <= rd_sync1;
full <=
((wr_addr+1)==rd_sync2)?1:0;
end

case (rd_addr)
3’d0: rd_data <= Mem1[0];
endcase
wr_sync1 <= wr_addr;
wr_sync2 <= wr_sync1;
empty <=
(rd_addr == wr_sync2)? 1:0;
end

July 2013
Reference
fifo
Evaluations
=============================================================
-----------------------------------------------------------------
wr_clk : start : Mem1[0] (fifo2.v : 11) (ID:fifo_47408)

-----------------------------------------------------------------
rd_clk : start : rd_addr (fifo2.v : 5)
wr_clk : end : rd_sync1 (fifo2.v : 10) (ID:bus_two_dff_18726)
wr_clk : start : wr_addr (fifo2.v : 5)
rd_clk : end : wr_sync1 (fifo2.v : 10) (ID:bus_two_dff_646)

July 2013
Reference
fifo_memory
fifo_memory
FIFO MEMORY: FIFO Memory Synchronization.
wr_clock
raddr
wr_data
memory
rd_data
waddr rd_clock
that pass the criteria for FIFO memories are identified as belonging to the fifo_memory scheme:
1. The crossing involves a memory or a register file.

2. Memory is in the same clock domain as the write data signal to the memory.
3. The write address pointer must be in the same clock domain as the memory write
address input. Similarly, The read address pointer must be in the same clock domain as
the memory read address input.
Crossing Type
data bus
Default Severity
caution
Promoted Checkers
No checker is promoted.
Examples
cdc report scheme fifo_memory –severity evaluation

July 2013
Reference
fifo_memory
2. FIFO-style synchronizer reported as a fifo_memory crossing, because the clock domains

of the address pointers are identified explicitly:
netlist port domain wr_addr -clock wr_clk
netlist port domain rd_addr -clock rd_clk
No further FIFO detection is performed because cdc preference -fifo_scheme is not

specified.
module dut(
input wr_clk, rd_clk ,
input [7:0] wr_data, wr_addr rd_addr
input [2:0] wr_addr, rd_addr, wr_data rd_data
output reg [7:0] rd_data, Mem
output reg full, empty);
wr_clk rd_clk
// Memory array is a FIFO
reg [2:0] Mem [7:0];
Mem[wr_addr] <= wr_data;
full <=((wr_addr+1) == rd_addr) ? 1 : 0;
end

rd_data <= Mem[rd_addr];
empty <= (rd_addr == wr_addr) ? 1 : 0;
end
endmodule
Violations
=================================================================
Single-bit signal does not have proper synchronizer. (no_sync)
-----------------------------------------------------------------
rd_clk : start : rd_addr (.../fifo_memory.v : 5)
wr_clk : end : full (.../fifo_memory.v : 7)(ID:no_sync_19228)
wr_clk : start : wr_addr (.../fifo_memory.v : 5)

rd_clk : end : empty (.../fifo_memory.v : 8)(ID:no_sync_86436)
Cautions
=================================================================
FIFO memory synchronization. (fifo_memory)
-----------------------------------------------------------------
wr_clk : start : Mem (.../fifo_memory.v : 10) (ID:fifo_memory_28636)
rd_clk : end : rd_data[2:0] (.../fifo_memory.v : 6)

July 2013
Reference
FIFO POINTER MISMATCH: FIFO-style Memory with Mismatching Data/Pointer Clock
Domains.
FIFO pointer domains
waddr raddr
wr_data
memory
rd_data
wr_clock rd_clock
memories (see “FIFO Memory and FIFO Crossings” on page 44). A
fifo_memory_ptr_mismatch scheme is a FIFO-style memory crossing that fails the following
criterion, so it cannot be a true FIFO memory crossing (fifo_memory):
Write address pointer must be in the same clock domain as the memory write address
input. Similarly, the read address pointer must be in the same clock domain as the
memory read address input.
The clock domains of the pointers and data mismatch (or cannot be detected).
Crossing Type
data bus
Default Severity
violation
Promoted Checkers
Examples
cdc report scheme fifo_memory_ptr_mismatch –severity caution

July 2013
Reference
2. FIFO-style synchronizer is reported as a fifo_memory_ptr_mismatch crossing because

the port domains of wr_addr and rd_addr are not specified.
module dut(
wr_clk rd_clk
reg [2:0] Mem [7:0];
end

end
endmodule
Violations
=================================================================
FIFO pointer mismatch. (fifo_memory_ptr_mismatch)
-----------------------------------------------------------------
wr_clk : start : Mem (.../fifo_bad_ptr.v : 10)
(ID:fifo_memory_ptr_mismatch_3670)
rd_clk : end : rd_data (.../fifo_bad_ptr.v : 6)
<clock N/A> : write pointer : wr_addr

July 2013
Reference
fifo_ptr_no_sync
fifo_ptr_no_sync
MISSING FIFO POINTER SYNCHRONIZER: Synchronization of Memory Pointer Input is
Missing.
?
missing raddr
wr_clock synchronizer
wr_data
memory
rd_data
missing rd_clock
waddr synchronizer
?
that pass the criteria for FIFO memories are identified as belonging to the fifo_memory scheme.
Specifying cdc preference -fifo_scheme turns on FIFO detection. Here, static CDC analysis
determines whether or not what is previously a fifo_memory scheme passes the criteria for being
a crossing with true FIFO synchronization. The fifo_ptr_no_sync scheme is a FIFO memory
crossing that fails the following criterion, so it cannot be a true FIFO crossing (fifo):
Write address pointer must synchronize in the Rx domain and the read address pointer
must synchronize in the Tx domain.
You can relax these requirements with the -no_write_sync and -no_read_sync options to the cdc
preference fifo directive.
Crossing Type
data bus
Default Severity
violation
Promoted Checkers
Examples
cdc report scheme fifo_ptr_no_sync –severity caution

July 2013
Reference
fifo_ptr_no_sync
2. FIFO detection is performed because the -fifo_scheme preference is specified:

But the FIFO-style synchronizer is reported as a fifo_ptr_no_sync crossing because the

port domains of wr_addr and rd_addr are not specified.
module dut(
wr_clk rd_clk
reg [2:0] Mem [7:0];
end

end
endmodule
Violations
=================================================================
-----------------------------------------------------------------
rd_clk : start : rd_addr (.../fifo_memory.v : 5)
wr_clk : end : full (.../fifo_memory.v : 7)(ID:no_sync_19228)
wr_clk : start : wr_addr (.../fifo_memory.v : 5)

rd_clk : end : empty (.../fifo_memory.v : 8)(ID:no_sync_86436)
Missing FIFO pointer synchronization. (fifo_ptr_no_sync)

-----------------------------------------------------------------
wr_clk : start : Mem (.../fifo_memory.v : 10)
(ID:fifo_ptr_no_sync_66643)
rd_clk : end : rd_data (.../fifo_memory.v : 6)

July 2013
Reference
forward_simple_dmux
forward_simple_dmux
FORWARD_SIMPLE_DMUX: Forward Simple DMUX synchronization..
tx_data MUX rx_data
tx_clk
tx_sel
synchronizer
tx_clk rx_clk
The forward simple DMUX scheme is a restricted version of the general DMUX scheme. For
the general scheme, the fanin logic of the Rx signal can contain any logic and the synchronized
The forward simple DMUX scheme has the following restrictions:
• Logic between the first and second Rx signals has a MUX.

• Second Rx output feeds back to the MUX input.
• Tx signal drives the D-input of the Rx register
• No combo logic is between the Tx register and first Rx register.
• No combo logic is between select output from the synchronizer and the MUX.
Note
changes value.
Crossing Type
Default Severity
caution
Promoted Checker
cdc_dsel

July 2013
Reference
forward_simple_dmux
Examples
cdc report scheme forward_simple_dmux -severity evaluation
2. Following is an example to turn on promotion:

cdc promote scheme forward_simple_dmux -promotion on

Message : <None>
Line 336
-tx_data tx_mask_d
-rx_data mask
-tx_min 1
-areset ( ! rst)
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
-rx_data : mask
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal

July 2013
Reference
four_latch
four_latch
FOUR LATCH SYNCHRONIZER: Single-bit signal synchronized by latch synchronizer.
tx_sig rx_sig
latch latch latch latch
tx_clk rx_clk
Synchronization using four latches is a standard method of synchronizing a 1-bit signal. Here,
the latch enables are of alternating polarity. The end Rx signal for the synchronizer is the first
latch in the synchronizer.
Crossing Type
control signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
cdc report scheme four_latch -severity caution

cdc promote scheme four_latch -promotion off
3. Example promoted transfer protocol checker for four_latch synchronization scheme (in
cdc_checker.rpt):
Type/Name : cdc_hamming_distance_one demo_top.bus_two_dff_62001
clock to receive clock domain changes by
only one hamming distance and that it
remains stable for a specified tx_min clock
cycles.
Message : <None>
Location : File
/home/cdc/src/vlog/generic_fifo_dc_gray.v,
Line 147
-tx_var fifo_0_h.rp_gray
-reference two_dff_62001

July 2013
Reference
four_latch
-module demo_top
-inferred
Module : demo_top
-tx_var : fifo_0_h.rp_gray
-tx_reset : 1'b0
-areset : 1'b0
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : two_dff_62001
Checker Class : CDC
Checker Internal
4. Four-latch synchronizer:
always @ (*)
if (rx_clk) begin
sync1 <= tx_sig;// 1st latch tx_sig rx_sig
sync3 <= sync2; // 3rd latch
end
else begin tx_clk rx_clk
sync2 <= sync1; // 2nd latch
rx_sig <= sync3;// 4th latch
end
Evaluations
=============================================================
Single-bit signal synchronized by latch synchronizer. (four_latch)
-----------------------------------------------------------------
tx_clk : start : tx_sig (four_latch.v : 8)
rx_clk : end : sync1 (four_latch.v : 8) (ID:four_latch_51294)
via : sync1

July 2013
Reference
handshake
handshake
HANDSHAKE: Handshake synchronization.
MUX recirculation
ack-tx path en
DEST FSM
SRC FSM
rx_clk
tx_clk
handshake loop
acknowledge synchronizer request synchronizer
Specifying the cdc preference directive with the -handshake_scheme option directs CDC static
analysis to identify DMUX synchronization schemes like that shown above as HANDSHAKE
CDC schemes. Like DMUX synchronization, handshake synchronization uses a synchronized
select signal to enable a data MUX to pass through data to the receive clock domain. Handshake
synchronization has additional synchronization of the receive data MUX select signal back to
the transmit clock domain as feedback into the select logic. This “round-trip” synchronizer
circuit automatically resets the receive domain MUX select signal. The enable signal to the
transmit data MUX select also activates the receive data MUX select via the round-trip
synchronizer.
Crossing Type
data bus
Default Severity
evaluation
Promoted Checkers
• No checker is promoted for the handshake protocol.
• A cdc_dsel checker is promoted for the DMUX synchronization.
• Two cdc_sync checkers are promoted for the round-trip synchronizer.

July 2013
Reference
handshake
Examples
cdc preference -handshake_scheme
cdc report scheme handshake -severity caution
2. In the following CDC report entry, the two synchronizers are the two 2DFF
synchronizers in the round-trip synchronizer circuit.
Cautions
=================================================================
Handshake synchronization. (handshake)
-----------------------------------------------------------------
ClkO : start : DMUXInLtch (Sync_ReqAck.v: 107)
ClkR : end : DMUXOutLtch (Sync_ReqAck.v: 114)(ID:handshake_21466)
Synchronizer ID : pulse_sync_28075
Request Signal: ReqInO
Acknowledge Signal: AckIn
3. Following example shows an instance of a handshake scheme. This scheme is a special

case of a DMUX scheme and by default, is reported as such. To turn on HANDSHAKE
reporting:
cdc preference -handshake_scheme
The following code implements handshake synchronization:

// transmit data register
always @ (posedge tx_clk)
if (enable & ack_synced) tx_data <= din;
// receive data register

if (ack) rx_data <= tx_data;
// generate request
always @ (posedge tx_clk) req <= (req | enable) & !ack_synced;
// generate acknowledge
always @ (posedge rx_clk) ack <= req_synced;
// acknowledge synchronizer in TX domain

always @ (posedge tx_clk) begin: ACK_SYNC
reg temp;
temp <= ack;
ack_synced <= temp;
end
// request synchronizer in RX domain

always @ (posedge rx_clk) begin: REQ_SYNC
reg temp;
temp <= req;
req_synced <= temp;
end

July 2013
Reference
handshake
ack_synced
req ack
req_synced
enable
din en tx_data en rx_data
data flow
tx_clk rx_clk
Handshake synchronization. (handshake)

-----------------------------------------------------------------
tx_clk : start : tx_data (handshake.v : 11)
rx_clk : end : rx_data (handshake.v : 11) (ID:handshake_7492)
Request Signal: req
Acknowledge Signal: ack

July 2013
Reference
multi_bits
multi_bits
MULTIPLE BITS: Multiple-bit signal across clock domain boundary.
additional logic
driven by signal
tx_data rx_data
DFF DFF
tx_clk rx_clk
tx_data ? rx_data
tx_clk missing rx_clk

synchronizer
An unsynchronized CDC data bus in most cases should be a static violation. Similarly, a CDC
data bus synchronized using a 2DFF synchronizer should not drive any logic from the wire
connecting the two flip-flops. However, some data buses from test or configuration logic might
be constant or ad hoc synchronous with the receive clock domain. Similarly, test or
configuration logic driven by the wire connecting the two flip-flops of a 2DFF synchronizer
might also be constant or ad hoc synchronous with the receive clock domain. The severity of
these crossing schemes are typically set to caution.
Crossing Type
multibit data bus
Default Severity
violation
Promoted Checker
cdc_sample
Examples
1. Following is an example to turn reporting off for the status_test signal in module dut:
cdc crossing off -from status_test -module dut

July 2013
Reference
multi_bits
2. Example promoted transfer protocol checker for multi_bits synchronization (in

cdc_checker.rpt):
Type/Name : cdc_sample dut.multi_bits_2760
Description : Ensures that data between two clock domains
remain stable in the transmit domain for one
transmit clock cycle before, and for one
transmit clock cycle after, it is sampled in
the receive domain.
Message : <None>
Location : File .../multi_bits.v, Line 11
Directive : cdc_sample
-tx_var tx_reg
-tx_clock tx_clk
-rx_var rx_reg
-rx_clock rx_clk
-reference multi_bits_2760
-name multi_bits_2760
-module dut
-inferred
Module : dut
Check hold : On <Default On>
Check setup : On <Default On>
-tx_var : tx_reg
-rx_var : rx_reg
-rx_enable : 1'b1
-tx_clock : tx_clk
-rx_clock : rx_clk
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : 1'b0
-rx_areset : 1'b0
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-name : multi_bits_2760
Checker Class : CDC
Checker Internal
3. Multibit Tx signal is read without synchronization in the Rx domain.

rx_bus <= tx_bus; tx_bus rx_bus
tx_clk rx_clk
Violations
==============================================================
-----------------------------------------------------------------
tx_clk : start : tx_bus (multi_bits.v : 11)
rx_clk : end : rx_bus (multi_bits.v : 11) (ID:multi_bits_2760)

July 2013
Reference
multi_sync_mux_select
MULTIPLE SYNCHRONIZERS AT DMUX: MUX select fan-in contains more than one
synchronizer.
tx_data rx_data
MUX DFF
rx_sel
tx_sel1
DFF DFF
tx_clk rx_clk
tx_sel2
DFF DFF
In most cases, if a MUX select is used to synchronize a signal or data bus, then the MUX select
fan-in should not have more than one synchronizer. However, some synchronization schemes
are tolerant of this type of synchronization scheme. In this case, the two synchronizers
reconverge at the MUX select. So, a reconvergence scheme is reported in addition to the
multi_sync_mux_select scheme.
This crossing type is also reported for multiply-synchronized signals in the fanin of an enable.
Crossing Type
Default Severity
caution
Promoted Checker
cdc_dsel
Examples
cdc report scheme multi_sync_mux_select -severity evaluation

cdc promote scheme multi_sync_mux_select -promotion off

July 2013
Reference
3. DMUX synchronizer with multiple control signals synchronized in the Rx domain:

tx_sel1 s1_sel1 s2_sel1
DFF DFF
tx_clk rx_clk
tx_sel2 s_sel2[1]
shift register
MUX rx_data
tx_data

reg s1_sel1, s2_sel1;
reg [1:0] s_sel2;
s1_sel1 <= tx_sel1;
s2_sel1 <= s1_sel1;
s_sel1 <= {s_sel2[0], tx_sel2};
if (s_sel2[1] | s2_sel1)
rx_data <= tx_data;
end
Cautions
=============================================================
Mux select fanin contains more than one synchronizer.
(multi_sync_mux_select)
-----------------------------------------------------------------
tx_clk: start: tx_data (test31.v: 9)
rx_clk: end: rx_data (test31.v: 6)(ID:multi_sync_mux_select_53401)
Synchronizer ID : shift_reg_41011

July 2013
Reference
mux_lock_dmux
mux_lock_dmux
MUX_LOCK_DMUX: MUX lock enable.
tx_data MUX MUX rx_data
tx_lock rx_lock rx_clk

Tx Clock Domain tx_clk Rx Clock Domain
The mux-lock DMUX scheme is a restricted version of the general DMUX scheme. For the
The mux-lock DMUX scheme has the following restrictions:
• Logic between the enabled Tx signal and the Rx signal has a MUX.
• Rx output feeds back to the MUX input.
• Logic between the Tx signal and the enabled Tx signal has a MUX and a second Tx
register.
• Tx register output feeds back to the MUX input.
• First Tx register clock is inverted to clock the second Tx signal.
• First Tx, second Tx and Rx drivers are registers.
• A cdc dmux directive is used to specify the Tx lock signal (–tx_enable) and Rx lock
signal (–rx_enable).
Note
changes value.
Crossing Type
Default Severity
caution
Promoted Checker
cdc_dsel

July 2013
Reference
mux_lock_dmux
Examples
cdc report scheme mux_lock_dmux -severity evaluation
2. Following is an example to turn on promotion:

cdc promote scheme mux_lock_dmux -promotion on

Message : <None>
Line 336
-tx_data tx_mask_d
-rx_data mask
-tx_min 1
-areset ( ! rst)
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
-rx_data : mask
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal

July 2013
Reference
no_sync
no_sync
MISSING SYNCHRONIZER: Single-bit signal does not have proper synchronizer.
additional logic
driven by signal
tx_sig rx_sig
DFF DFF
tx_clk rx_clk
tx_sig ? rx_sig
tx_clk missing rx_clk

synchronizer
An unsynchronized CDC signal is typically a static violation, but if such a crossing terminates
at a black box module or RAM, the default severity is reported as caution (because
synchronization might occur in the black box). Similarly, a CDC signal synchronized using a
2DFF synchronizer that drives logic from the wire connecting the two flip-flops is reported as a
static violation by default.
Some signals from test or configuration logic might be constant or ad hoc synchronous with the
receive clock domain. Also, test or configuration logic driven by the wire connecting the two
flip-flops of a 2DFF synchronizer might also be constant or ad hoc synchronous with the
receive clock domain. The severity of these crossing schemes are typically set to caution.
Crossing Type
1-bit signal
Default Severity
violation or caution
Promoted Checker
cdc_sample

July 2013
Reference
no_sync
Examples
1. Following is an example to turn severity to caution for the write_test signal in the
module dut:
cdc report crossing -severity caution -scheme no_sync \
-from write_test -module dut
2. Example promoted transfer protocol checker for no_sync synchronization (in

cdc_checker.rpt):
Type/Name : cdc_sample dut.no_sync_59042
Description : Ensures that data between two clock domains
remain stable in the transmit domain for one
transmit clock cycle before, and for one
transmit clock cycle after, it is sampled in
the receive domain.
Message : <None>
Location : File .../no_sync.v, Line 9
Directive : cdc_sample
-tx_var tx_sig
-tx_clock tx_clk
-rx_var rx_sig
-rx_clock rx_clk
-reference no_sync_59042
-name no_sync_59042
-module dut
-inferred
Module : dut
Check hold : On <Default On>
Check setup : On <Default On>
-tx_var : tx_sig
-rx_var : rx_sig
-rx_enable : 1'b1
-tx_clock : tx_clk
-rx_clock : rx_clk
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : 1'b0
-rx_areset : rst
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-name : no_sync_59042
Checker Class : CDC
Checker Internal
3. Tx signal is read without synchronization in the Rx domain.

always @(posedge rx_clk, posedge rst)
if (rst) tx_sig rx_sig
rx_sig <= 1’b1;
else
rx_sig <= tx_sig; tx_clk rx_clk

July 2013
Reference
no_sync
Violations
==============================================================
-----------------------------------------------------------------
tx_clk : start : tx_sig (no_sync.v : 9)
rx_clk : end : rx_sig (no_sync.v : 9) (ID:no_sync_59042)

July 2013
Reference
port_constraint_mismatch
PORT CONSTRAINT MISMATCH: Signal connected to a port of a custom synchronizer is in
a clock domain that is not allowed by the custom synchronizer’s port constraints.
illegal Tx clock domain for port
tx_sig rx_sig
custom
port synchronizer
constraint
tx_clk rx_clk
illegal Rx clock domain for port
illegal Tx clock illegal Rx clock

domain for port domain for port
tx_sig rx_sig
custom synchronizer
port with crossing port
constraint constraint
tx_clk rx_clk
A CDC port constraint identifies all clock domains allowed for signals connected to instances of
the port. A port constraint is specified using the netlist port constraint directive. Currently port
constraints are supported only for design units that are custom synchronizers (i.e., identified
with the cdc synchronizer custom directive).
Custom Synchronizer
For a standard custom synchronizer, you can specify a CDC port constraint on any of its signal
and data bus input ports. The constraint can specify allowed clock domains for signals
connected to it, allowed clock domains for the signal that clocks the port, or both. You also can
specify allowed pairs of clock domains for instances of the port: one for the signal connected to
the port and one for signal that clocks the port. A constrained port of an instance of the design
unit has a port constraint mismatch if one of the following holds:
• The signal connected to the port is not from an allowed transmit clock domain for the
port.
• The signal clocking the port is not from an allowed receive clock domain for the port.
• The domain of the transmit signal and the domain of the receive clock signal are not an
allowed clock domain pair for the port.
Custom Synchronizer with Crossing
For a custom synchronizer with crossing, you can specify CDC port constraints on its signal and
data bus ports. These identify the allowed clock domains for signals connected to them.

July 2013
Reference
Crossing Type
Default Severity
violation
Promoted Checker
none
Examples
1. Following is an example to turn severity to evaluation for port constraint mismatches for
custom synchronizers in module prk:
cdc report crossing -severity evaluation \
-scheme port_constraint_mismatch -from write_test -module prk
2. The following custom synchronizer is defined:

module cust_sync(input rx_clk, din1, din2, output reg dout);
dout = din1 | din2 ; // Expressions inside custom synchronizer
// not considered
endmodule
The specifications for cust_sync are:

netlist port domain din* -async -clock rx_clk -module cust_sync
netlist port domain dout -clock rx_clk -module cust_sync
To ensure instances of cust_sync are properly connected, the following port constraints
are defined:
cdc port constraint cust_sync -ports din1 \
-clock_group_pair tx_clk rx_clk
cdc port constraint cust_sync -ports din2 -rx_clock_groups tx_clk
But, the following top module instantiates cust_sync in a way that obeys the first
constraint (reported as a custom_sync crossing), but violates the second constraint
(reported as a port_constraint_mismatch).

July 2013
Reference
module dut(
input tx_clk, rx_clk, din1
input din1, din2,
output reg dout); tx_clk dout
cust_sync1
reg tx_sig1, tx_sig2, rx_sig; din2
rx_clk
// Transmit register
always @ (posedge tx_clk) begin
tx_sig1 <= din1;
tx_sig2 <= din2;
end
// Custom synchronizer
cust_sync cust_sync1 (rx_clk, tx_sig1, tx_sig2, rx_sig);
// Signal output from the custom synchronizer

always @ ( posedge rx_clk ) dout <= rx_sig ;
endmodule
Violations
=================================================================
Port constraints mismatch: cust_sync (port_constraint_mismatch)
-----------------------------------------------------------------
tx_clk : start : tx_sig2 (.../port_constraint_mismatch.v : 21)
rx_clk : end : cust_sync1.din2 (...constraint_mismatch.v : 32)
(ID:port_constraint_mismatch_18308)
Evaluations
=================================================================
Single-bit signal synchronized by Custom CDC scheme: cust_sync
(custom_sync)
-----------------------------------------------------------------
tx_clk : start : tx_sig1 (.../port_constraint_mismatch.v : 21)
rx_clk : end : cust_sync1.din1 (...constraint_mismatch.v : 32)
(ID:custom_sync_53909)

July 2013
Reference
pulse_sync
pulse_sync
PULSE SYNC: Pulse Synchronization.
rx_sig
tx_sig
DFF DFF DFF
tx_clk rx_clk
Pulse synchronization is a standard method of synchronizing a 1-bit signal. A variation of this

scheme happens if the pulse output is delayed. Specify the cdc preference -delayed_pulse
directive to recognize such schemes as pulse_sync schemes.
rx_sig
tx_sig
DFF DFF DFF DFF
tx_clk rx_clk
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
cdc report scheme pulse_sync –severity caution

cdc promote –scheme pulse_sync –promotion off
3. Example promoted transfer protocol checker for the pulse_sync synchronization scheme
Type/Name : cdc_sync dut.pulse_sync_1845
Description : Ensures that a clock domain crossing signal
from a faster clock to a slower clock is
held stable long enough for the signal to be
sampled reliably by the receiver.
Message : <None>
Location : File .../pulse_sync.v, Line 8
Directive : cdc_sync

July 2013
Reference
pulse_sync
-tx_var tx_sig
-tx_clock tx_clk
-tx_min 2
-reference pulse_sync_1845
-name pulse_sync_1845
-module dut
-inferred
Module : dut
Check stable : On <Default On>
-tx_var : tx_sig
-tx_clock : tx_clk
-tx_reset : 1'b0
-active : 1'b1
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : pulse_sync_1845
Checker Class : CDC
Checker Internal
4. Standard pulse synchronizer:

reg p0, p1, p2, pulse;
always @ (posedge rx_clk) tx_sig pulse
begin
p0 <= tx_sig; // 1st flop
p1 <= p0; // 2nd flop
p2 <= p1; // 3rd flop
end tx_clk rx_clk
always @ * pulse <= p1 ^ p2;
Evaluations
=============================================================
Pulse Synchronization. (pulse_sync)
-----------------------------------------------------------------
tx_clk: start: tx_sig (pulse_sync.v : 8)
rx_clk: end: PULSE_SYNC.p0 (pulse_sync.v :16)
(ID:pulse_sync_1845)
5. Pulse synchronizer with delay. To detect this type of synchronizer, specify:

cdc preference -delayed_pulse
reg p0, p1, p2, pulse, dpulse; pulse

always @ (posedge rx_clk) tx_sig
begin dpulse
p0 <= tx_sig; // 1st flop
p1 <= p0; // 2nd flop
p2 <= p1; // 3rd flop
dpulse <= pulse;// 4th flop tx_clk rx_clk
end
always @ * pulse <= p1 ^ p2;

July 2013
Reference
pulse_sync
Evaluations
=============================================================
Pulse Synchronization. (pulse_sync)
-----------------------------------------------------------------
tx_clk: start: tx_sig (pulse_sync.v : 8)
rx_clk: end: PULSE_SYNC.p0 (pulse_sync.v :16)
(ID:pulse_sync_1845)

July 2013
Reference
reconvergence
reconvergence
RECONVERGENCE: Reconvergence of synchronizers.
reconverging signals
sig1 tx_sig1 rx_sig
tx/rx_clk
sig2 tx_sig2
Source Clock Domains Tx/Rx Clock Domain
Reconvergence occurs when the fan-in of a flip-flop includes two separately synchronized CDC
signals from a different clock domain. The synchronizers can be any of the following:
bus_dff_sync_gated_clk, bus_four_latch, bus_shift_reg, bus_two_dff, bus_two_dff_phase or
two_dff_phase, dff_sync_gated_clk, four_latch. shift_reg, two_dff, pulse_sync and custom.
Reconvergence of two signals might result in synchronization problems. When multiple bits
reconverge, their relative timing is unpredictable. Logic that receives these signals should
account for potential cycle skew—for example, by using a hamming encoding scheme for
signals in the receiving domain. For signals that have large guard times between changes, this
encoding happens naturally.
If it is not feasible to either design receiving logic that accounts for the potential cycle skew or
encode the signals, then you should group the signals and transfer them as a group using a
synchronized MUX enable (as used for multiple-bit data signals). To force CDC analysis to
recognize reconvergence schemes that start from a dmux, simple_dmux or
multi_sync_mux_select scheme, specify cdc preference reconvergence -dmux_as_recon_start.
Crossing Type
multiple control signals or data buses
Default Severity
caution
Promoted Checker
cdc_hamming1 (if enabled, see cdc preference).

July 2013
Reference
reconvergence
Examples
1. Following is an example to change the reconvergence depth to 4:
cdc preference reconvergence -depth 4
2. Following is an example that disables reconvergence analysis to reduce run time.

cdc reconvergence off
3. Following example shows an instance of a reconvergence scheme that is reported when

reconvergence depth is 0. The following code shows the reconvergence point and the
two synchronizers on the reconverging paths.
// Tx signals
tx1 <= in1;
tx2 <= in2;
end
// two_dff synchronizer
always @ (posedge rx_clk) begin: two_dff
reg temp;
temp <= tx1;
two_dff_sync <= temp;
end
// shift_reg synchronizer
always @ (posedge rx_clk) begin: shift_reg
shift_reg_sync <= {shift_reg_sync[0], tx2};
end
// reconvergence point (depth 0)
dout <= two_dff_sync ^ shift_reg_sync[1];
shift_reg_sync[0] reconvergence point

[1]
in2 tx2 shift_reg_sync[1]
dout
[0] shift register
tx_clk rx_clk
in1 tx1 temp two_dff_sync

DFF DFF
Cautions
=================================================================
-----------------------------------------------------------------
rx_clk : end : dout (reconvergence.v : 5) (ID:reconvergence_78116)
rx_clk : start : shift_reg_sync (reconvergence.v : 10)
rx_clk : start : two_dff_sync (reconvergence.v : 9)

July 2013
Reference
reconvergence
4. Following example shows an instance of a reconvergence scheme that is reported when

reconvergence depth is 1. To set the depth:
cdc preference reconvergence -depth 1
The following code shows the reconvergence point and the two synchronizers on the
reconverging paths.
// Tx signals
tx_data1 <= din1;
tx_data2 <= din2;
end
// bus two_dff synchronizer
reg [3:0] temp;
temp <= tx_data1;
end
shift_reg_sync <= {shift_reg_sync[3:0], tx_data2};
end
// reconvergence point (depth 1)
always @ (posedge rx_clk) begin
rx1 <= two_dff_sync;
rx2 <= shift_reg_sync[7:4];
dout <= rx1 - rx2;
end
shift_reg_sync[3:0]
[7:4]
shift_reg_sync[7:4] rx2
in1 tx_data1 shift register
reconvergence point
rx_clk
tx_clk
temp two_dff_sync rx1 dout
–
in2 tx_data2 DFF DFF
Cautions
=================================================================
-----------------------------------------------------------------
rx_clk : end : dout (test4.v : 5) (ID:reconvergence_78116)
rx_clk : start : shift_reg_sync (test4.v : 10)
(Synchronizer ID:bus_shift_reg_96629)
rx_clk : start : two_dff_sync (test4.v : 9)
(Synchronizer ID:bus_two_dff_9116)

July 2013
Reference
redundant
redundant
REDUNDANT: Redundant synchronization.
rx_sig1
synchronizer
tx_sig
rx_clk
tx_clk
synchronizer rx_sig2
Redundant synchronizers are multiple synchronizers in the same clock domain that synchronize
the same CDC signal. The values of the rx_sig1 and rx_sig2 signals might not match, because
of metastability. If these separately synchronized signals are in the fan-in of the same flip-flop,
then a reconvergence problem might exist. But, even if they are not, redundant synchronizers
create extra logic that can be eliminated by splitting the signals after they are synchronized.
Crossing Type
Default Severity
caution
Promoted Checker
none
Example
1. Following is an example to disable reporting of redundant synchronizers on *_en
signals:
cdc crossing off -from *_en

July 2013
Reference
redundant
2. Redundant synchronizers: shift register plus two dff synchronization:

// two_dff synchronizer of tx_sig
reg s0 , s1;
s0 <= tx_sig; // 1st flop
s1 <= s0; // 2nd flop
end
// two_dff synchronizer of tx_sig

reg [1:0] sh_reg;
sh_reg <= {sh_reg[0], tx_sig};
end
sh_reg[0]
[1]
tx_sig shift_reg.sh_reg
[0] shift_reg
redundantly synchronized
signals
tx_clk rx_clk
DFF twc_dff.s0 DFF two_dff.s1
Violations
=================================================================
Redundant synchronization. (redundant)
-----------------------------------------------------------------
tx_clk: start: tx_sig (redundant.v: 4) (ID:redundant_87696)
rx_clk: end: shift_reg.sh_reg (redundant.v : 20)
rx_clk: end: two_dff.s1 (redundant.v: 12)

July 2013
Reference
series_redundant
series_redundant
SERIES REDUNDANT: Custom synchronizers connected in series.
Tx synchronizer Rx synchronizer
tx_sig rx_sig
custom custom
synchronizer synchronizer
tx_clk rx_clk
Series redundant synchronizers are custom synchronizers connected in series, which

synchronize to the same clock domain or do not have a specified clock domain. To determine if
two custom synchronizers in series are in the same domain, the clock domain of the output of
the Tx synchronizer is matched with the clock domain of the input of the Rx synchronizer. If a
custom synchronizer’s input port is driven by an element in the same clock domain, that custom
synchronizer also is reported as series redundant.
CDC analysis does not report custom synchronizers in series as series redundant if one of the
synchronizers’ ports is specified as asynchronous. However, series redundant synchronizers are
reported even if they are not used in a clock domain crossing. Use the
-print_detailed_custom_sync CDC preference to report custom synchronizers that are not used
in a clock domain crossing. Series-redundant synchronizers do not indicate CDC problems, but
they do indicate a waste of logic and power consumption.
Note
Series redundant scheme detection is off by default. Use cdc preference
-series_redundant_scheme to turn on detection of this scheme.
Crossing Type
Default Severity
caution
Promoted Checker
none
Examples
1. Following is an example to disable reporting of series redundant synchronizers on *_en
signals from the tx_clk domain:
cdc crossing off -from *_en

July 2013
Reference
series_redundant
2. Custom synchronizers connected in a redundant series

custom_sync #(4)
cust_sync_A(
.clk (rx_clk),
.d (tx_data),
.q (cust_sync_A_out));
custom_sync #(4)
cust_sync_B(
.clk (rx_clk),
.d (cust_sync_A_out),
.q (cust_sync_B_out));
cust_sync_A_out
tx_data cust_sync_B_out
cust_sync_A cust_sync_B
rx_clk
tx_clk
Series Redundant synchronization. (series_redundant)

-----------------------------------------------------------------
rx_clk: start: custom_sync_A.q (series_redundant.v : 27)
rx_clk: end: custom_sync_B.d (series_redundant.v : 29)
(ID:series_redundant_93597)

July 2013
Reference
shift_reg
shift_reg
SHIFT REG: Shift-register synchronization.
tx_sig rx_sig
shift register
tx_clk rx_clk
Synchronization using a shift register is a standard method of synchronizing a 1-bit signal. It is

equivalent to synchronization with two or more in-phase flip-flops. The difference is in the
coding templates recognized by the two schemes. The following example shows the code for a
shift register synchronization scheme:
reg [n:0] shftreg

always @(clock)
shftreg <= {shftreg[n-1:0],din};
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
cdc report scheme shift_reg –severity caution

cdc promote scheme shift_reg –promotion off
3. Example promoted transfer protocol checker for shift_reg synchronization scheme (in
cdc_checker.rpt):
Type/Name : cdc_sync dut.shift_reg_99229
Message : <None>
Location : File .../cdc_shift_reg/shift_reg.v, Line 10
-tx_var tx_sig
-tx_clock tx_clk

July 2013
Reference
shift_reg
-tx_min 2
-reference shift_reg_99229
-name shift_reg_99229
-module dut
-inferred
Module : dut
-tx_var : tx_sig
-tx_clock : tx_clk
-tx_reset : 1'b0
-active : 1'b1
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : shift_reg_99229
Checker Class : CDC
Checker Internal
4. Shift register synchronizer:

// shift_levels = 8
always @ (posedge rx_clk) begin shift_reg
reg [1:shift_levels] shift_reg_sync;
shift_reg <= {tx_sig, shift_reg_sync[1:shift_levels-1]} ;
end
shift_reg_sync[1:7] synchronized signal
[0:6]
tx_sig
[7] shift register shift_reg_sync[8]
tx_clk rx_clk
Evaluations
=============================================================
Shift-register synchronization. (shift_reg)
-----------------------------------------------------------------
tx_clk : start : tx_sig (shift_reg.v : 10)
rx_clk : end : shift_reg.shift_reg_sync[1] (shift_reg.v : 19)
(ID:shift_reg_99229)

July 2013
Reference
simple_dmux
simple_dmux
SIMPLE_DMUX: Simple MUX enable.
tx_data MUX rx_data
tx_clk
tx_sel
DFF DFF
rx_sel
tx_clk rx_clk
The simple DMUX scheme is a restricted version of the general DMUX scheme. For the
The simple DMUX scheme has the following restrictions:
• Logic between the Tx and Rx signals has a MUX.

• Rx output feeds back to the MUX input.
• Tx signal drives the D-input of the Rx register
• No combo logic is between the Tx and Rx registers.
• No combo logic is between select output from the synchronizer and the MUX.
Note
changes value.
Crossing Type
Default Severity
caution
Promoted Checker
cdc_dsel

July 2013
Reference
simple_dmux
Examples
cdc report scheme simple_dmux -severity evaluation

cdc promote scheme simple_dmux -promotion off

Message : <None>
Line 336
-tx_data tx_mask_d
-rx_data mask
-tx_min 1
-areset ( ! rst)
-name dmux_12402
-module demo_top
-inferred
Module : demo_top
-rx_data : mask
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-TX_MIN : 1
-name : dmux_12402
Checker Class : CDC
Checker Internal

July 2013
Reference
simple_dmux
4. Bus synchronized by a simple DMUX synchronizer:
always @(posedge rx_clk) rx_data

tx_data
begin: DMUX
reg s1, rx_sel; MUX
s1 <= tx_sel; // 1st DFF tx_clk
rx_sel <= s1; // 2nd DFF s1
tx_sel
if (rx_sel) DFF DFF
rx_data <= tx_data; rx_sel
end
rx_clk
Cautions
=============================================================
Simple DMUX synchronization. (simple_dmux)
-----------------------------------------------------------------
tx_clk : start : tx_data (simple_dmux.v : 9)
rx_clk : end : rx_data (simple_dmux.v : 6) (ID:simple_dmux_44768)

July 2013
Reference
SSR: Single-source reconvergence of synchronizers.
single source reconverging signals
tx/rx_clk
clk
Source Clock Domain Tx/Rx Clock Domain
Reconvergence occurs when the fan-in of a flip-flop includes two separately synchronized CDC
signals from a different clock domain. Single-source reconvergence is the special case where
reconverging signals in the receive domain originate from the same signal in the transmit
domain. Reconvergent signals might result in synchronization problems, but large designs can
have large numbers of reconvergence paths. Single-source reconvergence paths are more likely
to cause design problems than reconvergence paths from unrelated sources, so they can be given
a higher priority when resolving issues of reconvergence.
Static CDC analysis reports single-source reconvergence paths as both reconvergence violations
and SSR violations. The cdc preference reconvergence directive adjusts two parameters used to
determine how extensive static CDC analysis of reconvergence paths should be:
• depth
Maximum number of sequential levels in the receive domain from the synchronizers to
the reconverging paths. The depth is used to limit analysis of reconverging paths (both
single-source and separate-source).
• divergence depth
Maximum number of sequential levels in the transmit domain from the flip-flops driving
the synchronizers backwards to the single source. The depth is used to limit analysis of
single-source reconverging paths.
By default, instances of single-source reconvergence are reported only as instances of the
reconvergence scheme. Specifying cdc preference reconvergence -divergence_depth <depth>
enables SSR reporting for matching divergence/reconvergence paths (a divergence_depth of 0
turns on single-source reconvergence reporting from divergence points with no sequential levels
before the synchronizers).
Crossing Type

July 2013
Reference
Default Severity
violation
Promoted Checker
cdc_hamming1 (if enabled, see cdc preference).
Examples
1. Following is an example to disable reporting of single-source reconvergence points
originating in the tx_clk domain:
cdc crossing off -scheme single_source_reconvergence \
-tx_clock tx_clk
2. Following is an example to change the severity of single-source reconvergence points

originating from the cluster of synchronizers driving stat1, stat2, and stat3:
cdc report crossing -severity evaluation \
-scheme single_source_reconvergence \
-from_signals stat1 stat2 stat3
3. Following is an example to change the reconvergence depth to 4 and enable single-

source reconvergence reporting with a divergence depth of 5:
cdc preference reconvergence -depth 4 -divergence_depth 5
4. Following examples change the reconvergence depth and enables single-source

reconvergence reporting:
divergence depth = 3 depth = 1
0
1 synchronizer
2
0
3 1 synchronizer
2
0
1 synchronizer
Tx Clock Domain Rx Clock Domain reported single-source

reconvergence paths

July 2013
Reference

divergence depth = 2
depth = 1
synchronizer
synchronizer
synchronizer
Tx Clock Domain Rx Clock Domain reported single-source

reconvergence paths
5. Following example shows an instance of a single-source reconvergence scheme that is
reported when divergence depth is 0. SSR reporting is off by default, so turn on SSR
reporting:
cdc preference reconvergence -divergence_depth 0
The following code shows the divergence and reconvergence points and the two
synchronizers on the reconverging paths.
// divergence point
always @ (posedge tx_clk)
ctrl <= ci0 | ci1 ;
reg temp;
temp <= ctrl;
end
shift_reg_sync <= {shift_reg_sync[0], ctrl};
end
// reconvergence point
dout <= two_dff_sync ^ shift_reg_sync[1];
divergence point shift_reg_sync[0] reconvergence point

[1]
ctrl shift_reg_sync[1]
dout
[0] shift register
tx_clk rx_clk
divergence depth = 0 DFF DFF two_dff_sync

July 2013
Reference

-----------------------------------------------------------------
rx_clk : end : dout (single_source_reconvergence.v : 5)
rx_clk: start: shift_reg_sync(single_source_reconvergence.v : 10)
rx_clk : start : two_dff_sync (single_source_reconvergence.v : 9)
tx_clk : diverge : ctrl (single_source_reconvergence.v : 8)
6. Following example shows an instance of a single-source reconvergence scheme that is

reported when divergence depth is 1. SSR reporting is off by default, so turn on SSR
reporting:
cdc preference reconvergence -divergence_depth 1
The following code shows the divergence and reconvergence points and the two
synchronizers on the reconverging paths.
// divergence point
diverge <= diverge + 1; // 1 level to sync
tx_data1 <= din + diverge; // 0 levels to sync
tx_data2 <= ~diverge; // 0 levels to sync
end
reg [3:0] temp;
temp <= tx_data1;
end
// bus_shift_reg synchronizer
shift_reg_sync <= {shift_reg_sync[3:0], tx_data2};
end
// reconvergence point
always @ ( posedge rx_clk )
dout <= two_dff_sync - shift_reg_sync[7:4];
divergence point shift_reg_sync[3:0] reconvergence point

[7:4]
diverge [3:0] shift_reg_sync[7:4]
bus shift dout
tx_data2 –
register
tx_clk rx_clk
din +
tx_data1 two_dff_sync
DFF DFF
divergence depth = 1

July 2013
Reference

-----------------------------------------------------------------
rx_clk : end : dout (single_source_reconvergence.v : 5)
rx_clk: start: shift_reg_sync (single_source_reconvergence.v : 10)
(Synchronizer ID:bus_shift_reg_96629)
rx_clk : start : two_dff_sync (single_source_reconvergence.v : 9)
(Synchronizer ID:bus_two_dff_9116)
tx_clk : diverge : diverge (single_source_reconvergence.v : 8)

July 2013
Reference
two_dff
two_dff
TWO DFF SYNCHRONIZER: Single-bit signal synchronized by DFF synchronizer.
tx_sig rx_sig
DFF DFF
tx_clk rx_clk
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal.
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
cdc report scheme two_dff –severity caution

cdc promote scheme two_dff –promotion off
3. Example promoted transfer protocol checker for the two_dff synchronization scheme (in
cdc_checker.rpt):
Type/Name : cdc_sync dut.two_dff_32868
Message : <None>
Location : File .../two_dff.v, Line 9
-tx_var tx_sig
-tx_clock tx_clk
-tx_min 2
-reference two_dff_32868
-name two_dff_32868
-module dut
-inferred
Module : dut
-tx_var : tx_sig

July 2013
Reference
two_dff
-tx_clock : tx_clk
-tx_reset : 1'b0
-active : 1'b1
-areset : rst
-support : 1'b0
-nv : 1'b1
-TX_MIN : 2
-name : two_dff_32868
Checker Class : CDC
Checker Internal
4. Single-bit signal synchronized by two cascaded flip-flops:

s0 <= tx_sig; // 1st DFF tx_sig s0 s1
s1 <= s0; // 2nd DFF DFF DFF
end
tx_clk rx_clk
Evaluations
=================================================================
-----------------------------------------------------------------
tx_clk : start : tx_sig (two_dff.v : 9)
rx_clk : end : s0 (two_dff.v : 10) (ID:two_dff_32868)

July 2013
Reference
two_dff
5. Single-bit signal synchronized by two cascaded flip-flops with enable ports:

cdc preference -allow_enable_in_sync
always @(posedge rx_clk) enable

if (enable) tx_sig EN EN
{s0, s1} <= {tx_sig, s0};
s0 s1
tx_clk rx_clk
Evaluations
=============================================================
-----------------------------------------------------------------
tx_clk : start : tx_sig (two_dff.v : 9)
rx_clk : end : s0 (two_dff.v : 10) (ID:two_dff_32868)
Notes
If you use a DFF synchronization scheme that has more than two flip-flops, then you can get
CDC analysis to recognize the scheme by specifying a cdc synchronizer directive. For example,
the following CDC directive identifies 4 DFF synchronizers as valid “two_dff” schemes for
CDC paths from the tx_clk domain to the rx_clk domain:
cdc synchronizer dff -level 4 -tx_clock tx_clk -rx_clock rx_clk

July 2013
Reference
two_dff_phase
two_dff_phase
TWO DFF SYNCHRONIZER OPPOSITE POLARITY: Single-bit signal synchronized by DFF
of opposite clock polarity.
tx_sig rx_sig
DFF DFF
tx_clk rx_clk
Synchronization using two opposite polarity flip-flops has a reduced time for rx_sig to settle.
When using this synchronization scheme, be sure the MTBF is acceptable.
Crossing Type
1-bit signal
Default Severity
caution
Promoted Checker
cdc_sync
Example
cdc report scheme two_dff_phase -severity caution
2. 2DFF phase synchronizer has one FF clocked by a clock with the opposite polarity of
the Rx clock:
tx_sig sync1 sync2
sync1 <= tx_sig; // 1st FF
sync2 <= sync1; // 2nd FF tx_clk rx_clk
Cautions
=============================================================
Single-bit signal synchronized by DFF of opposite clock polarity.
(two_dff_phase)
-----------------------------------------------------------------
tx_clk : start : tx_sig (two_dff_phase.v : 9)
rx_clk : end : s0 (two_dff_phase.v : 10)
(ID:two_dff_phase_42446)

July 2013
Reference
Protocol/FX Checkers
Each checker type has a data sheet that provides the specification for checkers of that type. Data
sheets contain the following information:
• Symbolic Representation
Symbolic representation of a generic checker of that type.
• Description
Description of the properties checked by checkers of the checker type.
• Syntax
Syntax statement for the checker directive.
• Corner Cases
Names of the corner case counts maintained by the checker.
• Statistics
Names of statistics maintained by these checkers, with explanations of each. One
statistic is designated as the evaluation statistic (evals), which typically corresponds to
the number of times the checker evaluated.
• Notes
Notes describing any special features or requirements of these checkers.
• Examples
Examples of directives and checker applications.
Standard Options
One group of options (Table 5-3) is included in every syntax statement (except for certain
special checker types that do not support some of the options). These options are called
standard options and are indicated in syntax statements as:
[standard_option…]
These options are universal—they have the same meaning for each checker type.

July 2013
Reference
Table 5-3. Standard Options of a Checker Directive

standard_options ::=
[-active signal] [-module mod] [-name identifier] [-group identifier] [-message “string”]
[-severity level] [-quiet] [-assume_if constant] [-check_fire signal]…
[-corner_case variable]… [-statistic variable]… [-non_vacuous off]
-active signal Signal to connect to the active input. If < is specified, the active
input is the logical AND of signal with the inferred activation
signal. Default (with <): inferred activation. Default (without <):
always active.
-module mod Module containing the signals and variables probed by the
checker. Default: module containing the directive.
-name Base name for the checker. Default: derived from the directive
{identifier | and hierarchy.
formatted_string}
-group Base name for the checker. Default: derived from the directive
{identifier | and hierarchy.
formatted_string}
-message formatted_string User message shown when the checker fires (in addition to the
firing message). Default: standard message only.
-severity level_constant Sets the severity level of the checker, level_constant is a constant
or parameter that must evaluate to a positive digit [1..9]. You can
override the severity level of a checker with the set_severity
directive. Default severity level is 0.
-quiet Disables reporting of firing data without disabling firing signals
from the checker. Default: firing data for the checker are always
reported.
-assume_if constant If constant is not zero, this option marks all checks for the checker
as check assumptions. If constant is zero, the checks are marked
as targets unless overridden by an enable_assumption or
exclude_target directive. The disable_assumption directive
overrides this setting.
-non_vacuous off Excludes non_vacuous check logic from the formal model.
Default: csl compiles non-vacuity check logic for the checker.
-check_fire signal Connects the firing output for the specified check to the specified
signal. Default: no connection.
-corner_case variable Outputs the specified corner_case count to the specified variable.
Default: no output.
-statistic variable Outputs the specified statistic to the specified variable. Default:
no output.

July 2013
Reference
cdc_dsel
cdc_dsel
default name:
active tx_data_var_tx_data_var
tx_clock tx_data_stable_fire
rx_data_stable_fire firings
checks:
tx_reset
tx_data_select tx_min_fire tx_data_stable (On)
signals rx_data_stable (On)
rx_clock
rx_reset corner tx_min (On)
asserted_for_tx_min cases
rx_data_select
dsel tx_clock, tx_reset, areset:
inferable from
transfers_checked evals tx_data_variable
tx_data longest_assertion
variables
rx_data shortest_assertion statistics rx_clock, rx_reset:
constants tx_min longest_receive_period
shortest_receive_period
inferable from
areset rx_data_variable
vacuity property:
!tx_reset && !rx_reset &&
!areset && active &&
tx_dsel_signal === 0
Description
Ensures that a signal between two clock domains, where the transmitter’s data select signal
drives the select input of a data multiplexor in the receiver, is held stable enough for the signal
to be sampled reliably by the receiver and ensures that the data remains stable while the data
select signal asserts.
Syntax
[<] {cdc_dsel | dsel}
-tx_data tx_data_variable -rx_data rx_data_variable
{-tx_data_select tx_dsel_signal | -tx_data_stable off}
{-rx_data_select rx_dsel_signal | -rx_data_stable off}
[-tx_min tx_min_constant | -tx_min_check off ]
[-tx_clock tx_clock] [-tx_reset tx_reset ] [-rx_clock rx_clock] [-rx_reset rx_reset]
[-assume [all | {txdata | rxdata | txdsel}…]] [standard_option…]
Required Arguments
• -tx_data tx_data_variable
Variable with the transmit data in the transmit clock domain.
• -rx_data rx_data_variable
Variable with the receive data in the receive clock domain.

July 2013
Reference
cdc_dsel
Inferable Options
• [-tx_clock tx_clock] [-tx_reset tx_reset]
Transmit clock and synchronous reset. If unspecified, each is inferable from
tx_data_variable.
• [-rx_clock rx_clock] [-rx_reset rx_reset]
Receive clock and synchronous reset. If unspecified, each is inferable from
rx_data_variable.
Checks and Related Options
• Tx_data_stable check, default On
{-tx_data_select tx_dsel_signal | -tx_data_stable off}
The tx_data_variable value must not change while the data select signal tx_dsel_signal
asserts in the transmit clock domain. This check requires tx_dsel_signal. This check occurs
at the active transmit clock edge. The checker fires each time tx_data_variable improperly
changes. The -tx_data_stable off option turns off this check.
Firing message: ’tx_data_variable’ changed from last_tx_data to current_tx_data in the
data transfer window.
• Rx_data_stable check, default On
{-rx_data_select rx_dsel_signal | -rx_data_stable off}
The rx_data_variable value must not change while the data select signal rx_dsel_signal
asserts in the receive clock domain. This check requires rx_dsel_signal. This check occurs
at the active receive clock edge. The checker fires each time rx_data_variable improperly
changes. The -rx_data_stable off option turns off this check.
Firing message: ’rx_data_variable’ changed from last_rx_data to current_rx_data in the
data transfer window.
• Tx_min check, default On
[-tx_min tx_min_constant | -tx_min_check off ]
The tx_dsel_signal signal must not assert for fewer than tx_min_constant cycles of the
transmit clock. This check requires tx_dsel_signal. This check occurs at the active transmit
clock edge. The checker fires each time tx_dsel_signal improperly deasserts. The
-tx_min_check off option turns off this check. If -tx_min is unspecified, the default
tx_min_constant is 2.
Firing message: ’tx_dsel_signal’ was asserted for number cycles, but the specified
minimum assertion time is tx_min cycles.
Other Options
• [-assume [all {txdata | rxdata | txdsel}…]]
Sets the following checks to formal assumptions:
o all (default) — all enabled checks

July 2013
Reference
cdc_dsel
o txdata — tx_data_stable
o rxdata — rx_data_stable
o txdsel — tx_min
Corner Cases
• Asserted for ’tx_min’ Cycles — number of times tx_dsel_signal asserted for exactly
tx_min_constant cycles. Reported only if the tx_min check is enabled.
Statistics
• Transfers Checked (Evals) — number of data transfers checked.
• Longest Assertion — maximum number of transmit clock cycles tx_dsel_signal remained
active.
• Shortest Assertion — minimum number of transmit clock cycles tx_dsel_signal remained
active.
• Longest Receive Period— maximum number of receive clock cycles tx_dsel_signal
remained active.
• Shortest Receive Period — minimum number of receive clock cycles tx_dsel_signal
remained active.
Notes
The following block diagram shows a typical implementation of a cdc_dsel checker:
TX Module RX Module
tx_dsel rx_dsel
tx_data_select SYNC
cdc_dsel
checker rx_data
MUX
tx_data
tx_data
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock
tx_clock (inferable from -tx_data tx_data_variable) and the receive data are based on -
rx_clock rx_clock (inferable from -rx_data rx_data_variable). The standard -clock
option should not be specified.
2. Asynchronous reset for this checker can be specified using the standard -areset option. If
this option is not specified, then the asynchronous reset is inferred from -tx_data
tx_data_variable. In either case, the reset applies to the entire checker, including logic
on both clocks.
3. This checker is synchronous with respect to each clock, so it responds only to behavior
that is observable at the active edge of the transmit or receive clock.

July 2013
Reference
cdc_dsel
Examples
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data -tx_min 3
-rx_data_stable_off -tx_data_select tx_dsel
-tx_min_fire tx_min_fire */
Checks that tx_dsel does not assert for fewer than 3 cycles of the transmitting domain
clock.
tx_clk
tx_dsel
tx_min_fire
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data

-rx_data_stable off -tx_data_select tx_dsel
-tx_data_stable_fire tx_data_stable_fire */
Checks that the value of tx_data does not change while tx_dsel asserts.
tx_clk
tx_data AF FF
tx_dsel
tx_data_stable_fire
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data -tx_min_check off

-tx_data_stable off -rx_data_select rx_dsel
-rx_data_stable_fire rx_data_stable_fire */
Checks that the value of rx_data does not change while rx_dsel asserts.
rx_clk
tx_clk
tx_data AF 00 FF
rx_dsel
tx_data_stable_fire

July 2013
Reference
cdc_fifo
cdc_fifo
default name:
active wr_ptr_fire enq_var_deq_var
tx_clock rd_ptr_fire
firings
tx_reset enqueue_fire checks:
enq dequeue_fire wr_ptr (On)
signals
rx_clock rd_ptr (On)
rx_reset full_count corner
deq empty_count cases enqueue (On)
cdcf dequeue (On)
enqueues_and_dequeues evals
wr_ptr
variables enqueues tx_clock, tx_reset, areset:
rd_ptr
dequeues statistics
maximum_fifo_entries
inferable from enq_signal
constants depth
current_fifo_entries rx_clock, rx_reset:
areset inferable from deq_signal
vacuity property:
enq_signal === 0
Description
Ensures that the write and read pointers of an asynchronous FIFO change by hamming distance
one, and ensures that the FIFO does not overflow or underflow.
Syntax
[<] {cdc_fifo | cdcf}
-enq enq_signal -deq deq_signal -depth depth_constant
[-tx_clock tx_clock] [-tx_reset tx_reset] [-rx_clock rx_clock] [-rx_reset rx_reset]
{-wr_ptr write_pointer_variable | -wr_ptr_check off}
{-rd_ptr read_pointer_variable | -rd_ptr_check off}
[-enqueue off] [-dequeue off] [-assume [all | {wptr | rptr | ptr | enq | deq}…]]
Required Arguments
• -enq enq_signal
FIFO enqueue signal. This signal indicates that the current FIFO entries should increase by
one.
• -deq deq_signal
FIFO dequeue signal. This signal indicates that the current FIFO entries should decrease by
one.
• -depth depth_constant
FIFO depth, where depth_constant is an HDL constant. The depth must be greater than 1.

July 2013
Reference
cdc_fifo
Inferable Options
Transmit clock and synchronous reset. If unspecified, each is inferable from enq_signal.
Receive clock and synchronous reset. If unspecified, each is inferable from deq_signal.
• Wr_ptr check, default On
{-wr_ptr write_pointer_variable | -wr_ptr_check off}
When the value of write_pointer_variable changes, the hamming distance between the
previous and the new values must be 1. This check occurs at the active transmit clock edge.
The checker fires each time write_pointer_variable improperly changes. The -wr_ptr_check
off option disables this check.
Firing message: The value (write_pointer) has a distance more than one from the previous
value (previous_write_pointer).
• Rd_ptr check, default On
{-rd_ptr read_pointer_variable | -rd_ptr_check off}
When the value of read_pointer_variable changes, the hamming distance between the
previous and the new values must be 1. This check occurs at the active receive clock edge.
The checker fires each time read_pointer_variable improperly changes. The -rd_ptr_check
off option disables this check.
Firing message: The value (read_pointer) has a distance more than one from the previous
value (previous_read_pointer).
• Enqueue check, default On
[-enqueue off]
An enqueue should not occur while the FIFO is full. This check occurs at the active transmit
clock edge. The checker fires each time the FIFO improperly enqueues. The -enqueue off
option disables this check.
Firing message: An enqueue occurred while the FIFO was full.
• Dequeue check, default On
[-dequeue off]
A dequeue should not occur while the FIFO is empty. This check occurs at the active
receive clock edge. The checker fires each time the FIFO improperly dequeues. The
-dequeue off option disables this check.
Firing message: A dequeue occurred while the FIFO was empty.

July 2013
Reference
cdc_fifo
Other Options
• [-assume [all | {wptr | rptr | ptr | enq | deq}…]]
o default — enqueue, dequeue
o all — all enabled checks
o wptr — wr_ptr
o rptr — rd_ptr
o ptr — wr_ptr, rd_ptr
o enq — enqueue
o deq — dequeue
Corner Cases
• FIFO Is Full — number of times the FIFO was full.
• FIFO Is Empty — number of times the FIFO was empty.
Statistics
• Enqueues and Dequeues (Evals) — number of times the FIFO enqueued or dequeued a
value.
• Enqueues — number of times the FIFO enqueued a value.
• Dequeues — number of times the FIFO dequeued a value.
• Maximum FIFO Entries — maximum number of values held in the FIFO at one time.
• Current FIFO Entries* — number of values currently held in the FIFO.
* Cannot accumulate across multiple simulations.
Notes
The following block diagram shows a typical implementation of a cdc_fifo checker:
tx_clock FIFO rx_clock

write wr_ptr rd_ptr read
mem
TX Module RX Module
cdc_fifo
checker
tx_clock (inferable from -enq enq_signal) and the receive data are based on -rx_clock

July 2013
Reference
cdc_fifo
rx_clock (inferable from -deq deq_signal). The standard -clock option should not be
specified.
this option is not specified, then the asynchronous reset is inferred from -enq
enq_signal. In either case, the reset applies to the entire checker, including logic on both
clocks.
Examples
/* 0in cdc_fifo -enq enq -deq deq -depth 8
-wr_ptr_check off -rd_ptr_check off
-enq_fire enq_fire */
Checks that the FIFO does not overflow or underflow.

/* 0in cdc_fifo -enq enq -deq deq -depth 8
-wr_ptr write_ptr -wr_ptr_fire write_ptr_fire
-rd_ptr read_ptr -rd_ptr_fire read_ptr_fire */
Checks that the values of write_ptr and read_ptr do not change by more than a
hamming distance of 1.
rx_clk
tx_clk
write_ptr 3 5
enq
write_ptr_fire
rx_clk
tx_clk
read_ptr 5 3 4
deq
read_ptr_fire

July 2013
Reference
cdc_glitch
cdc_glitch
default name:
active var_signal
signals var cdc_glitch_fire firings
checks:
cglt glitch (On)
flags used
cycles_checked evals statistics
clock, reset, areset:
clock reset areset inferable from var_signal
vacuity property:
!reset && !areset && active
=== 0
Description
Ensures that the input signal to a specified register does not change more than once within a
clock period.
Syntax
[<] {cdc_glitch | cglt}
[-var var_signal] [-glitch off] [-used] [-clock signal] [-reset signal] [-areset signal]
Inferable Options
• [-var var_signal]
Register driven by the signal to be checked. If unspecified, it is inferred from the declaration
or assignment in the most recent HDL statement on the same line as the beginning of the
0-In comment.
• Glitch check, default On
[-glitch off]
The value driving the var_signal register should not change more than once in a clock cycle.
The active edges of the clock input define checking windows for this check (each active
clock edge marks the beginning of a new clock cycle window). The checker monitors the
wire driving var_signal combinationally and fires if var_signal changes value two or more
times in a window (indicating a signal glitch). The firing output asserts at the start of the
next cycle and is held asserted for the duration of the clock cycle.
Firing message: The input signal to the specified register changed more than once within
the clock period.
Other Options
• [-used]
The checker fires only if var_signal is used (that is, loaded into a destination register).

July 2013
Reference
cdc_glitch
Statistics
• Cycles Checked (Evals) — number of cycles checked (i.e., the number of cycles that the
signal driving var_signal changed value at least once).
Notes
1. This is an asynchronous checker that responds to combinational behavior. The clock
signal’s active edges are used to define time windows for the checker’s glitch detection
logic.
2. Whereas the glitch checker checks for glitches on the specified -var signal, the
cdc_glitch checker infers the driving logic to the specified -var register and checks for
glitches on the inferred driving signal (connected to the var_d port of the cdc_glitch
checker).
inferred
connection
var_d
cdc_glitch //0in cdc_glitch -var var
checker checks
for glitch on var_d var
Examples
// 0in cdc_glitch -var reg
Checks that the input (var_d) to the reg register does not glitch.
clk
var_d
glitch
glitch_fire

July 2013
Reference
cdc_hamming_distance_one
default name:
active hamming_one_fire tx_variable
firings
tx_clock stable_fire
signals corner checks:
tx_reset value_changed_at_tx_min cases
hamming_one (On)
cdc_hamming1
variables tx_var values_checked evals
data_stable (Off)
constants tx_min lontgest_stable_time statistics tx_clock,tx_reset, areset:
shortest_stable_time
areset inferable from tx_variable
vacuity property:
!tx_reset && !areset &&
active === 0
Description
Ensures that the data crossing from transmit clock to receive clock domain changes by only one
hamming distance and that it remains stable for a specified tx_min clock cycles.
Syntax
[<] {cdc_hamming_distance_one | cdc_hamming1}
[-tx_var tx_variable] [-tx_clock tx_clock] [-tx_reset tx_reset ]
[-tx_min tx_min_constant] [-hamming_one off] [-assume [all | {dist | stable}…]]
Inferable Options
• [-tx_var tx_variable]
Variable with the transmit data in the transmit clock domain. If unspecified, it is inferred
from the declaration or assignment in the most recent HDL statement on the same line as the
beginning of the 0-In comment.
• [-tx_clock tx_clock][-tx_reset tx_reset]
Transmit clock and synchronous reset. If unspecified, each is inferable from tx_variable.
• Hamming_one check, default On
[-hamming_one off]
The transmit data should only change by a hamming distance of 1. This check occurs at the
active transmit clock edge whenever the value of tx_variable changes. The checker fires
each time the hamming distance between the previous and the new tx_variable value is
greater than 1. The -hamming_one off option disables this check.
Firing message: The value (tx_variable_value) has a distance more than one from the
previous value (previous_tx_variable_value).

July 2013
Reference
• Data_stable check, default Off

[-tx_min tx_min_constant]
The transmit data should remain stable for at least tx_min_constant cycles of the transmit
clock. This check occurs at the active transmit clock edge whenever the value of tx_variable
changes. The checker fires each time the value of tx_variable changes before
tx_min_constant cycles have elapsed.
Firing message: The value changed after number_of_cycles, but the specified minimum
time to remain constant is tx_min_constant cycles.
Other Options
• [-assume [all | {dist | stable}…]]
o all (default) — all enabled checks
o dist — hamming_one
o stable — data_stable
Corner Cases
• Value Changed at ’tx_min’ — number of times tx_variable changed at tx_min_constant
cycles. Reported only if the data_stable check is enabled.
Statistics
• Values Checked (Evals) — number of values checked.
• Longest Stable Time — most number of cycles tx_variable remained stable.
• Shortest Stable Time — fewest number of cycles tx_variable remained stable.
Notes
tx_clock (inferable from -tx_var tx_variable) and the receive clock is unused. The
standard -clock option should not be specified.
this option is not specified, then the asynchronous reset is inferred from -tx_var
tx_variable. In either case, the reset applies to the entire checker, including logic on both
clocks.
3. This checker is synchronous with respect to the transmit clock, so it responds only to
behavior that is observable at the active edge of the transmit clock.

July 2013
Reference
Examples
/* 0in cdc_hamming_distance_one -tx_var tx_var
-hamming_one_fire hamming_one_fire */
Checks that the value of tx_var only changes by a hamming distance of 1.

rx_clk
tx_clk
tx_var 0011 0101
hamming_one_fire
/* 0in cdc_hamming_distance_one -tx_var tx_var

-tx_min 3 -stable_fire stable_fire */
Checks that each time the value of tx_var changes, the data remains stable for at least
3 cycles of the transmit domain clock.
rx_clk
tx_clk
tx_var 0101 0100 1100
stable_fire

July 2013
Reference
cdc_handshake_data
cdc_handshake_data
default name:
active
tx_invalid_handshake_fire tx_valid_sig_tx_done_si
rx_invalid_handshake_fire g
data_stable_fire checks:
tx_valid_assert_until_done_assert_fire
cdc_handshake (On)
tx_done_assert_until_valid_deassert_fire
data_stable (On)
tx_valid_deassert_until_done_deassert_fire
firings tx_valid_assert_until_tx_
rx_valid_assert_until_done_assert_fire
done_assert (On)
rx_done_assert_until_valid_deassert_fire
tx_valid_stable_fire
tx_done_assert_until_tx_
tx_clock
rx_done_stable_fire
valid_deassert (On)
tx_reset
turnaround_max_fire
tx_valid_deassert_until_t
tx_valid
signals turnaround_min_fire
x
tx_done
rx_clock
_done_deassert (On)
cdc_hsd rx_valid_assert_until_rx_
rx_reset
rx_valid
done_assert (On)
turnaround_at_max corner rx_done_assert_until_rx_
rx_done turnaround_at_min cases
valid_deassert (On)
tx_valid_stable (Off)
variables
tx_data handshake_cycles_started evals rx_done_stable (Off)
handshake_cycles_compeleted statistics turnaround_max (Off)
handshake_turnaround_time_max turnaround_min (Off)
tx_min handshake_turnaround_time_min
constants rx_min clock, reset, areset:
turnaround_max inferable from
turnaround_min tx_valid_signal
areset vacuity property:
!tx_reset && !rx_reset
&&
tx_valid_signal === 0
Description
Ensures that the handshaking protocol between transmitter and receiver is correctly followed,
and ensures that the transmit data remains stable in data transfer window.
Syntax
[<] {cdc_handshake_data | cdc_hsd}
[-tx_data tx_data_variable] [-tx_clock tx_clock] [-tx_reset tx_reset]
[-rx_clock rx_clock] [-rx_reset rx_reset] [-tx_valid tx_valid_signal]
[-tx_min tx_min_constant] [-rx_min rx_min_constant]
[-turnaround_max turnaround_max_constant][-turnaround_min turnaround_min_constant]
[-cdc_handshake off] [-data_stable off] [-tx_valid_assert_until_tx_done_assert off]
[-tx_done_assert_until_tx_valid_deassert off]
[-tx_valid_deassert_until_tx_done_deassert off]

July 2013
Reference
cdc_handshake_data
[-rx_valid_assert_until_rx_done_assert off] [-rx_done_assert_until_rx_valid_deassert off]

[-tx_done tx_done_signal] [-rx_valid rx_valid_signal] [-rx_done rx_done_signal]
[-assume [all | {txval | tx_done | rxval | rxdone | data | max | min}…]] [standard_option…]
Inferable Options
• [-tx_data tx_data_variable]
Variable with the transmit data in the transmit clock domain. This variable is used with the
cdc_handshake, data_stable and turnaround checks. If one of these checks is on and -tx_data
is unspecified, it is inferred from the declaration or assignment in the most recent HDL
statement on the same line as the beginning of the 0-In comment.
If transmit data bus is not available, you must turn off the cdc_handshake and data_stable
checks.
Transmit clock and synchronous reset. If unspecified, each is inferred from tx_valid_signal.
Receive clock and synchronous reset. If unspecified, each is inferred from rx_done_signal.
• [-tx_valid tx_valid_signal]
Signal that indicates the transmit data in the transmit clock domain is valid. This signal is
used with the cdc_handshake, data_stable, tx_* and turnaround checks. If one of these
checks is on and -tx_valid is unspecified, it is inferred from the declaration or assignment in
the most recent HDL statement on the same line as the beginning of the 0-In comment.
If transmit valid signal is not available, you must turn off the cdc_handshake, data_stable
and *_tx_valid_* checks.
• Cdc_handshake check, default On
[-cdc_handshake off]
The handshake protocol must remain in a known state. This check requires
tx_data_variable, tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal.
This check occurs at the active transmit clock edge. The checker fires each time the
handshake protocol is violated by the transmitter. A violation asserts either
tx_invalid_handshake_fire or rx_invalid_handshake_fire. The -cdc_handshake off option
turns off this check.
Firing message: Handshake protocol was not followed properly by transmitter.
Firing message: Handshake protocol was not followed properly by receiver.
• Data_stable check, default On
[-data_stable off]
The transmit data (tx_data_variable) must be held stable in the data transfer window, which
opens when tx_valid_signal asserts and closes when tx_done_signal asserts. This check

July 2013
Reference
cdc_handshake_data
requires tx_data_variable, tx_valid_signal and tx_done_signal. This check occurs at the

active transmit clock edge. The checker fires each time the value of tx_data_variable is
sampled changed in the data transfer window. The -data_stable off option turns off this
check.
Firing message: ’tx_data’ changed from previous_value to value in the data transfer
window.
• Tx_valid_assert_until_tx_done_assert check, default On
[-tx_valid_assert_until_tx_done_assert off]
The tx_valid_signal signal, once asserted, must remain asserted until tx_done is received.
This check requires tx_valid_signal and tx_done_signal. This check occurs at the active
transmit clock edge whenever a data transfer window is open. The checker fires each time
tx_valid_signal deasserts before tx_done_signal is sampled asserted. The
-tx_valid_assert_until_tx_done_assert off option turns off this check.
Firing message: ’tx_valid’ deasserted before ’tx_done’ was received.
• Tx_done_assert_until_tx_valid_deassert check, default On
[-tx_done_assert_until_tx_valid_deassert off]
The tx_done_signal must remain asserted until tx_valid_signal deasserts. This check
requires tx_valid_signal and tx_done_signal. This check occurs at the active transmit clock
edge whenever a data transfer window is open. The checker fires each time tx_done_signal
deasserts before tx_valid_signal deasserts. The -tx_done_assert_until_tx_valid_deassert off
option turns off this check.
Firing message: ’tx_done’ deasserted before ’tx_valid’ deasserted.
• Tx_valid_deassert_until_tx_done_deassert check, default On
[-tx_valid_deassert_until_tx_done_deassert off]
The tx_valid_signal must not assert again until the current tx_done_signal deasserts
completing the current data transfer cycle. This check requires tx_valid_signal and
tx_done_signal. This check occurs at the active transmit clock edge whenever a data transfer
window is open. The checker fires each time tx_valid_signal reasserts before
tx_done_signal deasserts to close the data transfer window. The
-tx_valid_deassert_until_tx_done_deassert off option turns off this check.
Firing message: New ’tx_valid’ asserted before current ’tx_done’ deasserted to complete
the current data transfer cycle.
• Rx_valid_assert_until_rx_done_assert check, default On
[-rx_valid_assert_until_rx_done_assert off]
The rx_valid_signal signal, once asserted, must remain asserted until rx_done is received.
This check requires rx_valid_signal and rx_done_signal. This check occurs at the active
receive clock edge whenever a data transfer window is open. The checker fires each time
rx_valid_signal deasserts before rx_done_signal is sampled asserted. The
-rx_valid_assert_until_rx_done_assert off option turns off this check.

July 2013
Reference
cdc_handshake_data
Firing message: ’rx_valid’ deasserted before ’rx_done’ was received.

• Rx_done_assert_until_rx_valid_deassert check, default On
[-rx_done_assert_until_rx_valid_deassert off]
The rx_done_signal must remain asserted until rx_valid_signal deasserts. This check
requires rx_valid_signal and rx_done_signal. This check occurs at the active transmit clock
edge whenever a data transfer window is open. The checker fires each time rx_done_signal
deasserts before rx_valid_signal deasserts. The -rx_done_assert_until_rx_valid_deassert off
option turns off this check.
Firing message: ’rx_done’ deasserted before ’rx_valid’ deasserted.
• Tx_valid_stable check, default Off
[-tx_min tx_min_constant]
The tx_valid_signal signal must be held stable for at least tx_min_constant transmit clocks.
This check requires tx_valid_signal and is turned on by the -tx_min tx_min_constant option.
This check occurs at the active transmit clock edge whenever tx_valid_signal deasserts. The
checker fires each time tx_valid_signal deasserts prematurely.
Firing message: ’tx_valid’ changed after number_of_cycles cycles, but the specified
minimum time to remain constant is tx_min cycles.
• Rx_done_stable check, default Off
[-rx_min rx_min_constant]
The rx_done_signal signal must be held stable for at least rx_min_constant receive clocks.
This check requires rx_done_signal and is turned on by the -rx_min rx_min_constant
option. This check occurs at the active receive clock edge whenever rx_done_signal
deasserts. The checker fires each time rx_valid signnal deasserts prematurely.
Firing message: ’rx_done’ changed after number_of_cycles cycles, but the specified
minimum time to remain constant is rx_min cycles.
• Turnaround_min check, default Off
[-turnaround_min turnaround_min_constant]
Each data handshake protocol cycle must not complete in fewer than
turnaround_min_constant transmit clock cycles. This check requires tx_data_variable,
tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal and is turned on by
the -turnaround_min turnaround_min_constant option. This check occurs at the active
transmit clock edge whenever the data transfer window closes. The checker fires each time
the data transfer window closes before turnaround_min_constant transmit clock cycles.
Firing message: Data transfer handshake cycle completed in number_of_cycles cycles, but
the specified minimum turnaround time is turnaround_min cycles.
• Turnaround_max check, default Off
[-turnaround_max turnaround_max_constant]

July 2013
Reference
cdc_handshake_data
Each data handshake protocol cycle must not complete in more than
turnaround_max_constant transmit clock cycles. This check requires tx_data_variable,
tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal and is turned on by
the -turnaround_max turnaround_max_constant option. This check occurs at the active
transmit clock edge. The checker fires each cycle the data transfer lasts more than
turnaround_min_constant transmit clock cycles.
Firing message: Data transfer handshake cycle completed in number_of_cycles cycles, but
the specified maximum turnaround time is turnaround_max cycles.
Other Options
• [-tx_done tx_done_signal]
Signal that indicates data transmission is complete. This signal is required for the
cdc_handshake, data_stable, tx and turnaround checks.
• [-rx_valid rx_valid_signal]
Signal that indicates the receive data in the receive clock domain is valid. This signal is used
with the cdc_handshake, data_stable, rx and turnaround checks.
• [-rx_done rx_done_signal]
Signal that indicates data reception is complete. This signal is required for the
cdc_handshake, data_stable, rx and turnaround checks.
Note
Important: If the rx_valid and rx_done signals are not available, you must turn off the
cdc_handshake, rx_valid_assert_until_rx_done_assert and
rx_done_assert_until_rx_valid_deassert checks.
• [-assume [all | {txval | tx_done | rxval | rxdone | data | max | min}…]]

o default — cdc_handshake
o all — all enabled checks
o txval — tx_valid_assert_until_tx_done_assert,
tx_valid_deassert_until_tx_done_deassert, tx_valid_stable, cdc_handshake
o txdone — tx_done_assert_until_tx_valid_deassert, cdc_handshake
o rxval — rx_valid_assert_until_rx_done_assert, cdc_handshake
o rxdone — rx_done_assert_until_rx_valid_deassert, rx_done_stable, cdc_handshake
o data — data_stable, cdc_handshake
o max — turnaround_max, cdc_handshake
o min — turnaround_min, cdc_handshake

July 2013
Reference
cdc_handshake_data
Corner Cases
• Turnaround Cycles Completed at ’turnaround_max’— number of times a data transfer
completed in exactly turnaround_max_constant transmit clock cycles.
• Turnaround Cycles Completed at ’turnaround_min’— number of times a data transfer
completed in exactly turnaround_max_constant transmit clock cycles.
Statistics
• Total Tx_valid (Evals) — number of times tx_valid_signal was asserted, starting a new data
transfer cycle.
• Total Turnaround Cycles — number of data transfer cycles completed.
• Maximum Turnaround Cycles — maximum number of transmit clock cycles taken for a
complete data transfer cycle.
• Minimum Turnaround Cycles — minimum number of transmit clock cycles taken for a
complete data transfer cycle.
Notes
The following block diagram shows a typical implementation of a cdc_handshake_data
checker:
tx_valid Rx SYNC rx_valid
cdc_handshake_data
TX Module checker RX Module
tx_done Tx SYNC rx_done
tx_data data rx_data
tx_clock (inferable from -tx_valid tx_valid_signal) and the receive data are based on
-rx_clock rx_clock (inferable from -rx_done rx_done_signal). The standard -clock
this option is not specified, then the asynchronous reset is inferred from -tx_valid
tx_valid_signal. In either case, the reset applies to the entire checker, including logic on
both clocks.

July 2013
Reference
cdc_handshake_data
Examples
/* 0in cdc_handshake_data -tx_data tx_data
-tx_valid tx_valid -tx_done tx_done
-rx_valid rx_valid -rx_done rx_done
-tx_invalid_handshake_fire tih_fire
-rx_invalid_handshake_fire rih_fire
-data_stable_fire ds_fire*/
Checks that the handshake protocol between transmitter and receiver is correctly
followed and the value of tx_data remains unchanged during the data transfer.

-cdc_handshake off -data_stable off
-tx_valid_assert_until_done_assert_fire tvauda_fire
-tx_done_assert_until_valid_deassert_fire tdauvd_fire
-tx_valid_deassert_until_done_deassert_fire tvdudd_fire
-rx_valid_assert_until_done_assert_fire rvauda_fire
-rx_done_assert_until_valid_deassert_fire rdauvd_fire */
Checks that the handshaking protocol between the transmit and receive valid/done
signal pairs is obeyed for each data transfer window.
rx_clk
tx_clk
tx_valid
tx_done
tvauda_fire
rx_clk
tx_clk
tx_valid
tx_done
tdauvd_fire
rx_clk
tx_clk
tx_valid
tx_done
tvdudd_fire

July 2013
Reference
cdc_handshake_data
rx_clk
tx_clk
rx_valid
rx_done
rvauda_fire
rx_clk
tx_clk
rx_valid
rx_done
rdauvd_fire
/* 0in cdc_handshake_data
-tx_valid tx_valid -tx_min 5 -rx_done rx_done -rx_min3
-cdc_handshake off -data_stable off
-tx_valid_assert_until_done_assert_fire off
-tx_done_assert_until_valid_deassert_fire off
-tx_valid_deassert_until_done_deassert_fire off
-rx_valid_assert_until_done_assert_fire off
-rx_done_assert_until_valid_deassert_fire off
-tx_valid_stable_fire tvs_fire
-rx_done_stable_fire rds_fire */
Checks that tx_valid is held constant for at least 4 transmit clock cycles and that
rx_done is held constant for at least 2 receive clock cycles.
rx_clk
tx_clk
tx_valid
rx_done
tvs_fire
rds_fire

-turnaround_min 10 -turnaround_max 16*/
Checks that the handshake protocol between transmitter and receiver is correctly
followed and the value of tx_data remains unchanged during the data transfer. Also
checks that the handshaking protocol between the transmit and receive valid/done
signal pairs is obeyed for each data transfer window. Also checks that every data
transfer cycle lasts at least 10, but no more than 16, transmit clock cycles.

July 2013
Reference
cdc_sample
cdc_sample
default name:
active setup_fire tx_var_rx_var
firings
hold_fire
tx_clock all_one checks:
tx_reset all_zero setup (On)
signals corner
rx_clock cases
rx_reset
all_zero_to_one hold (On)
all_one_to_zero
sample tx_clock, tx_reset, areset:
values_sampled evals
tx_var sample_zero_bitmap inferable from tx_variable
variables sample_one_bitmap statistics
rx_var rx_clock, rx_reset:
one_to_zero_transition_bitmap
zero_to_one_transition_bitmap inferable from rx_variable
areset
vacuity property:
rx_enable_signal === 0
Description
Ensures that transmit data between two clock domains remain stable in the following intervals:
• From one rx_clock cycle before, to one rx_clock cycle after being sampled (in the
rx_clock domain).
• From one tx_clock cycle before, to one tx_clock cycle after being sampled (in the
rx_clock domain).
That is: the receive domain should sample at least twice for each transmit signal so that the
correct value is sampled.
Syntax
[<] {cdc_sample | sample}
-tx_var tx_variable -rx_var rx_variable [-tx_clock tx_clock] [-tx_reset tx_reset]
[-rx_clock rx_clock] [-rx_reset rx_reset] [-setup off] [-hold off] [-assume]
Required Arguments
• -tx_var tx_variable
Source variable in the transmit clock domain.
• -rx_var rx_variable
Destination variable in the receive clock domain.
Inferable Options

July 2013
Reference
cdc_sample

Receive clock and synchronous reset. If unspecified, each is inferable from rx_variable.
• Setup check, default On
[-setup off]
For every cycle that rx_variable is sampled, the value of tx_variable must remain constant
from the previous active transmit clock edge to the active receive clock edge at which the
value of rx_variable is sampled. This check occurs at the active rx_clock edge whenever
rx_variable is sampled. The checker fires each time tx_variable has improperly changed.
The -setup off option turns off this check.
Firing message: The transmit data were unstable before being sampled in the receive clock
domain.
• [-hold off]
For every cycle that rx_variable is sampled, the value of tx_variable must remain constant
from the active receive clock edge at which the value of rx_variable is sampled to the next
active transmit or receive clock edge (whichever is earlier). This check occurs at the active
rx_clock edge whenever rx_variable has been sampled at the previous active rx_clock edge.
The checker fires each time tx_variable has improperly changed. The -hold off option turns
off this check.
Firing message: The transmit data was unstable after being sampled in the receive clock
domain.
Other Options
• [-assume]
Sets all enabled checks to formal assumptions.
Corner Cases
• All Zero — non-zero if every bit of rx_variable was sampled as 0.
• All One — non-zero if every bit of rx_variable was sampled as 1.
• All One to Zero — non-zero if every bit of rx_variable was sampled transitioning from
1 to 0 (that is, all bits of One to Zero Transition Bitmap are 1).
• All Zero to One — non-zero if every bit of rx_variable was sampled transitioning from
0 to 1 (that is, all bits of Zero to One Transition Bitmap are 1).
Statistics
• Values Sampled (Evals) — number of times rx_variable was checked.
• Sample Zero Bitmap — bit vector representing which bits of rx_variable were sampled
as 0.

July 2013
Reference
cdc_sample
• Sample One Bitmap — bit vector representing which bits of rx_variable were sampled
as 1.
• One to Zero Transition Bitmap — bit vector representing which bits of rx_variable were
sampled transitioning from 1 to 0.
• Zero to One Transition Bitmap — bit vector representing which bits of rx_variable were
sampled transitioning from 0 to 1.
If more than 32 bits are specified, the bitmaps are displayed as hexadecimal values.
Notes
The following block diagram shows a typical implementation of a cdc_sample checker:
tx_var rx_var_d rx_var

TX Reg RX Reg
tx_clk cdc_sample rx_clk

checker
tx_clock and the receive data are based on -rx_clock rx_clock. The standard -clock
clocks.
3. The cdc_sample checker has an rx_enable port with an inferred connection to the
sampling condition used to sample tx_variable in the receive clock domain. If the
rx_enable connection cannot be inferred, the checker is excluded (directive-166
warning).
Examples
/* 0in cdc_sample
-tx_var tx_var -tx_clock tx_clk
-rx_var rx_var -rx_clock rx_clk
-setup_fire setup_fire -hold_fire hold_fire */

July 2013
Reference
cdc_sample
Checks that tx_var remains stable for the tx_clk cycle preceding, and for the tx_clk
cycle after, each rx_clk edge at which rx_var is sampled.
rx_clk
tx_clk
tx_var AA A5 C5
rx_enable
(inferred)
setup_fire
hold_fire

July 2013
Reference
cdc_sync
cdc_sync
default name:
active tx_variable
stable_fire firings
tx_var[n]* corner checks:
signals tx_clock value_changed_at_tx_min cases
stable (On)
tx_reset sync
values_checked evals tx_clock, tx_reset, areset:
constants tx_min shortest_stable_time statistics inferable from tx_variable
longest_stable_time
areset
vacuity property:
active === 0
* one checker is instantiated for each tx_var bit
Description
Ensures that a clock domain crossing signal from a faster clock to a slower clock is held stable
long enough for the signal to be sampled reliably by the receiver.
Syntax
[<] {cdc_sync | sync}
[-tx_var tx_variable] [-tx_clock tx_clock] [-tx_reset tx_reset] [-stable off]
[-tx_min tx_min_constant] [-assume] [standard_option*…]
Inferable Options
• [-tx_var tx_variable]
Variable with the transmit data in the transmit clock domain. If unspecified, it is inferred
from the declaration or assignment in the most recent HDL statement on the same line as the
beginning of the 0-In comment.
• Stable check, default On
[-stable off]
The transmit data should remain stable for at least tx_min_constant cycles of the transmit
clock. This check occurs at the active transmit clock edge whenever the value of tx_variable
changes. The checker fires each time the value of tx_variable changes before
tx_min_constant cycles have elapsed. The -stable off option disables this check.
Firing message: ’tx_var’ changed after number_of_cycles cycles, but the specified
minimum time to remain constant is tx_min_constant cycles.

July 2013
Reference
cdc_sync
Other Options
• [-tx_min tx_min_constant]
Minimum number of transmit clock cycles that the value of tx_variable should remain
stable. Default: 2 cycles.
• [-assume]
Sets the stable check to a formal assumption, if it is on.
Corner Cases
• Value Changed at ’tx_min’ — number of times tx_variable changed at tx_min_constant
cycles. Reported only if the stable check is enabled.
Statistics
• Values Checked (Evals) — number of values checked.
• Longest Stable Time — most number of cycles tx_variable remained stable.
• Shortest Stable Time — fewest number of cycles tx_variable remained stable.
Notes
The following block diagram shows a typical implementation of a cdc_sync checker:
tx_var SYNC
(double ff)
TX Module rx_clk RX Module
tx_clk cdc_sync
checker
tx_clock (inferable from -tx_var tx_variable) and the receive clock is unused. The
standard -clock option should not be specified.
clocks.
3. This checker is synchronous with respect to the transmit clock, so it responds only to
behavior that is observable at the active edge of the transmit clock.

July 2013
Reference
cdc_sync
Examples
/* 0in cdc_sync -tx_var tx_var
-tx_min 3 -stable_fire data_stable_fire */
Checks that each time the value of tx_var changes, the data remains stable for at least
3 cycles of the transmit domain clock.
rx_clk
tx_clk
tx_var 5 3 4
stable_fire

July 2013
Reference
cdc_fx
cdc_fx
default name:
active
cdc_fx_fire
rx_reg
glitch_swallowed_fire firings
checks:
cfx glitch_caught_fire
cdc_fx (Off)
signals all_bits_inverted corner
tx_clock cases
glitch_swallowed (Off)
loading_while_clocks_aligned glitch_caught (Off)
rx_clock
evals
rx_reset clocks_aligned_cycles
rx_areset
tx_clock, tx_reset, areset:
metastable_cycles
loading_while_rx_clock_before_tx_clock
inferable from rx_reg
loading_while_tx_clock_before_rx_clock vacuity property:
rx_clock_before_tx_clock
tx_clock_before_rx_clock statistics
rx_load_enable
delayed_transitions
active === 0
clks_aligned[65:0] advanced_transitions
bits_inverted
inverted_bits_bitmap
rx_reg
tx_reg
rx_q
clocks
monitor rx_reg
value
tx_clock rx_clock
tx_reg rx_reg
Description
Injects metastability at the output of a receive register.
Syntax
[<] {cdc_fx | cfx}
-rx_reg rx_register_variable -tx_reg tx_register_variable
[-rx_clock rx_clock] [-tx_clock tx_clock] [-rx_reset rx_reset] [-rx_areset rx_areset]
[-rx_load_enable value] [-cdc_fx] [-glitch_caught] [-glitch_swallowed][standard_option…]
Required Arguments
• -rx_reg rx_register_variable
Receiving register in the receive clock domain.
• -tx_reg tx_register_variable
Transmitting register in the transmit clock domain. The tx_register_variable can be a
concatenation of source registers for the receiving register (for example, {tx_reg3, tx_reg2,
tx_reg1}).

July 2013
Reference
cdc_fx
Inferable Options
• -rx_clock rx_clock
Receive clock. If unspecified, then it is inferred from rx_register_variable.
Transmit clock. If unspecified, then it is inferred from tx_register_variable.
• -rx_reset rx_reset
Receive synchronous reset. If unspecified, then it is inferred from rx_register_variable.
• -rx_areset rx_areset
Receive asynchronous reset. If unspecified, then it is inferred from rx_register_variable.
• -rx_load_enable value
Asserted when rx_reg is loaded with valid data. If unspecified, then it is inferred from
rx_register_variable.
• cdc_fx Check, Default On for multi_bits, dmux, simple_dmux, multi_sync_mux_select,
handshake and no_sync
-cdc_fx
Ensures the data output of the transmitting register is stable in the receiving register’s
metastability window. Typically, the data output of the transmit register can change value in
the receive register’s metastability window. This change can cause metastability of the
receiving register’s output, but the circuit is hopefully tolerant of this effect. However, an ad
hoc synchronizer might presume the transmit logic prevents the transmitting register from
changing value in the receiving register’s metastability window. Therefore, the ad hoc
synchronizer logic assumes the receiving register cannot become metastable. In this case,
the cdc_fx check can be used to verify the transmit value is held stable whenever the
transmit/receive clocks are aligned. Here, the cdc_fx check is a transmit protocol check for
the ad hoc synchronizer.
This check fires when any of the bits in the receive register is metastable. Default: fx checks
are on for multi_bits, dmux, simple_dmux, multi_sync_mux_select, handshake and no_sync
schemes; fx checks are off for all other schemes.
Firing message: Data changed in metastability window.
• glitch_caught Check, Default Off
-glitch_caught
Ensures metastability injection does not cause a glitch at the rx_reg input to be reflected as a
pulse at the rx_reg output unless the glitch is also caught in simulation (see Figure 5-1 on
page 275). The check fires at the second active receive clock edge after the glitch. The
check reports a bitmap showing those rx_reg bits that had a glitch caught.
Firing message: Glitch detected at the receiver output. Glitched output bitmap:
glitch_caught_bitmap.

July 2013
Reference
cdc_fx
• glitch_swallowed Check, Default Off

-glitch_swallowed
Ensures metastability injection does not cause a glitch at the rx_reg input to be swallowed
(that is, missed) at the rx_reg output unless the glitch is also swallowed in simulation (see
Figure 5-1). The check fires at the second active receive clock edge after the glitch. The
check reports a bitmap showing those rx_reg bits that had a glitch swallowed.
Firing message: Glitch swallowed by receiver output. Swallowed glitch bitmap:
glitch_swallowed_bitmap.
Figure 5-1. Transmit Protocol Checks for Glitches
cdc_fx checker
rx_q
d q_sim
tx_reg rx_reg
tx_clock rx_clock
Glitch_caught Check
tx_clk
rx_clk
d glitch
injected not injected
rx_q
q_sim
glitch_caught_fire
Glitch_swallowed Check
tx_clk
rx_clk
d glitch
injected not injected
rx_q
q_sim
glitch_swallowed_fire

July 2013
Reference
cdc_fx
Corner Cases
• All Bits Inverted — nonzero if every output bit of the receive register has had metastability
inserted.
Statistics
• Clocks Aligned Cycles (Evals) — number of clocks aligned cycles in which
tx_register_variable is changing.
• Loading While Clocks Aligned — number of clocks aligned cycles in which
rx_register_variable is loading.
• Metastable Cycles — number of clocks aligned cycles in which tx_register_variable is
changing and rx_register_variable is loading.
• Rx_clock Before Tx_clock — number of receive clocks cycles in which rx_clock goes
active before tx_clock and tx_register_variable is changing.
• Tx_clock Before Rx_clock — number of clocks aligned cycles in which tx_clock goes
active before rx_clock and tx_register_variable is changing.
• Loading While Rx_clock Before Tx_clock — number of clocks aligned cycles in which
rx_clock goes active before tx_clock, tx_register_variable is changing and
• Loading While Tx_clock Before Rx_clock — number of clocks aligned cycles in which
tx_clock goes active before rx_clock, tx_register_variable is changing and
• Delayed Transitions — number of times metastability injection delayed a transition until the
next cycle.
• Advanced Transitions — number of times metastability injection advanced a transition to
the current cycle.
• Bits Inverted — number of bits of the receive register output that had metastability inserted
(that is, the number of 1s in the inverted bits bitmap).
• Inverted Bits Bitmap — bitmap of the bits that had metastability injected.
Notes
1. The following statistics and corner case are updated each cycle: Clocks Aligned Cycles,
Tx_clock Before Rx_clock, Rx_clock Before Tx_clock, and Loading While Clocks
Aligned. The other statistics and corner case are updated only if the rx_register_variable
is loaded.

July 2013
Reference
cdc_mfx
cdc_mfx
default name:
active rx_reg
tx_clocks[n-1:0] cdc_mfx_fire firings
clock
checks:
rx_reset clocks_aligned_cycles
evals
statistics cdc_mfx (Off)
rx_areset
cmfx inject_metastability rx_reset, rx_areset,
rx_load_enable specified_window rx_load_enable,
rx_async_data[w-1:0] window_start rx_async_data, rx_data:
rx_data[w-1:0]
rx_reg[w-1:0]
inferable from rx_reg
rx_q[w-1:0]
rx_reg vacuity property:
value
n = number of clocks !tx_reset && !areset &&
w = variable width
active === 0
Description
Injects metastability at the output of a receive register driven by transmit registers from multiple
transmit clock domains.
Syntax
[<] {cdc_mfx | cmfx}
-rx_reg rx_register_variable -tx_clocks tx_clocks -clock rx_clock
[-rx_reset rx_reset] [-rx_areset rx_areset] [-rx_load_enable value] [-cdc_mfx]
Required Arguments
• -rx_reg rx_register_variable
Receiving register in the receive clock domain.
• -tx_clocks tx_clocks
Clock bus where the bits are clocks from the transmit clock domains.
• -clock rx_clock
Receive clock.
Inferable Options
• -rx_reset rx_reset
Receive synchronous reset. If unspecified, it is inferred from rx_register_variable.
• -rx_areset rx_areset
Receive asynchronous reset. If unspecified, it is inferred from rx_register_variable.
• -rx_load_enable value
Asserted when rx_reg is loaded with valid data. If unspecified, it is inferred from
rx_register_variable.

July 2013
Reference
cdc_mfx

• cdc_mfx Check, Default On for multi_bits, dmux, simple_dmux, multi_sync_mux_select,
handshake and no_sync
-cdc_mfx
Ensures the data output of the transmitting register is stable in the receiving register’s
metastability window.
This check fires when any of the bits in the receive register changes in the metastability
window. Default: cdc_mfx checks are on for multi_bits, dmux, simple_dmux,
multi_sync_mux_select, handshake and no_sync schemes; cdc_mfx checks are off for all
other schemes.
Firing message: Data changed in metastability window.
Statistics
• Clocks Aligned Cycles (Evals) — number of Rx clock cycles in which at least one active
clock edge occurred within the metastability window.
Notes
1. The following cdc_mfx checker outputs provide information about simulation:
• -cdc_mfx_fire
Pulses high when a setup violation occurs.
• -inject_metastability
Bitmap of the variable’s bits that are being inverted for the current metastability
injection.
• -specified_window
Previous cycle’s specified metastability window start time.
• -window_start
Previous cycle’s metastability window start time.
• rx_q
Value forced onto rx_reg.

July 2013
Reference
GUI Windows
GUI Windows
Menus Toolbar Debugging Windows
Design Data
Windows
Analysis
Windows
CDC Checks Window

The CDC checks window (Figure 5-2) shows the static CDC analysis results and the merged
results of formal verification and simulation with promoted CDC assertions. Entries in the CDC
checks tab are instances of CDC checks (schemes) detected by CDC static analysis. Selecting a
check shows detailed information in the details pane. Hovering over a selected group or CDC
scheme entry shows bubble help with additional information about the selected object.
The Static field of a scheme is the scheme’s status reported by static CDC analysis. If a Prove
database is merged, a Prove field shows the formal analysis results for the associated protocol
check. If a database generated by simulation with the promoted protocol checkers is merged, a
Simulation field shows the simulation results. The Type field shows the merged results form all
these analyses. See “Status Flags” on page 54 for an explanation of the status flags used to show
the status of these field entries.

July 2013
Reference
GUI Windows
Figure 5-2. CDC Checks Window
Each entry also has the following information:
• Check — Type of CDC scheme (for example: Two DFF Bus Sync, Combo Logic,
DMUX).
• Mode — User or inferred mode.
• Tx Signal — Tx signal in the HDL.
• Rx Signal — Rx signal in the HDl.
• Tx Clock — Tx clock in the HDL.
• Rx Clock — Rx clock in the HDL.
• Tx Module — Module containing the tx signal driver.
• Rx Module — Module containing the rx signal receiver.
• Tx File — File containing the tx module and file line number of the tx signal.
• Rx File —File containing the rx module and file line number of the rx signal.
• ID — ID that identifies the scheme and the design objects associated with it. The name
of the promoted checker includes this ID so simulation and formal results can be merged
into the static CDC results (see “Path and Protocol ID” on page 50).
If a simulation database (created by simulating the CDC protocol checkers) is merged in, each
entry has the following additional information:
• Checker — Name of the CDC protocol checker.

• Evaluations — Evaluation count of the checker in simulation.

July 2013
Reference
GUI Windows
• Covered — Whether or not the checker’s corner cases were covered in simulation.
• Firings — Number of times the checker fired in simulation..
• First Firing — Testbench time of the first firing, if the checker fired.
Right-click on an entry to pop up a menu:
• Show
• Source — view the declaration of the TX signal driver or the RX signal receiver.
• Schematic — view the CDC path in a schematic window and highlight the TX or
RX signal.
• Simulation Firings — view a firings waveform for the protocol check promoted for
the selected CDC scheme (if the check fired).
• Coverage — view simulation coverage data for the protocol check promoted for the
selected CDC scheme in the details window.
• Details — view details of the selected schemes in the details window.
• Filter – set and manage filter lists that hide groups of CDC scheme entries based on
various criteria. Also used to create cdc report directives from filtered elements:
• From Instance — hide schemes on paths that originate from specified design
instances.
• To Instance — hide schemes on paths that end at specified design instances.
• By Column — view Filter CDC Checks dialog for filtering entries based on their
CDC checks tab field values.
• Selected — add the currently selected schemes to the filtered list.
• Clear All — clear the filtered list.
• Import — clear the current filtered list and load a previously-saved filtered list.
• Export — save the current filtered list.
• Reset Columns — redisplay hidden columns and display columns in the default order.
• Create Directive — view Set Cdc Report dialog for creating cdc report directives.
Dialog fields are pre-filled with information extracted from the selected scheme.
• Find — view Search CDC Checks View dialog for searching for specified text in
column entries.
Help – invoke HTML help for the selected CDC scheme type.

July 2013
Reference
GUI Windows

July 2013
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
—C—
Index
—A— CDC, 37
ad hoc synchronizer, 28
promotion, 76
assertion defined, 49
schemes, 37, 144
assertion-based verification, 49
schemes with potential errors, 43
-assume, 271
CDC checks window, 279
Assumption groups
cdc_dsel, 245
data, 262
cdc_fifo, 249
deq, 251
cdc_glitch, 253
dist, 256
cdc_hamming_distance_one, 255
enq, 251
-cdc_handshake, 259
max, 262
cdc_handshake_data, 258
min, 262
cdc_sample, 266
ptr, 251
cdc_sync, 270, 273, 277
rptr, 251
CDC-FX
rxdata, 247
cdc_fx checker, 141
rxdone, 262
metastability injected simulation, 26
rxval, 262
Checker
stable, 256
promotion, 50
txdata, 247
checker
txdone, 262
cdc_fx, 127
txdsel, 247
promotion, 39
txval, 262
protocol, 49
wptr, 251
simulate a design, 51
async_reset scheme, 149
Checker types
async_reset_no_sync scheme, 152, 172
cdc_dsel, 245
asynchronous
cdc_fifo, 249
clocks, 21
cdc_glitch, 253
inputs, 21
cdc_hamming_distance_one, 255
—B— cdc_handshake_data, 258
black_box scheme, 154 cdc_sample, 266
Block specifications, 107 cdc_sync, 270, 273, 277
Block-level constraints, 100 clock
bus_dff_sync_gated_clk scheme, 161 asynchronous, 21
bus_four_latch scheme, 163 domain crossing, 22
bus_shift_reg scheme, 165 domains, 21
bus_two_dff scheme, 167 group, 21
bus_two_dff_phase scheme, 170 jitter, 25
Clock domain crossing, 37
Clocks, 21

July 2013
combo_logic scheme, 174 Formal CDC effort level, 48

Complex crossing, 37, 44 four_latch scheme, 202
Control file models, 114
control signal synchronizers, 28 —G—
Corner cases -glitch, 253
all one, 267 Global CDC preferences, 107
all one to zero, 267 Global reconvergence, 32
all zero, 267 Gray-coding protocol, 49
all zero to one, 267 —H—
asserted for ’tx_min’ cycles, 247 -hamming_one, 255
FIFO is empty, 251 Hierarchical constraints control file, 103
FIFO is full, 251 hierarchical verification
turnaround cycles completed at use model, 100
’turnaround_max’, 263 -hold, 267
turnaround cycles completed at Homogeneous instances of a block, 112
’turnaround_min’, 263
value changed at ’tx_min’, 256, 271 —I—
custom_sync scheme, 157, 159, 176, 178, 180 Ignored clock groups, 88
Inconclusive, 48
—D— Inferred clock trees, 89
data InfoHub, 16, 17
synchronization, 41, 42
Data sheets, checkers, 243 —J—
-data_stable, 259 jitter, 25
-depth, 249
Depth of divergence, 34 —L—
Local reconvergence, 32
Depth of reconvergence, 34
-deq, 249 —M—
-dequeue, 250, 270 mean-time-between-failure, 22
Derived clock group name, 86 metastability
dff_sync_gated_clk scheme, 182 cdc_fx checker, 127
Divergence depth, 34 fence logic, 27
dmux scheme, 183, 200, 211, 231 in hardware, 22
in RTL simulation, 23
—E—
-enq, 249 injection, 127
-enqueue, 250, 271 metastable flip-flops, 22
Evals, 243 registers, 22
Evaluation statistic, 243 windows, 128
Explicit clock group name, 86 MTBF, 22
multi_bits scheme, 207
—F— multi_sync_mux_select scheme, 209
fanin_different_clks scheme, 186 Multibit reconvergence, 32
FIFO crossing, 45 Multicycle reconvergence, 33
FIFO memory crossing, 44
Formal CDC, 48 —N—
netlist analysis, 47

July 2013
no_sync scheme, 213, 216 dff_sync_gated_clk, 182

dmux, 183, 200, 211, 231
—O— fanin_different_clks, 186
out-of-band signals, 27 four_latch, 202
—P— multi_bits, 207
Path ID, 50 multi_sync_mux_select, 209
PLI no_sync, 213, 216
function calls, 137 potential problems, 43
Promoted checkers, 50 pulse_sync, 219
promotion, 39 reconvergence, 222, 234
pulse_sync scheme, 219 redundant, 225, 227
shift_reg, 229
—R— two_dff, 239
-rd_ptr, 250 two_dff_phase, 242
-rd_ptr_check, 250 -setup, 267
reconvergence Severity, 38
defined, 32 severity level
scheme, 222, 234 caution, 38
Reconvergence depth, 34 evaluation, 38, 39
Reconvergence severity, 35 violation, 38
redundant scheme, 225, 227 waived, 39
-registered, 271 shift_reg scheme, 229
Resolving inferred clock trees, 89 Signal stability protocol, 48
-rx_clock, 246, 250, 259, 267 signals
-rx_data_select, 246 out-of-band, 27
-rx_data_stable, 246 Simple crossing, 37, 44
-rx_done, 262 simulation
-rx_done_assert_until_rx_valid_deassert, 261 checkers in simulation, 51
-rx_min, 261 transfer protocol, 27
-rx_reset, 246, 250, 259, 267 Single-source reconvergence, 34, 234
-rx_valid, 262 specifying design intent, 49
-rx_valid_assert_until_rx_done_assert, 260 stability protocol, 48
-rx_var, 266 -stable, 270
Standard options
—S— definition, 243
schemes
Statistics
async_reset, 149
current FIFO entries, 251
async_reset_no_sync, 152, 172
cycles checked (evals), 254
black_box, 154
dequeues, 251
bus_dff_sync_gated_clk, 161
enqueues, 251
bus_four_latch, 163
enqueues and dequeues (evals), 251
bus_shift_reg, 165
longest assertion, 247
bus_two_dff, 167
longest stable time, 256, 271
bus_two_dff_phase, 170
maximum FIFO entries, 251
combo_logic, 174
maximum turnaround cycles, 263
custom_sync, 157, 159, 176, 178, 180

July 2013
minimum turnaround cycles, 263 -tx_var, 255, 266, 270

one to zero transition bitmap, 268
sample one bitmap, 268 —U—
sample zero bitmap, 267 Unused clocks, 88
shortest assertion, 247 -used, 253
shortest stable time, 256, 271 —V—
total turnaround cycles, 263 -var, 253
total tx_valid, 263
transfers checked, 247 —W—
values checked enqueues and dequeues Waiver file, 110
(Evals), 271 Windows
values checked enqueues and dequeues CDC checks, 279
(evals), 256 -wr_ptr, 250
values sampled (evals), 267 -wr_ptr_check, 250
zero to one transition bitmap, 268
Status flags, 54
structured synchronizers, 28
synchronization
data, 41, 42
scheme, 27, 50
synchronizer
ad hoc, 28
block diagram, 27
control signal, 28
structured, 28
—T—
Target design, 119
transfer protocol, 27
-turnaround_max, 261
-turnaround_min, 261
two_dff scheme, 239
two_dff_phase scheme, 242
-tx_clock, 246, 250, 255, 259, 266, 270
-tx_data, 245, 259, 270
-tx_data_select, 246
-tx_data_stable, 246
-tx_done, 262
-tx_done_assert_until_tx_valid_deassert, 260
-tx_min, 246, 256, 261
-tx_min_check, 246
-tx_reset, 246, 250, 255, 259, 266, 270
-tx_valid, 259
-tx_valid_assert_until_tx_done_assert, 260
-tx_valid_deassert_until_tx_done_deassert,
260

July 2013
Third-Party Information
This section provides information on open source and third-party software that may be included in the Questa CDC product.
• This software application may include google hash table version 1.9 third-party software, which is distributed on an "AS
IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. google hash table version 1.9 may be
subject to the following copyrights:
© 2005, 2006, 2007, 2010, Google Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
© 1996-1999 Silicon Graphics Computer Systems, Inc.
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted
without fee, provided that the above copyright notice appears in all copies and that both that copyright notice and this
permission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability of
this software for any purpose. It is provided "as is" without express or implied warranty.
© 1994 Hewlett-Packard Company
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted
without fee, provided that the above copyright notice appears in all copies and that both that copyright notice and this
permission notice appear in supporting documentation. Hewlett-Packard Company makes no representations about the
suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
• This software application may include Aiger third-party software, which is distributed on an "AS IS" basis, WITHOUT
WARRANTY OF ANY KIND, either express or implied. Aiger may be subject to the following copyrights:
© 2006-2007, Armin Biere, Johannes Kepler University.
© 2006, Marc Herbstritt, University of Freiburg.
© 2006, Daniel Le Berre, Universite d’Artois.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
• This software application may include minisat version 2.0 third-party software, which is distributed on an "AS IS" basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. minisat version 2.0 may be subject to the
following copyrights:
© 2003-2006, Niklas Een, Niklas Sorensson
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
• This software application may include Open Source SDC Parser version SDC1.8 third-party software. Open Source SDC
Parser version SDC1.8 is distributed under the terms of the Synopsys Open Source License version 1.0 and is distributed
on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the license for the
specific language governing rights and limitations under the license. You can view a copy of the license at:
<your_Mentor_Graphics_documentation_directory>/legal/synopsys_open_source_1.0.pdf.
• This software application may include mpich2 version 1.4 third-party software. Portions of mpich2 version 1.4 may be
subject to the Perl Artistic and is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either
express or implied. See the license for the specific language governing rights and limitations under the license. You can
view a copy of the license at: <your_Mentor_Graphics_documentation_directory>/legal/perl_artistic_2.0.pdf. mpich2
version 1.4 may be subject to the following copyrights:
© 2010 Mathematics and Computer Science, Argonne National Laboratory
© 2010 Argonne Leadership Computing Facility, Argonne National Laboratory
© 2010 Futures Laboratory, Oak Ridge National Laboratory
Permission is hereby granted to use, reproduce, prepare derivative works, and to redistribute to others.
LICENSE
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer listed in this license in the documentation and/or other materials provided with the distribution.
Neither the name of the copyright holders nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
The copyright holders provide no reassurances that the source code provided does not infringe any patent, copyright, or
any other intellectual property rights of third parties. The copyright holders disclaim any liability to any recipient for
claims brought against recipient by any third party for infringement of that parties intellectual property rights.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S
COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN
THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS
SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the
corresponding quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor
Graphics”). Except for license agreements related to the subject matter of this license agreement which are physically
signed by Customer and an authorized representative of Mentor Graphics, this Agreement and the applicable quotation
contain the parties’ entire understanding relating to the subject matter and supersede all prior or contemporaneous
agreements. If Customer does not agree to these terms and conditions, promptly return or, in the case of Software
received electronically, certify destruction of Software and all accompanying items within five days after receipt of
Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and
Mentor Graphics accepts purchase orders pursuant to this Agreement (“Order(s)”), each Order will constitute a contract
between Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of
this Agreement, any applicable addenda and the applicable quotation, whether or not these documents are referenced on the
Order. Any additional or conflicting terms and conditions appearing on an Order or presented via any electronic portal or
other automated order management system will not be effective unless agreed in writing by an authorized representative of
Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such
invoice. Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half
percent per month or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight,
insurance, customs duties, taxes or other similar charges, which Mentor Graphics will state separately in the applicable
invoice(s). Unless timely provided with a valid certificate of exemption or other evidence that items are not taxable, Mentor
Graphics will invoice Customer for all applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax
and service tax. Customer will make all payments free and clear of, and without reduction for, any withholding or other
taxes; any such taxes imposed on payments by Customer hereunder will be Customer’s sole responsibility. If Customer
appoints a third party to place purchase orders and/or make payments on Customer’s behalf, Customer shall be liable for
payment under Orders placed by such third party in the event of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software
delivered electronically, which shall be deemed delivered when made available to Customer for download. Mentor
Graphics retains a security interest in all Products delivered under this Agreement, to secure payment of the purchase price
of such Products, and Customer agrees to sign any documents that Mentor Graphics determines to be necessary or
convenient for use in filing or perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means
is subject to Customer’s provision of both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement,
including any updates, modifications, revisions, copies, documentation and design data (“Software”) are copyrighted, trade
secret and confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain
all rights not expressly granted by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicable
license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form (except
as provided in Subsection 5.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius.
Customer may have Software temporarily used by an employee for telecommuting purposes from locations other than a
Customer office, such as the employee’s residence, an airport or hotel, provided that such employee’s primary place of
employment is the site where the Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary
depending on Software, license fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of
Software, which may be limited, for example, to execution of a single session by a single user on the authorized hardware or for
a restricted period of time (such limitations may be technically implemented through the use of authorization codes or similar
devices); and (c) support services provided, including eligibility to receive telephone support, updates, modifications, and
revisions. For the avoidance of doubt, if Customer provides any feedback or requests any change or enhancement to Products,
whether in the course of receiving support or consulting services, evaluating Products, performing beta testing or otherwise, any
inventions, product improvements, modifications or developments made by Mentor Graphics (at Mentor Graphics’ sole
discretion) will be the exclusive property of Mentor Graphics.
3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics’ Embedded
Software Channel (“ESC”), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce and
distribute executable files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++
compiler Software that are linked into a composite program as an integral part of Customer’s compiled computer program,
provided that Customer distributes these files only in conjunction with Customer’s compiled computer program. Mentor
Graphics does NOT grant Customer any right to duplicate, incorporate or embed copies of Mentor Graphics’ real-time operating
systems or other embedded software products into Customer’s products or applications without first signing or otherwise
agreeing to a separate agreement with Mentor Graphics for such purpose.
4. BETA CODE.
4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or
beta, collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor
Graphics’ authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for
experimental use to test and evaluate the Beta Code without charge for a limited period of time specified by Mentor
Graphics. This grant and Customer’s use of the Beta Code shall not be construed as marketing or offering to sell a license
to the Beta Code, which Mentor Graphics may choose not to release commercially in any form.
4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under
normal conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s
use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation
and testing, Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,
weaknesses and recommended improvements.
4.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform
beta testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or
developments that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based
partly or wholly on Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have
exclusive rights, title and interest in all such property. The provisions of this Subsection 4.3 shall survive termination of
this Agreement.
5. RESTRICTIONS ON USE.
5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all
notices and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All
copies shall remain the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number and
primary location of all copies of Software, including copies merged with other software, and shall make those records
available to Mentor Graphics upon request. Customer shall not make Products available in any form to any person other
than Customer’s employees and on-site contractors, excluding Mentor Graphics competitors, whose job performance
requires access and who are under obligations of confidentiality. Customer shall take appropriate action to protect the
confidentiality of Products and ensure that any person permitted access does not disclose or use Products except as
permitted by this Agreement. Customer shall give Mentor Graphics written notice of any unauthorized disclosure or use of
the Products as soon as Customer becomes aware of such unauthorized disclosure or use. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
reverse-compile, reverse-engineer or in any way derive any source code from Software. Log files, data files, rule files and
script files generated by or for the Software (collectively “Files”), including without limitation files containing Standard
Verification Rule Format (“SVRF”) and Tcl Verification Format (“TVF”) which are Mentor Graphics’ proprietary
syntaxes for expressing process rules, constitute or include confidential information of Mentor Graphics. Customer may
share Files with third parties, excluding Mentor Graphics competitors, provided that the confidentiality of such Files is
protected by written agreement at least as well as Customer protects other information of a similar nature or importance,
but in any case with at least reasonable care. Customer may use Files containing SVRF or TVF only with Mentor Graphics
products. Under no circumstances shall Customer use Software or Files or allow their use for the purpose of developing,
enhancing or marketing any product that is in any way competitive with Software, or disclose to any third party the results
of, or information pertaining to, any benchmark.
5.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct
software errors and enhance or modify the Software for the authorized use. Customer shall not disclose or permit disclosure
of source code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or
on-site contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile
source code in any manner except to support this authorized use.
5.3. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written
consent and payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer
without Mentor Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’
option, result in the immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms
of this Agreement, including without limitation the licensing and assignment provisions, shall be binding upon Customer’s
permitted successors in interest and assigns.
5.4. The provisions of this Section 5 shall survive the termination of this Agreement.
6. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with
updates and technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with
Mentor Graphics’ then current End-User Support Terms located at http://supportnet.mentor.com/about/legal/.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly
installed, will substantially conform to the functional specifications set forth in the applicable user manual. Mentor
Graphics does not warrant that Products will meet Customer’s requirements or that operation of Products will be
uninterrupted or error free. The warranty period is 90 days starting on the 15th day after delivery or upon installation,
whichever first occurs. Customer must notify Mentor Graphics in writing of any nonconformity within the warranty period.
For the avoidance of doubt, this warranty applies only to the initial shipment of Software under an Order and does not
renew or reset, for example, with the delivery of (a) Software updates or (b) authorization codes or alternate Software under
a transaction involving Software re-mix. This warranty shall not be valid if Products have been subject to misuse,
unauthorized modification, improper installation or Customer is not in compliance with this Agreement. MENTOR
GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE REMEDY SHALL BE, AT MENTOR
GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF THE PRODUCTS TO
MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE PRODUCTS THAT DO NOT MEET
THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO:
(A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF WHICH ARE
PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR
ITS LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS
SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BE

VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITS
LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING
LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVEN
IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN
NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS AGREEMENT EXCEED
THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR SERVICE GIVING
RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORS
SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8 SHALL
SURVIVE THE TERMINATION OF THIS AGREEMENT.
9. HAZARDOUS APPLICATIONS. CUSTOMER ACKNOWLEDGES IT IS SOLELY RESPONSIBLE FOR TESTING ITS

PRODUCTS USED IN APPLICATIONS WHERE THE FAILURE OR INACCURACY OF ITS PRODUCTS MIGHT
RESULT IN DEATH OR PERSONAL INJURY (“HAZARDOUS APPLICATIONS”). EXCEPT TO THE EXTENT THIS
EXCLUSION OR RESTRICTION OF LIABILITY WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN
NO EVENT SHALL MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES RESULTING FROM
OR IN CONNECTION WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS
APPLICATIONS. THE PROVISIONS OF THIS SECTION 9 SHALL SURVIVE THE TERMINATION OF THIS
AGREEMENT.
10. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND
ITS LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDING
ATTORNEYS’ FEES, ARISING OUT OF OR IN CONNECTION WITH THE USE OF MENTOR GRAPHICS PRODUCTS
IN OR FOR HAZARDOUS APPLICATIONS. THE PROVISIONS OF THIS SECTION 10 SHALL SURVIVE THE
TERMINATION OF THIS AGREEMENT.
11. INFRINGEMENT.
11.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product
acquired by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction.
Mentor Graphics will pay costs and damages finally awarded against Customer that are attributable to such action.
Customer understands and agrees that as conditions to Mentor Graphics’ obligations under this section Customer must:
(a) notify Mentor Graphics promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and
assistance to settle or defend the action; and (c) grant Mentor Graphics sole authority and control of the defense or
settlement of the action.
11.2. If a claim is made under Subsection 11.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product
so that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return
of the Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
11.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with
any product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the
use of other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a
product that Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided
by Mentor Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or
(h) infringement by Customer that is deemed willful. In the case of (h), Customer shall reimburse Mentor Graphics for its
reasonable attorney fees and other costs related to the action.
11.4. THIS SECTION 11 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT
INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS
AGREEMENT.
12. TERMINATION AND EFFECT OF TERMINATION.

12.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the
authorized term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
immediately upon written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the
licensing or confidentiality provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes
proceedings for liquidation or winding up or enters into an agreement to assign its assets for the benefit of creditors. For
any other material breach of any provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any
license granted under this Agreement upon 30 days written notice if Customer fails to cure the breach within the 30 day
notice period. Termination of this Agreement or any license granted hereunder will not affect Customer’s obligation to pay
for Products shipped or licenses granted prior to the termination, which amounts shall be payable immediately upon the
date of termination.
12.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination, Customer shall ensure that all use of the affected Products ceases, and shall return hardware
and either return to Mentor Graphics or destroy Software in Customer’s possession, including all copies and
documentation, and certify in writing to Mentor Graphics within ten business days of the termination date that Customer no
longer possesses any of the affected Products or copies of Software in any form.
13. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States (“U.S.”) government
agencies, which prohibit export, re-export or diversion of certain products, information about the products, and direct or indirect
products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products in any
manner without first obtaining all necessary approval from appropriate local and U.S. government agencies. If Customer wishes
to disclose any information to Mentor Graphics that is subject to any U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export
Administration Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure,
that such information is subject to such export restrictions.
14. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all
Software is commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant
to U.S. FAR 48 CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S.
government or a U.S. government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which
shall supersede any conflicting terms or conditions in any government order document, except for provisions which are contrary
to applicable mandatory federal laws.
15. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation
and other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
16. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and
during Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to
review Customer’s software monitoring system and records deemed relevant by the internationally recognized accounting firm
to confirm Customer’s compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include
FlexNet (or successor product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer
shall make records available in electronic format and shall fully cooperate with data gathering to support the license review.
Mentor Graphics shall bear the expense of any such review unless a material non-compliance is revealed. Mentor Graphics shall
treat as confidential information all information gained as a result of any request or review and shall only use or disclose such
information as required by law or to enforce its rights under this Agreement. The provisions of this Section 16 shall survive the
termination of this Agreement.
17. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics
intellectual property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the
world, disputes shall be resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed
under the laws of the State of Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if
Customer is located outside of North or South America. All disputes arising out of or in relation to this Agreement shall be
submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when
the laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia arising out of or in relation to this Agreement shall
be resolved by arbitration in Singapore before a single arbitrator to be appointed by the chairman of the Singapore International
Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with the Arbitration Rules of the SIAC in
effect at the time of the dispute, which rules are deemed to be incorporated by reference in this section. Nothing in this section
shall restrict Mentor Graphics’ right to bring an action (including for example a motion for injunctive relief) against Customer in
the jurisdiction where Customer’s place of business is located. The United Nations Convention on Contracts for the
International Sale of Goods does not apply to this Agreement.
18. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,
unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full
force and effect.
19. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all
prior or contemporaneous agreements. Some Software may contain code distributed under a third party license agreement that
may provide additional rights to Customer. Please see the applicable Software documentation for details. This Agreement may
only be modified in writing, signed by an authorized representative of each party. Waiver of terms or excuse of breach must be
in writing and shall not constitute subsequent consent, waiver or excuse.
Rev. 130502, Part No. 255853

Questa

Uploaded by

Copyright:

Available Formats

Questa

Uploaded by

Document Information

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

Questa

Uploaded by

Copyright:

Available Formats

Questa® CDC

Software Version 10.2b_1

Questa® Formal-based Technology

© 1995-2013 Mentor Graphics Corporation

Mentor Graphics Corporation

Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form

Questa CDC User Guide, v10.2b_1 3

CDC Protocol Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4 Questa CDC User Guide, v10.2b_1

Questa CDC User Guide, v10.2b_1 5

6 Questa CDC User Guide, v10.2b_1

Example 3-1. Hierarchical Constraints File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7 Questa CDC User Guide, v10.2b_1

Figure 2-1. Clock Domains and Clock Dividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Questa CDC User Guide, v10.2b_1 8

Table 1-1. Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

9 Questa CDC User Guide, v10.2b_1

10 Questa CDC User Guide, v10.2b_1

Questa CDC User Guide, v10.2b_1 11

Questa Static Manuals

12 Questa CDC User Guide, v10.2b_1

Table 1-1. Notational Conventions

Questa CDC User Guide, v10.2b_1 13

Table 1-2. Syntax Conventions

signal Single-bit register or wire.

14 Questa CDC User Guide, v10.2b_1

• Shell command help

• Tcl command help

prompt> qcdc -c -do “help settings”

prompt> qcdc -c -do “help configure output directory”

Questa CDC User Guide, v10.2b_1 15

16 Questa CDC User Guide, v10.2b_1

Questa CDC User Guide, v10.2b_1 17

Mentor Graphics Support

18 Questa CDC User Guide, v10.2b_1

Questa CDC User Guide, v10.2b_1 19

CDC Design Issues

• Static CDC analysis with the CDC compiler.

20 Questa CDC User Guide, v10.2b_1

Figure 2-1. Clock Domains and Clock Dividers

clock divider clk

Single Clock Domain Multiple Clock Domains

Figure 2-2. Asynchronous Clock Domains

Questa CDC User Guide, v10.2b_1 21

Figure 2-3. Metastable Flip-Flop

The following mean-time-between-failure (MTBF) formula predicts how often metastability

22 Questa CDC User Guide, v10.2b_1

1 f clk = clock frequency

Metastability in Standard RTL Simulation

• The hardware output value matches the value predicted by simulation.

Questa CDC User Guide, v10.2b_1 23

Figure 2-4. Four Metastability Scenarios

Pseudorandom Delay Insertion

Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output

However, this method has the following limitations:

24 Questa CDC User Guide, v10.2b_1

• Synchronization violations are difficult to debug, because the offending metastability

Questa CDC User Guide, v10.2b_1 25

CDC-FX Injected RTL Simulation

Figure 2-6. Metastability Injector for a CDC Data Bus