walkeranderson Posted November 11, 2014 Report Share Posted November 11, 2014 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 EkbergMit, WelchKino and JeremyCali 3 Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted November 11, 2014 Report Share Posted November 11, 2014 I tried it out on EDAPlayground and it works properly there. Seems like you've got a simulator bug on your hands. Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted November 11, 2014 Author Report Share Posted November 11, 2014 Thanks. I'll log it with the simulator vendor. Quote Link to comment Share on other sites More sharing options...
uwes Posted November 12, 2014 Report Share Posted November 12, 2014 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 Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted November 12, 2014 Report Share Posted November 12, 2014 @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. Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted November 12, 2014 Author Report Share Posted November 12, 2014 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. Quote Link to comment Share on other sites More sharing options...
dave_59 Posted November 12, 2014 Report Share Posted November 12, 2014 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 232th object? Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted November 13, 2014 Author Report Share Posted November 13, 2014 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. Quote Link to comment Share on other sites More sharing options...
uwes Posted November 13, 2014 Report Share Posted November 13, 2014 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 232th 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 Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted November 13, 2014 Report Share Posted November 13, 2014 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. Quote Link to comment Share on other sites More sharing options...
uwes Posted November 13, 2014 Report Share Posted November 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
dave_59 Posted November 13, 2014 Report Share Posted November 13, 2014 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. Quote Link to comment Share on other sites More sharing options...
uwes Posted November 20, 2014 Report Share Posted November 20, 2014 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.