Skip to main content
Lab Notes

Tools

Adding AI Agents to Your EDA Flow Without Replacing Your Toolchain

Lena Hoffmann 9 min read
EDA flow integration diagram showing AI agent connection without toolchain replacement

On a USB 3.0 host controller block, the first ChipAgents coverage report arrived 38 minutes after the team began integration. Their concern was not test generation. It was whether adding an agent would force a new simulator setup or a rebuilt Makefile. It did not. The integration point is the coverage database produced by the existing flow.

Keep the Simulator, Exchange Files

ChipAgents sits between simulator output and regression input. Xcelium, VCS, or QuestaSim runs with its current scripts and options. After simulation, the tool writes coverage data. ChipAgents reads that data with the RTL, identifies uncovered bins, generates targeted SystemVerilog tests, and writes those tests to a directory that the next regression can compile.

This is a file exchange, not a simulator plugin. A plugin brings tool-version builds, EDA release compatibility work, and possible vendor coordination. File exchange needs a directory path and one post-simulation command. For a team with years invested in a stable verification Makefile, that is a smaller operational change.

The agent uses the coverage model and RTL together. Mapping bins to branches, state machine transitions, assertions, and other RTL constructs is what distinguishes targeted stimulus from another batch of unconstrained or weakly correlated random inputs.

Export Coverage from the Existing Flow

Coverage flags are often already present in the simulation command. If not, adding them is usually a small command-line change.

For Cadence Xcelium, a coverage-enabled run can write a UCDb database like this:

xrun -coverage all -covworkdir ./cov_work \
     -covdb run1 \
     your_testbench.sv your_dut.sv

The resulting database is ./cov_work/run1.ucdb. For multiple seeds, Xcelium's imc -exec merge combines per-seed databases into one merged UCDb before analysis.

Synopsys VCS collects coverage under the directory named by -cm_dir:

vcs -cm line+tgl+fsm+branch+assert \
    -cm_dir ./coverage/my_cov_work \
    your_testbench.sv your_dut.sv

After the run, urg can merge per-seed data and produce a UCIS-compatible export. ChipAgents accepts either the raw VCS coverage directory or merged UCIS XML.

With Mentor QuestaSim, the simulation command coverage save coverage.ucdb can run at the end of a session or from a run script. Its UCDb output uses the same standard coverage interchange expected by the analysis step.

Run Analysis Against RTL and Coverage

Once the database or directory is available, the analysis command is short:

chipagents analyze \
  --coverage-db ./cov_work/merged.ucdb \
  --rtl-root ./rtl/usb3_host \
  --output-dir ./generated_tests

--rtl-root identifies the RTL source tree. ChipAgents maps coverage bins back to source constructs, then generates stimulus for the paths associated with the gaps. The result is intended to target a particular branch, transition, assertion condition, or protocol sequence, not to produce generic tests without reference to the design.

Runtime depends on the coverage model. A block with 200 to 400 coverage groups generally completes in under two minutes. Hierarchical models with per-instance bins can be analyzed independently. A large flat model with thousands of bins may benefit from pre-filtering to the functionally important groups before analysis.

Review the Output, Then Add Tests

The output directory contains structured JSON and human-readable HTML gap reports. They list uncovered bins and rank them by estimated difficulty. A bin requiring a deep error-recovery sequence ranks differently from one tied to a counter boundary. The HTML is for review, while the JSON can feed CI.

Generated tests are SystemVerilog files. Each addresses one gap or a related group. For example, a link-state test might narrow a constrained-random class or issue a directed sequence that establishes required preconditions before applying the triggering transaction. The tests call the existing interface drivers, constraint classes, and checkers in the team's testbench.

We review generated tests before compilation. For a typical gap set of 10 to 30 tests, intent review takes about 10 to 20 minutes per block. That checkpoint matters because a syntactically valid test can still express the wrong verification intent.

A generated test can live beside hand-written tests in a project directory:

generated_tests/
  gap_usb3_error_recovery_seq.sv
  gap_endpoint_stall_handling.sv
  gap_split_transaction_timeout.sv

The Makefile can include the directory without changing the simulator target:

TESTS += $(wildcard generated_tests/*.sv)

These tests compile against the existing UVM environment and use the current coverage groups, checkers, and run scripts. Their coverage writes to the same UCDb flow, so generated and hand-written tests can be merged in the existing report process.

After regression, run coverage again. If a bin remains open, the diagnostic distinguishes a likely testplan issue, such as a structurally unreachable scenario, from a stimulus model that needs refinement for that coverage group.

Place the Agent in CI

For a Jenkins or GitLab CI regression, analysis belongs after coverage merge. The pipeline can use this sequence:

  1. Run simulation with coverage collection enabled.
  2. Merge coverage databases across seeds.
  3. Run chipagents analyze to create the gap report and generated tests.
  4. Apply the configured coverage gate and flag runs below threshold for review.
  5. Optionally start another regression that includes the generated tests.

A project targeting 95 percent functional coverage might set its review gate at 90 percent. A run below 90 percent, without candidate tests addressing the gaps, then requires engineer attention rather than disappearing into a manual weekly review.

The gate is useful only when the report includes actionable candidates. A threshold alert without generated tests creates another queue of work. Pairing the alert with gap-specific test files lets the team respond within the same CI cycle.

Boundaries and Practical Questions

We are not saying ChipAgents replaces the simulator, UVM environment, testplan, coverage goals, or engineering review. We are saying it reads coverage output and writes candidate tests to a directory. It does not alter the RTL hierarchy, EDA configuration, regression targets, assertions, wave dump setup, licenses, or existing coverage definitions.

That boundary is deliberate for a small verification team in the middle of a sprint. Existing Xcelium, VCS, or QuestaSim versions remain in place, and the team decides which generated tests enter regression.

For a well-formed UCDb and accessible RTL, initial analysis typically finishes in under five minutes after setup. In the USB 3.0 example, the first report took 38 minutes largely because the team had to locate the correct UCDb in its coverage work directory.

Custom coverage group and bin names are accepted as defined in the database. No naming convention is required. RTL is read during the analysis session and is not retained after it ends. Coverage and RTL are processed for that run only.

Multiple engineers can analyze the same database concurrently because it is read-only input. Those sessions do not interfere with one another or with the simulation environment that produced the database. The practical integration task is therefore to expose the right UCDb, point the agent at the matching RTL revision, and keep review between generation and regression.

ChipAgents

Connect ChipAgents to your Cadence or Synopsys flow today

UCDb export, ChipAgents analysis, test vector import: under an hour of setup for most teams.

Request Access