jasperCDC

JasperGold Clock Domain Crossing
Verification App User Guide

Product Version 2019.09
September 2019
© 2019 Cadence Design Systems, Inc. All rights reserved.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Product JasperGold Apps incorporates software developed by others and redistributed according to license
agreement. For further details, see doc/third_party_readme.txt.
Trademarks: Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are
trademarks or registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries
and are used with permission.
Firefox is a registered trademark of the Mozilla Foundation.
Liberty™ is a trademarks of Synopsys®, Inc. in the U.S. and/or other countries.

Trademarks and service marks of Cadence Design Systems, Inc. contained in this document are attributed to
Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal
department at the address shown above or call 800.862.4522. All other trademarks are the property of their
respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and contains
trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or distribution of this
publication, or any portion of it, may result in civil and criminal penalties. Except as specified in this permission
statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted,
or distributed in any way, without prior written permission from Cadence. Unless otherwise agreed to by
Cadence in writing, this statement grants Cadence customers permission to print one (1) hard copy of this
publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright, trademark,
and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs
of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in
FAR52.227-14 and DFAR252.227-7013 et seq. or its successor
JasperGold Clock Domain Crossing Verification App User Guide
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Who Should Read this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
How This Guide Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Related References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Conventions Used in JasperGold Apps Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1
CDC Concepts and GUI Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Synchronizer Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Automatically-Detected Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
User-Defined Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Heuristic Scheme Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Standard and Direct Reset Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CDC Verification Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
CDC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Reset Order Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Structural Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Functional Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Metastability Modeling and Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Reset Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CDC App GUI Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2
General Flow and Key Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
General CDC App Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CDC App Key Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
September 2019 3 Product Version 2019.09

Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Checks Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Clock Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Rule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Structural Analysis (Pairs, Scheme, Convergence, and Reset) . . . . . . . . . . . . . . . . . 57
Functional Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Metastability Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Filtering Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Waiving Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CDC Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
CDC Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Bottom-Up Hierarchical CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Reporting Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Listing Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Saving and Restoring a CDC Analysis Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Reading an SDC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3
GUI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
CDC App Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CDC App Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Identifying Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Resolving Problems with Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
CDC Phases Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Pairs and Schemes Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Convergence Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Functional Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Metastability Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Waiving Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Waiving Single Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Waiving Groups of Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Waiving Structural Violations by Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Specifying Conditional Waivers by Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Specifying Conditional Waivers by Violation Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Automatic Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Integrated Debugging Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4
User-Defined and Custom Synchronizer Schemes . . . . . . . . . 134
User-Defined and Custom Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Module-Based Versus Instance-Based Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 135
CDC Pairs Covered by User-Defined and Custom Synchronizers . . . . . . . . . . . . . . 136
Generation of Functional Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Adding User-Defined Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding a Module-Based User-Defined Synchronizer Using the GUI . . . . . . . . . . . . 137
Adding a User-Defined Synchronizer from the Command Line . . . . . . . . . . . . . . . . 139
Creating Custom Schemes and Protocol Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5
CDC App Path Rule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
CDC Path Rules Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Modifying Path Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
CDC Path Rule (Pair and Scheme) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
CDC Pair Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
CDC Pair Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Minimum and Maximum DFFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Synchronization Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Same Clock Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Synchronization Path Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Convergence and Reconvergence Rules (Group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Source Unit Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Source Unit Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
MUX Convergence Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Convergence Inside Control Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reset Rules (Reset) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Reset Minimum DFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Reset Synchronization Chain Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Reset Same Clock Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Reset Pair Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Configuration Rules (Config) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Multi-Mode Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Apply Auto Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
FIFO Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Handshake Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
NDFF Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
NDFF_BUS Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
MUX_NDFF Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Pulse Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
MUX_PULSE Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Automatic Scheme Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Automatic Black Box Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Treat Boundaries as Unclocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Strict NDFF Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Strict MUX Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Redundant Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Reset Redundant Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Bus Convergence Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Reset Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Clock Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Clock Selector Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Inactive CDC Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Inactive Reset Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Direct Reset Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Automatically Waive RDC with NDFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Automatically Waive Reset Clamp Pair Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Automatically Waive Reset Clear Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Ignore Non-Resettable Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Synchronize Clocks in Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Show Expanded Clock Crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Non-Blocking Reset Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Use SDC Clock Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Add Stopat for Internal Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Use RTL Constants Only for Glitch Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6
CDC App Functional Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Protocol Check Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
NDFF Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
NDFF_BUS Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Pulse Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
MUX_NDFF Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
MUX_PULSE Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Handshake Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Handshake Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
FIFO Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Glitch Protector Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7
Debugging CDC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
CDC Violations Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Structural Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Functional Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Metastability Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Reset Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
CDC Debugging Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Debugging Structural Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Debugging Structural Violations with More than One Associated CDC Pair . . . . . . 205
Debugging Functional Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Debugging Metastability Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Addressing CDC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Configuration-Related Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Signal Configuration Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Pair Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Scheme Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Convergence Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Reset Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Full List of Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Preface
The JasperGold® Clock Domain Crossing Verification (CDC) App provides formal and
simulation-based solutions that enable comprehensive CDC sign-off. The CDC App manages
clock complexity by automatically inferring clock domain crossing intent from the design and
comprehensively analyzing structural, functional, and reconvergence issues. It also provides
an integrated debugging environment with access to advanced debugging options, including
schematics, graphs, and waveform analysis with Visualize™.
This guide provides setup and flow information to help you successfully integrate CDC sign-
off in your verification efforts. This chapter includes the following sections:
■ Who Should Read this Guide on page 10
■ How This Guide Is Organized on page 10
■ Related References on page 11
■ Conventions Used in JasperGold Apps Documents on page 12
Cadence® Design Systems, Inc. prohibits the use of our software in a way that
does not comply with our written guidelines and documentation.

Preface
Who Should Read this Guide

This guide is intended for verification engineers who need to exhaustively verify clock domain
crossing.
How This Guide Is Organized

This guide is organized as follows:
■ Preface
Describes the purpose and scope of this guide, includes a preview of its contents, and
lists typographic conventions.
■ Chapter 1, “CDC Concepts and GUI Orientation”
Introduces common synchronizer schemes, CDC verification phases, and the CDC App
GUI.
■ Chapter 2, “General Flow and Key Commands”
Introduces the CDC App general use flow and key commands.
■ Chapter 3, “GUI Features”
Describes key CDC App GUI features.
■ Chapter 4, “User-Defined and Custom Synchronizer Schemes”
Describes user-defined and custom schemes and provides examples.
■ Chapter 5, “CDC App Path Rule Configuration”
Provides information on the CDC App rule set, the default values for each rule, and
command examples for changing the default behavior.
■ Chapter 6, “CDC App Functional Checks”
Provides information on CDC App functional checks and property templates.
■ Chapter 7, “Debugging CDC Violations”
Provides a standalone overview of the debugging environment, specifics regarding the
consequences of ignoring violations, and actions you might take to address CDC
violations.

Preface
Related References
To learn more about CDC App commands, refer to the check_cdc command help (type
help check_cdc -gui in the session) or access the JasperGold Apps Command
Reference Manual from the Help menu.
To learn more about the JasperGold Apps platform, access the JasperGold Platform and
Formal Property Verification App User Guide (Help – User Guide).

Preface
Conventions Used in JasperGold Apps Documents

The following tables list conventions used in syntax and text.
Table 1-1 JasperGold Apps Syntax Conventions
Convention Definition
Courier font Indicates text you will type on the command line.
-underscore_separation
Indicates a command switch.
Switches are not case-sensitive.
[ ] Indicates optional arguments.
Do not type the square brackets.
| Indicates a choice (a logical OR) among alternatives.
Do not type the vertical bar.
\ The backslash character (\) at the end of a line indicates that the
command you are entering continues on the next line.
* Indicates the preceding argument appears zero or more times per
command.
+ Indicates the preceding argument appears one or more times per
command.
‘’ Indicates the enclosed character(s) should be explicitly included on
the command line.
Do not type the single quotation marks.
<Italics> Indicates a command option that you will replace with a valid value.
Do not type the angle brackets.
( ) Used as a grouping convention.
Do not type the parentheses.
For example, parentheses in the following syntax indicate that if you
use the -bbox option, you will follow it with either the 0 or 1.
[-bbox ( 0 | 1 )]

Preface
Table 1-2 JasperGold Apps Text Conventions
Convention Definition
Courier font This style indicates:
■ Text you will type in GUI fields
■ Commands and options
■ Filenames and paths
■ Code samples
Italics User interface items such as button and field names.
Menu – Option GUI command sequence; that is, click on a menu followed by an
option.
Example: Help – Command Reference Manual
Meaning: Click on the Help menu and choose the option Command
Reference Manual.
Blue text Hyperlinked cross-reference.
When you view the PDF version of JasperGold manuals from a
computer screen, click on the blue text to view related information.
➡ Single-step procedure.

1
CDC Concepts and GUI Orientation
Clock domain crossing occurs when a signal crosses from one asynchronous clock domain
to another. Due to the non-deterministic relationship between these clocks, they will
continuously skew causing setup and hold violations. When setup and hold conditions are
violated, the output of a flip-flop becomes unstable, and after an unpredictable delay, the
value of the flip-flop may settle either way (1 or 0). This phenomenon is called metastability,
and while you cannot prevent metastability in asynchronous designs, you can use
synchronizers to prevent the forward propagation of metastable values, data loss or
corruption caused by metastability, and data coherency issues related to reconvergence.
This chapter briefly describes the synchronizer schemes most commonly used to mitigate the
challenges associated with metastability, introduces CDC verification phases, and provides
an overview of the CDC App GUI. It includes the following sections:
■ Synchronizer Schemes on page 15
■ CDC Verification Phases on page 30
■ CDC App GUI Orientation on page 41
Important
At various points, this user guide references CDC units. Units are always a design
element, that is, flops, top inputs and outputs, black-boxed inputs and outputs, and
signals with stopats.

Synchronizer Schemes
The tool supports ten pre-defined synchronizer schemes. Eight of these, including NDFF,
NDFF_BUS, MUX_NDFF, MUX_PULSE, handshake, FIFO, pulse, and edge, can be
automatically identified by the tool or defined by the user. Two others, glitch protector and
synchronization enabler, are strictly user-defined.
The tool supports user-defined schemes for those instances where it cannot automatically
identify a predefined scheme and custom schemes for those instances where the design
uses synchronizer cells that do not map to any of the predefined types. Use check_cdc
-scheme -add to add user-defined or custom schemes.
Note: Chapter 4, “User-Defined and Custom Synchronizer Schemes” details procedures for
adding user-defined and custom schemes.
Two additional schemes include 1) heuristic scheme detection, which uses heuristic
algorithms to find synchronizers for additional CDC pairs, and 2) reset synchronizers, which
are relevant to the reset phase only and can be automatically detected with the check_cdc
-reset -find command.
This section briefly summarizes automatically-detected and user-defined schemes and

provides information on the parameters required to add user-defined schemes. It also
introduces heuristic scheme detection and reset synchronizers. It includes the following
sections:
■ Automatically-Detected Schemes on page 15
■ User-Defined Schemes on page 23
■ Heuristic Scheme Detection on page 27
■ Standard and Direct Reset Synchronizers on page 28
Automatically-Detected Schemes
In most cases, the tool automatically identifies the following synchronizer schemes:
■ NDFF
■ NDFF_BUS
■ MUX_NDFF
■ MUX_PULSE
■ Handshake

■ FIFO
■ Pulse
■ Edge
If the tool cannot automatically identify one of these, you can add a user-defined scheme of
a specified type by providing the required parameters as discussed below.
NDFF
NDFF synchronizers check single-bit crossovers like control paths. The simplest NDFF
synchronizers use 2 DFFs, but you can add more flops to increase the mean time between
failure (MTBF).
To add an NDFF synchronizer, you must supply the mandatory parameters data and dout.
You might also need to supply the drst and dclk signals if the tool cannot infer them (see
Figure 1-1 on page 16).
Figure 1-1 NDFF Template
NDFF_BUS
Use NDFF_BUS schemes to synchronize a wide signal from the source domain to the
destination domain. To add an NDFF_BUS synchronizer, you must supply the mandatory
parameters data and dout. You might also need to supply the drst and dclk signals if the
tool cannot infer them.

MUX_NDFF and MUX_PULSE
MUX synchronizers are typically used for data paths. Open-loop synchronization ensures that
data is captured without acknowledgment and when the MUX enable is active. MUX schemes
use a synchronized control signal as the select line of the MUX. The MUX_NDFF scheme
uses an NDFF to synchronize the control signal and the MUX_PULSE scheme uses a pulse
to synchronize the control signal. This control signal can be the selector pin of a MUX gate or
can be the enable condition of a clock gating as shown in Figure 1-2 on page 18 and Figure 1-
3 on page 19.
To add a MUX_NDFF synchronizer, you must supply the mandatory parameters data, dout,
sready, and dready. To add a MUX_PULSE synchronizer you must add all of these as well
as the enable parameter. You might also need to supply the drst and dclk signals if the
tool cannot infer them (see Figure 1-2 on page 18 and Figure 1-3 on page 19).

Figure 1-2 MUX_NDFF Templates

Figure 1-3 MUX_PULSE Templates
Handshake
Handshake synchronization is a closed-loop synchronization method that requires

acknowledgment of receipt of the signal that crosses the CDC boundary. With this type of
synchronization, the source and destination modules use a simple request-acknowledgment
protocol.
To add a handshake synchronizer, you must supply the following mandatory parameters:
data, sreq, dack, dreq, and sack. You might also need to supply the following signals if
the tool cannot infer them: dCtrl, sCtrl, srst, sclk, drst, and dclk (see Figure 1-4 on
page 20).

Figure 1-4 Handshake Template
FIFO
FIFO synchronizers are used to transfer data from faster to slower clock domains. Data is
written into the FIFO from the source clock domain, which never writes when the FIFO is full,
and read from the FIFO in the destination clock domain, which never reads when the FIFO is
empty. The gray-coded read and write pointers are passed to the alternate clock domain to
generate full and empty status flags.
To add a FIFO synchronizer, you must supply the following mandatory parameters: rdata,
wptr, rptr, wfull, rempty, winc, rinc, and wdata. You might also need to supply the
srst, sclk, drst, and dclk signals if the tool cannot infer them (see Figure 1-5 on
page 21).

Figure 1-5 FIFO Template
Pulse
Pulse synchronizers are used to synchronize pulses entering the destination clock domain
from the source clock domain. The basic function of a pulse synchronizer is to take a single
clock-wide pulse from the source clock domain and create a single clock-wide pulse in the
destination domain.
To add a pulse synchronizer, you must supply the mandatory parameters data, dout, and
enable. You might also need to supply the srst, sclk, drst, and dclk signals if the tool
cannot infer them (see Figure 1-6 on page 22).

Figure 1-6 Pulse Template
Edge
Edge synchronizers detect the rising or falling edge of the input and generate a one-clock-
cycle-wide active high or active low pulse to the output. Mandatory parameters for edge
synchronizers include data, dout, activity (high | low), and sensitivity
(rising | falling). See Figure 1-7 on page 22, Figure 1-8 on page 23, Figure 1-9 on
page 23, and Figure 1-10 on page 23.
Figure 1-7 Rising Edge Active High Template

Figure 1-8 Rising Edge Active Low Template
Figure 1-9 Falling Edge Active High
Figure 1-10 Falling Edge Active Low
User-Defined Schemes
This section describes glitch protector, synchronization enabler, and reset schemes and the
parameters you must include to add one of these synchronizer types.

Glitch Protector
Use glitch protector schemes to add a custom module that acts as a control-based
synchronizer. Mandatory parameters for glitch protector synchronizers include dout only.
You might also need to supply the GPData and control signals if the tool cannot infer them.
For example, you might specify the glitch protector with the following command:
check_cdc –scheme –add glitch_protector –module <module_name> -map

{{Dout dout} {GPData data} {Control en}}
You must provide the glitch protector module name before automatic scheme detection. See
Figure 1-11 on page 25.
The tool detects a glitch protector scheme only when at least one unit connected to the control
input is the output of a control synchronizer. After a glitch protector synchronizer has been
added, no cdc_pair_fanout or cdc_pair_logic violations are reported for the pairs
related to that synchronizer.
Note:
■ If the source domain of the control is not synchronized with the source domain of the
data, the tool generates an async_inputs violation.
■ If CDC units connected to control en are not synchronized with the destination, the
tool generates an async_outputs violation.
■ Starting with the 2019.06 release, you can define specific instances of a glitch protector
module as a valid synchronizer scheme as follows:
check_cdc -scheme -add glitch_protector -map {{Dout
top.gp_inst1.gpout} {GPData top.gp_inst1.data1} {Control
top.gp_inst1.dready}}

Figure 1-11 Glitch Protector Synchronizer
Synchronization Enabler
Use the synchronization enabler scheme to synchronize a data path between one or more
source domains and a specified destination domain. With this scheme, you inform the tool of
the signal that controls the data going from one or more domains to another.
To add the synchronization enabler, you must supply the following mandatory parameters:
enable, (srcdomain or srcdomainlist), and dstdomain (see Figure 1-12 on page 26).
Before running check_cdc –scheme –find, add an instance-based scheme for a
particular combination of source domain(s), destination domain, and enable signal as follows:
check_cdc –scheme –add sync_enabler –map {{enable <enable_signal>}

{srcdomain <source_domain> | srcdomainlist <source_domain_list> }
{dstdomain <destination_domain>}}
When you run check_cdc –scheme –find, the tool processes all the synchronization
enabler schemes after every other type of supported scheme and considers any remaining
uncovered data pairs from the source domain(s) to the destination domain covered if they are
controlled by the specified enable signal. The tool shows these pairs as Passed without any
associated violation even if they have a cdc_pair_logic violation. Conversely, invalid
synchronization enabler schemes fail with a valid_sync_enabler or no_scheme
violation.
Note:
■ The tool assigns the destination unit name to sync_enabler schemes.

■ The tool validates the enable signal during the detection phase and not during the
specification phase.
Figure 1-12 Synchronization Enabler
Reset
Use the reset scheme to synchronize a reset signal's de-assertion to a specific clock.
Mandatory parameters for reset synchronizers include srst (the input reset to be
synchronized), dclk (the clock to which the reset de-assertion is synchronized), and dout
(the synchronized output reset).
Note: The tool assumes the signal at the dout port to be asynchronously asserted and
synchronously de-asserted, as is the case with the standard reset synchronizer automatically
detected by the tool (see Figure 1-14 on page 29). However, the tool does not verify whether
the internal structure of the module guarantees the previous assumption.
To add a module-based reset synchronizer, use the following command before running
check_cdc -scheme -find:
check_cdc -scheme -add reset -module <module_name> -map {{Srst

<input_reset>} {Dclk <clock>} {Dout <output_reset>}}
Then, after running check_cdc -reset -find, the tool identifies any instance of -module
<module_name> as a standard reset synchronizer.

Heuristic Scheme Detection

The CDC App includes an aggressive option that uses heuristic algorithms to find
synchronizers for the CDC pairs that remain uncovered after the default analysis. The main
goal of the heuristic approach is to reduce noise in CDC analysis by removing possible false
violations.
Use the following command to run aggressive scheme detection:
check_cdc –scheme –find –aggressive
All synchronizers the tool detects with the heuristic approach will have a potential_ prefix
so you can easily identify them. The tool does not automatically generate any kind of protocol
check for the synchronizers detected using this approach, so reviewing all synchronizers is
advised.
Aggressive Detection of Sync Enablers
In addition to finding potential_sync_enabler schemes, with aggressive

sync_enabler detection, the tool uses a more generic algorithm to look for structurally valid
user-defined sync_enabler schemes.
User-Defined Sync Enablers
With aggressive sync_enabler detection, for each user-defined sync_enabler scheme,

the tool explores the fanin cone of the provided sync enabler signal until it reaches a boundary
defined by one or more of the following elements:
1. Constant or static CDC units
2. CDC units in a clock domain different from the specified destination domain
3. CDC units known as the output of control synchronizers from any of the specified source
domains into the destination domain
4. Externally synchronized port associated with the destination domain
Note:
■ The presence of an element of the second type automatically renders the sync enabler
scheme structurally invalid.
■ For the third element type above, at least one synchronizer from each source domain into
the destination domain must be found for the sync enabler to be structurally valid.

Automatic (Potential) Sync Enablers
With aggressive sync_enabler detection, CDC automatically looks for

potential_sync_enabler schemes, which adhere to the following pattern (see Figure 1-
13 on page 28):
1. There must be at least one signal connected to the logic between the source and the
destination that is an output of a control synchronizer.
2. Any potential sync enabler the tool finds covers only CDC pairs from source domains for
which a control synchronizer is found in the fanin of the potential sync enabler signal. If
no CDC pairs are covered by a potential sync enabler, the tool does not add the scheme.
Figure 1-13 Heuristic Sync Enabler Detection
Standard and Direct Reset Synchronizers

In standard reset synchronization, the reset assertion is asynchronous to the clock, but when
the reset signal is de-asserted, it happens synchronously with the synchronizer clock. Thus,
when reset is asserted, the output of the reset synchronizer assumes the reset value
asynchronously, reseting the target flops. When the reset is de-asserted, the output of the
synchronizer assumes the input value synchronously after two active clock edges, de-
asserting the target flops’ resets. See Figure 1-14 on page 29 for an example.

Figure 1-14 Standard Reset Synchronizer
If the reset signal of a flop is the output of a reset synchronizer, CDC reports the reset pair
between the reset signal of the synchronizer and the flop, that is, between rst and dout in
the above example.
In direct reset synchronization, the reset signal enters the data of the first flop and the
asynchronous resets are set to zero. The gate present in the output of the synchronizer
guarantees that the reset assertion is asynchronous and the de-assertion synchronous. See
Figure 1-15 on page 29 and Figure 1-16 on page 30.
Figure 1-15 Negedge Asynchronous Reset

Figure 1-16 Posedge Asynchronous Reset
The tool detects this type of synchronizer as direct reset (see help for the
direct_reset_detection configuration rule). Direct reset synchronization has the
following limitations:
■ The tool does not verify, either structurally or functionally, the correct polarity of direct
reset synchronizers.
■ Direct reset synchronizers are detected when the input is a declared reset signal only.
Note: Direct reset synchronizer detection is included as an initial release to gather feedback
from early adopters and finalize implementation for an upcoming release. Contact
support@cadence.com to provide feedback or comments targeting the upcoming production
version.
CDC finds these reset synchronizers in the design and reports them as CDC schemes of type
reset (Figure 1-16 on page 30).
Note: CDC does not report reset inside reset synchronizers.
CDC Verification Phases

CDC verification phases include configuration, reset order analysis, structural analysis,
functional analysis, metastability injection, and reset analysis.

CDC Configuration
Flops can be driven by two or more different clock signals, depending on the control signal
value. The assignment of a constant value for each clock mux selector characterizes an
operation mode for the design, and depending on the operation mode, the tool detects
different pairs and violations.
For example, in Figure 1-17 on page 31, the tool detects a pair when en = 1 but not when
en = 0.
Figure 1-17 Pair Detection Dependent on Operation Mode
Not a CDC Pair
CDC Pair
Thus, you must manually constrain the mux selectors with single-mode analysis, which is the
default, or enable multi-mode analysis with the following command:
check_cdc -check –rule –set {{multi_mode_analysis true}}.
With multi-mode analysis enabled, CDC reports all possible crossings between the clock
signal at the mux inputs and all the clock signals in the design and identifies the condition (that
is, the control signal value) in which the tool detects each pair and violation (see Figure 1-18
on page 32).

