Recently a customer sought a help on how does the UVM’s built-in scoreboard mechanism works, specifically in_order and algorithmic comparators. While he was able to use them well in his design, it when things fail – i.e. he potentially found a design bug he needed additional assistance in debug. By default the UVM framework provides compare() routine for transaction/uvm_sequence_item. However unlike its predecessor HVLs such as the “E” language (IEEE 1647) or the OpenVera, System Verilog does not have the compare routine built-in to the language itself (for classes). Hence UVM adds it via base class and more. So when we have a transaction model such as:
Now by virtue of inheritance, a handy method my_xactn::compare is available. So one can use it to compare 2 objects of this type as shown below:
Note: in the above code snippet the return value of compare is unused, in actual code of-course you should assert it/throw an `uvm_error etc.
Now, when we simulate this with Aldec’s Riviera-PRO here is what we see:
But now the user asked 2 good questions:
- How does it know what to compare?
- Why is printing only 1 mismatch and not all?
The answer to the first question above is the `uvm_field_int macro. In the transaction model one should add:
The UVM_ALL_ON flag in the macro instructs the code to consider each field for all built-in routines/methods like copy/clone/compare etc. We also suggest adding the post_randomize for ease of debug.
Now moving onto the 2nd question that the user asked: “Why does it print only 1 mismatch”?” – the built-in uvm_comparer has a field show_max that controls how many mismatches to show/display and its default value is 1. One could change it and set it to its maximum using SystemVerilog’s bit-fill operator ‘1. Now when we pass the modified comparator object to the compare() routine we will see al mismatches:
Sample output from Riviera-PRO is below:
Hope you find this hidden-gem nside uvm_comparator useful in your debug cycles. Have fund and contact us via email@example.com in case you’ve a tough debug problem to crack.