An AXI-4 constrained-random driver can turn a day of testbench work into a reviewable draft in minutes, especially when the target is a small compute block with a defined port interface. The transaction class needs randomized address, burst length, and data fields. Its constraints must enforce alignment and legal burst sizes. The driver must model valid and ready timing, and the coverage group must measure burst-length distribution. In our early-access work, an agent produced roughly 95 percent of that structure correctly. Checking the remaining 5 percent was faster than building the component from an empty file.
That result does not generalize to every SystemVerilog pattern. Some components depend on micro-architectural intent, undocumented device rules, or multi-transaction behavior that cannot be inferred from RTL ports. The useful distinction is not whether AI generation is good or bad. It is whether the requested code is a repeatable structural pattern or an executable statement of design intent.
Structural Templates Still Need Block-Specific Work
Most verification teams have templates for UVM drivers, monitors, scoreboards, and coverage collectors. These templates preserve familiar class hierarchies and factory patterns, but they do not remove adaptation work. Constraints must describe the legal input space for the current block. Coverage must reflect its behavioral requirements. A scoreboard must model expected output from the relevant input history.
Interface templates also have narrow boundaries. An AXI-4 template does not transfer directly to APB or CHI. A coverage template built for a memory controller is not a useful specification for a packet processor. Engineers often spend more time changing templates than using them.
This is where generation helps most. Give the agent the RTL port interface, protocol rules, coverage groups, and block-specific exceptions. It can produce the structural variant while the engineer concentrates on whether the specification itself is complete.
Constrained-Random Drivers and Sequencers
Constrained-random drivers are a strong fit because their ingredients are explicit. A transaction object declares randomizable fields. Constraint blocks define legal values. A driving task serializes transactions according to protocol timing. A coverage collector records functional behavior at the transaction level.
For a standard AXI-4 interface, an agent can usually generate field declarations, alignment and size constraints, exclusions for zero-length or illegal-length bursts, and a valid/ready handshake implementation. This is repetitive construction, and the generated structure is generally easy to inspect in Xcelium, VCS, or QuestaSim.
The review boundary is device-specific legality. A datasheet may reserve address ranges or prohibit a legal abstract-protocol combination. The agent cannot infer those rules from ports alone. Put them in the generation request and the resulting constraints can encode them. Omit them and the driver may create transactions that are legal AXI-4 traffic but illegal for the device.
UVM sequence infrastructure has a similar profile. Sequence items, base sequence hierarchies, p_sequencer binding, factory registration, start-method overrides, and sequencer connections are structural. Agents handle these patterns well when the interface description is clear.
Scenario sequences are different. A read-modify-write operation on a semaphore register may depend on a read-and-clear window. A back-pressure sequence may need the exact conditions under which the DUT de-asserts ready. Generate the sequencer framework, then write those protocol scenarios yourself. That split keeps engineer attention on the behavior that requires interpretation.
Coverage Groups and Randomized Objects
Coverage declarations for enumerated types and state-machine transitions are also suitable for generation. From the defined states, an agent can create state-to-next-state cross coverage, add illegal_bins for forbidden transitions, and account for self-loops and null transitions.
At the interface level, it can enumerate useful crosses such as burst type with burst length or protection type with data width. This mechanical bin construction is tedious by hand and maps naturally from a protocol specification into SystemVerilog.
Coverage names still require an explicit convention. Generated names such as trans_cg and bin_state_0 compile, but they make UCDB and UCIS reports harder to navigate. Specify names for groups and bins in the prompt. The agent can apply that convention consistently, which matters when Coverage Tracker compares results across regressions.
Randomized transaction objects for scoreboard checking are another productive target. Given expected input-output behavior, an agent can draft the reference transaction class, pre-randomize and post-randomize hooks, a comparison function, and constraints that bias values toward corner cases.
The useful part is the connection between uncovered bins and stimulus. If the coverage gaps are supplied as context, the generated constraints can prioritize the missing combinations instead of merely reproducing a generic template. Test Writer can handle that mechanical translation, while the engineer decides whether the requested bins actually represent meaningful behavior.
Where Manual Authoring Remains Safer
SystemVerilog Assertions are the clearest counter-point. SVA properties encode temporal relationships over arbitrary intervals, often with implication operators and conditional sequences. Their correctness depends on the micro-architectural behavior of the block, not only on the abstract protocol.
An agent can produce syntactically valid SVA while asserting the wrong causality or omitting an exception. That is dangerous because a passing property can create false confidence. Engineers who understand the block's intent usually write better assertions than an agent working from interface descriptions.
We use generation around assertions rather than for the assertion meaning itself. An agent can draft the bind module, connect properties into the DUT hierarchy, collect assertion activity in coverage, and prepare analysis reports. The properties remain under human ownership.
Complex scoreboards have the same boundary. A model for cache-coherence state across multiple memory masters, or for out-of-order completion in a PCIe root complex, requires correctness criteria that ports do not expose. Agents can create the scoreboard skeleton and transaction plumbing. The engineer must implement and review the design-intent logic.
A Practical Review Boundary
Our small-team workflow uses two levels. The engineer defines what must be tested: coverage objectives, protocol scenarios, assertion properties, and the exceptions that make this block different. That is the intent layer.
The agent receives the implementation request: these fields and constraints, this sequence hierarchy, these state transitions, and these naming rules. It writes the mechanical construction. Failure Explainer can then help classify review findings, especially when a coverage result or simulator error points to a mismatch between the request and the generated code.
For an engineer familiar with the protocol, reviewing generated SystemVerilog typically takes 20 to 30 minutes per component. That is materially less than authoring the same component from scratch, and review has a useful advantage: the complete draft makes missing constraints and incorrect assumptions visible. The recurring findings are device-specific legality and naming deviations, not basic class structure.
We are not saying that agents can replace verification judgment, and we are not saying that templates become unnecessary. We are saying that generation is most effective where the specification is explicit and the implementation repeats. The practical implication is to route structural drivers, sequencers, coverage declarations, and transaction objects to generation, while reserving manual design time for assertions and correctness models whose meaning lives beyond the interface.
The 9-minute reading estimate is optimistic if the constraint details are examined line by line, but the engineering decision is straightforward: use generation to shorten construction, then spend the saved time on the assumptions that determine whether coverage and checking describe the RTL you actually intend to tape out.