Tuesday, November 27, 2012

UVM Questions -1

Q. Why the heck there are so many UVM Run time phases ? I want to have freedom to write the test in my own way without the hassle of these phases. Why can't I?

A: No, that's UVM for you. UVM expects the Verification Engineer to be much more organised in the way tests are written. Imagine verification team of five to six verification engineers, all writing tests in their own way, they might be able to verify the DUT to good extent, but there won't be any standard *flow* in those tests and it will be highly time consuming for someone to understand/modify/maintain the tests written by someone else in the team. That's why UVM is prescribing the following predefined RUN phases which suites most of the verification environments:-


From Accellera's Universal Verification Methodology (UVM) 1.1 Class Reference:-

UVM Run-Time Phases  
The run-time schedule is the pre-defined phase
schedule which runs concurrently to the

uvm_run_phase global run phase.

uvm_pre_reset_phase Before reset is asserted.

uvm_reset_phase Reset is asserted.

uvm_post_reset_phase After reset is de-asserted.

uvm_pre_configure_phase Before the DUT is configured by the SW.

uvm_configure_phase The SW configures the DUT.

uvm_post_configure_phase After the SW has configured the DUT.

uvm_pre_main_phase Before the primary test stimulus starts.

uvm_main_phase Primary test stimulus.

uvm_post_main_phase After enough of the primary test stimulus.

uvm_pre_shutdown_phase Before things settle down.

uvm_shutdown_phase Letting things settle down.

uvm_post_shutdown_phase After things have settled down.

This way , irrespective who writes the test, one has to organise his tests using these phases. Effectively UVM enforces this 'test writing descipline' for the common benefit of the team of verification engineers which is also productive indeed.

Of course, one has to understand that you are not limited to/by above mentioned phases. One can always come up with new run_phase and add it this phase sequence for which UVM already has the support.

Bottomline is UVM is not curtailing the 'creative thinking' in writing testcases by verification engineer, rather its demanding you to be 'organised', that's it.

 

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