In reply to mseyunni:
Hi Madhu,
People solve the testbench problem in all kinds of ways; a lot of their choices depend on their level of knowledge and big-picture requirements.
So it’s hard for me to give you a “works for everybody” answer.
Here’s what I find works best:
If you have access to Mentor Questasim, use the UVMF packages and testbench generator scripts
- UVMF implements a set of standard classes and practices, that you’d wind up
creating yourself eventually - might as well use an existing one. - the testbench generator scripts save an enormous amount of effort because they generate
lots and lots of boilerplate for you.
If you have registers, then use any tool you can find that’ll generate the C header files and RTL code and UVM register package. Every vendor has one - Mentor’s is registerassistant. Agnisys sells one.
Then use the UVM builtin register-test sequences to test that the RTL works the way you claimed it did; since you used the same input file to generate the C headers and documentation, you’ll now know that your docs and C headers are correct.
Have the C programmers write their bring up C code and do cosimulation against the hardware. They’re going to wind up writing that bringup code; might as well flush out HW/SW issues early rather than later. And it saves the HW verification engineers from having to write the equivalent in SystemVerilog sequences. You’ll link C to your simulation using DPI.
Use the RAL to capture register traffic, so you can prove you’ve actually tested all the register values per your requirements. Use your favorite requirements-tracing tool to trace from the requirements to the covergroups in the register package.
For stimulus generation: something a lot of people forget about is error injection/detection: does the user need to be able to corrupt stimulus, either in terms of timing or in terms of data-values? If so, your transactions, BFMs, etc. will all have to support that. And then of course the testbench has to be able to detect the proper error-response to stimulus that has errors.
I hope that helps! If I did one thing, though, it’d be to use a testbench generator - it’ll save you a tremendous amount of pain to get your first testbench running. Then you can add things to a working design, instead of trying to figure out why you have a cryptic UVM_FATAL error at time0.