meridian - RDC

Details

Last Updated: Wednesday, 03 January 2024 17:35

Published: Thursday, 16 May 2019 20:35

Hits: 1443

Meridian RDC:

Meridian RDC is a tool by company called "Real Intent", which does RDC checks. Spyglass by synopsys is other tool that does CDC/RDC checks too. Cadence has their own RDc/CDC checkers.

Install Meridian RDC and then invoke it. Assuming mrdc is the Meridian RDC tool alias:

mrdc -input mrdc.tcl -log mrdc.log -project meridian_project  => we provide i/p file mrdc.tcl which has cmds for all the 4 steps below (instead of -input, we can also use short form -i, and instead of using *.tcl file, we can also use *.rdc file). option -project allows us to dump mrdc internal db into that dir, so that we can restore the old database for debug purpose (tool idebug is used, instead of mrdc. It's invoked as "idebug  -project meridian_project"). option -reset_scenario_mode enables using only reset scenarios instead of groups. So, all cmds use scenarios (scn) in place of group (grp). Total violations in scenario mode is more than in group mode. -reset_scenario_mode will become default in future release.

Steps: All of the tcl cmds are supported in mrdc.

1. design setup => Sets up design for RDC verification. Analyze and elaboarate of RTL done here.


set ri_search_path [list /home/project/ip/src  /home/myblock/rtl ] => optional, setting search path for RTL sources in case we don't provide full path of any rtl file below. There are 100's of meridian var that can be set, look at mrdc manual.
read_liberty [list /home/memory/memory.lib /home/clk_gen/pll.lib ] => optional since we are checking RTL (and not gates), reading in technology specific library cells
analyze -file rtl_file.f -svverilog => analyze all the RTL source files (rtl_file.f is same format as used for any other tool, which has paths of all rtl files, along with any options as "+define+, "-v2k", etc). we can also put options on cmd line as "-svverilog" to enable system verilog
elaborate design_top -black_box [list analog_d2a analog_a2d] => elaborates design with "design_top" as top module. We blackbox blocks that we do not want analyzed or are IP for which there is only verilog model. We can use -auto_black_box to automatically black box any block for which defn is not found, or use -black_box to give list of blocks to black box.

NOTE: elaborate produces internal The database which includes complete description of design. read_design_db cmd can be used to read this database. The name of database can be specified else it's some fixed name (i.e mdrdc.db or something). If we run hierarchical flow for mrdc (discussed later), then we use this elaborate cmd to create db for lower level modules. However, if there are multiple instantiation of this module in top level, then we won't be able to use the same name for different inst of same module. In such scenario, mrdc allows us to create unique db for each such module by having parameter names in name of db. i.e:

elaborate -hier_design_db {dut_block1} => here design db for dut_block1 created with names of all parameter values, i.e for parameter values 1,2,3,4, name=dut_block1-1-2-3-4 where this particular inst of dut_block1 has parameter values 1,2,3,4, similarly for all other parameter values. If -hier_design_db option was not used, then the design db would be named dut_block1 (all such db created under dir meridian_project/dut_block1/dbs/dut_block1-1-2-3-4.db).

read_design_db dut_block1-1-2-3-4 => This cmd used to read the previously created db. So, we don't need to read in all rtl files, we can just read this db for next run. This makes it load design faster. We don't specify dir, as it looks in standard path under project dir (here it's under meridian_project/dut_block1/dbs/)

2. environment setup => optional, needed only if SDC (.sdc) or ENV  (.env) files are already available. SDC is std sdc file, while ENV is native enirnoment file in lieu of sdc. Meridian needs these files to know what signals are clock, primary reset and functional reset. Primary reset are ones that are externally generated, while functional reset are ones that are internally generated (e.g. output of a counter, output of a S/W register, …). Constants should also be provided (i.e jtag_mode is set to 0, etc). Meridian can automatically figure out a lot of this info, and dumps that into a template file for user to review (incase the user doesn't provide the sdc or env file with this info). Any problems found are reported under "SDC_ENV_LINT" Rule group.

There is 1:1 conversion from sdc cmd to env cmd.

SDC: create_clock => ENV: create_clock. create_waveform/create_derived_waveform are used to define a waveform, and then these are used in "create_clock -waveform waveform_1 clk_1" cmd.

SDC: create_generated_clock => ENV: create_clock. create_waveform/create_derived_waveform

SDC: set_case_analysis => ENV: set_constant

SDC: set_input_delay/set_output_delay => ENV: create_input/create_output

ENV: create_reset (no equiv cmd in sdc) => this cmd needed to specify reset. 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.

set_false_path and set_clock_groups are used to determine whether clocks are synchronous or asynchronous.


read_sdc [list /home/mydesign/clock.sdc  /home/mydesign/io.sdc  /home/mydesign/exception.sdc ] => reads in sdc to derive clock information, design boundary relation, and synchronous/asynchronous relationship
#read_env [list /home/mydesign/design_top.env ] => read an existing ENV file to derive design spec. We read either sdc or env file.

 #reset groups => reset group is a set of resets that are activated together during functional operation, along with any mode constraints at the time of activation.  Reset groupings control how checks are created - some checks occur only on resets within a group some checks occur only across groups. A reset domain is a set of flops that become initialized when a "reset group" is asserted. If we don't define reset gropus, then our results will be very noisy, as RDC won't won't know how these resets work with each other. Meridian RDC defines "reset_groups" using the set_reset_group command. However, we use below cmd to create groups automatically. We can also define other characteristics as if clocks are off, when reset is active,
 
create_set_reset_group_scripts -output reset_groups.tcl => rdc reset group definitions. All Primary resets are grouped into 1 group, while each functional reset is grouped into it's own separate group.
source reset_groups.tcl => source above file

An ex of env file:

set_hierarchy_separator . => here . is set as hier separator (Default is /)

create_waveform -period 10 -transition {0 5} CLKA_W
create_waveform -period 10 -transition {0 5} CLKB_W
create_clock -waveform CLKA_W clkA => creates clk on clkA pin/port/net with waveform CLKA_W
create_clock -waveform CLKB_W clkB

create_reset -interval 10 -low -async {reset_n} => specifies "reset_n" is primary reset (default), and is active low. -interval specifies the length the reset to be held active and should be set to lowest possible length (i.e. number of clock periods) that meets the design requirements. Here, it's set to 10 clk cycles. We can also specify waveform of reset pin using -waveform, but most of the times it's not needed, as it's simple state change. -async specifies that the waveform of this reset is to be automaticaly generated by the tool and is async to all other waveforms (generally true). -waveform and -async are mutually exclusive, so only 1 of them should be used.

create_reset -functional -low [get_object_name mod1/sync2/Q] => specifies sync2/Q is an internal reset, which is active low (by default it's active high)

create_input -async {PI_7} => associates waveforms for primary i/p. However, when we don't want to specify a waveform using -waveform, we use -async to indicate that waveform on this object is to be automatically created by the tool, and should be async to receiver (i.e capture clock waveform).

create_input -waveform CLKA_W {PI_1} =>Here we specify a waveform on PI_1.


set_constant -value 1’b0 jtag_pin_1 => All remaining i/p ports are assigned constant values (instead of waveforms)
set_constant -value 1’b1 mod1.gmi_mode => constant can also be set on internal nets and pins.

set_initial_value -interval 10 -value 1'b0 PI_3 => sets initial value on an i/p or inout port for specified interval. At end of interval, signal can take any value at any interval of time (independent of clk edge). This cmd is useful for design inittialization, but is seldom used, as usually we have waveform specified on i/p pin (clk and reset pins are enough)

set_stable_value PI_EN => makes a given port or net's value unchanged from first value that it gets. Thus it's different than above cmd, as we do not specify it's value, but is derived based on deign. After that, the value doesn't change. Thus this cmd excludes given signal from verification, as the signal remains stable, so is not verified during reset analysis. Used frequently for dft signals to cut down on unnecessary noise in results

 set_reset_scenario -name rst_scenario_1  { {reset_n {reset {@t0 0 ->t1} }} {reset_core {reset {@t1 1} }} } => this cmd is used to define resets that work together with other constraints. One command per scenario is needed. While processing a reset scenario, the resets are asserted and de-asserted as specified in the scenario. All reset signals that are not specified in the reset scenario being processed are considered to be in an unknown state (i.e. X). Here, we give the scenario a name "rst_scenario_1". Then we specify the behaviour of reset signals in this scenario. We specify behaviour of each reset signal. Any reset signal not defined in this scenario has a value of X. Here 2 reset signals: reset_n and reset_core are specified with thier behaviour. PI reset_n is specified as reset signal (signal can be either reset or constraint type), @t0 indicates an event at time 0, when the signal "reset_n" changes from x to 0. Arrow -> defines this event (when reset_n changes from x to 0) as t1, so that it can be used in other reset scenarios. Similarly PI reset_core is specified as changing from x to 1 at time t1 (which happens to be time 0). Other special characters as ^, v, # and $ are also used to specify delays. First edge of reset signal is treated as an assertion of reset for metastability checks. Subsequent edge of reset signal is treated as deassertion, but it doesn't matter for metastability checks as deassertion do not start metastability. We can have as many reset scenarios as we want by specifying "set_reset_scenario" multiple times.

set_rdc_false_path -from_scenario rst_scenario_1 => false path from specified scenario to all other. So, no RDC violations from scenario "rst_scenario_1" will be reported.

3. analyze intent => This step checks for correctness of spec provided in setup files. If step was not run, then an env file is created automatically via this cmd.

analyze_intent => all spec such as clocks, resets etc checked. Any problems reported under "MRDC_SETUP_CHECKS" Rule group

4. verify rdc => This is the step that does RDC verification of design.
verify_rdc => rdc structural analysis. Any problems reported under "MRDC_ANALYSIS_CHECKS" Rule group

#verify_rdc -db_model dut_block1-1-2-3-4 => When run with option -db_model, mrdc creates a reduced db with name=dut_block1-1-2-3-4, that doesn't have all design, but only that part that is needed to efficiently run rdc on this block. This is needed when we are running hierarchical flow (discussed below), which uses this lower level reduced db.

#read_rdc_db -block dut_block1-1-2-3-4 -name dut_block1-1-2-3-4 => This reads above created reduced db with name=dut_block1-1-2-3-4.db, for block=dut_block1-1-2-3-4 (dir=meridian_project/block_name/dbs/db_name.db).

source waivers_file => sources any waivers provided

report_policy -compat ALL -verbose -output full.rpt => reports for setup checks, waivers, analysis checks

5. exit => typing exit, quits the tool

Hierarchical flow for mrdc:

Here instead of running mrdc on top level design which may be very large and take days to run, we run mrdc on lower level blocks, dump the reduced db for these blocks. Then we run mrdc at top level, where we read these reduced db for lower level blocks. Tis saves significant run time and makes analysis easy to debug at top level, since lower level module issues are already cleaned up by this time (when we ran mrdc at block level, we try to get it clean, before running mrdc at top level). There may be some differences in violations being reported at top level hierarchical vs top level flat, as some design info is missing when we abstract models of lower level modules. All env files specified when running block level rdc, should be provided exactly the same when running top level runs, so that the constraints are the same, else the model may not reflect the right behaviour (as the model was created in the first place with those set of constraints, so if the constraints changed, then that model is not valid anymore).

IP abstraction: The same concept of hier run is applicable to IP for which we have verified rdc at IP level, and then we incorporate these IP in our design. We can create reduced db for these IP, and then use these reduced db when running rdc at higher level. We blackbox these IP or lower level modules when reading top level design, and then read their respective reduced db files only.

Top level hier run flow steps: Read design files for top level, then read rdc for block level, then provide constraints, and then analyze top level design

analyze -f chip_top.f => reads top level design

elaborate -black_box {dut_block1} => during elaboration, we blackbox lower level modules, since we are going to read their reduced db, instead of reading the whole design for these lower level modules

read_rdc_db -block dut_block1-1-2-3-4 -name dut_block1-1-2-3-4 => reads reduced db for dut_block1 with parameters 1,2,3,4

read_rdc_db -block dut_block1-5-6-7-8 -name dut_block1-5-6-7-8 => reads reduced db for dut_block1 with parameters 5,6,7,8

read_sdc, read_env, analyze_intent .... => Now run the flow as regular flow, and analyze results

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