Cadence Digital Design Synthesis Flow
Cadence Digital Design Synthesis Flow
Cadence Digital Design Synthesis Flow
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.
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).
./
will
imply
./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.
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 doesnt 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.
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 Ns and Es 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(1b0), .TEN(1b0)
);
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.
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.
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 dont 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
its 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.
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.
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 youre using, separated by a comma. If youre 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 its 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.