AHB2APB Verification

Hopefully I've answered some of your questions here in my reply just sent to your earlier post in the Architectures and Processors forum.

Regardless of the HSIZE width of transfer you are requesting, the "unused" bits of HRDATA will still have some values, so all of the 4 above HRDATA values could be correct, and we would need to know what data 32-bit WAS stored at PADDR=0x0 to know what is then the correct HRDATA value to be returned.

HADDR does increase by 1 for each sequential step in an HSIZE=0 burst, but as described in the other forum question, having PADDR not aligned to the width of the data bus can result in UNPREDICTABLE results, and I guess this is what is happening here when presumably you have driven PADDR to 0x0, 0x1, 0x2 and 0x3 for this sequence.

Instead I suspect that your APB bridge should have aligned PADDR to the data bus width (so driving PADDR[1:0] to 2'b00) so that it always correctly addresses the word addressable targets, and returning a full 32-bits of PRDATA back to HRDATA (I suspect the expected data was the 0x0A0B0C0D) for each of the 4 byte width AHB read requests.

The AHB manager will then know which HRDATA bits to read for each of the 4 byte requests (HRDATA[7:0] for the 0x0 address, HRDATA[15:8] for the 0x1 address, and so on - although note that this would only be correct for a little endian system - which is probably a different question altogether). It is perfectly valid for the APB bridge to return 32-bits of read data for a byte read request as the AHB manager will only be looking at one of the byte lanes of the returned data.

Hopefully I've answered some of your questions here in my reply just sent to your earlier post in the Architectures and Processors forum.

Regardless of the HSIZE width of transfer you are requesting, the "unused" bits of HRDATA will still have some values, so all of the 4 above HRDATA values could be correct, and we would need to know what data 32-bit WAS stored at PADDR=0x0 to know what is then the correct HRDATA value to be returned.

HADDR does increase by 1 for each sequential step in an HSIZE=0 burst, but as described in the other forum question, having PADDR not aligned to the width of the data bus can result in UNPREDICTABLE results, and I guess this is what is happening here when presumably you have driven PADDR to 0x0, 0x1, 0x2 and 0x3 for this sequence.

Instead I suspect that your APB bridge should have aligned PADDR to the data bus width (so driving PADDR[1:0] to 2'b00) so that it always correctly addresses the word addressable targets, and returning a full 32-bits of PRDATA back to HRDATA (I suspect the expected data was the 0x0A0B0C0D) for each of the 4 byte width AHB read requests.

The AHB manager will then know which HRDATA bits to read for each of the 4 byte requests (HRDATA[7:0] for the 0x0 address, HRDATA[15:8] for the 0x1 address, and so on - although note that this would only be correct for a little endian system - which is probably a different question altogether). It is perfectly valid for the APB bridge to return 32-bits of read data for a byte read request as the AHB manager will only be looking at one of the byte lanes of the returned data.