Figure 1-18 Mux Chain Example
Also, as shown in Figure 1-19 on page 33, if you configure clk3 to be synchronous with
clk1 and clk2, the tool does not report a pair since there is no possible asynchronous
combination between the clock signals in the source and destination flops.

Figure 1-19 Synchronous Clock Signals
When comparing multi-mode to the default single-mode analysis, multi-mode analysis might
report more pairs than single-mode. These pairs are a consequence of the extra clock
domains that multi-mode analysis reports. The constants defined in the configuration for
single-mode analysis simplify some clock trees in the design, making it possible for the tool
to group more clock signals in the same domain. This is not possible with multi-mode analysis
because there are no constants defined.
Known limitations of CDC multi-mode analysis follow:

■ The tool does not detect equivalent modes that require any equivalent logic support.
■ The tool might report internal signals for the identified clock modes.
■ When the analysis does not reach a primary clock (or reaches more than one primary
clock) from the input of a mux in the clock tree, the multi-mode analysis for that muxed
clock is interrupted. In this case, the tool handles the muxed clock as a separate domain
and issues a warning.
Note: Multi-mode analysis is included as an initial release to gather feedback from early
adopters and finalize implementation for an upcoming release. Contact
version.

Reset Order Analysis

Reset domain crossings (RDC) are a well-known source of metastability in digital designs.
Assertion of an asynchronous reset in a flop might cause the data input of subsequent flops
to change asynchronously with respect to their clocks. One possibility for addressing this
structural problem is to ensure that resets on both sides of an RDC are asserted in the correct
order, that is, the latter flop needs to be reset by the time the reset of the first flop is asserted.
During structural reset analysis, you can specify reset order information using the
check_cdc -reset -set_order command. CDC then uses the information you have
provided to automatically waive the appropriate RDC violations.
Reset Order Command
The basic command syntax for the reset order command follows:
check_cdc –reset –set_order <reset_signal_list>
The reset signal list is a list of lists that reflects how different resets are asserted with respect
to each other. Resets appearing later in the list are asserted before resets appearing earlier
in the list. Resets that are asserted simultaneously can be specified by grouping them
together in a second-level list. See the following example:
% check_cdc –reset –set_order {ARST1 ARST2 {ARST3 ARST4}}
With this command, you inform the tool that ARST3 and ARST4 are asserted simultaneously
and are already reset by the time ARST2 is asserted, which is already reset by the time ARST1
is asserted.
Note:
■ You must specify reset order during CDC setup phase. You cannot run check_cdc
-reset -set_order after running reset analysis with check_cdc -reset –find
unless you first run reset –clear.
■ check_cdc -reset -find uses the reset order information you specify to
automatically waive non-problematic RDC violations. Use the check_cdc -reset
-set_order -preview command to get the set of reset domain crossings the tool will
automatically waive as a result of the reset order definitions provided.
■ Reset order information can be specified in successive check_cdc -reset
-set_order commands. The tool keeps an internal representation of the cumulative
effect of all the reset order definitions provided.

❑ CDC issues warning WCDC005 if a new check_cdc -reset -set_order

command contradicts previous reset order relationships between resets. The
previous relationships are overridden, and the last definition provided prevails.
❑ If a new reset order command creates a circular dependency among resets, the tool
issues error ECDC001, and the entire new reset order definition is discarded.
❑ Use the check_cdc -list reset_order command to get the set of reset order
definitions you provided.
See the following examples of RDC violations based on the reset setup specified with the
following command:
% check_cdc –reset –set_order {ARST1 ARST2 {ARST3 ARST4}}
Example 1
Crossing ARST1->ARST3 is not problematic considering that ARST3 will already be reset by
the time ARST1 is asserted. The tool automatically waives this RDC violation.
The tool reports crossing ARST3->ARST2 as an RDC violation since there is no guarantee
that ARST2 is reset by the time ARST3 is asserted (only the opposite has been specified).
Figure 1-20 Example 1
Example 2
Crossing ARST4->ARST3 is not problematic considering that ARST4 and ARST3 are asserted
simultaneously. The tool automatically waives this reset violation.

Reset domain crossings between resets for which no order relationship is specified are not
automatically waived. Thus, the tool would report a violation for a crossing between ARST3-
>ARST5 since it cannot infer anything about the reset order of ARST5.
Figure 1-21 Example 2
Example 3
When CDC cannot trace each flop's asynchronous reset pin back to a single reset signal, the
tool reports an RDC violation, as shown in the two scenarios below:

Figure 1-22 Crossing ARST1,ARST2->ARST1
Figure 1-23 Crossing ARST2->ARST1,ARST2
Structural Analysis
Structural checks identify issues related to synchronizers, convergence, and combinational
logic to confirm that all CDC signals have been properly synchronized. CDC structural
analysis automatically identifies and classifies all CDC pairs and schemes and reports

structural issues, for example, erroneous or missing synchronizers, combinational logic in the
CDC path or synchronization path, and convergence, divergence, and reconvergence issues.
See Chapter 5, “CDC App Path Rule Configuration” for additional information on structural
checks rule configuration.
Functional Analysis
Functional analysis automatically generates CDC protocol assertions to identify transfer
protocol issues related to synchronization schemes, that is, to confirm that data from the
source clock is properly captured by the destination clock without loss or corruption. Typical
CDC protocol assertions include data and control signal stability checks and handshake or
FIFO synchronizer-related checks. You can run these assertions in a formal or simulation
environment.
Note:
■ For information on running and proving functional checks, see “Running Functional
Checks” on page 94, and for associated command syntax, see “Functional Analysis” on
page 58.
■ For information on exporting functional checks to simulation, see “Exporting Functional
Checks to Simulation” on page 96.
The tool generates functional checks based on the synchronizer type. Currently, the tool
generates functional checks only for schemes that have no structural violations.
See Chapter 6, “CDC App Functional Checks” for a description of functional checks the tool
generates for each of the supported synchronizer schemes.
Metastability Modeling and Injection

While structural analysis can identify reconvergent structures, not all of these structures are
problematic. To identify and debug problematic reconvergence, the tool must successfully
model non-deterministic delays in synchronizers. Both the setup and hold violations must be
modeled to detect all metastability-related bugs.
Reset Analysis
Reset analysis automatically identifies reset synchronizers and reset violations in the design.
The tool reports two types of reset violations: 1) scenarios in which there is a clock crossing
through the reset path and 2) scenarios in which there is a reset crossing even though the

flops are in the same clock domain. Both scenarios can cause metastability problems and
should, therefore, be reported as reset pairs.
Clock Crossing Reset Pairs
Disregarding buffers, the tool considers the signal connected to the flop's reset pin the reset
signal of a flop. Consider the following cases:
■ Primary input (see Figure 1-23 on page 39) – In this case, if rst is a primary input, the
tool considers rst the reset signal of the flop and the reset pair is generated between
rst and dout.
Figure 1-24 Primary Input in Reset Path
■ Combinational logic in the reset path (see Figure 1-23 on page 39) – In this case, CDC
considers the reset signal the output of the combinational logic grst and the reset pair
is generated between grst and dout.
Figure 1-25 Combinational Logic in Reset Path

■ Flop in the reset path (see Figure 1-23 on page 40) – In this case, CDC considers the
output of srst the reset signal and the reset pair is generated between srst and dout.
Figure 1-26 Flop in Reset Path
A clock crossing reset pair is reported between a flop and its asynchronous reset signal as
follows.
■ If the flop and its reset signal are in the same clock domain or the reset signal is a correct
reset synchronizer, the reset pair is reported as Passed.
■ If the flop and its reset signal are in different clock domains, the reset pair shows Failed
status.
■ If the reset pair contains violations, it shows a Failed status. See the “Full List of
Violations” on page 222 for additional information.
Reset Domain Crossing
Metastability can be propagated from the reset path when the reset of the source register is
different from the reset of the destination register even though the data path is in the same
clock domain (Figure 1-27 on page 41). Additionally, if the source flop has an asynchronous
reset signal and the destination flop does not, the tool reports a reset violation.

Figure 1-27 Reset Domain Crossing
During reset assertion (srst), if the reset value is different from the value in the source flop
output (data), the destination flop can become metastable if it is not being reset. To address
this problem, the design should always use the same reset in a clock domain or both resets
must be asserted simultaneously.
CDC App GUI Orientation

This section provides an overview of the CDC App GUI. For detailed procedures, see
Chapter 3, “GUI Features”.

Figure 1-28 CDC App Main Window Orientation
CDC App
menu
Expert
System
Status
CDC App
Review
Violations
pane
CDC App
main tab
sub-tabs
CDC App
main tabs
Figure 1-29 CDC App Wizard
Design Setup CDC CDC Phases Formal CDC CDC CDC

Configuration tools Verification Export Waiver Debug
Additional setup tools tools Tools and Tools
controls Reporting
tools

Table 1-1 CDC App GUI Components
Window
Function
Component
Application menu This menu includes the Add Signal Configuration, Generate
Report, Waivers, and Proof options. Use these options as follows:
■ Add Signal Configuration – Define one or more signals as
constant, static, mutually exclusive, or gray coded.
■ Generate Report – Generate a violations report.
■ Waivers – Access the Add Waiver dialog or export waivers.
■ Proof – Prove signal configuration, protocol checks, or
metastability, or access the ProofGrid Manager.

Table 1-1 CDC App GUI Components, continued
Window
Function
Component
Toolbar The toolbar includes generic and CDC App wizards with the following
button groups:
■ Design Setup – Set up the design and environment. Use the
down arrow to access additional setup and session options.
■ CDC Configuration – Load the port configuration; define one or
more signals as constant, static, or mutually exclusive, or gray
coded; automatically detect all clock domains in the design; or
create a filter based on GUI filters.
■ CDC Phases – Find CDC pairs and schemes, identify structural
convergence and reconvergence issues, generate protocol
checks for previously detected schemes, inject metastability into
the synchronizers in the COI of all user properties, and find reset
signals.
Note: For ease of use, the icons on the associated CDC
Configuration and CDC Phases tab sub-tabs mirror the buttons
on this wizard, and clicking these buttons brings the associated
sub-tab table to focus if applicable.
■ Formal Verification – Specify proof settings, prove signal
configuration, prove protocol checks, verify the result of the
metastability injection, stop all jobs in the current session, and
access the ProofGrid™ Manager.
■ Export – Export filtered checks or metastability candidates to
simulation.
■ Violations – Waive violations based on filter criteria and generate
violations reports.
■ CDC Debug – Show CDC graph plus schematic or open the
Schematic Viewer.
Just above the toolbar on the right is the JasperGold Expert System
status bar. For additional information, access the Expert System
User Guide from the tool (Menu – Application Guides).

Window
Function
Component
Review Violations/ The Review Violations table includes two tabs, the Checks tab and
Review Waiver the Hier Groups tab.
Effects table
The Checks tab lists all rule violations by type in the left-hand pane
and provides additional information, including the violation check type
and severity, in the right-hand pane. The check type is listed under the
Check column. If you hover over the check type, you see a tooltip that
both defines the rule and provides possible actions to resolve the
violation.
This table includes a drop-down menu in the upper right-hand corner
that opens the following views:
■ Review Violations (the default)
■ Review Waiver Effects
Use this menu to toggle between reviewing violations and assessing
waiver effects. To view the details for a specified waiver only, click on a
waiver in the Waiver table. Doing so automatically filters the violations
table to show only violations affected by the selected waivers. Clicking
the Exit Waiver View button that appears at the top left of the
violations table returns you to the full list of violations.
The Hier Groups tab groups pair and reset violations by hierarchy
based on source and destination instances. Thus, you can detect
patterns based on the instance information provided by the tool.

Window
Function
Component
CDC Configuration The CDC Configuration tab includes the following sub-tabs:
tab
■ Port Configuration – Includes information about all design ports.
Use this table to configure top inputs and outputs and black-boxed
inputs and outputs.
■ Signal Configuration – Displays constant and static signals.
Note: During CDC configuration, you may need to define one or
more signals as constant, static, or mutually exclusive toggle to
resolve problems in the design. For example, to select one of the
inputs of a clock mux, the mux select needs to be tied to a constant
value.
■ Clock Domains – Displays all clock domains in the left-hand pane
and indicates with a green check mark, a red x, or a yellow
question mark the status of each clock domain, for example, a red
x may indicate a clock that has not been defined or has a complex
driving logic which makes automatic tracing difficult.
Click on a clock domain to see the associated clock signals, signal
types, and clock domains in the pane to the right. Double-click on
a clock signal (or right-click and choose View in Schematic) to
open a schematic viewer and debug erroneous clock domains.
■ CDC Rules – This table displays the specifics of the default path
rules for structural analysis. It contains a column header for Rule
Type (Pair, Scheme, Group, Reset, and Config) and for each rule,
for example, CDC Pair Logic, CDC Pair Fanout, N Min, N Max,
Sync Chain Logic, and so forth. Move your cursor and hover over
the contents of the first populated cell under each rule header to
access a tooltip that defines the rule and lists the default and other
valid options.
Continued below.

Window
Function
Component
CDC Configuration You can modify rule attributes based on your design. All rule
tab (Continued) modifications are applied globally.
Access the full command reference from the command line (help
check_cdc -gui) and click on check_cdc -check for
additional details. Also see Chapter 5, “CDC App Path Rule
Configuration,”
■ Filters – Displays the specifics of all user-added filters.
check_cdc -gui) and click on check_cdc -filter for
additional details.
■ User-Defined Schemes – Displays information for all user-
defined and custom schemes. Since not all schemes can be
automatically detected, you can add user-defined schemes as
needed.
check_cdc -gui) and click on check_cdc -scheme for
additional details. Also see Chapter 4, “User-Defined and Custom
Synchronizer Schemes”.

Window
Function
Component
CDC Phases tab The CDC Phases tab provides information on the different stages of
the CDC analysis and includes the following sub-tabs:
■ Pairs – The left-hand pane displays a tree of all CDC pairs. Click
on a CDC pair to see the related information in the right-hand
pane. Related information includes source and destination clocks;
source and destination units; pair classification (that is, data,
control, or data and control); rule violations; and scheme. Green
checks indicate that the CDC pairs passed all path rules, red Xs
indicate rule violations, blue “not” icons indicate CDC pairs that
you have waived, and orange “not” icons indicate pairs that the tool
has automatically waived. Use the Pairs table context menu to
view a schematic, see associated rule violations in the Review
Violations table, view a scheme in the Schemes sub-tab, or view
the source.
■ Schemes – The left-hand pane displays a tree of all CDC pairs.
Click on a CDC pair to see the scheme information in the right-
hand pane. Scheme information includes scheme, scheme type,
detection type, and violation. A third pane at the bottom of the
Schemes sub-tab includes information from the Pairs sub-tab.
■ Convergence – The left-hand pane displays a tree that lists all
identified convergence, divergence, and reconvergence issues.
Click on a group of issues (or expand the group [+] and click on a
specific issue) to see the CDC group information in the right-hand
pane. Group information includes CDC group, convergence type,
whether the convergence came from the same source domain or
signal, and depth. A third pane at the bottom of the Convergence
sub-tab includes information from the Pairs sub-tab.
■ Functional – The left-hand pane displays a tree that lists all CDC
checks. Click on a CDC pair (or expand the pair [+] and click on a
scheme) to view a table with the names of the associated
functional checks. From this table, you can use the context menu
to verify properties, view associated rule violations in the Review
Violations table, Visualize a failing property, show a property
graph, show a scheme schematic, or view a witness trace.
Continued below.

Window
Function
Component
CDC Phases tab ■ Metastability – This tab includes a task table with a summary of
(Continued) proof results, a property table with assertions and a set of
assumptions that represent the formal verification environment,
and a table detailing CDC pair information. Prove properties
before injecting metastability, and then use the toolbar wizards to
inject metastability and verify whether the properties still pass
(that is, are immune to metastability effect).
Waivers tab The Waivers table displays information on added waivers. When you
click on a waiver in the Waivers table, the Violations table enters the
Review Waiver Effect view, which is automatically filtered to show
only violations affected by the selected waivers. The Exit Waiver
View button that appears at the top left of the Review Waiver Effect
table returns you to the full list of violations.
Use the waivers button on the Violations wizard to waive all CDC
pairs that match any filters you have created using the GUI column
filters. Use this table’s context menu to add or remove waivers, to
open the Edit Waiver Comment dialog, or to open a Visualize trace
for debugging (if applicable).

Window
Function
Component
Design Hierarchy The Design Hierarchy tree displays the source file hierarchy.
tree
Note: This pane can be accessed by clicking the Show Design
Hierarchy button on the far right of the CDC App toolbar.
From this pane, you can use the context menu (right-click) to do any of
the following:
■ Open the Source Browser window with a focus on the instance you
selected in the tree
■ Expand (or collapse) all levels of the hierarchy, or click individual
expand (+) or collapse (-) buttons to view various levels of the
hierarchy
■ Access the Design Information window with context-sensitive
details
■ Visualize the selected instance in WaveEdit mode or show the
related graph or schematic view.
To see proof details for a module or entity with embedded properties,
move your cursor and hover over the module or instance name to
reveal the tooltip.

2
General Flow and Key Commands
This chapter summarizes the general use flow and introduces key CDC App commands. It
includes the following sections:
■ General CDC App Flow on page 52
■ CDC App Key Commands on page 52
Note: This chapter does not cover all commands or options. Refer to the full command
documentation for additional information. To access the command documentation from the
tool, type help check_cdc -gui on the command line.

General CDC App Flow

The general use flow for the CDC App follows:
1. Analyze and elaborate the design.
2. Declare clocks and reset.
3. Find clock domains and debug.
4. Find CDC pairs.
5. Automatically find pre-defined synchronizer schemes.
6. Manually add unidentified synchronizer schemes.
7. Run structural checks and debug.
8. Generate functional checks for schemes, prove, and debug.
9. Export functional checks and run them in simulation.
10. Inject metastability, prove user-defined properties, and debug.
11. Export metastability candidates to simulation.
CDC App Key Commands

This section includes information on key commands. It does not cover all commands or
options. Refer to the full command documentation for additional information. To access the
command documentation from the tool, type help check_cdc -gui on the command line.
■ Environment Setup on page 53
■ Checks Extraction on page 54
■ Clock Domain on page 54
■ Rule Configuration on page 56
■ Structural Analysis (Pairs, Scheme, Convergence, and Reset) on page 57
■ Functional Analysis on page 58
■ Metastability Injection on page 58
■ Filtering Results on page 59
■ Waiving Violations on page 59

■ CDC Export on page 60

■ CDC Import on page 60
■ Bottom-Up Hierarchical CDC on page 60
■ Reporting Results on page 61
■ Listing Objects on page 62
■ Saving and Restoring a CDC Analysis Session on page 64
■ Reading an SDC File on page 65
Environment Setup
Manage constant and static values and create asynchronous and synchronous groups of
clocks.
■ Use check_cdc -init to load the Port Configuration table in the CDC
Configuration tab.
■ Use check_cdc -signal_config (-add_constant {{signal_name
value}+} |-add_static signal_list |-add_exclusive signal_list
|-add_gray_code signal_list) to define one or more signals as constant, static,
or mutually exclusive toggle or to add gray encoding to a signal.
■ Use check_cdc -signal_config -add_false_path (-from list |-to
list |-through list) to specify paths that should be excluded from the CDC
analysis.
■ Use config_rtlds -reset ( ( -sync signal_list -clock clock_signal
|-async signal_list
|-synchronized signal_list -clock
clock_signal
[-polarity (high | low)]) to specify design
resets as asynchronous, synchronous, or synchronized.
■ Use config_rtlds -reset
-set_order {reset_signal+ {reset_signal+}+})) to
specify an order among reset signals during CDC setup phase.

Checks Extraction
Use the check_cdc -extract basic command to infer the formal setup (that is, the
clocks and asynchronous resets of the design) if none is provided, uses heuristics to define
the environment setup, and runs CDC structural checks.
Clock Domain
Automatically detect and redefine the clock domain configuration.
■ Use check_cdc -clock_domain -port signal_list -clock_signal
clock_signal to define the clock signal associated with the top output or the input of
a black-boxed instance.
■ Use check_cdc -clock_domain -port signal_list -clock_signal
clock_signal -external_sync [-source_domain
source_domain_list] to specify that the ports in signal_list are externally
synchronized into clock_signal_list. Use the optional -source_domain switch
to specify the source domains from which these ports are synchronized.
Note:
❑ If you use the -source_domain switch, you must run this command after
check_cdc -clock_domain -find.
❑ See “Externally Synchronized Ports” on page 55 for additional details.
■ Use check_cdc -clock_domain -port -module module_name -input
signal_name to create a clock association that will be used for instantiations of this
module, associating the list of signals with the domain of the provided input port.
■ Use check_cdc -clock_domain -virtual_clock name_list to create virtual
clocks that represent clock domains external to the design.
■ Use check_cdc -clock_domain -find to automatically detect all clock domains in
the design.
This command has two options, -aggressive and -use_liberty_information,
that function as follows:
❑ Use -aggressive to run an additional analysis in an effort to reduce the number
of undeclared clock domains. This additional analysis starts from the signals in the
undeclared domains and traverses backward collecting all declared clocks. If it finds
a single declared clock, it joins the undeclared domain into the declared one. If it
finds multiple declared clocks, it creates a new domain called
jg_combined_clock_i, and joins the domains.

❑ Use -use_liberty_information to use the timing information contained in a

Liberty™ file to automatically infer the clock domain of ports of black-boxed
instances in a design. Typically, the flow would be as follows:
analyze + elaborate
# Design configuration, including loading one or more Liberty files

...
liberty -load libfile1.lib
...
liberty -load libfileM.lib
...
check_cdc -clock_domain -find -use_liberty_information
See the full command help (help check_cdc -gui) for the known limitations of
this command.
Note: -use_liberty_information is included as initial release to gather feedback
from early adopters and finalize implementation for an upcoming release. Contact
support@cadence.com to provide feedback or comments targeting the upcoming
production version.
■ Use check_cdc -clock_domain -join src_clock_domain -into
dest_clock_domain to join two clock domains, adding all the clocking signals to the
same domain.
■ User check_cdc -split clock_name to define a clock signal as a new clock
domain.
Externally Synchronized Ports
When specifying the clock domain for a port, you can use the optional-external_sync
switch to indicate that the port is correctly synchronized into the specified clock by means of
control synchronizers present outside the block under analysis. You can also provide one or
more source domains with the optional -source_domain switch. See the example below:
check_cdc -clock_domain -port P -clock_signal clk -external_sync

-source_domain {jg_sclk1 jg_sclk2}
This command informs the tool that port P is externally synchronized into the domain of clk
from domains jg_sclk1 and jg_sclk2.

Currently, CDC uses this information exclusively for the detection of certain types of
composite synchronization schemes, such as the automatic MUX_NDFF detection scheme
and the user-defined glitch protector and sync enabler detection schemes. The tool allows
ports specified as externally synchronized as the output of the control synchronizer expected
as one of the building blocks of composite schemes. See Figure 2-1 on page 56:
Figure 2-1 Externally Synchronized MUX_NDFF
Given the case above, the following command allows the tool to identify the structure as a
MUX_NDFF scheme since it considers port EN equivalent to the output of the control
synchronizer required for the scheme:
check_cdc -clock_domain -port EN -clock_signal DCLK -external_sync

