AMBA AHB Lite addressable space for byte size transfer

I think what you are now describing is correct.

The AHB-lite protocol is a byte addressable protocol, so with HADDR at 32-bits this supports 4G of addressable bytes. If your target slave only has 32-bit registers (and these must be at 32-bit aligned addresses), this means you have up to 1G of addressable word registers supported

So yes, a byte position on the data bus has to be changed depending on the HADDR LSBs, using HADDR[1:0] on a 32-bit data bus, or HADDR[2:0] on a 64-bit data bus.

For your i2C-to-AHBlite bridge, if it is targetting a 16KB slave which has 4K of 32-bit registers, the bridge would signal byte accesses (or half-word 16-bit accesses) on HSIZE, and it would then be up to the AHB-lite slave design implementation whether it supports 8- and/or 16-bit accesses, and if it does it will expect to see HWDATA on the correct segments of the wider data bus, and it will return HRDATA on the correct segments of the wider data bus, those segments being defined by HADDR LSBs (and the bus endianness).

Note that the slave might NOT support sub-32-bit accesses to its 32-bit registers, so would then return ERROR responses on HRESP. But that would be a system design issue, why implement a slave that does not support sub-32-bit accesses when the system designer knows it will be accessed by the i2c-to-AHBlite bridge.

I think what you are now describing is correct.

The AHB-lite protocol is a byte addressable protocol, so with HADDR at 32-bits this supports 4G of addressable bytes. If your target slave only has 32-bit registers (and these must be at 32-bit aligned addresses), this means you have up to 1G of addressable word registers supported

So yes, a byte position on the data bus has to be changed depending on the HADDR LSBs, using HADDR[1:0] on a 32-bit data bus, or HADDR[2:0] on a 64-bit data bus.

For your i2C-to-AHBlite bridge, if it is targetting a 16KB slave which has 4K of 32-bit registers, the bridge would signal byte accesses (or half-word 16-bit accesses) on HSIZE, and it would then be up to the AHB-lite slave design implementation whether it supports 8- and/or 16-bit accesses, and if it does it will expect to see HWDATA on the correct segments of the wider data bus, and it will return HRDATA on the correct segments of the wider data bus, those segments being defined by HADDR LSBs (and the bus endianness).

Note that the slave might NOT support sub-32-bit accesses to its 32-bit registers, so would then return ERROR responses on HRESP. But that would be a system design issue, why implement a slave that does not support sub-32-bit accesses when the system designer knows it will be accessed by the i2c-to-AHBlite bridge.

Thanks Colin for the reply, much appreciated