GridStack white paperGS-WP-03Rev. 1.0October 2026

GridStack vs. RedHawk-SC on real chip designs

AbstractBenchmark grids show that a solver is fast. A sign-off team needs to know whether it gives the same answer as the tool they already trust, on a real design. This paper runs GridStack 1.5 side by side with RedHawk-SC, run in-design from Synopsys Fusion Compiler, on two chips taken through place, route and sign-off in the SAED32 process: a RISC processor core with four SRAM macros, and a Groq-style LPU accelerator with eighteen SRAM macros and a 242K-node power grid. Both tools analyse the same grid, taps and per-cell power. Across static and dynamic analysis on both designs, GridStack's worst-case IR drop agrees with RedHawk-SC within 0.6–1.6%, and it completes the analysis 3.8–11× faster for dynamic IR drop and 23–27× faster for static IR drop.

3.8–27×faster than RedHawk-SC end to end: 3.8–11× dynamic, 23–27× static

≤ 1.6%difference in worst-case IR drop across all four analyses; 0.6–1.5% in three of them

242Kpower-grid nodes and 24,038 cells on the larger of two signed-off designs

1 / THE QUESTION

Does it agree with the sign-off tool, on a real chip?

Speed against a direct solver says nothing about agreement with the tool a sign-off flow is built on.

The IBM benchmarks in GS-WP-01 fix the grid and the stimulus and compare solvers. A production flow asks a harder question. Given a design that has been placed, routed and signed off, with real standard cells, SRAM macros, a power mesh designed for that floorplan and a vectorless activity model, does GridStack report the same IR drop at the same cells as RedHawk-SC?

To answer it, both tools were run on the same two designs, on the same server, from the same Fusion Compiler database. Every cell's result is compared one to one.

2 / THE DESIGNS

Two signed-off SAED32 chips

Both designs were implemented end to end in Synopsys Fusion Compiler: synthesis, floorplan and power mesh, placement, clock tree, routing and sign-off.

RISC_CORE is a compact processor core whose register files are SRAM macros. The LPU is a statically scheduled machine-learning accelerator in the style of Groq's tensor streaming processor: an 8 × 8 systolic matrix unit, a vector unit and an instruction sequencer, fed by sixteen SRAM data banks and two instruction-memory SRAMs.

Table 1 — Design specifications.
Specification	RISC_CORE	LPU accelerator
Process	SAED32, 1P9M	SAED32, 1P9M
Die size	323.5 × 322.6 µm	767.5 × 538.1 µm
Clock	200 MHz (5 ns)	400 MHz (2.5 ns)
SRAM macros	4	18
Powered standard cells	4,312	24,038
Analysis corner	ss, 0.95 V, 125 °C	ss, 0.95 V, 125 °C
Implementation	Fusion Compiler X-2025.06-SP3, through sign-off	Fusion Compiler X-2025.06-SP3, through sign-off

RISC_CORE routed layout with all nine metal layers; four SRAM macros outlined on the right and top, standard-cell logic in the lower left — Figure 1a · RISC_CORE layoutRouted layout, all nine metal layers, rendered from the sign-off GDS. Dashed outlines are the SRAM macros.

LPU routed layout with all nine metal layers; two rows of nine SRAM macros above and below a dense logic band — Figure 1b · LPU layoutRouted layout, all nine metal layers. Eighteen SRAMs in two rows; the logic fills the 212 µm band between them.

The power grids

Both grids follow the same plan: M1 rails along every standard-cell row, M2 straps over the logic, and a mesh of horizontal M7 and vertical M8 straps over the whole die, joined by stacked vias. Supply enters through ideal taps at the ends of the M8 straps. Table 2 gives the grid that both tools analysed.

RISC_CORE power grid: M8 vertical straps, M7 horizontal straps, M2 straps and M1 row rails, with SRAM outlines — Figure 2a · RISC_CORE power gridVDD and VSS wiring from the sign-off DEF: M1 row rails, M2 straps, M7/M8 mesh.

LPU power grid: M8 vertical straps and M7 horizontal straps across the die, M2 straps and M1 row rails in the logic band, with eighteen SRAM outlines — Figure 2b · LPU power gridThe same plan at 2.4× the die area; M5/M6 wires (not drawn) tie the SRAM power pins to the mesh.

