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:

SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16.

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.