eda-install

eda-install Skill

Provision the open-source EDA toolchain, then get out of the way. This is the setup companion to the two working skills: signoff-loop (RTL→GDS + signoff) and def-graph (graph datasets). It answers one question — "are the tools this machine needs present, and if not, how do I get them without breaking anything?" — and acts on the answer.

The one command

bash r2g-skills/eda-install/bootstrap.sh --dry-run     # detect + plan, install NOTHING
bash r2g-skills/eda-install/bootstrap.sh               # install missing tiers + pin env.local.sh + verify

bash r2g-skills/bootstrap.sh is a shim to the same script.

What it does — detect → plan → install → pin → verify

1. Detect (scripts/setup/detect_env.sh) — a clean KEY=VALUE snapshot of the machine: OS + package manager, HAVE_SUDO, HAVE_CONDA, a big writable volume (≥15 GB, preferring /proj), plus every tool + PDK the shared scripts/flow/_env.sh resolver already discovers, and a torch-capable python. Absence is data, never an error.
2. Plan — bootstrap.sh prints a per-tier table (core / frontend / sky130 / klayout / pdk / graph), each OK / MISS (required, absent) / OPT (optional, installable), with the exact action it would take. The install channel is chosen by HAVE_SUDO (see below).
3. Install — each tier is scripts/setup/install_<tier>.sh; bootstrap.sh dispatches to one the moment it exists (and until then prints the command it would run). The platform_rules tier is in the default plan (2026-07-20, round-2 pilot P0-3 — a stock nangate45 checkout has no LVS deck and an unusable 0-area antenna diode, so strict signoff is impossible while every tool reads green): the plan probes platform_capability.py --platform nangate45 --strict and shows OK/OPT; being ORFS-mutating it still installs only when named (--tiers platform_rules), materializing the repo's bundled nangate45 DRC/LVS/antenna rule decks into the ORFS checkout (install_platform_rules.sh, best-effort, HINTs when the repo tools/ installers are unreachable). check_env.sh prints the same per-platform capability table; R2G_STRICT_PLATFORMS="nangate45" makes readiness REQUIRED there.
4. Pin (scripts/setup/write_env_local.sh) — writes references/env.local.sh into both signoff-loop and def-graph from the resolved paths, so the flow skills find a conda / /proj toolchain with no manual edit. It pins only what autodetect would miss (e.g. omits openroad/yosys already under $ORFS_ROOT/tools/install) and adds R2G_GRAPH_PYTHON.
5. Verify — runs scripts/flow/check_env.sh (ORFS + required + optional + graph stage + platforms) and reports the same table the README documents.

The channel is chosen for you: no-sudo is the default

Detection runs sudo -n true. Without root (HAVE_SUDO=0 — the common case on shared servers) every tier routes through pre-built conda litex-hub packages + a venv, all under the big volume:

Tool(s)	No-sudo channel
openroad, yosys, iverilog, verilator, klayout, magic, netgen, opensta	conda litex-hub (all --override-channels -c litex-hub -c conda-forge — the ToS-gate workaround)
ORFS flow + platforms	git clone --recursive — no build; env.local.sh points OPENROAD_EXE/YOSYS_EXE at the conda binaries
sky130A PDK	conda open_pdks.sky130a → the big volume (never volare — proxy/rate-limit caveat)
torch / torch_geometric / pandas	python3 -m venv + pip (CPU wheels)

"No sudo" means download pre-built binaries into a user-writable prefix — not compile in userspace. With root, core/frontend may instead build ORFS from source (--yes-gated, ~30 min); every other tier is already root-free. What cannot be self-healed (conda/network blocked, no ≥15 GB volume, a GLIBC too old for the conda binaries) escalates with a clear HINT — never a silent failure.

Flags

Flag	Effect
--dry-run	Detect + plan only; install nothing. Always run this first.
--yes / -y	Non-interactive; accept the plan (incl. --yes-gated heavy tiers).
--prefix DIR	Big-volume root for the conda install, PDK, and torch venv.
--tiers a,b,c	Act only on a subset (core,frontend,sky130,klayout,pdk,graph).
--graph-python P	Pin an existing torch venv (R2G_GRAPH_PYTHON) instead of building one.
--plan-from FILE	Plan against a saved detect dump (review / tests) — implies --dry-run.
--deploy [--link]	After provisioning, run install.sh to deploy the skills (--link recommended).

Invariants (honesty layer)

• scripts/flow/_env.sh is byte-identical across all three skills (md5 a5ac873e…) — the same resolver the flow scripts use; edit every copy together.
• Detection is read-only and total — it emits every key (empty == absent) and never exits non-zero for a missing tool.
• The pin file is idempotent — regenerating env.local.sh writes only what autodetect misses, so it never fights _env.sh.
• --dry-run and --plan-from install nothing — the plan is always previewable before any action.

References

• references/setup.md — tiers, the no-sudo path in depth, and troubleshooting.
• docs/superpowers/plans/r2g-skills-bootstrap-2026-07-08.md — full design + rationale.