uvm_mem get_default_map problem

[etrounce]

Hi,

I think there's a bug in uvm_mem, I'm using 1.1b.

I'm using a uvm_mem object (myMem) created/built inside a uvm_reg_block (myRegblock) and assigned to a uvm_reg_map (myRegmap), however the uvm_reg_block has no default_map object, instead it has multiple uvm_reg_map objects all named something other than default_map. However, when I go to do a myMem.read in my testcase, I get a UVM_WARNING:

UVM_WARNING .../uvm_mem.svh(1101) @ 51000000.0 ps: reporter [RegModel] Memory 'myRegblock.myMem' is not contained within map 'myRegBlock.firstRegMap'

When I do a read, this turns into read() -> do_read() -> Xcheck_accessX() -> get_local_map() -> get_default_map(). In get_default_map, the code discovers the correct map using the sole entry in m_maps and should likely return immediately (bug #1). However it continues by looking at myMem's parent (myRegBlock), gets his default_map (firstRegMap), and passes this map to uvm_mem::get_local_map to check if the memory belongs to this map. It doesn't, so get_local_map throws the warning. I think, in cases where a memory belongs to multiple maps, the read/write command should be forced to provide a map. I think this search for a default map isn't required, instead there should be an error or fatal here.

Does this make sense?

Erik

[janick]

I agree that a return statement is missing in uvm_mem.svh at line 1121. I have filed a mantis for this one: http://www.eda.org/svdb/view.php?id=4340

As for your statement that "in cases where a memory belongs to multiple maps, the read/write command should be forced to provide a map.", I have to disagree for reuse reasons: Assume some block-level code where the memory is only in one map, and the memory accesses are written without specifying a map (because there is only one). The block is subsequently modified to add a new address map (or instantiated in a multi-map block [not yet supported BTW -- see http://www.eda.org/svdb/view.php?id=4009]), all these accesses will now have to be modified to explicitly specify a map to use.

[etrounce]

Hi Janick,

Thanks for filing the mantis for me.

With regards to the scenario where a memory belongs to a single map in a block environment but is then added to a second map, I agree, however in that case there may be one or more UVM_WARNINGs every time the memory is accessed, depending on whether the memory belongs to the first map declared in each of the reg_block objects it's instantiated in. I don't see the purpose of the current warning, other than indicating that the memory doesn't belong to the first map built in the reg_block that owns the first map it was added to. It seems to me it would be more intuitive and informative to simply select the 1st map the memory was added to and perhaps have a warning or info indicating the memory belongs to multiple maps and a particular map was selected.

Regards,

Erik

[janick]

The warning is an artifact of the missing return statement. If a map can successfully be found, the access should proceed without any messages.

[etrounce]

Hi Janick,

If a memory belongs to more than one map, then the search below the missing return takes place. This search goes through each of the maps the memory belongs to, retrieves the parent reg_block for that map, and checks to see if the memory belongs to the 1st map of that reg_block. Each time this check fails, you'll get a warning. So, if a memory belongs to the 2nd and 3rd map of a particular reg_block for example, you'll get two warnings that it doesn't belong to that reg_block's 1st map, every time you access the memory.

Regards,

Erik