Backside Routing Realization Specialist
Use this skill when the key question is not "is backside theoretically useful?" but "why is backside routing not being physically/electrically realized, and how do we build, fix, and evolve our own controlled rerouter to test it?"
When to use
Use this skill when:
- targeted backside reroute reports nonzero selected nets but final DEF shows no
BM2/BM1 occupancy,
- manual DEF patching is being used to test physical realizability,
- OpenROAD/OpenDB must be used to build a local rerouter or wire rewriter,
- the project needs a diagnostic bridge between theory-ranked nets and physically realized backside routing,
selection bookkeeping must be separated from real route realization.
Scope boundary
This skill owns:
- routing-realization diagnosis for backside signal paths,
- local reroute/patch implementation strategy,
- OpenROAD/OpenDB-backed net wire rewriting and rerouter bring-up,
- understanding the structure of our own routing-related code and patch/replay stack,
- directly modifying and repairing our own rerouter, patch generator, DEF bridge, and related debug tools,
- deciding whether current blockers are in route realization, wire encoding, extraction friendliness, or access path construction.
It does not own:
- workflow ownership or batch orchestration; use it as an expert skill under the active workflow owner,
- the BSPDN physical contract itself without
bspdn-physical-contract-auditor,
- PDN sufficiency judgments without
bspdn-pdn-sufficiency-evaluator,
- final backside benefit attribution without
backside-benefit-attribution-evaluator,
- full batch orchestration.
Core questions
- Are target nets actually leaving the frontside and occupying
BM2/BM1, or is the flow only reporting bookkeeping success?
- Is the current blocker in route realization, access construction, DEF/OpenDB encoding, or extraction compatibility?
- Can a local rerouter or wire-rewrite engine physically realize the intended
BM2/BM1 -> M0 -> M1 path?
- Does an OpenROAD/OpenDB-backed patch path provide a more stable realization vehicle than raw DEF text patching?
- Which part of our own code stack should change: selector, route-spec generation, wire encoder, DEF sanitization, replay contract, or extraction path?
Code ownership expectation
This is not a read-only analysis skill.
When the request requires it, this skill should:
- inspect our local routing-related code structure,
- identify the minimum implementation layer that should change,
- patch the code directly,
- leave behind a reproducible route spec / patch manifest / script artifact,
- explain whether the fix belongs in:
openroad_backside_rerouter.py
sanitize_def_for_openroad.py
manual_backside_patch_oracle.py
- related replay / extraction helpers
The default expectation is "can read, can repair, can extend", not just "can diagnose."
Expected outputs
Emit the smallest useful routing-realization package:
*.results.tsv
*.conclusion.md
- optional
*.experience_delta.md
- when implementation is involved, a concrete tool/script artifact and a reproducible route spec or patch manifest
Hard rules
- Do not treat
routed_signal_net_count > 0 as proof of backside realization unless final geometry or extracted connectivity shows real BM2/BM1 use.
- Keep
M0-only separate from confirmed backside success.
- When manual patching is used, distinguish:
- geometry preserved in DEF,
- connectivity valid,
- extraction valid,
- electrical benefit measured.
- Prefer tool-backed route encoding (
OpenDB/dbWireEncoder) over repeated raw DEF text surgery once DEF syntax itself becomes a blocker.
- When modifying our own rerouter stack, prefer the smallest stable implementation layer and avoid copying full industrial router logic unless the lighter
wire-rewrite / local-spec / incremental realization path has already been falsified.
Operational references
- Load
references/background-knowledge-links.md for the current routing-realization knowledge contract and source anchors.
- Load
references/update-mechanism.md when deciding whether routing-realization lessons should refresh KB gates, local rerouter assumptions, or the skill's references.
1---2name: backside-routing-realization-specialist3description: Diagnose and implement backside-routing realization paths, including targeted reroute, local DEF/OpenDB patching, and OpenROAD-backed net-level rerouter bring-up, when theory predicts benefit but the current flow does not realize BM2/BM1 usage.4---56# Backside Routing Realization Specialist78Use this skill when the key question is not "is backside theoretically useful?" but "why is backside routing not being physically/electrically realized, and how do we build, fix, and evolve our own controlled rerouter to test it?"910## When to use1112Use this skill when:131. targeted backside reroute reports nonzero selected nets but final DEF shows no `BM2/BM1` occupancy,142. manual DEF patching is being used to test physical realizability,153. OpenROAD/OpenDB must be used to build a local rerouter or wire rewriter,164. the project needs a diagnostic bridge between theory-ranked nets and physically realized backside routing,175. `selection bookkeeping` must be separated from real route realization.1819## Scope boundary2021This skill owns:22- routing-realization diagnosis for backside signal paths,23- local reroute/patch implementation strategy,24- OpenROAD/OpenDB-backed net wire rewriting and rerouter bring-up,25- understanding the structure of our own routing-related code and patch/replay stack,26- directly modifying and repairing our own rerouter, patch generator, DEF bridge, and related debug tools,27- deciding whether current blockers are in route realization, wire encoding, extraction friendliness, or access path construction.2829It does not own:30- workflow ownership or batch orchestration; use it as an expert skill under the active workflow owner,31- the BSPDN physical contract itself without `bspdn-physical-contract-auditor`,32- PDN sufficiency judgments without `bspdn-pdn-sufficiency-evaluator`,33- final backside benefit attribution without `backside-benefit-attribution-evaluator`,34- full batch orchestration.3536## Core questions37381. Are target nets actually leaving the frontside and occupying `BM2/BM1`, or is the flow only reporting bookkeeping success?392. Is the current blocker in route realization, access construction, DEF/OpenDB encoding, or extraction compatibility?403. Can a local rerouter or wire-rewrite engine physically realize the intended `BM2/BM1 -> M0 -> M1` path?414. Does an OpenROAD/OpenDB-backed patch path provide a more stable realization vehicle than raw DEF text patching?425. Which part of our own code stack should change: selector, route-spec generation, wire encoder, DEF sanitization, replay contract, or extraction path?4344## Code ownership expectation4546This is not a read-only analysis skill.4748When the request requires it, this skill should:491. inspect our local routing-related code structure,502. identify the minimum implementation layer that should change,513. patch the code directly,524. leave behind a reproducible route spec / patch manifest / script artifact,535. explain whether the fix belongs in:54 - `openroad_backside_rerouter.py`55 - `sanitize_def_for_openroad.py`56 - `manual_backside_patch_oracle.py`57 - related replay / extraction helpers5859The default expectation is "can read, can repair, can extend", not just "can diagnose."6061## Expected outputs6263Emit the smallest useful routing-realization package:641. `*.results.tsv`652. `*.conclusion.md`663. optional `*.experience_delta.md`674. when implementation is involved, a concrete tool/script artifact and a reproducible route spec or patch manifest6869## Hard rules70711. Do not treat `routed_signal_net_count > 0` as proof of backside realization unless final geometry or extracted connectivity shows real `BM2/BM1` use.722. Keep `M0-only` separate from confirmed backside success.733. When manual patching is used, distinguish:74 - geometry preserved in DEF,75 - connectivity valid,76 - extraction valid,77 - electrical benefit measured.784. Prefer tool-backed route encoding (`OpenDB/dbWireEncoder`) over repeated raw DEF text surgery once DEF syntax itself becomes a blocker.795. When modifying our own rerouter stack, prefer the smallest stable implementation layer and avoid copying full industrial router logic unless the lighter `wire-rewrite / local-spec / incremental realization` path has already been falsified.8081## Operational references82831. Load `references/background-knowledge-links.md` for the current routing-realization knowledge contract and source anchors.842. Load `references/update-mechanism.md` when deciding whether routing-realization lessons should refresh KB gates, local rerouter assumptions, or the skill's references.