An AI agent can plan an HDL task, call its tools, and declare the job finished. This recorded webinar shows what that “finished” is worth on a real project, and what it takes to check it.
The agent says “done”. What does your project say?
If you have let a coding agent loose on an HDL task, you know the hard part is not watching it write code. It is the moment it tells you the job is finished.
In our previous webinar on Agentic AI, each demo gave an agent one bounded task in a project that was already set up: generate a controller until it met the project’s naming rules, add a missing library mapping, fix the include directories of a UVM testbench, format a workspace. The agent worked inside the editor and reached Sigasi through MCP.
This webinar takes the next step. The agent gets a whole objective. It plans the steps, chooses its tools, and carries context from one action into the next until it decides the work is done. That changes what can go wrong, and what the check has to do.
Two workflows, shown live
Requirements in, project out. An agent starts from a set of design requirements and creates and configures a complete HDL project from scratch, with no scaffolding provided in advance. For this demo, Sigasi does not correct the agent while it works. Instead, we run Sigasi on what the agent built after it declared the job done, and go through what is still wrong.
Existing codebase in, simulation out. An agent takes a codebase it has never seen and turns it into a Project. Instead of guessing how the files fit together, it asks Sigasi for a compilation recipe: the compile order, library mappings, and dependencies derived from the actual project rather than reconstructed by the model. The agent then uses that recipe to drive a downstream simulation workflow.
What changes when the agent does the whole job
Mistakes compound. In a single task, a wrong library mapping is one wrong answer you see right away. Over a whole objective, every later step builds on it. The first demo shows what that looks like by the time the agent calls the work finished.
The agent’s “done” replaces your checkpoints. Nobody reviews between the steps, so the check has to run between them, at the speed the agent iterates. A check that takes minutes either gets skipped or runs after the agent has already built on its own mistakes.
The agent leaves the editor. A whole job runs as a scripted workflow across several tools. The check has to be a tool the agent can call from that workflow, not only a view an engineer looks at.
The tooling behind it
The CLI. In June, the agent reached Sigasi through MCP inside VS Code. This time it uses the CLI: the same project-aware analysis, called from the command line, so the agent can use it as one tool among several. Through the CLI, an agent can verify the full project, pull structured diagnostics, retrieve the compile order and compilation recipes, and generate documentation.
Daemon mode. An agent iterating on a design does not call an analysis tool once. It modifies, checks, and modifies again, sometimes dozens of times in one session. Daemon mode keeps the project loaded between calls, so after the first call, each check only processes what changed.
Skills. Skills are reusable, task-specific instructions that tell an agent how a kind of HDL work should be done: how to set up a project, when to check diagnostics, how to reason about compile order. Skills guide the agent’s process. The CLI gives it the deterministic project facts to act on. Neither replaces the other, and both demos show them working together.
Local analysis. Sigasi analyzes your project on your own infrastructure, on-premises or in your VPC. Sigasi does not store design data outside your environment. A connected coding agent’s data handling depends on its own provider and configuration.
What you will learn
- where agents fail on project-level work: libraries, compile order, dependencies, and configuration
- how to check an agent’s result against the real project after it declares the job done
- how an agent can use project facts from Sigasi instead of guessing at project setup
- how the CLI and daemon mode keep repeated checks fast inside an agent loop
- how skills and deterministic diagnostics work together
- what has to be in place before you let an agent work through a whole objective
The goal is not more generated code. It is RTL that engineers can inspect, understand, and validate before it moves downstream.
Who should watch?
- RTL design engineers
- verification engineers
- technical leads and engineering managers
- CAD and methodology owners deciding whether, and how, coding agents fit into their flow
- teams already using Claude Code, Codex, Cursor, Copilot, or other coding agents for SystemVerilog, Verilog, or VHDL
- engineers who do not use agents yet and want to see where they break before anyone on their team relies on one
What this does not claim
Sigasi does not generate RTL. The agent, or the engineer, writes and modifies HDL. Sigasi analyzes it in project context when it is called.
A clean diagnostic list means the checks that ran found nothing, over the scope they cover. It does not mean the design is correct. Simulation, formal verification, timing analysis, and sign-off remain essential, and nothing shown here replaces them.
The engineer stays accountable for what moves downstream. Sigasi gives that decision a deterministic basis.
AI can generate HDL fast. Sigasi keeps engineers in control.
Fill in the form to get instant access to the recorded webinar.
We do not recommend using LLM agents for RTL without a deterministic check by Sigasi at interactive speed.