RISC-V LinuxBetaOPEN SILICON. SHARED KNOWLEDGE.

LLM Agent-Based Design of RISC-V CPUs with FPGA-in-the-Loop Evaluation

AI Analysis Abstract This work introduces a development environment that integrates LLM agents with FPGA-in-the-loop evaluation for designing RISC-V CPUs. The system allows LLM agents to implement CPU candidates on an FPGA and utilize on-board performance measurements to guide…

Conceptual illustration of a processor connected to a neural network
AI-generated editorial illustration.

AI Analysis

Abstract

This work introduces a development environment that integrates LLM agents with FPGA-in-the-loop evaluation for designing RISC-V CPUs. The system allows LLM agents to implement CPU candidates on an FPGA and utilize on-board performance measurements to guide design decisions, thereby addressing the time-consuming nature of long-run RTL simulations. Applied to the human-supervised development of a single-cycle RV32I core into a three-wide out-of-order RV32IM core, the approach demonstrated significant speedups in evaluation time. The final design achieved 5.61 CoreMark/MHz at 130 MHz on an Artix-7 FPGA, and the methodology proved effective in identifying long-run performance degradations that short diagnostic runs missed.

Key Highlights

  • Introduced an FPGA-in-the-loop evaluation environment for LLM agent-based RISC-V CPU design.
  • Achieved a 9.6x to 13.7x speedup in CPU candidate evaluation time compared to single-threaded RTL simulation.
  • Successfully developed a three-wide out-of-order RV32IM core reaching 5.61 CoreMark/MHz at 130 MHz on an Artix-7 FPGA.
  • Demonstrated the ability to detect long-run performance degradation on hardware that short diagnostic simulations failed to identify, leading to root-cause analysis and fixes.

Technical Details

  • The development environment connects agent-driven RTL changes to on-board evaluation under human supervision.
  • Human roles include setting goals, proposing directions (e.g., multiple issue, out-of-order execution), approving work, and deciding when to stop.
  • LLM agents (GPT models for orchestration, Qwen3.8-Flash-Next for implementation/analysis) write and modify CPU RTL, perform detailed design, implementation, optimization, analysis, and verification.
  • FPGA evaluation uses a Nexys Video board, Vivado, hw_server, and a serial API for resource usage, timing, cycle counts, and CRCs.
  • Functional verification includes lint, directed tests, and per-retirement comparison with a custom Python RV32IM instruction-set model.
  • The final CPU design is a three-wide out-of-order RV32IM core with register renaming, timing-aware pipeline partitioning, register-move aliasing, and a two-way BTB.
  • The core achieved 730.6 iter/s at 130.137 MHz over 8,000 CoreMark iterations and a geometric-mean frequency-normalized score of 1.759 on 18 Embench-IoT benchmarks.
  • A case study revealed a load-wait predictor issue causing a 9.98% increase in cycle count over 8,000 iterations, which was diagnosed via per-iteration RTL analysis and fixed.

Implications

  • The FPGA-in-the-loop approach significantly accelerates the design and verification cycle for LLM-agent-based CPU development.
  • Enables the detection and resolution of complex, long-run performance issues that are difficult to identify with traditional RTL simulation methods.
  • Provides a robust framework for integrating physical hardware evaluation into AI-driven hardware design flows, enhancing the reliability and performance of generated designs.
  • The achieved CoreMark/MHz performance demonstrates the potential for LLM agents, guided by hardware feedback, to design competitive RISC-V cores.

Limitations

  • The development process still requires human supervision for setting high-level goals, approving changes, and determining project completion.
  • The reported development activity statistics are based on three adopted changes and do not represent a complete census of all development activity.
  • Comparisons with existing soft cores (VexRiscv, NaxRiscv) are limited by differences in speed grades, memory configurations, compiler settings, and design scopes.
  • The 'cubic' benchmark from Embench-IoT could not be evaluated due to instruction memory size constraints (32 KiB).

Source: https://arxiv.org/abs/2610.39570