Repository navigation
Conversation
A generated macro's power pins are horizontal M4 rails; the platform's macro grid connects them to the core's vertical M5 straps, one per net every 5.4 um (grid_strategy-M1-M2-M5-M6.tcl). The backend sizes a macro from its bit cells alone, with a floor on height and none on width, so a small memory can come out narrower than the strap pitch, land between two straps of a net, and fail pdngen for the whole design. In asap7/tage_update, with the column mux of The-OpenROAD-Project#4659, the 64x16 SRAM is 4.18 um wide and floorplan stops with PDN-0179, "Unable to repair all channels". The process gets a min_width_um floor beside the existing height floor, and the asap7 backend sets it to one pitch plus one strap plus the rails' inset at both edges, 5.616 um: a strap of each net then crosses the rails wherever the macro is placed. Wider macros are unchanged. The 64x16 SRAM becomes 5.70 um wide and tage_update gets through PDN. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a minimum width constraint (min_width_um) for macros in the FakeRAM2.0 tool to prevent pdngen failures on narrow macros. This includes updating the ASAP7 configuration, enforcing the minimum width in get_macro_dimensions, and adding a unit test to verify the behavior. Feedback suggests handling cases where min_width_um might be explicitly set to None in the JSON configuration to avoid a potential TypeError during the max comparison.
Review: an explicit null would reach max() as None. Rather than read null as no floor, the process config is refused, as the file already refuses a pin pitch that is off the track grid: min_width_um must be a non-negative number. The comment on the asap7 floor names PDN-0179 as well as PDN-0233, the error asap7/tage_update met. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
🔍 QoR checkMetrics reflect the PR merge build — i.e. what will land on the target branch. Commit 62 design(s) checked — 0 with regression(s), 0 without a comparable baseline. |
|
@gadfort does pdn add repair straps for macros? |
|
@maliberty no it doesn't |
|
@gadfort You are reviewer, what should I do here? I'm out of my depth. |
|
I doubt a real memory would be this small. I have no objections to making sure the macros don't get too tiny. |
Thanks! Yes, too small memories is mostly about getting some signal in design space exploration so that the search can crawl out rather than getting no signal and fumbling in the dark without a gradient... |
4 participants
Draft: waits for #4659. Without its column mux, asap7/tage_update stops at macro placement before it gets to PDN, so this has nothing to show until #4659 is in. It does not depend on #4659's code and merges cleanly with it.
A generated macro's power pins are horizontal M4 rails; the platform's macro grid connects them to the core's vertical M5 straps, one per net every 5.4 um (
grid_strategy-M1-M2-M5-M6.tcl). The backend sizes a macro from its bit cells alone, with a floor on height and none on width, so a small memory can come out narrower than the strap pitch, land between two straps of a net, and fail pdngen for the whole design. In tage_update (#4595), with #4659, the 64x16 SRAM is 4.18 um wide and floorplan stops with PDN-0179, "Unable to repair all channels".The process gets a
min_width_umfloor beside the existing height floor, and the asap7 backend sets it to one pitch plus one strap plus the rails' inset at both edges, 5.616 um: a strap of each net then crosses the rails wherever the macro is placed. Wider macros are unchanged. The 64x16 SRAM becomes 5.70 um wide and tage_update gets through PDN.🤖 Generated with Claude Code