How to define sequence_item

[mwhite_cp]

Is there a standard way or rule of thumb to follow when defining a sequence_item?

I need to define a item for video data. The video data pixel consists of Red, Green, and Blue data (8, 10, or 12 bits). A frame image consists of 1920x1080 pixels. (The actual size is a little bigger and needs to be parameterized.)

What is a recommended way to define the sequence_item for this?

If possible, I would like to use UVM macros (uvm_field*), this means I should not be using unpacked arrays to define data members?

Thanks!

[lisakb1963]

This is pseudo code, but you can use dynamic arrays and set this pixel size on the command line with set_config_int or with the tb, or a test. This allows for flexible code.

You could have a default_pixels_size and and a control knob for using it, versus making it random.

The uvm_array_field macros are 1 dimensional, I've tried to work around it in pseudo code, but you can try to make multi-dimensional objects.

class frame (type int HEIGHT, int WIDTH) extends uvm_sequence_item;

int pixels[][][]; // R, G, B or you can make this easier with one dimension arrays or a struct and put those into a struct for manipulation.

//one dimension version;

// data

rand int pixel_red[][]

rand int pixel_green[][];

rand int pixel_blue[][];

//control knobs

int use_default_pixel_size;

rand int pixel_size; // this is actual pixel_size can be overriden from a higher source.

// register with macros

`uvm_object_utils_begin(frame)

`uvm_field_int(pixel_size, UVM_ALL_ON);

`uvm_field_array_int(pixel_red, UVM_ALL_ON);

....

`uvm_object_utils_end;

` // Default Constraints

constraint c_pixel_size{ pixel_size == 8; pixel_size== 10, pixel_size == 12 ; }

constraint c_frame_width { WIDTH == frame[1].size(); }

constraint c_frame_height {HEIGHT == frame[0].size();}

get_config_int("use_default_pixel_size", use_default_pixel_size);

if ( use_default_pixel_size == 1)

get_config_int("default_pixel_size", pixel_size);

if you want the pixels to be packed logic vectors, you can still use the uvm_field macros) -- it may be hard to put a bounds on the logic vector -- if you want flexibility.

rand logic [7:0] pixel_red[][];

Now you need to paramaterize the size as well (and you might want to do that, and have the height and width in the configuration data base.

class frame #(type int PIXEL_SIZE) extends uvm_sequence_item; or

class frame #(type int PIXEL_SIZE, int HEIGHT, int WIDTH);

You can play around a see what works best for you and what compiles with your compile and constraint solver

get_ config_data

[mwhite_cp]

Hello lisakb1963,

Thank you very much for your response to my post.

I am confused why pixel_xxx[][] will be one-dimensional. Would this work with `uvm_field_array_int? I probably want to use rand logic [7:0] pixel_xxx[][]. I will play around with your code suggestion. Thank you!

[lisakb1963]

If you hard code logic[7:0] pixel_xxx[][], then you will not be able to 8, 10 and 12 bit pixels.

The one dimension part comes from the user's guide:

`uvm_field_array_int

Implements the data operations for a one-dimensional dynamic array of integrals.

`uvm_field_array_int(ARG,FLAG)

ARG is a one-dimensional dynamic array of integrals, and FLAG is a bitwise OR of one or more flag settings as described in Field Macros above.

`uvm_field_array_object

Implements the data operations for a one-dimensional dynamic array of uvm_object-based objects.

`uvm_field_array_object(ARG,FLAG)

ARG is a one-dimensional dynamic array of uvm_object-based objects, and FLAG is a bitwise OR of one or more flag settings as described in Field Macros above.

You could have a further refine your model by having a pixel class

It would have properties, like size, color, etc (maybe something in post_randomize() like perform gamma to change a 12 bit pixel to 8 bit. Or some other type of transform.

Then you can have an array of pixel objects , but it still seems like you have row/column 2 dimensional array issue. I am not sure you can slice off a dimension and register it with the field operations (this seems like a basic concept to me).

[mwhite_cp]

Thank you again for your response.

Yeah, I meant to say I will use parameterized (pixel size, height, and width) class as you suggested near the end, instead of hard coding the pixel size.

My thought has been that I need to create classes for pixel, row, and frame if I want to use uvm_field_array_* macros. The row class has data members of pixel array objects, and the frame class has data members of row array objects. This will avoid having multi-dimensional arrays. But I wondered if there is a better way and posted here. It seems that there is no other way if using the macros. Would you agree? If I don't use the uvm_field macros, I don't need to create multiple classes and only need to create a frame class. Would it be better to use multiple sequence item classes in order to use the uvm macros or would it be better to create a single sequence item class without uvm_field macros?

Thank you!

[janick]

Be careful with the decision to use class parameters! Every class (e.g. the driver. monitor and scoreboard) that will have to process the video transaction will have to be similarly parameterized. This will then require that every class using those classes (e.g. agent, environment, tests) to be parameterized as well!

Parameters, when used for sizing, can "infect" your entire verification environment...

[mwhite_cp]

Hello Janick,

Thank you for your post regarding to the parameters. What would you use instead of class parameters when the size is fixed per DUT basis?

Thank you!

[janick]

You can use class parameters if you can separate the size-specific stuff from the size-generic stuff (the latter going into a base class) and be able to write all of the processing in terms of the base class. That would leave the parameter specializations only when instantiating the transaction classes which can be done via a factory.

The other alternative is to code for the maximum size and let Verilog's automatic truncation/extension take care of the scalar values.