Assertion-Based Verification CDC Verilog Tutorial User Guide

Assertion-Based Verification
CDC Verilog Tutorial User Guide
Software Version V2.6a

October 2008
© 1995-2008 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
RESTRICTED RIGHTS LEGEND 03/97
U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely
at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.7202-
3(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.
Contractor/manufacturer is:
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777.
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/user/feedback_form.cfm
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other third parties. No one is permitted to use these Marks without the
prior written consent of Mentor Graphics or the respective third-party owner. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/terms_conditions/trademarks.cfm.
Table of Contents
Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Verilog Tutorial Overviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Static Clock-Domain Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Protocol Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CDC-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
0-In Shell Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
0in Command help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0in_cdc Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0-In View Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
0-In Documentation Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 2
Static CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Static CDC Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Static CDC Functional Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Set the Basic Environment Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Generate the Clock Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Check Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Perform CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Debug and Remove Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Export Constraints in a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tutorial Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Project Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Create a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
cdc_control.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Create a Project Using a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Makefile File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Running CDC in Batch Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 3
Protocol CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Protocol CDC Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
CDC Protocol Analysis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Project Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Create a Project Using a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 3

October 2008
Table of Contents
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Makefile File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
cdc_control.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Running CDC and Promoting Checkers in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapter 4
CDC-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
CDC-FX Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
CDC-FX Analysis Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Makefile File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
cdc_control.v Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ccl_control.v Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Run CDC and Simulation with Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
End-User License Agreement
4 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

October 2008
List of Examples
Example 2-1. Error/Warning Summary in the 0in.log File . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Example 2-2. Clock Information in the 0in_cdc_design.rpt File. . . . . . . . . . . . . . . . . . . . . . 35
Example 2-3. CDC Summary in the 0in_cdc.rpt File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Example 2-4. CDC Summary with Waived in the 0in_cdc.rpt File . . . . . . . . . . . . . . . . . . . 53
Example 2-5. export_directives File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Example 2-6. cdc_control.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Example 2-7. Makefile File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Example 2-8. CDC Summary Information in the 0in.log File. . . . . . . . . . . . . . . . . . . . . . . . 61
Example 2-9. Error/Warning Summary Information in the 0in.log File . . . . . . . . . . . . . . . . 61
Example 2-10. Clock Group Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . . 62
Example 2-11. Design Information in the 0in_cdc_design.rpt File. . . . . . . . . . . . . . . . . . . . 63
Example 2-12. Port Domain Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . . 63
Example 3-1. cdc_dsel Checker Directive in the 0in_cdc_ctrl.v File . . . . . . . . . . . . . . . . . . 74
Example 3-2. Checker Report in the 0in_checker.rpt File. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Example 3-3. Snippet of the run_check_mti.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Example 3-4. demo_top.multi_bits_76265 Checker in 0in_checker.rpt File . . . . . . . . . . . . 85
Example 3-6. cdc_control.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Example 3-7. CDC Summary Information in the 0in_cdc.rpt File . . . . . . . . . . . . . . . . . . . . 100
Example 3-9. cdc_dsel Checker Directive in the 0in_cdc_ctrl.v File . . . . . . . . . . . . . . . . . . 101
Example 3-10. Checker Report in the 0in_checker.rpt File. . . . . . . . . . . . . . . . . . . . . . . . . . 103
Example 3-11. Snippet of the run_check_mti.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Example 4-2. cdc_control.v Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Example 4-3. ccl_control.v Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Example 4-4. CDC Summary Information in the 0in.log File. . . . . . . . . . . . . . . . . . . . . . . . 118
Example 4-6. Clock Group Summary Information in 0in_cdc_design.rpt File. . . . . . . . . . . 119
Example 4-7. General Design Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . 120
Example 4-8. Port Domain Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . . . 121
Example 4-9. 0in_cdc_fx_sim_ctrl.v File Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Example 4-10. Checker Report in the 0in_checker.rpt File. . . . . . . . . . . . . . . . . . . . . . . . . . 124
Example 4-11. run_check_mti.log File Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Example 4-12. Firing Report in the run_check_mti.log File . . . . . . . . . . . . . . . . . . . . . . . . . 132
Example 4-13. Snippet of the 0in_checker.rpt File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

October 2008
List of Figures
Figure 1-1. 0-In Help Button for Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 2-1. Static CDC Functional Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 2-2. Demo Circuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2-3. 0in_cdc GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2-4. Create Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2-5. Add Items to the Project Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2-6. Add File to Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2-7. Select Files to Add to Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2-8. Select Files to Add to Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-9. Add File to Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-10. Workspace Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 2-11. Add Constant Directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 2-12. Set Constant Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 2-13. Constant Directive in Workspace Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 2-14. Compile Options Common Tab Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 2-15. Compile Options Verilog Tab Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 2-16. CDC Options Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 2-17. Select Verilog Checker Control File Window . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 2-18. Workspace Clock Tab Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 2-19. Show Clocks in Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 2-20. Clock Signals Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 2-21. Results Window with Check Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 2-22. Transcript and Results Window Errors/Warning Tab. . . . . . . . . . . . . . . . . . . . 42
Figure 2-23. Results Popup Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 2-24. Choose Reconvergent Paths to Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 2-25. rx_payload_en Combinational Reconvergence. . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 2-26. Show Net Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 2-27. Expand Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 2-28. Schematic with Expanded Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 2-29. Source Code with Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 2-30. Missing Synchronizer Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 2-31. Combinational Logic Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 2-32. Filter to Specify Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 2-33. Filter CDC Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 2-34. Modify Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 2-35. Set CDC Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 2-36. Combo Logic Severity Waived. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 2-37. Waived Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 2-38. Workspace Directives Tab Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 2-39. Export Directives Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

October 2008
List of Figures
Figure 2-40. 0in_cdc GUI Created with a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figure 2-41. 0in_cdc GUI Invoked in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 3-1. CDC Protocol Analysis Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 3-2. 0in_cdc GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 3-3. Compile Options Common Tab Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 3-4. Results Window with Check Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 3-5. Results Window with 0in_cdc.db Loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 3-6. Merge Database Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 3-7. Results Window CDC Checks Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 3-8. Show Simulation Firings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 3-9. Firings Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 3-10. Load Waveform Database Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 3-11. Waveform Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 3-12. demo_top.multi_bits_76265 Checker Schematic View . . . . . . . . . . . . . . . . . . 87
Figure 3-13. Configure Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 3-14. Results Window with Configured Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 3-15. Results Window with the Columns Reconfigured . . . . . . . . . . . . . . . . . . . . . . 89
Figure 3-16. View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 3-17. Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 3-18. Workspace Window Design Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 3-19. Coverage by Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 3-20. Expanded Results Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 3-21. 0in_cdc CDC GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 3-22. Merge Database in Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 3-23. CDC Checks Tab in the Results Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 4-1. CDC-FX Analysis Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 4-2. 0in_cdc GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 4-3. View Menu or Results Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 4-4. Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 4-5. Show Simulation Firings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 4-6. Firings Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 4-7. Load Waveform Database WIndow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 4-8. Waveform Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

October 2008
List of Tables
Table 1-1. Help Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Table 2-1. General Design Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . . . 38
Table 2-2. Port Domain Information in the 0in_cdc_design.rpt File . . . . . . . . . . . . . . . . . . 39
Table 2-3. MISSING SYNCHRONIZER Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

October 2008
Chapter 1
Introduction
Verilog Tutorial Overviews

Static Clock-Domain Crossing
Incorrect handling of clock-domain crossing (CDC) signals is the second major cause of
respins. Traditional verification techniques do not work for CDC signals. CDC problems are
subtle, occur in hardware, and are complex to debug. 0-In assertion synthesis automates CDC
verification, which significantly reduces the risk of CDC related silicon respins.
Refer to the “Static CDC Tutorial” on page 17 for information on running the static CDC design
example.
The example to run this tutorial is located in the following directory:
$HOME_0IN/share/examples/Verilog/CDC/Static_CDC
The Assertion-Based Verification Verilog CDC Tutorial User Guide is located in the following
directory:
$HOME_0IN/share/doc/pdfdocs or $HOME_0IN/share/doc/htmldocs
Protocol Verification
Failure to verify all CDC protocols can leave undetected bugs. Protocol verification ensures
data reaches it final destination. 0-In protocol verification supports structured and ad hoc
synchronization.
The user is not required to make changes to the existing verification environment. Protocol
verification leverages with simulation and formal verification, and it promotes CheckerWare
CDC monitors.
Refer to “Protocol CDC Tutorial” on page 67 for information on running the protocol CDC
design example.
$HOME_0IN/share/examples/Verilog/CDC/Protocol_CDC
directory:

October 2008
Introduction
0-In Shell Help
CDC-FX
If any CDC signal does not hold steady during the setup and hold time of its receiving register,
then the register can become metastable. That is, its output can settle at random to a value that is
different from the RTL simulated value. Data values that cross clock domains can be advanced
or delayed randomly relative to the RTL simulation.
If the receiving logic is not specifically designed to tolerate these metastability effects, then
functional errors can occur. Standard simulation cannot accurately model metastability in a
design; therefore, an extension to standard functional verification is required to model the
effects of metastability in a design.
CDC-FX runs standard simulation with metastability injected into the circuit. Refer to the
“CDC-FX Tutorial” on page 111 for information on handling metastability in a register.
$HOME_0IN/share/examples/Verilog/CDC/CDC_FX
directory:
0-In Shell Help

All 0-In compilers run under the 0-In shell. They can be run in batch mode or interactively. The
usage is as follows:
% 0in [script_file | -cmd command_string]
The 0-In shell help command displays the syntax for utilities recognized by the 0-In shell. To
view a list of the 0-In shell commands, enter 0in in the UNIX shell, then enter help with no
arguments in the 0in shells as follow:
% 0in
0in> help
The help commands are displayed in Table 1-1.
Table 1-1. Help Commands

Command Command to View Help Description
help help Help

October 2008
Introduction
0-In Shell Help
Table 1-1. Help Commands (cont.)

Command Command to View Help Description
quit quit or exit Exit
cwc help cwc Checkerware Creator
compile_check_logic help ccl Synthesizes checkers for the design
analyze help analyze Compiles and saves the design
compile_search_logic help csl Prepares design files for search
checklist help checklist Performs automatic RTL check for
the design
cdc help cdc Performs clock domain crossing
check for the design
cwhelp help cwhelp Help for Checkerware
cwhelp Displays global directives and
checker directives
cwhelp globals Displays global directives only
cwhelp checkers Displays checker directives only
pathmap_arg_file help pathmap_arg_file Converts a 0-In arg file in
conjunction with ZI_PATHMAP
For checklist, only the global directives are used. To view the syntax for a global directive or
checker directive, type the following in the 0in shell:
0in> cwhelp <directive_name>
For example,
0in> cwhelp checklist_off
displays the following:
Command: cwhelp
Command arguments:
checklist_off
usage: checklist_off
[-type <type_string>]
[-name <name>]
[-module <module_name>]
[-global]
[-help]
Excludes a specified checklist check from the design file.

October 2008
Introduction
0in Command help
0in Command help

It is required to exit from the 0-In shell to display the 0in command syntax. Do the following
to display 0in -help:
0in> exit
% 0in -help
The following is displayed:

usage: 0in [options] [<script file>]
usage: 0in [options] -cmd <rest of line passed as a command>
Options:
-l <log_file>
-detail <detailed_log_file_name>
-wd <work_directory>
-od <output_directory>
-rel_paths
-nl
-limit_messages
-sim <questa | mti | vcs | nc | nc3>
-version
+0in_licq (queue for 0-In licenses)
0in_cdc Help
0-In CDC-IDE is the integrated design environment graphical browser. To invoke this graphical
browser, use the 0in_cdc command in the 0-In shell. It is required to exit from the 0-In shell to
display the 0in_cdc command syntax. (However, note that you must return to the 0-In shell to
invoke the GUI.) Do the following to display 0in_cdc -help:
0in> exit
% 0in_cdc -help

Options:
[ [-db <db_name>] | [<db_name>] [-mergedb <db_name>] | \
[[-p <project_name>] | [<project_file>] \
[[<hdl_file_name>+[-]]
[-d <top_level_module>] [-od <output_directory>] \
[-f <verilog_file_list>] [-vhf <VHDL_file_list>] \
[-libmapfile <library_mapping_file>] \
[-sdc_in <sdc_file>] [-sdc_out <sdc_file>] \
[-v95] \
[-ctrl <verilog_control_file>] [-vhctrl <VHDL_control_file>] \
[-import_ctrl <control_file>] \
[-no_directive_error_check] \
[-work <work_lib_path>] [-y <Library_search_file>][-v <Library_file>] \
[-qy <skip_lib_search_file>] [-qv <skip_lib_file>] \
[+define+<name=val>] [+libext+<ext>] [+incdir+<path>] \
[-block <treat_module_as_a_block_for_hierarchical_analysis>+[-]] \
[-ignore_translate_off]] ]

October 2008
Introduction
0-In View Help
0-In View Help

0-In View can be run as an interactive browser, a batch processor, or a text-based interactive
interpreter.
Following is the command in the UNIX shell to invoke the 0in_view help:
% 0in_view -help

0in_view
[[-db] <db_name>]
[-db_list <file>]
[-l <log_file_name>]
[-no_init (skip_loading_preference_files)]
[-text [<script_name>]]
[+0in_licq]
[-display_limit <number> (default 1000, 0 means unlimited)]
[-h | help]
[-cmd <rest_of_line_passed_as_a_command>]
[-version]
[-force_append]
[-raw_coverage_counts]
[-classic_coverage]
The 0-In View shell is invoked in the UNIX shell with the 0in_view -text command as follows:
% 0in_view -text
For the 0-In View help, type the following in the 0-In View shell:
0-In View> help

0-In View> help
Command: help
Command arguments:
0-In View
help Help
report_firings reports firings
print_view prints data views
report_density reports density
report_formal reports formal results
read_db read violations db
append_db append violations db
save_db save violations db
rank_dbs rank db list
read_dblist read violations db list
extract_top extract new db with specified top
report_module_instances report modules instances
To view the command argument syntax, do the following:

October 2008
Introduction
0-In Documentation Help
0-In View> help <command_argument>
For example,
help report_density
displays the following:

Command: help
Command arguments:
report_density
usage: report_density
[-db <db_name>]
[-module <module_name>]
[-o <output_file_name>]
[-help]
reports density

Click on the Help Button to view the list of PDF and HTML manuals that can be invoked from
the 0in_view browser and the 0in_cdc browser (see Figure 1-1 on page 15).
Following is the command in the UNIX shell to invoke the 0in_cdc GUI:
% 0in_cdc
Following is the command in the UNIX shell to invoke the 0in_view GUI:
% 0in_view

October 2008
Introduction
Figure 1-1. 0-In Help Button for Documentation

October 2008
Introduction
Mentor Graphics Support
Mentor Graphics Support

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

October 2008
Chapter 2
Static CDC
Static CDC Tutorial

0-In CDC performs structural verification using static analysis techniques that automatically
perform the following tasks:
• Identify the clock structure used in the design (clock domains, clock gating, dividers,
etc.).
• Identify all CDC signals in the design.
• Determine the synchronization scheme (if any) used on the signals.
• Check that each synchronization structure is implemented and used correctly.
While the process is automated, the user has the ability to guide the CDC tool by providing
additional information on clock groups, preferred synchronization types, exceptions, and many
other options. If a problem is identified in the structural synchronization, then it can be
debugged using an interactive environment. All problems identified during structural
verification should be corrected through modification of the design or, if appropriate, waived
after a manual review by the user.
This tutorial shows how to run 0-In CDC to identify clock domain crossing (CDC) problems in
a demonstration design. In this tutorial, the following is demonstrated:
• Create a Project.
• View the clock tree in the 0-In CDC GUI.
• Run CDC static analysis on the RTL to find CDC bugs.
• Run 0-In CDC GUI and view the CDC results.
• Analyze the CDC results and fix a CDC synchronization error.
• View the different synchronization schemes.
$HOME_0IN/share/examples/Verilog/CDC/Static_CDC

October 2008
Static CDC
Static CDC Functional Flow

Figure 2-1. Static CDC Functional Flow Diagram
Set Basic Environment Conditions
Generate Clock Report
N
Check Clock Groups? Modify the Clock Constraints
Y Any Other
CDC Constraints?
Modify the CDC Constraints N
Perform CDC Checks
Y
Violations? Debug and Remove Violations
CDC Done

October 2008
Static CDC
Set the Basic Environment Conditions

The basic CDC analysis conditions include configuring the clock and other signals. This can be
done in the following two ways:
• Write the configuration in a Verilog/VHDL control file (see “cdc_control.v File” on

page 57), and then import the file before analyzing the clocks.
• Add the required global directives using the 0-In CDC GUI Directives tab (see
Figure 2-11 on page 28) before analyzing the clocks.
The user can choose either process above or a combination of both. Following are some cases
where the user might want to add global directives to the basic environment:
• Define clock domains and group synchronous or related (by some gating logic) clocks in
one domain.
• Change the default clock group for any port by using the set_cdc_port_domain
global directive.
• Set any test signal or configuration register to a constant value for the entire CDC run by
using the set_constant global directive. This can be done using a control file (see
page 57) or using the 0-In CDC GUI (see “Set Constant Window” on page 28).
Generate the Clock Report

View the clocks in the design.
Running the Analyze Clocks (see page 33) step automatically generates the 0in_cdc_design.rpt
clock report file. This file contains all the required information about the various clock domains.
Check Clock Groups

Verify that the asynchronous clock groups are correct. If the clocks are incorrect, then the user
must add the appropriate constraints. The correct clock grouping should be confirmed before
running the full CDC analysis.
Verify the following in the 0in_cdc_design.rpt file (see Example 2-2 on page 35):
• All the clocks are as intended.

• All the clocks are grouped correctly.
• All the ports are assigned to the correct clock domain.
Modify the Clock Constraints

This step is optional.

October 2008
Static CDC
The user can modify the clock constraints by adding global directives to customize the static
CDC synthesis run. Following are situations when modifying the clock constraints can be
helpful:
• If you want to turn off unintended clocks that are in the clock report.
• If you want to group clocks in the same domain and they appear in different inferred
domains in the control file.
• If the inferred port clock domains are not correct, then add global directives to set the
port clock domain for the required ports.
Note that adding new global directives requires running the Analyze Clocks step again.
Modify the CDC constraints

Global directives other than clock related global directive can be added. Following are some
examples:
• A module can be specified as a black box using the set_black_box global directive.
CDC understands RTL code and nonsynthesizable elements for which there is no inner
RTL module that can be black-boxed. For example, memory that you do not want to
perform clock analysis on should be black-boxed. Every port of the black box must be
assigned a clock domain.
• If there is behavioral (no RTL) custom made synchronizer in the design, then this means
that you already have the synchronizer for that particular CDC signal. For this scenario,
use the set_cdc_synchronizer global directive to inform CDC to ignore the custom
synchronizer. The user is required to define the input and output ports connected to the
clock domains for custom synchronizers, which should be defined like a black box.
• CDC classifies each of the CDC signals so that it can identify the type of
synchronization needed. For example, a different type of scheme is required for a data
signal than for a control signal, or a synchronizer is not needed if it is a stable signal.
CDC might interpret some signals incorrectly. Therefore, use the set_cdc_signal
global directive to override the inferred category and hence the synchronization scheme
needed for that CDC signal.
Perform CDC Analysis

0-In CDC automatically detects all the CDC paths and checks the CDC synchronization
structures.
Run CDC to analyze the design (see page 39). This step automatically generates the 0in_cdc.rpt
file that contains the violations and other attributes. The 0-In CDC GUI Results window
displays the Errors/Warnings.

October 2008
Static CDC
Tutorial Design
Violations
In reviewing CDC results, any paths classified as violations should be reviewed (see page 40).
Debug and Remove Violations

Debug the violations by invoking the schematic view to observe the cause of the errors and
warning (see Step 9 on page 43). After editing the source code to fix the errors and warnings,
run CDC again. A violation can be waived if a CDC path is found to have a good
synchronization scheme.
Export Constraints in a File

If there are a lot of constraints, then use the export global directive, which results in all
constraints in one file (see page 55).
Tutorial Design
Figure 2-2 is a block diagram illustrating an interface block between a Media Access Controller
and a custom core that is controlled via a CPU interface. This design contains the following
three clock domains:
• core_clk domain
• cpu_clk domain
• mac_clk domain
The mode status bits go back and forth at the clock domain boundaries. There are different types
of synchronization schemes in this circuit (for example, Data MUX, 2-DDF, etc.).

October 2008
Static CDC
Project Mode
Figure 2-2. Demo Circuit
Data Preparation
The only preparation to run this tutorial is to copy the example directory to your local work
directory. The tutorial directory include the following:
Makefile
SOLUTION/
demo_top_fix.v
SRC/
demo_top.v
dff2_sync.v
dpmem2clk.v
generic_fifo_dc_gray.v
tb.v
cdc_control.v
filelist
Project Mode
It is not required to use a Project (instead of batch mode). However, using a Project makes
interaction with the tool easier and it is useful for organizing files and specifying analysis
settings.
A Project has the following information:

October 2008
Static CDC
Project Mode
• DUT source code files and libraries

• Assertion source code and files
• Control data and files
• Default compile options
• Default formal analysis options
Saving the current Project saves the current settings for all of this information.
Create a Project
Following are the steps to manually create a Project:
1. Invoke the 0-In CDC GUI using the following command:
0in_cdc
This opens the 0in_cdc GUI window as shown in Figure 2-3.
Figure 2-3. 0in_cdc GUI

October 2008
Static CDC
Project Mode
2. Create a new project as follows:

File -> New -> Project ...
This opens the Create Project window shown in Figure 2-4. In the window, the user
can specify the Project Name, Project Location, and Default Library Name. In general,
leave the Default Library Name set to “work.” The name you specify is used to create a
working library subdirectory within the Project Location. In this tutorial, the Project
Name is myProj_Static_CDC.
Figure 2-4. Create Project Window
In the Project Name field, type the following:

myProj_Static_CDC
select -> OK
This invokes the Add Items To The Project window as shown in Figure 2-5.
Figure 2-5. Add Items to the Project Window
select -> Add Existing File
This invokes the Add File to Project window as shown in Figure 2-6.

October 2008
Static CDC
Project Mode
Figure 2-6. Add File to Project
Add the File Name as follows:

select -> Browse
This invokes the Select Files to Add to Project window as shown in Figure 2-7.
Figure 2-7. Select Files to Add to Project Window
Navigate to the correct directory level
Select the correct file type
From the Files of type popup menu, select the correct file type for the design as shown
in Figure 2-7.
Files of type: -> Verilog Files (*.v, *.vl, *.vo, *. vp, *.vt)
The next step is to add the design file to the Project.

For this tutorial, navigate to the Static_CDC/SRC directory level. Add all five Verilog
files (using the Control key allows selecting multiple files).
select ->demo_top.v, dff2_sync.v, dpmem2clk.v, generic_fifo_dc_gray.v, tb.v files

October 2008
Static CDC
Project Mode
Notice in Figure 2-8 that the five files are activated (blue). An error message is
displayed stating the “file do not exists” if Open is selected when the file is deactivated
(not blue).
select -> Open
This opens the Add File to Project window as shown in Figure 2-9.
select-> OK
This places the five files in the Workspace window as shown in Figure 2-10.
In the Add Items to the Project window, do the following:
select -> Close
Figure 2-8. Select Files to Add to Project
Figure 2-9. Add File to Project Window

October 2008
Static CDC
Project Mode
Figure 2-10. Workspace Window
The question mark icon (?) in the Workspace window Status column denotes the file
has not been compiled into the project, or the source has changed since the last compile.
A check mark icon indicates the file is compiled successfully.
3. Set the basic environment conditions using global directives. This illustrates the “Set
Basic Environment Conditions” step in the flow chart (see Figure 2-1 on page 18).
The set_constant global directive is used to specify a signal (wire) to a constant
value for the entire CDC run.
In this example, scan mode is used for the test purpose, and the normal multiple clock
operation during scan mode is not performed. As you can see in Figure 2-20 on page 37,
the generic_fifo_dc_gray modules are controlled by a MUX that allows either
scan_clock (for the scan mode to pass through) or the respective asynchronous parent
clocks.
In this tutorial, the set_constant global directive is used to disable scan mode for
CDC analysis. The signal is set to constant 1'b0, which enables the normal operation
and CDC crossings can be checked for proper synchronization. For example,
// 0in set_constant scan_mode 1'b0
Note that the values assigned in the global directives need to be in the same format as
the RTL design language. For example, to assign a value to a signal when the design is
Verilog-based, assign the value 1'b0 to the signal.
Global directives can be added using the Directive tab (see Figure 2-11) or by including
a design control file. To add global directives using a control file, see Figure 2-16 on
page 32. This tutorial shows both processes for adding global directives as the user can
choose either method or a combination of both methods.
Use the Directives tab in the Workspace window to set the constant as shown in
Figure 2-11.

October 2008
Static CDC
Project Mode
select -> Directive Tab

right-click in the field
This invokes the popup menu as shown in Figure 2-11.
Figure 2-11. Add Constant Directive
select -> Add -> Constant
This invokes the Set Constant window as shown in Figure 2-12. Note that the value
assigned in the global directive is in the same format as the RTL design language. Do
the following:
Signal -> scan_mode
Constant -> 1'b0
select -> OK
Figure 2-12. Set Constant Window
Figure 2-13 shows the scan_mode signal set to a constant value of 0.

October 2008
Static CDC
Project Mode
Figure 2-13. Constant Directive in Workspace Window
The design is now ready to compile.
4. Compile the design using the 0in_cdc GUI.

The design is compiled before generating the clock report. After compiling the design,
the next step is to perform CDC analysis (see page 33) and then view the clocks (see
“View the clock group information.” on page 34).
The first phase of CDC verification is to compile the CDC model of the design block by
running the cdc compile command. This creates the logic and supporting files for CDC
verification.
select -> Compile -> Compile All
or select the Compile All icon from the Toolbar as shown below:
Compile All
This invokes the Compile Options window as shown in Figure 2-14. The compile
options allows the user to set project wide options for Verilog and VHDL.
On the Common tab, type the correct information. For this tutorial, the Top Module is
demo_top, the Work Library is work, and the Set Output Directory is Output_Results.
Top Module -> demo_top
Work Library -> work
Append to path in Set Output Directory -> /Output_Results

October 2008
Static CDC
Project Mode
Figure 2-14. Compile Options Common Tab Window
In the Compile Options Verilog tab window (see Figure 2-15), do the following:
In the Language Syntax field
select -> Verilog 2001
select -> OK

October 2008
Static CDC
Project Mode
Figure 2-15. Compile Options Verilog Tab Window
This step creates the work directory, the Project directory (myProj_Static_CDC), and
the automatically generated 0in.log and 0in_detail.log output files in the Output_Results
directory.
Notice that the Workspace window Project tab in Figure 2-10 on page 27 that the
question mark icons (?) are now check mark icons, which indicates the files are
compiled successfully.
5. Analyze the clocks.

Before analyzing the clocks, add the cdc_control.v control file as follows:
select -> CDC -> CDC Options...
This invokes the CDC Options window as shown in Figure 2-16.

Refer to the “cdc_control.v File” on page 57 for details on the information in the control
file.

October 2008
Static CDC
Project Mode
Figure 2-16. CDC Options Window
select -> Add
This invokes the Select Verilog Checker Control File window shown in Figure 2-17.
For this tutorial, navigate to the Static_CDC directory level.
select -> cdc_control.v
select -> Open
In the CDC Options window, do the following:

select -> OK

October 2008
Static CDC
Project Mode
Figure 2-17. Select Verilog Checker Control File Window
6. Run the Analyze Clocks step as follows:

select -> CDC -> Analyze Clocks
or select the Analyze Clocks icon from the Toolbar as shown below:
Analyze Clocks
This illustrates the “Generate Clock Report” step in the flow chart (see Figure 2-1 on page 18).
This step automatically generates the following output files and directory in the Output_Results
directory:
• 0in.log – Short log file, which is a copy of the standard output.
• 0in_cdc.db – The CDC database for examining in the GUI environment.
• 0in_cdc.rpt – The clock domain crossing report.
• 0in_cdc_design.rpt – The CDC design report.
• 0in_design.rpt – The design summary.
• 0in_detail.log – The detailed log of the transcript.

October 2008
Static CDC
Project Mode
• 0in_cache/ – The working directory for storing internal data and checker logic.
The screen displays the information on the Error/Warning Summary. This information is also
available in 0in.log file (see Example 2-1).
Example 2-1. Error/Warning Summary in the 0in.log File
Count Type Message ID Summary

-----------------------------------------------------------------------
2 Warning hdl-41 Primary port connects out to multiple
clock domains.
19 Warning hdl-51 Port assigned to inferred clock domain.
Summary: 21 Warnings in cdc
7. View the clock group information.

Figure 2-18 shows the clock group information in the Workspace window Clock tab.
This information is also available in the Output_Results/0in_cdc_design.rpt file as
shown in Example 2-2.
Observe that there are three clock groups. The three asynchronous clocks are as follows:
• core_clk_in
• cpu_clk_in
• mac_clk_in
These three clocks pass through the MUX and since scan_mode is disabled, these
clocks are assigned to core_clk_in, cpu_clk_in, and mac_clk_in, respectively.

October 2008
Static CDC
Project Mode
Figure 2-18. Workspace Clock Tab Window
Example 2-2. Clock Information in the 0in_cdc_design.rpt File
Module 'demo_top'
-----------------------------------------------------------------
Clock Group Summary for 'demo_top'

==================================
Total Number of Clock Groups : 3
Number of User-Defined Clock Groups : 3
Number of Inferred Clock Groups : 0
Number of Ignored Clock Groups : 0
User-Specified Clock Groups

===========================
Group 0(35 Register Bits)

-----------
cpu_clk_in
cpu_clk

-----------
core_clk_in
core_clk

October 2008
Static CDC
Project Mode
fifo_1_d.wr_clk
fifo_1_d.u0.Wclk
fifo_0_h.wr_clk
fifo_0_h.u0.Wclk

-----------
mac_clk_in
mac_clk
fifo_1_d.rd_clk
fifo_1_d.u0.Rclk
fifo_0_h.rd_clk
fifo_0_h.u0.Rclk
crc_1.clk
Inferred Clock Groups

=====================
None
Ignored Clock Groups

====================
None
To view these clocks in the schematic view, do the following as shown in Figure 2-19:
select all signals
right-click on a clock signal
select -> Show in Schematic -> Drivers and Readers -> New View
Figure 2-20 is the clock schematic view.

To change the size of the schematic for viewing, use the Zoom In, Zoom Out, and
Zoom Full icons (circled in red in Figure 2-20).
Notice the schematic view on your GUI screen does not display the scan_clk signal.
Expand the schematic to show the scan_clk signal as follows:
double-click on the D1 signal of the mac_clk_in clock
(as shown by the red arrow in Figure 2-20)

October 2008
Static CDC
Project Mode
Figure 2-19. Show Clocks in Schematic View
Figure 2-20. Clock Signals Schematic View

October 2008
Static CDC
Project Mode
In general, you should check the 0in_cdc_design.rpt file to make sure all the clocks are inferred
correctly. If they are not, then you need to make changes to the control file (see “cdc_control.v
File” on page 57).
Verify the following in the 0in_cdc_design.rpt file:
• All the clocks are as intended. That is, all the asynchronous clocks are listed and
there are no unintended clocks.
• The CDC clock analysis has captured the intent correctly. That is, there are two
clocks that are related (indirectly synchronous) and they should be in the same clock
group.
• If there is more than one clock domain to a particular port, then the CDC clock
analysis is not performed on that one. Verify the ports and their respective assigned
clock domains.
The user can modify the clock constraints by adding global directives to customize the static
CDC synthesis run. Following are situations when modifying the clock constraints can be
helpful:
• If you want to turn off unintended clocks that are in the clock report.
• If you want to group clocks in the same domain and they appear in different domains
in the control file.
• If the port domain information is not correct and any of the ports are assigned to
undesired clock domains, then add global directives to set the port domain for the
required ports using the set_cdc_port_domain global directive.
If the user adds new global directives, then it is required to rerun the Analyze Clock
step.
In addition to the clock information, the 0in_cdc_design.rpt file also contains the General
Design Information (see Table 2-1) and the Port Domain Information (see Table 2-2).
Table 2-1. General Design Information in the 0in_cdc_design.rpt File

General Design Information
==========================
Number of blackboxes = 0
Number of Registers = 302
Number of Latches = 0
Number of RAMs = 2
Detail Design Information

=========================
RAMs:
-----
fifo_1_d.u0.data
fifo_0_h.u0.data

October 2008
Static CDC
Project Mode
Table 2-2. Port Domain Information in the 0in_cdc_design.rpt File

Printing port domain info
=========================
Port Direction Constraints Clock Domain Type
-------------------------------------------------------------------
rst input Reset { cpu_clk_in
core_clk_in
mac_clk_in } 0-In CDC
clr input Reset { mac_clk_in
core_clk_in } 0-In CDC
din input { core_clk_in } 0-In CDC
we input { core_clk_in } 0-In CDC
we_1 input { core_clk_in } 0-In CDC
cpu_addr input { cpu_clk_in } 0-In CDC
cs input { cpu_clk_in } 0-In CDC
cpu_data input { cpu_clk_in } 0-In CDC
init_done_in input { cpu_clk_in } 0-In CDC
hdrin input { core_clk_in } 0-In CDC
scan_mode input Constant ---
scan_clk input ---
mac_clk_in input Clock { mac_clk_in } User
core_clk_in input Clock { core_clk_in } User
cpu_clk_in input Clock { cpu_clk_in } User
full output { core_clk_in } 0-In CDC
full_1 output { core_clk_in } 0-In CDC
pass output { mac_clk_in } 0-In CDC
pass_valid output { mac_clk_in } 0-In CDC
crc_16 output { mac_clk_in } 0-In CDC
rx_payload_en output { mac_clk_in } 0-In CDC
rx_masked_data output { mac_clk_in } 0-In CDC
rx_mask_en output { mac_clk_in } 0-In CDC
rx_pass output { mac_clk_in } 0-In CDC
rx_check output { mac_clk_in } 0-In CDC
8. Perform CDC checks by running CDC. This illustrates the “Perform CDC Checks” step
in the flow chart (see Figure 2-1 on page 18).
CDC -> Run CDC
or select the Run CDC icon from the Toolbar as shown below:
Run CDC
This invokes the Results window CDC Checks tab with the check violations as shown
in Figure 2-21.

October 2008
Static CDC
Project Mode
Figure 2-21. Results Window with Check Violations
The automatically generated 0in_cdc.rpt report file (see Example 2-3) gives a CDC Summary,
which is a breakdown of the status (violations, unknowns, evaluations, waived, proven, and the
CDC promotion summary) as shown in Figure 2-21.
The cdc command evaluates the RTL netlist and finds violations. These violations are a
mixture of errors that must be fixed and rule violations that do not apply to any current design
style. Also, cdc finds unknowns (potential rule violations). The user can promote checks for
these potential rule violations and then run them on simulation (see “Protocol CDC Tutorial” on
page 67).
Example 2-3. CDC Summary in the 0in_cdc.rpt File
CDC Summary
=================================================================
Violations (9)
-----------------------------------------------------------------
Single-bit signal does not have proper synchronizer. (3)
Combinational logic before synchronizer. (2)
Reconvergence of synchronizers. (4)

October 2008
Static CDC
Project Mode
Unknowns (9)
-----------------------------------------------------------------
DMUX synchronization. (2)
Multiple-bit signal synchronized by DFF synchronizer. (4)
Multiple-bit signal across clock domain boundary. (1)
Memory Synchronization. (2)
Evaluations (2)
-----------------------------------------------------------------
Single-bit signal synchronized by DFF synchronizer. (2)
Waived (0)
-----------------------------------------------------------------
<None>
Proven (4)
-----------------------------------------------------------------
Pulse Synchronization. (1)
Filtered (0)
-----------------------------------------------------------------
<None>
CDC Promotion Summary

=================================================================
Promoted protocol checkers (14)
Unpromoted checkers (see 0in_detail.log) (10)
=================================================================
Check the Results window Error/Warnings tab to verify there are no unexpected errors or
warning as shown in Figure 2-22. Note that the Transcript window and the 0in_detail.log file
also contains the Errors/Warnings Summary.

October 2008
Static CDC
Project Mode
Figure 2-22. Transcript and Results Window Errors/Warning Tab
Figure 2-22 displays the warnings. Following are the descriptions of some of the warnings:
• Warning hdl-101 — Unable to promote protocol checker (unsupported scheme).
In this design, there are six warnings for unpromoted checkers. This is because
the tool does not promote reconvergence protocol checkers. The user can add a
global directive to the cdc_control.v file to promote protocol checkers. For
examples,
// 0in set_cdc_preference -promote_reconvergence
• Warning hdl-105 — Memory write-through condition could be undetected.

The CDC compiler reports this warning for every memory_sync
implementation. The compiler currently does not perform read/write analysis,
and misses the condition where the read and write addresses are equal, which
could result in memory write-through errors. Adding checkers to guard against
this condition is suggested.
• Warning hdl-41 — Primary input port fans out to multiple clock domains.

October 2008
Static CDC
Project Mode
If there are ports that have more than one clock domain, then CDC checking is
not performed for those ports. If there is no synchronizer for the signals, then the
user can specify the correct port domains so that the CDC check is performed.
Each set_cdc_port_domain global directive with a -clock argument assigns
all matching ports to the same clock domain (that is, the directive does not assign
to multiple clock domains). For example, the following can be added to the
control file:
// 0in set_cdc_port_domain a b c –clock U1.clk_A
// 0in set_cdc_port_domain d –clock U2.clk_B
• Warning hdl-51 — Port assigned to inferred clock domain.

By default, a port is associated with the clock domain of the register that it
directly connects to. To associate with another clock domain, identify it as an
asynchronous port using set_cdc_port_domain -async global directive. For
example,
// set_cdc_port_domain in -async -mode mode2
In the above example, constraint port in is asynchronous in mode mode2.
9. Debug the violations for Reconvergence (below), Missing Synchronizer (see page 47),
and Combo Logic (see page 49). This step illustrates the “Debug and Remove
Violations” in the flow chart (see Figure 2-1 on page 18).
Reconvergence
Reconvergence is the process of using separately propagated correlated information.
A primary example of reconvergence is information crossing clock domain (CDC)
boundaries that is recombined in the receiving logic.
Because they can become metastable, CDC signals are always subject to variable delays
(even when a proper synchronizer is used). Variable delays can cause reconvergence
information to be inconsistent. One example is a data bus that is split and transmitted
across different synchronizers. If the synchronized parts are recombined, then the
received value will not match the transmitted value in some cycles.
The CDC compiler checks each CDC signal for a number of cycles after the value is
received in the receive clock domain, to determine if the transmitted data value
reconverges with other transmitted data. The maximum number of cycles analyzed is
called the reconvergence depth. The CDC compiler only detects reconverging values if
they reconverge within the reconvergence depth from the cycle the values are received.

October 2008
Static CDC
Project Mode
The default reconvergence depth is 0 cycle, which corresponds to combinational

reconvergence. The set_cdc_reconvergence global directive changes the
reconvergence depth to 10 in this tutorial design (see Example 2-6 on page 57).
Figure 2-25 on page 45 shows the schematic for the rx_payload_en signal. This signal
is combinational reconvergence. There are two signals, tx_sop_r2 and tx_eop_r2,
reconverged at the AND gate. Note that in a large design there can be hundreds of paths
like this, which can make manual review difficult and error prone.
To display the schematic for the rx_payload_en signal, in the Results window CDC Checks
tab right-click on the tx_eop_r2, tx_sop_r2 signal, select Show -> Schematic -> Path as
shown in Figure 2-23. This invokes the Choose Reconvergent Paths to Display window as
shown in Figure 2-24.
Figure 2-23. Results Popup Menu
Figure 2-24. Choose Reconvergent Paths to Display
select -> Show All
This invokes the schematic view shown in Figure 2-25.

October 2008
Static CDC
Project Mode
Figure 2-25. rx_payload_en Combinational Reconvergence
To change the schematic size in the window, use the Zoom In, Zoom Out, and Zoom
Full Toolbar Icons that are circled in red in Figure 2-25.
To display the net name, right-click on a signal in the schematic window, then select
Show, then select Net Names (see Figure 2-26).
Figure 2-26. Show Net Names
To expand just a net in the schematic view, place the cursor in the schematic window,
left-click and draw a box around what you want expanded. This turns the selected
signals orange (see Figure 2-27). Then right-click and select Expand, then select Net as
shown in Figure 2-27. This expands the net as shown in Figure 2-28.

October 2008
Static CDC
Project Mode
Figure 2-27. Expand Net
Figure 2-28. Schematic with Expanded Net

October 2008
Static CDC
Project Mode
Missing Synchronizer
In the Results window, right-click on Missing Synchronizer the init_done TX
Signal tx_mask_valid RX Signal, and select Show -> Source -> TX Signal as shown
in Figure 2-29.
This invokes the demo_top.v file in the window, and the user can view the cause of the
error. This violation happens because the init_done signal that is in the cpu_clock
domain is driving a FSM in the core clock domain. To correct this, add a
2-DFF synchronizer for this signal by editing the demo_top.v file.
Note that the Static_CDC/SOLUTION directory contains the demo_top_fix.v file. This
file contains the corrected source code (line number 127 to 134), which is also shown in
Table 2-3 on page 66.
Figure 2-29. Source Code with Violations

October 2008
Static CDC
Project Mode
Figure 2-30 shows the Missing Synchronizer check failed because the next_tx_state
needs a synchronizer before it goes into the register. Invoke the schematic view as
follows:
right-click on Missing Synchronizer, tx_state signal
select -> Show -> Schematic -> Path
right-click in window
select -> Show -> Net Names
Observe in Figure 2-30 the schematic view shows that the CDC path from the
init_done signal, the next_tx_state signal to the receive domain register is crossing
the clock domain from cpu_clk_in to core_clk_in domain. This needs a single-bit
synchronization scheme, such as a 2-DFF register. Therefore, there is a violation of a
missing synchronizer.
Figure 2-30. Missing Synchronizer Schematic

October 2008
Static CDC
Project Mode
Combo Logic
Figure 2-31 shows combinational logic in the form of an OR gate.
right-click on Combo Logic, pass_en signal
This shows that the signal crossing the clock domain, named pass_en in the transmit
domain and the check_en signal in the receive domain, is more prone to frequently
changing (unstable) than if there was no Combo Logic.
The CDC signal is crossing from the clock domain cpu_clk_in to mac_clk_in.
Figure 2-31. Combinational Logic Schematic

October 2008
Static CDC
Project Mode
Filter Out a Violation

This is an optional feature that can be used to control the reporting of violations.
If you know that the CDC violation that appears in the Results window is handled by
some other synchronizer, (for example, by an Ad Hoc synchronizer) then use the tool’s
filter to specify that the severity be waived, turned off, or changed to a different severity
type for this violation.
Figure 2-32. Filter to Specify Severity
Do the following as shown in Figure 2-32.

select -> Violation you want to filter
right-click -> Filter -> Selected...
This invokes the Filter CDC Checks window as shown in Figure 2-33.

October 2008
Static CDC
Project Mode
Figure 2-33. Filter CDC Checks
select -> Violation you want to modify

select -> Modify
This invokes the Modify Filter window as shown in Figure 2-34.
Figure 2-34. Modify Filter

October 2008
Static CDC
Project Mode
select -> Exclude Matches

select -> Create Directive...
This invokes the Set CDC Report window as shown in Figure 2-35.
Figure 2-35. Set CDC Report
select -> Waived

select -> OK
In the Modify Filter window,

select -> OK
In the Filter CDC Checks window,

select -> OK
The Workspace window Directives tab now shows the combo_logic as shown in
Figure 2-36. Hovering over combo_logic shows that its severity is waived.

October 2008
Static CDC
Project Mode
Figure 2-36. Combo Logic Severity Waived
Rerun CDC by selecting the Run CDC icon or selecting CDC -> Run CDC from the
Toolbar.
The Results window now shows Waived status of the Combo Logic Check for the
pass_en TX signal as shown in Figure 2-37.
The CDC Summary report in the 0in_cdc.rpt file also shows this waive change (see
Example 2-4). In addition, notice in the CDC Promotion Summary section, there is now
only 13 promoted protocol checkers versus the 14 promoted protocol checkers (see
Example 2-3 on page 40) before waiving Combo Logic.
Figure 2-37. Waived Status
Example 2-4. CDC Summary with Waived in the 0in_cdc.rpt File
CDC Summary
=================================================================
Violations (8)
-----------------------------------------------------------------

October 2008
Static CDC
Project Mode

Unknowns (9)
-----------------------------------------------------------------
Evaluations (2)
-----------------------------------------------------------------
Waived (1)
-----------------------------------------------------------------
Proven (4)
-----------------------------------------------------------------
Filtered (0)
-----------------------------------------------------------------
<None>
CDC Promotion Summary

=================================================================
Promoted protocol checkers (13)
Unpromoted checkers (see 0in_detail.log) (11)
=================================================================

October 2008
Static CDC
Project Mode
Export Directives
The 0in_cdc GUI enables the user to export directives to an output file as shown in
Figure 2-38.
right-click in the Workspace field
select -> Export -> Overwrite -> All...
Figure 2-38. Workspace Directives Tab Export
This invokes the Export Directives window as shown in Figure 2-39.
Figure 2-39. Export Directives Window
Enter your desired file name. For this tutorial, the file name is export_directives.v.
File name: export_directives.v
select -> Save

October 2008
Static CDC
Project Mode
This automatically generates the export_directives.v file (see Example 2-5) in the local
working directory
Example 2-5. export_directives File
module rtld_ctrl;
//0in set_constant scan_mode 1'b0

//0in set_cdc_report -scheme combo_logic -from pass_en[1] \
-to check_en_r1 -tx_clock cpu_clk_in -rx_clock mac_clk_in \
-severity waived
endmodule
10. Correct the missing synchronizer error discussed in Step 9, starting on page 47.
Verify the corrections are correct by cleaning your work directory and then rerun the
design.
11. This tutorial is now complete for the Project Mode. Close the 0in_cdc GUI as follows:
File -> Save -> Project
File -> Quit
Notice that a myProj_Static_CDC directory and a myProj_Static_CDC.zpf file are

automatically generated.
Do the following to reopen your Project:
0in_cdc myProj_Static_CDC.zpf
This opens the 0in_cdc GUI with the Project loaded.

October 2008
Static CDC
Project Mode
cdc_control.v File
Global directives in a control file can be used to control CDC analysis as shown in
Example 2-6.
Example 2-6. cdc_control.v File
module ctrl;
// 0in set_cdc_reconvergence -depth 10
// 0in set_cdc_clock cpu_clk_in -period 50

// 0in set_cdc_clock core_clk_in -period 60
// 0in set_cdc_clock mac_clk_in -period 50
endmodule
The set_cdc_reconvergence global directive sets the reconvergence depth. The default
reconvergence depth is 1 cycle, which corresponds to combinational reconvergence. In this
example, the depth is set to 10. The CDC compiler only detects reconverging values if they
reconverge within the reconvergence depth from the cycle the values are received.
The set_cdc_clock global directive specifies clocks with their characteristics and redefine
the clock domains. No two set_cdc_clock global directives can specify the same clock. The
user must specify one or more clocks.
The set_constant global directive sets scan_mode to a constant 0. This is done to turn scan
mode off.
Create a Project Using a Script

Following is the step to create a Project using a script:
Run cdc as follows:

make cdcui
The make cdcui script runs the following (see “Makefile File” on page 59):
0in_cdc -p myproj -d $(DUT) \
-f $(SRCLIST) -ctrl $(CTRLFILE) \
The -p myproj option creates a Project named myproj.

Running this script invokes the 0in_cdc GUI as shown in Figure 2-40.

October 2008
Static CDC
Project Mode
Figure 2-40. 0in_cdc GUI Created with a Script
Do the following to save the Project and close the 0in_cdc GUI:
select -> File -> Save -> Project
select -> File -> Quit -> Yes
Notice that a myproj directory and a myproj.zpf file are automatically generated.
0in_cdc myproj.zpf
This opens the 0in_cdc GUI with the Project loaded as shown in Figure 2-40.

October 2008
Static CDC
Batch Mode
Batch Mode
To run this tutorial in batch mode, copy the example directory to your local directory (see “Data
Preparation” on page 22).
Makefile File
The Makefile file is shown in Example 2-7. This Makefile file contains the commands to run
this example.
Example 2-7. Makefile File
#####################################################################
#
# DUT Sources
#
#####################################################################
DUT=demo_top
SRCLIST=filelist
CTRLFILE=cdc_control.v
DB = Output_Results/0in_cdc.db
#########################################################################
#
#
# Make Targets
#
#########################################################################
#
all: cdc\
view
report_clock:
0in -od Output_Results -cmd cdc -d $(DUT) \
-f $(SRCLIST) -ctrl $(CTRLFILE) -report_clock \
cdc:
view:
0in_cdc \
$(DB)
cdcui:
0in_cdc -p myproj -d $(DUT) \
clean:
0in_clean
rm -rf 0in_seed_control.v 0in_prove.ist 0in_tb_template.v

October 2008
Static CDC
Batch Mode
rm -rf csrc simv* work transcript export_directives.v Output_Results

rm -rf *.vcd
rm -rf ./waves/*.dsn ./waves/*.trn \
ncwork/inc* ncwork/.inc* ncverilog.key \
./verilog.* .nclog hal.log INCA_libs \
./replay* ./nWaveLog ./verdiLog ./vfastLog \
*~ *.sv *.rc *.log *.rpt
######################################################################
Running CDC in Batch Mode

Following are the steps to run this tutorial example in Batch Mode:
1. Run cdc as follows:

make cdc
The make cdc script runs the following (see “Makefile File” on page 59):
-f $(SRCLIST) -ctrl $(CTRLFILE)
The -od <output_directory> option is the directory to store all output files. Note
that the -od option can only be used before the -cmd option.
The -cmd <command_string> passes the succeeding arguments to the 0in shell as a
single command.
The -d option specifies the target design module name. Note that the filelist file
contains the testbench for this tutorial. To prevent the tool from performing RTL
analysis on the testbench, the top-level RTL module to be analyzed is specified using the
cdc -d command.
The -f <verilog_command_file> file containing additional arguments or source

filenames.
The -ctrl option specifies the Verilog control file.
The screen displays the CDC Summary (see Example 2-8) and Error/Warning Summary (see
Example 2-9. This information is also available in the automatically generated
Output_Results/0in.log file.
The cdc command evaluates the RTL netlist and finds violations. These violations are a
mixture of errors that must be fixed and rule violations that do not apply to any current design
style. Also, cdc finds unknowns (potential rule violations). The user can promote checks for
these potential rule violations and then run them on simulation (see “Protocol CDC Tutorial” on
page 67).

October 2008
Static CDC
Batch Mode
Example 2-8. CDC Summary Information in the 0in.log File
CDC Summary
=================================================================
Violations (9)
-----------------------------------------------------------------
Unknowns (9)
-----------------------------------------------------------------
Evaluations (2)
-----------------------------------------------------------------
Waived (0)
-----------------------------------------------------------------
<None>
Proven (4)
-----------------------------------------------------------------
Filtered (0)
-----------------------------------------------------------------
<None>
Example 2-9. Error/Warning Summary Information in the 0in.log File

-----------------------------------------------------------
6 Warning hdl-101 Unable to promote protocol checker
(unsupported scheme).
2 Warning hdl-105 Memory Write-through condition could
be undetected.
clock domains.
19 Warning hdl-51 Port assigned to inferred clock
domain.

October 2008
Static CDC
Batch Mode
The automatically generated 0in_cdc_design.rpt file contains the Clock Group Summary
information (see Example 2-10), General Design Information (see Example 2-11), and Port
Domain information (see Example 2-12).
In general, you should check the 0in_cdc_design.rpt file to make sure all the clocks are inferred
correctly. If they are not, then you need to make changes to the control (cdc_control.v) file (see
Example on page 57).
The Clock Group Summary displays the total counts for each type of clock group (see
Example 2-10). There are two types of clock groups: user-specified and inferred. All user-
specified clocks are defined by the user with the set_cdc_clock global directive. Inferred
clock groups are clocks that are not specified, but inferred by the CDC tool.
Example 2-10. Clock Group Information in the 0in_cdc_design.rpt File
Clock Group Summary for ’demo_top’

==================================

===========================

-----------
cpu_clk_in
cpu_clk

-----------
core_clk_in
core_clk
fifo_1_d.wr_clk
fifo_1_d.u0.Wclk
fifo_0_h.wr_clk
fifo_0_h.u0.Wclk

-----------
mac_clk_in
mac_clk
fifo_1_d.rd_clk
fifo_1_d.u0.Rclk
fifo_0_h.rd_clk
fifo_0_h.u0.Rclk
crc_1.clk

=====================

October 2008
Static CDC
Batch Mode
None

====================
None
The General Design Information displays the total counts for each basic design element (see
Example 2-11).
Example 2-11. Design Information in the 0in_cdc_design.rpt File

==========================
Number of RAMs = 2

=========================
RAMs:
-----
fifo_1_d.u0.data
fifo_0_h.u0.data
The Port Domain Information displays the clock domains identified for the design’s ports (see
Example 2-12). The following defines the port domain information:
o Port — Port name.
o Direction — The valid directions are: input, output, and inout
o Constraint — Identifies clock and reset ports.
o Clock Domain — Clock domain of the port. The {clock} indicates the primary clock
for the domain, and {clock1 | clock2 |...} indicates the clock domain is ambiguous.
The relevant primary clocks are listed. An async indicates the port is marked as an
asynchronous port using the set_cdc_port_domain global directive.
o Type — Method used to determine the clock domain. User indicates the clock
domain is assigned by the set_cdc_clock global directive or the port is marked
asynchronous (using set_cdc_port_domain global directive). Inferred indicates
CDC analysis identified the domain (or potential domains).
Example 2-12. Port Domain Information in the 0in_cdc_design.rpt File

=========================

October 2008
Static CDC
Batch Mode

----------------------------------------------------------------------
core_clk_in

scan_clk input ---
2. Invoke the 0in_cdc GUI as follows:

make view
The make view script runs the following (see “Makefile File” on page 59):
0in_cdc \
$(DB)
This command loads the 0in_cdc.db database file and invokes the 0in_cdc GUI with the
CDC violations displayed as shown in Figure 2-41.

October 2008
Static CDC
Batch Mode
Figure 2-41. 0in_cdc GUI Invoked in Batch Mode
3. From this point on, the Project Mode and Batch Mode are identical.
Continue this tutorial by following the steps in the Project Mode, starting with Step 9 on
page 43.

October 2008
Static CDC
Solution
Solution
In the demo_top.v file, add the solution information shown in Table 2-3.
Table 2-3. MISSING SYNCHRONIZER Solution

Violation Solution
MISSING SYNCHRONIZER 127 //SOLUTION TO MISSING SYNC PROBLEM
128 reg init_done_rsol1, init_done_rsol2;
This violation happens because the 129
init_done signal that is in the 130 always @ (posedge core_clk)
cpu_clk domain is driving a FSM 131 begin
in the core_clk domain. 132 init_done_rsol1 <= init_done;
133 init_done_rsol2 <= init_done_rsol1;
134 end
259 IDLE: if (init_done_rsol2) //SOLUTION TO
MISSING SYNC PROBLEM

October 2008
Chapter 3
Protocol CDC
Protocol CDC Tutorial

This tutorial shows how to run 0-In CDC with checker directives for promotion to simulation.
In this tutorial, the following is demonstrated:
• Create a Project using a script.

• Run CDC and observe the summary report.
• Correlate how checker directives are promoted for simulation.
• Generate the internal simulator arguments file using ccl and your simulator.
• Run simulation using your simulator.
• Invoke the 0-In CDC GUI and examine the promoted checkers.
$HOME_0IN/share/examples/Verilog/CDC/Protocol_CDC
Data Preparation
directory. The tutorial directory include the following:
Makefile
cdc_control.v
filelist
SRC/
demo_top.v
dff2_sync.v
dpmem2clk.v
tb.v

October 2008
Protocol CDC
CDC Protocol Analysis Flow

Figure 3-1. CDC Protocol Analysis Flow Diagram
Run Simulation
Y
Violations? Debug and Remove Violations
Review Coverage
N Modify or Write New Tests

Covered?
CDC Protocol Done
1. Running simulation is the first step in the CDC Protocol analysis flow. Following are the
steps to run simulation:
• Run Static CDC to identify the CDC signals and the related results, including
violations. Since the tool is designed in a sequential (incremental) testing process,
the data generated in structural verification is used in the protocol verification. Static
CDC generates the 0in_cdc_ctrl.v file, which has checker directives that are
promoted for the protocol verification. Protocol checkers are generated for
violations, unknowns, and evaluations unless explicitly turned off.
• Generate the internal simulator argument file by running the target simulator to
compile the assertions, which generates the database of compiled checkers contained

October 2008
Protocol CDC
in the 0in_check.db file. The output of the simulator run is the 0in_checker.rpt file
that has detailed information of the checkers and signals for which these checkers
are generated with their respective ID. The description of the checker details what
the assertion tests.
• Run the simulator with the generated checker file, which results in the design being
simulated with the assertions and the output reports are generated. The
0in_checksim.db database is created, which can be used to examine the violations,
firings, unknowns, etc.
2. The next step is to debug the violations in the design. Use the 0-In CDC GUI to debug
the simulation results. Then edit the source code to remove the violations and firings that
shows the protocol what the assertion is checking for that is not being respected.
3. When the design is violation free, the next step is to review the coverage. Observe if the
protocol checker written for a particular case is covered at an acceptable percentage to
meet the coverage goal. Also, see if the essential checks are covered for a checker. If
there is no firing but the coverage percentage is low, then write a better checker to obtain
the coverage goal.

October 2008
Protocol CDC
Project Mode
Project Mode
Create a Project Using a Script
Following is the step to create a Project using a script:
Run cdc as follows:
make cdcui
The make cdcui script runs the following script (see “Makefile File” on page 97):
0in_cdc -p myProj_Protocol_CDC -d $(DUT) \

The -p myProj_Protocol_CDC option creates a Project named myProj_Protocol_CDC.

Running this script invokes the 0in_cdc GUI as shown in Figure 3-2.
The question mark icon (?) in the Project tab Workspace window Status column denotes the
files have not been compiled into the project or the source has changes since the last compile.
The check mark icon indicates the files are compiled successfully.

October 2008
Protocol CDC
Project Mode
1. Compile the design using the 0in_cdc GUI.

The first phase of CDC verification is to compile the CDC model of the design block by
running the cdc compile command. This creates the logic and supporting files for CDC
verification.
select -> Compile -> Compile All
or select the Compile All icon from the Toolbar as shown below:
Compile All
This invokes the Compile Options window as shown in Figure 3-3. The compile
options allows the user to set project wide options for Verilog and VHDL.
On the Common tab, type the correct information. For this tutorial, the Top Module is
demo_top, the Work Library is work, and the Set Output Directory is Output_Results.
Top Module -> demo_top
Work Library -> work
select -> Browse...
navigate to Protocol_CDC
select -> OK
Append to path in Set Output Directory -> /Output_Results
select -> OK

October 2008
Protocol CDC
Project Mode
Figure 3-3. Compile Options Common Tab Window
This step creates the work directory and the automatically generated 0in.log and
0in_detail.log files in the Output_Results directory.
Notice in Figure 3-2 on page 70 that the question mark icons (?) are now check mark
icons, which indicates the files are compiled successfully.
2. Analyze the clocks.

To analyze the clocks, the cdc_control.v control file is required. For this tutorial, the
control file was added using the Project script (see “Create a Project Using a Script” on
page 70).
Run the Analyze Clocks step as follows:
select -> CDC -> Analyze Clocks

October 2008
Protocol CDC
Project Mode
or select the Analyze Clocks icon from the Toolbar as shown below:
Analyze Clocks
This action invokes the CDC Options window. Notice that the cdc_control.v file is
already added.
select -> OK
This step automatically generates the output files and directory in the Output_Results
directory.
3. Perform CDC checks by running CDC as follows:

CDC -> Run CDC
or select the Run CDC icon from the Toolbar as shown below:
Run CDC
This invokes the Results window CDC Checks tab with the check violations as shown
in Figure 3-4.

October 2008
Protocol CDC
Project Mode
Figure 3-4. Results Window with Check Violations
View the automatically generated Output_Results/0in_cdc_ctrl.v file.

This file contains the automatically generated checker directives for promotion to
simulation and/or formal verification. Example 3-1 is the cdc_dsel checker directive
generated for a DMUX synchronization. (see CDC Compiler User Guide for
information).
Example 3-1. cdc_dsel Checker Directive in the 0in_cdc_ctrl.v File
/* 0in cdc_dsel
-tx_data fstp[7:1]
-rx_data crc_1.scramble
-tx_clock cpu_clk_in
-rx_clock mac_clk_in
-tx_data_select init_done
-rx_data_select init_done_r2
-tx_min ‘P_cpu_clk_mac_clk_tx_min
-areset ( ( ! rst) )
-name dmux_30303
-module demo_top
-inferred
*/
This checker ensures that a signal between two clocks (cpu_clk and mac_clk), where
the transmitter’s data select signal (init_done) drives the select input of a data
multiplexor (init_done_r2) in the receiver, is held stable enough for the transmit signal

October 2008
Protocol CDC
Project Mode
(fstp[7:1]) to be sampled reliably by the receiver (crc_1.scramble). This ensures

that the data remains stable while the data select signal asserts.
Notice in this 0in_cdc_ctrl.v file that several checker directive have a x0in token mark.
For example,
/* x0in cdc_sync
-tx_var tx_en
-tx_clock core_clk_in
-tx_min ‘P_core_clk_mac_clk_tx_min
-name pulse_sync_13276
-module demo_top
-inferred
*/
The x0in token marks the directives as plain comments that are skipped by the 0-In
compilers (to save time in a default flow). To mark individual directives as 0-In
comments for processing by the 0-In compilers, delete the x characters. Use this to
selectively promote checkers.
The x token must be removed by the user for the checker directive to be promoted.
In addition to the 0in_cdc_ctrl.v file, the following files and directory are automatically
generated in the Output_Results directory:
• 0in.log — A short log file that is a copy of the standard output.
• 0in_cdc.db — The CDC database for examining in the 0-In CDC GUI
environment.
• 0in_cdc.rpt — The clock domain crossing (CDC) report.
• 0in_cdc_ctrl.v — The clock domain crossing checker control file contains
suggested CDC protocol checker directives for signals crossing clock domains
(for use with simulation and the formal tools).
• 0in_cdc_design.rpt — The CDC design report.
• 0in_cdc_param.inc — The checker parameter file.
• 0in_design.rpt — A design summary.
• 0in_detail.log — A detailed log of the transcript.
• 0in_cache/ — Working directory for storing internal data and checker logic.
4. Save and exit from the 0in_cdc GUI as follows:

File -> Quit -> Yes -> Yes

October 2008
Protocol CDC
Project Mode
5. Generate the internal simulator arguments file for the design using the ccl command
and your simulator (see the “Makefile File” on page 97). Following is the command to
use the ModelSim simulator:
make ccl_mti
The make ccl_mti script runs the following (see “Makefile File” on page 97):
0in -od Output_Results -cmd ccl -ctrl $(CTRLFILE2) -sim mti \
-f $(SRCLIST) -d $(DUT)
single command.
The ccl command synthesizes the checkers for the design.
The -ctrl <control_file_name> option specifies the Verilog checker control file.
The -sim mti command specifies that ModelSim is the simulator to be used for
simulating the design with the CDC protocol assertions.
The -f <Verilog_command_file> option containing additional arguments or source
filenames.
The -d <design_module> option specifies the target design module name.
Following are the automatically generated output files and directory in the Output_Results
directory:
• 0in.log — A short log file that is a copy of the standard output.
• 0in_check.db — The 0-In database file showing the checkers created and
incorrect checker directives.
• 0in_checker.rpt — This report contains the results of checker synthesis.
• 0in_sim.arg — Simulation argument file used to invoke simulation with
assertions.
• 0in_sim.arg.vsim — This file specifies the top-level modules containing the
checker logic.
• 0in_sim.arg.vsimrun — Contains information for ModelSim.
• 0in_sim_modules.lst — Contains the simulation module list.
The other files in the Output_Results directory are generated using the 0in_cdc GUI.

October 2008
Protocol CDC
Project Mode
The 0-In Checker Summary is displayed on the screen. The 0in_checker.rpt file contains
detailed information on the checkers as shown in Example 3-2.
Observe the total number of checkers generated and the type of checkers generated. For
example, in this design there is a total of 17 checkers with each checker applying a
different number of checks for a total of 27 checks as shown in the Checker Summary
section. As you scroll down, the Checker List section shows what all the checkers are
generating. The Checker Details section displays the functionality of each checker.
Example 3-2. Checker Report in the 0in_checker.rpt File
-------------------------------------------------------------------
0-In Check V2.6 (rh3_x86_64) 07/31/08
Checker Report
-------------------------------------------------------------------
Report Generated : Tue Aug 5 16:48:13 2008
Design Name : demo_top
Checker File : 0in_sim.arg
Checker File Date : Tue Aug 5 16:48:13 2008
-------------------------------------------------------------------
Checker Directives Recognized : 17
Checker Directives Processed : 17
Incorrect Checker Directives : 0
Checkers Synthesized : 17
Checkers with Warnings : 0
-------------------------------------------------------------------
Checker Summary
-------------------------------------------------------------------
Checker Type Directives Checkers Checks
-------------------------------------------------------------------
assert 1 1 1
assert_timer 1 1 1
cdc_dsel 2 2 6
cdc_glitch 1 1 1
cdc_hamming_distance_one 4 4 4
cdc_sample 4 4 8
cdc_sync 2 2 2
multi_clock_fifo 2 2 4
--------------------------------------------------------------------
All 17 17 27
--------------------------------------------------------------------
--------------------------------------------------------------------
Checker List
--------------------------------------------------------------------
assert demo_top.zivar
assert_timer demo_top.cs
cdc_dsel demo_top.dmux_12402
cdc_glitch demo_top.combo_logic_85239
cdc_hamming_distance_one demo_top.bus_two_dff_53361
cdc_sample demo_top.multi_bits_76265

October 2008
Protocol CDC
Project Mode
cdc_sample demo_top.no_sync_2628
cdc_sync demo_top.two_dff_5840
multi_clock_fifo demo_top.we_1_re_1
multi_clock_fifo demo_top.we_re
--------------------------------------------------------------------
Checker Details
--------------------------------------------------------------------
--------------------------------------------------------------------
Type/Name : assert demo_top.zivar
Checkerware Instance : zi_cm_demo_top.demo_top_31c26a68_inst_0.U0.U3
Description : Ensures that a specified signal asserts.
Message : <None>
Location : File /Protocol_CDC/SRC/demo_top.v, Line 187
Directive : assert -var $0in_delay(!empty && !empty_1) -active
pass_valid -clock mac_clk
Module : demo_top
Check assert : On <Default On>
-zivar : $0in_delay((( ! empty) && ( ! empty_1)),1'b1,mac_clk)
-sop : 1'b0
-pos : 1'b0
-eval : 1'b0
-clock : mac_clk
-reset : 1'b0
-areset : 1'b0
-active : pass_valid
-support : 1'b0
-nv : 1'b1
-name : zivar
Checker Class : Usr
Checker Internal
------------------------------------------------------------------
Type/Name : assert_timer demo_top.cs
Description : Ensures that a signal asserts for the specified
cycle times.
Message : <None>
Directive : assert_timer -max 8 -clock cpu_clk
Module : demo_top
Check max : On <Default Off>
Check min : Off <Default Off>
-zivar : cs
-max : 4'b1000
-active : 1'b1
-clock : cpu_clk
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : cs
Checker Class : Ifc
Checker External on Interface
-------------------------------------------------------------------

October 2008
Protocol CDC
Project Mode
Type/Name : cdc_glitch demo_top.combo_logic_85239

Description : Ensures that the input signal to a specified
register does not change more than
once within a clock period
Message : <None>
Location : File /Protocol_CDC/0in_cdc_ctrl.v, Line 185
Directive : cdc_glitch
-var check_en_r1
-clock mac_clk_in
-name combo_logic_85239
-module demo_top
-inferred
Module : demo_top
Check cdc_glitch : On <Default On>
-zivar : check_en_r1
-used : 1'b0
-active : 1'b1
-clock : mac_clk_in
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : combo_logic_85239
Checker Class : CDC
Checker Internal
-------------------------------------------------------------------
...
...
-------------------------------------------------------------------
Incorrect Checker Directive Details (0 directives)
-------------------------------------------------------------------
6. Run the simulation as follows:

make check_mti
The make check_mti script runs the following (see “Makefile File” on page 97):
vlib work
qverilog -f $(SRCLIST) -f Output_Results/0in_sim.arg \
-R -c -wlf verilog.wlf -do "log -r /*;run -all;exit" \
-pli $(HOME_0IN)/lib/lib0InLoadMTIPLI.so \
-l run_check_mti.log
The vlib command creates the design library.

The qverilog command invokes the vlog, vopt, and vsim commands. The
qverilog command compiles (vlog), optimizes (vopt), and simulates (vsim) the
Verilog design in a single step. All vsim options are supported and are applied through
the qverilog -R option.
The -R <vsim_options> specifies valid vsim options to be applied to simulation.
The -R option must come after all vlog and vopt options of the qverilog
command string.

October 2008
Protocol CDC
Project Mode
The -c option specifies that the VSIM simulator is run in the command-line mode.
The -wlf option specifies the name of the wave log format (WLF) file to create. The
default file name is vsim.wlf.
The -do “<command_string>” instructs vsim to use the command(s) specified by
<command_string> rather than the startup file specified in the .ini file, if any. Multiple
commands should be separated by a semi-colon (;).
The log command creates a wave log format (WLF) file that contains the simulation
data for all HDL objects whose names match the provided specifications. The
log -r /* command specifies to recursively log all objects in the design.
The -pli “<object_list>” loads a space-separated list of PLI shared objects (.so).
The list must be quoted if it contains more than one object.
The -l <filename> option saves the contents to <filename>.
Following are the automatically generated output files and directory (notice these files are in
your working directory and not the Output_Results directory). This is because the qverilog
command has no output directory option):
• 0in_checksim.db — Database showing checkers created for examining in the 0-
In CDC GUI environment.
• qverilog.log — Log file that contains the output from vlog, vopt, and vsim.
• run_check_mti.log — The detailed log of the transcript.
• verilog.wlf — Log file that contains the simulation data for all HDL objects
whose names match the provided specifications.
• work/ — The work library in the current directory.
There is a self-testing testbench that runs on the design. As you can see, “TEST
PASSED!” is displayed on the screen. This information is also available in the
run_check_mti.log file (at the very end) as shown in Example 3-3.
Example 3-3. Snippet of the run_check_mti.log File
Failed compares = 0
Good compares = 5027
TEST PASSED!
** Note: $finish : SRC/tb.v(143)

Time: 101141 ns Iteration: 0 Instance: /tb

October 2008
Protocol CDC
Project Mode
0-In Info: Generating reports ... at time 101141000

Report Generated : Wed Aug 6 08:43:12 2008
Database File : /Protocol_CDC/0in_checksim.db
Simulation Date : Wed Aug 6 08:43:10 2008
Checker File Date : Tue Aug 5 16:48:13 2008
Checker Firings Summary by Checker Type

----------------------------------------------------------------------
Checker Type Checkers Checkers Checkers
with Firings w/o Evaluations
----------------------------------------------------------------------
cdc_glitch 1 0 0
cdc_dsel 2 2 0
cdc_sample 4 4 0
cdc_sync 2 0 0
assert 1 0 0
assert_timer 1 0 0
----------------------------------------------------------------------
Total Checker Summary 17 6 0
----------------------------------------------------------------------
Checkers Covered Summary (Fire checkers excluded)

----------------------------------------------------------------------
Checkers Checkers Checkers
Total Covered Evaluated Proven
----------------------------------------------------------------------
17 7 ( 41%) 17 (100%) 0 ( 0%)
----------------------------------------------------------------------
7. Invoke the 0-In CDC GUI as follows:

make view
0in_cdc \
$(DB)
This invokes the 0-In CDC GUI with the 0in_cdc.db file loaded as shown in Figure 3-5.

October 2008
Protocol CDC
Project Mode
Figure 3-5. Results Window with 0in_cdc.db Loaded
Load the 0in_checksim.db file as follows:

File -> Merge Database...
This invokes the Merge Database window as shown in Figure 3-6.
Figure 3-6. Merge Database Window
select -> 0in_checksim.db -> Open
With the 0in_checksim.db file loaded, the Results window CDC Checks tab shows the
results of the CDC verification as shown in Figure 3-7.

October 2008
Protocol CDC
Project Mode
Figure 3-7. Results Window CDC Checks Tab
Even though the test passed, a number of assertions fired. “CDC-FX Tutorial” on
page 111 explains how to use CDC-FX to catch these bugs automatically and make this
test fail.
Figure 3-11 on page 85 shows the waveform for the Check Multiple Bits expanded
signal demo_top.multi_bits_76265 in the GUI. Following are the step to invoke this
signal in the GUI as shown in Figure 3-8.
right-click on Checker
select -> Show -> Simulation Firings...
Figure 3-8. Show Simulation Firings
This invokes the Firings window as shown in Figure 3-9.

October 2008
Protocol CDC
Project Mode
select -> setup: Signature 1 : (All Firings)

select -> OK
Figure 3-9. Firings Window
It is required to have the verilog.wlf file loaded. If it is not loaded, then the Load
Waveform Database window automatically invokes as shown in Figure 3-10.
left-click -> verilog.wlf -> Open
This invokes the GUI with the waveform loaded as shown in Figure 3-11 with All
Firings selected.
Figure 3-10. Load Waveform Database Window
Once the verilog.wlf file is loaded, it is not required to load it with each additional run.
To resize the waveform for viewing, use the Zoom In, Zoom Out, Zoom Full, and
Zoom in on Active Cursor icons (circled in red in Figure 3-11).

October 2008
Protocol CDC
Project Mode
Figure 3-11. Waveform Window
Figure 3-11 shows that the Multiple Bits check, with an ID of multi_bits_76265, fired
during simulation with the first firing at 378ns. Refer to the
Output_Results/0in_checker.rpt file for a description of this cdc_sample checker type as
shown in Example 3-4, which is highlighted in bold.
Example 3-4. demo_top.multi_bits_76265 Checker in 0in_checker.rpt File
Checker Details
------------------------------------------------------------------------
Type/Name : cdc_sample demo_top.multi_bits_76265
Description : Ensures that data between two clock domains remain
stable in the transmit domain for one transmit
clock cycle before, and for one transmit clock
cycle after, it is sampled in the receive domain.
Message : <None>
Location : File /Protocol_CDC/Output_Results/0in_cdc_ctrl.v,
Line 146
Directive : cdc_sample
-tx_var crc_seed[7:1]
-rx_var crc_1.crc_16
-name multi_bits_76265
-module demo_top
-inferred

October 2008
Protocol CDC
Project Mode
Module : demo_top
Check hold : On <Default On>
Check setup : On <Default On>
-tx_var : crc_seed[7:1]
-rx_var : crc_1.crc_16
-rx_enable : 1'b1
-tx_clock : cpu_clk_in
-rx_clock : mac_clk_in
-tx_reset : 1'b0
-rx_reset : 1'b0
-areset : ( ! rst)
-active : 1'b1
-support : 1'b0
-nv : 1'b1
-name : multi_bits_76265
Checker Class : CDC
Checker Internal
---------------------------------------------------------------
Figure 3-12 shows the schematic view for the Check Multiple Bits expanded signal
demo_top.multi_bits_76265. Following are the step to invoke this schematic view of
the signal:
right-click on Checker
To display the net names in the schematic view, do the following:

right-click in schematic window
select -> Show -> Net Names

October 2008
Protocol CDC
Project Mode
Figure 3-12. demo_top.multi_bits_76265 Checker Schematic View
From Example 3-4 on page 85 and Figure 3-12 you can observe the following data:
Transmit data = crc_seed
Transmit clock = cpu_clk_in
Receive data = crc_16
Receive clock = mac_clk_in
In Figure 3-11 on page 85, you can observe in the waveform that all firings are there
during the cpu_clk_in transmit clock cycle and the crc_16 transmit data has
changed in the previous clock cycle. Therefore, every time the data is sampled in the
receive clock domain with the positive clock edge of the mac_clk_in.
Remember the description requirement in Example 3-4 for the cdc_sample checker is as
follows:
o Ensures that data between two clock domains remain stable in the transmit
domain for one transmit clock cycle before, and for one transmit clock cycle
after, it is sampled in the receive domain.
The requirement is violated four times in one transmit clock period, which results in four
firings.
8. To configure the columns for the Results window shown in Figure 3-13, do the
following:
left-click on down arrow

October 2008
Protocol CDC
Project Mode
check to make visible

select -> OK
Figure 3-13. Configure Columns
Figure 3-14 shows the Results window with the signals, clocks, modules, and files
hidden as directed in the Configure Columns in Figure 3-13. Also, the order of the
columns can be changed by selecting the column and dragging it to a new location as
shown in Figure 3-15.
Do the following as shown in Figure 3-15 to return to the default column order:
right-click in the Results window
select -> View -> Reset Column Order

October 2008
Protocol CDC
Project Mode
Figure 3-14. Results Window with Configured Columns
Figure 3-15. Results Window with the Columns Reconfigured

October 2008
Protocol CDC
Project Mode
9. The Details window displays the Checker information. Do the following to activate this
window as shown in Figure 3-16:
select -> View -> Details
Figure 3-16. View Menu
The Details window is populated by selecting the Checker in the Results window that
you want to view. Figure 3-17 shows the Details window populated with the details of
the demo_top.multi_bits_76265 Checker.

October 2008
Protocol CDC
Project Mode
Figure 3-17. Details Window

October 2008
Protocol CDC
Project Mode
Protocol Monitors track coverage, which can be viewed in the Workspace window
Design tab as shown in Figure 3-18.
Figure 3-18. Workspace Window Design Tab
Expand the cdc_sample no_sync_2628 checker as shown in Figure 3-19.

In the no_snyc_2628 checker case, all scenarios are not covered. It is only 40%
covered. That is All Zero bits are covered, but All One, All Zero to One, and All One to
Zero bits are not covered.

October 2008
Protocol CDC
Project Mode
Figure 3-19. Coverage by Instance
10. The running of this tutorial is now complete for the Project Mode. Close the 0in_cdc
GUI as follows:
select -> File -> Quit -> Yes
Notice that a myProj_Protocol_CDC directory and a myProj_Protocol_CDC.zpf file are

automatically generated.
0in_cdc myProj_Protocol_CDC.zpf
This opens the 0in_cdc GUI with the Project loaded.
Conclusion
The CDC compiler analyzes the design netlist and identifies logic involving CDC signals that
matches various pattern templates. Each occurrence of logic that matches a template is called a
CDC scheme.

October 2008
Protocol CDC
Project Mode
Looking at the Results window in Figure 3-20 on page 96, the following conclusions can be
drawn:
• Violation and Firing (3) — The CDC scheme’s severity level is Violation and its
protocol is violated in simulation.
Formal firings indicate must-fix issues. For this tutorial, these missing synchronizers
should be removed as they are carried over from the “Static CDC Tutorial” on page 17.
When the violation fires, it means that it violated the protocol also. When editing the
source code to remove the bugs, keep in mind that it should also take care of the firings
(protocol violations).
• Violation (6) — The CDC scheme’s severity level is Violation.
Observe that there are two types of violations in the Simulation column: Not Promoted
(5) and Covered (see Figure 3-20).
o Not Promoted — This means that they have not been checked for protocol violations
with checkers. That is, for some reason the checkers for them were not generated.
There can be several reasons why the checkers for the particular scheme was not
promoted. In this example, the Not Promoted checkers are in association with the
following:
a. Proven — As discussed in the Static CDC Tutorial, if a CDC scheme is
proven, then it does not need a protocol verification because the protocol is
already respected.
b. In the case of the Combo Logic Violation ID combo_logic_46571, observe
in the Output_Results/0in_cdc_ctrl.v file that another checker for Combo
Logic has exactly the same check. Therefore, the checks are redundant and
Not Promoted. That is, /* 0in cdc_glitch has the following:
combo_logic_46571 has the same checks as combo_logic_85239
c. Memory Sync does not have checkers, the result being memory_sync_17786
and memory_sync_1560 are Not Promoted. The user is expected to generate
memory checkers for Memory Sync to prevent the “read” while “write” or
“write while read” conditions. The “write through” should be checked for
and “no new data” should be written before the previous data has been read.
o Covered — This means that the protocol associated with these violations is correct.
• Firing (3) — The CDC scheme’s protocol is violated in simulation.
Simulation violated the scheme’s protocol. The number of firings is the number of times
the protocol is violated.
• Unknown (2) — The CDC scheme’s severity level is Unknown.

October 2008
Protocol CDC
Project Mode
This is a potential rule violation. Unknowns are usually promoted to CDC transfer
protocol checks. Most Unknowns have designated CDC protocol checkers that the CDC
compiler configures automatically.
Unknowns with Covered and Promoted are good. However, if an Unknown is Not
Covered, then the testbench is not able to check for all possible cases. The user should
make the appropriate changes to include all possible cases, unless the full or desired
coverage is obtained.
• Not Covered (2) — Not covered and not fired.
The checker is not covered and did not fire, which means that the tool cannot conclude if
there is a protocol violation or not.
When a checker is Not Covered but is Evaluated, it means that the testbench has not
been able to check for all possible cases. The user should make the appropriate changes
to include all possible cases, unless the desired coverage is obtained.
• Covered (4) — The CDC scheme’s protocol checker’s cover points are covered in
simulation.
This means that the checker is covered and did not fire.
• Proven (4) — The CDC scheme’s protocol cannot be violated.
A checker that is proven by statical verification is not capable of firing.
In summary, the only checkers that the user is sure follows the correct protocols are the ones for
which protocol is promoted, which means the following:
• Checker has no violation.

• Checker is not in the category of Not Promoted.
• Checker is Covered.

October 2008
Protocol CDC
Project Mode
Figure 3-20. Expanded Results Window

October 2008
Protocol CDC
Batch Mode
Batch Mode
To run this tutorial in batch mode, copy the example directory to your local directory (see “Data
Preparation” on page 67).
Makefile File
this example.
########################################################################
#
# DUT Sources
#
########################################################################
DUT=demo_top
SRCLIST=filelist
CTRLFILE2=Output_Results/0in_cdc_ctrl.v
CTRLFILE3=0in_cdc_ctrl.v
DB = Output_Results/0in_cdc.db
#########################################################################
#
# Make Targets
#
#########################################################################
all: cdc\
ccl_mti \
check_mti \
view
cdc:
cdcui:
0in_cdc -p myProj_Protocol_CDC -d $(DUT) \
view:
0in_cdc \
$(DB)
view_checksim_batch:
0in_cdc \
0in_cdc.db
ccl_nc:
0in -cmd ccl -ctrl $(CTRLFILE3) -sim nc -f $(SRCLIST) \
-d $(DUT)

October 2008
Protocol CDC
Batch Mode
ccl_nc3:
0in -cmd ccl -ctrl $(CTRLFILE3) -sim nc3 -f $(SRCLIST) \
-d $(DUT)
ccl_vcs:
0in -cmd ccl -ctrl $(CTRLFILE3) -sim vcs -f $(SRCLIST) \
-d $(DUT)
ccl_mti:
check_mti:
vlib work
qverilog -f $(SRCLIST) -f 0in_sim.arg \
check_mti_0in_cdc:
(vlib work > /dev/null ) ; \
-R -c -wlf verilog.wlf -do "log -r /*; run -all;exit" \
-wlf verilog.wlf -pli $(HOME_0IN)/lib/lib0InLoadMTIPLI.so \
check_nc:
ncverilog \
+loadpli1=$(HOME_0IN)/lib/lib0InLoadVXLPLI:zi_bootstrap \
+access+r +ncstatus \
-f $(SRCLIST) \
-f 0in_sim.arg \
-l run_check_nc.log
check_nc3:
-ncprep +overwrite -f $(SRCLIST)
ncvlog -f ncvlog.args -f 0in_sim.arg
ncelab -f ncelab.args -f 0in_sim.arg.ncelab
ncsim worklib.tb_smp -f 0in_sim.arg.ncsim \
-LOGFILE run_check_nc3.log
check_vcs:
vcsi -R -f $(SRCLIST) \
$(HOME_0IN)/0InPLI/vcs/lib0InvcsPLI.so \
-f 0in_sim.arg \
-l run_check_vcs.log
clean:
0in_clean
rm -rf csrc simv* work transcript Output_Results
rm -rf *.vcd
*~ *.sv *.rc *.log *.rpt *.do

October 2008
Protocol CDC
Batch Mode
cdc_control.v File
Global directives can be used to control CDC analysis as shown in Example 3-6.
Example 3-6. cdc_control.v File
module ctrl;
// 0in set_cdc_clock cpu_clk -period 50

// 0in set_cdc_clock core_clk -period 60
// 0in set_cdc_clock mac_clk -period 50
endmodule
The set_cdc_reconvergence global directive sets the reconvergence depth. In this example,
the depth is set to 10.
The set_cdc_clock global directive specifies clocks with their characteristics and redefine
user must specify one or more clocks.
The set_constant global directive sets scan_mode to a constant 0. This is done to turn scan
off.
Running CDC and Promoting Checkers in Batch Mode

make cdc
The make cdc script runs the following (see “Makefile File” on page 97):
single command.
The cdc command performs the clock domain crossing check for the design.
cdc -d command.

October 2008
Protocol CDC
Batch Mode

filenames.
Following are the automatically generated output files and directory:

• 0in.log – Short log file, which is a copy of the standard output.
• 0in_cdc.db – The CDC database for examining in the 0-In CDC GUI
environment.
• 0in_cdc.rpt – The clock domain crossing report.
• 0in_cdc_ctrl.v – The clock domain crossing checker control file contains
• 0in_cdc_design.rpt – The CDC design report.
• 0in_cdc_param.inc – The checker parameter file.
• 0in_design.rpt – The design summary.
• 0in_detail.log – The detailed log of the transcript.
• 0in_cache/ – The working directory for storing internal data and checker logic.
The screen displays the CDC Summary (see Example 3-7) and the Error/Warning Summary
(see Example 3-8). In addition, the automatically generated Output_Results/0in.log file contains
this information.
Example 3-7. CDC Summary Information in the 0in_cdc.rpt File
CDC Summary
=============================================================
Violations (9)
-------------------------------------------------------------
Unknowns (9)
-------------------------------------------------------------
Evaluations (2)
-------------------------------------------------------------

October 2008
Protocol CDC
Batch Mode
Waived (0)
-------------------------------------------------------------
<None>
Proven (4)
-------------------------------------------------------------
Filtered (0)
-------------------------------------------------------------
<None>

-----------------------------------------------------------
be undetected.
1 Warning hdl-190 Inferred clock group exist, please
check CDC design report.
clock domains.
View the automatically generated Output_Results/0in_cdc_ctrl.v file.

This file contains the automatically generated checker directives for promotion to
simulation and/or formal verification. Example 3-9 is the cdc_dsel checker directive
generated for a DMUX synchronization. (see CDC Compiler User Guider for
information).
Example 3-9. cdc_dsel Checker Directive in the 0in_cdc_ctrl.v File
/* 0in cdc_dsel
-tx_data fstp[7:1]
-rx_data crc_1.scramble
-tx_clock cpu_clk
-rx_clock mac_clk
-tx_data_select init_done
-rx_data_select init_done_r2
-tx_min ‘P_cpu_clk_mac_clk_tx_min
-name dmux_30303
-module demo_top
-inferred
*/

October 2008
Protocol CDC
Batch Mode
This checker ensures that a signal between two clocks (cpu_clk and mac_clk), where
the transmitter’s data select signal (init_done) drives the select input of a data
multiplexor (init_done_r2) in the receiver, is held stable enough for the transmit signal
(fstp[7:1]) to be sampled reliably by the receiver (crc_1.scramble) and ensures that
the data remains stable while the data select signal asserts.
Notice that some of the checker directive have a x0in token mark (for example,
x0in cdc_sync). The x token must be removed by the user for the checker directive to
be promoted.
The x0in token marks the directives as plain comments that are skipped by the 0-In
compilers (to save time in a default flow). To mark individual directives as 0-In
comments for processing by the 0-In compilers, delete the x characters. Use this to
selectively promote checkers.
2. Generate the internal simulator arguments file for the design using the ccl command
and your simulator (see the “Makefile File” on page 97). Following is the command to
use the ModelSim simulator:
make ccl_mti
The ccl command synthesizes the checkers for the design.

The -sim -mti command specifies that ModelSim is the simulator to be used for
Following are the automatically generated output files and directory located in the
Output_Results directory:
• 0in.log – A short log file that is a copy of the standard output.
• 0in_check.db – The 0-In database file showing the checkers created and
• 0in_checker.rpt – This report contains the results of checker synthesis.
• 0in_detail.log – A detailed log of the transcript.
• 0in_sim.arg – Simulation argument file used to invoke simulation with
assertions.
• 0in_sim.arg.vsim – This file specifies the top-level modules containing the
checker logic.
• 0in_sim.arg.vsimrun – Contains information for ModelSim.

October 2008
Protocol CDC
Batch Mode
• 0in_sim_modules.lst – Contains the simulation module list.

• 0in_cache/ – Working directory for storing internal data and checker logic.
----------------------------------------------------------------
0-In Check V2.6 BETA (rh3_x86_64) 07/31/08
Checker Report
----------------------------------------------------------------
Checker File Date : Wed Aug 6 16:20:37 2008
----------------------------------------------------------------
----------------------------------------------------------------
Checker Summary
----------------------------------------------------------------
----------------------------------------------------------------
assert 1 1 1
assert_timer 1 1 1
cdc_dsel 2 2 6
cdc_glitch 1 1 1
cdc_sample 4 4 8
cdc_sync 2 2 2
----------------------------------------------------------------
All 17 17 27
----------------------------------------------------------------
----------------------------------------------------------------
Checker List
----------------------------------------------------------------
cdc_glitch demo_top.combo_logic_85239
cdc_sample demo_top.multi_bits_76265

October 2008
Protocol CDC
Batch Mode
----------------------------------------------------------------
Checker Details
----------------------------------------------------------------
----------------------------------------------------------------
Message : <None>
Location : File /Protocol_CDC/SRC/demo_top.v,Line 187
Directive : assert -var $0in_delay(!empty && !empty_1) -active
pass_valid -clock mac_clk
Module : demo_top
-zivar : $0in_delay((( ! empty) && ( ! empty_1)),1’b1,mac_clk)
-sop : 1'b0
-pos : 1'b0
-eval : 1'b0
-clock : mac_clk
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : zivar
Checker Class : Usr
Checker Internal
--------------------------------------------------------------------
cycle times.
Message : <None>
Module : demo_top
-zivar : cs
-max : 4'b1000
-active : 1'b1
-clock : cpu_clk
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : cs
Checker Class : Ifc
--------------------------------------------------------------------
...
...
---------------------------------------------------------------------

October 2008
Protocol CDC
Batch Mode
Incorrect Checker Directives Details (0 directives)

---------------------------------------------------------------------

make check_mti
vlib work

the qverilog -R option.
The -R <vsim_options> specifies valid vsim options to be applied to simulation.
The -R option must come after all vlog and vopt options of the qverilog
command string.
default file name is vsim.wlf.
The qverilog command has no output directory option. Therefore, the following
automatically generated output files and directory are located in your working directory:
• 0in_checksim.db – Database showing checkers created for examining in the 0-In
CDC GUI environment.
• qverilog.log – Log file that contains the output from vlog, vopt, and vsim.

October 2008
Protocol CDC
Batch Mode
• run_check_mti.log – The detailed log of the transcript.

• verilog.wlf – Log file that contains the simulation data for all HDL objects whose
names match the provided specifications.
• 0in_cache/ — The working directory for storing internal data and checker logic.
• work/ – The work library in the current directory.
There is a self-testing testbench that runs on the design. As you can see, “TEST PASSED!” is
displayed on the screen. This information is also available in the run_check_mti.log file (at the
very end) as shown in Example 3-11.
Example 3-11. Snippet of the run_check_mti.log File
Failed compares = 0
TEST PASSED!

Database File : Protocol_CDC/0in_checksim.db
Simulation Date : Wed Aug 6 16:28:29 2008
Checker File Date : Wed Aug 6 16:20:37 2008

------------------------------------------------------------------------
------------------------------------------------------------------------
cdc_glitch 1 0 0
cdc_dsel 2 2 0
cdc_sample 4 4 0
cdc_sync 2 0 0
assert 1 0 0
assert_timer 1 0 0
------------------------------------------------------------------------
------------------------------------------------------------------------

------------------------------------------------------------------------

October 2008
Protocol CDC
Batch Mode

------------------------------------------------------------------------
17 7 ( 41%) 17 (100%) 0 ( 0%)
------------------------------------------------------------------------

make view
0in_cdc \
$(DB)
This invokes the 0-In CDC GUI with the 0in_cdc.db file loaded as shown in
Figure 3-21.

October 2008
Protocol CDC
Batch Mode
Figure 3-21. 0in_cdc CDC GUI
5. Load the 0in_checksim.db file as follows:

File -> Merge Database...
This invokes the Merge Database window as shown in Figure 3-22.

October 2008
Protocol CDC
Batch Mode
Figure 3-22. Merge Database in Batch Mode
select -> 0in_checksim.db -> Open
With the 0in_checksim.db file loaded, the Results window CDC Checks tab shows the
results of the CDC verification as shown in Figure 3-23.
Figure 3-23. CDC Checks Tab in the Results Window
6. From this point on, running in Batch Mode and Project Mode are identical. Go to Step 7
on page 81 and continue following the Project Mode to complete this tutorial.

October 2008
Protocol CDC
Batch Mode

October 2008
Chapter 4
CDC-FX
CDC-FX Tutorial
Metastability injected simulation is an extension to normal RTL simulation that injects random
metastability into the circuit’s behavior. CDC-FX metastability injected simulation is similar to
simulation with assertions. But, it uses special CDC-FX checkers to inject metastability into the
circuit during simulation. These checkers also monitor the metastability logic and report
coverage of metastability effects during simulation.
This tutorial shows how to run standard simulation with metastability injected into the circuit.
In this tutorial, the following is demonstrated:
• Run cdc and observe the violations found.

• Run ccl with a simulator.
• Inject metastability checkers using the ccl_control.v file.
• Invoke the Waveform GUI to observe metastability violations.
$HOME_0IN/share/examples/Verilog/CDC/CDC_FX
Data Preparation
directory. The tutorial directory includes the following:
Makefile
ccl_control.v
cdc_control.v
filelist
SRC/
demo_top.v
dff2_sync.v
dpmem2clk.v
tb.v

October 2008
CDC-FX
CDC-FX Analysis Flow

Figure 4-1. CDC-FX Analysis Flow Diagram
Run Simulation
N Debug in GUI and

Test Passed? Remove Reconvergence Errors
Review Coverage
N Modify or Write New FX Checkers

Covered? to Cover the Required Coverage
CDC Analysis Complete
1. Run the design with the cdc_fx checkers to test the circuit’s behavior once
metastability is injected:
The simulation “run” has the following steps:
a. Run cdc_fx — Start with running cdc_fx, which generates the cdc_fx checkers.
This determines the CDC signals that have the possibility of going metastable. The
user can apply the checkers generated to potential CDC paths that are/can be
intolerant to metastability. The cdc_fx checker control file (0in_cdc_fx_sim_ctrl.v)
is automatically generated, and it contains the list of checkers and the required
information about these checkers (for example, what checks are on, transmit and
receive registers, etc.). If there is a path that the user is sure metastability has been
taken care of, then the user can turn off the checker that is turned on by default. The

October 2008
CDC-FX
user can turn the default check on or off depending on whether or not the respective
CDC path is tolerant to metastability.
b. Run ccl_mti — Run ccl_mti to compile the cdc_fx checkers and generate the
simulator arguments to create the checker database (0in_check.db file). The output
of this step is the 0in_checker.rpt file, which has detailed checker information and
specifies the checks that are turned on.
c. Run check_mti — The above two steps generate arguments that are passed to the
check_mti run. This step completes the design simulation with the cdc_fx
metastability injecting checkers, and the screen displays “Test Passed” or “Test
Failed.” If the test fails, then it proves the fact that the design might have been
implementing the correct protocol (as the test passed during the CDC Protocol
Analysis (see “Protocol CDC Tutorial” on page 67) but when metastability is
injected, then the test fails.
The 0in_checksim.db file is the output of the above steps that is used to view the firings
with the waveform using the 0-In CDC GUI.
The Checkerware outputs can also be viewed using the 0-In CDC GUI. These
Checkerware signals are used to inject metastability in the design; therefore, viewing the
waveform shows the instance at which metastability is injected and caused the firing.
The user should edit the source code to remove the reconvergence errors, which makes
the design tolerant to metastability.
2. Observe how completely each metastability injector covers the range of metastability
efforts during simulation. Make sure that the cdc_fx checker has respective checks
turned on and what percentage of the total case has coverage. View the coverage
information for all checkers; if there is no firing but the coverage percentage is low, then
the user needs to write a better checker that covers more cases to obtain the desired
coverage percentage.
Makefile File
this example.
#######################################################################
#
# DUT Sources
#
#######################################################################
DUT=demo_top
SRCLIST=filelist
CTRLFILE2=Output_Results/0in_cdc_fx_sim_ctrl.v
CTRLFILE_2=0in_cdc_fx_sim_ctrl.v
CTRLFILE3=ccl_control.v

October 2008
CDC-FX
DB = 0in_checksim.db
VLOG = vlib work; vlog
#VLOG = qverilog
#########################################################################
#
# Make Targets
#
#########################################################################
#
all: cdc_fx\
ccl_mti \
check_mti \
view
cdc_fx:
0in -od Output_Results -cmd cdc -fx -d $(DUT) \
-f $(SRCLIST) -ctrl $(CTRLFILE) -print_all_cdc_paths
debug:
0in_rtld -db $(DB)
view:
0in_cdc \
$(DB)
view_ccl:
0in_view \
0in_check.db
view_checksim:
0in_cdc \
0in_checksim.db
ccl_nc:
0in -cmd ccl -ctrl $(CTRLFILE_2) -ctrl $(CTRLFILE3) \
-sim nc -f $(SRCLIST) -d $(DUT)
ccl_nc3:
-sim nc3 -f $(SRCLIST) -d $(DUT)
ccl_vcs:
-sim vcs -f $(SRCLIST) -d $(DUT)
ccl_mti:
0in -od Output_Results -cmd ccl -ctrl $(CTRLFILE2) \
-ctrl $(CTRLFILE3) -sim mti -f $(SRCLIST) -d $(DUT)
check_mti:
( vlib work > /dev/null ) ; \

October 2008
CDC-FX
check_mti_0in_cdc:
qverilog -f $(SRCLIST) -f 0in_sim.arg \
check_nc:
ncverilog \
+loadpli1=$(HOME_0IN)/lib/lib0InLoadVXLPLI:zi_bootstrap \
+access+r +ncstatus \
-f $(SRCLIST) \
-f 0in_sim.arg \
-l run_check_nc.log
check_nc3:
-ncprep +overwrite -f $(SRCLIST)
ncvlog -f ncvlog.args -f 0in_sim.arg
ncelab -f ncelab.args -f 0in_sim.arg.ncelab
ncsim worklib.tb_smp -f 0in_sim.arg.ncsim \
-LOGFILE run_check_nc3.log
check_vcs:
vcsi -R -f $(SRCLIST) \
$(HOME_0IN)/0InPLI/vcs/lib0InvcsPLI.so \
-f 0in_sim.arg \
-l run_check_vcs.log
clean:
0in_clean
rm -rf csrc simv* work transcript Output_Results
rm -rf *.vcd
*~ *.sv *.rc *.log *.rpt *.vsimrun *.do
cdc_control.v Control File

Global directives can be used to control CDC analysis as shown in Example 4-2.
Example 4-2. cdc_control.v Control File
module ctrl;
// 0in set_cdc_clock cpu_clk_in -period 50

// 0in set_cdc_clock core_clk_in -period 60
// 0in set_cdc_clock mac_clk_in -period 50
// 0in set_cdc_preference -promote_reconvergence
endmodule

October 2008
CDC-FX
The set_cdc_reconvergence global directive sets the reconvergence depth. In this example,
the depth is set to 10. The -depth option is used for sequential reconvergence analysis depth.
The default is 0.
The set_cdc_clock global directive specifies clocks with their characteristics and redefines
user must specify one or more clocks. Verilog clocks can be bits of multiple-bit variables.
VHDL clocks must be scalars (bit, std_logic, std_ulogic); they cannot be vector records. The
-period option specifies the clock period in time units. This value is used to calculate directive
parameters for promoted checkers.
The set_constant global directive sets ports to constant values and checks testbench
simulation. For this tutorial example, it sets scan_mode to a constant 0. This is done to turn
scan off.
The set_cdc_preference global directive defines the preferences for CDC. The
-promote_reconvergence option promotes the cdc_hamming1 checker for reconvergence
schemes. The default is that no protocol checkers are promoted for reconvergence scheme.
ccl_control.v Control File

The metastability window indicates the transmit and receive clock edge relations that determine
when metastability can occur. The set_cdc_fx_metastability_window global directive is
used by the ccl command (see Example 4-3). Refer to the CDC Compiler User Guide for
detailed information on metastability.
Example 4-3. ccl_control.v Control File
module ccl_control;
// 0in set_cdc_fx_timescale 1ps/1ps

// 0in set_cdc_fx_metastability_window -start 5000 -stop 1000 \
-rx_clock core_clk -tx_clock mac_clk
// 0in set_cdc_fx_metastability_window -start 6000 -stop 1000 \
-rx_clock mac_clk -tx_clock core_clk
endmodule
The set_cdc_fx_metastability_window global directive specifies a metastability window

for one or more receive register clocks. The user can specify the metastability window as a
percentage of the RX clock rather than an absolute value. The -start and -stop values
specify the metastability using directional time units as follows:
• The -start value specifies the metastability using directional time units. The -start
value is the number of time units before the active receive clock edge that the associated
metastability window opens.

October 2008
CDC-FX
• The -stop value specifies the metastability using directional time units. The -stop
value is the number of time units after the active receive clock edge that the associated
metastability window closes.
Run CDC and Simulation with Metastability

The metastability injectors (cdc_fx checkers and metastability detection logic) are instantiated
from cdc_fx checker directives. The user can specify these directives manually, but CDC
paths can be numerous and this process is prone to user error.
Instead, use the built-in feature of the cdc command to automate the process of preparing the
design data for the CCL compiler. Since the cdc command analyzes CDC paths, it can readily
construct the cdc_fx checker directives for them. Therefore, if the user includes the -fx
option to the cdc command, then it automatically generates a CDC-FX control file
(0in_cdc_fx_sim_ctrl.v) that contains cdc_fx checker directives, which can be used with the
CCL compiler.

make cdc_fx
The make cdc_fx script runs the following (see “Makefile File” on page 113):
0in -od Output_Results -cmd cdc -fx -d $(DUT) \
-f $(SRCLIST) -ctrl $(CTRLFILE) -print_all_cdc_paths
single command.
The cdc command has the -fx option to automatically synthesize checkers and the
0in_cdc_fx_sim_ctrl.v control file with directives for the promoted cdc_fx checkers.
cdc -d command.

filenames.
The -print_all_cdc_paths option is used to print all CDC path information. Use this
option to extract register information or to create PrimeTime scripts. Using the
-print_all_cdc_paths option automatically generates the 0in_cdc_paths.rpt file.

October 2008
CDC-FX
• 0in.log — Short log file, which is a copy of the standard output.
• 0in_cdc.db — The CDC database for examining in the 0-In GUI environment.
• 0in_cdc.rpt — The clock domain crossing report.
• 0in_cdc_ctrl.v — The clock domain crossing checker control file contains
• 0in_cdc_design.rpt — The CDC design report.
• 0in_cdc_fx_formal_ctrl.v — The CDC-FX formal control file.
• 0in_cdc_fx_sim_ctrl.v — The CDC-FX simulation file.
• 0in_cdc_param.inc — The checker parameter file.
• 0in_cdc_path.rpt — The detailed report of the CDC path information.
• 0in_design.rpt — The design summary.
• 0in_detail.log — The detailed log of the transcript.
The screen displays the CDC Summary (see Example 4-4) and Error/Warning Summary (see
Example 4-5). The automatically generated Output_Results/0in.log file also contains this
information.
The cdc command evaluates the RTL netlist and finds violations. These violations are
a mixture of errors that must be fixed and rule violations that do not apply to any current
design style. Also, cdc finds unknowns (potential rule violations).
Example 4-4. CDC Summary Information in the 0in.log File
CDC Summary
===========================================================
Violations (9)
-----------------------------------------------------------
Unknowns (9)
-----------------------------------------------------------

October 2008
CDC-FX
Evaluations (2)
-----------------------------------------------------------
Waived (0)
-----------------------------------------------------------
<None>
Proven (4)
-----------------------------------------------------------
Filtered (0)
------------------------------------------------------------
<None>

-----------------------------------------------------------
be undetected.
clock domains.
The automatically generated 0in_cdc_design.rpt file contains Clock Group Summary

information (see Example 4-6), General Design Information (see Example 4-7), and Port
Domain Information (see Example 4-8).
The Clock Group Summary displays the total counts for each type of clock group. There are two
types of clock groups: user-specified and inferred. All user-specified clocks are defined by the
user with the set_cdc_clock global directive (see “ccl_control.v Control File” on page 116).
Inferred clock groups are clocks that are not specified, but inferred by the CDC tool.
Example 4-6. Clock Group Summary Information in 0in_cdc_design.rpt File
Clock Group Summary for 'demo_top'

==================================

October 2008
CDC-FX

===========================

-----------
cpu_clk_in
cpu_clk

-----------
core_clk_in
core_clk
fifo_1_d.wr_clk
fifo_1_d.u0.Wclk
fifo_0_h.wr_clk
fifo_0_h.u0.Wclk

-----------
mac_clk_in
mac_clk
fifo_1_d.rd_clk
fifo_1_d.u0.Rclk
fifo_0_h.rd_clk
fifo_0_h.u0.Rclk
crc_1.clk

=====================
None

====================
None
The General Design Information displays the total counts for each basic design element (see
Example 4-7).
Example 4-7. General Design Information in the 0in_cdc_design.rpt File

==========================
Number of RAMs = 2

October 2008
CDC-FX
=========================
RAMs:
-----
fifo_1_d.u0.data
fifo_0_h.u0.data
The Port Domain Information displays the clock domains identified for the design’s ports (see
Example 4-8). The following defines the port domain information:
o Port — Port name.
o Direction — The valid directions are: input, output, and inout
o Constraint — Identifies clock and reset ports.
o Clock Domain — Clock domain of the port. The {clock} indicates the primary clock
for the domain, and {clock1 | clock2 |...} indicates the clock domain is ambiguous.
The relevant primary clocks are listed. An async indicates the port is marked as an
asynchronous port using the set_cdc_port_domain global directive.
o Type — Method used to determine the clock domain. User indicates the clock
domain is assigned by the set_cdc_clock global directive or the port is marked
asynchronous (using set_cdc_port_domain global directive). Inferred indicates
CDC analysis identified the domain (or potential domains).
Example 4-8. Port Domain Information in the 0in_cdc_design.rpt File

=========================
----------------------------------------------------------------------
core_clk_in
scan_clk input ---

October 2008
CDC-FX

The automatically generated Output_Results/0in_cdc_fx_sim_ctrl.v control file contains the

cdc_fx checker directives as shown in Example 4-9. Note that the first two in this example
have the cdc_fx checker turned on (designated in bold) and the third displayed in this example
does not have the cdc_fx checker turned on.
If the user is sure that the path is tolerant to metastability, then the user can remove the cdc_fx
check on the path. Also, the user can add the cdc_fx check to a path. In other words, the user
can add or remove the cdc_fx check as desired.
Example 4-9. 0in_cdc_fx_sim_ctrl.v File Snippet
//Summary
//-------
//Count : Module
//------------------------------------------------------------
// 17 : demo_top
module zin_cdc_fx_sim_ctrl;
//cpu_clk_in --> mac_clk_in

//ID:dmux_30303 --> fstp[7:1]
//------------------------------------------------------------
/* 0in cdc_fx
-tx_reg fstp[7:1]
-rx_reg crc_1.scramble
-rx_areset ( ( ! rst) )
-cdc_fx
-name zin_cdc_fx_sim_crc_1_scramble_0
-module demo_top
-inferred
*/
//core_clk_in --> mac_clk_in

//ID:dmux_12402 --> tx_mask_d
//------------------------------------------------------------
/* 0in cdc_fx
-tx_reg tx_mask_d
-rx_reg mask
-cdc_fx
-name zin_cdc_fx_sim_mask_1
-module demo_top
-inferred
*/

October 2008
CDC-FX
. . .
. . .
//core_clk_in --> mac_clk_in

//ID:pulse_sync_13276 --> tx_en
//------------------------------------------------------------
/* 0in cdc_fx
-tx_reg tx_en
-rx_reg tx_en_r1
-name zin_cdc_fx_sim_tx_en_r1_6
-module demo_top
-inferred
*/
. . .
endmodule
2. Generate the internal simulator argument file for the design using the ccl command
and your simulator. Following is the command to use the ModelSim simulator:
make ccl_mti
0in -od Output_Results -cmd ccl -ctrl $(CTRLFILE2) \
-ctrl $(CTRLFILE3) -sim mti -f $(SRCLIST) -d $(DUT)
The ccl command synthesizes checkers for design.

The -sim -mti command specifies that ModelSim is the simulator to be used for
• 0in.log — Short log file, which is a copy of the standard output.
• 0in_check.db — The 0-In database file showing the checkers created and
• 0in_checker.rpt — This report contains the results of checker synthesis.
• 0in_sim.arg — Simulation argument file used to invoke simulation with
assertions.
• 0in_sim.arg.vsim — This file specifies the top-level modules containing the
checker logic.

October 2008
CDC-FX
• 0in_sim.arg.vsimrun — Contains information for ModelSim.

• 0in_sim_modules.lst — Contains the simulation module list.
Observe the total number of checkers generated and the type of checkers generated. For
example, in this design there is a total of 21 checkers with each checker applying a different
number of checks for a total of 12 checks as shown in the Checker Summary section. As you
scroll down, the Checker List section shows what all the checkers are generating. The Checker
Details section displays the functionality of each checker. Notice in the 0in_checker.rpt file that
some have the cdc_fx directive turned on (one is shown in bold in the example below).
--------------------------------------------------------------------
0-In Check V2.6 BETA (rh3_x86_64) 07/31/08
Checker Report
--------------------------------------------------------------------
Report Generated : Thu Aug 7 09:23:35 2008
Checker File Date : Thu Aug 7 09:23:35 2008
--------------------------------------------------------------------
--------------------------------------------------------------------
Checker Summary
--------------------------------------------------------------------
--------------------------------------------------------------------
assert 1 1 1
assert_timer 1 1 1
cdc_fx 17 17 6
--------------------------------------------------------------------
All 21 21 12
--------------------------------------------------------------------
--------------------------------------------------------------------
Checker List
--------------------------------------------------------------------
cdc_fx demo_top.zin_cdc_fx_sim_check_en_r1_16
cdc_fx demo_top.zin_cdc_fx_sim_crc_1_crc_16_5
cdc_fx demo_top.zin_cdc_fx_sim_crc_1_scramble_0

October 2008
CDC-FX
cdc_fx demo_top.zin_cdc_fx_sim_fifo_0_h_rp_s1_7
cdc_fx demo_top.zin_cdc_fx_sim_fifo_0_h_wp_s1_8
cdc_fx demo_top.zin_cdc_fx_sim_fifo_1_d_rp_s1_9
cdc_fx demo_top.zin_cdc_fx_sim_fifo_1_d_wp_s1_10
cdc_fx demo_top.zin_cdc_fx_sim_init_done_r1_11
cdc_fx demo_top.zin_cdc_fx_sim_mask_1
cdc_fx demo_top.zin_cdc_fx_sim_pass_en0_r1_12
cdc_fx demo_top.zin_cdc_fx_sim_tx_en_2
cdc_fx demo_top.zin_cdc_fx_sim_tx_en_r1_6
cdc_fx demo_top.zin_cdc_fx_sim_tx_eop_r1_13
cdc_fx demo_top.zin_cdc_fx_sim_tx_mask_valid_3
cdc_fx demo_top.zin_cdc_fx_sim_tx_mask_valid_r1_14
cdc_fx demo_top.zin_cdc_fx_sim_tx_sop_r1_15
cdc_fx demo_top.zin_cdc_fx_sim_tx_state_0__4
--------------------------------------------------------------------
Checker Details
--------------------------------------------------------------------
--------------------------------------------------------------------
Message : <None>
Location : File /CDC_FX/SRC/demo_top.v, Line 187
Directive : assert -var $0in_delay(!empty && !empty_1) \
-active pass_valid -clock mac_clk
Module : demo_top
-sop : 1'b0
-pos : 1'b0
-eval : 1'b0
-clock : mac_clk
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : zivar
Checker Class : Usr
Checker Internal
--------------------------------------------------------------------
cycle times.
Message : <None>
Module : demo_top
-zivar : cs
-max : 4'b1000

October 2008
CDC-FX
-active : 1'b1
-clock : cpu_clk
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : cs
Checker Class : Ifc
--------------------------------------------------------------------
. . .
. . .
. . .
--------------------------------------------------------------------
Type/Name : cdc_fx demo_top.zin_cdc_fx_sim_mask_1
Description : Injects metastability at the output of a
receive register.
Message : <None>
Location : File/Output_Results/0in_cdc_fx_sim_ctrl.v, Line 36
Directive : cdc_fx
-tx_reg tx_mask_d
-rx_reg mask
-cdc_fx
-name zin_cdc_fx_sim_mask_1
-module demo_top
-inferred
Module : demo_top
Check glitch_caught : Off <Default Off>
Check glitch_swallowed : Off <Default Off>
Check cdc_fx : On <Default Off>
-tx_clock : core_clk_in
-rx_clock : mac_clk_in
-rx_reset : 1'b0
-rx_areset : ( ! rst)
-active : 1'b1
-rx_reg : mask
-tx_reg : tx_mask_d
-rx_load_enable : (mask_pass && tx_mask_valid_r2)
-rx_q : mask
-name : zin_cdc_fx_sim_mask_1
Checker Class : FX
Checker Internal
--------------------------------------------------------------------
. . .
. . .
. . .
--------------------------------------------------------------------
Incorrect Checker Directive Details (0 directives)
--------------------------------------------------------------------

October 2008
CDC-FX

make check_mti

the qverilog -R option. The -R option specifies the valid vsim options to be applied
to the simulation. Note that -R <vsim_options> must be the last argument in the
command string.
default file name is vsim.wlf. For this tutorial example, the file name is verilog.wlf.
Following are the automatically generated output files and directory (notice these files are in
your working directory and not the Output_Results directory as the qverilog command has no
output directory option):
• 0in_checksim.db — Database showing checkers created for examining in the
GUI environment.
• qverilog.log — Log file that contains the output from vlog, vopt, and vsim.
• run_check_mti.log — The detailed log of the transcript.

October 2008
CDC-FX
• verilog.wlf — Log file that contains the simulation data for all HDL objects
whose names match the provided specifications.
• work/ — The work library in the current directory.
This test failed, but this same test passed in the Protocol CDC Tutorial (see page 67). The
reason this test now fails is because there are now injected metastability CDC-FX checkers.
There is a self-testing testbench that runs on the design. As you can see, “TEST FAILED” is
displayed on the screen. This information is also available in the run_check_mti.log file (at the
very end) as shown in Example 4-11.
Example 4-11. run_check_mti.log File Snippet
Failed compares = 857

TEST FAILED

Report Generated : Thu Aug 7 09:35:30 2008
Database File : /CDC_FX/0in_checksim.db
Simulation Date : Thu Aug 7 09:35:27 2008
Checker File Date : Thu Aug 7 09:23:35 2008

----------------------------------------------------------------------
----------------------------------------------------------------------
cdc_fx 17 2 6
assert 1 1 0
assert_timer 1 0 0
----------------------------------------------------------------------
----------------------------------------------------------------------

----------------------------------------------------------------------
----------------------------------------------------------------------
21 10 ( 47%) 15 ( 71%) 0 ( 0%)
----------------------------------------------------------------------

October 2008
CDC-FX
You can debug this failure by traditional debug methods; run waveform comparisons on
simulation with metastability, and simulation without metastability. Or, if you have
assertions in your design, then they can bring you closer to the source of the problem.
Another debug aid is the inject metastability signal.

make view
0in_cdc \
$(DB)
This command opens the 0in_cdc GUI with the cdc_fx checkers and assert checker
firing displayed in the Results window as shown in Figure 4-2.

October 2008
CDC-FX
Observe in Figure 4-2 that the assert check fired on the demo_top.zivar path. The
Firing Report and Checker Report can be viewed in the Details window as shown in
Figure 4-4.
To invoke the Details window, select -> View -> Details or in the Results window,
right-click -> Show -> Details as shown in Figure 4-3.
Figure 4-3. View Menu or Results Window

October 2008
CDC-FX
Figure 4-4. Details Window
In addition to the Design window, the Firing Report information is located in the
run_check_mti.log file (see Example 4-12) and the Checker Report information is
located in the 0in_checker.rpt file (see Example 4-13 on page 134).

October 2008
CDC-FX
Example 4-12. Firing Report in the run_check_mti.log File
0-In Firing: assert demo_top.zivar (Firing: 1)

Time: 618000ps
Message: Ensures that a specified signal asserts.
Signature: The specified signal was not asserted.
Module: demo_top, File:
/Tutorials_CDC_Verilog/examples/CDC_FX/SRC/demo_top.v,
Line: 187
Directive: assert -var $0in_delay(!empty && !empty_1) \
Check: ’assert’
0-In End Firing
ERROR: Failed compare: Expected = 01011100 , Received = 10111101
Following are the steps to invoke a signal in the Waveform GUI:

right-click on Check assert
select -> Show -> Simulation Firings...
Figure 4-5. Show Simulation Firings
This invokes the Firings window as shown in Figure 4-6.

select -> assert: Signature 1: (All Firings)
select -> OK

October 2008
CDC-FX
Figure 4-6. Firings Window
It is required to have the verilog.wlf file loaded. If it is not loaded, then the Load
Waveform Database window automatically invokes as shown in Figure 4-7.
Figure 4-7. Load Waveform Database WIndow
left-click -> verilog.wlf -> Open
This invokes the GUI with the waveform loaded as shown in Figure 4-8 with All
Firings selected.
Once the verilog.wlf file is loaded, it is not required to load it with each additional run.
Use the Zoom In, Zoom Out, and Zoom Full icons to control the waveform size
(circled in red in Figure 4-8)

October 2008
CDC-FX
Figure 4-8. Waveform Window
The waveforms displayed are from the “Directive” line as shown in Example 4-13 (in
bold). The violation occurs because the !empty && !empty_1 does not assert at the
correct time.
Example 4-13. Snippet of the 0in_checker.rpt File
-----------------------------------------------------------------------
Checker Details
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Message : <None>
Directive : assert -var $0in_delay(!empty && !empty_1) \
Module : demo_top
-sop : 1'b0
-eval : 1'b0
-clock : mac_clk

October 2008
CDC-FX
-reset : 1'b0
-areset : 1'b0
-support : 1'b0
-nv : 1'b1
-name : zivar
Checker Class : Usr
Checker Internal
-----------------------------------------------------------------------
5. This tutorial is now done. Close the 0in_cdc GUI as follows:

File -> Quit -> Yes

October 2008
CDC-FX

October 2008
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/terms_conditions/enduser.cfm
IMPORTANT INFORMATION
USE OF THIS SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS

LICENSE AGREEMENT BEFORE USING THE SOFTWARE. USE OF SOFTWARE INDICATES YOUR
COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH
IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND
CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software between you, the end user, as an authorized
representative of the company acquiring the license, and Mentor Graphics Corporation and Mentor Graphics
(Ireland) Limited acting directly or through their subsidiaries (collectively “Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by you and an
authorized representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties'
entire understanding relating to the subject matter and supersede all prior or contemporaneous agreements. If you
do not agree to these terms and conditions, promptly return or, if received electronically, certify destruction of
Software and all accompanying items within five days after receipt of Software and receive a full refund of any
license fee paid.
1. GRANT OF LICENSE. The software programs, including any updates, modifications, revisions, copies, documentation
and design data (“Software”), are copyrighted, trade secret and confidential information of Mentor Graphics or its
licensors who maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement.
Mentor Graphics grants to you, subject to payment of appropriate license fees, a nontransferable, nonexclusive license to
use Software solely: (a) in machine-readable, object-code form; (b) for your internal business purposes; (c) for the license
term; and (d) on the computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half
mile (800 meter) radius. Mentor Graphics’ standard policies and programs, which vary depending on Software, license
fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be
limited, for example, to execution of a single session by a single user on the authorized hardware or for a restricted period
of time (such limitations may be technically implemented through the use of authorization codes or similar devices); and
(c) support services provided, including eligibility to receive telephone support, updates, modifications, and revisions.
2. EMBEDDED SOFTWARE. If you purchased a license to use embedded software development (“ESD”) Software, if
applicable, Mentor Graphics grants to you a nontransferable, nonexclusive license to reproduce and distribute executable
files created using ESD compilers, including the ESD run-time libraries distributed with ESD C and C++ compiler
Software that are linked into a composite program as an integral part of your compiled computer program, provided that
you distribute these files only in conjunction with your compiled computer program. Mentor Graphics does NOT grant
you any right to duplicate, incorporate or embed copies of Mentor Graphics' real-time operating systems or other
embedded software products into your products or applications without first signing or otherwise agreeing to a separate
agreement with Mentor Graphics for such purpose.
3. BETA CODE. Software may contain code for experimental testing and evaluation (“Beta Code”), which may not be used
without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants to you a
temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Code without charge
for a limited period of time specified by Mentor Graphics. This grant and your use of the Beta Code shall not be construed
as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not to release
commercially in any form. If Mentor Graphics authorizes you to use the Beta Code, you agree to evaluate and test the
Beta Code under normal conditions as directed by Mentor Graphics. You will contact Mentor Graphics periodically
during your use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of your
evaluation and testing, you will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,
weaknesses and recommended improvements. You agree that any written evaluations and all inventions, product
improvements, modifications or developments that Mentor Graphics conceived or made during or subsequent to this
Agreement, including those based partly or wholly on your feedback, will be the exclusive property of Mentor Graphics.
Mentor Graphics will have exclusive rights, title and interest in all such property. The provisions of this section 3 shall
survive the termination or expiration of this Agreement.
4. RESTRICTIONS ON USE. You may copy Software only as reasonably necessary to support the authorized use. Each
copy must include all notices and legends embedded in Software and affixed to its medium and container as received from
Mentor Graphics. All copies shall remain the property of Mentor Graphics or its licensors. You shall maintain a record of
the number and primary location of all copies of Software, including copies merged with other software, and shall make
those records available to Mentor Graphics upon request. You shall not make Software available in any form to any
person other than employees and on-site contractors, excluding Mentor Graphics' competitors, whose job performance
requires access and who are under obligations of confidentiality. You shall take appropriate action to protect the
confidentiality of Software and ensure that any person permitted access to Software does not disclose it or use it except as
permitted by this Agreement. Except as otherwise permitted for purposes of interoperability as specified by applicable
and mandatory local law, you shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive from
Software any source code. You may not sublicense, assign or otherwise transfer Software, this Agreement or the rights
under it, whether by operation of law or otherwise (“attempted transfer”), without Mentor Graphics’ prior written consent
and payment of Mentor Graphics’ then-current applicable transfer charges. Any attempted transfer without Mentor
Graphics' prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics' option, result in
the immediate termination of the Agreement and licenses granted under this Agreement. The terms of this Agreement,
including without limitation, the licensing and assignment provisions shall be binding upon your successors in interest
and assigns. The provisions of this section 4 shall survive the termination or expiration of this Agreement.
5. LIMITED WARRANTY.
5.1. Mentor Graphics warrants that during the warranty period Software, when properly installed, will substantially
conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant
that Software will meet your requirements or that operation of Software will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. You
must notify Mentor Graphics in writing of any nonconformity within the warranty period. This warranty shall not be
valid if Software has been subject to misuse, unauthorized modification or improper installation. MENTOR
GRAPHICS' ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS'
OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF SOFTWARE TO MENTOR
GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF SOFTWARE THAT DOES NOT MEET THIS
LIMITED WARRANTY, PROVIDED YOU HAVE OTHERWISE COMPLIED WITH THIS AGREEMENT.
MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B) SOFTWARE
WHICH IS LICENSED TO YOU FOR A LIMITED TERM OR LICENSED AT NO COST; OR
(C) EXPERIMENTAL BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”
5.2. THE WARRANTIES SET FORTH IN THIS SECTION 5 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS
NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, WITH
RESPECT TO SOFTWARE OR OTHER MATERIAL PROVIDED UNDER THIS AGREEMENT. MENTOR
GRAPHICS AND ITS LICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF
INTELLECTUAL PROPERTY.
6. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY

WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS
OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
(INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS' OR ITS LICENSORS'
LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT PAID BY YOU FOR THE SOFTWARE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR
GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE
PROVISIONS OF THIS SECTION 6 SHALL SURVIVE THE EXPIRATION OR TERMINATION OF THIS
AGREEMENT.
7. LIFE ENDANGERING ACTIVITIES. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BE
LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF SOFTWARE IN
ANY APPLICATION WHERE THE FAILURE OR INACCURACY OF THE SOFTWARE MIGHT RESULT IN
DEATH OR PERSONAL INJURY. THE PROVISIONS OF THIS SECTION 7 SHALL SURVIVE THE
EXPIRATION OR TERMINATION OF THIS AGREEMENT.
8. INDEMNIFICATION. YOU AGREE TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS
LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE, OR LIABILITY, INCLUDING
ATTORNEYS' FEES, ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF SOFTWARE AS
DESCRIBED IN SECTION 7. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE EXPIRATION OR
TERMINATION OF THIS AGREEMENT.
9. INFRINGEMENT.
9.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against you alleging that
Software infringes a patent or copyright or misappropriates a trade secret in the United States, Canada, Japan, or
member state of the European Patent Office. Mentor Graphics will pay any costs and damages finally awarded
against you that are attributable to the infringement action. You understand and agree that as conditions to Mentor
Graphics' obligations under this section you must: (a) notify Mentor Graphics promptly in writing of the action;
(b) provide Mentor Graphics all reasonable information and assistance to defend or settle the action; and (c) grant
Mentor Graphics sole authority and control of the defense or settlement of the action.
9.2. If an infringement claim is made, Mentor Graphics may, at its option and expense: (a) replace or modify Software so
that it becomes noninfringing; (b) procure for you the right to continue using Software; or (c) require the return of
Software and refund to you any license fee paid, less a reasonable allowance for use.
9.3. Mentor Graphics has no liability to you if infringement is based upon: (a) the combination of Software with any
product not furnished by Mentor Graphics; (b) the modification of Software other than by Mentor Graphics; (c) the
use of other than a current unaltered release of Software; (d) the use of Software as part of an infringing process; (e) a
product that you make, use or sell; (f) any Beta Code contained in Software; (g) any Software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or (h) infringement by
you that is deemed willful. In the case of (h) you shall reimburse Mentor Graphics for its attorney fees and other costs
related to the action upon a final judgment.
9.4. THIS SECTION IS SUBJECT TO SECTION 6 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS AND YOUR SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO
ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION
BY ANY SOFTWARE LICENSED UNDER THIS AGREEMENT.
10. TERM. This Agreement remains effective until expiration or termination. This Agreement will immediately terminate
upon notice if you exceed the scope of license granted or otherwise fail to comply with the provisions of Sections 1, 2, or
4. For any other material breach under this Agreement, Mentor Graphics may terminate this Agreement upon 30 days
written notice if you are in material breach and fail to cure such breach within the 30 day notice period. If Software was
provided for limited term use, this Agreement will automatically expire at the end of the authorized term. Upon any
termination or expiration, you agree to cease all use of Software and return it to Mentor Graphics or certify deletion and
destruction of Software, including all copies, to Mentor Graphics’ reasonable satisfaction.
11. EXPORT. Software is subject to regulation by local laws and United States government agencies, which prohibit export
or diversion of certain products, information about the products, and direct products of the products to certain countries
and certain persons. You agree that you will not export any Software or direct product of Software in any manner without
first obtaining all necessary approval from appropriate local and United States government agencies.
12. RESTRICTED RIGHTS NOTICE. Software was developed entirely at private expense and is commercial computer
software provided with RESTRICTED RIGHTS. Use, duplication or disclosure by the U.S. Government or a U.S.
Government subcontractor is subject to the restrictions set forth in the license agreement under which Software was
obtained pursuant to DFARS 227.7202-3(a) or as set forth in subparagraphs (c)(1) and (2) of the Commercial Computer
Software - Restricted Rights clause at FAR 52.227-19, as applicable. Contractor/manufacturer is Mentor Graphics
Corporation, 8005 SW Boeckman Road, Wilsonville, Oregon 97070-7777 USA.
13. THIRD PARTY BENEFICIARY. For any Software under this Agreement licensed by Mentor Graphics from Microsoft
or other licensors, Microsoft or the applicable licensor is a third party beneficiary of this Agreement with the right to
enforce the obligations set forth herein.
14. AUDIT RIGHTS. You will monitor access to, location and use of Software. With reasonable prior notice and during
your normal business hours, Mentor Graphics shall have the right to review your software monitoring system and
reasonably relevant records to confirm your compliance with the terms of this Agreement, an addendum to this
Agreement or U.S. or other local export laws. Such review may include FLEXlm or FLEXnet report log files that you
shall capture and provide at Mentor Graphics’ request. Mentor Graphics shall treat as confidential information all of your
information gained as a result of any request or review and shall only use or disclose such information as required by law
or to enforce its rights under this Agreement or addendum to this Agreement. The provisions of this section 14 shall
survive the expiration or termination of this Agreement.
15. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. THIS AGREEMENT SHALL BE
GOVERNED BY AND CONSTRUED UNDER THE LAWS OF THE STATE OF OREGON, USA, IF YOU ARE
LOCATED IN NORTH OR SOUTH AMERICA, AND THE LAWS OF IRELAND IF YOU ARE LOCATED
OUTSIDE OF NORTH OR SOUTH AMERICA. All disputes arising out of or in relation to this Agreement shall be
submitted to the exclusive jurisdiction of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the
laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia (except for Japan) arising out of or in relation to
this Agreement shall be resolved by arbitration in Singapore before a single arbitrator to be appointed by the Chairman of
the Singapore International Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with the
Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by reference
in this section 15. This section shall not restrict Mentor Graphics’ right to bring an action against you in the jurisdiction
where your place of business is located. The United Nations Convention on Contracts for the International Sale of Goods
does not apply to this Agreement.
16. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,
unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in
full force and effect.
17. PAYMENT TERMS AND MISCELLANEOUS. You will pay amounts invoiced, in the currency specified on the
applicable invoice, within 30 days from the date of such invoice. Any past due invoices will be subject to the imposition
of interest charges in the amount of one and one-half percent per month or the applicable legal rate currently in effect,
whichever is lower. Some Software may contain code distributed under a third party license agreement that may provide
additional rights to you. Please see the applicable Software documentation for details. This Agreement may only be
modified in writing by authorized representatives of the parties. Waiver of terms or excuse of breach must be in writing
and shall not constitute subsequent consent, waiver or excuse.
Rev. 060210, Part No. 227900

Assertion-Based Verification CDC Verilog Tutorial User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Assertion-Based Verification CDC Verilog Tutorial User Guide

Uploaded by

Copyright:

Available Formats

Assertion-Based Verification

CDC Verilog Tutorial User Guide

Software Version V2.6a

© 1995-2008 Mentor Graphics Corporation

RESTRICTED RIGHTS LEGEND 03/97

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 3

4 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Example 2-1. Error/Warning Summary in the 0in.log File . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Figure 1-1. 0-In Help Button for Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Figure 2-40. 0in_cdc GUI Created with a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 7

Table 1-1. Help Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 8

Verilog Tutorial Overviews

The example to run this tutorial is located in the following directory:

The example to run this tutorial is located in the following directory:

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 9

The example to run this tutorial is located in the following directory:

0-In Shell Help

% 0in [script_file | -cmd command_string]

The help commands are displayed in Table 1-1.

Table 1-1. Help Commands

10 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Table 1-1. Help Commands (cont.)

0in> cwhelp <directive_name>

0in> cwhelp checklist_off

displays the following:

Excludes a specified checklist check from the design file.

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 11

0in Command help

The following is displayed:

The following is displayed:

12 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

0-In View Help

The following is displayed:

The following is displayed:

To view the command argument syntax, do the following:

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 13

0-In View> help <command_argument>

displays the following:

0-In Documentation Help

14 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Figure 1-1. 0-In Help Button for Documentation

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 15

Mentor Graphics Support

16 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Static CDC Tutorial

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 17

Static CDC Functional Flow

Set Basic Environment Conditions

Generate Clock Report

Modify the CDC Constraints N

Perform CDC Checks

18 Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a

Set the Basic Environment Conditions

• Write the configuration in a Verilog/VHDL control file (see “cdc_control.v File” on

Generate the Clock Report

Check Clock Groups

• All the clocks are as intended.

Modify the Clock Constraints

Assertion-Based Verification Verilog CDC Tutorial User Guide, V2.6a 19