Hi,
you raised some interesting question.
First of all, even for verification you need to write a testbench.
For the average designer a Testbench generally is just a stimuli generator for simulation.
Depending on the skills there may be some automatic result checking implemented, otherwise one will look at waveforms to decide wether everything is going well. The last part is good for debugging, when you know that there arte errors, but very unreliable to confirm the correct behavior of the circuit.
Also, ordinary testbenches use "Directed Testing".
That means, the testbench contains just some selected stimuli (and checks) for expected behavior.
Verification goes beyond this.
So what's the goal of verification?
Basically, to ensure that the circuit works correct under all conditions according to the specification.
This is a very big claim, so the effort to fulfil it is also increasing.
So what need to be done?
- A higher number of testvectors is needed
- The power of checking statements must be increased
- The tools have to collect statistical data beyond the pure waveforms
- (and several things more, that may be added later)
Also the methods of testing needs some change.
You may already use Code Coverage. A helpful methiod to ensure that every line of code has been hit during your simulation. A nice begining, but there's some big problem.
e.g.
if cond_A or cond_B then
do this
else
do that
end if
While Code Coverage may hit al these lines, it is not possible to say, wether condition A or B were used.
It may be that one of these conditions never appeared or even worse at some wrong time, yet untested.
So, the verification tool must be able to take track of this as well. This is when you start talking about Functional Coverage (Or Functional Verification).
While e.g. ModelSim is not capable of this, there's an advanced version called Questa(Sim) for this.
Guess what? It costs a lot more and there's no student version available at this time.
What else? Now, I talked about Directed Testing and the need to increase the number of test vectors.
This method is not helpful for that approach. We're not tolking about some hundred but millions of test vectors.
Creating them for Directed Testing will be a pain and taking forever.
So what can be done? Well, using some algorithm for creating test vectors seems a good idea. But most algorithms always create the same sequence of tests. This way we can not ensure that the circuit works under all (and that includes unpredicted ) cicumstances. But there's one exception: Random Number Algorithms.
There's just one disadvantage. Even after a gazillion of tests vectors there may not once be a sequence that causes the circuit to do something meaningful, as we know it from directed tests. This means that some mechanism for controlling the random number generation is needed.
In the end this is known as CRT (Constrained-Random Testing).
With CRT the verification engineer is able to create masses of testvectors including unexpected combinations, while still being able to direct the testing according to simulation results even during runtime.
e.g.
If after some testing time your stimuli generator has hit the reset button for the thousands time you can be quite sure now that the reset works properly. So when some limit of tests is reached the random function for the reset input can be disabled.
Now, we have lots of stimuli and probably even more results coming out of the circuit.
How to check this for correctness. The VHDL assert surely can't cope with this.
But you may have heared of Assertion Based Verification (ABV). So what's the difference?
For ABV a much more powerful syntax for assertions has been developed.
One of the early results of this is PSL (Property Specification Language).
With this kind of assertions even complex interleaved signal sequences can be described in just a few lines of code.
(However, the simulation tool must be able to do the checks for these assertions.)
Doing the same with ordinary languages like verilog, VHDL or even C would cause very big coding effort for the verification engineer.
While PSL is available in different language flavors and runs with some special licenses of Modelsim, it still is quite clumsy to handle.
Now here comes Systemverilog into play. PSL like assertions have been polished up and properly implemented ito the syntax. As well as Constrained Random Methods and even Object Oriented Programming stuff. (The only annoying thing might be the remaining corpus of verilog underneath it all. ;-) )
So now we went all the way from CRT, and ABV to Systemverilog.
But what is this OVM/UVM stuff?
As said earlyer, the testbenches for verification are more demanding and therefore bigger than the average Testbench for directed testing. While the language concept of System verilog helps to keep the programming comfortable, using actual programming Methods like classes etc. this is still not enough. Systemverilog is a monster of a language. Try to find a book about it. There is none that covers it all. Some deal with the System Verilog Assertions (SVA) only, some deal with the OOP stuff and basic language concepts and so on.
So if verification engineers all over the world would come up with their own style of testbench approaches this would create a mess and lots of people would badly reinvent other peoples wheels.
That's why the simulation tool designers created soem standards for verification testbenches like VMM, AVM, OVM and the latest revision of it all: UVM (Which is very much alike to OVM).
These Methods describe how to set up a testbench and provide the test engineer with predefined Classes and Assertion Based checkers for standard protocolls etc..
Learning Systemverilog takes some time, and learning the Methodologies takes even more time. Still this is faster than inventing a methodology of your own.
And at last the good news for VHDL users: Systemverilog can instantiate VHDL designs.
To learn more about verification go to
http://verificationacademy.com/
They have lots of great videos that explains all of the above in detail and much better than I could in this brief form.
Have a nice simulation
Eilert
