Defining uvm_test class inside test program block. Any reason for it?

[klarson]

In every single published example that I've ever seen, including all of the 'official' UVM examples, the extended uvm_test test class always is defined inside of the SV program block. Is there any actual advantage or reason to do this, or is this simply a convention that has been established?

I could see one advantage might be if you are instantiating your UVM environment inside the program block, then a test class which is defined inside the program block will be able to reference that environment pointer directly. This actually seems like a bad idea though, from an data encapsulation point of view, and sure enough many (but not all) of the example programs will do a uvm_root::get() with a find coupled with a $cast to locally get a pointer to the specific UVM environment before using it, even though they could simply reference the environment variable in the program block directly if they wanted.

So if it's not for easy access to the UVM environment pointer, why define the class inside the program block at all? Couldn't you argue for more flexibility and reuse by defining the uvm_test objects independently from any program block? Why does everybody do it this way? I've tried definining the uvm_test object outside the program block and it seems to work just fine.

[dave_59]

None of our examples at http://verificationacademy.com/uvm-ovm define the test classes in program blocks. In fact, we do not even recommend the use of program blocks.

We recommend that all testbench classes be defined inside packages, and you use the factory to select which test to run using +UVM_TESTNAME. That way you never have to re-compile your simulation in order to select or add a new test.

[klarson]

Thanks Dave, I'll definitely check out the examples.

Regarding program blocks, I thought the main reason to use program blocks in SystemVerilog was because of the evaluation order of events within the simulation. I suppose you could argue that if you're using interface modules with clocking blocks correctly you should already be able to eliminate race conditions between the DUT and the testbench.

If your main environment didn't use program blocks, you'd have to take additional measures explicitely end the simulation. You'd also run the risk of somebody else's embedded program block ending your simulation prematurely when their program block ended before you were ready. Seems a little scary :-)

[dave_59]

Yes, if you are already using clocking blocks, then program blocks add no value.

The UVM provides a much better end-of-test mechanism with objections. I suppose I never considered the case you mentioned as I usually only see one program block if any in someones testbench.

[Logger]

Here's a tidbit from what I've learned with our tests.

In some of our directed tests, we utilize white box, cross module references to force events in the DUT. Achieving the same result would be extraordinarily difficult if we had to coax the DUT to generate the desired behavior. Putting tests in a package makes using XMRs illegal. Because of this I've concluded it's best to put all of the testbench, sans the tests themselves, into packages. For the tests however, it makes the most sense to put them in a module or a program. This seems a lot easier than creating some interface that indirectly implements the forces, and is easier for test writers to work with. You could put the tests in the global scope, but putting them in a module or program enables incremental/partial compiles.