uvm_object get_inst_id() not working

[walkeranderson]

I'm seeing the uvm_object get_inst_id() function not returning unique, new IDs for new objects that I create.  More specifically, it's returning a repeating cycle of a few different IDs.  Looking under the hood at uvm_object.svh it's a pretty trivial mechanism so I can't see why it isn't working.  Also, in a derived class I created I mimicked the same mechanism and my mechanism works fine.

 

Test case and example output is below.  Note that the static instance count value seems to increment nicely as expected but the instance ID values seem to bear no relation to that count and repeat every 6 objects.

 

 

Am I missing something really obvious here or is this a possible bug.  I see this using UVM 1.1d downloaded from Accellera.

 

//////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

 

class my_object_t extends uvm_object;

 

  static int next_id;

  int my_id;

 

  function new (string name="my_object");

    super.new(name);

    my_id = next_id++;

  endfunction : new

 

  `uvm_object_utils(my_object_t)

 

endclass

 

 

 

 

      begin

         my_object_t my_object;

         for (int i = 0; i < 100; i++)

           begin

              my_object = new();

              `uvm_info("", $sformatf("my object inst id is %d (0x%0x) or %0d, inst count is %d (0x%0x) or %0d", my_object.get_inst_id(), my_object.get_inst_id(), my_object.my_id,

                                      my_object.get_inst_count(), my_object.get_inst_count(), my_object.next_id), UVM_LOW)

           end

      end

 

 

 

 

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 0, inst count is        9585 (0x2571) or 1

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 1, inst count is        9586 (0x2572) or 2

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 2, inst count is        9587 (0x2573) or 3

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 3, inst count is        9588 (0x2574) or 4

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 4, inst count is        9589 (0x2575) or 5

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 5, inst count is        9590 (0x2576) or 6

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 6, inst count is        9591 (0x2577) or 7

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 7, inst count is        9592 (0x2578) or 8

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 8, inst count is        9593 (0x2579) or 9

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 9, inst count is        9594 (0x257a) or 10

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 10, inst count is        9595 (0x257b) or 11

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 11, inst count is        9596 (0x257c) or 12

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 12, inst count is        9597 (0x257d) or 13

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 13, inst count is        9598 (0x257e) or 14

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 14, inst count is        9599 (0x257f) or 15

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 15, inst count is        9600 (0x2580) or 16

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 16, inst count is        9601 (0x2581) or 17

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 17, inst count is        9602 (0x2582) or 18

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 18, inst count is        9603 (0x2583) or 19

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 19, inst count is        9604 (0x2584) or 20

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 20, inst count is        9605 (0x2585) or 21

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 21, inst count is        9606 (0x2586) or 22

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 22, inst count is        9607 (0x2587) or 23

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 23, inst count is        9608 (0x2588) or 24

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 24, inst count is        9609 (0x2589) or 25

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 25, inst count is        9610 (0x258a) or 26

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 26, inst count is        9611 (0x258b) or 27

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 27, inst count is        9612 (0x258c) or 28

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 28, inst count is        9613 (0x258d) or 29

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 29, inst count is        9614 (0x258e) or 30

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 30, inst count is        9615 (0x258f) or 31

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 31, inst count is        9616 (0x2590) or 32

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 32, inst count is        9617 (0x2591) or 33

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72126 (0x119be) or 33, inst count is        9618 (0x2592) or 34

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72120 (0x119b8) or 34, inst count is        9619 (0x2593) or 35

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       69783 (0x11097) or 35, inst count is        9620 (0x2594) or 36

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72135 (0x119c7) or 36, inst count is        9621 (0x2595) or 37

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is       72122 (0x119ba) or 37, inst count is        9622 (0x2596) or 38

UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is         581 (0x245) or 38, inst count is        9623 (0x2597) or 39

[tudor.timi]

I tried it out on EDAPlayground and it works properly there. Seems like you've got a simulator bug on your hands.

[walkeranderson]

Thanks.  I'll log it with the simulator vendor.

[uwes]

hi,

 

my initial take is that this is simply due to the fact that you allocate the object but since its unused the object gets garbage collected AND the id gets reused in a subsequent object allocation. the point is that there is that the id's are the actual internal heap id's from the simulator and they are reused (there is no guarantee that an id is uniquie over the whole simulation its only unique in the current set of objects)

 

to prove the assumption simply keep the ref by pushing it into an dyn array.

 

/uwe

[tudor.timi]

@Uwe Still, even if this does happen, the static variable for the inst_id (inside uvm_object) shouldn't get decremented. I'd still go with simulator bug.

[walkeranderson]

Funny, the response I got from the simulator vendor is basically that the ID is not guaranteed to be unique over the whole simulation for the very reasons cited by post #4.

 

