Full chip verification methodologies

UVM
1

Hi,
I have done unit level verification so far. However, I need to do create top level verification environment for full chip. I see that the chip level verification is very different from the unit level, which requires different approach. Different people implement stuff differently with a combination of C/C++ and UVM based stimulus generation etc. I wonder if there is documentation or recommendation of how to approach. Is there an example in verification academy? Is it possible to build a full chip environment with just UVM itself? for example my top level would be a GPU/CPU.

Any help appreciated.

Thanks,
Madhu

2

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.

3

In reply to erik.k.jessen@raytheon.com:
Hi Erik,

I understand question is such that it doesn’t or cannot have a “one answer” that fits all. Thank you for your reply. What I am not sure is, what is the stimulus that the software guys should be giving? whether the stimulus is on-the-fly or offline generated etc. What things need to consider, what should be the approach. Where can I get the “testbench generator?” Does it need license? Is this generation applicable for top level as well?

Thanks,
Madhu

4

In reply to mseyunni:

There is not only ‘the answer’ because it depends on your environment and the rules and guidelines in your Company. And there are a lot of not answered questions.

  • What is your C/C++ Code for?
  • What is your current verification methodology?
  • What is the size/complexity of your design?
  • Do you have additional aspects to consider, like is your design algorithmic based?
  • How many persons are involved in verification and design?
  • etc.

What I recommend is also to use a UVM Framework Generator. Instead of the UVMF from Mentor I recommend the EasierUVM Framework Generator from Doulos. It is free-of-charge. Follow this link:
https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm_generator/

5

In reply to chr_sue:

In reply to mseyunni:
There is not only ‘the answer’ because it depends on your environment and the rules and guidelines in your Company. And there are a lot of not answered questions.

  • What is your C/C++ Code for?

  • What is your current verification methodology?

  • What is the size/complexity of your design?

  • Do you have additional aspects to consider, like is your design algorithmic based?

  • How many persons are involved in verification and design?

  • etc.
    What I recommend is also to use a UVM Framework Generator. Instead of the UVMF from Mentor I recommend the EasierUVM Framework Generator from Doulos. It is free-of-charge. Follow this link:
    https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm_generator/

  • We have C/C++ reference model to compare against the RTL

  • UVM in general, but top level has a hybrid of C (and few other languages, scripts) and UVM.

  • It is of size GPU

  • Yes, the design is algorithmic in some parts.

  • It is incremental design, we have about 2 designers and 2 verification engineers. I am trying to explore what would be the best possible method of verifying this complex design at top level. We have some unit level tb’s in UVM though.

Thanks,
Madhu

6

In reply to mseyunni:

Using a C/C++ refernce model is very easy, because you can connect it through the DPI directly to your UVM testbench.
If you have Matlab models you cann connect them also directly to a UVM testbench.
Regarding all the other stuff you should try to remove it completely because the pattern Generation, based on sequences and sequence items might completely differ from the current Approach.
If you are using a UVM Framework Generator you will save a huge amount of time. My estimates are between 6 and 8 man weeks.

7

In reply to chr_sue:

I completely agree on using Framework generator; it’ll save a tremendous amount of work.
And often regenerating a testbench that’s standard is, in the long run, more productive than trying to integrate different architectural approaches in the testbench.

Note: if you already have block-level UVM testbenches, you can vertically reuse them in your top-level testbench. But of course - it’ll be a lot easier if both block and top-level testbenches are built using the same framework.

8

In reply to erik.k.jessen@raytheon.com:

This is one of the benefits UVM is providing to you: reuse. If you have a block-Level testbench you can reuse this witout making any modifications. Using the same Framework is absolutely necessary. This is on additional benefit of the Framework Generators. BTW EasierUVM provides to you also a set of useful coding Guidelines.

9

Thank you all for the comments. I still have these questions unanswered though.

  • What is the stimulus that the software guys should be giving?
  • Can a full-chip verification environment be built from purely UVM, without the use of any other languages like C/C++. Any performance issues?
  • Whether the stimulus is on-the-fly or offline generated etc
  • Should the checking be on-the-fly or post processing.
  • What things need to consider, what should be the approach
10

In reply to mseyunni:
A few Answers:

  • You can give the Software guys selected stimulus from your Simulation runs (what is relevant);
  • Yes it can be a pure UVM Environment. This makes your life quite easy. But you should consider if you can reuse something from your current approach.
  • Pattern are generated always on the fly (online). Offline is a limited appproach.
  • Checking can be done only on the fly.
    You should consider if you have Registers in your design.