We are trying to move from a homegrown testbench infrastructure to a UVM based testbench. But I find it hard to map our datapath stimulus/checking onto the UVM structure with sequences, monitors, etc…
I actually have many questions/ideas/proposals/etc…, but maybe a few simple questions could start the discussion (if any).
Q1: are there actually any UVM examples with datapath centric designs? So far I only found the Bi-Quad example: https://verificationacademy.com/cookbook/coverage/datapath_example. This example mainly focusses on coverage, but it is still useful. More elaborate examples would be useful as well.
Q2: in the example mentioned above the driver is actually creating the stimulus waveform. In the example, arrival of a sequence item will cause the driver to create a complex waveform, sample by sample/clock by clock. I guess it could be extended by letting the sequence item contain parameters for the waveform (e.g. frequency). Although this works, it feels kind of like that intelligence should not belong in the driver? What do you guys think? Do you think this should be done in the driver?
The driver is where the intelligence should be located. The driver is responsible for taking the sequence_item and generating the appropriate signals per the interface specification. Essentially the driver is the BFM for your interface, with the data and other appropriate parameters coming from the sequence_item.
The monitor is similar except that it does the reverse, converting the signals into a sequence_item.
the data and other appropriate parameters coming from the sequence_item
.
When I wrote stimulus waveform I meant for example:
a sine wave
a triangular wave
a sum of 3 sine waves
etc…
Is this what you mean by data?
It could be that these signals are sent into the DUT over AXI, OCP, etc…
In the example there is a task in the driver that generates a sin wave.
But in our verification we will need a multitude of waveforms to be generated.
The creation of a particular waveform can sometimes be the essence of a test.
Should the driver really care/know if it is sending a sine wave or a triangular wave?
Intuitively I would have thought the driver would not have to care what kind of signal (waveform/data) it is sending, but it should just wiggle the pins according to the DUT interface/protocol to transmit the signal (waveform/data) it received (e.g. via a sequence_item)
The driver is inteface specific, in that it knows how to transmit data using the correct interface protocol (i.e. AXI, OCP, etc.) to the DUT. The driver shouldn’t care about what the data is. It’s job is to convert the data into the appropriate pin wiggles.
You should have sequences that create the appropriate stimulus (i.e. the sine wave, triangular wave, etc.) and generate the appropriate sequence_item(s) that encapsulate the data values so that they can be clocked onto the bus by the driver.