The market window of opportunity for electronic products is gradually shrinking. This directly affects the design cycle of SOCs going into these products. Aggressive schedules leave no margin of error. Since verification claims most part of the design schedule it becomes all the more important to improve efficiency and weed out redundancies wherever possible. Mini regression, ubiquitous to all ASIC projects is a subset of stable tests to ensure sanity when –
- RTL was fixed for a bug.
- TB was fixed for issues.
- Before main regression to confirm that the database is clean.
- Precedes check-in (configuration management).
Considering the above list, mini regression assumes an important role throughout the project. If not defined logically, this can invite inefficiencies in the process and affect schedule. Imagine if the tests in mini regression don’t exercise the common functionality of the design that gets affected due to a bug fix. The next regression run is a complete waste of resources - both simulation cycles and debugging efforts which otherwise could have been avoided.
So, how to define a mini regression?
Coverage driven verification has been religiously adopted by all new project starts. An essential part of this approach is to run coverage frequently as compared to legacy approach of directed scenario based verification where coverage was run in the later part of the projects. If you are working on a legacy test suite then you already have enough tests in place to run the coverage at the start itself. Verification tools have supported ‘coverage grading’ for a long time. Coverage grading helps you identify the tests contributing maximum to the coverage goals. If you are working at the block/IP level the focus of the coverage would be on the functionality of the block and once you move to subsystem or SOC level, the integration verification becomes the focus. To analyze the coverage grading, it is important to make sure that the coverage goals are in line with the scope of verification. With this list in hand, engineers can easily identify the list of tests that have the maximum reach to the functionality of the design thereby improving the effectiveness of mini regression.
But, hold on; is this criterion good enough to select the tests? Remember, mini regression is used quite frequently. Another important aspect to be considered is the total turn-around time for mini regression. A test running for a long time can contribute maximum to coverage. However this test may not be the best choice for the mini regression as the total time to execute this test will be quite long and waste resources otherwise. So now we have two parameters, ‘coverage grading’ and ‘simulation time grading’ and we need to identify a compromise between the two to define a mini regression suite. Finally, since the main regression keeps on growing as the verification progresses, it is important to update the mini regression test list periodically.
With design complexity increasing, verification is becoming even more complex. Efficiency is vital to accomplish the given task in short time. A well planned mini regression is one of the keys to improve that efficiency.