UVM vs COCO TB for Verification

I have got these questions from customers and here’s my findings (from a year ago):

  1. Debug challenge: You will debug RTL in one environment and the testbench parts in another environment. You will reside to print statements and gdb for python. This means that building and debugging testbench components will be very slow. And many times you are trying to figure out if the problem is in RTL or in the testbench.

  2. Coverage handling will be done in two places, code coverage in the simulator. Functional coverage will be handled inside python. Which means that verification management (coverage driven verification) will be … complicated.

  3. Availability of commercial VIPs, there is none as far as I understand.

  4. PERFORMANCE. I did a small test on the tinyalu example and applied 120 000 transactions on both a UVM testbench and the cocotb tb and even on this small example, Cocotb was 2x Slower.

The main reason for this is that for every clock cycle, communication is done between python and questasim through FLI/PLI which means that a lot of time is spent on this:

It also means that the performance will probably be exponentially slower the bigger your design and testbenches are.

3 Likes