Jump to content

steveb

Members
  • Content Count

    4
  • Joined

  • Last visited

  1. Yeah that makes sense. It seems that some of the examples out there really aren't good methods to follow. Some of the UVM reference examples and the Verification Academy both have examples where the model is locked within the reg_block. But other examples show it done in the env, which is probably the best place to do it. Thanks for the clarification. Steve
  2. I'm running into an error with my register blocks that works fine for MTI and NCSIM but doesn't work in VCS. What's the UVM policy on when a lock_model() statement should be called? I have a system-level testbench where there are unit-level register blocks that get integrated into the top-level register block. In each unit-level build(), I add all the registers then lock_model(). In the system-level register block I build each unit-level register block, add them as submaps, then lock_model(). This seems to make sense to me because each unit-level register block does a lock_model() and that exact code can be re-used at the system-level. However, VCS doesn't like that. It only works for me if the lock_model() is done only at the system-level register block. Which method is correct? Is it valid to lock unit-level register blocks before locking the top-level register block? I wanted to ask here before filing an issue against VCS. VCS generates the following error if the unit-level blocks are locked first: UVM_FATAL @ 0 ns: reporter [REG/MAP/UNMAPD] Address map "unit_regblk" in block "sys_regblk.unit_regblk" is not mapped in an address map in parent block of type "sys_regblk". A related question to this issue is why does VCS have this piece of code checking to see if a map has a parent map when it's not part of the official UVM-1.1 code? I've search the UVM git repository and can't seem to find anything related to this UNMAPD check that's in the UVM code distributed with VCS. Thanks, Steve
  3. I guess I thought it was a missing feature because in set_attribute it performs a call to uvm_radix_to_string so it could format the value correctly but then never uses it. Just seems weird to pass it a radix and have it pretty much ignore it. But either way, I don't know why I didn't think of overriding the default recorder. This workaround works fine for me. Thanks. Steve
  4. When transaction recording is enabled and logged to the tr_db.log file, all the values written are specified in decimal. The radix is printed along with the value, but the value is always in decimal. By the look of the uvm_recorder.svh file it appears that outputting the value in decimal is hardcoded: $fdisplay(file," SET_ATTR @%0t {TXH:%0d NAME:%s VALUE:%0d RADIX:%s BITS=%0d}", $time,txh, nm, (value & ((1<<numbits)-1)),radix.name(),numbits); Would it be possible to get the value printed in the specified radix instead of in decimal? I didn't see any open UVM issues regarding this, so I believe this would be a new change request. Steve
×
×
  • Create New...