CDC User

0-In CDC User Guide
Software Version 10.0 February 2011
1995-2011 Mentor Graphics Corporation All rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this document may duplicate this document in whole or in part for internal business purposes only, provided that this entire notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make changes in specifications and other information contained in this publication without prior notice, and the reader should, in all cases, consult Mentor Graphics to determine whether any changes have been made. The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in written agreements between Mentor Graphics and its customers. No representation or other affirmation of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor Graphics whatsoever. MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT, EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. RESTRICTED RIGHTS LEGEND 03/97 U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely at private expense and are commercial computer software provided with restricted rights. Use, duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.72023(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clause at FAR 52.227-19, as applicable. Contractor/manufacturer is: Mentor Graphics Corporation 8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777. Telephone: 503.685.7000 Toll-Free Telephone: 800.592.2210 Website: www.mentor.com SupportNet: supportnet.mentor.com/ Send Feedback on Documentation: supportnet.mentor.com/user/feedback_form.cfm
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of Mentor Graphics Corporation or other third parties. No one is permitted to use these Marks without the prior written consent of Mentor Graphics or the respective third-party owner. The use herein of a thirdparty Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics trademarks may be viewed at: www.mentor.com/terms_conditions/trademarks.cfm.
Table of Contents
Chapter 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0-In Advanced Functional Verification Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 CDC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metastability in Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metastability in Standard RTL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC-FX Injected RTL Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Signal Synchronizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Bus Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ad Hoc Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconvergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributes of CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Severity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signal/Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schemes with Potential CDC Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formal CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Protocol Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-Step Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-Step Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 17 18 22 23 24 25 25 26 26 27 29 30 31 32 34 35 38 39 39 39 40 41 41 42 43 44 45 46 47 49 50 53 55 56 57
0-In CDC User Guide, v10.0 February 2011
Table of Contents
Step 1: Compile and Maintain Design Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 2: Run CDC Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc: Clock Domain Crossing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDC Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing an SDC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting SDC Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Style Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Binding to Verilog Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0-In Directives Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4 CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in_cdc: GUI Debug Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in_cdc: GUI Project Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 1. Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 2: Analyzing Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 3: Compiling CDC Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 4: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic CDC Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Protocol Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0-In Formal Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation with CDC Protocol Assertions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC-FX Metastability Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Simulation with CDC-FX Metastability Injection. . . . . . . . . . . . . . . . . . . . . . . Simulation Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling with ccl for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical CDC Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variations on the Hierarchical CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heterogeneous Instances of Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control File Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modal CDC Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specify Modes (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Report Mode Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mode Verification and Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual Mode Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Incomplete CDC Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
57 57 59 60 64 64 66 66 67 69 72 75 84 85 87 88 88 91 92 93 93 96 96 104 104 105 107 111 112 113 115 118 119 124 127 129 129 131 133 134 135 135 136 138 138 144 146
Table of Contents
CDC Analysis of FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 1: Compiling the FPGA Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Xilinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Altera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical-physical Library Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 2: Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 3: Compiling a CDC Model of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 4: Running GUI Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 5 CDC-FX Metastability Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Metastability Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metastability Windows Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running CDC-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fx_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC-FX PLI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verilog Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VHDL Glue Logic Option Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metastability Injector Simulation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assertion Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6 Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . async_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . async_reset_no_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . blackbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_four_latch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_shift_reg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bus_two_dff_phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . combo_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . custom_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . custom_sync_with_crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dff_sync_gated_clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . fanin_different_clks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . fifo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . four_latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . memory_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multi_bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multi_sync_mux_select. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . port_constraint_mismatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149 149 149 151 151 152 152 157 159 160 161 165 165 169 170 171 171 173 174 174 177 179 181 184 186 189 191 193 195 197 199 201 203 205 207 208 210 213 218 220 223 225 227 229 231
5
Table of Contents
pulse_sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . redundant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . series_redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . shift_reg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . simple_dmux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . single_source_reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . two_dff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . two_dff_phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0-In Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0-In Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wildcards in Directive Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directive Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directives for CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_black_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fifo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fifo_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fx_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fx_metastability_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_fx_timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_handshake_preference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_hier_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_port_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_port_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_reconvergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_cdc_synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_constant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_constant_propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_mode_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directives for Checker Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . checker_firing_keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . create_wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . default_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . disable_checker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . disable_used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exclude_checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . include_checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_checker_action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
233 235 238 240 242 244 246 251 253 254 254 255 257 257 259 260 262 263 266 267 268 269 270 271 272 273 276 283 289 291 293 299 302 305 306 308 310 311 312 313 314 315 316 318 319 320 321 322 323
Table of Contents
use_synthesis_case_directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . verror. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vdel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in_cdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in_db2ucdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0in Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cwhelp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol/FX Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_dsel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_glitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_hamming_distance_one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_handshake_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_fx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cdc_custom_fx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 7 GUI Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Window Layouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analysis Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errors/Warnings Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Checks Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log/Report Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schematics Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expanding Logic in the Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zooming the Schematic View In or Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving Waveforms and Waveform Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Waveforms and Waveform Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zooming the Wave View In or Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capturing Zoomed/Scrolled Views as Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
324 325 326 327 330 334 340 342 345 347 349 353 358 359 373 375 375 377 381 385 387 390 398 401 404 408 411 411 411 415 418 418 419 422 422 423 424 426 426 428 429 430 430 430 431 432
Table of Contents
Selecting Multiple Signals for Format Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Display Properties of Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Signal Pathname Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Multiple Window Panes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Cursors to Analyze Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capturing a Waveforms Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Source Code Variable to a Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annotating Source Code with Variables Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Mode Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modules Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clocks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directives Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 8 Reports/Logs Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Design Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Group Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User-Specified Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inferred Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ignored Clock Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detailed Design Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Domain Crossing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Promotion Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Waived . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custom Synchronization Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Reset Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Reset Synchronizers Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User-entered Asynchronous Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Reset with Missing Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All Transmitting Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC Settings Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Section A: Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Section B: Unmatched Global Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Section C: Wildcard Expansion for Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . .
433 433 433 434 435 435 436 437 438 438 438 440 440 441 442 443 444 445 446 446 447 447 449 449 449 450 451 452 452 453 453 454 455 456 456 457 458 458 458 459 459 461 462 462 462 463
Table of Contents
Section D: Global CDC Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Section E: Default CDC Scheme Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Index End-User License Agreement
List of Examples
Example 2-1. Promoted CDC Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3-1. 0in_sdc_ctrl.v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3-2. SDC Export File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 4-1. Hierarchical Constraints Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 4-2. 0in_hier.scr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 4-3. 0in_hier.Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 5-1. 0in_cdc_fx_sim_ctrl.v File Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 5-2. Editing the 0in_cdc_fx_sim_ctrl.v File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 6-1. Single-source Reconvergence Code Snippet. . . . . . . . . . . . . . . . . . . . . . . . . . Example 6-2. Single-source Reconvergence 0in_cdc.rpt File . . . . . . . . . . . . . . . . . . . . . . . . Example 8-1. Clock Group Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-2. User-Specified Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-3. Inferred Clock Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-4. Ignored Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-5. General Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-6. Detailed Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-7. Port Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-8. Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-9. CDC Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-10. CDC Promotion Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-11. Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-12. Cautions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-13. Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-14. Waived. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-15. Proven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-16. Filtered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-17. Custom Synchronization Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-18. Asynchronous Reset Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-19. Asynchronous Reset Synchronizers Detected. . . . . . . . . . . . . . . . . . . . . . . . Example 8-20. User-entered Asynchronous Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-21. Asynchronous Reset with Missing Synchronizer . . . . . . . . . . . . . . . . . . . . . Example 8-22. All Transmitting Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-23. Global Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-24. Unmatched Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-25. Wildcard Expansion for Global Directives . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-26. Global CDC Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 8-27. Default CDC Scheme Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 67 68 120 125 126 166 167 281 281 446 447 447 449 449 449 450 451 452 453 453 454 455 456 457 457 458 458 458 459 459 461 462 463 463 463 465
10
List of Figures
Figure 2-1. Clock Domains and Clock Dividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-2. Asynchronous Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-3. Metastable Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-4. Four Metastability Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output . . . . . . . . . . . . . . . Figure 2-6. Metastability Injector for a CDC Data Bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-7. Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-8. Synchronization Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-9. CDC Checks Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-10. Show Simulation Firings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-11. Simulation Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-12. Checker Simulation Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-13. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3-1. CDC Compilation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3-2. Design Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3-3. Preparing the work Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3-4. modelsim.ini Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3-5. Compiling Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-1. 0-In CDC Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-2. Static 0-In CDC Tool Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-3. CDC GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-4. Simulation with CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-5. Hierarchical CDC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-6. Basic Hierarchical CDC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-7. -report_constraints Generates Hierarchical CDC Scripts. . . . . . . . . . . . . . . . . . Figure 4-8. Waiving a Block-level Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-9. Top-level CDC Analysis with CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-10. Modes are Inferred Based on the Clock Multiplexing . . . . . . . . . . . . . . . . . . . Figure 4-11. 0in_cdc Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-12. Moving the Mode Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-13. Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-14. Filter Hierarchy Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-15. Mode for the Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-16. Clock Coloring Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-17. Color Change as the Mode Context Changes . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-18. Modes Have No Clock Tree Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-19. Reload Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4-20. Some Modes Have Clock Tree Information . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-1. Setup and Hold Times for a Register Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-2. Metastability Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 25 26 27 28 29 30 30 50 51 52 52 53 55 57 57 59 59 87 88 89 107 118 120 124 128 131 134 139 140 140 141 142 143 143 147 147 148 160 161
11
List of Figures
Figure 5-3. clks_aligned Input to the cdc_fx Checker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-4. Metastability Window Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-5. CDC Data Flow for Simulation with Metastability . . . . . . . . . . . . . . . . . . . . . . Figure 5-6. Metastability-injected Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5-7. CDC GUI with Merged CDC_FX Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6-1. Single-source Reconvergence Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6-2. Global CDC Preferences (0in_detail.log) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6-3. CDC Analysis with cdc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6-4. Compiling CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6-5. Transmit Protocol Checks for Glitches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-1. Dragging and Dropping a Port to the Schematic Window . . . . . . . . . . . . . . . . . Figure 7-2. Configuring Columns in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-3. Organizing the Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-4. Zoomed View of a Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-5. Undocking a Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-6. Saving and Restoring a GUI Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-7. Errors/Warnings Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-8. Error/Warning Hover Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-9. CDC Checks Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-10. Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-11. Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-12. Log/Report Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-13. Log Browser Showing Error/Warning Information . . . . . . . . . . . . . . . . . . . . . Figure 7-14. Schematics Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-15. Source Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-16. Waveform Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-17. Find Panel in Design Data Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-18. Project Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-19. Design Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-20. Modules Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-21. Clocks Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7-22. Directives Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
162 164 165 169 175 281 287 366 366 406 413 413 415 416 416 417 418 419 420 422 423 424 425 426 429 430 440 440 441 442 443 444
12
List of Figures
13
List of Tables
Table 1-1. Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 1-2. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2-1. Signal Synchronization Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2-2. Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2-3. Signal and Data Synchronization Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2-4. Potential CDC Problem Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 2-5. CDC Checks Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-1. 1-Step Compilation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-2. vcom Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-3. vlog Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-4. cdc Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-5. Imported SDC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-6. Exported SDC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-7. Inferred Clocks and Port Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-8. Unsupported Verilog Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-9. Verilog Design Style Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-10. Supported VHDL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 3-11. VHDL Design Style Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-1. CDC GUI Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-2. 0in_cdc Project Mode Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-3. CDC Protocol Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-4. Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-5. ccl Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-6. ILMs vs. CFMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4-7. Control File Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 5-1. CDC Schemes and cdc_fx Checker Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-1. CDC Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-2. Global Directives for CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-3. Global Directives for Checker Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-4. cdc Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-5. cdc Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6-6. Standard Options of a Checker Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 41 42 43 44 53 56 59 60 65 66 67 67 72 72 75 80 89 91 104 113 115 132 132 167 179 260 313 368 368 376
14
Chapter 1 Introduction
Welcome to the 0-In Advanced Functional Verification suite, a collection of functional analysis tools from Mentor Graphics. The 0-In Advanced Functional Verification suite, along with your standard HDL simulation environment (for example, the Questa Sim product), provides a complete, integrated functional verification environment for assertion-based verification of your complex HDL designs. The 0-In Functional Verification suite has the following verification tools: 0-In AutoCheck analyzer, for analyzing violations of various standard design rules and common coding practices. 0-In Formal verification tools, for static formal analysis of SVA, PSL, OVL and QVL assertions. 0-In CDC analyzer, for clock domain crossing analysis, CDC transfer protocol checking and CDC-FX metastability effects injection.
These tools and the Questa simulator use a common set of front-end utilities to compile and maintain design and resource libraries. So, 0-In verification is compatible with your simulation environment, if you use the Questa simulator. The 0-In tools analyze synthesizable logic, so some variance with simulation is common, but this is not unlike the restrictions for logic synthesis and design emulation. Each tool comes with a GUI debugger environment for organizing, waiving and debugging verification results. These GUI environments are tightly integrated with their analysis tools. All have a common look-and-feel, as they are based on a common set of GUI widgets (which are also used for the Questa Sim GUI environment). In addition to tabs and windows for organizing source data and running the analysis tools, the GUIs have useful analyzer windows such as language-oriented source code editors, schematic browsers, waveform viewers and finite-statemachine viewers. Since their use models are so similar, once you are familiar with the operation of one GUI environment, you can easily learn how to run the others.
15
Introduction 0-In Advanced Functional Verification Manuals
0-In Advanced Functional Verification Manuals

The manual set for the 0-In Advanced Functional Verification suite has the following documents: Release Documents 0-In Release Notes Bugs fixed in the current release and support information. 0-In Release Highlights New features; user-visible changes; support information and installation notes.
Quick-Start Guides 0-In AutoCheck Quick Start Guide Tool flows and methodology for 0-In Formal AutoCheck; syntaxes for commands and directives; and autochecks quick reference. 0-In Formal Quick Start Guide Tool flows and methodology for 0-In Formal; and syntaxes for commands and directives. 0-In CDC Quick Start Guide Tool flows and methodology for 0-In CDC; syntaxes for commands and directives; and CDC schemes quick reference.
Quick References 0-In Quick Reference Syntaxes of commands and directives for all 0-In tools. 0-In Assertions Quick Reference Quick reference for OVL and QVL checker libraries; and SVA coding style examples. 0-In Messages Quick reference for messages issued by the 0-In tools.
User Guides 0-In AutoCheck User Guide Basics and tool flow for AutoCheck operation; command and directives reference; autochecks reference; and GUI reference. 0-In Formal User Guide Basics and tool flow for formal analysis and assertion debug; command and directives reference; and GUI reference. 0-In CDC User Guide Basics and tool flow for static CDC analysis, dynamic CDC analysis and simulation with CDC-FX metastability injection; command and directives reference; CDC schemes reference; and GUI reference. Syntaxes of commands and directives for all 0-In tools.
Tutorials 0-In Formal Verilog Tutorial User Guide Formal analysis tutorial using a Verilog design. 0-In Formal VHDL Tutorial User Guide Formal analysis tutorial using a VHDL design.
16
Introduction Notational Conventions
0-In CDC Verilog Tutorial User Guide Static and dynamic CDC analysis tutorial using a Verilog design. 0-In CDC VHDL Tutorial User Guide Static and dynamic CDC analysis tutorial using a VHDL design.
Notational Conventions
This manual uses the notational conventions illustrated in Table 1-1. Table 1-1. Notational Conventions Notation italics Description In syntax statements: oblique font indicates a variable. In text: oblique font indicates: (1) variable (2) code excerpt (3) term being defined Example [-depth cycles] Specify the black box as module. Both tx_sig1 and tx_sig2 converge at rx_sig. A port constraint is a restriction on the clock domains of signals...
<italics in angle brackets> Italics in angle brackets are used in text Specify the reconvergence depth: -depth <cycles>. to distinguish variables from literals when necessary to reduce confusion. <angle brackets> Angle brackets are used in alphanumeric messages from the software to indicate variables. cdc [-d <design>] [+define+<define>]...
italics underline
Oblique underline font in text indicates See the Questa Sim User the name of another document. Guide for details of the vlog command.
17
Introduction Online Help
This manual uses the conventions illustrated in Table 1-2 for syntax statements. Table 1-2. Syntax Conventions Meta-symbol ... [ ] { } | _pattern Description Ellipses indicate a repeatable entry. Square brackets indicate an optional entry. Example -ports portID. . . [-module module]
Braces indicate a required entry {-set signal value}... (typically used with |-bars or ellipses). Or-bars separate choices in [ ] and { } [-87|-93|-2002|-2008] entries. An argument variable with a _pattern suffix accepts wildcards. set_constant var_pattern constant
The following replaceable variables in directive syntax statements represent the shown object types. signal variable constant string Single-bit register or wire. Expression that can change value at any time. Expression that evaluates to a statically constant value. String enclosed in double-quotes.
When specifying a directive from a directive syntax statement, substitute for each meta-variable an HDL identifier, or an expression enclosed in parentheses, that evaluates to an object of the corresponding type.
Online Help
0-In software includes several ways of getting online help: Shell help Type -help with any shell command for the syntax of that command. For example:
prompt> vlib -help Usage: vlib -help vlib [-short|-dos|-long|-unix] [-archive [-compact <compact>]] [-unnamed_designs <count>] [{-lock|-unlock} <design>] [-locklib|-unlocklib] <library_name>
18
0in shell help Type -help with any 0in shell command for the syntax of that command. For example:
prompt> 0in -cmd csl -help . . . usage: compile_search_logic alias: csl -d <design name> [-prefix <prefix for search dut in test bench>] [-ctrl_module <control module name>]... Verilog Options: [-v95 | -sv | -v2k] [-ctrl <verilog checker control file>]... [-ctrl_list <list of verilog checker control files>...] [+define+<macro[=val]>]... [+incdir+<incdir>]... [+libext+<libext>]... [-cuname <compilation unit name>...] VHDL Options: [-vhctrl <vhdl checker control file>]... [-93 | -87 | -2002 | -2008] Assertion Options: [+assert] [-psl] [+propfile+<compile verilog flavor PSL vunit>]... [-pslfile_vl <compile verilog flavor PSL vunit>]... [-pslfile_vh or -pslfile <compile VHDL PSL vunit>]... [-assertion_compiler_stats or -ac_stats] [-ovl] [-ovl_cov] [-qvl] [-sva_strong] 3rd Party Tool Options: [-sim <select simulator (questa,mti,vcs,nc,nc3)>] Advanced Usage Options: [-G[ ]<<name=value> override top level generic>]... [-g[ ]<<name=value> default top level generic>]... [-use_synthesis_case_directives] [-sif <simulator arg file for running checkers>] [-tcs or -target_cover_statements] [-dut_instance or -di <instance name>...] [-dut_exclude or -de <instance name>...] RTL Options: [-work <logical work library name>] [-L <search library for saved modules>]... [-Lf <library, searched before uselib>]... [-modelsimini <modelsim.ini to provide library mapping>] Reporting Options: [-rcd_file <checker density report file>] [-cr <checker report file>] [-cache <working directory>] [-rel_paths] [-full] [-rcd] [-rcd_level <report level>] [-eode or -exit_on_directive_errors] [+nowarn+<message-id>]...
19
Introduction Online Help [+error+<message-id>]... [-sir or -static_input_report] [-scr or -static_coverage_report] [-help] Prepares design files for formal verification.
CW help The cwhelp 0in shell command displays the syntaxes of the global directives. For example:
prompt> 0in -cmd cwhelp set_black_box usage: set_black_box <name pattern>... [-dont_use_outputs] Set module as a black-box for formal processing
Specify cwhelp with no arguments to list the available directives:

prompt> 0in -cmd cwhelp 0-In Checker Directive Compiler globals Global Directives autocheck_off Turn off autocheck autocheck_on Turn on autocheck autocheck_preference Set autocheck preference autocheck_report Set autocheck message and/or waive autocheck create_wire Create a checkerware wire default_reset Specifies a default reset disable_assumption Do not use specified checks as formal assumptions . . .
Hover help When using the GUIs, placing the cursor over certain items displays pop-up text boxes called hover help. This pop-up information helps you understand the GUI. For example, hovering over an icon displays a description of the function performed by the icon (such as zoom in and trace fanin to register or primary port). Other types of hover help include hovering over a status flag to see the meaning of that status and hovering over a warning message to see the full details of the message.
20
InfoHub The 0-In Functional Verification documentation is available in HTML and PDF forms from the 0-In Functional Verification InfoHub. Use a web browser to open the InfoHub top page:
install_dir/share/doc/info/hubs/index.html
21
Introduction Mentor Graphics Support
Mentor Graphics Support

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

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

CDC verification initially ensures that all appropriate CDC signals have correct synchronization logic. But, CDC verification really addresses the larger question: Does my CDC synchronization logic prevent data corruption across clock domains? Even for a design that has correct synchronizers on all signals, you must consider questions such as: What happens if the CDC signals are changing when the handshake signal indicates they are stable? Does the gray-code logic on a multiple bit bus using 2FF synchronization have a bug? Does the input to a data synchronizer change in two successive clock cycles of the receiving domain? What happens when multiple CDC signals are recombined and used together in the receiving domain?
Problems such as these often do not cause simulations to fail; instead, they commonly manifest as intermittent post-silicon failures. To protect against these types of failures (and ensure CDC problems are addressed early in the design process), you can use the CDC verification methodology that consists of a three-pronged approach as follows: Static CDC analysis with the CDC compiler. Assertion-based verification with CDC protocol checkers. Metastability effects analysis with CDC-FX metastability injected simulation.
24
CDC Basics Clock Domains
Clock Domains
A clock domain is a section of a design that has a clock asynchronous to (or which has a variable phase relationship to) another clock in the design. For example, suppose one clock is derived from another clock through a clock divider. These two clocks have a constant phase relationship; therefore, the two sections of the design that use these clocks are really part of the same clock domain (Figure 2-1A). However, suppose two clocks have frequencies of 50 MHz and 33 MHz. These clocks phase relationships change over time; therefore, they clock two different clock domains (Figure 2-1B). Figure 2-1. Clock Domains and Clock Dividers
A
clock divider clk/2 clk
B
clk
clk clk33 PLL clk50
clk33
clk
clk50
Single Clock Domain
Multiple Clock Domains
If the primary inputs to a circuit include multiple clocks, then these asynchronous clocks determine separate clock domains (Figure 2-2A). If the inputs to a circuit are asynchronous to the circuit itself, then these asynchronous inputs are in separate clock domains (Figure 2-2B). Clocks are the clock signals of registers and the enable signals of latches (when properly identified). Figure 2-2. Asynchronous Clock Domains
A
clk33 clk50 clk50 clk clk clk33
B
a b
Asynchronous Clocks
Asynchronous Inputs
Clock Groups
All the clocks that are part of the same clock domain constitute a clock group. Hence, clock groups partition all of the clocks in the design. The clock groups identify the various clock domains in the design.
25
CDC Basics Metastability
Metastability
A clock domain crossing (CDC) signal is a signal originating in a clock domain that crosses the boundary into another domain (whose clock is asynchronous to the original clock) and is then sampled by a register in that asynchronous clock domain. When the active edge of a CDC signals transmit clock is too close to the active edge of the receive registers clock, metastability occurs if data changes within the setup/hold time. With the TX/RX clock very close, input to the RX register changes within the setup/hold window, which causes metastability. The registers output settles to an unpredictable value. Metastability can occur if the clocks are asynchronous, or if they are synchronous but have unpredictable or drifting skews. Every type of bi-stable storage element is susceptible to metastability. Logic subject to metastability must be designed to tolerate its effects. The effects of metastability are unpredictable in hardware as the output signal can settle randomly to 1 or 0. However, RTL simulation provides predictable results. As a result, RTL simulation does not accurately model the hardware implementation when metastability is present. To ensure a circuit design is immune to metastability effects, functional verification methods must incorporate technology beyond RTL simulation. To design circuits that tolerate the effects of metastability, you must understand: How registers in hardware exhibit metastability and how registers function in simulation when the conditions for metastability are present.
Metastability in Hardware
Registers can go metastable in hardware. Consider the 1-bit CDC signal s that is sampled by the flip-flop DFF in Figure 2-3 on page 26. Since s comes from a different clock domain, its value can change at any time with respect to the DFF clock (clk). If the value of s is not held constant at 0 or 1 during the DFF setup and hold time, then the output (q) might assume an intermediate voltage for an indeterminate amount of time. Then, q settles randomly to either 0 or 1. The flip-flop is said to be metastable for that interval. Figure 2-3. Metastable Flip-Flop
setup and hold time
clk s DFF clk q s q
The following mean-time-between-failure (MTBF) formula predicts how often metastability occurs: f clk = clock frequency 1 MTBF = ---------------------------------f in = asynchronous signal frequency f clk f in t d t d = setup/hold window
26
Metastability in Standard RTL Simulation

Registers cannot go metastable in RTL simulation. RTL simulation handles single-bit registers predictably as follows: If the simulated input switches value before the simulated clock edge, then the simulated output switches value at the clock edge. If the simulated input switches value after the simulated clock edge, then the simulated output does not switch value.
Therefore, for both setup time and hold time violations, two results are possible as follows: The hardware output value matches the value predicted by simulation. The hardware value differs from the value predicted by simulation.
Figure 2-4 shows the resulting four metastability scenarios. Comparing hardware with RTL simulation behavior: When a setup time violation occurs, the hardware transition is delayed randomly by one cycle. When a hold time violation occurs, the hardware transition is advanced randomly by one cycle. Note that metastability models can be generalized for multibit registers by treating them as aggregate single-bit registers. Figure 2-4. Four Metastability Scenarios
cdc_s
R
q setup time violations

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

A common method of modeling metastability in standard RTL simulation is to introduce pseudorandom delays in CDC signals at the synchronizers. For example, Figure 2-5 shows a two-register synchronizer with a MUX that selects a 3-cycle delayed value (instead of the normal 2-cycle delayed value) in a pseudorandom manner. End-to-end functional simulation with these types of pseudorandom delays helps to verify that the design works properly in the presence of CDC metastability. Figure 2-5. Synchronizer with Pseudorandom 1-Cycle Delay on Output
synchronizer s R1 clk q1 R2 q2 R3 q3 $random()
However, this method has the following limitations: It is incomplete, because it only models two of the four possible metastability scenarios. It models metastability only across synchronized CDC signals. Results are difficult to predict, because metastability is introduced into the simulation at random. Synchronization violations are difficult to debug, because the offending metastability can occur any number of cycles before the cycle in which the simulation check first fails (and irrelevant metastability can occur along the way).
Clock Jitter
Another method of modeling CDC metastability effects in standard RTL simulation is to jitter the clocks in simulation and see if end-to-end functional simulation still works when the clock phase relationships change. This method is good for verifying that the design works properly in the presence of clock jitter and clock skews. But, this method does not completely model CDC metastability effects.
28
CDC-FX Injected RTL Simulation

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

tx_reg reg rx_reg
tx_clock
rx_clock
tx_clock
synchronizer
rx_clock
tx_reg
rx_reg cdc_fx checker
tx_reg
cdc_fx checker
rx_reg reg
tx_clock
clocks monitor metastability injector
rx_clock
tx_clock
clocks monitor synchronizer metastability injector
rx_clock
The ccl compiler generates the checker logic for running metastability injected simulation. To do this, it adds metastability injection logic for each affected CDC signal or bus in the following two parts: CDC clocks monitor logic Glue logic used to extract load and timing conditions from the circuit. cdc_fx checker Checkers that monitor conditions that might cause metastability on a CDC bus and injects metastability at the receiver outputs. The cdc_fx checkers maintain statistics and corner-case counts for the metastability and CDC effects modeled by the transformed circuit. The cdc_fx checkers have default-off checks (cdc_fx) that fire in cycles in which metastability might occur (for use on data buses that are presumed to be synchronized properly). See CDC-FX Metastability Injection on page 159 for additional information.
29
CDC Basics Synchronizers
Synchronizers
Designers generally assume signals are in-band, which means they have a value of either logic 0 or logic 1. Metastable signals can have values that are neither 0 or 1; therefore, they are considered out-of-band signals. Out-of-band signals have unexpected effects and propagate unpredictably. To handle CDC signals, designers fence in potentially metastable logic to ensure logic beyond the fence only needs to handle in-band signals. The logic inside the fence is called a synchronizer (see Figure 2-7). Figure 2-7. Synchronizer
out-of-band value in-band value
cdc_d tx_clk
int_d
sync logic rx_clk
Tx Clock Domain
synchronizer
Rx Clock Domain
Metastability manifests as variable delays in transitions of the outputs of registers driven by CDC signals. Relative to normal simulation, transitions are randomly delayed or advanced. This affects every CDC signal. Even if a CDC signal or data bus has a synchronizer, the output of the synchronizer is subject to variable delays. Logic outside the fence in the receiving domain might not interpret receive data correctly in the presence of variable delays. Such intolerance of metastability effects can lead to functional errors in hardware, even when normal simulation cannot detect the problem. Designers implement various types of synchronizers as appropriate for particular situations and design styles. Logic for each synchronizer type assumes a set of preconditions about the logic connecting the synchronizer and about the function of the circuit during simulation. Rules for the synchronizers connections can be checked during compilation before simulation. Transfer protocols can only be checked as the circuit operates in simulation. A synchronizer type, along with its connection rules and transfer protocol, is called a synchronization scheme as shown in Figure 2-8. Figure 2-8. Synchronization Scheme
glitch-free transmit logic* CDC signal stable for multiple cycles** no combo logic in path*
cdc_d tx_clk
int_d
sync logic rx_clk
Tx Clock Domain
synchronizer
Rx Clock Domain
* Connection rules assumptions that can be checked statically. ** CDC transfer protocol assumptions that must be checked with simulation or formal analysis.
30
Most CDC implementations use one or more synchronizers from a set of popular, wellcharacterized synchronization schemes. These structured synchronizers must follow welldefined connection rules and should obey specific transfer protocols. CDC identifies clock domains, CDC signals, and structured synchronizers; and it verifies that the structured synchronizers follow their connection rules. Then, CDC promotes their transfer protocols to CheckerWare CDC protocol checkers for use with assertion-based simulation and formal verification. Any clock domain crossing that does not have a structured synchronizer must be synchronized by custom logic or software. These ad hoc synchronizers prevent receive registers from sampling CDC signal values when they are changing. Therefore, the receive register outputs can never go metastable. For example, an ad hoc synchronizer might use custom logic to control its receive registers load enable signal, or software might control the loading of a circuits configuration registers.
Control Signal Synchronizers

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

2DFF synchronizers are used for CDC control signals, but not data buses. The following synchronizers are used to synchronize multibit CDC data in various logic configurations. 0-In CDC reports all structured synchronizers. For many synchronizer types, it promotes 0-In checkers that verify the CDC transfer protocols in simulation and formal verification.
DMUX Synchronizer
Select control signal from the transmit domain (synchronized by a 2DFF synchronizer) enables a MUX when the transmit data value is available.
dmux synchronizer
cdc_d
Tx Clock Domain
tx_sel
rx_sel 2DFF synchronizer
CDC Transfer Protocol 2DFF synchronizer must obey CDC q transfer protocol for tx_sel. Transmit clock domain logic must hold cdc_d stable while tx_sel or Rx Clock Domain rx_sel are asserting.
rx_clk
Asynchronous FIFO Synchronizer

Multiclock, multiaccess FIFO queues up transmitted data.
fo synchronizer
rx_d
Tx Clock Domain
cdc_d tx_addr wen tx_clk
rx_d_rdy async FIFO
CDC Transfer Protocol FIFO must not overflow or underflow. ren Transitions of tx_addr must have a hamming distance of 1. q Interval from write to read of any FIFO location must not be less than Rx Clock the following: Domain
rx_addr
t setup + t max_propagation_time
rx_clk
32
Multibit Data Synchronizer

2DFF synchronizer synchronizes each bit, but only a single transmit bit at a time should change during any receive clock cycle.
Tx Clock Domain
d[0] multibit synchronizer 2DFF synchronizer
CDC Transfer Protocol Rx Clock Transitions of cdc_d must Domain hamming distance of 1.
have a
cdc_d d[1]
2DFF synchronizer
2DFF synchronizers must obey the CDC transfer protocol for each cdc_d bit.
d[2]
2DFF synchronizer rx_clk
Custom Synchronizer
Special-purpose signal or data synchronizer designed, specified, and implemented by the user.
Tx Clock Domain
cdc_d custom synchronizer user-dened module
Rx Clock Domain
q rx_clk
CDC Transfer Protocol User-defined protocol.
Custom synchronizers can also have clock domain crossings internal to the user-defined module.
Tx Clock Domain
d tx_clk custom synchronizer with internal crossing user-dened module
Rx Clock Domain
q rx_clk
CDC Transfer Protocol User-defined protocol.
33
Ad Hoc Synchronizers
0-In CDC reports CDC signals without structured synchronizers and promotes appropriate CDC protocol checkers to verify ad hoc synchronization in simulation and formal verification.
Tx Clock Domain
cdc_d ad hoc synchronizer
CDC Transfer Protocol Rx When a changing rx_int is sampled by Clock Domain rx_clk, rx_int must be stable in the
q
rx_int
rx_clk
interval from: active_rx_clk_edge t setup to: active_rx_clk_edge + t hold
34
CDC Basics Reconvergence
Reconvergence
Reconvergence is the utilization of separately-propagated correlated information. An example of reconvergence is information crossing clock domain boundaries that is recombined in the receive logic.
reconverging signals tx_sig1 rx_sig1
tx_clk
rx_clk
tx_sig2
rx_sig2
Tx Clock Domain
Rx Clock Domain
The singular problem with reconvergence is: Can you assure that all of the correlated information used at the destination is consistent with the information that was transmitted from the source? CDC signal values might be metastable. Even when proper synchronizers are used, they are subject to variable delays, which might cause reconverging information to be inconsistent. Reconvergence occurs in two ways: Local reconvergence a single item of information propagates and is reconstituted in the receive logic, and global reconvergence multiple items of information propagate and are integrated in the receive logic. An example of local reconvergence is multibit reconvergence of a CDC data bus. Here, a data unit splits into pieces, crosses a clock domain boundary and then recombines in the receive logic. In the following example, a reconverged word value is used as the next state of a finite state machine. The individual bits of the word are synchronized to the receive clock domain, but each bit is subject to variable delays. As a result, the next_state input to the FSM can represent a command that is not consistent with the current state.
Tx Clock Domain
cdc_d d[1] d[0] synchronizer
Rx Clock Domain
next_state
FSM S2
synchronizer
S1
synchronizer d[2] rx_clk
S3 ?
S4
.
35
Another example of local reconvergence is multicycle reconvergence of a CDC signal that contains sequential information transmitted to receive logic. Here, variable delays in the propagated signal can disturb correlations between consecutive transitions. In the following example, the cdc_s pulse is not propagated to the receive logic. To avoid problems with multicycle reconvergence, either the transmit logic must not transition data too quickly or the receive logic must tolerate the loss of information in consecutive cycles.
Tx Clock Domain
cdc_s R1 int_s R2 rx_clk q
Rx Clock Domain
An example of global reconvergence is a set of data items transmitted across a clock domain boundary through different synchronizers that are combined in the receive clock domain. Another example of global reconvergence is the transmission of multiple items of information across a clock domain boundary at different times using the same synchronizer. Global and local reconvergence problems in CDC circuits are avoided by using proper synchronizers and good reconvergence schemes. A good implementation ensures information is always consistent. Either variable delay data cannot be sampled in the receive domain or the receive domain logic can recover from variable delayed values. In the following example of a good scheme, an arbiter selects a receive data value when the corresponding asynchronous FIFO read data value is guaranteed to be ready.
Tx Clock Domain
tx_0 async FIFO synchronizer rx_1 tx_1 async FIFO synchronizer rdy_0 arbiter rdy_1 sel rx_rdy rx_clk
Rx Clock Domain
rx_0 rx_out
A bad implementation results in unrecoverable errors in simulation or in the hardware implementation. In the following example of a bad scheme, variable delays can cause the wrong command to be applied to the data.
Tx Clock Domain
tx_cmd async FIFO synchronizer async FIFO synchronizer
Rx Clock Domain
rx_cmd apply command to data
tx_data
rx_data
rx_clk
36
Knowing which paths are reconvergent CDC paths is important for assessing reconvergence issues. But for many multiple-clock architectures, the number of reconvergent CDC paths can be staggering. To help rank paths for assessment, reconvergent paths can be filtered by several characteristics.
divergence depth synchronizer reconvergence depth
synchronizer
synchronizer
Tx Clock Domain
RX Clock Domain
single-source reconvergence paths
The reconvergence depth of a group of reconvergent CDC paths is the sequential depth from the synchronizers to the reconvergence point. Sometimes, heuristic information about the functional characteristics of the circuit can specify a reconvergence depth limit for problems to occur. General reconvergent CDC paths can start anywhere in the transmit domain. Reconvergent paths that start at different points can have reconvergence problems. However, single-source reconvergence pathsthose reconvergent paths that start from the same transmit domain sourceare characteristically vulnerable to reconvergence issues. Analogous to general reconvergent CDC paths, each group of single-source reconvergence paths has a sequential distance (called the divergence depth) from the single source to the synchronizers.
37
Verifying Reconvergence
Simulation alone is not sufficient to verify that a circuits hardware implementation tolerates metastability effects and will operate correctly without reconvergence issues. Normal simulation does not model metastability robustly and completely misses behavior that can manifest in the circuits hardware implementation. A multi-faceted approach to CDC verification is necessary for a high degree of confidence that a particular reconvergence scheme is a good one. Static reconvergence analysis. 0-In CDC creates static reconvergence reports showing general and single-source reconvergence points organized by signature. These reports can uncover reconvergence scenarios that might be overlooked. CDC transfer protocol checking. 0-In CDC identifies structured synchronizers and promotes their CDC transfer protocols to CDC assertion checkers for use in simulation and formal verification. Metastability injected verification. CDC-FX identifies registers that can become metastable. For each such register, 0-In CDC generates a cdc_fx checker directive for metastability injected simulation. This checker includes metastability injection and analysis logic. During simulation, the cdc_fx checker assumes control of the registers output. It injects variable delays on bits that transition when transmit and receive clocks are almost aligned. This causes some outputs to mimic metastable behavior in simulation. Problems are detected by end-to-end test failures. If the verification environment is instrumented with assertions, problems also can be detected by assertion failures.
38
CDC Basics CDC Schemes
CDC Schemes
The CDC compiler analyzes the design netlist and identifies logic involving CDC signals that matches various pattern templates. Each occurrence of logic that matches a template is called a CDC scheme. For example, you might have a 1-bit CDC signal sig from clock domain A being synchronized by two in-phase D flip-flops in clock domain B. The CDC compiler identifies this particular clock domain crossing and its synchronization logic. Classes of CDC schemes with the same functionality are called CDC scheme types (to distinguish them from individual CDC schemes). For example, the above CDC path with its synchronization logic is a CDC scheme of the two_dff type. CDC Schemes starting on page 179 have the detailed data sheets for the CDC schemes.
Attributes of CDC Schemes

Each CDC scheme detected by the CDC compiler has two attributes: severity and promotion (see page 39). By default, the severity and promotion attributes are taken from the default attributes of the CDC scheme type. You can adjust these attributes for individual CDC schemes, groups of schemes, and for the entire set of CDC schemes of a particular scheme type, using the set_cdc_report global directive (page 293). Part of the initial CDC compiler run is typically spent adjusting the attributes of CDC schemes to fine-tune the CDC reporting for the target design characteristics. For example, a combo_logic scheme in one part of the design might be acceptable, but it might be a serious concern in another part of the design.
Severity
Severity is an indicator of the seriousness of the particular logic pattern (CDC scheme). It also reflects the action you are expected to take. The severity levels are: Violation A violation is considered a must-fix problem. For example, an unsynchronized CDC signal from clock domain A to clock domain B might be a concern, so you might want to assign severity violations to all of these CDC schemes. Caution A caution is considered a valid static scheme, but it has an associated CDC transfer protocol that should be verified in simulation or by formal verification. Most cautions have designated CDC protocol checkers that the CDC compiler configures automatically and promotes for assertion-based verification.
39
Evaluation An evaluation is a valid CDC scheme that uses an appropriate synchronizer. The schemes CDC protocol must still be checked.
Proven A proven scheme is a valid CDC scheme with an associated CDC transfer protocol that formal CDC analysis has proven cannot be violated. No CDC protocol checkers for the scheme are promoted for assertion-based verification.
Waived A waived scheme is a CDC scheme with a CDC transfer protocol that does not require verification. CDC data for waived schemes are included in the 0in_cdc database, but no CDC protocol checkers for the scheme are promoted for assertion-based verification.
Filtered (Reporting Off) A filtered scheme is a CDC scheme that does not need CDC analysis. For example, test/configuration logic has a combo_logic scheme, but the combinational logic is constant during regular operation. Here, you can filter this combo_logic scheme so it is not reported (unless set_cdc_preference -filtered_report is specified).
Promotion
Whenever possible, CDC creates and configures a CDC transfer protocol checker for a scheme. Most synchronizers have corresponding protocol checkers. The process of identifying a CDC scheme and creating its protocol checker is called checker promotion. Here, a CDC scheme is deemed OK from a static perspective. The compiler does not have enough information to determine whether or not a synchronization problem will occur. The answer depends on the operating environment of the design. Promoted checkers can be used during simulation to monitor CDC activity and verify proper synchronization of CDC signals. They are also used in static and dynamic formal verification. Use the set_cdc_report global directive (see page 293) to turn off CDC checker promotion for specific CDC schemes.
Signals in Unnamed Blocks

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

Most CDC scheme types refer to synchronization logic. Some schemes apply to single-bit CDC signal synchronization, some apply to multiple-bit data bus synchronization, and some apply to both.
Signals
Signal synchronization schemes identify single-bit CDC signals with various synchronizers. For example, a two_dff scheme uses two in-phase D flip-flops clocked in the receive domain as a synchronizer.
Tx Clock Domain
tx_sig DFF tx_clk DFF DFF rx_clk
Rx Clock Domain
rx_sig
Table 2-1 shows the signal synchronization scheme types. Table 2-1. Signal Synchronization Scheme Scheme async_reset async_reset_no_sync dff_sync_gated_clk four_latch no_sync pulse_sync shift_reg two_dff two_dff_phase Synchronizer Asynchronous reset scheme. none Two flip-flops with gated clock. Three or more cascaded latches. none Pulse. Shift register. Two or more in-phase flipflops. Two out-of-phase flipflops. Custom. Message ASYNC RESET ASYNC RESET NO SYNC DFF GATED SYNC FOUR LATCH SYNCHRONIZER MISSING SYNCHRONIZER PULSE SYNC SHIFT REG TWO DFF SYNCHRONIZER TWO DFF SYNCHRONIZER OPPOSITE POLARITY CUSTOM Default Severity evaluation violation caution evaluation violation evaluation evaluation evaluation caution
custom_sync
evaluation or violation
41
Data
Data synchronization schemes identify multiple-bit CDC data buses with various synchronizers. For example, a bus_two_dff scheme uses two in-phase D flip-flops clocked in the receive domain as a synchronizer.
Tx Clock Domain
tx_data gray encoder DFF
Rx Clock Domain
DFF DFF gray decoder rx_data
tx_clk
rx_clk
Such a synchronizer is typically used for single-bit signals. When used to synchronize data buses, this synchronization scheme should only be used to synchronize data buses that are grey coded (i.e., at most, one bit changes per clock cycle). Table 2-2 shows the data synchronization scheme types. Table 2-2. Data Synchronization Schemes Scheme bus_dff_sync_gated_clk bus_four_latch bus_shift_reg bus_two_dff bus_two_dff_phase multi_bits bus_custom_sync Synchronizer Two flip-flops with gated clock. Four or more cascaded latches. Shift register. Two or more in-phase flipflops. Two out-of-phase flipflops. none Multi-bit custom. Message BUS DFF GATED SYNC BUS SYNC BUS SHIFT REG BUS SYNC BUS SYNC MULTIPLE BITS BUS CUSTOM Default Severity caution caution caution caution caution caution evaluation
42
Signal/Data
Signal/data synchronization schemes identify CDC signals and data buses with various synchronizers. For example, a DMUX scheme uses two in-phase D flip-flops clocked in the receive domain to synchronize the select signal to a MUX that selects the CDC data. The CDC data can be either a single-bit signal or a multiple-bit data bus.
Tx Clock Domain
tx_data
Rx Clock Domain
MUX rx_data
tx_clk tx_sel DFF tx_clk DFF rx_sel rx_clk
Table 2-3 shows the signal/data synchronization scheme types. Table 2-3. Signal and Data Synchronization Schemes Scheme custom_sync_with_cros sing simple_dmux dmux handshake memory_sync fifo multi_sync_mux_select Synchronizer Custom. Message CUSTOM WITH CROSSING SIMPLE_DMUX DMUX HANDSHAKE MEMORY SYNC FIFO MULTIPLE SYNCHRONIZERS AT DMUX Default Severity evaluation or violation caution caution caution caution caution caution
Restricted/simple MUX enable. MUX enable. MUX enable with handshaking. 2D array. FIFO. Multiple MUXs.
43
Schemes with Potential CDC Problems

In addition to identifying CDC synchronization schemes, the CDC compiler identifies CDC schemes that exhibit the potential for error. For example, combinational logic in a CDC path could cause a valid synchronizer to malfunction.
combinational logic tx_data synchronizer tx_clk rx_clk rx_data
Tx Clock Domain
Rx Clock Domain
Table 2-4 shows the potential CDC problem scheme types. Table 2-4. Potential CDC Problem Schemes Scheme blackbox combo_logic fanin_different_clks Problem Black box in fan-out of a synchronized signal. Combinational logic on a synchronization path. Fan-in logic from multiple clock domains. Reconvergent CDC signals. Reconvergent CDC signals from a single source. CDC signal drives multiple synchronizers. Custom synchronizers connected in series. Custom synchronizers connected in series. Message BLACKBOX COMBO LOGIC FANIN LOGIC FROM DIFFERENT CLOCKS RECONVERGENCE SSR Default Severity caution violation violation
reconvergence single_source_reconvergence
violation violation
redundant port_constraint_mismatch series_redundant
REDUNDANT SERIES REDUNDANT SERIES REDUNDANT
violation violation caution
44
CDC Basics Static CDC Analysis
Static CDC Analysis

Static CDC analysis performs the following critical functions for CDC verification: 1. Verifies synchronizers. Static CDC analysis examines the design RTL and uses the user-specified and inferred clock groups to find the clock trees that determine the clock domains in the design. It then assigns each register to a clock domain. Static CDC analysis identifies the CDC signals by finding registers that drive registers from other clock domains and verifying that correct synchronizers are present on all CDC signals. 2. Identifies CDC schemes. Static CDC analysis categorizes each CDC logic pattern as one of a set of predefined CDC schemes. For example, one scheme contains all single-bit CDC signals that are synchronized by two-register data synchronizers. Another scheme contains all multiplebit CDC signals that are not synchronized. Some schemes are identified as violations. For example, the following figure shows single-bit CDC signals with combinational logic driving, or within, the synchronizers.
combinational logic between DFFs tx_sig DFF tx_clk DFF DFF rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
combinational logic drives input to synchronizer tx_sig DFF tx_clk DFF DFF rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
You can redefine the statuses used for the different schemes. For example, you can make latch synchronization a violation. 3. Verifies certain CDC protocols If CDC formal verification is enabled, static CDC analysis includes static formal analysis of certain CDC protocols. 4. Promotes CDC protocol checkers. Static CDC analysis generates CDC protocol checkers for certain CDC schemes based on their scheme type, transmit clock, transmit signals, receive clock and receive signals.
45
CDC checkers are not promoted for CDC schemes that have severity proven, evaluation, waived or filtered. Promoted checkers represent CDC protocols that need assertionbased analysis by the 0-In formal tools and possibly simulation.
Formal CDC
Formal CDC is an advanced option of static CDC analysis that tries to verify the CDC transfer protocols of certain CDC schemes using a built-in formal proof engine. Formal CDC analyzes the fanin logic of these CDC schemes. If formal CDC finds a proof that a CDC schemes protocol cannot be violated, that scheme is reported as a proven scheme. Since the schemes synchronization is valid, no protocol checker is promoted for the scheme. If CDC formal analysis cannot find a proof that the protocol cannot be violated, the result is inconclusive. So, the associated protocol checker is promoted for verification by the 0-In formal tools or by simulation. The proportion of time formal CDC spends analyzing protocols is controlled by the formal CDC effort level:
low > medium > high > maximum
The default formal CDC effort level is low. Running static CDC with a higher formal effort level can result in additional proven CDC schemes. The formal CDC engine is tuned to analyze two specific types of CDC protocols: signal stability protocols and gray-coding protocols.
Signal Stability Protocols

Single-bit CDC signals can be synchronized by various different types of synchronizers. However, such synchronization must follow a signal stability protocol where each new value of a transmit signal is held stable long enough for the receiving domain to sample it at least twice. Formal CDC tries to find proofs for the signal stability protocols by analyzing the transmit signal pulse widths of the following types of CDC schemes: dff_sync_gated_clk four_latch pulse_sync shift_reg two_dff two_dff_phase
46
Gray-Coding Protocols
Multibit CDC signals (i.e., data buses) can be synchronized by synchronizers typically used for single-bit signals. However, such synchronization must follow a gray-coding protocol where only one data bit changes at a time. Formal CDC tries to find proofs for the gray-coding protocols of the following types of CDC schemes: bus_dff_sync_gated_clk bus_four_latch bus_shift_reg bus_two_dff bus_two_dff_phase reconvergence (if enabled by set_cdc_preference -promote_reconvergence).
CDC Protocol Checker Promotion

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

A checker is a conglomeration of assertions and a CDC protocol checker is a special type of checker configured to verify the CDC transfer protocol for a CDC synchronization scheme. A CDC protocol checkers assertions completely characterize its associated synchronization
47
scheme. If a design cannot violate any of the checkers assertions, then the design obeys the associated CDC synchronization scheme. The CheckerWare assertion library includes the set of CDC checkers described in the CheckerWare Data Book. CheckerWare CDC checkers are available for the common CDC synchronization schemes. Static CDC analysis identifies the synchronization schemes used for the CDC signals in the design. Based on the analysis, CDC promotes instances of CheckerWare CDC checkers depending on the synchronization scheme (although not all schemes have associated promoted checkers). The promoted checkers validate CDC behavior during assertion-based verification and are report in the automatically generated output 0in_cdc_ctrl.v file (see Example 2-1 for a snippet of this file). Example 2-1. Promoted CDC Checkers
// Synchronized multi-bit variable fifo_0_h.rp_s1 /* 0in cdc_hamming1 -tx_clock mac_clk_in -tx_var fifo_0_h.rp_gray -name bus_two_dff_62001 -module demo_top -inferred */ /* 0in cdc_sample -tx_var init_done -rx_var tx_state[0] -tx_clock cpu_clk_in -rx_clock core_clk_in -areset ( ( ! rst) ) -name no_sync_47305 -module demo_top -inferred */ /* 0in cdc_dsel -tx_data fstp[7:1] -rx_data crc_1.scramble -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 */ /* 0in cdc_glitch -var check_en_r1 -clock mac_clk_in -name combo_logic_85239 -module demo_top -inferred */ . . .
48
CDC Basics Formal Verification
Path and Protocol ID

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

/* 0in cdc_sample -tx_var crc_seed[7:1] -rx_var crc_1.crc_16 -tx_clock cpu_clk_in -rx_clock mac_clk_in -name multi_bits_76265 -module demo_top -inferred */
The Design Tab of the Workspace window of the 0in_cdc viewer. The Detail window of the 0in_cdc viewer.
Formal Verification
Formal verification uses mathematical analysis to verify a designs assertions. It has an advantage over simulation with assertions as it automatically analyzes complex corner cases that are difficult to simulate. Whereas a simulated design only covers the state spaces reached by simulation, formal analysis coverage is exhaustive. CDC checkers are compatible with the 0-In Formal tools: Prove and Confirm. Only a small incremental effort is needed as the 0-In Formal tools use the same configuration files and assertions as assertions in simulation. A designs individual assertions (including CDC checker assertions) are called formal targets when they are used as goals that the formal tools try to prove or disprove. Other assertions can be used as guides for the formal tools to ensure they do not attempt to test illegal behavior. These assertions are called formal constraints. The CDC checkers assertions are always used as targets, not constraints. Prove is a property checker that tries to prove targets cannot be violated. Targets with inconclusive results are passed to Confirm to attempt to disprove them. These tools disprove a target assertion by finding a counterexample to the assertion. A counterexample is a legal stimulus sequence applied to the design that eventually makes the assertion fail (that is, fire). Counterexamples are also called assertion firings. Refer to the 0-In Formal User Guide for information regarding the 0-In Formal tools.
49
CDC Basics Simulation
Simulation
To simulate a design with CDC checkers, use assertions in simulation and your standard HDL simulator. During assertions in simulation, the CDC checkers verify the functionality of the CDC protocols. A violation of a protocol assertion makes the associated CDC checker fire. To debug assertion firings, use the 0in_cdc viewer. Use the File >Merge Database command to load the database from the simulation, then from CDC Checks tab, you can browse the data for assertion firings (Figure 2-9). Figure 2-9. CDC Checks Simulation Results
To invoke the waveform viewer with the assertion firing from simulation (Figure 2-10) right click on the Firing in the Transcript window and select Show Firings to display the Firings window. Select all firings or an individual firing to show the waveform.
50
Figure 2-10. Show Simulation Firings
View the coverage statistics for the simulation from the Workspace window Design tab (Figure 2-11). View the checker information and simulation details from the Details window (Figure 2-12).
51
Figure 2-11. Simulation Coverage
Figure 2-12. Checker Simulation Details
52
CDC Basics Status Flags
Status Flags
Status flags give you a quick assessment of the results of CDC verification from the CDC GUI. The flags help you determine which CDC issues to examine first and they highlight additional problems you should investigate. Figure 2-13 shows a region of a CDC checks tab in the results pane of the CDC GUI after a CDC verification session, formal verification and simulation with the promoted CDC checkers. Entries can have Static status, Prove status and Simulation status as described in Table 2-5. Figure 2-13. CDC Checks Status Flags
status ags in CDC Checks tab
Table 2-5. CDC Checks Status Flags Flag Description Violation and Firing CDC schemes severity level is violation and its protocol is violated in simulation. Violation CDC schemes severity level is violation. Firing CDC schemes protocol is violated in simulation. Proven CDC schemes protocol cannot be violated. Evaluation CDC schemes severity level is evaluation. Static Prove Sim
53
CDC Basics Status Flags
Table 2-5. CDC Checks Status Flags Flag Description Covered CDC schemes protocol checkers cover points are covered in simulation. Caution CDC schemes severity level is caution. Inconclusive CDC schemes protocol is not guaranteed. Formal analysis could not prove the protocol cannot be violated. Evaluated CDC schemes protocol checker is evaluated in simulation. Not Promoted CDC scheme has no protocol checker automatically generated or the protocol checker is not promoted because the protocol is proven valid during static CDC analysis. Waived CDC schemes severity level is waived. Filtered CDC schemes severity level is off. Static Prove Sim
54
Chapter 3 Compilation
CDC analysis runs on a compiled image of the design logic plus a clock domain model. A set of design compilation utilities is used to compile the design logic from source files. Then, the CDC analyzer (cdc) is used to create a clock domain model. If this compilation completes without error, cdc performs CDC analysis and generates data for the CDC GUI. Two methods can be used to compile the design and clock domain model, and then perform CDC analysis: 1-Step Compilation Instead of running the design compilation utilities separately from the cdc command, add the arguments for design compilation to the cdc invocation. The design is compiled first (using the design compilation utilities under-the-hood). Then, the clock domain model is created and CDC analysis is performedall in one step using the cdc command. This method only works for restricted Verilog designs. 2-Step Compilation Use the design compilation utilities to create and maintain a compiled design library. Use the cdc command to compile the clock domain model and run CDC analysis. Figure 3-1. CDC Compilation Methods
1-Step Compilation
Questa Compilers and Library Management Tools
Compile design libraries and clock domain model
Verilog design les
design libraries clock domain model
0in -cmd cdc

control les
2-Step Compilation
design les
Compile design libraries
design libraries clock domain model Compile clock domain model
control les
0in -cmd cdc
55
Compilation 1-Step Compilation
1-Step Compilation
For the compilation of Verilog-only designs (but not SystemVerilog) you can use the 1-step compilation method. To do this, add the 1-step compilation arguments (Table 3-1) to the cdc invocation. The cdc compiler uses the design compilation utilities under-the-hood to compile the design and stores the compiled design library in the 0in cache. For example:
cdc -d dut -ctrl ctrl.v -f design.f +define+mode=initialized -y ../mylib
See cdc: Clock Domain Crossing Analyzer on page 64 for a description of the cdc command and clock domain model compilation. Table 3-1. 1-Step Compilation Options {Verilog_file | f filelist} [-v95] [+define{+macro[=value}] [+incdir{+include_dir}] [+libext{+extension}] [y library_dir] [v library_file] [skip_protected_modules] [skip_protected_code] [ignore_translate_off] [ignore_synthesis_off] [modelsimini init_file]
Verilog_file f filelist v95 +define{+macro[=value]} +incdir+dir +libext{+extension} y library_dir v library_file skip_protected_modules skip_protected_code
ignore_translate_off ignore_synthesis_off
Verilog source files. File containing additional Verilog design files and arguments Verilog version is Verilog 95. Default: Verilog 2K. Text macro specification. Include directory. File extensions to use when searching for library files. For example, +libext+.v. Directory containing library files. Library file. Skip encrypted modules. Skip encrypted code. This option skips parsing of all modules containing any protected code. This can result in the parent module being black-boxed (because it causes the module to be unresolved). Include logic in translate_off blocks. Ignore synthesis_off directives.
56
2-Step Compilation
With the 2-step compilation method, first use the design compilation utilities to create and maintain a compiled version of the design logic. Then, use the cdc command to create the clock domain model and perform CDC analysis.
Step 1: Compile and Maintain Design Libraries

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

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

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

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

modelsimini modelsim.ini_file $MODELSIM $MGC_WD/modelsim.ini ./modelsim.ini $MODEL_TECH/modelsim.ini $MODEL_TECH/../modelsim.ini $MGC_HOME/lib/modelsim.ini vlog/vcom compilers set $MODEL_TECH internally to the install directory for the tool. For 0-In tools, this directory is: zeroin_install_dir/modeltech/plat Finding which modelsim.ini le is used prompt> vsim -c QuestaSim> where # Current directory is: /u/cdc_demo # Project is: modelsim.ini
Compiling Design Files

After initializing the work design library and setting up the modelsim.ini file, you can compile design files into the work library (Figure 3-5). Figure 3-5. Compiling Design Files
design les modelsim.ini
vcom/vlog
append/update
work
Use vcom to compile VHDL style source files and vlog to compile Verilog style (including SystemVerilog) source code. These compilers have long lists of arguments, but many options are used to fine-tune simulation (vsim). Table 3-2 and Table 3-3 show the options that are relevant to 0-In analysis. Table 3-2. vcom Syntax vcom [compile_options] VHDL_file... VHDL_file VHDL source files. compile_options [-work logical_name] [modelsimini init_file] [-87 | -93 | -2002 | -2008] [-explicit] [-skipsynthoffregion [-synthprefix keyword]] [-check_synthesis] [-noindexcheck | -norangecheck | -nocheck] [{-fatal | -error | -warning | -note | -suppress} num[,num]...]... [-source] [-time] [-nowarn number]... [-quiet] [-mixedsvvh [b | l | r] [i]] [-pslfile vunit_file]... [-f arg_file]... [other_vcom_options]
59
Table 3-3. vlog Syntax vlog [compile_options] Verilog_file... Verilog_file compile_options HDL source files. [-work logical_name] [-libmap file [-libmap_verbose]] [modelsimini init_file] [{-Lf | -L } library]... [-vlog95compat | -vlog01compat] [-skipsynthoffregion [-synthprefix keyword]] [-skipprotected | -skipprotectedmodule] [-pedanticerrors] [-timescale units/precision] [+define{+macro[=value}] [-convertallparams] [+floatparameters[+param_path[.]]] [+incdir{+include_dir}] [+libext{+extension}] [{-fatal | -error | -warning |-note |-suppress} msg[,msg]...]... [-source] [-time] [-nowarnID | -nowarn number]... [-quiet] [-93] [-u] [-sv] [-mixedsvvh [b | s | v] [packedstruct]] [-mfcu [-cuname comp_unit] | -sfcu] [-pslfile vunit_file]... [-y library_dir] [-v library_file] [printinfilenames] [-f arg_file]... [other_vlog_options]
Compile Order
For a Verilog compilation, you can compile almost all compilation units in any order using any number of invocations of vlog. When cdc and csl load the compiled design, they resolve model instantiations and external hierarchical references. The one case where order matters is:
SystemVerilog packages must exist for the items they define to be recognized by the scopes in which they are imported. IEEE Std 1800-2005 LRM
For a VHDL compilation, order matters: you must compile entities/configurations before the architectures that reference them.
Resource Libraries
A resource library is a pre-compiled parts source for your design. It is typically a static library supplied by a vendor or another design team, but you also can create your own resource libraries. Resource libraries are compiled into libraries distinct from work using the same vlib/vmap and vcom/vlog utilities used for compiling the work design library. The distribution software includes pre-compiled resource libraries for common uses, located in <zeroin_install_dir>/modeltech. The [Library] section of the system-level modelsim.ini file (<zeroin_install_dir>/modeltech/modelsim.ini) shows these resource libraries:
[Library] std = $MODEL_TECH/../std ieee = $MODEL_TECH/../ieee verilog = $MODEL_TECH/../verilog vital2000 = $MODEL_TECH/../vital2000 std_developerskit = $MODEL_TECH/../std_developerskit synopsys = $MODEL_TECH/../synopsys
60
Compilation 2-Step Compilation modelsim_lib = $MODEL_TECH/../modelsim_lib sv_std = $MODEL_TECH/../sv_std mtiAvm = $MODEL_TECH/../avm mtiOvm = $MODEL_TECH/../ovm-2.1 mtiUPF = $MODEL_TECH/../upf_lib mtiPA = $MODEL_TECH/../pa_lib floatfixlib = $MODEL_TECH/../floatfixlib mc2_lib = $MODEL_TECH/../mc2_lib
The [Library] section of the modelsim.ini file shows the library mappings for user-defined libraries as well. For example, suppose you create a library with the physical location ../shiba and map this library to the logical name my_shiba.
prompt> vlib ../shiba prompt> vmap my_shiba ../shiba
If the local run directory does not already have a modelsim.ini file, vmap copies a version of $MODEL_TECH/../modelsim.ini to the local run directory. Then, vmap updates modelsim.ini with the new mapping:
prompt> more modelsim.ini . . . [Library] others = $MODEL_TECH/../modelsim.ini my_shiba = ../shiba work = work
If you use vmap to map a library to a logical name that is already mapped in the local modelsim.ini file, the new mapping simply replaces the old mapping. However, if you edit the local modelsim.ini file and specify two library mappings with the same logical name, the file is corrupt and you get an error when you try to compile. The others clause in the [Library] section has a special meaning. If a compiler does not find a referenced library in the local modelsim.ini file, but the local modelsim.ini file has an others clause, the compiler checks the [Library] section of the file specified by others. As with library mappings, only one others clause is allowed in a modelsim.ini file. However, note that the others clause provides a method for creating a hierarchy of library mappings because the file referred in an others clause can contain another others clause, and so on.
Verilog Compilation with Resource Libraries

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

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

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

CDC analysis is performed on synthesizable objects in the design: CDC analysis treats modules/entities that contain unsynthesizable code as inferred black boxes. In addition, some VHDL FPGA libraries use VITAL constructs. These are not synthesizable, so resource library elements containing any of these constructs are inferred as black boxes as well. Some Verilog FPGA libraries contain UDPs, but (unlike VITAL constructs) 0-In compilation automatically remodels most of these into synthesizable RTL. However, some Verilog FPGA resource library elements model global signals (i.e., signals accessible throughput the design) as hierarchical references to signals in separate top-level blocks outside the DUT. Library elements that reference global signals in this way are also analyzed as inferred black boxes. You can manually identify the clock domains of ports of these black boxeswhich helps with the analysis of CDC issues outside the black boxesbut internal clock domain crossing information of black boxes is missing. The best solution for CDC analysis is to use synthesizable libraries.
63
Some general-purpose FPGA resource libraries are available in synthesizable form. These libraries are often called formal-friendly because they are usable with formal model checkers such as 0-In Formal and formal equivalence checkers such as FormalPro. They are also appropriate for the 0-In CDC analyzer and other tools that need to synthesize a netlist. Some FPGA vendors (for example, Altera and Actel) include synthesizable libraries in their standard design kit installations. Xilinx, however, does not include the synthesizable unisim and simprim libraries within its standard ISE software installation. Synthesizable resource libraries (optimized for 0-In tools) and other supporting files for two common FPGA library families are included with the 0-In distribution software in the following directories:
$HOME_0IN/share/fpga_libs/Altera $HOME_0IN/share/fpga_libs/Xilinx
If the FPGA libraries used for simulation are synthesizable (which is rare except for Verilogonly designs), recompilation of the pre-compiled libraries might not be necessary for CDC analysis. In all other cases, you must compile an appropriate version of the library source files for use with 0-In CDC. When synthesizable FPGA resource libraries are available, you should use them instead of the unsynthesizable libraries optimized for simulation. The VHDL IEEE, STD and SYNOPSYS libraries are pre-compiled and are automatically recognized by 0-In software. You must compile all other resource libraries using the vcom/vlog commands on the appropriate FPGA library source files. If you have a VHDL-only design or if you have a mixed-language design with library elements instantiated in VHDL, first compile the VHDL component definitions (but not the VHDL models of the library elements) and then compile the appropriate Verilog library models.
Step 2: Run CDC Compilation

cdc: Clock Domain Crossing Analyzer
The cdc command runs within a special shell called the 0in shell (see 0in on page 347), which can run as a batch process or interactively. To run cdc as a batch process, use the -cmd option to 0in:
prompt> 0in -cmd cdc cdc_options
The cdc command performs 1-step compilation if necessary, compiles the clock domain model and performs CDC analysis. Table 3-4 shows the syntax for the cdc command (the 1-step compilation options are hidden).
64
Table 3-4. cdc Syntax cdc d design [ report_clock | report_modes | hier_cdc_options] [work work_library] [{L | Lf} library] [cuname comp_unit] [cache pathname] [options] d design report_clock report_modes HDL design unit to be verified. Report only clock domains and exit. Default: perform full CDC analysis. Infer all modes of operation or verifies the user-defined modes and exits (without doing any CDC analysis). Generate a modal script (0in_mode.scr). [report_hier_scripts | report_constraints block | hier | hier_block block | hier_instance instance | [hier_cache ILM_cache] [hier_ctrl_file_model block CFM_ctrl_file]] Logical name of the design library containing precompiled design units. Also used as the target library for compilation performed by cdc. Default: work in the current run directory. Resource library containing pre-compiled modules for the compilation. Name of a compilation unit specified to vlog. 0in cache directory. Default: same as the 0in shell cache directory. [ [ctrl file] [ctrl_list filelist] [v95 | v2k | sv] ] [vhctrl control_file] [93 | 87 | 2002 | 2008] | [ctrl_module module] ] [cr report_file] [verbose] [gen_port_domain_template] [print_all_cdc_paths] [+nowarn{+messageID}] [+error{+messageID}] [sdc_in sdc_file] [sdc_out file] [report_sdc] [de {[mod.]inst_pattern}] [di {[mod.]inst_pattern}] [G name=value] [g name=value] [mode mode] [fx] [process_dead_end] [effort unlimited] [compile_assertions prefix hierarchy_prefix [compiled_assertion_report file] [sim {questa | vcs | nc | nc3}] [sif root_name] [rel_paths] ]
hier_cdc_options
work work_library
L library | Lf library cuname comp_unit cache pathname control options
reporting options
sdc options advanced options
compile cdc assertions options
65
Compilation SDC Data
SDC Data
You can import an SDC file for the CDC compilation. Each supported SDC command is converted to an equivalent 0-In global directive. Similarly, you can export an SDC file at the end of CDC compilation and analysis. The relevant global directives, the inferred clocks and the inferred port domains are converted to equivalent SDC commands.
Importing an SDC File

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

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

When you export an SDC file, appropriate global directives are converted to equivalent SDC commands (Table 3-6). In addition, inferred clocks and port domains are converted to equivalent SDC commands (Table 3-6). Table 3-6. Exported SDC Commands Global Directive set_cdc_clock set_cdc_port_domain set_cdc_port_domain set_constant set_cdc_report -severity off SDC Command create_clock set_input_delay set_output_delay set_logic_one, set_logic_zero set_false_path
Table 3-7. Inferred Clocks and Port Domains Design Object Top-level inferred clock Inferred domain for primary input port Inferred domain for primary output port CDC path By default, all CDC paths are written. To export an SDC file characterizing the CDC constraints (Example 3-2), include the -sdc_out option in the cdc invocation:
prompt> 0in -cmd cdc -sdc_out file ...
SDC Command create_clock set_input_delay set_output_delay set_false_path
67
Example 3-2. SDC Export File

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

The 0-In tools can analyze most design styles seamlessly. However, some design styles and HDL constructs cannot be represented in the CDC analysis model. As cdc compiles the CDC model of a DUT, it handles each unsupported design style or construct in one of the following ways: The parent module/entity containing the design style is automatically marked as an inferred black box. Output signals of a black box are treated as asynchronous inputs to the DUT, which can result in extra violations. Mark the module/entity as a user-defined black box (see set_black_box on page 262) to remove these violations. Inputs to black boxes are reported as blackbox schemes with caution severity, by default. The cdc compiler terminates with an error. You must eliminate the error before cdc can compile the CDC model.
You have the following ways to manually adjust the compilation of the CDC model of a DUT. Skipping system calls (+skip_syscall). The outputs of unknown system calls are ignored. You can get cdc to skip over system calls when compiling the CDC model. To direct cdc to bypass one or more system calls and omit them from the CDC logic, use the +skip_syscall option to the cdc command. This option has the following syntax:
+skip_syscall{+syscall_name}. . .
Marking modules as black boxes (set_black_box). When a module cannot be synthesized and is part of the DUT, it can be skipped by marking it as a black box. A module is marked as a black box using the following checker directive in the checker control file:
// 0in set_black_box module_name
Use the set_cdc_port_domain global directive to identify the clock domains of the I/O ports of these user-defined black boxes. The following HDL constructs can impact cdc performance, creating long cdc run times and high memory consumption. Variable bit-selects and variable shifts on large bit-vectors (greater than 1000 bits) used in nested for-loop statements. Large 2-D arrays (greater than 100words) defined in the local scope of a function/task. Large numbers of gate-level instances. Large numbers of functions or tasks used in nested for-loop statements.
69
synthesis_off and translate_off Regions

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

-- synopsys translate_off entity bot... end entity -- synopsys translate_on -- synopsys translate_off arch bot... end arch -- synopsys translate_on -- synopsys translate_off entity top... end entity -- synopsys translate_on -- synopsys translate_off arch top u1: bot end arch -- synopsys translate_on
override_on/override_off Parser Directives

If you specify -skipsynthoffregion and then want the Questa compilers to process a translate_off or synthesis_off region, enclose the region in the 0in override_on and 0in override_off comments:
//0in override_on // synopsys translate_off synthesis translate_off block // synopsys translate_on //0in override_off
71
Verilog
The 0-In compilers mark objects containing unsupported code as black boxes or if problems are too severe, cdc terminates with errors. By default, all output signals from a black box (and all signals in the black box) are treated as primary inputs to the DUT. If possible, use ifdef directives or remodel the constructs. Table 3-8 shows the unsupported Verilog-95 (-v95) and Verilog 2005 (default) constructs. Table 3-8. Unsupported Verilog Constructs Gates Statements cmos, nmos, pmos, rcmos, rnmos, rpmos, tran, tranif1, tranif0, rtran, rtranif1, rtranif0, comb, seq, mos. forever, while, deassign, force-release, wait, fork, join for- and repeat-loop statements that are not statically unrollable. Reals. Reentrant tasks and recursive functions. Unknown functions (undefined and predefined system tasks/functions). Unsupported asynchronous reset templates. Multiple ports with the same name and inconstantly-defined ports (i.e., a port defined by a non-ANSI port definition or missing port direction/type). Events, event declarations and event control assignments. Disables with hierarchical labels. Non-constant parameters, loop indexes and part selects. Different load conditions for memory. Attributes are partly supported.
Numbers Tasks and Functions
Resets Ports
Other Constructs
Table 3-9 lists the restrictions on the Verilog design styles enforced by the 0-In compilers. Table 3-9. Verilog Design Style Restrictions Resets Primary inout ports cannot be used as resets. These are cdc errors. Bused single-bit asynchronous reset are supported but multiplebit asynchronous reset signals are not. For example, the following code produces an elaboration-541 error (Multi-bit reset signals are not supported) and cdc terminates:
input [0:3] arst_vector; reg r; always @(posedge clk or posedge arst_vector) if (arst_vector) r <= 0; else if (e) r <= d;
72
Table 3-9. Verilog Design Style Restrictions (cont.) If an asynchronous reset does not follow one of the following templates, the parent module is marked as a black box):
always @(posedge_negedge clock or posedge areset) if (areset) (. . . ) else (. . . )
or
always @(posedge_negedge clock or negedge areset) if (!areset) (. . . ) else (. . . )
Clocks always Blocks
Primary inout ports cannot be used as clocks. These are cdc errors. Memories driven in multiple always blocks are not supported. Their outputs are degraded. The same register bit must not be driven in multiple always blocks. The entire register output is degraded. (Individual bits in a register can be driven in different blocks.) Tasks and functions should not retain state between calls. A task or function called from a combo always block or a function on the RHS of a continuous assign statement cannot modify a state (register) outside of the task or function. Otherwise, these calls result in simulation/synthesis mismatches. Functions can call SVA built-in functions (for example, $past). But if the built-in SVA function does not have an explicit clock, the calling Verilog function must have a default clocking block. Combinational loops are not supported. RAMs with multiple write clocks are not supported. These are cdc errors. Supported: Edge-sensitive sequential UDPs (single clock, single edge), level-sensitive sequential UDPs, combinatorial UDPs. UDPs with notifiers are not black-boxed (notifier row is ignored for synthesis). Not supported: Multiclock UDPs and UDPs working on both the edges of a clock. Logic has a race condition when the order of arrival of two signals at a point is indeterminate and the exact arrival order affects the designs state. For example, if a data signal and clock signal arrive simultaneously at a register, the data signal might, or might not, be clocked at that time. In simulation, the outcome is simulator-dependent. With CDC analysis, the clock signal takes precedence.
Tasks and Functions
Combinational Loops RAMs UDPs
Race Conditions
73
Table 3-9. Verilog Design Style Restrictions (cont.) Initial Blocks Blocking Delay Statements bind to VHDL Other Constructs Initial blocks are ignored. Blocking delay statements are compiled without the delays. When a bind statement has a user-defined type, it must be defined in a VHDL package. specify, uselib and resetall statements are ignored. Selects such as sig[a:b] are only supported if a and b expressions are constant at elaboration time. Clashes in variables and instance names should be avoided.
74
VHDL
Compiler support for IEEE 1076-1993 Standard VHDL Language Reference Manual (LRM) constructs is shown in Table 3-10. Unless otherwise noted, each construct in the table is completely supported. Table 3-10. Supported VHDL Constructs LRM Section 1 1.1 1.1.1 1.1.1.1 1.1.1.2 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 LRM Section 2 2.1 2.1.1 2.1.1.1 2.1.1.2 2.1.1.3 2.2 2.3 2.3.1 2.3.2 2.4 2.5 2.6 2.7 LRM Section 3 3.1 3.1.1 3.1.1.1 3.1.2 3.1.2.1 3.1.3 3.1.3.1 3.1.4 3.1.4.1 Design Entities and Configurations Entity declarations Entity header Generics Ports Entity declarative part Entity statement part Architecture bodies Architecture declarative part Architecture statement part Configuration declarations Block configuration Component configuration Subprograms and Packages Subprogram declarations Formal parameters Constant and variable parameters Signal parameters File parameters Subprogram bodies Subprogram overloading Operator overloading Signatures Resolution functions Package declarations Package bodies Conformance rules Types Scalar types Enumeration types Predefined enumeration types Integer types Predefined integer types Physical types Predefined physical types Floating point types Predefined floating point types
not supported
not supported
not supported not supported
75
Table 3-10. Supported VHDL Constructs (cont.) 3.2 3.2.1 3.2.1.1 3.2.2 3.3 3.3.1 3.3.2 3.4 3.4.1 LRM Section 4 4.1 4.2 4.3 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.2 4.3.2.1 4.3.2.2 4.3.3 4.3.3.1 4.3.3.2 4.4 4.5 4.6 4.7 LRM Section 5 5.1 5.2 5.2.1 5.2.1.1 5.2.1.2 5.2.2 5.3 LRM Section 6 6.1 6.2 6.3 6.4 6.5 6.6 Composite types Array types Index constraints and discrete ranges Record types Access types Incomplete type declarations Allocation and de-allocation of objects File types File operations Declarations Type declarations Subtype declarations Objects Object declarations Constant declarations Signal declarations Variable declarations File declarations Interface declarations Interface lists Association lists Alias declarations Object aliases Non-object aliases Attribute declarations Component declarations Group template declarations Group declarations Specifications Attribute specification Configuration specification Binding indication Entity aspect Generic map and port map aspects Default binding indication Disconnection specification Names Names Simple names Selected names Indexed names Slice names Attribute name
not supported not supported not supported not supported
not supported
not supported not supported not supported
not supported
76
Table 3-10. Supported VHDL Constructs (cont.) LRM Section 7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.3 7.3.1 7.3.2 7.3.2.1 7.3.2.2 7.3.3 7.3.4 7.3.5 7.3.6 7.4 7.4.1 7.4.2 7.5 LRM Section 8 8.1 8.2 8.3 8.4 8.4.1 8.5 8.5.1 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 Expressions Expressions Operators Logical operators Relational operators Shift operators Adding operators Sign operators Multiplying operators Miscellaneous operators Operands Literals Aggregates Record aggregates Array aggregates Function calls Qualified expressions Type conversions Allocators Static expressions Locally static primaries Globally static primaries Universal expressions Sequential Statements Wait statement Assertion statement Report statement Signal assignment statement Updating a projected output waveform Variable assignment statement Array variable assignments Procedure call statement If statement Case statement Loop statement Next statement Exit statement Return statement Null statement
not supported
see Table 3-11 on page 80 parse/ignore parse/ignore parse/ignore
77
Table 3-10. Supported VHDL Constructs (cont.) LRM Section 9 9.1 9.2 9.3 9.4 9.5 9.5.1 9.5.2 9.6 9.6.1 9.6.2 9.7 LRM Section 10 10.1 10.2 10.3 10.4 10.5 LRM Section 11 11.1 11.2 11.3 11.4 LRM Section 12 12.1 12.2 12.2.1 12.2.2 12.2.3 12.2.4 12.3 12.3.1 12.3.1.1 12.3.1.2 12.3.1.3 12.3.1.4 12.3.1.5 12.3.1.6 12.3.1.7 Concurrent Statements Block statement Process statement Concurrent procedure call statements Concurrent assertion statements Concurrent signal assignment statements Conditional signal assignments Selected signal assignments Component instantiation statements Instantiation of a component Instantiation of a design entity Generate statements Scope and Visibility Declarative region Scope of declarations Visibility Use clauses The context of overload resolution Design Units and Their Analysis Design units Design libraries Context clauses Order of analysis Elaboration and Execution Elaboration of a design hierarchy Elaboration of a block header The generic clause The generic map aspect The port clause The port map aspect Elaboration of a declarative part Elaboration of a declaration Subprogram declarations and bodies Type declarations Subtype declarations Object declarations Alias declarations Attribute declarations Component declarations
not supported
78
Table 3-10. Supported VHDL Constructs (cont.) 12.3.2 12.3.2.1 12.3.2.2 12.3.2.3 12.4 12.4.1 12.4.2 12.4.3 12.4.4 12.5 12.6 12.6.1 12.6.2 12.6.3 12.6.4 LRM Section 13 13.1 13.2 13.3 13.3.1 13.3.2 13.4 13.4.1 13.4.2 13.5 13.6 13.7 13.8 13.9 13.10 LRM Section 14 14.1 14.2 14.3 Elaboration of a specification Attribute specifications Configuration specifications Disconnection specifications Elaboration of a statement part Block statements Generate statements Component instantiation statements Other concurrent statements Dynamic elaboration Execution of a model Drivers Propagation of signal values Updating implicit signals The simulation cycle Lexical Elements Character set Lexical elements, separators, and delimiters Identifiers Basic identifiers Extended identifiers Abstract literals Decimal literals Based literals Character literals String literals Bit string literals Comments Reserved words Allowable replacements of characters Predefined Language Environment Predefined attributes Package STANDARD Package TEXTIO
not supported
Unqualified constructs in Table 3-10 are completely supported. Other constructs are qualified as follows: not supported Modules/entities containing constructs identified as not supported are inferred black boxes. parse/ignore Constructs identified as parse/ignore are recognized and do not cause parsing errors, but no assertion logic is generated for the constructs.
79
Design styles described in Standard for VHDL RTL Synthesis, Section 6.1 Edge Sensitive Sequential Logic are supported, except as qualified in Table 3-11. Table 3-11. VHDL Design Style Restrictions Multiple Clocked Blocks (unsupported styles) Multiple active clocked blocks in the same process are not supported. For example:
multiEnableEdgeProc : process(clk, reset) begin if reset = 1 then Q <= 0; elsif e1 = 1 and rising_edge(clk) then Q <= D11; elsif e2 = 1 and rising_edge(clk) then Q <= D12; end if; end process;
The workaround is to model the same functionality using a supported clocking style. For example:
multiEnableEdgeProc : process(clk, reset) begin if reset = 1 then Q <= 0; elsif rising_edge(clk) then if e1 = 1 then Q <= D11; elsif e2 = 1 then Q <= D12; end if; end if; end process;
Multiple Clocked Blocks (supported styles)
One block reachable at a time Multiple clocked blocks are supported if the compiler determines that only one block is reachable at a time. For example:
-- Generic_value is a generic with some value -- Only one of the clocked blocks below is -- reachable in a particular design. multiEnableEdgeProc : process(clk, reset) begin if Generic_value = 1 then if rising_edge(clk) then Q <= D11; end if; else if rising_edge(clk) then Q <= D12; end if; end if; end process;
80
Table 3-11. VHDL Design Style Restrictions (cont.) Nested blocks with the same clock/edge Nested multiple clocked blocks that use the same clock signal and the same edge (i.e., posedge or negedge) are supported. For example:
multiEnableEdgeProc : process(clk, reset) begin if reset = 1 and rising_edge(clk) then if reset = 1 then Q <= 0; elsif rising_edge(clk) then Q <= D12; end if; end if; end process;
Clock Expressions in Procedures
The use of a clock_expression in a procedure is supported only if the procedure that contains the clock_expression is: Called directly as a concurrent procedure call (calling the procedure from another concurrent procedure is not supported). Not called in a sequential scope (for example as a statement inside a process statement). Not a recursive procedure. Implicit FSMs Implicit style finite state machines written using multiple wait statements are not supported. Using a single wait statement with a valid clocking style (as per the LRM) is supported. Non-static loops using wait statements Non-static loops with single-clock wait (usually written as implicit style state machines using wait statements) are not supported. For example:
UartTxFunction : Process begin TopLoop : loop wait until rising_edge(clk); Q <= D; end loop ; end process ;
wait Statements
81
Table 3-11. VHDL Design Style Restrictions (cont.) The following non-static loop with complex conditions is not supported:
UartTxFunction : Process begin TopLoop : loop if (nReset = 0) then SerialDataOut <= 1 ; TxRdyReg <= 1 ; end if ; wait until nReset = 0 or (rising_edge(UartTxClk) and DataRdy=1); next TopLoop when nReset = 0 ; SerialDataOut <= 0; TxRdyReg <= 0; -- Send 8 Data Bits for i in 0 to 7 loop wait until nReset = 0 or rising_edge(UartTxClk); next TopLoop when nReset = 0; SerialDataOut <= DataReg(i) ; TxRdyReg <= 0 ; end loop ; wait until nReset = 0 or rising_edge(UartTxClk) ; next TopLoop when nReset = 0; SerialDataOut <= 1 ; TxRdyReg <= 1 ; end loop ; end process ;
Selects Verilog Configuration
Selects such as sig(a to b) and sig(a downto b) are only supported if a and b expressions are constant at elaboration time. Entity/architecture bindings for instances across language boundaries are not supported. For example: VHDL specifying the configuration for a Verilog instance or a VHDL design unit instantiated in the Verilog part of the design. User-defined resolution functions (i.e., to resolve final values of the signals in case of multiple drivers) are ignored. The standard resolution function applied on the standard data type (std_logic) as defined in the IEEE package is supported. Direct Z assignment Tristate logic modeling through direct Z assignment on process variables and inside subprograms is not supported. Tri-states modeled through direct Z assignments in concurrent signal assignments or in processes on signals are supported.
User-defined Resolution Functions
Tristate Modeling
82
Table 3-11. VHDL Design Style Restrictions (cont.) Guard disconnect Tristate logic modeling using guard disconnect on std_logic type signals declared as bus/registers is not supported. For example:
signal dout: Std_Logic bus;-- "bus" yields 3-state; signal flag: Std_Logic; tri_state: block (en = 1) begin dout <= guarded din; flag <= en; end block;
RAM/ROM Modeling
RAM/ROM modeling and inferencing is optimized for the 0-In tools and has better results for the tool usage and characteristics of the design. The modeling process ignores some attributes provided in the IEEE rtl_attributes package, including the following: Ram_block Rom_block Logic_block Certain other pre-defined attributes. For example, the following attributes are ignored:
variable ram : ram_typ; -- ram element attribute logic_block of ram : variable is TRUE;
VHDL Library Override
Except for IEEE standard packages, VHDL libraries can be overridden. Overrides of IEEE standard packages are ignored because the 0-In native IEEE packages are optimized to improve compiler performance. Support for attaching 0-In checker directives to VHDL statements and objects is shown in Table 3-10 on page 75.
CheckerWare Directives
83
Binding to Verilog Design Units

VHDL names are case insensitive. They are stored in the design and resource libraries in lowercase. Verilog names are case sensitive. They are stored exactly as specified. Ambiguity can occur when binding to a Verilog design unit from VHDL. Here is the procedure used to select a design unit from a library: 1. If a design unit exists in the library that has the same name in all lower case, use that design unit. 2. Otherwise, find all design units in the library that have the same case-insensitive name. If only one design unit matches, use that design unit. If none or multiple design units match, do not use any design unit.
For example, assume VHDL code binds to a design unit named Test.
work: entity test, module Test
Design unit Test matches entity test (in all lower case). Entity test is used.
work: module TEST
No design unit is named test (in all lower case). So, the library is searched ignoring case, which finds the single match TEST. Module TEST is used.
work: module Test, module TEST
No design unit is named test (in all lower case). So, the library is searched ignoring case, which finds the multiple matches: Test and TEST. No design unit is used.
84
0-In Directives Restrictions

Expressions in 0-In checker and global directives have the following restrictions: Expressions in Verilog control file directives must use Verilog syntax. Expressions in VHDL control file directives must use VHDL syntax. In particular, hierarchical references are not supported in VHDL control files. Directives with -module arguments cannot use local signals/variables (of the control module). Data in quotes must use type qualifiers. For example:
--0in < value -val "000000000000000001" => warning, --0in < value -val b"000000000000000001" => OK --0in < value -val "true" => warning, --0in < value -val boolean(true) => OK
directive skipped
directive skipped
VHDL expressions in directives must be unambiguous. For example, others in aggregates must use type qualifiers:
package pack is type T_1_D_STRAIGHT is array (3 downto 1) of std_logic; type T_2_D_CASCADE is array (2 downto 1) of T_1_D_STRAIGHT; type T_3_D_CASCADE is array (2 downto 1) of T_2_D_CASCADE; type T_3_D_STRAIGHT is array (2 downto 1, 2 downto 1, 3 downto 1) of std_logic; end; entity e is port(a : T_3_D_STRAIGHT; b : out T_3_D_STRAIGHT); end; architecture arch1 of test is signal c : T_3_D_STRAIGHT; begin -- 0in custom -fire -(a = T_3_D_CASCADE(others =>(others =>(1, 0, 1)))) --clock clk -name a_all_1_0_1 end arch1
85
86
Chapter 4 CDC Analysis

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

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

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

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

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

Menus Toolbar Debugging Windows
Design Data Windows
Analysis Windows
Table 4-1. CDC GUI Debug Tools CDC Checks Window
Shows the results of CDC compilation and analysis. Each CDC scheme instance has a status flag (page 53) that indicates the status for the CDC instance. Right-click on a scheme instance to pop up commands for displaying various debug windows for inspecting the crossing. Also shows results merged from simulation and formal verification sessions.
89
Table 4-1. CDC GUI Debug Tools (cont.) Schematics Viewer
Shows hierarchical schematics for the design. To display the schematics viewer showing the logic of a CDC instance, right-click on the CDC instance and run a Show >Schematic command. Source Code Editor
Provides a dynamic view of the design source code for browsing. Code is tightly linked to the GUI objects, which helps navigate the source code. For example, right-click on various window objects to show in a source code editor: an objects declaration, an objects instantiation, an erroneous construct flagged in the source code, and other types of constructs flagged in the source code. The source code editor is also linked to the waveform viewer. As you move the main cursor in the waveform window, the associated values from the waveform are annotated to the variables in the source code.
90
Table 4-1. CDC GUI Debug Tools (cont.) Waveform Viewer
Shows waveforms found by simulation with CDC protocol assertions and CDC-FX metastability checkers. Only available for databases merged from simulation sessions. To display a waveform, right-click on a CDC instance and run Show >Simulation Firings.
0in_cdc: GUI Project Mode

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

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

Static CDC verification identifies the CDC signal paths and their associated CDC schemes. Schemes are ranked by severity, which can be the default severity of the scheme or a userspecified severity. Typically, several cycles are spent adjusting the scheme identification attributes and protocol promotion settings. Once you have properly configured static CDC verification, you can enable the formal CDC analysis engine for a session. This step identifies schemes with CDC protocols that can be proven to be logically valid (and therefore do not require the promotion of their CDC protocol checkers). Static CDC verification of a DUT is a multi-phased process: 1. Compile the design. 2. Analyze clock domains. 3. Compile the CDC logic. 4. Run GUI debug. The following sections describe this flow.
92
Phase 1. Compiling the Design

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

prompt> vlib work
3. Name the working library.

prompt> vmap work work Copying /u/0in_3.0/modeltech/linux/../modelsim.ini to modelsim.ini Modifying modelsim.ini
Note that a copy of the system modelsim.ini file (page 58) is copied to the run directory and the local copy is modified to match the arguments of the vmap command. 4. Compile the design files. Use vcom to compile the VHDL files and vlog to compile the Verilog/SystemVerilog files. For example:
prompt> vcom -f pci.f prompt> vlog dut.v
Check the warnings/errors messages and resolve any problems. To see more information about a message use the verror command.
prompt> verror -full 2155 MSG_IDX_GLBL_VARS_IN_VERILOG Global declarations are illegal in Verilog 2001 syntax. Global declarations are only legal in SystemVerilog. To enable SystemVerilog you can either use the -sv vlog command line switch or give the source file a .sv extension.
Phase 2: Analyzing Clock Domains

Once the design is compiled, you should identify (and verify) the clock domains before running a full cdc session to compile and analyze the CDC logic. You do this by creating a control file of global directives that configure CDC analysis and identify the various clocks and clock domains. Then, you run cdc in a special operational mode called report clocks, which scans the design data and reports clock domain information.
93
1. Set up global directives. Create one or more control files containing global directives used to configure the CDC analysis (see Global Directives on page 254). Following are some examples: Identify clocks characteristics (including which clocks belong to the same clock groups). See set_cdc_clock on page 263. Override the default clock groups assigned to DUT or instance ports. See set_cdc_port_domain on page 276. Identify modules/architectures that should be treated as black boxes for CDC analysis. See set_black_box on page 262. Identify signals that should be considered constant for CDC analysis. See set_constant on page 305. Identify large memories that are modeled as single sequential elements for CDC analysis. See set_memory on page 308. Set the preferences for static CDC analysis. See set_cdc_preference on page 283. Set severities and promotion properties for CDC scheme types and groups of schemes. See set_cdc_report on page 293. Override the classification of various signals and assign them certain CDC properties. See set_cdc_signal on page 299.
Example control file for CDC analysis:

module // 0in // 0in /* 0in ctrl; set_cdc_reconvergence -depth 10 -divergence_depth 1 set_cdc_preference -promote_reconvergence set_cdc_report -scheme series_redundant -severity off -from *_en -tx_clock tx_clk */ // 0in set_clock cpu_clk -period 50 // 0in set_clock core_clk -period 20 // 0in set_clock mac_clk -period 12 endmodule
2. Run report clocks. Run cdc with the -report_clock option. For example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v -report_clock
If you use the 1-step method of compiling the design, add the 1-step compilation arguments to the cdc command (as detailed in 1-Step Compilation on page 56). For example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v -report_clock \ -f design.f +define+mode=initialized -y ../mylib
94
3. Check for errors and warnings. Check the log file (0in_detail.log) for errors and warnings. The Error/Warning Summary table gives the violation count of each type of error/warning.
Error/Warning Summary ----------------------------------------------------------Count Type Message ID Summary ----------------------------------------------------------1 Warning hdl-136 Clock not found in directive. 1 Warning hdl-222 Possible dead end CDC paths not reported. 3 Warning hdl-41 Primary port connects to multiple clock domains. 25 Warning hdl-51 Port domain assignment inferred. Summary: 30 Warnings in cdc
The detailed error/warning messages are in the body of the log.

prompt> egrep Error|Warning 0in_detail.log Warning : Possible dead end CDC paths not reported. [hdl-222] Warning : Clock not found in directive. Directive set_cdc_report, Module demo_top, Clock tx_clk, File cdc_control.v, Line 5. [hdl-136] Warning : Port domain assignment inferred. Port mac_clk_in, File top.v, Line 31. [hdl-51] Warning : Port domain assignment inferred. Port core_clk_in, File top.v, Line 31. [hdl-51] . . . Warning : Port domain assignment inferred. Port rx_check, File top.v, Line 57. [hdl-51] Warning : Primary port connects to multiple clock domains. Pin rst. [hdl-41] Warning : Primary port connects to multiple clock domains. Pin scan_mode. [hdl-41] Warning : Primary port connects to multiple clock domains. Pin scan_clk. [hdl-41]
4. Check clock domain data. Check 0in_cdc_design.rpt (see CDC Design Report on page 446). This report shows information reported by cdc -report_clock such as identified clocks, clock groups and port domain mappings. CDC static analysis resource requirements increase with the number of CDC signals identified in the design. Unconfigured CDC analysis can identify more CDC signals than the design actually has (for example because automatic clock grouping identifies more than the actual number of clock domains). To improve performance, review and refine the clock trees to achieve the correct grouping. The following clock data should be accurate after this phase of CDC analysis: Clocks are identified correctly clocks not needed for CDC analysis can be removed from the clock list. Clock groups are identified correctly clocks can be added and removed from the different clock groups.
95
Ports are assigned to the correct clock domains clock domains of DUT ports are inferred, but you can override these assignments. Clock domains of black-box outputs must be identified. CDC signals are classified correctly the type of each CDC signal is inferred, but you can override these assignments. The CDC signal classification determines which synchronization schemes are valid for the signals. For example, a data bus can use a control signal synchronization scheme if it is grey-coded and a CDC signal that is known to be stable does not require synchronization. Custom synchronizers must be manually identified so CDC analysis can ignore the signals synchronized by them.
Phase 3: Compiling CDC Logic

Once the design is compiled and the clock domains are verified, use the cdc command to compile the CDC logic. This command also performs CDC analysis and generates the database (.db) file read by the 0in_cdc GUI debug tool. If you modify the source or control files, or adjust the CDC compilation options, you must re-run CDC compilation. 1. Run the CDC analyzer. Run cdc. For example:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v options
If you use the 1-step method of compiling the design, add the 1-step compilation arguments to the cdc command (as detailed in 1-Step Compilation on page 56). For example:
prompt> 0in -cmd csl -d dut -ctrl ctrl.v options\ -f design.f +define+mode=initialized -y ../mylib
2. Check for errors and warnings. Check the log file (0in_detail.log) for errors and warnings. The Error/Warning Summary table gives the violation count of each type of error/warning.
Phase 4: Running GUI Debug

The cdc command generates a 0in database file (0in_cdc.db) for input to the CDC GUI. 1. Run the CDC GUI in debug mode. Specify 0in_cdc.db as the only argument to 0in_cdc:
The CDC GUI main window is displayed.
96
2. Check static CDC analysis results. Results are shown in the CDC Checks window. Each entry represents a CDC path (scheme instance) detected by CDC static analysis. The Type field has a CDC status flag (see page 53) representing the status of the scheme. To help organize the data, the schemes are grouped by basic type (Violation, Caution, Evaluation, Proven, etc.) and within each of these groups, the schemes are grouped by scheme type (Two DFF Synchronizer, Combo Logic, etc.).
97
For an initial static CDC session, the basic types are: Violation The path is not an instance of valid CDC scheme. To remove this violation, either the logic must be changed or the violation must be waived (for example, when the CDC circuit is known to be valid). Caution The path is an instance of a CDC scheme that might or might not be valid. The CDC interface protocol can possibly be violated. A protocol checker should be used to check the interface logic. If the scheme type promotes protocol checkers, one is automatically created (unless promotion is specifically turned off for the scheme). Evaluation The path is an instance of a valid scheme for the CDC signal. Proven The path is an instance of a valid scheme for the CDC signal and the CDC interface protocol cannot be violated.
Typically static CDC verification results show proven schemes even when the CDC formal engine is not enabled. For these schemes, the clock ratio of TX/RX clock periods is < 2 (i.e., the path goes from a domain with a slow clock to one with a fast clock). 3. Fix violations. Carefully examine the violations. To debug a violation, view the schematic (select the scheme and run Show >Schematic) and view the source code for the violation (run Show >Source). You must rerun static CDC verification if you change the HDL source.
98
4. Adjust static CDC analysis attributes as needed. You typically need to adjust the CDC attributes. For example, to change the severity of a scheme, select the scheme and run Create Directive. The Set Cdc Report dialog shows the current data for the scheme. Below, the severity is changed to Waived. You might want to waive a scheme because it is known to be valid, it is not interesting at this point, or it will be fixed by a future enhancement.
Sometimes a path is identified with an incorrect synchronizer scheme. For example, a gray-coded bus is marked as a violation, but has a valid synchronizer, or a missing synchronizer is reported, but the clock domain crossing is known to be stable, so no synchronizer is needed. To fix this, set the signal properties of the signal. In a schematic or the objects pane, select the signal and run Edit Directive >Set Signal. Adjust the signal attributes in the Set Cdc Signal dialog.
99
Check the modifications in the directives tab.
Save the current directives as a control file. File >Export >Directive File. 5. Filter the reporting of static CDC results as needed. In the previous step, you adjusted how the CDC compiler analyzed specific CDC schemes. Filtering is the process of selecting CDC crossings not to display in the results pane. Filtered crossings are still analyzed by the CDC compilerbut they are not displayed in the CDC Checks window. To control the filtering process, select an individual CDC crossing or group of CDC crossings. Running a Filter >Selected popup command displays the Filter CDC Checks dialog. This dialog appears with the currently-filtered items along with the specified CDC crossing or group. Which specified crossing or group, is determined by the selection and the particular Filter command used.
Adjust the crossings selected for filtering using this form. Click on OK to accept the current filtering. This removes the crossings from the results pane. To un-filter a crossing entry, select any result and run Filter >By Column, which displays the Filter CDC Checks dialog again. Select the crossing you want to restore and then use the Delete (or Modify) button. You can save the current filtering settings using the Filter >Export popup command and restore filtering settings from a saved file using the Filter >Import popup command. This way, you can organize different groups of CDC issues to help you filter out extraneous information as you focus on particular hot spots in your CDC analysis.
100
Filtering can be a valuable tool for implementing targeting strategies in your CDC analysis methodology. Save the current filtering directives as a control file. Filter >Export Directive File. The global directives in this filters file have the form:
//0in set_cdc_report -scheme scheme ... -severity off
The -severity off option marks the crossing as a filtered CDC instance. 6. Exit the CDC GUI. File >Quit 7. Re-run CDC compilation/analysis. Re-run cdc with the two new control files. The ctrl_waived.v file is the control file saved in step 4. The ctrl_filtered.v file is the control file saved in step 5.
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v options -ctrl ctrl_waived.v -ctrl ctrl_filtered.v -formal
The above invocation includes the -formal option, which turns on low-level formal analysis of the promoted CDC protocol assertions. 8. Check static CDC analysis results.
Results are shown in the CDC Checks window. At this point problems should be fixed, but some violations might still be flagged. For example, a scheme might have severity violation, but its CDC transfer protocol is expected to be valid.
101
Since some schemes are marked with waived severity, the Type field has a new group of entries: Waived The schemes severity is manually set to waived.
Schemes with protocols that formal CDC proves are valid are shown with proven status (even waived schemes). 9. Create additional CDC attribute profiles to address specific issues. The default tuning of the CDC attributes provides a balance between performance and the effort spent to provide a high level of detail. You can adjust the exact balance by specifying a CDC attribute profile targeted to specific needs. For example, the following control file creates a profile that has the minimum compute time and memory consumption. This profile is useful for very large designs, especially when working iteratively to fine-tune results at early stages of verification.
// ctrl_high_performance.v // // High-performance CDC profile module ctrl_high_performance; // Turn off reconvergence checking. // 0in set_cdc_reconvergence -check off // Turn off exact memory modeling for large memories. // 0in set_memory -abstract mem1 -abstract mem2 // Disable generation of CDC protocol assertions // 0in set_cdc_report -default_promotion off // // // /* Define custom synchronizer modules and identify the clock domains of the custom synchronizer module pins. 0in set_cdc_synchronizer custom -module cust_2sync 0in set_cdc_port_domain in1 out2 -clock clk1 -module cust_2sync */ /* 0in set_cdc_port_domain in2 out1 -clock clk2 -module cust_2sync */ // Black-box modules that are not required for CDC analysis // 0in set_black_box modX endmodule // ctrl_high_performance
For extremely large designs, use a hierarchical CDC verification flow (see Hierarchical CDC Analysis on page 118).
102
The following example control file creates a profile that provides a higher level of detail in the checking and reporting of CDC data.
// ctrl_high_accuracy.v // // High-accuracy CDC profile module ctrl_high_accuracy; // Enable divergence checking and set reconvergence checking to // a greater depth (default is 0). Start with a depth of 1. // 0in set_cdc_reconvergence -divergence_depth 1 -depth 1 // Enable reconvergence reporting for paths thru // DMUX synchronizers. // 0in set_cdc_preference -dmux_as_recon_start // Enable FIFO and handshake scheme checking: // 0in set_cdc_preference -fifo_scheme -handshake_scheme // Report disabled CDC paths. // 0in set_cdc_preference -filtered_report // Enable constant propagation through sequential elements. // 0in set_constant_propagation -latch endmodule // ctrl_high_accuracy
Also, consider the following: Define all clock periods using set_cdc_clock and turn on formal CDC analysis with the cdc command-line switch -formal. Start with the default -formal_effort (low). Turn on reporting of patch to dead-end nodes using the cdc command-line switch -process_dead_end. Use modal analysis to check all modes of clocking (see Modal CDC Analysis on page 133).
103
CDC Analysis Dynamic CDC Verification Flow
Dynamic CDC Verification Flow

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

During static CDC verification, the formal CDC engine proved the CDC protocols are valid for some schemes with basic protocols. But, the CDC transfer protocols for caution schemes must be verified explicitly. Some scheme types have general characteristics that are readily verified by checkers in the 0-In CDC assertion library (Table 4-3). To test and verify the protocols for these schemes, static CDC analysis promotes protocol checkers for CDC protocol analysis. The promoted checkers are written to the 0in_cdc_control.v control file by default during static CDC analysis. The CDC checkers are modules that ensure that data crossing clock domain boundaries are transmitted and received correctly. The CDC checkers are implemented the same as other CheckerWare checkers. They monitor the design during assertions in simulation. Their checks can be targets for formal verification. They are instantiated directly by using checker directives. Checker Type cdc_sync cdc_sample Table 4-3. CDC Protocol Checkers Protocol Ensures that a clock domain crossing signal from a faster clock to a slower clock is held stable long enough for the signal to be sampled reliably by the receiver. Ensures that receive data between two clock domains remain stable in the transmit domain for one receive clock cycle before and one receive clock cycle after it is sampled in the receive domain. The receive domain samples at least twice for each transmit signal so that the correct value is sampled. Ensures that a signal between two clock domains, where the transmitters data select signal drives the select input of a data multiplexer in the receiver, is held stable enough for the signal to be sampled reliably by the receiver and ensures that the data remains stable while the data select signal asserts. Ensures that the handshaking protocol between transmitter and receiver is correctly followed, and ensures that the transmit data remains stable in the data transfer window.
cdc_dsel
cdc_handshake_data
104
Table 4-3. CDC Protocol Checkers Checker Type Protocol cdc_hamming_distance_one Ensures that the data crossing from transmit clock to receive clock domain changes by only one hamming distance and that it remains stable for a specified tx_min clock cycles. cdc_fifo Ensures that the write and read pointers of an asynchronous FIFO change by hamming distance one, and ensures that the FIFO does not overflow or underflow. cdc_glitch Ensures that a specified register does not have a glitch in its input. Using the generated promoted CDC checker control file, you analyze the CDC transfer protocols in either or both of the following ways: Run formal verification with the promoted CDC protocol checkers. Run simulation with the promoted CDC protocol checkers.
Checkers for the protocols verified by the formal CDC engine are not promoted, so formal analysis and simulation do not waste cycles analyzing pre-verified protocols. Standard 0-In CDC checkers can be manually added for cases where the schemes protocols match the protocols verified by the checkers. Custom assertions checkers can be created for other situations. Simulation and formal results for these checkers are not imported back into the CDC GUI, so problems must be debugged in those environments. CDC-FX metastability analysis also uncovers issues with protocols with inconclusive results.
0-In Formal Verification

This step is optional and requires significant setup for formal analysis (such as adding an initialization sequence and formal check assumptions). 0-In Prove formal verification analyzes the promoted CDC protocol checkers and identifies those protocols that it proves cannot be violated. The results of the formal analysis are then merged with the results of static CDC verification to show the progress of analyzing the CDC protocols. 1. Check the control file of promoted CDC protocol checkers. Examine 0in_cdc_ctrl.v in the directory containing the results of static CDC analysis. Check the contents of the control file. If you make adjustments, save the file to a different name to prevent the changes from being overwritten the next time you run static CDC analysis. 2. Run formal verification. Set up a run script for formal verification with the promoted control file. For example, the following Makefile entry runs the 0-In csl formal model compiler and then 0in_prove.
105
CDC Analysis Dynamic CDC Verification Flow run_prove: 0in -od prove -cmd csl -f $(EX_HOME)/source/filelist \ -d demo_top -ctrl $(EX_HOME)/bin/csl_control.v \ -ctrl $(EX_HOME)/static/0in_cdc_ctrl.v 0in_prove +0in_od+prove +0in_dir+prove/0in_cache \ +0in_init+$(EX_HOME)/bin/init.txt +0in_effort+med prompt> make run_prove
Check the Prove logs and reports for errors. 3. Run the CDC GUI in debug mode. Load the database from static CDC verification (0in_cdc.db) and merge the database from formal analysis (0in_prove.db).
prompt> 0in_cdc 0in_cdc.db -mergedb 0in_prove.db
4. Check results of Prove formal analysis of the CDC protocols. Two new columns of status flags are added. The Static field shows the status of the schemes from static CDC analysis. The Prove field shows the results of Prove formal verification. The Type field shows the merged statuses for the schemes.
The Prove field has three types of status flags: Proven The schemes protocol checker was promoted and Prove formal verification proved the schemes CDC interface protocol cannot be violated. Inconclusive The schemes protocol checker was promoted and Prove formal verification failed to prove the schemes CDC interface protocol cannot be violated. Sometimes increasing the formal effort level can reduce the number of inconclusive results.
106
Not Promoted No protocol checker was promoted for the scheme. Checkers are not promoted for proven schemes, some scheme types that do not support checker promotion and schemes that have promotion manually disabled.
Simulation with CDC Protocol Assertions

Once your test environment is set up to run simulations, you can add assertions for the promoted CDC protocol checkers to the compiled DUT logic. The -compile_assertions option to the cdc command compiles the assertions and sets up the arguments needed to run simulation with the protocol checkers (and FX checkers if enabled), as shown in Figure 4-4. Figure 4-4. Simulation with CDC Assertions
vcom/vlog design les
cdc -compile_assertions control les -f 0in_cdc_sim.arg -f 0in_cdc_sim_vhdl.arg vcom/vlog
-work library vsim
merge 0in_checksim.db 0in_cdc GUI
0in_cdc.db
vcom/vlog testbench les
debugging environment
Results from these simulations with CDC protocol assertions can be merged back into the CDC GUI for review and debugging. The following procedure uses the Questa vsim simulator. 1. Set up the design library and compile the design. For example:
prompt> vlib work prompt> vmap work work prompt> vcom dut.vhdl
2. Run CDC analysis. Specify the -compile_assertions option and the prefix showing the hierarchy path from the top level testbench to the DUT analyzed by cdc. For example:
prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v \ -compile_assertions -prefix tb.dut_inst
107
3. Compile the protocol assertions. Specify the simulation arguments files generated by cdc. For example:
prompt> vlog -f 0in_cdc_sim.arg prompt> vcom -f 0in_cdc_sim_vhdl.arg
4. Compile the testbench.

prompt> vlog tb.v
5. Run simulation. Specify the PLI library path for the simulator and the vsim arguments files. For example:
prompt> vsim -c tb -pli $HOME_0IN/lib/lib0InLoadMTIPLI.so \ -f 0in_cdc_sim.arg.vsim -f 0in_cdc_sim.arg.vsimrun \ -do "add log -r /*; run 1000; quit -f"
6. Run the CDC GUI. Load the 0in_cdc.db database generated by cdc and merge the 0in_checksim.db database generated by vsim.
prompt> 0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
7. Check results of simulation with the CDC protocol assertions. One new column of status flags and four new columns of simulation results are added. The Simulation field shows the status of the schemes from simulation. The Type field shows the merged statuses for the schemes. The Simulation field has five types of status flags: Firing Simulation violated the schemes protocol. The Firings field shows the number of firings (number of times the protocol was violated) and First Firing shows the testbench time of the first violation. Unevaluated Simulation never activated the schemes protocol assertion. Evaluated Simulation activated the schemes protocol assertion. The Evaluations field shows the number of cycles the protocol assertion activated. Covered Simulation covered all of the schemes protocol assertions cover points. Not Promoted No protocol checker was promoted for the scheme. Checkers are not promoted for proven schemes, some scheme types that do not support checker promotion and schemes that have promotion manually disabled.
Schemes with violation severity are promoted. Similarly, protocol assertions that are activated in simulation (Evaluated) might not be covered in simulation. So, two additional status flags are possible in the merged status (Type field):
108
Violation and Firing Scheme is a violation and the schemes protocol was violated during simulation. Not Covered Simulation activated the schemes protocol assertion, but simulation did not exercise all the assertions cover points.
8. Debug protocol assertion firings. Select the scheme and run Show >Simulation Firings. From the Firings dialog, select the desired firing. In the Load Waveform Database dialog, find the generated waveform file.
109
Use the waveform view, the schematic view and the source code editor to track down and fix the source of the firings.
110
9. Check CDC assertions that are not covered. Check results that are Not Covered. Select a crossing and run the Show >Protocol Checker popup command. The Checksim window is displayed with the entry for the selected protocol checker highlighted.
Typically, you modify simulation or run CDC protocol checking with additional tests to ensure complete coverage of the relevant CDC protocol assertions.
CDC-FX Metastability Analysis

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

1. If needed set up global directives for setting metastability windows. The following control module shows a control file that sets the FX timescale and metastability windows (see Metastability Windows on page 160) for wr_clk-to-rd_clk crossings and rd_clk-to-wr_clk crossings.
prompt> more fx_ctrl.v module fx_ctrl; // 0in set_cdc_fx_timescale 1ps/1ps /* 0in set_cdc_fx_metastability_window -start 5000 -stop 1000 -rx_clock wr_clk -tx_clock rd_clk */ /* 0in set_cdc_fx_metastability_window -start 6000 -stop 1000 -rx_clock rd_clk -tx_clock wr_clk */ endmodule
2. Compile and analyze the design. The same setup used for simulation with CDC protocol assertions can be adapted for CDC-FX simulationwith two modifications to the cdc invocation: Add the -fx argument, which generates the CDC-FX metastability injection logic. Add the control file containing the CDC-FX directives.
For example:
prompt> vlib work prompt> vmap work work prompt> vcom dut.v prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v fx -ctrl fx_ctrl.v\ -compile_assertions -prefix tb.dut_inst prompt> vlog -f 0in_cdc_sim.arg prompt> vcom -f 0in_cdc_sim_vhdl.arg prompt> vlog tb.v
3. Run simulation. For example:

Debug issues in the simulator debug environment as with standard simulations.
112
4. Check CDCFX checkers that are not covered. Load the results of simulation with CDC-FX checkers into the CDC GUI:
Check results that are Not Covered in the Checksim window.
Select a crossing and run Show >Coverage.
In this example, the All Bits Metastable cover points show only 11 out of 32 bits are tested with metastability injection. Typically, you modify simulation or run additional tests to ensure complete coverage of the CDC-FX checkers.
Simulation Arguments
Table 4-4 shows additional arguments you can include in your simulator invocation when you run simulation with CDC protocol checkers and CDC-FX checkers. Table 4-4. Simulator Arguments simulator_cmd simulator_args f sim_arg_file [+0in_no_checksim_db] [+0in_checker_finish_delay+time] [+define+prefix_0in=prefix] [+0in_db+file] [+0in_firing_limit+limit] [+0in_signature_limit+limit] [+0in_no_violation_limit] [+0in_firing_keyword+keyword] [+0in_licq] [+0in_od+output_dir] [+0in_no_statistics] [+0in_covered_report[+file]] [+0in_simulation_message_limit+limit] [+0in_no_simulation_messages] [version] [+0in_suppress_fx_name{+name}] [+0in_disable_fx_force] [+0in_random_seed+n]
113
Table 4-4. Simulator Arguments simulator simulator_args f sim_arg_file +0in_no_checksim_db +0in_checker_finish_delay +time +define+prefix_0in=prefix +0in_db+file +0in_firing_limit+limit +0in_signature_limit+limit +0in_no_violation_limit +0in_firing_keyword +keyword +0in_licq +0in_od+output_dir +0in_no_statistics +0in_covered_report[+file] +0in_simulation_message_ limit+limit +0in_no_simulation_ messages version +0in_suppress_fx_name {+name} +0in_disable_fx_force +0in_random_seed+n
114
Simulator invocation for the design and testbench, including HDL simulator arguments. File (generated by ccl or csl) with the simulator arguments for running simulation with assertions Turns off generation of the viewer database created by simulation with assertions. Default: 0in_checksim.db. Number of time units to continue simulation with assertions before exiting after a firing (in response to a set_checker_action finish directive). Default: 10 time units. Changes the hierarchy prefix if needed for the target design specified using the d option in ccl/csl. Name of the generated viewer database. Default: 0in_tool.db (tool = prove | confirm). Maximum number of firings in the viewer database. Default: 10. Maximum number of signatures per check in the viewer database. Default: 10. Removes the limits on firings per signature and signatures per check in the viewer database. Adds keyword to each firing message, so each firing message begins with: 0-In keyword Firing Default: Each firing message begins with: 0-In Firing. Enables license queuing. Default: tools terminate if required licenses are in use. Directory to store all output files. Default: current directory. Turns off statistics computation and reporting during simulation. Generates a structural coverage report. Default file name: 0in_covered.rpt. Number of firings per signature reported to the simulation log and STDOUT. Default: 1. Turns off reporting checker firing messages to the simulation log and STDOUT. Reports the software release version and copyright information and exits. Suppresses CDC-FX metastability injection for the specified registers. Suppresses CDC-FX metastability injection for all registers. Sets the seed for random metastability injection.
Compiling with ccl for Simulation

The -compile_assertions option configures the setup for simulation with CDC and CDC-FX checkers. For some situations, you need to run the ccl compiler instead to do this. Table 4-5 shows syntax for this 0in shell command. Table 4-5. ccl Syntax ccl [fastsim [turbo]] [fastmod [module]] [race_avoid] [incr] [incremental_firing_db] [ac_stats] [cuname comp_unit] [psl] [pslfile_vl verilog_vunit_file] [pslfile_vh vhdl_vunit_file][ovl] [ovl_cover] [sim {questa | mti | vcs | nc | nc3}] [full] [rel_paths] [prove_checkers] [use_synthesis_case_directives] [rcd] [rcd_file file] [rcd_level level] [sif simulation_arg_file] [unique_names] [exit_on_directive_errors] [verilog_options] [vhdl_options] [rtl_options] [reporting_options] [compile_options] fastsim [turbo] Creates checker logic without structural coverage logic, so simulation with assertions runs in high performance mode. The turbo option optimizes the checker logic further to increase simulation performance. Default: checker logic includes structural coverage logic, which decreases simulation performance. Creates checker logic with checkers moved up to the specified module, connected with collapsed nets. The top module is used if module is unspecified. This option can further increase simulation performance. Default: checkers are instantiated in their defining modules. Avoids race conditions during simulation. However, using this option can slow down simulation. Generates checker logic files incrementally, which can improve compile time by preventing recompilation of unchanged checker files. Default: generates all checker files Directs simulation with assertions to create a smaller viewer database with static data saved in 0in_cache. Default: simulation with assertions creates a full viewer database with static and dynamic data. Generates an assertion complexity report in 0in.log and 0in_detail.log. Root scope compilation unit name. Creates psl checkers from embedded PSL code. Compiles PSL assertions (for Verilog modules) specified in vunits in verilog_vunit_file.
fastmod [module]
race_avoid incr
incremental_firing_db
ac_stats cuname comp_unit psl pslfile_vl verilog_vunit_file
115
Table 4-5. ccl Syntax pslfile_vh vhdl_vunit_file ovl ovl_cover Compiles PSL assertions (for VHDL entities) specified in vunits in vhdl_vunit_file. Compiles the 0-In version of the OVL assertions. Compiles the 0-In version of the OVL assertions with coverage.
sim Default simulator: Questa, MTI, VCS, NC-Verilog, or 3-step {questa | mti | vcs | nc | nc3} NC-Verilog. Default: MTI. The default MTI version is the same as the vsim executable in the current search path. full rel_paths prove_checkers use_synthesis_case_ directives rcd Ignores previously cached files. Default: use cached files. Uses relative pathnames in generated argument files. Default: same as 0in shell. Tries to prove checkers unfireable and then excludes unfireable checkers from simulation to improve simulation performance. Creates case checkers for synthesis case directives embedded in the source code. Same as specifying the use_synthesis_case_directives global directive with no options. Turns on generation of a checker density report and MSD report (0in_density_msd.rpt). Default: off. Unless specified by rcd_file, the checker density report name is 0in_density.rpt. Turns on generation of a checker density report and renames the generated checker density report. Default: 0in_density.rpt (if rcd specified) otherwise, no report is created. Number of hierarchical levels below the target design instance that are included in the report. A value of 0 specifies all levels. Default: 4 levels. Name of the root of the generated simulation arguments files. Default: root file name is 0in_sim.arg. Checks directives for unique names. Only user provided names specified using the unique_names option are checked. Exits if any checker directive errors are found (after all checkers have been generated). [f filelist] [v95] [+incdir{+include_dir}] [y library_dir][ v library_file] [+libext{+extension}] [+define{+macro[=value}] [oy search_path] [work work_library] [93 | 87 | 2002] [libmap name=value] [libmapfile file] [read_questa_mapping] [read_cds_mapping]
rcd_file file
rcd_level level
sif simulation_arg_file unique_names exit_on_directive_errors verilog_options
vhdl_options
116
Table 4-5. ccl Syntax rtl_options [+skip_modules {+module}] [+skip_syscalls {+systemcall}] [skip_protected_modules] [skip_protected_code] [ignore_translate_off] [wd working_directory][+nowarn{+messageID}] [+error{+messageID} [file] [d design] [prefix hierarchy_prefix] [ctrl checker_control_file] [ctrl_list checker_ctrl_file []] [vhctrl vhdl_control_file] [G name=value] [g name=value] [cr report_file]
reporting_options compile_options
117
CDC Analysis Hierarchical CDC Analysis
Hierarchical CDC Analysis

Hierarchical CDC analysis is a methodology that runs CDC static analysis sessions with less memory. It is the only feasible methodology for analyzing some complex, large designs with many clock domain crossings. The hierarchical CDC flow is a bottom-up flow that analyzes selected lower-level blocks individually to resolve CDC problems and then analyzes the toplevel design to resolve inter-block and top-level issues (Figure 4-5). Figure 4-5. Hierarchical CDC Flow
top-level design ILM
top-level violation
V
ILM CDC interface logic model of a block
ILM
top-level violation
V
ILM
ILM 2. Analyze top-level design. Debug inter-block and top-level issues.
inter-block violation
V
ILM
ILM
ILM
block 1. Analyze selected blocks individually. Debug intra-block issues. Generate interface logic model (ILM) for the block.
intra-block violation
V
V
V
Note Hierarchical CDC analysis is static analysis only and does not support promotion of protocol checks or generation of CDC-FX injectors. Before running hierarchical CDC, set up the design for CDC analysis as you would for flat CDC analysis. 1. Compile the source files.
118
2. Set up a top-level control file. Identify the design clocks (set_cdc_clock). Identify the clock domains of the primary ports (set_cdc_port_domain). Identify sources of stable signals (set_constant and set_cdc_signal -stable) so CDC analysis can optimize design logic. Identify custom synchronizers (set_cdc_synchronizer) and black-box modules/entities (set_black_box). Set up any other CDC preferences.
3. Run cdc with the -report_clock option. For example:

0in> cdc -d top -report_clock -ctrl top_ctrl.v
4. Check for errors and warnings. Check the CDC logs; fix errors; and resolve warnings. If you change the source code, go to step 1. 5. Check 0in_cdc_design.rpt. Ensure the clock groups and port domains are identified correctly. If not, go to step 2 and fix.
Basic Hierarchical CDC Flow

To run CDC analysis for a particular block, you must specify a hierarchical constraints control file for the block. This file identifies the CDC constraints that the design imposes on the block You can generate control files for all specified blocks automatically by running CDC analysis of the top-level design in a special block constraints generation mode. The basic hierarchical CDC flow is a 3-phase process as shown in Figure 4-6.
Phase 1: Generate Block Constraints

In the first phase of the basic hierarchical CDC analysis flow, you generate block constraints for all the hierarchical blocks at once. A blocks CDC constraints are specified as a set of global directives in a Verilog hierarchical constraints module associated with the block, saved as a CDC control file for the block. A hierarchical constraints module for a block has two parts (see Example 4-1): Global CDC preferences Design-level global directives can apply to the various blocks as well as the design as a whole. For example, set_cdc_preference, set_cdc_fifo_preference, set_cdc_handshake_preference, set_constant_propagation and set_cdc_reconvergence
119
can apply globally and can apply to the hierarchical blocks or their sub-blocks (i.e., with the -module option). Those directives that apply to the block are reproduced in the global CDC preferences section so you do not need to taylor the design-level preferences to each block. Figure 4-6. Basic Hierarchical CDC Flow
Phase 1 Generate Block Constraints cdc . . . -report_constraints blk1 blk2 blk3 . . .
hierarchical constraints les (0in_cdc_hier_constraints_*_ctrl.v)
Phase 2 Analyze Blocks
cdc . . . -hier_block blk1 \ -ctrl 0in_cdc_hier_constraints_blk1_ctrl.v . . . cdc . . .-hier_block blk2 \ -ctrl 0in_cdc_hier_constraints_blk2_ctrl.v . . . cdc . . .-hier_block blk3 \ -ctrl 0in_cdc_hier_constraints_blk3_ctrl.v . . . ...
block CDC interface models (0in_hier/*/0in_cache)
Phase 3 Analyze Top-level Design cdc . . . -hier_cache \ 0in_hier/blk1/0in_cache \ 0in_hier/blk2/0in_cache \ 0in_hier/blk3/0in_cache . . .
Block specifications Clock domain analysis of the blocks instances determines the block instances clocks and clock domains of the blocks ports. These constraints are specified with set_cdc_clock and set_cdc_port_domain directives. Also, set_constant and set_cdc_signal -stable directives are propagated to the block instance logic. Example 4-1. Hierarchical Constraints Control File
module zin_cdc_hier_constraints_ctrl_blk2; // // // // // // Block: blk2 Instances: b2 Parameters/Generics: W = 16 Global CDC Preferences 0in set_cdc_preference -promote_reconvergence -formal_add_bus_stability -formal_add_recon_stability
120
CDC Analysis Hierarchical CDC Analysis // // // // // // // // // // 0in 0in 0in 0in 0in 0in 0in 0in 0in 0in set_cdc_fifo_preference -no_read_sync set_cdc_handshake_preference -check_mux_recirculation set_constant_propagation -latch set_cdc_reconvergence -depth 4 -divergence_depth 3 set_cdc_clock clk -module blk2 set_cdc_port_domain rst -none -module blk2 set_cdc_port_domain data_in1 -clock clk -module blk2 set_cdc_clock top.clk1 -virtual -module blk2 set_cdc_port_domain data_in -clock top.clk1 -module blk2 set_cdc_port_domain data_out -clock top.clk2 -module blk2
endmodule
Running cdc in the CDC constraints generation mode generates these control files for all of the block-level analyses: 1. Select hierarchical blocks. Select the blocks you want to analyze individually. Typically they correspond to design units handled by individual developers or development teams. Candidates are blocks with many internal CDC boundaries. Since you are trying to reduce the memory used for CDC analysis, you should select blocks that distribute the CDC logic evenly across the blocks. Block instances do not have to be at the top level of the design. But, block instances cannot have hierarchical references to objects in the top level or to other block instances (and vice versa). That is, when you analyze a hierarchical block in phase 2, all of its hierarchical references must be resolved within the block and when you analyze the top level in phase 3, all of its hierarchical references must be resolved to objects not in any block analyzed in phase 2. 2. Run cdc with the -report_constraints option. This option runs CDC constraint generation, reports the clock domain data and quits. The arguments to -report_constraints are the design unit names of the block instances. For example:
0in> cdc -d top -ctrl top_ctrl.v \ -report_constraints blk1 blk2 blk1
If the same module/entity is instantiated more than once, CDC constraint generation handles variations in the top-level connectivity and parameters/generics for the different instances. 3. Check results. a. Fix errors and resolve warnings. b. Check 0in_cdc_design.rpt and ensure the clock groups and port domains are identified correctly.
121
c. Check the 0in_cdc_hier_constraints_*_ctrl.v files (if desired). For each block, check the design unit name, instance name, parameter/generic values and the global directives.
Phase 2: Analyze Blocks

For block-level CDC analysis, run a CDC analysis session for each block. To speed up analysis, run these sessions on different hosts in parallel. The following steps analyze the blk2 block: 1. Run block-level CDC analysis. For example:
0in> cdc -d top -od 0in_hier/blk2 \ -ctrl 0in_cdc_hier_constraints_blk2_ctrl.v -hier_block blk2
To segregate the block-level analysis from that of the other blocks and from the toplevel analysis, the output is directed to a subdirectory of the 0in_hier directory (-od 0in_hier/blk2). The block constraints file (0in_cdc_hier_constraints_blk2_ctrl.v) was generated in phase 1. The -hier_block argument identifies the block for the block-level analysis. 2. Run the CDC GUI and verify the CDC analysis.
shell prompt> 0in_cdc 0in_hier/blk2/0in_cdc.db
Verify the CDC checks for the block. Violations represent issues within the block. You can fix problems with the RTL source code, re-run CDC analysis for the block and iterate. But, changes to the RTL might affect CDC analysis of other blocks or the top level design, so use caution. If you do change the source code, you must re-generate block constraints and re-run block analyses for all hierarchical blocksto ensure the results are accurate and completebefore you analyze the top-level design.
Phase 3: Analyze Top-level Design

Caution You can run top-level CDC analysis only if the RTL of the design and the blocks match. If you change the logic after running block-level analysis, you must re-run the complete hierarchical CDC flow. You also need to use the same version of vlog/vcom and 0-In tools for the complete hierarchical CDC flow. Top-level CDC analysis builds a model of the top design from the CDC interface models for the blocks analyzed in phase 2 and from the remaining design logic. 1. Run top-level CDC analysis. For example:
0in> cdc -d top -od 0in_hier/top -ctrl top_ctrl.v \
122
CDC Analysis Hierarchical CDC Analysis -hier_cache 0in_hier/blk1/0in_cache \ 0in_hier/blk2/0in_cache \ 0in_hier/blk3/0in_cache
The -hier_cache option lists cache directories for the hierarchical blocks. The 0in_hier/blk1, 0in_hier/blk2 and 0in_hier/blk3 directories were specified as the output directories (-od dir) during the block-level sessions. The name specified for caches is 0in_cache by default. However, if you change the 0in cache directory name (i.e., using the -cache option to the 0in shell), the corresponding -hier_cache pathnames must match. The top-level CDC analysis detects the crossings not covered by the block-level runs and the crossings into the portal boundaries of the hierarchical blocks. When you run cdc on the top-level design, the cdc command performs consistency checks. These ensure that the criteria assumed for block-level analyses are consistent with the logic of the top-level design. If the block-level analyses used constraints files generated by -report_constraints and the design logic did not change, the data should be consistent. Consistency check violations might occur if logic changes were made after running cdc -report_constraints, or if the constraints file for a block was specified manually. The types of constituency checks are: Clocks Clocks connected to the block ports are the same between block-level and toplevel runs. Block-level clock groups match the clock groupings in the top level.
Constants Constants on the block ports are the same between block-level and top-level runs.
Port domains Port domains of the block ports match between block-level and top-level runs.
Stable ports Stable block ports in the block level must also be marked stable in the top-level run.
2. Run the CDC GUI and verify the CDC analysis.

shell prompt> 0in_cdc 0in_hier/top/0in_cdc.db
Check the results for the design. At this point, the whole design is available to the GUI for debugging. Results from the block-level sessions are merged into the top-level results. However within the blocks, only partial netlist information is available (i.e., only the level of detail retained in the CDC interface models of the blocks).
123
Hierarchical CDC Scripts

In addition to generating the block CDC constraints, the -report_constraints option of cdc creates two scripts (0in_hier.scr and 0in_hier.Makefile) useful for hierarchical CDC analysis (Figure 4-7). These scripts run the basic hierarchical CDC flow based on the information supplied when running cdc in the CDC constraints generation mode. They can be used as is or can be modified to handle advanced flows. The -report_hier_scripts option generates these scripts without performing constraints generation. Figure 4-7. -report_constraints Generates Hierarchical CDC Scripts
Phase 1 Generate Block Constraints cdc -report_constraints blk1 blk2 blk3 . . .
0in_cdc_hier_blk1_ctrl.v 0in_cdc_hier_blk2_ctrl.v 0in_cdc_hier_blk3_ctrl.v
0in_hier.scr 0in_hier.Makele
Phase 2 Analyze Blocks
The scripts are generated so that the output directory specified by the -od 0in shell option (default: current run directory) for the cdc session is specified as the output directory for the files generated by the scripts.
0in_hier.scr
The 0in_hier.scr script (see Example 4-2) is a csh script that runs the block-level analyses in sequence and then runs the top-level analysis:
shell prompt> 0in_hier.scr output from block-level sessions output from the top-level session shell prompt> 0in_cdc 0in_hier/top/0in_cdc.db
124
Example 4-2. 0in_hier.scr

#!/bin/csh -f ##----------------------------------------------------------------## Hierarchical CDC Script ##----------------------------------------------------------------\rm -fr 0in_hier mkdir 0in_hier set cdc_od = 0in_hier set cdc_hier_cmd = cdc -d top dut.v set cdc_top_cmd = cdc -d top -ctrl top_ctrl.v dut.v set ZIN = 0in # Invoke CDC for all the blocks. set fail = 0 set fail_mode = # BLOCK LEVEL RUN: blk1 $ZIN -od $cdc_od/blk1 -cache 0in_cache -cmd $cdc_hier_cmd -hier \ -ctrl /design/dut/0in_cdc_hier_constraints_blk1_ctrl.v \ -hier_block blk1 # Check for failure if ($status != 0) then if ($fail == 0) then set fail = 1 set fail_mode = blk1:blk1 else set fail_mode = ($fail_mode blk1:blk1) endif endif . . . # TOP-LEVEL RUN: top $ZIN -od ${cdc_od}/top -cmd $cdc_top_cmd \ -hier_cache $cdc_od/sub1/0in_cache \ $cdc_od/sub2/0in_cache # Check for failure if ($status != 0) then if ($fail == 0) then set fail = 1 set fail_mode = top else set fail_mode = ($fail_mode top) endif endif # Summary if ($fail == 0) then echo PASSED exit 0 else echo FAILED : $fail_mode exit -1 endif
125
0in_hier.Makefile
The 0in_hier.Makefile script (see Example 4-3) is a Makefile that runs the block-level analyses and the top-level analysis. The make all directive runs these tasks in sequence:
shell prompt> make -f 0in_hier.Makefile all output from block-level sessions output from the top-level session shell prompt> 0in_cdc 0in_hier/top/0in_cdc.db
In addition to the front-to-back flow, the Makefile can be used to run the cdc sessions individually, for example:
shell prompt> make -f 0in_hier.Makefile blk1 shell prompt> 0in_cdc 0in_hier/blk1/0in_cdc.db shell prompt> make -f 0in_hier.Makefile blk2 shell prompt> 0in_cdc 0in_hier/blk2/0in_cdc.db shell prompt> make -f 0in_hier.Makefile blk3 shell prompt> 0in_cdc 0in_hier/blk3/0in_cdc.db shell prompt> make -f 0in_hier.Makefile top shell prompt> 0in_cdc 0in_hier/top/0in_cdc.db
The targets of the make commands are the design unit names of the blocks (blk1, blk2 and blk3 in this example) and the DUT name (top). Example 4-3. 0in_hier.Makefile
## Hierarchical CDC Makefile ##----------------------------------------------------CDC_OD = 0in_hier CDC_HIER_CMD = "cdc -d top dut.v" CDC_TOP_CMD = "cdc -d top dut.v" 0IN = 0in all:BLOCKS top BLOCKS:blk1 blk2 blk3 # BLOCK-LEVEL RUN: blk1 blk1: rm -rf $(CDC_OD)/blk1 $(0IN) $(DEBUG) -od $(CDC_OD)/blk1 -cache 0in_cache \ -cmd $(CDC_HIER_CMD) -hier \ -ctrl /design/dut/0in_cdc_hier_constraints_blk1_ctrl.v \ -hier_block blk1 # BLOCK-LEVEL RUN: blk2 blk2: rm -rf $(CDC_OD)/blk2 $(0IN) $(DEBUG) -od $(CDC_OD)/blk2 -cache 0in_cache \ -cmd $(CDC_HIER_CMD) -hier \ -ctrl /design/dut/0in_cdc_hier_constraints_blk2_ctrl.v \ -hier_block blk2
126
CDC Analysis Hierarchical CDC Analysis # BLOCK-LEVEL RUN: blk3 blk3: rm -rf $(CDC_OD)/blk3 $(0IN) $(DEBUG) -od $(CDC_OD)/blk3 -cache 0in_cache \ -cmd $(CDC_HIER_CMD) -hier \ -ctrl /design/dut/0in_cdc_hier_constraints_blk3_ctrl.v \ -hier_block blk3 # TOP-LEVEL RUN: top top: rm -rf $(CDC_OD)/top $(0IN) $(DEBUG) -od $(CDC_OD)/top -cmd $(CDC_TOP_CMD) -ctrl top_ctrl.v \ -hier_cache \ $(CDC_OD)/blk1/0in_cache \ $(CDC_OD)/blk2/0in_cache \ $(CDC_OD)/blk3/0in_cache
Waivers
Waivers are instances of clock-domain crossing schemes that are waived from reporting. Waiving scheme instances eliminate the noise created by identifying all of the CDC issues found in the design. By waiving a particular instance of a CDC scheme, you are indicating the instance is OK (at least for the time being). For example, you might waive an instance of a missing synchronizer because you know the crossing has no synchronization issues. Each time you run CDC analysis with waivers identified, only relevant CDC issues are shown in the GUI CDC Checks window by default, so you do not waste time studying CDC issues that are not meaningful. For example, before performing hierarchical CDC analysis, you typically run flat CDC analysis on the various blocks as they are developed. When you view the results and debug issues, you typically mark crossings and issues to be waived. These waivers are saved as a CDC control file from the GUI (sometimes called a waiver file). You can specify this file during later CDC analysis sessions, to filter out issues already considered. In a similar way, you can incorporate waivers into the hierarchical CDC flows. 1. After running block-level analysis of a block, run the CDC GUI:
shell prompt> make -f 0in_hier.Makefile blk1 shell prompt> 0in_cdc 0in_hier/blk1/0in_cdc.db
2. Import the waivers file for the block if you have one: File >Import >Directive File. Previously-created waivers from the block development stage can be applied to the hierarchical CDC block-level results. 3. Check the existing specifications for each waived instance of a CDC scheme and add additional waivers as needed. Since you eventually want to roll the waivers up into top-level analysis, you must ensure the waivers are properly formed for this purpose. To waive a CDC scheme instance,
127
select the instance and run Create Directive >Waived. The Set CDC Report dialog is displayed with information pre-filled (Figure 4-8). Figure 4-8. Waiving a Block-level Violation
Create Directive >Waived
Remove TX/RX Clock Names
Pre-filled Dialog Fields Add Module Name
Add Comment
Ensure the following: The TX Clock and RX Clock fields are blank. Clock names at the block level do not match the clock signal names at the top level. When they do not match at the top level, a warning is reported and the waiver is ignored. So, you must leave these fields blank. The Module field specifies the module/entity name of the block. This field is often omitted when developing at the block level, but should be specified so the waiver is recognized at the top level. A comment is provided (to document the reason for the waiver).
You can set the other fields as desired. When you apply the dialog, a set_cdc_report -severity waived directive is added to the Directives window. 4. Save the waivers to a control file. Select the waivers directives in the Directives window and run Export from the popup menu. Select the Selected Directives radio button and specify a name for the CDC waivers control file (for example, waivers_blk1.v).
128
5. Specify the waivers control files for the blocks during top-level CDC control file generation:
0in> cdc -d top -ctrl top_ctrl.v \ -report_constraints blk1 blk2 blk3 \ -ctrl waivers_blk1.v -ctrl waivers_blk2.v -ctrl waivers_blk3.v
Variations on the Hierarchical CDC Flow

With the basic hierarchical CDC flow, you propagate CDC constraints from the top level to the blocks, run block-level analyses and then analyze the top-level design. When you load the results into the CDC GUI, all the CDC checks from the block-level and top-level runs are merged into the GUI session. Virtually all of the designs internal logic is available for debugging operations. So, the basic hierarchical CDC flow produces results and provides a debug environment just as if you ran the design through flat CDC analysis. In addition: By carving up the analysis problem, memory needed for overall analysis is significantly reduced. Since you can run the various block-level sessions in parallel, end-to-end analysis time is significantly reduced.
The basic hierarchical CDC flow is based on certain assumptions. All instances of each hierarchical CDC block have the same clock domains, port domains and parameter/generics settings. All hierarchical CDC blocks are suitable for block-level CDC analysis. You have a top-level design you can use to generate the CDC block constraints.
You can work around these assumptions as described in the following sections.
Heterogeneous Instances of Blocks

Homogeneous instances of a module/entity are instances that have the same configuration (i.e. the same parameters/generics and connectivity). Heterogeneous instances of a module/entity are instances that have different configurations. With the basic hierarchical CDC flow, all instances of each hierarchical CDC block are assumed to be homogeneous. A variation of the basic hierarchical CDC flow is used to analyze designs whose hierarchical CDC blocks have heterogeneous instances. When you generate block constraints (phase 1), a hierarchical control file is generated for each specified hierarchical CDC block. For example:
0in_cdc_hier_constraints_blk1_ctrl.v 0in_cdc_hier_constraints_blk2_ctrl.v 0in_cdc_hier_constraints_blk3_ctrl.v
129
In this example, all instances of blk1 are homogeneous, all instances of blk2 are homogeneous, and so on. But, if a block has heterogeneous instances, a hierarchical control file is generated for each homogeneous group of instances of the block. So, if blk1 has two sets of instances that have different configurations, two hierarchical control files are generated:
0in_cdc_hier_constraints_blk1_0_ctrl.v 0in_cdc_hier_constraints_blk1_1_ctrl.v
During block-level analysis, each of these instance groups must be analyzed separately. For example:
0in> cdc -d top -od 0in_hier/blk1_0 \ -ctrl 0in_cdc_hier_constraints_blk1_0_ctrl.v \ -hier_instance top.U1 0in> cdc -d top -od 0in_hier/blk1_1 \ -ctrl 0in_cdc_hier_constraints_blk1_1_ctrl.v \ -hier_instance top.U3
In this example, blk1 has two homogeneous groups of instances: (top.U1 top.U1) and (top.U3). Instead of specifying the blk1 block with the -hier_block module argument, you specify the homogeneous instances with a -hier_instance instances argument. In this example, block-level analyses of blk1 generate two CDC interface models for use in the top-level analysis:
0in_hier/blk1_0/0in_cache 0in_hier/blk1_1/0in_cache
Tip: The 0in_hier.scr and 0in_hier.Makefile scripts also work for heterogeneous instances of blocks. For example, make -f 0in_hier.Makefile blk1_0. When hierarchical blocks are present, 0in_cdc_design.rpt identifies them:
General Design Information ========================== Number of Black Boxes = 0 Number of Registers = 145 Number of Latches = 0 Number of RAMs = 2 Number of CFM Hierarchical Blocks Number of ILM Hierarchical Blocks Number of CDC bits = 82 Detail Design Information ========================= CFM Hierarchical Blocks: -----------------------U1 ( blk1 ) ILM Hierarchical Blocks: -----------------------U2 ( blk2 )
= 1 = 1
130
Control File Models

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

interface logic model top-level violation
V
CFM
CFM
CFM control le model

inter-block violation
V
ILM
ILM
ILM
For the blocks that you want to use the control file models, specify the corresponding generated control files with the -hier_ctrl_file_model option. For example:
0in> cdc -d top -od 0in_hier/top -ctrl top_ctrl.v \ -hier_cache 0in_hier/blk1/0in_cache \ 0in_hier/blk2/0in_cache \ -hier_ctrl_file_model blk3 0in_cdc_hier_blk3_ctrl.v
131
Here, blk1 and blk2 are modeled as ILMs and blk3 is modeled as a CFM. Never specify both an ILM and a CFM for the same block. Table 4-6 compares the ILM and CFM models and Table 4-7 shows the limitations of the control file models. Feature data structure efficacy user control granularity GUI Table 4-6. ILMs vs. CFMs Interface Logic Model Internal interface logic model saved in a block-level cache. Results are equivalent to standard (flat) CDC analysis. User can limit the depth of CDC analysis. Blocks can be modules/entities and instances. Block logic schematics available. Limitation Separate constraints for different instances of the block are not supported. Separate parameter sets for different instances of the block are not supported. CDC analysis uses the default parameter values for the block. Reconvergence violations starting from or ending in the block are not reported. Fanout data in the block is discarded, so CDC reports only one crossing to an input port of the block when multiple crossings through the port fan out to multiple receivers. Number of promoted CDC protocol and CDC-FX checkers can differ between hierarchical and standard analysis. Ignored in generated control file models and during block-level analysis. Multibit (data) synchronizers are not supported. DMUX is the only complex (nested) scheme detected. However, basic schemes such as control and bit synchronizers are supported. Not supported. SystemVerilog structs with different port domains for different fields are marked as -nosync ports. Not supported. Slices and bits in the block are not supported for set_constant. Combo fanout can degrade constraints of ports which have majority of sequential fanouts. Workaround is to set -ignore or port domain on the combo fanout port at block level. Control File Model 0-In format control file. Some CDC schemes might be missed. User can edit the control file. Blocks can be modules/entities, but not instances. Block logic schematics not available.
Table 4-7. Control File Model Limitations Feature multiple constraints non-default parameters
reconvergence input port fanout
promoted checkers bused, internal and virtual clocks complex schemes
bitwise port domains inout ports set_constant combo fanout
132
CDC Analysis Modal CDC Analysis
Modal CDC Analysis

The customers design can have several modes of operation. Following are several reasons for having multiple modes: Testing in this mode, sequential elements are chained together. Power optimization idle design blocks can be disabled, and clocks can be gated. Handles configurable designs design might be targeted for multiple customers.
Running CDC analysis on these designs results in a large number of CDC violations. Users are only interested in a subset of the violations that are relevant to the modes their designs are intended to operate in. In addition, many users (particularly verification engineers) might not be aware of the operating modes a design could operate in. A feature to automatically infer all the operating modes and let the user select the ones their design can operate in helps address this issue. Modal analysis enables the user to specify the operating modes, or infer all of the modes, or allows the user to select the set that is of interest. CDC analysis only generates violations for the modes selected by the user. Modal analysis has the following features: Automatically infer clock domain modes, with capabilities for user specification of modes. Allows the user to spawn multiple CDC runs to analyze the circuit in each mode. Debug the results of all modes through a single data base.
The modes are inferred based on the clock multiplexing in the design. For example, for a design with three clock domains (A, B, and C), if clock domain B can be synchronized to A with a MUX and the clock domain C can be synchronized to A with a MUX, each with separate control signals as shown in Figure 4-10, then there are three possible modes that are of interest for CDC analysis as follows: 1. All asynchronous. 2. A and B grouped into one domain, C a separate domain. 3. A and C grouped into one domain, B a separate domain. The fourth mode of operation, when all clocks are grouped into one domain (driven by CLKA), is not of interest to CDC analysis.
133
Figure 4-10. Modes are Inferred Based on the Clock Multiplexing
To perform the automatic recognition of clock modes, add the -report_modes option to the CDC command line. With this option, the 0in_cdc_mode_control.v file is automatically created. This file contains the definition of the inferred modes. The 0in_mode.scr shell script is then executed to spawn multiple CDC runs to analyze each mode. The mode control file can be edited to eliminate any modes that are not of interest by adding the option to the corresponding set_mode global directive in this file. Then CDC can be rerun with the modified mode control file as an input control file (using the -ctrl option) to update the run script.
-ignore
The results of all modes can be analyzed together using the CDC GUI. Invoke the CDC GUI with the following command:
0in_cdc 0in_cdc.db
Use Model
Modal analysis has two approaches as follows: With user-specified modes and inferred modes With inferred modes only
The basic use model for both approaches is identical. The difference is in the way analysis is done and reports are generated. These differences are highlighted throughout the flow. Running modal analysis is a four step process as follows:
134
1. Specify Modes (optional, see page 135) 2. Report Modes Run (see page 135) 3. Individual Mode Analysis (see page 138) 4. Viewing Results (see page 138)
Specify Modes (optional)

The user can specify the modes that need to be verified. With each mode, the user specifies constant values for a set of registers, ports, and black-box outputs. In addition, the user is required to specify the complete path. The description of the supported options follows. The modes are specified using the set_mode global directive (and the set_mode_control directive). The syntax for this global directive is as follows:
set_mode <mode_name> [-set <hier_path> <value>]* [-ignore] // Current mode name. // Constant values for this mode. // Do not analyze for this mode.
The -set option is used to specify constant values in this specific mode. This option needs to be specified once for each constant value. The -ignore option is used to specify a mode that does not need to be considered for analysis. Following is an example:
// Test modes. // 0in set_mode scan_load -set tm 1'b1 -set scan_en 1'b1 // 0in set_mode scan_test -set tm 1'b1 -set scan_en 1'b0 // Regular operation modes. // 0in set_mode fast_mode -set tm 1'b0 -set sel 1'b1 // 0in set_mode ignr_mode -set tm 1'b0 -set sel 1'b0 -ignore
Report Mode Runs

The cdc -report_modes command is required for modal analysis flow. Run CDC with the -report_modes option similar to the following:
0in cmd cdc -d top t0.v -report_modes
This automatically generates the modal script 0in_mode.scr file that you execute (just 0in_mode.scr with no arguments) as follows:
0in_mode.scr
135
This runs CDC multiple times (one per mode) and creates all of the database files (.db) for each mode. For both approaches (user-specified and inferred), the 0in_mode.scr script file is generated (see page 145). This script contains the steps to run individual mode analysis. In the presence of user modes, this script runs the user-specified modes only. If the user wishes to analyze any of the missing modes, then the user needs to run this step again with an updated control file. If no user modes are specified, then CDC infers all the operating modes. A control file named 0in_cdc_mode_ctrl.v (see page 144) is automatically generated with directives specifying all the inferred modes. Details of all the inferred modes are included in the CDC design 0in_cdc_design.rpt report file (see page 144). If the user modes are specified, then mode inferencing still occurs. The inferred modes are compared to the user modes to identify any missing or incomplete modes. All errors identified in the user specified modes are reported in the 0in_cdc_design.rpt report file (see page 144). A control file named 0in_cdc_mode_ctrl.v (see page 144) is automatically generated with set_mode global directives for incomplete user modes and inferred modes not specified by the user.
Mode Verification and Coverage Reporting

Mode verification analyzes user-specified modes for completeness and coverage with respect to the modes inferred. Appropriate warning messages are generated to report the user modes that are missing, ignored, incomplete, OK, and duplicate when the cdc -report_option is specified. The messages in the modal summary table below have the following meanings: Missing mode This is an inferred mode. For every missing mode, a [hdl-119] message is generated. A set_mode global directive is generated for this inferred mode in the 0in_cdc_mode_ctrl.v file. Ignored mode This user mode is ignored for modal analysis. This is specified by the user with the -ignore option. Incomplete mode This user mode is partially specified and needs additional constants. For each missing constant inferred by the tool, a [hdl-125] warning message is issued. A set_mode global directive is generated for the corresponding complete mode in the 0in_cdc_mode_ctrl.v file. OK This user mode is complete (verified). The user mode may contain additional signals that were not inferred. These signals are marked as undetected in the mode information table. The [hdl-124] information messages are issued for each undetected signal.
136
Duplicate mode This user mode is a duplicate of another user-specified mode or incomplete mode. A [hdl-118] warning message is issued for every duplicate mode.
The Modal summary and information tables shown below are printed in the 0in_cdc_design.rpt file when the cdc -report_modes option is specified.
Modes ===== -------------------------------------------------------------Mode Type Message -------------------------------------------------------------cdc_mode_0 0-In CDC Missing mode mode2 User Ignored mode mode3 User Incomplete mode(missing constant) mode4 User OK mode5 User OK mode6 User Duplicate mode(mode4) --------------------------------------------------------------
User Modes ========= Constants in mode2 (Ignored) ---------------------------------------------------Signal Value Type ---------------------------------------------------sel1 1'b0 User sel2 1'b0 User ----------------------------------------------------
Constants in mode3 (Incomplete) ---------------------------------------------------Signal Value Type ---------------------------------------------------sel1 1'b0 User sel2 1'b1 User sel3 1'b1 0-In CDC ----------------------------------------------------
Constants in mode4 ---------------------------------------------------Signal Value Type ---------------------------------------------------sel4[3:2] 2'b10 User sel5 3'b110 User ----------------------------------------------------
Constants in mode5 ---------------------------------------------------Signal Value Type ---------------------------------------------------sel1 1'b1 User sel2 1'b0 User
137
CDC Analysis Modal CDC Analysis sel5 3'b101 User (Undetected) ----------------------------------------------------
Constants in mode6 (Duplicate) ---------------------------------------------------Signal Value Type ---------------------------------------------------sel4[3:2] 2'b10 User sel5 3'b110 User ----------------------------------------------------
Inferred Modes =============== Constants in cdc_mode_0 (Missing) ---------------------------------------------------Signal Value ---------------------------------------------------sel1 1'b1 sel2 1'b0 sel3 1'b1 ----------------------------------------------------
Individual Mode Analysis

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

The 0in_cdc user interface (UI) supports debug of the CDC modal database. To use it, invoke on the database (that is, 0in_cdc 0in_cdc.db) the same as for a database that is not modal. The UI automatically determines whether to be in modal mode or not. If the database has modal CDC results, then the UI displays the additional mode indicators to help the user browse the modal results. Figure 4-11 shows the mode indicators circled in red. To invoke the schematic view, double-click or right-click on the check, select Show Schematic > Path, as shown in Figure 4-11. To invoke the Details window, right click on the check, select Show Details. Figure 4-11. 0in_cdc Mode
If the database is modal, then the CDC Checks view has a mode column (see Figure 4-11) so that the checks can be grouped and sorted by mode. The clock tree display in the Workspace pane (see Figure 4-11) also shows an additional mode level of hierarchy.
139
Note that the Mode column in the Transcript window can be moved. This causes the display to reorganize the hierarchy, with Mode as the first level of sorting. Place the cursor on the Mode bar, then drag to the desired location as shown in Figure 4-12. Figure 4-12. Moving the Mode Location
The filters feature can be used to change the default maximum hierarchy displayed. To do this, right-click on a signal and select Filters as shown in Figure 4-13. This invokes the Edit Preferences window as shown in Figure 4-14. Change the Maximum Hierarchy Displayed number as desired. In this example, the number is changed from 3 to 0. Figure 4-13. Filter
140
Figure 4-14. Filter Hierarchy Displayed
Because any schematic path displayed from the CDC Checks view is from a specific CDC modal run, the schematic always retains its mode so that incremental exploring of that schematic colors itself as per that mode as shown in Figure 4-11 on page 139. The mode for the schematic path is displayed in the schematics title. In addition, the Path ID signal is displayed in the schematic title and in the Details pane, which is multi_bits_68424 for this example (circled in green in Figure 4-11 on page 139). Note that the bubble help not only displays the usual clock group for a signal, but also the mode for that clock tree as shown in Figure 4-15.
141
Figure 4-15. Mode for the Clock Tree
Clock Color as the Mode Context Changes

Any non-CDC path schematics as well as HDL source views update their clock coloring as the mode context changes. The user can change the mode context by selecting the mode or a signal in the mode tree from within the clock tree view. The current mode is displayed in the title bar and the footer. Figure 4-16 and Figure 4-17 show the color changes as the mode context changes. Note also that the Details window reflects the port constraint settings for the current mode selected. Go to the Workspace window, select Design, then double-click to select an Instance (modr(6) is used in this example). Then go to the Clocks tab and select a clock in the Mode window (cdc_mode_0 (4) is selected). View the color mode context scheme in Figure 4-16.
142
Figure 4-16. Clock Coloring Mode
Now select cdc_mode_1 (5) and observe the signals change color as shown in Figure 4-17. Figure 4-17. Color Change as the Mode Context Changes
143
Examples
0in_cdc_mode_ctrl.v File
An example of the automatically generated mode control file (0in_cdc_mode_ctrl.v) is shown below:
module zin_cdc_mode_ctrl_top; // Mode: cdc_mode_0 // Clock: TRK /* 0in set_mode cdc_mode_0 -set TCS 1'b1 */ // Mode: cdc_mode_1 // Clocks: // CLK0 // RCLK[0] /* 0in set_mode cdc_mode_1 -set TCS 1'b0 -set I5[1:0] 2'b0 */ // Mode: cdc_mode_2 // Clocks: // CLK0 // RCLK[1] /* 0in set_mode cdc_mode_2 -set TCS 1'b0 -set I5[1:0] 2'b1 */ endmodule
0in_cdc_design.rpt File
A sample mode coverage report file (generated in 0in_cdc_design.rpt) is shown below:
Mode information ================ -------------------------------------------Mode Type Information -------------------------------------------cdc_mode_0 0-In CDC Inferred mode cdc_mode_1 0-In CDC Inferred mode cdc_mode_2 0-In CDC Inferred mode -------------------------------------------User Modes ========== None Inferred Modes ============== Constants in cdc_mode_0
144
CDC Analysis Modal CDC Analysis ------------------------------------------Signal Value ------------------------------------------TCS 1'b1 ------------------------------------------Constants in cdc_mode_1 ------------------------------------------Signal Value ------------------------------------------TCS 1'b0 I5[1:0] 2'b00 ------------------------------------------Constants in cdc_mode_2 ------------------------------------------Signal Value ------------------------------------------TCS 1'b0 I5[1:0] 2'b01 -------------------------------------------
0in_mode.scr File
A sample automatically generated mode script file (0in_mode.scr) is shown below:
#!/bin/csh -f \rm -fr /modal/0in_mode mkdir /modal/0in_mode set cdc_od = /modal/0in_mode set cdc_cmd = "cdc -d top t0.v" # Invoke CDC for all the modes. set fail = 0 set fail_mode = "" foreach cdc_mode (cdc_mode_0 cdc_mode_1 cdc_mode_2) # Run CDC for $cdc_mode 0in -od ${cdc_od}/$cdc_mode \ -cmd $cdc_cmd \ -ctrl 0in_cdc_mode_ctrl.v \ -mode $cdc_mode # Check for failures if ($status != 0) then if ($fail == 0) then set fail = 1 set fail_mode = $cdc_mode else set fail_mode = ($fail_mode $cdc_mode) endif endif end
145
CDC Analysis Modal CDC Analysis # Cleanup if ($fail == 0) then echo PASSED exit 0 else echo FAILED : $fail_mode exit -1 endif
Viewing Incomplete CDC Runs

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

0in_cdc 0in_cdc.db &
This command invokes the CDC GUI as shown in Figure 4-18 with the Clock tab selected. Notice in the Workspace window that the modes are not loaded.
146
Figure 4-18. Modes Have No Clock Tree Information
3. Generate the reports for each modal run as follows:

0in_mode.scr
Refer to 0in_mode.scr File on page 145 for detailed information. While this command continues to run, the user can review the clock tree as follows (see Figure 4-19):
File > Reload > Database
Figure 4-19. Reload Database
147
Figure 4-20 shows cdc_mode_0 and cdc_mode_1 are now loaded. However, cdc_mode_2 has not completed running and is not loaded. As the design continues to run, the user can continue to select File > Reload > Database to load as they complete running. Figure 4-20. Some Modes Have Clock Tree Information
148
CDC Analysis CDC Analysis of FPGAs
CDC Analysis of FPGAs

CDC analysis of an FPGA design requires special handling. The standard FPGA source libraries are designed for simulation and in particular, they are not completely synthesizable. Synthesizable libraries are needed because CDC analysis (unlike simulation) is based on a netlist of the design. Building a netlist requires synthesizable code for compiling the design and for compiling the FPGA source libraries (see Compiling FPGA Source Libraries on page 63). 0-In distribution software comes with synthesizable versions of the unisim/simprim Xilinx and the Altera source libraries in $HOME_0IN/share/fpga_libs.
Phase 1: Compiling the FPGA Source Libraries

If you have compiled your FPGA source libraries already for Questa simulation, you can use them for CDC analysis if: The libraries RTL is synthesizable VHDL, Verilog or SystemVerilog code. The libraries were compiled using the versions of Questa vcom/vlog commands that match those shipped with the 0-In distribution software.
If these statements are true, skip to Phase 2. If not, compile the FPGA source libraries into resource libraries. First create a directory to hold the compiled FPGA resource libraries:
prompt> mkdir 0in_libs
Then, set up and compile the FPGA source libraries as illustrated in the following examples. If FPGA library elements are instantiated in VHDL code, you must compile a resource library for that. The logical library name for this library has no _ver suffix. If FPGA library elements are instantiated in Verilog code, you must compile a resource library for that. The logical library name for this library has a _ver suffix.
Xilinx
unisim Used for library elements instantiated in VHDL. Compile the VHDL files containing the component and package declarations from the standard Xilinx simulation library. Then compile the synthesizable Verilog models of the library. The vlog -convertallparams option is needed to convert the Verilog parameters to match the generics types in the VHDL component definitions.
vlib vmap vcom vcom vlog 0in_libs/unisim unisim 0in_libs/unisim -work unisim $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd -work unisim $XILINX/vhdl/src/unisims/unisim_VPKG.vhd -work unisim -convertallparams \ $HOME_0IN/share/fpga_libs/Xilinx/ISE/xeclib/unisims/*.v
149
unisims_ver Used for library elements instantiated in Verilog. Compile the synthesizable Verilog models of the Xilinx library.
vlib 0in_libs/unisim vmap unisims_ver 0in_libs/unisims_ver vlog -work unisims_ver \ $HOME_0IN/share/fpga_libs/Xilinx/ISE/xeclib/unisims/*.v
simprim Used for library elements instantiated in VHDL. Compile the VHDL files containing the component and package declarations from the standard Xilinx simulation library. Then compile the synthesizable Verilog models of the library. The vlog -convertallparams option is needed to convert the Verilog parameters to match the generics types in the VHDL component definitions.
vlib vmap vcom vcom vlog 0in_libs/simprim simprim 0in_libs/simprim -work simprim $XILINX/vhdl/src/simprims/simprim_Vcomponents.vhd -work simprim $XILINX/vhdl/src/simprims/simprim_Vpackage.vhd -work simprim -convertallparams \ $HOME_0IN/share/fpga_libs/Xilinx/ISE/xeclib/simprims/*.v
simprims_ver Used for library elements instantiated in Verilog. Compile the synthesizable Verilog models of the Xilinx library.
vlib 0in_libs/simprim vmap simprims_ver 0in_libs/simprims_ver vlog -work simprims_ver \ $HOME_0IN/share/fpga_libs/Xilinx/ISE/xeclib/simprims/*.v
XilinxCoreLib Used for library elements instantiated in VHDL. Compile the VHDL simulation library files. The XilinxCoreLib_vhdl_analyze_order filelist specifies the synthesizable files in the correct compilation order.
vlib 0in_libs/XilinxCoreLib vmap XilinxCoreLib 0in_libs/XilinxCoreLib vcom -work XilinxCoreLib -f XilinxCoreLib_vhdl_analyze_order
XilinxCoreLib_ver Used for library elements instantiated in Verilog. Compile the Verilog simulation library files.
vlib 0in_libs/XilinxCoreLib_ver vmap XilinxCoreLib_ver 0in_libs/XilinxCoreLib_ver vlog -work XilinxCoreLib_ver $XILINX/verilog/src/XilinxCoreLib/*.v
150
Altera
If FPGA library elements are instantiated in VHDL code, you must compile a resource library for that. The logical library name for this library has no _ver suffix. If FPGA library elements are instantiated in Verilog code, you must compile a resource library for that. The logical library name for this library has a _ver suffix. altera_mf Used for library elements instantiated in VHDL. Compile the VHDL files containing the component and package declarations from the standard Altera simulation library. Then compile the synthesizable Verilog models of the library. The vlog +incdir argument is the include directory for the source files.
vlib 0in_libs/altera_mf vmap altera_mf 0in_libs/altera_mf vcom -work altera_mf \ $QUARTUS_ROOTDIR/eda/sim_lib/altera_mf_components.vhd vlog -work altera_mf \ $HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \ +incdir+$HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog
altera_mf_ver Used for library elements instantiated in Verilog. Compile the synthesizable Verilog models of the Altera library. The vlog +incdir argument is the include directory for the source files.
vlib 0in_libs/altera_mf_ver vmap altera_mf_ver 0in_libs/altera_mf_ver vlog -work altera_mf_ver \ $HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog/*.v \ +incdir+$HOME_0IN/share/fpga_libs/Altera/quartus/fv_lib/verilog
Logical-physical Library Mappings

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

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

The target design is the top-level block for CDC analysis. This can be a VHDL entity (or configuration) or a Verilog module. The -d <design> argument to the cdc compiler/analyzer command is a required argument that identifies the target design. Once the FPGA resource libraries and the design library have been compiled, you can compile the CDC logic model using the cdc command (page 359). Here are two examples:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd
Compiles the target design DUT_top from work using libraries mapped in ./modelsim.ini (the default mapping file).
prompt> 0in -cmd cdc -d DUT_top -work top_lib -vhctrl cdc_control.vhd \ -modelsimini LibraryMapping.0in
Compiles the target design DUT_top from top_lib using libraries mapped in LibraryMapping.0in.
152
Tip: Running cdc on a design can take time. Initial cdc runs are used only to refine the clock domain model of the design in preparation for compiling and analyzing the CDC logic. The cdc commands -report_clock option short-circuits the complete cdc compilation/analysis and stops after identifying the clock domain model characteristics. You will use this option initially to ensure that the clocks and clock groups are identified correctly before performing complete compilation of the CDC logic. Use the following steps to compile a CDC model of the design. 1. Create one or more control files. A control file is a text file listing a series of 0in global directives (page 260). Global directives set up operating conditions, define clocks, define black boxes, specify custom synchronizers, modify reported results, create waivers, and so on. You will apply significant effort creating and adjusting the control files because this is how you fine tune CDC analysis. Here is an example control file:
entity cdc_control is end cdc_control; architecture ctrl of cdc_control is begin -- 0in set_constant scan_mode 0 -- 0in set_cdc_clock CLK_1 -group clk_grp_A -period 4 -- 0in set_cdc_clock CLK_2 -group clk_grp_A -period 8 -- 0in set_cdc_clock CLK_3 -group clk_grp_B -period 11 -- 0in set_cdc_port_domain input_port1 -async -- 0in set_cdc_port_domain input_port2 -clock CLK_1 -- 0in set_cdc_port_domain -output -clock CLK_2 -- 0in set_cdc_reconvergence -depth 1 -divergence_depth 1 -- 0in set_black_box syncA* cdi_master -- 0in set_cdc_preference -blackbox_empty_module end ctrl;
In addition to standard CDC global directives, the following directives are particularly useful for CDC analysis of FPGA designs. set_constant Applies a constant value to input ports (and sometimes to internal nodes) so the cdc compiler can prune irrelevant logic from the design logic and the CDC model. This technique makes the memory footprint smaller, improves performance and ensures only relevant results are returned. set_cdc_reconvergence Sets the sequential levels that define how deep paths diverge and reconverge to be considered instances of reconvergence and single_source_reconvergence schemes. The deeper the analysis, the greater the decrease in performance. Initially, set the reconvergence depth to 1 and the divergence depth to 1.
153
set_black_box Identifies specific modules/entities/architectures as user-defined black boxes. Use set_cdc_port_domain directives to identify the clock domains for the black boxes ports (even asynchronous ones) so the logic outside the black box instances can be analyzed properly. Fanin/fanout logic of ports of user-defined black box instances that are not assigned port domains is ignored for CDC analysis. set_cdc_preference -blackbox_empty_module Turns empty modules/entities/architectures into inferred black boxes instead of treating them as regular models. Some elements in a synthesizable FPGA library are stubs containing only the port declarations. Specifying the -blackbox_empty_module option makes it easier to identify these elements so you can add set_cdc_port_domain directives for their ports. Tip: Hierarchical paths always appear in the 0-In report files with . separators (which might be different from the path separator reported by simulation). Use these exact paths in the control files as well. When creating control directives that refer to specific signals in the RTL, cut and paste the exact pathnames from the report files or GUI. 2. Run cdc in report-clocks mode. For example:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd \ -report_clock
The command performs clock analysis and stops. Check the results: a. Check 0in.log for errors:
Error/Warning Summary (Look in 0in_detail.log for more information) ----------------------------------------------------------Count Type Message ID Summary ----------------------------------------------------------1 Error command-188 Design elaboration failed. 1 Error command-195 Design Elaboration (Child process) returned a non zero status. 1 Error parser-284 Vopt error.
Each error/warning is explicitly described in 0in_detail.log. Fix any issues, then rerun design compilation (if the source code changed) and cdc -report_clock. b. Check the clock groupings in 0in_cdc_design.rpt.
Clock Group Summary for DUT_top ================================= Total Number of Clock Groups Number of User-Defined Clock Groups Number of Inferred Clock Groups Number of Ignored Clock Groups
: : : :
2 1 1 0
154
User-Specified Clock Groups =========================== Group 0(0 Register Bits, 0 Latch Bits) -----------------------------------------clk[0] Inferred Clock Groups ===================== Group 0(11 Register Bits, 0 Latch Bits) ------------------------------------------clk[1] shft_sync.clk dff_sync.clk Ignored Clock Groups ==================== None
Synchronous clocks should be grouped together. Clocks in different groups are assumed to be asynchronous and therefore require synchronization on signals that traverse storage elements in different clock domains. CDC analysis results are not meaningful until the clocks are set up correctly. 3. Run cdc. For example:
prompt> 0in -cmd cdc -d DUT_top -work work -vhctrl cdc_ctrl.vhd
The command performs clock analysis, compiles the CDC model of the design, runs CDC analysis, generates reports on the results and generates a database file to load into the CDC GUI for debugging issues found by static CDC analysis. Among the files generated by cdc: 0in_cdc.db 0-In database of the CDC results for loading into the CDC GUI. 0in_cdc.rpt Text report containing CDC results. 0in_cdc_design.rpt Text report containing results of clock and design analysis 0in_cdc_ctrl.v Control file specifying generated CDC protocol checkers.
4. Check the 0in_cdc_design.rpt again. a. Check the port domains:

Port Domain Information ======================= Port Direction Constraints Clock Domain Type ------------------------------------------------------------------clk input Clock Bus {clk[1]} 0-In CDC rst input Reset {clk[1]} 0-In CDC in1 input {clk[0]} User in2 input {clk[0]} User in3 input {clk[0]} User out1 output {clk[1]} 0-In CDC out2 output {clk[1]} 0-In CDC
155
Check the inferred port domains (clock domains assigned to the ports). By default, each input port is assigned to the clock domain of its first fan-in register. Any primary inputs or outputs that connect to multiple clock domains or are not assigned to a clock domain are listed. Use set_cdc_port_domain directives to make adjustments. b. Check for black boxes.
Black Boxes: -----------cdi_master syncA_1 syncA_3 syncA_7 tctrl
( ( ( ( (
black_box ) black_box ) black_box ) black_box ) inferred )
Internal logic of the black boxes is unknown and in particular, the connectivity between a black boxs inputs and outputs is unknown. So, black boxes can mask some CDC problems. Check that the port domains of the user-defined black boxes (black_box in the report) are all specified. VITAL models, FPGA library elements that are not synthesizable and design blocks with unsynthesizable constructs are inferred black boxes (inferred in the report), unless explicitly specified with set_black_box directives. Check the inferred black boxes in 0in_cdc.rpt. If an inferred black box affects CDC results, at least one associated blackbox CDC scheme is reported:
Blackbox Crossing. (blackbox) ----------------------------------------------------------------tx_clk: start: tx_sig2 (/u/zin/blackbox/dut.v : 25) <clock N/A>: end: dut.Di2 (/u/zin/dut.v: 40) (ID:blackbox_12944)
You can declare the black box as a user-defined black box (with set_black_box) and specify the port domains for the black boxs I/O ports (with set_cdc_port_domain). The following example directives do this for an Altera dual-port RAM block:
-----------------0in 0in 0in 0in 0in 0in 0in 0in 0in 0in 0in 0in 0in set_black_box altdpram set_cdc_port_domain wren -clock inclock -module altdpram set_cdc_port_domain data -clock inclock -module altdpram set_cdc_port_domain wraddress -clock inclock -module altdpram set_cdc_port_domain wraddressstall -clock inclock -module altdpram set_cdc_port_domain inclocken -clock inclock -module altdpram set_cdc_port_domain byteena -clock inclock -module altdpram set_cdc_port_domain rden -clock outclock -module altdpram set_cdc_port_domain rdaddress -clock outclock -module altdpram set_cdc_port_domain rdaddressstall -clock outclock -module altdpram set_cdc_port_domain outclocken -clock outclock -module altdpram set_cdc_port_domain q -clock outclock -module altdpram set_cdc_port_domain aclr -async -module altdpram
156
You might be able to obtain or write synthesizable models of various black-boxed elements. For example, using the Xilinx CoreGen tool: run Project >Project Options; select the Generation tab; and set Simulation Files: Structural. Structural models are synthesizable. Be sure to keep the structural models and behavioral models in different locations to prevent overwriting previously-generated files.
Phase 4: Running GUI Debug

The 0in_cdc command runs the CDC GUI. To run 0in_cdc in GUI debug mode, specify the CDC results database as the only argument:
At this point, debugging CDC issues with the CDC GUI is the same for FPGA-based design as it is with other designs. See 0in_cdc: GUI Debug Mode on page 88. Also see the chapter GUI Reference on page 411 for details on the various GUI tools and windows. As you analyze the CDC results, you will find RTL issues to fix, to waive and to filter out. You might want to add or change directives in your control file to: Adjust clock configurations (set_cdc_clock) Set clock domains of I/O ports (set_cdc_port_domain) Declare custom synchronizers (set_cdc_synchronizer) Define characteristics of certain signals in the design (set_cdc_signal) Reclassify the results (set_cdc_report)
157
158
Chapter 5 CDC-FX Metastability Injection

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

The metastability windows indicate the transmit/receive clock edge relations that determines when metastability can occur. They are specified to the ccl command using the set_cdc_fx_metastability_window global directive (see page 163). This global directive sets the metastability window for the CDC-FX clocks.
Setup and Hold Periods

Figure 5-1 shows setup and hold time periods around a registers clock edge along with sample waveforms for an input to the register(s). The input signal is stable if it is held at a constant 0 or 1 value during the setup and hold periods. The signal is unstable if it changes during these periods. If the signal input to a register is unstable, then the register can become metastable. Figure 5-1. Setup and Hold Times for a Register Input
tsetup
rx_clk
thold
s s s s
stable unstable unstable stable
Metastability Windows
The setup and hold times determine receive clock cycles for which a register can become metastablebased on the active edge of the receive clock and the value of the signal at the input port of the register. In hardware, however, this input port switches value after the output port driving the signal (in the transmit clock domain) switches and the new value propagates to the input port (in the receive clock domain). This propagation delay (tprop) has the following physical bounds:
min tprop
tprop
max tprop
Accounting for propagation delay identifies a metastability window relative to each active edge of the receive clock, as shown in Figure 5-2. A metastability window defined this way assumes the worst case events as follows: CDC signal propagates as slowly as possible (max tprop) and violates the setup time (tsetup). CDC signal propagates as quickly as possible (min tprop) and violates the hold time (thold).
160
Figure 5-2. Metastability Window

tsetup
rx_clk
thold
max tprop min tprop

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

Note the following information about metastability windows: Except for the default case, the metastability windows are not set automatically by software. The user sets up metastability windows based on the knowledge of the hardware technology and characteristics of the design by specifying their start and stop values. However, the user does not need to specify setup/hold times or propagation delay ranges. Each pair of transmit/receive clocks has its own metastability window (either specified or default). In particular, a receive clock might have multiple windows. If the duration of a metastability window is sufficiently large, then every active edge of the corresponding transmit clock falls inside the window. In this case, simulation with metastability injectors randomly inserts metastability effects every clock cycle the register changes value. A common metastability verification methodology is to start with large metastability windows (for example, the default case). Then, successively narrow the windows and focus analysis on select CDC paths. This way the user can analyze the worst case scenario (so no bugs might be missed). Then, after eliminating false violations, the user can identify real problems caused by metastability intolerance. Metastability windows are used for metastability injected simulation. They have no counterpart in hardware. In hardware, a changing CDC signal either does or does not result in the receive register going metastable, and the hardware value either does or does not agree with the value used in plain simulation.
161
clks_aligned[65:0]
When the assertion compiler instantiates a cdc_fx checker, it also creates clock monitor logic that determines when the transmit clock is within the metastability window of the receive clock (for that transmit clock). Whenever this occurs, the receive register is prone to metastability if its input value also changes in that receive clock cycle. The clks_aligned output from the clock monitor is used to pass this information to the cdc_fx checker. The clks_aligned output is a 66-bit value that is 0 throughout normal cycles. When the clock monitor detects an active transmit clock edge in the corresponding metastability window of the receive clock edge, one of the clks_aligned bits asserts a pulse that begins at the second active clock edge and stops at the first subsequent inactive clock edge (see Figure 5-3). Note the following: clks_aligned[0] 1 if tx_clk is before rx_clk. clks_aligned[1] 1 if tx_clk is after rx_clk. clks_aligned[33:2] metastability window start time. clks_aligned[65:34] metastability window stop time. Figure 5-3. clks_aligned Input to the cdc_fx Checker
Clocks not aligned.
clks_aligned tx_clk rx_clk metastability window 0
Clocks aligned. Transmit clock edge before (or at) receive clock edge.
clks_aligned[0] tx_clk rx_clk metastability window
Clocks aligned. Receive clock edge before transmit clock edge.

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

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

tsetup
rx_clk start = 25% clock period stop = 10% default metastability window
thold
For example, if rx_clk has period 100 time units, then the default metastability window is the same as the window set by the following:
/* 0in set_cdc_fx_metastability_window -start 25 stop 10 -tx_clock tx_clk -rx_clock rx_clk */
See also set_cdc_fx_timescale on page 270.
164
CDC-FX Metastability Injection Running CDC-FX
Running CDC-FX
The metastability injectors (cdc_fx checkers and metastability detection logic) are instantiated from cdc_fx checker directives. The user can specify these directives manually, but CDC paths can be numerous and this process is prone to user error. Instead, use a built-in feature of the cdc command to automate the process of preparing the design data for the CCL compiler. Since cdc analyzes CDC paths anyway, it can readily construct the cdc_fx checker directives for them. Therefore, if the user includes the -fx option to the cdc command, then it generates a CDC-FX control file (0in_cdc_fx_sim_ctrl.v) that contains cdc_fx checker directives that can be used with the CCL compiler (see Figure 5-5). Figure 5-5. CDC Data Flow for Simulation with Metastability
CDC-FX control le (with set_cdc_fx_check directives) cdc -fx 0in_cdc_fx_sim_ctrl.v edit design checker les control les ccl CDC-FX control le (with set_cdc_fx_metastability_window directives) simulation with metastability
Figure 5-5 also shows that part of the data preparation for the CDC-FX analysis is to set up an optional CDC-FX control file that contains the set_cdc_fx_metastability_window global directives used to set the metastability windows for the cdc_fx checkers.
set_cdc_fx_check
The set_cdc_fx_check directive turns on specified checks in corresponding cdc_fx checker directives promoted by the cdc -fx command. set_cdc_fx_check [-scheme scheme] [-tx_clock clock_signal] [-rx_clock clock_signal] [-fx] [-glitch_swallowed] [-glitch_caught] By default, the cdc_fx checker directives promoted from the cdc -fx command are configured as follows: The cdc_fx checkers on single-bit registers have no checks turned on. The cdc_fx checkers on multiple-bit registers have only the cdc_fx check turned on.
165
Use the set_cdc_fx_check global directive to force cdc -fx to turn on the cdc_fx checkers checks. The user must specify at least one check to turn on (-fx, -glitch_caught, or -glitch_ swallowed). The -tx_clock option restricts the directive to those cdc_fx checkers with the specified transmit clock. The -rx_clock option restricts the directive to those cdc_fx checkers with the specified receive clock. The -scheme option restricts the directive to those cdc_fx checkers connected to synchronizers of the specified type. The set_cdc_fx_check global directive does not support wildcards.
0in_cdc_fx_sim_ctrl.v
0-In CDC analyzes CDC information. For certain CDC signals and data buses, it formulates checker directives that instantiate a cdc_fx checker and generates metastability detection logic for modeling CDC metastability effects during simulation with assertions. These promoted cdc_fx directives are saved in the zin_cdc_fx_sim_ctrl module in the 0in_cdc_fx_sim_ctrl.v file (see Example 5-1). The user can edit the 0in_cdc_fx_sim_ctrl.v file to remove unnecessary directives and make changes that might apply to your design. Then, the user specifies the edited file as a checker control file when invoking the ccl command, as demonstrated in Example 5-2 on page 167. Example 5-1. 0in_cdc_fx_sim_ctrl.v File Snippet
//----------------------------------------------------------------// CDC FX Simulation File // Created Mon Dec 18 14:56:50 2006 //----------------------------------------------------------------//Summary //------//Count : Module //----------------------------------------------------------------// 17 : demo_top
module zin_cdc_fx_sim_ctrl; //cpu_clk_in --> mac_clk_in //ID:two_dff_5840 --> init_done //----------------------------------------------------------------/* 0in cdc_fx -tx_reg init_done -rx_reg init_done_r1 -tx_clock cpu_clk_in -rx_clock mac_clk_in -name zin_cdc_fx_sim_init_done_r1_0 -module demo_top -inferred */
166
//cpu_clk_in --> core_clk_in //ID:no_sync_47305 --> init_done //----------------------------------------------------------------/* 0in cdc_fx -tx_reg init_done -rx_reg tx_state[0] -tx_clock cpu_clk_in -rx_clock core_clk_in -name zin_cdc_fx_sim_tx_state_0__1 -module demo_top -inferred */ //cpu_clk_in --> core_clk_in //ID:no_sync_2628 --> init_done //----------------------------------------------------------------/* 0in cdc_fx -tx_reg init_done -rx_reg tx_en -tx_clock cpu_clk_in -rx_clock core_clk_in -name zin_cdc_fx_sim_tx_en_2 -module demo_top -inferred */ . . . endmodule
Example 5-2. Editing the 0in_cdc_fx_sim_ctrl.v File

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

Table 5-1 shows the CDC schemes that promote cdc_fx checkers. Table 5-1. CDC Schemes and cdc_fx Checker Promotion Promote cdc_fx Checkers bus_dff_sync_gated_clk bus_four_latch bus_shift_reg bus_two_dff bus_two_dff_phase combo_logic dff_sync_gated_clk dmux fanin_different_clks four_latch handshake multi_bits multi_sync_mux_select no_sync pulse_sync shift_reg simple_dmux two_dff two_dff_phase Do Not Promote cdc_fx Checkers async_reset async_reset_no_sync blackbox custom_sync bus_custom_sync memory_sync reconvergence redundant single_source_reconvergence
167
The following situations can cause a cdc_fx checker not to be promoted, or to be promoted with partial information: Individual signals from multibit registers. Signals from registers with different transmit clocks fan into a receive register. The tx_reg or the rx_reg is not a real register and custom_fx is not on. For example, it is a memory or a FIFO. The tx_clk or rx_clk is missing. For example, the transmit register is an asynchronous input port. There are latches between tx_reg and rx_reg. Promotions are turned off. Clock logic for one of the clocks has a UDP. RX logic uses a custom synchronizer.
168
CDC-FX Metastability Injection Running Metastability-injected Simulation
Running Metastability-injected Simulation

Metastability-injected simulation uses the same flow as simulation with protocol checkers. The -compile_assertions option to the cdc command compiles the metastability injection logic and sets up the arguments needed to run metastability-injected simulation (Figure 5-6). Figure 5-6. Metastability-injected Simulation
-work library vsim
0in_cdc.db
Results from metastability-injected simulation can be merged back into the CDC GUI for review and debugging. The following procedure uses the Questa vsim simulator. 1. Set up the design library and compile the design. For example:
prompt> vlib work prompt> vmap work work prompt> vcom dut.vhdl
2. Run CDC analysis. Specify the -compile_assertions and the prefix showing the hierarchy path from the top level testbench to the DUT analyzed by cdc. Also specify -fx so cdc generates the information used to compile the metastability injection logic. For example:
prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v \ -compile_assertions -prefix tb.dut_inst -fx
169
3. Compile the CDC-FX metastability injection logic. Specify the simulation arguments files generated by cdc. For example:

prompt> vlog tb.v
5. Run simulation. Specify the PLI library path for the simulator and the vsim arguments files. For example:
6. Run the CDC GUI. Load the 0in_cdc.db database generated by cdc and merge the 0in_checksim.db database generated by vsim.
Simulation Arguments
The user can use simulation arguments to suppress metastability injection during simulation (for individual CDC signals or all CDC signals) and to set the seed for random metastability injection. The cdc_fx checkers maintain statistics, but metastability is not injected into simulation.
+0in_suppress_fx_name+name
To suppress metastability injection during simulation for individual signals, specify them with simulation arguments of the following form:
+0in_suppress_fx_name{+name}
Here, name is the cdc_fx checker name. Wildcards can be used in name. For example,
+0in_suppress_fx_name+tx4_*+tx_data
+0in_disable_fx_force
To suppress metastability injection for all individual signals, specify the following argument:
+0in_disable_fx_force
Refer to Verilog Glue Logic Option Impact on page 171 and VHDL Glue Logic Option Impact on page 173 for additional information.
170
+0in_random_seed+n
To set the random generator seed for random metastability injection, specify the following simulation argument:
+0in_random_seed+n
Here, n is a positive (32-bit decimal) integer to use as the seed for the random number generator. Default: 11449.
CDC-FX PLI Functions

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

The differences between the following options for Verilog glue logic are described in this section: ZI_NO_CDC_FORCE
171
+0in_disable_fx_force $0in_never_invert_metastable_signals
The Verilog glue logic is as follows:

initial begin ìfdef ZI_NO_CDC_FORCE èlse if (!($test$plusargs("0in_disable_fx_force"))) begin force ìnt_prefix_0in.U1.U12.dout = zin_wire_sg_0; end èndif end
The options have the following impact.
ZI_NO_CDC_FORCE Option
This option can only be used during compiling the design. It permanently removes the force statement. For example,
% vlog +define+ZI_NO_CDC_FORCE test.v
or
% vcs +define+ZI_NO_CDC_FORCE test.v
+0in_disable_fx_force Option
This option can only be used during simulation. It disables the force statements for that specific simulation run. For example,
% vsim tb \ +0in_disable_fx_force \ -f 0in_sim.arg.vsim \ -pli ${HOME_0IN}/lib/lib0InLoadMTIPLI.so
or
% ./simv +0in_disable_fx_force
$0in_never_invert_metastable_signals Option
This option does not impact the force statements. It only changes the random number generator during simulation to always produce 0. Hence, the forced values are supposed to be identical to the original values. The glue logic can produce data values different from the original RTL specially for Xs. Hence, this option can result in change in simulation behavior.
172
Sometimes a customer uses the $0in_never_invert_metastable_signals option while the chip is loading the configuration registers. During this phase, the users has external circuitry to ensure that the different clocks are in sync. Next, the user enables CDC-FX by calling the $0in_randomly_invert_metastable_signals option. Also, the user has the $0in_always_invert_metastable_signals option to get better coverage if the number of metastable cycles is limited in the testbench.
VHDL Glue Logic Option Impact

The differences between the following options for VHDL glue logic are described in this section: ZI_NO_CDC_FORCE +0in_disable_fx_force $0in_never_invert_metastable_signals
The VHDL glue logic is as follows:

module zi_xmr_wrap; ìfdef ZI_NO_CDC_FORCE èlse zi_cdc_fx_force_sigs_0_entity #(.prefix("/tb/U1")) i1(); èndif endmodule
The options have the following impact.
ZI_NO_CDC_FORCE Option
Same behavior as Verilog (see ZI_NO_CDC_FORCE Option on page 172).
+0in_disable_fx_force Option
No impact for VHDL.
$0in_never_invert_metastable_signals Option
Same behavior as Verilog (see $0in_never_invert_metastable_signals Option on page 173).
173
CDC-FX Metastability Injection Metastability Injector Simulation Methodology
Metastability Injector Simulation Methodology

Metastability injectors in simulation uncover problems that arise from CDC metastability effects. These problems cannot be detected with basic simulation. Therefore, use the following methodology: 1. Start with a clean design.
o o
End-to-end tests run completely, without errors. If the design is instrumented with assertions, then plain simulation with assertions does not violate any assertions.
2. Run metastability injected simulation. 3. Use the 0in_cdc database viewer to analyze the results.
o
End-to-end test errors indicate receive logic is not tolerant of CDC metastability effects. Assertion failures indicate receive logic is not tolerant of CDC metastability effects. The cdc_fx checker coverage shows how completely each metastability injector covers the range of metastability effects during simulation.
o o
4. If needed, suppress some checkers and rerun metastability injected simulation. 5. Debug any cdc_fx checker firings. The cdc_fx checker has three transfer protocol checks that by default are turned off.
o
The cdc_fx check ensures that the data input to the receive register does not change in a cycle for which the transmit/receive clock edges align (that is, metastability is not possible for the corresponding register). The generated cdc_fx directives for the CDC data buses are automatically included by the tool. The glitch_caught check ensures that metastability injection does not catch a glitch if it is not detected by simulation. The glitch_swallowed check ensures that metastability injection does not swallow a glitch if it is detected by simulation.
Assertion Violations
If metastability injected simulation produces assertion violations (i.e., check firings), then you can analyze them the same as you do firings from basic simulation with assertions (see Figure 5-7 on page 175). Use the 0in_cdc viewer to examine details of the check firings and to display their waveforms. These violations are caused by design defects in the fan-outs of the receiving registers that make the circuit intolerant of random delays in the transmission of their driving CDC signals.
174
Figure 5-7. CDC GUI with Merged CDC_FX Results
The cdc_fx checker entries in the viewer database provide a variety of information about the metastability injectors during simulation. Each cdc_fx checker maintains coverage information about its performance during simulation. The checker entry in the simulation database (0in_checksim.db) has this information. The cdc_fx checkers cdc_fx check fires if the active edge of the transmit clock is in the metastability window of the receive clock and the transmit data change in this window. These cycles are candidates for metastability injection. The Metastable Cycles evaluation statistic increments each cycle this happens. Normally, this is not problematic. The logic in the fan-out of the receive register is expected to tolerate this situation. Some design styles have transmitting circuitry that presumes data is stable during cycles when both clock edges occur in the metastability window. No metastability can occur and the receiving logic does not need to account for CDC metastability effects. In such cases, you can use the cdc_fx check to verify the transmit data remains stable when metastability can occur. Notice in the Checker Report that the -rx_q field identifies the register output from the original circuit that is replaced in the new circuit (remodeled with the metastability injection logic) with the rx_q output from the checker. When ccl compiles the design for simulation, each cdc_fx checker is connected so the output from the transmit register is routed to the cdc_fx checker and the rx_q output from the checker drives the load from the original receive register. For most cycles, the transmit data is latched by the checker and passed through to the rx_q output when the receive clock activates. This mimics the behavior of the original circuit under normal simulation.
175
But, when the checker determines it should inject metastability, randomly selected bits of the rx_q output are inverted. The rx_q output reflects a corrupted value unrelated to the original transmission. This condition emulates data transmission metastability from crossing clock domains. The circuit must be immune to these effects.
176
Chapter 6 Command Reference

This command reference consists of five sections: CDC Schemes Control: two_dff, two_dff_phase, four_latch, pulse_sync, shift_reg, dff_sync_gated_clk, custom_sync, async_reset, async_reset_no_sync and no_sync. Data: bus_two_dff, bus_two_dff_phase, bus_four_latch, bus_dff_sync_gated_clk, bus_shift_reg, bus_custom_sync and multi_bits. Control/data: dmux, simple_dmux, multi_sync_mux_select, handshake, fifo, memory_sync and custom_sync_with_crossing. Potential problems: combo_logic, port_constraint_mismatch, reconvergence, single_source_reconvergence, redundant, series_redundant, fanin_different_clks and blackbox.
Global Directives Clocks and domains: set_cdc_clock, and set_cdc_port_domain. CDC analysis: set_reset, set_cdc_preference, set_cdc_reconvergence, set_cdc_hier_preference, set_mode and set_mode_control. CDC schemes: set_cdc_synchronizer, set_cdc_signal and set_cdc_report, set_cdc_fifo, set_cdc_fifo_preference, set_cdc_handshake_preference,. Checker promotion: set_cdc_protocol. CDC-FX: set_cdc_fx_timescale, set_cdc_fx_metastability_window and set_cdc_fx_check. Netlist generation: set_black_box, set_memory, set_constant and set_constant_propagation. Checker generation: default_reset, use_synthesis_case_directives, exclude_checker, include_checker, disable_checker, disable_used, set_severity, set_checker_action, checker_firing_keyword and create_wire.
Shell Commands Utilities invoked from the system shell: vlib, vmap, vcom, vlog, verror, vdir, vdel, 0in, 0in_cdc and 0in_db2ucdb.
177
Command Reference
0in Shell Commands Utilities invoked from the 0in shell:cdc and cwhelp. Protocol/FX Checkers CDC protocol checkers: cdc_dsel, cdc_fifo, cdc_glitch, cdc_hamming_distance_one, cdc_handshake_data, cdc_sample and cdc_sync. CDC-FX checkers: cdc_fx and cdc_custom_fx.
178
Command Reference CDC Schemes
CDC Schemes
CDC analysis identifies logic patterns relevant to CDC verification. Groups of related patterns identify specific classes of situations called CDC schemes. Each CDC scheme represents a specific type of CDC synchronizer architecture or a potential CDC issue. This chapter consists of the data sheets for the various CDC schemes (see Table 6-1). Each data sheet has the following information: General Information 0in_cdc message, schematic representation, description, and the following information: Crossing Type signal, data bus, both, or not applicable. Default Severity evaluation, caution, or violation. Promoted Checker CDC checker promoted to check the associated transfer protocol. Examples examples of global directives that change the default behavior.
In addition, some data sheets show the following: Potential Problems information about consequences you should consider. Notes additional information relevant to the scheme. Table 6-1. CDC Schemes
Type Scheme ID TWO DFF SYNCHRONIZER TWO DFF SYNCHRONIZER OPPOSITE POLARITY FOUR LATCH SYNCHRONIZER PULSE SYNC SHIFT REG Description Default Severity
Signal two_dff Synchronizer two_dff_phase
Two or more in-phase flip-flops. evaluation Two out-of-phase flip-flops. caution
four_latch pulse_sync shift_reg dff_sync_gated_clk async_reset async_reset_no_sync
Four or more cascaded latches. evaluation Pulse. Shift register. evaluation evaluation
DFF GATED SYNC Two flip-flops with gated clock. caution ASYNC RESET Asynchronous reset scheme. evaluation violation
ASYNC RESET NO Asynchronous reset SYNC scheme.with a missing synchronizer MISSING SYNCHRONIZER Missing synchronizer
no_sync
violation or caution
179
Command Reference CDC Schemes Default Severity evaluation
Type
Scheme custom_sync
ID CUSTOM BUS SYNC BUS SYNC BUS SYNC BUS DFF GATED SYNC BUS SHIFT REG MULTIPLE BITS BUS CUSTOM DMUX SIMPLE DMUX MULTIPLE SYNCHRONIZERS AT DMUX HANDSHAKE FIFO MEMORY SYNC CUSTOM CUSTOM WITH CROSSING COMBO LOGIC
Description Custom control signal synchronizer.
Data bus_two_dff Synchronizer bus_two_dff_phase bus_four_latch bus_dff_sync_gated_clk bus_shift_reg multi_bits bus_custom_sync Signal and dmux Data Synchronizer simple_dmux multi_sync_mux_select
Two or more in-phase flip-flops. evaluation Two out-of-phase flip-flops. caution
Four or more cascaded latches. evaluation Two flip-flops with gated clock. caution Shift register. evaluation violation Custom bus synchronizer MUX enable. MUX enable. Multiple MUXes. evaluation or violation caution caution caution
handshake fifo memory_sync custom_sync custom_sync_with_crossing Potential Problem combo_logic reconvergence
MUX enable with handshaking evaluation FIFO. 2D array. Custom. Custom with internal crossing. Combinational logic on a synchronization path. evaluation caution evaluation or violation evaluation violation caution
RECONVERGENCE Reconvergent CDC signals.
single_source_reconvergence SSR redundant series_redundant fanin_different_clks REDUNDANT SERIES REDUNDANT
Reconvergent CDC signals from violation a single source. CDC signal drives multiple synchronizers. Custom synchronizers connected in series caution caution
FANIN LOGIC Fan-in logic from multiple clock violation FROM DIFFERENT domains. CLOCKS BLACKBOX Crossing drives an instance of an inferred black box. caution
blackbox
180
Command Reference async_reset
async_reset
ASYNC RESET: Signal feeds to the asynchronous reset port of the receiving register.
tx_rst tx_sig rst 1'b1 DFF rst DFF rx_rst
tx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using an asynchronous reset is a standard method of synchronizing a 1-bit signal. To detect this scheme, you must identify resets in the design (tx_rst and rx_rst) by specifying set_reset. Crossing Type 1-bit signal Default Severity evaluation Promoted Checker cdc_sync (if enabled, see set_cdc_preference on page 283). Examples 1. Following is an example to turn severity to violation.
// 0in set_cdc_report -scheme async_reset -severity violation
2. ASYNC_RESET scheme that uses an asynchronous reset input to drive the reset pins of the synchronizer. Synchronizer input is tied high.
always @(posedge rx_clk,negedge tx_sig) rx domain reset if (!tx_sig) begin s0 <= 1b0; tx_sig rst rst s1 <= 1b0; s1 1'b1 end else begin high s0 <= 1b1; tx_clk rx_clk s1 <= s0; end Evaluations ================================================================= Asynchronous reset synchronization. (async_reset) ----------------------------------------------------------------tx_clk : start : tx_sig (async_reset1.v : 9) rx_clk : end : s0 (async_reset1.v : 10) (ID:async_reset_95442)
181
Command Reference async_reset
3. ASYNC_RESET scheme that uses an asynchronous reset input to drive the reset pins of the synchronizer. Synchronizer input is tied low.
always @(posedge rx_clk,negedge tx_sig) rx domain reset if (tx_sig) begin s0 <= 1b1; tx_sig rx_rst set set s1 s1 <= 1b1; s0 1'b0 end else begin low s0 <= 1b0; tx_clk rx_clk s1 <= s0; end assign rx_rst = s1 | tx_sig; Evaluations ================================================================= Asynchronous reset synchronization. (async_reset) ----------------------------------------------------------------tx_clk : start : tx_sig (async_reset1.v : 9) rx_clk : end : s0 (async_reset1.v : 10) (ID:async_reset_95442)
4. ASYNC_RESET scheme that uses an asynchronous reset input to drive the D input of the first DFF in the synchronizer and the reset pins of the Rx domain registers.
always s0 s1 end assign @(posedge rx_clk) begin <= tx_sig; <= s0; rx_rst = s1 | tx_sig;
tx_clk rx_clk rx domain reset tx_sig s0 s1 rx_rst
Evaluations ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------tx_clk : start : tx_sig (async_reset3.v : 9) rx_clk : end : s0 (async_reset3.v : 10) (ID:two_dff_32868) Asynchronous reset synchronization. (async_reset) ----------------------------------------------------------------tx_clk : start : tx_sig (async_reset3.v : 9) rx_clk : end : rx_rst (async_reset3.v : 23) (ID: async_reset_)
5. ASYNC_RESET scheme that uses an asynchronous reset input to drive the reset pins of the synchronizer, the D input of the first DFF in the synchronizer and the reset pins of the Rx domain registers.
always @(posedge rx_clk,negedge tx_sig) if (! tx_sig) {s1, s0} <= 2b00; else {s1, s0} <= {s0, tx_sig}; assign rx_rst = s1 & tx_sig;
rx domain reset tx_sig rst s0 rst rx_rst s1
tx_clk
rx_clk
182
Command Reference async_reset Evaluations ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------tx_clk : start : tx_sig async_reset4.v : 9) rx_clk : end : s0 async_reset4.v : 10) (ID:two_dff_32868) Asynchronous reset synchronization. (async_reset) ----------------------------------------------------------------tx_clk : start : tx_sig async_reset4.v : 9) rx_clk : end : s0 async_reset4.v : 10) (ID:async_reset_95442)
183
Command Reference async_reset_no_sync
async_reset_no_sync
ASYNC RESET NO SYNC: Signal that feeds to the asynchronous reset port of the receiving register has no synchronizer.
tx_sig missing reset synchronizer tx_clk 1'b1 DFF rx_clk rx_sig
Tx Clock Domain
tx_sig 1'b1 DFF tx_clk
Rx Clock Domain
incorrect reset synchronizer rx_clk rx_reset
Tx Clock Domain
Rx Clock Domain
Synchronization using an asynchronous reset is a standard method of synchronizing a 1-bit signal, but the receiving register output must drive a control signal synchronizer before driving receive domain logic. To detect this scheme, you must identify resets in the design by specifying set_reset. Crossing Type 1-bit signal Default Severity violation Promoted Checker cdc_sync (if enabled, see set_cdc_preference on page 283). Example 1. Following example turns reporting off:
// 0in set_cdc_report scheme async_reset_no_sync severity off
2. Tx signal is used as an unsynchronized reset in the Rx domain.

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

// Reset triggered by tx_clk always @(posedge tx_clk) tx_sig <= rst;
improperly synchronized reset tx_sig 1'b1 rst rx_reset rst
// Improperly synchronized reset used // in Rx domain always @(posedge rx_clk,negedge tx_sig) if (!tx_sig) rx_reset <= 1b0; tx_clk rx_clk else rx_reset <= 1b1; Violations ================================================================= Asynchronous reset does not have proper synchronization. (async_reset_no_sync) ----------------------------------------------------------------tx_clk : start : tx_sig (test2.v : 9) rx_clk : end : rx_reset (test.v : 10) (ID:async_reset_no_sync_85287)
185
Command Reference blackbox
blackbox
BLACKBOX: Crossing drives an instance of an inferred black box.
tx_sig inferred black box tx_clk rx_clk
Tx Clock Domain
Rx Clock Domain
Inferred black boxes are modules/entities containing unsupported constructs, that are not explicitly declared as black boxes (with the set_black_box directive). Crossing Type control signal or data bus Default Severity caution Promoted Checker none Examples 1. Following is an example to turn severity to violation:
// 0in set_cdc_report scheme blackbox severity violation
2. Following is an example of the paths for a black box crossing (from 0in_cdc.rpt):
Cautions ================================================================= Blackbox Crossing. (blackbox) ----------------------------------------------------------------clk1 : start : u0.q (/u/bbox/dut.v : 41) <clock N/A>: end : u1.b (/u/bbox/dut.v : 12) (ID:blackbox_52) via: u0.q via: u1.b <clock N/A>: end : u1.c (/u/bbox/dut.v : 12) (ID:blackbox_53) via : u0.q via : u1.c
Following is a directive that identifies the port domains of the inferred black box:
// Blackbox ports // 0in set_cdc_port_domain b c -clock clk -module bbox_module
186
With this directive, the port domains of the black box ports are identified in 0in_cdc.rpt:
Cautions ================================================================= Blackbox Crossing. (blackbox) ----------------------------------------------------------------clk1 : start : u0.q (/u/bbox/dut.v : 41) clk3: end : u1.b (/u/bbox/dut.v : 12) (ID:blackbox_52) via: u0.q clk3: end : u1.c (/u/bbox/dut.v : 12) (ID:blackbox_53) via: u0.q
In this case, the port domain of the driver (u1.q) was set by a set_cdc_port_domain directive:
// 0in set_cdc_port_domain q -clock clk3
3. Following example shows an instance (BB) of a module (black_box) that cdc has inferred to be a black box.
rst din0 tx_clk din1 din2 din3 reset datain0 dataout datain1 datain2 datain3 clock rx_clk dout instance of an inferred black box
BB
status statout
By default, the datain inputs are assumed to be in different clock domains. Similarly, dout and stout are assumed to be in different clock domains. To make static CDC analysis more accurate and to reduce the clock domain complexity, identify the port domains of the black box data ports. For example:
// // // // // Input port domains 0in set_cdc_port_domain 0in set_cdc_port_domain 0in set_cdc_port_domain 0in set_cdc_port_domain datain0 datain1 datain2 datain3 -async -async -clock -clock -module black_box -module black_box clock -module black_box clock -module black_box
// Outrput port domains // 0in set_cdc_port_domain dataout -clock clock -module black_box // 0in set_cdc_port_domain status -clock clock -module black_box
Note that these are the port domains (not clock domains) for the data ports. Domains are identified according to the black boxs clock pins (not external clock signals).
187
Cautions ================================================================= Multiple-bit signal across clock domain boundary. (multi_bits) ----------------------------------------------------------------rx_clk : start : BB.dataout (blackbox.v : 40) tx_clk : end : dout (blackbox.v : 21) (ID:multi_bits_47389) Blackbox Crossing. (blackbox) ----------------------------------------------------------------tx_clk : start : din1 (blackbox.v : 25) <clock N/A> : end : BB.datain1 (blackbox.v : 40)(ID:blackbox_12944) Evaluations ================================================================= Blackbox Crossing. (blackbox) ----------------------------------------------------------------tx_clk : start : din0 (blackbox.v : 24) <clock N/A> : end : BB.datain0 (blackbox.v : 40)(ID:blackbox_48560)
188
Command Reference bus_custom_sync
bus_custom_sync
BUS_CUSTOM: Multiple-bit signal synchronized by custom CDC synchronizer.
gray encoder tx_data custom synchronizer rx_data gray decoder
tx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain
Custom synchronizers are instances of modules declared as custom synchronizers with the set_cdc_synchronizer custom directive. The bus_custom_sync scheme identifies multiple-bit custom synchronizers where the clock domain crossing is external to the synchronizer itself. Crossing Type data bus Default Severity evaluation (if all the ports are specified with set_cdc_port_domain) or violation. Promoted Checker none Examples 1. Following is an example to specify the cust_sync module with clock pin clk as a custom synchronizer:
//0in set_cdc_synchronizer custom -module cust_sync //0in set_cdc_port_domain d -async -clock clk -module cust_sync
The set_cdc_port_domain directive identifies d as an asynchronous port and directs CDC analysis to use the clk port to identify the receive clock reported for clock domain crossings though cust_sync. 2. Following is an example to turn severity to caution:
// 0in set_cdc_report -scheme bus_custom_sync -severity caution
189
Command Reference bus_custom_sync
3. Custom synchronizer for the Tx signal:

// Custom sync instance syncA S (rx_clk, tx_sig, rx_sig);
data tx_sig din dout rx_sig syncA clk rx_clk
always @(posedge tx_clk) tx_clk tx_sig <= data; Evaluations ================================================================= Custom CDC Scheme: syncA (custom_sync) ----------------------------------------------------------------tx_clk : start : tx_sig (custom_sync.v : 21) rx_clk : end : S.din (custom_sync.v : 29) (ID:custom_sync_5359)
Use the set_cdc_synchronizer custom directive to identify custom synchronizer modules/entities:

// 0in set_cdc_synchonizer custom syncA
Custom synchronizers are considered inferred black boxes for CDC analysis, so you must specify their port information:
/* 0in set_cdc_port_domain -input din -async -clock rx_clk -module syncA */ /* 0in set_cdc_port_domain -output dout -clock rx_clock -module syncA */
Potential Problem CDC analysis does not promote a checker for this scheme. You should implement a transfer protocol checking scheme using one or more checkers.
190
Command Reference bus_dff_sync_gated_clk
bus_dff_sync_gated_clk
BUS DFF GATED SYNC: Multiple-bit signals synchronized with DFF synchronizer with gated clock.
tx_data DFF en_rx_clk rx_clk DFF rx_data
tx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal, but one of the flip-flops is clocked by a gated version of the receive clock. Crossing Type multiple-bit data bus Default Severity caution Promoted Checker
cdc_hamming_distance_one
(cdc_hamming1)
Examples 1. Following is an example to turn severity to caution:

/* 0in set_cdc_report -scheme bus_dff_sync_gated_clk -severity caution */
2. Following is an example to turn off reporting for a particular CDC signal:

/* 0in set_cdc_report -scheme bus_dff_sync_gated_clk -severity off -from in1 -to r1 */
3. Bus 2 DFF synchronizer has one FF clocked by a gated version of the Rx clock.:
//gated Rx clock assign gclk = rx_clk & en; // 1st flip-flop triggered by // the gated clock always @(posedge gclk) sync1 <= tx_reg; // 2nd flip-flop triggered by // the Rx clock always @(posedge rx_clk) sync2 <= sync1;
tx_reg sync1 sync2
tx_clk
gclk
en
rx_clk
191
Command Reference bus_dff_sync_gated_clk Cautions ================================================================= Multiple-bits signals synchronized with DFF synchronizer with gated clock. (bus_dff_sync_gated_clk) ----------------------------------------------------------------tx_clk : start : tx_reg (test2.v : 12) rx_clk : end : sync1 (test2.v : 12)(ID:bus_dff_sync_gated_clk_8918)
192
Command Reference bus_four_latch
bus_four_latch
BUS SYNC: Multiple-bit signal synchronized by latch synchronizer.
tx_data gray encoder tx_clk rx_data latch latch latch latch latch rx_clk gray decoder
Tx Clock Domain
Rx Clock Domain
Synchronization using four latches is a standard method of synchronizing a gray-coded data bus. Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any cycle, so a four-latch synchronizer (typically used for 1-bit signal crossings) is appropriate if the data changes only at the frequency of the receiving domain. Crossing Type multiple-bit data bus Default Severity evaluation Promoted Checker cdc_hamming_distance_one (cdc_hammimg1) Examples 1. Following is an example to turn severity to violation:
// 0in set_cdc_report scheme bus_four_latch severity violation
2. Following is an example to turn off promotion:

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

// Synchronized multibit variable q /* 0in cdc_hamming1 -tx_clock clk3 -tx_var r1 -name cdc_data_0 -module test -inferred
*/
193
Command Reference bus_four_latch
4. Bus four-latch synchronizer:

always @ (*) if (rx_clk) begin sync1 <= tx_sig;// 1st latch tx_sig rx_sig sync3 <= sync2; // 3rd latch end tx_clk rx_clk else begin sync2 <= sync1; // 2nd latch rx_sig <= sync3;// 4th latch end Evaluations ================================================================= Multiple-bit signal synchronized by latch synchronizer (bus_four_latch) ----------------------------------------------------------------tx_clk : start: tx_sig (bus_four_latch.v : 8) rx_clk: end : sync1 (bus_four_latch.v : 8) (ID:bus_four_latch_51294) via : sync1
Potential Problem Four-latch synchronization of a data bus assumes the bus is gray-coded. Any data buses that cross clock domains that are not gray-coded should be identified as requiring complete data synchronization. Any of these crossings synchronized by four-latch synchronizers should be flagged as violations. To set these schemes to violations, use the set_cdc_report directive.
/* 0in set_cdc_report -scheme bus_four_latch -tx_clock clk_a -severity violation */
194
Command Reference bus_shift_reg
bus_shift_reg
SHIFT REG: Multiple-bit signal synchronized by shift-register synchronization.
tx_data shift register tx_clk rx_clk rx_data
Tx Clock Domain
Rx Clock Domain
Synchronization using a shift register is a standard method of synchronizing a gray-coded data bus. Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any cycle, so a shift register (typically used for 1-bit signal crossings) is appropriate if the data changes only at the frequency of the receiving domain. This CDC scheme is equivalent to synchronization with two or more in-phase flip-flops. Crossing Type multiple-bit data bus Default Severity evaluation Promoted Checker
cdc_hamming_distance_one (cdc_hamming1)
Examples 1. Following is an example to turn severity to violation:

// 0in set_cdc_report scheme bus_shift_reg severity violation

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

/* 0in cdc_hamming_distance_one -tx_var u0.q -tx_clock clk1 -name cdc_hamming1_0 -module dut -inferred
*/
195
Command Reference bus_shift_reg
4. Bus shift register synchronizer:

// 2-level shift register always @ (posedge rx_clk) {sync[1], sync[0]} <= {sync[0], tx_data};
[1] tx_data [0] shift register sync[1] sync[0] synchronized data
tx_clk
rx_clk
Evaluations ================================================================= Multiple-bit signal synchronized by shift-register synchronizer (bus_shift_reg) ----------------------------------------------------------------tx_clk : start : tx_data (bus_shift_reg.v : 10) rx_clk : end : sync[0] (bus_shift_reg.v : 19 (ID:bus_shift_reg_99229)
196
Command Reference bus_two_dff
bus_two_dff
BUS SYNC: Multiple-bit signal synchronized by DFF synchronizer.
gray encoder tx_data DFF tx_clk DFF rx_clk rx_data gray decoder
Tx Clock Domain
Rx Clock Domain
Synchronization using two flip-flops is a standard method of synchronizing a gray-coded data bus. Gray coding (i.e., hamming distance 1) assures that only one bit of data changes in any cycle, so a 2DFF synchronizer (typically used for 1-bit signal crossings) is appropriate if the data changes only at the frequency of the receiving domain. Crossing Type multiple-bit data bus Default Severity evaluation Promoted Checker cdc_hamming_distance_one (cdc_hammimg1) Examples 1. Following is an example to turn severity to violation:
// 0in set_cdc_report scheme bus_two_dff severity violation

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

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

reg [width-1:0] tx_reg, rx_reg; reg [width-1:0] sync1, sync2; always @(posedge rx_clk) begin sync1 <= tx_reg; // 1st FF sync2 <= sync1; // 2nd FF end
tx_reg sync1 sync2
tx_clk
rx_clk
197
Command Reference bus_two_dff Evaluations ================================================================= Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------tx_clk : start : tx_reg (bus_two_dff.v : 11) rx_clk : end : sync1 (bus_two_dff.v : 11) (ID:bus_two_dff_8942)
5. Bus 2 DFF synchronizer with enable. CDC analysis only recognizes this instance as a bus_two_dff scheme if set_cdc_preference -allow_enable_in_sync is specified.
reg [width-1:0] tx_reg, rx_reg; reg [width-1:0] sync1, sync2;
tx_reg enable sync1 sync2
EN EN always @(posedge rx_clk) if (enable) begin tx_clk rx_clk sync1 <= tx_reg; // 1st FF sync2 <= sync1; // 2nd FF end Evaluations ================================================================= Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------tx_clk : start : tx_reg (bus_two_dff_en.v : 11) rx_clk : end : sync1 (bus_two_dff_en.v : 11) (ID:bus_two_dff_8942)
Potential Problem The 2DFF synchronization of a data bus assumes the bus is gray-coded. Any data buses that cross clock domains that are not gray-coded should be identified as requiring complete data synchronization. Any of these crossings synchronized by 2DFF synchronizers should be flagged as violations. To set these schemes to violations, use the set_cdc_report directive.
/* 0in set_cdc_report -scheme bus_two_dff -tx_clock clk_a -severity violation */
Notes If you use a DFF synchronization scheme that has more than two flip-flops, then you can get CDC analysis to recognize the scheme by specifying a set_cdc_synchronizer global directive. For example, the following global CDC directive identifies 4 DFF synchronizers as valid two_dff schemes for CDC paths from the tx_clk domain to the rx_clk domain:
/* 0in set_cdc_synchronizer dff -level 4 -tx_clock tx_clk -rx_clock rx_clk */
198
Command Reference bus_two_dff_phase
bus_two_dff_phase
BUS SYNC: Multiple-bit signal synchronized by DFF synchronizer and multiple-bit signal synchronized by DFF of opposite clock polarity.
gray encoder tx_data DFF tx_clk DFF rx_clk rx_data gray decoder
Tx Clock Domain
Rx Clock Domain
Synchronization using two opposite polarity flip-flops reduces the time the signal takes to settle. When using this synchronization scheme, be sure the MTBF is acceptable. When used to synchronize a data bus, the bus should be gray-coded (i.e., have hamming distance 1), which assures that only one bit of data changes in any cycle, and the data should change only at the frequency of the receiving domain. Crossing Type multiple-bit data bus Default Severity caution Promoted Checker cdc_hamming_distance_one (cdc_hamming1) Example Following is an example to turn severity to caution:
// 0in set_cdc_report scheme bus_two_dff_phase severity caution
Potential Problems 1. Synchronization of a data bus using two opposite polarity DFFs assumes the bus is gray-coded. 2. Bus 2 DFF phase synchronizer has one FF clocked by a clock with the opposite polarity of the Rx clock:
reg [width-1:0] tx_reg, rx_reg; reg [width-1:0] sync1, sync2; always @(negedge rx_clk) sync1 <= tx_reg; // 1st FF
tx_clk tx_reg sync1 sync2
rx_clk
always @(posedge rx_clk) sync2 <= sync1; // 2nd FF
199
Command Reference bus_two_dff_phase Cautions ================================================================= Multiple-bits signal synchronized by DFF of opposite clock polarity. (bus_two_dff_phase) ----------------------------------------------------------------tx_clk : start : tx_reg (test.v : 11) rx_clk : end : sync1 (test.v : 11) (ID:bus_two_dff_phase_57873)
3. Bus 2 DFF phase synchronizer with enables has one FF clocked by a clock with the opposite polarity of the Rx clock. CDC analysis only recognizes this instance as a bus_two_dff_phase scheme if set_cdc_preference -allow_enable_in_sync is specified.
reg [width-1:0] tx_reg, rx_reg; reg [width-1:0] sync1, sync2; always @(negedge rx_clk) if (enable) sync1 <= tx_reg; always @(posedge rx_clk) if (enable) sync2 <= sync1;
tx_reg enable EN sync1 EN sync2
tx_clk
rx_clk
Cautions ================================================================= Multiple-bits signal synchronized by DFF of opposite clock polarity. (bus_two_dff_phase) ----------------------------------------------------------------tx_clk : start : tx_reg (test.v : 11) rx_clk : end : sync1 (test.v : 11) (ID:bus_two_dff_phase_57873)
200
Command Reference combo_logic
combo_logic
COMBO LOGIC: Combinational logic before synchronizer.
combinational logic tx_data synchronizer tx_clk rx_clk rx_data
Tx Clock Domain
Rx Clock Domain
Combinational logic in a synchronization path is a significant problem for synchronized signals, because the data used to determine an acceptable failure rate on synchronization paths assumes a single transition on a CDC signal during each clock period. But if combinational logic is placed on the path, then this assumption is false because of glitch propagation. As a result, the error rate rises significantly. To address this problem, you should remove all combinational logic from the logic path. Static CDC analysis checks for combo logic in every CDC path that has a detected synchronizer. For some cases, this combinational logic will be constant during normal operation, so glitches cannot be generated. For example, the combinational logic might consist of test MUXes or configuration logic. To remove the violation, identify the signal feeding that logic as a constant value using set_constant. Crossing Type control signal or data bus Default Severity violation Promoted Checker cdc_glitch Examples 1. Following is an example to specify that the MUX select in the combinational logic feeding a CDC signal is constant 1'b0 (so the crossing can be checked for proper synchronization):
// 0in set_constant test_sel 1'b0
2. Following is an example to turn severity for the CDC signal en to caution:

/* 0in set_cdc_report -scheme combo_logic -severity caution -from dut.U0.en
201
Command Reference combo_logic
3. Combinational logic between the Tx signal and a 2DFF synchronizer:

always @ (posedge rx_clk) begin s1 <= tx_sig & din; s2 <= s1; end
din tx_sig tx_clk DFF s1 DFF rx_clk s2
Violations ================================================================= Combinational logic before synchronizer. (combo_logic) ----------------------------------------------------------------tx_clk : start : tx_reg (combo_logic.v : 8) rx_clk : end : sync1 (combo_logic.v : 8) (ID:combo_logic_57762) Base Type : TWO DFF SYNCHRONIZER
The report for this violation shows the base type CDC scheme identified by CDC analysis (TWO DFF SYNCHRONIZER). To remove this violationand instead report the crossing as a 2DFF schemeyou can specify that din is stable. That is, it is properly synchronized in the Rx domain:
// 0in set_cdc_signal din -stable
202
Command Reference custom_sync
custom_sync
CUSTOM: Single-bit signal synchronized by custom CDC synchronizer.
tx_sig custom synchronizer rx_sig
tx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain
Custom synchronizers are instances of modules declared as custom synchronizers with the set_cdc_synchronizer custom directive. The custom_sync scheme identifies single-bit custom synchronizers where the clock domain crossing is external to the synchronizer itself. Crossing Type control signal Default Severity violation or evaluation (if input port is asynchronous) Promoted Checker none Examples 1. Following is an example to specify the cust_sync module with clock pin clk as a custom synchronizer:
//0in set_cdc_synchronizer custom -module cust_sync //0in set_cdc_port_domain d -async -clock clk -module cust_sync
The set_cdc_port_domain directive identifies d as an asynchronous port and directs CDC analysis to use the clk port to identify the receive clock reported for clock domain crossings though cust_sync. 2. Following is an example to turn severity to caution:
// 0in set_cdc_report -scheme custom_sync -severity caution
203
Command Reference custom_sync
3. Custom synchronizer for the Tx signal:

// Custom sync instance syncA S (rx_clk, tx_sig, rx_sig);
data tx_sig din dout rx_sig syncA clk rx_clk
always @(posedge tx_clk) tx_clk tx_sig <= data; Violations ================================================================= Custom CDC Scheme: syncA (custom_sync) ----------------------------------------------------------------tx_clk : start : tx_sig (custom_sync.v : 21) rx_clk : end : S.din (custom_sync.v : 29) (ID:custom_sync_5359)

// 0in set_cdc_synchonizer custom syncA
/* 0in set_cdc_port_domain -input din -async -clock rx_clk -module syncA */ /* 0in set_cdc_port_domain -output dout -clock rx_clock -module syncA */
204
Command Reference custom_sync_with_crossing
custom_sync_with_crossing
CUSTOM WITH CROSSING: Custom CDC synchronizer with an internal clock domain crossing.
custom synchronizer tx_data rx_data
tx_clk
rx_clk internal crossing
Tx Clock Domain
Rx Clock Domain
Custom synchronizers are instances of modules declared as custom synchronizers with the set_cdc_synchronizer custom directive. The custom_sync_with_crossing scheme identifies custom synchronizers where the clock domain crossing is internal to the synchronizer itself. To identify this type of custom synchronizer, you must identify a transmit clock port and a receive clock port using the set_cdc_port_domain directive for the custom synchronizer module. Every other signal/data port must be identified with either a transmit clock or a receive clock. If a port is identified as an -async port, the synchronizer is reported as a simple custom_sync scheme. Crossing Type control signal or data bus Default Severity evaluation Promoted Checker none Examples 1. Custom synchronizer module with crossing:
RST_A IN SYNC_VX RST_B OUT
CLKA
CLKB
// // // // //
0in 0in 0in 0in 0in
set_cdc_synchronizer custom -module SYNC_VX set_cdc_port_domain IN -tx_clock CLKA -module SYNC_VX set_cdc_port_domain RST_A -clock CLKA -module SYNC_VX set_cdc_port_domain OUT -rx_clock CLKB -module SYNC_VX set_cdc_port_domain RST_B -clock CLKB -module SYNC_VX
205
Command Reference custom_sync_with_crossing
2. Custom synchronizer with an internal crossing:

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

// 0in set_cdc_synchonizer custom syncC
// 0in set_cdc_port_domain din -tx_clock tclk -module syncC // 0in set_cdc_port_domain dout -rx_clock rclk -module syncC
206
Command Reference dff_sync_gated_clk
dff_sync_gated_clk
DFF GATED SYNC: DFF synchronizer with gated clock.
tx_sig DFF en_rx_clk rx_clk DFF rx_sig
tx_clk
Tx Clock Domain
Rx Clock Domain
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal. Crossing Type 1-bit signal Default Severity caution Promoted Checker cdc_sync Examples 1. Following is an example to turn severity to caution:
// 0in set_cdc_report scheme dff_sync_gated_clk severity caution
2. Following is an example to turn off reporting for a particular CDC signal:

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

// gated clock expression tx_sig sync2 sync1 assign gclk = rx_clk & clk_en; DFF DFF always @(posedge gclk) sync1 <= tx_sig; // 1st DFF rx_clk tx_clk always @(posedge rx_clk) clk_en sync2 <= sync1; // 2nd DFF Cautions ================================================================= DFF synchronizer with gated clock. (dff_sync_gated_clk) ----------------------------------------------------------------tx_clk: start: tx_reg (test4.v : 9) rx_clk: end: sync1 (test4.v: 9)(ID:dff_sync_gated_clk_11747)
207
Command Reference dmux
dmux
DMUX: DMUX synchronization.
tx_data MUX rx_data
Tx Clock Domain
Rx Clock Domain
Synchronization using a DMUX scheme is a standard method of synchronizing a data bus (or a control signal). The control signal can be synchronized by any of the following signal synchronizers: bus_dff_sync_gated_clk, bus_four_latch, bus_shift_reg, bus_two_dff, bus_two_dff_phase or two_dff_phase, dff_sync_gated_clk, four_latch. shift_reg, two_dff, pulse_sync and custom. Note The physical design of the MUX logic (that controls the path from the Tx register to the Rx registers) must not allow glitches at the input to an Rx register when the Tx register changes value. The DMUX scheme is similar to the SIMPLE_DMUX scheme. A SIMPLE_DMUX scheme is a strict version of MUX synchronization logic that requires a receive register, a MUX and feedback from the receiver to the MUX. A DMUX scheme is a generalized version of a MUX synchronization circuit. The MUXing logic can be any combinational logic and a feedback path from the Rx domain is not needed. Crossing Type synchronized control signal Default Severity caution Promoted Checker
cdc_dsel
Promoted CDC-FX Checker cdc_fx check is on by default.
208
Command Reference dmux
Examples 1. Following is an example to turn severity to evaluation:

// 0in set_cdc_report -scheme dmux -severity evaluation

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

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

always @(posedge rx_clk) begin: DMUX reg s1, rx_sel; s1 <= tx_sel; // 1st DFF rx_sel <= s1; // 2nd DFF if (rx_sel) rx_data <= tx_data; else rx_data <= rx_data ^ 4b1111; end
rx_data tx_data tx_clk tx_sel DFF 4b1111 MUX
s1 DFF rx_sel rx_clk
Cautions ================================================================= DMUX synchronization. (dmux) ----------------------------------------------------------------tx_clk : start : tx_data (dmux.v : 9) rx_clk : end : rx_data (dmux.v : 6) (ID:dmux_39152) Synchronizer ID : two_dff_44468 Evaluations ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------tx_clk : start : tx_sel (dmux.v : 10) rx_clk : end : DMUX.s1 (dmux.v : 22) (ID:two_dff_44468)
209
Command Reference fanin_different_clks
fanin_different_clks
FANIN LOGIC FROM DIFFERENT CLOCKS: Fan-in logic from multiple clock domains.
sig_a synchronizer clock_a clock_c sig_c
Clock Domain A
sig_b
Clock Domain C
clock_b
Clock Domain B
Fan-in logic for the input to a synchronizer must be synchronized to a single transmit clock domain for CDC analysis to properly identify the synchronization scheme. CDC analysis reports a FANIN LOGIC FROM DIFFERENT CLOCKS scheme if it finds two unsynchronized signals from different clock domains in the fan-in logic of the input to a synchronizer. For some cases, the signals from one domain are constant during normal operation. For example, the fan-in logic from one of the domains might consist of test MUXes or configuration logic. In some other cases, signals from one domain are marked as stable. How these cases are handled depends on the how many signals are in the fanin of the crossing: 2 signals in the fanin of the crossing If one signal is stable, it is not an instance of a fanin_different_clks or combo_logic scheme. Otherwise, if one signal has -severity off, then both signals are two individual combo_logic crossings. One signal is reported as a violation and the other is filtered.
more than 2 signals in the fanin of the crossing If one signal is stable or has -severity off: If the remaining signals start from the same domain, the crossing is reported as an instance of a combo_logic scheme. If the remaining signals start from more than one domain, the crossing is reported as an instance of a fanin_different_clks scheme. The filtered crossing is an instance of a filtered combo_logic scheme.
To remove the violation, do one of the following: 1. Keep one signal and use set_constant to identify the remaining signals coming from that logic as constants. The removed signals do not appear in the CDC report. 2. Keep one signal and use set_cdc_signal to identify the remaining signals coming from that logic as stable. If you specify set_cdc_preference -filtered_report, the removed
210
signals appear in the CDC report. The fanin_different_clks scheme is reported as the scheme detected for the remaining signal. When setting signals stable: CDC analysis assumes fan-in logic from a different clock domain is combo logic if the remaining signals are from the same domain. CDC analysis assumes a CDC signal has a valid synchronizer scheme if it is the only remaining signal after filtering the stable signals. The filtered signals also are reported as using the scheme. Filtered stable signals are reported as instances of the combo_logic scheme whenever fan-in is still detected after filtering them. Stable signals are reported in the CDC report if you specify set_cdc_preference filtered_report.
Crossing Type control signal or data bus Default Severity violation Promoted Checker
cdc_glitch
Examples 1.
sig_a
clock domain A
MUX sig_b synchronizer clock_b
clock_a
clock domain B
tsel
test_sel
clock_test
clock domain TEST
The above logic has a fanin_different_clks violation. To remove this violation, set test_sel in the TEST clock domain to the constant 1'b0:
// 0in set_constant test_sel 1'b0
211
2. Following is an example of reporting for fan-in logic from different clock domains:
Violations (1) ------------------------------------------Fan-in logic from different clock domain (1)
=========================================== Fan-in logic from different clock domain ------------------------------------------clk3: end: u1.q(t8.v: 30) clk1: start: u0.q(t8.v: 30) via: u0.q via: u1.d clk2: u5.q(t8.v: 30) via: u5.q via: u1.d
3. Fanin logic from 2 clock domains:

always @ (posedge tx1_clk) tx1_sig <= in1; always @ (posedge tx2_clk) tx2_sig <= in2; always @ (posedge rx_clk) begin sync0 <= tx1_sig | tx2_sig; sync1 <= sync0; end
tx1_sig DFF tx1_clk tx2_sig sync0 DFF rx_clk sync1
tx2_clk
Fanin logic from multiple clock domains. (fanin_different_clks) ----------------------------------------------------------------rx_clk : end : s0 (fanin_different_clks.v : 9) (ID:fanin_different_clks_84638) tx1_clk : start : tx1_sig (fanin_different_clks.v : 8) tx2_clk : start : tx2_sig (fanin_different_clks.v : 8)
212
Command Reference fifo
fifo
FIFO: FIFO Synchronization.
write address synchronizer rd_clock waddr_gray gray to binary wr_data fo_full wr_clock read address synchronizer wr_clock rd_clock waddr raddr raddr_gray gray to binary rd_data fo_empty
memory
FIFO write clock domain
FIFO read clock domain
By default, memories with read and write clocks are reported as memory_sync or multi_bits CDC schemes. Specifying the set_cdc_preference global directive with the -fifo_scheme option directs CDC static analysis to identify FIFO synchronization schemes like that shown above as FIFO schemes. FIFO synchronization is used to pass data between clock domains without synchronizing the data. However, to prevent FIFO overflow, transmit logic must know when the FIFO is full and to prevent FIFO underflow, the receive logic must know when the FIFO is empty. Transmit and receive logic calculates the number of entries in the FIFO from the read and write address pointers. In the FIFO synchronization scheme, the gray-coded values of the address pointers are synchronized to the clock domains of the opposite logic (read address pointer is synchronized to the transmit domain and the write address pointer is synchronized to the receive domain). By default, CDC static analysis identifies as FIFO schemes those schemes that have different combinations of binary and gray-coded address pointers, as shown below:
binary to gray waddr_gray write address synchronizer rd_clock waddr raddr fo_empty
wr_data fo_full wr_clock read address synchronizer wr_clock
memory
rd_data
rd_clock raddr_gray binary to gray
FIFO write clock domain
FIFO read clock domain
213
The templates CDC static analysis uses to detect FIFO schemes can be adjusted using the set_cdc_fifo_preference global variable (see page 267). The memories used in the FIFO schemes can be multidimensional arrays but they must be modeled as abstract memories (see set_memory on page 308). The memories also can be specified using register/latch files (see set_cdc_fifo on page 266). Crossing Type data bus Default Severity evaluation Promoted Checkers No checker is promoted for the FIFO protocol. A cdc_hamming_distance_one checker is promoted for each address synchronizer.

// 0in set_cdc_preference -fifo_scheme // 0in set_cdc_report scheme fifo severity caution
2. In the following CDC report entry, the two synchronizers are the read and the write pointer synchronizers:
Cautions ================================================================= FIFO synchronization. (fifo) ----------------------------------------------------------------sys_clk : start : inst_m1dsi_al_0.crs_async_fifo_0.data_q (/ASIC/lib/src/async_fifo_rtl.vhd : 34) tx_byte_hs_clk : end inst_m1dsi_al_0.crs_async_fifo_0.data2_q (/ASIC/lib/src/async_fifo_rtl.vhd : 37) (ID:fifo_85752) Read Synchronizer ID : bus_two_dff_48297 Write Synchronizer ID : bus_two_dff_55880
214
3. RAM-based FIFO synchronizer. CDC analysis only recognizes this instance as a fifo scheme if set_cdc_preference -fifo_scheme is specified.
reg [2:0] wr_sync1, wr_sync2, reg [2:0] rd_sync1, rd_sync2; reg [2:0] Mem [7:0]; always @(posedge wr_clk) begin Mem [wr_addr] <= wr_data; rd_sync1 <= rd_addr ; rd_sync2 <= rd_sync1; full <= ((wr_addr+1)==rd_sync2)?1:0; end
full
rd_sync2 wr_clk
rd_sync1
wr_data wr_addr memory
rd_addr rd_data rd_clk
always @(posedge rd_clk) begin wr_sync1 wr_sync2 empty rd_data <= Mem [rd_addr]; wr_sync1 <= wr_addr; wr_sync2 <= wr_sync1; empty <= (rd_addr == wr_sync2)? 1:0; end Evaluations ================================================================= FIFO synchronization. (fifo) ----------------------------------------------------------------wr_clk : start : Mem (fifo1.v : 11) (ID:fifo_10640) rd_clk : end : rd_data (fifo1.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------rd_clk : start : rd_addr (fifo1.v : 5) wr_clk : end : rd_sync1 (fifo1.v : 10) (ID:bus_two_dff_18726) wr_clk : start : wr_addr (fifo1.v : 5) rd_clk : end : wr_sync1 (fifo1.v : 10) (ID:bus_two_dff_646)
Also, the clock domains of the address pointers are identified explicitly:
// 0in set_cdc_port_domain wr_addr -clock wr_clk // 0in set_cdc_port_domain rd_addr -clock rd_clk
215
4. Register-file based FIFO synchronizer. CDC analysis only recognizes this instance as a fifo scheme if set_cdc_preference -fifo_scheme is specified. Also, to detect the register file:
// 0in set_cdc_fifo Mem1 Mem2 Mem3 Mem4 reg [2:0] wr_sync1, wr_sync2, reg [2:0] rd_sync1, rd_sync2; always @(posedge wr_clk) begin case (wr_addr) 3d0: Mem1[0] <= wr_data; 3d1: Mem1[1] <= wr_data; 3d2: Mem2[0] <= wr_data; 3d3: Mem2[1] <= wr_data; 3d4: Mem3[0] <= wr_data; 3d5: Mem3[1] <= wr_data; 3d6: Mem4[0] <= wr_data; 3d7: Mem4[1] <= wr_data; endcase rd_sync1 <= rd_addr ; rd_sync2 <= rd_sync1; full <= ((wr_addr+1)==rd_sync2)?1:0; end
full rd_sync2 wr_clk wr_data wr_addr memory rd_addr rd_data rd_clk wr_sync1 wr_sync2 empty rd_sync1
always @(posedge rd_clk) begin case (rd_addr) 3d0: rd_data <= Mem1[0]; 3d1: rd_data <= Mem1[1]; 3d2: rd_data <= Mem2[0]; 3d3: rd_data <= Mem2[1]; 3d4: rd_data <= Mem3[0]; 3d5: rd_data <= Mem3[1]; 3d6: rd_data <= Mem4[0]; 3d7: rd_data <= Mem4[1]; endcase wr_sync1 <= wr_addr; wr_sync2 <= wr_sync1; empty <= (rd_addr == wr_sync2)? 1:0; end Evaluations ================================================================= FIFO synchronization. (fifo) ----------------------------------------------------------------wr_clk : start : Mem1[0] (fifo2.v : 11) (ID:fifo_47408) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem1[1] (fifo2.v : 11) (ID:fifo_47412) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem2[0] (fifo2.v : 12) (ID:fifo_12944) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646
216
Command Reference fifo wr_clk : start : Mem2[1] (fifo2.v : 12) (ID:fifo_12948) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem3[0] (fifo2.v : 13) (ID:fifo_78480) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem3[1] (fifo2.v : 13) (ID:fifo_78484) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem4[0] (fifo2.v : 14) (ID:fifo_19728) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 wr_clk : start : Mem4[1] (fifo2.v : 14) (ID:fifo_19732) rd_clk : end : rd_data (fifo2.v : 6) Read pointer synchronizer ID : bus_two_dff_18726 Write pointer synchronizer ID : bus_two_dff_646 Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------rd_clk : start : rd_addr (fifo2.v : 5) wr_clk : end : rd_sync1 (fifo2.v : 10) (ID:bus_two_dff_18726) wr_clk : start : wr_addr (fifo2.v : 5) rd_clk : end : wr_sync1 (fifo2.v : 10) (ID:bus_two_dff_646)
217
Command Reference four_latch
four_latch
FOUR LATCH SYNCHRONIZER: Single-bit signal synchronized by latch synchronizer.
tx_sig latch tx_clk latch latch latch rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
Synchronization using four latches is a standard method of synchronizing a 1-bit signal. The end Rx signal for the synchronizer is the first latch in the synchronizer. Crossing Type 1-bit signal Default Severity evaluation Promoted Checker
cdc_sync

// 0in set_cdc_report -scheme four_latch -severity caution

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

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

tx_clk
tx_sig
rx_sig
rx_clk
2nd latch 4th latch
218
Command Reference four_latch Evaluations ================================================================= Single-bit signal synchronized by latch synchronizer. (four_latch) ----------------------------------------------------------------tx_clk : start : tx_sig (four_latch.v : 8) rx_clk : end : sync1 (four_latch.v : 8) (ID:four_latch_51294) via : sync1
219
Command Reference handshake
handshake
HANDSHAKE: Handshake synchronization.
MUX recirculation
Tx Clock Domain
Rx Clock Domain
ack-tx path
en
DEST FSM
SRC FSM rx_clk handshake loop acknowledge synchronizer request synchronizer
tx_clk
Specifying the set_cdc_preference global directive with the -handshake_scheme option directs CDC static analysis to identify DMUX synchronization schemes like that shown above as HANDSHAKE CDC schemes. Like DMUX synchronization, handshake synchronization uses a synchronized select signal to enable a data MUX to pass through data to the receive clock domain. Handshake synchronization has additional synchronization of the receive data MUX select signal back to the transmit clock domain as feedback into the select logic. This roundtrip synchronizer circuit automatically resets the receive domain MUX select signal. The enable signal to the transmit data MUX select also activates the receive data MUX select via the round-trip synchronizer. Crossing Type data bus Default Severity evaluation Promoted Checkers No checker is promoted for the handshake protocol. A cdc_dsel checker is promoted for the DMUX synchronization. Two cdc_sync checkers are promoted for the round-trip synchronizer.
Promoted CDC-FX Checker cdc_fx check is on by default.
220

// 0in set_cdc_preference -handshake_scheme // 0in set_cdc_report -scheme handshake -severity caution
2. In the following CDC report entry, the two synchronizers are the two 2DFF synchronizers in the round-trip synchronizer circuit.
Cautions ================================================================= Handshake synchronization. (handshake) ----------------------------------------------------------------ClkO : start : DMUXInLtch (Sync_ReqAck.v: 107) ClkR : end : DMUXOutLtch (Sync_ReqAck.v: 114)(ID:handshake_21466) Synchronizer ID : two_dff_17913 Synchronizer ID : pulse_sync_28075 Request Signal: ReqInO Acknowledge Signal: AckIn
3. Following example shows an instance of a handshake scheme. This scheme is a special case of a DMUX scheme and by default, is reported as such. To turn on HANDSHAKE reporting:
// 0in set_cdc_preference -handshake_scheme
The following code implements handshake synchronization:

// transmit data register always @ (posedge tx_clk) if (enable & ack_synced) tx_data <= din; // receive data register always @ (posedge rx_clk) if (ack) rx_data <= tx_data; // generate request always @ (posedge tx_clk) req <= (req | enable) & !ack_synced; // generate acknowledge always @ (posedge rx_clk) ack <= req_synced; // acknowledge synchronizer in TX domain always @ (posedge tx_clk) begin: ACK_SYNC reg temp; temp <= ack; ack_synced <= temp; end // request synchronizer in RX domain always @ (posedge rx_clk) begin: REQ_SYNC reg temp; temp <= req; req_synced <= temp; end
221
ack_synced req ack
req_synced enable din
en
tx_data data ow
en
rx_data
tx_clk
rx_clk
Handshake synchronization. (handshake) ----------------------------------------------------------------tx_clk : start : tx_data (handshake.v : 11) rx_clk : end : rx_data (handshake.v : 11) (ID:handshake_7492) Synchronizer ID : two_dff_24576 Synchronizer ID : two_dff_36232 Request Signal: req Acknowledge Signal: ack
222
Command Reference memory_sync
memory_sync
MEMORY SYNC: Memory Synchronization.
rd_data memory rd_clk
Wr Clock Domain
Rd Clock Domain
CDC synchronization using a 2D array (for example, a memory element used as a FIFO) is a standard method of synchronizing CDC signals or data buses. CDC analysis detects CDC crossings to and from memory, but the analysis cannot verify proper synchronization configuration and does not promote a transfer protocol checker to verify proper synchronization operation. Crossing Type control signal or data bus Default Severity caution Promoted Checker none Examples 1. Following is an example to turn severity to caution:
// 0in set_cdc_report scheme memory_sync severity caution
2. Following is an example to turn off reporting:

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

always @(posedge wr_clk) Mem [wr_addr] <= wr_data; always @(posedge rd_clk) rd_data <= Mem [rd_addr];
wr_clk wr_addr rd_addr wr_data Mem rd_data rd_clk
Memory Synchronization. (memory_sync) ----------------------------------------------------------------wr_clk: start: Mem (memory_sync.v : 9) rd_clk: end: rd_data (memory_sync.v: 6) (ID:memory_sync_69262)
223
Command Reference memory_sync
Potential Problem The CDC compiler currently does not perform read/write analysis, and misses the condition where the read and write addresses are equal, which could result in unreported memory write-through errors. Adding checkers to guard against this condition is suggested. The compiler issues a warning (hdl105) whenever it finds an instance of a memory_sync scheme.
224
Command Reference multi_bits
multi_bits
MULTIPLE BITS: Multiple-bit signal across clock domain boundary.
additional logic driven by signal tx_data rx_data
DFF
DFF
tx_clk
rx_clk
Tx Clock Domain
tx_data missing synchronizer tx_clk
Rx Clock Domain
rx_data
rx_clk
Tx Clock Domain
Rx Clock Domain
An unsynchronized CDC data bus in most cases should be a static violation. Similarly, a CDC data bus synchronized using a 2DFF synchronizer should not drive any logic from the wire connecting the two flip-flops. However, some data buses from test or configuration logic might be constant or ad hoc synchronous with the receive clock domain. Similarly, test or configuration logic driven by the wire connecting the two flip-flops of a 2DFF synchronizer might also be constant or ad hoc synchronous with the receive clock domain. The severity of these crossing schemes are typically set to caution. Crossing Type multibit data bus Default Severity violation Promoted Checker
cdc_sample
Promoted CDC-FX Checker cdc_fx check is on by default. Examples 1. Following is an example to turn reporting off for the status_test signal in module dut:
/* 0in set_cdc_report -scheme multi_bits -from status_test -severity off -module dut */
225
Command Reference multi_bits
2. Example promoted transfer protocol checker for multi_bits synchronization:

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

always @(posedge rx_clk) rx_bus <= tx_bus;
tx_clk tx_bus rx_bus rx_clk
Violations ================================================================= Multiple-bit signal across clock domain boundary. (multi_bits) ----------------------------------------------------------------tx_clk : start : tx_bus (multi_bits.v : 11) rx_clk : end : rx_bus (multi_bits.v : 11) (ID:multi_bits_2760)
226
Command Reference multi_sync_mux_select
multi_sync_mux_select
MULTIPLE SYNCHRONIZERS AT DMUX: MUX select fan-in contains more than one synchronizer.
tx_data MUX rx_sel tx_sel1 DFF DFF rx_clk DFF rx_data
tx_clk tx_sel2 DFF DFF
Tx Clock Domain
Rx Clock Domain
In most cases, if a MUX select is used to synchronize a signal or data bus, then the MUX select fan-in should not have more than one synchronizer. However, some synchronization schemes are tolerant of this type of synchronization scheme. In this case, the two synchronizers reconverge at the MUX select. So, a reconvergence scheme is reported in addition to the multi_sync_mux_select scheme. Crossing Type control signal or data bus Default Severity caution Promoted Checker cdc_sample Promoted CDC-FX Checker cdc_fx check is on by default. Examples 1. Following is an example to turn severity to evaluation:
/* 0in set_cdc_report -scheme multi_sync_mux_select -severity evaluation */

/* 0in set_cdc_report -scheme multi_sync_mux_select -severity evaluation -promotion off */
227
Command Reference multi_sync_mux_select
3. DMUX synchronizer with multiple control signals synchronized in the Rx domain:

tx_sel1 DFF s1_sel1 DFF s2_sel1 rx_clk tx_sel2 shift register MUX tx_data rx_data s_sel2[1]
tx_clk
always @(posedge rx_clk) begin reg s1_sel1, s2_sel1; reg [1:0] s_sel2; s1_sel1 <= tx_sel1; s2_sel1 <= s1_sel1; s_sel1 <= {s_sel2[0], tx_sel2}; if (s_sel2[1] | s2_sel1) rx_data <= tx_data; end Cautions ================================================================= Mux select fanin contains more than one synchronizer. (multi_sync_mux_select) ----------------------------------------------------------------tx_clk: start: tx_data (test31.v: 9) rx_clk: end: rx_data (test31.v: 6)(ID:multi_sync_mux_select_53401) Synchronizer ID : shift_reg_41011 Synchronizer ID : two_dff_93371
228
Command Reference no_sync
no_sync
MISSING SYNCHRONIZER: Single-bit signal does not have proper synchronizer.
additional logic driven by signal tx_sig rx_sig
DFF
DFF
tx_clk
rx_clk
Tx Clock Domain
tx_sig missing synchronizer tx_clk
Rx Clock Domain
rx_sig
rx_clk
Tx Clock Domain
Rx Clock Domain
An unsynchronized CDC signal is typically a static violation, but if such a crossing terminates at a black box module or RAM, the default severity is reported as caution (because synchronization might occur in the black box). Similarly, a CDC signal synchronized using a 2DFF synchronizer that drives logic from the wire connecting the two flip-flops is reported as a static violation by default. Some signals from test or configuration logic might be constant or ad hoc synchronous with the receive clock domain. Also, test or configuration logic driven by the wire connecting the two flip-flops of a 2DFF synchronizer might also be constant or ad hoc synchronous with the receive clock domain. The severity of these crossing schemes are typically set to caution. Crossing Type 1-bit signal Default Severity violation or caution Promoted Checker
cdc_sample
Promoted CDC-FX Checker cdc_fx check is on by default. Examples 1. Following is an example to turn severity to caution for the write_test signal in the module dut:
/* 0in set_cdc_report -scheme no_sync -from write_test
229
Command Reference no_sync -severity caution -module dut */
2. Example promoted transfer protocol checker for no_sync synchronization:

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

always @(posedge rx_clk, posedge rst) if (rst) rx_sig <= 1b1; else rx_sig <= tx_sig;
tx_sig tx_clk rx_sig rx_clk
Violations ================================================================= Single-bit signal does not have proper synchronizer. (no_sync) ----------------------------------------------------------------tx_clk : start : tx_sig (no_sync.v : 9) rx_clk : end : rx_sig (no_sync.v : 9) (ID:no_sync_59042)
230
Command Reference port_constraint_mismatch
port_constraint_mismatch
PORT CONSTRAINT MISMATCH: Signal connected to a port of a custom synchronizer is in a clock domain that is not allowed by the custom synchronizers port constraints.
illegal Tx clock domain for port
tx_sig custom port synchronizer constraint rx_sig
tx_clk
rx_clk
Tx Clock Domain
Rx Clock Domain illegal Rx clock domain for port illegal Rx clock domain for port
rx_sig port constraint rx_clk
illegal Tx clock domain for port

tx_sig port constraint tx_clk
custom synchronizer with crossing
Tx Clock Domain
Rx Clock Domain
A CDC port constraint identifies all clock domains allowed for signals connected to instances of the port. A port constraint is specified using the set_cdc_port_constraint directive. Currently port constraints are supported only for design units that are custom synchronizers (i.e., identified with the set_cdc_synchronizer custom directive). Custom Synchronizer For a standard custom synchronizer, you can specify a CDC port constraint on any of its signal and data bus input ports. The constraint can specify allowed clock domains for signals connected to it, allowed clock domains for the signal that clocks the port, or both. You also can specify allowed pairs of clock domains for instances of the port: one for the signal connected to the port and one for signal that clocks the port. A constrained port of an instance of the design unit has a port constraint mismatch if one of the following holds: The signal connected to the port is not from an allowed transmit clock domain for the port. The signal clocking the port is not from an allowed receive clock domain for the port. The domain of the transmit signal and the domain of the receive clock signal are not an allowed clock domain pair for the port.
Custom Synchronizer with Crossing For a custom synchronizer with crossing, you can specify CDC port constraints on its signal and data bus ports. These identify the allowed clock domains for signals connected to them.
231
Command Reference port_constraint_mismatch
Crossing Type control signal or data bus Default Severity violation Promoted Checker none Examples 1. Following is an example to turn severity to evaluation for port constraint mismatches for custom synchronizers in module prk:
/* 0in set_cdc_report -scheme port_constraint_mismatch -from write_test -severity evaluation -module prk */
232
Command Reference pulse_sync
pulse_sync
PULSE SYNC: Pulse Synchronization.
rx_sig tx_sig DFF tx_clk DFF DFF rx_clk
Tx Clock Domain
Rx Clock Domain
Pulse synchronization is a standard method of synchronizing a 1-bit signal. A variation of this scheme happens if the pulse output is delayed. Specify the set_cdc_preference -delayed_pulse directive to recognize such schemes as pulse_sync schemes.
rx_sig tx_sig DFF tx_clk DFF DFF DFF rx_clk
Tx Clock Domain
Rx Clock Domain
Crossing Type 1-bit signal Default Severity evaluation Promoted Checker

cdc_sync

// 0in set_cdc_report scheme pulse_sync severity caution

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

/* 0in cdc_sync -tx_var isyncabus.stage1_q -tx_clock clk1 -tx_min `P_clk1_clk2_tx_min -name cdc_sync_0 -module test -inferred */
233
Command Reference pulse_sync
4. Standard pulse synchronizer:

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

// 0in set_cdc_preference -delayed_pulse reg p0, p1, p2, pulse, dpulse; pulse tx_sig always @ (posedge rx_clk) begin p0 <= tx_sig; // 1st flop dpulse p1 <= p0; // 2nd flop p2 <= p1; // 3rd flop rx_clk tx_clk dpulse <= pulse;// 4th flop end always @ * pulse <= p1 ^ p2; Evaluations ================================================================= Pulse Synchronization. (pulse_sync) ----------------------------------------------------------------tx_clk: start: tx_sig (pulse_sync.v : 8) rx_clk: end: PULSE_SYNC.p0 (pulse_sync.v :16)(ID:pulse_sync_1845)
234
Command Reference reconvergence
reconvergence
RECONVERGENCE: Reconvergence of synchronizers.
reconverging signals sig1 tx_sig1 rx_sig
tx/rx_clk
sig2
tx_sig2
Source Clock Domains
Tx/Rx Clock Domain
Reconvergence occurs when the fan-in of a flip-flop includes two separately synchronized CDC signals from a different clock domain. The synchronizers can be any of the following: bus_dff_sync_gated_clk, bus_four_latch, bus_shift_reg, bus_two_dff, bus_two_dff_phase or two_dff_phase, dff_sync_gated_clk, four_latch. shift_reg, two_dff, pulse_sync and custom. Reconvergence of two signals might result in synchronization problems. When multiple bits reconverge, their relative timing is unpredictable. Logic that receives these signals should account for potential cycle skewfor example, by using a hamming encoding scheme for signals in the receiving domain. For signals that have large guard times between changes, this encoding happens naturally. If it is not feasible to either design receiving logic that accounts for the potential cycle skew or encode the signals, then you should group the signals and transfer them as a group using a synchronized MUX enable (as used for multiple-bit data signals). To force CDC analysis to recognize reconvergence schemes that start from a dmux, simple_dmux or multi_sync_mux_select scheme, specify set_cdc_preference -dmux_as_recon_start (page 283). Crossing Type multiple control signals or data buses Default Severity caution Promoted Checker cdc_hamming1 (if enabled, see set_cdc_preference on page 283).
235
Command Reference reconvergence
Examples 1. Following is an example to disable reporting of all reconvergence points originating in the tx_clk domain:
/* 0in set_cdc_report -scheme reconvergence -severity off -tx_clock tx_clk */
2. Following is an example to disable reporting of all reconvergence points originating from the cluster of synchronizers driving stat1, stat2, and stat3:
/* 0in set_cdc_report -scheme reconvergence -severity off -from_signals stat1 stat2 stat3 */
3. Following is an example to change the reconvergence depth to 4:

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

// 0in set_cdc_reconvergence -check off
5. Following example shows an instance of a reconvergence scheme that is reported when reconvergence depth is 0. The following code shows the reconvergence point and the two synchronizers on the reconverging paths.
// Tx signals always @ (posedge tx_clk) begin tx1 <= in1; tx2 <= in2; end // two_dff synchronizer always @ (posedge rx_clk) begin: two_dff reg temp; temp <= tx1; two_dff_sync <= temp; end // shift_reg synchronizer always @ (posedge rx_clk) begin: shift_reg shift_reg_sync <= {shift_reg_sync[0], tx2}; end // reconvergence point (depth 0) always @ (posedge rx_clk) dout <= two_dff_sync ^ shift_reg_sync[1];
[1] tx1 [0] shift_reg_sync[0] shift_reg_sync[1] shift register reconvergence point dout rx_clk tx2 DFF temp DFF two_dff_sync
in1
tx_clk in2
236
Command Reference reconvergence Violations ================================================================= Reconvergence of synchronizers. (reconvergence) ----------------------------------------------------------------rx_clk : end : dout (reconvergence.v : 5) (ID:reconvergence_78116) rx_clk : start : shift_reg_sync (reconvergence.v : 10) (Synchronizer ID:shift_reg_39969) rx_clk : start : two_dff_sync (reconvergence.v : 9) (Synchronizer ID:two_dff_74368)
6. Following example shows an instance of a reconvergence scheme that is reported when reconvergence depth is 1. To set the depth:
// 0in set_cdc_reconvergence -depth 1
The following code shows the reconvergence point and the two synchronizers on the reconverging paths.
// Tx signals always @ (posedge tx_clk) begin tx_data1 <= din1; tx_data2 <= din2; end // bus two_dff synchronizer always @ (posedge rx_clk) begin: two_dff reg [3:0] temp; temp <= tx_data1; two_dff_sync <= temp; end // shift_reg synchronizer always @ (posedge rx_clk) begin: shift_reg shift_reg_sync <= {shift_reg_sync[3:0], tx_data2}; end // reconvergence point (depth 1) always @ (posedge rx_clk) begin rx1 <= two_dff_sync; rx2 <= shift_reg_sync[7:4]; dout <= rx1 - rx2; end
[7:4] in1 shift_reg_sync[3:0] shift_reg_sync[7:4] tx_data1 shift register rx_clk tx_clk temp in2 tx_data2 DFF DFF two_dff_sync rx1 dout reconvergence point rx2
Violations ================================================================= Reconvergence of synchronizers. (reconvergence) ----------------------------------------------------------------rx_clk : end : dout (test4.v : 5) (ID:reconvergence_78116) rx_clk : start : shift_reg_sync (test4.v : 10) (Synchronizer ID:bus_shift_reg_96629) rx_clk : start : two_dff_sync (test4.v : 9) (Synchronizer ID:bus_two_dff_9116)
237
Command Reference redundant
redundant
REDUNDANT: Redundant synchronization.
rx_sig1 synchronizer tx_sig rx_clk
tx_clk
synchronizer
rx_sig2
Tx Clock Domain
Rx Clock Domain
Redundant synchronizers are multiple synchronizers in the same clock domain that synchronize the same CDC signal. The values of the rx_sig1 and rx_sig2 signals might not match, because of metastability. If these separately synchronized signals are in the fan-in of the same flip-flop, then a reconvergence problem might exist. But, even if they are not, redundant synchronizers create extra logic that can be eliminated by splitting the signals after they are synchronized. Crossing Type multiple control signals or data buses Default Severity caution Promoted Checker none Example 1. Following is an example to disable reporting of redundant synchronizers on *_en signals from the tx_clk domain:
/* 0in set_cdc_report -scheme redundant -severity off -from *_en -tx_clock tx_clk */
238
Command Reference redundant
2. Redundant synchronizers: shift register plus two dff synchronization:

// two_dff synchronizer of tx_sig always @ (posedge rx_clk) begin: two_dff reg s0 , s1; s0 <= tx_sig; // 1st flop s1 <= s0; // 2nd flop end // two_dff synchronizer of tx_sig always @ (posedge rx_clk) begin: shift_reg reg [1:0] sh_reg; sh_reg <= {sh_reg[0], tx_sig}; end
[1] tx_sig [0] shift_reg redundantly synchronized signals two_dff.s1 sh_reg[0] shift_reg.sh_reg
tx_clk
rx_clk
DFF twc_dff.s0 DFF
Violations ================================================================= Redundant synchronization. (redundant) ----------------------------------------------------------------tx_clk: start: tx_sig (redundant.v: 4) (ID:redundant_87696) rx_clk: end: shift_reg.sh_reg (redundant.v : 20) (Synchronizer ID:shift_reg_71323) rx_clk: end: two_dff.s1 (redundant.v: 12) (Synchronizer ID:two_dff_17946)
239
Command Reference series_redundant
series_redundant
SERIES REDUNDANT: Custom synchronizers connected in series.
Tx synchronizer
tx_sig custom synchronizer tx_clk custom synchronizer rx_clk
Rx synchronizer
rx_sig
Tx Clock Domain
Rx Clock Domain
Series redundant synchronizers are custom synchronizers connected in series, which synchronize to the same clock domain or do not have a specified clock domain. To determine if two custom synchronizers in series are in the same domain, the clock domain of the output of the Tx synchronizer is matched with the clock domain of the input of the Rx synchronizer. CDC analysis does not report custom synchronizers in series as series redundant if one of the synchronizers ports is specified as asynchronous. However, series redundant synchronizers are reported even if they are not used in a clock domain crossing. Series-redundant synchronizers do not indicate CDC problems, but they do indicate a waste of logic and power consumption. Crossing Type multiple control signals or data buses Default Severity caution Promoted Checker none Examples 1. Following is an example to disable reporting of series redundant synchronizers on *_en signals from the tx_clk domain:
/* 0in set_cdc_report -scheme series_redundant -severity off -from *_en -tx_clock tx_clk */
240
Command Reference series_redundant
2. Custom synchronizers connected in a redundant series

custom_sync #(4) cust_sync_A( .clk (rx_clk), .d (tx_data), .q (cust_sync_A_out)); custom_sync #(4) cust_sync_B( .clk (rx_clk), .d (cust_sync_A_out), .q (cust_sync_B_out));
cust_sync_A_out tx_data cust_sync_A tx_clk cust_sync_B rx_clk cust_sync_B_out
Series Redundant synchronization. (series_redundant) ----------------------------------------------------------------rx_clk: start: custom_sync_A.q (series_redundant.v : 27) rx_clk: end: custom_sync_B.d (series_redundant.v : 29) (ID:series_redundant_93597)
241
Command Reference shift_reg
shift_reg
SHIFT REG: Shift-register synchronization.
tx_sig shift register tx_clk rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
Synchronization using a shift register is a standard method of synchronizing a 1-bit signal. It is equivalent to synchronization with two or more in-phase flip-flops. The difference is in the coding templates recognized by the two schemes. The following example shows the code for a shift register synchronization scheme:
reg [n:0] shftreg always @(clock) shftreg <= {shftreg[n-1:0],din};
Crossing Type 1-bit signal Default Severity evaluation Promoted Checker

cdc_sync

// 0in set_cdc_report scheme shift_reg severity caution

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

/* 0in cdc_sync -tx_var u0.q -tx_clock clk1 -tx_min `P_clk1_clk2_tx_min -name cdc_sync_0 -module dut -inferred
*/
242
Command Reference shift_reg
4. Shift register synchronizer:

// shift_levels = 8 always @ (posedge rx_clk) begin shift_reg reg [1:shift_levels] shift_reg_sync; shift_reg <= {tx_sig, shift_reg_sync[1:shift_levels-1]} ; end
[0:6] tx_sig [7] shift register shift_reg_sync[8] shift_reg_sync[1:7] synchronized signal
tx_clk
rx_clk
Evaluations ================================================================= Shift-register synchronization. (shift_reg) ----------------------------------------------------------------tx_clk : start : tx_sig (shift_reg.v : 10) rx_clk : end : shift_reg.shift_reg_sync[1] (shift_reg.v : 19) (ID:shift_reg_99229)
243
Command Reference simple_dmux
simple_dmux
SIMPLE_DMUX: Simple MUX enable.
tx_data MUX rx_data
Tx Clock Domain
Rx Clock Domain
The simple DMUX scheme is a restricted version of the general DMUX scheme. For the general scheme, the fanin logic of the Rx signal can contain any logic and the synchronized control signal can use any logic to turn off the Tx signal (not just a MUX). The control signal can be synchronized by any of the following signal synchronizers: bus_dff_sync_gated_clk, bus_four_latch, bus_shift_reg, bus_two_dff, bus_two_dff_phase or two_dff_phase, dff_sync_gated_clk, four_latch. shift_reg, two_dff, pulse_sync and custom. The simple DMUX scheme has the following restrictions: Logic between the Tx and Rx signals has a MUX. Rx output feeds back to the MUX input. Tx signal drives the D-input of the Rx register Tx and Rx drivers are registers. No combo logic is between the Tx and Rx registers. No combo logic is between select output from the synchronizer and the MUX. Note The physical design of the MUX logic (that controls the path from the Tx register to the Rx registers) must not allow glitches at the input to an Rx register when the Tx register changes value. Crossing Type synchronized control signal and muxed data bus Default Severity caution
244
Command Reference simple_dmux
Promoted Checker
cdc_dsel
Promoted CDC-FX Checker cdc_fx check is on by default. Examples 1. Following is an example to turn severity to evaluation:
// 0in set_cdc_report -scheme simple_dmux -severity evaluation

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

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

always @(posedge rx_clk) begin: DMUX reg s1, rx_sel; s1 <= tx_sel; // 1st DFF rx_sel <= s1; // 2nd DFF if (rx_sel) rx_data <= tx_data; end
tx_data MUX tx_clk tx_sel DFF s1 DFF rx_sel rx_clk rx_data
Cautions ================================================================= Simple DMUX synchronization. (simple_dmux) ----------------------------------------------------------------tx_clk : start : tx_data (simple_dmux.v : 9) rx_clk : end : rx_data (simple_dmux.v : 6) (ID:simple_dmux_44768) Synchronizer ID : two_dff_44468
245
Command Reference single_source_reconvergence
single_source_reconvergence
SSR: Single-source reconvergence of synchronizers.
single source reconverging signals
tx/rx_clk clk
Source Clock Domain
Tx/Rx Clock Domain
Reconvergence occurs when the fan-in of a flip-flop includes two separately synchronized CDC signals from a different clock domain. Single-source reconvergence is the special case where reconverging signals in the receive domain originate from the same signal in the transmit domain. Reconvergent signals might result in synchronization problems, but large designs can have large numbers of reconvergence paths. Single-source reconvergence paths are more likely to cause design problems than reconvergence paths from unrelated sources, so they can be given a higher priority when resolving issues of reconvergence. Static CDC analysis reports single-source reconvergence paths as both reconvergence violations and SSR violations. The set_cdc_reconvergence (page 291) global directive adjusts two parameters used to determine how extensive static CDC analysis of reconvergence paths should be: depth Maximum number of sequential levels in the receive domain from the synchronizers to the reconverging paths. The depth is used to limit analysis of reconverging paths (both single-source and separate-source). divergence depth Maximum number of sequential levels in the transmit domain from the flip-flops driving the synchronizers backwards to the single source. The depth is used to limit analysis of single-source reconverging paths. By default, instances of single-source reconvergence are reported only as instances of the reconvergence scheme. Specifying set_cdc_reconvergence -divergence_depth <depth> enables SSR reporting for matching divergence/reconvergence paths. Crossing Type multiple control signals or data buses
246
Command Reference single_source_reconvergence
Default Severity violation Promoted Checker cdc_hamming1 (if enabled, see set_cdc_preference on page 283). Examples 1. Following is an example to disable reporting of single-source reconvergence points originating in the tx_clk domain:
/* 0in set_cdc_report -scheme single_source_reconvergence -severity off -tx_clock tx_clk */
2. Following is an example to disable reporting of single-source reconvergence points originating from the cluster of synchronizers driving stat1, stat2, and stat3:
/* 0in set_cdc_report -scheme single_source_reconvergence -severity off -from_signals stat1 stat2 stat3 */
3. Following is an example to change the reconvergence depth to 4 and enable singlesource reconvergence reporting with a divergence depth of 5:
// 0in set_cdc_reconvergence -depth 4 -divergence_depth 5
4. Following examples change the reconvergence depth and and enable single-source reconvergence reporting:
// 0in set_cdc_reconvergence -depth 1 -divergence_depth 2
divergence depth = 2 synchronizer depth = 1
synchronizer
synchronizer
Tx Clock Domain
Rx Clock Domain
reported single-source reconvergence paths
247
Command Reference single_source_reconvergence // 0in set_cdc_reconvergence -depth 2 -divergence_depth 1

divergence depth = 1 synchronizer depth = 2
synchronizer
synchronizer
Tx Clock Domain
Rx Clock Domain
reported single-source reconvergence paths
5. Following example shows an instance of a single-source reconvergence scheme that is reported when divergence depth is 0. SSR reporting is off by default, so turn on SSR reporting:
// 0in set_cdc_reconvergence -divergence_depth 0
The following code shows the divergence and reconvergence points and the two synchronizers on the reconverging paths.
// divergence point always @ (posedge tx_clk) ctrl <= ci0 | ci1 ; // two_dff synchronizer always @ (posedge rx_clk) begin: two_dff reg temp; temp <= ctrl; two_dff_sync <= temp; end // shift_reg synchronizer always @ (posedge rx_clk) begin: shift_reg shift_reg_sync <= {shift_reg_sync[0], ctrl}; end // reconvergence point always @ (posedge rx_clk) dout <= two_dff_sync ^ shift_reg_sync[1];
divergence point [1] ctrl [0] tx_clk two_dff_sync shift_reg_sync[0] reconvergence point shift_reg_sync[1] shift register dout rx_clk
divergence depth = 0
DFF
DFF
248
Command Reference single_source_reconvergence Single Source Reconvergence of synchronizers. (single_source_reconvergence) ----------------------------------------------------------------rx_clk : end : dout (single_source_reconvergence.v : 5) (ID:single_source_reconvergence_41397) rx_clk: start: shift_reg_sync(single_source_reconvergence.v : 10) (Synchronizer ID:shift_reg_97221) rx_clk : start : two_dff_sync (single_source_reconvergence.v : 9) (Synchronizer ID:two_dff_44733) tx_clk : diverge : ctrl (single_source_reconvergence.v : 8)
6. Following example shows an instance of a single-source reconvergence scheme that is reported when divergence depth is 1. SSR reporting is off by default, so turn on SSR reporting:
// 0in set_cdc_reconvergence -divergence_depth 1
The following code shows the divergence and reconvergence points and the two synchronizers on the reconverging paths.
// divergence point always @ (posedge tx_clk) begin diverge <= diverge + 1; tx_data1 <= din + diverge; tx_data2 <= ~diverge; end
// 1 level to sync // 0 levels to sync // 0 levels to sync
// two_dff synchronizer always @ (posedge rx_clk) begin: two_dff reg [3:0] temp; temp <= tx_data1; two_dff_sync <= temp; end // bus_shift_reg synchronizer always @ (posedge rx_clk) begin: shift_reg shift_reg_sync <= {shift_reg_sync[3:0], tx_data2}; end // reconvergence point always @ ( posedge rx_clk ) dout <= two_dff_sync - shift_reg_sync[7:4];
divergence point diverge [7:4] [3:0] tx_data2 shift_reg_sync[3:0] bus shift register reconvergence point dout rx_clk + tx_data1 divergence depth = 1 DFF DFF two_dff_sync
shift_reg_sync[7:4]
tx_clk din
249
Command Reference single_source_reconvergence Single Source Reconvergence of synchronizers. (single_source_reconvergence) ----------------------------------------------------------------rx_clk : end : dout (single_source_reconvergence.v : 5) (ID:single_source_reconvergence_84301) rx_clk: start: shift_reg_sync (single_source_reconvergence.v : 10) (Synchronizer ID:bus_shift_reg_96629) rx_clk : start : two_dff_sync (single_source_reconvergence.v : 9) (Synchronizer ID:bus_two_dff_9116) tx_clk : diverge : diverge (single_source_reconvergence.v : 8)
250
Command Reference two_dff
two_dff
TWO DFF SYNCHRONIZER: Single-bit signal synchronized by DFF synchronizer.
tx_sig DFF tx_clk DFF rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
Synchronization using two flip-flops is a standard method of synchronizing a 1-bit signal. Crossing Type 1-bit signal Default Severity evaluation Promoted Checker
cdc_sync

// 0in set_cdc_report scheme two_dff severity caution

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

always @(posedge rx_clk) begin s0 <= tx_sig; // 1st DFF s1 <= s0; // 2nd DFF end
tx_sig DFF tx_clk s0 DFF rx_clk s1
Evaluations ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------tx_clk : start : tx_sig (two_dff.v : 9) rx_clk : end : s0 (two_dff.v : 10) (ID:two_dff_32868)
251
Command Reference two_dff
5. Single-bit signal synchronized by two cascaded flip-flops with enable ports:

// 0in set_cdc_preference -allow_enable_in_sync always @(posedge rx_clk) if (enable) {s0, s1} <= {tx_sig, s0};
tx_sig
EN EN
enable s1 rx_clk
s0 tx_clk
Evaluations ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------tx_clk : start : tx_sig (two_dff.v : 9) rx_clk : end : s0 (two_dff.v : 10) (ID:two_dff_32868)
Notes If you use a DFF synchronization scheme that has more than two flip-flops, then you can get CDC analysis to recognize the scheme by specifying a set_cdc_synchronizer directive (page 302). For example, the following CDC global directive identifies 4 DFF synchronizers as valid two_dff schemes for CDC paths from the tx_clk domain to the rx_clk domain:
/* 0in set_cdc_synchronizer dff -level 4 -tx_clock tx_clk -rx_clock rx_clk */
252
Command Reference two_dff_phase
two_dff_phase
TWO DFF SYNCHRONIZER OPPOSITE POLARITY: Single-bit signal synchronized by DFF of opposite clock polarity.
tx_sig DFF tx_clk DFF rx_clk rx_sig
Tx Clock Domain
Rx Clock Domain
Synchronization using two opposite polarity flip-flops has a reduced time for rx_sig to settle. When using this synchronization scheme, be sure the MTBF is acceptable. Crossing Type 1-bit signal Default Severity caution Promoted Checker cdc_sync Example 1. Following is an example to turn severity to caution:
// 0in set_cdc_report -scheme two_dff_phase -severity caution
2. 2DFF phase synchronizer has one FF clocked by a clock with the opposite polarity of the Rx clock:
always @(negedge rx_clk) sync1 <= tx_sig; // 1st FF always @(posedge rx_clk) sync2 <= sync1; // 2nd FF
tx_clk tx_sig sync1 sync2
rx_clk
Cautions ================================================================= Single-bit signal synchronized by DFF of opposite clock polarity. (two_dff_phase) ----------------------------------------------------------------tx_clk : start : tx_sig (two_dff_phase.v : 9) rx_clk : end : s0 (two_dff_phase.v : 10) (ID:two_dff_phase_42446)
253
Command Reference Global Directives
Global Directives
Global directives configure and control the 0-In verification tools. This section has descriptions of the use of primitives and wildcards in global directives, followed by data sheets for the global directives.
0-In Comments
To use global directives, you place them inside 0-In comments in control files. A control file is a text file containing a Verilog module or VHDL design unit. Note Global directives specified outside a Verilog module or VHDL design unit are ignored. 0-In comments have a similar structure as generic HDL comments, but start with the identifier 0in. You can include multiple directives in the same 0-In comment, if you separate them by semicolons. Everything within a 0-In comment is meaningful to the 0-In compilers. The contents are interpreted as one or more directives. You cannot include a 0-In comment inside an HDL comment. The 0-In compilers read two types of 0-In comments: Single-line 0-In comments Verilog single-line 0-In comments begin with // 0in. VHDL single-line 0-In comments begin with -- 0in. Single-line 0-In comments are effective to the end of the line. You can include a single-line HDL comment inside a single-line 0-In comment.
// 0in set_black_box modX // Black-box modX module -- 0in set_black_box entityX -- Black-box entityX entity
Block 0-In comments Verilog block 0-In comments begin with /* 0in and are effective until the terminator */. VHDL block 0-In comments start each line with -- 0in. A new line in a block 0-In comment is treated as whitespace. Both the 0in keyword and the global directive name must be specified on the first line of a block 0-In comment. You cannot include HDL comments inside block 0-In comments. For example:
/* 0in set_cdc_report -scheme blackbox -from out2a -to bb1.* -severity off -- 0in set_cdc_report -scheme blackbox -- 0in -from out2a -to bb1.* -severity off */
254
0-In Primitives
Expressions in 0-In directives are HDL expressions that can include 0-In primitives. Expressions represent signals derived from other signals or expressions that evaluate to signals. 0-In primitives can refer to signals or expressions that evaluate to signals, including other primitives. Expressions can combine HDL expressions and 0-In primitives using HDL operators and parentheses for grouping. 0-In primitives are expressions. Expressions in directives must be enclosed in parentheses. The 0-In primitives are: $0in_rising_edge, $0in_falling_edge, $0in_0_to_1, $0in_1_to_0, $0in_delay, and $0in_spy. The $0in_rising_edge and $0in_falling_edge primitives use Verilog posedge/negedge semantics, which accounts for transitions involving X. The $0in_0_to_1 and $0in_1_to_0 primitives do not account for transitions involving X. $0in_0_to_1(expression [,clock]) Signal that asserts when expression transitions from 0 to 1. The signal de-asserts when expression deasserts or at the active edge of the clock, whichever comes first.
clock sig ($0in_0_to_1(sig, clock))
$0in_1_to_0(expression [,clock])
clock sig ($0in_1_t0_0(sig, clock))
Signal that asserts when expression transitions from 1 to 0. The signal de-asserts when expression asserts or at the active edge of the clock, whichever comes first.
$0in_rising_edge(expression [,clock]) Signal that asserts when expression transitions from 0 to 1/X or from X to 1. The signal de-asserts when sig_a expression transitions again or at the active edge of the clock, ($0in_rising_edge(sig_a, clock)) whichever comes first.
clock sig_b ($0in_rising_edge(sig_b, clock)) sig_c ($0in_rising_edge(sig_c, clock))
255
$0in_falling_edge(expression [,clock]) Signal that asserts when expression transitions from 1 to 0/X or from X to 0. The signal de-asserts when sig_a expression transitions again or at ($0in_falling_edge(sig_a, clock)) the active edge of the clock, whichever comes first.
clock sig_b ($0in_falling_edge(sig_b, clock)) sig_c ($0in_falling_edge(sig_c, clock))
$0in_delay(expression [, number_of_cycles [,clock]])

sig
n cycles
($0in_delay(sig, n, clock))
Signal derived from the signal specified by expression, delayed by the specified number of clock cycles. The default clock is inferred from expression if it is possible. Otherwise, the clock is inferred from the directive.
$0in_spy(name [, number]) Using $0in_spy simplifies the file list, which can reduce the runtime and memory footprint. This primitive allows specifying hierarchical names that might be outside of the file list given to the compiler. The representation is a signal whose name is name and whose bit-width is number (default 1). The compiler does not try to resolve this signal in the file list, and prints it out "as is" in the checker logic. For example,
// 0in set_reset -default $0in_spy(top.rst)
Assumes that top.rst signal is 1 bit and hooks up to the resets of checkers, even if top is not given in the filelist. Compare this with the following:
// 0in set_reset -default top.rst
This results in a warning/error with an unresolved signal on top.rst if the module top is not given in the filelist. Following is another example:
// 0in one_hot -var $0in_spy(tb.u0.a.b.c, 8) -clock clk
256
This puts a one_hot checker on an 8-bit tb.u0.a.b.c signal even if the compiler does not find it in the file list. If tb.u0.a.b.c does not exist or is not 8 bits wide, the simulator generates an error or reports width-mismatch warnings. The primitive peeks a signed signal into an unsigned vector. For example,
$0in_spy(a.b.c, w);
is mapped to
wire [w-1:0] sg_123 = a.b.c;
Hierarchical Paths
Directives in a control file that do not specify a -module argument (i.e., at the top level) specify signals with the complete hierarchical paths. Directives in a control file that specify a -module argument or set_clock/set_reset directives in a module/architecture (i.e., at a lower level) specify signals relative to the local module/architecture. Example 1
// G1 is the top level; m1_dut is an instance of M1 //0in set_constant G1.F1[0].I0.F2[0].m1_dut.x 1b1 -module M1
Generates a warning because it specifies an absolute path for x. The directive is skipped. Example 2
// G1 is the top level; m1_dut is an instance of M1 //0in set_constant x 1b1 -module M1
Matches
G1.F1[0].I0.F2[0].m1_dut.x
Wildcards in Directive Arguments

Wildcards (*) are supported in many global directive arguments. Typically values that support wildcards are called patterns in the argument descriptions (whereas, values that do not support wildcards are specified as simply variables, signals or values). In general, signal names and module names in global directives support wildcards. Clock group names do not. Path separators are matches for wildcards (see Example 2).
257
Example 1
G1.*.*.F3[0].*.clk* 1b0
Matches the following specifications. In this example, the bold * matches multiple hierarchical levels.
G1.F1[6].I1.F3[0].m1_dut.clk1 G1.F1[6].I1.F3[0].m2_dut.clk2 G1.F1[6].I1.F3[0].sync_dut.clk2 G1.F1[6].I1.F3[0].sync_dut.dmux_dut.clk G1.F1[6].I1.F3[0].sync_dut.dmux_dut.dff.clk
Example 2
G1.*
Matches all signals below G1 (i.e., any signal with a hierarchy depth > 0 from G1). Example 3
G1.*.*.*
Matches all signals with a hierarchy depth > 3 from G1, such as:
G1.F1[6].I1.F3[2].m2_dut.int_x G1.F1[6].I1.F3[2].m2_dut.mem_in G1.F1[6].I1.F3[2].sync_dut.bus_in
Example 4 See the CDC Settings Report to see how wildcards are expanded, for example:
***************************************************************** Section D: Wildcard Expansion for Global Directives ***************************************************************** Wildcards for set_cdc_port_domain directive ----------------------------------------------------------------File mixed1_ctrl.v : Line 2 *in* matches vhdl_inst.in1 vhdl_in v2k_in Wildcards for set_cdc_signal directive ----------------------------------------------------------------File mixed1_ctrl.v : Line 6 vhdl_inst.*c_enum matches vhdl_inst.rec_enum
258
Directive Order
Directive order is important in processing directives (especially directives with wildcard arguments). Directives are processed in order and directives that conflict with preceding directives are completely or partially skipped. For the following example, module moda has inputs in1, in2, in3 and in4:
// 0in set_cdc_port_domain -clock clk_a -module moda in1 // 0in set_cdc_port_domain -clock clk_b -module moda in2 // 0in set_cdc_port_domain -clock clk_c -module moda -input *
Since the last directive matches in1 and in2 (which were assigned in the previous directives), it generates the following warnings:
Warning : Multiple clocks defined for [File .../dut_ctrl.v, Line [File .../dut_ctrl.v, Line : Port will be ignored in the Warning : Multiple clocks defined for [File .../dut_ctrl.v, Line [File .../dut_ctrl.v, Line : Port will be ignored in the port. Port insta.in1, 54] and 56].[directive-248] second directive. port. Port insta.in2, 55] and 56].[directive-248] second directive.
The directives assign in1 to clk_a domain, in2 to clk_b domain, and in3/in4 to clk_c domain which is probably the intended resultso you do not need to modify the directives. But, suppose you swap the directive order as shown in the following specification:
// 0in set_cdc_port_domain -clock clk_c -module moda -input * // 0in set_cdc_port_domain -clock clk_a -module moda in1 // 0in set_cdc_port_domain -clock clk_b -module moda in2
The first directive assigns all input ports (in1/in2/in3/in4) to clk_c domain. The second directive produces the following warning:
Warning : Multiple clocks defined for [File .../dut_ctrl.v, Line [File .../dut_ctrl.v, Line : Port will be ignored in the port. Port insta.in1, 54] and 55].[directive-248] second directive.
and the third directive produces:

Warning : Multiple clocks defined for [File .../dut_ctrl.v, Line [File .../dut_ctrl.v, Line : Port will be ignored in the port. Port insta.in2, 54] and 56].[directive-248] second directive.
The second and third directives are completely vacuous and are totally ignored, which is certainly not what you intended. Here, you must modify the order of the directives (or remove the second and third directives).
259
Command Reference Directives for CDC Analysis
Directives for CDC Analysis

Table 6-2 shows the global directives used for static and dynamic CDC analysis. Additional directives used to configure and control assertion logic in simulation and the formal models in formal analysis are also relevant to CDC verification. They are described in Directives for Checker Generation on page 313. Table 6-2. Global Directives for CDC Analysis Type Clocks and Domains Directive set_cdc_clock set_cdc_port_domain Description Specifies clocks with their characteristics. Indicates the specified ports belong to a specified clock domain, are asynchronous to all identified clock domains or should be ignored. Wildcard Args clock -module port -same_clock -combo_path -module
set_cdc_port_constraint
Sets CDC port constraints for design module -ports units identified as custom synchronizers. Identifies reset signals or removes signal them from the list of inferred signals. -module Reclassifies the CDC signal type of specified CDC signals or adds properties to specified CDC signals. Sets preferences for CDC static analysis. signal -module
CDC Analysis
set_reset set_cdc_signal
set_cdc_preference
set_cdc_hier_preference Sets preferences for hierarchical CDC analysis. set_mode set_mode_control CDC Schemes set_cdc_synchronizer Sets an operational mode for modal analysis. -set signal
Identify legal values for the specified signal mode control signals. Identifies non-standard synchronizer -clock -module types and their corresponding properties. Sets the severity level and promotion -from -through property of matching clock domain -to crossings. -module
set_cdc_report
260
Command Reference Directives for CDC Analysis
Type
Directive set_cdc_fifo
Description Identifies FIFOs for fifo scheme recognition from register files and latch files. Sets preferences for CDC FIFO schemes, if they are enabled in CDC static analysis.
Wildcard Args register -module
set_cdc_fifo_preference
set_cdc_handshake_prefe Sets preferences for CDC handshake rence schemes, if they are enabled in CDC static analysis. set_cdc_reconvergence Sets preferences for CDC reconvergence schemes, if they are enabled in CDC static analysis. Identifies modules/entities as black boxes. Sets the memory model types for specified multidimensional arrays. module mem -module
Netlist Generation
set_black_box set_memory set_constant
Identifies the specified variable (port signal -module or internal variable) as having the specified constant value.
set_constant_propagation Propagates constants through sequential logic. Checker Promotion CDC-FX set_cdc_protocol Identifies a CDC protocol checker type to promote for one or more custom synchronizer modules. -module
set_cdc_fx_metastability Sets the metastability window for one _window or more pairs of CDC-FX clocks. set_cdc_fx_timescale set_cdc_fx_check Sets the timescale for CDC-FX logic. Turns on cdc_fx checks.
261
Command Reference set_black_box
set_black_box
Identifies modules/entities as black boxes. Syntax set_black_box module [-dont_use_outputs] module Module/entity names or wildcard patterns. -dont_use_outputs 0-In Formal argument ignored for CDC. Description The cdc compiler skips netlist elaboration of black-boxed modules/entities and their children. Typically modules/entities declared as user-defined black boxes contain unsupported constructs so the compiler would infer them as black boxes anyway. However, CDC analysis treats inferred and user-defined black-box modules differently: User-defined black box. No blackbox schemes are reported for the ports. If the clock domain for a port is specified (using a set_cdc_port_domain directive), the port is included in CDC analysis. Otherwise, fanin/fanout logic of the port is ignored. No CDC crossing is reported for the port, but a warning is issued. Ports asynchronous with the defined clocks should be identified as such using the -async argument.
Inferred black box. A blackbox scheme (with caution severity by default) is reported for each input. Each output port is automatically marked as an async port (no set_cdc_port_domain global directive is needed). The port is considered a transmit source for a CDC crossing, so it is reported as the source of a synchronized or unsynchronized path.
262
Command Reference set_cdc_clock
set_cdc_clock
Specifies clocks with their characteristics and redefines the clock domains. Syntax set_cdc_clock clock_signal [[posedge] [negedge] [waveform risingTime fallingTime] [period value] [virtual] [mode mode] [group group] | ignore | remove] [-jitter_percent number] [module module_pattern] clock_signal Clock signal names or wildcard patterns. Clock signals can be primary ports or hierarchical paths to clock signals. Clock signals can be individual bits of clock vectors. -posedge Clock signals have positive active edges. Default: -posedge. -negedge Clock signals have negative active edges. -waveform rising_Time falling_Time Rising edge and falling edge times (in time units) that define the clock duty cycle. This argument is ignored. -period value Clock period in time units. This value is used to calculate directive parameters for promoted checkers. -virtual Clock signals are virtual clocks used to identify clocks from ports that do not exist in the DUT. For example, specify -virtual for a port associated with a clock that is not an input to the design. -mode mode Mode for which this directive applies when running modal analysis. The directive is skipped unless you are running CDC modal analysis in the specified mode. Default: directive is recognized in all modes and for non-modal CDC analysis. -group group Clock group containing the specified clocks. All specified clocks are considered to be in the clock domain corresponding to the group. You can specify multiple set_cdc_clock global directives with the same -group name (for example, to identify clocks in the same domain that have different clock characteristics). Default: specified clocks are associated with a single unnamed default clock group.
263
-ignore Add the specified clocks to the list of ignored clocks. Typical usage is to run cdc -report_clock to identify the clocks in the design. Then, use set_cdc_clock -ignore to mark specific clocks to be ignored. Registers in the domains of ignored clocks are not used in CDC analysis. So, marking superfluous clocks as ignored can help improve performance. The 0in_cdc_design.rpt reports Ignore Clock Tree section lists the clocks marked as ignored. If both -ignore and -group are specified, the named clocks are added to the specified clock group and all clocks in that group are added to the list of ignored clocks. Default: specified clocks are added to the specified (or default) clock group.
-remove Remove clock_signals from the clock tree. Default: specified clocks are added to the specified (or default) clock group.
-jitter_percent number Proportion of the clock cycle that clock edges can jitter. The percent must be <100. Used to calculate tx_min: jitter rx_clk_period 1 + ---------- 100 tx_min = int(----------------------------------------------------------------- ) + 1 1 jitter tx_clk_period --------- 100
Default: jitter = 0. rx_clk_period tx_min = int(-------------------------------- ) + 1 tx_clk_period
-module module_pattern Clock signal names are specified relative to the module matching module_pattern. If multiple modules match module_pattern, then the matching clock_signals in the matching modules are grouped in the same clock group. Default: clock signal names are hierarchical from the top level.
Description Specifies clocks with their characteristics and redefines clock domains. You must specify a clock signal pattern that matches at least one clock signal and no two set_cdc_clock global directives can specify the same clock. Verilog clocks can be bits of multiple-bit variables. VHDL clocks can be scalars (bit, std_logic, std_ulogic) or single-bit vector record elements. The set_cdc_clock directives without the -module option are processed in the order of entries in the control file. Then the set_cdc_clock directives with the -module option are processed in the order of entries in the control file. Wildcard matches do not take precedence over exact matches.
264
Examples
module cdc_ctrl; // 0in set_cdc_clock U0.clk U1.clk -period 100 -group A // 0in set_cdc_clock U0.clk[2] U1.clk[2] -period 50 -group A endmodule
Creates a single clock domain A.

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

module ctrl; // 0in set_cdc_clock // 0in set_cdc_clock // 0in set_cdc_clock // 0in set_cdc_clock endmodule clkA clkB clkC -ignore clkD -ignore
Design has four clocks (clkA, clkB, clkC, and clkD), but user wants to restrict analysis to crossings between clkA and clkB. The clkC and clkD clocks are ignored. Only crossings between clkA and clkB are reported in 0in_cdc.rpt.
module ctrl; // 0in set_cdc_clock clk* -group G1 endmodule
The wildcard pattern clk* is expanded and matching signals are added to the G1 clock group. The list of wildcard expanded signals are reported in 0in_detail.log:
Wildcards for set_cdc_clock directive ----------------------------------------------------------------File t11_ctrl.v : Line 3 ----------------------------------------------------------------clk* matches clk1 clk2 // 0in set_cdc_clock clkA -virtual // 0in set_cdc_port_domain sigA -clock clkA
sigA clk_B DUT
clkA
Example of virtual clocks. Signal sigA is associated with clock clkA (which is outside the DUT).
265
Command Reference set_cdc_fifo
set_cdc_fifo
Identifies FIFOs for fifo scheme recognition from register files and latch files. Syntax set_cdc_fifo register_pattern [module module_pattern] [mode mode] register_pattern Name pattern for the FIFO registers (or latches). module module_pattern Name pattern for the modules containing the registers to match. Default: top module. mode mode Mode to which the FIFO identification belongs. Default: all modes. Description Identifies FIFOs defined in register files (or latch files) for analysis of FIFO synchronization schemes. Examples
//0in set_cdc_fifo -module reg_file_fifo_* reg*
266
Command Reference set_cdc_fifo_preference
set_cdc_fifo_preference
Sets preferences for FIFO CDC schemes, if they are enabled in CDC static analysis. Syntax set_cdc_fifo_preference [-no_write_sync] [-no_read_sync] [-allow_read_flop] [-multiple_write_syncs] [-multiple_read_syncs] -no_write_sync Reports as fifo schemes those memory_sync schemes that are FIFO schemes without a write address synchronizer. Default: such schemes are reported as memory_sync schemes. -no_read_sync Reports as fifo schemes those memory_sync schemes that are FIFO schemes without a read address synchronizer. Default: such schemes are reported as memory_sync schemes. -allow_read_flop In addition to standard FIFO schemes, reports as fifo schemes those memory_sync schemes that are FIFO schemes where the read address synchronizer is in the fanout of a read clock domain register that drives the read address. Default: unless -no_read_sync is specified, only FIFO schemes where the read address synchronizer is in the fanout of the read address are reported as fifo schemes. -multiple_write_syncs Reports all write address synchronizers and promotes cdc_hamming_distance_one checkers for them. Default: if the FIFO scheme has multiple write address synchronizers, only one of them is reported. -multiple_read_syncs Reports all read address synchronizers and promotes cdc_hamming_distance_one checkers for them. Default: if the FIFO scheme has multiple read address synchronizers, only one of them is reported. Description Changes the template used to detect fifo CDC schemes.
267
Command Reference set_cdc_fx_check
set_cdc_fx_check
Turns on/off cdc_fx checkers checks. Syntax set_cdc_fx_check [-scheme scheme] [-tx_clock clock_signal] [-rx_clock clock_signal] [-fx] [-glitch_swallowed] [-glitch_caught] -scheme scheme The -scheme option restricts the directive to those cdc_fx checkers connected to synchronizers of the specified type -tx_clock clock The -tx_clock option restricts the directive to those cdc_fx checkers with the specified transmit clock. -rx_clock clock The -rx_clock option restricts the directive to those cdc_fx checkers with the specified receive clock. -fx, -glitch_swallowed, -glitch_caught FX checks to turn on for the matching scheme instances. Checks that are not specified are explicitly turned off. -fx Turns on the FX check. Default: FX check off. -glitch_swallowed Turns on the glitch_swallowed check, which ensures that metastability injection does not swallow a glitch detected by simulation. Default: off. -glitch_caught Turns on the glitch_caught check, which ensures that metastability injection does not catch a glitch undetected by simulation. Default: off.
Description The -fx option to cdc generates CDC-FX checkers with metastability injection logic. The CDCFX checkers have three checks: fx, glitch_swallowed and glitch_caught. By default, the fx checks are on for multi_bits, dmux, simple_dmux, multi_sync_mux_select, handshake and no_sync schemes. For other CDC schemes the fx checks are default off. For all schemes, the glitch_swallowed and glitch_caught checks are default off. Use the set_cdc_fx_check directive to override these default switches. For example, to turn on the fx, glitch_swallowed and glitch_caught checks for all instances of the dmux scheme:
set_cdc_fx_check -scheme dmux -fx -glitch_swallowed -glitch_caught
To turn off all FX checks (yet still perform metastability injection) for all instances of the dmux scheme:
set_cdc_fx_check -scheme dmux
268
Command Reference set_cdc_fx_metastability_window
set_cdc_fx_metastability_window
Sets the metastability window for the CDC-FX clocks. Syntax set_cdc_fx_metastability_window -start value -stop value [-tx_clock clock_signal] [-rx_clock clock_signal] [-percent] -start value The -start value specify 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. -stop value The -stop value specify 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. The -stop value cannot be negative. -tx_clock <tx_clock> If the directive specifies -tx_clock and -rx_clock, then the directive applies to cdc_fx checkers with these clock pairs. If the directive omits -tx_clock and -rx_clock, then the directive applies to the remaining cdc_fx checkers. It is an error to specify more than one directive without the -tx_clock and -rx_clock arguments. -rx_clock <rx_clock> If the directive specifies -tx_clock and -rx_clock, then the directive applies to cdc_fx checkers with these clock pairs. If the directive omits -tx_clock and -rx_clock, then the directive applies to the remaining cdc_fx checkers. It is an error to specify more than one directive without the -tx_clock and -rx_clock arguments. -percent With the -percent option, all the numbers specified become percentage of the Rx clock, rather than absolute numbers. Description Sets the metastability window for the CDC-FX clocks. See set_cdc_fx_metastability_window on page 163 for additional information. You can specify the metastability window as a percentage of the Rx clock rather than an absolute value. Example Following is an example of setting the metastability window as a percentage:
// 0in set_cdc_fx_metastability_window -start 10 -stop 5 -percent
In this example, start is 10% of the Rx clock and stop is 5% of the Rx clock.
269
Command Reference set_cdc_fx_timescale
set_cdc_fx_timescale
Sets the timescale for CDC-FX logic. Syntax set_cdc_fx_timescale unit/precision unit Time unit (in ns, ps or fs). precision Precision (in ns, ps or fs). Description By default, the timescale at the end of the testbench files is used for CDC-FX logic. Use set_cdc_fx_timescale to override the default. Example
set_cdc_fx_timescale 1ns/10ps
270
Command Reference set_cdc_handshake_preference
set_cdc_handshake_preference
Sets preferences for handshake CDC schemes, if they are enabled in CDC static analysis. Syntax set_cdc_handshake_preference [req_unsync] [ack_unsync] [skip_ack_tx_path] [check_mux_recirculation] [handshake_effort {medium | high}]
Tx Clock Domain Rx Clock Domain
MUX recirculation
ack-tx path
en
DEST FSM
SRC FSM rx_clk handshake loop acknowledge synchronizer request synchronizer
tx_clk
req_unsync Reports handshake schemes that do not have a synchronizer for the request path in the handshake loop.
ack_unsync Reports handshake schemes that do not have a synchronizer for the acknowledge path in the handshake loop.
-skip_ack_tx_path Reports handshake schemes that do not have a connection from the acknowledge path of the handshake loop to the Tx logic.
-check_mux_recirculation Only reports handshake schemes that include a MUX recirculation path from the receiver. -handshake_effort {medium | high} Increases the effort spent to detect the req/ack loops of suspected handshake schemes at the expense of increased runtime. Default: low.
Description Changes the template used to detect handshake CDC schemes. Handshake schemes are distinguished from simple MUX schemes when a set_cdc_preference directive specifies the -handshake_scheme option. The set_cdc_handshake_preference options select the elements of the logic template used to identify handshake schemes.
271
Command Reference set_cdc_hier_preference
set_cdc_hier_preference
Sets preferences for hierarchical CDC analysis. Syntax set_cdc_hier_preference [-ctrl_file_models] [-propagate_global_directives] -ctrl_file_models Generate a control file model (CFM) for block-level analysis and use control file models for blocks with missing ILMs for top-level analysis. Default: only the interface logic model (ILM) is generated missing ILMs are treated as black boxes during top-level analysis. -propagate_global_directives Propagate all global directives in control files specified to cdc -report_constraints to the hierarchical block control files. This option expands and distributes wildcard patterns through the hierarchy, but also decreases performance. Default: faster heuristic algorithm propagates global directives to the block-level control files. Certain directives are skipped. Description During block-level analysis, cdc generates a CDC interface logic model of the block for use in top-level CDC analysis. Specifying -ctrl_file_models at the block level also generates a CDC control file model named 0in_cdc_hier_block_ctrl.v (see Control File Models on page 131). If you specify set_cdc_hier_preference -ctrl_file_models in a top-level CDC control file, the directive is propagated to the block levels via the hierarchical control files (during report constraints). However, it is not necessary to specify this directive for the top-level analysis run. Examples The following steps generate a control file model for block2 and use the control file model for block2 in the top-level analysis. Assume block1 and block3 have already been analyzed and interface logic models for them exist in the default cache directories. 1. Ensure set_cdc_hier_preference -ctrl_file_models directives are specified for the blocklevel analyses.
shell prompt> more 0in_hier/block2/block2_ctrl.v . . . // set_cdc_hier_preference -ctrl_file_models
2. Run block-level CDC analysis.

shell prompt> 0in -cmd cdc -d top -od 0in_hier/block2 \ -ctrl 0in_cdc_hier_constraints_block2_ctrl.v -hier_block blk2 \ 0in_hier/block2/block2_ctrl.v
3. Run top-level CDC analysis specifying the control file model generated in step 2.
shell prompt> 0in -cmd cdc -d top -od 0in_hier/top \ -ctrl 0in_hier/top/top_ctrl.v \ -hier_cache 0in_hier/blk1/0in_cache 0in_hier/blk3/0in_cache \ -hier_ctrl_file_model blk2 0in_cdc_hier_block2_ctrl.v
272
Command Reference set_cdc_port_constraint
set_cdc_port_constraint
Sets CDC port constraints for design units identified as custom synchronizers. Syntax set_cdc_port_constraint module_pattern -ports port_pattern [-tx_clock_groups clock_group] [-rx_clock_groups clock_group] [-clock_group_pair tx_clock_group rx_clock_group] module_pattern One or more custom synchronizer design units. -ports port_pattern Ports used to determine the constraints. -tx_clock_groups clock_group Clock groups allowed for the transmitting domain. -rx_clock_groups clock_group Clock groups allowed for the receiving domain. -clock_group_pair tx_clock_group rx_clock_group Tx/Rx clock domain pairs allowed. Description CDC port constraints are restrictions on which clock domains are allowed for signals that connect to ports of instances of a design unit. The set_cdc_port_constraint directive assigns CDC constraints to ports of design units. Currently, CDC port constraints are supported only for custom synchronizers (i.e., design units identified with set_cdc_synchronizer custom directives). CDC analysis reports custom synchronizer ports that violate their port constraints as port_constraint_mismatch violations. The module_pattern argument identifies the design units (which must be custom synchronizers) for the directive. Each matching design unit should have one or more ports with names that match the -ports port_pattern argument or a warning is issued for that design unit. How you specify port constraints depends on the type of custom synchronizer: custom_sync Use a single directive. Specify one or more input ports with the -ports argument. Use -tx_clock_groups to specify valid clock domains for signals connected to the inputs. Use -rx_clock_groups to specify valid clock domains for clocks that synchronize the signals connected to these inputs. Use -clock_group_pair arguments to identify valid pairs of clock domains associated with these input ports.
273
custom_sync_with_crossing Use two directives. For the first directive, specify one or more input ports using the -ports argument and use -tx_clock_groups to specify valid clock domains for signals connected to these inputs. For the other directive, specify one or more output ports with the -ports argument and use -rx_clock_groups to specify valid clock domains for signals connected to these outputs. Do not use the -clock_group_pair argument.
The clock_group arguments must be specified as clock groups at the top level (as specified in the User-specified Clock Groups and Inferred Clock Groups tables of 0in_cdc_design.rpt). They are not clocks specified with respect to the design units specified by module_pattern. Examples Example 1
// 0in set_cdc_synchronizer custom -module sync_2dff // 0in set_cdc_synchronizer custom -module sync_3dff // 0in set_cdc_port_domain -module sync_2dff IN -clock clks_slow
Identifies sync_2dff and sync_3dff as custom synchronizers.

/* 0in set_cdc_port_constraint sync_2dff -ports IN -rx_clock_groups clks_slow */ // 0in set_cdc_port_domain -module sync_2dff IN -clock clks_slow
Restricts signals connected to the IN port of sync_2dff to the domain of clock group clks_slow.
/* 0in set_cdc_port_constraint sync_3dff -ports IN -rx_clock_groups clks_fast */ // 0in set_cdc_port_domain -module sync_3dff IN -clock clks_fast
Restricts signals connected to the IN port of sync_3dff to the domain of clock group clks_fast. Example 2
// 0in set_cdc_synchronizer custom -module sync_2dff // 0in set_cdc_port_domain -module sync_2dff IN -clock clk1 /* 0in set_cdc_port_constraint sync_2dff -ports IN -rx_clock_groups clk1 clk2 -clock_group_pair clk3 clk5 -clock_group_pair clk4 clk6 */
Restricts signals connected to the IN port of sync_2dff to the domains of the following clock groups: clk1 clk2 clk3 (but only if the IN port of the sync_2dff instance is clocked by clk5) clk4 (but only if the IN port of the sync_2dff instance is clocked by clk6)
274
Note that the allowed domains are additive. That is, sync_2dff can legally synchronize a crossing from clk1, even if IN is clocked by clk5. Example 3
// 0in set_cdc_synchronizer custom -module syncx_2dff // 0in set_cdc_port_domain -module sync_2dff IN -clock clkA
Identifies syncx_2dff as a custom synchronizer. CDC analysis recognizes this design unit as a custom synchronizer with crossing.
// 0in set_cdc_port_constraint syncx_2dff -ports IN -tx_clock_groups clkA
Restricts signals connected to the IN port of the custom synchronizer with crossing syncx_2dff to the domain of clock group clkA. The -tx_clock_groups argument is used because IN is clocked by a transmit domain clock.
// 0in set_cdc_port_constraint syncx_2dff -ports OUT -rx_clock_groups clkB
Restricts signals connected to the OUT port of syncx_2dff to the domain of clock group clkB.
275
Command Reference set_cdc_port_domain
set_cdc_port_domain
Identifies the clock domains of top-level/black-box ports, enables reporting of clock domain crossings from the ports and identifies domains of black box ports for use with hierarchical verification. Syntax set_cdc_port_domain {-input | -output | -inout | port_pattern} {-async | [-async] -clock clock_id | -tx_clock clock_port | -rx_clock clock_port | -ignore} [-same_driver] [-mode mode] [-module module_pattern] [hierarchical_CDC_options] hierarchical_CDC_options ::= [-same_clock port_pattern] [-combo_logic] [-combo_path primary_input_port | -nosync] -input, -output, -inout A collection of ports: all input ports, all output ports, or all inout ports. Can be combined with port_pattern. For example, the following arguments apply the directive to all of the modules ports that are inputs with names that match A*:
-input A*
port_pattern One or more top-level or black box ports (wildcards are allowed). Top-level port matches to bit slices are supported. Matches to bit-sliced black-box ports are not supported.
-async Identifies the ports as asynchronous to all clock domains. For a custom synchronizer module, -clock clock_signal -async means that the associated port is considered asynchronous, but the ports receive domain clock is derived from clock_signal.
-clock clock_id Identifies the clock domain. You can specify a clock signal local to any of the specified modules (or a top clock name if module is not specified) or a clock group name.
tx_clock clock_port | rx_clock clock_port Clock port of -module for the clock domain of the ports. Must be specified with a -module that is also declared as a custom synchronizer (set_cdc_synchronizer custom) with at least two clock ports. The data/signal ports must be identified with either the transmit or the receive clock (in particular, no -async ports); at least one port must be identified with tx_clock and at least one port must be identified with a -rx_clock. Instances of this custom synchronizer module are reported as instances of a custom sync with crossing scheme (see custom_sync_with_crossing on page 205). Otherwise, they are reported as instances of a simple custom_sync scheme.
276
-ignore Identifies primary input ports as driving signals that should be ignored for structural CDC analysis. Also identifies ports of black boxes and custom synchronizers that are driven by signals that should be ignored for CDC structural analysis.
-same_driver Ports are considered driven by the same source driver signal when analyzing single-source reconvergence paths. The divergence depth from the single-source driver to the ports is taken as 1 sequential level for the purpose of calculating the divergence depth of reconverging pathseven if the actual divergence depth inside the black box is greater than 1. Option is supported only on DUT (-d module) inputs.
-same_driver divergence depth = 1 black box synchronizer single-source reconvergence paths depth = 1
synchronizer
synchronizer
Tx Clock Domain
Rx Clock Domain
-mode mode The -mode option specifies the mode name to which the command in question is applicable in modal analysis. The user might have different CDC constraints, such as port domains in different modes. This can be specified as follows:
// 0in set_mode mode1 -set sel 1'b1 // 0in set_mode mode2 -set sel 1'b0 // set_cdc_port_domain in -clock clk1 -mode mode1 // set_cdc_port_domain in -async -mode mode2
With the above example, constraints port in is synchronous to clk1 in mode mode1 and asynchronous in mode mode2. If the user specifies the -mode option with a constraint and is using regular (not modal) CDC analysis flow, then the directive is ignored. -module module_pattern The directive applies to ports on all instances of the modules that match module_pattern. Default: top-level module.
277
-same_clock port_pattern This option is used only for hierarchical verification. The -same_clock option is specified for an input port. This option is used to specify that the port should be in the same clock domain as the other ports. If the two ports are not clocked on the same clock, then a warning is printed. This models cases when two ports of a block are connected to a DMUX synchronizer. One of the ports goes to the select of the DMUX and the other goes to the data bus. The same clock constraint ensures that the DMUX select and data are clocked on the same clock.
-combo_logic This option is used only for hierarchical verification. Identifies a hierarchical blocks input ports with combinational fanout logic and output ports with combinational fanin logic (for hierarchical CDC analysis). With this information, CDC analysis can detect combinational logic before synchronizers:
combinational logic data_a synchronizer clock_a clock_b -combo_logic data_b
black box
-combo_path primary_input_port This option is used only for hierarchical verification. This option is used to model a combination path from a list of primary inputs to a primary output. The option specified for an output port, indicates a combinational path from the input ports to the output. The option takes a list of string names that are the names of primary inputs which have a combinational path to that output. While computing the outputs port domain, the inputs port domain is taken into account. In case of conflicting input port domains, the output port domain is inferred as -async. The -combo_path option is also used in clock propagation when the input is connected to a clock. The output is then treated as a clock and propagated forward.
black box combinational logic -combo_path port_a port_b
port_a
port_b
278
-nosync This option is used only for hierarchical verification. The -nosync option is specified for an input port. This option is used to model a primary input port that is connected to flipflops clocked on different clock domains. Such a port is declared as nosync because any crossing to such a port is a missing synchronizer. In other words, specifies that the port is sampled by a different clock and therefore, is a bad crossing.
sampled by different clock
-nosync
black box clk_b
clk_a
Description The set_cdc_port_domain global directives identify the clock domain characteristics of the ports of the top-level module and internal black boxes. Without information from set_cdc_port_domain directives, CDC only has the logic driven inside the DUT when it analyzes clock domain crossings that originate outside the DUT logic. The set_cdc_port_domain directives have two uses: Enable reporting of clock domain crossings originating outside the DUT. CDC extrapolates what it can from the DUT logic, but since the information is incomplete, reporting all CDC paths can introduce too much noise. Reporting of the related schemes is disabled by default. The set_cdc_port_domain directives provide the details needed to properly analyze crossings through primary ports, so CDC analysis reports schemes involving these ports. Pass hierarchical CDC information from an analyzed hierarchical level to be used in the current level analysis. This information is generated automatically by the CDC tool during hierarchical CDC analysis of other hierarchical levels. The hierarchical_CDC_options (-same_clock port_pattern, -combo_logic, -combo_path primary_input_port and -nosync) are reserved for hierarchical CDC sessions and generate warnings if the hierarchical data for the ports is missing.
279
Examples 1. Each set_cdc_port_domain global directive with a -clock argument assigns all matching ports to the same clock domain (that is, the directive does not assign to multiple clock domains). For example,
module cdc_ctrl; // 0in set_cdc_port_domain a b c clock U1.clk_A // 0in set_cdc_port_domain d clock U2.clk_B endmodule
Wildcards for set_cdc_port_domain directive ----------------------------------------------------------------File t9_ctrl.v : Line 5 ----------------------------------------------------------------*t1 matches rst1 aint1 aout1 bout1 Wildcards for set_cdc_port_domain directive with -module ----------------------------------------------------------------File t9_ctrl.v : Line 6 ----------------------------------------------------------------u*d in module dff3 matches u0.d File t9_ctrl.v : Line 7 ----------------------------------------------------------------u*d in module dff5 matches u0.d File t9_ctrl.v : Line 8 ----------------------------------------------------------------a*2 in module dut matches aint2 aout2
2. This example illustrates single-source reconvergence using the set_cdc_port_domain global directive -same driver option. This example, uses the -same_driver option of the set_cdc_port_domain global directive to report diverging points of primary ports having the same driver. With the single-source depth of 2, use the following global directives:
// 0in set_cdc_port_domain p2 p3 in[1:4] -same_driver // 0in set_cdc_reconvergence -divergence_depth 2
This results in ports p2, p3 and in[1:4] being reported.
280
The code snippet for this example is shown in Example 6-1 on page 281, the schematic view is shown in Figure 6-1 on page 281, and the 0in_cdc.rpt report file is shown in Example 6-2 on page 281. Example 6-1. Single-source Reconvergence Code Snippet
dff f1(clk1, rst1, d, d_tx0); dff f2(clk1, rst1, d_tx0, d_tx1_1); // single-source_depth = 1 Divergence dff f3(clk1, rst1, d_tx0, d_tx1_2); // single-source_depth = 1 sync sync1(clk2, rst2, d_tx1_1, q_rx0_1); sync sync2(clk2, rst2, d_tx1_2, q_rx0_2); Synchronizers Convergence
dff f4(clk2, rst2, q_rx0_1, q_rx1_1); // depth = 1 dff f5(clk2, rst2, q_rx0_2, q_rx1_2); // depth = 1
dff f6(clk2, rst2, q_rx1_1 | q_rx1_2, q_rx2); // depth = 2 dff f7(clk2, rst2, q_rx2, q);
Figure 6-1. Single-source Reconvergence Schematic
Example 6-2. Single-source Reconvergence 0in_cdc.rpt File

Single-source Reconvergence of synchronizers. (SSR) ----------------------------------------------------------------clk2 : end : f6.q (back_depth1.v : 6) (ID:SSR)
281
Command Reference set_cdc_port_domain clk2 : start : sync2.u1.q (back_depth1.v : 6) (Synchronizer ID:two_dff_19004) clk2 : start : sync1.u1.q (back_depth1.v : 6) (Synchronizer ID:two_dff_18748) clk1 : diverge : f1.q (back_depth1.v : 6) (ID:SSR_7566)
282
Command Reference set_cdc_preference
set_cdc_preference
Sets preferences for CDC static analysis. Syntax set_cdc_preference [-multi_clock_convergence] [-unrestricted_reconvergence] [-clock_in_data] [-infer_clock_off] [-allow_enable_in_sync] [-max_cdc_crossings number] [-custom_fx] [-promote_reconvergence] [-promote_async_reset] [-dmux_promote_sample] [-sample_data_stability] [-mult_fanout_async] [-input_async] [-handshake_scheme] [-fifo_scheme] [-delayed_pulse] [-detect_primary_output_clock] [-detect_pure_latch_clock] [-formal_add_bus_stability] [-formal_add_recon_stability] [-filtered_report] [-vectorize_nl] [-ignore_black_box] [-blackbox_empty_module] [-dmux_as_recon_start] [-complex_scheme_as_synchronizer] [-multi_paths] [-clock_as_rx] [-report_bbox_recon] [-report_resets] [-report_undriven_custom_sync] [-print_port_domain_template] [-print_detailed_custom_sync] [-infer_modes_off] -multi_clock_convergence Reports reconvergence with synchronizers in different Rx clock domains or coming from different Tx clock domains. -unrestricted_reconvergence Reports reconvergence for unsynchronized paths (i.e., paths with missing synchronizers, combo logic, and so on). Default: reconvergent paths reported only if no other schemes apply. -clock_in_data Reports all crossings, including clock signals that go to data inputs of registers. In some cases, runtime can increase substantially. Default: CDC crossings of signals used as both clock and data are not reported. -infer_clock_off Disables clock inference. Only user-specified clocks (i.e., specified by set_cdc_clock) are assumed to be clocks. This option lets you avoid grouping inferred clocks. Default: CDC clock analysis infers clocks. -allow_enable_in_sync Recognizes 2-DFF synchronizers with enable signals in the DFFs. Default: 2-DFF synchronizers with enables are not recognized as 2-DFF synchronizers. -max_cdc_crossings number Limits the number of CDC crossings analyzed. Once this limit is reached, no more crossings are analyzed. You can use this option to reduce session time when initially setting up a design for CDC analysis. Default: no limit (number = 0).
283
-custom_fx Allows tx signals in CDC-FX checkers to come from ports and custom synchronizers and allows rx signals to drive custom synchronizers. Injection occurs when tx and rx clocks are aligned and the checker fires when data changes in the metastability window. With this option more false violations can occur. Default: tx signals must come from registers and rx signals must drive only registers.
-promote_reconvergence Promotes cdc_hamming1 checkers for reconvergence schemes. Default: checkers are not promoted for reconvergence schemes.
-promote_async_reset Promotes cdc_sync checkers for async_reset and async_reset_no_sync schemes. Default: checkers are not promoted for async_reset and async_reset_no_sync schemes.
-dmux_promote_sample Promotes cdc_sample checkers for dmux schemes. Default: no protocol checkers are promoted for dmux schemes.
-sample_data_stability Turns on the data_sample check (by specifying -tx_min) for all promoted cdc_hamming_one checkers. Default: cdc_hamming_one checkers are promoted with the data_sample check turned off.
-mult_fanout_async Identifies input ports that fan out to multiple clock domains as asynchronous ports. Default: one clock domain is selected.
-input_async Identifies all DUT input ports as asynchronous ports. Default: all inputs are assumed to be synchronous with their fanout logic.
-handshake_scheme Identifies HANDSHAKE CDC schemes. Default: HANDSHAKE CDC schemes are reported as dmux or multi_bits schemes.
-fifo_scheme Identifies FIFO CDC schemes. Default: FIFO CDC schemes are reported as memory_sync or multi_bits schemes.
-delayed_pulse Recognizes pulse schemes that have a register to delay the output of the pulse synchronizer. -detect_primary_output_clock Detects primary output clocks. An output port of the top module is inferred as a clock port if the fanin logic of the port has a signal either specified as a clock (with set_cdc_clock) or is used to clock a register/latch. Default: clocks are not inferred for top-level output ports.
284
-detect_pure_latch_clock Assumes latch enables are clocks. Default: only latch enable signals that clock another register or that are specified with set_cdc_clock are recognized as clock signals.
-formal_add_bus_stability Adds checks for signal stability to the synchronization schemes gray-coding protocols verified by formal CDC.
-formal_add_recon_stability Adds checks for signal stability to the reconvergence schemes gray-coding protocols verified by formal CDC.
-filtered_report Identifies filtered CDC schemes in the CDC report and in the 0in_cdc static CDC analysis results (GUI). With this preference, schemes identified using the set_cdc_report global directive as filtered (-severity off) and schemes with stable transmit domain signals (set_cdc_signal -stable) are reported. Caution: Can result in increased runtime and memory usage if many set_cdc_report -severity off with wildcards are specified. Default: Filtered schemes are not reported.
-vectorize_nl Reports as a single-bus synchronizer (for example, BUS_TWO_DFF) each CDC scheme where the signals start from the same bus, all the signals are synchronized by the same synchronization scheme and all signals are merged back into a single bus after synchronization. Default: Bus bits that are separately synchronized are reported as single-bit CDC schemes (for example, TWO_DFF).
-ignore_black_box Do not report CDC blackbox crossings to the ports of any blackbox design units that do not have port domain definitions. Default: report blackbox crossing schemes to ports without port domain definitions for inferred blackbox design units. Crossings to user-specified blackbox design units are never reported as blackbox schemes.
-blackbox_empty_module Turns all empty (i.e., stub) modules/entities into inferred black boxes. An empty module/entity is one for which a module or entity/architecture definition is present, but the content is empty. That is, only the I/O ports (with directions) are declared. This option does not apply to unresolved modules/entities. Crossings to or from inferred black boxes are reported to guard against possible real clock domain crossings. To eliminate false positives you should indicate the port domains of inferred black boxes using set_cdc_port_domain directives. Default: empty modules are analyzed as regular modules.
-dmux_as_recon_start Recognizes dmux, simple_dmux and multi_sync_mux_select schemes as starting points for reconvergence schemes.
285
-complex_scheme_as_synchronizer Recognizes dmux schemes that have complex synchronizers as the MUX-select synchronizer. Default: to report a dmux scheme, its MUX-select synchronizer must be a two_dff synchronizer.
-multi_paths Reports all the paths for each clock domain crossing (i.e., Tx/Rx pair). This option can reduce performance significantly. Default: Only one path per crossing is reported in the CDC report.
-report_bbox_recon Reports reconvergence schemes that reconverge at black boxed instances. Default: these schemes are not reported.
-clock_as_rx Reports clock domain crossings to Rx nodes that have clock signals in their fanin cones (and are not registers, latches, primary outputs, or inputs to custom synchronizers or black boxes)unless Tx is part of the clock tree. Default: these crossings are not reported.
-report_resets Reports reset tree data in the design report. Default: reset trees are not reported. -report_undriven_custom_sync Reports as instances of the custom_sync scheme custom synchronizer crossings originating from internal or undriven wires. Default: only reports custom synchronizers that are driven by ports.
-print_port_domain_template Creates a 0in_cdc_port_domain_template.v file with the set_cdc_port_domain directives for the primary ports. Use this template as a starting point for setting up the set_cdc_port_domain constraints. CDC analysis cannot identify the clock domains of the ports as they depend on the DUT external environment. You should review the constraints and adjust as necessary. You can ignore set_cdc_clock directives in the template if you have specified the set_cdc_clock directives in a control file.
-print_detailed_custom_sync Reports custom synchronizers on signals that are not reported as CDC crossings (see Custom Synchronization Modules on page 458). Default: these signals are not reported. To report a custom synchronizer in a CDC crossing, add the -tx/-rx arguments to the set_cdc_port_domain specification.
-infer_modes_off Turns off inferring of modes during cdc -report_modes sessions. Used in special circumstances to reduce cdc run time: if you know the user-defined modes are complete, you do not need to infer other modes. For example, if you run a default -report_modes session and define the inferred modes with set_mode, you can re-run cdc -report_modes with mode inference disabled. Default: -report_modes performs mode inference.
286
Description This global directive defines preferences for CDC. The status of the CDC preferences is printed in the 0in_detail.log file (see Figure 6-2). Figure 6-2. Global CDC Preferences (0in_detail.log)
Global CDC Preferences --------------------------------------------------------------------Option Value --------------------------------------------------------------------multi_clock_convergence FALSE clock_in_data FALSE allow_enable_in_sync FALSE max_cdc_crossings 0 custom_fx FALSE promote_reconvergence TRUE mult_fanout_async TRUE dmux_promote_sample FALSE ignore_black_box FALSE input_async FALSE handshake_scheme FALSE fifo_scheme TRUE delayed_pulse TRUE report_resets TRUE detect_primary_output_clock FALSE formal_add_bus_stability FALSE formal_add_recon_stability FALSE filtered_report FALSE filtered_report FALSE vectorize_nl FALSE unrestricted_reconvergence FALSE multi_paths FALSE report_undriven_custom_sync TRUE print_port_domain_template FALSE dmux_as_recon_start FALSE print_detailed_custom_sync FALSE report_bbox_recon FALSE report_bbox_recon FALSE blackbox_empty_module FALSE sample_data_stability TRUE infer_clock_off TRUE detect_pure_latch_clock TRUE promote_async_reset FALSE complex_scheme_as_synchronizer FALSE infer_modes_off FALSE
Examples
// 0in set_cdc_preference -allow_enable_in_sync // 0in set_cdc_preference -clock_in_data // 0in set_cdc_preference -max_cdc_crossings 200 // 0in set_cdc_preference -filtered_report
287
0in_cdc.rpt includes the following table:

Filtered CDC Checks Summary ================================================================= Single-bit signal does not have proper synchronizer. (no_sync) ----------------------------------------------------------------clk1 : start : X1.cdc_inst.int1 (t21.v : 17) clk2 : end : X1.out2a (t21.v : 36) (ID:no_sync_29270) via : X1.cdc_inst.intt1 Asynchronous reset does not have proper synchronization. (async_reset_no_sync) ----------------------------------------------------------------clk1 : start : X1.cdc_inst.int1 (t21.v : 17) clk2 : end : X1.out2d (t21.v : 36) (ID:async_reset_no_sync_47514) via : X1.cdc_inst.intt1
288
Command Reference set_cdc_protocol
set_cdc_protocol
Identifies a CDC protocol checker type to promote for one or more custom synchronizer modules. Syntax set_cdc_protocol checker_type -module custom_synch_pattern [-rx_clock clock] [-tx_var signal] checker_type Type of checker to promote. Currently, only values of cdc_sync and cdc_hamming1 are supported. -module custom_synch_pattern Custom synchronizer modules. -rx_clock clock Rx clock signal in the synchronizer. Default: if the synchronizer has only one clock port, that clock is inferred as the Rx clock. Otherwise, a warning is issued and the directive is skipped. -tx_var signal Transmit domain CDC input signal in the synchronizer. Default: if the synchronizer has only one data input port, that signal is inferred as tx_var. Otherwise, a warning is issued and the directive is skipped. Description Used with the set_cdc_synchronizer directive to identify custom synchronizers for CDC analysis. Static CDC analysis assumes each module specified by a set_cdc_synchronizer directive is a custom synchronizer. The set_cdc_protocol directive indicates a type of checker to promote to check the CDC transfer protocol for schemes that are synchronized by one of the matching synchronizers. The directive needs the module name pattern of the synchronizers and the checker type for the promoted protocol checkers. Currently, only the cdc_sync and cdc_hamming1 checker types are supported. A basic custom synchronizer has an Rx clock input, a Tx domain input and an Rx domain output. Currently, this is the only type of custom synchronizer supported by set_cdc_protocol. If two set_cdc_protocol directives reference the same port, a directive-273 warning is issued and the second directive is ignored.
289
Command Reference set_cdc_protocol
Example
// 0in set_cdc_synchronizer cust -module cust_sync1 // 0in set_cdc_port_domain D -async -module cust_sync1 // 0in set_cdc_protocol cdc_sync -module cust_sync1
Promotes the following checker directive, where tx_var is the signal connected to the D port of the cust_sync1 instance, tx_clock is the inferred clock in cust_sync1 and clock_ratio is the ratio of the inferred Rx/Tx clocks.
/* 0in cdc_sync -tx_var tx_var -tx_clock tx_clock -tx_min clock_ratio */
290
Command Reference set_cdc_reconvergence
set_cdc_reconvergence
Specifies reconvergence control parameters. Syntax set_cdc_reconvergence [-check off] [-depth depth] [-divergence_depth depth] [-tx_clock clock] [-rx_clock clock] [-bit_recon] -check off The -check option is used to turn off reconvergence checking totally. The default is On. -depth depth Maximum sequential reconvergence depth for reporting reconvergence and single-source reconvergence CDC schemes.
depth 3 synchronizer 3 sequential levels
synchronizer 3 sequential levels synchronizer 2 sequential levels reconvergence paths combinational logic
Tx Clock Domain
Rx Clock Domain
The sequential reconvergence depth is the number of sequential levels from the storage element after the synchronizer to the reconvergence point. In cases where the reconvergent paths have different numbers of levels, the sequential reconvergence depth is the largest number of sequential levels. For example, suppose paths A and B are reconvergent with 5 and 8 sequential levels to the reconvergence point respectively. Then this scheme instance is not reported as a reconvergence violation if set_cdc_reconvergence sets -depth 5, but is reported if set_cdc_reconvergence sets -depth 8. Default: 0. -divergence_depth depth Enables reporting of single-source reconvergence and sets the divergence depth. Default: instances of SSR schemes are reported only as reconvergence schemes.
291
Command Reference set_cdc_reconvergence
divergence_depth 2 synchronizer
depth 2
synchronizer
synchronizer single-source reconvergence paths
Tx Clock Domain
Rx Clock Domain
combinational logic
-tx_clock clock Restricts the directive to paths originating in the Tx clock domain. -rx_clock clock Restricts the directive to paths terminating in the Rx clock domain. bit_recon Report as instances of the reconvergence scheme, those paths where the individual bits of the output of a bus 2DFF synchronizer are re-combined.
bus 2DFF
re-converging bits
Description Use this global directive to specify reconvergence control parameters.
292
Command Reference set_cdc_report
set_cdc_report
Sets the severity level and promotion property of matching clock domain crossings. Syntax set_cdc_report { -severity severity [-scheme sync_scheme] [-promotion {on | off | protocol | fx}] | -default_severity severity -scheme sync_scheme} [-default_promotion {off | on}] [-tx_clock clock_signal] [-rx_clock clock_signal] [[-from var_pattern] [-through var_pattern] | -from_signals var_pattern ] [-to variable_pattern] [-message string] [-mode mode] [-module module_pattern] severity := {violation | caution | evaluation | waived | off} Arguments -severity {violation | caution | evaluation | waived | off} The severity levels are violation, caution, evaluation, waived, or off. Specifying off removes the crossings from CDC analysis. Paths filtered out from the report with the set_cdc_report -severity off directive are reported in the 0in_cdc.rpt file with the cdc -verbose command. The results are reported at the end of the file in the section titled Filtered CDC Checks Summary. Note that the tool runtime and memory consumption can increase when a large number of set_cdc_report global directives with wildcards are used. When multiple set_cdc_report directive with conflicting -severity arguments apply to the same scheme, -severity off takes precedence. Otherwise, one of the severities is selected and warnings are reported. You can set any crossing as waived by using the set_cdc_report global directive. For example,
// 0in set_cdc_report -severity waived
By default, crossing that are waived are not promoted. The waived crossing can be promoted using the following:
// 0in set_cdc_report -severity waived -promotion on
When -severity is used to set the severity of a particular crossing to violation, formal CDC does not analyze the crossing (so the crossing remains a violation). -scheme sync_scheme Set attributes for crossings conforming to the specified scheme type (for example, single_source_reconvergence, dmux, and so on). Default: all schemes. -promotion {on | off | protocol | fx} Whether or not to promote transfer protocol and/or FX checkers for the matching crossings (when the -compile_assertions to cdc is specified). You also must specify the -severity for the crossings. Off turns off all matching promoted checkers. On turns on all matching
293
promoted checks. FX checkers are generated only if the -fx option to cdc is specified. Protocol turns on just the protocol checkers; fx turns on just the FX checkers. -default_severity {violation | caution | evaluation | waived | off} Sets the default severity for the specified scheme type. Directive is ignored if any arguments other than -scheme and -module are specified. -default_promotion {off | on} Whether or not to promote a CDC protocol assertion if no other -promotion options apply. Although by default CDC protocol assertion promotion is on, the -default_promotion on is useful when severity or default severity is off (which usually turns off CDC protocol assertion promotion). For example, the following directive turns severity off for bus_shift_reg schemes, but retains CDC protocol assertion promotion:
/* 0in set_cdc_report -scheme bus_shift_reg -severity off -default_promotion on */
-tx_clock clock_signal Crossings from transmission logic clocked by a particular clock. -rx_clock clock_signal Crossings to receive logic clocked by a particular clock. -from variable_pattern, -to variable_pattern, -through variable_pattern One or more paths that include CDC crossings. You can specify any combination of -from, -to, and -through arguments (but multiple -from variables only are allowed for the reconvergence and single_source_reconvergence schemes). The -through variable_pattern argument specifies a wire in the paths. These wires are the waypoints shown as VIA points in the CDC report. You can include wildcards and slices in variables and wire names. To match the specification, a path must pass through wires specified by every -through argument. The directive is ignored if you specify -through with -scheme reconvergence or -scheme single_source_reconvergence and a directive-214 warning is issued: Unmatched CDC crossing specified. If a CDC crossing originates from (-from) or ends at (-to) a stable variable (see set_cdc_signal on page 299), then the crossing is removed from CDC analysis. Even though the -to variable_pattern does not support multiple signal names, a wildcard pattern can be specified that has multiple matches. For example, the following directive turns off multiple crossings:
//0in set_cdc_report -to a.gen*.c -severity off
Schemes other than the reconvergence scheme do not allow specification of more than one signal in the -from option (including wildcard matches). A directive that violates this rule is ignored, in which case the CDC compiler issues a warning message. In the special case of reconvergence to black boxes (i.e., set_cdc_preference -report_bbox_recon) the -to variable_pattern can be the instance name pattern of one or
294
more black-boxed modules. To be considered a reconvergent path, the two converging paths need only end at any port of the same black boxed instance. -from_signals variable_pattern This option is used only for reconvergence analysis. Specifies variables that identify registers or wires that contain data in one clock domain that are separately synchronized and then recombined in another clock domain. The difference between -from and -from_signals is that -from takes the OR of the signals and -from_signals takes the AND of the signals. You must specify -scheme reconvergence with this option, otherwise, the directive is ignored and the CDC compiler issues the following warning message:
Warning: Reconvergence scheme must be used when the -from_signals option is specified. Directive set_cdc_report. : Directive will be ignored.[hdl-86]
If both -from and -from_signals options are specified, the directive is ignored and the CDC compiler issues the following warning message:
Warning: Options from and from_signals specified. Directive set_cdc_report. : Directive will be ignored.[hdl-104]
If the variable_patterns have no wildcards, the list of signals must be completein particular, the list must include two or more signalsthe directive only applies to reconvergence instances where all of the specified source signals reconverge. If the variable_patterns have wildcards, the directive only applies to reconvergence instances where every variable_pattern has a matching start point and the matched start points are complete. Fore example, consider the following argument:
from_signals A* B C
The directive matches reconverging paths that have the following (complete) sets of start points: (A1 B C) and (A1 A2 B C). The directive does not match reconverging paths that have the following (complete) sets of start points: (B C) and (A1 B C E). -message string Message string to add to the path reports of matching CDC schemes. Default: no message added. -mode mode The -mode option specifies the mode name to which the command in question is applicable in modal analysis. If you specify the -mode option with a constraint and is using regular (not modal) CDC analysis flow, then the directive is ignored. -module module_pattern The global directive applies to matching CDC crossings in all instances of the module specified by module_pattern. Wildcards are allowed, in which case the directive applies to
295
all instances of the matching modules. If the -module option is omitted, then the directive applies the -d module. Example 1:
//0in set_cdc_report -module A -severity caution
Only crossings completely within the same instance of A are set to caution. Crossings across instances of A are not affected. Example 2:
//0in set_cdc_report -module A -from B -severity caution
Crossings in which the from signal is X.B are set to caution, where X is any instance of module A. Description The set_cdc_report global directive sets the severity level and promotion property of matching clock domain crossings. Use this directive to override the default severity and promotion of clock domain crossing checks. Specify one of the following: -severity severity with an optional -scheme or -promotion. -default_severity severity -scheme sync_scheme
If you do not specify other arguments, then the directive applies to all CDC crossings. If you do not specify other arguments except -module module, then the directive applies only to crossings entirely within module. Otherwise, you can specify a combination of arguments to identify one or more CDC crossings. The specified crossings are all of those that match all of the criteria. If -module module is specified, these crossings need not lie completely inside module. Note that an increase in runtime and memory usage can occur when a large number of set_cdc_report global directives with wildcards are used with the -verbose option of cdc. Also, -severity off turns off promotionso, -severity off -promotion on generates a warning message and the directive is ignored. Example 1: set_cdc_report
module cdc_ctrl; /* 0in set_cdc_report -scheme blackbox -from out2a -to bb1.* -severity off */ // 0in set_cdc_report -scheme two_dff_phase -severity evaluation endmodule
296
Example 2: -verbose Option Following are -verbose examples: -verbose and wildcard expansion
//0in set_cdc_report -from A*B -severity off
If A*B is an invalid signal and does not exist in the design Without -verbose Warning message directive-214 With -verbose Warning message hdl-77 -verbose and reconvergence
/*0in set_cdc_report -from_signals A* B* C* -scheme reconvergence -severity off */
Case 1
For reconvergences from (A, B) to (D) (G, E, F) to (H) (AL, BL, CL, DL) to (M)
With -verbose The reconvergences ending at D and M have at least one matching start point so the following warning messages should appear: Warning message directive-235 for recon ending at D for C* directive-236 for recon ending at M for DL Without -verbose Warning message directive-214 Case 2
For reconvergences from (G, E, F) to (H) (X, Y, Z) to (M).
With and without -verbose Warning message directive-214, since not even one start point matched in any of the reconvergences.
297
Case 3
If there are reconvergences from (A, B) to (D) (G, E, F) to (H) (AL, BL, CL) to (M)
With and without -verbose No warning message because (Al, BL, CL) matched exactly. Example 3: Set All DMUX Crossings to Evaluation This example illustrates using the set_cdc_report global directive to set all DMUX crossings to evaluation, except for those that start from A and end at B.
// 0in set_cdc_report -scheme demux -severity evaluation // 0in set_cdc_report -from A -to B -severity waived
Warnings are produced when there are conflicts.
298
Command Reference set_cdc_signal
set_cdc_signal
Reclassifies the CDC signal type of specified CDC signals or adds properties to specified CDC signals. Syntax set_cdc_signal variable_pattern [-split] [-stable] [-gray_coded] [-module module_pattern] [-mode mode] [-merge] variable_pattern One or more CDC signals. Names can include wildcards and can be bit slices. The classification or CDC property assigned by the directive is applied to all matching variables. -split Treats bits of the specified multiple-bit registers/latches as individual control signals for CDC analysis. By default, synchronization of a CDC data bus must be performed on the whole bus. If not, then the bus is marked with a BUS SYNC warning. But, if a register has only one bit derived from a CDC signal, then synchronization of that bit should be allowed. For example, a status bit might be extracted from a state variable or a single multiple-bit register (for example, a status register) might store amalgamated control signals. Splitting a CDC data bus for CDC analysis eliminates the BUS SYNC warning. Treating bits individually is independent of the synchronization type: the bits can be synchronized with control synchronization (for example, 2DFF) or data synchronization (for example, DMUX). You might want to treat bits in a bus individually for any of the following reasons: Only some bits of the bus cross a clock domain boundary. Different bits in the bus go to different clock domains. The bus is a collection of individual signals (such as status signals) that you want to consider as individual bits.
Various bits of a split bus can be used together in the destination domain (for example, in a receiving state machine decoding). To check for reconvergence problems, CDC analysis identifies these crossings as potential RECONVERGENCE warnings. -gray_coded Identifies the specified variables as properly gray-coded data buses for CDC analysis. 2DFF and four latch synchronizations can be valid for a gray-coded data bus. So by default, checks for CDC data buses that have either of these types of synchronizers are promoted as a cdc_hamming_distance_one checkers to verify gray-coding and synchronization. Identifying a particular variable as gray-coded indicates the data bus is properly gray-coded (that is, with gray coder/decoder logic), so gray-code checking is unnecessary. In this case, the crossing check is promoted as a cdc_sync checker.
299
Command Reference set_cdc_signal
-stable Identifies the specified variables as stable for CDC analysis. CDC analysis considers a stable variable (and its propagated values) as properly synchronized. The -stable option has no effect if signal is not an Rx or Tx of a CDC crossing, or if signal cannot be propagated to an Rx of a CDC crossing, or if signal drives an input of combinational logic whose output is not stable. To see the signals marked as stable that have no effect on CDC analysis, specify the set_cdc_preference -filtered_report directive and review the Filtered CDC Checks Summary section in 0in_cdc.rpt.
-module module_pattern The global directive applies to matching CDC signals in all instances of modules that match module_pattern. If -module is omitted, the global directive applies to the -d module.
-mode mode The -mode option specifies the mode name to which the command in question is applicable in modal analysis. If you specify the -mode option with a constraint and is using regular (not modal) CDC analysis flow, then the directive is ignored.
-merge Merge the signals into a single signal for CDC analysis.
Description The set_cdc_signal global directive reclassifies the CDC signal type of specified CDC signals or adds properties to specified CDC signals. Use this directive to override the inferred classifications of CDC signals and to identify synchronization properties of particular CDC signals. Specify the following: signals -split, -gray_coded, or -stable
Note that all CDC crossings filtered by the // 0in set_cdc_signal -stable global directive are reported at the end of the 0in_cdc.rpt file when the cdc -verbose command option is used. Examples Example 1
module cdc_ctrl; // 0in set_cdc_signal tx_status control module mtr // 0in set_cdc_signal write_addr gray_coded module pci_if endmodule
The list of wildcard expanded signals are reported in the 0in_detail.log file. Following is a sample control file showing the use of wildcards with the set_cdc_signal global directive:
module check; // 0in set_cdc_clock clk1
300
Command Reference set_cdc_signal // 0in // 0in // 0in // 0in endmodule set_cdc_clock clk2 -group g2 set_cdc_signal out[1:4] -module dff20 -stable set_cdc_signal * -module dff40 -split set_cdc_signal q -module *10 -gray_coded
Following is the information regarding the wildcard expanded signals that are reported in the 0in_detail.log file for the above example:
Wildcards for set_cdc_signal directive with -module ----------------------------------------------------------------File t28_ctrl.v : Line 5 ----------------------------------------------------------------* in module dff40 matches clk rst ena d q File t28_ctrl.v : Line 6 ----------------------------------------------------------------q in module dff10 matches q
Example 2
sig_b sig_a tx_clk -stable might not be stable rx_clk combo logic sig_c
set_cdc_signal sig_a -stable has no effect
Marking sig_a as stable has no effect on CDC analysis because the sig_b input to the combo logic block might make sig_c unstable. Therefore, a combo_logic violation is reported. Specifying set_cdc_preference -filtered_report causes CDC analysis to report signals marked as stable that do not affect CDC analysis (see the 0in_cdc.rpt).
301
Command Reference set_cdc_synchronizer
set_cdc_synchronizer
Identifies nonstandard synchronizer types and their corresponding properties. Syntax set_cdc_synchronizer { dff {-level level | -min level -max level} [-tx_clock clock_signal] [-rx_clock clock_signal] | latch -level level [-tx_clock clock_signal] [-rx_clock clock_signal] | custom -module module_pattern} [-mode mode] dff, latch. or custom DFF, latch or custom synchronizer. -level level Number of DFF or latch instances in the synchronizer. Single-bit crossings synchronized by this type of synchronizer are considered properly synchronized by default; they have evaluation severity. Default: 2 for DFF synchronizers and 4 for latch synchronizers. Note the following: If you set the level to N, then the number of DFF in the synchronizers should be exactly N. If there are < N DFFs, then the synchronizer will have severity violation. If there are > N DFFs, then the synchronizer will have severity evaluation; but if it is used to control other crossings (like DMUX), then the tool will not be able to recognize it. In this case, you should use the -min and -max options to define a valid window of delays.
You can restrict the assignment to DFF synchronization schemes on signals from a specified -tx_clock domain, or to a specified -rx_clock domain, or on signals between both. -min level Minimum number of DFFs to be considered a dff synchronizer. If a crossing has fewer than level DFFs in series, a MISSING_SYNCHRONIZER violation is reported. -max level Maximum number of DFFs in the dff synchronizer. If a crossing has more than level DFFs in series, a MISSING_SYNCHRONIZER violation is reported. -tx_clock clock_signal Restricts the directive to dff/latch synchronizers with Tx clock -tx_clock clock_signal. -rx_clock clock_signal Restricts the directive to dff/latch synchronizers with Rx clock -rx_clock clock_signal.
302
-module module_pattern The module name of the custom synchronizer. A custom synchronization scheme must be contained within its own module definition. You must identify the synchronizer module (that is, the -module option is required). You can use wildcards in the module identifier; the custom synchronizer specification applies to all matching modules.
-mode mode The -mode option specifies the mode name to which the command in question is applicable in modal analysis. If you specify the -mode option with a constraint and are using regular (not modal) CDC analysis flow, then the directive is ignored.
Description The set_cdc_synchronizer global directive identifies nonstandard synchronizer types and their corresponding properties. Use this directive to configure CDC analysis to handle specific DFF or custom synchronizers. Each global directive identifies a single synchronizer type; therefore, you must specify only one synchronizer type (dff, latch or custom).
Examples
Example 1
// 0in set_cdc_synchronizer custom -module cust_2sync // 0in set_cdc_port_domain in1 out2 -clock clk1 -module cust_2sync // 0in set_cdc_port_domain in2 out1 -clock clk2 -module cust_2sync
Identifies cust_2sync as a custom synchronizer module and assigns the clock domains of its data ports. Example 2
// 0in set_cdc_synchronizer dff -min 2 -max 4
Specifies that 2-, 3- and 4-delay DFFs are valid DFF synchronizers. Note that a 5-delay DFF is not a valid synchronizer. Example 3
// 0in set_cdc_synchronizer dff -level 1
Specifies that 1-delay DFFs are valid DFF synchronizers. Example 4

// 0in set_cdc_synchronizer custom -module cust_sync // 0in set_cdc_port_domain in -async -clock clk_rx -module cust_sync
Identifies cust_sync as a custom synchronizer module; identifies in as an asynchronous port and identifies the clk_rx port as the receive clock for clock domain crossings through the in port.
303
Example 5 (Internal-crossing Custom Synchronizer)

// // // // // 0in 0in 0in 0in 0in set_cdc_synchronizer custom module INT_SYNC set_cdc_port_domain sig_tx tx_clock clk_tx -module INT_SYNC set_cdc_port_domain sig_rx rx_clock clk_rx -module INT_SYNC set_cdc_protocol cdc_sync -module INT_SYNC set_cdc_protocol cdc_hamming1 -module INT_SYNC Internal-crossing Custom Synchronizer
Tx Clock Domain sig_tx Rx Clock Domain DFF DFF sig_rx
clk_tx
clk_rx
INT_SYNC
The INT_SYNC module is a custom synchronizer module where the transmitting register is internal to the module. In particular, the clock domain crossing for the synchronizer occurs within the custom synchronizer module itself. The set_cdc_synchronizer directive specifies INT_SYNC as a custom synchronizer module. The two set_cdc_port_domain directives declare the INT_SYNC to be an internal-crossing synchronizer (compare with Example 1). The two set_cdc_protocol directives promote pulse-width and gray-code checkers for the driver of sig_tx. An internal-crossing custom synchronizer module is identified when all the following requirements are met: A set_cdc_synchronizer custom directive with multiple clock ports is specified for the module. No ports of the module are defined as asynchronous (set_cdc_port_domain -async). At least one transmit clock and one receive clock are identified using the set_cdc_port_domain options -tx_clock and -rx_clock.
304
Command Reference set_constant
set_constant
Assumes a variable is kept at a specified constant value for CDC analysis. Syntax set_constant variable_pattern constant [-module module_pattern] variable_pattern Hierarchical name pattern for the variables, specified relative to the DUT. Pattern matches can be bit slices. constant Constant Verilog or VHDL value for variable. If constant has fewer bits than variable, then constant is zero-extended. If constant has more bits than variable, then the high-order bits of constant are truncated. All nets connected to variable are forced to the constant value. -module module_pattern Module or modules containing variable. Description CDC analysis keeps variable set to constant. This directive can be used on internal variables. The set_constant directive simplifies the CDC model by discarding part of the DUT circuitry during cdc compilation. For example, this capability is useful for disabling test logic to reduce DUT size. Example
// 0in set_constant U0.rst 1'b1
CDC analysis assumes the port U0.rst is held at 1'b1.

// 0in set_constant U0.in[1:4] 4'b1010
CDC analysis assumes the port slice U0.in[1:4] is held at 4'b1010.
305
Command Reference set_constant_propagation
set_constant_propagation
Propagates constants through sequential logic. Syntax set_constant_propagation [reset] [enable] -reset Value of the D-input of the register can be different from the reset value. The propagated value only depends on the D-input. For example,
always @(posedge clk) if (rst) q <= 1'b0 else q <= d;
Constant d is not propagated through this register with:

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

// 0in set_constant d 1'b1 // 0in set_constant_propagation -reset
and:
-enable Propagates through registers with non-constant enables. For example,

always @(posedge clk) if (rst) q <= 1'b0; else if (enable) q <= d;
Constant d is not propagated through this register with:

But, constant d is propagated through this register with:

// 0in set_constant d 1'b0 // 0in set_constant_propagation -enable
and:
// 0in set_constant d 1'b0 // 0in set_constant enable 1'b1 // 0in set_constant_propagation
You should always include this argument when specifying set_constant_propagation for formal analysis.
306
Command Reference set_constant_propagation
Description Simplifies CDC and formal models by propagating constant values set by the RTL source code or by set_constant through sequential logic, including latches.
307
Command Reference set_memory
set_memory
Sets the memory model type for specified multidimensional arrays. Syntax set_memory {{-exact | -abstract} [mem_pattern]} [-module module_pattern] mem_pattern Name pattern for one or more multidimensional arrays. Pattern can be hierarchical, can contain wildcards and can be repeated. Default: * -exact | -abstract How the arrays are modeled: -exact models the arrays as register logic; -abstract models them as abstract memories. The default model for each multidimensional array is determined by heuristic analysis. -module module_pattern Module patterns for modules containing multidimensional arrays that match mem_pattern. Default: * (all modules). Description Selects the type of model to use (exact or abstract) for the specified multidimensional arrays. Used to override memory modeling assignments made by the csl and cdc compilation heuristics. The following example sets ram32x512 in module sram to be modeled as an abstract memory and ram4x16 to be modeled as an exact memory.
reg [32] ram32x512 [511:0] //0in set_memory -abstract ram32x512 -exact ram4x16 -module sram
Exact memories are modeled as register banks. They are simple sequential logic, so they behave as RTL logic in CDC and formal analysis (i.e., they match the design behavior exactly). When a very large multidimensional array is modeled exactly, the footprints of the formal and CDC models can be too large and analysis can be too slow. So, logic models for these memories are abstracted. For formal verification, an abstract model of a multidimensional array is a partial model of the memory. For formal proofs, the memory outputs are treated as inputs controllable by the proof algorithms. Proven assertions are legitimately proven, but proofs can be missed that would otherwise be found if the model were exact. Formal firings are found in two ways. When the partial model of a memory is used for a firing, the behavior of the memory is modeled exactly. The firing is a violation and is reported as a regular firing. Otherwise, if formal analysis can fire the target by controlling the part of the memory that is not exact, the violation is reported as a firing with a warning. For CDC analysis, an abstract model of a multidimensional array is treated as a black box.
308
Command Reference set_memory
By default, the csl and cdc compilers use similar (but slightly different) heuristic analyses to determine which multidimensional arrays are selected for abstract modeling. Each abstracted memory is reported by an SPC warning:
Warning SPC-116 Abstracting large memory. Memory mem in module module
The set_memory directive is used to override this selection, typically with the -abstract option to force the modeling for one or more memories to be exactfor example, if an assertions fanin logic has an abstract memory that is causing a firing with a warning. The set_memory directive also is used to force an exact memory to be abstractedfor example, to reduce system memory usage or to speed up analysis.
309
Command Reference set_mode
set_mode
Selects a mode of operation for CDC analysis.. Syntax set_mode mode {-set variable value} [-ignore] mode The mode is the current mode name. -set variable value Constant values in the mode. -ignore Mode is not to be considered for analysis. Description The set_mode global directive is used to create a mode of operation (see Modal CDC Analysis on page 133). Example
/* 0in set_mode ModeA -set sel1 1'b0 -set sel2 1'b1 */
310
Command Reference set_mode_control
set_mode_control
Identifies allowed values for specified mode control signals. Syntax set_mode_control signal_pattern [-values value] signal_pattern The signal name can have bit/wildcard. For example,
sig{1} sig*
-values values The values can have the question mark (?) wildcard. For example,
3'b?1?
Description The set_mode_control global directive is used to define mode signals for mode inference (see Modal CDC Analysis on page 133).
311
Command Reference set_reset
set_reset
Identifies the specified signals as reset signals or removes them from the list of inferred resets. Syntax set_reset signal_pattern [-remove] [-module module_pattern] signal_pattern Name pattern for the reset signals. Can include wildcards and references to bit slices. -remove Changes the sense of the directive to remove the specified signals as inferred resets. -module module_pattern Name of the module containing the reset signals. Default: top-level module. Description The set_reset directive is used to adjust the reset inferencing performed by the CDC compiler. Inferred asynchronous resets are true resets, but in certain cases, inferred synchronous resets might not be resets. Use set_reset with the -remove option to remove these resets from the list of resets. Some other reset schemes might result in the reset inference algorithm missing bona fide resets. Use the set_reset directive to specify the missed resets. By default added resets are synchronous with active high polarity. Use the -negedge and -async options to override these defaults. Some designs (for example some low-power handling schemes) use the same signal as an active high reset for one part of the circuit and as an active low rest for another part of the circuit. In this case, the compiler issues a warning, but reset inference still considers these signals as real resets (to both subcircuits). Examples
// 0in set_reset rst_* -async -negedge -module pci // 0in set_cdc_port_domain rst_* -async -module pci
The set_reset directive sets the rst_* signals to asynchronous negedge to override the CDC inference. You also need the set_cdc_port_domain directive to enable reporting of the schemes involving the rst_* signals.
// 0in set_reset rst_a -remove -module crc_16_calc
Removes rst_a from the list of resets.
312
Command Reference Directives for Checker Generation
Directives for Checker Generation

Global directives for checker generation (Table 6-3) control in particular how the promoted CDC checkers and the generated CDC-FX checkers are configured. In general, they control how simulation with assertions and formal verification of assertions operate. Table 6-3. Global Directives for Checker Generation Directive default_reset Description Wildcard Args
Specifies a default signal for the reset inputs to -module checkers.
-module use_synthesis_case_directives Directs the compilers to recognize non-0in case directives (for example full and parallel case directives). exclude_checker Specifies checkers to exclude from simulation -type with assertions and formal analysis. -name -module -group Specifies checkers to include for simulation with assertions and formal analysis. -type -name -module -group -type -name -module
include_checker
disable_checker
Identifies a signal that can disable checkers during simulation.
disable_used set_severity
Overrides the used options for all checkers of -type a given checker type in a module. -module Overrides the severity levels if any are specified in the checker directives. -type -name -module
set_checker_action
-module Specifies the action to perform when the number of firings of checkers with the given -severity reaches the specified count. Directive only applies to assertions in simulation. Specifies the keyword used in the firing messages for checkers with the specified severity level. Creates a wire in checker logic.
checker_firing_keyword
create_wire
313
Command Reference checker_firing_keyword
checker_firing_keyword
Specifies the keyword used in the firing messages for checkers. Syntax checker_firing_keyword name keyword_string [severity level] -name "keyword_string" String to insert into firing messages. -severity level Severity level (0 - 9) of checkers that are to have the specified keyword string added to their firing messages. Default: keyword_string is added to all checker messages. Description By default, each checker firing message begins with:
0-In Firing:...
The checker_firing_keyword directive adds a specified keyword string to checker firing messages:
0-In keyword_string Firing:...
The -severity level option restricts the directive to checkers with matching severity level. Example
//0in checker_firing_keyword -name "Warning S4" -severity 4
Produces the following firing entry:

0-In Warning S4 Firing: S4 assert_window tb.U1...Devsel (Firing: 1) Time: 330s Message: Ensures that signals assert correctly relative to a specified multiple-cycle time window Signature: One or more signals that should not have asserted outside the window did assert. Module: pci_slv, File: /examples/pci_slave/checker_control.v,Line: 14 Directive: awin -start Devsel -stop_count 2 -in Trdy -not_out Trdy -module pci_slv -severity 4 Check: not_out 0-In End Firing
314
Command Reference create_wire
create_wire
Creates a wire to use with assertion logic. Syntax create_wire -var wire [-width width] [-module module] -var wire Name to give the created wire. -width width Number of bits in the wire. Default: 1. -module module Create the wire in the specified module. Default: wire is created in the current module. Description The create_wire global directive creates a wire in the current or specified module, for use in assertion logic. Wires created by this directive have the following limitations: Can only be driven by checker outputs. Can only be used as input to other checkers. Cannot be referenced hierarchically (in the design and in directive arguments). Cannot have the same name as an existing design signal name.
Examples Following example creates a wire inside the module containing the create_wire directive.
module dut(in, clk, out); parameter P1 = 3; input [P1-1:0] in; input clk; output [P1-1:0] out; // 0in set_clock clk -default // 0in create_wire -var w -width P1 // 0in create_assign -var (~out) -var_out w // 0in one_hot -var w endmodule
Following example creates a wire inside the specified module.

module ctrl; // 0in create_wire -var w -width P1 -module dut // 0in create_assign -var (~out) -var_out w -module dut // 0in one_hot -var w -module dut // 0in create_wire -var f0 -module dut // 0in assert -var (out !=0) -assert_fire f0 -module dut endmodule
315
Command Reference default_reset
default_reset
Specifies a default checker reset signal or activates default reset inference. Can be specified in a design module. Syntax
Identify Default Reset
default_reset {-none | signal [-active_high | -active_low]} [-sync | -async] [-infer] [-module module] signal | -none Signal to be used as the default reset signal for checkers. The signal is taken to be a signal in module. If module is not specified, you must specify the full hierarchical path to signal. -active_high | -active_low Polarity of the reset signal. Checker resets are active-high polarity, so specifying -active_high connects the signal directly and specifying -active_low inverts the signal before connecting. Default: -active_high. -sync | -async Checker reset port: reset (-sync) or areset (-async). Typically, only one type of reset is used for the design and the other checker reset ports are tied to zero. Default: -sync -infer Infers the reset for each checker and only uses signal if the inference is not successful. This option can reduce ccl checker (i.e., simulation) compilation performance. Default: no inference. -module module Module name or wildcard pattern (pattern must match exactly one module). Default: checkers in all modules (if specified in a control file) or the current module (if specified in a source code module).
Activate Default Reset Inference
default_reset -infer [-sync | -async | -sync -async] [-module module] -infer Infers the reset for each checker and uses 1b0 if the inference is not successful. This option can reduce checker (i.e., simulation) compilation performance. Default: no inference. -sync | -async | -sync -async Checker reset ports: reset (-sync), areset (-async) or both. Typically, only one type of reset is used for the design and the other checker reset ports are tied to zero. Default: -sync
316
Command Reference default_reset
-module module Module name or wildcard pattern (pattern must match exactly one module). Default: checkers in all modules (signal must be a hierarchical path).
Description Checker reset signals are not used by the SVA and PSL checkers, and they are explicitly identified in the instantiations of OVL and QVL checkers. CheckerWare checkers have two reset ports: reset (synchronous) and areset (asynchronous). Connection to these ports can be specified in the checker directive for a checker with the -reset and -areset arguments. When both connections are not specified, the missing connections are determined from the specification of default_reset global directives and by reset signal inference. Inferring reset connections (and similarly clock connections) can be expensive in terms of lower compilation performance. The default_reset directive has two basic uses and the syntax depends on the usage: Identifies a default reset signal for CheckerWare checkers. A specific reset signal is provided as the default reset for checkers in the DUT or for a particular module. The -active_low option inverts the signal before connecting. The -sync or -async option identifies which reset ports to connect. The -infer option directs the compiler to try to infer the connection before assigning the default reset. Activates the inference of default resets. By default, if a connection to a checker reset port is not covered by an explicit checker directive (i.e., -reset signal or -areset signal argument) or by a default_reset signal global directive, then the reset port is connected to 1b0. Specifying the inference activation form of the default_reset directive directs the compiler to try to infer the connection before assigning 1b0. Note The default_reset directives identify reset signals for CheckerWare directives only. To properly detect async_reset and async_reset_no_sync CDC schemes, you must identify the reset signals with the set_reset directive.
317
Command Reference disable_checker
disable_checker
Identifies a signal that can disable checkers during simulation. Syntax disable_checker signal [severity level] [name checker] [type type] [module module [local]] Arguments signal Signal to use to disable matching checkers. -severity level Severity level of checkers to disable with signal. Default: all levels. -name checker Checker name or wildcard pattern. Default: *. -type type Checker type or wildcard pattern. Default: *. -module module Module name or wildcard pattern. Default: all modules. -local Restrict the directive to checkers in the top-level of module. Default: module hierarchy. Description The disable_checker global directive specifies a signal that dynamically disables specified checkers during simulation. When ccl synthesizes a checker, it derives the signal to connect to the checkers active input from the AND of the inverted disabling signal, any activation condition (<), if specified and any active option signal, if specified.
318
Command Reference disable_used
disable_used
Disables the -used option of CheckerWare checkers of a given type. Syntax disable_used -type type [-module module [-local]] -type type Checker type or wildcard pattern. -module module Module name or wildcard pattern. Default: all modules. -local Restricts the directive to checkers in the top-level of module. Default: module hierarchy. Description Overrides the -used option of CheckerWare checkers that have the specified checker type. The -used option constrains a checker to fire only if at least one downstream register samples at least one bit of the value on the element being checked (this constraint is called the used_condition). In general, used_condition is composed of the conditions in which downstream registers load a value, and the muxing/combinational logic (between the downstream registers and the element being checked) is turned on to allow the value to flow through combinationally to the downstream registers. Example
//0in disable_used -type one_hot
319
Command Reference exclude_checker
exclude_checker
Excludes the specified checkers from formal verification (and simulation with assertions). Syntax exclude_checker [-severity level] [-name checker] [-type type] [-group group] [-module module [-local]] -severity level Severity level of checkers to exclude. Default: all levels. -name checker Checker name or wildcard pattern. -type type Checker type or wildcard pattern. -group group Group name or wildcard pattern. -module module Module name or wildcard pattern. Default: all modules. -local Restrict the directive to checkers in the top-level module. Default: module hierarchy. Description Identifies checkers to exclude from the formal model by the csl compiler. The -group, -type and -name options restrict the directive to checkers with the specified checker group, checker type or checker name. The wildcard character * matches zero or more characters. Use the include_checker directive to override checkers specified with wildcards in exclude_checker directives. For example:
// 0in exclude_checker -type * -module sync3_r // 0in include_checker -type fire -module sync3_r
In the -name option, the wildcard can match the hierarchy delimiter. For example:
-name tb.*.state*
matches the names:

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

tb.cpu1.fifo16.state_cur tb.cpu2.fifo16.state_next tb.cpu1.fifo16.state_cur
321
Command Reference set_checker_action
set_checker_action
Specifies the action to perform when the number of simulation firings of checkers having a given severity level reaches the specified count. Syntax set_checker_action [-count count ] [-stop | -finish] [-severity level] [-module module] -count count Total number of firings for all checkers of the specified severity. When the number of firings of the specified severity reaches this count, the simulation performs the specified action of -stop or -finish. -stop Stop the simulation, but you can restart the session. -finish End the simulation. By default, the simulation ends 10 time units after the last firing. Use the +0in_checker_finish_delay+time ccl option to change this default. -severity level The directive specifies a single severity level (positive digit 0 to 9) and an optional count. Severity level 0 sets the default checker action. -module module Restrict the global directive to checkers in the specified module. Description Each set_checker_action global directive specifies the action to perform when the number of firings of checkers having a given severity level reaches the specified count. This directive only applies to simulation.
322
Command Reference set_severity
set_severity
Assigns a severity level to specified checkers. Syntax set_severity [-severity level [-default]] [-name checker_pattern] [-type type_pattern] [-module module_pattern [-local]] -severity level Severity level to assign to matching checkers (0 - 9). Default: no severity. -default Restricts the directive to checkers that have default severity. CheckerWare checkers that do not have a -severity level argument in the original checker directive have default severity. PSL and SVA checkers also have default severity. -name checker_pattern Checker name or wildcard pattern. -type type_pattern Checker type or wildcard pattern. -module module_pattern Module name or wildcard pattern. Default: all modules. -local Restricts the directive to checkers in the top-level module. Default: module hierarchy. Description Overrides the severity level of specified checkers. A checkers can have no severity (called the default severity) or it can have a value in the range 0 to 9 assigned as its severity level. Ranking is up to you (default might have level 0 or level 10). Severity levels are used primarily in simulation with assertions to affect the simulator response to checker firings. Example The following directives exclude psl and decrement checkers.
// 0in set_severity -severity 7 -type psl // 0in set_severity -severity 7 -type decrement // 0in exclude_checker -severity 7
323
Command Reference use_synthesis_case_directives
use_synthesis_case_directives
Creates case checkers for matching non-native (e.g., synthesis) case directives. Syntax use_synthesis_case_directives [-min_width width] [-min_item_count count] [-max_width width] [-max_item_count count] [-used] [-module module [-local]] -min_width width Minimum width of the case switch. -min_item_count count Minimum number of case items in the statement. -max_width width Maximum width of the case switch. -max_item_count count Maximum number of case items in the statement. -used Adds the -used argument to the generated case checkers. A generated case checker can fire only when at least one bit of a variable assigned in the active case block is loaded into a destination register. -module module Module name or wildcard pattern. Default: all modules. -local Restricts the directive to checkers in the top-level module. Default: module hierarchy. Description Creates case checkers for non-native case directives in the HDL code. These are directives of the following form:
// product [full_case] [parallel_case]
Where product indicates the identifier for the non-native synthesis product (for example, synopsys or synthesis).
324
Command Reference Shell Commands
Shell Commands
Three types of shell commands are used in CDC analysis: Compiler commands The 0-In/Questa design compiler commands handle front-end compilation of the design logic for CDC analysis. Questa and 0-In tools support the same design styles and HDL constructs. The vlib command sets up the working library for compiling the design units for CDC analysis. The vmap command maps logical library names to physical directories. The vcom command compiles VHDL source files. The vlog command compiles Verilog (and SystemVerilog) source files. The verror command reports additional detail for messages. The vdir command reports information about design units in libraries. The vdel command deletes design units from libraries.
0in shell The compilation environment for CDC, the 0-In formal tools and 0-In assertions in simulation is controlled from a special verification command shell called the 0in shell, invoked from the system shell by the 0in shell command. CDC GUI The 0in_cdc command runs the CDC GUI. Simulation commands The ccl 0in shell command generates the assertion logic for simulation with assertions. Using the data generated by ccl and a set of simulation-time simulator arguments, you run simulation with assertions using a native (Questa/ModelSim) simulator or a third-party simulator (VCS/NC-Verilog).
325
Command Reference vlib
vlib
Creates a design library for use by vmap/vcom/vlog, and sets accessibility to design units in a library (or to the entire library). Syntax vlib [-locklib | -unlocklib] [{-lock | -unlock} design_unit] library -locklib Locks the library so the library cannot be overwritten by the compilers. -unlocklib Unlocks the library so the library can be overwritten by the compilers. {-lock | -unlock} design_unit Locks/unlocks the specified design unit (module) in the library so it cannot be refreshed or recompiled. File permissions are not affected by these switches library Name to identify the library. The name work is the default working library: a library work statement is not needed in the source and work is the default destination of compiled units (so work need not be mapped). Must be the last argument. Description Two types of design libraries are used with the Questa tools: resource libraries Static libraries used by the source code for your design. Pre-compiled resource libraries are typically supplied by a third party (for example, models of gate-level netlists) or another design team. But, you also can specify resource libraries when compiling the design (after using vlib to create the library). For a Verilog library, use the -L option to vlog. For a VHDL library, use the -work library option to vcom to specify the library name for the compiled VHDL resource library, so it is not saved as the work library. Within a VHDL source file, use a VHDL library clause to specify names of resource libraries referenced in the design unit. working library Dynamic library containing executable code, debug information, dependency information and other data for compiling a design. Only one library is the working library for analyzing a design. The library named work is the default assumed working library. But, you still must use vlib to create the working library:
system prompt> vlib work
326
Command Reference vmap
vmap
Creates a logical-to-physical mapping for a design library, removes logical-to-physical mappings or reports current mappings Syntax vmap [-modelsimini init_file [-c]] [logical_name [dir] | -del logical_name] -modelsimini init_file Add the mapping to the compiler initialization file init_file. Default: ./modelsim.ini (copied from the distribution software if ./modelsim.ini does not exist. -c Copy init_file to ./modelsim.ini and add the mapping to ./modelsim.ini. However, if ./modelsim.ini exists and is write-protected, add the mapping to init_file instead. logical_name Name to map or un-map. Default: reports the current logical-to-physical mappings (from modelsim.ini). dir Physical directory to which the logical name should map. Default: prints the current logicalto-physical mapping for logical_name. -del logical_name Un-map the logical-to-physical mappings for the specified logical_name list. Description The vlib command creates a design library with a given logical name and stores the library information in a directory with the same name in the current directory. By default, the library name is mapped to the directory name. The vmap command is used to change this logical-tophysical mapping and to manage logical-to-physical mappings. Non-default logical-to-physical mappings are stored in the modelsim.ini file in the current directory. Examples Example 1
system prompt> vmap
Reports the current mappings. Example 2

system prompt> vmap work
Reports the current mapping for the work library.
327
Example 3
system prompt> vmap work ../shiba/my_work Copying path/modelsim.ini to modelsim.ini Modifying modelsim.ini
Maps the work library to ../shiba/my_work. Copies modelsim.ini from the software installation to the current directory and adds the mapping to ./modelsim.ini. Example 4
system prompt> vmap -modelsimini ../shiba/modelsim.ini \ work ../shiba/my_work Modifying ../shiba/modelsim.ini
Maps the work library to ../shiba/my_work and adds the mapping to ../shiba/modelsim.ini. Example 5
system prompt> ls work system prompt> vmap -modelsimini -c ../shiba/modelsim.ini \ work ../shiba/my_work Copying ../shiba/modelsim.ini to modelsim.ini Modifying modelsim.ini ** Warning: Copied ../shiba/modelsim.ini to modelsim.ini. Updated modelsim.ini. MODELSIM set to ../shiba/modelsim.ini. The MODELSIM environment variable is used to find the modelsim.ini file, so this local copy will not be used.
Maps the work library to ../shiba/my_work, copies ../shiba/modelsim.ini to ./modelsim.ini and adds the mapping to ./modelsim.ini. Example 6
system prompt> ls modelsim.ini work system prompt> chmod a-w modelsim.ini system prompt> vmap -modelsimini -c ../shiba/modelsim.ini \ work ../shiba/my_work Copying ../shiba/modelsim.ini to modelsim.ini ** Error: (vmap-7) Failed to open ini file "modelsim.ini" in write mode. Permission denied. (errno = EACCES) Modifying ../shiba/modelsim.ini ** Warning: vmap will not overwrite local modelsim.ini. MODELSIM set to ../shiba/modelsim.ini. ../shiba/modelsim.ini was modified because copy failed The MODELSIM environment variable is used to find the modelsim.ini file, so this local copy will not be used.
Maps the work library to ../shiba/my_work and adds the mapping to ./modelsim.ini.
328
Example 7
system prompt> vmap -del work Removing reference to logical library work Modifying modelsim.ini
Un-maps any existing mapping for the work library and restores the mapping to the default directory for the library (./work). Example 8
system prompt> vmap -del ZLIB YLIB Removing reference to logical library ZLIB Modifying modelsim.ini Removing reference to logical library YLIB Modifying modelsim.ini
Un-maps any existing mappings for the ZLIB and YLIB libraries and restores the mappings to the default directories (./ZLIB and ./YLIB).
329
Command Reference vcom
vcom
Compiles VHDL source files into a design or resource library. Syntax vcom [-version] [-work logical_name] [modelsimini init_file] [-87 | -93 | -2002 | -2008] [-explicit] [skipsynthoffregion [synthprefix keyword]] [-check_synthesis] [-noindexcheck | -norangecheck | -nocheck] [{-fatal | -error | -warning | -note | -suppress} msg_number [,msg_number]] [-source] [-time] [-nowarn number] [-quiet] [-mixedsvvh [b | l | r] [i]] [-pslfile vunit_file] [-f arg_file] [other_vcom_options] VHDL_file -version Report the Questa version and exit. -work logical_name Name of the design library to use as the destination for the compilation. Default: work. modelsimini init_file Load init_file as the initialization (modelsim.ini) file. Default: search path shown in Figure 3-4 on page 59. -87 | -93 | -2002 | -2008 VHDL version: VHDL-87, VHDL-93, VHDL-2002 or VHDL-2008. Default: value specified by the VHDL93 variable (default 2002) in modelsim.ini. -explicit Resolve ambiguous function overloading in favor of the explicit definition. Default: value specified by the Explicit variable (default on) in modelsim.ini. Having Explicit set in modelsim.ini makes the compiler compatible with common industry practice. Commenting out Explicit favors implicit definitions, which matches the VHDL standard. -skipsynthoffregion Do not parse synthesis off and translate off regions of HDL code. Keywords for synthesis off/on and translate off/on pragmas are: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and vcs, plus custom keywords specified with the -synthprefix keyword argument. Default: HDL code in synthesis off and translate off regions is parsed and made ready for use in simulation and 0-In analysis. Use this option to avoid parsing synthesis/translate off region code that might be syntactically or semantically incorrect. However, if you specify -skipsynthoffregion, the design library is not suitable for simulation. Therefore, Questa simulator users should try to avoid using this option.
330
synthprefix keyword Synthesis off/on pragma keyword. Treat code in <keyword> synthesis_off /synthesis_on regions and <keyword> translate_off /translate_on regions as parse and ignore. For example if you specify -synthprefix zin, the following synthesis off regions of code are parsed and ignored.
-- zin synthesis_off VDHL code to parse and ignore -- zin synthesis_on
// zin translate_off Verilog code to parse and ignore // zin translate_on
Default synthesis off/on keywords: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and vcs. -check_synthesis Perform limited synthesis rule checks (for example, process signals are in the process sensitivity list). Default: value specified by the CheckSynthesis variable (default off) in modelsim.ini. -noindexcheck | -norangecheck | -nocheck Do not check that indexes are in bounds (-noindexcheck); do not check that scalar values are defined in their ranges (-norangecheck); or do not perform either of these checks (-nocheck). These options can speed up compilation of large designs. Default: values specified by the NoIndexCheck and NoRangeCheck variables (default off, i.e., checking enabled) in modelsim.ini. {-fatal | -error | -warning | -note | -suppress} msg_number [,msg_number] Change the severity of the specified messages. You cannot suppress fatal (or internal) messages. Default: severities set in the [msg_system] section of modelsim.ini, which overrides the default settings from the compiler. -source Include corresponding source code line numbers in messages. -time Report the process time (actual time, not CPU time) taken for the compilation. -nowarn number Do not report warning messages for number category: 1 2 3 4 5 unbound component process without a wait statement null range no space in time literal multiple drivers on unresolved signal 8 9 10 11 13 lint checks signal value dependency at elaboration VHDL-93 constructs in VHDL-87 code PSL warnings constructs that coverage cannot handle
331
6 VITAL compliance checks 7 VITAL optimization messages -quiet Do not report loading messages. -mixedsvvh [b | l | r] [i]
14 locally static error deferred until
Compile VHDL packages so they can be included in a SystemVerilog design. Qualifiers have the following meanings: b l r i scalars and vectors have SystemVerilog bit type scalars and vectors have SystemVerilog logic type scalars and vectors have SystemVerilog reg type ignore the ranges specified with VHDL integer types
Default: see VHDL to SystemVerilog Data Types Mapping. -pslfile vunit_file PSL VHDL flavor vunit file to bind and compile. Vunits must be compiled at the same time as the design units to which they are bound. -f arg_file File containing additional command arguments. Argument files have the following syntax rules: newlines treated as spaces. // text to the end of the line is ignored. /* text */ text (including newlines) is ignored. single quotes (text) groups text and prevents character substitution (such as variable expansion and character escapes). double quotes (text) groups text and prevents character substitution except for backslash escape and environment variable substitution. For example:
// groups argument with spaces and substitutes value for $TIME_UNIT -timescale "$TIME_UNIT / 1 ps"
environmental variables are expanded unless preceded by a backslash (for example, \$USER) or in single quotes (for example, $USER). -f arg_file can be nested inside an argument file.
other_vcom_options Options only relevant to simulation do not affect the 0-In compilers. Other advanced options might affect 0-In tool resultsthese are described in the Questa documentation.
332
VHDL_file Files containing VHDL source code to compile. Wildcards are supported (e.g., *.vhd). Design units are compiled in the order they appear.
Description The vcom command compiles one or more VHDL source files into a design library. Before using this command, use the vlib command to create the initial design library. Subsequent applications of vcom can be used to incrementally compile and recompile the VHDL portion of the design. For VHDL, compile order is important. You must compile entities and configurations before architectures that reference them. Examples Example 1
system prompt> vcom dut.vhd
Compiles dut.vhd into the work library. Example 2

system prompt> vcom -work my_work block1.vhd block2.vhd top.vhd
Compiles block1.vhd, block2.vhd and top.vhd (in that order) into the my_work library. Example 3
system prompt> vlib work system prompt> vcom -2008 block1.vhd system prompt> vcom block2.vhd top.vhd
Creates a work library; compiles the VHDL-2008 flavor block1.vhd file; then compiles the VHDL-2002 (default) flavor block2.vhd and top.vhd files.
333
Command Reference vlog
vlog
Compiles Verilog source files into a design or resource library. Syntax vlog [version] [work logical_name] [libmap library_map_file [libmap_verbose]] [modelsimini init_file] [{Lf | L } library] [vlog95compat | vlog01compat] [skipsynthoffregion [synthprefix keyword]] [skipprotected | skipprotectedmodule] [pedanticerrors] [timescale units/precision] [+define{+macro[=value}] [convertallparams] [+floatparameters[+param_path[.]]] [+incdir{+include_dir}] [+libext{+extension}] [printinfilenames] [{fatal | error | warning | note | suppress} msg_number [,msg_number]] [source] [time] [nowarnID | nowarn number] [quiet] [93] [u] [sv] [mixedsvvh [b | s | v] [packedstruct]] [mfcu [cuname comp_unit] | sfcu] [pslfile vunit_file] [y library_dir] [v library_file] [f arg_file] [other_vlog_options] Verilog_file version Report the Questa version and exit. work logical_name Name of the library to use as the destination for the compilation. Default: work. libmap library_map_file Verilog 2001 logical-to-physical library map file. libmap_verbose Report library map pattern matching information to troubleshoot problems with matching filename patterns in the library file. modelsimini init_file Load init_file as the initialization (modelsim.ini) file. Default: search path shown in Figure 3-4 on page 59. Lf library | L library Resource library containing pre-compiled modules for the compilation. With the Lf argument, library is searched before searching in the effective uselib library (if specified) for the instantiation. With the L argument, library is searched after searching the effective uselib library. The LibrarySearchPath variable defines an initial resource library search path. When searching for a module for an instantiation, the libraries specified by LibrarySearchPath are searched in (left-to-right) order, as if they were specified with the L argument. If no match is found, the libraries specified in the Lf and L options are searched in the order specified in the command invocation.
334
vlog95compat | vlog01compat Assume the IEEE 1364-1995 standard (-vlog95compat) or the IEEE 1364-2001 standard (-vlog01compat). These two Verilog standards have some conflicts, so running the correct compatibility ensures valid code is compiled properly. Default: value specified by the vlog95compat variable (default off, i.e., 2001) in modelsim.ini.
-skipsynthoffregion Ignore (do not parse or compile) synthesis off and translate off regions of HDL code. Keywords for synthesis off/on and translate off/on pragmas are: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and vcs, plus custom keywords specified with the synthprefix keyword argument. Default: HDL code in synthesis off and translate off regions is parsed and compiled, ready for use in simulation and 0-In analysis. If you specify skipsynthoffregion, the design library might not be suitable for simulation.
synthprefix keyword Synthesis off/on pragma keyword. Skip (i.e., ignore and do not parse) code in <keyword> synthesis_off regions and <keyword> translate_off regions. For example if you specify -synthprefix zin, the following regions of code are ignored.
-- zin synthesis_off VDHL code to ignore -- zin synthesis_on
// zin translate_off Verilog code to ignore // zin translate_on
Default synthesis off/on keywords: pragma, synthesis, synopsys, 0in, mentor, mspa, mti and vcs. skipprotected Ignore (do not parse or compile) protected regions of HDL code. Default: compile code inside protected/endprotected regions. skipprotectedmodule Exclude modules containing protected/endprotected regions from being added to the library. Declarations are preserved (for both skipprotectedmodule and skipprotected). For example:
module test(input in, output out); protected reg tmp; endprotected assign out = tmp && in; endmodule prompt> vlog test.v -skipprotected -- Compiling module test ** Warning: test.v(2): (vlog-2280) Skipping protected region.
The module compiles OKno undefined variable (tmp) error occurs. Default: modules containing protected regions are compiled and added to the library.
335
pedanticerrors Report mismatched else directives and enforce the following IEEE Verilog Standard 18002005 restrictions: new for queues is illegal. Default: new creates a queue whose elements are initialized to the default value of the queue element type. Sized, based literals containing underscore characters (for example, 8b0110_0110) are illegal. Default: these constructs are legal. Class extern method prototypes with lifetime (automatic/static) designations are illegal. Default: these constructs generate LRM-compliance warnings. PSL statements with cover bool@clk constructs are illegal. Default: these constructs are legal.
timescale units/precision Default timescale for modules. Precision must be units and both units and precision have the form: {1 | 10 | 100}{fs | ps | ns | us | ms | s} For example: timescale 10ns/100ps.
+define{+macro[=value]} Text macro specification. Overrides any matching define compiler directives. convertallparams Compile non-ANSI parameters so they can be translated into std_logic_vector, bit_vector, std_logic, vl_logic, vl_logic_vector, and bit generics when interfacing with VHDL design units.
+floatparameters[+param_path[.]] Do not evaluate specified parameters, so they can be overridden by -g/-G options to csl and vsim. The param_path is a module, module/parameter, hierarchical path to an instance, or hierarchical path to a parameter in an instance. Specifying a period (.) applies the argument recursively to instances in param_path. Default param_path: all parameters.
+incdir+include_dir Input include directory. +libext{+extension} File extensions to use when searching for library files. For example, +libext+.v compile_uselibs[=uselib_dir] Compile uselib source files into uselib_dir directory and update modelsim.ini with the logical-to-physical mappings for the uselib libraries. The uselib directives are persistent: the last uselib directive in a file applies to the rest of the code in the fileand to the code in subsequent files in the vlog invocation, up to the next uselib directive. You can specify an
336
empty uselib directive at the end of a file to prevent the effect of the last uselib directive from carrying over to the next file. Default uselib directory: $MTI_USELIB_DIR (if defined) in the current directory, otherwise mti_uselibs in the current directory. printinfilenames Print the paths of all source files opened during the session, including include files. {fatal | error | warning | note | suppress} msg_number [,msg_number] Change the severity of the specified messages. You cannot suppress fatal (or internal) messages. Default: severities set in the [msg_system] section of modelsim.ini, which overrides the default settings from the compiler. source Include corresponding source code line numbers in messages. time Report the process time (actual time, not CPU time) taken for the compilation. nowarnID | nowarn number Do not report warning messages for ID or number category. ID is an identifier for a class of messagesit appears in square brackets in the message. For example, ID is RDGN in the following message:
** Warning: test.v(15): [RDGN] - Redundant digits in numeric literal.
The argument to filter out RDGN warnings is: -nowarnRDGN. Warning category numbers identify broad categories of messages: 11 PSL warnings 12 non-LRM compliance to match alien simulator behavior quiet Do not report loading messages. 93 Use VHDL-1993 extended identifiers when interfacing with VHDL design units, to preserve case in Verilog identifiers that contain upper-case letters. u Convert identifiers to upper case. sv Recognize SystemVerilog source code in all files. Default: SystemVerilog source code is recognized only in files with .sv extensions. 13 constructs that code coverage cannot handle 15 SystemVerilog assertions using local variables
337
mixedsvvh [b | s| v] [packedstruct] Compile SystemVerilog packages so they can be included as packages in a VHDL design. Qualifiers have the following meanings: b s v packedstruct scalars and vectors are VHDL bit/bit_vector types scalars and vectors are VHDL std_logic/std_logic_vector types scalars and vectors are VHDL vl_logic/vl_logic_vector types packed structures are VHDL arrays with equivalent sizes
Default: see SystemVerilog-to-VHDL Data Types Mapping. mfcu Compile the named source files into a single compilation unit (i.e., a multi-file compilation unit). Default: value specified by the MultiFileCompilationUnit variable (default off) in modelsim.ini. If multi-file compilation units are not enabled, a compilation unit is created for each source file, which matches the SystemVerilog standard. cuname comp_unit Name to give the compilation unit created by -mfcu. Use this option if a module has a bind statement, but no module in the design depends on the resulting compilation unit. In this case, the bind statement would not be elaborated by csl or vsim. For these tools, naming comp_unit forces elaboration of the compilation unit package (including the bind statement), which otherwise would not be elaborated. If specified, you must also specify the comp_unit to csl/cdc (with the -cuname option). Though the vsim command accepts only a single comp_unit name, csl/cdc accept multiple comp_unit names. sfcu Compile the named source files into individual compilation units (i.e., single-file compilation units). Default: value specified by the MultiFileCompilationUnit variable (default off) in modelsim.ini. If MultiFileCompilationUnit is not set to 1, -sfcu is not needed. pslfile vunit_file PSL Verilog flavor vunit file to bind and compile. Vunits must be compiled at the same time as the design units to which they are bound. y library_dir Directory containing library files. v library_file Library file. f arg_file File containing additional command arguments. Argument files have the following syntax rules:
338
newlines treated as spaces. // text to the end of the line is ignored.

/* text */ text (including newlines) is ignored. single quotes (text) groups text and prevents character substitution (such as variable expansion and character escapes). double quotes (text) groups text and prevents character substitution except for backslash escape and environment variable substitution. For example:
// groups argument with spaces and substitutes value for $TIME_UNIT -timescale "$TIME_UNIT / 1 ps"
environmental variables are expanded unless preceded by a backslash (for example, \$USER) or in single quotes (for example, $USER). f arg_file can be nested inside an argument file.
other_vlog_options Options only relevant to simulation (which do not affect the 0-In tools). Other advanced options might affect 0-In tool resultsthese are described in the Questa documentation.
Verilog_file Files containing Verilog source code to compile. Wildcards are supported (e.g., *.v *.sv).
Description The vlog command compiles one or more Verilog/SystemVerilog source files into a design library. Before using this command, use the vlib command to create the initial design library. Subsequent applications of vlog can be used to incrementally compile and recompile the Verilog portion of the design. Examples Example 1
system prompt> vlog dut.v
Compiles dut.v into the work library. Example 2

system prompt> vlog -work my_work block1.v block2.v top.sv
Compiles block1.v, block2.v and top.sv into the my_work library. Example 3
system prompt> vlib work system prompt> vlog -vlog95compat block1.vhd system prompt> vcom block2.vhd top.vhd
Creates a work library; compiles the Verilog-95 flavor block1.v file; then compiles the Verilog-2001 (default) flavor block2.v and SystemVerilog top.sv files.
339
Command Reference verror
verror
Reports detailed information about Questa utility errors. Syntax verror [ ranges | [[fmt] [tag] | full] {message_number | [kind tool] -all} ] ranges Report the numeric ranges of message numbers for all tools. Numbers missing from the ranges are invalid messages. For example, 126 is not in a range so verror 126 returns:
** Error: Invalid message number 126.
fmt, tag, full Type of information to report for a message: fmt format string for the message, for example:
Failed to access library %s at "%s" .
tag message tag, for example:

MSG_IDX_LIBRARY_ACCESS_FAILED
Specify both fmt and tag to report the format string and the tag. Specify full to report this information plus a detailed message. Default: report the detailed message only. message_number List of message numbers. For example, the following vlog error message has message number 19:
Vlog error.(vlog-19) Failed to access library work at "work".
Information is reported for each specified message number. kind tool all Group of messages to report. The tool can be any of common, vcom, vcom-vlog, vlog, vsim, vsim-vish, wlf, vsim-sccom, sccom, vsim-systemc, ucdb, vsim-vlog or pseudo_synth. The all argument is required. Default tool: messages for all tools are reported. Description Error/warning messages reported by Questa tools are terse. Use the verror command to get detailed information about messages.
340
Command Reference verror
Examples Example 1
system prompt> verror -full 2155 MSG_IDX_GLBL_VARS_IN_VERILOG Global declarations are illegal in Verilog 2001 syntax. Global declarations are only legal in SystemVerilog. To enable SystemVerilog you can either use the -sv vlog command line switch or give the source file a .sv extension.
Example 2
system prompt> verror -ranges common: 1-98 (98) 100-125 (26) 129-148 (20) 151 (1) . . . pseudo_synth: 9001-9009 (9) 9100-9120 (21) 9200-9207 (8) 9300-9306 (7) 9308-9339 (32) 9401-9411 (11) 9600-9639 (40) 9650-9685 (36) Total number of messages = 2703.
341
Command Reference vdir
vdir
Reports information about the contents of a library. Syntax vdir [prop id | l] [r] [modelsimini file] [all | [lib library] [design_unit]] prop id Report the information specified by id for each design unit. id archcfg bbox body default dir dpnd entcfg extern inline lock lrm Information Configuration for architecture Blackbox for optimized design Needs a body Compile defaults Source directory Depends on Configuration for entity Package reference number Module inlined Design unit locked/unlocked VHDL language standard id mtime name opcode options fulloptions root src top ver vlogv voptv Information Source modified time Short name Opcode format Compile options Full compile options Optimized Verilog design root Source file Top-level model Version string Verilog version Verilog optimized version
Default: no detailed information is reported. l Report all the information in the above table for each design unit. r Report the architectures for each VHDL entity. modelsimini file Use file as the modelsim.ini file to determine the library or libraries. Default: ./modelsim.ini. all Report information for all libraries. Default: library (or work) only. lib library Report information for library (logical or physical library). Default library: work. design_unit Design unit to report. Default: all entities, configurations, modules, packages and optimized design units.
342
Description The vdir command reports information about the contents of a library. The command with no arguments lists the design units in the default library (work) with their types. You can specify another library with the lib library option or specify all the modelsim.ini libraries with the all option. The vdir command can report detailed information about the design units. Either specify prop id to get the information corresponding to a single id, or specify l to report the complete detailed information about each design unit. The l option produces a lengthy output, so you might also want to restrict the information reported to a single design_unit. Examples Example 1
system prompt> vdir Library vendor : Model Technology Maximum unnamed designs : 3 MODULE a_ovl_pci_pcir_fifo_control MODULE a_pci_monitor . . . MODULE pci_pciw_pcir_fifos ENTITY pci_perr_crit ENTITY pci_perr_en_crit MODULE pci_rst_int ENTITY pci_serr_crit ENTITY pci_serr_en_crit MODULE pci_sync_module MODULE pci_synchronizer_flop . . .
Example 2
system prompt> vlib -lock wb_slave system prompt> vdir -prop lock Library vendor : Model Technology Maximum unnamed designs : 3 MODULE a_ovl_pci_pcir_fifo_control MODULE a_pci_monitor . . . MODULE wb_slave Design unit locked/unlocked: locked . . .
343
Example 3
system prompt> vdir -l synchronizer_flop Library vendor : Model Technology Maximum unnamed designs : 3 MODULE synchronizer_flop Package reference number: 1 sv_std std Depends on: X sv_std std WnQ=;W1Xô9K1PIQTgInR3 Verilog version: 75H<P_OOUP;li]1h@XcB20 Version string: Vz3hiFlX4K>9PJJZjj9EW2 Source directory: /u/ramesh/examples/fv_demo/zin/demo Source modified time: Thu Oct 29 14:17:15 2009 HDL source file: ../../pci/rtl/verilog/synchronizer_flop.v Source file: ../../pci/rtl/verilog/synchronizer_flop.v Start location: ../../pci/rtl/verilog/synchronizer_flop.v:105 Opcode format: QA Baseline: 6.6 - 2149934; VLOG SE Object version 44 Optimized Verilog design root: 1 VHDL language standard: 1 Compile options: -sv -permissive -mixedansiports -compile_uselibs=/u/ramesh/examples/fv_demo/zin/demo/ log_static/0in_cache/AN/compile_uselibs_output -pslallowseverity -synthprefix {$s} -synthprefix {$s} -cuname root_cuname -mfcu +libext+.vlib -L mtiAvm -L mtiOvm -L mtiUPF
344
Command Reference vdel
vdel
Deletes design units from a library. Syntax vdel {all | primary [arch] | allsystemc} [lib library] [modelsimini file] [verbose] all Delete the entire library. Caution You are not prompted for confirmation. Once deleted, the library cannot be recovered. primary [arch] Design unit to delete: primary is the entity, package, configuration, or module; arch is a specific architecture for primary. If primary is an entity and arch is not specified, all architectures of primary are deleted. Not supported for SystemC modules. allsystemc Delete all SystemC modules. lib library Delete from library (logical or physical library). Default library: work. modelsimini file Use file as the modelsim.ini file to determine the library. Default: ./modelsim.ini. verbose Report progress messages. Description The vdel command deletes a design unit from a library, deletes all SystemC modules in a library, or deletes an entire library.
345
Command Reference vdel
Examples Example 1
system prompt> vdel shiba -all
Deletes the shiba library. Example 2

system prompt> vdel xor behavior
Deletes the behavior architecture of the xor entity from the work library.
346
Command Reference 0in
0in
Runs the 0in shell. Syntax 0in [version] [l log_file] [detail detailed_log_file] [nl][limit_messages] [cache dir] [rel_paths] [od output_dir] [sim {questa | vcs | nc | nc3}] [licq] [script_file | cmd command_string] version Print the version information and exit. l log_file Rename the generated 0in shell log file. Default: 0in.log. detail detailed_log_file Rename the generated detailed 0in shell log file. Default: 0in_detail.log. nl Disable message logging to the detailed log and the 0in shell log. Default: messages are logged. limit_messages Limit the number of messages in the detailed log. For each message type encountered, only the first 10 messages are logged. Default: all messages are logged. cache dir Rename the generated 0in cache directory for the session. Default: 0in_cache in the output directory. rel_paths Uses relative pathnames in generated argument files. Default: full paths. od output_dir Directory to store all output files. Default: current directory. sim {questa | vcs | nc | nc3} Target simulator: Questa, VCS, NCVerilog, 3step NCVerilog. Default: questa (with the same version as the vsim executable in the current search path). licq Enables license queuing for 0in shell commands. Default: command terminates if the required license is being used. Use this option to enqueue multiple sessions that are executed automatically as licenses become available. To do this, include +0in_licq as a 0in shell command option. For example:
shell prompt> 0in +0in_licq -cmd csl ....
347
Command Reference 0in
The following example does not work:

shell prompt> 0in -cmd csl +0in_licq ....
If a license is requested that is not available, then the shell issues the following warning:
0-In Info: Waiting for license key version
When the shell gains the license, it issues the following message and starts processing:
0-In Info: Obtained license key version
Requests in the queue are handled on a first-in, first-out basis, with all requests having the same priority. You cannot specify a timeout limit for the request; you must issue an interrupt signal to remove a request from the queue. The +0in_licq option does not apply to licenses for third-party EDA tools. script_file Specifies a script file containing 0in shell commands to run (ignored if cmd is specified). cmd command_string Passes the succeeding invoked arguments to the 0in shell as a single command. Description The 0in command runs the 0in shell. The 0in shell is a command execution environment for 0-In compilers and functional verification tools. The 0in shell runs the clock-domain crossing analyzer (cdc). In addition, the 0in shell runs the formal model compiler (csl) and the checker synthesis compiler (ccl). To run in batch mode, specify a script file. Otherwise the shell runs interactively. The special 0in shell command help, prints the utilities available to run in the shell. The utility cwhelp shows syntax of the global directives and the CheckerWare checker directives.
348
Command Reference 0in_cdc
0in_cdc
Runs the CDC GUI environment. Syntax 0in_cdc [ [db] db_file [restore_state gui_state_file | {mergedb db_file}] | project_file [restore_state gui_state_file] | [p project_name ] [hdl_file] [d design] [f verilog_filelist] [vhf vhdl_filelist] [[ctrl verilog_control_file] [vhctrl vhdl_control_file] | [ctrl_module module]] [import_ctrl control_file] [v95] [libmapfile library_map_file] [y lib_dir] [v lib_file] [work library] [od output_dir] [no_directive_error_check] [+libext{+ext}] [+incdir{+dir}] [+define{+macro[=val]}] [sdc_in sdc_file] [sdc_out file] [formal] [block module] [cdcid id] [verbose] ] db_file Formal database file (.db) to load. mergedb db_file Formal database file (.db) to merge (as with File >Merge Database). project_file Project file (.zpf) to load. p project_name Project or project file (.zpf) to load. If a project with the name project_name does not exist, a new project with that name is created. restore_state gui_state_file Load the initial state of the GUI windows from gui_state_file. Use File >Export >State to save the current GUI state to a file. This command also creates a run file having the same name, but with a _run extension. The run file runs the GUI with the .db file or project and the -restore_state option. You can use this process to freeze the view of the GUI so you can examine it later or from another system. Default: state of the GUI windows does not show the debug tools opened when the project was saved. hdl_file HDL files to add to the project. design Name of the top-level DUT design unit. f verilog_filelist Text file listing Verilog source files. Maximum pathname length: 1024 characters.
349
vhf vhdl_filelist Text file listing VHDL source files. ctrl verilog_control_file Verilog control file. vhctrl vhdl_control_file VHDL control file. ctrl_module module Module or design unit in the -work library to use as a 0-In control file. You can use vcom/vlog to compile a 0-In control file (for example, if a 0-In control module or 0-In control design unit contains modeling logic), then use the -ctrl_module option to indicate the 0-In control modules and control design units used for analysis.
import_ctrl control_file Verilog or VHDL control file containing global directives to import so they can be edited in the directive editor dialogs (as with File >Import >Directives).
v95 Assume Verilog 95 syntax. Default: Verilog 2K. libmapfile library_map_file Library mapping file. y lib_dir Directory containing library files. v lib_file Library file. work work_dir GUI work directory. Default: ./work. od output_dir Output directory for reports and databases. no_directive_error_check Turns off error checking (i.e., signals, ports, modules exist) in the directives dialogs. +libext{+ext} File extensions of library files to search for. Example: +libext+.v+.vhd +incdir{+dir} Directories containing the include files. Example: +libext+include+../common/include
350
+define{+macro[=val]} Verilog macro defines. Example: +define+STATIC_FIFO+FIFO_SIZE=16 sdc_in sdc_file Load the specified SDC file and use the SDC data to set up CDC analysis. sdc_out file Write the SDC data to file for use in downstream tools. formal Run formal CDC during static CDC analysis. block module Treat the module/entities as blocks for hierarchical analysis. cdcid id CDC crossing to select and show the corresponding source code. verbose Turn on verbose reporting (see cdc on page 359).
Description The 0in_cdc shell command runs the CDC GUI environment. Examples shell prompt> 0in_cdc Runs the CDC GUI with no data loaded. The blank main window appears.
shell_prompt> 0in_cdc -p mem_ctrl -d top -od mem_ctrl_work \

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

Save
The GUI saves the project to the mem_ctrl.zpf file in the current directory. shell prompt> 0in_cdc -p mem_ctrl The GUI starts up and loads the mem_ctrl project saved in the previous example.
352
Command Reference 0in_db2ucdb
0in_db2ucdb
Translates a 0-In database (.db file) into a UCDB database; or creates a .do file that excludes certain AutoCheck violations from coverage metrics calculated by vsim/vcover; or creates a report file for a specified UCDB. Syntax 0in_db2ucdb in_file out_file {prefix hierarchy_prefix prefix_modules module [cdc] | exclude | report} in_file Source file for the operation. For UCDB generation and exclusion .do file generation, in_file is a 0-In database file (.db). For report file generation, in_file is a UCDB file. out_file Name to give the generated file. prefix hierarchy_prefix Location in the design library of the generated UCDB scheme. prefix_modules module Design units to include in the translation. cdc Translate CDC data from the 0-In database file. Default: no CDC is translated. exclude Create a .do file of exclusion commands for input to vsim and do not generate a UCDB file. report Create a report file showing the information in the specified UCDB file. Description The 0in_db2ucdb command has three functions: Translate a 0-In DB file to a UCDB file. For example:
0in_db2ucdb 0in_confirm.db 0in.ucdb -prefix work.tb.dut \ -prefix_modules tb dut
Create an exclusion .do file from a 0-In DB file. For example:

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

0in_db2ucdb 0in.ucdb 0in.rpt -report
353
0-In AutoCheck 0-In AutoCheck analysis detects three types of information relevant to UCDBs: unreachable FSM states, unreachable FSM transitions and unreachable blocks of code. After debugging any issues found by autocheck analysis, any remaining unreachable FSM states/transitions and blocks of code are presumably OK. However, after running simulations and merging results, these unreachable objects are used in the calculations of FSM and line coverage reported by vcover. The effect is that reported coverage measures are lower than necessary. To work around this problem, you can exclude certain coverage objects from the coverage calculations using the coverage exclude commands. For example:
coverage coverage coverage coverage coverage coverage coverage exclude exclude exclude exclude exclude exclude exclude -du -du -du -du -du -du -du work.shiba.fsm_a -fstate state 4b0111 work.shiba.fsm_a -fstate state 4b1000 work.shiba.fsm_a -ftrans state {4b0110 -> 4b0111} work.shiba.fsm_a -fstate current_state 5b01000 work.shiba.fsm_a -fstate current_state 5b10000 work.shiba.t2 -srcfile dut.v -linerange 75 work.shiba.t2 -srcfile dut.v -linerange 76
These commands exclude state states 4b0111 and 4b1000, state transition 4b0110 -> 4b0111, current_state states 5b01000 and 5b10000, and lines 75-76 in dut.v from coverage calculations. Since autocheck analysis has already detected these unreachable objects, you do not need to manually code these exclusionsthey are automatically generated by 0in_db2ucdb with the -exclude option:
prompt> prompt> prompt> prompt> prompt> 0in_autocheck .... 0in_db2ucdb -exclude 0in_autocheck.db exclude.do... vsim ... exclude.do... vcover report -select f -bydu sim.ucdb > du.report vcover report code s sim.ucdb > cover.report
0-In CDC The UCDB schema supports CDC attributes, however current vsim versions do not access any of this information. You can access CDC information via the UCDB API (see UCDB API Reference), however, you must include the following header file in the API code:
$HOME_0in/share/inluce/ucdb_cdc.h
This header defines the CDC_RECORD key and the supporting attributes. To include CDC data in the UCDB translation, specify the -cdc option to 0in_db2ucdb. If you specify -cdc when translating a CDC db file to a ucdb file, then run 0in_db2ucdb -report on the generated ucdb file, the utility creates a report with the CDC information included. For example:
prompt> 0in_db2ucdb -prefix tb.dut -prefix_modules pci \ -cdc 0in_cdc.db 0in_cdc.ucdb prompt> 0in_db2ucdb -report 0in_cdc.ucdb cdc.report prompt> more cdc.report
354
# 0in_db2ucdb Report ------------ TEST ------------------------Name : 0in_cdc File name : 0in_cdc.ucdb Status : OK Simulation time : 0.000000 us Compulsory : 0 Seed : NONE Test args : (null) Vsim args : (null) Comment : UCDB created from 0-In DB . . . Attribute: Attribute: Attribute: Attribute: . . . Attribute: #### START Attribute: Attribute: Attribute: = CDC_CROSSING_RECORD-dmux_3211, Attribute type: attr handle handle fields for CDC_CROSSING_RECORD-dmux_3211: = CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 6 = CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 1 = CDC_TX_NAME, Attribute type: string, Attribute value = pi.control[2] Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value = clk1 Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value = po.data Attribute: name = CDC_RX_CLK, Attribute type: string, Attribute value = clk2 Attribute: name = CDC_VIA_SIGNALS, Attribute type: attr array #### START attr array elements: #### END attr array elements : #### END attr handle fields for CDC_CROSSING_RECORD-dmux_3211 Attribute: #### START Attribute: Attribute: Attribute: = CDC_CROSSING_RECORD-no_sync_35713, Attribute type: attr handle handle fields for CDC_CROSSING_RECORD-no_sync_35713: = CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 0 = CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 2 = CDC_TX_NAME, Attribute type: string, Attribute value = pi.control[1] Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value = Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value = po.active Attribute: name = CDC_RX_CLK, Attribute type: string, Attribute value = clk1 Attribute: name = CDC_VIA_SIGNALS, Attribute type: attr array #### START attr array elements: #### END attr array elements : #### END attr handle fields for CDC_CROSSING_RECORD-no_sync_35713 Attribute: name = CDC_CROSSING_RECORD-no_sync_19588, Attribute type: attr handle #### START attr handle fields for CDC_CROSSING_RECORD-no_sync_19588: Attribute: name = CDC_SCHEME_TYPE, Attribute type: int, Attribute value = 0 Attribute: name = CDC_SEVERITY_TYPE, Attribute type: int, Attribute value = 2 Attribute: name = CDC_TX_NAME, Attribute type: string, Attribute value = pi.control[1] Attribute: name = CDC_TX_CLK, Attribute type: string, Attribute value = Attribute: name = CDC_RX_NAME, Attribute type: string, Attribute value = po.data Attribute: name = CDC_RX_CLK, Attribute type: string, Attribute value = clk2 Attribute: name = CDC_VIA_SIGNALS, Attribute type: attr array #### START attr array elements: #### END attr array elements : #### END attr handle fields for CDC_CROSSING_RECORD-no_sync_19588 . . . #### END attr handle fields for CDC_RECORD name attr name name name name attr name name name name name name name = = = = SIMTIME, Attribute type: double, Attribute value = 0.000000 TIMEUNIT, Attribute type: string, Attribute value = us CPUTIME, Attribute type: double, Attribute value = 0.100000 DATE, Attribute type: string, Attribute value = 20100205121243
355

------------- DESIGN UNIT -----------------Name : work.tb_top Type : UCDB_DU_MODULE Source type : VERILOG File info : name = unknown.v line = 2 Flags : 0x00000100 Attribute: name = #DUSIGNATURE#, Attribute type: string, Attribute value = (null) ------------- DESIGN UNIT -----------------Name : work.top Type : UCDB_DU_MODULE Source type : VERILOG File info : name = /u/cshaw/examples/ucdb_cdc/cdc.sv line = 15 Flags : 0x00000100 Attribute: name = #DUSIGNATURE#, Attribute type: string, Attribute value = (null) ------------- INSTANCE SCOPE ---------------Name : .tb_top Type : UCDB_INSTANCE Source type : VERILOG File info : name = <none> line = 2 DU Scope : work.tb_top Weight : 1 Flags : 0x00000000 ------------- INSTANCE SCOPE ---------------Name : .tb_top.top0 Type : UCDB_INSTANCE Source type : VERILOG File info : name = <none> line = 15 DU Scope : work.top Weight : 1 Flags : 0x00000000
0-In Formal 0-In Formal analysis detects three types of information relevant to UCDBs and assertion coverage: An assertion firing increments the assertions failure count. An assertions sanity check firing increments the assertions pass count A cover points covered count is added to the cover points coverage count.
Use 0in_db2ucdb to generate a UCDB file that you can merge with simulation UCDBs to update your coverage reports with this information. For example, assume vsim simulation generated a UCDB file called vsim.ucdb and the Assertions window looks like:
356
Then run:
prompt> 0in_confirm .... prompt> 0in_db2ucdb -prefix TESTBENCH.r -prefix_modules "TESTBENCH top" \ 0in_confirm.db 0in.ucdb prompt> vcover merge merge.ucdb vsim.ucdb 0in.ucdb prompt> vsim -viewcov merge.ucdb
Two things have happened: the pass/failure counts have been incremented with the new formal analysis data and the formal analysis results (vacuous count, formal and proof radius fields) are now shown.
357
Command Reference 0in Shell Commands
0in Shell Commands

The 0in shell commands are the formal verification utilities executed from within the 0in shell (see 0in on page 347). These commands typically are run in batch mode from a command string or batch script. The 0in command can also be run interactively and each of the 0in shell utilities can be invoked from the 0in shell session. The 0in shell commands include the assertions compiler for simulation (ccl) and the formal model compiler (csl) for formal verification. For CDC analysis, the 0in shell has the following utility: cdc CDC compiler.
The 0in shell also has a command-line help facility, which has the following invocations:
shell prompt>0in -help
Reports the syntax for the 0in command.

0in>command -help
Reports the syntax for the command 0in shell command. For example:
0in>cdc -help
0in>cwhelp [global_directive | checker_type]
Reports the syntax for the specified global directive or checker type (see cwhelp on page 373). For example:
0in>cwhelp set_cdc_report 0in>cwhelp bits_on
Note You cannot include UNIX environment variables in a 0in shell script or within an interactive 0in shell session. However, it is permitted to include UNIX environment variables when invoking from the system shell prompt or from a system shell script.
358
Command Reference cdc
cdc
Compiles a clock domain model of the design; performs static CDC analysis; promotes CDC protocol assertions for formal verification and simulation; and promotes CDC-FX metastability injection logic for simulation. Syntax cdc d design [ report_clock | report_modes | report_hier_scripts | report_constraints block_pattern | hier | hier_block block [-output_hier_ctrl file] | hier_instance instance | [hier_cache ILM_cache] [hier_ctrl_file_model block CFM_ctrl_file]] [work work_library] [modelsimini init_file] [{L | Lf} library] [cuname comp_unit] [cache pathname] control_options := [[ctrl control_file] [ctrl_list control_filelist] [v95 | v2k | sv] [vhctrl control_file] [93 | 87 | 2002 | 2008] | [ctrl_module module] ] reporting_options := [cr report_file] [verbose] [gen_port_domain_template] [print_all_cdc_paths] [+nowarn{+messageID}] [+error{+messageID}] sdc_options := [sdc_in sdc_file] [sdc_out file] [report_sdc] advanced_options := [de {[module.]inst_pattern}] [di {[module.]inst_pattern}] [G name=value] [g name=value] [mode mode] [fx] [process_dead_end] [effort unlimited] [formal [formal_effort {low | medium | high | maximum}]] [auto_blackbox] compile_cdc_assertions_options := [compile_assertions prefix hierarchy_prefix [compiled_assertion_report file] [sim {questa | vcs | nc | nc3}] [sif root_name] [rel_paths] ] d design HDL design unit to be verified. To specify a particular VHDL architecture for a top-level entity, specify the architecture in parentheses with the entity name. For example: d top(arch). report_clock Report only clock domains and exit. Default: perform full CDC analysis. report_modes Generate a mode report in the 0in_detail.log file and exit. Default: run CDC analysis; do not generate a mode report. report_hier_scripts Generate hierarchical flow scripts; and exit. The generated flow scripts create their output files in the directory specified by the -od 0in shell option (default: run directory).
359
report_constraints block_pattern Generate hierarchical constraints files for the matching blocks (modules and entities); generate hierarchical flow scripts; and exit. The generated flow scripts create their output files in the directory specified by the -od 0in shell option (default: run directory).
hier Generate an interface logic model of the CDC logic of the design using a user-specified CDC constraints file (i.e., one manually constructed). This model is used to run hierarchical CDC analysis when the current DUT is instantiated as part of a larger design. Use this option if the top-level design is not available.
hier_block block Run block-level hierarchical CDC analysis for block (Verilog module or VHDL design unit) using the hierarchical CDC constraints in the specified control file (created by a previous cdc session using -report_constraints). Using the results, generate a CDC interface logic model for the block for use in top-level CDC analysis. Use this option if all instances of the block are homogeneous.
output_hier_ctrl file Name to give the control file generated for the block (when set_cdc_hier_preference -ctrl_file_models is specified). Default: 0in_cdc_hier_<block>_ctrl.v.
hier_instance instance Run block-level hierarchical CDC analysis for the specified homogeneous instances of a block using the hierarchical CDC constraints in the specified control file (created by a previous cdc session using -report_constraints). Using the results, generate a CDC interface logic model for the group of instances for use in top-level CDC analysis. Use this option if the instances of the block are not homogeneous.
hier_cache ILM_cache Use the specified CDC interface logic model caches generated from block-level analyses and perform top-level hierarchical CDC analysis on the DUT.
hier_ctrl_file_model block CFM_ctrl_file Use the CDC control file model corresponding to block in CFM_ctrl_file (which is typically generated by block-level analysis of block) and perform top-level hierarchical CDC analysis on the DUT.
work work_library Logical name of the design library containing precompiled design units. Also used as the target library for compilation performed by cdc. If work_library does not exist, it is created. Default: work in the current run directory.
modelsimini init_file Load init_file as the compiler initialization (modelsim.ini) file, which is used when vopt is called (under the hood). If you ran vlog and vcom compilation with the -modelsimini
360
init_file option, you must use this option with cdc and the option must point to the same file. Default: search path shown in Figure 3-4 on page 59. L library | Lf library Resource library containing pre-compiled modules for the clock domain model compilation. With the Lf argument, library is searched before searching in the effective uselib library (if specified) for the instantiation. With the L argument, library is searched after searching the effective uselib library. The LibrarySearchPath variable defines an initial resource library search path. When searching for a module for an instantiation, the libraries specified by LibrarySearchPath are searched in (left-to-right) order, as if they were specified with the L argument. If no match is found, the libraries specified in the Lf and L options are searched in the order specified in the command invocation. cuname comp_unit Specifies -cuname comp_unit when vopt is called (under the hood). If you ran vlog compilation with the -cuname comp_unit option, you must use the same option with csl/cdc. This option can be specified multiple times. Note that for 1-step csl/cdc compilation, -cuname root_cuname (default name of the global SystemVerilog package) is passed automatically. The root_cuname package contains everything outside the compiled modules/packages. When preparing to run Questa simulation, include the -cuname root_cuname option to vlog and vcom to catch these extra constructs. cache pathname 0in cache directory. Default: same as the 0in shell cache directory.
Control Options
ctrl control_file Verilog-flavor control file. ctrl_list control_filelist [] Verilog-flavor control file list. The dash () terminate a list of file names to separate the names from Verilog file names.
v95 | v2k | sv Verilog version (Verilog-95, Verilog 2000 or SystemVerilog) used in Verilog-flavor control files. Default: v2k if modelsim.ini variable vlog95compat is 0 or 95 if vlog95compat is 1. In Verilog 1-step mode, this argument specifies the Verilog version (v95 or v2k) used by the design files having .v extensions. Files with .sv extensions are assumed to be SystemVerilog files. Default for Verilog 1-step: -v2k.
vhctrl control_file VHDL-flavor control file.
361
-87 | -93 | -2002 | -2008 VHDL version: VHDL-87, VHDL-93, VHDL-2002 or VHDL-2008 used in VHDL-flavor control files. Default: value specified by the VHDL93 variable (default 2002) in modelsim.ini.
ctrl_module module Module or design unit in the -work library to use as a 0-In control file. You can use vcom/vlog to compile a 0-In control file (for example, if a 0-In control module or 0-In control design unit contains modeling logic), then use the -ctrl_module option to indicate the 0-In control modules and control design units used for analysis. For example, if ctrl.v is a 0-In control file with a Verilog module ctrl_mod that contains global directives. then the following sequence of commands:
prompt> vlog ctrl.v prompt> 0in -cmd cdc -d dut -ctrl_module ctrl_mod
is equivalent to:
prompt> 0in -cmd cdc -d dut -ctrl ctrl.v Reporting Options
cr report_file Name to give the CDC report file. Default: 0in_cdc.rpt. verbose Report the filtered CDC crossings (turned off using the -severity off option of the set_cdc_report directives) and the stable signals (identified by set_cdc_signal directives with the -stable option) in the Filtered CDC Checks Summary section of the 0in_cdc.rpt file. Report detailed warning messages related to the set_cdc_report global directives. For example, by default, if a set_cdc_report global directive has an invalid wildcard signal or an incomplete list of signals for reconvergence filtering, then a warning message that the global directive did not match any CDC crossing is issued (directive-214). With -verbose, the warning message specifies the type of error in the global directive. Also report the list of signals that match wildcard patterns for each directive that supports wildcards in arguments. To report crossings filtered by set_cdc_report -severity off and set_cdc_signal -stable directivesbut not the other extra informationuse set_cdc_preference -filtered_report directives.
gen_port_domain_template Generate a 0in_cdc_port_domain_template.v file containing set_cdc_port_domain directives for the primary ports.
print_all_cdc_paths Print all CDC paths to 0in_cdc_path.rpt.
362
+nowarn{+messageID} Turn off reporting of the specified warning messages. Message ID is a category and number (e.g., parser-47). Default: all warning messages reported.
+error{+messageID} Turn the specified warning messages into errors. Message ID is a category and number (e.g., parser-47).
SDC Options
sdc_in sdc_file Load the specified SDC file and use the SDC data to set up CDC analysis. sdc_out file Write the SDC data to file for use in downstream tools. report_sdc Generate the 0in_sdc_ctrl.v control file with global directives for the SDC data.
Advanced Options
de {[module.]inst_pattern} Exclude instances in module that match inst_pattern. Default module is the design. di {[module.]inst_pattern} Exclude instances in module that do not match inst_pattern. Default module is the design. The following example shows usage of di and de together.
top m2 m1 top m2
i1 i2
-di m1 -de mid.i*

m1 mid excluded logic i1 i2
i3 e1 i1 i2
i3
e1
i3
e1
G name=value Override the final value of the generic/parameter specified by name. The name can be a hierarchical path. For example, irrespective of the value in the source code, the value used for dut.u1.p1 is 10 in the following invocation.
0in -cmd cdc -d dut -G dut.u1.p1=10 -G p2=20 -infer_clk
0-In and Questa implementations for -G differ slightly:
363
Command Line 0-In has no blank space between the -G option and the parameter. For example: -G p1=10 (0-In) vs -Gp1=10 (Questa).
g name=value Default value of the generic/parameter specified by name. The name can be a hierarchical path. For example, unless the value of p1 is set by a defparam statement, the value used for p1 is 10 in the following invocation.
0in -cmd cdc -d top -g p1=10 -g p2=20 -infer_clk
0-In and Questa implementations for -g differ slightly: Command Line 0-In has no blank space between the -g option and the parameter. For example: -g p1=10 (0-In) vs -gp1=10 (Questa).
mode mode Infer all modes of operation or run CDC modal analysis on the design using the specified mode and exits (without doing any CDC analysis). Generate a modal script (0in_mode.scr). Directives that specify -mode arguments with different modes are ignored. Default: run regular CDC analysis. Directives that specify any -mode arguments are ignored.
fx Generate the 0in_cdc_fx_sim_ctrl.v control file with directives for the promoted cdc_fx checkers.
process_dead_end Report all CDC issues, including paths that do not connect to output ports (dead end paths). Default: CDC does not report issues found on registers in dead logic.
effort unlimited Set the effort level of CDC analysis to unlimited, which can increase runtime and memory usage.
formal Run formal CDC during static CDC analysis. formal_effort {low | medium | high | maximum} Effort level for CDC formal analysis. Default: low. -auto_blackbox Turns all unresolved modules/entities into inferred black boxes. An unresolved module/entity is one for which no module or entity/architecture definition is present. If a component declaration is present, the port directions are derived from that declaration. Otherwise, the port directions are inferred from the connected logic. If a port direction cannot be inferred, the port direction is assumed to be INOUT. Default: unresolved modules are treated as unused/undriven logic.
364
Command Reference cdc Compile CDC Assertions Options
compile_assertions Compile CDC protocol checkers and CDC-FX checkers into the -work library and create a simulator arguments file for simulation. Use set_cdc_report -promotion off directives to skip compilation of CDC protocol checkers for specific crossings. Assertion compilation uses the CDC logic model to generate the CDC protocol assertions and CDC-FX logic used by vsim. So compilation is much more efficient than running a separate ccl session to compile the CDC assertion logic. Default: compilation for simulation is not performed.
prefix hierarchy_prefix Hierarchy prefix showing the hierarchy from the top level (typically the testbench) to the DUT.
compiled_assertion_report file Name to give the generated CDC assertion compilation report. Default: 0in_cdc_checker.rpt.
sim {questa | vcs | nc | nc3} Target simulators (VCS, NC-Verilog, or 3-step NC-Verilog). Default: same as the 0in shell. The default Questa version is the same as the vsim executable in the current search path.
sif file Root name to give the generated simulation arguments file. Default root file name: 0in_cdc_sim.arg.
rel_paths Use relative pathnames in generated argument files. This option can be used to change the 0in_check.db link path to not use the absolute path name. For example,
0in_check.db -> ./0in_cache/DB/0in_check.db
Default: same as the 0in shell. Description The 0-In CDC analyzer (cdc) performs static CDC analysis of a compiled design.The cdc analyzer assumes all design units have been compiled into -work and if not, generates error messages and exits. Use the -report_clock option to report initial CDC information without performing a complete CDC analysis. Then use this information to set up the initial environment for performing CDC analysis. After setting up the starting configuration, run cdc to perform a full CDC analysis (Figure 6-3).
365
Figure 6-3. CDC Analysis with cdc

vcom/vlog design les -work library
cdc control les
0in_cdc.db
0in_cdc GUI debugging environment
Compile CDC Assertions
If you specify compile_assertions, cdc performs CDC analysis as usual, but also compiles assertion logicand CDC-FX injectors, if you also specify -fx (Figure 6-4). The -compile_assertions argument also creates simulator arguments files used to direct vcom/vlog compilation and vsim simulation. When specifying -compile_assertions, also include the -prefix hierarchy_prefix that identifies the hierarchy path from the testbench top level to the DUT analyzed by cdc. Figure 6-4. Compiling CDC Assertions
-work library vsim
0in_cdc.db
The following example has a Verilog testbench and a VHDL DUT: 1. Set up the work library.
prompt> vlib work prompt> vmap work work
366
2. Compile the design.

prompt> vcom dut.v
3. Run CDC analysis.

prompt> 0in -cmd cdc -d dut -ctrl dut_ctrl.v \ -compile_assertions -prefix tb.dut_inst
4. Compile the protocol assertions with the simulation arguments files generated by cdc.

prompt> vlog tb.v
6. Run simulation. Specify the PLI library path for the simulator and the vsim arguments files.
7. View the results in the GUI.

The 0in_cdc.db database is generated by cdc; 0in_checksim.db is generated by vsim. Note The -compile_assertions option currently compiles checkers for all enabled protocol checks and CDC-FX checks. You can use set_cdc_report -promotion off directives to mark instances of CDC schemes that should not be promoted (so they are not compiled by -compile_assertions). Note Running the cdc -report_constraints step of hierarchical CDC creates hierarchical constraints files for specified blocks. These files contain set_cdc_port_domain directives for the blocks ports. If a port is driven by multiple clock domains, is unused or is undriven, cdc cannot infer its clock domain and cannot create a set_cdc_port_domain directive that properly handles the port. To document which block ports have these properties, cdc creates set_cdc_port_domain directives with -none arguments. These directives are skipped and do not constrain the blocks.
367
Command Reference cdc Input Files
The input files for the cdc command are shown in Table 6-4. Table 6-4. cdc Input Files design library control files Specified with -work library. Control files that contain global directives for the following operations: Specifying attributes of clocks and clock groups. Changing attributes of CDC schemes. Setting preferences for CDC analysis. Adjusting attributes of promoted CDC protocol assertions and CDC-FX checkers. Controlling netlist generation. Optional SDC files to load and use to configure CDC analysis. Files used in hierarchical CDC flows: 0in_cdc_hier_constraints_block_ctrl.v Constraints file for running block-level CDC analysis on the specified block. Generated by running -report_constraints at the top level. 0in_hier/block/0in_cache Hierarchical CDC cache containing the ILM model of block, generated during block-level CDC analysis of block. 0in_cdc_hier_block_ctrl.v Hierarchical CDC control file containing the CFM model of block, generated during block-level CDC analysis of block (if set_cdc_hier_preference -ctrl_file_models is specified).
SDC files Hierarchical CDC
Output Files
The 0in_cache directory contains cached data for CDC analysis. Other output files are listed in Table 6-5. Table 6-5. cdc Output Files 0in_cdc.db 0in.log 0in_detail.log 0in_cdc.rpt 0in_cdc_design.rpt 0in_design.rpt 0in_cdc_setting.rpt 0in_cdc_path.rpt Database file of the cdc session. Short log file for the session. This is a copy of the standard output. Detailed log file for the session. Clock domain crossing report. The -cr option renames this file. CDC design report. Design report. CDC settings report. Details of the CDC paths. Generated if the cdc -print_all_cdc_paths option is specified.
368
0in_cdc_mode_ctrl.v
0in_cdc_param.inc SDC output file Hierarchical CDC
Compile Assertions
0in_cdc_port_domain_template.v
0in_cdc_fx_sim_ctrl.v
Control file containing directives that specify the mode inferred by modal analysis. Generated if the cdc -report_modes option is specified. Include file referenced by 0in_cdc_ctrl.v. File name is specified by -sdc_out. Default: 0in_sdc_ctrl.v. Files used in hierarchical CDC flows: 0in_cdc_hier_constraints_block_ctrl.v Generated by running -report_constraints at the top level. 0in_hier/block/0in_cache Generated during block-level CDC analysis of block. 0in_cdc_hier_block_ctrl.v Generated during block-level CDC analysis of block (if set_cdc_hier_preference -ctrl_file_models is specified). Files generated by -compile_assertions: 0in_cdc_sim.arg, 0in_cdc_sim_vhdl.arg, 0in_cdc_sim.arg.vsim , 0in_cdc_sim.arg.vsimrun. These are generated for Questa use. If another simulator is specified, other files are generated as well. Also generated: a compile assertions report (default name: 0in_cdc_checker.rpt). Template file of the set_cdc_port_domain directives for the primary ports (when -gen_port_domain_template is specified). Control file containing CDC-FX checker directives for simulation with metastability injection logic (when -fx is specified).
Examples Example 1
system prompt> vlib work system prompt> vlog -f source/filelist QuestaSim-64 vlog 6.6c Compiler -- Compiling module tb -- Compiling module dpmem2clk . . . system prompt> 0in -cmd cdc -d demo_top 0-In: 0-In Functional Verification System V3.0... . . . Command: cdc Command arguments: -d demo_top . . . Top level modules:
369
Command Reference cdc demo_top Analyzing design... -- Loading module demo_top -- Loading module generic_fifo_dc_gray -- Loading module dpmem2clk -- Loading module crc_16_calc Optimizing 4 design-units (inlining 0 instances): -- Optimizing module dpmem2clk(fast) Error: Design unit dump is compiled with older Questa simulator version. . . . Error : Design elaboration failed. [command-188] : Processing will abort. Error : Design Elaboration (Child process) returned a non zero status. [command-195] : Processing will abort. Error/Warning Summary ----------------------------------------------------------Count Type Message ID Summary ----------------------------------------------------------1 Error command-188 Design elaboration failed. 1 Error command-195 Design Elaboration (Child process) returned a non zero status. 1 Error elaboration-113 Design unit dump is compiled with older Questa simulator version.
This example compiles the Verilog files using vlog and then runs the cdc command. An error is returned because the design is compiled with an older version of vlog than the version compatible with V3.x tools. To avoid these types of errors, use the front-end utilities from the 0-In installation softwarenot the utilities in the Questa installation. Example 2
system prompt> $HOME_0IN/modeltech/bin/vlib work system prompt> $HOME_0IN/modeltech/bin/vlog -f source/filelist Model Technology ModelSim SE vlog QA Baseline: 6.6 ... -- Compiling module tb -- Compiling module dpmem2clk . . . system prompt> 0in -cmd cdc -d demo_top 0-In: 0-In Functional Verification System V3.0 . . . Command: cdc Command arguments: -d demo_top . . . Parsing files... Analyzing designs. Processing CDC checks for module demo_top Processing 113 candidates Processing 27 CDC signals after duplicate removal. CDC Summary ================================================================= Violations (8) ----------------------------------------------------------------Single-bit signal does not have proper synchronizer. (3)
370
Command Reference cdc Combinational logic before synchronizer. Reconvergence of synchronizers. (2) (3)
Cautions (10) ----------------------------------------------------------------DMUX synchronization. (2) Multiple-bit signal synchronized by DFF synchronizer. (4) Multiple-bit signal across clock domain boundary. (1) Memory Synchronization. (2) Simple DMUX synchronization. (1) Evaluations (8) ----------------------------------------------------------------Single-bit signal synchronized by DFF synchronizer. (7) Pulse Synchronization. (1) Waived (0) ----------------------------------------------------------------<None> Proven (0) ----------------------------------------------------------------<None> Filtered (0) ----------------------------------------------------------------<None> . . . Error/Warning Summary ----------------------------------------------------------Count Type Message ID Summary ----------------------------------------------------------1 Warning hdl-222 Possible dead end CDC paths not reported. 4 Warning hdl-41 Primary port connects to multiple clock domains. 25 Warning hdl-51 Port domain assignment inferred.
This example specifies the absolute path to the 0-In installed front-end utilities, which eliminates the version mismatch error that occurs in Example 1. Example 3: Compile Assertions (VCS) This example runs cdc with the -compile_assertions option and runs CDC protocol simulation with a VCS simulator.
vlib work vmap work work vlog test.v 0in -sim vcs -cmd cdc -d test -compile_assertions -prefix tb.dut vcs -R test.v $HOME_0IN/0InPLI/vcs/lib0InvcsPLI.so -f 0in_cdc_sim.arg 0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
Example 4: Compile Assertions (NC) This example runs cdc with the -compile_assertions option and runs CDC protocol simulation with an NC-Verilog simulator.
vlib work vmap work work
371
Command Reference cdc vlog test.v 0in -sim nc -cmd cdc -d test -compile_assertions -prefix tb.dut ncverilog test.v -f 0in_cdc_sim.arg 0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
Example 5: Compile Assertions (NC3) This example runs cdc with the -compile_assertions option and runs CDC protocol simulation with a 3-step NC simulator.
vlib work vmap work work vlog test.v 0in -sim nc3 -cmd cdc -d test -compile_assertions -prefix tb.dut ncvlog test.v -f 0in_cdc_sim.arg ncelab tb -snapshot test -f 0in_cdc_sim.arg.ncelab ncsim test -f 0in_cdc_sim.arg.ncsim 0in_cdc 0in_cdc.db -mergedb 0in_checksim.db
372
Command Reference cwhelp
cwhelp
Reports the syntax for a 0in global directive. Syntax cwhelp [directive] directive Report syntax for directive. Default: list the global directives with short descriptions. Description The cwhelp 0in shell utility reports the directive syntaxes for the 0in global directives. Examples
Default
The cwhelp utility with no arguments lists the global directives by the 0in utilities.
0in> cwhelp globals checker_firing_keyword checklist_off checklist_on default_reset Global Directives Adds a keyword to firing messages Excludes a specified checklist check from design file Includes a specified checklist check from control file Specifies a default reset . . . Checker Directives Ensures that a specified signal always asserts. Ensures that an arbiter conforms to a specified arbitration scheme and that no more than one grant asserts at any time. Ensures that in an assignment statement, the result of an arithmetic expression does not overflow the left-hand-side variable. . . .
. . .
checkers always arbiter
arithmetic_overflow
Global Directive Syntax
After using cwhelp with no arguments to find the name of a global directive, use cwhelp again to find the syntax for the global directive:
0in> cwhelp default_reset Command: cwhelp Command arguments: default_reset usage: default_reset
373
Command Reference cwhelp [<signal>] [-module <module_name>] [-none] [-infer] [-posedge or -active_high or -negedge or -active_low] [-sync or -async] [-help] Specifies a default reset
The syntax shows alias names for arguments (for example, -posedge is an alias for -active_high).
374
Command Reference Protocol/FX Checkers
Protocol/FX Checkers
Each checker type has a data sheet that provides the specification for checkers of that type. Data sheets contain the following information: Symbolic Representation Symbolic representation of a generic checker of that type. Description Description of the properties checked by checkers of the checker type. Syntax Syntax statement for the checker directive. Corner Cases Names of the corner case counts maintained by the checker. Statistics Names of statistics maintained by these checkers, with explanations of each. One statistic is designated as the evaluation statistic (evals), which typically corresponds to the number of times the checker evaluated. Notes Notes describing any special features or requirements of these checkers. Examples Examples of directives and checker applications.
Standard Options
One group of options (Table 6-6) is included in every syntax statement (except for certain special checker types that do not support some of the options). These options are called standard options and are indicated in syntax statements as: [standard_option] These options are universalthey have the same meaning for each checker type.
375
Command Reference Protocol/FX Checkers
Table 6-6. Standard Options of a Checker Directive standard_options ::= [-active signal] [-module mod] [-name identifier] [-group identifier] [-message string] [-severity level] [-quiet] [-assume_if constant] [-check_fire signal] [-corner_case variable] [-statistic variable] [-non_vacuous off] -active signal Signal to connect to the active input. If < is specified, the active input is the logical AND of signal with the inferred activation signal. Default (with <): inferred activation. Default (without <): always active. Module containing the signals and variables probed by the checker. Default: module containing the directive. Base name for the checker. Default: derived from the directive and hierarchy. Base name for the checker. Default: derived from the directive and hierarchy. User message shown when the checker fires (in addition to the firing message). Default: standard message only. Sets the severity level of the checker, level_constant is a constant or parameter that must evaluate to a positive digit [1..9]. You can override the severity level of a checker with the set_severity global directive. Default severity level is 0. Disables reporting of firing data without disabling firing signals from the checker. Default: firing data for the checker are always reported. If constant is not zero, this option marks all checks for the checker as check assumptions. If constant is zero, the checks are marked as targets unless overridden by an enable_assumption or exclude_target directive. The disable_assumption directive overrides this setting. Excludes non_vacuous check logic from the formal model. Default: csl compiles non-vacuity check logic for the checker. Connects the firing output for the specified check to the specified signal. Default: no connection. Outputs the specified corner_case count to the specified variable. Default: no output. Outputs the specified statistic to the specified variable. Default: no output.
-module mod -name {identifier | formatted_string} -group {identifier | formatted_string} -message formatted_string -severity level_constant
-quiet
-assume_if constant
-non_vacuous off -check_fire signal -corner_case variable -statistic variable
376
Command Reference cdc_dsel
cdc_dsel
active tx_clock tx_reset tx_data_select rx_clock rx_reset rx_data_select tx_data_stable_re rx_data_stable_re tx_min_re
signals
dsel
variables constants
minimum_time_window_equals_min tx_data transfers_checked evals rx_data longest_assertion tx_min shortest_assertion areset
default name: tx_data_var_tx_data_var checks: rings tx_data_stable (On) rx_data_stable (On) tx_min (On) tx_clock, tx_reset, areset: inferable from tx_dsel_signal corner cases rx_clock, rx_reset: inferable from rx_dsel_signal statistics vacuity property: !tx_reset && !rx_reset && !areset && active && tx_dsel_signal === 0
Description Ensures that a signal between two clock domains, where the transmitters data select signal drives the select input of a data multiplexor in the receiver, is held stable enough for the signal to be sampled reliably by the receiver and ensures that the data remains stable while the data select signal asserts. Syntax [<] {cdc_dsel | dsel} -tx_data tx_data_variable -rx_data rx_data_variable {-tx_data_select tx_dsel_signal | -tx_data_stable off} {-rx_data_select rx_dsel_signal | -rx_data_stable off} [-tx_min tx_min_constant | -tx_min_check off ] [-tx_clock tx_clock] [-tx_reset tx_reset ] [-rx_clock rx_clock] [-rx_reset rx_reset] [-assume [all | {txdata | rxdata | txdsel}]] [standard_option]
Required Arguments
-tx_data tx_data_variable Variable with the transmit data in the transmit clock domain. -rx_data rx_data_variable Variable with the receive data in the receive clock domain.
Inferable Options
[-tx_clock tx_clock] [-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferable from tx_dsel_signal. [-rx_clock rx_clock] [-rx_reset rx_reset] Receive clock and synchronous reset. If unspecified, each is inferable from rx_dsel_signal.
377
Command Reference cdc_dsel Checks and Related Options
Tx_data_stable check, default On {-tx_data_select tx_dsel_signal | -tx_data_stable off} The tx_data_variable value must not change while the data select signal tx_dsel_signal asserts in the transmit clock domain. This check requires tx_dsel_signal. This check occurs at the active transmit clock edge. The checker fires each time tx_data_variable improperly changes. The -tx_data_stable off option turns off this check. Firing message: tx_data_variable changed from last_tx_data to current_tx_data in the data transfer window.
Rx_data_stable check, default On {-rx_data_select rx_dsel_signal | -rx_data_stable off} The rx_data_variable value must not change while the data select signal rx_dsel_signal asserts in the receive clock domain. This check requires rx_dsel_signal. This check occurs at the active receive clock edge. The checker fires each time rx_data_variable improperly changes. The -rx_data_stable off option turns off this check. Firing message: rx_data_variable changed from last_rx_data to current_rx_data in the data transfer window.
Tx_min check, default On [-tx_min tx_min_constant | -tx_min_check off ] The tx_dsel_signal signal must not assert for fewer than tx_min_constant cycles of the transmit clock. This check requires tx_dsel_signal. This check occurs at the active transmit clock edge. The checker fires each time tx_dsel_signal improperly deasserts. The -tx_min_check off option turns off this check. If -tx_min is unspecified, the default tx_min_constant is 2. Firing message: tx_dsel_signal was asserted for number cycles, but the specified minimum assertion time is tx_min cycles.
Other Options
[-assume [all {txdata | rxdata | txdsel}]] Sets the following checks to formal assumptions:
o o o o
all (default) all enabled checks txdata tx_data_stable rxdata rx_data_stable txdsel tx_min
378
Corner Cases Asserted for tx_min Cycles number of times tx_dsel_signal asserted for exactly tx_min_constant cycles. Reported only if the tx_min check is enabled.
Statistics Transfers Checked (Evals) number of data transfers checked. Longest Assertion maximum number of clock cycles tx_dsel_signal remained stable between any two successive legal events. Shortest Assertion minimum number of clock cycles tx_dsel_signal remained stable between any two successive legal events.
Notes The following block diagram shows a typical implementation of a cdc_dsel checker:
TX Module
tx_data_select tx_dsel SYNC rx_dsel
RX Module
cdc_dsel checker MUX tx_data tx_data
rx_data
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock (inferable from -tx_data_select tx_dsel_signal) and the receive data are based on -rx_clock rx_clock (inferable from -rx_data_select rx_dsel_signal). The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -tx_data_select tx_dsel_signal. In either case, the reset applies to the entire checker, including logic on both clocks. 3. This checker is synchronous with respect to each clock, so it responds only to behavior that is observable at the active edge of the transmit or receive clock.
379
Examples
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data -tx_min 3 -rx_data_stable_off -tx_data_select tx_dsel -tx_min_fire tx_min_fire */
Checks that tx_dsel does not assert for fewer than 3 cycles of the transmitting domain clock.
tx_clk tx_dsel tx_min_re
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data -rx_data_stable off -tx_data_select tx_dsel -tx_data_stable_fire tx_data_stable_fire */
Checks that the value of tx_data does not change while tx_dsel asserts.
tx_clk tx_data tx_dsel tx_data_stable_re AF FF
/* 0in cdc_dsel -tx_data tx_data -rx_data rx_data -tx_min_check off -tx_data_stable off -rx_data_select rx_dsel -rx_data_stable_fire rx_data_stable_fire */
Checks that the value of rx_data does not change while rx_dsel asserts.
rx_clk tx_clk tx_data rx_dsel tx_data_stable_re AF 00 FF
380
Command Reference cdc_fifo
cdc_fifo
active tx_clock tx_reset enq rx_clock rx_reset deq wr_ptr rd_ptr depth wr_ptr_re rd_ptr_re enqueue_re dequeue_re full_count empty_count rings
signals
variables constants
enqueues_and_dequeues evals enqueues statistics dequeues maximum_fo_entries current_fo_entries areset
cdcf
corner cases
default name: enq_var_deq_var checks: wr_ptr (On) rd_ptr (On) enqueue (On) dequeue (On) tx_clock, tx_reset, areset: inferable from enq_signal rx_clock, rx_reset: inferable from deq_signal vacuity property: !tx_reset && !rx_reset && !areset && active && enq_signal === 0
Description Ensures that the write and read pointers of an asynchronous FIFO change by hamming distance one, and ensures that the FIFO does not overflow or underflow. Syntax [<] {cdc_fifo | cdcf} -enq enq_signal -deq deq_signal -depth depth_constant [-tx_clock tx_clock] [-tx_reset tx_reset] [-rx_clock rx_clock] [-rx_reset rx_reset] {-wr_ptr write_pointer_variable | -wr_ptr_check off} {-rd_ptr read_pointer_variable | -rd_ptr_check off} [-enqueue off] [-dequeue off] [-assume [all | {wptr | rptr | ptr | enq | deq}]] [standard_option]
Required Arguments
-enq enq_signal FIFO enqueue signal. This signal indicates that the current FIFO entries should increase by one.
-deq deq_signal FIFO dequeue signal. This signal indicates that the current FIFO entries should decrease by one.
-depth depth_constant FIFO depth, where depth_constant is an HDL constant. The depth must be greater than 1.
381
Command Reference cdc_fifo Inferable Options
[-tx_clock tx_clock] [-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferable from enq_signal. [-rx_clock rx_clock] [-rx_reset rx_reset] Receive clock and synchronous reset. If unspecified, each is inferable from deq_signal.
Checks and Related Options
Wr_ptr check, default On {-wr_ptr write_pointer_variable | -wr_ptr_check off} When the value of write_pointer_variable changes, the hamming distance between the previous and the new values must be 1. This check occurs at the active transmit clock edge. The checker fires each time write_pointer_variable improperly changes. The -wr_ptr_check off option disables this check. Firing message: The value (write_pointer) has a distance more than one from the previous value (previous_write_pointer).
Rd_ptr check, default On {-rd_ptr read_pointer_variable | -rd_ptr_check off} When the value of read_pointer_variable changes, the hamming distance between the previous and the new values must be 1. This check occurs at the active receive clock edge. The checker fires each time read_pointer_variable improperly changes. The -rd_ptr_check off option disables this check. Firing message: The value (read_pointer) has a distance more than one from the previous value (previous_read_pointer).
Enqueue check, default On [-enqueue off] An enqueue should not occur while the FIFO is full. This check occurs at the active transmit clock edge. The checker fires each time the FIFO improperly enqueues. The -enqueue off option disables this check. Firing message: An enqueue occurred while the FIFO was full.
Dequeue check, default On [-dequeue off] A dequeue should not occur while the FIFO is empty. This check occurs at the active receive clock edge. The checker fires each time the FIFO improperly dequeues. The -dequeue off option disables this check. Firing message: A dequeue occurred while the FIFO was empty.
382
Command Reference cdc_fifo Other Options
[-assume [all | {wptr | rptr | ptr | enq | deq}]] Sets the following checks to formal assumptions:
o o o o o o o
default enqueue, dequeue all all enabled checks wptr wr_ptr rptr rd_ptr ptr wr_ptr, rd_ptr enq enqueue deq dequeue
Corner Cases FIFO Is Full number of times the FIFO was full. FIFO Is Empty number of times the FIFO was empty.
Statistics Enqueues and Dequeues (Evals) number of times the FIFO enqueued or dequeued a value. Enqueues number of times the FIFO enqueued a value. Dequeues number of times the FIFO dequeued a value. Maximum FIFO Entries maximum number of values held in the FIFO at one time. Current FIFO Entries* number of values currently held in the FIFO.
* Cannot accumulate across multiple simulations. Notes The following block diagram shows a typical implementation of a cdc_fifo checker:
tx_clock write FIFO wr_ptr mem rd_ptr rx_clock read
TX Module
cdc_fo checker
RX Module
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock (inferable from -enq enq_signal) and the receive data are based on -rx_clock
383
Command Reference cdc_fifo
rx_clock (inferable from -deq deq_signal). The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -enq enq_signal. In either case, the reset applies to the entire checker, including logic on both clocks. 3. This checker is synchronous with respect to each clock, so it responds only to behavior that is observable at the active edge of the transmit or receive clock. Examples
/* 0in cdc_fifo -enq enq -deq deq -depth 8 -wr_ptr_check off -rd_ptr_check off -enq_fire enq_fire */
Checks that the FIFO does not overflow or underflow.

/* 0in cdc_fifo -enq enq -deq deq -depth 8 -wr_ptr write_ptr -wr_ptr_fire write_ptr_fire -rd_ptr read_ptr -rd_ptr_fire read_ptr_fire */
Checks that the values of write_ptr and read_ptr do not change by more than a hamming distance of 1.
rx_clk tx_clk write_ptr enq write_ptr_re rx_clk tx_clk read_ptr deq read_ptr_re 5 3 4 3 5
384
Command Reference cdc_glitch
cdc_glitch
active signals ags var used clock cdc_glitch_re rings
cglt
cycles_checked evals statistics reset areset
default name: var_signal checks: glitch (On) clock, reset, areset: inferable from var_signal vacuity property: !reset && !areset && active === 0
Description Ensures that the input signal to a specified register does not change more than once within a clock period. Syntax [<] {cdc_glitch | cglt} [-var var_signal] [-glitch off] [-used] [-clock signal] [-reset signal] [-areset signal] [standard_option]
Inferable Options
[-var var_signal] Register driven by the signal to be checked. If unspecified, it is inferred from the declaration or assignment in the most recent HDL statement on the same line as the beginning of the 0In comment.
Glitch check, default On [-glitch off] The value driving the var_signal register should not change more than once in a clock cycle. The active edges of the clock input define checking windows for this check (each active clock edge marks the beginning of a new clock cycle window). The checker monitors the wire driving var_signal combinationally and fires if var_signal changes value two or more times in a window (indicating a signal glitch). The firing output asserts at the start of the next cycle and is held asserted for the duration of the clock cycle. Firing message: The input signal to the specified register changed more than once within the clock period.
Other Options
[-used] The checker fires only if var_signal is used (that is, loaded into a destination register).
385
Command Reference cdc_glitch
Statistics Cycles Checked (Evals) number of cycles checked (i.e., the number of cycles that the signal driving var_signal changed value at least once).
Notes 1. This is an asynchronous checker that responds to combinational behavior. The clock signals active edges are used to define time windows for the checkers glitch detection logic. 2. Whereas the glitch checker checks for glitches on the specified -var signal, the cdc_glitch checker infers the driving logic to the specified -var register and checks for glitches on the inferred driving signal (connected to the var_d port of the cdc_glitch checker).
inferred connection checker checks for glitch on var_d var_d cdc_glitch var
//0in cdc_glitch -var var
Examples
// 0in cdc_glitch -var reg
Checks that the input (var_d) to the reg register does not glitch.
clk var_d glitch_re glitch
386
Command Reference cdc_hamming_distance_one
cdc_hamming_distance_one
active signals variables constants tx_clock tx_reset tx_var tx_min areset hamming_one_re stable_re value_changed_at_tx_min values_checked evals lontgest_stable_time shortest_stable_time
cdc_hamming1
default name: tx_variable rings corner checks: cases hamming_one (On) data_stable (Off) statistics tx_clock, tx_reset, areset: inferable from tx_variable vacuity property: !tx_reset && !areset && active === 0
Description Ensures that the data crossing from transmit clock to receive clock domain changes by only one hamming distance and that it remains stable for a specified tx_min clock cycles. Syntax [<] {cdc_hamming_distance_one | cdc_hamming1} [-tx_var tx_variable] [-tx_clock tx_clock] [-tx_reset tx_reset ] [-tx_min tx_min_constant] [-hamming_one off] [-assume [all | {dist | stable}]] [standard_option]
Inferable Options
[-tx_var tx_variable] Variable with the transmit data in the transmit clock domain. If unspecified, it is inferred from the declaration or assignment in the most recent HDL statement on the same line as the beginning of the 0-In comment.
[-tx_clock tx_clock][-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferable from tx_variable.
Hamming_one check, default On [-hamming_one off] The transmit data should only change by a hamming distance of 1. This check occurs at the active transmit clock edge whenever the value of tx_variable changes. The checker fires each time the hamming distance between the previous and the new tx_variable value is greater than 1. The -hamming_one off option disables this check. Firing message: The value (tx_variable_value) has a distance more than one from the previous value (previous_tx_variable_value).
387
Data_stable check, default Off [-tx_min tx_min_constant] The transmit data should remain stable for at least tx_min_constant cycles of the transmit clock. This check occurs at the active transmit clock edge whenever the value of tx_variable changes. The checker fires each time the value of tx_variable changes before tx_min_constant cycles have elapsed. Firing message: The value changed after number_of_cycles, but the specified minimum time to remain constant is tx_min_constant cycles.
Other Options
[-assume [all | {dist | stable}]] Sets the following checks to formal assumptions:
o o o
all (default) all enabled checks dist hamming_one stable data_stable
Corner Cases Value Changed at tx_min number of times tx_variable changed at tx_min_constant cycles. Reported only if the data_stable check is enabled.
Statistics Values Checked (Evals) number of values checked. Longest Stable Time most number of cycles tx_variable remained stable. Shortest Stable Time fewest number of cycles tx_variable remained stable.
Notes 1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock (inferable from -tx_var tx_variable) and the receive clock is unused. The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -tx_var tx_variable. In either case, the reset applies to the entire checker, including logic on both clocks. 3. This checker is synchronous with respect to the transmit clock, so it responds only to behavior that is observable at the active edge of the transmit clock.
388
Examples
/* 0in cdc_hamming_distance_one -tx_var tx_var -hamming_one_fire hamming_one_fire */
Checks that the value of tx_var only changes by a hamming distance of 1.

rx_clk tx_clk tx_var hamming_one_re 0011 0101
/* 0in cdc_hamming_distance_one -tx_var tx_var -tx_min 3 -stable_fire stable_fire */
Checks that each time the value of tx_var changes, the data remains stable for at least 3 cycles of the transmit domain clock.
rx_clk tx_clk tx_var stable_re 0101 0100 1100
389
Command Reference cdc_handshake_data
cdc_handshake_data
tx_invalid_handshake_re rx_invalid_handshake_re data_stable_re tx_valid_assert_until_done_assert_re tx_done_assert_until_valid_deassert_re tx_valid_deassert_until_done_deassert_re rx_valid_assert_until_done_assert_re rx_done_assert_until_valid_deassert_re tx_valid_stable_re tx_clock rx_done_stable_re tx_reset turnaround_max_re tx_valid turnaround_min_re tx_done rx_clock rx_reset rx_valid rx_done variables active
signals
cdc_hsd
turnaround_at_max turnaround_at_min handshake_cycles_started evals handshake_cycles_compeleted handshake_turnaround_time_max handshake_turnaround_time_min
tx_data
constants
tx_min rx_min turnaround_max turnaround_min
areset
default name: tx_valid_sig_tx_done_sig checks: cdc_handshake (On) data_stable (On) tx_valid_assert_until_tx_ done_assert (On) rings tx_done_assert_until_tx_ valid_deassert (On) tx_valid_deassert_until_tx _done_deassert (On) rx_valid_assert_until_rx_ done_assert (On) rx_done_assert_until_rx_ valid_deassert (On) tx_valid_stable (Off) corner cases rx_done_stable (Off) turnaround_max (Off) turnaround_min (Off) statistics clock, reset, areset: inferable from tx_valid_signal vacuity property: !tx_reset && !rx_reset && !areset && active && tx_valid_signal === 0
Description Ensures that the handshaking protocol between transmitter and receiver is correctly followed, and ensures that the transmit data remains stable in data transfer window. Syntax [<] {cdc_handshake_data | cdc_hsd} [-tx_data tx_data_variable] [-tx_clock tx_clock] [-tx_reset tx_reset] [-rx_clock rx_clock] [-rx_reset rx_reset] [-tx_valid tx_valid_signal] [-tx_min tx_min_constant] [-rx_min rx_min_constant] [-turnaround_max turnaround_max_constant][-turnaround_min turnaround_min_constant] [-cdc_handshake off] [-data_stable off] [-tx_valid_assert_until_tx_done_assert off] [-tx_done_assert_until_tx_valid_deassert off] [-tx_valid_deassert_until_tx_done_deassert off] [-rx_valid_assert_until_rx_done_assert off] [-rx_done_assert_until_rx_valid_deassert off] [-tx_done tx_done_signal] [-rx_valid rx_valid_signal] [-rx_done rx_done_signal] [-assume [all | {txval | tx_done | rxval | rxdone | data | max | min}]] [standard_option]
390
Command Reference cdc_handshake_data Inferable Options
[-tx_data tx_data_variable] Variable with the transmit data in the transmit clock domain. This variable is used with the cdc_handshake, data_stable and turnaround checks. If one of these checks is on and -tx_data is unspecified, it is inferred from the declaration or assignment in the most recent HDL statement on the same line as the beginning of the 0-In comment. If transmit data bus is not available, you must turn off the cdc_handshake and data_stable checks.
[-tx_clock tx_clock] [-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferred from tx_valid_signal. [-rx_clock rx_clock] [-rx_reset rx_reset] Receive clock and synchronous reset. If unspecified, each is inferred from rx_done_signal. [-tx_valid tx_valid_signal] Signal that indicates the transmit data in the transmit clock domain is valid. This signal is used with the cdc_handshake, data_stable, tx_* and turnaround checks. If one of these checks is on and -tx_valid is unspecified, it is inferred from the declaration or assignment in the most recent HDL statement on the same line as the beginning of the 0-In comment. If transmit valid signal is not available, you must turn off the cdc_handshake, data_stable and *_tx_valid_* checks.
Cdc_handshake check, default On [-cdc_handshake off] The handshake protocol must remain in a known state. This check requires tx_data_variable, tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal. This check occurs at the active transmit clock edge. The checker fires each time the handshake protocol is violated by the transmitter. A violation asserts either tx_invalid_handshake_fire or rx_invalid_handshake_fire. The -cdc_handshake off option turns off this check. Firing message: Handshake protocol was not followed properly by transmitter. Firing message: Handshake protocol was not followed properly by receiver.
Data_stable check, default On [-data_stable off] The transmit data (tx_data_variable) must be held stable in the data transfer window, which opens when tx_valid_signal asserts and closes when tx_done_signal asserts. This check requires tx_data_variable, tx_valid_signal and tx_done_signal. This check occurs at the active transmit clock edge. The checker fires each time the value of tx_data_variable is sampled changed in the data transfer window. The -data_stable off option turns off this check.
391
Firing message: tx_data changed from previous_value to value in the data transfer window. Tx_valid_assert_until_tx_done_assert check, default On [-tx_valid_assert_until_tx_done_assert off] The tx_valid_signal signal, once asserted, must remain asserted until tx_done is received. This check requires tx_valid_signal and tx_done_signal. This check occurs at the active transmit clock edge whenever a data transfer window is open. The checker fires each time tx_valid_signal deasserts before tx_done_signal is sampled asserted. The -tx_valid_assert_until_tx_done_assert off option turns off this check. Firing message: tx_valid deasserted before tx_done was received. Tx_done_assert_until_tx_valid_deassert check, default On [-tx_done_assert_until_tx_valid_deassert off] The tx_done_signal must remain asserted until tx_valid_signal deasserts. This check requires tx_valid_signal and tx_done_signal. This check occurs at the active transmit clock edge whenever a data transfer window is open. The checker fires each time tx_done_signal deasserts before tx_valid_signal deasserts. The -tx_done_assert_until_tx_valid_deassert off option turns off this check. Firing message: tx_done deasserted before tx_valid deasserted. Tx_valid_deassert_until_tx_done_deassert check, default On [-tx_valid_deassert_until_tx_done_deassert off] The tx_valid_signal must not assert again until the current tx_done_signal deasserts completing the current data transfer cycle. This check requires tx_valid_signal and tx_done_signal. This check occurs at the active transmit clock edge whenever a data transfer window is open. The checker fires each time tx_valid_signal reasserts before tx_done_signal deasserts to close the data transfer window. The -tx_valid_deassert_until_tx_done_deassert off option turns off this check. Firing message: New tx_valid asserted before current tx_done deasserted to complete the current data transfer cycle. Rx_valid_assert_until_rx_done_assert check, default On [-rx_valid_assert_until_rx_done_assert off] The rx_valid_signal signal, once asserted, must remain asserted until rx_done is received. This check requires rx_valid_signal and rx_done_signal. This check occurs at the active receive clock edge whenever a data transfer window is open. The checker fires each time rx_valid_signal deasserts before rx_done_signal is sampled asserted. The -rx_valid_assert_until_rx_done_assert off option turns off this check. Firing message: rx_valid deasserted before rx_done was received.
392
Rx_done_assert_until_rx_valid_deassert check, default On [-rx_done_assert_until_rx_valid_deassert off] The rx_done_signal must remain asserted until rx_valid_signal deasserts. This check requires rx_valid_signal and rx_done_signal. This check occurs at the active transmit clock edge whenever a data transfer window is open. The checker fires each time rx_done_signal deasserts before rx_valid_signal deasserts. The -rx_done_assert_until_rx_valid_deassert off option turns off this check. Firing message: rx_done deasserted before rx_valid deasserted.
Tx_valid_stable check, default Off [-tx_min tx_min_constant] The tx_valid_signal signal must be held stable for at least tx_min_constant transmit clocks. This check requires tx_valid_signal and is turned on by the -tx_min tx_min_constant option. This check occurs at the active transmit clock edge whenever tx_valid_signal deasserts. The checker fires each time tx_valid_signal deasserts prematurely. Firing message: tx_valid changed after number_of_cycles cycles, but the specified minimum time to remain constant is tx_min cycles.
Rx_done_stable check, default Off [-rx_min rx_min_constant] The rx_done_signal signal must be held stable for at least rx_min_constant receive clocks. This check requires rx_done_signal and is turned on by the -rx_min rx_min_constant option. This check occurs at the active receive clock edge whenever rx_done_signal deasserts. The checker fires each time rx_valid signnal deasserts prematurely. Firing message: rx_done changed after number_of_cycles cycles, but the specified minimum time to remain constant is rx_min cycles.
Turnaround_min check, default Off [-turnaround_min turnaround_min_constant] Each data handshake protocol cycle must not complete in fewer than turnaround_min_constant transmit clock cycles. This check requires tx_data_variable, tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal and is turned on by the -turnaround_min turnaround_min_constant option. This check occurs at the active transmit clock edge whenever the data transfer window closes. The checker fires each time the data transfer window closes before turnaround_min_constant transmit clock cycles. Firing message: Data transfer handshake cycle completed in number_of_cycles cycles, but the specified minimum turnaround time is turnaround_min cycles.
Turnaround_max check, default Off [-turnaround_max turnaround_max_constant] Each data handshake protocol cycle must not complete in more than turnaround_max_constant transmit clock cycles. This check requires tx_data_variable,
393
tx_valid_signal, tx_done_signal, rx_valid_signal and rx_done_signal and is turned on by the -turnaround_max turnaround_max_constant option. This check occurs at the active transmit clock edge. The checker fires each cycle the data transfer lasts more than turnaround_min_constant transmit clock cycles. Firing message: Data transfer handshake cycle completed in number_of_cycles cycles, but the specified maximum turnaround time is turnaround_max cycles.
Other Options
[-tx_done tx_done_signal] Signal that indicates data transmission is complete. This signal is required for the cdc_handshake, data_stable, tx and turnaround checks.
[-rx_valid rx_valid_signal] Signal that indicates the receive data in the receive clock domain is valid. This signal is used with the cdc_handshake, data_stable, rx and turnaround checks.
[-rx_done rx_done_signal] Signal that indicates data reception is complete. This signal is required for the cdc_handshake, data_stable, rx and turnaround checks. Note Important: If the rx_valid and rx_done signals are not available, you must turn off the cdc_handshake, rx_valid_assert_until_rx_done_assert and rx_done_assert_until_rx_valid_deassert checks.
[-assume [all | {txval | tx_done | rxval | rxdone | data | max | min}]] Sets the following checks to formal assumptions:
o o o
default cdc_handshake all all enabled checks txval tx_valid_assert_until_tx_done_assert, tx_valid_deassert_until_tx_done_deassert, tx_valid_stable, cdc_handshake txdone tx_done_assert_until_tx_valid_deassert, cdc_handshake rxval rx_valid_assert_until_rx_done_assert, cdc_handshake rxdone rx_done_assert_until_rx_valid_deassert, rx_done_stable, cdc_handshake data data_stable, cdc_handshake max turnaround_max, cdc_handshake min turnaround_min, cdc_handshake
o o o o o o
394
Corner Cases Turnaround Cycles Completed at turnaround_max number of times a data transfer completed in exactly turnaround_max_constant transmit clock cycles. Turnaround Cycles Completed at turnaround_min number of times a data transfer completed in exactly turnaround_max_constant transmit clock cycles.
Statistics Total Tx_valid (Evals) number of times tx_valid_signal was asserted, starting a new data transfer cycle. Total Turnaround Cycles number of data transfer cycles completed. Maximum Turnaround Cycles maximum number of transmit clock cycles taken for a complete data transfer cycle. Minimum Turnaround Cycles minimum number of transmit clock cycles taken for a complete data transfer cycle.
Notes The following block diagram shows a typical implementation of a cdc_handshake_data checker:
tx_valid Rx SYNC rx_valid
TX Module
cdc_handshake_data checker
RX Module
tx_done
Tx SYNC
rx_done
tx_data
data
rx_data
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock (inferable from -tx_valid tx_valid_signal) and the receive data are based on -rx_clock rx_clock (inferable from -rx_done rx_done_signal). The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -tx_valid tx_valid_signal. In either case, the reset applies to the entire checker, including logic on both clocks. 3. This checker is synchronous with respect to each clock, so it responds only to behavior that is observable at the active edge of the transmit or receive clock.
395
Examples
/* 0in cdc_handshake_data -tx_data tx_data -tx_valid tx_valid -tx_done tx_done -rx_valid rx_valid -rx_done rx_done -tx_invalid_handshake_fire tih_fire -rx_invalid_handshake_fire rih_fire -data_stable_fire ds_fire*/
Checks that the handshake protocol between transmitter and receiver is correctly followed and the value of tx_data remains unchanged during the data transfer.
/* 0in cdc_handshake_data -tx_data tx_data -tx_valid tx_valid -tx_done tx_done -rx_valid rx_valid -rx_done rx_done -cdc_handshake off -data_stable off -tx_valid_assert_until_done_assert_fire tvauda_fire -tx_done_assert_until_valid_deassert_fire tdauvd_fire -tx_valid_deassert_until_done_deassert_fire tvdudd_fire -rx_valid_assert_until_done_assert_fire rvauda_fire -rx_done_assert_until_valid_deassert_fire rdauvd_fire */
Checks that the handshaking protocol between the transmit and receive valid/done signal pairs is obeyed for each data transfer window.
rx_clk tx_clk tx_valid tx_done tvauda_re rx_clk tx_clk tx_valid tx_done tdauvd_re rx_clk tx_clk tx_valid tx_done tvdudd_re
396
rx_clk tx_clk rx_valid rx_done rvauda_re rx_clk tx_clk rx_valid rx_done rdauvd_re
/* 0in cdc_handshake_data -tx_valid tx_valid -tx_min 5 -rx_done rx_done -rx_min3 -cdc_handshake off -data_stable off -tx_valid_assert_until_done_assert_fire off -tx_done_assert_until_valid_deassert_fire off -tx_valid_deassert_until_done_deassert_fire off -rx_valid_assert_until_done_assert_fire off -rx_done_assert_until_valid_deassert_fire off -tx_valid_stable_fire tvs_fire -rx_done_stable_fire rds_fire */
Checks that tx_valid is held constant for at least 4 transmit clock cycles and that rx_done is held constant for at least 2 receive clock cycles.
rx_clk tx_clk tx_valid rx_done tvs_re rds_re
/* 0in cdc_handshake_data -tx_data tx_data -tx_valid tx_valid -tx_done tx_done -rx_valid rx_valid -rx_done rx_done -turnaround_min 10 -turnaround_max 16*/
Checks that the handshake protocol between transmitter and receiver is correctly followed and the value of tx_data remains unchanged during the data transfer. Also checks that the handshaking protocol between the transmit and receive valid/done signal pairs is obeyed for each data transfer window. Also checks that every data transfer cycle lasts at least 10, but no more than 16, transmit clock cycles.
397
Command Reference cdc_sample
cdc_sample
active tx_clock tx_reset rx_clock rx_reset setup_re hold_re all_one all_zero all_zero_to_one all_one_to_zero
signals
variables
tx_var rx_var
values_sampled evals sample_zero_bitmap sample_one_bitmap one_to_zero_transition_bitmap zero_to_one_transition_bitmap areset
sample
default name: tx_var_rx_var rings checks: setup (On) corner cases hold (On) tx_clock, tx_reset, areset: inferable from tx_variable statistics rx_clock, rx_reset: inferable from rx_variable vacuity property: !tx_reset && !rx_reset && !areset && active && rx_enable_signal === 0
Description Ensures that data between two clock domains remain stable in the transmit domain for one receive clock cycle before and one receive clock cycle after it is sampled in the receive domain. (i.e., the receive domain samples at least twice for each transmit signal so that the correct value is sampled). Syntax [<] {cdc_sample | sample} -tx_var tx_variable -rx_var rx_variable [-tx_clock tx_clock] [-tx_reset tx_reset] [-rx_clock rx_clock] [-rx_reset rx_reset] [-setup off] [-hold off] [-assume] [standard_option]
Required Arguments
-tx_var tx_variable Source variable in the transmit clock domain. -rx_var rx_variable Destination variable in the receive clock domain.
Inferable Options
[-tx_clock tx_clock] [-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferable from tx_variable. [-rx_clock rx_clock] [-rx_reset rx_reset] Receive clock and synchronous reset. If unspecified, each is inferable from rx_variable.
398
Command Reference cdc_sample Checks and Related Options
Setup check, default On [-setup off] For every cycle that rx_variable is sampled, the value of tx_variable must remain constant from the previous active transmit clock edge to the active receive clock edge at which the value of rx_variable is sampled. This check occurs at the active rx_clock edge whenever rx_variable is sampled. The checker fires each time tx_variable has improperly changed. The -setup off option turns off this check. Firing message: The transmit data were unstable before being sampled in the receive clock domain.
[-hold off] For every cycle that rx_variable is sampled, the value of tx_variable must remain constant from the active receive clock edge at which the value of rx_variable is sampled to the next active transmit or receive clock edge (whichever is earlier). This check occurs at the active rx_clock edge whenever rx_variable has been sampled at the previous active rx_clock edge. The checker fires each time tx_variable has improperly changed. The -hold off option turns off this check. Firing message: The transmit data was unstable after being sampled in the receive clock domain.
Other Options
[-assume] Sets all enabled checks to formal assumptions.
Corner Cases All Zero non-zero if every bit of rx_variable was sampled as 0. All One non-zero if every bit of rx_variable was sampled as 1. All One to Zero non-zero if every bit of rx_variable was sampled transitioning from 1 to 0 (that is, all bits of One to Zero Transition Bitmap are 1). All Zero to One non-zero if every bit of rx_variable was sampled transitioning from 0 to 1 (that is, all bits of Zero to One Transition Bitmap are 1).
Statistics Values Sampled (Evals) number of times rx_variable was checked. Sample Zero Bitmap bit vector representing which bits of rx_variable were sampled as 0. Sample One Bitmap bit vector representing which bits of rx_variable were sampled as 1.
399
Command Reference cdc_sample
One to Zero Transition Bitmap bit vector representing which bits of rx_variable were sampled transitioning from 1 to 0. Zero to One Transition Bitmap bit vector representing which bits of rx_variable were sampled transitioning from 0 to 1.
If more than 32 bits are specified, the bitmaps are displayed as hexadecimal values. Notes The following block diagram shows a typical implementation of a cdc_sample checker:
tx_var rx_var_d rx_var
TX Reg
RX Reg
tx_clk
cdc_sample checker
rx_clk
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock and the receive data are based on -rx_clock rx_clock. The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -tx_var tx_variable. In either case, the reset applies to the entire checker, including logic on both clocks. 3. The cdc_sample checker has an rx_enable port with an inferred connection to the sampling condition used to sample tx_variable in the receive clock domain. If the rx_enable connection cannot be inferred, the checker is excluded (directive-166 warning). Examples
/* 0in cdc_sample -tx_var tx_var -tx_clock tx_clk -rx_var rx_var -rx_clock rx_clk -setup_fire setup_fire -hold_fire hold_fire */
Checks that tx_var remains stable for the tx_clk cycle preceding, and for the tx_clk cycle after, each rx_clk edge at which rx_var is sampled.
rx_clk tx_clk tx_var rx_enable (inferred) setup_re hold_re AA A5 C5
400
Command Reference cdc_sync
cdc_sync
active signals tx_var[n]* tx_clock tx_reset tx_min areset stable_re value_changed_at_tx_min rings corner cases
sync
constants
values_checked evals shortest_stable_time statistics longest_stable_time
default name: tx_variable checks: stable (On) tx_clock, tx_reset, areset: inferable from tx_variable vacuity property: !tx_reset && !areset && active === 0
* one checker is instantiated for each tx_var bit Description Ensures that a clock domain crossing signal from a faster clock to a slower clock is held stable long enough for the signal to be sampled reliably by the receiver. Syntax [<] {cdc_sync | sync} [-tx_var tx_variable] [-tx_clock tx_clock] [-tx_reset tx_reset] [-stable off] [-tx_min tx_min_constant] [-assume] [standard_option*]
Inferable Options
[-tx_var tx_variable] Variable with the transmit data in the transmit clock domain. If unspecified, it is inferred from the declaration or assignment in the most recent HDL statement on the same line as the beginning of the 0-In comment.
[-tx_clock tx_clock] [-tx_reset tx_reset] Transmit clock and synchronous reset. If unspecified, each is inferable from tx_variable.
Stable check, default On [-stable off] The transmit data should remain stable for at least tx_min_constant cycles of the transmit clock. This check occurs at the active transmit clock edge whenever the value of tx_variable changes. The checker fires each time the value of tx_variable changes before tx_min_constant cycles have elapsed. The -stable off option disables this check. Firing message: tx_var changed after number_of_cycles cycles, but the specified minimum time to remain constant is tx_min_constant cycles.
401
Command Reference cdc_sync Other Options
[-tx_min tx_min_constant] Minimum number of transmit clock cycles that the value of tx_variable should remain stable. Default: 2 cycles.
[-assume] Sets the stable check to a formal assumption, if it is on.
Corner Cases Value Changed at tx_min number of times tx_variable changed at tx_min_constant cycles. Reported only if the data_stable check is enabled.
Statistics Values Checked (Evals) number of values checked. Longest Stable Time most number of cycles tx_variable remained stable. Shortest Stable Time fewest number of cycles tx_variable remained stable.
Notes The following block diagram shows a typical implementation of a cdc_sync checker:
tx_var
SYNC (double ff) rx_clk
TX Module
RX Module
tx_clk
cdc_sync checker
1. This is a dual-clock checker, in which the transmit data are based upon -tx_clock tx_clock (inferable from -tx_var tx_variable) and the receive clock is unused. The standard -clock option should not be specified. 2. Asynchronous reset for this checker can be specified using the standard -areset option. If this option is not specified, then the asynchronous reset is inferred from -tx_var tx_variable. In either case, the reset applies to the entire checker, including logic on both clocks. 3. This checker is synchronous with respect to the transmit clock, so it responds only to behavior that is observable at the active edge of the transmit clock.
402
Command Reference cdc_sync
Examples
/* 0in cdc_sync -tx_var tx_var -tx_min 3 -stable_fire data_stable_fire */
Checks that each time the value of tx_var changes, the data remains stable for at least 3 cycles of the transmit domain clock.
rx_clk tx_clk tx_var stable_re 5 3 4
403
Command Reference cdc_fx
cdc_fx
active cfx signals cdc_fx_re glitch_swallowed_re glitch_caught_re rings corner cases
all_bits_inverted tx_clock loading_while_clocks_aligned rx_clock evals rx_reset clocks_aligned_cycles rx_areset metastable_cycles loading_while_rx_clock_before_tx_clock loading_while_tx_clock_before_rx_clock rx_clock_before_tx_clock tx_clock_before_rx_clock rx_load_enable delayed_transitions clks_aligned[65:0] advanced_transitions bits_inverted inverted_bits_bitmap rx_reg tx_reg rx_q clocks monitor tx_clock rx_clock tx_reg rx_reg
statistics
default name: rx_reg checks: cdc_fx (Off) glitch_swallowed (Off) glitch_caught (Off) tx_clock, tx_reset, areset: inferable from rx_reg vacuity property: !tx_reset && !areset && active === 0
rx_reg value
Description Injects metastability at the output of a receive register. Syntax [<] {cdc_fx | cfx} -rx_reg rx_register_variable -tx_reg tx_register_variable [-rx_clock rx_clock] [-tx_clock tx_clock] [-rx_reset rx_reset] [-rx_areset rx_areset] [-rx_load_enable value] [-cdc_fx] [-glitch_caught] [-glitch_swallowed][standard_option]
Required Arguments
-rx_reg rx_register_variable Receiving register in the receive clock domain. -tx_reg tx_register_variable Transmitting register in the transmit clock domain. The tx_register_variable can be a concatenation of source registers for the receiving register (for example, {tx_reg3, tx_reg2, tx_reg1}).
404
Command Reference cdc_fx Inferable Options
-rx_clock rx_clock Receive clock. If unspecified, then it is inferred from rx_register_variable. -tx_clock tx_clock Transmit clock. If unspecified, then it is inferred from tx_register_variable. -rx_reset rx_reset Receive synchronous reset. If unspecified, then it is inferred from rx_register_variable. -rx_areset rx_areset Receive asynchronous reset. If unspecified, then it is inferred from rx_register_variable. -rx_load_enable value Asserted when rx_reg is loaded with valid data. If unspecified, then it is inferred from rx_register_variable.
cdc_fx Check, Default Off -cdc_fx Ensures the data output of the transmitting register is stable in the receiving registers metastability window. Typically, the data output of the transmit register can change value in the receive registers metastability window. This change can cause metastability of the receiving registers output, but the circuit is hopefully tolerant of this effect. However, an ad hoc synchronizer might presume the transmit logic prevents the transmitting register from changing value in the receiving registers metastability window. Therefore, the ad hoc synchronizer logic assumes the receiving register cannot become metastable. In this case, the cdc_fx check can be used to verify the transmit value is held stable whenever the transmit/receive clocks are aligned. Here, the cdc_fx check is a transmit protocol check for the ad hoc synchronizer. This check fires when any of the bits in the receive register is metastable. Default: fx checks are on for multi_bits, dmux, simple_dmux, multi_sync_mux_select, handshake and no_sync schemes; fx checks are off for all other schemes. Firing message: Data changed in metastability window.
glitch_caught Check, Default Off -glitch_caught Ensures metastability injection does not cause a glitch at the rx_reg input to be reflected as a pulse at the rx_reg output unless the glitch is also caught in simulation (see Figure 6-5 on page 406). The check fires at the second active receive clock edge after the glitch. The check reports a bitmap showing those rx_reg bits that had a glitch caught. Firing message: Glitch detected at the receiver output. Glitched output bitmap: glitch_caught_bitmap.
405
glitch_swallowed Check, Default Off -glitch_swallowed Ensures metastability injection does not cause a glitch at the rx_reg input to be swallowed (that is, missed) at the rx_reg output unless the glitch is also swallowed in simulation (see Figure 6-5). The check fires at the second active receive clock edge after the glitch. The check reports a bitmap showing those rx_reg bits that had a glitch swallowed. Firing message: Glitch swallowed by receiver output. Swallowed glitch bitmap: glitch_swallowed_bitmap. Figure 6-5. Transmit Protocol Checks for Glitches
cdc_fx checker rx_q tx_reg tx_clock Glitch_caught Check tx_clk rx_clk d glitch metastability injected rx_q q_sim glitch_caught_re Glitch_swallowed Check tx_clk rx_clk d glitch metastability injected rx_q q_sim glitch_swallowed_re metastability not injected metastability not injected d q_sim rx_reg rx_clock
406
Corner Cases All Bits Inverted nonzero if every output bit of the receive register has had metastability inserted. Loading While Clocks Aligned number of clocks aligned cycles in which rx_register_variable is loading.
Statistics Clocks Aligned Cycles (Evals) number of clocks aligned cycles in which tx_register_variable is changing. Metastable Cycles number of clocks aligned cycles in which tx_register_variable is changing and rx_register_variable is loading. Rx_clock Before Tx_clock number of receive clocks cycles in which rx_clock goes active before tx_clock and tx_register_variable is changing. Tx_clock Before Rx_clock number of clocks aligned cycles in which tx_clock goes active before rx_clock and tx_register_variable is changing. Loading While Rx_clock Before Tx_clock number of clocks aligned cycles in which rx_clock goes active before tx_clock, tx_register_variable is changing and rx_register_variable is loading. Loading While Tx_clock Before Rx_clock number of clocks aligned cycles in which tx_clock goes active before rx_clock, tx_register_variable is changing and rx_register_variable is loading. Delayed Transitions number of times metastability injection delayed a transition until the next cycle. Advanced Transitions number of times metastability injection advanced a transition to the current cycle. Bits Inverted number of bits of the receive register output that had metastability inserted (that is, the number of 1s in the inverted bits bitmap). Inverted Bits Bitmap bitmap of the bits that had metastability injected.
Notes 1. The following statistics and corner case are updated each cycle: Clocks Aligned Cycles, Tx_clock Before Rx_clock, Rx_clock Before Tx_clock, and Loading While Clocks Aligned. The other statistics and corner case are updated only if the rx_register_variable is loaded.
407
Command Reference cdc_custom_fx
cdc_custom_fx
signals tx_clock rx_clock active cdc_custom_fx_re all_bits_inverted ccfx evals clocks_aligned_cycles metastable_cycles bits_inverted inverted_bits_bitmap rx_q clocks monitor tx_clock rx_clock tx_reg rx_reg rx_reg value ring corner case
clks_aligned[65:0] rx_reg tx_reg
statistics
default name: rx_reg checks: cdc_custom_fx (Off) tx_clock, tx_reset, areset: inferable from rx_reg vacuity property: !tx_reset && !areset && active === 0
Description Injects metastability at the input of a custom synchronizer. Injection occurs when -tx_clock and -rx_clock align and the checker fires when data changes within the metastability window. Syntax [<] {cdc_fx | cfx} -rx_reg rx_register_variable -tx_reg tx_register_variable [-rx_clock rx_clock] [-tx_clock tx_clock] [-cdc_custom_fx off] [standard_option]
Required Arguments
-rx_reg rx_register_variable Receiving register in the receive clock domain. -tx_reg tx_register_variable Transmitting register in the transmit clock domain. The tx_register_variable can be a concatenation of source registers for the receiving register (for example, {tx_reg3, tx_reg2, tx_reg1}).
Inferable Options
-rx_clock rx_clock Receive clock. If unspecified, then it is inferred from rx_register_variable. -tx_clock tx_clock Transmit clock. If unspecified, then it is inferred from tx_register_variable.
408
Command Reference cdc_custom_fx Checks and Related Options
cdc_custom_fx Check, Default On -cdc_custom_fx off Ensures the data output of the transmitting register is stable in the receiving registers metastability window. Typically, the data output of the transmit register can change value in the receive registers metastability window. This change can cause metastability of the receiving registers output, but the circuit is hopefully tolerant of this effect. The -cdc_custom_fx off option disables this check. This check fires when any of the bits in the receive register is metastable. Firing message: Data changed in metastability window.
Corner Cases All Bits Inverted nonzero if every output bit of the receive register has had metastability inserted.
Statistics Clocks Aligned Cycles (Evals) number of clocks aligned cycles in which tx_register_variable is changing. Metastable Cycles number of clocks aligned cycles in which tx_register_variable is changing and rx_register_variable is loading. Bits Inverted number of bits of the receive register output that had metastability inserted (that is, the number of 1s in the inverted bits bitmap). Inverted Bits Bitmap bitmap of the bits that had metastability injected.
Notes Clocks Aligned Cycles is updated each cycle. The other statistics and corner case are updated only if the rx_register_variable is loaded. clks_aligned[65:0] When the assertion compiler instantiates a cdc_custom_fx checker, it also creates clock monitor logic that determines when the transmit clock is within the metastability window of the receive clock (for that transmit clock). Whenever this occurs, the receive register is prone to metastability if its input value also changes in that receive clock cycle. The clks_aligned output from the clock monitor is used to pass this information to the cdc_custom_fx checker. During the analysis phase, promotion is generated for the cdc_custom_fx checker. The tx_reg signal is the transmitting register. The custom synchronizer input port is specified as rx_reg. These promotions should only be done on the input ports of the custom synchronizer. If there is a crossing from an output port to another synchronizer, then no promotions are done. CDC promotion is enabled by the set_cdc_preference global directive.
409
Command Reference cdc_custom_fx
During simulation, metastability is injected on the port specified as rx_reg. The metastable value is a function of the data value on the port before and after the tx_clk edge. There are two main limitations when compared to general CDC-FX flow as follows: The active edge of rx_clk should occur after tx_clk. If rx_clk ticks before or in the same delta cycle as tx_clk, then metastability injection does not impact the simulation behavior. The data transitions can only be delayed. The data transitions cannot be advanced one clock cycle as in the general CDC-FX solution. In other words, the stop window is implicitly set to zero.
410
Chapter 7 GUI Reference

GUI Main Window
Menus Toolbar Debugging Windows
Design Data Windows
Analysis Windows
GUI Basics
The main GUI window has popup menus that appear when you select certain window objects and right-click. Each popup menu shows commands relevant to the selected object (or objects). For example, right-clicking on an instance of a CDC scheme displays commands (such as Show Source and Show Schematic) for displaying the various debug windows for that check.
Popup Menu
411
GUI Reference GUI Main Window
For some objects (such as check types and schematic objects), the GUI window has hover help, which displays relevant information about an object when you hover the cursor over the object.
u1.txdata3_r1
Hover Help
In the default layout, the design data windows and the analysis windows are stacked, that is, they occupy the same part of the GUI window. To display (bring to the front) a particular window, click on its associated tab.
Project Window Design Window
Design Tab
Drag and Drop

For some objects (such as ports, instances and signals), some GUI windows are linked by a drag-and-drop capability. Here, if you click-hold on an object in a source window, then drag the objects name and drop it into a target window, the object is added to the new window. For example, you can drag and drop objects from the objects window into a schematic window (Figure 7-1) and you can drag and drop signals from the details window to the waveform window
412
Figure 7-1. Dragging and Dropping a Port to the Schematic Window
Object Icon Click-hold and drag object to the target window
Showing and Hiding Columns in Windows

Use the configure columns buttons to show/hide columns (i.e., fields) in windows. Figure 7-2. Configuring Columns in Windows
Configure Columns Button Displays dialog for selecting columns to display in the window.
413
Showing and Closing Windows

Use the View menu to show and close a window. Use the close button (x) at the top right of a window to close that window.
View Menu
Indicates the pane is displayed
close Button (X)

Closes the window
Changing the Help Browser

Mozilla is the default help browser, but you can set a different browser for online help. To change the help browser for the GUI: Tools >Edit Preferences. Select the By Name tab. Set up the browserExec/browserCommand data: browserExec is the path to the browser executable; browserCommand is the command passed to the browser executable. For example: browserExec: /usr/bin/firefox browserCommand: -browser -height 500 -width 600 <URL> <URL> is a literal. It is used to pass the URL of the target document to the browser. For example, the invocation of the Firefox browser has URL as an option. For Mozilla, the option is openfile(URL), so its Command value is:
openfile(<URL>).
Depending on your selected browser, you might need to adjust some browser preferences. From the title page of an HTML document, scroll down and click on the Browser Requirements link. Select the Browser Settings topic and follow the directions for your brand of browser. With the Firefox browser, if the fonts are too small, you can adjust the font sizes from the browser itself (for example, using [CTRL SHIFT +] and [CTRL ]).
414
Window Layouts
Adjust the current window layout using the move-window buttons to drag windows to new locations and the stretch-shrink bars to adjust the sizes of the windows (Figure 7-3). Figure 7-3. Organizing the Window Layout
Move-Window Button Click-hold and drag window outline to the new location for the window.
Window Outline
Stretch/Shrink Bar Click-hold and drag window border to reshape the window
Zoom/Unzoom Buttons
When the window shows multiple windows, each window has a zoom button (+) at the top right of the window. A zoomed window takes up the entire layout (Figure 7-4). The other windows are available from tabs at the bottom of the window. When you select a tab, its window is displayed as a zoomed window. The unzoom button () on the zoomed window returns the window to the composite window layout.
415
Figure 7-4. Zoomed View of a Window

Zoom Button On a layout shows the zoomed view view of the window Unzoom Button Returns the window to the previous layout
Tabs for the other panes
Undock/Dock Buttons
The undock button at the top right of a window undocks the window, so it appears as a separate window (Figure 7-5). You also can undock a window by using its move-window button to drag the window to the edge of the main window. The dock button on an undocked window docks the window back into the main window. Figure 7-5. Undocking a Window
Undock Button Moves the window to its own window
Dock Button Re-docks the window back to the main window
416
Saving and Restoring the GUI Window Layout

Moving windows to new locations in the GUI window, adjusting the size and shapes of windows, showing and closing windows, undocking windows, zooming to a window, and undocking windows are all examples of modifying the GUI window layout. But different layouts are useful for different stages of the analysis and debug process. Rather than manually re-arrange the GUI window real estate each time you want to work on a new stage of the flow, you can save the current layout at any time. To do this, use the Layout >Save command and specify a name for the current window layout. The window layouts are stored as part of the project, so they persist between project sessions. To restore the GUI window to a saved layout, use the drop-down Layout menu from the toolbar or select the layout from the main Layout menu (Figure 7-6). Figure 7-6. Saving and Restoring a GUI Window Layout
Layout > Save Saves the current window layout with the specified name Layout Menus Restore saved window layouts
Tabs for the other panes
417
GUI Reference Analysis Windows
Analysis Windows
The CDC GUI has the following windows that show information about CDC analysis results. Errors/Warnings Window shows errors and warnings reported by CDC analysis. CDC Checks Viewer shows the static CDC analysis results and the merged results of formal verification and simulation with promoted CDC assertions.
Errors/Warnings Window
The error/warnings window (Figure 7-7) shows the errors and warning generated by the formal session. Figure 7-7. Errors/Warnings Window
Hover the cursor over a message to display additional information about the error/warning. Right-click on a message to pop up a menu that you can use to: Import Log loads information from a log file. Go to Source in the associated log file document in a source browser. Go to Log File in the detailed log file document in a source browser. Find displays the find panel.
418
Figure 7-8. Error/Warning Hover Help

Hover Help Hovering cursor over error message displays bubble help message with added information
CDC Checks Viewer

The CDC checks viewer (Figure 7-9) shows the static CDC analysis results and the merged results of formal verification and simulation with promoted CDC assertions. Entries in the CDC checks tab are instances of CDC checks (schemes) detected by CDC static analysis. Selecting a check shows detailed information in the details pane. Hovering over a selected group or CDC scheme entry shows bubble help with additional information about the selected object. The Static field of a scheme is the schemes status reported by static CDC analysis. If a Prove database is merged, a Prove field shows the formal analysis results for the associated protocol check. If a database generated by simulation with the promoted protocol checkers is merged, a Simulation field shows the simulation results. The Type field shows the merged results form all these analyses. See Status Flags on page 53 for an explanation of the status flags used to show the status of these field entries.
419
Figure 7-9. CDC Checks Viewer
Each entry also has the following information: Check Type of CDC scheme (for example: Two DFF Bus Sync, Combo Logic, DMUX). Mode User or inferred mode. Tx Signal Tx signal in the HDL. Rx Signal Rx signal in the HDl. Tx Clock Tx clock in the HDL. Rx Clock Rx clock in the HDL. Tx Module Module containing the tx signal driver. Rx Module Module containing the rx signal receiver. Tx File File containing the tx module and file line number of the tx signal. Rx File File containing the rx module and file line number of the rx signal. ID ID that identifies the scheme and the design objects associated with it. The name of the promoted checker includes this ID so simulation and formal results can be merged into the static CDC results (see Path and Protocol ID on page 49).
If a simulation database (created by simulating the CDC protocol checkers) is merged in, each entry has the following additional information: Checker Name of the CDC protocol checker. Evaluations Evaluation count of the checker in simulation.
420
Covered Whether or not the checkers corner cases were covered in simulation. Firings Number of times the checker fired in simulation.. First Firing Testbench time of the first firing, if the checker fired.
Right-click on an entry to pop up a menu: Show Source view the declaration of the TX signal driver or the RX signal receiver. Schematic view the CDC path in a schematic window and highlight the TX or RX signal. Simulation Firings view a firings waveform for the protocol check promoted for the selected CDC scheme (if the check fired). Coverage view simulation coverage data for the protocol check promoted for the selected CDC scheme in the details window. Details view details of the selected schemes in the details window.
Filter set and manage filter lists that hide groups of CDC scheme entries based on various criteria. Also used to create set_cdc_report directives from filtered elements: From Instance hide schemes on paths that originate from specified design instances. To Instance hide schemes on paths that end at specified design instances. By Column view Filter CDC Checks dialog for filtering entries based on their CDC checks tab field values. Selected add the currently selected schemes to the filtered list. Clear All clear the filtered list. Import clear the current filtered list and load a previously-saved filtered list. Export save the current filtered list.
Reset Columns redisplay hidden columns and display columns in the default order. Create Directive view Set Cdc Report dialog for creating set_cdc_report directives. Dialog fields are pre-filled with information extracted from the selected scheme. Find view Search CDC Checks View dialog for searching for specified text in column entries.
Help invoke HTML help for the selected CDC scheme type.
421
GUI Reference Debug Windows
Debug Windows
The CDC GUI has the following tools used to debug problems detected by CDC analysis: Details Window shows details for the design instances/entities. Objects Window design objects (ports and internal registers/nets) for design units. Log/Report Browsers shows logs and reports. Schematics Viewer shows schematics for the design. Source Code Editor displays and edits source code.. Waveform Viewer shows waveforms for assertion firings, sanity checks, anystate checks and cover points.
The debug windows are not all stacked together like the design data windows and the analysis windows. The firings, objects, details and FSM viewer windows are singular windows. Only one of each can be displayed and the contents are updated depending on your selections in the analysis windows. The source code editor, schematic browser and waveform viewer are multiple windows. You can display multiple instances of each of these windows. Each of these three groups of windows are stacked. For example, you can display waveforms for several property violations at the same time. The waveform windows are stacked together. Clicking on a tab displays its associated waveform viewer in front.
Details Window
The details window (Figure 7-10) shows the details for the design instance or entity selected in the design window. Figure 7-10. Details Window
The window shows the following information: Name instance/entity name. Inst Type type of instance (for example, Module Instance). Module name of the model (module/architecture) for the instance.
422
Clock Group clock group that clocks the instance, or unspecified. Assertion MSD ratio of the instances registers covered by assertions (within the Minimum Sequential Distance).
Objects Window
The objects window (Figure 7-11) displays design objects (ports and internal registers/nets) for the current design unit instance . Click on a design unit instance in the design window to select the current design unit. Figure 7-11. Objects Window
Use drag-and-drop to add selected objects to the waveform viewer or the schematics viewer. Right-click on an entry to pop up a menu that you can use to: Go to Declaration in the source file in a source code editor. Edit Directive Set Signal see set_cdc_signal on page 299. Set Reset see set_reset on page 312. Set Constant see set_constant on page 305. Set Port Domain see set_cdc_port_domain on page 276. Set Clock see set_cdc_clock on page 263.
Show in Schematic New View open a new schematic viewer showing the selected objects. Active View add the selected objects to the active schematic view.
423
Abstract View show the selected objects in an abstract view of the design unit.
Select in Schematic selects and highlights the selected objects in the active schematic view. Add to Path Tracing From Signals Add the selected objects to the From Signals group for path tracing. To Signals Add the selected objects to the To Signals group for path tracing. Thru Signals Add the selected objects to the Thru Signals group for path tracing.
Add to Wave Window Current add the selected objects to the current waveform view. Always always add the selected objects to new waveform views.
Log/Report Browsers
You can open a log or report directly in a browser (Figure 7-12): File > Open or in the toolbar.
Log menu to view a particular log file. Report menu to view a particular report. Figure 7-12. Log/Report Browser
424
You also can open a log (Figure 7-13) indirectly from the popup menu for a selected item in the errors/warnings window: Go to Log File shows the log with the corresponding error/warning flagged. Figure 7-13. Log Browser Showing Error/Warning Information
425
GUI Reference Schematics Viewer
Schematics Viewer
Running a Show >Schematic command for a CDC check or a Show in Schematic command for a clock in the Clocks window displays a schematic view of the clock domain crossing scheme or the drivers/receivers of the selected clock (Figure 7-14). Figure 7-14. Schematics Viewer
Expanding Logic in the Schematic View

The Show >Fanin popup command for a property (in the Properties tab) displays the collapsed schematic view of the property. You can expand the view to show details of the fanin logic driving the property. You can:
426
Expand the view to show the drivers/readers of a net or port. To do this, double-click on the net or port.
expand drivers/readers of a net or port double-click on net/port
Expand the view to show details of combinational logic. To do this, double-click on the combo logic block.
expand combinational logic double-click on logic block
TBS
427
Zooming the Schematic View In or Out

A quick way of zooming the view (in or out) to fit the viewer (i.e., zoom full) is to middle-click and drag up and left.
zoom-to-fit
drag middle-mouse up & left
A quick way of zooming the view out is to middle-click and drag up and right. The longer the distance dragged, the greater the amount zoomed.
drag middle-mouse up & right
zoom out
A quick way of zooming the view in is to middle-click and drag left/right (level or down). The view zooms in to the range selected by the bounding box.
drag middle-mouse down & left or right zoom in
428
GUI Reference Source Code Editor
Source Code Editor

You can open a source code file for editing or browsing (Figure 7-15): Directly: File > Open or in the toolbar: opens the specified file at line 1.
Edit from the project window popup window opens the selected file at line 1.
Indirectly from the popup menu for certain selected items: Go to Declaration opens the source code file containing the items declaration with the declaration flagged. This command is available for the following windows: project, design, modules and objects. Go to Instantiation opens the source code file containing the module instantiation with the instantiation flagged. This command is available for the following windows: design and modules. Go to Source opens the source code file containing the erroneous construct with the construct flagged. This command is available for the following window: errors/warnings. Show Source opens the file containing the associated construct with the construct flagged. This command is available for the following windows: property checks, policy checks, design checks, properties and firing inputs. Figure 7-15. Source Code Editor
429
GUI Reference Waveform Viewer
Waveform Viewer
The Show Waveform command for a CDC protocol check firing displays a waveform for the firing (Figure 7-16). Figure 7-16. Waveform Viewer
Saving Waveforms and Waveform Formats

As you use the waveform viewer to analyze firings and coverage data, you can adjust the formats of various view objects to customize the views appearance and organize the waveforms to help simplify your analysis. Then, you can take a snapshot of the current setup of a wave view to use for multiple purposes. To save this snapshot: File >Save Format. In the Save Format dialog, specify a pathname to save the waveform format file.
The wave view data are saved as a do file.
Loading Waveforms and Waveform Formats

You can load a waveform configuration file into an empty view, edit the file and load it into another view and also take code snippets from the file to create a custom do file for other uses. To reconstitute a saved view in an empty viewer: From a view generated from the same data as the saved view: File >New Window. An empty wave viewer appears. From this viewer: File >Load. From the Open Format dialog, select the saved do file. The new viewer displays the saved wave view.
430
To load saved wave format data into the current wave view: Create a do file with the desired wave format data (taken from a saved waveform format file), for example:
WaveRestoreCursors {{Config Complete} {1033 ns} 1} configure wave -justifyvalue right configure wave -timelineunits ps bookmark add wave {Cmd Load} {{1774 ns} {3709 ns}} 0 bookmark add wave Firing {{893 ns} {4887 ns}} 0
From the current wave view: File >Load. From the Open Format dialog, select the do file. To load saved wave format data into the every wave view: Create a do file with the desired wave format data (taken from a saved waveform format file), for example:
add wave -noupdate -format Logic -radix binary replay_qvl_.../clock1 add wave -noupdate -format Logic replay_qvl_.../pci_err__in add wave -noupdate -format Logic -radix binary replay_qvl.../combo WaveRestoreCursors {{Config Complete} {1033 ns} 1} configure wave -justifyvalue right configure wave -timelineunits ps bookmark add wave {Cmd Load} {{1774 ns} {3709 ns}} 0 bookmark add wave Firing {{893 ns} {4887 ns}} 0
From the GUI main window: Tools >Edit Preferences. From the Edit Preferences dialog, go to the Misc tab. In the Waveform section, add the do file to the Configuration File field. This procedure applies the saved wave view formatting to every waveform. The identity of the wave format configuration file is saved in .0in_ui_local_prefs, so it is persistent across GUI sessions run from the current directory. You also can use this procedure to automatically load a reference set of specific signals to every waveform. These signals provide a baseline for analyzing formal results. If the added signals are in the fanin/fanout cones of the current property, formal analysis controls affect their individual waveforms and the baseline information is useful. Signals not in these cones provide baseline information up to the starting state for formal analysis, but are set to flat-line after that.
Zooming the Wave View In or Out

Use the zoom in, zoom out, zoom full and zoom in on active cursor icons ( ).
431
A quick way of zooming the view (in or out) to fit the viewer (i.e., zoom full) is to middle-click and drag up and left.
drag middle-mouse up & left
zoom-to-fit
A quick way of zooming the view out is to middle-click and drag up and right. The longer the distance dragged, the greater the amount zoomed.
drag middle-mouse up & right
zoom out
A quick way of zooming the view in is to middle-click and drag left/right (level or down). The view zooms in to the range selected by the starting and ending points.
drag middle-mouse down & left or right zoom in
Capturing Zoomed/Scrolled Views as Bookmarks

As you analyze a waveform, you zoom the view in and out, scroll the waves back and forth in time and scroll up and down lists of signals. Often you want to capture specific views, so you can quickly jump the view to them. Such a captured view is called a bookmark. You can: Create a bookmark for the current view: Add >Bookmark. In the Bookmark Properties dialog, provide a mnemonic for the view in the Bookmark Name field. By default, the bookmark saves the zoom value (Zoom Range) and the vertical scroll location (Top Index). You can select to save either or both with the bookmark. Jump the viewer to a saved bookmark view: View >Bookmarks >name. The Bookmarks submenu lists all the saved bookmarks. Here, name is ne of the bookmarks.
432
Manage bookmarks: View >Bookmarks >Bookmarks. Use the Bookmark Selection dialog to Add, Modify, Delete and Goto individual bookmarks.
Selecting Multiple Signals for Format Operations

Some format operationssuch as setting the signal value radix and combining signals into signal groupscan be applied to multiple signals at a time. When you click on a signal, it is selected (but other selections are deselected). To select multiple signals: Use SHIFT-click to select a range of adjacent signals. Use CTRL-click to add individual signals to the current selection.
Changing the Display Properties of Signals

Double-click on the signal name. The Wave Properties dialog for the signal is displayed. You can: Give the signal a Display Name, which is shown in the pathname pane in place of the signal name. Select colors for the signal waveform (Wave Color) and signal name (Name Color). Change the Radix (for example, decimal, octal, hex, binary) for the displayed signal value.
To change display properties for multiple signals, select the signals and use the Format menu commands (Radix, RadixEnum, Format, Color and Height) to adjust their display properties as a group.
Changing the Signal Pathname Properties

Signal names are shown in the grey signal pathname pane at the left of the waveform viewer. You can toggle between short signal names and full pathnames.
Click on the toggle leaf/full names icon (

toggle leaf names full names
) at the top left of the cursor pane.
edit grid/timeline
433
Since full signal names can be overly long, you can set the maximum number of hierarchical levels displayed in the long names. To do this: click the edit grid/timeline icon ( ) next to the pathname toggle icon. From the Display tab of the Wave Window Properties dialog, set the Display Signal Path field to the maximum number of pathname elements to display.
Adding Signals
To add signals, do one of the following: From the signals pane popup menu, run Add Signals >Current View. In the Add Signal to Wave Window dialog, select the signals and click on Add. From the objects window, select an object to add to the waveform. Drag and drop the object to the signals pane of the waveform viewer.
drag and drop Waveform View Objects Window
434
These signals are added to the current wave view. You also can identify signals to add to every wave view. To do this: From the signals pane popup menu, run Add Signals >Always. In the Always Add Signals to Wave Display dialog, update the Always Add These Signals list.
Removing Signals
To remove signals from the viewer: select the signals and press Delete.
Organizing Signals
The signals panel at the left of the waveform viewer lists the signals in the waveform. Signals are identified by blue diamonds ( ). To organize the signals in the signals panel you can: Combine signals into a bus. To do this: select the signals for the bus and run Tools >Wave >Combine Signals. From the Combine Selected Signals dialog, provide a name for the new bus. Set the other fields to determine the ordering of the signals in the bus. To remove the old signals after the bus is created, select Remove selected signals after combining. The created bus is identified by a red diamond ( ). The bus waveform shows the the combined values of the constitute signals.
Combine signals into a wave group. To do this: select the signals for the group and run Tools >Groups. From the Wave Group Create dialog, provide a name for the new wave group. The created group is identified by a red diamond ( ). No waveform is displayed for the group itself, but waveforms for the group members are displayed when the group is expanded.
435
Add category dividers. Signals in the signals panel are separated into categories labeled with dividers. When you add signals they are automatically assigned to the Added Signals category (unless they are added by dragging and dropping). To help you organize signals, you can add new category dividers. To do this, select the signals and run View >Wave >Add >Divider. The Wave Divider Properties dialog is displayed. Specify a divider name and specify the divider height (to add extra spacing around the divider).
custom category dividers
To move a divider to a new location, select the divider and drag. To delete a divider, select the divider and press Delete. Re-order signals. Select the signals and drag to the new location. You also can sort the signals alphabetically with the View >Wave >Sort commands (Ascending, Descending, Ascending Full Path and Descending Full Path). Signals are sorted within each category (defined by the dividers).
Using Multiple Window Panes

Initially, the wave view has a single window pane showing the signals and waveforms. The wave view has one scroll bar. So for large numbers of signals, you scroll back and forth to visualize comparisons. To solve this problem, you can add one or more window panes. To do this, run Add >Window Pane. A new empty window pane with a scroll bar is added just above the cursor region. Then, you can drag and drop (or copy and paste) signals from the original pane to the added pane.
436
original pane pane boundary active pane bar added pane drag and drop signals to the new pane separate scroll bars
Click and drag the pane boundary to reshape both panes. To delete a pane, click in the pane (the active pane is identified with a white bar) and run Edit >Delete Window Pane.
Using Cursors to Analyze Events
The initial waveform shows at least three cursors. These are vertical lines that let you compare signal behavior at specific times. Start indicates the starting state of formal analysis. Firing indicates a firing of the associated assertion or sanity check. For a cover property or covered checker, the Firing cursor indicates when the property became covered. A user-defined cursor is also displayed.
The left (gray) panel of the cursor pane lists the cursors. You can: Lock/unlock a cursor by clicking on the corresponding lock icon ( ). A locked cursor cannot move and is shown in red. The Start and Firing cursors are initially locked and should be left locked. You can slide an unlocked cursor back and forth in time. The cursor time is shown at the bottom of the cursor and also in the left panel. To set a cursor at a precise time (for example, if you have trouble adjusting the cursor), click on the corresponding cursor tool ( ). Type the exact time in the Cursor Properties dialog. Give the cursor a name by selecting and right-clicking on the cursor name and entering a user-specified name. Add a new cursor by clicking on the add cursor icon ( ).
Remove a cursor by selecting the cursor and clicking on the corresponding remove cursor icon ( ).
437
Capturing a Waveforms Image

Undock and size the waveform viewer. From the undocked waveform viewer: To save the image as a BMP file, File >Export >Image. Use the Save Image dialog to save the file. To save the image as a PostScript file, File >Print PostScript. Use the Write PostScript dialog to print all or part of the waveform to a PS file.
Do not remove the focus from the waveform window until the capture completes (to prevent the captured image from being corrupted).
Adding a Source Code Variable to a Waveform

You can add a source code variable as a signal in a waveform view in two ways: Select the variable. All references to the variable are then highlighted. Drag and drop any reference to the variable to any wave view at the desired location.
add a signal to a wave view from the source code viewer
drag and drop
Select the variable. All references to the variable are then highlighted. Place the cursor over one of the variables references and run the Add to Wave Window popup command. The signal is added to the Added Signals category of the last displayed wave view. Drag the signal to the intended category and location.
Annotating Source Code with Variables Values

You can turn on source code annotation in either of two ways:
438
Use the Source Annotation button in the toolbar ( on/off. Run View >Show Source Annotation.
) to toggle source code annotation
With source code annotation on, the source code view shows values of the variables in the source code. They are displayed in red under the associated variables. The variables values are their values at the time of the current selected cursor in the current wave view. So, as you move a cursor along a wave view, the source code reflects the changing values of the variables.
moving a cursor changes the annotated values
variables values are shown for the time of the current active cursor
439
GUI Reference Project Mode Windows
Project Mode Windows

The CDC GUI has the following windows that show information about CDC projects. Project Window manages the source code files for the project. Design Window shows the hierarchy of the DUT instances. Modules Window shows the DUT design units. Clocks Window shows the DUT clock signals. Directives Window shows the current global directives.
The project mode windows display objects at the design unit level, set global directives for the objects, manage source files for the project and set basic project properties. In addition, some windows have a find panel (Figure 7-17). Use this panel to search for matches to specified text in the window Figure 7-17. Find Panel in Design Data Windows
Pull-down Menu
Wrap search Match whole word Find all matches Search direction
Project Window
The project window (Figure 7-18) manages the source code files for the project. Figure 7-18. Project Window
440
Right-click on an entry to pop up a menu that you can use to: Edit the source file. Compile the source file, all source files or the out-of-date source files. Add to Project new or existing files. Import File List from a Verilog or VHDL filelist file. Change Compile Order move the selected files up or back in compile order. Remove from Project the selected source file. Change Compile Options change the work library, language syntax or language type and add command line options. Close Project close the current project.
Design Window
The design window (Figure 7-19) shows the hierarchy of the DUT instances. Figure 7-19. Design Window
Right-click on an entry to pop up a menu that you can use to: Go to instance or declaration in the source file document. Filter Checks displays the Filter Design Checks dialog for filtering the display of types of design checks. Edit Directive see set_black_box on page 262 and set_cdc_synchronizer on page 302. Show in Schematic view the selected design unit in a schematics window. Select in Schematic select the design unit in the current displayed schematics window.
441
Search by Column search for text pattern in design workspace. Copy to Clipboard save the design unit name or details to the clipboard. Show Details display a details window. Find Displays the find panel.
Modules Window
The modules window (Figure 7-20) shows the DUT design units with their assertion densities. Figure 7-20. Modules Window
Right-click on an entry to pop up a menu that you can use to: Go to declaration or instantiation in the source file. Edit Directive see set_black_box on page 262 and set_cdc_synchronizer on page 302.. Show in Schematic view the selected instance in a schematics window. Select in Schematic select the instance in the current displayed schematics window. Copy to Clipboard save the design unit name or details to the clipboard. Find Displays the find panel.
442
Clocks Window
The clocks window (Figure 7-21) shows the DUT clock signals. Figure 7-21. Clocks Window
Right-click on a clock to pop up a menu that you can use to: Go to clock declaration in the source code or the design unit with the clock in the hierarchy. Edit Directive see set_cdc_clock on page 263 and set_constant on page 305.. Show in Schematic shows the clock drivers, clock readers or both in a schematics view. Select in Schematic zooms in and selects the clock signal in the active schematic view. Add to Path Tracing adds the clock to the path tracing points.\ Copy to Clipboard copies the clock path (name) or name and clock group (details) to the clipboard. Show Details shows the details window with clock name and clock group name. Find Displays the find panel.
443
Directives Window
The directives tab (Figure 7-22) shows the current global directives. Use this tab to add and edit global directives. Figure 7-22. Directives Window
Right-click on an entry to pop up a menu that you can use to: Add view a dialog customized for the selected type of directive. After completing the form, the directive is added to the directives tab. The directive types are: Clock (set_cdc_clock on page 263), Reset (set_reset on page 312), Port Domain (set_cdc_port_domain on page 276), Signal (set_cdc_signal on page 299), Report (set_cdc_report on page 293), Synchronizer (set_cdc_synchronizer on page 302), Constant (set_constant on page 305), Reconvergence (set_cdc_reconvergence on page 291), Preference (set_cdc_preference on page 283), Blackbox (set_black_box on page 262), Memory (set_memory on page 308), FX Metastability (set_cdc_fx_metastability_window on page 269), FX Check (set_cdc_fx_check on page 268) and FX Timescale (set_cdc_fx_timescale on page 270). Edit view a dialog for changing the selected directive. Move move the selected directives up or back in compile order. Delete remove the selected directives. Import load a set of directives from a text file. Export save selected directives to a text (control) file.
444
Chapter 8 Reports/Logs Reference

The CDC compiler automatically generates the following files: 0in.log Short log file that is a copy of the standard output. 0in_cdc.db CDC database for examining in the CDC GUI environment. 0in_cdc.rpt Clock domain crossing report. 0in_cdc_setting.rpt CDC settings report. 0in_cdc_ctrl.v Clock domain crossing checker control file, which contains suggested CDC protocol checker directives for signals crossing clock domains (for use with simulation and the formal tools). 0in_cdc_design.rpt CDC design report. 0in_cdc_mode_ctrl.v Control file with directives specifying the modes inferred by modal analysis (generated if the cdc -report_modes option is specified). 0in_cdc_param.inc Checker parameter file. 0in_detail.log Detailed log of the transcript.
445
Reports/Logs Reference CDC Design Report
CDC Design Report

The clock domain crossing design report file (0in_cdc_design.rpt) shows detailed information about the clocks and clock groups in the design. It also shows summary information about design elements. The report contains the following: Clock Group Summary (see page 446) User-Specified Clock Groups (see page 447) Inferred Clock Groups (see page 447) Ignored Clock Groups (see page 449) General Design Information (see page 449) Detailed Design Information (see page 449) Port Domain Information (see page 450) Mode Information (see page 451)
Clock Group Summary

The automatically generated 0in_cdc_design.rpt file contains the clock group summary that displays the total counts for each type of clock group as shown in Example 8-1. There are two types of clock groups: user-specified and inferred. All user-specified clocks are defined by the user with the set_cdc_clock global directive. Inferred clock groups are clocks that are not specified, but inferred by the CDC tool. Example 8-1. Clock Group Summary
Clock Group Summary for top ============================= Total Number of Clock Groups : 5 Number of User-Defined Clock Groups : 0 Number of Inferred Clock Groups : 5 Number of Ignored Clock Groups : 1
446
User-Specified Clock Groups

The automatically generated 0in_cdc_design.rpt file contains the user-specified clock groups created using set_cdc_clock global directive (page 263) as shown in Example 8-2. Example 8-2. User-Specified Clock Groups
User-Specified Clock Groups =========================== Group 0(35 Register Bits) ----------cpu_clk Group 1(119 Register Bits) ----------core_clk fifo_1_d.wr_clk fifo_1_d.u0.Wclk fifo_0_h.wr_clk fifo_0_h.u0.Wclk Group 2(148 Register Bits) ----------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

Inferred clock groups (including gated clocks) are reported as clock domains in the clock tree. The automatically generated 0in_cdc_design.rpt file contains the clocks that comprise the clock groups inferred by the compiler as shown in Example 8-3. Example 8-3. Inferred Clock Groups
Inferred Clock Groups ===================== Group 0(25 Register Bits) ----------CLK3 Group 1(38 Register Bits) ----------CLK1 sy1.I_CLK ntX_rg.clk edX_rg.clk
447
Reports/Logs Reference CDC Design Report tgX_rg.clk O1r_0_rg.clk O2r_0_rg.clk O2r_1_rg.clk O2r_2_rg.clk O2r_3_rg.clk Group 2(12 Register Bits) ----------CLK2 sy2.I_CLK sy3.I_CLK sy4.I_CLK sy5.I_CLK detrxst_0_rg.clk Group 3(358 Register Bits) ----------CLKX [gate: ((TCS === 1b0) ? CLK0 : ((TCS === 1b1) ? TRK : 1bx))] O2w_0_rg.clk O2w_1_rg.cl O2w_2_rg.clk O2w_3_rg.clk sy6.I_CLK sy7.I_CL sy8.I_CLK sy9.I_CLK sya.I_CLK modr.I_CLK modr.modr1_0.I_CLK modr.modr1_0.syb.I_CLK modr.modr1_0.syc.I_CLK . . . modr.modr1_3.ft_rg.clk modr.modr1_3.f_r_rg.clk Group 4(5 Register Bits) ----------modr.rz0_tree [gate: (TCS ? TRK : ((I5[1:0] == 2'b0) ? RCLK[0] :RCLK[1]))] modr.wz_rg.clk modr.t_l0_rg.clk
448
Ignored Clock Groups

Ignored clock groups are identified by the set_cdc_clock -ignore global directive and are listed in the 0in_cdc_design.rpt file (Example 8-4). Example 8-4. Ignored Clock Groups
Ignored Clock Groups ==================== Group 0(158 Register Bits) ----------mac_clk [gate: (scan_mode ? scan_clk : mac_clk_in)] fifo_1_d.rd_clk fifo_1_d.u0.Rclk fifo_0_h.rd_clk fifo_0_h.u0.Rclk crc_1.clk
General Design Information

The automatically generated 0in_cdc_design.rpt file contains the general design information that displays the total counts for each basic design element as shown in Example 8-5. Example 8-5. General Design Information
General Design Information ========================== Number of blackboxes = 0 Number of Registers = 438 Number of Latches = 0 Number of RAMs = 0
Detailed Design Information

The automatically generated 0in_cdc_design.rpt file contains the detailed design information that lists the basic design elements (except the registers) as shown in Example 8-6. Example 8-6. Detailed Design Information
Detail Design Information ========================= RAMs: ----fifo_1_d.u0.data fifo_0_h.u0.data
449
Port Domain Information

The automatically generated 0in_cdc_design.rpt file contains the port domain information that displays the clock domains identified for the designs ports as shown in Example 8-7. Example 8-7. Port Domain Information
Printing port domain info ========================= Port Direction Constraints Clock Domain Type --------------------------------------------------------------------RST input Reset { CLK3 CLK1 } 0-In CDC CLK3 input Clock { CLK3 } 0-In CDC CLK0 input --CLK1 input Clock { CLK1 } 0-In CDC CLK2 input Clock --RCLK input --I1 input --I2 input --I3 input --I4_0_I input --I4_1_I input --I4_2_I input --I4_3_I input --IT input { CLK3 } 0-In CDC I5 input { CLK2 CLK3 } 0-In CDC TM input --TRK input --TCS input --O1 output { CLK1 } 0-In CDC O2_0 output { CLK1 } 0-In CDC O2_1 output { CLK1 } 0-In CDC O2_2 output { CLK1 } 0-In CDC O2_3 output { CLK1 } 0-In CDC
The following defines the port domain information: Port Port name. Direction The valid directions are: input, output, and inout Constraint Identifies clock and reset ports. Clock Domain Clock domain of the port. The {clock} indicates the primary clock for the domain, and {clock1 | clock2 |...} indicates the clock domain is ambiguous. The relevant primary clocks are listed. An async indicates the port is marked as an asynchronous port using the set_cdc_port_domain global directive (page 276). Type Method used to determine the clock domain. User indicates the clock domain is assigned by the set_cdc_clock global directive (page 263) or the port is marked asynchronous (using set_cdc_port_domain global directive (see page 276)). 0in_cdc indicates CDC analysis identified the domain (or potential domains).
450
Mode Information
The automatically generated 0in_cdc_design.rpt file contains the mode information as shown in Example 8-8. Note that the mode information is generated only when the cdc -report_modes option is specified. Example 8-8. Mode Information
Mode information ================ --------------------------------------------Mode Type Information --------------------------------------------cdc_mode_0 0-In CDC Missing mode cdc_mode_1 0-In CDC Missing mode cdc_mode_2 0-In CDC Missing mode --------------------------------------------User Modes ========== None Inferred Modes ============== Constants in cdc_mode_0 (Missing) ----------------------------------------Signal Value ----------------------------------------TCS 1'b1 ----------------------------------------Constants in cdc_mode_1 (Missing) ----------------------------------------Signal Value ----------------------------------------TCS 1'b0 I5[1:0] 2'b00 ----------------------------------------Constants in cdc_mode_2 (Missing) ----------------------------------------Signal Value ----------------------------------------TCS 1'b0 I5[1:0] 2'b01 -----------------------------------------
451
Reports/Logs Reference Clock Domain Crossing Report
Clock Domain Crossing Report

The automatically generated clock domain crossing report file (0in_cdc.rpt) shows detailed information about the CDC signals and their schemes. The report contains the following: CDC Summary (see page 452) CDC Promotion Summary (see page 453) Violations (see page 453) Cautions (see page 454) Evaluations (see page 455) Waived (see page 456) Proven (see page 456) Filtered (see page 457) Custom Synchronization Modules (see page 458) Asynchronous Reset Detection (see page 458) Asynchronous Reset Synchronizers Detected (see page 458) User-entered Asynchronous Reset (see page 459) Asynchronous Reset with Missing Synchronizer (see page 459) All Transmitting Signals (see page 461)
CDC Summary
The automatically generated 0in_cdc.rpt file contains the CDC summary that shows the counts for each type of violation, caution, and evaluation as shown in Example 8-9. Example 8-9. CDC Summary
CDC Summary ================================================================= Violations (7) ----------------------------------------------------------------Single-bit signal does not have proper synchronizer. (3) Combinational logic before synchronizer. (1) Reconvergence of synchronizers. (1) Single Source Reconvergence of synchronizers. (2) Cautions (6) ----------------------------------------------------------------DMUX synchronization. (2) Multiple-bit signal across clock domain boundary. (1) FIFO synchronization. (2)
452
Reports/Logs Reference Clock Domain Crossing Report Handshake synchronization. (1)
Evaluations (1) ----------------------------------------------------------------Single-bit signal synchronized by DFF synchronizer. (1) Waived (6) ----------------------------------------------------------------Multiple-bit signal synchronized by DFF synchronizer. (4) Reconvergence of synchronizers. (2) Proven (8) ----------------------------------------------------------------Single-bit signal synchronized by DFF synchronizer. (6) Reconvergence of synchronizers. (1) Pulse Synchronization. (1) Filtered (1) ----------------------------------------------------------------Combinational logic before synchronizer. (1)
CDC Promotion Summary

The automatically generated 0in_cdc.rpt file contains the CDC promotion summary that shows the checkers that are promoted and the checkers that are not promoted as shown in Example 8-10. Example 8-10. CDC Promotion Summary
CDC Promotion Summary ========================================================== Promoted protocol checkers (18) Unpromoted checkers (see 0in_detail.log) (6) ==========================================================
Violations
The automatically generated 0in_cdc.rpt file contains the CDC violations that shows the paths that result in the CDC violations as shown in Example 8-11. Example 8-11. Violations
Violations ======================================================================== Single-bit signal does not have proper synchronizer. (no_sync) -----------------------------------------------------------------------cpu_clk_in : start : init_done (/demo_top.v : 82) core_clk_in : end : tx_state[0] (/demo_top.v : 193) (ID:no_sync_47305) core_clk_in : end : tx_en (/demo_top.v : 86) (ID:no_sync_2628) core_clk_in : end : tx_mask_valid (/demo_top.v : 90) (ID:no_sync_31547) Combinational logic before synchronizer. (combo_logic) -------------------------------------------------------------------------
453
Reports/Logs Reference Clock Domain Crossing Report cpu_clk_in : start : pass_en[1] (/demo_top.v : 79) mac_clk_in : end : check_en_r1 (/demo_top.v : 324) (ID:combo_logic_46571) cpu_clk_in : start : err_thrs (/demo_top.v : 78) mac_clk_in : end : check_en_r1 (/demo_top.v : 324) (ID:combo_logic_85239) Reconvergence of synchronizers. (reconvergence) ------------------------------------------------------------------------mac_clk_in : end : rx_payload_en (/demo_top.v : 381) (ID:reconvergence_68819) mac_clk_in : start : tx_sop_r2 (/demo_top.v : 360) mac_clk_in : start : tx_eop_r2 (demo_top.v : 371) mac_clk_in : end : rx_masked_data (/demo_top.v : 382) (ID:reconvergence_51498) mac_clk_in : start : tx_eop_r2 (/demo_top.v : 371) mac_clk_in : start : tx_mask_valid_r2 (/demo_top.v : 303) mac_clk_in : end : pass_valid (/demo_top.v : 47) (ID:reconvergence_31994) mac_clk_in : start : fifo_1_d.wp_s (/generic_fifo_dc_gray.v : 149) mac_clk_in : start : fifo_0_h.wp_s (/generic_fifo_dc_gray.v : 149) mac_clk_in : end : pass (/demo_top.v : 45) (ID:reconvergence_11498) mac_clk_in : start : fifo_1_d.wp_s (/generic_fifo_dc_gray.v : 149) mac_clk_in : start : fifo_0_h.wp_s (/generic_fifo_dc_gray.v : 149)
Cautions
The automatically generated 0in_cdc.rpt file contains the CDC cautions that displays the paths that result in the CDC cautions as shown in Example 8-12. Example 8-12. Cautions
Cautions ======================================================================= DMUX synchronization. (dmux) ----------------------------------------------------------------------cpu_clk_in : start : fstp[7:1] (/demo_top.v : 81) mac_clk_in : end : crc_1.scramble (/demo_top.v : 435) (ID:dmux_30303) via : crc_1.fstp core_clk_in : start : tx_mask_d (/demo_top.v : 198) mac_clk_in : end : mask (/demo_top.v : 336) (ID:dmux_12402)
Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------------core_clk_in : start : fifo_1_d.wp_gray (/generic_fifo_dc_gray.v : 147) mac_clk_in : end : fifo_1_d.wp_s1 (/generic_fifo_dc_gray.v : 150) (ID:bus_two_dff_80275) mac_clk_in : start : fifo_1_d.rp_gray (/generic_fifo_dc_gray.v : 148) core_clk_in : end : fifo_1_d.rp_s1 (/generic_fifo_dc_gray.v : 150) (ID:bus_two_dff_94611)
454
core_clk_in : start : fifo_0_h.wp_gray (/generic_fifo_dc_gray.v : 147) mac_clk_in : end : fifo_0_h.wp_s1 (/generic_fifo_dc_gray.v : 150) (ID:bus_two_dff_53361) mac_clk_in : start : fifo_0_h.rp_gray (/generic_fifo_dc_gray.v : 148) core_clk_in : end : fifo_0_h.rp_s1 (generic_fifo_dc_gray.v : 150) (ID:bus_two_dff_62001)
Multiple-bit signal across clock domain boundary. (multi_bits) ---------------------------------------------------------------------cpu_clk_in : start : crc_seed[7:1] (/demo_top.v : 80) mac_clk_in : end : crc_1.crc_16 (/demo_top.v : 434) (ID:multi_bits_76265) via : crc_1.seed
Evaluations
The automatically generated 0in_cdc.rpt file contains the CDC evaluations that displays the paths that result in the CDC evaluations as shown in Example 8-13. Example 8-13. Evaluations
Evaluations ======================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------------cpu_clk_in : start : init_done (/demo_top.v : 82) mac_clk_in : end : init_done_r1 (/demo_top.v : 119) (ID:two_dff_5840) cpu_clk_in : start : pass_en[0] (/demo_top.v : 79) mac_clk_in : end : pass_en0_r1 (/demo_top.v : 314) (ID:two_dff_81824) core_clk_in : start : tx_sop (/demo_top.v : 88) mac_clk_in : end : tx_sop_r1 (/demo_top.v : 360) (ID:two_dff_11314) core_clk_in : start : tx_eop (/demo_top.v : 87) mac_clk_in : end : tx_eop_r1 (/demo_top.v : 371) (ID:two_dff_54238) core_clk_in : start : tx_mask_valid (/demo_top.v : 90) mac_clk_in : end : tx_mask_valid_r1 (/demo_top.v : 303) (ID:two_dff_52495) Pulse Synchronization. (pulse_sync) ----------------------------------------------------------------------core_clk_in : start : tx_en (/demo_top.v : 86) mac_clk_in : end : tx_en_r1 (/demo_top.v : 289) (ID:pulse_sync_13276) Memory Synchronization. (memory_sync) ----------------------------------------------------------------------core_clk_in : start : fifo_1_d.u0.data (/dpmem2clk.v : 58) mac_clk_in : end : fifo_1_d.u0.outport (/dpmem2clk.v : 60) (ID:memory_sync_1560)
455
Reports/Logs Reference Clock Domain Crossing Report core_clk_in : start : fifo_0_h.u0.data (/dpmem2clk.v : 58) mac_clk_in : end : fifo_0_h.u0.outport (/dpmem2clk.v : 60) (ID:memory_sync_17786)
Waived
The 0in_cdc.rpt file contains the schemes assigned with waived severity using the set_cdc_report -waived directive as shown in Example 8-13. Example 8-14. Waived
Waived ================================================================= Multiple-bit signal synchronized by DFF synchronizer. (bus_two_dff) ----------------------------------------------------------------mac_clk : start : fifo_0_h.rp_gray (.../generic_fifo_dc_gray.v : 147) core_clk : end : fifo_0_h.rp_s1 (.../generic_fifo_dc_gray.v : 149) (ID:bus_two_dff_62001) core_clk : start : fifo_0_h.wp_gray (.../generic_fifo_dc_gray.v : 146) mac_clk : end : fifo_0_h.wp_s1 (.../generic_fifo_dc_gray.v : 149) (ID:bus_two_dff_53361) mac_clk : start : fifo_1_d.rp_gray (.../generic_fifo_dc_gray.v : 147) core_clk : end : fifo_1_d.rp_s1 (.../generic_fifo_dc_gray.v : 149) (ID:bus_two_dff_94611) core_clk : start : fifo_1_d.wp_gray (.../generic_fifo_dc_gray.v : 146) mac_clk : end : fifo_1_d.wp_s1 (.../generic_fifo_dc_gray.v : 149) (ID:bus_two_dff_80275)
Reconvergence of synchronizers. (reconvergence) ----------------------------------------------------------------<clock N/A> : end : pass (.../demo_top.v : 49) (ID:reconvergence_11498) mac_clk : start : fifo_0_h.wp_s (.../generic_fifo_dc_gray.v : 148) (Synchronizer ID:bus_two_dff_53361) mac_clk : start : fifo_1_d.wp_s (.../generic_fifo_dc_gray.v : 148) (Synchronizer ID:bus_two_dff_80275) mac_clk : end : pass_valid (.../demo_top.v : 51) (ID:reconvergence_31994) mac_clk : start : fifo_0_h.wp_s (.../generic_fifo_dc_gray.v : 148) (Synchronizer ID:bus_two_dff_53361) mac_clk : start : fifo_1_d.wp_s (.../generic_fifo_dc_gray.v : 148) (Synchronizer ID:bus_two_dff_80275)
Proven
The 0in_cdc.rpt file contains the paths with CDC transfer protocols that cannot be violated as shown in Example 8-13.
456
Example 8-15. Proven

Proven ================================================================= Single-bit signal synchronized by DFF synchronizer. (two_dff) ----------------------------------------------------------------core_clk : start : hdren_tx (.../demo_top.v : 76) mac_clk : end : hdren_rx1 (.../demo_top.v : 77) (ID:two_dff_33161) cpu_clk : start : init_done (.../demo_top.v : 94) mac_clk : end : init_done_r1 (.../demo_top.v : 131) (ID:two_dff_5840) cpu_clk : start : pass_en[0] (.../demo_top.v : 91) mac_clk : end : pass_en0_r1 (.../demo_top.v : 371) (ID:two_dff_81824) core_clk : start : tx_eop (.../demo_top.v : 99) mac_clk : end : tx_eop_r1 (.../demo_top.v : 428) (ID:two_dff_54238) core_clk : start : tx_mask_valid (.../demo_top.v : 102) mac_clk : end : tx_mask_valid_r1 (.../demo_top.v : 360) (ID:two_dff_52495) core_clk : start : tx_sop (.../demo_top.v : 100) mac_clk : end : tx_sop_r1 (.../demo_top.v : 417) (ID:two_dff_11314)
Reconvergence of synchronizers. (reconvergence) ----------------------------------------------------------------mac_clk : end : rx_payload_en (.../demo_top.v : 438) (ID:reconvergence_68819) mac_clk : start : tx_eop_r2 (.../demo_top.v : 428) (Synchronizer ID:two_dff_54238) mac_clk : start : tx_sop_r2 (.../demo_top.v : 417) (Synchronizer ID:two_dff_11314)
Pulse Synchronization. (pulse_sync) ----------------------------------------------------------------core_clk : start : tx_en (.../demo_top.v : 98) mac_clk : end : tx_en_r1 (.../demo_top.v : 346) (ID:pulse_sync_13276)
Filtered
The -filtered_report option of the set_cdc_preference directive directs CDC analysis to include details of filtered schemes in the 0in_cdc.rpt report as shown in Example 8-13. Use the set_cdc_report -severity off directive to filter CDC schemes. Example 8-16. Filtered
Filtered ================================================================= Combinational logic before synchronizer. (combo_logic) ----------------------------------------------------------------cpu_clk : start : err_thrs (.../demo_top.v : 90)
457
Reports/Logs Reference Clock Domain Crossing Report mac_clk : end : check_en_r1 (.../demo_top.v : 381) (ID:combo_logic_85239)
Custom Synchronization Modules

The automatically generated 0in_cdc.rpt file contains the custom synchronization modules that lists the modules designated as custom synchronizers (see set_cdc_synchronizer on page 302) as shown in Example 8-17. If detailed custom synchronization reporting is turned on (with the -print_detailed_custom_sync option to the set_cdc_preference directive), cdc checks for custom synchronizers on signals that do not cross clock domain boundaries. Either the wrong clock is connected to the synchronizer or the synchronizer is not needed. The detailed custom synchronization reporting adds this information in a Custom synchronizers which have internal crossings section. Example 8-17. Custom Synchronization Modules
Custom Synchronization Modules ============================== sync dff4 Custom synchronizers which have internal crossings: =================================================== Module : cust_sync Instance : u1
Asynchronous Reset Detection

The automatically generated 0in_cdc.rpt file contains the asynchronous reset detection that contains details about CDC signals used as asynchronous resets as shown in Example 8-18. Example 8-18. Asynchronous Reset Detection
Asynchronous Reset Detection ( dut ) ====================================
Asynchronous Reset Synchronizers Detected

The automatically generated 0in_cdc.rpt file contains the asynchronous reset synchronizers that are detected as shown in Example 8-19. Example 8-19. Asynchronous Reset Synchronizers Detected
Asynchronous Reset Synchronizers Detected ========================================= rst1 ( clk1 )
458
User-entered Asynchronous Reset

The automatically generated 0in_cdc.rpt file contains the user-entered asynchronous reset as shown in Example 8-20. Example 8-20. User-entered Asynchronous Reset
User-entered Asynchronous Reset =============================== None
Asynchronous Reset with Missing Synchronizer

The automatically generated 0in_cdc.rpt file contains the asynchronous reset with missing synchronizer identifies the CDC reset signals that are not synchronized properly and indicates the cause of the potential problem as shown in Example 8-21. Example 8-21. Asynchronous Reset with Missing Synchronizer
Asynchronous Reset with Missing Synchronizer ================================================================== bad2.R2 (wrong reset_polarity : posedge U0.f2) bad2.R3 (wrong clock : clk2) bad4.R2 (wrong reset_polarity : posedge U0.f2) bad4.R3 (wrong clock : clk2) good2.R1 (wrong reset_polarity : posedge U0.f2) good2.R3 (wrong clock : clk2, wrong reset_polarity : posedge U0.f2) good3.R1 (wrong reset_polarity : posedge U0.f2) good3.R3 (wrong clock : clk2, wrong reset_polarity : posedge U0.f2) good4.R1 (wrong reset_polarity : posedge U0.f2) good4.R3 (wrong clock : clk2, wrong reset_polarity : posedge U0.f2) bad3.R2 (wrong reset_polarity : posedge U0.f2) bad3.R3 (wrong clock : clk2) bad1.R2 (wrong reset_polarity : posedge U0.f2) bad1.R3 (wrong clock : clk2) good1.R1 (wrong reset_polarity : posedge U0.f2) good1.R3 (wrong clock : clk2, wrong reset_polarity : posedge U0.f2)
Asynchronous reset signals that are not synchronized properly either have no synchronizer or are not properly synchronized as follows: no synchronizer Asynchronous reset detection reports no synchronizer if a reset signal is used to reset flip-flops in a multiple clock design without using a synchronizer. In the following subcircuit, rst_a is used directly (without a synchronizer):
459
rst_a 1'b1
rst_a is used directly
rst_a 1'b1
clk_a
clk_a
Incorrect Usage
Correct Usage
wrong clock Asynchronous reset detection reports wrong clock if an asynchronous reset signal is used to reset logic in another clock domain. In the following subcircuit, the reset_a signal is used incorrectly to reset logic in a clock domain other than the domain of clk_a.
rst_a 1'b1
reset_a
rst_a 1'b1 wrong clock
reset_a
clk_a
clk_b
clk_a
clk_a
Incorrect Usage
Correct Usage
wrong reset polarity Asynchronous reset detection reports a wrong reset polarity violation if an active high asynchronous reset is used as an active low reset, or if an active low asynchronous reset is used as an active high reset (that is, the reset has the wrong polarity). In the following subcircuit, the active high reset_a signal is used as an active low reset.
rst_a 1'b1
reset_a wrong polarity
rst_a 1'b1
reset_a
clk_a
clk_a
Incorrect Usage
Correct Usage
460
All Transmitting Signals

The automatically generated 0in_cdc.rpt file contains the transmitting signals that lists the sources of signals that cross clock domains as shown in Example 8-22. Example 8-22. All Transmitting Signals
All Transmitting Signals (17) ======================================================== Name Width Location -------------------------------------------------------init_done 1 /demo_top.v:82 pass_en[0] 1 /demo_top.v:79 tx_sop 1 /demo_top.v:88 tx_eop 1 /demo_top.v:87 tx_mask_valid 1 /demo_top.v:90 tx_en 1 /demo_top.v:86 fstp[7:1] 7 /demo_top.v:81 tx_mask_d 8 /demo_top.v:198 crc_seed[7:1] 7 /demo_top.v:80 fifo_1_d.wp_gray 5 /generic_fifo_dc_gray.v:147 fifo_1_d.rp_gray 5 /generic_fifo_dc_gray.v:148 fifo_0_h.wp_gray 5 /generic_fifo_dc_gray.v:147 fifo_0_h.rp_gray 5 /generic_fifo_dc_gray.v:148 fifo_1_d.u0.data 16 /dpmem2clk.v:58 fifo_0_h.u0.data 16 /dpmem2clk.v:58 pass_en[1] 1 /demo_top.v:79 err_thrs 8 /demo_top.v:78 o o o
Name Signal name. Width Number of bits. Location Source code location.
461
Reports/Logs Reference CDC Settings Report
CDC Settings Report

The settings report (0in_cdc_setting.rpt) shows the global CDC settings and the results of processing global CDC directives. Section A: Global Directives (page 462) Section B: Unmatched Global Directives (page 462) Section C: Wildcard Expansion for Global Directives (page 463) Section D: Global CDC Preferences (page 463) Section E: Default CDC Scheme Settings (page 465)
Section A: Global Directives

Information about the CDC directives that can be processed (Example 8-23). Example 8-23. Global Directives
***************************************************************** Section A: Global Directives ***************************************************************** set_cdc_fifo_preference directive ----------------------------------------------------------------//0in set_cdc_fifo_preference -no_write_sync -no_read_sync set_cdc_signal directive ----------------------------------------------------------------//0in set_cdc_signal vhdl_inst.*c_enum -stable set_cdc_synchronizer directive ----------------------------------------------------------------//0in set_cdc_synchronizer custom -module BB . . .
Section B: Unmatched Global Directive

Directives (Example 8-24) that cannot be processed because: Signal or module information cannot be resolved. Module containing referred signals is black boxed
462
Example 8-24. Unmatched Global Directives

***************************************************************** Section B: Unmatched Global Directives ***************************************************************** 1. Unrecognized signal/module 2. Module inside blackbox ----------------------------------------------------------------Directive Module ----------------------------------------------------------------set_cdc_port_domain LATCH -----------------------------------------------------------------
Section C: Wildcard Expansion for Global Directives

Signals expanded from wildcard patterns in global directives (Example 8-25). Example 8-25. Wildcard Expansion for Global Directives
***************************************************************** Section C: Wildcard Expansion for Global Directives ***************************************************************** Wildcards for set_cdc_port_domain directive ----------------------------------------------------------------File mixed1_ctrl.v : Line 2 *in* matches vhdl_inst.in1 vhdl_in v2k_in Wildcards for set_cdc_signal directive ----------------------------------------------------------------File mixed1_ctrl.v : Line 6 vhdl_inst.*c_enum matches vhdl_inst.rec_enum
Section D: Global CDC Preferences

CDC preferences. (Example 8-26). Example 8-26. Global CDC Preferences
***************************************************************** Section D: Global CDC Preference ***************************************************************** Option Value ----------------------------------------------------------------multi_clock_convergence FALSE clock_in_data FALSE allow_enable_in_sync FALSE
463
Reports/Logs Reference CDC Settings Report max_cdc_crossings custom_fx promote_reconvergence mult_fanout_async dmux_promote_sample fx_use_local_clk input_async ignore_black_box handshake_scheme fifo_scheme delayed_pulse report_resets detect_primary_output_clock formal_add_bus_stability formal_add_recon_stability filtered_report vectorize_nl unrestricted_reconvergence no_clock_as_rx multi_paths multi_through report_undriven_custom_sync print_port_domain_template dmux_as_recon_start print_detailed_custom_sync report_bbox_recon blackbox_empty_module sample_data_stability infer_clock_off detect_pure_latch_clock promote_async_reset complex_scheme_as_synchronizer 0 FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
464
Section E: Default CDC Scheme Settings

Default severities and promotions for CDC schemes (Example 8-27). Example 8-27. Default CDC Scheme Settings
****************************************************************************** Section E: Default CDC Scheme Settings ****************************************************************************** CDC Scheme Severity Enabled Promotion Promotion Status -----------------------------------------------------------------------------async_reset evaluation yes none off blackbox evaluation yes none off custom_sync evaluation yes none off dff_sync_gated_clk evaluation yes cdc_sync on four_latch evaluation yes cdc_sync on custom_sync_with_crossing evaluation yes none off memory_sync evaluation yes none off pulse_sync evaluation yes cdc_sync on shift_reg evaluation yes cdc_sync on two_dff evaluation yes cdc_sync on bus_dff_sync_gated_clk caution yes cdc_hamming_distance_one off dmux caution yes cdc_dsel on fifo caution no none off handshake caution no none off multi_bits caution yes cdc_sample on series_redundant caution yes none off simple_dmux caution yes cdc_dsel on two_dff_phase caution yes cdc_sync on async_reset_no_sync violation yes none off bus_two_dff_phase violation yes cdc_hamming_distance_one off bus_four_latch violation yes cdc_hamming_distance_one off bus_two_dff violation yes cdc_hamming_distance_one off combo_logic violation yes cdc_glitch on no_sync violation yes cdc_sample on bus_shift_reg violation yes cdc_hamming_distance_one off multi_sync_mux_select violation yes cdc_sample on fanin_different_clks violation yes cdc_glitch on reconvergence violation yes depth:0 none off redundant violation yes none off single_source_reconvergence violation yes none off
465
466
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
Symbols
+0in_licq, 347 +define+, 336 +error, 363 +incdir+, 336 +libext, 336 +nowarn, 363 +skip_syscall, 69 stable, 388 txdata, 378 txdone, 394 txdsel, 378 txval, 394 wptr, 383 async_reset scheme, 181 async_reset_no_sync scheme, 184 asynchronous clocks, 25 inputs, 25 no synchronizer, 459 reset detection, 458 reset signals, 459 reset synchronizers, 458 reset with missing synchronizer, 459 user-entered reset, 459 wrong clock, 460 wrong reset polarity, 460 -auto_blackbox, 364
Numerics
0-In comments, 254 definition, 254 single-line, 254 0in.log, 368 0in_checkcsl.db, 368 0in_db2ucdb, 353 0in_detail.log, 368 1-Step compilation, 56 2-Step compilation, 57
A
abstract memory model, 308 ad hoc synchronizer, 31 -allow_enable_in_sync, 283 Altera, 63 assertion defined, 47 assertion-based verification, 47 -assume, 402 Assumption groups data, 394 deq, 383 dist, 388 enq, 383 max, 394 min, 394 ptr, 383 rptr, 383 rxdata, 378 rxdone, 394 rxval, 394
B
Black box, 69 blackbox scheme, 186 -blackbox_empty_module, 285, 286 Block constraints generation mode, 119 Block specifications, 120 Bookmarks, 432 bus_dff_sync_gated_clk scheme, 191 bus_four_latch scheme, 193 bus_shift_reg scheme, 195 bus_two_dff scheme, 197 bus_two_dff_phase scheme, 199
C
cache, 361 Case directive, non-native, 324 CDC cautions report, 454 evaluation report, 455, 456
467
filtered crossings, 362 promotion, 104 promotion summary report, 453 scheme types, 39 scheme, turn off reporting, 40 schemes, 39, 179 schemes with potential errors, 44 summary report, 452 violation report, 453 CDC checks window, 419 cdc command, 359 CDC port constraint, 273 cdc_dsel, 377 cdc_fifo, 381 cdc_glitch, 385 cdc_hamming_distance_one, 387 -cdc_handshake, 391 cdc_handshake_data, 390 cdc_sample, 398 cdc_sync, 401, 404, 408 CDC-FX cdc_fx checker, 175 metastability injected simulation, 29 Checker promotion, 48 checker cdc_fx, 159 promotion, 40 protocol, 47 simulate a design, 50 Checker summary, 287 Checker types cdc_dsel, 377 cdc_fifo, 381 cdc_glitch, 385 cdc_hamming_distance_one, 387 cdc_handshake_data, 390 cdc_sample, 398 cdc_sync, 401, 404, 408 CheckerWare assertion library, 48 clock asynchronous, 25 domain crossing, 26 domains, 25 group, 25 group inferred by compiler, 447 group summary, 446 jitter, 28 user-specified clock group, 447 clock domain crossing report file, 452 -clock_as_rx, 286 -clock_group_pair, 273 -clock_in_data, 283 Clocks, 25 Clocks window, 443 cmd, 348 combo_logic scheme, 201 Configure columns buttons, 413 Consistency checks, 123 Control file models, 131 control signal synchronizers, 31 Corner cases all one, 399 all one to zero, 399 all zero, 399 all zero to one, 399 asserted for tx_min cycles, 379 FIFO is empty, 383 FIFO is full, 383 turnaround cycles completed at turnaround_max, 395 turnaround cycles completed at turnaround_min, 395 value changed at tx_min, 388, 402 counterexample, 49 Coverage count, 356 csl, 373 csl input files, 368 cuname, 361 Current layout, 417 -custom_fx, 284 custom_sync scheme, 189, 203, 205
D
data synchronization, 42, 43 Data sheets, checkers, 375 -data_stable, 391 de, 363 Defaults file, 58
468
-delayed_pulse, 284 -depth, 381 Depth of divergence, 37 Depth of reconvergence, 37 -deq, 381 -dequeue, 382, 401 design detailed information, 449 general information, 449 Design window, 441 detail, 347 Details window, 422 -detect_primary_output_clock, 284 dff_sync_gated_clk scheme, 207 Directive order, 259 Directives non-native case, 324 Directives window, 444 Divergence depth, 37 Dividers, 436 dmux scheme, 208, 244 -dmux_as_recon_start, 285 -dmux_promote_sample, 284 Dock button, 416 Drag-and-drop, 412 -filtered_report, 285 Filtering CDC results, 100 Find panel, 440 formal constraint, 49 target, 49 tools, 49 verification, 49 Formal block restrictions, 69 Formal CDC, 46 Formal CDC effort level, 46 -formal_add_bus_stability, 285 -formal_add_recon_stability, 285 four_latch scheme, 218 FPGA resource libraries, 63 Functions, 73
G
G, 363 g, 364 -glitch, 385 Global CDC preferences, 119 global directives create_wire, 315 disable_checker, 318 set_cdc_port_domain, 279 set_cdc_preference, 287 set_cdc_reconvergence, 292 set_cdc_report, 296 set_cdc_signal, 300 set_cdc_synchronizer, 303 set_checker_action, 322 set_constant_propagation, 306 set_memory, 308 set_mode, 310 set_mode_control, 311 wildcarded signals, 362 Global reconvergence, 35 Gray-coding protocol, 47
E
Empty modules, 285 -enq, 381 -enqueue, 382, 402 Errors/Warnings window, 418 Evals, 375 Evaluation statistic, 375 exact memory model, 308 Expansion, 257
F
Failure count, 356 fanin_different_clks scheme, 210 -fifo_scheme, 284 files 0in_cdc_design.rpt, 446 automatically generated, 445 design report, 446 filtered CDC crossings, 362
H
-hamming_one, 387 -handshake_scheme, 284 Hierarchical constraints control file, 119 hierarchical verification use model, 118
469
-hold, 399 Homogeneous instances of a block, 129 Hover help, 412 Move-window, 415 MTBF, 26 -mult_fanout_async, 284 multi_bits scheme, 225 -multi_clock_convergence, 283 multi_sync_mux_select scheme, 227 Multibit reconvergence, 35 Multicycle reconvergence, 36 Multiple always blocks, 73 Multiple directives, 254
I
-ignore_black_box, 285 Inconclusive, 46 Inferred black box, 69 -input_async, 284
J
jitter, 28
N
netlist analysis, 45 nl, 347 no_sync scheme, 229, 231 Non-native case directives, 324
L
l, 347 L/-Lf, 334, 361 libmap, 334 libmap_verbose, 334 Library section, 61 limit_messages, 347 Local reconvergence, 35 -locklib, 326, 327
O
Objects window, 423 od, 347 out-of-band signals, 30 override_on/override_off, 70
M
-max_cdc_crossings number, 283 mean-time-between-failure, 26 memory increase, 296 memory_sync scheme, 223 metastability cdc_fx checker, 159 fence logic, 30 in hardware, 26 in RTL simulation, 27 injection, 159 metastable flip-flops, 26 registers, 26 windows, 160 modal analysis capabilities, 133 mode report information, 451 modelsim.ini, 58, 61 modelsimini, 330, 334, 360 Modules window, 442 Move-window button Buttons
470
P
Parser directives, 70 Pass count, 356 Path ID, 49 PLI function calls, 171 Popup menus, 411 port domain information, 450 Port constraints, 273 -ports, 273 Pragmas, 70 -print_detailed_custom_sync, 286 -print_port_domain_template, 286 Project mode, 91 Project window, 440 -promote_reconvergence, 284 Promoted checkers, 48 promotion, 40 pulse_sync scheme, 233
Q
question mark (?) wildcard, 311
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z R
-rd_ptr, 382 -rd_ptr_check, 382 reconvergence defined, 35 scheme, 235, 246 Reconvergence depth, 37 redundant scheme, 238, 240 -registered, 402 rel_paths, 347 Report clocks, 93 Resource libraries, 60 -restore_state, 349 Restrictions formal block, 69 runtime increase, 296 -rx_clock, 377, 382, 391, 398 -rx_clock_group, 273 -rx_data_select, 378 -rx_data_stable, 378 -rx_done, 394 -rx_done_assert_until_rx_valid_deassert, 393 -rx_min, 393 -rx_reset, 377, 382, 391, 398 -rx_valid, 394 -rx_valid_assert_until_rx_done_assert, 392 -rx_var, 398 dmux, 208, 244 fanin_different_clks, 210 four_latch, 218 memory_sync, 223 multi_bits, 225 multi_sync_mux_select, 227 no_sync, 229, 231 potential problems, 44 pulse_sync, 233 reconvergence, 235, 246 redundant, 238, 240 shift_reg, 242 two_dff, 251 two_dff_phase, 253 set_black_box, 69 set_constant_propagation, 306 set_memory, 308 -setup, 399 severity level caution, 39 evaluation, 40 violation, 39 waived, 40 shift_reg scheme, 242 Signal dividers, 436 Signal stability protocol, 46 signals out-of-band, 30 transmitting, 461 sim, 347 simulation checkers in simulation, 50 transfer protocol, 30 Single-source reconvergence, 37, 246 Skipping modules, 69 specifying design intent, 47 stability protocol, 46 -stable, 401 Standard options definition, 375 Static formal analysis, 91 Statistics current FIFO entries, 383 cycles checked (evals), 386 dequeues, 383
S
-sample_data_stability, 284 Saving the current layout, 417 schemes async_reset, 181 async_reset_no_sync, 184 blackbox, 186 bus_dff_sync_gated_clk, 191 bus_four_latch, 193 bus_shift_reg, 195 bus_two_dff, 197 bus_two_dff_phase, 199 CDC, 39 combo_logic, 201 custom_sync, 189, 203, 205 dff_sync_gated_clk, 207
471
enqueues, 383 enqueues and dequeues (evals), 383 longest assertion, 379 longest stable time, 388, 402 maximum FIFO entries, 383 maximum turnaround cycles, 395 minimum turnaround cycles, 395 one to zero transition bitmap, 400 sample one bitmap, 399 sample zero bitmap, 399 shortest assertion, 379 shortest stable time, 388, 402 total turnaround cycles, 395 total tx_valid, 395 transfers checked, 379 values checked enqueues and dequeues (Evals), 402 values checked enqueues and dequeues (evals), 388 values sampled (evals), 399 zero to one transition bitmap, 400 Status flags, 53 Stretch-shrink bars, 415 structured synchronizers, 31 Stub modules, 285 synchronization custom modules, 458 data, 42, 43 scheme, 30, 48 synchronizer ad hoc, 31 asynchronous reset, 458 block diagram, 30 control signal, 31 structured, 31 synthesis_off/synthesis_on, 70 two_dff_phase scheme, 253 -tx_clock, 377, 382, 387, 391, 398, 401 -tx_clock_group, 273 -tx_data, 377, 391, 401 -tx_data_select, 378 -tx_data_stable, 378 -tx_done, 394 -tx_done_assert_until_tx_valid_deassert, 392 -tx_min, 378, 388, 393 -tx_min_check, 378 -tx_reset, 377, 382, 387, 391, 398, 401 -tx_valid, 391 -tx_valid_assert_until_tx_done_assert, 392 -tx_valid_deassert_until_tx_done_deassert, 392 -tx_var, 387, 398, 401
U
Undock button, 416 Unresolved modules, 364 Unsynthesizable code, 72 Unzoom button, 415 -used, 385
V
v, 338 -var, 385 -vectorize_nl, 285 verification formal, 49 version, 347 vhctrl, 361
W
Waiver file, 127 Wave view Bookmarks, 432 wd, 347 Wildcards Directive order, 259 Patterns, 257 wildcards in variables and wire names, 294 question mark(?), 311 with global directives, 265, 300, 362 Windows
T
Target design, 152 Tasks, 73 transfer protocol, 30 translate_off regions, 70 transmitting signals, 461 -turnaround_max, 393 -turnaround_min, 393 two_dff scheme, 251
472
CDC checks, 419 Clocks, 443 Design, 441 Details, 422 Directives, 444 Errors/Warnings, 418 Modules, 442 objects, 423 Project, 440 work, 360 -wr_ptr, 382 -wr_ptr_check, 382
X
Xilinx, 63
Y
y, 338
Z
Zoom button, 415
473
474
End-User License Agreement

The latest version of the End-User License Agreement is available on-line at: www.mentor.com/eula IMPORTANT INFORMATION USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMERS COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (Agreement) This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively Products) between the company acquiring the Products (Customer), and the Mentor Graphics entity that issued the corresponding quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (Mentor Graphics). Except for license agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties' entire understanding relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT. 1.1. To the extent Customer (or if agreed by Mentor Graphics, Customers appointed third party buying agent) places and Mentor Graphics accepts purchase orders pursuant to this Agreement (Order(s)), each Order will constitute a contract between Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement, any applicable addenda and the applicable quotation, whether or not these documents are referenced on the Order. Any additional or conflicting terms and conditions appearing on an Order will not be effective unless agreed in writing by an authorized representative of Customer and Mentor Graphics. 1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice. Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes or other similar charges, which Mentor Graphics will state separately in the applicable invoice(s). Unless timely provided with a valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all applicable taxes including, but not limited to, VAT, GST, sales tax and service tax. Customer will make all payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by Customer hereunder will be Customers sole responsibility. If Customer appoints a third party to place purchase orders and/or make payments on Customers behalf, Customer shall be liable for payment under Orders placed by such third party in the event of default. 1.3. All Products are delivered FCA factory (Incoterms 2000), freight prepaid and invoiced to Customer, except Software delivered electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or perfecting such security interest. Mentor Graphics delivery of Software by electronic means is subject to Customers provision of both a primary and an alternate e-mail address. 2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any updates, modifications, revisions, copies, documentation and design data (Software) are copyrighted, trade secret and confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form (except as provided in Subsection 5.2); (b) for Customers internal business purposes; (c) for the term of the license; and (d) on the computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as the employee's residence, an airport or hotel, provided that such employee's primary place of employment is the site where the Software is authorized for use. Mentor Graphics standard policies and programs, which vary depending on Software, license fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer requests any change or enhancement to Software, whether in the course of
receiving support or consulting services, evaluating Software, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made by Mentor Graphics (at Mentor Graphics sole discretion) will be the exclusive property of Mentor Graphics. 3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics Embedded Software Channel (ESC), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce and distribute executable files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++ compiler Software that are linked into a composite program as an integral part of Customers compiled computer program, provided that Customer distributes these files only in conjunction with Customers compiled computer program. Mentor Graphics does NOT grant Customer any right to duplicate, incorporate or embed copies of Mentor Graphics real-time operating systems or other embedded software products into Customers products or applications without first signing or otherwise agreeing to a separate agreement with Mentor Graphics for such purpose. BETA CODE. 4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (Beta Code), which may not be used without Mentor Graphics explicit authorization. Upon Mentor Graphics authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. This grant and Customers use of the Beta Code shall not be construed as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not to release commercially in any form. 4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customers use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customers evaluation and testing, Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and recommended improvements. 4.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on Customers feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and interest in all such property. The provisions of this Subsection 4.3 shall survive termination of this Agreement. 5. RESTRICTIONS ON USE. 5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall remain the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number and primary location of all copies of Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon request. Customer shall not make Products available in any form to any person other than Customers employees and on-site contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person permitted access does not disclose or use it except as permitted by this Agreement. Customer shall give Mentor Graphics written notice of any unauthorized disclosure or use of the Products as soon as Customer learns or becomes aware of such unauthorized disclosure or use. Except as otherwise permitted for purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive any source code from Software. Log files, data files, rule files and script files generated by or for the Software (collectively Files), including without limitation files containing Standard Verification Rule Format (SVRF) and Tcl Verification Format (TVF) which are Mentor Graphics proprietary syntaxes for expressing process rules, constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use Software or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way competitive with Software, or disclose to any third party the results of, or information pertaining to, any benchmark. 5.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software errors and enhance or modify the Software for the authorized use. Customer shall not disclose or permit disclosure of source code, in whole or in part, including any of its methods or concepts, to anyone except Customers employees or contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in any manner except to support this authorized use. 5.3. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense or otherwise transfer the Products, whether by operation of law or otherwise (Attempted Transfer), without Mentor Graphics prior written consent and payment of Mentor Graphics then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor Graphics prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics option, result in the immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms
4.
of this Agreement, including without limitation the licensing and assignment provisions, shall be binding upon Customers permitted successors in interest and assigns. 5.4. The provisions of this Section 5 shall survive the termination of this Agreement. 6. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer updates and technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics then current End-User Support Terms located at http://supportnet.mentor.com/about/legal/. AUTOMATIC CHECK FOR UPDATES; PRIVACY. Technological measures in Software may communicate with servers of Mentor Graphics or its contractors for the purpose of checking for and notifying the user of updates and to ensure that the Software in use is licensed in compliance with this Agreement. Mentor Graphics will not collect any personally identifiable data in this process and will not disclose any data collected to any third party without the prior written consent of Customer, except to Mentor Graphics outside attorneys or as may be required by a court of competent jurisdiction. LIMITED WARRANTY. 8.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed, will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant that Products will meet Customers requirements or that operation of Products will be uninterrupted or error free. The warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a) Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty shall not be valid if Products have been subject to misuse, unauthorized modification or improper installation. MENTOR GRAPHICS ENTIRE LIABILITY AND CUSTOMERS EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY, PROVIDED CUSTOMER HAS OTHERWISE COMPLIED WITH THIS AGREEMENT. MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF WHICH ARE PROVIDED AS IS. 8.2. THE WARRANTIES SET FORTH IN THIS SECTION 8 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. 9. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS OR ITS LICENSORS LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 9 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
7.
8.
10. HAZARDOUS APPLICATIONS. CUSTOMER ACKNOWLEDGES IT IS SOLELY RESPONSIBLE FOR TESTING ITS PRODUCTS USED IN APPLICATIONS WHERE THE FAILURE OR INACCURACY OF ITS PRODUCTS MIGHT RESULT IN DEATH OR PERSONAL INJURY (HAZARDOUS APPLICATIONS). NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BE LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS APPLICATIONS. THE PROVISIONS OF THIS SECTION 10 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT. 11. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDING ATTORNEYS FEES, ARISING OUT OF OR IN CONNECTION WITH THE USE OF PRODUCTS AS DESCRIBED IN SECTION 10. THE PROVISIONS OF THIS SECTION 11 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT. 12. INFRINGEMENT. 12.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States, Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics will pay costs and damages finally awarded against Customer that are attributable to the action. Customer understands and agrees that as conditions to Mentor Graphics obligations under this section Customer must: (a) notify Mentor Graphics promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance
to settle or defend the action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action. 12.2. If a claim is made under Subsection 12.1 Mentor Graphics may, at its option and expense, (a) replace or modify the Product so that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use. 12.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor Graphics licensors who do not provide such indemnification to Mentor Graphics customers; or (h) infringement by Customer that is deemed willful. In the case of (h), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs related to the action. 12.4. THIS SECTION 12 IS SUBJECT TO SECTION 9 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR GRAPHICS AND ITS LICENSORS FOR DEFENSE, SETTLEMENT AND DAMAGES, AND CUSTOMERS SOLE AND EXCLUSIVE REMEDY, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT. 13. TERMINATION AND EFFECT OF TERMINATION. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized term. 13.1. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement or any license granted hereunder will not affect Customers obligation to pay for Products shipped or licenses granted prior to the termination, which amounts shall be payable immediately upon the date of termination. 13.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this Agreement. Upon termination, Customer shall ensure that all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in Customers possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form. 14. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States government agencies, which prohibit export or diversion of certain products and information about the products to certain countries and certain persons. Customer agrees that it will not export Products in any manner without first obtaining all necessary approval from appropriate local and United States government agencies. 15. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. All Software is commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to US FAR 48 CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in this Agreement, except for provisions which are contrary to applicable mandatory federal laws. 16. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein. 17. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during Customers normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customers software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customers compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FLEXlm or FLEXnet (or successor product) report log files that Customer shall capture and provide at Mentor Graphics request. Customer shall make records available in electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights under this Agreement. The provisions of this Section 17 shall survive the termination of this Agreement. 18. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual property licensed under this Agreement are located in Ireland and the United States. To promote consistency around the world, disputes shall be resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of Oregon, USA, if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or South America. All disputes arising out of or in relation to this Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a single arbitrator to be appointed by the chairman of the Singapore International
Arbitration Centre (SIAC) to be conducted in the English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by reference in this section. This section shall not restrict Mentor Graphics right to bring an action against Customer in the jurisdiction where Customers place of business is located. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement. 19. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect. 20. MISCELLANEOUS. This Agreement contains the parties entire understanding relating to its subject matter and supersedes all prior or contemporaneous agreements, including but not limited to any purchase order terms and conditions. Some Software may contain code distributed under a third party license agreement that may provide additional rights to Customer. Please see the applicable Software documentation for details. This Agreement may only be modified in writing by authorized representatives of the parties. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver or excuse.
Rev. 100615, Part No. 246066

CDC User

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CDC User

Uploaded by

Copyright:

Available Formats

0-In CDC User Guide

Software Version 10.0 February 2011

1995-2011 Mentor Graphics Corporation All rights reserved.

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

0-In CDC User Guide, v10.0 February 2011

Introduction 0-In Advanced Functional Verification Manuals

0-In Advanced Functional Verification Manuals

0-In CDC User Guide, v10.0 February 2011

Introduction Notational Conventions

0-In CDC User Guide, v10.0 February 2011

Introduction Online Help

0-In CDC User Guide, v10.0 February 2011

Introduction Online Help

0-In CDC User Guide, v10.0 February 2011

Specify cwhelp with no arguments to list the available directives:

0-In CDC User Guide, v10.0 February 2011

Introduction Online Help

0-In CDC User Guide, v10.0 February 2011

Introduction Mentor Graphics Support

Mentor Graphics Support

0-In CDC User Guide, v10.0 February 2011

Chapter 2 CDC Basics

0-In CDC User Guide, v10.0 February 2011

CDC Basics CDC Design Issues

CDC Design Issues

0-In CDC User Guide, v10.0 February 2011

CDC Basics Clock Domains

clk clk33 PLL clk50

Single Clock Domain

Multiple Clock Domains

0-In CDC User Guide, v10.0 February 2011

CDC Basics Metastability

0-In CDC User Guide, v10.0 February 2011

CDC Basics Metastability

Metastability in Standard RTL Simulation

q setup time violations

rx_clk hardware matches simulation

hold time violations

0-In CDC User Guide, v10.0 February 2011

CDC Basics Metastability

Pseudorandom Delay Insertion

0-In CDC User Guide, v10.0 February 2011

CDC Basics Metastability

CDC-FX Injected RTL Simulation

CDC Bus with a Synchronizer

rx_reg cdc_fx checker

clocks monitor metastability injector

clocks monitor synchronizer metastability injector

0-In CDC User Guide, v10.0 February 2011

CDC Basics Synchronizers

sync logic rx_clk

sync logic rx_clk

0-In CDC User Guide, v10.0 February 2011