Question:
Suppose you preload a binary test program into CPU memory on a UVM testbench. What is the proper method for raising/lowering objections to start/stop the preloaded test, considering you aren't necessarily driving data/running sequences to the DUT during the test?
Background:
I built a simple UVM testbench and am verifying an extremely simple 8-instruction CPU, to teach myself UVM/SV fundamentals.
I verified each block in isolation, using constrained-random or directed tests.
I am now testing the full CPU. I have short 32-line binary test program, that adds, xors, jumps, etc. If the CPU works correctly, execution will end on reaching a halt opcode at a certain memory address.
I successfully preloaded that file into the memory from the top module with $readmemb.
https://verificationacademy.com/forums/uvm/preloading-memory-uvm
But now what?
For block-level testing, run_test() would start a test that raises an objection, the sequence would start_item and run to completion, and then the test would drop the objection.
But for a preloaded test, the test is already in memory, so I don't have transactions to drive, so I don't have a sequence to run, and therefore, don't have anything raise/drop an objection around.
I am sure there is a simple answer, but I have failed to find it. I did look at the OpenHW team's test bench. They appear to use some kind of flagging, but it seems sort of advanced, and I'd like to confirm this is the proper approach before diving in.
---
https://docs.openhwgroup.org/projects/core-v-verif/en/latest/uvm_tests.html
"In the self-checking scenario, the testcase is pre-compiled into machine code and loaded into the dp_ram using the $readmemh() DPI call. The next sub-section explains how to select which test program to run from the command-line. During the configuration phase the test signals the TB to load the memory. The TB assumes the test file already exists and will terminate the simulation if it does not.
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).
At this point the run flow will simply wait for the test program to flag that it is done via the status flags virtual peripheral. The test program is also expected to properly assert the test pass or test fail flags."
