VCS knowledge base

VCS and coverage by Aviral Mittal


As usual I am putting mixed unstructured infromation on yet another tool, this time it is VCS.

I believe that it will provide a lot of practical information for users than the user guides or any other tutorial

provides. Any questions, please write to me at avimit at yahoo dat com.



VCS is 3 step process

1. Analyze (vhdlan vlogan) This command complies the given code and checks for syntax errors.

2. Elaborate ( vcs or or or )

3. Simulate ( simv )



While using VHDL design files, a simulaiton file 'synopsys_sim.setup' is usually defined, which defines

the compiled vhdl library.

Example 'synopsys_sim.setup' file:

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

WORK > DEFAULT

DEFAULT : ./work

memlib : ./mem_lib

xm_bus_lib : ./xm_bus_lib

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

The first line maps the WORK library to a name 'DEFAULT', and the second line maps the 'DEFAULT' library

to a physcial directory called './work'.

The second line defines a library memlib which is mapped to a physcial directory called 'mem_lib'.



In the absence of any 'synopsys_sim.setup' file in your working directory, vcs will look for the same file in your home directory,

and if there is no 'synopsys_sim.setup' in your home directory, it will look for the same file in the tool installation directory.

The default 'synopsys_sim.setup' is in the tool installation directory, which maps the default work directory to '.'.

You will see complied VHDL files in '.' in case you dont have a 'synopsys_sim.setup' file.



Example vhdlan commands:



vhdlan -w memlib../../pid_filter/rtl/fun_pkg.vhdl

vhdlan -w work ../vhdl/state_machine.vhd

vhdlan ./state_machine_tb.vhd



Example elaboration commands:

vcs -cm line+cond+fsm+tgl+path pid_filter_tb

This steps generates an executable file which is named simv by default. This name can be changed.



Example simulaiton commands:

simv -ucli -do file.cmds

Contents of a simple file.cmds

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

run 1 ms

exit

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

simv -gui

simv -cm line+cond+fsm+tgl+path -gui

simv -g generics_file



contents of 'generic_file'

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

assign 1 /TOP/LEN

assign "OK.dat" /TOP/G1/vhdl1/FILE_NAME

assign (4 ns) /TOP/G1/VHDL1/delay

assign 16 /TOP/width

assign 4 /TOP/add_width

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



VCS can be a 2 step process if only verilog is being used

vcs [compile options]



Generating Makefile:

vcs -lca -makedepends=makefile state_machine_tb

It seems that the same above command is used to generate makefile, and to do an incrimental compliation.

Incremental compliation is enabled by default:



VCS commands

removing like ncrm

updating like ncupdate

hierarchy browsing using commands

dump values in a txt file like ncsim

how to define the hierarchy

forcing nets in simulation, syntax.



LEDA:

Latches, linting, cross clock domain checking. Can write the rule in leda.





setenv VCS_HOME < VCS_Install_Dir>

set path = ($VCS_HOME/bin $path)

syschk.sh -v : will tell about environment

vcs -doc

command_name -help



The simulation flow:

synopsys_sim.setup : to map logical and physcial libraries

vlogan

vhdlan

vcs

vsim



setenv SYNOPSYS_SIM_SETUP / : global preference

1 tools setup

2 home

3 current dir

4 $SYNOPSYS_SIM_SETUP



include: not sure.



WORK> logical_name

Example:

WORK > gate_lib

gate_lib : /libs/glib



LIBRARY_SCAN = TRUE
FALSE

ASSERT_IGNORE = NOTE

ASSERT_IGNORE_NOTE

ASSERT_IGNORE_WARNING

ASSERT_IGNORE_ERROR

ASSERT_IGNORE_FAILURE



TIME_RESOLUTION = 10 ps



ASSERT_STOP = NOTE
WARNING
ERROR
FAILURE
NOSTOP



RUNREAD =

run this file automatically when it starts.



show_setup



show_setup -lib



-v means file containing many modules

-y means directories where tech libs are



makedepends



