Bit-Manipulation extension (Zba/Zbb/Zbc/Zbs)

The Bit-Manipulation extension (commonly grouped under the Zb* umbrella — Zba, Zbb, Zbc, Zbs) is a standard RISC-V ISA extension that adds instructions for bit-level and small-integer arithmetic operations. In the CHIA riscv_extensions case study, it is treated as a first-class target extension alongside scalar Cryptography (Zbk*/Zkn*) and Zicond.

Role in the CHIA riscv_extensions flow

In the riscv_extensions example, Bit-Manipulation is registered as the "bitmanip" extension entry:

EXTENSIONS = {
    "bitmanip": Extension(name="bitmanip", isa_suffix="_zba_zbb_zbc_zbs", ...),
    "crypto":   Extension(..., isa_suffix="_zbkb_zbkc_zbkx_zknd_zkne_zknh",
                          dv_target="riscv_dv_target_crypto"),
    "zicond":   Extension(..., isa_suffix="_zicond",
                          dv_target="riscv_dv_target_zicond"),
}

This entry ties the Zba/Zbb/Zbc/Zbs ISA string to CHIA's extension pipeline.

Verification methodology

As one of the three implemented extensions, Bit-Manipulation is taken through CHIA's full verify-then-stress loop:

1. Directed tests. One minimal program per instruction is emitted from specs/bitmanip/instructions.json (the closed instruction set generated from riscv-opcodes) and cross-compiled to ELF. Coverage is 100% by construction because the table is the instruction set.
2. Base-ISA regression. The full base-ISA riscv-test suite is run on the DUT so the Bit-Manipulation implementation cannot break unrelated instructions.
3. Stress testing. riscv-dv generates large random programs that weave Bit-Manipulation instructions through ordinary code — hazards, loops, memory traffic — and streams them through parallel lockstep cosims against Spike. A single divergence resets the pool, and the stress phase only declares success on a clean run.

Bit-Manipulation is the only one of the three extensions with native riscv-dv support; the case study notes that "riscv-dv can generate bitmanip, but has no generator for scalar crypto or Zicond." The crypto and Zicond extensions therefore define riscv-dv custom targets; Bit-Manipulation uses riscv-dv's native Zb* support.

Differential verification against Spike

Throughout, Spike is the golden oracle. Spike is compiled into the simulator (cospike), and CosimNode runs one ELF in lockstep between the DUT and Spike. The embedded Spike's ISA string comes from the DUT's own config, so the oracle always decodes exactly what the core claims to implement. For Bit-Manipulation, this means the Spike instance decodes with the Zba/Zbb/Zbc/Zbs ISA string and checks every committed instruction against the architectural specification. No expected outputs are hand-encoded.

LLM-in-the-loop implementation

The Bit-Manipulation RTL is written by an LLM editing BOOM Chisel, guided by the ratified spec provided as input. On a stress divergence, a debug LLM is handed the failing lockstep trace and repairs the RTL; the verify-then-stress loop restarts, and a fresh clean stress run is the bar to converge. The implementing and debugging agents run on an llm worker via ClaudeCodeLLM with resume_session=True, and the LLM's editor tool is pinned to the same Chipyard build-host bundle so its edits land in that host's BOOM tree.

Reported result

Per the CHIA documentation's "Result" note, Bit-Manipulation (Zba/Zbb/Zbc/Zbs) — along with scalar Cryptography and Zicond — was implemented and verified on a MegaBOOM core. The three extensions together deliver approximately 5.6% and 3.5% speedups (with up to 10× on OpenSSL crypto), no timing regressions, and only modest area overhead in SkyWater 130nm. Full per-extension sweeps store the BOOM diff, LLM transcripts, per-test simulation logs, PPA delta against the unmodified core, and the generated stimulus. The case-study paper (arXiv:2606.27350) provides additional results.