Bus-Handshake Timing

Concept

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.

First seen 7/12/2026

Last seen 7/12/2026

Evidence 3 chunks

Wiki v1

WIKI

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).

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

CITATIONS

7 sources

7 citations — click to expand

[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