-xlrm

uum : unified use model. $VCS_HOME/doc/uum.pdf



-ucli - Enable Tcl command-line interface

-debug : allows to dump waveforms

-debug_all : line debug

-cm : enable coverage options



vcs -makedepends =

gamke makefile



vcs -cflags ""

vcs -hsopt improve gate-level and debug simulation speed



vcs -debug_pp (post processing)

for tcl and gui

use

vcs -debug



checkpointing:



$vcdpluson

$dumpvars



vcs -debug +memcbk to dump say vhdl record types, which are not dumped by default

initial $sdf_annotate(...);

vcs -sdf=[min
typ
max]:instance_name:



-P $VCS_ROOT/include/hdl_xmr.tab for

hdl_xmr instead of init_signal_spy in modelsim



library synopsys;

use synopsys.hdl_xmr_pkg.all



above to use the signal_spy kinda thing



ncmirror I guess is an eq in cadence.



add_wave /E/UUT/T_BLOCK/HRS_OUT

scope /E/UUT/A_BLOCK

add_wave RESET : will add a wave from A_BLOCK as the scope has been set



-gv -Override run time VHDL generics

-do instead of -i : because gives more than -i

-i



-gv can also be used with vcs -gv, which will help in changing all generics instead of limited as in vsim -gv



Recommendation: Always analyze verilog first



vcs -cm line : enable line coverage





IF it crashes, to clean up do the following:

