A map can only have one adapter/sequencer associated with it. There are hooks for supporting multiple parent maps, but the algorithm for choosing which map to use (without an explicit map provided in calls to write/read) gets complicated.
For now we produce an error when adding a submap that has already been added to a different sibling map. You might instead individually add each register belonging to the submap to the new map. We don’t do that automatically because often the new map has only a subset of the subblock registers accessible, or their access rights have changed, or the new map consists of new registers plus some subset of registers from different subblocks. So you will need to add regs manually to all but the 1st map. There are currently no plans to add automatic support via add_submap. If your company filed a Mantis under Accellera’s VIP TSC working group, perhaps we can add support for the next major release–support for multiple parent maps, or support for automatic adding of individual regs to the new map.
The Mantis database is at https://accellera.mantishub.com/view.php?id=4009
I believe this describes your scenario:
**** Going from block to system, DUT still has one instance of the register block but now has two busses that can access it.
Sys reg model definition: Define sys block's build() method to add instance of the subblock, and create two maps. One sys map can simply have the subblock's map added (add_submap). For the other map, you need to individually add the regs of the subblock to it. Call subblock.get_regs, then call mapB.add_reg(...) for each reg to the 2nd sys level map, perhaps giving each a different address offset than the original, or even restricting access rights (RO), or skipping some registers, i.e. not adding them at all to the new map. What you do depends on what the 2nd bus and DUT hardware allows.
Testbench updates: bus interface added, have sys env create two agent instances to drive two busses. Each sys map configured with own adapter/sequencer (from these two bus agents).
With the system level reg model defined, each reg has handles to two maps: (1) a handle to the submap, which now has a parent (sys) map, perhaps a different offset, and (2) a handle to a new parent (sys) map, which can be effectively a copy of the subblock map, or have completely different address translation.
Now, during write/read operations:
(1) A reg write/read without explicit map argument will select the default_map in effect at the sys (topmost parent) level, which is the first map added to the sys block if you don’t assign default_map handle directly.
(2) If you supply an explicit map argument in calls to write/read, it must be a handle to the original subblock map or the two sys-level parent maps, else you’ll get an error.