Jump to content
Sign in to follow this  
steveb

Locking register blocks and building system-level register blocks.

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×