Active test components

[Erling]

In the uvm examples and user guide, a test (derived from uvm_test) is usually just a constructor, it does not actually do any real work during the simulation. I wonder if things could be simplified by having the test component itself participate more actively in the test. A start could be to run sequences in the test run phase instead of storing a reference to the sequence in the config_db to be picked up later on as the default sequence on some sequencer. A more complicated test could, for example, start multiple sequences directly in its run phase, perhaps on multiple sequencers, orchestrate the overall test activity, handle dependencies between sequences to different interfaces, and so on. However, the user guide recommend virtual sequence®s for this purpose, again doing construction and config only in the test itself.

Any thoughts on this? Is it best to follow the user guide in this regard to avoid accidents, and if so, what accidents would that be?

Erling

[krb]

I think the benefit of using using sequences/virtual_sequences is that they could be reused in other sequences.

I am not sure if you can reuse a uvm_test (derived components).

I partly see the point in your question.

At the moment for my test envinorment, there is a one to one correspondence for a uvm_test to a top_level sequence.

[Tedd]

uvm_test contain test specific things, as you see most time it is doing config thing. and it is not a place to start sequence.

the accidents is that maybe your colleges will complain you, do you like this?

[Erling]

I think the benefit of using using sequences/virtual_sequences is that they could be reused in other sequences.

Yes, that is a good point. Primitive sequences and composite sequences (like dut config sequences etc) are perfect (and often easy to design) for reuse. A top level sequence, however, seems to be much more difficult be put together as a reusable unit in isolation, since they are written for a specific purpose, perhaps for a specific configuration of the dut and/or test environment.

I am not sure if you can reuse a uvm_test (derived components).

Well, that is exactly what I want to do in many cases. A new test can be derived from an existing one. That way, both behavior and configuration are inherited. The new test can modify the base test in many ways, for example by factory replacement of sub-sequences used by the base test with bad sequences for error injection etc, and it could be overriding virtual hooks in the base test and so on. This should work even if the test does not have a top level sequence.

Another thing is that the run phase of a test is a nice place to be, since a test is a first class component with a perfect view over the entire environment. A top level sequence lives in a more limited space, and would require helpers like virtual sequencers etc to do things that would come for free in a test run phase.

However, inexperienced as I am, it would seem best to follow advice in the uvm user guide. But the approach there seems to be incompatible with my brain somehow:confused:. Overuse of macros, for example, to hide things that would aid understanding if made explicit, the approval of virtual interfaces, and overuse of the config_db. It is as if things that can't be done through the config_db is not worth doing. Consider a trivial test class, it goes like this in my small world:

class MyTest extends ...

  function void build();
    // build test environment here
  endfunction
  
  task run();
    // run the test here
  endtask
  
endclass

The user guide version of the same test goes like this:

class MyTest extends ...

  function void build_phase(uvm_phase phase);
     uvm_config_db#(uvm_object_wrapper)::set(this, "tb.agt.sqr.run_phase",
    	"default_sequence", SomeSequence::type_id::get());
  endfunction

endclass

The simple concept is now obfuscated with boost::like::style and a hard coded path that can't be checked at compile time. Not sure how this is going help.

Anyway, for all I know, the user guide may be right on the spot, and me that don't get it. Are you at home with test benches as presented in the user guide?

Regards,

Erling

[Erling]

uvm_test contain test specific things, as you see most time it is doing config thing. and it is not a place to start sequence.

Why? It seems it could help keep simple things simple, and also lower the threshold to get started with uvm. For example, with the recommended test style, a trivial thing like adding a delay to end a test is a major undertaking for a non-expert, while an active test can simply #delay and return, and that's it.

the accidents is that maybe your colleges will complain you, do you like this?

Yes. It could result in a fruitful discussion and exchange of ideas. We have goals with uvm key to implement them, but how to get there isn't written in stone.

Erling