This example describes a global timing characterization methodology. It is based upon a simple 4-bit adder-accumulator.
This example takes place in the directory addaccu/.
Timing characterization provides the timing properties (or constraints) of a macroblock, generally in the Liberty format. The purpose of the timing characterization is to provide other tools in the design flow - physical design, chip-level STA - with sufficient timing information about the macroblock, so that those tools can perform their task correcly. Typically, the information given in the Liberty file are:
We describe here a methodology for secure timing characterization of macroblocks and cells. The following steps are involved:
The addaccu chip consists of a four-bit adder, a four-bit register, and a 2 to 1 four-bit multiplexer.
The circuit performs an addition between either the b[3:0] and a[3:0] inputs when sel is set to 0, or between b[3:0] and the content of the four-bit register when sel is set to 1. The content of the register is overwritten by the values of the outputs s[3:0] on each falling edge of the clock, ck..
The temperature and supplies specifications take place in the addaccu_schem.spi file:
.TEMP 125 .GLOBAL vdd vss Vsupply vdd vss DC 2.0 Vground vss 0 DC 0 |
As the addaccu_schem.spi subcircuit is not instantiated, the vdd and vss signals appear in the .GLOBAL statement.
In the present example, the .INCLUDE statement is used for technology file integration:
.INCLUDE ../techno/bsim4_dummy.ng |
The additional configuration required for the database construction takes place in the db.tcl script. The script also launches the commands that effectively generate that database.
Configuration variables are set in the Tcl script by the mean of the avt_config function.
avt_config tasGenerateConeFile yes | |
tells the tool to dump on disk the .cns file, which contains the partitions (the cones) created by the partitioning algorithm. | |
avt_config avtVerboseConeFile yes | |
tells the tool to dump on disk the .cnv file, which is a more readable version. | |
avt_config simVthLow 0.2 | |
Low threshold of slope definition | |
avt_config simVthHigh 0.8 | |
High threshold of slope definition | |
avt_config simToolModel ngspice | |
tells the tool the technology file type (which simulator it is designed for) |
The construction itself is done through the command hitas:
avt_LoadFile addaccu_schem.spi set fig [hitas addaccu] |
The paths.tcl script reports the timing paths involved in the constraints described above (setup, hold, access and combinational paths).
Let's have a look at the following code sequence in the script:
# Setup / Hold paths set file [fopen $figname.setuphold w] ttv_DisplayConnectorToLatchMargin $file $fig * "split all" fclose $file |
The function ttv_DisplayConnectorToLatchMargin displays the setup and hold constraints associated with the input pins, related to the clock signal created with the create_clock statement (note that the frequency information is irrelevant here, as setup and hold constraints do not depend upon frequency - the syntax just requires it). Precisely, for each input pin, the ttv_DisplayConnectorToLatchMargin function displays all possible setup and hold values, depending on the latch involved. All information about the data paths, clock paths and latch involved is reported in the addaccu.setuphold file.
Now let's look at the maximum access paths detection. The related code sequence is:
# Max access paths set file [fopen $figname.accessmax w] set pathlist [ttv_GetPaths $fig * s\[*\] ?? 0 critic access max] ttv_DisplayPathListDetail $file $pathlist fclose $file |
The ttv_GetPaths function looks for all (argument 0) the access paths ending on signals s[0:3], using maximum path values for data and clock. The whole detail of those paths is reported in the addaccu.accessmax.
The next code sequence deals with minimum access paths, and is very similar to the one described above. The ttv_GetPaths function looks here for all the access paths ending on signals s[0:3], using minimum path values for data and clock. The whole detail of those paths is reported in the addaccu.accessmin file.
The final code sequence deals with combinational paths between input and output pins:
# Combinatorial paths set file [fopen $figname.comb w] set pathlist [ttv_GetPaths $fig a\[*\] s\[*\] ?? 0 critic path max] ttv_DisplayPathListDetail $file $pathlist set pathlist [ttv_GetPaths $fig b\[*\] s\[*\] ?? 0 critic path max] ttv_DisplayPathListDetail $file $pathlist set pathlist [ttv_GetPaths $fig sel s\[*\] ?? 0 critic path max] ttv_DisplayPathListDetail $file $pathlist set pathlist [ttv_GetPaths $fig ck s\[*\] ?? 0 critic path max] ttv_DisplayPathListDetail $file $pathlist fclose $file |
The whole detail of those paths is reported in the addaccu.comb file.
All these paths will be the ones which will be used to characterize the design, it is therefore necessary to carefully check that there are relevant.
The paths_simu.tcl script performs the same task as the paths.tcl script, and re-simulates the paths with NG-SPICE. NG-SPICE is a freeware SPICE simulator (Berkeley license). It is provided with this tutorial. Binaries are in ../bin/Linux/ and ../bin/Solaris/. For the sake of understanding, the set of paths - reported and simulated - has been reduced to the ones originating from some inputs only. HITAS actually generates a SPICE deck with all the stimuli allowing for signal propagation. It automatically invokes the simulator and retrieve the results, which are integrated in the reports. It just needs the following configuration:
avt_config avtSpiceString "./bin/Solaris/ngspice -b $" | |
The command line which will be invoked by HITAS | |
avt_config SimToolModel ngspice | |
Tells HITAS the SPICE format to use for the SPICE deck | |
avt_config simTechnologyName ../techno/bsim4_dummy.ng | |
The technology file to include in the SPICE deck (.INCLUDE) | |
avt_config avtSpiceOutFile $.log | |
Tells HITAS the suffix of the file containing the simulation results, required unless the simulator fixes this. | |
ttv_DisplayActivateSimulation yes | |
The flag for activating the re-simulation of reported paths |
Just invoke paths_simu.tcl to run the simulations. As before, the results are displayed in the files addaccu.comb, addaccu.setuphold, addaccu.accessmin and addaccu.accessmax. An additionnal column gives the NG-SPICE values.
The configuration is given for ngspice since the simulator is provided however another simulator can be used, for example the configuration for hspice would be something like:
avt_config avtSpiceString "hspice $" | |
The command line which will be invoked by HITAS | |
avt_config SimToolModel hspice | |
Tells HITAS the SPICE format to use for the SPICE deck | |
avt_config simTechnologyName ../techno/bsim4_dummy.hsp | |
The technology file to include in the SPICE deck (.INCLUDE) | |
ttv_DisplayActivateSimulation yes | |
The flag for activating the re-simulation of reported paths |
The timing abstraction configuration takes place in the charac.tcl script. Let's review the configuration needed:
inf_SetFigureName addaccu | |
tells the tool to apply the SDC constraints to the design addaccu. | |
create_clock -period 3000 -waveform {0 1500} ck | |
Creates a clock on signal ck. Period is not relevant, but required by the SDC syntax | |
inf_DefineSlopeRange default {25ps 50ps 100ps 200ps 400ps} custom | |
The set of slopes to be applied on input pins | |
inf_DefineCapacitanceRange default {8fF 16fF 32fF 64fF} custom | |
The set of loads to be applied on output pins |
The timing abstraction is done through the command tmabs:
set abs [tmabs $fig NULL * * * -verbose -detailfile $figname.clog] lib_drivefile [list $abs] NULL addaccu.lib max |
A file addaccu.clog is issued, which contains all the paths used for characterization.
The referent script is charac_simu.tcl. The simulation configuration is the same as in the paths_simu.tcl script, except for the two following lines:
# Simulation speed-up avt_config simOutLoad dynamic avt_config avtTechnologyName ../techno/bsim4_dummy.ng |
It just tells HITAS to transform out-of-path transistors into equivalent capacitances.
The charac_simu.tcl script simulates all the paths used for characterization and issues the addaccu_golden.lib file. It uses a cache mechanism in order to avoid resimulating several times the same path (clock paths for instance).