Sie sind auf Seite 1von 15

5/2/2017 UVMTutorialforCandyLovers24.

RegisterAccessthroughtheBackDoorClueLogic Welcome to ClueLogic

ClueLogic Search... Search

Provi d i n g t h e c l u es to solve your verication problems


Home Services Events ClueBlog About

ClueLogic > UVM > UVM Tutorial for Candy Lovers 24. Register Access through the Back Door

UVM Tutorial for Candy Lovers 24. Register Access through the Back Door
September 14, 2014 Keisuke Shimizu

Last Updated: February 14, 2015 (xed broken EDA Playground link)

This post will add back-door access to the registers dened in Register Abstraction. With a few additional lines of code, you can access the registers through the back door.

We use the same DUT (jelly_bean_taster) as dened in Register Abstraction. The DUT has two registers as shown below.

DUT Registers

The DUT denes each eld of the registers as reg (lines 4 to 8).

1 modulejelly_bean_taster(jelly_bean_if.slave_mpjb_if);
2 importjelly_bean_pkg::*;
4 reg[1:0]taste;//TASTEregister
5 reg[2:0]flavor;//RECIPEregister
6 reg[1:0]color;
7 regsugar_free;
8 regsour;
10 reg[1:0]command;
12 initialbegin
13 flavor=0;
14 color=0;
15 sugar_free=0;
16 sour=0;
17 command=0;
18 taste=0;
19 end
21 always@(posedgejb_if.clk)begin
22 if(jb_if.command==JB_WRITE)begin
23 flavor<=jb_if.flavor;
24 color<=jb_if.color;
25 sugar_free<=jb_if.sugar_free;
26 sour<=jb_if.sour;
27 endelseif(jb_if.command==JB_READ)begin
28 jb_if.taste<=#2nstaste;
29 end
30 end
32 always@(posedgejb_if.clk)begin
33 if(jb_if.flavor==CHOCOLATE&&jb_if.sour)taste<=YUCKY;
34 elseif(jb_if.flavor!=NO_FLAVOR)taste<=YUMMY;
35 end
37 endmodule:jelly_bean_taster 1/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic

The top-level testbench instantiates the jelly_bean_taster as the dut (line 6).

1 moduletop;
2 importuvm_pkg::*;
4 regclk;
5 jelly_bean_ifjb_if(clk);
6 jelly_bean_tasterdut(jb_if);//DUT
8 initialbegin//clock
9 clk=1;
10 forever#5nsclk=!clk;
11 end
13 initialbegin//waveform
14 $dumpfile("dump.vcd");
15 $dumpvars(0,top);
16 end
18 initialbegin
19 uvm_config_db#(virtualjelly_bean_if)::set(.cntxt(null),
20 .inst_name("uvm_test_top*"),
21 .field_name("jb_if"),
22 .value(jb_if));
23 run_test();
24 end
25 endmodule:top

Register Block
To access the DUT registers through the back door, we need to inform the register block about its corresponding HDL path (line 27). In our case, the hierarchical HDL path
corresponding to the register block is "top.dut".

