Simulation doubt

In simulation i am getting such type of report:
Name type size value
uvm_test_top ei_usb30_base_test - @464
uvm_30_env ei_usb30_env - @477

Q1) my question is what is this value?
Q2) how to check functional coverage in questa?

In reply to tech_savvy:

Q1) my question is what is this value?

That’s a number made up by the simulator to represent an object.

Q2) how to check functional coverage in questa?

Please contact your vendor directly for tool support.

In reply to warnerrs:

Q1) So does this value keep changes(for respective object) whenever i do simulation?

In reply to tech_savvy:

In my experience, the tools use a deterministic algorithm to generate those numbers. However you can’t actually rely on that being the same from one sim to the next, as any number of little things could slightly perturb the algorithm ( it’s undocumented ).

On the other hand, during the course of a single simulation, that number should be constant for a given object. So,

Klass k = new;
Klass j = new;
Klass i = new;

$write( "k=@%0d, j=@%0d, i=@%0d\n", k, j, i );

Will print something like:
[pre]k=@1, j=@2, i=@3[/pre]

And the same number for those objects, should print for the remainder of the simulation. This is a big assumption on my part. I haven’t seen an SV LRM requirement that requires that. But I’ve used multiple simulators, and so far that’s the behavior I’ve seen.

@warnerrs, you’re right in your observation but wrong in your conclusion :-). It is not the tools that generate these numbers but UVM itself. The number is a UVM object instance id, accessible via the uvm_object::get_inst_id(). For every uvm_object that UVM creates, it increments the ID. Therefore it will remain constant as long at you don’t change either your code (creating new objects, changing the order of creation), or your simulator (which might trigger changes to order of execution anyway).

m_inst_id code on github

code that prints top question on github

In reply to avidan:

@avidan, I never traced back to the source of those numbers, but I noticed they behaved just like my example $write() statement. Thanks for that detail, thanks makes a lot of sense.