AgentStack
SKILL verified MIT Self-run

Backside Routing Realization Specialist

skill-mr-fang-vlsi-edagent-backside-routing-realization-specialist · by Mr-Fang-VLSI

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.

No reviews yet
0 installs
9 views
0.0% view→install

Install

$ agentstack add skill-mr-fang-vlsi-edagent-backside-routing-realization-specialist

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Backside Routing Realization Specialist? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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:

  1. targeted backside reroute reports nonzero selected nets but final DEF shows no BM2/BM1 occupancy,
  2. manual DEF patching is being used to test physical realizability,
  3. OpenROAD/OpenDB must be used to build a local rerouter or wire rewriter,
  4. the project needs a diagnostic bridge between theory-ranked nets and physically realized backside routing,
  5. 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

  1. Are target nets actually leaving the frontside and occupying BM2/BM1, or is the flow only reporting bookkeeping success?
  2. Is the current blocker in route realization, access construction, DEF/OpenDB encoding, or extraction compatibility?
  3. Can a local rerouter or wire-rewrite engine physically realize the intended BM2/BM1 -> M0 -> M1 path?
  4. Does an OpenROAD/OpenDB-backed patch path provide a more stable realization vehicle than raw DEF text patching?
  5. 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:

  1. inspect our local routing-related code structure,
  2. identify the minimum implementation layer that should change,
  3. patch the code directly,
  4. leave behind a reproducible route spec / patch manifest / script artifact,
  5. 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:

  1. *.results.tsv
  2. *.conclusion.md
  3. optional *.experience_delta.md
  4. when implementation is involved, a concrete tool/script artifact and a reproducible route spec or patch manifest

Hard rules

  1. Do not treat routed_signal_net_count > 0 as proof of backside realization unless final geometry or extracted connectivity shows real BM2/BM1 use.
  2. Keep M0-only separate from confirmed backside success.
  3. When manual patching is used, distinguish:
  • geometry preserved in DEF,
  • connectivity valid,
  • extraction valid,
  • electrical benefit measured.
  1. Prefer tool-backed route encoding (OpenDB/dbWireEncoder) over repeated raw DEF text surgery once DEF syntax itself becomes a blocker.
  2. 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

  1. Load references/background-knowledge-links.md for the current routing-realization knowledge contract and source anchors.
  2. Load references/update-mechanism.md when deciding whether routing-realization lessons should refresh KB gates, local rerouter assumptions, or the skill's references.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.