Simple UVM testbench through a DFF or a buffer

Hi,

I’m trying to learn the basic framework for the simplest UVM testbench for a DUT like a DFF or a buffer.

Where to find this kind of simple example ?

DUT = DFF or a buffer

The Data_Input bus should equal to the Data_Output bus with parameter WIDTH.
In the case of a DFF one cycle later or for a buffer (make it clocked testbench and strobe output one clock later).

Thanks,

David

Hi David,
If you are looking for dut you can easily find in opencores.com
Thanks

In reply to shobhana.swarnkar18:

Hi,

I’m not looking for the DUT.
I can code a DFF myself.

I’m looking for a complete UVM testbench that can exercise an n-bit wide DFF
with randomized input data and compare the expected data (Q bus output) one cycle later.

This will help me understand UVM better with a simple UVM testbench.

Thanks,

David

The link below provides a model written by Srini; It has one bug - for you to debug :-)
Also monitor & SBRD is empty. Checking is done by SVA.
http://SystemVerilog.us/fv/vw_dff.tgz

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

In reply to davidct:
You can use the following one as reference. Its DFF verification env.
You may suggest some enhancement, I did not put into this one.

In reply to davidct:

A flip-flop is much too simple to verify using UVM and IMO you will barely learn anything useful. There’s a reason why the “router” is a common example. It’s because it contains many of the “problems” UVM was designed to solve: multiple interface protocols, scoreboarding between multiple interfaces, configurability, composition of multiple verification components etc.

In reply to Tudor Timi:

Thanks everyone for your feedback.

I’ve been going through the basic UVM videos
which have been very helpful.
Although, I wish they had a link to download the code
that was shown in the videos.

As for DFF being too basic, I agree it is too simple an example DUT.
However, since I’m getting acquainted with the various concepts of UVM
I needed to know the testbench environment and how things connect up
and communicate with each other. Once I get over this hurdle, I
will move on to the next step.

Next step is a slightly more complex DUT, like a single AXI channel
using a register slice as the DUT. At least, it will get me to
handling handshakes and how things are modified in the testbench
to handle this.

m_payload_in (payload generated by UVM tb to DUT)
m_valid_in (valid generated by UVM tb to DUT)
m_ready_out (ready generated by DUT to accept the valid payload)

s_payload_out (payload output by DUT to UVM tb)
s_valid_out (valid indicator by DUT to UVM tb to transfer this data)
s_ready_in (ready generated by UVM tb to accept the data and compare against the
payload)

The idea of a router where many channels and same or different protocols are handled
simultaneously is a good idea and if you have the link to the uvm
code for this router including the DUT I would appreciate it.

In reply to davidct:

The UVM Cookbook has lots of small examples. The largest have Wishbone and SPI interfaces.

https://verificationacademy.com/cookbook/cookbook-code-examples#UVM_Examples:#UVM_Examples:#UVM_Examples:

In reply to dave_59:

Thanks for the link.
I think a natural progression from simple to complex DUT
would help me understand UVM and modifications in testbenches
to support more complex DUTs.

DFF DUT
AXI REGISTER SLICE DUT
SPI DUT
ROUTER DUT