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).
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.
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
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.
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.
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.
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.