SPEF generation and validation

Every command below was checked before it went on this page, and anything that could not be confirmed is labelled so you know to look it up in your own install before you copy it.

Tool versions differ, and option names and defaults do move between releases, so treat every command here as something to confirm with man or the documentation that ships with your installed version.

One more convention. When something is true of parasitic extraction in general, I say so plainly. When it is specific to StarRC, ICC2 or PrimeTime, the tool is named, and when it depends on your foundry, the text says the foundry decides.

A SPEF is the extractor's description of one routed layout at one extraction corner. It carries RC and connectivity, not timing, and it is only as trustworthy as the layout and settings it came from.

SPEF is the Standard Parasitic Exchange Format, IEEE 1481. It is a text file that describes, net by net, the resistors and capacitors an extractor found in the routed layout, plus enough connectivity to hang them on the right pins. StarRC writes it, ICC2 can write its own version, and PrimeTime reads it with read_parasitics, which also accepts GPD, DSPF, RSPF and Milkyway parasitics.

AWhat is inside, and what is not

BDistributed R, ground C, coupling C

A routed wire is not one resistor and one capacitor. It has resistance spread along its length and at every via, and it has capacitance spread along its length to everything around it. The extractor chops the wire into segments, and each segment becomes a resistor between two nodes with capacitance hanging off the nodes. That is the distributed RC model, and it is what timing and SI need, while a lumped total capacitance is enough for dynamic power estimation.

Capacitance splits two ways. Capacitance to a net held at a fixed potential, power and ground shapes and the substrate, becomes ground capacitance. Capacitance to another signal net becomes coupling capacitance, because the other net switches too and that is where crosstalk comes from. Whether a given coupling capacitor survives into the SPEF as coupling, or gets folded into ground capacitance, is a setting, and by default StarRC grounds all of them. Section 6 comes back to this.

CUnits and name mapping

Every number in the body of a SPEF is a multiple of the header units. If the header says *C_UNIT 1 FF, a capacitor of 0.84 is 0.84 fF, and the same value under *C_UNIT 1 PF would be a thousand times bigger. Tools read the header, so this only bites when someone hand-edits a file or merges files with different headers, but it is the first thing worth checking when two SPEFs disagree by a clean factor of 1000.

The name map replaces long hierarchical names with *n codes to keep the file small. StarRC maps names by default (NETLIST_NAME_MAP: YES) and turning it off greatly increases file size. ICC2 write_parasitics also maps by default and has -no_name_mapping to write real names. Mapping does not change matching. PrimeTime still needs the net and instance pin names in the SPEF to match the names in the netlist it loaded, and name matching is the most common reason nets end up not annotated.

DSPEF, TLUPlus and nxtgrd are different things

EWhich analyses consume parasitics

The same design gets extracted several times, and what changes each time is the model, the engine and whether the layout is final, but only the last extraction on the final layout is a signoff input.

AImplementation extraction and signoff extraction

ICC2 extracts parasitics all the time during implementation, using the TLUPlus models you load with read_parasitic_tech and attach to corners with set_parasitic_parameters. That extraction drives optimisation and it is good enough to steer the tool. ICC2 can write it out with write_parasitics, and you should run update_timing first so the parasitics are up to date. That file is an implementation estimate. Signoff extraction is StarRC with the foundry nxtgrd, and the two should correlate but they are not the same engine or the same model.

There is a middle option, In-Design StarRC, where ICC2 runs the StarRC engine itself through set_starrc_in_design. It brings implementation closer to signoff, but it is still implementation. RC scaling factors, which ICC2 can insert into an In-Design corners file for correlation, are not meant for final signoff runs.

read_parasitic_tech -tlup <cmax.tluplus> -layermap <icc2_itf.map> -name cmax
read_parasitic_tech -tlup <cmin.tluplus> -layermap <icc2_itf.map> -name cmin
set_parasitic_parameters -corners <corner> -late_spec cmax -late_temperature 125 \
    -early_spec cmin -early_temperature 125
report_parasitic_parameters -corners <corner>
update_timing -full
write_parasitics -output <block> -format spef   ;# writes <block>.<tech>_<temp>.spef

# compare ICC2 extraction settings with a StarRC setup (reports CORR-8xx differences)
set_consistency_settings_options -exec_path <starrc_bin_dir> -tool starrc \
    -script <starrc_setup> -corner <corner>