Table 2 — Extracted power grids.
Grid	RISC_CORE	LPU accelerator
Power-grid layers	M1, M2, M7, M8 + via stacks	M1, M2, M6, M7, M8 + via stacks
Grid nodes (VDD + VSS)	27,747	242,378
Resistors	32,272	263,258
of which vias	8,793	43,516
Supply taps	16	96
M8 / M7 strap width	—	4.64 / 1.104 µm
Sheet resistance	0.1 Ω/□ (M1–M8)	0.1 Ω/□ (M1–M8)
Dynamic current sources	per cell	46,518
Transient	10 cycles, 5,000 steps of 10 ps	10 cycles, 2,500 steps of 10 ps

3 / METHOD

Same design, same inputs, cell-by-cell comparison

The comparison removes every difference except the analysis itself.

Sign-off database

Fusion Compiler opens the signed-off block. RedHawk-SC runs in-design, with vectorless activity, the SAED32 Cmax interconnect technology and the design's own liberty files.

Shared grid and stimulus

The DEF, LEF, tap locations, timing windows and parasitics that Fusion Compiler hands to RedHawk-SC are converted to a GridStack netlist, with resistances from the same technology file and per-cell power and current from the same analysis.

Cell-by-cell comparison

Both tools report the effective drop, VDD minus VSS, at every cell's power pins. Each cell is matched by name and compared, along with the worst cell and the top-50 list.

Static IR drop — each cell draws its average power divided by the supply voltage as a DC current between its VDD and VSS rails.
Dynamic IR drop, LPU — GridStack uses RedHawk-SC's own per-cell demand-current waveforms and cell decoupling capacitance, imported from the in-design run, plus the grid capacitance RedHawk-SC reports.
Dynamic IR drop, RISC_CORE — GridStack uses a vectorless switching model built from RedHawk-SC's per-cell power and Fusion Compiler's clock arrival times and switching windows, with a cell decoupling capacitance of 2 fF per cell.

All results use GridStack's sign-off mode: a full-order back-Euler transient over every grid node, with no model reduction. GridStack also provides a fast mode, the reduced-order Krylov engine of GS-WP-01, for rapid what-if evaluation during floorplanning and decap planning.

4 / ACCURACY

Worst-case drop within 1.6%, on every analysis

The two tools find the same worst-case IR drop, at the same cells.

Table 3 — Worst-case effective IR drop and per-cell agreement.
Design · analysis	Cells	RedHawk-SC worst	GridStack worst	Difference	Correlation	Top-50 shared
RISC_CORE · static	4,279	19.43 mV	19.55 mV	+0.6%	1.000	50 / 50
RISC_CORE · dynamic	4,279	160.19 mV	157.61 mV	−1.6%	0.948	40 / 50
LPU · static	24,038	7.589 mV	7.702 mV	+1.5%	0.9998	44 / 50
LPU · dynamic	24,038	35.79 mV	36.32 mV	+1.5%	0.988	41 / 50

Four scatter plots of GridStack against RedHawk-SC worst effective drop per cell, for RISC_CORE and LPU, static and dynamic; points lie along the diagonal — Figure 3 · Per-cell agreementWorst effective drop at every cell, GridStack against RedHawk-SC. The dashed line is perfect agreement.

In static analysis the two tools agree to within 0.6% on RISC_CORE and 1.5% on the LPU, with per-cell correlation of 1.000 and 0.9998. Both name the same worst cell on RISC_CORE, and their top-50 lists are identical. With RedHawk-SC's own current waveforms, the LPU's dynamic worst-case drop agrees to 1.5% and the per-cell correlation is 0.988. On RISC_CORE, whose dynamic stimulus is GridStack's own vectorless model, the worst-case drop agrees to 1.6% and 40 of the top 50 cells are shared; mid-range cells read higher because the two current models place switching events differently in time.

Where the drop is

GridStack maps the drop at every grid node, not only at the cells it reports. The maps below use the same views as GS-WP-02: VDD nodes show IR drop and VSS nodes show ground bounce, on one shared scale. Static maps show the DC solution. Dynamic maps show each node’s peak over the whole transient. Each rail is mapped on its own, so the worst node reads lower than the effective, VDD-minus-VSS, drop in Table 3. Dashed boxes are the SRAM macros and the black circle marks the worst node.

