Skip to content
STIMSMITH

Control Bus Master Bus Functional Model (BFM)

Concept WIKI v1 · 7/9/2026

In a constrained random test bench for control-oriented designs, the Control Bus Master BFM (Bus Functional Model) is the module that physically drives the control command bus to apply stimuli to the design under test (DUT) and to capture responses from it. It receives high-level commands from an instruction translator (typically through a Register Abstraction Layer), drives the address bus, data bus, and read/write control signal, and participates in both write operations (driving address, data, and control) and read operations (capturing data driven by the DUT or a slave BFM).

Control Bus Master Bus Functional Model (BFM)

Role in the Test Bench

In the constrained random test (CRT) test bench architecture described in U.S. patent application 20090164861, the test bench is composed of a test case generator, a test manager, a control bus master BFM module, and a control bus slave BFM module. The control bus master BFM module is the component that actually drives the control command bus to stimulate the design under test (DUT) and that captures the DUT's responses off the bus.

  • During a register write operation, the master BFM drives the address bus, the data bus, and the read/write control signal toward the DUT and the slave BFM.
  • During a register read operation, the master BFM captures the data bus values driven by the DUT (or by the slave BFM) and forwards them for comparison.

The control command bus 112 typically comprises an address bus, a data bus, and a read/write control signal. The master BFM is responsible for driving the address bus and the read/write control signal in general, while the data bus is driven by the master BFM during writes and by the slave BFM (or DUT) during reads.

How Commands Reach the Master BFM

Test cases generated by the test case generator are scheduled by the test manager, which selects instruction streamers (program, noise, interrupt service, custom). A priority scheduler selects an individual instruction from these streamers and forwards it to an instruction translator. The instruction translator converts the selected macro instruction into one or more low-level commands that the control bus master BFM module understands, which the master BFM then executes on the control command bus.

A typical instruction issued to the master BFM carries:

  • An address value,
  • A data value, and
  • A read/write control signal value.

For example, the master BFM may be instructed to write a data value of 1234 to a register at address location 104; the master BFM then drives the address bus with 104, drives the data bus with 1234, and asserts the read/write control to indicate a write operation.

Interaction with the Instruction Abstraction Layer and Register Abstraction Layer

The test bench exposes an Instruction Abstraction Layer (IAL) that allows test cases to be written in terms of macro instructions rather than low-level HDL/RTL constructs. The IAL typically sends one instruction at a time to the control bus master BFM module.

The instruction translator translates high-level atomic instructions into low-level register read/write commands executed by the Register Abstraction Layer (RAL) — which may be implemented as a SystemVerilog application package that automates a high-level abstraction of memory-mapped registers/memories and maintains a mirror copy of the DUT's register values.

  • On a write-type atomic instruction, the RAL's generic write function is invoked; the register write is performed on the DUT via the master BFM, and the corresponding register in the mirror is updated with the written data value.
  • On a read-type atomic instruction, the DUT (or slave BFM) supplies the data value to the master BFM; the RAL's generic read function is invoked to compare the captured value against the expected value stored in the mirror.

At the end of a simulation, if all expected values match the values read, the test bench indicates that the DUT passed the test case; otherwise, a DUT failure is reported.

Bus Activity Around the Master BFM

During a typical test case execution, the control command bus alternates between busy and idle periods:

  1. A busy period while commands are sent to the design to set up the functional mode of operation to be tested.
  2. An idle period while the design performs the specified operation.
  3. A second busy period while commands are issued to the design to read back the test results.

During the idle periods, the priority scheduler may issue any atomic instructions queued in the noise instruction streamer queue. Because the noise streamer queues noise instructions at random times, these atomic noise instructions can be applied on the control command bus — and hence through the master BFM — at random times. This mode is useful for simulating control command bus activity directed to another device sharing the control command bus, exercising the DUT's sensitivity to commands aimed at a different address space that should be ignored.

Why the Master BFM Matters

Verifying proper control-path operation in a control-oriented chip design requires checking that the design follows the proper bus protocol on the control command bus, including its behavior when the bus is shared with other integrated circuits. The control bus master BFM module is the test-bench element that translates the test bench's macro-level instructions into protocol-level activity on the address, data, and read/write control signals, making it the linchpin for system-level verification of the DUT's bus interface.

LINKED ENTITIES

3 links
Constrained Random Test (CRT) USES
Instruction Translator USES
Control Command Bus USES

CITATIONS

9 sources
9 citations
[1] The test bench includes a test case generator, a test manager, a control bus master BFM module, and a control bus slave BFM module. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[2] During a write operation the master BFM drives the address bus, data bus, and read/write control signal; during a read operation it captures data driven by the DUT or slave BFM. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[3] The control command bus 112 typically includes an address bus, a data bus, and a read/write control signal. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[4] Each instruction sent to the control bus master BFM may include an address value, a data value, and a read/write control signal value. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[5] The priority scheduler selects an individual instruction from the instruction streamers and sends it to the instruction translator, which translates it into low-level commands understood by the control bus master BFM module. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[6] The instruction translator translates high-level atomic instructions into low-level register read/write commands executed by the Register Abstraction Layer (RAL), which may be a SystemVerilog application package that maintains a mirror copy of the device's register values. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[7] The RAL's generic read/write functions are invoked to send register access instructions to the control bus master BFM module, updating the mirror on writes and comparing expected vs. read values on reads. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[8] During idle control command bus periods, the priority scheduler issues atomic noise instructions queued by the noise instruction streamer, applied on the bus to simulate activity from another device sharing the bus. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application
[9] The control command bus alternates between busy setup periods, idle periods while the DUT operates, and busy read-back periods during a typical test case. METHOD AND APPARATUS FOR A CONSTRAINED RANDOM TEST BENCH - Patent application