Let us first try to understand the concept of what is termed as "Constrained Random Verification".
As SoCs/ASICs became more and more complex, Traditional testbenches started failing the primary verification
objective of catching bugs. This was simply because, it was becoming impossible to simulate all the possible
scenarios using traditional test benches. The concept of constrained random verification then started gaining
traction. This concept is basically allow the user to generate random test vectors, which provided a way of
exercising the DUT with more combinations of inputs in less simulation time.
Consider a very simple example:
A DUT is designed to handle a Computer Key Board, which will detect a button press, and generate a N-Bit
code corresponding to the Key Press.
The traditional way to test is, to present all the possible key presses, and then check if the Key Board would
produce the expected Code.
However will the above technique test all the possible combinations of sequences of key presses?
The clear answer is NO.
Here is where the Concept of Constrained Random Verification comes in.
This concept will allow the user to generate Random key presses, in a Random Sequence. Of course, we are still
not testing all possible sequences, but it is giving us far more confidence, as we know that this way of generating
test vectors is testing a lot more than the traditional method. If we run 10000 Random sequences, and could not
find a bug, the chances are DUT is indeed bug free. On the other hand, using traditional methods, the test
coverage remains significantly low.
Here we have seen an example of just one Key Board. A complex SoC can have 100s of interfaces, each working in parallel.
Clearly a traditional testbench will spectacularly fail to address the Random-ness of the system, and any procedural
algorithm to generate test vectors would be clearly insufficient.
However, it is important to understand that the test vectors cannot be totally Random. Hence the term constrained
Random Verification. This will be more evident when a real-life example is considered.
An AHB protocol is a good example. The AHB protocol has following Burst Types:
The field name is called HBURST, which can take values from 0 to 7, and each value corresponds
to one of the above possibilities.
An AHB protocol compliant Verification IP written using SystemVerilog, would then be required to
produce the HBURST field, with a constraint that it can take only the above values, but the order in which
these are produced will be random.
For another example, consider the field AWBURST from AXI Protocol. It is 2 bits wide, and can take values
00,01,10. Value '11' is Reserved.
Now the constrained Random generation would then support generation of the 3 legal values in random fashion,
but it will never generate a value of '11' in the field AWBURST.
This is what is meant by Constrained Random. These are very 2 very small examples of Constrained Random
Generation. The real life is far more complex.