Tuesday, November 20, 2012

Top 12 Questions on Testbench

Verification Engineer can ask these general questions about the Verification Infrastructure or popularly known as Test-bench either at the beginning of the project or at the end of the project as check.

1. Is Verification infrastructure are nicely broken down into logical, appropriate Test-bench components to enable parallel development of those components ?

2. Have I understood the Requirement Specifications or Design specifications to the extent to by which I can handle ambiguity and take independent decisions during debug ?

3. Do I have the reasonable amount of practical knowledge of the off-the-shelf VIPs, if any used ?

4. If the Test-bench is inherited from the previous project, Is the due-diligence done on the various aspects of the Test-bench considering the current design? Have I identified the list of modifications to existing Test-bench?

5. Do I have the list of sanity test-cases which target the minimal set of design functionality?

6. Do I have a plan where I execute test-cases (or verification plan) systematically in the order of increasing complexity?

7. What is the strategy to connect the various Test-bench components and their unit of interaction. Has this been figured out?

8. Is the running of Test-cases 'push button' or single command-line?

9. Is the Verification infrastructure good enough to handle the Corner cases ? Consider interesting and overlapping of design features in a single scenario.

10. Have I investigated the possibility of replacing the Test-bench checkers with assertions in RTL?

11. Is my test-bench robust enough, means once all the regression PASSES, suppose a fault is introduced into the RTL, can the test-bench really catch this ?

12. What is the strategy on Functional Coverage ? It depends on the kind of design under test(DUT).         
              * If the design has predominantly 'data-path' kind of functionality, its generally sufficient just to cover the stimulus (means various fields of generated items)
              * If the design has predominantly 'control-path' kind of functionality, its required to cover for both stimulus and manifestation in an intelligent way

No comments: