Search the Community
Showing results for tags 'UVM RAL'.
Found 3 results
(Possible) Bug in uvm_mem
tudor.timi posted a topic in UVM (Pre-IEEE) Methodology and BCL ForumI'm trying to declare a memory like this: class some_mem extends uvm_mem; function new(string name = "some_mem"); super.new(name, 2 ** 24, 8, "RO"); endfunction endfunction Later on, I'm trying to add this memory to an address map that was created like this: default_map = create_map("some_map", 0, 4, UVM_NO_ENDIAN); By using the default value for the byte_addressing argument I want each address to represent a one byte location. The problem I'm seeing is that the uvm_reg_map_info associated with this memory shows an end address of 32'03ff_ffff and a stride of 4, instead of 32'00ff_ffff and a stride of 1. I've narrowed it down to the function uvm_reg_map::get_physical_address(...), at line 1378 of uvm_reg_map.svh: int multiplier = m_byte_addressing ? bus_width : 1; I guess this should be the other way around: int multiplier = m_byte_addressing ? 1: bus_width; Even better would be to use: int multiplier = get_addr_unit_bytes();
I found that UVM register model use semaphore to avoid conflicts, and this may cause some problems: (1) when one sequence is writing some registers, and at the mean time, a UVM_BACK_DOOR is reading some registers, conflict happened. I found that the uvm_back_door reading is stoped.( in m_atomic.get(1) ) (2)another scenario: when config the registers using uvm register model in one sequence, one on fly reset happened, so I need to kill the sequence. and then uvm_do_on this sequence again. One problem came up, the second sequence will stop at the same writing register as the first sequence. I guess it also because the semaphore problems. I hope that someone will help me to solve this problems. Thanks.
Hi, I have a doubt related to UVM 's RAL with compared to OVM's RGM. The OVM's RGM seems to have only two sets of registers i.e., the actual ones belonging to DUT and the other belonging to the register model(testbench side regs to mimic duts regs). But the UVM's RAL has three sets namely 1) DUT's regs as usual and 2)Mirror registers 3)Desired value registers, the 2) and 3) are part of the testbench i.e., register model side. Why is this kind of implementation has been adopted in UVM RAL where as we could accomplish our tasks with the 2 sets as is in RGM. Can any one please enlighten me regarding the advantages or usecases related to this? Thanks In advance.