-source_domain {jg_SCLK}
Without this definition, the clock domain crossing A->B remains uncovered, and the tool
reports the corresponding no_scheme violation.
Rule Configuration
Change checks configuration.
■ Use check_cdc -check -rule -set {{rule_attribute
attribute_value}+} to change rule configuration attributes.

■ Use check_cdc -check -severity {severity_value {checks_list}} to

change the severity of a list of checks for filtering purposes.
■ Use check_cdc -check -hier_group_level level to specify the maximum
hierarchical level in which violations should be grouped. If a violation belongs to an
instance that has a greater level than the one specified, this violation is related to the
parent instance corresponding to the maximum level. The default is 3.
Note: See Chapter 5, “CDC App Path Rule Configuration” for specifics regarding rule
configurations.
Structural Analysis (Pairs, Scheme, Convergence, and Reset)

Automatically identify CDC pairs, synchronizer types, and convergence and reset issues
■ Use check_cdc -pair -find to automatically detect the configuration of CDC pairs.
■ Use check_cdc -scheme -create scheme_type -formal_list
{formal_signals} to create a new scheme type and insert it into the library.
■ Use check_cdc -scheme -add ( ndff | ndff_bus | mux_ndff
| mux_pulse | handshake | fifo | pulse
| edge | glitch_protector
| sync_enabler | reset)
-map {{formal_signal signal}+} to add a user-
defined CDC scheme that maps to one of the pre-defined synchronizer types using the
specified signal mappings.
■ Use check_cdc -scheme -find to find all pre-defined CDC schemes.
Use the optional -aggressive switch with this command to automatically detect control
schemes.
Note:
❑ Reviewing detected synchronizers is advised with this option.
❑ No protocol check is automatically generated.
■ Use check_cdc -group -find to identify structural glitch, convergence, and
reconvergence issues.
Use the optional -aggressive switch with this command to prevent the tool from
reporting convergence or reconvergence of data signals that are synchronized by
complex schemes like FIFO, handshake, and MUX.
Note: check_cdc -group -find -aggressive is included as an initial release to

gather feedback from early adopters and finalize implementation for an upcoming
release. Contact support@cadence.com to provide feedback or comments targeting the
upcoming production version.
■ Use check_cdc -reset -find to identify reset synchronizers and reset violations in
the design.
■ Use check_cdc -violation ( -split violation_key
( -occurrence signal_list [-bit_blast]
|-source signal_list
|-destination signal_list)
|-regroup original_violation_key ) to
split violations according to specific criteria or regroup previously split violations.
Functional Analysis
Generate and prove functional checks for all CDC schemes detected.
■ Use check_cdc -protocol_check -add expression_name -expression
expression_template -scheme scheme_type to automatically create
functional checks.
■ Use check_cdc -protocol_check -generate to automatically create functional
checks.
■ Use check_cdc -protocol_check -prove to validate the functional checks.
■ Use check_cdc -protocol_check -export -file file_name to export the
functional checks to a file for use in simulation.
Note: check_cdc -protocol_check -export is included as an initial release to
gather feedback from early adopters and finalize implementation for an upcoming
release. Contact support@cadence.com to provide feedback or comments targeting the
Metastability Injection
Inject metastability effect in all CDC pairs in the COI of all user properties and verify the
properties in the presence of metastability.
■ Use check_cdc -metastability -inject to automatically inject metastability in
all non-reset CDC pairs in the COI of all user properties. To include reset pairs, use the
optional switch -include_reset with this command. To consider protocol checks
automatically generated by the tool as targets for metastability injection, use the
-include_protocol_check switch.

Note: Both -include_reset and -include_protocol_check are included as

initial release to gather feedback from early adopters and finalize implementation for an
upcoming release. Contact support@cadence.com to provide feedback or comments
targeting the upcoming production version.
■ Use check_cdc -metastability -prove to check the results of the injection.
■ Use check_cdc -metastability -export file file_name
(-time_window ( N | time_window | N time_window ) |-to_formal)
to export the metastability candidates for use in simulation or in a different formal
environment.
■ Use check_cdc -metastability -import (-file file_name
-from_formal) to import metastability candidates in a different formal environment.
Note:
❑ The design setup (RTL, clocks, resets, configuration) must be the same as when the
imported file was generated.
❑ check_cdc -metastability -import is included as an initial release to gather
feedback from early adopters and finalize implementation for an upcoming release.
Contact support@cadence.com to provide feedback or comments targeting the
Filtering Results
Create re-usable filters to specify which violations should be waived. Create filters using the
check_cdc -filter command or by filtering table columns in the GUI and clicking on the
Create a Filter based on GUI Filters button in the CDC Configuration wizard. See
“Waiving Groups of Violations” on page 117.
To add CDC filters, use check_cdc -filter -add...

Note: See the command reference or type help check_cdc -gui for a full list of command
options.
Waiving Violations
Waive violations that you do not plan to fix immediately. To add a new waiver for CDC pairs,
use the following command syntax:
check_cdc -waiver -add -filter filter_id -comment comment

Note:

■ Waivers are based on filters created with check_cdc -filter -add...

■ The -comment switch is mandatory.
■ See “Waiving Violations” on page 115.
CDC Export
Export CDC information to be used in simulation or saved a CDC session.
■ Use check_cdc -export ( -type (signal_config_property
| waiver_cond_property) -file file_name to specify that signal configuration
properties or waiver conditional validation properties be exported to the specified file.
■ Use check_cdc -export -database -file file_name to export the current
CDC database to the specified file.
■ Use check_cdc -export -to_formal -file file_name to export signal config,
conditional waiver, and scheme properties that you want to import to JasperGold in a
different formal environment.
Note: check_cdc -export is included as an initial release to gather feedback from early
version.
CDC Import
Import a CDC session.
Use check_cdc -import -database -file file_name -module module_name

to export the current CDC database to the specified file.
Note: check_cdc -import is included as an initial release to gather feedback from early
version.
Bottom-Up Hierarchical CDC

Reuse information from a block-level analysis at the SoC level by exporting the block
information and then loading that information in the SoC-level analysis before running
check_cdc -clock_domain -find.

Use check_cdc -hierarchical (-module module_name -info file_name) to

load information from a previous analysis. The tool uses the imported information to
automatically create clock domain abstractions for the black-boxed instances of the given
module and generates new integration violations if inconsistencies are detected.
For parameterized designs, if the instance parameters used at the top level do not match the
parameters used during the IP level CDC analysis, the tool issues an error when you attempt
to load the hierarchical database at the top level.
To fix this error, do one of the following:

■ Provide the matching parameter values while loading the database.
■ When different instances of the same module use different parameter values, generate
multiple databases with appropriate parameter values for use at the top level.
Note:
■ The specified file must be a valid CDC database generated with the command
check_cdc -export -database.
■ The specified file must have been generated with version 2018.12 or later, that is, this
flow is backward compatible with 2018.12, 2018.12p001, and 2018.12p002. However, if
you include a file generated with an older version, the tool warns that the analysis might
not be complete. Use the following command to get the version of the database used to
produce a specified file:
check_cdc -hierarchical -get_version -file file_name
■ check_cdc -hierarchical is included as an initial release to gather feedback from
early adopters and finalize implementation for an upcoming release. Contact
production version.
Reporting Results
Generate reports in CSV format for the current CDC setup.
Use check_cdc -report [ pairs | violations | domains | rules

| filters | signoff | signal_config
| user_defined_schemes | waivers | reset
| scheme_properties | domain_crossings
| groups | schemes | checks | units
| clock_signals | inactive_pairs
| clock_groups | clock_matrix | setup
| ports | reset_order | reset_definitions

| reset_paths | reset_schemes]
[-file file_name ]
to generate reports of the specified type and save to the specified file.
Note:
■ When you use check_cdc -report without additional arguments, the tool prints a
violations summary to the console.
■ See the full check_cdc command help for additional details.
Listing Objects
Return a Tcl dictionary listing the detected objects.
■ Use check_cdc -list ( pairs | violations | domains | rules
| filters | signoff | signal_config
| user_defined_schemes | waivers | reset
| scheme_properties | domain_crossings
| groups | schemes | checks | units
| clock_signals | inactive_pairs
| clock_groups | clock_matrix | setup
| ports | reset_order | reset_definitions
| reset_paths | reset_schemes)
to list the detected objects for the specified type.
Since all information in the GUI is listed, you can create a number of scripts using the
-list information. For example, suppose check_cdc -list schemes returns the
following:
FSM_block.control_counter_pulse {Status Passed Scheme
FSM_block.control_counter_pulse {Scheme Type} Edge {Detection
Type} Automatic Pairs control_ block.control_counter_r-
FSM_block.counter_sync.data_meta Violation {}}
control_block.i_manager.msynchronizer.data_sync {Status Failed
Scheme control_block.i_manager.msynchronizer.data_sync {Scheme
Type} MUX_NDFF {Detection Type} Automatic Pairs
{FSM_block.i_code-control_block.i_manager
.msynchronizer.data_sync, FSM_block.i_valid-
control_block.i_manager. msynchronizer.en1} Violation
sync_chain_logic}
This result is a Tcl dictionary for which the keys are the scheme names:
❑ FSM_block.control_counter_pulse

❑ control_block.i_manager.msynchronizer.data_sync
For each scheme, there is another Tcl dictionary containing the scheme information as
follows: Status, Scheme, {Scheme Type}, {Detection Type}, Pairs and Violation.
To access all the information for a certain scheme, pass the key (scheme name) as index:
dict get $DICTIONARY scheme_name
For example,
set dictionary [check_cdc -list schemes]
dict get $dictionary FSM_block.control_counter_pulse
would return
Status Passed Scheme FSM_block.control_counter_pulse {Scheme
Type} Edge {Detection Type} Automatic Pairs
control_block.control_counter_r-FSM_block
.counter_sync.data_meta Violation {}
To list all keys, use dict keys $dictionary, which in this example, would return the
following:
FSM_block.control_counter_pulse,
control_block.i_manager.msynchronizer.data_sync
With the scheme dictionary, you can access any information inside a scheme providing
a key.
For example,
set scheme_info [dict get $dictionary
FSM_block.control_counter_pulse] dict get $scheme_info Pairs
would return
control_block.control_counter_r-FSM_block.counter_sync.data_meta
Also, if you want to count how many sync_chain_logic violations the tool found, you
can use the following script:
set scheme_list [check_cdc -list schemes]
set schemes {}
foreach key [dict keys $scheme_list] {
if {[lsearch [dict get [dict get $scheme_list $key] \
Violation] sync_chain_logic] >= 0} {
lappend schemes $key
}

}
puts $schemes
■ Use check_cdc -list -filter filter_id to list only the IDs of the objects
related to the specified filter.
For example, if you want to remove all schemes of type edge, you can create a filter as
follows,
set filter_id [check_cdc -filter -add -scheme_type edge]
and then use the filter to list only edge schemes:
set edge_schemes [check_cdc -list schemes -filter $filter_id]
The result would be as follows:
FSM_block.control_counter_pulse {Status Passed Scheme
FSM_block.control_counter_pulse {Scheme Type} Edge {Detection
Type} Automatic Pairs control_block.control_counter_r-
FSM_block.counter_sync.data_meta Violation {}}
To remove the schemes, you can now use the dictionary keys:
foreach key [dict keys $edge_schemes] {
check_cdc -scheme -remove $key
}
Saving and Restoring a CDC Analysis Session

Save or restore the design and the current CDC setup.
Note: You can use the Incremental Analysis feature to save the current state of the CDC App
analysis to a database and then restore the database to that same state at a later time. To
use the Incremental Analysis feature, ensure that set_capture_elaborated_design is
on before elaborating the design.
■ Use check_cdc -save -file file_name to save the current state of the tool to
the specified file.
■ Use check_cdc -load -file file_name to reload a saved database from the
specified file and restore the tool to an earlier state.

Reading an SDC File

Use the following command to read an SDC source file and translate its contents to
JasperGold Apps commands:
check_cdc -sdc -source sdc_file_name
When you source an SDC file with this command, the JasperGold console displays a report
that prints, for each supported command found, the count of successful and failed executions.
For example, the report would show the following for the create_clock command:
create_clock <successes><failures>
Note:
■ Run this command after elaboration, but before any clock and any other check_cdc
command.
■ When the tool encounters an unknown SDC command, it issues a warning that points to
the line and file where the command was used.
■ check_cdc -sdc is included as an initial release to gather feedback from early
production version.
A table of supported SDC commands with brief descriptions follows.
Table 2-1 Supported SDC Commands
Command Description
Create Clock
create_clock <source_objects>
Source objects are RTL signals that are the target of the command.
They will be declared as clocks.
create_clock -name <name>
Name of the clock definition. Used to reference this definition later on
SDC file.
create_clock -add
Used to avoid overwriting clock definitions for the same target.
create_clock -period

Command Description
Used to infer the factor for clock declarations. For this switch to
function, the use_sdc_clock_period rule must be set to true.
Note: CDC never creates JasperGold clocks with a period larger than
10. If any clock has a period larger than 10, all created clocks receive a
period and phase of 1.
create_clock -waveform
Uses the specified waveform (together with the period of the clock) to
automatically generate clock definitions with appropriate clock factors.
Use use_sdc_clock_period to disable translation of waveform
information while reading the SDC commands.
Note: The difference between the last and first edges in the specified
waveform must not be equal to or larger than the period.
Example:
create_clock -period 10 -name C1 -waveform {0 10} clk -add
Create Generated Clock

create_generated_clock <source_objects>
Source objects are RTL signals that are the target of the command.
They will be declared as generated clocks related to a source clock.
create_generated_clock -divide_by <integer>
Specifies the frequency division factor. The generated clock will be
<integer> times slower than the source clock.
create_generated_clock -multiply_by <integer>
Scales the generated clock. The frequency is multiplied with the
specified factor.
create_generated_clock -combinational
The tool interprets the -combinational switch to be equal to
-divide_by 1.

Command Description
create_generated_clock -edges
Pulses are not supported.
If the CDC use_sdc_clock_period command is false, the
-edges switch is not considered and all clocks are translated to have
a period and phase of 1. However, the arguments of the
create_generated_clock command must still be valid or the tool
returns an error.
create_generated_clock -invert
Inverts the generated clock and can only be used together with
-divide_by, -multiply_by, and -edges.
create_generated_clock -name <name>
Name of the generated clock definition. Used to reference this
definition later on SDC file.
create_generated_clock -source <signal>
RTL signal that is the source clock of the generated clock that is being
defined.
create_generated_clock -add
Used to avoid overwriting generated clock definitions for the same
target.
create_generated_clock -master_clock <clock_name>
Specifies which source clock definition should be used when
<signal> has more than one definition.
Examples:
create_generated_clock clk_dst -name RCLK -source clk -master_clock
C1 -divide_by 2 -add
create_generated_clock -name MC1 -source [get_ports fclk] [get_pins
mclk] –combinational
create_generated_clock -name MC2 -source [get_ports tclk] [get_pins
mclk] -divide_by 2 –invert
create_generated_clock -name GC1 -source [get_ports clk1] [get_pins
clk_reg1] -edges {1 3 5}

Command Description
Set Clock Groups

set_clock_groups -name <name>
Name of the clock group.
set_clock_groups -asynchronous
Defines that the group is a set of asynchronous signals. By default,
members of the same group are considered synchronous between
them.
set_clock_groups -logically_exclusive
Pairs between clocks set as logically exclusive are generated as
inactive.
set_clock_groups -physically_exclusive
Pairs between clocks set as physically exclusive are generated as
inactive.
set_clock_groups -group <list_of_clocks>
RTL clock signals that are part of the group.
Example:
set_clock_groups -name cgroup -asynchronous -group {C1 C2} -group
{C3} -group {C4}
Set Case Analysis

set_case_analysis <port_or_pin_list>
List of ports or pins to which <value> is assigned.
set_case_analysis <value>
Specifies the constant value or the transition to assign to the given
port.
Example:
set_case_analysis 1 sig
Set Input Delay

set_input_delay <delay>

Command Description
Integer that specifies the delay. It is necessary because of command
syntax, but has no effect.
set_input_delay <port_pin_list>
RTL signals that are the target of the command. They will be rated in
the provided clock.
set_input_delay -clock <clock>
Clock signal used to rate the target ports in <port_pin_list>.
set_input_delay -clock_fall
Specifies that the delay is relative to the falling edge of the clock.
set_input_delay -add_delay
Specifies whether to add delay information to the existing input delay
or to overwrite a previous constraint for a signal in
<port_pin_list>.
Example:
set_input_delay 10 -clock C1 in
Set Output Delay

set_output_delay <delay>
Integer that specifies the delay. It is necessary because of command
syntax, but has no effect.
set_output_delay <port_pin_list>
RTL signals that are the target of the command. They will be rated in
the provided clock.
set_output_delay -clock <clock>
Clock signal used to rate the target ports in <port_pin_list>.
set_output_delay -clock_fall
Specifies that the delay is relative to the falling edge of the clock.
set_output_delay -add_delay

Command Description
Specifies whether to add delay information to the existing output delay
or to overwrite a previous constraint for a signal in
<port_pin_list>.
Example:
set_output_delay 10 -clock C1 out
Set Clock Sense

set_clock_sense <pin_list>
List of pins that are the target of the command.
set_clock_sense -stop_propagation
Stops the propagation of specified clocks in <clock_list> from the
specified pins in <pin_list> forward.
set_clock_sense -clock <clock_list>
Specifies a list of clocks to be applied with the given definition.
Note: CDC supports both -clock and -clocks.
Example:
set_clock_sense -clock {C1 C2} -stop_propagation sig
Additional Commands
set_hierarchy_separator <separator>
Defines which will be the hierarchy separator used in the SDC file.
get_pins <pattern>
Returns all the signals in the design that match the pattern used.
get_ports <pattern>
Return all the ports in the design that match the pattern used.
set_disable_timing
Used to ignore timing arcs.
Example:
set_disable_timing -from clk0 -to fclk top.cpu0.m_inst.mem0_m0

3
GUI Features
This chapter provides information on specific GUI features and includes the following
sections:
■ CDC App Wizard on page 72
■ CDC App Configuration Tab on page 73
■ CDC Phases Tab on page 87
■ Waiving Violations on page 115
■ Reporting on page 123
■ Integrated Debugging Environment on page 127

GUI Features
CDC App Wizard

The CDC App wizard includes Design Setup, CDC Configuration, CDC Phases, Formal
Verification, Export, Violations, and CDC Debug button groups as shown in Figure 3-1
on page 72. Use these buttons to guide the flow:
Figure 3-1 CDC App Wizard
■ Use the Design Setup group buttons to set up the design and environment. Use the
down arrow to access additional setup and session options. See “Specifying the
Environment” in the JasperGold Platform and Formal Property Verification App
User Guide for additional information.
■ Use the CDC Configuration group buttons to load the Port Configuration table,
access the Add Signal Configuration dialog, automatically find clock domains, or create
a filter based on GUI filters.
Note:
❑ You can also use the check_cdc -extract basic command to run the tool with
no configuration.
❑ Clicking these buttons brings the associated sub-tab table to focus if applicable.
■ Use the CDC Phases group buttons to automatically find CDC pairs, find CDC
schemes, find CDC convergence issues, generate protocol checks for previously
detected schemes, inject metastability into the synchronizers in the COI of all user
properties, and find CDC reset signals.
Note: Clicking these buttons brings the associated sub-tab table to focus if applicable.
■ Use the Formal Verification group buttons to specify proof settings, verify functional
checks, verify the result of the metastability injection, stop all jobs in the current session,
and access the ProofGrid Manager.
■ Use the Export group buttons to export filtered checks or metastability candidates to
simulation.
■ Use the Violations group buttons to waive violations based on filter criteria and generate
violations reports.

GUI Features
■ Use the CDC Debug group buttons to show the CDC graph plus schematic or open the
Schematic Viewer.
CDC App Configuration Tab

The CDC Configuration tab includes sub-tabs for the following:
■ Port Configuration – Displays information about all design ports.
■ Signal Configuration – Displays constant or static signals and their values
■ Clock Domains – Displays all clock domains and indicates any problems with a domain
■ CDC Rules – Displays specifics of the path rules for structural analysis
■ Filters – Displays the specifics of all user-added filters
■ User-Defined Schemes – Displays information for all user-defined and custom
synchronizer schemes
This section discusses the Port Configuration and Clock Domains sub-tabs in greater
detail and includes the following sections:
■ Port Configuration on page 73
■ Identifying Clock Domains on page 81
■ Resolving Problems with Clock Domains on page 82
Note:
■ Other sub-tabs associated with the CDC Configuration tab are discussed in context
later in this guide.
■ For additional details on the CDC Configuration tab, see “CDC Configuration tab” on
page 46.
Port Configuration
Port configuration is the first step in CDC analysis. The Port Configuration table shows all
top level inputs and outputs and black-boxed inputs and outputs in one table.
To populate the Port Configuration table, do one of the following:

■ Click the Load ports configuration button on the CDC Configuration wizard.
■ Type the command check_cdc -init on the command line.

GUI Features
The Port Configuration tab displays all top level inputs and outputs and black-boxed
inputs and outputs and indicates port status with a green check mark (passing), a red x
(failing), or a blue circle (static). See Figure 3-2 on page 74.
Note: If you have not loaded the port configuration before you run check_cdc
-clock_domain -find, the Port Configuration table is populated with the
check_cdc -clock_domain -find command.
Figure 3-2 Port Configuration Tab
A port passes if it is any of the following:

❑ A declared clock
❑ A declared reset
❑ A static signal (static assertion proven)
❑ A signal declared as constant
❑ Rated to a clock (manually or automatically by the tool)
A port fails if it is 1) not rated to any clock or 2) declared as a static signal but the static
assertion has failed.
The Port Configuration table context-menu provides the following options for resolving
failures:

GUI Features
■ View in Schematic – Open a schematic viewer window with the port signal and its
fanout.
■ Declare as clock – Declare top inputs as clock
■ Declare as reset– Declare top inputs as reset
■ Add Signal Configuration – Declare constant or static value for top level input/
output and black-boxed output ports
■ Set Clock for Port – Set the signal clock for top level input/output and black-boxed
output ports
■ Sync with all domains – Declare synchronization with all domains for all top-level input
and black-boxed output ports
Declaring a Signal as Constant or Static
To declare a port as constant or static, do the following:

1. Right click on a signal and choose the Add signal configuration context-menu option.
The Add Signal Configuration dialog opens with the Signal Name field pre-filled
(Figure 3-3 on page 76).

GUI Features
Figure 3-3 Add Signal Configuration
2. Specify the Signal Type by selecting the Constant or Static radio button.
3. Complete the Value field if you have selected constant for the signal type.
4. Complete the Condition field if you have selected Static and want to specify a
precondition.
5. Click Add.
6. To add additional constant or static signals, type a signal name in the Signal Name field
and repeat steps 2-5.
7. Click OK.
Adding a constant signal invalidates the current port configuration.
8. Click the Load Ports Configuration button on the CDC Configuration wizard to
repopulate the tab.
The tool adds the configuration details to the CDC Configuration tab’s Signal
Configuration tab (see Figure 3-4 on page 77).

