I found that in the AHB spec Rev 2 it is mentioned that AHB burst can be of any length but the upper limit is that the address should not cross 1KB boundary. We wanted to know what this 1KB boundary means and how is it calculated. It would be of a great help if it is explained with some relevant examples.
»
Quick Links
Page 1 of 1
AHB spec related queries
Rate Topic:
#2
JD 
- Regular Contributor
-
- Group: Members.
- Posts: 260
- Joined: 17-November 06
Posted 01 December 2011 - 03:05 PM
A 1KB boundary is simply a multiple of 1K, so 0 (0x0), 1024 (0x400), 2048 (0x800), 3072 (0xC00), etc.
Bursts cannot cross these boundaries because the minimum address range assigned to an AHB slave is 1KB. If you had 2 slaves back to back in the address space, and a burst DID cross a 1KB boundary from the first slave to the second, you could have problems in both slaves.
As an example of this...
Slave1 might see an INCR8 word-width burst indicated, starting at 0x3EC, so 5 transfers to slave 1 (0x3EC, 0x3F0, 0x3F4, 0x3F8 and 0x3FC), and then the burst crosses to Slave2. But slave 1 has been told to expect 8 transfers (so a protocol violation as masters cannot terminate bursts they have indicated, and potentially redundant Slave1 prefetches if it had tried to interpret what the master actually wanted and had prefetched from 0x0, 0x004 and 0x008 to complete 8 accesses).
Slave2 also then sees HBURST=INCR8, but the burst it is selected for starts with a SEQ access (protocol violation), and there are only 3 transfers from the master (0x400, 0x404 and 0x408), so the same burst termination protocol violation as before.
Even if you were not using a defined length burst, and instead just used burst type INCR, the first transfer Slave2 sees is a SEQ, and the slave state machine might not be designed to accept this if it attempts to differentiate between NONSEQ and SEQ accesses. So the INCR burst would need to end when it reached the 1KB boundary, and start with a NONSEQ at the 1KB boundary (potentially a different slave).
Forcing bursts to terminate at 1KB boundaries shouldn't be a significant problem, even if the slave is physically larger than 1KB in size (so not crossing between 2 smaller slaves). Most uses for defined length bursts use burst aligned start addresses (typically cache line accesses), so these wouldn't be crossing 1KB boundaries anyway, and for occasions where the start address isn't burst aligned, most won't cross a 1KB boundary. Undefined length bursts just terminate when they reach the boundary and start on the other side of it, so simple to code in the bus master.
What this solution does is make the master design work regardless of the physical construction of the slaves. Otherwise the master needs to know if address 0x400 in the above example is a boundary between 2 slaves that cannot be crossed, making the master application specific, and then not reusable.
JD
Bursts cannot cross these boundaries because the minimum address range assigned to an AHB slave is 1KB. If you had 2 slaves back to back in the address space, and a burst DID cross a 1KB boundary from the first slave to the second, you could have problems in both slaves.
As an example of this...
Slave1 might see an INCR8 word-width burst indicated, starting at 0x3EC, so 5 transfers to slave 1 (0x3EC, 0x3F0, 0x3F4, 0x3F8 and 0x3FC), and then the burst crosses to Slave2. But slave 1 has been told to expect 8 transfers (so a protocol violation as masters cannot terminate bursts they have indicated, and potentially redundant Slave1 prefetches if it had tried to interpret what the master actually wanted and had prefetched from 0x0, 0x004 and 0x008 to complete 8 accesses).
Slave2 also then sees HBURST=INCR8, but the burst it is selected for starts with a SEQ access (protocol violation), and there are only 3 transfers from the master (0x400, 0x404 and 0x408), so the same burst termination protocol violation as before.
Even if you were not using a defined length burst, and instead just used burst type INCR, the first transfer Slave2 sees is a SEQ, and the slave state machine might not be designed to accept this if it attempts to differentiate between NONSEQ and SEQ accesses. So the INCR burst would need to end when it reached the 1KB boundary, and start with a NONSEQ at the 1KB boundary (potentially a different slave).
Forcing bursts to terminate at 1KB boundaries shouldn't be a significant problem, even if the slave is physically larger than 1KB in size (so not crossing between 2 smaller slaves). Most uses for defined length bursts use burst aligned start addresses (typically cache line accesses), so these wouldn't be crossing 1KB boundaries anyway, and for occasions where the start address isn't burst aligned, most won't cross a 1KB boundary. Undefined length bursts just terminate when they reach the boundary and start on the other side of it, so simple to code in the bus master.
What this solution does is make the master design work regardless of the physical construction of the slaves. Otherwise the master needs to know if address 0x400 in the above example is a boundary between 2 slaves that cannot be crossed, making the master application specific, and then not reusable.
JD
This post has been edited by JD: 01 December 2011 - 03:08 PM
#4
vyankatg
- Member
-
- Group: Members
- Posts: 4
- Joined: 01-December 11
Posted 02 December 2011 - 07:35 AM
One more quick question I have here.. in the AHB master design, if the master is provided with an INCR burst as described below :
1. Number of bytes per beat = 8
2. Transfer size = 32 bit
3. starting addr = fff0
4. Number of beats = 2
These are some of the attributes of the burst I pass to the master.
So ideally, what should the master drive in this case? As the transfer size is 32 bit but the total number of bytes is (bytes per beat * number of beats) 16. Should the master di the write at addresses fff0,fff4,fff8,fffc respectively with 4 bytes each or it should expect that the transfer size (data width of current transfer) should be 64 bit?
1. Number of bytes per beat = 8
2. Transfer size = 32 bit
3. starting addr = fff0
4. Number of beats = 2
These are some of the attributes of the burst I pass to the master.
So ideally, what should the master drive in this case? As the transfer size is 32 bit but the total number of bytes is (bytes per beat * number of beats) 16. Should the master di the write at addresses fff0,fff4,fff8,fffc respectively with 4 bytes each or it should expect that the transfer size (data width of current transfer) should be 64 bit?
#5
JD
- Regular Contributor
-
- Group: Members.
- Posts: 260
- Joined: 17-November 06
Posted 02 December 2011 - 08:26 AM
If I understand this correctly, the AHB master interface is being provided with 64-bit stimulus, which for some reason it then has to convert into 32-bit transfers ?
If the master is using HSIZE=32 bit transfers, and there are 16 bytes to transfer, it would perform writes to 0xfff0, 0xfff4, 0xfff8 and 0xfffc.
However if the data bus width is 64 bits, the master could just drive 64-bit wide transfers, to addresses 0xfff0 and 0xfff8.
The master can use any HSIZE value it wants, the only limitation being that HSIZE cannot indicate wider than the HWDATA and HRDATA bus widths.
Neither of these involves crossing a 1KB boundary, so not really related to your earlier questions, so am I missing the problem you are concerned about ?
JD
If the master is using HSIZE=32 bit transfers, and there are 16 bytes to transfer, it would perform writes to 0xfff0, 0xfff4, 0xfff8 and 0xfffc.
However if the data bus width is 64 bits, the master could just drive 64-bit wide transfers, to addresses 0xfff0 and 0xfff8.
The master can use any HSIZE value it wants, the only limitation being that HSIZE cannot indicate wider than the HWDATA and HRDATA bus widths.
Neither of these involves crossing a 1KB boundary, so not really related to your earlier questions, so am I missing the problem you are concerned about ?
JD
#6
vyankatg
- Member
-
- Group: Members
- Posts: 4
- Joined: 01-December 11
Posted 02 December 2011 - 10:32 AM
I have these scenarios reported by one of our customers:
m_enHdataWidth = HDATA_WIDTH_32
m_nNumBeats = 2
m_bvAddress = fffffffffffffff8 (starting address)
m_enXferSize = XFER_SIZE_32BIT (transfer size)
m_enBurstType = INCR
Other scenario has :
m_enHdataWidth = HDATA_WIDTH_32
m_nNumBeats = 2
m_bvAddress = fffff8
m_enXferSize = XFER_SIZE_32BIT
m_enBurstType = INCR
In both the cases, the number of bytes per beat is 8 and there are two beats. So in which of the above case the 1KB boundary is crossed? Also in both the cases, the transfer size is 32 bit but beats have 8 bytes each.
m_enHdataWidth = HDATA_WIDTH_32
m_nNumBeats = 2
m_bvAddress = fffffffffffffff8 (starting address)
m_enXferSize = XFER_SIZE_32BIT (transfer size)
m_enBurstType = INCR
Other scenario has :
m_enHdataWidth = HDATA_WIDTH_32
m_nNumBeats = 2
m_bvAddress = fffff8
m_enXferSize = XFER_SIZE_32BIT
m_enBurstType = INCR
In both the cases, the number of bytes per beat is 8 and there are two beats. So in which of the above case the 1KB boundary is crossed? Also in both the cases, the transfer size is 32 bit but beats have 8 bytes each.
Share this topic:
Page 1 of 1
