Skip to content
STIMSMITH

Bus-Handshake Timing

Concept WIKI v1 · 7/12/2026

Bus-handshake timing denotes the precise, clock-edge-ordered sequencing of control and data signals that a bus protocol requires to complete a transaction (e.g., address setup, strobe assertion, acknowledgment). It is a critical correctness property for UVM drivers and Bus Functional Models (BFMs). Because correct bus-handshake timing depends on hardware-specific conventions such as blocking vs. non-blocking assignments and clock-edge synchronization, Large Language Models (LLMs) that generate HDL directly frequently get it wrong; template- and rule-based code generation is used in the HAVEN system to guarantee it.

Bus-Handshake Timing

Definition

In the context of Universal Verification Methodology (UVM) testbench generation, bus-handshake timing refers to the protocol-defined temporal ordering of the control and data signals that together constitute one bus transaction. A handshake is the coordinated exchange of signals — such as address setup, strobe/valid assertion, and acknowledgment/ready return — that must occur across specific clock edges for the transaction to be considered valid by the Device Under Test (DUT).

The evidence describes a Wishbone transaction as a concrete example: it "requires a coordinated sequence of address setup, strobe assertion, and acknowledgment waiting." The correctness of such a sequence depends on matching each signal transition to the right clocking event in the UVM driver's clocking block, and on using the appropriate SystemVerilog blocking (=) versus non-blocking (<=) assignment for each step.

Why Bus-Handshake Timing Is a Hard Problem for LLM-Based HDL Generation

Bus-handshake timing is repeatedly identified in the evidence as a failure mode when LLMs are used to generate UVM components directly:

  • "LLMs find it hard to distinguish between blocking (=) and non-blocking (<=) assignments and to employ clock-edge synchronization correctly. These constructs have no analog in high-level languages, causing LLMs to frequently produce incorrect code."
  • Prior work such as UVM2 "covered only five simple UVM components, without protocol information. Consequently, when DUTs contain bus protocols with clocking-sequence events, misusing a blocking assignment in a bus-handshake protocol often causes the entire verification process to fail."
  • Self-correction-based LLM pipelines (e.g., AutoBench, CorrectBench, ConfiBench) "rely on iterative self-correction to repair errors," which is "expensive in both time and token usage and may still not yield correct results."

In short, bus-handshake timing is an area where small syntactic mistakes (wrong assignment operator, wrong clock edge) propagate to silent functional failures of the entire verification flow.

How HAVEN Guarantees Correct Bus-Handshake Timing

The HAVEN system treats bus-handshake timing as something that should not be written by an LLM. Instead, correctness is encoded into pre-defined, protocol-specific Jinja2 templates and a rule-based CodeGen:

  1. LLM role restricted to specification extraction. LLM agents analyze the design specification and emit two structured JSON artifacts — a UVM Blueprint (testbench structure, agent topology, component connectivity, interface protocol type) and Protocol Flows (signal-level data contracts). No HDL is written by the LLM.
  2. Template Engine. A Template Engine combines the Blueprint and Protocol Flows with pre-defined, protocol-specific Jinja2 templates to "generate all UVM components, including drivers with correct bus-handshake timing, peripheral Bus Functional Models (BFMs), and functional coverage subscribers." Because the templates "encode protocol-correct coding conventions," this approach "eliminates SystemVerilog syntax errors when using LLMs to generate UVM components."
  3. Rule-based CodeGen for sequences. A separate rule-based CodeGen translates DSL step types (e.g., register write, poll, value sweep, BFM action) into "protocol-correct UVM sequence code," so sequences also inherit correct bus-handshake timing even when the LLM composes them.
  4. Compile-fix loop. After template generation, a compile-fix loop validates that the resulting testbench compiles before further stages run.

This design is reported to achieve 100% compilation success across 19 open-source IP designs spanning the Direct, Wishbone, and AXI4-Lite interface protocols.

Protocols Where Bus-Handshake Timing Matters

The HAVEN evaluation covers three interface protocols in which bus-handshake timing is non-trivial:

  • Direct — a simple bus without multi-step handshakes.
  • Wishbone — multi-step handshakes requiring address setup, strobe assertion, and acknowledgment waiting.
  • AXI4-Lite — a lightweight AMBA protocol with its own valid/ready handshake conventions.

The abstract and main text describe HAVEN as "the first system that utilizes pre-defined, protocol-specific Jinja2 templates to generate all UVM components and UVM sequences using our proposed Protocol-Aware DSL and rule-based code generator," with the explicit goal of "preventing LLMs from writing HDL directly" so that timing-critical code (drivers, BFMs, sequences) is generated by the rule-based path.

Connection to Other Verification Concepts

  • UVM drivers and BFMs are the components in which bus-handshake timing is concretely realized in SystemVerilog.
  • Protocol-Aware Sequence DSL step types such as "register writes, polling loops, value sweeps, and BFM actions" exist so that stimulus generation can delegate handshake-correct signal sequencing to the rule-based CodeGen.
  • Functional and code coverage depend on bus-handshake timing being correct; otherwise valid stimulus never reaches the DUT and coverage collapses. HAVEN reports 90.6% average code coverage and 87.9% average functional coverage on the 19-IP benchmark, attributed in part to this correctness.

Reported Outcomes (HAVEN Evaluation)

  • 100% compilation success across all 19 IP designs, attributed to template-generated UVM components.
  • 90.6% average code coverage and 87.9% average functional coverage through iterative refinement of DSL sequences.
  • Pipeline cost averaging 6 LLM calls, 68k tokens, and $0.38 per design, with no per-design tuning.

CITATIONS

7 sources
7 citations
[1] HAVEN's Template Engine combines a UVM Blueprint and Protocol Flows with pre-defined, protocol-specific Jinja2 templates to generate UVM drivers with correct bus-handshake timing, peripheral Bus Functional Models, and functional coverage subscribers. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[2] A Wishbone transaction requires a coordinated sequence of address setup, strobe assertion, and acknowledgment waiting, illustrating what bus-handshake timing means concretely. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[3] LLMs find it hard to distinguish between blocking (=) and non-blocking (<=) assignments and to employ clock-edge synchronization correctly, which is what causes bus-handshake timing errors in LLM-generated HDL. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[4] Prior work UVM2 covered only five simple UVM components without protocol information, so misusing a blocking assignment in a bus-handshake protocol often causes the entire verification process to fail. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[5] Because the templates encode protocol-correct coding conventions, HAVEN's approach eliminates SystemVerilog syntax errors when using LLMs to generate UVM components, achieving 100% compilation success across 19 open-source IP designs spanning Direct, Wishbone, and AXI4-Lite. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[6] HAVEN's DSL defines step types including register writes, polling loops, value sweeps, and BFM actions, with a rule-based CodeGen that translates them into protocol-correct UVM sequence code so that bus-handshake timing is preserved in stimuli as well as in components. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs
[7] HAVEN achieves 90.6% average code coverage and 87.9% average functional coverage on the 19-IP benchmark, with the full pipeline averaging 6 LLM calls, 68k tokens, and $0.38 per design. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs