Data-type Parameters

[mea1201]

What's the best way to define the actual data type from a test, and set the module side accordingly? In the class side, the sequence item has a data member. Its type is parameterized, and it's intended to be overridden usually with some sort of bit vector of any size (e.g. bit[N-1:0], packed struct). The rest of the classes are parameterized on this data type. Similarly, the module side is parameterized (interface, top-module). If I define a particular type in a test class, then how can that pass over to the module side?

Thanks for any ideas and opinions.

[pratta]

The value used to specialize the SV classes and the modules and interfaces must be consistent, and they must be known at the time of elaboration (so accessor methods won't help). The only way to test multiple values of N that I know of is to pass the value in as a compile-time constant and run all tests with that value. If you need to test multiple values of N then you will need several compile and run passes (luckily that is a highly parallel problem and so each value of N could be run on a separate host in a separate testbench area).

[mea1201]

I agree. However, the issue described is related to type parameters, not value parameters. There are more limitations to overriding types, and none of the major simulators, as far as I know, supports overriding types from the command-line, such as a -g option (for generic) or from a params file. I suppose I could encapsulate the data item with a UVM object, develop a bunch of various classes for that, and use the factory override, which can be dictated by the test class. But, what if I want to keep it lightweight, and be able to override the data item within the transaction with a variety of packed representations.

For example, this is representative of the sequence item:

class trans #(type T = bit[7:0]) extends uvm_sequence_item;  // default type unsigned byte
`uvm_object_param_utils(trans#(T))
...
T data;

The interface would have tasks that can operate on trans.data, so it is also parameterized the same way. And, the testbench would instantiate the interface such as

typedef struct packed { bit[31:0] my_data, bit error_bit } a_data_item_t;  // overriding default just to illustrate the point
bus_if#(.T(a_data_item_t)) u_bus_if (.*);
...

Except, I'd like more variability with the type definition, ideally letting the chosen test determine that.

PS: Why is BB editing off???

[pratta]

I agree that this is a trickier problem. You're right that simulators cannot pass types in on the command line, but if the variable portion of your design is scalar values such as data vector widths or number of elements then you can still pass those values in on the command line and then use the typedef construct to create your specific type. For example, pass this in on the command line:

+define+DATA_VECTOR_WIDTH=<value>

Then in your code you define your customized type:

typedef bit [`DATA_VECTOR_WIDTH-1:0] data_vector_t;

Now in your code you always use the data_vector_t type.