Meridian CDC

Meridian CDC
2016.A
© 1998-2016 Real Intent, Inc. All rights reserved.
Table of Contents
License Agreement ..............................................................................................................................18
Getting Started .....................................................................................................................................19
Supported Platforms ......................................................................................................................20
Software Installation .......................................................................................................................21
License Installation .........................................................................................................................28
Customer Support ..........................................................................................................................30
Release Notes ......................................................................................................................................31
Meridian CDC 2016.A ....................................................................................................................32
Meridian CDC 2015.A ....................................................................................................................34
Meridian CDC 2015.A.P1 ........................................................................................................40
Meridian CDC 2015.A.P2 ........................................................................................................41
Meridian CDC 2015.A.P3 ........................................................................................................43
Meridian CDC 2015.A.P4 ........................................................................................................44
Meridian CDC 2015.A.P5 ........................................................................................................45
Meridian CDC 2015.A.P6 ........................................................................................................47
Meridian CDC User Guide ...................................................................................................................49
Meridian CDC Invocation ...............................................................................................................51
Meridian CDC Verification Flow .....................................................................................................52
Meridian CDC Usage Models ........................................................................................................56
Full Design CDC Verification Flow ..........................................................................................57
Bottom-Up Hierarchical (BUH) CDC Verification Flow ............................................................63
Meridian CDC Verification Policies ................................................................................................69
SDC_ENV_LINT .......................................................................................................................70
MCDC_SETUP_CHECKS ........................................................................................................71
MCDC_ANALYSIS_CHECKS ..................................................................................................72
Meridian CDC Formal Verification .................................................................................................73
Full Formal Analysis ................................................................................................................75
Gray Code Check ..............................................................................................................78
Data Stability Check ..........................................................................................................80
Formal Glitch Check ..........................................................................................................82
Pulse Width Check ............................................................................................................83
Frequency-Independent Formal Analysis ..........................................................................84
Local Formal Analysis ..............................................................................................................85
Meridian CDC Debugger ...............................................................................................................87
Converting SDC Commands to ENV Commands .........................................................................88
create_clock Conversion ..........................................................................................................89
create_generated_clock Conversion ........................................................................................91
set_case_analysis Conversion .................................................................................................93
set_input_delay Conversion .....................................................................................................94
set_output_delay Conversion ...................................................................................................96
set_false_path and set_clock_groups Conversion ..................................................................97
Recommended Order of Review ...................................................................................................98
Command Reference ...........................................................................................................................99
DESIGN Compilation Commands ................................................................................................100
http://www.realintent.com | [email protected] | +1-408-830-9336

analyze ...................................................................................................................................102
Language Support............................................................................................................108
Verilog/SystemVerilog Support ...................................................................................109
VHDL Support ............................................................................................................111
Mixed Language Support ...........................................................................................113
SVA Assertions ..........................................................................................................114
PSL Assertions...........................................................................................................117
Attribute and Pragma Support .........................................................................................124
ENV File Pragmas .....................................................................................................125
ri_set_stable_value...............................................................................................126
sync_set_reset .....................................................................................................127
Synthesis Pragmas ....................................................................................................128
translate on/translate off ......................................................................................129
synthesis off/synthesis on ....................................................................................130
read_comments_as_HDL on/read_comments_as_HDL off.................................131
parallel_case ........................................................................................................132
full_case ...............................................................................................................133
Special Handling of RTL ..................................................................................................134
RAMs and Big Arrays ................................................................................................135
Identification of RAMs ..........................................................................................136
Identification of Big Arrays ...................................................................................139
Loop Handling ............................................................................................................140
Nonsynthesizable Constructs.....................................................................................141
Arithmetic Operators ..................................................................................................142
Hard Macros...............................................................................................................143
Encrypted Modules ....................................................................................................144
Analog Blocks ............................................................................................................145
Simulation Models ......................................................................................................146
elaborate .................................................................................................................................147
Configuring a VHDL Top Entity via Generics ..................................................................150
Configuring a Verilog Module via Parameters .................................................................151
Handling Missing RTL Files using Blackboxing ...............................................................152
Resolving Verilog Modules ..............................................................................................153
Resolving VHDL Modules ................................................................................................154
Understanding VHDL Blackboxing...................................................................................155
Compiling the Design for Verdi ........................................................................................158
Design Compilation Summary .........................................................................................159
read_design_db ......................................................................................................................161
read_liberty .............................................................................................................................163
Liberty Functional Model ..................................................................................................165
Liberty Timing Model........................................................................................................169
Output Timing .............................................................................................................170
Input Timing................................................................................................................171
read_library_map....................................................................................................................172
CDC Commands ..........................................................................................................................173

create_association..................................................................................................................174
exclude_cntl_from_recon .......................................................................................................177
read_cdc_db ...........................................................................................................................179
remove_association................................................................................................................181
report_cdc_db.........................................................................................................................183
set_cntl_association_depth ....................................................................................................185
set_glitch_free_inputs.............................................................................................................188
set_max_search_depth ..........................................................................................................190
set_mutex_signals ..................................................................................................................194
set_shell_instances ................................................................................................................197
set_synchronizer_depth .........................................................................................................199
set_user_associated_cells .....................................................................................................201
set_user_cntl_synchronizer ....................................................................................................203
set_user_reset_synchronizer .................................................................................................205
set_user_specified_cells ........................................................................................................206
set_waveform_map ................................................................................................................207
user_defined_cntl_signals ......................................................................................................208
user_defined_data_signals.....................................................................................................210
verify_cdc ...............................................................................................................................217
verify_cdc_formal ...................................................................................................................219
write_scripts ............................................................................................................................229
ENV File Commands ...................................................................................................................231
create_clock ...........................................................................................................................233
create_derived_waveform ......................................................................................................235
create_input ............................................................................................................................239
create_output ..........................................................................................................................242
create_reset ............................................................................................................................245
create_waveform ....................................................................................................................247
set_async_waveforms ............................................................................................................250
set_constant ...........................................................................................................................252
set_data_clock_domain ..........................................................................................................254
set_initial_state .......................................................................................................................256
set_initial_value ......................................................................................................................258
set_stable_value.....................................................................................................................260
set_value_during_reset ..........................................................................................................262
GENERAL Commands .................................................................................................................264
check_command_exists .........................................................................................................265
create_rule_group ..................................................................................................................267
create_rule_instance ..............................................................................................................269
create_rule_policy ..................................................................................................................271
create_severity .......................................................................................................................273
create_status ..........................................................................................................................275
create_view_criteria................................................................................................................277
define_proc_attributes ............................................................................................................280
delete_view_criteria ................................................................................................................281

exit ..........................................................................................................................................282
export_associations ................................................................................................................283
export_reclassifications ..........................................................................................................284
export_rule_status ..................................................................................................................285
export_view_criteria................................................................................................................287
get_project ..............................................................................................................................288
get_signals .............................................................................................................................289
help .........................................................................................................................................290
import_status ..........................................................................................................................292
list_asserts ..............................................................................................................................293
list_assumes ...........................................................................................................................295
list_attributes ..........................................................................................................................296
list_categories .........................................................................................................................297
list_ports .................................................................................................................................298
parse_proc_arguments...........................................................................................................300
promote_rule_status ...............................................................................................................301
promote_rule_status_from_file ...............................................................................................303
report_messages ....................................................................................................................305
report_policy ...........................................................................................................................309
set_project ..............................................................................................................................312
set_rule_status .......................................................................................................................313
set_run_formal........................................................................................................................315
unset_run_formal....................................................................................................................317
update_view_criteria_details ..................................................................................................319
INTENT Analysis Commands ......................................................................................................320
analyze_intent ........................................................................................................................321
create_scenario ......................................................................................................................324
read_env .................................................................................................................................325
read_sdc .................................................................................................................................329
report_env ..............................................................................................................................333
report_sdc ...............................................................................................................................335
-output_env .............................................................................................................................341
RIDB Commands .........................................................................................................................343
RIDB Access Commands ......................................................................................................344
current_scenario ...............................................................................................................345
get_all_instances ..............................................................................................................346
get_all_modules ...............................................................................................................347
get_rule_contents .............................................................................................................349
get_rule_data....................................................................................................................351
get_rule_groups................................................................................................................353
get_rule_instances ...........................................................................................................355
get_rule_policies...............................................................................................................357
get_rules ...........................................................................................................................359
get_run_names.................................................................................................................361
get_scenarios ...................................................................................................................364

get_view_criteria...............................................................................................................365
RIDB Metadata Customization Commands ...........................................................................366
attach_view_criteria ..........................................................................................................367
set_rule_group_is_factory ................................................................................................368
set_rule_instance_is_factory ............................................................................................369
set_rule_policy_default_flag .............................................................................................370
set_rule_policy_is_factory ................................................................................................371
set_rule_policy_order .......................................................................................................372
set_status_is_default ........................................................................................................373
set_status_is_factory ........................................................................................................374
set_view_criteria_is_factory .............................................................................................375
unset_rule_policy_is_factory ............................................................................................376
unset_rule_policy_tool ......................................................................................................377
unset_status_tool .............................................................................................................378
SDC Commands ..........................................................................................................................379
Collection Commands ............................................................................................................380
add_to_collection..............................................................................................................381
append_to_collection........................................................................................................383
collection_contains ...........................................................................................................385
compare_collections .........................................................................................................387
copy_collection .................................................................................................................389
filter_collection ..................................................................................................................392
foreach_in_collection ........................................................................................................394
index_collection ................................................................................................................396
remove_from_collection ...................................................................................................398
sizeof_collection ...............................................................................................................400
sort_collection...................................................................................................................401
General Purpose Commands ................................................................................................403
current_instance ...............................................................................................................404
set_hierarchy_separator ...................................................................................................405
set_units ...........................................................................................................................406
Object Access Commands ....................................................................................................408
all_clocks ..........................................................................................................................411
all_connected ...................................................................................................................413
all_fanin ............................................................................................................................415
all_fanout ..........................................................................................................................418
all_inputs ..........................................................................................................................422
all_instances .....................................................................................................................424
all_outputs ........................................................................................................................426
all_registers ......................................................................................................................428
current_design ..................................................................................................................432
get_attribute......................................................................................................................434
get_cells ...........................................................................................................................437
get_clocks.........................................................................................................................440
get_designs ......................................................................................................................442

get_libs .............................................................................................................................445
get_lib_cells ......................................................................................................................448
get_lib_pins ......................................................................................................................451
get_lib_timing_arcs...........................................................................................................454
get_object_name ..............................................................................................................457
get_pins ............................................................................................................................459
get_ports ...........................................................................................................................463
get_nets ............................................................................................................................466
get_timing_arcs ................................................................................................................469
query_objects ...................................................................................................................472
set_attribute ......................................................................................................................474
Timing Constraints Commands ..............................................................................................476
create_clock .....................................................................................................................477
create_generated_clock ...................................................................................................480
group_path .......................................................................................................................484
set_clock_gating_check ...................................................................................................488
set_clock_groups..............................................................................................................490
set_clock_latency .............................................................................................................493
set_clock_sense ...............................................................................................................495
set_clock_uncertainty .......................................................................................................497
set_data_check ................................................................................................................500
set_disable_timing ............................................................................................................502
set_false_path ..................................................................................................................504
set_ideal_latency ..............................................................................................................508
set_ideal_network.............................................................................................................510
set_ideal_transition...........................................................................................................512
set_input_delay ................................................................................................................514
set_max_delay .................................................................................................................517
set_max_time_borrow ......................................................................................................520
set_min_delay ..................................................................................................................522
set_min_pulse_width ........................................................................................................525
set_multicycle_path ..........................................................................................................527
set_output_delay ..............................................................................................................531
set_propagated_clock ......................................................................................................534
Environment Commands ........................................................................................................536
set_case_analysis ............................................................................................................537
set_drive ...........................................................................................................................539
set_driving_cell .................................................................................................................541
set_fanout_load ................................................................................................................544
set_input_transition ..........................................................................................................545
set_load ............................................................................................................................547
set_logic_dc......................................................................................................................549
set_logic_one ...................................................................................................................550
set_logic_zero ..................................................................................................................551
set_max_area ...................................................................................................................552

set_max_capacitance .......................................................................................................553
set_max_fanout ................................................................................................................555
set_max_transition ...........................................................................................................556
set_min_capacitance ........................................................................................................558
set_operating_conditions..................................................................................................559
set_resistance ..................................................................................................................561
set_timing_derate .............................................................................................................563
set_voltage .......................................................................................................................566
set_wire_load_selection_group ........................................................................................568
set_wire_load_model........................................................................................................570
set_wire_load_mode ........................................................................................................572
set_wire_load_min_block_size .........................................................................................573
set_port_fanout_number ..................................................................................................574
Multi-Voltage and Power Commands ....................................................................................575
create_voltage_area .........................................................................................................576
set_level_shifter_strategy .................................................................................................578
set_level_shifter_threshold ...............................................................................................579
set_max_dynamic_power .................................................................................................580
set_max_leakage_power..................................................................................................581
Real Intent Database .........................................................................................................................582
RIDB Terminology ........................................................................................................................583
Design Objects .............................................................................................................................585
Design Attributes ....................................................................................................................588
Cell Attributes .........................................................................................................................589
Pin Attributes ..........................................................................................................................591
Net Attributes .........................................................................................................................593
Port Attributes ........................................................................................................................594
Timing Arc Attributes..............................................................................................................596
Clock Attributes ......................................................................................................................597
Library Attributes ....................................................................................................................598
Library Cell Attributes ............................................................................................................600
Library Pin Attributes .............................................................................................................602
Library Timing Arc Attributes .................................................................................................604
Rule Policy Objects ......................................................................................................................606
Rule Policy Attributes .............................................................................................................609
Rule Group Attributes ............................................................................................................610
Rule Instance Attributes .........................................................................................................612
Rule Attributes ........................................................................................................................614
Rule Data Attributes ...............................................................................................................615
Rule Content Attributes ..........................................................................................................617
Rule Reference ..................................................................................................................................618
SDC/ENV Lint Checks .................................................................................................................619
EMPTY_COLL ........................................................................................................................620
INCONSISTENT_MSTR_GEN_CLKS_SRC ..........................................................................621
INVALID_ARG_USAGE .........................................................................................................623

INVALID_SYNTAX ..................................................................................................................624
MISSING_ARG .......................................................................................................................625
NON_GEN_CLK_IN_FANOUT...............................................................................................626
REF_CLK_NOT_IN_NETWORK ............................................................................................627
UNMATCHED_PATTERN.......................................................................................................629
INTENT (Setup) Checks ..............................................................................................................631
BLACK_BOX ..........................................................................................................................632
I_CLK_DOMAINS ...................................................................................................................634
I_CLK_TREES ........................................................................................................................635
I_CONSTANT .........................................................................................................................636
I_HENV_DB_MAP ..................................................................................................................637
I_HENV_WAVE_MAP.............................................................................................................638
I_RST_SIGNAL ......................................................................................................................639
S_CLK_GATE_NO_WAVE .....................................................................................................640
S_CLK_OFF_SUB_TREE ......................................................................................................642
S_COMBO_LOOPS ...............................................................................................................644
S_CONF_ENV ........................................................................................................................645
S_GENCLK ............................................................................................................................647
S_HENV_ATTR_CONFLICT ..................................................................................................649
S_HENV_EXTRA_SPEC .......................................................................................................651
S_HENV_MISSING_SPEC ....................................................................................................652
S_HENV_TYPE_CONFLICT ..................................................................................................653
S_HENV_WAVE_CONFLICT .................................................................................................654
S_INPUT_NO_WAVE .............................................................................................................655
S_MULTCLK ...........................................................................................................................657
S_NET_NO_WAVE ................................................................................................................659
S_NOCLK ...............................................................................................................................661
S_NORST ...............................................................................................................................663
S_NUM_ANALYSIS_TIME_SLICES ......................................................................................665
S_OUTPUT_NO_WAVE .........................................................................................................666
S_RST_INV ............................................................................................................................668
S_UNINIT_FLOPS_LATCHES ...............................................................................................670
S_UNKNOWN_CLKPOL ........................................................................................................671
CDC Checks ................................................................................................................................673
CLK_GROUPS .......................................................................................................................674
CNTL ......................................................................................................................................676
DATA.......................................................................................................................................685
GRAY_CODE_CHECKS ........................................................................................................693
I_ASSUME .............................................................................................................................696
INTERFACE ...........................................................................................................................697
PULSE_SYNC ........................................................................................................................700
RST_SYNC ............................................................................................................................702
SYNC_CROSSING ................................................................................................................704
U_INTERFACE .......................................................................................................................706
W_ASYNC_RST_FLOPS .......................................................................................................707

W_BLOCKED_CROSSING ....................................................................................................709
W_CLK_RECON ....................................................................................................................711
W_CNTL .................................................................................................................................713
W_D_CLK_GLITCH ...............................................................................................................717
W_DATA .................................................................................................................................719
W_ENCAP ..............................................................................................................................723
W_FANOUT ............................................................................................................................726
W_G_CLK_GLITCH ...............................................................................................................728
W_GLITCH .............................................................................................................................734
W_HALF .................................................................................................................................738
W_INTERFACE ......................................................................................................................740
W_LOCKUP ...........................................................................................................................743
W_MASYNC ...........................................................................................................................745
W_RECON_GROUPS............................................................................................................747
W_REDUNDANT_SYNC........................................................................................................750
W_RST_HALF ........................................................................................................................752
W_RST_SPEC_CLK ..............................................................................................................753
W_RST_UNCERTAINTY ........................................................................................................755
Variable Reference .............................................................................................................................758
design_configuration ....................................................................................................................760
ri_allow_plus_in_incdir ...........................................................................................................761
ri_assoc_as_fixed_array.........................................................................................................762
ri_assoc_as_fixed_array_of_size ...........................................................................................763
ri_auto_get_lib ........................................................................................................................764
ri_cadence_compatible...........................................................................................................765
ri_count_rtl_only_flops_and_latches_in_design_stats ...........................................................766
ri_dash_v_is_lib_cell ..............................................................................................................767
ri_ignore_pragma_vendors.....................................................................................................768
ri_ignore_vs_files....................................................................................................................769
ri_incdef_accumulate..............................................................................................................770
ri_match_nc ............................................................................................................................771
ri_match_vcs ..........................................................................................................................772
ri_max_exceeded_stops_elab ................................................................................................773
ri_max_loop_unroll .................................................................................................................774
ri_max_single_range_bits.......................................................................................................775
ri_max_total_range_bits .........................................................................................................776
ri_preserve_paths_in_auto_bboxed_insts ..............................................................................777
ri_quick_FE_run .....................................................................................................................778
ri_ram_max_reset_count ........................................................................................................779
ri_ram_max_word_size ..........................................................................................................780
ri_ram_min_size .....................................................................................................................781
ri_ram_min_words ..................................................................................................................782
ri_report_inferred_flops_in_log ...............................................................................................783
ri_report_inferred_latches_in_log ...........................................................................................784
ri_search_path ........................................................................................................................785

ri_synth_models_internal_dirs ................................................................................................786
ri_synth_models_user_dirs.....................................................................................................787
ri_vhdl_allowed_logic_types ...................................................................................................788
ri_vhdl_map_work_to_target_library ......................................................................................789
ri_vhdl_preserve_case ...........................................................................................................790
ri_vhdl_require_ordered_analyze ...........................................................................................791
ri_vhdl_std_logic_dash_is_x...................................................................................................792
ri_vy_lib_accumulate ..............................................................................................................793
cdc_configuration .........................................................................................................................794
ri_allow_flop_driven_clk_gate ................................................................................................795
ri_allow_ram_pin_driver_for_cntl............................................................................................796
ri_assume_primary_inputs_have_glitch_potential .................................................................797
ri_check_cntl_depth_mismatch ..............................................................................................798
ri_check_cntl_type_mismatch ................................................................................................799
ri_check_missing_feedback ...................................................................................................800
ri_detect_masync_on_outputs................................................................................................801
ri_detect_missing_sync_reset ................................................................................................802
ri_effort_level_for_data_control_condition..............................................................................803
ri_exclude_association_through_clock_gate ..........................................................................804
ri_exclude_clock_path_from_recon ........................................................................................805
ri_exclude_cntl_masync_from_w_glitch .................................................................................806
ri_fill_info_column_for_rs........................................................................................................807
ri_fill_info_column_for_warfs ..................................................................................................808
ri_group_data_rx_in_interface ................................................................................................809
ri_identify_controlled_propagation..........................................................................................810
ri_identify_data_control_condition ..........................................................................................811
ri_identify_sync_path_blocking...............................................................................................812
ri_ignore_w_fanout_with_no_recon........................................................................................813
ri_max_glitch_driver_count.....................................................................................................814
ri_max_num_vcd_files ............................................................................................................815
ri_min_synchronizer_depth_3_domains .................................................................................816
ri_on_the_fly_shell_write_debug ............................................................................................820
ri_reclass_max_sync_depth_to_data .....................................................................................821
ri_report_all_signals_in_i_constant ........................................................................................822
ri_report_all_unregistered_outputs_in_w_encap ...................................................................823
ri_report_all_w_blocked_crossing ..........................................................................................824
ri_report_all_w_fanout_points ................................................................................................825
ri_report_all_w_recon_points .................................................................................................826
ri_report_clk_glitch_dbg_files .................................................................................................827
ri_report_clk_groups ...............................................................................................................828
ri_report_crossing_rx_net_as_recon_point ............................................................................829
ri_report_dbg_file_for_each_driver.........................................................................................830

ri_report_dbg_files_for_rs.......................................................................................................831
ri_report_dbg_files_for_warfs .................................................................................................832
ri_report_dbg_files ..................................................................................................................833
ri_report_err_feedback ...........................................................................................................834
ri_report_glitch_on_all_data ...................................................................................................835
ri_report_i_assume .................................................................................................................836
ri_report_i_constant ................................................................................................................837
ri_report_i_encap....................................................................................................................838
ri_report_i_henv_wave_map ..................................................................................................839
ri_report_interface ..................................................................................................................840
ri_report_masync_dbg_files ...................................................................................................841
ri_report_missing_fbs_as_w_interface ...................................................................................842
ri_report_none_as_w_cntl ......................................................................................................843
ri_report_number_of_drivers_for_cntl ....................................................................................844
ri_report_number_of_drivers_for_data ...................................................................................845
ri_report_number_of_drivers_for_w_data ..............................................................................846
ri_report_potential_static_as_w_cntl ......................................................................................847
ri_report_pulse_sync ..............................................................................................................848
ri_report_recon_dbg_files .......................................................................................................849
ri_report_reset_syncs_with_func_cdc_as_warf .....................................................................850
ri_report_rst_sync ...................................................................................................................851
ri_report_s_henv_attr_conflict ................................................................................................852
ri_report_s_henv_missing_spec .............................................................................................853
ri_report_s_henv_type_conflict...............................................................................................854
ri_report_s_henv_waveform_conflict ......................................................................................855
ri_report_second_stage_as_sync_out ...................................................................................856
ri_report_sync_crossing .........................................................................................................857
ri_report_u_interface ..............................................................................................................858
ri_report_w_async_rst_flops...................................................................................................859
ri_report_w_blocked_crossing ................................................................................................860
ri_report_w_clk_recon ............................................................................................................861
ri_report_w_cntl ......................................................................................................................862
ri_report_w_d_clk_glitch .........................................................................................................863
ri_report_w_data.....................................................................................................................864
ri_report_w_encap ..................................................................................................................865
ri_report_w_fanout..................................................................................................................866
ri_report_w_masync_all_drivers .............................................................................................867
ri_report_w_g_clk_glitch .........................................................................................................868
ri_report_w_g_clk_glitch_async_input ...................................................................................869
ri_report_w_g_clk_glitch_async_reset_select ........................................................................870
ri_report_w_g_clk_glitch_bad_polarity ...................................................................................871
ri_report_w_g_clk_glitch_gate_config ....................................................................................872
ri_report_w_g_clk_glitch_missing_spec .................................................................................873
ri_report_w_g_clk_glitch_sync_reset_select ..........................................................................874
ri_report_w_glitch ...................................................................................................................875

ri_report_w_half ......................................................................................................................876
ri_report_w_interface ..............................................................................................................877
ri_report_w_lockup .................................................................................................................878
ri_report_w_masync ...............................................................................................................879
ri_report_w_recon_groups......................................................................................................880
ri_report_w_recon_points .......................................................................................................881
ri_report_w_redundant_sync ..................................................................................................882
ri_report_w_rst_glitch .............................................................................................................883
ri_report_w_rst_half ................................................................................................................884
ri_report_w_rst_spec_clk........................................................................................................885
ri_report_w_rst_uncertainty ....................................................................................................886
ri_report_warn_for_all_glitches ..............................................................................................887
ri_require_env_specs_on_all_inputs ......................................................................................888
ri_require_env_specs_on_all_outputs ....................................................................................889
ri_restrict_to_definite_constants .............................................................................................890
ri_smallest_depth_recon_report .............................................................................................891
ri_split_sync_across_hier .......................................................................................................892
ri_strict_rs_detection ..............................................................................................................893
ri_strict_synchronizer_detection .............................................................................................894
ri_trace_w_fanout_paths ........................................................................................................895
ri_unique_recon_points_at_all_depths ...................................................................................896
ri_user_defined_cells_file .......................................................................................................897
ri_user_module_data ..............................................................................................................898
ri_warn_all_multi_driver_crossings ........................................................................................899
ri_warn_potential_syncs .........................................................................................................900
ri_write_scripts_multi_clock_method ......................................................................................901
ri_write_scripts_skip_module_insts_limit ...............................................................................902
formal_configuration ....................................................................................................................903
ri_assume_timing_constraints_on_cntls ................................................................................904
ri_auto_break_all_loops_for_formal .......................................................................................905
ri_cdc_metastability_model_for_data_path ............................................................................906
ri_check_assumption_only_at_failure_point ..........................................................................907
ri_constrain_mcp_checking_to_tx_clk ....................................................................................908
ri_data_stable_checks ............................................................................................................909
ri_exclude_driver_list ..............................................................................................................910
ri_flop_depth_for_cntl .............................................................................................................911
ri_flop_depth_for_cntl_glitch...................................................................................................912
ri_flop_depth_for_data............................................................................................................913
ri_flop_depth_for_gray_code ..................................................................................................914
ri_formal_mode.......................................................................................................................915
ri_generate_vcd_for_bounded_and_pass ..............................................................................916
ri_identify_strict_data_control_condition ................................................................................917
ri_ignore_all_primary_input_drivers .......................................................................................918
ri_ignore_fast_to_slow_gray_code_checks ...........................................................................919
ri_include_driver_list ...............................................................................................................920

ri_max_ratio_after_auto_normalization ..................................................................................921
ri_max_time_slices .................................................................................................................922
ri_md_formal_flow ..................................................................................................................923
ri_normalize_clk_periods ........................................................................................................925
ri_normalize_to_uniform_clk_periods .....................................................................................926
ri_process_all_pulse_width_checks .......................................................................................927
ri_pulse_width_checks ...........................................................................................................928
ri_run_vacuity_check_with_formal .........................................................................................929
ri_use_free_running_clocks....................................................................................................930
ri_verify_cntl_glitch .................................................................................................................931
ri_verify_data_stability ............................................................................................................932
ri_verify_gray_codes ..............................................................................................................933
ri_verify_gray_codes_on_all_recon ........................................................................................934
ri_verify_gray_codes_on_rx_flops ..........................................................................................935
ri_verify_one_clock_glitch_bit_per_bus .................................................................................936
ri_verify_one_cntl_bit_per_bus...............................................................................................937
ri_verify_one_data_bit_per_bus .............................................................................................938
ri_verify_pulse_widths ............................................................................................................939
ri_verify_sync_pulse_widths ...................................................................................................940
ri_xing_mcp_cycles ................................................................................................................942
global_configuration .....................................................................................................................943
ri_abs_file_name ....................................................................................................................944
ri_enforce_strict_variable_settings .........................................................................................945
ri_ignore_unused_flops_in_analysis ......................................................................................946
ri_print_intermediate_memory_stats ......................................................................................947
ri_product_build_date .............................................................................................................948
ri_product_build_time .............................................................................................................949
ri_product_name.....................................................................................................................951
ri_product_rev.........................................................................................................................952
ri_product_version ..................................................................................................................953
ri_project_directory_name ......................................................................................................954
ri_remove_unused_combo_logic............................................................................................955
ri_remove_unused_flops ........................................................................................................956
ri_remove_unused_lib_cell_flops ...........................................................................................957
ri_session_name ....................................................................................................................958
ri_suppress_msg ....................................................................................................................959
ri_use_platform_gdb ...............................................................................................................960
ri_write_zdb ............................................................................................................................961
intent_configuration ......................................................................................................................962
ri_append_to_orig_env ...........................................................................................................963
ri_check_henv_input_spec .....................................................................................................964
ri_comment_auto_detected_sync_resets ...............................................................................965
ri_convert_SDC_clocks_async ...............................................................................................966
ri_create_inputs_on_black_box_outputs ................................................................................967
ri_create_inputs_on_undriven_nets .......................................................................................968

ri_create_outputs_in_create_env ...........................................................................................969
ri_create_outputs_on_black_box_inputs ................................................................................970
ri_disable_name_based_clock_and_reset_spec_creation.....................................................971
ri_echo_sdc_commands.........................................................................................................972
ri_enhance_clock_domain_analysis_in_conf_env .................................................................973
ri_env_error_on_signal_not_found .........................................................................................974
ri_env_priority_order...............................................................................................................975
ri_exclude_all_reset_analysis.................................................................................................976
ri_exclude_internal_reset_analysis ........................................................................................977
ri_extract_genclks_filename ...................................................................................................978
ri_extract_genclks_from_liberty ..............................................................................................979
ri_ignore_unused_virtual_clocks ............................................................................................980
ri_infer_s_no_reset_from_reset_syncs ..................................................................................981
ri_oac_result_display_limit .....................................................................................................982
ri_oac_strict_type_checking ...................................................................................................983
ri_override_input_spec_for_reset_or_mode_identification.....................................................984
ri_report_black_box ................................................................................................................985
ri_report_i_clk_trees ...............................................................................................................986
ri_report_i_clk_tree_alias_names...........................................................................................987
ri_report_i_henv_db_map.......................................................................................................988
ri_report_i_reset_signal ..........................................................................................................989
ri_report_internal_s_norst.......................................................................................................990
ri_report_s_clk_gate_no_wave...............................................................................................991
ri_report_s_clk_off_sub_tree ..................................................................................................992
ri_report_s_conf_env ..............................................................................................................993
ri_report_s_genclk ..................................................................................................................994
ri_report_s_henv_extra_spec .................................................................................................995
ri_report_s_input_no_wave ....................................................................................................996
ri_report_s_multclk .................................................................................................................997
ri_report_s_multclk_max_count..............................................................................................998
ri_report_s_multclk_verbose ..................................................................................................999
ri_report_s_net_no_wave .....................................................................................................1000
ri_report_s_noclk ..................................................................................................................1001
ri_report_s_norst ..................................................................................................................1002
ri_report_s_num_analysis_time_slices ................................................................................1003
ri_report_s_output_no_wave ................................................................................................1004
ri_report_s_rst_inv ................................................................................................................1005
ri_report_s_rst_inv_verbose .................................................................................................1006
ri_report_s_unknown_clkpol .................................................................................................1007
ri_report_s_unknown_clkpol_max_count .............................................................................1008
ri_report_setup_dbg_files .....................................................................................................1009
ri_report_static_loops ...........................................................................................................1010
ri_report_uninitialized_flops_latches ....................................................................................1011
ri_sdc_echo_limit ..................................................................................................................1012
ri_sdc_error_on_cmd_failure ................................................................................................1013

ri_sdc_report_ignored_commands .......................................................................................1014
ri_sdc_uniquify_warning_numbers .......................................................................................1016
ri_sdc2env_exact_translation ...............................................................................................1017
ri_sdc2env_ignore_set_clock_groups ..................................................................................1019
ri_sdc2env_ignore_set_false_paths .....................................................................................1020
ri_sdc2env_make_all_clocks_async ....................................................................................1021
ri_synth_array_naming_style................................................................................................1022
ri_synth_design_naming_style .............................................................................................1023
ri_synth_design_parameter_style.........................................................................................1025
ri_synth_design_separator_style ..........................................................................................1026
ri_synth_interface_naming_style ..........................................................................................1028
ri_synth_record_naming_style..............................................................................................1029
ri_synth_reg_clear_pin_name ..............................................................................................1030
ri_synth_reg_clocked_on_pin_name ....................................................................................1031
ri_synth_reg_data_in_pin_name ..........................................................................................1032
ri_synth_reg_enable_pin_name ...........................................................................................1033
ri_synth_reg_naming_style...................................................................................................1034
ri_synth_reg_next_state_pin_name .....................................................................................1036
ri_synth_reg_output_inv_pin_name .....................................................................................1037
ri_synth_reg_output_pin_name ............................................................................................1038
ri_synth_reg_preset_pin_name ............................................................................................1039
ri_synth_reg_synch_clear_pin_name ...................................................................................1040
ri_synth_reg_synch_enable_pin_name ................................................................................1041
ri_synth_reg_synch_preset_pin_name ................................................................................1042
ri_synth_reg_synch_toggle_pin_name .................................................................................1044
ri_synth_vhdl_generate_naming_style .................................................................................1045
ri_synth_vhdl_generate_separator_style .............................................................................1046
ri_synth_vlog_generate_naming_style .................................................................................1047
ri_synth_vlog_generate_separator_style .............................................................................1048
ri_translate_set_output_delay ..............................................................................................1049
ri_use_exact_waveform_periods_in_sdc_to_env_translation ..............................................1050
ri_use_logically_exclusive_as_async ...................................................................................1051
ri_use_physically_exclusive_as_async ................................................................................1052
ri_use_unidir_clk2clk_sfp_as_async ....................................................................................1053
ri_write_multi_clock_waveforms ...........................................................................................1055
List of Meridian Variables and Their Default Values..................................................................1057
How-To Topics ..................................................................................................................................1065
Compiling Your Design ..............................................................................................................1066
Generating Design Specification................................................................................................1067
Understanding Formal Verification Results................................................................................1068
Global Clock Period and Number of Segments ..................................................................1069
Understanding Debug Information .............................................................................................1070
Rules That Generate Debug Information ............................................................................1071
Creating Your Own Rule Policy .................................................................................................1073
Using Scope-Based Reporting...................................................................................................1075

Viewing Rule Violations for a Particular Block ....................................................................1076

Viewing Top-Level Rule Violations.......................................................................................1079
Using Shell Models ....................................................................................................................1082
Customizing Metadata in the RIDB ...........................................................................................1083
Changing the Default Status Specifiers ...............................................................................1084
Changing the Default Rule Policies .....................................................................................1085

License Agreement
REAL INTENT LICENSE AGREEMENT & COPYRIGHT NOTICE

Copyright (c) 1998-2016 Real Intent, Inc. All rights reserved.
This software and documentation (“Product”) is copyrighted and contains material that is protected by patent,
copyright, trademark, trade secret or other laws and international treaties. The Product is provided to you
under a license agreement with Real Intent, Inc. You have the right to use the Product only in accordance with
such license agreement. No part of the Product may be reproduced, transmitted, or translated, in any form or
by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Real
Intent, Inc., or as expressly provided by the license agreement. Real Intent and its licensors reserve all other
rights, express and implied, in the Product.
Export Control
All technical data contained in this reference manual is subject to the export control laws and regulations of
the United States of America. You may not export or re-export to foreign countries, or disclose to nationals of
foreign countries, such technical data in violation of such laws and regulations. You are solely responsible for
complying with all such laws and regulations.
Real Intent's Rights

Information in this reference manual is subject to change without notice and does not represent a commitment
on the part of Real Intent. Such information is the proprietary and confidential information of Real Intent or its
licensors.
Disclaimer
Except as otherwise expressly provided in any agreement you may have with Real Intent that covers this
reference manual, Real Intent does not make, and expressly disclaims, any representations or warranties as
to the completeness, accuracy or usefulness of the information in this reference manual and does not warrant
that use of such information will not infringe upon third party rights, nor does Real Intent assume any liability
for damages or costs of any kind that may result from use of such information.
Trademarks
Real Intent, the Real Intent logo, Ascent, and Meridian are trademarks of Real Intent, Inc. Real Intent makes
no endorsement of any vendor’s products. Synopsys Design Compiler® and Verdi® are registered trademarks of
Synopsys, Inc. in the U.S. and other countries. Cadence Encounter® RTL Compiler is a registered trademark of
Cadence Design Systems, Inc. in the U.S. and other countries. All other trademarks are the exclusive property
of their respective holders.

Getting Started
This section provides the information needed to install and use your Real Intent software. It also provides information
for getting customer support.
Conventions
The conventions used within this manual are shown below.
Symbol Meaning
monospace Example code samples
italics A user-defined specification
bold Code that should be entered exactly as written
[] An optional item; if the square brackets surround several words, all must be entered as
a group; the brackets themselves are not entered as part of the item
... Items that may be entered more than once; the ellipsis itself does not appear in
commands
{} A list of arguments enclosed in curly braces
\ A continuation of a command line
/ Levels of directory structure
# A comment
Audience
This manual is written for RTL logic designers. It assumes a basic understanding of RTL languages and the UNIX shell
environment. A basic knowledge of the Tcl Command Language is recommended, but not required.

Supported Platforms
Platform 64-bit
Red Hat Enterprise Linux 5.0 and above *
SuSE Linux Enterprise Server 11.0 and above *
CentOS 5.0 and above *
Ubuntu 12.0 and above *

Software
Installation
Each
Real
Intent
product
is
shipped
as
a
gzipped
tar
file.
As
such,
Real
Intent
iDebug
is
shipped
as
its
own
gzipped
tar
file.
You
can
download
the
required
tar
files
from
the
Real
Intent
web
site
(http://
www.realintent.com).
Users
with
an
existing
installation
can
skip
this
topic.
Install
each
Real

Intent
product
using
these
same
installation
instructions.
1.
Perform
the
following
steps
for
each
tarball
a. cd
to
the
directory
where
you
want
to
install
the
software.
b. Install
using
the
following
command
for
each
Real
Intent
product
(<ri_product>):
unix_prompt>
tar
xvfz
<ri_product>.<version>.<date>.tar.gz
2.
Make
sure
the
path
to
the
executable
is

in
your
PATH
You
can
use
the
full
path
to
the
executable
or
make
sure
the
path
to
the
executable
is
in
your
PATH
environment
variable.
unix_prompt>
setenv
PATH
<path_to_installation>/
bin:
$PATH
3.
Be
sure
xterm
is
available
on
your
system
Real
Intent
GUIs
optionally
invoke
an
editor
to
allow
viewing
of

the
source
code,
which
requires
an
xterm.
Be
sure
xterm
is
available
on
your
system.
4.
Real
Intent
products
use
the
FlexLM
licensing
system
Real
Intent
products
use
the
FlexLM
licensing
system.
See
License
Installation.
5.
Real
Intent
iDebug
can
optionally
use
Synopsys’s
(Springsoft)
TM
Verdi
Automated
Debug
System

While
Real
Intent
recommends
you
use
the
built-
in
default
iVision
visualizer
to
avoid
issues
related
to
multiple
compiles,
you
can
optionally
use
Synopsys’s
(Springsoft)
TM
Verdi
Automated
Debug
System.
To
do
so,
you
must
specify
idebug
-
verdi,
and
the
verdi
command
must
be
in
your
path.
6.
Verify
your
installation

To
verify
your
installation,
type
the
following
at
the
system
prompt:
unix_prompt>
<analysis_engine_executable>
-
version
where
<analysis_engine_executable>
is
one
of
the
following:
Analysis
Product
Engine
Executable
Ascent
ascentlint
Lint
Meridian
mcdc
CDC
or
meridian
Meridian
mpcdc
Physical
CDC
Meridian
mdconstraints
Constraints
Ascent
ascentxv
XV
Ascent
ascentiiv
IIV
Real
idebug
Intent
iDebug
unix_prompt>
idebug
-
version
unix_prompt>
xterm
Version
compatibility:
Real
Intent

iDebug
verifies
compatibility
with
the
analysis
engine
used
when
you
launch
iDebug
(idebug).

License Installation
Real Intent products use the FlexLM licensing system. The FlexLM binaries lmgrd, lmdown, vlmd, and so on are located
in the <RI_INSTALL>/bin directory (<RI_INSTALL> is where your Real Intent software is installed). To obtain a license file
for Real Intent products, contact Real Intent.
Setting Up the License Server

Your Real Intent license file will require modification before you can use it. Once you have installed your Real Intent
products locally, open the license file using a text editor and look for the SERVER and VENDOR lines within the license
file.
SERVER
If you only provided a hostid to Real Intent when requesting a license, your host name may be set to “unknown” in the
SERVER string. If this is the case, you will see an error message when you start the license server:
14:23:44 (lmgrd) "license.mydomain.com": Not a valid server hostname, exiting.
14:23:44 (lmgrd) Valid server hosts are: "unknown"
14:23:44 (lmgrd) Using license file "license.dat"
In this case, you will need to edit your SERVER line to replace:
SERVER unknown <hostid>
with
SERVER license.mydomain.com <hostid>
The host name you specify on the SERVER line should exactly match the output of the “hostname” command on the
license server.
VENDOR
All VENDOR lines require updating the path prefix to match the installation path of your local Real Intent installation.
This step must be performed for every license file received from Real Intent to match your local installation settings.
VENDOR vlmd <RI_INSTALL>/bin/vlmd

VENDOR dconcept <RI_INSTALL>/iDebug/iVision/flexnet-11.12.1.4/linux64/dconcept
Note: <RI_INSTALL> is the full absolute path to the “RealIntent” directory that was created when the iDebug tarball
distribution was untarred.
LM_LICENSE_FILE
With the license file updated, you need to tell the shell where to look for the license file by setting the
LM_LICENSE_FILE environment variable. There are two approaches:
1. Add the full path to the license.dat file to your LM_LICENSE_FILE environment variable.
C-Shell example:
unix_prompt> setenv LM_LICENSE_FILE <RI_INSTALL>/license/license.dat:${LM_LICENSE_FILE}
Bourne-Shell example:
unix_prompt> export LM_LICENSE_FILE=”<RI_INSTALL>/license/license.dat:${LM_LICENSE_FILE}”
2. Alternatively, you can set the LM_LICENSE_FILE to point to the <port>@name, where the port number is added after
the hostid in the license file. For example, the first line in the license file looks like this:
SERVER <hostname> <hostid> <port_number>
The host cannot be changed without invalidating the license, but the port number can. If the SERVER line of
the license file is modified as follows:
SERVER <hostname> <hostid> 27001

then the following setting of LM_LICENSE_FILE will work:

C-Shell example:
unix_prompt> setenv LM_LICENSE_FILE 27001@<hostname>
Bourne-Shell example:
unix_prompt> export LM_LICENSE_FILE=”27001@<hostname>”
Starting the License Server

Start the license server by running the command:
unix_prompt> <RI_INSTALL>/bin/lmgrd -c <RI_INSTALL>/license/license.dat -l
<RI_INSTALL>/license/lmgrd.log
Verifying the License Installation

You can verify the license installation as follows:
1. Examine the lmgrd.log file to see if any errors occurred during startup.
2. If the lmgrd.log file contains no error messages, invoke the Real Intent tool from the UNIX command prompt.
For example, for Meridian CDC and iDebug:
unix_prompt> mcdc
unix_prompt> idebug
Bringing Down the License Server

To bring down the license server, use the following command:
unix_prompt> <RI_INSTALL>/bin/lmdown -c <RI_INSTALL>/license/license.dat

Customer Support
For support issues, contact Real Intent at +1-408-830-9336 between 9:00 A.M. and 5:00 P.M. PST or by email at
[email protected]. Refer to the Real Intent web site at http://www.realintent.com for more information. In
addition you can contact your local support as shown below:
Region Organization Phone Email

Worldwide Real Intent, Inc. +1-408-830-9336 [email protected]
China TopBrain Design +86-21-6630-6500 [email protected]
Systems
Europe EuropeLaunch +49-8254-4869401 [email protected]
India Claytronics Solutions +91-80-9528-8163 [email protected]
Israel Real Intent Israel +972-54-5422605 [email protected]
Japan Real Intent KK +81-45-550-3054 [email protected]
Korea Real Intent Korea +82-10-9730-8563 [email protected]

Taiwan Kaviaz Technology +886-3-573-9968 support_tw@realintent_com

Release Notes
This section contains product release notes.

Meridian CDC 2016.A

The following features and enhancements are part of the Meridian CDC 2016.A FCS release.
Main Enhancements
1. Meridian CDC generates an iVision ZDB for use with iDebug at the end of elaboration.
2. RI_ROOT and similar variables are no longer used or required. Simply put the RI install directory in your path.
Enhancements that affect compatibility

CDC Analysis
Structural
• Changes in Reconvergence analysis
• 2016.A ignores recon along async reset arcs
• The Recon type "InterfaceReconWithGlobalInteraction" has been removed since it is
subsumed by "InterfaceReconWithGlobalDrivers"
• A new Info message called "SubsetDrivers" is added to denote the cases where
the recon drivers listed in a violation are a subset of the overall recon drivers for
that recon flop. This can only happen in case of multiple TX domains, where the
recon is split into multiple violations per each TX domain. It is possible sometimes
there is only driver in a given TX domain (which lcannot cause recon) and hence
ignored in reporting. So, whenever, "SubsetDrivers" is seen in Info column, it means
the ReconSignal is listed in some other recon violation as well, or that it has some
singleton CNTLs coming in from a different TX domain which were rejected.
• ActualReconPoint is enhanced to search backwards and report the earliest recon
point from the driving CNTLs.
• ReceiveFlop name will change and the name will appear without _REALINTENT for
liberty models when there is a single timing arc from input to internal flop or input flop to
output pin. If there are multiple timing arcs to output pins the flop name still would have
_REALINTENT
General Enhancements and Corrections

ID Summary
13093 Error #59137, func returns value of non-constant format
18425 Replace existing read_liberty ENV variable with Tcl variable
19819 FPGA: Backtrace while running Xilinx Verilog model, but compiles with VHDL model
19821 FPGA: Backtrace while running Xilinx VHDL model
20149 FPGA: Cannot pass string generics through "-generics" argument to elaborate
20488 FPGA: Encrypted models not picking up local parameter definitions
20494 Missing w_glitch
20496 Missing s_henv_wave_conflict
20500 Missing w_recon_groups
20504 Incorrect w_glitch being reported
20589 Full verilog functional model not being translated
20792 Have command wrapper ignore all RI*_ROOT variables defined in user's environment
20816 -write_formal_checks_file is listed incorrectly in online help under simportal options
20858 Change -module to -modules in set_shell_instances now that lists of modules are accepted
20865 Unexpected S_CONF_ENV detected
20870 translate_5.0_filters script should translate S_INPUT_CLK_DOMAIN to W_REDUNDANT_SYNC
20889 config of PULSE_SYNC description is wrong

20892 Remove I_GLITCH and W_PROP_CNTL_GLITCH descriptions from doc

20952 Improve W_LOCKUP description
20954 set_max_search_depth doc needs improvement
20955 report_env shows report_sdc example in doc
20956 Docs need a section/page that shows all CDC-relevant SDC commands
20963 Error in description for ri_ignore_unused_flops_in_analysis
20975 Color of clock domain incorrectly reflected on schematic
20976 Do not report S_INPUT_NO_WAVE when signal drives combinational logic only
21039 create_generated_clock needs examples filled in
21353 set_max_search_depth -recon default changed to 3

Meridian CDC 2015.A

The following features and enhancements are part of the Meridian CDC 2015.A FCS release.
Enhancements that affect compatibility

Front-End
read_lib changes to read_liberty
CDC Analysis
Structural
• create_env_file has been deprecated, analyze_intent -output_env can be used to create an
env file
• If a signal is fanning out to multiple waveforms then create_input is defined using a virtual
waveform which is asynchronous to all the waveforms. Earlier one of the wavform in the
fanout was arbitrarily picked up.
• Setup checks are not automatically done when verify_cdc is run. analyze_intent has to be
run for intent(setup) checks. Earlier setup checks were done when verify_cdc was run.
• verify_cdc no longer supports -env option, the environment specification in memory are
used for CDC analysis.
• Variables ri_report_i_{sync_crossing, clk_groups, interface, u_interface} have been replaced
by ri_report_{sync_crossing, clk_groups, interface, u_interface}
• Default value for following variables have been changed
• ri_report_w_interface (false to true)
• ri_synth_vhdl_generate_separator_style (defaults to "_" now)
• ri_allow_flop_driven_clk_gate (false to true)
• ri_report_u_interface (false to true)
• ri_synth_vlog_generate_naming_style (defaults to "%s[%d}" now)
• ri_verify_cntl_glitches (true to false)
• ri_max_loop_unroll (150 to 1024)
• ri_report_interface (false to true)
• ri_synth_vlog_generate_separator_style (defaults to "." now)
• ri_report_w_g_clk_glitch_bad_polarity (true to false)
• ri_exclude_internal_reset_analysis (false to true)
• ri_synth_vhdl_generate_naming_style (defaults to "%s_%d" now)
• ri_enforce_strict_variable_settings (false to true)
Formal
• verify_cdc -formal has been replaced by verify_cdc_formal command.
UI/GUI
• mddebug has been replaced by next generation debug debugger and data manager iDebug.
Enhancements
Front-End Changes
• Use ri_max_total_range for both limits when it is greater than ri_max_single_range_bits
• read_lib changes to read_liberty (not backwards compatible due to read_library_map)
• Improved Verilog/SystemVerilog Loop Handling

• The default value of the ri_max_loop_unroll will be increased from 150 to 1024 (as with DC)
so FE can unroll more loops by default.

• Added variable: ri_max_exceeded_stops_elab - this variable determines whether to stop

or continue when the tool cannot model big arrays, loops. Valid values are true or false.
When true, an error occurs and processing stops after elaboration. When false (default) the
construct is ignored, in essence creating an open circuit (outputs are undrivens and inputs are
not loaded). This variable is applicable to Verilog/SystemVerilog only.
• Compilation summary and setup report will have a separate BigLoop Type (used in the same
manner as BigArray is used)
• Support for pragma vendors has changed to enable disabling those supported by default. All
supported pragma vendors are now enabled by default, including verific, exemplar, synopsys, cadence,
pragma, synthesis, LV_BIST, spyglass, 0-in, and magma. The default list can be overridden as follows:
• Specific vendors can be globally disabled by setting the variable ri_ignore_pragma_vendors
to the list of vendors to be ignored.
• The analyze command switch has a new switch, -ignore_pragma_vendors {list}, that
provides a list of vendors to be ignored for that command only. This overrides the
ri_ignore_pragma_vendors variable setting.
• The analyze command has a new switch, -ignore_translate_off {list}, that causes
the <vendor> synthesis_off and <vendor> translate_off pragmas from the specified list
of vendors to be ignored for that command only. Note that this switch replaces the –
ignore_synth_translate_pragmas.
• SystemVerilog support of `begin_keyword `end_keyword for 1800-2005 and 1800-2009. The

keywords must be outside of design elements. The keywords override command line and file
extension directives.
• A new Tcl variable is added to control how a "-" is interpreted in VHDL. When
ri_vhdl_std_logic_dash_is_x is false, a VHDL '-' is treated as Don't Care(default). When
ri_vhdl_std_logic_dash_is_x is set to true, '-' will be treated as Don't Care. It will be treated as 'X',
meaning that '-' is interpreted strictly as a symbol which does not match any of the other 8 std_logic
values.
• RAMs and ROMs cannot have more than 128 constant indexed writes
• The ability to control the maximum license wait time was added. You can limit how long it will wait
by setting the environment variable RI_LIC_WAIT_TIMEOUT to a value between 3600s (1 hour) and
216000 (3 days); for example, setenv RI_LIC_WAIT_TIMEOUT 7200. The default value is 86400s (1 day).
If the value is outside the allowed range, the default value will be used.
• read_liberty was enhanced with the options -collapse_indexed_pins (which replaces -

no_blasted_buses) and -blast_bussed_pins. Refer to read_liberty. For backwards compatibility, use
read_liberty -collapse_indexed_pins.
• Some corner case bugs were fixed in the automatic naming of unnamed generate blocks.
• The "-F <file>" option was added to the analyze command. This is the same as "-file" but all
relative paths in <file> are relative to the location of <file>.
CDC Analysis
• Additional new rules are as follows
• CLK_GROUPS (replaces I_CLK_GROUPS)
• INTERFACE (replaces I_INTERFACE)
• I_HENV_DB_MAP
• I_HENV_WAVE_MAP
• SYNC_CROSSING (replaces I_SYNC_CROSSING)

• S_HENV_ATTR_CONFLICT
• S_HENV_EXTRA_SPEC
• S_HENV_MISSING_SPEC
• S_HENV_TYPE_CONFLICT
• S_HENV_WAVE_CONFLICT
• U_INTERFACE (replaces I_U_INTERFACE)
• W_REDUNDANT_SYNC
• W_RST_HALF
• Additional new commands are as follows

• set_max_search_depth
• set_synchronizer_depth
• set_user_reset_synchronizer
• set_glitch_free_inputs
• set_mutex_signals
• set_shell_instances
• set_user_cntl_synchronizer
• set_user_specified_cells
• user_defined_cntl_signals
• user_defined_data_signals
• analyze_intent
• verify_cdc_formal
• Additional new variables are as follows

• ri_synth_reg_preset_pin_name
• ri_synth_reg_synch_preset_pin_name
• ri_synth_models_user_dirs
• ri_synth_design_parameter_style
• ri_synth_design_separator_style
• ri_synth_array_naming_style
• ri_ram_max_word_size
• ri_ignore_pragma_vendors
• ri_remove_unused_combo_logic
• ri_project_directory_name
• ri_env_priority_order
• ri_oac_strict_type_checking
• ri_max_exceeded_stops_elab
• ri_auto_get_lib
• ri_use_platform_gdb
• ri_synth_design_naming_style
• ri_synth_record_naming_style
• ri_synth_reg_output_pin_name
• ri_synth_reg_enable_pin_name
• ri_report_i_henv_wave_map
• ri_synth_reg_output_inv_pin_name
• ri_assoc_as_fixed_array
• ri_disable_name_based_clock_and_reset_spec_creation
• ri_synth_interface_naming_style
• ri_synth_reg_synch_toggle_pin_name
• ri_vhdl_preserve_case
• ri_report_all_signals_in_i_constant
• ri_synth_reg_synch_clear_pin_name
• ri_synth_reg_synch_enable_pin_name
• ri_report_w_redundant_sync

• ri_synth_reg_clear_pin_name
• ri_synth_reg_data_in_pin_name
• ri_remove_unused_lib_cell_flops
• ri_synth_reg_naming_style
• ri_oac_result_display_limit
• ri_synth_reg_next_state_pin_name
• ri_synth_models_internal_dirs
• ri_report_w_g_clk_glitch_sync_reset_select
• ri_sdc_uniquify_warning_numbers
• ri_report_w_g_clk_glitch_async_reset_select
• ri_synth_reg_clocked_on_pin_name
• ri_session_name
Deprecated Categories, Commands and Variables

• Deprecated rules are as follows
• I_CNTL_DATA_GROUPS
• FIFO_CNTL_DATA_GROUPS
• I_ASYNC_RST_FLOPS
• I_INT_ASYNC_RST
• I_PSEUDO_CONSTANT
• I_SYNC_RST_FLOPS
• LOAD_CNTL_DATA_GROUPS
• PROP_CNTL_DATA_GROUPS
• S_INPUT_CLK_DOMAIN
• S_INT_RST_SYNC
• S_RST_PROP
• W_CNTL_DATA_GROUPS
• W_SIMUL_SET_RST
• W_INT_ASYNC_RST
• Deprecated commands are as follows

• write_shell_model
• cleanup
• create_env_file
• check_setup
• Deprecated variables are as follows

• ri_check_setup_dump_reset_simulation_vcd
• ri_check_setup_dump_signals_with_x_values_in_vcd
• ri_check_setup_num_timeframes_in_vcd_upto_reset_seq_end
• ri_check_setup_report_possible_bus_contention_nets
• ri_check_setup_report_potential_floating_bus_nets
• ri_check_setup_report_static_loops
• ri_report_all_supported
• ri_print_cdc_constants_to_log
• ri_glitch_checks
• ri_env_override_previous_command
• ri_report_s_rst_prop_deassert
• ri_use_seq_temp_constant_prop_for_data_glitch
• ri_resolve_mult_clocks
• ri_ignore_waveforms
• ri_report_s_rst_prop
• ri_report_s_input_clk_domain

• ri_report_load_cntl_data_groups
• ri_formal_checks_starter_file
• ri_report_driver_as_crossing_signal
• ri_report_i_int_async_rst
• ri_enable_interface_categories
• ri_report_zero_in_summary
• ri_limit_rst_prop_to_async_resets
• ri_abort_on_setup_issues
• ri_report_w_simul_set_rst
• ri_report_all_reset_recon_points
• ri_db_file
• ri_write_report_file
• ri_env_ignore_reset_commands
• ri_max_db_crossing_count
• ri_report_fifo_cntl_data_groups
• ri_report_cntl
• ri_effort_level_for_data_glitch_condition
• ri_report_w_g_clk_glitch_reset_select
• ri_report_prop_cntl_data_groups
• ri_report_i_async_rst_flops
• ri_report_crossing_file_name
• ri_sync_pulse_width_checks
• ri_shell_model_suppress_msgs
• ri_extra_pragmas
• ri_report_i_pseudo_constant
• ri_identify_clock_glitch_condition
• ri_warn_internal_reset
• ri_do_not_identify_rams
• ri_effort_level_for_clock_glitch_condition
• ri_proj_dir
• ri_report_data
• ri_report_i_sync_rst_flops
• ri_hdl_record_naming_style
• ri_report_groups_collapse
• ri_report_ram_internal_name
• ri_identify_data_glitch_condition
• ri_disable_auto_reclass
• ri_report_all_reset_fanout_points
• ri_gray_code_checks
• ri_report_bits_collapse
• ri_write_sim_model_templates
• ri_report_s_int_rst_sync_sync_clock_domains
• ri_shell_model_signal_tag
• ri_include_isolated_reset_propagation_rule
• ri_report_i_cntl_data_groups
• ri_report_w_cntl_data_groups
• ri_detect_half_cycle_reset_sync
• Deprecated variables that have a new command to cover similar functionality are as follows
• ri_user_sync_cells, new command is set_user_cntl_synchronizer
• ri_force_sync_within_cells, new command is set_user_cntl_synchronizer -force
• ri_non_strict_in_cells, new command is set_user_cntl_synchronizer-non_strict
• ri_force_reset_sync_within_cells, new command set_user_reset_synchronizer -force
• ri_max_reset_recon_depth, new command set_max_search_depth -rst_recon

• ri_max_reset_fanout_depth, new command is set_max_search_depth -rst_fanout

• ri_flop_depth_for_data_control, new command is set_max_search_depth -association.
Also there is a change in the way value is interpreted now. So if user was setting
ri_flop_depth_for_data_control to n now he should set set_max_search_depth -association to
n+1.
• ri_max_recon_depth, new command is set_max_search_depth -recon
• ri_max_w_fanout_depth, new command is set_max_search_depth -fanout
• ri_max_rst_uncertainty_recon_depth, new command is set_max_search_depth -rst_recon
• ri_max_rst_uncertainty_fanout_depth, new command is set_max_search_depth -rst_fanout
• ri_min_synchronizer_depth, new command is set_synchronizer_depth -min
• ri_max_synchronizer_depth, new command set_synchronizer_depth -max
• ri_min_reset_synchronizer_depth, new command set_synchronizer_depth -rst_min
• ri_max_reset_synchronizer_depth, new command set_synchronizer_depth -rst_max)
• ri_inputs_without_glitch_potential, new command set_glitch_free_inputs
• ri_user_specified_cells, new command set_user_specified_cells
• ri_flops_are_cntl, new command user_defined_cntl_signals
• ri_flops_are_data, new command user_defined_data_signals
• ri_user_associated_cntl, new command set_user_associated_cells -cntl_rx
• ri_user_associated_data, new command set_user_associated_cells -data_rx
• Deprecated variables that have been replaced with a new variable are as follows
• ri_report_all_drivers_for_cntl has been replaced with ri_report_number_of_drivers_for_cntl
• ri_report_all_drivers_for_data has been replaced with
ri_report_number_of_drivers_for_data
• ri_report_all_drivers_for_w_data has been replaced
withri_report_number_of_drivers_for_w_data

Meridian CDC 2015.A.P1

The following information applies to the Meridian CDC 2015.A.P1 release.
• Enhancements in 2015.A.P1
1. RAM detection changed to require that writes are from a conditional (if/else, ?:) statement.
2. The analyze command has a new -libmap option that allows for providing a library map file that maps a source file
to a specific V2K/SV library. An example library map file is:
library work ./src/config0.v;
library libtop ./src/top.v;
library lib0 ./src/m0.v;
library lib2 ./src/ma.v;
The above file maps config0.v to library work, top.v to library libtop, and m0.v to library lib0, m1.v to lib1, and ma.v
to lib2. In this case, file config0.v is a configuration file:
config config0;
design libtop.top;
instance top.i1 liblist lib1 lib0;
cell m liblist lib2 lib1 lib0;
endconfig
• Defects Corrected in 2015.A.P1

ID# Summary
16820 VHDL elaboration failure due to left range bound is not constant
17499 Error on localparam assignment with packed union lhs and array rhs
18409 VHDL var'left could not be resolved as a constant value
18620 Elaboration failure on mixed language design
19059 Tool not parsing an encrypted model enclosed by protect pragmas
19108 set_shell_instances -module accepts multiple modules
19125 Report all drivers for W_MASYNC
19129 X_INPUT category to be removed from W_G_CLK_GLITCH
18863 W_MASYNC not waived using set_mutex_signals command
15276 Annotation in CNTL to denote FastToSlow,SlowToFast, SameFreq
19289 I_RST_SYNC changed to RST_SYNC
19208 synchronous reset, reset synchronizer model not being detected
19112 -reclassfile option removed from verify_cdc
19222 No clocks reported even though ENV says it Auto-identified few clocks
19281 I_BLACK_BOX changed to BLACK_BOX
19330 Way to avoid environment overwrite warning


• Enhancements in 2015.A.P2
1. Support of create_output on Bbox inputs. The new variable which does this is "ri_create_outputs_on_black_box_inputs"
2. Support of "ri_create_inputs_on_undriven_nets" to comment out create_input on undriven nets.

ID# Summary
19376 S_INPUT_NO_WAVE reported due to few inputs not associated with create_input -waveforms
19521 translate_5.0_filters does not work on valid, complex filter
19529 set_user_cnt_syncronizer ignoring rest of Sync-modules!
19549 SV interface design incorrectly elaborated
19611 Run-time has become longer than 5.0 with all tx-drivers reporting
19648 Crash During Elaboration
19295 Filter application to create file with report of how many matches from a given GUI or manually
generated waiver
19424 2015.A crash when running "read_design_db"
19434 Filter translation script to produce "set_rule_status" commands
19459 Search function not working in HTML docs
19489 move DBG info after the "MissingFeedback" etc statuses in the Info column (was: need to collapse
multiple Signal to same W_CNTL ReceivingFlop)
19541 translate_5.0_filters creates an invalid view_criteria with "All columns" criteria
19634 translate_5.0_filters issues multiple translations (~6k) for a single waiver
19639 there is obsolete description at page 11 and 12 in MeridianCDC_Formal_Verification_app_note.
19701 formal check is skipped - even after set_run_formal command ..
19533 idebug HTML help broken for search of any CDC checks
19178 online help for ri_sdc_error_on_cmd_failure references create_env_file
19427 Deprecated variable ri_inputs_without_glitch_potential mentioned in the CDC doc
19437 ActualReconpoint and ReconvergencePoint for W_FANOUT documentation
19439 Remove examples of ascent_project from Meridian CDC documentation
19461 set_user_associated_cells not always writing EngineComments for DATA
19509 ri_report_dbg_file_for_each_driver needs to be mentioned in the W_CNTL and W_DATA sections
19697 please add -rule option to "export_rule_status".
19129 X_INPUT sub-category should be removed from W_G_CLK_GLITCH
19436 Association misspelled as assocaition in the CDC ref manual
13757 would like to see memory associated with the FIFO displayed in the FIFO_CNTL_DATA_GROUPS
14198 Customer needs a way to report bad user synchronizer cells
11819 Comment all the create_input constraints for undriven Nets
13134 module names not recognized in -shell_modules and -shell_instances
13271 Report modules and instances that have been shelled with -shell_modules and -shell_instances
15371 Usability issue with module names for some and cell names for other Tcl vars
15833 create "create_output" on BBOX input
17752 Implement ri_force_reset_sync_within_cells , ri_user_reset_sync_cells in 2015
19231 add a way to generate a list of synchronizers, both inferred and instantiated
19664 Tool crashed while running write_scripts using netlist
19710 write_scripts missing some constants to propagate
19711 write_scripts missing some stable values to propagate




ID# Summary
18417 Weighted probability of simulation value for injected value
19820 Clock mapping information block to top
19881 I_RST_SYNC being printed in 'W_ENCAP' info
19883 New option in write_scripts ..
19359 W_CNTL association type "DATA" not described
19624 BLACK_BOX to be enhanced to indicate when clock information mesh-models are used
19940 Table of default values for all ri_* variables
19170 data control condition statuses not embedded in report
19205 report_policy not erring/warning on invalid rule instance
19640 Header of Formal report is obsolete...
19829 Status change in REVIEW and INFO cannot be saved in Waive file
19922 idebug -cli is error out when read in a tcl which idebug exported...
19490 support for -combinational option for the create_generated_clock SDC command
19613 generated clock objects should be accepted as valid master clocks
19720 exported "VIEW_CRITERIA" is empty...
19778 please add "meridian" command to verify_cdc_formal message.
18413 error part-select direction is opposite from prefix direction
19782 set_mutex_signals on W_RECON_GROUPS the last group is left as New
19796 set_mutex_signals on arbitrary signals to apply to Waiving of W_RECON_GROUPS
19852 U_INTERFACE should cause suppression of various messages, like W_CNTL (Missing-Feedback)
19811 Variable ri_preserve_paths_in_auto_bboxed_insts is ignored and treated as if set to false
17583 I_CONSTANT category needs info pointing to line in ENV if constant is due to spec
19799 translate_5.0_filters should issue a WARN message when a filter doesn't match anything
19781 Report policy is accumulative and .bak is not updated
19813 translate_5.0_filters created waiver does not waive obvious match
19822 additional actual recon points to be reported in W_RECON_GROUPS
19667 command to import block level waivers to top .


• Enhancements and Corrected Defects in 2015.A.P4

ID Summary
19972 Objects are not appended to empty collections
19498 ENV file not created properly when UNMATCHED_PATTERN are encountered
12968 Meridian Labs still contain references to SimPortal
19970 Commands to create corresponding with formal_check.com do not work on lab63 example
19719 Add "-status" option to "export_rule_status"
19419 Report all 5 signals as "ToolWaived" which they are specified mutex signals
13665 Description of Is-Feedback and Has-Feedback
Translate_5.0_filters creates view_criteria with wrong fields when both W_MASYNC and W_DATA
20005
are present in the original 5.0 filter
19449 Correct set_cntl_association_depth default value; note in syntax section
19312 set_shell_instance only hides violations from view_criteria, not from policy
19979 ri_write_scripts_skip_module_insts_limit has default 5 , not 10
19977 I_CONSTANT and I_PSEUDO_CONSTANT now reported by analyze_intent
20037 Backtrace signal 11 for full-chip design
17892 Save and import previous criteria from GUI
16988 iDebug Status options pull-down need to be more easily accessible
19757 iVision should show an hourglass/processing symbol while still loading a design
16935 Online documentation for analyze, and so on, not correct
16710 Document verify_cdc_formal command
19879 W_ASYNC_RST_FLOPS is not reported in shifter logic
20114 TX-DATA, which is not being controlled by CNTL properly, is not reported in W_DATA



ID Summary
12209 Need a nice way of finding out the clock name of a net
20247 iDebug showed column "StatusS" in RST_SYNC
20438 Block-level waivers not honored when read_design_db is used
20397 Crash during Analyze_Intent using 2015.P4
20382 Condition signals in .lib, but those are not generated in .v module
20256 W_DATA crossing missing in structural CDC run
20170 Crash when tried to display the clock tree in iVision
20428 Session switch messing up report_policy
20066 Support passing any size parameter across boundary to generic, rather than truncating to 32 bits
19622 Productize the Archive feature
16975 Reference Manual entry for set_data_clock_domain is incorrect
20258 Add explanation of how Domain and Waveform will be named
20239 W_REDUNDANT_SYNC description needs more information
20229 Help message not found for ri_assume_primary_inputs_have_glitch_potential
20226 I_CLK_* link problem to HTML Help
20152 Inconsistent Structural reports
20138 Description of "Blocked" association of CNTL is incorrect
20118 Need improved description of -instances option of set_mutex_signals
20115 Naming rule of parameterized module is unclear
19922 idebug -cli terminates with an error when read in a Tcl that idebug exported
19640 Header of Formal report is obsolete
19470 report_policy command should have -check option
20423 translate_5.0_filters script should translate 5.0 I_BLACK_BOX to 2015.A BLACK_BOX
20378 set_waveform_map does not report I_HENV_WAVE_MAP
“command failed" message received on update_view_criteria_details created by translate_5.0_filters
20371
script
translate_5.0_filters script not generating update_view_criteria_details and set_rule_status in output
20370
script
analyze_intent changing user-specified create_output, causing W_ENCAP mismatch between 5.0 and
20365
2015.A
20337 lib2v translator is writing out create_gen_clock -edge_shifts instead of -edge_shift
20069 Need documentation covering 5.0 to 2015.A transition
20045 File->Export (GUI menu) and export_rule_status (CLI) need to export EngineComments information
19360 Marking 1 W_CNTL for formal analysis, but seeing 2 pulse width failures
18495 Unpredicted elaboration result on large depth of memory
19913 Restore formal_checks.conf file capabilty in 2015.A
20105 analyze_intent -disable does not generate an ri_default.env file
20044 translate_5.0_filters fails when I_BLACK_BOX is done on parameterized module
20038 Exit 1 failure when attempting to run read_cdc_db
16897 set_clock_groups -asynchronous is not treated appropriately

13134 Add new command get_all_instances to retrieve all instances of a given uniquified module name
Filter application to create file with report of how many matches from a given GUI or manually
19295
generated waiver
20321 set_mutex_signals works for only 1 hierarchy deep when -instances option is used
20303 set_mutex_signal is not working well for unique parameterized modules


13630 Report clock domains of all the outputs in a design
17480 Trace generated shows no waveform in debug
17578 W_CNTL with 'Blocked' association needs to provide blocked type
18776 Primitives should not be reported as Location items
19528 Misleading msg when cell name not defined in set_user_cntl_synchronizer
19738 Need to error out when attempting to merge SDC and ENV into same scenario
19814 FPGA: Backtrace while running Xilinx Verilog Model
19821 FPGA: Backtrace while running Xilinx VHDL Model
20107 Terminate with error when ENV commands are used in CTL
20108 2015 P2 crashed after setting param value @ top level
20117 Warning message of -instances option of set_mutext_signals is unclear
20144 Report a warning when specified inactive set_mutex_signals command
20172 Handle glitch-free MUXes (W_G_CLK_GLITCH)
20323 set_mutex_signal should echo each command being applied
20324 New options for config commands needed for cdc
Constant driven on output port (latest ascenlint pass) whereas cdc-m-2015.P4 fails
20424
with ERROR
20478 set_mutex_signal issues with multiple sets and groupings
20536 Description of W_BLOCKED_CROSSING is insufficient
20568 analyze_intent instance name with -module option while writing out env file
20575 iDebug shows strange SpecifiedPeriod when exact waveform periods are specified
20577 Errors during filter translation
20582 Add -replace to all create_view_criteria in translate_5.0_filters script
20669 Script error in 5.0 translated filter
20674 Translate filter issues
20705 Regular expressions on translate_5.0_filters cause issue with size of log file
20713 elaborate took 48 minutes for 2M gate design

20718 Crash that occurs in formal CDC run

20721 Error with translate_5.0_filters
20729 analyze_intent adds a set_stable command on a signal that is NOT an RTL signal
20736 Reset Sync Name is not getting dumped in Cellname
20737 -force option in set_user_reset_synchronizer description is incorrect
20745 Improve S_INPUT_NO_WAVE description
20772 Not all W_REDUNDANT_SYNC is getting reported
20805 set_mutex_signals -collate_signals log file information is not correct

Meridian CDC User Guide

A clock domain refers to a synchronous subsystems where all the registers and logic are associated with the same
clock and/or its derived synchronous clocks. Today’s SoC integrates a diverse set of peripherals, memory, graphics,
networking and I/O components that may originate from a multitude of sources. The components operate at clock
frequency ranges that may be very different from the components they interact with. This leads to multiple clock
domains in the designs.
Since the domain crossing signals are asynchronous to the receiving clock domain, they could change value during the
setup and hold window of the receiving flop, as a result, the output of the receiving flop could become metastable.
This results in incorrect values being propagated downstream, causing functional errors. The failure signatures are
unpredictable and intermittent making them very hard to detect and diagnose via simulation or in the lab. Several
companies have experienced costly silicon re-spins as a result of not comprehensively verifying clock and reset-related
CDC issues.
Meridian CDC is a complete clock domain crossing (CDC) verification solution that performs structural and functional
analysis on the designs (RTL or Netlist) with multiple asynchronous clock domains for ASIC and FPGA designs. It verifies
that data crossing asynchronous clock domains in is always reliably received in the receiving clock domain. It works at
the block level, IP and chip-level.

Meridian CDC is the fastest, highest capacity and most precise CDC solution in the market. It performs comprehensive
structural and functional analysis to ensure that signals crossing asynchronous clock domains on ASIC, or FPGA devices
are received reliably. Meridian CDC is the only solution that enables all aspects of CDC sign-off for giga-gate SoC
designs. It supports flexible top-down and bottom-up analysis to accommodate different design methodologies needed
by the users.
Audience
This manual is written for logic designers, verification engineers and physical designers. It assumes a basic understanding
of Verilog or VHDL languages and the UNIX shell environment. A basic knowledge of the Tcl Command Language is
recommended but not required.

Meridian CDC Invocation

The Meridian CDC engine can be invoked in two different modes, depending on the usage model.
• Command Script Mode

• Interactive Shell Mode
Command Script Mode

When you run Meridian CDC in command script mode, you can provide a control script (ctl_file) that contains
commands for reading in a design creating the environment file, and performing CDC analysis. Here is how you run
Meridian CDC in command script mode.
unix_prompt> meridian -i <ctl_file>

or
unix_prompt> mcdc -i <ctl_file>
Meridian CDC supports the following command-line options.
Command-Line Option Description

-d|-design Design top name
-doc Load HTML help in your preferred browser (all other command-
line options are ignored)
-h|-help Display this help message
-i|-input <cmdfile> Execute meridian commands in <cmdfile>
-l|-log <file> Name of the log file (default is mcdc.log)
-previous|-previous_project <dir> Use this project directory from a previous run
-proj|-project <dir> Meridian project directory (default is meridian_project)
-session <name> Session name, prefixed to all Meridian output files and project
directory
-version Print Meridian version
-wait|-wait_license Wait until Meridian license becomes available. This option
tells Meridian CDC to keep polling the license daemon until
a license is available and then run. User can limit how long
tool will wait for license by setting the environment variable
RI_LIC_WAIT_TIMEOUT to a value between 3600s (1 hour) and
216000 (3 days); for example, setenv RI_LIC_WAIT_TIMEOUT 7200.
The default value is 86400s (1 day). If the value is outside the
allowed range, the default value will be used.
Interactive Shell Mode

Type “meridian” at the unix prompt to start running Meridian CDC interactively. In the Meridian CDC shell, users can
issue any Meridian CDC commands. The commands from any session will be written to meridian.his which can also be
used as a basis for a control file. Extensive online help is available in interactive mode as well. Type “help” or “help
<cmd>” at the meridian prompt. Refer to section on Command Reference for commands. Please see Meridian CDC
Verification Flow to understand more about ordering of the commands.

Meridian CDC Verification Flow

Meridian CDC offers a simple yet configurable flow that can be fully automated to meet user methodologies. The flow
consists with three basic steps: Design Analysis, Intent Analysis, and CDC analysis. At the end of each step, Meridian
CDC generates results that indicate whether each step can be signed off. The flow diagram below shows the complete
flow of running CDC verification signoff with Meridian CDC. Each individual step can be configured to meet user
methodology requirements. Use the links provided to view topics that have more details.

Design Analysis
This is the design setup step for CDC verification. Design Setup consists of read_liberty (optional, not
required if technology specific cells are not used), analyze, and elaborate commands. This is analogous
to compilation and elaboration in a simulator or any synthesis tools, Meridian CDC also offers the same
functionality to facilitate the Design Setup. The analyze command supports IEEE standards such as
Verilog, SystemVerilog, and VHDL (please refer to analyze command for details) and read_liberty for
reading in technology specific library cells (please refer to read_liberty command for details). Meridian
CDC provides comprehensive set of variables (please refer to Design Configuration) to configure design
setup to meet user specific methodologies.
Below is a sample run script of Design Setup, complete details of Design Setup and Configuration:
Sample run script Sample rtl_file.list

## setting search path for RTL sources +incdir+src
set ri_search_path [list /home/project/ip/src \ +define+SYNTHESIS+define+CDC
/home/myblock/rtl ] -v2k
design_top.v
## reading in technology specific library cells -sverilog
read_liberty [list /home/technology/memory/ async_fifo.v
memory.lib \ or_dc.v
/home/technology/clk_gen/ or_ic.v
pll.lib ] clock_gen.v
## analyze all the RTL source files

analyze -file rtl_file.list
## elaborating the design

elaborate design_top \
-black_box [list analog_d2a analog_a2d]
## generate message related to design

report_messages -output design_messages.txt
Please refer to following topics for more details:
• Design Compilation Flow

• Commands related to Design Compilation
• Variables related to Design Compilation

Intent Analysis
Intent analysis is a critical step in the flow to create design specifications, this step allows user
to read in design specification (if available) required for CDC verification or generate them
automatically. User specification can be in form of SDC (Synopsys Design Constraints) or Real Intent
native ENV format. Command read_sdc supports widely used SDC (frequently used for Static Timing
Analysis) to derive clock information, primary input and output ports and their clock relation, and
synchronous/asynchronous relationship for CDC analysis. Command read_sdc also perform language
level syntax and semantics checks to ensure intent of user SDC is correct. Similarly, command
read_env can be used to read in ENV if exists as a seed to derive design specification. Any problem
related to user SDC via read_sdc can be reported by report_sdc command, like wise, any problem
related to user ENV via read_env can be reported by report_env commands. All the violations
related to syntax and semantics checks are reported under SDC_ENV_LINT Rule Group by default
in the iDEBUG. If user specification does not exist, Meridian CDC can generate initial set of design
specification automatically.
Once the user specification is read in, Intent Analysis step performs following task to validate them.
Please see analyze_intent command for more details on automatic intent creation.
• Analyze specification for correctness

Checks if the user provided specifications are correct with respect to the design, any
problem identified during this analysis are reported with details and root causes such
problems.
• Analyze specification for consistency

Checks if the user provided specifications are consistent. It checks the consistency
between the specifications to ensure the intent for CDC verification is valid.
• Analyze specification for completeness

Checks the user provided specification to see if it completes. If there are missing
specification needed for CDC verification, command analyze_intent automatically
generates them by default (user can control this behavior).
All the issues related to specification that require user action to correct before moving to CDC
Verification are reported under MCDC_SETUP_CHECKS Rule Group.
Below is a sample run script of Intent Analysis step.
Sample run script

## Configuring Environment setup
set ri_translate_set_output_delay true
set ri_create_inputs_on_black_box_outputs true
set ri_create_outputs_in_create_env true
## reading in SDC
read_sdc [list /home/mydesign/clock.sdc \

/home/mydesign/io.sdc \
/home/mydesign/exception.sdc ]
## reading an existing ENV

read_env [list /home/mydesign/design_top.env ]
## running intent analysis

analyze_intent
Please refer to following topics for more details:

• Intent Analysis Flow
• Default Rule Group related to Intent Analysis
• Commands related to Intent Analysis
• Variables related to Intent Analysis
CDC Analysis
This is the step that performs CDC verification. Structural analysis traverses the design looking for
structures in the design that do not conform to safe CDC requirements. Users should examine the
structural analysis results carefully to make sure that design issues are corrected or signed off on
certain findings. Meridian CDC offers many debugging capabilities to help pinpoint the errors and
minimize the debugging effort. Meridian CDC report is carefully organized to offer important and
relevant information, with helpful explanations. It is important to understand Meridian CDC structural
analysis results and fix all relevant issues before performing formal analysis.
Sample run script

## run cdc structural analysis
verify_cdc

Meridian CDC Usage Models

offers various CDC verification flows based on the user methodology. Following are some of the commonly used flows.
1. Full Design CDC Verification flow

This is the very basic flow of running CDC verification. Full design is readin and INTENT and CDC Analysis is
done on all the design in one run. This supports SoC,Block, or IP Level CDC verification.
Meridian CDC
2. Bottom Up Hierarchical(BUH) CDC Verification flow
Meridian CDC’s bottom-up CDC capability is used for
• CDC Verification at SoC integration level
• Leverages IP/Block Level CDC Verification
BUH flow allows users to read db for modules already verified to be free of CDC issues. The lower level
db together with the environment information can be used for verification at higher levels. The benefits
of bottom-up verification include faster processing time at the top level, simpler verification report
and therefore simplified debugging since lower level issues are gone, as well as ensuring correctness of
environment specification at the top level vs. the lower level.

Full Design CDC Verification Flow

Meridian CDC offers various CDC verification flows based on the user methodology and this is the very basic flow of
running CDC verification. Below flow diagram shows complete set of steps and the details of each individual steps.

Methodology Configuration
User can configure his methodology by importing user created policy file or use builtin policy files.
Design Setup
Required step, this step setup the design for CDC verification. Design Setup consists with read_liberty
(optional), analyze, and elaborate commands. This is analogous to compilation and elaboration in a
simulator, Meridian CDC also offers the same functionality to complete the Design Setup. The analyze
command supports IEEE standards such as Verilog, SystemVerilog, and VHDL (please refer to analyze
command for details) and read_liberty for reading in technology specific library cells (please refer to
read_liberty command for details). Meridian CDC provides comprehensive set of variables to configure
design setup to meet user specific methodologies. Below is a sample run script of Design Setup,
complete details of Design Setup and Configuration, please see DESIGN Compilation Commands.

design_top.v



Environment Setup
Optional step, if SDC or ENV does not exist user can move to next step Analyze Intent. If SDC
constraints or ENV from previous run available, user can read them in to derive design specification
for CDC verification. Command read_sdc supports widely used SDC (frequently used for Static Timing
Analysis) to derive clock information, design boundary relation, and synchronous/asynchronous
relationship for CDC analysis. Command read_sdc also perform language level syntax and semantics
checks to ensure intent of user SDC. Also, command read_env can be used to read in ENV (RI native
environment specification format) if exists as a seed to derive design specification. Below is a sample
run script of Environment Setup, complete details of reading SDC and configuring read_sdc, please
refer to SDC Read In topic.
Sample run script

## reading in SDC
Any problem related to read_sdc can be reported by report_sdc command, like wise, any problem
related to read_env can be reported by report_env command. All the violations related to syntax and
semantics checks are reported under SDC_ENV_LINT Rule Group by default.
A mix-and-match of SDC and ENV is not supported. In case reading of both sdc and env is required
following sample script can be used
Sample run script

create_scenario {sdc env}

## reading in SDC
/home/mydesign/exception.sdc ] -output_env converted.env -scenario sdc
read_env {converted.env user.env} -scenario env
current_scenario env

Analyze Intent
[Required] This step helps with sign off on the design environment for verification. The
analyze_intent command performs the following tasks:
Checks whether the user-provided specifications are correct with respect to the
design.
Checks whether the user-provided specifications are consistent. Checks consistency
between specifications to ensure the verification intent. The analyze_intent
command also performs a specification consistency check between the top-
level specification and the pre-verified IP-level specification in the Bottom-Up-
Hierarchical CDC verification flow.
Checks whether the user-provided specifications cover the requirements for CDC
analysis. If a user specification is not provided, analyze_intent auto-generates the
initial design specification.
Sample run script

##
analyze_intent
Analyze Intent is an iterative process. Any problems are reported under the MCDC_SETUP_CHECKS
Rule Group.
CDC Structural Analysis
Required step, this is the step that performs CDC verification. Structural analysis traverses the design
looking for structures in the design that do not conform to safe CDC requirements. Users should
examine the structural analysis results carefully to make sure that design issues are corrected or
signed off on certain findings. Meridian CDC offers many debugging capabilities to help pinpoint
the errors and minimize the debugging effort. Meridian CDC report is carefully organized to offer
important and relevant information, with helpful explanations. It is important to understand Meridian
CDC structural analysis results and fix all relevant issues before performing formal analysis. For more
details about the issues reported in this category please refer to section CDC Checks.
Sample run script

## cdc structural analysis
verify_cdc

CDC Formal Analysis
This is an optional step if CDC sign off methodology is established based only on the structural
analysis. However, verifying functional aspect of the signals that cross asynchronous domains remain
intact and captured correctly in the receiving clock domain is required either through formal analysis
or dynamic simulation.Though structural analysis can identify all potential structural errors in the
design, it does not check for CDC related functional errors. Formal analysis can precisely identify CDC
related functional failures in the design. Traditional formal analysis, such as equivalence checking and
property verification, is built to analyze steady state design behavior. Hence, these formal techniques
are incapable of formally analyzing certain behavior because of metastability and glitches. Special
formal analysis techniques that are capable of handing behavioral uncertainty are needed for CDC
applications. As the computational complexity of formal analysis is very high, this can require a large
amount of computation time. But early detection provides significant savings in the overall debugging
and sign-off cost and ensures a robust design.
Meridian CDC performs four types of formal analysis:
•Gray code check to ensure that FIFO related reconvergent control signals are Gray coded
•Data stability check to ensure safe data crossings across asynchronous clock domains.
•Formal glitch check to ensure that there is no glitch in the combinational circuit to cause wrong
value to be captured at the receiving domain
•Pulse width check to ensure that control crossings are held long enough to be sampled at the
receiving domain
IMPORTANT: In order to get accurate results, you must specify correct clock frequencies in the ENV
or SDC file (read in using the read_sdc or read_env command).
Sample run script

## CDC formal analysis
verify_cdc_formal
• Running Meridian CDC Verification Flow

Meridian CDC offers simplest and most performance efficient flows. If the verification process is in the
refinement step, that helps re-use data from the previous run in the refinement. read_design_db command
can be used to read previously saved design database. -previous_porject option can be used with meridian to
start with last saved run. Following are some example flows.
Fresh run
This flow facilitates when running CDC verification for the first time on the design using design source.
This step includes complete design compilation step and also library cell compilation. Invoke meridian
with a runscript with using -i option. Following is example runscript.

design_top.v



read_sdc design.sdc
analyze_intent
verify_cdc
report_policy {NEW TO_BE_FIXED DEFERRED WAIVED}
Starting a run from saved design database

This flow facilitates running CDC verification from already saved design database. User can compile the design
and save in a database and restart CDC verification using this usage model. Invoke mrdc with a run script using
-i option.
Sample run script

read_desgn_db
read_sdc design.sdc
analyze_intent
verify_cdc
report_policy {NEW TO_BE_FIXED DEFERRED

WAIVED}
Starting a formal run with structural run saved database

This flow facilitates running CDC verification from already saved design and specification database. This flow
is used when environment file has been finalized and user wants to start with intent checks. Invoke meridian
with a runs cript with using -i option, -previous, -design option. Meridian RDC will read sturctural results
from previous saved database and restart formal run from there. Following is example run script.
Sample run script

read_design_db
verify_cdc_formal

Bottom-Up Hierarchical (BUH) CDC Verification Flow

Meridian CDC offers BUH CDC verification flow. This flow can be used for CDC Verification at SoC/Subsystem integration
level. The flow leverages Block/IP level CDC Verification run. The flow first checks if there are consistencies issues
between block level and top level specification. Once those are cleaned or signed-off CDC issues are reported.
Following shows the high level flow
The benefits of bottom-up verification include faster processing time at the top level, simpler verification report
and therefore simplified debugging since lower level issues are gone, as well as ensuring correctness of environment
specification at the top level vs. the lower level. Following figure shows ion detail all the steps involved with
description of each step in the flow.

Block Level CDC Verfication

This is the block level CDC verification. The flow is same as Full Design CDC Verification Flow. At the end of
the run a Model db is generated which can used for top level run. For more detailed information refer to Full
Design CDC Verification Flow.

Design Setup
Required step, this step setup the design for CDC verification. Design Setup consists with read_liberty (optional),
analyze, and elaborate commands. This is analogous to compilation and elaboration in a simulator, Meridian CDC
also offers the same functionality to complete the Design Setup. The analyze command supports IEEE standards
such as Verilog, SystemVerilog, and VHDL (please refer to analyze command for details) and read_liberty for
reading in technology specific library cells (please refer to read_liberty command for details). Meridian CDC
provides comprehensive set of variables to configure design setup to meet user specific methodologies. Below
is a sample run script of Design Setup, complete details of Design Setup and Configuration, please see DESIGN
Compilation Commands.

design_top.v
read_liberty [list /home/technology/memory/memory.lib async_fifo.v
\ or_dc.v
/home/technology/clk_gen/pll.lib ] or_ic.v
clock_gen.v

## read db for block

read_cdc_db -block_proj_dir block_meridian_project/
block -name block

Environment Setup
Optional step, if SDC or ENV does not exist user can move to next step Analyze Intent. If SDC constraints or
ENV from previous run available, user can read them in to derive design specification for CDC verification.
Command read_sdc supports widely used SDC (frequently used for Static Timing Analysis) to derive clock
information, design boundary relation, and synchronous/asynchronous relationship for CDC analysis. Command
read_sdc also perform language level syntax and semantics checks to ensure intent of user SDC. Also,
command read_env can be used to read in ENV (RI native environment specification format) if exists as a seed
to derive design specification. Below is a sample run script of Environment Setup, complete details of reading
SDC and configuring read_sdc, please refer to SDC Read In topic.
Sample run script

set ri_create_inputs_on_black_box_outputs
true
## reading in SDC
Any problem related to read_sdc can be reported by report_sdc command, like wise, any problem related to
read_env can be reported by report_env command. All the violations related to syntax and semantics checks
are reported under SDC_ENV_LINT Rule Group by default.

Analyze Intent
Required step, this step helps user sign off on design environment for CDC verification. Command
analyze_intent performs following tasks during this step:
Checks if the user provided specifications are correct with respect to the design. Any
problems
Checks if the user provided specifications are consistent. It checks the consistency between
the specifications to ensure the intent for CDC verification. Command analyze_intent also
performs specification consistency check between top level specification and pre-verified IP
level specification in the Bottom-Up-Hierarchical CDC verification flow. Following is the list of
checks that report inconsistency between top level and IP specifications
a. S_HENV_ATTR_CONFLICT
b. S_HENV_EXTRA_SPEC
c. S_HENV_MISSING_SPEC
d. S_HENV_TYPE_CONFLICT
e. S_HENV_WAVE_CONFLICT
Analyze specification for completeness

Checks if the user provided specifications covers the requirements for CDC analysis, if
user specification is not provided, command analyze_intent auto generates initial design
specification.
Sample run script
analyze_intent
Analyze Intent is a iterative process, problems related to above are reported under MCDC_SETUP_CHECKS
Rule Group.
CDC Structural Analysis

Required step, this is the step that performs CDC verification. Structural analysis traverses the design looking
for structures in the design that do not conform to safe CDC requirements. Users should examine the
structural analysis results carefully to make sure that design issues are corrected or signed off on certain
findings. Meridian CDC offers many debugging capabilities to help pinpoint the errors and minimize the
debugging effort. Meridian CDC report is carefully organized to offer important and relevant information, with
helpful explanations. It is important to understand Meridian CDC structural analysis results and fix all relevant
issues before performing formal analysis. For more details about the issues reported in this category please
refer to section CDC Checks.
Sample run script

verify_cdc

CDC Formal Analysis

This is an optional step if CDC sign off methodology is established based only on the structural analysis.
However, verifying functional aspect of the signals that cross asynchronous domains remain intact and
captured correctly in the receiving clock domain is required either through formal analysis or dynamic
simulation.Though structural analysis can identify all potential structural errors in the design, it does not
check for CDC related functional errors. Formal analysis can precisely identify CDC related functional failures
in the design. Traditional formal analysis, such as equivalence checking and property verification, is built to
analyze steady state design behavior. Hence, these formal techniques are incapable of formally analyzing
certain behavior because of metastability and glitches. Special formal analysis techniques that are capable
of handing behavioral uncertainty are needed for CDC applications. As the computational complexity of
formal analysis is very high, this can require a large amount of computation time. But early detection provides
significant savings in the overall debugging and sign-off cost and ensures a robust design.
Meridian CDC performs four types of formal analysis:
•Gray code check to ensure that FIFO related reconvergent control signals are Gray coded
•Data stability check to ensure safe data crossings across asynchronous clock domains.
•Formal glitch check to ensure that there is no glitch in the combinational circuit to cause wrong value to be
captured at the receiving domain
•Pulse width check to ensure that control crossings are held long enough to be sampled at the receiving
domain
Sample run script

verify_cdc_formal

Meridian CDC Verification Policies

Meridian CDC offers the ability to define your CDC Methodology. You can enable/disable or change the severity
of factory rules (also known as a policy file) to suit your design needs. The table below shows the factory
policies provided with Meridian CDC. You can move violations from one policy to another, either by modifying the
RuleContentStatus or by selecting an action from the Analysis menu in iDebug (Set Status -> New, Fix, Waive, Defer).
NEW This policy is for new violations where no action has yet been taken. For a first run, all violations are
reported under this policy. For subsequent runs, Meridian CDC reports all violations not moved from
this policy, or any new violations, under this policy.
TO_BE_FIXED Move violations that have been reviewed and need fixes (in the design, in the env, or elsewhere) to this
policy.
DEFERRED Move violations that have been reviewed and are not being acted upon right now to this policy. You can
update the Comments field to indicate the reason for moving the violation to this policy.
WAIVED Move violations that have been reviewed and can be ignored to this policy. You can update the
Comments field to indicate the reason for moving the violation to this policy.
Note: In some cases, the tool will automatically move some violations into this policy based on user-
specified commands in the run script. For these tool-waived violations, ToolWaived appears in the
RuleContentStatus field in iDebug, and the command that caused the violation to be waived appears in
Comment field.
Each policy has the following Meridian CDC factory rule groups:
Factory Rule Group Reports Results from

SDC_ENV_LINT All syntax and semantic issues read_sdc and read_env
commands
MCDC_SETUP_CHECKS Issues related to CDC specification analyze_intent command
MCDC_ANALYSIS_CHECKS Issues related to CDC verification verify_cdc and
verify_cdc_formal
commands
In addition to above factory policies, you can create your own policies and modify the default severity of above rule
violations (see Creating Your Own Rule Policy).

SDC_ENV_LINT
Rules in this group are related to SDC and ENV syntax and semantic checks (see SDC/ENV Lint Checks).
While running the read_sdc or read_env command, all the violations related to syntax and semantics checks are
reported under the SDC_ENV_LINT rule group by default. The following table shows all the rules in this rule group and
their severity.
Rule Name Severity

INVALID_SYNTAX ERROR
INVALID_ARG_USAGE ERROR
MISSING_ARG ERROR
INCONSISTENT_MSTR_GEN_CLKS_SRC ERROR
REF_CLK_NOT_IN_NETWORK ERROR
UNMATCHED_PATTERN WARNING
EMPTY_COLL WARNING

MCDC_SETUP_CHECKS
Rules in this group are used to check SDC or ENV constraints for consistency and completeness (see INTENT Checks).
The violations related to this policy are generated when the analyze_intent command is run. The intent of this
command is to
Checks if the user provided specifications are correct with respect to the design. Any
problems
Checks if the user provided specifications are consistent. It checks the consistency between
the specifications to ensure the intent for CDC verification. Command analyze_intent also
performs specification consistency check between top level specification and pre-verified IP
level specification in the Bottom-Up-Hierarchical CDC verification flow.
Checks if the user provided specifications covers the requirements for CDC analysis, if
user specification is not provided, command analyze_intent auto generates initial design
specification.
The following table shows all the rules in this rule group and their severity.
Rule Name Severity

S_CLK_GATE_NO_WAVE ERROR
S_CLK_OFF_SUB_TREE ERROR
S_CONF_ENV ERROR
S_HENV_ATTR_CONFLICT ERROR
S_HENV_EXTRA_SPEC ERROR
S_HENV_MISSING_SPEC ERROR
S_HENV_TYPE_CONFLICT ERROR
S_HENV_WAVE_CONFLICT ERROR
S_INPUT_NO_WAVE ERROR
S_NET_NO_WAVE ERROR
S_NOCLK ERROR
S_RST_INV ERROR
S_GENCLK WARNING
S_MULTCLK WARNING
S_NORST WARNING
S_NUM_ANALYSIS_TIME_SLICES WARNING
S_UNINIT_FLOPS_LATCHES WARNING
S_UNKNOWN_CLKPOL WARNING
BLACK_BOX REVIEW
I_CLK_DOMAINS INFO
I_CLK_TREES INFO
I_HENV_DB_MAP INFO
I_HENV_WAVE_MAP INFO
I_RST_SIGNAL INFO

MCDC_ANALYSIS_CHECKS
Rules in this group are for CDC checks.
The violations are reported under this Rule Group when the verify_cdc command is run. The following table shows all
the rules in this rule group and their severity.
Rule Name Severity

W_ASYNC_RST_FLOPS ERROR
W_CLK_RECON ERROR
W_CNTL ERROR
W_DATA ERROR
W_FANOUT ERROR
W_G_CLK_GLITCH ERROR
W_GLITCH ERROR
W_MASYNC ERROR
W_RECON_GROUPS ERROR
W_INTERFACE WARNING
W_D_CLK_GLITCH WARNING
W_ENCAP WARNING
W_HALF WARNING
W_REDUNDANT_SYNC WARNING
W_RST_HALF WARNING
W_RST_SPEC_CLK WARNING
W_RST_UNCERTAINTY WARNING
BLACK_BOX REVIEW
CLK_GROUPS REVIEW
CNTL REVIEW
DATA REVIEW
GRAY_CODE_CHECKS REVIEW
INTERFACE REVIEW
PULSE_SYNC REVIEW
RST_SYNC REVIEW
SYNC_CROSSING REVIEW
U_INTERFACE REVIEW
I_ASSUME INFO
I_CLK_DOMAINS INFO
I_CLK_TREES INFO
I_CONSTANT INFO
I_RST_SIGNAL INFO

Meridian CDC Formal Verification

The default analysis provided by Meridian CDC is based on highly efficient structural analysis. This technology is proven
to catch most clock-domain-crossing design errors in a fast and straightforward way. However, structural analysis has
its limitations because it does not understand the actual functionality of the circuitry.
One powerful and unique way to gain insight into the functionality of your circuit and how it interacts with the
CDC design, is to employ Meridian CDC formal analysis capability. Sufficient knowledge about formal technologies
is required in order to apply formal analysis to a CDC problem successfully. In particular, constraints are needed to
establish the normal mode of operation of the design. In addition, capacity limits common to all formal analysis tools
require that modules, such as big arithmetic units, are blackboxed. Because formal analysis is exhaustive, successful
completion leads to greater confidence in CDC logic.
See Full Design CDC Verification Flow for information about deploying Meridian CDC formal analysis successfully.
For successful formal analysis, we recommend the following steps.
1. Environment setup and refinement

A typical SOC has multiple modes of operation characterized by clocking schemes, reset sequences, and mode
controls. Functional setup requires the design to be set up in functionally valid modes for verification, by
proper identification of clocks, resets, and mode-select pins. Bad setup can lead to poor quality of verification
results or incomplete verification.
Correct functional setup of large designs may require setup of a large number of signals. Meridian CDC allows
users to import a top-level SDC file, and automatically extracts and derives environment setup files for lower-
level blocks. Not only does this ensure correct functional setup, it also reduces the manual effort required to
set up the environment for lower levels of the design hierarchy, where formal analysis runs more efficiently. Be
sure to examine the generated environment file to make sure all clock, reset, and constant specifications are
correct and complete.
2. Meridian setup checks

Meridian CDC performs setup checks to ensure that clocks and resets will be correctly propagated to the flops,
and that there is no conflict between the environment setup and the actual design. The setup analysis is
automatically performed using the analyze_intent command. You might need to refine the setup or fix the
design, if there are any violations reported in the setup categories.
3. Meridian structural analysis

It is important to understand Meridian CDC structural analysis results and fix all relevant issues before
performing formal analysis. Meridian CDC offers debugging capabilities to help pinpoint the errors and
minimize the debugging effort. The structural analysis report is carefully organized to offer important and
relevant information, with explanations.
4. Meridian formal analysis

Though structural analysis can identify all potential structural errors in the design, it does not check for
CDC-related functional errors. Formal analysis can precisely identify CDC-related functional failures in the
design. Traditional formal analysis, such as equivalence checking and property verification, is built to analyze
steady-state design behavior. Hence, these formal techniques are incapable of formally analyzing certain
behavior because of metastability and glitches. Special formal analysis techniques that are capable of handling
behavioral uncertainty are needed for CDC applications. The computational complexity of formal analysis is
very high, and can require a large amount of computation time. Early detection provides significant savings in
the overall debugging and sign-off cost, and ensures a robust design.
Meridian CDC supports following two types of formal analysis

a. Full Formal Analysis

b. Local Formal Analysis
Note: Meridian CDC formal analysis is not available with a Meridian FPGA license.

Full Formal Analysis

In full formal analysis, Meridian CDC performs a complete analysis of the sequential design over a period of many clock
cycles, specified by the user, and performs the following checks.
Formal Analysis Check Description

Gray code check Checks that FIFO-related reonvergent control signals are Gray-coded
Data stability check Checks for safe data crossings across asynchronous clock domains
Formal glitch check Checks that there is no glitch in the combinational circuit that can cause an
incorrect value to be captured at the receiving domain
Pulse width check Checks that control crossings are held long enough to be sampled at the receiving
domain
Full formal analysis verifies the functional aspects of signals that cross asynchronous clock domains. The analysis
comprehensively considers all
combinational and sequential logic interactions to ensure that data is captured correctly and that problems, such as
loss of correlation, information loss, and glitches, do not materialize. In theory, one could write SVA assertions to check
for such failures, but the process would be imperfect, inefficient, and
cumbersome. Meridian CDC builds internal formal models for such checks that are precise and efficient. The reporting
of these checks is tied in the
debugger to the precursor structural analysis to enable an intuitive and holistic sign-off process.
Meridian CDC full formal analysis is optional if your CDC sign-off flow is based solely on structural analysis.
Nevertheless, it is highly recommended that you run full formal analysis as a backstop to structural analysis. Apart
from enhancing confidence in certifying the crossings, it has the ability to find
complex metastability-related bugs caused by functional errors (state-machine bugs, logic errors, and so on) that
structural analysis is incapable of detecting.
Meridian CDC full formal analysis is backed by state-of-art multicore-parallel formal engines. It is supported by a full-
featured debug capability, including
waveform generation and RTL+schematic cross-probing capability. It has the ability to find complex bugs involving long
traces and to complete almost all
checks either as an exhaustive or sufficiently-deep proof of correctness.
The advantage of full formal analysis is that tool does a full sequential analysis of the design, resulting in an accurate
analysis. Full formal analysis is run using the verify_cdc_formal command.
IMPORTANT: In order to get accurate results, you must specify correct clock frequencies in the ENV or SDC file (read in
using the read_sdc or read_env command).
When Meridian CDC formal analysis is completed, verification results are added to the Meridian CDC structural analysis
report, thus providing a composite report with a complete view of the verification status. A summary table provides
a quick overview of formal analysis performance. Detailed results (status and information) appear in iDebug in the
FormalStatus column of the DATA, CNTL, GRAY_CODE_CHECKS, and W_GLITCH rules.
Meridian CDC formal analysis could result in the following statuses:
• Passed
Meridian CDC’s formal analysis has exhaustively verified that no failing conditions exist for the formulated
check. No user action is needed when a check passes.
• Failed

A vector sequence (VCD trace) was generated that shows the violation of the formulated check. Use iDebug
to view the VCD trace, the schematic, and the design source. Fix the issues and rerun Meridian CDC formal
analysis to make sure the design is behaving as desired.
• Bounded
The analysis complexity was too high to generate a definite result within the specified number of clock cycles
(default is 50). You can increase the number of clock cycles analyzed by specifying the verify_cdc_formal -
max_clock_cycles command argument, which might result in definite results for some of the bounded status.
Also user can modify the -effort level on verify_cdc_formal command and change it to hard-pass or hard-fail.
• Unprocessed
The total run time was insufficient, if specified using the verify_cdc_formal -time_limit command argument
(default run time is unlimited). As a result, formal verification of the formulated check was not attempted.
Rerun incrementally using a larger value for the -time_limit command argument. Meridian CDC resumes formal
analysis from the previously saved results.
• Skipped-Option
Formal analysis was not run either because you told Meridian CDC not to run certain checks (skipped by
user) or Meridian CDC could not perform formal analysis on this check (skipped by tool). Typical reasons that
Meridian CDC skips certain checks include crossings from/to non-flop objects and crossings from/to flops with
no clocks or with multiple clocks. Below is the list of reasons why the formal run is skipped:
• Setup
Engine cannot support the crossing owing to internal setup problems.
• Loop
Fanin cone of the crossing has a static loop that cannot be processed.
• Latch
A latch is present between the transmit and receive flops.
• User
Removed by the user, either through iDebug Engine Actions or variable settings.
• Read-RAM
Formal analysis supports only crossings that are incoming.
• Fast-to-Slow
Pulse width check is skipped because it is covered by fast-to-slow gray code conversion.
• Flop-Multiple-Clocks
Flop is sensitive to multiple clock domains.
• Flop-Is-A-Constant
Receiving flop has a constant value.
• Flop-Input-Unknown-Domain
Some or all inputs of the receiving flop have setup issues. See the MCDC_SETUP_CHECKS rule group
(CDC Checks).
• Flop-Input-Sync-Domain
All the inputs of the receiving flop are coming from the same clock domain as the receiving flop.
• By-Tool
Meridian CDC does not support this check.
• Not-In-W-GlitchCheck
Flop is not part of W_GLITCH violation.
• Unsupported
Meridian CDC does not support this check.
• Option
Checks are not enabled by Tcl variable (when ri_verify_data_stability, ri_verify_gray_codes,
ri_verify_cntl_glitches, ri_verify_pulse_widths are set to false).
• Bit
The check is performed on a bit level, as per variable settings (when ri_verify_one_data_bit_per_bus
and ri_verify_one_cntl_bit_per_bus variables are set to true).


Gray Code Check

Gray code is used on asynchronous interfaces so multibit signals do not change value simultaneously, thus eliminating
potential loss of correlation. Meridian CDC can automatically detect FIFO-related reconvergent control signals across
asynchronous clock domains and apply formal analysis to ensure that these signals are Gray-coded. When Meridian
CDC detects a condition that violates Gray encoding (FormalStatus = Failed), it generates a VCD trace to assist in
debugging.
In iDebug, the GRAY_CODE_CHECKS rule in the MCDC_ANALYSIS_CHECKS rule group displays control signals requiring
Gray-code checks. Formal analysis status appears in the FormalStatus column. VCD traces appear in the Info column.
The following figure shows a Gray code failure where rdptr changes from 2 (010) to 7 (111), resulting in two bits
changing at the same time.
Once the fix to the design has been applied, the next formal analysis shows GRAY_CODE_CHECKS FormalStatus =
Passed.

(Note: To turn off Gray code checking, set variable ri_verify_gray_codes to false.)

Data Stability Check

Meridian CDC automatically detects data crossings in the design and performs formal analysis to ensure these data
crossings are multicycle paths (MCPs). Meridian CDC’s data stability check formulation goes to the root cause of a data
metastability problem to verify that data launched in the transmit clock domain is not captured by the next edge of
the receive clock domain (that is, when the data path is an MCP).
MCP formulation implicitly covers all functional protocols and offers the best solution compared to other approaches
that attempt to generate assertions based on structural identification of data crossing protocols, which can
be prone to error. By default, Meridian CDC checks to make sure that data is stable for two clock cycles of
receive clock when crossing the clock domain boundary. You can specify a different length for the MCP using the
ri_xing_mcp_cycles variable. Formal analysis of data stability is not turned on by default. To enable this check, set the
ri_verify_data_stability variable to true.
Before running Meridian CDC formal analysis for data stability, examine the Meridian CDC structural report to ensure
that all signals identified as Data are indeed data signals. You can use the reclassify feature in Real Intent iDebug to
correct any incorrect classifications.
Data stability check results are reported in the FormalStatus column under the DATA rule in the
MCDC_ANALYSIS_CHECKS rule group.
When Meridian CDC detects a condition that violates a multicycle path of data crossings (FormalStatus = Failed), it
generates a VCD trace to assist in debugging. The VCD trace appears in the Info column.
The following figures shows an example of data stability failure where xmitData from the transmitting clock domain is
sampled and received at the next receiving clock edge, signal rcvDataOut.
Meridian CDC skips the data stability check if any of the following conditions is true:
• The transmitting signal is neither a flop, nor an input with a create_input spec, nor a RAM pin.
• The transmitting flop is not clocked correctly; for example, there is no clock waveform.
• There are latches in the logic between the sending signals and the receiving flop.
• The read address is asynchronous to the read clock for RAMs.
• The crossing is from the read side of one RAM to the write side of another RAM.

For these situations, "Skipped-Option" appears in the FormalStatus column and “By-Tool” appears in the Info column to
indicate that Meridian CDC skipped these checks.

Formal Glitch Check

Meridian CDC structural analysis reports combinational signals going across asynchronous clock domains as W_GLITCH:
These signals have glitch potential. Meridian CDC formal analysis checks to see if there can be a true glitch in the
combinational logic between the transmit flops and the receiving flop, which can cause an incorrect value to be
captured at the receiving flop.
Formal analysis results appear in the FormalStatus column for the W_GLITCH rule results in the
MCDC_ANALYSIS_CHECKS rule group. If Meridian CDC formal analysis detects a failure condition, a VCD trace is
generated showing the error condition. The VCD trace appears in the Info column.
In the VCD trace, at least one of the transmit flops has a transition to cause a glitch and the receiving flop does not
transition at the captured (last) receiving clock edge.
Meridian CDC skips the formal glitch check if any of the following conditions is true:
• The transmitting signal is neither a flop, nor an input with a create_input spec.
Note: Formal glitch check is run by default. To turn off formal glitch check, set the ri_verify_cntl_glitches variable to
false.

Pulse Width Check

For all control crossings between the transmit flop and the receiving flop, such that the frequency of the transmit
clock is faster than the frequency of the receiving clock, Meridian CDC formal analysis verifies whether it is possible
for a pulse from the transmit domain to be missed at the receiving domain because the receiving clock is too slow.
In other words, the pulse width on the transmit flop is too small to be captured. Formal analysis results appear in
the PulseWidth column for the CNTL rule results in the MCDC_ANALYSIS_CHECKS rule group. If Meridian CDC detects a
failute, a VCD trace is generated. The VCD trace appears in the Info column.
Failure conditions include a scenario in which the pulse width of the control crossing is equal to or smaller than the
cycle width of the receiving clock. The VCD trace will show the pulse being propagated through the receiving domain
(see picture below), even though there is a probability that the pulse might not be captured in reality, hence the
pulse-width failure.
For control signals going from slow to fast clock domains, this check passes trivially.
Meridian CDC skips the pulse width check if any of the following conditions is true:
• The transmitting signal is neither a flop, nor an input with a create_input spec.
• The receiving flop is part of a fast-to-slow gray encoding check.
• Any of the transmitting signals are synchronous to the receiving flop.
• Receiving flops are sensitive to multiple clock waveforms.
Note: Pulse width check is run by default. To turn off the pulse width check, set the ri_verify_pulse_widths variable to
false.

Frequency-Independent Formal Analysis

Meridian CDC supports the ability to perform formal analysis assuming all clocks are free running with no frequency
or phase correlation. This feature is helpful when clocks function within a frequency range, rather than at a
particular frequency point. Instead of performing formal analysis at various operating conditions, you can set the
ri_use_free_running_clocks variable to true to enable Meridian CDC to perform formal analysis assuming all the clocks
are free running. This feature can uncover additional errors and ensure CDC correctness under all operating conditions.

Local Formal Analysis

Local formal analysis is a mixture of combinational analysis and restricted sequential analysis over a typical duration
of a few clock cycles. Because local formal analysis limits the sequential depth of the design, it is significantly faster
than full formal analysis. You can catch design errors relatively quickly with a lower overhead of memory and runtime
relative to structural analysis. For most cases, the local formal analysis flags real violations; but in some complex
cases where proving the condition requires full sequential analysis, local formal analysis can report results that require
further review.
In Meridian CDC, local formal analysis can be used to identify controlling conditions for DATA crossings. Local formal
analysis is run when user runs verify_cdc command.
Controlling Condition for DATA crossing

When variable ri_identify_data_control_condition is set to true, Meridian CDC performs combinational or limited-
depth-sequential formal analysis to identify the controlling condition for the DATA crossings. This analysis reports one
of the following status strings, appearing in the INFO column for each DATA crossing.
Data-Control-NonBlock
The synchronizers do not have a condition that can block the transfer of transmitting data. This status is conclusive.
Following figure shows an example of this. In this when TxData can transfer to RxData and Sync Control would not be
able to block it. Blocking condition is based upon identification of Hold condition for Receive flop NonBlock will be flagged
if the hold condition was not identified or the hold condition is not dependent upon synchronizers.
Data-Control-ByPass
This status means that there exists a combination of non-synchronizer Rx domain flops that can enable the data transfer
from TX flop(s) to receive flop. This status requires further review to determine whether the condition identified on
the receiving domain logic is valid (reachable). Following figure shows an example of this. In this when x_signal is
“1”, TxData can transfer to RxData and Sync Control would not be able to block it. Note that x_signal is driven from
RxDomain

Data-Control-Complex
Meridian CDC could not complete the combinational or limited-depth-sequential analysis to identify a blocking
condition.
Data-Control-Unprocessed
Meridian CDC did not perform this analysis because of the design style.
Data-Control-Pass
Meridian CDC identified a condition on the synchronizer that blocks the transfer of the transmitting data. The
identified condition is recorded in the .dbg file for this DATA crossing. This status requires further review to determine
whether the identified condition on the synchronizer is valid (reachable). The following figure shows an example of
this, where the Sync Control blocks the transfer of Data when it is 0.
DATA crossings that have status of Data-Control-NonBlock, Data-Control-ByPass, Data-Control-Complex, or Data-

Control-Unprocessed are listed in the W_DATA category as well. Examine these crossings to make sure the crossing
interface is correct.

Meridian CDC Debugger

Meridian CDC debugger, iDebug, allows users to cross-probe between Meridian CDC report, schematic view, RTL source,
and VCD waveforms to assist in debugging. Alternatively, Meridian CDC can also generate text reports, which you can
view using any text editor; however, the recommended utility is iDebug. You can run iDebug using the Graphical User
Interface (GUI) or the Command-Line Interface (CLI).
For more information about iDebug, you can launch 'idebug -doc' from your UNIX shell, or click Help -> iDebug HTML
Doc in the iDebug window.

Converting SDC Commands to ENV Commands

Meridian CDC can take an SDC file as input and extracts relevant clock and constant information for environment setup.
Recognized SDC commands and their equivalent ENV commands are as follows.
SDC Command Equivalent ENV Command(s)

create_clock create_waveform, create_clock
create_generated_clock create_derived_waveform, create_clock
set_case_analysis set_constant
set_input_delay create_input
set_output_delay create_output
You must set ri_translate_set_output_delay to true for translation of set_output_delay; the set_output_delay command
is not translated by default.
In addition to the commands shown, set_false_path and set_clock_groups are used to help determine whether clocks
are synchronous or asynchronous. Clocks specified using set_clock_groups -asynchronous and set_false_path are written
to the output ENV file as asynchronous clocks. Only following types of set_false_paths commands are used for CDC
analysis
• set_false_path -from [get_clocks ...]

• set_false_path -to [get_clocks ..]
• set_false_path -from [get_clocks ..] -to [get_clocks ..]
Rest of the SDC commands are ignored for CDC analysis. Also see following related variables
• ri_sdc2env_ignore_set_clock_groups
• ri_sdc2env_ignore_set_false_paths
• ri_sdc2env_make_all_clocks_async
• ri_use_logically_exclusive_as_async
• ri_use_physically_exclusive_as_async
• ri_use_unidir_clk2clk_sfp_as_async

create_clock Conversion
All SDC clocks are considered synchronous by default in Meridian CDC. By default set_clock_groups -asynchronous
command is used to define asynchronous relationships. In addition to that following variables control asynchronicity
• ri_sdc2env_ignore_set_clock_groups
• ri_sdc2env_ignore_set_false_paths
• ri_sdc2env_make_all_clocks_async
• ri_use_logically_exclusive_as_async
• ri_use_physically_exclusive_as_async
• ri_use_unidir_clk2clk_sfp_as_async
SDC create_clock commands are translated to create_waveform and create_clock commands according to the following
table.
create_clock create_waveform/create_clock
-period <period> -period <period> for create_waveform
-name <waveform_name> <waveform_name> for create_waveform
-waveform <edge_list> -transitions <edge_list> for create_waveform
-add Meridian CDC translates both clock specifications; however, one must be
chosen to avoid setup analysis violations. Translates to a commented out
create_clock command when anothe create_clock command exists on the
specified net/port
<source_objects> <source_objects> for create_clock
Example 1
SDC Command:
create_clock -name CLK1 -period 20 [get_ports clk1]
ENV Command:
create_waveform -period 20 -transitions {0 10} {“CLK1”}
create_clock -waveform {“CLK1”} {“clk1”}
Example 2
SDC Command:
create_clock -name CLK1 -period 20 -waveform {8 12} [get_ports clk1]
ENV Command:
Example 3
SDC Command:
create_clock -name CLK2 -period 20 [get_ports clk1] -add
ENV Command:


#create_clock -waveform {“CLK2”} {“clk1”}

create_generated_clock Conversion
SDC create_generated_clock commands are translated to Meridian CDC create_derived_waveform/create_clock
commands according to the following table.
create_generated_clock create_derived_waveform/create_clock
-add Creates a commented out command when another exists on the specified
net/port
-name <waveform_name> <waveform_name> for create_derived_waveform
-source <master_pin> -parent <master_pin> for create_derived_waveform
-edges <edge_list> -edges <edge_list> for create_derived_waveform
-invert -inverted for create_derived_waveform
-edge_shift <list> -offset edge_shift_list[0]; only the first edge shift is used
-divide_by <factor> -divide_by <factor> for create_derived_waveform
<source_objects> <source_objects> for create_clock
-master_clock <clock> Not supported
-duty_cycle <percent> Not supported
-multiply_by <factor> -multiply_by <factor> for create_derived_waveform
-combinational The only logic for this clock is combinatorial logic in the domain of the
master clock.
-pll_output <output_pin> Not supported
-pll_feedback Not supported
<feedback_pin>
Example 1
SDC Command:
create_generated_clock -name GEN_CLK -source [get_ports clk1] -divide_by 2 [get_pins aCell/
Q]
ENV Command:
create_clock -waveform {“CLK1”} [get_ports clk1]
create_derived_waveform -parent {“CLK1”} -divide_by 2 {"GEN_CLK"}
create_clock -waveform {“GEN_CLK”} [get_pins aCell/Q]
Example 2
SDC Command:
create_clock [get_ports master_clock] -name master_clock -period 10 -waveform {0 5}
create_generated_clock [get_pins {test/testclk}] -name derived_clock -source [get_ports
master_clock] -master_clock master_clock -divide_by 1
ENV Command:
create_waveform -period 10 -transitions {0 5} {“master_clock”}
create_derived_waveform -master {“master_clock”} -divide_by 1 {"derived_clock"}
create_clock -waveform {“master_clock”} {“master_clock”}
create_clock -waveform {“derived_clock”} {“derived_clock”}

Example 3 - with set_clock_groups

SDC Command:
set_clock_groups -asynchronous -group [list[get_clocks master_clock]] -group
[list[get_clocks derived_clock]]
ENV Command:
create_waveform -period 10 -transitions {0 5} {“derived_clock”}
Example 4 - with set_false_path

SDC Command:
set_false_path -from [get_clocks master_clock] -to [get_clocks derived_clock]
ENV Command:
create_waveform -period 10 -transitions {0 5} {“derived_clock”}

set_case_analysis Conversion
SDC set_case_analysis commands are translated to Meridian CDC set_constant commands according to the following
table.
set_case_analysis set_constant
<value> -value <value>; only values of 0 or 1 are translated
<port_pin_list> <port_pin>
Example 1
SDC Command:
set_case_analysis 0 [get_ports portA]
ENV Command:
set_constant -value 0 [get_ports portA]
Example 2
SDC Command:
set_case_analysis 1 [get_ports portA port B]
ENV Command:
set_constant -value 1 [get_ports portA]
set_constant -value 1 [get_ports portB]
Example 3
SDC Command:
set_case_analysis rising [get_ports portA]
set_case_analysis falling [get_ports portA]
ENV Command: None. Rising and falling cannot be translated.
Example 4
SDC Command:
set_case_analysis 0 [get_ports {select[0]}]
set_case_analysis 1 [get_ports {select[1]}]
ENV Command:
set_constant -value 0 [get_ports {select[0]}]
set_constant -value 1 [get_ports {select[1]}]

set_input_delay Conversion
SDC set_input_delay commands are translated to Meridian CDC create_input commands according to the following
table.
set_input_delay create_input
-clock <waveform_name> -waveform <waveform_name>
-clock_fall -fall
<port_pin_list> <port_pin_list>
-reference_pin -waveform <waveform_name>
<port_pin_name>
-level_sensitive Not applicable
-rise Not applicable
-fall Not applicable
-max Not applicable
-min Not applicable
-add_delay Not applicable
-network_latency_included Not applicable
-source_latency_included Not applicable
<delay_value> Not applicable
Example 1
SDC Command:
set_input_delay 10 -clock [get_clocks CLKA] [get_ports portA portB]
ENV Command:
create_input -waveform {"CLKA"} {portA portB}
Example 2
SDC Command:
set_input_delay 10 -reference_pin [get_ports clockAPort] [get_ports portA portB]
ENV Command:
Example 3
SDC Command:
set_input_delay 8 -rise -min -clock [get_clocks CLKA] [get_ports portA portB]
set_input_delay 10 -rise -max -clock [get_clocks CLKA] [get_ports portA portB]
set_input_delay 5 -fall -min -clock [get_clocks CLKA] [get_ports portA portB]
set_input_delay 15 -fall -max -clock [get_clocks CLKA] [get_ports portA portB]
ENV Command:
Example 4

SDC Command:
set_input_delay 10 [get_ports portA portB]
Env Command: None. No clocks have been defined.
Example 5
SDC Command:
set_input_delay -clock CLK1 [get_ports in]
ENV Command:
create_waveform -period 20 -transitions {0 10} CLK1
create_input -waveform {"CLK1"} {in}

set_output_delay Conversion
SDC set_output_delay commands are translated to Meridian CDC create_output commands when
ri_translate_set_output_delay is set to true (default is false). Meridian CDC’s handling of set_output_delay commands
is the same as for the set_input_delay conversion.
Example 1
SDC Command:
create_clock -name CLK1 -period 20 [get_ports clk1] set_output_delay -clock CLK1 [get_ports
out]
ENV Command:
create_waveform -period 20 -transitions {0 10} CLK1
create_output -waveform {"CLK1"} [get_ports out]

set_false_path and set_clock_groups Conversion

The SDC to ENV behavior is affected by the following factors:
• whether there is a set_clock_groups command in the SDC file

• whether there is a set_false_path command in the SDC file
• whether the user instructs create_env_file command to ignore set_clock_groups commands in the SDC file
• whether the user instructs create_env_file command to ignore set_false_paths commands in the SDC file
The following table describes the behavior with respect to the desired clock relationships in all combinations of the
above factors.
SDC has no SDC has only SDC has only SDC has both
set_clock_groups set_clock_groups set_false_path set_clock_groups
or set_false_path commands commands and set_false_path
commands commands
Clocks are Clocks are Clocks are Clocks are
asynchronous synchronous, except synchronous, except synchronous, except
those annotated by those annotated by those annotated by
set_clock_groups - set_false_path set_clock_groups -
asynchronous asynchronous and
set_false_path
N/A; clocks are set_clock_groups are N/A; clocks are Clocks are
asynchronous ignored; clocks are synchronous, except synchronous, except
asynchronous those annotated by those annotated by
set_false_path set_false_path
N/A; clocks are N/A; clocks are set_false_path Clocks are
asynchronous synchronous, except ignored; clocks are synchronous, except
those annotated by asynchronous those annotated by
set_clock_gropus - set_clock_gropus -
asynchronous asynchronous
N/A; clocks are set_clock_groups are set_false_path set_clock_groups and
asynchronous ignored; clocks are ignored; clocks are set_false_path are
asynchronous asynchronous ignored; clocks are
asynchronous

Recommended Order of Review

The Meridian CDC debugger, iDebug, shows the violations in the order they should be reviewed.
The review steps that enable CDC signoff of your designs include Intent Analysis Signoff and Structural Analysis Signoff,
as described below.
Intent Analysis Signoff

This step helps with signoff on the design environment for verification. These checks appear under the rule group
MCDC_SETUP_CHECKS. Rules are classified in the following categories.
Category Description
• ERROR Rule violations with severity ERROR
• WARNING Rule violations with severity WARNING
• REVIEW Rule violations with severity MINOR
Browse and confirm that these rule checks match your design CDC intent.
• INFO These are not rule violations; just informational messages to aid debug.
The recommended debug order is as follows:

1. ERROR > WARNING > REVIEW
2. Glance at rule checks in the INFO category
Structural Analysis Signoff

This step helps with signoff on the structural analysis. These checks appear under the rule group
MCDC_ANALYSIS_CHECKS. Rules are classified in the following categories.
• ERROR Rule violations with severity ERROR
• WARNING Rule violations with severity WARNING
• REVIEW Rule violations with severity MINOR
Browse & confirm that these rule checks match your design CDC intent.
• INFO These are not rule violations; just informational messages to aid debug.
The recommended debug order is as follows:

1. ERROR > WARNING > REVIEW
2. Glance at rule checks in the INFO category
Detailed steps for Structural Analysis Signoff are as follows:

1. Review and debug crossings errors - W_CNTL,W_DATA,W_ASYNC_RST_FLOPS
2. Review and debug reconvergence errors - W_FANOUT,W_RECON_GROUPS,W_RST_UNCERTAINTY
3. Review miscelleanous crossing errors - W_GLITCH, W_HALF, W_CLK_RECON, W_G_CLK_GLITCH, W_D_CLK_GLITCH
and so on.
4. Review and debug issues related to associations
a. W_INTERFACE - Review. Save RxFlops for running full formal Data Stability
b. Run Local Formal - Review local formal failures. Save RxFlops for running full formal Data Stability
c. Review INTERFACE - Save RxFlops for running full formal Data Stability
5. Run full formal checks
a. Gray Code Checks on FIFO crossings
b. Pulse Width Check on CNTL Crossing
c. Glitch checks on selected CNTL Crossings
d. Data Stability on selected RxFlops

Command Reference
This chapter has information about all the commands supported by Meridian CDC.

DESIGN Compilation Commands

Real Intent supports Verilog, SystemVerilog, VHDL, and mixed-language designs. Real Intent tools automatically
recognize standard file extensions, including .v for Verilog 2001, .sv for SystemVerilog, and .vhd for VHDL. Language
Support provides a high-level overview, and then discusses special topics for Verilog, SystemVerilog, and VHDL
languages.
Design Read-In
In Real Intent tools, the two steps for reading in the design using a control file are analyze and elaborate.
1. The analyze command parses design files and resolves libraries.
2. The elaborate command builds the design hierarchy, checks semantics, and builds an internal netlist model.
Note: In some cases, library cells need to be coverted to a Verilog model using the read_liberty command
before reading them in using the analyze command.
You can set the ri_search_path variable to specify the search path and search order for source files, library files,
and include files when they are not found elsewhere. For include files, the search path is, in this order, the current
directory, the +incdir+ directory, followed by the paths specified by this variable. For unresolved modules and source
files, the search path is, in this order, the files specified by -v, in the directories specified by -y, followed by the paths
specified by this variable.
You can set the ri_vy_lib_accumulate variable to change the library resolution procedure so that Meridian CDC will
resolve all unresolved modules at the beginning of the elaborate command instead of during the analyze command.
All libraries specified in each analyze command are accumulated into one library list. Using this variable may change
library resolving behavior. You can look in the log file for messages that indicate how modules were resolved.
Additionally, pragmas in the design can impact compilation. See Attribute and Pragma Support for more information.
Below is a sample run script, with complete details of design setup and configuration.

## set the search path for RTL source files +incdir+src
/home/myblock/rtl] -v2k
design_top.v
## read in technology-specific library cells -sverilog
read_liberty [list /home/technology/memory/memory.lib \ async_fifo.v
/home/technology/clk_gen/pll.lib] or_dc.v
or_ic.v
## analyze all the RTL source files clock_gen.v
## elaborate the design

## generate messages related to design

report_messages -output design_messages.txt
Compilation Log File

The compilation log file provides details of the entire run, including the reading in of the design. The header of the log
file contains product version information, run time information, the working directory, the project directory, variables

set from the .realrc file, and the commands executed from the control file. In addition, there are many messages in
the log file that track what the tool is doing, and there is a compilation summary at the end.
Log file messages consist of a severity, an ID, and the message. The message ID identifies the message. The severity is
one of INFO, ERROR, and WARN, where:
• INFO is for informational purposes only. Messages include information on what file is being analyzed, which file
is being included, the top level of the design to elaborate, blackboxing, etc. No action is required, though the
information can be helpful for determining such things as how libraries were resolved.
• WARN is a non-critical issue that should be reviewed. Most of the warned constructs, identifiers, or actions are
ignored. A WARN will not cause the tool to stop.
• ERROR is an issue that will prevent further progress and needs to be corrected.
Some message severities can change depending on options or variable settings. For example, the -auto_black_box option
will change a missing module error to a warning.
Some example messages are shown below:
INFO [#19013] : on line 2 in file test.v

: Module "mux21" is being created as black box
WARN [#25010] : on line 58 in file test.v
: Signal "wire4" of module "test" does not affect the output
Undesired messages can be suppressed using a Tcl command in the control file or in the .realrc file:
set ri_suppress_msg { 19013 25010 }
where the argument is a list of message IDs that you want to have suppressed.
In some cases, additional help is provided from the Meridian CDC shell for a message ID:
prompt>> help 25010
**> help 25010
25010: Signal <signalname> of module <modulename> does not affect the output
The named signal is declared and may be assigned a value, but it does not drive logic that affects at least one output
port. If this code is meant for debugging, this may be acceptable, however the user is encouraged to investigate the
causes of the warning to ensure the design behaves as intended.
By default, full paths are used to reference filenames in the log file. When relative paths are used to reference the design
files provided to the analyze command, you can request the use of relative paths in messages by setting the variable
ri_abs_file_name to false. This can significantly reduce the size of the log file and make messages easier to read.

analyze
Analyze the given HDL source files and store them in the specified libraries for elaboration.
The analyze command is used to parse the design files and resolve libraries. You can have one or more analyze
commands in a control file. Each analyze command has its own options, such as design files, define macros, included
files, library files and directories, and so on. This information does not pass to the next analyze command by default.
The analyze command accepts most of the switches that are common across simulation tools, such as -f,-v,-y,
+incdir+,+define+, and so on.
All specified design files are analyzed even when errors exist. If errors do occur, Meridian CDC will exit before
elaboration to give you a chance to correct errors.
SYNTAX
string analyze
-- Common Options
<files> | -file <file_name> -F <file_name>
[-skip_files <skip_files>]
[-format <file_format>]
[-work <work_libname>]
[-ignore_translate_off <vendors>]
[-ignore_pragma_vendors <vendors>]
[-ignore_read_comments_as_hdl]
-- Verilog options
[-v95 | -v2k | -sverilog | -sv05 | -sv09]
[-v <ref_files>] ...
[-y <ref_dirs>] ...
[+define+DEFINE+] ...
[+incdir+INCDIR+] ...
[+libext+LIBEXT+] ...
[-libmap <file_name>]
[+liborder]
[+librescan]
--VHDL options
[+propfile+PROPFILENAME] ...
[-psl]
Data Type
files list
vendors listce, synopsys, pragma,
synthesis, verific,
LV_BIST, spyglass, 0-in,
and magma
file_name string
file_format string
work_libname string
skip_files list

ref_files list
ref_dirs list
ARGUMENTS
<files>
List of RTL files to analyze. Multiple RTL files can be included on the line by giving a space-separated
list enclosed within curly braces {} For wildcard expansion, use the Tcl glob command; for example,
analyze [glob *.sv].
-f <file_name>
Specifies the name of the file that provides the all the RTL files and related options to be analyzed.
You can provide multiple -f options and you can nest file lists.
In this example, files.list1 and files.list2 are two text files that contain the path to the source code
for the project. Within the filelist, you can use “//” or “#” for one line comments. Shell environment
variables can be used in the content of the file but not Tcl variables. You can also use language
specification options. The switch, "-f”, is used to specify the name of the file. An example files.list is
as follows:
+incdir+src
-file nested.file.list
-sverilog # subsequent file will be SystemVerilog
./src/async_fifo.v
./src/or_dc.v
-v2k # subsequent files will be v2K
./src/or_ic.v
./src/design_top.v
This is a simple files.list from a Verilog design. The first line in the files.list contains the +incdir+
option which allows users to specify directories that contain files specified in the source code with
the ‘include compiler directive. The second line includes another file list. The third line directs
that the subsequent files should be interpreted as SystemVerilog. This is overriden by the -v2K three
lines down. As a result, async_fifo.v and or_dc.v are interpreted as SystemVerilog and or_ic.v and
design_top.v are interpreted as v2K files. You can use any number of analyze options inside the
files.list.
VHDL option: If the [-work working_library_name] option appears on the same line or next line, after
the RTL file name in filename, the analyzed RTL file is stored in the working_library_name library.
When a variable is used in the filelist file, you can set the environment variable from within the
control file so it will not affect other processes by:
global env
set ::env(WORKDIR) ./ethmac/rtl/verilog
-F <file_name>
Specifies the name of the file that provides the RTL files and related options to be analyzed. All files
are searched relative to the location of <file_name>. A -f arguments file can contain -F options.
All file references from a -F file will show full path names in logfile references, independent of
ri_abs_file_name setting.
-skip_files <skip_files>
Specifies the name of one or more files to be skipped.

[-ignore_pragma_vendors {vendor1 vendor2 ..}]

This tells Meridian CDC to ignore all pragmas contained within the listed filenames. By default,
Meridian CDC respects all pragmas in order to verify the same functionality that synthesis will
produce. This switch allows you to override this default behavior for the listed files only. Other
analyze commands are unaffected. Allowed vendor identifiers include cadence, synopsys, pragma,
synthesis, verific, LV_BIST, spyglass, 0-in, and magma.
[-ignore_translate_off {vendor1 vendor2 ..}]

This tells Meridian CDC to ignore all synthesis translate pragmas contained within the listed filenames.
This includes both "synthesis off" and "translate off" pragmas. By default, Meridian CDC respects all
synthesis pragmas in order to verify the same functionality that synthesis will produce. This switch
allows you to override this default behavior for the listed files only. Other analyze commands are
unaffected. Allowed vendor identifiers include cadence, synopsys, pragma, synthesis, verific, LV_BIST,
spyglass, 0-in, and magma.
[-help]
Prints the online help for this command.
****** Verilog/SystemVerilog Only Options ******
[-v filename or {filename filename ...}]

Specifies the name of the Verilog or SystemVerilog file(s) to be treated as source library files. These
files may contain one or more module definitions. Minimally, the top level source file is required
on the analyze command. Any unresolved modules that are not specified on the command line are
resolved from the source library files. Multiple source library files may exist on one command line,
including source libraries specified using the -y option discussed below.
Resolution of unresolved modules is done by searching the source files listed for that analyze
command, followed by the source library files in the order they are listed on the command line,
followed by the paths specified by the variable ri_search_path. For each analyze command, the first
source library file is compiled into the tool library, overriding previously compiled modules of the same
name from previous analyze commands .
By default, specification of a source library file applies only to the local analyze command. The
variable ri_vy_lib_accumulate can be set to true to accumulate library files across analyze commands.
[-y directory]
Specifies the Verilog or SystemVerilog source library search path. The name of the library file must
have the format <module_name>.<libext>, where <module_name> is the name of the module and
<libext> is defined by the +libext+ option. Multiple source library files may exist on one command line,
including source libraries specified using the -v option discussed above.
Resolution of unresolved modules is done by searching the source files listed for that analyze
command, followed by the source library files in the order they are listed on the command line,
followed by the paths specified by the variable ri_search_path. For each analyze command, the first
source library file is compiled into the tool library, overriding previously compiled modules of the same
name from previous analyze commands.
By default, specification of a library applies only to the local analyze command. The variable
ri_vy_lib_accumulate can be set to true to accumulate library paths across analyze commands.
[-ignore_read_comments_as_hdl]

This tells the analyzer to ignore all read_comments_as_hdl pragmas contained within the listed
filenames. By default, all such pragmas are reported. This switch allows you to override this default
behavior for the listed files only. Other analyze commands are unaffected.
[+define+arg ...]
Specify Verilog preprocessor define variables. This option is similar to the +define+ option available on
many Verilog simulators. This option can be included in the files list as a +define+ entry. The following
forms are accepted for this option:
+define+varname
+define+varname=varvalue
These forms can be mixed within a single +define+ option and additional variables can be added by
separating the entries with a “+” as in the following example:
+define+TX_MODE+PKT_SIZE=64
The above command defines TX_MODE (no value is assigned) and it defines PKT_SIZE to a value of
64.
Note that +define arguments to the analyze command persist in subsequent analyze commands
when variable ri_incdef_accumulate is true. All defines are accumulated for library files
specified by -v or -y.
[+incdir+DIR]
Sets the include file directory search path. This option is similar to the +incdir+ option available in
many Verilog simulators. The option accepts a series of strings delimited by “+” signs that specify
the search path for include file directories. Any time a file is analyzed and has an ‘include command
contained within it, Meridian CDC will search this path for the named files. For example:
+incdir+/project/design/include+/usr/local/design/include
adds the two named directories to the Meridian CDC include file search path. This option can be
included in the files list as a +incdir+ entry.
Resolution of include files is done by searching, in this order, the current directory, the +incdir+
directory, followed by the paths specified by the variable ri_search_path.
Note that +incdir+ arguments to the analyze command persist in subsequent analyze commands
when variable ri_incdef_accumulate is true. All +incdir+ are accumulated for library files
specified by -v or -y.
[+libext+LIB_EXTENSION]
Specifies that Meridian CDC only search source files with the specified LIB_EXTENSION in the search
directories through the -y option. More than one extension can be specified by separation with the
“+”character.
[-libmap <file>]
An example library map file is:
library work ./src/config0.v;
library libtop ./src/top.v;
library lib2 ./src/ma.v;
The above file maps config0.v to library work, top.v to library libtop, and m0.v to library lib0, m1.v to
lib1, and ma.v to lib2. In this case, file config0.v is a SV configuration file:
config config0;

design libtop.top;
cell m liblist lib2 lib1 lib0;
endconfig
[+librescan]
Specifies that searching for unresolved modules always start from the beginning of the listed libraries.
[-v95]
Specifies that design files are in Verilog 95 language.
[-v2k]
Specifies that design files are in Verilog 2001 language. This is the default for verilog files
.
[-sv[erilog] | -sv05 | -sv09]
Specifies that design files contain System Verilog language or System Verilog Assertions. Either -sv or
-sverilog is recognized and the default is to support IEEE 1800-2009. Use -sv05 instead of -sv or -sv09
to override the version supported.
****** VHDL Only Options ******

[-work working_library_name]
Specifies the name of the working VHDL library. When the design is analyzed, the analyzed design is
stored in this library. The default VHDL library name is “work”.
****** Options for VHDL PSL ******

[-format <hdl>]
In most cases, the following standard file extentions are used for identifying the language used: .v for
Verilog, .sv for SystemVerilog, and.vhd or .vhdl for VHDL. When the RTL design file name contains
non-standard extension, use this option to specify the Hardware Description Language in which the RTL
code is written. Valid arguments are verilog for Verilog or System Verilog languages and vhdl for
VHDL language. Note that you may need to also specify -v95, -v2k or -sv05, or -sv/-sv09 to distinguish
the version of Verilog, and use of those options imply -format verilog. The only need for this option
is for VHDL.
[+propfile+filename]
Specifies the name of the external PSL VHDL property file that is associated with the current entity.
[-psl]
Reads in pragma form PSL constructs written in the VHDL RTL code. By default prompt> ignores the
PSL constructs. PSL is not supported in Verilog or SystemVerilog designs.
EXAMPLES
• Example-1 : Queries all clocks in the design
prompt> analyze -work WORK receiver.vhd
• Example-2 : Queries all generated clocks in the design

prompt> analyze -ignore_translate_off synopsys {transmitter.v main.v}
• Example-3 : Following command set propagated attribute on all clocks

prompt> analyze +incdir+../include -v {cpu_lib.v alu_lib.v} alu.v

• Example-4 : Following command create and exception between clkA and clkB
prompt> analyze -propfile alu.vunit alu.vhd
RELATED COMMANDS
elaborate
read_design_db
read_liberty
read_library_map
RELATED VARIABLES
ri_incdef_accumulate
ri_match_nc
ri_march_vcs
ri_search_path
ri_vy_lib_accumulate

Language Support
This topic describes the various languages supported by Meridian CDC. Meridian CDC is an RTL Lint tool designed to
run rules that check HDL designs for coding style, language construct usage, synthesizability, possible modeling errors,
dubious or possibly misleading modeling constructs, and conformance to subset and style restrictions.
Verilog, SystemVerilog, VHDL, and mixed-language designs are supported. Standard file extensions are automatically
recognized including .v for Verilog 2001; .sv for SystemVerilog; and .vhd for VHDL.
The analyze command options for language support include -format vdhl, -v95, -v2k, -sverilog, -sv09, -sv05

Verilog/SystemVerilog Support
Meridian CDC supports the entire Verilog 2001 standard by default and also supports the entire Verilog 1995 standard with
the -v95 switch. Support for the synthesizable subset of SystemVerilog 2005 is provided with the -sv05 switch. In addition,
many IEEE 1800-2009 SystemVerilog constructs are supported with either the –sv, -sv09, or –sverilog switch.Meridian
CDC supports the entire Verilog 2001 standard by default and also supports the entire Verilog 1995 standard. In addition
to design constructs, a rich set of assertion constructs are also supported - refer to
By default, the analyze command understands files with .v extension to contain Verilog 2001, files with .sv extension
contain SystemVerilog 2009 constructs. This default can be overridden by the -sv, -sv09, or -sverilog switch available
for the analyze command. When multiple switches are provided, a warning is issued and the newest version is used.
Processing is consistent with the standard. There exists two variables, ri_match_vcs and ri_match_nc that control non-
standard aspects consistent with VCS and NC simulators, respectively. Refer to the Variable Reference section for details.
Support is also included for user-defined primitives (UDPs) and other simulation-specific models when proper functional
models can be built. Non-synthesizable constructs such as initial, fork-join and event are ignored. Timing information
is also ignored since Meridian CDC performs zero-delay cycle-based analysis. Only connectivity is taken into consideration
in timing constructs. Meridian CDC also supports gate and switch level models that are applicable to digital analysis.
Here are some basic Verilog examples of using the analyze command:
1. analyze -f files.list1 –f files.list2 ---

Here the location of design files as well as other analyze options is specified in a text file.
You can even nest file lists. The analyze command can use text files to compile all design files within the project. In this
example, files.list1 and files.list2 are two text files that contain the path to the source code for the project. The switch, "-f”, is
used to specify the name of the file. Within the file list, you can use “//” or “#” for one line comments. Shell environment
variables can be used in the content of the file but not Tcl variables. You can also use language specification options.
An example files.list is as follows:
+incdir+src
-f nested.file.list
-sverilog # subsequent files will be SystemVerilog
./src/async_fifo.v
./src/or_dc.v
-v2k # subsequent files will bev2k
./src/or_ic.v
./src/design_top.v
This is a simple files.list from a Verilog design. The first line in the files.list contains the +incdir+ option which allows
users to specify directories that contain files specified in the source code with the ‘include compiler directive. The second
line includes another file list. The third line directs that the subsequent files should be interpreted as SystemVerilog.
The next two lines point to the location of the SystemVerilog source code that needs to be compiled. The sixth line
changes the default language to v2k for the next two Verilog files. You can use any number of analyze options inside the
files.list.
When a variable is used in the filelist file, you can set the environment variable from within the control file so it will not
affect other processes by:
global env
set ::env(WORKDIR) ./ethmac/rtl/verilog
2. analyze [glob ./src/*.sv] --- In this example, all files in directory

./src that end in .sv are analyzed as SystemVerilog files. This shows the use of wildcards on the command line. Note
that wildcards are not supported from within a file list.
3. analyze +incdir+../include -v {cpu_lib.v} top.v --- This is a Verilog example. The +incdir+ specifies
directories that contain files referenced in the source code with the 'include compiler directive. Another common option
is the "-v" option. This option allows you to specify the names of files to be treated as library files. In this example, the
cpu_lib.v file is treated as a library file that contains one or more module definitions. Only modules that are instantiated
in the design will be compiled into the database. Finally the top.v file in this example is the top-level module of the
design to be compiled.
For Verilog designs, the order in which source code files are specified in the files.list text file does not matter.
Resolution of included files is done by searching, in this order, the current directory, the +incdir+ directory, followed by
the paths specified by the variable ri_search_path.
When multiple analyze commands are used, the +incdir+ directory and the +define+ defines will be visible only to
the local command. A variable exists, ri_incdef_accumulate, that when true will result in include directories and defines
being visible to later design files.
There exists an ri_match_vcs variable that can be set to true to match VCS behavior. Currently it controls only one
feature. When this variable is false (default), a zero length multiple concatenation, for example, { 0 { aa } }, is treated as 1'b0.
When this variable is true, Real Intent matches the behavior as VCS, which is: In v2k and v95 mode, it treats zero length
multiple concatenation as 1'b0. In SV mode, it treats it as zero length if it is part of a concatenation expression; otherwise
it gives an error on a zero length multiple concatenations.
Some simulators are known to use the .vs filename extension for internal purposes. These files can be safely
ignored by setting ri_ignore_vs_files true.
Pragmas can also impact design read-in. Refer to Attribute and Pragma Support

VHDL Support
Meridian CDC supports VHDL designs based on the synthesizable subset of the VHDL 1076-2002 language. The VHDL flavor
of IEEE 1850-2005 PSL is supported in RTL via the -psl pragma or externally via property files. Inline PSL is enabled with
the -psl option and property files are provided with the +propfile+ option to the analyze command.
Reading code into Meridian CDC is similar to Verilog, except that the analyze command includes a -work option to specify
the library where the code should be stored. The default library is work. By default, the analyze command understands
files with .vhd and .vhdl extensions to contain VHDL code. This default can be overridden by the -format vhdl switch
available for the analyze command.
• The following variables impact the compilation of VHDL code:

• ri_vhdl_require_ordered_analyze: When ri_vhdl_require_ordered_analyze is true, the analyze command strictly
enforces VHDL’s library visibility rules that require symbols to be visible when a source file is read. When false, all symbols
are resolved at elaboration so the files can be analyzed in any order.
• ri_vhdl_std_logic_dash_is_x: When ri_vhdl_std_logic_dash_is_x is false, a VHDL '-' is treated as Don't Care(default).
When ri_vhdl_std_logic_dash_is_x is set to true, '-' will not be treated as Don't Care. It will be treated as 'X', meaning that
'-' is interpreted strictly as a symbol which does not match any of the other 8 std_logic values.
ri_vhdl_preserve_case: VHDL case is preserved in Meridian CDC. The variable ri_vhdl_preserve_case, when set to true or
false, can be used to change the default behavior.
ri_vhdl_map_work_to_target_library: When reading in libraries, use the standard “use” clause in the VHDL code to specify
where VHDL libraries are located. The analyze command will look in this library for library files. When the “work” library is
specified in the “use” clause, a special variable enables the mapping of the work directory to other other libraries. When
the variable ri_vhdl_map_work_to_target_library is true, Meridian CDC will first search for a “work.pkg” package in the
library called “work”, and if not found, it will search the library specified by the -work <lib_name> option of the analyze
command. If not in the library specified by -work either, then all libraries are searched. In addition, read_library_map
handles interpretation of cds.lib files used by Cadence simulators. Refer to “Resolving VHDL Modules” in the section on
elaborate for more information.
Here are some basic VHDL examples of using the analyze command:
• example 1: analyze –work lib1 {mypkg.vhd myent.vhd} --- Suppose mypkg.vhd is a file containing a VHDL package called
mypkg.. Suppose myent.vhd is a file containing a VHDL entity called myent, and two architectures of myent called beh
and rtl. This command will analyze both files into a work library called lib1.
Now the declarations inside mypkg are available in lib1, and would be resolved from within other VHDL code as:
library lib1;
use lib1.mypkg.all;
Also, myent has been compiled into lib1, so if you want to elaborate myent as the top level of the design, you have to
specify -work lib1 to the elaborate command (see “elaborate”).
• example 2: analyze –work lib1 –f mylist.txt --- You can achieve the same analyze command as above by
creating a file named mylist.txt that contains the following list of files:
mypkg.vhd
myent.vhd

The default -work is called “work”, so if you omit the -work switch, files are compiled into work.

Mixed Language Support
Meridian CDC can process mixed language designs in addition to Verilog, SystemVerilog, and VHDL designs. Reading in
the design is similar to a single language design. It is suggested to use separate analyze commands for Verilog and VHDL
files for a mixed language design. Also, you must have only one Verilog language version in each analyze command, that
being v95, v2k or sverilog.
Verilog modules can be instantiated from VHDL only by component instantiation. Direct entity instantiation of Verilog
modules from VHDL is not supported. Because VHDL is case-insensitive, a Verilog module can match a VHDL component
even if their names have different capitalization.
By default, the analyze command understands files with .v extension to contain Verilog, files with .sv extension contain
SystemVerilog, and files with .vhd and vhdl extensions to contain VHDL code. This default can be overridden by the
explicit –v95, -v2k, or -sv analyze command options.
Assuming a mixed design is comprised of 3 Verilog (vl1.v, vl2, vl3.v) and 2 VHDL (vhd1.vhd, vh2.vhd) files, they can be
read in the following manner.
analyze {vl1.v vl2.v vl3.v}

analyze {vh1.vhd vh2.vhd}
As another example - VHDL files can be analyzed before Verilog files.
analyze {vh1.vhd vh2.vhd}

analyze {vl1.v vl2.v vl3.v}
File specification is very flexible. For example, the following command provides a Verilog, SystemVerilog, and VHDL file,
based on the file extensions.:
analyze v1.v v2.sv v3.vhd

SVA Assertions
Meridian CDC supports a subset of IEEE 1800-2005 SystemVerilog Assertions (SVA) for defining constraints/assumptions on
formal analysis. These SVA assumptions are used to define valid input scenarios. Failures that violate the assumptions
placed on the inputs will not be reported.
Scope of Support
The IEEE 1800-2005 flavor of SVA is currently parsed. A model can be built for the subset indicated in this document.
Properties lying outside this subset cause an Elaboration Warning. Unsupported properties get ignored, but elaboration
continues. The same is true if the building of the model exceeds a default time limit.
Basic Syntax
SVA statements are inserted like regular Verilog statements inside modules, or in a separate file that is then bounded
using the keyword bind. Support for bind is limited to binding to a RTL module. Binding to a specific instance of a RTL
module is not supported and is ignored.
bind <ModuleName> <BindInstantiation>;

• ModuleName - name of RTL module.
• BindInstantiation - one of program, module, or interface instance.
Verification Directives
Meridian CDC supports immediate and concurrent properties. The following directives are supported:
Verification Directive Definition
assert property <prop>; Check if property holds starting from reset. The check is not
supported, but Tcl commands allow an assert to be changed to
an assume.
assume property <prop>; Constrain inputs such that property holds.
assert <expr>; Check if property holds starting from reset. The check is not
supported, but Tcl commands allow an assert to be changed to
an assume.
assume <expr>; Constrain inputs such that property holds
cover property <prop> Cover properties will be compiled but are ignored.
The following limitations also apply:

• Concurrrent cover statements are not supported; they are ignored.
• There is no initial assertion.
• Recursive properties are not allowed.
Clock Definitions
All assertions require a clock. The property is evaluated only at the specified clock-event and its variables are sampled
in that time window. Only one clock per property is supported. You can specify a default clock as follows:
default clocking <name> @(<clock_event>) ; endclocking
or

clocking <name> @(posedge clk); endclocking

default clocking <name>;
System Functions
The following SVA system functions are supported within assertions. Syntactically they are treated as HDL extensions
(RTL-level functions). These functions are evaluated according to the clock specified for the property they occur in.
System Function Description
$rose(<HDL-expression>) true if least significant bit of argument changed from 0 to 1 in the
previous clock cycle.
$fell(<HDL-expression>) true if least significant bit of argument changed from 1 to 0 in the
$stable(<HDL-expression>) true if least significant bit of argument did not change in the
$past(<HDL-expression>[ , i] returns the value of the first argument i clock cycles before the
[ , <GateExpression>] current clock cycle. Clock cycles are either referring to the global
[, <Clocking Event>]) clock of the property, or that clock gated by GateExpression.
$sampled(<HDL-expression> returns the value of the expression at the last clocking-event of the
[, <Clocking Event>]) property.
$onehot(<HDL-expression>) returns true if only 1 bit of the expression is high.
$onehot0(<HDL-expression>) returns true if at most 1 bit of the expression is high
$countones(<HDL-expression>) returns the count of the number of ones in a bit vector expression
Sequences
Sequences are used to specify a reference name for scenarios that span time, often used to improve readability of the
complex properties. The following shows supported syntax:
Sequence Declaration
sequence <name> [(<parameter_list>)] ;

<sequence_expression> ;
endsequence [ : <name> ]
or
sequence <name> [(<parameter_list>)] ;

@ ( <clock_event> ) <sequence_expression> ;
endsequence [ : <name> ]
Note: Limitations exist on actual parameter values in a sequence instantiation:

• Another sequence instantiation cannot be passed as a parameter
• $ cannot be passed as a parameter
Sequence Expressions
<bool> boolean (HDL-) expression
<seq_expr>
instance of another sequence (evaluated with its own parameters) or a
sequence expression where ##<n> denotes n clock periods ( example: x
##1 y says x occurs and then y occurs 1 clock cycle later.)

Sequence Boolean operations:

Complex sequences can be formed using sequence boolean operators. Evaluation of both arguments starts at the same
clock cycle, but they may have differing length (the shorter sequence is filled with “true”)
<sequ_expr> or <sequ_expr> either of the sequences hold
<sequ_expr> and <sequ_expr> both seqeuences hold
Properties
Properties describe relationships between sequences, boolean expressions and other properties. Note that liveness
properties and local variables are not supported.
Property declaration syntax

The following syntax is supported for declaration of properties:
property <name> [(<parameter_list>)];

<property_expr> ;
endproperty [ : <name> ]
or
property <name> [(<parameter_list>)] ;

@ ( <clock_event> ) [disable iff <expression>]
<sequence_expr> ;
endproperty [ : <name> ]
Property expression:
<boolean>boolean expression / parameter
<sequence_expr>
(instance of) a sequence

PSL Assertions
Meridian CDC supports a subset of the VHDL flavor of PSL for defining constraints/assumptions for formal analysis of VHDL
designs. These PSL assumptions are used to define valid input scenarios. Failures that violate the assumptions placed
on the inputs will not be reported.
Scope of Support
The IEEE 1850 - 2005 language is currently parsed for VHDL language. A model can be built for the subset discussed
in this topic. Properties outside this subset cause an elaboration warning. The property gets ignored, but elaboration
continues. The same is true if the building of the model either times-out or spaces-out.
Basic Syntax
The following describes the supported modes of PSL, that being embedded pragmas in the VHDL design code or
external vunit files.
embedded pragmas in
VHDL:
-- psl <statement> ;
-- psl
-- <statement_0>
-- <statement_1>
-- ...
-- <statement_k>
@(posedge clk);
external file:
vunit <name>
(<entity>[(<architecture>) ]
{
default clock is
<clock_expr>;
<statement_0>
...
<statement_k>;
Notes:
i. inherit <vunit_name> is allowed inside a vunit to inherit the contents of another vunit.
ii. vmode and vprop are currently not supported. Use vunit instead.
Verification Directives
Meridian CDC supports the following directives are supported:
Verification Definition
Directive
assert Check if property holds starting from reset. The check is not supported, but Tcl
<prop>; commands allow an assert to be changed to an assume.

assume Constrain inputs such that property holds.

<prop>;
restrict Constrain inputs such that property holds.
<prop>;
Constrain inputs such that property holds
assume_guarantee
<prop>;
Notes:
• There is no logical difference between assume, assume_guarantee, and restrict.
• Not supported: fairness, strong_fairness.
Clock definitions
Clocks are used to prevent transitional logic from causing false errors.
• @true is allowed which essentially says all transitions on all signals of the property cause an evaluation.
• Properties are evaluated at the current time window when the clocking expression is true.
• Examples of individually clocked properties:
<property> @ rose(clk); <property> @ fell(clk);
Note: Meridian CDC allows only one clock per property or vunit
Boolean layer
The boolean layer consists of extended HDL expressions that result in true or false. Expressions use VHDL-native
operators. Expressions may use built-in functions or HDL specific operations.
The following PSL system functions are treated as HDL extensions (RTL-level functions):
System functions Definition

rose(<HDL-expression>) true if argument changed from 0 to 1 in the previous clock cycle.
<HDL-expression> has to evaluate to a single bit.
fell(<HDL-expression>) true if argument changed from 1 to 0 in the previous clock cycle.
<HDL-expression> has to evaluate to a single bit
prev(<HDL-expression>, returns the value of the first argument i clock cycles before the
i ) current clock cycle.
stable( <HDL-expression>) true if argument did not change in the previous clock cycle.The
<HDL-expression> has to evaluate to a bitvector.
onehot( <HDL- countones(<HDL-expression> ) <HDL-expression> has to evaluate to
expression>) , a bitvector, the argument must have a static value.
onehot0( <HDL-
expression>)
Note: isunknown and the HDL-function next are parsed but ignored by Meridian CDC. You can use the PSL
operators X or next instead.
Clock expressions
For use in any clocked property / default clock assignment:
• boolean name
• boolean function call
• ( Boolean )
• ( HDL clock-expression )

Booleans and the HDL-clock-expression must be enclosed in parenthesis.
Regular sequential expressions (SEREs)

Sequences are used to specify a reference name for scenarios that span time, often used to improve readability of the
complex properties. The following shows supported syntax:
Sequence declaration
sequence <name> [(<parameter_list>)] is { <SERE> } ;
where <parameter_list> allows the following types:

• boolean expression evaluating to true / false
• statically determined integer value
• instance of another sequence (possibly with its own parameters).
Sequence expressions
<bool> | boolean (VHDL) expression
{ bool }
<seq_expr> instance of another sequence (evaluated with its own parameters)

or a sequence expression that uses SERE concatenations ( example:
x;y says x occurs and then y occurs 1 clock cycle later.)
Sequence concatenations
SERE1;SERE2 non-overlapping concatenation (SERE2 occurs one clock after SERE1)
SERE1:SERE2 overlapping concatenation (LHS and RHS overlap in one clock cycle)
SERE non-length matching boolean operators:

Complex sequences can be formed using sequence boolean operators. Evaluation of both arguments starts at
the same clock cycle, but they may have differing length (the shorter sequence is filled with “true”)
<SERE> | <SERE> either of the sequences hold
<SERE> & <SERE> both seqeuences hold

Note: The length-matching conjunction && and within are not yet supported.
SERE consecutive repetition

finite repetition according to the range
<ext_sequence>
[*<range>]
unbounded repetition: zero or any number
<ext_sequence>[*]
unbounded repetition: one or any number > 1

<ext_sequence>[+]
Notes:
i. <ext_sequence> can be either a <sequence>, a boolean, or an empty string standing for the constant
TRUE.
ii. the non-conscutive repetition operators [= ] and [ -> ] are not yet supported.
iii. Repeated SEREs are “braced to the left”: a[*2][*3] = {a[*2]}[*3].
iv. Ranges are interpreted as follows:

[*n] n repetitions
[*m:n] / [*m to n] between m and n repetitions
where:
i. m must be smaller or equal to n
ii. m may be 0 - (no repetition)
iii. n may be inf - any number of reptitions (unbounded)
iv. <SERE>[*0] defines the empty sequence for any SERE
Note:
1. Meridian CDC does not allow unbounded repetition operators within the scope of another
unbounded repetition operator.
2. Meridian CDC currently only supports safety properties only. This results in a weak interpretation
of the unbounded repetition operators: sequences like a[*];b are satisfied not only in an execution
sequence where a is true until the clock cycle before b is true, but also where a is true forever.
Temporal properties
Temporal properties describe temporal relationships between sequences, boolean expressions, and other properties.
Note: Liveness properties are not supported.
Property declaration
property <name> [(<parameter_list>)] is { <property_expression> } ;
where <parameter_list> allows the following types:

• boolean expression evaluating to true / false
• statically determined integer value
• instance of another sequence (possibly with its own parameters).
Property expressions
<bool> boolean expression
(<prop>) (instance of) another property
Initial sequence
<sequence>[ ! ] sequence holds initially from reset state
Clocked property:
<prop> property is evaluated according to clock-expression
@
<clock_expression>
Suffix implications (conditional concatenation):

<sere> |-> <sere> if LHS holds, RHS holds starting the last clock cycle of LHS.
(overlapping suffix implication)
<sere> |=> <sere> if LHS holds, RHS holds starting the clock cycle after the last clock
cycle of LHS (non-overlapping)

<sere> |-> <prop> if LHS holds, RHS prop holds at the last clock cycle of LHS.
(overlapping)
Property operators
not <prop> negation
<prop> and <prop> conjunction
<prop> or <prop> disjunction
<prop> -> <prop> implication: “not prop1 or prop2”
<prop> <-> <prop> logical equivalence
Temporal operators
always <prop> prop holds always
never <prop> prop never holds
next (<prop>) prop holds in the next clock cycle
next! (<prop>) prop holds in the next clock cycle
next[ <number> ] (<prop>) prop holds in the next <number> clock cycles
next![ <number> ] (<prop>) prop holds in the next <number> clock cycles
next_a[ <finite_range> ] (<prop>) prop holds in all clock cycles within the specified range
next_a![ <finite_range> ] (<prop>) prop holds in all clock cycles within the specified range
next_e[ <finite_range> ] (<prop>) prop holds in some clock cycles within the specified range
next_e![ <finite_range> ] (<prop>) prop holds in some clock cycles within the specified range
Notes:
a. According to the PSL LRM next! requires the existence of a next clock cycle to be satisfied, while next does
not. This distinction makes sense only for simulation, where execution sequences are of finite length. For
formal verification purposes, execution sequences are always infinite (hardware never stops), thus there is
always a next clock cycle.
b. next[0](<prop>) is equivalent to <prop>,
c. next[1](<prop>) is equivalent to next(<prop>).
<prop> until <prop> either RHS holds until the clock cycle before RHS holds, or
LHS holds forever
<prop> until_ <prop> either LHS holds until the clock cycle where RHS holds, or
LHS holds forever
<prop> before <prop> LHS holds at some clock cycle before RHS holds, if ever
<prop> before_ <prop> LHS holds at some clock cycle before RHS holds or at the
clock cycle where RHS holds, if ever

Note: The respective strong operators until!, until!_, before!, before!_ are not supported currently.
next_event(<bool>)(<prop>) prop holds at the next clock cycle where bool holds
next_event(<bool>)[<number>] prop holds at the next clock cycle where bool holds the
(<prop> ) number-th time
Note: the respective strong next_event operators are not yet supported.
Short notations:
G <prop> always <prop>
X <prop> / X! <prop> next <prop> / next! <prop>

[<prop W <prop>] <prop> until <prop>
Note:
1. For all operators in the next family, only finite ranges are allowed.
2. Meridian CDC currently supports only safety properties. This only allows the weak versions of until, before,
and next_event operators. Weak operators are called such, because their termination condition may never
occur. For example, see the semantics for (p until q) satisfied at clock cycle i: either there is a clock cycle
j>=i such that q holds at clock cycle j and in all clock- cycles k with i<=k<=j p holds; or, p holds forever. So, for
(p until q) to hold, q needs not to hold in any point in the future.
3. Meridian CDC does not impose the restriction of simple subset (where each operand of a before / before_
needs to be a boolean, and RHS operand of until / both operands of until_ need to be booleans).
Abort directive
abort is supported only in certain contexts. Occurrences outside these contexts are ignored while leaving the rest of
the property intact. This is because for formal verification abort has no meaning outside these contexts - this preserves
the meaning of the property.
<prop> abort <bool> is semantically supported in the following contexts only:

always ( <prop> abort <bool> );or
<prop> abort <bool> ;
where these have to be top-level properties.
In the first case, the property holds either if <prop> holds forever, or, if <bool> occurs at a clock cycle c, evaluation
of <prop> is restarted, even if checking of <prop> at clock cycle c is not complete. The latter holds either if <prop>
holds, or if <bool> occurs during evaluation of <prop>.
Note: At, or before the clock cycle the abort condition occurs, <prop> may or may not hold. Thus, the passsage of such
a property does not mean that “<prop> holds unless <bool> occurs”. This has to be formulated correctly as
always ( <prop> until <bool> );
using the weak until that expresses just that unless-condition.
In all other contexts the abort directive is ignored, while leaving the rest of the property intact.
Operator precedence
Operator precedence is decreasing precedence top to down and left to right:
HDL operators, @, [*], [+], &, |, :, ;,
abort,
next-family ,
W / until / until_ , before / before_,

|->, |=>, ->, <->,

always / G, never.
The next family contains all next, X, next_a next_e, next_event, etc. operators. They all have the same precedence.
Note the unusually low priority of the next operators. Also, boolean property operators have the same (high)
precedence as HDL-boolean operators (!). Also note the high priority of boolean (HDL) expressions implies that
whenever there is ambiguity, the construct of higher precedence is chosen. Example: in the expression {{req} &&
{req}};{ack} , {req} && {req} is parsed as boolean instead of a sequence (Verilog allows braces for booleans). Both
readings, have the same meaning.
Other unsupported constructs

Besides the constructs mentioned above, the following constructs are currently not supported. They are parsed, but
ignored:
• endpoint
• within family
• the pre-processing macros (%for, %if, %forall, %define)
• the forall operator
• struct types and union types
• HDL in PSL vunits
• module instantiations within vunits

Attribute and Pragma Support
Real Intent tools recognize a variety of types of pragmas in the RTL. Supported pragma vendors include synopsys,
cadence, verific, exemplar, pragma, synthesis, LV_BIST, spyglass, 0-in, and magma.
The typical format of a pragma is "// <vendor_id> <directive>". There are three types of pragmas supported: those
that impact the ENV file generation, those that impact the creation of the design database, and those that are used by
the verification engine. Each is discussed in the following sections.
Note that for vendor’s verific, exemplar, LV_BIST, spyglass, 0-in, and magma, the translate_off or synthesis_off pragma
identifier will be honored by Meridian CDC but will not be reflected in the Verdi debugger.

ENV File Pragmas

There are two pragmas that impact the creation of the ENV file:
sync_set_reset
set_stable_value
sync_set_reset recognizes any of the standard pragma vendors. set_stable_value is unique to Real Intent and requires
an "ri" as an identifier.

ri_set_stable_value
Pragma used in the creation of an ENV file to identify signals that will have a stable value during normal operation.
This can be used to reduce false failures by directing the tool to not change the signal value during verification.
VERILOG SYNTAX
// ri set_stable_value <signal>
/* ri set_stable_value <signal> */
VHDL SYNTAX
-- ri set_stable_value "<signal>"
EXAMPLES
// set stable value on sig1
reg sig1; // ri set_stable_value sig1
reg sig2; /* ri set_stable_value sig2 */
RELATED COMMANDS
RELATED VARIABLES

sync_set_reset
Pragma or attribute is used in the creation of an ENV file to identify synchronous resets that cannot be identified
automatically.
The identification of resets is an important part of the setup process for many Real Intent tools. Synchronous resets
are recognized automatically when the name implies it is a reset signal, it is not an event trigger, and there is not an
asynchronous reset for that block. This pragma is used in the creation of an ENV file to identify synchronous resets that
cannot be identified automatically.
VERILOG SYNTAX
// <keyword> sync_set_reset <signal>
/* <keyword> sync_set_reset <signal> */
VHDL SYNTAX
-- <keyword> sync_set_reset <signal>
EXAMPLES
reg sig1; // synopsys sync_set_reset sig1
reg sig2; /* cadence sync_set_reset sig2 */
(* sync_set_reset *) reg sig3;
RELATED COMMANDS
read_env
RELATED VARIABLES

Synthesis Pragmas
There are several pragmas that impact the creation of the design database that is created via analyze and elaborate:
translate_off and translate_on,

synthesis_off and synthesis_on,
read_comments_as_hdl on and read_comments_as_hdl off,
parallel case
full case
Pragmas are directives that exist in a comment in the file. The comment can use one of the following formats:
• in a Verilog or Systemverilog file, use either comment style:
/* <comment> */
// <comment>
• in a VHDL file, use the standard “- - comment”
In the comment, precede the directive with any of the supported keywords, where the supported vendor keywords
include synopsys, cadence, verific, exemplar, pragma, synthesis, LV_BIST, spyglass, 0-in, and magma.
The supported vendor keywords must be first in the comment line.
The analyze command provides options to ignore the synthesis_off and translate_off and
read_hdl_comments_as_code. The switch, -ignore_translate_off {list}, causes the <vendor>
synthesis_offand <vendor> translate_off pragmas from the specified list of vendors to be ignored for that
command only. The switch -ignore_read_comments_as_hdl will result in that Verilog pragma being ignored.
In addition, you can choose to ignore all pragmas from a specified vendor in one of two ways:
• The analyze command allows for ignoring all pragmas from a specified list of vendors via the -
ignore_pragma_vendors {list} switch.
• The variable ri_ignore_pragma_vendors enables specifying a list of pragma vendors to be ignored.

translate on/translate off

These pragmas are used to identify code that should not be synthesized. The code between the “keyword
translate_off” and a subsequent “keyword translate_on” is ignored by Real Intent tools and noted in the compilation
section of the logfile as “code ignored by pragmas”. A matching keyword is required to turn translation back on.
For example, if you use “cadence translate_off”, all code and pragmas are ignored until a matching “cadence
translate_on”.
Use of this pragma can cause the following warnings to appear in the logfile during elaboration:

: Port "cadence_pragma" of module "test" is unused

: Output port "out2" of module "test" is not driven
The analyze command has an option to ignore these synthesis translation pragmas.
VERILOG SYNTAX
// <keyword> translate_off; ... .. // <keyword> translate_on
/* <keyword> translate_off */ ....... /* <keyword> translate_on */
VHDL SYNTAX
-- <keyword> translate off ....... -- <keyword> tranlsate on
RELATED COMMANDS
analyze
RELATED VARIABLES
ri_ignore_pragma_vendors

synthesis off/synthesis on
These pragmas are used to identify code that should not be synthesized. The code between the “keyword
synthesis_off” and a subsequent “keyword synthesis_on” is ignored by Real Intent tools and noted in the compilation
section of the logfile as “code ignored by pragmas”. A matching keyword is required to turn translation back on.
For example, if you use “cadence synthesis_off”, all code and pragmas are ignored until a matching “cadence
synthesis_on”.
Use of this pragma can cause the following warnings to appear in the logfile during elaboration:

: Port "cadence_pragma" of module "test" is unused

: Output port "out2" of module "test" is not driven
The analyze command has an option to ignore these synthesis translation pragmas.
VERILOG SYNTAX
// <keyword> synthesis_off; ... .. // <keyword> synthesis_on
/* <keyword> synthesis_off */ ....... /* <keyword> synthesis_on */
VHDL SYNTAX
-- <keyword> synthesis_off ....... -- <keyword> synthesis_on
RELATED COMMANDS
analyze
RELATED VARIABLES

read_comments_as_HDL on/read_comments_as_HDL off

Pragma pair that is used specify that commented code between the on and off pragma should be read as HDL. All
pragma keywords are accepted, however the keyword for the "on" must match the keyword for the "off". An option to
the analyze command, -ignore_read_comments_as_hdl, enables ignoring these pragmas. This is supported for Verilog
only.
VERILOG SYNTAX
// <keyword> read_comments_as_HDL on .... // <keyword> read_comments_as_HDL off
/* <keyword> read_comments_as_HDL on*/ .... /* <keyword> read_comments_as_HDL off */
EXAMPLES
In the following example, the pragma cause the dataout1 and dataout2 logic to be synthesized.
// synthesis read_comments_as_HDL on
// always @(posedge clk or negedge reset)

// if (!reset)
// dataout1 <= 'b0;
// else
// dataout1 <= datain1;
/*
always @(posedge clk)
begin
dataout2 <= datain2;
end
*/
// synthesis read_comments_as_HDL off
RELATED COMMANDS
analyze
RELATED VARIABLES

parallel_case
These pragmas are used to identify case statements that should be synthesized as simple multiplexors, versus priority
encoding. It means that there will never be more than one case item that is true at the same time: the case items are
mutually exclusive. Parallel case pragmas apply to Verilog/SystemVerilog only.
VERILOG SYNTAX
case (1'b1) // <keyword> parallel_case
begin
a: .....;
b: .....;
c: .....;
endcase
RELATED COMMANDS
analyze
RELATED VARIABLES

full_case
These pragmas are used to identify case statements that should be synthesized as flops versus latches. It means that all
case items that can be reached are fully specified.
VERILOG SYNTAX
case (1'b1) // <keyword> full_case
begin
a: .....;
b: .....;
c: .....;
endcase
VHDL SYNTAX
case sel is -- <keyword> full_case
when "00" => .....;
when "01" => .....;
when "10" => .....;
when "11" => .....;
when others => .....;
endcase
RELATED COMMANDS
analyze
RELATED VARIABLES

Special Handling of RTL

Some types of constructs can cause memory or performance issues for formal technologies and are therefore have
special handling. RAMs and other large arrays are one such example. Liberty files that provide models is another.
The following discusses these and other constructs and modules/entities that may have special handling. Refer to the
compile summary and the detailed logfile messages for information on special handling that occurred during the design
read in.

RAMs and Big Arrays

For improved performance, Real Intent tools have special handling of large arrays of flops are automatically identified
as RAMs and big arrays (a.k.a.Big IDs).
Real Intent tools decide how to model arrays of flops according to the following criteria:
• An array is first analyzed to determine if it is a RAM and modeled accordingly. In Meridian CDC,the RAM is modeled
with a netlist primitive. In Ascent IIV and Ascent XV they are blackboxed. In Ascent Lint, RAMs do not count as registers
whereas flops do.
• If an array is not a RAM, then the criteria for modeling the array as a big array (a.k.a. BigID in the blackbox report) is
examined. In all tools, big arrays are blackboxed. See the table below for more information.
• Arrays that do not meet the criteria for being identified as a RAM or a Big Array are modeled as flops.
In addition to the above criteria, there are variables that impact The default values variables that affect the identification
of RAMs and Big Arrays vary across tools. The table below shows a summary.
Table 2: Default values of RAM and Big Array Variables

Meridian Ascent Ascent Ascent
RAM Lint IIV XV
ri_ram_min_words 0 3 3 3
ri_ram_min_size 0 63 63 63
ri_ram_max_reset_count 1 1 1 1
BIG ARRAY
ri_max_single_range_bits 12 12 12 12
ri_max_total_range_bits 12 17 12 12

Identification of RAMs
RAMs are identified based on how the array is declared and used in the RTL, as well as its size. Four types of RAM are
supported:
• read only (ROM),
• RAMs with one read and one write
• RAMs with multiple reads and one write (multi-port RAM)
• Resettable RAM
Specifically RAMs must meet ALL of the following criteria:
1. RAM declarations require:

a. A minimum size of RAMs that is controlled by 2 Tcl variables: ri_ram_min_words: specifies the minumum
word count, above which a RAM may be inferred. ri_ram_min_size: specifies the minimum total number of
bits, above which a RAM may be inferred. Both thresholds must be exceeded for the array to be recognized as
a RAM.
b. The declaration does not exceed the maximum number of bits per word, above which an array will not be
recognized as a RAM. This is controlled by a Tcl variable ri_ram_max_word_size (default 4096).
c. RAMs must be defined as a variable, cannot be in a function or task
d. RAMs must have only 1 unpacked dimension
2. A read of a RAM
a. RAMs must have at least one read.
b. RAMs cannot be referenced by the entire ID.
c. RAMs cannot be referenced by a range or sub-block inside a word.
3. A write to a RAM
a. Writes must be under an clock control, from a conditional (if/else, ?:), from an instance output port, or
must be addressed with a non-constant index.
b. Writes in a loop can only be for resetting the RAM.
c. In a multi-port RAM, writes must either be all synchronized or all non-synchronized.
d. Multi-port RAMs may have a maximum number of async resets that is controlled by ri_ram_max_reset_count
(default 1). In addition to async resets, synchronous resets with an initialization loop are also counted. Arrays
with more resets will not be treated as a RAM.
4. Other Rules:
a. A RAM must have at least one non-constant index.
b. RAMs cannot be read or written from within an SVA structure.
c. A non-const index of a RAM cannot exist in both the left and right hand side of an assignment; for example,
the following is not allowed: array[2]=array[2].
d. A self assignment loop (for example, mem=mem) is ignored, and does not count as a read or a write.
e. A RAM cannot have the same constant index used in both the LHS and RHS of an assignment; for example,
the following is not allowed: array[2]=array[2+const].
f. The size must exceed user defined values determined by the variables ri_ram_min_size, ri_ram_min_words,
and ri_ram_max_reset_count.
g. RAMs and ROMs cannot have more than 128 constant indexed writes
The default values of variables that affect the identification of RAMs vary across tools. The table below shows a summary:
Table 2: Default values of RAM and Big Array Variables

RAM Lint IIV XV

ri_ram_min_words 0 3 3 3
ri_ram_min_size 0 63 63 63
ri_ram_max_reset_count 1 1 1 1
RAMs are identified in the log file messages and also reported in the compilation summary discussed earlier. An example
logfile message for an automatically identified RAM is as shown below:
INFO [# 4009] : on line 22 in file ./edg_wr_edg_rd_ram.v

: Signal/Variable "mem" will be treated as RAM.
The following provide some examples of RAM identification. Aassume you have the following memory declaration:
reg [7:0] data1 [15:0] // size is 128 (=8*16), words is 16
reg [15:0] data2 [31:0] // size is 512 (=16*32) and words is 32
Data1 will be modeled as a RAM when both ri_ram_min_size < 128 and ri_ram_min_words < 16, otherwise it will be
modeled as flops. So for example:
ri_ram_min_size=129, ri_ram_min_words=17 -> data1 not modeled as a RAM

ri_ram_min_size=127, ri_ram_min_words=15 -> data1 modeled as RAM
Similarly, data2 will be modeled as a RAM when both ri_ram_min_size < 512 and ri_ram_min_words < 32, otherwise it
will be modeled as flops.
Currently a 2-dimensional array with one packed dimension and one unpacked dimension is the only format to qualify as
a RAM/ROM. The memory is declared as a two dimensional array with read access only or multiple read and write access
(RAM).
The following are some Verilog examples where Real Intent tools will identify a RAM structure:
Edge Write Edge Read
reg [4:0] mem [5:0];

always @(posedge w_clk)
if (w_en)
mem[w_addr] = w_data;
always @(posedge r_clk)
if (r_en)
r_data = mem[r_addr];
Edge Write Level Read
reg [4:0] mem [5:0];

always @(posedge w_clk)
if (w_en)
always @(r_clk)
if (r_clk)

if (r_en)
Level Write Edge Read
reg [4:0] mem [5:0];

always @(w_clk)
if (w_clk)
if (w_en)
always @(posedge r_clk)
if (r_en)
Level Write Level Read
reg [4:0] mem [5:0];

always @(w_clk)
if (w_clk)
if (w_en)
always @(r_clk)
if (r_clk)
if (r_en)
RAM Without Write or Read Clocks
reg [4:0] mem [5:0];

always @(w_en)
mem[w_addr] <= w_data;
assign r_data = mem{r_addr];
In Meridian CDC, when RAM modules cannot be identified automatically, and have clock domain crossings that need to be
verified on a RAM boundary, use the read_liberty command. The read_liberty command takes the .lib format description
of the RAM and writes out a Verilog description. This Verilog description of the RAM will contain only clock domain
association and "startpoint" and "endpoint" information. The detailed functional behavior of the RAM is ignored. This
Verilog description is automatically compiled in to perform analysis to "endpoints" ending at the RAM and from "startpoints"
starting from the RAM.
In Ascent XV, the outputs of RAMs are considered X-sources when the input signals have X-sources.
In Ascent Lint, the following rules are not enabled for RAMs: DFF_NOT_RESET, REG_NAME, REG_SUFFIX,
CONST_FF, REG_CAPTURED, REG_DRIVEN, and HIER_NET_* . However, the following rules (if enabled) are
agnostic to the interpretation of logic arrays, and hence continue to apply, irrespective of the interpretation: DFF_RESET,
DFF_DELAY, MISSING_RESET, RESET_ONLY, OVERWRITTEN, MULTI_PROC_ASSIGN, MULTI_NBA,
CASE_ASSIGNS, and IF_ASSIGNS.

Identification of Big Arrays

Big arrays that cannot be mapped as a RAM and are too big to represent in the internal model, are blackboxed to avoid
a performance cost. All reads and writes of this array are ignored. The following rules are used to identify big arrays:
1. The array is not a RAM

2. A big array can be a one dimensional or a multiple dimensional array.
3. The array must be referenced by a non-constant index.
4. There are two variables to control whether this big array can be modeled. The variable ri_max_single_range_bits
specifies the maximum allowed single address size, in bits, for a single dimension of a multi-dimensional variable that
can be modeled. If the address size is larger, then the module that contains the array is blackboxed. Similarly, the
variable ri_max_total_range_bits specifies the maximum allowed total address size, in bits, for all dimensions of a
multiple dimensional variable that can be modeled. If the total address size is larger, the module is blackboxed. When
ri_max_single_range_bits is larger than ri_max_total_range_bits, then the total range is assumed for both. This table
below shows a summary:
Table 2: Default values of Big Array Variables

BIG ARRAY Lint IIV XV
ri_max_single_range_bits 12 12 12 12
ri_max_total_range_bits 12 17 12 12
As an example, assume you have the following multi-dimensional array: [21:0] rom1 [1023:0]. Rom1 has 2**10 words,
so 10 bits is enought to represent the word address, and each word has 22 bits, so 5 bits is enough to represent the
indexes. So the biggest single range bits is 10 and the total is 15 (10+5). As long as you set the variables bigger than
these 2 numbers, the array will be modeled. Examples are shown below:
Table 1: Big Array Handling Variable Controls

ri_max_single_range_bits ri_max_total_range_bits array treated as
10 15 modeled
9 15 black box
11 12 black box
8 12 black box

Loop Handling
There are a few things to note about loops. This includes for, while, do-while, forever, repeat, and foreach. All
loop stop conditions must evaluate to a constant, consistent with synthesizability requirements. But also, loops can
sometimes cause explosion when unrolling. A variable exists, ri_max_loop_unroll, that allows the user to control
the maximum number of allowed unrollings. The default value is 1024. For any Verilog loop, it is unrolled 1024
times and if it is not terminated, analysis either stops with an error or is automatically blackboxed, depending
on the variable ri_max_exceeded_stops_elab. When ri_max_exceeded_stops_elab is true, an error occurs. When
ri_max_exceeded_stops_elab is false, the loop is ignored. Inputs will not have any load and outputs driven from within
the loop will be undriven. For VHDL, compilation will fail. The compilation summary and the setup report will show
that the loop is blackboxed.

Nonsynthesizable Constructs
The elaborate command models synthesizable designs and ignores or errors on non-synthesizable constructs. When
a non-synthesizable construct is simply ignored - there is no driver for the outputs and no load on the inputs to the
construct.
Non-synthesizable constructs are reported in log file messages and summarized in the compile summary. Undrivens and
no-load warnings are often a result.

Arithmetic Operators
Big arithmetic operators will be automatically blackboxed, though it happens after the design is read in. It is not
reported in the compilation summary, and it is not affected by the –auto_black_box option to elaborate. It is reported
in the setup_check.rpt and in the main report under BLACK_BOX category.
Big operators include shift registers greater than 10 bits, multiplier/dividers whose operands or outputs are greater
than 8 bits, decoders greater than 16 bits.
In Meridian, the ri_preserve_paths_in_auto_bboxed_insts variable determines the behavior. When

ri_preserve_paths_in_auto_bboxed_insts is true, every input becomes connected to every output in this operator
through an exclusive or gate with a value of X. If the variable is false, all output nets are driven with an X value.

Hard Macros
Hard macros are not directly supported. These must be blackboxed. It may be advantageous to create a shell of the
macro that identifies the ports.

Encrypted Modules
Real Intent tools recognize the standard `protect pragmas and ignores that protected code. It is important that all
begin protect pragmas be matched with end protect pragmas or compilation errors will result. When the module
declaration is not protected, it is important that the endmodule also not be protected. The module definitions
contained in files that are skipped will be reported as missing - no definition, at elaboration time. They can then
be automatically blackboxed at elaboration using the -auto_black_box option or explicitely blackboxed using the -
black_box option.

Analog Blocks
For analog models, Meridian CDC will model these appropriately as either open circuits or short circuits and ignore those
that do not impact digital analysis.

Simulation Models
Vendor libraries, such as Synopsys DesignWare, may include non-synthesizable simulation models. Real Intent offers
compatible synthesizable models for some vendor libraries. These are located in <RI_INSTALL>/synth_models. Contact
support for details. The user can also provide their own models.
Synthesizable models are automatically swapped-in in place of the original simulation model that is specified in
the simulation-based file list. Verdi will continue to reference the original file specified in the simulation-based file
list. Only compile and elaboration error messages are reported. There will be no report references to these files: no
violations, no special handleing such as RAM or loop handling, no setup issues, and so on. Details are not provided for
the synthesizable models. The compilation summary shows the number of simultion models that were substituted and
INFO messages in the logfile provide the details.
There are two variables that control the behavior: ri_synth_models_user_dirs and ri_synth_models_internal_dirs:
• ri_synth_models_user_dirs: This variable is used to specify the full path list of directories to search for synthesizable
models, searching from left to right in the directory list. These directories are searched before the installation
directories. The filename of the simulation model should match the filename of the synthesizable model. The default
value is {}.
• ri_synth_models_internal_dirs: If the file is not found in the directories specified by ri_synth_model_user_dirs, the
directories specified by ri_synth_model_internal_dirs variable are searched from the first in the list to the last in the
list. ri_synth_model_internal_dirs specifies the leaf directory name of the models provided in the installation directory
<RI_INSTALL>/synth_models (not the full path). The default vlaue is {user vendor1}. To turn off the search of the
installation models, set this to {}. The variable is intended primarily to allow for changing the search order when there
is more than one directory of models.

elaborate
Build the design hierarchy from the specified (or default) root module, check semantics, and build an internal netlist
model.
The elaborate command supports one hierarchy top. You can elaborate any design hierarchy by specifying the hierarchy
top as any module or entity name in the design. If no top hierarchy is specified, the last top-level module or entity
found in the design will be used as the hierarchy top.
You can run Meridian CDC anywhere within the design hierarchy. Elaboration starts at the top of the hierarchy and
instances are resolved as the hierarchy is built.
SYNTAX
string elaborate
[module_name | entity_name]
[-abstract_modules {modules...}]
[-abstract_report name]
[-auto_black_box]
[-black_box module_name | entity_name]
[-gui_compile]
Verilog Options
[-params value {value ...}]
VHDL Options
[-arch vhdl_architecture_name]
[-generics {value ...}]
[-psl]
Options that apply when ri_vy_lib_accumulate is true

[-y directory [+libext+<ext>] [-v2k] [-v95] [-sv[erilog] [-ignore_translate_off]]
Data Type
value, modules list

*name string
ARGUMENTS
[module_name | entity_name]
Verilog or VHDL option. The name of the Verilog module or VHDL design to be elaborated. Meridian
CDC will use the current top-level design in memory by default, if this is unspecified. (Note: When
the top level module has an interface port, you must create a new wrapper top level module that
instantiates the top and the interface.)
[-auto_black_box]
Automatically blackbox missing modules. This switch does not impact the blackboxing of RAMs, big
arrarys, or auto-operators. The log file will indicate in the compilation summary which modules were
blackboxed, as will the setup report when a setup analysis is done.

[-abstract_modules {modules...}]
List of abstract modules.
[-abstract_report name]
Name of abstract report file.
[-black_box module_name | entity_name]

Treat the named modules or entities as blackboxes and perform validation up to their boundaries.
Multiple module names can be included within curly braces {}.
[-gui_compile]
Compile design for SpringSoft Verdi. Compiling the design ahead of time can significantly improve the
start time of bringing up the debug environment. Verdi compilation pass/fail status is noted in the log
file and when errors exist, a pointer is provided to the Verdi log file.
The pass/fail status of the Verdi compilation will NOT affect the pass/fail status of Meridian CDC.
Processing will continue independent of the Verdi exit status.
Subsequently when launching Verdi, if there is an error the debugger will note the log file that
shows the errors and will ask whether to proceed, giving a checkbox to not show it again. Often it is
acceptable to proceed with limited functionality.
[-help]
Verilog Only Options

[-params value {value ...}]
Verilog option. List of parameter values or name value pairs for a top-level parameterized module.
When a values-only list is provided, the order is the same as the order in which they are defined in the
Verilog RTL source code; for example, {value1 value2 value3}. Alternatively, name value pairs can be
provided in any order ( e.g. {{param3 value3} {param1 value1}} ) to override the specified parameters.
This allows a user to configure the module into a particular form so that verification is run using the
settings that higher level blocks may use.
VHDL Only Options

[-arch vhdl_architecture_name]
VHDL option. Specifies the architecture for the top-level entity.
VHDL option. Name of working library.
[-generics {value ...}]

VHDL option. Specifies the actual values of the generics in the top level VHDL entity. When a values-
only list is provided, the order is the same as the order in which they are defined in the VHDL RTL
source code ({value1 value2 value3} ). Alternatively, name value pairs can be provided in any order
({{param3 value3} {param1 value1}}) to override the specified parameters. This allows a user to
configure the VHDL entity into a particular form so that verification is run using the settings that
higher level blocks may use.
[-psl]
Enable VHDL flavor of PSL pragma. This option is used during the analysis of library modules that are
resolved before building the hierarchy.

[-y directory [+libext+<ext>] [-v2k] [-v95] [-sv[erilog]]

[-ignore_translate_off] [-psl]]
These options are used during the analysis of library modules that are resolved before building the
hierarchy when ri_vy_lib_accumulate is true. Refer to the analyze command for complete details.
EXAMPLES
• Example-1 : Elaborate the last top module/entity
prompt> elab
• Example-2 : Elaborate CPU - This is a Verilog example. This example builds the design hierarchy from the CPU
module. In this example "CPU" is the module name.
prompt> elaborate CPU
• Example-3 : The following example shows the use of environment variablesor Tcl variables
as generics (same approach can be used for Verilog parameters). You can form lists with
[list] instead of using curly brackets that prevent the variables from expanding
prompt> set count [expr $env(TESTING_DATA_WIDTH)*2]
prompt> elaborate -generics [ list [list \

DATA_COUNT $count] [list DATA_WIDTH $env(DATA_WIDTH)] ] \
adder_tree
• Example-4 : The following example also builds the design hierarchy from the CPU module, but it ignores all
modules that start with ROM.
prompt> elaborate CPU -black_box { ROM* }
• Example-5 : This is a VHDL example. In this example, "myent" is the entity name that is compiled to work
directory WORK-arch with values 32 and 8 assigned to the first and second generics.
prompt> elaborate -work WORK-arch -generics {32 8} myent
RELATED COMMANDS
analyze
read_design_db
read_liberty
RELATED VARIABLES

Configuring a VHDL Top Entity via Generics

If you wish to set generic values on the top level VHDL entity, use the -generics switch. You can assign generics by name
or by order. For example, suppose the generic port list on myent looks like this:
generic (
A : integer;
B : integer := 7;
C : integer := 15
);
You can set A to 1 and B to 3 with this elaborate command:
elaborate -lib lib1 myent -generics { 1 3 }
You can set A to 2 and C to 31 with this command:
elaborate -lib lib1 myent -generics { { A 2 } { C 31 } }

Configuring a Verilog Module via Parameters

If you wish to set parameter values on the top level Verilog/SystemVerilog module, use the -params switch. You can assign
parameters by name or by order. For example, suppose the parameter list on CPU looks like this:
module CPU #(
int A = 1,
int B = 7,
int C = 15
….) (…);
….
endmodule;
You can set A to 1 and B to 3 with this elaborate command:
elaborate CPU -params { 1 3 }
You can set A to 2 and C to 31 with this command:
elaborate CPU -params { { A 2 } { C 31 } }

Handling Missing RTL Files using Blackboxing

You can use the elaborate –black_box {list} option or –auto_black_box option to ignore missing or unsynthesizable
modules or entities. By default, the output signals from a black box are considered as value x.
The –auto_black_box option allows the compiler to blackbox unresolved modules automatically. Once this option is set
to true, missing modules and modules with large constructs (big arrays) will be treated as black boxes and processing
continues. By default, modules not resolved in design or modules with big arrays are not explicitly blackboxed.
Meridian CDC will stop at the end of the elaborate command and give a list of unresolved module or entity names.
Here are some examples of how to blackbox modules:
• elaborate -black_box {RAM1 RAM2 RAM3} top_level

This is a Verilog example. This example blackboxes 3 modules RAM1, RAM2, and RAM3. Note: RAM1, RAM2, and RAM3
are module names. Meridian CDC analysis is run from the module named "top_level".
• elaborate -black_box {RAM1 RAM2 RAM3} top

This is a VHDL example. This example blackboxes 3 entities RAM1, RAM2, and RAM3. Note: RAM1, RAM2, and RAM3 are
entity names. Meridian CDC analysis is run from the entity named "top".
• elaborate -black_box {RAM*} top_level

The blackbox option supports wildcarding. This example produces the same result as the first example, except that
there is no need to specify all module names. "RAM*" automatically blackboxes any modules that start with "RAM".
• elaborate -auto_black_box
This option enables Meridian CDC to automatically blackbox any missing modules in the design.
Note: -auto_black_box is not needed for VHDL component instantiations of missing entities. A warning message will
be given, and the instances will be blackboxed automatically. If direct entity instantiation is used, but the RTL for the
entity is not available, then either -black_box or -auto_black_box is needed. For more information, see Understanding
VHDL Blackboxing.
All blackboxed modules are reported in the BLACK_BOX category in the setup section of the report, as well as in log
file messages and the log file Compilation Summary.

Resolving Verilog Modules

By default, most Verilog modules are resolved during the analyze step. Hierarchies compiled across analyze commands
are linked during elaborate. Libraries are searched to locate unresolved modules. Libraries are specified by –v for files,
or -y for directories. In addition, ri_search_path can be used to specify more directories. By default, each analyze
command has a list of libraries, including libraries from –v, -y and ri_search_path. Libraries are searched in the order
listed on the analyze command followed by the libraries from ri_search_path. The first module found is used in design.
Each analyze command should have all the libraries needed by the design files listed. These library files are located
and compiled into the database.
TIP: When multiple analyze commands are used, care is needed to ensure that modules with the same name do not
overwrite modules from earlier analyze commands in the same library. Design files and library files are analyzed in the
order listed on the analyze command or in a –f file. If there are more than one definitions of the same name, the last
definition is used.
There is a variable, ri_vy_lib_accumulate, that changes this library resolve procedure. This option will resolve all
unresolved modules at the beginning of elaborate command instead of in the analyze command, and all the libraries
specified in each analyze command are accumulated into one library list. This option may change library resolving
behavior. Messages in the log file will identify how modules were resolved.

Resolving VHDL Modules

VHDL hierarchy is built during elaboration. Consider the same example provided for VHDL analyze. There are two
architectures of myent: the “beh” architecture followed by the “rtl” architecture. By default, the last architecture
analyzed is the one which will be elaborated. So you can elaborate lib1.myent(rtl) as the top level of your design with
this command:
elaborate -work lib1 myent
If you want to choose the other architecture, use the -arch switch:
elaborate -work lib1 myent -arch beh
As with analyze, the default -work is called “work”, so if your top level entity is compiled in work, you do not need to
provide the -work switch to elaborate.
• The following variables impact resolution:

• ri_auto_get_lib: By default, Meridian CDC looks in the specified library for the top level entity/module that is
elaborated. You can set the variable ri_auto_get_lib to true to have Meridian CDC search all existing work libraries.
• ri_vhdl_preserve_case: VHDL case is preserved in Meridian CDC. The variable ri_vhdl_preserve_case, when set to true
or false, can be used to change the default behavior.
• ri_vhdl_map_work_to_target_library: When reading in libraries, use the standard “use” clause in the VHDL code to
specify where VHDL libraries are located. The analyze command will look in this library for library files. When the “work”
library is specified in the “use” clause, a special variable enables the mapping of the work directory to other other
libraries. When the variable ri_vhdl_map_work_to_target_library is true, Meridian CDC will first search for a “work.pkg”
package in the library called “work”, and if not found, it will search the library specified by the -work <lib_name> option
of the analyze command. If not in the library specified by -work either, then all libraries are searched. In addition,
read_library_map handles interpretation of cds.lib files used by Cadence simulators. Refer to “Resolving VHDL Modules”
in the section on elaborate for more information.

Understanding VHDL Blackboxing
The log file provides detailed information for understanding and debugging your design read in. As an example, let’s use
the log file to understand why a VHDL instance might be blackboxed.
There are several reasons a VHDL instance might be blackboxed during elaboration:
• If the instance is a component instantiation, and no entity with the same name was analyzed.
• If the instance is a direct entity instantiation, and no entity with that name was analyzed into the library specified in
the instantiation, and the -auto_black_box command was present on the elaborate command.
• If the instance is a component instantiation, and an entity with that name was analyzed, but the component's port
list or generic list is different than the entity's.
• If the user explicitly asked to blackbox the module with the -black_box switch on the elaborate command.
Case 1 above results in warning #35032, for example:

WARN [#35032] : on line 22 in file /home/me/src/find_component0.vhd
: "enum" remains a blackbox since it has no binding entity.
Cases 2 and 4 result in warning #35046, for example:

WARN [#35046] : on line 13 in file /home/me/src/top.vhd
: "sub" is being treated as blackbox.
Several possible warnings can occur for case 3, where the component and the entity interfaces do not match. In order
to help you debug the mismatches, these warnings will always be followed by info messages #15026 and #15030, which
tell the location of the component and the entity.
Warning #35066 happens when the component declares a port which is not found on the entity:
WARN [#35066] : on line 18 in file /home/me/src/top0.vhd

Instance "inst0" of entity "entity0" will be blackboxed because its component has an extra
port "extra".
INFO [#15026] : on line 9 in file /home/me/src/top0.vhd

: Here is the component "entity0" which is bound to instance "inst0".
INFO [#15030] : on line 1 in file /home/me/src/entity0.vhd

: Here is the entity "entity0" which is bound to instance "inst0".
Note: If the entity declares a port but the component does not, the instantiation is not blackboxed. The port connection
is left open. Warning #35074 will be given, followed by info #15026 and #15030.
Warning #35072 happens when the component declares a generic which is not found on the entity:
WARN [#35072] : on line 18 in file /home/me/src/top1.vhd'

: Instance "inst0" of entity "entity0" will be blackboxed because its component has an extra
generic "width".

Note: If the entity declares a generic but the component does not, the instantiation is not blackboxed. The generic
receives its default value. Warning #35075 will be given, followed by info #15026 and #15030.
Warning #35067 happens when the component declares a port with a different direction than the entity:

: Instance "inst0" will be blackboxed because its component declares
port "o1" with direction "inout", but entity "entity0" declares it
with direction "out".
Warning #35068 happens when the component declares a port with a different type than the entity:

port "in1" with type "integer", but entity "entity0" declares it
with type "bit".
Warning #35073 happens when the component declares a generic with a different type than the entity:

generic "msb" with type "bit", but entity "entity0" declares it
with type "integer".
Warning #35070 happens when the component declares a port with a different size than the entity. For instance, if the
component declares o1 as std_logic_vector(7 downto 0) and the entity declares it as std_logic_vector(15 downto 0):

: Instance "fail1" of entity "entity0" will be blackboxed because
the constraint for port "o1" has the wrong length.
: Here is the component "entity0" which is bound to instance "fail1".
: Here is the entity "entity0" which is bound to instance "fail1".
Usually it is allowed for a component to declare a port with a different range than the entity, as long as the ranges are
the same length. For instance, suppose a component declares a port “data_i” as std_logic_vector(8 downto 1), but the
entity declares it as std_logic_vector(7 downto 0). In such a situation, warning #35071 is given, along with info #15026
and #15030, and the instance is not blackboxed. However, if the instance uses partial port association in its port map (for
instance, connecting each bit of data_i individually), the instance will be blackboxed, and warning #35077 will follow
#35071. For example:

WARN [#35071] : on line 26 in file /home/me/src/sample1.vhd

: The component for instance "u_block1" declares port "data_i" with
range "(8 downto 1)", but entity "block1" declares it with range
"(7 downto 0)".
WARN [#35077] : on line 26 in file /home/me/src/sample1.vhd
: Instance "u_block1" of entity "block1" will be blackboxed because
its component doesn't match its entity and it uses partial port
association.
INFO [#15026] : on line 15 in file /home/me/src/sample1.vhd
: Here is the component "block1" which is bound to instance
"u_block1".
INFO [#15030] : on line 4 in file /home/me/src/block1.vhd
: Here is the entity "block1" which is bound to instance "u_block1".
The log file provides detailed information for understanding and debugging your design read-in.

Compiling the Design for Verdi

Meridian CDC's debugger can optionally make use of Synopsys’s Verdi for exploring the design. There is an additional
overhead for compiling the design into Verdi. In addition, schematics viewed may not exactly match the internal
modeling of the tool.
Compiling the design for Verdi is done when you double-click the hierarchy or a message in the report. It is also
possible, and recommended, to add the –gui_compile option to the elaborate command so it is compiled at the same
time as elaboration. The log file will show Verdi compilation status messages.
Occasionally, Verdi will flag some error that Meridian CDC does not. If the compilation fails, the message will point to
the Verdi log file for debug. Compiling the design for Verdi during the elaboration will save time late. Compiling the
design for Verdi during the elaboration will save time late. Use of the default iVision visualizer avoids this issues and
eliminates the need to compile the design twice.
Note that for vendor’s verific, exemplar, LV_BIST, spyglass, 0-in, and magma, the translate_off or synthesis_off pragma
identifier will be honored by Meridian CDC but will not be reflected in the Verdi debugger.

Design Compilation Summary

After compilation using the analyze and elaborate commands, a summary is provided. The summary gives a quick view
of how the design is read-in and what is modeled and not modeled in the design hierarchy. For things not modeled,
such as black boxes, it provides the details. All the detailed information is in the log file messages. The following is an
example:
Compilation Summary
-------------------------
Count
Blackboxed modules 1
Blackboxed big ids 0
Blackboxed big loops 0
Synthesizable model modules 0
Empty modules 0
Code ignored by pragmas 3
Ignored protected code 0
Non-synthesizable RTL 0
Unsupported constructs 0
RAMs 0
Blackboxed modules
------------------
Automatically blackboxed by Meridian CDC:
No definition:
DATA_PATH RISC_CORE.vhd:77
Code ignored by pragmas

-----------------------
/home/user/verilog/i2c_master_bit_ctrl.v:137
/home/user/verilog/i2c_master_byte_ctrl.v:69
/home/user/verilog/i2c_master_top.v:72
End Compilation Summary

-----------------------------
This summary should be reviewed to ensure there are no surprises before proceeding. The following provides a description
of each entry in the above Compilation Summary:
• Blackboxed modules are distinguished as having definition or not having definition, and by whether they were
blackboxed by the user or automatically. Note that blackboxed modules are also identified in the setup report and in
the setup summary of the main report. There may be discrepancies due to later blackboxing of arithmetic operators –
see Handling Arithmetic Operators.
• Blackboxed big ids are large arrays that are not modeled. These arrays exceed size limitations set by variables and do
not meet the requirements to be recognized as a RAM. Only the array itself is not modeled; it has no drivers and is not
a load. Refer to the section on large arrays.
• Blackboxed big loops are loops (such as a for-loop or while-loop) that exceed the threshold specified by
ri_max_loop_unroll. As with large arrays, the loop is not modeled when the threshold is exceeded.
• Synthesizable model modules are modules that automatically replaced a non-synthesizable simulation model.

• Empty modules are modules that have no synthesizable content.
• Code ignored by pragmas is the number of code segments that are ignored due to synthesis on/off directives
• Code ignored by protected is code that is not readable due to regions of protected/encrypted code.
• Ignored protected code is code that cannot be read into the tool due to encryption.
• Nonsynthesizable RTL is code that is ignored because it is not synthesizable.
• Unsupported constructs is code that is ignored due to an unsupported construct.
• RAMs are large arrays that meet the criteria for RAM recognition. How a RAM is treated by the tool varies by the tool.
See Identification of RAMs for more information.

read_design_db
Reads a saved design database into Meridian CDC from the project directory. Once the design is elaborated, you can
choose to do verification runs using the existing database using the command read_design_db <top_design_name>.
This command reads a saved database instead of doing a full analyze/elaborate on the source again. By default, if the
<top> is not specified, the last elaborated design is used. It is recommended to use the default in cases where the top
level uses generics or parameters.
The log file provides a pointer to the compilation log file, elab_<top_design_name>.log, which is saved in the project
directory (location stored in the ri_project_directory_name). When the design source has not changed, this command is
much faster than compiling and elaborating again.
The verification log file states:

**> read_design_db
Reading design "eth_top" database compiled "Date 6/13/2012, Time
Compilation log is "meridian_project/elab_top.log"
Reading data for design "eth_top" from disk
Note: you cannot load different levels of the hierarchy from what was elaborated. Only the elaborated view can be read.
SYNTAX
string read_design_db
[<top_design_name>]
[-project <project_directory>]
Data Type
top_design_name string
project_directory string
ARGUMENTS
<top_design_name>
[Optional] The name of the top level design name whose data is to be restored. When no design name
is provided, the default is to use the top level design from the most recent elaborate command.
If the -project option is not used, the default project directory is used.
For VHDL designs, the design_name should be specified as library.entity.arch. For Verilog designs, the
name is typically the top level module name that was elaborated.
It is recommended that you not provide a design name when parameters or interfaces are used in the
top level module because the design_name is uniquified when parameters or interfaces exist in the top
level module.
-project <project_directory>
The name of the project directory which contains the data.
EXAMPLES
• Example-1 : Read in verilog design whose top module is MODA
prompt> read_design_db MODA

• Example-2 : Read in the last elaborated design in project directory run2

prompt> read_design_db -project run2
RELATED COMMANDS
analyze
elaborate
RELATED VARIABLES
ri_project_directory_name

read_liberty
Read a Liberty file (.lib) into a -v library file and make the cells visible for elaboration. The cells are converted to
Verilog files in the <project_directory>/liberty directory, then automatically analyzed.
The read_liberty command can produce “functional” Verilog if enough information is available in the Liberty file;
otherwise, it produces “timing” Verilog based on the timing arcs described in the file. The default behavior is to use
as much of the functional information as possible, filling in with timing information for pins that have no functional
description. You can use the -functional_only option to override this default behavior: Instead of falling back to a
timing model if the functional model is not possible, halt with an error. In addition, you can use the -timing_only
switch if you want the functional information ignored, and to produce only the timing model.
The read_liberty command can be called with one file, a list of files, or with the -f option to read a text file containing
a list of .lib files to be converted and analyzed. The command output looks like this:
**> read_liberty /home/me/src/part0.lib

INFO [#103001] : Parsing Liberty file "/home/me/src/part0.lib".
INFO [#103003] : on line 111274 in file /home/me/src/part0.lib
: Writing Verilog functional model for cell "DFFSX4".
INFO [#103002] : Writing conversion report to "meridian_project/liberty/part0.rpt".
INFO [#19001] : Analyzing file "meridian_project/liberty/part0.v".
In addition to the Verilog file, a report file is also generated. This file tells how many cells in the Liberty file were
converted into functional models, and how many were converted into timing models.
You can use the read_liberty -translate_only option when you want to examine the intermediate generated Verilog
files.
The following zipped file formats are supported: .gz, .zip, .Z, .bz2, .tar, and .tar.gz. Support for .tar and .tar.gz files
has the following restrictions:
1. The tar file must contain a “single” .lib file.
2. The tar’ed .lib filename must not contain directory paths.
The zip file’s installation path (for example, /usr/bin/gzip) is required to be on the PATH search variable.
SYNTAX
read_liberty
file
[-blast_bussed_pins]
[-collapse_indexed_pins]
[-f file]
[-functional_only]
[-map_lsb_first]
[-timing-only]
[-translate_only [-vhdl][-library_dir dir | -library_file file]]
[-help]
Data Type
dir string
file string

ARGUMENTS
file
Name of one or more Liberty files.
[-blast_bussed_pins]
Expand bus ports into indexed pins; for example, a[1:0] becomes a[0], a[1].
[-collapse_indexed_pins]
Collapse indexed pin names into buses; for example, a[0], a[1] becomes a[1:0].
[-f file]
Text file containing list of .lib files to be read.
[-functional_only]
Report an error if any pin lacks a functional description. With this option, instead of falling back to a
timing model if the functional model is not possible, it will halt with an error.
[-library_dir]
In -translate_only mode, generate a -y library directory, <lib>-timing and <lib>-functional, that contain
the generated library files.
[-library_file]
In -translate_only mode, generate -v library files instead of a -y library directory. (default).
[-map_lsb_first]
Make collapsed bus with ascending range (such as a[0:3], which is the default).
[-timing_only]
Functional models are not needed, just timing.
[-translate_only]
Write converted .v files in current directory instead of the project directory, and do not automatically
analyze them. Any functional models are written to a file <lib>-functional.v. Any timing models
are written to <lib>.rpt. The options -library_dir, -vhdl, and -library_file are only useful with the -
translate_only option.
[-vhdl]
In -translate_only mode, generate VHDL wrappers into <lib>-wrapper.vhd. This option is used when you
have VHDL components that have the ports in a different order than the .lib cell, so that only a VHDL
instantiation would get it right.
[-help]
EXAMPLES
• Example-1 : Read my.lib file
prompt> read_liberty -f my.lib
RELATED COMMANDS
analyze
RELATED VARIABLES

Liberty Functional Model

The conversion from Liberty to Verilog looks for functional behavior information for each output or internal pin in the
cell. This section gives some examples of Liberty structures that describe the function of a pin or a bus. Note: the
examples illustrate just part of the behavior, and they are edited to highlight the functional parts of a cell description.
For more information on the Liberty format, please consult the Liberty Reference Manual available from http://
www.opensourceliberty.org/.
function:
Liberty cell:
pin(CO0) {
direction : output;
function : "(((A ^ B) !CI0N) | (A B))";
}
Verilog:
// output function
// /home/me/src/cells.lib:309
assign CO0 = (((A ^ B) & ~CI0N) | (A & B));
state_function:
Liberty cell:
pin(ECK) {
direction : output;
state_function : "CK * ENL";
}
Verilog:
// output function
assign ECK = CK & ENL;
statetable/internal_node:
Liberty cell:
statetable( "CK E", "ENL") {
table : "L L : - : L,\
L H : - : H,\
H - : - : N";
}
pin(ENL) {
direction : internal;
internal_node : "ENL";
}
Verilog:
/ internal node function
always @(*) begin
// latch enable
if (!CK) begin
ENL <= (E);
end
end
three_state:
Liberty cell:
pin(RB) {
direction : output;

function : IQ;
three_state : "RWN & !RW";
}
Verilog:
// output function
// /home/me/src/part1.lib:74746
assign RB = (RWN & ~RW) ? 'bz : (IQ);
memory_read:
Liberty cell:
bus(QB) {
direction : output;
memory_read() {
address : ADRB ;
}
timing() {
related_pin : "CLKB";
timing_type : rising_edge
when : "( OEB & !BISTEB & !AWTB ) | ( TOEB & BISTEB & !AWTB )";
}
}
Verilog:
// memory read
// /home/me/src/basic.lib:486
always@(posedge CLKB)
if (( OEB & !BISTEB & !AWTB ) | ( TOEB & BISTEB & !AWTB ))
QB <= mem_16x32[ADRB];
memory_write:
Liberty cell:
bus(DA) {
direction : input;
memory_write() {
address : ADRA ;
clocked_on : CLKA ;
}
timing() {
timing_type : setup_rising;
related_pin : "CLKA";
when : "WEA & !BISTEA & MEA";
}
}
Verilog:
// memory write
always@(posedge CLKA)
if (WEA & !BISTEA & MEA)
mem_16x32[ADRA] <= DA;
ff/ff_bank:
Liberty cell:

ff(IQ,IQN) {
clocked_on : "!CKN";
next_state : "(SE SI) + (!SE D)";
clear : "!RN";
preset : "!SN";
clear_preset_var1 : H;
clear_preset_var2 : L;
}
Verilog:
// ff group
// /home/me/src/part1.lib:77789
always @(negedge CKN or negedge RN or negedge SN)
begin
if (~RN && ~SN) begin
IQ <= 1'b1;
IQN <= 1'b0;
end
else if (~RN) begin
IQ <= 1'b0;
IQN <= 1'b1;
end
else if (~SN) begin
IQ <= 1'b1;
IQN <= 1'b0;
end
else begin
IQ <= (SE & SI) | (~SE & D);
IQN <= ~((SE & SI) | (~SE & D));
end
end
latch/latch_bank:
Liberty cell:
latch_bank(IQ,IQN,4) {
enable : G;
data_in : D;
}
Verilog:
// latch group
// /home/me/src/latch1.lib:14
always @(*)
begin
if (G) begin
IQ <= { D1, D2, D3, D4 };
IQN <= ~({ D1, D2, D3, D4 });
end
end
Generated Clocks:
The generated clock staments in the .lib are translated into Real Intent pragmas in the generated Verilog model if the
Tcl variable ri_extract_genclks_from_liberty is set to true (default). As an example:
Liberty definition:
generated_clock ( calclk_x4_a ) {

clock_pin : calclk_x4_a ;
master_pin : vco_clk_a ;
divided_by : 8 ;
}
Verilog Comment:
// ri create_generated_clk 'calclk_x4_a' -divide_by 8 -source vco_clk_a -location cw.lib:193
-pins { calclk_x4_a }
The Liberty extracted generated clocks are used in the environment. Upon reading any constraint file (SDC) in the
control file using the read_sdc command, an SDC file is written out that defines all the generated clocks in the Liberty
file, and the generated clock commands are automatically read in. The ri_extract_genclks_filename variable controls
the name of the generated file. By default, the file is <project_dir>/liberty/read_lib.sdc.

Liberty Timing Model

Any pins or buses that are not given functional behavior by any of the constructs listed in Liberty Functional Model, or
because the user has selected the -timing_only option, will be sampled or driven by registers whose timing reflects the
timing_type and related_pin attributes of the timing() constructs in the Liberty description of the bus or pin.

Output Timing
For output or internal pins and buses, sequential timing is inferred from timing groups whose timing_type is either
rising_edge or falling_edge. For example, if an output bus called “dout” contains a timing group like this:
timing() {
related_pin : "rclk";
timing_type : rising_edge;
}
That timing group will be represented in the Verilog module like:

// output timing arc
reg [95:0] dout_REALINTENT_SEQ_0 ;
always @(posedge rclk)
begin
dout_REALINTENT_SEQ_0 <= 'bx;
end
assign dout = dout_REALINTENT_SEQ_0 ;
There may be more than one driver of a bus or pin, if there are multiple timing arcs with different related pins or
timing_types.
Combinational timing for output or internal pins and buses is inferred from timing groups whose timing_type is one of
the following:
combinational
preset
clear
three_state_disable
three_state_enable
Combinational timing is also inferred if the timing group does not have a timing_type attribute, because the default
timing_type is combinational. Here is an example of a timing group that will result in a combinational model:
timing() {
related_pin : "byp";
timing_type : combinational;
}
The corresponding Verilog will look like this:
// output timing arc
reg [95:0] dout_REALINTENT_COMB_2 ;
always @(*)
begin
if (byp) dout_REALINTENT_COMB_2 = 'bx;
else dout_REALINTENT_COMB_2 = 'bx;
end
assign dout = dout_REALINTENT_COMB_2 ;
As noted above, there can be multiple drivers of a bus or pin, and one pin may be driven by both combinational and
sequential logic.

Input Timing
When the -timing_only switch is used, or when an input bus or pin has not been referred to in any functional
descriptions, input timing arcs will be created based on the timing() groups whose timing type is one of the following:
setup_rising
hold_rising
setup_falling
hold_falling
For example, if an input pin called “web” has the following timing group:
timing() {
timing_type : setup_rising;
related_pin : "wclk";
}
The following Verilog will be produced:
// input timing arc

reg web_0_REALINTENT;
always @(posedge wclk)
begin
web_0_REALINTENT <= {web} | ({web} & web_0_REALINTENT & ~web_0_REALINTENT);
end
The righthand side of the assignment may look a little convoluted. It is that way in order to avoid any kind of noisy
warnings about unused variables during elaboration, while still providing the correct timing information. But the model
accurately captures the desired behavior.

read_library_map
Read a VHDL library mapping file that specifies the mapping between logic libraries and physical compiled libraries.
The physical library should be compiled first using analyze -work.
SYNTAX
read_library_map
filename
[-help]
Data Type
filename string
ARGUMENTS
file_name
The name of the library mapping file.
[-help]
EXAMPLES
Example-1 : Map the logical aliases in library_map.txt to the physically compiled library
prompt> analyze -work scanlib /home/users/source/scanlib.pkg
prompt> read_library_map library_map.txt

The contents of library_map.txt are:
unit_a_scanlib > scanlib
unit_b_scanlib > scanlib
unit_c_scanlib > scanlib
RELATED COMMANDS
analyze
RELATED VARIABLES

CDC Commands
Following commands are used to configure and run CDC Verification.

create_association
Specify user Control-Data association of Clock Domain Crossings.
SYNTAX
string create_association
-name <association_name>
-cntl_rx <cntlrx_list>
[-data_rx <datarx_list>]
[-data_tx <datatx_list>]
[-cntl_fb <cntlfb_list>]
[-match_subset]
[-module <module_name> [-exclude_instances <exclude_instances>] | -instances <instances>]
[-comment <comments>]
[-replace]
Data Type
association_name string
datarx_list list or collection
datatx_list list or collection
cntlrx_list list or collection
cntlfb_list list or collection
module_name string
exclude_instances list or collection
instances list or collection
comment string
ARGUMENTS
[Optional] Specifies the name for the user-defined Control-Data association. If the name is omitted,
the name is automatically added by Meridian CDC.
-data_rx <datarx_list>
[Optional] Specifies list of <datarx_list> for association to be created. Names of <datarx_list> can
either be a list of signal names or a collection. When use with -module option, all <datarx_list> names
should be limited to module scope and collection cannot be used.
-data_tx <datatx_list>
[Optional] Specifies the list of <datatx_list> to be associated with <datarx_list>. Names of
<datatx_list> can either be a list of signal names or a collection. When use with -module option, all
<datatx_list> names should be limited to module scope and collection cannot be used.
Specifies the list of <cntlrx_list> to be associated with <datarx_list>. this is a mandatory option.
Names of <cntlrx_list> can either be a list of signal names or a collection. When used with -module
option, all <cntlrx_list> names should be limited to module scope and collection cannot be used.
-cntl_fb <cntlfb_list>
List of CNTL Feedback receive signals for creating the association

-match_subset
The specified association constitutes the complete interface set, even if the DATA receive signal
is controlled by other controls or has other transmitters in the design. Meridian CDC reports the
U_INTERFACE that contains DATA Rx with the specified CNTLs, and DATA Txs. The rest of the CNTLs and
Data Txs for this DATA Rx are listed as W_INTERFACE.
Note: This does not change DATA/W_DATA/CNTL reporting.
-module <module_name>
Specify the module (or design) name the association to be applied to. When -module is used, all
<datarx_list>, <datatx_list>, and <cntltx_list> names should be limited to module scope. When
-module is used, association is applied to all the instances of the given <module_name>, use -
exclude_instances if certain instances of the module need to be exempted. The -module and -
instances options are mutually exclusive, you must use only one.
-exclude_instances <exclude_instances>
Specifies the list of instances the association to be excluded from. The -exclude_instances option is
only valid with -module option, use of -exclude_instances with -instance option is a command syntax
error. Names of the <exclude_instances> can either be a list of names or a collection.
-instances <instances>
Specifies the list of instances the association is applied to. When -instance is used, all <datarx_list>,
<datatx_list>, and <cntltx_list> names should be full path from top level. Names of the instances can
either be a list of names or a collection. The -instances and -module options are mutually exclusive,
you must use only one.
-comment <comments>
Specifies the comments to be added to the user defined association to help track the history.
-replace
Indicates existing association to be removed and replace with the given association if the association
with <> exists.
DESCRIPTION
Command create_association allows users define Control-Data association for known good Clock Domain
Crossings. User defined associations are taken into consideration during structural analysis, User defined
association will have an impact on how the Control-Data Clock Domain Crossings are reported under
INTERFACE rule.
Also user-defined associations are stored in the database and can be accessed through DB access commands.
EXAMPLES
• Example-1 : create an association with name good_ifc
prompt> create_association -name good_ifc \
-data_rx uut2.r_din_rx \
-data_tx uut2.r_din \
-cntl_rx uut2.r_cin_rx \
-cntl_fb uut2.r_cin_fb_rx \
-comment "This is for the lab"
RELATED COMMANDS

remove_association
RELATED VARIABLES
None

exclude_cntl_from_recon
Set a list of cntl signals excluded from recon
SYNTAX
string exclude_cntl_from_recon
-name <usync_name>
[-replace]
<sig_list>
Data Type
usync_name string
module_name string
comments string
sig_list list or collection
ARGUMENTS
-name <usyn_name>
[Required] Specifies the name for this list.
[Optional] The -module and -instances options are mutually exclusive, you must use only one. Specify
the module (or design) name user defined control synchronizer to be applied to. When -module
is used, command is applied to all the instances of the module, use -exclude_instances if certain
instances of the module need to be excluded.
[Optional] The -exclude_instances option is only valid with -module option, use of -exclude_instances
with -instance option is a command syntax error. Specifies the list of instances the command to be
excluded from. Names of the <exclude_instances> can either be a list of names or a collection.
[Optional] The -instances and -module options are mutually exclusive, you must use only one.
Specifies the list of instances the command to be applied to. Names of the <instances> can either be a
list of names or a collection.
-comment <comments>
[Optional] Specifies the comments to be added to the command to help track the history.
-replace
[Optional] Indicates existing <usync_name> to be removed and create a new user defined control
synchronizer. If the <usync_name> does not exist, it still creates a new user defined control
synchronizer with given information.

<sig_list>
List or collection of signal names in design
EXAMPLES
• Example-1 :
prompt> exclude_cntl_from_recon -name data_signals {din}
RELATED COMMANDS
RELATED VARIABLES

read_cdc_db
Specify the block-level cdc data-base information for use in CDC hierarchical analysis
SYNTAX
string read_cdc_db
-block_proj_dir <dir_name>
-name <dname>
[-instances <instances> | -exclude_instances <instances>]
[-dry_run]
[-verbose_log]
[-verbose_rpt]
Data Type
dir_name string
name string
instances list
ARGUMENTS
-block_proj_dir <dir_name>
Specify the path to the sub directory below the meridian_project directory that corresponds to the
block.
-dry_run
Display database contents without proceeding with any checking.
-exclude_instances
Specify list of instances (full hierarchical names) that need to be excluded.
-instances
Specify list of instances (with full hierarchical names) to which to apply the CDC database
-name
Specify name of the CDC database written during the block-level run.
-verbose_log
Request verbose details regarding database content in the log file.
-verbose_rpt
Request verbose details regarding database checks in the report.
EXAMPLES
• Example-1 :
prompt> read_design_db -block_proj_dir meridian_project/block -name block
RELATED COMMANDS

analyze_intent
RELATED VARIABLES
None

remove_association
Remove association of specified Control (CNTL) and Data (DATA) Crossings.
SYNTAX
string remove_association
-name <deassociation_name>
[-data_rx <datarx_list>]
[-comment <comment>]
Data Type
deassociation_name string
module_name string
comment string
ARGUMENTS
-name <deassociation_name>
[Required] Specifies the name for the user defined remove association.
[Required] Specifies the list of <cntlrx_list> not to be considered for CNTL-DATA association globally
when -data_rx option is not provided or not to consider as CNTL signals for specified <datarx_list>
crossings. The signals of <cntltx_list> can either be a list of signal names or a collection of CNTL
RxFlops
[Optional] Specifies list of <datarx_list> signals that are to be de-associated from <cntl_rx> signals.
The signals of <datarx_list> can either be a list of signal names or a collection of DATA RxFlops.
[Optional] The -module and -instances options are mutually exclusive, you must use only one.
Specify the module (or design) name the de-association to be applied to. When -module is used, all
<datarx_list> and <cntlrx_list> names should be limited to specified module scope. When -module
is used, association is removed from all the instances of the given module, use -exclude_instances if
certain instances of the specified module to be exempted. The <module_name> can either be a name
or a collection containing a single deisgn object.
[Optional] The -exclude_instances option valid only with -module option, use of -exclude_instances
with -instances option is a command syntax error. Specifies the list of instances of the <module_name>
deassociation to be excluded from. The <exclude_instances> can either be a list of names or a
collection.

Specifies the list of instances the de-association is applied to. When -instances is used, all
<datarx_list> (optional) and <cntlrx_list> names should be based on the instance scope (not the full
path from top level). Names of the <instances> can either be a list of names or a collection.
-comment <comment>
Specifies the comments to be added to the user defined deassociation to help track the history.
DESCRIPTION
Command remove_association enables user to configure certain CNTL signals to be not considered for CNTL-
DATA association.
EXAMPLES
• Example-1 : Remove specific CNTLs from association. This results in specified CNTL to be reproted as
association NONE.
prompt> remove_association -name mode_selects \

prompt> ? -cntl_rx {a.b.mode_sel_reg}
RELATED COMMANDS
create_association
set_cntl_association_depth
RELATED VARIABLES

report_cdc_db
Report CDC database available in the current project directory or user specified project directory.
SYNTAX
string report_cdc_db
[-proj_dir <dir_name>]
[-verbose]
Data Type
dir_name string
ARGUMENTS
-proj_dir <dir_name>
[Optional] Report CDC dbs in the specified project directory, <dir_name>. If project directory
<dir_name> is not specified, CDC dbs in the current project directory are reported.
-verbose
[Optional] Indicates that the report to include complete details of CDC db information, including the
design specification summary, in the specified project directory. Absence of -verbose, by default,
summary of the CDC db available in the project directory is generated.
DESCRIPTION
Command report_cdc_db reports the CDC db saved in the given project directory <dir_name>. If the project
directory has not been specified, CDC dbs saved in the current project directory are reported. If the project
directory has been specified, all the CDC dbs in the specified directory are reported. The -verbose option
allows details of each CDC db to be reported. Please see examples below for more details how CDC db
information is reported.
EXAMPLES
• Example-1 : Report summary of CDC dbs in the specified project directory
prompt> report_cdc_db /home/user1/block/bluetooth/meridian_project
Command : report_cdc_db -project_dir /home/user1/block/bluetooth/meridian_project

Product : ri_product_name - ri_product_version
User/Host : user on host
Date/Time : 01/14/2014 - 13:16:25
=========================================================
Properties:
V1 - CDC db Version
V2 - CDC db Version
------------------------------------------------------------------------
Module ModuleRef cdcDbName Properties
------------------------------------------------------------------------
bt_functional-3-4-5 bt_functional func_mode_0 V1

bt_functional-4-5-3 bt_functional func_mode_2 V1

bt_functional-3-4-5 bt_functional sleep_mode V2
....
....
------------------------------------------------------------------------
RELATED COMMANDS
read_cdc_db
analyze_intent
RELATED VARIABLES
None

set_cntl_association_depth
Specify the depth from control (CNTL) synchronizer output to data (DATA) association to be searched.
SYNTAX
string set_cntl_association_depth
<depth_to_associate>
[-replace]
Data Type
depth_to_associate integer
module_name string
comment string
ARGUMENTS
[Required] Specifies the name for the user defined association depth for certain CNTL crossings, the
name provided is used in the report where association is being used.
<depth_to_associate>
[Required] Specifies the depth for CNTL synchronizer output to look for DATA to be associated. The
depth can be 0 or positive number. The default is 2.
[Required] Specifies the list of <cntlrx_list> the <depth_to_associate> to be applied to. Names of
<cntlrx_list> can either be a list of signal names or a collection containing <cntlrx_list>.
the module (or design) name where the control association depth to be limited to. When -module is
used, all <cntlrx_list> names should be based on module scope.
[Optional] The -exclude_instances option is valid only with -module option and mutually exclusive with
-instance option. Specifies the list of instances of the <module_name> the control association depth to
be excluded from. The <exclude_instances> can either be a list of names or a collection.
Specifies the list of instances the association to be applied. When -instance is used, all <cntlrx_list>

names should be based on the instance scope (not the full path from top level). Names of the
instances can either be a list of names or a collection.
-comment <comment>
[Optional] Specifies the comments to be added to the user defined CNTL association depth.
-replace
[Optional] Indicates that <association_name> to be removed, if exists and re-create with specified
information, or previously defined association depth on <cntlrx_list> to be removed and re-assign the
specified value. When no <association_name> or no association depth on <cntlrx_list> has previously
not been defined, -replace option has no effect.
DESCRIPTION
Command set_cntl_association_depth allows user to configure CNTL to DATA association depth. This CNTL-
DATA association depth which instructs Meridian CDC search DATA from CNTL synchronizer output up to
<association_depth> while forming a clock domain crossing interface. The default CNTL-DATA association
depth is 2, meaning that Meridian CDC searches two flop depths from synchronizer output to see if CNTL
controls any DATA crossing.
Command set_cntl_association_depth can be used to configure CNTL-DATA association depth globally, as well
as on individual CNTLs, to meet the CDC intent. When configuring individual CNTLs, association depth should
be applied to CNTL-RX flops, options -module and -instances provide fleaxibility to specify association depth
based on the specific scope. Also, command takes collections as valid value, enabling Object Access Commands
to be used when specifying design objects. User defined CNTL-DATA <association_name> is used in the report
to indicate where user association depth configuration has been taken into consideration. User association
depth can be override by -replace option, without -replace option, first user configuration is always used (with
a message indicating that later setting being rejected), please see below examples for more details.
EXAMPLES
• Example-1 : Setting CNTL association depth to 3 globally, it is named as "my_default"
prompt> set_cntl_association_depth 3 -name my_default
• Example-2 : When multiple global association depths are specified, first one is taken into consideration,
unless -replace is used. Following example shows that association depth "default_b" and "default_c" have been
ignored (with a message to indicate such) due to lack of -replace option
prompt> set_cntl_association_depth 1 -name default_a

prompt> set_cntl_association_depth 3 -name default_b
prompt> set_cntl_association_depth 2 -name default_c
• Example-3 : In the following example "default_b" is used as global association depth (with a message
indicating as such) as -replace option in the second command overrides the "default_a" association depth
prompt> set_cntl_association_depth 1 -name default_a

prompt> set_cntl_association_depth 2 -name default_b -replace
Example-4 : Following example shows how association depth can be configured on specific CNTLs. Signals a/b/
c_rx_reg and x/y/z_rx_reg are configured for association to be limited up to 1 flop depth

prompt> set_cntl_association_depth 1 -name axi_hand_shake -cntl_rx {a/b/c_rx_reg x/y/

z_rx_reg}
Example-5 : When <cntlrx_list> signals are overlapped between the commands, later settings are ignored. In
below example, a/b/c_rx_reg is configured to depth 2 from "my_cntls" association and signal a/b/c_rx_reg is
ignored (with a message indicating as such) from "axi_hand_shake" association. However, x/y/z_rx_reg is taken
into consideration

prompt> set_cntl_association_depth 2 -name my_cntls -cntl_rx {a/b/c_rx_reg}
prompt> set_cntl_association_depth 1 -name axi_hand_shake -cntl_rx {a/b/c_rx_reg x/y/
z_rx_reg}
RELATED COMMANDS
create_association
remove_association
RELATED VARIABLES

set_glitch_free_inputs
Specify a list of glitch-free input signals.
SYNTAX
string set_glitch_free_inputs
-name <gfi_name>
<gf_inputs>
[-replace]
Data Type
gfi_name string
gf_inputs list or collection
module_name string
comments string
ARGUMENTS
-name <gfi_name>
[Required] Specifies the name for the glitch free inputs user constraints.
<gf_inputs>
[Optional] Specifies the primary inputs that are to be considered as glitch free for analysis.
Specify the module (or design) name user defined control synchronizer to be applied to. When -
module is used, user defined control synchronizer is applied to all the instances of the module, use -
exclude_instances if certain instances of the module need to be excluded.
with -instance option is a command syntax error. Specifies the list of instances the user defined
control synchronizer to be excluded from. Names of the <exclude_instances> can either be a list of
names or a collection.
Specifies the list of instances the user defined control synchronizer to be applied to. Names of the
<instances> can either be a list of names or a collection.
-comment <comments>
[Optional] Specifies the comments to be added to the user defined control synchronizer to help track
the history.
-replace

[Optional] Indicates existing <gfi_name> to be removed and create a new user defined glitch free
input constraints. If the <gfi_name> does not exist, option -replace is ignored and glitch free user
inputs be created with the <gf_name> specified.
EXAMPLES
• Example-1 :
prompt> set_glitch_free_inputs -name gfi {din}
RELATED COMMANDS
RELATED VARIABLES
ri_assume_primary_inputs_have_glitch_potential

set_max_search_depth
Specify the depth to search for convergence and fanout of the Control or Reset crossings and association depth for
Control crossings.
SYNTAX
string set_max_search_depth
-name <search_depth_name>
-association | -fanout | -recon | -rst_fanout | -rst_recon | -fb_cntl_tx | -fb_data_tx <depth>
[-replace]
Data Type
search_depth_name string
depth integer
comments string
ARGUMENTS
-name <search_depth_name>
[Required] Specifies a name for max search depth. You can use the same name in different commands;
also, different commands with same settings can have different names.
-association | -fanout | -recon | -rst_fanout | -rst_recon | -fb_cntl_tx | -fb_data_tx <depth>

[Required]
• -association <depth> specifies the depth for CNTL-DATA association. The association depth is valid
only for CNTL crossings; -associaton cannot be used together with -reset. The default is 2.
• -fanout <depth> specifies the depth to search for fanout of CNTL crossings. The default is 1.
• -recon <depth> specifies the depth to search for reconvergence of CNTL crossings. The default is 3.
• -rst_fanout <depth> specifies the depth to search for fanout of reset crossings. The default is 1.
• -rst_recon <depth> specifies the depth to search for reconvergence of reset crossings. The default is
2.
• -fb_cntl_tx <depth> specifies the depth to search along the FEEDBACK-to-CNTL Tx path. If <depth>
is 0, Meridian CDC ignores missing FEEDBACK-to-CNTL Tx paths. If <depth> is greater than 0, Meridian
CDC reports a violation if the depth of the FEEDBACK-to-CNTL Tx path exceeds the value. The default
is 0.
• -fb_data_tx <depth> specifies the depth to search along the FEEDBACK-to-DATA Tx path. If <depth>
is 0, Meridian CDC ignores missing FEEDBACK-to-DATA Tx paths. If <depth> is greater than 0, Meridian
CDC reports a violation if the depth of the FEEDBACK-to-DATA Tx path exceeds the value. The default
is 0.
-comment <comments>
[Optional] Specifies comments to be added to the user-defined search depth, to help track the history.
-replace
[Optional] Indicates that any existing synchronizer depth with <search_depth_name> is to be deleted,
if it exists, and a new one created with the given specification.
DESCRIPTION

You can use the set_max_search_depth command to configure search depth for CNTL-DATA association,
reconvergence, and fanout of CNTL or Reset crossings. The search depth overrides the Meridian CDC built-in
defaults. By default, Meridian CDC searches one flop depth from synchronizer output to see whether CNTL
controls any DATA crossing.
Interface related Search Depth
Consider the simple interface example below. It has two clock domains, which are shown in blue (C1) and red
(C2). DATA and CNTL form an interface (CNTL controls DATA) because all the following conditions are met:
1. At least one path exists from CNTL's SyncOut (labeled "So" in C2) to DATA's Rx.
2. The depth D1 of the shortest path (measured in terms of number of flip-flops/RAMs between So and
DATA Rx) does not exceed a certain number.
3. All flip-flops/RAMs on that path are in the C2 domain.
The search depth here can be calculated by adding 1 to number of flip-flops/RAMs on a path between
So and Rx/Tx flop. So if number of flip-flops on the path from So to Rx is 0, then search depth is 0+1 =
1. D1 is value of association search depth and should be used with -association option. You can use the
set_max_search_depth command to set the maximum value for D1 globally. The maximum value for D2 is D1+1
(you do not need to set D2 separately). You can use the -fb_cntl_tx and -fb_data_tx options to control the
boundaries of D3 and D4, respectively.
Fanout Search Depth
Fanout search depth is calculated backwards starting from first flop of synchronizer. It can be calulated by
adding 1 to number of flip-flops on a path between first flop of the synchronizer and driving flop. To change
the value related to CNTL crossings use -fanout option with this command. Use -rst_fanout option to change
fanout depth related to reset crossings.

Recon Search Depth
Recon search depth is calculated forward starting from last (Syncout) flop of synchronizer. It can be calulated
by adding 1 to number of flip-flops on a path between last flop of the synchronizer and receiving flop. To
change the value related to CNTL crossings use -recon option with this command. Use -rst_recon option to
change recon depth related to reset crossings.

Any user-defined seach depth must be associated with a <search_depth_name>, which must be a unique
name for each user defined search depth. This <search_depth_name> is going to be linked from the report
where user-defined search depth is used for analysis, therefore <search_depth_name> must be a unique
identifier. The option -replace is provided to override the <search_depth_name> if previously defined, if -
replace is not provided, second <search_depth_name> is ignored with a message to indicate such scenario.
The option -comment provides annotation of the user description to the search depth to help track the
requirements for default override.
EXAMPLES
• Example-1 : Setting CNTL association depth to 3 with user comments annotated
prompt> set_max_search_depth -name cntl_assoc_depth -association 3\

prompt> ? -comment "Association depth requirement for my project A"
• Example-2 : Specify -fanout and -recon depth for CNTL crossings
prompt> set_max_search_depth -name cntl_fanout_depth -fanout 1

prompt> set_max_search_depth -name cntl_recon_depth -recon 3
• Example-3 : In the following example shows how <search_depth_name> "default_a" can be overridden from
the later definition.
prompt> set_max_search_depth -name default_a -association 1

prompt> set_max_search_depth -name default_a -fanout 1 -replace
Example-4 : Following example sets Reset reconvergence depth to be 3
prompt> set_max_search_depth -name rst_recon_depth -rst_recon 3\

prompt> ? -comment "Reconvergence depth requirements for the project"
Example-5 : Following example disables check for missing feedback-to-control Tx paths
prompt> set_max_search_depth -name disable_checks -fb_cntl_tx 0

RELATED COMMANDS
read_cdc_db
set_shell_instances
verify_cdc
RELATED VARIABLES

set_mutex_signals
Set a list of mutual exclusive signals. This command is used to specify signals in the design which cannot transition
together.
a) So if in a design all signals reported in a violation can not transition together. All can be defined in
set_mutex_signals command
b) If only few out signals out of all reported in a violation can not transition together only those signals which
can not transition together should be specified in set_mutex_signals
SYNTAX
string set_mutex_signals
-name <name>
[-comment <comments>] [-collate_signals]
[-error_on_missing_signals]
<sig_list>
Data Type
name string
module_name string
comments string
ARGUMENTS
-name <name>
[Required] Specifies identifier for this particular command.
<instances> can either be a list of names or a collection. Any specific set of instances can be specified,
but all should belong to the same module.
-comment <comments>

the history.
-collate_signals
[Optional] This option causes Meridian CDC to collate all signals in sig_list argument. Useful when -
module
or -instances option is used. See Notes: section in Examples for more details.
-error_on_missing_signals
[Optional] This option causes Meridian CDC to terminate this command with an error, instead of a
warning, for missing signals.
<sig_list>
List of signal names in the design.
EXAMPLES
• Example-1 :
prompt> set_mutex_signals -name n1 {sig1 sig2}
Notes:
• When set_mutex_signals is used with -module or -instances, the interpretation is "foreach" module/instance.
For example, the following command
set_mutex_signals -name cdc_path -instances {u1 u2} {a b c}
is equivalent to the following two commands
set_mutex_signals -name cdc_path {u1.a u1.b u1.c}
set_mutex_signals -name cdc_path {u2.a u2.b u2.c}
• When set_mutex_signals is used with -module or -instances with -collate_signals option, then all signals are
combined together before command is applied. For example, the following command
set_mutex_signals -name cdc_path -instances {u1 u2} {a b c}
is equivalent to the following 1 commands
set_mutex_signals -name cdc_path {u1.a u1.b u1.c u2.a u2.b u2.c}
• When there are multiple set_mutex_signals commands that can impact a particular violation, Meridian CDC
uses the command that is most restrictive. For example, consider a W_RECON_GROUPS with signals u1.a,u1.b,
and u1.c. If the following two set_mutex_signals commands are specified
a. set_mutex_signals -name u_cdc_1 { u1.a u1.b}
b. set_mutex_signals -name u_cdc_2 { u1.a u1.b u1.c }
the second one (b) prevails because it is more restrictive and constrains more signals. The EngineComments
column contains information about the command applied on the violation.
• When there are multiple set_mutex_signals commands that can impact a particular violation, and all are
equally restrictive, Meridian CDC selects one at random. For example, consider a W_RECON_GROUPS with
signals u1.a,u1.b,u1.c, u1.p,u1.q, and u1.r. If the following two set_mutex_signals commands are specified
a. set_mutex_signals -name u_cdc_1 { u1.a u1.b u1.c }
b. set_mutex_signals -name u_cdc_1 { u1.p u1.q u1.r }
either a or b randomly can prevail because both are equally restricitive. The EngineComments column will
have information about the command applied on the violation.

RELATED COMMANDS
RELATED VARIABLES

set_shell_instances
Specify hierarchical instances in the design that are to be dynamically shelled out in the analysis.
SYNTAX
string set_shell_instances
-module <module_name> [-exclude_instances <exclude_instances>] | -instances <instances>
Data Type
module_name string or collection

exclude_instances string or collection
instances string or collection
ARGUMENTS
[Required] The -module and -instances options are mutually exclusive, you must use only one. Specify
the reference name of the instances <module_name> to be shelled out in analysis. When -module
is specified, all the instances of the given module are shelled out, use -exclude_instances if certain
instances of the module need to be exempted. The <module_name> can either be a string or a
collection containing design objects.
[Optional] The -exclude_instances option is valid only with -module option, use of -exclude_instances
with -instances option is a command syntax error. Specifies the list of instances to be shelled out .
Names of the <exclude_instances> must be a full name to instances and can either be a list of names
or a collection.
[Required] The -instances and -module options are mutually exclusive, you must use only one.
Specifies the list of hierarchical instances to be shelled out in analysis. Names of the <instances> must
be a full name to instances and can either be a list of names or a collection.
DESCRIPTION
Command set_shell_instances allows users to define certain hierarchical instances to be excluded (or shelled
out) for reporting. Any analysis results encapsulated inside the shelled instances are excluded from the report.
However, analysis around the interface (inputs and outputs of the shelled instances that interact with outside)
of the "shelled instances" are reported. This command is specifically useful to remove certain instances from
analysis which are incompleted or pre-verified.
Meridian CDC does not report violations when ModuleScope of the violation lies within or equal to the module
being shelled out. The ModuleScope is defined as the lowest design hierarchy (from bottom up) where all
design signals of the violations are well contained. If a violation has multiple drivers and even one of the
drivers lies outside the shelled module, Meridian CDC reports the full violation.
EXAMPLES
• Example-1 :

prompt> set_shell_instances -module mod1
RELATED COMMANDS
analyze_intent
verify_cdc
RELATED VARIABLES
None

set_synchronizer_depth
Specify the depth of the control (CNTL) or reset (RST) synchronizer.
SYNTAX
string set_synchronizer_depth
-name <sync_depth_name>
-min <min_depth> | -max <max_depth>
-rst_min <min_depth> | -rst_max <max_depth>
[-replace]
Data Type
sync_depth_name string
min_depth integer
max_depth integer
comment string
ARGUMENTS
-name <sync_depth_name>
[Required] Specifies the name for the user defined synchronizer depth.
-min <min_depth>
[Required] Either -min option or -max option is required. Specifies the minimum number of flops to be
required for the synchronizer. Valid range is 1 through 5. If this option is not specified, Meridian CDC
uses <min_depth> of 2.
-max <max_depth>
[Required] Either -min option or -max option is required. Specifies the maximum number of flops to
be required for the synchronizer. If <min_depth> is bigger than <max_depth>, <max_depth> is set to
same depth as <min_dpeth> with a message indicating such adjustment. Valid range is 1 through 32. If
this option is not specified, Meridian CDC uses <max_depth> of 3.
-rst_min <min_depth>
[Required] Either -min option or -max option is required. Specifies the minimum number of flops to be
required for the reset synchronizer. Valid range is 1 through 6. If this option is not specified, Meridian
CDC uses <min_depth> of 2.
-rst_max <max_depth>
[Required] Either -min option or -max option is required. Specifies the maximum number of flops to be
required for the reset synchronizer. If <min_depth> is bigger than <max_depth>, <max_depth> is set to
same depth as <min_depth> with a message indicating such adjustment. Valid range is 1 through 32. If
this option is not specified, Meridian CDC uses <max_depth> of 6.
-comment <comment>
[Optional] Specifies the comments to be added to the user defined synchronizer depth to help track
the history.
-replace

[Optional] Indicates that existing synchronizer depth <sync_depth_name> to be deleted, if exists, and
recreate with given specification.
DESCRIPTION
Command set_synchronizer_depth allows users to configure synchronizer depth for CNTL and Reset
synchronizers. The depth overrides the Meridian CDC built-in defaults, below is how search depth for -
association, -fanout, and -recon are taken into consideration during the analysis.
The synchronizer depth is applied to current design scope by default. Any user defined synchronizer depth
must be associated with a <sync_depth_name>, which must be a unique name for each user defined
synchronizer depth. This <sync_depth_name> is going to be linked from the report where user defined
synchronizer depth is used for analysis, therefore <sync_depth_name> must be a unique identifier. The option
-replace is provided to override the <sync_depth_name> if previously defined, if -replace is not provided,
second <sync_depth_name> is rejected with a message to indicate such scenario. The option -comment
provides annotation of the user description to the synchronizer depth to help track the requirements (or
reason) for default override.
EXAMPLES
• Example-1 : Setting minimum CNTL synchronizer depth to be 3 and maximum to be 4
prompt> set_synchronizer_depth -name cntl_sync_depth -min 3 -max 4 \

prompt> ? -comment "CNTL synchronizer depth requirement for project A"
• Example-2 : Setting minimum Reset synchronizer depth to be 3 and maximum to be 5
prompt> set_synchronizer_depth -name rst_sync_depth -rst_min 3 -rst_max 5 \

prompt> ? -comment "Reset synchronizer depth requirement for project A"
Example-3 : Following example shows how to define synchronizer depth for a specific module instantiated
prompt> set ip_target [get_designs hdmi]

prompt> set_synchronizer_depth -name ip_cntl_sync_depth \
prompt> ? -min 3 -max 4 -module ${ip_target}
prompt> set_synchronizer_depth -name ip_rst_sync_depth \
prompt> ? -min 3 -max 5 -reset -module ${ip_target}
RELATED COMMANDS
read_cdc_db
set_shell_instances
verify_cdc
RELATED VARIABLES

set_user_associated_cells
This command allows user to specify the list of modules whose outputs need to be treated as safe DATA or CNTL
signals. The command will set CNTL or DATA signals to ToolWaived status.
SYNTAX
string set_user_associated_cells
-cntl_rx <cntlrx_list> | -data_rx <datarx_list>
[-replace]
[-help]
Data Type
comment string
ARGUMENTS
[Required] Specifies the name for the user-defined association.
Specifies list of modules for DATA association to be created. This option is mutually exclusive with -
cntl_rx option.
-cntl_rx <datarx_list>
Specifies list of modules for CNTL association to be created. This option is mutually exclusive with -
data_rx option.
-replace
[Optional] Suppresses warnings about duplicate signals.
-comment <comments>
[Optional] Specifies the comments to be added to the user defined association to help track the
history.
-help
[Optional] Displays this help text.
EXAMPLES
• Example-1 : Specify a CNTL association, mod1, with name good_cntl
prompt> set_user_associated_cells -name good_cntl -cntl_rx mod1

RELATED COMMANDS
RELATED VARIABLES
None

set_user_cntl_synchronizer
Specify a list of modules which should be allowed as CNTL synchronizer to enforce a CDC signoff methodology. All
crossings outside the specified modules will be treated as DATA crossings. If a crossing inside the specified modules
does not meet synchronizer depth requirements, it will be marked as W_CNTL with the message 'User-Specified-Sync-
Depth-Err' in the Info column.
SYNTAX
string set_user_cntl_synchronizer
-name <usync_name>
[-force]
[-non_strict]
[-replace]
<modules>
Data Type
sync_name string
modules list or collection
ARGUMENTS
-name <usyn_name>
[Required] Specifies the name for the user defined control synchronizer.
-force:
Specify to force all crossings inside the specified modules a CNTL synchronizers. Use this option only
when Meridian CDC does not automatically identify those synchronizers.
-non_strict:
Specify to identify synchronizers where the flop stages have incoming logic from other RX components.
By default, these are
not identified.
-comment <comments>
the history.
-replace
EXAMPLES
• Example-1 :
prompt> set_user_cntl_synchronizer -name proj_sync mod1

RELATED COMMANDS
RELATED VARIABLES

set_user_reset_synchronizer
Specify a list of user modules where the reset synchronizers should be allowed
SYNTAX
string set_user_reset_synchronizer
-name <usync_name>
[-force]
[-replace]
<modules>
Data Type
sync_name string
ARGUMENTS
-name <usyn_name>
[Required] Specifies the name for the user defined reset synchronizer.
-force:
Specify to force all crossings inside the specified modules a reset synchronizers. Use this option only
when Meridian CDC does not automatically identify those synchronizers.
-comment <comments>
[Optional] Specifies the comments to be added to the user defined reset synchronizer to help track
the history.
-replace
[Optional] Indicates existing <usync_name> to be removed and create a new user defined reset
synchronizer. If the <usync_name> does not exist, it still creates a new user defined reset synchronizer
with given information.
EXAMPLES
• Example-1 :
prompt> set_user_reset_synchronizer -name proj_sync mod1
RELATED COMMANDS
RELATED VARIABLES

set_user_specified_cells
Specify a list of user modules. Meridian CDC will report when this cell is being used in CDC crossings in column
CellName.
SYNTAX
string set_user_specified_cells
-name <usync_name>
[-replace]
<modules>
Data Type
sync_name string
ARGUMENTS
-name <usyn_name>
[Required] Specifies the name for the user defined control synchronizer.
-comment <comments>
the history.
-replace
EXAMPLES
• Example-1 :
prompt> set_user_specified_cells -name proj_sync mod1
RELATED COMMANDS
RELATED VARIABLES

set_waveform_map
Specify block/top waveform mappings. These mapping are reported in I_HENV_WAVE_MAP rule.
SYNTAX
string set_waveform_map
{ <block_level_waveform> { <top_level_waveforms> }
-module <name>[ -exclude_instances <instances>] | -instance <name>
[-replace]
Data Type
mapping, instances list or collection

name string
ARGUMENTS
{ <block_level_waveform> { <top_level_waveforms> }
[Required] One or more waveform mappings, from each block-level waveform to top-level waveforms.

[Required] Name of block-level module or full hierarchical name of instances of a block-level
module whose status and/or comments you are promoting. If you specify -module, you can use -
exclude_instances to specify the full hierarchical name of instances of the block-level module whose
status and/or comments you do not want to promote.
-replace
[Optional] Specify -replace to suppress warning messages about duplicate objects.
-help
[Optional] Display help text for this command.
EXAMPLES
• Example-1 : Map block-level waveform w1 to top-level waveforms wt1.1 and wt1.2, and block-level
waveform w2 to top-level waveforms wt2.1, wt2.2, and wt2.3
prompt> set_waveform_map { \
prompt> ?{w1 {wt1.1 wt1.2}} \
prompt> ?{w2 {wt2.1 wt2.2 wt2.3}} \
prompt> ?} -module m1
RELATED COMMANDS
RELATED VARIABLES
None

user_defined_cntl_signals
Specify a list of user-defined control signals
SYNTAX
string user_defined_cntl_signals
-name <usync_name>
[-replace]
<sig_list>
Data Type
usync_name string
module_name string
comments string
ARGUMENTS
-name <usyn_name>
[Required] Specifies the name for this list.
-comment <comments>
the history.
-replace

<sig_list>
List or collection of signal names in design. The signal names should be receive flops in the design
for this command to apply.
EXAMPLES
• Example-1 :
prompt> user_defined_cntl_signals -name cntl_signals {din}
RELATED COMMANDS
RELATED VARIABLES

user_defined_data_signals
Specify
a
list
of
user-
defined
data
signals
SYNTAX
string
-
name
<usync_name>
[-
module
<module_name>
[-
exclude_instances
<exclude_instances>]
|
-
instances
<instances>]
[-
comment
<comments>]
[-
replace]
<sig_list>
Data
Type
usync_name
string
module_name
string
exclude_instances
list
or
collection
instances
list
or
collection
comments
string
sig_list
list
or
collection

ARGUMENTS
-
name
<usyn_name>
[Required]
Specifies
the
name
for
this
list.
-
module
<module_name>
[Optional]
The
-
module
and
-
instances
options
are
mutually
exclusive,
you
must
use
only
one.
Specify
the
module
(or
design)
name
user
defined
data
signals
to
be
applied
to.
When
-
module
is
used,
user
defined
data

signals
is
applied
to
all
the
instances
of
the
module,
use
-
exclude_instances
if
certain
instances
of
the
module
need
to
be
excluded.
-
exclude_instances
<exclude_instances>
[Optional]
The
-
exclude_instances
option
is
only
valid
with
-
module
option,
use
of
-
exclude_instances
with
-
instance
option
is
a
command
syntax
error.
Specifies
the

list
of
instances
the
user
defined
data
signals
to
be
excluded
from.
Names
of
the
<exclude_instances>
can
either
be
a
list
of
names
or
a
collection.
-
instances
<instances>
[Optional]
The
-
instances
and
-
module
options
are
mutually
exclusive,
you
must
use
only
one.
Specifies
the
list
of
instances
the
user
defined

data
signals
to
be
applied
to.
Names
of
the
<instances>
can
either
be
a
list
of
names
or
a
collection.
-
comment
<comments>
[Optional]
Specifies
the
comments
to
be
added
to
the
user
defined
data
signals
to
help
track
the
history.
-
replace
[Optional]
Indicates
existing
<usync_name>
to
be
removed
and
create

a
new
user
defined
data
signals.
If
the
<usync_name>
does
not
exist,
it
still
creates
a
new
user
defined
data
signals
with
given
information.
<sig_list>
List
or
collection
of
signal
names
in
design.
The
signal
names
should
be
receive
flops
in
the
design
for
this
command
to
apply.

EXAMPLES
• Example-1 :
prompt>
-
name
data_signals
{din}
RELATED
COMMANDS
RELATED
VARIABLES

verify_cdc
This command reads in a user-specified environment and performs structural clock-domain crossing analysis on the
design.
SYNTAX
string verify_cdc
[-scenario <scenario_name>]
[-write_cdc_db <cdc_db_name>]
[-sample_data_stability_checks]
[-read_simportal_checks_file <read_simportal_conf>]
[-write_simportal_checks_file <write_simportal_conf>]
[-write_formal_checks_file <formal_check_file>]
Data Type
scenario_name string or collection

cdc_db_name string
read_simportal_conf string
write_simportal_conf string
formal_check_file string
ARGUMENTS
-scenario <scenario_name>
[Optional] Specifies the scenario for verify_cdc to be performed. Current scenario is considered If
-scenario is not specified, <scenario_name> can be a singleton collection. If scenario has not been
defined, then the scenario named "default" is created to store SDC constraints. Each named scenario
can be referenced in the session by subsequent tool commands.
-write_cdc_db <cdc_db_name>
Specify the name of the CDC database. If none specified, database will not be generated
-sample_data_stability_checks
Perform full formal analysis on one DATA per INTERFACE and W_INTERFACE group.
-read_simportal_checks_file <read_simportal_conf>
Specify the name of the file containing user-specified simportal checks.
-write_simportal_checks_file <write_simportal_conf>
Specify the name of the output file containing default simportal checks.
-write_formal_checks_file <formal_check_file>
Specify the name of the output file containing default formal checks.
EXAMPLES
• Example-1 :
prompt> verify_cdc -scenario s1

RELATED COMMANDS
RELATED VARIABLES

verify_cdc_formal
This
command
reads
in
a
user-
specified
environment
and
performs
formal
clock-
domain
crossing
analysis
on
the
design.
By
default,
Meridian
CDC
uses
parallel
processing
for
formal
analysis.
IMPORTANT:
In
order
to
get
accurate
results,
you
must
specify
correct
clock
frequencies
in
the
ENV
or
SDC
file
(read
in
using
the

read_sdc
or
read_env
command).
SYNTAX
string
verify_cdc_formal
[-
scenario
<scenario_name>]
[-
initialize]
[-
add_assumptions]
[-
remove_assumptions]
[-
time_limit
<tlimit>]
[-
time_limit_per_check
<tlimit>]
[-
max_clock_cycles
<clock_cycles>]
[-
force_formal_rerun]
[-
parallel
<max_cores>]
[-
read_formal_checks_file
<file>]
Data
Type
scenario_name
string
tlimit
minutes
clock_cycles
integer
max_cores
integer
file
string
ARGUMENTS
-
scenario
<scenario_name>:
Specify
the
environment

scenario
for
CDC
analysis.
This
scenario
must
be
read
in
using
the
read_sdc
or
read_env
commands,
or
auto-
generated/
enhanced
using
the
analyze_intent
command
-
initialize:
Initialize
Meridian
DB
(needed
for
list_assumes
and
list_asserts
commands)
-
add_assumptions:
Set
of
asserts
in
the
RTL
to
be
treated
as
assumes
-
remove_assumptions:

Set
of
assumes
in
the
RTL
to
be
ignored
for
formal
analysis
-
time_limit
<tlimit>:
CPU
time
limit
in
minutes.
Default
is
6
hours.
-
time_limit_per_check
<tlimit>:
CPU
time
limit
per
check
in
minutes.
Default
depends
on
selected
formal-
flow.
In
throughput
mode
by
default
it
is
TimeLimit/
Number
of
checks.
In

hard-
pass
or
hard-
fail
mode
it
is
equal
to
Time-
Limit.
-
max_clock_cycles
<clock_cycles>:
Maximum
number
of
clock
cycles
examined
per
check.
Default
is
50
clock
cycles
of
the
fastest
clock.
-
force_formal_rerun:
Starts
a
fresh
formal
analysis
overwriting
the
previous
results
in
Meridian
CDC
project
directory.
-
parallel
<max_cores>:

Specifies
the
maximum
number
of
multiple
cores
to
use
for
formal
processing.
When
parallel
with
number
N
is
used,
tool
checks
for
sufficient
cores
and
then
consumes
at
max
N
+2
cores.
1
additonal
core
is
used
for
master
process
and
the
other
additional
core
for
the
monitor
process.
The
maximum
number
of
cores

are
only
used
if
they
are
available
on
the
machine
and
not
being
used
by
other
processes.
When
"When
"set
ri_formal_mode
sequential"
is
used,
the
-
parallel
option
is
completely
ignored
and
a
single
core
is
used.
When
in
default
parallel
mode,
i.e.
"set
ri_formal_mode
parallel",
the
system
will
add
N
child
process

cores
to
the
default
of
2
(1
for
master
and
1
monitor).
So
"-
parallel
N"
will
result
in
a
maximum
of
(2
+
N)
cores
being
used,
if
and
only
if
they
are
available
and
not
being
used.
-
read_formal_checks_file
<file>:
Specify
the
name
of
the
file
containing
user-

specified formal
checks.
When
the
user
hits
Ctrl-
C
when
formal
engines
are
running,
the
processing
is
suspended
till
the
user
selects
from
one
of
the
following
options
that
are
displayed
on
the
screen:
Enter
"1"
to
finish
this
check,
save
db
and
exit..
Enter
"2"
to
abandon
this
check
then
continue...

Enter
"3"
to
abandon
this
check,
save
db
and
exit.
Enter
"c"
to
continue
Enter
"x"
to
exit
immediately.
EXAMPLES
• Example-1
:
prompt>
verify_cdc_formal
RELATED
COMMANDS
read_cdc_db
set_shell_instances
verify_cdc
RELATED
VARIABLES

write_scripts
Writes environment files for submodules of the design that are derived from the top-level environment, so that CDC
verification can be performed at these levels of hierarchy. Meridian CDC does not generate environment files for
modules without any clock ports or when there are more than 5 instances of a module (you can override this default
value of 5 by setting the ri_write_scripts_skip_module_insts_limit variable to a different value). The ENV file needs to
have been read in before issuing this command.
SYNTAX
string write_scripts
[-clock_const_only]
[-dir <dir_name>]
[-depth <d> | -instances <instances> | -module <module_name>]
Data Type
scenario_name string
dir_name string
d integer
ARGUMENTS
-clock_const_only
[Optional] Write only clocks and constants to the environment file.
-dir <dir_name>
[Optional] Specifies the output directory where the generated control and environment files should
reside. Default: “meridian_project/_SCRIPTS”
-depth <d>
[Optional] Specifies the number of levels of hierarchy upto which the scripts need to be written.
Default value: 2
[Optional] Specifies the list of instances for which scripts should be written. Name of each <instances>
must be a full name to the instance; it can be either a list of names or a collection.
[Optional] Specify the reference name of the instances <module_name> for which scripts should be
written.
[Optional] Specifies the scenario for which scripts need to be written. If -scenario is not specified,
command is applied to current scenario.
EXAMPLES
• Example-1 : Write scripts to 3 levels of hierarchy

prompt> write_scripts -depth 3
RELATED COMMANDS
None
RELATED VARIABLES
ri_write_scripts_skip_module_insts_limit

ENV File Commands

The ENVironment commands (ENV Commands) are Real Intent's native commands for defining environment
specification. ENV commands can be used to define the waveforms, clocks, resets, constants, and boundary waveform
associations under which the design is analyzed or verified. The set of ENV commands that can be used to define
the design environment are described in this chapter. ENV specification commands are not available directly from
interactive CLI, they are generally written in a separate file and are accepted only by the read_env command.
• Command Syntax
ENV Commands are based on Tool Command Language (a.k.a Tcl), are defined using syntax that is compatible
with Tcl, so that commands are parsed using Tcl intepreter. When specifying design reference for environment
settings, for Verilog, all bus notations using [] must be included in {} to prevent the Tcl interpreter from
treating the vector definition like an embedded Tcl command.
• Example-1 : Setting a constant or stable value on single bit of an array named dataBus in Verilog or
SystemVerilog
1. set_constant -value 0 [get_ports {dataBus[2]}]
2. set_stable_value [get_ports {dataBus[2]}]
ENV Commands can refer to an array of objects and their values using their respective language syntax. Use of
Verilog "object" name with VHDL "value" syntax (or the opposite) results in a command syntax error.
• Example-2 : Setting a constant or stable value on an 8bit array named dataBus in Verilog or
SystemVerilog (using binary & hex format for value)
1. set_constant -value 8'b10101100 {dataBus[7:0]}
2. set_constant -value 8'hac {dataBus[7:0]}
• Example-3 : Setting a constant or stable value on a single bit (note the [] in the index) of an array
named dataBus in Verilog or SystemVerilog
1. set_constant -value 1'b0 {dataBus[0]}
2. set_stable_value {dataBus[2]}
• Example-4 : Setting a constant or stable value on an 8bit array named dataBus in VHDL (using binary
& hex format for value)
1. set_constant -value B"10101100" {dataBus(7:0)}
2. set_constant -value X"AC" {dataBus(7:0)}
• Example-5 : Setting a constant or stable value on a single bit (note the () in the index) of an array
named dataBus in VHDL
1. set_constant -value B"0" {dataBus(0)}
2. set_stable_value {dataBus(2)}
In addition, ENV commands can also be used together with Object Access Commands and native Tcl functions.
For example, list or concat can be used when constructing a list of values and commands such as get_ports
or get_nets can be used to access the design references as shown in the example below. However, note that
accessing array of ports/pins/nets/cells using Object Access Commands are not compatible with ENV scheme,
see Object Access Commands for more details for accessing arrays.
• Example-6 : Creating a clock on a port named sysclk

1. create_waveform -name SYS_CLK -period 10 -transitions [list 0 5]
2. create_clock -waveform SYS_CLK [get_ports sysclk]
3. create_input -waveform SYS_CLK [get_ports datain]

The variable ri_env_error_on_signal_not_found controls behavior of read_env when a referenced object is

not found. When this variable is set to false (default) a warning is provided for an object that is not found,
however, ENV file is processed all the way to the end and read_env return an error status. When this variable
is set to true, an error is reported and ENV file processing continues to the end of the file, at the end of the
command which makes the tool exits with an error code.
• Priority of ENV commands

By default, when multiple ENV specifications are applied on an object, the following priority is applied. The
highest priority ENV specification on the object is used for the analysis. The ENV command create_output is
currently a non-prioritized ENV specification which does not conflict with other ENV specifications.
1. create_clock (highest)
2. create_reset
3. set_value_during_reset
4. set_initial_value
5. set_initial_state
6. set_constant
7. set_stable_value
8. create_input
9. set_data_clock_domain (lowest)
You can override the default with the variable ri_env_priority_order. Setting ri_en_priority_order to
"last_one_wins" will result in the last spec winning (regardless of whether it is a clock, reset, constant, etc).
For the same type of multiple ENV specifications on the same object, the order the ENV commands come in
matters and the most latest (or last) ENV specification always takes precedence.
In the below example-8, create_input in line #2 take precedence, therefore new waveform is created and port
"dataIn" and is associated to the newly created waveform (see create_input command for more detail about -
async)
• Example-8 :
1. create_input -waveform "sysclk" [get_ports dataIn]
2. create_input -async [get_ports dataIn]
In the below example-9 is a one more example of same type of ENV commands getting overridden,
create_waveform in line #2 take precedence, this results in period and transition to be modified by the
create_waveform in line #2.
• Example-9 :
1. create_waveform wf-1 -period 10 -transition [list 0 5]
2. create_waveform wf-1 -period 8 -transition [list 0 4]

create_clock
Create a clock source point in the clock tree network and define its waveform.
SYNTAX
string create_clock
-waveform <waveform_name>
<ref_objects>
[-comments <comments>]
[-name <name>]
[-source <source>]
Data Type
waveform_name string or collection

ref_objects string or collection
comments string
name string
source string
ARGUMENTS
[Required] Specifies the <waveform_name> clock frequency to be derived from. The
<waveform_name> can either be a string or a collection with one waveform object.
<ref_objects>
[Required] Specifies port, pin, or net objects for a clock with the frequency of a <waveform_name>
to be assigned to. The <waveform_name> is propagated to the fanout cone of the <ref_objects>. The
<ref_objects> can either be a list of names or a collection of ports, pins, or nets.
-comments <comments>
[Optional] Specifies comments, either user-defined or generated for report purposes.
-name <name>
[Optional] User-specified name to be used as a recognizable tag, maintained during analyze_intent.
-source <source>
[Tool-Generated] Generated during analyze_intent; file and line information regarding the source
command that generated this ENV command.
DESCRIPTION
Command create_clock allows users to create a clock source of a clock tree network in the current design.
The command takes the frequency from the <waveform_name> and assign it to the clock. A clock can be
created on port or pin object which then be propagated to its entire fanout tree, however, clocks are not
propagated over the sequential cell boundary. Creating a clock requires waveform to be created before hand,
it is a syntax error if the waveform referred by create_clock command does not exist.
EXAMPLES

• Example-1 : Creating a clock on port "sysclk"

1. create_waveform systemclock -period 10 -transitions {0 5}
2. create_clock -waveform systemclock [get_ports sysclk]
• Example-2 : Creating a generated clock on a pin gen_ff/Q

1. create_waveform systemclk -period 10 -transitions [list 0 5]
2. create_derived_waveform sysgenclk -divide_by 2 -parent systemclock
3. create_clock -waveform sysgenclk [get_pins gen_ff/Q]
RELATED COMMANDS
create_waveform
create_derived_waveform
create_clock (SDC)
create_generated_clock
RELATED VARIABLES
ri_env_error_on_signal_not_found

Create a derivation waveform of a parent waveform.
SYNTAX
string create_derived_waveform
-parent <parent_waveform>
[-divide_by <divideby_factor> [-high_pulse_width <numberof_edges>] [-offset <offset> | -invert]]| -edges
<edge_list>
<waveform_name>
[-name <name>]
[-source <source>]
Data Type
waveform_name string
parent_waveform string or collection
divideby_factor integer
edge_list list (integer)
numberof_edges integer
offset integer
comments string
name string
source string
ARGUMENTS
-parent <parent_waveform>
[Required] Specifies the parent (or master) waveform the derived waveform to be created. The
<parent_waverform> must be created before derived waveform creation, failure to do so results in
command syntax failure. The <parent_waveform> can either be a named object or a collection with
one waveform.
-divide_by <divideby_factor>
[Optional] This option is mutually exclusive with -edges, you must use only one. Specifies the
frequency division factor for the derived waveform. The period of derived waveform is period of
<parent_waveform> multiply by <divideby_factor> long.
-high_pulse_width <numberof_edges>
[Optional] Must use with -divide_by, is an error to use with -edges option. Specifies number of parent
waveform edges (or transitions) during high pulse of derived waveform. The <numberof_edges> must
be less than the total number of edges in the derived waveform.
-offset <offset>
[Optional] Must use with with -divide_by, and mutually exclulsive with with -invert option. Specifies
the number of parent waveform edges to occur before the first rising edge of the derived waveform.
-inverted
[Optional] Must use with -divide_by and mutually exclusive with -edges and -offset option. Indicates
that derived waveform to be an inverted.

-edges <edge_list>
[Optional] This option is mutually exclusive with -divide_by, you must use only one. Specifies list of
three parent waveform edges to form derived waveform. Specified <edge_list> represents rising,
falling, and rising edge of the derived waveform, each parent edge must be greater than or equal to
previous edge number.
<waveform_name>
[Required] Specifies the name for waveform to be created. All ENV commands can refer to
<waveform_name> when associating the waveform to an object.
-name <name>
-source <source>
DESCRIPTION
Command create_derived_waveform creates derived waveform from a parent waveform. Specification of a
derived waveform is same as any other waveform (created by create_waveform command), the only difference
is that derived waveform's characteristics such as period, transitions, etc. are taken from its parent waveform.
All the derived waveforms, by ENV semantics, are synchronous to its parent (or master) waveform. An
exception to this synchronous relation, to either its parent waveform or another derived waveform in the same
synchronous waveform group, can be defined by set_async_waveforms command.
The options -high_pulse_width and -offset can only be used with -divide_by option, using with -edges option
with them is considered a syntax error. The option -offset and -invert are mutually exclusive and cannot be
used ogether. When -invert option is specified without -divide_by option, then the resulted derived waveform
is considered as if <divideby_factor> were 1 of the <parent_waveform>.
Command create_derived_waveform be used when translating SDC's create_clock and

create_generated_clock to ENV commands.
EXAMPLES
• Example-1 : Creating a waveform "clk" of time units 10 with rising edge at 5 and falling edge at 10. Then
creating derived waveform divide by 2 of the master waveform
1. create_waveform clk -period 10 -transitions [list 5 10]
2. create_derived_waveform clkgen -divide_by 2 -parent clk

• Example-2 : Creating a waveform "clk" of time units 10 with rising edge at 0 and falling edge at 5. Then
creating derived waveform divide by 2 of the master waveform
2. create_derived_waveform clkgen -divide_by 2 -parent clk
• Example-3 : Creating a derived waveform using -edges

2. create_derived_waveform clkg1 -edges [list 1 3 5] -parent clk

• Example-3 : Creating a derived waveform using -edges

2. create_derived_waveform clkg2 -edges [list 2 4 6] -parent clk
RELATED COMMANDS
create_waveform
create_clock (SDC)
set_async_waveforms
RELATED VARIABLES
ri_convert_SDC_clocks_async
ri_use_unidir_clk2clk_sfp_as_async

create_input
Associate waveform for primary inputs or cell pins to their respective launch waveform.
SYNTAX
string create_input
-waveform <waveform_name> | -async
[-fall]
<ref_objects>
[-name <name>]
[-source <source>]
Data Type

ref_objects list or collection
comments string
name string
source string
ARGUMENTS
[Required] Mutually exclusive with -async, you must use only one. Specifies the <waveform_name> to
be associated with <ref_objects>. The <waveform_name> can either be a string or a collection with
one waveform.
-async
[Required] Mutually exclusive with -waveform, you must use only one. Indicates that all the
<ref_objects> specified are asynchronous to all its receivers (or capture clock waveforms). Each of the
<ref_objects> is assigned to a new, unique, automatically created waveform.
For example following will create one waveform and tie all 3 inputs to it
create_input –async {a b c}
For example following will create 3 separate waveforms and tie each input to separate waveforms
create_input –async {a}
create_input –async {b}
create_input –async {c}
-fall
[Optional] Indicates that <ref_objects> are sensitive to falling edge of the waveform (or launched by
falling edge of the waveform). By default (absence of this option), the <ref_objects> are sensitive to
rising edge of the waveform.
<ref_objects>
[Required] Specifies list of primary input ports or output pins or undriven nets the <waveform_name>
to be associated with. The <ref_objects> can either be a list of named objects or a collection of ports,
leaf cell output pins (hierarchical pins are not allowed), or nets.

-name <name>
-source <source>
DESCRIPTION
Command create_input allows users to associate primary input ports or pins or nets that do not have
waveform associated with (such as output pins of a blackbox cell or undriven nets) to their respective launch
clock waveform. The waveform associated by create_input command is used to determine if the transmit
signal of <ref_objects> is an asynchronous starting point of a path.
By default, all the <ref_objects> are sensitive to rising edge of an associated waveform, -fall overrides the
default definition and indicates that <ref_objects> are sensitive to falling edge of the waveform. The rising
and falling waveform sensitivity is taken into consideration only during the formal analysis.
The option -async provide users an easy way to specify <ref_objects> are asynchronous to all the waveform in
the design without specifying a waveform name. Meridian CDC automatically assigns a waveform and associate
all the <ref_objects> to it, thus -async is mutually exclusive to -waveform and making all <ref_objects>
to be synchronous to each other. A new waveform is automatically created for -async and is named as
"RI_WAVEFORM_ASYNC_n", where "n" is an integer representing number of waveforms created for -async
option.
EXAMPLES
• Example-1 : Associate "datain" port with a waveform (with a real clock)
1. create_waveform waveform_sysclk -period 7 -transition [list 0 3.5]
2. create_clock -waveform waveform_sysclk [get_ports sysclk]
3. create_input -waveform waveform_sysclk [get_ports datain]
• Example-2 : Associate "datain" port with a waveform (virtual clock) and sensitive to falling edge of the
waveform
2. create_input -waveform waveform_sysclk -fall [get_ports datain]
• Example-3 : Making "cntlin" input to be asynchronous to all the waveforms in the design and sensitive to
falling edge of the waveform
1. create_input -async -fall [get_ports cntlin]
RELATED COMMANDS
create_waveform
set_input_delay

RELATED VARIABLES

create_output
Associate waveform for primary outputs or cell pins to their respective capture waveform.
SYNTAX
string create_output
-waveform <waveform_name> | -async
<ref_objects>
[-name <name>]
[-source <source>]
Data Type

comments string
name string
source string
ARGUMENTS
[Required] Mutually exclusive with -async, you must use only one. Specifies the <waveform_name> to
be associated with <ref_objects>. The <waveform_name> can either be a named object or a collection
with one waveform.
-async
[Required] Mutually exclusive with -waveform, you must use only one. Indicates that all the
<ref_objects> specified are asynchronous to all its drivers (or launch clock waveforms). Each of the
<ref_objects> is assigned to a new, unique, automatically created waveform.
-fall
[Optional] Indicates that <ref_objects> are sensitive to falling edge of the waveform (or captured by
falling edge of the waveform). By default (absence of this option) the <ref_objects> are sensitive to
rising edge of the waveform.
<ref_objects>
[Required] Specifies list of primary output ports or input pins the <waveform_name> to be associated
with. The <ref_objects> can either be a list of named objects or a collection of ports, leaf cell input
pins (hierarchical pins are not allowed), or nets.

-name <name>
-source <source>
DESCRIPTION
Command create_output allows users to associate primary output ports and pins that do not have waveform
associated with (such as input pins of a blackbox cells) to be tied to their respective waveform. The waveform
associated by create_output command is used to determine if the <ref_objects> is a receiving signal end or
terminal point of an asynchronous path.
By default, all the <ref_objects> are sensitive to rising edge of associated waveform, -fall overrides the
default definition and indicates that <ref_objects> are sensitive to falling edge of the waveform. The rising
and falling waveform sensitivity is taken into consideration during the formal analysis.
The option -async provide users an easy way to specify <ref_objects> that are asynchronous to all the
waveform in the design without specifying a waveform name. Meridian CDC automatically assigns a waveform
and associate all the <ref_objects> to it (thus making objects in the <ref_objects> to be synchronous to each
other). The waveform automatically created for -async option is named as "RI_WAVEFORM_ASYNC_n", where
"n" is an integer representing number of waveforms created for -async option.
EXAMPLES
• Example-1 : Associate "dataout" port with a waveform (with a real clock)
2. create_clock -waveform waveform_sysclk [get_ports sysclk]
3. create_output -waveform waveform_sysclk [get_ports dataout]
• Example-2 : Associate "dataout" port with a waveform (virtual clock) and sensitive to falling edge of the
waveform
2. create_output -waveform waveform_sysclk -fall [get_ports dataout]
• Example-3 : Making "cntlout" output to be asynchronous to all the waveforms in the design and sensitive to
falling edge of the waveform
1. create_output -async -fall [get_ports cntlout]
RELATED COMMANDS
create_waveform
set_output_delay
RELATED VARIABLES

ri_create_output_in_create_env
ri_translate_set_output_delay

create_reset
Create a reset specification on reset signal.
SYNTAX
string create_reset
-waveform <waveform_name> | -functional | -async
[-interval <duration>]
[-low]
<ref_objects>
[-source <source>]
Data Type

duration integer
comments string
source string
ARGUMENTS
[Required] Specifies the <waveform_name> the reset behavior is pertinent to.
-functional
[Required] Mutually exclusive with -waveform and -async, you must use only one. Cannot be used on
primary inputs. Indicates that the reset is an internally generated functional reset. The waveform is
determined by the tool. (Note: Both functional and non-functional resets are used to determine the
steady state of a design.)
-async
[Required] Mutually exclusive with -waveform and -functional, you must use only one. Indicates that
objects should be asynchronous to all other waveforms. Each of the <ref_objects> is assigned to a
new, unique, automatically created waveform.
-interval <duration>
[Optional] Specifies the number of waveform periods reset signals <ref_objects> to be held active. In
absence of this option, <duration> is default to 10.
-low

[Optional] Indicates that the reset is a active "low" signal. Absence of this switch indicates that the
reset is active "high" signal (this is the default).
<ref_objects>
[Required] Specifies the reset signals where reset specification to be created. Reset signals,
<ref_objects> can either be a string or a collection of ports, pins, or nets.
-source <source>
DESCRIPTION
Command create_reset allows users to specify reset specification for the design for verification. The reset
specification is used to initialize the design for both structural and Formal analysis. Reset analysis is done in
both assertion phase (i.e while reset is active) and de-assertion phase so that initial values are properly set on
storage elements (i.e flops, latches, memory) as well as primary inputs for structural or formal analysis.
The length the reset to be held active (specified by -interval) should be set to lowest possible length (i.e.
number of clock periods) that meets the design requirements, excessive length of reset interval time could
lead to poor verification performance. Also correct active level of reset is critical for the analysis, incorrect
use of active level could lead to path nodes to be considered constant for analysis.
EXAMPLES
• Example-1 : Create an active high reset of 8 waveform periods long related to waveform sysclk on sysrst
1. create_waveform sysclk -period 10 -transitions [list 0 5]
2. create_reset -interval 8 -waveform sysclk [get_ports sysrst]
• Example-2 : Create an active low reset of 10 waveform periods long related to waveform sysclk on port sysrst
1. create_waveform sysclk -period 10 -transitions [list 0 5]
2. create_reset -interval 10 -waveform sysclk [get_ports sysrst]
RELATED COMMANDS
create_waveform
create_clock (SDC)
set_initial_state
set_initial_value
RELATED VARIABLES
ri_exclude_internal_reset_analysis

create_waveform
Create a waveform specification.
SYNTAX
string create_waveform
-period <clock_period>
-transitions { rise fall }
<waveform_name>
[-name <name>]
[-source <source>]
Data Type
waveform_name string
clock_preiod float
{ rise fall } list (integer)
comments string
name string
source string
ARGUMENTS
-period <clock_period>
[Required] Specifies the period for the waveform being defined. The <clock_period> must be greater
than zero.
-transition { rise fall }

[Required] Specifies the time of rising edge (first value in the list) and the falling edge (second value
in the list) of the waveform. Value of rising edge has to be less than the falling edge value.
<waveform_name>
[Required] Specifies the name for waveform to be created. All other ENV commands can refer to
waveform by <waveform_name> when associating the waveform to an object.
-name <name>
-source <source>
DESCRIPTION
Command create_waveform creates a waveform. Waveform is one of key specifications required for design
analysis by Meridian CDC. Waveform must be created before defining a clock, all the clocks associated with the

<waveform_name> are considered synchronous. And any clocks that are associated with derived waveform of
<waveform_name> are also considered synchronous. An exception to this synchronous relation can be defined
by set_async_waveforms command.
The transitions time <rise_fall> defines the time of the rising edge from time 0 and falling edge from time 0.
The rising edge must be greater than or equal to zero and time of the falling edge must be greater than that of
rising edge and less than or equal to <clock_period>.
EXAMPLES
• Example-1 : Creating a waveform "clk" of time units 10 with rising edge at 5 and falling edge at 10
create_waveform clk -period 10 -transitions [list 5 10]
• Example-2 : Creating a waveform "clk" of time units 10 with rising edge at 0 and falling edge at 5
create_waveform clk -period 10 -transitions [list 0 5]
RELATED COMMANDS
create_clock (SDC)
set_async_waveforms
analyze_intent
RELATED VARIABLES


set_async_waveforms
Specify asynchronous relation between waveforms within a synchronous waveform group.
SYNTAX
string set_async_waveforms
-group <waveform_list> ...
[-name <name>]
[-source <source>]
Data Type
waveform_list string or collection

comments string
name string
source string
ARGUMENTS
-group <waveform_list>
Required option, can be used multiple times in a single command to specify the asynchronous relation
between multiple <waveform_list>. Specifies the list of waveforms to be made asynchronous. This
<waveform_list> can be a named list or a collection containing waveforms.
-name <name>
-source <source>
DESCRIPTION
Command set_async_waveforms defines the asynchronous relation between two or more <waveform_list>
in synchronous waveform group. Any signals that are launched and/or captured by asynchronous waveforms
defined by set_async_waveforms are considered asynchronous crossings. Command set_async_waveforms
only defines the asynchronous relation between the waveforms specified by -group option and does not define
any relation between the waveforms within a group.
The command set_async_waveforms requires only to define an exception to waveforms within a synchronous
waveform group. By ENV semantics, two master waveforms are asynchronous to each other, therefore
set_async_waveforms between two master waveforms or two derived waveforms under two different master
waveforms are considered redundant and be ignored.
Command set_async_waveforms be used when translating SDC's set_clock_groups and set_false_path to ENV
commands.
EXAMPLES

• Example-1 : Defining asynchronous relation between waveforms when there is a transitive relation. Consider
following scenario, sysclk_gen1 and sysclk_gen2 waveforms are derived from master waveform, sysclk. By
ENV semantics this makes all the waveforms synchronous to each other. In the example below, sysclk_gen1
and sysclk_gen2 have been made asynchronous to each other without breaking the synchronous relation to its
parent waveform sysclk :
1. create_waveform sysclk -period 10 -transition [list 0 5]
2. create_derived_waveform sysclk_gen1 -parent sysclk -divide_by 2
3. create_derived_waveform sysclk_gen2 -parent sysclk -divide_by 3
4. set_async_waveforms -name async_gen1_gen2 -group {sysclk_gen1} -group
{sysclk_gen2}
• Example-2 : Following example shows that set_async_waveforms defining asynchronous relation between
two master waveforms (in the line #1 and #2 below) has no impact on the final outcome as all the master
waveforms are already considered asynchronous by ENV semantics :
1. create_waveform sysclk -period 10 -transition [list 0 5]
2. create_waveform dspclk -period 5 -transition [list 0 2.5]
3. create_derived_waveform dspclk_gen1 -divide_by 2 -parent dspclk
4. set_async_waveforms -name async_noeffect -group {sysclk} -group [list dspclk
dspclk_gen1]
RELATED COMMANDS
create_waveform
create_clock (SDC)
set_false_path
set_clock_groups
RELATED VARIABLES

set_constant
Assign constant value to ports, pins, or nets.
SYNTAX
string set_constant
-value <value>
<ref_objects>
[-name <name>]
[-source <source>]
Data Type
value 0|1
comments string
name string
source string
ARGUMENTS
-value <value>
[Required] Specifies the constant value, <value> to be assigned to <ref_objects>. Valid values cane
be either 0 (zero) or 1 (one), Verilog syntax notion and VHDL syntax notion. See examples for more
details.
<ref_objects>
[Required] Specifies objects constant to be assigned to. Constant object, <ref_objects> can either be
a string or a collection of ports, pins, or nets.
-name <name>
-source <source>
DESCRIPTION
Command set_constant allows users to assign constant values for certain objects in the design that do not
dynamically change (i.e. static signals). The object must be used and must not be already driven to a constant
by the RTL. Assigned constants are propagated forward from the objects and propagated over sequential cells
(i.e. flops & latches).
The list of <ref_objects> follows array notion, the assignment referring to primary ports in Verilog design,
set_constant -value 2'b10 {b[1] b[0]}, is treated as an array concatenation which results in an array

b[1:0], is getting constant value 2'b10 assigned to it. If the number of array elements do not match the
<value> specified, the constants are assigned from the LSB, higher bits (MSB) are zero extended.
EXAMPLES
• Example-1 : Setting constant value 0 on primary input ports. Following is applicable to both Verilog and VHDL
designs
1. set_constant -value 0 [get_ports "test_enable bypass_mode"]
2. set_constant -value 1 [get_nets "inst1/inst2/reconfig"]
• Example-2 : Setting constant value on an array in Verilog design, data[0] gets constant 0 and data[1] gets
constant 1
1. set_constant -value 2'b10 {data[1:0]}
• Example-3 : When bit-width between <value> and <ref_objects> miss-matches, higher bits of
<ref_objects> are zero extended, in following example, data[7:3] gets constant 0
1. set_constant -value 2'b10 {data[7:0]}
RELATED COMMANDS
set_case_analysis
set_logic_zero
set_logic_one
RELATED VARIABLES

set_data_clock_domain
Set clock domain specification for a net with respect to a reference net.
SYNTAX
string set_data_clock_domain
-derived_from <ref_signal>
[-neg_phase | -pos_phase]
<ref_objects>
[-source <source>]
Data Type
reference_signal string or collection

module_name string
comments string
source string
ARGUMENTS
-derived_from <reference_signal>
[Required] Specifies the reference signal for the waveform to be derived for the <ref_objects>. The
<reference_signal> can either be a string or a collection of signal names. When the -module or -
instances option is used, the <reference_signal> name should be limited to the respective scope and
only names (strings) are allowed (a collection is not allowed).
-neg_phase | -pos_phase
Associates either negative phase of clock waveform (-neg_phase) or positive phase of clock waveform
(-pos_phase) with the <ref_objects>.
[Optional] This option is mutually exclusive with -instance option, you must use only one. Specify
the module (or design) name the data clock domain to be applied to. When -module is used, all
<ref_objects> and <reference_signal> names should be limited to module scope. With -module
option, data clock domain is applied to all the instances of the given module, certain instances of
<module_name> can be exempted with -exclude_instances option.
[Optional] Specifies the list of instances of the <module_name> to be excluded from consideration.
The -exclude_instances option is only valid with -module option, use of -exclude_instances with -
instances option is a command syntax error. Names of the <exclude_instances> can either be a list of
instance names or a collection of instances.

[Optional] This option is mutually exclusive with -module option, you must use only one. Specifies
the list of instances of the <ref_objects> data clock domain to be applied. When -instances is used,
all <ref_objects> and <reference_signals> names should be limited to instance scope. Names of the
<ref_objects>
[Required] Specifies list of signals to where <waveform_name> to be assigned to. The new waveform
derived from <reference_signal> is assigned to <ref_objects> and propagate forward. Names of
<ref_objects> can either be a list of nets or leaf instance pins (hierarchical pins are not supported), or
ports. When -module or -instance option is used, <ref_objects> names should be based on module or
instance scope respectively and only names (strings) are allowed (collection are not allowed).
-source <source>
DESCRIPTION
Command set_data_clock_domain allows users to define how to derive waveform for a signal via a qualified
signal. The command instructs the tool the derive the waveform for the given set of signals from the reference
signal (i.e. qualifiers) at combinatorial logic where the qualified signal is properly synchronized. Specify
reference signal for a waveform to be derived from for given <ref_objects>. the clock domain of a processes
the timing constraints in the file_list in Synopsys Design Constraints (SDC) format and stores in the session.
EXAMPLES
• Example-1 :
prompt> set_data_clock_domain -derived_from pin1 {pin2}
RELATED COMMANDS
create_waveform
RELATED VARIABLES

set_initial_state
Set the initial state of a memory element (flop/latch) to a specific value. List of memory elements may also be
specified. A VCD trace file that contains the start value of all memory elements can also be given. The usual reset flow
within Meridian CDC is replaced by the sequence given when the -vcd_file option is used. If multiple set_initial_state
commands are used, they are executed in order; in case of a conflict, the last value prevails.
SYNTAX
string set_initial_state
-vcd_file <file_name> [-top_level_inst <vcd_scope>] | -value <value> <ref_objects>
-time_interval <duration>
[-name <name>]
[-source <source>]
Data Type
file_name string
vcd_scope string or collection
value 0 or 1
duration integer
comments string
name string
source string
ARGUMENTS
-vcd_file <file_name> [-top_level_inst <vcd_scope>] | -value <value> <ref_objects>
[Required] Specifies either the VCD trace file (<file_name>) to read in for design initialization or a
value to be assigned to reference objects. When specifying a VCD trace file, you can optionally specify
the top-level instance using the -top_level_inst option. For the -value option, <ref_objects> specifies
the storage elements in the design to be initialized.
-time_interval <duration>
[Required] Number of reset cycles to be held.
-name <name>
-source <source>
EXAMPLES
• Example-1 :

prompt> set_initial_state -value 1 {xsig}
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None.

set_initial_value
Sets the initial value on an input or inout port(s) for the specified interval. The interval specified is integer. The time
period corresponding to the interval can be calculated as interval*time period of the waveform.
By default at the end of the interval the signal can take any value 0 or 1 at any point in time (independent of clock
edge). By default the ports can take any value after the specified interval. If -constrained option is specified at the
end of the specified interval, the port(s) can take any value on subsequent positive edges of the waveform specified.
If a negative edge transitions are required, the user can create an inverted derived waveform. This command is useful
for design initialization.
This command is identical to set_value_during_reset command.
SYNTAX
string set_initial_value
-value <value>
[-constrained]
<ref_objects>
[-name <name>]
[-source <source>]
Data Type

duration integer
value 0 or 1
comments string
name string
source string
ARGUMENTS
<ref_objects>
[Required] Specifies the ports where initial value is being specified.
[Required] Specifies the <waveform_name> to be associated.
Specifies the number of clock periods for which the initial value must be held.
-value <value>
The constant value to which the state should be set. Valid values are 0 or 1. Other valid Verilog
values follow Verilog syntax; for example, 1'b0, 4'h0. Other valid VHDL values follow VHDL syntax; for
example, B"01", X"90AC". However, the default binary syntax ("0010") is treated as integer literal. If
binary syntax is desired, use binary literals such as 4b'0010 or B"0010".

-constrained
Indicates the specified value should be constrained to change only on the rising edge of the clock
waveform
-name <name>
-source <source>
EXAMPLES
• Example-1 :
prompt> set_initial_value -waveform CLOCK -interval 17 -value 1 {in_port}
RELATED COMMANDS
create_waveform
create_clock (SDC)
RELATED VARIABLES

set_stable_value
Makes a given net or port's value to be unchangeable from the first value that it gets. For example - if a net gets
assigned a high value, it must remain high during the entire analysis. This command can be used as a way to exclude
signals from verification. A signal included in this list, will be assumed stable, therefore will not be verified during
clock domain crossing analysis. However, the value 1 or 0 will be propagated to its fanout, allowing verification of its
fanout and potential crossings driven by it.
SYNTAX
string set_stable_value
<ref_objects>
[-name <name>]
[-source <source>]
Data Type

comments string
name string
source string
ARGUMENTS
<ref_objects>
[Required] Specifies the list of signals which should be held at stable values.
-name <name>
-source <source>
EXAMPLES
Example-1 :
prompt> set_stable_value scan_mode
RELATED COMMANDS
None.
RELATED VARIABLES


set_value_during_reset
Sets the initial value on an input or inout port(s) for the specified interval. The interval specified is integer. The time
period corresponding to the interval can be calculated as interval*time period of the waveform.
By default, at the end of the interval, the signal can take any value 0 or 1 at any point in time (independent of
clock edge). If -constrained option is specified at the end of the specified interval, the port(s) can take any value on
subsequent positive edges of the waveform specified. If a negative edge transitions are required, the user can create
an inverted derived waveform. This command is useful for design initialization.
Note: This command is identical to set_initial_value command. Both commands are available for backward
compatibility.
SYNTAX
string set_value_during_reset
-value <value>
[-constrained]
<ref_objects>
[-name <name>]
[-source <source>]
Data Type

duration integer
value 0 or 1
comments string
name string
source string
ARGUMENTS
<ref_objects>
[Required] Specifies the ports where initial value is being specified.
[Required] Specifies the <waveform_name> to be associated.
[Required] Specifies the number of clock periods for which the initial value must be held.
-value <value>
[Required] The constant value to which the state should be set. Valid values are 0 or 1. Other valid
Verilog values follow Verilog syntax; for example, 1'b0, 4'h1. Other valid VHDL values follow VHDL
syntax; for example, B"01", X"90AC". However, the default binary syntax ("0010") is treated as integer
literal. If binary syntax is desired, use binary literals such as 4b'0010 or B"0010".

-constrained
[Optional] Indicates the specified value should be constrained to change only on the rising edge of the
clock waveform.
-name <name>
-source <source>
EXAMPLES
• Example-1 :
prompt> set_value_during_reset -waveform CLOCK -interval 17 -value 1 {in_port}
RELATED COMMANDS
create_waveform
create_clock (SDC)
set_initial_value
RELATED VARIABLES

GENERAL Commands

check_command_exists
Checks whether a command exists for a given scenario, in a given RIDB.
SYNTAX
string check_command_exists
-project <project_name>
-design <design_name>
-command <command_name>
[-with_violations]
[-help]
Data Type
project_name string
design_name string
command_name string
-with_violations boolean
ARGUMENTS
-project <project_name>
Previous Meridian CDC project directory.
Design top module name.
-command <command_name>
Name of command whose existence you are checking.
[Optional] Name of scenario against which to check for <command_name>.
-with_violations
[Optional] Boolean flag. When specified, checks whether <command_name> generated any violations.
-help
DESCRIPTION
Use this command to check whether a particular command in a given scenario has already been executed
in a given RIDB. The RIDB is specified by a project_directory and design. The command checks to see if a
particular command, in a given scenario, has executed in any previous run stored in that database. There is a
further option available to check whether the specified command, in addition to executing, also produced any
violations.
EXAMPLES

• Example-1 :
prompt> check_command_exists -project /home/user1/block/bluetooth/meridian_project \
prompt> ? -design minsoc_top -command "get_attribute" -scenario sce1 -with_violations
RELATED COMMANDS
RELATED VARIABLES

create_rule_group
Create a rule group to organize rule instances of a rule policy.
SYNTAX
string create_rule_group
<rulegroup>
-rule_policy <policy_name> | -parent_group <group_name>
[-replace]
Data Type
rulegroup string
rule_name string or collection
policy_name string or collection
group_name string or collection
ARGUMENTS
<rulegroup>
[Required] Specifies the name of the rule group to be created. The rule group <rulegroup> is created
under rule policy <policy_name> or under rule group <group_name>.
-rule_policy <policy_name>
[Required] Mutually exclusive with -parent_group option, you must use only one. Specifies the rule
policy where the rule group to be created. The <policy_name> can either be a string or a collection
with one rule policy object.
-parent_group <group_name>
[Required] Mutually exclusive with -rule_policy option, you must use only one. Specifies the rule group
where the new rule group to be created. The <group_name> can either be a string or a collection with
one rule group object, when string is specified, full name to the <group_name> is required.
-replace
[Optional] Indicates existing rule group, <rulegroup> to be deleted and recreated. This option has no
meaning if the <rulegroup> does not exist.
DESCRIPTION
Command create_rule_group allows users to create rule group to organize a rule policy. Rule group is an
object that is designed to organize a rule policy so that each specific type of checks can be organized ease
the verification signoff. After rule group is created, attributes of the rule group can be manipulated using
get_attribute and set_attribute commands. Please see the rule group attributes for detail information.
When -rule_policy option is used, <rulegroup> is created directly under <policy_name>. When -
parent_group is used, <rulegroup> is created under <group_name>.
Rule group can only be created under a rule policy or under a rule group (optional) for better organization.
After rule group is created, it can then be configured to report or display verification results of all rule
instances under its group to meet user methodologies (overriding the default methodology provided by the
Meridian CDC).

EXAMPLES
• Example-1 : Creating a rule directly under a rule policy
prompt> create_rule_policy verilog_coding_guide
prompt> create_rule_group verilog_naming_conventions -rule_policy
verilog_coding_guide
• Example-2 : Creating a rule group under another rule group

prompt> create_rule_policy verilog_coding_guide
prompt> create_rule_group verilog_naming_conventions -rule_policy
verilog_coding_guide
prompt> create_rule_group module_name_convention -rule_policy verilog_coding_guide \
prompt> ? -parent_group verilog_naming_convention
RELATED COMMANDS
create_rule_policy
create_severity
create_view_criteria
get_rule_groups
RELATED VARIABLES

create_rule_instance
Create a rule instance of a rule for a rule policy.
SYNTAX
string create_rule_instance
<ruleinstance>
-rule <rule_name>
-rule_policy <policy_name> | -rule_group <group_name>
[-replace]
Data Type
ruleinstance string
rule_name string or collection
policy_name string or collection
group_name string or collection
ARGUMENTS
<ruleinstance>
[Required] Specifies the name of the rule instance to be created. Rule instance <ruleinstance> is
created under rule policy <policy_name> or under rule group <group_name>.
-rule <rule_name>
[Required] Specifies the name of the rule to be instantiated.
-rule_policy <policy_name>
[Required] Mutually exclusive with -rule_group option, you must use only one. Specifies the rule policy
where the rule instance to be created. The <policy_name> can either be a string or a collection with
one rule policy object.
-rule_group <group_name>
[Required] Mutually exclusive with -rule_policy option, you must use only one. Specifies the rule group
where the rule instance to be created. The <group_name> can either be a string or a collection with
one rule group object, when string is specified, full name to the <group_name> is required.
-replace
[Optional] Indicates existing rule instance, <ruleinstance> to be deleted and recreated. This option
has no meaning if the <ruleinstance> does not exist.
DESCRIPTION
Command create_rule_instance allows users to create rule instance of a built-in rule. Rule instances provide
flexibility to create user defined view of the results and ability establish a sign-off process. After rule
instance is created, attributes of the rule instance can be manipulated using get_attribute and set_attribute
commands. Please see the rule instance attributes for detail information.
When -rule_policy option is used, <ruleinstance> is created directly under <policy_name>. When -
rule_group is used, <ruleinstance> is created under <group_name>.

Rule instance can only be created under a rule policy or under a rule group (optional). After rule instance
is created, it can then be configured to verify particular check or to report or display verification results to
meet certain user methodology, other than the default methodology provided by the Meridian CDC. Multiple
rule instances of the same rule can be created and each individual rule instance can be configured to report a
particular view based on the user defined criteria.
EXAMPLES
• Example-1 : Creating a rule instance of W_DATA directly under a rule policy
prompt> create_rule_policy clock_domain_crossings
prompt> create_rule_instance unsync_data_crossings -rule W_DATA -rule_policy
clock_domain_crossings
• Example-2 : Creating a rule instance of W_DATA under a rule group

prompt> create_rule_group must_fix -rule_policy clock_domaing_crossings
prompt> create_rule_instance unsync_data_crossings -rule W_DATA \
prompt> ? -rule_policy clock_domain_crossings -rule_group must_fix
RELATED COMMANDS
create_rule_group
create_rule_policy
create_severity
create_status
get_rules
get_rule_instances
get_rule_data
get_rule_contents
RELATED VARIABLES
None

create_rule_policy
Create a rule policy.
SYNTAX
string create_rule_policy
<rulepolicy>
[-replace]
Data Type
rulepolicy string
ARGUMENTS
<rulepolicy>
[Required] Specifies the name of the rule policy to be created.
-replace
[Optional] Indicates existing rule policy, <rulepolicy> to be deleted and recreated. This option has no
meaning if the <rulepolicy> does not exist.
DESCRIPTION
Command create_rule_policy allows users to create rule policy for specific verification. Rule policy is the root
node of a policy which consists with rule groups and rule instances to create a sign-off methodology. User can
also create user specific policies. After a rule policy is created, rule groups and rule instances can be added to
the policy. Attributes of the rule policy can be manipulated using get_attribute and set_attribute commands.
Please see the rule policy attributes for detail information.
Rule policy can also be associated with different type of view criteria to display or report verification results
to meet user methodology, other than the default methodology provided by the Meridian CDC.
EXAMPLES
• Example-1 : Creating a rule policy and adding a rule instance of W_DATA rule directly under it
prompt> create_rule_instance unsync_data_crossings -rule W_DATA -rule_policy
clock_domain_crossings
• Example-2 : Creating a rule policy and adding rule instance and rule group to it
prompt> create_rule_group must_fix -rule_policy clock_domaing_crossings
prompt> create_rule_instance unsync_data_crossings -rule W_DATA \
prompt> ? -rule_policy clock_domain_crossings -rule_group must_fix
RELATED COMMANDS
get_rule_policies
create_severity

RELATED VARIABLES

create_severity
Create a user defined severity.
SYNTAX
string create_severity
<severity_name>
-type <Error | Warning | Info >
-level <severity_level>
[-replace]
Data Type
severity_name string
severity_level integer [0..9]
comments string
ARGUMENTS
<severity_name>
[Required] Specifies the name of new severity to be created. The severity name is treated as a case
insensitive string.
-type <Error | Warning | Info>

[Required] Specifies the type of the severity, it can be of either "Error", "Warning", or "Info" type
severities. These type values are case insensitive.
-level <severity_level>
[Required] Specifies the level for the severity. This allows the different level of criticality to be
assigned for the same type of severity. Severity level can be between 0 to 9.
[Optional] Specifies the comments to be added to the user defined severity to help track the history.
-replace
[Optional] Indicates existing severity, <severity_name> to be deleted and recreated with the new
information. This option has no meaning if the <severity_name> does not exist.
DESCRIPTION
Command create_severity allows users to create user specific severity labels to be assigned for particular rule
object. Meridian CDC has following default severities predefined ;
• Severity name Error of type Error with level 5

• Severity name Warning of type Warning with level 5
• Severity name Info of type Info with level 5
User can not override the default severity labels, user can, however, create new severity names of the same
type with different level which will be taken into consideration when sorting reports. Severity with level 0 has
highest precedence and 9 has the lowest. All user created severity names, including tool severity names are

available from iDebug to be assigned to any rule object. Severity labels have to be created before it can be
assigned to any rule data or rule content object.
EXAMPLES
• Example-1 : Creating a severity MUST_FIX of type Error with higher than that of tool default Error severity
prompt> create_severity MUST_FIX -type Error -level 3 \
prompt> ? -comments "These problems cannot be waived"
• Example-2 : Creating a severity DIFFERED_WARNINGS of type Warning with the level lower than the default
Warning severity
prompt> create_severity DIFFERED_WARNS -type Warning -level 8
RELATED COMMANDS
RELATED VARIABLES
None

create_status
Create a user defined status label.
SYNTAX
string create_status
<status_name>
-type <Review | Signoff>
-level <status_level>
[-replace]
Data Type
status_name string
status_level integer [0..9]
comments string
ARGUMENTS
<status_name>
[Required] Specifies the name of the new status label to be created. The <status_name> is treated as
a case insensitive string.
-type <Review | Signoff>

[Required] Specifies the type of the status, status label can be either type of "Review" or "Signoff"
label. The value of type is case insensitive. Status type <Review> has higher precedence over type
<Signoff> when deriving the status for a rule_data object from its rule_content obejcts
-level <status_level>
[Required] Specifies the level for the status type. This allows the different level of status to be
assigned for the same type. Type level can be between from 0 (highest) to 9 (lowest).
[Optional] Specifies the comments to be added to the user defined status to help track the history.
-replace
[Optional] Indicates existing status, <status_name> to be deleted and recreated with the new
information. This option has no meaning if the <status_name> does not exist.
DESCRIPTION
Command create_status allows users to create user specific status labels which can be assigned to specific
rule content objects to indicate the verification status of the results to ease the usability. The status has two
types, "Review" and "Signoff". The command provides a way for user to create user defined status label of
aforementioned types to meet their methodology requirements. Each type has its own level (or precedence) to
indicate the order how they should be ordered when sorting based on the status attribute (in both ascending
and descending order), each type has level 0 (highest precedence) to 9 (lowest precedence). Meridian CDC has
following default status predefined ;
List of default <Review> type status label available in Meridian CDC :

• Status RUNFORMAL of type Review with level 9

• Status SECONDARY of type Review with level 7
• Status PRIMARY of type Review with level 6
• Status ASSIGNED of type Review with level 5
• Status TOBEREVIEWED of type Review with level 4
• Status CRITICAL of type Review with level 3
List of default <Signoff> type status label available in Meridian CDC :
• Status SIGNEDOFF of type Signoff with level 6

• Status PRESIGNEDOFF of type Signoff with level 5
All the status labels are available from iDebug for users to assign them to rule contents (or verification
results). The status labels have to be defined first before it can be assigned (thus making them available in
iDebug) to any rule content object. The default status labels cannot be overridden by user, any attempt to
override the built-in status is ignored with a message to indicate such attempt.
EXAMPLES
• Example-1 : Creating a status label named CRITICAL_ERROR
prompt> create_status CRITICAL_ERROR -type Review -level 4 \
prompt> ? -comments "Problems that must be fixed"
• Example-2 : Creating a status label named ENV_CONFLICT

prompt> create_status IP_CONFLICT -type Review -level 2 \
prompt> ? -comments "Setup issues due to IP integration"
• Example-3 : Creating a status label named USER_SIGNEDOFF

prompt> create_status USER_SIGNEDOFF -type Signoff -level 3 \
prompt> ? -comments "Setup issues due to IP integration"
RELATED COMMANDS
RELATED VARIABLES
None

Create a view criteria.
SYNTAX
string create_view_criteria
-name <vc_name>
-criteria <expression> [-regexp]
[-module <module_name> [-exclude_instances <exclude_instances>]] | [-instances <inst_names>]
[-group_exclusive]
[-group_expression <expression>]
[-replace]
[-rule <rule_list>]
[-help]
Data Type
vc_name string
expression string
module_name string
exclude_instances
inst_names
comments string
rule_list string
ARGUMENTS
-name <vc_name>
[Required] Specifies the name for the user defined view criteria. Space character is not allowed for
the name.
-criteria <expression>
[Required] Specifies the <expression> as a matching criteria. The <expression> is evaluated based
on the attribute of the rule policy objects or command spec objects. The object is included in the
return collection if the <expression> is evaluated to true (see the filter_collection for details of
<expression>).
-regexp
[Optional] Indicates that pattern provided to attributes in the <expression> to be treated as Tcl regular
expressions.
the module (or design) name view criteria to be applied to. When -module is used, view criteria is
applied to all the instances of the module, use -exclude_instances if certain instances of the module
need to be excluded.
with -instance option is a command syntax error. Specifies the list of instances the view criteria to

be excluded from applying. Names of the <exclude_instances> can either be a list of names or a
collection.
Specifies the list of instances the view criteria to be applied to. Names of the <instances> can either
be a list of names or a collection.
-group_exclusive
[Optional] Prevents matching rule data where any rule content does not match an element of the -
group_expression <expression>.
-group_expression <expression>
[Optional] List of expressions, each one matching a different rule content.
[Optional] Specifies the comments to be added to the view criteria object to help track the history.
-replace
[Optional] Indicates existing view criteria, <vc_name> to be deleted and recreated with the new
information. This option has no meaning if <vc_name> does not exist.
-rule <rule_list>
[Optional] List of rules to which to restrict the view criteria.
-help
DESCRIPTION
Command create_view_criteria allows users to define customized views that can be used for reporting as well
as display. This user defined views can also be used to access RIDB objects where necessary, once the views
are created they are stored in the RIDB and can be used in subsequent commands and also be available to be
accessed via get_view_criteria command.
The view criteria can be named by the user, if not specified, Meridian CDC assigns a <vc_name> automatically
which can be used when querying the criteria. The <expression> is formed based on the attributes of the RIDB
objects, which follows the same functionality provided in the filter_collection command. See the examples
section below for more details.
The command also provides -comment option where user can specify the intent of the user defined view
criteria, which can later be accessed via view criteria object.
EXAMPLES
• Example-1 : Create view criteria that collects W_DATA between clkA domain and clkB domain
prompt> create_view_criteria -name mydata \
prompt> ? -criteria {((type == W_DATA) && ((FromClockDomain == clkA ||
FromClockDomain == clkB) && \
prompt> ? (ToClockDomain == clkA || ToClockDomain == clkB)))} \
prompt> ? -comments "These are configuration registers"
• Example-2 : Create view criteria that collects W_RECON_GROUPS groups that have ONLY control signals that
contain *Read* and *Data* strings

prompt> create_view_criteria -name {groupand_exclusive} -rule {W_RECON_GROUPS} \

prompt> ? -group_expression [list {ControlSignal =~ "*Read*"} {ControlSignal =~
"*Data*"}] \
prompt> ? -group_exclusive
RELATED COMMANDS
create_rule_policy
create_rule_group
create_rule_instance
get_attribute
get_rule_data
get_rule_contents
report_policy
set_attribute
RELATED VARIABLES
None

define_proc_attributes
Meridian CDC supports the define_proc_attributes Synopsys® Tcl extension for specifying attributes for proc arguments
and help information. To use define_proc_attributes, make a call to it outside your proc but before you use the proc.
The syntax for define_proc_attributes is as follows:
define_proc_attributes <your_proc_name> -info "<help text>" -define_args <list_of_lists>
where
Argument Description
<your_proc_name> Name of your proc
<help text> Description of what your proc does, for help text display
<list_of_lists> Definition for each proc argument and the properties of that argument
The items in the <list_of_lists> have the following fields:
-defing_args {
{<arg_name> "<help text>" <help_v_arg_name> <data_type> <optional_or_required>}
...
}
where
<arg_name> Name of a proc argument
<help text> Description of the argument's purpose, for help text display
<help_v_arg_name> Argument name for help -v (typically the same as <arg_name>)
Note: Because help -v uses <arg_name> as the name for booleans, specify
<help_v_arg_name> as a null string for boolean arguments.
<data_type> Expected data type used for argument validation; one of the following:
string|list|boolean|int|float|one_of_string
<optional_or_required> Specifies whether the argument is optional or required
For example:
-define_args { {mode "Mode (required)" mode string required} }
For more information, see Synopsys documentation.

delete_view_criteria
Delete a view criteria.
SYNTAX
string delete_view_criteria
<vc_name>
[-help]
Data Type
vc_name list or collection
ARGUMENTS
<vc_name>
[Required] Specifies the name of the user-defined view criteria you want to delete.
-help
EXAMPLES
• Example-1 : Delete view criteria mydata
prompt> delete_view_criteria mydata
RELATED COMMANDS
RELATED VARIABLES
None

exit
Exits the program. Returns the program exit value.
SYNTAX
string exit
ARGUMENTS
None.
EXAMPLES
• Example-1 : Exit the program
prompt> exit
**> exit 0
RELATED COMMANDS
None.
RELATED VARIABLES

export_associations
Export associations.
NOTE: Meridian RDC does not support this command.
SYNTAX
export_associations
[-name <name>]
[-output <file_name>]
[-help]
Data Type
name string
file_name string
ARGUMENTS
-name <name>
[Optional] List of one or more names of associations you want to export. If you do not specify -name,
all associations are exported.
-output <file_name>
[Optional] Name of exported associations file. By default, the output of this command is displayed to
standard output.
-help
EXAMPLES
• Example-1 : Export all associations to standard output
prompt> export_associations
• Example-2 : Export all associations to export.asn

prompt> export_associations -output export.asn
• Example-3 : Export assocation A1 to A1.asn

prompt> export_associations -name A1 -output A1.asn
RELATED COMMANDS
None
RELATED VARIABLES
none

export_reclassifications
Export reclassifications.
SYNTAX
export_reclassifications
[-rule <name>]
[-help]
Data Type
name string
file_name string
ARGUMENTS
-rule <name>
[Optional] List of one or more rules whose reclassifications you want to export. If you do not specify -
name, reclassifications for all rules are exported.
-output <file_name>
[Optional] Name of exported reclassifications file. By default, the output of this command is displayed
to standard output.
-help
EXAMPLES
• Example-1 : Export all reclassifications to standard output
prompt> export_reclassifications
• Example-2 : Export all reclassifications to export.rcl

prompt> export_reclassifications -output export.rcl
• Example-3 : Export reclassifications for rule DATA to DATA.rcl

prompt> export_associations -rule DATA -output DATA.rcl
RELATED COMMANDS
None
RELATED VARIABLES
none

export_rule_status
Export RuleContentStatus for a given run and scenario in the form of commands that can be imported in a future run.
SYNTAX
export_rule_status
[-all | -status <status>]
[-command <commands>]
[-expand_pattern]
[-group]
[-incremental]
[-rule <rule_name>]
[-run <run_name>]
[-scenario <scenario>]
[-view_criteria <view_criteria>]
[-help]
Data Type
status string
commands string or list
rule_name string
run_name string
scenario string
view_criteria string
file_name string
ARGUMENTS
-all | -status <status>
[Optional] Specify -all to export all RuleContentStatus.
[Optional] Specify -status to export only RuleContentStatus with the specified <status>.
By default, only user-edited statuses are exported.
-command <commands>
[Optional] One or more commands that generated the RuleContentStatus you are exporting. The
default is all commands.
-incremental
[Optional] Export only incremental statuses since the last run of Meridian CDC.
-expand_pattern
[Optional] Export expression patterns expanded as an AND expression of pivot columns.
-group
[Optional] Write a single set_rule_status command for each group violation (same RuleDataId) of the
rule you are exporting.
-rule <rule_name>
[Required] Name of rule whose RuleContentStatus you are exporting.

-run <run_name>
[Optional] Name of run whose statuses you want to export. The current run is the default.
[Optional] Name of scenario whose statuses you want to export. The default is the current scenario,
__ri_default.
-view_criteria <view_criteria>
[Optional] Name of view criteria whose RuleContentStatus you are exporting.
-output <file_name>
[Optional] Name of exported rule status file. By default, the output of this command is displayed to
standard output.
-help
DESCRIPTION
You can export all RuleContentStatus, or only user-edited statuses. Optionally, you can specify a run, and
scenario, whose statuses you want to export.
EXAMPLES
• Example-1 : Exporting all RuleContentStatus
prompt> export_rule_status -all
• Example-2 : Exporting only user-edited statuses

prompt> export_rule_status
• Example-3 : Exporting RuleContentStatus for a specific run and scenario

prompt> export_rule_status -run run1 -scenario sc1
RELATED COMMANDS
set_rule_status
RELATED VARIABLES
none

export_view_criteria
Export view criteria.
SYNTAX
string export_view_criteria
[-name <vc_name>]
[-output <name>]
[-help]
Data Type
vc_name list or collection

name string
ARGUMENTS
-name <vc_name>
[Optional] Specifies the name of the user-defined view criteria you want to export. If you do not
specify a name, Meridian CDC exports all view criteria.
-output <name>
[Optional] Output file name to which to export the specified view criteria. If you do not specify an
output file name, the view criteria are exported to standard out.
-help
EXAMPLES
• Example-1 : Export view criteria mydata
prompt> export_view_criteria mydata
• Example-2 : Export all view criteria

prompt> export_view_criteria
RELATED COMMANDS
delete_view_criteria
RELATED VARIABLES
None

get_project
Returns the current project name.
SYNTAX
string get_project
ARGUMENTS
None.
EXAMPLES
• Example-1 :
prompt> get_project
RELATED COMMANDS
set_project
RELATED VARIABLES

get_signals
Returns a collection of signals with attributes, including clock and env information.
Attribute Name Attribute Value

name string
waveform list
reset_phase_value 1|0|X
steady_state_value 1|0|X
stable true | false
environment (environment command on that signal; one of the following)
create_clock
create_reset
create_input
create_output
set_initial_value
set_stable_value
set_constant
set_initial_state
NULL
SYNTAX
string get_signals
<signal>
[-help]
ARGUMENTS
<signal>
[Required] Name of signal to be returned in the collection.
-help
[Optional] Displays help text for this command.
EXAMPLES
• Example-1 :
prompt> get_signals u_inst1/in1
• Example-2 :
prompt> get_attribute [get_signals u_inst1/in1] waveform
RELATED COMMANDS
get_attribute
RELATED VARIABLES

help
Get help on a particular topic (command, rule, variable), or get a list of variables or commands.
SYNTAX
string help
[vars|<command|variable|rule>]
Data Type
command|variable|rule string
ARGUMENTS
vars
[Optional] List all valid Tcl variables.
<command|variable|rule>
[Optional] Specifies the help topic you want to display. Type a valid command, Tcl variable, or rule
category.
EXAMPLES
• Example-1 : Get help on a particular variable
prompt> help ri_session_name
**> help ri_session_name
Session name string that is provided via the -session switch. Read-only variable.
• Example-2 : Get help on a particular command

prompt> help read_env
**> help read_env
read_env
Read Real Intent design environment (ENV) files.
****** Required Arguments ********

<file list> Space-separated list of ENV files to be read.
****** Optional Arguments ********

-all_errors: Set maximum number of errors to be reported as unlimited.
When -all_errors is used, -max_errors is ignored.
-case_insensitive: Treat design object names in a case insensitive manner.
-max_errors: Limit maximum number of errors to be reported.
Default value: 1000.
-quiet: Suppress echoing of contents while reading the given files.
-replace: Remove content of the target scenario before reading the
given files.
-scenario: Store contents of the given files in the given scenario.
-syntax_only: Check contents of the given files for syntax/semantic errors
only.
-help: Display this help message.

• Example-3 : Get help on a particular rule category

prompt> help W_GLITCH
**> help W_GLITCH
17057: These are synchronizers driven by combinational logic. Combinational
logic can generate glitches, and the glitches may be captured
by the synchronizer, creating a spurious control signal.
Structural analysis identifies control signals that reconverge...
RELATED COMMANDS
None.
RELATED VARIABLES
None.

import_status
Import previous run status to current run.
SYNTAX
import_status
-project <project_dir>
Data Type
project_dir meridian project

directory
design_name design top module
name
ARGUMENTS
-project <project_dir>
[Required] Meridian project directory.
[Required] Design top module name.
[Optional] Scenario to import status from. Uses default scenario by default.
EXAMPLES
• Example-1 :
prompt> import_status -project meridian_project_old -design top
RELATED COMMANDS
RELATED VARIABLES

list_asserts
Lists the assertions for the current design.
SYNTAX
string list_asserts
[-rtl]
[-file <file_name>]
[-help]
Data Type
file_name string
ARGUMENTS
-rtl
[Optional] List the original RTL assertions.
-file <file_name>
[Optional] Specify a file to which to write the list of assertions.
-help
[Optional] Display this help text.
EXAMPLES
• Example-1 : List asserts for the current design
prompt> list_asserts
**> list_asserts
Listing of asserts for design "eth_top" :
SAC:wishbone.parallel_82e88_50d185_ALWAYS_51505b
SAC:wishbone.parallel_2753fbb2_fdf0bd7d_ALWAYS_fdf13c53
SAC:wishbone.parallel_3beaa54_78ff41c_ALWAYS_3c830f7
SAC:wishbone.parallel_7af7e_146f96d_ALWAYS_cda072
SAC:wishbone.parallel_fa94_1e49a50_ALWAYS_cda072
SAC:wishbone.parallel_7af7e_30f6b0_ALWAYS_175424
SAC:wishbone.parallel_70f093_ALWAYS_e5b5ad
SAC:wishbone.parallel_70f092_17d4f75_ALWAYS_be3545
SAC:wishbone.full_70f092_17d4f75_ALWAYS_be3545
SAC:wishbone.parallel_70f092_d3eb0e_ALWAYS_d212e2
SAC:wishbone.parallel_70f092_226c7bd_ALWAYS_22303b2
SAC:wishbone.parallel_ee94_445f087_ALWAYS_22303b2
SAC:wishbone.parallel_7dd28_26b53b83_ALWAYS_fda36e3
• Example-2 : List the original RTL assertions

prompt> list_asserts -rtl
**> list_asserts -rtl

Listing of asserts in the RTL for design "eth_top" :

SAC:wishbone.parallel_82e88_50d185_ALWAYS_51505b
SAC:wishbone.parallel_2753fbb2_fdf0bd7d_ALWAYS_fdf13c53
SAC:wishbone.parallel_3beaa54_78ff41c_ALWAYS_3c830f7
SAC:wishbone.parallel_7af7e_146f96d_ALWAYS_cda072
SAC:wishbone.parallel_fa94_1e49a50_ALWAYS_cda072
SAC:wishbone.parallel_7af7e_30f6b0_ALWAYS_175424
SAC:wishbone.parallel_70f093_ALWAYS_e5b5ad
SAC:wishbone.parallel_70f092_17d4f75_ALWAYS_be3545
SAC:wishbone.full_70f092_17d4f75_ALWAYS_be3545
SAC:wishbone.parallel_70f092_d3eb0e_ALWAYS_d212e2
SAC:wishbone.parallel_70f092_226c7bd_ALWAYS_22303b2
SAC:wishbone.parallel_ee94_445f087_ALWAYS_22303b2
SAC:wishbone.parallel_7dd28_26b53b83_ALWAYS_fda36e3
• Example-3 : List assertions to a file

prompt> list_asserts -file assertions.txt
**> list_asserts -file assertions.txt

List of asserts for design "eth_top" have been written to file "assertions.txt"
• Example-4 : List original RTL assertions to a file

prompt> list_asserts -rtl -file assertions.txt
**> list_asserts -rtl -file assertions.txt

List of asserts for design "eth_top" have been written to file "assertions.txt"
RELATED COMMANDS
None
RELATED VARIABLES
None

list_assumes
Lists the assumptions for the current design.
SYNTAX
string list_assumes
[-rtl]
[-file <file_name>]
[-help]
Data Type
file_name string
ARGUMENTS
-rtl
[Optional] List the original RTL assumptions.
-file <file_name>
[Optional] Specify a file to which to write the list of assumptions.
-help
EXAMPLES
• Example-1 : List assumptions for the current design
prompt> list_assumes
• Example-2 : List the original RTL assumptions

prompt> list_assumes -rtl
• Example-3 : List assumptions to a file

prompt> list_assumes -file assumes.txt
• Example-4 : List original RTL assumptions to a file

prompt> list_assumes -rtl -file assumes.txt
RELATED COMMANDS
None
RELATED VARIABLES
None

list_attributes
List attributes for given classes.
SYNTAX
string list_attributes
-class <class>
<object>
Data Type
class list
object list or collection
ARGUMENTS
-class <class>
Name of class(es) for which to list attributes. Use [list] to specify multiple classes.
<object>
Object(s) for which to list attributes.
EXAMPLES
• Example-1 :
prompt> list_attributes pin1
RELATED COMMANDS
RELATED VARIABLES

list_categories
Lists valid report categories or rules.
SYNTAX
string list_categories
ARGUMENTS
None.
EXAMPLES
• Example-1 : List report categories in Meridian CDC
prompt> list_categories
**> list_categories
Below are the list of valid report categories. Deprecated categories are not shown.
...
RELATED COMMANDS
None
RELATED VARIABLES
None

list_ports
Lists the ports for the current design.
SYNTAX
string list_ports
[-file <file_name>]
[-help]
Data Type
file_name string
ARGUMENTS
-file <file_name>
[Optional] Specify a file to which to write the list of ports.
-help
EXAMPLES
• Example-1 : List ports for the current design
prompt> list_ports
**> list_ports
# List of input ports for design "eth_top"

SyncReset
wb_clk_i
wb_rst_i
wb_dat_i[31:0]
wb_adr_i[11:2]
wb_sel_i[3:0]
wb_we_i
wb_cyc_i
wb_stb_i
m_wb_dat_i[31:0]
m_wb_ack_i
m_wb_err_i
mtx_clk_pad_i
mrx_clk_pad_i
mrxd_pad_i[3:0]
mrxdv_pad_i
mrxerr_pad_i
mcoll_pad_i
mcrs_pad_i
md_pad_i
## Number of input ports for design "eth_top" = 20

# List of inout ports for design "eth_top"

## Number of inout ports for design "eth_top" = 0
# List of output ports for design "eth_top"

wb_dat_o[31:0]
wb_ack_o
wb_err_o
m_wb_adr_o[31:0]
m_wb_sel_o[3:0]
m_wb_we_o
m_wb_dat_o[31:0]
m_wb_cyc_o
m_wb_stb_o
mtxd_pad_o[3:0]
mtxen_pad_o
mtxerr_pad_o
mdc_pad_o
md_pad_o
md_padoe_o
int_o
## Number of output ports for design "eth_top" = 16
• Example-2 : List ports to a file

prompt> list_ports -file ports.txt
**> list_ports -file ports.txt

List of top-level ports for design "eth_top" have been written to file "ports.txt"
RELATED COMMANDS
None
RELATED VARIABLES
None

parse_proc_arguments
Meridian CDC supports the parse_proc_arguments Synopsys Tcl extension, which calls the standard parser and returns
the arguments of a proc in an array. To use parse_proc_arguments, make a call to it just inside your proc. For example:
parse_proc_arguments -args $args arg_array
where arg_array is an associative array containing all the argument values when the proc was called.
You can then use define_proc_attributes to specify help information for the arguments.
For more information, see Synopsys documentation.

promote_rule_status
Promote RuleContentStatus and Comments to instances of a block-level module in the current top-level run.
SYNTAX
string promote_rule_status
-rule <rule_name>
-expression <expr> [-group_expression <expr_list> [-group_exclusive]] | -use_view_criteria <view_criteria> | -
column_regexp <expr> | -line_expression <expr>
-module <name>
-instance <name>
[-create_view_criteria <view_criteria> [-replace]]
[-lastedit_time {<value>}]
[-lastedit_user {<value>}]
[-line_expression <expr>]
[-map_multiple_waveforms]
[-status <value>]
[-comment <comment_text>]
[-help]
Data Type
rule_name string
expr, expr_list string
value string
comment_text string
ARGUMENTS
-rule <rule_name>
[Required] Name of rule whose RuleContentStatus and Comments you are specifying.

[Required] Expression (-expression) or view criteria (-use_view_criteria) to specify a subset of rule
contents, or an expression to be matched against column data (-column_regexp), or an expression to
be matched against an entire rule content line (-line_expression).
-group_expression <expr_list> specifies a list of expressions, each one matching a different
rule_content.
-group_exclusive prevents matching rule_data where any rule_content does not match an element of -
group_expression.
-module <name>
[Required] Block-level module whose status and/or comments you are promoting. Parameterized
module names should be used.
-instance <name>
[Required] Instance of the block-level module in the current top-level run.
-create_view_criteria <view_criteria> [-replace]

[Optional] View criteria to write out for what was waived. Optionally replace existing view criteria, if
used.
-lastedit_time {<value>}
[Optional] Update LastEditTime to this value. For example, -lastedit_time {Wed May 11 09:30:21 2016}
-lastedit_user {<value>}
[Optional] Update LastEditUser to this value. For example, -lastedit_user {MyUser}
-map_multiple_waveforms
[Optional] Maps block waveforms to multiple top-level waveforms (defined using set_waveform_map
prior to running Meridian CDC).
-status <value>
[Optional] Status keyword to set for the specified rule contents: New, ToBeFixed, Deferred, Waived.
You must specify either -status or -comment, or both.
-comment <comment_text>
[Optional] Comment text to apply to the specified rule contents. You must specify either -comment or
-status, or both.
-help
EXAMPLES
• Example-1 : Promote RuleContentStatus and Comments for a rule
prompt> promote_rule_status -rule W_GLITCH -expr RuleDataId=2 -status Waived -comment
"Bob indicates this is not a problem"
• Example-2 :
prompt> promote_rule_status -rule {S_MULTCLK} -expression {Signal=="in_a"} -status
{Waived} -comment "This multclk is okay because in_a gets blocked earlier in the
logic"
• Example-3 :
prompt> promote_rule_status -rule {W_RECON_GROUPS} -expression {ReceivingFlop=="d1"}
-group_expression {FromClockDomain=~"clk_a" || FromClockDomain=~"clk_b"}
The above command matches W_RECON_GROUPS RuleDataIds with ReceivingFlop "d1", with
FromClockDomain within each RuleDataId having both "clk_a" and "clk_b". If you add -group_exclusive
to that, only RuleDataIds with FromClockDomain having both "clk_a" and clk_b" and no other clocks
will match.
RELATED COMMANDS
None
RELATED VARIABLES
None

promote_rule_status_from_file
Promote RuleContentStatus and Comments to instances of a block-level module in the current top-level run, read in
from a block-level status file.
SYNTAX
string promote_rule_status_from_file
<file_name>
[-help]
Data Type
file_name, name string

instances list
ARGUMENTS
<file_name>
[Required] Name of file containing block-level set_rule_status commands.

[Required] Block-level module or instances of a block-level module whose status and/or comments
you are promoting. If you specify -module, you can use -exclude_instances to specify instances of
the block-level module whose status and/or comments you do not want to promote. Parameterized
module names should be used.
-output <file_name>
[Optional] Name of file capturing promote_rule_status commands as they get executed. The default
file name is promoted_<module>_status_commands.tcl.
-help
EXAMPLES
• Example-1 : Using non parameterized module
prompt> promote_rule_status_from file -module m1 block_waivers.tcl
• Example-2 : Using non parameterized module

prompt>
foreach mod [get_all_modules m1] {
promote_rule_status_from file -module $mod block_waivers.tcl
}
RELATED COMMANDS
promote_rule_status

set_rule_status
RELATED VARIABLES
None

report_messages
Generate a report of messages in the given run.
SYNTAX
string report_messages
[-id <msg_ids>] | [-severity <msg_severity>] [-command <cmd_name>]
[-include_suppressed_messages]
[-run_id <run_id>]
[-verbose]
Data Type
msg_severity list
msg_ids list of integers
command_name list of commands
file_name string
run_id string
ARGUMENTS
-id <msg_ids>
[Optional] This is mutually exclusive with -severity option, you must use only one. Specify the list of
message IDs to be reported.
-severity <msg_severity>
[Optional] This is mutually exclusive with -id option, you must use only one. Specify the severity of the
messages to be reported.
-commands <cmd_names>
[Optional] This is mutually exclusive with -id option, you must use only one. Specify list of tool
commands messages associated with the commands to be reported.
-include_suppressed_messages
Indicates that user suppressed messages by variable ri_suppress_msg to be included in the report.
-output <file_name>
[Optional] Specify the file name for the report to be written out. If not specified, report is redirect to
standard output (i.e. printed to terminal).
-run_id <run_id>
[Optional] Specify the <run_id> from which to generate the report. Be default, current <run_id> used
for the report.
-verbose
Indicates that the report to include complete details of messages. If -verbose is not specified, by
default summary of the message is reported.
DESCRIPTION

By default all messages with different type of severities are reported as the Meridian CDC is run, all the
messages are also recorded in the RIDB under the run ID. However, the command allows for users to generate a
report of messages related to specific severity and list of commands.
EXAMPLES
• Example-1 : Report summary of all the messages
prompt> report_messages
Command : report_message
Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
F - Suppressed messages
----------------------------------------------------------------------------------
Severity Command ID Count Description
----------------------------------------------------------------------------------
INFO analyze 19001 19525 Analyzing file
INFO analyze 19003 6183 Analyzing included file
INFO analyze 19004 8 Redeclaration of ansiport
INFO elaborate 19006 1 Top level unit information
INFO elaborate 19007 22087 Elaborating module
INFO elaborate 19008 1 Elaborating UDP
....
....
WARN analyze 39005 126 Macro redefined
WARN analyze 39021 7 empty port in module declaration
WARN analyze 39032 2 assignment to input x
WARN elaborate 25010 43702 Signal of some module does not
affect the output
WARN elaborate 25011 64052 Some or all bits of signal do not
affect the output
WARN elaborate 25012 15482 Port of module is unused
WARN read_sdc 74003 1144 Sdc pattern did not match any
objects
WARN read_sdc 74005 1144 the object access command results
in an empty collection
WARN read_env 74007 1064 no valid objects were specified
WARN verify_cdc 37010 1 Ambiguous clocks detected at
state variables
....
....
ERR read_sdc XXXXX 2 Clock reference object was not
found
ERR read_sdc XXXXX 10 Clock object does not exist
ERR read_env XXXXX 15 Waveform specified does not exist
....
....
----------------------------------------------------------------------------------

• Example-2 : Report summary of messages with severity "WARN"

prompt> report_messages -severity WARN
Command : report_message -severity WARN

Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
F - Suppressed messages
----------------------------------------------------------------------------------
Severity Command ID Count Description
----------------------------------------------------------------------------------
WARN analyze 39005 126 Macro redefined
WARN analyze 39021 7 empty port in module declaration
WARN analyze 39032 2 assignment to input x
WARN elaborate 25010 43702 Signal of some module does not
affect the output
WARN elaborate 25011 64052 Some or all bits of signal do not
affect the output
WARN elaborate 25012 15482 Port of module is unused
WARN read_sdc 74003 1144 Sdc pattern did not match any
objects
WARN read_sdc 74005 1144 the object access command results
in an empty collection
WARN read_env 74007 1064 no valid objects were specified
WARN verify_cdc 37010 1 Ambiguous clocks detected at state
variables
....
....
----------------------------------------------------------------------------------
• Example-3 : Report verbose of message ID

prompt> report_message -id list_variables *max* -category design_compilation -
modified
Command : list_variables *max* -category design_compilation -modified

Date/Time : 01/14/2014 - 13:16:25
=========================================================
Properties:
M - user modified
D - Application defaults
R - Read only variables
------------------------------------------------------------------------
Variable Properties Type Value
------------------------------------------------------------------------
ri_max_loop_unroll M Integer 512
....

....
------------------------------------------------------------------------
• Example-4 : Report summary of messages that includes suppressed messages

prompt> report_message -includelist_variables -variable_categories
Command : list_variables -variable_categories

Date/Time : 01/14/2014 - 13:16:25
=========================================================
------------------------------------------------------------------------
------------------------------------------------------------------------
design_compilation Variables that configures design compilation
intent_analysis Variables that configures Intent Analysis step
intent_generation Variables that configures exporting the Intent
....
....
------------------------------------------------------------------------
RELATED COMMANDS
RELATED VARIABLES

report_policy
Generate a report of a rule policy in specified format.
SYNTAX
string report_policy
<rule_policies>
[-command_name <cmd_name>]
[-view_criteria <criteria_name>]
[-format <report_format>]
[-run_id <run_id>]
[-show_empty_rules]
[-sort <columns>]
[-compat]
[-verbose]
[-violationlimit <limit>]
[-iteration_count <count>]
[-skip_empty_summary_status] <-- Ascent Lint only
[-help]
Data Type
rule_policies list or collection

cmd_name list
scneario_name string or collection
criteria_name list or collection
report_format text | spreadsheet |
html
file_name string
run_id string
columns list or collection
limit integer
count integer
ARGUMENTS
<rule_policies>
[Required] Specify the list of rule policies for which to generate the report. Rule policies can be
a list of names of rule_policy or rule_group or rule_instance, or a collection containing them. The
<rule_policies> must be a homogeneous list. If not specified, all rule policies are considered.
-command_name <cmd_name>
[Optional] Specify the command name that the rule data have been been populated by to be reported.
This option help all the violations distributed in multiple policies to be reported in consolidated view.

The <cmd_name> can be a list containing one or more of read_sdc, read_env, analyze_intent, and
verify_cdc.
[Optional] Command report_policies reports all the rule data associated with specified
<scenario_name>. Current scenario is considered If -scenario is not specified, <scenario_name> can be
a singleton collection or a string.
the reference name of the instances <module_name> the report to be generated. When -module is
used, report is generated for all the instances of the given module, use -exclude_instances if certain
instances of the module need to be excluded from the report. The <module_name> can either be a
string or a collection containing design objects.
with -instance option is a command syntax error. Specifies the list of instances of the <module_name>
to be excluded from the report. Name of each <exclude_instances> must be a full name to the
instance, it can either be a list of names or a collection.
Specifies the list of instances report to be generated for. Name of each <instances> must be a full
name to the instance and can either be a list of names or a collection.
-view_criteria <criteria_name>
[Optional] Specify the list of view criteria to be applied when generating the report. Please see
create_view_criteria for the details.
-format <report_format>
[Optional] Specify the format of the report format. There are 3 type of report formats text,
spreadsheet and html are support. If <report_format> is not specified, default report format, text is
used.
-output <file_name>
[Optional] Specify the file name for the report to be written out. If not specified, report is redirect to
standard output (i.e. report is printed to terminal).
-run_id <run_id>
[Optional] Specify the <run_id> from which to generate the report. Be default, current <run_id> used
for the report.
-show_empty_rules
[Optional] Indicates that the report summary will also list rules with no violations.
-sort <columns>
[Optional] List of columns names by which you want to sort the reported results tables. For example, -
sort {Driver,ReceivingFlop}.
-compat
[Optional] Write report compatible with earlier tool versions. Adds a "RULE_NAME:" as the first token
for each Rule Content.

-verbose
[Optional] Indicates that the report to include complete details of requested report in the specified
format. If -verbose is not specified, summary of the given <rule_policies> is generated.
-violationlimit
[Optional] Limits the number of violations per rule instance in the report to the given value.
-iteration_count
[Optional] Sets up writing rule instances in iterations of given size.
-skip_empty_summary_status
[Ascent Lint only] [Optional] Skips empty status columns when reporting summary status.
-help
[Optional] Display help text.
DESCRIPTION
When strings are specified as <rule_policies>, the command searches rule_policy, rule_group, rule_instance,
and rule_data in that order to find the objects for the report to be generated. The first object that matches
the pattern is taken for the report generation.
EXAMPLES
• Example-1 : Using Policy name
prompt> report_policy NEW
• Example-2 : Using rule instances

prompt> report_policy [get_rule_instances NEW*MCDC_SETUP_CHECKS*]

prompt> report_policy [get_rule_instances NEW*W_DATA*]

prompt> report_policy [get_rule_instances *W_DATA*]
RELATED COMMANDS
RELATED VARIABLES

set_project
Set the project directory
SYNTAX
string set_project
[project]
Data Type
project string
ARGUMENTS
<project>
Name of project directory
EXAMPLES
• Example-1 :
prompt> set_project new_proj_dir
RELATED COMMANDS
RELATED VARIABLES

set_rule_status
Set RuleContentStatus and Comments in the current run.
SYNTAX
set_rule_status
-rule <rule_name>
[-create_view_criteria <view_criteria> [-replace]]
[-lastedit_time {<value>}]
[-lastedit_user {<value>}]
[-line_expression <expr>]
[-status <value>]
[-comment <comment_text>]
[-help]
Data Type
rule_name string
expr, expr_list string
value string
comment_text string
ARGUMENTS
-rule <rule_name>
[Required] Name of rule whose RuleContentStatus and Comments you are specifying.

[Required] Expression (-expression) or view criteria (-use_view_criteria) to specify a subset of rule
contents, or an expression to be matched against column data (-column_regexp), or an expression to
be matched against an entire rule content line (-line_expression).
-group_expression <expr_list> specifies a list of expressions, each one matching a different
rule_content.
-group_exclusive prevents matching rule_data where any rule_content does not match an element of -
group_expression.
-create_view_criteria <view_criteria> [-replace]

[Optional] View criteria to write out for what was waived. Optionally replace existing view criteria, if
used.
-lastedit_time {<value>}
[Optional] Update LastEditTime to this value. For example, -lastedit_time {Wed May 11 09:30:21 2016}
-lastedit_user {<value>}
[Optional] Update LastEditUser to this value. For example, -lastedit_user {MyUser}
-status <value>

[Optional] Status keyword to set for the specified rule contents: New, ToBeFixed, Deferred, Waived.
You must specify either -status or -comment, or both.
-comment <comment_text>
[Optional] Comment text to apply to the specified rule contents. You must specify either -comment or
-status, or both.
-help
DESCRIPTION
You can set RuleContentStatus and Comments in the current run.
EXAMPLES
• Example-1 : Set RuleContentStatus and Comments for a rule
prompt> set_rule_status -rule W_GLITCH -expr RuleDataId=2 -status Waived -comment
"Bob indicates this is not a problem"
• Example-2 :
prompt> set_rule_status -rule {S_MULTCLK} -expression {Signal=="in_a"} -status
{Waived} -comment "This multclk is okay because in_a gets blocked earlier in the
logic"
• Example-3 :
prompt> set_rule_status -rule {W_RECON_GROUPS} -expression {ReceivingFlop=="d1"} -
group_expression {FromClockDomain=~"clk_a" || FromClockDomain=~"clk_b"}
The above command matches W_RECON_GROUPS RuleDataIds with ReceivingFlop "d1", with
FromClockDomain within each RuleDataId having both "clk_a" and "clk_b". If you add -group_exclusive
to that, only RuleDataIds with FromClockDomain having both "clk_a" and clk_b" and no other clocks
will match.
RELATED COMMANDS
export_rule_status
RELATED VARIABLES
none

set_run_formal
Set Run Formal flag for a given rule and signal.
SYNTAX
set_run_formal
-rule <rule_name>
-signal <signal_name>
[-group]
[-help]
Data Type
rule_name, string
signal_name
ARGUMENTS
-rule <rule_name>
[Required] Name of rule whose Run Formal flag you are setting.
[Required] Signal or signals on which to create formal checks. This name must match the value of the
relevant rule attribute, which depends on the rule as follows:
Rule Attribute
DATA ReceivingFlop
W_DATA ReceivingFlop
CNTL ReceivingFlop
W_CNTL ReceivingFlop
SYNC_CROSSING Signal
GRAY_CODE_CHECKS Signal
W_GLITCH GlitchOutput
-group
[Optional] Set Run Formal flag on entire RuleDataId matching <signal_name>.
-help
DESCRIPTION
You can set the Run Formal flag on one or more signals, including groups of signals for an entire RuleDataId.
This command provides a mechanism for performing tasks that can be accomplished in iDebug using the Run
Formal menu actions on the Engine Actions menu ribbon.
EXAMPLES
• Example-1 : Set Run Formal flag and Comments for rule W_GLITCH, signal r1, entire RuleDataId matching r1
prompt> set_run_formal -rule W_GLITCH -signal r1 -group

RELATED COMMANDS
unset_run_formal
RELATED VARIABLES
None

unset_run_formal
Unset Run Formal flag for a given rule and signal.
SYNTAX
unset_run_formal
-rule <rule_name>
[-group]
[-help]
Data Type
rule_name, string
signal_name
ARGUMENTS
-rule <rule_name>
[Required] Name of rule whose Run Formal flag you are unsetting.
[Required] Signal or signals on which to unset formal checks. This name must match the value of the
relevant rule attribute, which depends on the rule as follows:
Rule Attribute
DATA ReceivingFlop
W_DATA ReceivingFlop
CNTL ReceivingFlop
W_CNTL ReceivingFlop
SYNC_CROSSING Signal
GRAY_CODE_CHECKS Signal
W_GLITCH GlitchOutput
-group
[Optional] Unset Run Formal flag on entire RuleDataId matching <signal_name>.
-help
EXAMPLES
• Example-1 : Unset Run Formal flag for rule W_GLITCH, signal r1, entire RuleDataId matching r1
prompt> unset_run_formal -rule W_GLITCH -signal r1 -group
RELATED COMMANDS
set_run_formal
RELATED VARIABLES
None


update_view_criteria_details
Update View Criteria details in the Summary table (visible on the Summary tab on the Query pane when the
ViewCriteria side-tab is selected in iDebug)
SYNTAX
string update_view_criteria_details -view_criteria <view_criteria_name> <optional_args>
ARGUMENTS
The command arguments are as follows:
-view_criteria Name of view criteria object whose details you are updating
<view_criteria_name>
-user <owner> [Optional] String to write to the Owner column
-host <address> [Optional] String to write to the Address column
-timestamp <timestamp> [Optional] String to write to the TimeStamp column
-comments <comments> [Optional] String to write to the Comments column
-help [Optional] Display help text for this command
EXAMPLES
• Example-1 :
prompt> update_view_criteria_details -view_criteria lvc_New_INVALID_ARG_USAGE
RELATED COMMANDS
RELATED VARIABLES

INTENT Analysis Commands

The following commands are used to configure and run intent analysis using Meridian CDC.

analyze_intent
Analyze the intent of the design specification.
SYNTAX
string analyze_intent
[-tag <tag_name>]
[-async_inputs] [-async_outputs] [-async_resets] [-clock_consts_only] | [-disable_auto_intent_generation]
[-output_env <env_file>]
[-enable_clock_normalization] | [-formal] [-promote]
[-skip_setup_checks]
Data Type
tag_name string or collection

scenario_name string or collection
env_file string
ARGUMENTS
-tag <tag_name>
[Optional] Specifies the <tag_name> for design intent to be taken from for analysis, <tag_name>
can also be a singleton collection. If the <tag_name> is omitted, design specifications with latest
<tag_name> is used. Command also prints out a message indicating the <tag_name> being used for
analysis.
[Optional] Specifies the scenario for analyze_intent to be performed. Current scenario is considered
If -scenario is not specified, <scenario_name> can be a singleton collection. If scenario has not been
defined, then the scenario named "default" is created to store SDC constraints. Each named scenario
can be referenced in the session by subsequent tool commands.
-async_inputs
[Optional] Indicates that all primary inputs to be associated with a virtual clock and make it
asynchronous to all clocks that receives the inputs.
-async_outputs
[Optional] Indicates that all outputs to be associated with a virtual clock and make it asynchronous to
all clocks that drive the outputs.
-async_resets
[Optional] Indicates that all primary resets to be associated with a virtual clock and make it
asynchronous to all clocks that receive the reset.
-clock_consts_only
[Optional] Indicates that automatic constant identification to be limited to clock select signals.
-disable_auto_intent_generation
[Optional] This option is mutually exclusive with -async_inputs, -async_resets, and -clock_consts_only
options. Indicates that the automatic specification generation to be turned off and analysis to be done
only with the design specifications from the given <tag_name> and <scenario_name>.

-output_env <env_file>
[Optional] Specify the file name to write out final generated ENV specs at the end of the command
execution. If -disable_auto_intent_generation is specified, the <env_file> contains the same ENV
specs, without syntax/semantics errors. By default, <env_file> includes both user- and auto-generated
ENV specs. The default name of the ENV file is ri_default.env. If -disable_auto_intent_generation
is specified and -output_env is not specified, Meridian CDC does not output ri_default.env. See -
output_env for more information.
-enable_clock_normalization
[Optional] This option is mutually exclusive with -formal option. Indicates that the clock normalization
to be turned on. By default, clock normalization is not performed.
-formal
[Optional] This option is mutually exclusive with -enable_clock_normalization option. Indicates
that intent analysis should consider formal analysis requirements as well. Additional checks and
clock normalizations are performed to ensure that the specification provided is adequate for formal
analysis.
-promote
[Optional] Promote block-level specs to top-level specs.
-skip_setup_checks
[Optional] Skip setup checks.
DESCRIPTION
Command analyze_intent performs intent analysis on design specification of given <scenario_name> in the
provided <tag_name> which perform various checks to ensure following aspects:
1. Correctness of the specification

Command analyze_intent performs correctness check on the specifications user has read in (see
read_sdc and read_env commands for details). This correctness step includes variety of checks to
ensure that the intent specification is correct with the design intent.
2. Consistency between the specifications

Command analyze_intent also performs consistency checks between the specifications. This includes
the consistency between the specifications at the top level (of the design being analyzed) and also the
consistency between the block level specifications against the top level specifications.
3. Completeness of the specification

In addition to correctness check, analyze_intent identifies design objects where specifications should
have been created but are missing from user inputs. Those missing specifications are automatically
created, by default, during the analyze_intent when option -disable_auto_intent_generation is not
given. Options -async_input, -async_reset, and -clock_consts_only also provide ability to configure
how the missing specification to be created.
By default, analysis is performed to help user sign off on the specification required for structural analysis,
option -formal allows analyze_intent to expand the analysis to include formal analysis requirements to be
considered. Clock normalization is turned off by default, as it is not required for structural analysis. However,
clock normalization can be turned on by -enable_clock_normalization option. When -formal is specified,
clock normalization is performed automatically as it is a required step for formal analysis.

EXAMPLES
• Example-1 : Running analyze_intent on user read in specifications and command output at the end
prompt> analyze_intent -tag <initial_spec>
• Example-2 : Running analyze_intent considering formal analsysi

prompt> analyze_intent -tag <initial_spec> -formal
• Example-3 : Running analyze_intent without user specifications to create initial spec

prompt> analyze_intent -async_input -async_reset -clock_consts_only
RELATED COMMANDS
read_env
read_sdc
RELATED VARIABLES
ri_use_exact_waveform_periods_in_sdc_to_env_translation

create_scenario
Specify a list of valid scenario names. The first one will be used as the current scenario.
SYNTAX
string create_scenario
<scenarios>
Data Type
scenarios list
comments string
ARGUMENTS
<scenarios>
List of scenario names
-comment <comments>
[Optional] Specifies the comments to be added.
EXAMPLES
• Example-1 :
prompt> create_scenario {sce1 sce2}
RELATED COMMANDS
RELATED VARIABLES

read_env
Read environment specification of a design in ENV (Real Intent) format.
SYNTAX
string read_env
<file_list>
[-syntax_only]
[-case_insensitive]
[-max_errors <max_errors> | -all_errors]
[-quiet | -verbose]
[-replace]
Data Type
file_list list
max_errors integer
ARGUMENTS
<file_list>
[Required] Specifies the list of ENV files to be read in.
[Optional] Specifies the scenario to which the ENV <file_list> to be read in. If -scenario is not
specified, ENV is applied to current scenario. If scenario has not been defined, then the scenario
named "default" is created to store ENV specification. Each named scenario can be referenced in the
session by subsequent tool commands.
Specify the reference name of the instances <module_name> the ENV specification to be applied to.
When -module is used, ENV specification is applied to all the instances of the given module, use -
exclude_instances if certain instances of the module need to be exempted. The <module_name> can
either be a string or a collection containing a one design object.
ENV specification to be exempted from. Name of each <exclude_instances> must be a full name to the

Specifies the list of instances ENV specification to be applied to. Name of each <instances> must be a
full name to the instance, it can either be a list of names or a collection.
-syntax_only
[Optional] Indicates that <file_list> to be processed only to check syntax and semantics. ENV
specification read in is not stored for later use. Options -scenario and -replace are ignored when used
together with -syntax_only option.
-case_insensitive
[Optional] Indicates that reference object names to be treated in case insensitive manner.
-max_errors
[Optional] This option is mutually exclusive with -all_errors option. Specify number of error to be
printed to stdout. The default number of errors reported is limit to 1000. This is the default if -
all_errors is not specified. All the errors found during the read_env command are stored in database
and can be reported by report_env command
-all_errors
[Optional] mutually exclusive with -max_errors option. Indicates that all the errors to be printed to
stdout.
-quiet
[Optional] This option is mutually exclusive with -verbose option. Indicates that echo'ing of each ENV
command while processing to be suppressed.
-verbose
[Optional] This option is mutually exclusive with -quiet option. Indicates that results of each ENV
command to be also echoed while ENV files are processed.
-replace
[Optional] Indicates that existing ENV specification in the given scenario to be deleted before reading
in new ENV specification.
DESCRIPTION
Command read_env processes the design environment specification in the <file_list> in Real Intent
Command (ENV) format. All the commands that are processed by read_env command are stored in RIDB under
<scenario_name>. Command read_env performs syntax and semantics checks and provides a summary (see
below) at the end of the command execution. All the ENV commands processed by read_env are stored to be
used by verification engines unless -syntax_only option is used. The option -syntax_only instructs read_env
command to process the ENV commands specified in the <file_list> and perform syntax and semantic checks
without storing them. All the problems found while processing ENV are stored in the violation database for
users to diagnose.
The option -scenario indicates which scenario ENV specification to be applied to. A new scenario
<scenario_name> is created to store ENV specification if named scenario does not exist. If -scenario is not
given, scenario named "default" is created. Command read_env incrementally adds constraints to specified
<scenario_name>, if <scenario_name> exists. If existing specification needs to be deleted before reading
in new set of ENV specification, use the option -replace. Also please see the ENV File Commands section for
precedence rules when SDC constraints are applying to the design.
Command read_env allows users to read in block level ENV specification into SoC level where the blocks are
instantiated. Use option -module or -instance to specify the scope of ENV specification. When -module option

is used, ENV specification is applied to all the instances of the specified module. If certain instances need to
be excluded, use -exclude_instances to specify those instances that are to be excluded.
Command read_env returns following status upon command completion indicating the command status.
Following is the list of return status of read_env command :
1 : Indicates that no Tcl syntax errors or undefined variables and all the commands are processed by
Meridian CDC
2 : Indicates that no Tcl syntax errors or undefined variables but there are commands with status
failed.
INFO [# 12345] : Summary of ENV specification processed by read_env

-------------------------------------------------------------------------
Supported Commands Succeeded Failed (Primary) Failed (Secondary) Total
--------------------------------------------------------------------------
create_clock 4 0 0 4
create_input 1 0 0 1
create_reset 1 0 0 1
create_waveform 4 0 0 4
set_constant 5 0 0 5
--------------------------------------------------------------------------
Total: 15 0 0 15
__________________________________________________________________________
Summary report can also be generated at any given time in the flow using report_env command.
EXAMPLES
• Example-1 : Reading in ENV files for a scenario named functional
prompt> read_env func.env -scenario functional
• Example-2 : Reading in ENV files to just check the syntax

prompt> read_env func.env -syntax_only
• Example-3 : Replace existing ENV specification and apply new ENV for a scenario
prompt> read_env func.env -scenario functional -replace
• Example-4 : Reading ENV files and stop based on the status of read_env command
prompt> set _cmdstatus_ [read_env func.env]
prompt> if {[expr ${_cmdstatus_} == 1]} then {
prompt> ? puts "INFO: read_env command Succefully processed the ENV Specification" }
prompt> ? puts "ERROR: Some ENV commands failed"
prompt> ? return -code error }
RELATED COMMANDS
read_sdc
RELATED VARIABLES
ri_env_priority_order
ri_override_input_spec_for_reset_or_mode_identification


read_sdc
Read timing intent of a design in SDC (Synopsys Design Constraints) format.
SYNTAX
string read_sdc
<file_list>
[-version <sdc_version>]
[-output_env <env_file_name>]
[-syntax_only]
[-case_insensitive]
[-max_errors <max_errors> | -all_errors]
[-quiet | -verbose]
[-replace]
Data Type
file_list list
sdc_version float

max_error integer
env_file_name string
ARGUMENTS
<file_list>
[Required] Specifies the list of SDC files to be read in (or executed).
-version <sdc_version>
[Optional] Specifies the version of SDC which the <file_list> conform to. Allowed values are 1.0, 1.1,
1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, and 1.9. if the version is not specified, default is the latest version
1.9.
[Optional] Specifies the scenario to which the SDC <file_list> to be read in. If -scenario is not
specified, SDC is applied to current scenario. If scenario has not been defined, then the scenario
named "default" is created to store SDC constraints. Each named scenario can be referenced in the
session by subsequent tool commands.
-output_env <env_file_name>
[Optional] Specifies the output env file name. This option is used to generate a corresponding env
format for sdc file being read. See -output_env for more information.

Specify the reference name of the instances <module_name> the SDC constraints to be applied to.
When -module is used, SDC constraints is applied to all the instances of the given module, use -
exclude_instances if certain instances of the module need to be exempted. The <module_name> can
either be a string or a collection containing a one design object.
constraints to be exempted from. Name of each <exclude_instances> must be a full name to the
Specifies the list of instances SDC constraints to be applied to. Name of each <instances> must be a
full name to instance, it can either be a list of names or a collection.
-syntax_only
[Optional] Indicates that <file_list> to be processed only to check syntax and semantics. Constraints
read in will not be stored for later use. Options -scenario and -replace are ignored when used together
with -syntax_only option.
-case_insensitive
[Optional] Indicates that reference object names to be treated in case insensitive manner.
-max_errors
[Optional] This option is mutually exclusive with -all_errors option. Specify number of error to be
printed to stdout. The default number of errors reported is limit to 1000. This is the default if -
all_errors is not specified. All the errors found during the read_sdc command are stored in database
and can be reported by report_sdc command.
-all_errors
[Optional] mutually exclusive with -max_errors option. Indicates that all the errors to be printed to
stdout.
-quiet
[Optional] This option is mutually exclusive with -verbose option. Indicates that echo'ing of each SDC
command while processing to be suppressed.
-verbose
[Optional] This option is mutually exclusive with -quiet option. Indicates that results of each SDC
command to be also echoed while SDC files are processed.
-replace
[Optional] Indicates that existing SDC constraints in the given scenario to be deleted before reading in
new SDC constraints.
DESCRIPTION
Command read_sdc processes the design constraints in the <file_list> in Synopsys Design Constraints (SDC)
format. All the commands that are processed by read_sdc are stored in RIDB under <scenario_name>.
Command read_sdc performs syntax and semantics checks and provides a summary (see below) at the end of
the command execution. All the SDC constraints processed by read_sdc are stored to be used by verification
engines unless -syntax_only option is used. The option -syntax_only instructs read_sdc command to process

the SDC specified in the <file_list> and perform syntax and semantic checks without storing any constraints.
The option -syntax_only conforms to the <sdc_version> provided during the syntax and semantics checks. All
the problems found while processing are stored in the violation database for users to diagnose.
The option -scenario indicates which scenario SDC constraints to be applied to. A new scenario
<scenario_name> is created to store SDC constraints if named scenario does not exist. If -scenario is not
given, scenario named "default" is created. Command read_sdc incrementally adds constraints to specified
<scenario_name> by default, this incremental behavior is true when reading in SDC constraints with -module
and -instances. If existing constraints in particular <scenario_name> need to be deleted before reading in
new set of constraints use the option -replace, a message is printed to indicate such scenario. Also please see
the SDC Commands section for precedence rules when SDC constraints are applying to the design.
When user SDC constraints contains SDC command options that are not supported by Meridian CDC, read_sdc
process those commands based on the variable ri_sdc_ignore_unsupported_options setting. If variable is set
to true (default), unsupported options are ignored and SDC commands are executed as if the options were not
specified. if set to false, SDC commands with unsupported options are marked failed and not executed. For the
SDC constraint commands that are not supported by Meridian CDC are stored and not executed. At the end of
the read_sdc command summary is reported to indicate all the commands that are processed, summary of the
commands that are not supported and the list of commands with the unsupported options.
Command read_sdc allows users to read in block level SDC into SoC level where the blocks are instantiated.
Use option -module or -instance to specify the scope of the SDC constraints. When -module option is used,
SDC constraints are applied to all the instances of the specified module. If certain instances need to be
excluded, use -exclude_instances to specify those instances that are to be excluded. When SDC
Command read_sdc returns following status upon command completion indicating the command status.
Following is the list of return status of read_sdc command :
1 : Indicates that no Tcl syntax errors or undefined variables and all the commands are processed by
Meridian CDC
2 : Indicates that no Tcl syntax errors or undefined variables but there are unknown commands and/or
options which the Meridian CDC is unable to process.
INFO [# 12345] : Summary of SDC constraints processed by read_sdc
------------------------------------------------------------------------------
------------------------------------------------------------------------------
create_generated_clock 1 0 0 1
get_clocks 22 0 0 22
get_pins 1 0 0 1
get_ports 19 2 0 21
set_false_path 3 0 0 3
set_input_delay 9 0 1 10
set_output_delay 6 0 1 7
------------------------------------------------------------------------------
Total: 68 2 2 72
Summary report can also be generated at any given time in the flow using report_sdc command, see the
command help for more details.
EXAMPLES

• Example-1 : Reading in SDC files for a scenario named functional

prompt> read_sdc func.sdc -scenario functional
• Example-2 : Reading in SDC files to just check the syntax for SDC version 1.9
prompt> read_sdc func.sdc -syntax_only -version 1.9
• Example-3 : Replace existing constraints and reading in new SDC constraints for a scenario
prompt> read_sdc func.sdc -scenario functional -version 1.9 -replace
• Example-4 : Reading SDC files and stop based on the status of read_sdc command
prompt> set _cmdstatus_ [read_sdc func.sdc -version 1.9]
prompt> ? puts "INFO: read_sdc command Succefully processed the SDC Constraints" }
prompt> ? puts "ERROR: read_sdc found unknown commands/options"
prompt> ? return }
RELATED COMMANDS
RELATED VARIABLES

report_env
Generate a report of ENV read in.
SYNTAX
string report_env
[<command_names>]
[-status <command_status> | -all]
[-tag_name <tag_name>]
[-run_name <run_id>]
Data Type
command_names list or collection

command_status list
tag_name string
run_name string
file_name string
ARGUMENTS
<command_names>
[Optional] Specify the list of commands the report to be generated for. Commands can be a list of
names or collection containing them. If not specified, summary of all the commands are reported.
[Optional] Specifies the scenario name SDC report to be generated for. If -scenario is not specified, by
default, current scenario associated with design root module is considered. You can specify only one
scenario for reporting.
-status <command_status>
[Optional] This option is mutually exclusive with -all option, you must use only one option. Specify
the list of status of the SDC commands to be reported. Valid status are Succeeded, PrimaryFailed,
SecondaryFailed, Overridden, Skipped, and Unsupported. The <command_status> can be a list
containing multiple status, when specified, all the <command_names> in the specified status are
reported.
-all
[Optional] This option is mutually exclusive with -status option, you must use only one option.
Indicates that all the SDC commands specified by <command_names> to be reported regardless of
their status.
-tag_name <tag_name>
[Optional] Specify the SDC tag name where SDC commands to be taken for reporting. By default,
report is generated for the SDC commands from current <tag_name>.

-run_name <run_nme>
[Optional] Specify the <run_id> from which to generate the report. By default, report is generated for
the SDC commands from current <run_id>.
-output <file_name>
[Optional] Specify the file name for the report to be written out. If not specified, report is redirected
to standard output (i.e. report is printed to terminal).
DESCRIPTION
Command report_env allows users to report all the SDC commands stored in the current database that
are read in using read_env command or interactively added by the user. Command also provides multiple
configurations to control the details of the report. The generated report can be saved to a file with given
format, so that information can later be reviewed.
EXAMPLES
• Example-1 : Report SDC summary
prompt> report_env
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
create_derived_waveform 6 0 0 6
create_input 17 0 0 17
create_reset 1 0 0 1
create_waveform 8 0 0 8
-------------------------------------------------------------------------------
Total: 38 0 0 38
_______________________________________________________________________________
RELATED COMMANDS
read_sdc
read_env
report_sdc
RELATED VARIABLES

report_sdc
Generate a report of SDC read in.
SYNTAX
string report_sdc
[<command_names>]
[-module <module_name> | -instance <instance>]
[-status <command_status> | -all]
[-tag_name <tag_name>]
[-run_id <run_id>]
[-format <report_format>]
[-verbose]
Data Type
command_names list or collection

module_name string
instance string or collection
command_status list
tag_name string
run_id string
file_name string
ARGUMENTS
<command_names>
[Optional] Specify the list of commands the report to be generated for. Commands can be a list of
names or collection containing them. If not specified, summary of all the commands are reported.
[Optional] Specifies the scenario name SDC report to be generated for. If -scenario is not specified, by
default, current scenario associated with design root module is considered. You can specify only one
scenario for reporting.
[Optional] Specifies the <instances> SDC report to be generated for. Name of <instances> must be full
name to the instances and can either be a list of string or a collection of instances.
-status <command_status>
[Optional] This option is mutually exclusive with -all option, you must use only one option. Specify
the list of status of the SDC commands to be reported. Valid status are Succeeded, PrimaryFailed,
SecondaryFailed, Overridden, Skipped, and Unsupported. The <command_status> can be a list
containing multiple status, when specified, all the <command_names> in the specified status are
reported.
-all

[Optional] This option is mutually exclusive with -status option, you must use only one option.
Indicates that all the SDC commands specified by <command_names> to be reported regardless of
their status.
-tag_name <tag_name>
[Optional] Specify the SDC tag name where SDC commands to be taken for reporting. By default,
report is generated for the SDC commands from current <tag_name>.
-run_id <run_id>
[Optional] Specify the <run_id> from which to generate the report. By default, report is generated for
the SDC commands from current <run_id>.
-output <file_name>
[Optional] Specify the file name for the report to be written out. If not specified, report is redirected
to standard output (i.e. report is printed to terminal).
-verbose
Indicates that the report to include full details of the SDC in the specified format. If -verbose is not
specified, by default, summary of SDC commands is reported. When this option is used, if either -
status or -all is not provided, by default, SDC commands with status PrimaryFailed are reported.
Please see the examples for details of the verbose report.
DESCRIPTION
Command report_sdc allows users to report all the SDC commands stored in the current database that
are read in using read_sdc command or interactively added by the user. Command also provides multiple
configurations to control the details of the report. The generated report can be saved to a file with given
format, so that information can later be reviewed.
Option -instances can be used to generate a report of SDC commands that are read in for particular instances
(please see read_sdc command for details of how to read in SDC for particular instance or multiple instances
of a module). If given instances are not associated with any SDC, a message is printed to indicate such
scenario. Reporting SDC Commands that are applied to instances by read_sdc -module <module_name> can
also be generated using the -instance option.
EXAMPLES
• Example-1 : Report SDC summary
prompt> report_sdc
Command : report_sdc
Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
P - Partially overridden
----------------------------------------------------------------------------------
File Name Full Path
----------------------------------------------------------------------------------
func_mode_clk.sdc /home/projects/my_designs/toplevel/func_mode_clk.sdc

func_mode_exc.sdc /home/projects/my_designs/toplevel/func_mode_exc.sdc
func_mode_const.sdc /home/projects/my_designs/toplevel/func_mode_const.sdc
....
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Supported Commands Succeeded Failed(Primary) Failed(Secondary) Total
----------------------------------------------------------------------------------
get_ports 100 2 0 102
get_pins 43 2 0 45
get_cells 78 24 19 121
all_instances
....
set_case_analysis 20 5 0 25
set_clock_groups 46 32 8 86
set_false_path
set_multicycle_path
....
----------------------------------------------------------------------------------
--------------------------------
Overridden Commands Total
--------------------------------
all_fanin 12
all_fanout 2
....
--------------------------------
--------------------------------
Skipped Commands Total
--------------------------------
set_max_transition 12
set_clock_latencu 2
....
--------------------------------
--------------------------------
Unupported Commands Total
--------------------------------
all_fanin 12
all_fanout 2
....
--------------------------------
----------------------------------------------------------
Unupported Options Commands Total
----------------------------------------------------------
-critical_range group_path 3
....
----------------------------------------------------------
• Example-2 : Report SDC that are unsupported

prompt> report_sdc -status unsupported
Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
----------------------------------------------------------------------------------
File Name Full Path
----------------------------------------------------------------------------------
....
----------------------------------------------------------------------------------
--------------------------------
--------------------------------
all_fanin 12
all_fanout 2
....
--------------------------------
• Example-3 : Report SDC that are failed

prompt> report_sdc -status [list PrimaryFailed SecondaryFailed]
Command : report_sdc -status [list primaryfailed secondaryfailed]

Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
----------------------------------------------------------------------------------
File Name Full Path
----------------------------------------------------------------------------------
....
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
get_ports 100 2 0 102
get_pins 43 2 0 45

get_cells 78 24 19 121
....
....
----------------------------------------------------------------------------------
• Example-4 : Generate verbose report of SDC commands in PrimaryFailed status

prompt> report_sdc -status [list PrimaryFailed] -verbose
Date/Time : 01/14/2014 - 13:16:25
=================================================================================
Properties:
----------------------------------------------------------------------------------
File Name Full Path
----------------------------------------------------------------------------------
....
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
get_ports 100 2 0 102
get_pins 43 2 0 45
get_cells 78 24 19 121
all_instances
....
set_false_path
set_multicycle_path
....
----------------------------------------------------------------------------------
--------------------------------
Overridden Commands Total
--------------------------------
all_fanin 12
all_fanout 2
....
--------------------------------

--------------------------------
Skipped Commands Total
--------------------------------
set_max_transition 12
set_clock_latencu 2
....
--------------------------------
--------------------------------
--------------------------------
all_fanin 12
all_fanout 2
....
--------------------------------
----------------------------------------------------------
Unupported Options Commands Total
----------------------------------------------------------
-critical_range group_path 3
....
----------------------------------------------------------
RELATED COMMANDS
read_sdc
read_env
report_env
RELATED VARIABLES
None.

-output_env
The -output_env option to the read_sdc and analyze_intent commands provides SDC-to_ENV translation. The default
behavior for this SDC-to-ENV translation is to try to preserve the exact periods used in create_clock SDC-commands
when creating the corresponding create_derived_waveform commands in the ENV. The Tcl variable
ri_sdc2env_exact_translation (default true) enables this behavior.
For example, this sample SDC file creates 3 clocks and 2 generated clocks. Because there are no set_clock_groups or
set_false_path SDC commands, all clocks are treated as synchronous as per SDC semantics:
create_clock -name sys_tx_clk1 -period 1.05 [get_ports sys_tx_clk1]

create_clock -name sys_tx_clk2 -period 1.65 [get_ports sys_tx_clk2]
create_clock -name sys_rx_clk -period 1.95 [get_ports sys_rx_clk]
create_generated_clock -master_clock sys_tx_clk1 -source [get_ports sys_tx_clk1] -add -name

eth_tx_clk -divide_by 2 [get_ports eth_tx_clk]
create_generated_clock -master_clock eth_tx_clk -source [get_ports eth_tx_clk] -add -name
eth_rx_clk -divide_by 2 [get_ports eth_rx_clk]
The set of clocks is treated as synchronous in the ENV file by creating a waveform (RI_SYNC_GRP_1) whose period
(0.15) divides all the clock periods in the set. The translation uses at most 6 digits after the decimal point to find this
waveform period. Which means during conversion, SDC clock periods are truncated to 6 decimal digits. Some comments
are written into the ENV file showing how each derived_waveform period is computed. (When the -edges notation is
used in SDC, then a create_derived_waveform command in the ENV
is created with appropriate values in -edges.)
create_waveform -period 0.15 -transition { 0.000000 0.075000 } {"RI_SYNC_GRP_1"}
# period = master_period * divide_by, where

# period = 4.2
# master_period = 0.15
# divide_by = 28
create_derived_waveform -parent RI_SYNC_GRP_1 -divide_by 28 {eth_rx_clk}

# period = 2.10
# divide_by = 14
create_derived_waveform -parent RI_SYNC_GRP_1 -divide_by 14 {eth_tx_clk}

# period = 1.95
# divide_by = 13
create_derived_waveform -parent RI_SYNC_GRP_1 -divide_by 13 {sys_rx_clk}

# period = 1.05
# divide_by = 7
create_derived_waveform -parent RI_SYNC_GRP_1 -divide_by 7 {sys_tx_clk1}

# period = 2.65

# divide_by = 11
create_derived_waveform -parent RI_SYNC_GRP_1 -divide_by 11 {sys_tx_clk2}
create_clock -waveform {eth_rx_clk} { eth_rx_clk }
create_clock -waveform {eth_tx_clk} { eth_tx_clk }
create_clock -waveform {sys_rx_clk} { sys_rx_clk }
create_clock -waveform {sys_tx_clk1} { sys_tx_clk1 }
create_clock -waveform {sys_tx_clk2} { sys_tx_clk2 }
You can disable this default behavior by setting ri_sdc2env_exact_translation false.
When ri_sdc2env_exact_translation is disabled,
• SDC-to-ENV translation uses an "approximation" scheme, where all create_derived_waveform commands use -
divide_by to approximate the period relationships among the SDC clock periods.
• ri_use_exact_waveform_periods_in_sdc_to_env_translation (default false) enables translation using

"normalization".
The variable ri_sdc2env_make_all_clocks_async (default false) enables translation where all ENV derived_waveforms
are treated as asynchronous to each other.
Other Tcl variables affecting SDC-to-ENV translation are as follows:
• ri_ignore_unused_virtual_clocks (default true) causes translation to ignore unused virtual clocks. The
clocks are listed after this message: "INFO: Ignoring the following clocks which are not referenced by any
set_input_delay, set_output_delay, or create_clock commands."
• ri_sdc2env_ignore_set_false_paths (default false) causes translation to ignore all set_false_path commands

in the SDC.
• ri_sdc2env_ignore_set_clock_groups (default false) causes translation to ignore all set_clock_group

commands in the SDC.
• ri_use_logically_exclusive_as_async (default false) causes translation to interpret set_clock_groups -

logically_exclusive as set_clock_groups -asynchronous.
• ri_use_physically_exclusive_as_async (default false) causes translation to interpret set_clock_groups -

physically_exclusive as set_clock_groups -asynchronous.
• ri_use_unidir_clk2clk_sfp_as_async (default true) causes translation to interpret uni-directional

set_false_path commands (having -from or -to but not both) as defining asynchronous clocks.
• ri_write_multi_clock_waveforms (default true) causes translation to create a waveform with prefix MCLKIN
whenever multiple clocks are defined on the same design object.

RIDB Commands
You can use RIDB access commands to access RIDB objects.
You can use RIDB metadata customization commands to alter the metadata in the RIDB.

RIDB Access Commands

This Chapter describes the user accessible Objects and their Attributes in Meridian CDC. An object is a building block
of the Meridian CDC database, named RIDB, which represents various information about the design, its environment,
and verification results. An attribute is a specification that represents a property of an object which consists of a
value or set of values. Design Objects can be accessed using SDC Object Access Commands and other RIDB objects
can be accessed using RIDB Commands. Attributes of all objects can be accessed by set_attribute and get_attribute
commands.
The Object Access Commands are set of commands frequently used to access design objects and constraint objects
available in Meridian CDC. This section describes Meridian CDC supported Object Access Commands. Most of the Object
Access Commands are compatible with SDC versions, Meridian CDC also supports additional non-SDC Object Access
Commands that are frequently used.
When design or rule object access commands get executed, in addition to returning the results, it prints out the
information to the standard output. The number of elements get printed to the standard output is controlled by
variable ri_oac_result_display_limit (default is 25). User can change this variable to adjust the number of elements to
be printed to standard output.

current_scenario
Returns the current scenario name of the specification.
SYNTAX
string current_scenario
[<scenario_name>]
Data Type
ARGUMENTS
<scenario_name>
[Optional] Specify the scenario name to be set as current scenario for the design specification.
DESCRIPTION
Command current_scenario returns the current working scenario if the <scenario_name> is not specified.
The command allows users to chose one of the scenario for the analysis, from multiple scenarios users have
already created. If no <scenario_name> has been created, command returns and empty string with a message
indicating it.
EXAMPLES
• Example-1 : Retrieve the current working scenario
prompt> set cs [current_scenario]
• Example-2 : Change the scenario to read in new speceifications

prompt> create_scenario "func_mode test_mode power_mode"
prompt> foreach i [get_scenarios] {
prompt> ? current_scenario $i
prompt> ? read_env /mydesign/projects/alpha/design.env.$i
prompt> ?}
RELATED COMMANDS
create_scenario
get_scenarios
RELATED VARIABLES
None

get_all_instances
Returns a list all instances of all the specified modules.
SYNTAX
string get_all_instances
<module_names>
[-help]
Data Type
module_names string
ARGUMENTS
<module_names>
[Required] List of one or more module names of the form <module/entity> or <library>.<module/
entity> or <library>.<entity>.<architecture>.
-help
EXAMPLES
• Example-1 : Access all the instances of module my_design in Verilog
prompt> set pd [get_all_instances my_design]
• Example-2 : Access all the instances of entity my_design in VHDL work library
prompt> set pd [get_all_instances work.my_design]
RELATED COMMANDS
get_all_modules
RELATED VARIABLES
None

get_all_modules
Returns a list of unique paramerized module name of a reference module (in Verilog) or an entity (in VHDL).
SYNTAX
string get_all_modules
<ref_design_name>
Data Type
ref_design_name string
ARGUMENTS
<ref_design_name>
[Required] Specify reference design name to access all of its unique parameterized designs in the
design db.
DESCRIPTION
Command get_all_modules returns a list of design unique parameterized design names in the current
elaborated design database. The command returns an empty list if the design has not been parameterized or
it has not be used with a message indicating it. The <ref_design_name> can be specified as <module/entity>
name or <library>.<module/entity> for both Verilog/VHDL and <library>.<entity>.<architecture> for VHDL.
Note that wild cards are not supported and full base name of the ref_design_name has to be provided.
The unique parameterized design names are created based upon parameter values. For a simple case, the
format is <mod_name>-<val>-<val>...., the param values are shown by order, the last one is the last param
with non-default value. e.g. if a module has 5 params, only the third param value changed, module name will
be mod-0-1-8, where 8 is the new value for the third param. The rest params won't be shown in name. For
example consider a module m1 with params p1 (default value = 1), p2 (default value = 1), p3 (default value =
1), p4 (default value = 1), p5 (default value = 1),
• Instantiation with parameter values p1 =1, p2 =1, p3 =1, p4=1, p5=1, will be named m-1
• Instantiation with parameter values p1 =2, p2 =1, p3 =1, p4=1, p5=1, will be named m-1-1
• Instantiation with parameter values p1 =1, p2 =2, p3 =1, p4=1, p5=1, will be named m-1-2
• Instantiation with parameter values p1 =1, p2 =1, p3 =1, p4=1, p5=2, will be named m-1-1-1-1-2
• Instantiation with parameter values p1 =1, p2 =2, p3 =2, p4=1, p5=1, will be named m-1-2-2
Differences between get_designs and get_all_modules command

• get_all_modules returns all parametrizations of a given module name (wildcards not allowed) in a Tcl
list matching Real Intent specific parameterized module names.
• get_designs returns all modules, including parameterizations, matching a pattern in an OAC
collection in SDC format
• As get_designs output is a Collection, it must be treated appropriately (i.e. if you need to add to it,
use append_to_collection)
• Output of get_designs and get_all_modules can differ as get_designs uses SDC design names whereas
get_all_modules follows Real Intent specific parameterized module names.

• If the full base name of a reference design name is known, use get_all_modules. If the full base
name is not known and wildcards are required use get_designs command.
• If you need a tcl list which can be provided to Real Intent commands (for example
set_shell_instances), use get_all_modules command.
• If you need a collection, use get_designs
EXAMPLES
• Example-1 : Access all the parameterized designs of a module name my_design in Verilog
prompt> set pd [get_all_modules my_design]
• Example-2 : Access all the parameterized designs of an entity name my_design in VHDL work library
prompt> set pd [get_all_modules work.my_design]
RELATED COMMANDS
get_designs
RELATED VARIABLES
None

get_rule_contents
Returns a collection of rule content objects.
SYNTAX
collection get_rule_contents
[<patterns> | -of_objects <objects>]
[-filter <expression>] | [-view_criteria <vcname>]
[-regexp] | [-nocase]
[-quiet]
Data Type
patterns string
objects collection
expression string
vcname string or collection
ARGUMENTS
<patterns>
[Optional] <pattern> and -of_objects options are mutually exclusive, you must use only one. Specifies
the <patterns> to match against the rule content objects. The <patterns> can include wildcard
characters such as * (asterisk) and ? (question mark) or regular expressions when use with -regexp. If
<patterns> is not given, * is used as a default <patterns> for the search.
-of_objects <objects>
[Optional] -of_objects and <patterns> options are mutually exclusive, you must use only one. Specifies
collection of rule data, rule instance, rule group, or rule policy objects for rule content objects to be
searched. The <objects> can be a homogeneous or heterogeneous collection that includes any of the
aforementioned rule objects.
-filter <expression>
[Optional] -filter and -of_objects options are mutually exclusive, you must use only one. Specifies the
<expression> for the matching criteria. The <expression> is evaluated based on the attribute of the
object (see rule content attributes for details), The object is included in the return collection if the
<expression> is evaluated to true (see the filter_collection for details of <expression>).
-regexp
[Optional] -regexp and -nocase options are mutually exclusive, you must use only one. Indicates that
the <patterns> and <expression> provided to be treated as regular expressions when searching rule
objects in the RIDB.
-nocase
[Optional] -nocase and -regexp options are mutually exclusive, you must use only one. Indicates that
the <patterns> and <expression> provided to be treated as case insensitive manner.
-quiet
[Optional] Indicates that warning or information messages to be suppressed if no objects were
matched for the given criteria and return an empty collection.

DESCRIPTION
Command get_rule_contents returns a collection of rule content objects in the RIDB that matches the criteria
given to the command. If -filter is provided, rule content attributes that used in the <expression> evaluate to
true are included in the returned collection, if no objects matches the criteria, empty collection is returned.
The returned collection is a named handle that holds the list of objects.
If <patterns> or -of_objects is not used, command uses * (asterisk) as the default <patterns> for the search
in RIDB. The <patterns> can be a regular expression when use with -regexp option, which is compatible with
Tcl regular expression matching.
EXAMPLES
• Example-1 : Queries a specific rule content objects in the S_NOCLK rule data object ID of 4
prompt> set rcntnt [get_rule_contents *S_NOCLK/4/*]
• Example-2 : Queries all the rule content objects from a rule data object, using the same example above;
prompt> set rdata [get_rule_data *S_NOCLK/4]
prompt> set rcntnt [get_rule_contents -of_objects ${rdata}]
• Example-3 : Queries rule content objects based on the attributes

prompt> set rcntnt [get_rule_contents -fitler {(rule_instance =~ S_NOCLK) && (Signal
=~ a.b.c.d)}]
RELATED COMMANDS
get_rule_policies
get_rule_groups
get_rule_instances
get_rule_data
filter_collection
query_objects
RELATED VARIABLES
ri_oac_result_display_limit

get_rule_data
Returns a collection of rule data objects.
SYNTAX
collection get_rule_data
[-filter <expression>] | [-view_criteria <vcname>]
[-regexp] | [-nocase]
[-quiet]
Data Type
patterns string
objects collection
expression string
vcname string or collection
ARGUMENTS
<patterns>
the <patterns> to match against the rule data objects. The <patterns> can include wildcard characters
such as * (asterisk) and ? (question mark) or regular expressions when use with -regexp. If <patterns>
is not given, * is used as a default <patterns> for the search.
collection of rule contents, rule instance, rule group, or rule policy objects for rule data objects to be
searched. The <objects> can be a homogeneous or heterogeneous collection that includes any of the
aforementioned rule objects.
[Optional] -filter and -view_criteria options are mutually exclusive, you must use only one. Specifies
the <expression> for the matching criteria. The <expression> is evaluated based on the attribute of
the object (see rule content attributes for details), The object is included in the return collection if
the <expression> is evaluated to true
-view_criteria <vcname>
[Optional] -view_criteria and -filter options are mutually exclusive, you must use only one. Specify the
name of list of <vcname>s to be used for the search. The <vcname> can either be a collection or list of
view criteria names.
-regexp
[Optional] -regexp and -nocase options are mutually exclusive, you must use only one. Indicates that
the <patterns> and <expression> provided to be treated as regular expressions when searching rule
objects in the RIDB.
-nocase
[Optional] -nocase and -regexp options are mutually exclusive, you must use only one. Indicates that
the <patterns> and <expression> provided to be treated as case insensitive manner.

-quiet
Indicates that warning or information messages to be suppressed if no objects were matched for the
given criteria and return an empty collection.
DESCRIPTION
Command get_rule_data returns a collection of rule data objects in the RIDB that matches the criteria given
to the command. If -filter is provided, rule data attributes that used in the <expression> evaluate to true
are included in the returned collection, if no objects matches the criteria, empty collection is returned with a
message indicate such unmatch scenario. Use -quiet option to suppress the message if desired. The returned
collection is a named handle that holds the list of objects.
in RIDB. The <patterns> can be a regular expression when use with -regexp option, which is compatible with
Tcl regular expression matching.
The -view_criteria option facilitates the searching rule data objects without applying to a specific rule policy,
rule group, or rule instance. Users can create new view criteria on demand and pass them to get_rule_data
command to isolate specific problem.
EXAMPLES
• Example-1 : Queries rule data objects in the S_NOCLK rule instances
prompt> set rd [get_rule_data *S_NOCLK*]
• Example-2 : Queries all the rule data objects that are not ins SignedOff or PreSignedOff status
prompt> set rd [get_rule_data -filter {status =~ *SignedOff}]
• Example-3 : Queries rule data objects based with view_criteria applied to

prompt> set rcntnt [get_rule_data -fitler {sizeof(view_criteria) > 0}]
RELATED COMMANDS
get_rule_policies
get_rule_groups
get_rule_instances
get_rule_contents
filter_collection
query_objects
RELATED VARIABLES

get_rule_groups
Returns a collection of rule group objects.
SYNTAX
collection get_rule_groups
[<patterns>]
[-filter <expression>]
[-nocase]
[-quiet]
Data Type
patterns string
expression string
ARGUMENTS
<patterns>
[Optional] Specifies the <patterns> to match against the rule group objects. The <patterns> can
include wildcard characters such as * (asterisk) and ? (question mark). If <patterns> is not given, * is
used as a default <patterns> for the search.
[Optional] Specifies the <expression> for the matching criteria. The <expression> is evaluated based
on the attribute of the object (see rule group attributes for details), The object is included in the
returned collection if the <expression> is evaluated to true (see the filter_collection for details of
<expression>).
-nocase
[Optional] Indicates that the <patterns> and <expression> provided to be treated as case insensitive
manner.
-quiet
DESCRIPTION
Command get_rule_groups returns a collection of rule group objects in the RIDB that matches the criteria
given to the command. If -filter is provided, rule group attributes that used in the <expression> evaluate to
true are included in the returned collection, if no objects matches the criteria, empty collection is returned
with a message by default, however, message can be suppressed with -quiet option. The returned collection is
a named handle that holds the list of group objects.
EXAMPLES
• Example-1 : Queries all the rule groups in the current session
prompt> set rg [get_rule_groups]
• Example-2 : Queries the rule groups that includes *ERROR* in its name

prompt> set rg [get_rule_groups *ERROR*]
• Example-3 : Queries rule groups that have view_criteria attached

prompt> set rg [get_rule_groups -fitler {sizeof(view_criteria) > 0}]
RELATED COMMANDS
create_rule_policy
create_rule_group
filter_collection
query_objects
RELATED VARIABLES

get_rule_instances
Returns a collection of rule instance objects.
SYNTAX
collection get_rule_instances
[<patterns>]
[-nocase]
[-quiet]
Data Type
patterns string
expression string
ARGUMENTS
<patterns>
[Optional] Specifies the <patterns> to match against the rule policy objects. The <patterns> can
on the attribute of the object (see rule instance attributes for details), The object is included in the
<expression>).
-nocase
manner.
-quiet
DESCRIPTION
Command get_rule_instances returns a collection of rule policy objects in the RIDB that matches the criteria
given to the command. If -filter is provided, rule policy attributes that makes up the <expression> evaluates
to true are included in the returned collection, if no objects matches the criteria, empty collection is returned
a named handle that holds the list of policy objects.
EXAMPLES
• Example-1 : Queries all the rule instances in the current session
prompt> set ri [get_rule_instances]
• Example-2 : Queries the rule instances that includes *DATA* it its name

prompt> set ri [get_rule_instances *DATA*]
• Example-3 : Queries rule instances that have view_criteria attached

prompt> set ri [get_rule_instances -fitler {sizeof(view_criteria) > 0}]
RELATED COMMANDS
create_rule_policy
create_rule_group
filter_collection
query_objects
RELATED VARIABLES

get_rule_policies
Returns a collection of rule policy objects.
SYNTAX
collection get_rule_policies
[<patterns>]
[-nocase]
[-quiet]
Data Type
patterns string
expression string
ARGUMENTS
<patterns>
[Optional] Specifies the <patterns> to match against the rule policy objects. The <patterns> can
on the attribute of the object (see rule policy attributes for details), The object is included in the
<expression>).
-nocase
manner.
-quiet
DESCRIPTION
Command get_rule_policies returns a collection of rule policy objects in the RIDB that matches the criteria
given to the command. If -filter is provided, rule policy attributes that used in the <expression> evaluate to
true are included in the returned collection, if no objects matches the criteria, empty collection is returned
a named handle that holds the list of policy objects.
EXAMPLES
• Example-1 : Queries all the rule policies in the current session
prompt> set rp [get_rule_policies]
• Example-2 : Queries the rule policy that includes *ANALYSYS* it its name

prompt> set rp [get_rule_policies *ANALYSIS*]
• Example-3 : Queries rule policies that have view_criteria attached

prompt> set rp [get_rule_policies -fitler {sizeof(view_criteria) > 0}]
RELATED COMMANDS
create_rule_policy
filter_collection
query_objects
RELATED VARIABLES

get_rules
Returns a collection of rule objects.
SYNTAX
collection get_rules
[-nocase]
[-quiet]
Data Type
patterns string
objects collection
expression string
ARGUMENTS
<patterns>
the <patterns> to match against the rule objects. The <patterns> can include wildcard characters such
as * (asterisk) and ? (question mark). If <patterns> is not given, * is used as a default <patterns> for
the search.
collection of rule content, rule data, rule instance, rule group, or rule policy objects for rule content
objects to be searched. The <objects> can be a homogeneous or heterogeneous collection that
includes any of the aforementioned rule objects.
[Optional] Specifies the <expression> for the matching criteria. The <expression> is evaluated
based on the attribute of the object (see rule attributes for details), The object is included in the
<expression>).
-nocase
manner.
-quiet
DESCRIPTION
Command get_rules returns a collection of rule objects in Meridian CDC that matches the criteria given to
the command. If -filter option is provided, rule attributes that used in the <expression> evaluate to true are
included in the returned collection, if no objects matches the criteria, empty collection is returned with a
message. The returned collection is a named handle that holds the list of objects.

If <patterns> or -of_objects is not used, command uses * (asterisk) as the default <patterns> to search the
rules in Meridian CDC. The <patterns> can be a regular expression when use with -regexp option, which is
compatible with Tcl regular expression matching. The -of_objects can be used to access the set of rules that
are used in set of rule_instances, rule_groups, or rule_policies or from rule_data or ruel_content objects to
find out which rule objects they have been generated from.
EXAMPLES
• Example-1 : Queries rules with W_ in the name
prompt> set myrules [get_rules W_*]
RELATED COMMANDS
get_rule_policies
get_rule_groups
get_rule_instances
get_rule_data
get_rule_contents
filter_collection
query_objects
RELATED VARIABLES

get_run_names
Returns
a
list
of
all
run
names
in
the
RIDB.
SYNTAX
collection
get_run_names
[-
filter
<expression>]
[-
help]
ARGUMENTS
-
filter
<expression>
[Optional]
Specifies
the
<expression>
for
the
matching
criteria.
The
object
is
included
in
the
return
collection
if
the
<expression>
is
evaluated
to
true
(see
the

filter_collection
for
details
of
<expression>).
-
help
[Optional]
Displays
help
text
for
this
command.
DESCRIPTION
Returns
a
list
of
all
run
names
in
the
RIDB.
You
can
provide
a
regular
expression
to
filter
the
run
names.
EXAMPLES
• Example-1 :
prompt>
get_run_names
RELATED
COMMANDS
RELATED
VARIABLES


get_scenarios
Returns a list of scenarios in the current session.
SYNTAX
string get_scenarios
ARGUMENTS
None
DESCRIPTION
Command get_scenarios returns the existing scenarios in the current working session. The command returns
and empty list if no scenarios has been created with a message indicating it.
EXAMPLES
• Example-1 : Access Change the scenario to read in new speceifications
prompt> create_scenario "func_mode test_mode power_mode"
prompt> foreach i [get_scenarios] {
prompt> ? current_scenario $i
prompt> ? read_env /mydesign/projects/alpha/design.env.$i
prompt> ?}
RELATED COMMANDS
create_scenario
current_scenario
RELATED VARIABLES
None

get_view_criteria
Returns a collection of view criterias.
SYNTAX
collection get_view_criteria
[<patterns> ]
Data Type
patterns string
objects collection
expression string
ARGUMENTS
<patterns>
Specifies the <patterns> to match against the view criterias. The <patterns> can include wildcard
characters such as * (asterisk) and ? (question mark). If <patterns> is not given, * is used as a default
<patterns> for the search.
[Optional] Specifies the <expression> for the matching criteria. The object is included in the
<expression>).
DESCRIPTION
Command get_view_criteria returns the existing view criterias in the current working session.
EXAMPLES
• Example-1 : Access Change the scenario to read in new speceifications
prompt> get_view_criteria
RELATED COMMANDS
RELATED VARIABLES
None

RIDB Metadata Customization Commands

To use RIDB metadata commands, put them in a file called custom_factory_db_override.tcl in the
<installation_directory>/release/RealIntent/Meridian/CDC/dbs/ directory. Meridian CDC will source this file to edit the
metadata prior to starting the engine run.
Note: Metadata commands are of the form <action>_<object>_<attribute>. For example, set_rule_policy_is_factory
sets the isFactory attribute for a rule policy. "set" is the <action>, "rule_policy" is the <object>, and "is_factory" is the
<attribute>.

attach_view_criteria
Attaches view criteria to a rule instance.
SYNTAX
attach_view_criteria -ruleinstance <ruleinstancename> -viewcriteria <viewcriterianame>
ARGUMENTS
-ruleinstance <ruleinstancename>
Specifies the rule instance to which you want to attach the named view criteria.
-viewcriteria <viewcriterianame>
Specifies the view criteria you want to attach to the named rule instance.
DESCRIPTION
Use the attach_view_criteria command to attach view criteria to a rule instance.
EXAMPLES
• Example-1 : Attach view criteria to a rule instance
attach_view_criteria -viewcriteria lvc_New_INVALID_ARG_USAGE -ruleinstance New/
SDC_ENV_LINT/ERROR/INVALID_ARG_USAGE
RELATED COMMANDS
RELATED VARIABLES
None

set_rule_group_is_factory
Sets the isFactory (factory internal) attribute for a rule group.
SYNTAX
set_rule_group_is_factory -rulegroup <rulegroupname>
ARGUMENTS
-rulegroup <rulegroupname>
Sets the isFactory attribute for the named rule group.
DESCRIPTION
Use the set_rule_group_is_factory command to set the isFactory attribute for one or more named rule groups.
Use one command per affected rule group.
EXAMPLES
• Example-1 : Set the isFactory attribute for the named rule group
set_rule_group_is_factory -rulegroup PARENT/CUSTOM_GROUP
RELATED COMMANDS
RELATED VARIABLES
None

set_rule_instance_is_factory
Sets the isFactory (factory internal) attribute for a rule instance.
SYNTAX
set_rule_instance_is_factory -ruleinstance <ruleinstancename>
ARGUMENTS
-ruleinstance <ruleinstancename>
Unsets the isFactory rule policy attribute for the named rule policy.
DESCRIPTION
Use the set_rule_instance_is_factory command to set the isFactory attribute for one or more named rule
instances. Use one command per affected rule instance.
EXAMPLES
• Example-1 : Set the isFactory attribute for the named rule instance
set_rule_instance_is_factory -ruleinstance New/SDC_ENV_LINT/ERROR/INVALID_ARG_USAGE
RELATED COMMANDS
RELATED VARIABLES
None

set_rule_policy_default_flag
Sets the default flag attribute for a rule policy.
SYNTAX
set_rule_policy_default_flag -policy <policyname>
ARGUMENTS
-policy <policyname>
Sets the default flag attribute for the named rule policy.
DESCRIPTION
Use the set_rule_policy_default_flag command to set the default flag attribute for one or more named rule
policies. Use one command per affected attribute.
EXAMPLES
• Example-1 : Set the default flag attribute for the named rule policies
set_rule_policy_default_flag -policy New
set_rule_policy_default_flag -policy Fix
set_rule_policy_default_flag -policy Defer
set_rule_policy_default_flag -policy Waive
RELATED COMMANDS
RELATED VARIABLES
None

set_rule_policy_is_factory
Sets the isFactory (factory internal) attribute for a rule policy.
SYNTAX
set_rule_policy_is_factory -policy <policyname>
ARGUMENTS
Sets the isFactory rule policy attribute for the named rule policy.
DESCRIPTION
Use the set_rule_policy_is_factory command to set the isFactory attribute for one or more named rule
policies. Use one command per affected rule policy
EXAMPLES
• Example-1 : Set the isFactory attribute for the named rule policies
set_rule_policy_is_factory -policy New
set_rule_policy_is_factory -policy Fix
set_rule_policy_is_factory -policy Defer
set_rule_policy_is_factory -policy Waive
RELATED COMMANDS
RELATED VARIABLES
None

set_rule_policy_order
Sets the order attribute for a rule policy.
SYNTAX
set_rule_policy_order -policy <policyname> -order <order>
ARGUMENTS
Specifies the rule policy whose order attribute you want to set.
-order <order>
Specifies the value for the order attribute.
DESCRIPTION
Use the set_rule_policy_order command to set the order attribute for one or more named rule policies. Use
one command for each affected rule policy.
EXAMPLES
• Example-1 : Set the order attribute for the named rule policies
set_rule_policy_order -policy New -order 10
set_rule_policy_order -policy Fix -order 11
set_rule_policy_order -policy Defer -order 12
set_rule_policy_order -policy Waive -order 13
RELATED COMMANDS
RELATED VARIABLES
None

set_status_is_default
Sets the isDefault attribute for status.
SYNTAX
set_status_is_default -status <statusname>
ARGUMENTS
-status <statusname>
Sets the isDefault attribute for the specified status.
DESCRIPTION
Use the set_status_is_default command to set the isDefault attribute for the named status.
EXAMPLES
• Example-1 : Set the isDefault attribute for status New
set_status_is_default -status New
RELATED COMMANDS
RELATED VARIABLES
None

set_status_is_factory
Sets the isFactory (factory internal) attribute for the names status.
SYNTAX
set_status_is_factory -status <statusname>
ARGUMENTS
Specifies the status whose isFactory attribute you want to set.
DESCRIPTION
Use the set_status_is_factory command to set the isFactory attribute for one or more named status object.
Use one command per affected status object.
EXAMPLES
• Example-1 :
set_status_is_factory -status New
set_status_is_factory -status Fix
set_status_is_factory -status Defer
set_status_is_factory -status Waive
RELATED COMMANDS
RELATED VARIABLES
None

set_view_criteria_is_factory
Sets the isFactory (factory internal) attribute for a view criteria object.
SYNTAX
set_view_criteria_is_factory -viewcriteria <viewcriterianame>
ARGUMENTS
-viewcriteria <viewcriterianame>
Sets the isFactory attribute for the named view criteria object.
DESCRIPTION
Use the set_view_criteria_is_factory command to set the isFactory attribute for one or more named view
criteria. Use one command per affected view criteria object.
EXAMPLES
• Example-1 : Set the isFactory attribute for the named view criteria object
set_view_criteria_is_factory -viewcriteria lvc_New_INVALID_ARG_USAGE
RELATED COMMANDS
RELATED VARIABLES
None

unset_rule_policy_is_factory
Unsets the isFactory (factory internal) attribute for a rule policy.
SYNTAX
unset_rule_policy_is_factory –all | -policy <policyname>
ARGUMENTS
-all
Unsets the isFactory rule policy attribute for all rule policies.
Unsets the isFactory rule policy attribute for the named rule policy.
DESCRIPTION
Use the unset_rule_policy_is_factory command to unset the isFactory attribute for one or more named rule
policies, or for all rule policies. Use one command per affected rule policy.
EXAMPLES
• Example-1 : Unset the isFactory attribute for all policies
unset_rule_policy_is_factory -all
RELATED COMMANDS
RELATED VARIABLES
None

unset_rule_policy_tool
Removes a rule policy from the list of policies.
SYNTAX
unset_rule_policy_tool -policy <policyname>
ARGUMENTS
Specifies the rule policy you want to remove from the list.
DESCRIPTION
Use the unset_rule_policy_tool command to remove one or more named rule policies from the list of policies.
Use one command per affected rule policy.
EXAMPLES
• Example-1 : Remove the named policies from the policy tree
unset_rule_policy_tool -policy SDC_ENV_LINT
unset_rule_policy_tool -policy MCDC_SETUP_CHECKS
unset_rule_policy_tool -policy MCDC_ANALYSIS_CHECKS
RELATED COMMANDS
RELATED VARIABLES
None

unset_status_tool
Removes the named status specifier from the list.
SYNTAX
unset_status_tool -status <statusname>
ARGUMENTS
Specifies the status you want to remove from the list.
DESCRIPTION
Use the unset_status_tool command to remove one or more named status specifiers from the list. Use one
command for each status specifier.
EXAMPLES
• Example-1 :
unset_status_tool -status ToBeReviewed
unset_status_tool -status Assigned
unset_status_tool -status Critical
unset_status_tool -status Primary
unset_status_tool -status Secondary
unset_status_tool -status SignedOff
unset_status_tool -status PreSignedOff
RELATED COMMANDS
RELATED VARIABLES
None

SDC Commands
The Synopsys Design Constraints (SDC commands) commands for defining timing requirements for the design. SDC
commands can be used to define the waveforms, clocks, constants, and boundary waveform associations under which
the design is analyzed or verified. The set of SDC commands that can be used to define the design environment are
described in this chapter. SDC specification commands are also available directly from interactive CLI. SDC commands
are generally written in a separate file and are accepted only by read_sdc command.

Collection Commands
Collection represents the group of objects, they are created when user access RIDB objects. Collection is not a Tcl
list, therefore native Tcl functions that process lists cannot operate directly on collections. This section describes list
of collection commands that are provided to process and manipulate collections, these commands are often used to
process objects queried by SDC Object Access Commands and RIDB Commands.
• Homogeneous and Heterogeneous collections

A collection can be made of different type of RIDB objects. When a collection contains only one type of object
class, it refers to as a homogeneous collection and when it contains more than one type of object class, it
refers to as a heterogeneous collection. Command that operates on collection handles both homogeneous
and heterogeneous collections but returned values could be different. Please refer to each command section
for the details on each command operates when homogeneous and heterogeneous collections are given as an
input.

add_to_collection
Add objects to a existing collection, results is a new collection, existing collection remains unchanged.
SYNTAX
collection add_to_collection
[-unique]
<base_collection>
<objects_tobe_added>
Data Type
base_collection collection
objects_tobe_added list or collection
ARGUMENTS
-unique
[Optional] Indicates that duplicate objects to be removed from the returned collection. By default,
meaning absence of this option, makes returned collection to include duplicates if based collection
already contains objects that are also in <objects_tobe_added>.
<base_collection>
[Required] Specifies the <base_collection> to which <objects_tobe_added> to be added. The returned
collection includes both <base_collection> and <objects_tobe_added>. The <base_collection> can be
an empty collection (or empty string).
<objects_tobe_added>
[Required] Specifies a list of named objects or collections to be added to <base_collection>. If the
<base_collection> is heterogeneous, <objects_tobe_added> must be a collection (meaning that named
objects are not allowed).
DESCRIPTION
The add_to_collection creates a new collection by adding a list of element names or collections to a base
collection, returning a new collection while <base_collection> remains unchanged. The same objects
that exist in both the <base_collection> and the <objects_tobe_added> are in the returned collection
unless -unique option is specified. The <base_collection> can be an empty collection (or an empty string).
If the <objects_tobe_added> is an empty collection, new collection is created which is identical to
<base_collection>.
If the <base_collection> is homogeneous, the implicit objects in <objects_tobe_added> must be same as

that of in the <base_collection>, and are searched using object class of <base_collection>. All implicit
objects in the <objects_tobe_added> are ignored if the base collection is heterogeneous.
If the <base_collection> is an empty collection, object class for the implicit objects is determined
by first homogeneous objects in the <objects_tobe_added> collection. All the implicit objects in the
<objects_tobe_added> are ignored if object class cannot be determined.
EXAMPLES

• Example-1 : The following example queries all clocks in the design beginning with 'clk' and then adds clock
'CLOCK' to the collection.
prompt> set allclks [get_clocks clk*]
prompt> set newallclks [add_to_collection ${allclks} [get_clocks CLOCK]]
• Example-2 : The following example queries all clocks in the design beginning with 'clk' and then adds clock
'clkA' to the collection. To avoid duplication, use -unique option.
prompt> set newallclks [add_to_collection -unique ${allclks} clkA]
• Example-3 : The following example queries all pins in the design and adds clock 'CLOCK' to the pin collection.
prompt> set allpins [get_pins *]
prompt> set allclks [get_clocks CLOCK]
prompt> set allelements [add_to_collection ${allpins} ${allclks}]
• Example-4 : The following example considers <objects_tobe_added> to be empty.

prompt> set allports [get_ports in*]
prompt> set allclks ""
prompt> set allelements [add_to_collection ${allports} ${allclks}]
RELATED RULE CHECKS

None.
RELATED COMMANDS
append_to_collection
remove_from_collection
query_objects
RELATED VARIABLES
None

Appends a set of objects (named objects or collection) to an existing collection, the existing collection is modified
directly.
SYNTAX
collection append_to_collection
[-unique]
<base_collection_name>
<objects_tobe_appended>
Data Type
base_collection_name string
objects_tobe_appended list or collection
ARGUMENTS
-unique
Allows removal of duplicate objects from the resulting collection. By default, duplicate objects are
not removed.
<base_collection>
Specifies collection to which the objects listed in <objects_tobe_apended> to be appended. Duplicate
objects are removed from the resulting collection if -unique is specified.
<objects_tobe_appended>
Specifies a list of named objects or collections to be appended to the <base_collection>.
DESCRIPTION
The append_to_collection appends a set of named objects or collection to an existing collection. The
<base_collection_name> is appended with <object_tobe_appended> and is modified directly. The same
objects that exist in both the <base_collection_name> and the <objects_tobe_appended> are kept unless -
unique option is specified. The <base_collection_name> can be an empty collection (or an empty string).
If the <base_collection_name> contains homogeneous collection, the implicit objects in

<objects_tobe_appended> must be same as that of in the <base_collection_name>, and are searched using
object class of <base_collection_name>. All implicit objects in the <objects_tobe_appneded> are ignored if
the <base_collection_name> hold heterogeneous collection.
If the <base_collection_name> is an empty collection, object class for the implicit objects is determined
by first homogeneous objects in the <objects_tobe_appended> collection. All the implicit objects in the
<objects_tobe_appended> are ignored if object class cannot be determined.
EXAMPLES
• Example-1 : The following example illustrates how to build up a collection by using append_to_collection
command.
prompt> set allports [get_ports in*]

prompt> ? append_to_collection allports [get_ports out*]
• Example-2 : The following example illustrates the case when the duplication of objects is avoided using -
unique option.
prompt> set allports [all_inputs]
prompt> ? append_to_collection -unique allports [all_outputs]
• Example-3 : The following example illustrates the case when <base_collection_name> is an empty collection
and <collection_tobe_appended> does not contain a collection which results in an error
prompt> set allports ""
prompt> append_to_collection allports [list clk clr]
RELATED RULE CHECKS

None.
RELATED COMMANDS
add_to_collection
query_objects
RELATED VARIABLES
None

collection_contains
Inspects a collection and identifies if it contains the specified object.
SYNTAX
int collection_contains
<base_collection>
<object_tobe_searched>
Data Type
objects_tobe_searched list or collection
ARGUMENTS
<base_collection>
[Required] Specifies the collection in which the object to be searched.
<objects_tobe_searched>
[Required] Specifies the object name to be searched in the collection.
DESCRIPTION
The collection_contains command inspects collection given by <base_collection> and identifies if it contains
the <objects_tobe_searched> for in the collection. When the <objects_tobe_searched> are found in
the <base_collection>, command returns an integer 1, if <objects_tobe_searched> do not exist in the
<base_collection> then the command returns integer 0.
EXAMPLES
• Example-1 : The following example illustrates
prompt> set mycoll [get_clocks {clkA clkB}]
prompt> collection_contains ${mycoll} clkA
• Example-2 : Using collection_contains in the if-else

prompt> set foo ""
prompt> append_to_collection foo [get_ports]
prompt> if {[collection_contains $foo clr]} then {
prompt> ? ## do something when object is in the list
prompt> ? } else {
prompt> ? ## do something when object is not found
prompt> ? }
RELATED RULE CHECKS

None.
RELATED COMMANDS

add_to_collection
index_collection
query_objects
RELATED VARIABLES
None

compare_collections
Compares two object collections.
SYNTAX
int compare_collections
[-order_dependent]
<base_collection>
<collection_tobe_compared>
Data Type
collection_tbe_compared collection
ARGUMENTS
-order_dependent
[Optional] Indicates that the order of objects in the two collections has to be taken into consideration
when comparing two collections.
<base_collection>
[Required] Specifies the base collection for comparison. The <base_collection> can be an empty
collection.
<collection_tobe_compared>
[Required] Specifies the collection which to be compared against <base_collection>.
<collection_tobe_compared> can also be an empty collection.
DESCRIPTION
The compare_collections command compares the contents between two collections <base_collection> and
<collection_tobe_compared>. With the -order_dependent option, the order in which objects appear in two
collections is considered for comparison. When the two collections have the same objects, command returns
an integer 0, if the collections have differences then the non-zero integer is returned. It is legal to have
empty collections, comparison of two empty collections also returns "0" indicating that the two collections are
identical.
EXAMPLES
• Example-1 : The following example illustrates the comparison of two collections.
prompt> set collection1 [get_clocks]
prompt> set collection2 [all_clocks]
prompt> compare_collections $collection1 $collection2
• Example-2 : The following example illustrates order dependent comparison of collections.

prompt> set collection1 [all_input]
prompt> set collection2 [get_ports -filter {port_direction == in || port_direction ==
inout}]
prompt> compare_collections $collection1 $collection2 -order_dependent

RELATED RULE CHECKS

None.
RELATED COMMANDS
Collection Commands
SDC Commands
RIDB Commands
RELATED VARIABLES
None

copy_collection
Creates
a
new
collection
by
duplicating
the
contents
of
the
base
collection.
The
base
collection
remains
unchanged.
SYNTAX
collection
copy_collection
<base_collection>
Data
Type
base_collection
collection
ARGUMENTS
<base_collection>
[Required]
Specifies
the
collection
to
be
copied.
<base_collection>
can
be
an
empty.
An
empty
collection
returned
for
an

empty
<base_collection>.
DESCRIPTION
The
copy_collection
command
is
a
convinient
way
to
create
a
copy
of
an
existing
<base_collection>
collection.
EXAMPLES
• Example-1 :
The
following
example
illustrates
the
comparison
of
collections.
prompt>
set
clks
[get_clocks
clk*]
prompt>
set
copy_clks
[copy_collection
$clks]
RELATED
RULE
CHECKS
None.
RELATED
COMMANDS

add_to_collection
query_objects
RELATED
VARIABLES
None.

filter_collection
Apply a filtering on an existing collection, result is a new collection.
SYNTAX
collection filter_collection
[-regexp [-nocase]]
<base_collection>
<expression>
Data Type
expression string
ARGUMENTS
-regexp
[Optional] Indicates that pattern matching operators to use Tcl regular expressions.
-nocase
[Optional] Valid only with -regexp option. Indicates that regular expression matching to be done in
case-insensitive manner.
<base_collection>
[Required] Specifies the collection to be filtered, the result collection is a filtered copy of the
<base_collection>.
<expression>
[Required] Specifies the expression to be used to filter the <base_collection>.
DESCRIPTION
The filter_collection command performs filtering on an existing collection <base_collection>, returns a
new collection with sub set of objects from <base_collection> if the <expression> evaluates to true with
some objects or an empty string if the <expression> evaluates to false with all the objects or same as
<base_collection> if the <expression> evaluates to true with all the objects in <base_collection>.
Command performs filtering based on the attribute of the objects in <base_collection>, an <expression> can
be constructed using relational operators (see the table below) together with AND(&&)/OR(||) operators and
parentheses. Below is set of relational operators currently supported and can be used in the <expression>.
Attribute Type
Operator Description
String Numeric Boolean
== Equal Y Y Y
!= Not equal Y Y Y
> Greater than Y Y N
< Less than Y Y N
>= Greater than or equal to Y Y N

<= Less than or equal to Y Y N

=~ Matches the pattern Y N N
!~ Does not match the pattern Y N N
Following is a list of predefined operators that can be used together with relational operators in the
<expression>. These predefined operators can be applied to any attribute in the <base_collection>.
• defined(<attribute_name>) - check existence of <attribute_name>
• undefined(<attribute_name>) - check non-existence of <attribute_name>
• !defined(<attribute_name>) - Check non-existence of <attribute_name>
• sizeof(<attribute_name>) - Return number of objects in the <attribute_name>, if the attribute is
not defined returns 0 (zero)
Using -regexp option instructs the command to use regular expressions for pattern matching, -nocase indicates
pattern matching to be performed in case-insensitive manner. Meridian CDC follows standard Tcl regular
expression semantics when -regexp is given. By default, pattern matching operators such as =~ and !~ support
simple wildcard pattern matching with * (asterisk) and ? (question mark).
When an attribute holds a singleton collection object as its value, any attribute of that singleton collection
object can be accessed using "." (dot) to specify the attribute name. See EXAMPLE section for more details.
EXAMPLES
• Example-1 : Accessing only hierarchical cells
prompt> set hiercells [filter_collection [get_cells -hierarchical] \
prompt> ? "is_hierarchical == true"]
• Example-2 : Accessing registers that receives more than one clock

prompt> set allregs [get_cells -hierarchical -filter {is_sequential == true}]
prompt> set multclkregs [filter_collection [get_pins -of_objects ${allregs}] \
prompt> ? "is_clock == true && sizeof(clocks_propagated) > 1"]
• Example-3 : Accessing all the rule instance under a policy name "sdc_checks". Note that the policy attribute
holds a singleton collection in which full_name can be accessed
prompt> set all_rule_insts [get_rule_instances -filter {rule_policy.full_name ==
sdc_checks}]
RELATED RULE CHECKS

None.
RELATED COMMANDS
Collection Commands
SDC Commands
RIDB Commands
RELATED VARIABLES
None

foreach_in_collection
Iterates over all elements of a given collection.
SYNTAX
string foreach_in_collection
<iterator>
<collections>
<body>
Data Type
iterator string
collections list
body string
ARGUMENTS
<iterator>
[Required] Specifies the name of the iterator which can be referenced inside the <body>.
<collections>
[Required] Specifies a collection over which iteration has to be executed.
<body>
[Required] Specifies a body to process the object assigned to <iterator> in each iteration.
DESCRIPTION
The foreach_in_collection command is used to iterate over each element of a collection. This is equivalent to
Tcl/Tk version of "foreach" command, however, foreach_in_collection can only operate on collection objects
(Tcl/Tk provided "foreach" command cannot be used to iterate through collection objects). The <iterator> can
only be one, unlike Tcl/Tk provided "foreach" command, foreach_in_collection does not allow list of iterators.
EXAMPLES
• Example-1 : The following example iterates over each input in the design and displays its name and direction
information.
prompt> foreach_in_collection i [add_to_collection -unique [all_inputs]
[all_outputs]] {
prompt> ? puts "[get_object_name $i] : [get_attribute $i port_direction]"
prompt> ? }
RELATED RULE CHECKS

None.
RELATED COMMANDS

Collection Commands
SDC Commands
RIDB Commands
RELATED VARIABLES
None.

index_collection
Returns an object at a given index in the base collection. The base collection remains unchanged.
SYNTAX
collection index_collection
<base_collection>
<index>
Data Type
index integer
ARGUMENTS
<base_collection>
[Required] Specifies the collection to be searched.
<index>
Requried option. Specifies the index to the object in the <base_collection> to be returned. The valid
value of <index> is an integer and the valid
range is from 0 to sizeof_collection - 1.
DESCRIPTION
The index_collection command is used to extract an object from the specified <base_collection> and
create a new collection with the extracted object only. The valid value of <index> is an integer and
the valid range is from 0 to "sizeof_collection <base_collection> - 1". Any index specified outside the
<base_collection> size results in an error. The <base_collection> can be an empty collection. However,
index_collection command used on an empty <base_collection> results in an empty result collection
and an error message as <index> is invalid for this case.
EXAMPLES
• Example-1 : The following example is used to extract the first object of a collection of clocks in the design.
prompt> query_objects [index_collection $allclks 0]
• Example-2 : The following example is uses the index_collection command on an empty base collection,
results in an error
prompt> set allpins ""
prompt> query_objects [index_collection $allpins 0]
RELATED RULE CHECKS

None.
RELATED COMMANDS

add_to_collection
query_objects
RELATED VARIABLES
None.

Creates a new collection by removing objects or collections from an existing base collection. The base collection
remains unchanged.
SYNTAX
collection remove_from_collection
[-intersect]
<base_collection>
<objects_tobe_removed>
Data Type
objects_tobe_removed list or collection
ARGUMENTS
-intersect
Remove_from_collection command returns a new collection by removing objects from
<base_collection> that are not present in <objects_tobe_removed>. If this option is not used,
then remove_from_collection removes objects present in <objects_tobe_removed> from the
<base_collection> to create a new collection.
<base_collection>
Specifies the <base_collection> to be used to create the new collection. The objects present in
<objects_tobe_removed> are removed and are not included in the returned new collection.
<objects_tobe_removed>
Specifies a list of named objects or collections to be removed. The object class of each element in
<objects_tobe_removed> must be the same as in the <base_collection>. The collection is used if the
name matches an existing collection. Otherwise, the objects are searched for in the database using
the object class of the <base_collection>.
DESCRIPTION
The remove_from_collection returns a new collection by removing a list of objects or collections from
a base collection. The <objects_tobe_removed> can either a list of named objects or a collection
containing objects. If the <base_collection> is homogeneous and <objects_tobe_removed> is a list of
named objects, then the objects in the <objects_tobe_removed> are searched using the object class of the
<base_collection>. If the <base_collection> is heterogeneous, the <objects_tobe_removed> must be a
collection and any named objects in the <objects_tobe_removed> is ignored.
By default, if there are no matching elements specified by <objects_tobe_removed> in the

<base_collection>, then the resulting new collection is a copy of the <base_collection>. If everything in the
<base_collection> matches the <objects_tobe_removed>, the returned collection is an empty collection.
On the other hand, if the -intersect option used, elements that are not in <object_tobe_removed>
are removed from <base_collection>, meaning returned collection has the objects that are specified in
<objects_tobe_removed>.

EXAMPLES
• Example-1 : The following example gets all ports and remove bidirectional ports from it.
prompt> set allports [get_ports]
prompt> set unidiroports [remove_from_collection ${allports} [get_ports -filter
"port_direction == inout"]]
RELATED RULE CHECKS

None.
RELATED COMMANDS
add_to_collection
index_collection
query_objects
RELATED VARIABLES
None.

sizeof_collection
Returns the number of objects in a collection.
SYNTAX
int sizeof_collection
<base_collection>
Data Type
ARGUMENTS
<base_collection>
[Required] Specifies the <base_collection> for which the number of objects to be determined.
DESCRIPTION
The sizeof_collection command is used to determine the number of objects in a <base_collection>. If
<base_collection> is empty, sizeof_collection command returns 0.
EXAMPLES
• Example-1 : The following example determines the number of designs in the elaborated design hierarchy.
prompt> puts "Number of designs used : \
prompt> ? [sizeof_collection [get_cells -hierarchical -filter {is_hierarchical ==
1}]]"
RELATED RULE CHECKS

None.
RELATED COMMANDS
Collection Commands
query_objects
RELATED VARIABLES
None.

sort_collection
Sorting a collection based on the criteria specified.
SYNTAX
collection sort_collection
[-descending]
[-dictionary]
<base_collection>
<criteria>
Data Type
criteria list
ARGUMENTS
[-descending]
[Optional] Indicates if the objects of the <base_collection> to be sorted in descending order. If the
option is not specified, the sorting is done in ascending order by default.
[-dictionary]
[Optional] Indicates the objects of the <base_collection> are sorted according to the dictionary order.
<base_collection>
[Required] Specifies the collection that is to be sorted.
<criteria>
[Required] Specifies a list of criteria to be used for sorting the <base_collection>.
DESCRIPTION
The sort_collection command sorts objects in a <base_collection> based on the user specified criteria. Sorts
are ascending by default, option -descending can reverse the sorting order. The sorting can be based on user
defined criteria, defined using attributes. When sorting a heterogeneous collection, attributes in the <criteria>
may be specific to subset of the objects, in such scenario, objects with attribute sorted and included in the
returned collection before the objects that do not have attribute.
EXAMPLES
• Example-1 : The following example sorts a ports in alphabetical order.
prompt> set allports [get_ports]
prompt> foreach_in_collection i [sort_collection ${allports} name] {
prompt> ? puts "get_attribute $i name"
prompt> ? }
RELATED RULE CHECKS

None.
RELATED COMMANDS
Collection Commands
query_objects
RELATED VARIABLES
None.

General Purpose Commands

This topic describes the commands that are used for setting up global environment for SDC Commands.

current_instance
Adds objects to create a new collection from an existing one. The existing collection remains unchanged.
SYNTAX
string current_instance
[<instance>]
Data Type
instance string or collection
ARGUMENTS
<instance>
[Optional] Specifies the <instance> to which the working scope to be changed.
DESCRIPTION
Command current_instance allows users to change hierarchy scope based on their instance name. Command
current_instance enable navigating design hierarchy and accessing the design information at each hierarchical
node.
EXAMPLES
• Example-1 : The following example shows how to go one hierarchy up.
prompt> current_instance ..
• Example-2 : The following example show how to change the scope to instance FOO in one level up.
prompt> current_instance ../FOO
RELATED RULE CHECKS

None.
RELATED COMMANDS
current_design
RELATED VARIABLES
None

set_hierarchy_separator
Add objects to a existing collection, results is a new collection, existing collection remains unchanged.
SYNTAX
string set_hierarchy_separator
<separator>
Data Type
separator / or . or @ or # or |
ARGUMENTS
<separator>
[Required] Specifies the <separator> to be considered for hierarchical object names.
DESCRIPTION
Command set_hierarchy_separator globally set the charactor to be used to determine hierarchical boundary in
the elaborated design tree. The default is "/" for all the SDC Commands.
EXAMPLES
• Example-1 : The following example shows how @ can b used as a hierarchy separator to avoid ambiguity
when boundaries are dessolved
prompt> set_hierarchy_separator @
prompt> set all_regs [get_cells inst1/inst2@sub1/sub2@*_reg]
RELATED RULE CHECKS

None.
RELATED COMMANDS
Object Access Commands
RELATED VARIABLES
None

set_units
Sets the units used for resistance, capacitance, timing, power, current, and voltage.
SYNTAX
string set_units
[-resistance <runits>]
[-capacitance <cunits>]
[-time <tunits>]
[-power <punits>]
[-current <aunits>]
[-voltage <vunits>]
Data Type
runits ohm|kohm|mohm|Mohm|10ohm|100ohm
cunits f|ff|pf|nf|uf|mf|10ff|100ff
tunits s|fs|ps|ns|us|ms|10ps|100ps
punits w|fw|pw|nw|uw|mw|10uw|100uw|10mw|100mw|10pw|100pw|10nw|100nw
aunits A|fA|pA|nA|uA|mA|10uA|100uA|10mA|100mA
vunits v|fv|pv|nv|uv|mv|10mv|100mv
ARGUMENTS
-resistance <runits>
[Optional] Sets the resistance unit.
-capacitance <cunits>
[Optional] Sets the capacitance unit.
-timing <tunits>
[Optional] Sets the time unit.
-power <punits>
[Optional] Sets the power unit.
-current <aunits>
[Optional] Sets the current unit.
-voltage <vunits>
[Optional] Sets the voltage unit.
DESCRIPTION
Command set_units set the units for all SDC commands. When specified units conflicts with the main library,
command issues a message to indicate such conflicts.
EXAMPLES

• Example-1 : The following sets time units for SDC commands

prompt> set_units -time ps
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

Object
Access
Commands
The
Object
Access
Commands
(OAC)
are
set
of
commands
frequently
used
to
access
design
objects
and
constraint
objects
available
in
Meridian
CDC.
This
section
describes
Meridian
CDC
supported
Object
Access
Commands.
Most
of
the
Object
Access
Commands
are
compatible
with
SDC
versions,
Meridian
CDC
also
supports
additional
non-
SDC

Object
Access
Commands
that
are
frequently
used.
When
object
access
commands
get
executed,
in
addition
to
returning
the
results,
each
command
prints
out
the
information
to
the
standard
output.
The
number
of
elements
get
printed
to
the
standard
output
is
controlled
by
variable
(default
is
25).
User
can
change
this
variable
to

adjust
the
number
of
elements
to
be
printed
to
standard
output.

all_clocks
Returns a collection of all clocks in the current design.
SYNTAX
collection all_clocks
ARGUMENTS
None.
DESCRIPTION
Command all_clocks returns a collection of clocks in the current design. If no objects exists, empty collection
is returned. The returned collection is a named handle that holds the list of objects. The command does not
print out the object names. Use the query_objects command to print out the object names if needed.
Clocks need to be created before all_clocks command can access the clocks. Clocks can be created by
create_clock or create_generated_clock command. The command all_clocks does not differentiate master
clocks from generated clocks.
The all_clocks command does not provide many capabilities provided in get_clocks command. To search
specific clock based on specific attribute of the clock, please use get_clocks command that provides more
control over the search.
EXAMPLES
• Example-1 : Query ports with the name contains clk
prompt> set allclks [all_clocks]
• Example-2 : Following makes all the clocks to be ideal

prompt> set_ideal_network [all_clocks]
• Example-3 : Queries all the objects where clocks are defined

prompt> set allrefs [get_attribute [all_clocks] sources]
SDC VERSION SUPPORT
Meridian CDC SDC Version

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_clocks Y Y Y Y Y Y Y Y
RELATED COMMANDS
create_clock
filter_collection
query_objects

RELATED VARIABLES
None

all_connected
Returns a collection of design objects that are connected to a given object in the current design.
SYNTAX
collection all_connected
[-leaf]
<object>
Data Type
object string or a collection
ARGUMENTS
-leaf
[Optional] Indicates that when the <object> is a net, only leaf pins to be included in the returned
collection. Valid for the nets that connects hierarchical cells.
<object>
[Required] Specify object for the connected design objects to be searched for. The <object> is either
name of a net, pin, or port, or a collection with one object of net, pin, or a port.
DESCRIPTION
Command all_connected returns a collection of design objects connected to a given <object>. The <object>
should only be a net, pin, or port, Specifying more than one object for <object> is a syntax error. When
name string is specified, command searches net, pin, port in that order for <object>, if finds then returns
the objects connected to specified named object. The return collection can either be a collection of nets, a
collection of pins, or a collection containing a mixture of pins and ports.
EXAMPLES
• Example-1 : Queries net name connected to clock pin of a register
prompt> set clknet [all_connected [get_pins a_reg/CP]]
• Example-2 : Queries drivers of a given net

prompt> set allpis [filter_collection [all_connected [get_nets clk_net] -leaf]
"direction == out"]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_connected Y N N N N N N N
<object> Y
-leaf Y

RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES
ri_synth_array_naming_style
ri_synth_interface_naming_style
ri_synth_record_naming_style
ri_synth_reg_clear_pin_name
ri_synth_reg_clocked_on_pin_name
ri_synth_reg_data_in_pin_name
ri_synth_reg_enable_pin_name
ri_synth_reg_naming_style
ri_synth_reg_next_state_pin_name
ri_synth_reg_output_inv_pin_name
ri_synth_reg_output_pin_name
ri_synth_reg_preset_pin_name
ri_synth_reg_synch_clear_pin_name
ri_synth_reg_synch_enable_pin_name
ri_synth_reg_synch_preset_pin_name
ri_synth_reg_synch_toggle_pin_name
ri_synth_vhdl_generate_naming_style
ri_synth_vhdl_generate_separator_style
ri_synth_vlog_generate_naming_style
ri_synth_vlog_generate_separator_style

all_fanin
Returns a collection of pin, port, or cell objects in the fan-in cone of given sink objects.
SYNTAX
collection all_fanin
-to <sink_objects>
[-flat]
[-only_cells]
[-startpoints_only]
[-exclude_bboxes]
[-break_on_bboxes]
[-levels <level_count>]
[-pin_levels <pin_count>]
[-trace_arcs <arc_type>]
[-step_into_hierarchy]
[-donot_return_sink_objects]
Data Type
sink_objects list or a collection

level_count integer
pin_count integer
arc_type timing | enabled |
all
ARGUMENTS
-to <sink_objects>
[Required] Specify a list of target <sink_objects> of the fan-in cone to be traversed. The all_fanin
command creates a collection of objects in the fan-in cone of the <sink_objects> based on the
command specification. Valid <sink_objects> can be of named pins, nets, or ports or a homogeneous or
heterogeneous collection of pins, nets, or ports.
-flat
[Optional] Indicates that the traversal to see the design as flat design without hierarchical boundaries,
thus the return collection includes only leaf cells (except the <sink_objects> which is included in the
returned collection without -dont_return_sink_objects) and the primary input or inout ports.
-only_cells
[Optional] Indicates that the returned collection to include only cells in the fan-in cone of the
<sink_objects>.
-startpoints_only
[Optional] Indicates that the returned collection to include only timing start points in the fan-in cone
of <sink_objects>.
-exclude_bboxes
[Optional] Indicates that blackbox cells to be removed from returned collection.
-break_on_bboxes

[Optional] Indicates that the fanin cone traversal to terminate at the black boxes.
-levels <level_count>
[Optional] Specifies the number of cell levels for tracing to be performed over from <sink_objects>.
Returned collection includes objects up to the cells limited by <level_count>.
-pin_levels <pin_count>
[Optional] Not supported by Meridian CDC. If incoming SDC contains all_fanin command with this
option, all_fanin command gets executed as if the option were not specified (ignoring the option).
Command is stored in Meridian CDC database as it appears in the SDC file but the command execution
results are not sensitive to this option.
-trace_arcs <arc_type>
[Optional] Specify the type of arcs the command is to navigate through during the design traversal.
Following values are allowed for the arc_type.
timing DEFAULT. Allow traversal through all active timing arcs that are not
disabled by set_disable_timing and set_case_analysis in the fanin cone
of the <sink_objects>.
enabled Allow traversal through all active timing arcs and arcs disabled
by set_case_analysis but disallow traversal through arcs disabled
set_disable_timing
all Allow traversal through all timing arcs, ignoring both set_disable_timing
and set_case_analysis
-step_into_hierarchy
[Optional] Not supported by Meridian CDC. If incoming SDC contains all_fanin command with this
option, all_fanin command gets executed as if the option were not specified (ignoring the option).
Command is stored in Meridian CDC database as it appears in the SDC file but the command execution
results are not sensitive to this option.
-donot_return_sink_objects
[Optional] Indicates that <sink_objects> in the -to option to be excluded from the returned collection.
By default, all <sink_objects> are included in the return collection. This option is Meridian CDC native
option and not valid in STA environment.
DESCRIPTION
Command all_fanin returns a collection of cell, pin, or port objects in the fan-in cone of <sink_objects>.
The <sink_objects> are included in the returned collection. With -dont_return_sink_objects option,
<sink_objects> can be excluded from return collection. The fan-in cone traversal stops at timing start points,
which is either at primary input, inout or at clock pin of a sequential cell. Unless user specified -only_cells,
return collection includes all the pins and ports in the fan-in cone of <sink_objects>.
Options -pin_levels, and -step_into_hierarchy are not supported. If they are used in the SDC file read into
Meridian CDC, these options are ignored and rule violation is flagged to indicated such behavior. Command
continues as if those options were not specified. However, command syntax checks for data types is performed
and report if invalid values are given.
Command all_fanin traverse the design relative to current_instance scope. Return collection only includes the
objects in the current_instance scope.
EXAMPLES

• Example-1 : Queries the register clock pin fan-in cone

prompt> set clkdrvs [all_fanin [get_pins "a_reg/CP"] -startpoints_only]
• Example-2 : Queries drivers of multi-driven net

prompt> set drvs [all_fanin [get_nets "foo/bar/multidrv_net"] -flat -level 1]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_fanin Y N N N N N N N
-to <sink_objects> Y
-flat Y
-only_cells Y
-startpoints_only Y
-exclude_bboxes Y
-break_on_bboxes Y
-levels <level_count> Y
-pin_levels <pin_count> N
-trace_arcs <arc_type> Y
-step_into_hierarchy N
-donot_return_sink_objects Y
RELATED COMMANDS
RELATED VARIABLES

all_fanout
Returns a collection of pin, port, or cell objects in the fan-out cone of given source objects.
SYNTAX
collection all_fanout
-from <source_objects> | -clock_tree
[-flat]
[-only_cells]
[-endpoints_only]
[-exclude_bboxes]
[-break_on_bboxes]
[-levels <level_count>]
[-pin_levels <pin_count>]
[-trace_arcs <arc_type>]
[-step_into_hierarchy]
[-donot_return_source_objects]
Data Type
source_objects list or a collection

level_count integer
pin_count integer
arc_type timing | enabled |
all
ARGUMENTS
-from <source_objects>
[Required] Specify a list of target <source_objects> of the fan-out cone to be traversed. The all_fanout
command creates a collection of objects in the fan-out cone of the <source_objects> based on the
command specification. Valid <source_objects> can be of named pins, nets, or ports or a homogeneous
or heterogeneous collection of pins, nets, or ports. Options -from and -clock_tree are mutually
exclusive options, you must use only one.
-clock_tree
[Optional] Indicates that the clock reference objects to be used as the list of <source_objects>. If no
clocks are defined or all the clocks defined are virtual clocks (which no objects are referenced) then
the results is an empty collection. Options -from and -clock_tree are mutually exclusive options, you
must use only one.
-flat
[Optional] Indicates that the traversal to see the design as flat design without hierarchical boundaries,
thus the return collection includes only leaf cells (except the <source_objects> which is included in
the returned collection) and the primary output or inout ports.
-only_cells
[Optional] Indicates that the returned collection to include only cells in the fan-out cone of the
<source_objects>.
-endpoints_only

[Optional] Indicates that the returned collection to include only timing end points in the fan-out cone
of <source_objects>.
-exclude_bboxes
[Optional] Indicates that blackbox cells to be removed from returned collection.
-break_on_bboxes
[Optional] Indicates that the fanin cone traversal to terminate at the black boxes.
-levels <level_count>
[Optional] Specifies the number of cell levels for tracing to be performed over from <source_objects>.
Returned collection includes objects up to the cells limited by <level_count>.
-pin_levels <pin_count>
[Optional] Not supported by Meridian CDC. If incoming SDC contains all_fanout command with this
option, all_fanout command gets executed as if the option were not specified (ignoring the option)
and flag a rule violation to indicate it. Command is stored in Meridian CDC database as it appears in
the SDC file but the command execution results are not sensitive to this option.
-trace_arcs <arc_type>
[Optional] Specify the type of arcs the command is to navigate through during the design traversal.
Following values are allowed for the arc_type.
timing DEFAULT. Allow traversal through timing arcs that are not disabled
by set_disable_timing and set_case_analysis in the fanout cone of the
<source_objects>.
enabled Allow traversal through all active timing arcs and arcs disabled by
set_case_analysis but disallow traversal through arcs disabled by
set_disable_timing
all Allow traversal through all timing arcs, ignoring both set_disable_timing
and set_case_analysis
-step_into_hierarchy
[Optional] Not supported by Meridian CDC. If incoming SDC contains all_fanout command with this
option, all_fanout command gets executed as if the option were not specified (ignoring the option)
and flag a rule violation to indicate it. Command is stored in Meridian CDC database as it appears in
the SDC file but the command execution results are not sensitive to this option.
-donot_return_source_objects
[Optional] Indicates that <source_objects> in the -from option to be excluded from the returned
collection. By default, all <source_objects> are included in the returned collection. This option is
Meridian CDC native option and not valid in STA environment.
DESCRIPTION
Command all_fanout returns a collection of cell, pin, or port objects in the fan-out cone of
<source_objects>. The <source_objects> are included in the returned collection. The fan-out cone
traversal stops at timing end points, which is either at primary output, inout or input pin of a sequential
cell. Unless user specified -only_cells, return collection includes all the pins and ports in the fan-out cone of
<source_objects>.
Options -pin_levels, and -step_into_hierarchy are not supported. If they are used in the SDC file read into
Meridian CDC, these options are ignored and rule violation is flagged to indicated such behavior. Command
continues as if those options were not specified. However, command syntax check for data types is performed
and rule violations are reported if invalid values are given.

Command all_fanout traverse the design relative to current_instance scope. Return collection only includes
the objects in the current_instance scope if the current_instance is not the design root (or top level).
EXAMPLES
• Example-1 : Queries the registers of clock source sysclk
prompt> set clksinks [all_fanout [get_port sysclk] -endpoints_only -flat]
• Example-2 : Queries feed through paths from PI to PO

prompt> set drvs [filter_collection [all_fanout [all_inputs] -endpoints_only]
"object_type == port"]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_fanout Y N N N N N N N
-from <sink_objects> Y
-clock_tree Y
-flat Y
-only_cells Y
-endpoints_only Y
-exclude_bboxes Y
-break_on_bboxes Y
-levels <level_count> Y
-pin_levels <pin_count> N
-trace_arcs <arc_type> Y
-step_into_hierarchy N
-donot_return_source_objects Y
RELATED RULE CHECKS
RELATED COMMANDS
RELATED VARIABLES


all_inputs
Returns a collection of input ports or inout ports in the current design.
SYNTAX
collection all_inputs
[-level_sensistive | -edge_triggered]
[-clock <clock_name>]
[-exclude_clock_ports]
Data Type
clock_name string or a collection
ARGUMENTS
-level_sensitive
[Optional] Indicates that ports with only level-sensitive input delay associated with to be considered.
If set_input_delay has not been defined using -level_sensitive option or no primary input or inout ports
is constrained by set_input_delay, an empty collection is returned.
-edge_triggered
[Optional] Indicates that ports with only edge-triggered input delay associated with to be considered.
Constraint set_input_delay without -level_sensitive is considered edge-triggered input delay. If such
input delay is not defined or no primary input or inout ports is constrained by set_input_delay, an
empty collection is returned.
-clock <clock_name>
[Optional] Specify clock name to be considered, primary input ports with set_input_delay -clock
<clock_name> associated are to be considered. The <clock_name> is either a name of a clock or a
collection including one clock.
-exclude_clock_ports
[Optional] Indicates that primary input ports with clock defined are to be excluded from the returned
collection.
DESCRIPTION
Command all_inputs returns a collection of primary input or inout ports in the current design, that matches
the criteria given to the command with options. If no objects matches the criteria, empty collection is
returned. The returned collection is a named handle that holds the list of objects. The command does not
print out the object names. Use the query_objects command to printout the object names if needed.
If -level_sensitive option is used, only primary inputs that are constrained by set_input_delay with -
level_sensitive are considered. if -edge_triggered option is used, only primary inputs that are constrained
by set_input_delay without -level_sensitive are considered. The ports that are not constrained by
set_input_delay are not considered and are not included in the returned collection.
The option -clock can be used to limit the search for input ports that are associated with a particular clock,
which can also be combined together with -level_sensitive and -edge_triggered to limit further objects
search.

The all_inputs command does not provide many capabilities provided in get_ports command. To search
specific input or inout ports, please use get_ports command that provides more control over the search.
EXAMPLES
• Example-1 : Queries primary inputs associated with clock name "sysclk"
prompt> set allpis [all_inputs -clock [get_clocks sysclk]]
• Example-2 : Queries all the inputs with level-sensitive delay associated with
prompt> set allpis [all_inputs -level_sensitive]
• Example-3 : Queries all inputs excluding inputs that have clock defined
prompt> set allpis [all_inputs -exclude_clock_ports]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_inputs Y Y Y Y Y Y Y Y
-level_sensitive Y Y Y Y Y Y Y Y
-edge_triggered Y Y Y Y Y Y Y Y
-clock <clock_name> Y Y Y Y Y Y Y Y
-exclude_clock_ports Y N N N N N N N
RELATED RULE CHECKS
RELATED COMMANDS
current_design
get_ports
query_objects
set_input_delay
RELATED VARIABLES

all_instances
Returns a collection of cell (or instance) objects of a design or a library cell in the current design relative to current
instance scope.
SYNTAX
collection all_instances
[-hierarchy]
<object>
Data Type
object string or a collection
ARGUMENTS
-hierarchy
[Optional] Indicates to perform search all levels of hierarchy down from the current instance when
searching cells (or instances) of a design or a library cell. The default is to search cells (or instances)
in the current instance level only.
<object>
[Required] Specify a design object or a library cell object of which cells (or instances) to be searched
for. The <object> is either name of a design or a library cell, or a collection with one object of design
or library cell.
DESCRIPTION
Command all_instances returns a collection of cell objects of a given design or a library cell. The <object>
should only be a design or a library cell, Specifying more than one object for <object> or any other objects
such as pin, nets, libpin, etc is a syntax error. When name string is specified, command searches design or
library cell in that order for <object>, if finds then returns the cells of the object.
EXAMPLES
• Example-1 : Queries instances of library cell CGCELL
prompt> set myinsts [all_instances [get_lib_cells "mylib/CGCELL"]]
• Example-2 : Queries instances of the user defined sync module

prompt> set syncinsts [all_instances [get_designs "sync_module"]]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_instances Y N N N N N N N
<object> Y
-hierarchy Y

RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES
ri_synth_design_naming_style
ri_synth_design_parameter_style
ri_synth_design_separator_style

all_outputs
Returns a collection of output ports or inout ports in the current design.
SYNTAX
collection all_outputs
[-level_sensistive]
[-edge_triggered]
Data Type
ARGUMENTS
-level_sensitive
[Optional] Indicates that ports with only level-sensitive output delay associated with to be considered.
If set_output_delay has not been defined using -level_sensitive option or no primary output or inout
ports is constrained by set_output_delay an empty collection is returned.
-edge_triggered
[Optional] Indicates that ports with only edge-triggered output delay associated with to be considered.
Constraint set_output_delay without -level_sensitive is considered edge-triggered output delay. If such
output delay is not defined or no primary output or inout ports is constrained by set_output_delay, an
empty collection is returned.
-clock <clock_name>
[Optional] Specify clock name to be considered, primary output or inout ports with set_output_delay -
clock <clock_name> associated are to be considered. The <clock_name> is either a name of a clock or
a collection including a clock.
DESCRIPTION
Command all_outputs returns a collection of primary output or inout ports in the current design, that matches
If -level_sensitive option is used, only primary outputs that are constrained by set_output_delay with -
level_sensitive are considered. if -edge_triggered option is used, only primary outputs that are constrained
by set_output_delay without -level_sensitive are considered. The ports that are not constrained by
set_output_delay are not considered and are not included in the returned collection.
The option -clock can be used to limit the search for output or inout ports that are associated with a particular
clock, which can also be combined together with -level_sensitive and -edge_triggered to limit the objects
search further.
The all_outputs command does not provide many capabilities provided in get_ports command. To search
specific output or inout ports, please use get_ports command that provides more control over the search.

EXAMPLES
• Example-1 : Queries primary outputs associated with clock name "sysclk"
prompt> set allpos [all_outputs -clock [get_clocks sysclk]]
• Example-2 : Queries all the outputs with level-sensitive delay associated with
prompt> set allpos [all_outputs -level_sensitive]
• Example-3 : Queries all outputs excluding inputs that have clock defined
prompt> set allpos [all_inputs -edge_triggered]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_outputs Y Y Y Y Y Y Y Y
-level_sensitive Y Y Y Y Y Y Y Y
-edge_triggered Y Y Y Y Y Y Y Y
-clock <clock_name> Y Y Y Y Y Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
get_ports
set_output_delay
query_objects
RELATED VARIABLES

all_registers
Returns a collection of cells or pins of registers based on the criteria.
SYNTAX
collection all_registers
[-rise_clock <rise_clock_name>]
[-fall_clock <fall_clock_name>]
[-cells]
[-data_pins]
[-clock_pins]
[-slave_clock_pins]
[-async_pins]
[-output_pins]
[-level_sensitive]
[-edge_triggered]
[-master_slave]
[-no_hierarchy]
Data Type

rise_clock_name string or a collection
fall_clock_name string or a collection
ARGUMENTS
-clock <clock_name>
[Optional] Specify name of the clock that the registers are clocked by to be considered. Object search
can be further controlled by other options in this command. The <clock_name> is either a name of a
clock or a collection including a clock.
-rise_clock <rise_clock_name>
[Optional] Specify the name of the clock that the registers are clocked by its rising edge to be
considered. Object search can further be controlled by other options in this command. The
<rise_clock_name> is either a name of the clock or a collection including a clock.
-fall_clock <fall_clock_name>
[Optional] Specify the name of the clock that the registers are clocked by its falling edge to
be considered. Object search can further be controlled by other options in this command. The
<fall_clock_name> is either a name of the clock or a collection including a clock.
-cells
[Optional] Indicates that the return collection to include cells, this is the default if no return object
type is specified.
-data_pins
[Optional] Indicates that the return collection to include data pins of registers.
-clock_pins
[Optional] Indicates that the return collection to include clock pins of registers.

-slave_clock_pins
[Optional] Indicates that the return collection to include clock pins of slave registers.
-async_pins
[Optional] Indicates that the return collection to include asynchronous pins of registers.
-output_pins
[Optional] Indicates that the return collection to include output pins of registers.
-level_sensitive
[Optional] Indicates that level sensitive registers (latches) to be considered for the search.
-edge_triggered
[Optional] Indicates that edge triggered registers (flops) to be considered for the search.
-master_slave
[Optional] Indicates that master/slave registers to be considered for the search.
-no_hierachy
[Optional] Indicates that search to be limited to current_instance scope only.
DESCRIPTION
Command all_registers returns a collection of primary input or inout ports in the current design, that matches
If -level_triggered or -edge_triggered option is used, only primary inputs that are constrained by
set_input_delay -level_triggered or set_input_delay -edge_triggered will be considered, respectively. The
ports that are not constrained, are not considered and are not included in the return collection.
The option -clock can be used to limit the search for input ports that are associated with particular clock,
which can also be combined together with -edge_triggered and -level_triggered to limit the objects search
further.
The all_inputs command does not provide many capabilities provided in get_ports command. To search
specific input or inout ports, please use get_ports command that provides more control over the search.
EXAMPLES
• Example-1 : Queries sequential cells that are driven by a clock "sysclk"
prompt> set sysclkregs [all_registers -clock [get_clocks sysclk]]
• Example-2 : Queries all level-sensitive latches driven by a clock "sysclk"

prompt> set sysclklats [all_registers -level_sensitive -clock [get_clocks sysclk]]
• Example-3 : Queries all inputs excluding inputs that have clock defined
prompt> set allpis [all_inputs -exclude_clock_ports]
SDC VERSION SUPPORT


Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
all_registers Y N N N N Y Y Y
-clock <clock_name> Y Y Y Y
-rise_clock Y Y Y Y
<rise_clock_name>
-fall_clock Y Y Y Y
<fall_clock_name>
-cells Y Y Y Y
-data_pins Y Y Y Y
-clock_pins Y Y Y Y
-slave_clock_pins ?? Y Y Y
-async_pins Y Y Y Y
-output_pins Y Y Y Y
-level_sensitive Y Y Y Y
-edge_triggered Y Y Y Y
-master_slave ?? Y Y Y
-no_hierarchy Y Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
get_cells
get_pins
query_objects
RELATED VARIABLES


current_design
Returns the current top design.
SYNTAX
string current_design
[<design_name>]
Data Type
design_name string
ARGUMENTS
<design_name>
[Optional] Specify the working design.
DESCRIPTION
Command current_design returns the current working design. NOTE that <design_name> is not currently
supported by Meridian CDC, as the current working design cannot be changed after design is elaborated.
However, working design name can be obtained by the command and passed onto subsequent commands for
applying constraints (see an example below).
EXAMPLES
• Example-1 : Retrieve the current working design
prompt> set mytop [current_design]
• Example-2 : Assign constraints to the top level

prompt> set_max_transition 0.22 [current_design]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
current_design Y Y Y Y Y Y Y Y
<design_name> N N N N N N N N
RELATED RULE CHECKS
RELATED COMMANDS
current_instance
RELATED VARIABLES


get_attribute
Access an attribute value of given objects.
SYNTAX
list get_attribute
<objects>
<attribute_name> | -all
[-class <object_type>]
[-value_list]
[-bus]
[-return_null_values]
[-quiet]
Data Type
objects list or a collection

attribute_name string
object_type string
ARGUMENTS
<objects>
[Required] Specifies the <objects> attributes to be accessed. The <objects> can be of named object
or list of objects combined with the -class indicating the <object_type> or collection of one or more
objects. When use with -all option, collection with only one <objects> is allowed. If <objects> is a
named string, the option -class <object_type> is also required.
<attribute_name>
Required option, <attribute_name> and -all are mutually exclusive options, you must use only one.
Specifies the name of the attribute the values to be accessed and returned. Attributes names are
specific to each object, refer to Real Intent Data Base for more details about attributes of each
object.
-all
[Required] <attribute_name> and -all are mutually exclusive options, you must use only one. Indicates
that all the attributes associated with the given object to be returned as attribute name/value pair.
This option helps reduce number of DB accesses when accessing multiple attributes of the same
object. When this option is used, collection with only one <objects> is allowed.
-class <object_type>
[Optional] Specifies the <object_type> of the named objects specified in <objects>. Specify the type
of the <objects>. This option has no impact and is ignored when the <objects> are a collection. Any
object described in the Real Intent Data Base are valid.
-value_list
[Optional] Indicated that the return value to be a list even the value is a single object. In Meridian
CDC, returned value is always a list even for a single object, this option is supported for command
syntax compatibility but there is no difference in return value with or without this option in Meridian
CDC.
-bus

[Optional] Indicates that attributes to be set on entire bus instead of individual members of the bus.
-return_null_values
[Optional] Return an empty string for the object where the attribute is not applicable in the given
<object_list>.
-quiet
[Optional] Indicates that warning or information messages to be suppressed if no <objects> were found
or <attribute_name> was not found, such cases command returns an empty list.
DESCRIPTION
Command get_attribute returns a list of values of an attribute of given objects. If attribute is unknown for
the given object, with -quiet option empty results is returned. If not message is issued to indicate such usage.
The <objects> can be a homogeneous or heterogeneous collection or named objects specified by -class
<object_type>. When -class option is used, <objects> can only be homogeneous list. In case of heterogeneous
collection, attribute name must be common to all attributes, if not message is issued to indicate such usage.
When accessing multiple of attributes of the same object, -all option makes it more robust, it returns all the
attributes in name/value pair in the returned list, which can then be stored into a Tcl array or dictionary
object. This reduces the number of RIDB access and thus improve performance.
EXAMPLES
• Example-1 : Queries clock sources of clock sysclk
prompt> set clkrefobj [get_attribute sysclk sources -class clock]
• Example-2 : Queris if the clock soruce is connected clock pins of sequetial cells
prompt> get_attribute [all_fanout [get_ports sysclk] -flat -endpoints_only]
is_clock_pin
• Example-3 : Accessing all the attributes of a given object and storing it in an array for later access
prompt> array set mydict [get_attribute [get_clocks sysclk] -all]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_attribute Y N N N N N N N
<objects> Y
<attribute_name> Y
-all Y
-class <object_type> Y
-value_list Y
-bus Y
-return_null_values Y
-quiet Y
RELATED RULE CHECKS

RELATED COMMANDS
query_objects
RELATED VARIABLES
None

get_cells
Returns a collection of cells in the current design relative to current instance scope.
SYNTAX
collection get_cells
[-regexp [-nocase] | -exact]
[-hierarchical]
[-hsc <separator>]
[-quiet]
Data Type
patterns list or collection

objects collection
separator string
expression string
ARGUMENTS
<patterns>
[Optional] This option is mutually exclusive with -of_objects, you must use only one. Specifies the
<patterns> to match against the cell names. The <patterns> can include wildcard characters such as
* (asterisk) and ? (question mark) or regular expressions when use with -regexp. The <pattern> can
also include collection as an input. If <patterns> is not given, * is used as a default <patterns> for the
search in the current design scope.
[Optional] This option is mutually exclusive with <patterns>, you must use only one. Specifies
collection of pin or net objects for the cells to be searched. The <objects> can be a homogeneous or
heterogeneous collection that includes pin and net objects. The option -hierarchical cannot be used
together with -of_objects.
-regexp
[Optional] This option is mutually exclusive with -exact, you must use only one. Indicates that the
<patterns> and <expression> in -filter provided to be treated as regular expressions when searching
objects in the design.
-nocase
[Optional] Valid only with -regexp. Indicates that the <patterns> and <expression> provided to be
treated as case insensitive manner.
-exact
[Optional] This option is mutually exclusive with -regexp, you must use only one. Indicates that the
<patterns> to be treated as literals and the pattern matching to be disabled. This option can be used
when searching object names that includes wildcards such as * (asterisk) and ? (question mark).
-hierarchical

[Optional] This option is mutually exclusive with -of_objects. Indicates that search to be performed
hierarchically from the current instance or current scope down. The hierarchical search matches the
object names against the <patterns> at particular level of design hierarchy. With -hierarchical option,
object "foo/bar/inst1" is returned by using "inst1" as a <pattern>.
-hsc <separator>
[Optional] Specify hierarchy separator (see set_hierarchy_separator for valid characters) to be used in
the <patterns> or object name search.
[Optional] Specifies the <expression> as a matching criteria. The <expression> is evaluated based
on the attribute of the object (see Design Objects for details), The object is included in the
<expression>).
-quiet
DESCRIPTION
Command get_cells returns a collection of cells in the current design, relative to current instance scope, that
matches the criteria given to the command. If -filter is provided, cell attributes that makes the <expression>
evaluates to true are included in the returned collection. If no objects matches the criteria, empty collection
in the current instance scope. if -hierarchical option is provided, command search objects in the design
hierarchy down from the current instance scope.
The <patterns> can be a regular expression when use with -regexp option, which is compatible with Tcl
regular expression matching. Options -exact is useful when the names include wildcard characters as a part of
the object name.
When querying a array of cells, <patterns> can be given in two ways. For example, if the design has an array
of cells named "data" of 32 bits on cell (or instnace) named "cpu" (i.e cpu/data[31:0]), cells can be access
by "cpu/data[*]" or just "cpu/data" as a <patterns>, both returns 32 bit cells. Also, individual cells can be
accessed by <cpu/data[index]> as a <patterns>, for ex. cpu/data[1].
EXAMPLES
• Example-1 : Queries cells with the name containing "reg"
prompt> set mycells [get_cells *reg*]
• Example-2 : Queries all the instance of hierarchical cells

prompt> set mycells [get_cells -hierarchical -filter {is_hierarchical == 1}]
• Example-3 : Queries all cells attached to a particular net

prompt> set mycells [get_cells -of_objects [get_nets "clock_net"]]
• Example-4 : Queries all cells where the "/" is part of the cell name
prompt> set mycells [get_cells -hsc @ top@inst1/inst2@leaf*_reg]

SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_cells Y Y Y Y Y Y Y Y
<patterns> Y Y Y Y Y Y Y Y
-of_objects <objects> Y N N Y Y Y Y Y
-regexp Y N N Y Y Y Y Y
-nocase Y N N Y Y Y Y Y
-exact Y N N N N N N N
-hierarchical Y Y Y Y Y Y Y Y
-hsc <separator> Y Y Y Y Y Y Y Y
-filter <expression> Y N N N N N N N
-quiet Y N N N N N N N
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES

get_clocks
Returns a collection of clocks in the current design.
SYNTAX
collection get_clocks
[<patterns>]
[-regexp [-nocase]]
[-quiet]
Data Type

expression string
ARGUMENTS
<patterns>
[Optional] Specifies the <patterns> to search clocks in the current design. The <patterns> can include
wildcard characters such as * (asterisk) and ? (question mark) or regular expressions when use with -
regexp. The <patterns> can also include collection as an input. If <patterns> is not given, * is used as a
default <patterns> for the search.
-regexp
[Optional] Indicates that the <patterns> and <expression> in -fitler provided to be treated as regular
expressions when searching objects in the design.
-nocase
[Optional] Valid only with -regexp option. Indicates that the <patterns> and <expression> provided to
be treated as case insensitive manner.
Specifies the <expression> as a matching criteria. The <expression> is evaluated based on the
attribute of the object (see Design Objects for details), The object is included in the return collection
if the <expression> is evaluated to true (see the filter_collection for details of <expression>).
-quiet
Indicates that warning or information messages to be suppressed if no objects were matched for the
given criteria and return an empty collection.
DESCRIPTION
Command get_clocks returns a collection of clocks in the current design, that matches the criteria given
to the command. If -filter is provided, clock attributes that makes the <expression> evaluates to true are
included in the returned collection. If no objects matches the criteria, empty collection is returned. The
returned collection is a collection that holds the list of clock objects. The command does not print out the
object names. Use the query_objects command to printout the clock object names if needed.
If <patterns> is not used, command uses * (asterisk) as the default <patterns> for the clock objects search in
the current design scope. The <patterns> can be a regular expression when use with -regexp option, which is
compatible with Tcl regular expression matching.

EXAMPLES
• Example-1 : Queries all clocks in the design (default pattern is *)
prompt> set allclks [get_clocks]
• Example-2 : Queries all generated clocks in the design

prompt> set allgclks [get_clocks -filter {is_generated == 1}]
• Example-3 : Following command returns clocks defined on port "myclk"

prompt> set portclk [get_clocks -filter {source == myclk}]
• Example-4 : Following command sets propagate attribute on all clocks

prompt> set_propagated_clock [get_clocks]
• Example-5 : Following command creates an exception between clkA and clkB

prompt> set_false_path -from [get_clocks clkA] -to [get_clocks clkB]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_clocks Y Y Y Y Y Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
all_clocks
create_clock (SDC)
create_clock (ENV)
query_objects
RELATED VARIABLES
None

get_designs
Returns a collection of designs in the current session.
SYNTAX
collection get_designs
[<patterns>]
[-hierarchical]
[-quiet]
Data Type
patterns list
expression string
ARGUMENTS
<patterns>
[Optional] Specifies the <patterns> to match against the design names read into the tool. The
<patterns> can include wildcard characters such as * (asterisk) and ? (question mark) or regular
expressions when use with -regexp. If <patterns> is not given, * is used as a default <patterns> for the
search in the current instance scope.
-regexp
[Optional] This option is mutually exclusive with -exact, you must use only one. Indicates that the
<patterns> and <expression> in -filter provided to be treated as regular expressions when searching
objects in the design.
-nocase
[Optional] Valid only with -regexp. Indicates that the <patterns> and <expression> provided to be
treated as case insensitive manner.
-exact
-hierarchical
[Optional] Indicates that design object search to be performed hierarchically from the current
instance scope down. The hierarchical search matches the design object names inferred in the design
hierarchy against the <patterns> from current scope down.
<expression>).
-quiet


DESCRIPTION
Command get_designs returns a collection of designs read into current session of Meridian CDC, object search
is done relative to current instance scope against the criteria specified. If -filter is provided, design attributes
that evaluates the <expression> to true are included in the returned collection. If no objects matches the
criteria, empty collection is returned. The returned collection is a named handle that holds the list of design
objects. The command does not print out the object names, use the query_objects command to printout the
object names if needed.
If <patterns> is not specified, command uses * (asterisk) as the default <patterns> for the object search in
the current instance scope. if -hierarchical option is provided, command search design objects in the design
hierarchy from the current instance scope down. The option -hierarchical also indicates that only the design
objects inferred in the design hierarchy to be searched (instead of all the design objects in the current working
session
the object name.
Differences between get_designs and get_all_modules command

• get_all_modules returns all parametrizations of a given module name (wildcards not allowed) in a Tcl
list matching Real Intent specific parametrized module names.
• get_designs returns all modules, including parametrizations, matching a pattern in an OAC collection
in SDC format
• As get_designs output is a Collection, it must be treated appropriately (i.e. if you need to add to it,
use append_to_collection)
• Output of get_designs and get_all_modules can differ as get_designs using SDC design names
whereas get_all_modules follow Real Intent specific parametrized module names.
• If full base name of reference design name is known, use get_all_modules. If full base name is not
known and wildcards are required use get_designs command.
• If you need a tcl list which can be provided to Real Intent commands (for example
set_shell_instances), use get_all_modules command.
• If you need a collection, use get_designs
EXAMPLES
• Example-1 : Queries designs with the name containing "cpu"
prompt> set mydesigns [get_designs *cpu*]
• Example-2 : Queries all the designs inferred for the current design
prompt> set mydesigns [get_designs -hierarchical]
• Example-3 : Queries the designs inferred from the specific instance down in the hierarchy
prompt> current_instance top/myinst1/myinst2
prompt> set subdesigns [get_designs -hierarchical]
SDC VERSION SUPPORT


Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_designs Y N N N N N N N
<patterns> Y
-regexp Y
-nocase Y
-exact Y
-hierarchical Y
-filter <expression> Y
-quiet Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
RELATED VARIABLES

get_libs
Returns a collection of libraries in the current design environment.
SYNTAX
collection get_libs
[-quiet]
Data Type

objects collection
expression string
ARGUMENTS
<patterns>
<patterns> to match against the libraries in current design environment. The <patterns> can include
wildcard characters such as * (asterisk) and ? (question mark) or regular expressions when use with -
regexp. The <patterns> can also include collection as an input. If <patterns> is not given, * (asterisk) is
collection of library cell objects of which their libraries to be returned. The <objects> is a collection
that includes library cell objects.
-regexp
[Optional] This option is mutually exclusive with -exact option, you must use only one. Indicates
that the <patterns> and <expression> in -filter provided to be treated as regular expressions when
searching objects in the design.
-nocase
-exact
<expression>).
-quiet


matched for the given criteria and return an empty string.
DESCRIPTION
Command get_libs returns a collection of libraries in the current design environment that matches the criteria
given to the command. If -filter is provided, library attributes that evaluates the <expression> to true are
included in the returned collection. If no objects matches the criteria, empty collection is returned. The
returned collection is a named handle that holds the list of objects. The command does not print out the
object names. Use the query_objects command to printout the object names if needed.
If <pattern> or -of_objects is not used, command uses * (asterisk) as the default <patterns> for the search
in the current design environment. if -hierarchical option is provided, command search objects in the design
hierarchy down from the current instance scope.
the object name.
EXAMPLES
• Example-1 : Queries all the libraries in the current design environment
prompt> set libs [get_libs]
• Example-2 : Queries all libraries of given library cells

prompt> set libs [get_libs -of_objects [get_lib_cells "*DFFRS*"]]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_libs Y Y Y Y Y Y Y Y
-of_objects <objects> Y N N N N N N N
RELATED RULE CHECKS
RELATED COMMANDS
current_design
query_objects
RELATED VARIABLES

None

get_lib_cells
Returns a collection of library cells in the libraries in the current design environment.
SYNTAX
collection get_lib_cells
[-hsc <separator>]
[-quiet]
Data Type

objects collection
separator string
expression string
ARGUMENTS
<patterns>
Specifies the <patterns> to match against the library cell names. The <patterns> can include wildcard
characters such as * (asterisk) and ? (question mark) or regular expressions when use with -regexp. The
<patterns> can also include collection as an input. If <patterns> is not given, */* is used as a default
<patterns> for the search, if the * (asterisk) is given as a <patterns>, it is also interpreted as */*.
collection of library pin or cell objects for the library cells to be searched. The <objects> can be a
homogeneous or heterogeneous collection that includes library pins and cell objects.
-regexp
-nocase
-exact
-hsc <separator>

<expression>).
-quiet
DESCRIPTION
Command get_lib_cells returns a collection of library cells in the current design environment, that
matches the criteria given to the command. If -filter is provided, library cell attributes that evaluates the
<expression> to true are included in the returned collection. If no objects matches the criteria, empty
collection is returned. The returned collection is a named handle that holds the list of objects. The command
does not print out the object names. Use the query_objects command to printout the object names if needed.
the object name.
The name of a library cell object consists with <library_name>/<library_cell_name>, where <library_name>
is the library that <library_cell_name> defined in. If <patterns> or -of_objects is not used, command uses
*/* (asterisk) as the default <patterns> for the search in the current design environment. if the * (asterisk)
is given as a <patterns>, it is also interpreted as */*. When only <library_cell_name> or * is provided as
a <pattern> for the search, return collection includes all <library_cell_name> in all libraries in the design
environment.
EXAMPLES
• Example-1 : Queries libraries cells in the library "mylib"
prompt> set mylibcells [get_lib_cells mylib/*]
• Example-2 : Return the library cell in all libraries

prompt> set mylibcells [get_lib_cells AND2XB]
• Example-3 : Queries sequential library cells in all the libraries

prompt> set libcells [get_lib_cells -of_objects [get_cells -filter {is_sequential ==
1}]]
• Example-4 : Queries all the library cells that are tagged as don't use
prompt> set dulibcells [get_lib_cells -filter {is_dont_use == 1}]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_lib_cells Y Y Y Y Y Y Y Y

RELATED RULE CHECKS
RELATED COMMANDS
current_design
query_objects
RELATED VARIABLES
None

get_lib_pins
Returns a collection of library pins of the libraries in the current design environment.
SYNTAX
collection get_lib_pins
[-hsc <separator>]
[-quiet]
Data Type

objects collection
separator string
expression string
ARGUMENTS
<patterns>
<patterns> to match against the library pin names. The <patterns> can include wildcard characters
such as * (asterisk) and ? (question mark) or regular expressions when use with -regexp. The <patterns>
can also include collection as an input. If <pattern> is not given, */*/* is used as a default <pattern>
for the search. if the * (asterisk) is given as a <pattern>, it is also interpreted as */*/*.
collection of library cell or pin objects for library pins to be searched. The <objects> can be a
homogeneous or heterogeneous collection that includes library cell and pin objects.
-regexp
-nocase
-exact
-hsc <separator>
the <pattern> or object name search.

<expression>).
-quiet
DESCRIPTION
Command get_lib_pins returns a collection of library pins in the current design environment, that matches the
criteria given to the command. If -filter is provided, library pin attributes that evaluated the <expression> to
true are included in the returned collection. If no objects matches the criteria, empty collection is returned.
The returned collection is a named handle that holds the list of objects. The command does not print out the
object names. Use the query_objects command to printout the object names if needed.
the object name.
The name of a library pin consists with <library_name>/<library_cell_name>/<library_pin_name>, where

<library_name> is the library that a <library_pin_name> of <library_cell_name> defined in. If <patterns>
or -of_objects is not used or used * (asterisk) for the pattern, command uses */*/* (asterisk) as the default
<patterns> for the search in the current design environment.
When querying an array of library pins, <patterns> can be given in two ways. For example, if the library cell,
named "memory", has an array of pins named "address" with 32 bits (i.e memory/address[31:0]), library pins
can be access by "*/memory/address[*]" or just "*/memory/address" as a <patterns>, both returns 32 library
pins. When only <library_pin_name> or * is provided as a <pattern> for the search, return collection includes
all <library_pin_name> of library cells in all libraries in the design environment.
EXAMPLES
• Example-1 : Queries clock pins of a particular cell
prompt> set clkpins [get_lib_pins top/inst1/leafcell2/* -filter {is_clock_pin == 1}]
• Example-2 : Queries all pins of a particular cell which contains hierarchical sperator as part of its name
prompt> set clkpins [get_lib_pins -hsc @ top@inst1/inst2@leafcell2@*]
• Example-3 : Queries all pins of a particular cell

prompt> set cellpins [get_lib_pins -of_objects [get_cells "top/level1/inst1"]]
• Example-4 : Queries all leaf pins (hierarchical pins excluded) connected to a particular net
prompt> set allpins [get_lib_pins -of_objects [get_nets "top/level1/inst1/mynet"] -
leaf]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_lib_pins Y Y Y Y Y Y Y Y

RELATED RULE CHECKS
RELATED COMMANDS
current_design
query_objects
RELATED VARIABLES
None

get_lib_timing_arcs
Returns a collection library timing arcs of a library cell.
SYNTAX
collection get_lib_timing_arcs
[-from <from_points>]
[-to <to_points>]
[-of_objects <objects>]
[-quiet]
Data Type
from_points list or collection

to_points list or collection
objects collection
expression string
ARGUMENTS
-from <from_points>
[Optional] Specifies a list of library cell pins library timing arcs in fanout cone to be returned for. The
<from_points> can either be a collection or a list of named objects.
-to <to_points>
[Optional] Specifies a list of library cell pins timing arcs in fanin cone to be returned for. The
<to_points> can either be a collection or a list of named objects.
[Optional] Specifies a list of library cell objects for their timing arcs to be returned.
<expression>).
-quiet
DESCRIPTION
Command get_lib_timing_arcs returns a collection of nets in the current design, relative to current instance
scope, that matches the criteria given to the command. If -filter is provided, library timing arcs attributes that
used in the <expression> evaluates to true are included in the returned collection. If no objects matches the
criteria, empty collection is returned. The returned collection is a named handle that holds the list of library
timing arc objects.

If <pattern> or -of_objects is not used, command uses * (asterisk) as the default <pattern> for the search
in the current instance scope. If both <from_points> and <to_points> are used, all the timing arcs between
those points are returned. If one of <from_points> or <to_points> is used, then library timing arcs from or to
that point are returned, respectively. Likewise, with -of_objects option, get_lib_timing_arcs command return
library cell arcs for the library cell objects specified in the list.
EXAMPLES
• Example-1 : Queries library timing arcs associated with register ouput pin of a library flops cell
prompt> set fin_arcs [get_lib_timing_arcs -to [get_lib_pins my_dff/Q]
• Example-2 : Queries all library arcs in a specified cell

prompt> set all_arcs [get_lib_timing_arcs -of_objects [get_lib_cells my_dff]]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_lib_timing_arcs Y Y Y Y Y Y Y Y
-from <from_points> Y Y Y Y Y Y Y Y
-to <to_points> Y Y Y Y Y Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES


get_object_name
Returns a full name of an object.
SYNTAX
string get_object_name
<object>
Data Type
object collection
ARGUMENTS
<object>
[Required] Specify an object for its full name to be returned. The <object> must be a collection,
named object (string) is not valid.
DESCRIPTION
Command get_object_name returns a full name of given <object>. The <object> should only be a collection,
specifying collection with more than one <object> is a syntax error. The command "get_object_name
<object>" is same as that of "get_attribute <objects> full_name", the only difference is latter supports more
than one object for accessing full_name attribute.
EXAMPLES
• Example-1 : Queries name of current instance
prompt> set mytop [get_object_name [current_instance]]
• Example-2 : Queries the name of all clocks in the design

prompt> foreach_in_collection i [get_clocks] { puts "Clock Name : [get_object_name
$i]" }
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_object_name Y N N N N N N N
<object> Y
RELATED RULE CHECKS
RELATED COMMANDS
query_objects
get_attribute

RELATED VARIABLES
None

get_pins
Returns a collection of pins in the current design relative to current instance scope.
SYNTAX
collection get_pins
[-hierarchical]
[-hsc <separator>]
[-leaf]
[-quiet]
Data Type

objects collection
separator string
expression string
ARGUMENTS
<patterns>
<patterns> to match against the pin names. The <patterns> can include wildcard characters such as *
(asterisk) and ? (question mark) or regular expressions when use with -regexp. The <patterns> can also
include collection as an input. If <patterns> is not given, */* is used as a default <patterns> for the
search. if the * (asterisk) is given as a <patterns>, it is also interpreted as */*.
[Optional] This option is mutually exclusive with <patterns> and -hierarchical options. Specifies
collection of net, or cell objects for the pins to be searched. The <objects> can be a homogeneous or
heterogeneous collection that includes cell and net objects.
-regexp
-nocase
-exact
-hierarchical

hierarchically from the current instance down. The hierarchical search matches the object names
against the <patterns> at particular level of design hierarchy. With -hierarchical option, object "foo/
bar/inst1/pinA" is returned by using "inst1/pinA" as a <patterns>.
-hsc <separator>
<expression>).
-leaf
[Optional] Indicates that only leaf cell pins to be included in the return collection.
-quiet
DESCRIPTION
Command get_pins returns a collection of pins in the current design, relative to current instance scope, that
matches the criteria given to the command. If -filter is provided, pin attributes that makes the <expression>
The name of a pin object consists with <cell_name>/<pin_name>, where <cell_name> is the full qualified
instance name of the parent that <pin_name> belongs to. If <patterns> or -of_objects is not used, command
uses */* (asterisk) as the default <patterns> for the search in the current instance scope. if -hierarchical
option is provided, command search objects in the design hierarchy down from the current instance scope.
the object name.
When querying an array of pins, <patterns> can be given in two ways. For example, if the design has an
array of pins named "address" with 32 bits on cell named "cpu" (i.e cpu/address[31:0]), pins can be access by
"cpu/address[*]" or just "cpu/address" as a <patterns>, both returns 32 bit pins. Also, individual bits can be
accessed by <cell/pin[index]> as a <patterns>, for ex. cpu/address[1].
EXAMPLES
• Example-1 : Queries clock pins of a particular cell
prompt> set clkpins [get_pins top/inst1/leafcell2/* -filter {is_clock_pin == 1}]
• Example-2 : Queries all pins of a particular cell which contains hierarchical sperator as part of its name
prompt> set clkpins [get_pins -hsc @ top@inst1/inst2@leafcell2@*]
• Example-3 : Queries all pins of a particular cell

prompt> set cellpins [get_pins -of_objects [get_cells "top/level1/inst1"]]

• Example-4 : Queries all leaf pins (hierarchical pins excluded) connected to a particular net
prompt> set allpins [get_pins -of_objects [get_nets "top/level1/inst1/mynet"] -leaf]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_pins Y Y Y Y Y Y Y Y
-leaf Y N N N N N N N
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES


get_ports
Returns a collection of ports in the current design.
SYNTAX
collection get_ports
[-quiet]
Data Type

objects collection
separator string
expression string
ARGUMENTS
<patterns>
<patterns> to match against the port names. The <patterns> can include wildcard characters such as
* (asterisk) and ? (question mark) or regular expressions when use with -regexp. The <patterns> can
search.
collection of net objects for the ports to be searched. The <objects> can be a homogeneous or
heterogeneous collection that includes net objects.
-regexp
-nocase
-exact
<expression>).

-quiet
DESCRIPTION
Command get_ports returns a collection of ports in the current design, that matches the criteria given to the
command. If -filter is provided, port attributes that makes the <expression> evaluates to true are included
in the returned collection. If no objects matches the criteria, empty collection is returned. The returned
collection is a named handle that holds the list of objects. The command does not print out the object names.
Use the query_objects command to print out the object names if needed.
in the current design. The <patterns> can be a regular expression when use with -regexp option, which is
compatible with Tcl regular expression matching. Options -exact is useful when the object names include
wildcard characters as a part of the object name.
When querying a bus ports, <patterns> can be given in two ways. For example, if the design has a bus
port named "address" with 32 bits (i.e address[31:0]), ports can be access by "address[*]" or just "address"
as a <patterns>, both returns 32 bit ports. Also, individual bits can be accessed by <name[index]> as a
<patterns>, for ex. address[1].
EXAMPLES
• Example-1 : Query ports with the name contains clk
prompt> set myports [get_ports *clk*]
• Example-2 : Queries all the input ports

prompt> set myports [get_ports -filter {direction == in}]
• Example-3 : Queries all cells attached to a particular net

prompt> set myports [get_ports -of_objects [get_nets "clock_net"]]
• Example-4 : Following create a clock on port bus_clk, get_ports command is embedded inside another
command
prompt> create_clock -name myclk -period 5.6 -waveform [list 0 2.8] [get_ports
bus_clk]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_ports Y Y Y Y Y Y Y Y

RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES

get_nets
Returns a collection of nets from the current design relative to current instance scope.
SYNTAX
collection get_nets
[-hierarchical]
[-hsc <separator>]
[-quiet]
Data Type

objects collection
separator string
expression string
ARGUMENTS
<pattern>
<patterns> to match against the net names. The <patterns> can include wildcard characters such as
* (asterisk) and ? (question mark) or regular expressions when use with -regexp. The <patterns> can
search.
collection of pin, port, or cell objects for the nets to be searched. The <objects> can be a
homogeneous or heterogeneous collection that includes pin, port, or cell objects.
-regexp
-nocase
-exact
-hierarchical
hierarchically from the current instance down. The hierarchical search matches the object names

against the <patterns> at particular level of design hierarchy. With -hierarchical option, object "foo/
inst1/net1" is returned by using "net1" as a <pattern>.
-hsc <separator>
the <pattern> or object name search.
<expression>).
-quiet
DESCRIPTION
Command get_nets returns a collection of nets in the current design, relative to current instance scope, that
matches the criteria given to the command. If -filter is provided, net attributes that makes the <expression>
If <pattern> or -of_objects is not used, command uses * (asterisk) as the default <pattern> for the search in
the current instance scope. if -hierarchical option is provided, command search objects in the design hierarchy
down from the current instance scope.
The <pattern> can be a regular expression when use with -regexp option, which is compatible with Tcl regular
expression matching. Options -exact is useful when the names include wildcard characters as a part of the
object name.
EXAMPLES
• Example-1 : Queries nets with the name containing "clk_int" in the current scope
prompt> set clknet [get_cells *clk_int*]
• Example-2 : Queries a net connected to a primary clock input port

prompt> set clknet [get_nets -of_objects [get_ports sysclk]]
• Example-3 : Queries all nets connected to a particular cell

prompt> set allnets [get_nets -of_objects [get_cells "inst1/inst2/genclk_reg"]]
• Example-4 : Queries all netss where the names hierarchical separator is part of the cell name
prompt> set mynets [get_nets -hsc @ top@inst1/inst2@clk_net]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_nets Y Y Y Y Y Y Y Y

RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES

get_timing_arcs
Returns a collection timing arcs in the design.
SYNTAX
collection get_timing_arcs
[-from <from_points>]
[-to <to_points>]
[-of_objects <objects>]
[-quiet]
Data Type
from_points list or collection

to_points list or collection
objects collection
expression string
ARGUMENTS
-from <from_points>
[Optional] Specifies a list of pins or ports timing arcs in fanout cone to be returned for. The
<from_points> can either be a collection or a list of named objects.
-to <to_points>
[Optional] Specifies a list of pins or ports timing arcs in fanin cone to be returned for. The <to_points>
can either be a collection or a list of named objects.
[Optional] Specifies a list of net or cell objects for their timing arcs to be returned. The <objects> can
be a homogeneous or heterogeneous collection that includes cell and/or net objects.
<expression>).
-quiet
DESCRIPTION
Command get_timing_arcs returns a collection of timing arcs in the current design, relative to current
instance scope, that matches the criteria given to the command. If -filter is provided, timing arcs attributes
that used in the <expression> evaluates to true are included in the returned collection. If no objects matches
the criteria, empty collection is returned. The returned collection is a named handle that holds the list of
timing arc objects.

If <pattern> or -of_objects is not used, command uses * (asterisk) as the default <pattern> for the search in
the current instance scope. If the <from_points> and <to_points> are input and output pins of the same cell,
cell arcs are returned. If <from_points> and <to_points> are connected by nets, then net arcs are returned.
Likewise, with -of_objects option, get_timing_arcs command return cell arcs for the cells object and net arcs
for the net objects specified in the list.
EXAMPLES
• Example-1 : Queries arcs associated with register ouput pin of a flop instance
prompt> set fin_arcs [get_timing_arcs -to [get_pins my_flop_reg/Q]
• Example-2 : Queries all the arcs in a specified cell

prompt> set all_arcs [get_timing_arcs -of_objects [get_cells my_flop_reg]]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
get_timing_arcs Y Y Y Y Y Y Y Y
-from <from_points> Y Y Y Y Y Y Y Y
-to <to_points> Y Y Y Y Y Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
current_design
current_instance
query_objects
RELATED VARIABLES


query_objects
Displays object names in specified collection.
SYNTAX
string query_objects
<objects>
[-class <object_class>]
[-truncate <element_count>]
[-verbose]
Data Type

object_class string
element_count integer
ARGUMENTS
<objects>
Specifies the <objects> names to be returned for. The <objects> can be of list of named objects
(strings) with the -class indicating the <object_class> or collection of one or more objects. If named
objects are used, -class is a required option.
-class <object_class>
[Optional] This option becomes required if the <objects> are named objects (strings). Specify the type
of the <objects>. This option has no impact and is ignored when the <objects> is a collection. Any
object described in the Real Intent Data Base is a valid <object_class>.
-truncate <element_count>
[Optional] Specifies the limit of elements to be reported (or displayed). Command stops displaying the
object names after <element_count> is reached and print out the total elements in the <objects> at
the end.
-verbose
[Optional] Indicates that output to indicate the class of each object found in the <objects>, by default
only name of <objects> is reported.
DESCRIPTION
Command query_objects displays the names of the specified name <objects> or the collection <objects>.
The <objects> can be a homogeneous or heterogeneous collection or named objects specified by -class
<object_class>. When -class option is used, name <objects> can only be homogeneous type, but can be used
together with collections in the list form. Command query_objects only process the collection objects when
the -class is not provided.
Note that query_objects command returns empty string always when command execution is successful, so the
command cannot be used to translate the collection objects to list of strings as shown in example-4.
EXAMPLES

• Example-1 : Display all the name of primary input ports

prompt> query_objects [all_inputs]
• Example-2 : Display all the objects and its type in the fan-out cone of sysclk primary port
prompt> query_objects -verbose [all_fanout [get_ports sysclk] -flat]
• Example-3 : When the display results are truncated, message is printed to indicate the total number of
matched objects
prompt> query_objects -verbose [all_fanout [get_ports sysclk] -flat]
• Example-4 : Command always returns empty string

prompt> set returnval [query_objects [all_input]]
prompt> puts ${returnval} ; ## Variable returnval has empty string assigned
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
query_objects Y N N N N N N N
<objects> Y
-truncate Y
<element_count>
-verbose Y
RELATED RULE CHECKS
RELATED COMMANDS
get_attribute
RELATED VARIABLES
None

set_attribute
Sets an attribute to a given value of specified objects.
SYNTAX
collection set_attribute
<objects>
<attribute_name>
<attribute_value>
[-class <object_type>]
[-type <attribute_value_type>]
[-bus]
[-quiet]
Data Type

attribute_name string
attribute_value string
attribute_value_type boolean | integer | float |
string
ARGUMENTS
<objects>
[Required] Specifies the <objects> attributes to be set. The <objects> can be of name of an object or
list of named objects (strings) with the -class option indicating the <object_type> or collection of one
or more objects. If <objects> is a named objects -class is a required option.
<attribute_name>
[Required] Specifies the name of the attribute the value to be set. Attributes names are specific to
each object, refer to Real Intent Data Base for more details about attributes of each object.
<attribute_value>
[Required] Specifies the value for the <attribute_name> to be set. If the <attribute_value> is not valid
value or valid type for <attribute_name>, message is issued to indicate such scenario. If -quiet option
is specified empty collection is returned and message is suppressed.
-class <object_type>
[Optional] If <objects> are named objects, this option becomes required. Specify the type of the
<objects>. This option has no impact and is ignored when the <objects> is a collection. Any object
described in the Real Intent Data Base is a valid <object_type>.
-type <attribute_value_type>
[Optional] Specifies the <attribute_value_type> of the name object specified in <objects>. This option
has no impact as Meridian CDC does not support creating user defined attributes for the objects using
set_attribute command.
-bus
[Optional] Indicates that attributes to be set on entire bus instead of individual members of the bus.

-quiet
[Optional] Indicates that warning or information messages to be suppressed if no <objects> were found
or <attribute_name> was not found and return an empty list.
DESCRIPTION
Command set_attribute sets an attribute to a given value of the <objects> and returns a collection of objects
the command was operated on. If the attribute is unknown for the given object, with -quiet option empty
collection is returned, if -quiet is not specified, message is issued to indicate such problem. The <objects> can
be a homogeneous or heterogeneous collection or named objects specified by -class <object_type>. When -
class option is used, <objects> can only be homogeneous list. In case of heterogeneous collection, attribute
name must be common to all attributes.
EXAMPLES
• Example-1 : Sets the status attribute to SIGNEDOFF of CDC static control crossings
prompt> set_attribute [get_violations -criteria static_signals] status "SIGNEDOFF"
• Example-2 : Sets the severity of rule instance to CRITICAL

prompt> set_attribute [get_rules W_DATA] severity CRITICAL
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
set_attribute Y N N N N N N N
<objects> Y
<attribute_name> Y
<attribute_value> Y
-type Y
<attribute_value_type>
-bus Y
-quiet Y
RELATED RULE CHECKS
RELATED COMMANDS
query_objects
RELATED VARIABLES
None

Timing Constraints Commands

This topic describes the commands that are used for setting up timing requirements for the design.

create_clock
Creates a clock object.
SYNTAX
string create_clock
[-name <clock_name>]
[-period <period_value>]
[-waveform <edge_list>]
[-add]
<ref_objects>
Data Type
clock_name string
period_value float
edge_list list
comment string
ref_objects list
ARGUMENTS
-period <period_value>
Specifies the clock period in library time units. The clock waveform repeats itself over, after this
minimum time value. The <period_value> should be greater than or equal to zero.
-name <clock_name>
Specifies the name of the clock being created. <clock_name> has to be enclosed in quotation marks. If
this option is not used while creating clock, then the clock gets the same name as the first clock source
specified in the <ref_objects> option. In case <ref_objects> had not been specified, -name <clock_name>
option has to be used, which creates a virtual clock, which is not associated with a port or a pin. Both -
name <clock_name> and <ref_objects> options can be used together to give a more descriptive name to
the clock created. If -add option is specified, -name option is mandatory. Clocks with the same source
must be assigned different names.
-waveform <edge_list>
Specifies the rise and fall edges of the waveform of the clock created in library time units over an
entire clock period. The first entry in the <edge_list> is typically the first rising transition after time
zero. The number of edges specified must be even and alternatively rising and falling. The edges must
be monotonically increasing. The numbers should represent one full clock period. If the option is not
specified, a default waveform is assumed, with a rise edge of 0.0 and a fall edge of <period_value>/2.
-add
Specifies whether to add this clock to the existing clock or to overwrite it. This option is used for the
case where multiple clocks are specified on the same source for simultaneous analysis with different
clock waveforms. The -name option is required with -add. Defining multiple clocks on the same source
pin or port cause longer runtime and higher memory usage than a single clock, because all possible
combinations of launch and capture clocks need to be explored. The set_false_path command can be
used to disable unwanted clock combinations.

-comment <comment_string>
Associates a string description with the command for tracking purpose. This can be useful when writing
out SDC to a tag, such as the methodology or tool that originally synthesized the command.
<ref_objects>
Specifies the objects used as sources of the clock. The sources can be ports, pins or nets in the design.
If this option is not specified, -name has to be used to create a virtual clock that is not associated with
a port, pin, or net. If a clock is specified on a pin that already has a clock associated with it, the new
clock overwrites the old one unless -add option is used. When a net is used as the source, the first driver
pin of the net is the actual source used in creating the clock.
DESCRIPTION
The create_clock command is used to create a clock object. It is created in the current design and is applied
to the specified <ref_objects>. If -name <clock_name> is specified without <ref_objects>, then a virtual clock is
created. A virtual clock could be created to represent an off-chip clock for input or output delay specification.
Please refer to set_input_delay and set_output_delay for more information about input or output delay
specification.
If one of the <ref_objects> values is already the source of a clock, the source is removed from that clock. This
clock is eliminated if it has just one source.
The create_clock command is used with set_clock_latency, set_clock_uncertainty, set_propagated_clock and

set_clock_transition commands to specify properties of clock networks. By default, a new path group is created
for the clock. This new path group brings together the endpoints related to this clock for cost function calculation.
To remove the clock from its assigned group, the group_path command is used to reassign the clock to another
group or to the default path group. Refer to group_path command for futher details on how to use the command.
The new clock has ideal clock latency and transition time, no propagated delay through the clock network
is assumed and a transition time of zero is used at the clock source pin. To enable propagated latency for a
clock network, the set_propagated_clock command is used. To set an estimated latency, the set_clock_latency
command is used.
Report_clocks can be used to get further information about the clocks in the design. To create a collection
of clocks matching a pattern and optionally matching filter criteria, use the get_clocks command. Use
remove_clock command to delete a created clock.
EXAMPLES
• Example-1 : The following example creates a clock with a period 20.0, rise of 1.0 and fall of
prompt> create_clock -name CLK -period 20.0
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.

RELATED COMMANDS
all_clocks
get_clocks
RELATED VARIABLES

Creates a generated clock object.
SYNTAX
string create_generated_clock
[-name <clock_name>]
[-source <master_pin>]
[-divide_by <divide_factor> | -multiply_by <multiply_factor> | -edges <edge_list> ]
[-combinational]
[-duty_cycle <percent>]
[-invert]
[-edge_shift <edge_shift>]
[-add]
[-master_clock <master_clock>]
[-pll_output <output_pin>]
[-pll_feedback <feedback_pin>]
<ref_objects>
Data Type
clock_name string
master_pin list
divide_factor integer
multiply_factor integer
edge_list list
percent float
edge_shift list
master_clock string
output_pin list
feedback_pin list
comment string
ref_objects list
ARGUMENTS
-name <clock_name>
Specifies the name of the generated clock. If this option is not used, the clock receives the same name
as the first clock source specified in the -source option. If -add option is specified, -name option must
be given too. The clocks with the same source must have different names.
-source <master_pin>
Specifies the master clock source (a clock source pin in the design) from which the clock waveform is
to be derived. The actual latency for the generated clock is computed using its own source pins and
not the <master_pin>.
-divide_by <divide_factor>

Specifies the frequency division factor. For example, for <divide_factor> value of 2, the generated clock
period is twice as long as the master clock period.
-multiply_by <multiply_factor>
Specifies the frequency multiplication factor. If the <multiply_factor> value is 3, the generated clock
period is one-third as long as the master_clock <clock> period.
-edges <edge_list>
Specifies a list of integers representing edges from the source clock that are to form the edges of the
generated clock.
The edges should alternately rise and fall and must be monotonically increasing. The number of edges
must be an odd number and should be greater than 3 to make one full clock cycle of the generated
clock waveform.
-combinational
The source latency paths for this type of generated clock only includes the logic where the master clock
propagates. The source latency paths do not flow through sequential element clock pins, transparent
latch data pins, or source pins of other generated clocks.
-duty_cycle <percent>
Specifies the duty cycle, in percentage, if frequency multiplication is used. Duty cycle is the high
pulse width.
-invert
Inverts the generated clock signal (in the case of frequency multiplication and division).
-edge_shift <edge_shift>
Specifies 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.The number of edge
shifts specified must be equal to the number of edges specified. The values can be positive or negative;
positive indicating a shift later in time,while negative indicates a shift earlier in time.
-add
Specifies whether to add this clock to the existing clock or to overwrite it. This option is used in cases
where multiple generated clocks must be specified on the same source. If -add option is used, then
specifying -name and -master_clock options is mandatory. Defining multiple clocks on the same source
pin or port causes longer runtime and higher memory usage than a single clock,because all possible
combinations of launch and capture clocks have to be explored. It is possible to use set_false_path
command to disable unwanted clock combinations.
-master_clock <master_clock>
Specifies the master clock to be used for the generated clock if multiple clocks fan into the master
pin. If this option is used, -add should be specified too.
-pll_output <output_pin>
Specifies the output pin of the PLL which is connected to the feedback pin. For single output PLLs, this
pin is same as the pin on which the generated clock is defined.
-pll_feedback <feedback_pin>
Specifies the feedback pin of the PLL. There should be a path in the circuit connecting one of the outputs
of the PLL to this feedback pin.
-comment <comment>

<ref_objects>
Specifies a list of ports, pins or nets which are source objects for the generated clock. When a net is used
as the source, the first driver pin of the net is the actual source used in creating the generated clock.
DESCRIPTION
This command is used to create a generated clock object in the current design. A pin or a port can be specified
as generated clock object. A list of objects as generated clock sources in the current design is also defined.
The generated clock changes in accordance with any changes in the master clock instantaneously.
The generated clock can be created as one of the following:
• A frequency multiplied clock by using the -multiply_by option

• A frequency divided clock by using the -divide_by option
• A special divide by one by using the -combinational option
• An edge-derived clock by using the -edges option
The frequency-multiplied or frequency-divided clock can be inverted by using the -invert option. The shifting
of edges of the edge-derived clock is specified by using -edge_shift option.
The number of edges specified by -edges to define a period of the generated clock waveform must be an odd
number greater than or equal to 3.
Non-increasing edges such as -edges { 2 2 4} is valid and usually used with -edge_shift to produce a generated
clock pulse independent of duty cycle of the master clock itself.
If a generated clock is specified with a <divide_factor> value that is a power of 2, the rising edges of the
master clock are used to determine the edges of the generated clock. If the <divide_factor> value is not a
power of 2, the edges are scaled from the master clock edges.
Using the create_generated_clock command on an existing generated_clock object overwrites its attributes.
The set_clock_latency, set_clock_uncertainty, set_propagated_clock and set_clock_transition commands

apply to the generated_clock as well.
For internally generated clocks, if the master_clock of the generated_clock has propagated latency and the
user does not define values for generated_clock source latency, then the clock source latency is automatically
computed.
If the master_clock is ideal and has source latency and the user does not define values for generated_clock
source latency, zero source latency is assumed.
To display information about generated clocks, use the report_clock command.
EXAMPLES
• Example-1 :
prompt> create_generated_clock -name genclk -divide_by 2 -source clk [get_pins
{clkdiv_reg/Q}]
SDC VERSION SUPPORT

RELATED RULE CHECKS

None.
RELATED COMMANDS
create_clock
get_generated_clocks
remove_generated_clock
report_clock
set_clock_latency
set_clock_uncertainty
set_clock_transition
set_false_path
set_propagated_clock
RELATED VARIABLES

group_path
Groups paths for cost function calculations and reporting.
SYNTAX
Boolean group_path
[-name <group_name>]
[-default]
[-weight <weight_value>]
[-from <from_list>]
[-rise_from <rise_from_list>]
[-fall_from <fall_from_list>]
[-through <through_list>]
[-rise_through <rise_through_list>]
[-fall_through <fall_through_list>]
[-to <to_list>]
[-rise_to <rise_to_list>]
[-fall_to <fall_to_list>]
Data Type
group_name string
weight_value float
from_list list
rise_from_list list
fall_from_list list
through_list list
rise_through_list list
fall_through_list list
to_list list
rise_to_list list
fall_to_list list
comment string
ARGUMENTS
-name <group_name>
Specifies a name for the group. If a group with the same name already exists, the paths or endpoints
are added to the existing group. A new group is created for each unique <group_name>. The -name
and the -default options are mutually exclusive. However, the -name option must be specified in the
absence of -default option.
-default
If this option is used, then the endpoints or paths are moved to the default group and are removed from
the current group. he -name and the -default options are mutually exclusive. However, the -default
option must be specified in the absence of -name option.
-weight <weight_value>

Specifies a cost function weight for the group. The <weight_value> must be lie between 0.0 and 100.0.
The default value is 1.0. A <weight_value> of 0.0 eliminates the paths in this group from cost function
calculations. If the -weight option is specified while adding members to the existing group, then the
new <weight_value> is used for the updated group.
-from <from_list>
Specifies a list of timing path startpoint objects. A valid timing startpoint is a clock, a primary input
or inout port, a sequential cell, a clock pin of a sequential cell, a data pin of a level sensitive latch,
or a pin that has input delay specified. If a clock is specified, all registers and primary inputs related
to that clock are used as path startpoints. If a cell is specified, one path startpoint on that cell is
affected. Only one option among -from, -rise_from, -fall_from options can be used.
-rise_from <rise_from_list>
This option is similar to the -from option except for the fact that the path must rise from the objects
specified. If a clock object is specified, startpoints clocked by this named clock are selected but only
the paths launched by rising edge of the clock at the clock source are considered taking into account
any logical inversions along the clock path. Only one option among -from, -rise_from, -fall_from
options can be used.
-fall_from <fall_from_list>
This option is similar to the -from option except for the fact that the path must fall from the objects
paths launched by falling edge of the clock at the clock source are considered taking into account any
logical inversions along the clock path. Only one option among -from, -rise_from,
-fall_from options can be used.
-through <through_list>
Specifies a list of path throughpoints. The valid objects are ports, pins, cells or nets. It is possible to
use the -through,
-rise_through, -fall_through options multiple times in a single command to specify paths traversing
through multiple points in the design. The points must be listed in order.
-rise_through <rise_through_list>
It is similar to -through option, but applies only to paths with a rising transition at the specified
objects.
-fall_through <fall_through_list>
It is similar to -through option, but applies only to paths with a falling transition at the specified
objects.
-to <to_list>
Specifies a list of timing path endpoint objects. A valid timing endpoint is a clock, a primary output or
inout port, a sequential cell, a data pin of a sequential cell, or a pin that has output delay specified. If
a clock is specified, all registers and primary outputs related to that clock are used as path endpoints.
If a cell is specified, one path endpoint on that cell is affected. Only one option among -to, -rise_to,
-fall_to options can be used.
-rise_to <rise_to_list>
This option is similar to the -to option except for the fact that it applies only to paths rising at the
endpoint. If a clock object is specified, endpoints clocked by the named clock are selected but only
the paths captured by rising edge of the clock at the clock source are considered taking into account
any logical inversions along the clock path. Only one option among -to, -rise_to,

-fall_to <fall_to_list>
This option is similar to the -to option except for the fact that it applies only to paths falling at the
the paths captured by falling edge of the clock at the clock source are considered taking into account
-comment <comment>
DESCRIPTION
The group_path command is used to group a set of paths or endpoints for cost function calculations in
optimization and analysis. Path groups affect the output of the report_timing and report_constraint
commands too.
The delay cost function is the sum of all groups (weight * violation), where violation is the cost of the worst
path in the path group. If no violations occur in a group, then the group cost is zero. Groups specify a set of
paths to optimize. If path endpoints are specified, all paths leading to those endpoints are grouped.
The weight of the default group is 1.0. Every new group is assigned the default weight_value of 1.0 unless
specified otherwise.
Remove_path_group command reverses the affect of the group_path command. To report path group
information for a design, use the report_path_group command.
EXAMPLES
• Example-1 :
prompt>
• Example-2 :
prompt>
prompt>
• Example-3 :
prompt>
prompt>
prompt>
• Example-4 :
prompt>
prompt>
prompt>
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
create_clock
current_design
remove_path_group
report_constraint
report_path_group
reset_design
set_input_delay
set_output_delay
RELATED VARIABLES

set_clock_gating_check
Specifies the value of setup and hold time for clock gating checks.
SYNTAX
string set_clock_gating_check
[-setup <setup_value>]
[-hold <hold_value>]
[-rise | -fall ]
[-high | -low]
<ref_objects>
Data Type
setup_value float
hold_value float
ref_objects list
ARGUMENTS
-setup <setup_value>
Specifies the clock gating setup time. The default value is 0.0.
-hold <hold_value>
Specifies the clock gating hold time. The default value is 0.0.
-rise
Indicates that only rising delays are constrained. If neither -rise nor -fall option is specified, both the
rising and falling delays are constrained.
-fall
Indicates that only falling delays are constrained. If neither -rise nor -fall option is specified, both the
rising and falling delays are constrained.
-high
Indicates that the check is performed on the high level of the clock. By default, the tool determined
whether to use the high or low level of clock using information from cell's logic. It is required to
specify the -high or -low option with the <ref_objects>; <ref_objects> must not contain a clock when
used with -high or -low.
-low
Indicates that the check is performed on the low level of the clock. By default, the tool determined
<ref_objects>
Specifies a list of objects in the current design for which the clock gating check is applied. The objects
can be clocks, pins, or cells. If a cell is specified, all input pins of that cell are affected. If a pin or cell is
specified, any clock gating checks located at the specified objects are affected. If a clock is specified,
the clock gating check is applied to all gates driven by that clock. <ref_objects> must be is specifies,

if -high or -low option is specified; however, <ref_objects> must not contain a clock. By default, if the
<ref_objects> is not specified, the clock gating check is applied to the current design.
DESCRIPTION
The set_clock_gating_check command specifies a setup or hold time clock gating check used for clocks, pins
or cells. The gating check is performed on pins that gate a clock signal.
The behavior of the set_clock_gating_check command is controlled by variable

timing_clock_gating_check_fanout_compatibility.
The clock gating setup check is used to ensure the controlling data signals are stable before the clock signal is
active. This check is performed on combinational gates through which the clock signals are propagated.
EXAMPLES
• Example-1 :
prompt> set_clock_gating_check -setup 0.2 [get_pins u_a/b]
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_clock_gating_check
reset_design
current_design
report_constraint
report_clock_gating_check
RELATED VARIABLES
None

set_clock_groups
Specifies clock groups that are mutually exclusive or asynchronous with each other in a design so that the paths
between these clocks are not considered during the timing analysis.
SYNTAX
Boolean set_clock_groups
[-group <clock_list>]
[-exclusive]
[-physically_exclusive]
[-logically_exclusive]
[-asynchronous]
[-allow_paths]
[-name <name>]
Data Type
clock_list list
name list
comment string
ARGUMENTS
-group <clock_list>
Specifies a list of clocks. This option can be used more than once in a single command execution. Each -
group specifies a group of clocks, which are exclusive or asynchronous with the clocks in all other groups.
If only one group is specified, then the clocks in that group are exclusive or asynchronous with all other
clocks in the design. A default other group is created for this single group.
-exclusive
Specifies logically exclusive clock groups.
-physically_exclusive
Specifies that the clock groups are physically exclusive with each other. Physically exclusive clocks
cannot co-exist in the design physically. The -physically_exclusive, -logically_exclusive and -
asynchronous options are mutually exclusive.
-logically_exclusive
Logically exclusive clocks do not have any functional paths between them, but may have coupling
interactions with each other. The -physically_exclusive, -logically_exclusive and -asynchronous options
are mutually exclusive.
-asynchronous
Specifies that the clock groups are asynchronous to each other. Two clocks are asynchronous
with respect to each other if they have no phase relationship at all. The -physically_exclusive, -
logically_exclusive and -asynchronous options are mutually exclusive.
-allow_paths

Enables the timing analysis between specified asynchronous clock groups. By default, the timing
paths between asynchronous clocks are suppressed. If -allow_paths option is used, then -asynchronous
option is required.
-name <name>
Specifies a name for the clock grouping to be created. Each command should specify a unique name,
which identifies the exclusive or asynchronous relationship among specified clock groups. By default,
the command creates a unique name.
-comment <comment>
Associates a string description with the command for tracking purpose. For example, this is useful
when writing out SDC to a tag.
DESCRIPTION
The set_clock_groups command specifies clock groups that are mutually exclusive or asynchronous with
each other in a design so that the paths between these clocks are not considered during the timing analysis.
These relationships also indicate the type of crosstalk analysis which should be performed between the
clocks. A clock cannot be present in mutiple groups for a single set_clock_groups command. However,
multiple set_clock_groups commands can be specified with the same clock included in mutiple groups. Clock
relationships are implied across specified clock groups; relationships can't exist across clocks within a single
group.
Timing paths between the clocks are suppressed for all three relationships.
EXAMPLES
• Example-1 :
prompt> set_clock_groups -asynchronous -group {clk1 clk2} -group {clk3}
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_clock_groups
report_clock
set_false_path
create_clock
set_active_clocks

RELATED VARIABLES

set_clock_latency
Specifies latency of clock network.
SYNTAX
string set_clock_latency
[-clock <clock_list>]
[-rise] [-fall]
[-min] [-max]
[-source]
[-late] [-early]
[-dynamic <dynamic_component_of_delay>]
[-pll_shift]
<delay>
<ref_objects>
Data Type
clock_list list
dynamic_component_of_delay float
delay float
ref_objects list
ARGUMENTS
-clock <clock_list>
Specifies a list of clock objects associated with the network latency placed on all pins/ports provided by
the <ref_objects>. -clock option is irrelevant in case -clock is specified when the <ref_objects> includes
clock objects. A warning is issued in such a situation and execution of the command proceeds ignoring
the -clock option.
-rise
Specifies clock rise latency.
-fall
Specifies clock fall latency.
-min
Specifies clock latency for the minimum operating condition.
-max
Specifies clock latency for the maximum operating condition.
-source
Specifies clock source latency.
-late
Specifies clock late source latency.
-early
Specifies clock early source latency.

-dynamic <dynamic_component_of_delay>
Specifies dynamic component of clock latency value.
-pll_shift
Specifies that latencies correspond to PLL shifts. This option applies only to PLL output clocks.
<delay>
Specifies clock latency value.
<ref_objects>
List of clocks, ports or pins.
EXAMPLES
• Example-1 :
prompt> set_clock_latency 0.5 [get_clocks clk1]
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_clock_latency
report_clock
RELATED VARIABLES

set_clock_sense
Specifies unateness propagating forward for pins with respect to clock source.
SYNTAX
string set_clock_sense
[-positive]
[-negative]
[-stop_propagation]
[-logical_stop_propagation]
[-pulse <pulse_type>]
[-clocks <clock_list>]
<ref_objects>
Data Type
clock_list list
ref_objects list
ARGUMENTS
-positive
Specifies positive unateness applied to all pins in the <ref_objects> with respect to clock source. The -
positive option is mutually exclusive with -negative and -pulse option.
-negative
Specifies negative unateness applied to all pins in the <ref_objects> with respect to clock source. The
-negative option is mutually exclusive with -positive and -pulse option.
-stop_propagation
Stops the propagation of specified clocks given in the <clock_list> from the specified pins or cell
timing arcs in the <ref_objects>. Both clock as clock and clock as data propagtion is stopped. The -
stop_propagation option is mutually exclusive with -positive, -negative and -pulse options.
-logical_stop_propagation
Stops the propagation of specified clocks as clock from the specified pins or cell timing arcs in
the <ref_objects>. Only the propagation of clocks as clock is stopped; clock as data is allowed to
propagate. The -logical_stop_propagation option is mutually exclusive with -positive, -negative and -
pulse options.
-pulse <pulse_type>
Specifies the type of pulse clock applied to all pins in the <ref_objects> with respect to clock
source. Valid <pulse_type> values are 'rise_triggered_high_pulse', 'fall_triggered_high_pulse',
'rise_triggered_low_pulse', and 'fall_triggered_low_pulse', you must use only one. The -pulse option
cannot be specified with -positive or -negative options.
-clocks <clock_list>
Specifies a list of pins or cell timing arcs with specified unateness to propagate. The timing arcs object
is specified with -stop_propagation and -logical_stop_propagation only.
<ref_objects>

List of pins or cell timing arcs with specified unateness to propagate. The timing arcs object is valid
only with -stop_propagation and -logical_stop_propagation options.
DESCRIPTION
Set_clock_sense command allows the user to control the unateness at pin with respect to clock source. The
specifies unateness applies only within the non-unate clock network.
Use remove_clock_sense command to undo the set_clock_sense command.

EXAMPLES
• Example-1 :
prompt> set_clock_sense -stop_propagation -clocks clk1 [get_pins pin1]
SDC VERSION SUPPORT

Command Options
Support V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9
set_clock_sense Y -- -- -- -- Y Y Y
<object_list> Y -- -- -- -- Y Y Y
-stop_propagation Y -- -- -- -- Y Y Y
-logical_stop_propagation Y -- -- -- -- -- -- --
-positive Y -- -- -- -- Y Y Y
-negative Y -- -- -- -- Y Y Y
-pulse <pulse_type> Y -- -- -- -- Y Y Y
-clocks <clock_list> Y -- -- -- -- Y Y Y
RELATED RULE CHECKS
RELATED COMMANDS
configure_commands
configure_command_arguments
current_design
current_instance
remove_clock_sense
RELATED VARIABLES
ri_synth_generate_naming_style
ri_synth_generate_separator_style
ri_spec_cmd_with_unknown_option

Specifies the uncertainty (skew) of specified clock networks.
SYNTAX
string set_clock_uncertainty
<ref_objects> |
-from <from_clock>
| -rise_from <rise_from_clock>
| -fall_from <fall_from_clock>
-to <to_clock>
| -rise_to <rise_to_clock>
| -fall_to <fall_to_clock>
[-rise]
[-fall]
[-setup]
[-hold]
<uncertainty>
Data Type
from_clock list
rise_from_clock list
fall_from_clock list
to_clock list
rise_to_clock list
fall_to_clock list
ref_objects list
uncertainty float
ARGUMENTS
<ref_objects>
Specify design objects in clock network
-from <from_clock> -to <to_clock>

Specifies a name for the group. If a group with the same name already exists, the paths or endpoints
are added to the existing group. A new group is created for each unique <group_name>. The -name
and the -default options are mutually exclusive. However, the -name option must be specified in the
absence of -default option.
-rise_from <rise_from_clock>
If this option is used, then the endpoints or paths are moved to the default group and are removed from
the current group. he -name and the -default options are mutually exclusive. However, the -default
option must be specified in the absence of -name option.
-fall_from <fall_from_clock>
Specifies a cost function weight for the group. The <weight_value> must be lie between 0.0 and 100.0.
The default value is 1.0. A <weight_value> of 0.0 eliminates the paths in this group from cost function

calculations. If the -weight option is specified while adding members to the existing group, then the
new <weight_value> is used for the updated group.
-rise_to <rise_to_clock>
-fall_to <fall_to_clock>
-rise
Indicates that uncertainty applies to only the rising edge of the destination clock. The uncertainty
applies to both rising and falling edges by default. This option is now obsolete and may be used if
needed for backward compatibility. Otherwise, use -rise_to option for all cases.
-fall
Indicates that uncertainty applies to only the falling edge of the destination clock. The uncertainty
applies to both rising and falling edges by default. This option is now obsolete and may be used if
needed for backward compatibility. Otherwise, use -fall_to option for all cases.
-setup
Indicates that uncertainty applies only to setup checks. The uncertainty applies both to setup and hold
checks by default.
-hold
Indicates that uncertainty applies only to hold checks. The uncertainty applies both to setup and hold
checks by default.
<uncertainty>
Specifies the uncertainty value. Clock uncertainty should be positive typically. Negative uncertainty
values may be supported for constraining designs with complex clock relationships.
DESCRIPTION
The set_clock_uncertainty command specifies the clock uncertainty (skew characteristics) of specified clock
networks. It can specify either simple or interclock uncertainty. Options -from/-rise_from/-fall_from and -to/-
rise_to/-fall_to are used to specify the source and destination clock for interclock uncertainty.
EXAMPLES
• Example-1 :
prompt> set_clock_uncertainty 0.4 -from clk1-to clk2
SDC VERSION SUPPORT

RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_clock_uncertainty
report_clock
set_clock_latency
timing_propagate_interclock_uncertainty
RELATED VARIABLES

set_data_check
Sets the data-to-data checks using the specified values of setup and hold time.
SYNTAX
string set_data_check
{-from <from_object>
| -rise_from <from_object>
| -fall_from <from_object>}
{-to <to_object>
| -rise_to <to_object>
| -fall_to <to_object>}
[-setup | -hold]
[-clock <clock_object>]
<check_value>
Data Type
from_object object
to_object object
clock_object object
check_value float
ARGUMENTS
-from <from_object>
Specifies a pin or port in the current design as the related pin of the data-to-data check to be set. Both
rising and falling delays are checked. -from, -rise_from and -fall_from are mutually exclusive options
and only one of them can be specified.
-rise_from <from_object>
This option is similar to -from, but applies only to rising delays at the related pin. -from, -rise_from
and -fall_from are mutually exclusive options and only one of them can be specified in a command.
-fall_from <from_object>
This option is similar to -from, but applies only to falling delays at the related pin. -from, -rise_from
and -fall_from are mutually exclusive options and only one of them can be specified in a command.
-to <to_object>
Specifies a pin or port in the current design as the constrained pin of the data-to-data check to be set.
Both rising and falling delays are checked. -to, -rise_to and -fall_to are mutually exclusive options and
only one of them can be specified.
-rise_to <to_object>
This option is similar to -to, but applies only to rising delays at the constrained pin. -to, -rise_to and -
fall_to are mutually exclusive options and only one of them can be specified in a command.
-fall_to <to_object>
This option is similar to -to, but applies only to falling delays at the constrained pin. -to, -rise_to and -
fall_to are mutually exclusive options and only one of them can be specified in a command.

-setup
Indicates that the data check value is for setup analysis only. The value applies both to setup and hold
analysis by default.
-hold
Indicates that the data check value is for hold analysis only. The value applies both to setup and hold
analysis by default.
-clock <clock_object>
<check_value>
Specifies the value of the setup and/or hold time for the check.
DESCRIPTION
The set_data_check command specifies a data-to-data check to be performed between the from obejct and
to object using the specified setup and/or hold time value.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
create_clock
current_design
remove_path_group
report_constraint
report_path_group
reset_design
set_input_delay
set_output_delay
RELATED VARIABLES

set_disable_timing
Disables timing arcs in a circuit.
SYNTAX
string set_disable_timing
[-from <from_pin_name> -to <to_pin_name>]
<ref_objects>
Data Type
from_pin_name string
to_pin_name string
ref_objects list
ARGUMENTS
-from <from_pin_name>
Specifies that arcs only from this pin on the specified cell are disabled. The from_pin_name must be a
valid library pin name corresponding to the cell in the <ref_objects>. The <ref_objects> must contain
only cells. It is necessary to specify the -from and -to options together. Only the arcs between the two
pins specified by -from and -to are disabled.
-to <to_pin_name>
Specifies that arcs only to this pin on the specified cell are disabled. The from_pin_name must be a
valid library pin name corresponding to the cell in the <ref_objects>. The <ref_objects> must contain
only cells. It is necessary to specify the -from and -to options together. Only the arcs between the two
pins specified by -from and -to are disabled.
<ref_objects>
Specifies a list of pins, ports, cells, libcells, libpins, timing arcs that are disabled. This list can include
library objects.
DESCRIPTION
The set_disable_timing command disables timing through the specified cells, pins, ports or timing arcs in the
current_design.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.

RELATED COMMANDS
remove_disable_timing
report_disable_timing
report_timing
reset_design
get_timing_arcs
report_lib
RELATED VARIABLES

set_false_path
Identifies paths in the design that are to be marked as false, so that they are not considered during timing analysis.
SYNTAX
Boolean set_false_path
[-setup]
[-hold]
[-rise]
[-fall]
[-reset_path]
[-from <from_list>]
[-to <to_list>]
Data Type
from_list list
rise_from_list list
fall_from_list list
through_list list
to_list list
rise_to_list list
fall_to_list list
comment string
ARGUMENTS
-setup
Indicates that the setup (maximum) paths are to be marked as false. This option disables setup
checking for specified paths. Both setup and hold timing are marked as false by default if neither -
setup nor -hold option is specified.
-hold
Indicates that the hold (minimum) paths are to be marked as false. This option disables hold checking
for specified paths. Both setup and hold timing are marked as false by default if neither -setup nor -
hold option is specified.
-rise
Indicates that rising delays are to be marked as false, as measured on the path endpoint. Both rise and
fall timing are marked false if neither -rise nor -fall option is specified.

-fall
Indicates that falling delays are to be marked as false, as measured on the path endpoint. Both rise and
fall timing are marked false if neither -rise nor -fall option is specified.
-reset_path
Indicates that existing point-to-point exception information is to be removed from the specified paths.
If used with only the -to option, all paths leading to the specified endpoints are reset. If used with only
the -from option, all paths leading from the specified startpoints are reset. If used with -from and -to
options, only paths between the points mentioned are reset.
-from <from_list>
Specifies a list of pins, ports, cells or nets through which the disabled paths must pass. If -through
option is not specified, all timing paths specified using the -from and -to options are affected. -
through, -rise_through, -fall_through options can be used multiple times in a single command to
specify paths that traverse multiple points in the design. The order in which the points are specified is
preserved.
It is similar to -through option, but applies only to paths with a rising transition at the through points.
It is similar to -through option, but applies only to paths with a falling transition at the through points.
-to <to_list>

-comment <comment>
DESCRIPTION
The set_false_path command identifies startpoint/endpoint pairs as false timing paths, i.e. paths that can't
propagate a signal. The command removes timing constraints on these 'false' paths, so that they are not
considered during timing analysis. Path startpoints are input ports or register clock pins; path endpoints are
output ports or register data pins. The command disables maximum delay (setup) and minimum delay (hold)
checking for the specified paths.
False path information always has higher priority over mutlicycle path information.
Set_disable_timing command can be used to disable the timing at a particular cell along the path. Use
reset_path to remove the false path designations set by the set_false_path command.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
current_design
reset_design
reset_path
set_disable_timing
set_max_delay
set_min_delay
set_multicycle_path
set_clock_groups

RELATED VARIABLES

set_ideal_latency
Specifies ideal latency values for the pins in an ideal network.
SYNTAX
int set_ideal_latency
[-rise] [-fall]
[-min] [-max]
<latency_value>
<ref_objects>
Data Type
latency_value float
ref_objects list
ARGUMENTS
-rise
Indicates that the <latency_value> represents the rise latency time. If -rise or -fall options are not
specified, both values are set by default.
-fall
Indicates that the <latency_value> represents the fall latency time. If -rise or -fall options are not
-min
Indicates that the <latency_value> represents the minimum latency time. If -min or -max options are
not specified, both values are set by default.
-max
Indicates that the <latency_value> represents the maximum latency time. If -min or -max options are
not specified, both values are set by default.
<latency_value>
Specifies an ideal latency value on leaf cell pins or top level ports in an ideal network.
<ref_objects>
Specifies a list of leaf cell pins and top level ports on which ideal latency is set.
DESCRIPTION
The set_ideal_latency command sets an ideal latency value on leaf cell pins and top level ports of an ideal
network.
SDC VERSION SUPPORT

RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_ideal_latency
remove_ideal_network
remove_ideal_transition
report_ideal_network
report_timing
set_ideal_network
set_ideal_transition
RELATED VARIABLES

set_ideal_network
Specifies a set of ports or pins in the design as sources of an ideal network. This disables timing update of cells and
nets in the transitive fanout of the specified objects.
SYNTAX
int set_ideal_network
[-no_propagate]
<ref_objects>
Data Type
ref_objects list
ARGUMENTS
-no_propagate
Indicates that the ideal network is not propagated through leaf cells. Ideal properties are enabled on all
nets that are electrically connected to the ideal network sources.
<ref_objects>
Specifies a list of ideal network source objects. These may be ports or pins of leaf cells at any
hierarchical level of the design. If nets are specifies in the <ref_objects>, all of the nets' global
driver pins are marked as ideal network sources. It is required to specify -no_propagate option if
<ref_obejcts> contains nets.
DESCRIPTION
The set_ideal_network command specifies a set of ports or pins in the design as sources of an ideal network.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
reset_design
set_ideal_latency

RELATED VARIABLES

Specifies ideal transition values for the pins in an ideal network.
SYNTAX
int set_ideal_transition
[-rise] [-fall]
[-min] [-max]
<transition_value>
<ref_objects>
Data Type
transition_value float
ref_objects list
ARGUMENTS
-rise
Indicates that the <transition_value> represents the rise transition time. If -rise or -fall options are not
-fall
Indicates that the <transition_value> represents the fall transition time. If -rise or -fall options are not
-min
Indicates that the <transition_value> represents the minimum transition time. If -min or -max options
are not specified, both values are set by default.
-max
Indicates that the <transition_value> represents the maximum transition time. If -min or -max options
are not specified, both values are set by default.
<transition_value>
Specifies an ideal transition value on leaf cell pins or top level ports in an ideal network.
<ref_objects>
Specifies a list of leaf cell pins and top level ports on which ideal transition is set.
DESCRIPTION
The set_ideal_transition command sets an ideal transition value on leaf cell pins and top level ports of an
ideal network.
SDC VERSION SUPPORT

RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_ideal_latency
remove_ideal_transition
report_timing
set_ideal_network
set_ideal_network
RELATED VARIABLES

set_input_delay
Specifies the arrival time relative to a clock.
SYNTAX
string set_input_delay
[-reference_pin <pin_port_name>]
[-clock_fall]
[-level_sensitive]
[-rise]
[-fall]
[-max]
[-min]
[-add_delay]
[-network_latency_included]
[-source_latency_included]
<delay_value>
<ref_objects>
Data Type
clock_name list
pin_port_name list
delay_value float
ref_objects list
ARGUMENTS
-clock <clock_name>
Specifies the name of a clock to which the specified delay is related.
-reference_pin <pin_port_name>
Specifies the clock, pin or port to which the specified delay is related. If propagated clocking is used
along with this option, then the delay value is related to the arrival time at the specified reference
pin, which is clock source latency plus its network latency from the clock source to this reference
pin. The -network_latency_included and -source_latency_included options are exclusive with the -
reference_pin option i.e. -network_latency_included or -source_latency_included options can't be
used with the -reference_pin option. For ideal clock network, only source latency is applied.
The pin specified with the -reference_pin option should be a leaf pin or port in a clock network, and
in the direct or transitive fanout of a clock source specified with the -clock option. If multiple clocks
reach the port or pin where you are setting the input delay, and if the -clock option is not used, the
command considers all of the clocks.
-clock_fall
Indicates that the delay is relative to the falling edge of the clock. If you specify the -clock_fall with
the -reference_pin option, the delay is relative to the falling transition of the reference pin. If the -
clock option is specified, the default is the rising edge or the rising transition of the reference pin.If
the -clock_fall option is specified, the -clock option must be specified too.
-level_sensitive

Indicates that the destination of the delay is a level-sensitive latch.This allows the tool to derive a
setup and hold relationship for paths to this port as if it were a level-sensitive latch. The output delay
is treated as if it were a path to a flip-flop by default.
-rise
Indicates that the <delay_value> option refers to a rising transition on specified ports of the current
design. Rising and falling delays are assumed to be equal by default.
-fall
Indicates that the <delay_value> option refers to a falling transition on specified ports of the current
-max
Indicates that the <delay_value> option refers to the longest path. Maximum and minimum output
delays are assumed to be equal by default.
-min
Indicates that the <delay_value> option refers to the shortest path. Maximum and minimum output
-add_delay
Indicates that delay information is added to the existing output delay, instead of overwriting the
output delay. By using the -add_delay option, it is possible to capture information about multiple
paths leading from an output port associated with different clocks or clock edges.
-network_latency_included
This option is used to exclude the clock network latency from the output delay value. If this option is
not specified, the clock network latency of the related clock is added to the output delay value. It has
no effect if the clock is propagated or the output delay is not specified with respect to any clock.
-source_latency_included
This option is used to exclude the clock source latency from the output delay value.. If this option is
not specified, the clock source latency of the related clock is added to the output delay value. It has
no effect if the output delay is not specified with respect to any clock.
-group_path <group_name>
Specifies the name of a group into which paths ending at the specified ports or pins are added. If
the group does not already exist, one is created. If the -group_path option of the set_output_delay
command is not specified, the existing path grouping does not change.
<delay_value>
Specifies the path delay in library units.The <delay_value> option represents the amount of time
before a clock edge that the signal is required. For maximum output delay, this represents a
combinational path delay to a register plus the library setup time of that register. For minimum output
delay, this value is usually the shortest path delay to a register minus the library hold time.
<ref_objects>
Specifies a list of output port or internal pin names in the current design to which the <delay_value>
option is assigned. If more than one object is specified, the objects are enclosed in braces ({}).
DESCRIPTION
Set_input_delay command sets input path delay values for the current design. The input and output
delays characterize the operating environment of the current design when used with the set_load

and set_driving_cell commands. The set_input_delay command sets input path delays on input ports
relative to a clock edge. Input ports have no input delay unless specified. For inout ports, the path
delays for both input and output modes can be specified.
The -level_sensitive option is used to describe a path delay to a level-sensitive latch. If the latch is
positive-enabled, the input delay is set relative to the rising clock edge; if it is negative-enabled, the
input delay is set relative to the falling clock edge. If time is borrowed at that latch, subtract that
time from the path delay to the latch when determining input delay.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
set_clock_latency
remove_propagated_clock
report_clock
RELATED VARIABLES

set_max_delay
Specifies a maximum delay for timing paths.
SYNTAX
Boolean set_max_delay
[-rise]
[-fall]
[-reset_path]
[-from <from_list>]
[-to <to_list>]
<delay_value>
Data Type
from_list list
rise_from_list list
fall_from_list list
through_list list
to_list list
rise_to_list list
fall_to_list list
delay_value float
comment string
ARGUMENTS
-rise
Indicates that only rising path delays are to be constrained. Both rising and falling delays are constrained
if neither -rise nor -fall option is specified.
-fall
Indicates that only falling path delays are to be constrained. Both rising and falling delays are constrained
if neither -rise nor -fall option is specified.
-reset_path
If used with the -to option only, all paths leading to the specified endpoints are reset. If used with the

-from option only, all paths leading from the specified startpoints are reset. If used with the -from and
-to options, only paths between the points mentioned are reset.
-from <from_list>
preserved.
-to <to_list>

<delay_value>
Specifies the maximum delay value for specified paths. The <delay_value> must have the same units
as the technology library used during analysis. If a path startpoint is on a sequential device, clock
skew is included in the delay value computation. If a path startpoint has an input delay specified, the
delay value is added to the path delay. If a path endpoint is on a sequential device, clock skew and
library setup time are included in the computed delay. If the endpoint has an output delay specified,
that delay is added to the path delay.
-comment <comment>
DESCRIPTION
The set_max_delay command specifies a maximum delay for timing paths in the current design.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
current_design
reset_design
reset_path
set_disable_timing
set_max_delay
set_min_delay
set_multicycle_path
set_clock_groups
RELATED VARIABLES

set_max_time_borrow
Specifies the time borrowing limit for latches.
SYNTAX
string set_max_time_borrow
<value>
<ref_objects>
Data Type
value float
ref_objects list
ARGUMENTS
<value>
Specifies the maximum time borrow value. It defines the desired limit of time borrowing on the
latches specified by the <ref_objects>. By default, the maximum <value> is derived from the ideal
clock waveform driving each latch and is equal to (closing edge - open edge). Library setup and data-
to-Q propagation times are taken into account. The units of <value> are the same as the technology
library used during analysis.
<ref_objects>
Specifies a list of objects in the current_design for which the time borrowing limit has to be applied
to. The valis objects are clocks, latch cells, data pins, or clock (enable) pins. If a cell is specified, all
enabled pins on that cell are affected.
DESCRIPTION
The set_max_time_borrow constrains the amount of time borrowing possible for level sensitive latches. The
command prevents automatic use of all or part of the enabling clock pulse on a latch to meet delay targets.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
current_design
remove_max_time_borrow
get_attribute
report_exceptions

RELATED VARIABLES

set_min_delay
Specifies a minimum delay for timing paths.
SYNTAX
Boolean set_min_delay
[-rise]
[-fall]
[-reset_path]
[-from <from_list>
| -rise_from <rise_from_list>
| -fall_from <fall_from_list>]
[-to <to_list>
| -rise_to <rise_to_list>
| -fall_to <fall_to_list>]
<delay_value>
Data Type
from_list list
rise_from_list list
fall_from_list list
through_list list
to_list list
rise_to_list list
fall_to_list list
delay_value float
comment string
ARGUMENTS
-rise
Indicates that only rising path delays are to be constrained. If neither -rise nor -fall option is specified,
both rising and falling delays are constrained.
-fall
Indicates that only falling path delays are to be constrained. If neither -rise nor -fall option is specified,
both rising and falling delays are constrained.
-reset_path

-from <from_list>
preserved.
-to <to_list>

<delay_value>
Specifies the minimum delay value for specified paths. The <delay_value> must have the same units as
the technology library used during analysis. If a path startpoint is on a sequential device, clock skew
is included in the delay value computation. If a path startpoint has an input delay specified, the delay
value is added to the path delay. If a path endpoint is on a sequential device, clock skew and library
setup time are included in the computed delay. If the endpoint has an output delay specified, that
delay is added to the path delay.
-comment <comment>
DESCRIPTION
The set_min_delay command specifies a minimum delay for timing paths in the current design. The path
length for any startpoint in <from_list> to any endpoint in <to_list> must be greater than the <delay_value>.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
current_design
reset_design
reset_path
set_disable_timing
set_max_delay
set_min_delay
set_multicycle_path
set_clock_groups
RELATED VARIABLES

set_min_pulse_width
Specifies the minimum required pulse width for a clock or clock pin in the clock network.
SYNTAX
string set_min_pulse_width
[-high]
[-low]
<value>
<ref_objects>
Data Type
setup_value float
hold_value float
ref_objects list
ARGUMENTS
-high
Indicates that the check is performed on the high level of the clock. By default, the tool determined
-low
<value>
<ref_objects>
Specifies a list of objects in the current design for which the clock gating check is applied. The objects
can be clocks, pins, or cells. If a cell is specified, all input pins of that cell are affected. If a pin or cell is
specified, any clock gating checks located at the specified objects are affected. If a clock is specified,
the clock gating check is applied to all gates driven by that clock. <ref_objects> must be is specifies,
if -high or -low option is specified; however, <ref_objects> must not contain a clock. By default, if the
<ref_objects> is not specified, the clock gating check is applied to the current design.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_clock_gating_check
reset_design
current_design
report_constraint
report_clock_gating_check
timing_clock_gating_check_fanout_compatibility
RELATED VARIABLES

set_multicycle_path
Defines the multicycle path.
SYNTAX
Boolean set_multicycle_path
[-setup]
[-hold]
[-rise]
[-fall]
[-start]
[-end]
[-reset_path]
[-from <from_list>]
[-to <to_list>]
<path_multiplier>
Data Type
from_list list
rise_from_list list
fall_from_list list
through_list list
to_list list
rise_to_list list
fall_to_list list
path_multiplier integer
comment string
ARGUMENTS
-setup
Indicates that the <path_multiplier> value is included in the setup (maximum delay) calculations.
Altering the <path_multiplier> for setup affects the hold check too. If neither -setup nor -hold option
is specified, <path_multiplier> is used for setup calculations and 0 for hold calculations.
-hold

Indicates that the <path_multiplier> value is included in the hold (minimum delay) calculations.
Altering the <path_multiplier> for setup affects the default hold check too. If neither -setup nor -hold
option is specified, <path_multiplier> is used for setup calculations and 0 for hold calculations.
-rise
Indicates that only rising path delays are to use <path_multiplier>. If neither -rise nor -fall option is
specified, both rising and falling delays are affected. Rise refers to rising value at the path endpoint.
-fall
Indicates that only falling path delays are to use <path_multiplier>. If neither -rise nor -fall option is
specified, both rising and falling delays are affected. Fall refers to falling value at the path endpoint.
-start
Indicates that the multicycle information is relative to the period of the start clock. The -start and -end
options are only required for multifrequency designs. They are equivalent otherwise.
-end
Indicates that the multicycle information is relative to the period of the end clock.
-reset_path
-from <from_list>
preserved.

-to <to_list>
<path_multiplier>
Specifies the number of cycles the datapath must have for setup or hold, relative to startpoint and
endpoint clock, before the data is required at the endpoint.
If -setup option is given, <path_multiplier> is used in setup path calculations.
If -hold option is given, <path_multiplier> is used in hold path calculations.
If neither -setup nor -hold option is specified, <path_multiplier> is used for setup and 0 is used for
hold calculations.
-comment <comment>
DESCRIPTION
The set_multicycle_path command specifies the number of cycles for a timing path.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.

RELATED COMMANDS
current_design
reset_design
reset_path
report_exceptions
set_false_path
set_max_delay
set_min_delay
RELATED VARIABLES

set_output_delay
Sets the output path delay values for the current design.
SYNTAX
string set_output_delay
[-reference_pin <pin_port_name>]
[-clock_fall]
[-level_sensitive]
[-rise]
[-fall]
[-max]
[-min]
[-add_delay]
[-network_latency_included]
[-source_latency_included]
[-group_path <group_name>]
<delay_value>
<ref_objects>
Data Type
clock_name list
pin_port_name list
group_name string
delay_value float
ref_objects list
ARGUMENTS
-clock <clock_name>
Specifies the name of a clock to which the specified delay is related. If -clock_fall option is specified,
then the -clock option should also be stated.
-reference_pin <pin_port_name>
Specifies the clock, pin or port to which the specified delay is related. If propagated clocking is used
along with this option, then the delay value is related to the arrival time at the specified reference
pin, which is clock source latency plus its network latency from the clock source to this reference
pin. The -network_latency_included and -source_latency_included options are exclusive with the -
reference_pin option i.e. -network_latency_included or -source_latency_included options can't be
used with the -reference_pin option. For ideal clock network, only source latency is applied. The
pin specified with the -reference_pin option should be a leaf pin or port in a clock network, and in
the direct or transitive fanout of a clock source specified with the -clock option. If multiple clocks
reach the port or pin where you are setting the input delay, and if the -clock option is not used, the
command considers all of the clocks.
-clock_fall
Indicates that the delay is relative to the falling edge of the clock. If you specify the -clock_fall with
the -reference_pin option, the delay is relative to the falling transition of the reference pin. If the -

clock option is specified, the default is the rising edge or the rising transition of the reference pin.If
the -clock_fall option is specified, the -clock option must be specified too.
-level_sensitive
Indicates that the destination of the delay is a level-sensitive latch.This allows the tool to derive a
setup and hold relationship for paths to this port as if it were a level-sensitive latch. The output delay
is treated as if it were a path to a flip-flop by default.
-rise
Indicates that the <delay_value> option refers to a rising transition on specified ports of the current
-fall
Indicates that the <delay_value> option refers to a falling transition on specified ports of the current
-max
Indicates that the <delay_value> option refers to the longest path. Maximum and minimum output
-min
Indicates that the <delay_value> option refers to the shortest path. Maximum and minimum output
-add_delay
Indicates that delay information is added to the existing output delay, instead of overwriting the
output delay. By using the -add_delay option, it is possible to capture information about multiple
paths leading from an output port associated with different clocks or clock edges.
-network_latency_included
This option is used to exclude the clock network latency from the output delay value. If this option is
not specified, the clock network latency of the related clock is added to the output delay value. It has
no effect if the clock is propagated or the output delay is not specified with respect to any clock.
-source_latency_included
This option is used to exclude the clock source latency from the output delay value.. If this option is
not specified, the clock source latency of the related clock is added to the output delay value. It has
no effect if the output delay is not specified with respect to any clock.
-group_path <group_name>
Specifies the name of a group into which paths ending at the specified ports or pins are added. If
the group does not already exist, one is created. If the -group_path option of the set_output_delay
command is not specified, the existing path grouping does not change.
<delay_value>
Specifies the path delay in library units.The <delay_value> option represents the amount of time
before a clock edge that the signal is required. For maximum output delay, this represents a
combinational path delay to a register plus the library setup time of that register. For minimum output
delay, this value is usually the shortest path delay to a register minus the library hold time.
<ref_objects>
Specifies a list of output port or internal pin names in the current design to which the <delay_value>
option is assigned. If more than one object is specified, the objects are enclosed in braces ({}).

DESCRIPTION
Set_output_delay command sets output path delay values for the current design. The input and
output delays characterize the operating environment of the current design when used with the
set_load and set_driving_cell commands. The set_output_delay command sets output path delays
on output ports relative to a clock edge. Output ports have no output delay unless specified. For inout
ports, the path delays for both input and output modes can be specified.
The -level_sensitive option is used to describe a path delay to a level-sensitive latch. If the latch is
positive-enabled, the output delay is set relative to the rising clock edge; if it is negative-enabled, the
output delay is set relative to the falling clock edge. If time is borrowed at that latch, subtract that
time from the path delay to the latch when determining output delay.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
remove_output_delay
current_design
group_path
report_design
report_timing
set_max_delay
all_outputs
create_clock
report_path_group
report_design
RELATED VARIABLES

Specifies the latency of the propagated clock.
SYNTAX
string set_propagated_clock
<object_list>
Data Type
object_list list
ARGUMENTS
<object_list>
Specifies a list of clocks, pins, or ports.
DESCRIPTION
The set_propagated_clock command is used to determine the latency at register clock pins by specifying
the delays to be propagated through the clock network. Ideal clocking is assumed in the absence of
set_propagated_clock command . In case of ideal clocking, the latency of the clock networks is defined by
the set_clock_latency command. The clock has zero latency by default. Propagated clock latency comes into
picture post-layout after the clock tree generation. The ideal clock latency povides an estimate of the clock
tree for pre-layout stage.
If the set_propagated_clock command is applied to pins or ports, it affects all register clock pins in the
transitive fanout of the pins or ports. If it is applied to an object (clock,port,or pin) on which network latency
is already defined, then a warning issued. If set_propagated_clock command is applied on a virtual clock, an
error is issued, as virtual clocks do not have any source, and they cannot affect any register in the design.
To undo the set_propagated_clock command, use either the remove_propagated_clock or set_clock_latency

command to provide an ideal latency. To see propagated clock attributes on clocks, use the report_clock
command.
SDC VERSION SUPPORT
RELATED RULE CHECKS

None.
RELATED COMMANDS
set_clock_latency
remove_propagated_clock
report_clock

RELATED VARIABLES

Environment Commands
This topic describes the commands that are used for setting up design environment.

set_case_analysis
Specifies that a port or pin is at a constant logic value 1 or 0, or is considered with a rising or falling transition.
status set_case_analysis
<value>
<port_or_pin_list>
Data Type
value string
port_or_pin_list list
ARGUMENTS
<value>
[Required] Specifies a constant logic value or a transition to assign to the given pin or port. The valid
constant values are 0, 1, zero, and one. The valid transition values are rising, falling, rise, and fall
<port_or_pin_list>
[Required] Lists ports or pins to which the case analysis is assigned. In the case of pins, constant
propagation is executed forward only. No backward constant propagation is performed.
DESCRIPTION
Case analysis is a way of specifying a given mode for the design without altering the netlist structure. You can
specify for the current analysis session, that some signals are at a constant value (1 or 0), or that only one type
of transition (rising or falling) is considered. Pins of a design may be driven by logic values from the design, but
if case analysis is used to set a value on such pins, the values set by case analysis will dominate. If the case
values are subsequently removed, the value driving the pin from the design will be propagated.
When case analysis is specified as a constant value, this value is propagated through the network as long as the
constant value is a controlling value for the traversed logic. For example, if you specify that one of the inputs
of a NAND gate is a constant value 0, it is propagated to the NAND output, which is now considered at a logic
constant 1. This propagated constant value is then propagated to all cells driven by this signal..
EXAMPLES
• Example-1 : The following example shows the port IN1 set to a logic value of 0
prompt> set_case_analysis 0 IN1
• Example-2 : The following example shows that the pins U1/U2/A and U1/U3/CI are considered only for a
rising transition. The falling transition on these pins is disabled.
prompt> set_case_analysis rising {U1/U2/A U1/U3/C}
RELATED RULE CHECKS

None.
RELATED COMMANDS

None
RELATED VARIABLES
None

set_drive
Sets the resistance to a specified value on specified input or inout ports in the current design.
status set_drive
[-rise] [-fall]
[-min] [-max]
<resistance_value>
<port_list>
Data Type
resistance_value float
port_list list
ARGUMENTS
-rise
[Optional] Indicates that resistance_value is to be used to drive the ports only for the rising case.
-fall
[Optional] Indicates that resistance_value is to be used to drive the ports only for the falling case.
-min
[Optional] Indicates that the resistance_value is the minimum resistance.
-max
[Optional] Indicates that the resistance_value is the maximum resistance.
<resistance_value>
[Required] Specifies a nonnegative port drive resistance value for the ports in port_list. The value
must be >= 0; units must be the same as those in the technology library.
<port_list>
[Required] Specifies a list of input or inout ports in the current design, on which the resistance_value
is to be set.
DESCRIPTION
Sets the resistance to a specified value on specified input or inout ports in the current design. There are two
other methods of describing port drive capability, the set_driving_cell command or the set_input_transition
command. The most recent drive command has precedence.
EXAMPLES
Example-1 : The following example sets the drive resistance to 5 on all input ports in the current design.
prompt> set_drive 5 [all_inputs]
Example-2 : The following example sets the rise drive resistance to on port B to 1.
prompt> set_drive 1 B
Example-3 : The following example sets the rise and fall drive resistance of ports A,B and C to 2.

prompt> set_drive 2 {A B C}
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_driving_cell
Sets the port driving cell
status set_driving_cell
[-lib_cell <lib_cell_name>]
[-rise][-fall]
[-min] [-max]
[-library <lib>]
[-pin <from_pin>]
[-from_pin <from_pin_name>]
[-multiply_by <factor>]
[-dont_scale]
[-no_design_rule]
[-input_transition_rise <rtrans>]
[-input_transition_fall <ftrans>]
[-clock_fall]
<port_list>
Data Type
lib_cell_name string
lib string
from_pin string
from_pin_name string
factor integer
rtrans float
ftrans float
clock_name string or collection
port_list list or collection
ARGUMENTS
-lib_cell <lib_cell_name>
[Required] Specifies the name of the library cell used to drive the ports. You must use the -pin option
if the cell has more than one output pin. If different cells are needed for the rising and the falling
cases, use separate commands with the -rise or -fall option. Use the -from_pin option to choose
between multiple input pins with arcs to this output pin.
-rise
[Optional] Specifies driving cell information for the rising transition.
-fall
[Optional] Specifies driving cell information for the fallng transition.
-library <lib>
Specifies the name of the library containing the lib_cell_name value This is the library of the driving
cell. By default, the libraries in link_library are searched for the cell.
-min

Specifies driving cell information for only the minimum analysis. This option is only valid in min-max
analysis
-max
Specifies driving cell information for only the maximum analysis. This option is valid even when not in
min-max mode. When not in min-max mode, the option is not required because it is the default.
-pin <pin_name>
Specifies the output pin whose drive is used. This is the driving pin name. If you do not include the -
from_pin option, the command uses an arbitrary pin arc ending at the specified pin.
-from_pin <from_pin_name>
Specifies an input pin on the specified cell so the command uses the drive of the timing arc from this
pin to the specified pin.
-multiply_by <factor>
Multiplies the calculated transition time by the specified multiplier. The valid transition multiplier
range is greater than or equal to 0.
-dont_scale
Prevents operating condition scaling. By default, the port drive capability is scaled for operating
conditions exactly as the driving cell itself would have been scaled.
-no_design_rule
Specifies not to transfer design rules from the driving cell to the port. If you do not include this
option, the design rules (such as max_capacitance) of the library pin are applied to the port.
-input_transition_rise <rtran>
Specifies the input rising transition time associated with the -from_pin option. If you do not include
this option, the default value is 0. Use the -
input_transition_rise and -input_transition_fall options to capture the accurate transition time
associated with the from_pin_name value.
-input_transition_fall <ftran>
Specifies the input falling transition time associated with the from_pin_name value. If you do not
include this option, the default value is 0.
-clock clock_name
The driving cell is set relative the specified clock.
-clock_fall
Specifies that driving cell is relative to the falling edge of the clock. The default is the rising edge.
<port_list>
Provides a list of input ports. The list contains input or inout port names in the current design on
which the driving cell information is set.
DESCRIPTION
Sets the port driving cell. Sets attributes on the specified input or inout ports in the current design to
associate an external driving cell with the ports. The drive capability of the port is the same as if the specified
driving cell were connected in the same context to allow accurate modeling of port drive capability for
nonlinear delay models. If you do not include the -dont_scale option, the drive capability of the port is scaled
according to the current operating conditions.

The driving cell can be relative to a clock by using -clock option. This means the driving cell apply only to
those external paths driven by the clock. Using -clock or -clock_fall option can be meaningful only when
timing_slew_propagation_mode is in worst_arrival mode. Note if it is in worst_slew mode, there must be a
driving cell without any clock specified to see any driving cell on the port.
EXAMPLES
Example-1 : The following example sets the cell AND as the driver of block port A.
prompt> set_driving_cell -lib_cell AND [get_ports A]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_fanout_load
Sets fanout_load for output ports in current design.
status set_fanout_load
<value>
<port_list>
Data Type
value float
port_list list of output ports
ARGUMENTS
<value>
[Required] Specifies a nonnegative load value for the ports in port_list. The value must be >= 0; units
must be the same as those in the
technology library.
<port_list>
[Required] Specifies a list of output ports in current design, on which the value is to be set.
DESCRIPTION
Specifies a fanout_load for output ports in the current design. By default, ports are considered to have
fanout_load of 0.0. Fanout load for a net is the sum of fanout_load attributes for all input pins and output
ports connected to the net. Output pins may have maximum fanout limits, specified in the library or with the
set_max_fanout command
EXAMPLES
Example-1 : The following example sets a fanout_load of 2 on all output ports in the current design.
prompt> set_fanout_load 2 [all_outputs]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_input_transition
Sets a fixed transition time on inputs or inout ports
status set_input_transition
[-rise] [-fall]
[-min] [-max]
[-clock <clock_name>] [-clock_fall]
<transition_value>
<port_list>
Data Type
port_list list of input or inout

ports
ARGUMENTS
-rise
[Optional] Specifies rising transition for all the selected ports.
-fall
[Optional] Specifies falling transition for all the selected ports.
-min
[Optional] Specifies transition for minimum conditions.
-max
[Optional] Specifies transition for maximum conditions.
-clock <clock_name>
[Optional] The input transition is set relative to the specified clock.
-clock_fall
[Optional] Specifies that the transition is relative to the falling edge of the clock.
<transition_value>
[Required] Transition value. The value must be >= 0; units must be the same as those in the technology
library.
<object_list>
[Required] Provides a list of input or inout ports on which to set transition.
DESCRIPTION
The set_input_transition command specifies a fixed transition time for a list of input or inout ports. This
transition time is not affected by the capacitance of the net connected to the port. The transition time
calculates delays for nets and cells in the transitive fanout of the port. The port itself has no cell delay. The
transition time can be relative to a clock by using -clock option. This means the transition apply only those
external paths driven by the clock.
EXAMPLES

Example-1 : The following example sets a transition time of 0.75 in inputs IN*
prompt> set_input_transition 0.75 [get_ports IN*]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_load
Sets the capacitance to a specified value on specified nets and ports in the design
status set_load
[-min] [-max]
[-rise] [-fall]
[-subtract_pin_load]
[-pin_load][-wire_load]
<capacitance_value>
<net_list>
Data Type
capacitance_value float
net_list list of nets or ports
ARGUMENTS
-min
[Optional] Indicates that the capacitance_value is the minimum capacitance.
-max
[Optional] Indicates that the capacitance_value is the maximum capacitance.
-rise
[Optional] Indicates that the capacitance_value is the rise capacitance. This option can be used in
combination with -min or -max. Use this option only with ports. An error message is generated if the
objects list contains nets.
-fall
[Optional] Indicates that the capacitance_value is the fall capacitance. This option can be used in
combination with -min or -max. Use this option only with ports. An error message is generated if the
objects list contains nets.
-subtract_pin_load
Indicates that the current pin capacitances of the specified net are to be subtracted from
capacitance_value before the net capacitance value is set. Any resulting negative net capacitance
values are set to zero. Use this option only if capacitance includes pin capacitances.
-pin_load
Indicates that the specified capacitance is a pin capacitance. Use this option only with ports. An error
message is generated if the objects list contains nets. If you do not specify either the -pin_load or the
-wire_load option, or both, -pin_load is the default.
-wire_load
Indicates that the specified capacitance is a wire capacitance. Pin capacitance is subject to "scaling"
using tree_type. Use this option only with ports. An error message is generated if the objects list
contains nets. If you do not specify either the -pin_load or the -wire_load option, or both, -pin_load is
the default.
<capacitance_value>

[Required] Specifies a nonnegative capacitance value for the nets and ports in net_list. The value must
be >= 0; units must be the same as those in thetechnology library.
<net_list>
[Required] Specifies a list of nets and ports in the current design on which the capacitance_value is to
be set.
DESCRIPTION
This command sets the capacitance to a specified value on specified ports and nets in the current design. You
can also use the set_load command for nets at lower levels of the design hierarchy. These nets are specified
in the "BLOCK1/BLOCK2/NET_NAME" format. The tool treats capacitances in such a way that timing on a sub
block should be the same as timing on the higher-level design, since pin/wire caps on ports represent a part of
the higher-level design.
EXAMPLES
Example-1 : The following example sets the resistance to 5 on nets A and B
prompt> set_load 5 {A B}
Example-2 : The following example sets the resistance to on net U1/U2/B to 1

prompt> set_load 1 U1/U2/B
Example-3: The following example sets a total net capacitance (wire capacitance + pin capacitances) of 3 on
the U1/U2/NET3 net. If the pin and port capacitances equal 2, the wire capacitance is annotated with 1; if the
pin and port capacitances are 3 or more, the wire capacitance is annotated with 0.
prompt> set_load -subtract_pin_load 3 U1/U2/NET3
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_logic_dc
Specifies one or more input ports in the current design that are to be driven by don't case.
int set_logic_dc
<port_list>
Data Type
port_list list of input ports
ARGUMENTS
<port_list>
[Required] Lists ports in the current_design that are to be driven by don't care. You can use only one
of set_logic_one, set_logic_zero and and set_logic_dc on a given port.
DESCRIPTION
Assigns a driven_by_dont-care attribute to the ports in port_list; a given port can have only one of
the driven_by_logic_one, driven_by_logic_zero, and driven_by_dont-care attributes. This information is
used by compile to create smaller designs by eliminating logic that is tied to a specific value and therefore
might not need to be maintained during optimization. After optimization, a port connected to logic one,
logic zero, or don't care usually does not drive anything inside the optimized design.
Note: This command cannot be used on output ports.
When a set_logic_dc command is used on an input port, compile is given the freedom to assign any signal to
that input (including, but not limited to, zero and one). The meaning of this command is that the outputs of
the design are significant only when the non-don't care inputs completely determine all outputs, independent
of the don't care inputs.
EXAMPLES
Example-1 : The following example drives the port C to don't care
prompt> set_logic_dc C
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_logic_one
Specifies one or more input ports in the current design that are to be driven by logic one
int set_logic_one
<port_list>
Data Type
ARGUMENTS
<port_list>
[Required] Lists ports in the current_design that are to be driven by logic one. You can use only one
DESCRIPTION
Assigns a driven_by_logic_one attribute to the ports in port_list; a given port can have only one of
EXAMPLES
Example-1 : The following example drives the port C to logic one
prompt> set_logic_one C
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_logic_zero
Specifies one or more input ports in the current design that are to be driven by logic zero
int set_logic_zero
<port_list>
Data Type
ARGUMENTS
<port_list>
[Required] Lists ports in the current_design that are to be driven by logic zero. You can use only one
DESCRIPTION
Assigns a driven_by_logic_zero attribute to the ports in port_list; a given port can have only one of
EXAMPLES
Example-1 : The following example drives the port C to logic zero
prompt> set_logic_zero C
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_max_area
Sets the max_area attribute on the current design to a specified value.
int set_max_area
[-ignore_tns]
<area_value>
Data Type
area_value float
ARGUMENTS
-ignore_tns
[Optional] Specifies that area is prioritized above total negative slack (TNS).
<area_value>
[Required] Specifies the value to which the max_area attribute is to be set. The value must be >=
0. The units of area_value must be consistent with the units in the technology library used during
optimization.
DESCRIPTION
Sets the max_area attribute on the current design to the specified area_value. This attribute represents the
target area of the design.
EXAMPLES
Example-1 : The following example sets a max_area for the current_design to 250.
prompt> set_max_area 250 [current_design]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_max_capacitance
Sets maximum capacitance for ports,clocks or designs.
int set_max_capacitance
<capacitance_value>
[-clock_path] [-data_path]
[-rise] [-fall]
<object_list>
Data Type
object_list list
ARGUMENTS
-clock_path
[Optional] Specifies all pins that are in the network of the specific clocks in the object_list
-data_path
[Optional] Specifies all pins that are in the data paths launched by the specific clocks in the
object_list.
-rise
[Optional] Specifies rising capacitance for all the selected pins.
-fall
[Optional] Specifies falling capacitance for all the selected pins.
<capacitance_value>
[Required] Capacitance limit. The value must be >= 0; units must be the same as those in the
technology library.
<object_list>
[Required] Provides a list of ports,clocks or designs on which to set maximum capacitance.
DESCRIPTION
Specifies a maximum capacitance on ports or designs. If maximum capacitance is set on a port, the net
connected to that port is expected to have a total capacitance less than the specified capacitance_value. If
specified on a design, the default maximum capacitance for that design is set. Library cell pins also can have a
max_capacitance value specified.
If maximum capacitance is set on a clock, the maximum capacitance is applied to all pins in this specified
clock domain. Within a clock domain, you can optionally restrict the constraint further to clock paths only or
data paths only, and to rising or falling capacitance only. Note that clock_path, data_path, rise and fall options
can only be used when the max capacitance limit is set on a clock and does not apply to design or port.
EXAMPLES
Example-1 : The following example sets a maximum capacitance limit of 200 units on ports OUT*.

prompt> set_max_capacitance 200 [get_ports OUT*]
Example-2 : The following example sets a maximum transition limit of 500 on the design TEST.
prompt> set_max_capacitance 500 [current_design]
Example-3 : The following example sets a maximum transition limit of 250 on all pins in the clock network of
CLK.
prompt> set_max_capacitance 250 [get_clocks CLK] -clock_path
Example-4 : The following example sets a maximum transition limit of 250 on all pins in the data path of CLK.
prompt> set_max_capacitance 250 [get_clocks CLK] -data_path
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_max_fanout
Sets maximum fanout for input ports or designs.
status set_max_fanout
<fanout_value>
<object_list>
Data Type
fanout_value float
object_list list of input ports or

designs
ARGUMENTS
<fanout_value>
[Required] Fanout limit. The value must be >= 0; units must be the same as those in the technology
library.
<port_list>
[Required] Specifies a list of input ports or designs on which to set maximum fanout.
DESCRIPTION
Specifies a maximum fanout on input ports or designs. If maximum fanout is set on a port, the net connected
to that port is expected to have fanout_load less than the specified fanout_value. Fanout load for a net is
the sum of fanout_load attributes for all input pins on the net. If specified on a design, the default maximum
fanout for that design is set. Library cell pins may also have a max_fanout value specified. The most restrictive
of the design limit and the pin or port limit will be used.
EXAMPLES
Example-1 : The following example sets a max_fanout of 20 on the inputs name din.
prompt> set_max_fanout 20 [get_ports din*]
Example-2 : The following example sets a max_fanout of 25 on the design TEST.

prompt> set_max_fanout 25 TEST
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_max_transition
Sets maximum transition for ports,clocks or designs.
status set_max_transition
<transition_value>
[-clock_path] [-data_path]
[-rise] [-fall]
<object_list>
Data Type
object_list list
ARGUMENTS
-clock_path
[Optional] Specifies all pins that are in the network of the specific clocks in the object_list
-data_path
[Optional] Specifies all pins that are in the data paths launched by the specific clocks in the
object_list.
-rise
[Optional] Specifies rising transition for all the selected pins.
-fall
[Optional] Specifies falling transition for all the selected pins.
<transition_value>
[Required] Transition limit. The value must be >= 0; units must be the same as those in the technology
library.
<object_list>
[Required] Provides a list of ports,clocks or designs on which to set maximum transition.
DESCRIPTION
Specifies a maximum transition on ports or designs. If maximum transition is set on a port, the port is expected
to have transition time less than the specified transition_value. If specified on a design, the default maximum
transition for that design is set. Library cell pins can also have a max_transition value specified. The most
restrictive of the design limit and the pin or port limit is used.
If maximum transition is set on a clock, the maximum transition is applied to all pins in this specified clock
domain. Within a clock domain, you can optionally restrict the constraint further to clock paths only or data
paths only, and to rising transitions only or falling transitions only.
The -clock_path, -data_path, -rise, and -fall options can be used only if the list of objects is a clock list, not a
port list or design list. If clock_list is specified without -clock_path, -data_path, -rise or -fall, both clock path
and data path, both rise and fall are considered by default.

EXAMPLES
Example-1 : The following example sets a maximum transition limit of 2 units on ports OUT*.
prompt> set_max_transition 2 [get_ports OUT*]
prompt> set_max_transition 5 [current_design]
Example-3 : The following example sets a maximum transition limit of 2 on all pins in the clock network of
CLK.
prompt> set_max_transition 2 [get_clocks CLK] -clock_path
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_min_capacitance
Sets minimum capacitance for ports or designs.
status set_min_capacitance
<capacitance_value>
<object_list>
Data Type
object_list list
ARGUMENTS
<capacitance_value>
[Required] Capacitance value. The value must be >= 0; units must be the same as those in the
technology library.
<object_list>
[Required] Specifies a list of input or inout ports in the current design, on which the
capacitance_value is to be set.
DESCRIPTION
Specifies a minimum capacitance on input/inout ports or designs. If minimum capacitance is set on a
port, the net connected to that port is expected to have total capacitance greater than the specified
capacitance_value. If specified on a design, the default minimum capacitance for that design is set. Library
cell pins can also have a min_capacitance value specified. The most restrictive of the design limit and the pin
or port limit is used.
EXAMPLES
Example-1 : The following example sets a maximum capacitance limit of 200 units on ports IN*.
prompt> set_min_capacitance 200 [get_ports IN*]
prompt> set_min_capacitance 500 [current_design]
RELATED RULE CHECKS

None
RELATED COMMANDS
None
RELATED VARIABLES
None

set_operating_conditions
Defines the operating conditions for the current design.
status set_operating_conditions
[-analysis_type <analysis_type>]
[-min <min_condition>] [-max <max_condition>]
[-min_library <min_lib>] [-max_library <max_lib>]
[-min_phys <min_proc>] [-max_phys <max_proc>]
[-library <lib>]
[-object_list <objects>]
<condition>
Data Type
analysis_type bc_wc | on_chip_variation |

single
min_condition string
max_condition string
min_lib string
max_lib string
lib string
objects list or collection
condition string
ARGUMENTS
-analysis_type <analysis_type>
Indicates how the specified operating conditions are to be used. This option has the following
mutually-exclusive valid values: single, bc_wc, and on_chip_variation.
-library <lib>
Specifies the library that contains definitions of the environmental characteristics to be used. This is
either a library name or a collection object.
-min <min_condition>
Specifies the minimum operating condition used for checking minimum delays and hold violations. If
you use this option you must also use the -max option.
-max <max_condition>
Specifies the maximum operating condition used for checking maximum delays and setup violations. If
you use this option you must also use the -min option.
-min_library <min_lib>
Specifies the library that contains the min_condition. This is either a library name or a collection
object. If you use this option you must also use the -max_library option.
-max_library <max_lib>
Specifies the library that contains the max_condition. This is either a library name or a collection
object. If you use this option you must also use the -min_library option.

-min_phys <min_proc>
Specifies the process resource to search for resistance and capacitance values for minimum delay
analysis. If you use this option you must also use the -max_phys option.
-max_phys <max_proc>
Specifies the process resource to search for resistance and capacitance values for maximum delay
analysis. If you use this option you must also use the -min_phys option.
<condition>
Specifies the name of the single operating condition.
-object_list <objects>
Specifies the cells or ports on which to set operating conditions. If you do not use this option,
operating conditions are set on the design. This option accepts both leaf cells and hierarchical blocks.
You cannot use this option with the -analysis_type option.
DESCRIPTION
Defines the operating conditions (or environmental characteristics) under which the current design is timed.
You are in min_max mode if you use the -min and -max options. In that case, the default analysis type is
bc_wc.
EXAMPLES
Example-1 : The following example uses operating condition WCIND found in the my_lib.db library to set the
operating conditions to WCIND if the link_path is my_lib.db.
prompt> set_operating_conditions WCIND
Example-2 : The following example uses operating condition WCIND found in the other_lib.db library to set the
operating conditions to WCIND if the link_path is other_lib.db.
prompt> set_operating_conditions WCIND -library other_lib.db
Example-3 : In the following example, the BCCOM values are used for minimum operating conditions and the
WCCOM values are used for maximum operating conditions.
prompt> set_operating_condtions -min BCCOM -max WCCOM -analysis_type bc_wc
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_resistance
Sets the resistance to a specified value on specified nets.
status set_resistance
<resistance_value>
[-min] [-max]
<net_list>
Data Type
resistance_value float
net_list list of nets
ARGUMENTS
<resistance_value>
[Required] Specifies a nonnegative resistance value for the nets in net_list. The value must be >= 0;
units must be the same as those in the
technology library.
-min
[Optional] Indicates that the resistance_value is the minimum resistance.
-max
[Optional] Indicates that the resistance_value is the maximum resistance.
<net_list>
[Required] Specifies a list of nets in the current design on which the resistance_value is to be set.
DESCRIPTION
Sets the ba_net_resistance attribute, which specifies the back-annotation of resistance values on nets in the
current design. You can use the set_resistance command also for nets at lower levels of the design hierarchy.
You can specify these nets as "BLOCK1/BLOCK2/NET_NAME".
EXAMPLES
Example-1 : The following example sets the resistance to 5 on nets A and B
prompt> set_resistance 5 {A B}
Example-2 : The following example sets the resistance to on net U1/U2/B to 1

prompt> set_resistance 1 U1/U2/B
RELATED RULE CHECKS

None.
RELATED COMMANDS
None

RELATED VARIABLES
None

set_timing_derate
Sets delay derating factors for either the current design or a specified list of instances (cells, library cells, or nets).
status set_timing_derate
-early | -late
[-clock] [-data]
[-rise] [-fall]
[-min][-max]
[-static][-dynamic]
[-cell_delay] [-cell_check][-net_delay]
[-aovcm_guardband][-scalar][-variation]
<derate_value>
<object_list>
Data Type
derate_value float
object_list list
ARGUMENTS
-early
Indicates that the derate_value specified should be applied to early delays (shortest paths). This
option and the -late option are mutually exclusive.
-late
Indicates that the derate_value specified should be applied to late delays (longest paths). This option
and the -early option are mutually exclusive.
-data
[Optional] Indicates that the derate value should only apply to data paths.
-clock
[Optional] Indicates that the derate value should only apply to clock paths.
-rise
[Optional] Indicates that the derate value should be applied to rise delays.
-fall
[Optional] Indicates that the derate value should be applied to fall delays.
-cell_delay
[Optional] Indicates that the specified derating factor should apply to cell delays. This option cannot
be specified with the -cell_check option.
-net_delay
[Optional] Indicates that the specified derating factor should apply to net delays. This option cannot
be specified with the -cell_check option.
-cell_check

[Optional] Indicates that the specified derating factor should apply only to cell timing checks. If this
option is specified then the derate value set with the -early option will be applied to hold and removal
timing checks and the derate value set with the -late option will be applied to setup and recovery
timing checks. This option cannot be specified with any of the following options: -clock, - data, -
cell_delay, -net_delay and -aocvm_guardband
-aocvm_guardband
[Optional] This option is only applicable in an AOCVM context. In a AOCVM context the derate factor
that is applied to an arc is a product of the guard-band derate factor and the AOCVM derate factor.
This option cannot be specified with anyof the following options: -scalar, -variation, -dynamic or -
cell_check options.
-static
[Optional] Indicates that the specified derating factor should apply to the non-delta portion of net
delays only. This option requires that the -net_delay option is specified.
-dynamic
[Optional] Indicates that the specified derating factor should apply to the dynami component of delays
only. This option requires that the -net_delay option i specified. This option cannot be specified with
the -aocvm_guardband option.
-scalar
[Optional] Indicates that the specified derating factor should apply to deterministic delays only.
-variation
Optional optioan. Indicates that the specified derating factor should apply to statistical delays only.
<derate_value>
[Required] Specifies the timing derate value that will be applied to the specified delays as a scalar
multiplicative factor.
<object_list>
[Required] Specifies current design or a list of cells, library cells or nets to which the specified derate
factor will be applied.
DESCRIPTION
Sets derating factors for either the current design (if no object list is specifiedor a set of cells, library cells or
nets in the current design.Timing derating factors affect delay values shown in timing reports. Longest path
delays (for example, launching paths for setup checks or capturing paths for hold checks) are multiplied by
the derate value set using the -late option, and shortest paths (for example, capturing paths for setup checks
or launching paths for hold checks) are multiplied by the derate values set using the -early option. If derating
factors are not specified, the a value of 1.0 is assumed.
EXAMPLES
Example-1 : The following example sets an early (shortest path) derate factor of 0.7 and a late (longest path)
derate factor of 1.0 globally on all cell and net delays the design.
prompt> set_timing_derate -early 0.7
prompt> set_timing_derate -late 1.0
Example-2 : The following example sets an early derate factor of 0.8 for the cell delay of cell U1.
prompt> set_timing_derate -early 0.8 [get_cells U1]

Example-3 : The following example illustrates how to set a derate factor on all cells and nets (including sub-
hierarchies) within the hierarchy top/H1
prompt> set_timing_derate -cell_delay -net_delay -late 1.05 [get_cells top/H1]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_voltage
Applies an operating voltage to a list of supply net or internal supply port objjects.
status set_voltage
<max_voltage>
[-min <min_voltage>]
-object_list <object_list>
Data Type
max_voltage float
min_voltage float
object_list list of supply objects
ARGUMENTS
<max_voltage>
[Required] Specifies the operating voltage for the maximum delay (slowest) case. This is typically a
smaller voltage value.
-min <min_voltage>
[Optional] Specifies the operating voltage for the minimum delay (fastest) case. This is typically a
larger voltage value.
<object_list>
[Required] Specifies the list of power nets that will have the operating voltages as specified in this
command.
DESCRIPTION
Defines the operating voltage on the power nets or pins so that the parts of the design powered by these
power nets are timed and optimized at the specified voltage. If you do not specify any operating voltage for a
power net, the part of the design connected by this power net will continue to be timed and optimized based
on the available operating condition settings.
EXAMPLES
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None


set_wire_load_selection_group
Sets the wire load selection group for the current design.
int set_wire_load_selection_group
<group_name>
[-library <lib_spec>]
[-min][-max]
<object_list>
Data Type
group_name string
lib_spec string
object_list list
ARGUMENTS
<group_name>
[Required] Specifies the name of the wire load model; must be a valid wire load model in a library
specified in link_path.
-library <lib_spec>
[Optional] Specifies the library in which to search for the group_name. If not specified, libraries in
the link_path are searched.
-min
Specifies the selection group for minimum conditions
-max
Specifies the selection group for maximum conditions
<object_list>
Provides a list of hierarchical cells or designs. If you do not specify object_list, the wire load selection
group is set on the current instance, or on the current design if current instance is not set.
DESCRIPTION
Specifies the name of the selection group used when determining the wire load mode based on cell area
of blocks, when auto_wire_load_selection is true. This option is required only when the main library has
more than one selection group defined, and the default group defined in the library is not the desired
group. Automatic wire load selection is supported only for the enclosed wire load mode, specified using the
set_wire_load_mode command
EXAMPLES
Example-1 : This example specifies that the selection group named "selgrp1" from library "tech_lib" be applied
to the current design.
prompt> set_wire_load_selection_group selgrp1 -library tech_lib
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_wire_load_model
Sets wire load model on designs, ports or hiearchical cells.
status set_wire_load_model
-name <model_name>
[-library <lib_spec>]
[-min][-max]
<object_list>
Data Type
model_name string
lib_spec string
object_list list
ARGUMENTS
-name <model_name>
[Required] Specifies the name of the wire load model; must be a valid wire load model in a library
specified in link_path.
-library <lib_spec>
[Optional] Specifies the library in which to search for the model_name. If not specified, libraries in
the link_path are searched.
-min
[Optional] Specifies that the model is for minimum conditions
-max
[Optional] Specifies that the model is for maximum conditions.
<object_list>
[Required] Specifies a list of designs, ports, or hierarchical cells. The default is to set the wire model
on the current instance, if set; or on the current design otherwise.
DESCRIPTION
Sets the wire load model on designs, ports, or hierarchical cells. The wire load model calculates net
capacitance, resistance, and area for designs that have not been placed and routed.
EXAMPLES
Example-1 : The following example specifies a wire load model of "BIG" on the top level design a model of
"MEDIUM" on hierarchical cell "u1"
prompt> current_design TOP
prompt> set_wire_load_model -name BIG
prompt> current_design u1
prompt> set_wire_load_model -name MEDIUM
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_wire_load_mode
Sets wire load mode for the current design
status set_wire_load_mode
<mode_name>
Data Type
mode_name top | enclosed |

segmented
ARGUMENTS
<mode_name>
[Required] Name of the wire load mode.
DESCRIPTION
Specifies a wire load mode with the set_wire_load_mode command. If the mode for the top level design is top,
the wire load model on hierarchical cells has no effect, and the top-level wire load model is used to compute
wire capacitance for all nets within the design. If no wire_load_model_mode is specified for a design, a default
wire_load_model_mode is searched for in the first library in the link path. If the library checked does not have
a default wire_load_model_mode, top is assumed.
EXAMPLES
Example-1 : This example sets the wire load mode to enclosed on the current design
prompt> set_wire_load_mode enclosed
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_wire_load_min_block_size
Sets the minimum block area for automatic wire load selection. Any blocks with an area below the minimum are
promoted to the minimum.
int set_wire_load_min_block_size
<block_size>
Data Type
block_size float
ARGUMENTS
<block_size>
[Required] Minimum block size for auto wire load selection. This float value must be greater than or
equal to 0.0.
DESCRIPTION
Specifies the minimum block area for automatic wire load selection in the current design. When automatic
wire load selection is enabled, hierarchical cells are assigned wire load models based on their area. Any cells
with an area below the minimum block size are assigned the minimum block_size before a wire load model is
selected. If the minimum block size is not explicitly set, the default value of 0.0 used.
EXAMPLES
Example-1 : The following example sets a minimum block size of 1000 area units
prompt> set_wire_load_min_block_size 1000
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

set_port_fanout_number
Sets number of external fanout points on ports
status set_port_fanout_number
<fanout_number>
<port_list>
Data Type
fanout_number float
port_list list of ports
ARGUMENTS
<fanout_number>
[Required] Number of external fanout points (Range: 0 to 100000).
<port_list>
[Required] Specifies a list of ports.
DESCRIPTION
Sets the number of external fanout pins for ports in the current design. The number of pins is used (along with
wire load models) to calculate capacitance and resistance of nets. Setting this value to 0 when the driver of
the port has no otherinternal fanout causes the net driving the port to be treated as unconnected.
EXAMPLES
Example-1 : The following example sets a fanout number of 50 on all output ports in the current design.
prompt> set_port_fanout_number 50 [all_outputs]
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None

Multi-Voltage and Power Commands

This topic describes the commands that are used for setting up power related requirements.

create_voltage_area
Sets the type of strategy to use for reporting the signal level mismatches in the design.
string create_voltage_area
-name <cva_name>
[-coordinates <coordinate_list>]
[-guard_band_x <x>]
[-guard_band_y <y>]
<cell_list>
Data Type
cva_name string
coordinate_list list
x float
y float
cell_list list of collection
ARGUMENTS
-name <cva_name>
[Required]
-coordinates <coordinate_list>
[Optional]
-guard_band_x <x>
[Optional]
-guard_band_y <y>
[Optional]
DESCRIPTION
EXAMPLES
Example-1 :
prompt>
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES

None.

set_level_shifter_strategy
Sets the type of strategy to use for reporting the signal level mismatches in the design.
int set_level_shifter_strategy
[-rule <strategy>]
[-location <location>]
Data Type
strategy all | low_to_high |

high_to_low
location inside | outside |
source | sink
ARGUMENTS
-rule <rule>
[Optional] Specifies the voltage level between the source and the sink. Valid value for this option is
"all or low_to_high or high_to_low" and "all" is the default strategy.
-location <location>
[Optional] This option is only effective in power state table based level shifter insertion. It specifies
the location for a level shifter when it is inserted on a boundary of two domains. Valid value for this
option is "inside or outside or source or sink".
DESCRIPTION
This command specifies the strategy for reporting nets that need insertion of level_shifters. Using -rule
low_to_high reports the voltage level mismatches when a source at a lower voltage drives a sink at a higher
voltage. Using -rule high_to_low reports the voltage level mismatches when a source at a higher voltage drives
a sink at a lower voltage.
EXAMPLES
Example-1 : The following example sets the level shifter strategy to the high_to_low option:
prompt> set_level_shifter_strategy -rule high_to_low
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None.

set_level_shifter_threshold
Sets the minimum threshold beyond which the voltage adjustment is required
int set_level_shifter_threshold
[-voltage <volt>]
[-percent <diff>]
Data Type
volt float
diff float
ARGUMENTS
-voltage <volt>
[Required] Optional when -percent option is used. The absolute difference between the source and
sink voltages.
-percent <diff>
[Required] Optional when -voltage option is used. The percentage by which the source and sink
voltages must differ.
DESCRIPTION
This command specifies the minimum threshold value for the voltage difference between a source and a sink.
The threshold can be specified as the absolute difference in voltages or a percentage difference or both.
The default threshold voltage and percentage is zero. Therfore you typically must specify both absolute and
relative thresholds to suppress reporting of belowthreshold level mismatches.
EXAMPLES
Example-1 : The following example sets the level shifter threshold value to the absolute difference of 0.1 (and
sets large relative threshold):
prompt> set_level_shifter_threshold -voltage 0.1 -percent 100
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None.

set_max_dynamic_power
Sets the target dynamic power for the current (non-MCMM) design by setting the max_dynamic_power attribute to a
specified value
status set_max_dynamic_power
<dynamic_power>
[<unit>]
Data Type
dynamic_power float
unit GW | MW | KW | W |
mW | uW | nW | pW
| fW | aW
ARGUMENTS
<dynamic_power>
[Required] Specifies the maximum target dynamic power of the current design.
<unit>
Specifies the power dimension in GW | MW | KW | W | mW | uW | nW | pW | fW | aW units. If not
specified, then the unit of dynamic_power are assumed to be the same as those in the technology
library used during optimization.
DESCRIPTION
Sets the target (desired) dynamic power for the current design by setting the max_dynamic_power
attribute. max_dynamic_power is set to a value no greater than dynamic_power. If max_dynamic_power is
set more than once for a design, the last value is used.
EXAMPLES
Example-1 : The following example sets a max_dynamic_pwer for the current_design to 250.
prompt> set_max_dynamic_power 250
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None.

set_max_leakage_power
Sets the target leakage power for the current (non-MCMM) design by setting the max_leakage_power attribute to a
specified value
status set_max_leakage_power
<leakage_power>
[<unit>]
Data Type
leakage_power float
unit GW | MW | KW | W |
mW | uW | nW | pW
| fW | aW
ARGUMENTS
<leakage_power>
[Required] Specifies the maximum target leakage power of the current design.
<unit>
Specifies the power units in GW | MW | KW | W | mW | uW | nW | pW | fW | aW. If not specified,
then the unit of leakage_power are assumed to be the same as those in the technology library used
during optimization.
DESCRIPTION
Sets the target (desired) leakage power for the current design by setting the max_leakage_power attribute.
max_leakage_power is set to a value no greater than leakage_power. If max_leakage_power is set more than
once for a design, the last value is used. .
EXAMPLES
Example-1 : The following example sets a max_leakage_power for the current_design to 250.
prompt> set_max_leakage_power 250
RELATED RULE CHECKS

None.
RELATED COMMANDS
None
RELATED VARIABLES
None.

Real Intent Database

This chapter describes the user accessible Objects and their Attributes in Meridian CDC in Real Intent database
(RIDB). An object is a building block of the Meridian CDC database, named RIDB, which represents various information
about the design, its environment, and verification results. An attribute is a specification that represents a property
of an object which consists of a value or set of values. Design Objects can be accessed using SDC Object Access
Commands and other RIDB objects can be accessed using RIDB Commands. Attributes of all objects can be accessed by
set_attribute and get_attribute commands. RIDB is consist of following objects (and their type name), -class option to
set_attribute and get_attribute command can be given following types when object name is a named string.
• Design objects (design)

• Cell objects (cell)
• Port objects (port)
• Pin objects (pin)
• Net objects (net)
• Timing arc objects (timing_arc)
• Library objects (library)
• Library cell objects (lib_cell)
• Library pin objects (lib_pin)
• Library timing arc objects (lib_timing_arc)
• Rule objects (rule)
• Rule policy objects (rule_policy)
• Rule group objects (rule_group)
• Rule instance objects (rule_instance)
• Rule data objects (rule_data)
• Rule content objects (rule_content)

RIDB Terminology
The Real Intent database (RIDB) contains objects of information about a design, its environment, and verification
results. This quick reference defines terms associated with these objects of information.
Rule
A rule is a self-contained check to verify a specific functionality of the design and its environment. Rules are built-in
checks (or a set of checks) in the engine, and the RIDB provides a receptacle for holding the results of these checks.
Rules are configurable and can be instantiated any number of times with different parameters to meet a specific debug
methodology (see Rule Instance). You can use the get_rules RIDB access command to retrieve information about a rule
and its attributes.
Rule Content
Rule content is the raw data stored in the RIDB for a given rule. The data generated by one or more engine checks for
a given rule is stored in the RIDB in multiple lines. Each line of data is rule content, uniquely marked by RuleContentId
for a given rule.
Rule Data
Some rules generate grouped data, where a set of rule contents makes up collective information about a given
violation. Rule data is a group view of a set of rule contents. The rule data consists of this set of rule contents,
uniquely marked by RuleDataId for a given rule. In cases where there is no grouped data, the RuleDataId is exactly and
only the RuleContentId.
Status and RuleContentStatus

Status is an attribute of both rule data (Status) and rule content (RuleContentStatus) that you can use to mark and
categorize your results as part of a debug methodology. You can edit RuleContentStatus to mark the priority of that line
(RuleContentId), to mark it as signed off, and so on. The Status is computed by the RIDB based on a priority order of all
the RuleContentStatus values for a rule data group (RuleDataId).
View Criteria
View criteria is a way to query the RIDB results using an AND/OR expression on the rule data to filter (match) the data
you want to view based on the attributes of a rule. View criteria help you narrow down your results to a short list of
what you want to debug. View criteria results are rule data.
Actions
Actions are debug actions you can perform on rule data and rule content objects. For example, changing the status of
rule contents is an action; opening a violation path in an RTL design schematic viewer is an action; and so on. The set
of actions you can perform depends on which engine generated the RIDB you are debugging.
Rule Instance
A rule instance is a configured view of a rule. One way to configure a rule instance is to filter the larger set of rule
results into a smaller set by adding view criteria to the rule instance. Another way to configure a rule instance is to
set the display_headers attribute to display only a subset of the headers of the rule, in the current rule instance. A
rule instance allows you access to all the data of the rule. The full set of rule instance attributes can be found in the
documentation.
Rule Group
A rule group is either a set of rule instances, or a set of rule groups, or a mix of the two. It is a way to organize your
debug methodology hierarchically to allow a structured view into the rules and their rule data.
Rule Policy

A rule policy is a user-configurable methodology to verify certain functionality of the design and its environment. You
can use a rule policy to meet various flow requirements, and to organize verification categories that allow a step-by-
step debugging methodology for faster turnaround time. A rule policy is either a set of rule groups, or a set of rule
instances, or a mix of the two.
Note: The debug rule policy is different and distinct from any engine policy. Engine policies are strictly rule
configurations for a given engine run. Debug rule policies offer an organized methodology to view rule data.

Design Objects
This chapter describes how the design is represented in the RIDB. The root of the design hierarchy is a design, which
also known as root design or current design, which consists of ports, cells, pins, and nets. Below is an example of a
top level design view and how they relate to each other. Each object has set of attributes associated with it to provide
additional information about the object.
Design
A design is a user defined hdl element, which can also be a root object in the elaborated design
hierarchy, which is normally known as top level design. The top level design can also be accessed
by current_design command. Design objects are stored in a container called library which either
user defined library or default library named "work". Design objects can be accessed by get_designs
command and information about design object can be obtained through design attributes.

Cell
A cell (also known as an instance) is an instance of a design or a library cell in the design hierarchy.
Cells can either be a reference of a technology specific library cell (leaf cell) or a user defined Verilog
module or VHDL entity (hierarchical cell). Cell objects can be accessed by get_cells command, detail
information about a cell object can be obtained through cell attributes. A primary entry point to or a
primary exit point from the root design (or current design).
Pin
A pin is an entry point to or an exit point from a cell. Pin can either be a reference of a library cell
pin (leaf pin) or a pin of a user defined Verilog module or VHDL entity (hierarchical pin). Pin objects
can be accessed by get_pins command, detail information about a pin object can be obtained through
pin attributes.
Net
A net is an object that connects pin objects or port and pin objects. Nets can be accessed by get_nets
command, additional information about net object can be obtained through net attributes.
Port
A port is an entry point to or exit point from a design root (or current_design). Port objects can
be accessed by get_ports command and additional information about port object can be obtained
through port attributes.
Timing Arc
A timing arc is an object that holds timing sense of a net arc or a cell arc of a timing path. Timing
arc objects can be accessed by get_timing_arc command and additional information about timing arc
object can be obtained through timing arc attributes.
Clock
A clock is an object with a periodic behavior defined and associated with clock network. Clock
definition point is either a port or a pin. Clock objects can be created by create_clock or
create_generated_clock commands, can be accessed by get_clocks command, and information about
clock object can be obtained through clock attributes.

Library
A library is a container that holds library cells, primitive building block of technology specific or user
defined elements. Library names are taken from Liberty file when reading in technology specific
library by read_liberty or specified by user when reading in hdl elements. Libraries can be accessed
by get_libs command and information about library object can be obtained through library attributes.
Library Cell
A library cell is a primitive building block of a technology specific or user defined element. Library
cells from Liberty libraries are stored under their respective library names, any user defined library
cells are stored under user provided library name or default library name "work". Library cell can be
accessed by get_lib_cells command and information about the library cell object can be obtained
through library cell attributes.
Library Pin
A library pin is an entry point to or an exit point from a library cell. Library pins can be accessed by
get_lib_pins command and information about library pin object can be obtained through library pin
attributes.
Library Timing Arc
A library timing arc is an object that holds information about timing sense of an output pin of a
library cell. Library timing arcs can be accessed by get_lib_timing_arc command and information
about library timing arc object can be obtained through library timing arc attributes.
• Hierarchical Names of the Design Objects

Elaborated design hierarchy is represeted as a tree structure, top level design being root (returned by
current_design command). Design hierarchy can be navigated or searched using current_instance. The cells
(or instances), pins, and at the each level of hierarchy can be accessed by Object Access Commands. In the
design tree, hierarchy is represented by set_hierarchy_separator. Design objects in different hierarchies can
be accessed without changing the current design or instance scope by levelraging the hierarchy separator. For
the SDC commands and Object Access Commands, default hierarchy separator is "/". For the ENV commands,
the default hierarchy separator is "." as it follows the simulation naming scheme. Most leaf level objects in the
design hierarchy can be specified (or access) as :
/<design_top>/<hierarchy_level1>/<hierarchy_level2>/<leaf_objects>
Where <leaf_objects> can be of cell, pin, or ports.

Design Attributes
This table describes the set of attributes associated with design object.
Attribute Name Type Permission Description

(Read/Write)
name string R Name of the design (module or entity)
full_name string R Full name of the design, which includes the library
where the design is stored. For example, library_name/
design_name
file_name string R File name where the design is declared
line_number integer R Line number in the file_name attribute where the design
is declared
library collection R Library object where the design is stored
reference_design string R Reference design name if the design is a parameterized

design. Empty string if the design is not a parameterized
design
type string R Indicates the type of the design
valid_values : <vhdl | verilog | systemverilog>
is_parameterized boolean R 1 indicates the design is parameterized design, if not 0
*1 boolean R 1 indicates if the design is the root module (or current
is_current_design
design), if not 0
*1 boolean R 1 indicates that the design is instantiated in the
is_instantiated
elaborated design hierarchy, if not 0
object_class string R Name of the object type
valid value : design
Notes :
*1 : Attributes is_current_design and is_instantiated are mutually exclusive, meaning that if the attribute
is_current_design is 1, then is_instantiated is 0 as the root design is not considered as an instantiation of a
design. On the other hand, if the design is instantiated in the design hierarchy, then it can't be a design root,
hence is_current_design is 0.

Cell Attributes
This table describes the set of attributes associated with rule instance object.

(Read/Write)
name string R Name of the cell (this is non-hierarchical name of the cell)
full_name string R Full hierarchical name of the cell from the top
file_name string R File name where the cell is instantiated
line_number integer R Line number in the file_name where cell is instantiated
ref_name collection R Reference object of the cell (either design object of library
cell object)
parent collection R Parent cell in the design hierarchy
*1 string R Type of the cell, is one of the type from design object or
type
library cell object
*1 list R Lists the mode_definitions of the Liberty cell instances,
mode_definition
format of the value is :
{mode_name1 {list of valid values} mode_name2 {list
of valid values} ...}
is_hierarchical boolean R 1 indicates that the cell is a hierarchical cell (an instance
of a design object), if not 0
is_shelled_node boolean R 1 indicates that the cell has to be treated as a shell for
analysis, if not 0
is_targeted_node boolean R 1 indicates that the cell has been set as a target for
analysis, if not 0
is_spec_node boolean R 1 indicates that the cell has been a scope for SDC or ENV, if
not 0
is_cdc_node boolean R/W 1 indicated that the cell has been tagged for scope based
reporting
*1 boolean R 1 indicates that the cell is a sequential cell, if not 0
is_sequential
*1 boolean R 1 indicates that the cell is a PAD cell, if not 0
is_pad_cell
*1 boolean R 1 indicates that the cell is a clock gating cell, if not 0
is_clock_gate
*1 boolean R 1 indicates that the cell is a don't touch cell, if not 0
is_dont_touch
(writable only at the cell object level)
*1 boolean R 1 indicates that the cell is a don't use cell, if not 0
is_dont_use
(writable only at the cell object level)
is_black_box boolean R 1 indicates that the cell is a black box, if not 0
*2 collection R list of clock domains the cell belongs to
clock_domains
valid value : cell
Notes :
*1 : All attributes are inherited from its reference object

*2 : The attribute clock_domains is only relevant for the sequential cells and derived from the clocks
reached to clock pins of the sequential cell. For the primary ports and blackbox input and output pins, clocks
associated with those objects determine the clock_domains

Pin Attributes
This table describes the set of attributes associated with pin object.

(Read/Write)
name string R Name of the pin (this is non-hierarchical name of the pin)
full_name string R Full name of the pin from the top (inst1/inst2/pin)
file_name string R File name where the pin is instantiated
line_number integer R Line number in the file_name where pin is instantiated
*1 string R Indicates the direction of the pin
direction
valid values : <in | out | inout | internal>
ref_name collection R Reference object of the pin
bus_basename string R Base name of the array
pin_index string R Index of the pin in the array
*1 string R Type of the pin inherited from library pin object
type
is_hierarchical boolean R i indicates that pin is a hierarchical pin (port of a design
instantiated)
*1 boolean R 1 indicates that pin is a pad pin, if not 0
is_pad
*1 boolean R 1 indicates that pin is a clock pin, if not 0
is_clock
clocks_propagated list R List of clock objects getting propagated to pin with clock
phase information when the pin is marked as is_clock. For
example: {{<clkobj> <rise | fall | unknown>} {<clkobj>
<rise | fall | unknown>} ...}
*1 boolean R 1 indicates that pin is a set/reset pin, if not 0
is_setrst
*1 boolean R 1 indicates that the pin is a test pin, if not 0
is_test
*2 boolean R 1 indicates that the pin is a constant, if not 0
is_constant
*2 enum R Value of the constant, "pseudo" means propagated constants
constant_value
valid values : <zero | one | pseudo_zero | pseudo_one>
*2 boolean R 1 indicates that the pin is on the ideal network, if not 0
is_ideal
*2 boolean R 1 indicated that the pin is on the don't touch network, if
is_dont_touch
not 0
*2 collection R List of launch clocks of the drivers in the fanin cone
launch_clocks
of the pin with their phase information. For example:
{{<clkobj> <rise | fall | unknown>} {<clkobj> <rise |
fall | unknown>} ...}
*2 collection R List of capture clocks of the sinks in the fanout cone
capture_clocks
of the pin with their phase informaiton. For example:
valid value : pin
Notes :

*1 : All these attributes are inherited from reference object

*2 : These attributes are available only after spec has been read in and spec propagation has been performed,
otherwise value for those attributes is an empty string

Net Attributes
This table describes the set of attributes associated with net object.

(Read/Write)
name string R Name of the net (this is non-hierarchical name of the net)
full_name string R Full name of the net from the top (i.e inst1/inst2/net)
file_name string R File name where the net is declared
line_number integer R Line number in the file_name where the net is declared
bus_width integer R Width of the array
net_index string R Index of the net in the array
is_undriven boolean R 1 indicates that net is not driven by any driver, if not 0
is_floating boolean R 1 indicates that net has no load (or not driving any pin or
port)
*1 boolean R 1 indicates that net is a clock net, if not 0
is_clock
clocks_propagated list R List of clock objects getting propagated to pin with clock
phase information when the net is marked as is_clock.
For example: {{<clock_obj> <rise | fall | unknown>}
{<clkobj> <rise | fall | unknown>} ...}
*1 boolean R 1 indicates that net is a set/reset net, if not 0
is_setrst
*1 boolean R 1 indicates that the net is a constant, if not 0
is_constant
*1 enum R Value of the constant, "pseudo" means propagated constants
constant_value
valid values : <zero | one | pseudo_zero | pseudo_one>
*1 boolean R 1 indicates that the net is on the ideal network, if not 0
is_ideal
*1 boolean R 1 indicated that the net is on the don't touch network, if
is_dont_touch
not 0
*1 collection R List of launch clocks of the drivers in the fanin cone
launch_clocks
of the net with their phase information. For example:
*1 collection R List of capture clocks of the sinks in the fanout cone
capture_clocks
of the net with their phase information. For example:
valid value : net
Notes :
*1 : All these attributes are populated after spec has been read in and spec propagation has been performed.

Port Attributes
This table describes the set of attributes associated with port object.

(Read/Write)
name string R Name of the port
full_name string R Full name of the port, for port this is same as name
file_name string R File name where the port is declared
line_number integer R Line number in the file_name where the port is declared
direction string R Indicates the direction of the port
valid values : <in | out | inout>
bus_width collection R Width of the array
bus_index string R Index of the current port in the array
lsb boolean R LSB bit of the array
msb string R MSB bit of the array
*3 boolean R 1 if the port is a clock port, if not 0
is_clock
*3 boolean R 1 if the port is a set/reset port, if not 0
is_setrst
*3 boolean R 1 if the port is a constant port, if not 0
is_constant
constant_type enum R Value of the constant, "pseudo" means those objects are
evaluated to be constant
valid values : <zero | one | pseudo_zero |
pseudo_one>
*3 boolean R 1 indicates that the port object is on the ideal network, if
is_ideal
not 0
*3 boolean R 1 indicates that the port object is on the don't touch
is_dont_touch
network, if not 0
*1*3 collection R List of launch clocks of the drivers in the fanin cone of the
launch_clocks
port object with their phase information. For example:
*2*3collection R List of capture clocks of the sinks in the fanout cone of the
capture_clocks
port object with their phase information. For example:
valid value : port
Notes :
*1 : The attribute launch_clocks for the ports with direction input (or input side of the inout ports) is derived
from the spec associated with the port objects. Attribute launch_clocks is an empty string in absence of the
spec or if it is clock node (i.e. when is_clock is 1).
*2 : The attribute capture_clocks for the ports with direction output (or output side of the inout ports)
is derived from the spec associated with the port objects. Attribute capture_clocks is an empty string in
absence of the spec or if it is a clock node (i.e. when is_clock is 1).

*3 : These attributes are available only after spec has been read and spec propagation has been performed

Timing Arc Attributes

This table describes the set of attributes associated with timing arc object.

(Read/Write)
parent collection R Cell/Net object the timing arc belongs to
*1 collection R Start point of the timing arc
from_pin
*1 collection R End point of the timing arc
to_pin
*1 list R list of modes the timing arc belongs to, if mode is not
mode
defined empty string
*1 string R "The condition "when" in the timing arc
when
*1 string R Indicates the timing type of the arc
type
*1 string R Indicates that timing sense of the arc
sense
valid values : <positive_unate | negative_unate |
non_unate>
*1 boolean R Indicates if the arc is disabled (due to mode)
is_disabled
*1 boolean R Indicates if the arc is disabled by user (by
is_user_disabled
set_disable_timing)
is_cellarc boolean R 1 indicates the timing arc is a cell timing arc, 0 indicates
net timing arc
valid value : timing_arc
Notes :
*1 : All these attributes are inherited from reference objects when is_cellarc is 1. Net arcs are created after
the design has been elaborated.

Clock Attributes
This table describes the set of attributes associated with clock object.
Attribute Type Permission Description

Name (Read/Write)
name string R Name of the clock object
full_name string R Full name of the cell from the top
file_name string R File name where the clock is declared
line_number integer R Line number in the file_name where clock is declared
*2 float R Period of the clock in library time units
period
*2 list R Waveform of the clock in library time units
waveform
*1 collection R Pin object the source clock information to be derived for
source_pin
generated clock
*1 collection R List of clocks used for generated clock
master_clock
*1 boolean R 1 indicates that the clock is a generated clock, if not 0
is_generated
*1 boolean R 1 indicated that the clock is inverted clock from its master
is_inverted
clock, if not 0
scope collection R Scope (or the instance) of the design clock is associated
clock_src collection R List of port pin list where the clock is defined
valid value : clock
Notes :
*1 : All these attributes are valid only for generated clocks (defined by create_generated_clock command),
clock objects created for create_clock have empty string for these attributes
*2 : These attributes should be calculated for generated clock after deriving master clock information

Library Attributes
This table describes the set of attributes associated with the library object.

(Read/Write)
name string R Name of the library
full_name string R Full name of the library (same as name to keep the
consistency across objects)
file_name string R File name where the library is declared
line_number integer R Line number in the file_name where library is
declared
type string R Type of the library
valid values : <vhdl | verilog | systemverilog |
liberty>
*1 dict R Library units defined in the library
library_units
operating_conditions list R List of operating conditions defined in the library
wire_load_model list R List of wire load models defined in the library
wire_load_table list R List of wire load tables defined in the library
wire_load_selection list R List of wire load selection names defined in the
library
default_max_fanout float R Default max fanout defined in the library
default_max_transition float R Default max transition defined in the library
default_max_capacitance float R Default max capacitance defined in the library
default_wire_load_mode string R Default wire load mode defined in the library
default_wire_load_model string R Default wire load model defined in the library
default_wire_load_selection string R Default wire load selection defined in the library
default_operating_condition string R Default operating condition defined in the library
*2 dict R List of bus groups defined in the library (valid only
bus_groups
for Liberty library)
valid value : lib
Notes :
*1 : The library_units is in dictionary format that represents the library units for the following units :
• time_unit
• voltage_unit
• current_unit
• capacitive_load_unit
• pulling_resistance_unit
• leakage_power_unit
*2 : The bus_groups is in dictionary format storing bus group information defined in the Liberty library as
"<bus_group_name> {base_type <value> data_type <value> bit_width <> bit_from <value> bit_to <value>
downto <true | false>}". This will represents the following bus group in the Liberty :
type ( ADR_3_0) {
base_type : array;

data_type : bit;
bit_width : 4;
bit_from : 3;
bit_to : 0;
downto : true;
}

Library Cell Attributes

This table describes the set of attributes associated with library cell object.

(Read/Write)
name string R Name of the library cell
full_name string R Full name of the library cell librarry_name/libcell_name
file_name string R File name where the library cell is declared
line_number integer R Line number in the file_name where library cell is declared
*1 string R Type of the library cell
type
library collection R Library object where library cell is stored
mode_definition list R Lists the mode_definitions defined in the Liberty cells,
format of the value is :
mode_name {list of valid values}
is_sequential boolean R 1 indicates if the library cell is a sequential cell, if not 0
is_pad_cell boolean R 1 indicates the library cell is a PAD cell (derived from
"pad_cell : true" from Liberty), if not 0
is_clock_gate boolean R 1 indicates the library cell is a clock gating cell (derived
from clock_gating_integrated_cell from Liberty), if not 0
is_dont_touch boolean R 1 indicates the library cell is a dont touch cell (derived from
dont_touch from Liberty), if not 0
is_dont_use boolean R 1 indicates the library cell is a dont use cell (derived from
dont_use from Liberty), if not 0
valid value : lib_cell
Notes :
*1 : The type attribute indicates cell is one of following type:

• Generic types : BUF, AND, OR, INV, NAND, XOR, XNOR, MUX, or COMBO (all other combinatorial logic)
• When is_sequential is 1, type is one of : flipFlop, latch, masterSlave, retentionFlop
• When is_clock_gating_cell is 1, type is one of following (see the Liberty Library LRM from Open
Source Liberty for more details)
• generic
• latch_posedge
• latch_posedge_precontrol
• latch_posedge_procontrol_obs
• latch_posedge_postcontrol
• latch_posedge_postcontrol_obs
• latch_negedge
• latch_negedge_precontrol
• latch_negedge_procontrol_obs
• latch_negedge_postcontrol
• latch_negedge_postcontrol_obs
• ff_posedge
• ff_posedge_precontrol
• ff_posedge_procontrol_obs
• ff_posedge_postcontrol

• ff_posedge_postcontrol_obs
• ff_negedge
• ff_negedge_precontrol
• ff_negedge_procontrol_obs
• ff_negedge_postcontrol
• ff_negedge_postcontrol_obs
• none_posedge
• none_posedge_precontrol
• none_posedge_procontrol_obs
• none_posedge_postcontrol
• none_posedge_postcontrol_obs

Library Pin Attributes

This table describes the set of attributes associated with library pin object.

Name (Read/Write)
name string R Name of the library pin (this is non-hierarchical name of the
pin)
full_name string R Full name of the library pin (i.e library/library_cell/
library_pin)
file_name string R File name where the library pin is declared
line_number integer R Line number in the file_name where library pin is declared
direction string R Indicates the direction of the library pin
valid values : <in | out | inout | internal>
library collection R Library object where the library pin is declared
bus_basename string R Base name of the library pin array
bus_groupname string R Bus group name of the library pin array (valid only for library
cell pin from Liberty)
pin_index integer R Indicates the index of this library pin in the array
*1 string R Indicates the library pin type (see the Notes below)
type
is_pad boolean R 1 indicates that library pin is a pad pin (derived from
"is_pad : true" in the Liberty), if not 0
*2 boolean R 1 indicates that library pin is a clock pin, if not 0
is_clock
is_setrst boolean R 1 indicates that library pin is a set/reset pin, if not 0
is_test boolean R 1 indicates that library pin is a test pin, if not 0
valid value : lib_pin
Notes :
*1 : The type attribute indicates pin is one of the following type:

• General type : data_in, data_out, select
• When is_clock is 1, library pin type is : clock_pos, clock_neg, clock_nonunate
• When is_setrst is 1, library pin type is : set_high, set_low, reset_high, reset_low
• When is_test is 1, library pin type is one of following (see the Liberty Library LRM from Open Source
Liberty for more details)
• test_scan_in
• test_scan_in_inverted
• test_scan_out
• test_scan_out_inteverted
• test_scan_enable
• test_scan_enable_inverted
• test_scan_clock
• test_scan_clock_a
• test_scan_clock_b
• test_clock
*2 : The attribute is_clock is derived from following information

1) Pins with the Liberty library pin with attribute "clock : true" (as in below code snippet) is derived as
is_clock pin
pin(CK) {
direction : input;
clock : true;
capacitance : 0.1;
related_power_pin : VDD;
related_ground_pin : VSS;
... /* Other pin level attributes and groups*/
}
2) Any sequential clock inferred from RTL is derived as is_clock pin. In the following example, clock
pin inferred for the sequential cell connected to signal CLK is considered a clock pin
always @(posedge CLK or negedge RST)
begin
if (RST == 1'b0)
myreg <= 1'b0;
else
myreg <= din ;
end

Library Timing Arc Attributes

This table describes the set of attributes associated with library timing arc object.

(Read/Write)
libcell collection R Library cell object the library timing arc belongs to
from_lib_pin collection R Library timing arc start pin
to_lib_pin collection R Library timing arc end pin
modes list R List of modes the timing arc belongs to, if mode is not
defined empty string
*1 string R Indicates the timing type of the arc
type
*2 string R Indicates that timing sense of the arc
sense
valid values : <positive_unate | negative_unate |
non_unate>
is_disabled boolean R Indicates if the arc is disabled (due to mode)
is_user_disabled boolean R Indicates if the arc is disabled by user (by
set_disable_timing)
valid value : lib_timing_arc
Notes :
*1 : See the timing_type in the Liberty Library LRM from Open Source Liberty for more details
• Combinational timing types

• combinational
• combinational_rise
• combinational_fall
• three_state_disable
• three_state_disable_rise
• three_state_disable_fall
• three_state_enable
• three_state_enable_rise
• three_state_enable_fall
• Sequential timing types
• rising_edge
• falling_edge
• preset
• clear
• hold_rising
• hold_falling
• setup_rising
• setup_falling
• recovery_rising
• recovery_falling
• skew_rising
• skew_falling
• removal_rising
• removal_falling

• min_pulse_width
• minimum_period
• max_clock_tree_path
• min_clock_tree_path
• Non-Sequential timing arcs
• non_seq_setup_rising
• non_seq_setup_falling
• non_seq_hold_rising
• non_seq_hold_falling
• No-Change timing arcs
• nochange_high_high
• nochange_high_low
• nochange_low_high
• nochange_low_low
*2 : See the timing_sense in the Liberty Library LRM from Open Source Liberty for more details

Rule Policy Objects

This chapter describes an overview of a policy. A policy is a methodology to verify certain functionality of the design
and its environment. Policy is a user configurable methodology to meet various user flow requirements. It also helps
organize the verification categories such that helps establish step-by-step debugging methodology for faster turn
around time. Below is an example of overall view of a basic rule policy structure and how they are related to each
other.
Rule Policy
Rule policy object, the root object of a policy. User can create a rule policy by create_rule_policy
command, once the policy is loaded to Meridian CDC, rule policy objects can be accessed by RIDB
access command get_policies. Each policy has its own attributes associated with it that provides
information about the object, see rule policy attributes for details of each attribute.

Rule Group
Rule groups is an object that allows grouping certain rule instances for better methodology creation.
Rule group can be made of sub rule groups (optional) and rule instances. Rule group objects can
be directly accessed by RIDB access command get_rule_groups. Rule group has its own attributes
associated with it providing more information about the object, see rule group attributes for the
details of each attribute.
Rule Instance
Rule instance object is an instance of a rule object which can be configured to meet user specific
methodology or requirement. Rule instance can be created by create_rule_instance command and
rule instance object can be accessed by RIDB access command get_rule_instances. Each rule instance
has its own attributes associated with it that provides information about particular rule instance, see
rule instance attributes for details.
Rule
Rule is a self contained check to verify a specific functionality of the design and its environment. Rule
can be configurable and can be instantiated (rule instance) multiple times with different parameters
(if configure-ability is provided) to meet a specific methodology. Rules are built-in checks which can
be accessed by RIDB access command get_rules, more information about the rule can be accessed
through rule attributes.
Rule Data
Rule data is an object that holds the results of a rule instance run. Rule data consists with one or
more collection of Rule content objects, representing the verification results. Rule data objects can
be accessed by RIDB access command get_rule_data, information about rule data can be obtained
through rule data attributes.
Rule Content
Rule content is an object that represents the information about each line in the rule data
object. Rule content is generated by rule instance and can be accessed by RIDB access command
get_rule_content, information about each rule content can be obtained via rule content attributes
that are associated with it.
• Hierarchical nodes of the rule policy tree

Rule policy is represented as a tree based on rule_group and rule_instances, rule policy is a presentation layer
of a specific verification task in the flow. Once the given verification has been performed, results are deposit
under their respective rule instances. Results is represented using rule data objects in which rule content

objects represents each line in the table, each results can be formed by multiple rule content objects. Similar
to design hierarchy, rule objects can also be accessed using "/" as a node separator. The separator "/" is not
controlled by the SDC command set_hierarchy_separator. The most leaf level object in the rule policy tree is a
rule content object, which can be specified (or access) as :
<rule_policy>/<rule_group>/<rule_instance>/<rule_data>/<rule_content>
Each node in the policy tree has an ID associated with them and can be accessed by full name using RIDB
Commands. RIDB access command supports global pattern matching, regular expressions as well as filtering
capabilities based on their attributes or based on user defined view criteria. Also report_policy command can
be used to generate a report for any node in the rule policy tree.
• Impact of the view_criteria on rule policy

The object view_criteria (created by create_view_criteria command) has been designed to support unique
search capability to ease the debugging, to configure the reporting as well as to configure the visualization of
a policy. A rule policy is made of rule_policy (root node), rule_group, and then rule_instance objects, each of
these node can have their own view_criteria associated with it (and it is user settable). So the view_criteria
at the child nodes inherit its parent view_criteria and anded with its own view_criteria if exists (default is
none). So the rule_data and rule_content objects of a given rule_instance object has view_criteria assigned as
"rule_policy.view_criteria && rule_group.view_criteria && rule_instance.view_criteria" as a result.

Rule Policy Attributes

This table describes the set of attributes associated with rule policy object.
Attribute Type Permission Permission Description

Name Factory User Policy
Policy (Read/Write)
(Read/Write)
name string R R/W Name of the policy object (no space allowed)
description string R R/W Short description of the policy (short
description will be used in the balloon help
when hovering the mouse over rule policy)
full_description string R R/W Full description of the rule policy. This full
description is included in the report
file_name string R R File name where the rule policy is created.
line_number integer R R Line number in the file_name where the rule
policy is created
status list R R Statistics of the rule data objects in the entire
policy object based on the status attribute
in Tcl list key/value pair form. This is a
compilation of status attribute of all the rule
data objects information. For example :
total <> status-a <> status-b <> status-c
<> ...
view_criteria collection R R/W List of view criteria objects applied to the rule
policy. Policy level view criteria is applied to
all of its descendent nodes (rule groups, rule
instance) down in the policy hierarchy
default : ""
chart_type string R/W R/W Specify the chart type to be used to report
the summary. Policy level chart_type for
displaying summary is applied to all of its
descendent nodes (rule groups, rule instance)
down in the hierarchy if lower level nodes do
not have view criteria specified
valid values : <pie | histogram | table>
default : pie
chart_based_on string R/W R/W Specify the information chart summary to
be created. Policy level chart_based_on
displaying the summary is applied to all of its
descendent nodes (rule groups, rule instance)
down in the hierarchy if lower level nodes do
not have view criteria specified
valid values : <status | severity>
default : status
version string R R/W Assign a version to the rule policy for
methodology management
default : ""
object_class string R R Name of the object type
valid value : rule_policy

Rule Group Attributes

This table describes the set of attributes associated with rule group object.

Name Factory User Group
Group (Read/Write)
(Read/Write)
name string R R Name of the rule group
full_name string R R Full name of the rule group, full name is
rule_policy/rule_group
description string R R/W Short description of the rule group (short
description will be used in the balloon help
when hovering the mouse over rule policy)
full_description string R R/W Full description of the rule group
file_name string R R File name where the rule group is created
line_number integer R R Line number in the file_name where rule
group is created
status dict R R Statistics of the rule data based on the status
of the rule data objects in Tcl dictionary form.
For example : total <> status-a <> status-b
<> status-c <> ...
rule_policy collection R R Rule policy object rule instance has been
created, collection contains one rule policy
object
parent_group collection R R Rule group if the current rule group is
*1 instantiated inside of another rule group.
The collection contains immediate rule group
object, if not empty string
view_criteria collection R R/W Specify list of view criteria objects applied to
*2 rule group and its descendants down in the
hierarchy. If not specified, parent level view
criteria is used
chart_type string R/W R/W Specify the chart type to be used to report
the summary and its descendants down in the
hierarchy. If not specified, immediate parent
level chart_type is used for the summary
report
valid values : <pie | histogram | table>
default : pie
chart_based_on string R/W R/W Specify the information chart summary to
be created and its descendants down in the
hierarchy. If not specified, immediate parent
level chart_based_on is used for the summary
report
default : status
version string R R/W Version of the rule
valid value : rule_group

Notes :
*1 : Object rule_group can be instantiated inside of another rule_group object (see the details in Policy
Objects), in such situations, <parent_group> attribute holds parent rule group node. If the rule_group object
directly instantiated under rule_policy object, then <parent_group> attribute has empty string.
*2 : The attribute <view_criteria> indicates what <view_criteria>s have been assigned to rule_group
object. The <view_criteria> at rule_group object level inherits <view_criteria> imposed by rule policy/
group object, as a result, <view_criteria> at rule_group is equivalent to "rule_policy.view_criteria &&
parent_group.view_criteria".

Rule Instance Attributes

This table describes the set of attributes associated with rule instance object.

Name Factory Rule User Rule
Instance Instance
(Read/Write) (Read/Write)
*1 string R R Name of the rule instance
name
full_name string R R Full name of the rule instance, full
name is rule_policy/rule_group/
rule_instance
*1 string R R/W Short description of the rule instance
description
(short description will be used in the
balloon help when hovering the mouse
over rule policy)
*1 string R R/W Full description of the rule instance
full_description
ref_name collection R R reference rule object of the rule
instance
file_name string R R File name where the rule instance is
created
line_number integer R R Line number in the file_name where
rule instance is created
*1 list R R Table headers if each rule
headers
*1 list R/W R/W List of headers to be visible in the
display_headers
report and table in the iDEBUG. Table
header follows the the order headers in
this attribute. This attribute contains
the same or subset of "headers"
attribute
*1 list R R Right-Mouse-Button actions available
actions
for the rule
enabled_actions list R/W R/W Enabled Right-Mouse-Button actions
*1 for the rule. This attribute contains
the same list as in "actions" attribute
as all available actions are enabled by
default
*1 string R/W R/W Severity of the rule
severity
status dict R R Statistics of the rule data based on the
status of the rule data objects in Tcl
dictionary form. For example : total
<> status-a <> status-b <> status-c
<> ...
rule_group collection R R Immediate rule group object rule
instance is created. This can be an
empty if the rule instance object is
directly instantiated under rule policy
object. Collection contains one rule
group object

rule_policy collection R R Rule policy object rule instance has

been created, collection contains one
rule policy object
*2 list/collection R R/W Specify list of view criteria for the
view_criteria
rule instance, value can either be a
collection or list of view_criteria names
*1 string R/W R/W Specify the chart type to be used to
chart_type
report the summary, if not specified,
parent level view criteria is used for
the summary report
valid values : <pie | histogram |
table>
default : pie
*1 string R/W R/W Specify the information chart summary
chart_based_on
to be created, if not specified, parent
level view criteria is used for the
summary report
default : status
is_dbgfile_enabled boolean R R 1 indicates if the dbg file generation of
*1 reference rule (ref_name) is enabled,
if not 0
*1 boolean R R 1 indicates if reference rule
is_rule_enabled
(ref_name) is enabled, if not 0
*1 boolean R R 1 indicates if the rule has been run, if
is_run
not 0
*1 string R R Version of the rule
version
*1 string R R Help ID of the rule
help_id
*1 string R R Executable function of the rule
exec_function
valid value : rule_instance
Notes :
*1 : All these attributes are inherited from rule object when rule_instance object is created. After rule is
instantiated, user can manipulate the attributes that are writable at the rule_instance object level
*2 : The attribute <view_criteria> indicates what <view_criteria>s have been assigned to rule_instance
object. The <view_criteria> at rule_instance object level inherits <view_criteria> imposed by rule policy/
group objects, as a result, <view_criteria> at rule_instance is equivalent to "rule_policy.view_criteria &&
rule_group.view_criteria && rule_instance.view_criteria".

Rule Attributes
This table describes the set of attributes associated with rule object.

Name (Read/Write)
name string R Name of the rule
description string R Short description of the rule
full_description string R Full description of the rule
headers list R Table headers of each rule
display_headers list R/W List of headers to be visible in the report and table
in the iDEBUG. Table header follows the the order
headers in this attribute. This attribute contains the
same or subset of "headers" attribute
actions list R Right-Mouse-Button actions available for the rule
enabled_actions list R/W Enabled Right-Mouse-Button actions for the rule.
This attribute contains the same or subset of actions
defined in the "actions" attribute
severity string R/W Severity of the rule (This severity is annotated to
all rule data and rule content objects of the rule
instance)
view_criteria list/collection R Specify list of view criteria for the rule, value can
either be a collection or list of view_criteria names
chart_type string R/W Specify the chart type to be used to report the
summary
valid values : <pie | histogram | Table>
default : pie
chart_based_on string R/W Specify the information chart summary to be created
default : status
is_rule_enabled boolean R 1 indicates if rule is enabled, if not 0
is_dbgfile_enabled boolean R 1 indicates if the dbg file generation is enabled, if not
0
version string R Version of the rule
help_id string R Help ID of the rule
exec_function string R Executable function of the rule, built-in rules have
empty string
valid value : rule

Rule Data Attributes

This table describes the set of attributes associated with rule data object.

(Read/Write)
ID string R Rule data ID
full_name string R Full name of the rule data, full name is rule_policy/
rule_group/rule_instance/RuleDataId
severity string R Severity of the rule data (inherited from parent Rule
Instance)
*4 string R Status of the rule data (see notes below)
status
signature string R unique signature for the each rule data
*1 --- -- Each rule specific attributes available as a standalone
<rule_specific>
attribute from the rule data object. Please see the Rule
Reference for each rule specific attributes
rule_content_status dict R Statistics of the rule content status in Tcl dictionary
form.
For example : total <> status-a <> status-b <> status-c
<> ...
*2 collection R Collection of rule contents of the rule data, each rule
rule_contents
content object showing single line of rule data
rule_instance collection R Immediate rule instance of the rule data, collection
contains one rule instance object
rule_group collection R Immediate rule group object rule instance is created.
This can be an empty if the rule instance object is
directly instantiated under rule policy object. Collection
contains one rule group object
rule_policy collection R Rule policy object rule instance has been created,
collection contains one rule policy object
*3 collection R List of view criteria objects rule data is matched with
view_criteria
valid value : rule_data
Notes :
*1 : List of attributes for <rule_specific> represents the attributes of a rule data object. Rule data object
inherits attributes of each rule instance object and they can be accessed as an individual attribute via
get_attribute command. Please see each rule in the Rule Reference for rule data specific attributes.
*2 : Store set of rule content objects which represent the rule data results. Each rule content object
represents the information about each contributor to the rule data, there can be of multiple rule content
objects for a rule data when a rule data is is consists of multiple contributers to form it.
*3 : The attribute <view_criteria> indicates what view criterias have been applied to it. The <view_criteria>
attribute is a "read-only" attribute, user cannot set view_criteria on rule_data object, but they are propagated
down from <view_criteria> of rule policy/group/instance objects.

*4 : Attribute <status> of rule data is derived from status of rule_content_status and their type/level, hence
<status> attribute of rule data object is a "read-only" attribute. There are two status types, "review" and
"signoff" (see create_status command for more details for default labels available and associated level), if all
the rule_content_status has "signoff" type assigned then the rule data status is considered as "signoff", exact
label getting assigned to the status is depending on the name of the status and their level.
Example-1 : Following example shows that how type and level contribute to the status of rule data.
In this example, W_RECON_GROUPS rule data has 6 contributors (rule_contents) to it, two of the
rule_contents have been assigned a label with "SignedOff" (of type "signoff"), two of them have been
assigned to "Critical" (of type "review"), and rest of the two have been assigned to "ToBeReview" (of
type "review"). Now the <status> of rule data shows "Critical" as its status because label "Critical" is of
level 3 and "ToBeReview" is of level 4.
Example-2 : Following example shows that how the type "signoff" labels are used to derive the rule
data status. In the case, the status label "PreSignedOff" is of type "signoff" with level 5 and label
"signedOff" is also of type "signoff" but with level 6, as a result, the status of rule data is derived as
"PreSignedOff".

Rule Content Attributes

This table describes the set of attributes associated with rule content object.

Name (Read/Write)
ID string R Rule content ID
full_name string R Full name of the rule content, is rule_policy/rule_group/
rule_instance/RuleDataId/RuleContentId
severity string R Severity of the rule data (inherited from parent Rule Instance)
status string R Status of the rule data
signature string R unique signature for the each rule content

rule_content_status string R/W Status of the rule content, by default "New" is assigned to each
rule content
*1 --- --- Each rule specific attributes available as standalone attribute
<rule_specific>
from the rule data object. Please see the Rule Reference for each
rule specific attributes
rule_data collection R Immediate rule data object in which rule content belongs to,
collection contains one rule data object
rule_instance collection R Immediate rule instance of the rule content, collection contains
one rule instance object
rule_group collection R Immediate rule group object of the rule_instance is created.
This can be an empty if the rule instance object is directly
instantiated under rule policy object. Collection contains one rule
group object
rule_policy collection R Rule policy object rule instance has been created, collection
contains one rule policy object
*2 collection R List of view criteria objects rule content is matched with
view_criteria
valid value : rule_content
Notes :
*1 : List of attributes for <rule_specific> represents the table headers of the rule instance object. Rule data
object inherit all the table headers of each rule instance objects and they can be accessed as an individual
attribute. Please see each rule in the Rule Reference for rule data specific attributes.
*2 : The attribute <view_criteria> indicates what view criterias have been applied to it. The <view_criteria>
attribute is a "read-only" attribute, user cannot set <view_criteria> on rule_content object, but they are
propagated down from <view_criteria> of rule policy/group/instance objects.

Rule Reference
This Rule Reference lists all rules reported by Meridian CDC.

SDC/ENV Lint Checks

This chapter describes list of checks available for SDC and ENV syntax and semantic checks (category SDC_ENV_LINT).
These built-in rules are available in Meridian CDC, and can be used to create a user policy to meet user specific
methodology. These checks are run by read_sdc or read_env command while reading in design specification.

EMPTY_COLL
EMPTY_COLL reports the case when an object access command resulted in empty collection.
SEVERITY WARNING
CATEGORY SDC_ENV_LINT
RULE ATTRIBUTES
The following table describes the header attributes specific to EMPTY_COLL rule. These attributes are
available on Rule objects as well as rule instance objects in addition to the attributes mentioned in the rule
data attributes and rule content attributes respectively.

Name (Read/Write)
Command string R SDC or ENV command that is passed an empty collection

Location string R Location in the source file where the empty collection is
encountered
Details string R Information about the empty collection
DESCRIPTION
EMPTY_COLL is analyzed during the read_sdc step, it informs the user about cases where an object access
command resulted in an empty collection. In particular, this rule indicates that an object access command
such as get_clocks does not return any clock objects. If an object access command does not return any
objects, it is likely that any optimization or analysis related to those commands will be inaccurate as the
constraints will not be properly applied . The user should examine the reported SDC object access command
and modify the design constraints accordingly.
EXAMPLES
• Example-1 : This example returns an EMPTY_COLL if the design has no input port 'ina'
prompt> set_case_analysis 1 [get_ports ina*]
• Example-1 : This example returns an EMPTY_COLL is there is no 'clka' in the design

prompt> set_clock_uncertainty 1 [get_clocks clka]
RELATED VARIABLES

INCONSISTENT_MSTR_GEN_CLKS_SRC
INCONSISTENT_MSTR_GEN_CLKS_SRC reports the case when multiple clocks propagate to the master clock source of a
generated clock, and the pin on which the generated clock has been defined does not have multiple generated clocks
corresponding to each of the clocks that propagate.
SEVERITY ERROR
RULE ATTRIBUTES
The following table describes the header attributes specific to INCONSISTENT_MSTR_GEN_CLKS_SRC rule.
These attributes are available on rule objects as well as rule instance objects in addition to the attributes
mentioned in the rule data attributes and rule content attributes respectively.

(Read/Write)
MasterClock string R Name of clock object created at the master pin that
propagates to GenClockSource but does not have a generated
clock defined relative to it
MasterClockLocation string R Location in constraint file where the MasterClock is defined
GenClockLocation string R Location in the constraint file where the generated clock is
defined
GenClockSource string R Design object where the generated clock is created
SourceLocation string R Location in the source RTL file where the generated clock
design object is defined
Details string R Information about which clock created at the master
pin is missing an associated generated clock object at
GenClockSource
DESCRIPTION
INCONSISTENT_MSTR_GEN_CLKS_SRC is analyzed during the read_sdc, it informs the user about the case
where there is no generated clock created for each clock that is created relative to particular master pin. In
particular, this can be a case where 1) multiple clocks are created at a master clock pin, or 2) multiple clocks
propagate to the master pin; there should be a generated clock for each clock that fans into the master pin.
Generated clocks are intended to be direct divisions or multiples of other clock objects, and if there are
multiple clocks created at a master pin and not a corresponding generated clock, it is likely that there will be
missing clock waveforms which will lead to invalid results during optimization and analysis. The user should
determine if there are missing generated clock definitions, extraneous clocks defined at the master pin or if
the clock network needs to be modified and make the corresponding changes to the design constraints.
EXAMPLES

RELATED VARIABLES

INVALID_ARG_USAGE
INVALID_ARG_USAGE reports the case where a constraint argument or combination or arguments is invalid.
SEVERITY ERROR
RULE ATTRIBUTES
The following table describes the header attributes specific to INVALID_ARG_USAGE rule. These attributes are
available on rule objects as well as rule instance objects in addition to the attributes mentioned in the rule

Name (Read/Write)
Command string R SDC or ENV command with an invalid argument

Location string R Location in the source file where the command with the invalid
argument is used
Details Information about which argument is invalid
DESCRIPTION
INVALID_ARG_USAGE is analyzed during the read_sdc step, it informs the user about cases where a constraint
has an invalid argument or combination or arguments. In particular, this rule indicates that there an argument
might be an invalid type or value or if a combination of arguments is invalid. If a constraint does not follow
proper syntax, it is likely that any optimization or analysis related to those constraints will be inaccurate as
the constraints will not be properly applied . The user should examine the reported SDC command and modify
the design constraints accordingly.
EXAMPLES
• Example-1 : This example returns an INVALID_ARG_USAGE since there cannot be both a -rise_from and -from
in a set_false_path constraint
prompt> set_false_path -from [get_clocks CLK1] -to [get_clocks CLK2] -rise_from
[get_clocks CLK1]
RELATED VARIABLES

INVALID_SYNTAX
INVALID_SYNTAX reports the case where a constraint did not follow the proper syntax.
SEVERITY ERROR
RULE ATTRIBUTES
The following table describes the header attributes specific to INVALID_SYNTAX rule. These attributes are

Name (Read/Write)
Command string R SDC or ENV command that has invalid syntax

Location string R Location in the source file where invalid syntax is used
Details Information about what syntax is invalid in the given command
DESCRIPTION
INVALID_SYNTAX is analyzed during the read_sdc step, it informs the user about cases where a constraint does
not follow the proper SDC syntax. In particular, this rule indicates that there is an unexpected or missing
argument. If a constraint does not follow proper syntax, it is likely that any optimization or analysis related to
those constraints will be inaccurate as the constraints will not be properly applied . The user should examine
the reported SDC command and modify the design constraints accordingly.
EXAMPLES
• Example-1 : This example returns an INVALID_SYNTAX since there is an odd number of waveform
specifications
prompt> create_clock -name CLK -period 10 -waveform {0} [get_ports CLK]
• Example-1 : This example returns an INVALID_SYNTAX since there is missing "-to" strin
prompt> set_false_path -from [get_clocks CLK1] [get_clocks CLK2]
RELATED VARIABLES

MISSING_ARG
MISSING_ARG reports the case when a constraint is missing a required argument.
SEVERITY ERROR
RULE ATTRIBUTES
The following table describes the header attributes specific to MISSING_ARG rule. These attributes are

Name (Read/Write)
Command string R SDC or ENV command that is missing a required argument

Location string R Location in the source file where the command with a missing
argument is encountered
Details string R Information about required argument or combination of arguments is
missing
DESCRIPTION
MISSING_ARG is analyzed during the read_sdc step, it informs the user about cases where a constraint is
missing a required argument. If a constraint does not follow proper syntax, it is likely that any optimization
or analysis related to those constraints will be inaccurate as the constraints will not be properly applied. The
user should examine the reported SDC command and modify the design constraints accordingly.
EXAMPLES
• Example-1 : This example returns a MISSING_ARG since create_generated_clock requires a -source option
prompt> create_generated_clock -name CLK2 -divide_by 2 [get_nets CLK1]
• Example-2 : This example returns a MISSING_ARG since create_generated_clock requires a -add option with -
master
prompt> create_generated_clock -name CLK2 -source [get_ports CLK2] -master CLK1 -
divide_by 2 [get_nets CLK1]
RELATED VARIABLES

NON_GEN_CLK_IN_FANOUT
NON_GEN_CLK_IN_FANOUT reports the case where a clock object created using create_clock has been found in the fanout
of another clock.
SEVERITY WARNING
RULE ATTRIBUTES
The following table describes the header attributes specific to NON_GEN_CLK_IN_FANOUT rule. These
attributes are available on Rule objects as well as rule instance objects in addition to the attributes mentioned
in the rule data attributes and rule content attributes respectively.

(Read/Write)
Clock string R Name of clock object

Location string R Location in command file of clock object
ClockSource string R Source of Clock
SourceLocation string R Location in RTL of ClockSource
FaninClock string R Name of fanin clock
FaninClockLocation string R Location in command file of FaninClock
FaninClockSource string R Source of FaninClock
FaninSourceLocation string R Location in RTL of FaninClockSource
DESCRIPTION
NON_GEN_CLK_IN_FANOUT is analyzed during the read_sdc step, it informs the user about where an internal
clock created via create_clock has been identified as being in the fanout of another clock object. Generated
clocks are intended to be direct divisions or multiples of other clock objects, and if a clock created on a pin
that is in the fanout of another clock object is not generated it is very likely that any optimization or analysis
results will be invalid. The user should determine if a create_generated_clock command needs to be added or
if the clock network needs to be modified and make the corresponding changes to the design constraints.
EXAMPLES
RELATED VARIABLES

REF_CLK_NOT_IN_NETWORK
REF_CLK_NOT_IN_NETWORK rule the case where a clock is not in the transitive fanin of a specified reference pin
SEVERITY ERROR
RULE ATTRIBUTES
The following table describes the header attributes specific to REF_CLK_NOT_IN_NETWORK rule. These
attributes are available on rule objects as well as rule instance objects in addition to the attributes mentioned
in the rule data attributes and rule content attributes respectively.

(Read/Write)
MasterClock string R Clock object defined as a master clock that does not fan into
its associated generated clock
MasterClockLocation string R Location in the SDC file where MasterClock is created
GenClock string R Clock object created as a generated clock that is not in the
fanout of its master clock object
GenClockLocation string R Location in the source file where the GenClock is created
GenClockSource string R RTL design object where the GenClock is created
SourceLocation string R Location in the source RTL file where the GenClockSource is
defined
Details string R Information about which generated clock is not in the fanout
of its master clock
DESCRIPTION
REF_CLK_NOT_IN_NETWORK is analyzed during the read_sdc step, it informs the user about cases where the
specified reference clock does not reach the related design object. This check reports the following on a SDC
constraint:
• A generated clock is not in the fanout of the specified master clock
In each of these instances, if a clock does not reach the specifed object it is likely that there will be
unexpected results during optimization and analysis as the intended constraints will not be applied. The user
should determine if the particular command should be modified or if the clock network needs to be adjusted
and make the corresponding changes to the design constraints.
EXAMPLES

RELATED VARIABLES

UNMATCHED_PATTERN
UNMATCHED_PATTERN reports the case when no design object was found for a specified pattern in object access
command.
SEVERITY WARNING
RULE ATTRIBUTES
The following table describes the header attributes specific to UNMATCHED_PATTERN rule. These attributes are
Attribute Type Permission rule rule rule Description

Name (Read/Write) instance data content
Command string R SDC or ENV command with an unmatched

pattern used as an argument
Location string R Location in the source file where the
unmatched pattern is encountered
Details string R Information about which pattern passed to
the command was not matched, including any
matching substring
DESCRIPTION
UNMATCHED_PATTERN is analyzed during the read_sdc step, it informs the user about cases where a pattern
specified for an object access command does not return any design objects. In particular, this rule indicates
that an object access command such as "get_pins ina* inb*" returned a match for "ina" but not "inb". If a
pattern is not matched, it is likely that any optimization or analysis related to those commands will be
inaccurate as the constraints will not be properly applied . The user should examine the reported SDC object
access commands and modify the design constraints accordingly.
EXAMPLES
• Example-1 : This example returns an UNMATCHED_PATTERN for port inb* if the design has an input port 'ina'
but no input port 'inb'
prompt> set_case_analysis 1 [get_ports ina* inb*]

RELATED VARIABLES
None

INTENT (Setup) Checks

This chapter describes list of INTENT checks available. Rules mentioned here are all built-in rules available in Meridian
CDC, they can be used to create a user policy to meet user-specific methodology. These checks are run by the
analyze_intent command. The intention of these checks is to cover following aspects:
Checks whether the user-provided specifications are correct with respect to the design.
Checks whether the user-provided specifications are consistent. It checks the consistency
between the specifications to ensure the intent for verification. Command analyze_intent
also performs a specification consistency check between the top-level specification and the
preverified IP specification.
Checks whether the user-provided specifications cover the requirements for analysis. If user
specification is not provided, the analyze_intent command autogenerates the initial design
specification.

BLACK_BOX
BLACK_BOX reports black boxes in the design.
SEVERITY REVIEW
CATEGORY INTENT_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to BLACK_BOX. These attributes are available
on rule data and content objects in addition to the attributes mentioned in the rule data attributes and rule
content attributes respectively.

Name (Read/Write)
Module string R Name of the module
SampleInstance string R A sample instance of the module

Location string R Location of the sample instance in source code in format
"FileName:LineNo"
Info string R Information about whether module is auto blackboxed or
blackboxed by user; one of the following:
• User-defined-module: the module is defined but the user
explicitly blackboxed it during elaboration (-black_box option).
No clock domains are propagated from inputs to outputs.
• Missing-module: the module is not defined and was explicitly
blackboxed during elaboration (-black_box option). No clock
domains are propagated from inputs to outputs.
• Unknown-missing-module: missing modules automatically
blackboxed during elaboration (-auto_black_box option).
• Auto-RAM: array treated as RAM because it meets the modeling
criteria threshholds(controlled by variables ri_ram_min_size,
ri_ram_min_words, ri_ram_max_reset_count)
• Auto-large-array: large array not modeled because it is
not recognized as a RAM and it exceeds resource constraint
thresholds (controlled by variables ri_max_single_range_bits and
ri_max_total_range_bits). No clock domains are propagated from
inputs to outputs.
• Auto-operator: An operator (such as * or /) automatically
blackboxed; mesh models are used to propagate clock-domain
information from inputs to outputs.

DESCRIPTION
These are blackboxes in the design.
RELATED VARIABLES
ri_report_black_box
ri_create_inputs_on_black_box_outputs

I_CLK_DOMAINS
I_CLK_DOMAINS reports the clock domains in the design.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_CLK_DOMAINS. These attributes are available

(Read/Write)
Domain string R Name of the clock domain. The domain refers to the master
waveform (added using create_waveform in ENV), while the
Waveform refers to the actual waveform name itself (added
using
create_waveform or create_derived_waveform). So, in the case
of reporting the master itself, both Domain and Waveform will
be the same. When reporting derived waveforms, they will be
different.
Waveform string R Waveform name of the clock
NormalizedPeriod float R Clock period after normalization
SpecifiedPeriod float R Specified period of the clock
RELATED VARIABLES
None

I_CLK_TREES
I_CLK_TREES reports clock trees in the design.
Note: Meridian Physical CDC does not support this rule check.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_CLK_TREES. These attributes are available

Name (Read/Write)
ClockDomain string R Name of the clock domain
Level string R Level of the tree

Signal string R Signal on which clock is defined
Alias string R Aliases of clock pin signal
RELATED VARIABLES
ri_report_i_clk_trees
ri_report_i_clk_tree_alias_names

I_CONSTANT
This section list the signals that evaluate to constant value.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_CONSTANT. These attributes are available

Name (Read/Write)
Signal string R Name of the signal which constant
Location string R Location of the signal in source file in format "FileName:LineNo"

Value string R Constant value applied; if the source of the constant comes from
an ENV file (such as a create_reset or a set_constant), it is so
noted
EnvFileLocation string R Location of the command in the environment file
DESCRIPTION
I_CONSTANT list out the signals that evalute to constant value. Possible values can Logic-1 or Logic-0. The
signals can evaluate to constant because of set_constant or create_reset in environment file.
RELATED VARIABLES
ri_restrict_to_definite_constants
ri_report_all_signals_in_i_constant
ri_report_i_constant

I_HENV_DB_MAP
This category reports module name to database mapping for hierarchical flow.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_HENV_DB_MAP. These attributes are available
on rule objects as well as on rule instance objects, in addition to the attributes mentioned in the rule
attributes and rule instance attributes, respectively.

Name (Read/Write)
Name string R Name of the database

Project string R Name of the block-level project directory
Location string R Location of read_cdc_db command for this module in the run
script
Module string R Module name of the block being replaced with the db
Instance string R Instance name(s) of the module being replaced by the db
RELATED VARIABLES
None

I_HENV_WAVE_MAP
This category reports top level to block-level waveform mapping for hierarchical flow.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_HENV_WAVE_MAP. These attributes are
available on rule objects as well as on rule instance objects, in addition to the attributes mentioned in the rule

Name (Read/Write)
Module string R Name of the block-level module name

SampleInstance string R One sample instance name of module
BlockWaveform string R Block-level waveform name
TopWaveform string R Top-level waveform name
RELATED VARIABLES

I_RST_SIGNAL
I_RST_SIGNAL reports reset signals in the design.
SEVERITY INFO
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_RST_SIGNAL. These attributes are available

Name (Read/Write)
ClockDomain string R Name of the clock domain of reset signal
ResetSignal string R Name of the reset signal

Polarity string R Polarity Active-High or Active-Low of reset signal
RELATED VARIABLES
None

S_CLK_GATE_NO_WAVE
S_CLK_GATE_NO_WAVE reports the case where a clock gating signal is missing a waveform environment specification.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_CLK_GATE_NO_WAVE. These attributes are

(Read/Write)
ClockGateSignal string R Name of the gated clock signal created by the GatingSignal
GatingSignal string R Clock gate enable signal that is missing an associated waveform
Location string R Location in the source RTL file where the GatingSignal is
declared
DESCRIPTION
S_CLK_GATE_NO_WAVE is analyzed during the analysis setup step. It informs the user about cases where a
clock gating signal does not have an associated waveform environment specification. This can be related to a
missing specification in the environment file, or a missing or incomplete input delay constraint on the clock
gating signal. If a clock gating signal is missing a waveform specification, Meridian CDC will not analyze any
potential crossings associated with the clock gating structure during analysis, which can make the analysis
results unreliable. It is important to determine the appropriate specification to be associated with the clock
gating signal and make the necessary changes to the environment file or to the design constraints.
Suggested Action: Complete the waveform specifications as pointed out in the rest of the setup report.
Examine the logic to determine the cause and its impact on the analysis.
EXAMPLES

RELATED VARIABLES
ri_report_s_clk_gate_no_wave

S_CLK_OFF_SUB_TREE
S_CLK_OFF_SUB_TREE reports the case where a subtree of the clock distribution network has been disabled.
SEVERITY WARNING
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_CLK_OFF_SUB_TREE. These attributes are

Name (Read/Write)
ClockNet string R Name of net at root of clock subtree that is disabled

DrivenFlop string R Instance name of a flop that is being clocked by the subtree that is
disabled
Location string R Location in RTL where the net specified in ClockNet is declared
Info string R Information locator string used to access and display available
debug information in iDebug (see Understanding Debug
Information). For example, debug cone information.
DESCRIPTION
S_CLK_OFF_SUB_TREE is analyzed during the analysis setup step. It informs the user about cases where part
of a clock distribution network has been disabled. This can be related to an incorrect specification in the
environment file or incorrect logic. An example of this would be a case where some flops in a clock network
are in reset when flops in the other part the network are not. If a part of a clock tree is disabled, Meridian
CDC will not analyze any potential crossings associated with the registers along this subtree during analysis,
which can make the analysis results unreliable. It is important to determine the appropriate environment
specification or clock tree structure and make the necessary changes to the environment file or the design
logic.
Suggested Action: Examine the clock net where the clock is not propagating. Fix if not intentional;
otherwise, sign off.
EXAMPLES

RELATED VARIABLES
ri_report_s_clk_off_sub_tree

S_COMBO_LOOPS
S_COMBO_LOOPS reports the presence of combinational cycles in the design.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_COMBO_LOOPS. These attributes are available

Name (Read/Write)
Signal string R Node along the loop

Location string R Location in RTL of Signal
AliasName string R Alternate name for when Signal changes as it crosses a module
boundary
DESCRIPTION
The presence of combinational cycles in the design can invalidate the results of formal analysis. Also, cycles
can generate internal errors in the tools. As a result, formal analysis will not be run when these cycles
participate in the logic to be analyzed.
Suggested Action: Break combinational loops by creating an input/constant spec on appropriate inputs or
internal signals or black box the modules having loops.
EXAMPLES
RELATED VARIABLES
ri_report_static_loops

S_CONF_ENV
S_CONF_ENV reports the case where there is a conflict between an environment specification and the driving condition
of a net in the design.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_CONF_ENV. These attributes are available on
rule objects as well as on rule instance objects, in addition to the attributes mentioned in the rule attributes
and rule instance attributes, respectively.

(Read/Write)
SpecSignal string R Signal in the design that has a conflicting environment

specification
Location string R Location in the source RTL file where the SpecSignal is declared
PropagatedValue string R Value determined by the driving condition seen in the design
on the SpecSignal. For create reset specs, this is one of Enable
Reset or Disable Reset, depending on whether the conflict is
during the time when reset is asserted or deasserted. Enable
Reset says the signal with the reset spec gets a conflicting value
in the assert phase, and likewise for Disable Reset.
UserSpecType string R Type of environment specification that is created on the
SpecSignal
• set_constant - When set_constant in environment differs from
design constant propagation. Propagates Value Indicates the
value propagated from design.
• create_reset - It can either be in waveform of create_reset or
conflict in the value during reset assert or deassert.
• create_clock - When there is conflict in create_clock
waveform specified with design driving conditions.
• create_input - When there is conflict in create_input
waveform specified with design driving conditions.
EnvLocation string R Location in the environment file of the conflicting environment
specification
Information)

DESCRIPTION
S_CONF_ENV is analyzed during the CDC setup analysis step, it informs the user about cases where there is a
conflict between an environment specification and the driving condition of a net in the design. An example of
this would be a create_input environment specified on an internal pin relative to a clock that is not the clock
actually driving the pin in the design. In this case if there is a conflict between the environment specification
and design behavior, Meridian CDC will choose the environment specification during CDC analysis which can
make the analysis results unreliable. The user should determine if the environment file or design logic is
incorrect and make the necessary changes to environment file, design constraints or design code.
If there is a a set_constant defined on a net in environment specifications that conflicts with driving conditions
of the net in the design, S_CONF_ENV is not issued. A warning is issued in the log file and environment
conditon is ignored.
Suggested Action: Examine the inconsistency to ensure that the design is properly setup and that the analysis
results are reliable.
EXAMPLES
RELATED VARIABLES
ri_report_s_conf_env

S_GENCLK
S_GENCLK reports the case where a clock network is driven by an internally generated signal.
SEVERITY WARNING
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_GENCLK. These attributes are available on

(Read/Write)
ClockTreeSignal string R Name of clock signal identified as a generated clock

Location string R Location in the source RTL file where the ClockTreeSignal is
created
DrivenFlop string R Instance name of a flop that is in the clock network of
ClockTreeSignal
DrivenFlopLocation string R Location in the source RTL file where the DrivenFlop instance
is delcared
Information).
DESCRIPTION
S_GENCLK is analyzed during the CDC setup analysis step, it informs the user about cases where an internally
generated net is driving a clock network. Because these types of clocks lack a precise environment
specification, Meridian CDC cannot determine the value of a generated clock at any given time, only that the
value is changing. If this is the case, Meridian CDC will dump all analysis related to these networks into the
W_G_CLK_GLITCH, which can make the analysis results unreliable or difficult to debug.
Suggested Action: The user should determine the appropriate waveform to apply to the generated clock
and make the necessary changes to the environment file or design constraints.
EXAMPLES

RELATED VARIABLES
ri_report_s_genclk

S_HENV_ATTR_CONFLICT
This category lists the signals that have the same environment behavior at the TOP and BLOCK levels, but with
conflicting attributes.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_HENV_ATTR_CONFLICT. These attributes are

(Read/Write)
Signal string R Primary module input that has the same environment behavior
at top and block levels, but with conflicting attributes
Location string R Location in the source RTL file where the primary input
specified in Signal is registered
Module string R Block module name
BlockSignal string R Name of signal in block module
SpecType string R Environment type of signal
BlockAttr string R Block-level spec attribute
BlockSpecLocation string R Location in environment file of block-level spec

TopAttr string R Top-level spec attribute
TopSpecLocation string R Location in environment file of top-level spec
Information)
DESCRIPTION
This category reports signals that have the same environment behavior at the TOP and BLOCK levels, but with
conflicting attributes.
Suggested Action: Resolve the mismatch by correcting block or top env file.
RELATED VARIABLES
None


S_HENV_EXTRA_SPEC
This category lists the signals that have an environment behavior specified at the BLOCK level but not at TOP level
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_HENV_EXTRA_SPEC. These attributes are

(Read/Write)
BlockSignal string R Signal name at the block level

Location string R Location of signal in RTL
BlockSpecType string R Block-level spec type misssing at top level
BlockSpecLocation string R Location in environment file of block-level spec

TopSpecType string R
TopSpecLocation string R
Information)
DESCRIPTION
This category reports signals that have an environment behavior specified at the block level, but not at the top
level.
RELATED VARIABLES
None

S_HENV_MISSING_SPEC
This category lists the signals that have an environment behavior specified at the TOP level but not at BLOCK level.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_HENV_MISSING_SPEC. These attributes are

(Read/Write)
Signal string R Signal name at the top level

Module string R Block-level module name
BlockSignal string R Block-level signal name
TopSpecType string R Top-level spec type misssing at block level
TopSpecLocation string R Location of top-level spec in environment file

Information)
DESCRIPTION
RELATED VARIABLES
None

S_HENV_TYPE_CONFLICT
This category lists the signals that have incompatible environment type at the TOP level compared to the BLOCK level
specification.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_HENV_TYPE_CONFLICT. These attributes are

(Read/Write)

Module string R Block-level module name
BlockSignal string R Block-level signal name
BlockSpecType string R Block-level spec type
BlockSpecLocation string R Block-level spec location in environment file
TopSpecType string R Top-level spec type misssing at block level

Information)
DESCRIPTION
RELATED VARIABLES
None

S_HENV_WAVE_CONFLICT
This category lists the Asynchronous vs Synchronous incompatibilities between waveforms at the TOP level to those
they correspond at the BLOCK level. Each violation is listed as a group of lines.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_HENV_WAVE_CONFLICT. These attributes are

(Read/Write)

Module string R Block level module name
Instance string R Instance name of block level
BlockWaveform string R Block-level waveform name
TopWaveform string R Top-level waveform name
BlockSpecLocation string R Block-level spec location in environment file
BlockRelation string R Relation at block level

TopRelation string R Relation at top level
Information)
DESCRIPTION
RELATED VARIABLES
None

S_INPUT_NO_WAVE
S_INPUT_NO_WAVE reports the case where the clock waveform associated with a primary input is unknown.
For each input with no specified clock-domain, one sample flop per unique driven domain is reported.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_INPUT_NO_WAVE. These attributes are

(Read/Write)
Signal string R Primary input that does not have an associated clock
waveform
SampleFanout string R Instance name of a flop that whose input data is tied to the
input with no clock waveform
FanoutClockDomain string R Clock domain driving the instance specified in SampleFanout
Location string R Location in RTL where the unassociated input is sampled at
Fanout
Information).
DESCRIPTION
S_INPUT_NO_WAVE is analyzed during the CDC setup analysis step, it informs the user about cases where
a primary input is not associated with a clock waveform. This can be related to a missing 'create_input' in
the environment file. If no clock domain is associated with a primary input Meridian CDC will not analyze
any potential crossings associated with the input during CDC analysis which can make the analysis results
unreliable. The user should determine the appropriate waveform to be associated with the specified input and
make the necessary changes to the environment file or design constraints.
Suggested Action: Specify clock domains for these inputs in the environment file.
EXAMPLES

RELATED VARIABLES
ri_report_s_input_no_wave

S_MULTCLK
S_MULTCLK reports the case where a register in the design has multiple clock waveforms propagating to it.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_MULTCLK. These attributes are available on

(Read/Write)
ClockTreeSignal string R Name of signal that has multiple clock waveforms progating to
it
Location string R Location in RTL where ClockTreeSignal is declared
ClockDomain string R Name of clock domain associated with DrivingNet
PropagatedDomain string R Clock waveform Meridian CDC has chosen to propagate onto
the ClockTreeSignal for CDC analysis
SampleFlop string R One flop instance driven by signal with multiple clock
waveforms propagating to it
Info Indicates whether DrivingNet is a Clock or Non-Clock object:
• Clock indicates there is a create_clock spec on this net.
• Non-Clock indicates there is no clock environment spec on
this net; it could be a clock gate enable or MUX select.
DrivingNet string R Name of internal net driving onto ClockNet
DESCRIPTION
S_MULTCLK is analyzed during the analysis setup step, it informs the user about cases where there are flops
in the design that are being clocked by multiple waveforms In particular, this can be the case where there is
no constant set on the select line of a multiplexor selecting between two clocks. If there are multiple clocks
propagated to a flop instance, Meridian CDC will arbitrarily select the waveform for used for analysis and the
corresponding results will not be reliable. It is important to determine whether the select signal can be set to
a constant value using a set_constant command and add the appropriate constraints to the environment file or
design constraints.
Suggested Action: Trace back from the clock mux to specify mode selection values on mode signals in the
environment file.

EXAMPLES
RELATED VARIABLES
ri_report_s_multclk
ri_report_s_multclk_verbose

S_NET_NO_WAVE
S_NET_NO_WAVE reports the case where the clock waveform associated with an internal net is unknown.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_NET_NO_WAVE. These attributes are available

(Read/Write)
Signal string R Driver of internal net that does not have an associated clock
waveform
DriverType string R Type of driver: either UnDriven or BBoxOut
SampleFanout string R Instance name of a flop that is sampling the net that does not
have an associated clock waveform
FanoutClockDomain string R Clock domain associated with the flop specified in
SampleFanout
Location string R Location in RTL where the net with no associated clock
waveform is registered at SampleFanout
Information)
DESCRIPTION
S_NET_NO_WAVE is analyzed during the CDC setup analysis step, it informs the user about cases where an
internal net is not associated with a clock waveform. This can be related to an incomplete environment
specification or the net being driven by a blackbox module, in which case Meridian CDC may not be able to
determine the appropriate waveform to apply to the net. If no clock domain is associated with an internal net,
Meridian CDC will not analyze any potential crossings associated with the net during CDC analysis which can
make the analysis results unreliable. The user should determine the appropriate waveform to associated with
the specified net and make the necessary changes to the environment file or design constraints.
Suggested Action: Check to see if the nets are going to flops, either directly or via combinational logic.
If not, they can be ignored from a CDC perspective. If they are, specify clock domains for these nets in the

environment file. When a clock is generated from within a black box, add a create_clock to the generated
ENV file and then rerun with the modified ENV file: read_env modified_env_file.env; analyze_intent -
output_env new_env_file.env. This will then generate the new clock and any blackbox outputs that should
have a create_input spec using that waveform.
EXAMPLES
RELATED VARIABLES
ri_report_s_net_no_wave

S_NOCLK
S_NOCLK reports the case where an identified clock signal is missing an environment specification.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_NOCLK rule. These attributes are available on

(Read/Write)
ClockTreeSignal string R Clock net that does not have an associated clock waveform
Location string R Location in RTL where the unassociated clock is declared
DrivenFlop string R Instance name of a flop that is driven by the ClockTreeSignal
DrivenFlopLocation string R Location in RTL where DrivenFlop is instantiated
Information)
DESCRIPTION
S_NOCLK is analyzed during the CDC setup analysis step. This check identifies signals that Meridian CDC
expects to have an associated clock waveform based on analysis of the RTL. If a clock waveform is not created
on an identified clock signal, all of the sequential cells in the fanout of that clock object will not be included
in CDC analysis and the corresponding results will be invalid and incomplete. The user should examine the
identified clock objects and add corresponding create_clock and create_waveform commands to the design
constraints or environment file.
Suggested Action: The user should investigate the indicated node and determine which waveform should be
associated with the missing clock. Specify a clock on the signal in the environment file.
EXAMPLES

RELATED VARIABLES
ri_report_s_noclk

S_NORST
S_NORST reports the case where a reset sub-tree structure in the design does not have an associated reset environment
specification.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_NORST rule. These attributes are available on

(Read/Write)
ResetTreeSignal string R Net at root of reset structure that is missing an

environment specification
DrivenFlop string R Instance name of a flop that is being reset by the
structure that is missing an environment specification
Location string R Location in RTL where ResetTreeSignal is declared
DrivenFlopLocation string R Location in RTL where the instance specified in DrivenFlop
is declared
DrivenFlopClockDomain string R Clock domain driving the instance specified in DrivenFlop
Reason string R Reason that the reset structure does not have an
environment specification
Info string R Information locator string used to access and display
available debug information in iDebug (see Understanding
Debug Information)
Polarity string R Polarity of reset structure driven by ResetTreeSignal
DESCRIPTION
S_NORST is analyzed during the CDC setup analysis step, it informs the user about cases where a reset
structure in the design does not have an associated reset environment specification. This can be related to a
missing reset specification in the environment file or a reset specification that has not completely propagated
through some reset distribution networks in the design. If a reset structure is missing a reset specification,

Meridian CDC will not analyze any potential crossings associated with the reset structure during CDC analysis
which can make the analysis results unreliable.
Suggested Action: The user should determine the appropriate reset specification to be associated with the
reset signal and make the necessary changes to the environment file.
EXAMPLES
RELATED VARIABLES
ri_report_s_norst

S_NUM_ANALYSIS_TIME_SLICES
S_NUM_ANALYSIS_TIME_SLICES reports the number of time slices created by each aligned clock event in the overall
period.
SEVERITY WARNING
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_NUM_ANALYSIS_TIME_SLICES. These attributes
are available on rule objects as well as on rule instance objects, in addition to the attributes mentioned in the
rule attributes and rule instance attributes, respectively.

Name (Read/Write)
NumTimeSlices integer R Number of time slices
DESCRIPTION
Formal analysis works with the overall periodicity of the specified clocks. This period is the LCM (Least
Common Multiple) of the periods of each specified waveform. A time slice is created by each aligned clock
event in the overall period. If the number of time slices is large, verification performance can be severely
affected. Typically, this number should be less than 10.
Suggested Action: Adjust the Clock cycle periods and offsets/duty-cycles such that different waveform
periods are integral multiples so that the LCM period is reduced and clock edges get better aligned.
EXAMPLES
RELATED VARIABLES
ri_report_s_num_analysis_time_slices

S_OUTPUT_NO_WAVE
S_OUTPUT_NO_WAVE reports the case where the clock waveform associated with a primary output is unknown.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_OUTPUT_NO_WAVE. These attributes are

(Read/Write)
Signal string R Primary module output that does not have an associated
clock waveform
SignalLocation string R Location in RTL where the unassociated output is declared
SampleFanin string R Instance name of a flop that whose output data is tied to
the output with no clock waveform
FaninLocation string R Location in RTL where the unassociated output is driven
FaninClockDomain string R Clock domain driving the instance specified in SampleFanin
ClockDomainLocation string R Location in environment file where the clock domain
associated with FaninClockDomain is created
DESCRIPTION
S_OUTPUT_NO_WAVE is analyzed during the CDC setup analysis step, it informs the user about cases where
a primary output is not associated with a clock waveform. This can be related to a missing 'create_output'
in the environment file or a missing 'set_output_delay' in the SDC file. If no clock domain is associated with
a primary output Meridian CDC will not analyze any potential crossings associated with the input during CDC
analysis which can make the analysis results unreliable. The user should determine the appropriate waveform
to be associated with the specified output and make the necessary changes to the environment file or design
constraints.
Suggested Action: Specify clock domains for these outputs in the environment file or design constraints.

EXAMPLES
RELATED VARIABLES
ri_report_s_output_no_wave

S_RST_INV
S_RST_INV reports the case where a reset environment specification is inverted from what is actually in the design.
SEVERITY ERROR
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to this rule check. These attributes are available

(Read/Write)
SampleFlop string R Example of a register that is being reset by the inverted reset
signal
SampleFlopLocation string R Location in RTL where the inverted reset is sampled
ResetTreeSignal string R Name of inverted reset signal identified as the root of the
reset tree going into the Sample Flop
Location string R Location in RTL of ResetTreeSignal
Active string R Indicates whether the ResetTreeSignal is active-high or
active-low
ResetType string R Type of reset:
• Primary -- from a port
• Functional -- from a flop
Information);Level is the number of flops that are between
the ResetTreeSignal and the SampleFlop
DESCRIPTION
S_RST_INV is analyzed during the CDC setup analysis step, it informs the user about cases where a reset in
the design conflicts with the environment specification. In particular, this check indicates a scenario where a
register in the design has an active-high reset and the reset is configured in the environment with 'create_reset
-low' or where a register in the design has an active-low reset but is configured in the environment with
'create_reset'. If there is a conflict between the design and the environment specification, it is possible that
there is an issue with the reset network logic which can affect design operation or formal verification.

Suggested Action: The user should determine if the reset network logic needs to be changed or if the
environment specification is inccorrect and make the necessary changes to the environment file or design
logic.
EXAMPLES
RELATED VARIABLES
ri_report_s_rst_inv
ri_report_s_rst_inv_verbose

S_UNINIT_FLOPS_LATCHES
When you run analyze_intent -formal, S_UNINIT_FLOPS_LATCHES reports the list of flops and latches in the design that
are not initialized.
SEVERITY WARNING
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_UNINIT_FLOPS_LATCHES. These attributes are

Name (Read/Write)
Signal string R Name of uninitialized flop or latch in the design

FunctionType string R Flop or Latch
Value string R Initial value of signal: X or Z
Location string R Location in RTL of Signal
SUGGESTED ACTION
Review and confirm that uninitialized flops and latches are intentional. Fix the design if unintentional;
otherwise, sign off.
RELATED VARIABLES
ri_report_uninitialized_flops_latches

S_UNKNOWN_CLKPOL
S_UNKNOWN_CLKPOL reports the case where the polarity of a clock tree signal cannot be determined.
SEVERITY WARNING
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to S_UNKNOWN_CLKPOL. These attributes are

(Read/Write)
ClockTreeSignal string R Clock net whose polarity cannot be determined

Location string R Location in RTL where the unknown polarity clock is created
ClockDomain string R Clock domain associated with the signal specified in DrivingNet
PropagatedPhase string R
SampleFlop string R Instance name of a flop that is on the network of the
ClockTreeSignal
Info string R Indicates whether DrivingNet is a Clock or Non-Clock object:
• Clock indicates there is a create_clock spec on this net.
• Non-Clock indicates there is no clock environment spec on this
net; it could be a clock gate enable or MUX select.
DrivingNet string R List of nets that are driving into the logic that is creating an
unknown polarity on ClockTreeSignal
DESCRIPTION
S_UNKNOWN_CLKPOL is analyzed during the setup analysis step, it informs the user about cases where the
polarity of a clock tree signal cannot be determined by Meridian CDC. This can be caused by the presence
of an XOR gate in the clock network, a clock driving the select input of a clock mux or a clock mux selecting
between a clock and its inverse. If a clock network has an unknown polarity, Meridian CDC will not analyze any
potential crossings associated with the registers along this sub-tree during formal analysis, which can make the
analysis results unreliable.
Suggested Action: Determine the appropriate environment specification or clock tree structure and make
the necessary changes to the environment file or the design logic.
EXAMPLES

RELATED VARIABLES
ri_report_s_unknown_clkpol

CDC Checks
Meridian CDC provides CDC checks as built-in rules that can be used to create a user policy to meet your specific
methodology. These checks are run by the verify_cdc or verify_cdc_formal command.

CLK_GROUPS
Reports identified clock groups.
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to this rule. These attributes are available on rule
data and content objects in addition to the attributes mentioned in the rule data attributes and rule content
attributes respectively.

Name (Read/Write)
Domain string R Clock domain name
ClockNames string R List of clock names in this domain

FromClock string R Launch clock name
ToClock string R Capture clock name
Relationship string R Relationship between FromClock to ToClock. Async means FromClock
and ToClock are considered asynchronous to each other during CDC
analysis, even if they are in the same clock domain.
Note: Two clocks belonging to different domains are considered
asynchronous to each other. Two clocks belonging to the same domain
are considered synchronous to each other, unless Async is specifically
mentioned in this report.
SdcLocation string R Location (<file>:<line>) of the command creating the identified
primary clock domain (create_waveform command when Meridian
CDC infers clock groups from an ENV file, or set_clock_groups
command when Meridian CDC infers clock groups from an SDC file).
DESCRIPTION

This category lists the set of primary clock domains in the design. Within each domain, the set of derived
waveforms, synchronous to each other by default, are reported. For each derived waveform, a list of local
asynchronous overrides are provided, while displaying the user command that caused the async relation.
RELATED VARIABLES
ri_report_clk_groups

CNTL
Asynchronous boundary signal feeding a synchronizer is identified as a CONTROL (CNTL) signal and reported in this
category. The synchronizer can be one, two, three, or more flop stages.
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to CNTL. These attributes are available on rule
attributes, respectively.

(Read/Write)
Signal string R Name of the signal crossing between clock domains
ReceivingFlop string R Name of the first flop in receive domain

ClockDomains string R From To clock domains in format "FromClock::ToClock"
Location string R Location of ReceivingFlop in source in format
"FileName:LineNo"
SyncFlop string R Name of the final flop in synchronizer
SyncDepth integer R Number of flop stages in synchronizer
Association string R Type of DATA-CNTL association (see table below)

Debug Information). For example, crossing paths information.
ClkInteractionType string R Keyword describing the clock interaction; one of FastToSlow,
SlowToFast, or SameFreq
FailDepth string R Fully analyzed failures show FailedFull. Otherwise, the value
is the depth at which it failed. Failure at a depth means it
failed at an incomplete depth and the check might pass if
you increase the flop depth. FailedFull means the result will
not change even if you increase flop depth.
Association
The association type can be any of the following.

Association Description
Type
DATA CNTL Signal has the potential to block the loading of metastable data into flops.
Is-Feedback These are signals from the receiving domain which are synchronized back into the
sending domain, as part of a data-transfer protocol.
Has-Feedback A Feedback is associated with the CNTL crossing. Path information is available in
the .dbg file.
Has-Err- A potential erroneous feedback is associated with the CNTL crossing. Path information
Feedback is available in the .dbg file. This association is not reported by default. To enable
reporting of this category, set variable ri_report_err_feedback to true.
Blocked The CNTL association is blocked. The association can be blocked because
• The association is blocked by constant
• CNTL has no load i.e. not driving any fanout. Note: Output port is considered a load.
• CNTL drives a black box
User Users have instructed Meridian CDC to report these control crossings within the listed
modules as User status using the Tcl variable ri_user_associated_cntl.
None Unsynchronized crossings are not detected to be controlled by these signals. Typically,
synchronized signals are expected to be controlling data crossings. The use of the
synchronizer may not be necessary or these signals may need to be reclassified as
data crossings. Check whether "set_cntl_association_depth" is lesser than needed for
association. Reclassify the signal as data if its not a CNTL signal.
DESCRIPTION
Asynchronous boundary signal feeding a synchronizeris identified a CNTL signal. The synchronizer can be one, two,
three, or more flop stages.
A CNTL signal is typically used to control DATA crossings to ensure metastability-free transfer of DATA.
The structural Association of a CNTL signal has the following categories
DATA
Meridian CDC detected synchronized CONTROL signals blocking or controlling DATA signals in the receive clock domain.

For example, in figure a synchronized control signal, “Sync Control”, is controlling a data signal, “Tx Data”. Meridian
CDC reports such a control signal as Data associated. User can dis-associate a CNTL crossing by providing the name
of the receiving flop to variable ri_exclude_cntl_from_association. Such CNTL crossings are reported with User
association.
Suggested Action: Ensure that the Control signal and DATA signal association that Meridian CDC reported is correct.
Is-Feedback
Meridian CDC detected synchronized CNTL signal(s) blocking or controlling DATA signals in the receive clock domain and
also, this CNTL signal(s) is being fed back to the transmit domain. Typically, such asynchronous interface structures are
used in handshaking protocols.

For example, in Figure a synchronized control signal, “Sync control”, is controlling a data signal, “Tx Data”. This CNTL
signal is also fed back to the Tx domain. Meridian CDC reports such a control signal as Is-Feedback associated.
Suggested Action: Ensure that the CNTL signal and the Feedback signal that Meridian CDC reported is correct.
Has-Feedback
Meridian CDC detected synchronized CNTL signal that has a feedback associated with it. Detailed path information is
available in the .dbg file.

Suggested Action: Examine the CNTL and feedback signals to ensure functionality is correct.
Has-Err-Feedback
Meridian CDC detected synchronized CNTL signal structurally associated with DATA signals but they are feeding back
to the transmit domain before they get a chance to control the data crossing.

For example, in Figure, a synchronized control signal “Sync Control” controls a data signal, “Tx Data”. The signal fed
back to the transmit domain has one more synchronization stage than the control signal. Meridian CDC reports such
a control association as Has-Err-Feedback. In general, there are two causes for Meridian CDC to identify a feedback
signal as Err-Feed- back:
• In Load control situation, the control to feedback path flop depth (from B to C) is at least one more than the
control to data path flop depth (from A to B)
• In FIFO control situation, the control to feedback path flop depth is at least as long as the control to data path
flop depth.
This association status is not reported by default. Set variable ri_report_err_feedback to true to enable reporting of
this association.
Suggested Action: Examine these crossings to ensure the functionality is correct.
Blocked
Meridian CDC detected synchronized CNTL signals that are either blocked by constants or don’t drive anything.

For example, in Figure, a signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock domain.
This crossing is controlled by a synchronized control signal, “Sync Control”. The loading of “Tx Data” into the receive
domain flop, “Rx Data”, is blocked by the signal, “Sync Control”, due to the constant disabling the output of the AND
gate. Meridian CDC reports such a DATA-CNTL association as Blocked
Suggested Action: Examine the CNTL signals to make sure the logic is intended.
User
When users provide a list of modules using command set_user_association -cntl_rx or a list of receiving flops to variable
ri_exclude_cntl_from_association, Meridian CDC considers the specified control signals as User associated.
None
Meridian CDC detected synchronized CNTL signals that are not blocking or controlling any DATA signals. Typically,
synchronized CNTL signals are expected to be controlling DATA crossings.
Suggested Action: The use of the synchronizer may not be necessary or these signals may need to be reclassified as
data crossings.
RELATED VARIABLES
ri_report_number_of_drivers_for_cntl
ri_report_none_as_w_cntl
ri_report_w_cntl
ri_verify_cntl_glitches
ri_verify_one_cntl_bit_per_bus
RECLASSIFY

You can use the Reclassify section of the Engine Actions menu ribbon in iDebug to reclassify a control signal as a data
signal or a data signal as a control signal. You can also remove reclassifications or save them to a file.
Alternatively, you can right-click a row in the rule instance data table on the Data pane to display a popup menu from
which you can select a Reclassify submenu item.
To reclassify a signal, select or right-click the row in the rule instance data table and click Reclassify.
When you reclassify a signal, the data in the row appears in blue italics:
Other actions you can perform on reclassifications include the following:
• To write all reclassifications for the current rule instance to a file, click Save to File.
• To remove a single reclassification, select the reclassification and click Remove Reclassify.
• To remove all reclassifications for the current rule instance, select Remove All.
RUN FORMAL CDC ANALYSIS

You can use the Run Formal menu actions in iDebug to flag instances for formal CDC verification. Once flagged, your
selections determine the scenario for formal CDC analysis using the verify_cdc_formal command the next time you run
using the same RIDB (using -previous|-previous_project).
Run Formal Menu Action Description

By Rule Content Flags rule instance data for all selected rows; formal CDC
analysis will be run based on rule content for all selected rows
Note: You can select more than one contiguous row using Shift-
click, and add/remove rows from your selection set using Ctrl-
click.

By Rule Data Flags all rule instance data whose RuleDataId matches all
RuleDataId values from the selected rows; formal CDC analysis
will be run based on rule data for all selected rows
By Match for ReceivingFlop Flags all rule instance data where the value in ReceivingFlop
matches the value(s) in ReceivingFlop for the selected rows;
formal CDC analysis will be run based on all ReceivingFlop
matches for all selected rows
Show All for CNTL Opens the Active Run Formal dialog displaying the rule instance
data flagged for formal CDC analysis for the rule instance you are
viewing

DATA
Asynchronous boundary signal not feeding a synchronizer is identified as a DATA signal and reported in this category.
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to DATA. These attributes are available on rule

Name (Read/Write)
ReceivingFlop string R Name of the first flop in receiving clock domain

ClockDomains string R Names of the From and To clock domains in format "From::To"
Location string R Location of the first flop in receive clock domain in source file in
format "FileName:LineNo"
Association string R Type of DATA-CNTL association
Information). For example, crossing paths, data control analysis
status.
FailDepth string R Fully analyzed failures show FailedFull. Otherwise, the value is
the depth at which it failed. Failure at a depth means it failed at
an incomplete depth and the check might pass if you increase the
flop depth. FailedFull means the result will not change even if you
increase flop depth.
Association
Type
None Synchronized Control Signals controlling or blocking the DATA signal were not detected.

Load-Control Synchronized Control signal(s) were detected that appear to block or control the loading
of the DATA signal into receiving domain flops.
Prop-Control Synchronized Control signal(s) were detected that appear to block or control the
propagation of metastable DATA from the first flop in the Receive Clock domain.
By default, Meridian CDC does not report Prop-Control. To enable reporting, set
ri_identify_controlled_propagation to true.
FIFO-Control The crossing of data is controlled by FIFO.
Err-Prop Data crossing controlled by Prop-Control but the operation of the interface may not be
reliable and metastability may still propagate into the design.
Potential- These could potentially be CNTL crossings but misidentified as DATA crossings.
Sync
User User provided association
DESCRIPTION
Meridian CDC considers an asynchronous boundary crossing signal that is not feeding a synchronizer as a DATA
signal.In most designs, a DATA crossing is allowed to become metastable. For safe operation, this metastability at the
boundary needs to be controlled by a synchronized control (CNTL) signal to ensure reliable operation. This is typically
accomplished by designing a multicycle path operation at the DATA crossing. Many design styles are possible to achieve
this.
Meridian CDC automatically associates DATA signal with a CNTL signal. The Association has following categories:
Load-Control
Synchronized Control signal(s) were detected that appear to block or control the loading of the DATA signal into
receiving domain flops.

For example, a signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock domain. This crossing
is controlled by a synchronized control signal, “Sync Control”. The loading of “Tx Data” into the receive domain flop,
“Rx Data”, is controlled by the signal, “Sync Control”. Meridian CDC reports such a DATA-CNTL association as Load
Control.
Suggested Action: Review the identified structural association and make sure it is correct.
Prop-Control
Synchronized Control signal(s) were detected that appear to block or control the propagation of metastable DATA from
the first flop in the Receive Clock domain.
For example, a signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock domain. This crossing
is not controlled by a synchronized control signal. The signal “Tx Data” is loaded into the receive domain flop, “Rx
Data”. Signal “Rx Data”, is allowed to be metastable. “Rx Data” is controlled from propagating into the design by a
synchronized control signal, “Sync Control”. Meridian CDC reports such a DATA-CNTL association as Prop-Control.
Suggested Action: Review the identified structural association and make sure it is correct.
FIFO-Control
The crossing of data is controlled by FIFO.

Err-Prop
Err-Prop: Synchronized signal(s) were detected that appear to block the propagation of metastable data from boundary
flops. However, the operation of the interface may not be reliable and metastability may still propagate into the
design. This typically happens when the DATA crossing is Prop controlled but the flop depth is incorrect.
The flop depths along the two arcs for data “Rx Data” and control “Sync Control” are the same. As a result, data
loaded on the first clock edge will propagate. This can possibly induce metastability in data.
Suggested Action: Review the identified structural association and make appropriate fixes.

Potential-Sync
These could potentially be CNTL crossings but misidentified by Meridian CDC as DATA crossings.
Suggested Action: Review the identified structural association to see what kind of crossings these should be. Based
on the reclassification information, Meridian CDC will report these in the DATA and CNTL categories without Potential-
Sync as association.
User
When users provide a list of modules using command set_user_association -data_rx, Meridian CDC considers data signals
within listed modules as User associated. This is used to overwrite the associations determined by Meridian CDC.
None
Synchronized Control Signals controlling or blocking the DATA signal were not detected.

A signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock domain. This crossing is not
controlled by a synchronized control signal or a FIFO. Meridian CDC reports such a DATA-CNTL association as None.
Suggested Action: Examine the logic controlling this interface. Try to find unidentified or misdetected Control
Signals.
DATA Glitch Analysis

When you issue the verify_cdc_formal command, Meridian CDC performs Boolean and formal analysis to identify the
glitch condition for the DATA crossings. Assuming that the crossing interface works correctly at the RTL (that is, there
is no logical error that could cause bad transitions between the transmitting and receiving clock domains), Meridian
CDC performs formal analysis to identify whether glitches can arise due to netlist implementation and be captured
erroneously in the receiving domain, hence violating setup and hold requirements. Meridian CDC shows a Boolean
condition for such situation when possible. The following are possible statuses resulted from this analysis, which are
annotated under the DataGlitch column for each DATA crossing:
Data-Glitch-Pass
Meridian CDC formally proves that the interface is glitch safe.
Data-Glitch-Fail
Meridian CDC finds a violating condition. The condition can be accesses by clocking on GlitchCondition in iDebug menu
Data-Glitch-Complex
Meridian CDC formal analysis is unable to process the intended glitch verification .
Data-Glitch-Unprocessed
Meridian CDC did not perform the analysis due to design style
DATA crossings with status Data-Glitch-Fail, Data-Glitch-Complex and Data-Glitch-Unprocessed will also be reported in
the W_DATA category. You should examine these crossings to make sure the crossing interface is correct.
RELATED VARIABLES
ri_effort_level_for_data_control_condition
ri_identify_data_control_condition
ri_reclass_max_sync_depth_to_data
ri_report_number_of_drivers_for_w_data
ri_report_glitch_on_all_data
ri_report_w_data
ri_user_module_data
ri_verify_data_stability
ri_verify_one_data_bit_per_bus
RECLASSIFY



click.

Show All for DATA Opens the Active Run Formal dialog displaying the rule instance
viewing

GRAY_CODE_CHECKS
Groups of control signals that require Gray-code checks using formal analysis are reported in this category.
SEVERITY REVIEW
CATEGORY CDC_CHECKS
RULE ATTRIBUTES
The following table describes the header attributes specific to GRAY_CODE_CHECKS. These attributes are
available on rule data and content objects in addition to the attributes mentioned in the rule data attributes
and rule content attributes respectively.

(Read/Write)
Signal string R Name of the signal reconvering
ClockDomains string R From and To clocks in format "FromClock::ToClock"

Location string R Location of the Signal in RTL source code in format
"FileName:LineNo"
ActualReconPoint string R Name of the signal where signals reconverge
FormalStatus string R Fromal verification status
Info string R Name of VCD file in case of formal failure
failed at an incomplete depth and the check might pass if you
increase the flop depth. FailedFull means the result will not
change even if you increase flop depth.
DESCRIPTION
These are groups of control signals that require Gray-code checks using formal analysis. Gray-code checks are
automatically formulated. Gray-code checks are based on reconvergence groups (see W_RECON_GROUPS). By default,
only control signals associated with FIFO type of interfaces are formulated for Gray-code checks and reported in this
category. Set variable ri_verify_gray_codes_on_all_recon to perform checking on all controls that reconverge. The
following table shows various formal statuses reported for this check
Status Interpretation
Passed The Gray-code check has been verified formally. Only a single bit of a multi-bit check may change
during any given clock cycle.
Failed A definite vector sequence has been generated that causes more than one bit to change during a
given clock cycle.

Bounded-N The analysis complexity was too high to generate a definite result, where N is the number of
cycles.
Unprocessed The total run time was insufficient, and formal verification of the check was not attempted.
Suggestion: re-run using a larger value for the -time_limit option.
Skipped-XYZ The check is not run because of XYZ reason.
EXAMPLES
RELATED VARIABLES
ri_verify_gray_codes_on_all_recon
ri_verify_gray_codes



click.
By Match for Signal Flags all rule instance data where the value in Signal matches the
value(s) in Signal for the selected rows; formal CDC analysis will
be run based on all Signal matches for all selected rows
Show All for GRAY_CODE_CHECKS Opens the Active Run Formal dialog displaying the rule instance
viewing

I_ASSUME
I_ASSUME reports SVA or PSL assumptions present in the design.
SEVERITY INFO
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to I_ASSUME. These attributes are available on
rule data and content objects in addition to the attributes mentioned in the rule data attributes and rule

(Read/Write)
Name string R Name of the assumption
Location string R Location of the assumption in source code in format

"FileName:LineNo"
AssumptionType string R Assumption type SVA or PSL
DESCRIPTION
These are SVA or PSL assumptions in the design (in the original RTL). These assumptions are respected while performing
formal analysis.
RELATED VARIABLES
ri_report_i_assume

INTERFACE
This category lists the set of cntl-data interfaces with valid structural association
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT reported
BEHAVIOR
RULE ATTRIBUTES
The following table describes the header attributes specific to INTERFACE. These attributes are available on

Name (Read/Write)
CrossingType string R Crossing type: DATA or CNTL or FEDBACK
Signal string R Name of the signal

Location string R Location of signal in RTL source in format FileName:LineNo
ClockDomains string R From and To clock domains FromClock::ToClock
Info string R More debug information related to the interface
Information locator string used to access and display available
Information).
DESCRIPTION
Meridian CDC considers automatically associates DATA and CNTL signals and reports these in INTERFACE categories.
There are typically following crossings in an interface
• CNTL - These are asynchronous boundary signals which end in a synchronizer.

• DATA- These are asynchronous boundary signals which are associated with CNTL. The DATA belonging to an interface
can be associated by various means for example LOAD-CNTL, FIFO-CNTL etc.
• FEEDBACK - These are asynchronous boundary signals which go from receive clock domain to transmit clock domain.
The feedback signal needs to be in fanout of CNTL to be associated.

A valid structural association is reported in INTERFACE.
EXAMPLE
Following example shows an interface with valid structural association.

RELATED VARIABLES
ri_report_interface

PULSE_SYNC
This category reports flops that are configured as pulse synchronizers. It is not reported by default. You can turn on
this category by setting the following variable at the top of the control script:
set ri_report_pulse_sync true
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT Not reported
BEHAVIOR
RULE ATTRIBUTES
The following table describes the header attributes specific to PULSE_SYNC. These attributes are available

Name (Read/Write)
Signal string R Name of the recieve signal
Location string R Location of crossing in source code in format "FileName:LineNo"

ClockDomains string R From and To Clock Domains in formal "From::To"
EXAMPLES
For example, in the following figure, ‘ipulse’, generated from clka domain, is synchronized in the clkb domain as
‘opulse’.
RELATED VARIABLES
ri_strict_synchronizer_detection


RST_SYNC
RST_SYNC reports the reset that are synchronized.
SEVERITY REVIEW
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to RST_SYNC. These attributes are available on

Name (Read/Write)
ResetSignal string R Name of the reset signal
ReceivingFlop string R Name of the receiving flop

Location string R Location in source code where reset synchronization is taking
place in format "FileName:LineNo"
SyncFlop string R Name of the sync flop
SyncDepth integer R Reset synchronizer depth
Info string R 1. Information locator string used to access and display
available debug information in iDebug (see Understanding Debug
Information).
2. One of the following keywords:
a. SyncAssertSyncDeassert - Reset signal is synchronously
asserted and deasserted
b. AsyncAssertSyncDeassert - Reset signal is
asynchronously asserted and synchronously deasserted
DESCRIPTION
These are reset signals originating in one domain, which then cross over to another domain, are synchronized in the
receiving domain, and then serve as reset signals to flops in the receiving domain. The synchronizer needs to be
strict in the sense that there should be no logic being driven by the receive domains either before or between the

synchronizer flops. The reset signal can either “asynchronously assert but synchronously deassert” or “synchronously
assert and synchronously deassert” the synchronizer flops.
EXAMPLES
For example, in the following figure, "reset", generated off clka domain, is synchronized in the clkb domain;
"reset_clkb" is then used to asynchronously assert a reset on FF1, FF2, FF3, but synchronously deassert the reset on
those flops. Meridian CDC will report "reset" as RST_SYNC.
RELATED VARIABLES
ri_report_rst_sync

SYNC_CROSSING
In this category a signal crossing between two synchronous clock domains is reported. The two clock domains
are derived from a common master clock. This category is not reported by default. To enable reporting, set
ri_report_sync_crossing to true.
SEVERITY REVIEW
CATEGORY CDC_CHECKS

BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to SYNC_CROSSING. These attributes are available

Name (Read/Write)
Signal string R Name of the recieve signal
Location string R Location of crossing in source code in format "FileName:LineNo"

EXAMPLES
In this example, clk1 and clk2 are both derived from Master clk. There is a known timing relationship between the two
domains. Therefore, the signal crossing between the two domains is a synchronous crossing.

RELATED VARIABLES
ri_report_sync_crossing


click.
By Match for Signal Flags all rule instance data where the value in Signal matches the
value(s) in Signal for the selected rows; formal CDC analysis will
be run based on all Signal matches for all selected rows
Show All for SYNC_CROSSING Opens the Active Run Formal dialog displaying the rule instance
viewing

U_INTERFACE
This category lists the set of cntl-data interfaces that are deemed safe by the user. User can specify user Control-Data
association of Clock Domain Crossings using create_association command.
SEVERITY INFO
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOR
RULE ATTRIBUTES
The following table describes the header attributes specific to U_INTERFACE These attributes are available

Name (Read/Write)
CrossingType string R Crossing type DATA or CNTL or FEDBACK

Information).
RELATED VARIABLES
ri_report_u_interface

W_ASYNC_RST_FLOPS
This category reports flops in the design that received an asynchronous reset generated from an asynchronous clock
domain.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_ASYNC_RST_FLOPS. These attributes are

Name (Read/Write)
ReceivingFlop string R Flop that is receiving the asynchronous reset
Location string R Location of the receivingflop in source file in format

"FileName:LineNo"
ClockDomains string R Launch and Capture clocks in format FromClock::ToClock
DrivingSignal string R Reset driver signal
Information).
DESCRIPTION
An asynchronous reset going to flops clocked by asynchronous clocks could cause undesired behavior during
reset removal. It is, therefore, better to have a reset synchronizer for each receiving clock domain in the
design. Examine reset signals for the reported flops.
Suggested Action: Insert a Reset Synchronizer in the receive clock domain, if needed. Else, sign off the
section after review.
EXAMPLES
For example, in Figure, clka and clkb are asynchronous to each other. Reset, generated from clka domain, is
used in the clkb domain, to asynchronously reset FF1, FF2 and FF3. Meridian CDC will flag FF1, FF2, FF3 as
W_ASYNC_RST_FLOPS.

RELATED VARIABLES
ri_report_w_async_rst_flops

W_BLOCKED_CROSSING
This category lists the set of crossings that are blocked due to constants.
SEVERITY INFO
CATEGORY CDC_CHECKS

BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_BLOCKED_CROSSING. These attributes are

Name (Read/Write)
InternalReset string R This is the name of the internally generated reset.
SampleFlop string R This is the name of a flop being asynchronously reset by

InternalReset. There can be many of these flops, but only one is
reported.
Location string R This is the file name and line number of the SampleFlop
DESCRIPTION
Clock crossings blocked because of constants are reported in this category. The constants could be those
present in the RTL design or coming from the specified environment constraints. For each crossing, the
transmit driver and the receiving flop are reported along with their clock-domains. Meridian CDC reports the
TxFlop and RxFlop Signal, the Location and the how the crossing is blocked (RTL constant or ENV specs) in this
category. The resulting analysis status could be:
•Drive-constant-zero - Transmitter is always logic-0 (i.e. has no logic transitions)

•Driver-constant-one -Transmitter is always logic-1 (i.e. has no logic transitions)
•ReceiveFlop-constant-zero - Reciever is always logic-0 (therefore excluded from regular crossing analysis)
•ReceiveFlop-constant-one - Reciever is always logic-1 (therefore excluded from regular crossing analysis)
•On-path-constant: Crossing path is blocked by constants along the path
•ReceiveFlop-also-has-normal-crossing - A path from transmitter is blocked but there are other active
transmitters to this reciever
Suggested Action: Analyze the crossing, fix if the crossing is not supposed to be blocked else signoff.
Note:
1. If there is a trivial constant in the RTL which blocks the crossing path. synthesis tool will optimize that path
away (since it is redundant). So, it is not reported as W_BLOCKED_CROSSING.
2. If there is a non-trivial constant in the RTL which blocks the crossing path, the synthesis tool may or may not
optimize the path. If it is optimized away, no crossing is reported as in case 1. If it is not optimized, W_DATA
with Association None is reported.

3. There is no RTL constant on the path, but an environment constraint (set_constant) is set on a signal which
blocks the crossing path. Since the crossing is not active during CDC analysis after the environment is applied,
it will not be reported as DATA or CNTL, but instead reported as W_BLOCKED_CROSSING.
RELATED VARIABLES
ri_report_all_w_blocked_crossing
ri_report_w_blocked_crossing

W_CLK_RECON
This category lists clock lines that fan out and later reconverge. This may affect clock duty cycle factors or causes
glitches.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_CLK_RECON. These attributes are available
content attributes, respectively.

Name (Read/Write)
Clock string R Name of the clock
ClockDomain string R Clock domain of reconvergent clock signal

ReconSignal string R Reconvergent point for clock signal
Location string R Location of the reconvergent signal in source file in format
"FileName:LineNo"
Info string R Information locator string used to access and display available debug
information in iDebug (see Understanding Debug Information). For
example, fanin cone for reconvergent clock signal.
DESCRIPTION
Suggested Action: Examine the clock network and modify logic or sign-off.
EXAMPLES
Figure shows an example of clk1 reconverging to become clk2. Meridian CDC will report W_CLK_RECON for
clk2.

RELATED VARIABLES
ri_report_w_clk_recon

W_CNTL
This category lists out all synhcronized domain crossing CNTL signal which have problems. The problems can be related
feedback logic related to this control or with synchronizer depth etc.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_CNTL. These attributes are available on rule
attributes, respectively.

(Read/Write)

ClockDomains string R Names of the From and To clock domains in format
"From::To"
Location string R Location of the first flop in receive clock domain in source
file in format "FileName:LineNo"
SyncFlop string R Name of the final flop in the synchronizer
SyncDepth integer R Number of flop stages detected in synchronizer
Debug Information). For example, crossing paths information.
By default, Meridian CDC reports the information locator
string for only ONE driver in the group. You can set the
ri_report_dbg_file_for_each_driver variable to have access to
debug information for ALL drivers.
ClkInteractionType string R Keyword describing the clock interaction; one of FastToSlow,
SlowToFast, or SameFreq
failed at an incomplete depth and the check might pass if
you increase the flop depth. FailedFull means the result will
not change even if you increase flop depth.

Association
Type
DATA CNTL Signal has the potential to block the loading of metastable data into flops.
Is-Feedback These are signals from the receiving domain which are synchronized back into the
sending domain, as part of a data-transfer protocol.
Has-Feedback A Feedback is associated with the CNTL crossing. Path information is available in
the .dbg file.
Has-Err- A potential erroneous feedback is associated with the CNTL crossing. Path information
Feedback is available in the .dbg file. This association is not reported by default. To enable
reporting of this category, set variable ri_report_err_feedback to true.
Blocked The CNTL association is blocked. The association can be blocked because
• The association is blocked by constant
• CNTL has no load i.e. no fanout. Note: Output port is considered a load.
• CNTL drives a black box
User Users have instructed Meridian CDC to report these control crossings within the listed
modules as User status using the Tcl variable ri_user_associated_cntl.
None Unsynchronized crossings are not detected to be controlled by these signals. Typically,
synchronized signals are expected to be controlling data crossings. The use of the
synchronizer may not be necessary or these signals may need to be reclassified as
data crossings. Check whether "set_cntl_association_depth" is lesser than needed for
association. Reclassify the signal as data if its not a CNTL signal.
DESCRIPTION
Synchronized domain crossing CNTL signals which have some issues are reported here.
The following violations are reported as W_CNTL category:

• Flop/output fanout count of CNTL SyncOut is zero. The Association column shall contain a “Blocked” clause.
• The CNTL does not have any DATA associated with it. The Association column shall contain a “None” clause.
This report is controllable by ri_report_none_as_w_cntl Tcl variable
• The CNTL has a user-specified synchronizer, but its depth is not within limits set by set_synchronizer_depth
-min and set_synchronizer_depth -max Tcl variables. The Info column shall contain a “User-Specified-Sync-
Depth-Err” clause.
• The CNTL feeds into multiple DATAs with different D1 depths. The Info column shall contain an “Err-Depth-
Mismatch” clause. The DBG file shall contain one CNTL SyncOut to DATA Rx path per each depth. This report is
controllable by ri_check_cntl_depth_mismatch Tcl variable
• If CNTL feeds into multiple DATAs with different association types (Load vs FIFO vs Clock). The Info column
shall contain an “Err-Assoc-Type-Mismatch” clause. The DBG file shall contain one CNTL SyncOut to DATA Rx
path per each association type. This report is controllable by ri_check_cntl_type_mismatch Tcl variable.
• CNTL is associated to some DATA, but has no feedback. The Info column shall contain a “MissingFeedback”
clause. This report is controllable by ri_check_missing_feedback Tclvariable.
Suggested Action: Refer to CNTL section to determine the action based upon association type.
EXAMPLES
For example, in Figure, a signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock domain.
This crossing is controlled by a synchronized control signal, “Sync Control”. The loading of “Tx Data” into the receive

domain flop, “Rx Data”, is blocked by the signal, “Sync Control”, due to the constant disabling the output of the AND
gate. Meridian CDC reports this as a W_CNTL.
RELATED VARIABLES
ri_report_w_cntl
RECLASSIFY



click.
Show All for W_CNTL Opens the Active Run Formal dialog displaying the rule instance
viewing

W_D_CLK_GLITCH
Meridian CDC reports derived clock signals that act as clock inputs to flops. A derived clock is defined as a signal
produced by combinationally combining outputs of multiple flops (for this purpose, a primary input is treated identical
to a flop output). Such signals have the potential for a glitch and hence should be reported. This category is not run by
default. To enable this check: set variable ri_report_w_d_clk_glitch true.
SEVERITY WARNING
CATEGORY CDC_CHECKS
DEFAULT not reported
BEHAVIOR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_D_CLK_GLITCH. These attributes are

(Read/Write)
DerivedClockInput string R Input signal driving derived clock
InputClockDomain string R Clock domain of Input signal

DerivedClock string R Derived clock signal name
SampleFlop string R sample flop in fanout of derived clock
Location string R Location of derived clock in format FileName:LineNo
SampleFlopLocation string R Location of sample flop in formal FileName:LineNo
DESCRIPTION
Suggested Action: Ensure reliable clocking in order to sign off.
EXAMPLES
For example, the combinational output is driving the clock input in Figure 6.9. Meridian CDC will report
W_D_CLK_GLITCH on clk2.

RELATED VARIABLES
ri_report_w_d_clk_glitch

W_DATA
This category lists out DATA crossing signals which have problems and can cause unreliable operation in design.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_DATA. These attributes are available on rule

Name (Read/Write)

Location string R Location of the first flop in receive clock domain in source file in
format "FileName:LineNo"
Information). For example, crossing paths, data control analysis
status.
By default, Meridian CDC reports the information locator
string for only ONE driver in the group. You can set the
ri_report_dbg_file_for_each_driver variable to have access to debug
information for ALL drivers.
Association

Type
None Synchronized Control Signals controlling or blocking the DATA signal were not detected.
Load-Control Synchronized Control signal(s) were detected that appear to block or control the loading
of the DATA signal into receiving domain flops.
Prop-Control Synchronized Control signal(s) were detected that appear to block or control the
propagation of metastable DATA from the first flop in the Receive Clock domain.
By default, Meridian CDC does not report Prop-Control. To enable reporting, set
ri_identify_controlled_propagation to true.
FIFO-Control The crossing of data is controlled by FIFO.
Err-Prop Data crossing controlled by Prop-Control but the operation of the interface may not be
reliable and metastability may still propagate into the design.
Potential- These could potentially be CNTL crossings but misidentified as DATA crossings.
Sync
User User provided association
DESCRIPTION
Asynchronous boundary signals not feeding a synchronizer are classified as DATA. The metastability at this
boundary needs to be controlled by synchronized signals to ensure reliable operation. When the crossing is not
associated with a CNTL it is categoried as None and reported in this category.
The following violations are reported as W_DATA category:
1. If DATA Rx is a flop and there is no path to it from any CNTL SyncOut within the depth D1 set by
set_max_search_depth Tcl command. The Association column shall contain a “None” clause.
2. If DATA Rx is a memory pin and there is no path to it from any CNTL SyncOut within the depth
D1 which is an incremented by 1 value specified by set_max_search_depth Tcl command
The Association column shall contain a “None” clause.
3. DATA crossings that have statuses of Data-Control-NonBlock, Data- Control-ByPass, Data-Control-Complex
and Data-Control-Unprocessed in data control condition.
Suggested Action: Check if there exists an association with CNTL. If yes use set_max_search_depth -
association command to set the right depth.
Even for associated crossings there can be following problems related to Err-Prop,Potential-Sync in association
causing signals to be reported in this category. When data control analysis is turned on, Data-Control-
NonBlock, Data-Control-ByPass, Data-Control-Complex, Data-Control-Unprocessed statuses can cause crossing
to be reported in this category. During glitch analysis Data- Glitch-Fail, Data-Glitch-Complex, Data-Glitch-
Unprocessed statues can cause crossing to be reported in this category.
Suggested Action: Refer to DATA section to determine the action based upon association type.
EXAMPLES
For example, in Figure, a signal from the Transmit domain, “Tx Data”, crosses over into the Receive clock
domain. This crossing is not controlled by a synchronized control signal or a FIFO. This DATA signal has no
association as described in the None section above. Meridian CDC reports this DATA signal in the W_DATA
category.

RELATED VARIABLES
ri_report_w_data
ri_user_module_data
RECLASSIFY



click.
Show All for W_DATA Opens the Active Run Formal dialog displaying the rule instance
viewing

W_ENCAP
W_ENCAP rule reports potential CDC problems at the boundary of the design where asynchronous crossings start from
or ending at primary input port, primary output port, blackbox input pin, or blackbox output pin.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_ENCAP rule. These attributes are available
on rule objects as well as rule instance objects in addition to the attributes mentioned in the rule attributes
and rule instance attributes respectively.

Name (Read/Write)
Signal collection R Name of the signal with insufficient environmental information
Location string R Location in the source code file that contains the signal
PortType string R Port type of the W_ENCAP:
• Input
• BboxOut
• Output
• BboxIn
• InOut
• NoLoadNet
Info list R Context of the W_ENCAP; one or more of the following:
• CNTL
• DATA
• W_ASYNC_RST_FLOPS
• RST_SYNC
• W_G_CLK_GLITCH(Async-Input)
• OutputSpec
• MASYNC
• Unregistered
• Incomplete-Recon

DESCRIPTION
W_ENCAP is analyzed during the CDC structural analysis step, it informs the user about asynchronous
crossings that cannot be completely verified due to lack of visibility within the current design scope such as
asynchronous crossings that are starting from or ending at primary input port, primary output port, blackbox
input pin, or blackbox output pin. There are different type of encapsulation issues reported by W_ENCAP, it is
important to understand the different flavors, they are categorized using portType and Info attributes to help
users take appropriate actions.
Following is the complete list of different flavors of W_ENCAP issues reported.
PortType Info Description

Input Tx Driver Indicates that there is a create_input spec on it and act as a Tx driver
*1 for a one of the rules
Rule
Output OutputSpec Indicates that there is a create_output spec on this primary output and
is driven by at least one asynchronous Tx driver in its fan-in cone
Unregistered Indicates that there is a create_output spec on this node and is not
directly driven by a sequential cell
MASYNC Indicates that there is a create_output spec on this primary output node
and is driven by more than one asynchronous waveforms
Incomplete- Indicates that there is a create_output spec with respect to
Recon Rx domain or no spec on the output side of this node and
reconvergence analysis reached this node (output port) before reaching
set_max_search_depth -recon
NoOutputSpec Indicates that there is no create_output spec on this node
BboxIn OutputSpec Indicates that there is a create_output spec on this blackbox input pin
and is driven by at least one asynchronous Tx driver in its fan-in cone
MASYNC Indicates that there is a create_output spec on this blackbox node and is
driven by more than one asynchronous waveforms
BboxOut Tx Driver Indicates that there is a create_input spec on it and act as a Tx driver
*1 for a one of the rules
Rule
InOut OutputSpec Indicates that there is a create_output spec on the output side of the
node and is driven by at least one asynchronous Tx driver in its fan-in
cone
Tx Driver Indicates that there is a create_input spec on the input side of the node
*1 and act as a Tx driver for a one of the rules
Rule
Incomplete- Indicates that there is a create_output spec with respect to
Recon Rx domain or no spec on the output side of this node and
reconvergence analysis reached this node (output port) before reaching
set_max_search_depth -recon
NoOutputSpec Indicates that there is no create_output spec on the output side of the
this node
NOTES:
*1 : Tx Driver Rule can be from one of CNTL, DATA, W_ASYNC_RST_FLOPS, RST_SYNC, W_G_CLK_GLITCH(Async-
Input), W_MASYNC rules
Suggested Action: Provide an additional environmental information to encapsulate the crossing.

EXAMPLES
For example, in following figure, a synchronized CNTL signal is feeding output port out1. The output port out1
is specified to belong to clk2 domain. out1 can potentially reconverge with another CNTL signal at top level
hierarchy and lead to W_RECON_GROUPS. But at this level there is not sufficient information regarding the
capture, So Meridian CDC reports W_ENCAP, "Incomplete-Recon" in this case.
RELATED VARIABLES
ri_report_w_encap
ri_report_dbg_files
ri_report_all_unregistered_outputs_in_w_encap

W_FANOUT
This category reports signals crossing between clock domains that fan out to multiple synchronizers in the same
receiving clock domain. This presents a possible loss of correlation between branches if each is intended to have the
same value simultaneously
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_FANOUT. These attributes are available on

(Read/Write)
Fanout string R Receiving flops
Driver string R Name of the signal that is being fanned out to multiple
synchronizers
Location string R Location of the first flop in receive clock domain in source
file in format "FileName:LineNo"
FanoutDepth string R Depth of the multiple fanout point from transmit flop
ReconvergencePoint string R Points where multiple fanouts are reconverging. This is a flop
or output port.
ActualReconPoint string R Actual combinational reconvergence point. This is the
combinational signal where reconvergence occcurs.
This typically drives D pin of the flop specified in
ReconvergencePoint.
DESCRIPTION
Suggested Action: Fix design. Else, use manual sign-off to ensure that the design does not contain
correlation related issues.
EXAMPLES

For example, in Figure, Meridian CDC will report a W_FANOUT, if such a structure exists in the design.
RELATED VARIABLES
ri_ignore_w_fanout_with_no_recon
ri_report_w_fanout
ri_trace_w_fanout_paths

W_G_CLK_GLITCH
This category reports gated clock signals with the potential for glitches.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_G_CLK_GLITCH. These attributes are

(Read/Write)
GatedClockInput string R One of the input of the clock gate
InputClockDomain string R Clock domain of input signal

GatedClock string R Outut of the clock gate
OutputClockDomain string R Clock domain of gated clock

GlitchType string R Type of glitch issue on this gate
Location string R Location of the gated clock input in RTL source in format
"FileName:LineNo"
SampleDestination string R Sample destination from the gated clock
Information). For example, fanin-cone for clock gate, formal
gltich analysis status.
DESCRIPTION
Meridian CDC lists gated clock signals with the potential for glitches. The glitch type reported, the last field in
the report, can pin-point the type of failure.
Following are the various glitch-type categories that are reported
ASYNC_INPUT

The gating signal is from an asynchronous clock domain. Following figure shows an example of this.
In this the enable for clock gating cell is coming from clock domain clk1 which is asynchronous to clk2.
MISSING_SPEC
The gating signal has no waveform association. It can happen either when the enable is being driven from an input port
and there is no create_input defined on the input port or the enable is being driven from output of a blackbox and
there is no create_input defined on blackbox output port. Following figure shows the case when create_input is missing
on input port
Following figure shows the case when create_input is missing on blackbox output

GATE_CONFIG
Meridian CDC supports commonly used latch and flop based integreted clock gating cells. Following figure
shows a couple of commonly used integrated clock gating cells.
By default tool allows both flop and latch driven clock gating cells. If only latch driven clock gating cells are desired
user can set the variable ri_allow_flop_driven_clk_gate to false. If the clock gating logic does not match the standard
latched or flop configuration tool reports W_G_CLK_GLITCH with GATE_CONFIG category. Following figure shows one
example where such violation will be issued

ASYNC_RESET_SELECT
The gating signal is a signal with reset spec associated and from an asynchronous clock domain. Following sigure shows
an example, here gating signal is derived from reset and reset is being driven from an asynchronous clock domain.
SYNC_RESET_SELECT

The gating signal is a signal with reset spec associated and is from a synchronous clock domain. Following sigure shows
an example, here gating signal is derived from reset and reset is being driven from a synchronous clock domain.
To disable reporting of subcategories within this category, users can set variables
ri_report_w_g_clk_glitch_<subcategory> to false. For example, setting the variable
ri_report_w_g_clk_glitch_missing_spec to false will disable reporting of this particular subcategory.
EXAMPLES
Figure shows an example for GATE_CONFIG. This category is reported by default.

RELATED VARIABLES
ri_report_clk_glitch_dbg_files
ri_report_w_g_clk_glitch
ri_report_w_g_clk_glitch_async_input
ri_report_w_g_clk_glitch_async_reset_select
ri_report_w_g_clk_glitch_bad_polarity
ri_report_w_g_clk_glitch_gate_config
ri_report_w_g_clk_glitch_missing_spec
ri_report_w_g_clk_glitch_sync_reset_select

W_GLITCH
This category is reported when combinational logic in one clock domain directly driving the first stage of a synchronizer
in the receiving clock domain.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_GLITCH. These attributes are available on

Name (Read/Write)
GlitchInput string R Input signal driving the combinational logic
GlitchOutput string R Named of the flop in fanout of combinational logic

Location string R Location of the fanout flop in RTL source in format
"FileName:LineNo"
ClockDomains string R From and To clock domains in format "FromClock::ToClock"
Information). For example, fanin-cone for combinational logic.
DESCRIPTION
Meridian CDC detects combinational logic in one clock domain directly driving the first stage of a synchronizer
in the receiving clock domain. Such logic presents the possibility of a logic hazard being captured
asynchronously by the receiving clock domain. All synchronizers fed by combinatorial logic driven by
asynchronous signals from 1 or more other domains are listed as synchronizers with glitch potential. W_GLITCH
also captures the situation with a single driver, but with multiple paths to a crossing flop, having both odd and
even parity of inverters in paths and therefore leading to a non-unate realization.

Meridian CDC will not report W_GLITCH by default if one signal crosses asynchronous clock domain and is
combined with another signal in that clock domain.
For example, in Figure, a signal from CLK1 domain and a signal from the CLK2 domain both feed into the combinatorial
logic. CLK1 and CLK2 are asynchronous to each other. Meridian CDC will not report this as W_GLITCH by default
However, there is a variable that enables Meridian CDC to perform more strict glitch checking to report any
crossings where there is combinational logic between the transmitting flops and the receiving flops. The variable is
ri_warn_all_multi_driver_crossings. When set to true, additional glitchy situations for control crossings, are reported in
the W_GLITCH category.
By default, all primary inputs are assumed to have glitch potential. Users can disable this behavior by setting the
variable ri_assume_primary_inputs_have_glitch_potential to false, or selectively disable this behavior for a subset of
primary inputs using the set_glitch_free_inputs command.
Suggested Action: Fix design or ensure that glitch is impossible, and then sign off.

Formal Verification
Structural analysis identifies control signals that reconverge before crossing clock domains. Formal analysis attempts
to find logic values that cause the generation, propagation, and capture of glitches by receiving flops. By default,
only synchronizers (CNTL signals) will be checked. Use ri_report_warn_for_all_glitches to extend glitch checking to all
crossing flops. Here are various statuses reported in formal verification
Status Interpretation
Passed The glitch constraint has been verified formally. The vacuity on this check also passed.
Passed-Vacuous The glitch constraint has been verified formally. The vacuity on this check failed i.e. there are
no transitions in any of the transmit flops.
Passed- The glitch constraint has been verified formally. The vacuity on this check did not generate a
BoundedVacuity definitive result. The check may or may not be vacuous.
Passed- The glitch constraint has been verified formally. The total run time was insufficient to run
UnprocessedVacuity vacuity on this check. The check may or may not be vacuous.
Failed A definite vector sequence has been generated that produces a glitch. A transition by one or
more glitch drivers proceeding through combinational logic created a spurious control signal.
Bounded-N The analysis complexity was too high to generate a definite result, where N is the number of
cycles.
Unprocessed The total run time was insufficient, and formal verification of the check was not attempted.
Suggestion: re-run using a larger value for the -time_limit option
Skipped-Bit The check is not run because it is a part of a control bus and the variable
"ri_verify_one_cntl_bit_per_bus" is set to true.
Skipped-XYZ The check is not run because of XYZ reason
RELATED VARIABLES
ri_exclude_cntl_masync_from_w_glitch
ri_report_w_glitch


click.
By Match for GlitchOutput Flags all rule instance data where the value in GlitchOutput
matches the value(s) in GlitchOutput for the selected rows;
formal CDC analysis will be run based on all GlitchOutput

Show All for W_GLITCH Opens the Active Run Formal dialog displaying the rule instance
viewing

W_HALF
This category detects a half-cycle synchronizer stage in the synchronizer logic.
SEVERITY WARNING
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_HALF. These attributes are available on rule

Name (Read/Write)
Location string R Location of the flop using opposite edge of the clock in RTL source
in format "FileName:LineNo"
Signal string R Flop in the synchronizer using opposite edge of the clock
DESCRIPTION
Meridian CDC has detected a half-cycle synchronizer stage in the synchronizer logic. This half cycle is usually
a flop that is clocked by the opposite edge logic of other flops in the synchronizer. Such logic may result in
transitions that may be too fast for the signals entering the flop to meet timing.
Suggested Action: Ensure that enough time is available for metastability to resolve within the
synchronizer.
EXAMPLES
For example, in Figure, Meridian CDC will report a W_HALF on such a structure.

RELATED VARIABLES
ri_report_w_half

W_INTERFACE
This category lists the set of cntl-data interfaces with potential issues.
SEVERITY WARNING
CATEGORY CDC_CHECKS
DEFAULT reported
BEHAVIOR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_INTERFACE These attributes are available

Name (Read/Write)
CrossingType string R Crossing type: DATA or CNTL or FEDBACK
ErrorType string R Error type for this interface, missing-feedback logic in the case
shown above
Information).
DESCRIPTION
Meridian CDC considers automatically associates DATA and CNTL signals and reports these in INTERFACE
categories. Following example shows an interface with valid structural association.
There are typically following crossings in an interface
• CNTL - These are asynchronous boundary signals which end in a synchronizer.

• DATA- These are asynchronous boundary signals which are associated with CNTL. The DATA belonging to an interface
can be associated by various means for example LOAD-CNTL, FIFO-CNTL etc.
• FEEDBACK - These are asynchronous boundary signals which go from receive clock domain to transmit clock domain.
The feedback signal needs to be in fanout of CNTL to be associated.

An interface is reported in W_INTERFACE category if there are potential issues in CNTL,DATA or FEEDBACK crossings
that are part of interface.
Following are various situations in which an interface will be reported as W_INTERFACE
Err-Feedback:
This is reported only when ri_report_error_feedback tcl variable is set to true. Here is the criteria for reporting error
feedback
For load-cntl situtation CNTL to Feedback depth (D2) should be more than CNTL to DATA (D1) depth for Err-Feedback
to be not reprted. So if D2 > D1 Err-Feedback is not reported else it is reported. This is because, if the RX domain is
much slower compared to the TX, the TX domain will recieve "early" feedback and begins to work and starts sending
new data, while the RX domain still hasn't received the last data.
• For fifo-cntl situation Err-Feednack is reported when CNTL to Feedback depth (D2) is less than the CNTL to DATA
depth (D1). Note that for Fifo-cntl situations, the feedback can be equal to the data depth because there is a
comparison between read and write that avoids any overwrite situations.
Suggested Action: Fix the feedback logic to ensure reliable CDC crossing.
Missing-Feedback-To-Tx: This is reported in following two cases

• Path from Feedback’s SyncOut to CNTL Tx (D3) is not found or exceeds the value set by Tcl command
‘set_max_search_depth –feedback –cntl_tx’ . The ErrorType column in the corresponding TX-CNTL line shall contain
"Missing-Feedback-To-Tx" clause.
• Path from Feedback’s SyncOut to DATA Tx (D4) is not found or exceeds the value set by Tcl command
'set_max_search_depth –feedback –data_tx’. The ErrorType column in the corresponding TX-DATA line shall contain
"Missing-Feedback-To-Tx" clause.

Suggested Action: create the association, logic control from the Feedback to CNTL/Data Tx side as appropriate.
If the control over the data is done in a more complex way, and assumed to be correct, and if a review confirmed that
the interface is safe, create a user interface using create_association.
EXAMPLE
For example, following is an interface classified in W_INTERFACE category because of error in feedback
RELATED VARIABLES
ri_report_w_interface

W_LOCKUP
A signal crossing a synchronous domain where clock distribution networks are not sufficiently balanced requires
lockup analysis. This means the transmitting and receiving clock domains should not be actively edge-aligned at these
interfaces. Meridian CDC checks for edge-alignment of the synchronous clocks.
Transmit and receive clocks for this check belong to same clock domain (synchronous to each other). One possible
scenario where this check can be used is scan chains, where transmit and receive clocks that are not sufficiently
balanced and a lockup latch is used to avoid timing problems.
Designs that use a lockup latch methodology should enable this rule.
SEVERITY WARNING
CATEGORY CDC_CHECKS
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_LOCKUP. These attributes are available on

Name (Read/Write)
Signal string R Name of the capture signal
Driver string R Name of driver signal

Location string R Location of the capture signal of the clock in RTL source in format
"FileName:LineNo"
Information).
DESCRIPTION

Suggested Action: Control the clock domain for lockup latch analysis. Run hold time (fast path) analysis,
insert lockup latch, or sign-off.
EXAMPLES
Please see figure, for such a structure W_LOCKUP will be reported.
RELATED VARIABLES
ri_report_w_lockup

W_MASYNC
This category is reported when multicple asynchronous signals combine and feed a synchronizer.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_MASYNC. These attributes are available

Name (Read/Write)
Driver string R Input signal driving the combinational logic
ReceivingFlop string R Name of the flop in fanout of combinational logic

Location string R Location of the fanout flop in RTL source in format
"FileName:LineNo"
Information). For example, fanin-cone for combinational logic. Also,
signal type: CNTL or Data.
DESCRIPTION
Meridian CDC reports multiple asynchronous signal combinations in the following situations:
a. when signals from two or more clock domains are combined and synchronized into a new clock domain, (for
example, a signal from CLK1 and a signal from CLK2 are combined and synchronized into CLK3).
b. when signals from two or more clock domains are combined to form an output of the module. Users can however, set
variable ri_detect_masync_on_outputs to false to disable Meridian CDC from checking W_MASYNC on outputs.
Suggested Action: Fix design or ensure that glitch is impossible, and then sign-off.
EXAMPLES
For example, in Figure, ‘sig a’ is a combinational output from signals coming from two different asynchronous clock
domains clk1 and clk2. Meridian CDC will report this as W_MASYNC.

RELATED VARIABLES
ri_report_w_masync
ri_detect_masync_on_outputs
ri_report_masync_dbg_files

W_RECON_GROUPS
This category reports groups of CNTL signals that are reconverging in the receiving domain.
SEVERITY ERROR
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_RECON_GROUPS. These attributes are

(Read/Write)
ControlSignal string R Control signals in transmit domain that reconverge after

synchronization
ReconSignal string R Flop name capturing ReconSignal in receive domain. This is
flop or output port.
Location string R Location of the capture flop in RTL source in format

"FileName:LineNo"
ActualReconPoint string R Actual combinational reconvergence point. This is the
combinational signal where reconvergence occcurs. This
typically drives D pin of the flop specified in ReconSignal.
ReconLocation string R Location of ReconSignal in RTL source in format
"FileName:LineNo"
Depth interger R Point at which reconvergence happens after the synchronizer
outputs (measured in flop-depth)
Information). For example, reconvergent paths.
DESCRIPTION
Groups of CNTL signals that are reconverging in the receiving domain are listed out. Since correlation can be
lost when simultaneously changing signals cross asynchronous clock domains, it is important to ensure that
reconverging control signals are Gray coded. Note that ReconSignal is always going to be a Flop or a Primary
Output, where as the ActualReconPoint is typically an internal combinatorial signal. The ReconSignal and
ActualReconPoint can both be the same signal in some cases.
Recon points are labeled as follows in the Info section:

Info Label Meaning Suggested Action
FifoInterfaceRecon Recon point part of a Informational, Review the reconverging signals.

fifo interface Make sure they are Gray Coded using Meridian
CDC formal analysis
InterfaceRecon Recon point part of a Informational, Review the reconverging signals.
load/prop interface Make sure they are Gray Coded using Meridian
CDC formal analysis
FifoInterfaceReconWithLocalFanout Recon point fans Informational, Review the reconverging signals.
outside of interface Make sure they are Gray Coded using Meridian
logic, but still doesn't CDC formal analysis
interact with outside
logic. Typical case for
primary outputs.
InterfaceReconWithLocalFanout Recon point fans Informational, Review the reconverging signals.
outside of interface Make sure they are Gray Coded using Meridian
logic, but still doesn't CDC formal analysis
interact with outside
logic. Typical case for
primary outputs.
MultipleInterfaceRecon Recon point Warning, ensure this is intended in design.
participates in more Review the reconverging signals. Make sure
than one interface they are Gray Coded using Meridian CDC formal
analysis
InterfaceReconButGlobalCntlDrivers All the CNTLs that Error,ensure this is intended in design. Review
are reported as the reconverging signals. Make sure they are Gray
drivers for this recon Coded using Meridian CDC formal analysis
point are part of an
interface, BUT there
are also other CNTLs
that drive this recon.
These are CNTLs that
are typically in other
clock
domains.
GlobalReconNoInterface The recon is truly not Error, Check whether interface association needs
part of any interface to be manually added using create_association.
Review the reconverging signals. Make sure
they are Gray Coded using Meridian CDC formal
analysis.
SubsetDrivers Addded where Informational, This can only happen in case of
the recon drivers multiple TX
listed in a violation domains, where the recon is split into multiple
are a subset of the violations per each TX domain. It is possible
overall recon sometimes there is only driver in a given TX
drivers for that recon domain (which
flop cannot cause recon) and hence ignored in
reporting. So, whenever, "SubsetDrivers" is seen
in Info column, it means the ReconSignal is
listed in some other recon violation as well,
or that it has some singleton CNTLs coming
in from a different TX domain which were

rejected. We may get a request from field to do

an enhancement to list that singleton CNTL as
well in the log etc (which are most likely global
CNTL signals).
Note that output ports as recon point are reported with one higher depth. Output ports driven by a single flop
(via direct assignment or via buffer/inverter chain) are not reported as recon, since the flop driving these is
already being reported.
EXAMPLES
For example, in Figure, three signals, siga, sigb, sigc, are synchronized in the Rx clock domain and appear to
reconverge. Meridian CDC will report siga, sigb, sigc, and the recon_point, in the W_RECON_GROUPS category.
RELATED VARIABLES
ri_report_all_w_recon_points
ri_report_crossing_rx_net_as_recon_point
ri_report_recon_dbg_files
ri_report_w_recon_groups
ri_report_w_recon_points

W_REDUNDANT_SYNC
This category reports synchronizers which are redundant. A synchronizer is considered redundant if launch and capture
clocks belong to same domain. This is reported when
1. Primary input and synchronizers are same clock domain.
2. Reset synchronizer are in the same clock domain.
SEVERITY WARNING
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_REDUNDANT_SYNC. These attributes are

Name (Read/Write)
Signal string R Launch signal name
Location string R Location of the capture flop in RTL source in format

"FileName:LineNo"
ReceivingFlop string R Name of the receive flop
SyncDepth string R Synchronizer depth
DESCRIPTION
Suggested Action: Fix the design to remove synchronizer if not needed. If env specification is incorrect fix
that.
EXAMPLES
Figure shows an example of W_REDUNDANT_SYNC and when Input Port clock domain is same as receive clock domain.

RELATED VARIABLES
ri_report_w_redundant_sync

W_RST_HALF
This category detects a half-cycle synchronizer stage in the reset synchronizer logic.
SEVERITY WARNING
CATEGORY CDC_CHECKS
RULE ATTRIBUTES
The following table describes the header attributes specific to W_RST_HALF. These attributes are available

Name (Read/Write)
ResetSignal string R Name of reset signal
ReceivingFlop string R Name of the first flop in receive domain

Location string R Location of the flop using opposite edge of the clock in RTL source
in format "FileName:LineNo"
SyncFlop string R Name of final flop in synchronizer

SyncDepth string R Number of flop stages in synchronizer
DESCRIPTION
Meridian CDC has detected a half-cycle synchronizer stage in the reset synchronizer logic. This half cycle is
usually a flop that is clocked by the opposite edge logic of other flops in the synchronizer. Such logic may
result in transitions that may be too fast for the signals entering the flop to meet timing.
Suggested Action: Ensure that enough time will be available for metastability to resolve within the
synchronizer.
RELATED VARIABLES
ri_report_w_rst_half

W_RST_SPEC_CLK
This category reports any signal that feeds reset pins of one or more flops but has a periodic behavior (either by
specifying the reset pin as clock in the environment file, or by deriving from a periodic waveform).
SEVERITY WARNING
CATEGORY CDC_CHECKS
DEFAULT Reported
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_RST_SPEC_CLK. These attributes are

Name (Read/Write)
ResetSignal string R Name of the signal identified as reset
SampleFlop string R Sample flop connected to reset
Location string R Location of the flop in RTL source in format "FileName:LineNo"
DESCRIPTION
Suggested Action: Ensure that the desired behavior is appropriately covered in timing analysis.
EXAMPLES
In the figure, the asynchronous reset ‘asyn_rst’ is derived from the signal ‘clk’. Since ‘clk’ is specified as
a clock signal in the environment file using the create_clock command, the ‘asyn_rst’ inherits the periodic
behavior of the clock.This periodic behavior conflicts with the internal Meridian CDC assumption that a reset
signal is active initially for a short duration and is then de-asserted during the normal operation of the chip.

RELATED VARIABLES
i_report_w_rst_spec_clk

W_RST_UNCERTAINTY
Flops that interact within a clock domain are reset both by a synchronized reset signal and by another reset signal
where metastability during the synchronized reset deassert may lead to unpredictable reset behavior. It is also
reported when various reset synchronizers converge. The output the two reset synchronizers may be off by one clock
due to metastability correction within the synchronizers. This category is not reported by default. To enable reporting,
set variable ri_report_w_rst_uncertainty to true.
SEVERITY WARNING
CATEGORY CDC_CHECKS
BEHAVIOUR
RULE ATTRIBUTES
The following table describes the header attributes specific to W_RST_UNCERTAINTY. These attributes are

Name (Read/Write)
ResetSignal string R Final flop name in reset synchronizer
ReconSignal string R Name of the flop where reset paths converge

Location string R Location of the ResetSignal in RTL source in format
"FileName:LineNo"
ReconLocation string R Location in the source code file that contains the reconvergence
flop
DESCRIPTION
Suggested Action: Within each clock domain, reset interacting flops by a signal, synchronized reset signal
or else sign-off on the interacting reset signals.
EXAMPLES
In the example, the asynchronous reset ‘Rst’ is synchronized in two places (i.e. ‘Sync Rst 1’ and ‘Sync Rst 2’).
The input, ‘Cntl’, is unsynchronized and subject to metastability. This causes the MUXed signal “Cntl Sync
Rst 1” to be an unknown value. When the reset path ‘Cntl Sync Rst 1’ reconverges with synchronous reset path
‘Sync Rst 2’, this leads to further uncertainty in the reset path where ‘Cntl Sync Rst 2’ propagates outwards.
Meridian CDC reports this issue as W_RST_UNCERTAINTY.

Following example shows W_RST_UNCERTAINTY being reported in case of reset synchronizer reconvergence
RELATED VARIABLES

ri_report_w_rst_uncertainty

Variable Reference
Meridian CDC provides a number of Tcl variables for configuring and controlling the verification process. There are
several ways to set and control variables within the Meridian CDC shell. Meridian CDC is written using a standard Tcl-
based shell environment that you can modify using standard Tcl variable procedures.
Where to place the variable commands depends upon the mode of operation. There are several methods:
• by writing the code within the Meridian CDC shell or the control file
• by manually sourcing an external file within the Meridian CDC shell (source filename). This method provides a simple
indexing scheme that can be used to reference an individual library of custom functions.
• by adding code to user’s .realrc file, either in the home directory or the run directory. This is useful for configuring
default variables to be set each time the user runs, independent of the project (see below for details).
Online Help for Variables

Online help is provided for all variables. Variables are grouped by topic. Type "help topics" to get a list of topics and
"help topic <topic_name>" for a list of variables on the specified topic. A description of a specific variable is provided
by typing "help <var_name>".
For example:
prompt> help topics

**> help topics
Use 'help topic <topic name>' for more information.
Unique prefixes are permitted. Topics are:
compilation
env_sdc
formal_analysis
general
read_only
setup_analysis
...
prompt> help topic compilation
**> help topic compilation

List of variables for topic compilation:
ri_allow_plus_in_incdir
...
ri_search_path
...
Use 'help <variable name>' for more information.
prompt> help ri_search_path
**> help ri_search_path

List of directories to find source files and to be added to all -incdir and -y search paths.
Default value is "".
The current setting can be printed in the Meridian CDC shell using the command:
puts ${variable}

See the topic for each variable for more information on how it affects verification results.
To configure or enable an internal variable, prepend the variable name with the word set. For example, to suppress
message ID 24004 from the log files, type:
set ri_suppress_msg 24004
Important Note: All variable text and values should be lowercase; Meridian CDC does not recognize uppercase.
Tip: Set the ri_enforce_strict_variable_settings variable to true to configure the tool to error when an unrecognized
variable is read.

design_configuration
This section describe all the variables available in Meridian CDC to configure design compilation functionality.

ri_allow_plus_in_incdir
Use this variable to allow the "+" character in the name of the include directory. By default, “+incdir+dir1+dir2”.
specifies a list of directories in which to search for include files, where the "+" is used to deliniate the directory names.
When this variable is set to true, the path of the search directories may include the “+” character. In this case, each
directory must be specified separately using multiple +include+ options.
TYPE
boolean: true, false
DEFAULT
false
GROUP
compilation
EXAMPLES
Example 1:
set ri_allow_plus_in_incdir true
analyze file.v +include+incdir1 +include+/home/user/src+incs/
Example 2:
set ri_allow_plus_in_incdir false
analyze file.v +include+incdir1+/home/user/src_incs/
RELATED RULES
RELATED COMMANDS
analyze
RELATED VARIABLES

ri_assoc_as_fixed_array
This variable controls whether an associative associative array is converted to a fixed array size so it can be
synthesized. Users might use this switch when they use associative arrays for efficient memory modeling. When true,
associative arrays are translated to a fixed array whose size is determined by the address width. The translated array
can then be recognized as a RAM or Big Array. The maximum size is 2^31.
The size is automatically determined. To control the size of the array that it gets translated to, use
ri_assoc_as_fixed_array_of_size. ri_assoc_as_fixed_array_of_size takes precedence so the size can be controlled.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_assoc_as_fixed_array true
RELATED COMMANDS
analyze
RELATED VARIABLES
ri_assoc_as_fixed_array_of_size

ri_assoc_as_fixed_array_of_size
This variable controls the size of the fixed array for converted associative arrays. Users might use this switch when
they use associative arrays for efficient memory modeling. When non-zero, this variable is used to translate associative
arrays to a fixed array, which can then be recognized as a RAM or Big Array. When a size of 0 is specified, no translation
occurs unless ri_assoc_as_fixed_array is true.
TYPE
Hexadecimal numbers
DEFAULT
Default value is 0, which disables the translation
GROUP
compilation
EXAMPLES
set ri_assoc_as_fixed_array_of_size 0x00ffffff
RELATED COMMANDS
analyze
RELATED VARIABLES
ri_assoc_as_fixed_array

ri_auto_get_lib
This variable controls what libraries are searched when looking for the elaboration top. When true, the tool will
automatically find the elaborated top module/entity’s work library by searching all libraries if it is not found in the
specified library. When false (default) the tool will error when a library is not found in the specified library.
TYPE
DEFAULT
false.
GROUP
compilation
EXAMPLES
# in the following script, assume that “top” instantiates “file1”. file1.vhd is compiled to library “my_work”,
but top.vhd is compiled to the default work “work”. The elaborate command states to look for the top module
in “my_work”. By setting ri_auto_get_lib to true, Meridian CDC looks in all known libraries when it is not found
in the specified library. In this example, an elaboration error would occur if ri_auto_get_lib were false, which
is the default.
set ri_auto_get_lib true

analyze -work my_work file1.vhd
analyze top.vhd
elaborate -work my_work top
RELATED COMMANDS
elaborate
RELATED VARIABLES
None

ri_cadence_compatible
This variable controls whether or not the Cadence extensions of PSL will be accepted.
TYPE
DEFAULT
true
GROUP
compilation
EXAMPLES
set ri_cadence_compatible false
RELATED COMMANDS
analyze
RELATED VARIABLES
None

ri_count_rtl_only_flops_and_latches_in_design_stats
If set to true, in the design stats section reported in the Meridian CDC log file, Meridian CDC counts flops and latches
that can be inferred from RTL only. By default, all signals, including those synthesized via assumes or asserts or
SystemVerilog constructs such as $rose, $fell etc will be counted towards the reported flops and latches.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_count_rtl_only_flops_and_latches_in_design_stats true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

ri_dash_v_is_lib_cell
When true, files specified with -v switch are treated as library cells. The specified files are flattened for optimum
performance in processing, so internal nodes of these library cells may not be accessible. When false(default), there
exists full visibility of all internal nodes. Changing the value of this variable provides a tradeoff between debug
visibility and performance. It is not expected to be necessary.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_dash_v_is_lib_cell true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

By default, the following pragma keywords are recognized: verific, exemplar, synopsys, cadence, pragma, synthesis,
LV_BIST, spyglass, 0-in, and magma. Users can set this variable to disable all pragmas of the specified vendor(s).
Alternatively, the analyze command option -ignore_pragma_vendors will override this variable. Also, the analyze
command option -ignore_translate_off can be used to disable translate_off and synthesis_off pragmas from the
specified vendors.
TYPE
string list
valid list items: LV_BIST spyglass 0-in magma.
DEFAULT
{}
GROUP
compilation
EXAMPLES
# define magma as a keyword that should be recognized in addition the defaults
set ri_ignore_pragma_vendors {magma}
RELATED RULES
RELATED COMMANDS
analyze
RELATED VARIABLES

ri_ignore_vs_files
When set to true, Meridian CDC will ignore all files ending in extension “.vs” from being analyzed. Set this variable to
false when .vs files should be processed as RTL files. This variable is used to bypass some vendor specific, non-standard
applications.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_ignore_vs_files true
RELATED COMMANDS
analyze
RELATED VARIABLES
None

By default, +incdir+ and +define+ command line arguments to the analyze command are specific to the files listed on
that command, versus accumulated across all analyze commands. It does not affect the accumulation of these arguments
for the processing of library cells.
Set this variable to true when the defines and the include directories specified on an analyze command should be applied
to all subsequent analyze commands. This is used to bypass some vendor specific, non-standard applications.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_incdef_accumulate true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_vy_lib_accumulate, ri_search_path

ri_match_nc
The ri_match_nc variable can be set to true to match NCSim behavior relative to the handling of packages in library
files. When false, unused packages are removed from libraries if they are not referenced by the current library file or
path. They are not visible outside the current library file or path. When true, packages are kept in libraries for reference
from other library files or paths.
TYPE
DEFAULT
false
GROUP
compilation
EXAMPLES
set ri_match_nc true
RELATED COMMANDS
analyze
elaborate
RELATED VARIABLES
ri_cadence_compatible

ri_match_vcs
This variable controls the length of the multiple concatenation expression. When ri_match_vcs is set to a value of false,
then a zero length multiple concatenation expression, for example, {0{xx}}, is evaluated as 1'b0 for both SystemVerilog
and Verilog. When ri_match_vcs is set to true, then for SystemVerilog designs, when a zero length multiple concatenation
occurs within a concatenate expression, it is evaluated to have a length of zero. If a zero length multiple concatenation
is not within a concatenate expression, then an error is reported. For Verilog designs, it is evaluated as 1'b0.
TYPE
DEFAULT
false
GROUP
EXAMPLES
set ri_match_vcs true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

ri_max_exceeded_stops_elab
For any big loop or big array (big id), when the specified maximum is exceeded, analysis either stops with an error or
the big array or big loop is automatically blackboxed, depending on this variable. When ri_max_exceeded_stops_elab
is true, an error occurs. When ri_max_exceeded_stops_elab is false, the big loop or big array is blackboxed. Inputs will
not have any load and outputs will be undriven. The compilation summary and the setup report will show that the big
loop/big array is blackboxed. This is applicable to Verilog/SystemVerilog only.
TYPE
integer value
DEFAULT
false
CATEGORY
design compilation
EXAMPLES
set ri_max_ecceded_stops_elab true
RELATED COMMANDS
analyze
elaborate
RELATED VARIABLES
ri_max_loop_unroll
ri_max_single_range_bits
ri_max_total_range_bits

ri_max_loop_unroll
This variable controls the maximum number of times to unroll a loop in a design before processing exits. During
elaboration, for each iteration of a for-loop, Meridian CDC needs to build a model. For optimization, Meridian
CDC limits the number of iterations a loop will make. For any loop, it is unrolled the specified number of
times and if it is not terminated, analysis either stops with an error or is automatically blackboxed, depending
the loop will be undriven. The compilation summary and the setup report will show that the loop is blackboxed.
TYPE
Integer
DEFAULT
1024
GROUP
compilation
EXAMPLES
set ri_max_loop_unroll 500
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

This variable controls the maximum allowed size, in bits, for a single dimension of a variable indexed array. This variable
is used in conjunction with ri_max_total_range_bits to determine whether an array is expanded to flops or blackboxed.
If ri_max_single_range_bits is larger than ri_max_total_range_bits, then ri_max_total_range_bits will be automatically
set to the same value as ri_max_single_range_bits
When the specified maximum is exceeded, analysis either stops with an error or is automatically blackboxed. When
ri_max_exceeded_stops_elab is true, an error occurs. When ri_max_exceeded_stops_elab is false, the big array is
ignored. Inputs will not have any load and outputs will be undriven. The compilation summary and the setup report will
show that the big array is blackboxed.
TYPE
integer
DEFAULT
12
GROUP
compilation
EXAMPLES
# For the array: reg [21:0] rom1 [1023:0], 2**10=1024 so it takes 10 bits
# to represent the address range, and 2**5=32 so it takes 5 bits to represent
# the 22 words. So with:
set ri_max_single_range_bits 20 # the array is modeled
set ri_max_single_range_bits 10 # the array is modeled
set ri_max_single_range_bits 5 # array would be blackboxed.
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

This variable is used in conjunction with ri_max_single_range_bits to determine whether an array is expanded to flops.
This variable specifies the maximum allowed address size, in bits, for all dimensions of a variable indexed array that will
be expanded as flops. If ri_max_single_range_bits is larger than ri_max_total_range_bits, then ri_max_total_range_bits
will be automatically set to the same value as ri_max_single_range_bits .
For any array that exceeds the size, analysis either stops with an error or is automatically blackboxed, depending
the loop will be undriven. The compilation summary and the setup report will show that the loop is blackboxed.
Increasing the value may prevent blackboxing which can slow performance, but verification is more accurate. Lowering
the value will cause more blackboxing, faster.
TYPE
Integer
DEFAULT
12
GROUP
compilation
EXAMPLES
# For the array: reg [21:0] rom1 [1023:0], it takes 2**10=1024 so it
# takes 10 bits to represent the addreass range and 2**5=32 so it takes
# 5 bits to represent the 22 words, a total of 15 bits. So with:
set ri_max_total_range_bits 20 # the array is modeled
set ri_max_total_range_bits 15 # the array is modeled
set ri_max_total_range_bits 10 # array would be blackboxed.
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

ri_preserve_paths_in_auto_bboxed_insts
By default, Meridian CDC automatically blackboxes arithmetic operators and memory. For these blackboxed modules,
there is no path from inputs to outputs. This variable is used to create a crossbar from inputs to outputs so that
specified waveforms on the inputs can be propagated to the outputs. The output, however, will still be driven with
1'bx.
The user can set this variable to false if he/she does not want to have the waveform from the inputs of the auto
blackboxed module to be propagated to the outputs of these modules.
TYPE
DEFAULT
true
GROUP
EXAMPLES
set ri_preserve_paths_in_auto_bboxed_inst false
RELATED COMMANDS
analyze
RELATED VARIABLES
None

ri_quick_FE_run
Specify whether to perform a quick front-end run on the design. Meridian CDC quits after analyze and elaborate
commands. The design database is not generated. The .src_files file in the project directory contains the entire file list
from these two commands.
Value
Value Type : boolean
Valid Values : true | false
Default Value : false
Category design_configuration
EXAMPLES
prompt> set ri_quick_FE_run true
RELATED COMMANDS
analyze
elaborate
RELATED VARIABLES
None

ri_ram_max_reset_count
This variable is the maximum count of async reset ports for an array to be recognized as a RAM. In addition to asynchronous
resets, synchronous resets with an initialization loop are also counted. Arrays with more resets will not be treated as a
RAM. The setting of this variable must be done before the analyze command.
TYPE
integer
DEFAULT
1
CATEGORY
compilation
EXAMPLES
• Example-1 : Increase the number of resets ports for an array to be 4
prompt> set ri_ram_max_reset_count 4
RELATED COMMANDS
analyze
RELATED VARIABLES
ri_ram_min_size
ri_ram_min_words

ri_ram_max_word_size
This variable is the maximum number of bits in one word, above which an array will not be recognized as a RAM. The
larger the value, the bigger the impact in time and memory to model the RAM. When the number of bits in a word exceeds
this threshhold, the description is treated as a data array.
TYPE
integer
DEFAULT
4096
CATEGORY
compilation
EXAMPLES
• Example-1 :
prompt> set ri_ram_max_word_size 64
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_ram_min_size
ri_ram_min_words

ri_ram_min_size
This variable is used in conjunction with to set the minimum number of memory locations, above which, the memory
may be modeled as a RAM. Refer to Identification of RAMs. The setting of this configuration must occur before the
analyze command. If the size of the memory array is less than or equal to this value, then the memory array will be
modeled as flops.
The user can adjust this variable parameter to allow larger memory blocks to be expanded, at the trade off of
verification performance.
TYPE
integer
DEFAULT
product dependent
GROUP
EXAMPLES
• Example-1 : Assume you have the following memory declaration:

Data1 will be modeled as a RAM when both ri_ram_min_size <128 and ri_ram_min_words <16,
otherwise it will be modeled as a flops. Similarly, data2 will be modeled as a RAM when both
ri_ram_min_size < 512 and ri_ram_min_words < 32, otherwise it will be modeled as a flops.
• Example 2: Increase this variable and ri_ram_min_words to allow larger memory blocks to be analyzed as
flops, at the trade off of verification performance.
prompt> set ri_ram_min_size 1024
RELATED COMMANDS
analyze
RELATED VARIABLES
ri_ram_min_words

ri_ram_min_words
This variable is used in conjunction with ri_ram_min_size to set the minimum size of a memory in words, above which,
the memory may be modeled as a RAM. Refer to Identification of RAMs.
The setting of this configuration must occur before the analyze command. If the size of the memory array is less than
or equal to this value, then the memory array will be modeled as flops.
TYPE
integer
DEFAULT
0
GROUP
EXAMPLES
As an example, assume you have the following memory declaration:
Data1 will be modeled as a RAM when both ri_ram_min_size <128 and ri_ram_min_words <16, otherwise it will
be modeled as a flops.
Similarly, data2 will be modeled as a RAM when both ri_ram_min_size < 512 and ri_ram_min_words < 32,
otherwise it will be modeled as a flops.
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_ram_min_size

ri_report_inferred_flops_in_log
When true, Meridian CDC will report a list of inferred flops in the logfile. When false, inferred latches are not listed.
TYPE
DEFAULT
false
CATEGORY
EXAMPLES
• Example-1 :
prompt> set ri_report_inferred_flops_in_log true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

ri_report_inferred_latches_in_log
When true, Meridian CDC will report a list of inferred latches in the logfile. When false, inferred latches are not listed.
TYPE
DEFAULT
false
CATEGORY
EXAMPLES
• Example-1 :
prompt> set ri_report_inferred_latches_in_log true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

ri_search_path
This variable is used to specify the search path and search order for source files, library files and include files when
they are not found elsewhere (Note: only use this for missing source files when Verdi is not going to be used). For
include files, the search path is, in this order, the current directory, the +incdir+ directory, followed by the paths
specified by this variable. For unresolved modules and source files, the search path is, in this order, the files specified
by -v in the directories specified by -y, followed by the paths specified by this variable.
TYPE
space separated list of paths
DEFAULT
{}
GROUP
EXAMPLES
Example-1:
prompt> set ri_search_path {$HOME/my_libs $HOME/my_includes}
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

ri_synth_models_internal_dirs
This variable is used to specify the list of directories to search for synthesizable models, searching from left to right
in the directory list. If the file is not found in the directories specifed by ri_synth_model_user_dirs, the directories
specified by this variable are searched from the first in the list to the last in the list.
This variable specifies the leaf directory name of the models provided in the installation (not the full path)
<RI_INSTALL>/synth_models directory. To turn off the search of the installation models, set this to {}. The variable is
intended only to allow for changing the search order when there is more than one directory of models.
TYPE
directory name under <RI_INSTALL>/synth_models
DEFAULT
{ user vendor1}
GROUP
EXAMPLES
• Example-1 : specify not to use the models
prompt> set ri_synth_models_internal_dirs {}
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_synth_models_user_dirs

ri_synth_models_user_dirs
This variable is used to specify the list of directories to search for synthesizable models, searching from left
to right in the directory list. These directories are searched before the installation directories specified in
ri_synth_models_internal_dirs. The filename of the simulation model must match the filename of the
synthesizable model.
TYPE
full path to a directory
DEFAULT
{}
GROUP
design_xonfiguration
EXAMPLES
Example-1 : specify to use the models from the user home directory
prompt> set ri_synth_models_user_dirs {$HOME}
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_synth_models_internal_dirs

ri_vhdl_allowed_logic_types
When setting this variable to true, and if the compiled design contains Synopsys DesignWare components, Meridian CDC
will create a directory called ri_templates under the specified Meridian CDC project directory (default <project_dir>/
ri_templates), and write out template models that can be used to instantiate netlist models of each parameterization
of the DesignWare components that the design uses.
Value
EXAMPLES
• Example-1 :
prompt> set ri_chdl_allowed_logic_types true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

ri_vhdl_map_work_to_target_library
By default, when a VHDL use clause names a package in a specified library, then that package must exist in that named
library. When true, if a VHDL use clause names a package in library ‘work’, but the package has not been compiled into
‘work’, then find a package with the same name compiled into the current named -work library. If the package is not
found there either, then the tool searches all libraries.
TYPE
DEFAULT
false
CATEGORY
EXAMPLES
Example-1 :
prompt> set ri_vhdl_map_work_to_target_library true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
ri_auto_get_lib

ri_vhdl_preserve_case
When true, the analyze command strictly enforces VHDL’s library visibility rules that require symbols to be visible when
a source file is read. When false, all symbols are resolved at elaboration so the files can be analyzed in any order.
TYPE
boolean: true, false.
DEFAULT
false
CATEGORY
EXAMPLES
Example-1 :
prompt> set ri_vhdl_require_ordered_analyze true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

ri_vhdl_require_ordered_analyze
When true, the analyze command strictly enforces VHDL’s library visibility rules that require symbols to be visible when
a source file is read. When false, all symbols are resolved at elaboration so the files can be analyzed in any order.
TYPE
DEFAULT
false
CATEGORY
EXAMPLES
Example-1 :
prompt> set ri_vhdl_require_ordered_analyze true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

ri_vhdl_std_logic_dash_is_x
This variable controls whether ‘-’ in VHDL is interpreted as Don’t Care or Unknown. When ri_vhdl_std_logic_dash_is_x
is false, a VHDL '-' is treated as Don't Care(default). When ri_vhdl_std_logic_dash_is_x is set to true, '-' will be treated
as 'X', meaning that '-' is interpreted strictly as a symbol which does not match any of the other 8 std_logic values.
.
TYPE
DEFAULT
false
CATEGORY
EXAMPLES
• Example-1 :
prompt> set ri_vhdl_std_logic_is_x true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES
None

When true, Verilog library paths and files are accumulated across analyze commands. When false (default), library paths
and files are local to the analyze command they are associated with. When accumulation is true, analysis of the libraries
occurs at the beginning of elaboration, so any special analysis options that are needed for library files should be provided
to the elaborate command as well.
Value
EXAMPLES
• Example-1 :
prompt> set ri_vy_lib_accumulate true
RELATED COMMANDS
analyze, elaborate
RELATED VARIABLES

cdc_configuration
This section describe all the variables available in Meridian CDC to configure Clock Domain Crossing Checking
functionality.

ri_allow_flop_driven_clk_gate
By default, only latch-based clock gating cell is supported. By setting this variable to true, Meridian CDC will support
flop based clock gating cell.
Value
Default Value : true
Category cdc_configuration
EXAMPLES
set ri_allow_flop_driven_clk_gate true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_allow_ram_pin_driver_for_cntl
Variable enables synchronizer detection of the clock domain crossing when the crossing driver is a RAM pin. By
default,Meridian CDC product does not detect synchronizers of the crossings that are driven by RAM pins.
Value
EXAMPLES
set ri_allow_flop_driven_clk_gate true
RELATED COMMANDS
None
RELATED VARIABLES
None

By default, Meridian CDC regards primary inputs that cross asynchronous clock domains controlling data crossings with
glitch potential, and they will be reported in the W_GLITCH category.
Value
EXAMPLES
set ri_assume_primary_inputs_have_glitch_potential false
RELATED COMMANDS
set_glitch_free_inputs
RELATED VARIABLES
None

ri_check_cntl_depth_mismatch
This Boolean variable controls whether the depth mismatch between different CNTL-to-DATA paths should be reported
as W_CNTL category.
Value
EXAMPLES
set ri_check_cntl_depth_mismatch true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_check_cntl_type_mismatch
This Boolean variable controls whether the association type mismatch between different CNTL-to DATA paths should be
reported as W_CNTL category.
Value
EXAMPLES
set ri_check_cntl_type_mismatch true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_check_missing_feedback
This Boolean variable controls whether the CNTL with missing FEEDBACK should be reported as W_CNTL category.
Value
EXAMPLES
set ri_check_missing_feedback false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_detect_masync_on_outputs
By default, Meridian CDC checks W_MASYNC for output signals. Setting this variable to false will disable Meridian CDC
from checking W_MASYNC on outputs.
Value
EXAMPLES
set ri_detect_masync_on_outputs false
RELATED COMMANDS
None
RELATED VARIABLES
ri_report_w_masync

ri_detect_missing_sync_reset
This option controls the analysis of potential missing synchronous resets. It causes missing sunchronous resets to be
listed in the S_NORST category.
Value
EXAMPLES
set ri_detect_missing_sync_reset false
RELATED COMMANDS
None
RELATED VARIABLES

Specify the effort level that Meridian CDC should take in performing data control analysis when variable
ri_identify_data_control_condition variable is set to true
Value
Value Type : integer
Valid Values : 1-5
Default Value : 3
EXAMPLES
set ri_effort_level_for_data_control_condition 2
RELATED COMMANDS
None
RELATED VARIABLES

ri_exclude_association_through_clock_gate
By default structural analysis uses clock gate path also for CNTL-DATA association. Setting this variable to true will
cause structural analysis to not use any clock gate path for CNTL-DATA association.
Value
EXAMPLES
set ri_exclude_association_through_clock_gate true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_exclude_clock_path_from_recon
Specify to exclude clock paths in reconvergence analysis.
Value
EXAMPLES
set ri_exclude_clock_path_from_recon true
RELATED COMMANDS
None
RELATED VARIABLES

ri_exclude_cntl_masync_from_w_glitch
By default, Meridian CDC also reports control crossings that have W_MASYNC violations in the W_GLITCH category so
that formal glitch checking can be performed on these control W_MASYNC. Setting the variable to true will disable
reporting of these control W_MASYNC in W_GLITCH.
Value
EXAMPLES
set ri_exclude_cntl_masync_from_w_glitch true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_fill_info_column_for_rs
Turn on Info column display in iDebug for RST_SYNC. When the variable is set to true
When true then the Info column contains one of the following keywords:
a. SyncAssertSyncDeassert - Reset signal is synchronously asserted and deasserted
b. AsyncAssertSyncDeassert - Reset signal is asynchronously asserted and synchronously deasserted
When false then then Info column contains NoUserSyncCell if set_user_reset_synchronizer is not specified in the
runscript.
Value
EXAMPLES
• Example-1 : Turn on Info column display in iDebug for RST_SYNC
prompt> set ri_fill_info_column_for_rs true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_fill_info_column_for_warfs
Turn on Info column display in iDebug for W_ASYNC_RST_FLOPS.
Value
EXAMPLES
• Example-1 : Turn on Info column display in iDebug for W_ASYNC_RST_FLOPS
prompt> set ri_fill_info_column_for_warfs true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_group_data_rx_in_interface
When set to "all" and DATA RxFlops that have the same CNTLs at the same depth and same association type are grouped
into one interface. When set to "bus", only DATA RxFlops that are part of a bus are grouped together. When set to
"none", each DATA RxFlop is reported independently in its own interface. Note that when grouping DATA RxFlops, all the
DATA transmitters are clubbed together into the same interface.
Value
Value Type : string
Valid Values : all,bus,none
Default Value : all
EXAMPLES
set ri_group_data_rx_in_interface bus
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_identify_controlled_propagation
When setting this variable to true, Meridian CDC performs PROP_CNTL_DATA crossing analysis.
Value
EXAMPLES
set ri_identify_controlled_propagation true
RELATED COMMANDS
None
RELATED VARIABLES
None

When setting this variable to true, Meridian CDC performs the following advanced rule checking for Load and FIFO
controlled DATAs in the following order:
1. If there doesn’t exist a Boolean value combination of the receiving side signals that can block all paths from the
transmitting flops, then the DATA signal is converted to W_DATA with the status “Data-Control-NonBlock”.
2. If the Boolean analysis finished with a set of Boolean values that allows the data transfer with the help of other signals
rather than through the synchronizers, the DATA signal is converted to W_DATA with the status “Data-Control-ByPass”.
3. If the Boolean analysis could not finish for some reason, the DATA signal is converted to W_DATA with the status “Data-
Control-Complex” so users can examine these.
4. If Meridian CDC doesn’t support the design style to be analyzed or if the setup is bad, the DATA signal is converted to
W_DATA with the status “Data-Control-Unprocessed” so users can examine these.
5. If none of the above happens, the DATA signal remains in the DATA category with the status “Data-Control-Pass” and
the block Boolean value combinations will be report in the .dbg file. Users can review those value combinations in the
Meridian CDC
Value
EXAMPLES
set ri_identify_data_control_condition true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_identify_sync_path_blocking
Identify masync crossings that may prevent CNTL-DATA associations.
Value
EXAMPLES
prompt> set ri_identify_sync_path_blocking true
RELATED COMMANDS
verify_cdc
RELATED VARIABLES
None

ri_ignore_w_fanout_with_no_recon
By default, Meridian CDC issues W_FANOUT for all crossings that fan out to multiple synchronizers. Set this variable to
true to report only W_FANOUT warnings having reconvergence points.
Value
EXAMPLES
set ri_ignore_w_fanout_with_no_recon true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_max_glitch_driver_count
This variable specifies the maximum number of flops Meridian CDC will report as sources for potential glitches in the
W_GLITCH, W_G_CLK_GLITCH and W_D_CLK_GLITCH categories.
Value
Valid Values : positive integer
Default Value : 5
EXAMPLES
set ri_max_glitch_driver_count 3
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_max_num_vcd_files
This variable specifies the maximum number of VCD files to be generated by the tool for the failing formal checks. Set
to 0 to have no VCD file generated.
Value
Default Value : 10
EXAMPLES
• Example-1 : Specify a maximum of 5 VCD files
prompt> set ri_max_num_vcd_files 5
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_min_synchronizer_depth_3_domains
This variable specifies the names of the asynchronous clock domains which require synchronizers with the minimum
number of 3 back to back flops. Control signals in these clock domains with sync-depth less than 3 will be reported as
W_CNTL with the INFO message “Sync-Depth-Err”.
Value
Value Type : list
Valid Values : clock domain names
Default Value : {}
EXAMPLES
set ri_min_synchronizer_depth_3_domains {clk1 clk2}
RELATED COMMANDS
None
RELATED VARIABLES
None

Value
Value Type : list
Default Value : {}
EXAMPLES
RELATED COMMANDS
None
RELATED VARIABLES
None

Value
Value Type : list
Default Value : {}
EXAMPLES
RELATED COMMANDS
None
RELATED VARIABLES
None

Value
Value Type : list
Default Value : {}
EXAMPLES
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_on_the_fly_shell_write_debug
This variable provides user controlability of debug messages to the log file to explain why certain violations are still
reported inside the shelled out modules/instances.
Value
EXAMPLES
set ri_on_the_fly_shell_write_debug true
RELATED COMMANDS
None
RELATED VARIABLES
None

Specify the maximum number of flops in a synchronizer that can be converted to data by auto-reclass
Value
Default Value : 1
EXAMPLES
set ri_reclass_max_sync_depth_to_data 2
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_all_signals_in_i_constant
Set this to true to report all wires and combinatorial signals in I_CONSTANT category. When the variable is false and
only ports, flops and latches are reported.
Value
EXAMPLES
set ri_report_all_signals_in_i_constant true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_all_unregistered_outputs_in_w_encap
Report all unregistered outputs in W_ENCAP category.
Value
EXAMPLES
set ri_report_all_unregistered_outputs_in_w_encap true
RELATED COMMANDS
None
RELATED VARIABLES
None

Report unlimited version of W_BLOCKED_CROSSING category. Use ri_report_w_blocked_crossing to enable reporting of
this category first.
By default, paths where Transmit Flop or Receive Flop are constants are not reported in W_BLOCKED_CROSSING. When
set to true, W_BLOCKED_CROSSING includes the paths where Transmit Flop or Receive Flop are constants.
Value
EXAMPLES
set ri_report_all_w_blocked_crossing true
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_all_w_fanout_points
Report W_FANOUT points, even when they are structurally dominated by other W_FANOUT points.
Value
EXAMPLES
• Example-1 : Report W_FANOUT points, even when they are structurally dominated by other W_FANOUT points
prompt> set ri_report_all_w_fanout_points true
RELATED COMMANDS
None
RELATED VARIABLES
None

By default, W_RECON_GROUPS reports all the reconverging flops. When this variable is set to true, Meridian CDC will
report all reconvergence flops even though they may have the same set of transmitters and multiple reconpoint in the
fanout cone of the transmitters but with bus collapsing so only one bit of a bus will be reported.
So consider a scenario where control signals A,B reconverging at depth 1 and signal A,B,C reconverging at depth 2. By
default only one A,B,C will be reported. Setting this variable to true will cause to report both the reconvergences.
Value
EXAMPLES
set ri_report_all_w_recon_points true
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_clk_glitch_dbg_files
Generate report files for enhancing debug information for W_G_CLK_GLITCH and W_D_CLK_GLITCH
Value
EXAMPLES
set ri_report_clk_glitch_dbg_files false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_clk_groups
Report CLK_GROUPS category.
Value
EXAMPLES
set ri_report_clk_groups false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_crossing_rx_net_as_recon_point
Enables crossings net to be reported as a reconvergence point when both CNTL and DATA are reconverging on the same
net.
Value
EXAMPLES
set ri_report_crossing_rx_net_as_recon_point false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_dbg_file_for_each_driver
Write a .dbg file for each driver in CNTL and DATA categories. When set to false (the default), the result is one .dbg file
for each Rx flop.
Note: Setting this variable to true affects debug.
Value
EXAMPLES
• Example-1 : Write a .dbg file for each driver in CNTL and DATA categories
prompt> set ri_report_dbg_file_for_each_driver true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_dbg_files_for_rs
Create report files with enhanced debug information for RST_SYNC.
Value
EXAMPLES
• Example-1 : Write report files with enhanced debug information for RST_SYNC
prompt> set ri_report_dbg_files_for_rs true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_dbg_files_for_warfs
Create report files with enhanced debug information for W_ASYNC_RST_FLOPS.
Value
EXAMPLES
• Example-1 : Write report files with enhanced debug information for W_ASYNC_RST_FLOPS
prompt> set ri_report_dbg_files_for_warfs true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_dbg_files
Meridian CDC by default generate debug files to enhance debug experience. This variable can control if all debug files
for all the rules to be written out. This will impact user debug.
Value
EXAMPLES
set ri_report_dbg_files false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_err_feedback
Meridian CDC by default does not report the association status Has-Err_Feedback for control crossings. Setting this variable
to true will enable reporting of this association status, as a result, W_CNTL and W_INTERFACE might be reported.
Value
EXAMPLES
set ri_report_err_feedback true
RELATED COMMANDS
None
RELATED VARIABLES
None

When set to true, Meridian CDC will report in the I_GLITCH category all glitch potentials that can occur on all clock
domain data crossings.
Value
EXAMPLES
set ri_report_glitch_on_all_data true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_i_assume
Report I_ASSUME category.
Value
EXAMPLES
set ri_report_i_assume false
RELATED COMMANDS
verify_cdc
RELATED VARIABLES
None

ri_report_i_constant
Report I_CONSTANT category.
Value
EXAMPLES
set ri_report_i_constant false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_i_encap
Report I_ENCAP category.
Value
EXAMPLES
set ri_report_i_encap false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_i_henv_wave_map
Report I_HENV_WAVE_MAP category.
Value
EXAMPLES
set ri_report_i_henv_wave_map false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_interface
Report INTERFACE category.
Value
EXAMPLES
set ri_report_interface false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_masync_dbg_files
Report files for enhancing debug information for W_MASYNC.
Value
EXAMPLES
set ri_report_masync_dbg_files false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_missing_fbs_as_w_interface
When the variable is set to true missing feedback is reported as W_INTERFACE. When the variable is set to false missing
feedback is reported in W_CNTL and corresponding interface is classified as INTERFACE.
Value
EXAMPLES
set ri_report_missing_fbs_as_w_interface true
RELATED COMMANDS
None
RELATED VARIABLES
None

When set to true, Meridian CDC will report none associated CNTL in the W_CNTL category.
Value
EXAMPLES
set ri_report_none_as_w_cntl true
RELATED COMMANDS
None
RELATED VARIABLES
None

Sets the maximum number of drivers to be reported per receive flop for CNTL rule.
Value
Value Type : integer | string
Valid Values : <integer larger than 1> | all
Default Value : all (report all drivers)
EXAMPLES
• Example-1 : Set the maximum number of drivers per receive flop reported to 3
prompt> set ri_report_number_of_drivers_for_cntl 3
RELATED COMMANDS
None
RELATED VARIABLES

Sets the maximum number of drivers to be reported per receive flop for DATA rule.
Value
EXAMPLES
prompt> set ri_report_number_of_drivers_for_data 3
RELATED COMMANDS
None
RELATED VARIABLES

Sets the maximum number of drivers to be reported per receive flop for W_DATA rule. Because W_DATA is a subset of
DATA, the number of drivers reported for W_DATA is always the maximum of ri_report_number_of_drivers_for_data
and ri_report_number_of_drivers_for_w_data. For example, if ri_report_number_of_drivers_for_data is set to all, the
corresponding W_DATA entries will contain all drivers.
Value
EXAMPLES
prompt> set ri_report_number_of_drivers_for_w_data 3
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_potential_static_as_w_cntl
Report CNTL with Potential-Static as W_CNTL.
Value
EXAMPLES
• Example-1 : Report CNTL with Potential-Status as W_CNTL
prompt> set ri_report_potential_static_as_w_cntl true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_pulse_sync
Report PULSE_SYNC category.
Value
EXAMPLES
set ri_report_pulse_sync true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_recon_dbg_files
When set to true, Meridian CDC will report Report files for enhancing debug information for W_RECON.
Value
EXAMPLES
set ri_report_recon_dbg_files true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_reset_syncs_with_func_cdc_as_warf
Restrict RST_SYNC detection to flops that will not be part of a CNTL or DATA crossing. Set it to true to detect RST_SYNC
on all possible flops.
Value
EXAMPLES
set ri_report_reset_syncs_with_func_cdc_as_warf true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_rst_sync
Report RST_SYNC category.
Value
EXAMPLES
set ri_report_rst_sync false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_s_henv_attr_conflict
Report W_HENV_ATTR category.
Value
EXAMPLES
set ri_report_w_henv_attr_conflict false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_s_henv_missing_spec
Report W_HENV_MISSING_SPEC category.
Value
EXAMPLES
set ri_report_w_henv_missing_spec false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_s_henv_type_conflict
Report W_HENV category.
Value
EXAMPLES
set ri_report_w_henv_type_conflict false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_s_henv_waveform_conflict
Report W_HENV_WAVE category.
Value
EXAMPLES
set ri_report_w_henv_waveform_conflict false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_second_stage_as_sync_out
When set to true, Meridian CDC will report the second flop instead of the sync-out flop in CNTL category in case of 3 or
more synchronizer stages.
Value
EXAMPLES
set ri_report_second_stage_as_sync_out true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_sync_crossing
Report SYNC_CROSSING category.
Value
EXAMPLES
set ri_report_sync_crossing true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_u_interface
Report U_INTERFACE category.
Value
EXAMPLES
set ri_report_u_interface false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_async_rst_flops
Report W_ASYNC_RST_FLOPS category.
Value
EXAMPLES
set ri_report_w_async_rst_flops false
RELATED COMMANDS
None
RELATED VARIABLES
None

When set to true, cases where the Transmit Flop to Receive Flop path is blocked are reported in W_BLOCKED_CROSSING.
Paths where Transmit Flop or Receive Flop are constants are not reported in W_BLOCKED_CROSSING. To enable
reporting even when Transmit or Receive Flop are constant, use ri_report_all_w_blocked_crossing.
Add ri_report_all_w_blocked_crossing in related variables
Value
EXAMPLES
set ri_report_w_blocked_crossing true
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_clk_recon
Report W_CLK_RECON category.
Value
EXAMPLES
set ri_report_w_clk_recon false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_cntl
Report W_CNTL category.
Value
EXAMPLES
set ri_report_w_cntl false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_d_clk_glitch
Report W_D_CLK_GLITCH category.
Value
EXAMPLES
set ri_report_w_d_clk_glitch true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_data
Report W_DATA category.
Value
EXAMPLES
set ri_report_w_data false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_encap
Report W_ENCAP category.
Value
EXAMPLES
set ri_report_w_encap false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_fanout
Report W_FANOUT category.
Value
EXAMPLES
set ri_report_w_fanout false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_masync_all_drivers
Report all MASYNC drivers. By default, Meridian CDC reports one driver per unique waveform.
Value
EXAMPLES
set ri_report_w_masync_all_drivers true
RELATED COMMANDS
None
RELATED VARIABLES
None

Report W_G_CLK_GLITCH category.
Value
EXAMPLES
set ri_report_w_g_clk_glitch false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_g_clk_glitch_async_input
Report asynchronous gating signals in the W_G_CLK_GLITCH category. This switch has effect only when
ri_report_w_g_clk_glitch is set to true.
Value
EXAMPLES
set ri_report_w_g_clk_glitch_async_input false
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_g_clk_glitch_async_reset_select
Report an improper use of the gated clock signal in the W_G_CLK_GLITCH category. This switch has effect only when
Value
EXAMPLES
set ri_report_w_g_clk_glitch_async_reset_select false
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_g_clk_glitch_bad_polarity
Value
EXAMPLES
set ri_report_w_g_clk_glitch_bad_polarity true
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_g_clk_glitch_gate_config
Report improper gating logic configurations in the W_G_CLK_GLITCH category. This switch has effect only when
Value
EXAMPLES
set ri_report_w_g_clk_glitch_gate_config false
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_g_clk_glitch_missing_spec
Report missing specs on gating signals in the W_G_CLK_GLITCH category. This switch has effect only when
Value
EXAMPLES
set ri_report_w_g_clk_glitch_missing_spec false
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_g_clk_glitch_sync_reset_select
Value
EXAMPLES
set ri_report_w_g_clk_glitch_sync_reset_select false
RELATED COMMANDS
None
RELATED VARIABLES

ri_report_w_glitch
Report W_GLITCH category.
Value
EXAMPLES
set ri_report_w_glitch false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_half
Report W_HALF category.
Value
EXAMPLES
set ri_report_w_half false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_interface
Report W_INTERFACE category.
Value
EXAMPLES
set ri_report_w_interface false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_lockup
Report W_LOCKUP category.
Value
EXAMPLES
set ri_report_w_lockup true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_masync
Report W_MASYNC category.
Value
EXAMPLES
set ri_report_w_masync false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_recon_groups
Report W_RECON_GROUPS category.
Value
EXAMPLES
set ri_report_w_recon_groups false
RELATED COMMANDS
None
RELATED VARIABLES
None

By default, W_RECON_GROUPS reports the reconverging flops based on the unique set of transmitting synchronizers.
When this variable is set to true, Meridian CDC will report all reconvergence flops even though they may have the same
set of transmitters but with bus collapsing so only one bit of a bus will be reported.
Value
EXAMPLES
set ri_report_w_recon_points true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_redundant_sync
Report W_REDUNDANT_SYNC category.
Value
EXAMPLES
set ri_report_w_redundant_sync false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_rst_glitch
Report W_RST_GLITCH category.
Value
EXAMPLES
set ri_report_w_rst_glitch false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_rst_half
Report W_RST_HALF category.
Value
EXAMPLES
• Example-1 : Disable reporting of W_RST_HALF category
prompt> set ri_report_w_rst_half false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_rst_spec_clk
Report W_RST_SPEC_CLK category.
Value
EXAMPLES
set ri_report_w_rst_spec_clk false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_w_rst_uncertainty
Report W_RST_UNCERTAINTY category.
Value
EXAMPLES
set ri_report_w_rst_uncertainty true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_report_warn_for_all_glitches
When setting to true, Meridian CDC will report in the W_GLITCH category all flops driven from asynchronous clock domain
with glitch potential on input, this includes both control and data crossings.
Value
EXAMPLES
• Example-1 : Enabling all glitches to be reproted
prompt> set ri_report_warn_for_all_glitches true
RELATED COMMANDS
RELATED VARIABLES

ri_require_env_specs_on_all_inputs
Report S_INPUT_NO_WAVE even for inputs driving only combinational logic.
Value
EXAMPLES
set ri_require_env_specs_on_all_inputs true
RELATED COMMANDS
RELATED VARIABLES
ri_require_env_specs_on_all_outputs

ri_require_env_specs_on_all_outputs
Report S_OUTPUT_NO_WAVE even for outputs driven only by combinational logic.
Value
EXAMPLES
set ri_require_env_specs_on_all_outputs true
RELATED COMMANDS
RELATED VARIABLES
ri_require_env_specs_on_all_inputs

ri_restrict_to_definite_constants
By default, Meridian CDC treats flops and latches which transition only once after reset (pseudo constants) as constant
and perform constant propagation during CDC analysis. This could result in crossings unreported or warnings missed
in some categories, such as W_MASYNC. Setting this variable to true restricts Meridian CDC to perform constant
propagation for only definite constants.
Value
EXAMPLES
set ri_restrict_to_definite_constants true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_smallest_depth_recon_report
When this switch is set, recons/fanouts at the smallest depth will be reported when the same group of CNTLs violate at
multiple depths. Similarly, when reporting all recon/fanout points, all points at the smallest depth will be reported and
the higher depths will be suppressed.
So for example consider signals A,B,C reconverge at flop flop1 at depth 1, and flop1 feeds flop2 at depth2. If the
variable ri_smallest_depth_recon_report is set to false, any one flop1 or flop2 can be reported as reconvergent point.
When the variable ri_smallest_depth_recon_report is set to true flop1 will be reported as reconvergent point as it is at
the smallest depth.
Value
EXAMPLES
set ri_smallest_depth_recon_report true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_split_sync_across_hier
By default, different synchronizer stages can be split in different modules. When setting this variable to false, all
synchronizer stages must be in the same module.
Value
EXAMPLES
set ri_split_sync_across_hier false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_strict_rs_detection
When this variable to true, Meridian CDC checks that the synchronizer is being used to reset other flops asynchronously.
If so, Meridian CDC reports RST_SYNC; if not, Meridian CDC reports W_ASYNC_RST_FLOPS. When this variable is set to
false, Meridian CDC reports RST_SYNC even when the synchronizer is not used to reset other flops asynchronously.
Value
EXAMPLES
prompt> set ri_strict_rs_detection true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_strict_synchronizer_detection
This variable is used to turn off strict multiple flop synchronizer detection. By default, when Meridian CDC runs structural
analysis, it will not allow logic being driven from the receive domain to be present between or before the flops of
synchronizers. This switch allows the user to override that definition and allow this logic to be present. However, any
form of buffered logic between the multiple synchronizers will still be allowed.
For designs with pulse synchronization scheme, users need to set variable ri_strict_synchronizer_detection to false for
Meridian CDC to correctly identify pulse synchronizers.
Value
EXAMPLES
set ri_strict_synchronizer_detection false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_trace_w_fanout_paths
This variable, when set to true, enables Meridian CDC to write out the path file for W_FANOUT called “fanoutpaths” in
the invocation directory.
Value
EXAMPLES
set ri_trace_w_fanout_paths true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_unique_recon_points_at_all_depths
This variable, when set to true, enables Meridian CDC to report unique recon points at each depth with a sample recon
flop. (Note: ri_report_all_w_recon_points overrides this option.)
Value
EXAMPLES
set ri_unique_recon_points_at_all_depths true
RELATED COMMANDS
None
RELATED VARIABLES

ri_user_defined_cells_file
This variable specifies the file name containing used-defined crossing cells to be annotated in the Meridian CDC report.
Providing user specified cell list in the file will add a new column to CNTL and W_CNTL reporting to indicate if the user
specified cell is used as a synchronizer at the receiving end of the asynchronous crossing. If not, the column will be left
empty, indicating that the asynchronous crossing is not synchronized by user specified synchronous scheme.
Value
Value Type : string
Valid Values : valid file name
Default Value :
EXAMPLES
set ri_user_defined_cells_file “my_crossing_cells.txt”
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_user_module_data
Specify the list of library cell modules for 'User-Module' association classification.
Value
Value Type : list
Valid Values : library cell module names
Default Value : {}
EXAMPLES
set ri_user_module_data {libcell1 libcell2}
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_warn_all_multi_driver_crossings
When set to true, Meridian CDC will report additional glitch situations for both control and data crossings when there
is any combinational logic between the transmitting flops and the receiving flops. For control crossings, the additional
glitchy situations will be reported in the W_GLITCH category.
Value
EXAMPLES
set ri_warn_all_multi_driver_crossings true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_warn_potential_syncs
By default, Meridian CDC will mark all DATAs that can act as synchronizers as “W_DATA” and appends a label “Potential-
Sync” in the association column in the Meridian CDC report. Users should review this list and reclass these signals
depending on whether these signals should be CNTL or DATA. Once the reclass is done, Meridian CDC will remove them
from W_DATA section.
Value
EXAMPLES
set ri_warn_potential_syncs false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_write_scripts_multi_clock_method
The write_scripts command uses one of the method specified by this variable for writing multi-clock constraints on
the port of a sub-block. The default is to pick one clock and issue a warning that other clocks are present. Method
combine_clocks creates new waveforms, each being the concatenation of multiple waveforms at some design object.
Method skip_clocks writes out the new waveforms, but comments out each command.
Value
Value Type : string
Valid Values : pick_one_clock, skip_clocks,
combine_clocks
Default Value : pick_one_clock
EXAMPLES
Example-1: Write out new waveforms, but comment out each command
prompt> set ri_write_scripts_multi_clock_method skip_clocks
Example-2: Create new waveforms, each being the concatenation of multiple waveforms
prompt> set ri_write_scripts_multi_clock_method combine_clocks
RELATED COMMANDS
write_scripts
RELATED VARIABLES
None

ri_write_scripts_skip_module_insts_limit
During write_scripts, Meridian CDC tries to determine whether a particular module is a library cell based on the
number of instantiations of the module. If it is more than the default 5 instantiations (hence likely to be a library cell),
write_scripts will not write out environment and control script for that module. Setting this variable to a different
value can overwrite this default behavior.
Value
Valid Values : valid integer
Default Value : 5
EXAMPLES
prompt> set ri_write_scripts_skip_module_insts_limit 10
RELATED COMMANDS
None
RELATED VARIABLES
None

formal_configuration
This section describe all the variables that are available in Meridian CDC to configure formal checking functionality.

ri_assume_timing_constraints_on_cntls
While doing formal analysis, assume that for CNTL crossings, the max delay is smaller than the clock period of the
receive clock and the min delay is greater than the sum of the worst case transmit and receive clock jitters. This
assumption is true by default and limits meta-stability injection on CNTL signals. To enable metastability injection at
all times during the formal analysis, set it to false.
Value
Category formal_configuration
EXAMPLES
Example-1 : Enabling meta-stability injection to ocur all the times during formal analysis
prompt> set ri_assume_timing_constraints_on_cntls false
RELATED COMMANDS
RELATED VARIABLES
None

ri_auto_break_all_loops_for_formal
This variable when set to true will automatically break the inverting loops in the design and continue with the formal
analysis. The loops are broken by adding constant values on the appropriate signals in the identified loops. Note that
this may cause an undesired result because new constants are being forced onto the design, which will change the
functionality.
Value
EXAMPLES
Example-1 : Enabling the automatic breaking of inverting loops in the design
prompt> set ri_auto_break_all_loops_for_formal true
RELATED COMMANDS
RELATED VARIABLES
None

ri_cdc_metastability_model_for_data_path
Specify the metastability model for checking stability of signals along CDC data paths.
Value
Value Type : string
Valid Values : composite | transition-only
Default Value : composite
EXAMPLES
• Example-1 : Specify the transition-only metastability model.
prompt> set ri_cdc_metastability_model_for_data_path transition-only
RELATED COMMANDS
RELATED VARIABLES

ri_check_assumption_only_at_failure_point
When set to true, formal analysis checks whether the assumptions specified are satisfied at the point where the check
fails only. When set to false (the default), formal analysis checks whether the assumptions specified are satisfied at all
times.
Value
EXAMPLES
• Example-1 : Check whether assumptions specified are satisfied at the point where the check fails only.
prompt> set ri_check_assumption_only_at_failure_point true
RELATED COMMANDS
RELATED VARIABLES

ri_constrain_mcp_checking_to_tx_clk
When set to true, the formal check is sensitive to the TX clock rather than to the RX clock. This is similar to the -start
option in set_multicycle_path command.
Value
EXAMPLES
• Example-1 : Make the formal check sensitive to the TX clock.
prompt> set ri_constrain_mcp_checking_to_tx_clk true
RELATED COMMANDS
set_multicycle_path
RELATED VARIABLES

ri_data_stable_checks
Specify the custom list of receiving flops that need to be formally checked for data-stability.
Value
Value Type : list
Valid Values : flop names in design
Default Value : {}
EXAMPLES
set ri_data_stable_checks {flop1 flop2}
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_exclude_driver_list
Specify the custom list of transmit signals to be excluded from formal analysis.
Value
Value Type : string
Valid Values : valid transmit signal names
Default Value : none
EXAMPLES
• Example-1 : Specify list of transmit signals to be excluded from formal analysis. For example to exclude
drivers ff1.q and ff2.q from formal analysis specify following
prompt> set ri_exclude_driver_list {ff1.q ff2.q}
RELATED COMMANDS
RELATED VARIABLES

ri_flop_depth_for_cntl
This variable sets the number of flops to be included during control checking.
Value
Valid Values : integer
Default Value : (unlimited)
EXAMPLES
set ri_flop_depth_for_cntl 3
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_flop_depth_for_cntl_glitch
This variable sets the number of flops to be included during control glitch checking.
Value
EXAMPLES
set ri_flop_depth_for_cntl_glitch 3
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_flop_depth_for_data
This variable sets the number of flops to be included during data checking.
Value
EXAMPLES
set ri_flop_depth_for_data 3
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_flop_depth_for_gray_code
This variable sets the number of flops to be included during recon checking.
Value
EXAMPLES
set ri_flop_depth_for_gray_code 3
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_formal_mode
Specify sequential or parallel mode for running formal analysis. The default is parallel: Meridian CDC checks to see
whether there are multiple cores available on the machine. If not, Meridian CDC reverts to sequential mode.
Value
Value Type : string
Valid Values : parallel | sequential
Default Value : parallel
EXAMPLES
• Example-1 : Specify sequential mode for running formal analysis
prompt> set ri_formal_mode sequential
RELATED COMMANDS
RELATED VARIABLES

ri_generate_vcd_for_bounded_and_pass
This variable controls whether or not a trace VCD file is generated for bounded and pass formal checks. This enables
the user to verify the bounded results as well as see the behavior of the design to ease the debug.
Value
This variable applies only when vacuity checks are enabled. For enabling vacuity checks set ri_md_formal_flow to any
of
throughput-vacuity, hard-pass-vacuity or hard-fail-vacuity. This variable only generates traces for Data Stability, Glitch
checks and Pulse width checks. Traces are not generated for GRAY Code checks even when variable is set to true.
EXAMPLES
• Example-1 : Enable VCD generation for bounded and pass formal checks.
prompt> set ri_generate_vcd_for_bounded_and_pass true
RELATED COMMANDS
RELATED VARIABLES
None

ri_identify_strict_data_control_condition
This variable controls the strict data control condition. When strict data control condition is on, Meridian CDC
checks that the blocking condition is only dependent upon synchronizers and not on any other Rx domain flops/
inputs. When strict data control condition is off, Meridian CDC accepts the blocking condition if it is dependent upon
some synchronizer flops.
Value
EXAMPLES
• Example-1 : Enable strict data control condition.
prompt> set ri_identify_strict_data_control_condition true
RELATED COMMANDS
RELATED VARIABLES
None

ri_ignore_all_primary_input_drivers
By default, Meridian CDC removes all primary inputs and adds only transmit flops for formal analysis. Set this variable
to false to include all primary inputs.
Value
Category physical_cdc_configuration
EXAMPLES
• Example-1 : Include all paths from drivers that are primary inputs for formal analysis
prompt> set ri_ignore_all_primary_input_drivers false
RELATED COMMANDS
RELATED VARIABLES

ri_ignore_fast_to_slow_gray_code_checks
By default, Meridian CDC performs Gray code checks from fast to slow and slow to fast clock domain. Setting this
variable to true will disable Gray coding check on reconverging signals going from fast to slow clock domain.
Value
EXAMPLES
• Example-1 : Disabling fast-to-slow clock Gray code checks in formal analysis
prompt> set ri_ignore_fast_to_slow_gray_code_checks true
RELATED COMMANDS
RELATED VARIABLES
None

ri_include_driver_list
Specify the custom list of transmit signals to be included for formal analysis.
Value
Value Type : string
Valid Values : valid transmit signal names
Default Value : none
EXAMPLES
• Example-1 : Specify list of transmit signals for formal analysis. For example to include drivers ff1.q and ff2.q
in formal analysis specify following
prompt> set ri_include_driver_list {ff1.q ff2.q}
RELATED COMMANDS
RELATED VARIABLES

ri_max_ratio_after_auto_normalization
This variable specifies the maximum ratio of the max to min clock periods after normalization. Increasing this number
may adversely affect runtimes of formal analysis.
Value
Default Value : 16
EXAMPLES
• Example-1 : Changing the max ratio to be
prompt> set ri_max_ratio_after_auto_normalization 10
RELATED COMMANDS
RELATED VARIABLES
None

ri_max_time_slices
This variable specifies the maximum number of time slices allowed for formal analysis, where each time-slice
represents a unique combination of clock phases. Increasing the number can have adverse affect on runtime or memory
usage.
Value
Valid Values : positive integer < INT_MAX(2147483647)
Default Value : 10000
EXAMPLES
• Example-1 : Reduce the time slices allowed for formal analysis
prompt> set ri_max_time_slices 100
RELATED COMMANDS
RELATED VARIABLES
ri_use_free_running_clocks
ri_xing_mcp_cycles

ri_md_formal_flow
This variable specifies the effort level for formal verification checks. This variable, together with verify_cdc_formal
-time_limit and -time_limit_per_check command arguments, can be used to control overall runtime for formal
verification.
Value
Value Type : string
Valid Values : throughput | hard-pass | hard-fail | find-constraints
| throughput-vacuity | hard-pass-vacuity | hard-fail-
vacuity | medium-parallel | debug
throughput indicates a first-level quick check, where
the number of clock cycles for finding failure in
throughput is limited to 50 clock cycles of the fastest
clock
hard-pass indicates an active hunt for passes
hard-fail spends more effort finding failures
find-constraints identifies whether there are (SVA/
PSL) constraints in the design that impact checks
throughput-vacuity runs vacuity checks in
throughput mode
hard-pass-vacuity runs vacuity checks in hard-pass
mode
hard-fail-vacuity runs vacuity checks in hard-fail
mode
medium-parallel runs similarly to hard-parallel
mode, using less memory and time resources for the
checks
debug runs the QBF-based algorithm on the data
glitch and clock glitch checks; used as a pipe-clean
mode to identify whether there are any setup issues
in the design; flop depth level in this mode
is 0
Default Value : throughput
EXAMPLES
• Example-1 : Below is an example of directing formal analysis to perform an active hunt for passes
prompt> set ri_md_formal_flow hard-pass
RELATED COMMANDS
verify_cdc_formal
RELATED VARIABLES


ri_normalize_clk_periods
This variable enable normalization of clock periods of all the master waveforms. Meridian CDC be default normalize the
clock period, this variable provide user overrides over the default behavior.
Value
EXAMPLES
• Example-1 : Disable the clock
prompt> set ri_normalize_clk_periods false
RELATED COMMANDS
RELATED VARIABLES
ri_normalize_to_uniform_clk_periods
ri_xing_mcp_cycles

ri_normalize_to_uniform_clk_periods
This variable instructs the Meridian CDC to make the clock periods and transitions of all master waveforms in the
environment to be the same as that of the fastest clock.
Value
EXAMPLES
• Example-1 : Enable clock uniformity during the clock normalization
prompt> set ri_normalize_to_uniform_clk_periods true
RELATED COMMANDS
RELATED VARIABLES
ri_normalize_clk_periods
ri_xing_mcp_cycles

ri_process_all_pulse_width_checks
This variable specifies the tool to run all pulse width checks. It overrides the cases when pulse width checks are
skipped due to Fast-to-Slow-Gray-Codes, Flop-Input-Unknown-Domain, and Flop-Input-Sync-Domain.
Value
EXAMPLES
• Example-1 : Enable all the puls width checks on all the CNTL crossings.
prompt> set ri_process_all_pulse_width_checks true
RELATED COMMANDS
RELATED VARIABLES
ri_verify_pulse_widths
ri_verify_sync_pulse_widths

ri_pulse_width_checks
Specifies the names of the signals for formal pulse width checks between asynchronous clock domains.
Value
Value Type : list
Valid Values : signal names in design
Default Value : {}
EXAMPLES
set ri_pulse_width_checks {sig1 sig2}
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_run_vacuity_check_with_formal
This variable specifies whether Meridian CDC performs vacuity checking in the same run as formal checking of regular
CDC checks.
Value
EXAMPLES
• Example-1 : Specify vacuity checking to be done in the same run as formal checking
prompt> set ri_run_vacuity_check_with_formal true
RELATED COMMANDS
RELATED VARIABLES

This variable enables formal analysis in free running clock mode. When this variable is set to true, all the clocks
(including the clocks created off derived waveforms) become free running with no frequency or phase correlation.
Each clock will retain its periodic behavior until the first reset/initial value specified with respect to its waveform is
released. After that it will become free running. For example:
create_clock -waveform SYS_CLK { clk1 }

create_reset -interval 10 -waveform SYS_CLK {rst1}
set_value_during_reset -interval 6 -waveform SYS_CLK {input1}
The clock “clk1” will be treated as periodic until the interval of 6 (minimum of the two specifications). When there
is no reset/initial spec with respect to the clock waveform, then the global earliest reset release specified in the
environment is used. If there is no reset/initial value specified in the environment file, then the clocks are treated as
free running from the beginning of analysis.
Value
EXAMPLES
• Example-1 : Turning on free running clock mode for formal analysis
prompt> set ri_use_free_running_clocks true
RELATED COMMANDS
RELATED VARIABLES
None

ri_verify_cntl_glitch
This variable controls the formal analysis of glitch checks which verify that logic generating control signals is not prone
to glitches.
Value
EXAMPLES
• Example-1 : Turning off formal glitch checks
prompt> set ri_verify_cntl_glitch false
RELATED COMMANDS
RELATED VARIABLES
None

This variable controls the formal analysis of glitch checks which verify that stability of data transfer across
asynchronous crossings are prone to meta-stability.
Value
EXAMPLES
• Example-1 : Turning on formal data stability checks
prompt> set ri_verify_data_stability true
RELATED COMMANDS
RELATED VARIABLES
None

This variable controls the formal analysis of Gray code checks which verify that sets of signals for Gray encoding. By
default, only FIFO based reconverging CNTLs are considered for Gray encoding. To add all reconvergence CNTLs to Gray
encoding checks, use the variable ri_verify_gray_codes_on_all_recon.
Value
EXAMPLES
• Example-1 : Turning off formal Gray code checks
prompt> set ri_verify_gray_codes false
RELATED COMMANDS
RELATED VARIABLES

The variables allows user to add all W_RECON_GROUP for Gray encoding checks. By default, only FIFO based
reconverging CNTLs are considered for Gray encoding.
Value
EXAMPLES
• Example-1 : Turning on formal Gray code checks of items reported in W_RECON_GROUP category
prompt> set ri_verify_gray_codes_on_all_recon true
RELATED COMMANDS
RELATED VARIABLES

ri_verify_gray_codes_on_rx_flops
This variable controls if the Gray encoding checks to be done on inputs of the CNTL RxFlops or outputs. The default is
false, and a Gray encoding check is performed on the inputs of the CNTL RxFlops. Setting this variable to true to move
Gray encoding checks to the outputs.
Value
EXAMPLES
• Example-1 : Below change the Gray encoding checks to be done on outputs of the CNTL RxFlops
prompt> set ri_verify_gray_codes_on_rx_flops true
RELATED COMMANDS
RELATED VARIABLES

ri_verify_one_clock_glitch_bit_per_bus
By default, formal analysis runs on only one of the representative bits of each clock glitch, skipping the remaining bits.
This variable controls whether all bits of a vector should be verified formally, and takes precedence over the default
run, reading from the RIDB, and reading from formal_checks.conf file.
Value
EXAMPLES
• Example-1 : Enable formal analysis on all bits of a vector (an array or a bus).
prompt> set ri_verify_one_clock_glitch_per_bus false
RELATED COMMANDS
None
RELATED VARIABLES

By default, formal analysis runs on only one of the representative bits of each control bus, skipping the remaining bits.
Value
EXAMPLES
• Example-1 : Enabling formal analysis on all the bits of a vector (an array or a bus)
prompt> set ri_verify_one_cntl_bit_per_bus false
RELATED COMMANDS
RELATED VARIABLES
ri_verify_sync_pulse_width

By default, formal analysis runs on only one of the representative bits of each data bus, skipping the remaining bits.
Value
EXAMPLES
• Example-1 : Enabling formal analysis on all the bits of a vector (an array or a bus).
prompt> set ri_verify_one_data_bit_per_bus false
RELATED COMMANDS
RELATED VARIABLES

This variable enables formally analysis of pulse width checks and verify if a control signal is asserted long enough for
reliable data transfer.
Value
EXAMPLES
• Example-1 : Turning of pulse width checks in formal analysis
prompt> set ri_verify_pulse_widths false
RELATED COMMANDS
RELATED VARIABLES
ri_process_all_pulse_width_checks

This
variable
enables
formally
analysis
of
pulse
width
checks
and
verify
if
a
control
signal
that
crosses
synchronous
clock
domain
is
asserted
long
enough
to
be
able
to
capture
by
receiving
clock.
Value
Value boolean
Type :
Valid true
Values : |
false
Default false
Value :
Category
formal_configuration
EXAMPLES
• Example-1 :

prompt>
set
true
RELATED
COMMANDS
RELATED
VARIABLES

ri_xing_mcp_cycles
This variable controls how many clock cycles to be checked for data transfer across asynchronous domains. Setting a
value of 1 has a special meaning. It causes the tool to not fail a data-stability check when TxClk and RxClk edges align
at TX transition time (typically being the same clock period). So, when ri_xing_mcp_cycles is 2 (default), the check
fails, when set to 1, it will pass (only for the aligned case).
Value
Default Value : 1
EXAMPLES
• Example-1 : Increasing the number of clock cycles to 4 for data should be stable for data stability checks
prompt> set ri_xing_mcp_cycles 4
RELATED COMMANDS
RELATED VARIABLES

global_configuration
This section describe all the variables available in Meridian CDC to configure global functionality of the tool.

ri_abs_file_name
This variable can be used to force full paths to be used for all file name references in the log file. By default, absolute
path file names are used when referencing HDL design source files in compiler messages and reports. When false, the
HDL file names are reported exactly as specified in the control file with the exception of files referenced through -
F file lists, which will always show as full path. Users might use this switch when they have used relative path names
in the control file and want relative path names in the report and log files. By default, this variable forces absolute
paths.
Value
Category global_configuration
EXAMPLES
• Example-1 :
prompt> set ri_abs_file_name false
RELATED COMMANDS
analyze
elaborate
RELATED VARIABLES
ri_search_path

ri_enforce_strict_variable_settings
When setting ri_* Tcl variables, abort the run if the variable is not a Meridian CDC variable. By default, this variable is
set to true, meaning that any attempt to define a ri_* variable that Meridian CDC does not recognize is accepted with a
warning message recorded in the log file.
Value
EXAMPLES
Example-1 : Enforcing tool abort when unrecognized ri_* variable is used in the control file
prompt> set ri_enforce_strict_variable_settings true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_ignore_unused_flops_in_analysis
This variable controls whether to consider flops with no fanout for analysis. By default (when false), all flops with no
load or fanout are considered for analysis. When true, Meridian CDC does not report any issues/crossings related to
flops that are unused.
Value
EXAMPLES
Example-1 :
prompt> set ri_ignore_unused_flops_in_analysis true
RELATED COMMANDS
RELATED VARIABLES
None

ri_print_intermediate_memory_stats
When set to true, Meridian CDC writes the memory consumed by the parent and all the child processes to the log file
every 30 sec.
Value
EXAMPLES
Example-1 :
prompt> set ri_print_intermediate_memory_stats true
RELATED COMMANDS
RELATED VARIABLES
None

ri_product_build_date
This variable reports the product build date of the Meridian CDC being run. This is a read-only variable, user cannot
change the value.
Value
Value Type : string
Valid Values : <read_only>
EXAMPLES
• Example-1 : Accessing the build date for generating an output
prompt> set fid [open output.rpt w]

prompt> set ${fid} "Tool Name : $ri_product_name"
prompt> set ${fid} "Tool Version : $ri_product_version/$ri_product_rev"
prompt> set ${fid} "Build Date/Time : $ri_product_build_date/$ri_product_build_time"
prompt> close ${fid}
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_product_build_time
This
variable
reports
the
product
build
time
of
the
Meridian
CDC
being
run.
This
is
a
read-
only
variable,
user
cannot
change
the
value.
Value
Value string
Type :
Valid <read_only>
Values :
Category
global_configuration
EXAMPLES
• Example-1 :
Accessing
the
build
time
for
generating
an
output
prompt>
set
fid

[open
output.rpt
w]
prompt>
set
${fid}
"Tool
Name
:
$ri_product_name"
prompt>
set
${fid}
"Tool
Version
:
$ri_product_version/
$ri_product_rev"
prompt>
set
${fid}
"Build
Date/
Time :
$ri_product_build_date/
$ri_product_build_time"
prompt>
close
${fid}
RELATED
COMMANDS
None
RELATED
VARIABLES
None

ri_product_name
This variable reports the product name of the Meridian CDC being run. This is a read-only variable, user cannot change
the value.
Value
Value Type : string
EXAMPLES
• Example-1 : Accessing the product name to determine which message to suppress
prompt> if {[info exists ri_product_name]} then {

prompt> ? if {[string equal -nocase $ri_product_name meridiancdc]} then {
prompt> ? set ri_suppress_msg 74002
prompt> ? }
prompt> ? }
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_product_rev
This variable reports the product revision of the Meridian CDC being run. This is a read-only variable, user cannot
change the value.
Value
Value Type : string
EXAMPLES
• Example-1 : Accessing the revision for generating an output

RELATED COMMANDS
None
RELATED VARIABLES
None

ri_product_version
This variable reports the product version of the Meridian CDC being run. This is a read-only variable, user cannot
change the value.
Value
Value Type : string
EXAMPLES
• Example-1 : Accessing the version for generating an output

prompt> set ${fid} "Tool Name : $ri_product_build_date/$ri_product_build_time"
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_project_directory_name
This variable reports the project directory of the current Meridian CDC run. This is a read-only variable, user cannot
change the value.
Value
Value Type : string
EXAMPLES
Example-1 : Accessing the project directory name for generating an output

prompt> set ${fid} "Project Dir : $ri_project_directory_name/$ri_session_name"
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_remove_unused_combo_logic
Transitively remove (or retain, when set to false) any dangling combo logic in the design.
Warning: Setting this variable to false might increase the noise in the run.
Value
EXAMPLES
• Example-1 : Retain unused combo logic
prompt> set ri_remove_unused_combo_logic false
RELATED COMMANDS
None
RELATED VARIABLES
ri_remove_unused_flops
ri_remove_unused_lib_cell_flops

Transitively remove and ignore, or retain (when set to false), flops and latches that have no fanout.
Warning: When set to true, the following variables are ignored:

• ri_remove_unused_combo_logic
• ri_remove_unused_lib_cell_flops
Value
EXAMPLES
• Example-1 : Remove and ignore flops and latches that have no fanout (note: variables
ri_remove_unused_combo_logic and ri_remove_unused_lib_cell_flops are ignored)
prompt> set ri_remove_unused_flops true
RELATED COMMANDS
None
RELATED VARIABLES

Transitively remove and ignore (or retain, when set to false) flops and latches inside library cells that have no fanout.
Note: This variable does not consider Liberty modules as library cells.
Value
EXAMPLES
• Example-1 : Remove and ignore flops and latches inside library cells that have no fanout
prompt> set ri_remove_unused_lib_cell_flops true
RELATED COMMANDS
None
RELATED VARIABLES

ri_session_name
This variable reports name of the current session of the Meridian CDC. This is a read-only variable, user cannot change
the value.
Value
Value Type : string
Default Value : {}
EXAMPLES
Example-1 : Generating reports with session name annotated
prompt> report_policy MCDC_ANALYSIS_CHECKS -output $ri_session_name.my_policy.rpt
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_suppress_msg
This variable controls turning off catalog messages that occur within the Meridian CDC and supressing them from
the log. Disabling catalog messages may result in masking of important information that identify problems in the
RTL source code or the Meridian CDC setup and can increase the complexity of debugging failures in verification.
However, suppressed messages are stored in RIDB and those can later be reported by report_messages command (see
the command for detail on how to report suppressed messages).
Value
Value Type : string
Valid Values : <list of message IDs>
Default Value : {}
EXAMPLES
• Example-1 : Supressing message of WARN [#39386] : on line 18 in file test.sv : for loop does not terminate
after "1024"
prompt> set ri_suppress_msg 39386
• Example-2 : Multiple messages can be suppressed by setting list of IDs
prompt> set ri_suppress_msg [list 39386 6001]
RELATED COMMANDS
analyze
analyze_intent
elaborate
read_sdc
read_env
report_messages
RELATED VARIABLES
None

ri_use_platform_gdb
This variable provides user control over which gdb to be used for debugger when investigating software problems. When
true, use the platform gdb binary at /usr/bin/gdb for writing backtrace on a crash. When false, use the ri_gdb from
the product installation.
Value
Valid Values : <true | false>
EXAMPLES
• Example-1 : Letting system gdb to be used instead of gdb from product installation
prompt> set ri_use_platform_gdb true
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_write_zdb
This variable provides user control over whether Meridian CDC writes a zdb (for iVision).
Value
Valid Values : <true | false>
EXAMPLES
• Example-1 : Disable writing the zdb for iVision
prompt> set ri_write_zdb false
RELATED COMMANDS
None
RELATED VARIABLES
None

intent_configuration
This section describe all the variables available in Meridian CDC to configure intent configuration functionality both
reading in and writing out.

ri_append_to_orig_env
By default during environment generation, Meridian CDC will append the incrementally created ENV commands to the
provided base ENV commands. Setting this variable to false will result in a consolidated ENV file.
Value
Category intent_configuration
EXAMPLES
• Example-1 : Allow creation of a consolidated environment file
prompt> set ri_append_to_orig_env false
RELATED COMMANDS
RELATED VARIABLES
None

ri_check_henv_input_spec
Verify input specs during HENV analysis.
Value
EXAMPLES
• Example-1 : Turn off verification of input specs during HENV analysis
prompt> set ri_check_henv_input_spec false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_comment_auto_detected_sync_resets
By default, automatically detected synchronous resets are written to the environment file. This variable can be set
to true if it is not desired to not have the tool automatically detect synchronous resets. If set to true, the resets are
commented in the environment file shoudl the user choose to enable them.
Value
EXAMPLES
• Example-1 : write automatically detected synchronous resets to environment file as comments.
prompt> set ri_comment_auto_detechted_sync_resets true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
ri_disable_name_based_clock_and_reset_spec_creation

This variable is used to configure how SDC clocks are translated into an environment file. When set to true, SDC clock
commands are translated as asynchronous clocks.
Value
EXAMPLES
• Example-1 : Enable SDC clocks to be translated into asynchronous environment waveforms
prompt> set ri_convert_SDC_clocks_async
RELATED COMMANDS
RELATED VARIABLES
None

ri_create_inputs_on_black_box_outputs
By default, Meridian CDC generates create_input commands in the environment file for the outputs of the user
specified blackbox modules. The associated clock is the clock of the driven flop. Setting this variable to false disables
this behavior, which can lead to S_NET_NO_WAVE violations.
Value
EXAMPLES
• Example-1 : Disassociate outputs of blackboxed modules with any clock domain.
prompt> set ri_create_inputs_on_black_box_outputs false
RELATED COMMANDS
analyze_intent
create_input
RELATED VARIABLES
None

ri_create_inputs_on_undriven_nets
By default, Meridian CDC generates create_input commands in the environment file for each net that has no driver. Set
this variable to false to make these commands commented for user review.
Value
EXAMPLES
• Example-1 : Comment out create_input commands for nets that have no drivers.
prompt> set ri_create_inputs_on_undriven_nets false
RELATED COMMANDS
analyze_intent
create_input
RELATED VARIABLES
None

ri_create_outputs_in_create_env
When setting to true, Meridian CDC generates create_output commands in the environment file for the outputs of modules
based on the waveforms driving those outputs. The following criteria are used to generate create_output commands:
• If the output is driven by only one clock waveform, create output with respect to that waveform.
• If the output is driven by multiple synchronous waveforms, create output with respect to the primary waveform.
• If the output is driven by multiple asynchronous waveforms, create output with respect to one arbitrary
waveform.
• If the output spec is already given in user’s SDC and environment file, it will not be overwritten.
Value
EXAMPLES
• Example-1 : Enable generation of create_output commands during environment file generation
prompt> set ri_create_outputs_in_create_env true
RELATED COMMANDS
analyze_intent
create_output
RELATED VARIABLES

ri_create_outputs_on_black_box_inputs
This variable takes effect only when ri_create_outputs_in_create_env is true. When this variable is set to true,
Meridian CDC writes create_output commands for inputs to black boxes in the automatically generated environment
file.
Value
EXAMPLES
• Example-1 : Enable writing of create_output commands on black box inputs.
prompt> set ri_create_inputs_on_black_box_inputs true
RELATED COMMANDS
analyze_intent
create_output
RELATED VARIABLES
ri_create_outputs_in_create_env

ri_disable_name_based_clock_and_reset_spec_creation
This variable is used to configure how clock and reset specs are generated. If set to true, signal names are not used as
hints for possible spec generation candidates. Setting this variable may lead to S_NORST and S_NOCLK violations.
Value
EXAMPLES
• Example-1 : Disable the name matching rule for clock and reset spec generation
prompt> set ri_disable_name_based_clock_and_reset_spec_creation true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
ri_comment_auto_detected_sync_resets

ri_echo_sdc_commands
This variable, when set to true, enables Meridian CDC to echo SDC commands that are being converted to Meridian CDC
environment commands in the log file.
Value
EXAMPLES
• Example-1 : Disable the echo of SDC commands to log file
prompt> set ri_echo_sdc_commands false
RELATED COMMANDS
RELATED VARIABLES

ri_enhance_clock_domain_analysis_in_conf_env
Meridian CDC does not flag S_CONF_ENV for internal reset and input specs when the clock domain on the spec is
asynchronous to all receiving clock domains for the spec.
Value
EXAMPLES
• Example-1 : Flag S_CONF_ENV for internal reset and input specs when the clock domain on the spec is
asynchronous to all receiving clock domains for the spec
prompt> set ri_enhance_clock_domain_analysis_in_conf_env false
RELATED COMMANDS
None
RELATED VARIABLES
None

The variable affects whether the tool will error or simply issue a warning when a signal argument of an ENV command
is not found. By default, the tool will issue a warning. When set to “true”, the tool will error out after processing all
ENV file commands.
Value
EXAMPLES
• Example-1 : Configure Meridian CDC to error out when a signal argument of an ENV command is not found
prompt> set ri_env_error_on_signal_not_found true
RELATED COMMANDS
RELATED VARIABLES
None

ri_env_priority_order
This variable specifies the priority order while processing environment file commands. By default, a built-in priority
order "priority_single" is followed which says create_clock specs have the highest priority, then create_reset,
create_constant, set_stable_value, and the lowest priority is create_input. The ENV command create_output is an
unprioritized specification that does not conflict with other specifications (see ENV Commands for details). If set to
"last_one_wins", the last spec on a signal overrides any previous specs on that signal.
Value
Value Type : string
Valid Values : priority_single | last_one_wins
Default Value : priority_single
EXAMPLES
• Example-1 : Allow the last environment spec read on signal to override any previous specs.
prompt> set ri_env_priority_order last_one_wins
RELATED COMMANDS
RELATED VARIABLES
None

ri_exclude_all_reset_analysis
This variable configures how Meridian CDC performs reset identification and completeness analysis. Setting this to true
may reduce S_NORST violations. If set to true:
• all reset specs are suppressed
• reset candidates that come from blackbox outputs have a create_input spec with a virtual clock waveform
• reset candidates that come from primary inputs will have a create_input spec with a virtual clock waveform
• all reset violations during analyze_intent will be suppressed.
Value
EXAMPLES
• Example-1 : Disable reset identification and completeness analysis
prompt> set ri_exclude_all_reset_analysis true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

This variable configures how Meridian CDC performs reset identification and completeness analysis on internal nets.
If set to false, internally generated resets are included in reset identification and completeness analysis and are
designated as functional resets. When true, these functional resets are commented.
Value
Default Value : true, RDC default is false
EXAMPLES
• Example-1 : Include internally generated resets in reset identification and completeness analysis.
prompt> set ri_exclude_internal_reset_analysis false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

ri_extract_genclks_filename
If generated clocks are extracted from Liberty models, this variable configures the filename where the related SDC
commands are written (only as a reference to see extracted information).
Value
Value Type : string
Valid Values : <string>
Default Value : "meridian_project/liberty/read_lib.sdc"
EXAMPLES
• Example-1 : Write generated clock SDC commands to "my.sdc"
prompt> set ri_extract_genclks_filename "my.sdc"
RELATED COMMANDS
read_sdc
read_liberty
RELATED VARIABLES
ri_extract_genclks_from_liberty

ri_extract_genclks_from_liberty
This variable configures how generated clocks are extracted from Liberty models. If set to false, generated clocks are
not extracted from Liberty library cells.
Value
EXAMPLES
• Example-1 : Disable the extraction of generated clocks from Liberty models.
prompt> set ri_extract_genclks_from_liberty false
RELATED COMMANDS
read_sdc
read_liberty
RELATED VARIABLES
ri_extract_genclks_filename

ri_ignore_unused_virtual_clocks
Ignore any virtual clock, vclk, in the CLK_GROUPS category, if there is no set_input_delay or set_output comand with -
clock vclk specified in SDC file.
Value
EXAMPLES
set ri_ignore_unused_virtual_clocks false
RELATED COMMANDS
None
RELATED VARIABLES
None

ri_infer_s_no_reset_from_reset_syncs
Specify whether S_NORST detection will traverse through complex reset synchronizers to identify S_NORST sources.
Value
EXAMPLES
prompt> set ri_infer_s_no_reset_from_reset_syncs false
RELATED COMMANDS
None
RELATED VARIABLES
None

This variable limits the number of collection items returned by object access commands that are printed to logfile.
If the limit is exceeded by a particular object access command, this is indicated in the logfile as "... output truncated
(total objects %d)" where %d is the collection size.
Value
Valid Values : <integer>
Default Value : 100
EXAMPLES
• Example-1 : Allow collections up to 100 items to be printed to the logfile.
prompt> set ri_oac_result_display_limit 100
RELATED COMMANDS
read_sdc
RELATED VARIABLES
None

ri_oac_strict_type_checking
When set to true, if an object list argument to an object access command is a collection of a different type than the
command itself, the argument will be ignored. Otherwise, for each object in the collection argument, if an object with
the same name and the correct type exists, it will be added to the result collection.
Value
EXAMPLES
• Example-1 :
prompt> set ri_oac_strict_type_checking false
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

ri_override_input_spec_for_reset_or_mode_identification
This variable prompt> to over user specified create_input specs to be override by create_reset or set_constants if
those drivers are identified as candidates for resets and modes.
Value
EXAMPLES
• Example-1 : Override create_input specs during reset and mode control signal identification.
prompt> set ri_override_input_spec_for_reset_or_mode_identification true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

ri_report_black_box
This variable enables Meridian CDC to report all blackbox modules in the BLACK_BOX report. By default, black boxes
are reported via BLACK_BOX.
Value
EXAMPLES
• Example-1 : Disable reporting of BLACK_BOX.
prompt> set ri_report_black_box false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_i_clk_trees
This variable enables reporting of clock trees in the I_CLK_TREES report. By default, clock trees are included in the
report.
Note: Meridian Physical CDC does not support this variable.
Value
EXAMPLES
• Example-1 : Disable reporting of clock trees via _I_CLK_TREES.
prompt> set ri_report_i_clk_trees false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_i_clk_tree_alias_names
This variable enables reporting of all clock pin alias names in the I_CLK_TREES report. By default, alias names are not
included in the report.
Note: Meridian Physical CDC does not support this variable.
Value
EXAMPLES
• Example-1 : Enable all the aliases to be reported in the I_CLK_TREE.
prompt> set ri_report_i_clk_tree_alias_names true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_i_henv_db_map
Report I_HENV_DB_MAP category.
Value
EXAMPLES
• Example-1 : Disable reporting of I_HENV_DB_MAP
prompt> set ri_report_i_henv_db_map false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_i_reset_signal
This variable enables Meridian CDC to report all identified reset signals in the I_RESET_SIGNAL report. By default,
identified resets are included in the report.
Value
EXAMPLES
• Example-1 : Disable the reporting of all the identified resets via I_RESET_SIGNAL.
prompt> set ri_report_i_reset_signal false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_internal_s_norst
This variable enables Meridian CDC to report relevant S_NORST rule violations on internal reset signals (typically flops
or complex combo logic wires), irrespective of the setting of the ri_exclude_internal_reset_analysis variable.
Value
EXAMPLES
• Example-1 : Enable the reporting of relevant S_NORST violations.
prompt> set ri_report_internal_s_norst true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

ri_report_s_clk_gate_no_wave
This variable configures the reporting of S_CLK_GATE_NO_WAVE. If set to false, S_CLK_GATE_NO_WAVE is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_CLK_GATE_NO_WAVE
prompt> set ri_report_s_clk_gate_no_wave false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_clk_off_sub_tree
This variable configures the reporting of S_CLK_OFF_SUB_TREE. If set to false, S_CLK_OFF_SUB_TREE is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_CLK_OFF_SUB_TREE
prompt> set ri_report_s_clk_off_sub_tree false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_conf_env
This variable configures the reporting of S_CONF_ENV. If set to false, S_CONF_ENV is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_CONF_ENV
prompt> set ri_report_s_conf_env false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_genclk
This variable configures the reporting of S_GENCLK. If set to false, S_GENCLK is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_GENCLK
prompt> set ri_report_s_genclk false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_henv_extra_spec
Report S_HENV_EXTRA_SPEC category.
Value
EXAMPLES
• Example-1 : Disable reporting of S_HENV_EXTRA_SPEC
prompt> set ri_report_s_henv_extra_spec false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_input_no_wave
This variable configures the reporting of S_INPUT_NO_WAVE. If set to false, S_INPUT_NO_WAVE is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_INPUT_NO_WAVE
prompt> set ri_report_s_input_no_wave false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_multclk
This variable configures the reporting of S_MULTCLK. If set to false, S_MULTCLK is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_MULTCLK
prompt> set ri_report_s_multclk false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_multclk_max_count
This variable configures the maximum number of S_MULTCLK violations to report for a given run.
Value
EXAMPLES
• Example-1 : Report a maximum of 2000 S_MULTCLK violations
prompt> set ri_report_s_multclk_max_count 2000
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_multclk_verbose
This variable configures the verbose reporting of S_MULTCLK. If set to true, more off-path information is reported on
S_MULTCLK checks.
Value
EXAMPLES
• Example-1 : Enable the verbose reporting of S_MULTCLK
prompt> set ri_report_s_multclk_verbose true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
ri_report_s_multclk

ri_report_s_net_no_wave
This variable configures the reporting of S_NET_NO_WAVE. If set to false, S_NET_NO_WAVE is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_NET_NO_WAVE
prompt> set ri_report_s_net_no_wave false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_noclk
This variable configures the reporting of S_NOCLK. If set to false, S_NOCLK is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_NOCLK
prompt> set ri_report_s_noclk false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_norst
This variable configures the reporting of S_NORST. If set to false, S_NORST is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_NORST
prompt> set ri_report_s_norst false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_num_analysis_time_slices
This variable configures the reporting of S_NUM_ANALYSIS_TIME_SLICES when analyze_intent is run with the -formal
option.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_NUM_ANALYSIS_TIME_SLICES
prompt> set ri_report_s_num_analysis_time_slices false
RELATED COMMANDS
analyze_intent -formal
RELATED VARIABLES
None

ri_report_s_output_no_wave
Report S_OUTUPT_NO_WAVE category.
Value
EXAMPLES
• Example-1 : Enable reporting of S_OUTPUT_NO_WAVE
prompt> set ri_report_s_output_no_wave true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_rst_inv
This variable configures the reporting of S_RST_INV If set to false, S_RST_INV is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_RST_INV
prompt> set ri_report_s_rst_inv false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

This variable configures the verbose reporting of S_RST_INV. If set to true, verbose information about S_RST_INV
checks is reported.
Value
EXAMPLES
• Example-1 : Enable the verbose reporting of S_RST_INV
prompt> set ri_report_s_rst_inv_verbose true
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

ri_report_s_unknown_clkpol
This variable configures the reporting of S_UNKNOWN_CLKPOL. If set to false, S_UNKNOWN_CLKPOL is not reported.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_UNKNOWN_CLKPOL
prompt> set ri_report_s_unknown_clkpol false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_s_unknown_clkpol_max_count
This variable configures the maximum number of S_UNKNOWN_CLKPOL violations to report for a given run.
Value
EXAMPLES
• Example-1 : Report a maximum of 2000 S_UNKNOWN_CLKPOL violations
prompt> set ri_report_s_unknown_clkpol_max_count 2000
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_setup_dbg_files
This variable configures the reporting of enhanced debug information. If set to false, enhanced debug report files for
setup checks (S_*) are not generated.
Value
EXAMPLES
• Example-1 : Disable the generation of enhanced report files for setup checks.
prompt> set ri_report_setup_dbg_files false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_report_static_loops
This variable configures the reporting of S_COMBO_LOOPS when analyze_intent is run with the -formal option.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_COMBO_LOOPS
prompt> set ri_report_static_loops false
RELATED COMMANDS
RELATED VARIABLES
None

ri_report_uninitialized_flops_latches
This variable configures the reporting of S_UNINIT_FLOPS_LATCHES when analyze_intent is run with the -formal option.
Value
EXAMPLES
• Example-1 : Disable the reporting of S_UNINIT_FLOPS_LATCHES
prompt> set ri_report_uninitialized_flops_latches false
RELATED COMMANDS
RELATED VARIABLES
None

ri_sdc_echo_limit
This variable sets a soft limit on the number of characters to print when echoing an SDC command. Once the limit is
reached, an ellipsis is printed in lieu of any remaining arguments.
Value
Valid Values : integers greater than 0
Default Value : 256
EXAMPLES
• Example-1 : Set character limit for SDC command echo to 512
prompt> set ri_sdc_echo_limit 512
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_sdc_error_on_cmd_failure
This variable determines whether the read_sdc command will issue an error if there are any errors in SDC commands
passed to the read_sdc command.
Value
EXAMPLES
• Example-1 : Issue an error if there are any errors in SDC commands passed to the read_sdc command
prompt> set ri_sdc_error_on_cmd_failure true
RELATED COMMANDS
analyze_intent
read_sdc
RELATED VARIABLES
None

ri_sdc_report_ignored_commands
This
variable
determines
whether
to
include
tool-
specific
ignored
SDC
commands
in
SDC
reports.
Value
Value boolean
Type :
Valid true
Values : |
false
Default false
Value :
Category
EXAMPLES
• Example-1 :
Include
tool-
specific
ignored
SDC
commands
in
SDC
reports
prompt>
set
ri_sdc_report_ignored_commands
true
RELATED
COMMANDS

analyze_intent
RELATED
VARIABLES
None

ri_sdc_uniquify_warning_numbers
This variable configures the generation of warning numbers for SDC syntax messages. If set to false, SDC syntax
messages are grouped into a smaller set of warning numbers.
Value
EXAMPLES
• Example-1 : Disable the uniquifying of SDC syntax messages
prompt> set ri_sdc_uniquify_warning_numbers false
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

ri_sdc2env_exact_translation
When
converting
SDC
to
ENV
during
read_sdc
-
output_env
and
analyze_intent
-
output_env,
Meridian
CDC
tries
to
try
to
preserve
the
exact
periods
used
in
create_clock
SDC
commands
when
creating
the
corresponding
commands
in
the
ENV.
Set
this
variable
to
false
to
disable
this
behavior.
See
-
output_env
for
more
information.

Value
Value boolean
Type :
Valid true
Values : |
false
Default true
Value :
Category
EXAMPLES
• Example-1 :
When
converting
SDC
to
ENV,
disable
exact
translation
prompt>
set
ri_sdc2env_exact_translation
false
RELATED
COMMANDS
None
RELATED
VARIABLES
ri_sdc2env_ignore_set_clock_groups
ri_sdc2env_ignore_set_false_paths
ri_sdc2env_make_all_clocks_async

When converting SDC to ENV, ignore set_clock_groups commands.
Value
EXAMPLES
• Example-1 : When converting SDC to ENV, ignore set_clock_groups commands
prompt> set ri_sdc2env_ignore_set_clock_groups true
RELATED COMMANDS
None
RELATED VARIABLES

When converting SDC to ENV, ignore set_false_path commands.
Value
EXAMPLES
• Example-1 : When converting SDC to ENV, ignore set_false_path commands
prompt> set ri_sdc2env_ignore_set_false_paths true
RELATED COMMANDS
None
RELATED VARIABLES

When converting SDC to ENV, make all clocks asynchronous.
Value
EXAMPLES
• Example-1 : When converting SDC to ENV, make all clocks asynchronous
prompt> set ri_sdc2env_make_all_clocks_async true
RELATED COMMANDS
None
RELATED VARIABLES

Sets the naming style for referring to array elements. This must be a string that matches the pattern "%s.*%d.*" where
%s refers to the array name and %d refers to the array index. Any of the .* elements can be empty.
Value
Value Type : string
Valid Values : %s.*%d.*
Default Value : %s[%d]
EXAMPLES
• Example-1 : Use parentheses to seperate array elements
prompt> set ri_synth_array_naming_style %s(%d)
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

Sets
the
naming
style
for
design
object
names.
This
must
be
a
string
that
matches
the
pattern
"%s.*
%p.*"
where
%s
refers
to
the
module
or
entity
name
and
%p
refers
to
the
list
of
paremeter
or
generic
values.
Any
of
the
".*"
values
can
be
empty
Value

Value string
Type :
Valid %s.*
Values : %p.*
Default %s_
Value : %p
Category
EXAMPLES
• Example-1 :
Use
periods
to
seperate
design
objects
and
parameters.
prompt>
set
%s.
%p.
RELATED
COMMANDS
analyze_intent
RELATED
VARIABLES

Sets the naming style for the object names of parameterized designs. This must be a string that matches the pattern
"%s.*%d.*" where %s refers to the parameter or generic name and %d refers to the parameter or generic value. Any of
the ".*" elements can be empty.
Value
Value Type : string
Default Value : %s%d
EXAMPLES
• Example-1 : Use parentheses to seperate parameter names and values.
prompt> set ri_synth_design_parameter_style %s(%d)
RELATED COMMANDS
analyze_intent
RELATED VARIABLES

Sets
the
separator
betwee
name-
value
pairs
for
object
names
of
parameterized
design
designs.
This
must
be
a
string
that
matches
the
pattern
"%s"
where
%s
refers
to
the
separator
string.
Value
Value string
Type :
Valid %s
Values :
Default _
Value :
Category
EXAMPLES
• Example-1 :
Use
a

period
to
seperate
name-
value
pairs
for
parameterized
designs.
prompt>
set
ri_synth_design_separator_style .
RELATED
COMMANDS
analyze_intent
RELATED
VARIABLES

Sets the naming style for referring to interface member objects. This must be a string that matches the pattern "%s.*
%s" where %s refers to the interface name and %d refers to the interface member. The ".*" can be an empty string.
Value
Value Type : string
Valid Values : %s.*%s
Default Value : %s.%s
EXAMPLES
• Example-1 : Use underscore to seperate interface names and member objects.
prompt> set ri_synth_interface_naming_style %s_%s
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

Sets the naming style for referring to record and field objects. This must be a string that matches the pattern "%s.*
%s.*" where %s refers to the record name and %d refers to the record field. Any of the .* elements can be empty.
Value
Value Type : string
Valid Values : %s.*%s.*
Default Value : %s[%s]
EXAMPLES
• Example-1 : Use parentheses to seperate record elements
prompt> set ri_synth_record_naming_style %s(%s)
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the clear pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : clear
EXAMPLES
• Example-1 : Set the name of the clear pin for inferred register objects to "clr".
prompt> set ri_synth_reg_clear_pin_name "clr"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the clocked_pin pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : CK
EXAMPLES
• Example-1 : Set the name of the clocked_on pin for inferred register objects to "clk".
prompt> set ri_synth_reg_clear_pin_name "clk"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the data input pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : data_in
EXAMPLES
• Example-1 : Set the name of the data input pin for inferred register objects to "din".
prompt> set ri_synth_reg_data_in_pin_name "din"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the enable pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : enable
EXAMPLES
• Example-1 : Set the name of the enable pin for inferred register objects to "EN".
prompt> set ri_synth_reg_clear_pin_name "EN"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets
the
suffix
for
mapping
inferred
register
objects
to
their
netlist
names.
Value
Value string
Type :
Valid %s
Values :
Default _reg
Value :
Category
EXAMPLES
• Example-1 :
Set
the
naming
style
for
inferred
register
objects
to
"_ff".
prompt>
set
"ff"
RELATED
COMMANDS
analyze_intent
read_env
read_sdc

RELATED
VARIABLES
None

Sets the name of the next state pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : D
EXAMPLES
• Example-1 : Set the name of the next state pin for inferred register objects to "d_in".
prompt> set ri_synth_reg_clear_pin_name "d_in"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the inverted output pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : QN
EXAMPLES
• Example-1 : Set the name of the inverted output pin for inferred register objects to "q_bar".
prompt> set ri_synth_reg_output_inv_pin_name "q_bar"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the output pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : Q
EXAMPLES
• Example-1 : Set the name of the output pin for inferred register objects to "out".
prompt> set ri_synth_reg_output_pin_name "out"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the preset pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : preset
EXAMPLES
• Example-1 : Set the name of the preset pin for inferred register objects to "pre".
prompt> set ri_synth_reg_preset_pin_name "pre"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the synchronous clear pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : synch_clear
EXAMPLES
• Example-1 : Set the name of the synchronous clear pin for inferred register objects to "sync_clr".
prompt> set ri_synth_reg_synch_clear_pin_name "sync_clr"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the name of the synchronous enable pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : synch_enable
EXAMPLES
• Example-1 : Set the name of the synchronous enable pin for inferred register objects to "sync_enable".
prompt> set ri_synth_reg_synch_enable_pin_name "sync_enable"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets
the
name
of
the
synchronous
preset
pin
for
inferred
register
objects.
Value
Value string
Type :
Valid %s
Values :
Default synch_preset
Value :
Category
EXAMPLES
• Example-1 :
Set
the
name
of
the
synchronous
preset
pin
for
inferred
register
objects
to
"sync_preset".
prompt>
set
"sync_preset"
RELATED
COMMANDS

analyze_intent
read_env
read_sdc
RELATED
VARIABLES
None

Sets the name of the synchronous toggle pin for inferred register objects.
Value
Value Type : string
Valid Values : %s
Default Value : synch_toggle
EXAMPLES
• Example-1 : Set the name of the synchronous toggle pin for inferred register objects to "sync_tog".
prompt> set ri_synth_reg_synch_toggle_pin_name "sync_tog"
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the naming style for referring to design objects created by VHDL generate statements. This must be a string that
matches the pattern "%s.*%d.*" where %s refers to the design name and %d refers to the generate index value. Any of
the .* elements can be empty.
Value
Value Type : string
Default Value : %s_%d
EXAMPLES
• Example-1 : Use parentheses to seperate generated VHDL design elements
prompt> set ri_synth_vhdl_generate_naming_style %s(%d)
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the separator style for referring to design objects created by VHDL generate statements with multple indexes.
If a generated instance has more than one index, it will be separated by the given string. This must be a string and
cannot be empty.
Value
Value Type : string
Valid Values : %s
Default Value : _
EXAMPLES
• Example-1 : Use periods to seperate generated VHDL design elements with multiple indexes.
prompt> set ri_synth_vhdl_generate_separator_style .
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the naming style for referring to design objects created by Verilog generate statements. This must be a string
that matches the pattern "%s.*%d.*" where %s refers to the design name and %d refers to the generate index value. Any
of the .* elements can be empty.
Value
Value Type : string
Default Value : %s[%d]
EXAMPLES
• Example-1 : Use parentheses to seperate generated Verilog design elements
prompt> set ri_synth_vlog_generate_naming_style %s(%d)
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

Sets the separator style for referring to design objects created by Verilog generate statements with multple indexes.
If a generated instance has more than one index, it will be separated by the given string. This must be a string and
cannot be empty.
Value
Value Type : string
Valid Values : %s
Default Value : .
EXAMPLES
• Example-1 : Use underscores to seperate generated Verilog design elements with multiple indexes.
prompt> set ri_synth_vlog_generate_separator_style _
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

This variable is used to the translation of set_output_delay commands to an environment file. If disabled,
set_output_delay commands will not be translated to create_output environment specifications.
Value
EXAMPLES
• Example-1 : Disable translation of set_output_delay commands to create_output environment specifications.
prompt> set ri_translate_set_output_delay false
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

ri_use_exact_waveform_periods_in_sdc_to_env_translation
This variable is used to configure the translation of synchronous SDC clocks. When enabled, synchronous SDC clocks
are translated to environment specifications using a normalization factor.
Value
EXAMPLES
• Example-1 : Enable use of a normalization factor when SDC clocks are translated to environment waveforms.
prompt> set ri_use_exact_waveform_periods_in_sdc_to_env_translation true
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

ri_use_logically_exclusive_as_async
This variable is used to configure how logically exclusive clock groups are translated into an environment file. If set to
true, logically exclusive clocks are translated to asynchronous waveforms in an environment specification.
Value
EXAMPLES
• Example-1 : Enable logically exclusive clock groups to be translated into asynchronous environment
waveforms
prompt> set ri_use_logically_exclusive_as_async true
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

ri_use_physically_exclusive_as_async
This variable is used to configure how physically exclusive clock groups are translated into an environment file. If set
to true, physically exclusive clocks are translated to asynchronous waveforms in an environment specification.
Value
EXAMPLES
• Example-1 : Enable physically exclusive clock groups to be translated into asynchronous environment
waveforms
prompt> set ri_use_physically_exclusive_as_async
RELATED COMMANDS
analyze_intent
read_env
read_sdc
RELATED VARIABLES
None

This
variable
is
used
to
configure
how
set_false_path
commands
are
translated
into
an
environment
file.
If
disabled,
false
paths
have
to
be
specified
in
both
directions
for
clocks
to
be
created
as
asynchronous
waveforms
in
an
environment
specification.
Value
Value boolean
Type :
Valid true
Values : |
false
Default true
Value :
Category

EXAMPLES
• Example-1 :
Require
false
paths
in
both
directions
for
clocks
to
be
translated
into
asynchronous
environment
waveforms
prompt>
set
false
RELATED
COMMANDS
analyze_intent
read_env
read_sdc
RELATED
VARIABLES
None

ri_write_multi_clock_waveforms
Write multi-clock waveforms with single corresponding create_input and create_output commands for inputs and
outputs that have a spec on multiple clocks. When set to false, inputs and outputs that have a spec on multiple clocks
are written as separate create_input and create_output commands in the generated env file.
Value
EXAMPLES
• Example-1 : Disable writing of multi-clock waveforms
prompt> set ri_write_multi_clock_waveforms false

In this case, Meridian CDC writes separate create_input and create_output commands in the generated
env file. For example, the following .sdc file contains the following commands the put more than one
clock on an input and an output:
set_output_delay 1 -clock [get_clocks {sys_tx_clk2}] [get_ports col]
set_output_delay 1 -clock [get_clocks {eth_tx_clk}] [get_ports col] -add
set_input_delay 1 -clock [get_clocks {eth_tx_clk}] rmii_mode

set_input_delay 1 -clock [get_clocks {sys_tx_clk1}] rmii_mode -add
After running analyze_intent, the generated env file contains the following separate create_input and
create_output commands:
create_input -waveform {"eth_tx_clk"} { rmii_mode }
create_input -waveform {"sys_tx_clk1"} { rmii_mode }
create_output -waveform {"eth_tx_clk"} { col }

create_output -waveform {"sys_tx_clk2"} { col }
In the above case, one waveform will be chosen for each port that has more than one waveform during
structural CDC analysis.
• Example-2 : Enable writing of multi-clock waveforms
prompt> set ri_write_multi_clock_waveforms true

In this case, Meridian CDC writes one create_input and one create_output command corresponding to
the multi-clock waveform in the generated env file. For example, the following .sdc file contains the
following commands the put more than one clock on an input and an output:
set_output_delay 1 -clock [get_clocks {sys_tx_clk2}] [get_ports col]
set_output_delay 1 -clock [get_clocks {eth_tx_clk}] [get_ports col] -add
set_input_delay 1 -clock [get_clocks {eth_tx_clk}] rmii_mode

set_input_delay 1 -clock [get_clocks {sys_tx_clk1}] rmii_mode -add
After running analyze_intent, the generated env file contains the following single create_input and
create_output commands corresponding to the generated multi-clock (which has an MCLK prefix):
create_waveform -period 10 -transitions {0 5} MCLKIN_eth_tx_clk_sys_tx_clk1_RI_W
create_input -waveform {"MCLKIN_eth_tx_clk_sys_tx_clk1_RI_W"} { rmii_mode }

create_waveform -period 10 -transitions {0 5} MCLKOUT_eth_tx_clk_sys_tx_clk2_RI_W

create_output -waveform {"MCLKOUT_eth_tx_clk_sys_tx_clk2_RI_W"} { col }
RELATED COMMANDS
analyze_intent
RELATED VARIABLES
None

List of Meridian Variables and Their Default Values

The following table lists all Meridian CDC variables and their default values.
ri_on_the_fly_shell_write_debug false
ri_synth_reg_enable_pin_name enable
ri_normalize_to_uniform_clk_periods false
ri_exclude_association_through_clock_gate false
ri_report_s_multclk true
ri_detect_masync_on_outputs true
ri_simportal_pulse_width_checks {}
ri_quick_FE_run false
ri_report_s_henv_extra_spec true
ri_report_w_masync true
ri_synth_reg_synch_toggle_pin_name synch_toggle
ri_vhdl_std_logic_dash_is_x false
ri_report_s_unknown_clkpol_max_count 1000
ri_allow_flop_driven_clk_gate true
ri_report_s_henv_attr_conflict true
ri_report_s_henv_missing_spec true
ri_use_more_patterns_for_bus_bit_skip false
ri_report_w_async_rst_flops true
ri_use_free_running_clocks false
ri_report_i_constant true
ri_simportal_enable_data_stability_checks true
ri_old_mixed_lang_name_format false
ri_report_err_feedback false
ri_report_s_num_analysis_time_slices true
ri_read_design_report false
ri_report_black_box true
ri_vhdl_map_work_to_target_library false
ri_echo_sdc_commands true
ri_verify_data_stability false
ri_synth_reg_synch_clear_pin_name synch_clear
ri_verify_gray_codes true
ri_incdef_accumulate false
ri_report_number_of_drivers_for_data all
ri_sdc_report_ignored_commands false
ri_report_w_d_clk_glitch false
ri_set_delay_on_async_cntl_xings 0
ri_simportal_data_stable_checks {}
ri_max_time_slices 10000
ri_report_internal_s_norst false
ri_md_formal_flow throughput

ri_set_number_of_sync_stage_delays 1
ri_verify_one_data_bit_per_bus true
ri_use_unidir_clk2clk_sfp_as_async true
ri_max_total_range_bits 12
ri_auto_get_lib false
ri_user_defined_cells_file {}
riSrcRecursionCnt 1
ri_max_modulus_size 8
ri_synth_reg_data_in_pin_name data_in
ri_simportal_force_control {}
ri_synth_reg_clocked_on_pin_name CK
ri_set_min_default_delay_on_async_data_xings 0
ri_use_logically_exclusive_as_async false
ri_strict_synchronizer_detection true
ri_remove_unused_flops false
ri_generate_vcd_for_bounded_and_pass false
ri_user_module_data {}
ri_simportal_gray_code_checks {}
ri_ram_max_reset_count 3
ri_synth_reg_next_state_pin_name D
ri_assoc_as_fixed_array false
ri_report_i_encap true
ri_ignore_pull_up_down false
ri_exclude_internal_reset_analysis true
ri_report_s_conf_env true
ri_report_none_as_w_cntl false
ri_simportal_glitch_checks {}
ri_warn_potential_syncs true
ri_verify_pulse_widths true
ri_infer_s_no_reset_from_reset_syncs true
ri_vy_lib_accumulate false
ri_create_outputs_on_black_box_inputs false
ri_effort_level_for_data_control_condition 3
ri_max_loop_unroll 1024
ri_min_synchronizer_depth_4_domains {}
ri_assume_timing_constraints_on_cntls true
ri_synth_reg_preset_pin_name preset
ri_use_physically_exclusive_as_async false
ri_vhdl_allowed_logic_types {}
ri_report_w_g_clk_glitch_sync_reset_select true
ri_report_s_henv_type_conflict true
ri_report_clk_groups true
ri_identify_sync_path_blocking false

ri_ram_min_size 0
ri_restrict_to_definite_constants false
ri_override_input_spec_for_reset_or_mode_identification true
ri_fill_info_column_for_warfs false
ri_oac_strict_type_checking true
ri_synth_vlog_generate_naming_style {%s[%d]}
ri_write_lib_modules true
ri_report_s_clk_off_sub_tree true
ri_xv_max_pess_expr 80000
ri_report_s_input_no_wave true
ri_report_all_w_recon_points false
ri_max_decoder_size 16
ri_report_w_g_clk_glitch_missing_spec true
ri_report_w_fanout true
ri_sv_compilation_unit single
ri_report_i_henv_db_map true
ri_report_dbg_file_for_each_driver false
ri_report_i_clk_tree_alias_names false
ri_ignore_w_fanout_with_no_recon false
ri_report_s_henv_waveform_conflict true
ri_synth_array_naming_style {%s[%d]}
ri_check_henv_input_spec true
ri_enhance_clock_domain_analysis_in_conf_env true
ri_ignore_fast_to_slow_gray_code_checks false
ri_vhdl_preserve_case false
ri_max_multiplier_size 8
ri_exclude_cntl_masync_from_w_glitch false
ri_xv_check_polarity_of_recon true
ri_report_w_encap true
ri_report_dbg_files_for_warfs false
ri_report_w_g_clk_glitch true
ri_report_number_of_drivers_for_cntl all
ri_report_inferred_latches_in_log false
ri_comment_auto_detected_sync_resets false
ri_sdc_echo_limit 256
ri_disable_name_based_clock_and_reset_spec_creation false
ri_simportal_dont_touch_modules {}
ri_product_name MeridianCDC
ri_suppress_msg {}
ri_xv_initial_pess_input_cone 20
ri_report_all_w_blocked_crossing false
ri_generate_traces true
ri_simportal_enable_gray_code_checks true

ri_dash_v_is_lib_cell false
ri_synth_record_naming_style {%s[%s]}
ri_simportal_sync_pulse_width_checks {}
ri_product_version 2015.A.P3.RC
ri_enable_vx_code true
ri_extract_genclks_from_liberty true
ri_xv_initial_pess_expr 30000
ri_synth_interface_naming_style %s.%s
ri_report_w_g_clk_glitch_gate_config true
ri_report_u_interface true
ri_write_expanded_async_xings_exceptions true
ri_report_s_genclk true
ri_smallest_depth_recon_report false
ri_report_number_of_drivers_for_w_data all
ri_ignore_pragma_vendors {}
ri_report_clk_glitch_dbg_files true
ri_max_divider_size 8
ri_report_w_lockup false
ri_exclude_all_reset_analysis false
ri_user_associated_data {}
ri_synth_reg_clear_pin_name rst
ri_simportal_name_map {}
ri_count_rtl_only_flops_and_latches_in_design_stats false
ri_search_path {}
ri_exclude_clock_path_from_recon false
ri_report_w_masync_all_drivers false
ri_synth_reg_synch_enable_pin_name synch_enable
ri_report_s_noclk true
ri_oac_result_display_limit 100
ri_report_s_clk_gate_no_wave true
ri_ignore_vs_files false
ri_report_w_g_clk_glitch_x_input false
ri_max_signed_modulus_size 8
ri_report_i_assume true
ri_report_all_w_fanout_points false
ri_report_setup_dbg_files true
ri_report_w_data true
ri_report_s_norst true
ri_check_missing_feedback true
ri_report_interface true
ri_synth_vhdl_generate_separator_style _
ri_xv_max_pess_input_cone 60

ri_report_second_stage_as_sync_out false
ri_create_outputs_in_create_env false
ri_report_w_g_clk_glitch_async_reset_select true
ri_vhdl_require_ordered_analyze false
ri_reading_sdc_file false
ri_set_min_default_delay_on_async_cntl_xings 0
ri_ram_max_word_size 4096
ri_synth_translate_style {}
ri_report_w_glitch true
ri_convert_SDC_clocks_async false
ri_synth_reg_output_inv_pin_name QN
ri_report_i_clk_trees true
ri_normalize_clk_periods true
ri_sourcing_file 1
ri_report_w_interface true
ri_cadence_compatible true
ri_verify_one_cntl_bit_per_bus true
ri_report_masync_dbg_files true
ri_max_single_range_bits 12
ri_simportal_checks_starter_file simportal_checks.conf
ri_max_remainder_size 8
ri_synth_models_internal_dirs {}
ri_simportal_enable_force_control true
ri_auto_break_all_loops_for_formal false
ri_report_static_loops true
ri_extract_genclks_filename meridian_project/liberty/read_lib.sdc
ri_project_directory_name meridian_project
ri_report_w_recon_points false
ri_unique_recon_points_at_all_depths false
ri_report_w_rst_spec_clk true
ri_product_build_time 19:46:45
ri_report_reset_syncs_with_func_cdc_as_warf false
ri_report_sync_crossing false
ri_report_w_rst_uncertainty false
ri_report_s_rst_inv_verbose false
ri_verify_one_clock_glitch_bit_per_bus true
ri_simportal_enable_pulse_width_checks true
ri_set_delay_on_synchronizer_stages 0
ri_write_multi_clock_waveforms true
ri_report_s_rst_inv true
ri_max_glitch_driver_count 5
ri_simportal_enable_glitch_checks true
ri_max_ratio_after_auto_normalization 16

ri_report_crossing_rx_net_as_recon_point true
ri_report_w_half true
ri_env_priority_order priority_single
ri_synth_design_separator_style _
ri_report_recon_dbg_files false
ri_synth_models_user_dirs {}
ri_hdl_sv true
ri_create_inputs_on_black_box_outputs true
ri_sdc_uniquify_warning_numbers true
ridbMode 1
ri_check_cntl_type_mismatch false
ri_synth_reg_naming_style _reg
ri_simportal_enable_force_w_data false
ri_report_s_multclk_max_count 1000
ri_report_w_g_clk_glitch_async_input true
ri_trace_w_fanout_paths false
ri_simulation_prefix MERIDIAN_HIER_PREFIX
ri_report_i_henv_wave_map true
ri_report_w_g_clk_glitch_bad_polarity false
ri_report_w_recon_groups true
ri_synth_reg_synch_preset_pin_name synch_preset
ri_enforce_strict_variable_settings true
ri_synth_vlog_generate_separator_style .
ri_synth_design_naming_style %s_%p
ri_synth_reg_output_pin_name Q
ri_report_warn_for_all_glitches false
ri_report_w_blocked_crossing false
ri_set_delay_on_async_data_xings 0
ri_verify_gray_codes_on_rx_flops false
ri_report_s_multclk_verbose false
ri_max_signed_remainder_size 8
ri_report_all_unregistered_outputs_in_w_encap false
ri_remove_unused_lib_cell_flops true
ri_fill_info_column_for_rs false
ri_simportal_force_data {}
ri_product_build_date 11/25/2015
ri_product_rev 69066
ri_abs_file_name true
ri_match_nc false
ri_verify_gray_codes_on_all_recon false
ri_synth_vhdl_generate_naming_style %s_%d
ri_report_s_bb_out_no_wave true

ri_user_associated_cntl {}
ri_env_error_on_signal_not_found false
ri_xing_mcp_cycles 2
ri_translate_set_output_delay true
ri_max_left_shift_size 10
ri_synth_design_parameter_style %s%d
ri_assume_primary_inputs_have_glitch_potential true
ri_report_w_fanout_to_mult_async_domains false
ri_report_potential_static_as_w_cntl false
ri_allow_ram_pin_driver_for_cntl false
ri_assoc_as_fixed_array_of_size 0
ri_max_signed_divider_size 8
ri_max_signed_multiplier_size 8
ri_warn_all_multi_driver_crossings false
ri_report_pulse_sync false
ri_report_w_cntl true
ri_report_uninitialized_flops_latches true
ri_ignore_unused_virtual_clocks true
ri_ignore_unused_flops_in_analysis false
ri_report_dbg_files_for_rs false
ri_process_all_pulse_width_checks false
ri_max_exceeded_stops_elab false
ri_report_rst_sync true
ri_report_s_unknown_clkpol true
ri_report_w_redundant_sync true
ri_identify_data_control_condition false
ri_max_signed_right_shift_size 10
ri_use_platform_gdb true
ri_simportal_enable_force_data false
ri_max_right_shift_size 10
ri_report_s_net_no_wave true
ri_use_exact_waveform_periods_in_sdc_to_env_translation false
ri_reclass_max_sync_depth_to_data 1
ri_report_w_clk_recon true
ri_sdc_error_on_cmd_failure false
ri_report_s_output_no_wave false
ri_report_inferred_flops_in_log false
ri_verify_cntl_glitches true
ri_detect_missing_sync_reset true
ri_session_name {}
ri_remove_unused_combo_logic true
ri_check_cntl_depth_mismatch false
ri_allow_plus_in_incdir false

ri_match_vcs false
ri_ram_min_words 0
ri_report_dbg_files true
ri_simportal_ignore_checks_with_Z_X_inputs false
ri_report_all_signals_in_i_constant false
ri_preserve_paths_in_auto_bboxed_insts true
ri_report_w_rst_half true
ri_identify_controlled_propagation false
ri_create_inputs_on_undriven_nets true
ri_require_env_specs_on_all_inputs false
ri_require_env_specs_on_all_outputs false
ri_ignore_all_primary_input_drivers true
ri_flop_depth_for_cntl unlimited
ri_flop_depth_for_cntl_glitch unlimited
ri_flop_depth_for_data unlimited
ri_flop_depth_for_gray_code unlimited
ri_write_zdb true

How-To Topics

Compiling Your Design
read_liberty
Use the read_liberty command to convert any Liberty library files to Verilog modules.
analyze
Use the analyze command to parse the design files and resolve libraries.
elaborate
Use the elaborate command to build the design hierarchy, check semantics, and build the internal netlist
model.

Generating Design Specification
Spec Configuration
This step is to configure the specs using the variables. For variables relating to this look into the
section Intent Configuration
read_sdc/read_env
This is the step where already existing sdc file or env file is read.
analyze_intent
This step analyzes the intent of design specification.

Understanding Formal Verification Results

This topic explains how to interpret formal verification results in Meridian CDC.

Global Clock Period and Number of Segments

This section explains how Global clock period and phases are calculated while doing formal analysis. The global clock
period is the time period in which all the clocks defined in the design complete at least one cycle. The farmula for
calculating global clock period involves all the specified clock periods and it something like
Global clock period = LCM of (Tclk1, Tclk2 .... Tclkn) where Tclk1 is period of clock clk1
For example consider a design in which there are three clocks with periods 80,100 and 640. Then the global clock
period would be 3200.
Within the global clock period there would be time stamps at which the circuit is evaluated during formal analysis. The
number of these time stamps is referred to as time segments. Time segments gives an indication of number of circuit
updates and hence higher number of time segments mean decline in performance of formal verification. The formula
for calculating number of time segments is
# time segments = 2*(GlobalClockPeriod/clk1 + GlobalClockPeriod/clk2 ... + GlobalClockPeriod/clkn

- (CM(clk1, clk2) + CM(clk1, clk3) + ... + CM(clk1, clkn))
- (CM(!clk1, clk2, clk3) + ... + CM(!clk1, clk2, clkn))
- (CM(!clk1, !clk2, clk3, clk4) + ... + CM(!clk1, !clk2, clk3, clkn))
.......
- (CM(!clk1, !clk2, !clk3, ..., clkedn-1, clkedn)))
Where CM is number of common multiples till the LCM value. So
• CM(!clk1, clk2, clk3) means number of common multiples of clk2 an clk3 till the LCM value that are not in clk1
• CM(!clk1, !clk2, clk3, clk4) -> # of common multiples of clk3 and clk4 till the LCM value that are not in clk1 and clk2
Using the same example of clock periods 80,100 and 640, let us calculate number of time segments.
# time segments = (3200/80 + 3200/100 + 3200/640) - CM(80,100) - CM(80,640) - CM(!80,100,640)

CM(80,100) = 8 (400, 800, 1200, 1600, 2000, 2400, 2800, 3200)
CM(80, 640) = 5 (640, 1280, 1920, 2560, 3200)
CM(!80, 100, 640) = 0
So
#time segments = 2*(40 + 32 + 5 -8 -5 -0) = 128

Understanding Debug Information

When there is debug information available for a rule result, a debug information locator string appears in the Info
column of the rule results table on the Data pane in iDebug (see Rules with Debug Information Files).
Using the Analysis menu ribbon, you can view details of the debug information for a rule result in a popup window.
Information about the environment specification or waveform information relevant to the design analysis and
verification appears in the Env Info column of the popup window.
For example, you might see the following details appear in a debug popup window when you click Crossing Path on the
Analysis menu ribbon for a DATA rule result.
The following strings might appear in the Env Info column.
Env Info Meaning

-env= cc- The net is a create_clock in the env file
ci- The net is a create_input in the env file
co- The net is a create_output in the env file
cr- The net is a create_reset in the env file

in- The net has a set_initial_value in the env file
sc- The net has a set_constant in the env file
ss- The net has a set_initial_state in the env file
st- The net has a set_stable_value in the env file
(<during>,<after>) Values during and after the reset
-const0- The net is constant zero
-stable- The net has a stable value
-x- The net has an unknown value
The Point Info column contains information about the sequence of signals, from a starting signal (driver) to an ending
signal (receiving-flop). The signals in between appear as "on-path".

Rules That Generate Debug Information

The following rules generate debug information (.dbg) when there is a violation to investigate.
BLACK_BOX
CNTL
DATA
GRAY_CODE_CHECKS
I_ASSUME
I_CLK_DOMAINS
I_CONSTANT
INTERFACE
PULSE_SYNC
RST_SYNC
S_CLK_OFF_SUB_TREE
S_CONF_ENV
S_GENCLK
S_HENV_ATTR_CONFLICT
S_HENV_EXTRA_SPEC
S_HENV_MISSING_SPEC
S_HENV_TYPE_CONFLICT
S_HENV_WAVE_CONFLICT
S_INPUT_NO_WAVE
S_MULTCLK
S_NET_NO_WAVE
S_NOCLK
S_NORST
S_OUTPUT_NO_WAVE
S_RST_INV
S_UNKNOWN_CLKPOL
SYNC_CROSSING
U_INTERFACE
W_ASYNC_RST_FLOPS

W_BLOCKED_CROSSING
W_CLK_RECON
W_CNTL
W_DATA
W_ENCAP
W_FANOUT
W_G_CLK_GLITCH
W_GLITCH
W_HALF
W_INTERFACE
W_LOCKUP
W_MASYNC
W_RECON_GROUPS
W_RST_HALF
W_RST_UNCERTAINTY

Creating Your Own Rule Policy

You can create your own rule policy for Meridian CDC. You can save your policy in a Tcl file and source it in a run script
or as part of a flow script. The sample script below demonstrates how you can create your own rule policy based on
factory rules.
Sample policy script - my_policy.tcl

## Meridian CDC Analysis check from 2015.A
## This specific format implies that the rule_instance name and the rule reference
## names are the same. If customer wants to create their own rule instance name
## and link to our built in rules, then change the name of the 0 index in the list
## to the prefered name. For example, if W_DATA to be displayed as FOO, below
## should be followed ;
#set ERROR [list \
# [list FOO W_DATA] \
# ]
## Rules in the ERROR group

set ERROR [list \
[list W_DATA W_DATA] \
[list W_CNTL W_CNTL] \
[list W_MASYNC W_MASYNC] \
[list W_GLITCH W_GLITCH] \
[list W_FANOUT W_FANOUT] \
[list W_RECON_GROUPS W_RECON_GROUPS] \
[list W_G_CLK_GLITCH W_G_CLK_GLITCH] \
[list W_CLK_RECON W_CLK_RECON] \
[list W_ASYNC_RST_FLOPS W_ASYNC_RST_FLOPS] \
[list W_RST_GLITCH W_RST_GLITCH] \
]
## Rules in the WARNING group

set WARNING [list \
[list W_HALF W_HALF] \
[list W_INTERFACE W_INTERFACE] \
[list W_ENCAP W_ENCAP] \
[list W_REDUNDANT_SYNC W_REDUNDANT_SYNC] \
[list W_D_CLK_GLITCH W_D_CLK_GLITCH] \
[list W_LOCKUP W_LOCKUP] \
[list W_BLOCKED_CROSSING W_BLOCKED_CROSSING] \
[list W_RST_SPEC_CLK WRST_SPEC_CLK] \
[list W_RST_UNCERTAINTY W_RST_UNCERTAINTY] \
]
## Rules in the INFO group

set INFO [list \
[list DATA DATA] \
[list CNTL CNTL] \
[list GRAY_CODE_CHECKS GRAY_CODE_CHECKS] \
[list PULSE_SYNC PULSE_SYNC] \
[list INTERFACE INTERFACE] \
[list U_INTERFACE U_INTERFACE] \
[list SYNC_CROSSING SYNC_CROSSING] \

[list I_ASSUME I_ASSUME] \

[list I_CLK_DOMAINS I_CLK_DOMAINS] \
[list I_CLK_TREES ICLK_TREES] \
[list BLACK_BOX BLACK_BOX] \
[list I_CONSTANT I_CONSTANT] \
[list I_RESET_SIGNAL I_RESET_SIGNAL] \
[list RST_SYNC RST_SYNC] \
]
## Create specific view criterias below if policy needed to be customized

## create_view_criteria -name foo -criteria ""
## Creating rule policy for Meridian-CDC ANALYSIS checks

set rp "MCDC_USER_POLICY" ; ## default policy name, please change the name for user policies
create_rule_policy $rp
## create rule groups for the policy MCDC_USER_POLICY

foreach rg [list ERROR WARNING INFO] {
## create the group
create_rule_group $rg -rule_policy $rp
## then add rule instances
foreach {ri rf} [set $rg] {
create_rule_instance $ri -rule_group $rp/$rg -rule $rf
## if specific view criteria needs to be attached to the specific rule instance
## then do it here
## set_attribute [get_rule_instance $rp/$rg/$ri] view_criteria "foo"
}
}

Using Scope-Based Reporting

You can use the ModuleScope rule attribute to view either block-level or top-level rule violations. The recommended
approach is to use Real Intent iDebug to create queries based on results filtered by block (module) name or by top-
level module.
Note: Using the CLI, you can create similar view criteria (using the create_view_criteria command) to report results
using the report_policy command (-module <name>).

Viewing Rule Violations for a Particular Block

To view rule violations for a particular block, do the following:
1. Identify the block for which you want to view rule violations.
In iDebug, you can do the following:
a. Click Show/Hide Columns and scroll down the list of available columns to mark the box for ModuleScope and
click Apply.
For example:
b. [Optional] From the Rows Per Page drop-down list, select All.
For example:
c. Click the down-arrow in the ModuleScope column heading to view available filters (values in the
ModuleScope column).
For example:

d. Note the block designation you want to specify and click Cancel.
2. Use the View Criteria pane to specify the appropriate filter to display block-level rule violations.
a. Click the ViewCriteria side-tab.

b. On the View Criteria menu, click New.
c. On the Query pane, specify ModuleScope, matches pattern, "*<block_name>".
For example:
d. Click Submit Query to view results.

For example:

e. On the View Criteria menu, use Save As to save the query.

Viewing Top-Level Rule Violations

To view top-level rule violations, do the following:
1. Identify the top-level module.
In iDebug, you can do the following:
a. Click Show/Hide Columns and scroll down the list of available columns to mark the box for ModuleScope and
click Apply.
For example:
b. [Optional] From the Rows Per Page drop-down list, select All.
For example:
c. Click the down-arrow in the ModuleScope column heading to view available filters (values in the
ModuleScope column).
For example:

d. Note the top-level module designation and click Cancel.
2. Use the View Criteria pane to specify the appropriate filter to display block-level rule violations.
a. Click the ViewCriteria side-tab.

b. On the View Criteria menu, click New.
c. On the Query pane, specify ModuleScope, matches pattern, "*<top_level>" (for example,
d. Click Submit Query to view results.

For example:

e. On the View Criteria menu, use Save As to save the query.

Using Shell Models

Meridian CDC’s bottom-up CDC capability allows users to create CDC shell models for modules already verified to be
free of CDC issues. The generated shell models together with the environment information can be used for verification
at higher levels. The benefits of bottom-up verification include faster processing time at the top level, simpler
verification reporting and, therefore, simplified debugging, because lower level issues are gone, as well as ensuring
correctness of environment specification at the top level versus the lower level.
The following steps are needed for the bottom-up CDC verification:
1. Make sure that lower level blocks are free of CDC issues, and in particular, there are no signals listed in the
W_ENCAP category.
W_ENCAP reports crossings at the input and output boundary. For example, if an input signal is associated with
clock domain A through a create_input specification in the environment file, yet it is feeding into a flop driven
by clock domain B, then there is a crossing at the boundary for this input from clock domain A to domain B.
Similarly on the output side, if an output signal is driven by a flop from clock domain A, yet the environment
specification for this output is defined to be associated with clock domain B through the create_output
command, then there is a crossing at the output for this signal. Blocks with crossings at the boundary are not
good candidates for shell model generation because verification on these signals could be incomplete if the
logic associated with these signals is shelled out during the shell model process.
2. Run Meridian CDC at the top level using the shell model. For a CDC-clean block, add a set_shell_instances
command in the control script.
analyze {list of design files}

elaborate <design_top>
read_env <design.env>
analyze_intent
set_shell_instances -module <shell_module_name>
verify_cdc
Note that set_shell_instances only accepts one module name at a time. Incase there are mutiple
instantations of same module with different parameters, set_shell_instances can be used in following
way
foreach mName [get_all_modules <shell_module_name>] {

set_shell_instances -module $mName
}
See get_all_modules for additional information.
3. You can review the top-level report and debug CDC issues using Real Intent iDebug.

Customizing Metadata in the RIDB

To use RIDB metadata customization commands, you must put them in a file called custom_factory_db_override.tcl
in the <installation_directory>/release/RealIntent/<family>/<tool>/dbs/ directory. (For example, for Meridian CDC:
<installation_directory>/release/RealIntent/Meridian/CDC/dbs/) The Real Intent tool engine will source this file to edit
the metadata prior to starting the engine run. You cannot use RIDB metadata customization commands any other way
(not interspersed with other CLI commands in your run script, not at the iDebug CLI prompt).
Note: Metadata commands are generally of the form <action>_<object>_<attribute>. For example,
set_rule_policy_is_factory sets the isFactory attribute for a rule policy. "set" is the <action>, "rule_policy" is the
<object>, and "is_factory" is the <attribute>.

Changing the Default Status Specifiers

To change the default status specifiers for a tool, do the following:
1. Unset to remove the current set of default factory status specifiers from the tool.
2. Create a new set of status specifiers using the create_status RIDB access command.
3. Set the isFactory attribute.
For example:
unset_status_tool -status New

unset_status_tool -status ToBeFixed
unset_status_tool -status Deferred
unset_status_tool -status Waived
unset_status_tool -status ToolWaived
create_status -type Review -level 4 StageOne
create_status -type Review -level 5 StageTwo
create_status -type Review -level 6 StageThree
create_status -type Signoff -level 4 StageFour
set_status_is_factory -status StageOne
set_status_is_factory -status StageTwo
set_status_is_factory -status StageThree
set_status_is_factory -status StageFour
set_status_is_default -status StageOne

Changing the Default Rule Policies

To change the default rule policies, do the following:
1. Unset the isFactory attribute for all factory rule policies.

2. Remove the current set of rule policies from the tool.
3. Create your own set of policies.
4. Set the isFactory attribute, the default flag, and the order.
5. [Optional] Create rule groups.
6. [Optional] Create rule instances.
7. [Optional] Attach any view critera.
For example:
# Unset isFactory attribute for all current factory rule policies

unset_rule_policy_is_factory -all
# Remove the current policies from the policy tree

unset_rule_policy_tool -policy New
unset_rule_policy_tool -policy ToBeFixed
unset_rule_policy_tool -policy Deferred
unset_rule_policy_tool -policy Waived
# Create four new policies, mark them isFactory, and set a display order
create_rule_policy StageOne
create_rule_policy StageTwo
create_rule_policy StageThree
create_rule_policy StageFour
set_rule_policy_is_factory -policy StageOne
set_rule_policy_is_factory -policy StageTwo
set_rule_policy_is_factory -policy StageThree
set_rule_policy_is_factory -policy StageFour
set_rule_policy_default_flag -policy StageOne
set_rule_policy_default_flag -policy StageTwo
set_rule_policy_default_flag -policy StageThree
set_rule_policy_default_flag -policy StageFour
set_rule_policy_order -policy StageOne -order 10
set_rule_policy_order -policy StageTwo -order 11
set_rule_policy_order -policy StageThree -order 12
set_rule_policy_order -policy StageFour -order 13
# Create rule groups in the StageOne rule policy

create_rule_group ENVIRONMENT -rule_policy StageOne
create_rule_group Errors -parent_group StageOne/ENVIRONMENT
create_rule_group Warnings -parent_group StageOne/ENVIRONMENT
create_rule_group SETUP -rule_policy StageOne

create_rule_group Errors -parent_group StageOne/SETUP
create_rule_group Warnings -parent_group StageOne/SETUP
create_rule_group Informational -parent_group StageOne/SETUP
create_rule_group ANALYSIS -rule_policy StageOne

create_rule_group ERROR -parent_group StageOne/ANALYSIS
create_rule_group WARNING -parent_group StageOne/ANALYSIS

create_rule_group INFO -parent_group StageOne/ANALYSIS
# Set the isFactory attribute for the new rule groups

set_rule_group_is_factory -rulegroup StageOne/ENVIRONMENT
set_rule_group_is_factory -rulegroup StageOne/ENVIRONMENT/Errors
set_rule_group_is_factory -rulegroup StageOne/ENVIRONMENT/Warnings
set_rule_group_is_factory -rulegroup StageOne/SETUP

set_rule_group_is_factory -rulegroup StageOne/SETUP/Errors
set_rule_group_is_factory -rulegroup StageOne/SETUP/Warnings
set_rule_group_is_factory -rulegroup StageOne/SETUP/Informational
set_rule_group_is_factory -rulegroup StageOne/ANALYSIS

set_rule_group_is_factory -rulegroup StageOne/ANALYSIS/Errors
set_rule_group_is_factory -rulegroup StageOne/ANALYSIS/Warnings
set_rule_group_is_factory -rulegroup StageOne/ANALYSIS/Informational
# Create rule instances, create and attach view criteria

# Set isFactory for new view criteria
create_rule_instance INVALID_SYNTAX -rule_group StageOne/ENVIRONMENT/Errors \
-rule INVALID_SYNTAX
create_view_criteria -name lvc_New_INVALID_SYNTAX \
-rule INVALID_SYNTAX \
-criteria {Status == 'StageTwo'}
attach_view_criteria -viewcriteria lvc_New_INVALID_SYNTAX \
-ruleinstance StageOne/ENVIRONMENT/Errors/INVALID_SYNTAX
set_view_criteria_is_factory -viewcriteria lvc_New_INVALID_SYNTAX
create_rule_instance INVALID_ARG_USAGE \
-rule_group StageOne/ENVIRONMENT/Errors \
-rule INVALID_ARG_USAGE
create_view_criteria -name lvc_New_INVALID_ARG_USAGE \
-rule INVALID_ARG_USAGE \
-criteria {Status == 'StageTwo'}
attach_view_criteria -viewcriteria lvc_New_INVALID_ARG_USAGE -ruleinstance \
StageOne/ENVIRONMENT/Errors/INVALID_ARG_USAGE
set_view_criteria_is_factory -viewcriteria lvc_New_INVALID_ARG_USAGE

Meridian CDC

Uploaded by

Copyright:

Available Formats

Meridian CDC

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Meridian CDC

Uploaded by

Copyright:

Available Formats

Meridian CDC

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

Viewing Rule Violations for a Particular Block ....................................................................1076

http://www.realintent.com | [email protected] | +1-408-830-9336

REAL INTENT LICENSE AGREEMENT & COPYRIGHT NOTICE

Real Intent's Rights

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

Setting Up the License Server

VENDOR vlmd <RI_INSTALL>/bin/vlmd

http://www.realintent.com | [email protected] | +1-408-830-9336

then the following setting of LM_LICENSE_FILE will work:

Starting the License Server

Verifying the License Installation

Bringing Down the License Server

http://www.realintent.com | [email protected] | +1-408-830-9336

Region Organization Phone Email

Korea Real Intent Korea +82-10-9730-8563 [email protected]

http://www.realintent.com | [email protected] | +1-408-830-9336

http://www.realintent.com | [email protected] | +1-408-830-9336

Meridian CDC 2016.A

Enhancements that affect compatibility

General Enhancements and Corrections

http://www.realintent.com | [email protected] | +1-408-830-9336

20892 Remove I_GLITCH and W_PROP_CNTL_GLITCH descriptions from doc

http://www.realintent.com | [email protected] | +1-408-830-9336

Meridian CDC 2015.A

Enhancements that affect compatibility

• read_lib changes to read_liberty (not backwards compatible due to read_library_map)

• Improved Verilog/SystemVerilog Loop Handling

http://www.realintent.com | [email protected] | +1-408-830-9336

• Added variable: ri_max_exceeded_stops_elab - this variable determines whether to stop

• SystemVerilog support of `begin_keyword `end_keyword for 1800-2005 and 1800-2009. The

• read_liberty was enhanced with the options -collapse_indexed_pins (which replaces -

http://www.realintent.com | [email protected] | +1-408-830-9336

• Additional new commands are as follows

• Additional new variables are as follows

http://www.realintent.com | [email protected] | +1-408-830-9336