In Directed verification, the Verification Environment has mechanism to send the Stimulus to DUT and collect the responses and check the responses. The Stimulus is generated in Tests case. Directed testbenchs may also use a limited amount of randomization, often by creating random data values rather than simply filling in each data element with a predetermined value. Each test case verifies specific feature of the design. This becomes tedious when the design complexity increases. As circuit
complexity increases, it becomes more difficult to create patterns that fully exercise the design. Test case maintenance become harder and time consuming.
In Directed Verification, test writer has to list out each feature. Test writer can't think of all possible potential bug scenarios and there are chances that Bugs will escape. With these approaches, the bugs lurking in these corners hide until late in the development cycle, or aren't found at all until product is taped out.
Solution to the above problems is Constraint random verification. Using constraint random verification, the stimulus required to verify test features are generated automatically. Test writer specifies set of specification, and the TestBench automatically creates solution space and picks up scenarios from the solution space.
Constraint random verification also reduces manual effort and code for individual tests. As the scenarios are generated automatically by the TestBench, the number of test case files gets reduced. In Directed verification, some of the tests share similar logic, if the engineer has to change the logic which is common to certain group of tests, then he has to edit all the test case files and it is time consuming. But in Constraint random verification, the number of tests case files will be very less, so changes will be mostly in environment and minimal.
Directed verification with a fairly simple TestBench, verification engineers can start finding bugs in simulation almost immediately even before the TestBench is fully completed. With a constrained-random verification environment, there is an up-front cost that must be invested before the first test can be run. Constraint-based generators can be easily converted into checkers if required.
Generating fully randomly is meaningless as it may generate invalid scenarios and it may also regenerate the same scenario again and again wasting potential simulation time. A User must define data structures, which represent stimulus applied to the DUT input. Next, constraints must be defined to guide the random generator. Using constraint, the solution space is defined, and randomization picks up scenarios randomly from the solution space. Constraints act as knobs in the TestBench which control the generator's randomness.
The main disadvantage of constraint random verification is we never know how well the DUT is verified. If verification engineer can get the information about the logic in DUT which is not verified, he can further constraint the randomization or write directed testcases to exercise the unverified logic.