GUI Features
Note: You can also access the Add Signal Configuration dialog from the Signal
Configuration table context menu even if the table is empty.
Figure 3-4 Signal Configuration Tab
Important
You can remove the restriction of declaring the clock mux select lines as constant by
enabling multi-mode analysis. With multi-mode analysis enabled, the tool gets the
CDC analysis results for all operational modes, without having to run the analysis for
each mode separately, and reports them in a single view.
If you have enabled multi-mode analysis, the Mode column in the CDC Phases tab
Pairs sub-tab indicates whether a specific CDC pair exists in more than one mode. If
multi-mode analysis is disabled, which is the default, this column is empty (Figure 3-13
on page 88).
Enable multi-mode analysis with the following command:
check_cdc -check -rule -set {{multi_mode_analysis true}}
Note:
❑ See the command help for check_cdc -rule -set and check_cdc -pair
-list_modes for additional information.
❑ For more information on multi-mode versus single-mode analysis, see “CDC
Configuration” on page 31 in Chapter 1, “CDC Concepts and GUI Orientation.”

GUI Features
Adding Gray Encoding
You can also use the Add Signal Configuration dialog to create user-defined gray encoded
checks as follows:
The Add Signal Configuration dialog opens with the Signal Name field pre-filled
Figure 3-5 Add Gray Coded
2. Specify the Signal Type by selecting the Gray Coded radio button.
3. Click Add.
4. To add additional gray-encoded signals, type a signal name in the Signal Name field
and repeat steps 2-5.
5. Click OK.

GUI Features
The tool adds the signal to the CDC Configuration tab’s Signal Configuration sub-tab
as type GrayCodedSig (see Figure 3-6 on page 79)
If a signal is undriven, the tool generates an assumption; otherwise, the tool generates
an assertion that you can prove with the check_cdc –signal_config –prove
command. If the property is not proven, the tool generates a signal configuration
violation.
Note: You can also access the Add Signal Configuration dialog from the Signal
Configuration table context menu even if the table is empty.
Figure 3-6 Adding Gray Encoding
Adding Mutually Exclusive Toggle Signals
If there is more than one signal converging into a combinational logic in the destination
domain, but not more than one toggle at the same time, you can safely waive the convergence
or re-convergence violation. Thus, when you declare signals mutually exclusive, the tool
attempts to apply automatic waivers.
Use the Add Signal Configuration dialog as follows to declare signals mutually exclusive:
The Add Signal Configuration dialog opens with the Signal Name field pre-filled.
2. Specify the Signal Type by selecting the Exclusive radio button.
3. Click Add.

GUI Features
4. Specify a second signal in the Signal Name field.

You must specify at least two signals.
5. Click Add.
6. Specify additional signals in the Signal Name field as required.
7. Click Add.
8. Click OK.
Note: You can also add mutually exclusive signals from the session with the following
command:
check_cdc –signal_config –add_exclusive {<signal_name>+}
The tool uses this information to apply automatic waivers to applicable CDC groups during
convergence detection (see “Automatic Waivers” on page 122).
The signals must be either single-bit signals, which may or may not be bits of a bus, or
individual bits of a multi-bit bus. See the following examples:
■ Single-bit signals: sigA, sigB, sigC
■ Bits of different buses: busP[0], busQ[7], busR[3]
■ Individual bits of a multi-bit bus: sigX[0], sigX[1], sigX[2], sigX[3], or sigX
Note:
■ The mutually exclusive toggle relationship cannot be specified between two multi-bit
buses.
■ The tool issues a warning message during the re-convergence phase when the signal
list you have provided does not follow the listed specifications. In this case, the mutex
signals declared will have no effect in the auto waivers flow.
■ You can declare the mutually exclusive toggle relation during the CDC Configuration
phase only.
Rating a Signal
By default, CDC automatically rates unrated input ports by the clock of the flop they are
driving. If these inputs are driving flops in different clock domains, the tool cannot infer the
clock domain and the ports remain unclocked units.
Note:

GUI Features
■ If you prefer not to automatically rate these ports, set the

treat_boundaries_as_unclocked rule to true.
■ Constant ports are not affected by this analysis and remain in the sync domain.
Otherwise, this flow handles static values and the tool tries to assign a valid clock domain
for them.
To set the signal clock for an unrated signal, do the following:

1. Right click on a signal and choose the Set Clock for Port context-menu option.
The Set Signal Clock dialog opens with the Signal Name field pre-filled (Figure 3-7 on
page 81).
Figure 3-7 Set Signal Clock
2. Specify the signal clock in the Signal Clock field.

3. Click OK.
The tool runs the check_cdc -clock_domain -port <signal> -clock_signal
<signal> command and the Configuration column value changes from unrated to
Rated_Manual.
Identifying Clock Domains

To populate the Clock Domains tab, do one of the following:
■ Click the Find Clock Domains button on the CDC Configuration wizard.
■ Type the command check_cdc -clock_domain -find on the command line.

GUI Features
The Clock Domains tab displays all clock domains in the left-hand pane and indicates
with a green check mark, a red x, or a yellow question mark the status of each clock
domain. A red x indicates an error while a yellow question mark indicates some missing
configuration. Click on a clock domain to see the associated clock signals displayed in
the right-hand pane (see Figure 3-8 on page 82).
Figure 3-8 Clock Domains Tab
Resolving Problems with Clock Domains

To resolve problems with clock domains, you can do any of the following:
■ Define a signal as constant, static, or mutually exclusive toggle
■ Declare an undriven signal as clock for the clock domain
■ Create a group of synchronous clock signals
■ Make an unclocked input synchronous with all clock domains
■ Create a new clock domain by splitting an existing clock domain
■ Join two synchronous clocks
Note: See “Clock Domain” on page 54 for an overview of the CDC App clock domain
commands.

GUI Features
This section details GUI procedures for joining two synchronous clocks and handling unrated
units.
■ Joining Synchronous Clocks on page 83
■ Handling Unrated Units on page 85
Joining Synchronous Clocks
In Figure 3-9 on page 84, the Signal Type for signal

clocks_and_resets.clk1_div_reg is Clock Divider, which suggests that this signal is
an output of a clock divider module. To confirm and then join these two synchronous clocks,
do the following:
1. Right-click and choose View in Schematic.
The Schematic Viewer opens showing clk1_div as the output of the flop in the
clocks_and_reset block (see Figure 3-9 on page 84). This signal is an output of the
clock divider where clock_control1 is the input, and clock_control1 is selected
at the output of the clock mux whose select line is a constant value of 1. Thus, you can
safely declare clk1_div_reg as synchronous to clock_control1.

GUI Features
Figure 3-9 Viewing Schematic of a Clock Divider
2. To join these two synchronous clocks together, select the clock domain
jg_clocks_and_resets.clk1_div_reg and drag and drop it onto
jg_clock_control1.
The Join Clock Domains dialog opens (Figure 3-10 on page 85).

GUI Features
Figure 3-10 Join Clock Domains Dialog
3. Click Yes.
Handling Unrated Units
Unclocked ports, that is, all ports that do not have an associated clock domain, are associated
to the virtual clock signal :jg_cdc_unclocked, which is asynchronous to all clock signals
in the design. If you want to configure these units to be synchronous with all clock signals in
the design, use the following command:
check_cdc -clock_domain -sync_all_unclocked
This command associates the unclocked units to a virtual clock signal :jg_cdc_sync, which
is synchronous to all clock signals in the design.
You can also specify a list of unclocked units to be synchronous with all clock domains in the
design as follows:
check_cdc –clock_domain –sync_with_all <unclocked_inputs_list>
Important
These commands should be run after check_cdc -clock_domain -find and
before check_cdc -pair -find.
Use the following command to list all units:
check_cdc -list units
This command returns the CDC unit clock signal, type, status, and active clock edge. Unit
types include the following: TopInput, TopOutput, BBoxInput, BBoxOutput,
FlopUnit, and Clock. Unit statuses include the following: Rated_Auto, Rated_Manual,
Sync. Constant, Static, and Unrated.

GUI Features
The following script returns unrated units only. See “Listing Objects” on page 62 for additional
information on listing specified objects.
set cdc_units [check_cdc -list units]
set units {}
foreach key [dict keys $cdc_units] {
if {[lsearch [dict get [dict get $cdc_units $key] Status] Unrated] >= 0} {
lappend units $key
}
}
puts $units
The number of unclocked ports is shown on the status bar of the clock domain table (see
Figure 3-11 Status of Unclocked Ports
To view unclocked port violations in the Review Violations pane, do the following:
➡ Click unclocked_signal in the violations tree (see Figure 3-12 on page 87).

GUI Features
Figure 3-12 Viewing Unclocked Violations
CDC Phases Tab

This section details procedures for populating the CDC Phases sub-tabs and includes
information on the following:
■ Pairs and Schemes Tabs on page 87
■ Convergence Tab on page 92
■ Functional Tab on page 94
■ Metastability Tab on page 96
Pairs and Schemes Tabs

Structural checks identify issues related to synchronizers, convergence, and combinational
logic to confirm that all CDC signals have been properly synchronized. This section provides
information on CDC App pairs and schemes analysis and includes the following sections:
■ Finding CDC Pairs on page 87
■ Finding CDC Synchronizers on page 88
■ Understanding Structural Violations on page 91
■ Fixing a Violation on page 92
Finding CDC Pairs
To populate the Pairs tab, do the following:

1. Click the Find CDC Pairs button on the CDC Phases wizard (see Figure 3-13 on
page 88).

GUI Features
All clock domain crossings are listed in a tree on the left and the CDC pairs for each clock
crossing are displayed on the right.
Figure 3-13 Finding CDC Pairs
Finding CDC Synchronizers
To automatically identify all synchronizers on these paths, do the followings:

1. Click the Find Schemes button on the CDC Phases wizard (see Figure 3-14 on
page 89).
Icons in the left-most column of the right-hand pane of the Pairs tab now indicate the
status of the CDC pair. Red Xs denote paths that have violated path rules, blue “not”

GUI Features
circles denote violations that you have waived, orange “not” circles denote violations that
have been automatically waived, and green check marks denote paths that have passed
all path rules.
Note:
❑ Violations are listed in the Review Violations pane.
❑ See “Waiving Violations” on page 115 for additional information about user-defined
and automatic waivers.
Figure 3-14 Finding Schemes
2. To view only failing pairs from the Pairs table, do the following:

GUI Features
a. Click on the Change filter options button in the heading of the Status column to
open the filter dialog (see Figure 3-15 on page 90).
b. Click Select all to deselect all, and then select Failed to see only failed schemes.
The table contents are filtered and the status bar shows Column filter applied.
c. To restore the complete list, click the Reset all filters button.
Figure 3-15 Filtering by Status
3. To view the details of the schemes detected, click the Schemes tab (see Figure 3-16 on
page 91).
The left-hand pane displays a tree of all CDC pairs, and the right-hand pane shows all
synchronizers the tool identified. When you highlight a scheme, a third pane at the
bottom of the Schemes sub-tab shows the pairs table.

GUI Features
Figure 3-16 Schemes Tab
Understanding Structural Violations
To learn more about structural violations, do the following:

1. Click on a violation in the Review Violations table (see Figure 3-17 on page 91).
Figure 3-17 Review Violations Table and Brief Description

GUI Features
2. To see a brief description of the default path rule settings for the rule along with
suggestions for fixing the violation, hover over the rule type under the Check column.
3. Right-click on the violation of interest and choose Debug Violation.
An integrated debugging view with schematic and graph opens (see “Debugging
Structural Violations” on page 203 or additional information).
Note: You can also debug pair violations from the Hier Groups tab in the Review
Violations table.
Fixing a Violation
You can fix a violation by modifying the RTL or by altering the path rule settings for the
problematic CDC pair (see Chapter 5, “CDC App Path Rule Configuration”). You might also
choose to waive violations (see “Waiving Violations” on page 115).
Convergence Tab
The Convergence tab displays any glitch, convergence, or reconvergence issues that may
exist in the design. Structural glitches report potential glitch sources in a clock domain (for
example, combinational logic in the CDC path). Convergence issues identify cases where
CDC signals from different sources converge into combinational logic in the destination clock
domain, and reconvergence issues identify cases where CDC signals from the same source
(for example, a bus vector) converge into combinational logic in the destination domain.
This section provides information on CDC App convergence analysis and includes the
following:
■ Identifying Convergence Issues on page 92
■ Resolving Convergence Issues on page 93
Identifying Convergence Issues
To populate the Convergence tab, do one of the following:

■ Click the Find Convergence button on the CDC Phases wizard.
■ Type the command check_cdc -group -find in the console.
The tool shows convergence and reconvergence issues and structural glitches as sets
on the tree in the left-hand pane of the Convergence tab. The convergence points are
shown in the CDC Group column on the right-hand pane and all CDC pairs involved in

GUI Features
the CDC group are shown in the pairs table at the bottom of the Convergence tab
Figure 3-18 Convergence Tab
Resolving Convergence Issues
To open a schematic of a violation, do the following:

1. Select convergence or reconvergence checks in the Review Violations tree.
2. Right-click on a convergence or reconvergence in the Review Violation table and
choose Debug Violation.
Note: You can also right-click on a violation in the Convergence table and choose View
in Schematic.

GUI Features
A schematic plus graph view opens (see “Debugging Structural Violations” on page 203
for additional information).
Fix convergence issues by using a different synchronizer or choosing to automatically waive

violations (see “Automatic Waivers” on page 122).
Functional Tab
Functional analysis automatically generates CDC functional checks to identify transfer
source clock is properly captured by the destination clock without loss or corruption. This
section provides information on CDC App functional analysis and includes the following
sections:
■ Running Functional Checks on page 94
■ Understanding Functional Violations on page 95
■ Exporting Functional Checks to Simulation on page 96
Important
Before running functional checks, consider using the following command to link
user-defined assumptions in the <embedded> task to <CDC_*> tasks: task
-link (<task_name>)+ [-to <inheriting_task_name>]
Running Functional Checks
To populate the Functional tab, which displays all CDC checks on the left and the associated
details on the right, do the following:
1. Click the Generate Protocol Checks button on the CDC Phases wizard (see Figure 3-
19 on page 95).
2. To verify the checks, click the Prove Protocol Checks button on the CDC App Formal
Verification wizard.
Icons in the left-most column of the right-hand pane of the Functional tab indicate the
status of the proof.

GUI Features
Figure 3-19 Functional Checks Tab
Understanding Functional Violations
To better understand why a check failed, do the following:

1. Select a category of functional check in the Review Violations tree.
2. Right-click on a check in the Review Violation table and choose Debug Violation.
Note: You can also right-click on a failing property in the Functional table and choose
View Violation Trace.
A Visualize window and graph view opens (see “Debugging Functional Violations” on
page 206).

GUI Features
3. Use Visualize debugging features to debug the trace.

Note: For information on Visualize debugging features, access the Visualize manual
available from the tool’s Help menu (Help – Application Guides – Jasper Visualize
GUI Features) or consult the “Visualize” chapter in the JasperGold Platform and
Formal Property Verification App User Guide.
Exporting Functional Checks to Simulation
To export the generated assertions to simulation, do the following:

1. Click the Export Filtered Checks to Simulation button on the CDC App Export
wizard.
The Export File dialog opens.
2. Enter a file name.
3. Click Save.
The tool generates an encrypted assertion file.
4. From your UNIX®1 terminal, run the simulation using the generated assertion file.
Note: check_cdc -protocol_check -export is included as an initial release to gather
feedback from early adopters and finalize implementation for an upcoming release. Contact
version.
Metastability Tab
The Metastability tab includes three panes, a task table with a summary of proof results, a
table of assertions and assumptions that represent the formal verification environment of the
design, and a table that displays relevant CDC pairs. This section provides information on the
CDC App metastability analysis and includes the following:
■ Injecting and Verifying Metastability on page 97
■ Understanding Metastability Failures on page 98
■ Exporting Metastability to Simulation from the GUI on page 98
■ Exporting Metastability to Simulation from the Command Line on page 99
■ Running a Metastability-Aware Simulation on page 100
1.UNIX is a registered trademark of The Open Group.

GUI Features
■ Customizing Setup and Hold Times on page 103

■ Debugging Metastability Injection in Simulation on page 103
■ Combining Metastability Injection Models in a Single Simulation on page 111
■ Combinational Glitch Injection on page 113
Injecting and Verifying Metastability
To determine whether properties are immune to the metastability effect, do the following:
1. Go to the CDC Phases tab Metastability sub-tab.
2. Right-click on one or more user-defined properties and click Prove Property.
In the example shown below, all properties pass (see Figure 3-20 on page 97).
Figure 3-20 Passing Properties
3. To inject metastability effect into the synchronizers in the COI of the passing properties,
click the Inject Metastability in User properties button on the CDC Phases wizard.
This resets the property status.
4. Click the Prove User Properties with Metastability button on the CDC App Formal
Verification wizard.

GUI Features
If an assertion fails in the presence of metastability, then you can conclude that the failure
is because of metastability effect.
Figure 3-21 Failures after Metastability Injection
Understanding Metastability Failures
To debug a failure, do the following:

➡ Right-click on a failure and choose View Violation Trace.
A Visualize window plus graph view opens (see “Debugging Metastability Violations” on
page 206 for additional information).
Exporting Metastability to Simulation from the GUI
To export the generated insertion points to simulation from the GUI, do the following:
1. Click the Export Metastability Candidates to Simulation button on the CDC App
Export wizard.
The Export File dialog opens.
Note: Though you must specify a directory to continue, the tool ignores this information.
This dialog will be removed in a future release.

GUI Features
2. Select a directory from the list and click Choose.

The Export to Simulation dialog opens.
3. Enter a value for the Time Window parameter.
4. Specify the hierarchical path (Testbench Hierarchy) inside your simulation testbench,
for the design analyzed in the CDC App.
5. Click OK.
In the session folder, the tool generates the files.
6. From your UNIX terminal, run the simulation using the generated metastability injection
files.
Note:
■ Metastability injection in simulation works on top of CDC pairs and not CDC
synchronizers. Thus, all CDC pairs, including unsynchronized signals, are considered for
metastability injection in simulation. Therefore, you need to run the CDC analysis up to
the finding CDC pairs phase.
■ check_cdc -metastability -export is included as an initial release to gather
feedback from early adopters and finalize implementation for an upcoming release.
Contact support@cadence.com to provide feedback or comments targeting the
Exporting Metastability to Simulation from the Command Line
Alternatively, you can export the generated injection points to simulation from the command
line as follows:
check_cdc -metastability -export

-time_window ( <N> | <time_unit> | <N> <time_unit> )
[-include_comboglitch] [-include_reset]
[-dir <dir>] [-force]
[-report]
■ Use -time_window to specify the time window as follows:
❑ N is mandatory if you do not specify the time unit.
❍ If you use N and do not specify a time_unit, the default is nanoseconds (ns).
❍ N is a natural non-zero number.
❑ time_unit is mandatory if you do not specify N.

GUI Features
❍ If you use time_unit and do not specify N, the default is 1.

❍ time_unit is s, ms, us, ns, ps, or fs.
❑ If you override the setup and hold times when binding the metastability injection
model to your design, you need to specify the value in seconds using scientific
notation. For example, bind top : dut meta_injection
#(.TSETUP_clk(5e-9)) i_meta_injection(); overrides the value of the
setup window associated with clock clk to be 5ns.
■ Use -include_comboglitch to explicitly generate the extra RTL for combo-glitch
mode.
Note: +define+CDC_COMBOGLITCH has no effect unless you generate the model with
this switch.
■ Use -include_reset to explicitly generate the extra RTL for a simplified model of
injection due to asynchronous reset de-assertion. See “Metastability Injection due to
Asynchronous Reset De-Assertion” on page 109 for additional information.
■ Use -dir to export the simulation files to the specified directory. If you do not specify a
directory, the simulation files are written to the session directory.
■ Use -force to overwrite files in an existing directory.
■ Use -report to generate a report with the results of the -export command, including
the list of exported and discarded candidates.
Note: CDC groups injection points exported to simulation by destination and displays these
by destination in the report generated with the -report option. For example, even when two
different CDC pairs data1[1:0]->q[1:0] and data2[1:0]->q[3:2] are shown in the
Pairs tab, a single grouped injection point q[3:0] is exported to simulation and shown in the
metastability injection report. Consider this fact when noting divergences between the
number of CDC pairs reported and the number of candidates for metastability injection
exported to simulation.
Running a Metastability-Aware Simulation
When exporting metastability to simulation, the tool generates the following two files (in the
session folder by default or in the folder specified with -dir):
■ global_meta_injection.sv: This file contains shared utility code used by the
metastability injection model.
■ <top>_meta_injection.sv: <top> is the name of the top module analyzed in
JasperGold. This file contains the metastability injection model for the particular design

GUI Features
analyzed in JasperGold. The whole model is contained inside a module called

<top>_meta_injection in the file.
You must include both files when running a simulation, and you must also bind any instance
of the <top> module to the corresponding metastability injection model to make them
metastability-aware.
Important
Since the file global_meta_injection.sv contains code used by the
metastability injection model in <top>_meta_injection.sv, you must include
them in this order when calling the simulator.
Example
Top module controller is analyzed in JasperGold and files global_meta_injection.sv

and controller_meta_injection.sv are generated after exporting metastability to
simulation.
The simulation testbench has a top module called tb, and the module controller is
instantiated twice inside the testbench hierarchy, at tb.ip1.i_controller and
tb.ip2.i_controller, as shown in Figure 3-22 on page 102.

GUI Features
Figure 3-22 Controller Instantiated Twice
To bind the metastability injection model to the appropriate instances, you can include the
following statements in a file (bind.sv, for example):
bind controller : tb.ip1.i_controller
controller_meta_injection ip1_controller_msi();
bind controller : tb.ip2.i_controller
controller_meta_injection ip2_controller_msi();
When calling the simulator, you can then combine the design files, the metastability injection
files, and the bind file together as follows:
irun -sv <verilog_design_files> \

GUI Features
-v93|v200x <vhdl_design_files> \
global_meta_injection.sv \
controller_meta_injection.sv \
+extbind+bind.sv \
-access rwc
Note: The switch -hier_path in the check_cdc -metastability -export command

is deprecated. Its function, specifying to which instance the metastability injection model
needs to be attached, is now performed by the bind statements described above.
Customizing Setup and Hold Times
The metastability injection model includes separate values for the setup and hold times of
flops triggered by different clocks in the design. All are defined as parameters of the module
<top>_meta_injection, included in the model file <top>_meta_injection.sv (where
<top> is the name of the top module analyzed in JasperGold).
By default, all the setup and hold time parameters are set to the value you provide with the
-time_window switch of the check_cdc -metastability -export command.
However, their values can be individually overwritten when the model is instantiated in the
simulation testbench, specifying them in seconds using scientific notation as shown below:
bind controller : tb.ip1.i_controller controller_meta_injection #(.TSETUP_dclk(3e-

9),.THOLD_dclk(1e-9)) ip1_controller_msi();
The previous bind statement sets the setup and hold times as 3ns and 1ns, respectively, for
all flops triggered by clock dclk that can suffer metastability in the model
ip1_controller_msi.
Debugging Metastability Injection in Simulation
This section discusses debugging metastability injection in simulation and includes the
following topics:
■ Hierarchy of a Metastability Injection Model on page 104
■ Injection Enables on page 105
■ Internal Variables on page 105
■ Metastability Injection Messages on page 106
■ Writing Injection Messages to a File on page 107

