fix: behavioral_macros emits VDD/VSS pins so PDN can stitch the macro#711
Merged
Conversation
Behavioral memory macros previously omitted PG (VDD/VSS) pins from the
generated .lef. When the parent design's floorplan ran PDN, every
instance triggered
[WARNING PDN-0231] <inst> is not connected to any power/ground nets.
and the macros stayed off the parent power grid. Downstream the parent's
SAIF-driven `report_power` then accounted zero macro power, and the
calling project's power-report flow effectively saw the memories as
free. The first project to wire behavioral_macros into a real
power-simulation pipeline (Pinata-Consulting/ascenium#22358) hit this.
Add VDD/VSS to the stub LEF in `generate_lef()` and teach
`rewrite_lef()` to emit them as full-width horizontal M4 stripes — the
same shape `fakeram_*.lef` from the asap7 platform uses, which is the
minimum geometry PDN can find via overlap with parent stripes. Carve
the stripe rows out of the M4 OBS rectangle so the blockage doesn't
hide the PG pin geometry from the macro-pin search.
Adds `test_generate_lef_has_pg_pins` covering: PIN VDD/VSS exist with
USE POWER / USE GROUND; both stripes span the full macro width on M4.
The existing 57 tests stay green.
The .lib doesn't need pg_pin declarations to match — the asap7
platform's own fakeram_*.lib ships without them and OpenSTA reads them
fine, so the gap was strictly LEF-side.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Behavioral memory macros (
@bazel-orfs//tools/memory_macro_scaler:behavioral_macros) were dropping VDD/VSS pins from their generated.lef. The first downstream project to wirebehavioral_macrosinto a real SAIF-driven power-simulation flow (Pinata-Consulting/ascenium#22358) hit the gap immediately:Every behavioral memory stayed off the parent power grid; the parent's
report_powerthen accounted zero macro power. The.libwas already power-aware (per-pininternal_power, cell-leveldefault_cell_leakage_power) — the gap was strictly LEF-side, matching the precedent thatfakeram_*.libshipped with the asap7 platform also has nopg_pindeclarations.Fix
generate_lef()now appendsPIN VDD/PIN VSS(withUSE POWER/USE GROUND) to the stub LEF, andrewrite_lef()lays them down as full-width horizontal M4 stripes — the same shapefakeram_*.lefuses. The OBS rectangle is split into segments around the PG stripe rows so the blockage doesn't hide the pin geometry from PDN's macro-pin search.Test plan
python3 -m unittest memory_macro_scaler_test— all 57 existing tests pass; newtest_generate_lef_has_pg_pinscovers PIN VDD/VSS presence with the right USE classification and full-width M4 stripe geometry//hardware/tile:report_powerand//hardware/aptos-run:cts-8-Saif-run) currently in flight; the ascenium-side PR vendors this same change as agit_overridepatch and will drop it after this lands