Push the UVM start button then hit the accelerator, Part 2

December 08, 2015 // By Doug Amos, FPGA Consultant
So, you’re STILL not using UVM? This article won’t help you learn any of the features of UVM, but it will point you to how you might speed up your UVM learning, your UVM adoption and even your UVM execution throughput.

Editor's note; This commences part 2 of the article, of which part 1 appears on the EDN-Europe website, here. For convenience, this link accesses a single pdf file of the complete article.

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?