- Details
- Published: Wednesday, 26 September 2018 05:22
- Hits: 8498
History of Simulators
Verilog-XL (from Gateway design) was the 1st and only verilog simulator available for signoff in early 1990's. Cadence bought it, but ended support at Verilog-1995. It developed it's own compiled code simulator (NcVerilog). Docs from cadence still refer to Verilog-XL when talking about Nc-Verilog. Modern version of NcSim family is IES and recommended for newer projects. However, as of 2018, IES is replaced by even newer simulator Xcelium. VCS (Verilog Compiled code simulator, 1st SystemVerilog simulator) from Synopsys and ModelSim (ModelTech simulator, 1st VHDL simulator) from Mentor Graphics are the other two qualified for ASIC signoff. All 3 support V2001, VHDL-2002 and SV2005. Modelsim is implemented based on interpreter, so it's much slower compared to VCS and NC-verilog which are based on compilers.
Cadence Simulator: Incisiv Enterprise Simulator (IES) 9.2, verilog-XL (ncverilog) 9.2 from Cadence is the latest simulator (as of 2019). Now as of 2021 Xcelium from Cadence is widely used.
Cadence IES simulator:
Cadence Incisive sim (IES) is based on cadence's interleaved native compiled code arch (INCA is extension of native complied code arch (NCA). With INCA, we can verify multiple languages (verilog, VHDL, SV, Specman, SystemC, Verilog AMS, VHDL AMS, C , C++, SPICE files, etc), multiple levels (behavioral, rtl, gates), multiple paradigms (event driven, cycle based), mixed signals (digital, analog)) which provides high accuracy with accuracy of event driven simulation (found in interpreted and compiled code tech).
In an NCC simulator, a parser produces an intermediate representation of the input source text. This intermediate representation is then processed by a code generator that produces relocatable machine code that runs directly on the host processor. For example, in a Verilog/VHDL configuration, both the Verilog and VHDL compilers are used to generate code for the Verilog and VHDL portions of the design, respectively. During an elaboration process similar to the linking used in computer programming, the Verilog and VHDL code segments are combined into a single code stream. This single executable is then directly executed by the host processor.
For RTL designs, a min of 64Mb is required while for gate simulation of 150K gates, min of 128Mb mem reqd.
Simulator supports IEEE 1364-2001 std for verilog, OVI 2.0, and verilog XL. System Verilog extensions to verilog as defined in IEEE P1800 std also implemented. We use compiler (ncvlog) and than elaborator (ncelab), which are integrated into IES. When we compile and elaborate a design, all internal rep of cells and views reqd by simulator are contained in single file stored in lib dir. Compiler will automatically create a default work library called worklib in a directory called INCA_libs, which is under the current directory. All design units are compiled into this library.
Cadence Xcelium simulator:
Early simulators processed verilog code in single thread, managing a single active queue of events. This serial methods resulted in significant run time. Xcelium simulator is basically same as IES, except that it can be run in single core or multi core configuration. Multi core configuartion can shorten runtime considerably, by breaking dependency on RTL/gate designs into indep parts, and simulate these parts using independent threads on parallel processors. Xcelium partitions design into accelerated (ACC) and non accelerated (NACC) regions. ACC region contains RTL/gate design, which can be run as parallel threads, while NACC region contains behavioural portions such as testbench, behavioural (model) memories, etc which are run by single core engine. This multi core engine compiler is invoked by passing option "-mcebuild". Compiler will automatically create a default work library called worklib in a directory called xcelium.d, which is under the current directory. All design units are compiled into this library, as well as other libs explained later.
Example of simple design, testbench and testcase:
//simple verilog code that will compile and run: tb.v. To run it, use cmd: irun tb.v
module tb();
int a;
initial begin
$display("a=%d",a);
//$finish; => this not needed as there's only this file with initial, so nothing is running forever
end
endmodule
//to run a simple module, create a tb, and change signals at module i/p pins using initial block.
// To run it, use cmd: irun tb.v Top_module.v +access+r -timescale 1ns/1ps => access option needed so that waveforms can be dumped.
module tb(); => brackets optional
int a;
reg b,c; //reg neded as wire can't be assigned in always blocks
Top_module I_top (.IN1(b), .IN2(c)); //top module connections => preferred way
//assign Top_module.IN1 = b; assign Top_module.IN1 = c; => instead of instantiating Top_module as in above line, we can also directly connect pins to nets. NOTE: since IN1,IN2 are nets, "always *" won't work, since it needs regs. so, we use assign.
initial begin //to apply i/p stimuli and to end sim. Usually this whole block is placed in tc_1.v file, so that we can apply diff stimuli for each testcase
#100 b=1'b1; #200 c=1'b0;
$display("b=%d, c=%d",b,c);
$finish; => this should be last stmt as after this stmt, tool exits
end
//dump waveform in vcd format. To dump fsdb (novas proprietary format, but used by almost all vendors), we need other system task defined later.
initial begin //to dump vcd files for all modules. Does not matter in which module it's placed, it still dumps for all modules.
$dumpvars;
$dumpfile("tmp.vcd");
$dumpoff;
#3150us; //dump vcd starting from 3150us
$dumpon;
#600us; //end dump at 3750us
$dumpoff;
end
initial begin //other way to dump
#1000; //start of dump
$dumpvars;
$dumpfile("/sim/ACE/.../tmp.vcd");
#2000;
$dumpflush; //end of dump
end
endmodule
Running simulator: 2 ways.
- Multi-step: First compile (different compilers for diff src files), then elaborate then run simulator. Here all these steps are run separately. Not recommended.
- Compiler: We have different compilers for VHDL and Verilog. ncvhdl is VHDL compiler, while ncvlog is Verilog compiler.
- ncvhdl cmd: ncvhdl vhdl_src_files => ncvhdl is VHDL compiler. run ncvhdl -help to get other options
- ex: ncvhdl -V200X -messages -smartorder a.vhd b.vhd => enables V1993 and V2001 features (use -V93 to enable only VHDL 1993 features), print informative msg, and compile in order independent mode
- ncvlog cmd: ncvlog verilog_src_files => analyzes and compiles verilog src. performs syntax check on HDL design and generates intermediate representation, in lib database file called inca.architecture.lib_version.pak (architecture=lnx86)
- ncvhdl cmd: ncvhdl vhdl_src_files => ncvhdl is VHDL compiler. run ncvhdl -help to get other options
- Elaborator: Elaborates the design. ncelab is the elaborator provided by Cadence that elaborates the design compiled by compiler above.
- ncelab cmd: ncelab top_level_design_unit => elaborator takes lib cell:view of top level as i/p, and constructs design hier, establishes connectivity, and computes the initial values for all of the objects in the design. It creates a m/c code and snapshot where access level is no rd,wrt or connectivity access to simulation objects, That means we won't be able to probe these objects outside of HDL which is OK in regression mode, but we need to set it to rd access in debug mode.
- Simulator: Simulates the design using the test case or patterns provided.
- ncsim cmd: ncsim snapshot_name => The simulator loads the snapshot generated by the elaborator, as well as other objects that the compiler and elaborator generate that are referenced by the snapshot. The simulator may also load HDL source files, script files, and other data files as needed.
- ex: ncsim -run worklib.top:module => NOTE: Using -gui option with ncsim starts simVision. That brings up Design browser and Console. Then we can run ncsim cmds on the Console.
- ncsim cmd: ncsim snapshot_name => The simulator loads the snapshot generated by the elaborator, as well as other objects that the compiler and elaborator generate that are referenced by the snapshot. The simulator may also load HDL source files, script files, and other data files as needed.
- Compiler: We have different compilers for VHDL and Verilog. ncvhdl is VHDL compiler, while ncvlog is Verilog compiler.
- Single step: Here all the steps from above are run as part of one cmd. This is much more convenient. There are 3 different variants here depending on the simulator that you have from Cadence. Either we use ncverilog or use irun/xrun (irun for IES and xrun for xcelium). NcVerilog is run in single step by using ncverilog on cmd line. irun/xrun is very similar to ncverilog, but in addition to verilog/system verilog, it can also accept vhdl, systemC, AMS, etc. Since irun/xrun run all steps, that have a lot more options each of which are specific to the tool that is being invoked. So, we should refer to those tools (i.e ncelab, xmsim, etc) for the specific options that are supported. irun/xrun are not case dependent (i.e -nolog same as -NoLoG). Also, short version of cmd line options allowed (i.e -nowarn same as -now, various options support varying num of min char required for that option to be recognized in it's short form)
- ncverilog: ncverilog does what multi step simulation does by invoking ncvlog, ncelab and ncsim for you. It lets us run NC-verilog simulator exactly the same way that we ran Verilog-XL (verilog-XL was run using cmd "verilog" on cmd line). All cmd line args are same as those of verilog-XL. On top of this, ncverilog also allows us to include ncvlog, ncelab and ncsim options on cmd line in form of + options. It also suppports manymore + options than verilog-XL.
- irun: It's for use with IES simulator. specifies all files on single cmd line. In ex below, top.v and sub.v are compiled by ncvlog using option -ieee1364, middle.vhdl is compiled by ncvhdl using option -v93, verify.e is recognized as specman e file and compiled using sn_compile.sh. After compiling all these, ncelab elaborates design using -access +r option (to provide rd access to simulation object, else in vcd/fsdb dump file, we won't see all wires,reg,etc) and generates sim snapshot. ncsim is then invoked with both SimVision (comprehensive debug env which includes design browser, waveform viewer, src code browser, signal flow browser,etc) and Specview gui.
- ex: irun -ieee1364 -v93 +access+r +neg_tchk -gui verify.e top.v middle.vhd sub.v
- ex: irun a.v b.v top.v tb.v => simplest cmd to run all rtl and tb files
- xrun: very similar to irun. It's for use with Xcelium simulator. However, compilers here are xmvlog, xmvhdl, sn_compile.sh. xmelab elaborates design, while xmsim simulates the design (xm means xcelium, while nc meant ncverilog which was used earlier in IES). xrun uses xmsc_run compiler i/f to compile c/c++ files. These compiled files, along with any other object files provided on cmd line, are then linked into single dynamic library, that is then automatically loaded before elaboration of design.
- ex: xrun -ieee1364 -v93 +access+r +neg_tchk -gui verify.e top.v middle.vhd sub.v => NOTE: how all args are same as those of irun
Sequence of steps when running the Simulator:
NOTE: Both irun and ncverilog finally run ncsim which runs simulation cmds. Using -gui option brings up SimVision on ncsim cmd prompt. When running irun/ncverilog, this is what appears on screen:
1. ncvlog/ncvhdl: analyzes and compiles each source file. => done only when any file changes, else it's skipped
ex: file: ../models/CFILTER.v
module worklib.CFILTER:v
errors: 0, warnings: 0
2. ncelab: elaborates files and constructs design hier from top level design units. It auto figures out top level design units based on if they are referenced elsewhere. Usually digtop_tb and testcase_name_tc are top level design units as they aren't referenced anywhere else. Then it generates native compiled code for each module and then provides design hier summary. It finally writes the simulation snapshot, which is a file that has all info for sim to run on it (w/o needing any info from anywhere else). elaboration step is run only when any file changes, else it's skipped
ex: Elaborating the design hierarchy:
Top level design units:
digtop_tb
S1_main_hunt_tc
Building instance overlay tables: .................... Done
Generating native compiled code:
S1.AFE_AGC_S1:v <0x17bc2126>
streams: 28, words: 11022 < and so on for each module ....>
Building instance specific data structures.
Loading native compiled code: .................... Done
Design hierarchy summary:
Instances Unique
Modules: 1 1
Registers: 3 3
Initial blocks: 1 1
Writing initial simulation snapshot: worklib.tb:sv
Loading snapshot worklib.tb:sv .................... Done
3. ncsim: loads the snapshot generated above and runs ncsim. ncsim prompt appears. It first source ncsimrc file (this file is needed by ncsim for displaying rc files). Then it puts "run" cmd, and then on encountering $finish in any module or on reaching end of all "initial" and having no "always" or other infinite loops, it puts "exit" cmd to exit ncsim.
ex: ncsim> source /apps/cds/incisiv/12.20.018p2/tools/inca/files/ncsimrc => this file aliases run as "." and exit as "quit", so that . will also work instead of run, and quit will also work instead of exit.
ncsim> run .... (displays stmt which have $display ...)
ncsim> exit
----------------
NOTE: In verilog-XL(ncverilog) and irun, many cmds in ncvlog, ncelab and ncsim which are preceeded by "-" are replaced by +.
ex: ncvlog -define arg1 => in ncverilog/irun, it's irun +define+arg1
Help:
>irun -helphelp
>irun -helpall
NOTE: to get help on any error that we see on running irun, we can type this:
Ex: error ncelab: *E,CUVRFA: blah ... shows up. To get more info type: nchelp ncelab CUVRFA
Ex: If error happened in ncvlog, type: nchelp ncvlog CUVRFA
RTL and Gate Simulation setup:
Dir: /db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/
3 subdir:
--------
tb: testbench dir. It has top level tb file (digtop_tb.v). digtop_tb.v defines a top level module digtop_tb, includes file all_tasks.v & xfilter.v, does initial begin .. end, and then instantiates module digtop and calls this dut, and connects all tb_* signals to appropriate digtop pins.
tc: testcase dir. It has test cases for different tests. i.e for interrupt block, it has interrupt_tc.v. Remember, any signal that you specify in tc should be an i/o port of a module or block, as internal net names may get renamed in gate synthesis, so even though the testcase may run on RTL, it'll fail to run on gate netlist.
sims: This is the main dir to run gatesims or RTL sims.
RTL:
-----
Build RTL dir:
run_rtl_sims (verilog) => script to run verilog RTL sims
----------------------
#we need to be able to run debussy to debug, so we provide a link to provided compiled lib from Debussy (if PLI app from Debussy has already been compiled into dynamic shared lib as is the case here) to provide bootstrap dynamic linking. Then user defined bootstrap fn can be accessed using load* (loadpli1, loadvpi, etc) in irun (or Nc simulator). This PLI defines functions such as $fsdbdumpvars and $fsdbdumpfile, which are needed for dumping fsdb files (note functions for vcd dump don't require this PLI, since they are supported by default by all simulators).
#for linux OS
set DEBUSSY_PLI = "+loadpli1=/apps/novas/debussy/5.2_v21/share/PLI/nc_xl/LINUX/xl_shared/libpli.so:deb_PLIPtr"
#for SOLARIS OS
#set DEBUSSY_PLI = "+loadpli1=/apps/novas/debussy/5.2_v20/share/PLI/nc_xl/SOL2/xl_shared/libpli.so:deb_PLIPtr"
irun -9.20.039-ius \ => specifying version of irun is optional. default is chosen based on ame if nothing specified. (running "irun -version" returns the version of irun being used)
$DEBUSSY_PLI \ => loads debussy PLI
-y /db/pdk/lbc8/rev1/diglib/pml30/r2.5.0/verilog/models \ => -y for dir. All gate verilog included incase we've any stdcells instantiated in RTL (usually clk gaters and mux/logic on clk/reset are hard instantiated)
#+incdir+../../tb/ \ => incdir option is used when we have `include "file1" in some other verilog file2. Then we have to include whole dir where file1 resides, else while compiling file2, we'll get an error about file1 not found. We don't need to compile file1 as `include will cause file1 contents to be included in file2. Note that if we try to compile file1, it may not compile as any verilog file to be compiled needs to have proper syntax (i.e file should have "module", "endmodule", etc. Many times in such include files we just have some verilog stmts, which is fine as these are just inluded in main file2 which already has module etc).
-y /db/Hawkeye/design1p0/HDL/Source/golden \ => instead of this, we could also use "-f rtl_files.f" which would have paths for each RTL file to be included
/db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/tb/digtop_tb.v \
/db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/tc/$argv[1]_tc.v \
-coverage ALL -covdut digtop -covoverwrite -covworkdir ./coverage/cov_$1 => puts coverage results in dir "/coverag/cov_$1/". says top level dut used for coverage should be "digtop" instance (we can also limit coverage to particular sub-module by using hier path for that instance(Not defn of module but instance of module)". It generates binary coverage data files (UCD) and coverage model files (UCM). coverage types can be code(block, expr, fsm, toggl) or functional(assertion, covergroup). "all" enables all code coverage types listed (B=>Block, E=> expression, F=>FSM, T=>Toggle, U=> fUnctional, A=>all. ex: we can wrt "-coverage BEFT" to enable all code coverage).
#NOTE: instead of using coverage cmds, we can also pass a .ccf cfg file which can have all cmds in there. i.e -covfile config.ccf. sample coverage.ccf file
select_coverage -all -module * => selects all coverage
set_libcell_scoring => IMP: sometimes we get no coverage results. Reason is coverage stops at libcells. Sometimes all modules treated as libcells whenever irun calls source dir with -y option (-y option is usually used with libcell dir). So, this "set_libcell_scoring" option forces coverage to be reported for all libcells too.
-l ./rtl_logs/$argv[1].log \ => -l (small letter L) is to specify logfile instead of default irun.log. We can also use /$1.log (as $1 and $argv[1] are same)
+nclibdirname+"$argv[1]_INCA_libs" \
+access+r \ => rd access so that all wires,reg etc can be accessed in vcd/fsdb files
+libext+.v \ => specifies extension of files referenced by -y option (+libext+extension). If this option not used, then files referenced by -y should not have file extension, else they will be ignored (very imp to use this wuth -y)
+licq \
#+sv \ => with -sv option, all verilog type files are compiled as SystemVerilog.
+notimingchecks \ => do not execute timing checks for $setup, $recrem, etc
-input dump.tcl \ => optional. needed for shm db dump. see in simvision section below for more details
+define+TI_functiononly \
+define+FSDBFILE=\\\"/sim/HAWKEYE_DS/kagrawal/digtop/rtl/$argv[1].fsdb\\\" \ => important to have \\\ before "
+define+FSDB \
+define+IMGFILE=\\\"/sim/.../a.img\\\" \ => this can be used in tb.v file or any other verilog file, to assign value from cmdline. i.e
`ifdef IMGFILE defparam tb.block1.PRELOADFILE=`IMGFILE; `endif
-svseed random \ => assigns random seed to all $urandom fn
+nctimescale+1ns/1ps => default timescale to use if no timescale defined anywhere
#-work: by default, irun compiles all design units in HDL files in work library called worklib (located within INCA_libs dir). We can change work lib name by using -work.
#dir structure is:
INCA_libs/irun.nc/xllibs/models,golden => for models dir, golden dir, etc specified with -y above stored in xllibs
INCA_libs/worklib/.inca*db, inca*pak => contains all compiled units as one file in .pak lib database. within worklib dir, we have subdir for std,ieee,worklib,synopsys,etc which have their own .pak database.
#-linedebug: to get debugging info
run_rtl_sims (mixed: tb is in verilog but src files are in vhdl/verilog)
----------------------
remains same as above (i.e same as running verilog rtl sims)
The only difference is that novas fsdb dump doesn't work on vhdl src files (i.e it only shows signals for verilog files in waveform, but not for vhdl files). Option is to dump vcd file, as vcd file will always have all signals. Other option is to set DEBUSSY_PLI to newer version of novas (in run_rtl_sims file) as follows: (doesn't seem to work ?)
DEBUSSY_PLI = "+loadpli1=/apps/novas/debussy/2010.04/share/PLI/IUS/LINUX/boot/debpli:novas_pli_boot"
run vhdl rtl sims: /db/MOTGEMINI_DS/design1p0/HDL/Testbenches/digtop/sims/run_rtl_sims
-----------------
#for fsdb dump
In tb/tb_spi.vhd file, put "use WORK.novas.all;" at the top before entity declaration, and also add this directive:
process
begin
`ifdef FSDB
fsdbDumpvars(0,":");
fsdbDumpfile("test.fsdb");
`endif
end process;
#above code, always dumps fsdb file as dump.fsdb in current dir. So, we can instead run this to dump into specific file:
#create file nc.do and then call this file from irun cmd line by adding this option: -input nc.do \
call fsdbDumpfile /sim/HAWKEYE_DS/kagrawal/digtop/rtl/SPI.fsdb
call fsdbDumpvars 0 :
run => if we don't add this line, then ncsim stops at cmd prompt, and we have to type run on the prompt to continue
-----------
#run_rtl_sims (vhdl):
#LD_LIBRARAY_PATH needs to be set
#solaris
#setenv LD_LIBRARY_PATH /apps/novas/debussy/5.2_v21/share/PLI/nc_vhdl/SOL2:$LD_LIBRARY_PATH
#linux
setenv LD_LIBRARY_PATH /apps/novas/debussy/5.2_v21/share/PLI/nc_vhdl/LINUX:$LD_LIBRARY_PATH
#note, here we specified debussy_pli with path separately defined above, while for verilog, it was all in one line.
set DEBUSSY_PLI = "-loadpli1 debpli:novas_pli_boot"
#we may also add -loadcfc option above, to get rid of some system errors:
#set DEBUSSY_PLI = "-loadpli1 debpli:novas_pli_boot -loadcfc debcfc:novas_cfc_boot"
#irun (same as for verilog, except -top,relax,V93 options used)
irun \
$DEBUSSY_PLI \
-y /db/pdk/lbc7/rev1/diglib/msl270/r3.0.0/verilog/models \
/apps/novas/debussy/5.2_v21/share/PLI/nc_vhdl/LINUX/novas.vhd \
#/apps/novas/debussy/2011.01/share/PLI/IUS/LINUX/boot/novas.vhd \
/db/MOTGEMINI_DS/design1p0/HDL/Source/spi_typedefs.vhd \
/db/MOTGEMINI_DS/design1p0/HDL/Source/spi_control.vhd \
/db/MOTGEMINI_DS/design1p0/HDL/Source/spi_regs.vhd \
/db/MOTGEMINI_DS/design1p0/HDL/Source/spi.vhd \
/db/MOTGEMINI_DS/design1p0/HDL/Testbenches/digtop/tb/tb_spi.vhd \ =>
-top E \ => for vhdl, top entity has to be declared (this top entity is in tb/tb_spi.vhd)
-relax \ => to relax strict vhdl requirements
-V93 \ => since our vhdl is 1993 format
-input nc.do \ => use this, if we call fsdb cmd in nc.do isntead of fsdb cmd in tb_spi.vhd
-l ./rtl_logs/$argv[1].log ... => other options same as those for verilog
-------
#for vhdl and SystemC files, you have to specify the top level with -top option, as simulator does not automatically calculate top-level VHDL/SystemC design units. However, with this option, autodetection of top level verilog modules is disabled. (-vhdltop and -sctop specifies VHDL top level and Sc top level, but doesn't disable auto calculation of verilog top level units)
-top [lib].cell[:view] => specifies top level unit, can use multiple -top options to specify multiple top-level units
Ex: -top E \ => entity E is defined in top level testbench file tb_spi.vhd, which calls top level source entity spi.
#for vhdl, IEEE 1076 standard does not allow for multiple choices (i.e. 0=>'1', OTHERS=>'0') in an array aggregate that is not locally static (i.e. VECTOR(size-1 downto 0) has a variable range). If you make the range of the array static (e.g. VECTOR(3 downto 0) or provide only one choice (e.g. OTHERS=>'0'), then the code will compile correctly. Cadence has adjusted ncvhdl with a switch named '-relax' which relaxes a variety of LRM rules, and alows code to compile.
-relax \
#we can also use option -V93 to force irun to compile with VHDL93 syntax.
GATE:
----
gate sims run on gate level netlist, which has all nets as "wire". If there's a net which is i/o port of module, it has to be connected through a "wire" at higher level to another i/o port of some module, or to i/o port of top level module. All these "wire" have parasitics associated with them in spef file, and hence delays associated with them in sdf file. Some nets appaer as "wire", but during optimization, they are not used for connections (like instead of Q pin of flop, QZ pin is used sometimes, which results in net associated with Q pin to be floating). such nets even though listed as "wire" don't have any parasitics and are reported as "unannotated nets" during sdf file generation (in PT).
We do timing checks when running gate sims. This may cause non-convergence in simulator for cases where there are -ve setup/hold times or -ve rec/rem values in sdf file. see in verilog.txt.
--------------------------------
GateSim (for verilog testbench):
--------------------------------
For gatesims, we do xfiltering for meta flops, and we do sdf annotation for all nets/cells. We add this in digtop_tb.v in b/w "module ... endmodule", whenever SDF_MAX or SDF_MIN is defined.
digtop_tb.v:
1A. xfilter: include "../tb/xfilter.v" => In this file, we define Xon parameter for all meta flops to be 0. On doing this, setup/hold check is turned off for this flop, so that we don't see these warnings: "Warning! Timing violation $setuphold<setup> ( posedge CLKIN:65071 PS, posedge EN:65077 PS, 0.248 : 248 PS, 0.041 : 41 PS );... Time: 6548 PS" for that flop. Here, numbers shown are setup of 248ps(min:typ:max), and hold of 41ps(min:typ:max). When only 2 values shown instead of triplet, that means sdf file had only 2 values. Here CLK and EN comes within 6ps (65077-65071) causing a viol.
ex: defparam testbench.Idigtop.Ideglitch.mota_itrip_deg.sig_meta_reg.Xon = 0; => This Xon parameter = 1 in model of flop (in ifdef TI_verilog section of DTCD2.v flop). So, by default X is propagated, but if we set Xon=0, then X is not propagated. X value in that meta flop is forced to whatever RTL is modeling. That means whatever is the i/p of flop right before the clk edge is passed. If the i/p changes right on the clk edge, then the coding sequence determines which happens first, i/p change or clk edge. If we don't set Xon=0, then X's will get propgated to all logic eventually, and all our test cases will fail. By setting Xon=0, we force o/p of flop to be 0 or 1 always.
=> Next, in filtered_logs dir, we copy all log files from gate_logs dir, and search for any "Warning" msg using filter_warnings.pl script. We should not see any warnings as meta flops are the only ones that should have setup/hold viol. Any other viol is real, and should be fixed in design. Since we were timing clean, we should investigate if we had mistakenly set that path to a false path in PT/ETS.
1B. instead of xfilter.v file, we can also turn off timing check by using tcheck cmd by specifying it on irun cmd. (valid for irun versions 14.2 or later)
+nctfile+gate.tfile => arg to irun (no space in b/w "+")
ex: In gate.tfile, we put 1st sync flop for all synchronizers to be filtered out for x propagation. This also prevents tool from generating "Warning! Timing violation $setuphold ...". option 1A above may still generate warnings depending on library model written.
PATH tb_digtop.dut.sync_*.genblk1_S_sync1 -tcheck => turns off timing check for flop genblk1_S_sync1. Not sure, if it turns off all timing checks or just setup/hold.
NOTE: if running older version of irun, then the tool doesn't pick up thse tcheck and will throw this warning "ncelab: *W,TFANOTU (gate.tfile) tfile node ... was not used by design". This means tool discarded the tcheck, due to old version, etc, etc.
1C. we can also provide timing check file via "-input tcheck_off.tcl", which will have " tcheck -off" cmd for 1st stage of all sync flops.
ex: tcheck -off veridian_tb...i_sync_flops.u_sync.tiboxv_sync_2s_acn_sync_0
2. sdf_annotation: $sdf_annotate( .... ) for both max/min. see in sdf annotator section below.
Dir: /db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/gatesims
run_gate_sims_max => script to run gatesims for max delay
----------------------
#same as run_rtl_sims except netlist is gate level, neg_tchk, max_delays, define+TI_verilog used
set DEBUSSY_PLI = "+loadpli1=/apps/novas/debussy/5.2_v21/share/PLI/nc_xl/LINUX/xl_shared/libpli.so:deb_PLIPtr"
irun \
$DEBUSSY_PLI \
-y /db/pdk/lbc8/rev1/diglib/pml30/r2.5.0/verilog/models \
../../../Source/global.v \
../../../FinalFiles/digtop/digtop_final_route.v \ => gate netlist
../tb/digtop_tb.v \
../tc/$argv[1]_tc.v \
-l ./gate_logs/$argv[1]_max.log \
+nclibdirname+"$argv[1]_INCA_libs" \
+access+r \
+libext+.v \
+licq \
+sv \
+neg_tchk \ => allows neg values in $setuphold and $recovery timing checks in the Verilog description and in SETUPHOLD and RECREM timing checks in SDF annotation. This is needed, bacuse tools zero out -ve timing check numbers, as it may not converge and causes large performance issues. see in verilog.txt for more info on -ve timing checks.
+max_delays \ => Apply the maximum delay value if a timing triplet in the form min:typ:max is provided in the Verilog
description or in the SDF annotation.
-input dump_gate.tcl => optional. same format as for rtl sims.
-SDF_CMD_FILE sdf_max.cmd => optional. see sdf section below for details.
+nctfile+ gate.tfile => optional. turns off timing checks for specified gates. see above section for details.
+define+TI_verilog \ => TI_verilog uses models with delays
+define+FSDB \
+define+FSDBFILE=\\\"/sim/NOZOMI_NEXT_OA/kagrawal/digtop/gate/$argv[1]_max.fsdb\\\" \
#+define+VCD \
+define+VCDFILE=\\\"/sim/NOZOMI_NEXT_OA/kagrawal/digtop/gate/$argv[1]_max.vcd\\\" \
+define+SDF_MAX \ => SDF_MAX annotation used in top level module
+nowarnCUVWSP \
+nctimescale+1ns/1ps
run_gate_sims_min => script to run gatesims for min delay.
----------------------
same as for max, except +min_delays, +define+SDF_MIN used.
NOTE: after running gatesims with sdf_annotate, look in sdf_max.log to make sure it has no errors or warnings. Else, sdf is not correctly annotated.
----------------------------
GateSim (for vhdl testbench):
----------------------------
Dir: /db/MOTGEMINI_DS/design1p0/HDL/Testbenches/digtop/kagrawal/gatesims
run_gate_sims_max => script to run gatesims for max delay
#sdf compiled file generation (see below in sdf annotation)
ncsdfc /db/MOTGEMINI_DS/design1p0/HDL/FinalFiles/digtop/digtop_max.pt.sdf -output ./digtop_max.pt.sdf.X
setenv LD_LIBRARY_PATH /apps/novas/debussy/5.2_v21/share/PLI/nc_vhdl/LINUX:$LD_LIBRARY_PATH
set DEBUSSY_PLI = "-loadpli1 debpli:novas_pli_boot -loadcfc debcfc:novas_cfc_boot"
irun \
$DEBUSSY_PLI \
-y /db/pdk/lbc8/rev1/diglib/pml30/r2.5.0/verilog/models \
/apps/novas/debussy/5.2_v21/share/PLI/nc_vhdl/LINUX/novas.vhd \
/db/Hawkeye/design1p0/HDL/Source/golden/global.v \
/db/Hawkeye/design1p0/HDL/FinalFiles/digtop/digtop_final_route.v \ => gate netlist
/db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/tb/digtop_tb.v \
/db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/tc/$argv[1]_tc.v \
-l ./gate_logs/$argv[1]_max.log \
-input nc_max.do \ => look above in rtl sim for vhdl (it calls fsdb dump functions)
+nclibdirname+"$argv[1]_INCA_libs" \
+access+r \
+libext+.v \
+licq \
#+sv \
+neg_tchk \ =>allows neg values in $setuphold and $recovery timing checks in the Verilog description and in SETUPHOLD and RECREM timing checks in SDF annotation.
+max_delays \ => Apply the maximum delay value if a timing triplet in the form min:typ:max is provided in the Verilog
description or in the SDF annotation.
+define+TI_verilog \ => TI_verilog uses models with delays
+define+FSDB \
+define+FSDBFILE=\\\"/sim/HAWKEYE_DS/kagrawal/digtop/gate/$argv[1]_max.fsdb\\\" \
+define+GATE \
+define+SDF_MAX \ => SDF_MAX annotation used in top level module
+nowarnCUVWSP \
+nctimescale+1ns/1ps
run_gate_sims_min => script to run gatesims for min delay.
----------------------
same as for max, except +min_delays, +define+SDF_MIN used.
Waveform viewer and debugging system:
Many waveform viewer available to view the results of simulation. Some popular ones are as below:
- SimVision from Cadence: comprehensive debug env which includes design browser, waveform viewer, src code browser, signal flow browser,etc. It uses *.shm waveform database to store waveforms. Expensive license ($50K)
- Debussy from Novas (purchased by SpringSoft in 2008): The Knowledge-Based Debugging System. debussy is cheaper ($5K), but its superset Verdi is used, which is behaviour based debugger. It uses fsdb and vcd waveform database. All the cmds of Debussy are valid in Verdi. Debussy invoked by typing: debussy -f <cmd_file>. We use debussy, Release 2008.10 , Linux x86_64/64bit. (though it says it's using verdi 2008.10 version with 64 bits).
- Verdi from Novas (Verdi was a product of Novas, but was purchased by Synopsys): Verdi is superset of Debussy, costs more but has lot more features. invoked by typing: verdi -f <cmd_file>. Verdi is the recommended tool to use (instead of debussy).
All these waveform viewers need waveform in some format to display it. Two most common waveforms supported are as below.
- VCD: (value change dump), ASCII format for waveform dumpfiles. defined by IEEE std 1364-2001 and supports 6 value VCD format (orig 4 valued logic: 0,1,Z,X and later signal strength and direction added). widely used. The VCD file comprises a header section with date, simulator, and timescale information; a variable definition section; and a value change section, in that order.
- FSDB: (fast signal database), which is Novas' proprietary waveform dump format. It is much more compressed than the standard VCD format generated by most simulators. Novas provides a set of object files (using +loadpli) that link with all common commercial simulators to generate an FSDB file directly.
SimVision:
--------
Using -gui option with ncsim or irun/ncverilog brings up SimVision.
> irun -gui -f run.f -access RWC -linedebug (add "-uvmlinedebug" if running with uvm)
NOTE: "-access +r" or "-access RWC" is needed, else waveform dump won't show any signals (as they don't have read permission, r=read, w=write, c=connectivity to help with x propagation). Also, ncsim cmds for dumping waveform into cadence database (waves.shm) is needed in input script or on ncsim prompt. See below for details.
We can also directly type simvision to bring up simvision. We can then open "waves.shm" database.
simvision &
simvision -waves waves.shm -input digtop.svcf & => This will open up waves.shm database, with signal file digtop.svcf (similar to rc file in nWave). We can do "File->Source command script" to load svcf file or "save command script" to save svcf file.
Simvsion has a Design browser and Console.
1. Design Browser-simvsion: It allows to browse design. It shows modules, RTL, etc. NOTE: If we select signals on this, it won't show up in waveform window automatically. We have to do "send to waveform" to see them on waveform viewer.
2A. waveform-simvsion: To invoke waveform viewer, click on "send to waveform" on design browser of simvision (It's 2nd button after + sign on top right side). Imp cmds:
send to: => used to send values from waveform to RTL or schematic and vice versa
= => this zooms to fit waveform
2B. On waveform, to see delta time delay: take mouse to "yellow pulse shape", hold right click for a second, and a pop up comes. choose "expand time"->All_time. Then on waveform we see blue shaded area. The blue area shows what happens in delta delay time (you will see that time remains same in blue area, but numbers in brackets change implying delta delay)
3. Console-simvision: It's used to run ncsim cmds. It has ncsim prompt on simulator tab (It has 2 tabs on bottom: Simvsion and simulator). When we write "run" cmd on it, that it when it starts running sims. When we are not in Simvision gui mode, then run is automatically placed on ncsim cmd prompt, so that our simulation runs to completion. Then when completed, exit is automatically placed on ncsim cmd prompt to exit sim. If we want to stop sim when in cmd line mode, we can add "-tcl" to cmd line, and then tool will stop at ncsim prompt. We'll have to type "run" on ncsim prompt to continue. ex: irun -tcl -f run.f (stops at ncsim prompt)
Ex of ncsim cmd:
ncsim > database -event -open waves -into waves.shm => create shm database named waves.shm (which contains .dsn and .trn files, which are waveform dump). waves is the scope. "-event" provides zero time events to be seen on any signal, which is otherwise not possible to see. This helps detect edges happening with 0 width)
ncsim > probe -create -all -depth all -tasks -functions -memories -database waves -name probe_a => probe all signals, all depth and for all tasks,functions too. It does not probe memories (2-d,3-d array), so have to put -memories also.(also, if we run gui mode, w/o using -tcl, then memories are automatically added to probe). Put this probe data into database waves. If no name is provided for probe, then ncsim will name it probe 1, probe 2, etc. NOTE: in design browser, select Scope as "waves", and then you will all signals with values. By default, scope is "all available data" which shows simulator scope also (which may not have any probe data).
NOTE:To get extended vcd (which shows port dirn too), do this: (evcd needed to generate tdl files)
ncsim> database -open waves -evcd -into myvcd.vcde
ncsim> probe -create testbench.dut -evcd -database waves
Instead of above 2 cmds, we can also d this in Tb.sv file: initial $dumpports(UVMTb.I_dut, "sim.vcde");
nsicm > run => runs ncsim till it terminates. pgm terminates when $finish is reached in any module.
ncsim > run 2.5 ms => runs ncsim for 2.5ms
ncsim > exit => exits ncsim.
ncsim> reset => resets ncsim, so that we can run simulation again starting from time 0
NOTE: To rerun new rtl after modification, we can either close simvsion and rerun simulation again or from Console window we can click Simulation->Reinvoke Simulator. This reruns new rtl and loads new waveform.
NOTE: we can provide -input option with irun, specifying the input file, which gets loaded on ncsim prompt. This saves up from manually typing the ncsim cmds on cmd line. If we don't provide cmd for "database -open .." or "probe -create ...", then no cadence datanase is created. To create vcd/fsdb database, we have to provide system task "$dumpvars .." within "initial begin ... end" block to dump waveform database.
Ex: irun -access +r -f rtl_files.f -input dump.tcl .... => -access +r is needed to see signals in waveform dump
dump.tcl has these lines:
database -open waves -into /sim/bellatrix/kagrawal/waves.shm -default
probe -create -emptyok -database waves -all -memories -depth 10 digtop_tb => var in function/task not dumped by default. To dump those, use -variables.
probe -create -emptyok -database waves -all -depth 3 Silver_top.Xosc.I1 => This type of probe used for ams sims to dump voltages upto 3 levels deep
probe -create -emptyok -database waves -flow -ports Silver_top.Xosc.AVDD => This probes current at AVDD port of Xosc block. valid for ams sims, since digitl blocks (which are modeled as verilog) do not consume any current.
probe -create -emptyok -database waves -all -flow -depth 3 Silver_top.Xosc.I1 => This probes current for all nets upto 3 levels deep.
probe -create -emptyok -database waves -all -memories -depth 10 -domain digital => This is helpful in ams sims, where we do not need to specify path of digital block. It does probing upto 10 level deep of all nodes which are digital in nature (i.e have verilog models)
run
quit => this is executed after run has finished
----------
Xcelium (xrun):
--------
As discussed earlier, xrun is used to run designs on Xcelium Simulator. It does work similar to irun. All of the options for xrun same as those for irun. 2 imp help cmds for xrun:
> xrun -helpshowsubject => shows list of subjects as xmvlog, xmvhdl, xmelab, xmsim, etc
> xrun -helpsubject xmvlog => shows all options for subject xmvlog, as -assert, -ams, etc
> xrun -helpall -helpalias => -helpall displays list of every supported option, while -helpalias displays different ways to enter an option (ones entered using -/+ signs. irun/xrun use both "-" and "+" for cmd line options)
ex: xrun top.v test.c obj1.so -y ./libs -y ./models -l run1.log ... (source files can be in any format as .v, sv, .vhd, .e, .vams, .c, .cpp, .s, .o, .so, etc)
This is how dir looks like, when you run xrun: ex:
xcelium.d => instead of INCA_libs, this build dir created. Contents in this dir are automatically checked (timestamp, snashot info, etc) on rerun of xrun, to determine if recompilation or re-elaboration is needed. It has following subdir:
1. xcelium.d/run.<platform>.<xrun_version>.d (ex: xcelium.d/test_sim.lnx8664.19.01.d, instead of run, we created test_sim as custom name by using option -snapshot test_sim ). A soft link names test_sim.d is created by default pointing to this dir. Within this are subdir, is xllibs dir, which has subdir for each -y libraries and -v library files (i.e run.d/xllibs/<libs> and run.d/xllibs/<models> when cmd is "xrun top.v -y ./libs -y ./models ... ")
2. worklib => design files contained in HDL design files (as in top.v) are compiled in this dir. Usih option "-work <worklib_name>" changes name of this worklib dir. Within this dir is library database file called "xlm.lnx8664.066.pak" file, which stores all intermediate objects required by Xcelium core tools. These .pak files are large and so usually compressed by using -zlib option
3. history => There is history file which records all prev cmds run
options:
-64/-64bit => runs 64bit version of xrun
-top chipTb => defines top level module (can have multiple such cmds since there are typically multiple top level modules from uvm, design, etc). This option not needed for v/sv top level modules, but required for vhdl/systemC top level modules. By default, top level design units are automatically determined for v/sv, but are not automatically inferred for vhdl/systemC if top units are in these files. In such cases, this option is required
-l <logfile> => by default, log is written to xrun.log in same dir where xrun was invoked
-v libfile.v => old scheme of lib mgmt. xrun scans this file for module/udp defn that can't be resolved in normal src files specified. -v option causes module/udp in these files to be parsed, only if they have the same name as unresolved module/udp. Otherwise they are not parsed, which saves time. If we omit -v, then these module/udp in these files will always be parsed
-y <lib_dir> => specifies path to library dir, where files containing defn of module/udp are to be found
-define foo=2 => -define similar to using `define compiler directive in verilog. same as irun, can use +define+ also. If there's no value to assign, we can also do "-define foo".
-compile => parse and compile source files, but do not elaborate
-elaborate => parse and compile source files, elaboarte design and generate simulation snapshot but do not simulate. If -compile/-elaborate options not used, then all steps run (compile/elaborate/simulate)
-hal => this runs HAL (HDL analysis) on snapshot instead of running simulator. This is used to verify any errors/warninhgs etc on design files.
-snapshot <snapshot_name> => genrate sim snapshot with given name (-name or -snapshot are both same) in xcelium.d/worklib/<snapshot_name/*. By default, snapshot name are xcelium.d/worklib/run/*. This option also changes name of xcelium.d/run.lnx8664.19.01.d to xcelium.d/<snapshot_name>.lnx8664.19.01.d.
-r <sanpshot_name> => load and simulate specified snapshot, w/o doing any kind of checking. By providing "-input file1.tcl", we can provide diff tcl cmd i/p files to have multiple diff sims with same snapshot. -R (w/o any snapshot name) is used to simulate the last snapshot generated by xrun cmd.
-xmlibdirname <xcelime_dirname> to have custome dir name instead of xcelium.d. When running simulator only (using -r or -R option), we need to provide this, if snapshot is not in default dir path or default name.
-clean => this forces removal of dir xmlibdirname or xcelium.d and start fresh. This causes xrun to recompile, re-elaborate and recreate dir. In absence of this option, automatic checks are done to edtermine if this dir can be reused
-hdlvar /home/.../my_hdl.var => This var file is a configuration file that can have all cmd line options and args in 1 place (i.e DEFINE XRUNOPTS -ieee1364 -access +rw etc) . That way, the regular xrun cmd won't look lengthy and complex
-f <args_file> => We can also provide additional argument file that can have any args in it, name of source file, and everything else needed with xrun, which will be added to xrun existing args (i.e -clean source.v ...)
uvm cmd line options supported by xrun:
-uvm => enable support for uvm
-uvmhome /UVM/.../uvm-1.2 => specifies loc of uvm installation. By default, uvm is installed in <install_dir>/tools/methodology
-uvmexthome .../CDNS-1.2 => loc of cadence extensions to uvm. By default, uvm extensions are installed in <uvmhome>/additions/sv
. run_test() task in top level module calls this test to run+UVM_TESTNAME=<test_name> => specify name of test
Debussy:
---------
used to see waveform demp, and annotate it to rtl/gate so that debug is easier. It is also used to see schematic rep of rtl or gate, which helps to see connectivity. Gate schematic specially helps during ECO as we don't have to manually go thru verilog text file of digtop_final_route.v.
Debussy has following tools as part of the suite.
nTrace:
-------
gui that comes up to traverse design hier.can trace load, driver, connectivity. can change src code by choosing ur editor: tools->preferences->editor, and then choosing source->edit source file.
to import design, goto file->import design. Select "from file", set Virtual Top as "digtop", default dir as "/db/Hawkeye/.../FinalFiles/digtop", then in bottom LHS panel, goto dir "/db/Hawkeye/.../FinalFiles/digtop", then click on synthesized netlist "digtop_final_route.v" in RHS, and click Add. Then it shows up in design Files. Click OK. Now, you can see whole netlist in the top panel
active annotation: allows to view verification results in context of src code. But before using this, we need to load sim results (in FSDB file) using file->load simulation results. Then in hier browser, double click the instance that you want, choose source->goto->line, enter line number and OK. Then choose source->active annotation (or x key after putting the cursor in source code pane) to activate active annotation. values associated withj each signal are than displayed at time 0. Now we can do serach forward, backward for signals to change time.
nSchema
----------
gui that shows schematic.
Once you have imported design, goto tools->new scematic->current scope. Then schematic is drawn for whatever is selected as current scope in panel (current scope name also shows in the top window bar, it's set as whatever instance is selected, i.e digtop or interrupt etc).
In new schematic window, goto view->high contrast. This turns ON contrast for better viewing.
nWave
------
gui that shows waveform viewer:
nWave -ssf test1.fsdb => This loads the fsdb file directly
Load fsdb file: do file->open. then type name of dir containing fsdb file in white box. That shows the dir and files in that dir in two windows below. Select appropriate fsdb file in RHS window. click on Add, and then OK. This load the fsdb file.
get signals: click on "get signals" (next to open file drawing)
important settings:
1. Waveform->Snap cursor to transitions. when this is set, then when we click on any signal waveform, then the cursor goes to the next edge. Useful when doing active annotation in debussy, since the change shows up in rtl signal values.
2. Tools->Preferences. It has almost all settings for GUI. Thses settings remain there even on quitting nWave. Goto View Options->Waveform Pane. Check box "Highlight selected signals". This highlights selected signals.
3. To search for signal name, enter it in right hier and right case in "Find Signal). to search all hier, enter * at the end in "Scope", then it searches for everything under that hier. For ex:, if you are in digtop_tb hier, you will see "digtop_tb" in Scope. Just eneter * after that, i.e: /digtop_tb/*
4. To set an alias file fo state machine, etc, first select the signal that you want alias to be set to on the waveform viewer. Then select alias file as: waveform->Signal_value_radix->Add_alias_from_file, then choose the alias file and hit OK. alias file syntax is: states_timergen.alias
ALIAS timergen_sm
PT_RESET 4'b0000
PT_XG_INC 4'b0001
ENDALIAS
Verdi: superset of Debussy, as a lot more tools available.
------
nCompare - Waveform compare (compare rtl and gate level waveforms).
nSchema - Schematic browser(delay annotation).
nState - State Diagram Debugger (Displays the Bubble Diagram of state machines)
n Analyzer - Debug clock tree, clock and reset analysis,view multiple clock domains.
nEco - Evaluate the changes made on the fly and validate them.
SVTB - Gives the System Verilog Test Bench Inheritance view, class variables can be viewed synchronously with other signals on nWave.
Assertion Evaluator - Evaluates System Verilog assertions off line without the simulator.
Power Manager - Debug the UPF and CPF files and visualize the different power domains in the design
Temporal Flow Wiew - Brings time,value and hierarchy on the same window
Running Debussy:
--------------------
Dir: /db/Hawkeye/design1p0/HDL/Debussy/
#Before we can run debussy, we need to generate fsdb file and do sdf_annotation (for gate sim) in irun. fsdb generation is not necessary, since debussy can convert vcd into fsdb on the fly. sdf annotation is also not a necessity since we can always run gatesims w/o sdf annotation, but then it's not very useful.
#generate fsdb: add following lines in top level verilog code. (+loadpli option should be used on irun cmd)
#File: /db/Hawkeye/design1p0/HDL/Testbenches/digtop/kagrawal/tb/digtop_tb.v
initial
begin
`ifdef FSDB => note FSDB was defined in cmd line of irun, so this section is valid. It generates fsdb which is proprietary.
$fsdbDumpvars;
$fsdbDumpfile(`FSDBFILE);
#5000; //below cmds needed only if do not want dumping for all of sim time. Similar to vcd system task
$fsdbDumpon; // This starts dumping
#1000; //Dumps for 1000 time units startig from 5000 time units after sim starts
$fsdbDumpoff; //this stops dumping
`endif
-----
#NOTE: In $fsdbDumpvars, we can also provide 2 arguments. 1st arg is name of block from which you want to dump fsdb, and 2nd var implies if we just want to dump for this block (1) or for all the hierarchy below it (0).
ex: the code below dumps fsdb for digtop_tb (only top level since 2nd arg is 1), then dumps fsdb for digtop_00 which is a block within digtop_tb (all levels below it since 2nd arg is 0). The combined fsdb dump is in fsdbfile. So, in nWave, we'll see only digtop_tb. digtop_tb will contain digtop_00 module. digtop_00 module will contain all modules below it.
$fsdbDumpvars(digtop_tb, 1);
$fsdbDumpvars(digtop_00, 0);
$fsdbDumpfile(`FSDBFILE);
-----
`ifdef VCD => if we need VCD (value change dump) which is std waveform database. Can be used with Novas Debussy as it supports both VCD and FSDB. See in verilog.txt for details on these system tasks.
$dumpvars;
$dumpfile(`VCDFILE);
`endif
end // initial begin
SDF annotation: (for gate sims only)
--------------
annotator:
--------
The SDF file is brought into the analysis tool through an annotator. The job of the annotator is to match data in the SDF file with the design description and the timing models. Each region in the design identified in the SDF file must be located and its timing model found. Data in the SDF file for this region must be applied to the appropriate parameters of the timing model. SDF annotation is performed during elaboration, and can only take place at time 0.
2 ways to do sdf annotation:
-----------------------
A. $sdf_annotate utility:
Simulator only read compiled SDF file (sdf_filename.X). SDF src file is provided in $sdf_annotate and then it's compiled by the ncsdfc utility within elaborator to generate sdf_filename.X file, which is used by verilog-XL. Once *.X file is there, it can be used by the simulator for subsequent runs.
for SDF annotation, we need to do same thing as for fsdb/vcd dump file in top level module (digtop_tb). $sdf_annotate can only be in an initial block for verilog code, as it always takes place at time 0 only.
initial begin
$sdf_annotate("/db/DRV9401/design1p1/HDL/FinalFiles/digtop_VDIO_Max_aligned.sdf", digtop_00,,"logs/sdf_max.log", "MAXIMUM"); // 7 args to sdf_annotate = name of sdf file, top level module inst name, cfgfile, logfile, MINIMUM/TYPICAL/MAXIMUM, scale_factor, scale_type.
#for min sdf ann
#$sdf_annotate("/db/DRV9401/design1p1/HDL/FinalFiles/digtop_VDIO_Min_aligned.sdf", digtop_00,,"logs/sdf_min.log", "MINIMUM"); => if sdf_annotate was called in some other module, then we had to specify the full hier, i.e. dut.digtop_00
end
NOTE: after running gatesim with sdf_annotate, look in sdf_max.log to make sure it has no errors or warnings. Else, sdf is not correctly annotated or not annotated at all for such paths. Usually we get warnings like "ncelab: *W,SDFNEP: Unable to annotate to non-existent path ..." => this indicates that an arc was there in verilog model file (i.e in AN210.v), for which there was no corresponding arc found in sdf file. This usually happens with flops, where verilog models of flop (i.e SDC210.v) may have setup and hold arcs separate, while sdf file may have both combined as $setuphold, which may cause this warning. Arcs in sdf file came from .lib file, while sdf annotation is matching the arcs with std cell verilog model file. So, basically every arc in .lib file should match arcs in specify section of verilog model file. Sometimes we have conditional arcs in verilog (i.e arc from S->Y for MUX2). Corresponding arcs in .lib file are written with "sdf_cond : "!A&&B";" etc. "ifnone" arcs in verilog are written with no "sdf_cond" in .lib files. These arcs are written as "CONDELSE" in sdf files. Sometimes, some of these conditional arcs missing in .lib files can cause sdf files to be missing these arcs too. PT/ETS run using .lib files, so they may also have incoorect timing, as timing tools choose arc with worst/best possible timing, so if the missing arc has the worst/best timing, then the timing doesn't reflect that arc, resulting in incorrect timing.
NOTE: when generating sdf file, always use correct options, or some of the arcs might get removed from sdf file even though present in .lib files. One such example is using "CONDELSE" combo path arcs.
For ex: flop in SDC10.v has this in specify section:
(CLK *> Q ) = (0.100000:0.100000:0.100000 , 0.100000:0.100000:0.100000);
In SDF, 1st case shown below will pass while second will fail:
IOPATH CLK Q (1.0:1.0:1.0) (0.8:0.8:0.8) => pass
IOPATH (posedge CLK) Q(1.0:1.0:1.0) (0.8:0.8:0.8) => fail, since there no negedge/posedge clause in verilog model
Other warnings:
1. *W,NTCNNC: Non-convergence of negative timing check values in instance I_xyz/reg_5 => -ve timing check couldn't converge. see in verilog.txt for more details
2. *W,SDFNDP: Annotation resulted in a negative delay value or pulse limit to specify path or interconnect delay, setting to 0 => This happens when there are -ve values for delay in sdf file. Since simulator can't go back in time, it has to use 0 or +ve values. So, it sets all these -ve delay values to 0.
3. *W,SDFNEP: Unable to annotate to non-existent path (COND readcond (IOPATH CLK Q[24])) of instance DIG_TOP...U234 of module sshdbw00056025020 <../input/DIG_TOP_routed.fromPT.Min.sdf, line 169701> => This indicates that an arc was found in sdf but not in verilog model file. This usually happens with RAM/ROM IP, which may have intentional blackbox verilog models, which don't have any arcs.
NOTE: any of the above warnings do NOT cause missing annotations, as simulator runs with verilog arcs, and uses the default delay or the sdf delay for that arc. So extra arcs in sdf file are OK. Only when arcs are present in verilog but absent from sdf, is when we see unannotated arcs.
More options for sdf reporting:
1. -sdf_verbose: We can use option "-sdf_verbose" with irun cmd to print more detailed report in sdf.log file. With "-sdf_verbose" option, we'll see each cell instance, and the arcs annotated to it. It will have warnings (*W,SDFNEP) if while annotating a cell from sdf file, it's not able to find corresponding arc in verilog model file. Once all the cell arc annotation is done, we'll see "ABSOLUTE PORT:" delays, which show interconnect delay for getting to an i/p pin of each instance. This is taken from the "INTERCONNECT" delay section of sdf file. The reason, we only see i/p pins of cells and NOT the o/p pins is because interconnect delay is just needed for each i/p pin to form the full path. That is also the reason, why interconnect delays are not specified b/w 2 points (o/p of one gate to i/p of other gate), as it's not needed.
2. -sdfstats: If we want to have more sdf stats for unannotated arcs, we can run irun with options "-sdf_verbose -clean -sdfstats sdf_unannotated.txt". Then it shows a list of unannotated arcs with their corresponding cells. Arcs that are in verilog model, but not in sdf are the arcs that are left unannotated (and shows up as less than 100% annotation). In that case, simulator takes the default delay of such arcs from the verilog model file.
B. Cmd file:
Instead of using annotator cmd ($sdf_annotate), we can do sdf annotation using these 3 steps:
1. generate compiled sdf file using this cmd on the unix shell:
ncsdfc SPI.sdf -output SPI.blah => generates SPI.sdf.X in the current dir if no output file specified with -output.
2. wrt sdf cmd file: There are seven statements, which correspond to the seven arguments of the $sdf_annotate system task. Only one statement is required: the COMPILED_SDF_FILE statement, which specifies the compiled SDF file that you want to use. Others are optional (create cmd file named: myfile.sdf_cmd) Note, file has to be terminated with a ;
COMPILED_SDF_FILE = digtop_func_W_125_1.62.sdf.X,
SCOPE = :pm7324_inst, => annotate to the VHDL scope :pm7324_inst, which may contain Verilog blocks. For us, it's :UUT or tb_digtop.dut.
LOG_FILE = "pm7324_flat.sdf.log", =>log
MTM_CONTROL = "TYPICAL", => min/typ/max. Indicates which triplet will be used.
SCALE_FACTORS = "1.0:1.0:1.0", => optional. mult factor for min/typ/max
SCALE_TYPE = "FROM_MTM"; => optional. scales timing specs FROM_MINIMUM/FROM_TYPICAL/FROM_MAXIMUM/FROM_MTM. i.e it indicates which of the 3 triplets will be used. For ex: if MTM_CONTROL = "TYPICAL", then we specify SCALE_TYPE = "FROM_TYPICAL".
3. #for ncelab, use ncelab -sdf_cmd_file filename option to include the SDF command file.
ncelab -sdf_cmd_file myfile.sdf_cmd worklib.top
#For irun, we can use the same option: irun .... -sdf_cmd_file myfile.sdf_cmd -sdf_verbose ...
When running irun, we see annotation message like this:
Reading SDF file from location "/vobs/.../digtop_func_QC_NOM_1.8_ATD-N_25_1.8-.sdf"
Writing compiled SDF file to "/sim/.../../digtop_func_QC_NOM_1.8_ATD-N_25_1.8-.sdf.X".
Annotating SDF timing data: ....
Annotation completed successfully...
SDF statistics: No. of Pathdelays = 29695 Annotated = 100.00% -- No. of Tchecks = 38702 Annotated = 99.99% => Path_delays/Tchecks refer to ones in verilog model for cells, while Annotated refer to ones in sdf
Total Annotated Percentage
Path Delays 29695 29695 100.00 => path delays refer to IOPATH in cell, and not to interconnect delay. Here verilog model IOPATH(under Total) for all cells match sdf IOPATH(under Annotated). Reason for mismatch would be when there's an extra gate in netlist but not in sdf file
$period 2 2 100.00
$width 6942 6942 100.00
$recrem 4506 4506 100.00
$setuphold 27252 27250 99.99 => 2 setuphold arc in verilog for which the annotator didn't find corresponding arc or timing in sdf. This needs to be fixed as they should match exactly at 100%.
NOTE: missing interconenct delays will be reported separately as "ncelab: *W,SDFINC: interconnect ... not connected to ..."
NOTE: If we provide non-existent sdf file in $sdf_annotate, then irun doesn't give any warnings. We don't see any annotation messages as shown above. Instead delays from verilog models (ex 0.01ns for gates when TI_verilog is defined) are taken, and annotation is done using those delays. As a result, we may see tons of timing violations for cells. Best way to find out is to pull up waveform and check delay for buffers/inverters and make sure they match those from sdf files.
------------
SDF file format is below in another section.
----------------
#Then we run Ncverilog or irun with loadpli1 (pointing to verdi PLI), and we get waveform dump. Then we start running debussy in separate dir to debug this waveform.
script: create_symbols for debussy/verdi:
-----------------------
creating symbols: Debussy/Verdi can display gate-level schematics using the proper symbols for the cells used in the netlist. To enable this, you must set up a Debussy/verdi symbol library for the target cell library. The symbol library can be created by running the utility syn2SymDB on the equivalent Synopsys Liberty (.lib) library.
syn2SymDB -o foo_u foo.lib foo1.lib =>
-o: Specifies output library name
foo.lib: Synopsys library name. Other lib can be added separating them by space
This creates symbol library (directory) called foo_u.lib++.
NOTE: we can also run "vericom" compiler by synopsys to generate foo_u.lib++
cmd: vericom -2013.09 -sv -f list_rtl.f -lib VerdiLib => reads rtl files to generate VerdiLib.lib++
ex: just typing syn2SymDB may not work, so type the whole path
/apps/novas/debussy/2010.04/platform/LINUXAMD64/bin/syn2SymDB -o symbol \
/db/pdk/lbc8lv/current/diglib/msl445/current/synopsys/src/MSL445_N_25_1.8_CORE.lib \
/db/pdk/lbc8lv/current/diglib/msl445/current/synopsys/src/MSL445_N_25_1.8_CTS.lib \
/db/pdk/lbc8lv/current/diglib/msl445/current/synopsys/src/MSL445_N_25_1.8_ECO.lib
=> creates symbol.lib++ dir.
You must reference this symbol library by setting the following two environment variables:
setenv TURBO_LIBS "foo_u"
setenv TURBO_LIBPATHS <path to the directory containing the symbol library directory>
We can also include these 2 variables in novas.rc file as:
TurboLibs = symbol
TurboLibPaths = /data/VIKING_OA_DS3/a0783809/debussy/lib
=> novas.rc gets loaded anytime debussy is invoked, so it looks in "lib" dir for "symbol.lib++" and adds all those symbols.
#Invoke Debussy and compile/load your netlist.
debussy -2012.04 /data/.../DIG_TOP_routed.v => This loads PnR netlist so that we can see schematic of this. (2012 version shows old gui, while later ones show new gui)
verdi /data/.../DIG_TOP_routed.v -upf2.0 Top.upf -upftop digtop => Loads PnR netlist into verdi (-upf loads upf to show various power domains in design. If loading upf, top module name for upf needs to be provided)
debussy quick tips:
------------
0. clicking on the AND gate symbol (2nd row 3rd col on gui) brings up the schematic.
1. When tracing loads, click on any net and click "Trace Load". Then from top, do tools->New Schematic->From Trace Results. This brings a new window which only shows net and all loads. This is helpful to see all loads on any net.
2. click Schematic->Find (or Caps A), and put name of nets/instance and it will show all. Select one that you need and click "c" to change color of that net.
script: run_debussy_rtl/run_debussy_gate: for gate runs and rtl runs
----------------------
run_debussy_rtl:
#in our dir, we see PML30.lib++. So, we set these var as follows and invoke debussy. NOTE: we don't really need these symbols since rtl only has clk gaters instantiated from library, so those will show as square box.
setenv TURBO_LIBS PML30
setenv TURBO_LIBPATHS /db/Hawkeye/design1p0/HDL/Debussy/
debussy -f list_rtl.f -vtop vtop.map -2001 -autoalias & => we can also just use "debusssy &"
list_rtl.f
-------
-f /db/DRV9401/design1p1/HDL/Source/digtop_rtl.f => has paths to all rtl files from source area: /db/DRV9401/design1p1/HDL/Source/digtop.v, global.v, etc
/db/DRV9401/design1p1/HDL/Testbenches/kagrawal/digtop/tb/digtop_tb.v => has path to top level tb block
run_verdi_rtl:
----------------
#invoke verdi to load RTL
vericom -2013.09 -sv -f list_rtl.f -lib VerdiLib => invoke vericom to create VerdiLib.lib++ from rtl files. (for some reason, this gives lots of error whe reading verilog packages. options "-2012 -ssv -ssy" seem to resolve all these errors. -2012 enables system verilog constructs (probably same as -sv), while "-ssv -ssy" enables verdi database for library cells.
verdi -lib VerdiLib -top digtop => Here we are loading VerdiLib.lib++, no need to specify RTL files, as lib++ already has lib built from rtl from earlier step (when running vericom)
verdi -f list_rtl.f => This loads list_rtl.f directly instead of generating lib thru vericom. For some reason, this gives lots of errors with packages.
vtop.map: debussy accesses already dumped fsdb files. The map file maps hier in fsdb to that in RTL.
-------
digtop = digtop_tb.digtop_00 => this provides the hier path to the dut (digtop_00 is the instance name of digtop [digtop is top level RTL module] instantiated in digtop_tb)
run_debussy_gate: same as with rtl except that we run it directly on gate netlist:
---------------
list_gate.f
/db/DRV9401/design1p0/HDL/FinalFiles/digtop_VDIO.v => path to gate level netlist
../Testbenches/digtop/tb/digtop_tb.v => path to top level tb
vtop.map
-------
digtop_top = digtop_tb.digtop_00 (If top level module in gate netlist is called digtop_top, then that is what we specify. This digtop_top ties gate level netlist with tb file)
NOTE: If we get *.vcd file from analog team, then to run debussy, we need to map the hier from .vcd file to our gate netlist. so, in vtop.map:
digtop_top = zorro_toplevel_sch.I3.I7.I0 (here I0 at the end refers to the inst of "digtop_top" module in gate level netlist digtop_VDIO.v. zorro_toplevel_sch is the schematic name within which we have I3 top level block, which contains digital wrapper I3 within which we have digital block I0)
running debussy when debugging RTL:
----------------------------------
Bring up Debussy nTrace. goto source-> mark Parameter annotation and active annotation.
Now, open nWave by going to Tools->New Waveform.
Now, we can drag and drop signals from nTrace to nWave and vice vera, and observe signals.
1. We can click on clk edge in nWave and that will show which values changed.
2. We can click on signal names in nTrace and it will backtrace it.
2. We can click "c" on any net, and we can set net to chosen color.
3. We can open 2 nWave from nTrace by going to Tools->New Waveform. this way, we open 2 nWave window. we can goto nWave "window" button and turn ON sync waveform view. We do it for both the windows so that clicking on cursor in any one of them, will affect the other (if we do it for only one of them, then clicking on cursor in that window will affect the other, but not the other way around). Then the 2 nWave windows will be synced in time, so that it's easier to compare results (for ex b/w RTL and gate)
4. NOTE: when we open nWave using Debussy and do active annotation, we will see the name of the fsdb file on the top panel of debussy window. That is the fsdb file that is actively annotated with the current RTL that we see in the RHS of debussy main window. If we open open any other nWave window and any other fsdb file, it will NOT be actively annotated with that RTL. To actively annotate other fsdb file, we goto nWave window of new fsdb, click on Window->change to primary. This changes this new nWave window to be actively annotated with the current RTL (we will see the name of this new fsdb file on the top panel of debussy window). So, we can switch back and forth b/w multiple nWave window.
4. NOTE: sometimes when we load new fsdb from nWave window, it may not get annotated properly with rtl. So, best way to open a new fsdb is to do it from Debussy panel. In debussy, goto File->close simulation results. this kills the current fsdb, but retains all the signals, so that we don't have to save it. Now, do File->load simulation results and open the new fsdb. This is correct way to view new fsdb.
running debussy when looking at gate netlist for ECO:
----------------------------------------------------
run_debussy_eco: here we are just looking at schematic of gate netlist, so we invoke debussy with just gate level netlist.
#in our dir, we see PML30.lib++. So, we set these var as follows and invoke debussy.
setenv TURBO_LIBS PML30
setenv TURBO_LIBPATHS /db/Hawkeye/design1p0/HDL/Debussy/
debussy -f list_gate.f & => list_gate.f has path to gate level netlist /db/DRV9401/design1p0/HDL/FinalFiles/digtop_VDIO.v
#debussy & => If we call debussy w/o -f option, then we have to do File->Import design, Put the file name (/db/DRV9401/design1p0/HDL/FinalFiles/digtop_VDIO.v) in bottom box, and then click Add, then OK.
Then click on Tools->New Schematic->Current scope
patgen files:
-----------
Ex: /db/MOTGEMINI_DS/design1p0/HDL/Testbenches/digtop/patgen
verilog models used: (for lbc7)
--------------------
A. MODEL_functiononly: timescale is 1ps/1ps. It has following delays specified:
1. gates (AN2,etc) = 0
2. clk gating cells (CG*) = 0
3. flops, c2q delay = 1ps. For ex: in DTP20.v (in lbc7), "buf" and "not" gates are specified delay of #1(1ps), so final o/p Q/QZ have delay of 1ps.
B. MODEL_verilog: timescale is 1ns/1ps. It has following delays specified:
1. gates = 10ps(#0.01) (in specify section =>)
2. clk gating cells (CG*) = 100ps(#0.1) (in specify section =>). Also does setup/hold checks.
3. flops, c2q delay = 100ps(#0.1) (in specify section =>). Also does setup/hold checks.
C. If nothing defined (neither MODEL_functiononly nor MODEL_verilog). timescale is 1ns/1ps. same as MODEL_verilog except no checks done:
1. gates = 10ps(#0.01) (in specify section =>)
2. clk gating cells (CG*) = 100ps(#0.1) (in specify section =>). NO setup/hold checks done.
3. flops, c2q delay = 100ps(#0.1) (in specify section =>). NO setup/hold checks done.
NOTE: we used "specify" instead of putting delays as "#" so that when we sdf annotation, it will disregard delays in specify section. If we hardcoded delays as #, then we would have double counted the delay as sdf annotation would have happened on top of existing delay in verilog model.
NOTE: Only delay numbers are disregarded in specify section, all arcs (c2q, setup/hold, rec/rem, width, etc) are still honored and transfer is passed to appr notifier in the verilog model (using delay numbers from sdf file).
NOTE: When we run AMS sims, we run toplevel sims directly on digital schematic which is a gate level netlist. We don't have sdf file to annotate delays for gates. So, we set "MODEL_functiononly" as that will cause no setup/hold issues. Flops will always have 1ps delay, so they will always have enough setup time, and since all comb gates on clk have "0" delay, there will be no hold issues. If we run it with MODEL_verilog (or with nothing defined), then hold issues may show up, which may not be actually present in ckt. This hold will show up if we've (c2q+data_path_delay < clk_path_delay). Usually clk+path has < 10 clk buffers, so no hold issues. However, if even 1 clk gating cell gets added on clk path, then hold will get violated as clk will change before data (if no of clk buffers is greater than no of gates in data path) or at same time as data (if no of clk buffers is same as no of gates in data path).
modeling delays in simulations:
------------------------------
By default, verilog gate level models, and, interconnect delays are always simulated as transport delays, but they look as if they are simulated as pure inertial delays (since they don't allow glitches shorter than prop delay to pass thru). This is beacuse, by default, pulse_r and pulse_e are set to 100%. These are verilog cmd line switches that can be used to alter this behaviour for gate level sims. delays inside of specify blocks are affected, when this cmd line switches are used with simulators: (add +transport_path_delays also)
A. +pulse_r/R% : switch forces pulses that are shorter than R% (R=0 to 100) of the propagation delay of the device being tested to be "rejected" or ignored.
B. +pulse_e/E% : switch forces pulses that are shorter than E% (E=0 to 100) but longer than %R of the propagation delay of the device being tested to be an "error" causing unknowns (X's) to be driven onto the output of the device. Any pulse greater than E% of the propagation delay of the device being tested will propagate to the output of the device as a delayed version of the expected output value.
scenarios are as below:
0% ------ R% ------- E% ------ 100%
--- reject -- error(x) -- output --- => So, glitches can be rejected, output an x or get out as normal delayed version depending on settings.
Ex: vcs -RI +v2k tb.v delaybuf.v +pulse_r/0 +pulse_e/0 +transport_path_delays => causes pulses shorter than 0% to be rejected, and pulses greater than 0% to be propagated to the o/p. => all pulses are passed, no matter how small.
Ex: +pulse_r/0 +pulse_e/100 => causes no glitches to be rejected, but o/p x, for glitches shorter than propagation delay.
Ex: +pulse_r/100 +pulse_e/100 => models inertial delays, where all pulses shorter than propagation delay are ignored.
Ex: +pulse_r/20 +pulse_e/20 => causes glitches <20% to be rejected, but glitches >20% to be passed.
NOTE: when we run gate sim, we may start seeing "glitch suppression" warnings (many times after adding pulse_r/pulse_e switches).
EX: Warning! Glitch suppression
Scheduled event for delayed signal of net "GVC_D_D" at time 1027453294 PS was canceled!
File: /db/pdkoa/lbc8lv/current/diglib/msl458/PAL/CORE/verilog/SDP10B_LL.v, line = 92
Scope: tb_digtop.dut.I_i2c_top.I_bellatrix_i2c_slave.I_meson_i2c_fsm.bitCnt_reg_2
Time: 1027453096 PS
Glitch suppression: This happens when there are -ve timing values, which causes simulator to use delayed signals. When a delay with two values is calculated, there is the possibility that an event on the input net may cancel a scheduled event on the internal signal driven by the delay. This is called glitch suppression.Because glitch suppression can hide input events from a timing check's input, the simulator generates a glitch suppression timing violation if an event on a delayed signal is canceled.
To suppress the warnings due to the glitch suppression algorithm, use the -nontcglitch simulation option
NOTE: the above cmd line switches only valid for delays in specify block, not for delays using SDF annotation. For sdf delays, we need to have these in absolute numbers within sdf file for each cell.
NOTE: to specify reject/error, we need to have extra paranthesis, like this:
ex: (IOPATH A Y ((rise_delay) (rise_reject) (rise_error)) ((fall_delay) (fall_reject) (fall_error)) ) => extra parantheses, empty parantheses for reject/error imply that reject/error is set equal to delay value => inertial delay model
ex: (IOPATH A Y (rise_delay) (fall_delay)) => no extra brackets, so values are delay values. no reject/error values.
ex:
(CELL
(CELLTYPE "IV110")
(INSTANCE U32)
(DELAY
(ABSOLUTE
(IOPATH A Y ((0.066:0.066:0.066) (0.015:0.015:0.015) (0.019:0.019:0.019)) ((0.059:0.059:0.059) (0.012:0.012:0.012) (0.017:0.017:0.017))) => 66ps for o/p rise delay, 15ps is rise reject limit while 19ps is rise error limit. 59ps for o/p fall delay, 12ps is fall reject limit while 17ps is fall error limit.
)
)
)
Ex: we can also use "PATHPULSEPERCENT" keyword in sdf file to specify reject and error limits in % terms.
(IOPATH A Y (0.066:0.066:0.066) (0.059:0.059:0.059))
(PATHPULSEPERCENT A Y (25) (35)) => 25=pulse reject limit in %, 35=pulse error limit in %
-----------------------
SDF file syntax: ( /db/Hawkeye/design1p0/HDL/Primetime/digtop/sdf/digtop_max.pt.sdf)
-----------------
OVI (open verilog intl) developed SDF v3 syntax. timing calc tools (PT,etc) are resp for generating SDF.
syntax:
------
(DELAYFILE
(SDFVERSION "OVI 3.0")
(DESIGN "digtop")
(DATE "Thu Jul 21 20:22:34 2011")
(VENDOR "PML30_W_150_1.65_CORE.db PML30_W_150_1.65_CTS.db")
(PROGRAM "Synopsys PrimeTime")
(VERSION "D-2010.06")
(DIVIDER /) => hier divider is / (by default, it's .) a/b/c
// OPERATING CONDITION "W_150_1.65" => // is for comment
//triplets are always in form - min:typ:max for delay
(VOLTAGE 1.65:1.65:1.65) => best:nom:worst
(PROCESS "3.000:3.000:3.000") => best:nom:worst
(TEMPERATURE 150.00:150.00:150.00) => best:nom:worst
(TIMESCALE 1ns) => implies all delay values are to be multiplied by 1ns
//delays specified in CELLS for both interconnect and cell delay.
//interconnect delays => we may have the block below repeated many times as only some wires may be in each block. It's easier for readability. interconnect delays are always between 2 points => o/p of one gate to i/p of other gate.
(CELL => inter connect delays specified here. interconnect delays of order of ps (vry small), while cell delays of order of ns. All INTERCONNECT delays are only specified for top level module (digtop). For wires which are not in digtop, heir names are used.
(CELLTYPE "digtop")
(INSTANCE) //no instance specified, implying it's interconnect delay
(DELAY =>
(ABSOLUTE => delay can be ABSOLUTE or INCREMENT
(INTERCONNECT scan_out_iso/U282/Y em_out_31_I_bufx4/A (0.008:0.008:0.008) (0.008:0.008:0.008)) //rise/fall (min:typ:max)delays. min:typ:max are same delays for one sdf file as we use separate sdf files for min/typ/max corners. However, if we use newer tools as tempus to generate sdf, we may see (0.41::0.62), which indicates that for sdf generated at particular corner (say NOM.sdf), we may have different values for min,typ,max. In timing tools for OCV runs, for a giver corner (say NOM), min value in triplet is used for clk, max for data (for setup check) and viceversa for hold. However for gatesim, it takes only one value for all paths, and we specify what triplet value to use (by stating "MAXIMUM","TYPICAL" or "MINIMUM" in sdf_annotate). So, ideally, we should run gate sims with "MAX" triplet with QC_MAX.sdf, and "MIN" triplet with QC_MIN.sdf. "MAX" and "MIN" triplet with QC_NOM.sdf is not really needed as it will be bounded by MAX/QC_MAX.sdf and MIN/QC_MIN.sdf.
(INTERCONNECT scan_out_iso/U164/Y a2d_trg_out_I_bufx8/A (0.001:0.001:0.001)) //same delay for rise/fall (NOTE: hier names used)
...
)
)
)
//cell delays
(CELL => delay for cells: delays for each instance defined separately, since it may be diff based on load.
(CELLTYPE "NA210") =>nand gate
(INSTANCE test_mode_dmux/U85) => in test_mode_dumx module. since instance specified, it's cell delay
(DELAY
(ABSOLUTE
(IOPATH A Y (0.129:0.129:0.129) (0.170:0.170:0.170)) //rise/fall for Y (min:typ:max)delays. We don't specify rise/fall for A as it's automatically decided based on direction of Y.
(IOPATH B Y (0.157:0.157:0.157) (0.158:0.158:0.158))
(COND !A&&!B (IOPATH Y S (0.630::0.641) (1.470::1.476))) //some complex cells(adders, etc) will have cond delay arcs.
)
)
)
(CELL => flop delay. flops will have delay arcs as well as timing check arcs.
(CELLTYPE "TDC10")
(INSTANCE spi/data_reg_15)
(DELAY
(ABSOLUTE
(IOPATH CLK QZ (0.622:0.622:0.622) (0.624:0.624:0.624)) => NOTE: sdf doesn't say rise/fall of CLK in IOPATH. Only rise/fall of QZ. However, model file specifies QZ delay wrt posedge or negedge CLK. So, there's always this discrepancy b/w verilog model file and sdf file for all IOPATH.
(IOPATH CLK Q (1.308:1.308:1.308) (0.874:0.874:0.874))
(IOPATH CLRZ QZ (0.936:0.936:0.936) ())
(IOPATH CLRZ Q () (1.217:1.217:1.217))
)
)
(TIMINGCHECK => checks
(WIDTH (posedge CLK) (0.176:0.176:0.176)) => min allowable time for +ve(high) pulse of clk
(WIDTH (negedge CLK) (0.692:0.692:0.692)) => min allowable time for -ve(low) pulse of clk
(WIDTH (negedge CLRZ) (0.330:0.330:0.330)) => min allowable time for -ve(low) pulse of clrz
(SETUPHOLD (posedge D) (posedge CLK) (0.437:0.437:0.437) (-0.263:-0.263:-0.263)) => setup and hold checks for rising edge of D wrt +ve clk. first triplet(0.437) is for setup, while second(-0.263) is for hold. triplets are min:typ:max delays. SETUP and HOLD can also be separated by using SETUP and HOLD keywords. NOTE: setu is +ve, while hold is -ve (typically true for flops as data lines inside flops have extra gates before they hit clk logic)
(SETUPHOLD (negedge D) (posedge CLK) (0.716:0.716:0.716) (-0.288:-0.288:-0.288)) => similarly for falling edge of D
(SETUPHOLD (posedge SCAN) (posedge CLK) (0.954:0.954:0.954) (-0.592:-0.592:-0.592))
(SETUPHOLD (negedge SCAN) (posedge CLK) (0.659:0.659:0.659) (-0.538:-0.538:-0.538))
(SETUPHOLD (posedge SD) (posedge CLK) (0.472:0.472:0.472) (-0.317:-0.317:-0.317))
(SETUPHOLD (negedge SD) (posedge CLK) (0.756:0.756:0.756) (-0.332:-0.332:-0.332))
(RECREM (posedge CLRZ) (posedge CLK) (0.405:0.405:0.405) (0.084:0.084:0.084)) => recovery check is like setup check for clrz where it should go inactive sometime before the clk., so that flop i/p can get flopped. Removal check is like hold check for clrz where it should go inactive sometime after the clk, so that flop i/p doesn't get flopped that cycle, but the next cycle. RECREM combines RECOVERY ans REMOVAL checks in one. 1st triplet(0.405) is recovery, 2nd(0.084) is removal.
)
)
(CELL => clkgater delay
(CELLTYPE "CGPT40")
(INSTANCE hwk_regs/clk_gate_ccd_brightness_out_reg/latch)
(DELAY
(ABSOLUTE
(IOPATH CLK GCLK (0.642:0.642:0.642) (0.610:0.610:0.610))
)
)
(TIMINGCHECK
(WIDTH (negedge CLK) (0.538:0.538:0.538))
(SETUPHOLD (posedge TE) (posedge CLK) (0.701:0.701:0.701) (-0.448:-0.448:-0.448))
(SETUPHOLD (negedge TE) (posedge CLK) (0.795:0.795:0.795) (-0.508:-0.508:-0.508))
(SETUPHOLD (posedge EN) (posedge CLK) (0.468:0.468:0.468) (-0.214:-0.214:-0.214))
(SETUPHOLD (negedge EN) (posedge CLK) (0.721:0.721:0.721) (-0.430:-0.430:-0.430))
)
)
(CELL => latch delay
(CELLTYPE "LAH11")
(INSTANCE flipper_top/flipper_ram/flipper_ram_reg_185_5)
(DELAY
(ABSOLUTE
(IOPATH C Q (0.826:0.826:0.826) (1.097:1.097:1.097))
(IOPATH D Q (0.622:0.622:0.622) (1.250:1.250:1.250))
)
)
(TIMINGCHECK
(WIDTH (posedge C) (0.733:0.733:0.733))
(SETUPHOLD (posedge D) (negedge C) (0.464:0.464:0.464) (-0.339:-0.339:-0.339))
(SETUPHOLD (negedge D) (negedge C) (1.116:1.116:1.116) (-1.079:-1.079:-1.079))
)
)
(CELL //hard IP
(CELLTYPE "ophdll00032008040") => otp
(INSTANCE I_i2c_top/I_bellatrix_i2c_otp/I_otp_32x8)
(DELAY
(ABSOLUTE
(IOPATH CLK Q[0] (27.7495::27.7495) (7.7705::7.7705)) ...
(IOPATH CLK Q[7] (27.7482::27.7482) (7.7696::7.7696))
(COND WRITECOND (IOPATH CLK BUSY () (18.6512::18.9356)))
(COND READCOND (IOPATH CLK BUSY (5.5594::5.5594) (73.8027::73.8027)))
(IOPATH PROG BUSY (17.0202::17.2431) (18.7960::19.0702))
)
)
(TIMINGCHECK
(SETUPHOLD (posedge READ) (posedge CLK) (23.4053::23.4053) (4.3649::4.3649)) ...
(WIDTH (COND WRITECOND (posedge CLK)) (50000.0000::50000.0000)) ... => This WRITECOND should be there in verilog model of otp else tool will complain about missing "WRITECOND". This "WRITECOND" initially came from .lib file.
(PERIOD (COND WRITECOND (posedge CLK)) (50202.0000::50202.0000)) ...
(SETUPHOLD (posedge D[0]) (posedge CLK) (0.1406::0.1406) (5.4447::5.4447)) ...
(SETUPHOLD (negedge A[4]) (posedge CLK) (0.7298::0.7298) (4.0518::4.0518))
(SETUPHOLD (negedge PROG) (posedge READ) (163.5221::163.5221) ())
(SETUPHOLD (negedge CLK) (posedge READ) (163.5160::163.5160) ())
)
)
-------
SDF supports both a pin-to-pin and a distributed delay modeling style. We use pin to pin.
SDF supports setup, hold, recovery, removal, maximum skew, minimum pulse width, minimum period and no-change timing checks.
interconnect delay: SDF supports two styles of interconnect delay modeling.
A. The SDF INTERCONNECT construct allows interconnect delays to be specified on a point-to-point basis from o/p port of one device to i/p port of other device. This is the most general method of specifying interconnect delay.
B. The SDF PORT construct allows interconnect delays to be specified as equivalent delays occurring at cell input ports. This results in no loss of generality for wires/nets that have only one driver. However, for nets with more than one driver, it will not be possible to represent the exact delay.
cell delay: SDF supports 2 types of cell delay.
A. IOPATH implies delay from i/p port of device to o/p port of same device. We use this for all simple cells.
B. COND implies conditional i/p to o/p path delay. We use this for complex cells (adders, etc).
************************************************