Running/Ending Directed Test Preloaded Into CPU Memory?

UVM
1

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."

2

In reply to p*9s$eW:

You can have a scoreboard that raises an objection waiting for something to happen to lower that objection.

If your program is self checking, you can have halt at one particular PC address for a pass, another PC address for a fail. You can have a monitor on the address bus and send a transactions to the scoreboard. The scoreboard can then decide if the test passes or fails when one of the addresses are accessed. It should also have a timeout based on how long the program is supposed to run.

The OpenHW Group is doing something very similar by creating a virtual peripheral which is just a set of registers used by the test. The UVM RAL can be used to monitor the memory bus and a callback is can be set up to trigger the end of test when a particular register is written to.

BTW, that OpenHW page uses the term run_phase, when it really means main_phase.

3

In reply to dave_59:

Ok, great! I think I can make this approach work at my skill level. I will do some thinking, work on it and post either some working code or another question. Thanks, Dave.

4

In reply to p*9s$eW:

Hello, Dave.

Here is what I came up with:

In scoreboard.sv, I tried to drop objection when the CPU reaches the “success address” (17), and print to the log.

In test.sv, I raised/lowered an objection with an arbitrary time delay so that I could run_test(), to start the test.

Do you think this is a good approach? Any other criticism appreciated. I am next going to make the scoreboard uvm_tlm_analysis_fifo. This is simply my effort to teach myself sv/uvm, so all input welcome.

5

In reply to p*9s$eW:

Just a few style comments. The monitor class came up first so I’ll start there.

  • Always think about reusability. Give a meaningful prefix name to the class, even if it is just “cpu_monitor” instead of “monitor”.
  • The new() method is to initialize simple properties.
  • Use the build_phase() to construct the testbench, including the TLM port.
  • Always create your components and transactions, don’t call new(), otherwise you can’t override them later.
  • Reduce the number of messages in the log file. For example, “Build state complete” should be UVM_HIGH so it doesn’t normally print.
  • Split up the monitor run_phase() into two separate tasks, get_inputs() and get_outputs() to make it more modular. Each could have its own forever loop.
  • Your monitor only ever constructs one transaction object, then constantly writes over the properties, again and again. If your scoreboard ever has a delay between receiving a transaction handle and reading it, the object’s values could have been changed.

Also, the scoreboard’s write() method could process the incoming transaction handles immediately, without putting them in a queue. Trigger an event when pc_addr==17. Then the run_phase() just blocks on that event.

6

In reply to chrisspear:

This is excellent input! Thank you for the scrutiny, Chris. Will work on these changes.

-Taylor Templeton

7

In reply to p*9s$eW:

  • testbench.sv should be called cpu_test.sv as that is the core functionality in the file
  • A package is never included, only imported inside a module.
  • Don’t define anything outside a module / interface / package. Th.at is not really a global name space
  • Compile the packages first, then then the interface, and finally the modules.
  • The files with single classes should end with .svh for “SystemVerilog header”. This shows that these files are only included in a package, never compiled directly. Only .sv files are compiled directly.
  • A better name for the typedefs package would be cpu_rtl_pkg.sv
8

In reply to chrisspear:

  • The CPU transaction class could be called “cpu_item”, and stored in “cpu_item.svh”
  • Someday you might want to randomize the transaction properties, assuming these are inputs into the design. So declare them as rand.
  • The transaction class has 3 clock variables and reset. Those are really low-level RTL signals, not high-level properties. For example, are you going to generate a random clock or reset value? Is your scoreboard going to compare the clock value?

OK, enough avoiding my day job :-)

9

In reply to chrisspear:

Chris, this is awesome. Thank you for taking the time to look at it, really. Feedback is hard to come by and I very much appreciate it.

Taylor

10

In reply to p*9s$eW:

Gladly! Pay it forward and coach two more people. After 33 iterations, everyone in the world will know UVM. :-)

BTW - where did you learn SV and UVM? There are free courses here on Verification Academy, and UVM testbench generators from a wide range of providers. The simple ones will show you how to organize your code, while the sophisticated ones, like UVM Framework from Siemens, create highly reusable code.

11

In reply to chrisspear:

Will do, as soon as I am able to offer advice worth following, lol.

I started from zero in January with two online courses by Cadence. I then attended DVCon and learned about the Verification Academy early March.

I decided to first build a thing, no matter how ugly, to wrestle with the subject matter and enable feedback. Clearly I have a lot to work on, and I’ll pivot to working through the Academy material, in addition to working through your feedback.

Thanks again for the help.

(Will post to this thread when that piece of code has been improved.)