RISC_CORE static IR-drop map: the drop concentrates in the narrow logic channel between two register-file SRAMs on the right, peaking at 11.4 mV — Figure 4a · RISC_CORE static, 2DThe drop concentrates in the 31 µm logic channel between two SRAMs and rises toward its right end, peaking at 11.4 mV.

RISC_CORE dynamic peak IR-drop map: the same logic channel between two SRAMs is the hotspot, peaking at 97 mV, while the main logic block stays low — Figure 4b · RISC_CORE dynamic, 2DPeak drop over the transient. The same channel holds the hotspot, at 97 mV on a single rail.

3D view of RISC_CORE dynamic peak IR drop: a ridge of high drop rises along the logic channel between the SRAMs while the rest of the die stays flat — Figure 4c · RISC_CORE dynamic, 3DIn 3D the channel stands out as one ridge above an otherwise flat die.

LPU static IR-drop map: a broad bowl of drop across the logic band between the two SRAM rows, deepest right of centre, peaking at 4.3 mV — Figure 5a · LPU static, 2DA broad bowl across the logic band, deepest right of centre; the worst node, 4.3 mV, sits on the band’s lower edge.

LPU dynamic peak IR-drop map: a uniform 4 to 6 mV across the logic band, with the highest peaks on the rails along the band edges next to the SRAMs, up to 33 mV — Figure 5b · LPU dynamic, 2DThe logic band sits at a uniform 4–6 mV; the peaks, up to 33 mV, are on rail nodes along the band edges beside the SRAMs.

3D view of LPU dynamic peak IR drop: a flat plateau over the logic band with isolated narrow spikes along its edges — Figure 5c · LPU dynamic, 3D242K nodes in 3D: a flat plateau over the logic band, with isolated spikes along its edges.

5 / SPEED

3.8–11× faster dynamic, 23–27× faster static

Measured end to end on the same server, from launch to written results.

Bar chart of wall time: RISC_CORE static 198 s vs 8.6 s, dynamic 447 s vs 41.1 s; LPU static 566 s vs 20.8 s, dynamic 876 s vs 230 s — Figure 6 · Wall timeEnd-to-end wall time per analysis, RedHawk-SC against GridStack, with the speedup above each pair.

Table 4 — Runtime.
Design · analysis	RedHawk-SC wall	GridStack wall	Speedup	RedHawk-SC solve	GridStack solve
RISC_CORE · static	198 s	8.6 s	23.0×	0.48 s	0.17 s
RISC_CORE · dynamic	447 s	41.1 s	10.9×	213 s	24.1 s
LPU · static	566 s	20.8 s	27.2×	1.6 s	1.4 s
LPU · dynamic	876 s	230 s	3.8×	254 s	153 s

Host: 2 × Intel Xeon E5-2699 v4 (88 threads), 314 GB, Rocky Linux 8.10. RedHawk-SC ran in-design from Fusion Compiler with 8 local workers; its wall time includes its in-design data preparation, model build, solve and reports. GridStack's wall time covers start-up, netlist parsing, the solve and result writing; its full-order solve runs on a single core. The one-time conversion of the Fusion Compiler collateral into a GridStack netlist is not included.

6 / TAKEAWAYS

Sign-off agreement at a fraction of the turnaround

On two real, signed-off designs, GridStack reproduces RedHawk-SC's IR-drop answer and returns it several times sooner.

Same answer. Worst-case effective IR drop within 0.6–1.6% of RedHawk-SC in static and dynamic analysis on both designs, with per-cell correlation of 0.948–1.000 and the same hotspots at the top of the list.
Sooner. Dynamic analysis 3.8–11× faster and static analysis 23–27× faster end to end, short enough to run IR drop on every floorplan or power-mesh iteration rather than once at the end.
From the existing flow. GridStack reads the same Fusion Compiler collateral that RedHawk-SC uses: DEF, LEF, tap locations, timing windows, parasitics and per-cell power. No separate extraction or layout database is needed.
Two modes. Sign-off mode for the numbers that go into a review; fast mode (GS-WP-01) for quick what-if sweeps, with results that can be viewed at die level as in GS-WP-02.

From evidence to your design

Correlate GridStack on your own chip.

Bring a Fusion Compiler design and your RedHawk-SC setup. We will run both on the same database and compare them cell by cell.

Request a walkthrough