bare-metal-bringup
Use when bringing up bare-metal or kernel code on a new architecture, SoC, or board (RISC-V, ARM, x86, ESP32) and it won't boot, hangs after boot, or faults…
Use when preparing a design for tapeout or an MPW shuttle submission (wafer.space style), running DRC/LVS signoff, packaging the GDS, or deciding whether a physical-verification failure is safe to wave; covers metal-layer and std-cell rules
$ npx -y skills add Midstall/claude-for-hardware --skill tapeout-precheck --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/tapeout-precheckContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when preparing a design for tapeout or an MPW shuttle submission (wafer.space style), running DRC/LVS signoff, packaging the GDS, or deciding whether a physical-verification failure is safe to wave; covers metal-layer and std-cell rules
name: tapeout-precheck description: Use when preparing a design for tapeout or an MPW shuttle submission (wafer.space style), running DRC/LVS signoff, packaging the GDS, or deciding whether a physical-verification failure is safe to wave; covers metal-layer and std-cell rules
Tapeout is irreversible and expensive. The precheck is the last gate where a tool, not a person, confirms the layout obeys the foundry rules and matches the schematic. The job is to pass that gate honestly, because the alternative is paying for a respin to learn what the checker already knew.
**Core principle:** A physical-verification failure is the design telling you it's wrong. Fix the design, never the checker. Every disabled rule is a defect you chose to ship.
1. **DRC clean.** Geometry obeys the foundry rules (spacing, width, density, antenna, latchup). Zero unwaived violations. 2. **LVS clean.** The extracted layout netlist matches the schematic/source netlist exactly: same devices, same connectivity, no shorts, no opens, no unintended merges. 3. **Density / fill.** Metal density windows satisfied, fill added without creating new violations. 4. **Submission package.** Correct top-cell name, layer mapping, and the foundry's required metadata and file format. A perfect GDS rejected for a wrong top-cell name is a wasted shuttle slot.
A precheck step may be a no-op for a given flow (some shuttles run DRC on their side), but treat it as a real gate: know which checks run where, and don't assume "no errors printed" means "checked."
This is the rule that quietly destroys a chip:
Do not flatten standard cells and then merge their metal layers across cell boundaries. The std cells were verified as discrete cells with defined pins. Flatten-and-merge can short nets that the cell library kept apart and break the device-to-net correspondence LVS relies on. The result is an LVS mismatch at best, a silently shorted net at worst. Keep cells as instances; route between their pins. Let the router own inter-cell metal, not a flattening pass.
There is no `ERROR_ON_DRC=false`, no "skip antenna for now," no waiver-without-foundry-signoff. Those knobs convert a real, known defect into a green checkmark, which is the most dangerous output a tapeout flow can produce.
A design can fail place-and-route because it is routing-limited, not area-limited. A mux-heavy datapath (wide operand and result muxes, a multi-read register file) can leave the die only a third routing-utilized yet locally congested, so it never converges. Read the failure before you reach for the wrong knob.
| Smell | Do instead | |-------|------------| | Disabling a DRC rule to pass | Fix the geometry | | Tuning density on a fixed die that won't route | Read it as congestion; cut mux fan-in in RTL | | Adding cell padding to fix congestion | Padding hardens congestion; it does not relieve it | | Flatten + merge metal across std cells | Keep cells as instances, route between pins | | "LVS is close enough" | LVS must match exactly | | Assuming a no-op precheck checked something | Know which checks run where | | Self-granted waiver to hit a deadline | Only foundry-granted, written waivers | | Wrong top-cell/layer map in the package | Validate the submission package against foundry spec |
Claude Code skills for hardware design, validation, and bring-up. A plugin of focused skills that teach Claude how to do real hardware work: designing reusable HDL, integrating an SoC, bringing up FPGAs and bare-metal targets, building firmware boot chains,
Repo: Midstall/claude-for-hardware
Use when bringing up bare-metal or kernel code on a new architecture, SoC, or board (RISC-V, ARM, x86, ESP32) and it won't boot, hangs after boot, or faults…
Use when building or debugging a compiler backend, codegen, or assembler and you need to prove the generated machine code is correct by executing it on a real…
Use when verifying a hardware DUT (a CPU core, FPGA, or netlist) against a golden reference model, building coverage-guided fuzzing, or detecting where silicon…
Use when building or debugging a firmware and boot chain (RISC-V SBI, UEFI, ACPI, a bootloader handoff like Limine to an OS) or adding measured boot with a…
Use when loading a bitstream onto a physical FPGA and driving or observing it over JTAG or GPIO, especially bit-banged JTAG from a host like a Raspberry Pi, or…
Use when synthesizing RTL to an FPGA with yosys/nextpnr (ECP5/Lattice and similar), fighting area or routing congestion, measuring Fmax, deciding why a design…