Supported EDA tools¶

Read this first¶

This doc assumes a few Booley terms: Booley Flow (Booley's deterministic end-to-end orchestration), Target (a named FuseSoC .core build target), and EDA provisioning (where an approved tool installation comes from). If any are new, consult the glossary in GLOSSARY.md; the README and SETUP.md give the wider picture. Everything below is the detail layer on top of that vocabulary.

The single source of truth for which EDA tools Booley drives, with which provisioning source, trace support, and requirements. When README, SETUP, or ROADMAP need to state "what's supported," they link here rather than keeping their own drifting lists.

Source language: SystemVerilog/Verilog only. VHDL is not supported in any flow — there is no GHDL/NVC Booley Flow, no VHDL lint or synthesis path, and a mixed repo's VHDL files simply have no Booley Target to point at. If your design is VHDL-first, Booley has nothing to offer it today; a repo that ships both an SV and a VHDL implementation (a common pattern) onboards fine — you wire the SV half and leave the VHDL half alone.

Two axes govern every flow:

• EDA tool: the concrete external program a Flow executes. The Target's flow_options.tool (or default_tool) normally selects it and always participates in FuseSoC resolution. FPGA implementation is the fixed-backend exception: its Target-name axis declares intent, and Booley always executes Vivado after rebuilding the resolved inputs into a Vivado EDAM.
• Provisioning decides where the installation files originate, never where the command runs. image means the Sandbox Image supplies the tool. host means a built-in policy mounts one administrator-registered installation read-only into the Sandbox under an exact Project Grant. Every EDA process still executes inside that Sandbox; Project configuration cannot select a host command, path, arbitrary mount, license destination, or execution location.

For every host-provisioned EDA tool, the built-in policy owns one canonical container path. The administrator may register different host installation paths, but every approved installation of a given tool is mounted at that same read-only destination inside the Sandbox. Neither the Project nor the Installation Registration can configure the destination. This gives wrappers, Flows, Doctor checks, and future image changes one stable tool layout instead of making container paths part of Project configuration.

Built-in flows¶

Vivado host-provisioning policy¶

Vivado 2025.2 on Linux x86-64 is the first supported host-provisioned EDA policy. An administrator registers its release root, and Booley mounts that root read-only at the fixed target /opt/booley-eda/vivado inside the Sandbox. The wrapper, compatibility libraries, locale, image identity, mount, and environment are host-issued policy rather than Project settings. Vivado itself executes inside the Sandbox.

The FPGA Flow's portable compact, balanced, and max_frequency profiles were characterized on this exact lane. They map to supported Vivado run strategies; balanced preserves the vendor defaults without patching generated Tcl. The reproducible compatibility results are preserved in the checked-in Vivado characterization fixture. These names express optimization intent, not guaranteed QoR, and FPGA power is not currently a normalized metric.

The Project requests host provisioning under [eda.vivado]; the administrator selects the exact Installation Registration in the Grant for one canonical Project Root with booley eda. booley projects lists each remembered root and its Grants, including roots that have since been deleted. Host-provisioned Vivado is unavailable on Windows, macOS, and non-x86-64 Linux. Windows remains supported for Booley and EDA tools already provisioned in its Linux Docker image; a native Windows EDA installation cannot be mounted into a Linux container and executed there.

The optional fixed-destination FlexNet relay is experimental. Its synthetic forwarding, isolation, failure, and cleanup tests pass, but an administrator-approved paid-seat checkout, accounting, concurrency, and return matrix was not available. Do not treat floating-license behavior or its SLA as validated until that site evidence exists.

The base sandbox image pins cocotb 2.x, but the cocotb run-half — the run stage of the simulate flow that Booley drives after FuseSoC builds the sim — also speaks the cocotb 1.x selection dialect (TESTCASE instead of COCOTB_TEST_FILTER, auto-detected via cocotb-config --version). So a project that pins a 1.x stack still routes sim through the built-in flow.

Dialect compatibility does not guarantee that every historical cocotb release works with the image's current simulator. If simulation stalls at time zero, see TROUBLESHOOTING.md.

A test that needs a non-RTL build step before it can run (a per-case firmware compile, vector staging) declares it as [flows.sim].pre_run_commands (FLOW-SIM.md) — the project's own Makefile runs inside the Sandbox, and Booley keeps the same Flow contract above it. A simulator outside this matrix is out of scope for Goal Mode; widening the matrix is the sanctioned extension axis.

synth is a PPA estimate, not tape-out. It's a fast power/performance/area estimate to optimize RTL against, whatever engine backs it (today Yosys + OpenROAD, deliberately pre-layout, ideal-clock, setup-only; Genus / Design Compiler may follow). Real tape-out sign-off (physical impl, CTS, routing, DRC/LVS, multi-corner STA on a foundry PDK) is out of scope for Booley.

synth RTL frontend (sv2v vs slang)¶

Yosys reads the design through one of two frontends, selected by the synthesis Target's flow_options.frontend (or the --frontend override):

sv2v is the default and works on every sandbox image. slang skips the transpile step and handles SystemVerilog constructs sv2v can choke on (complex interfaces/modports, some casts), but needs a Yosys-0.67-or-newer image; on an older image synth fails fast with a message telling you to switch frontend or upgrade the image. Both frontends feed the same tech-mapping tail (dfflibmap → ABC → stat) and the same optional OpenROAD physical path, so the choice affects only RTL frontend processing, not the PPA methodology.

Which to pick. Stay on sv2v unless it fails. Reach for slang when the design puts parameterized interfaces on module port lists, or reads their parameters hierarchically (localparam KEEP_W = s_axis_tx.KEEP_W). sv2v cannot transpile either, and for such a design slang is not a preference but a requirement.

Neither frontend is strictly more capable, so "try the other one" is a real move in both directions. Before concluding that a design cannot be synthesized, check the known slang and sv2v failure signatures and workarounds.

Assertion behavior differs by frontend. sv2v drops SVA, so a design full of assert property reaches Yosys assertion-free. slang instead lowers SVA into $check cells; the flow strips those cells before tech mapping, so they neither reach ABC nor corrupt the netlist handed to OpenROAD. If your design guards its assertions behind a define (NO_ASSERTIONS and friends), setting it on the ASIC Target is still the cleanest option because it keeps RTL frontend processing cheap.

Versions in the sandbox image¶

Everything below is pinned in src/booley/data/docker/Dockerfile.base (the image digest and ARG lines are the source of truth). This table is what a fresh booley-sandbox build gives you; a project image may add to it, and [sandbox].pip_requirements may override the Python rows (see SANDBOX.md).

Verilator 5.052 includes the nested-shift compiler fix required for native coverage. The image includes LZ4 development headers for native FST model builds and retains the system allocator.

Check what your image actually has rather than trusting the table after an upgrade:

booley doctor -v                                  # prints each EDA tool's version line
booley session enter -- verilator --version       # or any other EDA tool
booley session enter -- python -m pip list        # the Python side

The RISC-V variant (booley-sandbox-riscv) adds xPack RISC-V GCC 15.2.0-1 and a tested official-master Spike snapshot at 609dbe0b9994154833039209fa37151e7c05e9d4 (1.1.1-dev) on top of these. Upstream has no maintained stable release suitable for Ubuntu 26.04, so Booley refreshes this exact official-master pin once per Booley release, after its image and RISC-V acceptance gates pass; see ADR 0069. This is upstream Spike, not lowRISC's ibex-cosim fork that Ibex's UVM co-simulation needs. See also SANDBOX.md.

Future commercial EDA integrations require their own built-in provisioning, licensing, Doctor, security, and full-Flow evidence before they can join this matrix. Planned integrations live in ROADMAP.md.

Native coverage capabilities¶

Coverage requires stable Verilator v5.052, full commit ea338be98e1e838d3518809ce8899f85a009963c; 5.050 is excluded. Explicit collection selecting any Icarus Target is an atomic all-Target Preflight error.

Capabilities distinguish reported (parsed and retained), absent (no records), and unsupported (cannot produce or safely interpret). Unscored does not mean unsupported. Generated-main, declared custom-main, HDL-testbench, and Cocotb harnesses are supported; every selected test owns its native database and process.

Source: docs/user/SUPPORTED-EDA-TOOLS.md on GitHub