Local UVM Components Aren’t Local

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.

Screen Shot 2013-01-24 at 12.19.09 PM

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?

Screen Shot 2013-01-24 at 12.19.19 PM

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.


About nosnhojn

I've been working in ASIC and FPGA development for more than 13 years at various IP and product development companies and now as a consultant with XtremeEDA Corp. In 2008 I took an interest in agile software development. I've found a massive amount of material out there related to agile development, all of it is interesting and most of it is applicable to hardware development in one form or another. So I'm here to find what agile concepts will work for hardware development and to help other developers use them successfully. I've been fortunate to have the chance to speak about agile hardware development at various conferences like Agile2011, Agile2012, Intel Lean/Agile Conference 2013 and SNUG. I also do lunch-n-learn talks for small groups and enjoy talking to anyone with an agile hardware story to tell! You can find me at neil.johnson@agilesoc.com.
This entry was posted in Functional Verification. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *