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