uvm_ config_ DB can be used in three ways
Pass the virtual interface to the environment p>
Set a single variable value, such as int.string.enum, etc p>
Pass the config object to the environment
Using UVM_ config_ Some suggestions are given as follows:
·When using the set/get method, the parameter types passed should be consistent up and down. For UVM_ If the get type is inconsistent with the set type, you should first complete the type conversion through $cast(), and then operate on the converted object p>
·The parameters passed by the set/get method can use the wildcard “*” to represent any level, similar to the usage of regular expressions. At the same time, users need to understand the difference between “*. Comp1” and “* Comp1”. The former means all components named “Comp1” under the current level, while the latter means all components named “Comp1” under the current level and below p>
·In the module environment, if you want to use UVM_ config_ DB:: set, then the first parameter UVM is passed_ Component cntxt is used to represent the current level. Because the current level is the highest level, the user can set it to null or UVM_ Root:: get() to represent UVM_ Global instance of root p>
·When using the configured variables, make sure that UVM is performed first_ config_ DB:: get operation, get the correct value, and then use it p>
·UVM should be ensured as much as possible_ config_ Db:: set method is called before its associated configuration component is created. This is because only after the configuration is carried out first, and its related components enter the build phase during instantiation, the expected value can be obtained p>
·For the same variable of the same instance component, if there are multiple upper level components setting the variable, the configuration of the higher level component will cover the configuration of the lower level component; However, if the same level component configures the variable multiple times, it should follow that the latter configuration will override the former one p>
·Users should be using UVM_ config_ When using the DB:: get() method, add a statement that is easy to debug to know whether the variables of the get method are from UVM by printing UVM information_ config_ If not, whether other measures need to be taken p>
As can be seen from the above example, the interface can be transferred from the hardware world to the UVM environment through UVM_ config_ DB. In the process of implementation, we need to pay attention to the following points:
·Interface should be passed in run_ Before test(). This ensures that the virtual interface has passed into UVM before entering build phase_ config_ DB p>
·Users should distinguish the declaration of interface from that of virtual interface. The type in passing should be virtual interface, which is the handle to the actual interface p>
Using UVM_ config_ When DB API set/get, the following background operations actually occur:
1. uvm_ config_ DB:: set places this information into UVM through hierarchy and variable name_ PKG unique global variable UVM_ pkg::uvm_ resources。 p>
2. Global variable UVM_ Resources is used to store and release resource information. uvm_ Resources is UVM_ resource_ The global unique instance of the pool class. In this instance, there are two resource arrays used to store the configuration information. One of the two arrays is indexed by the hierarchical name and the other is indexed by the type. Through these two associative arrays, you can store any configuration information through the hierarchy. At the same time, the low-level components can also get the high-level configuration information through the level or type. This method also completes the separation of information configuration and information acquisition, which is easy to debug and reuse p>
3. When using UVM_ config_ In the DB:: get method, the index level is formed by passing parameters, and then the index level is set in UVM_ This configuration is indexed in the existing configuration information pool of resource. If it is indexed, the method returns 1, otherwise it is 0 p>
How to use
h5>
uvm_ config_ db#(int)::set(this, “env.i_ agt.drv”, “pre_ num”, 100); p>
Four parameters: set to send and get to receive p>
The first and second parameters are combined to form the target path, and only the target corresponding to this path can receive the message. The first parameter must be a UVM_ The second parameter is the path relative to the component instance. The third parameter represents a token to indicate which member of the target the value is passed to, and the fourth parameter is the value to be set p>
uvm_ config_ db#(int)::get(this, “”, “pre_ num”, pre_ num); p>
Among the four parameters, the first parameter can be the pointer of “this”, “null” and other instances p>
The second parameter can be null “” or wildcard, such as the example in the screenshot, “* YY”_ agent” “yy_ agent.drv”
The first to third parameters of set and get “send” and “receive” must meet two conditions: the time matching must be sending the letter first and then receiving it. In order to avoid mistakes, it is generally best to judge before get, and the 2 marks are consistent, that is, the mail destination is matched p>
The third is often a parameter value, or handle p>
Similar Posts:
- UNREFERENCED_ The role of parameter
- [Solved] Java Call Error: java.lang.IllegalArgumentException: wrong number of arguments
- Fatal error: Call-time pass-by-reference has be…
- [Solved] IllegalArgumentException: object is not an instance of declaring class
- [Solved] CDH6.3.2 Hive on spark Error: is running beyond physical memory limits
- [Solved] Jupiter notebook failed to start Error: DLL load failed
- Oracle: db_12.2.0.1.0_Linux-x86-64: dbca Customized mode:ORA-07202: sltln: invalid parameter to sltln.
- Invalid prop: type check failed for prop value