1 classjelly_bean_reg_blockextendsuvm_reg_block;
2 `uvm_object_utils(jelly_bean_reg_block)
4 randjelly_bean_recipe_regjb_recipe_reg;
5 randjelly_bean_taste_regjb_taste_reg;
6 uvm_reg_mapreg_map;
8 functionnew(stringname="jelly_bean_reg_block");
10 endfunction:new
12 virtualfunctionvoidbuild();
13 jb_recipe_reg=jelly_bean_recipe_reg::type_id::create("jb_recipe_reg");
14 jb_recipe_reg.configure(.blk_parent(this));
17 jb_taste_reg=jelly_bean_taste_reg::type_id::create("jb_taste_reg");
18 jb_taste_reg.configure(.blk_parent(this));
21 reg_map=create_map(.name("reg_map"),.base_addr(8'h00),
22 .n_bytes(1),.endian(UVM_LITTLE_ENDIAN));
23 reg_map.add_reg(.rg(jb_recipe_reg),.offset(8'h00),.rights("WO"));
24 reg_map.add_reg(.rg(jb_taste_reg),.offset(8'h01),.rights("RO"));
26 //forbackdooraccess
27 add_hdl_path(.path("top.dut"));
29 lock_model();//finalizetheaddressmapping
30 endfunction:build
31 endclass:jelly_bean_reg_block

We also need to inform each register abstraction class about the HDL path to the register eld (line 31). In our case, the taste register eld corresponds to the taste reg

1 classjelly_bean_taste_regextendsuvm_reg;
2 `uvm_object_utils(jelly_bean_taste_reg)
4 randuvm_reg_fieldtaste;
6 //
7 //Function:new
8 //
10 functionnew(stringname="jelly_bean_taste_reg");
12 endfunction:new
13 2/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
14 //
15 //Function:build
16 //
18 virtualfunctionvoidbuild();
19 taste=uvm_reg_field::type_id::create("taste");
20 taste.configure(.parent(this),
21 .size(2),
22 .lsb_pos(0),
23 .access("RO"),
24 .volatile(1),
25 .reset(0),
26 .has_reset(1),
27 .is_rand(0),
28 .individually_accessible(0));
30 //forbackdooraccess
31 add_hdl_path_slice(.name("taste"),.offset(0),.size(2));
32 endfunction:build
33 endclass:jelly_bean_taste_reg

We set the HDL paths to the RECIPE register, too (lines 66 to 69). In this case, we add four HDL paths (one path per DUT reg).