rm -rf physcial_lib_dirs/*, simv*, csrc*

OPTIMISE = FALSE -- In synopsys_sim.setup



vcs -gui -debug : only show if compilation is successfull

vcs -debug_pp

vcs -debug_all

vcs -debug=1
2
3
4(level of debug)



simv -gui : preferred way of doing it. I.E first create a executable.



vcs -assert dve -Enable assertion debug

dve -vpd



run -posedge my_sig



restart



help -ucli

help -gui



alias



dump -file -type VPD

dump -add /tb

dump -add -depth

dump

dump -fid -VPD0 -add * -depth 0



fid is a file identifier returned by command dump -file -type VPD

add '-aggregates' in the dump command for dumping multi dim arrays



vpd2vcd +morevhdl

+morevhdl will dump 'records' type as well.



//VCS coverage off

//VCS coverage on



vcs -cm

simv -cm



urg : unified report generator

urg -dir ./simv.cm -grade -report ./reports



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

VCS libraries for VHDL compilation

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



VHDL files are compiled into a library.

Usually the default library is 'work' which is mapped to your current working directory i.e "."



Usually you will see that this 'work' library path is changed by defining the work library in synopsys_sim.setup file



WORK > DEFAULT

DEFAULT : ./work_lib



Then other libs may be defined in the same file i.e synopsys_sim.setup file:



memlib : ./memlib

pkg_lib : ./allcompiledpkgs

xm_bus_lib : ./xm_bus_lib



Further observation about vhdl library and vhdl compliation:



vhdlan -work work fun_pkg.vhdl

OR

vhdlan fun_pkg.vhdl



which means that 'fun_pkg.vhdl' is complied into work_lib

when you see the contents of work_lib you will see files FUN_PKG.sim FUN_PKG__.sim



Now I have another file called

xmbus_master.vhd which intends to use 'fun_pkg' package from the work lib

i.e the xmbus_master.vhd has the following lines



use work.fun_pkg.all



now if I compile the xmbus_master.vhd like this



vhdlan -w xm_bus_lib xmbus_master.vhd



I would expect that the complier picks up fun_pkg from work_lib. But it DOESNOT!



Which emplies that 'work' in the statemetn use work.fun_pkg.all refers to the library xm_bus_lib, to which xmbus_master.vhd is being complied into.



On the other hand if I do the following



vhdlan -w memlib fun_pkg.vhdl



Then I use the following lines in xmbus_master.vhd



library memlib;

use memlib.fun_pkg.all;



then I compile xmbus_master.vhd like



vhdlan -w xm_bus_lib xmbus_master.vhd



Then things are FINE, this time the complier picks up complied 'fun_pkg' from the memlib.



So the conclusion is:



when using 'use work.abcd.all', 'work' refers to the current compliation lib given with -w option while compliling the file

containing 'use work.abcd.all' , and NOT to the 'work_lib' which is the default compliation lib





IMP CMDS:



show_setup -lib

show_setup



llib



llib -l pidf

It will show the source file, dependency files





vhdlan options:



-q : quite

-nc : supress the copyright message

-l : log file





VCS OPTIONS:



vcs -debug_all : to enable force/line debug etc.



vcs -o gives named output executable



VCS/Synopsys Code Coverage:



3 Step Process: (after vhdlan or vlogan)

Step 1: Include -cm option during vcs: This step makes sure that the selected code is complied for selected type of coverage

Example:

vcs -cm line+cond+fsm+tgl+path pid_filter_tb

OR

vcs -cm_tgl mda -lca -cm line+cond+fsm+tgl+path -debug_all pidf_tb

OR

vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file



Step 2: Include -cm option during simulation: This Step makes sures that simulator doesnot forget to collect coverage data during simulaiton

Example:

simv -cm line+cond+fsm+tgl+path -gui



Step 3: cmView : for gui based analysis : This Step will let you see coverage results in a GUI

Example:

cmView



Step 3: vcs -cm_pp : for batch mode post processing. This step outputs report files

Example:

vcs -cm_pp -cm_report summary

This will generate human viewable reports in the simv.cm/reports directory.

it also writes a summary file in the same directory, named 'cmView.summary'







vcs -cm line
cond
fsm
tgl
path
branch
assert



Example command

vcs -cm line+cond pid_filter_tb



vcs -cm line+cond+fsm+tgl+path pid_filter_tb



adding -path gives an Error to avoid it use -lca



vcs -lca -cm path pid_filter_tb



And dont forget the -debug, in case you want to see anything : ).



vcs -lca -debug_all -cm line+cond+fsm+tgl+path pid_filter_tb



Still I have to face problems, so the final command line looked like:



vcs -cm_tgl mda -lca -cm line+cond+fsm+tgl+path -debug_all pidf_tb



Now simulaiton may be launched, again all the coverage options given at the 'vcs' compilation

MUST be given to the simv as well or there will be NO coverage recorded.

But then you cant use '-cm_tgl mda'. You see dont apply your common sense, or nothing will work.

After all vcs is developed by Synopsys not Google.



simv -cm line+cond+fsm+tgl+path -gui





NOTES:



-cm option creates simv.cm directory



During Simulation following files are produced:

test.line and test.fsm etc.. depending upon the coverage option.



To over ride the default 'test' name you can use

vcs source.v -cm line -cm_name test1

vcs source.v -cm line -cm_name test2 ...etc

OR

simv -cm line -cm_name test2

simv -cm line -cm_name test3 etc...







Also, during simulation, VCS and VCS MX write the cm.decl_info file

in either the simv.cm/db/verilog directory (for Verilog) or the simv.cm/

db/vhdl directory (for VHDL). cmView needs this file to show

coverage information.





If you invoke your binary executable from a different location, then

use -cm_dir option at runtime to specify the the path for the

coverage database directory



By default VCS does not compile the following for coverage:

• The source code in Verilog library directories

• Verilog library files

• Any module defined under the celldefine compiler directive





yv

For compiling for coverage source code from Verilog libraries.

celldefine

For compiling for coverage modules defined under the



vcs source.v -v mylib.v -y /net/libs/teamlib -cm fsm -cm_libs yv+celldefine



To prevent this lowering of coverage percentages, use the

-cm_noconst compile-time option

Constant filtering for toggle coverage is available only for

Verilog-only designs



simv -cm fsm -cm_log run1.log





Hierarcy in the design, and inclusion/exclusion of modules/files/instances.

-tree instance_name [level_number]

A level number of 0 (or no level number) specifies the entire

subhierarchy, 1 specifies only this instance, 2 specifies this

instance and those instances directly under this instance, and so

on



vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file



cm_hire.file contents

begin

line+cond+fsm+tgl+path -file ../../pid_filter/rtl/fun_pkg.vhdl

end

begin

line+cond+fsm+tgl+path -tree STATE_MACHINE_TB 1

end



Interesting observation

If I miss (all) coverage options on the command line, with this file its an error

If I miss (all) coverage options in the cm_hier.file, its an error.



Various hit and trials:

Works

vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file

simv -cm line+cond+fsm+tgl+path -gui

cm_hier file is:

begin

line+cond+fsm+tgl+path -module pidf

//The above line means exclude line, cond, fsm, tgl, path coverage from module pidf

end



Another example which worked

begin

cond+tgl+path -module pidf

end



I intended to exclude cond+tgl+path, and include the fsm coverage.

The above does write the fsm coverage, since fsm is not excluded from the list inside the cm_hier.file

NOTE: line coverage is always opened for modules or instances that have cond/path/fsm/branch coverage ON.



After several unsuccessfull runs to use '-tree' options, I concluded that it is 'case sensitive', even though i have a VHDL design,

and in my vhdl design pidf_tb, and pidf_u1 are lower case.

For some reason I am required to put the instance name in upper case

Following works

begin

fsm+line -tree PIDF_TB.PIDF_U1

end

BUT the following DoestNOT work.

begin

fsm+line -tree pidf_tb.pidf_u1

end



Now my objective is only to remove the top level testbench from coverage collection. For this I will have to use [level number]

begin

line+cond+fsm+tgl+path -tree PIDF_TB 1

//using level number 1 will make sure only the testbench level is excluded from the coverage collection

end



If I dont use the [level number] in front of PIDF_TB, then by default all scopes under PIDF_TB will be excluded from coverage

This is the same as using level number 0.



PROBLEM: while trying to use the -file option

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

Warning-[VCM-HFUFR] Hier Config: regions not found

In the hier config file ( given by -cm_hier option ), pattern "-file or

specified by -filelist ---

/projects/leota/amittal/block_design_flow_dev/pid_filter/rtl/pidf.vhd" did

not match any pattern.

Please check the hier config file "cm_hier.file".





Warning-[VCM-HFNM] Hier Config: No pattern match

None of the patterns in the hier config file ( given by -cm_hier option )

matched any pattern.

Please check the hier config file "cm_hier.file".

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



I have been trying to use -file option and above is the warning message. The corresponding cm_hier.file is

Note that I have used full path for the file I wanted to exclude. This doesNOT work.

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

begin

line+cond+fsm+tgl+path -file /projects/leota/amittal/block_design_flow_dev/pid_filter/rtl/pidf.vhd

end

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



Now if I use relative path, then vcs does not complain about the file and things go on fine: The corresponding cm_hier.file is

This Does Work.

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

begin

line+cond+fsm+tgl+path -file ../rtl/pidf.vhd

end

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



The HDL Compiler and Behavioral Compiler user can use the

//synopsys translate_off directive in place of the //VCS

coverage off pragma and the

//synopsys translate_on directive in place of the //VCS

coverage on pragma.

The //VCS coverage on pragma enables line coverage after a

//synopsys translate_off directive and a

//synopsys translate_off directive disables line coverage

after a //VCS coverage on pragma.

Similarly the //VCS coverage off pragma disables line coverage

after a //synopsys translate_on directive and a

//synopsys translate_on directive enables line coverage after

a //VCS coverage off pragma.



Pragmas do not exclude module instances. For example:

module test;

reg clk, a;

// Synopsys translate_off

mod1 inst1(a,clk);

// Synopsys translate_on

.

.

.

endmodule

This example does not exclude test.inst1 from coverage





--synopsys coverage_off or --VCS Cover off

--synopsys coverage_on or --VCS Cover on

--vhdlcoveroff

--vhdlcoveron



Glitch supression.

To prevent this, there is the -cm_glitch compile-time option. Its

syntax is as follows:

vcs -cm line+cond+tgl -cm_glitch period



The -cm_glitch option is also a runtime option, but it only works

for toggle coverage



Collecting an Execution Count

-cm_count compile-time option





Post Processing:

vcs -cm_pp -cm_report summary

The above command is used to post process the results of Code Coverage generated during simulaion.

This command produces results in simv.cm/reports directory.



Some more imp commands:

vcs -cm_pp -cm line+cond -cm_report testlists



NOTE:

The graphical user interface (GUI) for cmView does not display

path coverage information. You must have cmView write path

coverage reports



VCS and VCS MX do not monitor the if statement in the for loop

statement and the if statement in the user-defined task



Branch coverage is implemented for Verilog simulation only :(



NOTE:

By default VCS and VCS MX do not monitor for branch coverage if

and case statements and uses of the ternary operator (?:) if they

are in user-defined tasks or functions or in code that executes as a

result of a for loop. You can, however, enable branch coverage in

this code. See “For Loops and User-Defined Tasks and Functions”

on page 4



Assignment Coverage

-cm_line assigntgl compile-time option and keyword argument.

Note:

This is a Verilog-only feature. There is no similar report for VHDL



Glitch suppression does not work for VHDL code

Static Timing Analysis - Prime Time

How many minimum modes i should qualify STA for a chip
1. Scan Shift mode
2. Scan Capture mode
3. MBIST mode
4. Functional modes for Each Interface
5. Boundary scan mode
6. scan-compression mode

How many minimum process lots , should STA be qualified.

1. Fast corner
2. Slow corner
3. Typical corner
How many minimum Timing , Should STA be qualified.

1. normal delay mode(with out applying deration)
2. On-chip variation mode (deration applied)
3. SI mode (Signal integrity cross talk impact on STA)
How many minimum STA runs should we needed to address = 6*3*3.

A Typical RC script for Scan Insertion

read_netlist -top ahb_master

read_sdc ahb_master.sdc

set_attribute dft_scan_style muxed_scan

define_dft test_mode -name test_mode -active high test_mode

define_dft shift_enable -name scan_en -hookup_pin [find / -pin dft_fix/Z] -active high ahb_master/dft_fix/Z (if using an internal pin for scan enable)

define_dft scan_chain -name chain1 -sdi -sdo -shared_out -shared_select test_mode

(assuming that you are using shared scan input and scan outputs)

check_dft_rules

report dft_registers > dft_reg.rpt

report dft_setup > dft_setup.rpt

set_attribute dft_max_length_of_scan_chains

synthesize -to_mapped

connect_scan_chains -preview -auto_create_chains

connect_scan_chains -pack

report dft_chains > chain.rpt

write_hdl >

write_script > dft.tcl

write_atpg -mentor

I have found that the RC tool does not write out a really useful testproc file
I will soon upload a proc file, keep watching

DFT Adviosr typical do file

analyze control signals -auto_fix

set system mode dft
setup scan identification full_scan

setup test_point identification -control 0 -observe 0 -noverbose
run
report statistics
report sequential instances -unidentified -nonscannable
write scan identification seq_inst_rpt -replace -identified -defined_scan
insert test logic -scan on -test_point on -ram on -number 1 -hierarchical off
write netlist -replace
write atpg setup -replace

Please Note

Take care while using the dont_touch attribute when there are gated clocks in the design

Good Question

What are Top Down and Bottom Up compile methodologies in Synthesis?

In top down compile methodology you start compiling from the top of the design hierarchy. Whereas in the bottom up compile methodology we start building from the bottom of the design hierarcy. In general we go for the top down compile method.

Why should we not use tri-state logic arbitrarily?

Tri-state logic reduces testability
Tri-state logic is difficult to optimize - since it cannot be buffered leading to max fanout violations and heavily loaded nets

However tri-state logic can provide significant savings in area.

To Do

Look for Synopsys application notes on coding guidelines