Learning Objectives: Master the write register model while integrating it into a verification environment
Table of contents
1.1 Implementation of the small unit reg in the register model
1.2 Implementation of the register model register model (rgm)
2. Integrate the written register model into the environment
3. Change the method of sending sequence through the bus to send through the register model
1. Write register model
A complete register model includes registers, register blocks, adapters, and predictors. We can write a package separately to include the first three parts. The three of them inherit from uvm_reg, uvm_reg_block, and uvm_reg_adapter in the UVM package. Note that these three are all objects, not in the component tree of uvm ;
Taking MCDF as an example, we define
The control register ctrl_reg and the status register stat_reg inherit from the register uvm_reg;
The register model mcdf_rgm inherits from the register block uvm_reg_block;
The adapter reg2mcdf_adapter inherits from uvm_reg_adapter;
1.1 Implementation of the small unit reg in the register model
In reg, we need to complete the domain division and coverage collection control. That is, we need to divide a 32-bit register into different domains to represent different functions. Different domains are declared through uvm_reg_field (a class inherited from uvm_object). In MCDF, the domains of the control register are divided as follows
Then we need to complete the creation of the fields we declared in the build function (uvm_reg comes with it) (UVM’s regular create creation method), and then assign different bits to different fields through configure (uvm_reg comes with it). Since then, we have completed the division of the most important fields in writing reg.
The second important part is coverage collection. The sample function that comes with uvm will be called automatically when we read and write registers through the register model, that is, automatically collect coverage. We need to define the coverage, and then define the sample function; define a coverage group, and define different coverage points through coverpoint;
Then set a switch in the new function, has_coveragre, you can choose whether to enable coverage measurement;
The last definition of reg is sample;
The definitions of the status registers are similar and will not be repeated here.
1.2 Implementation of the register model register model (rgm)
If we have defined various registers reg, then we need a unified carrier to store them, and also need a class uvm_reg_map (a class inherited from uvm_object) that can identify its location. With map, we can store various registers in rgm, and at the same time find their location conveniently;
We build it in the same function build, create each reg in it, and then set the current reg to mount on this register model through the upper configure (note that this is the configure method of the reg register, not the configure of uvm_reg_field, see the note at the bottom of the article for details) and call the build of the lower layer reg to complete the configuration;
Then there is the implementation of map, through create_map (a function that comes with uvm_reg_block, and the add_reg that comes with the register block, which are preset by UVM in order to facilitate the construction of register maps in register blocks), so far we have completed placing registers in register blocks, and at the same time drew a map for our search. We can find the corresponding registers in the register model through the map and access the registers through the front door.
Finally, in order to achieve backdoor access, we also need to add a shortcut path to achieve, the specific code is as follows, they are realized through the function add_hdl_path_slice that comes with uvm_reg and the function add_hdl_path that comes with uvm_reg_block.
1.3 Implementation of adapter
The data we output through the register model cannot be directly sent to the bus, because the data types are different (bus transactions are different according to different bus protocols, but reg trans is fixed), so we need to introduce an adapter between the register model and the bus to complete the conversion of data types.
So far, we have established the register model, completed the creation of registers, the division of domains and the definition of coverage groups, and then added registers to the register block, and drew a map for register addressing. Upwards we define the adapter, which is used to realize the data type conversion when the data is transmitted to the bus.
2. Integrate the written register model into the environment
In the environment env, we instantiate the register block rgm and the adapter adapter, and at the same time we make up the last piece of the puzzle predictor for the register model
Then we create the three parts of the register model in build_phase;
Then connect the adapter to the sequencer in the connect_phase; then connect the port receiving the transaction on the register monitor to the bus_in (responsible for receiving data from the bus port), connect the map and adapter of the predictor to the corresponding part, or connect the handle, so that the data members of the adapter and map can be accessed in the predictor;
So far, we have completed the declaration, creation and connection of the three parts of the register module in env. The most important connection is the connection between the predictor and both ends. One end is the register model end, that is, the handles of the map and adapter are passed to the predictor (both the map and the adapter need to be bound together on the sqr in advance), and the other end is the bus end, which is realized through ana_port. Finally, the rgm handle is passed to virt_sqr for top-level control.
3. Change the method of sending sequence through the bus to send through the register model
If you want to use the register model to send transactions in the sequence, you need to declare rgm in the sequence, and at the same time implement the connection with sqr in the body of the sequence;
Then we can implement register access from the register model side in do_reg, a task that specifically sends register transactions, through rgm.reg.write()/read(); note that status indicates the current state of the register (see the note at the end of the article for details);
The expected value is the value we want the registers in the DUT to achieve, and the mirrored value is used for the greatest possible synchronization with the actual value. The wr_val and rd_val read and written above are the values we expect, and the actual value of the register can be changed to the value we expect through the bus. But if we want to modify a single domain, we can also try another method, through set and update.
That is, we set the expected value to 1 through set, and then call update. UVM will check whether the expected value and the mirror value are equal. If they are not equal, they will input 1 in the DUT and update the mirror value (these two methods are used in the current lab, and both need to be learned);
If we have completed reg.set(); and reg.update(); we can also do another check and do reg.mirror() through the back door, which will read back the hardware value and update the mirror value at the same time. Of course, we have already updated through the front door update, and it will be more perfect if we do a back door check;
4. Use the sequence that comes with the register model to complete the routine verification of the register
This small experiment only needs our body() inside the virtual sequence or hierarchical sequence; the following example creates the seq that comes with the corresponding register model;
Then complete the binding of seq and the register model (specify who the rgm of the seq application is through the model, see the note at the end of the article for details), and then call start;
Difficulties:
1. Adapter and rgm are uvm_object types, why use the same creation method as predictor? The predictor is a component!
In fact, this can be added or not when creating an object;
to add on:
1. The configure method of uvm_reg (above) and the configure method of uvm_reg_field (below) are different
2. uvm_status_e
3.model
