I want to know your opinion about using python to fully replace UVM.
There is kind of ready flow based on pyuvm,cocotb and pyconstraints. Which fully replace the UVM.
No need to write UVM code, all these python packages will do it.
I am very new in that flow. Just doing 1st steps.
Can anyone please do some experience sharing. Mostly I want to know
is this flow scalable for big designs
Is it easy to debug complex DUT bugs using this flow
Has anyone experience working with the flow to verify complex protocols such as PCIe
I wrote pyuvm as a Python implementation of the UVM. So the UVM remains with all its sequences, tlm_fifos, ports, exports, etc. I simplified where I could to take advantage of the lack of strong typing in Python.
So its not a replacement for UVM, just another approach.
That said I can’t definitively answer your questions because its so new. That said here are my answers.
Can anyone please do some experience sharing. Mostly I want to know
is this flow scalable for big designs I see no reason that it would not be. One would compile the RTL once and then use the Python to create stimulus and check results. I suspect most of the time in a large design would be spent in the RTL simulation, but I haven’t tested that.
Is it easy to debug complex DUT bugs using this flow This is more a matter of using a tool such as Visualizer that captures all the signal
behavior in a simulation and lets you walk back through it like using a DVR.
Has anyone experience working with the flow to verify complex protocols such as PCIe Nope.I released it three weeks ago
Why vendors do not support this flow? Why do you say this? It works with all simulators.
What are drawbacks of this flow? I don’t understand how to link the testbench into a Python debugger. So right now the drawback is in debugging the testbench
Finding a solution when there are many constraints and many random variables is a hard problem. Finding out that there are no solutions is much harder, and letting you know which constraints conflict preventing a solution harder still. Tools supporting languages with constraints built into them spend substantial effort optimizing performance and improving debuggability. This is not to say that pyconstraints is inappropriate for all verification tasks, or that it could not be improved to handle more. But I think that engineering effort is a long way off.
And more on overall debuggability
The introduction of SystemVerilog came at a point when Verilog and VHDL were no longer adequate for verification. Many other languages evolved to bridge this gap in verification capability (Vera, Specman e, in-house tools) to act as the testbench. But interaction with the internals of the DUT and lack of combining waveforms of the design and testbench during the progress of simulation became a drawback.
The goal behind SystemVerilog was merging the capabilities of all these different tools into a single language so that it could be executed under a single simulation kernel. This also unifies the event scheduling semantics and expression evaluation rules. The also give you access to a single debugger where you can put design and testbench singles in a waveform, set breakpoints, and navigate the entire hierarchy. Since many tools have also integrated the simulation kernels of VHDL and SyetmeC, you get some of the same debugging benefits even though they use different languages. This was possible because the languages are based on the same discrete event simulation semantics. Integrating python would be a much more difficult task.