Here’s a tips-n-tricks tidbit for the functional verification engineers in the crowd that are using UVM. You may have found yourself in this situation before, you’re using IP developed by somebody else and that person has deemed a certain UVM component within that IP untouchable by declaring it local. You really need access to that component though because you need to hack its state for a really, really good reason. Sure you could follow the advice of the original developer, leave the component local and find an appropriate work around. Or you could just disregard the fact that it’s local and hack it anyway.

Here’s the scenario… you’re using some other_guys_ip that has a secret_uvm_component. The secret_uvm_component has a special_property_that_should_never_change which is why the other_guys_ip has declared the secret_uvm_component local. You know better though because under some obscure_test_condition that only you know about, the special_property_that_should_never_change should actually be 61 instead of 71.

There it is… the secret_uvm_component is local so you can’t do anything with your obscure_test_condition because you don’t have access to the special_property_that_should_never_change… or do you?

Et voila! Using the lookup method to circumvent the access restrictions of the secret_uvm_component, you’re now free to hack the special_property_that_should_never_change as you see fit…

…not that I’d advocate doing that :)! I just find it ironic that with all the restrictions UVM imposes, it let’s you disregard access restrictions defined in Systemverilog without IP developers necessarily understanding it’s possible. I’m sure this type of thing exists in other libraries, not just UVM, so I’m not just trying to punch holes in the framework. I reckon it is the type of thing people should know about though instead of assuming local means local.

-neil