( ESNUG 419 Item 7 ) -------------------------------------------- [10/08/03]
From: Reza Hariri <rhariri=user domain=sequencedesign got calm>
Subject: A "How To" Using Sequence PhysicalStudio Along With Apollo/Astro
Hi John,
Some of our customers have integrated Sequence's PhysicalStudio tool suite
into their existing Apollo/Astro flow. I thought a note on the basic flow
and lessons learned through the integration process would be useful to your
readers.
Prior to joining Sequence, I was a user of PhysicalStudio at my previous
company, where we successfully integrated the tool into just such a flow:
Synthesis (Design Compiler)
|
V
Placement (Apollo/Astro)
|
V
Pre-route prediction & avoidance (PhysicalStudio)
|
V
Routing (Apollo/Astro) ------>--------
| | |
| V |
| Parasitic Extraction |
| (STAR or Columbus) |
| | |
| V |
V (PhysicalStudio) |
---> Post-route analysis & optimization |
| | |
| V |
---- ECO-route (Apollo/Astro) ---<---------
|
V
Design finishing
|
V
LVS/DRC (Calibre or Hercules)
Table of Contents
=================
1) Source Files
a) Netlist
b) Placement and preroutes
c) Signal Parasitics
d) Timing Constraints
2) Running PhysicalStudio
a) Running Columbus extraction
b) .studio General Parameters File
c) ElMo signal and voltage integrity Libraries:
d) sample run script for a post-route optimization
3) Running ECO_route in Apollo/Astro
a) PhysicalStudio output files
b) Performing the ECO_route
1) Source files:
----------------
All the library specific information can be provided in industry standard
formats, including .lib, .lef as well as the Avanti techfile .tf
The design specific information can be categorized in the following five
groups:
Netlist
Placement
Routing
Signal Parasitics
Timing constraints
a) Netlist
----------
The netlist is dumped from Apollo/Astro using the following commands:
;for hierarchical verilog out
;first recreate a hierarchical netlist
auCreateHierNetlist
setFormField "Create Hierarchical Netlist" "Lib.Name" "Lib.Name"
setFormField "Create Hierarchical Netlist" "Cell Name" "CellName"
(setFormField "Create Hierarchical Netlist"
"reference Netlist Cell Name" "CellName.NETL" )
(setFormField "Create Hierarchical Netlist" "Output Cell Name"
"CellName.HNET" )
(setFormField "Create Hierarchical Netlist"
"Create Scan Chains Nets" "1" )
(setFormField "Create Hierarchical Netlist"
"No Assign Created In Verilog" "1" )
formOK "Create Hierarchical Netlist"
;then output the hierarchical netlist
auHierVerilogOut
setFormField "Hierarchical Verilog Out" "Library Name" "LibraryName"
setFormField "Hierarchical Verilog Out" "Cell Name" "CellName.HNET"
(setFormField "Hierarchical Verilog Out" "Verilog Out Data File"
"chip.vg" )
(setFormField "Hierarchical Verilog Out"
"Output Bus As Individual Bits" "0" )
(setFormField "Hierarchical Verilog Out"
"Reference Top NETL Cell to Output Bus" "CellName" )
setFormField "Hierarchical Verilog Out" "Output Wire Declaration" "1"
setFormField "Hierarchical Verilog Out" "No Diode Ports" "0"
(setFormField "Hierarchical Verilog Out"
"No Core Filler Cell Instances" "0" )
formOK "Hierarchical Verilog Out"
This results in a Verilog file called chip.vg.
b) Placement and pre-routes
---------------------------
The following commands will perform the dumping of the placement and pre-
routes:
; dump placement and pre-routes
axgDumpFloorPlan
setToggleField "Dump Floor Plan" "Type" "io cell placement" 1
setToggleField "Dump Floor Plan" "Type" "std cell placement" 1
setToggleField "Dump Floor Plan" "Type" "macro cell placement" 1
setToggleField "Dump Floor Plan" "Type" "row" 1
setToggleField "Dump Floor Plan" "Type" "track" 1
setToggleField "Dump Floor Plan" "Type" "region" 1
setToggleField "Dump Floor Plan" "Type" "Floor Plan group" 1
setToggleField "Dump Floor Plan" "Type" "Blockage/Density" 1
(setFormField "Dump Floor Plan"
"No Backslashes in Cell Instance Names" "1" )
setFormField "Dump Floor Plan" "Output Filename" "floorplan.dmp"
formOK "Dump Floor Plan"
; The following is to make sure std. cell rail connections are not
; dumped out as a part of the power grid, but if you do this, be
; sure to close the cell without saving
axgDelRouteType
setToggleField "Delete Route Type" "Signal" "detailed route" 1
setToggleField "Delete Route Type" "Signal" "user" 1
setToggleField "Delete Route Type" "Clock" "ring" 0
setToggleField "Delete Route Type" "Clock" "strap" 0
(setToggleField "Delete Route Type" "Clock"
"tie off (detailed route)" 1 )
setToggleField "Delete Route Type" "Clock" "user" 0
setToggleField "Delete Route Type" "P/G" "ring" 0
setToggleField "Delete Route Type" "P/G" "strap" 0
setToggleField "Delete Route Type" "P/G" "tie off (detailed route)" 1
setToggleField "Delete Route Type" "P/G" "user" 1
setToggleField "Delete Route Type" "P/G" "std cell pin conn" 1
setToggleField "Delete Route Type" "P/G" "macro/IO pin conn" 1
setToggleField "Delete Route Type" "Misc" "bus" 0
setToggleField "Delete Route Type" "Misc" "shield" 0
formOK "Delete Route Type"
axgDumpRouting
setFormField "Dump Routing" "Output File Name" "routing.dmp"
formOK "Dump Routing"
These two files then need to be concatenated in Unix into a single file
containing both the placements and the preroutes. In Unix:
cat floorplan.dmp routing.dmp > placement_preroute.scm
This will result in a placement and pre_route Scheme file called
placement_preroute.scm. The pre-routes are used for two purposes. In pre-
or post-route optimization, the user may specify certain pre-route layers
as placement blockages, thus avoiding placing cells under them, such as
metal two power straps. Additionally, in pre-route optimization, they are
used to determine the amount of route resources available.
Finally, a LEF file needs to be generated, this is done using the makeLEFDEF
command. It generates the LEF file at the same time as it generates the DEF
files for Columbus extraction.
c) Signal Parasitics
--------------------
Next, the signal parasitics can be extracted using STAR-RC-XT via this
command file:
MILKYWAY_DATABASE : /home/projectX/rev1.8/DESIGNS
BLOCK : top
MAPPING_FILE : /home/projectX/rev1.8/libs_etc/map.dat
TCAD_GRD_FILE : /home/projectX/rev1.8/libs_etc/techY.grd
NETLIST_FORMAT : SPEF
NETLIST_FILE : ./top.spef
* ==================
* Extraction Options
* ==================
COUPLE_TO_GROUND : NO
COUPLING_MULTIPLIER : 1
EXTRACTION : RC
REDUCTION : YES
REDUCTION_MAX_DELAY_ERROR : 6e-15
COUPLING_REL_THRESHOLD : 0.01
COUPLING_ABS_THRESHOLD : 1e-15
* ===============
* Netlist Options
* ===============
NETLIST_CONNECT_OPENS : *
NETLIST_DELIMITER : : ** Other Valid settings are: . or | or /
NETLIST_INSTANCE_SECTION : YES
NETLIST_CONNECT_SECTION : YES
NETLIST_NODE_SECTION : YES
NETLIST_SUBCKT : YES
NETLIST_NAME_MAP : YES
NETLIST_TIME_UNIT : 1e-09
NETLIST_RESISTANCE_UNIT : 1
NETLIST_CAPACITANCE_UNIT : 1e-15
* NETLIST_TEMPERATURE : -
NETLIST_LOGICAL_TYPE : VERILOG
Alternatively, Columbus-Turbo can also be used to generate sign-off quality
parasitics files. In order to do this, the route information must be dumped
out in a DEF format using the following commands.
First Add the following lines to your .avntrc file.
; Load Apollo/Columbus conversion utility
load (string-append (getenv "SEQUENCE_ROOT")
"/lib/apollo_interface/lefdef/LEFDEF.scm")
Then, in a Milkyway session at the tool prompt, type in the makeLEFDEF
utility using the following syntax:
(makeLEFDEF "library_name" "cell_name" "lef_name" "def_name")
Example:
(makeLEFDEF "ST703" "CPU" "cpu.lef" "cpu.def")
The resulting DEF, along with the generated LEF files, can then be run
through Columbus-Turbo to generate the SPEF files required for post-route
optimization in Studio.
d) Timing Constraints
---------------------
Finally, the timing constraints are loaded in SDC format. Users can
provide native SDC files if they have them. For those customers who use
PrimeTime in their flow, they can easily generate an SDC file from PrimeTime
using the following commands:
# First ensure that your design as well as the timing constraints
# have all been loaded into the PT session.
# Before writing the SDC be sure to set the proper scope
current_design top_module_name
# Then write out the SDC using the following command
write_sdc top_module.sdc
2) Running Columbus and PhysicalStudio
--------------------------------------
a) Running Columbus extraction
------------------------------
An example run script for Turbo which can be used after having run sctrans:
layers columbus.layermap
layout -reuse
library technology.proclib
result_db -dir ./ppd # Extraction results are saved in this directory
coupling -on -normal
decouple_xcap -total_cap 5e-15 -total_cross_cap 1e-15 -percent_cross_cap 1
# -total_cap : decouples to ground all coupling caps to a net if
# the total net capacitance is below the threshold
# -total_cross_cap : decouples to ground all coupling caps to a
# net if the total coupling between the net and an aggressor is
# less than the threshold -percent_cross_cap : decouples to
# ground all coupling caps to a net if the total coupling between
# the net and an aggressor as a percentage of total net capacitance
# is less than the threshold
net_reduction_maxr 75
# Instructs Turbo to insert node points every 75 ohms along a
# signal line - creates buffer insertion points for PhysicalStudio
extract -all
write output.spef -spef -nameMap -xy -mdml
# The -xy option on the write statement inserts node/pin/port
# coordinate information into the SPEF output. The -nameMap option
# produces smaller SPEF file sizes
One thing to note is that the accuracy of the noise analysis vs. runtime is
affected by the granularity of the SPEF file. Extraction engines have the
ability to filter the coupling capacitances, generally based on two metrics:
1.) the absolute value of a given coupling capacitance, and
2.) the percentage of the total capacitance of the given net that
consists of the coupling capacitance in question.
If it falls below either threshold, it will simply be grounded in the
resulting SPEF file. The settings stated above are conservative settings as
the starting point. The user may wish to do his own analysis to fine-tune
the settings for their purposes. Additionally, many users prefer to trade
off accuracy in favor of runtime at the earlier stages of the design, and
crank down on the accuracy as they approach tapeout. The settings provided
above are those recommended for tapeout for a typical 0.13 um design.
b) .studio General Parameters File:
-----------------------------------
Once all the input files are available, they need to be specified in the
Studio general parameters file called "CHIP.studio" -- assuming that
the top module of the design is called CHIP. CHIP.studio may look like:
# For a post-route timing analysis flow, the following constitute a
# sufficient set of input files to be specified
set synopsys_lib { ../libs/standard_cells.lib \
../libs/memories.lib \
../libs/I_Os.lib \
::::::
}
set cell_lib_lef {
../libs/standard_cells.lef \
../libs/memories.lef \
../libs/I_Os.lef \
::::::
}
set verilog_netlist { ../design_files/top_module.vg \
../design_files/sub_module_A.vg \
::::::
}
set floor_plan_scheme preroute_and_placement.scm
set synopsys_write_sdc chip.sdc
# Note that if the spef file is compressed with a .gz file extension,
# Studio will automatically decompress the file as needed
set spef chip.spef.gz
# The following additional parameters need to be set for a design
# with two levels of physical hierarchy. Note that both the
# floor_plan pla file and spefs are specified for each physical
# block and each entry consists of the hierarchical name of the
# block and the associated pla or spef file.
set leaf_pla { \
{blockA_inst0 ../pla_files/blockA.pla} \
{blockA_inst1 ../pla_files/blockA.pla} \
{blockB_inst0 ../pla_files/blockB.pla} \
:::::
}
set leaf_spef {
{blockA_inst0 ../spef_files/blockA.spef.gz} \
{blockA_inst1 ../spef_files/blockA.spef.gz} \
{blockB_inst0 ../spef_files/blockB.spef.gz} \
:::::
}
# The SPEF files must all either be compressed with a .gz extension
# or must all be uncompressed.
#
# The following enables dual corner analysis and optimization
set synopsys_min_lib { ...}
set min_spef
# and if applicable chip.min.spef.gz
set min_leaf_spef { ...}
# Coupling Delay settings (NoiseAnalysis)
#
# For coupling delay, no additional files are required as Studio
# uses the timing information in the standard .libs to determine
# the impact of coupling on delay. However, the user does need
# to ensure that the .spef files do include fully coupled (i.e.
# non grounded) coupling capacitances, otherwise the timing
# analysis and coupling delay analysis numbers will be identical.
#
# GlitchAnalysis settings
#
# For accurate and comprehensive GlitchAnalysis, PhysicalStudio uses
# an adjunct signal integrity library .silib which can be generated
# using the ElMo ElectricalModeler characterization tool from Sequence.
# In order to use this library, it must be specified in the .studio file:
set si_lib {../LIBS/standard_cells.silib \
../LIBS/io_cells.silib \
: : : : : : : :
}
# for dual corner analysis, the following needs to be set
set si_min_lib { ...}
# Runtime vs. Accuracy settings:
#
# The user may fine tune the runtime vs. accuracy "knobs" based on
# their needs. Here are some recommendations (comment one out).
#
# Early FAST settings:
set spf_reduction_order 2
# ACCURATE setting (which is the default):
set spf_reduction_order 4
c) ElMo signal and voltage integrity Libraries:
-----------------------------------------------
To enable the signal and voltage integrity parts of PhysicalStudio, namely
the GlitchAnalysis and voltage-derated timing/noise/glitch analysis to give
the most accurate results, the cells need to be characterized for signal and
voltage integrity. Sequence provides ElectricalModeler, a characterization
engine which by using the SPICE sub-circuits as well as the .lib and lefs of
the cells, and a SPICE simulator, currently HSPICE, runs all the required
simulations and assembles all the data into an adjunct library file
called the .silib file.
d) Sample run script for a post-route optimization
--------------------------------------------------
A typical analysis and optimization script. BE SURE TO COMMENT OUT SPECIFIC
COMMANDS TO SUIT YOUR NEEDS! Tailoring is required!
# Basic Analysis and PostRouteOptimization run
# Runtime vs. Accuracy settings:
#
# As mentioned earlier, the user may fine tune the runtime vs.
# accuracy "knobs" on the signal integrity analysis commands as
# well.
#
# For the NoiseAnalysis command, the following is the fastest setting
# possible
NoiseAnalysis -compatible_mode fast_min_max
# The GlitchAnalysis command may be run either in Noise mode or in Timing
# mode. The fastest mode of all is the Timing mode as shown below
GlitchAnalysis -ta_mode timing
# However, if you wish to run GlitchAnalysis in Noise mode,
# the -compatible_mode option may be used to speed it up. The
# following is the fastest noise mode setting
GlitchAnalysis -compatible_mode fast_min_max -ta_mode noise
DataPreparation
LoadLib
LoadNetlist
LoadTimingConstraint
LoadPlacementConstraint
LoadParasiticFile
# PRO is first run in timing mode so that it can
# fix all the TA timing violations as fast as possible
TimingAnalysis -ta_type both -ta_corner dual
# Detailed reports can be obtained using the ta_print_path command
# in both TimingAnalysis mode as well as NoiseAnalysis mode
PostRouteOptimization
LegalizePlacement
# By default, the switching events on each signal is broken down
# into 32 switching windows or "time slices". This value can be
# set anywhere from 1 to 128. The higher the value, the less
# pessimistic the analysis, but there is a potential runtime impact
# associated with this variable.
setvar si_clock_period_windows 64
# The following group can be used to "smudge" the switching events
# determined by timing analysis and introduce some pessimism into
# the determination as to whether signals overlap or not. As the
# window uncertainty is increased, or the leading edge or trailing
# edge are multiplied by a number greater than one, the
# probability that two capacitively coupled nets will be found to
# potentially switch simultaneously will increase, resulting in a
# more conservative determination of the value of the Miller
# coefficients and hence the coupling delay, as well as glitch
# interactions.
setvar si_window_uncertainty 0.100
setvar si_edge_time_window_lead_mult 1.1
setvar si_edge_time_window_trail_mult 1.1
# Often times, for simplicity, clocks which are asynchronous or
# which can be varying multiples of each other depending on
# operating mode, are set to be the same value, or exact multiples
# of each other. Although such cases can simplify TimingAnalysis
# without causing any loss of coverage, when dealing with signal
# integrity, such an approach can falsely mask potential coupling
# delay or glitch violations. PhysicalStudio automatically detects
# asynchronous clock domains from the timing constraint file,
# however, if two clocks are artificially set to be the same or
# multiples of each other, they can be forced to be asynchronous
# for the purposes of signal integrity analysis for both coupling
# delay as well as glitch analysis purposes.
si_set_asynchronous -from CLK1 -to CLK2 CLK3
# In NA mode, ta_corner slow is used in order to close all setup
# AND hold timing in the slow corner. This is because fast corner
# hold violations are not necessarily a superset of the slow
# corner hold violations
NoiseAnalysis -ta_type both -ta_corner slow
PostRouteOptimization LegalizePlacement
# Finally phase4H is run to fix fast corner hold violations
# while setup is still being checked in slow corner
NoiseAnalysis -ta_type both -ta_corner dual
PostRouteOptimization
LegalizePlacement
# Additionally, the following variables can be used to adjust
# the conservatism for GlitchAnalysis. To begin with, default
# settings should be used.
setvar si_aggressor_rise_time_multiplier 0.9
setvar si_aggressor_fall_time_multiplier 0.9
setvar si_glitch_up_magnitude_multiplier 1.1
setvar si_glitch_dn_magnitude_multiplier 1.1
setvar si_rdrive_high_multiplier 1.1
setvar si_rdrive_low_multiplier 1.1
# The above setting will add a 10% margin to each of the
# parameters. For example, multiplying the aggressor rise time by
# 0.9 makes it faster (for the purposes of glitch calculation) and
# will therefore result in a larger glitch on the victim.
# The following variable has a significant impact on the accuracy
# vs. runtime. The "weighted" setting does make the results quite
# pessimistic, but it runs significantly faster, so you may need
# to try it out and decide if the additional false violations are
# worth the saved runtime.
setvar si_glitch_model_type worst_case | weighted | distributed
# The following option can be used to specify the cell(s) to be
# used for glitch suppression. If available, such cells should
# ideally have propagation delays on par with normal buffers,
# while being less susceptible to propagating glitches.
setvar si_noise_suppress_buffers ref_cell_name(s)
GlitchOptimization -slack_margin 0.2 -slack_check worst -propagation 1
# The following generates the final output files for taking the
# optimized design back into Apollo/Astro to be eco_routed
WriteFinalPlacement
exit
3) Running ECO_route in Apollo/Astro:
-------------------------------------
a) PhysicalStudio output files
------------------------------
The output files from the above script will reside under
working_xx/xx_WriteFinalPlacement
directory. Of particular interest are the files CHIP.final.clone_list and
CHIP.final.ApolloECOByChange.scm
The top_module.final.clone_list contains a one-to-one mapping of the
original net name and the new net which has been created as a result of
inserting a buffer somewhere along the route of the original unbuffered net.
The following is a short excerpt.
I1/I1/N2050 I1/I1/GB_0_1_1_N_N2050
I4/I1/N2517 I4/I1/GB_0_1_0_N_N2517
This information is then used to ensure as little perturbation as possible
to the routes during the eco_route process. This will in turn maximize pre-
and post-eco-route timing correlation and minimize the number of iterations.
b) Performing the ECO_route
---------------------------
Finally, the user needs to simply run the file by typing:
Load top_module.final.ApolloECOByChange.scm
This takes care of all the naming issues and the route preservation, creates
a copy of the original cell, performs the eco_route and saves the results.
Unless the original cell already had route congestion issues, the script
will automatically complete the eco_route. The resulting cell can then be
dumped again, the spef re-extracted and the timing, coupling delay, and
glitch can then be re-verified in PhysicalStudio.
Once these parameters meet the user's requirements, then the final wrap up
work can be completed in Apollo/Astro.
- Reza Hariri
Sequence Design, Inc. Santa Clara, CA
|
|