I guess I'd argue that I would have thought that the UVM intention was that these IDs would be unique across UVM objects over the life of the simulation.  Is that the UVM intention?

 

The use of a static counter variable in the reference implementation suggest that it is the intention.

 

Also, as post #5 says, since the uvm_object new() is using a static count variable to assign the ID, this shouldn't ever be decremented/destroyed by garbage collection so I agree that I still think it's a simulator bug.

[dave_59]

I don't understand how any of the reasoning in post #4 can be correct.

First of all, the object is in use until the next object gets created. As long as a class variable holds a handle to a class object, that object must exist.

Second, when you construct an object, all class members get initialized with default values. That is independent of any simulator implementation; the user should not be aware of any reused objects.

Third, there is only one static variable m_inst_count for all classes derived from uvm_object. So how could the id not be unique until you construct the 2³²th object?

[walkeranderson]

Agree with post #7.  Also, if you look carefully at the example I posted, the count seemed to be incrementing quite nicely but it didn't seem to be getting used to initializing the ID of each object.

[uwes]

hi,

 

uvm_object::new says that m_inst_id == m_inst_count++. essentially take the current global id then increment the counter. so when you print the object right after its construction you both should be almost the same. as you can see from your log that isnt the case for IUS. the reason for this is that for IUS the m_inst_id is being set to the (internal) heap id of the object in the simulator. the reason for this is that that way simulator internal heap id's does not differ from those printed/used via UVM. 

 

regarding dave's points:

 

>First of all, the object is in use until the next object gets created. As long as a class variable holds a handle to a class object, that object must exist.

 

agreed, but in the example code that isnt the case. in the original code the "my_object" gets new() and the old handle isnt used anymore therefore the core can garbage collect the object (and therefore free the IUS internal heap id (the uvm m_inst doesnt reuse id's) 

 

>Second, when you construct an object, all class members get initialized with default values. That is independent of any simulator >implementation; the user should not be aware of any reused objects.

yes

 

>Third, there is only one static variable m_inst_count for all classes derived from uvm_object. So how could the id not be unique until >you construct the 2³²th object?

 

m_inst_count is unique as the log indicates. all what happens is that IUS overrides m_inst_id for the newly created object with the heap-id (which is also unique). the difference here is that UVM m_inst_id is unique over the full simulation while the IUS heap id gets reused if an object is disposed.

 

 

here is an example illustrating that the print of the uvm object showing object with the inst_id 2570 can be as well referenced with TCL cmds as @2570

ncsim> run -next
UVM_INFO test387.sv(33) @ 0: reporter [] 

-----------------------------------
Name       Type         Size  Value
-----------------------------------
my_object  my_object_t  -     @2570
-----------------------------------


ncsim>  describe @2570
test.my_object_t@2570_1...handle class test.my_object_t extends uvm_pkg::uvm_object {
                            static int next_id = 1
                            int my_id = 0
                            const static string type_name = my_object_t
                            static bit use_uvm_seeding = 1'h1 (from class uvm_object)
                            local string m_leaf_name = my_object (from class uvm_object)
                            local int m_inst_id = 2570 (from class uvm_object)
                            static protected int m_inst_count = 448 (from class uvm_object)
                            static handle class uvm_pkg::uvm_status_container __m_uvm_status_container = @425_1 (from class uvm_object)
                          }

so this is a feature not a bug.

 

/uwe

[tudor.timi]

You guys are comparing apples vs. oranges here, then. In this case, the simulator doesn't do what the code tells it do, but implements its own backdoor. This is why it works for your own static variable, but not for m_inst_id. It's a cool feature, I give it that, but it causes confusion.

[uwes]

hi,

 

>In this case, the simulator doesn't do what the code tells it do

 

you could see it this way - on the other hand from an UVM API perspective there is no guarantee that you are getting an incremental number starting from 0. the get_inst_id() is supposed to return the "object's unique id" as per specification. 

 

>but it causes confusion.

 

well its the first time time it causes confusion. when the get_inst_id() and the internal heap id ius is using in all other places would differ then there would be much more confusion. 

 

/uwe

 

btw: this functionality obviously is only enabled for uvm_object::m_inst_id

[dave_59]

Uwe, I agree that the specification does not guarantee an inst_id that is incremental starting at 0, but the API does say "The instance counter is used to form a unique numeric instance identifier." so that implies a unique inst_id across all constructed objects derived from uvm_object that cannot be reused.

[uwes]

dave,

 

>so that implies a unique inst_id across all constructed objects derived from uvm_object that cannot be reused.

 

maybe the term "instance counter" is misleading - all the inst-id is about is an unique id for an object. unfortunately UVM does specify another "instance id" on top of the handles the simulator is already using. it is guaranteed that the internal heap id is unique among all existing objects. An internal heap id can only be reused once all references to that object are gone and the object is garbage collected.