1 classjelly_bean_recipe_regextendsuvm_reg;
2 `uvm_object_utils(jelly_bean_recipe_reg)
4 randuvm_reg_fieldflavor;
5 randuvm_reg_fieldcolor;
6 randuvm_reg_fieldsugar_free;
7 randuvm_reg_fieldsour;
9 constraintflavor_color_con{
10 flavor.value!=NO_FLAVOR;
11 flavor.value==APPLE>color.value!=BLUE;
12 flavor.value==BLUEBERRY>color.value==BLUE;
13 flavor.value<=CHOCOLATE;
14 }
16 functionnew(stringname="jelly_bean_recipe_reg");
18 endfunction:new
20 virtualfunctionvoidbuild();
21 flavor=uvm_reg_field::type_id::create("flavor");
22 flavor.configure(.parent(this),
23 .size(3),
24 .lsb_pos(0),
25 .access("WO"),
26 .volatile(0),
27 .reset(0),
28 .has_reset(1),
29 .is_rand(1),
30 .individually_accessible(0));
32 color=uvm_reg_field::type_id::create("color");
33 color.configure(.parent(this),
34 .size(2),
35 .lsb_pos(3),
36 .access("WO"),
37 .volatile(0),
38 .reset(0),
39 .has_reset(1),
40 .is_rand(1),
41 .individually_accessible(0));
43 sugar_free=uvm_reg_field::type_id::create("sugar_free");
44 sugar_free.configure(.parent(this),
45 .size(1),
46 .lsb_pos(5),
47 .access("WO"),
48 .volatile(0),
49 .reset(0),
50 .has_reset(1),
51 .is_rand(1),
52 .individually_accessible(0));
54 sour=uvm_reg_field::type_id::create("sour");
55 sour.configure(.parent(this),
56 .size(1),
57 .lsb_pos(6),
58 .access("WO"),
59 .volatile(0),
60 .reset(0),
61 .has_reset(1),
62 .is_rand(1),
63 .individually_accessible(0));
65 //forbackdooraccess
66 add_hdl_path_slice(.name("flavor"),.offset(0),.size(3));

67 add_hdl_path_slice(.name("color"),.offset(3),.size(2)); 3/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
67 add_hdl_path_slice(.name("color"),.offset(3),.size(2));
68 add_hdl_path_slice(.name("sugar_free"),.offset(5),.size(1));
69 add_hdl_path_slice(.name("sour"),.offset(6),.size(1));
70 endfunction:build
71 endclass:jelly_bean_recipe_reg

Thats about all you need. Lets test the back door.

Register Sequence
This sequence demonstrates several ways to access the registers through the back door. As a refresher, we access the registers through the front door rst.

1. The line 24 uses the write_reg task of the uvm_reg_sequence class to write to the RECIPE register.
2. The line 27 uses the read_reg task of the uvm_reg_sequence class to read from the TASTE register.

Then, we write the RECIPE register through the back door in three dierent ways.

1. The line 32 uses the poke_reg task of the uvm_reg_sequence class.

2. The line 36 uses the write_reg task of the uvm_reg_sequence class with the UVM_BACKDOOR option.
3. The line 41 uses the write task of the uvm_reg class with the UVM_BACKDOOR option.

Similarly, we read the TASTE register through the back door in three dierent ways.

1. The line 46 uses the peek_reg task of the uvm_reg_sequence class.

2. The line 49 uses the read_reg task of the uvm_reg_sequence class with the UVM_BACKDOOR option.
3. The line 52 uses the read task of the uvm_reg class with the UVM_BACKDOOR option.

1 classjelly_bean_reg_sequenceextendsuvm_reg_sequence;
2 `uvm_object_utils(jelly_bean_reg_sequence)
4 functionnew(stringname="");
6 endfunction:new
8 virtualtaskbody();
9 jelly_bean_reg_blockjb_reg_block;
10 flavor_eflavor;
11 color_ecolor;
12 bitsugar_free;
13 bitsour;
14 uvm_status_estatus;
15 uvm_reg_data_tvalue;
17 $cast(jb_reg_block,model);
18 flavor=APPLE;
19 color=GREEN;
20 sugar_free=0;
21 sour=1;
23 //frontdoorwrite
24 write_reg(jb_reg_block.jb_recipe_reg,status,{sour,sugar_free,color,flavor});
26 //frontdoorread
27 read_reg(jb_reg_block.jb_taste_reg,status,value);
28 #20ns;
30 //backdoorwrites
31 flavor=BLUEBERRY;
32 poke_reg(jb_reg_block.jb_recipe_reg,status,{sour,sugar_free,color,flavor});
33 #10ns;
35 flavor=BUBBLE_GUM;
36 write_reg(jb_reg_block.jb_recipe_reg,status,{sour,sugar_free,color,flavor},
38 #10ns;
40 flavor=CHOCOLATE;
41 jb_reg_block.jb_recipe_reg.write(status,{sour,sugar_free,color,flavor},
42 UVM_BACKDOOR,.parent(this));
43 #10ns;
45 //backdoorreads
46 peek_reg(jb_reg_block.jb_taste_reg,status,value);
47 assert(value==YUMMY);
49 read_reg(jb_reg_block.jb_taste_reg,status,value,UVM_BACKDOOR);
50 assert(value==YUMMY);
53 assert(value==YUMMY);
54 #10ns;
55 endtask:body
57 endclass:jelly_bean_reg_sequence 4/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic

Here is an annotated waveform. The front-door access uses the jb_if, whereas the back-door access directly updates the register value of the DUT. Note that back-door
writing CHOCOLATE to the flavor eld does not update the taste eld of the DUT even though the DUT is supposed to respond YUCKY to the combination of sour and
CHOCOLATE. This is because the DUT updates the taste eld in response to the value on the jb_if, but not to the internal RECIPE register values.

Annotated Waveform

You can view and run the code on EDA Playground.

Share this:

LinkedIn 29 Facebook 2 Google Twitter Email Print

Like this:


UVM UVM_BACKDOOR, uvm_reg, uvm_reg_block, uvm_reg_data_t, uvm_reg_eld, uvm_reg_sequence, uvm_status_e

UVM Tutorial for Candy Lovers 23. Jelly Bean Taster in UVM 1.2 Hidden Gems of SystemVerilog 1. Compilation unit scope

44 thoughts on UVM Tutorial for Candy Lovers 24. Register Access through the Back Door

taahir says:
September 16, 2014 at 1:23 am
Great work.Hope you may start tutorial on SV 5/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic


Keisuke Shimizu says:

September 21, 2014 at 11:11 am

Thank you for your comment. Several people have asked me a SystemVerilog tutorial. I am planning it, so stay tuned!


Avinash says:
September 21, 2014 at 10:38 pm

Ya. I will be waiting for your SV tutorial too. Thanks.


Avinash says:
September 16, 2014 at 11:25 pm


Thanks for your article on the back door. I am curious to know what is the use case of back door register access. Actually i am new to uvm and ramping on uvm
RAL. If there is a status register in dut whose value change due to some input, I can equally change the status register vlaue in register model by accessing the
register from the model in tb using get_reg_by_name for a particular register.
So I am bit confused as to how and why to use the back door.

Question2: If via a interface I change the register value then in the model which value get updated desired or mirror value or both? My requirement is to write
into register and read back and compare the read value to reference value which was written earlier.


Avinash says:
September 17, 2014 at 1:21 am

Question3 : I have a generic question on the write functions to write. Is it always I need to use this function to write into register in dut and update the
data in register model. I mean I have a adapter and I send a I2C write into a register via driver. So will the equvivalent register not get update in the
register model? if reg data is updated Will the update be for desired and mirror value in model. Just curious to know if I always need write read and
update functions to update data in model.



Keisuke Shimizu says:

September 21, 2014 at 12:20 pm

If you connect a uvm_reg_predictor to your I2C monitor, the desired and mirrored values of the model are updated at every I2C
read/write regardless of accessing the register by RAL functions or not, because the monitor captures all I2C transactions.
If you use your_reg_map.set_auto_predict(.on(1)), the values of the model will be updated only when you use RAL read/write.


Avinash says:
September 21, 2014 at 11:26 pm


Thanks for your inputs.

I have a particular register write read scenario : 6/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
When I send 2 commands then a register is addressed and next 8 bits data is written into this register in DUT. Now how should I
write the regsiter denition for this register in RAL?
Usually I used to have one command and data. The command is the address of register and data is stored of this register.
I am not able to get how to implement RAL register defn. for this kind of register.
I mean address denition of this register in RAL.

Please help.



Keisuke Shimizu says:

September 27, 2014 at 12:58 pm

I think you can dene the registers in RAL as if you directly access them. Then, one solution would be to implement a
register adapter that converts a register read/write into two bus transactions (one for a command and the other for data),
and vice versa. Let me put this into my To Do list of future articles.

Keisuke Shimizu says:

September 21, 2014 at 11:48 am

1. You can use the back-door to peek the value of registers in a DUT for the purpose of debugging or controlling a test-bench based on the peeked
value. You could also use the back-door to initialize a large set of registers in a DUT, if doing so through the front-door takes too long.
2. If you write a register through the front-door, both desired and mirrored values are updated. Please see Register Access Methods for more detail.


Avinash says:
September 22, 2014 at 4:50 am

Clarication : So you can only peek(quickly see) the data from the DUT register via back door and you cannot modify the data in that register
via back door.
Am I right ?



Keisuke Shimizu says:

September 27, 2014 at 11:27 am

You can do both peek (read) and poke (write) through the back door.


Euphemia says:
September 22, 2014 at 12:38 pm

Hi Shimizu,

Thank you for writing such a great article about backdoor access. Im new to UVM and just started to implement backdoor access on both register block level
and register level.

I have a question about if it possible for me to implement backdoor write on each bit of a register. I want to implement a bit bash test on several registers in
UVM using backdoor access instead of using .start() to use apb bus and master sequencer. Is it possible? I didnt nd out any way to access each bits on
registers right now.

Thank you.
Euphemia 7/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic


Keisuke Shimizu says:

September 27, 2014 at 11:45 am

As far as I know the smallest unit you can peek/poke is a uvm_reg_eld, but not a bit.


yorams70 says:
December 21, 2014 at 4:04 am

I need to use the registers le in 2 contexts:
1. In the block level simulation.
2. In the fullchip simulation.

The path of the registers block is dierent in each context.

How do you advise to set the hdl path?

Can the add_hdl_path() method get a variable argument?
Should I use `ifdef to distinguish between the 2 contexts?



Keisuke Shimizu says:

January 25, 2015 at 11:37 am

I think the easiest way would be using the set_hdl_path_root function of the uvm_reg_block to specify the absolute HDL path to the registers. For
example, you can set the block-level path as jb_reg_block.set_hdl_path_root("dut"), whereas you can set the chip-level path as something like


Shreemant says:
December 24, 2014 at 1:07 am

Hello Keisuke Shimizu,

I am getting an error while accessing dutregister via backdoor as :-

UVM_ERROR: get: unable to locate hdl path dut.avor

# Either the name is incorrect, or you may not have PLI/ACC visibility to that name

I have even used the set_backdoor method within the register model but If I use it I am getting the error
UVM_FATAL verilog_src/uvm-1.1d/src/reg/uvm_reg_backdoor.svh(329) @ 0: reporter [RegModel] uvm_reg_backdoor::write() method has not been overloaded

whenever I am using any access method from the sequence.

What can be the probable issue?

Thanks in advance.



Shreemant says:
December 24, 2014 at 4:27 am
Hello, 8/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
I got the issue resolved, Actually you have instantiated the DUT as dut in module top, however when you are setting the path in add_hdl_path method its just
written as dut, this gives the error

UVM_ERROR: get: unable to locate hdl path dut.avor

# Either the name is incorrect, or you may not have PLI/ACC visibility to that name

Actually it should be top.dut .

Please correct me if I am wrong.

Thanks & Regards



Keisuke Shimizu says:

January 25, 2015 at 2:05 pm

Hi Shreemant,

You are right. I have corrected the path. Thank you for pointing this out.


Loren says:
January 21, 2015 at 2:28 pm

Hi Keisuke San,

I have a question on how to integrate the mulitple env together. For example, I have a spi env, and a gpio env. Each of them has there regmodel and adapter.
When I have created a top_reg_model to include spi_regmodel and gpio_regmodel, and I used map.add_submap to properly pass the oset to the, and gpio_regmodel. If I already have a spi_reg_test_seq which call reg_write(spi_regmodel.spi0, ), is there a way to reuse the test for my
top_reg_model? Or do I need to rewrite to
reg_write(top_reg_model.spi_regmodel.spi0, .)?

Many thanks.



Keisuke Shimizu says:

January 25, 2015 at 4:15 pm

You dont need to modify the sequences at all. I assume your spi_reg_test_seq is a subclass of the uvm_reg_sequence. In your SPI test, you probably
did something like:


If you modify this to something like:


you should be OK.


Loren says:
January 27, 2015 at 12:07 pm

Keisuke san,

Great. Many thanks.

Reply 9/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic

Jean-Luc says:
January 28, 2015 at 12:45 am

Thank you for this very interesting tutorial.
I am experimenting backdoor write access in my reg_model. It works ne for all registers that have a 0 reset value, but not for registers that have a non-zero
value (reset eld set to e.g. h86, has_reset eld set to 1). For these registers, the backdoor read access works ne, but the backdoor write access leads to a
wrong value. It seems the force applied on the backdoor is incorrect.
Are you aware of known limitations with non-zero reset ? Am I missing some conguration somewhere ?
Any help is appreciated. Thank you.


Keisuke Shimizu says:

January 28, 2015 at 9:51 am

Having non-zero reset value should not aect the behavior of the back-door write. I changed my candy example to have a non-zero reset value, but
both back-door read and write seemed to be ne. How did you know the back-door write did not work? By looking at the waveform? If you can post
the read/write procedure you used, I might be able to gure out.


Jean-Luc says:
January 28, 2015 at 11:27 am

Well. I have investigated this a bit further and it appeared that everything was correct until the call to uvm_hdl_deposit. And in fact, the
problem is related to the simulation tool I am using (QuestaSim) and from the fact that the DUT is written in VHDL using std_ulogic_vector
type. Changing to std_logic_vector solved the bug, but that was not acceptable for us. Changing the default radix for waveforms from
hexadecimal to binary (sic!) magically solved the backdoor problem (I would not have imagined this without the help of Mentor support).
In the end, registers with a null reset value were passing my tests even with a wrong backdoor access. I would have found this only much
later if all registers were reset to zero. Thats why annoys me most.
The positive side is that I had to dig a little bit in the UVM code. Sometimes it is as valuable as text books !


Kousik says:
February 9, 2015 at 4:28 am

hi ,
thank you for this valuable tutorial..i am getting error to run this codewhat should i do?.


Attempting to place a value into top.dut.avor which does not have write access.
./, 9:
Attempting to place a value into top.dut.color which does not have write access.
./, 10:
Attempting to place a value into top.dut.sugar_free which does not have write access.
./, 11:
Attempting to place a value into top.dut.sour which does not have write access.

in reg denition le
virtual function void build();
avor = uvm_reg_eld::type_id::create( avor );
avor.congure( .parent ( this ),
.size ( 3 ),
.lsb_pos ( 0 ),
.access ( WO ), //this is write accessible
.volatile ( 0 ),
.reset ( 0 ),
.has_reset ( 1 ), 10/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
.is_rand ( 1 ),
.individually_accessible( 1 ) );

color = uvm_reg_eld::type_id::create( color );

color.congure( .parent ( this ),
.size ( 2 ),
.lsb_pos ( 3 ),
.access ( WO ), //this is write accessible
.volatile ( 0 ),
.reset ( 0 ),
.has_reset ( 1 ),
.is_rand ( 1 ),
.individually_accessible( 1 ) );


Keisuke Shimizu says:

February 14, 2015 at 12:00 pm

Try this option, access+rw, when you run a simulation.


Kousik says:
February 17, 2015 at 10:45 pm

thanks for your works please elaborate more operation with example like mirror(),update() etc

thanks again for this most useful tutorial


Keisuke Shimizu says:

February 19, 2015 at 9:46 am

The mirror and update methods are explained in Register Access Methods. If you need more clarication, please let me know.


Kousik says:
February 19, 2015 at 9:05 pm

i got little bit idea from Register Access Methods .But i want some sort of coding example as you describe for backdoor operation.



Keisuke Shimizu says:

March 22, 2015 at 6:21 pm

This is one way of writing to a register in the DUT.


You can do the same thing with the update task.

jb_reg_block.jb_recipe_reg.update(status); 11/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic
One dierence is that if the mirrored value of the register model is equal to the value specied by the set function, the update task
wont write to the register in the DUT (because RAL assumes the DUT already has that value). On the other hand, the write task
always writes to the DUT regardless of the specied value.

Similarly, this is one way of reading from a register in the DUT.,value);

You can do the same thing with the mirror task.


Both the read and mirror tasks always read from the DUT. You can check the read value against the current mirrored value if
check is UVM_CHECK. Default is UVM_NO_CHECK.



Piyush Dodiya says:

May 6, 2015 at 4:23 am

Hi Keisuke,

Thanks for to the point explanation. Rally such a nice articles this one and Register Access Methods. Actually, I am new to the RAL and went through UVM user
guide, Reference manual and src/reg/* les but nally I satised with these articles presented over here on RAL.

Thanks once again. And keep writing


Thiru says:
August 4, 2015 at 7:02 am

Hi Keisuke,
I need your help in implementing I2C protocol based Register write and read functions using UVM. I think bus2reg and reg2bus functions should be changed.
Apart from these changes what else should be implemented. Please me out, how to proceed?



Keisuke Shimizu says:

September 7, 2015 at 2:11 pm

If you already have the transaction, driver, sequencer, and monitor for the I2C, you are pretty much ready to go once you implement the reg adapter.
Let me know if you have further questions.


Harshit says:
October 8, 2015 at 11:30 am

Hi Keisuke,

I am learning UVM RAL and found your tutorials are giving me a great help to understand quickly. On the backdoor access I have a doubt,

Suppose My testbench components are packed in test_pkg and this package is imported inside TOP module where DUT and Interfaces are instantiated. Our
UVM_RAL is also inside in test_pkg. Now to give backdoor access to UVM_RAL, weve to provide direct RTL submodule path from TOP, but as per my knowledge
we cant access the RTL hierarchy from package. So in that case how can we use RAL?

Harshit 12/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic


Keisuke Shimizu says:

December 27, 2015 at 11:41 am

Sorry for the slow reply. Since we add the HDL path as a string, not directly accessing the module hierarchy, you should be able to specify the path
from within a package.


krishna says:
October 28, 2015 at 3:54 am

while implementing reg model i got several run time errors what could be the reason ??

UVM_INFO @ 0: reporter [RNTST] Running test hpdmc_base_test
# include_coverage not located
# did you mean cvif?
# did you mean dvif?
# include_coverage not located
# did you mean cvif?
# did you mean dvif?
# UVM_ERROR C:/questasim_10.0b/uvm-1.0p1/uvm_pkg/reg/uvm_reg.svh(1239) @ 0: reporter [RegModel] Field cke_control overlaps eld reset in register


// uvm_reg_fieldbypass_en//bypassmodeenable





Remaining things done at nxt class which is not included in this code


Keisuke Shimizu says:

October 28, 2015 at 5:24 pm

The configure function takes parent, size, lsb_pos, etc. as the arguments in this order. Your code congures the reset to be at the bit 1 of sys_reg
and the cke_control to be at bit 1 and 0. The overlapped bit 1 caused the UVM_ERROR. 13/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic


Dam Bui says:

December 4, 2015 at 11:17 am

Hi Keishuke-san,

I have question/comment on the hdl_path_slice specication that associates a register eld with a DUT reg.
It seems to me it would make more sense for it to be done at the instantiation of the register in reg_block and not in the denition of the register.
I have a situation where the same register layout to be used multiple times in the register map.
I will have one register denition and instantiate it as many times as I need within a loop in the reg_block.
I do not have a one to one association between the register eld denition and the DUT reg.

Am I seeing this correctly? If so, is there a way to get around this?



Keisuke Shimizu says:

December 27, 2015 at 11:03 am

You dont have to call the add_hdl_path_slice from within the register model. In my new article, Backdoor HDL Path, I moved up the
add_hdl_path_slice to the test level. As long as you have a physical register that corresponds to the model, you should be able to specify the HDL


ravig says:
December 7, 2015 at 3:46 am

Great job



December 10, 2015 at 4:08 am

What is the use of add_submap when you have create_map

Also clarify what is meant by default_map


Keisuke Shimizu says:

December 13, 2015 at 1:20 pm

Suppose you have a register block (blk_a) that has two sub-register blocks (blk_b and blk_c). Like the add_reg() adds a register to a register map,
the add_submap() adds a register map to its parent register map (see the gure below).

The default_map is used if no register map is specied for a register operation such as read() and write(). If you do not assign the default_map,
the rst register map created for a register block is assigned to the default_map. 14/15
5/2/2017 UVMTutorialforCandyLovers24.RegisterAccessthroughtheBackDoorClueLogic



December 14, 2015 at 10:33 pm

Hi Shimizu,
Thanks for your explanation.
I have one more doubt regarding backdoor access
I have one IP where the registers are not in one le and they are scattered
All these registers are brought into some module using its input wires
If both the register elds and the register available in the same module (or le.v) i can specify the path
If the register elds are coming from dierent modules, then how shall i specify the hierarchical path

Please suggest in this case



Keisuke Shimizu says:

December 27, 2015 at 10:29 am

My new article, Backdoor HDL Path, might help. Basically, you can specify the source of the register elds like:



Leave a Reply


(c) 2011-2016, ClueLogic, LLC

Proudly powered by WordPress | Education Hub by WEN Themes 15/15