I searched in net to get some materials for MVRC but can’t find anything, other than Synopsys website. So I thought that it may be useful for others at least if I write some of its basics that I learned, so that others can find some. These are something that I learned from the Synopsys mv tool user guide. There are chances of misinterpretation of some concepts, correct me if anything u come across like that here.
MVRC
MVRC = Multi Voltage Rule Check. It is a Synopsys tool (mvtools) that does this check. Be aware that MVRC doesn’t do any functional checks. It just checks whether the supplied UPF file and the Design file’s power connections are correct. Whether specials cells (isolation, level shifter, always on, retain register) are correctly inserted as per the given UPF file.
Role of MVRC:
Are LS/ISO (level shifter/isolation) cells really needed but not specified in the UPF?
Are LS/ISO specified but not needed?
Whether power pins correctly inserted?
Whether shut down domain blocking any signal that is supplying to always on domain?
Basics flow:
Below is the basic flow of MVRC
1.
Compile the UPF and Design files.
2.
Generate multi-voltage database. While doing this we
should pass liberty data base also.
3.
Generate physical multi-voltage database.
4.
Perform static verification using mvrc on the
design(using physical multi-voltage and multi-voltage database)
We can do mvrc in 3 ways as below:
1. RTL + UPF
2. Netlist + UPF
3. PGNetlist + UPF
UPF = Unified Power Format, it is an IEEE standard. You can find many materials for UPF in net.
PGNetlist = Power and Ground Netlist.
Before getting in to flow I like explain about .ini file. The .ini file is a file that contains some of the setup variables. This file will automatically picked up by the mvrc tool if we have this file in our working directory. If not it will take the default .ini file which comes with the mvrc tool itself. If we have that file somewhere else other than working directory we need to give its path using –ini switch.
NOTE: (FOR LIBRARY FILES) We need to set the search_path with the paths which contains .db file. MVRC can take only .db files not .lib files. After search_path we need to set the link_library with the library (.db) file name. If we have more than one we can give them (for both search_path / link_library) separated by space or colon (:).
The flow for all these types are almost same except a switch to run the mvrc design check. So below are the common commands, these commands have to be given without invoking mvrc shell.
è
mvcmp –upf <file_name>.upf
The first step is to compile the files. Here we are compiling the UPF file.
è
mvcmp <design_file_name/names>.v
This is also compiling part. We need to give the design file here. If we are doing with RTL then we can have the
entire design files path in a file and by using –f switch we can compile.
è
mvdbgen –top <top_module_name> -rc (-netlist/pgnetlist
Optional)
-rc is must for generating mvdb for mvrc
-netlist is for generating mvdb using netlist
-pgnetlist is for generating mvdb using pgnetlist
-bbox can be used to convert all the unresolved
modules errors to warnings
-ini <.ini file> if we have the .ini file
somewhere other than working directory
è
mvphydbgen –top <top_module_name>
è
mvrc –f <mvrc_commands_file_name>
Contents of the <mvrc_commands_file_name>
are given below for appropriate flows. Put
those commands in a file and give that file name here. This command invokes
mvrc shell and executes the commands which are in the file which we give here.
1. RTL + UPF: in this flow we have to give RTL and UPF files as input to the tool. The tool will check mainly for the correctness of UPF file in this flow.
read_db
read_phydb
check_design
–rtl
exit
In this case check_design executes the following commands and dump the
results in a single file (check_design.log).check_protection -critique -no_design_checks
check_retention –critique( if retention policy is defined in UPF)
check_retention -rail_order( if retention policy is defined in UPF)
check_architecture –signal_corrutpion( if roots are inferred from the design)
2. Netlist + UPF: In this flow we have to supply Netlist and UPF to the tool. The flow for this will be as similar to the previous, since the concept is same everywhere but with some small changes in the switches we give. Here is the flow:
read_db
read_phydb
check_design
–netlist
exit
In this case check_design executes the following commands and dump the
results in a single file (check_design.log).check_protection –intent
check_protection rail_order
check_special_cell placement
check_special_cell rail_order
check_retention –intent ( if retention policy is defined in UPF)
check_retention –reachability (if retention policy is defined in UPF345 Synopsys Low Power Verification Tools Suite User Guide
check_retention -rail_order(if retention policy is defined in UPF)
check_architecture –signal_corruption( if roots are inferred from the design)
3. PGNetlist + UPF: In this flow we have to supply PGNetlist(Power aware netlist) and UPF to the tool. This is very important flow since pgnetlist has the power related connections with it. Flow wise there isn’t much difference comparing the other two flows but this check completes the purpose of doing Multi Voltage Rule Check. Here is the flow:
read_db
read_phydb
check_design
–pgnetlist
exit
In this case check_design executes the following commands and dump the
results in a single file (check_design.log).check_protection_pg
check_retention_pg
check_switch_pg –functional
check_switch_pg –consistency
check_special_cell_pg
check_connection_pg
check_protection intent
check_protection rail_order
check_protection –functional
check_special_cell –placement
check_special_cell rail_order
check_retention –intent ( if retention policy is defined in UPF)
check_retention –reachability ( if retention policy is defined in UPF346 Synopsys Low Power Verification Tools Suite User Guide)
check_retention rail_order (if retention policy is defined in UPF)
check_switch
check_architecture –signal_corruption (if roots are inferred from the design)
No comments:
Post a Comment