Overview
The Control Command Bus is the command interface used by a constrained random test (CRT) bench to exercise the control path of a design under test (DUT). In the described architecture, the bus carries control instructions used to initialize a selected DUT functional mode, trigger the DUT operation, and later read internal status or result registers to determine whether the test passed or failed.
The bus is treated as a system-level resource because it may be shared with other integrated circuits. As a result, verification is not limited to checking whether the DUT follows the bus protocol for commands addressed to it; it also checks whether the DUT ignores commands directed to other address spaces.
Bus Signals and Drivers
The evidence describes the Control Command Bus as involving an address bus, a data bus, and a read/write control signal:
- The Control Bus Master BFM Module drives the address bus and the read/write control signal.
- During a write operation, the Control Bus Master BFM also drives the data bus.
- During a read operation, the data bus is driven by the DUT or by the Control Bus Slave BFM Module, and the value is returned to the master BFM.
A typical write instruction includes an address value, a data value, and a read/write control value. For example, the master BFM may drive address 104, drive data value 1234, and assert the read/write control to indicate a write operation.
Role in the Instruction Abstraction Layer
The Instruction Abstraction Layer (IAL) abstracts lower-level control instructions into higher-level macro instructions (MIs) or atomic instructions (AIs). The IAL sends instructions that eventually become low-level register read/write commands understood by the Control Bus Master BFM.
In one embodiment, the IAL includes instruction streamers, a priority scheduler, and an instruction translator. Instruction streamers independently generate instruction streams; the priority scheduler selects an individual instruction according to a priority scheme; and the instruction translator converts the selected high-level instruction into one or more low-level commands for the Control Bus Master BFM.
The Register Abstraction Layer (RAL) may then execute the low-level register read/write commands. For writes, the RAL updates a mirror copy of the register value. For reads, the DUT or slave BFM supplies data to the master BFM, and the RAL compares the read value with the expected mirror value.
Typical Test-Case Activity Pattern
A test case generally produces a repeating busy / idle / busy pattern on the Control Command Bus:
- Setup busy period — commands configure the DUT for the functional mode under test.
- Idle period — the DUT performs the requested operation while the bus is not transferring commands to the DUT.
- Read-back busy period — commands read device status or result registers to verify success or failure.
The next test case typically follows the same pattern: a setup busy interval, an idle interval, and a read-back busy interval.
Noise Instruction Use During Idle Periods
The Noise Instruction Streamer uses idle Control Command Bus periods to simulate bus activity for another device sharing the same bus. It queues random noise commands whose addresses lie outside the DUT address space. During an idle period, the priority scheduler transfers queued noise commands for execution.
This mode tests the DUT's sensitivity to commands issued to a different address space. Such commands should be ignored by the DUT. The noise instruction streamer may also be programmed to queue noise instructions at a specified interval, such as every 20 ms, so that they are applied at random times during idle Control Command Bus periods.
Verification Significance
The Control Command Bus is central to constrained random verification of a control-oriented DUT because it is the medium through which the test bench:
- applies ordered and randomized control sequences;
- programs internal control registers for a selected functional mode;
- injects interrupt-service or noise instruction sequences; and
- reads internal registers or status bits to determine test completion and pass/fail status.
The shared-bus assumption makes out-of-address-space traffic an important verification stimulus: commands intended for another integrated circuit should not perturb the DUT.