white paper
Go figure – UVM configure: the good, the bad, the debug
Spanning module and testbench space
This paper will try to shed some light on the complexity and provide some useful code extensions for debug.
We will explore the UVM 1.1d config database implementation and theory with an effort to explaining the desired functionality to the new user, as well as clarifying how to best do debug when things go wrong. Additionally, UVM 1.1d to UVM 1.2 changes will be discussed, and a proposal for a simple, easier to understand and easier to debug implementation will be proposed.
The output from the instrumented code is demonstrated below. The UVM 1.1d output is listed and the enhanced UVM 1.1d output is listed. For UVM 1.1d, this output is generated by using UVM_CONFIG_DB_TRACE +UVM_RESOURCE_DB_TRACE during simulation.
Background
The UVM config database began life as a reimagined, re-implemented configuration database implemented in the OVM. The old version had limitations and was hard to use. The new UVM based implementation was imagined as a global database with a simple (name:value) lookup. As the integration into the UVM code stream began, forces worked to change the code, to layer it, and adapt it for certain poorly defined requirements. The changes made during this integration effort made the implementation more complex, and harder to understand.
The configuration database is best thought of as a global table of (name:value) pairs. You register a configuration name and value, like NUMBER_OF_TRANSACTIONS:1000 so that later other UVM testbench components can lookup NUMBER_OF_TRANSACTIONS and use the value returned accordingly. There is one global table which holds (name:value) pairs.