FPGA and Agentic AI Glossary

These articles are read from both sides. An FPGA engineer meets the agentic AI vocabulary for the first time; someone who writes software every day meets RTL and timing closure. This page defines both, once, so the articles do not have to stop and explain. It is a working list and it grows as the articles do.

Agentic AI

Agent / agentic

An agent is AI that runs the tools itself: it edits a file, runs a command, reads what the command prints, and decides what to do next from that, on repeat until a stop condition is met. What makes it agentic is that it acts on the tool's answer rather than on its own confidence.

Chatbot vs agent

A chatbot answers a question in a reply you have to check yourself. An agent runs the check itself and only then reports back, so the tool, not the model's confidence, tells you whether it worked.

The agentic loop

The cycle an agent runs on every task: plan the step, act by editing or running something, observe what the tool reports, and iterate from that observation. A tool that only generates code without running anything collapses this to plan, act, stop.

Two loops

The simulation loop is the fast cycle of edit, lint, simulate and check that runs on every change. The synthesis and implementation loop is the slower cycle of synthesis, place and route, and timing analysis that normally only starts once simulation is green. A failure in either sends the agent back to the edit.

Stop condition

The description of "done" the agent is working towards, in terms a tool can answer: lint clean, simulation passing with no mismatches, coverage full, timing met. Every requirement in it means more runs before the agent may stop, so the most thorough stop condition is also the most expensive.

Two attempt rule

A cap on how many times an agent may try the same failing check before it must stop and report instead of iterating further. It exists so a stuck agent hands the problem back rather than spending unbounded runs chasing the same failure.

Preflight

A check the agent runs before starting work, to find out which tools are actually installed. Running it first stops the agent from either inventing a result for a missing tool or burning attempts trying to install one.

Guard

A check that compares the files the agent was told not to touch against what git last recorded, and reports GUARD OK or names the file that changed. It catches an edit that got through despite the permission settings rather than trusting those settings held. It compares against a recorded baseline, so an agent that can also commit can move that baseline, which is why it sits alongside permissions rather than replacing them.

Project instructions file

CLAUDE.md and AGENTS.md are files an agent reads automatically at the start of a session, holding the standing rules for a project: which files it may not edit, coding style, how to run the tests. They save retyping the same rules into every prompt.

Agent Skill

A packaged set of instructions for one job, as a folder with a SKILL.md file and optionally scripts or reference files alongside. The agent loads the full instructions only when a task matches, so a library of skills costs almost nothing until it is needed.

MCP

The Model Context Protocol, an open standard for connecting an agent to an external tool or data source, so that tool can be exposed once and called by any agent that speaks the protocol rather than integrated separately for each one.

Reward hacking

Also called gaming the test. The agent satisfies a check by weakening it, loosening an assertion, narrowing the stimulus or skipping a case, instead of fixing the design underneath. It looks identical to a genuine pass unless someone reads the diff of the check itself, which is why the checks belong in files the agent may not edit.

Verification

Testbench

The code that drives the design under test with stimulus and checks what comes out. It has to come from the specification rather than from the design it is checking, or a passing test proves only that the design agrees with itself.

Reference model

An independent implementation of what the design should do, built from the specification rather than from the RTL, that the testbench compares the design's output against. If one reading of the spec produced both the design and the model, a mistake in that reading passes unnoticed.

Coverage

A measure of what the tests actually exercised. Code coverage asks whether every line and branch ran. Functional coverage asks whether the scenarios that matter were hit, such as every packet length or every point at which back pressure can occur. The two are not interchangeable: a design can have full code coverage and a large functional coverage gap, and it is functional coverage that catches an untested path in the articles here.

Clock domain crossing (CDC)

A signal moving between logic run by two different clocks. It needs a synchroniser or a handshake, because a signal can arrive at an unpredictable point in the receiving clock's cycle and go metastable, which is a bug that passes simulation and fails intermittently on hardware.

Implementation

RTL

Register transfer level, the code that describes hardware: what a register holds, and what logic feeds it on each clock edge. It is what an FPGA designer writes and what an agent edits in this loop.

HDL

Hardware description language, the language RTL is written in, which here means Verilog, SystemVerilog or VHDL. An agent editing HDL is running the same edit, run, read loop as one editing Python, on different code and different tools.

Lint

A static check on the RTL that runs before simulation. It flags a width mismatch or a likely latch by reading the code rather than running it, which makes it the cheapest and fastest check in the loop, and a linter with synthesis rules also flags constructs that simulate but cannot be synthesised.

Synthesis

The step that turns RTL into a netlist of the logic cells a device would actually use. It is where "it simulates" becomes "it builds", and it catches what lint cannot, such as a memory that became distributed logic or a block that does not fit the part.

Inferred latch

A latch the tools build without being asked, because a block meant to be combinational does not assign a signal on every path: an if without an else, a case without a default. Simulation often hides it. Synthesis and a linter with synthesis rules do not.

Slack

The margin, in nanoseconds, between how long a signal path is allowed to take and how long it actually takes after place and route. Positive slack means the design meets the clock. Negative slack means it misses timing, however well it simulates.

Interfaces

AXI-Stream handshake

AXI-Stream moves data one direction, one beat per clock edge, whenever both tvalid and tready are high. The sender may not wait for tready before raising tvalid, and once tvalid is high the data must not change until the beat transfers.

Back pressure

What happens when the receiver is not ready: the sender holds its data steady and waits rather than pushing it through. In AXI-Stream it is tready going low while tvalid is high, and it is the case a converter is most likely to get wrong.

tkeep and tlast

tlast marks the final beat of a packet. tkeep marks which bytes of that beat actually hold data, for a packet that does not end on a whole word. The rest of the word is padding, and the checker should not compare it.

Related Articles

Related article Agentic AI for FPGA Design: How the Loop Works An introduction to agentic AI for FPGA design: what separates an agent from a chatbot, what the plan, act, observe, iterate loop looks like on RTL, and what it takes to set one up.

Related article Using Vivado's New AI Chatbot: A Practical Guide A practical guide to AMD's Vivado chatbot: what to ask, where it helps, where it can mislead, and how to verify its answers against docs and tool reports.