Jump to content

How to define sequence_item


Recommended Posts

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...