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,…
Use when composing an SoC from peripherals and a bus fabric, or when generating device trees, ACPI tables, docs, or pin lists from a hardware description and they keep drifting out of sync
Claude Code
$ npx -y skills add lilithsemi/claude-for-hardware --skill soc-integration --agent claude-code
Codex
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a codex -y
Cursor
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a cursor -y
Gemini CLI
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a gemini-cli -y
GitHub Copilot
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a github-copilot -y
OpenCode
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a opencode -y
Windsurf
$ npx skills add lilithsemi/claude-for-hardware --skill soc-integration -a windsurf -y
name: soc-integration description: Use when composing an SoC from peripherals and a bus fabric, or when generating device trees, ACPI tables, docs, or pin lists from a hardware description and they keep drifting out of sync
An SoC is a CPU, a bus fabric, and a set of peripherals connected by an address map. The integration job is to make that map the single source of truth and derive everything else (RTL wiring, device trees, ACPI, docs, firmware headers) from it.
**Core principle:** Describe the SoC once in a neutral structure. Every output is a consumer of that structure, never a producer of its own truth. The day a device tree and the RTL disagree about a base address is the day you debug ghosts.
Skip for a single fixed-function block with no bus and no software-visible map.
Model each peripheral as a first-class hardware module that exposes its bus interface, its register block, and its metadata (compatible string, interrupt number, address size). Because it is a real module, you can elaborate it, test it, and read its metadata to generate a device tree node.
Avoid a "plugin" that is just a config blob with no hardware behind it. If the device tree generator and the RTL both have to know a peripheral exists, they should learn it from the same module, not from two parallel lists that rot independently.
Do not couple the generators to each other or to one CPU implementation. Define a neutral type that captures what every consumer needs (cores, memory regions, peripherals, interrupts, the address map) and have each generator read from it.
SoC description (neutral)
/ | \
RTL DeviceTree ACPI / docs / headers
wiring generator generatorsThe thing that hosts peripherals and builds the fabric must be per-instance, not a global registry. Two SoCs (or two test cases) being elaborated at once must not stomp each other. Per-instance state is also what lets you build many configurations in parallel.
| Smell | Do instead | |-------|------------| | DTS list and RTL list of peripherals maintained separately | Derive both from the peripheral modules | | Generator imports another generator | Both read the neutral description | | Global peripheral registry | Per-instance host | | Base addresses assigned ad hoc | One validated address-map allocator | | Generator hardcodes one CPU type | Generators take a neutral SoC type |
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,
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,…
Use when building or debugging a compiler backend, codegen, or assembler and you need to prove the generated machine code is…
Use when verifying a hardware DUT (a CPU core, FPGA, or netlist) against a golden reference model, building coverage-guided…
Use when building or debugging a firmware and boot chain (RISC-V SBI, UEFI, ACPI, a bootloader handoff like Limine to an OS) or…
Use when loading a bitstream onto a physical FPGA and driving or observing it over JTAG or GPIO, especially bit-banged JTAG from…
Use when synthesizing RTL to an FPGA with yosys/nextpnr (ECP5/Lattice and similar), fighting area or routing congestion,…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.