Parameterized agent classes

UVM
,
1

I have come across a lot of statements related to parameterized classes that they should be avoided.
We know the flexibility parameters bring for RTL logic.

I am not sure why this is discouraged in UVM testbench. I understand that it creates a lot of verbose code and is probably prone to error but that is no reason not to use it given the advantage it brings.

I see the following reasons where parameters are really powerful.

  1. I have an agent which can be instantiated multiple times and each instance can have different bus widths corresponding to DUT interfaces
  2. I am developing an agent and design team is not in a position to fix the bus size. It might be 128 bits today but can change to 256 bits later
    So, the capture buffer in the sequence_items need to be properly parameterized. Once I do this, the sequence_items where they are used also need to be parameterized. For example, in drivers, monitors. Once driver/monitors are parameterized, the agent too need to be parameterized and hence the environment too.

I would like to hear comments why parameters are discouraged given the advantage they bring and if they need to be avoided, are there safer ways to implement?

2

In reply to verif_learner:

Hello,

Probably Dave will answer this with a more comprehensive explanation, but the main problem you face with parameters is that each agent with a different parameter represents a specialisation, then you face problems for example when casting or using configdb for example the following code will be illegal


function build_phase();

  agent_m=new[2];

  agent_m[0]=agent#(32)::type_id::create("agent", this)

  agent_m[1]=agent#(64)::type_id::create("agent", this)

I previous example you cannot store these agents in a single array since each specialization is a unique type thus generating issues in maintaining the code and extending it.

Probably there are more good reasons lets wait for Dave’s response :)

HTH,

-Ronald

3

In reply to rgarcia07:

In reply to verif_learner:
Hello,
Probably Dave will answer this with a more comprehensive explanation, but the main problem you face with parameters is that each agent with a different parameter represents a specialisation, then you face problems for example when casting or using configdb for example the following code will be illegal


function build_phase();
agent_m=new[2];
agent_m[0]=agent#(32)::type_id::create("agent", this)
agent_m[1]=agent#(64)::type_id::create("agent", this)

I previous example you cannot store these agents in a single array since each specialization is a unique type thus generating issues in maintaining the code and extending it.
Probably there are more good reasons lets wait for Dave’s response :)
HTH,
-Ronald

so, what is the solution?
There is no way one can design IP blocks without parameters.
I assume the same would be the case with UVM also.

4

In reply to verif_learner:
There are 3 ways to deal with oarameters:
(1) storing your parameters in a common package which i specific for each application
(29 using parameterized classes
(3) holding your parameters in the config_db (setting from test)

Depending on your actual requirements you can chosse on of these options.

5

In reply to verif_learner:

This paper can give you ideas EDA Software, Hardware & Tools | Siemens Software