check_consistency_settings -tool starrc

BWhich milestone is good for which analysis

CRouting ECOs, metal fill and other physical changes

A SPEF describes the layout at the moment it was extracted. Any reroute, NDR or shielding change, cell swap with new wires, or fill change after that point means the file describes a layout that no longer exists. The case that catches people is a small ECO, where ten changed nets feel too few to matter and the old SPEF gets reused, but the nets next to those ten also changed their coupling, and the new nets have no parasitics at all, so PrimeTime falls back for them in ways that look fine in a report.

StarRC has an incremental ECO flow that re-extracts only the ECO-affected nets. It needs ECO_MODE with a GPD directory, and it requires EXTRACTION: RC, COUPLE_TO_GROUND: NO and POWER_EXTRACT: NO. It includes nets directly coupled to the changed nets, but not nets one step further away; PrimeTime adjusts those. Whether you use it or a full rerun, the rule does not change: after a physical change, you extract again.

StarRC will extract an old design at the wrong corner and still report success, so whether the output means anything is decided by the inputs, not by the run.

Most extraction problems turn out to be input problems, not StarRC problems. The tool did exactly what it was told with the files it was given. This is the checklist I would walk before a signoff extraction, with the failure each missing, stale or mismatched input causes.

StarRC can read the ICC2 library directly, so on the direct route the handoff is a save, not an export. The other routes add files, and each file is a place for versions to disagree.

StarRC reads the design database directly. For gate-level extraction it accepts ICC2 and Fusion Compiler NDM libraries, Milkyway, and LEF/DEF. That gives you three practical routes out of ICC2, and they do not all need the same exports.

ARoute A: StarRC reads the ICC2 design library

Nothing needs to be exported for extraction. NDM_DATABASE is the library name you would give open_lib, and BLOCK is the block you would open, optionally as block/label. Only gate-level designs are supported this way. Metal fill in the block's FILL view is read from the database. You still write a netlist for PrimeTime, because PrimeTime reads Verilog, not NDM.

save_block
write_verilog -exclude {physical_only_cells pg_objects} <block>.v

Both -exclude values are real options. Which constructs your STA netlist should drop is a flow decision, which is why this block is marked environment-specific rather than verified.

NDM_DATABASE: <design_lib>
BLOCK: <top_block>
MAPPING_FILE: <starrc_layer.map>

BRoute B: LEF and DEF

ICC2 writes DEF with write_def; the valid versions are 5.7, 5.8 and 6.0 with 5.8 as the default. StarRC 2022.12 reads LEF/DEF 5.2 through 5.8, so a DEF 6.0 file from a newer ICC2 is a mismatch to check against your StarRC version. On the StarRC side, LEF_FILE and TOP_DEF_FILE are mandatory, the technology LEF must come first, and BLOCK is not valid because the block name comes from the DEF. LEF parasitic capacitance is ignored.

# ICC2
write_def -version 5.8 -compress gzip <block>.def.gz
write_gds -fill fill_only <block>_fill.gds      ;# only if fill goes to StarRC as GDS

* StarRC (tech LEF first)
LEF_FILE: <tech.lef>
LEF_FILE: <stdcell.lef>
LEF_FILE: <macros.lef>
TOP_DEF_FILE: <block>.def.gz
METAL_FILL_GDS_FILE: <block>_fill.gds
GDS_LAYER_MAP_FILE: <fill_layer.map>

CRoute C: In-Design StarRC

set_starrc_in_design loads a configuration file with the StarRC executable, the corner-to-nxtgrd list, the same mapping file standalone StarRC uses, and a command file. check_starrc_in_design -effort medium validates it and writes a StarRC command file you can review or run standalone, which is a good way to see what ICC2 actually asked StarRC to do.

set_starrc_in_design -config <starrc_in_design.cfg>
check_starrc_in_design -effort medium

DOther tools only when the flow really needs them

For gate-level signoff extraction from an NDM or LEF/DEF design, you do not need an LVS tool in the loop or a GDS merge step. LVS-based inputs from IC Validator, Calibre or Hercules are for transistor-level extraction and for the connectivity-interface flows. A separate GDS or OASIS file appears only if your fill lives outside the design database. If someone tells you every flow needs a conversion step, ask which database format they are starting from.

