Sequence aware testbenches

[Erling]

I wonder if anyone has been thinking of (or perhaps even implemented) uvm testbenches that are aware of which sequencer a given sequence is supposed to run on. The usual procedure to run a sequence goes something like this:

MySequence seq = MySequence::type_id::create();

if (!seq.randomize()) uvm_error(...)

seq.start(path_to_some_agent.m_sqr, this);

A problem with this is that the test has to peek inside a changing environment during development. The test-writer has to know where things are, and if components are moved around or renamed, the test is broken. If the sequence is installed as a default sequence, the sequencer path will be a string not checked by the compiler and the test will break at runtime, which is potentially bad news, since it may not be obvious what has happened. Also, reusing a test with a different environment is more difficult when the test makes assumptions about what the environment looks like internally. Another issue is that virtual sequencers have to be properly connected to sub-sequencers, which requires even more hierarchical references. And the whole shebang is pretty verbose as well. What if it was possible to write:

RunSequence(MySequence::type_id::create());

in tests and sequences and be done with it? The testbench would simply route the sequence to the right sequencer by means of some sort of type discrimination. For example, if MySequence happens to be a virtual sequence, the testbench would recover this fact and run the sequence on the right virtual sequencer. And the virtual sequence, in turn, would also call RunSequence without the virtual sequencer having to be connected to any particular sub-sequencer(s).

Has anyone implemented such a scheme already and/or has ideas about how to implement it on top of uvm? Or, is there reason to believe this is a pretty daft idea after all, not worthwhile?

BTW, another motiviation behind this is to have the test be a place where non-experts can feel somewhat at home. I even want to get rid of the type_id, but that is a another story.

Erling

[Adam Rose]

Erling,

If the mapping from sequence to sequencer is done on the basis of type, then how do we deal with testbenches where there is more than one agent of the same type ?

Adam.

Edited November 17, 2011 by Adam Rose
typo

[Erling]

Good question. I did write a mockup to try out this idea in an environment with many sequencers, 14 to be exact, where 12 of them has the same type, i.e they are subcomponents of 12 agents of the same type. The references to these agents are kept in array, and what I did was to add an Index() method to the common sequence base class, where the Index() return value is derived from the sequence name. So, for example, to have a virtual sequence run sub-sequences on the agent array, we can do something like this:

class MyVirtualSequence extends VirtualSequence;

task body();
  for (int i = 0; i < nAgents; ++i) begin
    fork
      int agentIndex = i;
      begin
        string name = $sformatf("MySequence%0d", agentIndex);
        RunSequence(MySequence::FactoryNew(name));
      end
    join_none
  end
  wait fork;
endtask: body

endclass: MyVirtualSequence

A test can then run the sequence without reference to the virtual sequencer, for example:

task run_phase(...);

RunSequence(MyVirtualSequence::FactoryNew());

endtask

What happens then, is that the testbench first finds that this is a VirtualSequence, so it locates the virtual sequencer in the environment and have MyVirtualSequence run on it. When the virtual sequence, in turn, runs MySequence, the testbench finds that it shall run on the agent array, and therefore calls Index() on the sequence to lookup the actual agent. As a result, the virtual sequencer runs sequences on 12 different sub-sequencers without refererences to any of them.

The implementation of this is trivial, except for the implicit connection between sequences and the testbench. Another issue was how to deal with sequence randomization, but there are solutions for that as well, not super elegant but this is a more general problem, since it isn't possible to pass inline constraints as parameters or have them specified before point of randomization.

BTW, the sequence Index() was not actually introduced for this purpose, but was something I already had there in order to set command line options on a sequence when running on a specific agent.

There may of course be much better solutions, but the concept seems to work well so far.

Erling