what are some of the limitations of UVM. I want to ask this as I got familiar with E-UVM which is called Embedded-UVM which says UVM cannot be used to make multicore testbenches and therefore not used to make H/W tests which are used in emulation.
2)If we get to compare both what will you say are the advantages and disadvantages of both?.
3)If We consider UVM for emulation what are the basic Hardware/software requirements necessary (I.e whether EDA’s simulator is multicore enabled , How Testbench is layered over when run multithread (single but shared RAM etc).
I have trouble understanding role of H/w specific Tests over FPGA’s .Does this means ,Once
we dump our DUT-HDL design on the FPGA . its performance is monitored by different UVM- tests and just like the design we can also dump testcases on it ? (I want a basic knowledge to get started with UVM in emulation )
I happen to know UVM cannot simulate the testbench on separate threads running parallel to design simulation. Thread refers to each thread of a multicore processor.I also came to know SV does not offer behavioral parallelism.
Due to the nature of hardware design, a typical UVM testbench will create a large number of dynamic parallel processes. Most of these processes are very small in nature, and attempting to create a new CPU thread for each process and synchronize these threads would create so much overhead that it isn’t worth it. This is why the typical UVM/SV simulator is not multi-threaded.
There are ways to simulate RTL using multiple threads, but since RTL is static in nature, it is easier to control the number of parallel threads.
Okay I get it . Do you see any upside in creating multicore Testbenches ? I have read somewhere that Parallel testbenches are faster and the “overhead” as you said , which I think refers to "small processes at each thread " being dereferenced and garbage collected after execution is taken care of.
Because there is a way to change your singlecore Testbench to Multicore Testbench when your native HVL supports some additional constructs .
In reply to cgales:
I happen to know UVM cannot simulate the testbench on separate threads running parallel to design simulation. Thread refers to each thread of a multicore processor.I also came to know SV does not offer behavioral parallelism.
What exactly stops me from writing verification environment which will have modification in driver and monitor to store transactions into file (driver) and read them from the file (monitor) and second one which will read stored transaction (and sent them to DUT) and write the outputs from the DUT? Then I could run two instances of the simulator.
I am not sure why I would want to do it this way, because I have yet to see reasonable UVM testbench that would be bottleneck in comparison to the design simulation but it should be possible. Please keep in mind, that if you have predictor that take sooo much time, you can go for the faster implementation of the function outside SV environment and just call it from SV. That way you have GPU acceleration, cloud or whatever is needed for your super computation intensive function.