steveb Posted May 11, 2012 Report Share Posted May 11, 2012 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 Quote Link to comment Share on other sites More sharing options...
adielkhan Posted May 12, 2012 Report Share Posted May 12, 2012 hi, Locking is done by the root block, recursively and that must be called by the user, never internally by the genrated uvm_reg model. It should be called after all the maps are setup. The FATAL (which will be downgraded to Warning to allow for incorrect usage from non-Ralgen created uvm_reg models) is to prevent users from writing incorrect RALF files which can lead to runtime errors much later in the simulation like “UVM_FATAL @ 100: reporter@@write_item [sTRITM] sequence_item has null sequencer†-adiel Quote Link to comment Share on other sites More sharing options...
steveb Posted May 14, 2012 Author Report Share Posted May 14, 2012 hi, Locking is done by the root block, recursively and that must be called by the user, never internally by the genrated uvm_reg model. It should be called after all the maps are setup. The FATAL (which will be downgraded to Warning to allow for incorrect usage from non-Ralgen created uvm_reg models) is to prevent users from writing incorrect RALF files which can lead to runtime errors much later in the simulation like “UVM_FATAL @ 100: reporter@@write_item [sTRITM] sequence_item has null sequencer” -adiel 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 Quote Link to comment Share on other sites More sharing options...
paragsathe Posted September 28, 2012 Report Share Posted September 28, 2012 Is there any specific reason locking should not be done in the Register model itself and done externally by the user? Quote Link to comment Share on other sites More sharing options...
janick Posted September 28, 2012 Report Share Posted September 28, 2012 Because it has to be done once all of the maps are loaded and from the top-most block only because it builds the address-to-register index for all top-level address maps. 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.