GUI Features
■ META BEHAVIOR Tag on page 107

■ META BEHAVIOR for Setup Violations on page 107
■ META BEHAVIOR for Hold Violations on page 108
Hierarchy of a Metastability Injection Model
Metastability injection models generated by the tool are organized hierarchically, following
some naming conventions. Being aware of the hierarchy and naming conventions will help
you debug metastability related behavior.
In the content that follows, <top> is the name of the top module analyzed in JasperGold,
<model_instance> is the instance name given to the model when instantiated using the
bind construct, and <register> is the path to each of the specific registers that can suffer
metastability.
The hierarchy inside a metastability injection model includes the following four nested levels:
1. Wrapper module for the whole model:
❑ Module name: <top>_meta_injection
❑ Instance name: <model_instance>
2. Wrapper module for a specific register:
❑ Module name: msi_<top>_<register>
❑ Instance name: i_msi_<top>_<register>
3. Wrapper modules for setup/hold violations for a specific register:

❑ Module names: msi_setup_<top>_<register> and
msi_hold_<top>_<register>, respectively
❑ Instance names: i_msi_setup_<top>_<register> and
i_msi_hold_<top>_<register>, respectively
4. Setup/hold timing violation checkers:

❑ Module names: check_setup_violation and check_hold_violation,
respectively
❑ Instance names: i_cs and i_ch, respectively

GUI Features
Injection Enables
Each wrapper module for specific registers inside the model have setup and hold injection
enables exposed. Their full paths inside the model are as follows:
<model_instance>.i_msi_<top>_<register>._setup_inj_en
<model_instance>.i_msi_<top>_<register>._hold_inj_en
These signals have been exposed to allow a basic means of enabling/disabling metastability
injection for specific registers during a simulation. By default, they are true, that is,
metastability injection is enabled for every register in the model, but you can override this
value by using force statements.
Internal Variables
Several internal variables of the setup/hold timing violation checkers are also exposed to ease
debugging of metastability injection opportunities. All can be found at the following paths
inside the model's hierarchy:
<model_instance>.i_msi_<top>_<candidate>.i_msi_setup_<to
p>_<candidate>.i_cs
<model_instance>.i_msi_<top>_<candidate>.i_msi_setup_<to
p>_<candidate>.i_ch
The purpose of each variable is indicated below:

■ data_last_change: Timestamp of the data’s last change
■ clock_last_change: Timestamp of the clock’s last change
■ delta: Last computed difference between data_last_change and clock_last_change
■ regular_value: The value sampled by the register in a regular simulation (not
metastability-aware)
■ meta_value: This value can be considered as an indication that a specific data change
can produce a metastable behavior, different from that of a regular simulation. This is not
the value that gets injected when a timing violation happens (see inject_value
below), but it is used to randomize inject_value. The key ideas follow:
❑ A given data change inside the setup/hold window is considered as an injection
opportunity if regular_value and meta_value are different from each other.

GUI Features
❑ Only the bits that are different between regular_value and meta_value are
randomized to generate the value actually injected ( inject_value ).
■ inject_value: The actual value forced at the register’s output as the result of a timing
violation
■ rand_sel: Random boolean value used to choose between the regular and meta
values (done bit-wise) to decide the final inject_value
■ timing_violation: A pulse that indicates that data has changed causing a timing
violation; its width is TW (the time window, that is, either the setup or hold times)
■ meta_behavior: Boolean value that indicates whether the value (randomly) injected is
different from that of a regular simulation (not metastability-aware)
Metastability Injection Messages
Once the files global_meta_injection.sv and <top>_meta_injection.sv are

included in a simulation, the tool reports metastability injections in the simulation log as
follows:
In addition, at the beginning of the simulation, each timing violation checker module issues a
message informing the value of the time window used to detect metastability injection
opportunities. For example:
tb.i_soc.i_ip1A.ip1A_ip1_meta_injection.i_msi_ip1_q1.i_m
si_setup_ip1_q1.i_cs: Time Window (TW) =
2.000 ns
These messages follow the hierarchy and naming conventions described above. In the
previous example, the tool is informing that the time window for the setup violation checker

GUI Features
(i_msi_setup_ip1_q1.i_cs) of register q1 of metastability injection model for module

ip1 (i_msi_ip1_q1) is 2 ns.
Writing Injection Messages to a File
Alternatively, you can write the injection messages to a file instead of including them in the
simulation log. To do so, set the following macro when calling the simulator:
+define+METALOGFILE=<file>
Note: File global_meta_injection.sv contains a top-level module msi_global used

for allowing the model to open and write the injection opportunity messages to the file
provided. This module needs to be identified by the simulator as a top-level module; otherwise
you see a *E,CUVUNF: Hierarchical name component lookup failed at
'msi_global' elaboration error when trying to run a metastability aware simulation.
As a general rule, just take care when your simulation contains VHDL top-level design units,
since Verilog and SystemVerilog top-level modules are determined automatically (module
msi_global among them):
■ If your simulation testbench contains a single VHDL top-level design units, use the
-vhdltop <design_unit> option when calling the simulator.
■ If your simulation testbench contains multiple VHDL top-level design units, use one -top
<design_unit> option for each of the top-level units.
Refer to the simulator documentation for additional details on how top-level modules are
determined in a simulation.
META BEHAVIOR Tag
As mentioned above, the tool adds a META BEHAVIOR tag in the message corresponding to
metastability injections that caused a behavior different from that of a regular simulation (not
metastability-aware). This indicates different behaviors depending on the timing violation type
(setup or hold), as shown in the examples below.
META BEHAVIOR for Setup Violations
225.000 ns: SETUP violation detected; Injected 0 @

tb.dut.q1
[tb.dut.data1 (data): 0 -> 1, at 224.000 ns]

GUI Features
[META BEHAVIOR]
285.000 ns: SETUP violation detected; Injected 1 @
tb.dut.q1
META BEHAVIOR for Hold Violations
225.000 ns: HOLD violation detected; Injected 0 @

tb.dut.q1
285.000 ns: HOLD violation detected; Injected 1 @
tb.dut.q1
[META BEHAVIOR]

GUI Features
Metastability Injection Release Time
Metastability injections are achieved by forcing random values at the output of flops suffering
timing violations. By default, the model releases such nodes one fentosecond after the
random value is forced (so the flop can resume its normal operation). If flops in your design
are modeled with some CLK-to-Q delay, this might create a race condition between the
design and the metastability injection model when writing a value to the output of a flop. In
such scenarios, the result of a metastability-aware simulation can be unexpected and difficult
to debug (flops suffering metastability injection do not actually see their output forced to a
random value).
To avoid this, you can override the 1 fs default value for the release time by defining the
INJECTION_RELEASE_DELAY_FS macro when running the simulation. The value specified
is interpreted in fentoseconds. For example, including
+define+INJECTION_RELEASE_DELAY_FS=1000000 sets the release time to be 1 ns.
Metastability Injection due to Asynchronous Reset De-Assertion
Asynchronous reset de-assertion is another well known source of metastability. When the
asynchronous reset of a flop is de-asserted inside a recovery/removal time window around
the clock's active edge, its output can go metastable if the input being sampled by the flop is
different from the reset value. As a result, the flop can randomly sample the new input or
remain with its reset value.
When exporting metastability to simulation, you can optionally include a simplified model for
the injection due to asynchronous reset de-assertion if you add the -include_reset switch
to check_cdc -metastability -export.

GUI Features
Important
This simplified model monitors the flop’s asynchronous reset pin, without analyzing
whether the changes seen are actually asynchronous or synchronous to the flop’s
clock. As a result, spurious injections due to asynchronous reset pins being
synchronously de-asserted are a known limitation of the model.
Most of what has previously been described about the data-path injection also applies to the
metastability injection due to async reset de-assertion. Any relevant difference is explained
below:
■ Customizing recovery and removal times: By default, recovery and removal times are set
to the value you provide with the -time_window switch of the check_cdc
-metastability -export command. Their values can be individually overwritten
when the model is instantiated in the simulation testbench, specifying them in seconds
using scientific notation (for example, bind controller : tb.ip1.i_controller
controller_meta_injection #(.TRECOVERY_dclk(3e-
9),.TREMOVAL_dclk(1e-9)) ip1_controller_msi();).
■ Levels 2, 3, and 4 in the “Hierarchy of a Metastability Injection Model” on page 104 are
slightly different for the reset-path injection model:
❑ Wrapper modules/instances for specific registers are called
msi_reset_<top>_register and i_msi_reset_<top>_<register>,
respectively.
❑ Wrapper modules/instances for recovery/removal violations for a specific register
are called msi_recovery_<top>_<register> /
msi_removal_<top>_<register> and
i_msi_recovery_<top>_register> /
i_msi_removal_<top>_<register>, respectively.
❑ Recovery/removal violation checkers are called check_recovery_violation /
check_removal_violation and i_crcv / i_crmv, respectively.
■ Injection enables for recovery/removal violations can be found in the following paths:
❑ <model_instance>.i_msi_reset_<top>_<register>._recovery_inj_en
❑ <model_instance>.i_msi_reset_<top>_<register>._removal_inj_en
■ Internal variables of the model: reset_last_change contains the timestamp of the
reset's last de-assertion.
■ Metastability injection messages for recovery/removal violations include the type of
violation, the value injected at the output of the flop, and whether or not the value injected
is different from that of a regular simulation (non-metastability aware).

GUI Features
Combining Metastability Injection Models in a Single Simulation
The process described in “Running a Metastability-Aware Simulation” on page 100 can also
be used with multiple metastability injection models generated for different subsystems of a
larger design. Basically, this is a two-phase process where 1) you need to analyze each
subsystem in JasperGold separately to generate its corresponding metastability injection
model for simulation, and 2) you combine all the different metastability injection models
together with your simulation testbench in a call to the simulator where the models are binded
to the appropriate instances in the testbench.
Example
A SoC design (top module named soc) contains two different IP blocks (top modules named
ip1 and ip2, respectively), where soc actually contains two instances of ip1 ( i_ip1A) and
i_ip1B) and one instance of ip2 (i_ip2).
Figure 3-23 Combining Metastability Injection Models

GUI Features
To set up a metastability-aware simulation where the SoC is instantiated as i_soc inside the
simulation testbench module tb (as shown in the diagram above), perform the following
steps:
1. Analyze ip1 in JasperGold, and generate its metastability injection model. This creates
files global_meta_injection.sv and ip1_meta_injection.sv.
2. Analyze ip2 in JasperGold, and generate its metastability injection model. This creates
files global_meta_injection.sv and ip2_meta_injection.sv.
3. Analyze soc in JasperGold, black-boxing modules ip1 and ip2 (since their models
have already been created), and generate the metastability injection model for soc. This
creates files global_meta_injection.sv and soc_meta_injection.sv.
4. Create a separate file to bind the different models to the appropriate instances in the
simulation testbench, including bind statements like the following:
bind ip1 : tb.i_soc.i_ip1A ip1_meta_injection

ip1A_msi();
bind ip1 : tb.i_soc.i_ip1B ip1_meta_injection
ip1B_msi();
bind ip2 : tb.i_soc.i_ip2 ip2_meta_injection ip2_msi();
bind soc : tb.i_soc soc_meta_injection soc_msi();
5. Finally, call the simulator including all the necessary files, as follows:
irun -sv <verilog_design_files> \

global_meta_injection.sv \
ip1_meta_injection.sv \
ip2_meta_injection.sv \
soc_meta_injection.sv \
+extbind+bind.sv \
-access rwc
Important
As shown above, you just need to include one instance of the file
global_meta_injection.sv, since its content is fixed and independent of the
corresponding metastability injection model. In addition, you must include it before
all the model files, since it contains code used by the latter.

GUI Features
You must take care not to include the same clock-domain crossings in more than one
metastability injection model. This is the reason, in step 3 above, the module soc is
analyzed with instances of modules ip1 and ip2 black boxed. Otherwise, metastability
injection for any crossing inside those instances would be duplicated (once in the models
created for ip1 and ip2).
Note: As mentioned in “Running a Metastability-Aware Simulation” on page 100, setup and
hold times can be customized on a per-instance basis. To do so, simply overwrite the default
value of the corresponding parameters in the appropriate bind statements.
Combinational Glitch Injection
Due to the potential for glitches generated by logic, including combinational logic in a
synchronization path is generally against CDC design guidelines. However, due to some
design constraints, designers might be sufficiently confident that the combinational logic is
glitch-free to ignore reported violations. These potential violations, however, are normally
masked during RTL simulation only to become apparent at a later stage, for example, gate-
level simulation, as a source of metastability problems.
To reduce this risk, the CDC App includes a pessimistic metastability injection mode in
simulation, which allows potential combinational glitches to create metastability injection
opportunities at the flops sitting at the output of the combinational logic. That is, when you
enable this pessimistic injection mode, the tool considers potential glitches due to changes in
the CDC path signals violating the setup/hold times of the destination register. The relative
order of the changes in the CDC path signals is randomized internally by the tool, thus
creating the opportunity for glitches to be present at the output of the combinational logic.
Example
As shown in Figure 3-24 on page 114, there is some combinational logic, a simple AND gate
between source flops data_a and data_b and the destination flop q.

GUI Features
Figure 3-24 Combinational Logic inside Synchronization Path
Figure 3-25 on page 115 shows a potential glitch happening at TimeA = 75 ns. Inputs to
the combinational logic data_a and data_b are simultaneously changing from 0 to 1 and
from 1 to 0, respectively. In an RTL simulation, however, these changes do not affect the
output of the combinational logic (signal a_and_b), which remains at 0. Therefore, no
metastability injection opportunity should be generated at the destination flop q, even though
data_a and data_b are changing precisely at the active edge of destination clock dclk.
However, with combinational glitch injection mode enabled, changes in data_a and data_b
are internally randomized, simulating the chance of having a glitch at a_and_b and therefore
creating a metastability injection opportunity at the destination flop, as shown in Figure 3-25
on page 115. Note that q becomes 1 at TimeA = 75 ns even though its input a_and_b
remains at 0.

GUI Features
Figure 3-25 Potential Glitch in the Combinational Logic
Enabling Combinational Glitch Injection
Enable the combinational glitch injection mode by setting the macro CDC_COMBOGLITCH
when calling the simulator as follows:
irun \
-sv <verilog_design_files> \
<path_to_session_folder>/global_meta_injection.sv \
<path_to_session_folder>/<top>_meta_injection.sv \
+extbind+bind.sv \
+define+CDC_COMBOGLITCH \
-access rwc
Note: : +define+CDC_COMBOGLITCH has no effect unless you add the

-include_comboglitch switch to the check_cdc -metastability -export
command.
Waiving Violations
Though you can resolve violations in various ways, for example, by altering the RTL,
modifying the structural path rule attributes, or using a different synchronizer, you can also

GUI Features
choose to waive violations if you determine that it is safe to do so. You can waive single
violations, groups of violations, violations that satisfy a specified expression, or you can
automatically waive violations. This section includes procedures for the following:
■ Waiving Single Violations on page 116
■ Waiving Groups of Violations on page 117
■ Waiving Structural Violations by Hierarchy on page 118
■ Specifying Conditional Waivers by Expression on page 119
■ Specifying Conditional Waivers by Violation Key on page 120
■ Automatic Waivers on page 122
Waiving Single Violations

To waive a single violation, do the following:
1. Right-click on a violation in the Review Violations table and choose Waive.
The Add Waiver dialog box opens (see Figure 3-26 on page 116).
Figure 3-26 Add Waiver Dialog
2. Add a comment to the Comment field.

Note: This field is mandatory. After you have added a comment, you can edit it with the
following command if necessary:

GUI Features
check_cdc -waiver -edit <waiver_id> -comment <new_comment>

This functionality is also available from the Waivers tab context menu.
3. Click OK.
The violation is waived, and the status icon changes from red to blue.
Waiving Groups of Violations

To waive a group of violations, you can set GUI filters and then use the Waive all violations
that match the filters button on the Violations wizard. To set a GUI filter, do the following:
1. Chose which column you want to filter from the Review Violations table and click on the
Change filter options button at the top right of the column heading.
A control box appears (Figure 3-27 on page 117).
Figure 3-27 Waiving Violations Using GUI Filters
2. Enter text to filter the contents of the column.

For example, enter fifo_sync1* in the Occurrence filter box to filter out all violations
except those related to the fifo_sync1* source.
3. Click on the Waive all violations that match the filters button on the Violations
wizard.
The Add Waiver dialog appears (Figure 3-28 on page 118).

GUI Features
Figure 3-28 Add Waiver Dialog
4. Complete the Comment field, which is mandatory.

5. Click OK.
The icons associated with the waived failures change from red to blue, indicating these
pairs have been waived, and the tool adds waived failures to the Waivers tables.
Waiving Structural Violations by Hierarchy

If you know a block is clean and want to avoid running CDC analysis, you can choose to
automatically waive all structural violations fully contained inside a previously analyzed
module or instance. Use the following command to specify the modules or instances that the
tool should skip upon execution of the check_cdc <-phase> -find commands:
check_cdc -waiver -add -hierarchy <module_or_instance>
If you specify a module, the tool automatically translates the command to all instances of the
specified module unless parameters are defined. If parameters are defined, the tool
considers only the instances that match the specified parameters.
Note:
■ You must run this command before generating any violations (that is, before running any
check_cdc <-phase> -find command).
■ For ease of identification, all violations waived with the check_cdc -waiver -add -
hierarchy command include the prefix Hierarchical Waiver in the waiver comment.
■ To facilitate review, these waivers are identified as waiver type Hierarchical in the
Waivers table.

GUI Features
Specifying Conditional Waivers by Expression

You can specify an SVA expression as a waiver condition and then validate the condition with
a formal proof. Once proven, the waiver is considered safe.
To specify a conditional waiver and then validate, do the following:

1. Add the filter on which the waiver will be based (see check_cdc -filter -add...
and Figure on page 119).
Figure 3-29 Added Filter
2. Use the following command syntax to add the conditional waiver:

check_cdc -waiver -add -comment <comment> -filter <filter_id>
(-expression <sva_expression> |-expression_list <exp_list>)
The tool adds the waiver to the Waivers tab as NotProcessed since you have not yet
run the proof (see Figure 3-30 on page 120).

GUI Features
Figure 3-30 Waiver Not Yet Processed
3. Run check_cdc -waiver -prove.

The NotProcessed status becomes Safe if the condition is proven and the waived
violation is removed from the violations table (see Figure 3-31 on page 120).
Figure 3-31 Safe Waiver
Specifying Conditional Waivers by Violation Key

