TABLE OF CONTENTS When you think of randomizing the stimulus to a design, the first thing you may think of are the data fields. These are the easiest to create just call $random. The problem is that this approach has a very low payback in terms of bugs found: you only find data-path bugs, perhaps with bit-level mistakes. The test is still inherently directed. The challenging bugs are in the control logic. As a result, you need to randomize all decision points in your DUT. Everywhere control paths diverge, randomization increases the probability that you'll take a different path in each test case.
You need to think broadly about all design input such as the following.
Device configuration
Environment configuration
Primary input data
Encapsulated input data
Protocol exceptions
Delays
Transaction status
Errors and violations
What is the most common reason why bugs are missed during testing of the RTL design? Not enough different configurations have been tried! Most tests just use the design as it comes out of reset, or apply a fixed set of initialization vectors to put it into a known state. This is like testing a PC's operating system right after it has been installed, and without any applications; of course the performance is fine, and there are no crashes.
Over time, in a real world environment, the DUT's configuration becomes more and more random. For example, a Synopsys customer had to verify a time-division multiplexor switch that had 600 input...