An extraction corner and a timing scenario are different objects. One SPEF per nxtgrd and temperature pair is the rule, not one SPEF per scenario.

An RC extraction corner is a process variant of the interconnect plus a temperature. StarRC defines a unique corner as an nxtgrd file combined with a pattern density specification, and each corner in the corners file carries its own OPERATING_TEMPERATURE. A timing scenario is bigger: a mode, a library PVT corner, and one parasitic corner. PrimeTime builds scenarios in DMSA with create_scenario and per-scenario scripts, and the parasitic file is one of the things a scenario script reads.

So one SPEF can serve many scenarios. Functional and scan mode at the same slow corner and 125 C can share one rcworst extraction, because the wires did not change between modes. You need a new SPEF when the nxtgrd or the temperature changes, not when the mode does.

AResistance, capacitance and temperature

Interconnect corners exist because metal width, thickness and dielectric vary, and those move R and C in different directions. A corner that makes wires fat and close pushes capacitance up and resistance down; one that makes them thin pushes resistance up. Which corner is worst for a path depends on whether the path is dominated by wire capacitance or wire resistance, which is why kits commonly ship separate C-worst and RC-worst style corners. The exact names and what each one varies are defined by your foundry, so read the kit documentation rather than a generic article, this one included.

Temperature is separate. Wire resistance changes with temperature, and StarRC applies the nxtgrd derating only if OPERATING_TEMPERATURE is set, recording it in the SPEF header. The extraction temperature should match the temperature of the scenarios that use it. A 125 C timing scenario reading a 25 C extraction is timing the wires colder than the cells.

BSimultaneous multicorner extraction

StarRC can extract up to 15 corners in one run. You define all corners in a CORNERS_FILE, pick the ones to run with SELECTED_CORNERS, and one netlist per selected corner comes out, named <NETLIST_FILE>.<corner> with CORNER_NAME in the header. In SMC mode the nxtgrd files and temperatures in the corners file win, and specifying the nxtgrd in both places is an error. All corners must share the same layer stack structure.

CORNER_NAME: cworst_125
TCAD_GRD_FILE: <kit>/cworst.nxtgrd
OPERATING_TEMPERATURE: 125
CORNER_NAME: rcworst_125
TCAD_GRD_FILE: <kit>/rcworst.nxtgrd
OPERATING_TEMPERATURE: 125
CORNER_NAME: cbest_m40
TCAD_GRD_FILE: <kit>/cbest.nxtgrd
OPERATING_TEMPERATURE: -40
* rcbest_m40 and typ_25 are defined the same way

* in the main command file
SIMULTANEOUS_MULTI_CORNER: YES
CORNERS_FILE: corners.smc
SELECTED_CORNERS: cworst_125 rcworst_125 cbest_m40

CA practical naming convention

Let the tool name the corner and do not rename files by hand. StarRC already appends the corner name, and ICC2 write_parasitics names its files <base>.<parasitic_tech>_<temperature>.spef and writes a .spef_scenario file listing the scenarios each file belongs to. What I would add is a small manifest per run: block, design label, netlist file, corner, nxtgrd path, temperature, StarRC version and date. When a scenario script reads a SPEF, it should read it through that manifest, so a scenario cannot quietly pick up the wrong corner.

StarRC turns shapes into conductors, conductors into R and C using the nxtgrd, then decides what to keep and how much to reduce. Two defaults in that chain matter more than the rest.

Two defaults in this picture change what your SPEF can be used for. With COUPLE_TO_GROUND left at YES, the SPEF has no coupling capacitors, so PrimeTime SI has nothing to work with, however carefully you set it up. And REDUCTION defaults to YES, while StarRC recommends NO_EXTRA_LOOPS when PrimeTime is the consumer.

AAn illustrative run configuration

Every command in this file is a real StarRC command used the way the tool intends. The values in angle brackets are placeholders, and the fill setting has to match how fill was inserted in your flow, so treat this as a shape to start from, not a recipe. Lines starting with * are comments.