You can use the key in the Violation Key column of the Rule Violations table to waive only
part of a bus_convergence or cdc_pair_logic violation. This column displays a unique
name for each violation, which reports the check type followed by the occurrence (see

GUI Features
Figure 3-32 Violation Key
The syntax for this feature follows:
check_cdc -violation ( -split violation_key

( -occurrence signal_list [-bit_blast]
|-source signal_list
|-destination signal_list)
|-regroup original_violation_key )
Use -split to split a violation based on specific criteria or to regroup previously split
violations.
■ Use -occurrence to split violations based on occurrence signal. And use -bit_blast
to split the given portion of the violation bitwise.
■ Use -source to split violations by source signal.
■ Use -destination to split violations by destination signal.
Note:
❑ Splitting is supported for bus_convergence and cdc_pair_logic violations
only.
❑ -occurrence criteria is available for bus convergence violations only.
❑ -source and -destination criteria are available for pair violations only.
■ Use -regroup to regroup a violation that was previously split.
See the following examples:

■ Split violation into two portions, [6.5] and [2:1].
check_cdc –violation –split bus_convergence:a[7:0] –occurrence {a[6:5] a[2:1]}

GUI Features
■ Split violation into two portions, [A] and [B], and then undo the split:
check_cdc –violation –split cdc_pair_logic:S –destination {A B}
check_cdc –violation –regroup cdc_pair_logic:S
Automatic Waivers
The tool automatically waives structural violations that are a result of logic simplification.
Additionally, the tool can automatically generate gray encoding checks for converging signals
and validate whether these are genuine violations. If proven, these violations are
automatically waived.
To generate and verify automatic waivers, do the following:

1. Click the Find Convergence button on the CDC Phases wizard.
Figure 3-33 Find Convergence Button
2. Run check_cdc -waiver -generate.

The tool adds the automatic waivers to the Waivers tab as NotProcessed since you
have not yet run the proof (figure).
Figure 3-34 Waivers Generated
3. Run check_cdc -waiver -prove.

GUI Features
The NotProcessed status becomes Safe if the condition is proven and Unsafe if the
tool finds a counterexample.
Note: To determine whether automatic waivers are due to static, constant, or mutually
exclusive toggle signals, you can run check_cdc -waiver -why <waiver_id>. This
command lists the signals that might be causing an auto waiver, or returns an empty list if no
related signals are identified.
Reporting
This section presents information on generating reports.
Important
Access to CDC HTML reports requires Firefox® 17 or above.
To access the Generate Report dialog, do the following:

1. Click the Generate Report button on the CDC App Violations toolbar.
Figure 3-35 Generate Report Button
The Generate Report dialog appears with the General tab active (Figure 3-36 on
page 124).

GUI Features
Figure 3-36 Generate Report Dialog (General Tab)
2. Click Generate Detailed Report for a detailed report. By default, the tool generates a
summary report.
3. Under Violation Settings do the following:
❑ Deselect Violation if you do not want violations included in the report. All reports
include violations by default.
❑ Select the check boxes for all violation severities you want reported. The default is
all.
❑ Use the drop-down menu under Order report by to choose how you want the report
organized. Options include Category, Filename, Severity, Label, and Instance.

GUI Features
4. Under Property Settings, do the following:

❑ Select the Property check box to access the options in this group and generate a
properties report.
❑ To focus on properties of a specific type, select one or more Types check boxes. The
default is all types.
❑ To focus on properties of a specific status, select one or more Status check boxes.
The default is all statuses.
5. Under Format, select one or more of the following formats for the report:
❑ HTML
Note: If you choose this option, the Open in Browser option is automatically
selected. Deselect Open in Browser if you prefer not to immediately open the
report in a browser.
❑ XML
❑ CSV
❑ Text
❑ Console
Note: The Console option generates a report to the console only and is the default. This
is the equivalent of issuing check_cdc -report without -html, -xml, or -csv.
6. Under Waived Settings, do the following:
❑ Select the Waived checks only check box if you want to generate a report of
waived checks only.
❑ Select the Exclude waived checks check box if you want to generate a report that
excludes waivers.
❑ Select the Include waived checks check box if you want to generate a report that
includes waivers. This option is the default.
7. Click the Select Instances tab (Figure 3-37 on page 126), and do any of the following:
❑ Use the Filter items field to filter the results list.
❑ Use the context menu (right-click) to expand or collapse all, enable or disable all, or
enable or disable a the selected hierarchy.
❑ Click on the plus sign (+) to expand an instance or click on the minus sign (-) to
collapse an instance.

GUI Features
❑ Select the check boxes for those instances that you want included in the report.
❑ Deselect the check boxes for those instances that you do not want included in the
report.
Figure 3-37 Generate Reports Dialog (Select Instances Tab)
8. When you are ready to generate the report, click OK from any tab.
If you have selected any format other than Console, a Save Report dialog opens.
9. Complete the name field and click Save.

GUI Features
Integrated Debugging Environment

The CDC App provides an integrated debugging environment with advanced debugging
options, including schematics, graphs, and waveform analysis with Visualize. This section
discusses CDC schematics and graphs.
■ Schematics on page 127
■ Graphs on page 130
Note:
■ For additional information on waveform analysis with Visualize, see Help – Application
Guides – Jasper Visualize GUI Features or the “Visualize” chapter in the
JasperGold Platform and Formal Property Verification App User Guide.
■ For a standalone overview of the debugging environment, specifics regarding the
consequences of ignoring violations, and actions you might take to address CDC
violations, see Chapter 7, “Debugging CDC Violations”.
Schematics
You can access simple clock schematics, structural schematics, or scheme schematics from
the context menus of the following tables:
■ CDC Configuration tab – Clock Domains Table (Right-click on a signal and choose
View in Schematic.)
■ CDC Phases Tables
❑ Pairs (Right-click on a CDC pair and choose View in Schematic.)
❑ Schemes (Right-click on a scheme and choose View in Schematic.)
❑ Convergence (Right-click on a CDC group and choose View in Schematic.)
❑ Functional (Right-click on a scheme property and choose Show Scheme
Schematic.)
❑ Reset (Right-click on a CDC pair and choose View in Schematic.)
■ Review Violations Table
❑ Review Violations mode (Right-click on a violation and choose Debug Violation.)
❑ Review Waiver Effects mode (Right-click on a violation and choose Debug
Violation.)

GUI Features
Note:
■ By default, structural schematics include graphs, but the following discusses features of
the schematic viewer only. See “Graphs” on page 130 for a brief discussion of CDC
graphs.
■ Structural schematics are disabled for convergence violations with greater than 1000
signals. For these violations, CDC opens graphs only.
■ For additional information on the JasperGold Apps Schematic Viewer, see the
“Schematic Viewer” chapter in the JasperGold Platform and Formal Property
Verification App User Guide.

GUI Features
Figure 3-38 Schematic of Structural Violation
Undo/Redo
Zoom In
Zoom Out
Zoom Fit
Open
Schematic
Viewer
Settings
Magnifying
Pane
To undo or redo the last action only, click on the Undo or Redo button.
To zoom in on a specific element of the schematic, do any of the following:

■ Left-click on the schematic and drag the mouse to select the section you want to zoom
in on.
■ Left-click over the magnifying pane to grab the magnifier and drag it to the desired view
(see Figure 3-39 on page 130).
■ Click on the Zoom In button.

GUI Features
■ Use the wheel on your mouse to zoom in and out.
Click the Open Schematic Viewer Settings Dialog button to open the Schematic Viewer
Settings dialog. This dialog provides the option to specify the behavior when double-clicking
on a wire or pin. You can choose the default, which is the equivalent of the Add Objects
context menu option, or you can choose to Add objects until instance boundary, flop, or
port.
Figure 3-39 Structural Schematic Magnifier Pane
Graphs
You can access a graph of a property or violation in any of the following ways:
■ Click the Show CDC Graph and Schematic button on the CDC Debug wizard.
■ Right-click on a violation in the Pairs, Schemes, Convergence, or Reset tables and
choose View in Schematic.
■ Right-click on a structural, metastability, or reset violation in the Review Violations table
and choose Debug Violation.
■ Right-click on a property in the Functional or Metastability table and choose Show
Property Graph or Show Graph.

GUI Features
The graph presents a high-level view where nodes represent flops, arrows represent paths,
and different colors represent different clock domains (Figure 3-40 on page 131). You can
expand or collapse detail for square nodes, which represent blocks, by hovering over the
block and clicking on the (+) or (-) that appears in the top left corner.
Figure 3-40 Graph View
In addition to various zoom functions, context-menu options (right-click) for unexpanded

blocks include the following (see Figure 3-41 on page 132):
■ Expand – Expands the selected node
■ Expand All – Expands all nodes in the block
■ Set Focus – Sets the focus to the selected instance node
■ Source Instance Source – Opens the source browser for the instance
■ Design Information – Opens Design Information for the selected node
■ Show All – Expands all
■ Reset Focus – Collapses any expanded instance on the current graph and resets the
focus to the top instance

GUI Features
Figure 3-41 Graph Context-Menu for Unexpanded Nodes
Additional context-menu options for expanded nodes include the following (see Figure 3-42
on page 133):
■ View Fanin in Graph and Schematic – Shows the fanin for the selected node and
expands the schematic accordingly
■ View Fanout in Graph and Schematic – Shows the fanout for the selected node and
expands the schematic accordingly
■ Driver – Opens the source code browser and highlights the driver for the selected node
■ Load – Opens the source code browser and highlights the load for the selected node

GUI Features
Figure 3-42 Additional Context-Menu Options

4
User-Defined and Custom Synchronizer
Schemes
This section explains the user-defined and custom synchronizer schemes the tool supports
and how you can add them using the GUI and command line. The related tool features are
explained in the following sections:
■ User-Defined and Custom Synchronizers on page 135
■ Adding User-Defined Synchronizers on page 137
■ Creating Custom Schemes and Protocol Checks on page 140

User-Defined and Custom Synchronizer Schemes
User-Defined and Custom Synchronizers

The JasperGold CDC App supports ten pre-defined synchronizer schemes. Eight of these,
including NDFF, NDFF_BUS, MUX_NDFF, MUX_PULSE, handshake, FIFO, pulse, and edge,
can be automatically identified by the tool or defined by the user. The other two, glitch
protector and synchronization enabler, are strictly user-defined. See “Synchronizer
Schemes” on page 15 for additional information.
In general, the tool identifies synchronizers when you run check_cdc –scheme –find.
However, in some cases, the tool might be unable to identify a scheme even when it belongs
to one of the automatically detectable types. Any such unidentified synchronizer is reported
as a violation, which adds to the noise. To reduce this noise, you can add unidentified
synchronizers as user-defined schemes. See “Adding User-Defined Synchronizers ” on
page 137 for additional information.
Also, some designs might use synchronizer cells that do not map to any of the ten pre-defined
types. In these cases, again, the tool reports violations since it does not recognize these
synchronizer cells as valid synchronizers. To avoid this, you can add these cells as custom
synchronizer schemes so that the tool accepts them. See “Creating Custom Schemes and
Protocol Checks” on page 140 for additional information.
The remainder of this section offers additional information about user-defined and custom
schemes as follows:
■ Module-Based Versus Instance-Based Schemes on page 135
■ Generation of Functional Checks on page 136
■ Adding a Module-Based User-Defined Synchronizer Using the GUI on page 137
Module-Based Versus Instance-Based Schemes

With the exception of glitch protector schemes, which can be specified exclusively as a
module-based schemes, and synchronization enabler schemes, which can be specified only
as an instance-based scheme, all user-defined and custom schemes can be added as either
module-based or instance-based. To add a scheme as module-based, use the -module
switch when you add the scheme.
Use the module-based approach when the synchronizer is contained in its own RTL module.
In this case, synchronizer detection is based on the detection of any instance of that particular
module. For module-based specification of user-defined or custom schemes, provide the key
signals of the scheme within the scope of the module. Both ports and internal signals in the
module can be used in the specification of the scheme.

Conversely, use the instance-based approach when the synchronizer is not contained in an
RTL module. For instance-based specification of user-defined or custom schemes, provide
the key signals of the scheme within the scope of the top-level module.
CDC Pairs Covered by User-Defined and Custom Synchronizers

For module-based schemes, one of the following must apply:
■ Both source or destination must be inside the module.
■ Either the source or the destination is inside the module and the clock of the source is
synchronous with the source clock you provide (or with the one automatically inferred by
the tool), and the destination clock is synchronous with the destination clock you provide
(or with the one automatically inferred by the tool). If the synchronizer does not have a
source or destination clock, this criteria is ignored and the tool does not perform this
check, which means that all CDC pairs with either the source or the destination inside
the module will be covered by the synchronizer.
There are two exceptions to this rule as follows:

■ Glitch protector schemes cover every CDC data pair including the glitch protector in the
path as well as the CDC control pairs linked to the glitch protector.
■ If the source and destination clocks of the pair are synchronous with the source and
destination clocks of the synchronizer, handshake covers CDC pairs related to the data
parameter you provided even if the CDC pair is not inside the module as long as the
source signal goes into the synchronizer module, crosses it, and then goes out to the
destination flop.
For instance-based schemes, any CDC pair whose source or destination is one of the signals
provided during the specification is covered by the scheme. There is one exception to this
rule; synchronization enabler schemes cover every CDC pair going from the specified source
domain to the destination domain that is controlled by the synchronization enabler signal as
well as the CDC control pair synchronizing the enabler signal (if it is the case).
Generation of Functional Checks

A user-defined synchronizer always maps to one of the ten pre-defined synchronizer
schemes. As a result, the tool automatically generates functional checks for user-defined
synchronizers (with the exception of the synchronization enabler). On the other hand, a
custom synchronizer is an ad-hoc scheme that does not map to any of the pre-defined types.
Therefore, the tool does not generate functional checks for a custom synchronizer, although
custom protocol checks can be added by the user.

Note: The tool generates protocol checks for building blocks of composite schemes only
once (for example, protocol checks for an NDFF that is shared by several MUX_NDFF
schemes).
Adding User-Defined Synchronizers

The tool captures and displays user-defined and custom synchronizer module-based
definitions in the CDC Configuration tab User-Defined Schemes sub-tab as shown in
Figure 4-1 on page 137. The User-Defined Schemes table lists all modules added as user-
defined or custom synchronizers along with their scheme type and signal mapping.
There are formal parameter names defined for each pre-defined synchronizer type in the tool.
To add a module as a user-defined synchronizer, map the actual RTL signal names of the
module to these formal parameter names. These can be either ports or internal signals in the
module.
Figure 4-1 User-Defined Schemes Table
Adding a Module-Based User-Defined Synchronizer Using the GUI

To add module afifo as a user-defined FIFO synchronizer, do the following:
1. Access the CDC Configurations tab User-Defined Schemes sub-tab.
2. Right click on the blank table and select Add FIFO Scheme (see Figure 4-2 on
page 138).

Figure 4-2 Add a FIFO Scheme Menu Item
The Add User-Defined FIFO Scheme dialog box opens with the formal parameter names
listed (see Figure 4-4 on page 139).
Figure 4-3 Add User-Defined FIFO Scheme Dialog
3. Enter the module name in the Module field.

4. Enter the actual RTL signal names in the given fields (see Figure 4-4 on page 139 for a
completed dialog).

Figure 4-4 Add User-Defined FIFO Scheme Dialog with Module and Signal Names
5. Click OK.
The tool adds the module afifo as a user-defined FIFO synchronizer, and it appears in
the User-Defined Schemes table (see Figure 4-4 on page 139).
Henceforth, the tool considers all instances of afifo a FIFO synchronizer and
automatically generates the FIFO synchronizer functional checks for every instance of
afifo.
Adding a User-Defined Synchronizer from the Command Line

You can add a user-defined synchronizer from the command line as well as from the GUI.
Following are two examples of how to add user-defined using the command line.
Example 1
Adding the module afifo as a user-defined FIFO synchronizer:

check_cdc -scheme -add FIFO -module afifo
-map {{Wfull o_full} {Rempty o_empty}
{Winc i_push} {Rinc i_pop}
{Wptr gray8_wr_pointer}
{Rptr rd_pointer} {Wdata i_data}
{Rdata o_data}}

Example 2:
Adding an instance-based user-defined MUX_NDFF synchronizer:

check_cdc -scheme -add MUX_NDFF -map {{data i0.count} {dout i0.m1.count_reg}
{sready i0.m0.en} {dready i0.enable}}
Creating Custom Schemes and Protocol Checks

If you find that the available pre-defined synchronizer schemes are insufficient for your
design, you can create custom schemes and then create protocol checks to verify them.
To create a custom scheme, use the following command syntax:
check_cdc -scheme -create scheme_type -formal_list

{formal_signals}
Formal signals are names for the relevant signals inside each synchronizer. The tool maps
these to the actual RTL signals in your design for each instance of a synchronizer. The tool
already has a set of these signals for the supported types, but it can be extended with new
ones. A valid formal signal name can only have letters, numbers, and underscores. If you
provide an invalid formal signal, the tool errors out.
Note: The scheme_type provided must be a new type. If you provide a name that conflicts
with one that already exists in the library, the tool errors out. Existing scheme types are ndff,
ndff_bus, mux_ndff, mux_pulse, handshake, fifo, pulse, edge, sync_enabler,
and glitch_protector.
Once the new scheme type is created, you can add it as a module-based or instance-based
scheme using the regular check_cdc -scheme -add command. Map the formal signals
of the scheme to actual RTL signals in your design as follows:
check_cdc -scheme -add scheme_type -map {signal_mapping}

[-module module_name]
After you have created and added your custom scheme, use the following command to add
custom protocol checks for the newly created scheme:
check_cdc -protocol_check -add expression_name -expression

expression_template -scheme scheme_type
The expression template must be a valid SVA or PSL property. To build this template, you
must replace the signal names with the corresponding formal signal. All formal signals used
in the template must be related to the synchronizer in question and should be preceded by a

% character. The tool then replaces all instances of %formal_signal by the actual formal
signal when creating the protocol checks for the synchronizer instance.
An example of a valid expression template follows:
{@(posedge %dclk) $changed(%sready) |=> $stable(%sready) until_with

$rose(%dclk)}
Note:
■ The expression name must be a new name. If you provide a name that conflicts with one
that already exists in the tool library, the tool errors out. See Chapter 6, “CDC App
Functional Checks” for additional information.
■ The scheme_type must be a valid one and must already be in the tool library.

5
CDC App Path Rule Configuration
This section provides information on the CDC App path rule set, the default values for each,
and command examples for changing the default behavior. It includes the following sections:
■ CDC Path Rules Overview on page 143
■ Modifying Path Rules on page 143
■ CDC Path Rule (Pair and Scheme) on page 144
■ Convergence and Reconvergence Rules (Group) on page 151
■ Reset Rules (Reset) on page 159
■ Configuration Rules (Config) on page 161

CDC Path Rules Overview

The CDC App path rules define the criteria for each crossing between source and destination
clock domains to ensure proper synchronization of the CDC signals. By default, the tool has
a value set for each rule, but during CDC App setup, you can change the values to specify
what the tool considers as violation criteria.
The CDC Configuration tab CDC Rules sub-tab displays the CDC App path rules and their
values (see Figure 5-1 on page 143).
Figure 5-1 CDC Rules Tab
The rules are divided into five categories as follows:

■ pair – Rules pertaining to CDC pairs
■ scheme – Rules pertaining to synchronization schemes
■ group – Rules pertaining to a group of signals involved in convergence or
reconvergence
■ reset – Rules pertaining to reset issues
■ config – Rules pertaining to configuration options
Modifying Path Rules

You can modify the default rule settings from the CDC App session using the check_cdc
-rule command:
check_cdc -check -rule -set {{rule_attribute attribute_value}+}

Note: For the full command syntax and details, type help check_cdc -gui on the
command line and navigate to the -check -rule command.
CDC Path Rule (Pair and Scheme)
CDC Pair Logic
Rule Type Pair

Description Specifies the logic type allowed on the CDC path
Possible Values wire | buf | logic | latch
wire – Allows no logic
buf – Allows buffers or inverters only
logic – Allows any logic
latch – Allows latches in the logic
Default Value buf
Example check_cdc -check –rule –set {{cdc_pair_logic
wire | buf | logic | latch}}
Figure 5-2 cdc_pair_logic


CDC Pair Fanout
Rule Type Pair

Description Specifies whether the CDC path can fanout to multiple
destinations
Possible Values true | false
true – Multiple fanouts allowed
false – Multiple fanouts not allowed
Default Value false
Example check_cdc -check –rule –set {{cdc_pair_fanout
true | false}}
Figure 5-3 cdc_pair_fanout

Minimum and Maximum DFFs
Rule Type Pair

Description n_min – Specifies the minimum number of DFFs in the
NDFF synchronizer
n_max – Specifies the maximum number of DFFs in the
NDFF synchronizer
n_max >= n_min
Note: Starting with the 2018.06 release, you can change
n_min and n_max rules for a specified crossing only. Consult
the full check_cdc command help for additional information
(help check_cdc -gui).
Possible Values Any integer value
Default Value min (2), max (3; must be equal to or greater than
n_min value )
Example check_cdc -check –rule –set {{n_min 2} {n_max
3}}
Figure 5-4 n_min <int> and n_max <int>

Synchronization Chain
Rule Type Scheme

Description Specifies the logic type allowed on the synchronization path
Default Value buf
Example check_cdc -check –rule –set
{{sync_chain_logic wire | buf | logic
| latch}}
Figure 5-5 sync_chain_logic

Same Clock Phase
Rule Type Scheme

Description Specifies whether all flops in the synchronizer are driven by
the same clock phase
true – Allows only same clock phase to drive all flops
false – Allows different clock phases to drive the
synchronizer flops
Default Value true
{{same_clock_phase true | false}}

Figure 5-6 same_clock_phase
Synchronization Path Fanout
Rule Type Scheme

Description Specifies whether multiple fanouts are allowed on the
synchronization path
true – Allows multiple fanouts
false – Does not allow multiple fanouts
Default Value false
{{sync_chain_fanout true | false}}

Figure 5-7 sync_chain_fanout
Convergence and Reconvergence Rules (Group)

Convergence is defined as a group of different signals converging into a combinatorial logic
in the destination clock after synchronization. Reconvergence is defined as different bits of
the same signal converging into a combinatorial logic in the destination domain after being
synchronized individually. See Figure 5-8 on page 152 and Figure 5-9 on page 152 for
illustrations of both scenarios.

Figure 5-8 Convergence
Figure 5-9 Reconvergence

The tool reports convergence and reconvergence issues in terms of CDC groups. A CDC
group consists of the flop after the combinatorial logic where the signals or bits converge and
the CDC pairs that converge.
The following rules apply to CDC groups (convergence and reconvergence structures):
Source Unit Domain
Rule Type Group

Description Configures whether the tool reports convergence from the
same source clock domain, from different source clock
domains, or from both
Possible Values diff | same | both
diff – Converging branches are reported from different
source clock domains only
same – Converging branches are reported from the same
source clock domain only
both – Converging branches are reported from both different
and same source clock domains
Default Value both
Example check_cdc -check –rule –set {{src_unit_domain
same | diff | both}}

Figure 5-10 src_unit_domain

Source Unit Signal
Rule Type Group

Description Specifies whether the converging signals come from the
same source signal (reconvergence), from different source
signals (convergence), or from both
Possible Values diff | same | both
diff – Converging branches come from different source
signals only
same – Converging branches come from the same source
signal only
both – Converging branches come from both different
source signals and the same source signal
Default Value both
Example check_cdc -check –rule –set {{src_unit_signal
same | diff | both}}
Figure 5-11 src_unit_signal

Depth
Rule Type Group

Description Specifies the number of flops in the destination domain until
the tool looks for (re-)convergence
Default Value 5
Example check_cdc -check –rule –set {{depth
<integer> }}
Figure 5-12 depth

MUX Convergence Check
Figure 5-13 mux_convergence_check
Rule Type Group

Description Specifies whether convergence or reconvergence problems
should be detected inside MUX_NDFF and MUX_PULSE
schemes
Default Value true
{{mux_convergence_check (true | false}}

Convergence Inside Control Synchronizers
Rule Type Group

Description Specifies whether the tool attempts to find convergence
issues inside control synchronizers
Default Value false
{{convergence_inside_ctrl_sync (true
| false}}
Figure 5-14 convergence_inside_ctrl_sync
Convergence
Convergence is is
reported in dout
reported if rule
in dout is set
if rule is to
true
set to true

Reset Rules (Reset)
Reset Minimum DFF
Rule Type Reset

Description Specifies the minimum number of flops in the reset
synchronizer
Default Value 2
Example check_cdc -check –rule –set {{reset_min_dff
3}}
Reset Synchronization Chain Logic
Rule Type Reset

Description Specifies the logic type allowed on the reset synchronization
path
Default Value buf
{{reset_sync_chain_logic wire | buf | logic
| latch}}

Reset Same Clock Phase
Rule Type Reset

Description Specifies whether all elements in the reset synchronizer are
driven by the same clock phase.
true – Allows only same clock phase to drive all flops
false – Allows different clock phases to drive the
synchronizer flops
Default Value true
{{reset_same_clock_phase true | false}}
Reset Pair Logic
Rule Type Reset

Description Specifies the logic type allowed on the reset path between
the reset synchronizer and the target flops
Default Value buf
{{reset_pair_logic wire | buf | logic
| latch}}

Configuration Rules (Config)
Multi-Mode Analysis
Rule Type Config

Description Specifies whether multi-mode analysis should be executed
KNOWN LIMITATIONS:
■ The tool does not detect equivalent modes that require
any equivalent logic support.
■ The tool might report internal signals for the identified
clock modes.
■ When the analysis does not reach a primary clock or
reaches more than one primary clock from the input of a
mux in the clock tree, the multi-mode analysis for that
muxed clock is interrupted. In this case, the tool handles
the muxed clock as a separate domain and issues a
warning.
Note: Multi-mode analysis is included as an initial release to
gather feedback from early adopters and finalize
implementation for an upcoming release. Contact
support@cadence.com to provide feedback or comments
true – Execute multi-mode analysis
false – Do not execute multi-mode analysis
Default Value false
{{multi_mode_analysis true | false}}

Apply Auto Waivers
Rule Type Config

Description Specifies whether the tool should automatically waive off
structural violations due to constant or static values handling
true – Automatically waive off structural violations due to
constant or static values handling
false – Do not automatically waive off structural violations
due to constant or static values handling
Default Value true
{{apply_auto_waivers true | false}}
FIFO Detection
Rule Type Config

Description Specifies whetherautomatic FIFO detection should be
executed
true – Execute automatic FIFO detection
false – Do not execute automatic FIFO detection
Default Value false
Example check_cdc -check –rule –set {{fifo_detection
true | false}}

Handshake Detection
Rule Type Config

Description Specifies whether automatic handshake detection should be
executed
true – Execute automatic handshake detection
false – Do not execute automatic handshake detection
Default Value false
{{handshake_detection true | false}}
NDFF Detection
Rule Type Config

Description Specifies whether automatic NDFF detection should be
executed
true – Execute automatic NDFF detection
false – Do not execute automatic NDFF detection
Default Value true
Example check_cdc -check –rule –set {{ndff_detection
true | false}}

NDFF_BUS Detection
Rule Type Config

Description Specifies whether automatic NDFF_BUS detection should be
executed
true – Execute automatic NDFF_BUS detection
false – Do not execute automatic NDFF_BUS detection
Default Value true
{{ndff_bus_detection true | false}}
MUX_NDFF Detection
Rule Type Config

Description Specifies whether automatic MUX_NDFF detection should
be executed
true – Execute automatic MUX_NDFF detection
false – Do not execute automatic MUX_NDFF detection
Default Value true
{{mux_ndff_detection true | false}}

Pulse Detection
Rule Type Config

Description Specifies whether automatic pulse detection should be
executed
true – Execute automatic pulse detection
false – Do not execute automatic pulse detection
Default Value true
Example check_cdc -check –rule –set {{pulse_detection
true | false}}
MUX_PULSE Detection
Rule Type Config

Description Specifies whether automatic MUX_PULSE detection should
be executed
true – Execute automatic MUX_PULSE detection
false – Do not execute automatic MUX_PULSE detection
Default Value true
{{mux_pulse_detection true | false}}

Edge Detection
Rule Type Config

Description Specifies whether automatic edge detection should be
executed
true – Execute automatic edge detection
false – Do not execute automatic edge detection
Default Value true
Example check_cdc -check –rule –set {{edge_detection
true | false}}
Automatic Scheme Detection
Rule Type Config

Description Specifies whether automatic scheme detection should be
executed.
true – Execute automatic scheme detection
false – Do not execute automatic scheme detection
Default Value true
{{automatic_scheme_detection true | false}}

Automatic Black Box Domain
Rule Type Config

Description Specifies whether the tool will try to automatically assign
clock domains to black-boxed outputs
true – Automatically assign clock domains to black-boxed
outputs
false – Do not automatically assign clock domains to
black-boxed outputs
Default Value true
{{automatic_bbox_domain true | false}}

Treat Boundaries as Unclocked
Rule Type Config

Description Specifies whether the tool will treat top inputs and outputs
and black-boxed inputs as unclocked units
Note:
■ Auto rating for top inputs considers only flops and rated
output ports when inferring the clock domain.
■ Heuristic clock assignment for inputs does not work with
resets.
true – Treat top inputs and outputs and black-boxed inputs
as unclocked units (pessimistic approach)
false – Associate top inputs and outputs and black-boxed
inputs with the clock connected to the flip-flop driving it
(optimistic approach)
Default Value false
{{treat_boundaries_as_unclocked true
| false}}

Strict NDFF Detection
Rule Type Config

Description Specifies whether the tool only detects NDFF schemes with
all flops in the same hierarchy
true – Attempt to detect NDFF schemes with all flops in
the same hierarchy
false – Does not attempt to detect NDFF schemes with all
flops in the same hierarchy
Default Value false
{{strict_ndff_detection true | false}}

Strict MUX Detection
Rule Type Config

Description Specifies whether MUX schemes can be detected only when
there is a single control signal, the signal is a synchronizer,
and there is no logic in the control path or in the feedback
loop
true – Detect MUX schemes only when there is a single
control signal, the signal is a synchronizer, and there is no
logic in the control path or in the feedback loop
false – Detect MUX schemes even when there is logic
between the control signal and MUX
Default Value false
{{strict_mux_detection true | false}}
Redundant Synchronizer
Rule Type Config

Description Specifies whether the tool attempts to find redundant
synchronizers for automatic NDFFs
Note: The tool reports redundant synchronization for
automatically detected NDFFs only and assumes that there
will be no combo logic between the sync flops of the second
synchronizer.
true – Attempt to find redundant synchronizers
false – Does not attempt to find redundant synchronizers
Default Value false
Example check_cdc -check –rule –set {{redundant_sync
true | false}}

Reset Redundant Synchronizer
Rule Type Config

Description Specifies whether the tool attempts to automatically report
the reset redundant synchronizer violation whenever it
identifies two reset synchronizers in the same reset path
during the reset schemes detection phase
Note: The tool reports redundant synchronization for
automatically detected NDFFs only and assumes that there
will be no combo logic between the sync flops of the second
synchronizer.
true – Attempt to find redundant synchronizers
false – Does not attempt to find redundant synchronizers
Default Value false
{{reset_redundant_sync true | false}}

Bus Convergence Detection
Rule Type Config

Description Specifies whether the tool attempts to find bus convergence
issues
Note: The bus_convergence_detection check is
included as an initial release to gather feedback from early
adopters and finalize implementation for an upcoming
release. Contact support@cadence.comto provide feedback
or comments targeting the upcoming production version.
true – Attempt to find bus convergence issues
false – Does not attempt to find bus convergence issues
Default Value false
{{bus_convergence_detection true | false}}

Reset Convergence
Rule Type Config

issues on the reset tree
Note: The reset_convergence check is included as an
initial release to gather feedback from early adopters and
finalize implementation for an upcoming release. Contact
true – Attempts to find convergence issues on the reset
tree
false – Does not attempt to find convergence issues on the
reset tree
Default Value false
{{reset_convergence true | false}}

Clock Convergence
Rule Type Config

issues on the clock tree
Note: The clock_convergence check is included as an
true – Attempts to find convergence issues on the clock
tree
clock tree
Default Value false
{{clock_convergence true | false}}

Clock Selector Convergence
Rule Type Config

issues on the selection path of a muxed clock
Note: The clock_selector_convergence check is
included as an initial release to gather feedback from early
adopters and finalize implementation for an upcoming
release. Contact support@cadence.com to provide feedback
or comments targeting the upcoming production version.
true – Attempts to find convergence issues on the
selection path of a muxed clock
selection path of a muxed clock
Default Value false
{{clock_selector_convergence true | false}}
Inactive CDC Pair
Rule Type Config

Description Specifies whether the tool generates violations for inactive
CDC pairs
true – Attempts to generate violations for inactive CDC
pairs
false – Does not attempt to generate violations for inactive
CDC pairs
Default Value false
{{inactive_cdc_pair true | false}}

Inactive Reset Pair
Rule Type Config

Description Specifies whether the tool generates violations for inactive
reset pairs
true – Attempts to generate violations for inactive reset
pairs
false – Does not attempt to generate violations for inactive
reset pairs
Default Value false
{{inactive_reset_pair true | false}}

Direct Reset Detection
Rule Type Config

Description Specifies whether the tool executes the automatic detection
of direct reset synchronizers
KNOWN LIMITATIONS:
■ The tool does not verify, either structurally or functionally,
the correct polarity of direct reset synchronizers.
■ Direct reset synchronizers are detected for declared
reset signals only.
Note: Direct reset synchronizer detection is included as an
true – Automatically detect direct reset synchronizers
false – Do not automatically detect direct reset
synchronizers
Default Value false
{{direct_reset_detection true | false}}

Automatically Waive RDC with NDFF
Rule Type Config

Description Specifies whether different_reset violations are
automatically waived for reset crossing paths that include an
NDFF.
true – Automatically waive different_reset violations
for reset crossing paths that include an NDFF.
false – Do not automatically waive different_reset
violations for reset crossing paths that include an NDFF.
Default Value true
{{autowaive_rdc_with_ndff true | false}}
Figure 5-15 autowaive_rdc_with_ndff
In the diagram above, a different_reset violation is reported between data -> d1.
With autowaive_rdc_with_ndff set to true (the default), the violation is automatically waived if the
NDFF (d1 and d2) found for this violation matches all of the following conditions:
. All flops are in the same clock domain (data, d1, d2, dout)
. NDFF has at least two flops
. NDFF flops does not have an asynchronous reset
. No logic is found between the NDFF flops
. No fanout is found for the NDFF flops
. dout reset signal is different from data reset signal

Automatically Waive Reset Clamp Pair Logic
Rule Type Config

Description Specifies whether the tool automatically waives a
cdc_pair_logic violation when the source and destination
flops have no reset, and the logic between them is an AND
gate with one input connected to a reset signal synchronous
to the destination flop domain and the other input connected
to a flop or primary input.
true – Automatically waive cdc_pair_logic violations in
the scenario described above
false – Do not automatically waive cdc_pair_logic
violations in the scenario described above
Default Value false
{{autowaive_reset_clamp_pair_logic true |
false}}

Automatically Waive Reset Clear Logic
Rule Type Config

Description Specifies whether the tool automatically waives
reset_pair_logic violations when the only logic present
in the reset path is due to the synthesis of preset and clear
pins of the flop.
Note: This rule must be enabled before elaboration or
automatic waivers are not created.
true – Automatically waive reset_pair_logic violations
in the scenario described above
false – Do not automatically waive reset_pair_logic
violations in the scenario described above
Default Value false
{{autowaive_reset_clear_logic true | false}}
Ignore Non-Resettable Flops
Rule Type Config

Description Specifies whether a destination flop that is non-resettable
should be considered a different_reset violation
true – Considers a non-resettable destination flop a
different_reset violation
false – Does not consider a non-resettable destination flop
a different_reset violation
Default Value false
{{ignore_non_resettable_flop true | false}}

Synchronize Clocks in Group
Rule Type Config

Description Specifies whether clocks that belong to the same clock group
should be considered synchronous.
true – Considers clocks in the same group synchronous
false – Does not consider clocks in the same group
synchronous
Default Value true
{{sync_clocks_in_group true | false}}

Show Expanded Clock Crossings
Rule Type Config

Description Specifies whether multiple clock domain crossings should be
reported for clocks with multiple roots.
With multi-clock reporting, there is no need to set the clock
mux select lines to a constant value. The tool analyzes the
design for all possible values of a clock mux select and
reports the CDC crossings in terms of all clock domain
crossings of their root clocks.
true – Reports multiple clock domain crossings for clocks
with multiple roots
false – Does not report multiple clock domain crossings for
clocks with multiple roots
Default Value true
{{show_expanded_clock_crossings true
| false}}

Non-Blocking Reset Control Logic
Rule Type Config

Description Specifies whether control logic in the reset path should be
considered non-blocking when defining the reset signal of a
flop while detecting RDC problems (different_reset
violations). Considering this logic (or not considering this
logic) affects the automatic waiver of RDC issues due to
reset order definition.
true – Consider control logic non-blocking. Only declared
resets are considered when identifying the reset of a flop.
false – Do not consider control logic non-blocking.
Default Value false
{{nonblocking_reset_control_logic true
| false}}
Use SDC Clock Period
Rule Type Config

Description Specifies whether the information provided by the SDC
-period switch on create_clock commands infers the
factor for clock declarations.
true – Use the information provided by the -period
switch to infer the factor for clock declarations.
false – Do not use the information provided by the
-period switch to infer the factor for clock declarations.
Default Value true
{{use_sdc_clock_period true | false}}

Add Stopat for Internal Constants
Rule Type Config

Description Specifies whether a global stopat should be created for
internal constant signals defined with check_cdc
-signal_config -add_constant.
true – Create a global stopat for internal constant signals
defined with check_cdc -signal_config
-add_constant
false – Do not create a global stopat for internal constant
signals defined with check_cdc -signal_config
-add_constant
Default Value false
{{add_stopat_for_internal_constants
true | false}}
Use RTL Constants Only for Glitch Simplification
Rule Type Config

Description Specifies whether the tool should use RTL constants only or
all constants in glitch simplification.
true – Use RTL constants only in glitch simplification.
false – Use all constants in glitch simplification.
Default Value false
{{use_rtl_constants_only_for_glitch_simplifi
cation true | false}}

6
CDC App Functional Checks
Functional analysis automatically generates CDC functional checks to identify transfer

source clock is properly captured by the destination clock without loss or corruption. The tool
generates functional checks based on the synchronizer type.
This chapter provides a description of functional checks generated for each of the supported
synchronizer schemes and includes information on the following:
■ Protocol Check Command Syntax on page 186
■ NDFF Checks on page 186
■ NDFF_BUS Checks on page 187
■ Pulse Checks on page 187
■ MUX_NDFF Checks on page 188
■ MUX_PULSE Checks on page 190
■ Handshake Checks on page 191
■ FIFO Checks on page 193
■ Glitch Protector Checks on page 197

Protocol Check Command Syntax

Use the following command syntax to generate and verify functional checks for all previously
detected CDC schemes:
check_cdc -protocol_check ( -generate
|-prove
|-export -file file_name
■ Use -generate to automatically create the properties.

■ Use -prove to validate the properties created.
■ Use -export to export the properties to a file.
Note:
■ Currently, the tool generates functional checks only for schemes that have no structural
violations.
■ Checks are based on property templates (see “Synchronizer Schemes” on page 15 for
related template diagrams.)
■ This section includes the basic syntax only. Type help check_cdc -gui on the
command line to see the full check_cdc command syntax.
NDFF Checks
Checks of NDFF synchronizers ensure control signal stability (data_stable). This type of
functional check confirms that the signal from the source clock domain remains stable long
enough to be captured properly in the destination clock domain. The data stability property
samples the destination clock on the posedge or negedge.
Figure 6-1 on page 187 shows the correct behavior of a stable signal, and Figure 6-2 on
page 187 shows the incorrect behavior.

Figure 6-1 Data Stability - Correct Behavior
Figure 6-2 Data Stability - Incorrect Behavior
NDFF_BUS Checks
Checks of NDFF_BUS synchronizers generate the same property as NDFF checks, that is,
the data_stable property (see “NDFF Checks” on page 186). In addition, NDFF_BUS
checks generate properties to verify that NDFF_BUS schemes are properly gray encoded.
These properties are identical to the write pointer gray encoding protocol checks generated
for FIFOs. See “FIFO Checks” on page 193 for additional information.
Pulse Checks
Checks of pulse synchronizers ensure data stability as follows:
■ Data stability (data_stable_pulse) – Checks that the signal from the source clock
domain remains stable long enough to be captured properly in the destination clock
domain
■ Pulse width (input_pulse_single_cycle) – Checks that the input pulse is always
one source-clock cycle wide

■ Pulse width (output_pulse_single_cycle) – Checks that the output pulse is always

one source-clock cycle wide
Figure 6-3 on page 188 shows the correct behavior of an input pulse synchronizer, and
Figure 6-4 on page 188 shows the incorrect behavior.
Figure 6-3 Input Pulse Sync – Correct Behavior
Figure 6-4 Input Pulse Sync – Incorrect Behavior
MUX_NDFF Checks
Checks of MUX_NDFF synchronizers ensure control or data path stability.
■ Control path stability (sready_stable): Functionally checks that the mux select signal
from the source clock domain remains stable long enough to be captured properly in the
destination clock domain.
Figure 6-5 on page 189 shows the correct behavior of sready_stable, and Figure 6-
6 on page 189 shows the incorrect behavior.
■ Data path stability (datapath_stable): Functionally checks that the data remains
stable in the destination clock domain during the data transfer phase. The tool generates
one datapath_stable property for each path between the source and destination. If
the same source signal goes through different paths to the same destination, the tool

generates one property for the path. If multiple sources go to the same destination
through a MUX scheme, the tool generates one property for each source. The first
property is named <mux_name>_datapath_stable, and subsequent properties
include a suffix with a number, for example, <mux_name>_datapath_stable_1,
<mux_name>_datapath_stable_2, ...,
<mux_name>_datapath_stable_n.
Figure 6-7 on page 189 shows the correct behavior of a datapath_stable, and
Figure 6-5 Control Path Stability – Correct Behavior
Figure 6-6 Control Path Stability – Incorrect Behavior
Figure 6-7 Data Path Stability – Correct Behavior

Figure 6-8 Data Path Stability – Incorrect Behavior
MUX_PULSE Checks
Checks of MUX_PULSE synchronizers ensure control or data path stability.
■ Control path stability (sready_stable): Functionally checks that the mux select signal
from the source clock domain remains stable long enough to be captured properly in the
■ Data path stability (datapath_stable): Functionally checks that the data remains
stable in the destination clock domain during the data transfer phase.
Figure 6-9 on page 190 shows the correct behavior of a MUX pulse data path, and
Figure 6-9 MUX Pulse Data Path – Correct Behavior

Figure 6-10 MUX Pulse Data Path – Incorrect Behavior
Handshake Checks
Checks of handshake-based synchronizers ensure request-acknowledgment stability or data
stability during transfer.
■ Request and acknowledgment stability (sreq_stable, dack_stable): Functionally
checks that the request (acknowledgment) signal from the source (destination) clock
domain remains stable long enough to be captured properly in the destination (source)
clock domain.
See Figure 6-11 on page 191 for the correct behavior of a request and Figure 6-12 on
page 192 for both the correct and incorrect behavior of dack_stable.
■ Data stability during transfer (data_stability_dest): Functionally checks that the
data from the sender remains stable until it receives an acknowledgment from the
receiver.
See Figure 6-13 on page 192 for the behavior of data_stability_dest when not
captured and when captured correctly.
Figure 6-11 Request – Correct Behavior

Figure 6-12 Acknowledgment – Correct and Incorrect Behavior
Figure 6-13 Data Stability During Transfer
Handshake Protocols
The tool observes the following handshake protocols:
■ Functionally checks that the sender continues to assert the request signal until it receives
an acknowledgment from the receiver (src_req)
■ Functionally checks that the sender does not send a new request until the
acknowledgment for the previous transfer has been de-asserted (src_new_req)
The receiver should continue to assert the dack signal until dreq is asserted at the
destination clock (dclk) domain.

The receiver should not assert a new acknowledgment dack until a new request is
received in the destination clock (dclk) domain.
■ Functionally checks that the receiver continues to assert the acknowledgment until the
request is de-asserted at the destination clock domain (dest_conformance_req)
■ Functionally checks that the receiver does not assert a new acknowledgment until a new
request is received (dest_conformance_new_req
Also see Figure 6-14 on page 193 and Figure 6-15 on page 193.
Figure 6-14 Handshake Protocol Conformance Source – Correct Behavior
Figure 6-15 Handshake Protocol Conformance Destination – Correct Behavior
FIFO Checks
Checks of FIFO-based synchronizers ensure FIFO full and empty status generation and gray-
encoding of read and write pointers.
■ Write/Read pointer stability (wptr_stable, rptr_stable): Functionally checks that
the FIFO writer/read pointer value remains stable long enough to be captured correctly
in the destination domain
Figure 6-16 on page 194 shows the correct behavior of wptr_stable, and Figure 6-17
on page 194 shows the incorrect behavior.

Figure 6-18 on page 195 shows the correct behavior of rptr_stable, and Figure 6-19
■ No write on FIFO full condition (no_write_on_full): Functionally checks that there is
no write to the FIFO when it is full
Figure 6-20 on page 195 shows the correct behavior of no_write_on_full, and
■ No read on FIFO empty condition (no_read_on_empty): Functionally checks that there
is no read from the FIFO when it is empty
Figure 6-22 on page 196 shows the correct behavior of no_read_on_empty, and
■ Write/Read pointer gray encoding check (wptr_gray_coded, rptr_gray_coded):
Functionally checks that the FIFO pointers are gray encoded (only one bit changes at a
time)
Figure 6-24 on page 197 shows the correct behavior of wptr_gray_coded, and
Figure 6-25 on page 197 shows the correct behavior of rptr_gray_coded.
Figure 6-16 Write Pointer Stability – Correct Behavior
Figure 6-17 Write Pointer Stability – Incorrect Behavior

Figure 6-18 Read Pointer Stability – Correct Behavior
Figure 6-19 Read Pointer Stability – Incorrect Behavior
Figure 6-20 No Write on Full – Correct Behavior

Figure 6-21 No Write on Full – Incorrect Behavior
Figure 6-22 No Read on Empty – Correct Behavior
Figure 6-23 No Read on Empty – Incorrect Behavior

Figure 6-24 Write Pointer Gray Encoded – Correct Behavior
Figure 6-25 Read Pointer Gray Encoded – Correct Behavior
Glitch Protector Checks

Checks of glitch_protector synchronizers ensure control and data path stability.
■ Control path stability (data_stable): Confirms that the signal from the source clock
domain remains stable long enough to be captured properly in the destination clock
domain.
Figure 6-26 on page 198 shows the correct behavior of a stable signal, and Figure 6-27
■ Data path stability (datapath_stable_glitch): Functionally checks that the data
remains stable in the destination clock domain during the data transfer phase.
Figure 6-28 on page 198 shows the correct behavior of a datapath_stable_glitch,
and Figure 6-29 on page 199 shows the incorrect behavior.

Figure 6-26 Data Stability - Correct Behavior
Figure 6-27 Data Stability - Incorrect Behavior
Figure 6-28 Data Path Stability (Glitch) – Correct Behavior
control
control

Figure 6-29 Data Path Stability (Glitch) – Incorrect Behavior
control Data changing while control is asserted

7
Debugging CDC Violations
This chapter provides information on debugging CDC violations and includes the following
sections:
■ CDC Violations Overview on page 201
■ CDC Debugging Environment on page 203
■ Addressing CDC Violations on page 207

CDC Violations Overview

The CDC App finds and reports violations during every phase of clock domain crossing
analysis. The Review Violations pane provides a consolidated list of all violations reported
in all CDC phases. The Checks tab organizes the violations by CDC phase, and the Hier
Groups tab organized violations by hierarchy based on source and destination instances.
For the Checks tab, the violation tree on the left displays the phase in which the violation
occurred and the Check column shows the rule or property that was violated (Figure 7-1 on
page 201). Open the debugging environment by right-clicking on any of the rows and
selecting Debug Violation. This menu option is context-specific and opens the appropriate
debugging views for the corresponding violation type.
To filter noise, CDC generates single no_scheme and cdc_pair_logic violations by

destination and single cdc_pair_fanout violations by source. The # Pairs column of the
Review Violations table shows the number of CDC pairs related to each violation.
Additionally, cdc_pair_logic violations are created only when glitch_check violations
will not be, that is, when the destination has only one source from a different domain.
Figure 7-1 Review Violations Table (Checks Tab)
For the Hier Groups tab, the violation tree on the left groups pair and reset violations by
hierarchy based on source and destination instances (Figure 7-2 on page 202). Click on a
group to display that group’s violations in the table to the right. Violations other than pair and
reset violations are reported as ungrouped.

Figure 7-2 Review Violations Table (Hier Groups Tab)
Structural Violations
The tool reports structural violations in three sub-tabs of the CDC Phases tab, Pairs,
Schemes, and Convergence. In the tables of these three sub-tabs, a red icon in the status
column marks a violation. For Pairs and Schemes tables, the tool reports the violated rule
in the Violation column. To debug a violation, do the following:
1. Click on a pair, scheme, or convergence violation in the Review Violations tree.
This shows a list of the specified violations in the Review Violations table (see Figure 7-
1 on page 201).
2. Right click on a check in the Review Violations table and choose Debug Violation.
Functional Violations
The tool reports functional violations in the Functional sub-tab of the CDC Phases tab. A
red cross in the status column indicates a CDC functional check violation. To debug a
violation, do the following:
1. Click on a functional violation in the Review Violations tree.
This shows a list of the specified violations in the Review Violations table.

Metastability Violations
Metastability violations occur when user-defined properties fail after the tool injects
metastability. Like functional violations, these violations are indicated with a red cross. To
debug a violation, do the following:
1. Click on Metastability in the Review Violations tree.
This shows a list of violations in the Review Violations table.
Reset Violations
Reset violations occur when 1) there is a clock crossing through the reset path or 2) there is
a reset crossing even though the flops are in the same clock domain. To debug a violation, do
the following:
1. Click on a reset violation in the Review Violations tree.
This shows a list of the specified violations in the Review Violations table.
CDC Debugging Environment

The CDC App provides an advanced debugging environment where multiple debugging
views, such as schematic, graph, waveform, and source code browser, are integrated
together for an enhanced debugging experience. The Debug Violations context-menu
option in the Review Violations table opens a debugging view suitable for the particular
violation type. For example, any structural violation is best debugged using the schematic
viewer. Thus, CDC opens an integrated schematic+graph to facilitate the debugging process.
Debugging Structural Violations

When you choose Debug Violation on a structural violation in the Review Violations table,
the tool opens a schematic+graph view for debugging (Figure 7-3 on page 204). While the
schematic view shows the relevant section of the design related to the violation, the graph
shows an abstracted view of the same logic. Both views are updated automatically based on
any additional information plotted on either side. A CDC Violation Info pane at the top of the
schematic plus graph window shows all violation-related information. Use the context-menu
of either view to perform various actions, for example, view fanin or fanout and open the
source code browser.

Note: The CDC Schematic Viewer is disabled for convergence violations with greater than
1000 signals. For these violations, CDC opens the graph only.
Figure 7-3 Schematic+Graph

Debugging Structural Violations with More than One Associated CDC Pair
When you choose Debug Violation on a convergence or pair violation in the Review
Violations table, the tool opens a schematic+graph view for debugging that automatically
loads the signals related to the first CDC pair only (Figure 7-4 on page 205). At the bottom of
the schematic is a table with the source and destination unit, source and destination domain,
and status of all CDC pairs in the violation. You can add signals related to any CDC pair by
right-clicking on a signal in this table and choosing Add to schematic. You can also remove
all signals from the schematic by right-clicking and choosing Clear schematic or add all
signals at once by right-clicking and choosing Add all to schematic. When applicable, the
CDC graph shows only the nodes related to the CDC pair.
Figure 7-4 Schematic for Violations with More than One Associated Pair

Debugging Functional Violations

When you choose Debug Violation on a functional violation in the Review Violations table,
the tool opens a Visualize window, providing a waveform-based debugging environment
(Figure 7-5 on page 206). With Visualize, you can do various What if analyses, and since
Visualize is coupled with a source browser, signals can be plotted to the waveform from the
source browser.
Figure 7-5 Functional Violation Debugging
Debugging Metastability Violations

When you choose Debug Violation on a metastability violation in the Review Violations
table, the tool opens the debugging environment for analyzing property failures due to
metastability injection (Figure 7-6 on page 207). This debugging environment is the same as
the functional violation debugging environment discussed above, but it includes additional
customization for metastability related information. To facilitate the debugging process, the
tool highlights the signals that have been affected due to metastability with red in specific
clock cycles. This helps you concentrate on specific cycles for the root cause analysis.

Figure 7-6 Metastability Debugging
Addressing CDC Violations

This sections discusses some common violations reported by the CDC App and provides
possible courses of action for addressing them. It also outlines the consequences of not fixing
a violation.
Note:
■ See Table 7-1 on page 222 for a list of all possible violations.
■ See Chapter 5, “CDC App Path Rule Configuration” for information on changing the
default behavior of path rules.

Configuration-Related Violations
Reported Violation unclocked_signal

Consequence of not This violation indicates that the signal is not associated with
fixing this violation any clock signal. The tool considers it an independent clock
domain and all connections are reported as clock domain
crossings. This leads to added noise in CDC pairs reported
by the tool.
Possible courses of If the signal is an asynchronous signal, you can ignore this
action violation. The signal will be considered a separate clock
domain in itself and will be reported as a clock domain
crossing.
If the signal is not an asynchronous signal and it is either a
primary input or output of a black-boxed module, you can
associate it with the appropriate clock signal by using the
command check_cdc -clock_domain -port
<signal_name> -clock_signal <clock_signal>.
If the signal is not an asynchronous signal and it is either a
primary output or input of a black-boxed module, you can
associate it with the appropriate clock signal by using the
command check_cdc -clock_domain -port
<signal_name> -clock_signal <clock_signal>.

Signal Configuration Violations
Reported Violation static_signal

Consequence of not This violation indicates a signal you declared as static is
fixing this violation actually not static in the design. This can lead to glitches or
convergence violations in the design.
Possible courses of To debug, right-click on the failing row and select See
action Violations to go to the Review Violations table. Then
select Debug Violation by right-clicking on the violation you
want to debug. This brings up the Visualize waveform based
debug window.
Investigate the reasons the signal is not static.
If the signal is not expected to be static as per the design,
remove the corresponding signal configuration.
If the signal is supposed to be static, but the current design
allows it to toggle, fix the RTL.

Pair Violations
Reported Violation cdc_pair_logic

Consequence of not If this violation is not fixed, the combinatorial logic may
fixing this violation produce glitches in the design.
Possible courses of To debug, double-click on the row containing the violating
action pair to open the schematic+graph integrated view.
Check the clock setup.
If the source signal is reconverging at the destination through
multiple paths, try to modify the design to make it a single
path.
Check if any of the source signals are quasi-static. You can
specify this in the configuration phase.
Modify the path rule for this particular path or for all the paths
in the design to allow the logic present on the crossing path.
Waive the violation if you know that there is no possibility of
glitch due to this logic. The signals are quasi-static or they
might not be toggling at the same time. To waive, right-click
on the row in the Violation tab and select Waive.

Reported Violation cdc_pair_fanout

Consequence of not If this violation is not fixed, there can be coherency issues in
fixing this violation the design due to the unequal delay in the synchronizers in
the fanout branches.
Possible courses of To debug, double click on the row containing the violating
Check the clock setup.
If the fanout branches are converging after synchronization,
try to modify the design to synchronize the source signal first
before creating a fanout to multiple points in the destination
domain.
You can modify the path rule to allow fanout of this particular
crossing path or all crossing paths.
You can waive the violation if you are confident that the
unequal delay due to synchronization in the different
branches is not going to cause any coherency issue.

Reported Violation no_scheme

Consequence of not If this violation is not fixed, metastable values can propagate
fixing this violation through the design and the data from the source domain may
not be properly captured in the destination domain.
Check the source and destination clock setup.
Based on the source or destination clock frequency ratio, if
the number of flops is sufficient, you can modify the path rule
to reduce the minimum number of flops in the NDFF for this
path. The tool will no longer report it as a violation.
If the design is not following the minimum number of flops in
a NDFF for this path, modify the design to match the n_min
requirement.
number of flops used in the NDFF for this path is sufficient.

Scheme Violations
Reported Violation sync_chain_logic

Consequence of not If this violation is not fixed, the combinatorial logic on the
fixing this violation synchronizer chain can cause glitches in the design.
If the combo logic is not required on the sync chain, modify
the design to remove it.
If the combo logic is necessary, modify the path rule to allow
combo logic for this path.
Waive the violation if you are confident that the combo logic
is not going to cause any glitch in the design.

Reported Violation same_clock_phase

Consequence of not By default, all flops in the synchronizer are expected to be
fixing this violation triggered by the same clock edge. If this violation is not fixed,
there can be clock phase difference between the
synchronizer flops and the destination instance to which the
synchronized signal is connected.
Check the destination clock setup.
If the NDFF is not supposed to work as a half synchronizer,
you should modify the design to make all sync flops to trigger
at the same clock edge.
If the NDFF is supposed to work as a half synchronizer,
modify the path rule to allow different clock edges to trigger
different sync flops for this path by setting
same_clock_phase to false.
NDFF is supposed to work as a half synchronizer.

Reported Violation sync_chain_fanout

Consequence of not A divergence of the metastable signal can cause functional
fixing this violation errors. Due to different settling times in the flops, the outputs
of the two branches can come out in different cycles causing
a functional error.
In general, it is inadvisable to fanout the metastable signal to
multiple places in the design. You should synchronize the
signal first before it fans out to other parts of the design.
If you are confident that the fanout of the metastable signal
will not cause any functional issue due to the unequal delay
in different branches, you can allow the fanout by setting the
sync_chain_fanout rule to true.
Waive the violation if you are confident that the fanout of the
metastable signal will not cause any functional error.

Reported Violation n_min

Consequence of not This violation is reported when the NDFF synchronizers on
fixing this violation the control paths of Mux, handshake, or FIFO synchronizers
do not meet the minimum number of flops. This can cause
metastable data to flow through the design resulting in
functional failures.
the number of flops is sufficient, you can modify the path rule
to reduce the minimum number of flops in the NDFF for this
path.
If the design is not following the minimum number of flops in
an NDFF for this path, modify the design to match the n_min
requirement.
Waive the violation if you are confident that the number of
flops used in the NDFF for this path is sufficient.

Reported Violation n_max

Consequence of not This violation is reported when the NDFF synchronizers on
fixing this violation the control paths of Mux, handshake or FIFO synchronizers
have more than the maximum number of flops allowed by the
n_max rule. This might lead to additional latency and timing
issues in the design.
the number of flops in the NDFF is correct, modify the path
rule to increase the maximum number of flops in the NDFF
for this path.
If the design is not following the maximum number of flops in
a NDFF for this path, modify the design to match the n_max
requirement.
Waive the violation if you are confident that the number of
flops used in the NDFF for this path is correct.

Reported Violation constant_scheme

Consequence of not This violation indicates that the data path or control path of
fixing this violation the synchronizer is constant. This can lead to no
synchronization or passing the unstable data through the
synchronizer.
Possible courses of To debug, double-click on the row containing the violation to
action open the schematic+graph integrated view.
Check the control or data path reported as constant by the
tool. If the signal is not supposed to be constant, investigate
the reason and fix the RTL
If this signal is expected to be constant, declare it as part of
the signal configuration.
Waive the violation if the signal is expected to be constant
and you don't want to declare it as a signal configuration.
Reported Violation bus_gray_coded

Consequence of not This violation is reported when a bus synchronized using a
fixing this violation NDFF_BUS synchronizer (each bit synchronized individually)
is not gray encoded. If this violation is not fixed, it can result
in data-coherency issues due to random delay in
synchronization of each individual bits.
Possible courses of To debug, double-click on the row containing the violation in
action the Violations table or right-click and select Debug
Violation. This opens the Visualize waveform view. The
waveform shows a counterexample explaining why the bus is
not gray encoded.
■ If the bus is supposed to be gray encoded, investigate
why the bus is not behaving as gray encoded in the
Visualize waveform window.
■ If the bus is not gray encoded, you can add gray encoding
logic in the design.
■ If you are confident that there will be no data coherency
issue with the bus, you can waive the violation.

Convergence Violations
Reported Violation Structural glitch

Consequence of not The tool reports this violation if it finds combinatorial logic on
fixing this violation the CDC signal. The logic on the CDC path can cause
glitches in the design.
Possible courses of To debug, double-click on the row containing the violation or
action to open the schematic+graph integrated view.
If the source signal is reconverging at the destination through
multiple paths, try to modify the design to make it a single
path.
Check if any of the source signals are quasi-static. You can
specify this in the configuration phase.
Modify the path rule for this particular path or for all the paths
in the design to allow the logic present on the crossing path.
Waive the violation if you know that there is no possibility of a
glitch due to this logic. The signals might be quasi-static or
they might not be toggling at the same time.

Reported Violation Convergence

Consequence of not Convergence happens when a group of signals from same or
fixing this violation different source clock domains after synchronization
converge into a combinatorial logic before or after sequential
elements in the destination clock domain. This can cause
data coherency issues in the design and lead to functional
failures.
If the convergent branches are synchronized by NDFF
schemes, consider replacing the synchronization schemes
with Mux, handshake, or FIFO type schemes.
Convergence will not cause a data coherency issue if one of
the following conditions is true. In that case, you can waive
the violation:
■ If all but one branch are static signals
■ If the signals cannot toggle at the same time
■ If the convergent branches are gray encoded
■ If more than one path cannot functionally control the
converging net.

Reported Violation Reconvergence

Consequence of not Reconvergence happens when different bits of the same
fixing this violation signal after being synchronized individually converge into a
combinatorial logic before or after sequential elements in the
destination domain. This can cause data coherency issues in
the design leading to functional failures.
If the signal is a data signal and individual bits are
synchronized using an NDFF scheme, consider replacing the
synchronizer scheme with Mux, handshake, or FIFO
schemes.
The reconvergence will not cause a data coherency issue if
one of the following conditions is true. In that case, you can
waive the violation:
■ If all but one branch (bits) are static
■ If only one bit cannot toggle at the same time
■ If the signal is gray encoded
Reset Violations
Reported Violation different_reset

Consequence of not Connected flops in the same clock domain are driven by
fixing this violation different asynchronous reset signals. As a result, if the reset
connected to the first flop is asserted very close the active
clock edge, it can cause the second flop to go metastable
causing functional errors in the design.
action pair to open the schematic view.
Check if there is any reset priority defined between the two
reset signals, which ensures that the first one does get
asserted when the second one is not asserted.
Fix the RTL to drive both the flops with the same reset signal.

Reported Violation reset_sync_chain_logic

Consequence of not If this violation is not fixed, the combinatorial logic on the
fixing this violation synchronizer chain might produce glitches in the design.
Possible courses of To debug, double-click on the row containing the violation in
action the Violations table or right-click and select Debug
Violation. This opens the schematic view.
If the combinatorial logic is not required on the sync chain,
modify the design to remove it.
If the combinatorial logic is necessary, modify the path rule to
allow it for this path. See Chapter 5, “CDC App Path Rule
Configuration” for additional information.
Full List of Violations

This section provides a table of all possible violations (Table 7-1 on page 222).
Note: You can access additional this information from the tool by hovering over the rule type
under the Check column of the Violations table to view the tool tip. The tool tip also provides
information on addressing the violation.
Table 7-1 CDC Violations
Configuration Checks Severity Description

unclocked_signal Error Check if the signal is not associated with any
clock.
constant_clock Warning Check if the clock domain analysis attempts to
process clocks set as constants (that is, inactive
clocks).
clock_not_declared Error Check if a primary input is declared as clock.
static_signal Error Check if the signal declared as static is really
static.


gray_coded_signal Error Check if a signal declared as gray encoded is
actually gray encoded.
exclusive_signal Error Check if a signal declared as exclusive is actually
exclusive.
clock_selector_convergence
Warning Check whether the tool generates violations for
MUX gates with unconstrained select pins in the
clock path. This rule is disabled by default.
Synchronization Checks Severity Description

no_scheme Error Pair has not been synchronized.
cdc_pair_logic Error Specifies the logic type allowed in the CDC path.
The default is buf. Other valid options are wire,
logic, and latch.
cdc_pair_fanout Error Specifies whether a CDC path can fanout to
multiple destinations, including scenarios in
which a single bit from the CDC source fans out
to multiple bits of the same CDC destination
signal. The default is false.
n_min Error Specifies the minimum number of DFFs in the
NDFF synchronizer. The default is 2.
n_max Error Specifies the maximum number of DFFs in the
NDFF synchronizer (must be equal to or greater
than the n_max value).
sync_chain_logic Error Specifies the logic type allowed in the
synchronizer path. The default is buf. Other valid
options are wire, logic, and latch.
same_clock_phase Error Specifies whether all elements in the
synchronizer are driven by the same clock phase.
The default is true.
sync_chain_fanout Error Specifies whether fanouts are allowed in the
CDC path or the synchronizer chain. The default
is false.
redundant_sync Error Check if a CDC pair is synchronized more than
once in the same clock domain.


valid_sync_enabler Error Checks if sync_enabler signal belongs to the
destination domain and is either constant, static
or properly synchronized by a control scheme of
type pulse, edge, or NDFF.
async_input Error Check that the control signal and data signal of a
glitch protector synchronizer belong to the same
source clock domain.
async_output Error Check that the control signal and data signal of a
glitch protector synchronizer belong to the same
inactive_cdc_pair Error Specifies whether the tool generates violations
for inactive CDC pairs. The default is false.
latch_cdc Error Checks whether latches are being driven by units
from different domains, but does not report a
violation when different domains come from a
constant or static path.
Convergence Checks Severity Description

glitch_check Error Check if there is convergence in the source
domain which can cause glitches.
convergence_check Error Check if there is a convergence of multiple paths
from same or different source clock domains after
synchronization.
reconvergence_check Error Check if there is a convergence of multiple bits of
the same vector signal after synchronization.
bus_convergence_detection
Error Check if there are bus convergence issues.
clock_convergence Error Check if there are convergence issues on the
clock tree.
clock_selector_convergence
Error Check if there are convergence issues on the
selection path of a muxed clock.

Functional Checks Severity Description

data_stable Error Functionally checks if the signal from the source
clock domain remains stable long enough to be
captured properly in the destination clock
domain.
rptr_stable Error Functionally checks if the FIFO read pointer
value remains stable long enough to be captured
correctly in the destination domain.
wptr_stable Error Functionally checks if the FIFO write pointer
value remains stable long enough to be captured
correctly in the destination domain.
data_stable_pulse Error Functionally checks if the signal from the source
clock domain remains stable long enough to be
captured properly in the destination clock
domain.
datapath_stable Error Functionally checks if the data remains stable in
the destination clock domain during the data
transfer phase.
src_req_hold Error Functionally checks if that the sender continues
to assert the request signal until it receives an
acknowledgment from the receiver.
src_new_req Error Functionally checks if that the sender should not
send a new request until the acknowledgment for
the previous transfer has been de-asserted.
dest_ack_hold Error Functionally checks if the receiver continues to
assert the acknowledgment until the request is
de-asserted at the destination clock domain.
dest_new_ack Error Functionally checks if the receiver does not
assert a new acknowledgment until a new
request is received.
data_stability_dest Error Functionally checks if the data from the sender
remains stable until it receives an
acknowledgment from the receiver.
no_write_on_full Error Functionally checks if there is no write to the
FIFO when it is full.


no_read_on_empty Error Functionally checks if there is no read from the
FIFO when it is empty.
p_wptr_gray_coded Error Functionally checks if the FIFO write pointers are
gray encoded (only one bit changes at a time).
p_rptr_gray_coded Error Functionally checks if the FIFO read pointers are
gray encoded (only one bit changes at a time).
bus_gray_coded Error Check if a bus synchronized using a NDFF_BUS
synchronizer is gray encoded.
input_pulse_single_cycle
Error Functionally checks if the input of the pulse
synchronizer is one source clock wide.
output_pulse_single_cycle
Error Functionally checks if the output of the pulse
synchronizer is one destination clock wide.
output_pulse_single_cycle_mux
Error Functionally checks if the output of the pulse
synchronizer is one destination clock wide.
pulse_toggle_circuit Error Functionally checks if the toggle circuit works
properly.
Error Checks that the datapath in a glitch protector
remains stable while the enable signal is
asserted.
incomplete_scheme_property
Error Check if all the functional protocol checks for the
synchronizer have been generated.
undeclared_clock Error Generated when a block-level clock is not driven
by a declared clock in the SoC level.
unmatched_clock_factor
Error Generated when the block-level clock has a
different factor or different base clock in the SoC
level.


pending_sync Error Check if a port has become unsynchronized in
the block level and is not properly synchronized
in the SoC level.
Metastability Checks Severity Description

metastability_check Error Check if a user-defined property has failed due to
metastability injection.
injection_failure Error Check if metastability injection is successful.
Reset Checks Severity Description

no_reset_scheme Fatal Reset pair has not been synchronized.
reset_sync_chain_logic
Error Check whether there is combinational logic on
the sync chain.
reset_same_clock_phase
Error Specifies whether all elements in the reset
synchronizer are driven by the same clock phase.
The default is true.
reset_min_dff Error Check if the reset synchronizer meets the
minimum number of flops specified. The default
is 2.
reset_same_driver Error Check if flops of reset synchronizers have the
same reset.
reset_source_driver Error Check if the reset signal of a reset synchronizer
is declared as reset.
reset_pair_logic Error Specifies the logic type allowed in the reset
synchronizer path. The default is buf. Other valid
options are wire, logic, and latch.
reset_sync_domain Error Check if a flop clock domain is synchronous to
the clock domain of the reset synchronizer
driving it.
reset_redundant_sync Error Check if a RDC path from the source clock
domain is synchronized more than once in the


reset_fanout Error Check if a reset signal is synchronized to one
clock domain by more than one reset
synchronizer.
different_reset Error Check if the connected flops are connected to
different async reset inputs.
reset_convergence Error Check if there are convergence issues in the
reset tree during reset analysis.
inactive_reset_pair Error Specifies whether the tool generates violations
for inactive reset pairs. The default is false.
reset_in_data_path Error Specified whether the tool generates violations
when a reset signal is connected in the data pin
of one or more flops.
no_reset_definition Error Specifies whether the tool generates violations
when no reset definition drives the module ports
defined as resets during IP-level analysis.
unmatched_reset_type Error Specifies whether the tool generates violations
when the reset definition driving the module ports
defined as resets during IP-level analysis are of a
different type.
unmatched_reset_clock
Error Specifies whether the tool generates violations
when the reset definitions driving the module
ports defined as resets during IP-level analysis
rated on a different clock.
unmatched_reset_polarity
Error Specifies whether the tool generates violations
when the reset definitions driving the module
portsdefined as resets during IP-level analysis
have a different polarity.


jasperCDC

Uploaded by

Copyright:

Available Formats

You might also like

jasperCDC

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

jasperCDC

Uploaded by

Copyright:

Available Formats

JasperGold Clock Domain Crossing

Verification App User Guide

Liberty™ is a trademarks of Synopsys®, Inc. in the U.S. and/or other countries.

September 2019 3 Product Version 2019.09

September 2019 4 Product Version 2019.09

Automatic Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

September 2019 5 Product Version 2019.09

Reset Minimum DFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

September 2019 6 Product Version 2019.09

Use SDC Clock Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

September 2019 7 Product Version 2019.09

Reset Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

September 2019 8 Product Version 2019.09

September 2019 9 Product Version 2019.09

Who Should Read this Guide

How This Guide Is Organized

September 2019 10 Product Version 2019.09

September 2019 11 Product Version 2019.09

Conventions Used in JasperGold Apps Documents

Table 1-1 JasperGold Apps Syntax Conventions

September 2019 12 Product Version 2019.09

Table 1-2 JasperGold Apps Text Conventions

September 2019 13 Product Version 2019.09

September 2019 14 Product Version 2019.09

This section briefly summarizes automatically-detected and user-defined schemes and

September 2019 15 Product Version 2019.09

Figure 1-1 NDFF Template

September 2019 16 Product Version 2019.09

MUX_NDFF and MUX_PULSE

September 2019 17 Product Version 2019.09

Figure 1-2 MUX_NDFF Templates

September 2019 18 Product Version 2019.09

Figure 1-3 MUX_PULSE Templates

Handshake synchronization is a closed-loop synchronization method that requires

September 2019 19 Product Version 2019.09

Figure 1-4 Handshake Template

September 2019 20 Product Version 2019.09

Figure 1-5 FIFO Template

September 2019 21 Product Version 2019.09

Figure 1-6 Pulse Template

Figure 1-7 Rising Edge Active High Template

September 2019 22 Product Version 2019.09

Figure 1-8 Rising Edge Active Low Template

Figure 1-9 Falling Edge Active High

Figure 1-10 Falling Edge Active Low

September 2019 23 Product Version 2019.09

check_cdc –scheme –add glitch_protector –module <module_name> -map

September 2019 24 Product Version 2019.09

Figure 1-11 Glitch Protector Synchronizer

check_cdc –scheme –add sync_enabler –map {{enable <enable_signal>}

September 2019 25 Product Version 2019.09

Figure 1-12 Synchronization Enabler

check_cdc -scheme -add reset -module <module_name> -map {{Srst

September 2019 26 Product Version 2019.09

Heuristic Scheme Detection

Use the following command to run aggressive scheme detection:

check_cdc –scheme –find –aggressive

Aggressive Detection of Sync Enablers

In addition to finding potential_sync_enabler schemes, with aggressive