Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
9K views986 pages

VC SpyGlass CDC UserGuide

This document provides a user guide for VC SpyGlass Clock Domain Crossing (CDC) analysis. It describes how to set up the design environment for CDC analysis, perform CDC checks using VC SpyGlass, and debug any CDC violations found. Key features of VC SpyGlass CDC include integrity checks, synchronization checks, convergence checks, and glitch checks to verify correct data transfer between clock domains in a design. The guide also explains how to specify clocks and resets in the design to enable accurate CDC analysis.

Uploaded by

workat60474
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9K views986 pages

VC SpyGlass CDC UserGuide

This document provides a user guide for VC SpyGlass Clock Domain Crossing (CDC) analysis. It describes how to set up the design environment for CDC analysis, perform CDC checks using VC SpyGlass, and debug any CDC violations found. Key features of VC SpyGlass CDC include integrity checks, synchronization checks, convergence checks, and glitch checks to verify correct data transfer between clock domains in a design. The guide also explains how to specify clocks and resets in the design to enable accurate CDC analysis.

Uploaded by

workat60474
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 986

VC SpyGlass

Clock Domain Crossing


User Guide
S-2021.09, September 2021
Copyright Notice and Proprietary Information
©2021 Synopsys, Inc. All rights reserved. This Synopsys software and all associated
documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the
terms and conditions of a written license agreement with Synopsys, Inc. All other use,
reproduction, modification, or distribution of the Synopsys software or the associated
documentation is strictly prohibited.

Destination Control Statement


All technical data contained in this publication is subject to the export control laws of the
United States of America. Disclosure to nationals of other countries contrary to United
States law is prohibited. It is the reader's responsibility to determine the applicable
regulations and to comply with them.

Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.

Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth
at http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.

Third-Party Links
Any links to third-party websites included in this document are for your convenience
only. Synopsys does not endorse and is not responsible for such websites and their
practices, including privacy practices, availability, and content.

Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
Synopsys Statement on Inclusivity and Diversity
Synopsys is committed to creating an inclusive environment where every employee,
customer, and partner feels welcomed. We are reviewing and removing exclusionary
language from our products and supporting customer facing collateral. Our effort also
includes internal initiatives to remove biased language from our engineering and
working environment, including terms that are embedded in our software and IPs. At
the same time, we are working to ensure that our web content and software
applications are usable to people of varying abilities. You may still find examples of non-
inclusive language in our software or documentation as our IPs implement industry-
standard specifications that are currently under review to remove exclusionary
language.
Contents

Introduction to VC SpyGlass CDC ...............................................15


Verification Compiler (VC) Platform ..................................................... 16
VC SpyGlass Solution ........................................................................... 17
VC SpyGlass CDC .................................................................................. 18
Licensing Requirements ....................................................................... 18
Key Features of VC SpyGlass CDC ......................................................... 18
VC SpyGlass CDC Methodology Flow ..................................................... 20

Reading the Design ....................................................................21


Setting Up CDC Design Environment .................................................... 22
VC SpyGlass Fundamentals for CDC ...................................................... 23
Checking License Usage ....................................................................... 23
Support for DesignWare (DW) Components ......................................... 24
Reusing the Pre-compiled DW Components ............................................ 24
Selecting DW Components for Elaboration .............................................. 24
Language Support .............................................................................. 25
Opening the vc_static_shell ................................................................. 25
Changing the VC Static Session Name and Location ................................. 27
Sample Design Setup .......................................................................... 27
Saving and Restoring Sessions Using Checkpoint/Restart Technology ......... 29
Saving and Restoring Sessions Using save_session and -restore_session .... 30
Updating the vc_static_shell Setup File .................................................. 31
Updating Application Variable Settings ................................................... 32
Reading the Liberty Files ...................................................................... 35
The search_path and link_library Variable .............................................. 35
Reading the Design .............................................................................. 37
Application Variables that Impact Reading a Design ................................. 41
Performing VC SpyGlass CDC Checks .................................................... 42
Verifying CDC Setup ............................................................................ 42
VC SpyGlass CDC Integrity Checks ........................................................ 42
VC SpyGlass CDC Synchronization Checks .............................................. 42
VC SpyGlass CDC Convergence Checks .................................................. 42
VC SpyGlass CDC Glitch Checks ............................................................ 43

v
Feedback Synopsys, Inc.
Analyzing Reports ................................................................................ 44

Creating and Verifying CDC Setup ..............................................45


Creating CDC Setup .............................................................................. 46
Running a Quick CDC Analysis .............................................................. 47
Specifying Clocks in a Design ............................................................... 48
Providing an SDC File .......................................................................... 48
Inferring Clocks Automatically .............................................................. 49
Customizing Clocks Auto-inference ........................................................ 50
Providing SDC File and Auto-inferring Missing Clocks ............................... 52
Getting a Report of the Clocks in the Design ........................................... 53
Viewing the Clocks in the GUI ............................................................... 53
Generating Count of Crossings Per Source Report .................................... 54
Specifying Reset in a Design ................................................................ 56
Providing an SDC File .......................................................................... 56
Inferring Resets Automatically .............................................................. 56
Getting a Report of the Resets in the Design .......................................... 59
Verifying CDC Setup ............................................................................. 60
Use Models for Performing CDC Setup Checks ......................................... 60
Debugging CDC Setup Violations .......................................................... 63

VC SpyGlass CDC Integrity Checks ...........................................229


About Integrity Checks ...................................................................... 229
Debugging CDC Integrity Violations ....................................................230

VC SpyGlass CDC Unsynchronized Crossing Checks ..................263


About CDC Synchronization Checks .....................................................264
Performing Synchronization Checks ....................................................267
Debugging CDC Synchronization Violations .........................................268

VC SpyGlass CDC Unsynchronized Reset Checks .......................319


About Reset Synchronization ..............................................................320
Enabling Reset Verification Checks .....................................................322
Performing Reset Synchronization Checks ..........................................323
Resolving Reset Synchronization Violations ........................................324

vi
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks .....................................363
About Convergence .............................................................................364
Running Convergence Checks .............................................................368
Resolving Convergence Violations .......................................................369
Control Synchronization Scheme .........................................................401

VC SpyGlass CDC Glitch Checks ................................................403


About Glitch Checks ............................................................................404
Types of Glitches in a Design ...............................................................406
Glitch on Synchronized Control Path .................................................... 406
Glitch on Synchronized Data Path ....................................................... 406
Glitch on Unsynchronized Path ............................................................ 407
Performing Glitch Checks ....................................................................409
Debugging Glitch Violations ................................................................410

VC SpyGlass CDC Hierarchical Flow ..........................................435


Advantages of SAM Based Hierarchical Flow ......................................... 436
CDC Abstraction Model ...................................................................... 438
Use Model ....................................................................................... 438
Validation Checks - Block Constraints Vs Top-Level Constraints ............... 443
Debugging Validation Check Violations ...............................................446

Analyzing VC SpyGlass CDC Results .........................................509


Understanding VC SpyGlass CDC Violation Database ...........................510
Configuring Message Tags .................................................................. 510
Default Format of Message Tags ......................................................... 514
Debugging CDC Violations Using Tcl ....................................................515
Examples of Violation Fields ............................................................... 522
Filtering Messages ............................................................................ 523
Operations on Tag Definitions ............................................................. 524
Debugging CDC Violations Using GUI ..................................................527
Invoking and Running CDC Checks ...................................................... 527
Message Summary View .................................................................... 533
Analyzing the Results ........................................................................ 537
Using Filters ..................................................................................... 539
Using Waivers .................................................................................. 544
Pivot Tables to Filter Violations ........................................................... 557

vii
Feedback Synopsys, Inc.
Exporting Violation Table ................................................................... 561
Reports Generated by VC SpyGlass CDC ..............................................563

Performing RCA on Violations ..................................................571


Prerequisites .......................................................................................572
Licensing Requirements ..................................................................... 572
Enabling ML-based RCA ..................................................................... 572
Configuring ML-based RCA ................................................................. 572
Running CDC Checks with ML-based RCA ............................................574
Generated Logs ................................................................................ 574
Analyzing Results ................................................................................576

Generating and Using Metastability Monitors ...........................629


Specifying Signals for Monitor Generation ...........................................630
Output of Metastability Analysis ..........................................................631
Cases When Metastability Injection Does Not Occur ...........................632
Running Metastability Monitors in VCS ................................................633
Debugging Simulation Results .............................................................637
Tracediff Command ........................................................................... 637
Dynamic CDC Coverage Report ........................................................... 643

Hybrid Flow ..............................................................................645


VC SpyGlass Hybrid Flow .....................................................................646
Generating SVAs for Simulation ..........................................................647
Simulating SVAs ..................................................................................649
Running VCS .................................................................................... 649
Assertion Coverage .............................................................................651
SVA Error Message in Simulation Output .............................................652
Debugging Using VERDI GUI ...............................................................654

Appendix A - Supported Commands .........................................655


Application Variables ..........................................................................656
cdc_clock_race_thru_latch ................................................................. 656
cdc_clockgate_enable_glitch .............................................................. 656
cdc_disable_sam_glitchport_reporting ................................................. 656
cdc_enable_merge_vector ................................................................. 657

viii
Synopsys, Inc. Feedback
cdc_enable_splitbus_mapping ............................................................ 658
cdc_include_constant_source_paths .................................................... 659
enable_cdc ...................................................................................... 659
enable_resetless_analysis .................................................................. 660
pt_compatibility_mode ...................................................................... 660
enable_viapoint_for_violations ........................................................... 661
enable_nested_hierarchy ................................................................... 661
clock_source_sequential_propagation .................................................. 662
cdc_enable_sam_port_reporting ......................................................... 662
report_net_for_combo_and_simple_seq .............................................. 662
cdc_enable_reason_for_unused_uds ................................................... 663
cdc_hybrid_dataloss_clock_ratio ......................................................... 663
cdc_enable_sam_syncport_checks ...................................................... 664
enable_default_waiver_filter_fields ..................................................... 664
prefer_lib_or_rtl_model ..................................................................... 665
cdc_enable_dataloss_multiple_sources ................................................ 665
cdc_sg_detailed_report ..................................................................... 666
prefer_dw_over_rtl ........................................................................... 666
cdc_enable_new_tags ....................................................................... 667
cdc_enable_quasi_static_setup ........................................................... 667
Supported SDC Commands ..................................................................669
CDC Commands ...................................................................................671
apply_attribute ................................................................................ 671
all_registers ..................................................................................... 672
check_cdc ....................................................................................... 673
create_cdc_abstract_model ................................................................ 675
remove_redundant_logic ................................................................... 675
write_abstract_model ........................................................................ 677
compress_cdc .................................................................................. 678
customize_cdc_abstract_model .......................................................... 679
define_attribute ................................................................................ 680
get_blocking_report .......................................................................... 681
get_cdc_coherency ........................................................................... 682
get_cdc_coherency_elements ............................................................. 683
get_clock_domains ........................................................................... 685
get_clock_roots ................................................................................ 686
get_reset_roots ................................................................................ 687
get_cdc_cluster_cause_viols .............................................................. 687
get_cdc_cluster_effect_viols .............................................................. 688
get_cdc_cluster_viols ........................................................................ 689
get_synchronizer_cells ...................................................................... 689

ix
Feedback Synopsys, Inc.
map_point_info ................................................................................ 690
report_cdc ....................................................................................... 690
report_reset_control_signals .............................................................. 697
report_clock_control_signals .............................................................. 698
set_allowed_cells .............................................................................. 699
set_asyncrst_ignore_path .................................................................. 700
set_asyncrst_synchronizer ................................................................. 701
set_cdc_convergence_ports ............................................................... 702
set_clock_relation ............................................................................. 703
set_connectivity_attribute .................................................................. 704
set_reset_attribute ........................................................................... 705
waive_cdc ....................................................................................... 706
configure_cdc_rca ............................................................................ 711
get_asyncrst_paths .......................................................................... 715
get_cdc_paths ................................................................................. 717
get_cdc_path_elements ..................................................................... 719
group_cdc_paths .............................................................................. 721
remove_cdc_violation ....................................................................... 722
get_cdc_control_synchronizer_elements .............................................. 723
get_cdc_control_synchronizers ........................................................... 723
get_cdc_mapped_name ..................................................................... 724
get_connected_objs .......................................................................... 724
report_cdc_reason_code .................................................................... 725
get_clock_relationship ....................................................................... 726
report_attribute ............................................................................... 730
set_constraints_scope ....................................................................... 732
set_cdc_ignore_path ......................................................................... 734
report_clock_reset_tree ..................................................................... 737
set_clock_attribute ........................................................................... 738
set_clockglitch_ignore_path ............................................................... 739
set_sync_attribute ............................................................................ 741
set_tag_attribute .............................................................................. 742
set_test_attribute ............................................................................. 743
set_reset_sense ............................................................................... 744
end_constraints_scope ...................................................................... 745
write_clock_tree ............................................................................... 745
write_reset_tree ............................................................................... 746
write_resets ..................................................................................... 747
write_cdc_property ........................................................................... 747
set_seq_pin_map ............................................................................. 749
generate_datasheet .......................................................................... 750

x
Synopsys, Inc. Feedback
meta_design_hier ............................................................................. 750
meta_monitor_options ...................................................................... 751
generate_clock_reset_tree ................................................................. 752
set_ignore_attribute ......................................................................... 753
Configure Commands ..........................................................................755
configure_cdc_glitch ......................................................................... 755
configure_cdc_port ........................................................................... 760
configure_cdc_power_aware .............................................................. 761
configure_cdc_reason_code ............................................................... 761
configure_cdc_static ......................................................................... 762
configure_ip_block ............................................................................ 764
configure_cdc_tag ............................................................................ 765
configure_libcell_uniquification ........................................................... 766
configure_glitch_free_cells ................................................................. 766
configure_cdc_internal_crossing ......................................................... 769
configure_cdc_crossing ..................................................................... 771
configure_property_panel .................................................................. 775
configure_cdc_smart_netlist .............................................................. 777
configure_cdc_integrity_checks .......................................................... 780
configure_cdc_asyncrst_crossing ........................................................ 781
configure_cdc_asyncrst_data_sync ..................................................... 782
configure_cdc_asyncrst_nff_sync ........................................................ 787
configure_cdc_convergence ............................................................... 792
configure_cdc_data_sync ................................................................... 797
configure_cdc_nff_sync ..................................................................... 803
configure_cdc_netlist_busmerging ...................................................... 808
configure_cdc_abstract_model ........................................................... 808
configure_cdc_rule ........................................................................... 810
configure_cdc_rule_param ................................................................. 810
configure_cdc_setup_check ................................................................ 811
configure_cdc_setup_libcell ................................................................ 816
configure_clock_propagation .............................................................. 817
configure_console_messages ............................................................. 817
configure_set_clock_group ................................................................ 819
configure_unconstrained_ports ........................................................... 820
configure_cdc_setup_blackbox ........................................................... 823
configure_cdc_validation ................................................................... 824
configure_setup_port ........................................................................ 826
configure_cdc_attribute ..................................................................... 827
configure_clock_reset_tree ................................................................ 827
configure_cdc_multiflop ..................................................................... 829

xi
Feedback Synopsys, Inc.
Database Commands ...........................................................................830
all_clock_gates ................................................................................. 830
all_clocks ........................................................................................ 830
all_connected ................................................................................... 830
all_designs ...................................................................................... 832
all_fanin .......................................................................................... 832
all_fanout ........................................................................................ 835
all_inputs ........................................................................................ 837
all_instances .................................................................................... 838
all_outputs ...................................................................................... 838
change_link ..................................................................................... 839
configure_mem_macro_inference ....................................................... 840
connect_net ..................................................................................... 840
create_bus ...................................................................................... 841
create_cell ....................................................................................... 843
create_net ....................................................................................... 844
create_port ...................................................................................... 845
define_user_attribute ........................................................................ 846
disconnect_net ................................................................................. 848
find ................................................................................................ 849
get_cdc_sequentials .......................................................................... 849
get_cells ......................................................................................... 849
get_designs ..................................................................................... 852
get_lib_cells .................................................................................... 854
get_lib_pins ..................................................................................... 857
get_lib_timing_arcs .......................................................................... 859
get_libs ........................................................................................... 860
get_link ........................................................................................... 862
get_nets .......................................................................................... 863
get_object_name ............................................................................. 867
get_pins .......................................................................................... 868
get_ports ........................................................................................ 871
get_timing_arcs ............................................................................... 874
insert_buffer .................................................................................... 875
list_designs ..................................................................................... 876
list_instance .................................................................................... 877
list_libs ........................................................................................... 878
remove_attribute .............................................................................. 879
remove_buffer ................................................................................. 879
remove_bus ..................................................................................... 880
remove_cell ..................................................................................... 881

xii
Synopsys, Inc. Feedback
remove_net ..................................................................................... 882
remove_port .................................................................................... 883
report_cell ....................................................................................... 884
report_link ....................................................................................... 886
report_net ....................................................................................... 887
report_port ...................................................................................... 888
set_always_on_cell ........................................................................... 889
set_attribute .................................................................................... 890
set_get_command_message_limit ...................................................... 891
set_isolation_cell .............................................................................. 891
set_level_shifter_cell ........................................................................ 892
set_pg_pin_model ............................................................................ 894
set_pin_model ................................................................................. 895
set_power_switch_cell ....................................................................... 897
set_retention_cell ............................................................................. 898
set_top_module ............................................................................... 899
Common Commands ............................................................................900
add_tag_field ................................................................................... 900
analyze ........................................................................................... 900
change_names ................................................................................. 903
check_hdl_lib ................................................................................... 904
checkpoint_session ........................................................................... 905
cluster_static_violations .................................................................... 905
configure_libcell_uniquification ........................................................... 905
configure_module_synthesis .............................................................. 906
configure_reset_propagation .............................................................. 907
configure_tcl_command .................................................................... 912
configure_unobservable_logic_identification ......................................... 913
configure_waiver_filter_field .............................................................. 913
create_clock .................................................................................... 914
create_generated_clock ..................................................................... 916
create_interface_wrapper .................................................................. 918
create_reset .................................................................................... 919
create_static .................................................................................... 921
define_design_lib ............................................................................. 922
define_glitch_free_mux ..................................................................... 923
define_name_rules ........................................................................... 924
define_reset_mapping ....................................................................... 925
diff_database ................................................................................... 926
disable_tag_field .............................................................................. 927
dw_analyze ..................................................................................... 928

xiii
Feedback Synopsys, Inc.
elaborate ......................................................................................... 928
execute_rootcause_analysis ............................................................... 931
generate_waiver_commands .............................................................. 933
get_blackbox ................................................................................... 934
get_clock_relationship ....................................................................... 935
get_constant_sources ....................................................................... 936
get_exception .................................................................................. 937
get_field_subfield ............................................................................. 938
get_glassbox ................................................................................... 939
get_license ...................................................................................... 939
get_no_msg_reporting_tags .............................................................. 940
get_pi_drive_clock ............................................................................ 941
get_readmsg_attribute ...................................................................... 941
get_readmsg_field ............................................................................ 941
get_readmsg_ids .............................................................................. 942
get_readmsg_names ......................................................................... 942
get_readmsg_names ......................................................................... 943
get_violation_waiver ......................................................................... 943
get_waiver_attribute ......................................................................... 944
get_waivers ..................................................................................... 945
index_database ................................................................................ 945
infer_clock_roots .............................................................................. 945
infer_reset_roots .............................................................................. 946
infer_setup ...................................................................................... 946
link ................................................................................................. 948
link_design ...................................................................................... 949
list_all_waiver_files ........................................................................... 950
llib .................................................................................................. 950
man ................................................................................................ 951
merge_database .............................................................................. 952
read_cdc_constraints ........................................................................ 953
read_file .......................................................................................... 953
read_sdc ......................................................................................... 958
remove_case_analysis ....................................................................... 959
remove_clock ................................................................................... 959
remove_clock_groups ....................................................................... 960
remove_generated_clocks ................................................................. 961
report_mode .................................................................................... 962
report_names .................................................................................. 963
report_properties ............................................................................. 963
report_read ..................................................................................... 964

xiv
Synopsys, Inc. Feedback
report_read_violations ...................................................................... 964
report_session_data ......................................................................... 968
report_tag ....................................................................................... 968
reset_mode ..................................................................................... 970
restart_session ................................................................................. 970
set_case_analysis ............................................................................. 971
set_abstract_model .......................................................................... 972
waive_read ...................................................................................... 973
Command Sanity Checks .....................................................................976
Errors Generated by Tcl Commands ..................................................... 976

xv
Feedback Synopsys, Inc.
xvi
Synopsys, Inc. Feedback
Introduction to VC
SpyGlass CDC

This section introduces Verification Compiler (VC) Platform, VC SpyGlass,


and VC SpyGlass CDC and is organized into the following sections:
 Verification Compiler (VC) Platform
 VC SpyGlass Solution
 VC SpyGlass CDC

15
Feedback Synopsys, Inc.
Introduction to VC SpyGlass CDC

Verification Compiler (VC) Platform

Verification Compiler (VC) Platform


Today's electronic consumer market is driven by a huge demand for
mobility, portability, and reliability. Additional functionality, performance,
and bandwidth are very important for maximizing semiconductor sales in
addition to faster time-to-market and product quality. The evolution of
applications, such as cellular phones, laptops, PDAs, computers, mobile
multimedia devices, and portable systems, has seen an exponential growth
in battery operated systems.
The increase in design complexities and shrinking technologies, where
more and more functionality is being added into smaller area of a chip has
brought in a new set of challenges in System-on-Chip (SoC) verification.
With adoption of advanced techniques and sophisticated tools, which helps
in verifying SoC connectivity, signal integrity, power management, and
functionality of analog components, hardware-software co-verification has
become inevitable.
This brings in a need for a unified and integrated verification environment
with seamless flow and reuse of the information across different domains/
levels to achieve faster results.
Verification Compiler Platform is a next-generation verification solution that
provides a scalable environment, where sophisticated tools work
seamlessly with each other throughout the flow to accomplish various
verification tasks using integration of technologies. It helps in optimizing
design iterations and recompilations, shortens debug cycles, and enables
steady integration and interoperability between individual verification tools.

16
Synopsys, Inc. Feedback
Introduction to VC SpyGlass CDC

VC SpyGlass Solution

VC SpyGlass Solution
Traditionally, simulation-based dynamic verification techniques have been
the mainstay of functional verification. As modern day SoC designs become
more complex, the adoption of static verification techniques is important.
Synopsys' VC SpyGlass solution offers the next-generation comprehensive
VC SpyGlass Lint, VC SpyGlass CDC, and VC SpyGlass RDC solutions.
VC SpyGlass Lint, a static verification tool, performs system-to-netlist
verification using prepackaged rules to check Verilog, SystemVerilog, VHDL
designs against various coding standards and design rules. After you
elaborate your design in the VC Lint environment, you can use built-in Tcl
queries, prepackaged checks, and a set of predefined procedures to run
interactive queries on your design. For more information, see the VC Lint
User Guide.
RTL code is verified for connectivity correctness between two nodes of a
design using the VC Formal Connectivity Checking solution. For more
information, see the VC Formal Connectivity Checking User Guide.
RTL is further verified for functionality and policy compliance. Model
checking technique exhaustively and automatically checks whether a
model adheres to a given specification and verifies correct properties of
finite-state systems. For more information, see the VC Formal Verification
User Guide.
VC SpyGlass RDC performs reset verification to report issues, such as
metastability, glitches, and functional failures leading to silicon failure. It
also provides advanced RDC capabilities, such as performing RDC
synchronization in sequential crossing paths, memory modeling, and
extracting reset order automatically from the simulation database. In
addition, it generates RDC reports that you can use to identify
synchronization issues in the design. You can also waive and filter
violations.

17
Feedback Synopsys, Inc.
Introduction to VC SpyGlass CDC

VC SpyGlass CDC

VC SpyGlass CDC
VC SpyGlass CDC enables you to detect issues related with Clock Domain
Crossings (CDC) in a design. CDC can help to verify if proper
synchronization is added in the circuit.
Some of the problems associated with clock domain crossings include:
 Issues related to metastability
 Issues related to complex synchronizers
 Issues related to reset synchronization
 Issues related with the implementation of clocks, resets, and crossings
The VC SpyGlass CDC setup enables you to verify the design specific
configuration, synchronizer schemes and other advanced CDC checks like
reconvergence, divergence, and reset verification.
As a part of the CDC verification, the tool identifies clock domains, creates
crossings and detects synchronizers. In this process, problems found in the
design are captured in the violation database. CDC reports issues in the
form of rule messages, reports, and related files, which enables you to
review and rectify the issues effectively.
After the basic CDC verification is complete, more advanced CDC checks
like reconvergence, divergence and reset verification can be run.
Using Tcl based query commands, violation reports (custom reports) can
also be generated using the tool.

Licensing Requirements
VC SpyGlass CDC requires the 'VC-LINT-BASE & checker', 'VC-CDC-BASE &
adv_checker' and ‘cdc_adv_checker’ licenses. Ensure that these licenses
are available before you run VC SpyGlass CDC.

Key Features of VC SpyGlass CDC


The key features and benefits of using VC SpyGlass CDC for static
verification in a typical design flow are as follows:
 Clock and reset analysis

18
Synopsys, Inc. Feedback
Introduction to VC SpyGlass CDC

VC SpyGlass CDC

 Glitch analysis
 Synchronization checks
 Convergence/coherency checks

19
Feedback Synopsys, Inc.
Introduction to VC SpyGlass CDC

VC SpyGlass CDC Methodology Flow

VC SpyGlass CDC Methodology Flow


Figure 1 shows the VC SpyGlass CDC methodology flow.

FIGURE 1. VC SpyGlass CDC Methodology Flow

20
Synopsys, Inc. Feedback
Reading the Design

This section describes how you can get started with VC SpyGlass CDC.

21
Feedback Synopsys, Inc.
Reading the Design

Setting Up CDC Design Environment

Setting Up CDC Design Environment


You must provide the synthesizable design files (RTL/Netlist) and the
Synopsys Design Constraints (SDC) file to perform CDC verification. VC
SpyGlass CDC can also generate the SDC file by auto-inferencing clock
roots.

Licensing and Installation


This release of VC Static Platform is a standalone platform and must be
installed in an empty directory, using the latest version of the Synopsys
Installer. Do not install this release over an existing release of a Synopsys
tool.
For installation instructions, see the vc_static_INSTALL_README.txt file
in the product download directory. For detailed installation instructions, see
the Synopsys Installation Guide at the following address:
http://www.synopsys.com/install
Before running Synopsys tools, you must have installed and configured the
Synopsys Common Licensing (SCL) software, retrieved your license key
file, and defined the license file environment variable. For detailed
information about SCL installation and setup, see the Synopsys Licensing
Quickstart Guide at the following address:
http://www.synopsys.com/licensing
For more information on the VC Static license keys, see section VC Static
Product Installation Notes.

22
Synopsys, Inc. Feedback
Reading the Design

VC SpyGlass Fundamentals for CDC

VC SpyGlass Fundamentals for CDC


VC SpyGlass CDC uses the synthesizable RTL files and the Synopsys Design
Constraints (SDC) file to perform CDC verification. The tool provides you
with commands that you can use to create and verify CDC setup, perform
various checks, such as integrity, synchronization, glitch, and convergence
checks on the design.
VC SpyGlass CDC supports multiple constraints that you can use to specify
the design intent. You can also use the supported application variables to
define the checks performed on the design.
VC SpyGlass CDC reports the results of the checks performed on the
design in the form of violation tags. A violation tag can be an Error,
Warning, or Info type depending on the type of violation reported.

Checking License Usage


You can set the SNPS_VCSG_LICENSE_REPORTING environment variable
to track the licenses that are checked-in and checked-out. Use the
following command to set the environment variable and then run a
command in vc_static_shell:
$ setenv SNPS_VCSG_LICENSE_REPORTING
The license check out information is displayed on the screen. For example,
consider the following check_cdc command:
vc_static_shell> check_cdc
Successful checkout of 1 license(s) of feature = VC-LINT-BASE
port@server = 7183@us01vglmd1
Successful checkout of 1 license(s) of feature = VC-CDC-BASE
port@server = 7183@us01vglmd1
Successful checkout of 1 license(s) of feature = checker
port@server = 7183@us01vglmd1
Alternatively, you can use the -lic_report command line option.

23
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

Support for DesignWare (DW) Components


VC Static supports usage of DesignWare components in the RTL. To compile
DW components, use the dw_analyze command as shown below:
dw_analyze -dwroot <DC-install-path> <dir-name>
Where:
 <DC-install-path> specifies the path to Design Compiler
 <dir-name> specifies the directory where the compiled DW is stored
For example, consider the following command:
dw_analyze -dwroot /global/apps/syn_2016.12-SP3
NG_DW_WORK_1712
In the above command, /global/apps/syn_2016.12-SP3 specifies the
path to DC and NG_DW_WORK_1712 is the name of the directory where the
compiled DW is generated.

Reusing the Pre-compiled DW Components


You can use DW components that are compiled in a previous major release
by saving the compiled DW components to an appropriate location that is
accessible by other users. Users can use this compile in all Service Pack
releases of the major VC Static release. You need to recompile the DW
components when you move to the next major VC Static release.
For example, if you compile DW components in the VC Static 2017.12
release and save it at a central location, all users can use the compile in all
the VC Static 2017.12-SP* releases.
To use such compiled DW components, use the following command:
set_app_var vsi_dwroot <path>/NG_DW_WORK_1712
Where, <path> specifies the directory where the compiled DW components
are stored.
NOTE: You can save the compiled DW components on your local machine and use it in
successive SP* releases as well.

Selecting DW Components for Elaboration

24
Synopsys, Inc. Feedback
Reading the Design

Support for DesignWare (DW) Components

If both RTL and DW pre compiled libraries are present in a design, VC


SPYGLASS, by default, uses the RTL definition for elaboration. This might
lead to creation of blackboxes of the DesignWare components in the
design.
Set the prefer_dw_over_rtl application variable to true to enable VC
SpyGlass to use the DW pre-compiled libraries instead of RTL.

Language Support
VC Static platform supports the following industry standard HDLs:
 Verilog (1995, v2k)
 VHDL (‘87, ‘93, 2008)
 SystemVerilog 1800-2005, and 2009
 Mixed Language Design

Opening the vc_static_shell


VC SpyGlass CDC uses the pivotal environment variable:
VC_STATIC_HOME. This variable must be set to point to the installation
directory as shown in the following code snippet. In the installation
directory, you can find the bin, lib, doc and other directories.
% setenv VC_STATIC_HOME /tools/synopsys/vcst
Optionally, you can add $VC_STATIC_HOME/bin to your $PATH. To start the
VC Static tool, execute the following command:
% $VC_STATIC_HOME/bin/vc_static_shell
To invoke the VC Static platform from the shell in the 64-bit mode (default
mode), use the following command:
%vc_static_shell

VC Static Shell Command Line Options


The following command line options are available for VC Static. The options
might be abbreviated by leaving out the text in parenthesis; for example,
either –f or –file can be used to give the name of a script file to execute.

25
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

Syntax
%vc_static_shell -help
Usage: /~/Release/bin/vc_static_shell
[-batch]Start tool in batch mode (non-interactive).
[-cmd_log_file <log_name>]Name of command log file in current
directory.
[-f(ile) <file_name>]Script file to exec after setup.
[-gui]Start the GUI ActivityView.
[-h(elp)]Print this help message.
[-id | -ID] Give more information about application build/
env.
[-lic_wait <minutes>]Wait for license for #minutes.
[-no_init]Don't load .synopsys_vcst.setup files.
[-no_restore]Remove previous session and start a new one.
[-no_ui]Starts the tool without the GUI/UI process.
[-output_log_file <log_name>]Capture console output in given
log file.
[-read_only]Restore a previous session in read-only mode.
[-restore]Restore a previous session.
[-session <session_name>]Use the <session_name> directory
for the runtime database.
[-lic_report] Enable reporting of license check-in check-out
information.
debug options:
[-echo]Echo the environment but do not invoke the executable.

Use Model
Using vc_static_shell in batch mode
%vc_static_shell -f vcst.tcl -batch

26
Synopsys, Inc. Feedback
Reading the Design

Support for DesignWare (DW) Components

Using vc_static_shell in interactive mode


%vc_static_shell -f vcst.tcl
NOTE: When you use the -batch option, VC Static automatically quits the shell even when
quit is not explicitly specified in the vcst.tcl file or when an unexpected error occurs
and the full run is not complete. This is useful for regression runs.

Changing the VC Static Session Name and Location


After vc_static_shell is run in any user work directory, VC Static creates
a default session (work database directory) in the current working area
called vcst_rtdb [VC Static Run Time Data Base] along with default log
files. The default session name is vcst.
You can change the name of the session and the location of the session at
the time of invoking vc_static_shell.
%vc_static_shell -session my_path/my_session <other
commands>
This command creates a database directory named my_session_rtdb in the
./my_path directory.

Sample Design Setup


The following script file is a sample script that you can use to run VC
SpyGlass CDC flow in vc_static_shell.
# Basic VC SpyGlass CDC TCL file.
# Edit, fill in <options> and uncomment any settings/commands,
then save.

#Settings to enable VC SpyGlass CDC flow


set_app_var enable_cdc true

# Options:
set design <top-module-name>

27
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

#Following command reads Cell library files in .db format


set search_path < Path to directory which contain db files
set link_library <db file list which located in search path>
Refer to the Reading the Liberty Files section for details.

#Commands for auto inferencing clock candidates


#infer_setup -type clock -full
#write_inferred_setup -file inferred_setup_clock.sdc -type
clock
#read_sdc inferred_setup_clock.sdc
Refer to the Inferring Clocks Automatically section for
details.

#Commands for auto inferencing reset candidates


#infer_setup -type reset -full
#write_inferred_setup -file inferred_setup_reset.tcl -type
reset
#read_sdc inferred_setup_reset.tcl
Refer to the Inferring Resets Automatically section for
details.

#SDC file for CDC setup


read_sdc <constraints.sdc>
Refer to the Providing an SDC File section for details.

#Add CDC analysis configure commands here

#Command to check CDC


check_cdc -type <type>
Refer to the Performing VC SpyGlass CDC Checks section for
details.

28
Synopsys, Inc. Feedback
Reading the Design

Support for DesignWare (DW) Components

#Following command generates verbose report


report_cdc -verbose -file verbose.rpt
Refer to the Analyzing Reports section for details.

# Show results in GUI


view_activity

Saving and Restoring Sessions Using Checkpoint/Restart


Technology
You can save a session at a point in time and quickly restart the session
later from that point. VC SpyGlass CDC supports the save and restore a
session by using the process Checkpoint/Restart (CR) technology to
improve performance.
The process CR technology creates a snapshot (checkpoint) of the process
image on disk and later reload the image to the memory and restart the
process from the same execution point. The CR technology is a very fast
save-and-restore solution because it saves and reads the data of the
process to and from disk without any transformation or computation.
Use the checkpoint_session command to save a session. This command
saves the session in the <sessionName>_cpdb/checkpoints directory. The
command uses the following syntax:
checkpoint_session # Saves the process image of a session
-session <session_name> (Specifies the name of the
session)
You can add multiple checkpoints during a single run at different stages.
However, these checkpoints must have different session_name to avoid
overwriting the existing files. If two checkpoint_session commands are
run in succession with the same session name, the output of the second
command overwrites the output of the first command.
Use the restart_session command to restart the session from the
process where it was saved by using the checkpoint_session command.
The restart_session command restarts the session from the

29
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

<sessionName>_cpdb/checkpoints directory. The command uses the


following syntax:
restart_session # Restarts process from a saved image
[-session <session_name>] (Restarts the process from the
specified session name)
[-file <file_name>] (Executes the commands specified in
this file after the process restarts)
For example, the following commands saves a session with the
checkCDC_sync name and restarts the session from the same point:
%vc_static_shell checkpoint_session -session checkCDC_sync
%vc_static_shell restart_session -session checkCDC_sync

Saving and Restoring Sessions Using save_session and -


restore_session
VC SpyGlass CDC enables you to save the results of the run after any TCL
command and restore the results in the subsequent run from the same
point. This results in a significant performance boost.
When you exit the vc_static_shell, the results of the current session are
not automatically saved. To save the session setup and run data, use the
save_session command. The command uses the following syntax:
save_session
-session <session_name>
where, -session <session_name> specifies the name to be used to save
the session.
You can use multiple commands to save multiple sessions at different
points in a run.
To restore a saved session, use the restore_session command. The
command uses the following syntax:
restore_session
[-session <session_name>]
where, -session <session_name> specifies the name of a previously

30
Synopsys, Inc. Feedback
Reading the Design

Support for DesignWare (DW) Components

saved session.

Saving a Session Automatically

Updating the vc_static_shell Setup File


VC SpyGlass CDC uses the .synopsys_vcst.setup file to configure its
environment for the design files for the VC SpyGlass CDC run. You can
create your own custom setup file with all the required settings (application
variables, settings, custom scripts) that must be loaded each time you
invoke the vc_static_shell. The key components of the
.synopsys_vcst.setup file are the name mappings in the design libraries
and the variable assignments.
When you invoke VC Static, VC SpyGlass CDC looks for the
.synopsys_vcst.setup files in the following three directories in the
following order:
1. Master Setup Directory
The .synopsys_vcst.setup file in the $VC_STATIC_HOME/bin directory
contains default settings for the entire installation. If this file exists, VC
SpyGlass CDC reads it first.
2. User Home Directory
VC SpyGlass CDC reads the setup file in your home directory second, if
present. The settings in this file take precedence over the conflicting
settings in the .synopsys_vcst.setup file in the master setup directory,
and carry over the rest.
3. User Run Directory
VC SpyGlass CDC reads the setup file in your design directory last. The
settings in this file take precedence over the conflicting settings in the
.synopsys_vcst.setup file in the master setup directory, and the
.synopsys_vcst.setup file in your home directory, and will carry over
the rest. You can use this file to customize the environment for a design.

31
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

TABLE 1 The .synopsys_vcst.setup Files

File Location Function Preference

.synopsys_vcst.setup Master setup directory Contains general VC Low


($VC_STATIC_HOME/ SpyGlass CDC setup
bin) information.
.synopsys_vcst.setup User home directory Contains your preferences Medium
for the VC SpyGlass CDC
working environment.

.synopsys_vcst.setup User run directory Contains design-specific VC High


SpyGlass CDC setup
information.

NOTE: If you want to prevent VC SpyGlass CDC from reading setup files, you can use the -
no_init command line switch.

Updating Application Variable Settings


VC SpyGlass CDC offers a list of application variables that can be used as
per your requirements. To see the list of all the available application
variables and their current settings in the vc_static_shell, use the
following command:
%vc_static_shell> printvar (or)
%vc_static_shell> report_app_var
The printvar command reports all variables including user-defined
variables while the report_app_var command reports only the VC Static
and Formal application variable settings.
Example 1
%vc_static_shell> printvar
......
......
....

32
Synopsys, Inc. Feedback
Reading the Design

Support for DesignWare (DW) Components

build_timeout = "0"
cdc_clock_converge_on_output = "false"
cdc_clock_race_thru_latch = "false"
cdc_glitch_on_vck_port = "false"
cdc_glitch_unate_analysis = "false"
cdc_include_constant_source_paths = "false"
cdc_stop_resetprop_at_reset_source = "true"
check_string_literal = "false"
...
...
....
.....
Example 2
vc_static_shell> report_app_var *cdc*
Variable Value Type
Default Constraints
----------------------- --------- ------- -----
----- ---------------
cdc_clock_converge_on_output false bool false
cdc_clock_race_thru_latch false bool false
cdc_glitch_on_vck_port false bool false
cdc_glitch_unate_analysis false bool false
cdc_include_constant_source_paths false bool false
cdc_stop_resetprop_at_reset_source true bool true
enable_cdc false bool false
report_cdc_limit 100 int 100

Example 3

33
Feedback Synopsys, Inc.
Reading the Design

Support for DesignWare (DW) Components

vc_static_shell> report_app_var cdc_clock_race_thru_latch -


verbose
Variable Value Type Default
Constraints
----------------------- --------- ------- ---------- -------
----------------
cdc_clock_race_thru_latch false bool false
# Prohibits propagation through latches

For more information on the available application variables and their


functions, see Appendix A - Supported Commands.
You can change the default behavior of VC SpyGlass CDC by changing the
default settings of the application variables. You can use the set_app_var
command to change the setting of an application variable. The following
example shows how to set a variable:
vc_static_shell> set_app_var
clock_source_sequential_propagation false

34
Synopsys, Inc. Feedback
Reading the Design

Reading the Liberty Files

Reading the Liberty Files


For pure RTL designs, supplying liberty files is not necessary, However,
supplying liberty files is necessary for RTL designs with pre-instantiated
cells and for most logical/physical netlist designs. You must provide all the
required liberty files using search_path and link_library application
variables before reading the design. After the link_library and
search_path commands are set, read the design using the read_file
command.

The search_path and link_library Variable


The search_path application variable specifies a sequence of directories
where VC SpyGlass CDC looks for the library (.db) files. The specified
directories are searched before a new library file is loaded.
%vc_static_shell> set_app_var search_path <list of all the
paths>
 Specify all the paths where VC SpyGlass CDC should search for the
library files and design files. The paths might be absolute or relative to
the directory from which VC SpyGlass CDC is invoked.
 If multiple paths are present, specify the paths as space separated
values in double quotation marks.
 The search_path variable supports environment variables.
 The search_path variable does not support wildcard characters.
The link_library application variable specifies a list of .db library files to
be searched when a cell instantiation is to be resolved.
%vc_static_shell> set_app_var link_library <list of .db files>
 Specify all the library files that should be read.
 Only Liberty .db files (not .lib files) are read in by the tool.
 If multiple .db files are present, specify the paths as space separated
values in double quotation marks.
 The link_library variable does not support environment variables.
Example
%vc_static_shell> set_app_var set search_path “. path1 path2

35
Feedback Synopsys, Inc.
Reading the Design

Reading the Liberty Files

…"
%vc_static_shell> set_app_var set link_library “lib1 lib2 …
libN"

36
Synopsys, Inc. Feedback
Reading the Design

Reading the Design

Reading the Design


VC SpyGlass CDC reads design in RTL (verilog, VHDL, SystemVerilog) and
netlist (verilog) formats.
VC SpyGlass CDC provides the following commands to read a design:
 read_file: Read in design source files, and link design in memory. This
command can be used to load design in a single language (Verilog/SV or
VHDL). Using this command, you can specify all source files in one
command in a single language environment. The files get analyzed and
then elaborated. Upon completion of the command the complete design
has been loaded and is ready to be used. The command returns 1 on
success and 0 on failure.
Syntax:
%vc_static_shell> read_file -help
Usage: read_file # Reading design files
[-top <top_design>](Name of the top design)
[-library <library_name>](Remaps work library to library_name)
[-define <list of verilog defines>](Verilog/SV defines)
[-work <work_library>](alias for -library)
[-netlist](Verilog Netlist Reader)
[-parameters <comma-separated list of ordered or named
parameters>](design parameters)
[-vcs <vcs command line>](VCS Command line for reading design)
[-vcs_elab <vcs elaborate command line>](VCS Command line for
elaborating design)
[-format <file format>](Verilog/SV defines: Values: verilog,
sverilog, vhdl, mdb)
[-sva](Process SVA/PSL during compilation using 2009 semantics)
[-sva2005](Process SVA/PSL during compilation using 2005
semantics)
[-v2kconfig <configuration-name>](Specifies the v2k
configuration)
[-buildTop <dut name>](Specifies the DUT down from which
synthesis model is generated)

37
Feedback Synopsys, Inc.
Reading the Design

Reading the Design

[-multi_step](Load design in multi-step mode)


[-cov <metric_type>](Enables coverage instrumentation during
compilation)
[-llk <llk_type>](Creates livelock goals during compilation)
[-aep <aep_type>](Enables AEP extraction during compilation)
[-inject_fault <fault_type>](Injects behavioral faults in the
design for doing sign-off with formal)
[-j <number_of_processes>](Specifies the number of processes to
use for parallel compilation: Value >= 1)
[slist](List of input files)
NOTE: For details on how to compile a design using the VCS standard switches, see the
VCS® MX/VCS® MXi™ User Guide. You can download this document from
SolvNetPlus.
 analyze: Analyzes the specified HDL source files and stores the design
templates into the specified library in a format that is ready to elaborate
to form linkable cells of a full design. Using this command, you can
specify multiple source files in a single language in one command. On
completion of the command, all specified files are analyzed and are
ready for elaboration. The command returns 1 on success and 0 on
failure.
Syntax:
%vc_static_shell> analyze -help
Usage: analyze # Analyze the source files
[-format <file_format>] (Specify file format:
Values: verilog, vhdl, sverilog, sysc, spi)
[-library <library_name>] (Remaps the work library to
library_name)
[-work <library_name>] (Remaps the work library to library_name)
[-define <define_macros>](Spcify list of top-level macros)
[-vcs <vcs_cmd>](VCS Command line for reading design)
[design_file_list](List of source files)
NOTE: When you use the -vcs switch, the vlogan and vhdlan arguments and switches must
be enclosed in curly braces.
Examples:

38
Synopsys, Inc. Feedback
Reading the Design

Reading the Design

analyze -format verilog {test.v}


analyze -format vhdl {test.vhd}
analyze -format vhdl -vcs {-vhdl08} test.vhd
analyze -format vhdl -vcs {-f filelist_vhdl.f}
analyze -format verilog -vcs {+define+g90d -f sources_ng.f}
analyze -format verilog -vcs { +incdir+src/./sim_1 -f
sources_ng.f}
analyze -format verilog -vcs { +incdir+src/./sim_1 -f
sources_ng.f}
 elaborate: Builds a design from the intermediate format of a Verilog
module, a VHDL entity and architecture, or a VHDL configuration. Using
this command, the user can elaborate design from pre-analyzed design
files, from a specified top module. This command returns 1 on success
and 0 on failure.
Syntax
%vc_static_shell> elaborate -help
Usage: elaborate # Elaborate the design, which is analyzed
using analyze command
[-work <library_name>](Specifies the library name to which work
is to be mapped)
[-library <library_name>](Specifies the library name to which
work is to be mapped)
[-architecture <arch_name>](Specifies the name of the
architecture)
[-parameters <param_list>](Specifies a list of design parameters
enclosed in quotation marks)
[-file_parameters <file_list>](Specifies a list of files that
contain parameter specifications)
[-vcs <vcs_cmd>](VCS Command line for elaborating design)
[-sva](Process SVA/PSL during compilation using 2009 semantics)
[-sva2005](Process SVA/PSL during compilation using 2005
semantics)
[-v2kconfig <configuration-name>](Specifies the v2k
configuration)
[-buildTop <dut name>](Specifies the DUT down from which

39
Feedback Synopsys, Inc.
Reading the Design

Reading the Design

synthesis model is generated)


[-cov <metric_type>](Enables coverage instrumentation during
compilation)
[-llk <llk_type>](Creates livelock goals during compilation)
[-aep <aep_type>](Enables AEP extraction during compilation)
[-inject_fault <fault_type>](Injects behavioral faults in the
design for doing sign-off with formal)
[-j <number_of_processes>](Specifies the number of processes to
use for parallel compilation: Value >= 1)
design_name(Specifies the name of the design to build)
NOTE: (1) If there is one design top, it must not be passed using vcs arguments, that is,
elaborate –vcs {designtop}. It must be passed as follows: elaborate
designtop
(2) For a model with testbench, you must pass the arguments as follows:
elaborate dut_top -vcs "tb_top"
Where, “dut_top” is the design top, and “tb_top” is the testbench top.
(3) Set the cdc_number_of_processes application variable before the
sg_read_project command to specify if value of the -j argument of the
elaborate command should be generated in the internal.tcl and
vc_setup.tcl files created by the sg_read_project command.
 read_verilog: Reads in one or more design or library files in Verilog
format.
Syntax:
%vc_static_shell> read_verilog -help
Usage: read_verilog # Read one or more verilog files
[-netlist](Use structural Verilog netlist reader)
[-rtl](Use RTL Verilog)
file_names(Files to read)
 read_vhdl: Reads in one or more designs or library files in VHDL
format.
Syntax
%vc_static_shell> read_vhdl -help
Usage: read_vhdl # Read one or more vhdl files
[-netlist](Use structural VHDL netlist reader)

40
Synopsys, Inc. Feedback
Reading the Design

Reading the Design

file_names(Files to read)
 read_sverilog: Reads in one or more design or library files in
SystemVerilog format.
Syntax
%vc_static_shell> read_sverilog -help
Usage: read_sverilog # Read one or more systemverilog files
[-netlist](Use structural Verilog netlist reader)
[-rtl](Use RTL Systemverilog)
file_names(Files to read)

Application Variables that Impact Reading a Design


There are few application variables that affect the design read and
database generation. Before you start reading the design, ensure that you
review and set these application variables as per your design read
requirements.
 autobb_unresolved_modules
 ignore_multiple_module_def
 enable_dirty_data
 analyze_skip_translate_body
 hierarchy_delimiter
 sh_continue_on_error
For details on each of these application variables, refer to the man pages.

41
Feedback Synopsys, Inc.
Reading the Design

Performing VC SpyGlass CDC Checks

Performing VC SpyGlass CDC Checks


Performing VC SpyGlass CDC checks involves verifying the CDC setup,
performing integrity checks, performing synchronization checks,
performing convergence checks, and performing glitch checks.

Verifying CDC Setup


To verify the CDC setup, use the following command:
%vc_static_shell> check_cdc -setup
When you run the check_cdc -setup checks, VC SpyGlass CDC reports the
setup issues in the form of violation messages. You must resolve the
reported issues before performing the other CDC checks.

VC SpyGlass CDC Integrity Checks


VC SpyGlass CDC integrity checks ensure that the clocks and resets are
properly defined and are free of glitches, race conditions, and other
hazards.
To perform cdc integrity checks, use the following command:
%vc_static_shell> check_cdc -integ

VC SpyGlass CDC Synchronization Checks


To perform synchronizer detection and analysis, use the following Tcl
command:
check_cdc -type sync

VC SpyGlass CDC Convergence Checks


To perform convergence checks, use the following Tcl command:
check_cdc -type struct

42
Synopsys, Inc. Feedback
Reading the Design

Performing VC SpyGlass CDC Checks

VC SpyGlass CDC Glitch Checks


To perform glitch checks, use the following Tcl command:
check_cdc -type struct

43
Feedback Synopsys, Inc.
Reading the Design

Analyzing Reports

Analyzing Reports
After performing VC SpyGlass CDC checks, you should analyze the reports
that VC SpyGlass CDC generates. Refer to the Analyzing VC SpyGlass CDC
Results section for more information.

44
Synopsys, Inc. Feedback
Creating and Verifying
CDC Setup

This chapter is organized into the following sections:


 Creating CDC Setup
 Running a Quick CDC Analysis
 Specifying Clocks in a Design
 Specifying Reset in a Design
 Verifying CDC Setup
 Debugging CDC Setup Violations

45
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Creating CDC Setup

Creating CDC Setup


You must create a CDC setup by specifying the design information, such as
clocks, resets, boundary (input/output) port clock relationship, constants in
the design and stop modules. The quality of setup dictates the quality of
CDC verification. A wrong or incomplete setup might result in many false
violations or mask a real design bug.
Most of this information is also required for the synthesis of the design and
is readily available as part of the SDC file or might be available as a Tcl
constraints file to drive the Design Compiler (DC).
To create a setup for CDC verification, perform the following steps:
4. Define clocks (see Specifying Clocks in a Design) and resets (see
Specifying Reset in a Design).
5. Perform CDC setup checks on the design (see Verifying CDC Setup).
6. Review the results of the setup checks and modify the SDC file to
update the clock and reset signals as required. (See Creating CDC
Setup)
7. Repeat step 2 with the modified SDC file in the previous step.

46
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Running a Quick CDC Analysis

Running a Quick CDC Analysis


You must run a quick CDC analysis before RTL check-in. With the help of
pre-submit VC SpyGlass CDC verification flow, you can perform limited
checks on small blocks in various stages of development and can judge the
basic state of the design in a fast run time.
Pre-checking VC SpyGlass CDC verification flow covers the following:
 CDC crossing analysis with multi-flop/sync-cell detection
 Skips advanced CDC checks such as data sync, convergence, and glitch
analysis
 Fast Library DB load and design read
 Exits quickly when no clocks are found in the design

47
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Clocks in a Design

Specifying Clocks in a Design


You can define clocks in the design in the following ways:
 Providing an SDC file that contains all the clocks defined (see section
Providing an SDC File)
 Infer all the clocks automatically in the design and generated the SDC
file for all the inferred clocks (see section Inferring Clocks Automatically)
 Provide an SDC file and infer all the missing clocks automatically (see
section Providing SDC File and Auto-inferring Missing Clocks)

Providing an SDC File


You can specify the clocks in the design by reading in an SDC file. An SDC
file contains the clock relationships that can be imported in a design.
Use the read_sdc command to read the SDC file:
%vc_static_shell> read_sdc [-version_sdc_version] [-module
<list_of_modules>] [-instance <list_of_instances>]
[spec_file]
Example
%vc_static_shell> read_sdc [-version_sdc_version] [-module
<list_of_modules>] [-instance <list_of_instances>]
[spec_file]

Supported SDC Commands


The SDC file contains the SDC commands for defining clocks in the design.
Refer the Supported SDC Commands section for details. The following are
the supported SDC commands.
 create_clock
 create_generated_clock
 set_clock_sense
 set_clock_groups
 set_case_analysis

48
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Clocks in a Design

 set_disable_timing
 set_mode
 set_input_delay
 set_output_delay

Inferring Clocks Automatically


You can infer all the clocks in the design and generate an SDC file
automatically. By default, all the clocks are auto-inferred. VC SpyGlass
CDC also generates clocks for the flip-flops which are not associated by the
clocks.
The inferred clocks are updated in an SDC file. The generated SDC file
contains the create_clock commands for all the clock sources and
create_generated_clock commands for the generated clocks. When
there are multiple clock sources for a generated clock, multiple
create_generated_clock commands are generated.
To auto-infer the clocks in the design, use the infer_setup command:
%vc_static_shell> infer_setup -type clock | reset [-full] [-
incremental]
Example
%vc_static_shell> infer_setup -type clock [-full] [-
incremental]
For example, consider the following design:

In this case, the following commands are generated:

49
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Clocks in a Design

create_clock -name C1 [get_ports top/CLK1]


create_clock -name C2 [get_ports top/CLK2]

create_generated_clock -name GC1 [get_pins top/ff1_reg/GCP1]


-source_clock [get_pins top/ff1_reg/CP1] -master_clock C1
create_generated_clock -name GC2 [get_pins top/ff1_reg/GCP1]
-source_clock [get_pins top/ff1_reg/CP1] -master_clock C2 -
add
In auto-inference mode, all the source clocks are considered asynchronous
to each other and all the generated clocks are considered synchronous to
their master clocks. Therefore, the following set_clock_groups commands
are generated as shown below:
set_clock_groups -async {C1 GC1}
set_clock_groups -async {C2 GC2}
You must manually review the set_clock_groups commands for correct
relationships.

Saving all the Auto-inferred Clock in the Design


To save all the auto-inferred clocks, use the write_inferred_setup
command:
Syntax
%vc_static_shell> write_inferred_setup -file <file_name> -
type <setup_type>
Example
%vc_static_shell> write_inferred_setup -file <file_name> -
type clock

Customizing Clocks Auto-inference

50
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Clocks in a Design

Ignoring Elements While Inferring Clocks in a Design


Clock auto-inference in VC SpyGlass CDC starts from sequential elements
(flip-flops, latches, library sequential cells, macros pins with is_clock
attribute) and stops at the clock sources at the stop points.
To specify the types of elements that should not be considered as a start
point while auto-inferencing clocks, use the
configure_infer_setup_start_pts command.
Syntax
%vc_static_shell> configure_infer_setup_start_pts
-cell_type (flop/latch/lib-cell)
-path_type (clock/reset)
Example
%vc_static_shell> configure_infer_setup_start_pts -cell_type
latch -path_type clock

Specifying the Elements at Which Clocks Inference Must Stop


If you want to stop the collection of clocks at specified objects, then use
the configure_infer_setup_stop_pts command.
Syntax
%vc_static_shell> configure_infer_setup_stop_pts -path_type
<path_type> -type <setup_type>
Example
%vc_static_shell> configure_infer_setup_stop_pts -help
Usage: configure_infer_setup_stop_pts # Specify the type of
object at which clock propagation should stop
-path_type <path_type> (Specify the type of
path(clock/reset) whose propagation needs to be stopped)
-type <setup_type> (At which type object
propagation needs to be stopped)
When the level-shifter object is specified in the -type option, all the three
types of level-shifters, such as normal, ELS, and DLS, are ignored.

51
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Clocks in a Design

Other Customizations Available


By default, if an input of a gate has definite clock (that is, it is directly (or
after ignoring buffers/inverters) reaching to a clock pin in other paths), all
other inputs are skipped. You can use the infer_all_potentials switch of
infer_setup command to consider all the inputs even when one input is
directly reaching to a clock pin.
In the design example shown in the following figure, by default, only CLK2
is inferred as a clock. However, when infer_all_potentials is used, both
CLK1 and CLK2 are inferred as clocks.

In this case, if you want to stop clock propagation through sequential


elements, set the following application variable:
%vc_static_shell> set_app_var
clock_source_sequential_propagation false

Providing SDC File and Auto-inferring Missing Clocks


You can also provide an SDC file for the design and VC SpyGlass CDC can
infer all the missing clocks in the design automatically.
Use the following built-in use_inferred_clocks Tcl procedure to auto-infer
the clocks for remaining sequential elements. When this Tcl procedure is
used while performing setup check, VC SpyGlass CDC reads the auto-
inferred clock in the same run.
proc use_inferred_clocks {
input file_name
infer_setup -type clock --incremental

52
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Clocks in a Design

write_inferred_setup -type clock -file <file_name>


report_clocks -file file_name -type inferred
read_sdc -file <file_name> -inferred
NOTE: To use the built-in use_inferred_clocks Tcl procedure, source the cdc.tcl file by
using the source $VC_STATIC_HOME/auxx/monet/tcl/cdc_scripts/cdc.tcl command
in vc_static_shell.

Getting a Report of the Clocks in the Design


Use the following Tcl commands to get the list of clocks in the design:
 get_clocks
 report_clocks
For details on the Tcl commands, refer to the VC Static Platform Command
Reference Manual.

Viewing the Clocks in the GUI


You can see the clocks present in the design in the view_activity GUI. Use
the view_clock_tree command to highlight schematic of each clock in the
GUI.
Syntax
%vc_static_shell> view_clock_tree [-clocks <clocks>] [-cones
<cones>]
Example
For the example in , if you specify the following, the schematic of top/CLK1
tree is displayed:
%vc_static_shell> view_clock_tree -clock top/CLK1
or
%vc_static_shell> view_clock_tree -clock C1
If you specify clock cone G1, the input cone of G1 and output cone which
has ff1_reg is displayed:
%vc_static_shell> view_clock_tree -cone top/G1

53
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Clocks in a Design

FIGURE 2. Clock Tree Example

Generating Count of Crossings Per Source Report


You can generate a report that includes the count of crossings per source
object. To generate this report, create a file, such as count_proc.tcl, with
the following Tcl procedure and source it on the VC Static shell:
proc report_cdc_source_path_count { obj } {
set grp_list [ lsort -unique [ get_attribute $obj group_name
]]
foreach i $grp_list {
set count [sizeof_collection [ get_cdc_paths -group_name $i
]]
set src_name [lindex [ get_attribute [get_attribute [
get_cdc_paths -group_name $i ] source ]
full_name ] 0]

54
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Clocks in a Design

puts "$src_name: $count"


}
}
After sourcing this Tcl procedure on the shell, you can use the following
commands:
To get the crossings count for each source, use following command on VC
Shell:
report_cdc_source_path_count [get_cdc_paths ]}
You can also capture the screen output in text file. Use the following
command to redirect the screen output to the CDC-SRC-Count.rpt text
file:
redirect -file CDC-SRC-Count.rpt
{report_cdc_source_path_count [get_cdc_paths ]}
To get the count of crossings for a source name by using a regular
expression, use the following command:
report_cdc_source_path_count [get_cdc_paths -from u1/u2/u3*/
Q]

55
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Reset in a Design

Specifying Reset in a Design


You can define resets in the design in the following ways:
 Providing an SDC file that contains all resets defined (see section
Providing an SDC File)
 Infer all resets automatically in the design by using the provided utility
and generate the SDC file for all inferred resets (see section Inferring
Resets Automatically)
NOTE: Automatically inferencing the reset is not the recommended way. The automatic
reset inference utility should be used for guidance only. Review all resets inferred
by the automatic reset inference utility, prune it with the design intents, and then
use it in the VC SpyGlass CDC.

Providing an SDC File


You can specify the resets in the design by reading in an SDC file. Use the
read_sdc command to read the SDC file:
%vc_static_shell> read_sdc [-version_sdc_version] [-module
<list_of_modules>] [-instance <list_of_instances>]
[spec_file]
Example
%vc_static_shell> read_sdc resets.sdc

Supported SDC Commands


The SDC file contains the SDC commands for defining clocks in the design.
The following are the supported SDC commands:
 create_reset

Inferring Resets Automatically


You can infer all potential resets in the design and generate an SDC file
automatically. VC SpyGlass CDC also generates resets for the flip-flops
which are not associated by the clocks.

56
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Reset in a Design

The inferred resets are updated in an SDC file. The generated SDC file
contains the create_reset commands for all potential reset sources. This
also contains internally generated reset candidates.
To auto-infer the reset in the design, use the infer_setup command:
%vc_static_shell> infer_setup -type reset [-full] [-incremental]
Example
%vc_static_shell> infer_setup -type reset -incremental
To view all the inferred reset in the SDC file, using following command:
%vc_static_shell> write_inferred_setup -type reset -file <file-
name>
For example, consider the following design:

In this case, the following commands are generated:


set DEFAULT_PERIOD 10

### PRIMARY RESET ###

## Top-Module-Port
create_reset {RST1} -async -type reset -sense low
## Top-Module-Port
create_reset {RST2} -async -type reset -sense low

57
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Specifying Reset in a Design

Saving all the Auto-inferred Resets in the Design


To save all the auto-inferred resets, use the write_inferred_setup
command:
Syntax
%vc_static_shell> write_inferred_setup -file <file_name> -
type [reset|clock]
Example
%vc_static_shell> write_inferred_setup -file <infreset_file>
-type reset

Specifying the Elements at Which Resets Inference Must Stop


If you want to stop the reset inference at specified objects, use the
set_reset_sense command.
Syntax
%vc_static_shell> set_reset_sense -reset <reset name> -
direction backward <design_object>

Inferring all Potential Resets in the Design


By default, if an input of a gate has definite clock (that is, it is directly (or
after ignoring buffers/inverters) reaching to a clock pin in other paths), all
other inputs are skipped. You can use the infer_all_potentials switch of
infer_setup command to consider all the inputs even when one input is
directly reaching to resets clock pin.
In the design example shown in , by default, only RST2 is inferred as a
reset. However, when the infer_all_potentials is used, both RST1 and
RST2 are inferred as resets.

58
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Specifying Reset in a Design

FIGURE 3. Example of inferring all resets

Getting a Report of the Resets in the Design


Use the following Tcl commands to get the list of clocks in the design:
 get_resets
 write_inferred_setup
For details on the Tcl commands, refer to the VC Static Platform Command
Reference Manual.

59
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Verifying CDC Setup

Verifying CDC Setup


You must review and modify the clock roots list, and add information such
as domain grouping of clocks, constants, I/O relationships, and reset
definitions. VC SpyGlass CDC performs setup checks to verify the sanity of
the SDC generated used for CDC verification.
VC SpyGlass CDC performs the following checks on the SDC or Tcl file:
 Existence of SDC design objects
 Clock groups are non-conflicting
 SDC options in these commands are complete
 No empty clock groups
 Clocks used in I/O delay are properly defined
VC SpyGlass CDC reports violations on the registers covered after the
checks are performed.
To verify the CDC setup, use the following command:
%vc_static_shell> check_cdc -type setup
When you run check_cdc setup checks, you might get violation tags. The
Debugging CDC Setup Violations section describes each of the tag and how
to resolve them.

Use Models for Performing CDC Setup Checks


 Providing SDC clocks with no auto-inference
%vc_static_shell> read_sdc T.sdc // Read SDC file
%vc_static_shell> check_cdc -type setup // Propagate all the
clocks, compute domains and perform CDC setup checks
 Providing SDC clocks and inferring clocks for missing clocks. It uses the
inferred clocks in the same runs.
%vc_static_shell> read_sdc T.sdc // Read SDC file
%vc_static_shell> infer_setup -type clock -apply // Auto-
infer clocks and read the generated SDC
%vc_static_shell> check_cdc -type setup // Propagate all the
clocks, compute domains and perform CDC setup checks

60
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Verifying CDC Setup

OR
%vc_static_shell> read_sdc T.sdc // Read SDC file
%vc_static_shell> infer_setup -type clock -incremental
%vc_static_shell> report_clocks write_inferred_setup -file
out.sdc -type clockinferred
%vc_static_shell> read_sdc -file out.sdc -inferred
%vc_static_shell> check_cdc -type setup // Propagate all the
clocks, compute domains and perform CDC setup checks
 Providing SDC clocks and use all the inferred clocks
%vc_static_shell> use_inferred_clocks -file out.sdc // Auto-
infer clocks and read the generated SDC
%vc_static_shell> check_cdc -type setup // Propagate all the
clocks, compute domains and perform CDC setup checks
 Inferring all the clocks, but would want to review before using them in
the same run
%vc_static_shell> infer_setup -type clock -full
%vc_static_shell> write_inferred_setup -file out.sdc -type
inferredclock // Review these clocks, edit the SDC accordingly
 Performing a full auto-inference even in presence of SDC clocks (to
compare the inferred clock list with SDC clock list)
%vc_static_shell> read_sdc T.sdc // Read SDC file
%vc_static_shell> infer_setup -type clock -full // Full auto-
inference
%vc_static_shell> write_inferred_setup -file out.sdc -type
clock // Review these clocks, edit the SDC accordingly
%vc_static_shell> report_clocks -file out.sdc -type inferred
// Review these clocks and compare with SDC clocks
 Reviewing applied case analysis constraints and applying clock
constraints properly
set_app_var cdc_dump_clkpath_case_analysis true
When the cdc_dump_clkpath_case_analysis application variable is set
to true, at the setup stage of check_cdc command, the tool generates
the auto_case_analysis.sdc file that contains the case analysis
constraints, as comments, for the mux-select and the clock enable

61
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Verifying CDC Setup

signals in the clock path.


You can review this file and uncomment the required constraints. By
default, the auto_case_analysis.sdc file is generated in the
vcst_rtdb/.internal/cdc/ directory.

62
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Debugging CDC Setup Violations


This section describes the various tags VC SpyGlass CDC reports for setup
violations.

63
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

CDC_STOPPED_LIMIT_REACHED
Severity
Warning

Short Help
Generating CDC violations stopped at user defined limit.

Description
VC SpyGlass CDC reports this tag if the count of violations crosses the limit
set with the configure_cdc_violation -limit command. By default, the
limit is set to 1M violations per tag, within a tag group.
If the violation count of a tag in a tag group reaches the specified limit, VC
SpyGlass CDC stops generating violations for that tag group even if some
other tags in the group have reported lesser number of violations than the
specified limit.
In this case, VC SpyGlass CDC reports the
CDC_STOPPED_LIMIT_REACHED tag if the number of violations reported
by all the tag groups exceed the limit specified in the command.
VC SpyGlass CDC considers a tag group as a group of related tags for
which violations are appended. The following table lists the tag groups in
VC SpyGlass CDC:

TABLE 2

Group Tags
Group 1 SYNCCDC_DATAPATH_FULL, SYNCCDC_DATAPATH_PARTIAL,
SYNCCDC_CTRLPATH_PARTIAL, SYNCCDC_CTRLPATH_FULL,
SYNCCDC_UNSYNC_NOSCHEME
Group 2 CDC_GLITCH_CTRLPATH, CDC_GLITCH_DATAPATH,
CDC_GLITCH_UNSYNC

SpyGlass VC CDC considers all tags, other than the tags specified in
Table 2, as a tag group.

64
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
To enable VC SpyGlass CDC to report all violations of a tag group, set the
configure_cdc_violation -limit command to 0.

Related Command(s)
None

Related App-var(s)
None

65
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_LIBCELL_COMBO_DRIVEN_ASYNCPIN
Severity
Error

Short Help
Reports library cell async pins driven by combinational logic

Description
VC SpyGlass CDC reports this tag if library cell async pin is driven by
combinational logic. These special async pins have:
 No timing arc defined with respect to any clock pin of the cell.
 Even if the non-combinational timing arc is defined, it is defined with
respect to a non-clock pin.
The SETUP_LIBCELL_COMBO_DRIVEN_ASYNCPIN tag is not reported for any
pins that has any of the following attributes:
 Constant
 Quasi-static
 Hanging
 Clock
 Reset
 Power/Ground
 Internal
Consider the following schematic:

66
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

In the above schematic, the SD pin of the libcell is driven by the I_OR_x3
(OR) gate. Therefore, the SETUP_LIBCELL_COMBO_DRIVEN_ASYNCPIN tag
reports violation.

What Next
Review the library cell pins and check the logic driving the pin.

Related Command(s)
None

Related App-var(s)
None

67
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SG_ABSTRACT_READ
Severity
Info

Short Help
Abstracted view has been read for block <BlockName>

Description
VC SpyGlass CDC reports this tag to indicate that the SpyGlass generated
abstract view has been used in the hierarchical SoC flow.

What Next
This is an informational message and no action is required.

Related Command(s)
 configure_cdc_validation: Configures validation checks in SAM flow and
SpyGlass-like hierarchical flow.

Related App-var(s)
None

68
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

CDC_UNUSED_IGNOREPATH
Severity
Warning

Short Help
The set_cdc_ignore_path constraint is not used to waive any crossing in
the design

Description
VC SpyGlass CDC reports this tag if a user-specified set_cdc_ignore_path
command is incorrectly specified and therefore is not used to ignore any
crossing path in the design.
Consider the following schematic where the clk1 clock reaches the F1
source flip-flop and the clk2 clock reaches the F2 destination flip-flop.

Now, consider that the following constraint is applied to ignore the crossing
path from F1 to F2.
set_cdc_ignore_path -through F1/q
In this case, the set_cdc_ignore_path command is specified with the -
through <obj> option where obj is the source of a crossing. Therefore,
this crossing is not ignored by the set_cdc_ignore_path constraint and VC

69
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SpyGlass CDC reports the CDC_UNUSED_IGNOREPATH tag.

What Next
Specify the set_cdc_ignore_path constraint correctly. Check if the objects
and options specified with the set_cdc_ignore_path command are
correct. Check if the -through option is specified inadvertently instead of
the -from option.

Related Command(s)
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.

Related App-var(s)
None

70
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_ASYNC_CLOCK_OVERLAP
Severity
Error

Short Help
Two or more clocks from different domains overlap

Description
VC SpyGlass CDC reports this tag if two or more asynchronous clocks
converge on gates.
This tag reports the following reason codes:
 MULT_ASYNC_CLK_MUX
 MULT_ASYNC_CLKGATE
 MUX_DRIVING_REDUNDANT_LOGIC
 COMBO_DRIVING_REDUNDANT_LOGIC

MULT_ASYNC_CLK_MUX
This reason code is reported when two or more asynchronous clocks are
converging on a MUX. By default, this violation is reported if the output of a
mux (where clocks converge) is driving the clock pin of a sequential
element.
For example, consider the schematic in Figure 4 where clk4 and clk3 are
asynchronous clocks that are passed to the inputs of a MUX. The output of

71
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

the MUX is captured by the clock pin of a flip flop.

FIGURE 4.

What Next
This might result in inaccurate CDC analysis because the required mode is
not selected in the design. In the schematic, check the MUX where clock
signals are converging. Apply the appropriate set_case_analysis
constraint on MUX select line so that accurate CDC analysis can be
performed.

MULT_ASYNC_CLKGATE
This reason code is reported when two or more asynchronous clocks
converge on combinational logic other than mux.
For example, consider the schematic in Figure 5 where clk4 and clk3 are
asynchronous clocks that are passed to the inputs of an AND gate. The

72
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

output of the AND gate is captured by the clock pin of a flip flop.

FIGURE 5.

What Next
This might result in inaccurate CDC analysis because the required clock is
not selected in the design. Open the schematic and review the convergence
logic and make sure that it is intentional. Otherwise, change the logic to
eliminate it.

MUX_DRIVING_REDUNDANT_LOGIC
This reason code is reported when two or more asynchronous clock signals
converge on a mux which is driving a redundant logic in its fanout.
For example, consider the following schematic which has a MUX with direct
multiple clocks and a hanging output.

73
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This might result in inaccurate CDC analysis because the required clock is
not selected in the design. Open the schematic and review the convergence
logic and make sure that it is intentional. Else, change the logic to
eliminate it.

COMBO_DRIVING_REDUNDANT_LOGIC
This reason code is reported when two or more asynchronous clock signals
converge on a combinational logic which is driving a redundant logic in its
fanout.
For example, consider the following schematic which has a combo gate
with direct multiple clocks and a hanging output.

74
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This might result in inaccurate CDC analysis because the required clock is
not selected in the design. Open the schematic and review the convergence
logic and make sure that it is intentional. Otherwise, change the logic to
eliminate it.

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.
 configure_glitch_free_cells: Configures cells to control pessimism in
glitch analysis.
 create_clock: Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.
 remove_redundant_logic: Removes redundant logic to the specified
sequential depth.

Related App-var(s)
None

75
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_ASYNC_CLOCK_OVERLAP_CONSTRAINED
Severity
Info

Short Help
Two or more clocks from different domains overlap on a constrained
combinational logic

Description
VC SpyGlass CDC reports this tag if two or more asynchronous clocks
overlap on a constrained combinational logic.
This tag reports the following reason codes:
 MUX_SELPIN_CONSTRAINED
 MUX_OUTPUT_CLOCK
 COMBO_OUTPUT_CLOCK

MUX_SELPIN_CONSTRAINED
This reason code is reported when multiple clocks reach a Mux that has a
constant select.
For example, consider the following schematic where a MUX with direct
multiple clocks and constrained select has the output connected to flop
through a combo logic.

76
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This is an informational message for review purpose.

MUX_OUTPUT_CLOCK
This reason code is reported when multiple clocks reach a Mux whose
output is driving another clock.
For example, consider the following schematic where a MUX has multiple
clocks in the input side and a clock is created at the output of the MUX.

77
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This is an informational message for review purpose.

COMBO_OUTPUT_CLOCK
This reason code is reported when multiple clocks reach a combinational
gate other than Mux whose output is driving another clock.
For example consider the following schematic where a combinational gate
has multiple clocks on its input pins and another clock is created on the
output of this gate.

What Next
This is an informational message for review purpose.

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.
 configure_glitch_free_cells: Configures cells to control pessimism in
glitch analysis.
 create_clock: Creates a clock object in the current design and defines
the specified source_objects as clock sources.

78
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 create_generated_clock: Creates a generated clock object.


 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.
 remove_redundant_logic: Removes redundant logic to the specified
sequential depth.

Related App-var(s)
None

79
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_ASYNC_CLOCK_OVERWRITE
Severity
Warning

Short Help
User clock propagates to another user clock which has asynchronous
relationship with the propagating clock

Description
VC SpyGlass CDC reports this tag if a user-defined clock propagates to
another user-defined clock that has an asynchronous relationship with the
propagating clock. The propagation of the primary user-defined clock that
propagated to the overwriting clock would be stopped at the point where
the overwriting clock is defined. Only the overwriting clock propagates
beyond this point in the design as shown in the following schematic.

What Next
Check if stopping the propagation of the primary clock by defining the
other asynchronous clock on its path is as per the design intent. If not,

80
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

remove the overwriting clock.


Also check if the primary clock should have propagated to this point or
should have stopped earlier in the path.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

81
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_ASYNCRESET_UNUSED
Severity
Warning

Short Help
User-defined asynchronous reset is not driving any sequential element.

Description
VC SpyGlass CDC generates this tag to report unused asynchronous resets
that are defined with the create_reset command in SDC file. This warning
indicates that the design intent of specifying the asynchronous reset
constraint on an object is not met in the design.

What Next
To fix the issue, review the reported unused constraints. Ensure that you
have defined it on the expected object. If this is not required for the design
and is redundant, remove the asynchronous reset constraint.
If it is defined intentionally and would be used in a more mature version of
RTL design, ignore it for now or add a waiver to filter it. For example,
currently, a reset is unused because design has black boxes and once they
are resolved in later RTL version, the specified reset object would drive the
sequential element.

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

82
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_BBOXPIN_CONSTRAINED
Severity
Info

Short Help
Reports black box pins that are fully constrained or can be ignored.

Description
VC SpyGlass CDC reports this tag to show the constraint status of the black
box pins. Depending on the constraints applied, the status of pin constraint
is categorized as constrained or fully constrained as shown in Figure 6.

FIGURE 6.

83
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This is informational message for review purpose.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 create_generated_clock: Creates a generated clock object.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

84
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_BBOXPIN_UNCONSTRAINED
Severity
Error

Short Help
Reports black box pins that are unconstrained or partially-constrained

Description
VC SpyGlass CDC reports this tag to show the constraint status of the black
box pins as shown in Figure 7. Depending on the constraints applied, the
pin constraint status is categorized as unconstrained, fully constrained,

85
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

ignored, partially unconstrained, or auto-inferred.

FIGURE 7.

What Next
Review the unconstrained and partially constrained pins and define the
required constraints to make them fully constrained.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.

86
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 create_generated_clock: Creates a generated clock object.


 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

87
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_ASYNCRST_UDS_UNUSED
Severity
Warning

Short Help
UDS instances of module not used to synchronize any reset crossing.

Description
VC SpyGlass CDC generates this tag to report the User Defined
Synchronizer (UDS) instances that have not been used to synchronize any
reset crossing. By default, this tag is disabled. Use the following command
to enable it:
configure_cdc_tag -enable -tag SETUP_ASYNCRST_UDS_UNUSED
This tag reports reason codes only if the
cdc_enable_reason_for_unused_uds application variable is set to true.
This violation can have the following reason codes:
 SAME_DOMAIN_SEQ_DRIVES_UDS
 REDUNDANT_LOGIC_DRIVES_UDS
 CONST_INPUT_DRIVES_UDS
 STABLE_INPUT_DRIVES_UDS
 UNCONSTRAINED_INPUT_DRIVES_UDS
 UDS_DRIVES_UNOBSERVABLE_LOGIC

SAME_DOMAIN_SEQ_DRIVES_UDS
This reason code is reported if the data pin of UDS is in the same domain
as the clock pin of UDS. For example, in the following schematic, the reset
pin of inst4 is driven by the inst3 flip flop and both are in the same

88
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

domain.

What Next
Review the results and fix the design/setup if required.

REDUNDANT_LOGIC_DRIVES_UDS
This reason code is reported if the UDS input is driven by a redundant
logic. For example, in the following schematic, the reset pin of the Flop5 is
not connected to any logic.

89
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

CONST_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by constant logic.
For example, in the following schematic, the reset pin of inst6 is driven by
a constant.

90
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

STABLE_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by stable logic. For
example, in the following schematic, the reset pin of inst6 is driven by a
quasi-static signal.

91
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

UNCONSTRAINED_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by unconstrained
input. For example, in the following schematic, the reset pin of inst8 is
driven by an unconstrained port.

92
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

UDS_DRIVES_UNOBSERVABLE_LOGIC
This reason code is reported if the UDS output drives logic which is
unobservable. For example, in the following schematic, the output pin of
Flop5 is not connected to any logic, and is therefore unobservable.

93
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

Related Command(s)
 configure_cdc_tag: Displays and configures CDC violation tags.

Related App-var(s)
 cdc_enable_reason_for_unused_uds: Enables the supported tags to
report additional reason codes.

94
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CDC_UDS_UNUSED
Severity
Warning

Short Help
UDS instances are not used to synchronize any crossing.

Description
VC SpyGlass CDC generates this tag to report the UDS instances that have
not been used to synchronize any crossing. By default, this tag is disabled.
Use the following command to enable it:
configure_cdc_tag -enable -tag SETUP_CDC_UDS_UNUSED
This tag reports reason codes only if the
cdc_enable_reason_for_unused_uds application variable is set to true.
This violation can have the following reason codes:
 SAME_DOMAIN_SEQ_DRIVES_UDS
 REDUNDANT_LOGIC_DRIVES_UDS
 CONST_INPUT_DRIVES_UDS
 STABLE_INPUT_DRIVES_UDS
 UNCONSTRAINED_INPUT_DRIVES_UDS
 UDS_DRIVES_UNOBSERVABLE_LOGIC

SAME_DOMAIN_SEQ_DRIVES_UDS
This reason code is reported if the data pin of UDS is in the same domain
as the clock pin of UDS. For example, in the following schematic, the data
pin of inst4 is driven by the inst3 flip flop and both the sequential
elements are in the same domain.

95
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

REDUNDANT_LOGIC_DRIVES_UDS
This reason code is reported if the UDS input is driven by a redundant
logic. For example, in the following schematic, the data pin of Flop5 is not
connected to any logic.

96
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

CONST_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by constant logic.
For example, in the following schematic, the data pin of Flop2 is driven by
a constant value.

97
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

STABLE_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by stable logic. For
example, in the following schematic, the data pin of inst6 is driven by a
quasi-static signal.

98
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

UNCONSTRAINED_INPUT_DRIVES_UDS
This reason code is reported if the UDS input is driven by unconstrained
input. For example, in the following schematic, the data pin of inst8 is
driven by an unconstrained port.

99
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review the results and fix the design/setup if required.

UDS_DRIVES_UNOBSERVABLE_LOGIC
This reason code is reported if the UDS output drives logic which is
unobservable. For example, in the following schematic, the output pin of
Flop5 is not connected to any logic, and therefore is unobservable.

What Next
Review the results and fix the design/setup if required.

Related Command(s)
 configure_cdc_tag: Displays and configures CDC violation tags.

Related App-var(s)
 cdc_enable_reason_for_unused_uds: Enables the supported tags to
report additional reason codes.

100
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CGLIBCELL_DEF_INCOMPLETE
Severity
Error

Short Help
Clock gating cells without complete definition.

Description
VC SpyGlass CDC reports this tag when the clock gating cells do not have
complete definition. A CGC is considered as incompletely defined if proper
attributes are not set for at least one of the pins of the cell. The must use
attributes are:
 clock_gate_clock_pin
 clock_gate_enable_pin
 clock_gate_test_pin
 clock_gate_out_pin
For example, consider the schematic and the corresponding PinInfoList
in Figure 8 where Pin Type is missing for some of the pins. VC SpyGlass

101
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

CDC reports this tag in such scenarios.

FIGURE 8.

What Next
 If the information reported in PininfoList section is intentional, ignore
this violation.
 Else, check the clock gating cell file and verify if all the pin attributes are
properly specified or not.

102
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
None

Related App-var(s)
None

103
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLKPATH_MUX_NOCLOCK
(Alias: SETUP_CLOCKPATH_MUX_NOCLOCK)

Severity
Warning

Short Help
Unconstrained mux does not receive clocks in all its data inputs.

Description
VC SpyGlass CDC reports this tag if all the pins of a MUX do not receive
clocks from the top level when the MUX output reaches to a clock pin of
sequential elements as shown in Figure 9. It is mandatory to have
following conditions satisfied:
 One clock reaching to at least one data pin of the MUX
 At least one pin which is unblocked (non-constant and non-quasi)
without any clock reaching to it.
 A mux with dynamic selection does not receive clocks in all its data
inputs.
Exceptions
VC SpyGlass CDC does not report this tag:
 If the mux selection is constant
 For a mux whose output is defined as a new clock
 For constant mux inputs

104
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 9.

What Next
Check the clock setup in the fanin of the data pins or tie the MUX select line
to constant.

Related Command(s)
None

Related App-var(s)
None

105
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLKPROP_NO_CLK
Severity
Error

Short Help
No clock definition found in SDC file(s)

Description
Use this rule to check for setup issues related to clocks or asynchronous
resets.
VC SpyGlass CDC reports this tag if all the following conditions are true:
For Clocks
 If no clock definition is specified either by using the create_clock or by
setting the infer_setup -type clock -apply command.
 Clocks are present in the design.
 Rules that require clocks as input are enabled in the CDC run.

What Next
To fix this violation, specify clock signals for your design in either of the
following ways:
 By using the clock constraint
 By setting the infer_setup -type clock -apply command

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

106
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related App-var(s)
None

107
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RSTPROP_NO_RST
Severity
Warning

Short Help
No reset definition found in SDC file(s)

Description
Use this rule to check for setup issues related to asynchronous resets. VC
SpyGlass CDC reports this tag if all the following conditions are true:
 If no reset definition is specified either by using the reset constraint or
by setting the infer_setup -type reset -apply to yes.
 Asynchronous resets are present in the design.
 Rules that require asynchronous resets as input are enabled in the CDC
run.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
To fix this violation, specify reset signals for your design in either of the
following ways:
 By using the reset constraint
 By setting the infer_setup -type reset -apply command

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

108
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_CONSTANT
Severity
Error

Short Help
Clock net is set to a constant

Description
VC SpyGlass CDC reports this tag if the clock pin of a sequential element is
tied to a constant.

FIGURE 10.

In such cases, the clock pin of reported flip-flops, latches, or sequential


library cells can be:
 Constrained by case analysis settings (specified using the
set_case_analysis command)
 Connected to supply nets
 Connected to tied-off/tied-on cells
 Connected to combinational gate with constant output

109
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Such sequential elements are not checked for clock domain crossings.

What Next
Sequential elements with clock pins tied to a constant are not checked in
CDC analysis. Not resolving such issues can cause valid crossings to be
missed by the tool during CDC analysis. To analyze this violation, back
trace the clock pin of the corresponding sequential logic.
Review the schematic to ensure that no constant is propagating to the
clock pin of the cell. Review the set_case_analysis constraints in the
design.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

110
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_GLITCH
Severity
Error

Short Help
Asynchronous source converges with different domain clock(s)

Description
VC SpyGlass CDC reports this tag to report asynchronous signals, which
isolate the clock, but are not in the same domain as the clock signal. It
reports one violation per clock cone per asynchronous isolation source
signal.
A clock cone is a net that directly drives either the clock pin of a sequential
element, top-level port, or black box pin.
If a clock cone receives multiple asynchronous isolation sources, the
SETUP_CLOCK_GLITCH tag reports multiple violations.
The tag reports the following reason codes:
 UPF_INSTRUMENTED

UPF_INSTRUMENTED
If power intent is provided in UPF, the SETUP_CLOCK_GLITCH tag reports
an issue where the clock signal is isolated by an isolation signal generated
from a different asynchronous clock signal.
Gated clocks might result in timing hazards, such as glitches that can lead
to duty cycle distortion.

111
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
To fix the issue, review the logic to ensure that there are no glitches on the
gated clock signal. Consider declaring the asynchronous signal (or isolation
enable signal) as quasi static to resolve the issue.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.
 set_clockglitch_ignore_path: Ignores the clock path glitch crossings
reported by the supported tags.

Related App-var(s)
None

112
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_GLITCH_IGNORED
Severity
Info

Short Help
Ignores asynchronous source converging with different domain clock(s) at
convergence point defined by set_clockglitch_ignore_path command

Description
VC SpyGlass CDC reports this tag to report ignored violations for
asynchronous signals, which isolate the clock, but are not in the same
domain as the clock signal.
The SETUP_CLOCK_GLITCH_IGNORED tag reports the following reason
codes:
 USER_CLOCKGLITCH_IGNORE_PATH
 SETUP_IGNOREPATH_USER_CONSTRAINT

USER_CLOCKGLITCH_IGNORE_PATH
This reason code is reported if clock path glitches are ignored by user-
specified set_clockglitch_ignore_path constraint

What Next
This is an informational message for review purpose.

SETUP_IGNOREPATH_USER_CONSTRAINT
This reason code is reported when a clock glitch violation is ignored due to
logically exclusive or physically exclusive clock relationship between the
participating clocks.
For example, consider the following schematic where the clock relationship
between clk3 and clk4 is defined as physically exclusive by using the
set_clock_group command:

113
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set_clock_groups -physically_exclusive -group {clk3} -group


{clk4}

In this case, VC SpyGlass CDC ignores this clock glitch violation and
reports the SETUP_IGNOREPATH_USER_CONSTRAINT reason code.

What Next
This is an informational message for review purpose.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.
 set_clockglitch_ignore_path: Ignores the clock path glitch crossings
reported by the supported tags.

114
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related App-var(s)
None

115
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_UNDECL
Severity
Error

Short Help
Clock net does not receive any user-defined clock.

Description
VC SpyGlass CDC reports this tag when all the nets reaching the clock pin
of any sequential element (flop/latch) do not receive any user-defined
clock. This might lead to incorrect CDC analysis.
This violation can have the following reason codes:
 CLOCK_UNDEFINED
 CLOCK_BLOCKED_BBOX
 CLOCK_UNCONNECTED
 CLOCK_PIN_BLOCKED

CLOCK_UNDEFINED
This reason code is reported when the sequential element does not receive
any user-defined clock because the signal received by the clock pin is not
defined in SDC file.
For example, in the schematic in Figure 11, both the clocks are undefined

116
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

in the SDC file and therefore a potential crossing can be missed.

FIGURE 11.

What Next
CDC analysis is not performed on sequential elements where clock is not
reached. This can lead to valid crossings being missed out during CDC
analysis.
 Define the clock on appropriate net or port by using the create_clock
constraint.
 Use the infer_setup -type clock -apply command to auto infer
clocks. Use the automatically inferred clocks as a guidance only to
identify the clock candidates. Review all inferred clocks before
performing CDC analysis.

117
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

CLOCK_BLOCKED_BBOX
This reason code is reported when the clock pin of a sequential element
does not receive any user-defined clock because the clock signal is blocked
by a black box as shown in Figure 12.

FIGURE 12.

What Next
CDC analysis is not performed on sequential elements where clock is not
reached. This can lead to valid crossings being missed out during CDC
analysis.
Open the schematic and back-trace the clock net of the corresponding
sequential element. If the black box is created due to missing design files,
provide these files in setup. If the black box is intentional, define the clock
constraint on the black box output port.

CLOCK_UNCONNECTED
This reason code is reported when the clock pin of a sequential element
does not receive any user-defined clock because the clock pin of the

118
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

sequential element is left unconnected as shown in Figure 13

FIGURE 13.

CLOCK_PIN_BLOCKED
This reason code is reported if a clock pin of a sequential element is
blocked inside the library cell because of a constant reaching on other pins
and blocking the timing arc or mode condition inside the library cell as
shown in Figure 14.

119
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 14.

What Next
CDC analysis is not performed on sequential elements where clock is not
reached. This can lead to valid crossings being missed out during CDC
analysis. To resolve this, make the proper connection of such clock pins in
the RTL and ensure that the required clock reaches at the sequential
element.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.
 remove_redundant_logic: Removes redundant logic to the specified
sequential depth.

120
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 configure_cdc_static: Configures quasi-static for CDC analysis.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

121
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_UNUSED
Severity
Warning

Short Help
Clock object unused

Description
The specified clock object in the create_clock command setup does not
drive any flip flops/latches and is not associated with any other port of the
design using the set_clock_attribute command.
Therefore, this clock is unused and is not considered in the subsequent
CDC analysis.

FIGURE 15.

122
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

This information is useful to analyze clock domain crossings,


synchronization schemes, and other related checks.

What Next
VC SpyGlass CDC ignores this clock because it is not driving any logic. If
this is correct, then no further action is required. Else, this could be an
indication of a tool input specification error or design read issue. For
example, a black box might be blocking the clock propagation.
Review the tool setup and fix any specification errors and rerun the tool to
incorporate the revised setup information.

Related Command(s)
None

Related App-var(s)
None

123
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_DATA_CONSTANT
Severity
Info

Short Help
Reports data signals in sequential elements that are set to a constant

Description
VC SpyGlass CDC reports this tag when the data pin of a flip-flop/latch is
tied to a constant.
This tag is reported when the flip-flops and latches that cannot change
value because of any of the following reasons, and therefore are not
checked for clock domain crossings:
 Data is tied to a constant and no clear or reset.
 Data is tied to a 0 and only a clear pin.
 Data is tied to a 1 and only a set pin.
Figure 16 shows such flip-flops:

FIGURE 16.

124
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

The tag reports the following reason codes:


 CONST_DATA
 CONST_DATA_SET
 CONST_DATA_RESET

CONST_DATA
This reason code is reported if there are sequential elements with no set/
reset pin that has data pin tied to a constant.

What Next
Clock domain crossing violations are not reported for flip-flops and latches
that cannot change value. Open the schematic and trace back to review the
case analysis settings which is causing data input to be constant. If
constant value of data pin is intentional, waive the violation. Otherwise,
change the logic.

CONST_DATA_SET
This reason code is reported if there are sequential elements with set pin
that has the data pin tied high.

What Next
See What Next.

CONST_DATA_RESET
This reason code is reported if there are sequential elements with reset pin
that has data pin tied low.

What Next
See What Next.

125
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.

Related App-var(s)
None

126
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_GROUP_CONFLICT
Severity
Warning

Short Help
Mismatch between tool-inferred and user-defined clock relationship

Description
VC SpyGlass CDC reports this tag if there is a mismatch between the user-
defined clock and tool-inferred clock relationship. Based on the
create_clock commands specified in SDC, VC SpyGlass CDC can infer one
of the following relationships between clocks:
 Physically exclusive
 Logically exclusive
 Synchronous
This violation is reported if the inferred relationship between clocks is
different from the user-defined relationship (using set_clock_group). In
this case, VC SpyGlass CDC does not honor the auto-inferred clock
relationship.
For example, consider the following SDC commands:
create_clock -name clkA [get_ports A B C] -add
create_clock -name clkB [get_ports A B C] -add
set_clock_groups -group {clkA} -group {clkB} -asynchronous
In this case, clkA and clkB clocks will be inferred as physically exclusive
by the VC SpyGlas CDC. However, the relationship defined between clkA
and clkB is asynchronous. Therefore, there in a mismatch between the
tool-inferred behavior and the user-defined behavior.
NOTE: The SETUP_CLOCK_GROUP_CONFLICT tag is reported only if
pt_compatibility_mode is set to true.

What Next
This is an informational message indicating that there is a mismatch
between the user-defined clock relationship and tool-inferred clock

127
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

relationship. Review the mismatch to understand the difference. If the


mismatch is unintentional, resolve it by using the set_clock_groups
command to define the correct clock relationships.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

128
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_CLOCK_GROUP_INFER
Severity
Info

Short Help
Clock domains inferred by tool

Description
This tag reports an informational message when a clock domain is inferred
by the tool based on SDC commands and other user inputs.
For multiple clock definitions specified while creating setup, the tool creates
an elaborated clock domain list while propagating the clocks. For each
inferred domain, this informational message is displayed.
For example, consider the schematic in Figure 17 where the Domain ID 1 is
inferred by the tool for the clk2 clock object.

129
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 17.

What Next
This is an informational message indicating that the tool has inferred a
clock domain based on the SDC commands and other user inputs. The
resulting inferred clock domain is for subsequent CDC analysis. No
additional user action is typically required.
If required, review the design at the point where the clock was inferred and
ensure the resulting clock is consistent with the required clock specification
for analysis. If the clock inference is believed to be erroneous, review the
source of the clock inference (SDC clock specification, user setup
commands or identification of a composite clock).

130
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.

Related App-var(s)
None

131
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_IGNORE_COMMAND
Severity
Error

Short Help
Reports commands that are ignored during current run.

Description
VC SpyGlass CDC reports this tag if invalid objects are specified for the -
ignore_through_objects,
-ignore_at_objects, or the -ignore_among_signals options of the
configure_cdc_convergence command.
The tag reports the following reason codes:
 CONFIG_OBJ_NOT_FOUND
 CONFIG_CMD_FULLY_IGNORED
 CONFIG_MIN_OBJS_NOT_SPECIFIED

CONFIG_OBJ_NOT_FOUND
This reason code is reported if no matching design object is found for
some/all value(s) specified with the -ignore_through_objects, -
ignore_at_objects, or the -ignore_among_signals options of the
configure_cdc_convergence command.

What Next
Review the command specified in the violation for spelling errors,
syntactical correctness, and if the arguments of the command (Nets/Pins/
Ports) are present in the design.

CONFIG_CMD_FULLY_IGNORED
This reason code is reported if all the options specified are ignored due to
invalid data.

132
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
See What Next.

CONFIG_MIN_OBJS_NOT_SPECIFIED
This reason code is reported if at least two objects are not specified for the
-ignore_among_signals option.

What Next
See What Next.

Related Command(s)
 configure_cdc_convergence: Configures convergence detection criteria.

Related App-var(s)
None

133
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_INFER_CLKGRP_PHYEXCLUSIVE
Severity
Info

Short Help
Override clock relationship to physically exclusive

Description
VC SpyGlass CDC reports this tag when the clock relation inferred by the
tool is Physically exclusive while the relationship defined by the user is
Logically exclusive/Synchronous/Asynchronous. In this case, the tool
overrides the clock relation of the corresponding clocks to Physically
exclusive.
NOTE: The SETUP_INFER_CLKGRP_PHYEXCLUSIVE tag is reported only if
pt_compatibility_mode and
override_physically_exclusive_clock_relationship is set to true.
For example, consider the following SDC commands:
create_clock -name clkA [get_ports A B C] -add
create_clock -name clkB [get_ports A B C] -add
set_clock_groups -group {clkA} -group {clkB} -asynchronous
In this case, the clock relation inferred by the tool between clkA and clkB
will be Physically exclusive. However, the user-defined clock relation is
Asynchronous. Therefore in this case, the tool overrides the user-defined
clock relation to Physically exclusive for clkA and clkB.

What Next
This is an informational message regarding the clock relationship used for
CDC analysis. If the clock relations are unintentional, review the SDC
commands. If intentional, then no further action is required.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.

134
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related App-var(s)
None

135
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_INPUT_MULTICLK_LOAD
(Alias: SETUP_INPUT_MULTICLOCK_LOAD)

Severity
Error

Short Help
Primary input signal PortName is sampled by multiple clock-domains

Description
This tag is reported when a primary input is sampled by multiple clock
domains.
SETUP_INPUT_MULTICLK_LOAD tag reports primary inputs that are
sampled by more than one of the following elements clocked by different
clock domains:
 D inputs, set/reset pins of sequential elements
 A non-clock pin of a black box
 A primary output port

The SETUP_INPUT_MULTICLK_LOAD tag does not report a violation if the


primary input signal:

136
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 Is defined by using the set_input_delay or set_clock_attribute


commands.
 Drives a quasi-static flip-flop.
 Is of a domain that is auto-inferred by using the
configure_unconstrained_port command. The
SETUP_INPUT_CONSTRAINED_MULTICLK_LOAD tag reports a violation
in such cases.

What Next
 Check if set_case_analysis constraint is missing on any of the paths
that should be blocked.
 If the port is static, you might specify the create_static constraint to
remove the violations.
 If the input port does not belong to any of the domain by which it is
being sampled, make sure that synchronizers are present to
synchronize such input port on all the paths.
 Otherwise, it is better to first latch the input port in the domain it
belongs to and then distribute it to synchronizers.

Related Command(s)
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 set_case_analysis: Specifies a logic value on pins or ports.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_clock_attribute: Specifies the path element(s) or the attribute to
which the clock constraints are to be applied.

Related App-var(s)
None

137
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_INPUT_CONSTRAINED_MULTICLK_LOAD
Severity
Warning

Short Help
Primary input (for which domain is auto-inferred using
configure_unconstrained_ports) signal PortName is sampled by multiple
clock-domains

Description
SETUP_INPUT_CONSTRAINED_MULTICLK_LOAD tag reports primary inputs
(for which domain is auto-inferred using configure_unconstrained_ports)
that are sampled by more than one of the following elements clocked by
different clock domains:
 D inputs, set/reset pins of sequential elements
 A non-clock pin of a black box
 A primary output port

The SETUP_INPUT_CONSTRAINED_MULTICLK_LOAD tag does not report a


violation if the primary input signal:

138
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 Is defined by using the set_input_delay or set_clock_attribute


commands.
 Drives a quasi-static flip-flop.
The tag reports the following reason code:
 USER_CONFIGURE_PORT

USER_CONFIGURE_PORT
This reason code is reported if the port is configured by using the
configure_unconstrained_ports command.

What Next
 Check if set_case_analysis constraint is missing on any of the paths
that should be blocked.
 If the port is static, you might specify the create_static constraint to
remove the violations.
 If the input port does not belong to any of the domain by which it is
being sampled, make sure that synchronizers are present to
synchronize such input port on all the paths.
 Otherwise, it is better to first latch the input port in the domain it
belongs to and then distribute it to synchronizers.

Related Command(s)
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 set_case_analysis: Specifies a logic value on pins or ports.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_clock_attribute: Specifies the path element(s) or the attribute to
which the clock constraints are to be applied.

Related App-var(s)
None

139
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_LIBCELL_CONNECTIVITY_MISMATCH
Severity
Error

Short Help
Mismatch in path between functional and timing model found for cell
module

Description
VC SpyGlass CDC generates this tag to report mismatch in the path in the
functional model and timing model of a libcell.
This tag reports the following reason codes:
 TIMING_ARC_PATH
 FUNCTIONAL_PATH

TIMING_ARC_PATH
This reason code is reported if a path exists in the timing model only.

What Next
Use the create_trace_constraint command for missing paths that
should be analyzed for Clock Domain Crossings.

FUNCTIONAL_PATH
This reason code reports a path exists in the functional model only.

What Next
Use the create_trace_constraint command for missing paths that
should be analyzed for Clock Domain Crossings.

Related Command(s)
None

140
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related App-var(s)
None

141
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_LIBCELL_DEF_COMPLETE
Severity
Info

Short Help
All pins have complete definition for instance of library cell

Description
VC SpyGlass CDC reports this tag if all the pins of library cell instance are
defined correctly.

What Next
This is informational message for review purpose.

Related Command(s)
None

Related App-var(s)
None

142
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_LIBCELL_DEF_INCOMPLETE
Severity
Error

Short Help
Instance of library cell module has pin(s) with multiple timing arcs

Description
VC SpyGlass CDC reports this tag on a library cell data pin when it is
clocked by two different clock objects. For example, this tag is reported if a
library cell data pin has at least 2 sequential arcs. The
SETUP_LIBCELL_DEF_INCOMPLETE tag indicates the risk of missing a
mode constraint on the dbcell (e.g. scan enable on a memory, which
selects between PLL/scan clocks).
This tag is not reported for any pins that has any of the following
attributes:
Constant, Quasi-static, Hanging, Clock, Reset, Power/Ground, or Internal.

What Next
Review the unconstrained pins, check the clock setup, and define the
required mode.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 set_case_analysis: Specifies a logic value on pins or ports.

Related App-var(s)
None

143
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_MULTIPLE_CONSTRAINTS
Severity
Warning

Short Help
Conflicting constraints have been specified

Description
This violation reports presence of conflicting constraints for an object in the
SDC file. This issue indicates that the design intent of specifying certain
constraint on object has been overwritten by another conflicting constraint.
Conflicting constraints impact the quality of results and might lead to
incorrect results.
For example, consider a design that has a pin named X and has the
following constraints applied:
set_case_analysis 1 { X }
create_static -name { X }
In this case, the tool reports the SETUP_MULTIPLE_CONSTRAINTS violation
indicating that both set_case_analysis and create_static constraints
are applied to the same pin.

What Next
To fix the issue, review the conflicting constraints reported. Ensure that you
define unique constraints on each object. Remove (or comment out) the
conflicting constraint definitions. If the conflicting constraint is defined
intentionally, then waive the message by providing justification for ignoring
the message.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.

144
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 define_attribute: Creates a virtual path object.


 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 set_input_delay: Associates an input port with specific clock domain(s).
 set_output_delay: Associates an output port with specific clock
domain(s).

Related App-var(s)
None

145
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_OUTPUT_MULTICLK_DRIVER
(Alias: SETUP_OUTPUT_MULTICLOCK_DRIVER)

Severity
Error

Short Help
Primary output signal is in the fan-out cone of multiple clock-domains

Description
This tag is reported when a primary output is driven by multiple clock
domains.
SETUP_OUTPUT_MULTICLK_DRIVER tag reports primary outputs which are
driven by more than one of the following elements clocked by different
clock domains:
 Flops or latches
 A non-clock pin of a black box
 A primary input port

Rule Exceptions
The SETUP_OUTPUT_MULTICLK_DRIVER tag does not report a violation if
the primary output signal:

146
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 Is defined by using the set_output_delay or set_clock_attribute


command.
 Is driven by quasi-static flip-flops.
 Is of a domain that is auto-inferred by using the
configure_unconstrained_port command. The
SETUP_OUTPUT_CONSTRAINED_MULTICLK_DRIVER tag reports a
violation in such cases.

What Next
 Check if set_case_analysis constraint is missing on any of the paths
that should be blocked.
 If the port is static, you might specify create_static constraint to
remove the violations.
 If the output port does not belong to any of the domain by which it is
being fed, make sure that synchronizers are present to synchronize such
asynchronous signals before they reach the output port.

Related Command(s)
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 set_case_analysis: Specifies a logic value on pins or ports.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_clock_attribute: Specifies the path element(s) or the attribute to
which the clock constraints are to be applied.

Related App-var(s)
None

147
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_OUTPUT_CONSTRAINED_MULTICLK_DRIVER
Severity
Warning

Short Help
Primary output (for which domain is auto-inferred using
configure_unconstrained_ports) signal is in the fan-out cone of multiple
clock-domains

Description
SETUP_OUTPUT_CONSTRAINED_MULTICLK_DRIVER tag reports primary
outputs (for which domain is auto-inferred using
configure_unconstrained_ports) which are driven by more than one of the
following elements clocked by different clock domains:
 Flops or latches
 A non-clock pin of a black box
 A primary input port

Rule Exceptions
The SETUP_OUTPUT_CONSTRAINED_MULTICLK_DRIVER tag does not
report a violation if the primary output signal:

148
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 Is defined by using the set_output_delay or set_clock_attribute


command.
 Is driven by quasi-static flip-flops.
Reason Codes
This violation reports the following reason code:
 USER_CONFIGURE_PORT

USER_CONFIGURE_PORT
This reason code is reported when the port is configured by using the
configure_unconstrained_ports command.

What Next
 Check if set_case_analysis constraint is missing on any of the paths
that should be blocked.
 If the port is static, you might specify create_static constraint to
remove the violations.
 If the output port does not belong to any of the domain by which it is
being fed, make sure that synchronizers are present to synchronize such
asynchronous signals before they reach the output port.

Related Command(s)
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 set_case_analysis: Specifies a logic value on pins or ports.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_clock_attribute: Specifies the path element(s) or the attribute to
which the clock constraints are to be applied.

Related App-var(s)
None

149
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_OVERRIDE_COMMAND
Severity
Error

Short Help
Reports if a command value is overridden.

Description
When the configure_cdc_convergence command is specified two times,
then the values of the options of the second command overrides the values
of the first. VC SpyGlass CDC reports this tag to indicate that the values of
the options specified with the first command is overridden.

What Next
Review the message and make sure that the overridden options are as per
expectations.

Related Command(s)
 configure_cdc_convergence: Configures convergence detection criteria.

Related App-var(s)
None

150
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_CONSTRAINED
Severity
Info

Short Help
Port is fully constrained

Description
VC SpyGlass CDC reports this tag for top-level input, inout, and output
ports which are fully constrained. A port is considered fully constrained if
the following constraints are defined on it:
create_clock, set_input_delay, set_output_delay,

151
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set_case_analysis, or create_static

FIGURE 18.

What Next
This is an informational message and provides information of ports in
design which are fully constrained. No action required.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.

152
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 configure_unconstrained_ports: Configures to model unconstrained


inputs and outputs of top, black-box modules, and library cells.
 create_generated_clock: Creates a generated clock object.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

153
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_IGNORED
Severity
Info

Short Help
Port can be ignored since no constraints are required

Description
VC SpyGlass CDC reports this tag for top-level ports of a design that do not
need to be constrained for CDC analysis.

FIGURE 19.

This violation can have the following reason codes:


 PORT_UNCLOCKED_SEQS
 PORT_UNCONNECTED
 PORT_NO_SEQS

PORT_UNCLOCKED_SEQS
This reason code is reported when the top-level port reaches an

154
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

unconstrained sequential element. Unconstrained sequential element is


any sequential element that receives an unconstrained clock. For example,
a sequential element with clock pin driven by a constant as shown in
Figure 20.

FIGURE 20.

What Next
Open the Incremental Schematic and back trace the clock pin of the
corresponding sequential element. Check if the clock pin is unconnected or
is driven by constant. Edit the design to provide valid clocks to sequential
elements.
Review the setup. If clock constraint is missing in the setup, define the
clock constraint.
If this is the intended behavior, ignore the violation.

PORT_UNCONNECTED
This reason code is reported for unconnected ports of a design. An
unconnected port is a port that is connected to neither sequential logic nor

155
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

combinational logic.

FIGURE 21.

What Next
This reason code is reported when the port is unconnected in the design.
Open the schematic and review the setup. Fix it in the design or if it is
intentional, ignore the violation message.

PORT_NO_SEQS
This reason code is reported for ports of a design which do not reach a
sequential element.

FIGURE 22.

156
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This reason code is reported for ports that do not reach any sequential
element. Open the schematic and review the violation. Fix it in the design.
If the violation is intentional, ignore the message.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 configure_setup_port: Configures the SETUP_PORT_* tags.
 create_generated_clock: Creates a generated clock object.
 create_reset: Defines a reset in a design.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

157
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_PARTIALLY_CONSTRAINED
Severity
Error

Short Help
Port is partially constrained

Description
This violation reports the number of top-level input, inout, and output ports
that are not fully constrained. A port is considered fully constrained if the
following constraints are defined on a port with all the required switches:
create_clock, set_input_delay, set_output_delay,
set_case_analysis, or create_static
For example, consider the schematic in Figure 23.

FIGURE 23.

In addition, consider that the following command is specified:


create_reset -name r1 {rst1}

158
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

In this case, this tag reports rst1 as partially constrained because


specifying only the create_reset command on rst1 constraints the port
partially. To fully constraint the port, specify the following commands:
create_clock -name c1 -period 10 {clk1}
create_reset -name r1 {rst1}
set_input_delay 0 -clock {c1} {rst1}

What Next
Partially constrained ports can lead to inaccurate CDC analysis. This can
result in valid crossings to be missed out during cdc checks.
Review all SDC constraints on ports that have been specified in violations
as unconstrained, incorrect constraint, partially constrained (suggested -
combo no), or combo path.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 create_generated_clock: Creates a generated clock object.
 create_reset: Defines a reset in a design.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

159
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_UNCONSTRAINED
Severity
Error

Short Help
Port has no constraints

Description
VC SpyGlass CDC reports this tag for top-level ports that have no
constraints specified on them and are reaching sequential elements having
a valid clock domain as shown in Figure 24.

160
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 24.

What Next
Unconstrained ports can cause a valid crossing to be missed out during
CDC analysis. Open the schematic and review the design. Open the SDC
file and review applied constraints. Add corresponding constraints to the
SDC file to remove this violation. If this is intentional, ignore the violation
or waive it.

Related Command(s)
 configure_cdc_data_sync: Configures the data synchronizer detection.

161
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 configure_cdc_nff_sync: Configures the multi-flop synchronizer


detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 configure_setup_port: Configures the SETUP_PORT_* tags.
 create_generated_clock: Creates a generated clock object.
 create_reset: Defines a reset in a design.
 create_static: Specifies the design object which must be treated as
quasi-static signal.
 define_attribute: Creates a virtual path object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

162
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_QUAL_CLK_DOMAIN_INFERRED
Severity
Info

Short Help
Clock domain of unconstrained qualifier signal(s) inferred from fanout
cone.

Description
VC SpyGlass CDC reports this tag when the clock domain information is not
available for a qualifier object and VC SpyGlass CDC infers the clock
domain of unconstrained qualifier signal(s) from the fanout cone of the
qualifier object.

What Next
To fix this issue, perform the following steps as appropriate:
 Verify and define the set_clock_attribute for the unconstrained RDC
qualifier signal.
 If you want to ignore such inferencing, use the following command:
configure_rdc_sync -infer_clk_domain false

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

163
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_ASSERT_MISSING
Severity
Error

Short Help
Reports sequential elements that are not asynchronously asserted by
active reset/set.

Description
VC SpyGlass CDC reports this tag for sequential elements that are not
asynchronously asserted by an active reset/set. A reset/set can be active
high or active low. When the reset/set root is asserted, the reset/set pin of
the sequential element should receive the active value. If the sequential
element does not receive the active value it will not be asserted properly
which can cause functional issues. This rule identifies these issues in a
design.
It does not report cases in which a reset is not specified for a sequential
element. It does not report a violation for the blocked path present in the
fan-in of the reset of a sequential element.
The tag violation schematic annotates the reset value if the
configure_cdc_setup_check -annotate_reset_assertion command.
You can specify this command before or after check_cdc.
The tag reports a violation in the scenarios described in the following
schematics:

164
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 25. Reset Constraint Without Sense Switch (Default sense is low)

165
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 26. Conflicting Reset Sense in RTL and Constraints

166
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 27. Black Box in Reset Path

167
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 28. Reset Blocked by Unconstrained Signal

168
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 29. Sequential Element Driving Reset Pin of Sequential

169
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

FIGURE 30. Convergence of Multiple Resets - Violating Scenario

The tag does not report a violation in the following scenario:

FIGURE 31. Convergence of multiple Resets - Non-Violating Scenario

What Next
If you do not fix this violation, basic functionality of an asynchronous reset/

170
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set is not served. In this case, the reported cell is not initialized and
therefore the design does not have the expected functionality.
To fix the violation, perform the following steps.
8. Check if -sense in create_reset constraint is properly set.
9. Check the RTL to confirm that the logic between reset pin and reset root
is correct.

Related Command(s)
 configure_cdc_asyncrst_data_sync: Configures the criteria for detecting
reset path synchronization schemes.
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 create_static: Specifies the design object which must be treated as
quasi-static signal.

Related App-var(s)
None

171
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_CONSTANT_ACTIVE
Severity
Error

Short Help
Reset/Set pin is tied to active constant value.

Description
This tag is reported when the asynchronous set/reset pins are tied to an
active constant value. If the reset pin of the sequential elements is tied to a
constant active value, the sequential elements will always be in assertion
mode.

FIGURE 32.

What Next
Perform the following steps:
10. Check the set_case_analysis command in the SDC file and modify
them if unintentional set_case_analysis commands are defined.
11. If the constant value is set in the RTL itself, review the RTL and modify if
the RTL is incorrect.

172
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
 report_net_for_combo_and_simple_seq: Default value is false.
Enables reporting of net names for combo and simple sequential db cells
in CDC report.

173
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_CONSTANT_INACTIVE
Severity
Info

Short Help
Reset/Set pin is tied to inactive constant value.

Description
This tag is reported when the asynchronous set/reset pins are tied to an
inactive constant value. If the reset pin of the sequential elements is tied to
a constant inactive value, the sequential elements will always be in
functional mode.

FIGURE 33.

What Next
Perform the following steps:
1. Check the set_case_analysis command in the SDC file and modify
them if unintentional set_case_analysis commands are defined.
2. If the constant value is set in the RTL itself, review the RTL and modify if
the RTL is incorrect.

174
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
 report_net_for_combo_and_simple_seq: Default value is false.
Enables reporting of net names for combo and simple sequential db cells
in CDC report.

175
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_CONV_COMBO
Severity
Warning

Short Help
Resets have converged on a multi input gate.

Description
VC SpyGlass CDC reports this tag if two or more resets converge on a
multi-input gate.
NOTE: VC SpyGlass CDC does not report this violation for convergence of two test debug
resets.
For example, consider the following schematic where rst2 and rst3 are
converging on an AND gate. VC SpyGlass CDC reports the
SETUP_RESET_CONV_COMBO tag in this case.

FIGURE 34.

176
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review these messages and ensure that appropriate design-mode
configuration constants are specified in the design setup and no
unintentional reset convergence is present in the design.

Related Command(s)
 configure_cdc_convergence: Configures convergence detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

Related App-var(s)
None

177
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_CONV_MUX
Severity
Warning

Short Help
Resets have converged on a multi-input Mux.

Description
VC SpyGlass CDC reports this tag if two or more resets converge on a
multi-input mux.
NOTE: VC SpyGlass CDC does not report this violation for convergence of two test debug
resets. VC SpyGlass CDC reports this tag only if at least two functional resets reach
the output pin of the Mux. The reset convergence can happen at data inputs, select
inputs, or data-select inputs,
For example, consider the following schematic where rst1 and rst2 are
converging on a MUX. VC SpyGlass CDC reports the
SETUP_RESET_CONV_MUX tag in this case.

FIGURE 35.

178
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review these messages and ensure that appropriate design-mode
configuration constants are specified in the design setup and no
unintentional reset convergence is present in the design.

Related Command(s)
 configure_cdc_convergence: Configures convergence detection criteria.
 configure_cdc_static: Configures quasi-static signals for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

179
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_OVERLAP
Severity
Warning

Short Help
One reset has reached another reset.

Description
VC SpyGlass CDC reports this tag when a reset overlaps with another
reset.
Note that if the configure_reset_propagation -ignore_reset_overlap
command is set to true, the SETUP_RESET_OVERLAP tag does not report
a violation.
NOTE: VC SpyGlass CDC does not report this violation for overlapping test debug resets.
In the following example, the resets are defined as:
create_reset -async -sense low {rst}
create_reset -async -sense low {tmp1}
Here, tmp1 is the net which is pointed by RESET_2 locater in the schematic.
VC SpyGlass CDC reports this violation because the two resets are

180
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

overlapping.

FIGURE 36.

What Next
In this case, reset propagation stops along the path where a reset reaches
another reset of a different domain. This may result in an improper reset
domain crossing analysis. Make necessary changes to resolve the
overlapping.

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

181
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_PROPAGATED
Severity
Info

Short Help
Reset reaches a set/reset pin of a sequential.

Description
VC SpyGlass generates this tag to report propagation of resets defined with
the create_reset command in SDC file.

What Next
This is an informational message indicating that the tool has propagated a
reset that is defined by using the create_reset command.

Related Command(s)
 create_reset: Defines a reset in a design.

Related App-var(s)
None

182
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_UNDECL
Severity
Error

Short Help
Reset/Set pin does not receive any asynchronous user-defined reset.

Description
This tag is reported when there are unconstrained asynchronous set/reset
pins in the design. VC SpyGlass CDC considers a set/reset pin as
unconstrained if the net is undeclared, unconnected, or if the net is
unconstrained due to black box module on its path.
VC SpyGlass CDC does not consider the registers/flops, for which these
violations are reported, as a source for RDC analysis.
The tag reports the following reason codes:
 UNDECLARED
 UNCONNECTED

UNDECLARED
VC SpyGlass CDC reports this reason code when the reset input of a
sequential element does not receive any reset because of an unconstrained

183
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

net.

FIGURE 37.

What Next
To fix this issue, use the following commands to infer resets:
infer_setup -type reset -sync_resets false -full
write_inferred_setup -file tool_inferred_resets.sdc -type reset
Review the file and then read the constraints by using the following
command:
read_sdc tool_inferred_resets.sdc

UNCONNECTED
VC SpyGlass CDC reports this reason code when the reset input of a

184
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

sequential element is unconstrained due to unconnected net.

FIGURE 38.

What Next
Review the RTL for the unconnected net and modify if the RTL is incorrect.

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

185
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CLK_NOTFOUND
Severity
Error

Short Help
SDC clock specified in SDC command does not exist

Description
VC SpyGlass CDC reports this tag if an undefined clock is referred in SDC/
Tcl file. You must define a clock by using either the create_clock or the
create_generated_clock command before referring the clock in other
SDC commands. For example, consider the following commands:
vc_static_shell> set_clock_groups -group C1 -group C6
In this case, VC SpyGlass CDC reports this tag if the C6 SDC clock specified
with the set_clock_groups SDC command does not exist.

What Next
Without fixing such problem, the setup might not be correct because the
violating SDC command is ignored for CDC analysis. To fix this issue,
perform the following as appropriate:
 If the file containing such clock definitions is not provided to the tool,
add this SDC file in setup.
 If the clock declaration is violated for non-existence by the tool, perform
steps to fix non-existence issue of the violating clock object.
 In case you missed to declare this clock, declare the clock by using
create_clock or create-generated_clock.
 If such error is expected, then waive the violation.

Related Command(s)
None

Related App-var(s)
None

186
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CLKGRP_IGNORED
Severity
Warning

Short Help
The -physically_exclusive or the -logically_exclusive arguments
are used with the set_clock_groups command

Description
VC SpyGlass CDC reports this tag if the -physically_exclusive or the -
logically_exclusive arguments are used with the set_clock_groups
command in the constraint file. Such commands are ignored for CDC
analysis.
To define the clock relationship, use the set_clock_groups command with
-asynchronous argument.

What Next
Check if the -physically_exclusive or the -logically_exclusive
arguments are used with the set_clock_groups command and remove
them. Instead, use the -asynchronous argument to specify the clocks as
asynchronous as shown in the following command:
set_clock_groups -group {clk1} -group {clk2 clk3} -asynchronous

Related Command(s)
None

Related App-var(s)
None

187
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CLKGRP_INCOMPLETE
Severity
Warning

Short Help
Incomplete set_clock_groups command

Description
VC SpyGlass CDC reports this tag when clock groupings specified by using
multiple set_clock_groups is conflicting. The count of this violation tag is
the same as the number of set_clock_groups which are incomplete.
By default, this tag is disabled. Use configure_cdc_tag -enable option to
enable this tag.

What Next
Review the missing clock in groups of set_clock_groups constraint,
otherwise VC SpyGlass CDC groups all the clocks to the same clock
domain.

Related Command(s)
None

Related App-var(s)
None

188
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CLKGRP_INVALID
Severity
Error

Short Help
Same clock object used multiple times in set_clock_groups or clock group
type is missing

Description
VC SpyGlass CDC reports this tag if the clock group defined by using the
set_clock_groups command is invalid. A valid definition of this command
includes the type of clock group, such as -asynchronous, and a non-
overlapping list of clock definitions by using the -group option.
This tag reports the following reason codes:
 SAME_CLK_MULTI_GRPS
 CLK_GRP_TYPE_MISSING
 CONFLICTING_CLK_GRP_INFO

SAME_CLK_MULTI_GRPS
Description
This reason code appears if the same clock object is used multiple times in
set_clock_groups command.

What Next
Command is ignored if this reason code is flagged. Resolve the conflict by
removing same object specified in different groups.

CLK_GRP_TYPE_MISSING
Description
This reason code appears if type of clock group is missing in

189
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set_clock_groups command.

What Next
Command is ignored if this reason code is flagged. The set_clock_groups
command must have one of the options, such as -physically_exclusive/
-logically_exclusive/-asynchronous type, specified. To resolve this
issue, specify the correct group type in the set_clock_groups command.

CONFLICTING_CLK_GRP_INFO
Description
This reason code appears if multiple SDC commands with conflicting clock
grouping information is specified.

What Next
Review the set_clock_groups commands having conflicting clock group
information and fix it.

Related Command(s)
None

Related App-var(s)
None

190
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CLKNAME_MISSING
Severity
Error

Short Help
Source object or -name missing in create_clock or
create_generated_clock commands

Description
VC SpyGlass CDC reports this tag if the SDC clock name is not specified by
using the -name option in the create_clock and create_generated_clock
commands.
The -name argument is optional in these commands. In case this option is
not specified, the clock is created by the name of the first clock root.
However, for creating virtual SDC clocks, clock root need not be specified.
In this case, -name must be present in the create commands.

What Next
To resolve this, specify the -name argument with the create_clock and the
create_generated_clock commands.

Related Command(s)
None

Related App-var(s)
None

191
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CMD_IGNORED
Severity
Warning

Short Help
SDC commands ignored

Description
This tag appears if the SDC commands are not considered for analysis

What Next
Review set_clock_groups SDC command and fix it so that it is considered
for analysis.

Related Command(s)
None

Related App-var(s)
None

192
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_CMD_OVERWRITTEN
Severity
Warning

Short Help
SDC command overwritten by subsequent SDC command with same name.

Description
This violation is reported when an existing SDC command is over written
with a new one. An existing SDC command can get overwritten if the SDC
command is specified multiple times in the SDC file.
For example, consider the following commands:
vc_static_shell> create_clock -name C7 RG1/QN -period 1
1
vc_static_shell> create_clock -name C7 RGCLKGI1/Q -period 1
1

What Next
This message informs the user that an existing SDC command is over
written. Review the SDC commands mentioned in violation message. If
intentional, waive the violation message. Else, comment out the
inappropriate SDC command.

Related Command(s)
None

Related App-var(s)
None

193
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_EMPTY_CLKGRP
Severity
Error

Short Help
Empty clock groups detected

Description
VC SpyGlass CDC reports this tag if a group defined as part of
set_clock_groups command is either empty which means no clock is
listed as part of group or all the listed clocks do not exist in the design.
For example, consider the following example where no clock is listed in the
clock group:
vc_static_shell> set_clock_groups -asynchronous -group {}
In this case, VC SpyGlass CDC reports this tag because no clock is listed in
the clock group.
The following snippet shows an example where clk10 listed in the group is
not defined:
vc_static_shell> set_clock_groups -asynchronous -group
{clk10}
SDC clock 'clk10' specified in SDC command 'set_clock_groups'
does not exist

What Next
To resolve this, review the set_clock_groups command and fix the non-
existent clocks or list the clocks in the clock group.

Related Command(s)
None

Related App-var(s)
None

194
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_GENCLK_INVALID
Severity
Warning

Short Help
Generated clock has no path to its source clock, will be ignored for RDC
analysis.

Description
VC SpyGlass CDC reports this tag if the path, specified with the
create_clock or the create_generated_clock commands, between the
given source object and destination (master_clock) is invalid. For
example, consider the following command:
vc_static_shell> create_generated_clock RGCLKGI1/Q -source
rst1 -master_clock C8
In this case, VC SpyGlass CDC reports this tag if the path between the
rst1 source and the C8 destination is an invalid path.

What Next
Specify the appropriate destination and source objects so that the specified
generated clock is valid.

Related Command(s)
None

Related App-var(s)
None

195
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_OBJECT_NONEXIST
Severity
Error

Short Help
Object specified in the SDC command does not exist.

Description
VC SpyGlass CDC reports this tag if, while reading the SDC file, the tool
encounters a design object specified in the SDC command that does not
exist in the design. For example, consider the following command:
vc_static_shell> set_false_path -from obj1
In this case, the tool reports the SETUP_SDC_OBJECT_NONEXIST tag if the
obj1 object does not exist in the design.

What Next
To fix this issue, perform the following as appropriate:
 Use the design query in Tcl shell to check if relevant design hierarchy
exists. It is possible that due to missing RTL definitions, there are black
boxes in design which is causing such design objects to be non-existent.
In such cases, provide the missing RTL definitions.
 Check if the design object name has been spelled incorrectly and correct
it by editing the SDC file.
 If missing design object is intentional, then comment out the violating
SDC command OR waive this violation.

Related Command(s)
None

Related App-var(s)
None

196
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_OBJECT_NOTFOUND
Severity
Error

Short Help
Objects specified with SDC command not found in design

Description
VC SpyGlass CDC reports this tag when objects specified in SDC
commands cannot be found in the design. For example, the
create_generated_clock command expects a clock for the -
master_clock option.

What Next
Without fixing this problem, SDC setup may be incorrect. To fix this issue,
specify the correct SDC objects.

Related Command(s)
None

Related App-var(s)
None

197
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_DUTYCYCLE_INVALID
Severity
Error

Short Help
Duty cycle option is invalid in the create_generated_clock SDC command

Description
VC SpyGlass CDC reports this tag when an invalid duty cycle option is
specified with the create_generated_clock command. Duty cycle
becomes invalid when a negative value is specified.
For example, consider the following command which has a negative value
for the -duty_cycle option:
vc_static_shell> create_generated_clock RGCLKGI1/Q -source RG1/
QN -master_clock RG1/QN -duty_cycle -1

What Next
Without fixing this problem, SDC setup may be incorrect. To fix this issue,
specify a non-negative value for the -duty_cycle option.

Related Command(s)
None

Related App-var(s)
None

198
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_OPTIONS_INCOMPLETE
Severity
Errors

Short Help
Inter dependent options of SDC commands missing

Description
VC SpyGlass CDC reports this tag when the SDC command have missing
dependent options.
For example, the create_clock -add option requires that the -name option
is specified. This tag is reported if any of the following commands are
specified:
create_clock -name clk1 -period 10 -waveform {0 5} [get_clocks
clk1] -- > -add option is missing.
create_clock -add -period 20 -waveform {0 10} [get_clocks clk1]
-- > -name option is missing.

What Next
Review the SDC commands mentioned in the violation message and
provide the mandatory option for SDC message or specify the dependent
option. If corresponding SDC command is not intentional in design,
comment out the SDC command.

Related Command(s)
None

Related App-var(s)
None

199
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SDC_RST_SENSE_MISSING
(Alias: SETUP_SDC_RESET_SENSE_MISSING)

Severity
Warning

Short Help
The sense of the user reset is not specified.

Description
VC SpyGlass CDC reports this tag when the user-specified create_reset
command does not have sense specified by the user. For example, consider
the following command:
create_reset r1 -async {rst1}
In this case, VC SpyGlass CDC reports this tag because no information is
provided about the active value of the r1 reset.

What Next
To fix this issue, specify sense [low/ high/any] with the create_reset
command as shown below:
create_reset r1 -async {rst1} -sense low

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

200
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SYNC_CLOCK_OVERLAP
Severity
Info

Short Help
Two or more clocks from same domain overlap

Description
VC SpyGlass reports this tag when two or more synchronous clocks
converge on combinational gates. This violation can have the following
reason codes:
 MULT_SYNC_CLK_MUX
 MULT_SYNC_CLKGATE
 MUX_DRIVING_REDUNDANT_LOGIC
 COMBO_DRIVING_REDUNDANT_LOGIC

MULT_SYNC_CLK_MUX
This reason code is reported when two or more synchronous clock signals
converge on a MUX.
For example, consider the schematic in Figure 39 where clk3 and clk4 are
synchronous clocks. By default, this reason code is reported if the output of
the MUX (where clocks converge) is captured by the synchronous clock pin

201
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

of a sequential element.

FIGURE 39.

What Next
This is an informational message to highlight the merging points of
synchronized clocks. Review the schematic and check the MUX where
synchronous clock signals converge with the unconstrained select signal.
You might want to add an appropriate case analysis value to select a single
clock.

MULT_SYNC_CLKGATE
This reason code is reported when two or more synchronous clock signals
converge on combinational logic other than a MUX. For example, consider
the schematic in Figure 40 where clk1 and clk2 are synchronous clocks
that are the inputs of an AND gate. The output of the AND gate is captured

202
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

by the synchronous clock pin of a sequential element.

FIGURE 40.

What Next
This is an informational message to highlight the merging point of
synchronized clocks on combinational logic other than MUX. Review the
convergence gate and make sure that it is intentional. Otherwise, change
the logic to eliminate it. You can also use the set_case_analysis
command on appropriate signals in the SDC file.

MUX_DRIVING_REDUNDANT_LOGIC
This reason code is reported when two or more synchronous clock signals
converge on a mux which is driving a redundant logic in its fanout.
For example, consider the following schematic which has a MUX with direct
multiple clocks and a hanging output.

203
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This might result in inaccurate CDC analysis because the required clock is
not selected in the design. Open the schematic and review the convergence
logic and make sure that it is intentional. Else, change the logic to
eliminate it.

COMBO_DRIVING_REDUNDANT_LOGIC
This reason code is reported when two or more synchronous clock signals
converge on a combinational logic that is driving a redundant logic in its
fanout.
For example, consider the following schematic which has a combo gate
with direct multiple clocks and a hanging output.

204
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This might result in inaccurate CDC analysis because the required clock is
not selected in the design. Open the schematic and review the convergence
logic and make sure that it is intentional. Otherwise, change the logic to
eliminate it.

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.
 configure_glitch_free_cells: Configures cells to control pessimism in
glitch analysis.
 create_clock: Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

205
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SYNC_CLOCK_OVERLAP_CONSTRAINED
Severity
Info

Short Help
Two or more clocks from same domain overlap

Description
VC SpyGlass reports this tag when two or more synchronous clocks
converge on a combinational gate which is a:
 Mux with constrained SELECT
 Combo and its output drives another clock
This violation can have the following reason codes:
 MUX_SELPIN_CONSTRAINED (for MUXs with constrained Select)
 MUX_OUTPUT_CLOCK (for MUXs driving another clock)
 COMBO_OUTPUT_CLOCK (for Combo-gates driving another clock)

MUX_SELPIN_CONSTRAINED
This reason code is reported if same domain clocks reach two different
input pins of a MUX and the select pin of the mux is constrained. For
example, consider the following schematic.

206
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This is an informational message for review purpose.

MUX_OUTPUT_CLOCK
This reason code is reported if same domain clocks converge on a MUX
from different input pins and the output of the mux is driving another
clock. For example, consider the following schematic.

207
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
This is an informational message for review purpose.

COMBO_OUTPUT_CLOCK
This reason code is reported if same domain clocks converge on a COMBO
gate and the output of the gate is driving another clock. For example,
consider the following schematic.

What Next
This is an informational message for review purpose.

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.
 configure_glitch_free_cells: Configures cells to control pessimism in
glitch analysis.
 create_clock: Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.

208
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 set_clock_sense: Stops the propagation of specified clocks on the


objects with the specified polarity.

Related App-var(s)
None

209
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SYNC_CLOCK_OVERWRITE
Severity
Info

Short Help
User clock propagates to another user clock which has synchronous
relationship with the propagating clock

Description
VC SpyGlass CDC reports this tag if a user-defined clock propagates to
another user-defined clock that has a synchronous relationship with the
propagating clock. The propagation of the primary user-defined clock that
propagated to the overwriting clock would be stopped at the point where
the overwriting clock is defined. Only the overwriting clock propagates
beyond this point in the design as shown in the following schematic.

What Next
Check if stopping the propagation of the primary clock by defining the
other synchronous clock on its path is as per the design intent. If not,

210
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

remove the overwriting clock.


Also check if the primary clock should have propagated to this point or
should have stopped earlier in the path.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

211
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_INFER
Severity
Info

Short Help
Reset MasterResetRoot has been inferred by the tool.

Description
VC SpyGlass CDC generates this tag to report inferred resets in a design.
This is an informational message about the resets inferred and used in
design analysis.
If you need to disable this violation, use the following command before
executing the infer_setup command:
configure_cdc_tag -disable -tag SETUP_RESET_INFER

What Next
This is an informational message about the resets inferred in the design.

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

212
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_SYNCRESET_UNUSED
Severity
Warning

Short Help
User-defined synchronous reset is not driving any sequential element.

Description
VC SpyGlass CDC generates this tag to report unused synchronized resets
that are defined with the create_reset command in SDC file. This warning
indicates that the design intent of specifying synchronous reset constraint
on an object is not met in the design.
This tag reports the following reason codes:
 BLOCKED_BY_RESET
 HANGING_FANOUT
 NON_SEQ_FANOUT
 BLOCKED_BY_CONSTANT

BLOCKED_BY_RESET
This reason code is reported when sync reset propagation is blocked by
overlapping reset as shown in the following schematic.

213
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
Review your sync reset constraints. If the reset is defined intentionally and
would be used in more mature version of RTL design, ignore it for now or
add a waiver to filter this violation.

HANGING_FANOUT
This reason code is reported when sync reset propagation is blocked by a
hanging fanout as shown in the following schematic.

What Next
Review the sync reset constraints. If the reset is defined intentionally and
would be used in more mature version of RTL design, ignore it for now or

214
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

add a waiver to filter this violation.

NON_SEQ_FANOUT
This reason code is reported when sync reset propagation is blocked by a
non-sequential fanout, such as the enable of a tri-state buffer as shown in
the following schematic.

What Next
Review the sync reset constraints. If the reset is defined intentionally and
would be used in more mature version of RTL design, ignore it for now or
add a waiver to filter this violation.

BLOCKED_BY_CONSTANT
This reason code is reported when sync reset propagation is blocked due to

215
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

a constant value as shown in the following schematic.

What Next
Review the sync reset constraints and the set_case_analysis constraints.
If the reset is defined intentionally and would be used in more mature
version of RTL design, ignore it for now or add a waiver to filter this
violation.

Related Command(s)
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

216
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_COMBO_MISMATCH
Severity
Warning

Short Help
Design contains combo mismatches at output ports.

Description
VC SpyGlass CDC generates this tag for a sequential source-destination
pair if:
 The set_clock_attribute -combo no is specified on any output or
inout port and the port is driven by combinational logic in its fanin.
 The set_clock_attribute -combo yes is specified on any output or
inout port and the port is not driven by combinational logic in its fanin.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.
For example, consider the following schematic.

In addition, consider the following command specifications:


set_constraints_scope -module {top}
define_attribute -name vc_path1

217
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set_clock_attribute vc_path1 -clock_objects {clk1} -combo no


apply_attribute vc_path1 -objects {out1}
end_constraints_scope
In this case, the tag reports a violation because set_clock_attribute -
combo no is specified on the out1 output port and the U1/out sequential
element exists in the fanin of the out1 port which has the I_AND_out AND
gate in its path.

What Next
If you do not fix this violation, it might result in an incorrect setup at the
block level. To fix this mismatch, perform any of the following based on the
design intent:
 Remove the -combo no argument from the set_clock_attribute
constraint.
 Analyze the combinational logic between the sequential element and
output/inout port.
 Remove the -combo yes argument from the set_clock_attribute
constraint.

Related Command(s)
 define_attribute: Creates a virtual path object.
 set_clock_attribute: Specifies the path element(s) or the attribute to
which the clock constraints are to be applied.
 apply_attribute: Specifies the pins to which the specified virtual nodes
are applied.

Related App-var(s)
None

218
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_QUASI_STATIC_MISMATCH
Severity
Warning

Short Help
Design contains quasi-static mismatches at output ports.

Description
The SETUP_PORT_QUASI_STATIC_MISMATCH tag checks for quasi-static
mismatch at output or inout ports. VC SpyGlass CDC reports this tag if an
user has defined a quasi_static constraint on a particular output/inout port
and none of the quasi_static constraint is propagated to that port.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
If you do not fix this violation, it results in an incorrect setup at the block
level.
To debug and fix this violation, perform the following steps:
 Identify the problematic output ports by referring the rule-based
spreadsheet for the top module.
 If any quasi_static value is not propagated to an output/inout port on
which the quasi_static constraint is defined, remove the quasi_static
constraint from that port.

219
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

Related Command(s)
None

Related App-var(s)
None

220
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_DATA_MISMATCH
Severity
Error

Short Help
Design contains data mismatches at output ports.

Description
The SETUP_PORT_DATA_MISMATCH tag reports a violation if an output
port is defined in a data domain by using the set_clock_attribute or the
set_output_delay commands but is not driven by any data domain signal
from the fan-in.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
If you do not fix this violation, it results in an incorrect setup at the block
level. To debug and fix this violation, check the constraints specified on the
output port and correct it. Also, check the fan-in logic of the output port.

Related Command(s)
None

Related App-var(s)
None

221
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_PORT_CASE_ANALYSIS_MISMATCH
Severity
Warning

Short Help
Design contains case analysis mismatches at output ports.

Description
The SETUP_PORT_CASE_ANALYSIS_MISMATCH tag checks for case
analysis mismatch at output or inout ports. VC SpyGlass CDC reports the
top module output ports on which user-defined set_case_analysis value
differs from the propagated value.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
If you do not fix this violation, the constrained port will pass incorrect
information to other interacting modules when these modules are used at
the SoC level.
To debug and fix this violation, perform the following steps:
 Identify the problematic output ports by referring the rule-based
spreadsheet for the top module.
 If any set_case_analysis value is not propagated to an output port on
which set_case_analysis constraint is defined, remove the

222
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

set_case_analysis constraint from that port. Else, set the value of the
specified set_case_analysis constraint so that it equals to the
propagated value.
 If the specified constraint is correct, verify the fanin cone for incorrect
propagation of the constraint.

Related Command(s)
None

Related App-var(s)
None

223
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_RESET_DRIVING_NON_ASYNC_PIN
Severity
Warning

Short Help
Reports asynchronous resets used as non-reset signals.

Description
VC SpyGlass CDC reports this tag for asynchronous resets that drive any of
the following objects:
 Data pin of sequential elements
 Enable pin of sequential elements
 Primary ports
 Black boxes
 Library cells
For example, consider the following schematic where rst1 is driving the D
pin of the q2_reg sequential element. VC SpyGlass CDC reports the
SETUP_RESET_DRIVING_NON_ASYNC_PIN tag in this case.

224
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

What Next
If you do not fix this violation, your design may contain functional issues.
Analyze if this is the desired behavior and make the required changes as
appropriate.

Related Command(s)
 configure_reset_propagation: Configures reset propagation.
 create_reset: Defines a reset in a design.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_reset_sense: Specifies the reset propagation stop points.

Related App-var(s)
None

225
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

SETUP_DOMAIN_INFER
(Alias: SETUP_CLOCK_PROPAGATED)

Severity
Info

Short Help
Clock domain ClkDomainId, consisting of the clock(s) ClksPropagated,
has been inferred by the tool. It reaches to SeqPinReachable sequential
pin(s)

Description
VC SpyGlass CDC reports this tag when a clock domain is inferred by the
tool based on SDC commands and other user inputs.
For multiple clock definitions specified while creating setup, the VC
SpyGlass CDC creates an elaborated clock domain list while propagating
the clocks. The informational message is displayed for each inferred
domain.

What Next
This is an informational message indicating that the tool has inferred a
clock domain based on the SDC commands and other user inputs. The
resulting inferred clock domain is considered for subsequent CDC analysis.
No additional user action is usually required.
If required, review the design at the point where the clock was inferred and
ensure the resulting clock is consistent with the required clock specification
for analysis. If the clock inference is believed to be erroneous, review the
source of the clock inference, such as the SDC clock specification, user
setup commands, or identification of a composite clock.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines
the specified source_objects as clock sources.
 create_generated_clock: Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.

226
Synopsys, Inc. Feedbac
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

 set_clock_groups: Specifies clock relationships.


 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

227
Feedbac Synopsys, Inc.
Creating and Verifying CDC Setup

Debugging CDC Setup Violations

228
Synopsys, Inc. Feedbac
VC SpyGlass CDC
Integrity Checks

This chapter is organized into the following sections:


 About Integrity Checks
 Debugging CDC Integrity Violations

About Integrity Checks


This step ensures that clocks and resets are properly defined, and they are
free of glitches, race conditions, and other hazards.

229
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

Debugging CDC Integrity Violations


The following section describes all the violations reported for integrity
checks.

230
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_CLKGATE_GLITCH
(Alias: INTEGRITY_CLOCKGATE_GLITCH)

Severity
Error

Short Help
Clock is not gated after latching the enable in the inactive half of the clock
cycle

Description
VC SpyGlass CDC reports this tag if a clock signal is gated by using the
AND/OR/NOR/NAND gates and an enable signal is used directly without
latching the enable signal. The gating enable signal must be latched with
an inverted clock going to the enable pin of the latch. Latching the clock
enable in the inactive half of the clock cycle ensures that clock-gating setup
requirement is always met. Use the configure_cdc_integrity_checks
command to configure this tag.

What Next
Gated clocks might result in timing hazards, such as glitches that can lead

231
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

to duty cycle distortion.


It is recommended to change the gating signal for a clock when the clock is
inactive. If a gating signal is functionally changed while the clock is active,
there is a possibility of a glitch.
To avoid glitches in the clock path, the gating enable signal should be
latched with an inverted clock going to the enable pin of the latch. Latching
the clock enable in the inactive half of the clock cycle ensures that clock-
gating setup requirement is always met.

Related Command(s)
None

Related App-var(s)
None

232
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_CLOCK_AS_NON_CLOCK
Severity
Warning

Short Help
Reports clocks that are being used as non-clocks

Description
VC SpyGlass CDC reports this tag if clock signals are used as non-clock
signal.
The INTEGRITY_CLOCK_AS_NON_CLOCK tag reports violations for the
following objects:
 Data pin of a flip-flop, latch, or library cell
 Enable pin of a flip-flop
 Reset pin of a flip-flop, latch, or library cell
 Black box
Consider the following schematic:

233
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

In the above schematic, the clk2 clock signal is used as clock at s3_reg
and data in the s1_reg flop.
Reason Codes
NA

What Next
If you do not fix this violation, your design may contain functional issues.
To fix this violation, avoid using clocks as non-clock signals.

Related Command(s)
None

Related App-var(s)
None

234
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_ASYNCRST_COMBO_MUX
(Alias: INTEGRITY_ASYNCRESET_COMBO_MUX)

Severity
Warning

Short Help
Reports asynchronous reset pins driven by a combinational logic or a mux

Description
VC SpyGlass CDC reports this tag if an asynchronous reset/set pins are
driven by a combinational logic or a mux.
Set the following command to report a violation when the asynchronous
set/reset pins of a sequential element are driven by a mux. By default,
violation is not reported for mux.
configure_cdc_setup_check -report_reset_path_mux
The INTEGRITY_ASYNCRST_COMBO_MUX tag reports one violation for each
reset cone.

235
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

Consider the following schematic:

In the above schematic, the s1_reg and the s2_reg reset pins are driven
by a combinational logic. Therefore, the INTEGRITY_ASYNCRST_COMBO_MUX
tag reports one sequential element per reset cone.

What Next
If you do not fix this violation, there is a possibility of glitches on the set/
reset signal.
To fix this issue, eliminate the combinational logic or mux found in the
reset path.

Related Command(s)
None

Related App-var(s)
None

236
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_MUXRECONV_CLOCK_GLITCH
Severity
Info

Short Help
Reports clock signals that pass through a MUX and reconverge back on the
same MUX

Description
VC SpyGlass CDC reports this tag if clock signals that pass through a MUX,
and reconverges back on the same MUX. In such cases, output of a MUX
after passing through a clock-pin of flip-flop/latches reconverges back on
the same MUX that results in creation of a glitch.
Consider the following schematic:

In the above schematic, the clock clk1 reaches the I_MUX_mux_out at D0


pin and reconverges back on the same mux at D1 pin. Therefore, the
INTEGRITY_MUXRECONV_CLOCK_GLITCH tag reports a violation.

What Next
If you do not fix this violation, there is a possibility of a glitch in the clock
path.

237
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

To fix the violation and avoid glitches in the clock path, constraint the
select signal of the MUX to block the re-convergence path or use glitch free
MUXes.

Related Command(s)
None

Related App-var(s)
None

238
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_CLKRST_OUTPUT_RACE
(Alias: INTEGRITY_CLOCKRESET_OUTPUT_RACE)

Severity
Warning

Short Help
Potential race between flop and its pins

Description
VC SpyGlass CDC reports this tag if potential race conditions are detected
between the output of a flip-flop and its clock/reset pins. Race conditions
can occur if a feedback path exists between the output of a flip-flop to its
clock/reset pins.
Use the configure_cdc_integrity_checks command to configure this tag.

What Next
If race conditions exist, timing and behavior in such cases can be difficult
to predict.
To fix the issue, review the violation schematic and check the path between
the output of the flip-flop and its clock/reset pin. Next, check if the
constraints are applied properly on the path. Else, apply the missing
constraints, such as set_case_analysis.

Related Command(s)
None

Related App-var(s)
None

239
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_CLOCK_RECONVERGE
Severity
Error

Short Help
Clock with multiple fanout converges on re-convergence point

Description
VC SpyGlass CDC reports this tag if clocks with multiple converging fan-
outs are detected. It also reports a violation if convergence is at a mux
select.
This violation can have the following reason codes:
 MULT_SYNC_CLKGATE
 MULT_SYNC_CLK_MUX
 MUX_SELPIN_CONSTRAINED

MULT_SYNC_CLKGATE
This reason code is reported when the same clock converges on combo
gate. For example, consider the schematic in Figure 41 where clk3

240
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

diverges and then converges on the gate_gf3 gate.

FIGURE 41.

What Next
In this case, a clock signal can have different delays along different paths
before it re-converges. This might result in glitches or an incorrect clock
waveform. To fix this issue, check the set_case_analysis in the converging
path and correct it.

MULT_SYNC_CLK_MUX
This reason code is reported when the same clock converges on a MUX. For
example, consider the schematic in Figure 42 where clk1 diverges and
then converges on the mux_gf1 MUX.

241
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

FIGURE 42.

What Next
In this case, a clock signal can have different delays along different paths
before it re-converges. This might result in glitches or an incorrect clock
waveform. To fix this issue, check the set_case_analysis in the converging
path and correct it.

MUX_SELPIN_CONSTRAINED
This reason code is reported when the same clock converges on a Mux that
has a constant select.
For example, consider the schematic in Figure 43 where clk3 diverges and
then converges on the mux_ngf3 MUX and the select pin of the MUX has a
constant defined on it.

242
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

FIGURE 43.

What Next
In this case, a clock signal can have different delays along different paths
before it re-converges. This might result in glitches or an incorrect clock
waveform. To fix this issue, check the set_case_analysis in the converging
path and correct it.

Related Command(s)
 configure_cdc_setup_check: Configures parameters of setup checks.
 configure_glitch_free_cells: Configures cells to control pessimism in
glitch analysis.

Related App-var(s)
None

243
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_CLOCK_RESET_RACE
Severity
Warning

Short Help
Potential race between clock and pins of a flop

Description
VC SpyGlass CDC reports this tag if race conditions exist between clock and
reset pins of a flip-flop. Race conditions occasionally occur when clock and
reset signals of a flip-flop conflict. In such cases, gate output takes a finite,
non-zero amount of time to react to any change in inputs. Therefore,
simultaneous propagation of clock and reset signals produce undesired
outputs.
If you do not fix this violation, timing, and therefore behavior might be
difficult to predict.
For example, consider the following schematic.

In this case, VC SpyGlass CDC reports the


INTEGRITY_CLOCK_RESET_RACE tag because race condition exists
between the clock and reset pins of the q flip-flop.

244
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

What Next
To fix this issue, perform the following:
 Review the schematic and check the path from the output of the flip-flop
to the clock/reset pin.
 Check that the constraints are applied properly on the path. Else, apply
the missing constraints, such as set_case_analysis.

Related Command(s)
 create_clock:Creates a clock object in the current design and defines the
specified source_objects as clock sources.
 create_generated_clock:Creates a generated clock object.
 set_case_analysis: Specifies a logic value on pins or ports.
 set_clock_groups: Specifies clock relationships.
 set_clock_sense: Stops the propagation of specified clocks on the
objects with the specified polarity.

Related App-var(s)
None

245
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_RESET_RECONVERGE
(Alias: INTEGRITY_RESET_RECONVERGE_GLITCH)

Severity
Warning

Short Help
Reset signal converges at combinational type reconvergence point.

Description
VC SpyGlass CDC reports this tag if an asynchronous reset signal first
diverges and then reconverges before being used. VC SpyGlass CDC
checks for only combinational convergences and does not report this tag if
a reset converges after sequential elements.
VC SpyGlass CDC reports this tag also for derived resets that diverge and
then converge. In case of multiple paths, this tag reports convergence on
the last point with two paths. If a converging gate output is an internal net,
this tag reports the closest RTL net.

246
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

What Next
Such logic in design might cause glitch at the reset path in the design and
it might result in functional failure.
Fix the design to ensure that there are no such reconvergence paths in
reset tree before it reaches at functional flip-flops.

Related Command(s)
 configure_cdc_convergence: Configures convergence detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

247
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_UNWANTED_CELLS
Severity
Warning

Short Help
Reports unwanted cells found in clock or reset networks.

Description
VC SpyGlass CDC reports this tag for unwanted instances of cells appearing
either in clock or reset networks or in the entire design. Specify names of
allowed or disallowed cells by using the set_allowed_cells command. For
example, consider the following schematic.

In this case, AN2 should not appear in the clock or reset network. The
INTEGRITY_UNWANTED_CELLS tag reports such unwanted cells.

What Next
If you do not fix this violation, disallowed cells may result in timing issues
on clock paths. It may also change the polarity or add to delays. To fix this
violation, remove disallowed cells from clock or reset path.

Related Command(s)
 set_allowed_cells: Specifies cells that can be allowed or disallowed in
clock or reset networks.

248
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

Related App-var(s)
None

249
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_UNEXPECTED_CELLS_CLKPATH
Severity
Warning

Short Help
Reports unexpected cells, such as latches, tristate gates, or XOR/XNOR
gates found in a clock tree

Description
VC SpyGlass CDC reports this tag for unexpected cells, such as latches,
tristate gates, or XOR/XNOR gates found in a clock tree. For example,
consider the following schematic.

In this case, the INTEGRITY_UNEXPECTED_CELLS_CLKPATH tag reports a


violation because the I_XOR_q1_wire2 XOR gate is unexpected in the clock
tree.

What Next
Such cells in a clock tree may block further propagation of clock or may
change the clock behavior. Ensure that the clock tree has only the
permitted cells.

Related Command(s)
None

250
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

Related App-var(s)
None

251
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_ASYNCRESET_HIGH_AND_LOW_USAGE
Severity
Warning

Short Help
Reports asynchronous resets that are used as both active-high and active-
low

Description
VC SpyGlass CDC reports this tag for asynchronous resets that are used as
both active-high and active-low. For example, consider the following
schematic.

In this case, the INTEGRITY_ASYNCRESET_HIGH_AND_LOW_USAGE tag


reports a violation because rst2 asynchronous reset is used as both
active-high and active-low.

252
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

What Next
If you do not fix this violation, the design would fail to initialize properly. As
a result, functional analysis may not work properly in this case. Ensure that
asynchronous resets are not used as active-high and active-low
simultaneously in the design.

Related Command(s)
None

Related App-var(s)
None

253
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_SYNCRESET_HIGH_AND_LOW_USAGE
Severity
Warning

Short Help
Reports synchronous reset signals that are used as active high as well as
active low

Description
VC SpyGlass CDC reports this tag for synchronous resets that are used as
both active-high and active-low. For example, consider the following
schematic.

In this case, the INTEGRITY_SYNCRESET_HIGH_AND_LOW_USAGE tag


reports a violation because the rst synchronous resets is used as active-
high and active-low simultaneously.

254
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

What Next
Using synchronous resets as active high and active low simultaneously
always keeps some logic of a design in a reset mode and blocks data
propagation from that part. Ensure that synchronous resets are not used
as active-high and active-low simultaneously in the design.

Related Command(s)
None

Related App-var(s)
None

255
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_UNEXPECTED_CELLS_RSTPATH
Severity
Warning

Short Help
Reports latches, tristate signals, or XOR/XNOR gates in a reset tree

Description
VC SpyGlass CDC reports this tag for latches, tristate signals, or XOR/
XNOR gates in a reset tree. For example, consider the following schematic.

In this case, the INTEGRITY_UNEXPECTED_CELLS_RSTPATH tag reports a


violation because the I_XOR_ASN_8 gate is not expected in the reset tree.

What Next
Presence of latches, tristate signals, or XOR/XNOR gate in a reset tree may
block further propagation of a reset signal or may change the reset
behavior.
A reset tree should contain only permitted cells because designs are very

256
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

sensitive to resets.

Related Command(s)
None

Related App-var(s)
None

257
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_BUFINVEQUAL_CELLS_RSTPATH
Severity
Info

Short Help
Reports the cells acting as buffers or inverters in a reset tree

Description
VC SpyGlass CDC reports this tag for buffer/inverter equivalent cells in a
reset tree. This can happen in the following scenarios:
 Tristate/ Latch is permanently enabled/disabled
 Input of XOR/XNOR gate is tied to active high/low
For example, consider the following schematic.

What Next
Not fixing this violation may add to delays in a reset path. Ensure that the
reset tree has only the permitted cells.

258
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

Related Command(s)
None

Related App-var(s)
None

259
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

INTEGRITY_RESET_ASYNC_AND_SYNC_USAGE
Severity
Warning

Short Help
Reports reset signals that are used asynchronously as well as
synchronously for different flip-flops

Description
VC SpyGlass CDC reports this tag for reset signals that are used as both
asynchronous and synchronous reset signals for different flip-flops. For
example, consider the following schematic.

In this case, the INTEGRITY_RESET_ASYNC_AND_SYNC_USAGE tag


reports a violation because the rst reset is being used as both
asynchronous and synchronous reset signals for the ff and the ff2 flip-

260
Synopsys, Inc. Feedback
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

flops.

What Next
Using same reset signal asynchronously as well as synchronously may
violate some of the design requirements.

Related Command(s)
None

Related App-var(s)
None

261
Feedback Synopsys, Inc.
VC SpyGlass CDC Integrity Checks

Debugging CDC Integrity Violations

262
Synopsys, Inc. Feedback
VC SpyGlass CDC
Unsynchronized
Crossing Checks

This chapter is organized into the following sections:


 About CDC Synchronization Checks
 Performing Synchronization Checks
 Debugging CDC Synchronization Violations

263
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

About CDC Synchronization Checks

About CDC Synchronization Checks


Edges of clocks coming from the same clock domain are always aligned for
all registers in the design and for all time throughout design run. As a
result, if setup and hold time for a flip-flop input is considered, there is no
risk in capturing the data of the flip-flop throughout the design.
However, clocks from different domains might reach different flip-flops at
different times in each cycle during design run. This timing uncertainty
might cause random setup and hold-time violations. Such problems might
result in metastability.
In addition, timing paths between clocks that are not synchronous are not
timed in STA tools and therefore synchronization is required.
Metastability is the design problem in which metastable values are created
and propagated due to setup and hold-time issues in an asynchronous
crossing.
The following figure shows an example of such an issue:

Figure 5-1 Metastability Issue

To remove metastability, use the following approaches:


 Control signal synchronization
Control signals crossing clock domains are typically synchronized by
using multi-flop synchronizers. In such cases, multiple stages of flip-
flops transform the metastable values to a cleaner 0 or 1 before it is
passed to downstream logic.
 Data signal synchronization

264
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

About CDC Synchronization Checks

Data signals are synchronized by using enable techniques where the


data is first stabilized on the crossing path and then the destination flip-
flop is enabled to capture the stable data (so the setup and hold time is
not violated).
Following are some of the possible reasons for synchronization failure:
 Lack of a qualifier: No qualifier converges with the crossing. This might
be due to the presence of an unsynchronized control signal that is
intended to qualify a crossing.
 Invalid gating of the crossing with a valid qualifier: This happens for
example when the crossing and a qualifier converges on a XOR gate.
 A source diverges to multiple paths that are synchronized separately.
 A source converges with the qualifier before the qualifier feeds the
synchronizing gate.
 Two sources from different domains converge before they are
synchronized.
Some simple examples of control and data synchronizers are shown in
Figure 5-2:

265
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

About CDC Synchronization Checks

Figure 5-2 Common synchronization schemes

Refer to the reason codes of the SYNCCDC_CTRLPATH_FULL and


SYNCCDC_DATAPATH_FULL tags for the supported CDC synchronizers.

266
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Performing Synchronization Checks

Performing Synchronization Checks


To perform synchronizer detection and analysis, use the check_cdc –type
sync Tcl command.

267
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

Debugging CDC Synchronization Violations


The following section describes all the violations reported for
synchronization checks.

268
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_UNSYNC_NOSCHEME
(Alias: CDC_UNSYNC_NOSCHEME)

Severity
Error

Short Help
Unsynchronized CDC path is found.

Description
VC SpyGlass CDC reports this tag if an unsynchronized data transfer can
occur between different domain signals.
The tag reports the following reason codes:
 UPF_INSTRUMENTED
 CDC_UNSYNC_INTERNAL_CROSSING
 CDC_CLOCK_TO_D_CROSSING
 UPF_INSTRUMENTED
 NO_SYNC_METHOD

UPF_INSTRUMENTED
This reason code is reported if the crossing path is UPF instrumented.

CDC_UNSYNC_INTERNAL_CROSSING
This reason code is reported for a crossing path between two clock pins
of same lib cell.

CDC_CLOCK_TO_D_CROSSING
This reason code is reported for a crossing path when source of crossing
is a clock node.

269
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SRC_CONVERGES_ASYNC_SRC
This reason code is reported on a clock domain crossing where multiple
source domains converge on a single destination domain.

What Next
Check the source domain and ensure that there are no multiple source
domain participating in the clock-domain crossing. If this is expected,
use the ignore_multi_domain_sources = Yes setting to allow multiple
domain at source.
To hide this reason code, use the following command:
configure_cdc_nff_sync -ignore_multi_domain_sources yes
configure_cdc_reason_code -code SRC_CONVERGES_ASYNC_SRC -
hide -type full
By default, this reason code is of type "PARTIAL", you must convert this
to type "FULL" to hide it.
This reason code should be made to "full" before hiding it otherwise VC
SpyGlass CDC reports the following warning message:
[Warning] PARTIAL_REASON_CODE_HIDE: A reason code cannot be
PARTIAL and hidden at the same time

270
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

Reason code SRC_CONVERGES_ASYNC_SRC cannot be PARTIAL and


hidden at the same time
Error: 0

NO_SYNC_METHOD
This reason code is reported in any of the following cases:
 When application is not able to find any synchronizing structure at
the destination of a crossing, there is a possibility that a qualifier
should have been present but the designer forgot to add it, did not
connect it properly, or the application was not able to find the
qualifier.
 When a source converges with an invalid qualifier at some gate
 When a source converges with an unsynchronized qualifier crossing
defined by the configure_cdc_data_sync constraint.

Figure 5-3

What Next
If you know that the crossing is controlled by a valid qualifier, mark the
qualifying signal by using the configure_cdc_data_sync constraint.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.

271
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 configure_cdc_data_sync: Configures the data synchronizer detection.


 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 configure_cdc_internal_crossing: Enables reporting of internal crossings
of the specified libcell.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

272
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_CTRLPATH_FULL
(Alias: CDC_SYNC_CTRL)

Severity
Info

Short Help
Control synchronization scheme is found on the CDC path.

Description
VC SpyGlass CDC reports this tag when a control synchronization scheme
is found on the CDC path. The tag reports the following reason codes:
 SYNC_BY_NFF
 STATIC_COMBO_IN_CROSSING
 SYNC_BY_UDS

SYNC_BY_NFF
This reason code is reported when a conventional multi-flop
synchronization scheme is found on the path.

What Next
This is an information message indicating that VC SpyGlass CDC
recognizes the NFF structure with default settings or with the user-
specified configurations. No further action is required.

273
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

STATIC_COMBO_IN_CROSSING
This reason code is reported when static combo logic is found in a
crossing path.

What Next
Normally static signal is not meant to be part of CDC analysis as the
signal does not change at any instance of the design cycle, thus this
needs attention to ensure that the structure is clean without any such
path so that CDC analysis can be performed by tool.
 Check the design structure for user-defined create_static and
set_case_analysis configurations. If these configurations exist, validate
if that is as per design intent. Else, modify the design.
 Check the design structure if any combo logic output which is static in
nature feeds to synchronization structure and validate if that is as per
the design intent. If not, modify the design.

SYNC_BY_UDS
This reason code is reported if a user-specified synchronizer cell is
detected in the crossing path. For example, consider the following
command where SYNC is specified as the user-defined synchronizer:
configure_cdc_nff_sync -uds_modules SYNC

274
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
This is an information message indicating that VC SpyGlass CDC recognizes
the UDS structure with the user-specified configurations. No further action
is required.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer
detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 define_attribute: Creates a virtual path object.
 configure_cdc_internal_crossing: Enables reporting of internal crossings
of the specified libcell.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.

275
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 set_clock_relation: Specifies two synchronous points in the


asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

276
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_CTRLPATH_PARTIAL
(Alias: CDC_UNSYNC_CTRL)

Severity
Error

Short Help
Partially matched control synchronization scheme found on the CDC path.

Description
VC SpyGlass CDC reports this tag when a partially matched control
synchronization scheme is found on the CDC path.
The tag reports the following reason codes:
 NFF_DST_WITH_MULTI_FANOUTS
 NONSTATIC_COMBO_IN_CROSSING
 ASYNC_SRC_CONVERGE
 NFF_DST_SYNC_POLARITY_MISMATCH
 NFF_WITH_POTENTIAL_SYNCRESET_GATE

NFF_DST_WITH_MULTI_FANOUTS
This reason code is reported when the destination of the crossing is
driving the other paths before being synchronized

277
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check the user-specified NFF depth value. By default, it is 2. Next,
check the number of NFF reset sync structure in the design. To fix this
issue, ensure that these two values match.

NONSTATIC_COMBO_IN_CROSSING
This reason code is reported when the destination is synchronized by
Conventional Multi-Flop Synchronization Scheme, Synchronizing Cell
Synchronization Scheme, or defined by the qualifier -crossing
constraint, but there is non-static combo logic present between the
source and destination.

What Next
Check the structure if the combo logic in the crossing is intentional as
per design requirement. If not, modify the design as per the structure
by removing the combo-logic shown in the violation message.
If combo logic in the crossing is intentional as per design requirement,
specify the following configuration to allow combo logic in the crossing
and to hide the specific reason code from showing.
%vc_static_shell> configure_cdc_nff_sync -allow_combo_logic
yes

278
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

ASYNC_SRC_CONVERGE
This reason code is reported when an asynchronous source converges
before the crossing destination.

What Next
Check the multiple asynchronous source domains and qualify
appropriately. If specifying the qualifier, check if the qualifier has the
same domain as that of the destination.
Sometimes this problem could be an attempt to qualify with an
incorrectly synchronized qualifier.
It might also be the case of a qualifier that is correctly synchronized but
is not recognized by VC SpyGlass CDC. In this case, use the qualifier
constraint to mark that signal.

NFF_DST_SYNC_POLARITY_MISMATCH
This reason code is reported when a destination clock is reaching a
synchronizer clock pin with a different polarity.

279
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check if the polarity of the destination and the synchronizer are as
intended and fix the polarity accordingly.

NFF_WITH_POTENTIAL_SYNCRESET_GATE
This reason code is reported when an AND/OR gate (or an AND/OR gate
equivalent circuit) exists in the path from destination to synchronizer
flop but no synchronized reset is reaching that gate.

280
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check if the synchronized resets are specified on the AND/OR gate as
intended in the design. Use the create_reset -sync command on the
objects to specify that a synchronous reset is reaching the object.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer
detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 configure_cdc_internal_crossing: Enables reporting of internal crossings
of the specified libcell.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

281
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_IGNORE_INTERNAL_CROSSING
Severity
Info

Short Help
Reports CDC paths with internal crossings

Description
VC SpyGlass CDC reports this tag for CDC paths between two clock pins of
the same lib cell where the source and destination of the paths are
specified by using the configure_cdc_internal_crossing command. For
example, consider the following schematic.

In addition, consider the following command:


configure_cdc_internal_crossing -libcell_inst ssync1 -
src_clk_pin SRC_CLK -dest_clk_pin DST_CLK -tag
SYNCCDC_IGNORE_INTERNAL_CROSSING
In this case, VC SpyGlass CDC reports this tag because the CDC path
between the two clock pins of the same lib cell has been configured by

282
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

using the configure_cdc_internal_crossing command.

What Next
This is an information message. Check if the configuration specified with
the configure_cdc_internal_crossing command is as per the design
intent.

 configure_cdc_internal_crossing: Enables reporting of internal crossings


of the specified libcell.

Related App-Vars(s)
None

283
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_IGNOREPATH_CLOCK_MODES
Severity
Info

Short Help
Crossing paths ignored due to functionally-exclusive clock modes

Description
VC SpyGlass CDC reports this tag when a CDC crossing is ignored because
all asynchronous source/destination clock pairs are functionally exclusive.
For example, consider the schematic in Figure 5-4.

Figure 5-4

In the schematic, both c1 and c2 clocks propagate to both data_cross/Q


and data_out/Q pins. In this case, this tag is reported because there are
synchronous clocks in source and destination.

What Next
This is an informational message for review purpose.

284
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer
detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

285
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_IGNOREPATH_QUASI_STATIC
(Alias: CDC_IGNOREPATH_QUASI_STATIC)

Severity
Info

Short Help
CDC path is ignored because of a quasi-static signal

Description
VC SpyGlass CDC reports this tag when a CDC path is ignored because the
source is driven by a quasi-static signal.
The tag reports the following reason codes:
 USER_QUASI_STATIC_SRC
 INFERRED_QUASI_STATIC_SRC
 SEMI_QUASI_STATIC_SRC

USER_QUASI_STATIC_SRC
This reason code is reported if a CDC path is ignored because the source is
driven by a user-specified quasi-static signal as shown in the following
schematic.

What Next
Check if the user-specified create_static command in SDC is either an

286
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

input to the source of the CDC or is in the crossing path which makes the
CDC path quasi-static.
If this is not the design intent, remove the create_static constraint. Else,
ignore this violation.

INFERRED_QUASI_STATIC_SRC
This reason code is reported if a CDC path is ignored because the source is
driven by a quasi-static signal that is automatically inferred by VC SpyGlass
as shown in the following schematic.

What Next
Check for the reason of blocked input crossing source to avoid automatic
inferencing of quasi-static signal. For example, in the above schematic, the
constant 1 on the select pin of recirculation MUX leading to blocked input
data pin for crossing source can be avoided to prevent automatic
inferencing of quasi-static on source.

SEMI_QUASI_STATIC_SRC
This reason code is reported if a CDC path is ignored because the source is
a semi quasi-static signal.
This reason code is reported if a CDC path is ignored because the source is
driven by a user-specified quasi-static signal with the -check_glitch

287
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

option specified. For example, consider the following command and the
corresponding schematic.
create_static -name {f1/q} -check_glitch

When the create_static -check_glitch command is specified, the


crossing is marked as ignored. In addition, Glitch analysis is performed on
this crossing unlike any other ignored crossing.

What Next
Check for the reason of blocked input crossing source to avoid automatic
inferencing of quasi-static signal. For example, in the above schematic, the
constant 1 on the select pin of recirculation MUX leading to blocked input
data pin for crossing source can be avoided to prevent automatic
inferencing of quasi-static on source.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.

288
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 define_attribute: Creates a virtual path object.


 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

289
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_IGNOREPATH_CONST_SRC
(Alias: CDC_IGNOREPATH_CONST_SRC)

Severity
Warning

Short Help
Crossing path between source and destination ignored because the source
is constant

Description
VC SpyGlass CDC reports this tag for any CDC path where the source is
driven by a constant. This is because such paths are not metastable and
cannot control other logic.

What Next
Check for the following:
 If the input to the source of CDC or objects between the crossing path is
tied to constant, fix the design if this is not intended. Else, ignore the
message.

290
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 Check if the set_case_analysis command is used to set to a constant


value (0 or 1), either the input to source of CDC, or to any object in the
crossing path, is as per the design intent. If not, fix the design. Else,
ignore this message.
 Review the flip-flops and ensure that the flip-flops associated with the
reported objects are as intended.

Related Command(s)
None

Related App-var(s)
 cdc_include_constant_source_paths: Default value is false. Set the
value to true to treat cdc paths with constant input at the source as cdc
ignore path.

291
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_DATAPATH_FULL
(Alias: CDC_SYNC_DATA)

Severity
Info

Short Help
Synchronized data path found

Description
VC SpyGlass CDC reports this tag when a synchronized data path is found.
The tag reports the following reason codes:
 SYNC_AT_RECIRC_MUX
 SYNC_AT_LIBCELL_CGC
 SYNC_AT_NON_RECIRC_MUX
 SYNC_AT_BLOCKING_GATE
 UDS_USED_AS_QUALIFIER
 SYNC_AT_AUTO_INFERRED_CGC

SYNC_AT_RECIRC_MUX
This reason code is reported when a data crossing is synchronized using
MUX recirculation.

292
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

The clock domain crossing is marked as synchronized if either of the


following conditions is met:
 The MUX select pin is driven by a signal synchronized to the
destination clock domain.
 A valid synchronizer exists in any one of the paths driving the MUX
select pin and the signals in all other paths are driven either by
primary ports or the destination clock domain flip-flops and there is
no unsynchronized crossing in any of the paths.

What Next
This is an informational message related to the MUX recirculation
scheme.

SYNC_AT_LIBCELL_CGC
This reason code is reported when a crossing is synchronized using a
library cell clock gating.

293
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
This is an informational message pertaining to a lib cell-based clock
gating scheme. No action is required.

SYNC_AT_NON_RECIRC_MUX
This reason code is reported when there is a data crossing synchronized
without MUX recirculation.

294
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
This is an informational message pertaining to non-MUX recirculation
scheme. No action is required.

SYNC_AT_BLOCKING_GATE
This reason code is reported when there is data crossing synchronization
with AND logic.

What Next
This is an informational message pertaining to AND logic scheme. No
action is required.

UDS_USED_AS_QUALIFIER
This reason code is reported when an user-defined synchronizer cell is
used as a control path qualifier.

295
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
This is an informational message pertaining to user-defined
synchronizer cell.

SYNC_AT_AUTO_INFERRED_CGC
This reason code is reported when a crossing is synchronized using an
auto-detected clock gating cell.

296
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

To disable the violation, use the following command:


configure_cdc_data_sync -sync_point {and mux_select
mux_recirc sync_point_cell and_or_mux_recirc}

What Next
This is an informational message pertaining to auto-detected clock
gating cell.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer
detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_cdc_internal_crossing: Enables crossings on the source clock
pin and the destination clock pin of the specified libcell.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.

297
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 configure_unconstrained_ports: Configures to model unconstrained


inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

298
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_DATAPATH_PARTIAL
(Alias: CDC_UNSYNC_DATA)

Severity
Error

Short Help
Partially synchronized data path found

Description
VC SpyGlass CDC reports this tag when a partially matched data
synchronization scheme for CDC path from given source object to
destination object is found in the design.
The tag reports the following reason codes:
 INVALID_BLOCKING_GATE
 MUX_SELPIN_SRC
 QUAL_ON_MUX_DATAPIN
 NO_DESTDOM_SIGNAL_ON_MUX_DATAPINS
 SRC_SAME_AS_QUAL_SRC
 QUAL_CONVERGES_OTHER_SYNC_SRC
 QUAL_CONVERGES_SAME_SRC
 SRC_CONVERGES_QUAL_INSIDE_LOOP
 QUALIFIER_PROPAGATED_ACROSS_DEST
 POTENTIAL_SYNCRST_QUALIFIER

INVALID_BLOCKING_GATE
This reason code is reported when the control path cannot block the
transfer of data because of gating logic which is not valid.

299
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check the presence of following logic, which is considered as invalid,
and correct the same to make the tag to full match. Gating logic, such
as XOR gate, is considered as invalid. Replace the XOR with valid gating
logic such as AND gate.

MUX_SELPIN_SRC
This reason code is reported when the source drives the MUX select
input. This can be in a scenario where the select signal of the mux is
multi-bit and one of the bits is from the source domain itself along with
qualifier.

300
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Modify the structure so that the source does not drive the MUX select
pin.

QUAL_ON_MUX_DATAPIN
This reason code is reported when both source signal and control path
reach MUX's data pins. This reason code is flagged in the following
scenario as the qualifier signal (control) drives the mux data input
rather than the mux select pin. As a result, the qualifier does not
synchronize the source.

301
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Make sure the control qualifier goes to select pin of the MUX to make
this tag as full match.

NO_DESTDOM_SIGNAL_ON_MUX_DATAPINS
This reason code is reported when only sources drive MUX data inputs.

302
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

At least one destination domain signal should drive a MUX data input.

What Next
Make sure at least one destination domain signal should drive a MUX
data input or driven by MUX output otherwise the crossing is incomplete
without proper destination.

SRC_SAME_AS_QUAL_SRC
This reason code is reported when the source of data crossing is the
same as the source of the control path qualifier. In such cases, the
qualifier is not considered as a valid qualifier. This is because the source
acts as both data and control signal in the data crossing.

303
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Source control logic should have different source than that of data
crossing, same source of data crossing should not be merged with
control crossing and it becomes invalid. Make sure that structure has
separate source for data and control logic.

QUAL_CONVERGES_OTHER_SYNC_SRC
This reason code is reported when a qualifier converges with another
synchronous source before gating logic.

304
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check if the qualifier is able to block the source correctly or not. The
blocking value depends on the gate used in convergence. If it is an AND
gate, the blocking value will be 0 and if it is an OR gate, the blocking
value is 1. If not correctly blocked, modify the code.

QUAL_CONVERGES_SAME_SRC
This reason code is reported when a qualifier converges with the same
source before gating logic.

305
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
Check if qualifier is able to block the source correctly or not. The
blocking value depends on the gate used in convergence. If it is an AND
gate, the blocking value will be 0 and if it is an OR gate, the blocking
value is 1. If not correctly blocked, modify the code.

SRC_CONVERGES_QUAL_INSIDE_LOOP
This reason code is reported when source converges with qualifier inside
combinational loop.

306
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

What Next
To fix this violation, design should be modified such that qualifier loop is
resolved.

QUALIFIER_PROPAGATED_ACROSS_DEST
This reason code is reported when the qualifier propagated across the
destination of a separate crossing can potentially qualify the current
crossing.

307
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

In the above schematic, a CDC crossing exists between the s1 and d1


flops, qualified by the q1 qualifier. The q1 qualifier is then propagated
across the d1 destination to qualify other crossings. There also exists a
CDC crossing between s2 and d2, which can potentially be qualified by
the propagated qualifier.

What Next
To fix this violation, review if the destination propagated qualifier can
act as a valid qualifier for the crossing by checking the schematic for
valid gating logic to gate the propagated qualifier. If the crossing can be
qualified by the propagated qualifier, mark it as synchronous by using
the configure_cdc_data_sync command or waive it.
NOTE: You can enable propagation of qualifier across destination by using the
configure_cdc_data_sync -allow_qual_prop_across_dest true
command.

POTENTIAL_SYNCRST_QUALIFIER
This reason code is reported if a crossing is synchronized by a qualifier
which is passing through a potential sync reset gate (I_AND_grst in below
schematic).
This check is enabled when the configure_cdc_data_sync -

308
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

auto_syncrst_qual is set to true.

What Next
To fix this violation, check if a sync reset is missed on any gate in the path.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer
detection.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_cdc_internal_crossing: Enables crossings on the source clock
pin and the destination clock pin of the specified libcell.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.

309
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 set_clock_relation: Specifies two synchronous points in the


asynchronous clock(s) pair path to form a crossing.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

310
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_IGNOREPATH_USER_CONSTRAINT
(Alias: CDC_IGNOREPATH_USER_CONSTRAINT)

Severity
Info

Short Help
Ignore crossing path due to user defined constraint.

Description
VC SpyGlass CDC reports this tag when a crossing is ignored because of a
user-specified constraint. VC SpyGlass CDC does not detect synchronizer
for such ignored crossings because such destination cannot be metastable.
For example, consider the following command and schematic.
set_cdc_ignore_path -from_clock clk1 -to_clock clk2

This tag reports the following reason codes:


 CDC_IGNORE_PATH_COMMAND
 CDC_IGNORE_PATH_USER_CONSTRAINT

CDC_IGNORE_PATH_COMMAND
This reason code is reported if a crossing is waived by the

311
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

set_cdc_ignore_path command.

What Next
This is an informational message for review purpose.

CDC_IGNORE_PATH_USER_CONSTRAINT
This reason code is reported if a crossing is waived by the
-logically_exclusive or -physically_exclusive arguments of the
set_clock_groups command.

What Next
This is an informational message for review purpose.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

312
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

 cdc_enable_splitbus_mapping: Default value is false. Set the value to


true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

313
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_CLOCK_RELATION
Severity
Info

Short Help
Filter crossing path due to user-defined set_clock_relation constraint.

Description
VC SpyGlass CDC reports this tag when a crossing path between a source
flip-flop and destination flip-flop is filtered with user-specified
set_clock_relation constraint.
Consider the following schematic where data crossing path exists between
the src_reg and dst_same_phase, driven by clk1 and clk2 with following
SDC constraints:
create_clock -name C1 -period 6 -waveform {0 3} {clk1}
create_clock -name C2 -period 6 -waveform {3 6} {clk2}
set_clock_groups -asynchronous -group {C1} -group {C2}

In this case, VC SpyGlass CDC considers the crossing as a synchronized


crossing because of the set_clock_relation -from_clock C1 -to_clock

314
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

C2 constraint and reports the SYNCCDC_DATAPATH_FULL tag.

What Next
This is an informational message for review purpose.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.

Related App-var(s)
None

315
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

SYNCCDC_UNSYNC_CLOCK_RELATION
Severity
Info

Short Help
Filter crossing path due to user-defined set_clock_relation constraint with
no phase requirements.

Description
VC SpyGlass CDC reports this tag if a crossing path between a source flip-
flop and a destination flip-flop is filtered with user-specified
set_clock_relation constraint but the phase requirement in clock
relationship is not specified.
For example, consider the following schematic.

In addition, consider that the following constraints are specified for the
design:
create_clock -name C1 -period 6 -waveform {0 3} {clk1}
create_clock -name C2 -period 6 -waveform {3 6} {clk2}
create_clock -name C3 -period 6 -waveform {3 6} {clk3}
create_clock -name C4 -period 6 -waveform {3 6} {clk4}
set_clock_groups -asynchronous -group { C1 } -group { C2 } -
group { C3 } -group { C4 }

316
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

set_clock_relation -from_clock { C1 C2 } -to_clock { C3 C4 }


In this case, VC SpyGlass CDC reports the SYNCCDC_DATAPATH_PARTIAL
tag with the CLOCK_PHASE_RELATION_NOT_SATISFIED reason code.

What Next
To fix the issue, specify the correct phase relationship between the source
clock and the destination clock by using the following constraint:
set_clock_relation -phase <inv|noninv|any>
For example, to analyze the phase relationship, consider that
from_inv[i]= number of inversion from point defined in from_clock/
from_obj to the clock pin of i flip-flop. In addition, consider to_inv[j]=
number of inversion from point defined in from_clock/from_obj to the
clock pin of j flip-flop.
VC SpyGlass CDC requires that for all i, from_inv[i] are all even or all
odd and for all j, to_inv[j] are all even or all odd. In other words, it is
required that the same polarity exists from the from_clock/from_obj
point to all flip-flops it drives.
If -phase option is set to inv, VC SpyGlass CDC verifies that
abs(from_inv[0] - to_inv[0]) is odd.
If -phase option is set to noninv, VC SpyGlass CDC verifies that abs
(from_inv[0] -to_inv[0]) is even.
If -phase option is set to any, no additional check is carried.
VC SpyGlass CDC applies the result of the phase analysis to the
synchronization results. If -phase is specified (with any value), the
set_clock_relation command takes priority over auto-data
synchronization detection as well as qualifier command synchronization for
all the source and destination flip-flops that are driven by nets/ports in the
from/to set.
To resolve such issues, specify the -phase option with the
set_clock_relation constraint.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.

317
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Crossing Checks

Debugging CDC Synchronization Violations

Related App-var(s)
None

318
Synopsys, Inc. Feedback
VC SpyGlass CDC
Unsynchronized Reset
Checks

This chapter is organized into the following sections:


 About Reset Synchronization
 Enabling Reset Verification Checks
 Performing Reset Synchronization Checks
 Resolving Reset Synchronization Violations

319
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

About Reset Synchronization

About Reset Synchronization


After completing clock propagation and resolving setup issues, the next
step is to:
 Recognize all good synchronizer structures
 Report all problematic or missing synchronizers
With increasing design complexity, exploding clock and power domains, the
SoCs have a complex reset architecture which are often overlooked by
designers. Resets are designed to cater to various requirements like
multiphase power up, start sequence, multiple power domains, time
keeping functionality, self-test modes and so on, which can be generated
by either hardware or software. Due to this, there can be multiple design
issues such as metastability, reset recovery and removal time when
asynchronous reset is asserted.
When a source from an asynchronous clock domain reaches to the
asynchronous preset or clear pin of a sequential element, it might cause
metastability.

Figure 6-5

In Figure 6-5, when RST1 de-asserts, then the de-asserted value on N1 is


with respect to the C2 clock. Therefore, de-assertion on the D flip-flop can
be very close to C1 clock edge. If value on S is '1', it can cause
metastability on output D. This phenomenon is also normally referred as
reset recovery time (when reset is de-asserted and the time that the clock
signal goes high again). Missing a recovery time can cause signal integrity
or metastability problems.

320
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

About Reset Synchronization

Similarly, the path from N1 to D is detected as Reset path crossing.


All the problems reported by data path crossings are also applicable to
reset path crossing.
Refer to the reason codes of the ASYNCRST_CTRLPATH_FULL and
ASYNCRST_DATAPATH_FULL tags for the supported reset synchronizers.

321
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Enabling Reset Verification Checks

Enabling Reset Verification Checks


By default, reset verification check is enabled. Use the following application
variable to perform reset-less verification:
%vc_static_shell> set_app_var enable_resetless_analysis true
By default, this application variable is set to false.
When this variable is set, the reset verification check is performed even if
the reset setup is not completed. Therefore, even if there are no
create_reset or inferred reset constraints in the design, reset verification
check is performed.

322
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Performing Reset Synchronization Checks

Performing Reset Synchronization Checks


After you have enabled the reset verification checks, use the check_cdc –
type sync Tcl command to run the reset synchronization checks.

323
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Resolving Reset Synchronization Violations


The following section describes all the violations reported for
synchronization checks.

324
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_UNSYNC_NOSCHEME
(Alias: CDC_UNSYNC_ASYNCRESET)

Severity
Error

Short Help
No valid synchronization scheme found for a reset path crossing.

Description
VC SpyGlass CDC reports this tag if there is a reset path crossing and the
tool could not find any synchronization scheme that can synchronize this
crossing.
For example, consider the schematic in Figure 6-6 where there is a reset
path crossing between the q source and the out destination. In addition,
no synchronization scheme exists to synchronize this crossing and
therefore, the tool reports the ASYNCRST_UNSYNC_NOSCHEME tag in this
case.

Figure 6-6
The tag reports the following reason codes:
 UNSYNC_NONSTATIC_COMBO
 SRC_CONVERGES_ASYNC_SRC
 NO_SYNC_METHOD

325
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

UNSYNC_NONSTATIC_COMBO
This reason code is reported if there is non-static combo logic in the reset
crossing path.
For example, consider the schematic in Figure 6-7 where there is an AND
gate between the q source and the out destination. In such cases, this
reason code is reported.
Use the configure_cdc_reason_code -code UNSYNC_NONSTATIC_COMBO -
unhide -type full command before elaboration to report this reason
code.

Figure 6-7

What Next
Check the structure and see if the combo logic between the reset crossing
is intentional as per design requirement, if not, modify the design as per
the structure by removing the combo logic shown in the violation message.

SRC_CONVERGES_ASYNC_SRC
This reason code is reported when a source converges with another
asynchronous source before gating logic. Sometimes this problem could
indicate an attempt to qualify an incorrectly synchronized qualifier (or a
qualifier that is correctly synchronized but is not recognized by VC

326
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

SpyGlass CDC). In this case, use the qualifier constraint to mark the signal.
For example, consider the schematic in fig where the q source is
converging with another domain source, q2, before reaching the
destination. In this case, VC SpyGlass CDC reports this reason code.

Figure 6-8
The crossing might have a conventional multi-flop structure, synchronizing
cell structure, handshake, FIFO structures, or any other synchronization
structure.

What Next
This reason code appears in reset domain crossing where multiple reset
source domains converge on one single destination domain. Check the
source domain and ensure that there are no multiple source domain
participating in the clock-domain crossing. If this is expected, then ignore
this message.
To hide this reason code, use the following command:
configure_cdc_reason_code -code SRC_CONVERGES_ASYNC_SRC -hide -
type full

327
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

By default, this reason code is of type partial, you must convert this to
type full to hide it.

NO_SYNC_METHOD
This reason is reported if VC SpyGlass CDC cannot find a synchronizing
structure at the destination of a reset crossing. This might be because the
designer missed to add a valid qualifier, connect it properly, or VC SpyGlass
CDC was unable to find the qualifier.
For example, consider the schematic shown in Figure 6-9 where
synchronizer a1->a2->a3 is not a valid synchronizer and therefore it is
reported by this reason code. If you think the synchronizer you are applied
is valid, mark the qualifying signal by using the qualifier constraint.

Figure 6-9

What Next
If you know that the reset crossing is controlled by a valid qualifier, mark
the qualifying signal by using the configure_cdc_asyncrst_data_sync
constraint:
 If a reset source converges with an invalid qualifier at some gate.
 If a reset source converges with an unsynchronized qualifier crossing
defined by the configure_cdc_asyncrst_data_sync constraint.

328
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related Command(s)
 configure_cdc_asyncrst_data_sync: Configures the criteria for detecting
reset path synchronization schemes.
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

329
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_CTRLPATH_FULL
(Alias: CDC_SYNC_ASYNCRESET)

Severity
Info

Short Help
A valid asynchronous reset synchronization scheme found to ensure
synchronous de-assertion of the asynchronous reset.

Description
VC SpyGlass CDC reports this tag if a valid asynchronous reset
synchronization scheme is found to ensure synchronous de-assertion of the
asynchronous reset on the CDC path.
The tag reports the following reason codes:
 SYNC_BY_NFF
 STATIC_COMBO_IN_CROSSING
 NON_CONST_DST_INPUT
 CONST_DST_INPUT
 SYNC_BY_UDS

SYNC_BY_NFF
This reason code is reported when a conventional multi-flop
synchronization scheme is found on the reset path as shown in

330
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Figure 6-10.

Figure 6-10

What Next
This is an informational message indicating the VC SpyGlass CDC
recognizes the NFF structure with default settings or with the user-
specified configurations. No further action is required.

STATIC_COMBO_IN_CROSSING
This reason code is reported when static combo logic is found on a reset
crossing path.
For example, consider the schematic in Figure 6-11 where q1 is a crossing
source and q2 is the crossing destination. The q1 source converges at the
AND gate with another source on which the set_case_analysis constraint is
applied and its value is always 1. Therefore, there is static combo path in

331
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

the crossing path.

Figure 6-11

What Next
Usually, static signal is not considered during CDC analysis because the
signal does not change at any instance of the design cycle. However, it is
recommended that you review and ensure that the structure is clean
without any such paths so that CDC analysis can be performed by the tool.
To fix the violation, perform any of the following, as appropriate:
 Check the design structure for the user-defined create_static and
set_case_analysis configurations. If these exist, validate that these are as
per the design intent. If not, modify the design.
 Check the design structure if combo logic output, which is static in
nature, acts as an input to a reset synchronization structure and
validate that it is as per the design intent. If not, modify the design.

NON_CONST_DST_INPUT
This reason code indicates that something other than a constant value
drives the D pin of a reset synchronizer. The driver might be a net or a
primary port.
For example, consider the schematic in Figure 6-12 where the out flop is a

332
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

synchronizer flop. The D pin of the out flop is driven by the output of the q2
flop which is not a constant. In such cases, the tool reports the
NON_CONST_DST_INPUT reason code.

Figure 6-12

What Next
This is an informational message. However, if the inputs to reset
synchronizers must be the constants 1 or 0 because of design
requirements, the design should be updated to remove the non-constant
nature of the input to the reset synchronizer.

Limitations:
Consider the following verilog code:
input ck1,ck2,rstn,d;
output z;

reg q1rstn,q2rstn;
always @(posedge ck2 or negedge rstn)
if (!rstn) begin
q1rstn <= 1'b0;
q2rstn <= 1'b0;
end
else begin

333
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

q1rstn <= rstn;


q2rstn <= q1rstn;
end
In the above snippet, note that the rstn port is the input to the reset
synchronizer. However, due netlist optimization, VC SpyGlass CDC
synthesizes to a 1 attached to the input of the reset synchronizer. This is
because if the value of rstn is 0 and the flip-flop is being reset, the only
meaningful value of rstn at the D pin is 1.
However, this leads to an unexpected result in the reason code. VC
SpyGlass CDC reports the reason code as CONST_DST_INPUT and not
NON_CONST_DST_INPUT because the netlist sees a 1 at the D pin.
Figure 6-13 shows the schematic of the above code.

Figure 6-13

CONST_DST_INPUT
This reason code indicates that a constant value drives the D pin of a reset

334
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

synchronizer as shown in Figure 6-14.

Figure 6-14

What Next
This is an informational message to distinguish the case of non-constant
input to reset synchronizer, which is covered by the
NON_CONST_DST_INPUT reason code.

SYNC_BY_UDS
This reason code is reported if a user-specified reset synchronizer cell is
detected in the reset crossing path. For example, consider the following
command where SYNC is specified as the user-defined reset
synchronizer:
configure_cdc_asyncrst_nff_sync -uds_modules SYNC

335
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

What Next
This is an information message indicating that VC SpyGlass CDC recognizes
the UDS structure with the user-specified configurations. No further action
is required.

Related Command(s)
 configure_cdc_asyncrst_data_sync: Configures the criteria for detecting
reset path synchronization schemes.
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

336
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related App-var(s)
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

337
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_CTRLPATH_PARTIAL
(Alias: CDC_UNSYNC_ASYNCRESET)

Severity
Error

Short Help
A partially matched asynchronous reset control synchronization scheme is
found for the CDC path.

Description
This violation is reported when a partially matched control synchronization
scheme is found for the CDC path.
The tag reports the following reason code:
 ASYNC_SRC_CONVERGE
 NFF_DST_WITH_MULTI_FANOUTS

ASYNC_SRC_CONVERGE
This reason code is reported when an asynchronous source converges
before the reset crossing destination.
For example, consider the schematic in Figure 6-15 where the q3 source
converges with q1 at the AND gate before getting synchronized by the

338
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

reset NFF.

Figure 6-15

What Next
Check the multiple asynchronous source reset domains and qualify them
appropriately. To specify the qualifier, check if the qualifier has the same
reset domain as that of the destination.
Sometimes, this problem might indicate an attempt to qualify an
incorrectly synchronized qualifier or a qualifier that is correctly
synchronized but is not recognized by VC SpyGlass CDC. In this case, use
the qualifier constraint to mark that signal.

NFF_DST_WITH_MULTI_FANOUTS
This reason code is reported when the destination of a crossing is driving
other paths it gets synchronized.

339
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Figure 6-16

What Next
To fix the violation, perform the following steps:
1. Check the user-specified NFF depth value. By default, the depth is 2.
2. Next, check the number of NFF reset sync structure in the design.
3. To fix this issue, ensure that these two values match.

Related Command(s)
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

340
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related App-var(s)
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

341
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_DATAPATH_FULL
(Alias: CDC_SYNC_ASYNCRESET)

Severity
Info

Short Help
Qualifier found in reset crossing data path.

Description
VC SpyGlass CDC reports this violation if a reset path crossing that is
synchronized by valid qualifier in data path is found in the design.
For example, consider the schematic in Figure 6-17 where there is a reset
crossing between the q1 source and the q6 destination. Here, the q2 -> q4
-> q5 NFF chain synchronizes the reset path crossing.

Figure 6-17
The tag reports the following reason code:
 NFF_USED_AS_QUALIFIER

NFF_USED_AS_QUALIFIER
This reason code is reported when reset crossing source is merged with

342
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

NFF at valid gate as shown in Figure 6-18.

Figure 6-18

What Next
This is an informational message pertaining to an NFF used as qualifier
synchronization scheme.

Related Command(s)
 configure_cdc_asyncrst_data_sync: Configures the criteria for detecting
reset path synchronization schemes.
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

343
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

 cdc_enable_splitbus_mapping: Default value is false. Set the value to


true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

344
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_DATAPATH_PARTIAL
(Alias: CDC_UNSYNC_ASYNCRESET)

Severity
Info

Short Help
Qualifier unable to block the source and therefore unable to synchronize
the crossing.

Description
VC SpyGlass CDC reports this violation when a valid qualifier is unable to
block the source and therefore unable to synchronize the crossing.
For example, consider the schematic in Figure 6-19 where the q1->q2->q3
is the NFF and the source is converging at the EXOR gate. The EXOR gate is
not a valid gate to block the source of crossing. Therefore, although there
is a synchronizer, it could not avoid the crossing in this case.

Figure 6-19
The tag reports the following reason codes:
 INVALID_BLOCKING_GATE

345
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

 QUAL_CONVERGES_OTHER_SYNC_SRC
 QUAL_CONVERGES_SAME_SRC
 SRC_CONVERGES_QUAL_INSIDE_LOOP

INVALID_BLOCKING_GATE
This reason code is reported when source and synchronizer are converging
at an invalid gate due to which the synchronizer is unable to block the
source.

Figure 6-20

What Next
Check for the presence of such invalid logic and correct the same to make
the tag to full match. Gating logic, such as XOR gate is considered invalid.
Replace the XOR with valid gating logic, such as AND gate.

QUAL_CONVERGES_OTHER_SYNC_SRC
This reason code is reported when a qualifier converges with another

346
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

synchronous reset source before gating logic.


For example, consider the schematic in Figure 6-21 where the q1->q2->q3
qualifier converges with another source, q6, before converging with the q4
source at qualifier gate. VC SpyGlass CDC reports this reason code in such
cases.

Figure 6-21

What Next
Ideally, qualifier should not converge with other synchronous sources
before it qualifies the intended source. If this is not intended, correct the
design setup accordingly.

QUAL_CONVERGES_SAME_SRC
This reason code is reported when a qualifier converges with the same
reset source before gating logic.
For example, consider the schematic in Figure 6-22 where the q1->q2->q3
qualifier converges with another source, q6, before converging with the q4
source at the qualifier gate. VC SpyGlass CDC reports this reason code in

347
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

such cases.

Figure 6-22

What Next
Ideally, qualifier should not converge with the same source twice. If this is
not intended, correct the design setup accordingly.

SRC_CONVERGES_QUAL_INSIDE_LOOP
This reason code is reported when the reset source converges with qualifier
inside combinational loop. For example, consider the schematic in
Figure 6-23 where the q1->q2->q3 reset synchronizer converges with the
q4 source at the I_AND_w AND gate. The output of this gate feeds back to

348
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

the input of the I_AND_g AND gate which creates a combinational loop.

Figure 6-23

What Next
Review the design for combinational loops that are not intended in the
design. Correct the design setup for such combinational loops.

Related Command(s)
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

349
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

350
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_IGNOREPATH_USER_CONSTRAINT
(Alias: CDC_IGNOREPATH_USER_CONSTRAINT_ASYNCRESET)

Severity
Info

Short Help
Used to ignore Reset Verification path crossings.

Description
VC SpyGlass CDC reports this tag if the reset verification crossing path is
ignored by the set_asyncrst_ignore_path command specified by the
user. This tag reports the following reason codes:
 RST_IGNOREPATH_COMMAND
 RST_IGNOREPATH_USER_CONSTRAINT

RST_IGNOREPATH_COMMAND
This reason code is reported if a crossing is waived by the
set_asyncrst_ignore_path command.
For example, consider the schematic in Figure 6-24 where the q1 flop
output is acting as a reset signal of another flop out. Here, both the flops
have different clocks which are asynchronous and therefore there is a reset
path crossing. However, this crossing can be ignored by using the following
command:
set_asyncrst_ignore_path -from <source-of-crossing path> -to
<dest-of-crossing-path>

351
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Figure 6-24

What Next
This is an informational message for review purpose. This message also
indicates that a user-specified set_asyncrst_ignore_path is honored by
the tool.

RST_IGNOREPATH_USER_CONSTRAINT
This reason code is reported if a crossing is waived by the
-logically_exclusive or the -physically_exclusive arguments of the
set_clock_groups command.

What Next
This is an informational message for review purpose.

Related Command(s)
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.

352
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

 configure_ip_block: Configures the modules for which CDC, RDC and


ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

Related App-var(s)
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

353
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_RSTSYNC_INVALID_USE
Severity
Error

Short Help
User-defined reset synchronizers drive an invalid (non set/reset) pin.

Description
VC SpyGlass CDC reports this tag if user-defined reset synchronizers which
drive an invalid (non set/reset) pin is found in the design.
For example, consider the schematic in Figure 6-25 where the output of
the FR8->FR9->FR10 reset synchronizers drives the black box pin, which is
neither a reset nor a set. To see this tag, enable the tag by using the
configure_cdc_tag -enable -tag ASYNCRST_RSTSYNC_INVALID_USE
command.

Figure 6-25

354
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

The tag reports the following reason codes:


 RESET_SYNCHRONIZER_NON_RESET_USE
 RESET_SYNCHRONIZER_REDUNDANT_LOGIC
 RESET_SYNCHRONIZER_DRIVES_OUTPUT_PORT

RESET_SYNCHRONIZER_NON_RESET_USE
This reason code appears when a reset synchronizer drives a pin that is
neither a set or a reset.
For example, consider the schematic in Figure 6-25 where the output of
the FR8->FR9->FR10 reset synchronizers drives the black box pin, which is
neither a reset nor a set.

What Next
To fix this issue, perform the following steps:
1. Check if this structure is expected, if yes, you can ignore this reason
code.
2. Modify the design to correct the usage of reset synchronizer.

RESET_SYNCHRONIZER_REDUNDANT_LOGIC
This reason code appears when a reset synchronizer is hanging or blocked.
For example, consider the schematic in Figure 6-26 where the output of
the FR8->FR9->FR10 reset synchronizers does not drive any pin. The
output of reset synchronizer is hanging, and therefore this reason code
reports such cases.

355
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Figure 6-26

What Next
To fix this issue, perform the following steps:
1. Check if this structure is expected, if yes, you can ignore this reason
code.
2. Modify the design to correct the usage of reset synchronizer.

RESET_SYNCHRONIZER_DRIVES_OUTPUT_PORT
This reason code appears when a reset synchronizer drives an unconnected
output port. For example, consider the schematic in Figure 6-27 where the
output of the FR8->FR9->FR10 reset synchronizers drives the Q9 port,

356
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

which further does not drive any pin. This reason code reports such cases.

Figure 6-27

What Next
To fix this issue, perform the following steps:
1. Check if this structure is expected, if yes, you can ignore this reason
code.
2. Modify the design to correct the usage of reset synchronizer.

Related Command(s)
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

357
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related App-var(s)
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

358
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_IGNOREPATH_FLOATING_SIGNAL
Severity
Warning

Short Help
Ignore path between source object and destination object, crossing from
source clock to destination clock as destination/synchronizer output is
floating

Description
VC SpyGlass CDC reports this tag if reset paths are ignored with floating
destination/synchronizer output.

What Next
This is an informational message. Review such flops and ensure that the
flops reported as part of this message are as per the design intent.

Related Command(s)
 configure_cdc_asyncrst_nff_sync: Configures the reset path multi-flop
synchronizers detection criteria.
 configure_cdc_asyncrst_crossing: Configures crossing detection on
asynchronous reset paths.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_asyncrst_ignore_path: Ignores specified paths for async reset
analysis.

359
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

Related App-var(s)
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.
 enable_resetless_analysis: Default value is false. Set the value to true
to detect reset crossings even for destinations to which no reset is
propagating.

360
Synopsys, Inc. Feedback
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_IGNOREPATH_QUASI_STATIC
Severity
Info

Short Help
Ignore path between source object and destination object, crossing from
source clock to destination clock as the source is quasi static

Description
VC SpyGlass CDC reports this tag if a quasi-static source reaches
destination of a reset crossing. This tag is disabled by default. To enable it,
use the configure_cdc_tag -enable command.

What Next
This is an informational message. Review such floating flops and ensure
that the flops reported as part of this message are as per the design intent.

Related Command(s)
None

Related App-var(s)
None

361
Feedback Synopsys, Inc.
VC SpyGlass CDC Unsynchronized Reset Checks

Resolving Reset Synchronization Violations

ASYNCRST_PATH_COHERENCY
Severity
Warning

Short Help
Reset signal is getting synchronized multiple times

Description
VC SpyGlass CDC reports this tag for asynchronous resets that are
synchronized multiple times in the same clock domain. The tag checks the
presence of multi-flop synchronizer irrespective of if synchronous
deassertion is happening properly or not. Any two synchronizers are
reported by the rule in case more than two synchronizers exist in the same
clock domain for the reset.
NOTE: This tag does not check for resets that are synchronized by synchronize cells
specified by using the set_asyncrst_synchronizer parameter.

What Next
Synchronize the reset signals and then use it.

Related Command(s)
None

Related App-var(s)
None

362
Synopsys, Inc. Feedback
VC SpyGlass CDC
Convergence Checks

This chapter is organized into the following sections:


 About Convergence
 Running Convergence Checks
 Resolving Convergence Violations

363
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

About Convergence

About Convergence
Convergence issues can occur when multiple signals cross from one
domain to another but are separately synchronized. The VC SpyGlass CDC
convergence checks enable you to ensure that there is reliable transfer of
signals between two parts of circuits driven by two different clocks which
are asynchronous to each other.
It is unreliable to sample a signal at the destination side (on destination
side's clock edge) when the signal is changing in the source side (at source
side's clock edge). The signal sampled at such point in time does not
assume a stable '0' or '1' value, and therefore is metastable.
The effect of a metastable signal is neutralized by introducing
synchronizers, which are usually a chain of flip-flops that are driven by a
destination clock after the crossing. However, even if each crossing has the
necessary synchronizer to transfer a signal reliably to the destination side,
there can still be functional failure if two or more source signals (either
originating from the same signal, or from two or more related signals) are
synchronized at different cycles at the destination side and then converge
at downstream logic.
Consider the example illustrated in Figure 7-28. The source signals X1 and
Y1 (driven by Clk_A) is synchronized at the destination side by respective
synchronizer flip-flops (driven by Clk_B, which is asynchronous to Clk_A)

364
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

About Convergence

and become stable signals X4 and Y4 respectively.

Figure 7-28 Convergence Checks

Figure 7-29 Convergence Checks Example

365
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

About Convergence

However, as shown in Figure 7-29, it is possible that transitions of X2 and


Y2 might be slightly off each other and therefore can be captured by
different edges of Clk_B. In Figure 7-28, the signals X4 and Y4 finally get
their stable values in cycle N and N+1 respectively and therefore creating
an unwanted difference of one cycle relative to each other. Now, when
these two signals converge in downstream logic, they create an unwanted
value due to the single cycle gap introduced over the synchronizers. This is
known as the problem of convergence in the context of CDC analysis.
Figure shows different types of convergences that might lead to

366
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

About Convergence

convergence issues.

FIGURE 8. Convergence Issues

367
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Running Convergence Checks

Running Convergence Checks


Before you run convergence checks, ensure the following:
 The design has been successfully read-in and elaborated.
 The SDC commands have been read successfully.
 The clocks in the design have been inferred automatically, if required.
 Clock propagation with user-defined clocks and auto-inferred clocks has
been performed.
 CDC crossings in the design have been detected.
 CDC synchronizers in the design have been detected.
To run convergence checks, use the check_cdc -type struct command.

368
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

Resolving Convergence Violations


The following section describes all the violations reported for convergence
checks.

369
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_SINGLE_SRC_COMBCONV_FVUNCHECK
(Alias: CDC_COHERENCY_SINGLESRC_RECONV)

Severity
Error

Short Help
Combinational convergence of single source divergence found at
convergence point

Description
VC SpyGlass CDC reports this tag when there is combinational convergence
of single synchronized signals on which the check for gray encoding of
source bits is skipped. A combinational convergence, in this context, is
considered to be a convergence through paths that have zero sequential
depth.
The tag uses the following fields:
 ReasonInfoList: Reason info list
 ConvergencePoint: Convergence point
 ConvControlPathList: List of converging control paths from source(s)
to destination
 CdcAttributeName: CDC attribute name for black box as convergence
point
 ToModule: Parent Module of the Destination objects. Possible sub-fields
include:
 MdmObjInfo: MdmObject Details for Violation.
 DstFileLine: File name and line number of destination object. Possible
sub-fields include:
 FileName: File Name
 LineNumber: Line number
 ViaPointList: List of all the ViaPoints for a violation
 ContainerInstance: Containing instance
 Module: Design Unit

370
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

 FullyContainedViolation: Flagged violation is fully inside the


abstracted module
The tag reports the following reason code:
 GRAY_CHECK_IGNORED_DIV_SRC_CONV
 SYNC_SRC_CONV
 DIV_SRC_CONV

GRAY_CHECK_IGNORED_DIV_SRC_CONV
This reason code is reported when the presence of gray encoder is not
checked as a functional check because of the presence of a diverging
source.

SYNC_SRC_CONV
This reason code is reported when multiple source signals from the same
domain converge after synchronization.

DIV_SRC_CONV
This reason code is reported when the same source diverges and
converges after synchronization through multiple paths.
By default, this tag is disabled. Use configure_cdc_tag -enable option to
enable this tag.

What Next
This kind of convergence can cause data coherency issues and might cause
chip failure. To fix the violation, perform either of the following, as
appropriate:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

371
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_SINGLE_SRC_SEQCONV_FVUNCHECK
(Alias: CDC_COHERENCY_SINGLESRC_RECONV)

Severity
Error

Short Help
Sequential convergence of single source divergence found at convergence
point

Description
VC SpyGlass CDC reports this tag when there is sequential convergence of
single synchronized signals on which the check for gray encoding of source
bits is skipped. A combinational convergence, in this context, is considered
to be a convergence through paths that have zero combinational depth.
The tag uses the following fields:
 ReasonInfoList: Reason info list
 ConvergencePoint: Convergence point
 ConvControlPathList: List of converging control paths from source(s)
to destination
 CdcAttributeName: CDC attribute name for black box as convergence
point
 ToModule: Parent Module of the Destination objects. Possible sub-fields
include:
 MdmObjInfo: MdmObject Details for Violation.
 DstFileLine: File name and line number of destination object. Possible
sub-fields include:
 FileName: File Name
 LineNumber: Line number
 ViaPointList: List of all the ViaPoints for a violation
 ContainerInstance: Containing instance
 Module: Design Unit

372
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

 FullyContainedViolation: Flagged violation is fully inside the


abstracted module
The tag reports the following reason code:
 GRAY_CHECK_IGNORED_SEQ_CONV
 GRAY_CHECK_IGNORED_DIV_SRC_CONV
 SYNC_SRC_CONV
 DIV_SRC_CONV

GRAY_CHECK_IGNORED_SEQ_CONV
This reason code is reported when the presence of gray encoder is not
checked because of non-zero sequential depth of convergence path partial.

GRAY_CHECK_IGNORED_DIV_SRC_CONV
This reason code is reported when the presence of gray encoder is not
checked as a functional check because of the presence of a diverging
source.

SYNC_SRC_CONV
This reason code is reported when multiple source signals from the same
domain converge after synchronization.

DIV_SRC_CONV
This reason code is reported when the same source diverges and
converges after synchronization through multiple paths.
By default, this tag is disabled. Use configure_cdc_tag -enable option to
enable this tag.

What Next
This kind of convergence can cause data coherency issues and might cause
chip failure. To fix the violation, perform either of the following, as

373
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

appropriate:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

374
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_COMBCONV_FVUNCHECKED
(Alias: CDC_COHERENCY_RECONV)

Severity
Error

Short Help
Combinational convergence found at ConvergencePoint

Description
VC SpyGlass CDC reports this tag when there is combinational convergence
of multiple synchronized signals on which the check for gray encoding of
source bits is skipped. A combinational convergence, in this context, is
considered to be a convergence through paths that have zero sequential
depth.
The CDC_COMBCONV_FVUNCHECKED tag reports same source signals that
converge after satisfying the following conditions:
 Signals from the same source domain are synchronized in the same
destination domain.
 The signals are synchronized by using the Control Synchronization
Scheme.
 The sequential depth of the synchronizer up to the convergence point is
zero.
Figure 9 shows an example of convergence of signals from same source

375
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

clock domains.

FIGURE 9.

The tag supports the following features:


 Reports only one violation if the same set of signals converge in more
than one path.
 Reports a violation at a point that has the maximum number of signals
converging if convergence happens at multiple points in a path.
 Ignores convergence of clock domain crossing signals specified by using
the set_cdc_ignore_path command.
 Checks both scalar and bus signals.
 Reports only combinational convergences. It does not allow flip-flops in
the output cone of synchronizing signals.
The tag reports the following reason codes:
 GRAY_CHECK_USER_DISABLED
 DIV_SRC_CONV
 GRAY_CHECK_IGNORED_DIV_SRC_CONV
 SYNC_SRC_CONV

GRAY_CHECK_USER_DISABLED
This reason code is reported when the functional check is disabled and

376
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

therefore the presence of gray encoder is not checked.

What Next
View the schematic of the violation by clicking the New Violation
Schematic button. In the schematic, analyze the path of convergence of
synchronizers if they are expected or not.
Based on the information in the violation and the schematic, perform any
of the following actions, as appropriate:
 Make sure that gray encoding is applied on source signals so that there
is no coherency issue.
 If convergence is for static signals, use the create_static constraint.
 If the path of synchronizers confirms that synchronizers cannot
functionally control the converging net at the same time, waive the
violation.
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 If the convergence is at mux, being mutually exclusive inputs, disable
the configure_cdc_convergence -disable_mux_exclusivity
command.

377
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

 If the convergence is for different domains, use the


configure_cdc_convergence -stop_diff_domain command.

DIV_SRC_CONV
This reason code is reported when the same source diverges and
converges after synchronization through multiple paths.

What Next
This kind of convergence can cause data coherency issues and might cause
chip failure. To fix the violation, perform either of the following, as
appropriate:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

GRAY_CHECK_IGNORED_DIV_SRC_CONV
This reason code is reported when the presence of gray encoder is not
checked as a functional check because of the presence of a diverging

378
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

source.

What Next
This kind of convergence can cause data coherency issues and might cause
chip failure. To fix the violation, perform either of the following, as
appropriate:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

SYNC_SRC_CONV
This reason code is reported when multiple source signals from the same
domain converge after synchronization.

379
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

What Next
If you do not gray encode converging signals, there might be data
coherency issues and might cause chip failure. To fix the violation, see
What Next.

Related Command(s)
 configure_cdc_convergence:
 configure_ip_block
 configure_unconstrained_ports
 define_attribute

Related App-var(s)
cdc_enable_merge_vector

380
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_SEQCONV_FVUNCHECKED
(Alias: CDC_COHERENCY_RECONV)

Severity
Error

Description
VC SpyGlass CDC reports this tag when sequential convergence (at least
one converging path should have a non-zero sequential depth) of multiple
synchronized signals on which the check for gray encoding of source bits is
skipped.
The tag reports the following reason codes:
 GRAY_CHECK_IGNORED_SEQ_CONV
 GRAY_CHECK_IGNORED_DIV_SRC_CONV (Disabled):

GRAY_CHECK_IGNORED_SEQ_CONV
This reason code is reported when multiple same domain synchronized
signals converge through non-zero sequential depth paths and the
presence of gray encoder check is not applied due to non-zero sequential
depth of convergence path.

381
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

What Next
This kind of convergence can cause data coherency issues and might cause
chip failure. To fix the violation, either of the following needs to be done:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

GRAY_CHECK_IGNORED_DIV_SRC_CONV (Disabled):
This reason code appears when the presence of gray encoder is ignored
because it is not checked as functional check due to the presence of
diverging source which converges after synchronization through non-zero
sequential depth paths.

What Next
Such convergences can cause data coherency issues and might cause chip
failure. To fix the violation, perform either of the following:
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the

382
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

related nets or signals. Then, the violation is not reported on the


specified nets or signals.
 Modify the design to remove such a convergence

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports
define_attribute

Related App-var(s)
cdc_enable_merge_vector

383
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_NOCONV_MULTIPLE_SYNC
(Alias: CDC_COHERENCY_MULTI_SYNC)

Severity
Error

Short Help
Signals control synchronized multiple times in same domain without
convergence.

Description
VC SpyGlass CDC generates this tag to report the signals that are control
synchronized multiple times in same domain without convergence. This is
important to avoid coherency issues in a design.

What Next
Not fixing this violation might result in:
 Data coherency issues if synchronized destinations driven by the same
source converge.
 A higher gate count because this is excessive synchronization.
Such designs are not reusable because there is a risk of chip failure due to

384
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

potential convergence problem. To fix the violation, synchronize the signal


and then distribute it.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports
define_attribute

Related App-var(s)
cdc_enable_merge_vector

385
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_NOCONV_MULTIPLE_SYNCBUS

Severity
Warning

Short Help
Separate synchronization of different bits of same source bus at
destination bus

Description
VC SpyGlass CDC generates this tag to report when each bit of the source
bus is synchronized separately by scalar conventional multi flops or
synchronized cells. This can cause skew between destination bus bits.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
To fix the violation, synchronize different bits of the same source bus using
same multiflops/sync cell and then distribute it.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports

386
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

define_attribute

Related App-var(s)
cdc_enable_merge_vector

387
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_NOCONV_FV_UNCHECKED
(Alias: CDC_COHERENCY_BUS_NOCONV)

Severity
Warning

Short Help
Control synchronized bits of same source vector signal that are neither
converging nor checked for presence of gray encoder

Description
VC SpyGlass CDC generates this tag to report control synchronized bits of
same source vector signal that are neither converging nor checked for
presence of gray encoder. In this case, combinational or sequential
convergence is not reported because these control synchronized bits are
not converging.
The tag reports the following reason code:
 GRAY_CHECK_USER_DISABLED

GRAY_CHECK_USER_DISABLED
This reason code appears when the presence of gray encoder is not
checked as functional check is disabled by user.

388
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

What Next
If you do not gray encode converging signals, the data in the crossing
might be lost. To fix the violation, either of the following needs to be done-
 Ensure that gray encoding is applied on source signals so that there
will no data loss.
 Enable functional checks and check whether gray encoding is passed.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports
define_attribute

Related App-var(s)
cdc_enable_merge_vector

389
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_NOCONV_MISMATCH
(Alias: CDC_COHERENCY_VECTOR_DIFF_SYNC)

Severity
Warning

Short Help
Mismatch in synchronization among different bits of the same vector
source.

Description
VC SpyGlass CDC reports this tag when there is a mismatch in
synchronization among different bits of the same vector source. Use this
tag to check for coherency issues in the synchronized clock domain
crossings to control bus signals.
The tag reports the following reason codes:
 DIFF_CONTROL_SIGNAL
 DIFF_SYNC_SCHEME

DIFF_CONTROL_SIGNAL
This reason code is reported when different source bits of same vector

390
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

source are enable-synchronized using different enable signals.

What Next
If you do not fix this violation, the bus bits might not change at the same
time. This might result in data coherency problem that can cause chip
failure. To fix the violation, either of the following needs to be done-
 Review if such a different enable usage is expected or not design needs
to be changed
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.

391
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

DIFF_SYNC_SCHEME
This reason code is reported when different bits of same vector source are
synchronized using different synchronization mechanism.

What Next
If you do not fix this violation, the bus bits might not change at the same
time. This might result in data coherency problem that can cause chip
failure. To fix the violation, either of the following needs to be done-
 Review if such a different enable usage is expected or not design needs
to be changed
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports

392
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

define_attribute

Related App-var(s)
cdc_enable_merge_vector

393
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_COMBCONV_ASYNC_SRCS
(Alias: CDC_COHERENCY_ASYNCSRCS_RECONV)

Severity
Error

Short Help
Combinational convergence of multiple synchronized signals from mutually
asynchronous sources

Description
VC SpyGlass CDC generates this tag to report combinational convergence
(Convergence through paths which has zero sequential depth) of multiple
synchronized signals from mutually asynchronous sources. This type of
convergence of synchronizers from different domains can cause data
coherency. This might result in chip failure.
NOTE: If the CDC_COMBCONV_ASYNC_SRCS and the CDC_SEQCONV_ASYNC_SRCS tags
are disabled, and the configure_cdc_convergence -
enable_seq_based_analysis argument is set to true, VC SpyGlass performs
convergence analysis separately and reports two violations if a convergence point
has qualifiers from two different source domains.
The tag reports the following reason code:
 ASYNC_SRC_CONV

ASYNC_SRC_CONV
This reason code appears when multiple source signals from different
domains converge after synchronization. The convergence happens

394
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

through combinational paths.

What Next
If you do not fix this violation, convergence of synchronizers from different
domains can cause data coherency. This might result in chip failure. To fix
the violation, either of the following needs to be done-
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such convergences.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports

395
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

define_attribute

Related App-var(s)
cdc_enable_merge_vector

396
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_SEQCONV_ASYNC_SRCS
Severity
Error

Short Help
Sequential convergence of multiple synchronized signals from mutually
asynchronous sources

Description
VC SpyGlass CDC generates this tag to report sequential convergence (at
least one converging path should have a non-zero sequential depth) of
multiple synchronized signals from mutually asynchronous sources. This
type of convergence of synchronizers from different domains can cause
data coherency. This might result in chip failure.
NOTE: If the CDC_COMBCONV_ASYNC_SRCS and the CDC_SEQCONV_ASYNC_SRCS tags
are disabled, and the configure_cdc_convergence -
enable_seq_based_analysis argument is set to true, VC SpyGlass performs
convergence analysis separately and reports two violations if a convergence point
has qualifiers from two different source domains.
The tag reports the following reason code:
 ASYNC_SRC_CONV

ASYNC_SRC_CONV
This reason code appears when multiple source signals from different
domains converge after synchronization. At least one converging path

397
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

should have a non-zero sequential depth.

What Next
If you do not fix this violation, convergence of synchronizers from different
domains can cause data coherency. This might result in chip failure. To fix
the violation, either of the following needs to be done-
 If you can ensure that the convergence does not cause coherency
issues, use configure_cdc_convergence (-ignore_through_objects
/-ignore_at_objects /-ignore_among_signals) command on the
related nets or signals. Then, the violation is not reported on the
specified nets or signals.
 Modify the design to remove such a convergence.

Related Command(s)
configure_cdc_convergence
configure_ip_block
configure_unconstrained_ports
define_attribute

398
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

Related App-var(s)
cdc_enable_merge_vector

399
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Resolving Convergence Violations

CDC_JITTER_MONITORS_GENERATED
Severity
info

Short Help
Reports number of jitter monitors

Description
VC SpyGlass CDC generates this tag to report the number of jitter monitors
generated in CDC jitter model.

Related Command(s)
meta_design_hier
meta_monitor_options

Related App-var(s)
None

400
Synopsys, Inc. Feedback
VC SpyGlass CDC Convergence Checks

Control Synchronization Scheme

Control Synchronization Scheme


The Control Synchronization Scheme marks those clock crossings as
synchronized where flip flops are in a synchronization flip-flops
arrangement. In addition, the scheme marks those clock crossings as
synchronized in which the destination object is an instance of a
synchronizing cell.

401
Feedback Synopsys, Inc.
VC SpyGlass CDC Convergence Checks

Control Synchronization Scheme

402
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch
Checks

This chapter is organized into the following sections:


 About Glitch Checks
 Types of Glitches in a Design
 Performing Glitch Checks
 Debugging Glitch Violations

403
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

About Glitch Checks

About Glitch Checks


A race from a source or multiple sources through two different paths
mainly leads to a glitch. For example, in FIGURE 10. , the glitch captured
on D1 propagates to D2 and then to downstream logic, potentially causing
a functional failure.
VC SpyGlass CDC supports glitch checks on synchronous as well as
asynchronous paths.

FIGURE 10. Example for Glitch in a Design

404
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

About Glitch Checks

Glitches in a design can be caused because of following three reasons:


 Re-convergence of same source
 Multiple sources of different domains converging
 Multiple sources from same domain converging

405
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Types of Glitches in a Design

Types of Glitches in a Design


The following types of glitches can be present in a design:
 Glitch on Synchronized Control Path
 Glitch on Synchronized Data Path
 Glitch on Unsynchronized Path

Glitch on Synchronized Control Path


Consider the example in FIGURE 11. which is a case of glitch only since
the metastability is handled by using NFF.

FIGURE 11. Glitch on synchronized control path

In the above example, source S1 diverges and converges back at C0.


Because of different delay in path D0 and I1, glitch can occur at C0. The
glitch if occurs very close to clock CK2, it will be captured by the multi-flop
structure D1 and propagated downstream. Thus, such unexpected output
of the control synchronizers might not be able to act as a proper qualifier
downstream.

Glitch on Synchronized Data Path

406
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Types of Glitches in a Design

Synchronized Data path always has a combo gate in its path because there
is some qualifier merging with the source at some point. You can put a
qualifier to control the metastability in the path. However, it might happen
that because of the combo gate glitch is blocked or not blocked by the
qualifier.
Consider the following example:

FIGURE 12. Glitch on synchronized data path

The above example is a case of glitch only as metastability is taken care of


by synchronizing the above crossing by the qualifier.
In the above example the crossing from S1 to D1 is synchronized using the
qualifier and therefore there is no metastability issue in the path. But the
path from S1 to D1 has glitch issue. In the above example, since S1
diverges and converges back at C0, glitch is produced at C0 because of
different delay in path D0 and I1. Now this glitch propagates downstream
which might cause functional failure. But the glitch can be blocked using
the same qualifier (CK2). Therefore, the output of C1 can be made stable
using the same qualifier and is a good value to pass to D1.

Glitch on Unsynchronized Path

407
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Types of Glitches in a Design

Consider the following example:

FIGURE 13. Glitch on Unsynchronized data path

The above crossing from S1 to D1 is a case of both metastability and glitch.


Metastability because qualifier is invalid and glitch because the qualifier
cannot block the glitch produced at C0.

408
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Performing Glitch Checks

Performing Glitch Checks


The prerequisites for performing glitch checks are:
 The design must be read and elaborated
 The SDC commands must be read
 Auto inference of clocks is completed (if needed)
 Clock propagation is completed with user-defined clocks and auto-
inferred clocks
 CDC crossings have been detected
 CDC synchronizers have been detected
Use the check_cdc -type struct command to perform glitch checks.

409
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Debugging Glitch Violations


The following section describes all the violations reported by glitch checks.

410
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

CDC_GLITCH_CTRLPATH
(Alias: CDC_GLITCH_CTRL)

Severity
Error

Short Help
Glitch found on control crossing paths

Description
VC SpyGlass CDC reports this tag when glitches are detected on the
crossing from the source to destination, when the path can be identified as
synchronized by NFF, sync cell paths scheme, and not by a qualifier.
NOTE: When a single non-quasi source is reaching the output port through a combinational
logic, which is generated as -single_non_quasi argument of the
set_connectivity_attribute command, the combo mismatch violation is not
reported because of the combo logic inside the block.
The tag reports the following reason codes:
 GLITCH_SOURCE_RECONVERGES
 GLITCH_SOURCES_FROM_DIFF_DOMAIN
 GLITCH_SOURCES_FROM_SAME_DOMAIN
 GLITCH_SOURCE_UNCONSTRAINED

GLITCH_SOURCE_RECONVERGES
This reason code is reported if an asynchronous source reaches its
destination through multiple paths. In the example schematic in Figure 14,
the source diverges and multiple paths reconverge before reaching the
destination.

411
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

FIGURE 14.

Consider another schematic and the structure of a mux as shown in


Figure 15.

FIGURE 15.

412
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

In this case, this reason code is reported because the mux structures are
glitchy in nature as shown in Figure 15.
If you are using glitch-free mux in the design, use the
configure_glitch_free_cells command to define GLITCH free muxes.

What Next
Different paths of same sources might have different timing delay and
therefore when the paths reconverge, it might introduce glitch. To fix this,
perform either of the following:
 Modify the design so that the reported source reaches its destination
through a single path.
 You can review the reconvergence paths where the polarity changes
using the positive/negative/mixed annotation in the schematic. Ensure
that the timing delays of all the paths are same.

GLITCH_SOURCES_FROM_DIFF_DOMAIN
This reason code is reported if asynchronous sources from different
domains converge and reach the destination a shown in Figure 16.

FIGURE 16.

What Next
Different sources might have different timing delays on their paths before

413
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

they converge, and therefore it might introduce a glitch at the convergence


point. To fix this, perform either of the following:
 Ensure that the setup of clocks is correct.
 Check if a source in other domain is quasi-static.
 If the above two conditions are satisfied, then you might need to fix the
design.

GLITCH_SOURCES_FROM_SAME_DOMAIN
This reason code is reported if asynchronous sources from same domains
converge and reach the destination.

FIGURE 17.

What Next:
Different sources might have different timing delay of their paths before
they converge and therefore it might introduce a glitch at the convergence
point. To fix this, perform either of the following:
 Check if one of the sources is quasi-static.
 Modify the design to fix it.

414
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

GLITCH_SOURCE_UNCONSTRAINED
This reason code is reported when an unconstrained port merges with an
asynchronous source and reaches the destination. This is reported under
the below option:
configure_cdc_glitch -glitch_on_unconstrained_src

FIGURE 18.

What Next:
Different sources might have different timing delay of their paths before
they converge and therefore it might introduce a glitch at the convergence
point. To fix this, perform either of the following:
 Check if one of the sources is quasi-static.
 Modify the design to fix it.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.
 configure_cdc_static: Configures quasi-static signals for CDC
analysis.

415
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

 configure_glitch_free_cells: Configures cells to control pessimism


in glitch analysis.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

416
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

CDC_GLITCH_DATAPATH
(Alias: CDC_GLITCH_DATA)

Severity
Info

Short Help
Glitch found on data crossing paths.

Description
VC SpyGlass CDC reports this tag when glitches are detected on the
crossing from the source to destination, when the path can be identified as
synchronized by a qualifier/enable (synchronized signal in the same clock
domain as destination).
The tag reports the following reason codes:
 GLITCH_SOURCE_RECONVERGES
 GLITCH_RECONVERGNCE_AFTER_BLOCKING
 GLITCH_SOURCES_BLOCKED

GLITCH_SOURCE_RECONVERGES
This reason code is reported if the data path crossing of an asynchronous
source reaches its destination through multiple paths. The source diverges
and multiple paths converge before reaching the destination as shown in
Figure 19.

417
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

FIGURE 19.

Consider another schematic and the structure of a mux as shown in

418
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Figure 20.

FIGURE 20.

In this case, this reason code is reported because the mux structures are
glitchy in nature as shown in Figure 20.
If you are using glitch-free mux in the design, use the
configure_glitch_free_cells command to define GLITCH free muxes.

What Next
This is reported for information purpose and indicates that there is glitch-
prone logic in the design.

419
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

You can review the reconvergence paths where the polarity changes using
the positive/negative/mixed annotation in the schematic. Ensure that the
timing delays of all the paths are same.

GLITCH_RECONVERGNCE_AFTER_BLOCKING
This reason code is reported for a data path crossing if an asynchronous
source reaches its destination through multiple paths. The source diverges
and multiple paths converge after the qualifier gate and reaches the
destination as shown in Figure 21.

FIGURE 21.

What Next
This is a warning message and indicates that there is glitch-prone logic in
the design.
You can review the reconvergence paths where the polarity changes using
the positive/negative/mixed annotation in the schematic. Ensure that the
timing delays of all the paths are same.

GLITCH_SOURCES_BLOCKED
This reason code appears for a data path crossing if an asynchronous
source reaches its destination through multiple paths. The source diverges
and multiple paths converge before the qualifier gate and reaches the

420
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

destination. Since the introduced glitch is isolated by qualifier logic at AND


gate (blocking gate), it would not cause any problem in the design as
shown in Figure 22.

FIGURE 22.

What Next
This is reported for information purpose and indicates that there is glitch-
prone logic in the design, but it is structurally blocked by the qualifier.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.
 configure_cdc_static: Configures quasi-static signals for CDC
analysis.
 configure_glitch_free_cells: Configures cells to control pessimism
in glitch analysis.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

421
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

422
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

CDC_GLITCH_UNSYNC
(Alias: CDC_GLITCH_UNSYNC)

Severity
Error

Short Help
Glitch found on unsynchronized crossing paths.

Description
VC SpyGlass CDC reports this tag if glitches are detected on the crossing
from the source to destination or when it cannot be identified as a
synchronized crossing. This includes scenarios where synchronization
information is unavailable.
NOTE: When a single non-quasi source is reaching the output port through a combinational
logic, which is generated as -single_non_quasi argument of the
set_connectivity_attribute command, the combo mismatch violation is not
reported because of the combo logic inside the block.
The tag reports the following reason codes:
 GLITCH_SOURCE_RECONVERGES
 GLITCH_SOURCES_FROM_DIFF_DOMAIN
 GLITCH_SOURCES_FROM_SAME_DOMAIN
 GLITCH_SOURCES_UNBLOCKED
 GLITCH_SOURCE_UNCONSTRAINED

GLITCH_SOURCE_RECONVERGES
This reason code appears for unsynchronized crossing if an asynchronous
source reaches its destination through multiple paths. The source diverges
and multiple paths converges before reaching at destination as shown in

423
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Figure 23.

FIGURE 23.

Consider another schematic and the structure of a mux as shown in


Figure 24.

FIGURE 24.

424
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

In this case, this reason code is reported because the mux structures are
glitchy in nature as shown in Figure 24.
If you are using glitch-free mux in the design, use the
configure_glitch_free_cells command to define GLITCH free muxes.

What Next
Different paths of same sources might have different timing delay and
therefore when they reconverge, it might introduce a glitch. To fix this,
perform either of the following:
 Modify the design so that the reported source reaches its destination
through a single path.
 You can review the reconvergence paths where the polarity changes
using the positive/negative/mixed annotation in the schematic. Ensure
that the timing delays of all the paths are same..

GLITCH_SOURCES_FROM_DIFF_DOMAIN
This reason code is reported for an unsynchronized crossing if
asynchronous sources from different domains converge and reach the
destination as shown in Figure 25.

FIGURE 25.

What Next
Different sources might have different timing delay before they converge
and therefore it might introduce a glitch at the convergence point. To fix
this, perform either of the following:

425
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

 Ensure that the setup of clocks is correct.


 Check if a source in other domain is quasi-static.
 If the above two conditions are satisfied, then you might need to fix the
design.

GLITCH_SOURCES_FROM_SAME_DOMAIN
This reason code is reported for an unsynchronized crossing if
asynchronous sources from same domains converge and reach the
destination as shown in Figure 26.

FIGURE 26.

What Next
Different sources might have different timing delay before they converge
and therefore it might introduce a glitch at the convergence point. To fix
this, perform either of the following:
 Check if one of the sources is quasi-static.
 Modify the design to fix it.

426
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

GLITCH_SOURCES_UNBLOCKED
This reason code is reported for an unsynchronized crossing that has an
invalid qualifier if an asynchronous source reaches its destination through
multiple paths. The source diverges and multiple paths converge before
reaching at destination as shown in Figure 27.

FIGURE 27.

What Next
Different paths of same sources might have different timing delay and
therefore when they reconverge, it might introduce a glitch. To fix this,
perform either of the following:
 Modify the design so that the reported source reaches its destination
through a single path.
 Ensure that timing delays of all paths from where source reaches the
destination are same.

GLITCH_SOURCE_UNCONSTRAINED
This reason code is reported for an unsynchronized crossing when an
unconstrained port merges with an asynchronous source and reaches the
destination. This is reported under the below option:
configure_cdc_glitch -glitch_on_unconstrained_src

427
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

FIGURE 28.

What Next
Different sources might have different timing delay of their paths before
they converge and therefore it might introduce a glitch at the convergence
point. To fix this, perform either of the following:
 Check if one of the sources is quasi-static.
 Modify the design to fix it.

Related Command(s)
 configure_cdc_glitch: Configures glitch checking criteria.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.
 configure_cdc_static: Configures quasi-static signals for CDC
analysis.
 configure_glitch_free_cells: Configures cells to control pessimism
in glitch analysis.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

428
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.

429
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

RESET_PATH_GLITCH

Severity
Warning

Short Help
PinType pin of sequential element DestReset is driven by combinational
logic.

Description
A glitch on a combinational gate can occur whenever the two signals toggle
simultaneously or when the same signal re-converges through non-
unateness.
It is important for the design endpoints to be safe from glitches i.e. an
asynchronous reset should never have a glitch that momentarily resets a
flop. Such glitches on the reset pin can lead to metastable state and an
eventual chip failure.
Some glitches on the reset pin of a flip-flop might result in a metastable
state. For example, consider an active low reset pin. A glitch of the form
010 on the logic driving the active low reset pin does not result in a
metastable state as shown in the Fig 1 below. However, a glitch of the form
101 on the active low reset pin can cause metastable behavior as shown in
the Fig 2 below.

430
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

VC SpyGlass CDC identifies the kind of glitch, "010' or "101" that is


produced at the gate to categorize the glitch as critical glitch or non-critical
glitch for the destination flop's reset pin.
The following types of Glitch can be produced on basic AND-OR multi input
gates:
 AND GATE: It could produce '010" type of glitch only as shown in the
following Figure.

 OR GATE: It could produce "101" type of glitch only as shown in the


following Figure.

Similarly, VC SpyGlass CDC can deduce the glitch type produce by different
gates as shown in the following table.
Gate Glitch Type
AND 010
OR 101
NAND 101
NOR 010
XOR 010/101
XNOR 010/101
MUX 010/101

For example, consider the following logic driving the active-low reset pin of
a flip-flop:

431
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

In the above logic flop is active low reset so any glitch of type "101" on the
reset pin would result in flop output to go metastable. Here glitch produced
on gate 'G2' (AND GATE) would be of type "010" and is non-critical glitch
for the destination flip-flop. However, in the fan-in of gate G2 there exist an
OR gate (G1) where glitch of type "101" could be produced and which can
be then propagated through gate 'G2' to reach active low reset pin of flip-
flop causing it to go in metastable state. Thus, here gate 'G1' is critical
glitch ("010") producing gate.
Detection of critical glitches in the reset path is important to avoid design
metastability issues. VC SpyGlass CDC reports this tag if critical glitches
exist in the reset path. The tag reports all the sources which can potentially
create a glitch.
The exclusive combinational gates, such as XOR and MUX, are taken care
of to make sure that the glitch can come inside such combinational gates
due to re-convergence inside their gate functionality.
The tag is disabled by default. Use the configure_cdc_tag -enable
command to enable it.

What Next
Combinational logic may cause a glitch on the reset path and it may
result in functional failure.
Review the glitch producing sources and critical gates. The glitch producing
gate is highlighted for root causing the glitch path correctly. You can review
and make sure that the signals are gray encoded or do not change
simultaneously.

432
Synopsys, Inc. Feedback
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

Related Command(s)
None

Related App-var(s)
None

433
Feedback Synopsys, Inc.
VC SpyGlass CDC Glitch Checks

Debugging Glitch Violations

434
Synopsys, Inc. Feedback
VC SpyGlass CDC
Hierarchical Flow

With rapidly growing designs sizes, performing CDC analysis in one go at


the SoC level is challenging because of performance/capacity, report
volumes, and alignment with design cycle issues.
Design development cycles usually follow the bottom-up approach.
Hierarchical CDC approach is best suited for such development cycle. The
approach is efficient in managing CDC reports because design blocks are
locally signed-off and the SoC integration team reviews the CDC-reports at
SoC level only.
The new hierarchical flow in VC SpyGlass CDC is based on design
abstraction approach to generate accurate top-level CDC reports, which are
similar to the reports generated in a flat run but excludes the block-level
reports. Design abstraction retains the relevant design intent for top-level
analysis to achieve this accuracy. With this approach, schematic debug is
easier with full design view for CDC logic scope and does not require the
user to iteratively run the block level to debug as required in the
conventional approach.
In the new flow, VC SpyGlass CDC creates an abstract-relevant structural
logic of block which can be part of top-level CDC analysis as shown in
Figures 29. This generated abstract model is a structural Netlist model in
binary format and is called Sign-off Abstract Model (SAM).
NOTE: SAM will be compatible between Patch releases/Service Pack releases of a major

435
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

release unless specified. However, SAM backward compatibility across major


releases is not guaranteed. Therefore, migrating to new major release version
might involve additional migration tasks.
The new flow addresses the challenges of the current conventional
hierarchical CDC flow by achieving reporting accuracy and performance
gains at the top-level CDC runs.

FIGURE 29. Static Abstract Model

Advantages of SAM Based Hierarchical Flow


The SAM-based hierarchical flow offers the following advantages:
 The top-level CDC run reports generated in the new flow is the same as
flat run reports without the block-level reports. Therefore,
{HIER TOP-REPORTS} == {FLAT-RUN TOP-REPORTS - BLOCK-
REPORTS}

436
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

This ensures 100% sign-off in hierarchical approach and therefore users


can convincingly adopt this as sign-off flow.
 Built-in flow in VC SpyGlass CDC to match reports with flat run. This
feature is used to qualify and sign-off SAM Hierarchical Flow QoR. This
flow also provides a measure to ensure that no CDC bug is missed with
the SAM based hierarchical flow as compared to flat runs.
 Block SAMs are loaded as part of design elaboration at the top-level
runs and remaining flow is the same as flat run. Therefore, SAM-based
hierarchical flow provides more stability and is less error-prone as
compares to the conventional flow.
 SAM-based hierarchical flow provides improved waiver applicability
across flows. With existing hierarchical flow, waivers created during
hierarchical runs cannot be applied to final flat run because they contain
references abstracted boundary ports. However, waivers created in the
SAM-based flow, which retains CDC relevant objects, can be
transformed to apply to flat run, if needed. The applicability of the
waivers can be improved with some simple utilities with Tcl query in VC
Static.
 Encrypted modules are automatically supported and do not require any
special handling in the SAM-based hierarchical flow.
 Supports boundary and black box modeling by using CDC attribute
commands.
 Provides backward compatibility by enabling users to regenerate
abstract models for their blocks so that users can benefit from the
advantages of the SAM-based hierarchical flow.

Licensing Requirements
The SAM-based hierarchical flow requires the VC-CDC-BASE license keys.

437
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

CDC Abstraction Model


The design logic abstracted for CDC includes the logic involved and
therefore absorbs the potential differences in block-level constraints
against the top-level propagated constraints for block at top-level runs.
The logic structure is retained as SAM in the following scenarios:
 Paths with either source or destination inside block scope
 Convergence violation in block with NFF Sync/Control paths in top-level
logic and vice versa
 Top-level data paths synchronized by qualifier/control path in block
scope and vice versa
 Quasi static propagated path
 SCA propagated constant path
 Paths from constraint such as src_qualifier and des_qual of
configure_cdc_glitch that reach ports or preserved sequential from
other steps
 Apart from structural logic, basic constraint information is also included
for simple crosschecking with top-level constraints

Use Model
CDC analysis by using the hierarchical CDC approach involves:
 Generating the Abstract Model
 Specifying the SAM Model

Generating the Abstract Model


After the block-level reports are generated and signed-off, use the
create_cdc_abstract_model command in the same session (post
check_cdc) to initiate creation of the abstract model. Next, use the
write_abstract_model command to generate the abstract model. Use the

438
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

set_app_var enable_abstraction true command to enable this flow.

FIGURE 30. Enabling Abstract Generation

#Block Run to Sign-Off Reports #Block Run to Sign-Off Reports


# Design Libraries # Design Libraries
set_app_var search_path ... set_app_var search_path ...
set_app_var link_library ... set_app_var link_library ...
set_app_var enable_abstraction true
# Load Design and Constraints # Load Design and Constraints
analyze ... analyze ...
elaborate ... elaborate ...
read_sdc<dc_setup>.sdc read_sdc<dc_setup>.sdc
source <cdc_config>.tcl source <cdc_config>.tcl
configure_cdc_abstract_model
# Run CDC/RDC
# Run CDC/RDC check_cdc
check_cdc create_cdc_abstract_model
write_abstract_model -path <path>
# View/Analyze Reports
# View/Analyze Reports report_cdc
report_cdc view_activity

Configuring the Abstract Model


Use the configure_cdc_abstract_model command to configure design
abstraction.

Specifying the SAM Model


Specify the SAM model by module/instance before top level elaboration
using the set_abstract_model Tcl command. This command is used

439
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

during top level run when the abstract models are to be linked instead of
original, VC SpyGlass CDC automatically links the abstract models for block
instances. If the set_abstract_model command is specified after design
elaboration, the abstract models will not be linked.
NOTE: If you run only check_cdc, the abstraction contains only CDC-specified design
structure.
Figures 31 shows the difference between a top-level flat run and a top-
level hierarchical run.

FIGURE 31. Comparing top-level flat run and a top-level hierarchical run

The following is the syntax of the set_abstract_model Tcl command:


set_abstract_model
[-app <application name>]
[-module <block_module_name>]
[-path <abstract_location>]
[-user_mode <mode_name>]

440
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

[-instances <list_of_instance_names>]
[-enable_auto_abstraction]
Arguments:
 -app: Specifies the application which SAM flow will be invoked.
Supported applications include lp, cdc, rdc, and lint. If not specified,
non-lp flow is used.
 -module: Specifies the module for which abstract models needs to be
loaded.
 -path: Specifies the Unix path from which abstract models needs to be
searched and read.
 -user_mode: Use this argument if abstract models were written with -
mode option.
 -instances: Link only specific instances with the abstract model. It is
useful to link specific instances when -user_mode is used or when
linking to abstraction generated for specific parameter value
combination.
 -enable_auto_abstraction: Use this argument to enable auto
abstraction of parameterized module instances.

QoR Validation
You can compare the VC SpyGlass CDC reports generated after a
hierarchical run and flat run. VC SpyGlass CDC compares the violations
only from the sync, conv, and glitch stage from the hierarchical run set up
and the flat run setup.
During the top-level run, the following constraints that are specified at the
block level are automatically applied at the top level:
 set_case_analysis
 create_static
 configure_cdc_convergence -ignore_among_signals
 configure_cdc_data_sync -ignore_des_qual
Therefore, the block-level constraints are validated against the top-level
environment. As part of validation checks, VC SpyGlass CDC reports any
mismatch between the block-level constraints and the constraints in the

441
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

environment of the block instance during the top-level run. Refer to the
Validation Checks - Block Constraints Vs Top-Level Constraints section for
validation checks.
For comparing the reports, VC SpyGlass CDC assumes that the block
internal violations are signed off during the block-level run. Therefore, VC
SpyGlass CDC does not report the block internal violations during the top-
level run. VC SpyGlass CDC uses the following rationale for comparing the
reports from the flat level runs and the hierarchical runs:
Hierarchical Top Run Violation - Block Internal Violations = Flat Run
Violations - Block Internal Violations
Ensure that there are no validation check violations before you initiate the
comparison. For this comparison method, it is essential that all violations
from the sync, conv, and glitch stage have the ContainerScope debug
field.
From the flat-run report database, waive off the violations contained within
the block. Similarly, from the hierarchical top-run report database, waive
off the violations contained within the block using the ContainerScope
debug field.
For waiving violations contained within block, use the following Tcl
command:
waive_cdc_block_violations -blocks
<list_of_block_module_names>
After the waive_cdc_block_violations command completes the run,
save the report in xml format by using the report_cdc command for both
the flat and hierarchical-level runs:
report_cdc -stage "sync conv glitch" -xml -verbose -limit 0 -
file <file_name>.xml

Comparing Violations
You can generate the reports for the three stages separately as well and
compare the reports for each stage separately. Use the
compare_violations command for comparing the violation reports.
compare_violations -implementation_run top_flat_report.xml -
reference_run top_sam_report.xml -app cdc_general -
debug_priority config.xml -output_dir <outDir> -split

442
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

For sync, conv, and glitch tags, the config.xml file is stored at the
following location:
$VC_STATIC_HOME/auxx/cdc/config.xml

Validation Checks - Block Constraints Vs Top-Level


Constraints
As part of block abstraction, the constraints related to clock, reset,
set_case_analysis and quasi static, qualifier constraints, configure_cdc_*
global values are also included in the abstracted block. During top-level
abstraction, when abstract models are linked, VC SpyGlass CDC
automatically reads the SAM constraints.
However, these constraints are not used for verification. These constraints
are only used for validation to check if the constraints reaching the block
instance boundary (or internal object, if constraints was defined on internal
object) during the hierarchical top-level run matches the constraints which
were used during abstraction of the block.
The following validation checks are performed at the block boundary and
internal design objects, when needed:
 Clock mismatch: The following scenarios are validated:
 A block port is defined as clock during block abstraction. However, no
top-level clock reaches the relevant pin of the abstract block
instance.
 Clocks are defined on an internal design object during block run but
no top-level clock reaches the design object in top run.
 No clock is defined on the block port during block abstraction.
However, a top-level clock reaches the relevant pin of the abstract
block instance.
 A pair of clocks are defined as asynchronous (or synchronous) at the
block level during abstraction. However, at the top-level, the
relationship of those pair of clocks are different. For example, at the
top level, the clock pair is synchronous (or asynchronous).
 Reset mismatch: The following scenarios are validated:

443
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

 A block port is defined as reset during block abstraction. However, no


top-level reset reaches the relevant pin of the abstract block
instance.
 Resets are defined on an internal design object during block run but
no top-level reset reaches the design object in top run or there is a
mismatch of reset reaching to the design object.
 No reset defined on the block port during block abstraction. However,
a top-level reset reaches the relevant pin of the abstract block
instance.
 The reset attributes are different between the block-level run and the
top-level run.
 Constant (SCA) mismatch: The following scenarios are validated:
 A block port was constrained with SCA value during block abstraction.
However, no constant value from the top level reaches the relevant
pin of the abstract block instance.
 SCA is defined on an internal design object during block run but no
top-level constant reaches the design object in the top run or there is
a mismatch in constant values at design object.
 No SCA is defined on the block port during block abstraction.
However, from the top-level, constant value reaches the relevant pin
of the abstract block instance.
 The constant value is different between the block-level run and the
top-level run.
 Quasi static mismatch: The following scenarios are validated:
 A block port is constrained as quasi static during the block
abstraction. However, at the top level, no quasi static constraint
reaches the relevant pin of the abstract block instance.
 Quasi static constraint is defined on an internal design object during
block run but no top-level quasi static reaches the design object in
top run.
 No quasi static constraint is defined on the block port during the
block abstraction. However, from the top level, quasi static constraint
reaches the relevant pin of the abstract block instance.
 Configure values mismatch: The following scenarios are validated:

444
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

 If there is a mismatch of global values of configure_cdc_* commands


between block run and top-level run, VC SpyGlass CDC reports a
mismatch. VC SpyGlass CDC compares and reports the following
values if there is a mismatch:
 configure_cdc_convergence -cdc_conv_seq_depth_max
 configure_cdc_convergence -
cdc_diverge_src_seq_depth_max
 configure_cdc_nff_sync -depth
 configure_cdc_data_sync -des_qual_depth (global and max
qualifier depth)
 configure_cdc_asyncrst_nff_sync -depth
 configure_cdc_asyncrst_data_sync -des_qual_depth (global
and max asynchronous reset qualifier depth)
 configure_cdc_glitch -glitch_on_vck_port
 configure_cdc_glitch -multi_src_check_type
 Unconstrained block ports validation: The following scenarios are
validated:
 A port is unconstrained during block run but is being driven by
sequential element in top.
NOTE: By design, SAM abstraction flow intends to catch all interface related CDC issues at
top-level run. The scope of supported validation checks to validate only those
constraints, which otherwise would result in different abstraction model.

445
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

Debugging Validation Check Violations


The following section describes all the violations reported by validation
checks.

446
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_CLOCK_MISMATCH
Severity
Warning

Short Help
Mismatch in create_clock constraint applied on design-object between top
level and block level

Description
VC SpyGlass CDC reports this tag if there is a mismatch between the
create_clock constraint specified on design objects at the block level and the
design objects at the top level.
This tag reports the following reason codes:
 NO_TOP_LEVEL_CLOCK
 NO_BLOCK_LEVEL_CLOCK

NO_TOP_LEVEL_CLOCK
This reason code is reported if no top-level clock propagates to the block
level though a clock is defined at the block level as shown in Figures 32.

FIGURE 32.

447
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
If the user has missed to constraint an actual top-level clock by clock
constraint, the CDC verification might be inaccurate.
 Make sure that the top-level constraint file has all the required clock
constraints.
 Make sure that the clock coming from top-level is not blocked by
incorrect logic before reaching to the block port.
 Make sure that the block port defined as the clock is an actual clock.
Else, remove the block-level clock constraint.

NO_BLOCK_LEVEL_CLOCK
This reason code is reported if a top-level clock reaches to a clock port of a
block, but that block-level clock port is not constrained by the clock
constraint as shown in Figures 32.

FIGURE 33.

What Next
Make sure that the block-level constraint file has all the required clock
constraints. Otherwise specify the missing clock constraint. Also, check if
the defined clock at the top level is an actual clock. Else, remove the top-
level clock constraint.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.

448
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 create_cdc_abstract_model: Creates in-memory CDC abstract model


from block-level run.

Related App-var(s)
None

449
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_CLOCK_DOMAIN_MISMATCH
VC SpyGlass CDC reports this tag due to one of the reasons which are
described in the reason codes below.
Prerequisites
This is applicable when user is performing CDC verification using VC
SpyGlass CDC hierarchical flow. This validation check violation comes when
abstract model of some subsystem are used at the top level for the
verification and there is mismatch of <constraint> between the one which
was used during the abstract model generation of the subsystem and the
surrounding environment where the abstract model is used at the top level.
This tag reports the following reason codes:
 TOP_SYNC_BLOCK_ASYNC
 TOP_ASYNC_BLOCK_SYNC

TOP_SYNC_BLOCK_ASYNC
This can occur when multiple clock ports in different domains of an abstract
view are triggered from the top-level clocks of the same domain.

What Next
If top-level clocks of the same domain trigger block ports of different
domains, it might result in spurious synchronization results during
verification phase of higher-level blocks. Therefore, the user should take
below actions.
 Verify the specification of different domains on multiple clock ports
 Analyze the specification or propagation of the top-level clock.

TOP_ASYNC_BLOCK_SYNC
This can occur when any of the following cases are true.
 If multiple clock ports in the same domain of an abstract view are
triggered from top-level clocks of different domains.
 If virtual clocks <virtual-clock1> and <virtual-clock2> specified at the
ports <block-port1> and <block-port2>, respectively, are in the same

450
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

domain of an abstract view and are triggered from top-level clocks of


different domains.

What Next
If block-level clocks of the same domain are triggered by top-level clocks of
different domains, it might result in incorrect synchronization results
during verification phase of higher-level blocks. Therefore, take the
following actions.
 Analyze the specification or propagation of top-level clocks.
 Ensure that the specification of the same domain virtual clocks is
consistent with the specification of top-level clocks identified in the first
step.

Related Command(s)
 set_abstract_model: Associates abstract block model in the top level.

Related App-var(s)
None

451
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_RESET_MISMATCH
VC SpyGlass CDC reports this tag if there is a mismatch between the
create_reset constraint specified on design objects at the block level and
the design objects at the top level.
This tag reports the following reason codes:
 NO_TOP_LEVEL_RESET
 NO_BLOCK_LEVEL_RESET
 RESET_TYPE_MISMATCH
 RESET_SENSE_MISMATCH

NO_TOP_LEVEL_RESET
VC SpyGlass CDC reports this tag if no top-level reset propagates to the
block level though a reset is defined at the block level.

What Next
 Make sure that the top-level constraint file has all the required reset
constraints.
 Make sure that the reset coming from top-level is not blocked by
incorrect logic before reaching to the block port.
 Make sure that the block port defined as the reset is an actual reset.
Else, remove the block-level reset constraint.

NO_BLOCK_LEVEL_RESET
VC SpyGlass CDC reports this tag if the top-level reset propagates to the
block level, but no reset is defined at the block level. Due to this, some
potential resets might not propagate during the verification of the abstract
view.

What Next
Make sure that the block-level constraint file has all the required reset
constraints. Else, specify the missing reset constraint. In addition, check if
the defined reset at the top level is an actual reset. Else, remove the top-

452
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

level reset constraint.

RESET_TYPE_MISMATCH
VC SpyGlass CDC reports this tag if a top-level asynchronous reset reach a
synchronous reset port of the abstracted block or vice-versa.

What Next
Specify an appropriate reset constraint on the block-level port. In addition,
analyze the specification or propagation of the top-level reset to the block.

RESET_SENSE_MISMATCH
VC SpyGlass CDC reports this tag if the active value of the top-level reset is
different from the active value of the block-level reset port driven by that
top-level reset. This might result in an incorrect initial state of an abstract
view during verification.

What Next
Check the value specified by the reset constraint on the block port and
verify that the top-level reset of the block port has the same active value
as the block port.

Related Command(s)
 set_abstract_model: Associates abstract block model in the top level.

Related App-var(s)
None

453
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_STATIC_MISMATCH
Severity
Warning

Short Help
Mismatch in create_static constraints applied on design-object between
top level and block level

Description
VC SpyGlass CDC reports this tag if there is a mismatch between the
create_static constraint specified on design objects at the block level
and the design objects at the top level.
This tag reports the following reason codes:
 NO_TOP_LEVEL_STATIC
 NO_BLOCK_LEVEL_STATIC

NO_TOP_LEVEL_STATIC
This reason code is reported if a create_static constraint is specified at a
block-level port and no top-level quasi-static signal is driving the block port
as shown in Figures 34.

FIGURE 34.

454
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
Add the missing create_static constraint at top-level if the quasi-static
specification for the block port is correct. Else, remove the create_static
constraint from the block port.

NO_BLOCK_LEVEL_STATIC
This reason code is reported if a top-level static signal reaches a block pin
which is not defined as static as shown in Figures 34.

FIGURE 35.

What Next
Specify the create_static constraint on the block port. In addition,
analyze the specification or propagation of the top-level signal to the block
port.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.
 create_cdc_abstract_model: Creates in-memory CDC abstract model
from block-level run.

Related App-var(s)
None

455
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_CONSTANT_MISMATCH
Severity
Warning

Short Help
Mismatch in set_case_analysis constraints applied on design-object at top
level and block level

Description
VC SpyGlass CDC reports this tag if there is a mismatch between the
set_case_analysis constraint specified on design objects at the block level
and the design objects at the top level.
This tag reports the following reason codes:
 NO_TOP_LEVEL_CONSTANT
 NO_BLOCK_LEVEL_CONSTANT
 CONSTANT_VALUE_MISMATCH

NO_TOP_LEVEL_CONSTANT
This reason code is reported when a constant value does not reach to a
top-level net connected to a block-level port, but the set_case_analysis

456
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

constraint is specified on the block-level port as shown in Figures 36.

FIGURE 36.

What Next
To resolve this issue user should take below actions.
 Analyze the top-level design for propagation of a constant value to the
block port.
 Remove the set_case_analysis constraint if a valid constant value does
not reach the block port.

NO_BLOCK_LEVEL_CONSTANT
This reason code is reported when a constant value reaches a top-level net
connected to a block-level port, but no set_case_analysis constraint is
specified on the block-level port as shown in Figures 37.

457
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

FIGURE 37.

What Next
To resolve this issues user should take below actions.
 Analyze the top-level design for propagation of a constant value to the
block port.
 Specify the set_case_analysis constraint on the block port.

CONSTANT_VALUE_MISMATCH
This can occur when there is a mismatch between the constant value
specified by set_case_analysis constraint on a block port and the constant
value propagated from top level to the same block port as shown in
Figures 38.

458
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

FIGURE 38.

This can lead to the following consequences:


 If the specified value at the block-level port is incorrect, block-level CDC
verification is inaccurate.
 If the specified value at the block-level port is correct but constant
propagation at the top-level is incorrect, it indicates a logical issue at
the top-level because of which incorrect value is propagated at the
block-level.

What Next
To resolve this issue, perform the following:
 Check the value specification of the set_case_analysis constraint on a
block port.
 Analyze the top-level design for propagation of a constant value to the
block port.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.
 create_cdc_abstract_model: Creates in-memory CDC abstract model
from block-level run.

459
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

Related App-var(s)
None

460
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_CONFIG_VAL_MISMATCH
Severity
Warning

Short Help
Mismatch in configuration values applied on design objects at top level and
block level

Description
VC SpyGlass CDC reports this tag if any there is any mismatch in the global
configuration values of CDC constraints applied on design objects at top
level and block level.
CDC analysis can be configured by using various configuration values. The
configuration values used in the block abstraction and during the top-level
run must match or VC SpyGlass CDC might miss reporting violations or
additional violations can be reported.
The tag reports the following reason codes:
 CONV_SEQ_DEPTH_VALUE_MISMATCH
 CONV_DIV_SRC_SEQ_DEPTH_VALUE_MISMATCH
 CDC_DATA_SYNC_DES_QUAL_DEPTH_VALUE_MISMATCH
 CDC_DATA_SYNC_MAX_DES_QUAL_DEPTH_VALUE_MISMATCH
 CDC_NFF_SYNC_DEPTH_VALUE_MISMATCH
 RST_DATA_SYNC_DES_QUAL_DEPTH_VALUE_MISMATCH
 RST_DATA_SYNC_MAX_DES_QUAL_DEPTH_VALUE_MISMATCH
 RST_NFF_SYNC_DEPTH_VALUE_MISMATCH
 CDC_GLITCH_ON_VCLK_PORT_VALUE_MISMATCH
 CDC_GLITCH_MULTI_SRC_CHECK_VALUE_MISMATCH

CONV_SEQ_DEPTH_VALUE_MISMATCH
This can occur when there is a mismatch between the
configure_cdc_convergence -cdc_conv_seq_depth_max values specified

461
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

at the top level and block level.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

CONV_DIV_SRC_SEQ_DEPTH_VALUE_MISMATCH
This can occur when there is a mismatch between the
configure_cdc_convergence -cdc_diverge_src_seq_depth_max values
specified at the top level and block level.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

CDC_DATA_SYNC_DES_QUAL_DEPTH_VALUE_MISMATCH
This can occur if the default qualifier depth specified for the top level and
block level using configure_cdc_glitch -des_qual_depth do not match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

CDC_DATA_SYNC_MAX_DES_QUAL_DEPTH_VALUE_MISMATCH
This can occur if the max qualifier depth specified for the top level and
block level by using the configure_cdc_glitch -des_qual_depth
command do not match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

462
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

CDC_NFF_SYNC_DEPTH_VALUE_MISMATCH
This can occur if the values specified with the configure_cdc_port -
depth command for the top level and the block level do not match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

RST_DATA_SYNC_DES_QUAL_DEPTH_VALUE_MISMATCH
This can occur if the default qualifier depth value specified with the
configure_cdc_asyncrst_data_sync -des_qual_depth command for the
top level and the block level do not match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

RST_DATA_SYNC_MAX_DES_QUAL_DEPTH_VALUE_MISMATCH
This can occur if the max qualifier depth value specified with the
configure_cdc_asyncrst_data_sync -des_qual_depth command for the
top level and the block level do not match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

RST_NFF_SYNC_DEPTH_VALUE_MISMATCH
This can occur if the value specified with the
configure_cdc_asyncrst_nff_sync -depth command for the top level
and the block level do not match.

463
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

CDC_GLITCH_ON_VCLK_PORT_VALUE_MISMATCH
This can occur if the value specified with the configure_cdc_glich -
glitch_on_vck_port command for the top level and the block level do not
match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

CDC_GLITCH_MULTI_SRC_CHECK_VALUE_MISMATCH
This can occur if the value specified with the configure_cdc_glitch -
multi_src_check_type command for the top level and the block level do not
match.

What Next
To resolve this issue, make sure that the setup has similar values in cdc
constraints applied to both top and block level.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.
 create_cdc_abstract_model: Creates in-memory CDC abstract model
from block-level run.

Related App-var(s)
None

464
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_PORT_CONSTRAINT_MISMATCH
Severity
Warning

Short Help
Unconstrained ports driven by sequentials

Description
VC SpyGlass CDC reports this tag if an unconstrained block port is being
driven by a sequential element. This might cause some CDC bugs to be
missed because the required logic may not be specified in the abstracted
block.
The tag reports the following reason code(s):
 BLOCK_PORT_CONSTRAINT_MISMATCH

BLOCK_PORT_CONSTRAINT_MISMATCH
This reason code is reported if an unconstrained block port is driven by
sequential at the top level as shown in Figures 39. This might cause some
CDC bugs to be missed because the required logic might not be generated

465
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

in the abstracted block.

FIGURE 39.

What Next
To resolve this issue, configure the setup by applying either the sdc or the
attribute constraints to the block ports before abstracting it.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.
 create_cdc_abstract_model: Creates in-memory CDC abstract model
from block-level run.

Related App-var(s)
None

466
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SAMCDC_INCOMPLETE_UNCONSTRAINED_PORTS
Severity
Warning

Short Help
Generated SAM might be incomplete because there are critical setup issues
and SETUP_PORT_UNCONSTRAINED violation(s) are reported during setup
checks.

Description
VC SpyGlass CDC reports this tag during SAM generation if any
SETUP_PORT_UNCONSTRAINED violations are generated as part of the
analysis. Unconstrained ports can lead to the creation of incomplete SAM
model.

What Next
Review each of the SETUP_PORT_UNCONSTRAINED violations, generated
during the Setup check of CDC analysis, for corresponding ports and fix
those. Perform CDC analysis again with the updated constraints and ensure
that SETUP_PORT_UNCONSTRAINED violations are resolved before
proceeding with SAM generation.
You can use the configure_unconstrained_ports command to automatically
constrain each port before running CDC analysis.

Related Command(s)
 configure_cdc_abstract_model: Configures design abstraction.
 create_cdc_abstract_model: Creates in-memory CDC abstract model
from block-level run.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.

Related App-var(s)
None

467
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

468
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_MISMATCH
(Alias: HIER_ABSTRACT_MISMATCH)

Severity
Error

Short Help
Design contains validation mismatches.

Description
The SETUP_HIER_MISMATCH tag reports block abstraction mismatch with
the top-level design. The tag reports the following mismatch types:
 Clock Mismatch
 Clock Domain Mismatch
 Virtual Clocks Mismatch
 Case Analysis Mismatch
 Quasi Static Mismatch
 Data Path Domain Mismatch
 Reset Mismatch
 Qualifier Mismatch
 Combo Check Mismatch

Clock Mismatch
This mismatch occurs in the following cases:

469
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If a top-level clock reaches to a clock port of a block but the block clock
port is not constrained by create_clock. For example, refer the following
scenario and the corresponding Verdi violation view for the mismatch.

 If a block-level clock port is not driven from any top-level clock. This can
occur when the block-level clock port is constrained with create_clock but

470
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

the top-level clock does not reach the block clock port. For example,
refer the following scenario.

What Next
Some valid clock ports may get missed in the block SAM or constraint file.
As a result, VC SpyGlass CDC may not perform synchronization checks for
such potential clock signals.
If the path of top-level clock is blocked before reaching to a clock port of a
block, it may result in incorrect violations at the top-level.
If the block port is not a clock but it is defined as a clock in the block-level
SAM or constraint file by mistake, the block-level CDC verification may be
inaccurate.
Perform appropriate actions based on the following cases:
 If a top-level clock reaches to an unconstrained clock port of a block
Action: Specify the clock constraint on the clock port of the reported
block instance and analyze the specification or propagation of the top-
level clock.
 If a block-level clock port is not driven from a top-level clock port.
Action: Open the schematic and perform the following actions:

471
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 Analyze the top-level design for propagation of a clock to the block


port.
 Check if the path of the top-level clock is blocked before reaching to
the clock port of the block. In this case, fix the logic accordingly.
 Check if the top-level net driving the clock port of a block is a clock,
but it is not defined in top-level constraint file. In this case, define the
clock in the constraint file.
 If the block port is not a clock but it is defined as a clock in block-
level SGDC file by mistake, perform the following actions:
 Remove the clock specification from block-level SAM or constraint
file.
 Re verify the block-level CDC verification.

Clock Domain Mismatch


This mismatch occurs in the following cases:

472
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If multiple clock ports in the same domain of an abstract view are


triggered from the top-level clocks of a different domain. For example,
refer the following scenario.

Top module sdc constraints:


create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_groups -asynchronous -group { clk1 }
set_clock_groups -asynchronous -group { clk2 }
Block module sdc constraints:
create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_groups -asynchronous -group { clk1
clk2}

 If virtual clock specified at a block port and the clock port are in the
same clock domain of an abstract view and they are triggered by the

473
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

top-level clocks of different clock domain. For example, refer the


following scenario.

Top module sdc constraints:


create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_group -asynchronous -group { clk1} -group {clk2}
set_constraints_scope -module {test}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {clk1}
apply_attribute vc_path1 -add -objects {in2}
end_constraints_scope
Block module sdc constraints:
create_clock -name clk2 -period 10 {clk2}
create_clock -tag VCLK -period 10
set_clock_group -asynchronous -group { VCLK clk2 }
set_constraints_scope -module {block}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {VCLK}
apply_attribute vc_path1 -add -objects {in2}
end_constraints_scope

 If virtual clocks 'virtual-clock1' and 'virtual-clock2' specified at the ports


'block-port1' and 'block-port2' respectively, are in the same domain of

474
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

an abstract view and are triggered from top-level clocks of different


domains. For example, refer the following scenario.

Top module sdc constraints:


create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_group -asynchronous -group { clk1 } -group { clk2 }
set_constraints_scope -module {test}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {clk1}
apply_attribute vc_path1 -add -objects {in1}
end_constraints_scope
set_constraints_scope -module {test}
define_attribute -name vc_path2
set_clock_attribute vc_path2 -clocks {clk2}
apply_attribute vc_path2 -add -objects {in2}
end_constraints_scope
Block module sdc constraints:
create_clock -tag VCLK1 -period 10
create_clock -tag VCLK2 -period 10
set_clock_group -asynchronous -group { VCLK1 VCLK2}
set_constraints_scope -module {block}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {VCLK1}
apply_attribute vc_path1 -add -objects {in1}
end_constraints_scope
set_constraints_scope -module {block}
define_attribute -name vc_path2
set_clock_attribute vc_path2 -clocks {VCLK2}

475
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If multiple clock ports in different domains of an abstract view are


triggered from the top-level clocks of the same domain. For example,
refer the following scenario.

The Clock Domain Mismatch violations are grouped together based on


following criteria:
 Same top clock domain mismatch: All the top-level attributes having the
same clock domain for the same instance are grouped together.
 Same block clock domain mismatch: All the block-level attributes having
the same clock domain for the same instance are grouped together.
The following figure shows the Verdi violation view for the mismatch.

What Next
The consequences vary based on the following situations:
 If multiple clock ports in the same domain of an abstract view are
triggered from the top-level clocks of different domains, VC SpyGlass
may map the reported virtual clock to an incorrect top-level domain.

476
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

This may result in spurious synchronization violations during the block


verification stage.
 If top-level clocks of the same domain trigger block ports of a different
domain, it may result in spurious synchronization results during
verification phase of higher-level blocks.
Perform appropriate actions based on the following cases:
 If multiple clock ports in the same domain of an abstract view are
triggered from the top-level clocks of different domains, perform the
following:
 Analyze the specification or propagation of top-level clocks.
 Ensure that the specification of the same domain virtual clocks is
consistent with the specification of top-level clocks identified in the
first step.
 If top-level clocks of the same domain trigger block ports of a different
domain, perform the following:
 Verify the specification of different domains on multiple clock ports.
 Analyze the specification or propagation of the top-level clock.

Virtual Clocks Mismatch


This mismatch occurs in the following cases:

477
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If multiple ports of the same block specified with the same virtual clock
are driven by different domains from top level. For example, refer the
following scenario.

Top module sdc constraints:


create_clock -name clk1 -period 10
{clk1}
create_clock -name clk2 -period 10 Block module sdc constraints:
{clk2} create_clock -tag VCLK1 -period 10
set_clock_group -asynchronous -group set_clock_group -asynchronous -group {
{ clk1} -group {clk2} VCLK1}
set_constraints_scope -module {test} set_constraints_scope -module {block}
define_attribute -name vc_path1 define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks set_clock_attribute vc_path1 -clocks
{clk1} {VCLK1}
apply_attribute vc_path1 -add - apply_attribute vc_path1 -add -objects
objects {in1} {in1}
end_constraints_scope end_constraints_scope
set_constraints_scope -module {test} set_constraints_scope -module {block}
define_attribute -name vc_path2 define_attribute -name vc_path2

478
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If no top-level clock is reaching the block port specified with a virtual


clock.

What Next
If you do not fix these violations, VC SpyGlass CDC analysis may produce
inaccurate synchronization results during block verification, thereby
generating incorrect abstract view model. This may further generate
incorrect synchronization violations in the SoC verification stage.
To fix this mismatch, perform the following actions:
 Analyze design connectivity between the top-level sequential element
and a block input port.
 Verify the virtual clock specified by the apply_attribute.

Case Analysis Mismatch


This mismatch occurs in the following cases:
 If there is a mismatch between the following values:

479
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 Constant value specified by the set_case_analysis constraint for a


block-level port
 Constant value propagated from the top-level

 If a simulated value reaches a top-level net connected to a block-level


port, but no:
 set_case_analysis constraint is specified on the block-level port.

480
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If a simulated value does not reach to a top-level net connected to a


block-level port, but the set_case_analysis constraint is specified on
the block-level port.

What Next
If you do not fix this violation, the following issues may arise depending
upon different situations:
 If the specified value at the block-level port is incorrect, block-level CDC
verification is inaccurate.
 If the specified value at the block-level port is correct but constant
propagation at the top-level is incorrect, it indicates a logical issue at
the top-level because of which incorrect value is propagated at the
block-level.
To fix this mismatch, perform appropriate actions based on the following
cases:
 If block-level ports are constrained to values that do not match with
constant values propagated from the top-level:
 Check the value specification of the set_case_analysis constraint on a
block port.

481
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 Analyze the top-level design for propagation of a constant value to


the block port.
 If a constant value propagates from the top-level but the port of the
abstract view is not constrained with the set_case_analysis constraint:
 Analyze the top-level design for propagation of a constant value to
the block port.
 Specify the set_case_analysis constraint on the block port.
 If a block port is constrained with the set_case_analysis constraint, but no
constant value propagates from the top-level:
 Analyze the top-level design for propagation of a constant value to
the block port.
 Remove the set_case_analysis constraint if a valid constant value does
not reach the block port.

Quasi Static Mismatch


This mismatch occurs in the following cases:
 If a top-level quasi-static signal reaches a block port on which a
create_static command has not been specified.

482
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If a create_static command has been specified at a block-level port,


however no top-level quasi-static signal is driving the block port.

What Next
If you do not fix this violation, the following issues may arise depending
upon different situations:
 If a top-level quasi-static signal reaches a block port on which a
quasi_static constraint has not been specified, the design may not
operate in the desired mode. In addition, the quasi_static constraints
would not be propagated to block outputs.
 If a quasi_static constraint has been specified at a block-level port,
however no top-level quasi-static signal is driving the block port, some
crossings in the design may not be detected.
To fix this violation, perform appropriate actions based on the following
cases:
 If a top-level quasi-static signal reaches a block port on which a
quasi_static constraint has not been specified, perform the following:
 Specify quasi_static constraint on a block port, or

483
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 Analyze the specification or propagation of the top-level quasi-static


signal to the block port.
 If a quasi_static constraint has been specified at a block-level port and
no top-level quasi-static signal is driving the block port, perform the
following:
 If the block quasi-static specification is correct, add the missing
quasi_static at the top-level, else
 Remove the quasi_static constraint from the block port.

Data Path Domain Mismatch


This mismatch occurs if an abstract-block port is driven from a sequential
instance, and there is a mismatch between the clock domain of the clock
pin driving this sequential instance and the clock specified in the

484
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

set_clock_attribute command on the block port.

Top module sdc constraints:


create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_group -asynchronous -group { clk1} -group {clk2}
set_constraints_scope -module {test}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {clk1}
apply_attribute vc_path1 -add -objects {in1}
end_constraints_scope
Block module sdc constraints:
create_clock -name clk1 -period 10 {clk1}
create_clock -name clk2 -period 10 {clk2}
set_clock_group -asynchronous -group { clk1} -group {clk2}
set_constraints_scope -module {test}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {clk2}
apply_attribute vc_path1 -add -objects {in1}

What Next
If you do not fix this violation, SpyGlass may report incorrect
synchronization violations during verification phase of the hierarchical
verification flow.

485
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

To fix this violation, perform the following steps:


 Analyze the design connectivity between the top-level sequential
element and the block input port.
 Check if the clock domain specified by the apply_attribute or the
input constraint is consistent with the clock domains driving sequential
elements identified in the first step.
 Check constraints (apply_attribute) back-annotation for block
apply_attribute for which the violation was reported and back-
annotation of top level sequential element to indicate the differing clock.

Reset Mismatch
This mismatch occurs in the following cases:
 If a top-level reset reaches a block port for which no reset constraint is
specified.
 If the reset constraint is specified for a block-level port, but no top-level
reset drives that block-level port.

 If an asynchronous reset specified at a top-level reaches to a


synchronous reset port of an abstract view or vice-versa.

486
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If the active value of the top-level reset is different from the active value
of the block-level reset port driven by that top-level reset.

Top module sdc constraints:


create_reset {rst} -sync -sense high
Block module sdc constraints:
create_reset {rst} -async -sense low

What Next
If you do not fix this violation, the following issues may arise depending
upon different situations:
 If a top-level reset reaches a block port for which no reset constraint is
specified, some potential resets may not propagate during the
verification of the abstract view. This may result in the following:
 The block may not achieve its initial state.
 In the absence of synchronous resets, VC SpyGlass may report
violations related with unsynchronized clock domains.
 If the reset constraint is specified for a block-level port but no top-level
reset drives that block-level port, the reported port of an abstract view
may not be considered as a valid reset signal. This may alter the initial
state of the block during verification.

487
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If an asynchronous reset specified at a top-level reaches to a


synchronous reset port of an abstract view or vice-versa:
 Incorrect reset analysis may happen at the block-level. That is, the
initial state of the block may get altered during its verification.
 VC SpyGlass may generate incorrect clock domain violations during
block verification if synchronous resets are not properly specified.
 If the active value of the top-level reset is different from the active value
of the block-level reset port driven by that top-level reset:
 It may result in an incorrect initial state of an abstract view during
verification.
 It may generate spurious reset simulation results for the abstract
view.
To fix this mismatch, perform appropriate actions based on the following
cases:
 If a top-level reset reaches a block port for which no reset constraint is
specified, perform the following:
 Specify the reset constraint on the reported block port.
 Analyze the specification or propagation of the top-level reset to the
block.
 If the reset constraint is specified for a block-level port, but no top-level
reset drives that block-level port, perform the following actions:
 Remove the reset constraint from the reported block port.
 Analyze the specification or propagation of a top-level reset to the
block port.
 If an asynchronous reset specified at a top-level reaches to a
synchronous reset port of an abstract view or vice-versa, perform the
following actions:
 Specify an appropriate reset constraint on the block-level port.
 Analyze the specification or propagation of the top-level reset to a
block.
 If the active value of the top-level reset is different from the active value
of the block-level reset port driven by that top-level reset, perform the
following actions:
 Check the value specified by the reset constraint on the block port.

488
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 Assign a proper value in the reset constraint.


 Verify that the top-level reset of the block port has the same active
value identified in step above.

Qualifier Mismatch
This mismatch occurs in the following cases:
 If a synchronized signal reaches to an input port of an abstract block for
which:
 The qualifier (configure_cdc_data_sync) constraint is not defined,
or
 The apply_attribute constraint is not defined with the -sync
argument (sync_attribute), or
 The apply_attribute constraint is defined with the -sync
(sync_attribute) argument, but the 'from' and 'to' clocks of the
apply_attribute constraint do not match with the source or
destination clocks of the synchronizer reaching to the input port, or
 The qualifier (configure_cdc_data_sync) constraint is defined, but
the 'from' and 'to' clocks of the qualifier (configure_cdc_data_sync)
constraint do not match with the source or destination clocks of the
synchronizer reaching to the input port.

489
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 If a synchronizer does not reach to an input port of a block for which:


 The qualifier (configure_cdc_data_sync) constraint is specified, or
 The -sync (sync_attribute) argument of the apply_attribute
constraint is specified.

What Next
If you do not fix this violation, SpyGlass may report incorrect
synchronization violations during the block verification stage.
To fix this mismatch, perform appropriate actions based on the following
cases:
 If clocks specified by the -from_clk and -to_clk arguments of the
qualifier constraint for an abstract view exist in the same top-level
domain, perform the following:
 Analyze the clocks specified in the -from_clk and -to_clk arguments
of the qualifier constraint.
 Analyze specification or propagation of top-level clocks.
 If a synchronizer does not reach to an input port of a block for which the
-sync (sync_attribute) argument of the apply_attribute constraint
is specified, perform the following:
 Analyze the fan-in cone of an input port for the presence of a
synchronizer.
 Remove the -sync (sync_attribute) argument from the
apply_attribute constraint.

Combo Check Mismatch


This mismatch occurs if a combinational logic exists between a block-level
input port and the output of a sequential element at the top-level when the
-combo no argument of the set_clock_attribute constraint is specified
for that block in the following cases:
 If at the block level, the set_clock_attribute constraint is defined
along with the -combo_ifn argument. In this case, the
SETUP_HIER_MISMATCH tag reports a violation if a sequential element
reaches the block port after a combinational logic and if the sequential

490
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

cell has a clock domain that is different from the clock domain of the
clock specified in the -combo_ifn argument.

Block sdc constraints for port in1:


set_constraints_scope -module {block}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clocks {SG_VCLK_1} -combo no
-combo_ifn {clk2}
apply_attribute vc_path1 -add -objects {in1} -sgdc_cmd
abstract_port -start
end_constraints_scope

 If at the block level, the set_clock_attribute constraint is defined


with real clocks. In this case, the SETUP_HIER_MISMATCH tag will
report a violation if a sequential element reaches the block port after
combinational logic.
 If at the block level, the set_clock_attribute constraint is defined
with only virtual clock. In this case, the SETUP_HIER_MISMATCH tag

491
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

reports a violation if the sequential element reaches the block port after
combinational logic.

Block sdc constraints for port in1:


set_constraints_scope -module {block}
define_attribute -name vc_path1
set_clock_attribute vc_path1 -clock_objects {clk1} -combo no
apply_attribute vc_path1 -add -objects {in1}
end_constraints_scope

NOTE: When a single non-quasi source is reaching the output port through a combinational
logic, which is generated as -single_non_quasi argument of the
set_connectivity_attribute command, the combo mismatch violation is not
reported because of the combo logic inside the block.

What Next
If you do not fix this violation, it results in an incorrect setup at the block
level.
To fix this mismatch, perform the following:
 Remove the -combo no argument from the set_clock_attribute
constraint.
 Analyze the combinational logic between the sequential element and
block-level input port.

492
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_IGNORE_PORTS

Severity
Warning

Short Help
The set_ignore_attribute command is specified on a port of an
abstracted block

Description
VC SpyGlass CDC report this tag if the set_ignore_attribute command is
specified on a port of an abstracted block. If this command is specified on a
wrong object, it might result in missing real CDC issues.
By default, this tag is disabled. Use the following command to enable it:
configure_cdc_tag -enable -tag SETUP_HIER_IGNORE_PORTS

What Next
To resolve this issue, specify the set_ignore_attribute constraint
correctly. Review the results and fix the design/setup if required.

Related Command(s)
 set_ignore_attribute: Ignores the validation of the design objects on
which this attribute is applied.

Related App-var(s)
None

493
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SYNCCDC_DATAPATH_SAM_SYNCPORT
(Alias: CDC_SYNC_DATA_SAM_SYNCPORT)

Severity
Info

Short Help
Data synchronization scheme found for CDC path from SrcObject to
DestObject, crossing from SrcClockInfoList to DestClockInfoList
Synchronized data path found

Description
VC SpyGlass CDC report this tag if a crossing is synchronized in the SAM
abstract model by using the data synchronization scheme.
The tag reports the following reason codes:
 SYNC_AT_RECIRC_MUX
 SYNC_AT_LIBCELL_CGC
 SYNC_AT_NON_RECIRC_MUX
 SYNC_AT_BLOCKING_GATE
 UDS_USED_AS_QUALIFIER

SYNC_AT_RECIRC_MUX
This reason code is reported when a data crossing is synchronized using
MUX recirculation.

494
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

The clock domain crossing is marked as synchronized if either of the


following conditions is met:
 The MUX select pin is driven by a signal synchronized to the
destination clock domain.
 A valid synchronizer exists in any one of the paths driving the MUX
select pin and the signals in all other paths are driven either by
primary ports or the destination clock domain flip-flops and there is
no unsynchronized crossing in any of the paths.

What Next
This is an informational message related to the MUX recirculation
scheme.

SYNC_AT_LIBCELL_CGC
This reason code is reported when a crossing is synchronized using a
library cell clock gating.

495
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
This is an informational message pertaining to a lib cell-based clock
gating scheme. No action is required.

SYNC_AT_NON_RECIRC_MUX
This reason code is reported when there is a data crossing synchronized
without MUX recirculation.

496
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
This is an informational message pertaining to non-MUX recirculation
scheme. No action is required.

SYNC_AT_BLOCKING_GATE
This reason code is reported when there is data crossing synchronization
with AND logic.

What Next
This is an informational message pertaining to AND logic scheme. No
action is required.

UDS_USED_AS_QUALIFIER
This reason code is reported when an user-defined synchronizer cell is
used as a control path qualifier.

497
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

What Next
This is an informational message pertaining to user-defined
synchronizer cell.

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_internal_crossing: Enables reporting of internal crossings
of the specified libcell.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.

498
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

 set_cdc_ignore_path: Specifies the clock domain crossings that should


be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.
 configure_cdc_port: Specifies the inout/output port(s) that will be
connected to a control synchronizer.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

499
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SYNCCDC_CTRLPATH_SAM_SYNCPORT
(Alias: CDC_SYNC_CTRL_SAM_SYNCPORT)

Severity
Info

Short Help
Control synchronization scheme is found on the CDC path.

Description
VC SpyGlass CDC report this tag if a crossing is synchronized in the SAM
abstract model by using the control synchronization scheme. The tag
reports the following reason codes:
 NFF_SYNC
 NFF_STATIC_COMBO
 NFF_DST_FLOATING_FANOUT

NFF_SYNC
This reason code is reported when a conventional multi-flop
synchronization scheme is found on the path.

What Next
This is an information message indicating that VC SpyGlass CDC
recognizes the NFF structure with default settings or with the user-
specified configurations. No further action is required.

500
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

NFF_STATIC_COMBO
This reason code is reported when static combo logic is found in a
crossing path.

What Next
Normally static signal is not meant to be part of CDC analysis as the
signal does not change at any instance of the design cycle, thus this
needs attention to ensure that the structure is clean without any such
path so that CDC analysis can be performed by tool.
 Check the design structure for user-defined create_static and
set_case_analysis configurations. If these configurations exist, validate
if that is as per design intent. Else, modify the design.
 Check the design structure if any combo logic output which is static in
nature feeds to synchronization structure and validate if that is as per
the design intent. If not, modify the design.

NFF_DST_FLOATING_FANOUT
VC SpyGlass CDC reports this reason code when the destination of a
crossing is driving other floating paths before getting synchronized.

What Next
This reason is reported when multiple floating/hanging fan-outs are
present in the destination instance output. The output of the first flip-flop
would have a metastable value thereby making the crossing as
unsynchronized. In this case, it is recommended to avoid such floating path
to have a robust synchronizing structure.

501
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

Related Command(s)
 configure_cdc_crossing: Enables various configurations on crossings.
 configure_cdc_data_sync: Configures the data synchronizer detection.
 configure_cdc_internal_crossing: Enables reporting of internal crossings
of the specified libcell.
 configure_cdc_nff_sync: Configures the multi-flop synchronizer
detection.
 configure_cdc_static: Configures quasi-static for CDC analysis.
 configure_ip_block: Configures the modules for which CDC, RDC and
ResetAsync analysis needs to be turned OFF.
 configure_unconstrained_ports: Configures to model unconstrained
inputs and outputs of top, black-box modules, and library cells.
 define_attribute: Creates a virtual path object.
 set_cdc_ignore_path: Specifies the clock domain crossings that should
be ignored for CDC analysis.
 set_clock_relation: Specifies two synchronous points in the
asynchronous clock(s) pair path to form a crossing.

Related App-var(s)
 cdc_enable_merge_vector: Default value is maximal. Enables vector
merging of CDC crossings.
 cdc_enable_splitbus_mapping: Default value is false. Set the value to
true to allow bit-blasted operation for CDC crossings specified in the
report_cdc command argument.

502
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_TESTBUS_ANALOG_MATCH
Severity
Info

Short Help
Matching path found from 'FromObject' to 'ToObject', Match type
'ToObjectType'

Description
VC SpyGlass CDC reports this tag if the testbus/analog input/output port of
an abstracted block matches with the top level design and the top-level
input/output port matches with respect to the top design.

What Next
This is an informational message. Disable/waive this tag if not required.

503
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_TESTBUS_ANALOG_MISMATCH
Severity
Warning

Short Help
Path mismatch found from 'FromObject' to 'ToObject', Mismatch type from
'FromObjectType' to 'ToObjectType'

Description
VC SpyGlass CDC reports this tag if the testbus/analog input/output port of
an abstracted block does not match the top level design and the top-level
input/output port does not match with respect to the top design.

What Next
To fix the reported mismatches, perform the following:
 If the block-level input/output/inout ports are constrained to values that
do not match with testbus/analog values propagated from the top-level,
perform the following actions:
 Check the value specification of the testbus/analog constraint on a
block port and specify the testbus/analog constraint accordingly
either at the block port or at top.
 Analyze the top-level design for propagation of a testbus/analog
signal to the block port.
 If the top-level input/output/inout ports are constrained to a testbus/
analog constraint that does not match the testbus/analog signals inside
the top, perform the following actions:
 Analyze the top-level design for propagation of the testbus/analog
value inside the top and connect the testbus/analog signals with the
appropriate signals inside the top.
 Check the value specification of the testbus/analog constraint on the
top port and modify the testbus/analog constraint accordingly at the
top port.

504
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_HIER_VIRTUAL_CLOCK_SAME
Severity
Warning

Short Help
Same virtual clock is used for both input and output ports of the module

Description
VC SpyGlass CDC reports this tag if the same virtual clock is specified on
both input and output ports of a module.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.
For example, consider the following schematic where the same vclk2
virtual clock is used for both the b input port and the x output port of the
module.

What Next
To fix the reported issue, correct the setup and ensure that the same

505
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

virtual cock is not used for both input and output ports of the module.

Related Commands
None

Related App-var(s)
None

506
Synopsys, Inc. Feedback
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

SETUP_PORT_CLOCK_MISMATCH
Severity
Error

Short Help
Design contains clock mismatches at output ports.

Description
VC SpyGlass CDC reports this tag if an output port has a clock constraint
defined on it but is not driven by any clock signal in fan-in.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.
For example, consider the following schematic where the output port has
clock constraint defined on it but is not driven by any clock signal in the
fan-in.

What Next
If you do not fix this violation, it results in an incorrect setup at the block
level.
To debug and fix this violation, perform the following steps:
 Identify the problematic output ports by referring the rule-based
spreadsheet for the top module.
 If any create_clock value is not propagated to an output/inout port on
which the create_clock constraint is defined, remove the
create_clock constraint from that port.

507
Feedback Synopsys, Inc.
VC SpyGlass CDC Hierarchical Flow

Debugging Validation Check Violations

Related Commands
None

Related App-var(s)
None

508
Synopsys, Inc. Feedback
Analyzing VC SpyGlass
CDC Results

This chapter is organized into the following sections:


 Understanding VC SpyGlass CDC Violation Database
 Debugging CDC Violations Using Tcl
 Debugging CDC Violations Using GUI
 Reports Generated by VC SpyGlass CDC

509
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Understanding VC SpyGlass CDC Violation Database

Understanding VC SpyGlass CDC Violation


Database
This section describes the following:
 Configuring Message Tags

Configuring Message Tags


VC SpyGlass CDC provides many CDC checks. All these checks have
message tags and a predefined reporting format. Based on collective user
feedback, by default, VC SpyGlass CDC has certain checks enabled and
certain checks disabled. Also, the severity is predefined for each tag of a
violation.
VC SpyGlass CDC provides the flexibility for you to pick and choose which
checks are relevant for your design. You can change the default enable/
disable status of check and the severity of a check by using the
configure_cdc_tag command. In summary, you must configure the VC
SpyGlass CDC tags in the following cases:
 When you want to permanently skip certain tags without the local
administrative overhead of a waiver.
 When you want to change the severity of some messages between error
and warning.
It is recommended that you use the configure_cdc_tag command before
reading a design.
NOTE: Configuring the CDC checks for a given design/run is one of the most important
review that must be done by the design engineer. Disabling an CDC check/tag
using the configure_cdc_tag command does not necessarily improve the VC
SpyGlass CDC runtime.
The configure_cdc_tag command uses the following syntax:
%vc_static_shell> configure_cdc_tag -help
Usage: configure_cdc_tag # Displays and configures CDC
violation tags
[-tag <tag list>](Defines the tag(s) operated on)
[-stage <stage list>] (Apply tag alternations to the entire

510
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Understanding VC SpyGlass CDC Violation Database

group(s):
Values: all, conv, glitch, setup, struct, sync)
[-enable] (Enables the tag(s))
[-disable] (Disables the tag(s))
[-severity <error|warning|info>] (Sets the tag(s) severity
level: Values: all, error, info, warning)
[-clear](Restores all tags to their original state)
[-tcl](Displays changes to the CDC tag set in a Tcl format
suitable for replay)
[-regexp] (Allows regexp expressions in the tag
list (default glob-style))
[-all] (Displays all messages, even with
default enable and severity status)
[-verbose](Displays short Description for each message)
Examples:
To enable all tags in VC SpyGlass CDC, use the following command:
%vc_static_shell>configure_cdc_tag -tag * -enable
Other possible use models
%vc_static_shell>configure_cdc_tag –tag/-stage <tag/stage
list> –disable/-enable
%vc_static_shell>configure_cdc_tag –tag/-stage <tag/stage
list> –severity <error|warning|info>
%vc_static_shell>configure_cdc_tag –regexp –tag <tag list>
–disable/-enable
%vc_static_shell>configure_cdc_tag –regexp –tag <tag list>
–severity <error|warning|info>
%vc_static_shell>configure_cdc_tag –clear
%vc_static_shell>configure_cdc_tag –tcl
%vc_static_shell>configure_cdc_tag
%vc_static_shell>configure_cdc_tag -enable -tag

511
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Understanding VC SpyGlass CDC Violation Database

%vc_static_shell>configure_cdc_tag -all -verbose >


all_tags.rpt

The following example shows VC SpyGlass CDC reports of a design before


and after configuration of certain tags/checks.
The following is the output without the use of the configure_cdc_tag
command:
%vc_static_shell>report_cdc
-----------------------------------------------------------
Report Summary
-----------------------------------------------------------
Product Info
Name : VC Static Master Shell
Report Info
Created : Feb 02, 2017 21:45:09

-----------------------------------------------------------
Management Summary
-----------------------------------------------------------
Stage Family Errors Warnings Infos
----- --------- -------- -------- --------
SETUP CLKPROP 3 3 9
SYNC UNSYNC 1 0 0
----- --------- -------- -------- --------
Total 4 3 9

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

512
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Understanding VC SpyGlass CDC Violation Database

Tree Summary
---------------------------------------------------------
Severity Stage Tag Count
-------- ----- ---------------------------- -----
error SETUP INTEGRITY_CLKGATE_GLITCH 1
error SETUP SETUP_PORT_UNCONSTRAINED 1
error SYNC SYNCCDC_UNSYNC_NOSCHEME 1
warning SETUP SETUP_ASYNC_CLOCK_OVERLAP 3
info SETUP SETUP_CLOCK_GROUP_INFER 4
info SETUP SETUP_PORT_CONSTRAINED 4
info SETUP SETUP_PORT_IGNORED 1
-------- ----- ---------------------------- -----
Total 16
The following is the output after the use of the configure_cdc_tag -
severity error command:
-----------------------------------------------------------
Report Summary
---------------------------------------------------------
Product Info
Name : VC Static Master Shell

Report Info

---------------------------------------------------------
Management Summary
---------------------------------------------------------
Stage Family Errors Warnings Infos
----- --------- -------- -------- --------

513
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Understanding VC SpyGlass CDC Violation Database

SETUP CLKPROP 3 3 9
SYNC UNSYNC 1 0 0
----- --------- -------- -------- --------
Total 4 3 9

---------------------------------------------------------
Tree Summary
---------------------------------------------------------
Severity Stage Tag Count
-------- ----- ---------------------------- -----
error SETUP INTEGRITY_CLKGATE_GLITCH 1
error SETUP SETUP_PORT_UNCONSTRAINED 1
error SYNC SYNCCDC_UNSYNC_NOSCHEME 1
-------- ----- ---------------------------- -----
Total 4

Default Format of Message Tags


By default, report_format argument of the get_tag_attribute and the
set_tag_attribute commands is set for all design read, setup, and sdc
tags. The default format includes all fields (except the Msg ID and the
Signature fields) registered for the tag. You can fetch the fields by using
the get_tag_fields <tag> tcl command.
You can get the report_format by using the get_tag_attribute <tag>
report_format command and set it by using the set_tag_attribute
<tag> report_format <new_format> command.

514
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

Debugging CDC Violations Using Tcl


You can debug the violation reported by VC SpyGlass CDC using the Tcl
commands described in the sections below. This section describes the
following:
 Examples of Violation Fields
 Filtering Messages
 Operations on Tag Definitions
The report_cdc command reports the messages generated after CDC
analysis is performed on the design. The report_cdc command is the main
output command for clock domain crossing checks. By default, it writes a
summary of the messages.

Syntax
vc_static_shell> report_cdc -help
Usage: report_cdc # Reports CDC check information
[-no_summary] (Suppresses summary
information)
[-list] (List all messages in simple
form)
[-verbose] (List all messages in detail
form)
[-limit <count>] (Limit the number of output
records per tag)
[-include_waived] (Include waived messages in the
report)
[-only_waived] (Report on waived messages)
[-tag <tag>] (Select violations based on
tag)
[-waived <list>] (Select violations based on
waiver name)

515
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

[-id <tag>] (Select violations based on


IDs)
[-family <family>] (Select violations based on
family:
Values: all, clkprop, clock,
comb_conv,
config, config_conv,
config_glitch,
config_setup, config_sync,
control_path,
conv, data_path, diverge, dmux,
fifo,
glitch, handshake, hiercdc,
ignore_path,
logic, nff, no_conv, pulse,
reset, sdc,
seq_conv, unsync)
[-stage <stage>] (Select violations based on
stage:
Values: all, conv, glitch,
setup,
struct, sync)
[-severity <list>] (Select violations based on
severity:
Values: all, error, info,
warning)
[-filter <expression>] (Select violations based on
expression)
[-regexp] (Indicates filter expression type to
be regular expression (default glob-style))
[-file <filename>] (Write the results to the
designated file)

516
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

[-append] (Append results to the


designated file)
[-report <sg_detailed, sg_summary, sg_moresimple, sg_waiver,
sg_conv_detailed, sg_glitch_detailed, sg_cross_analysis,
all, default>] (List all messages in specified reports)
[-hide_id] (Hide message id)
[-dir <directory name>](Write the results to the designated
dir)
[-cluster_viols_only] (Violations belonging to cluster will
be reported)
[-include_cause_viols] (Include cause violation(s) in
report.)
Use Model
Using the various options that the report_cdc command provides, you can
define the content of the report.
For example, if you specify report_cdc in the shell, VC SpyGlass CDC
displays a summary view of all messages, as shown below: -

-----------------------------------------------------------
Management Summary
-----------------------------------------------------------
Stage Family Errors Warnings Infos
----- ---------- -------- -------- --------
INTEGRITY CLKPROP 326 0 0
SETUP CLKPROP 0 2 27
SETUP RESET 5 0 1
SETUP SDC 0 1 0
SYNC CTRLPATH 80 0 3
SYNCUNSYNC 169 0 0
CONV_CHECKCOMBCONV 100

517
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

GLITCH_CHECKGLITCH50 0
----- ---------- -------- -------- ------------
Total 586 3 31

-----------------------------------------------------------
Tree Summary
-----------------------------------------------------------
Severity Stage Tag Count
-------- ----- ------------------------------- -----
errorSYNCASYNCRST_CTRLPATH_PARTIAL26
errorSYNCASYNCRST_UNSYNC_NOSCHEME60
errorCONV_CHECKCDC_COMBCONV_FVUNCHECKED 1
errorGLITCH_CHECK CDC_GLITCH_CTRLPATH 5
errorINTEGRITYINTEGRITY_CLKGATE_GLITCH326
errorSETUPSETUP_RESET_CONSTANT_ACTIVE1
errorSETUP SETUP_RESET_UNDECL4
errorSYNCSYNCCDC_CTRLPATH_PARTIAL54
errorSYNCSYNCCDC_UNSYNC_NOSCHEME109
warningSETUPSETUP_CLOCK_UNUSED1
warningSETUPSETUP_MULTIPLE_CONSTRAINTS1
warningSETUPSETUP_SDC_CMD_IGNORED1
infoSETUPSETUP_CLOCK_GROUP_INFER3
infoSETUPSETUP_PORT_CONSTRAINED21
infoSETUPSETUP_RESET_CONSTANT_INACTIVE1
infoSETUPSETUP_SYNC_CLOCK_OVERLAP3
infoSYNCSYNCCDC_CTRLPATH_FULL3
-------- ----- ------------------------------- -----
Total620

518
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

You can define the content of the report to make it verbose. The following
shows an example of verbose reporting:
%vc_static_shell> report_cdc -verbose -tag
SETUP_PORT_CONSTRAINED -limit 0 -file
SETUP_PORT_CONSTRAINED.rpt
-----------------------------------------------------------
Report Summary
---------------------------------------------------------
Product Info
Name : VC Static Master Shell

Report Info
-----------------------------------------------------------
Management Summary
---------------------------------------------------------
Stage Family Errors Warnings Infos
----- --------- -------- -------- --------
SETUP CLKPROP 6 0 4
----- --------- -------- -------- --------
Total 6 0 4
-----------------------------------------------------------
Tree Summary
---------------------------------------------------------
Severity Stage Tag Count
-------- ----- -------------------------- -----
error SETUP SETUP_PORT_UNCONSTRAINED 3
error SETUP SETUP_RESET_UNDECL 3

519
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

info SETUP SETUP_CLOCK_GROUP_INFER 2


info SETUP SETUP_PORT_CONSTRAINED 2
-------- ----- -------------------------- -----
Total 10
-----------------------------------------------------------
SETUP_PORT_UNCONSTRAINED (3 errors/0 waived)
---------------------------------------------------------
Tag : SETUP_PORT_UNCONSTRAINED
Description : Port [PortName] has no
constraints
Violation : CDC:3
PortName : in1
Direction : Input
Status : Unconstrained
Inferred Source Information List
Inferred Clock Information
Inferred Clock Source : clk1
-----------------------------------------------------------
Tag : SETUP_PORT_UNCONSTRAINED
Description : Port [PortName] has no
constraints
Violation : CDC:4
PortName : destsync
Direction : Output
Status : Unconstrained
Inferred Source Information List
Inferred Clock Information
Inferred Clock Source : clk1

520
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

-----------------------------------------------------------
Tag : SETUP_PORT_UNCONSTRAINED
Description : Port [PortName] has no
constraints
Violation : CDC:5
PortName : destunsync
Direction : Output
Status : Unconstrained
Inferred Source Information List
Inferred Clock Information
Inferred Clock Source : clk2
-----------------------------------------------------------
SETUP_RESET_UNDECL (3 errors/0 waived)
---------------------------------------------------------
Tag : SETUP_RESET_UNDECL
Description : Mux [InstanceName] does not receive rst on its
input pin.
Violation : CDC:8
InstanceName : FF1
Status : No explicit reason
-----------------------------------------------------------
Tag : SETUP_RESET_UNDECL
Description : Mux [InstanceName] does not receive rst on its
input pin.
Violation : CDC:9
InstanceName : FF2_1
Status : No explicit reason
-----------------------------------------------------------

521
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

Tag : SETUP_RESET_UNDECL
Description : Mux [InstanceName] does not receive rst on its
input pin.
Violation : CDC:10
InstanceName : FF2_2
Status : No explicit reason
By default, verbose reporting in the report_cdc command limits 100
messages per violation tag. If you want to apply a different limit of the
number of violations per ID, use the –limit option. For example,
report_cdc –limit 0 –verbose –file report_cdc.log gives a verbose
report of all message IDs.

Examples of Violation Fields


-----------------------------------------------------------
SETUP_CLOCK_GROUP_INFER (2 infos/0 waived)
---------------------------------------------------------
Tag : SETUP_CLOCK_GROUP_INFER
Description : Clock domain
[ClkDomainId], consisting of the clock(s) [ConstituentClks],
has been inferred by the tool. It reaches to
[SeqPinReachable] sequential pin(s)
Violation : CDC:1
ClkDomainId : 1
ConstituentClks
Clock
ClkName : clk1
ClkType : SDC_CLOCK
ClkRootList
ClkRoot : clk1

522
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

SeqPinReachable : 4

The short name, severity, and count of the messages are shown on the first
line. The Tag field shows the tag name. The Description field shows the
design-data dependent Description. The Violation field shows the
violation ID which can be used for reference in this run.
Next, the important fields, which are contained in the dynamic
Description, are shown. The remaining lines are less important fields
which might be useful for debugging.

Filtering Messages
You can filter messages by using the -filter <expression> option in the
report_cdc command based on the following:
 Family
 Severity
 Filter based on debug fields
 Wildcards and expressions
Example 1
%vc_static_shell> report_cdc -tag CDC_GLITCH_CTRLPATH
%vc_static_shell> report_cdc -family config_glitch
%vc_static_shell> report_cdc -severity error
Example 2
Usage of report_cdc with –filter
Consider a scenario where you:
 Need a report of all messages related to Glitch violation
(CDC_GLITCH_CTRLPATH)
 Need a filter for a ClockName containing the string new_clock1
Use the following command to get the required report:
%vc_static_shell> report_cdc –tag CDC_GLITCH_CTRLPATH –filter
{(ClockName==”top/*new_clock1*”)}

523
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

Operations on Tag Definitions


You can change the violation tags/violations and the sequence of debug
fields present in these violations. VC Static provides the following Tcl
commands to operate tags/violations. For example, renaming of tag/
violation, reorder/disable debug fields of a tag/violation.
 get_tags: Returns tag names. If a single tag name is given as an
argument, then it prints the same tag name. If used with a wildcard
character it expands the wildcard character to a list of matching tags. It
lists the tag/tags independently of the violations/tags present in the
current run of the report database. It does not accept a list of tags, but
wildcard characters are accepted. For example:
vc_static_shell> get_tags CDC_*

CDC_NOCONV_MULTIPLE_SYNC CDC_NOCONV_MISMATCH
CDC_NOCONV_FV_UNCHECKED CDC_NOCONV_FV_PARTIAL
CDC_NOCONV_FV_FAILED CDC_NOCONV_FV_PASSED
CDC_COMBCONV_FVUNCHECKED CDC_COMBCONV_FVPASSED
CDC_COMBCONV_FVPARTIAL CDC_COMBCONV_FVFAILED
CDC_COMBCONV_ASYNC_SRCS CDC_SEQCONV_FVUNCHECKED
CDC_SEQCONV_ASYNC_SRCS CDC_GLITCH_CTRLPATH
CDC_GLITCH_DATAPATH CDC_GLITCH_UNSYNC
 get_tag_info: Accepts a single tag at a time and lists the information
about the tag. It does not accept a list of tags or wildcard characters. It
runs independent of the violations/tags present in current run of report
database. For example:
vc_static_shell> get_tag_info CDC_GLITCH_DATAPATH
CDC info GLITCH_CHECK GLITCH enabled 0 0 1
In the above example, the numeric characters indicate the following:
 The first numeric character (0 in the above example) indicates the
total count of violations
 The middle numeric character (0 in the above example) indicates the
total count of waived violations
 The last numeric character indicates the count of built-in (1 in the
above example) and user-defined (not shown in the above example)
tags.

524
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

 get_tag_fields: Lists all the fields for a tag. It does not accept
wildcard characters and list of tags. It lists the tag fields independent of
the violations/tags present in current run of the report database. For
example:
vc_static_shell> get_tag_fields CDC_GLITCH_DATAPATH
{Msg ID} Tag Signature ReasonInfoList DstInfo
SrcFailureTypeCountInfo SrcInfoList ContainerScope
SgViolDetails
 get_violation_tags: Returns ordered list of tags for the violations
present in the report database. This command requires no arguments.
For example:
%vc_static_shell> get_violation_tags
CDC_GLITCH_DATAPATH
 rename_tag: Takes a single tag and replaces its name with the new
alias. This command should be used BEFORE the check* commands. It
does not accept a list of tags or wildcard characters. For example:
%vc_static_shell>rename_tag CDC_GLITCH_DATAPATH
NEW_GLITCH_VIOLATION
 disable_tag_field: Disables tag fields and prevents them from
getting printed in the report. This command should be used only AFTER
check* commands. It does not accept a list of tags or list of fields or
wildcard characters. For example:
%vc_static_shell> disable_tag_field CDC_GLITCH_DATAPATH
DstInfo
 reorder_tag_field: Generates a report where info fields appear just
after the design element fields, use the reorder_tag_fields command
to change the order of the fields reported. This command does not
accept wildcard characters and list of tags. It lists the tag fields
independent of the violations/tags present in the current run of the
report database. For example:
%vc_static_shell> set order [get_tag_fields
CDC_GLITCH_DATAPATH]
%vc_static_shell> set new_order [lsort $order]
%vc_static_shell> reorder_tag_fields CDC_GLITCH_DATAPATH
$new_order

525
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using Tcl

%vc_static_shell> report_cdc –verbose

526
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Debugging CDC Violations Using GUI


This section describes the following:
 Invoking and Running CDC Checks
 Message Summary View
 Analyzing the Results
 Using Filters
 Using Waivers
 Pivot Tables to Filter Violations
 Exporting Violation Table

Invoking and Running CDC Checks


All tasks that can be performed in the batch mode can be performed in the
GUI mode as well. You can invoke the GUI from vc_static_shell by using
the following sequence of commands:
%vc_static_shell
vc_static_shell> start_gui
Alternatively, you can use the following sequence of commands to invoke
the GUI:
%vc_static_shell
vc_static_shell> view_activity
These commands bring up the VCst Activity View window as shown in

527
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

FIGURE 40. .

FIGURE 40. VC Static Activity View

There are two panes available in the GUI at this stage:


 The left pane is called the activity tree
 The right pane is called the data view
To set up the design using the GUI, click Design Setup in the VC Static
(VCst) tree shown in the activity tree. The data view appears in the right
pane displaying all the Tcl files found in the current directory as shown in
Figure 10-1. These Tcl files contain the commands required to set up the
design.

528
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-1Data View with Tcl Files

Click the required Tcl file to set up the design. The Tcl file runs and the log
can be seen on the vc_static_shell output. After the Tcl file run
completes successfully, the design read violations are shown in the Design
Setup as shown in Figure 10-2. To stop displaying design read violations,
set the following application variable, which has a default value of 2, to 0.
enable_message_database_migration
Also the activity tree shows the Verification tree element under the VC
Static (VCst) tree, below Design Setup as shown in Figure 10-2.

529
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-2Activity View with Design Set Up

Click Verification in the activity tree to see the data view that displays the
checks you can perform on the design as shown in Figure 10-3.

530
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-3Activity View - Running CDC Checks

Click the Clock Domain Crossing Checks: Show Check Controls to see the
Check_CDC panel as shown in Figure 10-4.

531
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-4

Click Check_CDC to perform clock domain crossing related checks. After


you click, you can see the status Running Check CDC … until the checks are
completed. After the checks are completed, the status Check CDC ran
successfully ..! is displayed as shown in Figure 10-4.

Figure 10-5Activity View - Running CDC Checks

After the successful completion of Check_CDC, the activity tree is

532
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

populated with the following:


 CDC/RDC tree element under Verification in the VC Static (VCst) tree.
 Error, warning and information tags are flagged.
 The number of violations for an error/warning/information is displayed
in brackets.
 All error/warning/information tags are bucketed into the stages at which
they were flagged
 The number of violations for each stage is flagged.

Message Summary View


The Message Summary View displays the summary of the checks run on
the design, both with respect to the stages as well as the severity as shown
in Figure 10-6 and Figure 10-7 respectively.
To see the Message Summary View, click the CDC/RDC tree element under
Verification in the activity tree.

533
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-6Summary View - Stage Order

534
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-7Summary View - Severity Order

Icons available in the Message Summary View can be used to export the
message summary to a csv file and generate some clock/reset reports as
shown in the following figure.

535
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-8

In the flow explained above, tasks, such as setting up the design and
performing CDC checks, are accomplished after invoking the GUI.
Alternatively, GUI can be invoked after performing design setup and CDC
checks in the batch mode by using relevant Tcl commands. GUI is
populated with the results of already performance checks.
When start_gui or view_activity commands are invoked, VC SpyGlass
CDC internally launches Verdi in the background for improved
performance. To disable launching Verdi in the background, set the
following application variable, which has a default value of true, to false.
enable_verdi_background
Even though this application variable disables launching Verdi, all Verdi
related data will be created by VCst while running the design. To disable
this process as well, set the following application variable, which has a
default value of true, to false.
enable_verdi_debug
This application variable takes precedence over the
enable_verdi_background application variable.

536
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Analyzing the Results


You can analyze the results of the clock domain crossing related checks run
on a design using the GUI.
3. Click any tag of interest in the VC Static (VCst) tree to see a group of
similar tags reported for various CDC checks by the tool. All similar tags
are displayed in the data view of the GUI.
4. Click any tag to analyze the tag in the group as shown in Figure 10-9.
The pane that appears in the right bottom is called the information view
or detailed view. This is only available for the Open node and any node
below the Open node.

Figure 10-9Data View - Analyzing Results

5. Click the More Info…(Help) link in the Information view to understand


more about the error and its resolution.
6. Locators in the schematics are used to see the source and destination
points of the domain crossing. This helps you understand the violation

537
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

better. Locators are enabled by default. Click the Add Locator icon on
data view Toolbar to disable locators.
7. To see the information view of a violation, select a violation in the VC
Static (VCst) tree.
All the required information to understand the error is populated in the
information view, as shown in Figure 10-10.
a. To see the schematic, click the New Violation Schematic link.
b. To locate the point that is responsible for the ReasonCode, select the
respective ReasonCode from the ReasonInfoList to locate the reason
code in the schematic.

Figure 10-10Information View

As shown in Figure 10-11 adjust the locators to clearly observe the


violation. The GUI shows color coded flip-flops for each domain. Flip-
flops of the same color belong to a single domain.
By default, the Verdi GUI shows 4 or more gates inside a schematic
cloud. Use the schematic_cloud_gate_threshold application variable

538
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

to configure the Verdi GUI to show a reduced number of gates in a


schematic cloud.

Figure 10-11Schematic View

Using Filters
Filters are useful in highlighting unknown clock domain crossing violations.
Filters are used to filter out violations from many violations that meet the
criteria specified in the filter. This helps you focus on a group of violations
and resolve them quickly. This section describes the following:
 Creating a Filter for a Set of Violations
 Creating a Filter From a Single Violation
 Creating an Exclusive Subsets for Filtered Violations

539
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Creating a Filter for a Set of Violations


You can create filters by using the Create a Filter for the fields link on the
information view as shown in Figure 10-12.

Figure 10-12

Click the Create a Filter for the fields option to display the regular filtering
screen as shown in Figure 10-13.

540
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-13

You can select different fields based on different operators and apply filters.

Creating a Filter From a Single Violation


You can create a filter by using a selected violation from data view. To
create a filter, perform the following steps:
8. Select any violation from data view. The information view shows the
Create a Filter Template option as shown in Figure 10-14.

541
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-14

9. Click the Create a Filter Template option to create a filter from the
selected violation.

Creating an Exclusive Subsets for Filtered Violations


Exclusive subset is the set of unfiltered violations of a tag. When there are
filters applied for a tag, the Create Exclusive Subset feature can be used
to filter out the violations which are not included in any of the filters
applied under the tag.
This feature is available only for tags and levels below tags in the activity
tree. The feature is enabled only when there are one or more filters
applied. The following options are available to create an exclusive subset:
 Activity tree right-click menu command Create Exclusive Subset
 Create Exclusive Subset link from the information view

542
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-15f

Once the exclusive subset is created, it is displayed in the activity tree as a


new sibling node under the tag as shown in Figure 10-16. The violation
count for the exclusive subset is calculated by subtracting the total count of
filtered violations from the total violation count of the violation tag. The
violation count of the violation tag is also reduced and updated accordingly.

543
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Figure 10-16

Unlike a normal filter, exclusive subset is displayed with a green color.


You can create filters for an exclusive subset, Therefore, it is possible to
create an exclusive subset inside an existing exclusive subset.

Using Waivers
Waivers are useful in highlighting unknown clock domain crossing
violations.
Waivers are used to waive off tags/violations related to known issues or
issues that have already been analyzed. By introducing waivers, you can
keep track of the violations that are yet to be analyzed.
This section covers the following topics:
 Using Multiple Waiver Files
 Specifying the Waiver File While Creating Waivers
 Removing Waivers

544
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

 Editing Waivers
 Creating Waivers Data View Spreadsheet and Information View
 Waiving Violations in a Module

Using Multiple Waiver Files


VCst GUI supports multiple waiver files. This enables you to maintain more
than one waiver file. You can set one of them as the default waiver file
where the newly created waivers are included by default.
You can add multiple waiver files using GUI or Tcl commands (see the
Setting Waiver Files and Default Waiver File using Tcl Commands section).
There are two options to set waiver file in GUI:
 Using the Set Default Waiver File Option
 Using the Add New Waiver File Option

Using the Set Default Waiver File Option


To set default waiver file, perform the following steps:
1. Right click on activity tree > Set Default Waiver File.
If there are no existing waiver files, a pop-up menu, as shown in the

545
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

following figure, appears:

The following popup menu appears when waiver files are already
present, and one of them is selected as 'default'.

As displayed, the popup menu shows the check mark corresponding to


the current selected default waiver file. To change the default waiver
file, right click on the activity tree, click > Set Default Waiver File, and
select another file name. The check mark is updated to the selected file
and the setting is applied.
2. If no waiver files are present, click the Add waiver file option to add a
waiver file.

546
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

The Enter/Choose a Waiver File Name dialog box appears.


You can choose an existing waiver file from the list of available waiver
files. If you want to create a new waiver file, type a new name (such as,
new_waiver.tcl) in the File name box.

The Set this as Default Waiver File option is selected by default. This
option sets the selected file as the default waiver file.

Using the Add New Waiver File Option


To set the waiver file, perform the following steps:

547
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

1. Right click on activity tree > Add New Waiver File.

The Enter/Choose a Waiver File Name dialog box appears. See Step 2
for details.

Setting Waiver Files and Default Waiver File using Tcl Commands
Use the manage_waiver_file command to manage file-based waivers.
This command enables you to add waiver files while performing VC runs.
Syntax
%vc_static_shell> manage_waiver_file -help
Usage: manage_waiver_fileRead waivers from a file
-add(Add waiver file)
<file_name>(Waiver file name)
NOTE: An error is issued if the file does not exist or is not readable.
You must set the default_waiver_file application variable to set a file as
the default waiver file.
Example
Adding the following commands in the Tcl script adds three files, and sets
new1.tcl as default waiver file:

548
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

manage_waiver_file -add waiver2.tcl


manage_waiver_file -add waiver4.tcl
manage_waiver_file -add new1.tcl
set_app_var default_waiver_file new1.tcl

Specifying the Waiver File While Creating Waivers


You can also select the waiver file while creating waivers. For most waiver
creation flows (for example, Create a waiver or create a waiver based on
existing filter), the following waiver setup page is displayed. The Waiver
File drop-down list is added for such cases.

Select the default waiver file name from the Waiver File list to change the

549
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

default waiver file name. If any file is not selected from the Waiver File list,
waiver is added to the waiver file that is set as the default waiver file.
The Waiver File list also shows Add waiver option. You can use the Add
Waiver option to set additional file directly without going to the activity tree
right-click menu.
The following messages are reported if you have not set up any waiver file
and try to add waivers in the UI:
 If you are using one-click waiver (Waive this Item), the Enter/Choose a
Waiver File Name dialog box appears to select a waiver file. Closing this
dialog generates the following error message:

 If you are using the two-click waiver creation (example, 'Create a


waiver'), or when you create a filter and then generate a waiver based
on that filter, the waiver setup page comes up without any waiver files in
the corresponding 'Waiver File' drop-down list. If you continue to create
waiver by selecting the ADD Waiver option, the error message as shown
in the following figure appears.

NOTE: When you add the waiver file using above methods, except for deselecting Include
selected Waiver File content, the waivers contained in the file are added to the
database with the file name details. The waiver file management is applied only to
waivers added, changed, or deleted in the view_activity GUI. The save and
restore flow works with no requirement to repeat any commands.

550
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Removing Waivers
To remove a waiver file, perform the following steps:
1. Click activity tree right-click menu command > Remove Waiver File as
shown in the following figure.

A dialog box appears showing all the existing loaded waiver files.

551
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

2. The Remove Waiver Files dialog box appears showing all the existing
loaded waiver files as shown in the following figure.

3. Select the check box corresponding to the file/files to be removed and


click the Remove button to remove waiver files.
NOTE: To remove all waivers from UI, right mouse click on top level 'Waived' node and
select Remove all Waivers from the popup menu or select the Remove All Items
from the info page link as shown in the following figure.

552
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Editing Waivers
To edit a waiver, use the Edit this Waiver option in Waiver Control Console

553
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

as shown in the following figure.

When you click the Edit this Waiver option, the regular waiver setup page
appears as shown in the following figure. You can select fields from the

554
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

table.

The fields are populated from the existing waiver file. The non-existing
fields in the selected waiver are disabled and have "*" as the Match value.
You can specify the match value to waive specific message sets. After
editing, click the ADD Waiver option to overwrite the existing waiver file.

Creating Waivers Data View Spreadsheet and Information View


The following options are available in right-click menu of the data view

555
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

spreadsheet and in the information view.

To create waivers, right-click on the data view spreadsheet to show the


popup menu that has the Waive this Item and the Create a Waiver items.
You can start creating the waiver from either of the data view spreadsheet
or the links on the information view as highlighted in the above figure.

Waiving Violations in a Module


To waive violations contained in a block, use the
waive_cdc_block_violations Tcl command.
For example, consider the following SETUP_CLOCK_CONSTANT violation:
Tag : SETUP_CLOCK_CONSTANT
Description : Clock pin [PinName] set
to a constant
PinName : i_IP1/out/CLK
InstanceName : i_IP1/out
DestObjectType : flip-flop

556
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

ContainerScope
ContainerInstance : i_IP1
ContainerModule : IP1
In this case, s1 is the common parent instance of the i_IP1/out/CLK pin
and the i_IP1/out instance. In addition, IP1 is source module of the
instance.
You can use the waive_cdc_block_violations command to waive the
violations in the IP block specified with the command. For example, the
following command waives the violations in the IP1 block:
waive_cdc_block_violations -block IP1

Pivot Tables to Filter Violations


This section describes the following:
 Creating A Pivot Table
 Cross-probing from Pivot Table
 Cross-probing from Pivot Table

Creating A Pivot Table


Pivot table is quite useful in generating meaningful information from a
large-scale data set. This can be considered as an extended support for
filtering. User can select a combination of fields (visible in the data view
also) of the considered set of violations to create a pivot table.
A pivot table can be created using the activity tree right-click command
Create a Pivot Table as shown in following figure. This option is available
for tags and higher-level activity nodes, up to the Open node of the Activity
Tree.

557
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

This command opens Configure Pivot Table dialog appears with the
respective available Fields List as shown in the following figure.

558
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Check one or two fields to add them as Pivot rows and click the Add button
corresponding to Rows list box. Check another item from the Fields List and
click the Add button corresponding to Columns list box to add it as a Pivot
column (not mandatory). Click the OK button to create the pivot table.
The following figure shows a pivot table.

559
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

The first and Second column represents the two selected 'Row' fields (Only
first column if one row field is selected) and the values will be combination
of rows. If 'Column' field is selected, the corresponding unique values of
that field will show as each additional column with violation message
counts.
The last column shows the total counts of the row (If no column field
selected, then it will be count of row combinations)

Cross-probing from Pivot Table


Selecting a non-zero cell on a row will update the data view and shows the
corresponding violation messages matching to the count as displayed in
the pivot table, as shown in following figure.

560
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

Creating Multiple Pivot tables


You can create multiple pivot tables by going back to any desired Activity
Tree node and use the same procedure to create another pivot table. User
can give a different name to the pivot table in the Pivot table Configuration
dialog. The new pivot table will be opened in a new tab in the already
opened Pivot Table display dialog.

Exporting Violation Table


You can export the violation table displayed in the data view by using
Export Table for this Set of Violations link in the information view. A
snapshot of the currently displayed set of violations in the data view is
saved as a CSV file.

561
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Debugging CDC Violations Using GUI

562
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

Reports Generated by VC SpyGlass CDC


VC SpyGlass CDC generates a summary report after each run. A sample of
the generated report is shown below. For information on how to read and
use the report, see Debugging CDC Violations Using Tcl.

-----------------------------------------------------------
Report Summary
---------------------------------------------------------
Product Info
Name : VC Static Master Shell
Version :
Report Info
Created :
---------------------------------------------------------
Management Summary
---------------------------------------------------------
Stage Family Errors Warnings Infos
----- --------- -------- -------- --------
SETUP CLKPROP 0 1 6
SETUP RESET 0 0 1
STRUCT RESET 1 0 0
----- --------- -------- -------- --------
Total 1 1 7
---------------------------------------------------------
Tree Summary
---------------------------------------------------------
Severity Stage Tag Count
-------- ----- ------------------------ -----

563
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

error STRUCT SETUP_RESET_ASSERT_MISSING 1


warning SETUP SETUP_CLOCK_UNUSED 1
info SETUP SETUP_CLOCK_GROUP_INFER 2
info SETUP SETUP_PORT_CONSTRAINED 4
info SETUP SETUP_RESET_PROPAGATED 1
-------- ----- ------------------------ -----
Total 9
-----------------------------------------------------------
SETUP_RESET_ASSERT_MISSING (1 error/0 waived)
-----------------------------------------------------------
Tag : SETUP_RESET_ASSERT_MISSING
Description : [SeqType] [SeqObject] is not
asynchronously asserted
Violation : CDC:9
ResetInfoList
ResetInfo
ResetName : rst
ResetObject : rst
Reset Value : 1
SeqObject : out/Q
SeqType : Flip-flop

-----------------------------------------------------------
SETUP_CLOCK_UNUSED (1 warning/0 waived)
-----------------------------------------------------------
Tag :
SETUP_CLOCK_UNUSED
Description : Clock
object [Clock] in SDC clock command is not driving any

564
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

sequential element/ black box or delay constraints


Violation : CDC:3
SrcFileInfo
FileName :
test.tcl
LineNumber : 6
Clock
ClkName : clk1
ClkType :
SDC_CLOCK
ClkRootList
ClkRoot : clk1

-----------------------------------------------------------
SETUP_CLOCK_GROUP_INFER (2 infos/0 waived)
-----------------------------------------------------------
Tag :
SETUP_CLOCK_GROUP_INFER
Description : Clock
domain [ClkDomainId], consisting of the clock(s)
[ClksPropagated], has been inferred by the tool. It reaches
to [SeqPinReachable] sequential pin(s)
Violation : CDC:1
ClkDomainId : 1
ClksPropagated
Clock
ClkName : clk
ClkType :

565
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

SDC_CLOCK
ClkRootList
ClkRoot : clk
SeqPinReachable : 10
BBoxPinReachable : 0

-----------------------------------------------------------
Tag :
SETUP_CLOCK_GROUP_INFER
Description : Clock
domain [ClkDomainId], consisting of the clock(s)
[ClksPropagated], has been inferred by the tool. It reaches
to [SeqPinReachable] sequential pin(s)
Violation : CDC:2
ClkDomainId : 2
ClksNotPropagated
Clock
ClkName : clk1
ClkType :
SDC_CLOCK
ClkRootList
ClkRoot : clk1
SeqPinReachable : 0
BBoxPinReachable : 0

-----------------------------------------------------------
SETUP_PORT_CONSTRAINED (4 infos/0 waived)
-----------------------------------------------------------

566
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

Tag :
SETUP_PORT_CONSTRAINED
Description : Port
[PortName] is fully constrained
Violation : CDC:5
PortName : rst
Direction : Input
Status : Fully
constrained
Constraints
Constraint :
create_reset
Constraint :
set_cdc_attribute

-----------------------------------------------------------
Tag :
SETUP_PORT_CONSTRAINED
Description : Port
[PortName] is fully constrained
Violation : CDC:6
PortName : clk
Direction : Input
Status : Fully
constrained
Constraints
Constraint :
create_clock

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

567
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

Tag :
SETUP_PORT_CONSTRAINED
Description : Port
[PortName] is fully constrained
Violation : CDC:7
PortName : clk1
Direction : Input
Status : Fully
constrained
Constraints
Constraint :
create_clock

-----------------------------------------------------------
Tag :
SETUP_PORT_CONSTRAINED
Description : Port
[PortName] is fully constrained
Violation : CDC:8
PortName : in
Direction : Input
Status : Fully
constrained
Constraints
Constraint :
set_cdc_attribute

-----------------------------------------------------------
SETUP_RESET_PROPAGATED (1 info/0 waived)
-----------------------------------------------------------

568
Synopsys, Inc. Feedback
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

Tag :
SETUP_RESET_PROPAGATED
Description : Reset
[Reset] reaches to set/reset pin of some sequential(s)
Violation : CDC:4
Reset
ResetName : rst
RstType : Async
RstRootList
RstRoot : rst

569
Feedback Synopsys, Inc.
Analyzing VC SpyGlass CDC Results

Reports Generated by VC SpyGlass CDC

570
Synopsys, Inc. Feedback
Performing RCA on
Violations

As design sizes grow, setting up a design for CDC analysis with all
necessary constraints has become very challenging. It takes many
iterations before arriving at a valid setup to get meaningful and accurate
CDC analysis reports.
The number of CDC static checks are increasing and therefore more tool
expertise and domain expertise are required. Manually performing Root
Cause Analysis (RCA) of reported CDC violations and debugging them is
time consuming and error prone.
To automate this, VC SpyGlass CDC supports a new RCA flow that
leverages machine learning (ML) techniques to perform faster analysis of
the reported violations.
This section describes how to use this ML-based RCA feature to perform
CDC checks on a design that has CDC setup ready and how to perform RCA
on the reported violations for faster CDC analysis.

571
Feedback Synopsys, Inc.
Performing RCA on Violations

Prerequisites

Prerequisites
To run ML-based RCA feature, it is required that a design with VC SpyGlass
CDC setup is available.

Licensing Requirements
In addition, the ML-based RCA feature requires the VC-CDC-ADV license key.

Enabling ML-based RCA


To enable the ML-based RCA feature and to perform root cause analysis,
add the enable_rca_cluster -app cdc and the execute_rootcause_analysis
-app cdc commands in the CDC setup.

Configuring ML-based RCA


You can use the configure_cdc_rca command to specify configuration options
for the RCA flow, including tag-specific options for the DEBUG_CDC_*
cause-type violations.
The configure_cdc_rca command uses the following syntax:
configure_cdc_rca # configuration options for CDC RCA flow
[-tag <Tag>] (Specify the tag:
Values: DEBUG_CDC_ASYNC_CLOCKPAIR,
DEBUG_CDC_ASYNC_SRCDST_EQVDOMS,
DEBUG_CDC_BBOXPIN_CONSTRAINT, DEBUG_CDC_DST_HIGH_FANIN,
DEBUG_CDC_DST_INST_HIGH_FANIN, DEBUG_CDC_PORT_CONSTRAINT,
DEBUG_CDC_SRC_HIGH_FANOUT, DEBUG_CDC_SRC_INST_HIGH_FANOUT)
[-minimum_dest_signal_count <COUNT>]Specifies Minimum Unique
Destination Bus [SRC_HIGH_FANOUT]
[-minimum_src_signal_count <COUNT>]Specifies Minimum Unique
Source Bus Count [DEST_HIGH_FANIN]
[-async_dest_signal_atleast_one]Flags violation if atleast

572
Synopsys, Inc. Feedback
Performing RCA on Violations

Prerequisites

one Unsync Crossing present from source [SRC_HIGH_FANOUT]


[-async_dest_signal_all]Flags violation only if NO sync
crossings present from source [SRC_HIGH_FANOUT]
[-async_src_signal_atleast_one]Flags violation if atleast
one unsync crossing present to destination [DEST_HIGH_FANIN]
[-async_src_signal_all]Flags violation only if NO sync
crossings present to destination [DEST_HIGH_FANIN]
[-async_clk_domain_atleast_one]Flags violation if atleast
one asynchronous clock domain present [PORT/
BBOXPIN_CONSTRAINT]
[-async_clk_domain_only_one]Flags violation if ONLY one
asynchronous clock domain present [PORT/BBOXPIN_CONSTRINT]
[-async_crossings_only]Only consider count of unsync
crossings to flag an instance as high fanout / fanin. Used
for [SRC/DST_INST_HIGH_FANOUT/FANIN]
[-async_crossing_atleast_one] Considers instance as high
fanout / fanin if it contains atleast one unsync crossing.
USed for [SRC/DST_INST_HIGH_FANOUT/FANIN]
[-minimum_crossing_outside_inst <COUNT>] Specifies minimum
crossing count outside instance to be considered as high
fanout / fanin. [SRC/DST_INST_HIGH_FANOUT/FANIN])
[-exclude_datapath_partial]Excludes Data Path Partial
crossings. [ASYNC_CLOCKPAIR]
[-cocause_cutoff_threshold <CUTOFF>] Sets the threshold
percentage for cocause cut-off
[-enable_smart_group]Specifies this to enable generation of
SmartGroups during Clustering flow.
[-testlogic_filter_exp <SET OF STRINGS>]Specifies the string
to match to check TEST LOGIC Paths. [Used for TAG:
DEBUG_CDC_TESTLOGIC*])

573
Feedback Synopsys, Inc.
Performing RCA on Violations

Running CDC Checks with ML-based RCA

Running CDC Checks with ML-based RCA


To perform CDC checks with the ML-based RCA feature, modify VC
SpyGlass CDC setup to:
 Add the enable_rca_cluster -app cdc command before the
check_cdc command in the Tcl file
 Add the execute_rootcause_analysis -app cdc command after the
check_cdc command in the Tcl file
Retain the other settings in the VC Tcl file as required for CDC analysis. The
following sample Tcl file shows the location of the enable_rca_cluster -
app cdc and the execute_rootcause_analysis -app cdc commands:
set_app_var enable_cdc true
...
<Other app var setting if required for VC SpyGlass CDC run>
...
analyze <>
elaborate <>
read_sdc <vc/dc_setup>.sdc
source <cdc_config>.tcl #contains configure commands
enable_rca_cluster -app cdc# Enables RCA-ML feature
check_cdc
execute_rootcause_analysis -app cdc #Performs RCA
report_cdc
Ensure that the configure_cdc_tag command is specified after the
enable_rca_cluster -app cdc command in the ML-based RCA flow. If
configure_cdc_tag is followed by any enable_rca_cluster command,
then the configuration set through configure_cdc_tag gets overwritten.

Generated Logs
Once the ML-RCA run completes, review the vcst_rtdb/.internal/
adv_debug/cdc/output /coverge.log file to know the coverage statistics

574
Synopsys, Inc. Feedback
Performing RCA on Violations

Running CDC Checks with ML-based RCA

of the run.
The log captures the number for effect violations targeted in RCA analysis
and for how many violations the ML-based RCA feature found potential
effect violations, or root cause, and formed clusters. You can review and
confirm if potential cause/debug-clue reported by the tool are the real
reasons.
The following graphic shows a sample coverage.log file.

575
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Analyzing Results
Analyzing the results involve reviewing the log files generated after the ML-
RCA run and resolving the cause-effect violations reported in the generated
logs.
In the ML-RCA run, the existing setup violations are referred to as 'cause'
violations and subsequent violations from down-stream analysis are
referred as 'effect' violations.
The ML-based RCA feature adds more 'cause' type violations to allow you to
review the 'effect' violations to cover all possible potential root cause
analysis in one go. These new causes are called debug causes and starts
with the DEBUG_ string as highlighted in the following graphic:

Subsequent violations reported for the Sync stage are called ‘effect’
violations as highlighted in the following graphic:
NOTE: Currently, Debug RCA feature is supported only for SYNC type effect violations.

576
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

After performing root cause analysis based on reported Cause and Effect
Violations, the ML-based RCA feature reports the 'cause-effect' violations in
smart-groups, called Clusters or RCA Clusters, which is the outcome of
RCA, for your review and analysis.

577
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

The following graphic highlights the RCA Clusters:

Review the RCA clusters from Rank 1 to the last and check if the Cause
violation for the Effect violation in a cluster are real reasons for the
violations. If the reported violations are correct, fix the issue in the set up
or the design as appropriate.
Continue to analyze the next cluster until the review and analysis is
complete for all the reported clusters.
Analyzing all potential causes and fixing them reduces the reported effect
violations and enables you to quickly make your design CDC clean.
The ML-based RCA run reports the following debug causes:
 DEBUG_CDC_CLUSTER
 DEBUG_CDC_ASYNC_CLOCKPAIR
 DEBUG_CDC_PORT_CONSTRAINT
 DEBUG_CDC_BBOXPIN_CONSTRAINT

578
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

 DEBUG_CDC_BOTTLENECK_THROUGH_POINT
 DEBUG_CDC_BOTTLENECK_THROUGH_SET
 DEBUG_CDC_SRC_HIGH_FANOUT
 DEBUG_CDC_DST_HIGH_FANIN
 DEBUG_CDC_SRC_INST_HIGH_FANOUT
 DEBUG_CDC_DST_INST_HIGH_FANIN
 DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH
 DEBUG_CDC_QUALIFIER_BLOCKED
 DEBUG_CDC_QUALIFIER_POTENTIAL
 DEBUG_CDC_TESTLOGIC_SOURCE
 DEBUG_CDC_TESTLOGIC_DESTINATION
 DEBUG_CDC_TESTLOGIC_SRCCLK
 DEBUG_CDC_TESTLOGIC_DSTCLK
 DEBUG_CDC_SRCCLK_DSTCLK_CONNECTED
 DEBUG_CDC_ASYNC_SRCDST_EQVDOMS
 DEBUG_CDC_MEMLOGIC_SOURCE
 DEBUG_CDC_MEMLOGIC_DESTINATION
 DEBUG_CDC_CLOCK_OVERLAP_SYNCASYNC
 DEBUG_CDC_QUALIFIER_DIFF_DOMAIN
You can rename any ML-based RCA debug tags by using the following
command:
rename_command <old_tagname> <new_tagname>

579
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_CLUSTER
Severity
Error

Short Help
Set of violations for which the root cause is same.

Description
VC SpyGlass CDC reports this debug cluster to show the set of effect
violations that has the same debug clause.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
Review and analyze each debug cluster on the basis of ClusterRank, and
fix the debug causes if it is a valid RCA scenario.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

580
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_ASYNC_CLOCKPAIR
Severity
Warning

Short Help
Asynchronous clock pairs contribute to only unsynchronized CDC paths.

Description
VC SpyGlass CDC reports this debug cause only for those asynchronous
clock pairs that do not appear as source-dest clock pairs in any
synchronous crossings.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. This mostly indicates that all paths are
unsynchronized or partially synchronized and actual fix may not be
practical because the clock-relationship in SDC file are linked to legacy or
the design architect’s decision or is back-end-driven (clock skew).

581
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

However, this can help to filter and review for applying waivers. In addition,
it can help in an actual design fix where you may review the reported clock
pairs to check if they need to be defined as synchronous or mutually
exclusive.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

582
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_PORT_CONSTRAINT
Severity
Warning

Short Help
Incorrect clock attribute(s).

Description
VC SpyGlass CDC reports this debug cause if a clock relation or domain is
incorrectly defined or port is mistakenly associated with an unexpected
clock.
By default, this tag is reported if the pin in consideration participates in at
least one such unsynchronized or partially synchronized crossing where the
src-dest domains have no SYNC crossing associated with the given pin.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_PORT_CONSTRAINT command, you can configure this
tag to report in the following modes:
 [-async_clk_domain_atleast_one]: Reports violation if at least one
asynchronous clock domain is present.
 [-async_clk_domain_only_one]: Reports violation if only one
asynchronous clock domain is present.

583
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

In the above schematic, in1 is constrained to the clk1 clock and the out1
destination flop is connected to the clk2 clock. Here, a clock domain
crossing occurs between in1 and out1/Q. This might be the valid scenario
for review.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This might result in inaccurate CDC analysis because the clock relation is
incorrectly defined.
To fix the corresponding effect violation highlighted for this debug cause,
review the defined clock relation in the design and make sure that it is
intentional. Else, modify the required clock relationship in the design.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_PORT_CONSTRAINT -
async_clk_domain_only_one
execute_rootcause_analysis -app cdc

Related App-var(s)
None

584
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_BBOXPIN_CONSTRAINT
Severity
Warning

Short Help
Incorrect clock attribute(s) on black box pin.

Description
VC SpyGlass CDC reports this debug cause if a black box port is used as a
source or destination of an unsynchronized/partial crossing and if a clock
relation or domain is incorrectly defined or port is erroneously associated
with an unexpected clock.
By default, this tag is reported if the black box port in consideration
participates in at least one such unsynchronized or partially synchronized
crossing where the src-dest domains have no SYNC crossing associated
with the pin.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_BBOXPIN_CONSTRAINT command, you can configure
this tag to report in the following modes:
 [-async_clk_domain_atleast_one]: Reports violation if at least one
asynchronous clock domain is present.
 [-async_clk_domain_only_one]: Reports violation if ONLY one
asynchronous clock domain is present.

585
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This might result in inaccurate CDC analysis because the clock relation is
incorrectly defined. To fix the corresponding effect violation highlighted for
this debug cause, review the defined clock relation in the design and make
sure that it is intentional. Else, modify the required clock relationship in the
design.
If the clock relationship is correct, review if the inferred/defined clock for
the black box pin is as per the design intent.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_BBOXPIN_CONSTRAINT -
async_clk_domain_only_one / -async_clk_domain_atleast_one>
execute_rootcause_analysis -app cdc

Related App-var(s)
None

586
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_BOTTLENECK_THROUGH_POINT
Severity
Warning

Short Help
Adding path gating logic at boundary pin can synchronize <n> paths

Description
VC SpyGlass CDC RCA reports this debug cause if multiple crossings are
passing through the same hierarchical boundary port as shown in the
following schematic.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

What Next
This might help you in analyzing the CDC violations that are passing
through the same bottleneck through point.

587
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

To fix the corresponding effect violation highlighted for this debug cause,
apply the gating logic on this port to synchronize the crossing.

Related Command(s)
 configure_cdc_rca: Specifies configuration options for CDC RCA flow.

Related App-var(s)
None

588
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_BOTTLENECK_THROUGH_SET
Severity
Warning

Short Help
Adding path gating logic at one of the boundary pins can synchronize <n>
paths

Description
VC SpyGlass CDC RCA reports this debug cause if multiple crossings are
passing through a set of hierarchical boundary port as shown in the
following schematic.
This tag is disabled by default. To enable it, use the configure_cdc_tag -
enable command.

589
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

What Next
Review the violation because this may help in analyzing the CDC violations
that are passing through a set of common hierarchical ports. To fix this
debug cause, apply gating logic on these ports so that crossings are
synchronized.

Related Command(s)
 configure_cdc_rca: Specifies configuration options for CDC RCA flow.

Related App-var(s)
None

590
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_SRC_HIGH_FANOUT
Severity
Warning

Short Help
Source bus participating in a large number of unsynchronized crossings.

Description
VC SpyGlass CDC reports this debug cause if a source bus is participating
in a large number of unsynchronized crossings.
By default, this tag is reported if a source point has crossings reaching to
at least 20 different bus signals, of which at least ONE is unsynchronized.
You can configure the minimum number of crossings.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_SRC_HIGH_FANOUT command, you can configure this
tag to report in the following modes:
 [-minimum_dest_signal_count <COUNT>]: Configures the minimum
number of bus-merged destination signals. By default, the number is set
to 20.
 [-async_dest_signal_atleast_one]: Reports a violation if at least
one unsynchronized crossing is present from the source point.
 [-async_dest_signal_all]: Reports a violation only if NO synchronous
crossings are present from the source point.

591
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the signals to analyze if these
signals are static signals because such logic and registers are usually
special control logic. Consider applying the create_static command to
such signals to fix the issue.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_SRC_HIGH_FANOUT [-
minimum_dest_signal_count <COUNT>] / [-
async_dest_signal_atleast_one] / [-async_dest_signal_all]
execute_rootcause_analysis -app cdc

Related App-var(s)
None

592
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_DST_HIGH_FANIN
Severity
Warning

Short Help
Destination bus participating in a large number of unsynchronized
crossings.

Description
VC SpyGlass CDC reports this debug cause if a destination bus is
participating in a large number of unsynchronized crossings.
By default, this tag is reported if a destination point has crossings coming
from at least 20 different bus signals of which at least one is
unsynchronized. You can configure the minimum number of crossings.
If the mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_DST_HIGH_FANIN command, this tag can be configured
to flag in the following modes:
 [-minimum_src_signal_count <COUNT>]: Specifies the minimum
number of unique bus-merged source signals. By default, the number is
set to 20.
 [-async_src_signal_atleast_one]: Reports violation if at least one
unsynchronized crossing is present at the specified destination point.

593
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

 [-async_src_signal_all]: Reports violation only if no sync crossing is


present at the specified destination point.

Prerequisites
enable_rca_cluster -app cdc

What Next
This is an informational message because the presence of such logic and
registers is rare. However, review and fix the cause violations if it is a valid
scenario.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_DST_HIGH_FANIN [-
minimum_src_signal_count <COUNT>] / [-
async_src_signal_atleast_one] / [-async_src_signal_all]
execute_rootcause_analysis -app cdc

Related App-var(s)
None

594
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_SRC_INST_HIGH_FANOUT
Severity
Warning

Short Help
Incorrect clock connection for the specified source.

Description
VC SpyGlass CDC reports this debug cause if some clock connection is
incorrect for the specified source, which results in a large number of
unsynchronized crossings.
By default, this debug cause is reported if a point acts as source for a
minimum of 1000 unsynchronized crossings. You can configure the
minimum number of crossings.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_SRC_INST_HIGH_FANOUT command, this tag can be
configured to flag in the following modes:
 [-async_crossings_only]: Consider only the count of unsynchronized
crossings to flag an instance as high fanout.
 [-async_crossing_atleast_one]: Considers instance as high fanout if
it contains at least one unsynchronized crossing.
 [-minimum_crossing_outside_inst <COUNT>]: Specifies the minimum
count of bit-blasted crossings occurring outside an instance to be
considered as high fanout. By default, the number is set to 1000.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message because such a module/block is special
control logic and requires a user review.

595
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_SRC_INST_HIGH_FANOUT [-
async_crossings_only]/ [-async_crossing_atleast_one]/ [-
minimum_crossing_outside_inst <COUNT>]
execute_rootcause_analysis -app cdc

Related App-var(s)
None

596
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_DST_INST_HIGH_FANIN
Severity
Warning

Short Help
Incorrect clock connection for the specified destination.

Description
VC SpyGlass CDC reports this debug cause if some clock connection is
incorrect for the specified destination, which results in large number of
unsynchronized crossings.
By default, this debug cause is reported if a point acts as destination for a
minimum of 1000 unsynchronized crossings. You can configure the
minimum number of crossings.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_DST_INST_HIGH_FANIN command, you can configure
this tag to report in the following modes:
 [-async_crossings_only]: Consider only the count of unsynchronized
crossings to flag an instance as high fanin.
 [-async_crossing_atleast_one]: Considers instance as high fanin if it
contains at least one unsynchronized crossing.

597
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

 [-minimum_crossing_outside_inst <COUNT>]: Specifies the minimum


count of bit-blasted crossings occurring outside an instance to be
considered as high fanin. By default, the number is set to 1000.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message because such a module/block is special
control logic and requires a user review.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_DST_INST_HIGH_FANIN [-
async_crossings_only]/ [-async_crossing_atleast_one]/ [-
minimum_crossing_outside_inst <COUNT>]
execute_rootcause_analysis -app cdc

Related App-var(s)
None

598
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH
Severity
Warning

Short Help
Default qualifier propagation sequential depth modified.

Description
VC SpyGlass CDC reports this debug cause if the NFF sync depth is
modified by the user and set to a value lower than the default Qualifier
Propagation Sequential Depth. This can be a valid RCA scenario for the
user to check because with the default depth, qualifiers might qualify more
CDC paths.
If mode configuration is enabled by using the configure_cdc_tag -
enable DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH command, you can
configure this tag to report in the following mode:
 [-potential_default_depth <DEPTH>]: Specifies the potential default
qualifier depth to check for possible synchronization. Default value is 3.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions

599
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

None

What Next
This is an informational message. Review the value of the NFF sync depth
and ensure that a value lower than the default depth is intentional.

Related Command(s)
configure_cdc_tag -enable DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH [-
potential_default_depth <DEPTH>]
execute_rootcause_analysis -app cdc

Related App-var(s)
None

600
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_QUALIFIER_BLOCKED
Severity
Warning

Short Help
Qualifier reaching to the destination node is blocked by blocking logic.

Description
VC SpyGlass CDC reports this debug cause if a qualifier reaching to the
destination node is blocked by a blocking gate. Therefore, if a qualifier does
exist but blocked by a known SCA scenario or due to bad SCA setup from
CDC sign-off perspective, it should be reviewed by the designer.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review if the qualifier is blocked as per
the design intent because the blocked qualifier might have been introduced
to synchronize multiple crossings. Therefore, fixing this issue would fix all
unsynchronized crossings.

601
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

602
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_QUALIFIER_POTENTIAL
Severity
Warning

Short Help
Partial NFF sync qualifier reaching to a destination.

Description
VC SpyGlass CDC reports this debug cause if a potentially valid qualifier
object is reaching to a destination but is partial NFF Sync in nature.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the qualifier because modifying
such potential qualifier can result in qualifying a higher number of CDC
paths.

603
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

604
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_TESTLOGIC_SOURCE
Severity
Warning

Short Help
Source bus is potentially test logic, which participates in unsynchronized
crossing.

Description
VC SpyGlass CDC reports this debug cause if a source bus that is
potentially test logic participates in unsynchronized crossings. It is reported
if a source register has the following patterns in its name "TEST/BIST/SCAN/
DFT". You can also override the pattern to search for by using the
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search> configure command.
If mode configuration is enabled by using the configure_cdc_rca command,
you can configure this tag to report in the following mode:
 [-group_testlogic_violations]: Groups all TESTLOGIC_SOURCE /
TESTLOGIC_DESTINATION violations in to one violation. Default value is
OFF.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions

605
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

None

What Next
This is an informational message. Review the violation because the bus
acts as a source in unsynchronized crossings.

Related Command(s)
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search>
configure_cdc_rca -group_testlogic_violations
execute_rootcause_analysis -app cdc

Related App-var(s)
None

606
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_TESTLOGIC_DESTINATION
Severity
Warning

Short Help
Destination bus is potentially test logic, which participates in
unsynchronized crossing.

Description
VC SpyGlass CDC reports this debug cause if a destination bus that is
potentially test logic participates in unsynchronized crossings. It is reported
if a destination register has the "TEST/BIST/SCAN/DFT" patterns in its
name. You can also override the pattern to search for by using the
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search> configure command.
If mode configuration is enabled by using the configure_cdc_rca command,
you can configure this tag to report in the following mode:
 [-group_testlogic_violations]: Groups all TESTLOGIC_SOURCE /
TESTLOGIC_DESTINATION violations in to one violation. Default value is
OFF.

Prerequisites

607
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

enable_rca_cluster -app cdc


Rule Exceptions
None

What Next
This is an informational message. Review the violation because the bus
acts as a destination in unsynchronized crossings.

Related Command(s)
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search>
configure_cdc_rca -group_testlogic_violations
execute_rootcause_analysis -app cdc

Related App-var(s)
None

608
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_TESTLOGIC_SRCCLK
Severity
Warning

Short Help
Source clock is potentially test logic, which participates in unsynchronized
crossing.

Description
VC SpyGlass CDC reports this debug cause if a defined source SDC clock
that is potentially test logic participates in unsynchronized crossings. It is
reported if a source clock has the "TEST/BIST/SCAN/DFT" patterns in its
name. You can also override the pattern to search for by using the
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search> configure command.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the violation because the source

609
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

clock is participating in unsynchronized crossings.

Related Command(s)
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search>
execute_rootcause_analysis -app cdc

Related App-var(s)
None

610
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_TESTLOGIC_DSTCLK
Severity
Warning

Short Help
Destination clock is potentially test logic, which participates in
unsynchronized crossing.

Description
VC SpyGlass CDC reports this debug cause if a defined destination SDC
clock that is potentially test logic participates in unsynchronized crossings.
It is reported if a destination clock has the "TEST/BIST/SCAN/DFT" patterns
in its name. You can also override the pattern to search for by using the
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search> configure command.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the violation because the
destination clock is participating in unsynchronized crossings.

611
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Related Command(s)
configure_cdc_rca -testlogic_filter_exp <list-of-strings-to-
search>
execute_rootcause_analysis -app cdc

Related App-var(s)
None

612
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_SRCCLK_DSTCLK_CONNECTED
Severity
Warning

Short Help
Driver Clock converges at declaration of Child Clock but defined as
asynchronous clocks.

Description
VC SpyGlass CDC RCA reports this debug cause if the source and
destination clocks of an unsynchronized crossing are connected in a
manner where either of the two clocks reach the definition of the other
clock.

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This might result in inaccurate CDC analysis because the clock relation is
defined incorrectly.

613
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

To fix the corresponding effect violation highlighted for this debug cause,
review the defined clock domain relationship in the design and make sure
that it is intentional. Else, modify the required clock domain relationship in
the design.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

614
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_ASYNC_SRCDST_EQVDOMS
Severity
Warning

Short Help
Source and destination clock pairs form equivalent domains.

Description
VC SpyGlass CDC RCA reports this debug cause when the source and
destination clocks are converging and forming equivalent domains at both
sides. In this case, asynchronous clock pairs are formed by these two sets
of user-defined clocks that have identical set of source clocks and
destination clocks.

In the above schematic, the clk3 clock is synchronous with clk1 and clk2.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

615
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

What Next
This is an informational message. It is recommended that you review it
because such scenarios are noisy and should be pruned based on domains.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

616
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_MEMLOGIC_SOURCE
Severity
Warning

Short Help
Source bus is potentially memory logic, which participates in
unsynchronized crossing.

Description
VC SpyGlass CDC reports this debug cause if the source object of a
crossing is defined as part of memory logic or such behavior is inferred by
the tool based on the dimension/size properties of the object.
The default size/dimension properties considered are:
 Dimension > 1
 Size of all bits in the bus >= 1024
If mode configuration is enabled by using the configure_cdc_rca command,
you can configure this tag to report in the following modes:
 [-group_memlogic_violations]: Groups all MEMLOGIC_SOURCE /
MEMLOGIC_DESTINATION violations in to one violation. Default value is
OFF.
 [-memlogic_bus_size_threshold <SIZE>]: Specifies the threshold to
check bus sizes for filtering MEMLOGIC objects. Default value is 1024.

617
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the violation because the source
bus is participating in unsynchronized crossings.

Related Command(s)
configure_cdc_rca -group_memlogic_violations
execute_rootcause_analysis -app cdc

Related App-var(s)
None

618
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_MEMLOGIC_DESTINATION
Severity
Warning

Short Help
Destination bus is potentially memory logic, which participates in
unsynchronized crossing.

Description
VC SpyGlass CDC reports this debug cause if the destination object of a
crossing is defined as part of memory logic or such behavior is inferred by
the tool based on the dimension/size properties of the object. The default
size/dimension properties considered are:
 Dimension > 1
 Size of all bits in the bus >= 1024
If mode configuration is enabled by using the configure_cdc_rca command,
you can configure this tag to report in the following modes:
 [-group_memlogic_violations]: Groups all MEMLOGIC_SOURCE /
MEMLOGIC_DESTINATION violations in to one violation. Default value is
OFF.
 [-memlogic_bus_size_threshold <SIZE>]: Specifies the threshold to
check bus sizes for filtering MEMLOGIC objects. Default value is 1024.

619
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. Review the violation because the
destination bus is participating in unsynchronized crossings.

Related Command(s)
configure_cdc_rca -group_memlogic_violations
execute_rootcause_analysis -app cdc

Related App-var(s)
None

620
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_CLOCK_OVERLAP_SYNCASYNC
Severity
Warning

Short Help
Composite clock root which forms both synchronous and asynchronous
paths with another clock root.

Description
VC SpyGlass CDC reports this debug cause if at-least 1 synchronous pair
exist between the cross product of the composite SDC clocks of the two
roots. This debug cause is reported in the following scenarios for the
specified clock pair relationship:
 Scenario 1: SDC Clock clk3 is asynchronous with clock clk1 but
synchronous with clock clk2 (Sync pairs:clk1,clk1}, {clk2,clk2},
{ck2,clk3})
 Scenario 2: SDC Clock clk3 is asynchronous with clock clk2 but
synchronous with clock clk1 (Sync pairs:{clk1,clk1}, {clk2,clk2},
{clk1,clk3})
 Scenario 3: SDC Clock clk3 is asynchronous with clocks clk1 and clk2
(Sync pairs: {clk1,clk1}, {clk2,clk2})

621
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
This is an informational message. It is recommended that you review it
because such scenarios are noisy and should be pruned based on domains.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

622
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_QUALIFIER_DIFF_DOMAIN
Severity
Warning

Short Help
Qualifier reaching to destination object is of different domains.

Description
VC SpyGlass CDC reports this debug cause if a potentially sync NFF object
is reaching to the destination object but is of a different domain. This is a
valid RCA scenario to check because if the domain specification is
corrected, qualifiers might qualify more CDC paths.
Consider the following schematic:

Here, in this schematic, Qualifier Domain is clk3, whereas destination is of


domain clk2.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions

623
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

None

What Next
This is an informational message. It is recommended that you review it and
fix the clock domain specification if it is a valid RCA scenario.

Related Command(s)
execute_rootcause_analysis -app cdc

Related App-var(s)
None

624
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_GRAY_ENCODED_SIGNAL
Severity
Warning

Short Help
Potential gray encoded Signal GrayEncodedSignal in convergence where at
least one vector bus control path is participating in convergence

Description
VC SpyGlass CDC reports this debug cause if there is a potential gray
encoded signal participating in convergence where at least one vector bus
control path is converging.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
Review the potential gray encoded signal and fix it if it is a valid RCA
scenario.

Related Command(s)
configure_cdc_rca

Related App-var(s)
None

625
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_CONV_GRAYSIG_SRCBUS
Severity
Warning

Short Help
Potential gray encoded Signal in convergence where multiple control paths
with vector source signal are participating in convergence

Description
VC SpyGlass CDC reports this debug cause if potential gray encoded
signals are converging where multiple control paths with vector source
signal are converging.
This tag is disabled by default. Use the configure_cdc_tag -enable
command to enable it.
This cause violation is specific to only conv stage clustering. Therefore, this
cause violation will take part in clustering only when the
execute_rootcause_analysis -stage conv is run.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
Review the potential gray encoded signal and fix it if it is a valid RCA
scenario.

Related Command(s)
configure_cdc_rca

Related App-var(s)
None

626
Synopsys, Inc. Feedback
Performing RCA on Violations

Analyzing Results

DEBUG_CDC_CONV_GRAYSIG_COUNTER
Severity
Warning

Short Help
Potential gray encoded Signal in convergence where multiple control paths
with vector source forming counter signal are participating in convergence

Description
VC SpyGlass CDC reports this debug cause if potential gray encoded
signals are converging where multiple control paths with vector source
forming counter signal are converging.
This tag is disabled by default. Use the configure_cdc_tag -enable
command to enable it.
This cause violation is specific to only conv stage clustering. Therefore, this
cause violation will take part in clustering only when the
execute_rootcause_analysis -stage conv is run.
Prerequisites
enable_rca_cluster -app cdc
Rule Exceptions
None

What Next
Review the potential gray encoded signal and fix it if it is a valid RCA
scenario.

Related Command(s)
configure_cdc_rca

Related App-var(s)
None

627
Feedback Synopsys, Inc.
Performing RCA on Violations

Analyzing Results

628
Synopsys, Inc. Feedback
Generating and Using
Metastability Monitors

Metastability monitors generated by check_cdc -type jitter can be


simulated in functional simulation environment by using the VCS simulator.
NOTE: Use the VC-CDC-ADV and VC-CDC-JITTER-GEN licenses to use metastability
monitors during simulation. To run metastability monitors on third party simulators,
use the VC-SG-DS-TP license.
This section covers the following topics:
 Specifying Signals for Monitor Generation
 Output of Metastability Analysis
 Cases When Metastability Injection Does Not Occur
 Running Metastability Monitors in VCS
 Debugging Simulation Results
NOTE: Metastability models are available for VCS - Verilog. Metastability models are
not available for VCS-VHDL and Mixed.

629
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Specifying Signals for Monitor Generation

Specifying Signals for Monitor Generation


By default, monitors are generated for the following types of signals:
 Unsynchronized scalar signals reported by the NFF_SYNC tags.
 Signals synchronized by using any of the following synchronization
schemes (such signals are reported by the tags):
 Conventional Multi-Flop Synchronization Scheme
Consider the following figure:

In the above figure, monitors are generated for the des signal as the
destination signal is synchronized by using Conventional Multi-Flop
Synchronization Scheme.
 Synchronizing Cell Synchronization Scheme

630
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Output of Metastability Analysis

Output of Metastability Analysis


When check_cdc -type jitter is run, jitter database file is generated in
the ./vcst_rtdb/cdc_jitter directory with the following name:
dynamic_jitter_cdc_db<top name>
NOTE: This feature is currently supported for Verilog designs only.

631
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Cases When Metastability Injection Does Not Occur

Cases When Metastability Injection Does Not


Occur
Metastability injection does not occur during simulation when any of the
following condition is true:
 An asynchronous reset or set of the destination flip-flop is asserted.
 The enable of the destination flip-flop is inactive.
 The destination domain signal (synchronous source) in the input cone of
a destination signal changes.
Error injection is considered only when asynchronous sources change
without a change in the synchronous source, as shown in the following
figure:

Figure 12-17Case of Error Injection

632
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Running Metastability Monitors in VCS

Running Metastability Monitors in VCS


This section lists the steps to run metastability monitors in VCS. To run
metastability monitors, perform the following steps:
1. Run VC SpyGlass CDC with the following command in the tcl file:
check_cdc -type jitter
2. Run VCS with jitter
%> vcs -o simv -debug_access+all -kdb +vcs+fsdbon
<sourcefiles> -dynamic_cdc -dynamic_cdc_db=<path-to-
monitor-database-file> -dynamic_cdc_convergence -sverilog
-full64 -Xdyncdc=0x40
simv -dynamic_cdc
3. Open VERDI GUI for jitter analysis by using the following commands:
setenv FSDB_JITTER 1
setenv DYNAMIC_CDC_DEBUG 1
simv -dynamic_cdc -verdi &
4. Load the waveform by performing the following steps:
a. Click any destination flop on a synchronized crossing
b. Click on Signal_list button.
c. Select all the signals in signal_list view and add them to new wave
(Right Click -> Add to waveform)

633
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Running Metastability Monitors in VCS

NOTE: You can drag and drop above signal bundle into an already open wave window.

Next, run the Simulation.

The orange dots in the waveform represent jitter points.

Perform the following steps to see the jitter information on the pointer tip.

634
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Running Metastability Monitors in VCS

5. Go to nWave window
6. Click Tools ---> Preferences ---> double click on Waveform ---> double
click on view options ---> double click on waveform pane ---> click
"Enable Tip" ---> Apply ---> ok.
7. Place the cursor on each orange dot to see jitter information

Next, open Verdi GUI without jitter by using the following command:
%> simv_n -verdi &
Perform the above steps to load the waveforms in Verdi GUI. The following

635
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Running Metastability Monitors in VCS

figure shoes the waveform in the Verdi GUI:

Note that without jitter, data [1] and data[2] changes uniformly.

636
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Debugging Simulation Results

Debugging Simulation Results


To debug, use the tracediff command.

Tracediff Command
Tracediff is a tool used to compare 2 fsdbs and trace back the cause for any
signal value differences found.
Tracediff works in two modes
 Auto mode
 Manual mode
In auto mode, the tracediff utility automatically finds the diff in signals
and traces back them to the root cause i.e starting point where the change
of signal value start to appear.
In manual mode, you can give a set of signals that must be checked for
signal value differences in fsdbs and trace back if possible.
You can generate two fsdbs with the design with jitter injected fsdb and
normal fsdb and compare them using tracediff.

Using tracediff
Perform the following steps:
1. Generate FSDBs for normal simulation and with jitter simulation
2. Set env FSDB_GATE = 0
3. Run tracediff
a. Auto Mode
tracediff -lca -ssf no_jitter.fsdb -new_fsdb jitter.fsdb -
out_file ./trace_diff.log
b. Manual Mode
tracediff -lca -ssf no_jitter.fsdb -new_fsdb jitter.fsdb -
in_file ./tracediff.cfg -out_file ./trace_diff.log
NOTE: In manual mode, you need to specify tracediff.cfg. This file contains the required
signal name and the time stamp to start the traceback as shown in the following

637
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Debugging Simulation Results

figure. Note that in the figure, #780 is the time stamp.

Example
Refer the following schematic.

Custom assertions have been written to check f6_out and f4_out signals
has same values pairs at all times. Therefore, if f3_out or f6_out has
different values pairs {1 0} or {0 1}, assertion will fail.
Therefore, the /Assertion_mod_test/CUSTOM_ASSERT/data[1:0]#564
signal is set in config file. You can review the waveform to obtain the
required time stamp.

638
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Debugging Simulation Results

Refer following figure. At time 564 we can observe a failure.

Next, run tracediff in manual mode by using the following command:


tracediff -lca -ssf no_jitter.fsdb -new_fsdb jitter.fsdb -
compare_scope -in_file ./tracediff.cfg -out_file ./
trace_diff.log

639
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Debugging Simulation Results

Next, use the following command:


verdi -load_trace_report ./trace_diff.log &

640
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Debugging Simulation Results

On Line 14, the root cause for signal value change in #564 for the /
Assertion_mod_test/CUSTOM_ASSERT/data[1:0] signal can be found.
Then, by clicking on line 15, a flow diagram can be opened with more
details.

You can observe that started in time stamp #493, a change of the value
propagated through several instances and caused the failure in time stamp
#564.

641
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Debugging Simulation Results

Failure point can be found at #564.

642
Synopsys, Inc. Feedback
Generating and Using Metastability Monitors

Debugging Simulation Results

Dynamic CDC Coverage Report


After VCS simulation completes, the dynamic_cdc_coverage.rpt report is
generated in the Simulation directory. The following figure shows a
sample of the dynamic_cdc_coverage.rpt report.

The Dynamic CDC Verification Coverage Summary section includes the


following information about all jitter injected signals:
 Toggle: Shows information about the signals which toggle during
simulation.
 Async D Toggle: Shows information about the signals which toggle due
to only asynchronous sources.
 No Jitter: Shows information about the signals where Async D Toggle
occurred but error injection was not performed.
 Delayed Jitter: Shows information about the signals on which error
injected by the models is due to setup time violations.
If you specify the -dynamic_cdc_convergence argument with the VCS
command, the Dynamic CDC Convergence Report section is additionally
generated as shown in the following figure.

643
Feedback Synopsys, Inc.
Generating and Using Metastability Monitors

Debugging Simulation Results

The report includes the following information about each jitter injected
signal in hierarchical form:
 Convergence Group: Convergence Group ID in database file
 Converging Signal count: Number of signals in convergence group
 Number of single signal toggles: Number of signal toggles coming
from only one signal toggle at a time
 Number of multi signal toggles: Number of signal toggles coming
from multiple signals toggling at a time
The last section of the table provides information about jointly toggled
signals. In the sample report above, there are 2 signals, of all the
signals in this convergence group, has toggled together 29 times. Out of
these 29, jitter is injected into 24 toggles.

644
Synopsys, Inc. Feedback
Hybrid Flow

This section summarizes the VC SpyGlass CDC Hybrid flow.


The VC SpyGlass Hybrid flow generates System Verilog Assertions for
structural rules and selected set of constraints.
NOTE: Use the VC-CDC-ADV and VC-CDC-JITTER-GEN licenses to use metastability
monitors during simulation..

645
Feedback Synopsys, Inc.
Hybrid Flow

VC SpyGlass Hybrid Flow

VC SpyGlass Hybrid Flow


Structural rule-related SVAs are generated for following issue types:
 Data Loss
 Data coherency
 Glitch
 Data-Hold
Constraint-based SVAs are generated for following constraints:
 create_clock
 create_reset
 set_case_analysis
 set_input_delay
 configure_cdc_convergence -ignore_among_signals { <signal list> }
 set_rdc_define_assertion_sequence
 set_rdc_static

646
Synopsys, Inc. Feedback
Hybrid Flow

Generating SVAs for Simulation

Generating SVAs for Simulation


There are two ways to generate SVAs. Run the following tcl command.
%> write_cdc_property -simulator vcs|ncsim|modelsim|all
VC SpyGlass CDC generates following set of files:
vcst_rtdb/assertions/VCS/rules/
hybrid_rules_prop_<top_name>_vcs.sv
vcst_rtdb/assertions/VCS/rules/
hybrid_rules_prop_<top_name>_bind.sv
vcst_rtdb/assertions/VCS/assumptions/hybrid
vcst_rtdb/assertions/VCS/rules/inc_common.f
vcst_rtdb/assertions/VCS/rules/run_rules.f
For constraints, similar set of files are generated in
vcst_rtdb/assertions/VCS/assumptions/…
The inc_common.f file contains following:
$VC_STATIC_HOME/auxx/cdc/static_db/VCS/global_assert.sdb
$VC_STATIC_HOME/auxx/cdc/static_db/VCS/init.sdb
And the run_rules.f file contains the following:
+incdir+ <current_directory absolute path>/vcst_rtdb/
assertions/VCS/rules/
<absolute path of current directory>/vcst_rtdb/assertions/
VCS/rules/hybrid_rules_prop_top_bind.sv
<absolute path to current directory >/vcst_rtdb/assertions/
VCS/rules/hybrid_rules_prop_top_vcs.sv
-v $VC_STATIC_HOME/auxx/cdc/static_db/VCS/
rules_prop_definitions.sdb
If no assertions are generated in the rules or the assumptions directory,
please make sure relevant rule configurations are correct. The check_cdc
and check_rdc Tcl commands should be run before invoking
write_cdc_property and write_rdc_property.
The following shows an example TCL file for generating assertions:

647
Feedback Synopsys, Inc.
Hybrid Flow

Generating SVAs for Simulation

set_app_var enable_cdc true


read_file -format sverilog -top top test.v
read_sdc test.sdc

configure_cdc_glitch -multi_src_check_type all


configure_cdc_nff_sync -allow_combo_logic yes
configure_cdc_data_sync -sync_point mux_recirc

check_cdc
report_cdc
write_cdc_property -simulator all

648
Synopsys, Inc. Feedback
Hybrid Flow

Simulating SVAs

Simulating SVAs
You can use VCS to simulate the generated SVAs.

Running VCS
You can run VCS by using the single-step flow or the two-step flow.

Command Line for Single-Step Flow


Compilation
vcs -full64 -sverilog -assert svaext -debug_access+r -kdb
+vcs+fsdbon -o simv -lca -assert enable_diag\
-f source.f -f testbench.f \
-f ./vcst_rtdb/assertions/VCS/inc_common.f \
-f ./vcst_rtdb/assertions/VCS/run_rules.f \
-v $VC_STATIC_HOME/../../vgcommon/dynamic_cdc/rtl_lib/
macro_lib.v \
-v $VC_STATIC_HOME/../../vgcommon/dynamic_cdc/rtl_lib/
rtlc.prim.v \
Simulation
simv -assert summary

Need for macro_lib.v and rtlc.prim.v.


VC SpyGlass uses already defined RTL structures to model the SVA.
Therefore, VCS can also reuse the same RTL models and save resource
time. If the design does not contain external RTL models, you can omit the
above two files in the run command. If you do not specify those two files
and there are external RTL models, VCS shows the following XMRE errors
for RTL models:
“Error-[XMRE] Cross-module reference resolution error…”

649
Feedback Synopsys, Inc.
Hybrid Flow

Simulating SVAs

Command Line for Two-Step Flow


Compilation
vlogan -l source.log -kdb -work source -sverilog -full64 -f
source.f
vlogan -l tb.log -kdb -work tb -sverilog -full64 -f
testbench.f
vlogan -l assert.log -kdb -work assert -sverilog -full64 -f
assert.f
Elaboration
vcs -V -top <testbench top> \
-kdb Assertion_mod Assumption_mod Assertion_def
Assumption_def init \
-lca -debug_access+r\
-l vcs.log\
-timescale=1ns/1ns \
-assert svaext -assert enable_diag \
-full64

Simulation
simv -assert summary
In the two-step flow, you must specify the above highlighted additional top
modules because those top modules work as parallel tops in this
configuration. SVA bind file only binds the assertion files to the top
modules. If you do not specify additional tops, VCS will give XMRE errors
for "Assertion_mod".

650
Synopsys, Inc. Feedback
Hybrid Flow

Assertion Coverage

Assertion Coverage
You can generate assertion coverage details by specifying -assert
summary with simv command. Please note that -assert enable_diag
must be specified in compilation step. For example, simv -assert
summary.
Then, you can observe the following output in simv execution after
simulation concludes.

Now you can determine sva coverage and improve the testbench to get
more coverage if needed.

651
Feedback Synopsys, Inc.
Hybrid Flow

SVA Error Message in Simulation Output

SVA Error Message in Simulation Output


Whenever an assertion failure occurs, an error message will be printed on
simulation output. This assertion failure message contains valuable
information that user can traceback exact RTL code for further debug. For
example,
"/remote/vtgimages/SAFE/linux_RH6_EM64T_TD_mode64/monet/
Release/auxx/cdc/static_db/VCS/rules_prop_definitions.sdb",
67:
datahold_TB.dut.i_Assertion_mod_top.Datahold_0.ADVCDC_DATAHO
LD: started at 102s failed at 102s
Offending '<Protected>'
Error: "/remote/vtgimages/SAFE/linux_RH6_EM64T_TD_mode64/
monet/Release/auxx/cdc/static_db/VCS/
rules_prop_definitions.sdb", 67:
datahold_TB.dut.i_Assertion_mod_top.Datahold_0.ADVCDC_DATAHO
LD: at time 102
Datahold failure (test.v:38): Datahold failure
(Source:top.src.out, Destination:top.des.out)
(Data Hold violation: Data changed from 0 to 1 while
destination was active)
This message points out following information.
 Assertion module instance number
 Datahold_0
 Failure occurrence time
 Started at 102s failed at 102s
 Corresponding RTL line
 Datahold failure (test.v:38): Datahold failure
 Violation type
 (Data Hold violation: Data changed from 0 to 1 while destination was
active)
The following is another example of a set_case_analysis constraint failure.
“.../assumptions_definitions.sdb", 168:

652
Synopsys, Inc. Feedback
Hybrid Flow

SVA Error Message in Simulation Output

testbench.inst.i_Assumption_mod_test.Set_Case_Analysis_6.ADV
CDC_WRONG_VALUE: started at 1s failed at 1s
Offending 'ASSERT_SIG_VAL'
“../assumptions_definitions.sdb", 168:
testbench.inst.i_Assumption_mod_test.Set_Case_Analysis_6.ADV
CDC_WRONG_VALUE: at time 1
Set Case Analysis failure (test.sdc:14): Value 1 on signal
test.in1[6] does not match with the functional value
This message points out following information.
 Assertion module instance number
 Set_Case_Analysis_6
 Failure occurrence time
 started at 1s failed at 1s
 Corresponding RTL line
 Set Case Analysis failure (test.sdc:14):
 Violation type
 Value 1 on signal test.in1[6] does not match with the functional value

653
Feedback Synopsys, Inc.
Hybrid Flow

Debugging Using VERDI GUI

Debugging Using VERDI GUI


You can invoke Verdi Debug Tool after simulation execution and analyze
assertion failures. There are two ways to invoke Verdi.
4. Open fsdb file using Verdi after simv execution. To generate fsdb,
specify the following:
c. +vcs+fsdbon in compilation step
d. Default fsdb “novas.fsdb” will be generated
e. Please refer VCS user guide for fsdb customization commands.
5. Run simv using Verdi GUI
a. Set VERDI_HOME and then execute
 simv -gui &
b. To invoke Verdi in simulation step, user must specify -kdb option in
compilation stage
c. When Verdi database is created successfully, following string can be
observed
 Verdi KDB elaboration done and the database successfully
generated: 0 error(s), 0 warning(s)
d. Next, open Assertion Debug Mode
 Window->Assertion Debug Mode
 In assertion debug mode, you can analyze assertion in more
exhaustive ways.
 Please refer Verdi User Guide for Assertion Debug Mode

654
Synopsys, Inc. Feedback
Appendix A - Supported
Commands

This appendix briefly describes the SDC commands, Tcl commands,


configure commands and application variables supported by CDC:
 Application Variables
 Supported SDC Commands
 CDC Commands
 Configure Commands
 Database Commands
 Common Commands
 Command Sanity Checks

655
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

Application Variables

cdc_clock_race_thru_latch
Type:
bool

Default Value:
false

Description
This application variable has been deprecated. Use the
configure_cdc_integrity_checks command instead.

cdc_clockgate_enable_glitch
Type:
bool

Default Value:
true

Description
This application variable has been deprecated. Use the
configure_cdc_integrity_checks command instead.

cdc_disable_sam_glitchport_reporting
Type:
bool

656
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

Default Value:
false

Description
Enables reporting of multi-source glitch across SAM port in top-level SAM
run violations.
If a multi-source glitch violation is reported at block level because a valid
source is merging with a valid constrained port, the same glitch violation is
reported during top- level verification again if the signal is coming from the
same domain as the constrained block port and reaching the block port.
This is a noise for top-level user because the block-level user has already
waived/analyzed this glitch violation at the block level.
However if a combo exists at the top in fanin of block port which can cause
some delay and thereby creates a possibility of glitch again which the block
user might not know, that glitch violation should ideally be reported at the
top level. To reduce this noise at top-level, set this application variable to
true.

cdc_enable_merge_vector
Type:
string

Default Value:
maximal

Description
Enables vector merging of CDC crossings. When set to true, enables
merging of vector bits into vectors and combines crossings to produce
compact output. The application variable can take the following values:
 maximal: When set to maximal, all bits of a bus are merged to show a
single violation. In case of two-way bus merging, as in case of crossings,
for each crossing that needs to be merged, VC SpyGlass separately
merges the destination and source only if both the source and

657
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

destination of the crossing are part of the same bus and share the same
properties. For example, consider the following crossings:
Destination - Source
D[0] - S[0]
D[1] - S[0]
D[0] - S[1]
D[1] - S[1]
In this case, if the app var is set to maximal, the merged output would
be:
D[0:1] -S [0:1]
 compact: When set to compact, the criteria used to merge is similar as
in the case of maximal. However, in this case, the bus merging happens
on a combination of the source and the destination bus bits. In the
above example, the merged output would be:
D{ [0:1] , [0:1] } - S { [0], [1] }
Note that VC SpyGlass cannot consume such merged bus names as an
input to any VC SpyGlass command.
 separated: When set to separated, the criteria used to merge is similar
as in the case of compact. However, in this case, multiple violation are
reported separately for each group. In the above example, the merged
output would be:
D[0:1] - S[0]
D[0:1] - S[1]
 false: When set to false, no bus merging is performed.

cdc_enable_splitbus_mapping
Type:
bool

Default Value:
false

658
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

Description
When set to true, allows bit-blasted operation for CDC crossings specified
in the report_cdc command option. Default value is false.

cdc_include_constant_source_paths
Type:
bool

Default Value:
false

Description
When set to true, cdc paths with constant input at the source are treated
as cdc ignore path.

enable_cdc
Type:
string

Default Value:
false

Description
Enables the VC SpyGlass CDC flow and specifies the license tier.
This application variable can take either of the true, elite, apex, or false
values. Based on these values, tiered licenses are checked out.
When set to a value other than false, the following configurations and
application variables are used to enable the cdc flow.
 Application Variables
 set_app_var async_reset_nonseq_const_analysis true

659
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

 set_app_var case_analysis_propagate_through_icg true


 set_app_var case_analysis_sequential_propagation true
 Configurations
 configure_reset_propagation -propagate_through_reset_pin
true
 configure_read_tag -tag TCL_COMMAND_OPTION_VALUE_INVALID -
enable
 configure_read_tag -tag TCL_COMMAND_INVALID -enable
 configure_read_tag -tag TCL_COMMAND_CONFLICTING -enable
 configure_read_tag -tag TCL_PREREQUISITE_COMMAND_NOT_FOUND
-enable

enable_resetless_analysis
Type:
bool

Default Value:
false

Description
When set to true, enables detection of reset crossings even for
destinations to which no reset is propagating.

pt_compatibility_mode
Type:
bool

Default Value:
false

660
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

Description
Set this application variable to true to make VC SpyGlass compatible with
PrimeTime Suite. This variable enables the following implicit PT
configuration:
 set_app_var enable_new_name_interface false
 set_app_var cdc_include_constant_source_paths true
 set_app_var async_reset_nonseq_const_analysis false
 set_app_var case_analysis_sequential_propagation false
 set_app_var case_analysis_propagate_through_icg false
 set_app_var include_supply_in_get_nets false

enable_viapoint_for_violations
Type:
bool

Default Value:
false

Description
This variable enables generation of ViaPoints in the report_cdc -verbose
and report_cdc -format commands which can then be used to waive
violations by using the waive_cdc -through and by using ViaPoints in the
view_activity GUI.

enable_nested_hierarchy
Type:
bool

Default Value:
false

661
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

Description
This variable enables waiving at all levels of hierarchy for the waive_cdc -
from_module, -to_module, and -module options.

clock_source_sequential_propagation
Type:
bool

Default Value:
false

Description
This variable enables the propagation of clocks beyond sequential design
objects from clock pin, if the related output to clock pin of a sequential
element is further driving clock pin of any sequential. Default value is false.

cdc_enable_sam_port_reporting
Type:
bool

Default Value:
false

Description
This variable enables reporting of SAM port in top-SAM violations.

report_net_for_combo_and_simple_seq
Type:
bool

662
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

Default Value:
false

Description
This variable enables reporting net names for combo and simple sequential
db cell in CDC report.

cdc_enable_reason_for_unused_uds
Type:
bool

Default Value:
false

Description
This variable enables the SETUP_CDC_UDS_UNUSED and the
SETUP_ASYNCRST_UDS_UNUSED tags to report additional reason codes.
By default, the variable is set to false and the tags do not report any
reason codes.

cdc_hybrid_dataloss_clock_ratio
Type:
float

Default Value:
0.99

Description
This application variable specifies the ratio of source and destination clock
period for generating Dataloss property.

663
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

cdc_enable_sam_syncport_checks
Type
string

Default
false

Description
Set this application variable to true to report:
 SYNCCDC_DATAPATH_FULL violations, that are reported during block
analysis, as SYNCCDC_DATAPATH_SAM_SYNCPORT violations in the top
run.
 SYNCCDC_CTRLPATH_FULL violations, where both the synchronizer flop
and destination flop are in the same SAM abstract block, as
SYNCCDC_CTRLPATH_SAM_SYNCPORT violations.

enable_default_waiver_filter_fields
Type
bool

Default
false

Description
Set this application variable to true to activate the default tag fields in
the waiver filter template in the GUI. By default, this application variable is
set to false.
Once the application variable is set to true, its effect is persistent and
cannot be undone by setting the value to false. However, you can
subsequently modify the waiver filter fields by using the
configure_waiver_filter_field Tcl command.

664
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

Setting this application variable after using the configure_waiver_filter_field


command enables the default field even if they were previously disabled.

prefer_lib_or_rtl_model
Type
string

Default
exact_port_lib

Description
Use this application variable to specify the preferred source of a model
when the model is present in both RTL and library.
The application variable accepts the following values:
 lib: Set the application variable to this value to always prefer library
over RTL.
 rtl: Set the application variable to this value to always prefer RTL over
library.
 exact_port_lib: Set the application variable to this value to prefer
library over RTL when the library models have the exact port definition.
Else, prefer RTL.
 lib_if_function: Set the application variable to this value to prefer
library over RTL when the library models have at least one function
attribute defined. Else, prefer RTL.

cdc_enable_dataloss_multiple_sources
Type
bool

665
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

Default
no

Description
When there are crossings between multiple sources and a common
destination, only a single SVA dataloss assertion is generated for them by
default. Set this application variable to yes to enable the dataloss property
to generate assertions for all crossings separately.

cdc_sg_detailed_report
Type
string

Default
empty string

Description
Generates VC SpyGlass waivers for the Ac_sync01, Ac_sync02,
Ac_unsync01, and Ac_unsync02 rules from SpyGlass generated CDC-
detailed-report.rpt. Set the path of the application variable to the path
containing the SpyGlass generated CDC-detailed-report.rpt.

prefer_dw_over_rtl
Type
Bool

Default Value
false

Description
Configures VC SpyGlass to use DW pre-compiled libraries instead of RTL for

666
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Application Variables

elaboration.

cdc_enable_new_tags
Type
Bool

Default Value
false

Description
Set this application variable to true to enable new tag names in reports,
GUI and waivers. By default, the application variable is set to false.
Do not use this application variable in the SGUM flow. To enable the new
tag names in SGUM flow, specify it in the pre_check_tcl option of the
sg_read_project command.
NOTE: You need to specify the cdc_enable_new_tags application variable before specifying
the enable_cdc command.

cdc_enable_quasi_static_setup
Type
Bool

Default
false

Description
Generates assertions for the create_static constraint that can be controlled
using a user-specified qualifier signal. The specified qualifier signal is
considered as an input through the -rise_edge field. Therefore, it enables
quasi_static assertion (generated with respect to create_static constraint)
checking only when the signal specified in rise_edge is active-high.

667
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Application Variables

668
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Supported SDC Commands

Supported SDC Commands


 create_clock: This command specifies the defined clock sources in a
design.
 create_generated_clock: This command specifies the generated
clocks in the design.
 set_clock_sense [<object-list>] [-stop_propagation] [-
negative] [-positive] [-non_unate] [-pulse
<rise_triggered_high_pulse|fall_triggered_high_pulse|
rise_triggered_low_pulse|fall_triggered_low_pulse>] [-clocks
<clock-list>] [-clock_leaf]: This command stops the propagation
of specified clocks <clock-list> on <object-list> with the specified
polarity; positive, negative or non-unate. You can use either the
-stop_propagation arguments or the -clock_leaf argument to stop
the propagation of the clocks specified in the -clocks argument from
the pins specified in the object_list. It can be specified on any object
in the clock path. In case of multiple clocks on the same object, only
some clocks can be stopped using this command.
For example,
create_clock -name C1 [get_ports top/CLK1]
create_clock -name C2 [get_ports top/CLK1] -add
set_clock_sense G1 -clocks C1 -stop_propagation
 set_clock_groups: This command is used to specify clock
relationships.
 set_case_analysis: Propagate constants specified in
set_case_analysis during both forward and backward clock
propagation traversals.
 set_disable_timing -from <in-pin> -to <out-pin>: This command
is used to stop the propagation from an input specified in <-in-pin> to
an output specified in <out-pin>. All the traversals for clock setup
support set_disable_timing.
 set_mode: This command is used to specify the timing arcs for all the
library cells. This is required for all the traversals.
 set_input_delay: This command is used to associate an input port with
specific clock domain(s).

669
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Supported SDC Commands

 set_output_delay: This command is used to associate an output port


with specific clock domain(s).
 create_reset: Specify this command to define a reset in a design.

670
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

CDC Commands
This section describes the CDC Commands.

apply_attribute
Description
Specifies the pins to which the specified virtual nodes are applied.

Syntax
apply_attribute
<attribute name>
-objects {list of pins}
[-add]
[-direction {input|output}]
[-start]
[-end]

Arguments
 <attribute name>: Name of attribute element defined by
define_attribute.
 -objects {list of pins}: Pins to which given virtual nodes are
attached. Note that the get_* commands cannot be specified with this
argument. If the get_* commands are specified with the -objects
argument, VC SpyGlass CDC reports an error.
 [-add]: Specifies whether the attribute element specified by this
command will overwrite an already existing attribute.
 [-direction {input|output}]: Direction to which virtual node will be
applicable for inout ports.
 [-start]: Specifies that CDC attribute assumptions are considered for
the object's fan-in cone.

671
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-end]: Specifies that CDC attribute assumptions are considered for the
object's fan-out cone.

Example:
The following example shows some usages of apply_attribute command
set_constraints_scope -module top
define_attribute -name path1
set_clock_attribute path1 -clocks c1
apply_attribute path1 -objects {in1 in2}

define_attribute -name path2


set_clock_attribute path2 -clocks c2
apply_attribute path2 -objects {in1 in2} -add
end_constraints_scope

all_registers
Description
The all_registers command returns a collection of sequential cells or
pins in the current design, filtered as specified by the options. By default,
the command returns a collection of all sequential cells in the design. If you
specify clock_name, it considers only the sequential cells in the transitive
fanout of the sources of the clock.
You can use one or more of the -cells, -data_pins, -clock_pins, -
slave_clock_pins, and -output_pins options to return a collection
containing the respective types of objects. For example, if you use -
data_pins, the command returns a collection containing only the data pins
of the sequential cells that meet the search criteria. If you use both -cells
and -data_pins, the command returns a collection containing both the
sequential cells and their data pins.

Syntax
all_registers
[-name <clock_name>]
[-clock <clock_name>]

672
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

[-cells]
[-reset <reset-name>]
[-filter <filter-expr>]

Arguments
 [-clock <clock_name>]: Considers only sequential cells clocked by the
specified clock. By default, all sequential cells in the current design are
considered.
 [-cells]: Returns a collection of sequential cells that meet the search
criteria. If you do not specify any of the object type options, the
command returns a collection of sequential cells.
 [-reset <reset-name>]: Lists the sequential elements driven by the
specified reset.
 [-filter <filter-expr>]: Supports the is_a_flip_flop,
is_a_latch, and is_a_seq attributes.

Example:
all_registers -reset rst1 -filter is_a_flip_flop

check_cdc
Description
This command initiates the algorithms related to clock domain crossing
within the VSI. The prerequisite to this command is to read SDC (Synopsys
Design Constraints). This command identifies the clock domains based on
the constraints given in input SDC file. Consequent to inferring domains,
synchronizers are identified and checks related to clock domain crossing
are performed. All the information related to setup and CDC violations is
preserved in the database and can be reported using report_cdc or activity
browser in GUI.
By default, this command runs all checks related to synchronization as well
as structural checks related to re-convergence and divergence.

673
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
check_cdc
[-type setup|integ|sync|struct|formal|clock_prop| reset_prop]
[-j <thread_count>]

Arguments
 [-type setup|integ|sync|struct|formal|clock_prop|
reset_prop]: Use this option to specify the type of checks to be
performed. The -type argument takes the following values:
 setup: Performs setup checks only.
 integ: Performs setup and integrity checks.
 sync: Performs setup and synchronization checks.
 struct: Performs setup, synchronization, and structural checks.
 formal: Performs setup, synchronization, structural, and formal
checks.
 clock_prop: Performs clock propagation only.
 reset_prop: Performs reset propagation only.
 [-j <thread_count>]: Use this option to specify the number of
processes to be used for parallel analysis: Range: 4 to 32.
By default, VC SpyGlass CDC runs in 4 threads. You can modify the number
of threads by using the check_cdc -j <numthreads> in VCUM. For every
set of 4 threads, 1 license of VC_CDC_BASE is required.
For example, to run VC SpyGlass CDC in multi-threaded flow with 16
threads, use the check_cdc -j 16 command or the sg_read_project -j
16 command as per the use model. In this case, VC SpyGlass CDC requires
4 licenses of VC_CDC_BASE.

Examples
The following example shows some usages of check_cdc command.
check_cdc
check_cdc -type struct

674
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

create_cdc_abstract_model
Description
Creates in-memory CDC abstract model from block-level run.
NOTE: The create_cdc_abstract_model command generates a single
SAMCDC_INCOMPLETE_UNCONSTRAINED_PORTS violation for all unconstrained
ports.

Syntax
create_cdc_abstract_model
[-stage {list of stage names}]
[-gen_report]
[-j <num-threads>]
[-reference]

Arguments
 [-stage {list-of-stages}]: Specifies the stage for which the in-
memory CDC abstract model is created. Supported values are sync,
conv, and glitch. By default, the abstract model is created for all the
stages.
 [-gen_report]: Generates a text report for the abstract models.
 [-j <num-threads>]: Specifies the number of threads to be used for
multi-threaded abstract model generation for CDC. Valid range: 1 to 64.
 [-reference]: Generates reference SAM model to be used in the top-
level run for on-the-fly abstraction data generation of parameterized
models.

remove_redundant_logic
Description
Removes redundant logic to the specified sequential depth. Redundant
logic refers to the logic (such as crossings, setup violations, sync violations,
and so on) in blocked paths or paths terminating at hanging destinations.

675
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Issues reported by the violations in such paths does not propagate through
the design.

Syntax
remove_redundant_logic
-stage < seq_stage >
[-depth < seq_depth >]
[- enable_unobservable_crossings < true|false >]

Arguments
 -stage < seq_stage >: Specifies the stage for redundant logic
analysis. Valid inputs: none, setup, all.
 [-depth < seq_depth >]: Specifies the sequential depth for
redundant logic analysis. Default value is 0.
 [- enable_unobservable_crossings < true|false >]: Enables
reporting of crossings that have no observable path to a primary output.
Default value is false.

Example:
Consider the following schematic.

The following table describes the usage of the -depth argument of the

676
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

remove_redundant_logic command.
Command Description
remove_redundant_logic - Only u_IP3 is removed for crossing analysis.
depth 0 -stage all Crossing is reported by the
SYNCCDC_CTRLPATH_FULL tag with the
CDC_REDUNDANT_SYNCHRONIZER reason code
remove_redundant_logic - u_IP2 and u_IP3 are removed for crossing analysis.
depth 1 -stage all Crossing is reported as
CDC_REDUNDANT_SYNCHRONIZER reason code
of SYNCCDC_CTRLPATH_FULL
remove_redundant_logic - u_IP1, u_IP2, and u_IP3 are removed for crossing
depth 2 -stage all analysis. No Crossing is reported.

write_abstract_model
Description
Generates the abstract model.
The write_abstract_model command writes the
<design_top>_convergence_config.tcl file for the
configure_cdc_convergence -ignore_among_signal command and the
<design_top>_glitch_config.tcl file for the configure_cdc_glitch -
ignore_among_signals constraints used for block-level verification in the
<design_top>/.internal/constraints/ directory in SAM area.

Syntax
write_abstract_model
[-app < application name >]
[-format < format >]
[-path < dir name >]
[-user_mode < mode name >]
[-file <file_name>]
[-copy_kdb]

677
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 -app < application name >: Specifies the application which SAM flow
will be invoked. Applications that are supported are lp, cdc, rdc, and
lint. Must be used together with the -format option. If not specified,
binary SAM is written.
 -format < format >: Specifies the format. Supported formats are text
and binary. Must be used together with the -app option. If not specified,
binary SAM is written.
 -path: Specifies the location where the abstract model is generated.
 -user_mode: Specifies a mode name for abstraction. Use this argument
when different instances of same module receive different constraints
depending on the operating mode. In such cases, it is recommended
that you abstract the blocks with different constraint values for every
such mode. It is recommended that, for parameterized modules, you
generate the abstract model for every parameter combination used in
the design.
 -file <file_name>: Specifies the file where the verilog abstract model
is written.
 -copy_kdb: Specifies if the kdb should be copied to the abstraction
folder.

compress_cdc
Description
Use the compress_cdc command to report a representative violation for a
set of similar violations.

Syntax
compress_cdc
[-enable <cdc_sam_src_dest>]
[-disable]

678
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Arguments
 [-enable cdc_sam_src_dest ]: Groups the violations for each unique
SAM source and SAM destination pins.
 [-disable]: Use this option if you do not want VC SpyGlass CDC to
group the violations in any manner.

customize_cdc_abstract_model
Description
Customizes design abstraction in CDC flow

Syntax
customize_cdc_abstract_model
-from < pin_port_net_collection >
-to < pin_port_net_collection >
[-seq_depth < integer value >]

Arguments
 -from < pin_port_net_collection >: Specifies a list of pins, ports or
nets which are start points of paths required to be retained in
abstraction.
 -to < pin_port_net_collection >: Specifies a list of pins, ports or
nets which are end points of paths required to be retained in
abstraction.
 [-seq_depth < integer value >]: Specifies the maximum sequential
depth to be considered for retaining the paths between start and end
points. If no sequential depth is specified, then 0 sequential depth will
be considered.

Examples
To retain the path between FF1/Q and FF2/D with 0 sequential depth
customize_cdc_abstract_model -from { FF1/Q } -to { FF2/D }
To retain the path between FF1/Q and FF2/D with 2 sequential depth

679
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

customize_cdc_abstract_model -from { FF1/Q } -to { FF2/D } -


seq_depth 2

define_attribute
Description
The define_attribute command creates a virtual path object.
Note that the apply_attribute command is not allowed with the
define_attribute -objects command. In addition, the -add and
-direction arguments are allowed only if the -objects argument is
specified.

Syntax
define_attribute
-name <attribute_name>
[-objects <pins_or_ports>]
[-add]
[-direction <input/output>]

Arguments
 -name <attribute_name>: Specifies the logical name of the virtual path
object.
 [-objects <pins_or_ports>]: Specifies the design objects to which
the specified attribute is to be attached.
 [-add]: Adds the specified attribute to the specified design objects. If
the -add argument is not specified, the define_attribute command
overrides the existing attributes (if any) on the design object(s).
 [-direction <input/output>]: Specifies the direction of the inout
port/pin for which this attribute is applicable.

Examples
The following example shows some usages of define_attribute
command.

680
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Example 1:
Defining the top-level scope
define_attribute -name A1 -objects {TOP_P1 TOP_P2}
set_clock_attribute A1 -clocks TOP_C1
Example 2:
Specifying the scope by using set_constraints_scope
set_constraints_scope -module MOD
define_attribute -name A2 -objects {P1 P2}
set_clock_attribute A2 -clocks C2 -combo yes
set_sync_attribute A2 -sync active -from C1 -to C2
define_attribute -name A3 -objects {P11 P12}
set_connectivity_attribute A3 -path_type combo -related_ports
IN1
end_constraints_scope

get_blocking_report
Description
The get_blocking_report command retrieves the collection of sequentials
pins/ports that blocks the meta-stability from given sequential pin/port and
reset.

Syntax
get_blocking_report
-source <pin | port | Qpin>
-reset <reset>

Arguments
 -source <pin | port | Qpin>: Sequential object.
 -reset <reset>: Reset associated with object specified in source.

681
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Example:
get_blocking_report -source seq/Q -reset rst

get_cdc_coherency
Description
Returns an empty string or a collection of coherency issues in case of
successful execution based on provided arguments. The empty string is
returned if nothing matched the filtering criterion. In case of unsuccessful
execution an error is returned.

Syntax
get_cdc_coherency
[-from <from_pattern>]
[-to <to_pattern>]
[-from_clock <from_clock_name>]
[-to_clock <to_clock_name>]
[-convergence_point <convergence_point>]
[-of_object <collection>]
[-filter <filter_expression>]

Arguments
 [-from <from_pattern>]: Specify the list of net name, pin name or
port name of crossings source object.
 [-to <to_pattern>]: Specify the list of net name, pin name or port
name of crossing destination object.
 [-from_clock <from_clock_name>]: Specifies source clock name.
Source clock is the clock of crossing’s source.
 [-to_clock <to_clock_name>]: Specifies destination clock name.
Destination clock is the clock of crossing’s destination.

682
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-convergence_point <convergence_point>]: Specifies convergence


point name. Design coherency issues of these objects only will be
returned.
 [-of_object <collection>]: Specifies collection of convergence
source/destination/synchronizer-output objects. Design coherency
issues of these objects only will be returned.
 [-filter <filter_expression>]: Filters the violations based on filter
expression.

Examples
prompt> get_cdc_coherency -from_clock clk1 -to_clock clk2
prompt> get_cdc_coherency -from [get_ports I1/in1] -to
[get_ports I1/out1]
prompt> foreach_in_collection it [get_cdc_coherency -of_object
S1/q/Q] {
set pt2 [get_attribute $it -class cdc_coherency name]
puts $fp "$pt2"}

get_cdc_coherency_elements
Description
The get_cdc_coherency_elements command returns the different elements
in the specific CDC coherency based on the specified arguments.

Syntax
get_cdc_coherency_elements
[-convergence_point <convergence_point>]
[-convergence_depth <integer>]
[-diverging_net <diverging_net>]
[-diverging_net_depth <integer>]
[-common_sources <common_sources>]
[-of_object <collection>]
-cdc_coherency <cdc_coherency>

683
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 [-convergence_point <convergence_point>]: Returns the
convergence point of the specified CDC coherency.
 [-convergence_depth <integer>]: Returns the convergence depth
from synchronizer to convergence_point of the specified CDC coherency.
Applicable only when get_cdc_coherency and get_cdc_synchronizers
are given.)
 [-diverging_net <diverging_net>]: Returns the design object where
divergence happens before reaching source of the specified CDC
coherency. This is applicable only if the get_cdc_coherency and
get_cdc_synchronizers arguments are specified.
 [-diverging_net_depth <integer>]: Returns the divergence depth
from diverging point to source of the specified CDC coherency. This is
applicable only if the get_cdc_coherency and get_cdc_synchronizers
arguments are specified.
 [-common_sources <common_sources>]: Returns common sources of
the specified CDC coherency.
 [-of_object <collection>]: Specify the synchronizer to get
convergence_point/convergence_depth/diverging_net/
diverging_net_depth and so on.
 -cdc_coherency <cdc_coherency>: Specify the CDC coherency.

Examples
prompt> set conv_paths [get_cdc_coherency]
prompt> foreach_in_collection conv_path $conv_paths {
set syncs [get_cdc_control_synchronizers -of_object $conv_path]
foreach_in_collection sync_path $syncs {
set div_net [get_cdc_coherency_elements $conv_path -of_object
$sync_path -diverging_net]
set div_net_depth [get_cdc_coherency_elements $conv_path -
of_object $sync_path -diverging_net_depth]
set convPt [get_cdc_coherency_elements $conv_path -
convergence_point]
set convPtDepth [get_cdc_coherency_elements $conv_path -
of_object $sync_path -convergence_depth]

684
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

get_clock_domains
Description
Returns all specific clock domains

Syntax
get_clock_domains
[-include_derived]
[-id <clock_domain_id>]
[-filter <filterexp>]
[-of_objects <obj_list>]

Arguments
 [-include_derived]: Returns the clock domains created on internal
object during CDC checks.
 [-id <clock_domain_id>]: Returns clock domain object corresponding
to this ID.
 [-of_objects <obj_list>]: Valid objects include clock, clock_root,
cell, pin, net, and port.
 [-filter <filterexp>]: Filters the objects whose name matches the
specified expression.

Examples
To get all the clock domains for user specified clocks, use the following
command:
get_clock_domains
To get all the clock domains including the derived domain created during
CDC checks, use the following command:
get_clock_domains -include_derived
To get the clock domain for a specific id, use the following command:
get_clock_domains -id 2
To get clock domain for a specific clock, use the following command:

685
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

get_clock_domains -of_objects [ get_clocks C1 ]

get_clock_roots
Description
Returns all specific clock roots.

Syntax
get_clock_roots
[-user_roots]
[-filter <filter_expression>]
[-of_objects <obj_list>]

Arguments
 [-user_roots]: Specify this option to see user clock roots at any
object.
 [-filter <filter_expression>]: Filter the clock roots using the
attributes mentioned in next section.
 [-of_objects <obj_list>]: Object list clock_domain, clock, pin, and
port.

Examples
To get list of all clock roots, use the following command:
get_clock_roots
To get clock root for a specific clock, use the following command:
get_clock_root -of_objects [ get_clocks C1]
To get clock root on a specific pin, use the following command:
get_clock_roots -of_objects [ get_pins inst/P1 ]
To get user clock root on a specific pin, use the following command:
get_clock_roots -of_objects [ get_pins inst/P1 ] -user_roots

686
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

get_reset_roots
Description
This command reports all specific reset roots.

Syntax
get_reset_roots
[-include_derived]
[-filter <filter attribute>]
[-of_objects <pin|port|etc>]

Arguments
 [-include_derived]: Returns all roots, including derived reset sources.
 [-filter <filter attribute>]: Filter the reset roots using the
attributes.
 [-of_objects <pin|port|etc>]: Object list to check [reset, pin, port,
net].

Examples
To report reset sources in the design
get_reset_roots
To report reset source of given design object RST
get_reset_roots -of_objects RST

get_cdc_cluster_cause_viols
Description
Gets a collection of unique cause violation ids in the specified cluster(s). If
no cluster id is specified, all clusters are considered. Returned collection is
sorted based on the debug priority ranking.

687
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
get_cdc_cluster_cause_viols
[-cluster_id {list of violation ID}]

Arguments
 [-cluster_id {list of violation ID}]: Specifies the list of cluster
violation IDs.

Examples
The following command returns all cause violation IDs present in the
specified cluster id:
get_cdc_cluster_cause_viols -cluster_id 15

get_cdc_cluster_effect_viols
Description
Gets a collection of unique effect violation ids in the specified luster(s). If
cause id is specified, then effect violation IDs for the specified causes are
returned. If neither of these are specified, then all clusters are considered.
The returned collection is sorted based on the SHA1 key of the effect
violations.

Syntax
get_cdc_cluster_effect_viols
[-cluster_id {list of ids}]
[-cause_id {list of ids}]

Arguments
 [-cluster_id {list of ids}]: Specifies the list of cluster violation ID.
 [-cause_id {list of ids}]: Specifies the list of cause violation ID.

Examples
The following command returns all effect violation ids of all clusters:

688
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

get_cdc_cluster_effect_viols -cluster_id
[get_cdc_cluster_viols]

get_cdc_cluster_viols
Description
Gets a cluster violation IDs in cluster rank order. If cluster rank is specified,
the cluster violation id for that particular cluster is returned. If cause
violation id is specified, the id of clusters containing this cause violation is
returned. If neither of it is specified, all cluster ids are returned in order of
their rank.

Syntax
get_cdc_cluster_viols
[-rank value]
[-cause_id value]

Arguments
 [-rank value]: Specifies the rank of a particular cluster violation.
 [-cause_id value]: Specifies the cause violation ID.

Examples
The following command returns all cluster violation ids in order of its rank:
get_cdc_cluster_viols

get_synchronizer_cells
Description
This command reports a list of valid synchronizer cells that are specified by
using the configure_cdc_nff_sync -allowed_modules or the
configure_cdc_asyncrst_nff_sync -allowed_modules commands.

689
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
get_synchronizer_cells
[-type <cdc/reset>]
[-hier]

Arguments
 [-type <cdc/reset>]: Specify the type of synchronizers to be reported
( { cdc } / { reset } / { cdc reset }. Default: cdc
 [-hier]: If specified, hierarchical instances, along with the user
provided instances are reported

map_point_info
Description
Provide mapping between RTL signal and equivalent Netlist signal

Syntax
map_point_info
[-map_rtl]
[-map_gate]

Arguments
 [-map_rtl]: RTL signal name
 [-map_gate]: Equivalent Netlist signal name

Examples
To set the mapping between RtlNet1 in RTL design and GatePin1 in Netlist
design
map_point_info -map_rtl RtlNet1 -map_gate GatePin1

report_cdc

690
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Description
After performing CDC checks, use this command to print any violations
identified and stored in the report database.

Syntax
report_cdc
[<cdc_paths>]
[-no_summary]
[-list]
[-verbose]
[-limit count]
[-include_waived]
[-include_compressed]
[-only_waived]
[-tag {list of tags}]
[-waived {list of waivers}]
[-id {list | range of message IDs}]
[-family {list of fammily names}]
[-stage {list of stage names}]
[-severity {list of severities}]
[-filter expression]
[-regexp]
[-file file_name]
[-append]
[-cluster_viols_only]
[-include_cause_viols]
[-format]
[-separator]
[-default]
[-show_bit_level_viol]

691
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

[-id_list]
[-compressions]
[-ignore_viol_state { list of violation states }]
[-hide_id]
[-dir dir_name]
[-report { report list } ]
[-viol_state { list of violation states } ]
[-nocase]
[-hide_group_violations]
[-tag_format]
[-display_compressed]
[-family {list of family names}]

Arguments
 [<cdc_paths>]: Collection of CDC paths can be given using this option
for generating report.
 [-no_summary]: Two summary tables, Management and Tree Summary
are printed by default. This option suppresses printing of these tables.
These tables list number of violations in each family and stage.
 [-list]: In addition to the summary tables, print a one sentence
description of each violation with the design data fields filled in. Useful
for generating a file with one line per violation.
 [-verbose]: In addition to the summary tables, print a number of lines
of detail about each violation. This verbose format includes the
description, basic design detail fields for the violation, and also detailed
debugging fields for the violation. Useful for getting all details of the
violation.
 [-limit count]: By default, only 100 violations are printed, when used
with list or verbose mode. Mention <count> to print only this many
number of violations for each tag. Useful to limit the file size for designs
with a large violation count. With count = 0 (-limit 0), all the violations
can be printed.

692
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-include_waived]: By default, any violation which is waived is not


included in the report. Use this switch to include the waived messages in
the report.
 [-include_compressed]: By default, any violation which is compressed
is not included in the report. Use this switch to include the compressed
messages in the report.
 [-only_waived]: By default, any violation which is waived is not
included in the report. Use this switch to include only waived messages
in the report.
 [-tag {list of tags}]: To focus on only certain tags, use this switch
with a list of tag names. Only violations whose tag is on this list will be
displayed.
 [-waived {list of waivers}]: To focus on only certain waivers, use
this switch with a list of waiver names. Only violations which are waived
by a waiver name on this list will be displayed.
 [-id { list | range of message IDs}]: To focus on only one
message, a short list of messages, or a range of messages, use this
switch with a message identifier such as report_cdc -id {CDC:123}, list
of identifiers such as report_cdc -id {CDC:123 CDC:321} or a range of
identifiers such as report_cdc -id {1-2 3-43} respectively. Only these
violations will be displayed.
 [-family {list of family names}]: To focus on only messages from
certain families, use this switch with a list of families. The valid families
are: SDC, CLKPROP, CONFIG, UNSYNC, NFF, PULSE, DMUX, LOGIC,
HANDSHAKE, FIFO, DIVERGE, CONV, RESET, ISOEN, HIERCDC
 [-stage {list of stage names}]: To focus on only messages at
certain design stages, use this switch with a list of stages. The valid
stages are SETUP, SYNC, STRUCT and LPCDC.
 [-severity {list of severities}]: To focus on only messages with
a certain severity, use this switch with a list of severities. The valid
severities are: all, error, info, warning.
 [-filter expression]: This switch allows you to specify complex
criteria based on pattern matching. Only violations matching the filter
expression will be shown. An expression may contain several terms
separated with a double ampersand. Each term has a field name, a
comparison operator, and a target string. The field name may be any
field name shown in the verbose report; for a field inside a record, use a

693
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

colon to separate the record path components. The comparison operator


is any of the standard operators such as == , !=, =~. See the examples
section for several examples.
 [-regexp]: Use this switch to indicate that the filter expression type is a
regular expression. The default is glob-style.
 [-file file_name]: Write the results to the designated file.
 [-append]: Append results to the designated file.
 [-cluster_viols_only]: Violations belonging to cluster will be
reported.
 [-include_cause_viols]: Include cause violation(s) in report.
 [-format]: Report will be dumped with this format. This option can be
used along with -list and -tag option only.
 [-separator]: Multiple field values will be dumped using this separator.
 [-default]: Collection of CDC paths can be given using this option for
generating report.
 [-show_bit_level_viol]: Insert bit level violations corresponding to
bus merged violations and dump newly added bit level violations in
report.
 [-id_list]: Sets Matching violation id's as command result.
 [-compressions]: Specify this option to include all violations in the
same compression set(s).
 [-ignore_viol_state {list of violation states }]: Ignores
violation state(s) in report. Possible states are Acknowledged,
NeedsInfo, Open, Waived, Waived_Temp, and Ignore.
 [-ignore_viol_state { list of violation states }]:
 [-hide_id]: Violation ID will be hidden in verbose report.
 [-dir dir_name]: Write the results to the designated dir.
 [-report { report list } ]: List all messages in specified reports.
Possible reports are ac_sync_qualifier, SynchInfo.
 [-viol_state { list of violation states } ]: Shows violations for
given states. Possible states are Acknowledged, NeedsInfo, Open,
Waived, Waived_Temp, and Ignore.

694
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-nocase]: Use this switch to indicate that case will be ignored while
matching string values.
 [-hide_group_violations]: Use this option to show one violation per
group and hide rest of the grouped violations in detailed report.
 [-tag_format]: Use this option to generate report using tag-specific
format. Tag wise custom report format can be get/set by the
get_tag_attribute /set_tag_attribute commands.
 [-display_compressed]: Generate report corresponding to given
compression.
 [-family {list of family names}]: Use this argument to focus on
only messages from certain families. The valid families are: SDC,
CLKPROP, CONFIG, UNSYNC, NFF, PULSE, DMUX, LOGIC, HANDSHAKE,
FIFO, DIVERGE, CONV, RESET, ISOEN, and HIERCDC.

Examples
 The following command generates a verbose listing of all the violations
to a file report_cdc.txt. The number of violations reported for each Tag
is restricted to 100 only.
report_cdc -verbose -file report_cdc.txt
 The following command generates a listing of all the violations where
the SrcClk root pin is clk1;
report_cdc -filter SrcClk:ClkRoot==clk1
 The following command generates a listing of all the violations where
the SrcClk root pin is clk1 and SrcObject of the Crossing is not from
register r1's Q pin.
report_cdc -filter (SrcClk:ClkRoot==clk1)&&(SrcObject!=r1/Q)
 The following command generates report using user given format.
report_cdc -list -tag SYNCCDC_UNSYNC_NOSCHEME -format "Path
from %SrcObject% to %DestObject%, Clock From
%SrcClockInfoList% To %DestClockInfoList% " -limit 1
 The following command generates a report using user given format and
multiple field values are dumped using separator.
report_cdc -format "Reasons %ReasonInfoList%" -list -tag
ASYNCRST_CTRLPATH_PARTIAL -separator ","

695
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 The following command generates verbose report and the default format
is based on the unique fields set by the application.
report_cdc -tag_format
The above command generates the following:
Tag "SYNCCDC_CTRLPATH_FULL",
{(ReasonInfoList:ReasonInfo:ReasonCode == "SYNC_BY_NFF") AND
(SrcObject == "a_syncInfo2/b_src/out/Q[0]") AND (DestObject
== "a_syncInfo2/dest/out/Q[0]") AND
(SrcClockInfoList:SrcClockInfo:ClockName == "c1") AND
(DestClockInfoList:DestClockInfo:ClockName == "c3")}
 You can get tag specific format by using the following command:
get_tag_attribute <tag> report_format
The above command generates the following:
get_tag_attribute SYNCCDC_CTRLPATH_FULL report_format
{Tag "%Tag%", {(ReasonInfoList:ReasonInfo:ReasonCode ==
"%ReasonInfoList:ReasonInfo:ReasonCode%") AND (SrcObject ==
"%SrcObject%") AND (DestObject == "%DestObject%") AND
(SrcClockInfoList:SrcClockInfo:ClockName ==
"%SrcClockInfoList:SrcClockInfo:ClockName%") AND
(DestClockInfoList:DestClockInfo:ClockName ==
"%DestClockInfoList:DestClockInfo:ClockName%")}}
 You can get tag specific format by using the following command:
set_tag_attribute <tag> report_format <new format>
 You can add syncObject to CDC_SYNC_CTRLPATH, to existing
get_tag_attribute as follows:
set_tag_attribute SYNCCDC_CTRLPATH_FULL report_format {Tag
"%Tag%", {(ReasonInfoList:ReasonInfo:ReasonCode ==
"%ReasonInfoList:ReasonInfo:ReasonCode%") AND (SrcObject ==
"%SrcObject%") AND (DestObject == "%DestObject%") AND
(SyncObject == "%SyncObject%") AND
(SrcClockInfoList:SrcClockInfo:ClockName ==
"%SrcClockInfoList:SrcClockInfo:ClockName%") AND
(DestClockInfoList:DestClockInfo:ClockName ==
"%DestClockInfoList:DestClockInfo:ClockName%")}}

696
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 You can generate the SynchInfo.rpt report by using the following


command:
report_cdc -report SynchInfo [-dir <directory path where to
generate the report>]

report_reset_control_signals
Description
Reports each control signal that appears on the reset path. Report is
generated in csv format that includes the following four columns:
 ConvergenceType: Type of node on which the control signal and reset
path are merging.
 ConvergenceNode: Name of the merging node.
 ControlSignals: Signals that enable the reset.
 UserRsts: User resets reaching the convergenceNode.

Syntax
report_reset_control_signals
[-seq_pin <reset-pin>]
-file <file-name>

Arguments
 [-seq_pin <reset-pin>]: Reset pin of sequential for which control
signals need to be dumped
 -file <file-name>: Write results to the designated file

Example:
The seq_pin is an optional argument which you may or may not specify. If
you specify the seq_pin argument, it discards control signals for the given
reset pin in seq_pin option in the report_clock_control_signals
command. Else, it discards the control signals related to reset pins of all
the sequential.
report_reset_control_signals -file "resetControls.csv"

697
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

sh cat resetControls.csv

ConvergenceType,ConvergenceNode,ControlSignals,UserRsts
AND,rstand,rsten2,rst2
MUX,rstmux,rsten2:rsten3,rst1:rst2

report_clock_control_signals
Description
Reports each control signal that appears on the clock path. Report is
generated in csv format that includes the following four columns:
 ConvergenceType: Type of node on which the control signal and clock
path are merging.
 ConvergenceNode: Name of the merging node.
 ControlSignals: Signals that enable the clock.
 UserRsts: User clocks reaching the convergenceNode.

Syntax
report_clock_control_signals
[-seq_pin <clock-pin>]
-file <file-name>

Arguments
 [-seq_pin <clock-pin>]: Clock pin of sequential for which control
signals need to be dumped
 -file <file-name>: Write results to the designated file

Example:
The seq_pin is an optional argument which you may or may not specify. If
you specify the seq_pin argument, it discards control signals for the given
clock pin in seq_pin option in the report_clock_control_signals
command. Else, it discards the control signals related to clock pins of all

698
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

the sequential.
report_clock_control_signals -file "clockControls.csv"
sh cat clockControls.csv

ConvergenceType,ConvergenceNode,ControlSignals,UserClks
OR,clkor,clken2,clk2
MUX,clkmux,clken3ff/Q,clk1:clk2
CGC,clkg,clken1,clk1

set_allowed_cells
Description
Specifies cells that can be allowed or disallowed in clock or reset networks.

Syntax
set_allowed_cells
[-name]
[-disallow]
[-type]
[-from]

Arguments
 [-name]: Specifies allowed/disallowed cell names list. This is a
mandatory option for the set_allowed_cells command.
 [-disallow]: Indicates that the cells specified with the ? character
argument should be disallowed. By default, the specified cells are the
only cells allowed in the network. If the -disallow argument is specified,
these cells are the only cells NOT allowed in the network.
 [-type]: Specifies whether only clock, reset, or both trees should be
checked

699
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-from]: Specifies list of names of nets from which the check should
start

Examples
If both -type and -from arguments are not specified, the entire design is
checked for allowed/disallowed cells. Therefore, for the following
command, the tag reports instances of A1234 found in the entire design:
set_allowed_cells -name A1234 -disallow
To report instances of A1234 found in the fan-out tree of the w1 net, use the
following command:
set_allowed_cells -name A1234 -from w1 -disallow
To report instances of cells other than A1234 found in the clock tree of the
design, use the following command:
set_allowed_cells -name A1234 -type clock

set_asyncrst_ignore_path
Description
Specified path(s) will be ignored for async reset analysis.

Syntax
set_asyncrst_ignore_path
[-from <pin|port|Qpin list>]
[-to <pin|port|Qpin list>]
[-from_clock <from_clk_list>]
[-to_clock <to_clk_list>]
[-from_reset <pin|port|Qpin>]
[-through < pin|module list>]

Arguments
 [-from <pin|port|Qpin list>]: Specify pin or port or Qpin of a
sequential object, from where the Async Reset path is to be ignored.

700
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

pin|port can be given with get_pins or get_ports commands which


return the list of objects.
 [-to <pin|port|Qpin list>]: Specify pin or port or Qpin of a
sequential object, to which the Async Reset path is to be ignored.
pin|port|Qpin can be given with get_pins or get_ports commands which
return the list of objects.
 [-from_clock <from_clk_list>]: Specifies a list of clock objects from
which Async Reset paths need to be ignored.
 [-to_clock <to_clk_list>]: Specifies a list of destination clock
registers for which Async Reset paths need to be ignored
 [-from_reset < pin|port|Qpin>]: Specifies a list of reset objects
from which Async Reset paths need to be ignored.
 [-through < pin|module list>]: Specifies the pin throgh which the
crossover is passing between start and end points. You can specify
multiple through pins. The crossover must pass through the specified
sequence of through pins to be ignored.

Examples
To ignore path from Qpins of a register
set_asyncrst_ignore_path -from [get_pins usb3_noclkrst/
usb3_pwrm/usb3_pwrm_csr/gctl_reg/Q*]
To ignore from a register Qpin to destination pin
set_asyncrst_ignore_path -from [get_pins usb3_clk/host_mode_r/
Q*] -to [get_pins usb3_clk/usb3_sync_ctl_mac_mac3/in_p_1d/Q*]

set_asyncrst_synchronizer
Description
Specifies reset path synchronizer cell in design.

Syntax
set_asyncrst_synchronizer
[-cell <black-boxes | lib-cells >]
[-name <pin | port | net >]

701
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

[-reset < reset-name | reset-object>]


[-clock <clock-name | clock-object >]
[-ignore]

Arguments
 [-cell <black-boxes | lib-cells >]: Specifies lib-cells/black-boxes
objects in the design object that are to be used as reset synchronizers
for reset path checks.
 [-name <pin | port | net >]: Specifies the signal name which is to
be used as reset synchronizer for reset path from the specified reset to
the specified clock.
 [-reset < reset-name | reset-object>]: Specifies the reset for
which specified reset synchronizer is to be used.
 [-clock <clock-name | clock-object >]: Specifies the clock to
which specified reset synchronizer is to be used.
 [-ignore]: If specified, the auto-inferred synchronizer at the specified
name will not be used for any reset path.

set_cdc_convergence_ports
Description
Specifies the input ports of an abstract block which are converging
inside the block..

Syntax
set_cdc_convergence_ports
-ports <converging_ports>

Arguments
 [-ports <converging_ports>: Specifies the input ports of an abstract
block which are converging inside the block

702
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Examples
The following example shows the usages of the
set_cdc_convergence_ports command:
set_cdc_convergence_ports -ports { in1 in2 }

set_clock_relation
Description
Specifies two synchronous points in path of asynchronous clock(s) pair,
which forms crossing.

Syntax
set_clock_relation
[-from_clock Clock-Name|net|pin|port ]
[-to_clock Clock-Name|net|pin|port|]
[-ref_clk net|pin|port]
[-phase val]

Arguments
 [-from_clock Clock-Name|net|pin|port ]: Specifies source clock
name, or a space separated list of points in path of clock reaching to
source of crossing.
 [-to_clock Clock-Name|net|pin|port|]: Specifies destination clock
name, or a space separated list of points in path of clock reaching to
destination of crossing.
 [-ref_clk net|pin|port]: Specifies reference clock name.
 [-phase val]: Specifies destination object list

Examples
To specify a clock relation in inverted phase
set_clock_relation -from_clock clk1 -to_clock clk2 -phase
noninv

703
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

set_connectivity_attribute
Description
Specifies the type of connections between the pins of the blackbox
instance.

Syntax
set_connectivity_attributes
- <attribute name>
-path_type <combo|buf|inv>
-related_ports {list of input pins}
-single_non_quasi

Arguments
 - <attribute name>: Name of attribute element defined by
define_attribute.
 -path_type <combo|buf|inv>: Specifies if the connectivity is
combinational, buffer, inverter in nature.
 -related_ports {list of input pins}: Specifies input pins
connected to the objects specified by "-objects" of apply_attribute
command.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -related_ports
argument, VC SpyGlass CDC reports an error.
 -single_non_quasi: Specifies if a single non-quasi source is reaching
the output port through a combinational logic.

Examples
The following example shows some usages of set_connectivity_attribute
command
set_constraints_scope -instance I1
define_attribute -name path1
set_connectivity_attribute path1 -path_type combo
-related_ports {in1}

704
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

apply_attribute path1 -objects {out1}

set_reset_attribute
Description
Specifies the resets which drive the given virtual node.

Syntax
set_reset_attribute
- <attribute name>
[-resets {reset names}]
[-reset_objects {pin names}]
[-combo]
[-add]

Arguments
 - <attribute name>: Name of attribute element defined by
define_attribute.
 [-resets {reset names}]: Names of resets which is driving the path
element.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -resets argument, VC
SpyGlass CDC reports an error.
 [-reset_objects {pin names}]: Related reset pins (should exist) of
the current module to which resets reach or on which resets are defined.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -reset_objects
argument, VC SpyGlass CDC reports an error.
 [-combo]: Defines a combo logic before the virtual sequential.
 [-add]: If add is not given for the attribute, it will replace the existing
reset/reset_objects, if any.

705
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Examples
The following example shows some usages of set_reset_attribute
command
set_constraints_scope -module top
define_attribute -name path1
set_reset_attribute path1 -resets c1
set_constraints_scope -module top
define_attribute -name path1
set_reset_attribute path1 -reset_objects clk1

waive_cdc
Description
Provides ability to waived based on Tags, Family, Severity, Filter rules using
debug fields, Wildcards and expressions and add comment for waivers as
well.
Note: Use the waive_cdc command before the report_cdc command

Syntax
waive_cdc
[-add waiver_name]
[-append waiver_name]
[-comment {comment_string}]
[-delete waiver_name(s)]
[-delete_all]
[-tcl]
[-tag tag_name]
[-id ID]
[-stage stage_value]
[-family family_value]
[-severity value]

706
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

[-filter expression]
[-regexp]
[-from]
[-to]
[-through]
[-from_clock]
[-to_clock]
[-from_module]
[-to_module]
[-module]
[-hierarchy]
[-same_hier]
[-exact_match { list of qualified field names }]
[-nocase]
[-ip ip_module_name(s)/ip_instance_name(s)]
[-preview]
[-violations <vDescType>]
[-violation_limit <count>]
[-verbose]
[-not_applied]
[-ignore]
[-include_master_viol]
[-include_compressed_viol]
[-include_grouped_viol]
[-msg <violation message>]
[-posix_regex]

Arguments
 [-add waiver_name]: Add waiver. waiver_name is any user defined
string.

707
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-append waiver_name]: Append additional filter parameters to an


existing waiver, named as waiver_name
 [-comment {comment_string}]: Add a comment to the waiver,
explaining the nature or some info of the waiver
 [-delete waiver_name(s)]: Delete waiver(s) specified by the name(s)
 [-delete_all]: Delete all waivers, defined
 [-tcl]: Display the waiver list in TCL command format
 [-tag tag_name]: Waive violations based on tag
 [-id ID]: Waive violations based on IDs
 [-stage stage_value]: Waive violations based on stage: Values: all,
SETUP, SYNC, STRUCT and LPCDC
 [-family family_value]: Waive violations based on family: Values:
all, SDC, CLKPROP, CONFIG, UNSYNC, NFF, PULSE, DMUX, LOGIC,
HANDSHAKE, FIFO, DIVERGE, CONV, RESET, ISOEN, HIERCDC
 [-severity value]: Waive violations based on severity: Values: all,
error, info, warning
 [-filter expression]: Waive violations based on expression
 [-regexp]: Use this switch to indicate that the filter expression type is a
regular expression. The default is glob-style.
 [-from]: Waive violations based on source points
 [-to]: Waive violations based on destination points.
 [-through]: Waive violations based on via-points. Set the
enable_viapoint_for_violations application variable to true to
generate the via-points.
 [-from_clock]: Waive violations based on source clock.
 [-to_clock]: Waive violations based on destination clock.
 [-from_module]: Waive violations based on the sources in this module.
By default, only the violations with the source at the top level are
waived. To waive all violations across the hierarchy, set the
enable_nested_hierarchy application variable to true.
 [-to_module]: Waive violations based on the destination in this
module. By default, only the violations with the destination at the top

708
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

level are waived. To waive all violations across the hierarchy, set the
enable_nested_hierarchy application variable to true.
 [-module]: Waive violations based on source and destination in this
module. By default, only the violations having source and destination at
the top level are waived. To waive all violations across the hierarchy, set
the enable_nested_hierarchy application variable to true or specify
the -hierarchy option with the waive command.
 [-hierarchy]: Waive violations based on the hierarchy of modules. Use
this option with a waiver to waive the violations across the hierarchy.
 [-same_hier]: Waive violations if hierarchy of all field are matching
with 1st field.
 [-exact_match { list of qualified field names }]: Waive
violation only if all values for given object Type matches with given
pattern.
 [-nocase]: Ignores case while matching string values.
 [-ip ip_module_name(s)/ip_instance_name(s)]: Waive violations
based on the module/instances inside which it lies.
 [-preview]: If this option set, waivers are not added into database and
the matching violation ids are set as command output.
 [-violations <vDescType>]: Appends the violation's description to
signature based/all waivers. Values: all, none, signature
 [-violation_limit <count>]: Limits violation description for each
waiver.
 [-verbose]: Prints detailed description of each violation. This verbose
format includes the description, basic design detail fields for the
violation, and also detailed debugging fields for the violation.
 [-not_applied]: Displays the waivers which do not apply.
 [-ignore]: Applies the waiver but does not show in waiver report.
 [-include_master_viol]: Marks the master violation if the
compressed violations are already marked.
 [-include_compressed_viol]: Marks the compressed violation if the
master violations are already marked.
 [-include_grouped_viol]: Marks the grouped violations if the
representative violation is marked.

709
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-msg <violation message>]: Waives violations based on the message


pattern. Message pattern is matched with violation message generated
using report_cdc -list.
 [-posix_regex]: Specify this option to enable POSIX regular
expression matching in waivers.

Examples
Waives all the tags that starts with SETUP. Waiver name: setup_tags and a
comment is added to explain why the waiver
waive_cdc -add setup_tags -tag SETUP* -comment {setup tags are
verified}
Waives all the tags in the STRUCTural checking stage
waive_cdc -add struct_checks -stage STRUCT
Waives on Tag ID No 333
waive_cdc -add id333 -id CDC:333
Waive Tags that are with the reason code NFF_META_FANOUT
waive_cdc -add nff_metafanout_waive -comment {all meta fanout
tags can be waived} -filter {ReasonCode == NFF_META_FANOUT}
Consider the following violation:
Tag : SYNCCDC_UNSYNC_NOSCHEME
Description : No synchronization
scheme found
between [SrcObject] to [DestObject], crossing from
[SrcClockInfoList]
to [DestClockInfoList]
Violation : CDC:224
ReasonInfoList
ReasonInfo
ReasonCode :
SRC_CONVERGES_ASYNC_SRC
ReasonCodeMsg : [ERROR] Source
converges with

710
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

another asynchronous source


SrcObject : u_ACUS/bin_count/
Q[0:1]
DestObject : u_ACUS/u_sync2s/
meta/Q
SrcClockInfoList
SrcClockInfo
ClockName : _AUTO_CLK_2_
ClockObject : clkA
ClockDomainId : 4
DestClockInfoList
DestClockInfo
ClockName : _AUTO_CLK_3_
ClockObject : clkB
ClockDomainId : 5
SrcObjectType : flop
DestObjectType : flop
The following waiver command(s) can be used to waive the violation
above:
waive_cdc -add waive_with_simple_field -filter { SrcObject =~
u_ACUS/bin_count/Q[0:1] } -tag SYNCCDC_UNSYNC_NOSCHEME
waive_cdc -add waive_using_violation_id -id 224
waive_cdc -add waive_tag -tag SYNCCDC_UNSYNC_NOSCHEME
waive_cdc -add waive_with_nested_field -filter {
ReasonInfoList:ReasonInfo:ReasonCode =~ NO_SYNC_METHOD }
waive_cdc -add waive_to_points -to u_ACUS/u_sync2s/meta/Q

configure_cdc_rca
Description
This command is used to specify configuration options for CDC RCA flow.

711
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
configure_cdc_rca
[-tag <Tag Value>]
[-minimum_dest_signal_count <COUNT>]
[-minimum_src_signal_count <COUNT>]
[-async_dest_signal_atleast_one]
[-async_dest_signal_all]
[-async_src_signal_atleast_one]
[-async_src_signal_all]
[-async_clk_domain_atleast_one]
[-async_clk_domain_only_one]
[-async_crossings_only]
[-async_crossing_atleast_one]
[-minimum_crossing_outside_inst <COUNT>]
[-exclude_datapath_partial]
[-potential_default_depth <SEQ-DEPTH>]
[-testlogic_filter_exp <list of expressions>]
[-group_testlogic_violations]
[-group_memlogic_violations]
[-memlogic_bus_size_threshold <SIZE>]
[-uncovered_viols_report_path <DIR_PATH>]
[-include_rstviols_qual_rc]
[-groupby_dest_domain]
[-hotspot_view]
[-qualname_filter_exp]
[-depth_fanin_val size]
[-dest_count_threshold size]
[-ignore_fanin_signal {list of expressions}]

712
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Arguments
 [-tag <Tag>]: Specify the tag values wherever required for which the
additional CDC ML RCA configuration options need to be applied.
Tag Values: DEBUG_CDC_ASYNC_CLOCKPAIR,
DEBUG_CDC_ASYNC_SRCDST_EQVDOMS,
DEBUG_CDC_BBOXPIN_CONSTRAINT, DEBUG_CDC_DST_HIGH_FANIN,
DEBUG_CDC_DST_INST_HIGH_FANIN,
DEBUG_CDC_PORT_CONSTRAINT,
DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH,
DEBUG_CDC_SRC_HIGH_FANOUT,
DEBUG_CDC_SRC_INST_HIGH_FANOUT
 [-minimum_dest_signal_count <COUNT>]: Specify Minimum Unique
Destination Bus [Tag Value: DEBUG_CDC_SRC_HIGH_FANOUT]
(Default:20)
 [-minimum_src_signal_count <COUNT>]: Specify Minimum Unique
Source Bus Count [Tag Value: DEBUG_CDC_DST_HIGH_FANIN]
(Default:20)
 [-async_dest_signal_atleast_one]: Flag violation if atleast one
Unsync Crossing present from source [Tag Value:
DEBUG_CDC_SRC_HIGH_FANOUT] (Default: OFF)
 [-async_dest_signal_all]: Flag violation only if NO sync crossings
present from source [Tag Value: DEBUG_CDC_SRC_HIGH_FANOUT]
(Default: OFF)
 [-async_src_signal_atleast_one]: Flag violation if atleast one
unsync crossing present to destination [Tag Value:
DEBUG_CDC_DST_HIGH_FANIN] (Default: OFF)
 [-async_src_signal_all]: Flag violation only if NO sync crossings
present to destination [Tag Value: DEBUG_CDC_DST_HIGH_FANIN]
(Default: OFF)
 [-async_clk_domain_atleast_one]: Flag violation if atleast one
asynchronous clock domain present [Tag Value: DEBUG_CDC_PORT/
BBOXPIN_CONSTRAINT] (Default:ON)
 [-async_clk_domain_only_one]: Flag violation if ONLY one
asynchronous clock domain present [Tag Value: DEBUG_CDC_PORT/
BBOXPIN_CONSTRAINT] (Default: OFF)

713
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-async_crossings_only]: Only consider count of unsync crossings to


flag an instance as high fanout / fanin [Tag Value: DEBUG_CDC_SRC/
DST_INST_HIGH_FANOUT/FANIN] (Default:ON)
 [-async_crossing_atleast_one]: Consider instance as high fanout /
fanin if it contains atleast one unsync crossing [Tag Value:
DEBUG_CDC_SRC/DST_INST_HIGH_FANOUT/FANIN] (Default: OFF)
 [-minimum_crossing_outside_inst <COUNT>]: Specify minimum
crossing count outside instance to be considered as high fanout / fanin
[Tag Value: DEBUG_CDC_SRC/DST_INST_HIGH_FANOUT/FANIN]
(Default:1000)
 [-exclude_datapath_partial]: Exclude Data Path Partial crossings
[Tag Value: DEBUG_CDC_ASYNC_CLOCKPAIR] (Default: OFF)
 [-potential_default_depth <SEQ-DEPTH>]: Set potential default
qualifier depth to check for possible synchronization [Tag Value:
DEBUG_CDC_QUALIFIER_DEFAULT_SEQDEPTH] (Default:3)
 [-testlogic_filter_exp <list of expressions>]: Provide string to
match to check TEST LOGIC Paths [Tag Value:
DEBUG_CDC_TESTLOGIC_SOURCE/DESTINATION/SRCCLK/DSTCLK]
(Default expressions: TEST, DFT, SCAN, BIST, TCK)
 [-group_testlogic_violations]: Group All TESTLOGIC_SOURCE /
TESTLOGIC_DESTINATION violations into one (Default: OFF)
 [-group_memlogic_violations]: Group all MEMLOGIC_SOURCE /
MEMLOGIC_DESTINATION violations into one (Default: OFF)
 [-memlogic_bus_size_threshold <SIZE>]: Set the threshold to check
bus sizes for filtering MEMLOGIC objects (Default:1024)
 [-uncovered_viols_report_path <DIR_PATH>]: Directory where
uncovered effect violation information is dumped. Generates one tcl file
named, uncovered_effect_viols.tcl, comprising all uncovered violations
in the directory. The uncovered_effect_viols.tcl file contains the
report_cdc command that has file name specified as
uncovered_viols.log and directory name same as specified using the -
uncovered_viols_report_path <DIR_PATH> option.
 [-include_rstviols_qual_rc]: Includes debug qualifier violations for
CDC in reset paths. Default: OFF.
 [-groupby_dest_domain]: Groups all port constraint violations based
on Dest Clock domain. Default: OFF.

714
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-hotspot_view]: Enables quick analysis of cause with high impact and


re-run clustering iteratively in same session to cover all effect and
causes in subsequent RCA analysis. By default, RCA clusters report all
possible causes associated with effect violations in a cluster. Default:
OFF.
 [-qualname_filter_exp]: Provides string to check matching potential
qualifier paths [DEBUG_CDC_QUALIFIER_POTENTIAL]. Default
expression: SYNC.
 [-depth_fanin_val size]: Specifies the depth level for fanin analysis.
Default: 2.
 [-dest_count_threshold size]: Specifies the threshold count of
destinations to consider for violation. Default: 8.
 [-ignore_fanin_signal {list of expressions}]: Specifies the
string to ignore matching fanin signal paths on the next run. This is
applicable only for DEBUG_CDC_FANIN_SIGNAL_COMMON,
DEBUG_CDC_FANIN_QUAL_DIFF_DOMAIN, and
DEBUG_CDC_FANIN_QUAL_SAME_DOMAIN.

Example:
 configure_cdc_rca -group_memlogic_violations
This command groups all the DEBUG_CDC_MEMLOGIC_SOURCE/
DEBUG_CDC_MEMLOGIC_DESTINATION violations into one.
 configure_cdc_rca -minimum_src_signal_count 50 -tag
DEBUG_CDC_DST_HIGH_FANIN
This command changes the minimum Unique Source Bus Count that
destination may consider from default value to the new value specified
here, that is, 50 while flagging the tag DEBUG_CDC_DST_HIGH_FANIN.

get_asyncrst_paths
Description
The get_asyncrst_paths command retrieves the specified reset paths.

Syntax
get_asyncrst_paths

715
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

[-from <pin, net>]


[-to <pin, net>]
[-from_domain <clock_domain>]
[-to_domain <clock_domain>]
[-from_clock <clock>]
[-to_clock <clock>]
[-include_ignored]
[-only_instrumented]
[-filter <filter_expression>]
[-of_objects obj_list]
[-group_name <group_name>]
[-group_count <group_count>]
[-tag <tag>]
[-qualifiers <qualifier_list>]
[-qualifier_depth <unsigned int>]
[-id <unsigned int>]
[-quiet]

Arguments
 [-from <pin, net>]: Returns all reset paths from the specified source.
 [-to <pin, net>]: Returns all reset paths ending at the specified
destination.
 [-from_domain <clock_domain>]: Returns all reset paths originating
from the specified domain.
 [-to_domain <clock_domain>]: Returns all reset paths terminating in
the specified domain.
 [-from_clock <clock>]: Returns all reset paths originating from the
specified clock.
 [-to_clock <clock>]: Returns all reset paths terminating in the
specified clock.
 [-include_ignored]: Specifies to include ignored paths.

716
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-only_instrumented]: Returns the paths caused by UPF


instrumentation.
 [-filter <filter_expression>]: Filters the paths based on the
specified expression.
 [-of_objects obj_list]: Returns the paths of the specified objects
such as clock_domain, synchronizer.
 [-group_name <group_name>]: Returns the crossing paths grouped
under the specified group name.
 [-group_count <group_count>]: Returns the crossing paths under
groups with the specified group count.
 [-tag <tag>]: Select reset paths based on the specified tag.
 [-qualifiers <qualifier_list>]: Returns all reset paths
synchronized by the specified qualifiers.
 [-qualifier_depth <unsigned int>]: Returns synchronized reset
paths with the specified qualifier depth.
 [-id <unsigned int>]: Returns bit-level crossing paths corresponding
to a violation.
 [-quiet]: Does not generate any error or info message for the missing
reset path objects.

Example:
The following command returns reset paths report under given tag which
are not ignored, and begin from given pin/net.
get_asyncrst_paths -tag ASYNCRST_CTRLPATH_FULL -from <pin/
net> -filter "is_ignored==false"

get_cdc_paths
Description
The get_cdc_paths command retrieves the specified CDC paths.

Syntax
get_cdc_paths

717
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

[-from <pin, net>]


[-to <pin, net>]
[-from_domain <clock_domain>]
[-to_domain <clock_domain>]
[-from_clock <clock>]
[-to_clock <clock>]
[-include_ignored]
[-only_instrumented]
[-filter <filter_expression>]
[-of_objects obj_list]
[-group_name <group_name>]
[-group_count <group_count>]
[-tag <tag>]
[-qualifiers <qualifier_list>]
[-qualifier_depth <unsigned int>]
[-id <unsigned int>]
[-quiet]

Arguments
 [-from <pin, net>]: Returns all CDC paths from the specified source.
 [-to <pin, net>]: Returns all CDC paths ending at the specified
destination.
 [-from_domain <clock_domain>]: Returns all CDC paths originating
from the specified domain.
 [-to_domain <clock_domain>]: Returns all CDC paths terminating in
the specified domain.
 [-from_clock <clock>]: Returns all CDC paths originating from the
specified clock.
 [-to_clock <clock>]: Returns all CDC paths terminating in the
specified clock.
 [-include_ignored]: Specifies to include ignored paths.

718
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-only_instrumented]: Returns the paths caused by UPF


instrumentation.
 [-filter <filter_expression>]: Filters the paths based on the
specified expression.
 [-of_objects obj_list]: Returns the paths of the specified objects
such as clock_domain, synchronizer.
 [-group_name <group_name>]: Returns the crossing paths grouped
under the specified group name.
 [-group_count <group_count>]: Returns the crossing paths under
groups with the specified group count.
 [-tag <tag>]: Select CDC paths based on the specified tag.
 [-qualifiers <qualifier_list>]: Returns all CDC paths
synchronized by the specified qualifiers.
 [-qualifier_depth <unsigned int>]: Returns synchronized CDC
paths with the specified qualifier depth.
 [-id <unsigned int>]: Returns bit-level crossing paths corresponding
to a violation.
 [-quiet]: Does not generate any error or info message for the missing
CDC path objects.

Example:
The following command returns cdc paths report under given tag which are
not ignored, and begin from given pin/net.
get_cdc_paths -tag SYNCCDC_CTRLPATH_FULL -from <pin/net> -
filter "is_ignored==false"

get_cdc_path_elements
Description
The get_cdc_path_elements command returns the elements in the
specified CDC path.

719
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
get_cdc_path_elements
[-from]
[-to]
[-from_domain]
[-to_domain]
[-from_clock]
[-to_clock]
[-tag]
[-qualifiers]
[-qualifier_depth]
<cdc_path>

Arguments
 [-from]: Returns the source pin/port from which the specified CDC path
starts.
 [-to]: Returns the destination at which the specified path terminates.
 [-from_domain]: Returns the source clock domain object of the
specified CDC path.
 [-to_domain]: Returns the sink clock domain object of the specified
CDC path.
 [-from_clock]: Returns the source clock object of the specified CDC
path.
 [-to_clock]: Returns the sink clock object of the specified CDC path.
 [-tag]: Returns the synchronization tag for the specified path.
 [-qualifiers]: Returns all CDC qualifiers identified for the specified
path.
 [-qualifier_depth]: Returns the qualifier depth of the specified path.
 <cdc_path>: Specifies the CDC path.

720
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Example:
 The following command returns sources of all cdc paths
get_cdc_path_elements -from [get_cdc_paths ]
 The following command returns destination of given cdc path
get_cdc_path_elements -to F1/Q-F2/D

group_cdc_paths
Description
The group_cdc_paths command creates groups of crossings on the basis of
source, destination, source clock or domains, and destination clock or
domains.

Syntax
group_cdc_paths
[-automatic]
[-name]
[-file]

Arguments
 [-automatic]: Specifies that the grouping type is the automatic
grouping type. The -automatic argument can have the following
values:
source | destination | qualifier | sourceDomain |
destinationDomain | sourceClock | destinationClock
 [-name]: Specifies the name of the group.
 [-file]: Specifies the name of the file to generate the groups.

Example:
 The following command groups the crossings based on the source:
group_cdc_paths -automatic source -name grp1 -file
grp1_file.txt

721
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 The following command groups the crossings based on the source clock
domain:
group_cdc_paths -automatic sourceDomain -name
SrcClkDomaingrp1 -file SCDgrp1_file.txt
 The following command groups the clock domain crossing paths based
on the qualifiers:
group_cdc_paths -automatic qualifier -name
qualclkDomainGrp1 -file qual_groups.txt

remove_cdc_violation
Description
The remove_cdc_violation command use to remove violations from the
CDC database.

Syntax
remove_cdc_violation
[-tag <name>]
[-id <id>]
[-nosave]
[-save]

Arguments
 [-tag] : Remove violations based on Tag name
 [-id <id>] : Remove violations based on IDs
 [-nosave] : Skip updating removed violation in disk
 [-save] : Update all removed violation(s) in disk

Example:
The following command remove violations of given tag and updated in disk
remove_cdc_violation -tag SETUP_ASYNC_CLOCK_OVERLAP -save

722
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

get_cdc_control_synchronizer_elements
Description
The get_cdc_control_synchronizer_elements command returns the
synchronizer output design objects of the specified cdc control
synchronizer.

Syntax
get_cdc_control_synchronizer_elements
-output
<cdc_control_synchronizer>

Arguments
 -output: Returns the synchronizer output design object of the specified
cdc control synchronizer.
 <cdc_control_synchronizer>: Specify the CDC Control Synchronizer.

get_cdc_control_synchronizers
Description
The get_cdc_control_synchronizers command returns the clock domain
crossing control synchronizers.

Syntax
get_cdc_control_synchronizers
-of_object <get_cdc_coherency>
[-filter <expression>]

Arguments
 of_object <get_cdc_coherency>: Returns the control synchronizers
for the specified cdc coherency object.

723
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 [-filter <expression>]: Select the violations based on the specified


expression.

Example:
The following command returns pins related to cdc controlled synchronizer:
get_cdc_control_synchronizers -of_object [get_pins]
get_cdc_control_synchronizers -of_object [get_pins] -filter
"name==F3/Q"

get_cdc_mapped_name
Description
Use this command to get the equivalent NETLIST signal from a RTL signal
and vice-versa.

Syntax
get_cdc_mapped_name
-name
[-type rtl2netlist | netlist2rtl]

Arguments
 -name: Specify the name for which mapping is required.
 [-type rtl2netlist | netlist2rtl]: Specify the mapping type. By
default we will do rtl2netlist.

Example:
To get the equivalent NETLIST signal from a RTL signal
get_cdc_mapped_name -name RtlNet -type rtl2netlist

get_connected_objs

724
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Description
Returns a collection of the connected object of the given net/pin name

Syntax
get_connected_objs
-name
-type net | pin
[-dir fanin | fanout | both]
[-quiet]

Arguments
 -name: Specify the net/pin name for which connected object is required.
 -type net | pin: Specify the connected object type to be searched for
the given name in -name.
 [-dir fanin | fanout | both]: Specify the direction in which the
connected object needs to be searched. Default: fanout.
 [-quiet]: Suppresses all messages except syntax error messages.

Example:
To get a collection of the connected net of CKCK, where CKCK can be a net
or a pin, use the following command:
get_connected_objs -name CKCK -type net
If CKCK is a net, then get_connected_objs returns CKCK. However, if CKCK
is a pin, then get_connected_objs returns the connected net to the CKCK
pin.

report_cdc_reason_code
Description
The report_cdc_reason_code command reports all the reason codes used
during CDC analysis.

725
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
report_cdc_reason_code
[-code <reason_code>]
[-file <file_name>]

Arguments
 [-code <reason_code>]: Specifies the list of all the reason codes used
during CDC analysis.
 [-file <file_name>]: Specifies the name of the designated file to save
the results.

Example:
The following example shows some usages of report_cdc_reason_code
command:
report_cdc_reason_code
REASONCODE DEFAULT CURRENT DEFAULT CURRENT
REASONCODE
TYPE TYPE HIDDEN HIDDEN
HELP
----------
------- ------- ------- -
------ ----------
ASYNCRST_RSTLESS_PATH :FULL :FULL
:HIDDEN :HIDDEN :Resetless crossing path
RST_IGNOREPATH_COMMAND :FULL :FULL
:UNHIDDEN :UNHIDDEN :set_asyncrst_ignore_path matches fully
ASYNC_SRC_CONV :PARTIAL
:PARTIAL :UNHIDDEN :UNHIDDEN :Multiple source signals
from different domains
converge after synchronization

get_clock_relationship

726
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Description
This command reports the relationship between clocks passed in the clock
list.

Syntax
get_clock_relationship
<clocks>
[-type < asynchronous | logically_exclusive |
physically_exclusive | synchronous >
[-csv]
[-file <file name>]
[-gui]

Arguments
 The command has 1 compulsory argument that is the clock list, rest of
the arguments are optional.
 <clocks>: Specifies the list of clocks between which relationship is to be
checked. The number of clock that can be specified depend on the mode
in which VC Spyglass is operated. In PT compatibility mode, only 2
clocks can be specified in the clock list. Otherwise more than 2 clocks
can be specified in the list. For example, the below command with raise
an error in PT compatibility mode:
vc_static_shell> get_clock_relationship {c1 c2 c3}
where c1, c2 and c3 are clocks defined in SDC file.
VC Spyglass can be set to PT compatible through the pt_compatibility_mode
application variable. Setting this app_var true to make VC Spyglass compatible with
PT
 <-type>: Returns a Boolean value based on whether the clock
relationship specified with this option exists between the clock given in
the clock list. For example :
vc_static_shell> set_clock_groups -group {c1} -group {c2}
-asynchronous
1

727
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

vc_static_shell> get_clock_relationship {c1 c2} -type


asynchronous
{true}
vc_static_shell> get_clock_relationship {c1 c2} -type
logically_exclusive
{false}
 <-csv> : Displays result in csv format. For example:
 vc_static_shell> set_clock_groups -group {c1} -group {c2}
-group {c3} -asynchronous
1
 vc_static_shell> get_clock_relationship {c1 c2 c3}
c1 c2 : asynchronous
c1 c3 : asynchronous
c2 c1 : asynchronous
c2 c3 : asynchronous
c3 c1 : asynchronous
c3 c2 : asynchronous
 vc_static_shell> get_clock_relationship {c1 c2 c3} -csv
'Clock1','Clock2','Relationship'
c1,c2,asynchronous
c1,c3,asynchronous
c2,c1,asynchronous
c2,c3,asynchronous
c3,c1,asynchronous
c3,c2,asynchronous
 -file <file name>: Specifies the file in which the command output is
to be saved.
 -gui: Displays the result of the command in Verdi.

When to Use:
Clock relationship querying feature is a basic debugging feature in VC
Spyglass. In designs having large number of clocks and consequently
multiple clock relations, manually searching and inferring the clock
relationship by analyzing SDC file can be tedious and time consuming
hence this command provides a utility to infer clock relationships.

728
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

This command can also be used to checking whether specified clocks have
a specific clock relationship by using the "-type" argument. Furthermore
this command can output clock relationships to a file in csv format which
can be used to further debugging or analysis of the design.
For example consider the following clock relations:
vc_static_shell> set_clock_groups -group {c1} -group {c2} -
group {c3} -group {c4} -asynchronous
1
vc_static_shell> set_clock_groups -group {c1 c2} -group {c3
c4} physically_exclusive
1
vc_static_shell> set_clock_groups -group {c1 c4} -group {c2
c3} -logically_exclusive
1
To infer clock relationships between c1 and c2, use the following command:
vc_static_shell> get_clock_relationship {c1 c2}
c1 c2 : logically_exclusive asynchronous
c2 c1 : logically_exclusive asynchronous
To check whether c2 and c3 are physically exclusive, use the following
command:
vc_static_shell> get_clock_relationship {c2 c3} -type
physically_exclusive
c2 c3 : true
c3 c2 : true
To report the clock relationship between c1 and c4 in csv, use the following
command:
vc_static_shell> get_clock_relationship {c1 c4} -csv
'Clock1','Clock2','Relationship'
c1,c4,physically_exclusive asynchronous
c4,c1,physically_exclusive asynchronous
To display the above information in Verdi, use the following command:

729
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

get_clock_relationship {c1 c4} -csv -gui

report_attribute
Description
The report_attribute command reports the attributes on one or more
objects. To limit the reported attributes to a specific set, use the -
attributes option.

Syntax
report_attribute
[-class <class name>]
[-no_split]
[-attributes <attributes_list>]
[-summary]
<Object list>

Arguments
 -class <class-name>: Specifies the class name for the objects
specified in the object-list argument. Permissible values are cell,
clock, clock_dm_clock, design, isolation_strategy, lib_cell,
lib_pin, net, pin, pin_word, port, port_word.
 -no_split: Prevents the report from splitting the lines if the text in a
column overflows.
 -attributes <attributes-list>: Reports only the specified set of
attributes for each object in object-list.
 -summary: Prints a summary report in tabular format.
 object-list: Specifies the list of objects to report. Each element in the
list is either a collection or a pattern that combines with the class-name
value to find the objects.

Example:
Consider the following report_attribute commands and the corresponding

730
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

reports:
vc_static_shell> report_attribute -class net [get_nets clk*]
****************************************
Report : Attribute
Design : top
Version: O-2019.06-Alpha
Date : Tue Dec 18 20:08:25 2018
****************************************
Design Object Type Attribute Name
Value
---------------------------------------------------------------
-----------------------
top clk1 string base_name
clk1
top clk1 string full_name
clk1
top clk1 bool has_multi_driver
false
top clk1 bool is_sam_retained
false
top clk1 bool is_user_defined
true
top clk1 string name
clk1
top clk1 int net_width
1
top clk1 string object_class
net
top clk1 string create_static
false
top clk1 string source_location
top.v:1

731
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

****************************************

vc_static_shell> report_attribute [get_cells Data*] -attributes


is_a_flip_flop -summary
****************************************
Report : Attribute
Design : top
Version: O-2019.06-Alpha
Date : Tue Dec 18 20:12:00 2018

****************************************
Object is_a_flip_flop
DataD true
DataS__MD_2 true
DataS__MD_1 true
****************************************

set_constraints_scope
Description
The set_constraints_scope command defines the scope of the attribute
commands.
The set_constraints_scope command is optional. If not specified, the
scope of the top module is used.
NOTE: The scope can also be defined by using the read_sdc -module/instance
<module_name/instance_name> command.

Syntax
set_constraints_scope -module <module-name> / -instance
<instance-name >

732
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

...
end_constraints_scope

Arguments
 -module <module-name>: Specifies the name of the module to which
the specified attribute commands are applied. The scope includes all the
instances of the module as well as all the lower hierarchies. The -module
and the -instance arguments are mutually exclusive.
 -instance <instance-name>: Specifies the name of the instance to
which the specified attribute commands are applied. The -module and
the -instance arguments are mutually exclusive.

Example:
Consider the module shown in Figure 13.

FIGURE 13.

In addition, consider the following command is used for the design shown
in Figure 13:
set_constraints_scope -module Block1
In this case, the I1, I2 and 'I4/I5' are selected for applying the attributes.
Use the following command to apply the attributes to the 'I4/I6' instance:

733
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

set_constraints_scope -instance { I4/I6 }

set_cdc_ignore_path
Description
The set_cdc_ignore_path command specifies the clock domain crossings
that should be ignored for CDC analysis.

Syntax
set_cdc_ignore_path
[-from <pin|port|Qpin list|Module|Instance >]
[-to <pin|port|Qpin list|Module|Instance >]
[-from_clock <from_clk_list>]
[-to_clock <to_clk_list>]
[-through <through_object_list>]
[-user_clock_only]
[-derived_clock_only]
[-from_type <data|clock|all>]
[-to_type <data|clock|all>]
[-type <cdc_crossing|reset_path_crossing|
reset_path_glitch|data_path_glitch|lib_async_glitch|coherency_m
ulti_sync|input_multi_sample|input_constr_multi_sample|output_m
ulti_sample|output_constr_multi_sample|reset_multi_sync|data_do
main_validation|combo_validation|clock_validation|reset_validat
ion|quasi_validation|set_case_validation|qualifier_validation|a
ll>]
[-comments <comment>]

Arguments
 [-from <pin|port|Qpin list|Module|Instance >]: Specifies pin, port,
or Qpin of a sequential object from where the CDC path needs to be
ignored. For boundary ports, use set_input_delay, to make that

734
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

particular port part of the crossing. Pin|port can be specified with the
get_pins or get_ports commands which return the list of objects
 [-to <to_object_list>]: Specifies pin, port, or Qpin of a sequential
object, to which the CDC path needs to be ignored. For boundary ports,
use set_output_delay to make that particular port part of the crossing.
Pin|port|Qpin can be specified with the get_pins or get_ports commands
which return the list of objects.
 [-from_clock <from_clk_list>]: Specifies a list of clock objects from
which CDC paths need to be ignored.
 [-to_clock <to_clk_list>]: Specifies a list of destination clock
registers for which CDC paths need to be ignored.
 [-through <through_object_list>]: Specifies a list of modules, pins
through which CDC paths need to be ignored. You can specify multiple
through pins. Note that the crossing is ignored only if the crossing
passes via the specified through objects in the order in which the
objects are specified in the set_cdc_ignore_path command.
 [-user_clock_only]: Specifies if derived clocks in from_clock/to_clock
switch should be ignored.
 [-derived_clock_only]: Specifies if only derived clocks in from_clock/
to_clock switch should be ignored.
 [-from_type <data|clock|all>]: Specifies the types of objects
specified with the -from argument. Default: data.
 data: You can specify any of pin|port|Qpin list|Module|Instance
crossing source objects with the -from argument.
 clock: You can provide a list of clock objects reaching the crossing
source with the -from argument. However, it is recommended to use
equivalent -from_clock if clock objects are specified.
 all: You can provide both data as well as clock objects of crossing
source with the -from argument.
 [-to_type <data|clock|all>]: Specifies the types of objects specified
with the -to argument. Default: data.
 data: You can specify any of pin|port|Qpin list|Module|Instance
crossing destination objects with the -to argument.
 clock: You can specify a list of clock objects reaching the crossing
destination with the -to argument. However, it is recommended to
use equivalent -to_clock if clock objects are specified.

735
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 all: You can provide both data as well as clock objects of crossing
destination with the -to argument.
 [-type <cdc_crossing|reset_path_crossing|
reset_path_glitch|data_path_glitch|lib_async_glitch|coherenc
y_multi_sync|input_multi_sample|input_constr_multi_sample|ou
tput_multi_sample|output_constr_multi_sample|reset_multi_syn
c|data_domain_validation|combo_validation|clock_validation|r
eset_validation|quasi_validation|set_case_validation|qualifi
er_validation|all>]: Specifies the type of violations to be waived. If
not specified, VC SpyGlass ignores the crossings for matching fields. If
specified, VC SpyGlass waives the violations for the specified type only
and reports violations for the other types. The -type argument can be
used with the -to and the -from arguments only.
You can use the -type argument to specify multiple types of violations
to be ignored using the same command.
 [-comments <comment>]: Specifies the ignore path comments. This
argument works only with the -type argument.

Example:
Consider the following schematic where a CDC crossing exists from
topinst/inst3/out/Q to the topinst/inst7/out/Q pin.

In addition, consider the following set_cdc_ignore_path TCL command:


set_cdc_ignore_path -through {topinst/and_inst1/out} -

736
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

through {topinst/and_inst2/out} -through {topinst/and_inst4/


out}
In this case, the SYNCCDC_IGNOREPATH_USER_CONSTRAINT tag marks
this crossing as synchronized because the order of through fields in the TCL
command matches the crossing path specified with the through objects.

report_clock_reset_tree
Description
Reports constraints based on clock/reset tree browser.

Syntax
report_clock_reset_tree
[-type <clock | reset>]
[-format <sdc | utf>]
[-selected]
[-sort]
[-file <filename>]
[-filter <clocks | resets | constants | all>]

Arguments
 [-type <clock | reset>]: Select whether to generate the report for
clock or reset tree. (Default: clock)
 [-format <sdc | utf>]: Select whether to generate the report in SDC
format or UTF format. (Default: SDC)
 [-selected]: Generates constraints only for items selected using the
Clock/Reset Tree Browser.
 [-sort]: Prints the report in sorted order based on the names.
 [-file <filename>]: Writes the report to the specified file. By default,
prints on the shell.
 [-filter <clocks | resets | constants | all>]: Generates
specified constraint types only. (Default: all)

737
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

set_clock_attribute
Description
The set_clock_attribute command specifies the path element(s) or the
attribute to which the clock constraints is to be attached.

Syntax
set_clock_attribute
- <attribute name>
[-clocks {clock-names}]
[-clock_objects {pin-names}]
[-combo "yes/no/unknown"]
[-add]
[-combo_ifn {combo clock} ]

Arguments
 <attribute_name>: Specifies the path element(s) or the attribute name
to which the clock constraints are to be attached.
 -clocks <clock-names>: Specifies the SDC clock names that drive the
design objects to which the path element is attached. Note that the -
clocks and the -clock_objects are mutually exclusive arguments and
cannot be specified together.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -clocks argument, VC
SpyGlass CDC reports an error.
 -clock_objects <pin-names>: Specifies the clock ports of the design
objects to which the attribute is attached. Note that the -clocks and
the -clock_objects are mutually exclusive arguments and cannot be
specified together.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -clock_objects
argument, VC SpyGlass CDC reports an error.

738
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-combo "yes/no/unknown"]: Models a combinational logic between


the specified design objects and the virtual sequential element. The
supported values for the -combo option are yes and no.
 [-add]: Adds the clock (or clock ports) to the specified attribute. If -add
is not specified, VC SpyGlass CDC overrides the existing clocks, if any.
 [-combo_ifn {combo clock} ]: Specifies the clock root to be used for
combo validation.

Example:
The following example shows some usages of set_clock_attribute
command
set_constraints_scope -module top
define_attribute -name path1
set_clock_attribute path1 -clocks c1
set_constraints_scope -module top
define_attribute -name path1
set_clock_attribute path1 -clock_objects clk1
NOTE: If both I/O delay and clock attributes are specified for a design object, a warning
message is displayed and by default, the clock attribute is given preference over I/
O delay.

set_clockglitch_ignore_path
Description
The set_clockglitch_ignore_path command ignores the clock path
glitch crossings reported by the SETUP_CLOCK_GLITCH tag.

Syntax
set_clockglitch_ignore_path
[-from <pin|port|Qpin list>]
[-to <pin|port|Qpin list>]
[-from_clock <from_clock_list>]
[-to_clock <to_clock_list>]
[-through < pin|net|module list>]

739
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 [-from <pin|port|Qpin list>]: Specifies a list of ports or pins from
which CDC paths need to be ignored for clock path glitch analysis. You
can specify the ports or pins names directly as well as use the get_pins
or the get_ports command to specify pin or port value respectively.
 [-to <pin|port|Qpin list>]: Specifies a list of ports or pins (Q pin or
CLK pin) or converging net to which CDC paths need to be ignored for
clock path glitch analysis. Use get_pins or get_ports command to
specify the pin|port|Qpin|ClkPin value that return the list of objects.
 [-from_clock <from_clock_list>]: Specifies a list of source clock
objects from which CDC paths need to be ignored for clock path glitch
analysis.
 [-to_clock <to_clock_list>]: Specifies a list of destination clock
registers for which CDC paths need to be ignored for clock path glitch
analysis.
 [-through < pin|net|module>]: Specifies the pin, net, or module
through which crossover passes between the start and end points. You
can specify multiple through objects. The crossover should pass through
the specified sequence of through objects to get ignored for clock path
glitch analysis.

Example:
To ignore path from Qpins of a register, use the following command:
set_clockglitch_ignore_path -from [get_pinsusb3_noclkrst/
usb3_pwrm/usb3_pwrm_csr/gctl_reg/Q*]
To ignore from a register Qpin to destination pin, use the following
command:
set_clockglitch_ignore_path -from [get_pins usb3_clk/
host_mode_r/Q*]-to [get_pinsusb3_clk/usb3_sync_ctl_mac_mac3/
in_p_1d/Q*]
To ignore from a register Qpin to destination pin through specified operator
pin, use the following command:
set_clockglitch_ignore_path -from {topinst/inst3/out/Q} -
through{topinst/and_inst4/out} -to {topinst/inst4/out/Q}

740
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

set_sync_attribute
Description
The set_sync_attribute command specifies the synchronizers that drive
the given virtual node.

Syntax
set_sync_attribute
<attribute name>
-from {clock names/pin names}
-to {clock names/pin names}
-sync {active/inactive}
[-seq_depth]
-sync_names
[-combo "yes/no/unknown"]
[-combo_ifn {combo clock} ]

Arguments
 <attribute name>: Specifies the name of attribute element defined by
define_attribute.
 -from {clock names/pin names}: Specifies the names of sdc clocks/
related clock pins (should exist) to which clocks reach or on which clocks
are defined of the synchronizer source.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -from argument, VC
SpyGlass CDC reports an error.
 -to {clock names/pin names}: Specifies the names of sdc clocks/
related clock pins (should exist) to which clocks reach or on which clocks
are defined of the synchronizer destination.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -to argument, VC
SpyGlass CDC reports an error.

741
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

 -sync {active/inactive}: Specifies if the provided synchronizer is


active/inactive (can synchronize other crossings or not)
 [-seq_depth]: Specifies the sequential depth by which the synchronizer
reaches the virtual node. Default depth is 0.
 -sync_names: Specifies the synchronizer name reaching the virtual
node. If same synchronizers are reaching two virtual nodes, both nodes
will have same sync_names of the sync_attribute.
 [-combo]: Defines a combo logic before the virtual sequential.
 [-combo_ifn {combo clock} ]: Specify the clock root to be used for
combo validation.
Note that the get_* commands cannot be specified with this argument.
If the get_* commands are specified with the -combo_ifn argument,
VC SpyGlass CDC reports an error.

Example:
The following example shows the usage of the command:
set_constraints_scope -module top
define_attribute -name path1
set_sync_attribute path1 -from clk1 -to clk2 -sync inactive -
sync_names { s1 s2 }

set_tag_attribute
Description
The set_tag_attribute command sets the ordering of the violation tags
in the Activity Viewer. Violation tags with lower order value are displayed
first. Tags that do not have any order value are displayed at the end.

Syntax
set_tag_attribute
<tag>
<attribute>
<attrval>

742
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Arguments
 <tag>: Specifies the tag for which attribute name and attribute value is
to be changed.
 <attribute>: Specifies the name of the attribute to change for the
specified tag.
 <attrval>: Specifies the value to be applied to the selected attribute of
the specified tag.

Example:
Consider the following set_tag_attribute commands:
set_tag_attribute ISO_STRATEGY_MISSING order 1000
set_tag_attribute ISO_INST_MISSING order 100
set_tag_attribute PST_STATE_MULTIPLE order 500
The above commands are used, the violation tags are shown in the
following order in the Activity Viewer:
1. ISO_INST_MISSING violations
2. PST_STATE_MULTIPLE violations
3. ISO_STRATEGY_MISSING violations

set_test_attribute
Description
The set_test_attribute command define/provide the dft-related
information. This command cannot be used standalone. It should be used
along with other attribute commands.

Syntax
set_test_attribute
- <attribute name>
[-testbus]
[-analog]

743
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 <tag>: Specifies the tag for which attribute name and attribute value is
to be changed.
 - <attribute name>: Specifies the name of the attribute element
defined by define_attribute.
 [-testbus]: Specifies that the defined ports/pins are of type testbus.
 [-analog]: Specifies that the defined ports/pins are of type analog.

Example
The following example shows the usage of the set_test_attribute
command:
set_constraints_scope -module top
define_attribute -name path1
set_test_attribute path1 -testbus
apply_attribute path1 -objects in1 -direction input
end_constraints_scope

set_reset_sense
Description
Specifies the reset propagation stop points.

Syntax
set_reset_sense
-reset <reset_name_list|all>
-direction <forward|backward|both>
-design_object_list

Arguments
 -reset <reset_name_list|all>: Filters which resets this command
gets applied to. (Default: all)

744
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 -direction <forward|backward|both>: Specifies if command will be


honored during reset propagation or inference. (Default: both)
 -design_object_list: Name of the design objects to stop propagation
on.

Example:
The following example shows some usages of set_reset_sense command:
set_reset_sense -reset all
set_reset_sense -direction forward

end_constraints_scope
Description
The end_constraints_scope command defines the end of the current
scope of the attribute commands. The end_constraints_scope command
is applicable to CDC attribute commands only.

Syntax
set_constraints_scope
...
...
end_constraints_scope

Arguments
None

write_clock_tree
Description
Generates the Clock Tree report.
By default, the clock tree report is generated with the CLKTree.rpt name
in the vcst_rtdb/reports directory. You can specify a different file name

745
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

by using the -file option. VC CDC generates the report with the specified
file name in the current working directory.
By default, the clock tree report includes details of all the user-defined SDC
primary clocks. You can specify a space-separated list of SDC clock names
for which clock tree will be included in the report.

Syntax
write_clock_tree
[-clock {clock_list}]
[-file {filename}]
[-dump_rtl_net {true | false}]

Arguments
 [-clocks {space-separated-list-of-sdc-clocks}]: Specifies the
list of user-defined SDC primary clocks.
 [-file <user-specified-file-name>]: Specifies the file name.
 [-dump_rtl_net {true | false}]: Dumps only RTL nets in the clock
tree report. Default: false. If you specify the -dump_rtl_net option, the
clock tree report will have user specified RTL nets only.

write_reset_tree
Description
Generates the Reset Tree report.
By default, VC SpyGlass CDC includes the asynchronous resets in the
report. Use the -type argument to specify the type of resets to be included
in the report.
The command generates the reset tree report with the
ResetAsyncTree.rpt name for asynchronous resets and with the
ResetSyncTree.rpt name for synchronous resets in the vcst_rtdb/
reports directory. You can specify a different file name by using the -file
option. VC CDC generates the report with the specified file name in the
current working directory.

746
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

The reset tree report include details of all the user-defined SDC primary
asynchronous or synchronous resets (depending on the -type). You can
specify a space-separated list of SDC reset names for which reset tree will
be included in the report.

Arguments
 -type <sync|async>: Specifies the type of resets to consider for report
generation. By default, VC SpyGlass CDC includes the asynchronous
resets.
 -file <filename>: Specifies the file name.
 -resets {space separated list of user-defined SDC resets}:
Specifies a space-separated list of SDC reset names for which reset tree
is generated.

write_resets
Description
Writes the reset table to a file in comma separated (.csv) file format.

Syntax
write_resets
-file {filename}

Arguments
 -file {filename}: Specifies the file name to which the reset table
should be written.

write_cdc_property
Description
The write_cdc_property command generates System Verilog Assertions.

747
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Syntax
write_cdc_property [<filename>]
[-types <list of types>]
[-simulator <list of simulators>]
Arguments
 [<filename>]: Select the destination file to write the properties in. By
default the properties are generated in the sva folder in the session
directory.
 [-types <list of types>]: Select types to generate properties for.
Available types are split in two categories and the default is to enable all
available types.
The following properties check specific characteristics of the design:
 datahold: Correctness of CDC data
 dataloss: CDC prone to data loss
 glitch: Glitches at CDC
 coherency: Combinational convergence of signals part of the same
CDC
 bus_coherency: Coherency issues in synchronized CDC to control
bus signals
 rdc_qualifier: Source reset in RDC asserts while not gated to the
destination
The following properties check the specified constraints:
 create_clock: Defines a clock
 create_rdc_static: Specifies source that will be ignored for RDC
analysis
 create_reset: Defines a reset
 create_static: Static signal in CDC
 define_reset_sequence: Specifies reset assertion sequence
 set_case_analysis: Specifies a net to be treated as a constant
 set_rdc_ignore_path: Specifies paths to be ignored for RDC
analysis

748
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

 [-simulator <list of simulators>]: Specify the simulator for which


you want to generate the properties. Default is vcs. The following
simulators are supported:
 - vcs: Generate properties for VCS simulator.
 - ncsim: Generate properties NCSIM/IUS simulator.
 - modelsim: Generate properties QUESTASIM/MODELSIM simulator.
 - vcf: Generate properties for VC Formal tool.
 - all: Generate properties for all the above simulators and VC Formal
tool

Examples
Generate all available properties in the session sva folder:
write_cdc_property
Generate properties only for coherency related types:
write_cdc_property -types {bus_coherency coherency}

set_seq_pin_map
Description
The set_seq_pin_map command defines the mapping between the pin
names specified in the user library and the synthesis library.

Syntax
set_seq_pin_map
-clock <clock-pin-list>
-data <data-pin-list>
-out <out-pin-list>
-preset <preset-pin-list>
-clear <clear-pin-list>

749
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 -clock <clock pin list>: Specifies the list of clock pin names.
 -data <data pin list>: Specifies the list of data pin names.
 -out <out pin list>: Specifies the list of out pin names.
 -preset <preset pin list>: Specifies the list of preset pin names.
 -clear <clear pin list>: Specifies the list of clear pin names.

generate_datasheet
Description
The generate_datasheet command generates datasheet for VC run.

Syntax
generate_datasheet
[- type < clocks | ports | all >]

Arguments
 [- type < clocks | ports | all >]: Enables the generation of
datasheet file for the specified type. Use this command to generate the
datasheet_clocks and the datasheet_ports report. This report
includes information about the clocks, such as name, tag, frequency,
domain, and so on. The reports are available in the vcst_rtdb/
datasheet/cdc/ directory. For example, use the following command to
generate the datasheet_clocks report:
generate_datasheet -type clocks
You can also specify -type all with the generate_datasheet command
to generate both the reports.

meta_design_hier
Description
Sets test bench design information needed for cdc jitter flow.

750
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Syntax
meta_design_hier
-name <design_name>
-inst <instance_name>

Arguments
 -name <design_name>: Specifies the design name.
 -inst <instance_name>: Specifies the test bench instance name.

Examples
To set the testbench instance tb.inst for the design test, use the
following command:
meta_design_hier -name test -inst tb.inst

meta_monitor_options
Description
Sets monitor option values required for the cdc jitter flow.

Syntax
meta_monitor_options
[-setup_hold_time <+ve integer>]
[-init_time <+ve integer>]
[-phase_shift_control <+ve integer>]
[-error_inject_threshold <float value>]
[-log_file <logfile>]
[-print_violation <yes|no>]
[-coverage_file_name <coveragefile>]
[-error_injection_type <DELAYED_ONLY |IMMEDIATE_ONLY |BOTH|
NONE>]

751
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

Arguments
 [-setup_hold_time <+ve integer>]: Specifies the setup hold time.
 [-init_time <+ve integer>]: Specifies the init time.
 [-phase_shift_control <+ve integer>]: Specifies the phase shift
control.
 [-error_inject_threshold <float value>]: Specifies the error
injection threshold.
 [-log_file <logfile>]: Specifies the log file.
 [-print_violation <yes|no>]: Specifies if to print violation
information during simulation.
 [-coverage_file_name <coveragefile>]: Specifies the coverage file
name.
 [-error_injection_type <DELAYED_ONLY| IMMEDIATE_ONLY| BOTH|
NONE>]: Specifies the error injection type.

Example
To set setup_hold_time and print_violation, use the folloaing command:
meta_monitor_options -setup_hold_time 4 -print_violation "yes"

generate_clock_reset_tree
Description
Propagates clocks or resets through the design and generates the data for
Clock/Reset Tree Browser.

Syntax
generate_clock_reset_tree
[-type <clock | reset>]

752
Synopsys, Inc. Feedback
Appendix A - Supported Commands

CDC Commands

Arguments
 [-type <clock | reset>]: Specifies if to generate clock or reset tree.
Default: clock.

set_ignore_attribute
Description
Ignores validation of the design objects on which this attribute is applied.
If multiple attributes are applied to the same object, the validation would
be performed for the other attributes applied on the object along with the
set_ignore_attribute attribute.
To check if the set_ignore_attribute attribute is applied to a pin/port,
use the is_ignore_attr_defined attribute. The
is_ignore_attr_defined attribute returns true if the
set_ignore_attribute attribute is applied to the pin/port.
For example, the is_ignore_attr_defined attribute returns true for a
pin/port if set_ignore_attribute is used for that pin/port as below:
define_attribute -name IGNR_PORTS -objects {in1}
set_ignore_attribute IGNR_PORTS
It will return false if the set_ignore_attribute attribute is not defined
on the given pin/port. It returns attribute not defined if used before
check_cdc is run.

Syntax
set_ignore_attribute
-<attribute name>

Arguments
 -<attribute name>: Specifies the name of the attribute element
defined by define_attribute.

Examples
The following example shows some usage of the set_ignore_attribute

753
Feedback Synopsys, Inc.
Appendix A - Supported Commands

CDC Commands

command:
set_constraints_scope -instance I1
define_cdc_attribute -name path1
set_ignore_attribute path1
apply_attribute path1 -objects {out1}

754
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Configure Commands

configure_cdc_glitch
Description
Configures glitch checking criteria.

Syntax
configure_cdc_glitch
[-multi_src_check_type none | unsync | data_path_full |
data_path_partial | ctrl_path_full | ctrl_path_partial | all]
[-reconv_check_type <none | unsync | data_path_full |
data_path_partial | ctrl_path_full | ctrl_path_partial |
all>]
[-glitch_type <data | reset | all>]
[-strict_glitch_analysis <none | xor| mux_all_zeros|
mux_all_ones| mux_mix_const | all>]
[-glitch_on_vck_port]
[-glitch_unate_analysis <true | false>]
[-ignore_among_signals ]
[-glitch_on_unconstrained_src]
[-glitch_on_sync_src]
[-reconv_after_blocking_gate]
[-dump_detailed_info <none|ctrlPath|unsync|all>]
[-unrelated <unrelated-list>]

Arguments
 [-multi_src_check_type none | unsync | data_path_full |
data_path_partial | ctrl_path_full | ctrl_path_partial |
all]: Specifies the types of sources that needs to be considered for

755
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

glitch detection in case of multiple sources. Default: ctrl_path_full


ctrl_path_partial. By default only control path glitch violations are
reported due to multiple sources. When set to none, the command does
not report glitch violations due to multiple sources.
 [-reconv_check_type <none | unsync | data_path_full |
data_path_partial | ctrl_path_full | ctrl_path_partial |
all>]: Specifies the types of sources that needs to be considered for
glitch detection in case of reconverging sources. Default:
ctrl_path_full ctrl_path_partial.
 [-glitch_type <data | reset | all>]: Specifies the glitch path
types that needs to be considered for glitch detection. Default: data.
 [-glitch_on_vck_port]: Enables checking for glitch on ports defined
by using the configure_cdc_port -control command.
 [-glitch_unate_analysis]: Enables reporting glitch violation for same
source re-convergence with same polarity. By default tool reports glitch
violations for only the reconverging paths with different polarity or if at
least one path has unknown polarity.
 [-ignore_among_signals ]: Specifies design objects which can be
source output pins, among which glitch due to multi-source convergence
should not be reported.
 [-glitch_on_unconstrained_src]: Enables checking for glitch on
unconstrained ports present in the input cone of a destination.
 [-glitch_on_sync_src]: Considers synchronous sources present in the
input cone of destination signal for glitch checking.
 [-reconv_after_blocking_gate]: Specifies whether to report glitch
due to reconvergence after the blocking gate of a data path glitch. By
default, glitches before blocking gate only are reported when data-path
glitch is running.
 [-strict_glitch_analysis <none | xor| mux_all_zeros|
mux_all_ones| mux_mix_const | all>]: Specifies if glitches due to
reconvergence of same source with mixed unateness are reported. By
default, the argument is set to none. Set the parameter to one of the
following values to enable the supported tags to report such glitches:
 xor: Reports glitches due to reconvergence of same source with
mixed unateness for xor gates.

756
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 mux_all_zeros: Reports glitches due to reconvergence of same


source through mux select even if all mux-inputs are tied to 0.
 mux_all_ones: Reports glitches due to reconvergence of same
source through mux select even if all mux-inputs are tied to 1.
 mux_mix_const: Reports glitches due to reconvergence of same
source through mux select even if all mux-inputs are tied to 1 or 0.
 all: Reports glitches due to reconvergence of same source with
mixed unateness for both mux and xor gates.
 [-dump_detailed_info <none|ctrlPath|unsync|all>]: Enables
reporting of violation details in Clock-Reset-All-Rules.rpt report.
Default: none.
 [-unrelated <unrelated-list>]: Specifies the signals for which glitch
related violations should not be reported.

When to Use
You can use this command to report unsync/data path glitch violation due
to multiple sources. If you want that glitch violation for same source re-
convergence with same polarity should be reported, use this command.
You can also use this command to remove glitch violations reported due to
multiple sources.
Consider below schematic. Here, q1 and q2 are different domain sources.
Both the sources converged at the and gate and reach to destination flop
out. The CDC_GLITCH_UNSYNC violation reported between sources q1 and
q2 and destination out. By default, this violation is not reported, to report
this violation use the following command:
configure_cdc_glitch -multi_src_check_type unsync
Here, unsync argument shows that it only reports unsync glitch violation
due to multiple sources. Use argument all to report all kind of glitch
violations due to multiple sources.

757
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Consider below schematic. Here there is glitch violation reported due to


source IP1(8).instance3/out1_reg/Q and IP1(8).instance1/out1_reg/Q. If
you want that below glitch violation is not reported, use the following
command:
configure_cdc_glitch -ignore_among_signals { instance1_8/out1
instance3_8/out1 }.

Consider below schematic. Source t1 and t3 are converging at and gate


and reaching to the port out2. Here domain is associated with port out2. If
you want that glitch violation should be reported considering out2 port as

758
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

destination, use command configure_cdc_port -control out2 so that


glitch violation should be reported at port out2.

Consider below schematic. Here, both path starting from flop output q1 are
identical except one thing that one path have a buffer. Since buffer does
not change the polarity of the signal hence no glitch violation is reported by
default.
If you want that such scenarios are reported then use the following
command:
configure_cdc_glitch -glitch_unate_analysis

Consider below schematic. Here, an unconstrained port in2 merges with


source r1 before going to the destination r2. By default, no glitch is

759
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

reported for this scenario.


If you want that such scenarios are reported, use the following command:
configure_cdc_glitch -glitch_on_unconstrained_src

configure_cdc_port
Description
Specifies the inout/output port(s) that will be connected to a control
synchronizer.
Glitch analysis is performed on a crossing, if the port specified with the -
control argument of this command is a destination of the crossing.

Arguments
 [-control <port_names>]: Specifies the port(s) to be connected to a
synchronizer.
For example, consider the following schematic:

760
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

//SDC file
create_clock -name vck1
set_output_delay -name out4 -

In this case, to perform glitch analysis on the out4 port, use the following
command:
configure_cdc_port -control out4

configure_cdc_power_aware
Description
Considers isolation latch cell as sequential or combinatorial.

Arguments
 [-isolation_latch <comb | latch>]: Consider isolation latch cell as
sequential or combinatorial.

configure_cdc_reason_code
Description
Sets the type of CDC reason code.

761
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Arguments
 -code <reason_code>: Specify the reason code.
 [-type <full | partial>]: Specify the type.
 [-hide]: Hides reason code information in report.
 [-unhide]: Shows reason code information in report.

configure_cdc_static
Description
Configures quasi-static signals for CDC analysis.

Syntax
configure_cdc_static
[-prop_num_sequential < 0 | 1>]

Arguments
 [-prop_num_sequential <0 | 1 >]: Allows quasi static signal to
propagate beyond sequential elements. The default value is 0. By
default, the quasi static signals do not propagate beyond sequential
elements.

When to Use:
By default, quasi static signals are propagated until the first sequential
element is encountered. For enabling propagation of quasi static signal
beyond sequential elements, use the following command:
configure_cdc_static -prop_num_sequential 1
For example, consider the schematic below :

762
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Here clk1, clk2 and clk3 are asynchronous to each other and in is a quasi
static signal (A signal can be defined as quasi static through the constraint
create_static). By default VC Spyglass will report
SYNCCDC_IGNOREPATH_QUASI_STATIC for the crossing between reg1 and
reg2 and report SYNCCDC_UNSYNC_NOSCHEME for the crossing between
reg2 and reg3.
In the schematic below, observe that the property panel of the highlighted
net does not report the net as quasi static.

763
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

For propagating quasi static signal in beyond sequential elements we can


give the above-mentioned command (configure_cdc_static -
prop_num_sequential 1). In this case VC Spyglass will report
SYNCCDC_IGNOREPATH_QUASI_STATIC for the crossing between reg1 and
reg2, as well as between reg2 and reg3.
In the schematic below observe that the property panel of the highlighted
net reports the net as quasi static.

configure_ip_block
Description
Configures the modules for which CDC, RDC and ResetAsync analysis
needs to be turned OFF.

764
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Syntax
configure_ip_block
-names <module-list>
[-type < rdc | cdc | asyncreset >]
[-skip_cdc_analysis < true|false >]
[-report < sync | conv | glitch >]

Arguments
 -names <module-list>: Defines the list of modules or cells for which
crossing analysis needs to be turned OFF
 [-type < rdc | cdc | asyncreset >]: Defines the type of application
for which crossing analysis needs to be turned off. The default value is
rdc.
 [-skip_cdc_analysis < true|false >]: Skips CDC analysis on the
specified IP blocks. Default value is false.
 [-report < sync | conv | glitch >]: Specifies the use of the
specified IP blocks in the -names option to generate the IP block reports
in violations for specified checks. The new value of this option overrides
the previous values.

configure_cdc_tag
Description
Displays and configures CDC violation tags.

Arguments
 [-tag <tag list>]: Defines the tag(s) operated on.
 [-stage <stage list>]: Apply tag alternations to the entire group(s):
Values: all, conv, glitch, setup, struct, sync.
 [-enable]: Enables the tag(s).
 [-disable]: Disables the tag(s).
 [-severity <error|warning|info>]: Sets the tag(s) severity level.

765
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-clear]: Restores all tags to their original state.


 [-tcl]: Displays changes to the CDC tag set in a Tcl format suitable for
replay.
 [-regexp]: Allows regexp expressions in the tag list.
 [-all]: Displays all messages, even with default enable and severity
status.
 [-verbose]: Displays short description for each message.

Examples
To get list of all tags
configure_cdc_tag -all -verbose > all_tags.list
To enable all the tags, use
configure_cdc_tag -tag * -enable
To promote a set of checks from severity warning to ERROR
configure_cdc_tag -tag {STRUCT_CONV_SYNC_SIGNALS} -severity
error

configure_libcell_uniquification
Description
Configures libcell uniquification.

Arguments
 [-skip_sequential]: Skips uniquification of all sequential elements.
 [-skip_module <libcell-list>]: Skips uniquification of all instances
of the specified libcell.
 [-skip_instance <libcell-instance-list>]: Skips uniquification of
the specified instances.

configure_glitch_free_cells

766
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Description
Configures cells to control pessimism in glitch analysis.

Syntax
configure_glitch_free_cells
[-ignore_instances <instance_list>]
[-ignore_modules <module_list>]
[-types <NONE | BBOX | COMPARE | XOR | MUX>]
[-path_type <path_type>]
[-add]

Arguments
 [-ignore_instances <instance_list>]: Ignores the cell in the
specified instance.
 [-ignore_modules <module_list>]: Ignores the cells of the specified
module.
 [-types <NONE | BBOX | COMPARE | XOR | MUX>]: Ignores the cells of
the specified types. Default: NONE.
 [-path_type <path_type>]: Specifies the type of path where the
specified module is considered glitch free. Supported path type is clock
only.
 [-add]: It is a dependent switch of the -type switch. When you specify -
add switch to the configure_glitch_free_cells command, the value
of the -types switch is added to the existing cell value list.

Example:
configure_glitch_free_cells -types XOR -add
As the -add switch is specified here, the XOR value is added to the glitch
free cell list BBOX, COMPARE.
configure_glitch_free_cells -types BBOX
Here, the glitch free cell types list is overridden with BBOX value because -
add switch is not specified.

767
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Consider the following schematic:

Here, the configure_glitch_free_cells command does not report


reconvergence glitch violation at the converging gate I_XOR_mout if -types
switch is provided with XOR value before glitch run.

When to Use:
You can use this command to remove glitch violation due to single source
diverge, converge only. this command will not remove glitch violation
reported due to multiple sources.
Consider below schematic here source flop q1 output first diverges and
converges at mux I_MUX_w3 via data input D1 and select line SEL. there is
glitch violation between source flop q1 and destination flop mem. We can
remove this glitch violation using this command because this violation is
due to single source diverge and converge.

768
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

To remove this violation, use the configure_glitch_free_cells -


ignore_instances m1 command, where m1 is the name of instance for
which this command will ignore all glitch violation that are due to cells
present in instance m1.
To remove above violation, you can give module name also instead of
instance name. To remove above violation, use
configure_glitch_free_cells -ignore_modules memory. Here, memory
is module name. This command removes all the glitch violations due to
cells present in instances of module memory. Note that m1 is an instance
of the module memory.
Use this command to remove glitch violation due to single source diverge and
converge only. This command will not impact any glitch violation reported due to
multiple sources.

configure_cdc_internal_crossing
Description
Enables crossings on the source clock pin and the destination clock pin of
the specified libcell.

Syntax
configure_cdc_internal_crossing
-src_clk_pin <source_clock_pin>

769
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

-dest_clk_pin <destination_clock_pin>
-libcell_inst <libcell_instance_name>
[-tag
<SYNCCDC_IGNORE_INTERNAL_CROSSING|SYNCCDC_CTRLPATH_FULL|SYNC
CDC_CTRLPATH_PARTIAL|SYNCCDC_DATAPATH_FULL|SYNCCDC_DATAPATH_
PARTIAL|SYNCCDC_UNSYNC_NOSCHEME>]
(Default:SYNCCDC_UNSYNC_NOSCHEME)

Arguments
 -src_clk_pin <source_clock_pin>: Specifies the source clock pin name.
 -dest_clk_pin <source_clock_pin>: Specifies the destination clock pin
name.
 -libcell_inst <libcell_instance_name>: Specifies the library cell instance.
 [-tag <SYNCCDC_IGNORE_INTERNAL_CROSSING|
SYNCCDC_CTRLPATH_FULL| SYNCCDC_CTRLPATH_PARTIAL|
SYNCCDC_DATAPATH_FULL| SYNCCDC_DATAPATH_PARTIAL|
SYNCCDC_UNSYNC_NOSCHEME>]: Specifies the tags for reporting.

When to Use:
By default, the tool does not report internal crossings of libcell. This
command provides a way to report such crossings.
Consider the following schematic. This is the internal structure of a libcell
and there can be a crossing if CLK1 and CLK3 are asynchronous. To report
this crossing between CLK1 and CLK3, use the following command:
configure_cdc_internal_crossing -src_clk_pin CLK1 -dest_clk_pin
CLK3 -libcell_inst qual_nff -tag
SYNCCDC_IGNORE_INTERNAL_CROSSING

770
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

In this case, CLK1 pin of libcell is reported as IGNORE_PATH_SRC and CLK3


pin of libcell is reported as IGNORE_PATH_DST and violation tag is reported
as SYNCCDC_IGNORE_INTERNAL_CROSSING.

configure_cdc_crossing

771
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Description
Enables various configurations on crossing generation, such as disable
complex seq/primary ports as crossing start/end points or per domain limit
of start points.

Syntax
configure_cdc_crossing
[-disable_complex_seq]
[-disable_complex_iopad]
[-show_progress_per_crossing_count]
[-per_domain_start_points_limit]
[-skip_domains]
[-disable_icg_cell]
[-disable_clock_source_crossing <true|false>|
seq_out>]
[-disable_reset_source_crossing]
[-reset_cross_seq]
[-disable_const_source]
[-through_const_enable_latch <data |async_pin|
async_pin_priority >]
[-dump_detailed_info <none|src_seq_driver>]
[-enable_ignore_path_hier_view]

Arguments
 [-disable_complex_seq <true | false>]: Do not consider complex
seq as start/end points of a crossing. Default: false.
 [-disable_complex_iopad <true | false>]: Do not consider iopad as
start/end points of a crossing Default: false.
 [-show_progress_per_crossing_count]: Show crossing generation
progress report per crossing count. Default: 100000)

772
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-per_domain_start_points_limit]: Limits count of sequential


elements for crossing start points for each domain to be considered for
crossing generation. Default: 0.
 [-skip_domains]: specifies list of destination domain ids which are to
be skipped for crossing generation
 [-disable_icg_cell <true | false >]: Do not consider ICG cell as
source of a crossing. Default: false.
 [-disable_clock_source_crossing <true | false> | seq_out>]:
Disables identification of crossings whose source is a clock port. Default:
false. Set the value of the disable_clock_source_crossing
argument to seq_out to infer the data path domain of the output pin of
the sequential element based on the user-defined clocks reaching the
clock pin of the sequential element. In addition, any user-specified
create_clock or create_generated_clock constraints is not
considered for determining the data path domain of the output pin of
the sequential element.
 [-disable_reset_source_crossing]: Disables identification of
crossings when reset sdc command is specified on any object in the
crossing path. Default: false.
 [-reset_cross_seq]: Enables crossings from the asynchronous reset
pins of the library cells. Default: false.
 [-disable_const_source]: Disables reporting of crossings having
constant input source even if reset/set can cause metastability. Default:
false.
 [-through_const_enable_latch <data |async_pin|
async_pin_priority >]: Enables generation of crossings through the
data/set/reset pins of a latch when the enable pin of the latch is tied to
active value.
 When set to data, crossings are generated through the data pin of
the latch. This is the default value.
 When set to async_pin, crossings are generated through both set
and reset pins of the latch.
 When set to async_pin_priority, crossings are generated through
either set or reset pin based on priority logic.
You can specify multiple valid inputs with the -
through_const_enable_latch argument. For example, to generate

773
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

crossings through set and reset pins as well as data pin of the latch, set
the through_const_enable_latch argument to async_pin data.
NOTE: The argument controls only crossing generation for libcell/db latches. RTL
latches are not controlled by this argument.
 [-dump_detailed_info <none|src_seq_driver>]: Enables reporting
of sequential drivers for crossing start point. Default: none.
 [-enable_ignore_path_hier_view]: Enables support for hierarchical
terminals in SGUM for the cdc_false_path constraint. By default, VC
SpyGlass supports hierarchical terminal for this constraint and therefore
this option is not needed in the default VC flow. Default: false.

When to Use:
Use this command to match VC SpyGlass behavior with the behavior of
other tools, such as match VC SpyGlass behavior with PT behavior.
Consider below schematic here the source of crossing is a clock gating cell
if user want this crossing should not be reported then use command
configure_cdc_crossing -disable_icg_cell true.

Consider below schematic here at output of i_clk_anda_1 gate generated


clock constrained is applied hence there is CDC_CLOCK_TO_D_CROSSING
between source i_clk_anda_1 and destination PIXCLK. If user wants to
remove this crossing, use configure_cdc_crossing -
disable_clock_source_crossing true.

774
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

configure_property_panel
Description
Configures the data shown in the schematics property panel

Syntax
configure_property_panel
[-name <show|hide>]
[-object <show|hide>]
[-add <attribute_name>]
[-remove <attribute_name>]

Arguments
 [-name <show|hide>]: Show or hide the clock/reset name. Default
value: show. By default, it will show the clock/reset name.
 [-object <show|hide>]: show or hide the clock/reset object. Default value:
show. By default, it will show the clock/reset object.

775
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-add <attribute_name>]: Add a custom attribute (which would be


obtained with "get_attribute" in TCL).
 [-remove <attribute_name>]: Remove a custom attribute.

When to Use:
Only a limited number of properties to user in property panel is visible.
sometimes user often wanted to see a particular property/attribute.this
command can solve this problem, you can use this command to represent
his/her property in schematic property panel.this command is mainly used
to show user defined attributes in schematic property panel.
Consider below example.
set_attribute -type int -class cell [get_cells *] property_1
10
configure_property_panel -add property_1
This command sets a value of 10 to each cell. If you want this information
is shown in the schematic property panel, use the second command.
Consider the following schematic, where genblk1[23].f1 is a cell. When you
click this cell, the Customized Attributes field in property panel is displayed
which displays the property_1 attribute and its value 10.

776
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Use the report_attribute -attributes <user defined attribute


name> -summary -class <class name> <class-object> command to
see class objects and their values for given user define attributes. For
example, the following command provides the list:
report_attribute -attributes property_1 -summary -class cell
[get_cells *]
Object property_1
genblk1[2].f1 10
genblk1[1].f2 10
genblk1[1].f1 10
genblk1[0].f2 10
genblk1[0].f1 10
……………………………..
Use the get_attribute <object-name> <attribute-name> command to
get value of attribute for given object.
The get_attribute genblk1[2].f1 property_1 command gives you
value of property_1 attribute for object genblk1[2].f1 which is 10.

configure_cdc_smart_netlist
Description
Set up and configure the CDC Smart Netlist checks. CDC Smart Netlist
checks contain RTL CDC/SDC constraint translation to Netlist equivalent,
RTL CDC waiver translation to Netlist equivalent and differential analysis
between the RTL and Netlist design violation database.
You can specify the mapping file generated from Siloti/Formality to provide
the mapping between RTL and Netlist signals. In addition, you can specify
the type of CDC RTL violations that need to be reported at Netlist.

Syntax
configure_cdc_smart_netlist
[-flow_type

777
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

all|constraint_translation|waiver_translation|diff_analysis]
[-auto_perform
all|load_constraint|load_waiver|diff_analysis]
[-diff_ref_run]
[-obj_translation_scope allow_hierport|none]
[-diff_field_priority]
[-include_rtl_viol all|only_rtl|same_as_rtl|none]
[-dump_unmapped_obj TRUE|FALSE]
[-crdb_file]
[-siloti_map_file]
[-formality_map_file]

Arguments
 [-flow_type
all|constraint_translation|waiver_translation|diff_analysis]
: Specify the type of flow to be enabled. This option should be used in
RTL run only. To perform only constraints or waivers translation, set the
value of this argument to constraint_translation or
waiver_translation accordingly. VC SpyGlass CDC checks are not
performed in this case.
To perform only differential analysis between RTL and Netlist design
violation database, set the value to diff_analysis. In this case, CDC
checks are performed and RTL design database is created for differential
analysis during Netlist run. To perform translation for both RTL
constraints and waivers as well as perform differential analysis at
netlist, set the value of this argument to all.
 [-auto_perform
all|load_constraint|load_waiver|diff_analysis]: Use this option
to specify what should be performed. This option should be used in
Netlist run only. To perform auto loading of translated constraints or
waivers generated in RTL run, set value to load_constraint or
load_waiver respectively. To perform only differential analysis between

778
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

RTL and Netlist design violation database, set the value to


diff_analysis. By default, all is performed.
 [-diff_ref_run]: Specify the RTL design database directory with which
the Netlist design database needs to be compared. This option need to
be used in Netlist run only. This option is mandatory for performing
violation database comparison at Netlist.
 [-obj_translation_scope allow_hierport|none]: Generates
mapping for hierarchical ports for which mapping is missing in the
mapping file. This option should be used in RTL run only. By default, for
unmapped objects, additional traversal is not performed (except for
hierarchical ports) to check if mapping can be retrieved. Default value is
none.
 [-diff_field_priority]: Specifies the path of the XML file containing
the priority of debug fields. This option need to be used in Netlist run
only. VC SpyGlass CDC uses the default configure_smartnetlist.xml
file. You can use this option to override the default XML file.
 [-include_rtl_viol all|only_rtl|same_as_rtl|none]: Specifies
the type of CDC RTL violations that need to be reported in Netlist run.
This option need to be used in Netlist run only during differential
analysis. By default both only_rtl and same_as_rtl category violations
are filtered and not reported in Netlist run. To disable filtering, set the
value to all.
 [-dump_unmapped_obj TRUE|FALSE]: Generates unmapped objects
with their original name as mapped name. This option should be used in
RTL run only. By default, the argument is set to false and unmapped
objects are generated as unmapped signals only. When set to true, the
original name of the unmapped signal is generated as the mapped
name.
 [-crdb_file]: Specifies the Siloti-generated crdb file to generate
enhanced mapping and improved QOR at Netlist run. This option should
be used in RTL run only.
 [-siloti_map_file]: Specifies the Siloti mapping file. This option
should be used in RTL run only.
 [-formality_map_file]: Specifies the Formality mapping file
generated in Siloti style. This option should be used in RTL run only.

779
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Examples
 To generate translated constraints and waivers:
configure_cdc_smart_netlist -flow_type
{constraint_translation waiver_translation} -siloti_map_file
map.gz
 To perform differential analysis at Netlist and auto-load the translated
constraint and waiver files generated at RTL:
configure_cdc_smart_netlist -diff_ref_run rtl_results_dir
 To perform only differential analysis at Netlist and disable auto-loading
of the translated constraint and waiver files generated during RTL:
configure_cdc_smart_netlist -diff_ref_run rtl_results_dir -
auto_perform diff_analysis

configure_cdc_integrity_checks
Description
Enables integrity checks based on user inputs.

Syntax
configure_cdc_integrity_checks
[-clock_race_thru_latch]
[-clockgate_enable_glitch]
[-reset_deassert_value_as_sca]
[-report_all_flops <none|syncAsyncResetUsage>]
[-report_derived_reset <none|syncAsyncResetUsage>]
[-dump_detailed_info <none|asyncRstComboMux|all>]
[-report_detail <none|clockAsNonClock|all>]

Arguments
 [-clock_race_thru_latch]: Enables the
INTEGRITY_CLKRST_OUTPUT_RACE tag to report a violation. This
argument enables the propagation of clocks beyond the sequential

780
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

elements or prohibits propagation through latches. By default, the


argument is set to false.
 [-clockgate_enable_glitch]: Enables the
INTEGRITY_CLKGATE_GLITCH tag to report if latch data is undriven or
constant. By default, the argument is set to true.
 [-reset_deassert_value_as_sca]: consider other sync resets act as
set_case_analysis in its de-assert value to block the validating reset
while validating active high and active low usage in synchronous reset
for INTEGRITY_SYNCRESET_HIGH_AND_LOW_USAGE tag. Default value
is false.
 [-report_all_flops <none|syncAsyncResetUsage>]: Enables
generation of a csv file for other sequential elements that are not
reported by the INTEGRITY_RESET_ASYNC_AND_SYNC_USAGE tag.
The tool generates one csv per reset with the reset name. Default value
is none.
 [-report_derived_reset <none|syncAsyncResetUsage>]: Specifies if
the INTEGRITY_RESET_ASYNC_AND_SYNC_USAGE tag should report
for asynchronous derived resets. Default value is none.
 [-dump_detailed_info <none|asyncRstComboMux|all>]: Enables
reporting of all drivers of combo logic, such as primary inputs, library-
cell, black box, flop, latch, CGC in fanin of combo logic for
INTEGRITY_ASYNCRST_COMBO_MUX violation. The default value is
none.
 [-report_detail <none|clockAsNonClock|all>]: Specifies if all
violations should be reported for each clock or only one violation should
be reported per clock for the INTEGRITY_CLOCK_AS_NON_CLOCK tag.
Valid values include none | clockAsNonClock | all. The default value
is all.

When to Use:
Use this command to enable the INTEGRITY_CLKRST_OUTPUT_RACE tag
and the INTEGRITY_CLKGATE_GLITCH tag to perform integrity checks.

configure_cdc_asyncrst_crossing

781
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Description
Configures crossing detection on asynchronous reset paths.

Syntax
configure_cdc_asyncrst_crossing
[-allow_unconstrained_reset_in_rip < true | false >]

Arguments
 [-allow_unconstrained_reset_in_rip]: Configures if a reset path
crossing is ignored if an unconstrained reset source object is specified in
the from_rst argument of the set_asyncrst_ignore_path command.
By default, the argument is set to false.

When to Use:
Use this command to report a reset path crossing if an unconstrained reset
source object is specified in the from_rst argument of the
set_asyncrst_ignore_path command.

configure_cdc_asyncrst_data_sync
Description
Configures the criteria for detecting reset path synchronization schemes.

Syntax
configure_cdc_asyncrst_data_sync
[-from_clock < src-clk >]
[-to_clock < dest-clk >]
[-from_obj < src-obj >]
[-to_obj < dest-obj >]
[-to_obj_types]
[-skip_sync]
[-skip_autoqual]

782
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

[-des_qual < pin | port | net >]


[-des_qual_depth < integer value >= -1 >]
[-ignore_des_qual < pin | port | net >]
[-incr]
[-sync_point_cell <module-list>]
[-dual_qual_reqd]
[-validate_on_domain]
[-des_enable_expr < expression string >]
[-des_enable_expr_validate < obj_reachable |
obj_data_domain | obj_exist | dynamic_stimulation |
disable >]
[-blocking_gate_instances < module/lib-cell instances >]
[-blocking_gate_modules < modules >]
[-enable_autoqual]
[-allow_merged_qualifier]
[-sync_point_qualifier <first, all>]
[-sync_point_select <none, first, last, all,
user_defined>]
[-sync_point_report_limit <value>=-1>]
[-sync_check_type < qual_only, enable_with_qual,
enable_with_dest_domain>]
[-sync_point < and, mux_select, mux_recirc, clock_gate,
sync_point_cell, and_or_mux_recirc>]
[-analyze_async_sources < true | false >]
[-dynamic_side_channel < true | false >]
[-allow_qual_prop_across_dest < true | false >]
[-allow_cascaded_cgc < true | false >]
[-allow_qual_thru_cgc_gen_clock < true | false >]
[-allow_sync_clocks_qual < true | false >]
[-enable_syncpoint_reporting < true | false >]
[-allow_reset_domain_qual < true | false >]

783
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

[-allow_all_syncpoint_for_user_qual < true | false >]


[-enable_deassertion_checks < true | false >]

Arguments
 [-from_clock < src-clk >]: Specifies the list of clocks on the source
of the data crossings
 [-to_clock < dest-clk >]: Specifies the list of clocks on the
destination of the data crossings
 [-from_obj < src-obj >]: Specifies the list of source objects of the
data crossings
 [-to_obj < dest-obj >]: Specifies the list of destination objects of the
data crossings
 [-to_obj_types]: Specifies the types of destination of crossing for
which sync analysis needs to be skipped. This option can only be
specified in conjunction with the skip_sync argument.
 [-skip_sync]: It disables the auto detection of data synchronizers
 [-skip_autoqual]: It disables the auto detection of qualifiers
 [-des_qual < pin | port | net >]: It specifies the qualifier signal
which blocks the source of data crossing
 [-des_qual_depth < integer value >= -1 >]: It specifies the
maximum valid sequential depth of a qualifier. Default value is 0.
 [-ignore_des_qual < pin | port | net >]: It specifies the
synchronizers that are not allowed as qualifiers
 [-incr]: It disables the creation of new qualifiers on the output of cells
specified by -des_qual if an auto detected qualifier is not found
 [-sync_point_cell <module-list>]: It specifies modules or cells that
are valid for blocking condition
 [-dual_qual_reqd]: It allows user to specify that both source and
destination qualifier are required to synchronize data crossing
 [-validate_on_domain]: Allows validation of the user-specified
constraint on domains if provided with from_clock and to_clock instead
of clocks
 [-des_enable_expr < expression string >]: It specifies the enable
expression signal which enables the source of data crossing

784
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-des_enable_expr_validate < obj_reachable | obj_data_domain


| obj_exist | dynamic_stimulation | disable >]: It specifies the
type of validation to be performed on the specified enable expression.
 obj_reachable (default value): Objects Specified in expression
must exist in design, must be present in Destination Domain and
atleast one of those objects should reach destination within the
sequential depth specified by '-des_qual_depth'.
 obj_data_domain: Objects Specified in expression must exist in
design and must be present in Destination Domain. If the above two
criteria are specified, the crossing is marked synchronized by the
user specified expression.
 obj_exist: Only existence of Objects in the design is verified, if
objects are present, crossing is marked synchronized by the user
specified expression.
 disable: No validation on the expression is performed and crossing
is marked synchronized by the user specified expression
 [-blocking_gate_instances < module/lib-cell instances >]:
Specifies the list of module or library cell instances, the blocking gates
of which can use auto-inferred qualifiers for synchronization analysis
within the specified des_qual_depth.
 [-blocking_gate_modules < modules >]: Specifies the list of
modules, the blocking gates of which can use auto-inferred qualifiers for
synchronization analysis within the specified des_qual_depth.
 [-enable_autoqual]: Configures if the auto-inferred qualifiers are
allowed for synchronization analysis on the blocking gate that are in the
hierarchy of the modules/instances specified by using the
blocking_gate_modules or the blocking_gate_instances arguments.
 [-allow_merged_qualifier]: gate at which source and the qualifier
merges act as a new qualifier for other sources
 [-sync_point_qualifier <first, all>]: When set to all, all the
qualifier that can block the source on a blocking gate are reported.
Default: first
 [-sync_point_select <none, first, last, all, user_defined>]:
Specifies the location priority of the blocking gate with respect to source
node of a crossing. Default: none

785
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-sync_point_report_limit <value>=-1>]: Specified the maximum


number of blocking gates on which source can be blocked. Default: 5
 [-sync_check_type < qual_only, enable_with_qual,
enable_with_dest_domain>]: Specifies the type of synchronizer check
to be performed.Default: qual_only
 [-sync_point < and, mux_select, mux_recirc, clock_gate,
sync_point_cell, and_or_mux_recirc>]: Defines legal
synchronization points for blocking condition detection. Default: {and or
mux_select mux_recirc clock_gate sync_point_cell cdc_crossing }
 [-analyze_async_sources < true | false >]: Configures if
synchronization checks need to be performed for asynchronous sources
of different clock domains converging at the same point. Default: false.
 [-dynamic_side_channel < true | false >]: Configures if
deterministic gates in merged qualifier path with other inputs in
destination domain are to be treated as buffers for dynamic sync
analysis. This option is applicable only when the
enable_sync_dynamic_analysis application variable is set to true.
Default: true.
 [-allow_qual_prop_across_dest < true | false >]: When set to
true, qualifiers are propagated across destination of crossing, to
perform synchronization analysis on other crossings. Crossings that are
analyzed by such qualifiers are reported with the
QUALIFIER_PROPAGATED_ACROSS_DEST reason code. Default: false.
 [-allow_cascaded_cgc < true | false >]: Configures if cascaded
clock gating cells are to be allowed during clock gate synchronization
scheme. Only cascaded lib-cell clock gate cells are supported in this
argument. Default: false.
 [-allow_qual_thru_cgc_gen_clock < true | false >]: Allows
qualifiers to be propagated through CGC cells, on the output of which
generated clocks synchronous to destination domain are defined.
Default: false.
 [-allow_sync_clocks_qual < true | false >]: Allows
synchronization checks on qualifiers that are driven by clocks
synchronous to the destination. Default: false.
 [-enable_syncpoint_reporting < true | false >]: Enables the
reporting of blocking gate information for data-path synchronized
violations. Default: false.

786
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-allow_reset_domain_qual < true | false >]: Allows the qualifier


with same reset domain as that of the async reset path crossing when
set to true. When set to false, the source of crossing and source of
qualifier must be the same. Default: true.
 [-allow_all_syncpoint_for_user_qual < true | false >]: When
set to true, all types of sync gates are considered valid for user-
specified qualifier. Default: true.
 [-enable_deassertion_checks < true | false >]: Configures if
deassertion analysis should be performed for reset path crossings. Set
the value to false to skip deassertion analysis is for reset path
crossings. Default: true.

Example:
configure_cdc_asyncrst_data_sync -des_qual qual_obj -
from_clock clk1 -to_clock clk2 -des_qual_depth 4 -
allow_merged_qualifier
configure_cdc_asyncrst_data_sync -from_obj o1 -to_obj o2 -
des_qual qual_obj
configure_cdc_asyncrst_data_sync -skip_sync
configure_cdc_asyncrst_data_sync -des_enable_expr "o1&o2" -
from_clock c1 -des_enable -expr_validate dynamic_simulation

configure_cdc_asyncrst_nff_sync
Description
Configures the reset path multi-flop synchronizers detection criteria.

Syntax
configure_cdc_asyncrst_nff_sync
[-from_clock < src-clk >]
[-to_clock < dest-clk >]
[-from_obj < src-obj >]
[-to_obj < dest-obj >]

787
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

[-to_obj_types]
[-skip_sync ]
[-depth < value >= 1 >]
[-allowed_modules]
[-uds_modules]
[-ignore_multi_domain_sources < yes | no >]
[-allow_quasi_static < yes | no >]
[-allow_latch < destination | flop_chain | none >]
[-allow_half_sync <unset | yes | no | strict >]
[-allow_diff_clk_period <true | false >]
[-detect_potential_synchronizers <yes | no >]
[-suppress_unobservable <sync>]
[-strict]
[-remove_redundant_logic <true | false >]
[-allow_parallel_synchronizers <true | false>]
[-auto_detect_sync_cell <none | all | single_output >]
[-data_pin_connectivity
<tied_0|tied_1|same_as_async|no_check >]
[-filter_unused_synchronizer < true | false >]
[-allow_pulse_synchronizer < true | false >]
[-allow_diff_clock_net < true | false >]
[-detect_full_chain < true | false >]
[-same_hier_level < int >]
[-allow_quasi_gate_in_chain < true | false >]
[-allow_asyncrst_gate_in_chain < true | false >]
[-allow_buf_equiv_logic < true | false >]
[-detect_insufficient_depth_nff < true | false >]

788
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Arguments
 [-from_clock < src-clk >]: Specifies the list of clocks on the source
of the control crossings.
 [-to_clock < dest-clk >]: Specifies the list of clocks on the
destination of the control crossings.
 [-from_obj < src-obj >]: Specifies the list of source objects of the
control crossings.
 [-to_obj < dest-obj >]: Specifies the list of destination objects of the
control crossings.
 [-to_obj_types]: Specifies the types of destination of crossing for
which sync analysis needs to be skipped. This option can be specified
only in conjunction with skip_sync.
 [- skip_sync ]: It disables the auto detection of multi-flop
synchronizers.
 [-depth < value >= 1 >]: Specifies the sequential depth to be
considered as valid multi-flop synchronizer. Default value: 2.
 [-allowed_modules]: Restricts NFF synchronizer detection to specified
modules. The uds_modules and the allowed_modules arguments
cannot be specified in the same command. In addition, if the
uds_modules and the allowed_modules arguments are specified on the
same module, the constraint that is specified later is honored.
 [-uds_modules]: Specifies user synchronizer cells and libraries. The
uds_modules and the allowed_modules arguments cannot be specified
in the same command. In addition, if the uds_modules and the
allowed_modules arguments are specified on the same module, the
constraint that is specified later is honored.
 [-ignore_multi_domain_sources < yes | no >]: Setting it to true
will consider a destination for multi-flop synchronizer detection, even if
multiple domains srcs are driving the destination. Default: yes.
 [-allow_quasi_static < yes | no >]: Allows combinational logic
between the synchronizer flip-flops if the combinational logic is probable
buffer path as side inputs are quasi-static. Default: no.
 [-allow_latch < destination | flop_chain | none >]: Default:
flop_chain.

789
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 destination: allows latch only as destination of the crossings for


NFF detection.
 flop_chain: allows all latchs in multi-flop synchronizer chain for NFF
detection.
 none: no latches are allowed in the multi-flop chain for NFF detection.
 [-allow_half_sync <unset | yes | no | strict >]: Default: unset
 yes: Considers flops with inverted poplarity in the multi-flop chain as
depth 1.
 no: Considers flops with inverted polarity in the multi-flop chain has
0.5.
 strict: Does not allow flop (latch) with inverted (same) polarity in
the multi-flop chain.
 [-allow_diff_clk_period <true | false >]: When set to false,
different clock periods for destination and synchronizer flops are not
allowed. Default: true.
 [-detect_potential_synchronizers <yes | no >]: Detect potential
synchronizers in allowed modules. Default: no.
 [-suppress_unobservable <sync>]: Type of crossings required to be
suppressed.
 [-strict]: Type of method to detect unobservable object.
 [-remove_redundant_logic <true | false >]: Reduce redundant
logic in nff chain. Default: true.
 [-allow_parallel_synchronizers <true | false>]: Allow nffs which
have parallel synchronizer flops after destination to be marked as valid
synchronizer structures. Default: false.
 [-auto_detect_sync_cell <none | all | single_output >]: Type
of libcell inside which NFF detection needs to be done. Default: none.
 [-data_pin_connectivity
<tied_0|tied_1|same_as_async|no_check >]: Configuration for
connectivity of data pin of a valid synchronizer.
 [-filter_unused_synchronizer < true | false >]: Configures
reporting of violations for unused reset-synchronizers that are not
driving any sequential elements at set/reset pin. Default: false.

790
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-allow_pulse_synchronizer < true | false >]: Configures if pulse


generator circuit is to be allowed as part of NFF chain. Default: false.
 [-allow_diff_clock_net < true | false >]: Set this argument to
false to mark all NFFs that have different clock nets for the destination
flop and the corresponding synchronizer flops as invalid NFFs. By
default, the argument is set to true and VC SpyGlass CDC detects such
NFFs as valid NFFs.
 [-detect_full_chain < true | false >]: Reports the name of all
flops of the nff chain in the synchronizer_flop_chain attribute.
Default: false.
 [-same_hier_level < int >]: Specifies the common hierarchy level in
which the NFF chain flops should reside. This limits the number of
hierarchical levels. By default, hierarchies of NFF chain flops are not
considered. Minimum value is 1.
 [-allow_quasi_gate_in_chain < true | false >]: Configures if
quasi gate is allowed in multi-flop chain. Default: false.
 [-allow_asyncrst_gate_in_chain < true | false >]: Configures if
asyncrst gate is allowed in multi-flop chain. Default: false.
 [-allow_buf_equiv_logic < true | false >]: Configures if buffer-
equivalent logic is allowed in detection of NFFs. Set this argument to
false to not detect NFFs with buffer-equivalent logic. Default: true.
 [-detect_insufficient_depth_nff < true | false >]: When set to
true, if a NFF chain of at-least the minimum sequential depth is
detected and the user-specified depth criteria is not met, the
ASYNCRST_CTRLPATH_PARTIAL tag reports a violation with the
NFF_WITH_INSUFFICIENT_DEPTH reason code instead of the
ASYNCRST_UNSYNC_NOSCHEME tag reporting a violation. Default:
false.

Example:
configure_cdc_asyncrst_nff_sync -from_clock c1 -to_clock c2
-depth 3
configure_cdc_asyncrst_nff_sync -allowed_modules M1 -depth 1
configure_cdc_asyncrst_nff_sync -skip_sync
configure_cdc_asyncrst_nff_sync -ignore_multi_domain_sources
yes -allow_quasi_static no -allow_latch destination -

791
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

allow_half_sync no -remove_redundant_logic false

configure_cdc_convergence
Description
Configures several convergence detection criteria.

Syntax
configure_cdc_convergence
[-num_convergences <num_convergences>]
[-stop_at_sources <true|false>]
[-stop_at_clock <true|false>]
[-stop_at_reset <true|false>]
[-disable_schematic <true|false>]
[-stop_at_reset_of_diff_clk_seq <true|false>]
[-ignore_reset_port_for_multisync <true|false>]
[-ignore_diffdom_paths <true|false>]
[-report_conv_at_sync_output <true|false>]
[-allow_sync_reset_as_conv_point <true|false>]
[-cdc_conv_seq_depth_max <integer>]
[-cdc_diverge_src_seq_depth_max <integer>]
[-convergence_check_type <control|reset>]
[-report_async_seq <true|false>]
[-enable_conv_check_at_soc <true|false>]
[-ignore_through_objects <ignore_through_objects>]
[-ignore_at_objects <ignore_at_objects>]
[-ignore_among_signals <ignore_among_signals>]
[-allow_multiple_sync <data | reset | all | none>]
[-enable_seq_based_analysis <true|false>]

792
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

[-enable_scg_based_analysis <true|false>]
[-report_all_convergence <true|false>]
[-dump_detailed_info <none|noConvMismatch|noConvFvUnchecked
|all>]
[-enable_report_convergence_qualifier <true|false>]
[-allow_set_reset_latch <true|false>]
[-ignore_sources <list of sources of signal synced multiple
times>]
[-unrelated <unrelated-list>]

Arguments
 [-num_convergences <num_convergences>]: Specifies the number of
parallel convergences to be reported for any set of synchronizers.
Default: 1
 [-stop_at_sources <true|false>]: Specifies whether to stop at
sources of other crossings or not. Default: false
 [-stop_at_clock <true|false>]: Specifies whether to stop at clock.
Default: true
 [-stop_at_reset <true|false>]: Specifies whether to stop at reset.
Default: true.
 [-disable_schematic <true|false>]: Specifies if schematics of
convergence violations should be generated. Default: false.
 [-stop_at_reset_of_diff_clk_seq <true|false>]: Specifies
whether to stop at reset of diff domain. Default: true
 [-ignore_reset_port_for_multisync <true|false>]: Specifies
whether to ignore multiple sync violations in which source is driven by a
user defined reset port. Default: false
 [-ignore_diffdom_paths <true|false>]: When set to true,
convergence of paths leading to different domain sequential elements
(immediate - sequential just next to convergence port) will be ignored.
Default: false
 [-report_conv_at_sync_output <true|false>]: When set to true,
reports convergence at a synchronizer output if another synchronizer is
reaching the output of first synchronizer. Default: false

793
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-allow_sync_reset_as_conv_point <true|false>]: Specifies


whether to report convergence on synchronous reset path. Default:
false
 [-cdc_conv_seq_depth_max <integer>]: Specifies the maximum
sequential depth till which convergence has to be found. For infinte
depth use value -1. Default: 1
 [-cdc_diverge_src_seq_depth_max <integer>]: Specifies the
maximum sequential depth for determining the diverging source.
Infinite depth is not allowed for this option. Default: 0
 [-convergence_check_type <control|reset>]: Specifies the types of
synchronized paths participating in convergence detection. Please
configure stop_at_reset argument for reset-sync convergences. Default:
control
 [-report_async_seq <true|false>]: Control for reporting sequential
asynchronous source convergence. By default, asynchronous source
convergence are reported.
 [-enable_conv_check_at_soc <true|false>]: By default, in the SoC
run, convergence analysis is not performed for the top signals that are
converging inside the abstract block. Set this argument to true to
enable reporting of convergence points that are driving a sequential
element. Default value is false.
 [-ignore_through_objects <ignore_through_objects>]: Specifies
design objects beyond which convergences should not be reported.
 [-ignore_at_objects <ignore_at_objects>]: Specifies design
objects at which convergence should not be reported.
 [-ignore_among_signals <ignore_among_signals>]: Specifies design
objects which can be synchronizer output pins, among which
convergences should not be reported.
 [-allow_multiple_sync <data | reset | all | none>]: Configure
types of synchronizers that will take part in multiple sync violations.
Default: all
 data: Allows data synchronizers to participate in multiple sync no
convergence violations.
 reset: Allows reset synchronizers to participate in multiple sync no
convergence violations.

794
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 none: Does not allow any synchronizers to participate in multiple


sync no convergence violations.
 all: Considers both data and reset synchronizers to participate in
multiple sync no convergence violations. Multiple values can be
specified.
 [-enable_seq_based_analysis <true|false>]: Reports convergence
points that are driving a sequential element when set to true. Default:
false.
If the CDC_COMBCONV_ASYNC_SRCS and the
CDC_SEQCONV_ASYNC_SRCS tags are disabled, and the
configure_cdc_convergence -enable_seq_based_analysis argument
is set to true, VC SpyGlass performs convergence analysis separately
and reports two violations if a convergence point has qualifiers from two
different source domains.
 [-report_all_convergence <true|false>]: Reports all convergence
points, that are driving a sequential element when set to true. If set to
false, only points that are directly driving a sequential element (no
convergence point in the path of sequential and current convergence
point) are reported. Default: false.
 [-enable_scg_based_analysis <true|false>]: Performs
set_clock_groups based convergence analysis when set to true. The
violation message reports clock information for the convergence point.
In the set_clock_group-based convergence analysis, convergence is
reported for the synchronizers that have at least one common
synchronous clock between them. In addition, the clock should be
synchronous with at least one clock of the sequential element at the
convergence point.
Note that in this flow, convergence is reported only at simple sequential
elements (such as flip flops, latches, flip flop banks, latch banks) and
complex sequential elements (any other sequential object apart from
the simple sequential elements). However, qualifier does not propagate
through complex sequential elements.
NOTE: In the set_clock_group-based convergence analysis flow, the objects speci-
fied with the configure_cdc_convergence -ignore_at_objects
argument should be the sequential pins on which the convergence violation is
reported because the -ignore_at_objects argument ignores convergences
reported at a particular convergence point. In addition, when the -enable_sc-
g_based_analysis argument is enabled, the -num_convergence argument is not

795
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

honored.
For example, consider the following schematic.

In this case, the CDC_COMBCONV_FVUNCHECKED tag reports the


convergence for FD01, FD02, and FD03 at the data pin of FD04 because
the CK2 clock is a common synchronous clock between synchronizers
and the FD04 end point sequential.
 [-dump_detailed_info <none|noConvMismatch|noConvFvUnchecked
|all>]: Enables reporting of source and destination name and clock
information for the specified check. Default: none.
 [-enable_report_convergence_qualifier <true|false>]: Set this
argument to true to use the report_convergence_qualifier
command to report the path of a converging qualifier. Default value is
false.

796
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-allow_set_reset_latch <true|false>]: Set this argument to true


to report convergence through const-enable set reset latches. Default
value is false.
 [-ignore_sources <list of sources of signal synced multiple
times>]: Enables suppressing of CDC_NOCONV_MULTI_SYNC violations
for the specified sources.
 [-unrelated <unrelated-list>]: Specifies the signals for which glitch
related violations should not be reported.

configure_cdc_data_sync
Description
Configures the data synchronizer detection.
You can use the -from_clock <src-clk> and the -to_obj <dest-obj>
combination to synchronize the crossing between the objects. Similarly,
you can use the -from_obj <src-obj> and the -to_clock <dest-clk>
combination together. For example, consider the following schematic:

In this case, the crossing from src to des is synchronized by user-specified


qualifier with the following command:

797
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

configure_cdc_data_sync -to_clock {clk2} -des_enable_expr {q} -


from_obj {src/q/Q }
Alternatively, you can also use the following command:
configure_cdc_data_sync -to_obj {des/q/Q} -des_enable_expr {q}
-from_clock {clk1}

Syntax
configure_cdc_data_sync
[-from_clock < src-clk >]
[-to_clock < dest-clk >]
[-from_obj < src-obj >]
[-to_obj < dest-obj >]
[-to_obj_type <primary_output, black_box, library_cell, flop,
latch, multi_port_memory, clock_gate, macro_cell, none>]
[-skip_sync]
[-allow_complex_mux_recirc]
[-skip_autoqual]
[-des_qual < pin | port | net >]
[-des_qual_depth < integer value >= -1 >]
[-ignore_des_qual < pin | port | net >]
[-sync_point_qualifier <first, all>]
[-sync_point_select <none, first, last, all, user_defined>]
[-sync_point_report_limit <Value>=-1>]
[-sync_point_cell <module-list>]
[-and_or_based_cgc]
[-src_stable]
[-dual_qual_reqd]
[-validate_on_domain]
[-incr]
[-allow_merged_qualifier]

798
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

[-sync_point < and, mux_select, mux_recirc, clock_gate,


sync_point_cell, and_or_mux_recirc>]
[-src_qual < pin | port | net >]
[-src_qual_depth < integer value >= -1 >]
[-des_enable_expr < expression string >]
[-des_enable_expr_validate < obj_reachable | obj_data_domain |
obj_exist | disable | dynamic_stimulation >]
[-blocking_gate_instances < module/lib-cell instances >]
[-blocking_gate_modules < modules >]
[-enable_autoqual]
[-sync_check_type < qual_only | enable_with_qual |
enable_with_des_domain >]
[-analyze_async_sources < true | false >]
[-dynamic_side_channel < true | false >]
[-allow_qual_prop_across_dest < true | false >]
[-allow_cascaded_cgc < true | false >]
[-auto_syncrst_qual < true | false >]
[-allow_qual_thru_cgc_gen_clock < true | false >]
[-allow_sync_clocks_qual < true | false >]
[-enable_syncpoint_reporting < true | false >]
[-allow_all_syncpoint_for_user_qual < true | false >]

Arguments
 [-from_clock < src-clk >]: Specifies the list of clocks on the source
of the data crossings.
 [-to_clock < dest-clk >]: Specifies the list of clocks on the
destination of the data crossings.
 [-from_obj < src-obj >]: Specifies the list of source objects of the
data crossings.
 [-to_obj < dest-obj >]: Specifies the list of destination objects of the
data crossings.

799
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-to_obj_type <primary_output, black_box, library_cell, flop,


latch, multi_port_memory, clock_gate, macro_cell, none>]:
Specifies the types of destination of crossing for which sync analysis
need to be skipped. This option can be specified only in conjunction with
the skip_sync argument.
 [-skip_sync]: Disables the auto detection of data synchronizers.
 [-allow_complex_mux_recirc]: Allows additional combinational logic
driven by destination domain signal within mux recirculation structure.
 [-skip_autoqual]: Disables the auto detection of qualifiers.
 [-des_qual < pin | port | net >]: Specifies the qualifier signal
which blocks the source of data crossing.
 [-des_qual_depth < integer value >= -1 >]: Specifies the
maximum valid sequential depth of a qualifier. Default: 3.
 [-ignore_des_qual < pin | port | net >]: Specifies the
synchronizers that are not allowed as qualifiers.
 [-sync_point_qualifier <first, all>]: When set to all, all the
qualifier that can block the source on a blocking gate are reported.
Default: first.
 [-sync_point_select <none, first, last, all, user_defined>]:
Specifies the location priority of the blocking gate with respect to source
node of a crossing. Default: none.
 [-sync_point_report_limit <Value>=-1>]: Specifies the maximum
number of blocking gates on which source can be blocked. Default: 5.
 [-sync_point_cell <module-list>]: Specifies modules or cells that
are valid for blocking condition.
 [-and_or_based_cgc]: Allows AND/OR/NAND/NOR gates to be treated
as valid Clock Gating cells for CGC based synchronization scheme.
 [-src_stable]: Allows user specified source qualifier and destination
qualifier to synchronize data crossing if those are reaching the source
and destination of crossing respectively.
 [-dual_qual_reqd]: Allows user to specify that both source and
destination qualifier are required to synchronize data crossing.
 [-validate_on_domain]: Allows validation of the user-specified
constraint on domains if provided with from_clock and to_clock
instead of clocks.

800
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-incr]: It disables the creation of new qualifiers on the output of cells


specified by -des_qual if an auto detected qualifier is not found.
 [-allow_merged_qualifier]: Specifies the gate at which source and
the qualifier merges act as a new qualifier for other sources.
 [-sync_point <and, mux_select, mux_recirc, clock_gate,
sync_point_cell, and_or_mux_recirc>]: Defines legal
synchronization points for blocking condition detection. Default: {and,
mux_select, mux_recirc, clock_gate, sync_point_cell }.
 [-src_qual < pin | port | net >]: Specifies the source qualifier
signal which blocks the source of data crossing.
 [-src_qual_depth < integer value >= -1 >]: Specifies the
maximum valid sequential depth of a source qualifier. Default: 3.
 [-des_enable_expr < expression string >]: Specifies the enable
expression signal which enables the source of data crossing.
 [-des_enable_expr_validate < obj_reachable | obj_data_domain
| obj_exist | disable | dynamic_stimulation >]:
 obj_reachable (Default value): Objects specified in expression must
exist in design, must be present in destination domain and atleast
one of those objects should reach destination within the sequential
depth specified by -des_qual_depth.
 obj_data_domain: Objects specified in expression must exist in
design and must be present in Destination Domain. If the above two
criteria are specified, the crossing is marked synchronized by the
user specified expression.
 obj_exist: Only existence of objects in the design is verified, if
objects are present, crossing is marked synchronized by the user
specified expression.
 disable: No validation on the expression is performed and crossing
is marked synchronized by the user specified expression.
 [-blocking_gate_instances < module/lib-cell instances >]:
Specifies the list of module or library cell instances, the blocking gates
of which can use auto-inferred qualifiers for synchronization analysis
within the specified des_qual_depth.
 [-blocking_gate_modules < modules >]: Specifies the list of
modules, the blocking gates of which can use auto-inferred qualifiers for
synchronization analysis within the specified des_qual_depth.

801
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-enable_autoqual]: Configures if the auto-inferred qualifiers are


allowed for synchronization analysis on the blocking gate that are in the
hierarchy of the modules/instances specified by using the
blocking_gate_modules or the blocking_gate_instances arguments.
 [-sync_check_type < qual_only | enable_with_qual |
enable_with_des_domain >]: Specifies the type of synchronizer check
to be performed. Default: qual_only.
 [-analyze_async_sources < true | false >]: Configures if
synchronization checks need to be performed for asynchronous sources
of different clock domains converging at same point. Default: false.
 [-dynamic_side_channel < true | false >]: Configures if
deterministic gates in merged-qualifier path with other inputs in
destination domain are treated as buffers for dynamic synchronization
analysis. This option is applicable only if the
enable_sync_dynamic_analysis application variable is set to true.
Default: true.
 [-allow_qual_prop_across_dest < true | false >]: Enables
propagation of qualifiers across destination of crossing to perform
synchronization analysis on other crossings. Crossings that are analyzed
by such qualifiers report the QUALIFIER_PROPAGATED_ACROSS_DEST
reason-code additionally. Default: false.
 [-allow_cascaded_cgc < true | false >]: Configures if cascaded
clock gating cells should be allowed in the clock-gate synchronization
scheme. Only cascaded lib-cell clock gating cells are supported under
this option. Default: false.
 [-auto_syncrst_qual < true | false >]: When set to true,
crossings synchronized with potential sync reset qualifiers are
additionally reported with the POTENTIAL_SYNCRST_QUALIFIER reason
code. Default: false.
 [-allow_qual_thru_cgc_gen_clock < true | false >]: Allows
qualifiers to be propagated through CGC cells, on the output of which
generated clocks synchronous to destination domain are defined.
Default: false.
 [-allow_sync_clocks_qual < true | false >]: Enables qualifiers
driven by clocks synchronous to destination clocks for synchronization
checks. Default: false.

802
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-enable_syncpoint_reporting < true | false >]: Enables


reporting of blocking gate information for data-synchronized violations.
Default: false.
 [-allow_all_syncpoint_for_user_qual < true | false >]: When
set to true, all types of sync gates are considered valid for user-
specified qualifier. Default: true.

Examples
configure_cdc_data_sync -des_qual qual_obj -from_clock clk1
-to_clock clk2 -des_qual_depth 4 -allow_merged_qualifier
configure_cdc_data_sync -from_obj o1 -to_obj o2 -des_qual
qual_obj
configure_cdc_data_sync -skip_sync
configure_cdc_data_sync -allow_complex_mux_recirc
configure_cdc_data_sync -des_enable_expr "o1&o2" -from_clock
c1 -des_enable -expr_validate dynamic_simulation

configure_cdc_nff_sync
Description
Configures the multi-flop synchronizer detection.

Syntax
configure_cdc_nff_sync
[-from_clock < src-clk >]
[-to_clock < dest-clk >]
[-from_obj < src-obj >]
[-to_obj < dest-obj >]
[-to_obj_types]
[-skip_sync ]
[-depth < value >= 1 >]

803
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

[-allowed_modules]
[-uds_modules]
[-ignore_multi_domain_sources < yes | no >]
[-allow_quasi_static < yes | no >]
[-allow_latch < destination | flop_chain | none >]
[-allow_half_sync <yes | no | strict | unset >]
[-allow_diff_clk_period <true | false >]
[-detect_potential_synchronizers <yes | no >]
[-auto_detect_sync_cell < none|all|single_output >]
[-data_pin_connectivity <tied_0|tied_1|same_as_async|no_check
>]
[-suppress_unobservable <sync | unsync>]
[-strict]
[-remove_redundant_logic <true | false>]
[-allow_parallel_synchronizers <true | false>]
[-allow_combo_logic < yes | no | strict>]
[-allow_diff_clock_net < true | false >]
[-detect_full_chain < true | false >]
[-same_hier_level < int >]
[-allow_quasi_gate_in_chain < true | false >]
[-allow_asyncrst_gate_in_chain < true | false >]
[-allow_buf_equiv_logic < true | false >]
[-detect_insufficient_depth_nff < true | false >]

Arguments
 [-from_clock < src-clk >]: Specifies the list of clocks on the source
of the control crossings.
 [-to_clock < dest-clk >]: Specifies the list of clocks on the
destination of the control crossings.
 [-from_obj < src-obj >]: Specifies the list of source objects of the
control crossings.

804
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-to_obj < dest-obj >]: Specifies the list of destination objects of the
control crossings.
 [-to_obj_types]: Specifies the types of destination of crossing for
which sync analysis needs to be skipped. This option can be specified
only in conjunction with skip_sync argument.
 [- skip_sync ]: It disables the auto detection of multi-flop
synchronizers.
 [-depth < value >= 1 >]: Specifies the sequential depth to be
considered as valid multi-flop synchronizer. Default: 2
 [-allowed_modules]: Restricts NFF synchronizer detection to specified
modules. The uds_modules and the allowed_modules arguments
cannot be specified in the same command. In addition, if the
uds_modules and the allowed_modules arguments are specified on the
same module, the constraint that is specified later is honored.
 [-uds_modules]: Specifies user synchronizer cells and libraries. The
uds_modules and the allowed_modules arguments cannot be specified
in the same command. In addition, if the uds_modules and the
allowed_modules arguments are specified on the same module, the
constraint that is specified later is honored.
 [-ignore_multi_domain_sources < yes | no >]: Set it to true to
consider a destination for multi-flop synchronizer detection, even if
multiple domains srcs are driving the destination. Default: true.
 [-allow_quasi_static < yes | no >]: Allows combinational logic
between the synchronizer flip-flops if the combinational logic is probable
buffer path as side inputs are quasi-static. Default: no.
 [-allow_latch < destination | flop_chain | none >]: Default:
flop_chain
 destination: Allows latch only as destination of the crossings for
NFF detection.
 flop_chain: Allows all latchs in multi-flop synchronizer chain for NFF
detection.
 none: No latches are allowed in the multi-flop chain for NFF
detection.
 [-allow_half_sync <yes | no | strict | unset >]:

805
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 yes: Treats flops with inverted polarity in the multi-flop chain as


depth 1.
 no: Treats flops with inverted polarity in the multi-flop chain has 0.5.
 strict: Does not allow flop (latch) with inverted (same) polarity in
the multi-flop chain. Default: unset.
 [-allow_diff_clk_period <true | false >]: When set to false,
different clock periods for destination and synchronizer flops are not
allowed. Default: true.
 [-detect_potential_synchronizers <yes | no >]: Detect potential
synchronizers in allowed modules. Default: no.
 [-auto_detect_sync_cell < none|all|single_output >]: Type of
libcell inside which NFF detection needs to be done. Default: none.
 [-data_pin_connectivity
<tied_0|tied_1|same_as_async|no_check >]: Configuration for
connectivity of data pin of a valid synchronizer.
 [-suppress_unobservable <sync | unsync>]: Types of crossings
required to be suppressed
 [-strict]: Type of method to detect unobservable object
 [-remove_redundant_logic <true | false>]: Ignores the redundant
paths (hanging/blocked) for meta-fanout analysis for NFF detection.
Default: true.
 [-allow_parallel_synchronizers <true | false>]: Allow nffs which
have parallel synchronizer flops after destination to be marked as valid
synchronizer structures Default: false
 [-allow_combo_logic < yes | no | strict>]: Default value is no.
 yes: Allows all non-static combinational logic between source and
destination flop.
 no: Does not allow any non-static combinational logic between source
and destination flop.
 strict: Allows only those non-static combinational logic where the
inputs are either driven by the same source or by a destination
domain signal.
 [-allow_diff_clock_net < true | false >]: Set this argument to
false to mark all NFFs that have different clock nets for the destination
flop and the corresponding synchronizer flops as invalid NFFs. By

806
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

default, the argument is set to true and VC SpyGlass CDC detects such
NFFs as valid NFFs.
 [-detect_full_chain < true | false >]: Reports the name of all
flops of the nff chain in the synchronizer_flop_chain attribute.
Default: false.
 [-same_hier_level < int >]: Specifies common hierarchy level within
which the NFF chain flops should reside. This limits the number of
hierarchical levels. By default, hierarchies of NFF chain flops are not
considered. Minimum value is 1.
NOTE: NFF Detection for user-specified NFF-depth > 2 is stopped on reaching sequen-
tial, whose depth from destination is less than user specified NFF Depth but
other NFF detection criteria are not satisfied (For example: hierarchy criteria is
not satisfied with user-specified hierarchy difference specified by using the
same_hier_level argument of configure_cdc_nff_sync). In this case, such cross-
ings are reported as UNSYNC instead of partial.
 [-allow_quasi_gate_in_chain < true | false >]: Configures if
quasi gate is allowed in multi-flop chain. Default: false.
 [-allow_asyncrst_gate_in_chain < true | false >]: Configures if
asyncrst gate is allowed in multi-flop chain. Default: false.
 [-allow_buf_equiv_logic < true | false >]: Configures if buffer-
equivalent logic is allowed in detection of NFFs. Set this argument to
false to not detect NFFs with buffer-equivalent logic. Default: true.
 [-detect_insufficient_depth_nff < true | false >]: When set to
true, if a NFF chain of at-least the minimum sequential depth is
detected and the user-specified depth criteria is not met, the
SYNCCDC_CTRLPATH_PARTIAL tag reports a violation with the
NFF_WITH_INSUFFICIENT_DEPTH reason code instead of the
SYNCCDC_UNSYNC_NOSCHEME tag reporting a violation. Default:
false.

Example:
configure_cdc_nff_sync -from_clock c1 -to_clock c2 -depth 3
configure_cdc_nff_sync -allowed_modules M1 -depth 1
configure_cdc_nff_sync -skip_sync
configure_cdc_nff_sync -ignore_multi_domain_sources yes -
allow_quasi_static no -allow_latch destination -

807
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

allow_half_sync no -remove_redundant_logic false

configure_cdc_netlist_busmerging
Description
Configures netlist bus-merging attributes such as bus-delimiters.

Syntax
configure_cdc_netlist_busmerging
[-start_delimiter]
[-end_delimiter]
[-add_delimiter]
[-suffix]

Arguments
 [-start_delimiter]: Specifies allowed start-delimiter of netlist bus
 [-end_delimiter]: Specifies allowed end-delimiter of netlist bus
 [-add_delimiter]: Adds current pair of start and end delimiters to the
allowed delimiter's list for netlist bus-merging.
 [-suffix]: Specifies a list of suffixes used in netlist buses' name.

configure_cdc_abstract_model
Description
Configures design abstraction.

Syntax
configure_cdc_abstract_model
[-include_as_potential_qual < root_port_collection >]
[-exclude_fully < root_port_collection >]
[-potential_qual_applies_to < apply_parameter >]

808
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

[-qual_port_max_width < integer value >]


[-qual_port_conv_depth < integer value >]
[-qual_port_sync_depth <integer value>]
[-seq_fanout_threshold < float value >]
[-preserve_potential_reset_paths < bool value >]
[-enable_floating_convergence]

Arguments
 [-include_as_potential_qual < root_port_collection >]:
Specifies a list of primary input or inout ports that should be treated as
potential qualifiers for design abstraction for CDC.
 [-exclude_fully < root_port_collection >]: Specifies a list of
primary input or inout ports that should be ignored completely for
creating in-memory abstract model for CDC.
 [-potential_qual_applies_to < apply_parameter >]: Specifies the
parameter for which potential qualifier applies for abstraction. Valid
values include: convergence and data_sync.
 [-qual_port_max_width < integer value >]: Specifies the maximum
width of an input port that should be treated as potential qualifier during
abstraction. Default value is 8; Range is 1 to 32.
 [-qual_port_conv_depth < integer value >]: Specifies the
sequential depth to be considered for ports as potential qualifier during
abstraction. Default value is 1, Range is 1 to 255.
 [-qual_port_sync_depth <integer value>]: Specifies the sync depth
to be considered for potential qualifier port during abstraction. Default
value is 3, Range is 1 to 255.
 [-seq_fanout_threshold < float value >]: Specifies the threshold
value for percentage sequentials seen in the fanout cone. Beyond this
threshold value, VC SpyGlass CDC reports a warning indicating an
impact on SAM abstraction because a high fanout can cause higher
percentage of CDC logic being retained. Range: 1 to 100.
 [-preserve_potential_reset_paths < bool value >]: Specifies if
paths from the primary input ports, which are potential asynchronous
set/reset roots, to the async set/reset pins of sequential elements in the
design should be preserved.

809
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-enable_floating_convergence]: Specifies if abstraction for non-


observable convergence should be enabled. By default, floating
convergences are not abstracted.

configure_cdc_rule
Description
Configures CDC violation tags correspond to SpyGlass rules.

Syntax
configure_cdc_rule
[-rule <rule list>]
[-enable]
[-disable]

Arguments
 [-rule <rule list>]: Specifies the VC violation tag(s).
 [-enable]: Enables the tag(s).
 [-disable]: Disables the tag(s).

configure_cdc_rule_param
Description
Configures SpyGlass parameters.

Syntax
configure_cdc_rule_param
[-parameter <param name>]
[-value <param value>]
[-overridden]
[-after_design_read]

810
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

[-after_sgdc_read]

Arguments
 [-parameter <param name>]: Specifies the parameter name.
 [-value <param value>]: Specifies the parameter value.
 [-overridden]: Specifies whether value is SpyGlass overridden or not.
 [-after_design_read]: Specifies whether after design read.
 [-after_sgdc_read]: Specifies whether after sgdc read.

configure_cdc_setup_check
Description
Configures parameters of setup checks.

Syntax
configure_cdc_setup_check
[-report_latch]
[-clock_on_ports]
[-reset_on_ports]
[-same_domain_overlap]
[-clock_undecl_rca]
[-clock_usage]
[-check_port_setup]
[-no_unate_reconv]
[-report_reset_undecl_on_const_clock true|false ]
[-report_clock_glitch_on_hanging_net]
[-report_quasi_static_clock_as_constant true|false]
[-report_only_sca_violations]
[-report_overlap_on_sequential]
[-report_overlap_on_data_path]

811
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

[-report_clock_reconvergence_on_mux]
[-report_all_seq_for_assert_missing]
[-annotate_reset_assertion]
[-report_all_asyncreset_combo]
[-report_reset_path_mux]
[-report_clkglitch_on_io]
[-report_reset_undecl_on_const_clock true|false ]
[-filter_reset_undecl_on_quasi_static true|false ]
[-check_reset_for_constclock]
[-clock_usage <data,control,reset,bbox,others,port,all>]
[-async_reset_usage <data,control,port,bbox,libcell,
all>]
[-all_converging_clocks]
[-ignore_ports_for_inferdom]
[-report_overlap_on_genclk]
[-report_overlap_to_genclk]
[-dump_detailed_info <none| clockUndecl|
libCellComboDrivenAsyncPin| resetConstActive|
resetConstInactive| resetAssertMissing|
inputMultiClkLoad| outputMultiClkDriver|
inputMultiClkLoadInferredDomain|
outputMultiClkDriverInferredDomain| all>]
[-latch_as_seq]
[-show_constant_source]
[-max_reset_const_active_seq_count]
[-report_clock_port_as_constrained]

Arguments
 [-report_latch]: Reports setup violations on latches.
 [-clock_on_ports]: Reports clock overlaps/convergence on output
ports.

812
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-reset_on_ports]: Reports reset overlaps/convergence on output


ports.
 [-same_domain_overlap]: Reports overlaps of same-domain clocks in
SGUM.
 [-clock_undecl_rca]: Analyzes the reason for unclocked pins.
 [-clock_usage]: Specifies the signal types to be reported for non-clock
usage by the tag. Valid values include data, control, reset, port,
bbox, others, derived, all. Default value is data, control, reset,
bbox, others.
 [-check_port_setup]: Ports on which to checks SETUP_PORT.
 [-no_unate_reconv]: Report clock/reset convergence only if both
positive and negative polarities converge.
 [-report_reset_undecl_on_const_clock true|false ]: When set to
true, violation for the SETUP_RESET_UNDECL tag is reported for
sequential elements whose reset/set is not getting reset signal even if
clock pin is receiving a constant value. The default value is false.
 [-report_clock_glitch_on_hanging_net]: When set to true,
violation for the SETUP_CLOCK_GLITCH tag is reported on hanging nets
as well. The default value is false.
 [-report_quasi_static_clock_as_constant true|false]: When set
to true, violation for the SETUP_CLOCK_CONSTANT tag is also reported
when the clock pin ofa sequential element receives quasi signal. It also
impacts the reason code for the SETUP_CLOCK_UNDECL tag. The
default value is false.
 [-report_only_sca_violations]: When set to true, violation for the
SETUP_*_CONSTANT tags are reported only when they receive constant
specified by using the set_case_analysis sdc command. The default
value is false.
 [-report_overlap_on_sequential]: Reports
SETUP_SYNC_CLOCK_OVERLAP and SETUP_ASYNC_CLOCK_OVERLAP
violations only if a clock is reaching any sequential element, hanging
net, black-box, or top port. The default value is true.
 [-report_overlap_on_data_path]: Reports
SETUP_SYNC_CLOCK_OVERLAP, SETUP_ASYNC_CLOCK_OVERLAP,
SETUP_SYNC_CLOCK_OVERLAP_CONSTRAINED,
SETUP_ASYNC_CLOCK_OVER-LAP_CONSTRAINED and

813
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

INTEGRITY_CLOCK_RECONVERGE violations on data path. The default


value is false.
 [-report_clock_reconvergence_on_mux]: Reports
INTEGRITY_CLOCK_RECONVERGE violations on Muxs.
 [-report_all_seq_for_assert_missing]: Reports
SETUP_RESET_ASSERT_MISSING violation for all sequential elements.
 [-annotate_reset_assertion]: Annotates reset values for
SETUP_RESET_ASSERT_MISSING violations. The default value is true.
 [-report_all_asyncreset_combo]: Reports multiple violations for the
same input cone driven by combinational logic when the same input
cone is driving multiple flops.
 [-report_reset_path_mux]: Reports a violation when the
asynchronous set/reset pins of a sequential element are driven by mux.
 [-report_clkglitch_on_io]: Reports a SETUP_CLOCK_GLITCH
violation for those inout ports where user clock is defined. The default
value is true.
 [-report_reset_undecl_on_const_clock true|false ]: When set to
true, reports a SETUP_RESET_UNDECL violation for sequential
elements whose reset/set is not getting reset signal even if clock pin is
receiving a constant value. Default value is false.
 [-filter_reset_undecl_on_quasi_static true|false ]: When set
to true, does not report a SETUP_RESET_UNDECL violation for nets
that are constrained as quasi_static. The default value is false.
 [-check_reset_for_constclock]: Reports the status of set and preset
pins of sequential elements whose clock pin is tied to constant value.
This is applicable in SGUM only.
 [-clock_usage <data, control, reset, bbox, others, port,
all>]: Specifies signal types to be reported by the
INTEGRITY_CLOCK_AS_NON_CLOCK tag for non-clock usage. The
default values are data, control, reset, bbox, others.
 [-async_reset_usage <data, control, port, bbox, libcell,
all>]: Specifies the signal types to be reported by the
SETUP_RESET_DRIVING_NON_ASYNC_PIN tag for non-reset usage. The
default value is data.
 [-all_converging_clocks]: Reports all the clocks converging on a
mux.

814
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-ignore_ports_for_inferdom]: Ignores domain specified on output


port during auto-inference of domain for input ports and vice versa.
 [-report_overlap_on_genclk]: Reports
SETUP_SYNC_CLOCK_OVERLAP or SETUP_ASYNC_CLOCK_OVERLAP
violations on the point on which generated clock is defined and is getting
driven from another user-defined clock. The default value is true.
If the option is set to false, the SETUP_CLOCK_SYNC_OVERLAP or the
SETUP_ASYNC_CLOCK_OVERLAP violation are not reported on
generated clock if it only receives the clock which is defined as its
master clock. The violation is reported with CLOCK_PROP_SYNC or the
CLOCK_PROP_ASYNC reason code.
 [-report_overlap_to_genclk]: When the value of this option is set to
true, the SETUP_SYNC_CLOCK_OVERLAP or the
SETUP_ASYNC_CLOCK_OVERLAP violations are reported on the
overlapping points (which is receiving different clocks on its multiple
input pin) if it drives the generated clock defined by user in its fanout.
The default value is false.
 [-dump_detailed_info <none| clockUndecl| libCellComboDrive|
AsyncPin| resetConstActive| resetConstInactive|
resetAssertMissing| inputMultiClkLoad| outputMultiClkDriver|
inputMultiClkLoadInferredDomain|
outputMultiClkDriverInferredDomain| all>]: Enables the reporting
of driver information for the specified check. When set to clockUndecl,
reports sequential drivers of unconstrained clock for the
SETUP_CLOCK_UNDECL violation.
When set to libCellComboDrivenAsyncPin, reports drivers of combo
logic i.e. primary inputs, library cell, black-box, flop, latch, CGC in fanin
of combo logic for SETSETUP_LIBCELL_COMBO_DRIVEN_ASYNCPIN
violation. Default: none.
 [-latch_as_seq]: Set the value to true to consider latch output as
generated_clock for Clock_info01 rule in SpyGlass-like flow. Default:
false.
 [-show_constant_source]: Set the value to true to show the constant
source type (RTL, SCA, or MIXED) in violation for SETUP_DATA and the
CLOCK_CONSTANT tags. Default: false.
 [-max_reset_const_active_seq_count]: Specifies the maximum
number of SETUP_RESET_CONSTANT_ACTIVE violations for each
constant reset source. Default: 3.

815
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-report_clock_port_as_constrained]: Set the value to true to


report clock ports/pins as fully constrained when a clock is reaching to
them. Default: false.

Example:
To report setup related violation for latches, use the following command:
configure_cdc_setup_check -report_latch
To report SETUP_CLOCK_GLICTH tag violation for hanging nets and report
SETUP_CLCOK_CONSTANT violations when clock pin receives quasi signals,
use the following command:
configure_cdc_setup_check -report_clock_glitch_on_hanging_net -
report_quasi_static_clock_as_constant true

configure_cdc_setup_libcell
Description
Configures parameters for libcell setup and modeling.

Syntax
configure_cdc_setup_libcell
[-unconstr_libcell_pin_synchronized < true | false >]
[-user_analysis_module]

Arguments
 [-unconstr_libcell_pin_synchronized < true | false >]: If this
argument is set to true, input and inout pins of library cell that are not
associated with any real clock are assumed synchronized inside the
libcell.
 [-user_analysis_module]: Specifies the list of those library cells that
need to be analyzed.

Examples
To specify the LIB1 and LIB2 libcell modules for libcell modeling, use the
following command:

816
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

configure_cdc_setup_libcell -user_analysis_module {LIB1


LIB2}

configure_clock_propagation
Description
This command configures the propagation of clock.

Syntax
configure_clock_propagation
[-infer_strict_gen_clock]
[-propagate_on_hanging_pins]
[-propagate_through_tristate_enable]
[-derived_clk_thru_mux_sel]
[-disable_default_clk_thru_seq_setting]

Arguments
 [-infer_strict_gen_clock]: Disables propagation of derived clocks
through combinational logic where user-defined clocks is also reaching.
 [-propagate_on_hanging_pins]: Enables clock propagation to a path
that has a hanging pin at its end point.
 -propagate_through_tristate_enable: Use this option to enable
propagation of clock through tristate enable pin. Possible values are
false, true. The default value is false.
 [-derived_clk_thru_mux_sel]: Enables the propagation of clock
through the select pin of a mux. Default: false.
 [-disable_default_clk_thru_seq_setting]: Disables the default
setting for propagation of clock through sequential element.

configure_console_messages

817
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Description
This command configures where messages are shown. By default,
messages are shown in the console as well as included in the report
database. You can configure where messages should be shown based on
the tag or the severity.

Syntax
configure_console_messages
[-tag <tag_list>]
[-severity <severity_list>]
[-show <type>]

Arguments
 [-tag <tag_list>]: List of tag patterns to be configured. Wild cards
are supported.
 [-severity <severity_list>]: List of severities to be configured.
 [-show <type>]: Specifies where the messages are displayed/included.
Set the value to any of the following: Possible values are console,
database, both.
 console: Displays the message in the console output.
 database: Includes the message in the database.
 both: Displays messages in console as well as includes it in the
database. This is the default value for the option.

Examples
The following example shows how to configure the
SET_INPUT_DELAY_WITHOUT_CLOCK tag to include the messages in the
database only:
prompt> configure_console_messages -show database -tags
{SET_INPUT_DELAY_WITHOUT_CLOCK}
The following example shows how to configure all messages to be shown in
the console only:
prompt> configure_console_messages -show console

818
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

configure_set_clock_group
Description
Configures the domain inference of clocks

Syntax
configure_set_clock_group
[-consider_async_relation < none | create_clock | all >]
[-logically_exclusive_as_async <true | false>]
[-override_physically_exclusive_clock_relationship]
[-consider_sfp_clocks_async]
[-consider_set_max_clocks_async]

Arguments
 [-consider_async_relation < none | create_clock | all >]: The
default value of this option is none.
 none: All clocks that are not specified by using set_clock_groups
command are considered as synchronous.
 create_clock: The clocks specified using create_clock command
would be considered as asynchronous if these are not specified in any
set_clock_group command.
 all: All clocks that are not specified in set_clock_group commands
are considered as asynchronous.
 [-logically_exclusive_as_async <true | false>]: When this
option is set to true, VC SpyGlass CDC considers clocks specified as
logically_exclusive in the set_clock_group SDC command as
asynchronous clocks. By default, the argument is set to false.
 [-override_physically_exclusive_clock_relationship]: Overrides
existing clock relationship with physically exclusive relationship for
clocks which are defined on the same design objects.
 [-consider_sfp_clocks_async]: Considers two clocks as
asynchronous if there exists a two-way relationship of set_false_path
command between these clocks.

819
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 [-consider_set_max_clocks_async]: Considers two clocks as


asynchronous if there exists a two-way relationship of set_max_delay
command between these clocks.

Examples
To consider clocks specified as logically_exclusive in
set_clcok_group sdc command as asynchronous clocks, use the
following command:
configure_set_clock_group configure_cdc_tag -
logically_exclusive_as_async
To consider asynchronous clock relationship for clocks which are not part
of any set_clock_groups -asynchronous command, use the following
command:
configure_set_clock_group -consider_async_relation all

configure_unconstrained_ports
Description
Configures to model unconstrained inputs and outputs of top, black-box
modules, and library cells.

Syntax
configure_unconstrained_ports
[-module <module_name>]
-input_model <auto | virtual_diff_vector | virtual_diff_bits |
virtual_same | no_cross>
-output_model <auto | virtual_diff_vector | virtual_diff_bits |
virtual_same | no_cross>
[-auto_config <enable_virtual_diff | disable_virtual_diff>]
[-use_inferred_domains]
[-all_bbox]
[-all_libs]

820
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

Arguments
 [-module <module_name>]: Specify the name of the top module or black
box modules in the design that you want to configure for clock domain
association. If not specified, the configuration is performed for top-level
ports.
 -input_model <auto | virtual_diff_vector | virtual_diff_bits
| virtual_same | no_cross>: Specify the -input_model argument to
infer the domain information for the input ports of the top module or the
input pins of the black box. You can specify the following values with the
-input_model argument:
 auto: For top module, set the value of the -input_model argument
to auto to infer the domain information by using the semantics of the
SETUP_PORT_UNCONSTRAINED tag.
For black boxes and library cells, set the value of the -input_model
argument to auto to infer the domain information by using the
following criteria:
 If there is a single clock, then this clock is used.
 If there are multiple clocks, a new clock based on those clocks is
created.
 If there are no clocks, VC SpyGlass does not define any clock for
each unconstrained pin by default.
 no_cross: Set the value of the -input_model argument to no_cross
to not report a crossing from an unconstrained top-level input port or
unconstrained black-box input pins that are modeled using the
no_cross argument.
 virtual_same: Set the value of the -input_model argument to
virtual_same to enable VC SpyGlass define the same virtual clock
for the unconstrained input top-level ports or unconstrained black-
box which are modeled by using virtual_same argument. For black-
boxes, one domain will be used for one instance. VC SpyGlass
ensures that the defined virtual clock is asynchronous to the user-
defined clocks.
 virtual_diff_vector: Set the value of the -input_model argument
to virtual_diff_vector to enable VC SpyGlass define a unique
virtual clock for each unconstrained input port or unconstrained
black-box or unconstrained library cell pins.

821
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

 virtual_diff_bits: Set the value of the -input_model argument to


virtual_diff_bits to enable VC SpyGlass define different domains
for all the bits of unconstrained vector ports of an unconstrained
black box pin or unconstrained top-level ports.
 -output_model <auto | virtual_diff_vector | virtual_diff_bits
| virtual_same | no_cross>: Specify the -output_model argument
to infer the domain information for the output ports of the top module or
the output pins of the black box or library cell. You can specify the
following values with the -output_model argument:
 auto: For top module, set the value of the -output_model argument
to auto to infer the domain information by using the semantics of the
SETUP_PORT_UNCONSTRAINED tag.
For black boxes or library cells, set the value of the -output_model
argument to auto to infer the domain information by using the
following criteria:
 If there is a single clock, then this clock is used.
 If there are multiple clocks, a new clock based on those clocks is
created.
 If there are no clocks, VC SpyGlass does not define any clock for
each unconstrained port by default.
 no_cross: Set the value of the -output_model argument to
no_cross to not report a crossing from an unconstrained top-level
output port or unconstrained black-box output pins that are modeled
by using the no_cross argument.
 virtual_same: Set the value of the -output_model argument to
virtual_same to enable VC SpyGlass define the same virtual clock
for the unconstrained output ports or unconstrained black-box that
are modeled by using the virtual_same option. For black-boxes, one
domain will be used for one instance. VC SpyGlass ensures that the
defined virtual clock is asynchronous to the user-defined clocks.
 virtual_diff_vector: Set the value of the -output_model
argument to virtual_diff_vector to enable VC SpyGlass define a
unique virtual clock for each unconstrained output port or
unconstrained black-box or unconstrained library cell pins that are
modeled by using the virtual_diff_vector option.
 virtual_diff_bits: Set the value of the -output_model argument
to virtual_diff_bits to enable VC SpyGlass define different

822
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

domains for all the bits of unconstrained vector ports of a black box
or a top-level module.
 [-auto_config <enable_virtual_diff | disable_virtual_diff>]:
Specifies the configuration for auto type modeling.
 [-use_inferred_domains]: This parameter is used to specify whether
the inferred domain should be used for verification. This argument is not
applicable with the all_libs argument.
 [-all_bbox]: Specifies if all black boxes in the design should be
considered for modeling.
 [-all_libs]: Specifies if all library cells in the design should be
considered for modeling. Modeling is performed for only those library
cell pins that do not have any timing or functional arc defined in the
library cell definition. This option is supported with the -input_model
and -output_model arguments only.

configure_cdc_setup_blackbox
Description
Configures parameters for blackbox setup and modeling

Syntax
configure_cdc_setup_blackbox
[-ignore_module_type < empty_mod | no_output_mod >]
[-ignore_module_names]
[-report_abstract_module_coverage]

Arguments
 [-ignore_module_type < empty_mod | no_output_mod >]: Specifies
the criteria to ignore modeling and CDC analysis for black boxes.
 [-ignore_module_names]: Specifies a list of module names for which
Setup_blackbox01 violations need not be reported.
 [-report_abstract_module_coverage]: Set this value to yes to report
coverage of abstracted module under Setup_blackbox01. Default:
false.

823
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Examples
To ignore a module that has no output pins, use the following command:
configure_cdc_setup_blackbox -ignore_module_type no_output_mod
To ignore a module that has no logic, such as an empty blackbox, use the
following command:
configure_cdc_setup_blackbox -ignore_module_type empty_mod

configure_cdc_validation
Description
Configures validation checks in SAM flow and SpyGlass-like hierarchical
flow.

Syntax
configure_cdc_validation
[-abstract_model < abstract_model_type >]
[-express < validation type >]
[-reduce_pessimism < port_scenarios >]
[-extended_format < extended_format >]
[-dump_detailed_info < dump_detailed_info >]
[-traverse_combo < traverse_combo >]
[-disable < disable_types >]
[-enable < enable_types >]
[-translate_clocks < translate_clocks >]
[-report_unconstrained_sam_objects <
report_unconstrained_sam_objects>]

Arguments
 [-abstract_model < abstract_model_type >]: Applies validation
configurations to the specified abstract model type. Valid values are sam,
constraint, and all.

824
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

 [-express < validation type >]: Enables low noise and low effort
validation check for constraint type specified with this argument. Valid
values are none, clock_domain, quasi_static, case_analysis, reset,
virtual_clock, auto_qualifier, num_flops, user_qualifier, and
all.
 [-reduce_pessimism < port_scenarios >]: Ignores reporting of
validation checks in the specified port scenarios. Valid values are none,
hanging_net, constant, constant_clock, constant_reset,
constant_data, quasi_static, ignore_domain_overconstraint,
ignore_top_reset_mismatch, any_async_reset_match,
cdc_false_path, and all.
 [-extended_format < extended_format >]: Enables reporting of
violations in detailed format for the types specified with this argument.
Valid values are none, case, quasi, combo, data, clock, reset,
virtual, and all.
 [-dump_detailed_info < dump_detailed_info >]: Enables reporting
of violations in detailed format for the mismatch type specified with this
argument. Valid values are none, case, quasi, combo, data, clock,
reset, virtual, and all.
 [-traverse_combo < traverse_combo >]: Enables traversal through
combo path or assume path when -analog or the -testbus switches
are specified in apply_attribute.
 [-disable < disable_types >]: Ignores validation of specified list.
Valid values are none, clock, case_analysis, quasi_static,
combo_path, reset, clock_domain, data_path, auto_qualifier,
user_qualifier, and all.
 [-enable < enable_types >]: Enables validation of specified list. Valid
values are none, clock, case_analysis, quasi_static, combo_path,
reset, clock_domain, data_path, auto_qualifier, user_qualifier,
and all.
 [-translate_clocks < translate_clocks >]: Translates block level
internal clocks to boundary-level port.
 [-report_unconstrained_sam_objects <
report_unconstrained_sam_objects >]: By default, only constrained
SAM internal objects are checked for validation mismatch. Set this
option to enable the validation analysis on unconstrained SAM internal
objects.

825
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

Examples
To specify validation checks to be run in express mode, use the following
command:
configure_cdc_validation -express { reset quasi_static
case_analysis }
To specify conditions in which validation checks need to be ignored, use the
following command:
configure_cdc_validation -reduce_pessimism { hanging_net
constant quasi_static ignore_top_reset_mismatch }
To specify the abstract model for which validation configuration is
applicable, use the following command:
configure_cdc_validation -abstract_model sam -disable
{data_path combo_path}

configure_setup_port
Description
Configures the SETUP_PORT_* tags.

Syntax
configure_setup_port
[-report_unconstrained ]

Arguments
 [-report_unconstrained]: Specifies if the SETUP_PORT tags should
perform strict checking on ignored ports. When the value is set to all,
every SETUP_PORT_IGNORED tag violations are transformed into
SETUP_PORT_UNCONSTRAINED violations.

Example
Use the following command to perform strict checking on all ignored ports:
configure_setup_port -report_unconstrained all

826
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

configure_cdc_attribute
Description
Configures the specified cdc attribute. Use this command to specify
mutually-exclusive and unrelated signals such that convergence and glitch-
related violations are suppressed for such signals.

Syntax
configure_cdc_attribute
[-exclusive <exclusive-list>]
[-unrelated <unrelated-list>]

Arguments
 [-exclusive <exclusive-list>]: Specifies the design objects that act
as mutually-exclusive signals in the design.
 [-unrelated <unrelated-list>]: Specifies the design objects that act
as unrelated signals in the design.

Example
Consider the following examples:
configure_cdc_attribute -unrelated {s1 s2 }
configure_cdc_attribute -exclusive {s1 s2 }
configure_cdc_attribute -unrelated { s1 s3 } -exclusive { s2 s4
}

configure_clock_reset_tree
Description
Configures options to control the clock/reset tree browser.

Syntax
configure_clock_reset_tree

827
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Configure Commands

[-ignore_bbox_loads]
[-ignore_bbox_signals]
[-include_intermediate_cones]
[-count_vector_bits]
[-default]
[-include_non_clk_rst_mux]
[-dft_clock_ratio <float_value>]
[-dft_origin_modules <module_name_list>]

Arguments
 [-ignore_bbox_loads]: Ignores counting blackboxes as part of
sequential loads for a cone as well as transitive fanout (TFO).
 [-ignore_bbox_signals]: Ignores the mux-select or clock/reset
enable signals if they originate from a blackbox.
 [-include_intermediate_cones]: By default, only those cone points
are shown which directly connect to sequential elements. If this option
is specified, the intermediate cones with 0 sequential load are included
as well.
 [-count_vector_bits]: Counts all bits of a vector flop width for
sequential count and transitive fanout (TFO). By default, vector flops are
counted as 1.
 [-default]: Resets all configuration settings to their default values.
 [-include_non_clk_rst_mux]: Considers all muxes as candidates for
mux-select. By default, only muxes having > 1 clock/reset inputs are
considered.
 [-dft_clock_ratio <float_value>]: Mux-selects can be classified as
DFT Logic, if they originate in a DFT module and the frequency ratio of
the fastest clock to the slowest clock is above a threshold (Default: 2.0).
Use this argument to configure the frequency ratio threshold.
NOTE: Applies to Clock Tree only.
 [-dft_origin_modules <module_name_list>]: Adds to the module
name patterns for identifying DFT logic. Mux-selects can be classified as
DFT logic, if they originate in a DFT module and the frequency ratio of
the fastest clock to the slowest clock is above a threshold. Use this
option to configure the module name patterns which are used to identify

828
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Configure Commands

DFT modules. If the module name contains the specified strings, it is


considered DFT module. (Default: JTAG, m1500).

configure_cdc_multiflop
Description
Configures reporting of multi-flop chains.

Syntax
configure_cdc_multiflop
[-ignore_modules <module-list>]
[-check_diff_hierarchy <true | false>]
[-enable_merge_vector <true | false>]

Arguments
 [-ignore_modules <module-list>]: Reports a warning if a multi-flop
chain is present in the specified module.
 [-check_diff_hierarchy <true | false>]: Set this argument to
true to report synchronizer flops and multi-flop chains that have
different hierarchy of destinations as a warning.
 [-enable_merge_vector <true | false>]: Set this argument to true
to enable bus merging while reporting multi-flop violations.

Examples
 To ignore synchronizers present in the sync_cell module, use the
following command:
configure_cdc_multiflop -ignore_modules {sync_cell}
 To check diff hierarchy in multiflop synchronizers, use the following
command:
configure_cdc_multiflop -check_diff_hierarchy true
 To enable bus merging while reporting multi-flop violations, use the
following command:
configure_cdc_multiflop -enable_merge_vector true

829
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Database Commands
This section describes the database commands used by VC SpyGlass CDC.

all_clock_gates
Description
This command creates a collection of clock gating cells. If -clock_pins
option is specified, this command creates a collection of clock gating cells
clock pins instead of the collection of clock gating cells.

Syntax
all_clock_gates
[-no_hierarchy]
[-clock_pins]

Arguments
 [-no_hierarchy]: Searches for clock gating cells or their clock pins at
the current level of hierarchy. By default, the search is hierarchical.
 [-clock_pins]: Creates a collection of clock gating cells clock pins. By
default, this command creates a collection of clock gating cells.

all_clocks
Description
This command returns all clocks of the current design.

all_connected
Description
The all_connected command returns a collection of objects connected to
the specified net, port, pin, net instance, or pin instance. A net instance is

830
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

a net in the hierarchy of the design. A pin instance is a pin on a cell in the
hierarchy of a design.
If the -leaf option is used, a list of leaf pins of the net is returned.
To connect nets to ports or pins, use the connect_net command. To break
connections, use the disconnect_net command.

Syntax
all_connected <object>
[-leaf]

Arguments
 <object>: Specifies the object whose connections are returned. The
object must be a net, port, pin, net instance, or pin instance.
 [-leaf]: Specifies that only leaf pins are returned for a hierarchical net.
For non-hierarchical nets, there is no difference in output.

Examples
The following example uses all_connected to return the objects
connected to MY_NET:
prompt> all_connected MY_NET

prompt> connect_net MY_NET OUT3


Connecting net 'MY_NET' to port 'OUT3'.

prompt> connect_net MY_NET U65/Z


Connecting net 'MY_NET' to pin 'U65/Z'.

prompt> all_connected MY_NET


{OUT3 U65/Z}

prompt> all_connected OUT3


{MY_NET}

prompt> all_connected U65/Z


{MY_NET}
This example uses all_connected to associate net load capacitance with

831
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

the net n47, which is connected to the pin instance C/Z:


prompt> set_load 0.147 [all_connected [get_pins U0/U1/C/Z]]
Set "load" attribute to 0.147 for net "U0/U1/n47"

all_designs
Description
The all_designs command returns a collection containing the designs in
the current design hierarchy in bottom-up order. You must set the current
design using the current_design command before using all_designs.

Syntax
all_designs

all_fanin
Description
The all_fanin command reports the fanin of specified sink pins, ports, or
nets in the design. A pin is considered to be in the fanin of a sink if there is
a path through combinational logic from the pin to that sink. The fanin
report stops at the pins of registers (sequential cells).

Syntax
all_fanin
[-to <sink_list>]
[-from <source_list>]
[-through <through_list>]
[-startpoints_only]
[-only_cells]
[-flat]
[-quiet]
[-levels <count>]

832
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

[-pin_levels <pin_count>]
[-step_into_hierarchy]]
[-stop <stop_point_list>]
[-continue_trace <pin_types>]
[-trace_arc <trace_arc>]

Arguments
 [-to <sink_list>]: Reports a list of sink pins, ports, or nets in the
design and a fanin of each sink in the sink_list. If you specify a net, the
effect is the same as listing all driver pins on the net.
 [-from <source_list>]: Specifies a list of source pins, ports, or nets in
the design. The timing fanin of each object in to_list becomes part of
the resulting collection only if it is in the fanout cone of at least one
object in from_list.
 [-through <through_list>]: Specifies a list of through pins, ports, or
nets in the design. Only those points come in result collection only which
passes through the points given in through list.
 [-startpoints_only]: Returns only the startpoints.
 [-only_cells]: Results in a set of all cells in the fanin of the sink_list.
 [-flat]: Specifies to function in the flat mode of operation. The two
major modes in which all_fanin functions are hierarchical (the default)
and flat. When in hierarchical mode, only objects from the same
hierarchy level as the current sink are returned. Thus, pins within a level
of hierarchy lower than that of the sink are used for traversal but are not
reported.
 [-quiet]: Suppresses warning and error messages if no objects match.
 [-levels <count>]: Stops traversal when reaching the perimeter of
the search of count hops, where counting is performed over the layers
of cells that are equidistant from the sink.
 [-pin_levels <pin_count>]: Specifies the number of pins in the
design.
 [-step_into_hierarchy]]: You can only use this option in hierarchical
mode and with either the -levels or -pin_levels option. Without this
option, a hierarchical block at the same level of hierarchy as the current
object is considered to be a cell; the input pins are considered a single

833
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

level away from the related output pins, regardless of what is inside the
block. With the switch enabled, the counting is performed as though the
design were flat, and although pins inside the hierarchy are not
returned, they determine the depth of the related output pins.
 [-stop <stop_point_list>]: Specifies the custom stop points list at
which the traversal must stop. You can specify a collection of names,
any hierarchical name (pin, port, net, instance), design cell names or a
collection of these. When a match is found in the traversal, the traversal
stops at the specified point.
 [-continue_trace <pin_types>]: Overrides the default behavior of
the traversal which is to stop at all endpoints. When specified, the
traversal is permitted through endpoint pins of a type specified with
pin_types. Allowed pin_types include:
 generated_clock_source - Specifies that the traversal is to continue
tracing through source pins of generated clocks including sequential
clock pins in the generated clock source network.
 [-trace_arc <trace_arc>]: Specifies the type of combinational arcs to
trace during the traversal. Allowed combinational arcs types include:
 timing (the default): Traces valid timing arcs only, such as, arcs that
are neither disabled nor invalid due to case analysis.
 enabled: Traces all enabled arcs and disregards case analysis values.
 all: Traces all combinational arcs regardless of case analysis or arc
disabling.

Examples
The following examples show the fanin of a port in the design. The design
comprises three inverters in a chain named iv1, iv2, and iv3. The iv1 and
iv2 inverters are hierarchically combined in a larger cell named ii2.
prompt> all_fanin -to tout
{ii2/hin iv3/in iv3/out tin ii2/hout tout}

prompt> all_fanin -to tout -flat


{ii2/iv1/U1/a ii2/iv2/U1/z tin iv3/U1/a ii2/iv1/U1/z
ii2/iv2/U1/a iv3/U1/z tout}
The following example shows the fanout of a port in the design. The design
comprises the following three inverters in a chain named iv1, iv2, and iv3.
The iv1 and iv2 inverters are hierarchically combined in a larger cell named

834
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

ii2.
prompt> all_fanin -to tout
{"ii2/hout", "iv3/out", "ii2/hin", "iv3/in", "tin", "tout"}

prompt> all_fanin -to tout -flat


{"ii2/iv1/U1/Z", "ii2/iv1/U1/A", "ii2/iv2/U1/Z", "ii2/iv2/U1/
A", "iv3/U1/Z", "iv3/U1/A", "tin", "tout"}

prompt> all_fanin -to tout -stop ii2/hout


{"ii2/hout", "iv3/out", "iv3/in", "tout"}

prompt> all_fanin -to tout -stop {iv3/U1/A ii2/hout}


{"iv3/out", "tout", "iv3/out"}

all_fanout
Description
The all_fanout command reports the fanout of specified source pins,
ports, or nets in the design. A pin is considered to be in the fanout of a sink
if there is a path through combinational logic from that source to the pin.
The fanout report stops at the inputs to registers (sequential cells). The
source pins or ports are specified by using the -from source_list option.

Syntax
all_fanout
[-from <source_list>]
[-endpoints_only]
[-only_cells]
[-flat]
[-levels <count>]
[-pin_levels <pin_count>]
[-step_into_hierarchy]
[-stop <stop_point_list>]

835
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

[-exclude_resetless]
[-only_resetless]

Arguments
 [-from <source_list>]: Specifies a list of source pins, ports, or nets in
the design. The fanout of each source in the source_list is reported. If a
net is specified, the effect is the same as listing all load pins on the net.
The -clock_tree and -from options are mutually exclusive.
 [-endpoints_only]: Returns only endpoints as a result.
 [-only_cells]: Results in a set of all cells in the fanout of the
source_list, rather than a set of pins or ports.
 [-flat]: Specifies to function in the flat mode of operation. The two
major modes in which all_fanout functions are hierarchical (the default)
and flat. When in hierarchical mode, only objects from the same
hierarchy level as the current source are returned. Thus, pins within a
level of hierarchy lower than that of the source are used for traversal
but are not reported.
 [-levels <count>]: Stops traversal when reaching the perimeter of
the search of count hops, where counting is performed over the layers
of cells that are equidistant from the source.
 [-pin_levels <pin_count>]: Specifies the number of pins in the
design.
 [-step_into_hierarchy]: You can use this option only in hierarchical
mode with either the -levels or -pin_levels option. Without this option, a
hierarchical block at the same level of hierarchy as the current object is
considered to be a cell; the output pins are considered a single level
away from the related input pins, regardless of what is inside the block.
With the switch enabled, the counting is performed as though the design
were flat, and although pins inside the hierarchy are not returned, they
determine the depth of the related input pins.
 [-stop <stop_point_list>]: Specifies the custom stop points list.
 [-exclude_resetless]: Specifies to exclude fanout objects that are
reset-less flops.
 [-only_resetless]: Specifies to report only reset-less flops as fanout
objects.

836
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Examples
The following example shows the fanout of a port in the design. The design
comprises the following three inverters in a chain named iv1, iv2, and iv3.
The iv1 and iv2 inverters are hierarchically combined in a larger cell named
ii2.
prompt> all_fanout -from tin
{iv3/out tout iv3/in ii2/hin ii2/hout tin}

prompt> all_fanout -from tin -flat


{tout ii2/iv2/U1/z ii2/iv1/U1/a iv3/U1/z iv3/U1/a
ii2/iv2/U1/a ii2/iv1/U1/z tin}

prompt> all_fanout -from tin -levels 1 -only_cells


{iv3 ii2}

all_inputs
Description
The all_inputs command returns a collection of all input or inout ports in
the current design, unless one of the options limits the search. The
all_inputs command is usually used with a command that places attributes
on input ports. To get detailed information on ports in the current design,
use the report_port command.

Syntax
all_inputs

Examples
The following example lists all input ports in the current design:
prompt> all_inputs
{A1 A2 BIDIR1}
The following example sets the drive value of all the input ports on the
current design to 10:
prompt> set_drive 10.0 [all_inputs]
The following example marks with a multicycle value of 0 all paths from

837
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

inputs having level-sensitive input delay relative to PHI1 to level-sensitive


registers clocked by PHI1:
prompt> set_multicycle_path 0 \\
-from [all_inputs -clock PHI1 -level_sensitive] \\
-to [all_registers -data_pins -clock PHI1]

all_instances
Description
Create a collection of all instances of a design (stub)

Syntax
all_instances [<>]
[-hierarchical]

Arguments
 [<>]: Target design or lib cell name.
 [-hierarchical]: Search for instances hierarchically

all_outputs
Description
The all_outputs command returns a collection of all output or inout ports in
the current design, unless one of the options limits the search. This
command is usually used with a command that places attributes on output
ports. To get detailed information on ports in the current design, use the
report_port command.

Syntax
all_outputs

Examples
The following example lists all output ports:

838
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

prompt> all_outputs
{OUT1 OUT2 BIDIR1}

change_link
Description
The change_link command specifies a design for which to change the link
for a cell. If you specify a cell in the object list, the command changes it to
one occurrence of the specified design. You can change the cell link only to
a compatible design.For example, the design must have the same number
of ports with the same name and direction as the cell or reference.

Syntax
change_link <object_name_list>
[-force]
[-all_instances]
[-pin_map <pin map table>]

Arguments
 <object_name_list>: Specifies the cells or references in the current
design for which to change the link.
 <design_name>: Specifies the name of the design to which to link the
cells or references in the object list.
 [-force]: Enables the command to allow mismatched pin counts, as
long as any mismatched cells in the object list have fewer pins than the
specified design.
 [-all_instances]: Enables the command to accept instance cells in
the object list.
 [-pin_map <pin map table>]: Specifies the pin mapping used to map
old pin names to new pin names.The pin name must be the reference
cell pin name.To specify the pin mapping, use the following Syntax
{{old_pin1 new_pin1} ... {old_pin_n new_pin_n}} New pins maintain
the same net connections as the corresponding old pins.

839
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Examples
The following example creates a cell named cell1 under the sub design
corresponding to the mid1 cell:
vc_static_shell> create_cell cell1 my_lib/AND2
[Info] ADD_CELL: Creating cell 'cell1' in design 'mid1'.

configure_mem_macro_inference
Description
This command is used to specify the constraint for Memory Macro
Inference in synthesis.

Syntax
configure_mem_macro_inference
-mthresh int
-infer_1dmem
-skip_infer

Arguments
 -mthresh int: Use this option to specify the width of signal beyond
which memory inference will get triggered.The default value is 4096.
 -infer_1dmem: Use this option to specify the memory inference for
vector signal.
 -skip_infer: Use this option to skip the memory macro inference.

connect_net
Description
Connects the specified net to the specified pins or ports. This command
connects a net to the specified pins or ports at the same hierarchical level.
The net can be at any level of hierarchy but the pins or ports must be at
the same level. A net can be connected to many pins or ports; however,

840
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

you cannot connect a pin or port to more than one net. To disconnect
objects on a net, use the disconnect_net command. To display pins and
ports on a net, use either the all_connected or get_nets -of $net command.
Multicorner-Multimode Support This command has no dependency on
scenario-specific information.

Syntax
connect_net <net_name>

Arguments
 <net_name>: Specifies the net to connect. The net must be a scalar
(single bit) net, and must exist in the current design.
 <object_list>: Specifies a list of pins and ports to which the net is to
be connected. Pins and ports must be at the same hierarchical level as
the specified net, and must exist in the current design. If a specified pin
or port is already connected, the tool issues an error message. Use this
option to specify the list of nets

Examples
The following example uses connect_net to connect net NET0 to ports A1
and A2 and pin U1/A. The all_connected command returns the objects
connected to net NET0.
vc_static_shell> connect_net NET0 [get_ports {A1 A2}]
vc_static_shell> connect_net NET0 [get_pins U1/A]
vc_static_shell>all_connected NET0
{A1 A2 U1/A}

create_bus
Description
The create_bus command creates a bus object of the type port or net. The
number of objects in the list determines the bus width. Buses appear as
multibit ports on a design or as multiwire nets in a design. This command
groups any number of ports or any number of nets into a bus object.
Unless the -sort or -no_sort option is selected, the specified objects are
sorted by reverse alphanumeric order of names before the bus is created.

841
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

When using Design Vision to create a design schematic, bused nets are
inferred from bused ports or pins in the design. Bused nets only appear as
nets in a schematic if they are connected to a bused port. If the start bit
and end bit for the bus are specified with the -start and -end options, the
bus is created with these start and end indices. If only the start bit is
specified, an upward-going bus starting at that start bit is built. If only the
end bit is specified, an upward going bus ending at that end bit is built.

Syntax
create_bus <net_name_list>
[-start <start bit>]
[-end <end bit>]

Arguments
 <net_name_list>: Specifies a list of ports or nets to be put into a bus.
If both ports and nets have the same names, the ports are put into the
bus. This option is required.
 <bus_name>: Specifies the name of the bus. This name cannot be the
same as any other bus or object of the same type. Port bus names must
be different from the names of ports, and net bus names must be
different from the names of nets. This option is required.
 [-start <start bit>]: Specifies the start bit for the bus.
 [-end <end bit>]: Specifies the end bit for the bus.

Examples
This example groups the A1, A2, and A3 ports into a bus named A. The
ports must already exist. The order in which the ports appear in the bus is
A3, A2, A1.
vc_static_shell> create_bus {A1 A2 A3} A
This example groups the existing D1, D2, and D3 ports into a bus named D
and assigns it the index range 6-to-4. Port D1 is assigned index 6, port D2
to index 5, and port D3 to index 4.
vc_static_shell> create_bus {D1 D2 D3} D -start 6 -end 4

842
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

create_cell
Description
This command creates new leaf orhierarchical cells in the current design or
its subdesigns based on the cell_list argument. New leaf cells are the
instantiation of an existing design or library cell. New hierarchical cells are
the instantiation of a new design. New cells are the instantiation of an
existing design, a library cell, a logic 0 generator, or a logic 1 generator.
The created cells are unplaced. To be viewed properly in the GUI, the cells
must be placed either manually by using the set_cell_location command or
automatically by using placement commands. To remove cells from the
current design, use the remove_cell command. Although the
reference_name argument accepts names in the format library/library_cell,
the command might not instantiate the actual library cell from the specified
library. The actual library cell to be used is determined by the current link
library settings.

Syntax
create_cell <reference> [<reference>]
[-only_physical]
[-hierarchical]
[-logic <logic_value>]

Arguments
 <reference>: Specifies the design or library cell that new cells
reference. You must specify the reference_name. Ports on the reference
determine the name, number, and direction of pins on the new cell.
 [<name_list>]: Specifies the names of cells created in the current
design. Each cell name must be unique within the current design.
 [-only_physical]: Creates a new physical or physical-only cell using a
reference from the physical library. The -only_physical option sets the
is_physical_only attribute on the created physical-only cell. After you
create a physical-only cell, you must assign a location to that cell. Unlike
physical cells with logic functions, the tool does not assign a location to
a physical-only cell during synthesis. To assign a location, use the

843
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

set_cell_location command, Tcl commands, or a DEF file. By default, this


option is off.
 [-hierarchical]: Creates hierarchical cell instances and designs with
the name given by cell_list if the reference_name is not specified. If you
specify the reference_name, the cell_list must have a single element.
The command creates the hierarchical cell instance with the name given
by the single cell_list and also creates the design with the name given
by reference_name.
 [-logic <logic_value>]: Specifies that the new cell generates a logic
0 or logic 1 value. The logic value must be either 0 or 1. By using this
option, the cell contains a single output pin. By default, this option is off.

Examples
The following example creates a cell named cell1 under the subdesign
corresponding to the mid1 cell:
vc_static_shell> create_cell {mid1/cell1} my_lib/AND2
[Info] ADD_CELL: Creating cell 'cell1' in design 'mid1'.
The following example creates a cells with -hierarchical option
vc_static_shell> create_cell -hierarchical {H2 H3} my_lib/AND2
[Info] ADD_CELL: Creating cell 'H2' in design 'test'.
[Info] ADD_CELL: Creating cell 'H3' in design 'test'.

create_net
Description
The create_net command creates new net objects in the current design or
its subdesign based on the net_list argument. The create_net command
creates only scalar (single bit) nets. To bundle scalar nets into buses, use
the create_bus command. Nets connect pins and ports in a design. When
you create nets with create_net, they are not connected. To establish this
connection, use the connect_net command. To remove nets from the
current design, use the remove_net command.

Syntax
create_net <name_list>

844
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Arguments
 <name_list>: Specifies the names of the created nets. If you specify a
hierarchical net name, the net is created in the specified instance. The
net name must be unique within the current design or the subdesign
where it is created. If you use a hierarchical net name, the parent
instance must be unique; it cannot be an instance of a multiply-
instantiated design. This option is required.

Examples
The following example uses create_net to create net objects in the current
design :
vc_static_shell> create_net {N1 N2 N3 N4}
[Info] ADD_NET: Creating net 'N1' in design 'test'.
[Info] ADD_NET: Creating net 'N2' in design 'test'.
[Info] ADD_NET: Creating net 'N3' in design 'test'.
[Info] ADD_NET: Creating net 'N4' in design 'test'.
The following example uses create_net to create net objects in the mid
subdesign. Note that mid1 is an instance of the mid design. The mid design
must be unique for the create_net command to succeed.
vc_static_shell> create_net {mid1/N1 mid1/N2 mid1/N3 mid1/N4}
[Info] ADD_NET: Creating net 'N1' in design 'mid1'.
[Info] ADD_NET: Creating net 'N2' in design 'mid1'.
[Info] ADD_NET: Creating net 'N3' in design 'mid1'.
[Info] ADD_NET: Creating net 'N4' in design 'mid1'.

create_port
Description
The create_port command creates new port objects in the current design
or its subdesign. The create_port command creates only scalar or single bit
ports. To bundle scalar ports into buses, use the create_bus command.
Ports are the external connection points on a design. To connect ports to
nets inside a design, use the connect_net command. To remove ports from
the current design, use the remove_port command. Multicorner-Multimode
Support This command has no dependency on scenario-specific
information.

845
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Syntax
create_port <name_list>
[-direction <dir>]

Arguments
 <name_list>: Specifies names of ports created in the current design.
Each port name must be unique within the current design.
 [-direction <dir>]: Specifies the signal flow of the created port. The
possible values are in, out, or inout. The default is in.

Examples
The following example uses create_port to create ports in the current
design
vc_static_shell> create_port -direction "in" {A1 A2 A3 A4}
[Info] ADD_PORT: Creating port 'A1' in design 'test'.
[Info] ADD_PORT: Creating port 'A2' in design 'test'.
[Info] ADD_PORT: Creating port 'A3' in design 'test'.
[Info] ADD_PORT: Creating port 'A4' in design 'test'.
The following example uses create_port to create ports in the U1
subdesign.
vc_static_shell> create_port -direction "in" {U1/B1 U1/B2 U1/B3
U1/B4}
[Info] ADD_PORT: Creating port 'B1' in design 'U1'.
[Info] ADD_PORT: Creating port 'B2' in design 'U1'.
[Info] ADD_PORT: Creating port 'B3' in design 'U1'.
[Info] ADD_PORT: Creating port 'B4' in design 'U1'.

define_user_attribute
Description
This command defines a new attribute. Use the list_attributes command to
list the attributes that you have defined.
The definition for a user-defined attribute can be persistent if it has been
set on a specified object and stored in the database.

846
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Syntax
define_user_attribute <attr_name>
[-type <string | int | float | double | boolean>]
-classes <cell | clock | design | lib_cell | lib_pin | net |
net_word | pin | pin_word | port | port_word>
[-range_min <min>]
[-range_max <max>]
[-one_of <values>]

Arguments
 <attr_name>: Specifies the name of the attribute.
 [-type <string | int | float | double | boolean>]: Specifies the
data type of the attribute. Specifies the classes for the new user-defined
attribute. Valid classes are design, port, cell, net, etc.
 -classes <cell | clock | design | lib_cell | lib_pin | net |
net_word | pin | pin_word | port | port_word>: Specifies the
type of the object on which the new attribute is created.
 [-range_min <min>]: Specifies the minimum value for numeric ranges.
This option is valid only when the data type of the attribute is int or
double. Specifying a minimum constraint without a maximum constraint
creates an attribute that accepts a value greater than or equal to min.
 [-range_max <max>]: Specifies the maximum value for numeric ranges.
This option is valid only when the data type of the attribute is int or
double. Specifying a maximum constraint without a minimum constraint
creates an attribute that accepts a value less than or equal to max.
 [-one_of <values>]: Provides a list of allowable strings. This option is
valid only when the data type of the attribute is string.

Examples
The following example defines an attribute named attr_1, which has a data
type of double with a minimum value of 2 and a maximum value of 3.2 and
can be set on cells or nets.
prompt> define_user_attribute -class {cell net} -type double \\
-range_max 3.2 -range_min 2 attr_1

847
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

The following example defines an attribute named attr_2, which has a data
type of string with valid values of true or false and can be set on nets.
prompt> define_user_attribute -class net -type string \\
-one_of {true false} attr_2
The following example shows how to list the attribute definitions using the
list_attributes command:
prompt> list_attributes

disconnect_net
Description
The disconnect_net command breaks the connections between a net or a
net instance and its pins or ports. The net, pins, and ports are not
removed. This command accepts only scalar (single bit) nets, and not
bused nets. To connect nets, use the connect_net command. To display the
pins and ports connected to a net, use the all_connected command.

Syntax
disconnect_net <net_name>
Default Argument <net_name>
Specifies the net name or net instance name to disconnect. A net must
exist in the current design.
 Default Argument: <object_name_list>
Specifies the pins and ports disconnected from the net. Only pins and ports
existing in the current design are specified. Either object_list or -all must
be specified.

Examples
The following examples disconnect nets using the disconnect_net
command:
disconnect_net NET0 [get_ports A1]
Disconnecting net 'NET0' from port 'A1'
disconnect_net NET0 [get_pins U1/A]
Disconnecting net 'NET0' from pin 'U1/A'.

848
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

find
Description
Finds objects of specific object type

Syntax
find [<>]
[-hierarchy]
 Default Argument: [<>]
Specifies object type: Values: cell, design, lib_cell, lib_pin, net, pin, port
 Default Argument: [<>]
Specifies a list of names of design or library objects

Arguments
 [-hierarchy]: Specifies to return all objects matching type and
name_listwithin the current design hierarchy

get_cdc_sequentials
Description
The get_cdc_sequentials command retrieves the collection of sequentials
pins/ports driven by given clocks or clock domains.

Syntax
get_cdc_sequentials
-of_objects <obj_list>
Arguments
 -of_objects <obj_list>: List of clocks or clock_domains

get_cells

849
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Description
This command creates a collection of cells that match the specified criteria.
By default, the command creates the collection of cells from the current
design, relative to the current instance.
If the command cannot find any cells that match the criteria and the
current design is not linked, the design automatically links.
The command returns a collection if any cell matches the criteria. If no
object matches the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_cells [<patterns>]
[-hierarchical]
[-quiet]
[-regexp]
[-nocase]
[-exact]
[-filter <expression>]
[-of_objects <objects>]

Arguments
 Default Argument: [<patterns>]: Creates a collection of cells whose
names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man

850
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

page. Pattern matching is case sensitive unless you use the -nocase
option. are mutually exclusive; you can specify only one. If you do not
specify any of these arguments, the command uses * (asterisk) as the
default pattern.
 [-hierarchical]: Searches for cells level-by-level, relative to the
current instance. The name of the object at a particular level must
match the patterns. For example, if there is a cell block1/adder, a
hierarchical search finds it using "adder". By default, the search is not
hierarchical.
 [-quiet]: Suppresses warning and error messages if no object
matches. Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive. You can
specify only one of these options.
 [-nocase]: Makes matches case-insensitive, both for the patterns
argument and for the ==, =~, and !~ filter operators.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards.
 [-filter <expression>]: Filters the collection with the specified
expression. For each cell in the collection, the expression is evaluated
based on the cell's attributes. If the expression evaluates to true, the
cell is included in the result. To see the list of cell attributes that you can
use in the expression, use the list_attributes -application -class cell
command. For more information about how to use the -filter option, see
the filter_collection man page.
 [-of_objects <objects>]: Creates a collection of cells connected to
the specified objects. arguments are mutually exclusive; you can specify
only one. If you do not specify any of these arguments, the command

851
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

uses the * (asterisk) as the default pattern. In addition, you cannot use
the -hierarchical option with the -of_objects option.

Examples
The following example queries the cells that begin with "o" and reference
an FD2 library cell. Although the output looks like a list, it is only a display.
prompt> get_cells "o*" -filter "@ref_name == FD2"
{o_reg1 o_reg2 o_reg3 o_reg4}
The following example queries the cells connected to a collection of pins.
prompt> set pinsel [get_pins o*/CP]
{o_reg1/CP o_reg2/CP}

prompt> get_cells -of_objects $pinsel


{o_reg1 o_reg2}
The following example queries the cells connected to a collection of nets.
prompt> set netsel [get_nets tmp]
{tmp}

prompt> get_cells -of_objects $netsel


{b c}

get_designs
Description
The get_designs command creates a collection of designs from those
currently loaded into the tool that match certain criteria. The command
returns a collection if any designs match the patterns and pass the filter (if
specified). If no objects match your criteria, the empty string is returned.
Regular expression matching is the same as in the Tcl regexp command.
When using -regexp, take care in the way you quote the patterns and filter
expression. Using rigid quoting with curly braces around regular
expressions is recommended. Regular expressions are always anchored.
The expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen the
search simply by adding ".*" to the beginning or end of the expressions as
needed.

852
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

You can use the get_designs command at the command prompt, or you
can nest it as an argument to another command, such as query_objects. In
addition, you can assign the get_designs result to a variable.
When issued from the command prompt, get_designs behaves as though
query_objects has been called to display the objects in the collection. By
default, a maximum of 100 objects is displayed. You can change this
maximum using the collection_result_display_limit variable.
The implicit query property of get_designs provides a fast, simple way to
display designs in a collection. However, if you want the flexibility provided
by the query_objects options (for example, if you want to display the
object class), use get_designs as an argument to query_objects.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_designs
[-hierarchical]
[-quiet]
[-regexp]
[-nocase]
[-exact]
[-filter <expression>]

Arguments
 [-hierarchical]: Searches for designs inferred by the design
hierarchy relative to the current instance. The full name of the object at
a particular level must match the patterns. The use of this option does
not force an auto link.
 [-quiet]: Suppresses warning and error messages if no objects match.
Syntax error messages are not suppressed.
 [-regexp]: Uses the patterns argument as real regular expressions
rather than simple wildcard patterns.
 [-nocase]: Makes matches case-insensitive.

853
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

 [-exact]: Disables simple pattern matching. This is used when


searching for objects that contain the * (asterisk) and ? (question mark)
wildcard characters.
 [-filter <expression>]: Filters the collection with expression. For
any designs that match patterns, the expression is evaluated based on
the design's attributes. If the expression evaluates to true, the design is
included in the result.

Examples
The following example queries the designs that begin with mpu. Although
the output looks like a list, it is just a display. A complete listing of designs
is available using the list_designs command.
prompt> get_designs mpu*
{mpu_0_0 mpu_0_1 mpu_1_0 mpu_1_1}
The following example shows that, given a collection of designs, you can
remove those designs:
prompt> remove_design [get_designs mpu*]
Removing design mpu_0_0...
Removing design mpu_0_1...
Removing design mpu_1_0...
Removing design mpu_1_1...

get_lib_cells
Description
This command creates a collection of library cells from the libraries
currently loaded into memory that match the specified criteria.
If no libraries have been loaded into memory, the tool loads the libraries
specified in the link_library variable into memory the first time you run the
get_libs, get_lib_cells, or get_lib_pins command.
If you use the -scenarios option, only libraries associated with the specified
scenarios are included in the search.
The command returns a collection if any library cells match the criteria. If
no objects match the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an

854
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

argument to another command, such as query_objects. In addition, you


can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_lib_cells <patterns>
[-quiet]
[-regexp]
[-exact]
[-nocase]
[-filter <expression>]
[-of_objects <objects>]

Arguments
 Default Argument: <patterns>: Creates a collection of library cells
whose names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. The patterns and -of_objects arguments are mutually exclusive;
you must specify one.
 [-quiet]: Suppresses warning and error messages if no objects match.
Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.

855
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.
 [-nocase]: Makes matches case-insensitive, both for the patterns
argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each library cell in the collection, the expression is
evaluated based on the library cell's attributes. If the expression
evaluates to true, the library cell is included in the result. To see the list
of library cell attributes that you can use in the expression, use the
list_attributes -application -class lib_cell command. For more
information about how to use the -filter option, see the filter_collection
man page.
 [-of_objects <objects>]: Creates a collection of library cells that are
referenced by the specified cells or own the specified library pins. Each
object is either a named library pin, a netlist cell, a library pin collection,
or a netlist cell collection. The patterns and -of_objects arguments are
mutually exclusive; you must specify one.

Examples
The following example queries all library cells that are in the misc_cmos
library whose names begin with AN2. Although the output looks like a list,
it is just a display.
prompt> get_lib_cells misc_cmos/AN2*
{misc_cmos/AN2 misc_cmos/AN2P}
The following example shows one way to determine the library cell used by
a particular cell instance:
prompt> get_lib_cells -of_objects [get_cells o_reg1]
{misc_cmos/FD2}

856
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

get_lib_pins
Description
This command creates a of library cell pins from the libraries currently
loaded into memory that match the specified criteria.
If no libraries have been loaded into memory, the tool loads the libraries
specified in the link_library variable into memory the first time you run the
get_libs, get_lib_cells, or get_lib_pins command.
The command returns a collection if any library cell pins match the criteria.
If no objects match the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_lib_pins <patterns>
[-quiet]
[-regexp]
[-exact]
[-nocase]
[-filter <expression>]
[-of_objects <objects>]

Arguments
 Default Argument: <patterns>: Creates a collection of library cell pins
whose names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more

857
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. The patterns and -of_objects arguments are mutually exclusive;
you must specify one.
 [-quiet]: Suppresses warning and error messages if no objects match.
Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.
 [-nocase]: Makes matches case-insensitive, both for the patterns
argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each library cell pin in the collection, the expression is
evaluated based on the library cell pin's attributes. If the expression
evaluates to true, the library cell pin is included in the result. To see the
list of library cell pin attributes that you can use in the expression, use
the list_attributes -application -class lib_pin command. For more
information about how to use the -filter option, see the filter_collection
man page.
 [-of_objects <objects>]: Creates a collection of library cell pins
referenced by the specified netlist Each object is either a named library
cell, netlist pin, library cell collection, or a netlist pin collection. The
patterns and -of_objects arguments are mutually exclusive; you must
specify one.

858
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Examples
The following example queries all pins of the AN2 library cell in the
misc_cmos library. Although the output looks like a list, it is just a display.
prompt> get_lib_pins misc_cmos/AN2/*
{misc_cmos/AN2/A misc_cmos/AN2/B misc_cmos/AN2/Z}
The following example shows one way to find out how the library pin is
used by a particular pin in the netlist:
prompt> get_lib_pins -of_objects o_reg1/Q
{misc_cmos/FD2/Q}

get_lib_timing_arcs
Description
Creates a collection of library arcs for custom reporting and other
processing. You can assign these library arcs to a variable and get the
desired attribute for further processing.

Syntax
get_lib_timing_arcs
[-to <to_list>]
[-from <from_list>]
[-of_objects <cell list>]
[-filter <expression>]
Arguments
 [-to <to_list>]: Specifies the "to" library pins, or ports. All backward
library arcs from the specified library pins or ports are considered.
 [-from <from_list>]: Specifies the "from" library pins, or ports. All
forward library arcs from the specified library pins or ports are
considered.
 [-of_objects <cell list>]: Specifies library cells or timing arcs. If a
library cell is specified, all library cell arcs of that cell are considered. If a
timing arc collection is given in the object list, the corresponding library
timing arc is considered.

859
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

 [-filter <expression>]: Specifies the filter expression. A filter


expression is a string that comprises a series of logical expressions
describing a set of constraints you want to place on the collection of
library arcs. Each subexpression of a filter expression is a relation
contrasting an attribute name with a value, by means of an operator.

Examples
The following examples show the usage of the get_lib_timing_arcs
command:
vc_static_shell> get_lib_timing_arcs -of_objects [get_lib_cells
*/*]
{"tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/
INVD20BWP16P90LVT/I
tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/INVD20BWP16P90LVT/
ZN", "tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/
INVD4BWP16P90LVT/I
tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/INVD4BWP16P90LVT/
ZN"}
The following examples show the usage of the get_lib_timing_arcs
command:
vc_static_shell> get_lib_timing_arcs -from
tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/INVD20BWP16P90LVT/
I -to tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/
INVD20BWP16P90LVT/ZN -filter "object_class == lib_timing_arc"
{"tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/
INVD20BWP16P90LVT/I
tcbn16ffllbwp16p90lvtffgnp0p6v125c_ccs_cchp0/INVD20BWP16P90LVT/
ZN"}

get_libs
Description
This command creates a collection of libraries from the libraries currently
loaded into memory that match the specified criteria.
If no libraries have been loaded into memory, the tool loads the libraries
specified in the link_library variable into memory the first time you run the
get_libs, get_lib_cells, or get_lib_pins command.

860
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

The command returns a collection if any library matches the criteria. If no


library matches the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_libs [<patterns>]
[-quiet]
[-regexp]
[-exact]
[-nocase]
[-filter <expression>]
[-of_objects <objects>]

Arguments
 Default Argument: [<patterns>]: Creates a collection of libraries
whose names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. The patterns and -of_objects arguments are mutually exclusive;
you can specify only one. If you do not specify any of these arguments,
the command uses the * (asterisk) as the default pattern.
 [-quiet]: Suppresses warning and error messages if no object
matches. Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of

861
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

the =~ and !~ filter operators to use regular expressions rather than


simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.
 [-nocase]: Makes matches case-insensitive, both for the patterns
argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each library in the collection, the expression is evaluated
based on the library's attributes. If the expression evaluates to true, the
library is included in the result. To see the list of library attributes that
you can use in the expression, use the list_attributes -application -class
lib command. For more information about how to use the -filter option,
see the filter_collection man page.
 [-of_objects <objects>]: Creates a collection of libraries that contain
the specified objects. Each object is either a named library cell or a
library cell collection. The patterns and -of_objects arguments are
mutually exclusive; you can specify only one. If you do not specify any
of these arguments, the command uses the * (asterisk) as the default
pattern.

Examples
The following example queries all loaded libraries. Use the list_libs
command to get a complete listing of the libraries.
prompt> get_libs
{misc_cmos misc_cmos_io}

get_link

862
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Description
This command returns the designs built with reason code using Simon/
VNR.

Syntax
get_link
-reasons <reason_list>
Arguments
 -reasons <reason_list>: Use this option to specify the reason list.
The values are AutoBB, AutoGB, DirtyData, Empty, PhysicalCell,
SimDirection, SimMatch, SimPort, SimWidth, Synthesis, Unresolved,
UserBB, and UserGB.

get_nets
Description
This command creates a collection of nets in the current design relative to
the current instance that match the specified criteria.
The command returns a collection if any nets match the specified criteria.
If no objects match the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_nets <patterns>
[-regexp]

863
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

[-exact]
[-nocase]
[-filter <expression>]
[-hierarchical]
[-filter <expression>]
[-quiet]
[-top_net_of_hierarchical_group]
[-segments]
[-of_objects <objects>]

Arguments
 Default Argument: <patterns>: Creates a collection of nets whose
names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. mutually exclusive; you can specify only one. If you do not
specify any of these arguments, the command uses * (asterisk) as the
default pattern.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.

864
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

 [-nocase]: Makes matches case-insensitive, both for the patterns


argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each net in the collection, the expression is evaluated
based on the net's attributes. If the expression evaluates to true, the
net is included in the result. To see the list of net attributes that you can
use in the expression, use the list_attributes -application -class net
command. For more information about how to use the -filter option, see
the filter_collection man page.
 [-hierarchical]: Searches for nets level-by-level relative to the
current instance. The name of the object at a particular level must
match the patterns. For example, if there is a net named block1/muxsel,
a hierarchical search finds it using muxsel.
 [-filter <expression>]: Filters the collection with the value of the
expression argument. For any nets that match the specified criteria, the
expression is evaluated based on the net's attributes. If the expression
evaluates to true, the net is included in the result.
 [-quiet]: Suppresses messages if no objects match. Syntax error
messages are not suppressed.
 [-top_net_of_hierarchical_group]: Keeps only the top net of a
hierarchical group. When more than one hierarchical net of the same
group is specified (local nets at various hierarchical levels of the same
physical net), only the net closest to the top of the hierarchy is saved in
the collection. In the case of multiple nets at the same level, the first net
specified is kept. To get the top hierarchical net connected to a single
net, need to use this option in combination with the -segments option.
 [-segments]: Modifies the initial search that matches the patterns or -
of_object argument to include all global segments for the matching
nets. Global net segments are all the net segments that are physically
connected across all hierarchical boundaries. This option is best used
with a single net. When you use the -segments option with the -
top_net_of_hierarchical_group option, you can isolate the highest net
segment of a physical net.
 [-of_objects <objects>]: Creates a collection of nets connected to
the specified objects. arguments are mutually exclusive; you can specify
only one. If you do not specify any of these arguments, the command
uses * (asterisk) as the default pattern. You cannot use the -hierarchical
option with the -of_objects option.

865
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Examples
The following example queries the nets that begin with NET in a block
named block1. Although the output looks like a list, it is a display.
prompt> get_nets block1/NET*
{block1/NET1QNX block1/NET2QNX}
The following example queries the nets connected to a collection of pins.
prompt> current_instance block1
block1
prompt> set pinsel [get_pins {o_reg1/QN o_reg2/QN}]
{o_reg1/QN o_reg2/QN}
prompt> get_nets -of_objects $pinsel
{NET1QNX NET2QNX}
The following example queries the nets connected to a collection of cells.
prompt> current_instance block1
block1
prompt> set cellsel [get_cells {o_reg1 o_reg2}]
{o_reg1 o_reg2}
prompt> get_nets -of_objects $cellsel
{NET1QX NET1QNX NET1DX NET2QX NET2QNX NET2DX}
The following examples use the design shown below to show the behavior
of the get_nets command with various options. There is a buffer instance
named buffer in the L3 instance.
+------------------------------------+
| L1 |
| +-----------------------+ |
| | L2 | |
| | +------------+ | |
| | | L3 | | |
| | | | | |
net1 | net2 | net3 | net4 | | |
--------+------+------+------> | | |
| | | | | |
| | +------------+ | |
| | | |
| +-----------------------+ |
| |
+------------------------------------+

866
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

When you use the -of_objects option by itself, the command gets only the
net that connects to a pin directly.
prompt> get_nets -of_objects L1/L2/L3/buffer/A
{L1/L2/L3/net_4}
When you also use the -segments option, the command gets all the
hierarchical nets that connect together through the hierarchical pins.
prompt> get_nets -of_objects L1/L2/L3/buffer/A -segments
{L1/L2/L3/net_4 L1/L2/net_3 L1/net_2 net_1}
When you use the -segments and -top_net_of_hierarchical_group option
together, the command returns only the net in the topmost hierarchical net
group.
prompt> get_nets -of_objects L1/L2/L3/buffer/A -segments \
-top_net_of_hierarchical_group
{net_1}
The following examples use the patterns argument to select the nets.
prompt> get_nets net*4 -hierarchical
{L1/L2/L3/net_4}

prompt> get_nets net*4 -hierarchical -segments


{L1/L2/net_3 net_1 L1/L2/L3/net_4 L1/net_2}

prompt> get_net net*4 -hierarchical -segments -filter


name==net_2
{L1/net_2}

get_object_name
Description
This command returns a list of names of the objects in a collection.

Syntax
get_object_name <collection>
Default Argument <collection>
Specifies the name of the collection that contains objects whose names are
requested.

867
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Examples
The following example returns the name top as the object contained in the
collection returned by the current_design command.
prompt> get_object_name [current_design]
Current design is 'top'.
top

get_pins
Description
This command creates a collection of pins in the current design relative to
the current instance that match the specified criteria.
arguments do not match any objects and the current design is not linked,
the design automatically links.
The command returns a collection if any pins match the specified criteria. If
no objects match the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.

Syntax
get_pins <patterns>
[-hierarchical]
[-quiet]
[-regexp]
[-exact]
[-nocase]

868
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

[-filter <expression>]
[-of_objects <objects>]
[-leaf]
[-all]

Arguments
 Default Argument: <patterns>: Creates a collection of pins whose
names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. arguments are mutually exclusive; you can specify only one. If
you do not specify any of these arguments, the command uses *
(asterisk) as the default pattern.
 [-hierarchical]: Searches for pins level-by-level, relative to the
current instance. The name of the object at a particular level must
match the patterns. The search is similar to that of the UNIX find
command. For example, if there is a pin named block1/adder/D[0], a
hierarchical search finds it by using adder/D[0]. The -hierarchical option
is mutually exclusive with use the -of_objects option; you can use only
one.
 [-quiet]: Suppresses warning and error messages if no objects match.
Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.

869
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

 [-exact]: Considers wildcards to be plain characters, and does not


interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.
 [-nocase]: Makes matches case-insensitive, both for the patterns
argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each pin in the collection, the expression is evaluated
based on the pin's attributes. If the expression evaluates to true, the pin
is included in the result. To see the list of pin attributes that you can use
in the expression, use the list_attributes -application -class pin
command. For more information about how to use the -filter option, see
the filter_collection man page.
 [-of_objects <objects>]: Creates a collection of pins connected to
the specified objects. By default, the command considers only pins
connected to the specified nets at the same hierarchical level. To
consider only pins connected to leaf cells on the specified nets, use the -
leaf option. arguments are mutually exclusive; you can specify only one.
If you do not specify any of these arguments, the command uses *
(asterisk) as the default pattern. You cannot use the -hierarchical option
with the -of_objects option.
 [-leaf]: Includes only those pins that are on leaf cells connected to the
nets specified in the -of_objects option. The tool crosses hierarchical
boundaries to find pins on leaf cells. You can use this option only if you
also use the -of_objects option.
 [-all]: Includes power and ground pins.

Examples
The following example queries the CP pins of cells that begin with o.
Although the output looks like a list, it is only a display.
prompt> get_pins o*/CP
{o_reg1/CP o_reg2/CP o_reg3/CP o_reg4/CP}
The following example queries the pins connected to a collection of cells:
prompt> set csel [get_cells o_reg1]
{o_reg1}

prompt> get_pins -of_objects $csel


{o_reg1/D o_reg1/CP o_reg1/CD o_reg1/Q o_reg1/QN}

870
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

The following example shows the difference between getting the local pins
of a net and the leaf pins of net. In this example, NET1 is connected to the
i2/aP and reg1/QN. Cell i2 is hierarchical. Within cell i2, port a is connected
to U1/A and U2/A.
prompt> get_pins -of_objects [get_nets NET1]
{i2/a reg1/QN}

prompt> get_pins -leaf -of_objects [get_nets NET1]


{i2/U1/A i2/U2/A reg1/QN}
The following example shows how to create a clock using a collection of
pins:
prompt> create_clock -period 8 -name CLK [get_pins o_reg*/CP]
1

get_ports
Description
This command creates a collection of ports by selecting ports from the
current design that match the specified criteria.
The command returns a collection if any ports match the criteria. If no
objects match the criteria, the command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as query_objects. In addition, you
can assign the result to a variable.
When issued from the command prompt, the command behaves as though
you have called the query_objects command to report the objects in the
collection. By default, it displays a maximum of 100 objects. You can
change this maximum by using the collection_result_display_limit variable.
For information about collections and the querying of objects, see the
collections man page.
In addition, see the man pages for the all_inputs and all_outputs
commands, which also create collections of ports.

Syntax
get_ports <patterns>

871
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

[-quiet]
[-regexp]
[-exact]
[-nocase]
[-filter <expression>]
[-hierarchical]
[-of_objects <objects>]

Arguments
 Default Argument: <patterns>: Creates a collection of ports whose
names match the specified patterns. Patterns can include the *
(asterisk) and ? (question mark) wildcard characters. For more
information about using and escaping wildcards, see the wildcards man
page. Pattern matching is case sensitive unless you use the -nocase
option. arguments are mutually exclusive; you can specify only one. If
you do not specify any of these arguments, the command uses *
(asterisk) as the default pattern.
 [-quiet]: Suppresses warning and error messages if no objects match.
Syntax error messages are not suppressed.
 [-regexp]: Views the patterns argument as a regular expression rather
than a simple wildcard pattern. This option also modifies the behavior of
the =~ and !~ filter operators to use regular expressions rather than
simple wildcard patterns. The regular expression matching is similar to
the Tcl regexp command. When using the -regexp option, be careful
how you quote the patterns argument and filter expression. Using rigid
quoting with curly braces around regular expressions is recommended.
Note that regular expressions are always anchored; that is, the
expression is assumed to begin matching at the beginning of an object
name and end matching at the end of an object name. You can widen
the search by adding ".*" to the beginning or end of the expressions, as
needed. The -regexp and -exact options are mutually exclusive; you can
use only one.
 [-exact]: Considers wildcards to be plain characters, and does not
interpret their meaning as wildcards. The -regexp and -exact options
are mutually exclusive; you can use only one.

872
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

 [-nocase]: Makes matches case-insensitive, both for the patterns


argument and for the ==, =~, and !~ filter operators.
 [-filter <expression>]: Filters the collection with the specified
expression. For each port in the collection, the expression is evaluated
based on the port's attributes. If the expression evaluates to true, the
port is included in the result. To see the list of port attributes that you
can use in the expression, use the list_attributes -application -class port
command. For more information about how to use the -filter option, see
the filter_collection man page.
 [-hierarchical]: Searches for ports level-by-level, relative to the
current instance. The full name of the object at a particular level must
match the patterns. The search is similar to that of the UNIX find
command. For example, if there is a port named block1/adder/D[0], a
hierarchical search finds it by using adder/D[0]. The -hierarchical option
is mutually exclusive with use the -of_objects option; you can use only
one.
 [-of_objects <objects>]: Creates a collection of ports connected to
the specified objects. Each object can be a net, terminal, bound, or via
region. arguments are mutually exclusive; you can specify only one. If
you do not specify any of these arguments, the command uses *
(asterisk) as the default pattern.

Examples
The following example queries all input ports beginning with "mode".
Although the output looks like a list, it is only a display.
prompt> get_ports mode* -filter {@port_direction == in}
{mode[0] mode[1] mode[2]}
The following example sets the driving cell for ports beginning with
prompt> set_driving_cell -lib_cell FD2 -library my_lib \\
[get_ports in*]
The following example reports ports connected to nets that match the
pattern "bidir*".
prompt> report_port [get_ports -of_objects [get_nets bidir*]]
The following example get the ports connected to terminals that match the
pattern "CC*".
prompt> get_ports -of_objects [get_terminals CC*]]

873
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

{CC CCEN}
The following example shows you can get bus ports by their base name.
A[0], A[1], and A[2] are bus ports with the base name A; A[3] is not a bus
port.
prompt> get_ports A
{A[0] A[1] A[2]}

prompt> get_ports A[3]


{A[3]}

get_timing_arcs
Description
This command returns the collection of timing arc objects.

Syntax
get_timing_arcs
-from <from>
-to <to>
-of_objects obj_list
-filter <expression>
-onlyseq
-onlycombo

Arguments
 -from <from>: Use this option to specify the source objects in timing
arc objects.
 -to <to>: Use this option to specify the destination objects in timing
arc objects.
 -of_objects obj_list: Use this option to specify the object list (net/
cell).

874
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

 -filter <expression>: Use this option to specify the filters in those


timing arcs of which attributes matches with expression.
 -onlyseq: Use this option to get only the sequential timing arcs.
 -onlycombo: Use this option to get only the combinational timing arcs.

Examples
The following examples show how to use get_timing_arcs command
vc_static_shell> get_timing_arc -from INST/IN -to INST/PAD
{"INST/IN --> INST/PAD"}

vc_static_shell> get_timing_arc -of [get_cells INST]


{"INST/IN1 --> INST/PAD", "INST/IN --> INST/PAD", "INST/NOE -->
INST/PAD", "INST/PAD --> INST/OUT"}

vc_static_shell> get_timing_arc -of [get_cells INST] -onlyseq


{"INST/IN1 --> INST/PAD"}

insert_buffer
Description
This command adds a buffer at one specified net or pin. A library cell with a
single input and single output can be used as the buffer or inverter, as long
as output has the same or inverted logic function of the input.

Syntax
insert_buffer <object_name>
[-no_of_cells < number of cells>]
[-inverter_pair]
-new_net_cells <new net cells>
-new_cell_names <new cell names>

875
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Arguments
 Default Argument: <object_name>: Net or Pin which need to be
buffered.
 Default Argument: <buffer lib cell>: Reference buffer lib cell to be
instantiated.
 [-no_of_cells < number of cells>]: Number of level(s) of buffers to
be introduced.
 [-inverter_pair]: Insert a pair of inverter cells for each buffer.
 -new_net_cells <new net cells>: Specifies the name of the new net.
 -new_cell_names <new cell names>: Specifies the name of the new
buffer.

Examples
The following example creates a buffer named cell1 under the sub design
corresponding to the mid1 cell:
vc_static_shell> insert_buffer -new_net_names n1 -
new_cell_names buf1 i tiny/BUF
[Info] NET_BUFFERING: Buffering net 'i' in design 'top'.
[Info] NET_DISCONNECTED: Disconnecting net 'i' to object 'I' in
design 'top'
[Info] ADD_NET: Creating net 'n1' in design 'top'.
[Info] ADD_CELL: Creating cell 'buf1' in design 'top'.
[Info] NET_CONNECTED: Connecting net 'i' to object 'I' in
design 'top'
[Info] NET_CONNECTED: Connecting net 'n1' to object 'Z' in
design 'top'
[Info] NET_CONNECTED: Connecting net 'n1' to object 'I' in
design 'top'

list_designs
Description
list_designs command lists designs that have been loaded.

876
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Syntax
list_designs [<design_list>]

Arguments
 Default Argument [<design_list>]: Use this option to specify the list
of designs

Examples
The following examples show the usage of the list_designs command:
vc_static_shell> list_designs
ALU BLENDER CLOCK_GEN CONTEXT_MEM CONTEXT_MEM_DW01_inc_6_0
CONTEXT_MEM_DW01_inc_6_1 CONTROL DATA_PATH INSTRN_LAT ORCA (*)
ORCA_TOP PARSER PCI_CORE PCI_RFIFO PCI_WFIFO
PCI_W_MUX PRGRM_CNT_TOP REG_FILE RESET_BLOCK RISC_CORE
1
The following example shows the usage of the list_designs command with
a query pattern
vc_static_shell> list_designs ALU
ALU
1

list_instance
Description
list_instance command lists the instances in the current design or current
instance.

Syntax
list_instance [<instance_list>]
[-max_levels <num_levels>]
[-hierarchy]
[-full]

877
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Arguments
 Default Argument: [<instance_list>]: Use this option to specify the
list of instances. By default, all instances in the current design or current
instance are listed.
 [-max_levels <num_levels>]: Specifies a limit to the number of levels
of hierarchy that are listed.
 [-hierarchy]: Lists all levels of instance hierarchy. By default, only the
current level of hierarchy is listed.
 [-full]: Displays the full hierarchy. By default, if there is a submodule
in multiple locations in a hierarchy, its components are listed only once
with ellipses (...) indicating the contents of a previously displayed
module.

Examples
The following examples show the usage of the list_instance command:
vc_static_shell> list_instance
I_BNOT__SVAC_1_abort (BITWISE_NOT) I_BNOT__SVAC_1_disable_iff
(BITWISE_NOT) I_BNOT__SVAC_1_disable_iff_0 (BITWISE_NOT)
I_BNOT__SVAC_1_disable_iff_1 (BITWISE_NOT) _SVAC_1_ended_reg
(SEQ_FF) I_OR_N_36 (BITWISE_OR)
I_AND_N_1 (BITWISE_AND) I_BNOT_N_0 (BITWISE_NOT)
I_BUF__sva_topbit_0 (CONNECT)

list_libs
Description
list_libs command reports all the libs loaded and the details of these libs.

Syntax
list_libs [<patterns>]

Arguments
 Default Argument [<patterns>]: Use this option to specify the list of
libs

878
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Examples
The following examples show the usage of the list_libs command:
vc_static_shell> list_libs
-------------------------------------------------
Library File Path
------- ---- ----
ATL25_25_cell_wcmil ATL25_25_cell_wcmil.db /remote/dtdata1/
testdata/libraries/syn/
lsi_10k lsi_10k.db /remote/dtdata1/testdata/libraries/syn/
The following examples show the usage of the list_libs command with a
query pattern
vc_static_shell> list_libs ATL25_25_cell_wcmil
-------------------------------------------------
Library File Path
------- ---- ----
ATL25_25_cell_wcmil ATL25_25_cell_wcmil.db /remote/dtdata1/
testdata/libraries/syn/

remove_attribute
Description
This command removes the specified attribute from the specified objects.
For a complete list of attributes, see the attributes man page.
A returned empty string indicates that no object has been removed.

Syntax
remove_attribute <object_list>

Arguments
 Default Argument <object_list>: Specifies a list of objects from which
the attribute is to be removed.

remove_buffer

879
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Description
This command removes buffer cells and the specified connected net.

Syntax
remove_buffer <cell name>
[-from <start point>]
[-net]
[-to <pins>]
[-level <level>]

Arguments
 Default Argument: <cell name>: Specifies the buffer to be removed.
 [-from <start point>]: Starting Driver Pin to begin buffer deletion.
 [-net]: Net from which buffer need to be deleted.
 [-to <pins>]: Load pins where to end buffer deletion.
 [-level <level>]: Number of level(s) of buffers to be introduced.

Examples
The following example removes a buffer named buf1 in design top:
vc_static_shell> remove_buffer buf1
[Info] NET_DISCONNECTED: Disconnecting net 'n1' to object 'Z'
in design 'top'
[Info] NET_DISCONNECTED: Disconnecting net 'i' to object 'I' in
design 'top'
[Info] NET_DISCONNECTED: Disconnecting net 'n1' to object 'I'
in design 'top'
[Info] NET_CONNECTED: Connecting net 'i' to object 'I' in
design 'top'
[Info] REMOVE_CELL: Removing cell 'buf1' in design 'top'.
[Info] REMOVE_NET: Removing net 'n1' in design 'top'.

remove_bus

880
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Description
This command removes port or net buses from a design. If port and net
buses have the same name, both port buses and net buses are removed.
Individual members of buses remain. The bus can be from the current
design or one of its subdesigns. To delete a bus on a subdesign, it must be
unique. Multicorner-Multimode Support This command has no dependency
on scenario-specific information.

Syntax
remove_bus <bus_name_list>

Arguments
 Default Argument <bus_name_list>: Specifies a list of port or net
buses to remove.

Examples
The following example removes the specified port buses:
vc_static_shell> remove_bus {AB AC}
In the following example, all buses with names that end in s are removed.
If port and net buses have the same name, both buses are removed.
vc_static_shell> remove_bus *s

remove_cell
Description
The remove_cell command removes cells or cell instances from the current
design. The command also removes pins owned by the specified cells. The
design or library cell to which the cell refers is not removed. If a cell
instance is used, the parent design must be unique. To create cells, use the
create_cell command.

Syntax
remove_cell <name_list>
[-all]

881
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Arguments
 Default Argument: <name_list>: Specifies a list of cells to be
removed from the current design. Each cell name must exist in the
current design.
 [-all]: Removes all cells in the current design.

Examples
The following example uses remove_cell to remove the specified cells in
the current design:
vc_static_shell> remove_cell {U1 U2}
Removing cell 'U1' in design 'example'.
Removing cell 'U2' in design 'example'.
The following example removes all cells remaining in the current design:
vc_static_shell> remove_cell -all
Removing cell 'U3' in design 'example'.
Removing cell 'U4' in design 'example'.
Removing cell 'U5' in design 'example'.
Removing cell 'U6' in design 'example'.
Removing cell 'U7' in design 'example'.
Removing cell 'U8' in design 'example'.

remove_net
Description
This command removes nets or net instances from the current design. Net
connections to pins or ports are disconnected. You cannot remove bused
nets with the remove_net command. Use the remove_bus command to
remove bused nets. Scalar (single bit) nets that are components of a bused
net cannot be removed. You must remove bused nets first. To create nets,
use the create_net command. Multicorner-Multimode Support This
command has no dependency on scenario-specific information.

Syntax
remove_net <name_list>
[-only_physical]

882
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

[-all]

Arguments
 Default Argument: <name_list>: Specifies a list of nets to remove
from the current design. Each net name must exist in the current
design. You must specify either net_list or -all
 [-only_physical]: Removes only physical nets in the current design.
The physical nets are those nets that do not connect to a logical netlist.
 [-all]: Removes all nets in the current design. You must specify either
-all or net_list.

Examples
The following example removes the nets in the current design:
vc_static_shell> get_nets *
{"w2", "out", "w", "out1", "w3", "clk1", "w10", "clk2", "sel",
"in"}
vc_static_shell> remove_net w
[Info] REMOVE_NET: Removing net 'w' in design 'test'.
1
The following example removes the physical nets:
vc_static_shell>remove_net -only_physical {physnet1 physnet2}

remove_port
Description
This command removes ports from the current design or its subdesign.
Bused ports cannot be removed with remove_port; use remove_bus to
remove bused ports. Also, scalar (single bit) ports that are components of
a bused port cannot be removed. In this case, you must first remove the
bused port. To create ports, use the create_port command. Multicorner-
Multimode Support This command has no dependency on scenario-specific
information.

Syntax
remove_port <name_list>

883
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Arguments
 Default Argument <name_list>: Specifies a list of ports to be
removed from the current design. Each port name must exist in the
current design.

Examples
The following example uses remove_port to remove ports from the current
design
vc_static_shell> remove_port "B*"
Removing port 'B1' in design 'my_design'.
Removing port 'B2' in design 'my_design'.

report_cell
Description
Reports cell information of the current design

Syntax
report_cell <cell_list>
[-no_split]

Arguments
 Default Argument: <cell_list>: Use this option to specify the list of
cells
 [-no_split]: Prevents line splitting and facilitates writing software to
extract information from the report output. Most of the design
information is listed in fixed-width columns. If the information for a
given field exceeds its column's width, the next field begins on a new
line, starting in the correct column.

Examples
The following examples show the usage of the report_cell command:
vc_static_shell> report_cell
****************************************

884
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Report : cell
Design : top
Version: P-2020.03-Alpha
Date : Wed Mar 20 20:16:37 2019
****************************************
Attributes:
b - black-box (unknown)
h - hierarchical
n - noncombinational
Cell Reference Library Area Attributes
---------------------------------------------------------------
-----------------
u1 block 21.000000 h
u2 block 21.000000 h
u3 block 21.000000 h
---------------------------------------------------------------
-----------------
Total 3 Cells 63.000000
vc_static_shell> report_cell -no_split
****************************************
Report : cell
Design : top
Version: P-2020.03-Alpha
Date : Wed Mar 20 20:16:37 2019
****************************************

Attributes:
b - black-box (unknown)
h - hierarchical
n - noncombinational
Cell Reference Library Area Attributes
---------------------------------------------------------------
-----------------
u12345678910123456789 block 21.000000 h
u2 block 21.000000 h
u3 block 21.000000 h
---------------------------------------------------------------
-----------------
Total 3 Cells 63.000000

885
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

report_link
Description
Reports, with the applicable reasons, the status of designs that were
synthesized. The reasons can be one or more of below:
 Empty: Design definition is empty.
 Unsynthesizable: Design has non-synthesizable constructs.
 No functional view: Design does not have a functional view.
 UserBB: Design is black boxed by the user.
 Unresolved: Design definition is not provided.
 AutoBB: Design is a tool generated black box.
 AutoGB: Design is a tool generated glass box.
 SimPort: The RTL model is used because there is a mismatch in the port
name specified in the RTL model and the DB library definition.
 SimDirection: The RTL model is used because there is a mismatch in the
port direction specified in the RTL model and the DB library definition.
 DirtyData: The DB model is used after doing dirty data handling (a
port connection to port is not present in DB definition).
 abstract: The design is a constraint-based abstract model.

Syntax
report_link
[-sim_match]
 [-sim_match]: Includes library cells where a simulation model is given.

Examples
Consider a design where Block1 and Block2 are user-defined black boxes,
Block3 is an unresolved black box, and Block4 is an empty module. In this
case, the report_link command generates the following output:
vc_static_shell> report_link
Module Instances Reason

886
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

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


Block1 1 UserBB
Block2 4 UserBB
Block3 1 Unresolved
Block4 1 Empty
Note that the command reports the number of instances for each module
as well.

report_net
Description
Reports net information of the current design

Syntax
report_net <net_list>
[-no_split]

Arguments
 Default Argument: <net_list>: Use this option to specify the list of
nets
 [-no_split]: Prevents line splitting and facilitates writing software to
extract information from the report output. Most of the design
information is listed in fixed-width columns. If the information for a
given field exceeds its column's width, the next field begins on a new
line, starting in the correct column.

Examples
The following examples show the usage of the report_net command:
vc_static_shell> report_net
****************************************
Report : net
Design : top
Version: P-2020.03-Alpha

887
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Date : Wed Mar 20 20:16:37 2019


****************************************
Net Fanout Fanin Resistance Pins Attributes
---------------------------------------------------------------
-----------------
Q 1 1 0.000000 2
S 1 1 0.000000 2
PQRSTUVWXYZABCDEFGHIJKLMNOPGRS
1 1 0.000000 2
vc_static_shell> report_net -no_split
****************************************
Report : net
Design : top
Version: P-2020.03-Alpha
Date : Wed Mar 20 20:16:37 2019
****************************************
Net Fanout Fanin Resistance Pins Attributes
---------------------------------------------------------------
-----------------
Q 1 1 0.000000 2
S 1 1 0.000000 2
PQRSTUVWXYZABCDEFGHIJKLMNOPGRS1 1 0.000000 2

report_port
Description
Displays port information within the design

Syntax
report_port <port_list>
[-no_split]

Arguments
 Default Argument: <port_list>: Use this option to specify the list of
ports

888
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

 [-no_split]: Prevents line splitting and facilitates writing software to


extract information from the report output. Most of the design
information is listed in fixed-width columns. If the information for a
given field exceeds its column's width, the next field begins on a new
line, starting in the correct column.

Examples
The following examples show the usage of the report_net command:
vc_static_shell> report_port
****************************************
Report : port
Design : top
Version: P-2020.03-Alpha
Date : Wed Mar 20 20:16:37 2019
Port Dir Pin Cap(min/max) Wire Cap(min/max)
---------------------------------------------------------------
-----
A in 0.0000/0.0000 0.0000/0.0000
B out 0.0000/0.0000 0.0000/0.0000
C in 0.0000/0.0000 0.0000/0.0000
D out 0.0000/0.0000 0.0000/0.0000
vc_static_shell> report_port -no_split
****************************************
Report : port
Design : top
Version: P-2020.03-Alpha
Date : Wed Mar 20 20:16:37 2019
****************************************
Port Dir Pin Cap(min/max) Wire Cap(min/max)
---------------------------------------------------------------
-------
ABCDEFGHIJKLMNOPQRSTUVWXYZ in 0.0000/0.0000 0.0000/0.0000
B out 0.0000/0.0000 0.0000/0.0000
C in 0.0000/0.0000 0.0000/0.0000
D out 0.0000/0.0000 0.0000/0.0000

set_always_on_cell

889
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Description
The set_always_on_cell command sets all cells in the library whose name
matches the specified cell name as always-on cells. Only buffer or inverter
cells in the library can be specified as always-on cells.

Syntax
set_always_on_cell

Examples
The following example uses the set_always_on_cell command to set the
library cell named INV_AO as an always-on cell:
prompt> set_always_on_cell INV_AO

set_attribute
Description
This command sets the value of an attribute on an object. For a complete
list of attributes, see the attributes man page.
This command returns a collection of objects that have the specified
attribute value set. If the attribute is not set on any objects, the command
returns an empty string.

Syntax
set_attribute <objects>
[-type <boolean | integer | float | string>]
[-quiet]

Arguments
 Default Argument: <objects>: Specifies the objects on which the
attribute is to be set.
 [-type <boolean | integer | float | string>]: Specifies the data
type of the attribute_value argument. This argument is required when
creating new attributes; otherwise, it is optional. If the attribute data

890
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

type is not specified, the tool uses either the specified attribute_value
argument or the data type of the existing attribute.
 [-quiet]: Turns off the warning message that would otherwise be
issued if the attribute or objects are not found.

Examples
The following example defines an integer cell attribute named X, and then
sets this attribute to 30 on all cells in this level of the hierarchy:
prompt> define_user_attribute -type int -classes cell X
cell
prompt> set_attribute [get_cells *] X 30
{U1}

set_get_command_message_limit
Description
This command sets the limit number of get commands failures.

Syntax
set_get_command_message_limit <command name>
-no_limit
-number <number>

Arguments
 Default Argument: <command name>: Use this option to specify the
Get command to be set. The values are all, get_cells, get_designs,
get_lib_cells, get_lib_pins, get_nets, get_pins and get_ports.
 -no_limit: Use this option to remove limit.
 -number <number>: Use this option to specify the limit number of
failures. The value is >= 1.

set_isolation_cell

891
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Description
The set_isolation_cell command sets the specified library cells as isolation
cells. You can also specify the data and enable pin details for the isolation
cell.

Syntax
set_isolation_cell
[-data_pin <data_pin_name>]
[-enable_pin <enable_pin_name>]
 [-data_pin <data_pin_name>]: Specifies the name of the data pin of
the isolation cell.
 [-enable_pin <enable_pin_name>]: Specifies the name of the enable
pin of the isolation cell.

Examples
In the following example, all cells in the library whose name starts with ISO
are set as isolation cells. The EN pin of those library cells is considered the
enable pin of the isolation cell.
prompt> set_isolation_cell ISO* -enable_pin EN

set_level_shifter_cell
Description
The set_level_shifter_cell command specifies the properties of the level-
shifter cells.

Syntax
set_level_shifter_cell
[-cell_type <cell_type>]
[-cell_input_voltage_range <{lower_range upper_range}>]
[-cell_output_voltage_range <{lower_range upper_range}>]
[-std_cell_main_rail_pg_pin <pg_pin_name>]

892
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

[-data_pin <data_pin_name>]
[-input_voltage_range <{lower_range upper_range}>]
[-output_voltage_range <{lower_range upper_range}>]
[-input_signal_level <signal_level>]
[-enable_pin <enable_pin_name>]
[-enable_signal_level <signal_level>]
[-output_signal_level <signal_level>]

Arguments
 [-cell_type <cell_type>]: Specifies the cell type of the level-shifter
cell.
 [-cell_input_voltage_range <{lower_range upper_range}>]:
Specifies the cell input voltage range of the level-shifter cell.
 [-cell_output_voltage_range <{lower_range upper_range}>]:
Specifies the cell output voltage range of the level-shifter cell.
 [-std_cell_main_rail_pg_pin <pg_pin_name>]: Specifies the
standard cell P/G pin of the level-shifter cell.
 [-data_pin <data_pin_name>]: Specifies the data pint of the level-
shifter cell.
 [-input_voltage_range <{lower_range upper_range}>]: Specifies
the input voltage range of the level-shifter cell.
 [-output_voltage_range <{lower_range upper_range}>]: Specifies
the output voltage range of the level-shifter cell.
 [-input_signal_level <signal_level>]: Specifies the input signal
level of the level-shifter cell.
 [-enable_pin <enable_pin_name>]: Specifies the enable pin of the
level-shifter cell.
 [-enable_signal_level <signal_level>]: Specifies the enable signal
level of the level-shifter cell.
 [-output_signal_level <signal_level>]: Specifies the output signal
level of the level-shifter cell.

893
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Examples
In the following example, library cells whose names start with LVLLH are
set as level-shifter cells of type low to high.
prompt> set_level_shifter_cell LVLLH* -cell_type LH -
std_cell_main_rail_pg_pin VDD \\
-enable_pin EN -input_signal_level VDDL -enable_signal_level
VDDH \\
-output_signal_level VDDH -cell_input_voltage_range {0.7 1.4}
\\
-cell_output_voltage_range {0.7 1.4}

set_pg_pin_model
Description
The set_pg_pin_model command defines the power and ground pins for a
library cell. If the power or ground pin already exists, the new specification
overrides the old one. Otherwise, new power and ground pins are created
for the library cell.

Syntax
set_pg_pin_model
[-pg_pin_name <pin_name>]
[-pg_voltage_name <voltage_names>]
[-pg_pin_type <pin_types>]
[-pg_pin_direction <pin_directions>]
[-pg_physical_connection <physical_connections>]
[-pg_related_bias_pin <related_bias_pins>]

Arguments
 [-pg_pin_name <pin_name>]: Specifies the names of the power and
ground pins of the library cell.
 [-pg_voltage_name <voltage_names>]: Specifies the voltage name of
the corresponding power or ground pin of the library cell. The voltage

894
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

names are defined in the library voltage map. There must be a one-to-
one correspondence between the voltage names specified in this option
and the pins specified in the -pg_pin_name option.
 [-pg_pin_type <pin_types>]: Specifies the pin type for the each pin
specified in the -pg_pin_name option. Valid values are primary_power,
primary_ground, backup_power, backup_ground, internal_power,
internal_ground, pwell, nwell, deeppwell, and deepnwell. There must be
a one-to-one correspondence between the pin types specified in this
option and the pins specified in the -pg_pin_name option.
 [-pg_pin_direction <pin_directions>]: Specifies the direction for
each pin specified in the -pg_pin_name option. Valid values are input,
output, inout, and internal. There must be a one-to-one correspondence
between the pin directions specified in this option and the pins specified
in the -pg_pin_name option.
 [-pg_physical_connection <physical_connections>]: Specifies the
type of physical connection used for each pin specified in the -
pg_pin_name option. Valid values are device_layer and routing_pin.
There must be a one-to-one correspondence between the connection
types specified in this option and the pins specified in the -pg_pin_name
option.
 [-pg_related_bias_pin <related_bias_pins>]: Specifies the related
bias pin for each pin specified in the -pg_pin_name option. There must
be a one-to-one correspondence between the related bias pins specified
in this option and the pins specified in the -pg_pin_name option.

Examples
The following example defines the power and ground pins for the library
cells whose name starts with LVLH.
prompt> set_pg_pin_model LVLH* -pg_pin_name {VDD VSS} \\
-pg_voltage_name {VDDL VSS} \\
-pg_pin_type {primary_power primary_ground}

set_pin_model
Description
The set_pin_model command defines the related power pin, related ground

895
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

pin, and related bias pin for the specified library cell pins. If the related pin
is already defined, the new specification overrides the old one.

Syntax
set_pin_model
[-pins <pin_names>]
[-related_power_pin <pin_names>]
[-related_ground_pin <pin_names>]
[-related_bias_pin <pin_names>]
[-power_down_function <functions>]

Arguments
 [-pins <pin_names>]: Specifies the names of the pins for which you
are defining the related power and ground pins.
 [-related_power_pin <pin_names>]: Specifies the related power pin
for each pin specified in the -pins option. There must be a one-to-one
correspondence between the power pins specified in this option and the
pins specified in the -pins option.
 [-related_ground_pin <pin_names>]: Specifies the related ground
pin for each pin specified in the -pins option. There must be a one-to-
one correspondence between the ground pins specified in this option
and the pins specified in the -pins option.
 [-related_bias_pin <pin_names>]: Specifies the related bias pin for
each pin specified in the -pins option. There must be a one-to-one
correspondence between the bias pins specified in this option and the
pins specified in the -pins option.
 [-power_down_function <functions>]: Specifies the power-down
function for each pin specified in the -pins option. There must be a one-
to-one correspondence between the function specified in this option and
the pins specified in the -pins option.

Examples
The following example defines the pin model for the RETN and RETNOUT
prompt> set_pin_model *DRFF* -pins {RETN RETNOUT} \\

896
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

-related_power_pin VDDG \\
-related_ground_pin VSSG
The following example defines the pin model for the SLEEPOUT pin of the
library cells that match the pattern HEAD*.
prompt> set_pin_model HEAD* -pins {SLEEPOUT} \\
-power_down_function "!VDDG + VSS"

set_power_switch_cell
Description
The set_power_switch_cell command sets the specified library cells as
power-switch cells.
The switch_cell_type attribute must be either coarse_grain or fine_grain .
The switch_function attribute must be defined to identify the control logic
of its switch pins.
It can be defined at either controlled output power or ground pins which is
virtual VDD or vitural VSS pg_pin.
The cell must have at least one switch pin. And switch pin cannot be output
pin.
The cell must have at least one controlled power or ground pin, and one
regular power and ground pin.
The output power pin must have pg_function Boolean expression
containing input power or ground pin.
The pg_function attribute must contain only the input power or ground pin.

Syntax
set_power_switch_cell
[-cell_type <course_grain | fine_grain>]
[-switch_pin <pin_name>]
[-pg_pin <{pin_name switch_function pg_function}>]

897
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Database Commands

Arguments
 [-cell_type <course_grain | fine_grain>]: Specifies the type of
the power-switch cell. The type can be either coarse_grain or fine_grain.
 [-switch_pin <pin_name>]: Specifies the switch pin of the power-
switch cell.
 [-pg_pin <{pin_name switch_function pg_function}>]: Specifies
the power or ground pin of the power-switch cell.

Examples
In the following example, the library cells whose names starts with FOOT
are set as course-grain power-switch cells.
prompt> set_power_switch_cell FOOT* -cell_type coarse_grain \\
-switch_pin SLEEPN -pg_pin {VSS !SLEEPN VSS}

set_retention_cell
Description
The set_retention_cell command sets the specified library cells as retention
cells. You can also specify the retention pin and retention cell type for the
retention cell.

Syntax
set_retention_cell
[-cell_type <retention_type>]
[-retention_pin <{pin_name pin_type disable_value}>]

Arguments
 [-cell_type <retention_type>]: Specifies the type of the retention
cell.
 [-retention_pin <{pin_name pin_type disable_value}>]: Defines
the retention pin of the library cell. The valid values for the pin_type
argument are restore, save, and save_restore. The value values for the
disable_value argument are 0 and 1.

898
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Database Commands

Examples
The following example sets all library cells whose name matches *DRFF* as
DRFF retention cells. The retention pin, RETN, is a save-restore pin and is
disabled by a logic 1 value.
prompt> set_retention_cell *DRFF* -cell_type DRFF \\
-retention_pin {RETN save_restore 1}

set_top_module
Description
This command changes the top instance.

Syntax
set_top_module
-topInst <string>

Arguments
 -topInst <string>: Use this option to specify the top instance name.

899
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Common Commands

add_tag_field
Description
This command adds a new field to a tag. The field can be an existing field,
which was not previously used for that tag; or a new user field. After
adding the field to the tag, use set_violation_field to fill in the string for
each violation.

Syntax
add_tag_field <tag> [<tag>]
[-type <value>]

Arguments
 Default Argument: <tag>: Use this option to specify the tag name.
 Default Argument: <field>: Use this option to specify the field name.
Use colon separated name if field needs to be added to complex user
defined field.
 Default Argument: [<app>]: Use this option to specify the application
name.
 [-type <value>]: Use this option to specify the field type. Possible
option values are string and list. Default value is string.

analyze
Description
This command analyzes the specified HDL source files and stores the
design templates they define into the specified library in a format ready to
specialize and elaborate to form linkable cells of a full design.
Using this command, the user can specify multiple source files in single language in
one command. Upon completion of the command all specified files are analyzed and
ready to be elaborated. The command returns 1 on success and 0 on failure.

900
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

When the -vcs option is specified, other options cannot be specified, specify the entire
vlogan/vhdlan command line within '{' and '}'

Syntax
analyze <file_list>
-format <verilog | sverilog | vhdl | sysc | spi>
-library <library_name>
-work <library_name>
-define <define_macros>
[-vcs <vcs_cmd>]
[-netlist]

Arguments
 Default Argument: <file_list>: Use this option to specify the list of
files to be analyzed. When specifying more than one file, separate the
names with a space and enclose the list of names in braces ({}) or
within quotation (" ").
 -format <verilog | sverilog | vhdl | sysc | spi>: Use this
option to specify the input file format type. The supported types are
verilog: IEEE Standard Verilog format, VHDL: IEEE Standard VHDL,
sverilog: IEEE Standard System Verilog.
 -library <library_name>: Use this option to remap the work library in
the same way as the -library option. It specifies the library name to
which work must be mapped. The -work option references the library
where the top-level unit of the elaboration hierarchy is compiled. If the
elaboration starts from a module, then it is the library name where the
module is compiled. If the elaboration starts from a configuration (in
case of -v2kconfig), it is the library name where the configuration is
compiled.
 -work <library_name>: Use this option to remap the work library in the
same way as the -library option. It is an alias for the -library option for
VHDL only. It specifies the library name to which work must be mapped.
The -work option references the library where the top-level unit of the
elaboration hierarchy is compiled. If the elaboration starts from a
module, then it is the library name where the module is compiled. If the

901
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

elaboration starts from a configuration (in case of -v2kconfig), it is the


library name where the configuration is compiled.
 -define <define_macros>: Use this option to specify a list of top-level
macros. This option can only be used with the Verilog and System
Verilog formats.
 [-vcs <vcs_cmd>]: Use this option to analyze the design files using
VCS analyze command. This option specifies all VCS-specific command-
line options. Options specified by -vcs follow the VCS command-line
syntax. The vlogan and vhdlan arguments and switches used in this
switch must be enclosed in curly braces.
The [-sverilog|-verilog] argument specifies the format of the files to be
analyzed.
The [-y directory_path] argument specifies directories that contain the
library files to be searched for unresolved module instantiations in the
design.
The [+libext+.extension1+...] argument specifies the extension to
consider during a files search in the -y library directories. The default is
no extension.
The [-v library_file] holds several module definitions, to be used during
the search for unresolved modules.
The [-f command_file] argument specifies a command file.
The [+define+macro_name+...] argument defines a macro.
The [+incdir+dir1+...] argument includes directories in the search list.
 [-netlist]: Enables VC Static to invoke different design readers for
RTL file and Netlist file present in the tcl script. When RTL and netlist
files are present in the same tcl script, then you must read the netlist
designs using the -netlist option. This improves the performance of the
analyze command.

Examples
The following example analyzes a VHDL file named top.vhd. The library in
which this will be analyzed is my_work.
analyze -format vhdl -work my_work top.vhd
The following example analyzes a VHDL file named my_cfg.v using the VCS
analyze command.
analyze -vcs {my_cfg.v -sverilog}

902
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

change_names
Description
The change_names command changes the names of ports, cells (including
physical-only cells), and nets in a design to conform to specified name
rules. This command cannot be used to change the name of library cells or
bus ports.To change the name of bus ports, you must first use the
undefine_bus command to remove the bus property from the port. If an
object name does not conform to the specified rules, the tool changes the
name and ensures that the new name is unique within the design.
To show the effects of running this command without actually making the
changes, use the report_names command.
There are two primary reasons for using the change_names command: It
enables you to modify design object names in the tool so that the names
match those that are ultimately created for a saved design. The names the
tool displays in reports and in other information match those used in your
target system. It enables you to define naming rules specific to your target
system. For example, you might be using VHDL as a design transfer
mechanism, but the naming rules of your system might be more restrictive
than those supported by the true VHDL format.
When you run the change_names command with no options, it operates on
the ports, cells, and nets in the current design. When you specify the -
hierarchy option, changes are expanded to include all design objects within
the current design hierarchy. For runtime reasons, it's best to use the -
instance option only when you have a small list of instances to be renamed.
If you have a big list of instances to be renamed, you must use the -rule
option with change_names or use the -skip_inactive_constraints option
and apply the constraints after running change_names -instance.

Syntax
change_names
[-hierarchy]
[-rules <name_rules>]

Arguments
 [-hierarchy]: Use this option to apply change_names to the hierarchy.

903
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-rules <name_rules>]: Use this option to specify rules to be used for


change_names.

check_hdl_lib
Description
This command enables language check on VCS library files and library
modules. If enabled, VC Lint performs rule checking on the library files
passed with "-v" and "-y" options.

Syntax
check_hdl_lib
[-all]
[-lib <libFile list>]
[-module <libModule list>]
[-lib_file <libListFile>]
[-module_file <libModuleListFile>]

Arguments
 [-all]: Use this option to check all the library files and modules.
 [-lib <libFile list>]: Use this option to check the specified library
files.
 [-module <libModule list>]: Use this option to check the specified
library modules.
 [-lib_file <libListFile>]: Use this option to check the library files
in the specified file.
 [-module_file <libModuleListFile>]: Use this option to check the
library modules in the specified module.

Examples
The following example enables language check on all the library files and
modules.

904
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

check_hdl_lib -all

checkpoint_session
Description
Use the checkpoint_session command to save a session. This command
saves the session in the <sessionName>_rtdb /checkpoints directory.You
can add multiple checkpoints during a single run at different stages, but
these checkpoints must have different sessionName specified to avoid over
writing of the files. If two checkpoint_session commands are run one after
another with the same session_name, then the output of the second
command will overwrite the first command output.

Syntax
checkpoint_session
-session <session_name>
[-full]
[-incremental]

Arguments
 -session <session_name>:Use this option to checkpoint this session
under a specified name.
 [-full]: Use this option to create a full checkpoint.
 [-incremental]: Use this option to create an incremental checkpoint.

cluster_static_violations
Description
This command specifies the cluster static tool generated violations.

configure_libcell_uniquification

905
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Description
This command configures lib cell uniquification.

Syntax
configure_libcell_uniquification
-skip_sequential
-skip_module <libcell list>
-skip_instance <libcell instance list>

Arguments
 -skip_sequential: Use this option to skip uniquification of all
sequential.
 -skip_module <libcell list>: Use this option to skip uniquification of
all instances of a given libcell.
 -skip_instance <libcell instance list>: Use this option to skip
uniquification of specified instances.

configure_module_synthesis
Description
This command configures module level synthesis configurations.

Syntax
configure_module_synthesis
[-enable]
[-disable]
[-config <configuration>]
[-module_list <module_list>]

Arguments
 [-enable]: Use this option to enable module configuration.

906
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 [-disable]: Use this option to disable module configuration.


 [-config <configuration>]: Use this option to specify module
configuration.
 [-module_list <module_list>]: Use this option to specify list of
modules.

configure_reset_propagation
Description:
Configures reset propagation.

Syntax:
configure_reset_propagation
[-propagate_through_data_pin]
[-propagate_through_reset_pin]
[-propagate_through_mux_select_pin]
[-target_reset]
[-ignore_reset_overlap]
[-propagate_through_tristate_enable]

Arguments:
 [-propagate_through_data_pin]: Enables propagation of reset signal
from D to Q pin. The valid values are true and false. Default value is
false.

907
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

For example, consider the following schematic:

In this case, rst1 is propagated through the dff_1 flip flop if the
propagate_through_data_pin is set to true.
 [-propagate_through_reset_pin]: Enables propagation of Reset/Set
signal to Q pin. The valid values are true and false. Default value is
false.
For example, consider the following schematic:

In this case, the propagate_through_reset_pin argument is set to


false and therefore rst2 is not propagated through the dffr_2 flop
and the dffr_3 flop does not receive the reset.
NOTE: The propagate_through_reset_pin argument of the configure_reset_propagation

908
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

command is set to true if the enable_cdc or the enable_rdc application variables are
set to true.
 [-propagate_through_mux_select_pin]: Enables reset propagation
through the select pin of a mux. The valid values are true and false.
Default value is false.
For example, consider the following schematic:

In this case, rst6, rst7, and rst8 are defined as resets. If the
propagate_through_mux_select_pin argument is set to true, rst8 is
not propagated though the mux select pin.
 [-target_reset]: Defines the resets that should be allowed to
propagate from the D to the Q pin of a flop. You can specify one reset or
a list of resets as target resets.

909
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

For example, consider the following schematic:

In addition, consider the following configure_reset_propagation


command:
configure_reset_propagation -propagate_through_data_pin true
-target_reset {rst1 rst2 rst3}
In this case, rst4 is not specified with the -target_reset argument.
Therefore, rst4 is not propagated to dffr_6 because D->Q pin
propagation is disabled for rst4.
 [-ignore_reset_overlap]: Ignores overlapping resets and continues
propagation. Default value is false. Possible values are true and
false.
For example, consider the following schematic:

910
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

In this case, by default, the rst1 reset stops propagation after reg2/Q.
You can set the value of the ignore_reset_overlap argument to true
to propagate the rst1 reset beyond the reg2/Q. In this case, both the
resets propagate beyond reg2/Q.
 -propagate_through_tristate_enable: Use this option to enable
propagation of user reset through tristate enable pin. Possible values
are false and true. The default value is false.

911
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

For example, consider the following schematic:

In this case, by default, the rst_n reset stops propagation at the


I_BIF_P1 tristate register. You can set the value of the
propagate_through_tristate_enable argument to true to propagate
the rst_n reset beyond the I_BIF_P1 tristate register.

configure_tcl_command
Description
This command disables tcl commands. The commands can be enabled
again with -enable option.

Syntax
configure_tcl_command <cmd>
-enable
-disable

Arguments
 Default Argument: <cmd>: Use this option to specify the command to
be disabled.
 -enable: Use this option to enable the given command.
 -disable: Use this option to disable the given command.

912
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

configure_unobservable_logic_identification
Description
This command configures unobservable logic identification.

Syntax
configure_unobservable_logic_identification
-blackbox_endpoints yes/no/auto
-hierpin_endpoints yes/no/auto
-none/sequential/combinational

Arguments
 -blackbox_endpoints yes/no/auto: Use this option to treat black-box
inputs as primary outputs. The values are auto, no, and yes.
 -hierpin_endpoints yes/no/auto: Use this option to treat hierarchical
output pins as primary outputs. The values are auto, no, and yes.
 -none/sequential/combinational: Use this option to identify no,
sequential, or combinational unobservability. The values are
combinational, none, and sequential.

configure_waiver_filter_field
Description
This command configures filter field of a tag. Using this command, you can
customize filter fields for certain tags in waiver window. If this filter
command is not set, all fields are enabled in waiver window for each tag.

Syntax
configure_waiver_filter_field <tagname>
-enable
-disable

913
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Arguments
 Default Argument: <tagname>: Use this option to specify the tag
name.
 Default Argument: <fieldname>: Use this option to specify the field of
a tag.
 -enable: Use this option to enable field in waiver filter template in GUI.
 -disable: Use this option to disable field in waiver filter template in
GUI.

Examples
Specify the tag and field names, and use the -enable or -disable options to
enable or disable tags.
configure_waiver_filter_field -tag ISO_INST_MISSING -field
{Source:PinName} -enable
All the fields must include subfields till leaf level as below:
configure_waiver_filter_field -tag ISO_INST_MISSING -field
{SourceInfo:PowerNet:NetName} -enable
configure_waiver_filter_field -tag ISO_INST_MISSING -field
{SourceInfo:PowerNet:NetName} -enable
configure_waiver_filter_field -tag ISO_INST_MISSING -field
{SinkInfo:GroundNet:NetName} -disable
configure_waiver_filter_field -tag PG_SUPPLY_NOPORT -field
{SupplyPort:PortName} -enable

create_clock
Description
This command creates a clock object in the current design and defines the
specified source_objects as clock sources in the current design. A pin or
port can be a source for a single clock. If source_objects is not specified,
but a clock_name is given, a virtual clock is created. A virtual clock can be
created to represent an off-chip clock for input or output delay
specification. For more information about input and output delay, refer to
the set_input_delay and set_output_delay command man pages.
To show information about all clock sources in a design, use the

914
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

report_clock command. To get a list of clock sources, use the get_clocks


command. To return sequential cells related to a given clock, use the
all_registers command. To undo create_clock, use the remove_clock
command.

Syntax
create_clock [<value>]
[-period <period_value>]
[-name <clock_name>]
[-waveform <edge_list>]
[-add]
[-comment <string>]

Arguments
 Default Argument: [<>]: Specify this option to use clock as reference
clock [formal].
 Default Argument: [<value>]: Use this option to specify clock initial
value (0/1 - default 0) at time 0 [formal].
 Default Argument: [<>]: Use this option to specify a list of pins or
ports on which to apply this clock. If you do not use this option, you
must use -name clock_name, which creates a virtual clock not
associated with a port or pin. If you specify a clock on a pin that already
has a clock, the new clock replaces the old clock unless you use the -add
option.
 [-period <period_value>]: Use this option to specify the period of the
clock waveform in library time units.
 [-name <clock_name>]: Use this option to specify clock name.If you do
not use this option, the clock is given the same name as the first clock
source specified in source_objects. If you do not use source_objects,
you must use this option, which creates a virtual clock not associated
with a port or pin. Use this option along with source_objects to give the
clock a more descriptive name than that of the pin or port where it is
applied. If you specify the -add option, you must use the -name option
and the clocks with the same source must have different names.

915
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-waveform <edge_list>]: Use this option to specify the rise and fall
edge times, in library time units, of the clock over an entire clock period.
If the first time in the list is a rising transition, typically it is the first
rising transition after time zero. There must be an even number of
increasing times, and they are assumed to be alternating rise and fall
times. The numbers must represent one full clock period. If -waveform
edge_list is not specified, but -period period_value is, a default
waveform with a rise edge of 0.0 and a fall edge of period_value/2 is
assumed.
 [-add]: Use this option to either add the clock to the existing clock or to
overwrite the existing clock. Use this option to capture the case where
multiple clocks must be specified on the same source for simultaneous
analysis with different clock waveforms. When you specify this option,
you must also use the -name option. Defining multiple clocks on the
same source pin or port causes longer runtime and higher memory
usage than a single clock, because the synthesis timing engine must
explore all possible combinations of launch and capture clocks.
 [-comment <string>]: Use this option to specify comment. It allows
the command to accept a comment string. The tool honors the
annotation and preserves it with the SDC object so that the exact string
is written out when the constraint is written out when you use the
write_sdc or write_script command. The comment remains intact
through the synthesis, place-and-route, and timing-analysis flows.

create_generated_clock
Description
This command creates a generated clock object. Creates a generated clock
in the current design. If successful, the command returns a collection
containing the new or modified generated clock. You can specify a pin or a
port as a generated clock object. The command also specifies the clock
source from which it is generated. The advantage of using this command is
that whenever the master clock changes, the generated clock
automatically changes. If you use this command on an existing
generated_clock object, it overwrites its attributes. The generated_clock
objects are expanded to real clocks at the time of analysis. To display
information about generated clocks, use the report_clocks command.

916
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Syntax
create_generated_clock <master_pin>
-name <clock_name>
-divide_by <divide_factor>
-multiply_by <multiply_factor>
-duty_cycle <high_pulse_percentage>
-edges <edge_list>
-edge_shift <edge_shift_list>
-invert
-preinvert
-add
-combinational
-comment <string>
-pll_output <output_pin>
-pll_feedback <feedback_pin>
-master_clock <clock_name>

Arguments
 Default Argument: <master_pin>: Use this option to specify source
clock object from which this clock is derived (port or pin object).
 Default Argument: <>: Use this option to specify collection of objects.
 -name <clock_name>: Use this option to specify clock name.
 -divide_by <divide_factor>: Use this option to specify frequency
division factor (integer).
 -multiply_by <multiply_factor>: Use this option to specify
frequency multiplication factor (integer).
 -duty_cycle <high_pulse_percentage>: Use this option to specify
duty cycle(of high pulse width), if frequency multiplication is used.

917
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 -edges <edge_list>: Use this option to specify a list of positive


integers that represents the edges from the source clock that are to
form the edges of the generated clock.
 -edge_shift <edge_shift_list>: Use this option to specify a list of
floating-point numbers that represents the amount of shift, in library
time units, that the specified edges are to undergo to yield the final
generated clock waveform.
 -invert: Use this option to invert the generated clock signal.
 -preinvert: Use this option to create a generated clock based on the
inverted clock signal.
 -add: Use this option to add new options to the original clock.
 -combinational: Use this option to specify combinational signal.
 -comment <string>: Use this option to specify comment.
 -pll_output <output_pin>: Use this option to specify the output pin of
the PLL which is connected to the feedback pin.
 -pll_feedback <feedback_pin>: Use this option to specify the
feedback pin of the PLL.
 -master_clock <clock_name>: Use this option to specify master clock.

create_interface_wrapper
Description
This command creates the wrapper that instantiates the interfaces
specified using the add_top_interface commands, and connects the top
module ports to the interfaces/modports specified via the
connect_top_port commands. If the setup is incompletely specified, an
error is issued and the command is ignored.

Syntax
create_interface_wrapper
-top <top_module_name>
[-name <wrapper_name>]
[-output <wrapper_file>]

918
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

[-donot_compile]

Arguments
 -top <top_module_name>: Use this option to specify top module that is
instantiated in wrapper.
 [-name <wrapper_name>]: Use this option to specify the name of
wrapper (default top_<top_module_name>).
 [-output <wrapper_file>]: Use this option to specify the output file
for generated wrapper.
 [-donot_compile]: Use this option to create wrapper but not compile.

Examples
vc_static_shell> add_top_interface â?“top dut â?“interface
atb_if_t -instance ifx_a0
vc_static_shell> connect_top_port â?“port pm0 -interface
ifx_a0.master
vc_static_shell> connect_top_port â?“port ps0 â?“interface
ifx_a0.slave
vc_static_shell> read_file â?“top dut â?“sva â?“vcs { dut.v }
vc_static_shell> create_clock dut.clk â?“period 100
vc_static_shell> create_clock ifx_a0.clk â?“period 100
vc_static_shell> create_reset dut.resetn â?“low
vc_static_shell> create_reset ifx_a0.resetn â?“low

The generated wrapper would look like the following:


// Automatically Generated File: <date>
module top_dut;
atb_if_t ifx_a0();
dut dut (.pm0(ifx_a0.master),.ps0(ifx_a0.slave));
endmodule

create_reset
Description
This command is convenient and defines simulation reset value as well as
formal analysis value for a set of signals, all in one command. These

919
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

signals can be internal nets, or primary inputs (ports) of the design. Use of
create_reset is the same as pairs of sim_force and set_constant, but in
more concise and less error prone form. Return value is a collection, nets
or ports that are defined as resets with this command.

Syntax
create_reset [source_objects]
-sync
-async
-type {reset|set|both}
-name <reset_name>
-sense {low|high|any}
-add
-tdr

Arguments
 [source_objects]: List of nets, ports, and pins on which this reset is
defined.
 -sync: Use this option to specify if the signal drives synchronous reset.
If this argument is not specified, the reset is considered as async by
default.
 -async: Use this option to specify if the signal drives asynchronous
reset.
 -type {reset|set|both}: Use this option to specify the type of reset
signal. The default value is reset.
 -name <reset_name>: Use this option to specify the name of reset
signal.
 -sense {low|high|any}: These switches indicate the assertion polarity
for the reset signal. -low means the reset is asserted low. -high
indicates the reset is asserted high. any indicates the reset is asserted
to low or high. One of these switches is required.
 -add: Use this option to add new resets in addition to existing reset
specified in the default argument.

920
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 -tdr: The -tdr argument of the create_reset command has been


deprecated and will be removed in a future release. Use the
set_reset_inactive command instead to define a reset as inactive for
RDC analysis.

Examples
To create asynchronous reset on a pin a_RST_1:
create_reset a_RST_1 -type async

create_static
Description
Use this command to specify the design object (port/pin/net) which must
be treated as Quasi-static signal. Hierarchical objects can be specified in
this command. Quasi-static signals are the ones that are unlikely to change
and remain static most of the times.

Syntax
create_static <signal_name>
[-check_glitch]
[-des_clock <clk_name>]
[-cycle <cycle value>]
[-rise_edge <signal_name>]

Arguments
 Default Argument: <signal_name>: Use this option to specify
hierarchical pin or port or net name, which needs to be treated as quasi
static.
 <signal_name>: Use this option to specify hierarchical pin, port, or net
name that needs to be treated as quasi static.
 [-check_glitch]: Use this option to start Glitch analysis on the
specified Quasi objects.

921
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-des_clock <clk_name>]: Use this option to specify destination


clocks.
 [-cycle <cycle value>]: Use this option to specify the cycle of the
quasi static constraint. The value of this option must be an integer
between '1' and '100'; both inclusive.
 [-rise_edge <signal_name>]: Use this option to specify rise edge
signal of the quasi static constraint.

Examples
To make a EN signal quasi static:
create_static -name EN
To make a hierarchical pin quasi static:
create_static -name [get_pins -hierarchical Top/MUX/Sel

define_design_lib
Description
This command defines hdl design library.You can use this command
multiple times, once for each logical library name that is to be mapped to a
physical library. You can run the commands at any time, but they are valid
only before the first read into that logical library. When multiple logical
libraries point to the same physical library specified by using the
library_name argument, the tool uses the first logical library name that is
defined. The path specified by using the -path option is used for proper
mapping. All logical libraries that point to the same path, must share the
same physical library.
A logical library cannot be mapped to two physical libraries in the same
container. But they can be mapped to two physical libraries in different
containers.
This command returns 0 to indicate failure and 1 to indicate success.

Syntax
define_design_lib <library_name>
-path <directory>

922
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Arguments
 Default Argument: <library_name>: Use this option to specify the
design library to be mapped.
 -path <directory>: Use this option to specify the directory to map the
library.

define_glitch_free_mux
Description
The define_glitch_free_mux command defines a libcell or module on the
clock path as a glitch-free mux, which can be used to simplify its analysis.

Syntax
define_glitch_free_mux
[-module <module>]
[-cell <cell>]
[-clock <clock>]
[-select <select>]

Arguments
 [-module <module>]: Specifies the name of the glitch-free module
(default is the top name).
 [-cell <cell>]: Specifies the name of the glitch-free libcell (default is
the top name)
 [-clock <clock>]: Specifies a list of pin/port names corresponding to
the clock of the cell or module (optional)
 [-select <select>]: Specifies a list of pin/port names corresponding
to the control inputs of the cell or module (optional)

Examples
The following examples show the usage of the define_glitch_free_mux
command with -select option

923
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

vc_static_shell> define_glitch_free_mux -select {soft_sel_soc}


The following examples show the usage of the define_glitch_free_mux
command with -cell, -clock and -select options:
vc_static_shell> define_glitch_free_mux -cell CGMUX -clock {A B
C D} select { S0 S1 }

define_name_rules
Description
This command defines a set of rules for naming design objects. Name rules
are used by the change_names and report_names commands. The
report_name_rules command displays a listing of the name rules currently
defined in the shell.Name rules can be defined in multiple calls to the
define_name_rules command.
The -type option enables you to define rules that apply to a specific object
type, such as port, cell, or net). Each call to define_name_rules is additive
or overrides previous calls for a specific name rules.

Syntax
define_name_rules
[-allowed <char>]
[-first_restricted <string>]
[-last_restricted <string>]
[-prefix <prefix>]
[-map <map_string>]
[-type port|cell|net]
[-restricted <string>]
[-replacement_char <char>]
[-remove_char]
[-rule_name <rule_name>]

924
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Arguments
 [-allowed <char>]: Use this option to specify a set of allowed chars in
names.
 [-first_restricted <string>]: Use this option to specify set of
restricted first chars in name.
 [-last_restricted <string>]: Use this option to specify set of
restricted last chars in name.
 [-prefix <prefix>]: Use this option to specify prefix to be used when
creating names.
 [-map <map_string>]: Use this option to name mapping and
substitution.
 [-type port|cell|net]: Use this option to apply rules to port or cell or
net.
 [-restricted <string>]: Use this option to specify a set of restricted
chars in names.
 [-replacement_char <char>]: Use this option to specify replacement
char for name changes.
 [-remove_char]: Use this option to remove chars rather than replacing
illegal chars.
 [-rule_name <rule_name>]: Use this option to specify rule name.

define_reset_mapping
Description
This command associates block level reset to top level reset during CDC/
RDC hierarchical top run. This mapping between block and top level resets
is used for validating Block level constraints during hierarchical top run

Syntax
define_reset_mapping
-top_reset
-block_reset

925
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

-modules <list_of_modules>
-instances <list_of_instances>
-spec_file

Arguments
 -top_reset: Use this option to specify top level reset names.
 -block_reset: Use this option to specify block level reset names.
 -modules <list_of_modules>: Use this option to specify a list of
abstracted(SAM generated) modules.
 -instances <list_of_instances>: Use this option to specify a list of
abstracted instances.
 -spec_file: Use this option to specify the SDC file to be read in.

diff_database
Description
Given a previous run with violations on disk, this command reads the
violations from the previous run. For each violation which is common to
both runs, it either deletes the violation from the current run, or adds a
waiver for the violation in the current run. The result is a new, smaller
database where the current run contains only new violations, not found in
the previous run.
Either the option -remove or -waive must be given, to tell what operation
should be performed on the violations in both databases.
The previous run will normally have been saved by checkpoint_session in a
directory such as myrun_cpdb. Specify the session name with "-checkpoint
myrun". Since the database is not normally saved to disk, make sure to
save it before checkpointing by executing "save_db".
The older save/restore capability is also supported; specify the session
name with "-session myrun" to read from myrun_rtdb. In less common
flows, a database file may be directly available on disk; specify a filename
with "-raw mypath/report.db".

926
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Syntax
diff_database
[-remove]
[-waive]
[-checkpoint <session>]
[-session <session>]
[-raw <filename>]
[-app <Application>]

Arguments
 [-remove]: Remove violations found in previous database
 [-waive]: Waive violations found in previous database
 [-checkpoint <session>]: Checkpoint session name
 [-session <session>]: Saved session name
 [-raw <filename>]: Raw database filename (less common)
 [-app <Application>]: Use this option to specify the application
name.

disable_tag_field
Description
This command prevents a field from being printed in the report_* output
for a tag.

Syntax
disable_tag_field <tag>

Arguments
 Default Argument: <tag>: Use this option to specify the tag name.
 Default Argument: <field>: Use this option to specify the field that
must not appear in the report_* output.

927
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

dw_analyze
Description
This command analyzes the DW source files using the specified
VCS_HOME.

Syntax
dw_analyze <>
-log <log_file>
-fgpa

Arguments
 Default Argument: <>: Use this option to specify DW source.
 Default Argument: <>: Use this option to specify writable installation
directory.
 -log <log_file>: Use this option to specify log file.
 -fgpa: Specify this option to use FPGA libraries for HAPS.

elaborate
Description
This command builds a design from the intermediate format of a Verilog
module, a VHDL entity and architecture, or a VHDL configuration.
Note: Using this command, the user can elaborate design from pre-analyzed
design files, from a specified top module. At the completion, this command
returns 1 on success and 0 on failure.
Note: When the -vcs option is specified, other options cant be specified.

Syntax
elaborate <design_name>
[-library <library_name>]

928
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

[-work <library_name>]
[-architecture <arch_name>]
[-parameters <param_list>]
[-file_parameters <file_list>]
[-vcs <vcs_command>]
[-sva]
[-sva2005]
[-v2kconfig <configuration-name>]
[-buildTop <dut name>]
[-j <number_of_processes>]

Arguments
 Default Argument: <design_name>: Use this option to specify the
design name which needs to be elaborated. The design can be Verilog
module of VHDL entity.
 [-library <library_name>]: Use this option to remap the work library
to library_name. This option can only be used with the VHDL format. By
default, the analyze command stores all output in the work library. To
store design elements in libraries other than library specified by using
the -work option, use the -library option.
 [-work <library_name>]: Use this option to remap the work library in
the same way as the -library option. It is an alias for the -library option
for VHDL only. Specifies the library name to which work must be
mapped. The -work option references the library where the top-level
unit of the elaboration hierarchy is compiled. If the elaboration starts
from a module, then it is the library name where the module is
compiled. If the elaboration starts from a configuration (in case of -
v2kconfig), it is the library name where the configuration is compiled.
 [-architecture <arch_name>]: Use this option to specify the name of
the architecture. In VHDL, the default architecture is the most recently
analyzed architecture.
 [-parameters <param_list>]: Use this option to specify a list of
design parameters enclosed in quotes for Verilog. For VHDL use -vcs {-
gv ...} option. Parameters within the list must be separated by commas.

929
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

A specification can be based on parameter order (for example, 8,7,5) or


on parameter names (for example, N=>8,M=>6). It is acceptable to
mix ordered and named parameter specifications, as long as the ordered
parameters are listed first..
 [-file_parameters <file_list>]: Use this option to specify a list of
files that contain parameter specifications. The specifications are
appended to the parameters listed in the -parameters option (if
present). The syntax of the parameter file is identical to the syntax
between the parameter-delimiters (#) in the -parameters option, except
that the backslashes (\\) at the end of lines and the hashes (#) must be
omitted. The specified files are searched for in the search_path.
 [-vcs <vcs_command>]: Use this option to read the design using VCS
command arguments and switches. Options specified by -vcs follow the
VCS command-line syntax. When specifying the VCS commands, you
must include them either in ‘{ }’ or double quotes. Note: (1)If
there is one design top, it should not be passed using vcs arguments.
that is, elaborate -vcs {designtop}. It should be passed as follows:
%elaborate designtop (2) For a model with several top modules (in
following example: dut_top and tb_top), you must pass the arguments
as follows: %elaborate dut_top -vcs tb_top.
The [-sverilog|-verilog] argument specifies the format of the files to be
analyzed.
The [-y directory_path] argument specifies directories that contain the
library files to be searched for unresolved module instantiations in the
design.
The [+libext+.extension1+...] argument specifies the extension to
consider during a files search in the -y library directories. The default is
no extension.
The [-v library_file] holds several module definitions, to be used during
the search for unresolved modules.
The [-f command_file] argument specifies a command file.
The [+define+macro_name+...] argument defines a macro.
The [+incdir+dir1+...] argument includes directories in the search list.
 [-sva]: Use this boolean switch to compile any discovered SVA or PSL
properties into formally analyzable form when the design is read in.
Properties declared in the source code will be initially enabled as they

930
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

are declared in the code (assume, assert, cover). Use this option to
process SVA/PSL during compilation using 2009 semantics.
 [-sva2005]: Use this option to process SVA/PSL during compilation
using 2005 semantics.
 [-v2kconfig <configuration-name>]: Use this option to specify the
v2k configuration. v2k configuration cannot be directly specified as a
design top.
 [-buildTop <dut name>]: Use this option to specify the DUT down
from which synthesis model is generated.
 [-j <number_of_processes>]: Use this option to specify the number of
processes that can be used for parallel compilation in the RTL flow.
Value >= 1

Examples
The following example elaborates a design named top from a library name
my_work.
elaborate top -work my_work

execute_rootcause_analysis
Description
This command invokes the ML RCA engine and generates clusters of
related violations.

Syntax
execute_rootcause_analysis
-app <list of apps>
[-limit <count>]
[-j]
[-disable_non_rca_clustering]
[-rule_group_file <file_name>]
[-stage <list of stages>]
[-dashboard_limit <count>]

931
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

[-update_cause_viols]

Arguments
 -app <list of apps>: Specifies the application name on which to apply
clustering: Values: cdc, lint, rdc.
 [-limit <count>]: Limits the number of clusters to show. Set the
value to 0 to see all clusters.
 [-j]: Enables multi-threaded cluster generation for CDC. Specify the
number of threads to be used as argument value.
 [-disable_non_rca_clustering]: Disables non-RCA default clustering
after RCA clustering.
 [-rule_group_file <file_name>]: Specifies the rule group list path
 [-stage <list of stages>]: Specifies the stage whose effect
violations participate in clustering. Valid values include, conv, sync
(Default). Supported only in cdc flow.
 [-dashboard_limit <count>]: Limits the number of clusters for which
information is generated inside dashboard. Set the value to 0 to
generate information for all the clusters.
 [-update_cause_viols]: Regenerates all cause violations after
applying the constraints added for fanin signals.

Examples
Below is a sample tcl file for CDC run.
set_app_var enable_cdc true
#Other app var setting if required for VC SpyGlass CDC run
analyze
elaborate
read_sdc sdc_setup.sdc
source cdc_config.tcl #contains configure commands
enable_rca_cluster -app cdc # enables RCA-ML feature
check_cdc
execute_rootcause_analysis -app cdc #Performs RCA
report_cdc

932
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

generate_waiver_commands
Description
This command can be used to generate field-based waiver(s)
corresponding to violations.

Syntax
generate_waiver_commands
-app <app list>
[-status]
[-viol <viol list>]

Arguments
 -app <app-list>: Waivers will be generated for the specified
applications.
 [-status]: Waivers are generated with the specified state. Valid values
include: Acknowledged, NeedsInfo, Open, Waived, Waived_Temp, and
Ignore.
 [-viol <viol list>]: Field-based waivers are generated for the
specified violation id(s).

Examples
The following command generates filtered report:
generate_waiver_commands -app CDC -viol [ report_cdc -tag
SYNCCDC_CTRLPATH_FULL -id_list ]
In this case, VC SpyGlass CDC generates the following data:
waive_cdc -add SYNCCDC_CTRLPATH_FULL_98 -tag
SYNCCDC_CTRLPATH_FULL -filter { ContainerInstance ==
"a_syncInfo" && DestClockInfoList:DestClockInfo:ClockName ==
"c2" && DestClockInfoList:DestClockInfo:ClockObject == "clk2"
&& DestObject == "a_syncInfo/dest/out/Q[0]" && DestObjectType
== "flop" && DstFileLine:FileName == "../test.v" &&
DstFileLine:LineNumber == "295" && Module == "MultiSrcNFF" &&
ReasonInfoList:ReasonInfo:ReasonCode == "SYNC_BY_NFF" &&

933
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

ReasonInfoList:ReasonInfo:ReasonCodeMsg == "[INFO] Multi Flop


Synchronizer detected" &&
SrcClockInfoList:SrcClockInfo:ClockDomainId == "1.1" &&
SrcClockInfoList:SrcClockInfo:ClockName == "c1" &&
SrcClockInfoList:SrcClockInfo:ClockObject == "clk1" &&
SrcFileLine:FileName == "../test.v" && SrcFileLine:LineNumber
== "295" && SrcObject == "a_syncInfo/b_src/out/Q[0]" &&
SrcObjectType == "flop" && SyncDepth == "2" && SyncObject ==
"a_syncInfo/syncI/out/Q[0]"}
The following command generates the complete report:
generate_waiver_commands -app CDC
The generate_waiver_commands command honors the
configure_waiver_filter_field command and the
enable_default_waiver_filter_fields application variable. If you have
defined some fields for a tag by using the configure_waiver_filter_field
command, the enable_default_waiver_filter_fields application variable, or if
it is predefined by the application, waivers are generated using the defined
fields. Else, all fields are used.
For example, the configure_waiver_filter_field -tag
SYNCCDC_CTRLPATH_FULL -disable -field SrcObjectType command can
be used to disable generation for the Source object type.

get_blackbox
Description
This command returns the collection of black-boxed elements in the
design.

Syntax
get_blackbox
-designs
-automatic
-unresolved

934
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Arguments
 -designs: Use this option to create a collection of designs which are
black-boxed.
 -automatic: Use this option to create a collection of cells that are
automatically black-boxed by the tool, while loading the design. This
usually happens if an instance is present in the design, but its definition
is missing in the design. This can also happen if a module has non-
synthesizable constructs, hence the hardware inference tool has black-
boxed that module because that module cannot be synthesized.
 -unresolved: Use this option to return unresolved modules in the
design.

Examples
The following example shows the usage of the get_blackbox command:
vc_static_shell> get_blackbox -designs
{"module1"}

get_clock_relationship
Description
This command reports the relationship between any given number of
clocks based on the status of current clock groups. The relationship can be
asynchronous,logically_exclusive or physically_exclusive. Multiple types of
relationships or no relationship can exist between clocks.

Syntax
get_clock_relationship
-clocks
[-type <type>]
[-csv]
[-file <file name>]
[-gui]

935
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Arguments
 -clocks: Use this option to specifiy the clocks for which the relationship
needs to be reported.
 [-type <type>]: Use this option to check if a particualar type of
relationship exists between the given clocks.
 [-csv]: Use this option to report the output in comma separated
format.
 [-file <file name>]: Use this option to dump the output to a text file.
 [-gui]: Use this option to report the output in GUI.

Examples
The following example queries the relationship between clocks c1 and c2
prompt> get_clock_relationship {c1 c2}
asynchronous
The following example queries the if the clocks c1 cand c2 have a logically
exclusive relationship.
prompt> get_clock_relationship {c1 c2} -type
logically_exclusive
true
The following example reports the relationship between clocks c1 and c2 in
CSV format. -csv option is avaliable only in non-PT mode.
prompt> get_clock_relationship {c1 c2} -csv
'Clock1','Clock2','Relationship'
c1,c2,asynchronous
c2,c1,asynchronous

get_constant_sources
Description
Reports the RTL/SCA constant sources propagating to a signal. The
command calls a fanin traversal from the given constant signal, until it
reaches RTL constants (supply/ground) or set_case_analysis. Then it reports
the constant sources along with their types.

936
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Syntax
get_constant_sources <>

Arguments
 Default Argument: <>: Object to which constant(s) propagate

Examples
> get_constant_sources FF/CLK
Type Object
RTL scan_en
SCA sel1
SCA sel2

get_exception
Description
This command creates a collection of exception objects which are used to
store constraints information of any design object.
The command returns a collection, if the given pattern matches any design
object and constraints are defined on that object. If no object matches, the
command returns an empty string.
You can use this command at the command prompt or you can nest it as an
argument to another command, such as get_attribute. In addition, you can
assign the result to a variable.

Syntax
get_exception <design_object_name>
[-type]

Arguments
 Default Argument: <design_object_name>: Search for design objects
which matches this pattern and collects constraints on those objects.

937
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-type]: Searches for constraints in the given type only. This can be
one of set_case_analysis, set_cdc_ignore_path, set_clock_sense or
set_disable_timing.

Examples
The following example queries the constraints defined on the pin RG1/Q.
prompt> get_attribute [get_exceptions -type set_case_analysis
RG1/Q] type set_case_analysis
The following example queries the file line information of the constraints
defined on the pin RG1/Q.
prompt> get_attribute [get_exceptions RG1/Q] source {File: ./
test.sdc Line: 7} {File: ./test.sdc Line: 8} {File: ./test.sdc
Line: 9}
The following example queries the commands of the constraints defined on
the pin RG1/Q.
prompt> get_attribute [get_exceptions RG1/Q] command
{set_case_analysis 1 [get_pins RG1/Q]} {set_clock_sense
[get_pins {RG1/Q}]} {set_disable_timing [get_pins { RG1/Q }]}

get_field_subfield
Description
This command is used to query the qualified fields of violation which
belongs to record type.

Syntax
get_field_subfield <tag>
[-leaf]
[-quiet]

Arguments
 Default Argument: <tag>: Use this option to specify the tag name
you want to query.

938
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 Default Argument: <field>: Use this option to specify the field name
in the tag you want to query.
 [-leaf]: Use this option to recursively query the subfields.
 [-quiet]: Use this option if you want to suppress the error messages.

Examples
%vc_static_shell> get_field_subfield DESIGN_PIN_SCMR
InstanceInfo
PowerNet GroundNet PowerMethod GroundMethod
%vc_static_shell> get_field_subfield DESIGN_PIN_SCMR
InstanceInfo -leaf
PowerNet:NetName PowerNet:NetType GroundNet:NetName
GroundNet:NetType PowerMethod
GroundMethod
%vc_static_shell> get_field_subfield DESIGN_PIN_SCMR
wrong_instance
Error: undefined field 'wrong_instance'
%vc_static_shell> get_field_subfield DESIGN_PIN_SCMR
wrong_instance -quiet

get_glassbox
Description
This command returns list of objects which are listed as glassbox.

get_license
Description
Use this command to check-out the application specific license keys
explicitly. The command reserves all keys required by a particular script at
the beginning of a batch script. This command returns the number of
application license keys successfully obtained. For more details on the
application license keys, see the VC Static Platform Product Installation
Notes.

939
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Syntax
get_license <feature-list>
-quantity <num>
[-licwait <minutes>]

Arguments
 Default Argument: <feature-list>: Specifies the list of application
specific keys to be reserved.
 -quantity <num>: Specifies the total number of licenses to be checked
out: num >= 1
 [-licwait <minutes>]: Specifies the time period for which the license
server must wait (in minutes) before terminating the run.

get_no_msg_reporting_tags
Description
This command returns list of tags which doesn't report any violation
It will check all the tags which are enabled for the required applcation.
A tag may not report violation due to either it has not been run or it has
not found any violation scenario which needs to reported.

Syntax
get_no_msg_reporting_tags [<app>]

Arguments
 Default Argument: [<app>]: Use this option to specify the application
name , default Lint.

Examples
To get information about the tags which doesn't report any violation, use:
vc_static_shell> get_no_msg_reporting_tags Lint

940
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

get_pi_drive_clock
Description
This command returns all reset/clock pairs in the database.

get_readmsg_attribute
Description
This command returns specific attribute for a design read message.

Syntax
get_readmsg_attribute <>

Arguments
 Default Argument: <>: Use this option to specify message name.
 Default Argument: <>: Use this option to specify attribute name.

Examples
The following example retrieves the count attribute in the message
UPF_OBJECT_NOT_FOUND_ERROR.
get_readmsg_attribute UPF_OBJECT_NOT_FOUND_ERROR count

get_readmsg_field
Description
This command returns string data for one qualified field of the design read
message.

Syntax
get_readmsg_field <id>

941
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Arguments
 Default Argument: <id>: Use this option to identify integer violation.
 Default Argument: <field>: Use this option to specify qualified field
name.

Examples
The following example returns the 'file' field of the message with id given
by $id.
get_readmsg_field $id file

get_readmsg_ids
Description
This command returns the list of ids of violations for the given design read
message.

Syntax
get_readmsg_ids <name>

Arguments
 Default Argument: <name>: Use this option to specify existing design
read message name.

Examples
The following example returns the list of message ids corresponding to the
message, UPF_OBJECT_NOT_FOUND_ERROR.
get_readmsg_ids UPF_OBJECT_NOT_FOUND_ERROR

get_readmsg_names
Description
This command returns list of design read message names.

942
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Syntax
get_readmsg_names [<type>]

Arguments
 Default Argument: [<type>]: Use this option to specify design read
type and default is UPF.

Examples
The following example retrieves all upf read messages.
get_readmsg_names upf

get_readmsg_names
Description
This command returns list of design read message names.

Syntax
get_readmsg_names [<type>]

Arguments
 Default Argument: [<type>]: Use this option to specify design read
type and default is UPF.

Examples
The following example retrieves all upf read messages.
get_readmsg_names upf

get_violation_waiver
Description
This command returns the name of the waiver covering a single violation,
or the empty string if it is not waived. For example, to get the name of the

943
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

waiver covering violation 123, use:


vc_static_shell> set violation_name [get_violation_waiver 123]
To get a list of all the tags with violations in the current run, use
get_violation_tags. To get a list of all the violation IDs for an individual tag,
use get_violation_ids.
There are also commands that operate on tag definitions; for an overview,
see get_tags.

Syntax
get_violation_waiver <id> [<id>]

Arguments
 Default Argument: <id>: Use this option to identify integer violation.
 Default Argument: [<app>]: Use this option to specify application
name.

get_waiver_attribute
Description
This command returns specific attribute for waiver. This command helps to
identify specific attributes in the filter database and can be used to identify
waivers which possess a specific quality. One main usage of this command
is to identify waivers with no violations waived (zero violation count) and
correct/delete them.

Syntax
get_waiver_attribute <waiver>

Arguments
 Default Argument: <waiver>: Use this option to specify waiver name.
 Default Argument: <attribute>: Use this option to specify the
attribute name.

944
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

get_waivers
Description
This command is used to query all the waivers which matches the specified
pattern.

Syntax
get_waivers <pattern>

Arguments
 Default Argument: <pattern>
Use this option to specify pattern of waivers to be returned.

Examples
%vc_static_shell> get_waivers *ISO*
FLT-ISO_STRATEGY_MISSING

index_database
Description
This command creates an index to speed up multiple waivers. It speeds up
subsequent waiver/filter operations by creating a cache for commonly
requested fields. If only one or two simple waivers are executed, this
command will occupy more time than simply executing the waivers.
However, if many complex waivers are being executed, creating this cache
saves time.

infer_clock_roots
Description
This command infers clock roots automatically without the need of defining
the clock information using SDC.
This command does not provide any output. Use report_clock_roots -file

945
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

file_name to dump inferred clock roots to a file. This file can be read using
read_sdc file_name.

Syntax
infer_clock_roots
-exclude_latch
-sequentials <list_of_Qpins_or_cells>

Arguments
 -exclude_latch: Use this option to trace latch enables for clock root
identification.
 -sequentials <list_of_Qpins_or_cells>: Use this option to specify
sequential elements for which clock roots will be identified.

infer_reset_roots
Description
This command infers reset roots.

Syntax
infer_reset_roots
-include_latch
-report_reg <file_name>

Arguments
 -include_latch: Use this option to trace latch enables for reset root
identification.
 -report_reg <file_name>: Use this option to dump register and its
reset root to a specified file.

infer_setup

946
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Description
This command infers clock roots/reset roots automatically without the need
of defining the clock or reset information using SDC.
This command does not generate any output. Use the
write_inferred_setup -type (clock/reset) -file file_name to
include inferred clock roots/reset roots to a file.

Syntax
infer_setup
-type <clock/reset>
[-incremental]
[-full]
[-apply]
[-infer_all_potentials]
[-generated_clocks <true/false>]
[-generated_resets <true/false>]
[-sync_resets <true/false>]
[-infer_gated <true/false>]
[-include_hanging]
[-check_vcs_clock]
[-infer_latch_out]
[-filter_names <clock_name|reset_name>]

Arguments
 -type <clock/reset>: Use this option to specify the type of root
(clock/reset) to be inferred.
 [-incremental]: Use this option to specify that user-defined
commands are propagated first and then inference is done only from
elements that are not receiving anything.
 [-full]: Use this option to specify that all the roots are inferred.
 [-apply]: Use this option to use inferred clocks directly.

947
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-infer_all_potentials]: Use this option to enable inference to all


roots in auto detection.
 [-generated_clocks <true/false>]: Use this option to dump the
generated clocks.
 [-generated_resets <true/false>]: Use this option to dump the
generated resets.
 [-sync_resets <true/false>]: Use this option to enable inference for
sync resets.
 [-infer_gated <true/false>]: Use this option to enable inference for
gated roots.
 [-include_hanging]: Use this option to enable inference of clocks on
hanging nets.
 [-check_vcs_clock]: Use this option to infer paths with the vcs_clock
attribute.
 [-infer_latch_out]: Use this option to enable inference of latch
outputs as generated clock.
 [-filter_names <clock_name|reset_name>]: Use this option to not
infer clock/reset which have the specified string in its name.

Examples
To infer clock root/reset root based upon type requested.
infer_setup -type clock
write_inferred_setup -type clock -file infer.sdc

link
Description
This command is used to link current design.This command uses the
link_library and search_path variables to resolve design references. A "*"
entry in the value of the link_library variable indicates that link should
search all the designs already loaded in memory. If the link_library variable
has no "*" entry, the already-loaded designs are not searched. The default
value for the link_library variable is "* your_library.db". The search_path
variable specifies a list of directory names that the link command uses to

948
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

search for link_library files.


For simple file names (names that contain no '/' character), the link
command looks for the files in the directories specified by the search_path
variable. For absolute or relative path names, the search_path variable is
not used. If the referenced designs are not found in any of the specified
files, the link command looks in the search path directories for any .ddc or
.db files that have the same name as the referenced design (for example,
adder.ddc or adder.db). In this case, the .ddc files are searched first.
The order of directories in the search path and of the files in the link
libraries is important. Search order during a link is (1)Local link library files
(2)Link library files (3)Search path directories The first occurrence of a
design reference is used.

Syntax
link
-cov <metric_type>
-llk <llk_type>
-aep <aep_type>
-inject_fault <fault_type>

Arguments
 -cov <metric_type>: Use this option to enable coverage
instrumentation during compilation.
 -llk <llk_type>: Use this option to create livelock goals during
compilation.
 -aep <aep_type>: Use this option to specify the types of AEP checks
that should be instrumented as the design is compiled.
 -inject_fault <fault_type>: Use this option to inject behavioral
faults in the design for doing sign-off with formal.

link_design
Description
The link_design locates all designs and library components that are

949
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

referenced by the current design and links them to the current design.
During linking, the tool loads all files specified by the link_path variable if
they are not already in memory. Successful linking results in a fully
instantiated design on which you can perform analysis.

Syntax
link_design
[-design_name <design>]
[-quiet]

Arguments
 [-design_name <design>]: Specifies the design to be linked. The
default is the current design.
 [-quiet]: Does not print any information with this option.

Examples
The following example shows the usage of the link_design command:
vc_static_shell> read_verilog top.v
vc_static_shell> link_design top

list_all_waiver_files
Description
A waiver command can now be linked to a file when created from GUI or
given through manage_waiver_file command. This command displays a
complete list of files that are associated with such waivers.

llib
Description
This command lists information within library.This command lists the
information of VHDL objects (entity, architecture, configuration, package
and package body) and Verilog objects (modules) in specified design

950
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

library. It supports for pure design i.e. Verilog, VHDL, *.sv and mix design
as well. Before using this command, you must load design using analyze
command and then use this command.

Syntax
llib
[-l]
[-r]
[-lib <library_name>]
[-all]
[-design_unit_name <design_unit_name>]

Arguments
 [-l]: Use this option to show VCS version, timestamp, dependencies,
package references, etc.
 [-r]: Use this option to print architecture name for each entity and
print package body name for each package.
 [-lib <library_name>]: Use this option to search the logical name of
the library.
 [-all]: Use this option to search all logical libraries in setup file.
 [-design_unit_name <design_unit_name>]: Use this option to specify
design unit name (Configuration, Package, Entity or Module).

man
Description
This command shows the man page for the given command or message.
This command is used to view the runtime documentation for Monet
messages and commands in the Monet shell.

Syntax
man
-command_name

951
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Arguments
 -command_name: Use this option to specify the man page name.

merge_database
Description
This command merges report database from a saved run into the current
run.This command helps you to read a report database on the disk from a
previous run, and merge it into the report database for the current run.
Given a previous run with violations on disk, this command reads the
violations from the previous run. For each violation which is unique to the
previous run, it adds a copy of the violation into the current violation
database. The result is a new, larger database which is the union of both
databases.
The previous run will normally have been saved by checkpoint_session in a
directory such as myrun_cpdb. Specify the session name with "-checkpoint
myrun". Since the database is not normally saved to disk, make sure to
save it before checkpointing by executing "save_db".
The older save/restore capability is also supported; specify the session
name with "-session myrun" to read from myrun_rtdb. In less common
flows, a database file may be directly available on disk; specify a filename
with "-raw mypath/report.db".

Syntax
merge_database
[-session <session_name>]
[-input_filename <input_filename>]
[-checkpoint <session>]

Arguments
 [-session <session_name>]: Use this option to specify the name of
saved session to merge messages from database.
 [-input_filename <input_filename>]: Use this option to specify raw
message file.

952
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 [-checkpoint <session>]: Checkpoint session name

read_cdc_constraints
Description
This command reads in SDC file.

Syntax
read_cdc_constraints
[-version_sdc_version]
[-module <list_of_modules>]
[-instance <list_of_instances>]
[-spec_file]

Arguments
 [-version_sdc_version]: Use this option to specify SDC version value.
 [-module <list_of_modules>]: Use this option to specify a list of
modules for which the SDC must be applied.
 [-instance <list_of_instances>]: Use this option to specify a list of
instances for which the SDC must be applied.
 [-spec_file]: Use this option to specify SDC file to be read.

read_file
Description
This command helps you to read in design source files, and link design in
memory. This command can be used to load design in single language
(Verilog/SV or VHDL)
Note: Using this command, the user can specify all source files in one
command in a single language environment. The files get analyzed and then
elaborated. Upon completion of the command the complete design has been

953
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

loaded and is ready to be used. The command returns 1 on success and 0 on


failure.
Note: When the -vcs option is specified, other options cant be specified.

Syntax
read_file
- <top>
-library <library name>
-define <list of verilog defines>
-work <library name>
-netlist
-parameters <string containing ordered or named parameters
separated by comma>
-vcs <vcs command line>
-vcs_elab <vcs elaborate command line>
-sva
-sva2005
-v2kconfig <configuration-name>
-buildTop <dut name>
-multi_step
-cov <metric_type>
-llk type <llk_type>
-aep <aep_type>
[-inject_fault <fault_type>]
-j <number_of_processes>
-slist

Arguments
 -<top>: Use this option to specify the name of the top design.

954
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 -library <library name>: Use this option to remap the work library to
library_name. This option can only be used with the VHDL format. By
default, the analyze command stores all output in the work library. Use
the -library option to store design elements in libraries other than library
specified by using the -work option.
 -define <list of verilog defines>: Use this option to specify a list
of top-level macros. This option can only be used with the Verilog and
System Verilog formats.
 -work <library name>: Use this option to remap the work library in the
same way as the -library option. It is an alias for the -library option for
VHDL only. Specifies the library name to which work must be mapped.
The -work option references the library where the top-level unit of the
elaboration hierarchy is compiled. If the elaboration starts from a
module, then it is the library name where the module is compiled. If the
elaboration starts from a configuration (in case of -v2kconfig), it is the
library name where the configuration is compiled.
 -netlist: Use this option to invoke the Verilog netlist reader. This
option should only be specified if the design is in Verilog netlist format
only, no behavioral syntax is present. This option cannot be used in
conjunction with -vcs option.
 -parameters <string containing ordered or named parameters
separated by comma>: Use this option to specify a list of design
parameters enclosed in quotes. Parameters within the list must be
separated by commas. A specification can be based on parameter order
(for example, 8,7,5) or on parameter names (for example,
N=>8,M=>6). It is acceptable to mix ordered and named parameter
specifications, as long as the ordered parameters are listed first.
 -vcs <vcs command line>: Use this option to read the design using
VCS command arguments and switches. Options specified by -vcs follow
the VCS command-line syntax. When specifying the VCS commands,
you must include them either in ‘{ }’ or double quotes.
The [-sverilog|-verilog] argument specifies the format of the files to be
analyzed.
The [-y directory_path] argument specifies directories that contain the
library files to be searched for unresolved module instantiations in the
design.
The [+libext+.extension1+...] argument specifies the extension to
consider during a files search in the -y library directories. The default is

955
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

no extension.
The [-v library_file] holds several module definitions, to be used during
the search for unresolved modules.
The [-f command_file] argument specifies a command file.
The [+define+macro_name+...] argument defines a macro.
The [+incdir+dir1+...] argument includes directories in the search list.
 -vcs_elab <vcs elaborate command line>: Use this option to
elaborate the design using VCS command arguments and switches
enclosed in curly braces. Specifies all VCS-specific command-line
options. Options specified by -vcs follow the VCS command-line syntax.
 -sva: Use this option to process SVA/PSL during compilation using 2009
semantics.
 -sva2005: Use this option to process SVA/PSL during compilation using
2005 semantics.
 -v2kconfig <configuration-name>: Use this option to specify the v2k
configuration. V2k configuration cannot be directly specified as a design
top.
 -buildTop <dut name>: Use this option to specify the DUT down from
which synthesis model is generated.
 -multi_step: Use this option to load design in multi step mode.
 -cov <metric_type>: Use this option to specify types of structural
coverage properties that should be instrumented as the design is
compiled. These coverage properties match equivalent coverage objects
in VCS in senatics and locations. The keyword all is supported to prepare
for all structural coverage property types. Valid coverage property types
are the following and are separated by the plus + delimiter: line, cond,
toggle, fsm_state, fsm_transition. In order to control the shapes of
coverage instrumentation, the standard VCS switches such as like -
cm_cond, -cm_tgl etcetera can be used. These switches are passed
through the -vcs switch of read_file command.
 -llk type <llk_type>: Use this option to create livelock goals during
compilation.
 -aep <aep_type>: Use this option to specify types of AEP properties
that should be instrumented as the design is compiled. The keyword all
is supported to prepare for all structural property types. Valid structural

956
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

property types are the following and are separated by the plus +
delimiter:
 bounds_check: Create a property every place in the source design
where an array is indexed with a variable. The property will fail if the
index can be assigned a value that is outside the bounds of the
declared array. The type attribute is set to bounds_check.
 multi_driver: Create a check for signals that are driven by multiple
drivers. The property will fail if the signal is simultaneously driven by
more than 1 signal. The type attribute is set to multi_driver.
 conflict_driver: Create a check for signals that are driven by multiple
drivers. The property will fail if the signal is simultaneously driven by
more than 1 signal to opposite logic values. The type attribute is set
to conflict_driver.
 floating_bus: Create a check for signals that are driven by multiple
drivers. The property will fail if the signal is not driven by at least 1
driver at all times. The type attribute is set to floating_bus.
 x_assign: Create a check for every statement in the rtl where an
explicit logic X assignment is made. The property will fail if the
assignment is ever activated. The type attribute is set to x_assign.
 arith_oflow: Find all occurrences of arithmetic operators in the design
(+, -, *, /). The property will fail if the expression ever over- or
underflows the legal ranges for the operation being executed. The
type attribute is set to arith_oflow.
 set_reset: Find all sequentials in the design which use both set and
reset. The property fails if the set and reset signals are ever asserted
at the same time. The type attribute is set to set_reset.
 parallel_case: Find all occurrences of the parallel case directives in
the code. These can be either: // synopsys parallel_case pragma, //
synthesis parallel_case pragma, or SystemVerilog unique keyword
case statements. For each of those scenarios, the property will fail if
the design can behave in a way such that the pragma does not hold.
The type attribute is set to parallel_case.
 [-inject_fault <fault_type>]: Use this option to inject behavioral
faults in the design for formal testbench analyzer flow.
 -j <number_of_processes>: Use this option to specify the number of
processes that can be used for parallel compilation in the RTL flow.
Value >= 1.

957
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 -slist: Use this option to specify list of input files.

Examples
The following example reads in a verilog file named top.v in verilog netlist
format. The design top is named top.
read_file -format verilog -top top top.v -netlist

read_sdc
Description
This command helps you to read an already existing SDC file as an input.
SDC commands can be specified as Monet shell commands using this
command. (Currently SDC commands are read in Monet shell). Also, this
command is used to read User specified SDC file to populate SDC data
model.

Syntax
read_sdc
-version_sdc_version
-module <list_of_modules>
-instance <list_of_instances>
-spec_file

Arguments
 -version_sdc_version: Use this option to specify the SDC version
value.
 -module <list_of_modules>: Use this option to specify a list of
modules for which the SDC needs to be applied.
 -instance <list_of_instances>: Use this option to specify a list of
instances for which the SDC needs to be applied.
 -spec_file: Use this option to specify the SDC file to be read in.

958
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

remove_case_analysis
Description
This command removes the effect of setting value constraints from the
specified list of ports/pins/nets. Upon completion, it returns 1 for success
and 0 otherwise.

Syntax
remove_case_analysis
-all
-list

Arguments
 -all: Use this option to remove all case_analysis.
 -list: Use this option to specify a list of port/pin/net objects.

Examples
Here effect of constant value specified on “in1�port will get removed.
While for “in2�it will remains effective. If remove_case_analysis
–all is used then effect on all ports will get removed. i.e in this case on
both “ïn1�and “in2� .
vc_static_shell>set_case_analysis 1â?™b1 {in1 in2}
vc_static_shell>remove_case_analysis in1

remove_clock
Description
Removes one or more clocks from the current design.
To display information about clocks and generated clocks in the design, use
the report_clock command.

Syntax
remove_clock

959
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

-all
-clock_list

Arguments
 -all: Specifies to remove all clocks in the current design.
 -clock_list: Specifies a list of collections containing clocks or patterns
matching the clock names.

Examples
The following example removes clock CLK1.
vc_static_shell>remove_clock CLK1
The following example removes all clocks from current design.
vc_static_shell>remove_clock -all

remove_clock_groups
Description
Removes specific exclusive or asynchronous clock groups from the current
design.

Syntax
remove_clock_groups
[-logically_exclusive]
[-physically_exclusive]
[-exclusive]
[-asynchronous]
-name
-all

Arguments
 [-logically_exclusive]: Specifies that the groups set for logically
exclusive clocks are to be removed. The -physically_exclusive, -

960
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

logically_exclusive, and -asynchronous options are mutually exclusive.


You must choose only one.
 [-physically_exclusive]: Specifies that the groups set for physically
exclusive clocks are to be removed. The -physically_exclusive, -
logically_exclusive, and -asynchronous options are mutually exclusive.
You must choose only one.
 [-exclusive]: Specifies that the groups set for logically exclusive
clocks are to be removed.
 [-asynchronous]: Specifies that groups set for asynchronous clocks are
to be removed. The -physically_exclusive, -logically_exclusive, and -
asynchronous options are mutually exclusive. You must choose only
one.
 -name: Specifies a list of clock groups to be removed, which matches the
groups in the given names. These clock groups are predefined by the
set_clock_groups command. The -name and -all options are mutually
exclusive.
 -all: Specifies to remove all groups set for exclusive or asynchronous
clocks in the current design. The -name and -all options are mutually
exclusive.

Examples
The following example removes logically_exclusive clock group named
GRP1.
vc_static_shell>remove_clock_groups -logically_exclusive -name
GRP1
The following example removes all asynchronous clock groups from current
design.
vc_static_shell>remove_clock_groups -asynchronous -all

remove_generated_clocks
Description
Removes generated clock objects from the current design.
To display information about clocks and generated clocks in the design, use
the report_clock command.

961
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

Syntax
remove_generated_clocks
-all
-generated_clk_name

Arguments
 -all: Indicates that all generated clocks are to be removed.
 -generated_clk_name: Specifies a list of names of generated clocks to
be removed.

Examples
The following example removes generated clock GEN1.
vc_static_shell>remove_generated_clocks GEN1
The following example removes all generated clocks from current design.
vc_static_shell>remove_generated_clocks -all

report_mode
Description
This command defines active/inactive modes of dbcell instances.This
command reports which cells have modes and for each mode the current
status and condition causing current status. Also, the report reflects the
mode specifications of set_mode command and set_case_analysis.

Syntax
report_mode
-instance_objects

Arguments
 -instance_objects: Use this option to specify a list of dbcell instances.
Also, it specifies that the mode report is to include only the specified list
of cell instances. By default, all cell instances that have nodes are
reported.

962
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

report_names
Description
This command reports potential name changes of ports, cells, and nets in a
design.

Syntax
report_names
[-hierarchy]
[-rules <name_rules>]

Arguments
 [-hierarchy]: Use this option to apply change_names to the hierarchy.
 [-rules <name_rules>]: Use this option to specify rules to be used for
report_names.

report_properties
Description
This command reports properties for selected object.

Syntax
report_properties
[-instance <instance>]
[-port <port>]
[-pin <pin>]
[-net <net>]

Arguments
 [-instance <instance>]: Use this option to specify design instance
name.

963
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-port <port>]: Use this option to specify design port name.


 [-pin <pin>]: Use this option to specify design pin name.
 [-net <net>]: Use this option to specify design net name.

report_read
Description
This command reports the messages issued in reading the design. This
command is used to dump the messages issued in design load. The
command report_read (–family hdl) will work on the messages issued
during VCS flow, such as parsing, design resolution, and hardware
inference.

Syntax
report_read
[-family <{design_read_family_list}>]
[-list]
[-verbose]
[-no_summary]
[-tag_type <builtin | vcst | legacy>]

Arguments
 [-family <{design_read_family_list}>]: Use this option to provide
a list of allowable family: Values: all, hdl, netlist, sdc, upf.
 [-list]: Use this option to list all messages in simple form.
 [-verbose]: Use this option to display short description for each
message.
 [-no_summary]: Use this option to suppress summary information.
 [-tag_type <builtin | vcst | legacy>]: Use this option to specify
the tag naming convention: Values: builtin, legacy, vcst.

report_read_violations

964
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Description
Use this command to get reports of the design read, upf parsing, sdc read,
and Tcl command violations which were identified. By default, it writes a
summary of the messages. The -verbose option is required to write the
details of each message. By default, only the first 100 messages of each
tag are printed. To print more, use the -limit flag.

Syntax
report_read_violations
[-no_summary]
[-list]
[-verbose]
[-limit <count>]
[-include_waived]
[-only_waived]
[-all_tags]
[-tag <list of tag names>]
[-waived <list of waiver names>]
[-id <list of message identifiers>]
[-family <list of family name>]
[-severity <list of message severities>]
[-filter <expression>]
[-regexp]
[-nocase]
[-file <file name>]
[-append]
[-include_viol_state { list of violation states } ]
[-viol_state { list of violation states } ]
[-ignore_viol_state { list of violation states }]
[-add_markers]

965
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

[-display_severity]
[-tag_format]

Arguments
 [-no_summary]: Suppresses the two summary tables which list the
number of violations in each family and stage.
 [-list]: In addition to the summary tables, print a one sentence
description of each violation with the design data fields filled in. Useful
for generating a file with one line per violation.
 [-verbose]: In addition to the summary tables, print a number of lines
of detail about each violation. This verbose format includes the
description, basic design detail fields for the violation, and also detailed
debugging fields for the violation. Useful for getting all details of the
violation.
 [-limit <count>]: When used with list or verbose mode, print only
this number of violations for each tag. Useful to limit the file size for
designs with a large violation count.
 [-include_waived]: By default, any violation which is waived is not
included in the report. Use this switch to include the waived messages in
the report.
 [-only_waived]: By default, any violation which is waived is not
included in the report. Use this switch to invert the display so that only
waived messages are included in the report.
 [-all_tags]: Included all the tags checked for in the report.
 [-tag <list of tag names>]: To focus on only certain tags, use this
switch with a list of tag names. Only violations whose tag is on this list
will be displayed
 [-waived <list of waiver names>]: To focus on only certain waivers,
use this switch with a list of waiver names. Only violations which are
waived by a waiver on this list will be displayed.
 [-id <list of message identifiers>]: To focus on only one
message or a short list of messages, use this switch with a list of
message identifiers such as SDC:123, UPF:23. Only these violations will
be displayed.

966
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 [-family <list of family name>]: To focus on only messages from


certain families, use this switch with a list of families. The valid families
are: all, design, sdc, upf.
 [-severity <list of message severities>]: To focus on only
messages with a certain severity, use this switch with a list of severities.
The valid severities are: error, info, warning.
 [-filter <expression>]: This switch allows you to specify complex
criteria based on pattern matching. Only violations matching the filter
expression will be shown. An expression may contain several terms
separated with a double ampersand. Each term has a field name, a
comparison operator, and a target string. The field name may be any
field name shown in the verbose report; for a field inside a record, use a
colon to separate the record path components. The comparison operator
is any of the standard operators such as == != =~. See the examples
section for several examples.
 [-regexp]: Use this switch to indicate that the filter expression type is a
regular expression. The default is glob-style.
 [-nocase]: Use this switch to indicate that the filter expression ignoring
the case when matching string values.
 [-file <file name>]: Writes the results to the designated file.
 [-append]: Appends results to the designated file.
 [-include_viol_state {list of violation states}]: Includes
violations for given states. Possible states are: Acknowledged,
NeedsInfo, Open, Waived, Waived_Temp, and Ignore.
 [-viol_state { list of violation states}]: Shows violations for
given states. Possible states are: Acknowledged, NeedsInfo, Open,
Waived, Waived_Temp, and Ignore.
 [-ignore_viol_state {list of violation states}]: Ignores
violation state(s) in report. Possible states are: Acknowledged,
NeedsInfo, Open, Waived, Waived_Temp, and Ignore.
 [-add_markers]: Specify this option to display BEGIN_APPNAME:X,
END_APPNAME:X markers in verbose mode.
 [-display_severity]: Generates severity info for each record in
verbose mode.

967
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

 [-tag_format]: Generates report using tag specific format. Tag-wise


custom report format can be get/set by the get_tag_attribute/
set_tag_attribute command.

report_session_data
Description
This command displays session-specific information for the current and
restored runtime database.Upon completion, this command returns 1 for
success, 0 otherwise.

Syntax
report_session_data
[-commands]

Arguments
 [-commands]: Use this option to display the log file generated during the
saved session.

report_tag
Description
This command prints a report about a set of tags. For example, to get a
report of all the isolation tags and information about them, use:
vc_static_shell> report_tag -family isolation
The command has several arguments to control the set of tags which are
printed, and also allows control over which attributes are printed. If
requested, the report can be printed in "comma separated value" format
for easy import into a spreadsheet.

Syntax
report_tag
[-app <app>]

968
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

[-severity <severity>]
[-tag <pattern>]
[-stage <pattern>]
[-family <pattern>]
[-enabled]
[-disabled]
[-builtin]
[-user]
[-csv]
[-order <attributes>]

Arguments
 [-app <app>]: Use this option to specify application name.
 [-severity <severity>]: Use this option to print only tags with this
severity.
 [-tag <pattern>]: Use this option to print only tags with name
matching pattern.
 [-stage <pattern>]: Use this option to print only tags with stage
matching pattern.
 [-family <pattern>]: Use this option to print only tags with family
matching pattern.
 [-enabled]: Use this option to print only enabled tags.
 [-disabled]: Use this option to print only disabled tags.
 [-builtin]: Use this option to print only builtin tags.
 [-user]: Use this option to print only user defined tags.
 [-csv]: Use this option to print in "comma separated value" format.
 [-order <attributes>]: Use this option to specify Tcl list of attributes
in desired print order.

Examples
Report all the tags, and all the information about them to file tag.txt

969
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

report_tag > tag.txt


Report all the disabled, built-in tags
report_tag -disabled -builtin
Report only the severity attribute, followed by description, and use comma
separated value format
report_tag -csv -order {description severity}

reset_mode
Description
This command resets active modes of dbcell instances to default. This is
the default behavior when no modes are specified with the set_mode
command.

Syntax
reset_mode
-instance_objects

Arguments
 -instance_objects: Use this option to specify a list of dbcell instances.

restart_session
Description
This command restarts process from a dumped image.

Syntax
restart_session
[-session <session_name>]
[-file <file_name>]
[-force <force>]

970
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Arguments
 [-session <session_name>]: Use this option to restart the process
from the image of the given name.
 [-file <file_name>]: Use this option to execute commands from this
file once restart is complete.
 [-force <force>]: Usually, restart requires that the kernel version of
the checkpoint machine and the kernel version of the restart machine
should be the same. In case the kernel is different, the memory image
may be incompatible and may lead to instability or unexpected results.
Use this switch to force restart on an incompatible kernel anyway.

set_case_analysis
Description
This command is used to specify a logic value (treat it as temporary
constant) on pins or ports. This command performs analysis assuming this
constant value at this port/pin. You can use case analysis settings to place
the design into a given operating mode without altering the netlist. Then
these values are propagated based on the requirements of applications.
You can use remove_case_analysis to remove added case values.

Syntax
set_case_analysis
-value
-object_list

Arguments
 -value: Use this option to specify a constant value to be set. Either 1 or
0.
 -object_list: Use this option to specify a list of port/pin/net objects.

Examples
The following command sets the IN1 port to constant logic 0.

971
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

set_case_analysis 0 IN1

set_abstract_model
Description
Associates abstract block model in the top level.

Syntax
set_abstract_model
[-app <application name>]
[-module <module_name>]
[-path <unix_dir_name>]
[-modules_list <module_name>]
[-user_mode <mode_name>]
[-instances <inst_name_list>]
[-enable_auto_abstraction]

Arguments
 [-app <application name>]: Specifies the application which SAM flow
will be invoked. Applications that are supported lp, cdc, rdc, lint. If not
specified, non-lp flow will be used.
 [-module <module_name>]: Use this option to specify module name.
 [-path <unix_dir_name>]: Use this option to block abstract path.
 [-modules_list <module_name>]: Specify the module name list to be
abstracted in VCLP SAM flow. This argument is only valid when '-app' is
set to 'lp'.
 [-user_mode <mode_name>]: Use this option to pick up mode specific
abstract module.
 [-instances <inst_name_list>]: Use this option to specify instance
name list.
 [-enable_auto_abstraction]: Use this option to enable auto
abstraction of parameterized module instances.

972
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

Examples
To link abstract model for the block module from the abstraction path,
use the following command:
set_abstract_model -path abstraction -module block
To link abstract model for the Block module from the abstraction path for
the mode1 mode, use the following command:
set_abstract_model -path abstraction -module Block -user_mode
mode1

waive_read
Description
Provides ability to waive based on Tags, Family, Severity, Filter rules using
debug fields, Wildcards and expressions and add comment for waivers as
well.
NOTE: Use waive_read command before report_read_violations command.

Syntax
waive_read
[-add <name>]
[-append <name>]
[-comment <comment>]
[-delete <name(s)>]
[-delete_all]
[-tcl]
[-force]
[-tag <tag>]
[-id <tag>]
[-stage <stage>]
[-family <family>]
[-severity <list>]

973
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Common Commands

[-filter <expression>]
[-regexp]
[-nocase]
[-not_applied]
[-ignore]
[-msg <violation message>]
[-preview]
[-include_master_viol]
[-include_compressed_viol]
[-ip ip_module_name(s)]

Arguments
 [-add <name>]: Add waiver
 [-append <name>]: Append additional filter parameters to an existing
waiver
 [-comment <comment>]: Waiver Comment.
 [-delete <name(s)>]: Delete waiver
 [-delete_all]: Delete all waivers
 [-tcl]: Display the waiver list in TCL command format
 [-force]: Create a container for waive_read append operations.
 [-tag <tag>]: Waive violations based on tag
 [-id <tag>]: Waive violations based on IDs
 [-stage <stage>]: Waive violations based on stage: Values: design,
pg, upf
 [-family <family>]: Waive violations based on family: Values: all,
sdc, upf, design
 [-severity <list>]: Waive violations based on severity: Values: all,
error, info, warning
 [-filter <expression>]: Waive violations based on expression
 [-regexp]: Indicates filter expression type to be regular expression
(default glob-style).

974
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Common Commands

 [-nocase]: Filter expressions ignore case when matching string value.


 [-not_applied]: Displays the waivers that do not apply.
 [-ignore]: Applies the waiver but does not show in the waiver report.
 [-msg <violation message>]: Waives violations based on the message
pattern. Message pattern will be matched with violation message
generated by using report_read_violations -list.
 [-preview]: If this option is set, waivers are not added to the database
and matching violation ids are set as command output.
 [-include_master_viol]: Master violation will be marked if the
compressed violations are already marked.
 [-include_compressed_viol]: If the master violation is marked, the
compressed violations are also marked.
 [-ip ip_module_name(s)]: Waives violations based on the module
inside which it lies.

Examples
The following example shows some usage of waive_read command
vc_static_shell> waive_read -family upf -add waiver1 -comment
{ask hemang} -tag SM*

975
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Command Sanity Checks

Command Sanity Checks


This section describes the VC SpyGlass sanity checks on CDC Tcl
commands.
VC SpyGlass CDC provides the following tags that report sanity errors in
the Tcl commands. Use the report_read_violations command to report the
violations of these tags.

Errors Generated by Tcl Commands


VC SpyGlass reports error generated by Tcl commands in the session.log
file as well as the GUI.
For example, if you have specified a pattern in the get_cells command
and VC SpyGlass cannot find the corresponding cell in the design, it reports
the following DB_QUERY_PATTERN_NO_MATCH violation in the session log
as well as the GUI:
get_cells Cell*
case1.tcl:40: [Warning] DB_QUERY_PATTERN_NO_MATCH:
No matching cell to the given pattern 'Cell*'

976
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Command Sanity Checks

TCL_COMMAND_INVALID

Severity
Error

Short Help
Reports invalid values of Tcl commands

Description
Reports invalid values specified with a Tcl command argument. In this case,
VC SpyGlass CDC ignores the specified command. The tag reports the
following message:
Value <OptionValue> specified for option <OptionName> of
<CommandName> command is invalid. Command is ignored. [Reason:
<Reason>.].

Example
Consider the following specification:
set_constraints_scope -module M1
In this case, the TCL_COMMAND_INVALID reports a violation if the M1
module does not exist in the design.

What Next
Review the invalid value of the argument and specify the correct value.

977
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Command Sanity Checks

TCL_PREREQUISITE_COMMAND_NOT_FOUND

Severity
Error

Short Help
Reports if pre-requisite commands do not exist

Description
Reports a violation if any mandatory pre-requisite command for the
specified command does not exist. In this case, VC SpyGlass CDC ignores
the specified command. The tag reports the following message:
Prerequisite command(s) <CommandName> does not exist for
command <CommandName>. Command is ignored.

Example
Consider the following specification:
define_attribute -name ATTR1
In this case, the set_constraints_scope command, which is a pre-
requisite for the define_attribute command, is not specified. Therefore,
the TCL_PREREQUISITE_COMMAND_NOT_FOUND tag reports a violation
because the pre-requisite command is not specified.

What Next
Review the violation and ensure that the pre-requisite commands are
specified.

978
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Command Sanity Checks

TCL_COMMAND_OPTION_VALUE_INVALID

Severity
Warning

Short Help
Reports invalid values specified with an argument of a Tcl command

Description
This tag reports a violation if a value specified with an argument of a Tcl
command is invalid. In this case, VC SpyGlass considers only the other
valid values and ignores the invalid value.
The tag reports the following message:
Value <s> specified for option <s> of command <s> is invalid.
Option is ignored. [Reason: <Reason>].

Example
Consider the following specification:
apply_attribute ATTR1 -objects { OUT_PORT_1 IN_PORT_1} -start
In this case, OUT_PORT_1 is an invalid value of the -objects argument if
the -start argument is specified in the apply_attribute command. In
this case, the TCL_COMMAND_OPTION_VALUE_INVALID tag reports a
warning and considers only the IN_PORT_1 value and ignores the
OUT_PORT_1 value.

What Next
Review the invalid value of the argument and specify the correct value.

979
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Command Sanity Checks

TCL_OBJECT_NOT_FOUND

Severity
Error

Short Help
Reports invalid objects specified in Tcl commands

Description
Reports invalid objects specified with a Tcl command argument. In this
case, VC SpyGlass CDC ignores the specified command. The tag reports
the following message:
No matching object found for <object-name> in <OptionName>
option of <CommandName> command

Example
Consider the following specification:
configure_unconstrained_ports -module M1
In this case, the TCL_OBJECT_NOT_FOUND reports a violation if the M1
module does not exist in the design.

What Next
Review the invalid value of the argument and specify the correct value.

980
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Command Sanity Checks

TCL_COMMAND_CONFLICTING

Severity
Error

Short Help
Reports conflicting Tcl commands

Description
Reports a violation if conflicting commands are specified. In this case, VC
SpyGlass CDC ignores the command that is specified later. The tag reports
the following message:
Command <CommandName2> conflicts with command <CommandName1>.
Command is ignored

Example
Consider the following specifications:
set_constraints_scope -module M1
define_attribute -name ATTR1
set_connectivity_attribute ATTR1 -related_ports {P1}
set_clock_attribute ATTR1 -clock_objects {C1}
end_constraints_scope
In this case, the TCL_COMMAND_CONFLICTING tag reports a violation
because both the set_connectivity_attribute and the
set_clock_attribute commands are specified with the same attribute
name and in the same scope. Therefore, the set_clock_attribute
command is ignored.

What Next
Review and correct the conflicting commands.

981
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Command Sanity Checks

CMD_NOT_ALLOWED_IN_RESTORE

Severity
Error

Short Help
Reports commands that cannot be specified in the restore run.

Description
Reports a violation if a command that cannot be used in the restore run is
specified. The tag reports the following message:
"Command <CommandName> cannot be specified in restore_session
mode.

Example
Consider the following specifications:
save.tcl:
check_cdc
save_session -session block

restore.tcl:
restore_session -session block
create_cdc_abstract_model
In this case, the create_cdc_abstract_model command is specified after
the restore_session command and therefore the tag reports the following
violation in this case:
[Error] CMD_NOT_ALLOWED_IN_RESTORE: Command
'create_cdc_abstract_model' cannot be specified in
restore_session mode.

What Next
Review and remove the disallowed commands.

982
Synopsys, Inc. Feedback
Appendix A - Supported Commands

Command Sanity Checks

983
Feedback Synopsys, Inc.
Appendix A - Supported Commands

Command Sanity Checks

984
Synopsys, Inc. Feedback

You might also like