Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
IP Products
System
Jump...
Cancel
System
SoC Design forum
Write Data Interleaving - AXI
Blogs
Forums
Videos & Files
Help
Jump...
Cancel
New
State
Not Answered
Replies
2 replies
Subscribers
71 subscribers
Views
6056 views
Users
0 members are here
AMBA
AXI
Bus Architecture
Interface
Related
Write Data Interleaving - AXI
Offline
Amaresh Chaligeri
over 7 years ago
Note: This was originally posted on 19th March 2009 at
http://forums.arm.com
Hello,
Can anybody help me to understand the reasoning behind write data interleaving ordering restriction imposed by AXI spec.
[Chapter 8.5 Write data interleaving]
"The order in which a slave receives the first data item of each transaction must be the
same as the order in which it receives the addresses for the transactions."
Thanks in advance,
Amaresh
Parents
0
Offline
Colin Campbell
over 7 years ago
Note: This was originally posted on 20th March 2009 at
http://forums.arm.com
Hi Amaresh,
The only reason I can think of for this rule could be to simplify slave designs where the slave can store a greater number of address transactions than it can accept interleaved write data for, i.e. it has a "write_acceptance_capability" greater than the "write_interleave_depth".
I would expect the slave designer would want any interleaved write data to be for the earlier accepted addresses, so by insisting that the first write data follows the order of the addresses, the slave knows that any interleaved data following the first transfers will be for the oldest addresses, and once a data sequence completes, the slave can then move a stored address transaction parameters up to control the now free data receiving buffer.
To try to give an example (as the above doesn't clearly explain what I'm thinking). imagine a slave with a "write_acceptance_capability" of 4 addresses (A,B,C and D received in that order), but only a "write_interleave_depth" of 2 transactions, I would think the slave design would use the A and B transaction details to setup the write data buffers, and store C and D controls elsewhere.
By the protocol requirements, the first received data must be for A, for which a data buffer is already set aside.
Then we can have further data for A (which the slave is ready for), or we can have the first data for B, again for which the slave has a data buffer for.
From this point on, the "write_interleave_depth" parameter means only data for A or B can be received.
When either A or B completes, the slave can move the control information stored for C up to a data buffer, and it is then prepared to receive first data from C.
If we allowed data from any of A, B, C or D to come along first, the slave wouldn't know which address info to use for the buffer until this first data is seen.
This solution also ensures that the older addresses do get completed before the newer addresses, so preserving some sort of system event order.
I'm not saying that is how slaves MUST handle transactions, but it might apply for some slaves, and does then explain a reason for this protocol requirement.
JD
Cancel
Up
0
Down
Reply
Accept answer
Cancel
Reply
0
Offline
Colin Campbell
over 7 years ago
Note: This was originally posted on 20th March 2009 at
http://forums.arm.com
Hi Amaresh,
The only reason I can think of for this rule could be to simplify slave designs where the slave can store a greater number of address transactions than it can accept interleaved write data for, i.e. it has a "write_acceptance_capability" greater than the "write_interleave_depth".
I would expect the slave designer would want any interleaved write data to be for the earlier accepted addresses, so by insisting that the first write data follows the order of the addresses, the slave knows that any interleaved data following the first transfers will be for the oldest addresses, and once a data sequence completes, the slave can then move a stored address transaction parameters up to control the now free data receiving buffer.
To try to give an example (as the above doesn't clearly explain what I'm thinking). imagine a slave with a "write_acceptance_capability" of 4 addresses (A,B,C and D received in that order), but only a "write_interleave_depth" of 2 transactions, I would think the slave design would use the A and B transaction details to setup the write data buffers, and store C and D controls elsewhere.
By the protocol requirements, the first received data must be for A, for which a data buffer is already set aside.
Then we can have further data for A (which the slave is ready for), or we can have the first data for B, again for which the slave has a data buffer for.
From this point on, the "write_interleave_depth" parameter means only data for A or B can be received.
When either A or B completes, the slave can move the control information stored for C up to a data buffer, and it is then prepared to receive first data from C.
If we allowed data from any of A, B, C or D to come along first, the slave wouldn't know which address info to use for the buffer until this first data is seen.
This solution also ensures that the older addresses do get completed before the newer addresses, so preserving some sort of system event order.
I'm not saying that is how slaves MUST handle transactions, but it might apply for some slaves, and does then explain a reason for this protocol requirement.
JD
Cancel
Up
0
Down
Reply
Accept answer
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Not Answered
Behaviour of CHI Receiver during race condition from RUN to DEACTIVATE
0
AMBA
AMBA 5 CHI
CHI
Bus Architecture
AMBA 5
4181
views
0
replies
Started
4 months ago
by
amit
Not Answered
In APB, Why do we use enable signal? (Don't care about PREADY)
0
4518
views
0
replies
Started
4 months ago
by
INNS
Not Answered
DC/DC Controller SoC
0
5015
views
1
reply
Latest
5 months ago
by
Andy Neil
Not Answered
AMBA 5 CHI : Does Interleaving of TxnID within a Multiple flits message allowed?
+1
System on Chip (SoC)
AMBA 5 CHI
CHI
Cache Architecture
5206
views
1
reply
Latest
5 months ago
by
IPDeveloper
Not Answered
AXI4 transaction attributes
0
5024
views
0
replies
Started
5 months ago
by
Ravi V.
<
>
View all questions in SoC Design forum