* design (route A)
NDM_DATABASE: <design_lib>
BLOCK: <top_block>
MAPPING_FILE: <starrc_layer.map>
* corners
SIMULTANEOUS_MULTI_CORNER: YES
CORNERS_FILE: corners.smc
SELECTED_CORNERS: cworst_125 rcworst_125 cbest_m40
* extraction
EXTRACTION: RC
COUPLE_TO_GROUND: NO
REDUCTION: NO_EXTRA_LOOPS
* fill: must match your fill methodology
METAL_FILL_POLYGON_HANDLING: FLOATING
* outputs
NETLIST_FORMAT: SPEF
NETLIST_FILE: <top_block>.spef
STAR_DIRECTORY: star
SUMMARY_FILE: ./reports/<top_block>.star_sum
NUM_CORES: 8

StarXtract star_cmd
StarXtract -tech_out star_cmd                        # list options with effective defaults
StarXtract -convert_gpd_to_spef <gpd_dir> <out.spef>  # SPEF later, from the GPD
StarXtract -compare_parasitics <test> <reference>     # compare two parasitic sets

# job submission, license queue and run directory layout are local choices
submit --cores 8 --mem <N>G -- StarXtract star_cmd
archive_manifest block=<blk> label=<label> netlist=<blk>.v corners=<list>

Successful completion is not proof of a correct extraction. The reports tell you what StarRC worked around without stopping, and you have to read them before the SPEF goes to STA.

A clean exit only tells you StarRC did not crash. StarRC does not need an LVS-clean layout for extraction to complete, open nets are bridged so timing tools can still calculate delays, fill is ignored unless you say otherwise, and coupling is grounded unless you say otherwise. Each of those produces a SPEF that looks perfectly normal.

AValidation checklist

BRun-health summary, walked through

I do not have a real StarRC summary to show, and the layout of the summary file changes between releases, so this is a dashboard of the things worth pulling out of a run, not a copy of the real report. Every number in it is illustrative and none of them is a threshold; whether 3 bridged opens is acceptable depends on which nets they are.

A good extraction does not guarantee a good annotation, and the check that matters is the one PrimeTime runs against its own netlist.

Extraction coverage and annotation coverage are two separate questions. The first is whether StarRC produced parasitics for every net it should have. The second is whether PrimeTime attached those parasitics to the nets and pins in the netlist it loaded. A perfect StarRC run can still give you a PrimeTime session with nets that have no RC at all.

AChecking annotation in PrimeTime

read_parasitics checks the nets it annotates and runs report_annotated_parasitics -check by itself. When you read several files, for example block SPEFs plus a top-level SPEF, read them all and then run the check once explicitly, because that report covers the whole design and not just the last file. The report lists pin types with Total, RC pi, RC network and Not Annotated columns.

set_app_var si_enable_analysis true
# after search_path and link_path point at the libraries for this corner
read_verilog <block>.v
current_design <top>
link_design
read_parasitics -syntax_only -keep_capacitive_coupling <block>.spef.rcworst_125
read_parasitics -keep_capacitive_coupling -format spef <block>.spef.rcworst_125
report_annotated_parasitics -check

read_parasitics A.spef -path [all_instances -hierarchy BLKA]
read_parasitics top.spef
report_annotated_parasitics -check

report_annotated_parasitics -list_not_annotated

This option appears in scripts you may inherit, but I could not confirm it for this page, so check it with man report_annotated_parasitics in your version before you put it in a script. The -syntax_only read is the supported way to check that coupling capacitors are symmetric before the real read. Also check the parasitics log, parasitics_command.log by default, and remember that repeated messages are limited by sh_message_limit, so the count you see on screen is not always the full count.

BWhy nets and pins go missing

CHow serious is a missing annotation

There is no blanket safe-to-ignore list. Here is how I would sort them, with the condition that has to be true before anything goes in the low column.

Extraction completes on broken layouts and bridges opens by default. Connectivity is proven by LVS and physical checks, never by inspecting a SPEF.

Opens and shorts are layout problems, and extraction sits downstream of layout. StarRC will still finish on a layout with opens or shorts; it just tells you about them. The risk is in what it does with an open by default.

AWhich check belongs in which tool

A SPEF cannot tell you the layout is free of opens and shorts, because a bridged open is written as a normal resistor and the SPEF has no concept of shapes touching that should not. The only question a SPEF answers is what RC the extractor built, and whether that is the RC of a correct chip is a question for LVS.

