Mention of UVM run_phase in uvm_tests.rst is incorrect

[MikeOpenHWGroup]

Email from dave.rich@siemens.com:

I was reading the text on this page: https://github.com/openhwgroup/core-v-verif/blob/master/docs/VerifStrat/source/uvm_tests.rst

In the run phase the base test will assert the fetch_en input to the core which signals it to start running. The timing of this is randomized but keep in mind that it will always happen after reset is de-asserted (because resets are done in the reset phase, which always executes before the run phase).

This is not correct. The UVM’s run_phase starts at time 0 in parallel with the reset_phase. You use run_phase with components that do not need to be aware of other phases, or if your sequences are set up to be unaware of phases. (i.e. you would start a reset_sequence in the run_phase, followed by other sequences. Usually monitors are not aware of other phases.

But if you do choose to use the reset_phase, then you would use the main_phase instead of the run_phase.

See https://www.chipverify.com/uvm/uvm-phases

-Dave

[subbu009]

As Dave said, in UVM the run_phasestarts in parallel with other run time phases like reset_phaseand configure_phase. One of the base testcase here uses run_phasewhich only contains watchdog_timer(), which is essentially used to stop simulation if timeout is reached. So, according to this testcase it works fine even the other run time phases are used along with run_phase. But if some functional sequence needs to be started in run_phase, then as Dave said main_phasemust be used to run after configure_phase. Correct me if I am wrong.

[MikeOpenHWGroup]

You are not wrong @subbu009. This is an outstanding issue in CORE-V-VERIF. Resolving this issue would allow the testbench to support "on-the-fly" reset. Would you be interesting in submitting a fix for this?

[subbu009]

Yes, I am interested. Help me get started

[subbu009]

Hi @MikeOpenHWGroup , If we replace the run_phasewith main_phase, then all the three phases reset_phase, configure_phaseand main_phasewill run one after the other as expected. I guess this will fix the issue explained by Dave.

About the "on-the-fly" reset, could you please elaborate more on the task as what is expected?

[MikeOpenHWGroup]

If we replace the run_phase with main_phase, then all the three phases reset_phase, configure_phase and main_phase will run one after the other as expected.

Yes, that is my understanding as well.

About the "on-the-fly" reset, could you please elaborate more on the task as what is expected?

Essentially this means randomly asserting reset at some time after the initial reset is de-asserted. This implies that the RTL will be executing a test-program and then jump back to the initial boot-address and re-start executing the same test-program. These on-the-fly resets are handy for detecting un-initialized conditions in the RTL. Typically, the testbench will have a large amount of state and trying to figure out which should be discarded and which should be kept (if any) when an on-the-fly reset occurs is a difficult problem.