Extending a RISC-V core with a custom instruction set extension today is a multi-week process: write the ISA spec, manually patch the RTL for each core you target, update the compiler, set up a differential test harness, and debug the mismatches where your changes broke the formal model. LACE cuts that down to a prompt. The system converts natural-language ISAX intent into a two-level IR (operation-level, then HDL task-level), uses retrieval-guided localized edits to patch large RTL repositories, and closes the loop with a compiler-agnostic riscv-formal checking flow. Across four embedded RISC-V cores, it raises pass@1 from near-zero to 72.8%.
The architectural move that makes LACE work is the intermediate representation. Direct LLM-to-RTL generation fails on large codebases because the model has no stable anchor for where changes should land. LACE's IR decomposes the ISAX intent into named operations at the spec level, then maps each operation to a localized RTL patch with a defined change scope. That localization is what retrieval-guided editing then acts on, keeping patch sets small enough for the formal checker to verify without manual RTL review. The riscv-formal integration means the verification loop closes automatically if RVFI instrumentation is available on the target core.
The 72.8% pass@1 number is honest about what it covers: four cores in the evaluation setup, with RVFI available, on ISAXes that fit the two-level IR decomposition. That is not a claim it works everywhere. What it is: the first system to automate the per-core interface adaptation step that currently makes ISA extension fragmented across the RISC-V ecosystem. Teams building domain-specific RISC-V variants for inference, control, or cryptographic workloads spend a meaningful fraction of NPI time on exactly this per-core porting work. That time is now partially automatable. Vendors who sell RISC-V processor configurator licenses as a substitute for this work are looking at a compressed value proposition.