- Category
- Developer Tools
- Rank
- No. 1475Tools index
Previous survey · No. 1442 ·
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Coding · Software Testing & Quality
- Interfaces
- CLI · Editor Extension · Desktop
- GitHub
- 19 stars
- Latest release
- v0.3.0
- Date
About
Booley is an open-source VS Code-based IDE that lets LLM coding agents (Claude or Codex) write and verify RTL hardware designs inside a sandboxed Docker environment with a pinned EDA toolchain. It provides typed 'Flows' for simulation, linting, synthesis, and FPGA implementation, plus waveform-querying tools so agents can debug from real simulation traces instead of guessing.
What it does
Booley puts a coding agent to work on chip designs written in Verilog or SystemVerilog but refuses to take the agent's word that anything works. Every toolchain run, from running tests to estimating chip area, goes through a fixed interface that returns a structured pass or fail verdict. In its unattended ticket mode, a separate harness marks a task done only when those verdicts meet criteria you wrote in advance. The agent works in a locked-down container with no host access and outbound traffic limited to the model provider. A companion trace tool lets it query recorded signal history, such as counting handshakes in a time window.
Why it's ranked here
Agent tooling for hardware design is thin, and most of it trusts the model's own report. Booley bets the other way: a ticket's acceptance criteria are satisfied only by evidence from a check the harness ran, and later code edits invalidate earlier passes so they must be re-run. That is a direct answer to agents declaring victory early. The discipline shows elsewhere too: exact version pins on its two build libraries, a measured container overhead study, and a written security model that names its own residual risks. Apache 2.0. Against it: one maintainer, no VHDL, no macOS, and commercial simulators still on the roadmap.
What's good
The security posture is specific: the agent runs non-root with dropped capabilities, memory and process limits, no Docker socket, no host home directory, and default-deny egress apart from the model API. Pushing to a remote Git server is blocked, so the worst case is a spoiled working copy on a branch. Results come back trimmed, capped near 12 KB plus parsed report fields, not raw logs. Long jobs hand back a run handle the agent can poll, with waits sized to stay inside the provider's prompt-cache window. The author measured container overhead on an Ibex core campaign and found medians within one percent of native.
Tradeoffs
Every project must describe its builds as FuseSoC targets (FuseSoC is an open-source hardware build manager) before anything runs, a one-time porting cost. Only Verilator, Icarus, Verible, Yosys, OpenROAD and Vivado are wired up; Synopsys VCS and Cadence Xcelium are listed as coming. No VHDL, no UVM verification methodology, no macOS. Synthesis numbers are estimates for tuning, not tape-out results. Inside the container the agent runs with every permission prompt switched off, which is safe only while the container boundary holds, and the docs name kernel escape as a residual risk. The author states the code was written by agents under their review and asks for outside review.
How to use it well
Best fit: a digital designer who already writes and reviews RTL (register-transfer level code) and wants an agent to grind through the loop of edit, simulate, debug and measure area. Start in the hands-on mode, as the project's own guide advises, until you know what evidence each check returns. Then move bounded, well-specified jobs, such as a refactor with named tests that must pass and an area budget, into tickets. Budget about 4 GB of Docker storage and real setup time. It will not design architecture for you, and teams on VHDL or commercial-only flows should wait.
Technical notes+
pyproject.toml ships three console scripts (booley maps to booley.harness.booley:main, booley-mcp to booley.mcp.server:main, bwave to booley.bwave.cli:main), pins edalize==0.6.8 and fusesoc==2.4.7 exactly because their tool-vs-flow API is mid-migration, and requires mcp>=2.1.1,<3 and claude-agent-sdk>=0.2.140. src/booley/mcp/server.py serves stdio for Ticket Mode and streamable HTTP on 127.0.0.1 for Interactive Mode, hides tb_coder and submit_run_report interactively via _INTERACTIVE_HIDDEN_REASONS, runs sim, fpga, synth, reviewer, mutation_tester and coverage_analyst as submit-then-poll jobs (_ASYNC_JOB_MCP_TOOLS, 240 s inline wait), and caps stdout at 12,000 bytes. docs/internals/WHY.md says schemas are extracted from each tool's argparse parser, except bwave, which is hand-authored.
Observed
- License
- Apache-2.0
- Language
- Python, requires Python 3.11 or newer
- Packaging
- Distributed on PyPI as booley-rtl; installed with pip, then prepared with booley bootstrap
- Interfaces
- CLI (booley, bwave) and an MCP server (booley-mcp) exposing Flows and Specialists as tools
- Platforms
- Windows and Linux supported; macOS not supported
- Requirements
- Docker, Git 2.37.2+, VS Code, and Claude or Codex credentials
- Source languages
- SystemVerilog and Verilog only; VHDL and UVM not supported
- Build dependencies
- FuseSoC and Edalize are pinned to exact versions
- Sandbox
- Runs non-root with dropped capabilities, no-new-privileges, memory and PID limits, and default-deny egress
- State storage
- All project state is plain files; no database or state daemon
- Output cap
- MCP tool results cap returned stdout at 12,000 bytes by default
Read from README.md, pyproject.toml, docs/internals/ARCHITECTURE.md, docs/internals/WHY.md, docs/user/FEATURES.md, docs/user/USAGE.md, docs/internals/MCP-TOOLS.md, src/booley/mcp/server.py.
What it can do
Run LLM coding agents (Claude or Codex) to write and verify RTL hardware designs
Natural language prompts / RTL design tasks → RTL hardware design code
Execute simulation, linting, synthesis, and FPGA implementation via typed 'Flows'
RTL source files → Simulation, lint, synthesis, or FPGA implementation results
Query waveform data from simulation traces for debugging
Simulation waveform trace → Waveform query results/debug information
Run EDA tools (Verilator, Yosys, Vivado) inside a sandboxed Docker environment
RTL design files → EDA tool outputs (simulation/synthesis results)
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.