Hi,
It looks like when using a transfer size of one Byte, the position of this data on the 32-Bit bus must be set via ADDRESS[1:0]. This means that for a Byte transfer, the addressable space is reduced, from 4GB (2^32) to 2^(30) = 1GB. Is this correct ?
Thanks
Ok, so I believe this is not a correct interpretation. Now I think that the byte has to be dynamically changed depending on the position of HADDR[1:0].
In fairness the more I read this spec the less I understand it. Let me please explain what I am trying to do and please suggest whether I am getting it all wrong.
I have to design an i2c-to-amba-lite bridge. i2c data width will be of 8 or 16-bits, but the AHB-Lite is 32-Bits. One requirement for us is that we need to be able to access the whole AHB-Lite memory space (16K addresses) via i2c. The internal memory peripherals on the bus are made out of 32-Bits registers so I am a bit confused now with respect to whether it is possible to access just a byte out of these 32-Bits.
I think that this is precisely what the offset is about right? For a byte access, I need 2 extra address bits to "byte-select" within the 32-Bit data register. So, if I have 2^16 individual addresses I need to access, then, for a byte access, I would need an internal address of 2^18 bits.
I believe my understanding is correct now, but I would appreciate some feedback
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