Where to create regmodel? ...in the test or the env?

[mooredan]

Hi all.  This is my first post here and I'm learning UVM, but I'm not new to verification or SystemVerilog.

I've seen three examples of integrating uvm_reg_block objects into a test bench. two of them (jellybean and verificationacademy) create the extended uvm_reg_block  object in the test object, whereas doulos creates it in the top level env (above the agent env). 

For a hierarchical point of view, the latter location seems to make the most sense. However, it seems that there's a bunch of hoops to jump through to get it working.  From a ease of use sense, creating it in the test object (as long as you have a base test class from which all others are derived) gets around the struggles (at least the ones that I have had) with getting the right regmodel handle passed around to where it is needed.    ...and the traditional non-register-model test/sequence building/flow works because it is the test that sets the regmodel handle in the sequence after it is created.

The question that I have (and I might be opening up a can of worms here) is what is the consensus on where in the test bench hierarchy is the regmodel object built?   What pitfalls might I face later on down the road if I choose one methods over the other?  Thanks for you insight.

 

Dan Moore - Principal Engineer - Rohde & Schwarz, USA, Inc.

[Amit K Jain]

Hi Dan,

I have created a register layering example and I preferred to create object of class extended from "uvm_reg_block" in test.
As you mentioned, this provided me flexibility to pass references around between reg block and reg adapter, reg predictor and reg sequence.

While thinking of moving reg block to env class, ease of use or other issues would really depend on your use model.
Communication between reg block and adapter, predictor can be done in env class connect phase as well (You can move adapter, predictor handles creation as well in the env class).
If you are looking to keep reg block in test base and then use that in extended test class of different tests, I could see use of that in passing reg block to reg sequences.
But that could as well be achieved by passing uvm_reg_block class handle to uvm_resource_db and then access that from reg sequence.

So I think both the way should be OK (Though I haven't tried having reg block in env class yet, but if there is any specific pitfall then some expert on this forum could help us).
I preferred to have in test class, as I like having direct dotted access to refer objects rather than pass using uvm config or resource db.

I am not sure if I could help you much using above answer, but please let me know and I can provide you reference with example code snippets if needed.

Thanks,
Amit

[c4brian]

In the Mentor cookbook, they create it in the test, and then pass a handle to the env config object.

This resource is typically used by the sequence (also in test) so the structure is fine with me.

The use model is that you'll need to have a RAL declared for block, sub-system, and SoC levels.  This way you can specify offset for sub-level register blocks, hdl path slices for backdoor access (optional), etc.

 

[Xinwei]

Considering the block env reuse scenario, it's better to set the reg_model in test because the block level reg_model register address map could be changed after integrated to partial level or top level testbench and may have multiple instances. So be sure your block level env only create a reg_model by itself when it cannot find one from config db if you like reg_model be instanced in env.