Faster interfaces using transactors
Taking a look at the top-level ports of a typical DUT, in many cases these will be standard peripheral or bus interfaces (such as USB, SATA, APB etc.); the behaviour of each is well understood. We can use this known behaviour to agree short cuts in the communication between simulator and hardware. For example, instead of relying on the simulator to drive every signal change for the writing of a data value over a standard port, we place some extra hardware alongside the DUT in the FPGA(s) which makes those changes for us locally. This is shown in Figure 3 as a BFM, or Bus Functional Model.
A single command or function call on the simulator side could then initiate all the necessary changes on the hardware side. The mechanism by which this all happens is called a transactor, and in Figure 3 this comprises the BFM interface on the simulator side, a transaction layer and the BFM in the FPGA hardware.
Figure 3. Partitioning using a transactor
Not only does the transactor simplify the communication, it also allows the hardware to run faster because it is not reliant on slavishly following signal-by-signal events in the simulator. If all the interfaces between the simulator and the DUT employ the relevant transactor, then we can achieve greater acceleration overall.
UVM already employs transactional level communications, but how do we convert our simulator-only UVM test environment to use transactors and FPGA-based hardware?