Axi ARSIZE with narrow subordinates

Answering your second question first, the AXI4 initiator won't always know the structure of the target of the transaction, so this isn't an insane request.

However if the target is APB it is likely to be some sort of peripheral with control registers that the initiator must know about, and so would then know the width of the APB target registers, and so should be using appropriate width transfers.

Moving back to your first question, what is missing from your description is that as well as a protocol conversion bridge to handle the AXI4-APB conversion, you would also need to consider how to connect the 32-bit AXI4 initiator to an 8-bit APB target.

It is very unlikely that you would downsize the AXI4 bus to 8-bits before converting to APB (I've never seen an AXI implementation with data less than 32-bits as AXI is meant to be for the higher performance parts of your design), so presumably the APB bridge is working with 32-bit wide data. So how then are you connecting an 8-bit APB target to the 32-bit APB data bus ?

The simplest solution would be to just connect the 8-bit APB target to PxDATA[7:0] on the 32-bit bus, and know that your peripheral can only be accessed using 8-bit requests on 32-bit aligned addresses, so 0x0, 0x4, 0x8, 0xC, 0x10... etc. Which then leads back to your second question with the AXI4 initiator needing to be aware of the APB target addressing and width limitations.

Alternatively try to implement some sort of APB routing component that will MUX the 8-bit interface of the target to the relevant byte lane of the 32-bit APB bus using PADDR[1:0] to perform the MUX control (removing the 32-bit aligned addressing requirement), but this wouldn't handle when the AXI4 transfer is requesting 16-bits of data.

And trying to build an APB downsizer bridge to handle both the routing and width conversion is just not practical (again I've never seen this done).

So I think the answer to your problem is what your second question hinted at, and the AXI4 initiator needs to know that this particular target is an APB device with width limitations, and possibly addressing limitations if you go for the simpler PxDATA connection rather than any MUXing routing solution.

Answering your second question first, the AXI4 initiator won't always know the structure of the target of the transaction, so this isn't an insane request.

However if the target is APB it is likely to be some sort of peripheral with control registers that the initiator must know about, and so would then know the width of the APB target registers, and so should be using appropriate width transfers.

Moving back to your first question, what is missing from your description is that as well as a protocol conversion bridge to handle the AXI4-APB conversion, you would also need to consider how to connect the 32-bit AXI4 initiator to an 8-bit APB target.

It is very unlikely that you would downsize the AXI4 bus to 8-bits before converting to APB (I've never seen an AXI implementation with data less than 32-bits as AXI is meant to be for the higher performance parts of your design), so presumably the APB bridge is working with 32-bit wide data. So how then are you connecting an 8-bit APB target to the 32-bit APB data bus ?

The simplest solution would be to just connect the 8-bit APB target to PxDATA[7:0] on the 32-bit bus, and know that your peripheral can only be accessed using 8-bit requests on 32-bit aligned addresses, so 0x0, 0x4, 0x8, 0xC, 0x10... etc. Which then leads back to your second question with the AXI4 initiator needing to be aware of the APB target addressing and width limitations.

Alternatively try to implement some sort of APB routing component that will MUX the 8-bit interface of the target to the relevant byte lane of the 32-bit APB bus using PADDR[1:0] to perform the MUX control (removing the 32-bit aligned addressing requirement), but this wouldn't handle when the AXI4 transfer is requesting 16-bits of data.

And trying to build an APB downsizer bridge to handle both the routing and width conversion is just not practical (again I've never seen this done).

So I think the answer to your problem is what your second question hinted at, and the AXI4 initiator needs to know that this particular target is an APB device with width limitations, and possibly addressing limitations if you go for the simpler PxDATA connection rather than any MUXing routing solution.

To clarify more on my bridge design part:
I am breaking the 32bit data requests into 4 8bit data requests in my axi-to-apb bridge for both reads and writes. The bridge also generated appropriate addresss for apb.

If your AXI4-APB bridge is converting the 32-bit requests into 4 8-bit requests, and you have implemented some sort of MUXing to connect the 8-bit APB target to the appropriate 8-bits of the 32-bit APB bus, then the resulting read data for your example 4-beat 16-bit sequence would be...

0x1000 xxxx0001

0x1002 aaa1xxxx

0x1004 xxxx0002

0x1006 aaa2xxxx

The xxxx fields are data bytes that were not requested, so they are undefined. They could be a copy of the other 16-bits (it might simplify MUXing), or they could be whatever was last driven on those bits for the previous transfer, or they could be a default value (probably 0000), but that is all down to the implementation of the 32:8 conversion in the bridge.

Just realised I needed to add to the first sentence in that last reply...

"If your AXI4-APB bridge is converting the 32-bit requests into 4 8-bit requests AND is merging together the 8-bit results when returning read data,..."