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
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:
Post a Comment