UVM vs COCO TB for Verification

UVM
1

Hi All,

Which verification methodology is better coco tb or UVM, especially for a design containing some complex digital modules like FIR filters, ADC and analog modules?
Can anyone please throw some light on this? Also what are pros and cons of both coco tb and uvm?

Also how easy it is to integrate analog verification into UVM and coco tb?

Regards,
Abhinandan

2

I suppose you didn’t receive a response because the number of CocoTB users on this site is quite small, and the number of users who have a good grasp of both CocoTB and UVM is infinitesimal.

Also, you need to give us a clearer definition of what “better” means to you. Python is an excellent language for learning and experimentation, with a vast infrastructure supporting it compared to what’s available with UVM. However, when it comes to performance, Python is incredibly slow. This might not be a concern for you now, but it will become a significant issue in the future, making it difficult to address without starting over.

Is integrating a debug environment important to you? Do you need to see waveforms from your testbench and DUT together?

I could go on, but you can tell I’m pretty biased at this point. :slight_smile:

FYI, Accellera recently released the first version of UVM-MS at the beginning of this year.

3 Likes
3

Thanks for the response @dave_59 .

“Better” I meant in two ways:
One is the functional verification of a communication sub-system
Second, is if we want to verify the performance in terms of data rate.

So, keeping these two as criteria which is better?
Also, can we use both of them together? Or can we use one approach for functional and the other for performance?

Regards,
Abhinandan

4

Hi @dave_59 ,

Yes, integrating debug environment is important as I have verify functionally.

Regards,
Abhinandan

5

This link i 3 years old. Not much has changed.

https://www.reddit.com/r/FPGA/comments/v8fd63/cocotb_in_python_vs_uvm_in_systemverilog/

6

Thanks @dave_59

7

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:

image
image818Ă—481 90 KB

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

3 Likes
8

Thanks @mickedykare for the detailed reply. Its really helpful