Packing only some variables of class

Hi Verification Academy Team,

I have a query related to packing/unpacking in uvm.
I have a class named ‘packet’
It has 5 variables:
bit [2:0] a;
bit [3:0] b;
bit [4:0] c;
bit [5:0] d;
bit [7:0] e;

I want to pack only a,b,c variables, not d and e variables.
How to do that? (I tried using do_pack method, but somehow it is packing all of these variables)

Thanks,
Navdeep

In reply to navdeepp5:

Can you show us what you tried and did not work.

Hi Dave_59,

I was trying as below:

class Packet extends uvm_object;
rand bit [2:0] a;
rand bit [3:0] b;
rand bit [4:0] c;
rand bit [5:0] d;
rand bit [7:0] e;

uvm_object_utils_begin(Packet) uvm_field_int(a, UVM_DEFAULT)
uvm_field_int(b, UVM_DEFAULT) uvm_field_int(c, UVM_DEFAULT)
uvm_field_int(d, UVM_DEFAULT) uvm_field_int(e, UVM_DEFAULT)
`uvm_object_utils_end

endclass

After looking into UVM library, I got to know that uvm_field_int(a, UVM_DEFAULT) includes "packer.pack_field_int(a, $bits(a));". If I don't want to pack some variable, then I should use 'uvm_field_int(d, UVM_DEFAULT|UVM_NOPACK)'.

But now I have a different question:
I have a packet.sv file which has class Packet as shown above. But I cannot modify this packet.sv file.
And I want to pack only a,b,c variables. So how can I do that?

Thanks,
Navdeep

In reply to navdeepp5:
The fact that you cannot override the settings of the field macros and their poor performance are just some of the reasons we recommend against using them.

You said you tried using do_pack. Just make you do not call super.do_pack.

You can avoid avoid all of UVM’s pack/methods and just use SystemVerilog’s streaming operators

bit [7:0] myBytes[];

myBytes = {<<{a,b,c}};


In reply to navdeepp5:

Thank you for the Reply Dave.
Use of Streaming operator solves my problem.

But now I have a different question:
I have a packet.sv file which has class Packet as shown above. But I cannot modify this packet.sv file.
And I want to pack only a,b,c variables. So how can I do that?

Since you cannot modify it (assuming it came from a third party), could you derive a new class from packet.sv and use the UVM Macros there?

I never understood the advice (from Mentor specifically) for avoiding for the UVM field Macros. Ideally you could write your own methods (and more importantly debug and maintain them) assuming you had all the resources on the planet… but when we have done performance measurements of our sims, these things never seem to be where things get bogged down. I’ve seen papers where people run performance measurements of them, and tests are usually run sans RTL. We have found that the pros outweigh (engineers time) the cons for us.

In reply to Michael D Scott:

My 0.02$ here, I think Mentor also mentions some issues/complexity can arise when debugging the code generated by the automation macros (In several other questions in this forum), but I think generating these methods is quite simple to automate, specially if you have your transactions defined in some machine readable specification, which in my experience have been a very good investment rather than a waste of resources, but I guess each project/company has their own priorities when it comes to project development.

In any case for very simple transaction items macros are more than enough without any performance penalties.

-R

In reply to rgarcia07:

I can definitely see that debugging the macros might be difficult. You can’t really put a breakpoint on a macro AFAIK.

We too have some transaction types that are generated from a higher level specification. I wrote the PERL years ago and we use the Macros and maybe overload the compare function in the autogenerated code. It has been a while since we looked at performance but next time we get a chance, rewriting those functions might be a worthwhile use of time.

Didn’t mean to start a holy war…

In reply to rgarcia07:

I can definitely see that debugging the macros might be difficult. You can’t really put a breakpoint on a macro AFAIK.

We too have some transaction types that are generated from a higher level specification. I wrote the PERL years ago and we use the Macros and maybe overload the compare function in the autogenerated code. It has been a while since we looked at performance but next time we get a chance, rewriting those functions might be a worthwhile use of time.

Didn’t mean to start a holy war…

In reply to Michael D Scott:

Actually it is good to have this feedback tbh, most of the times I’ve seen in this forum and others that the recommendation is X or Y and no further explanation is given. I do use the macros when possible :-) and also use the custom methods when “complex” logic is required for comparison or packing.

In any case I feel is really valuable to get feedback such as yours otherwise we stop learning :-) (btw Let the holy war start)

In reply to rgarcia07:

There is no correct or incorrect way here but it’s good to know both methodologies are available. It’s true that as an EDA vendor, we are biased because we see more of the problems than the successes coming to us. So it may be that using the macros doesn’t always create a performance problem, but in those cases where it does, it’s going to be harder to switch away.

I will say that I’ve seen problems coming from macro usage with lots of autogenerated code. And that’s the ideal place not to be using macros. The scripts should be able generate the methods efficiently for you.