How to use new sequence item (extended from base sequence item & has new members)

[anantv]

Hi

I would like to know how to develop a UVM TB including:

1. "base_sequence_item" extended from uvm_sequence_item

2. driver, sequence & other components using the base_sequence_item

3. New sequence item "enh_sequence_item" extended from "base_sequence_item"

So in order to use the new sequence item "enh_sequence_item", what are the applicable changes to be done in UVM TB?

Just the set_override_by_type setting in uvm_test is OK ?

How about a local task inside driver with the base sequence item as argument?

It will flag compilation error, as the driver will be getting the new sequence item from sequencer, but the local task will have formal argument as base sequence item!!!

I can't modify the code of the local task in driver for each sequence item.

Please provide any suggestions.

Thanks

anantv

[dave_59]

Typically, your driver interacts with your item using virtual methods of the sequence item. For example, the pack and unpack methods will know what do do with the extra fields. The driver just sees a stream of bits or bytes. We we would need to know more about what these additional members do to suggest further.

[anantv]

Hi Dave,

My concern is that I have created the "base_sequence_item" extended from uvm_sequence_item with class members (like data & cmd).

Later I have created new sequence item "enh_sequence_item" extended from "base_sequence_item" with new class member (like addr).

Now the sequence item "enh_sequence_item" has three class members (data, cmd & addr).

But I have developed a custom task in run_phase of driver as follows:

task do_op(base_sequence_item item)

if(item.data == 'h00)...........

else .................

endtask

Now the problem is the custom task expects the argument of type "base_sequence_item" whereas I will be sending "enh_sequence_item" type.

This results in tool error, even though I have created uvm test & sequence using the "base_sequence_item".

Please provide me your suggestion on how to overcome this issue, without changing my custom task (do_op) in driver?

Thanks

anantv

[dave_59]

What you have shown should not result in a tool error. You should always be able to assign an extended object instance to a base class variable without a cast. Can you show us a little more code and the actual error message you are getting.

[anantv]

Hi dave,

Please find the details on the issue:

class base_sequence_item extends uvm_sequence_item;

rand bit[7:0] data;

rand byte cmd;

.................................

.........................................

endclass : base_sequence_item

class enh_sequence_item extends base_sequence_item;

rand byte addr;

.................................

.........................................

endclass : enh_sequence_item

Inside driver's run_phase task:

............................................................................

seq_item_port.get_next_item(req);

do_op(req);

........................................................................

task do_op(base_sequence_item temp_item);

if(temp_item.addr == 8'h00)

endtask

This code will result in compilation error as :

ncvlog: *E,NOTCLM (../sv/abc_driver.sv,130|189): addr is not a class item

I will be creating different sequence item from base item, hence changing the custom task "do_op" to use respective sequence items is not optimal solution.

Please provide me your suggestion on how to overcome this issue, without changing my custom task (do_op) in driver?

Thanks

anantv

[uwes]

hi,

obviously you cant access base_sequence_item::addr because its not a member of that class. even when you can assign a derived class handle to a base class handle you can only access properties of the baseclass via the baseclass handle.

there are a couple of approaches:

1. $cast the temp_item to an enh_sequence_item (then you can access the enh_sequence_item properties)

2. add a virtual function to base_sequence get_addr() and implement this in all derived classes. then in do_op() call get_addr() to retrieve the addr

3. guess there are more ...

/uwe

[anantv]

Hi Dave,

Thanks a lot for the clarifications & suggestions.

I am OK with appraoch 1).

Thanks

anantv

[uwes]

Hi Dave,

Thanks a lot for the clarifications & suggestions.

I am OK with appraoch 1).

Thanks

anantv

i'm not dave - but anyway :-)

[anantv]

Hi uwes

Sorry for that

Thanks

anantv