What is the correct way to update the mirrored state of a register? about uvm-python HOT 7 CLOSED

Thanks. Yeah, I'd missed registering my new classes so I wasn't calling what I thought I was.

So I now have things sort of working. The correct default_map gets called and I'm entering my custom do_bus_write() method. However, the logic there seems a bit broken. I'm performing a REG write and the rw_access.n_bits and rw_access.byte_en fields are 0 and -1 respectively. They don't seem to be setup correctly for the datawidth.

Is this functionality just missing here and is a TODO item? They only seem to be updated for UVM_FIELD.

Edit: found and fixed the issues here. See #32

from uvm-python.

from uvm-python.

Thanks, I'll give it another go.

One of my concerns with using this library for the register model was how much of it depends on all your UVM backend classes. We're using standard Cocotb with cocotb-coverage for our project and I was trying to find a UVM like register model to use - we're using the OpenTitan regtool.py to generate our registers and they use SV UVM - so using this library made sense but the more I look at it, the more it seems to not make sense for us.

For example, the UVMRegBlock class expects to be hooked up to a sequencer and adapter for the read/write functionality whereas for our use case we probably just want to hook it directly to our bus driver. Is this doable and how might we do this? Create a wrapper class that translates between the UVM sequencer to provide pure write/read methods to our side? Just thinking out loud really while I try to get my head round all the UVM methodology which I've not used before.

from uvm-python.

from uvm-python.

Thanks, I've had a closer look at the classes today. In uvm_reg::do_write, the only instance of anything sequency is if a user defined frontdoor has been defined I think. In that case, the sequence start() method is called, otherwise the uvm_reg_map::do_write() method is called. If we're just using a standard uvm_reg_block with a uvm_reg_map, we wouldn't be using a user defined frontdoor would we? Just thinking if there's actually anything in uvm_reg::do_{read,write} that I actually need to override.

from uvm-python.

Edit: a missing uvm_object_utils was the cause of my confusion. I'll update later with more progress...

So I've got a bit further and have my customised classes now. I didn't implement one for UVMReg as it looked like I didn't need it and it looks like the flow skips the sequence.start() method in do_write(). However, when it gets to calling rw.local_map.do_write(rw), it seems to be calling UVMRegMap and not my customised class, DVRegMap.

I can't see where this local_map is defined. In UVMReg::write() a new UVMRegItem is created but _map is None and rw.local_map is not written.

I'm calling the write function from my custom DVReg class:

class reg_udma_CONTROL(DVReg):
    def __init__(self, name="udma_CONTROL"):
        super().__init__(name, 32)
        self.ENABLE = None

    def build(self):
        self.ENABLE = DVRegField.type_id.create("ENABLE")
        self.ENABLE.configure(
            self,
            32,
            0,
            "RW",
            False,
            0,
            True,
            False,
            False
        )

uvm_object_utils(reg_udma_CONTROL)


class regblock_udma(DVRegBlock):
    def __init__(self, name="u_udma_regfile"):
        super().__init__(name)
        self.CONTROL = None

    def build(self):
        self.CONTROL = reg_udma_CONTROL.type_id.create("CONTROL")
        self.CONTROL.configure(self, None, "u_dma_control.q")

        self.default_map = self.create_map("default_map", 0x0, 4, UVM_LITTLE_ENDIAN)
        self.default_map.add_reg(self.CONTROL, 0x0, "RW")

uvm_object_utils(regblock_udma)

@cocotb.test(timeout_time = 1000, timeout_unit='ns')
async def test_block(dut):
    # snip
    status = []
    await tb.regmodel.CONTROL.write(status, 0xdeadbeef)

from uvm-python.

from uvm-python.