Locking register blocks and building system-level register blocks.

[steveb]

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

[adielkhan]

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

[steveb]

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

[paragsathe]

Is there any specific reason locking should not be done in the Register model itself and done externally by the user?

[janick]

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.