Lower bits of cpu addr bus not ignored with wider data bus

[roowatt]

I am working on the C Headers for register access interfacing a regblock generated to Xilinx Microblaze via AXI-Lite. I will post some screenshots at the end from Vivado that shows the issue that I will try to describe...

I am using an accesswidth and regwidth of 32, I have defeined a number of registers and I am poking at them from the CPU side. I have noticed the following. It looks like only writes that are regwidth aligned are successful, consider the following register that is located at offset 0x20...

    reg {
        field {
        } LOAD[24:24] = 0;
        field {
        } HYBRID_MODE[16:16] = 0;
        field {
        } HYBRID_POSTFIX[8:8] = 0;

        field {
            singlepulse;
        } START[0:0] = 0;
    } control0;

As can be seen, there are four 1 bit fields that are the LSB of the 4 bytes of the 32 bit register.

If I use a uint8_t pointer to access these fields, the writes to the first field succeeds but fails to the remaining three fields. Despite the WSTRB having the expected values. However, if I mask off the lower 2 bits of the CPU address then things work as I expect.

It seems to me that the lower 2 bits of the address bus should be ignored when generating the decoded_reg_strb.xx.yy signal.

Am I barking up the wrong tree here?

Lower 2bits not masked

Lower 2bits masked

I can provide additional information or clarification as needed.

[roowatt]

Version info is

peakrdl                0.8.0
peakrdl-html           2.10.1
peakrdl-ipxact         3.4.1
peakrdl-regblock       0.16.0
peakrdl-systemrdl      0.3.0
peakrdl-uvm            2.3.0

[amykyta3]

Yep definitely a bug. CPUIF implementations for AXI4-Lite, and probably also APB should ignore the lower bits of the address bus in order to properly handle unaligned accesses.

[roowatt]

"Unaligned Access"... that is a far simpler way of describing the issue. :)

I guess I was so focussed on packing registers so they could be efficiently accessed multiple ways that I didn't consider it to be unaligned as such.

[amykyta3]

Fixed in v0.18.0