CDC User

Questa CDC
User Guide
Software Version 10.0c_2
October 2011
1995-2011 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 CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
RESTRICTED RIGHTS LEGEND 03/97
U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely
at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.72023(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.
Contractor/manufacturer is:
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/user/feedback_form.cfm
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other third parties. No one is permitted to use these Marks without the
prior written consent of Mentor Graphics or the respective third-party owner. The use herein of a thirdparty 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/terms_conditions/trademarks.cfm.
Table of Contents
Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questa CDC/Formal Verification Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
16
17
18
22
Chapter 2
CDC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metastability in Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metastability in Standard RTL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC-FX Injected RTL Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Signal Synchronizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Bus Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ad Hoc Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reconvergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifying Reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes of CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Severity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signal/Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schemes with Potential CDC Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formal CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Protocol Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
24
25
25
26
26
27
29
30
31
32
34
35
38
39
39
39
40
41
41
42
43
44
45
46
47
49
50
53
Chapter 3
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-Step Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-Step Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
56
57
Questa CDC User Guide, v10.0c_2

October 2011
Table of Contents
Step 1: Compile and Maintain Design Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Preparing a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Step 2: Run CDC Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc: Clock Domain Crossing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parallel Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SDC Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Importing an SDC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exporting SDC Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Style Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binding to Verilog Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
59
60
64
64
66
67
67
68
70
73
76
85
Chapter 4
CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in_cdc: GUI Debug Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in_cdc: GUI Project Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 1. Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 2: Analyzing Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 3: Compiling CDC Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 4: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Protocol Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questa Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation with CDC Protocol Assertions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC-FX Metastability Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running Simulation with CDC-FX Metastability Injection. . . . . . . . . . . . . . . . . . . . . . .
Simulation Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling with ccl for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hierarchical CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hierarchical CDC Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variations on the Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heterogeneous Instances of Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control File Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modal CDC Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specify Modes (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Report Mode Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Verification and Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Individual Mode Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Incomplete CDC Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
88
88
91
92
93
93
96
96
104
104
105
107
111
111
113
114
117
118
123
126
128
128
130
132
133
134
134
135
137
137
144
146

October 2011
Table of Contents
CDC Analysis of FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Phase 1: Compiling the FPGA Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Xilinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical-physical Library Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 2: Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 3: Compiling a CDC Model of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 4: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
149
149
151
152
152
153
157
Chapter 5
CDC-FX Metastability Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Metastability Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metastability Windows Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running CDC-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fx_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC-FX PLI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verilog Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VHDL Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metastability Injector Simulation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assertion Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
159
160
161
165
165
169
170
171
171
173
174
174
Chapter 6
Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
async_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
async_reset_no_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
black_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_four_latch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_shift_reg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bus_two_dff_phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
combo_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
custom_sync_with_crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fanin_different_clks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fifo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
four_latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
memory_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
multi_bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
multi_sync_mux_select. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
no_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
port_constraint_mismatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
177
179
181
184
186
189
191
193
195
197
199
201
203
205
207
208
210
213
218
220
223
225
227
229
231

October 2011
Table of Contents
pulse_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
redundant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
series_redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
shift_reg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
simple_dmux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
single_source_reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
two_dff_phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0-In Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0-In Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hierarchical Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wildcards in Directive Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directive Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directives for CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
error_on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_black_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fifo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fifo_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fx_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fx_metastability_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_fx_timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_handshake_preference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_hier_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_port_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_port_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_report_comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_cdc_synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_constant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_constant_propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_mode_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directives for Checker Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
checker_firing_keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
create_wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
default_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
disable_checker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
disable_used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
exclude_checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
include_checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
233
235
238
240
242
244
246
251
253
254
254
255
257
257
259
260
262
264
265
268
269
270
271
272
273
274
276
279
286
292
294
296
300
301
304
307
308
310
312
313
314
315
316
317
318
320
321
322
323

October 2011
Table of Contents
set_checker_action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
use_synthesis_case_directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
verror. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vdel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in_cdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in_db2ucdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0in Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lib2v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cwhelp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol/FX Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_dsel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_glitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_hamming_distance_one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_handshake_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_fx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cdc_custom_fx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
324
325
326
327
328
329
332
336
344
346
349
351
353
357
363
364
379
381
383
383
385
389
393
395
398
406
409
412
416
Chapter 7
GUI Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GUI Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GUI Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Window Layouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analysis Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Errors/Warnings Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Checks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debug Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Log/Report Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schematics Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Expanding Logic in the Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zooming the Schematic View In or Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving Waveforms and Waveform Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
419
419
419
423
426
426
427
430
430
431
432
434
434
436
437
438
438

October 2011
Table of Contents
Loading Waveforms and Waveform Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Zooming the Wave View In or Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capturing Zoomed/Scrolled Views as Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting Multiple Signals for Format Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Display Properties of Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Signal Pathname Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removing Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organizing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Multiple Window Panes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Cursors to Analyze Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capturing a Waveforms Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a Source Code Variable to a Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annotating Source Code with Variables Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Mode Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modules Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clocks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directives Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
438
439
440
441
441
441
442
443
443
444
445
446
446
446
448
448
449
450
451
452
Chapter 8
Reports/Logs Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Design Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Group Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User-Specified Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inferred Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ignored Clock Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Design Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Detailed Design Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Domain Crossing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CDC Promotion Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Waived . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Proven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filtered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Custom Synchronization Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asynchronous Reset Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asynchronous Reset Synchronizers Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User-entered Asynchronous Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asynchronous Reset with Missing Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
453
454
454
455
455
457
457
457
458
458
459
461
461
462
462
463
463
464
465
466
467
467
467
468
468
468

October 2011
Table of Contents
All Transmitting Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CDC Settings Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section A: Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section B: Unmatched Global Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section C: Wildcard Expansion for Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section D: Global CDC Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section E: Default CDC Scheme Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
470
471
471
471
472
472
474
Index
Third-Party Information
End-User License Agreement

October 2011
List of Examples
Example 2-1. Promoted CDC Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 3-1. 0in_sdc_ctrl.v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 3-2. SDC Export File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 4-1. Hierarchical Constraints Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 4-2. 0in_hier.scr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 4-3. 0in_hier.Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 5-1. 0in_cdc_fx_sim_ctrl.v File Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 5-2. Editing the 0in_cdc_fx_sim_ctrl.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 6-1. Single-source Reconvergence Code Snippet. . . . . . . . . . . . . . . . . . . . . . . . . .
Example 6-2. Single-source Reconvergence 0in_cdc.rpt File . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-1. Clock Group Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-2. User-Specified Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-3. Inferred Clock Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-4. Ignored Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-5. Mode Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-6. General Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-7. Detailed Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-8. Port Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-9. Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-10. User Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-11. CDC Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-12. CDC Promotion Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-13. Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-14. Cautions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-15. Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-16. Waived. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-17. Proven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-18. Filtered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-19. Custom Synchronization Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-20. Asynchronous Reset Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-21. Asynchronous Reset Synchronizers Detected. . . . . . . . . . . . . . . . . . . . . . . .
Example 8-22. User-entered Asynchronous Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-23. Asynchronous Reset with Missing Synchronizer . . . . . . . . . . . . . . . . . . . . .
Example 8-24. All Transmitting Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-25. Global Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-26. Unmatched Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-27. Wildcard Expansion for Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-28. Global CDC Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 8-29. Default CDC Scheme Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
48
68
69
119
124
125
166
167
284
284
454
455
455
457
457
457
458
458
459
461
462
462
463
463
464
465
466
467
467
468
468
468
468
470
471
472
472
472
474

October 2011
List of Figures
Figure 2-1. Clock Domains and Clock Dividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-2. Asynchronous Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-3. Metastable Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-4. Four Metastability Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output . . . . . . . . . . . . . . .
Figure 2-6. Metastability Injector for a CDC Data Bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-7. Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-8. Synchronization Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-9. CDC Checks Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-10. Show Simulation Firings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-11. Simulation Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2-12. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-1. CDC Compilation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-2. Design Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-3. Preparing the work Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-4. modelsim.ini Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3-5. Compiling Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-1. Questa CDC Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-2. Static Questa CDC Tool Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-3. CDC GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-4. Simulation with CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-5. Hierarchical CDC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-6. Basic Hierarchical CDC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-7. -report_constraints Generates Hierarchical CDC Scripts. . . . . . . . . . . . . . . . . .
Figure 4-8. Waiving a Block-level Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-9. Top-level CDC Analysis with CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-10. Modes are Inferred Based on the Clock Multiplexing . . . . . . . . . . . . . . . . . . .
Figure 4-11. 0in_cdc Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-12. 0in_cdc Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-13. Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-14. Filter Hierarchy Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-15. Mode for the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-16. Clock Coloring Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-17. Color Change as the Mode Context Changes . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-18. Modes Have No Clock Tree Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-19. Reload Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4-20. Some Modes Have Clock Tree Information . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-1. Setup and Hold Times for a Register Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-2. Metastability Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-3. clks_aligned Input to the cdc_fx Checker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
October 2011
25
25
26
27
28
29
30
30
50
51
52
53
55
57
57
59
59
87
88
89
107
117
119
123
127
130
133
138
139
140
141
142
143
143
147
147
148
160
161
162
11
List of Figures
Figure 5-4. Metastability Window Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5-5. CDC Data Flow for Simulation with Metastability . . . . . . . . . . . . . . . . . . . . . .
Figure 5-6. Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5-7. CDC GUI with Merged CDC_FX Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-1. Single-source Reconvergence Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-2. Global CDC Preferences (0in_cdc_setting.rpt). . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-3. CDC Analysis with cdc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-4. Compiling CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6-5. Transmit Protocol Checks for Glitches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-1. Dragging and Dropping a Port to the Schematic Window . . . . . . . . . . . . . . . . .
Figure 7-2. Configuring Columns in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-3. Organizing the Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-4. Zoomed View of a Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-5. Undocking a Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-6. Saving and Restoring a GUI Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-7. Errors/Warnings Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-8. Error/Warning Hover Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-9. CDC Checks Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-10. Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-11. Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-12. Log/Report Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-13. Log Browser Showing Error/Warning Information . . . . . . . . . . . . . . . . . . . . .
Figure 7-14. Schematics Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-15. Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-16. Waveform Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-17. Find Panel in Design Data Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-18. Project Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-19. Design Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-20. Modules Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-21. Clocks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 7-22. Directives Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
164
165
169
175
284
290
371
372
414
421
421
423
424
424
425
426
427
428
430
431
432
433
434
437
438
448
448
449
450
451
452

October 2011
List of Figures

October 2011
13
List of Tables
Table 1-1. Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 1-2. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-1. Signal Synchronization Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-2. Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-3. Signal and Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-4. Potential CDC Problem Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 2-5. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-1. 1-Step Compilation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-2. vcom Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-3. vlog Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-4. cdc Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-5. Imported SDC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-6. Exported SDC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-7. Inferred Clocks and Port Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-8. Unsupported Verilog Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-9. Verilog Design Style Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-10. Supported VHDL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3-11. VHDL Design Style Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-1. CDC GUI Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-2. 0in_cdc Project Mode Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-3. CDC Protocol Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-4. Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-5. ccl Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-6. ILMs vs. CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 4-7. Control File Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 5-1. CDC Schemes and cdc_fx Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-1. CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-2. Global Directives for CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-3. Global Directives for Checker Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-4. cdc Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-5. cdc Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 6-6. Standard Options of a Checker Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
17
18
41
42
43
44
53
56
59
60
65
67
68
68
73
73
76
81
89
91
104
113
114
131
131
167
179
260
315
373
374
384

October 2011
Chapter 1
Introduction
Welcome to the Questa CDC/Formal Verification suite, a collection of functional analysis
tools from Mentor Graphics. The Questa CDC/Formal Verification suite, along with your
standard HDL simulation environment (for example, the Questa Sim product), provides a
complete, integrated functional verification environment for assertion-based verification of
your complex HDL designs.
The Questa CDC/Formal Verification suite has the following verification tools:
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 tools and the Questa 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
tools already are compatible with your simulation environment, if you use the Questa simulator.
The Questa CDC/Formal Verification tools analyze synthesizable logic, so some variance with
simulation is common, but this is not unlike the restrictions for logic synthesis and design
emulation.
Each tool comes with a GUI debugger environment for organizing, waiving and debugging
verification results. These GUI environments are tightly integrated with their analysis tools. 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 analysis tools, the GUIs have useful analyzer windows such as
language-oriented source code editors, schematic browsers, waveform viewers and finite-statemachine 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.

October 2011
15
Introduction
Questa CDC/Formal Verification Manuals
Questa CDC/Formal Verification Manuals

The manual set for the Questa CDC/Formal Verification suite has the following documents:
16
Release Documents
Questa CDC/Formal Release Notes Bugs fixed in the current release and support
information.
Questa CDC/Formal 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.
Quick References
Questa CDC/Formal Quick Reference Syntaxes of commands and directives for

all Questa CDC/Formal tools.
Questa Assertions Quick Reference Quick reference for OVL and QVL checker
libraries; and SVA coding style examples.
Questa CDC/Formal Messages Quick reference for messages issued by the

Questa CDC/Formal tools.
User Guides
Questa AutoCheck User Guide Basics and tool flow for AutoCheck operation;
command and directives reference; autochecks reference; and GUI reference.
Questa Formal User Guide Basics and tool flow for formal analysis and
assertion debug; command and directives reference; 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; command and
directives reference; CDC schemes reference; and GUI reference.
Tutorials
Questa Formal Verilog Tutorial User Guide Formal analysis tutorial using a
Verilog design.
Questa Formal VHDL Tutorial User Guide Formal analysis tutorial using a
VHDL design.
October 2011
Introduction
Notational Conventions
Questa CDC Verilog Tutorial User Guide Static and dynamic CDC analysis
tutorial using a Verilog design.
Questa CDC VHDL Tutorial User Guide Static and dynamic CDC analysis
tutorial using a VHDL design.
Notational Conventions
This manual uses the notational conventions illustrated in Table 1-1.
Table 1-1. Notational Conventions
Notation
Description
Example
italics
In syntax statements: oblique font

indicates a variable.
[-depth cycles]
In text: oblique font indicates:

(1) variable
(2) code excerpt
(3) term being defined
Specify the black box

as module.
Both tx_sig1 and
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 text Specify the reconvergence
depth: -depth <cycles>.
to distinguish variables from literals
when necessary to reduce confusion.
cdc [-d <design>]
[+define+<define>]...
<angle brackets>
Angle brackets are used in

alphanumeric messages from the
software to indicate variables.
italics underline
Oblique underline font in text indicates See the Questa Sim User
the name of another document.
Guide for details of the
vlog command.

October 2011
17
Introduction
Online Help
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.
-ports portID. . .
[ ]
Square brackets indicate an optional

entry.
[-module module]
{ }
Braces indicate a required entry

{-set signal value}...
(typically used with |-bars or ellipses).
Or-bars separate choices in [ ] and { } [-87|-93|-2002|-2008]

entries.
_pattern
An argument variable with a _pattern

suffix accepts wildcards.
set_constant var_pattern constant
The following replaceable variables in directive syntax statements represent the shown object
types.
signal
Single-bit register or wire.
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.
Online Help
Questa CDC/Formal software includes several ways of getting online help:
Shell help
Type -help with any shell command for the syntax of that command. For example:
prompt> vlib -help
Usage: vlib -help
vlib [-short|-dos|-long|-unix] [-archive [-compact <compact>]]
[-unnamed_designs <count>] [{-lock|-unlock} <design>]
[-locklib|-unlocklib] <library_name>
18

October 2011
Introduction
Online Help
0in shell help

Type -help with any 0in shell command for the syntax of that command. For example:
prompt> 0in -cmd csl -help
. . .
usage: compile_search_logic
alias: csl
-d <design name>
[-prefix <prefix for search dut in test bench>]
[-ctrl_module <control module name>]...
Verilog Options:
[-v95 | -sv | -v2k]
[-ctrl <verilog checker control file>]...
[-ctrl_list <list of verilog checker control files>...]
[+define+<macro[=val]>]...
[+incdir+<incdir>]...
[+libext+<libext>]...
[-cuname <compilation unit name>...]
VHDL Options:
[-vhctrl <vhdl checker control file>]...
[-93 | -87 | -2002 | -2008]
Assertion Options:
[+assert]
[-psl]
[+propfile+<compile verilog flavor PSL vunit>]...
[-pslfile_vl <compile verilog flavor PSL vunit>]...
[-pslfile_vh or -pslfile <compile VHDL PSL vunit>]...
[-assertion_compiler_stats or -ac_stats]
[-ovl]
[-ovl_cov]
[-qvl]
[-sva_strong]
3rd Party Tool Options:
[-sim <select simulator (questa,mti,vcs,nc,nc3)>]
Advanced Usage Options:
[-G[ ]<<name=value> override top level generic>]...
[-g[ ]<<name=value> default top level generic>]...
[-use_synthesis_case_directives]
[-sif <simulator arg file for running checkers>]
[-tcs or -target_cover_statements]
[-dut_instance or -di <instance name>...]
[-dut_exclude or -de <instance name>...]
RTL Options:
[-work <logical work library name>]
[-L <search library for saved modules>]...
[-Lf <library, searched before uselib>]...
[-modelsimini <modelsim.ini to provide library mapping>]
Reporting Options:
[-rcd_file <checker density report file>]
[-cr <checker report file>]
[-cache <working directory>]
[-rel_paths]
[-full]
[-rcd]
[-rcd_level <report level>]
[-eode or -exit_on_directive_errors]
[+nowarn+<message-id>]...

October 2011
19
Introduction
Online Help
[+error+<message-id>]...
[-sir or -static_input_report]
[-scr or -static_coverage_report]
[-help]
Prepares design files for formal verification.
CW help
The cwhelp 0in shell command displays the syntaxes of the global directives. For
example:
prompt> 0in -cmd cwhelp set_black_box
usage: set_black_box
<name pattern>...
[-dont_use_outputs]
Set module as a black box.
Specify cwhelp with no arguments to list the available directives:

prompt> 0in -cmd cwhelp
0-In Checker Directive Compiler
globals
Global Directives
autocheck_off
Turn off autocheck
autocheck_on
Turn on autocheck
autocheck_preference Set autocheck preference
autocheck_report
Set autocheck message and/or waive autocheck
create_wire
Create a checkerware wire
default_reset
Specifies a default reset
disable_assumption
Do not use specified checks as formal assumptions
. .
.
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.
20

October 2011
Introduction
Online Help
InfoHub
The Questa CDC/Formal documentation is available in HTML and PDF forms from the
Questa CDC/Formal InfoHub. Use a web browser to open the InfoHub top page:
install_dir/share/doc/infohubs/index.html

October 2011
21
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
22

October 2011
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 metastableits 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 159 for additional
information.

October 2011
23
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:
24
Static CDC analysis with the CDC compiler.
Assertion-based verification with CDC protocol checkers.
Metastability effects analysis with CDC-FX metastability injected simulation.

October 2011
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
A
clk
clock divider
clk
clk/2
clk33
clk
clk
clk33
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
clk33
B
a
b
clk33
clk50
clk50
clk
Asynchronous Clocks
clk
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.

October 2011
25
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 signals transmit clock is too close to the active edge of the
receive registers 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 registers 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 26. 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
clk
s
q
The following mean-time-between-failure (MTBF) formula predicts how often metastability

occurs:
f clk = clock frequency
1
MTBF = ---------------------------------f in = asynchronous signal frequency
f clk f in t d
t d = setup/hold window
26

October 2011
CDC Basics
Metastability
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.
Figure 2-4. Four Metastability Scenarios
cdc_s
q
R
rx_clk
hardware
matches
simulation
rx_clk
rx_clk
cdc_s
cdc_s
q (sim)
q (sim)
q (hw)
q (hw)
Setup time violation where the output

settles to the simulation value. The
hardware transition is not advanced or
delayed.
hardware
differs from
simulation
hold time violations
setup time violations
Hold time violation where the output

settles to the simulation value. The
hardware transition is not advanced or
delayed.
rx_clk
rx_clk
cdc_s
cdc_s
q (sim)
q (sim)
q (hw)
q (hw)
Setup time violation where the output

settles to the complement of the
simulation value. The hardware
transition is delayed by one cycle.
Hold time violation where the output

settles to the complement of the
simulation value. The hardware
transition is advanced by one cycle.

October 2011
27
CDC Basics
Metastability
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
R1
q2
R2
clk
R3
q3
$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.
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.
28

October 2011
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
tx_reg
rx_reg
CDC Bus with a Synchronizer

tx_reg
rx_reg
reg
tx_clock
rx_clock
tx_reg
tx_clock
rx_reg
cdc_fx
checker
clocks
monitor
rx_clock
metastability
injector
tx_clock
tx_reg
tx_clock
synchronizer
cdc_fx
checker
rx_clock
rx_reg
reg
clocks
monitor
synchronizer
rx_clock
metastability
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 159 for additional information.

October 2011
29
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
cdc_d
int_d
in-band value
sync logic
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
synchronizer
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 synchronizers 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
transmit logic*
CDC signal stable

for multiple cycles**
cdc_d
no combo logic
in path*
int_d
sync logic
rx_clk
tx_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.
30

October 2011
CDC Basics
Synchronizers
Most CDC implementations use one or more synchronizers from a set of popular, wellcharacterized synchronization schemes. These structured synchronizers must follow welldefined 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
CheckerWare 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 registers load enable signal, or software might control the loading of a circuits
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).
Tx Clock
Domain
2DFF synchronizer
cdc_s
int_s
R1
Connection Rules
Logic in cdc_s path must be glitch free
Rx Clock No combinational logic is allowed in
Domain
int_s path
R2
rx_clk
rx_clk
cdc_s
int_s
q

October 2011
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
cdc_s
int_s
q
31
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_d
Tx Clock
Domain
tx_sel
rx_sel

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

Multiclock, multiaccess FIFO queues up transmitted data.
fifo synchronizer
rx_d
Tx Clock
Domain
cdc_d
tx_addr
wen
tx_clk
32
rx_d_rdy

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

October 2011
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
Tx
Clock
Domain
d[0]
cdc_d
d[1]
d[2]

Rx
Clock
Transitions of cdc_d must
Domain
2DFF
synchronizer
have a
2DFF synchronizers must obey the

CDC transfer protocol for each cdc_d
bit.
2DFF
synchronizer
2DFF
synchronizer
rx_clk
Custom Synchronizer
Special-purpose signal or data synchronizer designed, specified, and implemented by the user.
Tx Clock
Domain
cdc_d
custom synchronizer
user-defined
module
Rx Clock
Domain
q

User-defined protocol.
rx_clk
Custom synchronizers can also have clock domain crossings internal to the user-defined
module.
Tx Clock Domain
d
user-defined
module
Rx Clock
Domain

User-defined protocol.
q
rx_clk
tx_clk
custom synchronizer
with internal crossing

October 2011
33
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
Clock
Domain
cdc_d
ad hoc synchronizer
rx_int

Rx
When a changing rx_int is sampled by
Clock
Domain
rx_clk, rx_int must be stable in the
q
rx_clk
34
interval from:
active_rx_clk_edge t setup
to:
active_rx_clk_edge + t hold

October 2011
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
rx_clk
tx_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
Clock
Domain
d[0]
synchronizer
Rx
Clock
Domain
FSM
S2
next_state
cdc_d
d[1]
synchronizer
S3
synchronizer
d[2]
S1
rx_clk
S4
?
.
October 2011
35
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
Domain
Rx Clock
Domain
cdc_s
int_s
R1
R2
rx_clk
rx_clk
cdc_s
int_s
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
Domain
Rx Clock
Domain
rx_0
tx_0
async FIFO
synchronizer
tx_1
async FIFO
synchronizer
rx_out
rx_1
sel
rdy_0
arbiter
rdy_1
rx_rdy
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
Domain
Rx Clock
Domain
tx_cmd
async FIFO
synchronizer
rx_cmd
tx_data
async FIFO
synchronizer
rx_data
apply
command
to data
rx_clk
36

October 2011
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 pathsthose reconvergent paths that start from the same transmit domain
sourceare 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.

October 2011
37
CDC Basics
Reconvergence
Verifying Reconvergence
Simulation alone is not sufficient to verify that a circuits 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 circuits 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 registers 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.
38

October 2011
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
CDC scheme. 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. The CDC compiler identifies this
particular clock domain crossing and its synchronization logic.
Classes of CDC schemes with the same functionality are called CDC scheme types (to
distinguish them from individual CDC schemes). For example, the above CDC path with its
synchronization logic is a CDC scheme of the two_dff type.
CDC Schemes starting on page 179 have the detailed data sheets for the CDC schemes.
Attributes of CDC Schemes

Each CDC scheme detected by the CDC compiler has two attributes: severity and promotion
(see page 39). By default, the severity and promotion attributes are taken from the default
attributes of the CDC scheme type. You can adjust these attributes for individual CDC schemes,
groups of schemes, and for the entire set of CDC schemes of a particular scheme type, using the
set_cdc_report global directive (page 296).
Part of the initial CDC compiler run is 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.
Severity
Severity is an indicator of the seriousness of the particular logic pattern (CDC scheme). 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 static scheme, 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.

October 2011
39
CDC Basics
CDC Schemes
Evaluation
An evaluation is a valid CDC scheme that uses an appropriate synchronizer. The
schemes CDC protocol must still be checked.
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 0in_cdc database, but no
CDC protocol checkers for the scheme are promoted for assertion-based verification.
Filtered (Reporting Off)

A filtered scheme is a CDC scheme that does not need CDC analysis. For example,
test/configuration logic has a combo_logic scheme, but the combinational logic is
constant during regular operation. Here, you can filter this combo_logic scheme so it is
not reported (unless set_cdc_preference -filtered_report is specified).
Promotion
Whenever possible, CDC creates and configures a CDC transfer protocol checker for a scheme.
Most synchronizers have corresponding protocol checkers. The process of identifying a CDC
scheme and creating its protocol checker is called checker 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 set_cdc_report global directive (see page 296) 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 IFgenerate blocks (the current Questa implementation does not allow access to these block
names). But if the specified simulator is VCS (i.e. 0in -sim vcs -cmd cdc...), these checkers are
promoted. However, checkers with signals in regular RTL unnamed blocks are not promoted. If
the specified simulator is NC (i.e. 0in -sim nc -cmd cdc...), checkers with signals in implicit
generate blocks are not promoted.
40

October 2011
CDC Basics
CDC Schemes
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.
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 Clock Domain
Rx Clock Domain
tx_sig
rx_sig
DFF
DFF
DFF
rx_clk
tx_clk
Table 2-1 shows the signal synchronization scheme types.

Table 2-1. Signal Synchronization Scheme
Scheme
Synchronizer
Message
Default
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

clock.
DFF GATED SYNC
caution
four_latch
Three or more cascaded

latches.
FOUR LATCH
SYNCHRONIZER
evaluation
no_sync
none
MISSING
SYNCHRONIZER
violation
pulse_sync
Pulse.
PULSE SYNC
evaluation
shift_reg
Shift register.
SHIFT REG
evaluation
two_dff
Two or more in-phase flipflops.
TWO DFF
SYNCHRONIZER
evaluation
two_dff_phase
Two out-of-phase flipflops.
TWO DFF
SYNCHRONIZER
OPPOSITE POLARITY
caution
custom_sync
Single-bit custom
synchronizer.
CUSTOM
evaluation
or
violation

October 2011
41
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 Clock Domain
tx_data
gray
encoder
Rx Clock Domain
DFF
DFF
DFF
gray
decoder
rx_data
rx_clk
tx_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
Severity
Scheme
Synchronizer
Message
bus_dff_sync_gated_clk
Two flip-flops with gated

clock.
BUS DFF GATED

SYNC
caution
bus_four_latch
Four or more cascaded

latches.
BUS SYNC
evaluation
bus_shift_reg
Shift register.
BUS SHIFT REG
evaluation
bus_two_dff
Two or more in-phase flipflops.
BUS SYNC
evaluation
bus_two_dff_phase
Two out-of-phase flipflops.
BUS SYNC
caution
multi_bits
none
MULTIPLE BITS
violation
bus_custom_sync
Multi-bit custom.
BUS CUSTOM
evaluation
or
violation
42

October 2011
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 Clock Domain
Rx Clock Domain
tx_data
rx_data
MUX
tx_clk
tx_sel
DFF
DFF
rx_sel
rx_clk
tx_clk
Table 2-3 shows the signal/data synchronization scheme types.

Table 2-3. Signal and Data Synchronization Schemes
Default
Severity
Scheme
Synchronizer
Message
custom_sync_with_cros
sing
Custom.
CUSTOM WITH
CROSSING
evaluation
simple_dmux
Restricted/simple MUX
enable.
SIMPLE_DMUX
caution
dmux
MUX enable.
DMUX
caution
handshake
MUX enable with

handshaking.
HANDSHAKE
evaluation
memory_sync
2D array.
MEMORY SYNC
caution
fifo
FIFO.
FIFO
evaluation
multi_sync_mux_select
Multiple MUXs.
MULTIPLE
SYNCHRONIZERS AT
DMUX
caution

October 2011
43
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
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
Table 2-4 shows the potential CDC problem scheme types.

Table 2-4. Potential CDC Problem Schemes
Scheme
Problem
Message
Default
Severity
black_box
Black box in fan-out of a

synchronized signal.
BLACK BOX
caution
combo_logic
Combinational logic on a
synchronization path.
COMBO LOGIC
violation
fanin_different_clks
Fan-in logic from

multiple clock domains.
FANIN LOGIC
FROM DIFFERENT
CLOCKS
violation
reconvergence
Reconvergent CDC
signals.
RECONVERGENCE
caution
single_source_reconvergence
Reconvergent CDC
signals from a single
source.
SSR
violation
redundant
CDC signal drives

multiple synchronizers.
REDUNDANT
caution
port_constraint_mismatch
Custom synchronizers
connected in series.
PORT
CONSTRAINT
MISMATCH
violation
series_redundant
connected in series.
SERIES
REDUNDANT
caution
44

October 2011
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 multiplebit 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
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
combinational logic
drives input to synchronizer
tx_sig
rx_sig
DFF
DFF
rx_clk
tx_clk
Tx Clock Domain
DFF
Rx Clock Domain
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.

October 2011
45
CDC Basics
Static CDC Analysis
CDC checkers are not promoted for CDC schemes that have severity proven, waived or
filtered. 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 schemes
protocol cannot be violated, that scheme is reported as a proven scheme. Since the schemes
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 > maximum
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.
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:
46
dff_sync_gated_clk
four_latch
pulse_sync
shift_reg
two_dff
two_dff_phase

October 2011
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_four_latch
bus_shift_reg
bus_two_dff
bus_two_dff_phase
reconvergence (if enabled by set_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 synchronizers 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 checkers assertions completely characterize its associated synchronization

October 2011
47
CDC Basics
Static CDC Analysis
scheme. If a design cannot violate any of the checkers assertions, then the design obeys the
associated CDC synchronization scheme.
The CheckerWare assertion library includes the set of CDC checkers described in the
CheckerWare Data Book. CheckerWare CDC checkers 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 the analysis, CDC promotes instances of CheckerWare
CDC checkers depending on the synchronization scheme (although not all schemes have
associated promoted checkers). The promoted checkers validate CDC behavior during
assertion-based verification and are report in the automatically generated output 0in_cdc_ctrl.v
file (see Example 2-1 for a snippet of this file).
Example 2-1. Promoted CDC Checkers
// Synchronized multi-bit variable fifo_0_h.rp_s1
/* 0in cdc_hamming1
-tx_clock mac_clk_in
-tx_var fifo_0_h.rp_gray
-name bus_two_dff_62001
-module demo_top
-inferred */
/* 0in cdc_sample
-tx_var init_done
-rx_var tx_state[0]
-tx_clock cpu_clk_in
-rx_clock core_clk_in
-areset ( ( ! rst) )
-name no_sync_47305
-module demo_top
-inferred */
/* 0in cdc_dsel
-tx_data fstp[7:1]
-rx_data crc_1.scramble
-rx_clock mac_clk_in
-tx_data_select init_done
-rx_data_select init_done_r2
-tx_min P_cpu_clk_mac_clk_tx_min
-areset ( ( ! rst) )
-name dmux_30303
-module demo_top
-inferred */
/* 0in cdc_glitch
-var check_en_r1
-clock mac_clk_in
-name combo_logic_85239
-module demo_top
-inferred */
. . .
48

October 2011
CDC Basics
Formal Verification
Path and Protocol ID

Each CDC path has a unique path IDderived from the path parametersthat 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:
0in_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
0in_cdc_ctrl.v (promoted checker file)

/* 0in cdc_sample
-tx_var crc_seed[7:1] -rx_var crc_1.crc_16
-tx_clock cpu_clk_in -rx_clock mac_clk_in
-name multi_bits_76265 -module demo_top -inferred */
The CDC Checks window of the 0in_cdc viewer.
The Detail window of the 0in_cdc viewer.
Formal Verification
Formal verification uses mathematical analysis to verify a designs assertions. It has an
advantage over simulation with assertions as it automatically analyzes complex corner cases
that are difficult to simulate. Whereas a simulated design only covers the state spaces reached
by simulation, formal analysis coverage is exhaustive. CDC checkers are compatible with the
Questa Formal tools: Prove and Confirm. Only a small incremental effort is needed as the
Questa Formal tools use the same configuration files and assertions as assertions in simulation.
A designs individual assertions (including CDC checker assertions) are called formal targets
when they are used as goals that the formal tools try to prove or disprove. Other assertions can
be used as guides for the formal tools to ensure they do not attempt to test illegal behavior.
These assertions are called formal constraints. The CDC checkers assertions are always used
as targets, not constraints.
Prove is a property checker that tries to prove targets cannot be violated. Targets with
inconclusive results are passed to Confirm to attempt to disprove them. These tools disprove a
target assertion by finding a counterexample to the assertion. A counterexample is a legal
stimulus sequence applied to the design that eventually makes the assertion fail (that is, fire).
Counterexamples are also called assertion firings. Refer to the Questa Formal User Guide for
information regarding the Questa Formal tools.

October 2011
49
CDC Basics
Simulation
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 0in_cdc viewer. Use the File >Merge Database command to
load the database from the simulation, then from CDC Checks tab, you can browse the data for
assertion firings (Figure 2-9).
Figure 2-9. CDC Checks Simulation Results
To invoke the waveform viewer with the assertion firing from simulation (Figure 2-10) 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.
50

October 2011
CDC Basics
Simulation
Figure 2-10. Show Simulation Firings
View the coverage statistics for the simulation from the Design window (Figure 2-11).

October 2011
51
CDC Basics
Simulation
Figure 2-11. Simulation Coverage
52

October 2011
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-12 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-12. CDC Checks Status Flags
status flags in CDC Checks window
Table 2-5. CDC Checks Status Flags

Flag
Description
Static Prove Sim
Violation and Firing

CDC schemes severity level is violation and its protocol is
violated in simulation.
Violation
CDC schemes severity level is violation.
Firing
CDC schemes protocol is violated in simulation.
Proven
CDC schemes protocol cannot be violated.
Evaluation
CDC schemes severity level is evaluation.
Covered
CDC schemes protocol checkers cover points are covered in
simulation.
Caution
CDC schemes severity level is caution.

October 2011
53
CDC Basics
Status Flags
Table 2-5. CDC Checks Status Flags

Flag
Description
Static Prove Sim
Inconclusive
CDC schemes protocol is not guaranteed. Formal analysis could
not prove that the protocol cannot be violated.
Evaluated
CDC schemes protocol checker is evaluated in simulation.
Not Promoted
CDC scheme has no protocol checker automatically generated or
the protocol checker is not promoted because the protocol is
proven valid during static CDC analysis.
Waived
CDC schemes severity level is waived.
Filtered
CDC schemes severity level is off.
54

October 2011
Chapter 3
Compilation
CDC analysis runs on a compiled image of the design logic plus a clock domain model. A set of
design compilation utilities is used to compile the design logic from source files. Then, the CDC
analyzer (cdc) is used to create a clock domain model. If this compilation completes without
error, cdc performs CDC analysis and generates data for the CDC GUI. Two methods can be
used to compile the design and clock domain model, and then perform CDC analysis:
1-Step Compilation
Instead of running the design compilation utilities separately from the cdc command,
add the arguments for design compilation to the cdc invocation. The design is compiled
first (using the design compilation utilities under-the-hood). Then, the clock domain
model is created and CDC analysis is performedall in one step using the cdc
command. This method only works for restricted Verilog designs.
2-Step Compilation
Use the design compilation utilities to create and maintain a compiled design library.
Use the cdc command to compile the clock domain model and run CDC analysis.
Figure 3-1. CDC Compilation Methods
1-Step Compilation
Compile design libraries
and clock domain model
Questa Compilers
and Library
Management Tools
design libraries
Verilog
design
files
0in -cmd cdc
clock domain
model
control
files
2-Step Compilation
design
files
Questa Compilers
and Library
Management Tools
design libraries
control
files
0in -cmd cdc

October 2011
clock domain
model
Compile clock domain

model
55
Compilation
1-Step Compilation
1-Step Compilation
For the compilation of Verilog-only designs (but not SystemVerilog) you can use the 1-step
compilation method. To do this, add the 1-step compilation arguments (Table 3-1) to the cdc
invocation. The cdc compiler uses the design compilation utilities under-the-hood to compile
the design and stores the compiled design library in the 0in cache. For example:
cdc -d dut -ctrl ctrl.v -f design.f +define+mode=initialized -y ../mylib
See cdc: Clock Domain Crossing Analyzer on page 64 for a description of the cdc command
and clock domain model compilation.
Table 3-1. 1-Step Compilation Options
{Verilog_file | f filelist} [-v95] [+define{+macro[=value}]
[+incdir{+include_dir}] [+libext{+extension}] [y library_dir] [v library_file]
[skip_protected_modules] [skip_protected_code] [ignore_translate_off]
[ignore_synthesis_off] [modelsimini init_file] [dw]
Verilog_file
f filelist
v95
+define{+macro[=value]}
+incdir+dir
+libext{+extension}
y library_dir
v library_file
skip_protected_modules
skip_protected_code
ignore_translate_off
ignore_synthesis_off
dw
56
Verilog source files.

File containing additional Verilog design files and arguments
Verilog version is Verilog 95. Default: Verilog 2K.
Text macro specification.
Include directory.
File extensions to use when searching for library files. For
example, +libext+.v.
Directory containing library files.
Library file.
Skip encrypted modules.
Skip encrypted code. This option skips parsing of all modules
containing any protected code. This can result in the parent
module being black boxed (because it causes the module to be
unresolved).
Include logic in translate_off blocks.
Ignore synthesis_off directives.
Compile remodeled versions of DesignWare elements.

October 2011
Compilation
2-Step Compilation
2-Step Compilation
With the 2-step compilation method, first use the design compilation utilities to create and
maintain a compiled version of the design logic. Then, use the cdc command to create the clock
domain model and perform CDC analysis.
Step 1: Compile and Maintain Design Libraries

Figure 3-2 shows the design compilation utilities. These front-end utilities are used to create
and maintain the compiled design library data. The same utilities and procedures work for all
Questa tools.
Figure 3-2. Design Compilation
vlog
vcom
Verilog
design files
VHDL
design files
vlog
vcom
Verilog
design files
VHDL
design files
Compiled Design Library
Library
Utilities
work
vopt/vsim
cdc
csl
0in_autocheck
Questa
Questa
Advanced
Verification
Simulator
0in_prove
0in_confirm
Preparing a Design Library

Before you can compile source code into the work library, you must generate an initial library
and prepare the environment for design compilation (Figure 3-3).
Figure 3-3. Preparing the work Library
vlib work
vmap work work
generate
work
generate
./modelsim.ini
defaults file

October 2011
edit
./modelsim.ini
custom defaults file
57
Compilation
2-Step Compilation
1. Generate the initial library.

prompt> vlib work
2. Map the work directory to the work library.

prompt> vmap work work
The name work is the default working library. A library statement (for work) is not
needed in the source. The work library is the default destination of compiled design
units. So, the above mapping is not necessary. However, the vmap command generates a
modelsim.ini file in the current run directory. The modelsim.ini file sets the library
mappings used for simulation by vsim and for CDC compilation/analysis by cdc. It also
sets the default values for compiler and simulator arguments. These default values can
be adjusted, which makes the command argument defaults user-configurable.
3. Edit the modelsim.ini default file to adjust the defaults to fit your environment.
prompt> vim modelsim.ini
The vcom and vlog compilers have an array of compilation parameters that control
exactly how source and resource data are compiled. Some of these compilation
parameters can be overridden at compile time by compiler switches. For example, the
-2008 argument to vcom directs the compiler to assume VHDL-2008 semantics when
compiling source files. Compilation parameters that are not overridden with compiler
switches assume the defaults specified in a modelsim.ini file.
modelsim.ini
The vcom/vlog compilers set $MODEL_TECH to the same directory as
$MODEL_TECH_OVERRIDE, if it is defined. Otherwise, they set $MODEL_TECH to the
directory containing the executable software. To ensure compatibility of software tools, you
should run the compilation commands (vlib, vmap, vcom, vlog, etc.) that are located in the
Questa CDC/Formal distribution software. The Questa CDC/Formal distribution versions of
vcom/log set $MODEL_TECH as follows:
set MODEL_TECH zeroin_install_dir/modeltech/plat
The vcom/vlog design compilers and the cdc clock domain analyzer use the search path shown
in Figure 3-4 to find the modelsim.ini file for their compilations.
58

October 2011
Compilation
2-Step Compilation
Figure 3-4. modelsim.ini Search Path

modelsimini modelsim.ini_file
$MODELSIM
$MGC_WD/modelsim.ini
./modelsim.ini
Finding which modelsim.ini file is used

prompt> vsim -c
QuestaSim> where
# Current directory is: /u/cdc_demo
# Project is: modelsim.ini
$MODEL_TECH/modelsim.ini
$MODEL_TECH/../modelsim.ini
$MGC_HOME/lib/modelsim.ini
vlog/vcom compilers set $MODEL_TECH internally to the install
directory for the tool. For Questa CDC/Formal tools:
zeroin_install_dir/modeltech/plat
Compiling Design Files

After initializing the work design library and setting up the modelsim.ini file, you can compile
design files into the work library (Figure 3-5).
Figure 3-5. Compiling Design Files
design
files
vcom/vlog
append/update
work
modelsim.ini
Use vcom to compile VHDL style source files and vlog to compile Verilog style (including
SystemVerilog) source code. These compilers have long lists of arguments, but many options
are used to fine-tune simulation (vsim). Table 3-2 and Table 3-3 show the options that are
relevant to Questa CDC/Formal Verification.
Table 3-2. vcom Syntax
vcom [compile_options] VHDL_file
VHDL_file
VHDL source files.
compile_options
[-work logical_name] [modelsimini init_file]
[-87 | -93 | -2002 | -2008] [-explicit]
[-skipsynthoffregion [-synthprefix keyword]]
[-check_synthesis] [-noindexcheck | -norangecheck | -nocheck]
[-source] [-time] [-mixedsvvh [b | l | r] [i]] [-pslfile vunit_file]
[-lower | -preserve] [-l file] [-quiet] [-nowarn number]
[{-fatal | -error | -warning | -note | -suppress | -msglimit}
msg_number[,msg_number]]
[-f arg_file] [other_vcom_options]

October 2011
59
Compilation
2-Step Compilation
Table 3-3. vlog Syntax

vlog [compile_options] Verilog_file
Verilog_file
HDL source files.
compile_options
[-work logical_name] [-libmap file [-libmap_verbose]]

[modelsimini init_file] [{-Lf | -L } library]
[-vlog95compat | -vlog01compat]
[-sv] [sv05compat | sv09compat]
[-skipsynthoffregion [-synthprefix keyword]]
[-skipprotected | -skipprotectedmodule] [-pedanticerrors]
[-timescale units/precision | -override_timescale units/precision]
[+define{+macro[=value}] [-convertallparams]
[+floatparameters[+param_path[.]]] [+incdir{+include_dir}]
[+libext{+extension}] [-y library_dir] [-v library_file]
[-compile_uselibs[=uselib_dir]] [printinfilenames] [-source]
[-time] [-93] [-u] [-mixedsvvh [b | s | v] [packedstruct]]
[-mfcu [-cuname comp_unit] | -sfcu] [-pslfile vunit_file]...
[-l file] [-quiet] [-nowarnID | -nowarn number]
[{-fatal | -error | -warning | -note | -suppress | -msglimit}
msg_number[,msg_number]]
[-f arg_file] [other_vlog_options]
Compile Order
For a Verilog compilation, you can compile almost all compilation units in any order using any
number of invocations of vlog. When cdc and csl load the compiled design, they resolve model
instantiations and external hierarchical references. The one case where order matters is:
SystemVerilog packages must exist for the items they define to be recognized by the scopes in
which they are imported. IEEE Std 1800-2005 LRM
For a VHDL compilation, order matters: you must compile entities/configurations before the
architectures that reference them.
Resource Libraries
A resource library is a pre-compiled parts source for your design. It is typically a static library
supplied by a vendor or another design team, but you also can create your own resource
libraries. Resource libraries are compiled into libraries distinct from work using the same
vlib/vmap and vcom/vlog utilities used for compiling the work design library.
The distribution software includes pre-compiled resource libraries for common uses, located in
<zeroin_install_dir>/modeltech. The [Library] section of the system-level modelsim.ini file
(<zeroin_install_dir>/modeltech/modelsim.ini) shows these resource libraries:
[Library]
std = $MODEL_TECH/../std
ieee = $MODEL_TECH/../ieee
60

October 2011
Compilation
2-Step Compilation
verilog = $MODEL_TECH/../verilog
vital2000 = $MODEL_TECH/../vital2000
std_developerskit = $MODEL_TECH/../std_developerskit
synopsys = $MODEL_TECH/../synopsys
modelsim_lib = $MODEL_TECH/../modelsim_lib
sv_std = $MODEL_TECH/../sv_std
mtiAvm = $MODEL_TECH/../avm
mtiOvm = $MODEL_TECH/../ovm-2.1
mtiUPF = $MODEL_TECH/../upf_lib
mtiPA = $MODEL_TECH/../pa_lib
floatfixlib = $MODEL_TECH/../floatfixlib
mc2_lib = $MODEL_TECH/../mc2_lib
The [Library] section of the modelsim.ini file shows the library mappings for user-defined
libraries as well. For example, suppose you create a library with the physical location ../shiba
and map this library to the logical name my_shiba.
prompt> vlib ../shiba
prompt> vmap my_shiba ../shiba
If the local run directory does not already have a modelsim.ini file, vmap copies a version of
$MODEL_TECH/../modelsim.ini to the local run directory. Then, vmap updates modelsim.ini
with the new mapping:
prompt> more modelsim.ini
. . .
[Library]
others = $MODEL_TECH/../modelsim.ini
my_shiba = ../shiba
work = work
If you use vmap to map a library to a logical name that is already mapped in the local
modelsim.ini file, the new mapping simply replaces the old mapping. However, if you edit the
local modelsim.ini file and specify two library mappings with the same logical name, the file is
corrupt and you get an error when you try to compile.
The others clause in the [Library] section has a special meaning. If a compiler does not find a
referenced library in the local modelsim.ini file, but the local modelsim.ini file has an others
clause, the compiler checks the [Library] section of the file specified by others. As with library
mappings, only one others clause is allowed in a modelsim.ini file. However, note that the
others clause provides a method for creating a hierarchy of library mappings because the file
referred in an others clause can contain another others clause, and so on.
Verilog Compilation with Resource Libraries

All modules, interfaces and UDPs instantiated in a Verilog design must be compiled into one or
more libraries. For many designs, you can do this by compiling these design units into the work
library along with the design logic. But, all design unit names must be unique in a library, so in
this case all models in work should have unique names. However, many designs require the
flexibility of switching among various implementations of cells with the same name or they are

October 2011
61
Compilation
2-Step Compilation
so complex that using resource libraries significantly simplify the organization of the design
data. In these cases, you need to use reference libraries. Consider this example:
prompt> vlib work
prompt> vlib asiclib
prompt> vlog -work asiclib and2.v or2.v
-- Compiling module and2
-- Compiling module or2
Top level modules:
and2
or2
prompt> vlog top.v
-- Compiling module top
Top level modules:
top
This example compiles and2 and or2 into the asiclib library and top into work.
When you run vlog to compile the top-level design, the compiler must know the resource
libraries needed to resolve instantiations and the order that these libraries should be searched (in
case multiple libraries contain different versions of the same models). However, instantiation
bindings are not determined during compilation; they are determined when you run cdc or csl.
So, whatever resource libraries and order specified to vlog should match the libraries and order
used by cdc and csl.
Resource libraries are specified with the L library and Lf library options to vlog, cdc and csl.
These utilities use the following search order to resolve each instantiation (and they stop at the
first match):
1. Libraries specified with the Lf option, in the order they appear in the invocation.
2. The current effective uselib library, if specified.
3. Search path specified in the LibrarySearchPath variable of modelsim.ini (as if these
libraries were specified with the L argument).
4. Libraries specified with the L option (searched in the order specified in the invocation).
5. work
6. Library named in the explicit escaped identifier instance name.
Verilog Compilation with Source Libraries

Verilog-XL style compilation is supported. Here, rather than compiling library models into
resource libraries, source libraries (i.e., un-compiled model descriptions) are used to create
compiled models in work. Source libraries are searched after the source files on the command
line are compiled. If any instantiation references are missing, the source libraries are searched in
command-line order. The following Verilog-XL style arguments are recognized by vlog: v file,
y directory, +libext+suffix, +librescan, +nolibcell and R simargs.
62

October 2011
Compilation
2-Step Compilation
VHDL Compilation with Resource Libraries

VHDL uses library clauses to make objects in reference libraries visible to the current design
unit. A library clause appears at the beginning of the design unit and its scope is the region from
the end of the library clause to the end of the design units declarative region. A use clause
associated with the library clause can be used to specify which reference library objects are
visible (with the all suffix indicating all objects). For example:
library IEEE;
use IEEE.std_logic_1164.all;
The IEEE library is a library of precompiled synthesis and arithmetic packages specially tuned
to the Questa tools. IEEE contains the following packages: math_complex, math_real,
numeric_bit, numeric_std, std_logic_1164, std_logic_misc, std_logic_textio, std_logic_arith,
std_logic_signed, std_logic_unsigned, vital_primitives and vital_timing. The above clauses
specify that the logical library IEEE is used as a reference library and all declarations in the
std_logic_1164 package are made visible for the scope of the design unit. (For strict IEEE
compliance, the IEEEPURE library contains only the IEEE approved packages.)
Certain libraries are predefined and are visible without explicit specification. The WORK library
is the current target of the compilation. Design units and packages in WORK are visible. The
STD library contains the standard, env and textio packages. Both WORK and STD are
predefined and are visible without explicit specificationas if the design units have the
following statements:
library STD, WORK;
use STD.standard.al
Compiling FPGA Source Libraries

CDC analysis is performed on synthesizable objects in the design: CDC analysis treats
modules/entities that contain unsynthesizable code as inferred black boxes. In addition, some
VHDL FPGA libraries use VITAL constructs. These are not synthesizable, so resource library
elements containing any of these constructs are inferred as black boxes as well. Some Verilog
FPGA libraries contain UDPs, but (unlike VITAL constructs) Questa compilation automatically
remodels most of these into synthesizable RTL. However, some Verilog FPGA resource library
elements model global signals (i.e., signals accessible throughput the design) as hierarchical
references to signals in separate top-level blocks outside the DUT. Library elements that
reference global signals in this way are also analyzed as inferred black boxes.
You can manually identify the clock domains of ports of these black boxeswhich helps with
the analysis of CDC issues outside the black boxesbut internal clock domain crossing
information of black boxes is missing. The best solution for CDC analysis is to use
synthesizable libraries.

October 2011
63
Compilation
2-Step Compilation
Some general-purpose FPGA resource libraries are available in synthesizable form. These
libraries are often called formal-friendly because they are usable with formal model checkers
such as Questa Formal and formal equivalence checkers such as FormalPro. They are also
appropriate for the Questa CDC analyzer and other tools that need to synthesize a netlist. Some
FPGA vendors (for example, Altera and Actel) include synthesizable libraries in their standard
design kit installations. Xilinx, however, does not include the synthesizable unisim and simprim
libraries within its standard ISE software installation. Synthesizable resource libraries
(optimized for Questa tools) and other supporting files for two common FPGA library families
are included with the Questa CDC/Formal distribution software in the following directories:
$HOME_0IN/share/fpga_libs/Altera
$HOME_0IN/share/fpga_libs/Xilinx
If the FPGA libraries used for simulation are synthesizable (which is rare except for Verilogonly designs), recompilation of the pre-compiled libraries might not be necessary for CDC
analysis. In all other cases, you must compile an appropriate version of the library source files
for use with Questa CDC. When synthesizable FPGA resource libraries are available, you
should use them instead of the unsynthesizable libraries optimized for simulation.
The VHDL IEEE, STD and SYNOPSYS libraries are pre-compiled and are automatically
recognized by Questa CDC/Formal software. You must compile all other resource libraries
using the vcom/vlog commands on the appropriate FPGA library source files. If you have a
VHDL-only design or if you have a mixed-language design with library elements instantiated in
VHDL, first compile the VHDL component definitions (but not the VHDL models of the library
elements) and then compile the appropriate Verilog library models.
Step 2: Run CDC Compilation

cdc: Clock Domain Crossing Analyzer
The cdc command runs within a special shell called the 0in shell (see 0in on page 351), which
can run as a batch process or interactively. To run cdc as a batch process, use the -cmd option to
0in:
prompt> 0in -cmd cdc cdc_options
The cdc command performs 1-step compilation if necessary, compiles the clock domain model
and performs CDC analysis. Table 3-4 shows the syntax for the cdc command (the 1-step
compilation options are hidden).
64

October 2011
Compilation
2-Step Compilation
Table 3-4. cdc Syntax

cdc d design
[ report_clock | report_modes | hier_cdc_options] [work work_library]
[{L | Lf} library] [cuname comp_unit] [cache pathname] [options]
d design
HDL design unit to be verified.
report_clock
Report only clock domains and exit. Default: perform full CDC
analysis.
report_modes
Infer all modes of operation or verifies the user-defined modes

and exits (without doing any CDC analysis). Generate a modal
script (0in_mode.scr).
hier_cdc_options
[report_hier_scripts | report_constraints block

| hier | hier_block block | hier_instance instance
| [hier_cache ILM_cache]
[hier_ctrl_file_model block CFM_ctrl_file]]
work work_library
Logical name of the design library containing precompiled

design units. Also used as the target library for compilation
performed by cdc. Default: work in the current run directory.
L library | Lf library
Resource library containing pre-compiled modules for the

compilation.
cuname comp_unit
Name of a compilation unit specified to vlog.
cache pathname
0in cache directory. Default: same as the 0in shell cache

directory.
control options
[ [ctrl file] [ctrl_list control_file] [v95 | v2k | sv] ]

[vhctrl control_file] [93 | 87 | 2002 | 2008]
| [ctrl_module module] ]
reporting options
[cr report_file] [verbose] [gen_port_domain_template]

[print_all_cdc_paths] [+nowarn{+messageID}]
[+error{+messageID}]
sdc options
[sdc_in sdc_file] [sdc_out file] [report_sdc]
advanced options
[de {[mod.]inst_pattern}] [di {[mod.]inst_pattern}]

[G name=value] [g name=value] [mode mode] [fx]
[process_dead_end] [effort unlimited] [dw]
compile cdc assertions

options
[compile_assertions prefix hierarchy_prefix

[compiled_assertion_report file]
[sim {questa | vcs | nc | nc3}] [sif root_name] [rel_paths] ]

October 2011
65
Compilation
2-Step Compilation
Parallel Sessions
With a compiled work library created with 2-step compilation, you can run multiple cdc
sessions in parallel off the same library. However, to do this, you cannot specify any -ctrl,
-ctrl_list or -vhctrl options. These options cause the control modules and entities to be compiled
and written into the work library during the session, which changes the library and can interfere
with other parallel sessions. The result is one or more of the sessions can fail or can return
unrelated results. When running parallel cdc sessions the work library must remain static.
To work around this limitation, you can pre-compile all control files during Step 1before
running any cdc sessions in parallelusing the vcom and vlog compilers. After compiling the
control modules and entities, you then specify their names using the -ctrl_module option to cdc.
In particular, you can compile different control modules for the various parallel sessions ahead
of time and then just specify the -ctrl_module design units applicable to each particular parallel
session. For example:
prompt> vlog -work MYLIB dut.v
prompt> vlog -work MYLIB common_ctrl.v run1_ctrl.v run2_ctrl.v
plat1> 0in -cmd cdc -od cdc1_results -L MYLIB -d MYLIB.dut \
-ctrl_module MYLIB.common_ctrl -ctrl_module MYLIB.run1_ctrl ...
plat2> 0in -cmd cdc -od cdc2_results -L MYLIB -d MYLIB.dut \
-ctrl_module MYLIB.common_ctrl -ctrl_module MYLIB.run2_ctrl ...
Note
You also can run csl and 0in_autocheck utilities in parallel with each other and with cdc
off the same work library using this method.
In some cases, pre-compiling control files into a main library for all CDC sessions at the same
time is not practical. For example during a hierarchical CDC flow, control modules/entities
might be generated and compiled automatically as each block-level session is started. In such
cases, you can pre-compile the control files for the separate sessions to separate libraries. For
example:
prompt> vlog -work MYLIB dut.v
prompt> vlog -work MYLIB common_ctrl.v
plat1> vlog -work MYLIB_BLK1 blk1_ctrl.v
plat1> 0in -cmd cdc -od cdc_blk1 -L MYLIB -L MYLIB_BLK1 -d MYLIB.dut \
-ctrl_module MYLIB.common_ctrl -ctrl_module MYLIB_BLK1.blk1_ctrl ...
plat2> vlog -work MYLIB_BLK2 blk2_ctrl.v
plat2> 0in -cmd cdc -od cdc_blk2 -L MYLIB -L MYLIB_BLK2 -d MYLIB.dut \
-ctrl_module MYLIB.common_ctrl -ctrl_module MYLIB_BLK2.blk2_ctrl ...
66

October 2011
Compilation
SDC Data
SDC Data
You can import an SDC file for the CDC compilation. Each supported SDC command is
converted to an equivalent global directive. Similarly, you can export an SDC file at the end of
CDC compilation and analysis. The relevant global directives, the inferred clocks and the
inferred port domains are converted to equivalent SDC commands.
Importing an SDC File

When you import an SDC file, supported SDC commands are converted to equivalent global
directives (Table 3-5). The SDC version must be 1.6 (or earlier), otherwise an hdl-148 warning
is reported. There is no support for design database queries. All signals must be explicitly listed
in the SDC file.
Table 3-5. Imported SDC Commands
SDC Command
Global Directive
create_clock
set_cdc_clock
create_generated_clock
set_cdc_clock
set_input_delay
set_cdc_port_domain
set_output_delay
set_cdc_port_domain
set_input_transition
set_cdc_port_domain
set_logic_one
set_constant
set_logic_zero
set_constant
set_case_analysis
set_constant
You can import SDC data two ways:
Directly
prompt> 0in -cmd cdc -sdc_in sdc_file ...
The SDC data from sdc_file is converted and used in the CDC compilation.
Indirectly
prompt> 0in -cmd cdc -report_sdc -sdc_in sdc_file ...
prompt> 0in -cmd cdc -ctrl 0in_sdc_ctrl.v ...
The -report_sdc option scans the CDC data and generates a control file (0in_sdc_ctrl.v)
containing the global directive equivalents of the relevant SDC commands in sdc_file
(Example 3-1). The second invocation of cdc runs CDC compilation and analysis with
the converted SDC constraints.

October 2011
67
Compilation
SDC Data
Example 3-1. 0in_sdc_ctrl.v

module zin_sdc_ctrl_top;
///// set_cdc_clock
// 0in set_cdc_clock cg.c1 -period 10
// 0in set_cdc_clock cg.c2 -period 15
///// set_port_domain
// 0in set_cdc_port_domain din -clock cg.c2
// 0in set_cdc_port_domain dout -clock cg.clk
///// set_constant
// 0in set_constant cir_a.cont[1] 1
// 0in set_constant cir_a.cont[0] 0
endmodule
Exporting SDC Data

When you export an SDC file, appropriate global directives are converted to equivalent SDC
commands (Table 3-6). In addition, inferred clocks and port domains are converted to
equivalent SDC commands (Table 3-6).
Table 3-6. Exported SDC Commands
Global Directive
SDC Command
set_cdc_clock
create_clock
set_cdc_port_domain
set_input_delay
set_cdc_port_domain
set_output_delay
set_constant
set_logic_one, set_logic_zero
set_cdc_report -severity off
set_false_path
Table 3-7. Inferred Clocks and Port Domains

Design Object
SDC Command
Top-level inferred clock
create_clock
Inferred domain for primary input port
set_input_delay
Inferred domain for primary output port
set_output_delay
CDC path
set_false_path
By default, all CDC paths are written.

To export an SDC file characterizing the CDC constraints (Example 3-2), include the -sdc_out
option in the cdc invocation:
prompt> 0in -cmd cdc -sdc_out file ...
68

October 2011
Compilation
SDC Data
Example 3-2. SDC Export File

#####################################################################
set sdc_version 1.6
#####################################################################
# Clock Information
#####################################################################
# create_clock [get_ports { clk }] -period <N>
#####################################################################
# Constant Information
#####################################################################
set_logic_zero [ get_ports { d[2] } ]
set_logic_one [ get_ports { d[1] } ]
#####################################################################
# Port Domain Information
#####################################################################
#
#
#
#
set_output_delay
set_output_delay
set_output_delay
set_output_delay
#
#
#
#
#
set_input_delay
set_input_delay
set_input_delay
set_input_delay
set_input_delay
0
0
0
0
0
0
0
0
0
-clock
-clock
-clock
-clock
[get_clocks
[get_clocks
[get_clocks
[get_clocks
[get_ports
[get_ports
[get_ports
[get_ports
[get_ports
{
{
{
{
{
{
{
{
{
clk
clk
clk
clk
}]
}]
}]
}]
[get_ports
[get_ports
[get_ports
[get_ports
{
{
{
{
q[0]
q[1]
q[2]
q[3]
}]
}]
}]
}]
clk }]
d[0] }]
d[1] }]
d[2] }]
d[3] }]
#####################################################################
# CDC Path Information
#####################################################################
set_false_path -from [get_ports { d }] -to [get_ports { q }]

October 2011
69
Compilation
Design Style Restrictions

The Questa CDC/Formal tools can analyze most design styles seamlessly. However, some
design styles and HDL constructs cannot be represented in the CDC analysis model. As cdc
compiles the CDC model of a DUT, it handles each unsupported design style or construct in one
of the following ways:
The parent module/entity containing the design style is automatically marked as an

inferred black box. Output signals of a black box are treated as asynchronous inputs to
the DUT, which can result in extra violations. Mark the module/entity as a user-defined
black box (see set_black_box on page 264) to remove these violations. Inputs to black
boxes are reported as black_box schemes with caution severity, by default.
The cdc compiler terminates with an error. You must eliminate the error before cdc can
compile the CDC model.
You have the following ways to manually adjust the compilation of the CDC model of a DUT.
Skipping system calls (+skip_syscall).

The outputs of unknown system calls are ignored. You can get cdc to skip over system
calls when compiling the CDC model. To direct cdc to bypass one or more system calls
and omit them from the CDC logic, use the +skip_syscall option to the cdc command.
This option has the following syntax:
+skip_syscall{+syscall_name}. . .
Marking modules as black boxes (set_black_box).

When a module cannot be synthesized and is part of the DUT, it can be skipped by
marking it as a black box. A module is marked as a black box using the following
checker directive in the checker control file:
// 0in set_black_box module_name
Use the set_cdc_port_domain global directive to identify the clock domains of the I/O
ports of these user-defined black boxes.
The following HDL constructs can impact cdc performance, creating long cdc run times and
high memory consumption.
70
Variable bit-selects and variable shifts on large bit-vectors (greater than 1000 bits) used
in nested for-loop statements.
Large 2-D arrays (greater than 100words) defined in the local scope of a function/task.
Large numbers of gate-level instances.
Large numbers of functions or tasks used in nested for-loop statements.

October 2011
Compilation
synthesis_off and translate_off Regions

By default, the vlog/vcom compilers do not skip the processing of code inside translate_off and
synthesis_off regions. If you want vlog or vcom to skip translate_off and synthesis_off regions,
specify the -skipsynthoffregion command argument. Pragma keywords recognized by the
compilers are: pragma, synopsys, 0in, mentor, mspa, mti and vcs. For example:
-- synopsys synthesis_off
synthesis off block
-- synopsys synthesis_on
-- 0in translate_off
translate off block
-- 0in translate_on
You also can specify a user-defined translate_off/synthesis_off keyword using the synthprefix
keyword option to vlog/vcom.
If a design unit is immediately preceded by a translate_off/synthesis_off pragma, the design unit
is black boxed and you get a vopt warning:
** Warning: (vopt-2057): file(line): translate_off pragma active at the
start of entity entity. It BBes the module.
The translate_off/synthesis_off pragmas reset at the end of the design unit. That is, they are
active until the end of the current design unit or until the terminating pragma, whichever comes
first. If a translate_off/synthesis_off block crosses a design unit boundary, the code from the
pragma to the end of the design unit is skipped, but the code in the next design is elaborated
(which is probably not the expected result). When the subsequent translate_on/synthesis_on
pragma is reached, an Ignoring pragma warning is reported.
For example, consider the following:
-- synopsys translate_off
entity bot ...
end entity
arch bot ...
end arch
entity top...
end entity
arch top
u1: bot
end arch
-- synopsys translate_on
Here, the bot entity is back-boxed (and the vopt-2057 warning is reported). But the translate_off
region terminates at the end of the bot entity design unit. The bot and top architectures are not in
any translate_off region. When translate_on is processed, it is reported as an ignored pragma.

October 2011
71
Compilation
Most likely, the expected outcome is accomplished by:

entity bot...
end entity
arch bot...
end arch
entity top...
end entity
arch top
u1: bot
end arch
override_on/override_off Parser Directives

If you specify -skipsynthoffregion and then want the Questa compilers to process a translate_off
or synthesis_off region, enclose the region in the 0in override_on and 0in override_off
comments:
//0in override_on
// synopsys translate_off
synthesis translate_off block
// synopsys translate_on
//0in override_off
72

October 2011
Compilation
Verilog
The Questa compilers mark objects containing unsupported code as black boxes or if problems
are too severe, cdc terminates with errors. By default, all output signals from a black box (and
all signals in the black box) are treated as primary inputs to the DUT. If possible, use ifdef
directives or remodel the constructs. Table 3-8 shows the unsupported Verilog-95 (-v95) and
Verilog 2005 (default) constructs.
Table 3-8. Unsupported Verilog Constructs
Gates
cmos, nmos, pmos, rcmos, rnmos, rpmos, tran, tranif1, tranif0,

rtran, rtranif1, rtranif0, comb, seq, mos.
Statements
forever, while, deassign, force-release, wait, fork, join

for- and repeat-loop statements that are not statically
unrollable.
Numbers
Reals.
Tasks and Functions
Reentrant tasks and recursive functions.

Unknown functions (undefined and predefined system
tasks/functions).
Resets
Unsupported asynchronous reset templates.
Ports
Multiple ports with the same name and inconstantly-defined

ports (i.e., a port defined by a non-ANSI port definition or
missing port direction/type).
Other Constructs
Events, event declarations and event control assignments.

Disables with hierarchical labels.
Non-constant parameters, loop indexes and part selects.
Different load conditions for memory.
Attributes are partly supported.
Table 3-9 lists the restrictions on the Verilog design styles enforced by the Questa compilers.
Table 3-9. Verilog Design Style Restrictions
Resets
Primary inout ports cannot be used as resets. These are cdc

errors.
Bused single-bit asynchronous reset are supported but multiplebit asynchronous reset signals are not. For example, the
following code produces an elaboration-541 error (Multi-bit
reset signals are not supported) and cdc terminates:
input [0:3] arst_vector;
reg r;
always @(posedge clk or posedge arst_vector)
if (arst_vector) r <= 0;
else if (e) r <= d;

October 2011
73
Compilation
Table 3-9. Verilog Design Style Restrictions (cont.)

If an asynchronous reset does not follow one of the following
templates, the parent module is marked as a black box):
always @(posedge_negedge clock or posedge areset)
if (areset) (. . . )
else (. . . )
or
always @(posedge_negedge clock or negedge areset)
if (!areset) (. . . )
else (. . . )
Clocks
Primary inout ports cannot be used as clocks. These are cdc

errors.
always Blocks
Memories driven in multiple always blocks are not supported.

Their outputs are degraded.
The same register bit must not be driven in multiple always
blocks. The entire register output is degraded. (Individual bits
in a register can be driven in different blocks.)
Tasks and Functions
Tasks and functions should not retain state between calls.

A task or function called from a combo always block or a
function on the RHS of a continuous assign statement cannot
modify a state (register) outside of the task or function.
Otherwise, these calls result in simulation/synthesis
mismatches.
Functions can call SVA built-in functions (for example, $past).
But if the built-in SVA function does not have an explicit
clock, the calling Verilog function must have a default clocking
block.
Combinational Loops
Combinational loops are not supported.
RAMs
RAMs with multiple write clocks are not supported. These are
cdc errors.
UDPs
Supported: Edge-sensitive sequential UDPs (single clock,

single edge), level-sensitive sequential UDPs, combinatorial
UDPs. UDPs with notifiers are not black boxed (notifier row is
ignored for synthesis).
Not supported: Multiclock UDPs and UDPs working on both
the edges of a clock.
Race Conditions
Logic has a race condition when the order of arrival of two

signals at a point is indeterminate and the exact arrival order
affects the designs state. For example, if a data signal and
clock signal arrive simultaneously at a register, the data signal
might, or might not, be clocked at that time. In simulation, the
outcome is simulator-dependent. With CDC analysis, the clock
signal takes precedence.
74

October 2011
Compilation
Table 3-9. Verilog Design Style Restrictions (cont.)

Initial Blocks
Initial blocks are ignored.
Blocking Delay
Statements
Blocking delay statements are compiled without the delays.
bind to VHDL
When a bind statement has a user-defined type, it must be

defined in a VHDL package.
Other Constructs
specify, uselib and resetall statements are ignored.

Selects such as sig[a:b] are only supported if a and b
expressions are constant at elaboration time.
Clashes in variables and instance names should be avoided.

October 2011
75
Compilation
VHDL
Compiler support for IEEE 1076-1993 Standard VHDL Language Reference Manual (LRM)
constructs is shown in Table 3-10. Unless otherwise noted, each construct in the table is
completely supported.
Table 3-10. Supported VHDL Constructs
LRM Section 1
1.1
1.1.1
1.1.1.1
1.1.1.2
1.1.2
1.1.3
1.2
1.2.1
1.2.2
1.3
1.3.1
1.3.2
LRM Section 2
2.1
2.1.1
2.1.1.1
2.1.1.2
2.1.1.3
2.2
2.3
2.3.1
2.3.2
2.4
2.5
2.6
2.7
LRM Section 3
3.1
3.1.1
3.1.1.1
3.1.2
3.1.2.1
3.1.3
3.1.3.1
3.1.4
3.1.4.1
76
Design Entities and Configurations

Entity declarations
Entity header
Generics
Ports
Entity declarative part
Entity statement part
Architecture bodies
Architecture declarative part
Architecture statement part
Configuration declarations
Block configuration
Component configuration
Subprograms and Packages
Subprogram declarations
Formal parameters
Constant and variable parameters
Signal parameters
File parameters
Subprogram bodies
Subprogram overloading
Operator overloading
Signatures
Resolution functions
Package declarations
Package bodies
Conformance rules
Types
Scalar types
Enumeration types
Predefined enumeration types
Integer types
Predefined integer types
Physical types
Predefined physical types
Floating point types
Predefined floating point types
not supported
not supported
not supported
not supported

October 2011
Compilation
Table 3-10. Supported VHDL Constructs (cont.)

3.2
3.2.1
3.2.1.1
3.2.2
3.3
3.3.1
3.3.2
3.4
3.4.1
LRM Section 4
4.1
4.2
4.3
4.3.1
4.3.1.1
4.3.1.2
4.3.1.3
4.3.1.4
4.3.2
4.3.2.1
4.3.2.2
4.3.3
4.3.3.1
4.3.3.2
4.4
4.5
4.6
4.7
LRM Section 5
5.1
5.2
5.2.1
5.2.1.1
5.2.1.2
5.2.2
5.3
LRM Section 6
6.1
6.2
6.3
6.4
6.5
6.6
Composite types
Array types
Index constraints and discrete ranges
Record types
Access types
Incomplete type declarations
Allocation and de-allocation of objects
File types
File operations
Declarations
Type declarations
Subtype declarations
Objects
Object declarations
Constant declarations
Signal declarations
Variable declarations
File declarations
Interface declarations
Interface lists
Association lists
Alias declarations
Object aliases
Non-object aliases
Attribute declarations
Component declarations
Group template declarations
Group declarations
Specifications
Attribute specification
Configuration specification
Binding indication
Entity aspect
Generic map and port map aspects
Default binding indication
Disconnection specification
Names
Names
Simple names
Selected names
Indexed names
Slice names
Attribute name

October 2011
not supported
not supported
not supported
not supported
not supported
not supported
not supported
not supported
not supported
77
Compilation

LRM Section 7
7.1
7.2
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.2.7
7.3
7.3.1
7.3.2
7.3.2.1
7.3.2.2
7.3.3
7.3.4
7.3.5
7.3.6
7.4
7.4.1
7.4.2
7.5
LRM Section 8
8.1
8.2
8.3
8.4
8.4.1
8.5
8.5.1
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
78
Expressions
Expressions
Operators
Logical operators
Relational operators
Shift operators
Adding operators
Sign operators
Multiplying operators
Miscellaneous operators
Operands
Literals
Aggregates
Record aggregates
Array aggregates
Function calls
Qualified expressions
Type conversions
Allocators
Static expressions
Locally static primaries
Globally static primaries
Universal expressions
Sequential Statements
Wait statement
Assertion statement
Report statement
Signal assignment statement
Updating a projected output waveform
Variable assignment statement
Array variable assignments
Procedure call statement
If statement
Case statement
Loop statement
Next statement
Exit statement
Return statement
Null statement
not supported
see Table 3-11 on page 81

parse/ignore
parse/ignore
parse/ignore

October 2011
Compilation

LRM Section 9
9.1
9.2
9.3
9.4
9.5
9.5.1
9.5.2
9.6
9.6.1
9.6.2
9.7
LRM Section 10
10.1
10.2
10.3
10.4
10.5
LRM Section 11
11.1
11.2
11.3
11.4
LRM Section 12
12.1
12.2
12.2.1
12.2.2
12.2.3
12.2.4
12.3
12.3.1
12.3.1.1
12.3.1.2
12.3.1.3
12.3.1.4
12.3.1.5
12.3.1.6
12.3.1.7
Concurrent Statements
Block statement
Process statement
Concurrent procedure call statements
Concurrent assertion statements
Concurrent signal assignment statements
Conditional signal assignments
Selected signal assignments
Component instantiation statements
Instantiation of a component
Instantiation of a design entity
Generate statements
Scope and Visibility
Declarative region
Scope of declarations
Visibility
Use clauses
The context of overload resolution
Design Units and Their Analysis
Design units
Design libraries
Context clauses
Order of analysis
Elaboration and Execution
Elaboration of a design hierarchy
Elaboration of a block header
The generic clause
The generic map aspect
The port clause
The port map aspect
Elaboration of a declarative part
Elaboration of a declaration
Subprogram declarations and bodies
Type declarations
Subtype declarations
Object declarations
Alias declarations
Attribute declarations
Component declarations

October 2011
not supported
79
Compilation

12.3.2
12.3.2.1
12.3.2.2
12.3.2.3
12.4
12.4.1
12.4.2
12.4.3
12.4.4
12.5
12.6
12.6.1
12.6.2
12.6.3
12.6.4
LRM Section 13
13.1
13.2
13.3
13.3.1
13.3.2
13.4
13.4.1
13.4.2
13.5
13.6
13.7
13.8
13.9
13.10
LRM Section 14
14.1
14.2
14.3
Elaboration of a specification
Attribute specifications
Configuration specifications
Disconnection specifications
Elaboration of a statement part
Block statements
Generate statements
Component instantiation statements
Other concurrent statements
Dynamic elaboration
Execution of a model
Drivers
Propagation of signal values
Updating implicit signals
The simulation cycle
Lexical Elements
Character set
Lexical elements, separators, and delimiters
Identifiers
Basic identifiers
Extended identifiers
Abstract literals
Decimal literals
Based literals
Character literals
String literals
Bit string literals
Comments
Reserved words
Allowable replacements of characters
Predefined Language Environment
Predefined attributes
Package STANDARD
Package TEXTIO
not supported
Unqualified constructs in Table 3-10 are completely supported. Other constructs are qualified as
follows:
not supported
Modules/entities containing constructs identified as not supported are inferred black
boxes.
parse/ignore
Constructs identified as parse/ignore are recognized and do not cause parsing errors,
but no assertion logic is generated for the constructs.
80

October 2011
Compilation
Design styles described in Standard for VHDL RTL Synthesis, Section 6.1 Edge Sensitive
Sequential Logic are supported, except as qualified in Table 3-11.
Table 3-11. VHDL Design Style Restrictions
Multiple Clocked Blocks
(unsupported styles)
Multiple active clocked blocks in the same process are not

supported. For example:
multiEnableEdgeProc : process(clk, reset)
begin
if reset = 1 then
Q <= 0;
elsif e1 = 1 and rising_edge(clk) then
Q <= D11;
elsif e2 = 1 and rising_edge(clk) then
Q <= D12;
end if;
end process;
The workaround is to model the same functionality using a

supported clocking style. For example:
begin
if reset = 1 then
Q <= 0;
elsif rising_edge(clk) then
if e1 = 1 then
Q <= D11;
elsif e2 = 1 then
Q <= D12;
end if;
end if;
end process;
Multiple Clocked Blocks

(supported styles)
One block reachable at a time

Multiple clocked blocks are supported if the compiler determines
that only one block is reachable at a time. For example:
-- Generic_value is a generic with some value
-- Only one of the clocked blocks below is
-- reachable in a particular design.
begin
if Generic_value = 1 then
if rising_edge(clk) then
Q <= D11;
end if;
else
if rising_edge(clk) then
Q <= D12;
end if;
end if;
end process;

October 2011
81
Compilation
Table 3-11. VHDL Design Style Restrictions (cont.)

Nested blocks with the same clock/edge
Nested multiple clocked blocks that use the same clock signal and
the same edge (i.e., posedge or negedge) are supported. For
example:
begin
if reset = 1 and rising_edge(clk) then
if reset = 1 then
Q <= 0;
elsif rising_edge(clk) then
Q <= D12;
end if;
end if;
end process;
Clock Expressions in
Procedures
The use of a clock_expression in a procedure is supported only if

the procedure that contains the clock_expression is:
Called directly as a concurrent procedure call (calling the
procedure from another concurrent procedure is not supported).
Not called in a sequential scope (for example as a statement
inside a process statement).
Not a recursive procedure.
wait Statements
Implicit FSMs
Implicit style finite state machines written using multiple wait
statements are not supported. Using a single wait statement with a
valid clocking style (as per the LRM) is supported.
Non-static loops using wait statements
Non-static loops with single-clock wait (usually written as implicit
style state machines using wait statements) are not supported. For
example:
UartTxFunction : Process
begin
TopLoop : loop
wait until rising_edge(clk);
Q <= D;
end loop ;
end process ;
82

October 2011
Compilation

The following non-static loop with complex conditions is not
supported:
UartTxFunction : Process
begin
TopLoop : loop
if (nReset = 0) then
SerialDataOut <= 1 ;
TxRdyReg <= 1 ;
end if ;
wait until nReset = 0 or
(rising_edge(UartTxClk) and DataRdy=1);
next TopLoop when nReset = 0 ;
SerialDataOut <= 0;
TxRdyReg <= 0;
-- Send 8 Data Bits
for i in 0 to 7 loop
rising_edge(UartTxClk);
next TopLoop when nReset = 0;
SerialDataOut <= DataReg(i) ;
TxRdyReg <= 0 ;
end loop ;
rising_edge(UartTxClk) ;
next TopLoop when nReset = 0;
SerialDataOut <= 1 ;
TxRdyReg <= 1 ;
end loop ;
end process ;
Selects
Selects such as sig(a to b) and sig(a downto b) are only supported

if a and b expressions are constant at elaboration time.
Verilog Configuration
Entity/architecture bindings for instances across language

boundaries are not supported. For example: VHDL specifying the
configuration for a Verilog instance or a VHDL design unit
instantiated in the Verilog part of the design.
User-defined Resolution
Functions
User-defined resolution functions (i.e., to resolve final values of

the signals in case of multiple drivers) are ignored. The standard
resolution function applied on the standard data type (std_logic) as
defined in the IEEE package is supported.
Tristate Modeling
Direct Z assignment
Tristate logic modeling through direct Z assignment on process
variables and inside subprograms is not supported. Tri-states
modeled through direct Z assignments in concurrent signal
assignments or in processes on signals are supported.

October 2011
83
Compilation

Guard disconnect
Tristate logic modeling using guard disconnect on std_logic type
signals declared as bus/registers is not supported. For example:
signal dout: Std_Logic bus;-- "bus" yields 3-state;
signal flag: Std_Logic;
tri_state: block (en = 1)
begin
dout <= guarded din;
flag <= en;
end block;
RAM/ROM Modeling
RAM/ROM modeling and inferencing is optimized for the Questa

tools and has better results for the tool usage and characteristics of
the design. The modeling process ignores some attributes provided
in the IEEE rtl_attributes package, including the following:
Ram_block
Rom_block
Logic_block
Certain other pre-defined attributes.
For example, the following attributes are ignored:
variable ram : ram_typ; -- ram element
attribute logic_block of ram : variable is TRUE;
VHDL Library Override
Except for IEEE standard packages, VHDL libraries can be

overridden. Overrides of IEEE standard packages are ignored
because the Questa native IEEE packages are optimized to improve
compiler performance.
CheckerWare Directives
Support for attaching CheckerWare checker directives to VHDL

statements and objects is shown in Table 3-10 on page 76.
84

October 2011
Compilation
Binding to Verilog Design Units

Verilog names are case sensitive. They are stored exactly as specified. By default, vcom
preserves the case of most VHDL names. However, VHDL names are not case sensitive. In
addition, there are the following exceptions:
Design unit names VHDL design units are treated as they are lower case.
VHDL packages compiled with -mixedsvvh VHDL basic identifiers are treated as
they are lower case,
Ambiguity can occur when binding to a Verilog design unit from VHDL. Here is the procedure
used to select a design unit from a library:
1. If a design unit exists in the library that has the same name in all lower case, use that
design unit.
2. Otherwise, find all design units in the library that have the same case-insensitive name.
If only one design unit matches, use that design unit.
If none or multiple design units match, do not use any design unit.
For example, assume VHDL code binds to a Verilog design unit named Test.
work: entity test, module Test
Design unit Test matches entity test (in all lower case). Entity test is used.
work: module TEST
No design unit is named test (in all lower case). So, the library is searched ignoring case,
which finds the single match TEST. Module TEST is used.
work: module Test, module TEST
No design unit is named test (in all lower case). So, the library is searched ignoring case,
which finds the multiple matches: Test and TEST. No design unit is used.

October 2011
85
Compilation
86

October 2011
Chapter 4
CDC Analysis
Clock domain crossing (CDC) analysis checks the design, infers clock trees, identifies signals
that cross clock domain boundaries, and detects a variety of synchronization patterns. The
analysis also suggests CDC checkers for possible inclusion in the design instrumentation.
Figure 4-1. Questa CDC Tools
0in_cdc
CDC GUI
interactive
(shell)
or
Command-line CDC Tools

batch
Shell Commands
Compiler Commands
vlib
vcom
vmap
vlog
0in Shell Tools
CDC Analyzer
cdc
Command Help
cwhelp

October 2011
87
CDC Analysis
CDC Analysis Tools
CDC Analysis Tools

As shown in Figure 4-2, the static Questa CDC flow starts with a compiled design library. As
described in the previous chapter, you can use the 2-step compilation method (vlog/vcom
commands). Or, under certain restrictions, you can use the 1-step compilation method where
you pass the design compilation arguments to cdc and (hidden to the user) cdc uses the design
compilation tools to compile the design before it compiles the clock domain model and analyzes
the CDC data.
Figure 4-2. Static Questa CDC Tool Flow
2-step compilation
design
files
Questa Compilers
and Library
Management Tools
1-step
compilation
control
files
design libraries
0in -cmd cdc
formal model
Compile clock domain

model
0in_cdc.db
0in_cdc
GUI
CDC Debug
CDC Checks Viewer
Schematic Browser
Source Code Editor
Analyze CDC results
So, after compiling the design data, the static Questa CDC tool flow consists of running two
tools in sequence:
1. cdc compiles the clock domain model and analyzes CDC data.
2. 0in_cdc displays a suite of GUI tools used to manage and debug the results of CDC
analysis.
0in_cdc: GUI Debug Mode

The 0in_cdc debug tool provides a GUI environment for viewing CDC analysis results,
debugging CDC violations and examining CDC check issues. The tool takes a .db file generated
by cdc and shows CDC analysis results in various windows and GUI tools (Figure 4-3 and
Table 4-1):
prompt> 0in_cdc 0in_cdc.db
88

October 2011
CDC Analysis
CDC Analysis Tools
Figure 4-3. CDC GUI

Menus
Toolbar
Debugging Windows
Design Data
Windows
Analysis
Windows
Table 4-1. CDC GUI Debug Tools

CDC Checks Window
Shows the results of CDC compilation and analysis. Each CDC scheme
instance has a status flag that indicates the status for the CDC instance (see
Status Flags on page 53). 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.

October 2011
89
CDC Analysis
CDC Analysis Tools
Table 4-1. 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 objects declaration, an objects 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.
90

October 2011
CDC Analysis
CDC Analysis Tools
Table 4-1. 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.
0in_cdc: GUI Project Mode

With the standard CDC verification flow, you compile the design and CDC logicall as a batch
process. Then, you load the results into the 0in_cdc GUI to debug CDC violations and explore
the results of CDC analysis. When run this way, 0in_cdc provides a GUI debug environment.
An alternate way of running CDC verification is to do all of these steps from within the 0in_cdc
environment as an interactive GUI session. To do this, run 0in_cdc in project mode (Table 4-2).
Table 4-2. 0in_cdc Project Mode Syntax
0in_cdc
[[p project_name ] [hdl_file] [d design] [f verilog_filelist]
[vhf vhdl_filelist] [ctrl verilog_control_file] [vhctrl vhdl_control_file]
[import_ctrl control_file] [v95] [libmapfile library_map_file] [y lib_dir]
[v lib_file] [qy lib_skip_dir] [qv lib_skip_file] [work library]
[od output_dir] [no_directive_error_check] [+libext{+ext}]
[+incdir{+dir}] [+define{+macro[=val]}] [dw] [sdc_in sdc_file]
[sdc_out file] [formal] [cdcid id] [verbose]
| project_file ]

October 2011
91
CDC Analysis
Static CDC Verification Flow
To start, simply specify no arguments:

prompt> 0in_cdc
Since no .db file is specified, the GUI is displayed in project mode (as opposed to GUI debug
mode). Here, you have the same functionality as GUI debug mode, plus additional tools you use
to interactively run design compilation, CDC compilation and other project management
functions. Any time you wish to quit, you can save the project and exit. To continue where you
left off, run 0in_cdc with the project loaded:
prompt> 0in_cdc my_project
When starting a project from scratch, you display and fill out dialogs to set up the details of the
project. However once this is done, running, saving and restarting projects is a simple process.
To get started with a project, you can include many of the design compilation and CDC
compilation arguments as shown in Table 4-2. The information from these arguments is used to
pre-populate various dialogs in the GUI with appropriate valueswhich can save you time
setting up a project. In some cases, if the command-line arguments are complete, you can
specify -run. The 0in_cdc command uses the specified pre-populated arguments to set up the
project, runs a formal verification flow (design compile, CDC compile), and then displays the
project with the CDC analysis results.

Static CDC verification identifies the CDC signal paths and their associated CDC schemes.
Schemes are ranked by severity, which can be the default severity of the scheme or a userspecified severity. 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 for a session. This step identifies
schemes with CDC protocols that can be proven to be logically valid (and therefore do not
require the promotion of their CDC protocol checkers).
Static CDC verification of a DUT is a multi-phased process:
1. Compile the design.
2. Analyze clock domains.
3. Compile the CDC logic.
4. Run GUI debug.
The following sections describe this flow.
92

October 2011
CDC Analysis
Phase 1. Compiling the Design

If you use the 1-step method for design compilation, skip this section (got to Phase 2:
Analyzing Clock Domains on page 93). Otherwise use the compilation utilities to set up,
compile and maintain the design libraries (as detailed in 2-Step Compilation on page 57):
1. Start from a working directory for the project.
For example:
prompt> cd /u/design/zin
2. Create a working library.

prompt> vlib work
3. Name the working library.

Copying /u/0in_3.0/modeltech/linux/../modelsim.ini to modelsim.ini
Modifying modelsim.ini
Note that a copy of the system modelsim.ini file (page 58) 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: Analyzing Clock Domains

Once the design is compiled, you should identify (and verify) the clock domains before running
a full cdc session to compile and analyze the CDC logic. You do this by creating a control file of
global directives that configure CDC analysis and identify the various clocks and clock
domains. Then, you run cdc in a special operational mode called report clocks, which scans the
design data and reports clock domain information.

October 2011
93
CDC Analysis
1. Set up global directives.

Create one or more control files containing global directives used to configure the CDC
analysis (see Global Directives on page 254). Following are some examples:
Identify clocks characteristics (including which clocks belong to the same clock
groups). See set_cdc_clock on page 265.
Override the default clock groups assigned to DUT or instance ports. See
set_cdc_port_domain on page 279.
Identify modules/architectures that should be treated as black boxes for CDC

analysis. See set_black_box on page 264.
Identify signals that should be considered constant for CDC analysis. See
set_constant on page 307.
Identify large memories that are modeled as single sequential elements for CDC
analysis. See set_memory on page 310.
Set the preferences for static CDC analysis. See set_cdc_preference on page 286.
Set severities and promotion properties for CDC scheme types and groups of
schemes. See set_cdc_report on page 296.
Override the classification of various signals and assign them certain CDC
properties. See set_cdc_signal on page 301.
Example control file for CDC analysis:

module
// 0in
// 0in
/* 0in
ctrl;
set_cdc_reconvergence -depth 10 -divergence_depth 1
set_cdc_preference -promote_reconvergence
set_cdc_report -scheme series_redundant -severity off
-from *_en -tx_clock tx_clk */
// 0in set_cdc_clock cpu_clk -period 50
// 0in set_cdc_clock core_clk -period 20
// 0in set_cdc_clock mac_clk -period 12
endmodule
2. Run report clocks.

Run cdc with the -report_clock option. For example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v -report_clock
If you use the 1-step method of compiling the design, add the 1-step compilation
arguments to the cdc command (as detailed in 1-Step Compilation on page 56). For
example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v -report_clock \
-f design.f +define+mode=initialized -y ../mylib
94

October 2011
CDC Analysis
3. Check for errors and warnings.

Check the log file (0in_detail.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-136 Clock not found in directive.
1 Warning hdl-222 Possible dead end CDC paths not reported.
3 Warning hdl-41
Primary port connects to multiple clock domains.
25 Warning hdl-51
Port domain assignment inferred.
Summary: 30 Warnings in cdc
The detailed error/warning messages are in the body of the log.

prompt> egrep Error|Warning 0in_detail.log
Warning : Possible dead end CDC paths not reported. [hdl-222]
Warning : Clock not found in directive. Directive set_cdc_report,
Module demo_top, Clock tx_clk, File cdc_control.v,
Line 5. [hdl-136]
Warning : Port domain assignment inferred. Port mac_clk_in, File
top.v, Line 31. [hdl-51]
Warning : Port domain assignment inferred. Port core_clk_in, File
. . .
Warning : Port domain assignment inferred. Port rx_check, File
Warning : Primary port connects to multiple clock domains. Pin
rst. [hdl-41]
scan_mode. [hdl-41]
scan_clk. [hdl-41]
4. Check clock domain data.

Check 0in_cdc_design.rpt (see CDC Design Report on page 454). 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). To improve
performance, review and refine the clock trees to achieve the correct grouping. The
following clock data should be accurate after this phase of CDC analysis:
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.

October 2011
95
CDC Analysis
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
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.
Phase 3: Compiling CDC Logic

Once the design is compiled and the clock domains are verified, use the cdc command to
compile the CDC logic. This command also performs CDC analysis and generates the database
(.db) file read by the 0in_cdc GUI debug tool. If you modify the source or control files, or adjust
the CDC compilation options, you must re-run CDC compilation.
1. Run the CDC analyzer.
Run cdc. For example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v options
If you use the 1-step method of compiling the design, add the 1-step compilation
arguments to the cdc command (as detailed in 1-Step Compilation on page 56). For
example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v options\
-f design.f +define+mode=initialized -y ../mylib

Check the log file (0in_detail.log) for errors and warnings. The Error/Warning
Summary table gives the violation count of each type of error/warning.
Phase 4: Running GUI Debug

The cdc command generates a 0in database file (0in_cdc.db) for input to the CDC GUI.
1. Run the CDC GUI in debug mode.
Specify 0in_cdc.db as the only argument to 0in_cdc:
The CDC GUI main window is displayed.
96

October 2011
CDC Analysis
2. Check static CDC analysis results.

Results are shown in the CDC Checks window. Each entry represents a CDC path
(scheme instance) detected by CDC static analysis. The Type field has a CDC status flag
(see page 53) representing the status of the scheme. To help organize the data, the
schemes are grouped by basic type (Violation, Caution, Evaluation, Proven, etc.) and
within each of these groups, the schemes are grouped by scheme type (Two DFF
Synchronizer, Combo Logic, etc.).
For an initial static CDC session, the basic types are:
Violation The path 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).

October 2011
97
CDC Analysis
Caution The path 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 scheme).
Evaluation The path is an instance of a valid scheme for the CDC signal.
Proven The path is an instance of a valid scheme for the CDC signal and
the CDC interface protocol cannot be violated.
Typically static CDC verification results show proven schemes even when the CDC
formal engine is not enabled. For these schemes, the clock ratio of 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
scheme and run Show >Schematic) and view the source code for the violation (run
Show >Source). You must rerun static CDC verification if you change the HDL source.
4. Adjust static CDC analysis attributes as needed.

You typically need to adjust the CDC attributes. For example, to change the severity of a
scheme, select the scheme and run Create Directive. The Set Cdc Report dialog shows
the current data for the scheme. Below, the severity is changed to Waived. You might
want to waive a scheme because it is known to be valid, it is not interesting at this point,
or it will be fixed by a future enhancement.
98

October 2011
CDC Analysis
Sometimes a path is identified with an incorrect synchronizer scheme. For example, a

gray-coded bus is marked as a violation, but has a valid synchronizer, or a missing
synchronizer is reported, but the clock domain crossing is known to be stable, so no
synchronizer is needed. To fix this, set the signal properties of the signal. In a schematic
or the objects pane, select the signal and run Edit Directive >Set Signal. Adjust the
signal attributes in the Set Cdc Signal dialog.

October 2011
99
CDC Analysis
Check the modifications in the directives tab.
Save the current directives as a control file.

File >Export >Directive File.
5. Filter the reporting of static CDC results as needed.
In the previous step, you adjusted how the CDC compiler analyzed specific CDC
schemes. Filtering is the process of selecting CDC crossings not to display in the results
pane. Filtered crossings are still analyzed by the CDC compilerbut they are not
displayed in the CDC Checks window.
To control the filtering process, 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. Click on OK to accept the
current filtering. This removes the crossings from the results pane. 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.
100

October 2011
CDC Analysis
You can save the current filtering settings using the Filter >Export popup command and
restore filtering settings from a saved file using the Filter >Import popup command. This
way, you can organize different groups of CDC issues to help you 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.
Save the current filtering directives as a control file.
Filter >Export Directive File.
The global directives in this filters file have the form:
//0in set_cdc_report -scheme scheme ... -severity off
The -severity off option marks the crossing as a filtered CDC instance.
6. Exit the CDC GUI.
File >Quit
7. Re-run CDC compilation/analysis.
Re-run cdc with the two new control files. The ctrl_waived.v file is the control file saved
in step 4. The ctrl_filtered.v file is the control file saved in step 5.
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v options
-ctrl ctrl_waived.v -ctrl ctrl_filtered.v -formal
The above invocation includes the -formal option, which turns on low-level formal
analysis of the promoted CDC protocol assertions.
8. Check static CDC analysis results.

October 2011
101
CDC Analysis
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 schemes 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
control 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.
// ctrl_high_performance.v
//
// High-performance CDC profile
module ctrl_high_performance;
// Turn off reconvergence checking.
// 0in set_cdc_reconvergence -check off
// Turn off exact memory modeling for large memories.
// 0in set_memory -abstract mem1 mem2
// Disable generation of CDC protocol assertions
// 0in set_cdc_report -default_promotion off
//
//
//
/*
Define custom synchronizer modules and identify the clock

domains of the custom synchronizer module pins.
0in set_cdc_synchronizer custom -module cust_2sync
0in set_cdc_port_domain in1 out2 -clock clk1
-module cust_2sync */
/* 0in set_cdc_port_domain in2 out1 -clock clk2
-module cust_2sync */
// Black box modules that are not required for CDC analysis
// 0in set_black_box modX
endmodule // ctrl_high_performance
For extremely large designs, use a hierarchical CDC verification flow (see Hierarchical
CDC Analysis on page 117).
102

October 2011
CDC Analysis
The following example control file creates a profile that provides a higher level of detail
in the checking and reporting of CDC data.
// ctrl_high_accuracy.v
//
// High-accuracy CDC profile
module ctrl_high_accuracy;
// Enable divergence checking and set reconvergence checking to
// a greater depth (default is 0). Start with a depth of 1.
// 0in set_cdc_reconvergence -divergence_depth 1 -depth 1
// Enable reconvergence reporting for paths thru
// DMUX synchronizers.
// 0in set_cdc_preference -dmux_as_recon_start
// Enable FIFO and handshake scheme checking:
// 0in set_cdc_preference -fifo_scheme -handshake_scheme
// Report disabled CDC paths.
// 0in set_cdc_preference -filtered_report
// Enable constant propagation through registers with
// non-constant enables
// 0in set_constant_propagation -enable
endmodule // ctrl_high_accuracy
Also, consider the following:
Define all clock periods using set_cdc_clock and turn on formal CDC analysis with
the cdc command-line switch -formal. Start with the default -formal_effort (low).
Turn on reporting of patch to dead-end nodes using the cdc command-line switch
-process_dead_end.
Use modal analysis to check all modes of clocking (see Modal CDC Analysis on
page 133).

October 2011
103
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 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 4-3). To test and verify the protocols for
these schemes, static CDC analysis promotes protocol checkers for CDC protocol analysis.
The promoted checkers are written to the 0in_cdc_control.v control file by default during static
CDC analysis.
The CDC checkers are modules that ensure that data crossing clock domain boundaries are
transmitted and received correctly. The CDC checkers are implemented the same as other
CheckerWare checkers. They monitor the design during assertions in simulation. Their checks
can be targets for formal verification. They are instantiated directly by using checker directives.
Checker Type
cdc_sync
cdc_sample
cdc_dsel
cdc_handshake_data
104
Table 4-3. CDC Protocol Checkers

Protocol
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.
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.
Ensures that a signal between two clock domains, where the
transmitters 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.
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.

October 2011
CDC Analysis
Table 4-3. CDC Protocol Checkers

Checker Type
Protocol
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.
Using the generated promoted CDC checker control file, you analyze the CDC transfer
protocols in either or both of the following ways:
Run formal verification with the promoted CDC protocol checkers.
Run simulation with the promoted CDC protocol checkers.
Checkers for the protocols verified by the formal CDC engine are not promoted, so formal
analysis and simulation do not waste cycles analyzing pre-verified protocols. Standard Questa
CDC checkers can be manually added for cases where the schemes protocols match the
protocols verified by the checkers. Custom assertions checkers can be created for other
situations. Simulation and formal results for these checkers are not imported back into the CDC
GUI, so problems must be debugged in those environments. CDC-FX metastability analysis
also uncovers issues with protocols with inconclusive results.
Questa Formal Verification

This step is optional and requires significant setup for formal analysis (such as adding an
initialization sequence and formal check assumptions).
Prove formal verification analyzes the promoted CDC protocol checkers and identifies those
protocols that it proves cannot be violated. The results of the formal analysis are then merged
with the results of static CDC verification to show the progress of analyzing the CDC protocols.
1. Check the control file of promoted CDC protocol checkers.
Examine 0in_cdc_ctrl.v in the directory containing the results of static CDC analysis.
Check the contents of the control file. If you make adjustments, save the file to a
different name to prevent the changes from being overwritten the next time you run
static CDC analysis.
2. Run formal verification.
Set up a run script for formal verification with the promoted control file. For example,
the following Makefile entry runs the csl formal model compiler and then 0in_prove.

October 2011
105
CDC Analysis
run_prove:
0in -od prove -cmd csl -f $(EX_HOME)/source/filelist \
-d demo_top -ctrl $(EX_HOME)/bin/csl_control.v \
-ctrl $(EX_HOME)/static/0in_cdc_ctrl.v
0in_prove +0in_od+prove +0in_dir+prove/0in_cache \
+0in_init+$(EX_HOME)/bin/init.txt +0in_effort+med
prompt> make run_prove
Check the Prove logs and reports for errors.

3. Run the CDC GUI in debug mode.
Load the database from static CDC verification (0in_cdc.db) and merge the database
from formal analysis (0in_prove.db).
prompt> 0in_cdc 0in_cdc.db -mergedb 0in_prove.db
4. Check results of Prove formal analysis of the CDC protocols.

Two new columns of status flags are added. The Static field shows the status of the
schemes from static CDC analysis. The Prove field shows the results of Prove formal
verification. The Type field shows the merged statuses for the schemes.
The Prove field has three types of status flags:
106
Proven The schemes protocol checker was promoted and Prove formal
verification proved the schemes CDC interface protocol cannot be violated.
Inconclusive The schemes protocol checker was promoted and Prove

formal verification failed to prove the schemes CDC interface protocol cannot be
violated. Sometimes increasing the formal effort level can reduce the number of
inconclusive results.
Not Promoted No protocol checker was promoted for the scheme.

Checkers are not promoted for proven schemes, some scheme types that do not
support checker promotion and schemes that have promotion manually disabled.

October 2011
CDC Analysis
Simulation with CDC Protocol Assertions

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 4-4.
Figure 4-4. Simulation with CDC Assertions
vcom/vlog
design
files
cdc
-compile_assertions
control
files
-work library
vsim
-f 0in_cdc_sim.arg
-f 0in_cdc_sim_vhdl.arg
merge
0in_checksim.db
vcom/vlog
0in_cdc
0in_cdc.db
GUI
vcom/vlog
testbench
files
debugging
environment
Results from these simulations with CDC protocol assertions 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
2. Run CDC analysis.

Specify the -compile_assertions option and the prefix showing the hierarchy path from
the top level testbench to the DUT analyzed by cdc. For example:
prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v \
-compile_assertions -prefix tb.dut_inst
3. Compile the protocol assertions.

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

October 2011
107
CDC Analysis
prompt> vlog -f 0in_cdc_sim.arg
prompt> vcom -f 0in_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 $HOME_0IN/lib/lib0InLoadMTIPLI.so \
-f 0in_cdc_sim.arg.vsim -f 0in_cdc_sim.arg.vsimrun \
-do "add log -r /*; run 1000; quit -f"
6. Run the CDC GUI.

Load the 0in_cdc.db database generated by cdc and merge the 0in_checksim.db database
generated by vsim.
prompt> 0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
7. Check results of simulation with the CDC protocol assertions.
One new column of status flags is added. The Simulation field shows the status of the
schemes from simulation. The Type field shows the merged statuses for the schemes.
The Simulation field has five types of status flags:
108
Firing Simulation violated the schemes 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 schemes protocol assertion.

October 2011
CDC Analysis
Evaluated Simulation activated the schemes protocol assertion. The

Evaluations field shows the number of cycles the protocol assertion activated.
Covered Simulation covered all of the schemes protocol assertions

cover points.
Not Promoted No protocol checker was promoted for the scheme.

Checkers are not promoted for proven schemes, some scheme types that do not
support checker promotion and schemes that have promotion manually disabled.
Schemes with violation severity are promoted. Similarly, protocol assertions that are
activated in simulation (Evaluated) might not be covered in simulation. So, two
additional status flags are possible in the merged status (Type field):
Violation and Firing Scheme is a violation and the schemes protocol

was violated during simulation.
Not Covered Simulation activated the schemes protocol assertion, but

simulation did not exercise all the assertions cover points.
8. Debug protocol assertion firings.

Select the scheme and run Show >Simulation Firings. From the Firings dialog, select the
desired firing. In the Load Waveform Database dialog, find the generated waveform file.

October 2011
109
CDC Analysis
Use the waveform view, the schematic view and the source code editor to track down
and fix the source of the firings.
9. Check CDC assertions that are not covered.

Check results that are Not Covered. Select a crossing and run the Show >Protocol
Checker popup command. The Checksim window is displayed with the entry for the
selected protocol checker highlighted.
Typically, you modify simulation or run CDC protocol checking with additional tests to
ensure complete coverage of the relevant CDC protocol assertions.
110

October 2011
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
passindicating a high level of confidence that the designs 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 set up global directives for setting metastability windows.
The following control module shows a control file that sets the FX timescale and
metastability windows (see Metastability Windows on page 160) for wr_clk-to-rd_clk
crossings and rd_clk-to-wr_clk crossings.
prompt> more fx_ctrl.v
module fx_ctrl;
// 0in set_cdc_fx_timescale 1ps/1ps

October 2011
111
CDC Analysis
/* 0in set_cdc_fx_metastability_window
-start 5000 -stop 1000 -rx_clock wr_clk -tx_clock rd_clk */
-start 6000 -stop 1000 -rx_clock rd_clk -tx_clock wr_clk */
endmodule
2. Compile and analyze the design.

The same setup used for simulation with CDC protocol assertions can be adapted for
CDC-FX simulationwith two modifications to the cdc invocation:
Add the -fx argument, which generates the CDC-FX metastability injection logic.
Add the control file containing the CDC-FX directives.
For example:
prompt> vlib work
prompt> vcom dut.v
prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v fx -ctrl fx_ctrl.v\
prompt> vlog tb.v
3. Run simulation.
For example:
Debug issues in the simulator debug environment as with standard simulations.

4. Check CDCFX checkers that are not covered.
Load the results of simulation with CDC-FX checkers into the CDC GUI:
Check results that are Not Covered in the Checksim window.
112

October 2011
CDC Analysis
Select a crossing and run Show >Coverage.
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.
Simulation Arguments
Table 4-4 shows additional arguments you can include in your simulator invocation when you
run simulation with CDC protocol checkers and CDC-FX checkers.
Table 4-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
+time
Number of time units to continue simulation with assertions

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.

October 2011
113
CDC Analysis
Table 4-4. Simulator Arguments

+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
+keyword
Adds keyword to each firing message, so each firing message

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.
+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_
limit+limit
Number of firings per signature reported to the simulation log

and STDOUT. Default: 1.
+0in_no_simulation_
messages
Turns off reporting checker firing messages to the simulation log

and STDOUT.
version
Reports the software release version and copyright information

and exits.
+0in_suppress_fx_name
{+name}
Suppresses CDC-FX metastability injection for the specified

registers.
+0in_disable_fx_force
Suppresses CDC-FX metastability injection for all registers.
+0in_random_seed+n
Sets the seed for random metastability injection.
Compiling with ccl for Simulation

The -compile_assertions option configures the setup for simulation with CDC and CDC-FX
checkers. For some situations, you need to run the ccl compiler instead to do this. Table 4-5
shows syntax for this 0in shell command.
Table 4-5. ccl Syntax
ccl
[fastsim [turbo]] [fastmod [module]] [race_avoid] [incr] [incremental_firing_db]
[ac_stats] [cuname comp_unit] [psl] [pslfile_vl verilog_vunit_file]
[pslfile_vh vhdl_vunit_file][ovl] [ovl_cover] [sim {questa | mti | vcs | nc | nc3}]
[full] [rel_paths] [prove_checkers] [use_synthesis_case_directives] [rcd]
[rcd_file file] [rcd_level level] [sif simulation_arg_file] [unique_names]
[exit_on_directive_errors] [verilog_options] [vhdl_options] [rtl_options]
[reporting_options] [compile_options]
114

October 2011
CDC Analysis

fastsim [turbo]
Creates checker logic without structural coverage logic, so

simulation with assertions runs in high performance mode. The
turbo option optimizes the checker logic further to increase
simulation performance. Default: checker logic includes
structural coverage logic, which decreases simulation
performance.
fastmod [module]
Creates checker logic with checkers moved up to the specified

module, connected with collapsed nets. The top module is used if
module is unspecified. This option can further increase
simulation performance. Default: checkers are instantiated in
their defining modules.
race_avoid
Avoids race conditions during simulation. However, using this

option can slow down simulation.
incr
Generates checker logic files incrementally, which can improve

compile time by preventing recompilation of unchanged checker
files. Default: generates all checker files
incremental_firing_db
Directs simulation with assertions to create a smaller .db

database with static data saved in 0in_cache. Default: simulation
with assertions creates a full .db database with static and
dynamic data.
ac_stats
Generates an assertion complexity report in 0in.log and

0in_detail.log.
cuname comp_unit
Root scope compilation unit name.
psl
Creates psl checkers from embedded PSL code.
pslfile_vl
verilog_vunit_file
Compiles PSL assertions (for Verilog modules) specified in

vunits in verilog_vunit_file.
pslfile_vh vhdl_vunit_file
Compiles PSL assertions (for VHDL entities) specified in vunits

in vhdl_vunit_file.
ovl
Compiles the Questa CDC/Formal version of the OVL

assertions.
ovl_cover
Compiles the Questa CDC/Formal version of the OVL assertions

with coverage.
sim
Default simulator: Questa, MTI, VCS, NC-Verilog, or 3-step
{questa | mti | vcs | nc | nc3} NC-Verilog. Default: MTI. The default MTI version is the same
as the vsim executable in the current search path.
full
Ignores previously cached files. Default: use cached files.
rel_paths
Uses relative pathnames in generated argument files. Default:

same as 0in shell.

October 2011
115
CDC Analysis

prove_checkers
Tries to prove checkers unfireable and then excludes unfireable

checkers from simulation to improve simulation performance.
use_synthesis_case_
directives
Creates case checkers for synthesis case directives embedded in

the source code. Same as specifying the
use_synthesis_case_directives global directive with no options.
rcd
Turns on generation of a checker density report and MSD report

(0in_density_msd.rpt). Default: off. Unless specified by
rcd_file, the checker density report name is 0in_density.rpt.
rcd_file file
Turns on generation of a checker density report and renames the

generated checker density report. Default: 0in_density.rpt (if rcd
specified) otherwise, no report is created.
rcd_level level
Number of hierarchical levels below the target design instance

that are included in the report. A value of 0 specifies all levels.
Default: 4 levels.
sif simulation_arg_file
Name of the root of the generated simulation arguments files.

Default: root file name is 0in_sim.arg.
unique_names
Checks directives for unique names. Only user provided names

specified using the unique_names option are checked.
exit_on_directive_errors
Exits if any checker directive errors are found (after all checkers
have been generated).
verilog_options
[f filelist] [v95] [+incdir{+include_dir}]

[y library_dir][ v library_file] [+libext{+extension}]
[+define{+macro[=value}] [oy search_path]
vhdl_options
[work work_library] [93 | 87 | 2002]

[libmap name=value] [libmapfile file]
[read_questa_mapping] [read_cds_mapping]
rtl_options
[+skip_modules {+module}]
[+skip_syscalls {+systemcall}]
[skip_protected_modules] [skip_protected_code]
[ignore_translate_off]
reporting_options
[wd working_directory][+nowarn{+messageID}]
[+error{+messageID}
compile_options
[file] [d design] [prefix hierarchy_prefix]

[ctrl control_file] [ctrl_list control_file []]
[vhctrl vhdl_control_file] [G name=value]
[g name=value] [cr report_file]
116

October 2011
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 toplevel design to resolve inter-block and top-level issues (Figure 4-5).
Figure 4-5. Bottom-up Hierarchical CDC Flow
intra-block violation
BLOCK
1. Analyze selected blocks

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

model of a block
Note
Hierarchical CDC analysis is static analysis only and does not support promotion of
protocol checks 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 source files.
October 2011
117
CDC Analysis
2. Set up a top-level control file.
Identify the design clocks (set_cdc_clock).
Identify the clock domains of the primary ports (set_cdc_port_domain).
Identify sources of stable signals (set_constant and set_cdc_signal -stable) so CDC

analysis can optimize design logic.
Identify custom synchronizers (set_cdc_synchronizer) and black box

modules/entities (set_black_box).
Set up any other CDC preferences.
3. Run cdc with the -report_clock option.

For example:
0in> cdc -d top -report_clock -ctrl top_ctrl.v

Check the CDC logs; fix errors; and resolve warnings. If you change the source code, go
to step 1.
5. Check 0in_cdc_design.rpt.
Ensure the clock groups and port domains are identified correctly. If not, go to step 2
and fix.
Bottom-up Hierarchical CDC Flow

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

b) Create hierarchical constraints for the blocks.
hierarchical constraints
Phase 2
Analyze Blocks
cdc . . . -hier_block blk1 -ctrl hier_constraints_blk1_ctrl.v

cdc . . .-hier_block blk2 -ctrl hier_constraints_blk2_ctrl.v
cdc . . .-hier_block blk3 -ctrl hier_constraints_blk3_ctrl.v
block CDC interface models (ILMs)
Phase 3
Analyze Top-level Design
118
cdc . . . -hier_cache \
0in_hier/blk1/0in_cache \

October 2011
CDC Analysis
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 121.
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
(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 121 describes two methods for creating the blocks
hierarchical constraints.
A blocks CDC constraints are specified as a set of global directives in a Verilog hierarchical
constraints module associated with the block, saved as a CDC control file for the block.
Example 4-1 shows a hierarchical constraints module for a sample block.
Example 4-1. Hierarchical Constraints Control File
module zin_cdc_hier_constraints_ctrl_blk2;
//
//
//
//
//
Block: blk2
Instances: b2
Parameters/Generics: W = 16
Global CDC Preferences
0in set_cdc_preference -promote_reconvergence

October 2011
119
CDC Analysis
//
//
//
//
//
0in
0in
0in
0in
-formal_add_bus_stability -formal_add_recon_stability
set_cdc_fifo_preference -no_read_sync
set_cdc_handshake_preference -check_mux_recirculation
set_constant_propagation -enable
set_cdc_reconvergence -depth 4 -divergence_depth 3
//
//
//
//
//
//
0in
0in
0in
0in
0in
0in
set_cdc_clock clk -module blk2

set_cdc_port_domain rst -none -module blk2
set_cdc_port_domain data_in1 -clock clk -module blk2
set_cdc_clock top.clk1 -virtual -module blk2
set_cdc_port_domain data_in -clock top.clk1 -module blk2
set_cdc_port_domain data_out -clock top.clk2 -module blk2
endmodule
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:
0in> cdc -d top -od 0in_hier/blk2 \
-ctrl 0in_cdc_hier_constraints_blk2_ctrl.v -hier_block blk2
To segregate the block-level analysis from that of the other blocks and from the toplevel analysis, the output is directed to a subdirectory of the 0in_hier directory (-od
0in_hier/blk2). The block constraints file (0in_cdc_hier_constraints_blk2_ctrl.v) 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.
shell prompt> 0in_cdc 0in_hier/blk2/0in_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 blocksto ensure the
results are accurate and completebefore you analyze the top-level design.
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 CDC/Formal tools for the complete hierarchical CDC flow.
120

October 2011
CDC Analysis
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:
0in> cdc -d top -od 0in_hier/top -ctrl top_ctrl.v \
-hier_cache 0in_hier/blk1/0in_cache \
0in_hier/blk3/0in_cache
The -hier_cache option lists cache directories for the hierarchical blocks. The
0in_hier/blk1, 0in_hier/blk2 and 0in_hier/blk3 directories were specified as the output
directories (-od dir) during the block-level sessions. The name specified for the cache is
0in_cache by default. However, if you change the 0in cache directory name (i.e., using
the -cache option to the 0in shell), the corresponding -hier_cache pathnames must
match.
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.
2. Run the CDC GUI and verify the CDC analysis results.
shell prompt> 0in_cdc 0in_hier/top/0in_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.
With bottom-up constraints, you manually create the constraints for the individual
blocks. Later, CDC analysis of the top level performs consistency checks that verify the
constraints specified at the top level do not conflict with the constraints propagated up
from the lower levels.
With top-down constraints, you first run a special CDC session on the top level, 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.

October 2011
121
CDC Analysis
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 blocks CDC constraints as a set of global directives in a Verilog hierarchical
constraints module, saved as a CDC control file for the block. To create bottom-up constraints:
1. Manually create a hierarchical CDC constraint file for each block.
Use global directives to specify: clocks, clock groups, constants, port domains and
stable ports.
2. Run hierarchical CDC analysis of the blocks and their constraints.
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:
122
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.

October 2011
CDC Analysis
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 -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:
0in> cdc -d top -ctrl top_ctrl.v -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.
2. Check results.
a. Fix errors and resolve warnings.
b. Check 0in_cdc_design.rpt and ensure the clock groups and port domains are
identified correctly.
c. Check the 0in_cdc_hier_constraints_*_ctrl.v files (if desired). For each block,
check the design unit name, instance name, parameter/generic values and the global
directives.
Each hierarchical constraints module for a block has two parts:
Global CDC preferences

Design-level global directives can apply to the various blocks as well as the design
as a whole. For example, set_cdc_preference, set_cdc_fifo_preference,
set_cdc_handshake_preference, set_constant_propagation and
set_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 blocks instances determines the block instances
clocks and clock domains of the blocks ports. These constraints are specified with

October 2011
123
CDC Analysis
set_cdc_clock and set_cdc_port_domain directives. Also, set_constant and

set_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.
Hierarchical CDC Scripts

In addition to generating the block CDC constraints, the -report_constraints option of cdc
creates two scripts (0in_hier.scr and 0in_hier.Makefile) useful for hierarchical CDC analysis
(Figure 4-7). These scripts run the basic hierarchical CDC flow based on the information
supplied when running cdc in the CDC constraints generation mode. They can be used as is or
can be modified to handle advanced flows. The -report_hier_scripts option generates these
scripts without performing constraints generation.
Figure 4-7. -report_constraints Generates Hierarchical CDC Scripts
Phase 1
Generate Block Constraints
0in_cdc_hier_blk1_ctrl.v
cdc -report_constraints blk1 blk2 blk3 . . .
0in_hier.scr
0in_hier.Makefile
Phase 2
Analyze Blocks
124

October 2011
CDC Analysis
The scripts are generated so that the output directory specified by the -od 0in shell option
(default: current run directory) for the cdc session is specified as the output directory for the
files generated by the scripts.
0in_hier.scr
The 0in_hier.scr script (see Example 4-2) is a csh script that runs the block-level analyses in
sequence and then runs the top-level analysis:
shell prompt> 0in_hier.scr
output from block-level sessions
output from the top-level session
Example 4-2. 0in_hier.scr

#!/bin/csh -f
##----------------------------------------------------------------## Hierarchical CDC Script
##----------------------------------------------------------------\rm -fr 0in_hier
mkdir 0in_hier
set cdc_od = 0in_hier
set cdc_hier_cmd = cdc -d top dut.v
set cdc_top_cmd = cdc -d top -ctrl top_ctrl.v dut.v
set ZIN = 0in
# Invoke CDC for all the blocks.
set fail = 0
set fail_mode =
# BLOCK LEVEL RUN: blk1
$ZIN -od $cdc_od/blk1 -cache 0in_cache -cmd $cdc_hier_cmd -hier \
-ctrl /design/dut/0in_cdc_hier_constraints_blk1_ctrl.v \
-hier_block blk1
# Check for failure
if ($status != 0) then
if ($fail == 0) then
set fail = 1
set fail_mode = blk1:blk1
else
set fail_mode = ($fail_mode blk1:blk1)
endif
endif
. . .
# TOP-LEVEL RUN: top
$ZIN -od ${cdc_od}/top -cmd $cdc_top_cmd \
-hier_cache $cdc_od/sub1/0in_cache \
$cdc_od/sub2/0in_cache
# Check for failure

October 2011
125
CDC Analysis
set fail = 1
set fail_mode = top
else
set fail_mode = ($fail_mode top)
endif
endif
# Summary
echo PASSED
exit 0
else
echo FAILED : $fail_mode
exit -1
endif
0in_hier.Makefile
The 0in_hier.Makefile script (see Example 4-3) is a Makefile that runs the block-level analyses
and the top-level analysis. The make all directive runs these tasks in sequence:
shell prompt> make -f 0in_hier.Makefile all
output from block-level sessions
output from the top-level session
In addition to the front-to-back flow, the Makefile can be used to run the cdc sessions
individually, for example:
shell prompt> make -f 0in_hier.Makefile blk1
shell prompt> make -f 0in_hier.Makefile top
The targets of the make commands are the design unit names of the blocks (blk1, blk2 and blk3
in this example) and the DUT name (top).
Example 4-3. 0in_hier.Makefile
## Hierarchical CDC Makefile
##----------------------------------------------------CDC_OD = 0in_hier
CDC_HIER_CMD = "cdc -d top dut.v"
CDC_TOP_CMD = "cdc -d top dut.v"
0IN = 0in
all:BLOCKS top
BLOCKS:blk1 blk2 blk3
126

October 2011
CDC Analysis
# BLOCK-LEVEL RUN: blk1

blk1: rm -rf $(CDC_OD)/blk1
$(0IN) $(DEBUG) -od $(CDC_OD)/blk1 -cache 0in_cache \
-cmd $(CDC_HIER_CMD) -hier \
-hier_block blk1
-hier_block blk2
-hier_block blk3
# TOP-LEVEL RUN: top
top: rm -rf $(CDC_OD)/top
$(0IN) $(DEBUG) -od $(CDC_OD)/top -cmd $(CDC_TOP_CMD)
-ctrl top_ctrl.v \
-hier_cache \
$(CDC_OD)/blk1/0in_cache \
$(CDC_OD)/blk2/0in_cache \
$(CDC_OD)/blk3/0in_cache
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:

October 2011
127
CDC Analysis
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 toplevel 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 4-8).
Figure 4-8. Waiving a Block-level Violation
Create Directive >Waived
Remove TX/RX
Clock Names
Pre-filled Dialog
Fields
Add Module
Name
Add Comment
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 set_cdc_report
-severity waived directive is added to the Directives window.
128

October 2011
CDC Analysis
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 control file (for example, waivers_blk1.v).
5. Specify the waivers control files for the blocks during top-level CDC control file
generation:
0in> cdc -d top -ctrl top_ctrl.v \
-report_constraints blk1 blk2 blk3 \
-ctrl waivers_blk1.v -ctrl waivers_blk2.v -ctrl waivers_blk3.v
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 designs 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. 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, 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 control file is generated for each
specified hierarchical CDC block. For example:
October 2011
129
CDC Analysis
0in_cdc_hier_constraints_blk1_ctrl.v
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 control 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 control files are generated:
0in_cdc_hier_constraints_blk1_0_ctrl.v
0in_cdc_hier_constraints_blk1_1_ctrl.v
During block-level analysis, each of these instance groups must be analyzed separately:
0in> cdc -d top -od 0in_hier/blk1_0 \
-ctrl 0in_cdc_hier_constraints_blk1_0_ctrl.v \
-hier_instance top.U1
0in> cdc -d top -od 0in_hier/blk1_1 \
-ctrl 0in_cdc_hier_constraints_blk1_1_ctrl.v \
-hier_instance top.U3
In this example, blk1 has two heterogeneous groups of instances: (top.U1) and (top.U3). Instead
of specifying the blk1 block with the -hier_block module argument, you specify the
heterogeneous instances with a -hier_instance instances argument. In this example, block-level
analyses of blk1 generate two CDC interface models for use in the top-level analysis:
0in_hier/blk1_0/0in_cache
0in_hier/blk1_1/0in_cache
Tip: The 0in_hier.scr and 0in_hier.Makefile scripts also work for heterogeneous
instances of blocks. For example, make -f 0in_hier.Makefile blk1_0.
When hierarchical blocks are present, 0in_cdc_design.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
Number of ILM Hierarchical Blocks
Number of CDC bits
= 82
= 1
= 1
Detail Design Information

=========================
CFM Hierarchical Blocks:
-----------------------U1 ( blk1 )
ILM Hierarchical Blocks:
-----------------------U2 ( blk2 )
130

October 2011
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: 0in_hier/*/0in_cache). 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. Some block netlists
can 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 4-9).
To generate a control file model during block-level analysis of a block, add the following
hierarchical CDC preference to the block-level control file:
// 0in set_cdc_hier_preference -ctrl_file_models
CDC analysis for the block generates both an ILM model and a CFM model (named
0in_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 control files (during the
report constraints step).
Figure 4-9. Top-level CDC Analysis with CFMs
ILM
top-level design
top-level violation
V
previously
analyzed blocks
ILM
ILM
interface
logic model
top-level violation
V
CFM
CFM
file
CFM control
model
inter-block violation
ILM
ILM
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 \
-hier_ctrl_file_model blk3 0in_cdc_hier_blk3_ctrl.v

October 2011
131
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 4-6 compares the ILM and CFM models and
Table 4-7 shows the limitations of the control file models.
Table 4-6. ILMs vs. CFMs
Interface Logic Model
Internal interface logic model
saved in a block-level cache.
Results are equivalent to
standard (flat) CDC analysis.
User can limit the depth of CDC
analysis.
Blocks can be modules/entities
and instances.
Block logic schematics
available.
Feature
data structure
efficacy
user control
granularity
GUI
Control File Model

Control file.
Some CDC schemes might be
missed.
User can edit the control file.
Blocks can be modules/entities,
but not instances.
Block logic schematics not
available.
Table 4-7. Control File Model Limitations

Feature
Limitation
multiple constraints
Separate constraints for different instances of the block are not

supported.
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.
bused, internal and virtual

clocks
Ignored in generated control file models and during block-level

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.
bitwise port domains
Not supported. SystemVerilog structs with different port domains

for different fields are marked as -nosync ports.
inout ports
Not supported.
set_constant
Slices and bits in the block are not supported for set_constant.
combo fanout
Combo fanout can degrade constraints of ports which have

majority of sequential fanouts. Workaround is to set -ignore or
port domain on the combo fanout port at block level.
132

October 2011
CDC Analysis
Modal CDC Analysis
Modal CDC Analysis

The customers design can have several modes of operation. Following are several reasons for
having multiple modes:
Testing in this mode, sequential elements are chained together.
Power optimization idle design blocks can be disabled, and clocks can be gated.
Handles configurable designs design might be targeted for multiple customers.
Running CDC analysis on these designs results in a large number of CDC violations. Users are
only interested in a subset of the violations that are relevant to the modes their designs are
intended to operate in. In addition, many users (particularly verification engineers) might not be
aware of the operating modes a design could operate in. A feature to automatically infer all the
operating modes and let the user select the ones their design can operate in helps address this
issue.
Modal analysis enables the user to specify the operating modes, or infer all of the modes, or
allows the user to select the set that is of interest. CDC analysis only generates violations for the
modes selected by the user.
Modal analysis has the following features:
Automatically infer clock domain modes, with capabilities for user specification of
modes.
Allows the user to spawn multiple CDC runs to analyze the circuit in each mode.
Debug the results of all modes through a single data base.
The modes are inferred based on the clock multiplexing in the design. For example, for a design
with three clock domains (A, B, and C), if clock domain B can be synchronized to A with a
MUX and the clock domain C can be synchronized to A with a MUX, each with separate
control signals as shown in Figure 4-10, then there are three possible modes that are of interest
for CDC analysis as follows:
1. All asynchronous.
2. A and B grouped into one domain, C a separate domain.
3. A and C grouped into one domain, B a separate domain.
The fourth mode of operation, when all clocks are grouped into one domain (driven by CLKA),
is not of interest to CDC analysis.

October 2011
133
CDC Analysis
Modal CDC Analysis
Figure 4-10. Modes are Inferred Based on the Clock Multiplexing
To perform the automatic recognition of clock modes, add the -report_modes option to the
CDC command line. With this option, the 0in_cdc_mode_control.v file is automatically created.
This file contains the definition of the inferred modes. The 0in_mode.scr shell script is then
executed to spawn multiple CDC runs to analyze each mode.
The mode control file can be edited to eliminate any modes that are not of interest by adding the
option to the corresponding set_mode global directive in this file. Then CDC can be
rerun with the modified mode control file as an input control file (using the -ctrl option) to
update the run script.
-ignore
The results of all modes can be analyzed together using the CDC GUI. Invoke the CDC GUI
with the following command:
0in_cdc 0in_cdc.db
Use Model
Modal analysis has two approaches as follows:
With user-specified modes and inferred modes
With inferred modes only
The basic use model for both approaches is identical. The difference is in the way analysis is
done and reports are generated. These differences are highlighted throughout the flow. Running
modal analysis is a four step process as follows:
134

October 2011
CDC Analysis
Modal CDC Analysis
1. Specify Modes (optional, see page 135)

2. Report Modes Run (see page 135)
3. Individual Mode Analysis (see page 138)
4. Viewing Results (see page 138)
Specify Modes (optional)

The user can specify the modes that need to be verified. With each mode, the user specifies
constant values for a set of registers, ports, and black box outputs. In addition, the user is
required to specify the complete path. The description of the supported options follows.
The modes are specified using the set_mode global directive (and the set_mode_control
directive). The syntax for this global directive is as follows:
set_mode
<mode_name>
[-set <hier_path> <value>]*
[-ignore]
// Current mode name.

// Constant values for this mode.
// Do not analyze for this mode.
The -set option is used to specify constant values in this specific mode. This option needs to
be specified once for each constant value.
The -ignore option is used to specify a mode that does not need to be considered for analysis.
Following is an example:
// Test modes.
// 0in set_mode scan_load -set tm 1'b1 -set scan_en 1'b1
// 0in set_mode scan_test -set tm 1'b1 -set scan_en 1'b0
// Regular operation modes.
// 0in set_mode fast_mode -set tm 1'b0 -set sel 1'b1
// 0in set_mode ignr_mode -set tm 1'b0 -set sel 1'b0 -ignore
Report Mode Runs

The cdc -report_modes command is required for modal analysis flow.
Run CDC with the -report_modes option similar to the following:
0in -cmd cdc -d top t0.v -report_modes
This automatically generates the modal script 0in_mode.scr file that you execute (just
0in_mode.scr with no arguments) as follows:
0in_mode.scr

October 2011
135
CDC Analysis
Modal CDC Analysis
This runs CDC multiple times (one per mode) and creates all of the database files (.db) for each
mode.
For both approaches (user-specified and inferred), the 0in_mode.scr script file is generated (see
page 146). This script contains the steps to run individual mode analysis.
In the presence of user modes, this script runs the user-specified modes only. If the user wishes
to analyze any of the missing modes, then the user needs to run this step again with an updated
control file.
If no user modes are specified, then CDC infers all the operating modes. A control file named
0in_cdc_mode_ctrl.v (see page 145) is automatically generated with directives specifying all
the inferred modes. Details of all the inferred modes are included in the CDC design
0in_cdc_design.rpt report file (see page 145).
If the user modes are specified, then mode inferencing still occurs. The inferred modes are
compared to the user modes to identify any missing or incomplete modes. All errors identified
in the user specified modes are reported in the 0in_cdc_design.rpt report file (see page 145). A
control file named 0in_cdc_mode_ctrl.v (see page 145) is automatically generated with
set_mode global directives for incomplete user modes and inferred modes not specified by the
user.
Mode Verification and Coverage Reporting

Mode verification analyzes user-specified modes for completeness and coverage with respect to
the modes inferred. Appropriate warning messages are generated to report the user modes that
are missing, ignored, incomplete, OK, and duplicate when the cdc -report_modes option is
specified.
The messages in the modal summary table below have the following meanings:
136
Missing mode This is an inferred mode. For every missing mode, a [hdl-119]
message is generated. A set_mode global directive is generated for this inferred mode
in the 0in_cdc_mode_ctrl.v file.
Ignored mode This user mode is ignored for modal analysis. This is specified by the
user with the -ignore option.
Incomplete mode This user mode is partially specified and needs additional
constants. For each missing constant inferred by the tool, a [hdl-125] warning message
is issued. A set_mode global directive is generated for the corresponding complete
mode in the 0in_cdc_mode_ctrl.v file.
OK This user mode is complete (verified). The user mode may contain additional
signals that were not inferred. These signals are marked as undetected in the mode
information table. The [hdl-124] information messages are issued for each undetected
signal.

October 2011
CDC Analysis
Modal CDC Analysis
Duplicate mode This user mode is a duplicate of another user-specified mode or

incomplete mode. A [hdl-118] warning message is issued for every duplicate mode.
The Modal summary and information tables shown below are printed in the 0in_cdc_design.rpt
file when the cdc -report_modes option is specified.
Modes
=====
-------------------------------------------------------------Mode
Type
Message
-------------------------------------------------------------cdc_mode_0
Questa CDC
Missing mode
mode2
User
Ignored mode
mode3
User
Incomplete mode(missing constant)
mode4
User
OK
mode5
User
OK
mode6
User
Duplicate mode(mode4)
--------------------------------------------------------------
User Modes
=========
Constants in mode2 (Ignored)
---------------------------------------------------Signal
Value
Type
---------------------------------------------------sel1
1'b0
User
sel2
1'b0
User
----------------------------------------------------
Constants in mode3 (Incomplete)

---------------------------------------------------Signal
Value
Type
---------------------------------------------------sel1
1'b0
User
sel2
1'b1
User
sel3
1'b1
Questa CDC
----------------------------------------------------
Constants in mode4
---------------------------------------------------Signal
Value
Type
---------------------------------------------------sel4[3:2]
2'b10
User
sel5
3'b110
User
----------------------------------------------------
Constants in mode5
---------------------------------------------------Signal
Value
Type
---------------------------------------------------sel1
1'b1
User
sel2
1'b0
User

October 2011
137
CDC Analysis
Modal CDC Analysis
sel5
3'b101
User (Undetected)
----------------------------------------------------
Constants in mode6 (Duplicate)

---------------------------------------------------Signal
Value
Type
---------------------------------------------------sel4[3:2]
2'b10
User
sel5
3'b110
User
----------------------------------------------------
Inferred Modes
===============
Constants in cdc_mode_0 (Missing)
---------------------------------------------------Signal
Value
---------------------------------------------------sel1
1'b1
sel2
1'b0
sel3
1'b1
----------------------------------------------------
Individual Mode Analysis

The user is required to execute the 0in_mode.scr file manually. This step has the longest
runtime. With minimal modifications, the generated script can be run using LSF, which can
significantly reduce runtimes for large designs. The run command is as follows:
0in_mode.scr
At this point, the user can observe the modes inferred by CDC as well as the modes specified by
the user, even though the CDC run is incomplete (see Viewing Incomplete CDC Runs on
page 147).
The user might be interested in verifying their clock tree first before running CDC analysis. In
this case, the cdc -report_clock option can be used along with report modes. After running
all of the steps, the user can view clock trees for all the modes in the CDC GUI (see Viewing
Incomplete CDC Runs on page 147).
Viewing Results
The results can be viewed using the CDC GUI as follows:
0in_cdc 0in_cdc.db
This command invokes the CDC GUI in the modal state as shown in Figure 4-12 on page 140.
138

October 2011
CDC Analysis
Modal CDC Analysis
This displays all the violations and their corresponding modes (see the 0in_cdc User Interface
Modal subsection below for detailed information).
0in_cdc User Interface Modal

The 0in_cdc user interface (UI) supports debug of the CDC modal database. To use it, invoke
on the database (that is, 0in_cdc 0in_cdc.db) the same as for a database that is not modal.
The UI automatically determines whether to be in modal mode or not. If the database has modal
CDC results, then the UI displays the additional mode indicators to help the user browse the
modal results. Figure 4-12 shows the mode indicators circled in red. To invoke the schematic
view, double-click or right-click on the check, select Show Schematic > Path, as shown in
Figure 4-12. To invoke the Details window, right click on the check, select Show Details.
Figure 4-11. 0in_cdc Mode

October 2011
139
CDC Analysis
Modal CDC Analysis
Figure 4-12. 0in_cdc Mode
If the database is modal, then the CDC Checks view has a mode column (see Figure 4-12) so
that the checks can be grouped and sorted by mode. The clock tree display in the Workspace
pane (see Figure 4-12) also shows an additional mode level of hierarchy.
The filters feature can be used to change the default maximum hierarchy displayed. To do this,
right-click on a signal and select Filters as shown in Figure 4-13. This invokes the Edit
Preferences window as shown in Figure 4-14. Change the Maximum Hierarchy Displayed
number as desired. In this example, the number is changed from 3 to 0.
140

October 2011
CDC Analysis
Modal CDC Analysis
Figure 4-13. Filter

October 2011
141
CDC Analysis
Modal CDC Analysis
Figure 4-14. Filter Hierarchy Displayed
Because any schematic path displayed from the CDC Checks view is from a specific CDC
modal run, the schematic always retains its mode so that incremental exploring of that
schematic colors itself as per that mode as shown in Figure 4-12 on page 140. The mode for the
schematic path is displayed in the schematics title. In addition, the Path ID signal is displayed
in the schematic title and in the Details pane, which is multi_bits_68424 for this example
(circled in green in Figure 4-12 on page 140).
Note that the bubble help not only displays the usual clock group for a signal, but also the mode
for that clock tree as shown in Figure 4-15.
142

October 2011
CDC Analysis
Modal CDC Analysis
Figure 4-15. Mode for the Clock Tree
Clock Color as the Mode Context Changes

Any non-CDC path schematics as well as HDL source views update their clock coloring as the
mode context changes. The user can change the mode context by selecting the mode or a
signal in the mode tree from within the clock tree view. The current mode is displayed in the
title bar and the footer.
Figure 4-16 and Figure 4-17 show the color changes as the mode context changes. Note also
that the Details window reflects the port constraint settings for the current mode selected. Go to
the Workspace window, select Design, then double-click to select an Instance (modr(6) is used
in this example). Then go to the Clocks tab and select a clock in the Mode window
(cdc_mode_0 (4) is selected). View the color mode context scheme in Figure 4-16.

October 2011
143
CDC Analysis
Modal CDC Analysis
Figure 4-16. Clock Coloring Mode
Now select cdc_mode_1 (5) and observe the signals change color as shown in Figure 4-17.
Figure 4-17. Color Change as the Mode Context Changes
144

October 2011
CDC Analysis
Modal CDC Analysis
Examples
0in_cdc_mode_ctrl.v File
An example of the automatically generated mode control file (0in_cdc_mode_ctrl.v) is
shown below:
module zin_cdc_mode_ctrl_top;
// Mode: cdc_mode_0
// Clock: TRK
/* 0in set_mode cdc_mode_0
-set TCS 1'b1
*/
// Mode: cdc_mode_1
// Clocks:
//
CLK0
//
RCLK[0]
-set TCS 1'b0
-set I5[1:0] 2'b0
*/
// Mode: cdc_mode_2
// Clocks:
//
CLK0
//
RCLK[1]
-set TCS 1'b0
-set I5[1:0] 2'b1
*/
endmodule
0in_cdc_design.rpt File
A sample mode coverage report file (generated in 0in_cdc_design.rpt) is shown below:
Mode information
================
-------------------------------------------Mode
Type
Information
-------------------------------------------cdc_mode_0
Questa CDC Inferred mode
cdc_mode_1
cdc_mode_2
-------------------------------------------User Modes
==========
None
Inferred Modes
==============
Constants in cdc_mode_0

October 2011
145
CDC Analysis
Modal CDC Analysis
------------------------------------------Signal
Value
------------------------------------------TCS
1'b1
------------------------------------------Constants in cdc_mode_1
------------------------------------------Signal
Value
------------------------------------------TCS
1'b0
I5[1:0]
2'b00
------------------------------------------Constants in cdc_mode_2
------------------------------------------Signal
Value
------------------------------------------TCS
1'b0
I5[1:0]
2'b01
-------------------------------------------
0in_mode.scr File
A sample automatically generated mode script file (0in_mode.scr) is shown below:
#!/bin/csh -f
\rm -fr /modal/0in_mode
mkdir /modal/0in_mode
set cdc_od = /modal/0in_mode
set cdc_cmd = "cdc -d top t0.v"
# Invoke CDC for all the modes.
set fail = 0
set fail_mode = ""
foreach cdc_mode (cdc_mode_0 cdc_mode_1 cdc_mode_2)
# Run CDC for $cdc_mode
0in -od ${cdc_od}/$cdc_mode \
-cmd $cdc_cmd \
-ctrl 0in_cdc_mode_ctrl.v \
-mode $cdc_mode
# Check for failures
set fail = 1
set fail_mode = $cdc_mode
else
set fail_mode = ($fail_mode $cdc_mode)
endif
endif
end
146

October 2011
CDC Analysis
Modal CDC Analysis
# Cleanup
echo PASSED
exit 0
else
echo FAILED : $fail_mode
exit -1
endif
Viewing Incomplete CDC Runs

Up to this point, only completed CDC runs for each mode with complete database results for
each mode have been described.
The user can run modal with the -report_modes option that allows the user to observe modes
inferred by CDC as well as the modes specified by the user. In a situation where the UI does not
have completed modal results, the UI displays the modes in the clock view; however, the modes
do not have clock tree information to display unless that mode has successfully completed and
the database for it exists.
There are no CDC checks displayed for an incomplete mode. A default clock tree is displayed
for the user to explore.
Run CDC with -report_modes option to review the clock tree and the possible set of modes
for Modal Analysis.
The ability to view modal results that are still in the process of completing is useful if the design
is very large and takes a long time to run CDC for all modes. In addition, the user can view
clock groups for each modal run and modify them accordingly.
Following are the steps to review the clock tree for each modal before the CDC run is complete:
1. Run CDC using the -report_modes option. For example,
cdc -d top t0.v -effort unlimited -cr t0.cdc.rpt -report_modes
This automatically generates the 0in_mode.scr file, which contains the source code to
generate the modes. In addition, the 0in_mode directory is automatically generated.
However, at this time the directory is empty because the 0in_mode.scr file that generates
the reports for each modal has not been run.
2. Invoke the CDC GUI with the following command:

0in_cdc 0in_cdc.db &
This command invokes the CDC GUI as shown in Figure 4-18 with the Clock tab
selected. Notice in the Workspace window that the modes are not loaded.

October 2011
147
CDC Analysis
Modal CDC Analysis
Figure 4-18. Modes Have No Clock Tree Information
3. Generate the reports for each modal run as follows:

0in_mode.scr
Refer to 0in_mode.scr File on page 146 for detailed information.

While this command continues to run, the user can review the clock tree as follows (see
Figure 4-19):
File > Reload > Database
Figure 4-19. Reload Database
148

October 2011
CDC Analysis
Modal CDC Analysis
Figure 4-20 shows cdc_mode_0 and cdc_mode_1 are now loaded. However,
cdc_mode_2 has not completed running and is not loaded. As the design continues to
run, the user can continue to select File > Reload > Database to load as they
complete running.
Figure 4-20. Some Modes Have Clock Tree Information

October 2011
149
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 (see Compiling FPGA Source Libraries on page 63).
Questa CDC/Formal distribution software comes with synthesizable versions of the
unisim/simprim Xilinx and the Altera source libraries in $HOME_0IN/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 0in_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
vmap
vcom
vcom
vlog
150
0in_libs/unisim
unisim 0in_libs/unisim
-work unisim $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd
-work unisim $XILINX/vhdl/src/unisims/unisim_VPKG.vhd
-work unisim -convertallparams \

October 2011
CDC Analysis
$HOME_0IN/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 0in_libs/unisim
vmap unisims_ver 0in_libs/unisims_ver
vlog -work unisims_ver \
$HOME_0IN/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
vmap
vcom
vcom
vlog
0in_libs/simprim
simprim 0in_libs/simprim
-work simprim $XILINX/vhdl/src/simprims/simprim_Vcomponents.vhd
-work simprim $XILINX/vhdl/src/simprims/simprim_Vpackage.vhd
-work simprim -convertallparams \
$HOME_0IN/share/fpga_libs/Xilinx/ISE/xeclib/simprims/*.v
simprims_ver
models of the Xilinx library.
vlib 0in_libs/simprim
vmap simprims_ver 0in_libs/simprims_ver
vlog -work simprims_ver \
$HOME_0IN/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 0in_libs/XilinxCoreLib
vmap XilinxCoreLib 0in_libs/XilinxCoreLib
vcom -work XilinxCoreLib -f xilinxcorelib_vhdl_analyze_order.f

October 2011
151
CDC Analysis
XilinxCoreLib_ver
Used for library elements instantiated in Verilog. Compile the Verilog simulation library
files.
vlib 0in_libs/XilinxCoreLib_ver
vmap XilinxCoreLib_ver 0in_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 0in_libs/altera_mf
vmap altera_mf 0in_libs/altera_mf
vcom -work altera_mf \
$QUARTUS_ROOTDIR/eda/sim_lib/altera_mf_components.vhd
vlog -work altera_mf \
$HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \
+incdir+$HOME_0IN/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 0in_libs/altera_mf_ver
vmap altera_mf_ver 0in_libs/altera_mf_ver
vlog -work altera_mf_ver \
$HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \
+incdir+$HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog
152

October 2011
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 0in_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 (see Preparing a Design
Library on page 57). This example shows the library mappings for a VHDL-only Xilinx
design:
[Library]
unisim = ./0in_libs/unisim
XilinxCoreLib = ./0in_libs/XilinxCoreLib
work = ./0in_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 0in_libs/work
vmap work 0in_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

October 2011
153
CDC Analysis
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 compiler/analyzer
command is a required argument that identifies the target design.
Once the FPGA resource libraries and the design library have been compiled, you can compile
the CDC logic model using the cdc command (page 364). Here are two examples:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd
Compiles the target design DUT_top from work using libraries mapped in ./modelsim.ini
(the default mapping file).
prompt> 0in -cmd cdc -d DUT_top -work top_lib -vhctrl cdc_control.vhd \
-modelsimini LibraryMapping.0in
Compiles the target design DUT_top from top_lib using libraries mapped in
LibraryMapping.0in.
Tip: Running cdc on a design can take time. Initial cdc runs are used only to refine the
clock domain model of the design in preparation for compiling and analyzing the CDC
logic. The cdc commands -report_clock option short-circuits the complete cdc
compilation/analysis and stops after identifying the clock domain model characteristics.
You will 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. Create one or more control files.
A control file is a text file listing a series of 0in global directives (page 260). Global
directives set up operating conditions, define clocks, define black boxes, specify custom
synchronizers, modify reported results, create waivers, and so on. You will apply
significant effort creating and adjusting the control files because this is how you fine
tune CDC analysis. Here is an example control file:
entity cdc_control is
end cdc_control;
architecture ctrl of cdc_control is
begin
-- 0in set_constant scan_mode 0
-- 0in set_cdc_clock CLK_1 -group clk_grp_A -period 4
-- 0in set_cdc_clock CLK_2 -group clk_grp_A -period 8
-- 0in set_cdc_clock CLK_3 -group clk_grp_B -period 11
-- 0in set_cdc_port_domain input_port1 -async
-- 0in set_cdc_port_domain input_port2 -clock CLK_1
-- 0in set_cdc_port_domain -output -clock CLK_2
-- 0in set_cdc_reconvergence -depth 1 -divergence_depth 1
154

October 2011
CDC Analysis
-- 0in set_black_box syncA* cdi_master
-- 0in set_cdc_preference -black_box_empty_module
end ctrl;
In addition to standard CDC global directives, the following directives are particularly
useful for CDC analysis of FPGA designs.
set_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
technique makes the memory footprint smaller, improves performance and ensures
only relevant results are returned.
set_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.
set_black_box
Identifies specific modules/entities/architectures as user-defined black boxes. Use
set_cdc_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.
set_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 set_cdc_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 in report-clocks mode.
For example:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd \
-report_clock
The command performs clock analysis and stops. Check the results:

October 2011
155
CDC Analysis
a. Check 0in.log for errors:

Error/Warning Summary (Look in 0in_detail.log for more information)
----------------------------------------------------------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 0in_detail.log. Fix any issues, then

rerun design compilation (if the source code changed) and cdc -report_clock.
b. Check the clock groupings in 0in_cdc_design.rpt.
Clock Group Summary for DUT_top
=================================
Total Number of Clock Groups
Number of User-Defined Clock Groups
Number of Inferred Clock Groups
Number of Ignored Clock Groups
:
:
:
:
2
1
1
0
User-Specified Clock Groups

===========================
Group
0(0 Register Bits, 0 Latch Bits)
-----------------------------------------clk[0]
Inferred Clock Groups
=====================
Group
0(11 Register Bits, 0 Latch Bits)
------------------------------------------clk[1]
shft_sync.clk
dff_sync.clk
Ignored Clock Groups
====================
None
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.
3. Run cdc.
For example:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd
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:
156

October 2011
CDC Analysis
0in_cdc.db .db database of the CDC results for loading into the CDC GUI.
0in_cdc.rpt Text report containing CDC results.
0in_cdc_design.rpt Text report containing results of clock and design analysis
0in_cdc_ctrl.v Control file specifying generated CDC protocol checkers.
4. Check the 0in_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
in2
input
{clk[0]}
User
in3
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
primary inputs or outputs that connect to multiple clock domains or are not assigned
to a clock domain are listed. Use set_cdc_port_domain directives to make
adjustments.
b. Check for black boxes.
Black Boxes:
-----------cdi_master ( black_box )
syncA_1
( black_box )
syncA_3
( black_box )
syncA_7
( black_box )
Inferred Black Boxes for unresolved modules
------------------------------------------dut.Di2
( mod )
Internal logic of the black boxes is unknown and in particular, the connectivity
between a black boxs 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 set_black_box directives. Check the inferred black
boxes in 0in_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)
-----------------------------------------------------------------

October 2011
157
CDC Analysis
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 set_black_box) and
specify the port domains for the black boxs I/O ports (with set_cdc_port_domain).
The following example directives do this for an Altera dual-port RAM block:
------------------
0in
0in
0in
0in
0in
0in
0in
0in
0in
0in
0in
0in
0in
set_black_box altdpram
set_cdc_port_domain wren -clock inclock -module altdpram
set_cdc_port_domain data -clock inclock -module altdpram
set_cdc_port_domain wraddress -clock inclock -module altdpram
set_cdc_port_domain wraddressstall
-clock inclock -module altdpram
set_cdc_port_domain inclocken -clock inclock -module altdpram
set_cdc_port_domain byteena -clock inclock -module altdpram
set_cdc_port_domain rden -clock outclock -module altdpram
set_cdc_port_domain rdaddress
-clock outclock -module altdpram
set_cdc_port_domain rdaddressstall
set_cdc_port_domain outclocken
set_cdc_port_domain q -clock outclock -module altdpram
set_cdc_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.
Phase 4: Running GUI Debug

The 0in_cdc command runs the CDC GUI. To run 0in_cdc in GUI debug mode, specify the
CDC results database as the only argument:
At this point, debugging CDC issues with the CDC GUI is the same for FPGA-based design as
it is with other designs. See 0in_cdc: GUI Debug Mode on page 88. Also see the chapter
GUI Reference on page 419 for details on the various GUI tools and windows. 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:
158
Adjust clock configurations (set_cdc_clock)
Set clock domains of I/O ports (set_cdc_port_domain)
Declare custom synchronizers (set_cdc_synchronizer)
Define characteristics of certain signals in the design (set_cdc_signal)

October 2011
CDC Analysis
Reclassify the results (set_cdc_report)

October 2011
159
CDC Analysis
160

October 2011
Chapter 5
CDC-FX Metastability Injection
Metastability injected simulation is an extension to normal RTL simulation that injects random
metastability into the circuits 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.

October 2011
159

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 set_cdc_fx_metastability_window global directive (see page 163). This global
directive sets the metastability window for the CDC-FX clocks.
Setup and Hold Periods

Figure 5-1 shows setup and hold time periods around a registers 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 5-1. Setup and Hold Times for a Register Input
tsetup
thold
rx_clk
stable
unstable
unstable
stable
Metastability Windows
The setup and hold times determine receive clock cycles for which a register can become
metastablebased 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 5-2. A metastability window defined this way assumes
the worst case events as follows:
160
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).

October 2011

Figure 5-2. Metastability Window

tsetup
rx_clk
thold
max tprop
min tprop
start
metastability window
start = tsetup - max tprop
stop
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.

October 2011
161

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 5-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 5-3. clks_aligned Input to the cdc_fx Checker
Clocks not aligned.
clks_aligned
tx_clk
rx_clk
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
162

October 2011

set_cdc_fx_metastability_window
The set_cdc_fx_metastability_window directive specifies a metastability window for one or
more receive register clocks. This global directive is used by the cdc -compile_assertions
command.
-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 set_cdc_fx_metastability_window global directive is specified, then the special
default case described in the next section is followed. However, if at least one
set_cdc_fx_metastability_window global 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 set_cdc_fx_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 set_cdc_fx_metastability_window global directive does not support bussed

clocks.
Special Default Case

If a set_cdc_fx_metastability_window global directive is not specified for a CDC crossing,
then the (default) metastability window is set as follows (see Figure 5-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.

October 2011
163

Figure 5-4. Metastability Window Default

tsetup
thold
rx_clk
start = 25%
clock period
stop = 10%
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:
-start 25 stop 10 -tx_clock tx_clk -rx_clock rx_clk */
See also set_cdc_fx_timescale on page 272.
164

October 2011

Running CDC-FX
Running CDC-FX
The metastability injectors (cdc_fx checkers and metastability detection logic) are instantiated
from cdc_fx checker directives. The user can specify these directives manually, but CDC
paths can be numerous and this process is prone to user error. Instead, use a built-in feature of
the cdc command to automate the process of preparing the design data for the CCL compiler.
Since cdc analyzes CDC paths anyway, it can readily construct the cdc_fx checker directives
for them. Therefore, if the user includes the -fx option to the cdc command, then it generates
a CDC-FX control file (0in_cdc_fx_sim_ctrl.v) that contains cdc_fx checker directives that
can be used with the CCL compiler (see Figure 5-5).
Figure 5-5. CDC Data Flow for Simulation with Metastability
CDC-FX control file
(with set_cdc_fx_check directives)
cdc -fx
0in_cdc_fx_sim_ctrl.v
edit
design checker
files
control
files
ccl
CDC-FX control file
(with set_cdc_fx_metastability_window directives)
simulation with
metastability
Figure 5-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 set_cdc_fx_metastability_window global
directives used to set the metastability windows for the cdc_fx checkers.
set_cdc_fx_check
The set_cdc_fx_check directive turns on specified checks in corresponding cdc_fx checker
directives promoted by the cdc -fx command.
set_cdc_fx_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.

October 2011
165

Running CDC-FX
Use the set_cdc_fx_check global 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 set_cdc_fx_check global directive does not support
wildcards.
Questa CDC analyzes CDC information. For certain CDC signals and data buses, it formulates
checker directives that instantiate a cdc_fx checker and generates metastability detection logic
for modeling CDC metastability effects during simulation with assertions. These promoted
cdc_fx directives are saved in the zin_cdc_fx_sim_ctrl module in the
0in_cdc_fx_sim_ctrl.v file (see Example 5-1).
The user can edit the 0in_cdc_fx_sim_ctrl.v file to remove unnecessary directives and make
changes that might apply to your design. Then, the user specifies the edited file as a checker
control file when invoking the ccl command, as demonstrated in Example 5-2 on page 167.
Example 5-1. 0in_cdc_fx_sim_ctrl.v File Snippet
//----------------------------------------------------------------// CDC FX Simulation File
// Created Mon Dec 18 14:56:50 2006
//----------------------------------------------------------------//Summary
//------//Count :
Module
//----------------------------------------------------------------//
17 :
demo_top
module zin_cdc_fx_sim_ctrl;
//cpu_clk_in --> mac_clk_in
//ID:two_dff_5840 --> init_done
//----------------------------------------------------------------/* 0in cdc_fx
-tx_reg init_done
-rx_reg init_done_r1
-rx_clock mac_clk_in
-name zin_cdc_fx_sim_init_done_r1_0
-module demo_top
-inferred
*/
//cpu_clk_in --> core_clk_in
//ID:no_sync_47305 --> init_done
166

October 2011

Running CDC-FX
//----------------------------------------------------------------/* 0in cdc_fx
-tx_reg init_done
-rx_reg tx_state[0]
-name zin_cdc_fx_sim_tx_state_0__1
-module demo_top
-inferred
*/
//cpu_clk_in --> core_clk_in
//ID:no_sync_2628 --> init_done
//----------------------------------------------------------------/* 0in cdc_fx
-tx_reg init_done
-rx_reg tx_en
-name zin_cdc_fx_sim_tx_en_2
-module demo_top
-inferred
*/
. . .
endmodule
Example 5-2. Editing the 0in_cdc_fx_sim_ctrl.v File

> cp 0in_cdc_fx_sim_ctrl.v cdc_fx_sim_ctrl.v
> vi cdc_fx_sim_ctrl.v
> 0in cmd ccl d design ctrl cdc_fx_sim_ctrl.v ...
CDC-FX Checker Promotion

Table 5-1 shows the CDC schemes that promote cdc_fx checkers.
Table 5-1. CDC Schemes and cdc_fx Checker Promotion
Promote cdc_fx Checkers
bus_four_latch
bus_shift_reg
bus_two_dff
bus_two_dff_phase
combo_logic
dff_sync_gated_clk
dmux
four_latch

October 2011
Do Not Promote cdc_fx Checkers

handshake
multi_bits
no_sync
pulse_sync
shift_reg
simple_dmux
two_dff
two_dff_phase
async_reset
async_reset_no_sync
black_box
custom_sync
bus_custom_sync
memory_sync
reconvergence
redundant
167

Running CDC-FX
The following situations can cause a cdc_fx checker not to be promoted, or to be promoted with
partial information:
168
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.

October 2011

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 5-6).
Figure 5-6. Metastability-injected Simulation
vcom/vlog
design
files
cdc
-compile_assertions
control
files
-work library
vsim
-f 0in_cdc_sim.arg
merge
0in_checksim.db
vcom/vlog
0in_cdc
0in_cdc.db
GUI
vcom/vlog
testbench
files
debugging
environment
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 the prefix showing the hierarchy path from the top
level testbench to the DUT analyzed by cdc. Also specify -fx so cdc generates the
information used to compile the metastability injection logic. For example:
-compile_assertions -prefix tb.dut_inst -fx

October 2011
169

3. Compile the CDC-FX metastability injection logic.

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

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 0in_cdc.db database generated by cdc and merge the 0in_checksim.db database
generated by vsim.
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
To suppress metastability injection for all individual signals, specify the following argument:
Refer to Verilog Glue Logic Option Impact on page 171 and VHDL Glue Logic Option
Impact on page 173 for additional information.
170

October 2011

+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.
Verilog Glue Logic Option Impact

The differences between the following options for Verilog glue logic are described in this
section:
ZI_NO_CDC_FORCE

October 2011
171

$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 ${HOME_0IN}/lib/lib0InLoadMTIPLI.so
or
% ./simv +0in_disable_fx_force
$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.
172

October 2011

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_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 172).
+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 173).

October 2011
173

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.
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 0in_cdc database viewer to analyze the results.
o
End-to-end test errors indicate receive logic is not tolerant of CDC metastability
effects.
Assertion failures indicate receive logic is not tolerant of CDC metastability effects.
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.
The glitch_caught check ensures that metastability injection does not catch a
glitch if it is not detected by simulation.
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 5-7 on page 175). Use the 0in_cdc 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.
174

October 2011

Figure 5-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 (0in_checksim.db) has this
information.
The cdc_fx checkers 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.

October 2011
175

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.
176

October 2011
Chapter 6
Command 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, custom_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 and multi_bits.
Control/data: dmux, simple_dmux, multi_sync_mux_select, handshake, fifo,

memory_sync and custom_sync_with_crossing.
Potential problems: combo_logic, port_constraint_mismatch, reconvergence,

single_source_reconvergence, redundant, series_redundant, fanin_different_clks
and black_box.
Global Directives
Clocks and domains: set_cdc_clock, set_cdc_port_domain and

set_cdc_port_constraint.
CDC analysis: set_reset, set_cdc_preference, set_cdc_reconvergence,

set_cdc_hier_preference, set_mode and set_mode_control.
CDC schemes: set_cdc_synchronizer, set_cdc_signal and set_cdc_report,

set_cdc_fifo, set_cdc_fifo_preference, set_cdc_handshake_preference,.
Checker promotion: set_cdc_protocol.
CDC-FX: set_cdc_fx_timescale, set_cdc_fx_metastability_window and

set_cdc_fx_check.
Netlist generation: set_black_box, set_memory, set_constant and

set_constant_propagation.
Checker generation: default_reset, use_synthesis_case_directives, exclude_checker,

include_checker, disable_checker, disable_used, set_severity, set_checker_action,
checker_firing_keyword and create_wire.

October 2011
177
Command Reference
Shell Commands
Utilities invoked from the system shell: vlib, vmap, vcom, vlog, verror, vdir, vdel, 0in,
0in_cdc and 0in_db2ucdb.
0in Shell Commands

Utilities invoked from the 0in shell:cdc. lib2v and cwhelp.
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 checkers: cdc_fx and
cdc_custom_fx.
178

October 2011
Command 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 6-1). Each data sheet has the
following information:
General Information 0in_cdc 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 global 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 6-1. CDC Schemes
Type
Scheme
Default
Severity
ID
Description
TWO DFF
SYNCHRONIZER
Two or more in-phase flip-flops. evaluation
two_dff_phase
TWO DFF
SYNCHRONIZER
OPPOSITE
POLARITY
Two out-of-phase flip-flops.
four_latch
FOUR LATCH
SYNCHRONIZER
Four or more cascaded latches. evaluation
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 clock. caution
async_reset
ASYNC RESET
async_reset_no_sync
ASYNC RESET NO Asynchronous reset

SYNC
scheme.with a missing
synchronizer
violation
no_sync
MISSING
SYNCHRONIZER
violation
Signal
two_dff
Synchronizer

October 2011
Asynchronous reset scheme.
Missing synchronizer
caution
evaluation
179
Command Reference
CDC Schemes
Type
Scheme
ID
Description
Default
Severity
custom_sync
CUSTOM
Custom control signal

synchronizer.
evaluation or
violation
BUS SYNC
Two or more in-phase flip-flops. evaluation
BUS SYNC
Two out-of-phase flip-flops.
bus_four_latch
BUS SYNC
Four or more cascaded latches. evaluation
BUS DFF GATED

SYNC
Two flip-flops with gated clock. caution
bus_shift_reg
BUS SHIFT REG
Shift register.
multi_bits
MULTIPLE BITS
bus_custom_sync
BUS CUSTOM
Custom bus synchronizer
evaluation or
violation
DMUX
MUX enable.
caution
SIMPLE DMUX
MUX enable.
caution
MULTIPLE
SYNCHRONIZERS
AT DMUX
Multiple MUXes.
caution
handshake
HANDSHAKE
MUX enable with handshaking evaluation
fifo
FIFO
FIFO.
evaluation
memory_sync
MEMORY SYNC
2D array.
caution
custom_sync_with_crossing
CUSTOM WITH
CROSSING
Custom with internal crossing.
evaluation
combo_logic
COMBO LOGIC
Combinational logic on a
synchronization path.
violation
reconvergence
RECONVERGENCE Reconvergent CDC signals.
Data
bus_two_dff
Synchronizer
bus_two_dff_phase
Signal and
dmux
Data
Synchronizer simple_dmux
Potential
Problem
single_source_reconvergence SSR
180
caution
evaluation
violation
caution
Reconvergent CDC signals from violation

a single source.
redundant
REDUNDANT
CDC signal drives multiple

synchronizers.
caution
series_redundant
SERIES
REDUNDANT
connected in series
caution
FANIN LOGIC
Fan-in logic from multiple clock violation
FROM DIFFERENT domains.
CLOCKS
black_box
BLACK BOX
Crossing drives an instance of

an inferred black box.
caution

October 2011
Command Reference
async_reset
async_reset
ASYNC RESET: Signal feeds to the asynchronous reset port of the receiving register.
tx_rst
tx_sig
rst
1'b1 DFF
rx_rst
rst
DFF
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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 set_cdc_preference on page 286).
Examples
1. Following is an example to turn severity to violation.
// 0in set_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 tx_sig)
rx domain reset
if (!tx_sig) begin
s0 <= 1b0;
tx_sig
rst
rst
s1 <= 1b0;
s1
1'b1
end
else begin
high
s0 <= 1b1;
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)

October 2011
181
Command Reference
async_reset
the synchronizer. Synchronizer input is tied low.
rx domain reset
if (tx_sig) begin
s0 <= 1b1;
tx_sig
rx_rst
set
set
s1
s1 <= 1b1;
s0
1'b0
end
else begin
low
s0 <= 1b0;
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.
always
s0
s1
end
assign
rx domain reset
@(posedge rx_clk) begin

<= tx_sig;
<= s0;
tx_sig
rx_rst
s1
s0
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.
if (! tx_sig)
{s1, s0} <= 2b00;
else
{s1, s0} <= {s0, tx_sig};
assign rx_rst = s1 & tx_sig;
182
rx domain reset
tx_sig
rst
rst
s0
tx_clk
rx_rst
s1
rx_clk

October 2011
Command 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)

October 2011
183
Command 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
missing
reset
synchronizer
rx_sig
1'b1 DFF
rx_clk
tx_clk
Rx Clock Domain
Tx Clock Domain
incorrect
tx_sig
1'b1 DFF
reset
synchronizer
rx_clk
tx_clk
Tx Clock Domain
rx_reset
Rx Clock Domain
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
Example
1. Following example turns reporting off:
// 0in set_cdc_report scheme async_reset_no_sync severity off
2. Tx signal is used as an unsynchronized reset in the Rx domain.

// Reset triggered by tx_clk
always @(posedge tx_clk)
tx_sig <= rst;
rx domain reset
tx_sig
// Unsynchronized reset used in

// Rx domain
if (!tx_sig) rx_sig <= 1b0;
tx_clk
else rx_sig <= din;
184
din
rst
rx_sig
rx_clk

October 2011
Command Reference
async_reset_no_sync
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
tx_sig <= rst;
improperly synchronized reset

tx_sig
rst
rx_reset
rst
1'b1
// Improperly synchronized reset used

// in Rx domain
if (!tx_sig) rx_reset <= 1b0;
tx_clk
rx_clk
else rx_reset <= 1b1;
Violations
=================================================================
----------------------------------------------------------------tx_clk : start : tx_sig (test2.v : 9)
rx_clk : end : rx_reset (test.v : 10) (ID:async_reset_no_sync_85287)

October 2011
185
Command Reference
black_box
black_box
BLACK BOX: Crossing drives an instance of an inferred black box.
tx_sig
inferred
black box
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
Inferred black boxes are modules/entities containing unsupported constructs, that are not
explicitly declared as black boxes (with the set_black_box directive).
Crossing Type
control signal or data bus
Default Severity
caution
Promoted Checker
none
Examples
1. Following is an example to turn severity to violation:
// 0in set_cdc_report scheme black_box severity violation
2. Following is an example of the paths for a black box crossing (from 0in_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
// 0in set_cdc_port_domain b c -clock clk -module black box_module
186

October 2011
Command Reference
black_box
With this directive, the port domains of the black box ports are identified in 0in_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 set_cdc_port_domain
directive:
// 0in set_cdc_port_domain q -clock clk3
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
inferred black box
reset
din0
datain0
dataout
tx_clk
datain1
din1
datain2
din2
din3
datain3
clock
dout
BB
status
statout
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

0in set_cdc_port_domain
datain0
datain1
datain2
datain3
-async
-async
-clock
-clock
-module black_box
-module black_box
clock -module black_box
clock -module black_box
// Outrput port domains

// 0in set_cdc_port_domain dataout -clock clock -module black_box
// 0in set_cdc_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 boxs clock pins (not external clock signals).

October 2011
187
Command Reference
black_box
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)
188

October 2011
Command Reference
bus_custom_sync
bus_custom_sync
BUS_CUSTOM: Multiple-bit signal synchronized by custom CDC synchronizer.
gray
encoder
tx_data
tx_clk
custom
synchronizer
rx_data
gray
decoder
rx_clk
Tx Clock Domain
Rx Clock Domain
Custom synchronizers are instances of modules declared as custom synchronizers with the
set_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.
Crossing Type
data bus
Default Severity
evaluation (if all the ports are specified with set_cdc_port_domain) or violation.
Promoted Checker
none
Examples
1. Following is an example to specify the cust_sync module with clock pin clk as a custom
synchronizer:
//0in set_cdc_synchronizer custom -module cust_sync
//0in set_cdc_port_domain d -async -clock clk -module cust_sync
The set_cdc_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.
2. Following is an example to turn severity to caution:
// 0in set_cdc_report -scheme bus_custom_sync -severity caution

October 2011
189
Command Reference
bus_custom_sync
3. Custom synchronizer for the Tx signal:

// Custom sync instance
syncA S (rx_clk,tx_data,rx_data);
tx_data <= data;
tx_data
rx_data
din
dout
syncA
clk
data
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 set_cdc_synchronizer custom directive to identify custom synchronizer

modules/entities:
// 0in set_cdc_synchonizer custom -module syncA
Custom synchronizers are considered inferred black boxes for CDC analysis, so you
must specify their port information:
/* 0in set_cdc_port_domain -input din -async -clock rx_clk
-module syncA */
/* 0in set_cdc_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.
190

October 2011
Command Reference
BUS DFF GATED SYNC: Multiple-bit signals synchronized with DFF synchronizer with
gated clock.
tx_data
DFF
rx_data
DFF
en_rx_clk
tx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain
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_hamming1)
Examples
1. Following is an example to turn severity to evaluation:
/* 0in set_cdc_report -scheme bus_dff_sync_gated_clk
-severity evaluation */
2. Following is an example to turn off reporting for a particular CDC signal:

/* 0in set_cdc_report -scheme bus_dff_sync_gated_clk
-severity 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;
// 1st flip-flop triggered by
// the gated clock
always @(posedge gclk)
sync1 <= tx_reg;
tx_reg
tx_clk
sync1
gclk
en
sync2
rx_clk
// 2nd flip-flop triggered by

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

October 2011
191
Command 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)
192

October 2011
Command Reference
bus_four_latch
bus_four_latch
BUS SYNC: Multiple-bit signal synchronized by latch synchronizer.
tx_data
gray
encoder
rx_data
latch
latch
latch
latch
latch
tx_clk
gray
decoder
rx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using four latches 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 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
// 0in set_cdc_report scheme bus_four_latch severity violation
2. Following is an example to turn off promotion:

/* 0in set_cdc_report scheme bus_four_latch
-severity caution promotion off */
3. Example promoted transfer protocol checker for four_latch synchronization scheme:

// Synchronized multibit variable q
/* 0in cdc_hamming1 -tx_clock clk3 -tx_var r1
-name cdc_data_0 -module test -inferred

October 2011
*/
193
Command Reference
bus_four_latch
4. Bus four-latch synchronizer:

always @ (*)
if (rx_clk) begin
sync1 <= tx_sig;// 1st latch
tx_sig
rx_sig
sync3 <= sync2; // 3rd latch
end
tx_clk
rx_clk
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 set_cdc_report directive.
/* 0in set_cdc_report -scheme bus_four_latch
-tx_clock clk_a -severity violation */
194

October 2011
Command Reference
bus_shift_reg
bus_shift_reg
SHIFT REG: Multiple-bit signal synchronized by shift-register synchronization.
tx_data
rx_data
shift register
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using a shift register is a standard method of synchronizing a gray-coded data

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
cdc_hamming_distance_one (cdc_hamming1)
Examples
// 0in set_cdc_report scheme bus_shift_reg severity violation

// 0in set_cdc_report severity evaluation promotion off
3. Example promoted transfer protocol checker for bus_shift_reg synchronization

scheme:
/* 0in cdc_hamming_distance_one
-tx_var u0.q -tx_clock clk1
-name cdc_hamming1_0 -module dut -inferred

October 2011
*/
195
Command Reference
bus_shift_reg
4. Bus shift register synchronizer:

// 2-level shift register
always @ (posedge rx_clk)
{sync[1], sync[0]} <= {sync[0], tx_data};
[1]
sync[0]
synchronized data
tx_data
[0]
tx_clk
shift register
sync[1]
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)
196

October 2011
Command Reference
bus_two_dff
bus_two_dff
BUS SYNC: Multiple-bit signal synchronized by DFF synchronizer.
gray
encoder
tx_data
rx_data
DFF
DFF
gray
decoder
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using two flip-flops is a standard method of synchronizing a gray-coded data

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
// 0in set_cdc_report scheme bus_two_dff severity violation

// 0in set_cdc_report scheme bus_two_dff
-severity caution promotion off */
3. Example promoted transfer protocol checker for bus_two_dff synchronization scheme:

// Synchronized multibit variable U1.U1.dsyncr
/* 0in cdc_hamming1
-tx_clock clk1 -tx_var U1.U1.dinr
-name cdc_data_1 -module dut inferred */
4. Bus 2 DFF synchronizer:

reg [width-1:0] tx_reg, rx_reg;
reg [width-1:0] sync1, sync2;
always @(posedge rx_clk) begin
sync1 <= tx_reg; // 1st FF
sync2 <= sync1; // 2nd FF
end

October 2011
tx_reg
tx_clk
sync1
sync2
rx_clk
197
Command Reference
bus_two_dff
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 set_cdc_preference -allow_enable_in_sync is specified.
enable
tx_reg
sync1
sync2
EN
EN
if (enable)
begin
tx_clk
rx_clk
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)
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 set_cdc_report directive.
/* 0in set_cdc_report -scheme bus_two_dff
-tx_clock clk_a -severity violation */
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 set_cdc_synchronizer global 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:
/* 0in set_cdc_synchronizer dff -level 4
-tx_clock tx_clk -rx_clock rx_clk */
198

October 2011
Command 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.
gray
encoder
tx_data
rx_data
DFF
tx_clk
DFF
gray
decoder
rx_clk
Tx Clock Domain
Rx Clock Domain
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
cdc_hamming_distance_one (cdc_hamming1)
Examples
// 0in set_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:
tx_reg
always @(negedge rx_clk)

tx_clk
sync1
sync2
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)

October 2011
199
Command Reference
bus_two_dff_phase
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 set_cdc_preference -allow_enable_in_sync is specified.
if (enable) sync1 <= tx_reg;
if (enable) sync2 <= sync1;
enable
tx_reg
tx_clk
EN sync1 EN
sync2
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.
200

October 2011
Command Reference
combo_logic
combo_logic
COMBO LOGIC: Combinational logic before synchronizer.
combinational logic
tx_data
rx_data
synchronizer
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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 set_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):
// 0in set_constant test_sel 1'b0
2. Following is an example to turn severity for the CDC signal en to caution:

/* 0in set_cdc_report -scheme combo_logic
-severity caution -from dut.U0.en

October 2011
201
Command Reference
combo_logic
3. Combinational logic between the Tx signal and a 2DFF synchronizer:

always @ (posedge rx_clk) begin
s1 <= tx_sig & din;
s2 <= s1;
end
din
tx_sig
tx_clk
s1
DFF
s2
DFF
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 violationand instead report
the crossing as a 2DFF schemeyou can specify that din is stable. That is, it is properly
synchronized in the Rx domain:
// 0in set_cdc_signal din -stable
202

October 2011
Command Reference
custom_sync
custom_sync
SINGLE-BIT CUSTOM SYNC: Single-bit signal synchronized by custom CDC synchronizer.
tx_sig
custom
synchronizer
tx_clk
Tx Clock Domain
rx_sig
rx_clk
Rx Clock Domain
set_cdc_synchronizer custom directive. The custom_sync scheme identifies single-bit custom
synchronizers where the clock domain crossing is external to the synchronizer itself.
Crossing Type
control signal
Default Severity
violation or evaluation (if input port is asynchronous)
Promoted Checker
none (or cdc_sync/cdc_hamming1 if specified with set_cdc_protocol)
Examples
1. Following is an example to specify the cust_sync module with clock pin clk as a custom
synchronizer:
//0in set_cdc_synchronizer custom -module cust_sync
//0in set_cdc_port_domain d -async -clock clk -module cust_sync
The set_cdc_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.
// 0in set_cdc_report -scheme custom_sync -severity caution

October 2011
203
Command Reference
custom_sync
3. Custom synchronizer for the Tx signal:

syncA S (rx_clk, tx_sig, rx_sig);
data
tx_sig
din
dout
rx_sig
syncA
clk
rx_clk

tx_clk
tx_sig <= data;
Violations
=================================================================
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:
// 0in set_cdc_synchonizer custom -module syncA
/* 0in set_cdc_port_domain -input din -async -clock rx_clk
-module syncA */
/* 0in set_cdc_port_domain -output dout -clock rx_clock
-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 set_cdc_protocol directive.
204

October 2011
Command Reference
CUSTOM WITH CROSSING: Custom CDC synchronizer with an internal clock domain
crossing.
custom synchronizer
tx_data
rx_data
rx_clk
tx_clk
Tx Clock Domain
internal crossing
Rx Clock Domain
set_cdc_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 set_cdc_port_domain directive for the custom synchronizer module. Every
other signal/data port must be identified with either a transmit clock or a receive 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:
RST_A
IN
CLKA
//
//
//
//
//
0in
0in
0in
0in
0in
SYNC_VX
RST_B
OUT
CLKB
set_cdc_synchronizer custom -module SYNC_VX

set_cdc_port_domain IN -tx_clock CLKA -module SYNC_VX
set_cdc_port_domain RST_A -clock CLKA -module SYNC_VX
set_cdc_port_domain OUT -rx_clock CLKB -module SYNC_VX
set_cdc_port_domain RST_B -clock CLKB -module SYNC_VX

October 2011
205
Command Reference
2. Custom synchronizer with an internal crossing:

syncC S (
tx_clk,rx_clk,tx_sig,rx_sig);
tx_sig <= data;
data
tx_sig
tx_clk
din
dout
rx_sig
syncC
rclk
tclk
rx_clk
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:
// 0in set_cdc_synchonizer custom -module syncC
// 0in set_cdc_port_domain din -tx_clock tclk -module syncC
// 0in set_cdc_port_domain dout -rx_clock rclk -module syncC
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.
206

October 2011
Command Reference
dff_sync_gated_clk
dff_sync_gated_clk
DFF GATED SYNC: DFF synchronizer with gated clock.
tx_sig
tx_clk
DFF
DFF
rx_sig
en_rx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain
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
//0in set_cdc_report scheme dff_sync_gated_clk severity evaluation
2. Following is an example to turn off reporting for a particular CDC signal:

/* 0in set_cdc_report -scheme dff_sync_gated_clk -severity off
-from in1 -to r1
*/
3. Single-bit signal synchronized by 2DFF synchronizer with a gated clock:

// gated clock expression
tx_sig
sync2
sync1
assign gclk = rx_clk & clk_en;
DFF
DFF
always @(posedge gclk)
sync1 <= tx_sig; // 1st DFF
rx_clk
tx_clk
clk_en
sync2 <= sync1;
// 2nd DFF
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)

October 2011
207
Command Reference
dmux
dmux
DMUX: DMUX synchronization.
tx_data
MUX
rx_data
tx_clk
tx_sel
DFF
tx_clk
Tx Clock Domain
DFF
rx_sel
rx_clk
Rx Clock Domain
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
Rx registers) must not allow glitches at the input to an Rx register when the Tx register
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
Default Severity
caution
Promoted Checker
cdc_dsel
Promoted CDC-FX Checker

cdc_fx check is on by default.
208

October 2011
Command Reference
dmux
Examples
// 0in set_cdc_report -scheme dmux -severity evaluation

/* 0in set_cdc_report -scheme dmux
-severity evaluation -promotion off */
3. Example promoted transfer protocol checker for DMUX synchronization scheme:

/* 0in cdc_dsel
-tx_data isyncdbus.data_reg -tx_clock clk1
-rx_clock clk2 -tx_data_select 1'b0
-rx_data_select (isyncdbus.stage3_q ^ isyncdbus.isync.out)
-tx_min `P_clk1_clk2_tx_min
-name cdc_dsel_1 -module test -inferred */
4. 4-bit bus synchronized by a DMUX synchronizer:

begin: DMUX
reg s1, rx_sel;
s1 <= tx_sel;
// 1st DFF
rx_sel <= s1;
// 2nd DFF
if (rx_sel)
rx_data <= tx_data;
else
rx_data <= rx_data ^ 4b1111;
end
rx_data
tx_data
4b1111
tx_clk
tx_sel
MUX
s1
DFF
DFF
rx_sel
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)

October 2011
209
Command Reference
FANIN LOGIC FROM DIFFERENT CLOCKS: Fan-in logic from multiple clock domains.
sig_c
sig_a
synchronizer
clock_c
clock_a
Clock Domain A
Clock Domain C
sig_b
clock_b
Clock Domain 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 the 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 has -severity off, then both signals are two individual
combo_logic crossings. One signal is reported as a violation and the other is filtered.
more than 2 signals in the fanin of the crossing

If one signal is stable or has -severity off:
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 set_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 set_cdc_signal to identify the remaining signals coming from
that logic as stable. If you specify set_cdc_preference -filtered_report, the removed
210

October 2011
Command Reference
signals 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 set_cdc_preference filtered_report.
Crossing Type
Default Severity
violation
Promoted Checker
cdc_glitch
Examples
1.
clock domain A
sig_a
MUX
sig_b
synchronizer
clock_a
clock_b
clock domain B
test_sel
tsel
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:
// 0in set_constant test_sel 1'b0

October 2011
211
Command 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:

always @ (posedge tx1_clk)
tx1_sig <= in1;
always @ (posedge tx2_clk)
tx2_sig <= in2;
sync0 <= tx1_sig | tx2_sig;
sync1 <= sync0;
end
tx1_sig
DFF
tx1_clk
sync1
sync0
DFF
rx_clk
tx2_sig
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)
212

October 2011
Command Reference
fifo
fifo
FIFO: FIFO Synchronization.
write address
synchronizer
fifo_empty
rd_clock
waddr_gray
gray to binary
waddr
wr_data
raddr
memory
raddr_gray
gray to binary
rd_data
fifo_full
wr_clock
rd_clock
read address
synchronizer
wr_clock
FIFO write
clock domain
FIFO read
clock domain
By default, memories with read and write clocks are reported as memory_sync or multi_bits
CDC schemes. Specifying the set_cdc_preference global directive with the -fifo_scheme option
directs CDC static analysis to identify FIFO synchronization schemes like that shown above as
FIFO schemes. FIFO synchronization is used to pass 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. Transmit and receive logic calculates the number of entries in the FIFO from the read
and write address pointers. In the FIFO synchronization scheme, the gray-coded 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).
By default, CDC static analysis identifies as FIFO schemes those schemes that have different
combinations of binary and gray-coded address pointers, as shown below:
binary to gray
waddr_gray
write address
synchronizer
fifo_empty
rd_clock
waddr
raddr
wr_data
memory
rd_data
fifo_full
wr_clock
read address
synchronizer
wr_clock

October 2011
FIFO write
clock domain
rd_clock
raddr_gray
binary to gray
FIFO read
clock domain
213
Command Reference
fifo
The templates CDC static analysis uses to detect FIFO schemes can be adjusted using the
set_cdc_fifo_preference global variable (see page 269).
The memories used in the FIFO schemes can be multidimensional arrays but they must be
modeled as abstract memories (see set_memory on page 310). The memories also can be
specified using register/latch files (see set_cdc_fifo on page 268).
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.
Examples
// 0in set_cdc_preference -fifo_scheme
// 0in set_cdc_report scheme fifo severity caution
2. 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
214

October 2011
Command Reference
fifo
3. RAM-based FIFO synchronizer. CDC analysis only recognizes this instance as a fifo
scheme if set_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];
always @(posedge wr_clk) begin
Mem [wr_addr] <= wr_data;
rd_sync1 <= rd_addr ;
rd_sync2 <= rd_sync1;
full <=
((wr_addr+1)==rd_sync2)?1:0;
end
full
rd_sync2
rd_sync1
wr_clk
wr_data
wr_addr
rd_addr
memory
rd_data
rd_clk
always @(posedge rd_clk) begin

wr_sync1
wr_sync2
empty
rd_data <= Mem [rd_addr];
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:
// 0in set_cdc_port_domain wr_addr -clock wr_clk
// 0in set_cdc_port_domain rd_addr -clock rd_clk

October 2011
215
Command Reference
fifo
4. Register-file based FIFO synchronizer. CDC analysis only recognizes this instance as a
fifo scheme if set_cdc_preference -fifo_scheme is specified. Also, to detect the register
file:
// 0in set_cdc_fifo Mem1 Mem2 Mem3 Mem4
reg [2:0] wr_sync1, wr_sync2,
reg [2:0] rd_sync1, rd_sync2;
always @(posedge wr_clk) begin
case (wr_addr)
3d0: Mem1[0] <= wr_data;
endcase
rd_sync1 <= rd_addr ;
rd_sync2 <= rd_sync1;
full <=
((wr_addr+1)==rd_sync2)?1:0;
end
full
rd_sync2
rd_sync1
wr_clk
wr_data
wr_addr
rd_addr
memory
rd_data
rd_clk
wr_sync1
wr_sync2
empty
always @(posedge rd_clk) begin

case (rd_addr)
3d0: rd_data <= Mem1[0];
endcase
wr_sync1 <= wr_addr;
wr_sync2 <= wr_sync1;
empty <=
(rd_addr == wr_sync2)? 1:0;
end
Evaluations
=================================================================
----------------------------------------------------------------wr_clk : start : Mem1[0] (fifo2.v : 11) (ID:fifo_47408)
wr_clk : start : Mem1[1] (fifo2.v : 11) (ID:fifo_47412)
216

October 2011
Command Reference
fifo
----------------------------------------------------------------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)

October 2011
217
Command Reference
four_latch
four_latch
FOUR LATCH SYNCHRONIZER: Single-bit signal synchronized by latch synchronizer.
tx_sig
rx_sig
latch
latch
latch
latch
rx_clk
tx_clk
Rx Clock Domain
Tx Clock Domain
Synchronization using four latches is a standard method of synchronizing a 1-bit signal. The
end Rx signal for the synchronizer is the first latch in the synchronizer.
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
// 0in set_cdc_report -scheme four_latch -severity caution

/* 0in set_cdc_report scheme four_latch -severity evaluation
-promotion off */
3. Example promoted transfer protocol checker for four_latch synchronization scheme:

/* 0in cdc_sync
-tx_var mtr.fifo_rd -tx_clock pci_clk
-name cdc_sync_0 -module cpu_top
-inferred */
4. Four-latch synchronizer:
always @ (*)
if (rx_clk) begin
sync1 <= tx_sig;//
sync3 <= sync2; //
end
else begin
sync2 <= sync1; //
rx_sig <= sync3;//
end
218
1st latch
3rd latch
tx_sig
tx_clk
rx_sig
rx_clk
2nd latch
4th latch

October 2011
Command Reference
four_latch
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

October 2011
219
Command Reference
handshake
handshake
HANDSHAKE: Handshake synchronization.
MUX recirculation
Tx Clock Domain
ack-tx path
Rx Clock Domain
en
DEST FSM
SRC FSM
rx_clk
tx_clk
handshake loop
acknowledge synchronizer
request synchronizer
Specifying the set_cdc_preference global 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 roundtrip 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.

220

October 2011
Command Reference
handshake
Examples
// 0in set_cdc_preference -handshake_scheme
// 0in set_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:
// 0in set_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

October 2011
221
Command Reference
handshake
ack_synced
req
ack
req_synced
enable
din
tx_clk
en
tx_data
en
data flow
rx_data
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
222

October 2011
Command Reference
memory_sync
memory_sync
MEMORY SYNC: Memory Synchronization.
rd_data
memory
rd_clk
Wr Clock Domain
Rd Clock Domain
CDC synchronization using a 2D array (for example, a memory element used as a FIFO) is a
standard method of synchronizing CDC signals or data buses. CDC analysis detects CDC
crossings to and from memory, but the analysis cannot verify proper synchronization
configuration and does not promote a transfer protocol checker to verify proper synchronization
operation.
Crossing Type
Default Severity
caution
Promoted Checker
none
Examples
// 0in set_cdc_report scheme memory_sync severity evaluation
2. Following is an example to turn off reporting:

// 0in set_cdc_report scheme memory_sync severity off
3. Fanin logic from 2 clock domains:

always @(posedge wr_clk)
Mem [wr_addr] <= wr_data;
wr_data
always @(posedge rd_clk)

rd_data <= Mem [rd_addr];
Mem
rd_data
wr_clk
rd_clk
wr_addr
rd_addr
Memory Synchronization. (memory_sync)

----------------------------------------------------------------wr_clk: start: Mem (memory_sync.v : 9)
rd_clk: end: rd_data (memory_sync.v: 6) (ID:memory_sync_69262)

October 2011
223
Command Reference
memory_sync
Potential Problem
The CDC compiler currently does not perform read/write analysis, and misses the condition
where the read and write addresses are equal, which could result in unreported memory
write-through errors. Adding checkers to guard against this condition is suggested. The
compiler issues a warning (hdl105) whenever it finds an instance of a memory_sync scheme.
224

October 2011
Command Reference
multi_bits
multi_bits
MULTIPLE BITS: Multiple-bit signal across clock domain boundary.
additional logic
driven by signal
tx_data
DFF
DFF
rx_data
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
tx_data
rx_data
missing
synchronizer
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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:
/* 0in set_cdc_report -scheme multi_bits -from status_test
-severity off -module dut */

October 2011
225
Command Reference
multi_bits
2. Example promoted transfer protocol checker for multi_bits synchronization:

/* 0in cdc_sample
-tx_var u1.q -rx_var u2.q
-tx_clock clk1 -rx_clock clk2
-name cdc_data_0 -module dut -inferred
*/
3. Multibit Tx signal is read without synchronization in the Rx domain.

rx_bus <= tx_bus;
tx_bus
tx_clk
rx_bus
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)
226

October 2011
Command Reference
MULTIPLE SYNCHRONIZERS AT DMUX: MUX select fan-in contains more than one
synchronizer.
tx_data
MUX
DFF
rx_data
rx_sel
tx_sel1
DFF
DFF
rx_clk
tx_clk
tx_sel2
DFF
DFF
Tx Clock Domain
Rx Clock Domain
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_sample
Examples
/* 0in set_cdc_report -scheme multi_sync_mux_select
-severity evaluation */

/* 0in set_cdc_report -scheme multi_sync_mux_select

October 2011
227
Command Reference
3. DMUX synchronizer with multiple control signals synchronized in the Rx domain:

tx_sel1
DFF
s1_sel1
DFF
s2_sel1
rx_clk
tx_clk
s_sel2[1]
tx_sel2
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
228

October 2011
Command Reference
no_sync
no_sync
MISSING SYNCHRONIZER: Single-bit signal does not have proper synchronizer.
additional logic
driven by signal
tx_sig
DFF
DFF
rx_sig
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
tx_sig
rx_sig
missing
synchronizer
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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

Examples
1. Following is an example to turn severity to caution for the write_test signal in the
module dut:
/* 0in set_cdc_report -scheme no_sync -from write_test

October 2011
229
Command Reference
no_sync
-severity caution -module dut
*/
2. Example promoted transfer protocol checker for no_sync synchronization:

/* 0in cdc_sample
-tx_var u1.q -rx_var u2.q
-tx_clock clk1 -rx_clock clk2
-name cdc_data_0 -module dut -inferred
*/
3. Tx signal is read without synchronization in the Rx domain.

always @(posedge rx_clk, posedge rst)
if (rst)
rx_sig <= 1b1;
else
rx_sig <= tx_sig;
tx_sig
tx_clk
rx_sig
rx_clk
Violations
=================================================================
Single-bit signal does not have proper synchronizer. (no_sync)
----------------------------------------------------------------tx_clk : start : tx_sig (no_sync.v : 9)
rx_clk : end : rx_sig (no_sync.v : 9) (ID:no_sync_59042)
230

October 2011
Command Reference
PORT CONSTRAINT MISMATCH: Signal connected to a port of a custom synchronizer is in
a clock domain that is not allowed by the custom synchronizers port constraints.
illegal Tx clock domain for port
tx_sig
custom
port synchronizer
constraint
tx_clk
Tx Clock Domain
port
constraint
tx_clk
rx_clk
Rx Clock Domain
illegal Rx clock domain for port
illegal Tx clock
domain for port
tx_sig
rx_sig
illegal Rx clock
domain for port
custom synchronizer
with crossing
Tx Clock Domain
rx_sig
port
constraint
rx_clk
Rx Clock Domain
A CDC port constraint identifies all clock domains allowed for signals connected to instances of
the port. A port constraint is specified using the set_cdc_port_constraint directive. Currently
port constraints are supported only for design units that are custom synchronizers (i.e.,
identified with the set_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.

October 2011
231
Command 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:
/* 0in set_cdc_report -scheme port_constraint_mismatch
-from write_test
-severity evaluation -module prk */
232

October 2011
Command Reference
pulse_sync
pulse_sync
PULSE SYNC: Pulse Synchronization.
rx_sig
tx_sig
DFF
DFF
DFF
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
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 set_cdc_preference -delayed_pulse
directive to recognize such schemes as pulse_sync schemes.
rx_sig
tx_sig
DFF
DFF
DFF
DFF
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
Crossing Type
1-bit signal
Default Severity
evaluation
Promoted Checker
cdc_sync
Examples
// 0in set_cdc_report scheme pulse_sync severity caution

/* 0in set_cdc_report scheme pulse_sync
severity cautionpromotion off */
3. Example promoted transfer protocol checker for the pulse_sync synchronization

scheme:
/* 0in cdc_sync
-tx_var isyncabus.stage1_q -tx_clock clk1
-tx_min `P_clk1_clk2_tx_min -name cdc_sync_0
-module test -inferred */

October 2011
233
Command Reference
pulse_sync
4. Standard pulse synchronizer:

reg p0, p1, p2, pulse;
pulse
tx_sig
p0 <= tx_sig; // 1st flop
p1 <= p0;
// 2nd flop
p2 <= p1;
// 3rd flop
end
rx_clk
tx_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:

// 0in set_cdc_preference -delayed_pulse
reg p0, p1, p2, pulse, dpulse;
pulse
tx_sig
p0 <= tx_sig;
// 1st flop
dpulse
p1 <= p0;
// 2nd flop
p2 <= p1;
// 3rd flop
rx_clk
tx_clk
dpulse <= pulse;// 4th flop
end
always @ * pulse <= p1 ^ p2;
Evaluations
=================================================================
----------------------------------------------------------------tx_clk: start: tx_sig (pulse_sync.v : 8)
rx_clk: end: PULSE_SYNC.p0 (pulse_sync.v :16)(ID:pulse_sync_1845)
234

October 2011
Command Reference
reconvergence
reconvergence
RECONVERGENCE: Reconvergence of synchronizers.
sig1
tx_sig1
rx_sig
tx/rx_clk
sig2
Source Clock Domains
tx_sig2
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 skewfor 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 set_cdc_preference -dmux_as_recon_start (page 286).
Crossing Type
multiple control signals or data buses
Default Severity
caution
Promoted Checker
cdc_hamming1 (if enabled, see set_cdc_preference on page 286).

October 2011
235
Command Reference
reconvergence
Examples
1. Following is an example to disable reporting of all reconvergence points originating in
the tx_clk domain:
/* 0in set_cdc_report -scheme reconvergence
-severity off -tx_clock tx_clk */
2. Following is an example to disable reporting of all reconvergence points originating

from the cluster of synchronizers driving stat1, stat2, and stat3:
/* 0in set_cdc_report -scheme reconvergence
-severity off -from_signals stat1 stat2 stat3
*/
3. Following is an example to change the reconvergence depth to 4:

// 0in set_cdc_reconvergence -depth 4
4. Following is an example that disables reconvergence analysis to reduces run time.

// 0in set_cdc_reconvergence -check off
5. 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
always @ (posedge tx_clk) begin
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];
in1
[1]
tx1
[0]
shift_reg_sync[0]
reconvergence point
shift_reg_sync[1]
shift register
rx_clk
tx_clk
in2
tx2
two_dff_sync
temp
DFF
236
dout
DFF

October 2011
Command Reference
reconvergence
Violations
=================================================================
Reconvergence of synchronizers. (reconvergence)
----------------------------------------------------------------rx_clk : end : dout (reconvergence.v : 5) (ID:reconvergence_78116)
rx_clk : start : shift_reg_sync (reconvergence.v : 10)
(Synchronizer ID:shift_reg_39969)
rx_clk : start : two_dff_sync (reconvergence.v : 9)
(Synchronizer ID:two_dff_74368)
6. Following example shows an instance of a reconvergence scheme that is reported when

reconvergence depth is 1. To set the depth:
// 0in set_cdc_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)
rx1 <= two_dff_sync;
rx2 <= shift_reg_sync[7:4];
dout <= rx1 - rx2;
end
[7:4]
shift_reg_sync[3:0]
shift_reg_sync[7:4]
in1
rx2
tx_data1 shift register

reconvergence point
rx_clk
tx_clk
temp
in2
tx_data2 DFF
two_dff_sync
DFF
rx1
dout
Violations
=================================================================
----------------------------------------------------------------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)

October 2011
237
Command Reference
redundant
redundant
REDUNDANT: Redundant synchronization.
rx_sig1
synchronizer
tx_sig
tx_clk
Tx Clock Domain
rx_clk
synchronizer
rx_sig2
Rx Clock Domain
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
from the tx_clk domain:
/* 0in set_cdc_report -scheme redundant
-severity off -from *_en -tx_clock tx_clk
238
*/

October 2011
Command 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
[1]
sh_reg[0]
tx_sig
shift_reg.sh_reg
[0]
tx_clk
shift_reg
rx_clk
redundantly synchronized
signals
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)

October 2011
239
Command Reference
series_redundant
series_redundant
SERIES REDUNDANT: Custom synchronizers connected in series.
Tx synchronizer
Rx synchronizer
rx_sig
tx_sig
custom
synchronizer
custom
synchronizer
rx_clk
tx_clk
Tx Clock Domain
Rx Clock Domain
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 synchronizers 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.
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:
/* 0in set_cdc_report -scheme series_redundant
-severity off -from *_en -tx_clock tx_clk
240
*/

October 2011
Command 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
cust_sync_B_out
tx_data
cust_sync_A
tx_clk
cust_sync_B
rx_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)

October 2011
241
Command Reference
shift_reg
shift_reg
SHIFT REG: Shift-register synchronization.
tx_sig
rx_sig
shift register
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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
// 0in set_cdc_report scheme shift_reg severity caution

/* 0in set_cdc_report scheme shift_reg
severity caution promotion off */
3. Example promoted transfer protocol checker for shift_reg synchronization scheme:

/* 0in cdc_sync
-tx_var u0.q -tx_clock clk1
-name cdc_sync_0 -module dut -inferred
242
*/

October 2011
Command Reference
shift_reg
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
[0:6]
shift_reg_sync[1:7] synchronized signal
tx_sig
[7]
tx_clk
shift register
shift_reg_sync[8]
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)

October 2011
243
Command 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
Tx Clock Domain
rx_clk
Rx Clock Domain
The 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
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: 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.
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
Tx and Rx drivers are registers.
No combo logic is between the Tx and Rx registers.
No combo logic is between select output from the synchronizer and the MUX.
Note
The physical design of the MUX 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
244

October 2011
Command Reference
simple_dmux
Promoted Checker
cdc_dsel

Examples
// 0in set_cdc_report -scheme simple_dmux -severity evaluation

/* 0in set_cdc_report -scheme simple_dmux
3. Example promoted transfer protocol checker for simple_dmux synchronization scheme:

/* 0in cdc_dsel
-tx_data isyncdbus.data_reg -tx_clock clk1
-rx_clock clk2 -tx_data_select 1'b0
-rx_data_select (isyncdbus.stage3_q ^ isyncdbus.isync.out)
-name cdc_dsel_1 -module test -inferred */
4. Bus synchronized by a simple DMUX synchronizer:

begin: DMUX
reg s1, rx_sel;
s1 <= tx_sel;
// 1st DFF
rx_sel <= s1;
// 2nd DFF
if (rx_sel)
rx_data <= tx_data;
end
rx_data
tx_data
MUX
tx_clk
tx_sel
s1
DFF
DFF
rx_sel
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)

October 2011
245
Command Reference
SSR: Single-source reconvergence of synchronizers.
single source
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 set_cdc_reconvergence (page 294) global 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 set_cdc_reconvergence -divergence_depth <depth> enables
SSR reporting for matching divergence/reconvergence paths.
Crossing Type
246

October 2011
Command Reference
Default Severity
violation
Promoted Checker
cdc_hamming1 (if enabled, see set_cdc_preference on page 286).
Examples
1. Following is an example to disable reporting of single-source reconvergence points
originating in the tx_clk domain:
/* 0in set_cdc_report -scheme single_source_reconvergence
-severity off -tx_clock tx_clk */
2. Following is an example to disable reporting of single-source reconvergence points

originating from the cluster of synchronizers driving stat1, stat2, and stat3:
/* 0in set_cdc_report -scheme single_source_reconvergence
-severity off -from_signals stat1 stat2 stat3 */
3. Following is an example to change the reconvergence depth to 4 and enable singlesource reconvergence reporting with a divergence depth of 5:
// 0in set_cdc_reconvergence -depth 4 -divergence_depth 5
4. Following examples change the reconvergence depth and and enable single-source
reconvergence reporting:
depth = 1
divergence depth = 2
synchronizer
synchronizer
synchronizer
Tx Clock Domain

October 2011
Rx Clock Domain
reported single-source
reconvergence paths
247
Command Reference
depth = 2
divergence
depth = 1
synchronizer
synchronizer
synchronizer
Tx Clock Domain
reported single-source
reconvergence paths
Rx Clock Domain
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:
// 0in set_cdc_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
[1]
ctrl
[0]
shift_reg_sync[0]
reconvergence point
shift_reg_sync[1]
shift register
rx_clk
tx_clk
248
dout
DFF
DFF
two_dff_sync

October 2011
Command Reference
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 (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:
The following code shows the divergence and reconvergence points and the two
synchronizers on the reconverging paths.
// divergence point
diverge <= diverge + 1;
tx_data1 <= din + diverge;
tx_data2 <= ~diverge;
end
// 1 level to sync
// 0 levels to sync
// 0 levels to sync
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
diverge
[7:4]
[3:0]
tx_data2
shift_reg_sync[3:0]
bus shift
register
reconvergence point
shift_reg_sync[7:4]
rx_clk
tx_clk
din
dout
+
tx_data1

October 2011
DFF
DFF
two_dff_sync
249
Command Reference
(single_source_reconvergence)
----------------------------------------------------------------rx_clk : end : dout (single_source_reconvergence.v : 5)
(ID:single_source_reconvergence_84301)
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)
tx_clk : diverge : diverge (single_source_reconvergence.v : 8)
250

October 2011
Command Reference
two_dff
two_dff
TWO DFF SYNCHRONIZER: Single-bit signal synchronized by DFF synchronizer.
tx_sig
rx_sig
DFF
DFF
tx_clk
Tx Clock Domain
rx_clk
Rx Clock Domain
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
// 0in set_cdc_report scheme two_dff severity caution

/* 0in set_cdc_report scheme two_dff
severity caution promotion off */
3. Example promoted transfer protocol checker for the two_dff synchronization scheme:
/* 0in cdc_sync
-tx_var mtr.fifo_rd -tx_clock pci_clk
-tx_min `P_pci_clk_cpu_clk_tx_min
-name cdc_sync_0 -module cpu_top
-inferred */
4. Single-bit signal synchronized by two cascaded flip-flops:

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

October 2011
251
Command Reference
two_dff
5. Single-bit signal synchronized by two cascaded flip-flops with enable ports:

// 0in set_cdc_preference -allow_enable_in_sync
if (enable)
{s0, s1} <= {tx_sig, s0};
tx_sig
EN
EN
s0
tx_clk
enable
s1
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 set_cdc_synchronizer directive
(page 304). For example, the following CDC global directive identifies 4 DFF synchronizers as
valid two_dff schemes for CDC paths from the tx_clk domain to the rx_clk domain:
/* 0in set_cdc_synchronizer dff -level 4
-tx_clock tx_clk -rx_clock rx_clk */
252

October 2011
Command 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
tx_clk
Tx Clock Domain
DFF
rx_clk
Rx Clock Domain
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
// 0in set_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:
sync1 <= tx_sig; // 1st FF
tx_sig
tx_clk
sync1
sync2
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)

October 2011
253
Command Reference
Global Directives
Global Directives
Global directives configure and control the Questa CDC/Formal tools. This section has
descriptions of the use of primitives and wildcards in global directives, followed by data sheets
for the global directives.
0-In Comments
To use global directives, you place them inside 0-In comments in control files. A control file is a
text file containing a Verilog module or VHDL design unit.
Note
Global directives specified outside a Verilog module or VHDL design unit are
ignored.
0-In comments have a similar structure as generic HDL comments, but start with the identifier
0in. You can include multiple directives in the same 0-In comment, if you separate them by
semicolons. Everything within a 0-In comment is meaningful to the Questa compilers. The
contents are interpreted as one or more directives. You cannot include a 0-In comment inside an
HDL comment.
The Questa compilers read two types of 0-In comments:
Single-line 0-In comments

Verilog single-line 0-In comments begin with // 0in. VHDL single-line 0-In comments
begin with -- 0in. Single-line 0-In comments are effective to the end of the line. You can
include a single-line HDL comment inside a single-line 0-In comment.
// 0in set_black_box modX // Black box modX module
-- 0in set_black_box entityX -- Black box entityX entity
Block 0-In comments

Verilog block 0-In comments begin with /* 0in and are effective until the terminator */.
VHDL block 0-In comments start each line with -- 0in. A new line in a block 0-In
comment is treated as whitespace. Both the 0in keyword and the global directive name
must be specified on the first line of a block 0-In comment. You cannot include HDL
comments inside block 0-In comments. For example:
/* 0in set_cdc_report -scheme black_box
-from out2a -to bb1.* -severity off
*/
-- 0in set_cdc_report -scheme black_box

-- 0in
-from out2a -to bb1.* -severity off
254

October 2011
Command Reference
Global Directives
0-In Primitives
Expressions in 0-In directives are HDL expressions that can include 0-In primitives.
Expressions represent signals derived from other signals or expressions that evaluate to signals.
0-In primitives can refer to signals or expressions that evaluate to signals, including other
primitives. Expressions can combine HDL expressions and 0-In primitives using HDL
operators and parentheses for grouping. 0-In primitives are expressions. Expressions in
directives must be enclosed in parentheses. The 0-In primitives are: $0in_rising_edge,
$0in_falling_edge, $0in_0_to_1, $0in_1_to_0, $0in_delay, and $0in_spy. The
$0in_rising_edge and $0in_falling_edge primitives use Verilog posedge/negedge semantics,
which accounts for transitions involving X. The $0in_0_to_1 and $0in_1_to_0 primitives do not
account for transitions involving X.
$0in_0_to_1(expression [,clock])
clock
sig
($0in_0_to_1(sig, clock))
Signal that asserts when expression

transitions from 0 to 1. The signal
de-asserts when expression deasserts or at the active edge of the
clock, whichever comes first.
$0in_1_to_0(expression [,clock])
clock
sig
($0in_1_t0_0(sig, clock))

transitions from 1 to 0. The signal
de-asserts when expression asserts
or at the active edge of the clock,
whichever comes first.
$0in_rising_edge(expression [,clock])
transitions from 0 to 1/X or from X
to 1. The signal de-asserts when
sig_a
expression transitions again or at
the active edge of the clock,
($0in_rising_edge(sig_a, clock)) whichever comes first.
clock
sig_b
($0in_rising_edge(sig_b, clock))
sig_c
($0in_rising_edge(sig_c, clock))

October 2011
255
Command Reference
Global Directives
$0in_falling_edge(expression [,clock])
transitions from 1 to 0/X or from X
to 0. The signal de-asserts when
sig_a
expression transitions again or at
($0in_falling_edge(sig_a, clock)) the active edge of the clock,
whichever comes first.
clock
sig_b
($0in_falling_edge(sig_b, clock))
sig_c
($0in_falling_edge(sig_c, clock))
$0in_delay(expression [, number_of_cycles [,clock]])

sig
n cycles
($0in_delay(sig, n, clock))
Signal derived from the signal

specified by expression, delayed by
the specified number of clock
cycles. The default clock is inferred
from expression if it is possible.
Otherwise, the clock is inferred
from the directive.
$0in_spy(name [, number])
Using $0in_spy simplifies the file list, which can reduce the runtime and memory footprint.
This primitive allows specifying hierarchical names that might be outside of the file list given to
the compiler. The representation is a signal whose name is name and whose bit-width is number
(default 1). The compiler does not try to resolve this signal in the file list, and prints it out "as is"
in the checker logic.
For example,
// 0in set_reset -default $0in_spy(top.rst)
Assumes that top.rst signal is 1 bit and hooks up to the resets of checkers, even if top is not
given in the filelist. Compare this with the following:
// 0in set_reset -default top.rst
This results in a warning/error with an unresolved signal on top.rst if the module top is not
given in the filelist. Following is another example:
// 0in one_hot -var $0in_spy(tb.u0.a.b.c, 8) -clock clk
256

October 2011
Command Reference
Global Directives
This puts a one_hot checker on an 8-bit tb.u0.a.b.c signal even if the compiler does not find it in
the file list. If tb.u0.a.b.c does not exist or is not 8 bits wide, the simulator generates an error or
reports width-mismatch warnings.
The primitive peeks a signed signal into an unsigned vector. For example,
$0in_spy(a.b.c, w);
is mapped to
wire [w-1:0] sg_123 = a.b.c;
Hierarchical Paths
Directives in a control file that do not specify a -module argument (i.e., at the top level) specify
signals with the complete hierarchical paths. Directives in a control file that specify a -module
argument or set_clock/set_reset directives in a module/architecture (i.e., at a lower level)
specify signals relative to the local module/architecture.
Example 1
// G1 is the top level; m1_dut is an instance of M1
//0in set_constant G1.F1[0].I0.F2[0].m1_dut.x 1b1 -module M1
Generates a warning because it specifies an absolute path for x. The directive is skipped.
Example 2
// G1 is the top level; m1_dut is an instance of M1
//0in set_constant x 1b1 -module M1
Matches
G1.F1[0].I0.F2[0].m1_dut.x
Wildcards in Directive Arguments

Wildcards (*) are supported in many global directive arguments. Typically values that support
wildcards are called patterns in the argument descriptions (whereas, values that do not support
wildcards are specified as simply variables, signals or values). In general, signal names and
module names in global directives support wildcards. Clock group names do not.
Path separators are matches for wildcards (see Example 2).

October 2011
257
Command Reference
Global Directives
Example 1
G1.*.*.F3[0].*.clk* 1b0
Matches the following specifications. In this example, the bold * matches multiple
hierarchical levels.
G1.F1[6].I1.F3[0].m1_dut.clk1
G1.F1[6].I1.F3[0].m2_dut.clk2
G1.F1[6].I1.F3[0].sync_dut.clk2
G1.F1[6].I1.F3[0].sync_dut.dmux_dut.clk
G1.F1[6].I1.F3[0].sync_dut.dmux_dut.dff.clk
Example 2
G1.*
Matches all signals below G1 (i.e., any signal with a hierarchy depth > 0 from G1).
Example 3
G1.*.*.*
Matches all signals with a hierarchy depth > 3 from G1, such as:
G1.F1[6].I1.F3[2].m2_dut.int_x
G1.F1[6].I1.F3[2].m2_dut.mem_in
G1.F1[6].I1.F3[2].sync_dut.bus_in
Example 4
See the CDC Settings Report to see how wildcards are expanded, for example:
*****************************************************************
Section D: Wildcard Expansion for Global Directives
*****************************************************************
Wildcards for set_cdc_port_domain directive
----------------------------------------------------------------File mixed1_ctrl.v : Line 2
*in* matches
vhdl_inst.in1
vhdl_in
v2k_in
Wildcards for set_cdc_signal directive
vhdl_inst.*c_enum matches
vhdl_inst.rec_enum
258

October 2011
Command Reference
Global Directives
Directive Order
Directive order is important in processing directives (especially directives with wildcard
arguments). Directives are processed in order and directives that conflict with preceding
directives are completely or partially skipped. For the following example, module moda has
inputs in1, in2, in3 and in4:
// 0in set_cdc_port_domain -clock clk_a -module moda in1
// 0in set_cdc_port_domain -clock clk_b -module moda in2
// 0in set_cdc_port_domain -clock clk_c -module moda -input *
Since the last directive matches in1 and in2 (which were assigned in the previous directives), it
generates the following warnings:
Warning : Multiple clocks defined for
[File .../dut_ctrl.v, Line
: Port will be ignored in the
port. Port insta.in1,

54] and
56].[directive-248]
second directive.
55] and
56].[directive-248]
second directive.
The directives assign in1 to clk_a domain, in2 to clk_b domain, and in3/in4 to clk_c domain
which is probably the intended resultso you do not need to modify the directives. But,
suppose you swap the directive order as shown in the following specification:
// 0in set_cdc_port_domain -clock clk_c -module moda -input *
// 0in set_cdc_port_domain -clock clk_a -module moda in1
// 0in set_cdc_port_domain -clock clk_b -module moda in2
The first directive assigns all input ports (in1/in2/in3/in4) to clk_c domain. The second directive
produces the following warning:

54] and
55].[directive-248]
second directive.
and the third directive produces:


54] and
56].[directive-248]
second directive.
The second and third directives are completely vacuous and are totally ignored, which is
certainly not what you intended. Here, you must modify the order of the directives (or remove
the second and third directives).

October 2011
259
Command Reference
Directives for CDC Analysis

Table 6-2 shows the global directives used for static and dynamic CDC analysis. Additional
directives used to configure and control assertion logic in simulation and the formal models in
formal analysis are also relevant to CDC verification. They are described in Directives for
Checker Generation on page 315.
Table 6-2. Global Directives for CDC Analysis
Type
Directive
Description
Wildcard Args
Clocks and
Domains
set_cdc_clock
Specifies clocks with their

characteristics.
clock
-module
set_cdc_port_domain
Indicates the specified ports belong to

a specified clock domain, are
asynchronous to all identified clock
domains or should be ignored.
port
-same_clock
-combo_path
-module
set_cdc_port_constraint
Sets CDC port constraints for design module

-ports
units identified as custom
synchronizers.
set_reset
Identifies reset signals or removes

signal
them from the list of inferred signals. -module
set_cdc_signal
Reclassifies the CDC signal type of

specified CDC signals or adds
properties to specified CDC signals.
set_cdc_preference
Sets preferences for CDC static

analysis.
CDC
Analysis
signal
-module
set_cdc_hier_preference Sets preferences for hierarchical CDC

analysis.
CDC
Schemes
260
set_mode
Sets an operational mode for modal

analysis.
-set signal
set_mode_control
Identifies legal values for the specified signal

mode control signals.
error_on
Changes the conditions for returning

an error.
set_cdc_synchronizer
Identifies non-standard synchronizer -clock

-module
types and their corresponding
properties.
set_cdc_report
Sets the severity level and promotion -from

-through
property of matching clock domain
-to
crossings.
-module

October 2011
Command Reference
Type
Directive
Description
Wildcard Args
set_cdc_report_comment Adds a user-specified comment to the

CDC report.
set_cdc_fifo
Identifies FIFOs for fifo scheme

recognition from register files and
latch files.
set_cdc_fifo_preference
Sets preferences for CDC FIFO

schemes, if they are enabled in CDC
static analysis.
register
-module
set_cdc_handshake_prefe Sets preferences for CDC handshake

rence
schemes, if they are enabled in CDC
static analysis.
Sets preferences for CDC

reconvergence schemes, if they are
enabled in CDC static analysis.
Checker
Promotion
set_cdc_protocol
Identifies a CDC protocol checker

type to promote for one or more
custom synchronizer modules.
CDC-FX
set_cdc_fx_metastability Sets the metastability window for one

_window
or more pairs of CDC-FX clocks.
Netlist
Generation
-module
set_cdc_fx_timescale
Sets the timescale for CDC-FX logic.
set_cdc_fx_check
Turns on cdc_fx checks.
set_black_box
Identifies modules/entities as black

boxes.
module
set_memory
Sets the memory model types for

specified multidimensional arrays.
mem
-module
set_constant
Identifies the specified variable (port signal

-module
or internal variable) as having the
specified constant value.
set_constant_propagation Propagates constants through

sequential logic.

October 2011
261
Command Reference
error_on
error_on
Changes the conditions for returning an error.
Syntax
error_on
[-inferred {black_box | clock | reset | control_point}]
[-unspecified clock_waveform] [-abstracted memory] [-warning_limit limit]
-inferred {black_box | clock | reset | control_point}

Return an error if the compiler creates the specified type of inferred object:
black box inferred black boxes do not have set_black_box directives.
clock inferred clocks do not have set_clock directives.
reset ignored by 0in_autocheck and csl.
control_point for example control points inserted to break combo loops, or

registers without base clocks, or multiply driven registers. Ignored by cdc.
-unspecified clock_waveform
Return an error if the compiler encounters a clock without a waveform specification. A
waveform specification is a set_clock directive with the following form:
//0in set_clock clk2 -period 30 -waveform 0 15
It can also have the following form:

//0in set_clock clk2 -period 20
which specifies the value -waveform 0 10 by default. This option is ignored by cdc.
-abstracted memory
Return an error if any memory is abstracted (even when it is specifically abstracted with the
set_memory -abstract directive). Ignored by cdc.
-warning_limit limit
Return an error when the number of warnings exceeds limit. Ignored by 0in_autocheck and
csl. Default: no warning limit.
Description
Sets additional conditions for which the tool (cdc, csl or 0in_autocheck) returns errors. The
-inferred, -unspecified and -abstracted options change the severities of their associated
instances from warnings to errors. The -warning_limit option returns an error when the number
of warnings exceeds the warning limit.
An error prevents the flow from proceeding to the analysis phase, whereas warnings do not.
262

October 2011
Command Reference
error_on
Examples
Example 1
// 0in error_on -inferred black_box -abstracted memory
Errors out if a black box is inferred (for example, if an unsupported construct is in the design
unit). Errors out if a memory is abstracted.

October 2011
263
Command Reference
set_black_box
set_black_box
Identifies modules/entities as black boxes.
Syntax
set_black_box module [-dont_use_outputs]
module
Module/entity names or wildcard patterns.
-dont_use_outputs
Questa Formal argument ignored for CDC.
Description
The cdc compiler skips netlist elaboration of black boxes and their children. Typically
modules/entities declared as user-defined black boxes contain unsupported constructs so the
compiler would infer them as black boxes anyway. However, CDC analysis treats inferred and
user-defined black box modules differently:
264
User-defined black box.
No black_box schemes are reported for the ports.
If the clock domain for a port is specified (using a set_cdc_port_domain directive),

the port is included in CDC analysis. Otherwise, fanin/fanout logic of the port is
ignored. No CDC crossing is reported for the port, but a warning is issued.
Ports asynchronous with the defined clocks should be identified as such using the
-async argument.
Inferred black box.
A black_box scheme (with caution severity by default) is reported for each input.
Each output port is automatically marked as an async port (no set_cdc_port_domain

global directive is needed). The port is considered a transmit source for a CDC
crossing, so it is reported as the source of a synchronized or unsynchronized path.

October 2011
Command Reference
set_cdc_clock
set_cdc_clock
Specifies clocks with their characteristics and redefines the clock domains.
Syntax
set_cdc_clock clock_signal
[[posedge] [negedge] [waveform risingTime fallingTime] [period value] [virtual]
[mode mode] [group group]
| ignore | remove]
[-jitter_percent number] [module module_pattern]
clock_signal
Clock signal names or wildcard patterns. Clock signals can be primary ports or hierarchical
paths to clock signals. Clock signals can be individual bits of clock vectors.
-posedge
Clock signals have positive active edges. Default: -posedge.
-negedge
Clock signals have negative active edges.
-waveform rising_Time falling_Time

Rising edge and falling edge times (in time units) that define the clock duty cycle. This
argument is ignored.
-period value
Clock period in time units. This value is used to calculate directive parameters for promoted
checkers.
-virtual
Clock signals are virtual clocks used to identify clocks from ports that do not exist in the
DUT. For example, specify -virtual for a port associated with a clock that is not an input to
the design.
-mode mode
Mode for which this directive applies when running modal analysis. The directive is skipped
unless you are running CDC modal analysis in the specified mode. Default: directive is
recognized in all modes and for non-modal CDC analysis.
-group group
Clock group containing the specified clocks. All specified clocks are considered to be in the
clock domain corresponding to the group. You can specify multiple set_cdc_clock global
directives with the same -group name (for example, to identify clocks in the same domain
that have different clock characteristics). Default: specified clocks are associated with a
single unnamed default clock group.

October 2011
265
Command Reference
set_cdc_clock
-ignore
Add the specified clocks to the list of ignored clocks. Typical usage is to run cdc
-report_clock to identify the clocks in the design. Then, use set_cdc_clock -ignore to mark
specific clocks to be ignored. Registers in the domains of ignored clocks are not used in
CDC analysis. So, marking superfluous clocks as ignored can help improve performance.
The 0in_cdc_design.rpt reports Ignore Clock Tree section lists the clocks marked as
ignored. If both -ignore and -group are specified, the named clocks are added to the
specified clock group and all clocks in that group are added to the list of ignored clocks.
Default: specified clocks are added to the specified (or default) clock group.
-remove
Remove clock_signals from the clock tree. Default: specified clocks are added to the
specified (or default) clock group.
-jitter_percent number
Proportion of the clock cycle that clock edges can jitter. The percent must be <100. Used to
calculate tx_min:
jitter
rx_clk_period 1 + -----------
100
tx_min = int(------------------------------------------------------------------) + 1
jitter
tx_clk_period 1 -----------
100
Default: jitter = 0.
rx_clk_period
tx_min = int(---------------------------------) + 1
tx_clk_period
-module module_pattern
Clock signal names are specified relative to the module matching module_pattern. If
multiple modules match module_pattern, then the matching clock_signals in the matching
modules are grouped in the same clock group. Default: clock signal names are hierarchical
from the top level.
Description
Specifies clocks with their characteristics and redefines clock domains. You must specify a
clock signal pattern that matches at least one clock signal and no two set_cdc_clock global
directives can specify the same clock. Clocks can be bits of multiple-bit variables.
The set_cdc_clock directives without the -module option are processed in the order of entries in
the control file. Then the set_cdc_clock directives with the -module option are processed in the
order of entries in the control file. Wildcard matches do not take precedence over exact
matches.
266

October 2011
Command Reference
set_cdc_clock
Examples
module cdc_ctrl;
// 0in set_cdc_clock U0.clk U1.clk -period 100 -group A
// 0in set_cdc_clock U0.clk[2] U1.clk[2] -period 50 -group A
endmodule
Creates a single clock domain A.

module myctrl;
// 0in set_cdc_clock ctrl.vclk -virtual
// 0in set_cdc_port_domain din -clock ctrl.vclk
endmodule
Identifies a virtual clock:

module ctrl;
// 0in set_cdc_clock
endmodule
clkA
clkB
clkC -ignore
clkD -ignore
Design has four clocks (clkA, clkB, clkC, and clkD), but user wants to restrict analysis to
crossings between clkA and clkB. The clkC and clkD clocks are ignored. Only crossings
between clkA and clkB are reported in 0in_cdc.rpt.
module ctrl;
// 0in set_cdc_clock clk* -group G1
endmodule
The wildcard pattern clk* is expanded and matching signals are added to the G1 clock
group. The list of wildcard expanded signals are reported in 0in_cdc_setting.rpt:
Wildcards for set_cdc_clock directive
----------------------------------------------------------------File t11_ctrl.v : Line 3
----------------------------------------------------------------clk* matches
clk1
clk2
// 0in set_cdc_clock clkA -virtual
// 0in set_cdc_port_domain sigA -clock clkA
sigA
clk_B
clkA
DUT
Example of virtual clocks. Signal sigA is associated with clock clkA (which is outside
the DUT).
October 2011
267
Command Reference
set_cdc_fifo
set_cdc_fifo
Identifies FIFOs for fifo scheme recognition from register files and latch files.
Syntax
set_cdc_fifo
register_pattern [module module_pattern] [mode mode]
register_pattern
Name pattern for the FIFO registers (or latches).
module module_pattern
Name pattern for the modules containing the registers to match. Default: top module.
mode mode
Mode to which the FIFO identification belongs. Default: all modes.
Description
Identifies FIFOs defined in register files (or latch files) for analysis of FIFO synchronization
schemes.
Examples
//0in set_cdc_fifo -module reg_file_fifo_* reg*
268

October 2011
Command Reference
Sets preferences for FIFO CDC schemes, if they are enabled in CDC static analysis.
Syntax
[-no_write_sync] [-no_read_sync] [-multiple_write_syncs] [-multiple_read_syncs]
-no_write_sync
Reports as fifo schemes those memory_sync schemes that are FIFO schemes without a write
address synchronizer. Default: such schemes are reported as memory_sync schemes.
-no_read_sync
Reports as fifo schemes those memory_sync schemes that are FIFO schemes without a read
address synchronizer. Default: such schemes are reported as memory_sync schemes.
-multiple_write_syncs
Reports all write address synchronizers and promotes cdc_hamming_distance_one checkers
for them. Default: if the FIFO scheme has multiple write address synchronizers, only one of
them is reported.
-multiple_read_syncs
Reports all read address synchronizers and promotes cdc_hamming_distance_one checkers
for them. Default: if the FIFO scheme has multiple read address synchronizers, only one of
them is reported.
Description
Changes the template used to detect fifo CDC schemes.

October 2011
269
Command Reference
set_cdc_fx_check
set_cdc_fx_check
Turns on/off cdc_fx checkers checks.
Syntax
set_cdc_fx_check
[-scheme scheme] [-tx_clock clock_signal] [-rx_clock clock_signal] [-fx]
[-glitch_swallowed] [-glitch_caught]
-scheme scheme
The -scheme option restricts the directive to those cdc_fx checkers connected to
synchronizers of the specified type
-tx_clock clock
The -tx_clock option restricts the directive to those cdc_fx checkers with the specified
transmit clock.
-rx_clock clock
The -rx_clock option restricts the directive to those cdc_fx checkers with the specified
receive clock.
-fx, -glitch_swallowed, -glitch_caught

FX checks to turn on for the matching scheme instances.
-fx Turns on the FX check. Default: FX check is on for multi_bits, dmux,

simple_dmux, multi_sync_mux_select, handshake and no_sync schemes only.
-glitch_swallowed Turns on the glitch_swallowed check, which ensures that

metastability injection does not swallow a glitch detected by simulation. Default:
off.
-glitch_caught Turns on the glitch_caught check, which ensures that

metastability injection does not catch a glitch undetected by simulation. Default: off.
Description
The -fx option to cdc generates CDC-FX checkers with metastability injection logic. The CDCFX checkers have three checks: fx, glitch_swallowed and glitch_caught. By default, the fx
checks are on for multi_bits, dmux, simple_dmux, multi_sync_mux_select, handshake and
no_sync schemes. For other CDC schemes the fx checks are default off. For all schemes, the
glitch_swallowed and glitch_caught checks are default off.
Use the set_cdc_fx_check directive to override these default switches. For example, to turn on
the fx, glitch_swallowed and glitch_caught checks for all instances of the dmux scheme:
set_cdc_fx_check -scheme dmux -fx -glitch_swallowed -glitch_caught
To turn off all FX checks (yet still perform metastability injection) for all instances of the dmux
scheme:
set_cdc_fx_check -scheme dmux
270

October 2011
Command Reference
Sets the metastability window for the CDC-FX clocks.
Syntax
{-start value -stop value [-percent] | -small | -medium | -large}
[-tx_clock clock_signal] [-rx_clock clock_signal]
-start value
Number of time units (or percent of the window duration) before the active receive clock
edge that the associated metastability window opens.
-stop value
Number of time units (or percent of the window duration) after the active receive clock edge
that the associated metastability window closes. Cannot be negative.
-percent
The -start and -stop values are percentages of the Rx clock, (rather than absolute numbers).
-small | -medium | -large

Window size: -small is (start=25%, stop=10%); -medium is (start=35%, stop=30%); -large
is (start=50%, stop=50%).
-tx_clock clock_signal
-rx_clock clock_signal
Description
Sets the metastability window for the CDC-FX clocks. See set_cdc_fx_metastability_window
on page 163 for additional information. You can specify the metastability window as a
percentage of the Rx clock rather than an absolute value.
Example
Following is an example of setting the metastability window as a percentage:
// 0in set_cdc_fx_metastability_window -start 10 -stop 5 -percent
In this example, start is 10% of the Rx clock and stop is 5% of the Rx clock.

October 2011
271
Command Reference
Sets the timescale for CDC-FX logic.
Syntax
set_cdc_fx_timescale unit/precision
unit
Time unit (in ns, ps or fs).
precision
Precision (in ns, ps or fs).
Description
By default, the timescale at the end of the testbench files is used for CDC-FX logic. Use
set_cdc_fx_timescale to override the default.
Example
set_cdc_fx_timescale 1ns/10ps
272

October 2011
Command Reference
set_cdc_handshake_preference
Sets preferences for handshake CDC schemes, if they are enabled in CDC static analysis.
Syntax
[req_unsync] [ack_unsync] [skip_ack_tx_path]
[check_mux_recirculation] [handshake_effort {medium | high}]
Tx Clock Domain
ack-tx path
Rx Clock Domain
MUX recirculation
en
DEST FSM
SRC FSM
rx_clk
tx_clk
handshake loop
acknowledge synchronizer
request synchronizer
req_unsync
Reports handshake schemes that do not have a synchronizer for the request path in the
handshake loop.
ack_unsync
Reports handshake schemes that do not have a synchronizer for the acknowledge path in the
handshake loop.
-skip_ack_tx_path
Reports handshake schemes that do not have a connection from the acknowledge path of the
handshake loop to the Tx logic.
-check_mux_recirculation
Only reports handshake schemes that include a MUX recirculation path from the receiver.
-handshake_effort {medium | high}

Increases the effort spent to detect the req/ack loops of suspected handshake schemes at the
expense of increased runtime. Default: low.
Description
Changes the template used to detect handshake CDC schemes. Handshake schemes are
distinguished from simple MUX schemes when a set_cdc_preference directive specifies the
-handshake_scheme option. The set_cdc_handshake_preference options select the elements of
the logic template used to identify handshake schemes.
October 2011
273
Command Reference
set_cdc_hier_preference
Sets preferences for hierarchical CDC analysis.
Syntax
set_cdc_hier_preference [-ctrl_file_models] [-propagate_global_directives]
-ctrl_file_models
Generate a control file model (CFM) for block-level analysis in addition to the interface
logic model (ILM). Default: only the ILM is generated. Missing ILMs are treated as black
boxes during top-level analysis.
-propagate_global_directives
Propagate all global directives in control files specified to cdc -report_constraints to the
hierarchical block control files. This option expands and distributes wildcard patterns
through the hierarchy, but also decreases performance. Default: faster heuristic algorithm
propagates global directives to the block-level control files. Certain directives are skipped.
Description
During block-level analysis, cdc generates a CDC interface logic model (ILM) of the block for
use in top-level CDC analysis. Specifying -ctrl_file_models at the block level also generates a
CDC control file model named 0in_cdc_hier_block_ctrl.v (see Control File Models on
page 131). If you specify set_cdc_hier_preference -ctrl_file_models in a top-level CDC control
file, the directive is propagated to the block levels via the hierarchical control files (during
report constraints). However, it is not necessary to specify this directive for the top-level
analysis run.
Examples
The following steps generate a control file model for block2 and use the control file model for
block2 in the top-level analysis. Assume block1 and block3 have already been analyzed and
interface logic models for them exist in the default cache directories.
1. Ensure set_cdc_hier_preference -ctrl_file_models directives are specified for the blocklevel analyses.
shell prompt> more 0in_hier/block2/block2_ctrl.v
. . .
// 0in set_cdc_hier_preference -ctrl_file_models
2. Run block-level CDC analysis.

shell prompt> 0in -cmd cdc -d top -od 0in_hier/block2 \
-ctrl 0in_cdc_hier_constraints_block2_ctrl.v -hier_block blk2 \
0in_hier/block2/block2_ctrl.v
274

October 2011
Command Reference
3. Run top-level CDC analysis specifying the control file model generated in step 2.
shell prompt> 0in -cmd cdc -d top -od 0in_hier/top \
-ctrl 0in_hier/top/top_ctrl.v \
-hier_cache 0in_hier/blk1/0in_cache 0in_hier/blk3/0in_cache \
-hier_ctrl_file_model blk2 0in_cdc_hier_block2_ctrl.v

October 2011
275
Command Reference
Sets CDC port constraints for design units identified as custom synchronizers.
Syntax
module_pattern -ports port_pattern
[-tx_clock_groups clock_group] [-rx_clock_groups clock_group]
[-clock_group_pair tx_clock_group rx_clock_group]
module_pattern
One or more custom synchronizer design units.
-ports port_pattern
Ports used to determine the constraints.
-tx_clock_groups clock_group
Clock groups allowed for the transmitting domain.
-rx_clock_groups clock_group
Clock groups allowed for the receiving domain.
-clock_group_pair tx_clock_group rx_clock_group

Tx/Rx clock domain pairs allowed.
Description
CDC port constraints are restrictions on which clock domains are allowed for signals that
connect to ports of instances of a design unit. The set_cdc_port_constraint directive assigns
CDC constraints to ports of design units. Currently, CDC port constraints are supported only for
custom synchronizers (i.e., design units identified with set_cdc_synchronizer custom
directives). CDC analysis reports custom synchronizer ports that violate their port constraints as
port_constraint_mismatch violations.
The module_pattern argument identifies the design units (which must be custom synchronizers)
for the directive. Each matching design unit should have one or more ports with names that
match the -ports port_pattern argument or a warning is issued for that design unit.
How you specify port constraints depends on the type of custom synchronizer:
custom_sync
Use a single directive. Specify one or more input ports with the -ports argument. Use
-tx_clock_groups to specify valid clock domains for signals connected to the inputs. Use
-rx_clock_groups to specify valid clock domains for clocks that synchronize the signals
connected to these inputs. Use -clock_group_pair arguments to identify valid pairs of
clock domains associated with these input ports.
276

October 2011
Command Reference
Use two directives. For the first directive, specify one or more input ports using the
-ports argument and use -tx_clock_groups to specify valid clock domains for signals
connected to these inputs. For the other directive, specify one or more output ports with
the -ports argument and use -rx_clock_groups to specify valid clock domains for signals
connected to these outputs. Do not use the -clock_group_pair argument.
The clock_group arguments must be specified as clock groups at the top level (as specified in
the User-specified Clock Groups and Inferred Clock Groups tables of 0in_cdc_design.rpt).
They are not clocks specified with respect to the design units specified by module_pattern.
Examples
Example 1
// 0in set_cdc_synchronizer custom -module sync_2dff
// 0in set_cdc_port_domain -module sync_2dff IN -clock clks_slow
Identifies sync_2dff and sync_3dff as custom synchronizers.

/* 0in set_cdc_port_constraint sync_2dff -ports IN
-rx_clock_groups clks_slow */
// 0in set_cdc_port_domain -module sync_2dff IN -clock clks_slow
Restricts signals connected to the IN port of sync_2dff to the domain of clock group
clks_slow.
-rx_clock_groups clks_fast */
// 0in set_cdc_port_domain -module sync_3dff IN -clock clks_fast
Restricts signals connected to the IN port of sync_3dff to the domain of clock group
clks_fast.
Example 2
// 0in set_cdc_port_domain -module sync_2dff IN -clock clk1
-rx_clock_groups clk1 clk2
-clock_group_pair clk3 clk5
-clock_group_pair clk4 clk6 */
Restricts signals connected to the IN port of sync_2dff to the domains of the following
clock groups:
clk1
clk2
clk5 (but only if the IN port of the sync_2dff instance is clocked by clk3)
clk6 (but only if the IN port of the sync_2dff instance is clocked by clk4)

October 2011
277
Command Reference
Note that the allowed domains are additive. That is, sync_2dff can legally synchronize a
crossing from clk1, even if IN is clocked by clk5.
Example 3
// 0in set_cdc_synchronizer custom -module syncx_2dff
// 0in set_cdc_port_domain -module sync_2dff IN -clock clkA
Identifies syncx_2dff as a custom synchronizer. CDC analysis recognizes this design

unit as a custom synchronizer with crossing.
// 0in set_cdc_port_constraint syncx_2dff -ports IN -tx_clock_groups clkA
Restricts signals connected to the IN port of the custom synchronizer with crossing
syncx_2dff to the domain of clock group clkA. The -tx_clock_groups argument is used
because IN is clocked by a transmit domain clock.
// 0in set_cdc_port_constraint syncx_2dff -ports OUT -rx_clock_groups clkB
Restricts signals connected to the OUT port of syncx_2dff to the domain of clock group
clkB.
278

October 2011
Command Reference
set_cdc_port_domain
set_cdc_port_domain
Identifies the clock domains of top level and black box ports, enables reporting of clock domain
crossings from the ports and identifies domains of black box ports for use with hierarchical
verification.
Syntax
set_cdc_port_domain {-input | -output | -inout | port_pattern}
{-async | [-async] -clock clock_id | -tx_clock clock_port | -rx_clock clock_port | -ignore}
[-same_driver] [-mode mode] [-module module_pattern] [hierarchical_CDC_options]
hierarchical_CDC_options ::= [-same_clock port_pattern] [-combo_logic]
[-combo_path primary_input_port | -nosync]
-input, -output, -inout

A collection of ports: all input ports, all output ports, or all inout ports. Can be combined
with port_pattern. For example, the following arguments apply the directive to all of the
modules ports that are inputs with names that match A*:
-input A*
port_pattern
One or more top-level or black box ports (wildcards are allowed). Top-level port matches to
bit slices are supported. Matches to bit-sliced black box ports are not supported.
-async
Identifies the ports as asynchronous to all clock domains. For a custom synchronizer
module, -clock clock_signal -async means that the associated port is considered
asynchronous, but the ports receive domain clock is derived from clock_signal.
-clock clock_id
Identifies the clock domain. You can specify a clock signal local to any of the specified
modules (or a top clock name if module is not specified) or a clock group name.
tx_clock clock_port | rx_clock clock_port

Clock port of -module for the clock domain of the ports. Must be specified with a -module
that is also declared as a custom synchronizer (set_cdc_synchronizer custom) with at least
two clock ports. The data/signal ports must be identified with either the transmit or the
receive clock (in particular, no -async ports); at least one port must be identified with tx_clock and at least one port must be identified with a -rx_clock. Instances of this custom
synchronizer module are reported as instances of a custom sync with crossing scheme (see
custom_sync_with_crossing on page 205). Otherwise, they are reported as instances of a
simple custom_sync scheme.

October 2011
279
Command Reference
set_cdc_port_domain
-ignore
Identifies primary input ports as driving signals that should be ignored for structural CDC
analysis. Also identifies ports of black boxes and custom synchronizers that are driven by
signals that should be ignored for CDC structural analysis.
-same_driver
Ports are considered driven by the same source driver signal when analyzing single-source
reconvergence paths. The divergence depth from the single-source driver to the ports is
taken as 1 sequential level for the purpose of calculating the divergence depth of
reconverging pathseven if the actual divergence depth inside the black box is greater than
1. Option is supported only on DUT (-d module) inputs.
single-source
reconvergence paths
-same_driver
depth = 1
synchronizer
black box
synchronizer
synchronizer
Tx Clock Domain
Rx Clock Domain
-mode mode
The -mode option specifies the mode name to which the command in question is applicable
in modal analysis.
The user might have different CDC constraints, such as port domains in different modes.
This can be specified as follows:
// 0in set_mode mode1 -set sel 1'b1
// 0in set_mode mode2 -set sel 1'b0
// set_cdc_port_domain in -clock clk1 -mode mode1
// set_cdc_port_domain in -async -mode mode2
With the above example, constraints port in is synchronous to clk1 in mode mode1 and
asynchronous in mode mode2.
If the user specifies the -mode option with a constraint and is using regular (not modal)
CDC analysis flow, then the directive is ignored.
The directive applies to ports on all instances of the modules that match module_pattern.
Default: top-level module.
280

October 2011
Command Reference
set_cdc_port_domain
-same_clock port_pattern
This option is used only for hierarchical verification. The -same_clock option is specified
for an input port. This option is used to specify that the port should be in the same clock
domain as the other ports. If the two ports are not clocked on the same clock, then a warning
is printed. This models cases when two ports of a block are connected to a DMUX
synchronizer. One of the ports goes to the select of the DMUX and the other goes to the data
bus. The same clock constraint ensures that the DMUX select and data are clocked on the
same clock.
-combo_logic
This option is used only for hierarchical verification. Identifies a hierarchical blocks
input ports with combinational fanout logic and output ports with combinational fanin logic
(for hierarchical CDC analysis). With this information, CDC analysis can detect
combinational logic before synchronizers:
combinational
logic
-combo_logic
data_a
data_b
synchronizer
clock_b
clock_a
black box
-combo_path primary_input_port
This option is used only for hierarchical verification. This option is used to model a
combination path from a list of primary inputs to a primary output. The option specified for
an output port, indicates a combinational path from the input ports to the output. The option
takes a list of string names that are the names of primary inputs which have a combinational
path to that output. While computing the outputs port domain, the inputs port domain is
taken into account. In case of conflicting input port domains, the output port domain is
inferred as -async. The -combo_path option is also used in clock propagation when the input
is connected to a clock. The output is then treated as a clock and propagated forward.
black box
port_a
combinational
logic
-combo_path port_a port_b
port_b

October 2011
281
Command Reference
set_cdc_port_domain
-nosync
This option is used only for hierarchical verification. The -nosync option is specified for
an input port. This option is used to model a primary input port that is connected to flipflops clocked on different clock domains. Such a port is declared as nosync because any
crossing to such a port is a missing synchronizer. In other words, specifies that the port is
sampled by a different clock and therefore, is a bad crossing.
sampled by
different clock
-nosync
black box
clk_b
clk_a
Description
The set_cdc_port_domain global directives identify the clock domain characteristics of the
ports of the top-level module and internal black boxes. Without information from
set_cdc_port_domain directives, CDC only has the logic driven inside the DUT when it
analyzes clock domain crossings that originate outside the DUT logic. The
set_cdc_port_domain directives have two uses:
Enable reporting of clock domain crossings originating outside the DUT.

CDC extrapolates what it can from the DUT logic, but since the information is
incomplete, reporting all CDC paths can introduce too much noise. Reporting of the
related schemes is disabled by default. The set_cdc_port_domain directives provide the
details needed to properly analyze crossings through primary ports, so CDC analysis
reports schemes involving these ports.
Pass hierarchical CDC information from an analyzed hierarchical level to be used in the
current level analysis.
This information is generated automatically by the CDC tool during hierarchical CDC
analysis of other hierarchical levels. The hierarchical_CDC_options (-same_clock
port_pattern, -combo_logic, -combo_path primary_input_port and -nosync) are
reserved for hierarchical CDC sessions and generate warnings if the hierarchical data for
the ports is missing.
282

October 2011
Command Reference
set_cdc_port_domain
Examples
1. Each set_cdc_port_domain global directive with a -clock argument assigns all
matching ports to the same clock domain (that is, the directive does not assign to
multiple clock domains). For example,
module cdc_ctrl;
// 0in set_cdc_port_domain a b c clock U1.clk_A
// 0in set_cdc_port_domain d clock U2.clk_B
endmodule

----------------------------------------------------------------File t9_ctrl.v : Line 5
----------------------------------------------------------------*t1 matches
rst1
aint1
aout1
bout1
Wildcards for set_cdc_port_domain directive with -module
----------------------------------------------------------------File t9_ctrl.v : Line 6
----------------------------------------------------------------u*d in module dff3 matches
u0.d
File t9_ctrl.v : Line 7
----------------------------------------------------------------u*d in module dff5 matches
u0.d
----------------------------------------------------------------a*2 in module dut matches
aint2
aout2
2. This example illustrates single-source reconvergence using the set_cdc_port_domain

global directive -same driver option. This example, uses the -same_driver option
of the set_cdc_port_domain global directive to report diverging points of primary
ports having the same driver. With the single-source depth of 2, use the following global
directives:
// 0in set_cdc_port_domain p2 p3 in[1:4] -same_driver
This results in ports p2, p3 and in[1:4] being reported.

October 2011
283
Command Reference
set_cdc_port_domain
The code snippet for this example is shown in Example 6-1 on page 284, the schematic
view is shown in Figure 6-1 on page 284, and the 0in_cdc.rpt report file is shown in
Example 6-2 on page 284.
Example 6-1. Single-source Reconvergence Code Snippet
dff f1(clk1, rst1, d, d_tx0);
dff f2(clk1, rst1, d_tx0, d_tx1_1); // single-source_depth =Divergence
1
dff f3(clk1, rst1, d_tx0, d_tx1_2); // single-source_depth = 1
sync sync1(clk2, rst2, d_tx1_1, q_rx0_1);
sync sync2(clk2, rst2, d_tx1_2, q_rx0_2);
Synchronizers
dff f4(clk2, rst2, q_rx0_1, q_rx1_1); // depth = 1

dff f5(clk2, rst2, q_rx0_2, q_rx1_2); // depth = 1
Convergence
dff f6(clk2, rst2, q_rx1_1 | q_rx1_2, q_rx2); // depth = 2

dff f7(clk2, rst2, q_rx2, q);
Figure 6-1. Single-source Reconvergence Schematic
Example 6-2. Single-source Reconvergence 0in_cdc.rpt File

Single-source Reconvergence of synchronizers. (SSR)
----------------------------------------------------------------clk2 : end : f6.q (back_depth1.v : 6) (ID:SSR)
284

October 2011
Command Reference
set_cdc_port_domain
clk2 : start : sync2.u1.q (back_depth1.v : 6) (Synchronizer
ID:two_dff_19004)
clk2 : start : sync1.u1.q (back_depth1.v : 6) (Synchronizer
ID:two_dff_18748)
clk1 : diverge : f1.q (back_depth1.v : 6) (ID:SSR_7566)

October 2011
285
Command Reference
set_cdc_preference
set_cdc_preference
Sets preferences for CDC static analysis.
Syntax
set_cdc_preference
[-clock_in_data] [-detect_primary_output_clock] [-detect_pure_latch_clock] [-clock_as_rx]
[-infer_clock_off] [-enable_internal_resets] [-report_resets] [-promote_async_reset]
[-handshake_scheme] [-fifo_scheme] [-complex_scheme_as_synchronizer]
[-report_undriven_custom_sync] [-print_detailed_custom_sync] [-custom_fx]
[-multi_clock_convergence] [-unrestricted_reconvergence] [-promote_reconvergence]
[-dmux_as_recon_start] [-report_black_box_recon] [-black_box_empty_module]
[-ignore_black_box] [-sample_data_stability] [-dmux_promote_sample]
[-formal_add_bus_stability] [-formal_add_recon_stability] [-infer_modes_off]
[-report_mode_signals] [-allow_enable_in_sync] [-delayed_pulse] [-mult_fanout_async]
[-input_async] [-vectorize_nl] [-filtered_report] [-print_port_domain_template]
[-multi_paths] [-max_cdc_crossings number]
Clocks
-clock_in_data
Reports all crossings, including clock signals that go to data inputs of registers. In some
cases, runtime can increase substantially. Default: CDC crossings of signals used as both
clock and data are not reported.
-detect_primary_output_clock
Detects primary output clocks. An output port of the top module is inferred as a clock port if
the fanin logic of the port has a signal either specified as a clock (with set_cdc_clock) or is
used to clock a register/latch. Default: clocks are not inferred for top-level output ports.
-detect_pure_latch_clock
Assumes latch enables are clocks. Default: only latch enable signals that clock another
register or that are specified with set_cdc_clock are recognized as clock signals.
-clock_as_rx
Reports clock domain crossings to Rx nodes that have clock signals in their fanin cones (and
are not registers, latches, primary outputs, or inputs to custom synchronizers or black
boxes)unless Tx is part of the clock tree. Default: these crossings are not reported.
-infer_clock_off
Disables clock inference. Only user-specified clocks (i.e., specified by set_cdc_clock) are
assumed to be clocks. This option lets you avoid grouping inferred clocks. Default: CDC
clock analysis infers clocks.
286

October 2011
Command Reference
set_cdc_preference
Resets
-enable_internal_resets
Infers internal reset signals as resets. Default: only reset signals derived from primary (i.e.,
DUT) ports are inferred as resets.
-report_resets
Reports reset tree data in the design report. Default: reset trees are not reported.
-promote_async_reset
Promotes cdc_sync checkers for async_reset. Default: checkers are not promoted for
async_reset schemes.
Complex Schemes
-handshake_scheme
Identifies HANDSHAKE CDC schemes. Default: HANDSHAKE CDC schemes are
reported as dmux or multi_bits schemes.
-fifo_scheme
Identifies FIFO CDC schemes. Default: FIFO CDC schemes are reported as memory_sync
or multi_bits schemes.
-complex_scheme_as_synchronizer
Recognizes dmux schemes that have complex synchronizers as the MUX-select
synchronizer. Default: to report a dmux scheme, its MUX-select synchronizer must be a
two_dff synchronizer.
Custom Synchronizers
-report_undriven_custom_sync
Reports as instances of the custom_sync scheme those custom synchronizer crossings
originating from internal or undriven wires. Default: only reports custom synchronizers that
are driven by ports.
-print_detailed_custom_sync
Reports custom synchronizers on signals that are not reported as CDC crossings (see
Custom Synchronization Modules on page 467). Default: these signals are not reported.
To report a custom synchronizer in a CDC crossing, add the -tx/-rx arguments to the
set_cdc_port_domain specification.
-custom_fx
Allows tx signals in CDC-FX checkers to come from ports and custom synchronizers and
allows rx signals to drive custom synchronizers. Injection occurs when tx and rx clocks are
aligned and the checker fires when data changes in the metastability window. With this
option more false violations can occur. Default: tx signals must come from registers and rx
signals must drive only registers.

October 2011
287
Command Reference
set_cdc_preference
Reconvergence
-multi_clock_convergence
Reports reconvergence with synchronizers in different Rx clock domains or coming from
different Tx clock domains.
-unrestricted_reconvergence
Reports reconvergence for unsynchronized paths (i.e., paths with missing synchronizers,
combo logic, and so on). Default: reconvergent paths reported only if no other schemes
apply.
-promote_reconvergence
Promotes cdc_hamming1 checkers for reconvergence schemes. Default: checkers are not
promoted for reconvergence schemes.
-dmux_as_recon_start
Recognizes dmux, simple_dmux and multi_sync_mux_select schemes as starting points for
reconvergence schemes.
-report_black_box_recon
Reports reconvergence schemes that reconverge at black boxed instances. Default: these
schemes are not reported.
Black Boxes
-black_box_empty_module
Turns all empty (i.e., stub) modules/entities into inferred black boxes. An empty
module/entity is one for which a module or entity/architecture definition is present, but the
content is empty. That is, only the I/O ports (with directions) are declared. This option does
not apply to unresolved modules/entities. Crossings to or from inferred black boxes are
reported to guard against possible real clock domain crossings. To eliminate false
positives you should indicate the port domains of inferred black boxes using
set_cdc_port_domain directives. Default: empty modules are analyzed as regular modules.
-ignore_black_box
Do not report CDC black_box crossings to the ports of any black box design units that do
not have port domain definitions. Default: report black_box crossing schemes to ports
without port domain definitions for inferred black box design units. Crossings to userspecified black box design units are never reported as black_box schemes.
Protocol Verification
-sample_data_stability
Turns on the data_sample check (by specifying -tx_min) for all promoted
cdc_hamming_one checkers. Default: cdc_hamming_one checkers are promoted with the
data_sample check turned off.
288

October 2011
Command Reference
set_cdc_preference
-dmux_promote_sample
Promotes cdc_sample checkers for dmux schemes. Default: no protocol checkers are
promoted for dmux schemes.
Formal Analysis
-formal_add_bus_stability
Adds checks for signal stability to the synchronization schemes gray-coding protocols
verified by formal CDC.
-formal_add_recon_stability
Adds checks for signal stability to the reconvergence schemes gray-coding protocols
verified by formal CDC.
Modal Analysis
-infer_modes_off
Turns off inferring of modes during cdc -report_modes sessions. Used in special
circumstances to reduce cdc run time: if you know the user-defined modes are complete,
you do not need to infer other modes. For example, if you run a default -report_modes
session and define the inferred modes with set_mode, you can re-run cdc -report_modes
with mode inference disabled. Default: -report_modes performs mode inference.
-report_mode_signals
Reports the mode control signals (see Mode Design Information on page 457) in
0in_cdc_design.rpt. Default: table not reported.
Other Options
-allow_enable_in_sync
Recognizes 2-DFF synchronizers with enable signals in the DFFs. Default: 2-DFF
synchronizers with enables are not recognized as 2-DFF synchronizers.
-delayed_pulse
Recognizes pulse schemes that have a register to delay the output of the pulse synchronizer.
-mult_fanout_async
Identifies input ports that fan out to multiple clock domains as asynchronous ports. Default:
one clock domain is selected.
-input_async
Identifies all DUT input ports as asynchronous ports. Default: all inputs are assumed to be
synchronous with their fanout logic.
-vectorize_nl
Reports as a single-bus synchronizer (for example, BUS_TWO_DFF) each CDC scheme
where the signals start from the same bus, all the signals are synchronized by the same
synchronization scheme and all signals are merged back into a single bus after

October 2011
289
Command Reference
set_cdc_preference
synchronization. Default: Bus bits that are separately synchronized are reported as single-bit
CDC schemes (for example, TWO_DFF).
-filtered_report
Identifies filtered CDC schemes in the CDC report and in the 0in_cdc static CDC analysis
results (GUI). With this preference, schemes identified using the set_cdc_report global
directive as filtered (-severity off) and schemes with stable transmit domain signals
(set_cdc_signal -stable) are reported. Caution: Can result in increased runtime and memory
usage if many set_cdc_report -severity off with wildcards are specified. Default: Filtered
schemes are not reported.
-print_port_domain_template
Creates a 0in_cdc_port_domain_template.v file with the set_cdc_port_domain directives
for the primary ports. Use this template as a starting point for setting up the
set_cdc_port_domain constraints. CDC analysis cannot identify the clock domains of the
ports as they depend on the DUT external environment. You should review the constraints
and adjust as necessary. You can ignore set_cdc_clock directives in the template if you have
specified the set_cdc_clock directives in a control file.
-multi_paths
Reports all the paths for each clock domain crossing (i.e., Tx/Rx pair). This option can
reduce performance significantly. Default: Only one path per crossing is reported in the
CDC report.
-max_cdc_crossings number
Limits the number of CDC crossings analyzed. Once this limit is reached, no more crossings
are analyzed. You can use this option to reduce session time when initially setting up a
design for CDC analysis. Default: no limit (number = 0).
Description
This global directive defines preferences for CDC. The status of the CDC preferences is printed
in the 0in_cdc_setting.rpt file (see Figure 6-2).
Figure 6-2. Global CDC Preferences (0in_cdc_setting.rpt)
Global CDC Preferences
--------------------------------------------------------------------Option
Value
--------------------------------------------------------------------multi_clock_convergence
FALSE
clock_in_data
FALSE
allow_enable_in_sync
FALSE
max_cdc_crossings
0
custom_fx
FALSE
promote_reconvergence
TRUE
mult_fanout_async
TRUE
dmux_promote_sample
FALSE
input_async
FALSE
290

October 2011
Command Reference
set_cdc_preference
ignore_black_box
handshake_scheme
fifo_scheme
delayed_pulse
report_resets
detect_primary_output_clock
formal_add_bus_stability
formal_add_recon_stability
filtered_report
vectorize_nl
unrestricted_reconvergence
clock_as_rx
multi_paths
report_undriven_custom_sync
print_port_domain_template
dmux_as_recon_start
print_detailed_custom_sync
report_black_box_recon
black_box_empty_module
sample_data_stability
infer_clock_off
detect_pure_latch_clock
promote_async_reset
complex_scheme_as_synchronizer
infer_modes_off
enable_internal_resets
report_mode_signals
FALSE
FALSE
TRUE
TRUE
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
TRUE
TRUE
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
Examples
// 0in set_cdc_preference -allow_enable_in_sync
// 0in set_cdc_preference -clock_in_data
// 0in set_cdc_preference -max_cdc_crossings 200
// 0in set_cdc_preference -filtered_report
0in_cdc.rpt includes the following table:

Filtered CDC Checks Summary
=================================================================
----------------------------------------------------------------clk1 : start : X1.cdc_inst.int1 (t21.v : 17)
clk2 : end : X1.out2a (t21.v : 36) (ID:no_sync_29270)
via : X1.cdc_inst.intt1
----------------------------------------------------------------clk1 : start : X1.cdc_inst.int1 (t21.v : 17)
clk2 : end : X1.out2d (t21.v : 36) (ID:async_reset_no_sync_47514)
via : X1.cdc_inst.intt1

October 2011
291
Command Reference
set_cdc_protocol
set_cdc_protocol
Identifies a CDC protocol checker type to promote for one or more custom synchronizer
modules.
Syntax
set_cdc_protocol
checker_type -module custom_synch_pattern [-rx_clock clock] [-tx_var signal]
checker_type
Type of checker to promote. Currently, only values of cdc_sync and cdc_hamming1 are
supported.
-module custom_synch_pattern
Custom synchronizer modules.
-rx_clock clock
Rx clock signal in the synchronizer. Default: if the synchronizer has only one clock port,
that clock is inferred as the Rx clock. Otherwise, a warning is issued and the directive is
skipped.
-tx_var signal
Transmit domain CDC input signal in the synchronizer. Default: if the synchronizer has
only one data input port, that signal is inferred as tx_var. Otherwise, a warning is issued and
the directive is skipped.
Description
Used with the set_cdc_synchronizer directive to identify custom synchronizers for CDC
analysis. Static CDC analysis assumes each module specified by a set_cdc_synchronizer
directive is a custom synchronizer. The set_cdc_protocol directive indicates a type of checker to
promote to check the CDC transfer protocol for schemes that are synchronized by one of the
matching synchronizers. The directive needs the module name pattern of the synchronizers and
the checker type for the promoted protocol checkers. Currently, only the cdc_sync and
cdc_hamming1 checker types are supported.
A basic custom synchronizer has an Rx clock input, a Tx domain input and an Rx domain
output. Currently, this is the only type of custom synchronizer supported by set_cdc_protocol.
If two set_cdc_protocol directives reference the same port, a directive-273 warning is issued
and the second directive is ignored.
292

October 2011
Command Reference
set_cdc_protocol
Example
// 0in set_cdc_synchronizer cust -module cust_sync1
// 0in set_cdc_port_domain D -async -module cust_sync1
// 0in set_cdc_protocol cdc_sync -module cust_sync1
Promotes the following checker directive, where tx_var is the signal connected to the D
port of the cust_sync1 instance, tx_clock is the inferred clock in cust_sync1 and
clock_ratio is the ratio of the inferred Rx/Tx clocks.
/* 0in cdc_sync
-tx_var tx_var -tx_clock tx_clock -tx_min clock_ratio */

October 2011
293
Command Reference
Specifies reconvergence control parameters.
Syntax
set_cdc_reconvergence [-check off] [-depth depth] [-divergence_depth depth]
[-tx_clock clock] [-rx_clock clock] [-bit_recon]
-check off
The -check option is used to turn off reconvergence checking totally. The default is On.
-depth depth
Maximum sequential reconvergence depth for reporting reconvergence and single-source
reconvergence CDC schemes.
depth 3
synchronizer
3 sequential
levels
synchronizer
3 sequential
levels
2 sequential
levels
synchronizer
Tx Clock Domain
Rx Clock Domain
reconvergence
paths
combinational
logic
The sequential reconvergence depth is the number of sequential levels from the storage
element after the synchronizer to the reconvergence point. In cases where the reconvergent
paths have different numbers of levels, the sequential reconvergence depth is the largest
number of sequential levels. For example, suppose paths A and B are reconvergent with 5
and 8 sequential levels to the reconvergence point respectively. Then this scheme instance is
not reported as a reconvergence violation if set_cdc_reconvergence sets -depth 5, but is
reported if set_cdc_reconvergence sets -depth 8. Default: 0.
-divergence_depth depth
Enables reporting of single-source reconvergence and sets the divergence depth. Default:
instances of SSR schemes are reported only as reconvergence schemes.
294

October 2011
Command Reference
depth 2
divergence_depth 2
synchronizer
synchronizer
synchronizer
Tx Clock Domain
Rx Clock Domain
single-source
reconvergence
paths
combinational
logic
-tx_clock clock
Restricts the directive to paths originating in the Tx clock domain.
-rx_clock clock
Restricts the directive to paths terminating in the Rx clock domain.
bit_recon
Report as instances of the reconvergence scheme, those paths where the individual bits of
the output of a bus 2DFF synchronizer are re-combined.
bus 2DFF
re-converging bits
Description
Use this global directive to specify reconvergence control parameters.

October 2011
295
Command Reference
set_cdc_report
set_cdc_report
Sets the severity level and promotion property of matching clock domain crossings.
Syntax
set_cdc_report
{ -severity severity [-scheme sync_scheme] [-promotion {on | off | protocol | fx}]
| -default_severity severity -scheme sync_scheme}
[-default_promotion {off | on}] [-tx_clock clock_signal] [-rx_clock clock_signal]
[[-from var_pattern] [-through var_pattern] | -from_signals var_pattern ]
[-to variable_pattern] [-message string] [-mode mode] [-module module_pattern]
severity := {violation | caution | evaluation | waived | off}
-severity {violation | caution | evaluation | waived | off}

The severity levels are violation, caution, evaluation, waived, or off. Specifying off removes
the crossings from CDC analysis. Paths filtered out from the report with the set_cdc_report
-severity off directive are reported in the 0in_cdc.rpt file when set_cdc_preference
-filtered_report is specified. The results are reported at the end of the file in the section titled
Filtered CDC Checks Summary. Note that the tool runtime and memory consumption can
increase when a large number of set_cdc_report global directives with wildcards are used.
When multiple set_cdc_report directive with conflicting -severity arguments apply to the
same scheme, -severity off takes precedence. Otherwise, one of the severities is selected and
warnings are reported.
You can set any crossing as waived by using the set_cdc_report global directive. For
example,
// 0in set_cdc_report -severity waived
By default, crossing that are waived are not promoted. The waived crossing can be
promoted using the following:
// 0in set_cdc_report -severity waived -promotion on
When -severity is used to set the severity of a particular crossing to violation, formal CDC
does not analyze the crossing (so the crossing remains a violation).
-scheme sync_scheme
Set attributes for crossings conforming to the specified scheme type (for example,
single_source_reconvergence, dmux, and so on). Default: all schemes.
-promotion {on | off | protocol | fx}

Whether or not to promote transfer protocol and/or FX checkers for the matching crossings
(when the -compile_assertions to cdc is specified). You also must specify the -severity for
the crossings. Off turns off all matching promoted checkers. On turns on all matching
promoted checks. FX checkers are generated only if the -fx option to cdc is specified.
Protocol turns on just the protocol checkers; fx turns on just the FX checkers.
296

October 2011
Command Reference
set_cdc_report
-default_severity {violation | caution | evaluation | waived | off}

Sets the default severity for the specified scheme type. Directive is ignored if any arguments
other than -scheme and -module are specified.
-default_promotion {off | on}

Whether or not to promote a CDC protocol assertion if no other -promotion options apply.
Although by default CDC protocol assertion promotion is on, the -default_promotion on is
useful when severity or default severity is off (which usually turns off CDC protocol
assertion promotion). For example, the following directive turns severity off for
bus_shift_reg schemes, but retains CDC protocol assertion promotion:
/* 0in set_cdc_report -scheme bus_shift_reg -severity off
-default_promotion on */
Crossings from transmission logic clocked by a particular clock.
Crossings to receive logic clocked by a particular clock.
-from variable_pattern, -to variable_pattern, -through variable_pattern

One or more paths that include CDC crossings. You can specify any combination of
-from, -to, and -through arguments (but multiple -from variables only are allowed for the
reconvergence and single_source_reconvergence schemes).
The -through variable_pattern argument specifies a wire in the paths. These wires are the
waypoints shown as VIA points in the CDC report. You can include wildcards and slices in
variables and wire names. To match the specification, a path must pass through wires
specified by every -through argument. The directive is ignored if you specify -through with
-scheme reconvergence or -scheme single_source_reconvergence and a directive-214
warning is issued: Unmatched CDC crossing specified.
If a CDC crossing originates from (-from) or ends at (-to) a stable variable (see
set_cdc_signal on page 301), then the crossing is removed from CDC analysis. Even
though the -to variable_pattern does not support multiple signal names, a wildcard pattern
can be specified that has multiple matches. For example, the following directive turns off
multiple crossings:
//0in set_cdc_report -to a.gen*.c -severity off
Schemes other than the reconvergence scheme do not allow specification of more than one
signal in the -from option (including wildcard matches). A directive that violates this rule is
ignored, in which case the CDC compiler issues a warning message.
In the special case of reconvergence to black boxes (i.e., set_cdc_preference
-report_black_box_recon) the -to variable_pattern can be the instance name pattern of one
or more black boxed modules. To be considered a reconvergent path, the two converging
paths need only end at any port of the same black boxed instance.

October 2011
297
Command Reference
set_cdc_report
-from_signals variable_pattern
This option is used only for reconvergence analysis. Specifies variables that identify
registers or wires that contain data in one clock domain that are separately synchronized and
then recombined in another clock domain. The difference between -from and -from_signals
is that -from takes the OR of the signals and -from_signals takes the AND of the signals.
You must specify -scheme reconvergence with this option, otherwise, the directive is
ignored and the CDC compiler issues the following warning message:
Warning: Reconvergence scheme must be used when the -from_signals
option is specified.
Directive set_cdc_report.
: Directive will be ignored.[hdl-86]
If both -from and -from_signals options are specified, the directive is ignored and the CDC
compiler issues the following warning message:
Warning: Options from and from_signals specified.
Directive set_cdc_report.
: Directive will be ignored.[hdl-104]
If the variable_patterns have no wildcards, the list of signals must be completein

particular, the list must include two or more signalsthe directive only applies to
reconvergence instances where all of the specified source signals reconverge.
If the variable_patterns have wildcards, the directive only applies to reconvergence
instances where every variable_pattern has a matching start point and the matched start
points are complete. For example, consider the following argument:
from_signals A* B C
The directive matches reconverging paths that have the following (complete) sets of start
points: (A1 B C) and (A1 A2 B C). The directive does not match reconverging paths that
have the following (complete) sets of start points: (B C) and (A1 B C E).
-message string
Message string to add to the path reports of matching CDC schemes. Default: no message
added.
-mode mode
in modal analysis. If you specify the -mode option with a constraint and is using regular
(not modal) CDC analysis flow, then the directive is ignored.
The global directive applies to matching CDC crossings in all instances of the module
specified by module_pattern. Wildcards are allowed, in which case the directive applies to
all instances of the matching modules. If the -module option is omitted, then the directive
applies the -d module.
Example 1:
298

October 2011
Command Reference
set_cdc_report
//0in set_cdc_report -module A -severity caution
Only crossings completely within the same instance of A are set to caution.
Crossings across instances of A are not affected.
Example 2:
//0in set_cdc_report -module A -from B -severity caution
Crossings in which the from signal is X.B are set to caution, where X is any
instance of module A.
Description
The set_cdc_report global directive sets the severity level and promotion property of matching
clock domain crossings. Use this directive to override the default severity and promotion of
clock domain crossing checks.
Specify one of the following:
-severity severity with an optional -scheme or -promotion.
-default_severity severity -scheme sync_scheme
If you do not specify other arguments, then the directive applies to all CDC crossings. If you do
not specify other arguments except -module module, then the directive applies only to crossings
entirely within module. Otherwise, you can specify a combination of arguments to identify one
or more CDC crossings. The specified crossings are all of those that match all of the criteria. If
-module module is specified, these crossings need not lie completely inside module.
Note that -severity off turns off promotionso, -severity off -promotion on generates a warning
message and the directive is ignored.
Example 1: set_cdc_report
module cdc_ctrl;
/* 0in set_cdc_report -scheme black_box
-from out2a -to bb1.* -severity off */
// 0in set_cdc_report -scheme two_dff_phase -severity evaluation
endmodule
Example 2: Set All DMUX Crossings to Evaluation

This example illustrates using the set_cdc_report global directive to set all DMUX
crossings to evaluation, except for those that start from A and end at B.
// 0in set_cdc_report -scheme demux -severity evaluation
// 0in set_cdc_report -from A -to B -severity waived
Warnings are produced when there are conflicts.

October 2011
299
Command Reference
set_cdc_report_comment
set_cdc_report_comment
Adds a user-specified comment to the CDC report.,
Syntax
set_cdc_report_comment -comment string
-comment string
String to print to the User Comment section of the CDC report.
Description
The set_cdc_report_comment global directive specifies a comment to add to the CDC report.
Example
// 0in set_cdc_report_comment -comment SHIBA: static CDC run.
prompt> more 0in_cdc.rpt
Questa CDC Version 10.0a linux_x86_64 18 March 2011
----------------------------------------------------------------Clock Domain Crossing Report.
Created Tue Mar 8 12:23:17 2011
----------------------------------------------------------------User Comments
=================================================================
SHIBA: static CDC run.
300

October 2011
Command Reference
set_cdc_signal
set_cdc_signal
Reclassifies the CDC signal type of specified CDC signals or adds properties to specified CDC
signals.
Syntax
set_cdc_signal
variable_pattern [-split] [-stable] [-gray_coded] [-module module_pattern] [-mode mode]
[-merge]
variable_pattern
One or more CDC signals. Names can include wildcards and can be bit slices. The
classification or CDC property assigned by the directive is applied to all matching variables.
-split
Treats bits of the specified multiple-bit registers/latches as individual control signals for
CDC analysis. By default, synchronization of a CDC data bus must be performed on the
whole bus. If not, then the bus is marked with a BUS SYNC warning. But, if a register has
only one bit derived from a CDC signal, then synchronization of that bit should be allowed.
For example, a status bit might be extracted from a state variable or a single multiple-bit
register (for example, a status register) might store amalgamated control signals. Splitting a
CDC data bus for CDC analysis eliminates the BUS SYNC warning.
Treating bits individually is independent of the synchronization type: the bits can be
synchronized with control synchronization (for example, 2DFF) or data synchronization
(for example, DMUX). You might want to treat bits in a bus individually for any of the
following reasons:
Only some bits of the bus cross a clock domain boundary.
Different bits in the bus go to different clock domains.
The bus is a collection of individual signals (such as status signals) that you want to
consider as individual bits.
Various bits of a split bus can be used together in the destination domain (for example, in a
receiving state machine decoding). To check for reconvergence problems, CDC analysis
identifies these crossings as potential RECONVERGENCE warnings.
-gray_coded
Identifies the specified variables as properly gray-coded data buses for CDC analysis.
2DFF and four latch synchronizations can be valid for a gray-coded data bus. So by default,
checks for CDC data buses that have either of these types of synchronizers are promoted as
a cdc_hamming_distance_one checkers to verify gray-coding and synchronization.
Identifying a particular variable as gray-coded indicates the data bus is properly gray-coded
(that is, with gray coder/decoder logic), so gray-code checking is unnecessary. In this case,
the crossing check is promoted as a cdc_sync checker.

October 2011
301
Command Reference
set_cdc_signal
-stable
Identifies the specified variables as stable for CDC analysis. CDC analysis considers a
stable variable (and its propagated values) as properly synchronized.
The -stable option has no effect if signal is not an Rx or Tx of a CDC crossing, or if signal
cannot be propagated to an Rx of a CDC crossing, or if signal drives an input of
combinational logic whose output is not stable. To see the signals marked as stable that have
no effect on CDC analysis, specify the set_cdc_preference -filtered_report directive and
review the Filtered CDC Checks Summary section in 0in_cdc.rpt.
The global directive applies to matching CDC signals in all instances of modules that match
module_pattern. If -module is omitted, the global directive applies to the -d module.
-mode mode
in modal analysis. If you specify the -mode option with a constraint and is using regular
(not modal) CDC analysis flow, then the directive is ignored.
-merge
Merge the signals into a single signal for CDC analysis.
Description
The set_cdc_signal global directive reclassifies the CDC signal type of specified CDC signals
or adds properties to specified CDC signals. Use this directive to override the inferred
classifications of CDC signals and to identify synchronization properties of particular CDC
signals.
Specify the following:
signals
-split, -merge, -gray_coded, or -stable
Note that all CDC crossings filtered by the // 0in set_cdc_signal -stable global directive are
reported at the end of the 0in_cdc.rpt file when the set_cdc_preference -filtered_report is
specified.
Examples
Example 1
module cdc_ctrl;
// 0in set_cdc_signal tx_status1 tx_status2 merge module mtr
// 0in set_cdc_signal write_addr gray_coded module pci_if
endmodule
The list of wildcard expanded signals are reported in 0in_cdc_setting.rpt. Following is a sample
control file showing the use of wildcards with the set_cdc_signal directive:
302

October 2011
Command Reference
set_cdc_signal
module check;
// 0in set_cdc_clock clk1
// 0in set_cdc_clock clk2 -group g2
// 0in set_cdc_signal out[1:4] -module dff20 -stable
// 0in set_cdc_signal * -module dff40 -split
// 0in set_cdc_signal q -module *10 -gray_coded
endmodule
Following is the information regarding the wildcard expanded signals that are reported in the
0in_detail.log file for the above example:
Wildcards for set_cdc_signal directive with -module
----------------------------------------------------------------File t28_ctrl.v : Line 5
----------------------------------------------------------------* in module dff40 matches
clk
rst
ena
d
q
----------------------------------------------------------------q in module dff10 matches
q
Example 2
sig_b
combo
logic
sig_c
sig_a
tx_clk
-stable
might not
be stable
rx_clk
set_cdc_signal sig_a -stable has no effect
Marking sig_a as stable has no effect on CDC analysis because the sig_b input to the combo
logic block might make sig_c unstable. Therefore, a combo_logic violation is reported. Signals
marked as stable that do not affect CDC analysis return a directive-284 warning.

October 2011
303
Command Reference
Identifies nonstandard synchronizer types and their corresponding properties.
Syntax
{ dff {-level level | -min level -max level} [-tx_clock clock_signal] [-rx_clock clock_signal]
| latch -level level [-tx_clock clock_signal] [-rx_clock clock_signal]
| custom -module module_pattern}
[-mode mode]
dff, latch. or custom

DFF, latch or custom synchronizer.
-level level
Number of DFF or latch instances in the synchronizer. Single-bit crossings synchronized by
this type of synchronizer are considered properly synchronized by default; they have
evaluation severity. Default: 2 for DFF synchronizers and 4 for latch synchronizers.
Note the following:
If you set the level to N, then the number of DFF in the synchronizers should be
exactly N.
If there are < N DFFs, then the synchronizer will have severity violation.
If there are > N DFFs, then the synchronizer will have severity evaluation; but if it is
used to control other crossings (like DMUX), then the tool will not be able to
recognize it. In this case, you should use the -min and -max options to define a valid
window of delays.
You can restrict the assignment to DFF synchronization schemes on signals from a specified
-tx_clock domain, or to a specified -rx_clock domain, or on signals between both.
-min level
Minimum number of DFFs to be considered a dff synchronizer. If a crossing has fewer than
level DFFs in series, a MISSING_SYNCHRONIZER violation is reported.
-max level
Maximum number of DFFs in the dff synchronizer. If a crossing has more than level DFFs
in series, a MISSING_SYNCHRONIZER violation is reported.
Restricts the directive to dff/latch synchronizers with Tx clock -tx_clock clock_signal.
Restricts the directive to dff/latch synchronizers with Rx clock -rx_clock clock_signal.
304

October 2011
Command Reference
The module name of the custom synchronizer. A custom synchronization scheme must be
contained within its own module definition. You must identify the synchronizer module
(that is, the -module option is required). You can use wildcards in the module identifier; the
custom synchronizer specification applies to all matching modules.
-mode mode
The -mode option specifies the mode name to which the command in question is
applicable in modal analysis. If you specify the -mode option with a constraint and are
using regular (not modal) CDC analysis flow, then the directive is ignored.
Description
The set_cdc_synchronizer global directive identifies nonstandard synchronizer types and their
corresponding properties. Use this directive to configure CDC analysis to handle specific DFF
or custom synchronizers. Each global directive identifies a single synchronizer type; therefore,
you must specify only one synchronizer type (dff, latch or custom).
Examples
Example 1
// 0in set_cdc_synchronizer custom -module cust_2sync
// 0in set_cdc_port_domain in1 out2 -clock clk1 -module cust_2sync
// 0in set_cdc_port_domain in2 out1 -clock clk2 -module cust_2sync
Identifies cust_2sync as a custom synchronizer module and assigns the clock domains of
its data ports.
Example 2
// 0in set_cdc_synchronizer dff -min 2 -max 4
Specifies that 2-, 3- and 4-delay DFFs are valid DFF synchronizers. Note that a 5-delay
DFF is not a valid synchronizer.
Example 3
// 0in set_cdc_synchronizer dff -level 1
Specifies that 1-delay DFFs are valid DFF synchronizers.

Example 4
// 0in set_cdc_synchronizer custom -module cust_sync
// 0in set_cdc_port_domain in -async -clock clk_rx -module cust_sync
Identifies cust_sync as a custom synchronizer module; identifies in as an asynchronous

port and identifies the clk_rx port as the receive clock for clock domain crossings
through the in port.

October 2011
305
Command Reference
Example 5 (Internal-crossing Custom Synchronizer)

//
//
//
//
//
0in
0in
0in
0in
0in
set_cdc_synchronizer custom module INT_SYNC

set_cdc_port_domain sig_tx tx_clock clk_tx -module INT_SYNC
set_cdc_port_domain sig_rx rx_clock clk_rx -module INT_SYNC
set_cdc_protocol cdc_sync -module INT_SYNC
set_cdc_protocol cdc_hamming1 -module INT_SYNC
Internal-crossing
Custom Synchronizer
Tx Clock Domain
sig_tx
Rx Clock Domain
DFF
DFF
sig_rx
clk_rx
clk_tx
INT_SYNC
The INT_SYNC module is a custom synchronizer module where the transmitting register
is internal to the module. In particular, the clock domain crossing for the synchronizer
occurs within the custom synchronizer module itself. The set_cdc_synchronizer
directive specifies INT_SYNC as a custom synchronizer module. The two
set_cdc_port_domain directives declare the INT_SYNC to be an internal-crossing
synchronizer (compare with Example 1). The two set_cdc_protocol directives promote
pulse-width and gray-code checkers for the driver of sig_tx.
An internal-crossing custom synchronizer module is identified when all the following
requirements are met:
306
A set_cdc_synchronizer custom directive with multiple clock ports is specified for

the module.
No ports of the module are defined as asynchronous (set_cdc_port_domain -async).
At least one transmit clock and one receive clock are identified using the
set_cdc_port_domain options -tx_clock and -rx_clock.

October 2011
Command Reference
set_constant
set_constant
Assumes a variable is kept at a specified constant value for CDC analysis.
Syntax
set_constant variable_pattern constant [-module module_pattern]
variable_pattern
Hierarchical name pattern for the variables, specified relative to the DUT. Pattern matches
can be bit slices.
constant
Constant Verilog or VHDL value for variable. If constant has fewer bits than variable, then
constant is zero-extended. If constant has more bits than variable, then the high-order bits
of constant are truncated. All nets connected to variable are forced to the constant value.
Module or modules containing variable.
Description
CDC analysis keeps variable set to constant. This directive can be used on internal variables.
The set_constant directive simplifies the CDC model by discarding part of the DUT circuitry
during cdc compilation. For example, this capability is useful for disabling test logic to reduce
DUT size.
Example
// 0in set_constant U0.rst 1'b1
CDC analysis assumes the port U0.rst is held at 1'b1.

// 0in set_constant U0.in[1:4] 4'b1010
CDC analysis assumes the port slice U0.in[1:4] is held at 4'b1010.

October 2011
307
Command Reference
set_constant_propagation
Propagates constants through sequential logic.
Syntax
set_constant_propagation [reset] [enable]
-reset
Value of the D-input of the register can be different from the reset value. The propagated
value only depends on the D-input. For example,
always @(posedge clk)
if (rst) q <= 1'b0
else q <= d;
Constant d is not propagated through this register with:

// 0in set_constant d 1'b1
// 0in set_constant_propagation
But, constant d is propagated through this register with:

// 0in set_constant_propagation -reset
and:
-enable
Propagates through registers with non-constant enables. For example,
always @(posedge clk)
if (rst) q <= 1'b0;
else if (enable) q <= d;
Constant d is not propagated through this register with:

But, constant d is propagated through this register with:

// 0in set_constant_propagation -enable
and:
// 0in set_constant enable 1'b1
You should always include this argument when specifying set_constant_propagation for
formal analysis.
308

October 2011
Command Reference
Description
Simplifies CDC and formal models by propagating constant values set by the RTL source code
or by set_constant through sequential logic, including latches.

October 2011
309
Command Reference
set_memory
set_memory
Sets the memory model type for specified multidimensional arrays.
Syntax
set_memory {{-exact | -abstract} [mem_pattern]} [-module module_pattern]
mem_pattern
Name pattern for one or more multidimensional arrays. Pattern can be hierarchical, can
contain wildcards and can be repeated. Default: *
-exact | -abstract
How the arrays are modeled: -exact models the arrays as register logic; -abstract models
them as abstract memories. The default model for each multidimensional array is
determined by heuristic analysis.
Module patterns for modules containing multidimensional arrays that match
mem_pattern. Default: * (all modules).
Description
Selects the type of model to use (exact or abstract) for the specified multidimensional arrays.
Used to override memory modeling assignments made by the csl and cdc compilation
heuristics. The following example sets ram32x512 in module sram to be modeled as an abstract
memory and ram4x16 to be modeled as an exact memory.
reg [32] ram32x512 [511:0]
//0in set_memory -abstract ram32x512 -exact ram4x16 -module sram
Exact memories are modeled as register banks. They are simple sequential logic, so they behave
as RTL logic in CDC and formal analysis (i.e., they match the design behavior exactly). When a
very large multidimensional array is modeled exactly, the footprints of the formal and CDC
models can be too large and analysis can be too slow. So, logic models for these memories are
abstracted.
For formal verification, an abstract model of a multidimensional array is a partial model of the
memory. For formal proofs, the memory outputs are treated as inputs controllable by the proof
algorithms. Proven assertions are legitimately proven, but proofs can be missed that would
otherwise be found if the model were exact. Formal firings are found in two ways. When the
partial model of a memory is used for a firing, the behavior of the memory is modeled exactly.
The firing is a violation and is reported as a regular firing. Otherwise, if formal analysis can fire
the target by controlling the part of the memory that is not exact, the violation is reported as a
firing with a warning.
For CDC analysis, an abstract model of a multidimensional array is treated as a black box.
310

October 2011
Command Reference
set_memory
By default, the csl and cdc compilers use similar (but slightly different) heuristic analyses to
determine which multidimensional arrays are selected for abstract modeling. Each abstracted
memory is reported by an SPC warning:
Warning SPC-116 Abstracting large memory. Memory mem in module module
The set_memory directive is used to override this selection, typically with the -abstract option
to force the modeling for one or more memories to be exactfor example, if an assertions
fanin logic has an abstract memory that is causing a firing with a warning. The set_memory
directive also is used to force an exact memory to be abstractedfor example, to reduce system
memory usage or to speed up analysis.

October 2011
311
Command Reference
set_mode
set_mode
Selects a mode of operation for CDC analysis..
Syntax
set_mode
mode {-set variable value} [-ignore]
mode
The mode is the current mode name.
-set variable value

Constant values in the mode.
-ignore
Mode is not to be considered for analysis.
Description
The set_mode global directive is used to create a mode of operation (see Modal CDC
Analysis on page 133).
Example
/* 0in set_mode ModeA
-set sel1 1'b0
-set sel2 1'b1 */
312

October 2011
Command Reference
set_mode_control
set_mode_control
Identifies allowed values for specified mode control signals.
Syntax
set_mode_control
signal_pattern [-values value]
signal_pattern
The signal name can have bit/wildcard. For example,
sig[1] sig*
-values values
The values can have the question mark (?) wildcard. For example,
3'b?1?
Description
The set_mode_control global directive is used to define mode signals for mode inference
(see Modal CDC Analysis on page 133).

October 2011
313
Command Reference
set_reset
set_reset
Identifies the specified signals as reset signals or removes them from the list of inferred resets.
Syntax
set_reset signal_pattern [-remove] [-module module_pattern]
signal_pattern
Name pattern for the reset signals. Can include wildcards and references to bit slices.
-remove
Changes the sense of the directive to remove the specified signals as inferred resets.
Name of the module containing the reset signals. Default: top-level module.
Description
The set_reset directive is used to adjust the reset inferencing performed by the CDC compiler.
Inferred asynchronous resets are true resets, but in certain cases, inferred synchronous resets
might not be resets. Use set_reset with the -remove option to remove these resets from the list of
resets. Some other reset schemes might result in the reset inference algorithm missing bona fide
resets. Use the set_reset directive to specify the missed resets. By default added resets are
synchronous with active high polarity. Use the -negedge and -async options to override these
defaults.
Some designs (for example some low-power handling schemes) use the same signal as an active
high reset for one part of the circuit and as an active low rest for another part of the circuit. In
this case, the compiler issues a warning, but reset inference still considers these signals as real
resets (to both subcircuits).
Examples
// 0in set_reset rst_* -negedge -module pci
Sets the rst_* signals to negedge to override the CDC inference.

// 0in set_reset rst_a -remove -module crc_16_calc
Removes rst_a from the list of resets.
314

October 2011
Command Reference
Directives for Checker Generation
Directives for Checker Generation

Global directives for checker generation (Table 6-3) control in particular how the promoted
CDC checkers and the generated CDC-FX checkers are configured. In general, they control
how simulation with assertions and formal verification of assertions operate.
Table 6-3. Global Directives for Checker Generation
Directive
Description
Wildcard Args
default_reset
Specifies a default signal for the reset inputs to -module

checkers.
-module
use_synthesis_case_directives Directs the compilers to recognize non-0in
case directives (for example full and parallel
case directives).
exclude_checker
Specifies checkers to exclude from simulation -type

with assertions and formal analysis.
-name
-module
-group
include_checker
Specifies checkers to include for simulation

with assertions and formal analysis.
-type
-name
-module
-group
disable_checker
Identifies a signal that can disable checkers

during simulation.
-type
-name
-module
disable_used
Overrides the used options for all checkers of -type

a given checker type in a module.
-module
set_severity
Overrides the severity levels if any are

specified in the checker directives.
set_checker_action
-module
Specifies the action to perform when the
number of firings of checkers with the given
-severity reaches the specified count. Directive
only applies to assertions in simulation.
checker_firing_keyword
Specifies the keyword used in the firing

messages for checkers with the specified
severity level.
create_wire
Creates a wire in checker logic.

October 2011
-type
-name
-module
315
Command Reference
Specifies the keyword used in the firing messages for checkers.
Syntax
checker_firing_keyword name keyword_string [severity level]
-name "keyword_string"
String to insert into firing messages.
-severity level
Severity level (0 - 9) of checkers that are to have the specified keyword string added to their
firing messages. Default: keyword_string is added to all checker messages.
Description
By default, each checker firing message begins with:
0-In Firing:...
The checker_firing_keyword directive adds a specified keyword string to checker firing

messages:
0-In keyword_string Firing:...
The -severity level option restricts the directive to checkers with matching severity level.
Example
//0in checker_firing_keyword -name "Warning S4" -severity 4
Produces the following firing entry:

0-In Warning S4 Firing: S4 assert_window tb.U1...Devsel (Firing: 1)
Time: 330s
Message: Ensures that signals assert correctly relative to a
specified multiple-cycle time window
Signature: One or more signals that should not have asserted
outside the window did assert.
Module: pci_slv,
File: /examples/pci_slave/checker_control.v,Line: 14
Directive: awin -start Devsel -stop_count 2 -in Trdy -not_out
Trdy -module pci_slv -severity 4
Check: not_out
0-In End Firing
316

October 2011
Command Reference
create_wire
create_wire
Creates a wire to use with assertion logic.
Syntax
create_wire -var wire [-width width] [-module module]
-var wire
Name to give the created wire.
-width width
Number of bits in the wire. Default: 1.
-module module
Create the wire in the specified module. Default: wire is created in the current module.
Description
The create_wire global directive creates a wire in the current or specified module, for use in
assertion logic. Wires created by this directive have the following limitations:
Can only be driven by checker outputs.
Can only be used as input to other checkers.
Cannot be referenced hierarchically (in the design and in directive arguments).
Cannot have the same name as an existing design signal name.
Examples
Following example creates a wire inside the module containing the create_wire directive.
module dut(in, clk, out);
parameter P1 = 3;
input [P1-1:0] in;
input clk;
output [P1-1:0] out;
// 0in set_clock clk -default
// 0in create_wire -var w -width P1
// 0in create_assign -var (~out) -var_out w
// 0in one_hot -var w
endmodule
Following example creates a wire inside the specified module.

module ctrl;
// 0in create_wire -var w -width P1 -module dut
// 0in create_assign -var (~out) -var_out w -module dut
// 0in one_hot -var w -module dut
// 0in create_wire -var f0 -module dut
// 0in assert -var (out !=0) -assert_fire f0 -module dut
endmodule

October 2011
317
Command Reference
default_reset
default_reset
Specifies a default checker reset signal or activates default reset inference. Can be specified in a
design module.
Syntax
Identify Default Reset
default_reset {-none | signal [-active_high | -active_low]}

[-sync | -async] [-infer] [-module module]
signal | -none
Signal to be used as the default reset signal for checkers. The signal is taken to be a signal in
module. If module is not specified, you must specify the full hierarchical path to signal.
-active_high | -active_low
Polarity of the reset signal. Checker resets are active-high polarity, so specifying
-active_high connects the signal directly and specifying -active_low inverts the signal
before connecting. Default: -active_high.
-sync | -async
Checker reset port: reset (-sync) or areset (-async). Typically, only one type of reset is used
for the design and the other checker reset ports are tied to zero. Default: -sync
-infer
Infers the reset for each checker and only uses signal if the inference is not successful. This
option can reduce ccl checker (i.e., simulation) compilation performance. Default: no
inference.
-module module
Module name or wildcard pattern (pattern must match exactly one module). Default:
checkers in all modules (if specified in a control file) or the current module (if specified in a
source code module).
Activate Default Reset Inference
default_reset -infer [-sync | -async | -sync -async] [-module module]
-infer
Infers the reset for each checker and uses 1b0 if the inference is not successful. This option
can reduce checker (i.e., simulation) compilation performance. Default: no inference.
-sync | -async | -sync -async

Checker reset ports: reset (-sync), areset (-async) or both. Typically, only one type of reset is
used for the design and the other checker reset ports are tied to zero. Default: -sync
318

October 2011
Command Reference
default_reset
-module module
Module name or wildcard pattern (pattern must match exactly one module). Default:
checkers in all modules (signal must be a hierarchical path).
Description
Checker reset signals are not used by the SVA and PSL checkers, and they are explicitly
identified in the instantiations of OVL and QVL checkers. CheckerWare checkers have two
reset ports: reset (synchronous) and areset (asynchronous). Connection to these ports can be
specified in the checker directive for a checker with the -reset and -areset arguments. When
both connections are not specified, the missing connections are determined from the
specification of default_reset global directives and by reset signal inference.
Inferring reset connections (and similarly clock connections) can be expensive in terms of lower
compilation performance.
The default_reset directive has two basic uses and the syntax depends on the usage:
Identifies a default reset signal for CheckerWare checkers.
A specific reset signal is provided as the default reset for checkers in the DUT or for a
particular module. The -active_low option inverts the signal before connecting. The
-sync or -async option identifies which reset ports to connect. The -infer option directs
the compiler to try to infer the connection before assigning the default reset.
Activates the inference of default resets.

By default, if a connection to a checker reset port is not covered by an explicit checker
directive (i.e., -reset signal or -areset signal argument) or by a default_reset signal
global directive, then the reset port is connected to 1b0. Specifying the inference
activation form of the default_reset directive directs the compiler to try to infer the
connection before assigning 1b0.
Note
The default_reset directives identify reset signals for CheckerWare directives only. To
properly detect async_reset and async_reset_no_sync CDC schemes, you must identify
the reset signals with the set_reset directive.

October 2011
319
Command Reference
disable_checker
disable_checker
Identifies a signal that can disable checkers during simulation.
Syntax
disable_checker signal [severity level] [name checker] [type type]
[module module [local]]
signal
Signal to use to disable matching checkers.
-severity level
Severity level of checkers to disable with signal. Default: all levels.
-name checker
Checker name or wildcard pattern. Default: *.
-type type
Checker type or wildcard pattern. Default: *.
-module module
Module name or wildcard pattern. Default: all modules.
-local
Restrict the directive to checkers in the top-level of module. Default: module hierarchy.
Description
The disable_checker global directive specifies a signal that dynamically disables specified
checkers during simulation. When ccl synthesizes a checker, it derives the signal to connect to
the checkers active input from the AND of the inverted disabling signal, any activation
condition (<), if specified and any active option signal, if specified.
320

October 2011
Command Reference
disable_used
disable_used
Disables the -used option of CheckerWare checkers of a given type.
Syntax
disable_used -type type [-module module [-local]]
-type type
Checker type or wildcard pattern.
-module module
-local
Restricts the directive to checkers in the top-level of module. Default: module hierarchy.
Description
Overrides the -used option of CheckerWare checkers that have the specified checker type. The
-used option constrains a checker to fire only if at least one downstream register samples at least
one bit of the value on the element being checked (this constraint is called the used_condition).
In general, used_condition is composed of the conditions in which downstream registers load a
value, and the muxing/combinational logic (between the downstream registers and the element
being checked) is turned on to allow the value to flow through combinationally to the
downstream registers.
Example
//0in disable_used -type one_hot

October 2011
321
Command Reference
exclude_checker
exclude_checker
Excludes the specified checkers from formal verification (and simulation with assertions).
Syntax
exclude_checker [-severity level] [-name checker] [-type type] [-group group]
[-module module [-local]]
-severity level
Severity level of checkers to exclude. Default: all levels.
-name checker
Checker name or wildcard pattern.
-type type
-group group
Group name or wildcard pattern.
-module module
-local
Restrict the directive to checkers in the top-level module. Default: module hierarchy.
Description
Identifies checkers to exclude from the formal model by the csl compiler. The -group, -type and
-name options restrict the directive to checkers with the specified checker group, checker type
or checker name. The wildcard character * matches zero or more characters. Use the
include_checker directive to override checkers specified with wildcards in exclude_checker
directives. For example:
// 0in exclude_checker -type * -module sync3_r
// 0in include_checker -type fire -module sync3_r
In the -name option, the wildcard can match the hierarchy delimiter. For example:
-name tb.*.state*
matches the names:

tb.cpu1.fifo16.state_cur
tb.cpu2.fifo16.state_next
322

October 2011
Command Reference
include_checker
include_checker
Includes the specified checkers in the formal model and checker compilation.
Syntax
include_checker [-severity level] [-name checker] [-type type] [-group group]
[-module module [-local]]
-severity level
Severity level of checkers to include. Default: all levels.
-name checker
-type type
-group group
Group name or wildcard pattern.
-module module
-local
Restricts the directive to checkers in the top-level module. Default: module hierarchy.
Description
Identifies checkers to compile by the ccl/csl compiler even if they are specified in an
exclude_checker directive. The -group, -type and -name options restrict the directive to
checkers with the specified checker group, checker type or checker name. The wildcard
character * matches zero or more characters. Use the include_checker directive to override
checkers specified with wildcards in exclude_checker directives. For example:
// 0in exclude_checker -type * -module sync3_r
// 0in include_checker -type fire -module sync3_r
In the -name option, the wildcard can match the hierarchy delimiter. For example:
-name tb.*.state*
matches the names:

tb.cpu2.fifo16.state_next

October 2011
323
Command Reference
set_checker_action
set_checker_action
Specifies the action to perform when the number of simulation firings of checkers having a
given severity level reaches the specified count.
Syntax
set_checker_action [-count count ] [-stop | -finish] [-severity level] [-module module]
-count count
Total number of firings for all checkers of the specified severity. When the number of
firings of the specified severity reaches this count, the simulation performs the specified
action of -stop or -finish.
-stop
Stop the simulation, but you can restart the session.
-finish
End the simulation. By default, the simulation ends 10 time units after the last firing. Use
the +0in_checker_finish_delay+time ccl option to change this default.
-severity level
The directive specifies a single severity level (positive digit 0 to 9) and an optional count.
Severity level 0 sets the default checker action.
-module module
Restrict the global directive to checkers in the specified module.
Description
Each set_checker_action global directive specifies the action to perform when the number of
firings of checkers having a given severity level reaches the specified count. This directive only
applies to simulation.
324

October 2011
Command Reference
set_severity
set_severity
Assigns a severity level to specified checkers.
Syntax
set_severity
[-severity level [-default]] [-name checker_pattern] [-type type_pattern]
[-module module_pattern [-local]]
-severity level
Severity level to assign to matching checkers (0 - 9). Default: no severity.
-default
Restricts the directive to checkers that have default severity. CheckerWare checkers that do
not have a -severity level argument in the original checker directive have default severity.
PSL and SVA checkers also have default severity.
-name checker_pattern
-type type_pattern
-local
Description
Overrides the severity level of specified checkers. A checkers can have no severity (called the
default severity) or it can have a value in the range 0 to 9 assigned as its severity level. Ranking
is up to you (default might have level 0 or level 10). Severity levels are used primarily in
simulation with assertions to affect the simulator response to checker firings.
Example
The following directives exclude psl and decrement checkers.
// 0in set_severity -severity 7 -type psl
// 0in set_severity -severity 7 -type decrement
// 0in exclude_checker -severity 7

October 2011
325
Command Reference
use_synthesis_case_directives
Creates case checkers for matching non-native (e.g., synthesis) case directives.
Syntax
[-min_width width] [-min_item_count count]
[-max_width width] [-max_item_count count]
[-used] [-module module [-local]]
-min_width width
Minimum width of the case switch.
-min_item_count count
Minimum number of case items in the statement.
-max_width width
Maximum width of the case switch.
-max_item_count count
Maximum number of case items in the statement.
-used
Adds the -used argument to the generated case checkers. A generated case checker can fire
only when at least one bit of a variable assigned in the active case block is loaded into a
destination register.
-module module
-local
Description
Creates case checkers for non-native case directives in the HDL code. These are directives of
the following form:
// product [full_case] [parallel_case]
Where product indicates the identifier for the non-native synthesis product (for example,
synopsys or synthesis).
326

October 2011
Command Reference
Shell Commands
Shell Commands
Three types of shell commands are used in CDC analysis:
Compiler commands The Questa compiler commands handle front-end compilation

of the design logic for CDC analysis. Questa tools support the same design styles and
HDL constructs.
The vlib command sets up the working library for compiling the design units for
CDC analysis.
The vmap command maps logical library names to physical directories.
The vcom command compiles VHDL source files.
The vlog command compiles Verilog (and SystemVerilog) source files.
The verror command reports additional detail for messages.
The vdir command reports information about design units in libraries.
The vdel command deletes design units from libraries.
0in shell The compilation environment for CDC, the Questa Formal tools and
assertions in simulation is controlled from a special verification command shell called
the 0in shell, invoked from the system shell by the 0in shell command.
CDC GUI The 0in_cdc command runs the CDC GUI.
Simulation commands The ccl 0in shell command generates the assertion logic for
simulation with assertions. Using the data generated by ccl and a set of simulation-time
simulator arguments, you run simulation with assertions using a native
(Questa/ModelSim) simulator or a third-party simulator (VCS/NC-Verilog).

October 2011
327
Command Reference
vlib
vlib
Creates a design library for use by vmap/vcom/vlog, and sets accessibility to design units in a
library (or to the entire library).
Syntax
vlib
[-locklib | -unlocklib] [{-lock | -unlock} design_unit] library
-locklib
Locks the library so the library cannot be overwritten by the compilers.
-unlocklib
Unlocks the library so the library can be overwritten by the compilers.
{-lock | -unlock} design_unit

Locks/unlocks the specified design unit (module) in the library so it cannot be refreshed or
recompiled. File permissions are not affected by these switches
library
Name to identify the library. The name work is the default working library: a library work
statement is not needed in the source and work is the default destination of compiled units
(so work need not be mapped). Must be the last argument.
Description
Two types of design libraries are used with the Questa tools:
resource libraries
Static libraries used by the source code for your design. Pre-compiled resource libraries
are typically supplied by a third party (for example, models of gate-level netlists) or
another design team. But, you also can specify resource libraries when compiling the
design (after using vlib to create the library). For a Verilog library, use the -L option to
vlog. For a VHDL library, use the -work library option to vcom to specify the library
name for the compiled VHDL resource library, so it is not saved as the work library.
Within a VHDL source file, use a VHDL library clause to specify names of resource
libraries referenced in the design unit.
working library
Dynamic library containing executable code, debug information, dependency
information and other data for compiling a design. Only one library is the working
library for analyzing a design. The library named work is the default assumed working
library. But, you still must use vlib to create the working library:
system prompt> vlib work
328

October 2011
Command Reference
vmap
vmap
Creates a logical-to-physical mapping for a design library, removes logical-to-physical
mappings or reports current mappings
Syntax
vmap
[-modelsimini init_file [-c]] [logical_name [dir] | -del logical_name]
-modelsimini init_file
Add the mapping to the compiler initialization file init_file. Default: ./modelsim.ini (copied
from the distribution software if ./modelsim.ini does not exist.
-c
Copy init_file to ./modelsim.ini and add the mapping to ./modelsim.ini. However, if
./modelsim.ini exists and is write-protected, add the mapping to init_file instead.
logical_name
Name to map or un-map. Default: reports the current logical-to-physical mappings (from
modelsim.ini).
dir
Physical directory to which the logical name should map. Default: prints the current logicalto-physical mapping for logical_name.
-del logical_name
Un-map the logical-to-physical mappings for the specified logical_name list.
Description
The vlib command creates a design library with a given logical name and stores the library
information in a directory with the same name in the current directory. By default, the library
name is mapped to the directory name. The vmap command is used to change this logical-tophysical mapping and to manage logical-to-physical mappings. Non-default logical-to-physical
mappings are stored in the modelsim.ini file in the current directory.
Examples
Example 1
system prompt> vmap
Reports the current mappings.

Example 2
system prompt> vmap work
Reports the current mapping for the work library.

October 2011
329
Command Reference
vmap
Example 3
system prompt> vmap work ../shiba/my_work
Copying path/modelsim.ini to modelsim.ini
Maps the work library to ../shiba/my_work. Copies modelsim.ini from the software installation
to the current directory and adds the mapping to ./modelsim.ini.
Example 4
system prompt> vmap -modelsimini ../shiba/modelsim.ini \
work ../shiba/my_work
Modifying ../shiba/modelsim.ini
Maps the work library to ../shiba/my_work and adds the mapping to ../shiba/modelsim.ini.
Example 5
system prompt> ls
work
system prompt> vmap -modelsimini -c ../shiba/modelsim.ini \
Copying ../shiba/modelsim.ini to modelsim.ini
** Warning: Copied ../shiba/modelsim.ini to modelsim.ini.
Updated modelsim.ini.
MODELSIM set to ../shiba/modelsim.ini.
The MODELSIM environment variable is used to find the modelsim.ini
file, so this local copy will not be used.
Maps the work library to ../shiba/my_work, copies ../shiba/modelsim.ini to ./modelsim.ini and

adds the mapping to ./modelsim.ini.
Example 6
system prompt> ls
modelsim.ini work
system prompt> chmod a-w modelsim.ini
system prompt> vmap -modelsimini -c ../shiba/modelsim.ini \
Copying ../shiba/modelsim.ini to modelsim.ini
** Error: (vmap-7) Failed to open ini file "modelsim.ini" in write mode.
Permission denied. (errno = EACCES)
Modifying ../shiba/modelsim.ini
** Warning: vmap will not overwrite local modelsim.ini.
MODELSIM set to ../shiba/modelsim.ini.
../shiba/modelsim.ini was modified because copy failed
The MODELSIM environment variable is used to find the modelsim.ini
file, so this local copy will not be used.
Maps the work library to ../shiba/my_work and adds the mapping to ./modelsim.ini.
330

October 2011
Command Reference
vmap
Example 7
system prompt> vmap -del work
Removing reference to logical library work
Un-maps any existing mapping for the work library and restores the mapping to the default
directory for the library (./work).
Example 8
system prompt> vmap -del ZLIB YLIB
Removing reference to logical library ZLIB
Removing reference to logical library YLIB
Un-maps any existing mappings for the ZLIB and YLIB libraries and restores the mappings to
the default directories (./ZLIB and ./YLIB).

October 2011
331
Command Reference
vcom
vcom
Compiles VHDL source files into a design or resource library.
Syntax
vcom
[-version] [-work logical_name] [modelsimini init_file] [-87 | -93 | -2002 | -2008]
[-explicit] [skipsynthoffregion [synthprefix keyword]] [-check_synthesis]
[-noindexcheck | -norangecheck | -nocheck] [-source] [-time] [-mixedsvvh [b | l | r] [i]]
[-pslfile vunit_file] [-lower | -preserve] [-l file] [-quiet] [-nowarn number]
[{-fatal | -error | -warning | -note | -suppress | msglimit} msg_number [,msg_number]...]...
[-f arg_file] [other_vcom_options] VHDL_file
-version
Report the Questa version and exit.
-work logical_name
Name of the design library to use as the destination for the compilation. Default: work.
-modelsimini init_file
Load init_file as the compiler initialization (modelsim.ini) file. Default: search path shown
in Figure 3-4 on page 59.
-87 | -93 | -2002 | -2008

VHDL version: VHDL-87, VHDL-93, VHDL-2002 or VHDL-2008. Default: value
specified by the VHDL93 variable (default 2002) in modelsim.ini.
-explicit
Resolve ambiguous function overloading in favor of the explicit definition. Default: value
specified by the Explicit variable (default on) in modelsim.ini. Having Explicit set in
modelsim.ini makes the compiler compatible with common industry practice. Commenting
out Explicit favors implicit definitions, which matches the VHDL standard.
-skipsynthoffregion
Do not parse synthesis off and translate off regions of HDL code. Keywords for synthesis
off/on and translate off/on pragmas are: pragma, synthesis, synopsys, 0in, mentor, mspa, mti
and vcs, plus custom keywords specified with the -synthprefix keyword argument. Default:
HDL code in synthesis off and translate off regions is parsed and made ready for use in
simulation and Questa CDC/Formal.
Use this option to avoid parsing synthesis/translate off region code that might be
syntactically or semantically incorrect. However, if you specify -skipsynthoffregion, the
design library is not suitable for simulation. Therefore, Questa simulator users should try to
avoid using this option.
332

October 2011
Command Reference
vcom
-synthprefix keyword
Synthesis off/on pragma keyword. Skip (i.e., ignore and do not parse) code in <keyword>
synthesis_off regions and <keyword> translate_off regions. For example if you specify
-synthprefix zin, the following regions of code are ignored.
-- zin synthesis_off
VDHL code to ignore
-- zin synthesis_on
// zin translate_off
Verilog code to ignore
// zin translate_on
Default synthesis off/on keywords: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and
vcs.
-check_synthesis
Perform limited synthesis rule checks (for example, process signals are in the process
sensitivity list). Default: value specified by the CheckSynthesis variable (default off) in
modelsim.ini.
-noindexcheck | -norangecheck | -nocheck

Do not check that indexes are in bounds (-noindexcheck); do not check that scalar values are
defined in their ranges (-norangecheck); or do not perform either of these checks
(-nocheck). These options can speed up compilation of large designs. Default: values
specified by the NoIndexCheck and NoRangeCheck variables (default off, i.e., checking
enabled) in modelsim.ini.
-source
Include corresponding source code line numbers in messages.
-time
Report the process time (actual time, not CPU time) taken for the compilation.
-mixedsvvh [b | l | r] [i]
Compile VHDL packages so they can be included in a SystemVerilog design. Qualifiers
have the following meanings:
b
l
r
i
scalars and vectors have SystemVerilog bit type

scalars and vectors have SystemVerilog logic type
scalars and vectors have SystemVerilog reg type
ignore the ranges specified with VHDL integer types
Default: see VHDL to SystemVerilog Data Types Mapping.
-pslfile vunit_file
PSL VHDL flavor vunit file to bind and compile. Vunits must be compiled at the same time
as the design units to which they are bound.

October 2011
333
Command Reference
vcom
-lower | -preserve
Store VHDL identifiers in lower case (-lower) or with the same case as the VHDL code
(-preserve). However, the following objects always are converted to lower case: VHDL
design unit names and basic VHDL identifiers in packages compiled with -mixedsvvh.
Preserving case does not make VHDL compilation case sensitive. These options set the case
of stored names of signals, functions, procedure, instances, variables, and constants in
messages, the GUI, reports, VCD output, WLF files, coverage reports and so on. Default:
value specified by the PreserveCase variable (default on) in modelsim.ini.
-l file
Write the log to file.
-quiet
Do not report loading messages.
-nowarn number
Do not report warning messages for number category:
1
2
3
4
5
6
7
unbound component
process without a wait statement
null range
no space in time literal
multiple drivers on unresolved signal
VITAL compliance checks
VITAL optimization messages
8
9
10
11
13
14
lint checks
signal value dependency at elaboration
VHDL-93 constructs in VHDL-87 code
PSL warnings
constructs that coverage cannot handle
locally static error deferred until
Use verror 1907 to seem them.
{-fatal | -warning | -note | -suppress | -msglimit} msg_number [,msg_number]

Change the severity, suppress the reporting, or limit to 5 the number of reported instances of
the specified messages. You cannot suppress/limit fatal/internal messages. Default:
severities set in the [msg_system] section of modelsim.ini, which overrides the default
settings from the compiler.
-f arg_file
File containing additional command arguments. Argument files have the following syntax
rules:
334
newlines treated as spaces.
// text to the end of the line is ignored.
/* text */ text (including newlines) is ignored.
single quotes (text) groups text and prevents character substitution (such as variable
expansion and character escapes).

October 2011
Command Reference
vcom
double quotes (text) groups text and prevents character substitution except for
backslash escape and environment variable substitution. For example:
// groups argument with spaces and substitutes value for $TIME_UNIT
-timescale "$TIME_UNIT / 1 ps"
environmental variables are expanded unless preceded by a backslash (for example,

\$USER) or in single quotes (for example, $USER).
-f arg_file can be nested inside an argument file.
other_vcom_options
Options only relevant to simulation do not affect the CDC compiler. But other advanced
options might affect tool resultsthese are described in the Questa documentation.
VHDL_file
Files containing VHDL source code to compile. Wildcards are supported (e.g., *.vhd).
Design units are compiled in the order they appear.
Description
The vcom command compiles one or more VHDL source files into a design library. Before
using this command, use the vlib command to create the initial design library. Subsequent
applications of vcom can be used to incrementally compile and recompile the VHDL portion of
the design. For VHDL, compile order is important. You must compile entities and
configurations before architectures that reference them.
Examples
Example 1
system prompt> vcom dut.vhd
Compiles dut.vhd into the work library.

Example 2
system prompt> vcom -work my_work block1.vhd block2.vhd top.vhd
Compiles block1.vhd, block2.vhd and top.vhd (in that order) into the my_work library.
Example 3
system prompt> vcom -2008 block1.vhd
system prompt> vcom block2.vhd top.vhd
Creates a work library; compiles the VHDL-2008 flavor block1.vhd file; then compiles the
VHDL-2002 (default) flavor block2.vhd and top.vhd files.

October 2011
335
Command Reference
vlog
vlog
Compiles Verilog source files into a design or resource library.
Syntax
vlog
[-version] [-work logical_name] [-libmap library_map_file [-libmap_verbose]]
[-modelsimini init_file] [{-Lf | -L } library] [-vlog95compat | -vlog01compat]
[-sv] [sv05compat | sv09compat] [-skipsynthoffregion [-synthprefix keyword]]
[-skipprotected | -skipprotectedmodule] [-pedanticerrors] [-mixedansiports]
[-timescale units/precision | -override_timescale units/precision]
[+define{+macro[=value}] [-convertallparams] [+floatparameters[+param_path[.]]]
[+incdir{+include_dir}] [+libext{+extension}] [-y library_dir]
[-v library_file] [-compile_uselibs[=uselib_dir]] [-printinfilenames] [-source] [-time] [-93]
[-u] [-mixedsvvh [b | s | v] [packedstruct]] [-mfcu [-cuname comp_unit] | -sfcu]
[-pslfile vunit_file] [-l file] [-quiet] [-nowarnID | -nowarn number]
[{-fatal | -error | -warning | -note | -suppress | -msglimit} msg_number [,msg_number]...]...
[-f arg_file] [other_vlog_options] Verilog_file
version
Report the Questa version and exit.
work logical_name
Name of the library to use as the destination for the compilation. Default: work.
libmap library_map_file
Verilog 2001 logical-to-physical library map file.
libmap_verbose
Report library map pattern matching information to troubleshoot problems with matching
filename patterns in the library file.
modelsimini init_file
Load init_file as the compiler initialization (modelsim.ini) file. Default: search path shown
in Figure 3-4 on page 59.
Lf library | L library
Resource library containing pre-compiled modules for the compilation. With the Lf
argument, library is searched before searching in the effective uselib library (if specified)
for the instantiation. With the L argument, library is searched after searching the effective
uselib library. The LibrarySearchPath variable defines an initial resource library search
path. When searching for a module for an instantiation, the libraries specified by
LibrarySearchPath are searched in (left-to-right) order, as if they were specified with the L
argument. If no match is found, the libraries specified in the Lf and L options are searched
in the order specified in the command invocation.
336

October 2011
Command Reference
vlog
vlog95compat | vlog01compat
Assume the IEEE 1364-1995 standard (-vlog95compat) or the IEEE 1364-2001 standard
(-vlog01compat). These two Verilog standards have some conflicts, so running the correct
compatibility ensures valid code is compiled properly. Default: value specified by the
vlog95compat variable (default off, i.e., 2001) in modelsim.ini.
sv
Recognize SystemVerilog source code in all files. Default: SystemVerilog source code is
recognized only in files with .sv extensions.
sv05compat | sv09compat
Assume the IEEE 1800-2005 standard (-sv05compat) or the IEEE 1800-2009 standard
(-sv09compat). These two SystemVerilog standards have some conflicts, so running the
correct compatibility ensures valid code is compiled properly. Default: value specified by
the sv09compat variable (default off, i.e., 2005) in modelsim.ini.
skipsynthoffregion
Do not parse synthesis off and translate off regions of HDL code. Keywords for synthesis
off/on and translate off/on pragmas are: pragma, synthesis, synopsys, 0in, mentor, mspa, mti
and vcs, plus custom keywords specified with the -synthprefix keyword argument. Default:
HDL code in synthesis off and translate off regions is parsed and made ready for use in
simulation and Questa CDC/Formal analysis.
Use this option to avoid parsing synthesis/translate off region code that might be
syntactically or semantically incorrect. However, if you specify -skipsynthoffregion, the
design library is not suitable for simulation. Therefore, Questa simulator users should try to
avoid using this option.
synthprefix keyword
Synthesis off/on pragma keyword. Skip (i.e., ignore and do not parse) code in <keyword>
synthesis_off regions and <keyword> translate_off regions. For example if you specify
-synthprefix zin, the following regions of code are ignored.
-- zin synthesis_off
VDHL code to ignore
-- zin synthesis_on
// zin translate_off
Verilog code to ignore
// zin translate_on
Default synthesis off/on keywords: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and
vcs.

October 2011
337
Command Reference
vlog
skipprotected
Ignore (do not parse or compile) protected regions of HDL code (inside
protected/endprotected regions). Default: compile code inside protected/endprotected
regions and assume that the HDL code in these regions is encrypted and must be decrypted
before parsing.
skipprotectedmodule
Exclude modules containing protected/endprotected regions from being added to the
library. However, check each of these modules for syntax errors until a protected pragma is
encountered. Default: modules containing protected regions are compiled and added to the
library.
This first example has a Verilog syntax error after the protected pragma:
module test(input in, output out);
protected reg tmp; endprotected
hello;
assign out = tmp && in;
endmodule
With the skipprotected option, the syntax error is reported:

prompt> vlog test.v -skipprotected
-- Compiling module test
** Warning: test.v(2): (vlog-2280) Skipping protected region.
** Error: test.v(3): near ";": syntax error, unexpected ;
With the skipprotectedmodule option the syntax error is not reported:

prompt> vlog test.v -skipprotectedmodule
** Warning: test.v(2): (vlog-2281) Skipping module containing
protected region.
This second example has a Verilog syntax error before the protected pragma:
module test(input in, output out);
hello;
protected reg tmp; endprotected
assign out = tmp && in;
endmodule
With the skipprotectedmodule option the syntax error is reported, because it is seen before
the first protected pragma:
prompt> vlog test.v -skipprotectedmodule
** Error: test.v(2): near ";": syntax error, unexpected ;
** Warning: test.v(3): (vlog-2281) Skipping module containing
protected region.
General rule: Try -skipprotected first, then if there is still a syntax error, try
-skipprotectedmodule.
338

October 2011
Command Reference
vlog
pedanticerrors
Report mismatched else directives and enforce the following IEEE Verilog Standard 18002005 restrictions:
new for queues is illegal. Default: new creates a queue whose elements are initialized
to the default value of the queue element type.
Sized, based literals containing underscore characters (for example, 8b0110_0110)

are illegal. Default: these constructs are legal.
Class extern method prototypes with lifetime (automatic/static) designations are

illegal. Default: these constructs generate LRM-compliance warnings.
PSL statements with cover bool@clk constructs are illegal. Default: these constructs
are legal.
mixedansiports
Allows mixing of ANSI-style and non-ANSI-style port declarations, which can cause
runtime errors when redefined types do not match. The following example shows such a
port re-declaration:
module a (input sig);
reg sig;
. . .
endmodule
Default: a redefined ANSI-style port generates a vlog-2248 warning: Port port already
declared (ANSI Style) in this scope (scope).
timescale units/precision
Default timescale for modules. Precision must be units and both units and precision have
the form:
{1 | 10 | 100}{fs | ps | ns | us | ms | s}
For example: timescale 10ns/100ps.
override_timescale timescale
Timescale to use for the compilation. Default: timescales specified in the source files and
the default timescale set by -timescale.
+define{+macro[=value]}
Text macro specification. Overrides any matching define compiler directives.
convertallparams
Compile non-ANSI parameters so they can be translated into std_logic_vector, bit_vector,
std_logic, vl_logic, vl_logic_vector, and bit generics when interfacing with VHDL design
units.

October 2011
339
Command Reference
vlog
+floatparameters[+param_path[.]]
Do not evaluate specified parameters, so they can be overridden by -g/-G options to csl and
vsim. The param_path is a module, module/parameter, hierarchical path to an instance, or
hierarchical path to a parameter in an instance. Specifying a period (.) applies the argument
recursively to instances in param_path. Default param_path: all parameters.
+incdir+include_dir
Input include directory.
+libext{+extension}
File extensions to use when searching for library files. For example, +libext+.v.
y library_dir
v library_file
Library file.
compile_uselibs[=uselib_dir]
Compile uselib source files into uselib_dir directory and update modelsim.ini with the
logical-to-physical mappings for the uselib libraries. The uselib directives are persistent:
the last uselib directive in a file applies to the rest of the code in the fileand to the code in
subsequent files in the vlog invocation, up to the next uselib directive. You can specify an
empty uselib directive at the end of a file to prevent the effect of the last uselib directive
from carrying over to the next file. Default uselib directory: $MTI_USELIB_DIR (if
defined) in the current directory, otherwise mti_uselibs in the current directory.
printinfilenames
Print the paths of all source files opened during the session, including include files.
source
Include corresponding source code line numbers in messages.
time
Report the process time (actual time, not CPU time) taken for the compilation.
93
Use VHDL-1993 extended identifiers when interfacing with VHDL design units, to
preserve case in Verilog identifiers that contain upper-case letters.
u
Convert identifiers to upper case.
340

October 2011
Command Reference
vlog
mixedsvvh [b | s| v] [packedstruct]
Compile SystemVerilog packages so they can be included as packages in a VHDL design.
Qualifiers have the following meanings:
b
s
v
packedstruct
scalars and vectors are VHDL bit/bit_vector types

scalars and vectors are VHDL std_logic/std_logic_vector types
scalars and vectors are VHDL vl_logic/vl_logic_vector types
packed structures are VHDL arrays with equivalent sizes
Default: see SystemVerilog-to-VHDL Data Types Mapping.
mfcu
Compile the named source files into a single compilation unit (i.e., a multi-file compilation
unit). Default: value specified by the MultiFileCompilationUnit variable (default off) in
modelsim.ini. If multi-file compilation units are not enabled, a compilation unit is created
for each source file, which matches the SystemVerilog standard.
cuname comp_unit
Name to give the compilation unit created by -mfcu. Use this option if a module has a bind
statement, but no module in the design depends on the resulting compilation unit. In this
case, the bind statement would not be elaborated by csl or vsim. For these tools, naming
comp_unit forces elaboration of the compilation unit package (including the bind
statement), which otherwise would not be elaborated. If specified, you must also specify the
comp_unit to csl/cdc (with the -cuname option). Though the vsim command accepts only a
single comp_unit name, csl/cdc accept multiple comp_unit names.
sfcu
Compile the named source files into individual compilation units (i.e., single-file
compilation units). Default: value specified by the MultiFileCompilationUnit variable
(default off) in modelsim.ini. If MultiFileCompilationUnit is not set to 1, -sfcu is not needed.
pslfile vunit_file
PSL Verilog flavor vunit file to bind and compile. Vunits must be compiled at the same time
as the design units to which they are bound.
l file
Write the log to file.
quiet
Do not report loading messages.
nowarnID | nowarn number

Do not report warning messages for ID or number category. ID is an identifier for a class of
messagesit appears in square brackets in the message. For example, ID is RDGN in the
following message:
** Warning: test.v(15): [RDGN] - Redundant digits in numeric literal.

October 2011
341
Command Reference
vlog
The argument to filter out RDGN warnings is: -nowarnRDGN. Warning category numbers
identify broad categories of messages:
11 PSL warnings
12 non-LRM compliance to match
alien simulator behavior
13 constructs that code coverage

cannot handle
15 SystemVerilog assertions using
local variables
{fatal | warning | note | suppress | msglimit} msg_number [,msg_number]

Change the severity, suppress the reporting, or limit to 5 the number of reported instances of
the specified messages. You cannot suppress/limit fatal/internal messages. Default:
severities set in the [msg_system] section of modelsim.ini, which overrides the default
settings from the compiler.
f arg_file
File containing additional command arguments. Argument files have the following syntax
rules:
newlines treated as spaces.
// text to the end of the line is ignored.
/* text */ text (including newlines) is ignored.
single quotes (text) groups text and prevents character substitution (such as variable
expansion and character escapes).
double quotes (text) groups text and prevents character substitution except for
backslash escape and environment variable substitution. For example:
// groups argument with spaces and substitutes value for $TIME_UNIT
-timescale "$TIME_UNIT / 1 ps"
environmental variables are expanded unless preceded by a backslash (for example,

\$USER) or in single quotes (for example, $USER).
f arg_file can be nested inside an argument file.
other_vlog_options
Options only relevant to simulation (which do not affect the Questa CDC/Formal tools).
Other advanced options might affect tool resultsthese are described in the Questa
documentation.
Verilog_file
Files containing Verilog source code to compile. Wildcards are supported (e.g., *.v *.sv).
Description
The vlog command compiles one or more Verilog/SystemVerilog source files into a design
library. Before using this command, use the vlib command to create the initial design library.
342

October 2011
Command Reference
vlog
Subsequent applications of vlog can be used to incrementally compile and recompile the
Verilog portion of the design.
Examples
Example 1
system prompt> vlog dut.v
Compiles dut.v into the work library.

Example 2
system prompt> vlog -work my_work block1.v block2.v top.sv
Compiles block1.v, block2.v and top.sv into the my_work library.

Example 3
system prompt> vlog -vlog95compat block1.v
system prompt> vcom block2.v top.sv
Creates a work library; compiles the Verilog-95 flavor block1.v file; then compiles the
Verilog-2001 (default) flavor block2.v and SystemVerilog top.sv files.

October 2011
343
Command Reference
verror
verror
Reports detailed information about Questa utility errors.
Syntax
verror
[ ranges | [[fmt] [tag] | full] {message_number | [kind tool] -all} ]
ranges
Report the numeric ranges of message numbers for all tools. Numbers missing from the
ranges are invalid messages. For example, 126 is not in a range so verror 126 returns:
** Error: Invalid message number 126.
fmt, tag, full

Type of information to report for a message:
fmt format string for the message, for example:
Failed to access library %s at "%s"
.
tag message tag, for example:

MSG_IDX_LIBRARY_ACCESS_FAILED
Specify both fmt and tag to report the format string and the tag. Specify full to report this
information plus a detailed message. Default: report the detailed message only.
message_number
List of message numbers. For example, the following vlog error message has message
number 19:
Vlog error.(vlog-19) Failed to access library work at "work".
Information is reported for each specified message number.
kind tool all

Group of messages to report. The tool can be any of common, vcom, vcom-vlog, vlog, vsim,
vsim-vish, wlf, vsim-sccom, sccom, vsim-systemc, ucdb, vsim-vlog or pseudo_synth. The all
argument is required. Default tool: messages for all tools are reported.
Description
Error/warning messages reported by Questa tools are terse. Use the verror command to get
detailed information about messages.
344

October 2011
Command Reference
verror
Examples
Example 1
system 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.
Example 2
system prompt> verror -ranges
common:
1-98 (98)
100-125 (26)
129-148 (20)
151
(1)
. . .
pseudo_synth:
9001-9009 (9)
9100-9120 (21)
9200-9207 (8)
9300-9306 (7)
9308-9339 (32)
9401-9411 (11)
9600-9639 (40)
9650-9685 (36)
Total number of messages = 2703.

October 2011
345
Command Reference
vdir
vdir
Reports information about the contents of a library.
Syntax
vdir
[prop id | l] [r] [modelsimini file] [all | [lib library] [design_unit]]
prop id
Report the information specified by id for each design unit.
id
archcfg
bbox
body
default
dir
dpnd
entcfg
extern
inline
lock
lrm
Information
Configuration for architecture
Black box for optimized design
Needs a body
Compile defaults
Source directory
Depends on
Configuration for entity
Package reference number
Module inlined
Design unit locked/unlocked
VHDL language standard
id
mtime
name
opcode
options
fulloptions
root
src
top
ver
vlogv
voptv
Information
Source modified time
Short name
Opcode format
Compile options
Full compile options
Optimized Verilog design root
Source file
Top-level model
Version string
Verilog version
Verilog optimized version
Default: no detailed information is reported.
l
Report all the information in the above table for each design unit.
r
Report the architectures for each VHDL entity.
modelsimini file
Use file as the modelsim.ini file to determine the library or libraries. Default: ./modelsim.ini.
all
Report information for all libraries. Default: library (or work) only.
lib library
Report information for library (logical or physical library). Default library: work.
design_unit
Design unit to report. Default: all entities, configurations, modules, packages and optimized
design units.
346

October 2011
Command Reference
vdir
Description
The vdir command reports information about the contents of a library. The command with no
arguments lists the design units in the default library (work) with their types. You can specify
another library with the lib library option or specify all the modelsim.ini libraries with the all
option.
The vdir command can report detailed information about the design units. Either specify prop
id to get the information corresponding to a single id, or specify l to report the complete
detailed information about each design unit. The l option produces a lengthy output, so you
might also want to restrict the information reported to a single design_unit.
Examples
Example 1
system prompt> vdir
Library vendor : Model Technology
Maximum unnamed designs : 3
MODULE a_ovl_pci_pcir_fifo_control
MODULE a_pci_monitor
. . .
MODULE pci_pciw_pcir_fifos
ENTITY pci_perr_crit
ENTITY pci_perr_en_crit
MODULE pci_rst_int
ENTITY pci_serr_crit
ENTITY pci_serr_en_crit
MODULE pci_sync_module
MODULE pci_synchronizer_flop
. . .
Example 2
system prompt> vlib -lock wb_slave
system prompt> vdir -prop lock
MODULE a_ovl_pci_pcir_fifo_control
MODULE a_pci_monitor
. . .
MODULE wb_slave
Design unit locked/unlocked: locked
. . .

October 2011
347
Command Reference
vdir
Example 3
system prompt> vdir -l synchronizer_flop
MODULE synchronizer_flop
Package reference number: 1 sv_std std
Depends on: X sv_std std WnQ=;W1Xô9K1PIQTgInR3
Verilog version: 75H<P_OOUP;li]1h@XcB20
Version string: Vz3hiFlX4K>9PJJZjj9EW2
Source directory: /u/ramesh/examples/fv_demo/zin/demo
Source modified time: Thu Oct 29 14:17:15 2009
HDL source file: ../../pci/rtl/verilog/synchronizer_flop.v
Source file: ../../pci/rtl/verilog/synchronizer_flop.v
Start location: ../../pci/rtl/verilog/synchronizer_flop.v:105
Opcode format: QA Baseline: 6.6 - 2149934; VLOG SE Object version 44
Optimized Verilog design root: 1
VHDL language standard: 1
Compile options: -sv -permissive -mixedansiports
-compile_uselibs=/u/ramesh/examples/fv_demo/zin/demo/
log_static/0in_cache/AN/compile_uselibs_output -pslallowseverity
-synthprefix {$s} -synthprefix {$s} -cuname root_cuname -mfcu
+libext+.vlib -L mtiAvm -L mtiOvm -L mtiUPF
348

October 2011
Command Reference
vdel
vdel
Deletes design units from a library.
Syntax
vdel
{all | primary [arch] | allsystemc} [lib library] [modelsimini file] [verbose]
all
Delete the entire library.
Caution
You are not prompted for confirmation. Once deleted, the library cannot be recovered.
primary [arch]
Design unit to delete: primary is the entity, package, configuration, or module; arch is a
specific architecture for primary. If primary is an entity and arch is not specified, all
architectures of primary are deleted. Not supported for SystemC modules.
allsystemc
Delete all SystemC modules.
lib library
Delete from library (logical or physical library). Default library: work.
modelsimini file
Use file as the modelsim.ini file to determine the library. Default: ./modelsim.ini.
verbose
Report progress messages.
Description
The vdel command deletes a design unit from a library, deletes all SystemC modules in a
library, or deletes an entire library.

October 2011
349
Command Reference
vdel
Examples
Example 1
system prompt> vdel shiba -all
Deletes the shiba library.

Example 2
system prompt> vdel xor behavior
Deletes the behavior architecture of the xor entity from the work library.
350

October 2011
Command Reference
0in
0in
Runs the 0in shell.
Syntax
0in [version] [l log_file] [detail detailed_log_file] [nl][limit_messages]
[cache dir] [rel_paths] [od output_dir] [sim {questa | vcs | nc | nc3}]
[licq] [script_file | cmd command_string]
version
Print the version information and exit.
l log_file
Rename the generated 0in shell log file. Default: 0in.log.
detail detailed_log_file
Rename the generated detailed 0in shell log file. Default: 0in_detail.log.
nl
Disable message logging to the detailed log and the 0in shell log. Default: messages are
logged.
limit_messages
Limit the number of messages in the detailed log. For each message type encountered, only
the first 10 messages are logged. Default: all messages are logged.
cache dir
Rename the generated 0in cache directory for the session. Default: 0in_cache in the output
directory.
rel_paths
Uses relative pathnames in generated argument files. Default: full paths.
od output_dir
Directory to store all output files. Default: current directory.
sim {questa | vcs | nc | nc3}

Target simulator: Questa, VCS, NCVerilog, 3step NCVerilog. Default: questa (with the
same version as the vsim executable in the current search path).
licq
Enables license queuing for 0in shell commands. Default: command terminates if the
required license is being used. Use this option to enqueue multiple sessions that are
executed automatically as licenses become available. To do this, include -licq as a 0in shell
command option. For example:
shell prompt> 0in -licq -cmd csl ....

October 2011
351
Command Reference
0in
The following example does not work:

shell prompt> 0in -cmd csl -licq ....
If a license is requested that is not available, then the shell issues the following warning:
0-In Info: Waiting for license key version
When the shell gains the license, it issues the following message and starts processing:
0-In Info: Obtained license key version
Requests in the queue are handled on a first-in, first-out basis, with all requests having the
same priority. You cannot specify a timeout limit for the request; you must issue an interrupt
signal to remove a request from the queue. The -licq option does not apply to licenses for
third-party EDA tools.
script_file
Specifies a script file containing 0in shell commands to run (ignored if cmd is specified).
cmd command_string
Passes the succeeding invoked arguments to the 0in shell as a single command.
Description
The 0in command runs the 0in shell. The 0in shell is a command execution environment for
Questa compilers and functional verification tools. The 0in shell runs the clock-domain crossing
analyzer (cdc). In addition, the 0in shell runs the formal model compiler (csl) and the checker
synthesis compiler (ccl). The 0in shell also runs the vlib, vmap, vcom and vlog design
compilation utilities. The shell runs the versions of these utilities stored in
$HOME_0IN/modeltech/plat.
To run in batch mode, specify a script file. Otherwise the shell runs interactively.
The special 0in shell command help, prints the utilities available to run in the shell. The utility
cwhelp shows syntax of the global directives.
352

October 2011
Command Reference
0in_cdc
0in_cdc
Runs the CDC GUI environment.
Syntax
0in_cdc
[ [db] db_file [restore_state gui_state_file | {mergedb db_file}]
| project_file [restore_state gui_state_file]
| [p project_name ] [hdl_file] [d design] [f verilog_filelist] [vhf vhdl_filelist]
[[ctrl verilog_control_file] [vhctrl vhdl_control_file] | [ctrl_module module]]
[import_ctrl control_file] [v95] [libmapfile library_map_file] [y lib_dir]
[v lib_file] [work library] [od output_dir] [no_directive_error_check]
[+libext{+ext}] [+incdir{+dir}] [+define{+macro[=val]}] [dw]
[sdc_in sdc_file] [sdc_out file] [formal] [block module] [cdcid id] [verbose]
]
db_file
Formal database file (.db) to load.
mergedb db_file
Formal database file (.db) to merge (as with File >Merge Database).
project_file
Project file (.zpf) to load.
p project_name
Project or project file (.zpf) to load. If a project with the name project_name does not exist,
a new project with that name is created.
restore_state gui_state_file
Load the initial state of the GUI windows from gui_state_file. Use File >Export >State to
save the current GUI state to a file. This command also creates a run file having the same
name, but with a _run extension. The run file runs the GUI with the .db file or project and
the -restore_state option. You can use this process to freeze the view of the GUI so you
can examine it later or from another system. Default: state of the GUI windows does not
show the debug tools opened when the project was saved.
hdl_file
HDL files to add to the project.
design
Name of the top-level DUT design unit.
f verilog_filelist
Text file listing Verilog source files. Maximum pathname length: 1024 characters.

October 2011
353
Command Reference
0in_cdc
vhf vhdl_filelist
Text file listing VHDL source files.
ctrl verilog_control_file
Verilog control file.
vhctrl vhdl_control_file
VHDL control file.
ctrl_module module
Module or design unit in the -work library to use as a control file. You can use vcom/vlog to
compile a control file (for example, if a control module or design unit contains modeling
logic), then use the -ctrl_module option to indicate the control modules and control design
units used for analysis.
import_ctrl control_file
Verilog or VHDL control file containing global directives to import so they can be edited in
the directive editor dialogs (as with File >Import >Directives).
v95
Assume Verilog 95 syntax. Default: Verilog 2K.
libmapfile library_map_file
Library mapping file.
y lib_dir
v lib_file
Library file.
work work_dir
GUI work directory. Default: ./work.
od output_dir
Output directory for reports and databases.
no_directive_error_check
Turns off error checking (i.e., signals, ports, modules exist) in the directives dialogs.
+libext{+ext}
File extensions of library files to search for. Example: +libext+.v+.vhd
+incdir{+dir}
Directories containing the include files. Example: +libext+include+../common/include
354

October 2011
Command Reference
0in_cdc
+define{+macro[=val]}
Verilog macro defines. Example: +define+STATIC_FIFO+FIFO_SIZE=16
dw
Compile remodeled versions of DesignWare elements (see dw on page 370).
sdc_in sdc_file
Load the specified SDC file and use the SDC data to set up CDC analysis.
sdc_out file
Write the SDC data to file for use in downstream tools.
formal
Run formal CDC during static CDC analysis.
block module
Treat the module/entities as blocks for hierarchical analysis.
cdcid id
CDC crossing to select and show the corresponding source code.
verbose
Turn on verbose reporting (see cdc on page 364).
Description
The 0in_cdc shell command runs the CDC GUI environment.
Examples
shell prompt> 0in_cdc
Runs the CDC GUI with no data loaded. The blank main window appears.

October 2011
355
Command Reference
0in_cdc
shell_prompt> 0in_cdc -p mem_ctrl -d top -od mem_ctrl_work \

-f ../source/filelist.mem_ctrl -ctrl bin/cdc_control.v \
-vhf mem_ctrl.vh -sdc_in mem_ctrl.sdc
Runs the CDC GUI with specified data and options. Project name is set to mem_ctrl The
main window appears.
CDC > Run CDC
The GUI runs CDC analysis.
File > Save As > Project...
File Name: mem_ctrl.zpf

Save
The GUI saves the project to the mem_ctrl.zpf file in the current directory.
shell prompt> 0in_cdc -p mem_ctrl
The GUI starts up and loads the mem_ctrl project saved in the previous example.
356

October 2011
Command Reference
0in_db2ucdb
0in_db2ucdb
Translates a .db database into a UCDB database; or creates a .do file that excludes certain
AutoCheck violations from coverage metrics calculated by vsim/vcover; or creates a report file
for a specified UCDB.
Syntax
0in_db2ucdb in_file out_file
{prefix hierarchy_prefix prefix_modules module [cdc] | exclude | report}
in_file
Source file for the operation. For UCDB generation and exclusion .do file generation, in_file
is a .db database file (.db). For report file generation, in_file is a UCDB file.
out_file
Name to give the generated file.
prefix hierarchy_prefix
Location in the design library of the generated UCDB scheme.
prefix_modules module
Design units to include in the translation.
cdc
Translate CDC data from the .db database. Default: no CDC data are translated.
exclude
Create a .do file of exclusion commands for input to vsim and do not generate a UCDB file.
report
Create a report file showing the information in the specified UCDB file.
Description
The 0in_db2ucdb command has three functions:
Translate a .db file to a UCDB file. For example:

0in_db2ucdb 0in_confirm.db 0in.ucdb -prefix work.tb.dut \
-prefix_modules tb dut
Create an exclusion .do file from a .db file. For example:

0in_db2ucdb 0in_autocheck.db 0in.do -exclude
Create a report from a UCDB file. For example:

0in_db2ucdb 0in.ucdb 0in.rpt -report

October 2011
357
Command Reference
0in_db2ucdb
Questa AutoCheck
Questa AutoCheck analysis detects three types of information relevant to UCDBs: unreachable
FSM states, unreachable FSM transitions and unreachable blocks of code. After debugging any
issues found by autocheck analysis, any remaining unreachable FSM states/transitions and
blocks of code are presumably OK. However, after running simulations and merging results,
these unreachable objects are used in the calculations of FSM and line coverage reported by
vcover. The effect is that reported coverage measures are lower than necessary.
To work around this problem, you can exclude certain coverage objects from the coverage
calculations using the coverage exclude commands. For example:
coverage
coverage
coverage
coverage
coverage
coverage
coverage
exclude
exclude
exclude
exclude
exclude
exclude
exclude
-du
-du
-du
-du
-du
-du
-du
work.shiba.fsm_a -fstate state 4b0111

work.shiba.fsm_a -fstate state 4b1000
work.shiba.fsm_a -ftrans state {4b0110 -> 4b0111}
work.shiba.fsm_a -fstate current_state 5b01000
work.shiba.fsm_a -fstate current_state 5b10000
work.shiba.t2 -srcfile dut.v -linerange 75
work.shiba.t2 -srcfile dut.v -linerange 76
These commands exclude state states 4b0111 and 4b1000, state transition 4b0110 ->
4b0111, current_state states 5b01000 and 5b10000, and lines 75-76 in dut.v from coverage
calculations. Since autocheck analysis has already detected these unreachable objects, you do
not need to manually code these exclusionsthey are automatically generated by 0in_db2ucdb
with the -exclude option:
prompt>
prompt>
prompt>
prompt>
prompt>
0in_autocheck ....
0in_db2ucdb -exclude 0in_autocheck.db exclude.do...
vsim ... exclude.do...
vcover report -select f -bydu sim.ucdb > du.report
vcover report code s sim.ucdb > cover.report
Questa CDC
The UCDB schema supports CDC attributes. To include CDC data in the UCDB translation,
specify the -cdc option to 0in_db2ucdb. If you run 0in_db2ucdb -report on the generated ucdb
file, the utility creates a report with the CDC information included. For example:
prompt> 0in_db2ucdb -prefix tb.dut -prefix_modules pci \
-cdc 0in_cdc.db 0in_cdc.ucdb
prompt> 0in_db2ucdb -report 0in_cdc.ucdb cdc.report
prompt> more cdc.report
# 0in_db2ucdb Report
------------ TEST ------------------------Name
: 0in_cdc
File name
: 0in_cdc.ucdb
Status
: OK
Simulation time : 0.000000 us
Compulsory
: 0
Seed
: NONE
Test args
: (null)
Vsim args
: (null)
Comment
: UCDB created from 0-In DB
358

October 2011
Command Reference
0in_db2ucdb
. . .
Attribute:
Attribute:
Attribute:
Attribute:
name
name
name
name
=
=
=
=
SIMTIME, Attribute type: double, Attribute value = 0.000000

TIMEUNIT, Attribute type: string, Attribute value = us
CPUTIME, Attribute type: double, Attribute value = 0.100000
DATE, Attribute type: string, Attribute value = 20100205121243
. . .
Attribute:
#### START
Attribute:
Attribute:
Attribute:
name
attr
name
name
name
= CDC_CROSSING_RECORD-dmux_3211, Attribute type: attr handle

handle fields for CDC_CROSSING_RECORD-dmux_3211:
= CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 6
= CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 1
= CDC_TX_NAME, Attribute type: string, Attribute value =
pi.control[2]
Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value = clk1
Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value = po.data
Attribute: name = CDC_RX_CLK, Attribute type: string, Attribute value = clk2
Attribute: name = CDC_VIA_SIGNALS, Attribute type: attr array
#### START attr array elements:
#### END attr array elements :
#### END attr handle fields for CDC_CROSSING_RECORD-dmux_3211
Attribute:
#### START
Attribute:
Attribute:
Attribute:
name
attr
name
name
name
= CDC_CROSSING_RECORD-no_sync_35713, Attribute type: attr handle

handle fields for CDC_CROSSING_RECORD-no_sync_35713:
= CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 0
= CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 2
= CDC_TX_NAME, Attribute type: string, Attribute value =
pi.control[1]
Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value =
Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value =
po.active
#### END attr handle fields for CDC_CROSSING_RECORD-no_sync_35713
Attribute: name = CDC_CROSSING_RECORD-no_sync_19588, Attribute type: attr handle
#### START attr handle fields for CDC_CROSSING_RECORD-no_sync_19588:
Attribute: name = CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 0
Attribute: name = CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 2
Attribute: name = CDC_TX_NAME, Attribute type: string, Attribute value =
pi.control[1]
Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value =
Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value = po.data
#### END attr handle fields for CDC_CROSSING_RECORD-no_sync_19588
. . .
#### END attr handle fields for CDC_RECORD
------------- DESIGN UNIT -----------------Name
: work.tb_top
Type
: UCDB_DU_MODULE
Source type
: VERILOG
File info
: name = caution.v line = 2
Flags
: 0x00000100
Attribute: name = #DUSIGNATURE#, Attribute type: string, Attribute value =
(null)
------------- DESIGN UNIT -----------------Name
: work.top
Type
: UCDB_DU_MODULE
Source type
: VERILOG
File info
: name = /u/cshaw/examples/ucdb_cdc/cdc.sv line = 15

October 2011
359
Command Reference
0in_db2ucdb
Flags
: 0x00000100
Attribute: name = #DUSIGNATURE#, Attribute type: string, Attribute value =
(null)
------------- INSTANCE SCOPE ---------------Name
: .tb_top
Type
: UCDB_INSTANCE
Source type
: VERILOG
File info
: name = <none> line = 2
DU Scope
: work.tb_top
Weight
: 1
Flags
: 0x00000000
------------- INSTANCE SCOPE ---------------Name
: .tb_top.top0
Type
: UCDB_INSTANCE
Source type
: VERILOG
File info
: name = <none> line = 15
DU Scope
: work.top
Weight
: 1
Flags
: 0x00000000
You can access UCDB CDC information in two ways:
UCDB API (see UCDB API Reference)

Include the following header file in the API code. This header defines the
CDC_RECORD key and the supporting attributes.
$HOME_0IN/share/include/ucdb_cdc.h
Questa Sim XML export utility

Load the generated UCDB (coverage) file and use the coverage export command to
create an XML version of the database. For example:
prompt> vsim -c -viewcov cdc.ucdb -do "coverage export cdc.xml;quit -f"
prompt> more cdc.xml

vsim -c -viewcov cdc.ucdb -do "coverage export cdc.xml;quit -f"
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ux:ucdb version="10000042" pathsep="/" xmlns:ux="www.mentor.com">
<ux:test><ux:attr key="SIMTIME" type="double">0.000000</ux:attr>
<ux:attr key="TIMEUNIT" type="str">us</ux:attr>
<ux:attr key="CPUTIME" type="double">0.100000</ux:attr>
<ux:attr key="DATE" type="str">20110110102608</ux:attr>
<ux:attr key="VSIMARGS" type="nullstr"></ux:attr>
<ux:attr key="USERNAME" type="str">andrewse</ux:attr>
<ux:attr key="TESTSTATUS" type="int">0</ux:attr>
<ux:attr key="TESTNAME" type="str">cdc</ux:attr>
<ux:attr key="ORIGFILENAME" type="str">cdc.ucdb</ux:attr>
<ux:attr key="SEED" type="nullstr"></ux:attr>
<ux:attr key="TESTCMD" type="nullstr"></ux:attr>
<ux:attr key="TESTCOMMENT" type="str">UCDB created from 0-In DB</ux:attr>
<ux:attr key="COMPULSORY" type="int">0</ux:attr>
<ux:attr key="CDC_RECORD" type="handle">
<ux:attr key="CDC_TOTAL_CLOCK_GROUPS" type="int">2</ux:attr>
<ux:attr key="CDC_INFERRED_CLOCK_GROUPS" type="int">2</ux:attr>
<ux:attr key="CDC_USER_CLOCK_GROUPS" type="int">0</ux:attr>
<ux:attr key="CDC_IGNORED_CLOCK_GROUPS" type="int">0</ux:attr>
<ux:attr key="CDC_TOTAL_VIOLATIONS" type="int">3</ux:attr>
360

October 2011
Command Reference
0in_db2ucdb
<ux:attr key="CDC_TOTAL_CAUTIONS" type="int">1</ux:attr>
<ux:attr key="CDC_TOTAL_EVALUATIONS" type="int">1</ux:attr>
. . .
<ux:attr key="CDC_CROSSING_RECORD-dmux_3211" type="handle"><ux:attr
key="CDC_SCHEME_TYPE" type="int">6</ux:attr>
<ux:attr key="CDC_SEVERITY_TYPE" type="int">1</ux:attr>
<ux:attr key="CDC_TX_NAME" type="str">pi.control[2]</ux:attr>
<ux:attr key="CDC_TX_CLK" type="str">clk1</ux:attr>
<ux:attr key="CDC_RX_NAME" type="str">po.data</ux:attr>
<ux:attr key="CDC_RX_CLK" type="str">clk2</ux:attr>
<ux:attr key="CDC_VIA_SIGNALS" type="array"/></ux:attr>
. . .
Questa Formal
Questa Formal analysis detects three types of information relevant to UCDBs and assertion
coverage:
An assertion firing increments the assertions failure count.
An assertions sanity check firing increments the assertions pass count
A cover points covered count is added to the cover points coverage count.
Use 0in_db2ucdb to generate a UCDB file that you can merge with simulation UCDBs to
update your coverage reports with this information. For example, assume vsim simulation
generated a UCDB file called vsim.ucdb and the Assertions window looks like:
Then run:
prompt> 0in_confirm ....
prompt> 0in_db2ucdb -prefix TESTBENCH.r -prefix_modules "TESTBENCH top" \
0in_confirm.db 0in.ucdb
prompt> vcover merge merge.ucdb vsim.ucdb 0in.ucdb
prompt> vsim -viewcov merge.ucdb

October 2011
361
Command Reference
0in_db2ucdb
Two things have happened: the pass/failure counts have been incremented with the new formal
analysis data and the formal analysis results (vacuous count, formal and proof radius fields) are
now shown.
362

October 2011
Command Reference
0in Shell Commands
0in Shell Commands

The 0in shell commands are the formal verification utilities executed from within the 0in shell
(see 0in on page 351). These commands typically are run in batch mode from a command
string or batch script. The 0in command can also be run interactively and each of the 0in shell
utilities can be invoked from the 0in shell session.
The 0in shell commands include the assertions compiler for simulation (ccl) and the formal
model compiler (csl) for formal verification. For CDC analysis, the 0in shell has the following
utility:
cdc CDC compiler.
lib2v Liberty to Verilog translator.
The 0in shell also has a command-line help facility, which has the following invocations:
shell prompt>0in -help
Reports the syntax for the 0in command.
0in>command -help
Reports the syntax for the command 0in shell command. For example:
0in>cdc -help
0in>cwhelp [global_directive | checker_type]
Reports the syntax for the specified global directive or checker type (see cwhelp on
page 381). For example:
0in>cwhelp set_cdc_report
0in>cwhelp bits_on
Note
You cannot include UNIX environment variables in a 0in shell script or within an
interactive 0in shell session. However, it is permitted to include UNIX environment
variables when invoking from the system shell prompt or from a system shell script.

October 2011
363
Command Reference
cdc
cdc
Compiles a clock domain model of the design; performs static CDC analysis; promotes CDC
protocol assertions for formal verification and simulation; and promotes CDC-FX metastability
injection logic for simulation.
Syntax
cdc d design
[ report_clock | report_modes
| report_hier_scripts | report_constraints block_pattern
| hier | hier_block block [-output_hier_ctrl file] | hier_instance instance
| [hier_cache ILM_cache] [hier_ctrl_file_model block CFM_ctrl_file]]
[work work_library] [modelsimini init_file] [{L | Lf} library]
[cuname comp_unit] [cache pathname]
control_options := [[ctrl control_file] [ctrl_list control_file] [v95 | v2k | sv]
[vhctrl control_file] [93 | 87 | 2002 | 2008] | [ctrl_module module] ]
reporting_options := [cr report_file] [verbose] [gen_port_domain_template]
[print_all_cdc_paths] [+nowarn{+messageID}] [+error{+messageID}]
sdc_options := [sdc_in sdc_file] [sdc_out file] [report_sdc]
advanced_options := [de {[module.]inst_pattern}] [di {[module.]inst_pattern}]
[G name=value] [g name=value] [mode mode] [fx] [process_dead_end]
[effort unlimited] [formal [formal_effort {low | medium | high | maximum}]]
[auto_black_box] [dw]
compile_cdc_assertions_options := [compile_assertions prefix hierarchy_prefix
[sim {questa | vcs | nc | nc3}] [sim_lib simulation_library]
[compiled_assertion_report file] [sif root_name] [rel_paths] ]
d design
HDL design unit to be verified. To specify a particular VHDL architecture for a top-level
entity, specify the architecture in parentheses with the entity name. For example: d
top(arch).
report_clock
Report only clock domains and exit. Default: perform full CDC analysis.
report_modes
Generate a mode report in the 0in_detail.log file and exit. Default: run CDC analysis; do not
generate a mode report.
report_hier_scripts
Generate hierarchical flow scripts; and exit. The generated flow scripts create their output
files in the directory specified by the -od 0in shell option (default: run directory).
364

October 2011
Command Reference
cdc
report_constraints block_pattern
Generate hierarchical constraints files for the matching blocks (modules and entities);
generate hierarchical flow scripts; and exit. The generated flow scripts create their output
files in the directory specified by the -od 0in shell option (default: run directory).
hier
Generate an interface logic model of the CDC logic of the design using a user-specified
CDC constraints file (i.e., one manually constructed). This model is used to run hierarchical
CDC analysis when the current DUT is instantiated as part of a larger design. Use this
option if the top-level design is not available.
hier_block block
Run block-level hierarchical CDC analysis for block (Verilog module or VHDL design unit)
using the hierarchical CDC constraints in the specified control file (created by a previous
cdc session using -report_constraints). Using the results, generate a CDC interface logic
model for the block for use in top-level CDC analysis. Use this option if all instances of the
block are homogeneous.
output_hier_ctrl file
Name to give the control file generated for the block (when set_cdc_hier_preference
-ctrl_file_models is specified). Default: 0in_cdc_hier_<block>_ctrl.v.
hier_instance instance
Run block-level hierarchical CDC analysis for the specified homogeneous instances of a
block using the hierarchical CDC constraints in the specified control file (created by a
previous cdc session using -report_constraints). Using the results, generate a CDC interface
logic model for the group of instances for use in top-level CDC analysis. Use this option if
the instances of the block are not homogeneous.
hier_cache ILM_cache
Use the specified CDC interface logic model caches generated from block-level analyses
and perform top-level hierarchical CDC analysis on the DUT.
hier_ctrl_file_model block CFM_ctrl_file

Use the CDC control file model corresponding to block in CFM_ctrl_file (which is typically
generated by block-level analysis of block) and perform top-level hierarchical CDC analysis
on the DUT.
work work_library
Logical name of the design library containing precompiled design units. Also used as the
target library for compilation performed by cdc. If work_library does not exist, it is created.
Default: work in the current run directory.
modelsimini init_file
Load init_file as the compiler initialization (modelsim.ini) file, which is used when vopt is
called (under the hood). If you ran vlog and vcom compilation with the -modelsimini

October 2011
365
Command Reference
cdc
init_file option, you must use this option with cdc and the option must point to the same file.
Default: search path shown in Figure 3-4 on page 59.
L library | Lf library
Resource library containing pre-compiled modules for the clock domain model compilation.
With the Lf argument, library is searched before searching in the effective uselib library
(if specified) for the instantiation. With the L argument, library is searched after searching
the effective uselib library. The LibrarySearchPath variable defines an initial resource
library search path. When searching for a module for an instantiation, the libraries specified
by LibrarySearchPath are searched in (left-to-right) order, as if they were specified with the
L argument. If no match is found, the libraries specified in the Lf and L options are
searched in the order specified in the command invocation.
cuname comp_unit
Specifies -cuname comp_unit when vopt is called (under the hood). If you ran vlog
compilation with the -cuname comp_unit option, you must use the same option with csl/cdc.
This option can be specified multiple times. Note that for 1-step csl/cdc compilation,
-cuname root_cuname (default name of the global SystemVerilog package) is passed
automatically. The root_cuname package contains everything outside the compiled
modules/packages. When preparing to run Questa simulation, include the -cuname
root_cuname option to vlog and vcom to catch these extra constructs.
cache pathname
0in cache directory. Default: same as the 0in shell cache directory.
Control Options
ctrl control_file
Verilog-flavor control file.
ctrl_list control_file []
One or more Verilog-flavor control files. For example:
-ctrl_list *.v
The dash () terminates a list of control file names to separate the names from source file
names.
v95 | v2k | sv
Verilog version (Verilog-95, Verilog 2000 or SystemVerilog) used in Verilog-flavor control
files. Default: v2k if modelsim.ini variable vlog95compat is 0 or 95 if vlog95compat is 1.
In Verilog 1-step mode, this argument specifies the Verilog version (v95 or v2k) used by
the design files having .v extensions. Files with .sv extensions are assumed to be
SystemVerilog files. Default for Verilog 1-step: -v2k.
vhctrl control_file
VHDL-flavor control file.
366

October 2011
Command Reference
cdc
-87 | -93 | -2002 | -2008

VHDL version: VHDL-87, VHDL-93, VHDL-2002 or VHDL-2008 used in VHDL-flavor
control files. Default: value specified by the VHDL93 variable (default 2002) in
modelsim.ini.
ctrl_module module
Module or design unit in the -work library to use as a control file. You can use vcom/vlog to
compile a control file (for example, if a control module or design unit contains modeling
logic), then use the -ctrl_module option to indicate the control modules and design units
used for analysis.
For example, if ctrl.v is a control file with a Verilog module ctrl_mod that contains global
directives. then the following sequence of commands:
prompt> vlog ctrl.v
prompt> 0in -cmd cdc -d dut -ctrl_module ctrl_mod
is equivalent to:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v
Reporting Options
cr report_file
Name to give the CDC report file. Default: 0in_cdc.rpt.
verbose
Report the filtered CDC crossings (turned off using the -severity off option of the
set_cdc_report directives) and the stable signals (identified by set_cdc_signal directives
with the -stable option) in the Filtered CDC Checks Summary section of the 0in_cdc.rpt
file. Report detailed warning messages related to the set_cdc_report global directives. For
example, by default, if a set_cdc_report global directive has an invalid wildcard signal or an
incomplete list of signals for reconvergence filtering, then a warning message that the global
directive did not match any CDC crossing is issued (directive-214). With -verbose, the
warning message specifies the type of error in the global directive. Also report the list of
signals that match wildcard patterns for each directive that supports wildcards in arguments.
To report crossings filtered by set_cdc_report -severity off and set_cdc_signal -stable
directivesbut not the other extra informationuse set_cdc_preference -filtered_report
directives.
gen_port_domain_template
Generate a 0in_cdc_port_domain_template.v file containing set_cdc_port_domain
directives for the primary ports.
print_all_cdc_paths
Print all CDC paths to 0in_cdc_path.rpt.

October 2011
367
Command Reference
cdc
+nowarn{+messageID}
Turn off reporting of the specified warning messages. Message ID is a category and number
(e.g., parser-47). Default: all warning messages reported.
+error{+messageID}
Turn the specified warning messages into errors. Message ID is a category and number
(e.g., parser-47).
SDC Options
sdc_in sdc_file
Load the specified SDC file and use the SDC data to set up CDC analysis.
sdc_out file
Write the SDC data to file for use in downstream tools.
report_sdc
Generate the 0in_sdc_ctrl.v control file with global directives for the SDC data.
Advanced Options
de {[module.]inst_pattern}
Exclude instances in module that match inst_pattern. Default module is the design.
di {[module.]inst_pattern}
Exclude instances in module that do not match inst_pattern. Default module is the design.
The following example shows usage of di and de together.
top
m2
m1
top
m2
-di m1
-de mid.i*
i1
i2
i3
e1
m1
mid
excluded logic
i1
i2
i3
e1
i2
i3
i1
e1
G name=value
Override the final value of the generic/parameter specified by name. The name can be a
hierarchical path. For example, irrespective of the value in the source code, the value used
for dut.u1.p1 is 10 in the following invocation.
0in -cmd cdc -d dut -G dut.u1.p1=10 -G p2=20 -infer_clk
Questa CDC/Formal and Questa Sim implementations for -G differ slightly:
368

October 2011
Command Reference
cdc
Command Line Questa CDC/Formal has no blank space between the -G option
and the parameter. For example: -G p1=10 (Questa CDC/Formal) vs -Gp1=10
(Questa Sim).
g name=value
Default value of the generic/parameter specified by name. The name can be a hierarchical
path. For example, unless the value of p1 is set by a defparam statement, the value used for
p1 is 10 in the following invocation.
0in -cmd cdc -d top -g p1=10 -g p2=20 -infer_clk
Questa CDC/Formal and Questa implementations for -g differ slightly:
Command Line Questa CDC/Formal has no blank space between the -g option
and the parameter. For example: -g p1=10 (Questa CDC/Formal) vs -gp1=10
(Questa Sim).
mode mode
Infer all modes of operation or run CDC modal analysis on the design using the specified
mode and exit (without doing any CDC analysis). Generate a modal script (0in_mode.scr).
Directives that specify -mode arguments with different modes are ignored. Default: run
regular CDC analysis. Directives that specify any -mode arguments are ignored.
fx
Generate the 0in_cdc_fx_sim_ctrl.v control file with directives for the promoted cdc_fx
checkers.
process_dead_end
Report all CDC issues, including paths that do not connect to output ports (dead end paths).
Default: CDC does not report issues found on registers in dead logic.
effort unlimited
Set the effort level of CDC analysis to unlimited, which can increase runtime and memory
usage.
formal
Run formal CDC during static CDC analysis.
formal_effort {low | medium | high | maximum}

Effort level for CDC formal analysis. Default: low.
auto_black_box
Turns all unresolved modules/entities into inferred black boxes. An unresolved
module/entity is one for which no module or entity/architecture definition is present. If a
component declaration is present, the port directions are derived from that declaration.
Otherwise, the port directions are inferred from the connected logic. If a port direction
cannot be inferred, the port direction is assumed to be INOUT. Default: unresolved modules
are treated as unused/undriven logic.

October 2011
369
Command Reference
cdc
dw
Compile remodeled versions of DesignWare elements (1-step compilation). For example:
prompt> 0in -cmd cdc dut.v -d dut -dw
For 2-step compilation, use vlog to compile the remodeled DesignWare element library by
specifying the encrypted Verilog source and the include directory as shown in this example:
prompt> vlog $HOME_0IN/share/MODIFIED/dw/dw.remodel.v \
+incdir+$HOME_0IN/share/MODIFIED/dw/
prompt> 0in -cmd cdc -d dut
Not all DesignWare elements are available. You cannot use remodelled DesignWare
elements for simulation with CDC protocol monitors or for CDC-FX simulation.
Compile CDC Assertions Options
compile_assertions
Compile CDC protocol checkers and CDC-FX checkers into the -work library and create a
simulator arguments file for simulation. Use set_cdc_report -promotion off directives to
skip compilation of CDC protocol checkers for specific crossings. Assertion compilation
uses the CDC logic model to generate the CDC protocol assertions and CDC-FX logic used
by vsim. So compilation is much more efficient than running a separate ccl session to
compile the CDC assertion logic. Default: compilation for simulation is not performed.
prefix hierarchy_prefix
Hierarchy prefix showing the hierarchy from the top level (typically the testbench) to the
DUT.
sim {questa | vcs | nc | nc3}

Target simulators (VCS, NC-Verilog, or 3-step NC-Verilog). Default: same as the 0in shell.
The default Questa version is the same as the vsim executable in the current search path.
sim_lib simulation_library
Logical name for the protocol assertion library used for simulation. The assertion names in
the Questa Sim simulation arguments file generated by cdc have simulation_library as a
prefix.
compiled_assertion_report file
Name to give the generated CDC assertion compilation report. Default:
0in_cdc_checker.rpt.
sif file
Root name to give the generated simulation arguments file. Default root file name:
0in_cdc_sim.arg.
370

October 2011
Command Reference
cdc
rel_paths
Use relative pathnames in generated argument files. This option can be used to change the
0in_check.db link path to not use the absolute path name. For example,
0in_check.db -> ./0in_cache/DB/0in_check.db
Default: same as the 0in shell.

Description
The Questa CDC analyzer (cdc) performs static CDC analysis of a compiled design. The cdc
analyzer assumes the top-level design unit is compiled into -work and if not, generates error
messages and exits.
Use the -report_clock option to report initial CDC information without performing a complete
CDC analysis. Then use this information to set up the initial environment for performing CDC
analysis. After setting up the starting configuration, run cdc to perform a full CDC analysis
(Figure 6-3).
Figure 6-3. CDC Analysis with cdc
vcom/vlog
-work library
design
files
cdc
control
files
0in_cdc.db
0in_cdc
GUI
debugging
environment
Compile CDC Assertions
If you specify compile_assertions, cdc performs CDC analysis as usual, but also compiles
assertion logicand CDC-FX injectors, if you also specify -fx (Figure 6-4). The
-compile_assertions argument also creates simulator arguments files used to direct vcom/vlog
compilation and vsim simulation. When specifying -compile_assertions, also include the -prefix
hierarchy_prefix that identifies the hierarchy path from the testbench top level to the DUT
analyzed by cdc.

October 2011
371
Command Reference
cdc
Figure 6-4. Compiling CDC Assertions

vcom/vlog
design
files
cdc
-compile_assertions
control
files
-work library
vsim
-f 0in_cdc_sim.arg
merge
0in_checksim.db
vcom/vlog
0in_cdc
0in_cdc.db
GUI
vcom/vlog
testbench
files
debugging
environment
The following example has a Verilog testbench and a VHDL DUT:

1. Set up the work library.
prompt> vlib work
2. Compile the design.

prompt> vcom dut.v

4. Compile the protocol assertions with the simulation arguments files generated by cdc.

prompt> vlog tb.v
6. Run simulation. Specify the PLI library path for the simulator and the vsim arguments
files.
372

October 2011
Command Reference
cdc
7. View the results in the GUI.

The 0in_cdc.db database is generated by cdc; 0in_checksim.db is generated by vsim.

Note
The -compile_assertions option currently compiles checkers for all enabled protocol
checks and CDC-FX checks. You can use set_cdc_report -promotion off directives to
mark instances of CDC schemes that should not be promoted (so they are not compiled
by -compile_assertions).
Note
Running the cdc -report_constraints step of hierarchical CDC creates hierarchical
constraints files for specified blocks. These files contain set_cdc_port_domain directives
for the blocks ports. If a port is driven by multiple clock domains, is unused or is
undriven, cdc cannot infer its clock domain and cannot create a set_cdc_port_domain
directive that properly handles the port. To document which block ports have these
properties, cdc creates set_cdc_port_domain directives with -none arguments. These
directives are skipped and do not constrain the blocks.
Input Files
The input files for the cdc command are shown in Table 6-4.
Table 6-4. cdc Input Files
design library
Specified with -work library.
control files
Control files that contain global directives for the following operations:
Specifying attributes of clocks and clock groups.
Changing attributes of CDC schemes.
Setting preferences for CDC analysis.
Adjusting attributes of promoted CDC protocol assertions and
CDC-FX checkers.
Controlling netlist generation.
SDC files
Optional SDC files to load and use to configure CDC analysis.

October 2011
373
Command Reference
cdc
Hierarchical CDC
Files used in hierarchical CDC flows:

0in_cdc_hier_constraints_block_ctrl.v
Constraints file for running block-level CDC analysis on the
specified block. Generated by running -report_constraints at the
top level.
0in_hier/block/0in_cache
Hierarchical CDC cache containing the ILM model of block,
generated during block-level CDC analysis of block.
0in_cdc_hier_block_ctrl.v
Hierarchical CDC control file containing the CFM model of
block, generated during block-level CDC analysis of block (if
set_cdc_hier_preference -ctrl_file_models is specified).
Output Files
The 0in_cache directory contains cached data for CDC analysis. Other output files are listed in
Table 6-5.
Table 6-5. cdc Output Files
0in_cdc.db
0in.log
0in_detail.log
0in_cdc.rpt
0in_cdc_design.rpt
0in_design.rpt
0in_cdc_setting.rpt
0in_cdc_path.rpt
0in_cdc_ctrl.v
0in_cdc_param.inc
0in_cdc_mode_ctrl.v
0in_mode.scr
SDC output file
374
Database file of the cdc session.

Short log file for the session. This is a copy of the
standard output.
Detailed log file for the session.
Clock domain crossing report. The -cr option renames
this file.
CDC design report.
Design report.
CDC settings report.
Details of the CDC paths. Generated if the cdc
-print_all_cdc_paths option is specified.
Control file specifying generated CDC protocol
checkers.
Include file referenced by 0in_cdc_ctrl.v.
Control file containing directives that specify the mode
inferred by modal analysis. Generated if the cdc
-report_modes option is specified.
Shell script that runs CDC analysis for the modes.
Generated when -report_modes is specified.
File name is specified by -sdc_out. Default:
0in_sdc_ctrl.v.

October 2011
Command Reference
cdc
Hierarchical CDC
Compile Assertions
0in_cdc_port_domain_template.v

October 2011
Files used in hierarchical CDC flows:

0in_cdc_hier_constraints_block_ctrl.v
Generated by running -report_constraints at the
top level.
0in_hier/block/0in_cache
Generated during block-level CDC analysis of
block.
0in_cdc_hier_block_ctrl.v
Generated during block-level CDC analysis of
block (if set_cdc_hier_preference
-ctrl_file_models is specified).
0in_hier.Makefile and 0in_hier.scr
Scripts for running hierarchical analysis.
Generated by running -report_constraints at the
top level.
Files generated by -compile_assertions:
0in_cdc_sim.arg, 0in_cdc_sim_vhdl.arg,
0in_cdc_sim.arg.vsim , 0in_cdc_sim.arg.vsimrun.
These are generated for Questa use. If another
simulator is specified, other files are generated as well.
Also generated: a compile assertions report (default
name: 0in_cdc_checker.rpt).
Template file of the set_cdc_port_domain directives for
the primary ports (when -gen_port_domain_template is
specified).
Control file containing CDC-FX checker directives for
simulation with metastability injection logic (when -fx
is specified).
375
Command Reference
cdc
Examples
Example 1
system prompt> vlog -f source/filelist
QuestaSim-64 vlog 6.6c Compiler
-- Compiling module tb
-- Compiling module dpmem2clk
. . .
system prompt> 0in -cmd cdc -d demo_top
Questa: Questa Advanced Functional Verification System v10.0...
. . .
Command: cdc
Command arguments:
-d demo_top
. . .
Top level modules:
demo_top
Analyzing design...
-- Loading module demo_top
-- Loading module generic_fifo_dc_gray
-- Loading module dpmem2clk
-- Loading module crc_16_calc
Optimizing 4 design-units (inlining 0 instances):
-- Optimizing module dpmem2clk(fast)
Error: Design unit dump is compiled with older Questa simulator version.
. . .
Error
: Design elaboration failed. [command-188]
: Processing will abort.
Error
: Design Elaboration (Child process) returned a non zero status.
[command-195]
: Processing will abort.
----------------------------------------------------------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
elaboration-113 Design unit dump is compiled with older
Questa simulator version.
This example compiles the Verilog files using vlog and then runs the cdc command. An error is
returned because the design is compiled with an older version of vlog than the version
compatible with V3.x tools. To avoid these types of errors, use the front-end utilities from the
Questa CDC/Formal installation softwarenot the utilities in the Questa Sim installation.
376

October 2011
Command Reference
cdc
Example 2
system prompt> $HOME_0IN/modeltech/bin/vlib work
system prompt> $HOME_0IN/modeltech/bin/vlog -f source/filelist
Model Technology ModelSim SE vlog QA Baseline: 6.6 ...
-- Compiling module tb
-- Compiling module dpmem2clk
. . .
system prompt> 0in -cmd cdc -d demo_top
Questa: Questa CDC/Formal Functional Verification System v10.0
. . .
Command: cdc
Command arguments:
-d demo_top
. . .
Parsing files...
Analyzing designs.
Processing CDC checks for module demo_top
Processing 113 candidates
Processing 27 CDC signals after duplicate removal.
CDC Summary
=================================================================
Violations (8)
----------------------------------------------------------------Single-bit signal does not have proper synchronizer.
(3)
Combinational logic before synchronizer.
(2)
Reconvergence of synchronizers.
(3)
Cautions (10)
----------------------------------------------------------------DMUX synchronization.
(2)
Multiple-bit signal synchronized by DFF synchronizer.
(4)
Multiple-bit signal across clock domain boundary.
(1)
Memory Synchronization.
(2)
Simple DMUX synchronization.
(1)
Evaluations (8)
----------------------------------------------------------------Single-bit signal synchronized by DFF synchronizer.
(7)
Pulse Synchronization.
(1)
Waived (0)
----------------------------------------------------------------<None>
Proven (0)
----------------------------------------------------------------<None>
Filtered (0)
----------------------------------------------------------------<None>
. . .
----------------------------------------------------------Count Type
Message ID
Summary
-----------------------------------------------------------

October 2011
377
Command Reference
cdc
1
4
25
Warning
Warning
Warning
hdl-222 Possible dead end CDC paths not reported.

hdl-41 Primary port connects to multiple clock domains.
hdl-51 Port domain assignment inferred.
This example specifies the absolute path to the Questa CDC/Formal installed front-end utilities,
which eliminates the version mismatch error that occurs in Example 1.
Example 3: Compile Assertions (VCS)
This example runs cdc with the -compile_assertions option and runs CDC protocol simulation
with a VCS simulator.
vlib work
vmap work work
vlog test.v
0in -sim vcs -cmd cdc -d test -compile_assertions -prefix tb.dut
vcs -R test.v $HOME_0IN/0InPLI/vcs/lib0InvcsPLI.so -f 0in_cdc_sim.arg
0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
Example 4: Compile Assertions (NC)

with an NC-Verilog simulator.
vlib work
vmap work work
vlog test.v
0in -sim nc -cmd cdc -d test -compile_assertions -prefix tb.dut
ncverilog test.v -f 0in_cdc_sim.arg
Example 5: Compile Assertions (NC3)

with a 3-step NC simulator.
vlib work
vmap work work
vlog test.v
0in -sim nc3 -cmd cdc -d test -compile_assertions -prefix tb.dut
ncvlog test.v -f 0in_cdc_sim.arg
ncelab tb -snapshot test -f 0in_cdc_sim.arg.ncelab
ncsim test -f 0in_cdc_sim.arg.ncsim
378

October 2011
Command Reference
lib2v
lib2v
Translates data from an Si2 Liberty file into Verilog modules containing functional descriptions
of each cell and corresponding control files for CFM-based hierarchical CDC.
Syntax
lib2v lib liberty_file [dir output_directory] [strict] [no_line] [verbose]
lib liberty_file
Liberty file to translate.
dir output_directory
Directory to store the generated Verilog cell library and control files. Default:
./0in_lib_vlog/<library>, where <library> is the Liberty technology library name.
strict
Generate an error message for each of the modules ports that does not have an associated
clock domain,
no_line
Do not insert V2K line directives into the generated Verilog modules and Verilog control
files. Default: generate code has line directives that link the generated code to the
corresponding line number and file name of the related attribute in the .lib file.
verbose
Report detailed messages. Use this option when comparing generated modules to the source
Liberty cells. When used with strict, the command strictly enforces the translation.
Liberty files sometimes contain directives that are unspecified in the Liberty LRM (i.e., the
directives are not publicly available). The Synopsys Library compiler can compile these
cells, but the Questa compilers might not. With both options specified, lib2v generates
errors for these unpublished directives. Default: unexpected Liberty directives generate
warnings.
Description
Liberty is a standard technology library specification format maintained by Synopsys, Inc.
Technology vendors use the Liberty format to describe cells in their libraries, for example,
cells pin-outs, functionality, timing, area, power requirements and so on. The lib2v utility reads
data from an Si2 Liberty file and creates Verilog cell libraries and Verilog CDC control files
from the data. You can then compile the generated Verilog files with vlog and add the generated
control files to the cdc/csl invocation.
For example, suppose technology library L contains cellA, cellB and so on. Then, lib2v creates a
Verilog file in 0in_lib_vlog/L for each cell: cellA.v, cellB.v and so on. Cell name, pin-out and
functionality directives for each cell are translated into the corresponding Verilog module.
The lib2v utility creates a control file in 0in_lib_vlog/L for each cell: cellA_lib_ctrl.v,
cellB_lib_ctrl.v and so on. These control files specify the clocks and the clock domains for the
October 2011
379
Command Reference
lib2v
ports of the corresponding cells. If a port does not have an associated clock domain, the
command generates a commented-out set_cdc_port_domain template.
By default, if the source library data do not include information to fully describe the
functionality of all output pins of a cell, lib2v issues a warning message, adds a Verilog
wrapper module for the cell and includes a set_black_box directive for the module in the
corresponding control file.
The lib2v utility translates only the Liberty directives needed to create Verilog models for use
with Questa CDC/Formal products. It ignores the other directives. Currently, the following
attributes are translated:
ID
library, cell
pin-out
pin, direction, type, bus, bundle
functionality
memory, memory_read, memory_write, pin_equal, pin_opposite, ff, state, ff_bank, latch,
latch_bank, state_table, complementary_pin, function, internal_node, inverted_output,
nextstate_type, pin_func_type, prefer_tied, primary_output, state_function,
test_output_only, three_state, x_function, input_map
timing
clock, generated_clock, clock_pin, master_pin, timing, timing_type, related_pin,
related_bus_pins, related_bus_equivalent
380

October 2011
Command Reference
cwhelp
cwhelp
Reports the syntax for a 0in global directive.
Syntax
cwhelp [directive]
directive
Report syntax for directive. Default: list the global directives with short descriptions.
Description
The cwhelp 0in shell utility reports the directive syntaxes for the 0in global directives.
Examples
Default
The cwhelp utility with no arguments lists the global directives by the 0in utilities.
0in> cwhelp
globals
checklist_off
checklist_on
default_reset
. . .
checkers
always
Global Directives
Adds a keyword to firing messages
Excludes a specified checklist check
from design file
Includes a specified checklist check
from control file
. . .
Checker Directives
Ensures that a specified signal always
asserts.
arbiter
Ensures that an arbiter conforms to a

specified arbitration scheme and that no
more than one grant asserts at any time.
arithmetic_overflow
Ensures that in an assignment statement,

the result of an arithmetic expression
does not overflow the left-hand-side
variable.
. . .
Global Directive Syntax
After using cwhelp with no arguments to find the name of a global directive, use cwhelp again
to find the syntax for the global directive:
0in> cwhelp default_reset
Command: cwhelp
Command arguments:
default_reset
usage: default_reset

October 2011
381
Command Reference
cwhelp
[<signal>]
[-module <module_name>]
[-none]
[-infer]
[-posedge or -active_high
or -negedge or -active_low]
[-sync
or -async]
[-help]
The syntax shows alias names for arguments (for example, -posedge is an alias for
-active_high).
382

October 2011
Command Reference
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 6-6) 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 universalthey have the same meaning for each checker type.

October 2011
383
Command Reference
Table 6-6. 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
{identifier |
formatted_string}
Base name for the checker. Default: derived from the directive
and hierarchy.
-group
{identifier |
formatted_string}
Base name for the checker. Default: derived from the directive
and hierarchy.
-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
global 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.
384

October 2011
Command Reference
cdc_dsel
cdc_dsel
active
signals
variables
constants
tx_clock
tx_reset
tx_data_select
rx_clock
rx_reset
rx_data_select
tx_data_stable_fire
rx_data_stable_fire
tx_min_fire
dsel
minimum_time_window_equals_min
tx_data
transfers_checked evals
rx_data
longest_assertion
tx_min
shortest_assertion
areset
default name:
tx_data_var_tx_data_var
checks:
firings
tx_data_stable (On)
rx_data_stable (On)
tx_min (On)
tx_clock, tx_reset, areset:
inferable from tx_dsel_signal
corner
cases
rx_clock, rx_reset:
inferable from rx_dsel_signal
statistics
vacuity property:
!tx_reset && !rx_reset &&
!areset && active &&
tx_dsel_signal === 0
Description
Ensures that a signal between two clock domains, where the transmitters 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.
Inferable Options
[-tx_clock tx_clock] [-tx_reset tx_reset]

Transmit clock and synchronous reset. If unspecified, each is inferable from tx_dsel_signal.
[-rx_clock rx_clock] [-rx_reset rx_reset]

Receive clock and synchronous reset. If unspecified, each is inferable from rx_dsel_signal.

October 2011
385
Command Reference
cdc_dsel
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:
386
all (default) all enabled checks
txdata tx_data_stable
rxdata rx_data_stable
txdsel tx_min

October 2011
Command Reference
cdc_dsel
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 clock cycles tx_dsel_signal remained stable

between any two successive legal events.
Shortest Assertion minimum number of clock cycles tx_dsel_signal remained stable

between any two successive legal events.
Notes
The following block diagram shows a typical implementation of a cdc_dsel checker:
TX Module
tx_dsel
tx_data_select
SYNC
rx_dsel
RX Module
cdc_dsel
checker
MUX
tx_data
rx_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_select tx_dsel_signal) and the receive data are based
on -rx_clock rx_clock (inferable from -rx_data_select rx_dsel_signal). 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_select
tx_dsel_signal. 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.

October 2011
387
Command 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
388

October 2011
Command Reference
cdc_fifo
cdc_fifo
signals
active
tx_clock
tx_reset
enq
rx_clock
rx_reset
deq
variables
wr_ptr
rd_ptr
constants
depth
cdcf
wr_ptr_fire
rd_ptr_fire
enqueue_fire
dequeue_fire
firings
full_count
empty_count
corner
cases
enqueues_and_dequeues evals
enqueues
statistics
dequeues
maximum_fifo_entries
current_fifo_entries
areset
default name:
enq_var_deq_var
checks:
wr_ptr (On)
rd_ptr (On)
enqueue (On)
dequeue (On)
inferable from enq_signal
rx_clock, rx_reset:
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}]]
[standard_option]
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.

October 2011
389
Command 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.
390

October 2011
Command Reference
cdc_fifo
Other Options
[-assume [all | {wptr | rptr | ptr | enq | deq}]]

o
default enqueue, dequeue
all all enabled checks
wptr wr_ptr
rptr rd_ptr
ptr wr_ptr, rd_ptr
enq enqueue
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
write
FIFO
wr_ptr
mem
TX Module
rx_clock
rd_ptr
read
RX Module
cdc_fifo
checker
tx_clock (inferable from -enq enq_signal) and the receive data are based on -rx_clock
October 2011
391
Command 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
rx_clk
tx_clk
write_ptr
enq
write_ptr_fire
rx_clk
tx_clk
read_ptr
deq
read_ptr_fire
392

October 2011
Command Reference
cdc_glitch
cdc_glitch
active
signals
flags
cdc_glitch_fire
var
firings
cglt
used
cycles_checked evals statistics

clock
reset
areset
default name:
var_signal
checks:
glitch (On)
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]
[standard_option]
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).

October 2011
393
Command 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
signals active edges are used to define time windows for the checkers 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
checker checks
for glitch on var_d
var_d
cdc_glitch
var
//0in cdc_glitch -var var
Examples
// 0in cdc_glitch -var reg
Checks that the input (var_d) to the reg register does not glitch.
clk
var_d
glitch_fire
394
glitch

October 2011
Command Reference
active
signals
tx_clock
tx_reset
variables
tx_var
constants
tx_min
hamming_one_fire
stable_fire
value_changed_at_tx_min
cdc_hamming1
areset
values_checked evals
lontgest_stable_time
shortest_stable_time
default name:
tx_variable
firings
corner checks:
cases
hamming_one (On)
data_stable (Off)
statistics tx_clock, tx_reset, 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}]]
[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.
[-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).

October 2011
395
Command 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
dist hamming_one
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.
396

October 2011
Command 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

October 2011
397
Command Reference
cdc_handshake_data
cdc_handshake_data
active
signals
tx_invalid_handshake_fire
rx_invalid_handshake_fire
data_stable_fire
tx_valid_assert_until_done_assert_fire
tx_done_assert_until_valid_deassert_fire
tx_valid_deassert_until_done_deassert_fire
rx_valid_assert_until_done_assert_fire
rx_done_assert_until_valid_deassert_fire
tx_valid_stable_fire
tx_clock
rx_done_stable_fire
tx_reset
turnaround_max_fire
tx_valid
turnaround_min_fire
tx_done
rx_clock
rx_reset
rx_valid
rx_done
variables
constants
tx_data
cdc_hsd
turnaround_at_max
turnaround_at_min
handshake_cycles_started evals
handshake_cycles_compeleted
handshake_turnaround_time_max
handshake_turnaround_time_min
tx_min
rx_min
turnaround_max
turnaround_min
areset
default name:
tx_valid_sig_tx_done_sig
checks:
cdc_handshake (On)
data_stable (On)
tx_valid_assert_until_tx_
done_assert (On)
firings
tx_done_assert_until_tx_
valid_deassert (On)
tx_valid_deassert_until_tx
_done_deassert (On)
rx_valid_assert_until_rx_
done_assert (On)
rx_done_assert_until_rx_
valid_deassert (On)
tx_valid_stable
(Off)
corner
cases
rx_done_stable (Off)
turnaround_max (Off)
turnaround_min (Off)
statistics clock, reset, areset:
inferable from
tx_valid_signal
vacuity property:
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]
[-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]
398

October 2011
Command Reference
cdc_handshake_data
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
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.

October 2011
399
Command Reference
cdc_handshake_data
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.
Firing message: rx_valid deasserted before rx_done was received.
400

October 2011
Command Reference
cdc_handshake_data
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

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]
Each data handshake protocol cycle must not complete in more than
turnaround_max_constant transmit clock cycles. This check requires tx_data_variable,

October 2011
401
Command Reference
cdc_handshake_data
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}]]

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

October 2011
Command 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
TX Module
Rx SYNC
cdc_handshake_data
checker
rx_valid
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
option should not be specified.
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.

October 2011
403
Command 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
404

October 2011
Command 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.

October 2011
405
Command Reference
cdc_sample
cdc_sample
active
signals
variables
tx_clock
tx_reset
rx_clock
rx_reset
tx_var
rx_var
sample
setup_fire
hold_fire
all_one
all_zero
all_zero_to_one
all_one_to_zero
values_sampled evals
sample_zero_bitmap
sample_one_bitmap
one_to_zero_transition_bitmap
zero_to_one_transition_bitmap
areset
default name:
tx_var_rx_var
firings
checks:
setup (On)
corner
cases
hold (On)
statistics rx_clock, rx_reset:
inferable from rx_variable
vacuity property:
rx_enable_signal === 0
Description
Ensures that 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.
(i.e., the receive domain samples 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]
[standard_option]
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


Receive clock and synchronous reset. If unspecified, each is inferable from rx_variable.
406

October 2011
Command Reference
cdc_sample
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.
Sample One Bitmap bit vector representing which bits of rx_variable were sampled
as 1.

October 2011
407
Command Reference
cdc_sample
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 Reg
tx_var
rx_var_d
cdc_sample
checker
tx_clk
rx_var
RX Reg
rx_clk
tx_clock and the receive data are based on -rx_clock rx_clock. The standard -clock
option should not be specified.
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 */
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
408

October 2011
Command Reference
cdc_sync
cdc_sync
active
signals
constants
tx_var[n]*
tx_clock
tx_reset
stable_fire
value_changed_at_tx_min
sync
tx_min
areset
firings
corner
cases
values_checked evals
shortest_stable_time
statistics
longest_stable_time
default name:
tx_variable
checks:
stable (On)
vacuity property:
!tx_reset && !areset &&
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.

October 2011
409
Command Reference
cdc_sync
Other Options
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 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
The following block diagram shows a typical implementation of a cdc_sync checker:
tx_var
SYNC
(double ff)
TX Module
rx_clk
tx_clk
RX Module
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.
410

October 2011
Command 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
stable_fire

October 2011
411
Command Reference
cdc_fx
cdc_fx
active
cdc_fx_fire
glitch_swallowed_fire
glitch_caught_fire
cfx
signals
all_bits_inverted
tx_clock
loading_while_clocks_aligned
rx_clock
evals
rx_reset
clocks_aligned_cycles
rx_areset
metastable_cycles
loading_while_rx_clock_before_tx_clock
loading_while_tx_clock_before_rx_clock
rx_clock_before_tx_clock
tx_clock_before_rx_clock
rx_load_enable
delayed_transitions
clks_aligned[65:0]
advanced_transitions
bits_inverted
inverted_bits_bitmap
rx_reg
tx_reg
rx_q
clocks
monitor
tx_clock
corner
cases
statistics
rx_reg
value
rx_clock
tx_reg
firings
default name:
rx_reg
checks:
cdc_fx (Off)
glitch_swallowed (Off)
glitch_caught (Off)
inferable from rx_reg
vacuity property:
active === 0
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}).
412

October 2011
Command Reference
cdc_fx
Inferable Options
-rx_clock rx_clock
Receive clock. If unspecified, then it is inferred from rx_register_variable.
-tx_clock tx_clock
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 registers
metastability window. Typically, the data output of the transmit register can change value in
the receive registers metastability window. This change can cause metastability of the
receiving registers 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 registers 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 6-5 on
page 414). 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.

October 2011
413
Command 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 6-5). 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 6-5. Transmit Protocol Checks for Glitches
cdc_fx checker
rx_q
q_sim
tx_reg
tx_clock
rx_reg
rx_clock
Glitch_caught Check
tx_clk
rx_clk
d
glitch
metastability
injected
metastability
not injected
rx_q
q_sim
glitch_caught_fire
Glitch_swallowed Check
tx_clk
rx_clk
d
glitch
metastability
injected
metastability
not injected
rx_q
q_sim
glitch_swallowed_fire
414

October 2011
Command Reference
cdc_fx
Corner Cases
All Bits Inverted nonzero if every output bit of the receive register has had metastability
inserted.
Loading While Clocks Aligned number of clocks aligned cycles in which

rx_register_variable is loading.
Statistics
Clocks Aligned Cycles (Evals) number of clocks aligned cycles in which

tx_register_variable is changing.
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.

October 2011
415
Command Reference
cdc_custom_fx
cdc_custom_fx
active
signals
cdc_custom_fx_fire
tx_clock
rx_clock
all_bits_inverted
ccfx
evals
clocks_aligned_cycles
metastable_cycles
bits_inverted
inverted_bits_bitmap
firing
corner
case
clks_aligned[65:0]
rx_reg
tx_reg
statistics
rx_q
clocks
monitor
tx_clock
rx_reg
value
rx_clock
tx_reg
default name:
rx_reg
checks:
cdc_custom_fx (Off)
inferable from rx_reg
vacuity property:
active === 0
rx_reg
Description
Injects metastability at the input of a custom synchronizer. Injection occurs when -tx_clock and
-rx_clock align and the checker fires when data changes within the metastability window. This
checker is only promoted if set_cdc_preference -custom_fx is specified.
Syntax
[<] {cdc_fx | cfx}
-rx_reg rx_register_variable -tx_reg tx_register_variable
[-rx_clock rx_clock] [-tx_clock tx_clock] [-cdc_custom_fx off] [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}).
Inferable Options
-rx_clock rx_clock
Receive clock. If unspecified, then it is inferred from rx_register_variable.
-tx_clock tx_clock
Transmit clock. If unspecified, then it is inferred from tx_register_variable.
416

October 2011
Command Reference
cdc_custom_fx
cdc_custom_fx Check, Default On

-cdc_custom_fx off
Ensures the data output of the transmitting register is stable in the receiving registers
metastability window. Typically, the data output of the transmit register can change value in
the receive registers metastability window. This change can cause metastability of the
receiving registers output, but the circuit is hopefully tolerant of this effect. The
-cdc_custom_fx off option disables this check.
This check fires when any of the bits in the receive register is metastable.
Firing message: Data changed in metastability window.
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.
Metastable Cycles number of clocks aligned cycles in which tx_register_variable is

changing and rx_register_variable is loading.
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
Clocks Aligned Cycles is updated each cycle. The other statistics and corner case are
updated only if the rx_register_variable is loaded.
clks_aligned[65:0]
When the assertion compiler instantiates a cdc_custom_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_custom_fx checker.
During the analysis phase, promotion is generated for the cdc_custom_fx checker. The
tx_reg signal is the transmitting register. The custom synchronizer input port is specified as
rx_reg. These promotions should only be done on the input ports of the custom
synchronizer. If there is a crossing from an output port to another synchronizer, then no
promotions are done. CDC promotion is enabled by the set_cdc_preference global directive.

October 2011
417
Command Reference
cdc_custom_fx
418
During simulation, metastability is injected on the port specified as rx_reg. The metastable
value is a function of the data value on the port before and after the tx_clk edge. There are
two main limitations when compared to general CDC-FX flow as follows:
The active edge of rx_clk should occur after tx_clk. If rx_clk ticks before or in the
same delta cycle as tx_clk, then metastability injection does not impact the simulation
behavior.
The data transitions can only be delayed. The data transitions cannot be advanced one
clock cycle as in the general CDC-FX solution. In other words, the stop window is
implicitly set to zero.

October 2011
Chapter 7
GUI Reference
GUI Main Window
Menus
Toolbar
Debugging Windows
Design Data
Windows
Analysis
Windows
GUI Basics
The main GUI window has popup menus that appear when you select certain window objects
and right-click. Each popup menu shows commands relevant to the selected object (or objects).
For example, right-clicking on an instance of a CDC scheme displays commands (such as Show
Source and Show Schematic) for displaying the various debug windows for that check.
Popup Menu

October 2011
419
GUI Reference
GUI Main Window
For some objects (such as check types and schematic objects), the GUI window has hover help,
which displays relevant information about an object when you hover the cursor over the object.
u1.txdata3_r1
Hover Help
In the default layout, the design data windows and the analysis windows are stacked, that is,
they occupy the same part of the GUI window. To display (bring to the front) a particular
window, click on its associated tab.
Project Window
Design Window
Design Tab
Drag and Drop

For some objects (such as ports, instances and signals), some GUI windows are linked by a
drag-and-drop capability. Here, if you click-hold on an object in a source window, then drag
the objects name and drop it into a target window, the object is added to the new window.
For example, you can drag and drop objects from the objects window into a schematic window
(Figure 7-1) and you can drag and drop signals from the details window to the waveform
window
420

October 2011
GUI Reference
GUI Main Window
Figure 7-1. Dragging and Dropping a Port to the Schematic Window
Object Icon
Click-hold and drag object
to the target window
Showing and Hiding Columns in Windows

Use the configure columns buttons to show/hide columns (i.e., fields) in windows.
Figure 7-2. Configuring Columns in Windows
Configure Columns Button
Displays dialog for selecting
columns to display in the window.

October 2011
421
GUI Reference
GUI Main Window
Showing and Closing Windows

Use the View menu to show and close a window. Use the close button (x) at the top right of a
window to close that window.
View Menu
Indicates the pane is displayed
close Button (X)

Closes the window
Changing the Help Browser

Mozilla is the default help browser, but you can set a different browser for online help. To
change the help browser for the GUI: Tools >Edit Preferences. Select the By Name tab. Set up
the browserExec/browserCommand data: browserExec is the path to the browser executable;
browserCommand is the command passed to the browser executable. For example:
browserExec: /usr/bin/firefox
browserCommand: -browser -height 500 -width 600 <URL>
<URL> is a literal. It is used to pass the URL of the target document to the browser. For
example, the invocation of the Firefox browser has URL as an option. For Mozilla, the option is
openfile(URL), so its Command value is:
openfile(<URL>).
Depending on your selected browser, you might need to adjust some browser preferences. From
the title page of an HTML document, scroll down and click on the Browser Requirements link.
Select the Browser Settings topic and follow the directions for your brand of browser.
With the Firefox browser, if the fonts are too small, you can adjust the font sizes from the
browser itself (for example, using [CTRL SHIFT +] and [CTRL ]).
422

October 2011
GUI Reference
GUI Main Window
Window Layouts
Adjust the current window layout using the move-window buttons to drag windows to new
locations and the stretch-shrink bars to adjust the sizes of the windows (Figure 7-3).
Figure 7-3. Organizing the Window Layout
Move-Window Button
Click-hold and drag window outline to
the new location for the window.
Window
Outline
Stretch/Shrink Bar
Click-hold and drag
window border to
reshape the window
Zoom/Unzoom Buttons
When the window shows multiple windows, each window has a zoom button (+) at the top right
of the window. A zoomed window takes up the entire layout (Figure 7-4). The other windows
are available from tabs at the bottom of the window. When you select a tab, its window is
displayed as a zoomed window. The unzoom button () on the zoomed window returns the
window to the composite window layout.

October 2011
423
GUI Reference
GUI Main Window
Figure 7-4. Zoomed View of a Window

Zoom Button
On a layout shows
the zoomed view
view of the window
Unzoom Button
Returns the window
to the previous layout
Tabs for the

other panes
Undock/Dock Buttons
The undock button at the top right of a window undocks the window, so it appears as a separate
window (Figure 7-5). You also can undock a window by using its move-window button to drag
the window to the edge of the main window. The dock button on an undocked window docks
the window back into the main window.
Figure 7-5. Undocking a Window
Undock Button
Moves the window
to its own window
Dock Button
Re-docks the window
back to the main window
424

October 2011
GUI Reference
GUI Main Window
Saving and Restoring the GUI Window Layout

Moving windows to new locations in the GUI window, adjusting the size and shapes of
windows, showing and closing windows, undocking windows, zooming to a window, and
undocking windows are all examples of modifying the GUI window layout. But different
layouts are useful for different stages of the analysis and debug process. Rather than manually
re-arrange the GUI window real estate each time you want to work on a new stage of the flow,
you can save the current layout at any time. To do this, use the Layout >Save command and
specify a name for the current window layout. The window layouts are stored as part of the
project, so they persist between project sessions.
To restore the GUI window to a saved layout, use the drop-down Layout menu from the toolbar
or select the layout from the main Layout menu (Figure 7-6).
Figure 7-6. Saving and Restoring a GUI Window Layout
Layout > Save
Saves the current window layout
with the specified name
Layout Menus
Restore saved window
layouts
Tabs for the

other panes

October 2011
425
GUI Reference
Analysis Windows
Analysis Windows
The CDC GUI has the following windows that show information about CDC analysis results.
Errors/Warnings Window shows errors and warnings reported by CDC analysis.
CDC Checks Window shows the static CDC analysis results and the merged results
of formal verification and simulation with promoted CDC assertions.
Errors/Warnings Window
The error/warnings window (Figure 7-7) shows the errors and warning generated by the formal
session.
Figure 7-7. Errors/Warnings Window
Hover the cursor over a message to display additional information about the error/warning.
Right-click on a message to pop up a menu that you can use to:
426
Import Log loads information from a log file.
Go to Source in the associated log file document in a source browser.
Go to Log File in the detailed log file document in a source browser.
Find displays the find panel.

October 2011
GUI Reference
Analysis Windows
Figure 7-8. Error/Warning Hover Help

Hover Help
Hovering cursor over error message
displays bubble help message with
added information
CDC Checks Window

The CDC checks window (Figure 7-9) 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 schemes 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 53 for an explanation of the status flags used to show
the status of these field entries.

October 2011
427
GUI Reference
Analysis Windows
Figure 7-9. 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 49).
If a simulation database (created by simulating the CDC protocol checkers) is merged in, each
entry has the following additional information:
428
Checker Name of the CDC protocol checker.
Evaluations Evaluation count of the checker in simulation.

October 2011
GUI Reference
Analysis Windows
Covered Whether or not the checkers 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 set_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 set_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.

October 2011
429
GUI Reference
Debug Windows
Debug Windows
The CDC GUI has the following tools used to debug problems detected by CDC analysis:
Details Window shows details for the design instances/entities.
Objects Window design objects (ports and internal registers/nets) for design units.
Log/Report Browsers shows logs and reports.
Schematics Viewer shows schematics for the design.
Source Code Editor displays and edits source code..
Waveform Viewer shows waveforms for assertion firings, sanity checks, anystate
checks and cover points.
The debug windows are not all stacked together like the design data windows and the analysis
windows. The firings, objects, details and FSM viewer windows are singular windows. Only
one of each can be displayed and the contents are updated depending on your selections in the
analysis windows. The source code editor, schematic browser and waveform viewer are
multiple windows. You can display multiple instances of each of these windows. Each of these
three groups of windows are stacked. For example, you can display waveforms for several
property violations at the same time. The waveform windows are stacked together. Clicking on
a tab displays its associated waveform viewer in front.
Details Window
The details window (Figure 7-10) shows the details for the design instance or entity selected in
the design window.
Figure 7-10. Details Window
The window shows the following information:
430
Name instance/entity name.
Inst Type type of instance (for example, Module Instance).
Module name of the model (module/architecture) for the instance.

October 2011
GUI Reference
Debug Windows
Clock Group clock group that clocks the instance, or unspecified.
Assertion MSD ratio of the instances registers covered by assertions (within the
Minimum Sequential Distance).
Objects Window
The objects window (Figure 7-11) displays design objects (ports and internal registers/nets) for
the current design unit instance . Click on a design unit instance in the design window to select
the current design unit.
Figure 7-11. Objects Window
Use drag-and-drop to add selected objects to the waveform viewer or the schematics viewer.
Right-click on an entry to pop up a menu that you can use to:
Go to Declaration in the source file in a source code editor.
Edit Directive
Set Signal see set_cdc_signal on page 301.
Set Reset see set_reset on page 314.
Set Constant see set_constant on page 307.
Set Port Domain see set_cdc_port_domain on page 279.
Set Clock see set_cdc_clock on page 265.
Show in Schematic
New View open a new schematic viewer showing the selected objects.
Active View add the selected objects to the active schematic view.

October 2011
431
GUI Reference
Debug Windows
Abstract View show the selected objects in an abstract view of the design unit.
Select in Schematic selects and highlights the selected objects in the active schematic
view.
Add to Path Tracing
From Signals Add the selected objects to the From Signals group for path tracing.
To Signals Add the selected objects to the To Signals group for path tracing.
Thru Signals Add the selected objects to the Thru Signals group for path tracing.
Add to Wave Window
Current add the selected objects to the current waveform view.
Always always add the selected objects to new waveform views.
Log/Report Browsers
You can open a log or report directly in a browser (Figure 7-12):
File > Open or
Log menu to view a particular log file.
Report menu to view a particular report.
in the toolbar.
Figure 7-12. Log/Report Browser
432

October 2011
GUI Reference
Debug Windows
You also can open a log (Figure 7-13) indirectly from the popup menu for a selected item in the
errors/warnings window:
Go to Log File shows the log with the corresponding error/warning flagged.
Figure 7-13. Log Browser Showing Error/Warning Information

October 2011
433
GUI Reference
Schematics Viewer
Schematics Viewer
Running a Show >Schematic command for a CDC check or a Show in Schematic command for
a clock in the Clocks window displays a schematic view of the clock domain crossing scheme
or the drivers/receivers of the selected clock (Figure 7-14).
Figure 7-14. Schematics Viewer
Expanding Logic in the Schematic View

The Show >Fanin popup command for a property (in the Properties tab) displays the
collapsed schematic view of the property. You can expand the view to show details of
the fanin logic driving the property. You can:
434

October 2011
GUI Reference
Schematics Viewer
Expand the view to show the drivers/readers of a net or port. To do this, double-click
on the net or port.
expand drivers/readers
of a net or port
double-click
on net/port
Expand the view to show details of combinational logic. To do this, double-click on

the combo logic block.
expand
combinational logic
double-click
on logic
block
TBS

October 2011
435
GUI Reference
Schematics Viewer
Zooming the Schematic View In or Out
A quick way of zooming the view (in or out) to fit the viewer (i.e., zoom full) is to
middle-click and drag up and left.
zoom-to-fit
drag
middle-mouse
up & left
A quick way of zooming the view out is to middle-click and drag up and right. The
longer the distance dragged, the greater the amount zoomed.
drag
middle-mouse
up & right
zoom out
A quick way of zooming the view in is to middle-click and drag left/right (level or
down). The view zooms in to the range selected by the bounding box.
drag
middle-mouse
down & left
or right
436
zoom in

October 2011
GUI Reference
Source Code Editor
Source Code Editor

You can open a source code file for editing or browsing (Figure 7-15):
Directly:
File > Open or
Edit from the project window popup window opens the selected file at line 1.
in the toolbar: opens the specified file at line 1.
Indirectly from the popup menu for certain selected items:
Go to Declaration opens the source code file containing the items declaration
with the declaration flagged. This command is available for the following windows:
project, design, modules and objects.
Go to Instantiation opens the source code file containing the module instantiation
with the instantiation flagged. This command is available for the following
windows: design and modules.
Go to Source opens the source code file containing the erroneous construct with
the construct flagged. This command is available for the following window:
errors/warnings.
Show Source opens the file containing the associated construct with the construct
flagged. This command is available for the following windows: property checks,
policy checks, design checks, properties and firing inputs.
Figure 7-15. Source Code Editor

October 2011
437
GUI Reference
Waveform Viewer
Waveform Viewer
The Show Waveform command for a CDC protocol check firing displays a waveform for the
firing (Figure 7-16).
Figure 7-16. Waveform Viewer
Saving Waveforms and Waveform Formats

As you use the waveform viewer to analyze firings and coverage data, you can adjust the
formats of various view objects to customize the views appearance and organize the
waveforms to help simplify your analysis. Then, you can take a snapshot of the current setup of
a wave view to use for multiple purposes. To save this snapshot:
File >Save Format. In the Save Format dialog, specify a pathname to save the
waveform format file.
The wave view data are saved as a do file.
Loading Waveforms and Waveform Formats

You can load a waveform configuration file into an empty view, edit the file and load it into
another view and also take code snippets from the file to create a custom do file for other uses.
438
To reconstitute a saved view in an empty viewer: From a view generated from the same
data as the saved view: File >New Window. An empty wave viewer appears. From this
viewer: File >Load. From the Open Format dialog, select the saved do file. The new
viewer displays the saved wave view.
October 2011
GUI Reference
Waveform Viewer
To load saved wave format data into the current wave view: Create a do file with the
desired wave format data (taken from a saved waveform format file), for example:
WaveRestoreCursors {{Config Complete} {1033 ns} 1}
configure wave -justifyvalue right
configure wave -timelineunits ps
bookmark add wave {Cmd Load} {{1774 ns} {3709 ns}} 0
bookmark add wave Firing {{893 ns} {4887 ns}} 0
From the current wave view: File >Load. From the Open Format dialog, select the do
file.
To load saved wave format data into the every wave view: Create a do file with the
desired wave format data (taken from a saved waveform format file), for example:
add wave -noupdate -format Logic -radix binary replay_qvl_.../clock1
add wave -noupdate -format Logic replay_qvl_.../pci_err__in
add wave -noupdate -format Logic -radix binary replay_qvl.../combo
WaveRestoreCursors {{Config Complete} {1033 ns} 1}
configure wave -justifyvalue right
configure wave -timelineunits ps
bookmark add wave {Cmd Load} {{1774 ns} {3709 ns}} 0
bookmark add wave Firing {{893 ns} {4887 ns}} 0
From the GUI main window: Tools >Edit Preferences. From the Edit Preferences
dialog, go to the Misc tab. In the Waveform section, add the do file to the Configuration
File field.
This procedure applies the saved wave view formatting to every waveform. The identity
of the wave format configuration file is saved in .0in_ui_local_prefs, so it is persistent
across GUI sessions run from the current directory. You also can use this procedure to
automatically load a reference set of specific signals to every waveform. These
signals provide a baseline for analyzing formal results. If the added signals are in the
fanin/fanout cones of the current property, formal analysis controls affect their
individual waveforms and the baseline information is useful. Signals not in these cones
provide baseline information up to the starting state for formal analysis, but are set to
flat-line after that.
Zooming the Wave View In or Out
Use the zoom in, zoom out, zoom full and zoom in on active cursor icons
(
).

October 2011
439
GUI Reference
Waveform Viewer
A quick way of zooming the view (in or out) to fit the viewer (i.e., zoom full) is to
middle-click and drag up and left.
drag
middle-mouse
up & left
A quick way of zooming the view out is to middle-click and drag up and right. The
longer the distance dragged, the greater the amount zoomed.
drag
middle-mouse
up & right
zoom-to-fit
zoom out
A quick way of zooming the view in is to middle-click and drag left/right (level or
down). The view zooms in to the range selected by the starting and ending points.
drag
middle-mouse
down & left
or right
zoom in
Capturing Zoomed/Scrolled Views as Bookmarks

As you analyze a waveform, you zoom the view in and out, scroll the waves back and forth in
time and scroll up and down lists of signals. Often you want to capture specific views, so you
can quickly jump the view to them. Such a captured view is called a bookmark. You can:
440
Create a bookmark for the current view: Add >Bookmark. In the Bookmark Properties
dialog, provide a mnemonic for the view in the Bookmark Name field. By default, the
bookmark saves the zoom value (Zoom Range) and the vertical scroll location (Top
Index). You can select to save either or both with the bookmark.
Jump the viewer to a saved bookmark view: View >Bookmarks >name. The Bookmarks
submenu lists all the saved bookmarks. Here, name is ne of the bookmarks.

October 2011
GUI Reference
Waveform Viewer
Manage bookmarks: View >Bookmarks >Bookmarks. Use the Bookmark Selection

dialog to Add, Modify, Delete and Goto individual bookmarks.
Selecting Multiple Signals for Format Operations

Some format operationssuch as setting the signal value radix and combining signals into
signal groupscan be applied to multiple signals at a time. When you click on a signal, it is
selected (but other selections are deselected). To select multiple signals:
Use SHIFT-click to select a range of adjacent signals.
Use CTRL-click to add individual signals to the current selection.
Changing the Display Properties of Signals

Double-click on the signal name. The Wave Properties dialog for the signal is displayed. You
can:
Give the signal a Display Name, which is shown in the pathname pane in place of the
signal name.
Select colors for the signal waveform (Wave Color) and signal name (Name Color).
Change the Radix (for example, decimal, octal, hex, binary) for the displayed signal
value.
To change display properties for multiple signals, select the signals and use the Format menu
commands (Radix, RadixEnum, Format, Color and Height) to adjust their display properties as
a group.
Changing the Signal Pathname Properties

Signal names are shown in the grey signal pathname pane at the left of the waveform viewer.
You can toggle between short signal names and full pathnames.
Click on the toggle leaf/full names icon (
) at the top left of the cursor pane.
toggle
leaf names
full names
edit grid/timeline

October 2011
441
GUI Reference
Waveform Viewer
Since full signal names can be overly long, you can set the maximum number of
hierarchical levels displayed in the long names. To do this: click the edit grid/timeline
icon ( ) next to the pathname toggle icon. From the Display tab of the Wave Window
Properties dialog, set the Display Signal Path field to the maximum number of pathname
elements to display.
Adding Signals
To add signals, do one of the following:
From the signals pane popup menu, run Add Signals >Current View. In the Add Signal
to Wave Window dialog, select the signals and click on Add.
From the objects window, select an object to add to the waveform. Drag and drop the
object to the signals pane of the waveform viewer.
drag and drop

Waveform View
442
Objects Window

October 2011
GUI Reference
Waveform Viewer
These signals are added to the current wave view. You also can identify signals to add to every
wave view. To do this:
From the signals pane popup menu, run Add Signals >Always. In the Always Add
Signals to Wave Display dialog, update the Always Add These Signals list.
Removing Signals
To remove signals from the viewer: select the signals and press Delete.
Organizing Signals
The signals panel at the left of the waveform viewer lists the signals in the waveform. Signals
are identified by blue diamonds ( ). To organize the signals in the signals panel you can:
Combine signals into a bus. To do this: select the signals for the bus and run Tools
>Wave >Combine Signals. From the Combine Selected Signals dialog, provide a name
for the new bus. Set the other fields to determine the ordering of the signals in the bus.
To remove the old signals after the bus is created, select Remove selected signals after
combining. The created bus is identified by a red diamond ( ). The bus waveform
shows the the combined values of the constitute signals.
Combine signals into a wave group. To do this: select the signals for the group and run
Tools >Groups. From the Wave Group Create dialog, provide a name for the new wave
group. The created group is identified by a red diamond ( ). No waveform is displayed
for the group itself, but waveforms for the group members are displayed when the group
is expanded.

October 2011
443
GUI Reference
Waveform Viewer
Add category dividers. Signals in the signals panel are separated into categories
labeled with dividers. When you add signals they are automatically assigned to the
Added Signals category (unless they are added by dragging and dropping).
To help you organize signals, you can add new category dividers. To do this, select the
signals and run View >Wave >Add >Divider. The Wave Divider Properties dialog is
displayed. Specify a divider name and specify the divider height (to add extra spacing
around the divider).
custom
category
dividers
To move a divider to a new location, select the divider and drag. To delete a divider,
select the divider and press Delete.
Re-order signals. Select the signals and drag to the new location. You also can sort the
signals alphabetically with the View >Wave >Sort commands (Ascending, Descending,
Ascending Full Path and Descending Full Path). Signals are sorted within each category
(defined by the dividers).
Using Multiple Window Panes

Initially, the wave view has a single window pane showing the signals and waveforms. The
wave view has one scroll bar. So for large numbers of signals, you scroll back and forth to
visualize comparisons. To solve this problem, you can add one or more window panes. To do
this, run Add >Window Pane. A new empty window pane with a scroll bar is added just above
the cursor region. Then, you can drag and drop (or copy and paste) signals from the original
pane to the added pane.
444

October 2011
GUI Reference
Waveform Viewer
original pane
pane
boundary
drag and drop

signals to the
new pane
separate
scroll
bars
active
pane
bar
added pane
Click and drag the pane boundary to reshape both panes. To delete a pane, click in the pane (the
active pane is identified with a white bar) and run Edit >Delete Window Pane.
Using Cursors to Analyze Events
The initial waveform shows at least three cursors. These are vertical lines that let you compare
signal behavior at specific times.
Start indicates the starting state of formal analysis.
Firing indicates a firing of the associated assertion or sanity check. For a cover property
or covered checker, the Firing cursor indicates when the property became covered.
A user-defined cursor is also displayed.
The left (gray) panel of the cursor pane lists the cursors. You can:
Lock/unlock a cursor by clicking on the corresponding lock icon ( ). A locked cursor

cannot move and is shown in red. The Start and Firing cursors are initially locked and
should be left locked. You can slide an unlocked cursor back and forth in time. The
cursor time is shown at the bottom of the cursor and also in the left panel. To set a cursor
at a precise time (for example, if you have trouble adjusting the cursor), click on the
corresponding cursor tool ( ). Type the exact time in the Cursor Properties dialog.
Give the cursor a name by selecting and right-clicking on the cursor name and entering a
user-specified name.
Add a new cursor by clicking on the add cursor icon (
Remove a cursor by selecting the cursor and clicking on the corresponding remove
cursor icon ( ).

October 2011
).
445
GUI Reference
Waveform Viewer
Capturing a Waveforms Image

Undock and size the waveform viewer. From the undocked waveform viewer:
To save the image as a BMP file, File >Export >Image. Use the Save Image dialog to
save the file.
To save the image as a PostScript file, File >Print PostScript. Use the Write PostScript
dialog to print all or part of the waveform to a PS file.
Do not remove the focus from the waveform window until the capture completes (to prevent
the captured image from being corrupted).
Adding a Source Code Variable to a Waveform

You can add a source code variable as a signal in a waveform view in two ways:
Select the variable. All references to the variable are then highlighted. Drag and drop
any reference to the variable to any wave view at the desired location.
add a signal to a wave view
from the source code viewer
drag and drop
Select the variable. All references to the variable are then highlighted. Place the cursor
over one of the variables references and run the Add to Wave Window popup command.
The signal is added to the Added Signals category of the last displayed wave view.
Drag the signal to the intended category and location.
Annotating Source Code with Variables Values

You can turn on source code annotation in either of two ways:
446

October 2011
GUI Reference
Waveform Viewer
Use the Source Annotation button in the toolbar (

on/off.
Run View >Show Source Annotation.
) to toggle source code annotation
With source code annotation on, the source code view shows values of the variables in the
source code. They are displayed in red under the associated variables. The variables values are
their values at the time of the current selected cursor in the current wave view. So, as you move
a cursor along a wave view, the source code reflects the changing values of the variables.
moving a cursor changes

the annotated values
variables values are shown for the time of the current active cursor

October 2011
447
GUI Reference
Project Mode Windows

The CDC GUI has the following windows that show information about CDC projects.
Project Window manages the source code files for the project.
Design Window shows the hierarchy of the DUT instances.
Modules Window shows the DUT design units.
Clocks Window shows the DUT clock signals.
Directives Window shows the current global directives.
The project mode windows display objects at the design unit level, set global directives for the
objects, manage source files for the project and set basic project properties. In addition, some
windows have a find panel (Figure 7-17). Use this panel to search for matches to specified text
in the window
Figure 7-17. Find Panel in Design Data Windows
Pull-down Menu
Wrap search
Match whole word
Find all matches
Search direction
Project Window
The project window (Figure 7-18) manages the source code files for the project.
Figure 7-18. Project Window
448

October 2011
GUI Reference
Edit the source file.
Compile the source file, all source files or the out-of-date source files.
Add to Project new or existing files.
Import File List from a Verilog or VHDL filelist file.
Change Compile Order move the selected files up or back in compile order.
Remove from Project the selected source file.
Change Compile Options change the work library, language syntax or language type
and add command line options.
Close Project close the current project.
Design Window
The design window (Figure 7-19) shows the hierarchy of the DUT instances.
Figure 7-19. Design Window
Go to instance or declaration in the source file document.
Filter Checks displays the Filter Design Checks dialog for filtering the display of
types of design checks.
Edit Directive see set_black_box on page 264 and set_cdc_synchronizer on

page 304.
Show in Schematic view the selected design unit in a schematics window.
Select in Schematic select the design unit in the current displayed schematics
window.

October 2011
449
GUI Reference
Search by Column search for text pattern in design workspace.
Copy to Clipboard save the design unit name or details to the clipboard.
Show Details display a details window.
Find Displays the find panel.
Modules Window
The modules window (Figure 7-20) shows the DUT design units with their assertion densities.
Figure 7-20. Modules Window
450
Go to declaration or instantiation in the source file.
Edit Directive see set_black_box on page 264 and set_cdc_synchronizer on

page 304..
Show in Schematic view the selected instance in a schematics window.
Select in Schematic select the instance in the current displayed schematics window.
Copy to Clipboard save the design unit name or details to the clipboard.

October 2011
GUI Reference
Clocks Window
The clocks window (Figure 7-21) shows the DUT clock signals.
Figure 7-21. Clocks Window
Right-click on a clock to pop up a menu that you can use to:
Go to clock declaration in the source code or the design unit with the clock in the
hierarchy.
Edit Directive see set_cdc_clock on page 265 and set_constant on page 307..
Show in Schematic shows the clock drivers, clock readers or both in a schematics
view.
Select in Schematic zooms in and selects the clock signal in the active schematic
view.
Add to Path Tracing adds the clock to the path tracing points.\
Copy to Clipboard copies the clock path (name) or name and clock group (details) to
the clipboard.
Show Details shows the details window with clock name and clock group name.

October 2011
451
GUI Reference
Directives Window
The directives tab (Figure 7-22) shows the current global directives. Use this tab to add and edit
global directives.
Figure 7-22. Directives Window
452
Add view a dialog customized for the selected type of directive. After completing the
form, the directive is added to the directives tab. The directive types are: Clock
(set_cdc_clock on page 265), Reset (set_reset on page 314), Port Domain
(set_cdc_port_domain on page 279), Signal (set_cdc_signal on page 301), Report
(set_cdc_report on page 296), Synchronizer (set_cdc_synchronizer on page 304),
Constant (set_constant on page 307), Reconvergence (set_cdc_reconvergence on
page 294), Preference (set_cdc_preference on page 286), Black Box (set_black_box
on page 264), Memory (set_memory on page 310), FX Metastability
(set_cdc_fx_metastability_window on page 271), FX Check (set_cdc_fx_check on
page 270) and FX Timescale (set_cdc_fx_timescale on page 272).
Edit view a dialog for changing the selected directive.
Move move the selected directives up or back in compile order.
Delete remove the selected directives.
Import load a set of directives from a text file.
Export save selected directives to a text (control) file.

October 2011
Chapter 8
Reports/Logs Reference
The CDC compiler automatically generates the following files:
0in.log Short log file that is a copy of the standard output.
0in_cdc.db CDC database for examining in the CDC GUI environment.
0in_cdc.rpt Clock domain crossing report.
0in_cdc_setting.rpt CDC settings report.
0in_cdc_ctrl.v Clock domain crossing checker control file, which contains suggested
CDC protocol checker directives for signals crossing clock domains (for use with
simulation and the formal tools).
0in_cdc_design.rpt CDC design report.
0in_cdc_mode_ctrl.v Control file with directives specifying the modes inferred by

modal analysis (generated if the cdc -report_modes option is specified).
0in_cdc_param.inc Checker parameter file.
0in_detail.log Detailed log of the transcript.

October 2011
453
CDC Design Report
CDC Design Report

The clock domain crossing design report file (0in_cdc_design.rpt) shows detailed information
about the clocks and clock groups in the design. It also shows summary information about
design elements. The report contains the following:
Clock Group Summary (see page 454)
User-Specified Clock Groups (see page 455)
Inferred Clock Groups (see page 455)
Ignored Clock Groups (see page 457)
Mode Design Information (see page 457)
General Design Information (see page 457)
Detailed Design Information (see page 457)
Port Domain Information (see page 458)
Mode Information (see page 459)
Clock Group Summary

The 0in_cdc_design.rpt file contains the clock group summary that displays the total counts for
each type of clock group as shown in Example 8-1.
There are two types of clock groups: user-specified and inferred. All user-specified clocks are
defined by the user with the set_cdc_clock global directive. Inferred clock groups are clocks
that are not specified, but inferred by the CDC tool.
Example 8-1. Clock Group Summary
Clock Group Summary for top
=============================
Total Number of Clock Groups
: 5
Number of User-Defined Clock Groups : 0
Number of Inferred Clock Groups
: 5
Number of Ignored Clock Groups
: 1
454

October 2011
CDC Design Report

The 0in_cdc_design.rpt file contains the user-specified clock groups created using
set_cdc_clock global directive (page 265) as shown in Example 8-2.
Example 8-2. User-Specified Clock Groups
===========================
Group
0(35 Register Bits)
----------cpu_clk
Group
1(119 Register Bits)
----------core_clk
fifo_1_d.wr_clk
fifo_1_d.u0.Wclk
fifo_0_h.wr_clk
fifo_0_h.u0.Wclk
Group
----------mac_clk
fifo_1_d.rd_clk
fifo_1_d.u0.Rclk
fifo_0_h.rd_clk
fifo_0_h.u0.Rclk
crc_1.clk

Inferred clock groups (including gated clocks) are reported as clock domains in the clock tree.
The 0in_cdc_design.rpt file contains the clocks that comprise the clock groups inferred by the
compiler as shown in Example 8-3.
Example 8-3. Inferred Clock Groups
=====================
Group
0(25 Register Bits)
----------CLK3
Group
1(38 Register Bits)
----------CLK1
sy1.I_CLK
ntX_rg.clk
edX_rg.clk
tgX_rg.clk

October 2011
455
CDC Design Report
O1r_0_rg.clk
O2r_0_rg.clk
O2r_1_rg.clk
O2r_2_rg.clk
O2r_3_rg.clk
Group
2(12 Register Bits)
----------CLK2
sy2.I_CLK
sy3.I_CLK
sy4.I_CLK
sy5.I_CLK
detrxst_0_rg.clk
Group
----------CLKX [gate: ((TCS === 1b0) ? CLK0 : ((TCS === 1b1) ? TRK : 1bx))]
O2w_0_rg.clk
O2w_1_rg.cl
O2w_2_rg.clk
O2w_3_rg.clk
sy6.I_CLK
sy7.I_CL
sy8.I_CLK
sy9.I_CLK
sya.I_CLK
modr.I_CLK
modr.modr1_0.I_CLK
modr.modr1_0.syb.I_CLK
modr.modr1_0.syc.I_CLK
. . .
modr.modr1_3.ft_rg.clk
modr.modr1_3.f_r_rg.clk
Group
4(5 Register Bits)
----------modr.rz0_tree [gate: (TCS ? TRK : ((I5[1:0] == 2'b0) ? RCLK[0] :RCLK[1]))]
modr.wz_rg.clk
modr.t_l0_rg.clk
456

October 2011
CDC Design Report

Ignored clock groups are identified by the set_cdc_clock -ignore global directive and are listed
in the 0in_cdc_design.rpt file (Example 8-5).
Example 8-4. Ignored Clock Groups
====================
Group
----------mac_clk [gate: (scan_mode ? scan_clk : mac_clk_in)]
fifo_1_d.rd_clk
fifo_1_d.u0.Rclk
fifo_0_h.rd_clk
fifo_0_h.u0.Rclk
crc_1.clk
Mode Design Information

The Mode Design Information table is reported if you specify set_cdc_preference
-report_mode_signals (Example 8-5). The Mode Control Signals portion of this table lists mode
control signals specified or inferred.
Example 8-5. Mode Design Information
Mode Design Information
=======================
Mode Control Signals
====================
in1[2]
in1[0]
in1[15]
in1[20]
Non-Mode Control Signals
========================
None

The 0in_cdc_design.rpt file contains the general design information that displays the total
counts for each basic design element as shown in Example 8-6.
Example 8-6. General Design Information
==========================
Number of Black Boxes = 0
Number of Registers = 438

October 2011
457
CDC Design Report
Number of Latches
Number of RAMs
= 0
= 0
Detailed Design Information

The 0in_cdc_design.rpt file contains the detailed design information that lists the basic design
elements (except the registers) as shown in Example 8-7.
Example 8-7. Detailed Design Information
Detail Design Information
=========================
RAMs:
----fifo_1_d.u0.data
fifo_0_h.u0.data
Port Domain Information

The 0in_cdc_design.rpt file contains the port domain information that displays the clock
domains identified for the designs ports as shown in Example 8-8.
Example 8-8. Port Domain Information
Printing port domain info
=========================
Port
Direction
Constraints
Clock Domain
Type
--------------------------------------------------------------------RST
input
Reset
{ CLK3 CLK1 } Questa CDC
CLK3
input
Clock
{ CLK3 }
Questa CDC
CLK0
input
--CLK1
input
Clock
{ CLK1 }
Questa CDC
CLK2
input
Clock
--RCLK
input
--I1
input
--I2
input
--I3
input
--I4_0_I
input
--I4_1_I
input
--I4_2_I
input
--I4_3_I
input
--IT
input
{ CLK3 }
Questa CDC
I5
input
{ CLK2 CLK3 } Questa CDC
TM
input
--TRK
input
--TCS
input
--O1
output
{ CLK1 }
Questa CDC
O2_0
output
{ CLK1 }
Questa CDC
O2_1
output
{ CLK1 }
Questa CDC
O2_2
output
{ CLK1 }
Questa CDC
O2_3
output
{ CLK1 }
Questa CDC
458

October 2011
CDC Design Report
The following defines the port domain information:
Port Port name.
Direction The valid directions are: input, output, and inout
Constraint Identifies clock, reset, stable and constant ports.
Clock Domain Clock domain of the port. The {clock} indicates the primary clock
for the domain, and {clock1 | clock2 |...} indicates the clock domain is
ambiguous. The relevant primary clocks are listed. An async indicates the port is
marked as an asynchronous port using the set_cdc_port_domain global directive
(page 279).
Type Method used to determine the clock domain. User indicates the clock domain is
assigned by the set_cdc_clock directive for clock ports, or by using the
set_cdc_port_domain directive. 0in_cdc indicates CDC analysis identified the domain
(or potential domains).
Mode Information
The 0in_cdc_design.rpt file contains the mode information as shown in Example 8-9. Note that
the mode information is generated only when the cdc -report_modes option is specified.
Example 8-9. Mode Information
Mode information
================
--------------------------------------------Mode
Type
Information
--------------------------------------------cdc_mode_0
Questa CDC Missing mode
cdc_mode_1
cdc_mode_2
--------------------------------------------User Modes
==========
None
Inferred Modes
==============
Constants in cdc_mode_0 (Missing)
----------------------------------------Signal
Value
----------------------------------------TCS
1'b1
----------------------------------------Constants in cdc_mode_1 (Missing)
-----------------------------------------

October 2011
459
CDC Design Report
Signal
Value
----------------------------------------TCS
1'b0
I5[1:0]
2'b00
----------------------------------------Constants in cdc_mode_2 (Missing)
----------------------------------------Signal
Value
----------------------------------------TCS
1'b0
I5[1:0]
2'b01
-----------------------------------------
460

October 2011
Clock Domain Crossing Report

The clock domain crossing report file (0in_cdc.rpt) shows detailed information about the CDC
signals and their schemes. The report contains the following:
User Comments (see page 462)
CDC Summary (see page 462)
CDC Promotion Summary (see page 462)
Violations (see page 463)
Cautions (see page 463)
Evaluations (see page 464)
Waived (see page 465)
Proven (see page 466)
Filtered (see page 467)
Custom Synchronization Modules (see page 467)
Asynchronous Reset Detection (see page 467)
Asynchronous Reset Synchronizers Detected (see page 468)
User-entered Asynchronous Reset (see page 468)
Asynchronous Reset with Missing Synchronizer (see page 468)
All Transmitting Signals (see page 470)
User Comments
The 0in_cdc.rpt file contains a user-specified comment when the set_cdc_report_comment
directive is specified, as shown in Example 8-11.
Example 8-10. User Comments
// 0in set_cdc_report_comments -comment SHIBA project; phase 3.
User Comments
=================================================================
SHIBA project; phase 3
-----------------------------------------------------------------

October 2011
461
CDC Summary
The 0in_cdc.rpt file contains the CDC summary that shows the counts for each type of
violation, caution, and evaluation as shown in Example 8-11.
Example 8-11. CDC Summary
CDC Summary
=================================================================
Violations (7)
----------------------------------------------------------------Single-bit signal does not have proper synchronizer.
(3)
Combinational logic before synchronizer.
(1)
(1)
(2)
Cautions (6)
----------------------------------------------------------------DMUX synchronization.
(2)
Multiple-bit signal across clock domain boundary.
(1)
FIFO synchronization.
(2)
Handshake synchronization.
(1)
Evaluations (1)
(1)
Waived (6)
----------------------------------------------------------------Multiple-bit signal synchronized by DFF synchronizer.
(4)
(2)
Proven (8)
(6)
(1)
Pulse Synchronization.
(1)
Filtered (1)
----------------------------------------------------------------Combinational logic before synchronizer.
(1)
CDC Promotion Summary

The 0in_cdc.rpt file contains the CDC promotion summary that shows the checkers that are
promoted and the checkers that are not promoted as shown in Example 8-12.
Example 8-12. CDC Promotion Summary
CDC Promotion Summary
==========================================================
Promoted protocol checkers
(18)
Unpromoted checkers (see 0in_detail.log) (6)
==========================================================
462

October 2011
Violations
The 0in_cdc.rpt file contains the CDC violations that shows the paths that result in the CDC
violations as shown in Example 8-13.
Example 8-13. Violations
Violations
========================================================================
-----------------------------------------------------------------------cpu_clk_in : start : init_done (/demo_top.v : 82)
core_clk_in : end : tx_state[0] (/demo_top.v : 193) (ID:no_sync_47305)
core_clk_in : end : tx_en (/demo_top.v : 86) (ID:no_sync_2628)
core_clk_in : end : tx_mask_valid (/demo_top.v : 90) (ID:no_sync_31547)
------------------------------------------------------------------------cpu_clk_in : start : pass_en[1] (/demo_top.v : 79)
mac_clk_in : end : check_en_r1 (/demo_top.v : 324) (ID:combo_logic_46571)
cpu_clk_in : start : err_thrs (/demo_top.v : 78)
mac_clk_in : end : check_en_r1 (/demo_top.v : 324) (ID:combo_logic_85239)
------------------------------------------------------------------------mac_clk_in : end : rx_payload_en (/demo_top.v : 381)
(ID:reconvergence_68819)
mac_clk_in : start : tx_sop_r2 (/demo_top.v : 360)
mac_clk_in : start : tx_eop_r2 (demo_top.v : 371)
mac_clk_in : end : rx_masked_data (/demo_top.v : 382)
mac_clk_in : start : tx_eop_r2 (/demo_top.v : 371)
mac_clk_in : start : tx_mask_valid_r2 (/demo_top.v : 303)
mac_clk_in : end : pass_valid (/demo_top.v : 47)
mac_clk_in : start : fifo_1_d.wp_s (/generic_fifo_dc_gray.v : 149)
mac_clk_in : start : fifo_0_h.wp_s (/generic_fifo_dc_gray.v : 149)
mac_clk_in : end : pass (/demo_top.v : 45) (ID:reconvergence_11498)
mac_clk_in : start : fifo_1_d.wp_s (/generic_fifo_dc_gray.v : 149)
mac_clk_in : start : fifo_0_h.wp_s (/generic_fifo_dc_gray.v : 149)
Cautions
The 0in_cdc.rpt file contains the CDC cautions that displays the paths that result in the CDC
cautions as shown in Example 8-14.
Example 8-14. Cautions
Cautions
=======================================================================

October 2011
463
DMUX synchronization. (dmux)
----------------------------------------------------------------------cpu_clk_in : start : fstp[7:1] (/demo_top.v : 81)
mac_clk_in : end : crc_1.scramble (/demo_top.v : 435) (ID:dmux_30303)
via : crc_1.fstp
core_clk_in : start : tx_mask_d (/demo_top.v : 198)
mac_clk_in : end : mask (/demo_top.v : 336) (ID:dmux_12402)

----------------------------------------------------------------------core_clk_in : start : fifo_1_d.wp_gray (/generic_fifo_dc_gray.v : 147)
mac_clk_in : end : fifo_1_d.wp_s1 (/generic_fifo_dc_gray.v : 150)
(ID:bus_two_dff_80275)
mac_clk_in : start : fifo_1_d.rp_gray (/generic_fifo_dc_gray.v : 148)
core_clk_in : end : fifo_1_d.rp_s1 (/generic_fifo_dc_gray.v : 150)
core_clk_in : start : fifo_0_h.wp_gray (/generic_fifo_dc_gray.v : 147)
mac_clk_in : end : fifo_0_h.wp_s1 (/generic_fifo_dc_gray.v : 150)
mac_clk_in : start : fifo_0_h.rp_gray (/generic_fifo_dc_gray.v : 148)
core_clk_in : end : fifo_0_h.rp_s1 (generic_fifo_dc_gray.v : 150)

---------------------------------------------------------------------cpu_clk_in : start : crc_seed[7:1] (/demo_top.v : 80)
mac_clk_in : end : crc_1.crc_16 (/demo_top.v : 434)
(ID:multi_bits_76265)
via : crc_1.seed
Evaluations
The 0in_cdc.rpt file contains the CDC evaluations that displays the paths that result in the CDC
evaluations as shown in Example 8-15.
Example 8-15. Evaluations
Evaluations
=======================================================================
----------------------------------------------------------------------cpu_clk_in : start : init_done (/demo_top.v : 82)
mac_clk_in : end : init_done_r1 (/demo_top.v : 119) (ID:two_dff_5840)
cpu_clk_in : start : pass_en[0] (/demo_top.v : 79)
mac_clk_in : end : pass_en0_r1 (/demo_top.v : 314) (ID:two_dff_81824)
core_clk_in : start : tx_sop (/demo_top.v : 88)
mac_clk_in : end : tx_sop_r1 (/demo_top.v : 360) (ID:two_dff_11314)
464

October 2011
core_clk_in : start : tx_eop (/demo_top.v : 87)

mac_clk_in : end : tx_eop_r1 (/demo_top.v : 371) (ID:two_dff_54238)
core_clk_in : start : tx_mask_valid (/demo_top.v : 90)
mac_clk_in : end : tx_mask_valid_r1 (/demo_top.v : 303)
(ID:two_dff_52495)
----------------------------------------------------------------------core_clk_in : start : tx_en (/demo_top.v : 86)
mac_clk_in : end : tx_en_r1 (/demo_top.v : 289) (ID:pulse_sync_13276)
Memory Synchronization. (memory_sync)
----------------------------------------------------------------------core_clk_in : start : fifo_1_d.u0.data (/dpmem2clk.v : 58)
mac_clk_in : end : fifo_1_d.u0.outport (/dpmem2clk.v : 60)
(ID:memory_sync_1560)
core_clk_in : start : fifo_0_h.u0.data (/dpmem2clk.v : 58)
mac_clk_in : end : fifo_0_h.u0.outport (/dpmem2clk.v : 60)
(ID:memory_sync_17786)
Waived
The 0in_cdc.rpt file contains the schemes assigned with waived severity using the
set_cdc_report -waived directive as shown in Example 8-15.
Example 8-16. Waived
Waived
=================================================================
----------------------------------------------------------------mac_clk : start : fifo_0_h.rp_gray (.../generic_fifo_dc_gray.v : 147)
core_clk : end : fifo_0_h.rp_s1 (.../generic_fifo_dc_gray.v : 149)
core_clk : start : fifo_0_h.wp_gray (.../generic_fifo_dc_gray.v : 146)
mac_clk : end : fifo_0_h.wp_s1 (.../generic_fifo_dc_gray.v : 149)
mac_clk : start : fifo_1_d.rp_gray (.../generic_fifo_dc_gray.v : 147)
core_clk : end : fifo_1_d.rp_s1 (.../generic_fifo_dc_gray.v : 149)
core_clk : start : fifo_1_d.wp_gray (.../generic_fifo_dc_gray.v : 146)
mac_clk : end : fifo_1_d.wp_s1 (.../generic_fifo_dc_gray.v : 149)

----------------------------------------------------------------<clock N/A> : end : pass (.../demo_top.v : 49) (ID:reconvergence_11498)

October 2011
465
mac_clk : start : fifo_0_h.wp_s (.../generic_fifo_dc_gray.v : 148)
mac_clk : start : fifo_1_d.wp_s (.../generic_fifo_dc_gray.v : 148)
mac_clk : end : pass_valid (.../demo_top.v : 51) (ID:reconvergence_31994)
mac_clk : start : fifo_0_h.wp_s (.../generic_fifo_dc_gray.v : 148)
mac_clk : start : fifo_1_d.wp_s (.../generic_fifo_dc_gray.v : 148)
Proven
The 0in_cdc.rpt file contains the paths with CDC transfer protocols that cannot be violated as
shown in Example 8-15.
Example 8-17. Proven
Proven
=================================================================
----------------------------------------------------------------core_clk : start : hdren_tx (.../demo_top.v : 76)
mac_clk : end : hdren_rx1 (.../demo_top.v : 77) (ID:two_dff_33161)
cpu_clk : start : init_done (.../demo_top.v : 94)
mac_clk : end : init_done_r1 (.../demo_top.v : 131) (ID:two_dff_5840)
cpu_clk : start : pass_en[0] (.../demo_top.v : 91)
mac_clk : end : pass_en0_r1 (.../demo_top.v : 371) (ID:two_dff_81824)
core_clk : start : tx_eop (.../demo_top.v : 99)
mac_clk : end : tx_eop_r1 (.../demo_top.v : 428) (ID:two_dff_54238)
core_clk : start : tx_mask_valid (.../demo_top.v : 102)
mac_clk : end : tx_mask_valid_r1 (.../demo_top.v : 360)
(ID:two_dff_52495)
core_clk : start : tx_sop (.../demo_top.v : 100)
mac_clk : end : tx_sop_r1 (.../demo_top.v : 417) (ID:two_dff_11314)

----------------------------------------------------------------mac_clk : end : rx_payload_en (.../demo_top.v : 438)
mac_clk : start : tx_eop_r2 (.../demo_top.v : 428) (Synchronizer
ID:two_dff_54238)
mac_clk : start : tx_sop_r2 (.../demo_top.v : 417) (Synchronizer
ID:two_dff_11314)

----------------------------------------------------------------core_clk : start : tx_en (.../demo_top.v : 98)
466

October 2011
mac_clk : end : tx_en_r1 (.../demo_top.v : 346) (ID:pulse_sync_13276)
Filtered
The -filtered_report option of the set_cdc_preference directive directs CDC analysis to include
details of filtered schemes in the 0in_cdc.rpt report as shown in Example 8-15. Use the
set_cdc_report -severity off directive to filter CDC schemes.
Example 8-18. Filtered
Filtered
=================================================================
----------------------------------------------------------------cpu_clk : start : err_thrs (.../demo_top.v : 90)
mac_clk : end : check_en_r1 (.../demo_top.v : 381)
(ID:combo_logic_85239)
Custom Synchronization Modules

The 0in_cdc.rpt file contains the custom synchronization modules that lists the modules
designated as custom synchronizers (see set_cdc_synchronizer on page 304) as shown in
Example 8-19. If detailed custom synchronization reporting is turned on (with the
-print_detailed_custom_sync option to the set_cdc_preference directive), cdc checks for custom
synchronizers on signals that do not cross clock domain boundaries. Either the wrong clock is
connected to the synchronizer or the synchronizer is not needed. The detailed custom
synchronization reporting adds this information in a Custom synchronizers which have internal
crossings section.
Example 8-19. Custom Synchronization Modules
Custom Synchronization Modules
==============================
sync
dff4
Custom synchronizers which have internal crossings:
===================================================
Module : cust_sync
Instance : u1
Asynchronous Reset Detection

The 0in_cdc.rpt file contains the asynchronous reset detection that contains details about CDC
signals used as asynchronous resets as shown in Example 8-20.

October 2011
467
Example 8-20. Asynchronous Reset Detection

Asynchronous Reset Detection ( dut )
====================================
Asynchronous Reset Synchronizers Detected

The 0in_cdc.rpt file contains the asynchronous reset synchronizers that are detected as shown in
Example 8-21.
Example 8-21. Asynchronous Reset Synchronizers Detected
Asynchronous Reset Synchronizers Detected
=========================================
rst1 ( clk1 )
User-entered Asynchronous Reset

The 0in_cdc.rpt file contains the user-entered asynchronous reset as shown in Example 8-22.
Example 8-22. User-entered Asynchronous Reset
User-entered Asynchronous Reset
===============================
None
Asynchronous Reset with Missing Synchronizer

The 0in_cdc.rpt file contains the asynchronous reset with missing synchronizer identifies the
CDC reset signals that are not synchronized properly and indicates the cause of the potential
problem as shown in Example 8-23.
Example 8-23. Asynchronous Reset with Missing Synchronizer
Asynchronous Reset with Missing Synchronizer
==================================================================
bad2.R2 (wrong reset_polarity : posedge U0.f2)
bad2.R3 (wrong clock : clk2)
good2.R1 (wrong reset_polarity : posedge U0.f2)
good2.R3 (wrong clock : clk2, wrong reset_polarity : posedge U0.f2)
468

October 2011
Asynchronous reset signals that are not synchronized properly either have no synchronizer or
are not properly synchronized as follows:
no synchronizer
Asynchronous reset detection reports no synchronizer if a reset signal is used to reset
flip-flops in a multiple clock design without using a synchronizer. In the following
subcircuit, rst_a is used directly (without a synchronizer):
rst_a is used
directly
rst_a
rst_a
1'b1
1'b1
clk_a
clk_a
Incorrect Usage
Correct Usage
wrong clock
Asynchronous reset detection reports wrong clock if an asynchronous reset signal is
used to reset logic in another clock domain. In the following subcircuit, the reset_a
signal is used incorrectly to reset logic in a clock domain other than the domain of
clk_a.
reset_a
rst_a
reset_a
rst_a
1'b1
1'b1
wrong clock
clk_a
clk_b
Incorrect Usage
clk_a
clk_a
Correct Usage
wrong reset polarity

Asynchronous reset detection reports a wrong reset polarity violation if an active high
asynchronous reset is used as an active low reset, or if an active low asynchronous reset

October 2011
469
is used as an active high reset (that is, the reset has the wrong polarity). In the following
subcircuit, the active high reset_a signal is used as an active low reset.
reset_a wrong polarity
rst_a
1'b1
1'b1
clk_a
clk_a
Incorrect Usage
reset_a
rst_a
Correct Usage
All Transmitting Signals

The 0in_cdc.rpt file contains the transmitting signals that lists the sources of signals that cross
clock domains as shown in Example 8-24.
Example 8-24. All Transmitting Signals
All Transmitting Signals (17)
========================================================
Name
Width
Location
-------------------------------------------------------init_done
1
/demo_top.v:82
pass_en[0]
1
/demo_top.v:79
tx_sop
1
/demo_top.v:88
tx_eop
1
/demo_top.v:87
tx_mask_valid
1
/demo_top.v:90
tx_en
1
/demo_top.v:86
fstp[7:1]
7
/demo_top.v:81
tx_mask_d
8
/demo_top.v:198
crc_seed[7:1]
7
/demo_top.v:80
fifo_1_d.wp_gray
5
/generic_fifo_dc_gray.v:147
fifo_1_d.rp_gray
5
fifo_0_h.wp_gray
5
fifo_0_h.rp_gray
5
fifo_1_d.u0.data
16
/dpmem2clk.v:58
fifo_0_h.u0.data
16
/dpmem2clk.v:58
pass_en[1]
1
/demo_top.v:79
err_thrs
8
/demo_top.v:78
470
Name Signal name.
Width Number of bits.
Location Source code location.

October 2011
CDC Settings Report
CDC Settings Report

The settings report (0in_cdc_setting.rpt) shows the global CDC settings and the results of
processing global CDC directives.
Section A: Global Directives (page 471)
Section B: Unmatched Global Directives (page 471)
Section C: Wildcard Expansion for Global Directives (page 472)
Section D: Global CDC Preferences (page 472)
Section E: Default CDC Scheme Settings (page 474)
Section A: Global Directives

Information about the CDC directives that can be processed (Example 8-25).
Example 8-25. Global Directives
*****************************************************************
Section A: Global Directives
*****************************************************************
set_cdc_fifo_preference directive
----------------------------------------------------------------//0in set_cdc_fifo_preference -no_write_sync -no_read_sync
set_cdc_signal directive
----------------------------------------------------------------//0in set_cdc_signal vhdl_inst.*c_enum -stable
set_cdc_synchronizer directive
----------------------------------------------------------------//0in set_cdc_synchronizer custom -module BB
. . .
Section B: Unmatched Global Directive

Directives (Example 8-26) that cannot be processed because:
Signal or module information cannot be resolved.
Module containing referred signals is black boxed

October 2011
471
CDC Settings Report
Example 8-26. Unmatched Global Directives

*****************************************************************
Section B: Unmatched Global Directives
*****************************************************************
1. Unrecognized signal/module
2. Module inside black box
----------------------------------------------------------------Directive
Module
----------------------------------------------------------------set_cdc_port_domain
LATCH
-----------------------------------------------------------------
Section C: Wildcard Expansion for Global Directives

Signals expanded from wildcard patterns in global directives (Example 8-27).
Example 8-27. Wildcard Expansion for Global Directives
*****************************************************************
Section C: Wildcard Expansion for Global Directives
*****************************************************************
*in* matches
vhdl_inst.in1
vhdl_in
v2k_in
Wildcards for set_cdc_signal directive
vhdl_inst.*c_enum matches
vhdl_inst.rec_enum
Section D: Global CDC Preferences

CDC preferences. (Example 8-28).
Example 8-28. Global CDC Preferences
*****************************************************************
Section D: Global CDC Preference
*****************************************************************
Option
Value
----------------------------------------------------------------multi_clock_convergence
FALSE
clock_in_data
FALSE
allow_enable_in_sync
FALSE
472

October 2011
CDC Settings Report
max_cdc_crossings
custom_fx
promote_reconvergence
mult_fanout_async
dmux_promote_sample
fx_use_local_clk
input_async
ignore_black_box
handshake_scheme
fifo_scheme
delayed_pulse
report_resets
detect_primary_output_clock
formal_add_bus_stability
formal_add_recon_stability
filtered_report
vectorize_nl
unrestricted_reconvergence
no_clock_as_rx
multi_paths
multi_through
report_undriven_custom_sync
print_port_domain_template
dmux_as_recon_start
print_detailed_custom_sync
report_black_box_recon
black_box_empty_module
sample_data_stability
infer_clock_off
detect_pure_latch_clock
promote_async_reset
complex_scheme_as_synchronizer

October 2011
0
FALSE
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
TRUE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
473
CDC Settings Report
Section E: Default CDC Scheme Settings

Default severities and promotions for CDC schemes (Example 8-29).
Example 8-29. Default CDC Scheme Settings
******************************************************************************
Section E: Default CDC Scheme Settings
******************************************************************************
CDC Scheme
Severity Enabled
Promotion
Promotion Status
-----------------------------------------------------------------------------async_reset
evaluation yes
none
off
black_box
evaluation yes
none
off
custom_sync
evaluation yes
none
off
dff_sync_gated_clk
evaluation yes
cdc_sync
on
four_latch
evaluation yes
cdc_sync
on
evaluation yes
none
off
memory_sync
evaluation yes
none
off
pulse_sync
evaluation yes
cdc_sync
on
shift_reg
evaluation yes
cdc_sync
on
two_dff
evaluation yes
cdc_sync
on
caution
yes
cdc_hamming_distance_one off
dmux
caution
yes
cdc_dsel
on
fifo
caution
no
none
off
handshake
caution
no
none
off
multi_bits
caution
yes
cdc_sample
on
series_redundant
caution
yes
none
off
simple_dmux
caution
yes
cdc_dsel
on
two_dff_phase
caution
yes
cdc_sync
on
async_reset_no_sync
violation yes
none
off
bus_two_dff_phase
violation yes
bus_four_latch
violation yes
bus_two_dff
violation yes
combo_logic
violation yes
cdc_glitch
on
no_sync
violation yes
cdc_sample
on
bus_shift_reg
violation yes
violation yes
cdc_sample
on
violation yes
cdc_glitch
on
reconvergence
violation yes depth:0 none
off
redundant
violation yes
none
off
single_source_reconvergence violation yes
none
off
474

October 2011
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
Symbols
+define+, 339
+error, 368
+incdir+, 340
+libext, 340
+nowarn, 368
+skip_syscall, 70
Numerics
0-In comments, 254
definition, 254
single-line, 254
0in.log, 374
0in_cdc.db, 374
0in_db2ucdb, 357
0in_detail.log, 374
1-Step compilation, 56
2-Step compilation, 57
A
abstract memory model, 310
ad hoc synchronizer, 31
-allow_enable_in_sync, 289
Altera, 63
ANSI port declaration, 339
assertion defined, 47
assertion-based verification, 47
-assume, 410
Assumption groups
data, 402
deq, 391
dist, 396
enq, 391
max, 402
min, 402
ptr, 391
rptr, 391
rxdata, 386
rxdone, 402
rxval, 402

October 2011
stable, 396
txdata, 386
txdone, 402
txdsel, 386
txval, 402
wptr, 391
async_reset scheme, 181
async_reset_no_sync scheme, 184
asynchronous
clocks, 25
inputs, 25
no synchronizer, 469
reset detection, 467
reset signals, 469
reset synchronizers, 468
reset with missing synchronizer, 468
user-entered reset, 468
wrong clock, 469
wrong reset polarity, 469
-auto_black_box, 369
B
Black box, 70
black_box scheme, 186
-black_box_empty_module, 288
Block constraints generation mode, 118
Block specifications, 119
Bookmarks, 440
bus_dff_sync_gated_clk scheme, 191
bus_four_latch scheme, 193
bus_shift_reg scheme, 195
bus_two_dff scheme, 197
bus_two_dff_phase scheme, 199
C
cache, 366
Case directive, non-native, 326
CDC
cautions report, 463
evaluation report, 464, 465, 466
475
filtered crossings, 367
promotion, 104
promotion summary report, 462
scheme types, 39
scheme, turn off reporting, 40
schemes, 39, 179
schemes with potential errors, 44
summary report, 462
violation report, 463
CDC checks window, 427
cdc command, 364
cdc input files, 373
CDC port constraint, 276
cdc_dsel, 385
cdc_fifo, 389
cdc_glitch, 393
cdc_hamming_distance_one, 395
-cdc_handshake, 399
cdc_handshake_data, 398
cdc_sample, 406
cdc_sync, 409, 412, 416
CDC-FX
cdc_fx checker, 175
metastability injected simulation, 29
Checker
promotion, 48
checker
cdc_fx, 159
promotion, 40
protocol, 47
simulate a design, 50
Checker summary, 290
Checker types
cdc_dsel, 385
cdc_fifo, 389
cdc_glitch, 393
cdc_hamming_distance_one, 395
cdc_handshake_data, 398
cdc_sample, 406
cdc_sync, 409, 412, 416
CheckerWare assertion library, 48
clock
asynchronous, 25
domain crossing, 26
domains, 25
476
group, 25
group inferred by compiler, 455
group summary, 454
jitter, 28
user-specified clock group, 455
clock domain
crossing report file, 461
-clock_as_rx, 286
-clock_group_pair, 276
-clock_in_data, 286
Clocks, 25
Clocks window, 451
cmd, 352
combo_logic scheme, 201
commands
ccl, 379
Configure columns buttons, 421
Consistency checks, 122
Control file models, 130
control signal synchronizers, 31
Corner cases
all one, 407
all one to zero, 407
all zero, 407
all zero to one, 407
asserted for tx_min cycles, 387
FIFO is empty, 391
FIFO is full, 391
turnaround cycles completed at
turnaround_max, 403
turnaround cycles completed at
turnaround_min, 403
value changed at tx_min, 396, 410
counterexample, 49
Coverage count, 361
cuname, 366
Current layout, 425
-custom_fx, 287
custom_sync scheme, 189, 203, 205
cwhelp, 381
D
data
synchronization, 42, 43
Data sheets, checkers, 383
-data_stable, 399
October 2011
de, 368
Defaults file, 58
-delayed_pulse, 289
-depth, 389
Depth of divergence, 37
Depth of reconvergence, 37
-deq, 389
-dequeue, 390, 409
design
detailed information, 458
general information, 457
Design window, 449
DesignWare, 355, 370
detail, 351
Details window, 430
-detect_primary_output_clock, 286
dff_sync_gated_clk scheme, 207
Directive order, 259
Directives
non-native case, 326
Directives window, 452
Divergence depth, 37
Dividers, 444
dmux scheme, 208, 244
-dmux_as_recon_start, 288
-dmux_promote_sample, 288, 289
Dock button, 424
Drag-and-drop, 420
dw, 355, 370
E
Empty modules, 288
-enq, 389
-enqueue, 390, 410
Errors/Warnings window, 426
Evals, 383
Evaluation statistic, 383
exact memory model, 310
Expansion, 257
F
Failure count, 361
fanin_different_clks scheme, 210
-fifo_scheme, 287
files
0in_cdc_design.rpt, 454
October 2011
automatically generated, 453

design report, 454
filtered
CDC crossings, 367
-filtered_report, 290
Filtering CDC results, 100
Find panel, 448
formal
constraint, 49
target, 49
tools, 49
verification, 49
Formal block restrictions, 70
Formal CDC, 46
Formal CDC effort level, 46
-formal_add_bus_stability, 289
-formal_add_recon_stability, 289
four_latch scheme, 218
FPGA resource libraries, 63
Functions, 74
G
G, 368
g, 369
-glitch, 393
Global CDC preferences, 118
global directives
create_wire, 317
disable_checker, 320
set_cdc_port_domain, 282
set_cdc_preference, 290
set_cdc_reconvergence, 295
set_cdc_report, 299, 300
set_cdc_signal, 302
set_cdc_synchronizer, 305
set_checker_action, 324
set_constant_propagation, 308
set_memory, 310
set_mode, 312
set_mode_control, 313
wildcarded signals, 367
Global reconvergence, 35
Gray-coding protocol, 47
H
-hamming_one, 395
477
-handshake_scheme, 287
Hierarchical constraints control file, 118
hierarchical verification
use model, 117
-hold, 407
Homogeneous instances of a block, 128
Hover help, 420
I
-ignore_black_box, 288
Inconclusive, 46
Inferred black box, 70
InfoHub, 21
-input_async, 289
J
jitter, 28
L
l, 351
L/-Lf, 336, 366
lib2v, 379
Liberty technology library, 379
libmapfile, 336, 339
library cells, 379
Library section, 61
-licq, 351
limit_messages, 351
Local reconvergence, 35
-locklib, 328, 329
-loop_no_latch, 262
M
-max_cdc_crossings number, 290
mean-time-between-failure, 26
memory_sync scheme, 223
metastability
cdc_fx checker, 159
fence logic, 30
in hardware, 26
in RTL simulation, 27
injection, 159
metastable flip-flops, 26
registers, 26
windows, 160
modal analysis
capabilities, 132
478
mode
report information, 459
modelsim.ini, 58, 61
modelsimini, 332, 336, 365
Modules window, 450
Move-window button
Buttons
Move-window, 423
MTBF, 26
-mult_fanout_async, 289
multi_bits scheme, 225
-multi_clock_convergence, 288
multi_sync_mux_select scheme, 227
Multibit reconvergence, 35
Multicycle reconvergence, 36
Multiple always blocks, 74
Multiple directives, 254
N
netlist analysis, 45
nl, 351
no_sync scheme, 229, 231
Non-native case directives, 326
O
Objects window, 431
od, 351
out-of-band signals, 30
override_on/override_off, 71
P
Parser directives, 71
Pass count, 361
Path ID, 49
PLI
function calls, 171
Popup menus, 419
port
domain information, 458
Port constraints, 276
-ports, 276
Pragmas, 71
-print_detailed_custom_sync, 287
-print_port_domain_template, 290
Project mode, 91
Project window, 448

October 2011
-promote_reconvergence, 287, 288
Promoted checkers, 48
promotion, 40
pulse_sync scheme, 233
Q
question mark (?) wildcard, 313
R
-rd_ptr, 390
-rd_ptr_check, 390
reconvergence
defined, 35
scheme, 235, 246
Reconvergence depth, 37
redundant scheme, 238, 240
-registered, 410
rel_paths, 351
Report clocks, 93
-report_black_box_recon, 288
Resource libraries, 60
-restore_state, 353
Restrictions
formal block, 70
-rx_clock, 385, 390, 399, 406
-rx_clock_group, 276
-rx_data_select, 386
-rx_data_stable, 386
-rx_done, 402
-rx_done_assert_until_rx_valid_deassert, 401
-rx_min, 401
-rx_reset, 385, 390, 399, 406
-rx_valid, 402
-rx_valid_assert_until_rx_done_assert, 400
-rx_var, 406
S
-sample_data_stability, 288
Saving the current layout, 425
schemes
async_reset, 181
async_reset_no_sync, 184
black_box, 186
bus_dff_sync_gated_clk, 191
bus_four_latch, 193
bus_shift_reg, 195

October 2011
bus_two_dff, 197
bus_two_dff_phase, 199
CDC, 39
combo_logic, 201
custom_sync, 189, 203, 205
dff_sync_gated_clk, 207
dmux, 208, 244
fanin_different_clks, 210
four_latch, 218
memory_sync, 223
multi_bits, 225
multi_sync_mux_select, 227
no_sync, 229, 231
potential problems, 44
pulse_sync, 233
reconvergence, 235, 246
redundant, 238, 240
shift_reg, 242
two_dff, 251
two_dff_phase, 253
set_black_box, 70
set_constant_propagation, 308
set_memory, 310
-setup, 407
severity level
caution, 39
evaluation, 40
violation, 39
waived, 40
shift_reg scheme, 242
Signal dividers, 444
Signal stability protocol, 46
signals
out-of-band, 30
transmitting, 470
sim, 351
simulation
checkers in simulation, 50
transfer protocol, 30
Single-source reconvergence, 37, 246
Skipping modules, 70
specifying design intent, 47
stability protocol, 46
-stable, 409
Standard options
479
definition, 383
Static formal analysis, 91
Statistics
current FIFO entries, 391
cycles checked (evals), 394
dequeues, 391
enqueues, 391
enqueues and dequeues (evals), 391
longest assertion, 387
longest stable time, 396, 410
maximum FIFO entries, 391
maximum turnaround cycles, 403
minimum turnaround cycles, 403
one to zero transition bitmap, 408
sample one bitmap, 407
sample zero bitmap, 407
shortest assertion, 387
shortest stable time, 396, 410
total turnaround cycles, 403
total tx_valid, 403
transfers checked, 387
values checked enqueues and dequeues
(Evals), 410
values checked enqueues and dequeues
(evals), 396
values sampled (evals), 407
zero to one transition bitmap, 408
Status flags, 53
Stretch-shrink bars, 423
structured synchronizers, 31
Stub modules, 288
synchronization
custom modules, 467
data, 42, 43
scheme, 30, 48
synchronizer
ad hoc, 31
asynchronous reset, 468
block diagram, 30
control signal, 31
structured, 31
synthesis_off/synthesis_on, 71
T
Target design, 153
Tasks, 74
480
transfer protocol, 30
translate_off regions, 71
transmitting signals, 470
-turnaround_max, 401
-turnaround_min, 401
two_dff scheme, 251
two_dff_phase scheme, 253
-tx_clock, 385, 390, 395, 399, 406, 409
-tx_clock_group, 276
-tx_data, 385, 399, 409
-tx_data_select, 386
-tx_data_stable, 386
-tx_done, 402
-tx_done_assert_until_tx_valid_deassert, 400
-tx_min, 386, 396, 401
-tx_min_check, 386
-tx_reset, 385, 390, 395, 399, 406, 409
-tx_valid, 399
-tx_valid_assert_until_tx_done_assert, 400
-tx_valid_deassert_until_tx_done_deassert,
400
-tx_var, 395, 406, 409
U
Undock button, 424
Unresolved modules, 369
Unsynthesizable code, 73
Unzoom button, 423
-used, 393
V
v, 340, 341
-var, 393
-vectorize_nl, 289
verification
formal, 49
version, 351
vhctrl, 366
W
Waiver file, 126
Wave view
Bookmarks, 440
wd, 351
Wildcards
Directive order, 259

October 2011
Patterns, 257
wildcards
in variables and wire names, 297
question mark(?), 313
with global directives, 267, 302, 367
Windows
CDC checks, 427
Clocks, 451
Design, 449
Details, 430
Directives, 452
Errors/Warnings, 426
Modules, 450
objects, 431
Project, 448
work, 365
-wr_ptr, 390
-wr_ptr_check, 390
X
Xilinx, 63
Y
y, 340
Z
Zoom button, 423

October 2011
481
482

October 2011
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 dArtois.
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
CUSTOMERS 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, Customers 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 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 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 Customers sole responsibility. If Customer appoints a third
party to place purchase orders and/or make payments on Customers 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 2000), 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 Customers 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 Customers 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 requests any change or enhancement to Software, whether in the course of
receiving support or consulting services, evaluating Software, 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 Customers compiled computer program,
provided that Customer distributes these files only in conjunction with Customers 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 Customers 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 (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 Customers 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 Customers
use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customers 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 Customers 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 Customers 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 it 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 learns or 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 Customers employees or
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 Customers
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 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.
AUTOMATIC CHECK FOR UPDATES; PRIVACY. Technological measures in Software may communicate with servers
of Mentor Graphics or its contractors for the purpose of checking for and notifying the user of updates and to ensure that the
Software in use is licensed in compliance with this Agreement. Mentor Graphics will not collect any personally identifiable data
in this process and will not disclose any data collected to any third party without the prior written consent of Customer, except to
Mentor Graphics outside attorneys or as may be required by a court of competent jurisdiction.
8.
LIMITED WARRANTY.
8.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 Customers 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 or improper installation. MENTOR GRAPHICS ENTIRE LIABILITY AND CUSTOMERS
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, PROVIDED
CUSTOMER HAS OTHERWISE COMPLIED WITH THIS AGREEMENT. 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.
8.2. THE WARRANTIES SET FORTH IN THIS SECTION 8 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.
9.
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 9 SHALL
SURVIVE THE TERMINATION OF THIS AGREEMENT.
10. 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). NEITHER MENTOR GRAPHICS
NOR ITS LICENSORS SHALL 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 10 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
11. 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 PRODUCTS AS DESCRIBED IN
SECTION 10. THE PROVISIONS OF THIS SECTION 11 SHALL SURVIVE THE TERMINATION OF THIS
AGREEMENT.
12. INFRINGEMENT.
12.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 the 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.
12.2. If a claim is made under Subsection 12.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.
12.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.
12.4. THIS SECTION 12 IS SUBJECT TO SECTION 9 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS FOR DEFENSE, SETTLEMENT AND DAMAGES, AND CUSTOMERS SOLE
AND EXCLUSIVE REMEDY, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
13. TERMINATION AND EFFECT OF TERMINATION. If a Software license was provided for limited term use, such license
will automatically terminate at the end of the authorized term.
13.1. 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 Customers obligation to pay for Products shipped or
licenses granted prior to the termination, which amounts shall be payable immediately upon the date of termination.
13.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 Customers 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.
14. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States government agencies,
which prohibit export or diversion of certain products and information about the products to certain countries and certain
persons. Customer agrees that it will not export Products in any manner without first obtaining all necessary approval from
appropriate local and United States government agencies.
15. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. All Software is commercial
computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to US 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, except for provisions which
are contrary to applicable mandatory federal laws.
16. 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.
17. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and
during Customers normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to
review Customers software monitoring system and records deemed relevant by the internationally recognized accounting firm
to confirm Customers compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include
FLEXlm or 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 17
shall survive the termination of this Agreement.
18. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics
intellectual property licensed under this Agreement are located in Ireland and the United States. 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, USA, 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. This section shall not
restrict Mentor Graphics right to bring an action against Customer in the jurisdiction where Customers place of business is
located. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
19. 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.
20. MISCELLANEOUS. This Agreement contains the parties entire understanding relating to its subject matter and supersedes all
prior or contemporaneous agreements, including but not limited to any purchase order terms and conditions. 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 by authorized
representatives of the parties. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent
consent, waiver or excuse.
Rev. 100615, Part No. 246066

CDC User

Uploaded by

Copyright:

Available Formats

CDC User

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CDC User

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What rights does Mentor Graphics reserve regarding the content?

What rights does Mentor Graphics reserve regarding the content?

Questa CDC

1995-2011 Mentor Graphics Corporation

Questa CDC User Guide, v10.0c_2

Step 1: Compile and Maintain Design Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Questa CDC User Guide, v10.0c_2

CDC Analysis of FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Loading Waveforms and Waveform Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Questa CDC User Guide, v10.0c_2

All Transmitting Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Figure 5-4. Metastability Window Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Questa CDC/Formal Verification Manuals

Questa CDC/Formal Release Highlights New features; user-visible changes;

Quick Start Guides

Questa CDC/Formal Quick Reference Syntaxes of commands and directives for

Questa CDC/Formal Messages Quick reference for messages issued by the

In syntax statements: oblique font

In text: oblique font indicates:

Specify the black box

Angle brackets are used in

Questa CDC User Guide, v10.0c_2

Ellipses indicate a repeatable entry.

Square brackets indicate an optional

Braces indicate a required entry

Or-bars separate choices in [ ] and { } [-87|-93|-2002|-2008]

An argument variable with a _pattern

set_constant var_pattern constant

Single-bit register or wire.

Expression that can change value at any time.

Expression that evaluates to a statically constant value.

String enclosed in double-quotes.

Questa CDC User Guide, v10.0c_2

0in shell help

Questa CDC User Guide, v10.0c_2

Specify cwhelp with no arguments to list the available directives:

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

Mentor Graphics Support

Questa CDC User Guide, v10.0c_2

Questa CDC User Guide, v10.0c_2

CDC Design Issues

Static CDC analysis with the CDC compiler.

Assertion-based verification with CDC protocol checkers.

Metastability effects analysis with CDC-FX metastability injected simulation.

Questa CDC User Guide, v10.0c_2

Single Clock Domain

Multiple Clock Domains