check_routes -open_net true -drc true
check_lvs -checks {short open floating_routes} -max_errors 0

ENHANCED_SHORT_REPORTING: YES
REPORT_METAL_FILL_STATISTICS: YES

BA practical debug sequence

1. Start from the StarRC reports. List every net in opens.sum and shorts_all.sum, and every via in vias.sum.
2. Run check_routes and check_lvs in ICC2 on the same saved block. If ICC2 sees the same open or short, it is a layout problem and you fix it in ICC2.
3. If ICC2 does not see it, look at what StarRC read and ICC2 did not check the same way: fill shapes, blockages, skip-cell pins, layers that are mapped differently. ENHANCED_SHORT_REPORTING widens what the shorts report includes.
4. For shorts to fill, check the fill source and the handling mode before touching routing.
5. Fix, save_block, re-extract. Do not edit the SPEF.
6. Re-run signoff LVS on the final layout. Extraction reports do not replace it.
7. Re-annotate in PrimeTime and confirm the affected nets now annotate fully and carry no 0.01 ohm resistors.

Once you can draw a SPEF as a schematic, most parasitic questions become arithmetic. The one convention to be careful with is where coupling capacitance is counted.

Here is a small SPEF I wrote by hand so every number can be traced. It has two nets. n_data is driven by u_drv/Z and fans out to two loads; sel comes in from a top-level input port and drives one load. The two nets run next to each other in one place, so there is one coupling capacitor between them. The header layout follows the form StarRC writes, and the values are illustrative.

*SPEF "IEEE 1481-1999"
*DESIGN "spef_demo"
*DATE "illustrative"
*VENDOR "pdverse example"
*PROGRAM "hand-written"
*VERSION "1.0"
*DESIGN_FLOW "PIN_CAP NONE" "NAME_SCOPE LOCAL"
*DIVIDER /
*DELIMITER :
*BUS_DELIMITER []
*T_UNIT 1 NS
*C_UNIT 1 FF
*R_UNIT 1 OHM
*L_UNIT 1 HENRY

*NAME_MAP
*1 n_data
*2 sel
*3 u_drv
*4 u_ld1
*5 u_ld2
*6 u_agl

*PORTS
*2 I

*D_NET *1 2.51
*CONN
*I *3:Z O *C 12.60 40.20
*I *4:A I *C 88.40 40.20
*I *5:A I *C 60.10 22.80
*CAP
1 *3:Z 0.21
2 *1:1 0.84
3 *1:2 0.66
4 *4:A 0.18
5 *5:A 0.27
6 *1:2 *2:1 0.35
*RES
1 *3:Z *1:1 12.4
2 *1:1 *1:2 18.6
3 *1:2 *4:A 9.3
4 *1:1 *5:A 21.7
*END

*D_NET *2 1.53
*CONN
*P *2 I *C 0.00 55.00
*I *6:A I *C 92.00 55.00
*CAP
1 *2 0.30
2 *2:1 0.72
3 *6:A 0.16
4 *2:1 *1:2 0.35
*RES
1 *2 *2:1 15.2
2 *2:1 *6:A 11.8
*END

ALine by line

BCapacitance accounting and the coupling convention

The total on *D_NET is the sum of every capacitor listed under that net, ground and coupling together. For n_data that is 0.21 + 0.84 + 0.66 + 0.18 + 0.27 = 2.16 fF of ground capacitance plus 0.35 fF of coupling, 2.51 fF. For sel it is 1.18 + 0.35 = 1.53 fF. This follows the IEEE 1481 convention used in SPEF files; the *DESIGN_FLOW line of your own file tells you what is and is not in the totals, so read it before comparing numbers across tools.

The coupling capacitor appears twice by design, once as line 6 of n_data and once as line 4 of sel, with the same two nodes and the same value. PrimeTime expects this symmetry and can check it with a -syntax_only -keep_capacitive_coupling read. Without SI enabled, PrimeTime splits coupling capacitors to ground on each net, which is the same total but no crosstalk.

Sorted by how much damage the problem does if nobody notices it, not by how often it happens.

If any line below is still open, the timing report is not signoff quality yet, however clean it looks.

Short answers with the follow-up that usually comes next, plus the common wrong answer to avoid.