Blog › How to run an AI agent on FPGA work
How to run an AI agent on FPGA work
The practical companion to the case study: what to set up before pointing an artificial intelligence (AI) coding agent at a field-programmable gate array (FPGA) project, how the working loop fits together, and — the question every reader asks first — the level of design complexity this approach has actually been demonstrated at. Every claim below traces to the public agilex_3_ai_benchmarks repository.
Published 2026-07-28.
The working loop
The engineer and the agent never share a screen. They share a repository, and the repository carries the contract: the canonical numbers, the conventions, the issue roadmap, and the schema every result must satisfy. The agent drives the toolchain and the board through scripts; the engineer reviews, merges, and provides the physical hands.
Setup, in seven steps
- Write the numbers down first. Before any RTL, create a canonical numbers document — silicon budgets, memory walls, derating assumptions, each with provenance. The agent’s standing rule is one sentence: never invent a number; cite the document. The case study’s version is
docs/PLAN.md. - Encode the discipline in a conventions file. Reset style, clock-domain-crossing policy, bus naming, testbench requirements, tool versions, and the honesty rules: estimates are labeled estimates, and no checkbox gets marked that was not verified. See
AGENTS.md. This is the same document a new human hire should get; writing it for an agent forces it to exist. - Cut the work into self-contained issues. Each issue states its acceptance criteria and dependencies. One issue, one branch, one pull request, and the pull request walks every criterion with evidence. Small units keep review tractable and failures cheap.
- Make every claim machine-checkable. Self-checking testbenches (Verilator runs anywhere the agent runs), pytest for tooling, and a results schema that makes configuration fields mandatory and separates
estimatefrommeasured. The agent cannot fabricate what the schema and the testbench refuse to accept. - Script the vendor flow end to end. Every project rebuilds from one command-line invocation; no state lives only in a graphical interface. This is what lets the agent iterate on synthesis, fitting, and timing unattended — and what makes every result reproducible by anyone.
- Forward the hardware. A board on a desk becomes agent-reachable with USB passthrough and a containerized vendor programmer; the Joint Test Action Group (JTAG) port is the control plane. If more than one session touches the board, add a lock file protocol — the case study’s is about a hundred lines of shell.
- Define the handoff and hold the review. Steps that need physical hands — plugging, power-cycling, probing — are listed by the agent under a “Hardware handoff” heading, never simulated into a checked box. The engineer stays sole approver on every merge.
What level of FPGA complexity this works at
The honest answer is a ladder, with a demonstrated rung and an undemonstrated one. The case-study project sits well above tutorial scale: a 100K logic-element Agilex 3 filled to 97 % of logic and 87 % of block memory, a multi-clock design with an external double-data-rate memory interface, vendor AI inference IP, and custom bus-bridge RTL — mid-complexity professional work.
| Level | What it looks like | Status in the case study |
|---|---|---|
| 1. Flow tooling | Build drivers, report parsers, result schemas, timing-report audits | Demonstrated; fully agent-verifiable without hardware |
| 2. Simulation-verified RTL | Modules with self-checking testbenches: bus bridges, scoreboards, microbenchmark cores | Demonstrated; Verilator closes the loop on the agent’s own machine |
| 3. Full-chip integration and timing closure | Scripted system integration, timing constraints, multi-clock architecture, external-memory interface, near-full device utilization | Demonstrated; 97 % logic utilization fit with a retuned clock plan |
| 4. Board bring-up and silicon debug | JTAG bring-up, on-chip capture, isolating a silicon-level write-path defect, per-build on-silicon regression | Demonstrated, with human hands for physical steps only |
| 5. Beyond | High-speed serial transceiver bring-up, multi-board systems, safety-certified flows, systems-on-chip at emulation scale | Not demonstrated; no claim made |
The controlling variable is not device size. It is whether each layer of the work produces evidence a script can check: a simulation exit code, a fitter report, a timing summary, a register read from silicon. Wherever that holds, the agent climbs the ladder — including the least favorable case the project hit, an input/output timing defect that static analysis could not see, which the agent handled the way an engineer would: hypothesis-driven silicon experiments, a workaround in RTL, and a scripted on-board regression run after every rebuild. Where evidence needs an oscilloscope probe or a lab instrument the agent cannot drive, the work crosses into the handoff protocol, and the engineer’s share grows.
Level 5 is a statement about what has been shown, not about a ceiling. The association will move rungs up this ladder as projects demonstrate them, and invites contributed reports from teams running the same experiment at other scales.
Further reading
The case study narrates the eight days this method produced, number by number. The repository is the primary source — plan, conventions, issues, and every measured result with its configuration attached. The systems-engineering framing behind the method is developed in the association’s AI-Augmented Systems Engineering course.