Dear all,
Here's the context: I am setting up a UVM database containing reusable components, such that different projects can reuse the same components over and over. For the sake of reusability I am planning to have a repo of reusable components, so that any project can make use of those components by simply referencing the repo.
For instance, in the UVM repo I would put components for AXI4 Stream: sequence item (axi4s_master_seq_item and axi4s_slave_seq_item), sequences (axi4s_master_seq and axi4s_slave_seq), sequencer (axi4s_seqr), and agents (axi4s_master_agent and axi4s_slave_agent). The axi4s_*_seq_item contain constraint to properly randomize the transactions, and the axi4s_*_seq classes simply create one single transaction.
In my project for instance, I have an AXI4 Stream Slave component that accepts transactions generated and managed by the axi4s_master_agent. The project repo contains the environment and the test classes. However, in this "default" scenario, the transactions generated by the axi4s_master_seq will meet the "default" constraints specified in axi4s_master_seq_item. As a reference for the discussion, the axi4s_master_seq_item contains a random integer specifying the length of the burst (number of data chunks to send):
class axi4s_master_seq_item extends uvm_sequence_item;
rand int stream_len;
//...
constraint len_c {
stream_len inside { [1:512] };
};
endclassThere might be cases, though, where I need to override the "default" constraints. For instance, in my test I want the stream_len field to be exactly 256. Being UVM newbie, my current thought is to create in my project a prj_master_seq class that inherits from axi4s_master_seq whose body contains the following:
class prj_master_seq extends axi4s_master_seq;
//...
virtual task body();
//..
assert(req.randomize() with {
stream_len == 256;
});
//...
endtask
//...
endclassThe test then instantiates such prj_master_seq instead of the axi4s_master_seq base. However, doing so would require having a different *_seq class for each scenario I want to test, bloating the repository.
So, which is the proper way to manage this? Is there a way to keep the reusable UVM repo as bare and generic as possible, so that each project should only write the really strictly necessary classes, ideally only the test and environment classes?
Many thanks
Best regards
S
