Skip to content
Timing Engine · CURRENT

iSTA · Static timing analysis

Static timing analysis engine supporting NLDM/Elmore/CCS delay models. Agents can run incremental dirty-cone analysis on demand, fetch typed timing reports, and identify critical paths—without drowning in irrelevant path detail.

Timing Engine CURRENT Tcl API Python SDK MCP
agent — iSTA
# Agent calls iSTA for timing
>>> client.call("iSTA.analyze",
...   design_ref="snap_7f3a",
...   scenarios=["func_typical", "func_worst"],
...   paths=100)
[iSTA] NLDM delay calc done   wns=0.032ns
[iSTA] path enumeration done  tns=-0.45ns
[iSTA] critical paths top     100 paths
→ coverage: 98.4% endpoints
iSTA timingNLDM delayElmore modelCCS currentWNS slackTNS totalSDC constraintSPEF parasiticsiSTA timingNLDM delayElmore modelCCS currentWNS slackTNS totalSDC constraintSPEF parasitics

Core capabilities

Multi-model delay calculation

iSTA supports three industry-standard delay models: NLDM (Non-Linear Delay Model) for fast estimation, Elmore for first-moment delay on RC trees, and CCS (Composite Current Source) for signoff-level accuracy. Agents pick models by flow stage—NLDM for early placement exploration, CCS for signoff verification. All intermediate results (cell delay, net delay, slew) export as structured vectors via AiEDA Library.

Incremental timing analysis (dirty cone)

This is iSTA's most valuable capability for Agent workflows. When upstream tools (e.g. iPL) move cells or iTO optimizes local paths, Agents need not rerun full-chip STA. With dirty_only=true, iSTA tracks dirty cells and nets in their fan-in/fan-out cones only, updating delay and slack in that region. Incremental runs typically take 5–15% of full-chip time, giving second-scale timing feedback.

Typed Timing Report

iSTA produces structured, typed timing reports—not text dumps. Agents set the number of critical paths via the paths parameter; results group by endpoint with per-stage detail (cell, delay, slew, slack). Reports include coverage (share of endpoints analyzed) and provenance (corner, parasitics files, constraints)—so Agents understand timing state without parsing logs.

Multi-scenario parallel analysis

A single iSTA.analyze call can analyze multiple PVT scenarios (Process, Voltage, Temperature), e.g. ["func_typical", "func_worst", "func_best"]. Results return grouped by scenario so Agents can compare WNS/TNS and worst paths across corners. Multi-scenario analysis runs in parallel threads inside the engine.

Agent calling patterns

iSTA exposes three equivalent calling protocols.

Python
MCP
Tcl

Python SDK

from ieda import Client

client = Client("http://localhost:9099")

# Full timing analysis across multiple scenarios
timing = client.call(
    "iSTA.analyze",
    design_ref="snap_7f3a",
    scenarios=["func_typical", "func_worst"],
    paths=100,
)

# Structured access
print(timing.wns)              # -0.032  (ns, negative = violation)
print(timing.tns)              # -0.45   (total negative slack)
for p in timing.critical_paths[:3]:
    print(p.slack, p.startpoint, p.endpoint)
print(timing.endpoint_slacks.keys())

# Incremental: only re-analyze dirty cones
incr = client.call(
    "iSTA.analyze",
    design_ref="snap_7f3a_v2",
    scenarios=["func_worst"],
    dirty_only=True,
    endpoints=timing.dirty_set,  # from upstream tool
)
print(incr.coverage)  # CoverageReport: what was analyzed

Input / output contract

Request Schema — iSTA.analyze

ParameterTypeRequiredDefaultDescription
design_refstringYesDesign snapshot reference with netlist, parasitics, and constraints
scenariosstring[]YesList of PVT scenarios, e.g. ["func_typical", "func_worst"]
pathsintNo100Number of worst critical paths to return
endpointsstring[]No[] (all)Endpoint list to scope analysis to specific paths
dirty_onlyboolNotrueRun incremental analysis on dirty cone only

Result Schema

FieldTypeDescription
wnsfloatWorst negative slack; positive means no violation
tnsfloatTotal negative slack (TNS)
critical_pathsPath[]Critical path list with startpoint, endpoint, slack, and stage detail
endpoint_slacksmap[string]floatSlack map for all analyzed endpoints
coverageCoverageReportCoverage report: analyzed vs. total endpoints and skip reasons
provenanceProvenanceInfoProvenance: corner, parasitics file version, constraint files

Role in the flow

iSTA is flow-wide infrastructure—not only at timing signoff.

  RTL
   ↓
 iMap (Synth)      ←→ iSTA (post-synth timing check)
   ↓
 iFP (Floorplan)         ←→ iSTA (early timing estimate)
   ↓
 iPDN (Power grid)  ←→ iSTA (IR-drop-aware timing)
   ↓
 iPL (Place)       ←→ iSTA (post-place annotation → incremental)
   ↓
 iCTS (Clock tree) ←→ iSTA (clock delay + skew)
   ↓
 iTO (Timing opt)  ←→ iSTA (incremental verify after each opt step)
   ↓
 iRT (Route)       ←→ iSTA (post-route signoff with parasitics)
   ↓
 iECO (ECO)        ←→ iSTA (local incremental verify)
   ↓
 Signoff         ←→ iSTA (multi-corner full-chip signoff)
End-to-endiSTA is the only infrastructure active from RTL through signoff. Each physical step (iPL, iCTS, iRT) triggers incremental timing analysis.
Upstream dependenciesiRCX (parasitic extraction), Liberty (.lib) libraries, SDC constraints
Downstream consumersiTO consumes iSTA critical-path reports for buffer sizing, gate sizing, VT swap, and other optimizations

Timing data ready for learning

Every iSTA timing report exports as structured tensors via AiEDA Library for AiSTA model training and inference.