Cadence Digital Design Synthesis Flow
Developed by : Zhenyu Qi (jerry@virginia.edu), Adam Cabe (acc9x@virginia.edu)
Mircea Stan (mircea@virginia.edu)
First Edition Date
: 4/3/2008
Latest Revision Date : 4/4/2008
Introductory Comments
This flow was originally designed to work in the .035 m AMI/TSMC technologies, and
has since been ported to work with the 90 nm ST design kit. The final goal of this design
flow is to provide sectioned scripts, where the process dependent parameters can be
separated from the design and flow parameters, making this flow easily portable from one
technology to another, and from one project to another. At the current time there are two
separate flows for the two technologies, however this separation of scripts has not been
accomplished yet. This manuscript details how to run the flows as they stand. Later
editions will detail the separation of design, technology, and flow parameters in different
scripts.
Chapter I : Setting up the Environment
This chapter demonstrates how the file structures and hierarchy are setup, and
how to initialize the Cadence environment to run design synthesis.
A. The file hierarchy
To keep version control and records in order, we are using CVS to manage the project
files. In order to checkout the current project into your working directory, follow these
steps. Step into the directory username/cadence and type “cvs checkout cordic” (without
quotes). This will checkout the current version of the script into the directory
username/cadence/cordic.
At present, the root file directory is set to the path user_name/cadence/project_name,
where user_name is your linux user name, and project_name is the name of the current
working project. For example, for user johndoe working on project cordic, the home path
should be set to johndoe/cadence/cordic.
Figure 1: File hierarchy.
The current file directory structure is shown here in Fig. 1. These directories will be
discussed in great detail throughout the document, however the following gives a brief
overview of what is contained in each directory.
rc – Contains the required scripts to synthesize the top level HDL code down-to a gatelevel verilog netlist.
dft – Contains the scripts to insert scan-chains into the post-RC gate-level netlist.
fe – Holds the scripts to perform back-end synthesis, which takes the gate-level netlists,
with scan chain inserted, and transfers them to layout. This step will provide a final gds
file which is used to tape-out the chip.
ic – This directory contains scripts used to import the post-encounter netlist into the
actual cadence design environment. In this environment, one can perform schematic and
extracted level simulations on the final design.
ncsim – Houses scripts to simulate the behavioral, post-RC and post-encounter netlists.
aux – Contains files that provide design constraints (timing, clock-tree specs, etc), and
configuration settings for the current project.
cdn_init – Holds the scripts needed to launch the cadence tools, and setup the project
environment.
mmsim – This directory contains scripts that perform simulations on the final schematic
and extracted netlists.
hdl – Houses the top level HDL code and testbenches.
lib – Holds all of the necessary library files (.lib, .lef, technology .v files, etc).
*** From this point forward, when referring to a directory,
username/cadence/cordic/, e.g. ./rc implies username/cadence/cordic/rc.
./
will
imply
B. Setting up the environment for an existing project
To setup the environment for your current project, cd into ./cdn_init and type the
following two commands :
. project_init
. cadence_cordic
This will setup your environment to run the Cadence toolset, and load the proper
environmental defaults for the design scripts. These commands should be run in the ksh
environment.
C. Setting up the environment for a new project
In order to setup your environment for a new project, you will need to modify some of
the parameters given in the files from chapter 1B (project_init, cadence_cordic). You
may also want to change the name cadence_cordic to match your own project name
(cadence_projname), although this isn’t necessary. Here are some of the parameters you
may need to modify in the respective files.
./cdn_init/project_init :
LIBFILE – list of the .lib files required for synthesis
LEFFILE – list of the .lef files required for synthesis
VLOGFILE – list of the technology .v files required for simulation
TECHFILE – technology file name
GDSMAPOUTFILE – layer map file used to stream out a gds from encounter
GDSMAPINFILE – layer map file used to stream in a gds to virtuoso
TOPMODULE – name of the top module of your design
./cdn_init/cadence_cordic :
The only thing to modify here is the paths to the cadence tools. If you get errors
where the tools cannot be found, you need to change the paths in this file to point to the
tool locations in your unix environment.
Chapter II : Setting Up Your Project
A. Libraries
i. Copying libraries into working directories
Before starting the design flow process, it is imperative to copy all of the necessary
library and technology files into their proper directories. To start with, let’s examine
what’s needed to add to the ./lib directory.
This directory houses all of the .lib, .lef, and .v files for the specific technology. The .lib
files detail the ports and timing of the technology standard cells. The .lef files provide
layer information for each standard cell, which helps the synthesis tool know how to
connect to each cell, and where it can and cannot route. The technology .v files, as
opposed to the design .v files, describe the functionality of each standard cell, and
generally provide timing information which is used to simulate gate level netlists. These
libraries should all be located in the design kit of the particular technology of use. Once
these libraries are located, they need to be copied into the ./lib directory of your current
project.
Next, a few files need to be copied into the /aux/forFE directory. These files consist of
the layer mapping files that are required to stream gds files out of encounter and into
Cadence layouts, and the technology file. The layer mapping files, to our dismay, do not
generally come with a specified suffix. This suffix tends to be either .map or .lmt,
however it could also be something else. The file name is generally given somewhere in
the design kit documentation. Examples of these files are provided in the current
working directories as ./aux/forFE/cmos090.lmt (90 nm gds stream in layer map file) and
./aux/forFE/gds2_cmos90.map (90 nm gds stream out layer map file). Once you locate
these files, copy them into the ./aux/forFE directory. Although not necessary right now,
you can also copy the technology file into this directory. This may be used later to do
steps with library characterization and additionally testing features.
Lastly, some technologies provide footprint files that may be necessary to run the backend flow. If your technology provides a footprint file, copy this into the ./lib directory.
This footprint file typically has a .cfp suffix, however check the design kit documentation
to see if it exists, and to get the exact file name.
ii. Defining the libraries in the scripts
Now that we’ve copied the appropriate libraries into the working directory, we need to
make sure our setup scripts point to these proper libraries. The first file to modify is the
./cdn_init/project_init script. In this file, we need to add the proper names of our lib, lef,
v, tech, gdsin, and gdsout files. This script is shown in Fig. 2 below.
Figure 2: project_init file, where lib, lef, and some technology files are declared.
The six parameters that should be modified are LIBFILE, LEFFILE, VLOGFILE,
TECHFILE, GDSMAPOUTFILE, and GDSMAPINFILE. Just replace these file names
with the names of the files for your proper technology. If you placed the files in the
proper directories as stated in the previous section, you will only need to modify the
filenames and nothing else.
*** Be sure to place the lef file that defines the layer information for the technology first
in the list, or else Encounter will complain that it cannot understand the layers of the
technology. For reference of what this file should look like, open the sample lef
./lib/encounter.lef. Some technologies have all of their lef files combined into one file, in
which case order doesn’t matter, but if they do not, be sure to order them properly.
B. Design Constraints
The next step to tackle is to setup the design constraints for your particular project. This
consists of defining the clock requirements, setup and hold time constraints, skew, rise,
and fall time constraints. The .sdc file defines these constraints, and is located in the
./aux/sdc directory. There is a .sdc file for each step in the flow, so this directory
contains four different .sdc files, although they look very similar. The four files are :
Design.sdc
Design_top.sdc
Design_scan.sdc
Design_top.postcts.sdc
Here, Design stands for the design name (and will from here on out), which in this case is
DenaliCordicProcessor. The first file defines the constraints used for RTL compiler, the
second defines constraints for the intial back-end synthesis, the third defines for scan
chain synthesis, and the fourth defines for post-clock-tree-synthesis. The constraints in
each of these files are close to identical, and can be tweaked to achieve the desired
performance. Fig. 3 shows an example of the constraints file.
Figure 3: Snip of the .sdc constraint file.
Check the RTL Compiler manuals to get a better understanding of these design
constraints. Here is a basic list of what these constraints do :
create_clock – Creates a clock with a certain clock period
set_clock_latency – defines delay from pin to clock source
set_clock_uncertainty – defines setup and hold time constraints
set_clock_transition – defines rise and fall time constraints
All of these constraints listed are in ns. These constraints will likely be parameterized in
future revisions, however for now these constraints must be changed manually in the
scripts. To be pessimistic, the constraints can be set the same for each sdc file, however,
the constraints can be set tighter (more realistic) in the postcts version of the sdc file.
C. IO Pads / Pad Ring
The next step in setup is to define the pad ring for the current chip. The pads must be
defined in three different files :
./aux/forFE/Design_top.io
./aux/forFE/topmodule.v
./aux/forFE/add_corner_pads.v
./aux/sdc/[each sdc file]
The first file defines where the pads are located on the pad frame, and is where you name
the pads. This file also tells the back-end tool Encounter where to place the pads on the
chip. A snip of this file is shown here in Fig. 4.
Figure 4: Piece of the .io file which specifies the position of each IO in the pad ring.
The capital N’s and E’s represent the side of the chip where the pad is located. N-north,
E-east, W-west, S-south, se-southeast, sw-southwest, ne-northeast, nw-northwest.
The next place to define your IO pads is in the topmodule.v file. This file is attached to
the gate-level netlist generated by the RTL compiler tool, and a snip of this file is shown
here in Fig. 5.
Figure 5: Piece of the topmodule.v file which specifies the IO connections, and the used IO types.
In this file, you need to define how the IO pads connect to the top level ports, and how
they should connect into the design. An example is shown here :
BD2CARDQP_2V5_LIN io_p38(.A(Dout_top[0], .IO(Dout[0]), .EN(1’b0), .TEN(1’b0)
…);
Here, BD2CARDQP_2V5_LIN is the type of IO pad as defined in the technology library.
The name io_p38 is the pad name as defined in the previous .io file. The rest of the line
states where the verilog ports connect to in the design. For instance, port A is connected
to node Dout_top[0], port IO is connected to node Dout[0].
The next place to add IO pads is in the add_corner_pads.v file. This file simply lists the
four corner pads, so that they can be added into the design later. Follow the format as is
shown in the add_corner_pads.v file.
The last place to add IO pads is in the sdc files. The purpose of this is to tell the tools
which pads are input pads, and are driving signals onto the chip. Again, you can follow
the example as shown in the sdc files to update your code accordingly.
D. Configuration File
The last step in the setup is to update the configuration file to meet your project
specifications. This file is located at :
./aux/forFE/Design_top.conf
The first things to change in this file are the buffer, inverter, and delay footprints. These
are defined on the lines :
set rda_input(ui_buf_footprint) {fprint_name}
set rda_input(ui_inv_footprint) { fprint_name }
set rda_input(ui_delay_footprint) { fprint_name }
The names of these footprints are either defined in the technology .lef files, or defined in
the .cfp footprint file. Locate these names and insert them where fprint_name is located.
The next thing to add is to list the proper technology clock buffer cells. This is done in :
set rda_input(ui_cts_cell_list) {cell1 cell2 cell3 …}
The last thing to do here is to define the proper power net names, which are given by :
set rda_input(ui_pwrnet) {vdd}
set rda_input(ui_gndnet) {gnd}
If your power net names are different, or would like to tie additional global signals to
power or ground rails, add them in these lists.
Chapter III : Running the Front End Flow
A. Setting up RC for your current project
RTL compiler is the Cadence tool for synthesizing the top-level HDL code down to a
gate-level verilog netlist. This section shows how we have setup the script for running
RTL compiler, and how you can use and modify it for your own project.
The main script to run the Cadence RTL compiler on your design is ./rc/cordic_rc. This
script calls two different scripts that are located in ./cordic/rc/scripts. These two scripts
are :
user_param.tcl
cordic_core_synth.tcl
User_param.tcl contains 1 parameter that you need to adjust for your technology, and
some that you may want to adjust based on your design preferences. The parameter that
you need to change is the USER_AVOID_CELLS parameter, which is based on your
technology. This parameter should contain any cells that you do not want the RTL
compiler to use when synthesizing your logic down to a gate-level verilog netlist. This
logic includes IO cells, clock buffers, and VDD/GND pads. If you do not specify to
avoid these cells, RTL compiler, for instance, may mistake an IO cell for a buffer, since
functionally they appear to be the same. Clock buffers are avoided at this stage because
they are meant for use in clock-tree-synthesis (CTS) which does not happen until the
back-end flow.
Other parameters in this file that you may want to modify are the RTL optimization
settings. For instance, you can tell RTL compiler to use a high synthesis effort or low
synthesis effort when meeting you timing constraints (set USER_SYN_EFFORT
high/low). This will effect how hard RTL compiler tries to accurately meet your
provided timing constraints. You can also change other settings related to power, clock
gating, etc in this file. To further understand these settings, refer to the RC manual.
The ./rc/scripts/cordic_core_synth.tcl file is the main script that calls the parameters
defined in the user_param.tcl file, and launches various RTL compiler commands. This
script should be setup and parameterized to where no editing is necessary.
B. Running RC
Once the user_param.tcl script is setup, and the design timing constraints are set, we can
now launch the RTL compiler script to generate our gate-level verilog netlist. The script
to run RTL compiler is located at ./rc/cordic_rc. With your environment setup correctly,
to run this script simply cd into the ./rc directory and type :
cordic_rc
This will launch RTL compiler and run the scripts provided in the ./rc/scripts directory.
During the run, a work directory is created that will house the final gate-level verilog
netlist, and the reports generated from the RTL compiler. Once the tool finishes running,
cd into ./rc/current/netlists to view the final netlist, and cd into ./rc/current/reports to see
the generated reports. Two files of particular interest may be the errorlog and warnlog
files in the ./rc/current/reports directory. If you have not setup the rc files properly for
your project, these files will detail the warnings and errors given by RTL compiler to help
you debug and find what you have missed. The rc.log file can also be helpful for this,
which is located in the ./rc/current directory.
Chapter IV : Running the Design-for-Test Flow
Running the design-for-test (DFT) flow is very similar to the previous RTL compiler
flow. It actually uses the same tool, and the scripts are setup in the same manner. Here,
the command to launch the DFT flow is located at :
./dft/cordic_dft
In order to run this command, simply cd into the ./dft directory, and type cordic_dft. The
directory structure is setup identical to the rc directory. The output netlists and reports
are placed into the ./dft/current/netlists and ./dft/current/reports directories respectively.
The purpose of this flow is to insert scan chains into the design, so that the tester can use
the scan chains to test the final chip. As it stands, six manual scan chains are inserted
into the current design, which is done in the ./dft/scripts/scan_chain.tcl script. A snip of
this code is shown here in Fig. 6.
Figure 6: Code sample from the DFT flow. Shows the scan chain definitions and setup.
There are four important things to note from this code snip. The first is the define_dft
shift_enable statement. This statement defines the top-level node which is used to control
the scan shifting when the scan-chain is enabled. In the code snip shown in Fig. 6, the
shift enable signal is defined from the output of the IO pad io_p140. In your design, you
should choose the correct port to define your shift_enable signal from. This should be
connected to a pad, since this shift enable signal will come from off-chip.
The next important thing to note is the define_dft test_mode statement. This signal
defines when the chip is in test mode, and is using the scan chain. In the example shown
in Fig. 6, this signal is defined from the output point of IO pad io_p141.
The next statements to note are the actual scan chain definitions. In this example, 6
chains are defined, and are running between the input and output ports the cordic
processor core. Here, you can create an arbitrary number of chains, you must define the
ports which the chains run between, and you must define whether the chains share
outputs with another port (muxed output or not). If you don’t define the outputs as –
shared_out, then the scan insertion procedure will insert extra top-level ports in your
design to use for scan outputs. Additionally, you must have more than 2 scan chains for
the scan-synthesis to work, or else RTL compiler will complain that it cannot optimize
it’s scan structures.
The last thing to note here is that you must define a test clock signal. You can define this
signal to be the same clock used for the rest of your design, however you could also
choose to use a different clock for your scan chain. However, if you do this, you will
have to optimize the design flow to include multiple clock signals.
Chapter V : Running the Back End Flow
A. Setting up the initialization file
Cadence Encounter is the chosen Cadence tool to run the back-end synthesis flow. The
first required step to run the back-end flow is to setup two initialization scripts. These
scripts are :
./fe/scripts/init.tcl
./aux/forFE/Design_top.tg
We will discuss the init.tcl file first since it’s more important, and contains more
information. The first thing to change is the clock buffer list in the command :
set USEFUL_SKEW_BUF_LIST {}
Here you need to add all of the clock buffer cells into this list to let Encounter know what
cells it can use when synthesizing the clock tree. The next statement to change is the
setSIMode command. Here you can define the technology node within the parameter.
Change this command accordingly.
setSIMode … 90nm
Next you need to modify two commands that set the allowable routing layers. These
commands are as follows :
setNanoRouteMode –routeTopRoutingLayer top
setNanoRouteMode –routeBottomRoutingLayer bottom
These commands are already listed in the init.tcl file, you just need to replace the top and
bottom with the number of your top and bottom routing layers. For instance, if you’re
using a 7 metal layer process, your top routing layer could be 7, and you bottom routing
layer could be 1.
The last thing to change in this file is the die size. These parameters are :
set diex
set diey
Here, just enter the size of your die in microns in these fields.
The last file to change for setup is the located at ./aux/forFE/Design_top.tg. This file
again contains some information about the clock and it’s duty cycle. Simply open this
file, make sure the clock signal is named correctly, enter the clock frequency in MHz, and
enter the duty cycle next to it.
B. Running the back-end scripts
Once you’ve setup the initialization scripts, running the back-end flow is very similar to
running the other flows introduced earlier. The script to launch the back-end flow is :
./fe/cordic_fe
Typing cordic_fe in the ./fe directory will launch the back-end Cadence Encounter flow.
This script launches a number of Encounter scripts, which do everything from floorplan
the chip, place the standard cells, synthesize the clock tree, and route the final netlist.
The following is a brief list of the steps taken to synthesize the final chip.
1) Floorplan the design – Defines the chip area, and sets up the IO pad ring
2) Place – Places the standard cells, and places any defined custom blocks.
3) Power Routing – Routes the power ring and stripes. Connects power to the
standard cells.
4) Clock tree synthesis – Synthesizes the clock tree into the design.
5) Scan Reordering – Reorders and optimizes the scan chain.
6) Nanoroute – Detail routes the final design.
7) Add filler – Adds filler standard cells into the design.
8) Write data – Writes out the final netlist, and writes out a gds layout.
At each step in the flow, a Encounter layout is generated and saved. These netlists can be
found in ./fe/work/data/step/Design_top.enc. Here, step indicates which script was
running. For instance, if you want to see the result from the place step, cd into
./fe/work/data/place/ and the .enc file there will be the encounter file generated during the
synthesis run. If you have your environment setup as shown in Chapter I, you can launch
Cadence Encounter by typing encounter in your terminal. Click Design->Restore Design
->SoCE, then type in the .enc file you would like to view and click OK to see the GUI
version of this Encounter step.
Additionally, when running the flow, log files are written into the ./fe/work directory.
The errorlog, warnlog, and encounter.log files are useful to debug if errors or warnings
are received when running the encounter flow.
Chapter VI : Simulating the RTL and Encounter Generated Netlists
NCVHDL/NCVLOG/NCELAB/NCSIM/SIMVISION compose the Cadence tool bundle
for compilation and simulation of both behavioral HDL code and gate-level verilog
netlist synthesized from RTL compiler or Encounter. This section shows how we have
setup the script for running these simulations with the Cadence tools, and how you can
use and modify it for your own project.
A. Compiling and Simulating the Design
The main scripts to compile and simulate your design are in ./ncsim
cd ./ncsim
cordic_sim_<step_name>,
where <step_name> should be changed with one of the following options: ‘bh’, ‘rc’ or
‘fe’. The scripts can be run without any parameters in the shell command line, since the
design files and other files needed for simulation are either set within the scripts or
generated before being used in the scripts. Therefore ‘cordic_sim_bh’ simulates the
behavioral design in the ./hdl directory, the ‘cordic_sim_rc’ simulates the gate-level
verilog netlist synthesized from RTL compiler, and ‘cordic_sim_fe’ simulates the gatelevel verilog netlist generated from Encounter with clock tree and buffers inserted.
The ‘cordic_sim_<step_name>’ scripts automatically sets up logic libraries, and calls
corresponding scripts in ./ncsim/scripts/ directory to compile and simulate the design with
NCVHDL/NCVLOG/NELAB/NCSIM, using the testbench in the ./hdl/testbench/
directory. The testbench is ‘self-checking’, in that it not only supplies input values to the
design but also checks output values from the design and compares them with the correct
value. If all simulation results are correct a ‘simulation successful’ statement would
appear at the end of the ouput when running the scripts, otherwise an error would pop up
and reports the simulation time point when the output value and correct value doesn’t
match. Any setup/hold time violation would be reported during the simulation when
synthesized netlists from RTL Compiler or Encounter are simulated, if the cells in the
verilog file provided by the library vendor have timing information embedded.
Although running the scripts with no parameters is perfectly fine for most of the time, the
‘cordic_sim_<step_name>’ scripts can actually take parameters. Those parameters can
change the default behavior of the scripts. For example, the default simulation results are
stored in ‘work_<step name>’ where <step name> is the same as in the script that is
called. This can be changed by providing a directory name when running the scripts.
Other parameters that can be provided include the format of simulation results and
simulation corner of the technology. A short message of the correct format would be
printed if the parameters are not correctly provided.
B. Visualizing the Simulation Results
Once the simulation finishes, the user can go into the directory where the simulation is
stored. Take the example of RTL Compiler netlist simulation. In the default case (when
the user runs ‘cordic_sim_rc’ with no parameters), the result is in
./ncsim/work_rc/rc.shm. Type
cd ./ncsim/work_rc/rc.shm
simvision &
In the command line and Cadence SIMVISION will be started. Once the SIMVISION
console window is popped up, go to ‘File’->’Source Command Script’ and choose
‘./ncsim/scripts/cordic_vision_rc.sv’ and click ‘OK’. This would automatically bring out
the waveform window named ‘RC simulation results’ and have all primary input/output
port waveforms displayed. The user can either edit the ‘cordic_vision_rc.sv’ file or just
use the SIMVIION GUI interface to add or delete other internal signal waveforms they
want to see.
Chapter VI I: Formal Verification
Function verification checks the equivalence or two netlists logically. This assures the
user the logic correctness of the synthesized or optimized netlists from frontend or
backend tools. The Cadence tool for formal verification is called LEC.
This step is done in ./lec. The shell script to run is called ‘cordic_lec’and it calls
corresponding scripts in ./lec/scripts/ directory internally:
cd ./lec
cordic_lec [bh2rc | bh2fe | rc2fe]
The script ‘cordic_lec’ takes in one parameter, which specifies which two netlists the user
wants to compare. For example, ‘bh2rc’ compares behavioral netlist and RTL Compiler
generated netlist, and ‘rc2fe’ compares RTL Compiler and Encounter generated netlists,
etc. Formal verification should pass after any synthesis or optimization step is done. The
result is stored in the log file, which should say something like ‘the two netlists are
equivalent’ at the end.
Chapter VIII : Importing Design into Cadence Virtuoso Environment
A. Streaming in schematics
In order to view your design in the actual Cadence design environment, you need to
stream in the final netlists and gds layouts into the Cadence. We developed two scripts
two perform this procedure. This section discusses the script for streaming in schematics.
This script is located at :
./ic/schin
The first required step is to open this file and modify the first two defined variables,
techLib and stdcellLib. The techLib variable should be set to the technology library
name as defined by your working design kit. The stdcellLib variable should list out the
various standard cell library names you’re using, separated by a comma. If you’re unsure
as to what these library names are, they are the library names that are specified in the
Library Manager in Cadence. You can view these libraries by launching Cadence in your
environment, and clicking Tools->Library Manager.
To run the schematic stream-in script, cd into the directory where you want to house your
schematics and layouts. This does not necessarily have to be your working directory for
your synthesis project, and probably will not be. Once there, launch the schin in script
(./ic/schin). A new library will be created in your library manager called Design
(whatever your design name is), and will contain the schematics for the top level design,
and all of it’s subdesigns.
B. Streaming in layouts
The next step is to stream in layouts using the script here :
./ic/lytin
Again, you need to change the first two variables techLib and stdcellLib to match your
design kit. Once this is done, you run the tool in the exact same manner as the previous
schin tool. CD into your schematic and layout directory, and launch the lytin script
(./ic/lytin). If you ran the schin script previously, this will load the top level layout into
the same library created for the schematics. If you did not run the schin script previously,
this command will create the layouts in a new library called Design.
In later revisions, the goal is to not have any manual insertion into these scripts. The
reason the manual changes are still required is that the syntax of this file type is not fully
understood at this time, which makes it challenging to bring in variables from outside
files. Once this challenge is understood, we will update these scripts accordingly.
Chapter IX : Simulating the Schematic and Extracted Netlists
A. Simulation
Schematic and extracted netlists simulations are performed with Cadence tool Ultrasim,
and this step is done in directory ./mmsim.
To simulate schematic, run
cd ./mmsim
cordicrun sch
This script would use Ultrasim to perform a transistor level simulation with transistor
delay/power models provided by the library vendor. Different from the logic level
simulation of behavioral or gate level HDL netlist described earlier, the simulation here is
essentially analog and produces more accurate and realistic results, at the expense or
simulation time.
To simulate the design with extracted parasitic parameters, use
cordicrun ext
C. Visualizing Simulation Results
Simulation results at this step are stored in ./mmsim/work. ./mmsim/work/cordicraw_sch/
stores results for schematic simulation and ./mmsim/work/cordicraw_ext/ stores extracted
view simulation.
Again, Cadence SIMVISION can be used to view the waveform, as in the logic
simulation in Chapter VI . Scripts for automatic opening and setting up waveform
windows and adding/deleting signals are in ./mmsim, named as <design_name>_sch or
<design_name>_ext, for schematic and extracted netlist respectively.
Chapter X : Sign-off Steps
1)
2)
3)
4)
5)
6)
7)
Simulate RC generated netlist
Simulate Encounter generated netlist
Import Design into Cadence Environment
DRC
LVS
Simulate schematic design (takes many hours)
Simulate extracted layout design (takes many hours)