I want to access the UVM RAL model handle inside the testbench module to get the values of the register fields for writing the system verilog assertions.
I am getting compile error when I am trying to access the RAL model handle using the uvm_test_top hierarchy inside the Testbench top module as classes are not created at elaboration time.
Following is the code I have used to access the RAL handle inside the top testbench module.
Why do you want to use the RAL model in the toplevel module? There is your DUT instantiated and you can directly Access the Registers through the hierarchical path from this module.
The registers are placed at different hierarchies in the design and the number of registers which I need to use for the assertions are more than 100. I do’nt want to snoop the hierarchy for each of the signal . Every time there is a change in the design hierarchy , re-work will be required.
In reply to nvjoshi85:
OK, I understand.
Could you please explain in some more Details where and how do you implement your RL model in the toplevel module.
uvm_config_db::get() method is called inside the initial block to get the RAL handle after some random non-zero delay to allow the UVM hierarchy to be built-up as I have mentioned in the first post in this thread.
A good approach is to put the register model into a configuration object and passing this object to the config_db.
Then you can retrieve it in any place from the config_db. But you have to do the get after the set was executed.
BTW the lock_model should be in the register model. It is one of the last lines like this:
What kind of immediate assertions on the register content do you mean?
Also using concurrent assertions to check the register content is unclear to me.
Could you please elaborate something more?
I want to write concurrent assertions. Since we can’t do that in a class, so I want to access the reg model in my interface or a module. I want to use reg model to know the state of my DUT and then write assertions accordingly. For example, to see if interrupt is enabled by reading Interrupt enable register bit and then writing a check for the interrupt assertion. Something like this.
OK, I understand.
The UVM RAL is not a UVM component, i.e. it does not have certain position in the UVM hierarchy. It is common practice to put the UVM RAL as a n object into th config_db. Then you can retrive a handle to the RAL in any UVM component, also in an interface. But you have to consider that the class-based components an dobjects are constructed at runtime 0 and after the the staic components (modules, interfaces) have been instantiated.After the connect_phase the complete UVM environment is existing. In the end_elaboration_phase you could triger a uvm_event indivcating you are there and all class-based stuf does exist. Then you can retrieve in a module/interface the RAL handle.
Note it is a good coding practice to hold your concurrent assertions in a seperate module. Then you can bind a special module to your DUT registers using the bind construct. In this way you can also consider DUT register content.