[Request] Local congestion control for dense SoC designs (density islands / router knobs)
Context
We are doing the backend for a 90k-cell SoC design on ICS55 (two 8 KB SRAM
macros, ~7k async-reset sinks, 100 MHz target). ECC current main
(ecc 50c1d7a / ecc-tools 2c11c6c77 / ecc-dreamplace 308dcd35).
Observation: the hotspot moves, but never disappears
No matter where we place the SRAM macros, there is always a local congestion
hotspot somewhere. Measured across a controlled matrix (same netlist,
same recipe, util 0.65 / density 0.66 / pad 150 / halo 8 / MET2-MET5,
DRT1 = DR iteration-1 completed violations):
| macro placement |
GRT total overflow |
DRT1 violations |
| M0 diagonal (DTCM BL-FS, ITCM TR-N) |
54,049 |
529,705 |
| M1 bar (two vertical, center channel) |
56,976 |
571,083 |
| fixed die 747x748 (util ~0.47!) |
55,508 |
545,218 |
Key evidence:
- More global space does not help: the fixed-die run had ~36% more area
(util 0.47 vs 0.65) yet DRT1 was unchanged. The bottleneck is local, not
global capacity.
- The GRT overflow concentrates in small pockets: e.g. for M0 a ~40x50 um
strip above the ITCM macro (max ~114-122 overflow per 1.6 um bin) holding
the PSRAM back-end logic — deep AOI/OAI clouds (8-9 levels) + mux trees.
- PinAccess is 0 in every run; SRAM pin escape is ~14% of one layer's
capacity — the congestion is generated inside the logic pockets, not at
the macro pins.
- Sizer (Timing Opt) makes it 2.5x worse: the design already meets 100 MHz
with +2.2 ns margin pre-Sizer; timing-driven repair inserts ~7k buffers
and destroys routability. (Separate issue-worthy topic.)
- GRT overflow predicts DRT1 ordering almost perfectly (~9x amplification
is uniform) — the problem is present at global-routing time.
What we miss in the current toolchain
- Density islands / placement regions: there is no way to express
"limit density in region X" or "spread this hierarchy out" — the standard
remedy for exactly this class of local congestion. (The DreamPlace
routability passes only do global inflation.)
- Router-level congestion controls: GRT/DR parameters are hard-coded
(DR iterations, violation units, rip-up settings) with no config surface.
- EGR-driven inflation is weak or ineffective: routability_opt +
NCTUgr adjustment are on by default yet GRT overflow stays ~54k;
the pin-area and RUDY branches are being tested separately (results to be
appended).
Ask
Please provide ECC toolchain updates to improve local-hotspot handling for
dense pockets at this scale. Concretely:
- density-island / placement-region support (expressible in ecc.toml);
- config-exposed router congestion controls (GRT/DR iterations, rip-up,
violation units);
- stronger EGR-driven local inflation (pin-area / RUDY branches verified
working end-to-end).
We are happy to test any update on this design immediately and provide
controlled data (12+ run matrix, congestion maps, netlists on request).
Environment
ecc 50c1d7a, ecc-tools 2c11c6c77, ecc-dreamplace 308dcd35, ICS55 PDK
1.10.102, yosys 0.62. Netlists: DELAY-4 dual-VT and historical LMS
(reference). Full matrix data available.
[Request] Local congestion control for dense SoC designs (density islands / router knobs)
Context
We are doing the backend for a 90k-cell SoC design on ICS55 (two 8 KB SRAM
macros, ~7k async-reset sinks, 100 MHz target). ECC current main
(ecc 50c1d7a / ecc-tools 2c11c6c77 / ecc-dreamplace 308dcd35).
Observation: the hotspot moves, but never disappears
No matter where we place the SRAM macros, there is always a local congestion
hotspot somewhere. Measured across a controlled matrix (same netlist,
same recipe, util 0.65 / density 0.66 / pad 150 / halo 8 / MET2-MET5,
DRT1 = DR iteration-1 completed violations):
Key evidence:
(util 0.47 vs 0.65) yet DRT1 was unchanged. The bottleneck is local, not
global capacity.
strip above the ITCM macro (max ~114-122 overflow per 1.6 um bin) holding
the PSRAM back-end logic — deep AOI/OAI clouds (8-9 levels) + mux trees.
capacity — the congestion is generated inside the logic pockets, not at
the macro pins.
with +2.2 ns margin pre-Sizer; timing-driven repair inserts ~7k buffers
and destroys routability. (Separate issue-worthy topic.)
is uniform) — the problem is present at global-routing time.
What we miss in the current toolchain
"limit density in region X" or "spread this hierarchy out" — the standard
remedy for exactly this class of local congestion. (The DreamPlace
routability passes only do global inflation.)
(DR iterations, violation units, rip-up settings) with no config surface.
NCTUgr adjustment are on by default yet GRT overflow stays ~54k;
the pin-area and RUDY branches are being tested separately (results to be
appended).
Ask
Please provide ECC toolchain updates to improve local-hotspot handling for
dense pockets at this scale. Concretely:
violation units);
working end-to-end).
We are happy to test any update on this design immediately and provide
controlled data (12+ run matrix, congestion maps, netlists on request).
Environment
ecc 50c1d7a, ecc-tools 2c11c6c77, ecc-dreamplace 308dcd35, ICS55 PDK
1.10.102, yosys 0.62. Netlists: DELAY-4 dual-VT and historical LMS
(reference). Full matrix data available.