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
More AXI write/read ordering
Blogs
Forums
Videos & Files
Help
Jump...
Cancel
New
State
Not Answered
Replies
3 replies
Subscribers
71 subscribers
Views
5078 views
Users
0 members are here
AMBA
AXI
Bus Architecture
Related
More AXI write/read ordering
Offline
Randy Pascarella
over 7 years ago
Note: This was originally posted on 25th October 2007 at
http://forums.arm.com
In another posting, a scenario given was with a RAW hazard where a bufferable write was followed by a read to an overlapping address. Sounds like the master's assumption upon receipt of BRESP is that a read with an address overlap can be issued and will be ordered beyond AXI behind the write, such that the read returns new data.
However, if there is no address overlap, is the master's assumption that the read may eventually pass the write beyond AXI?
Also, what qualifies as an address overlap? Is the range of overlap considered to be a hit to the range governed by the AADDR, ASIZE, ALEN, ABURST signals of both the write and read, or something different?
Finally, why is there a distinction between memory regions and peripheral regions in section 8.6 of the spec? If the master cannot discern between the two, should the most pessimistic view be assumed, which would be assuming a peripheral region?
Thanks!!!
Parents
0
Offline
Colin Campbell
over 7 years ago
Note: This was originally posted on 26th October 2007 at
http://forums.arm.com
I tried to cover both cases in my earlier reply.
There doesn't need to be any address overlap, as soon as the master sees a BRESP for any write access, it can assume that transfer has been completed.
In the simpler address overlap case, any slave that has buffered the write data will have to do hazard checking for subsequent read accesses.
In a non-overlap case, where I described the write as being a "control" access, as soon as the master sees a BRESP it might attempt a read, assuming the control access has switched whatever needed changing.
That is why I suggested that this type of "control" write accesses shouldn't be defined as bufferable, so you only get a BRESP when the "control" operation has been performed.
As for what qualifies as an "address overlap", I would expect this to be the whole address region defined by the AxADDR, AxSIZE, AxLEN and AxBURST controls.
Finally, the distinction between memory and peripheral regions in the spec is roughly what we have been discussing, namely that memory regions can rely on the AXI slave doing hazard checking against buffered write, but peripheral regions would be I/O type accesses where access ordering may be important with no address overlap detection occurring.
If you want to have some of the memory map as supporting bufferable accesses, you will need to programme this into the AXI master so that it knows what sort of access types it can use. This will normally be done in some sort of MMU or MPU inside the AXI master.
So the master AXI interface then does know the difference between peripheral and memory regions, and if it doesn't, it would have to assume all available memory space is non-bufferable to ensure correct ordering if it has RAW or WAW ordering requirements.
That's my thoughts anyway, maybe someone else will have a different view.
JD
Cancel
Up
0
Down
Reply
Accept answer
Cancel
Reply
0
Offline
Colin Campbell
over 7 years ago
Note: This was originally posted on 26th October 2007 at
http://forums.arm.com
I tried to cover both cases in my earlier reply.
There doesn't need to be any address overlap, as soon as the master sees a BRESP for any write access, it can assume that transfer has been completed.
In the simpler address overlap case, any slave that has buffered the write data will have to do hazard checking for subsequent read accesses.
In a non-overlap case, where I described the write as being a "control" access, as soon as the master sees a BRESP it might attempt a read, assuming the control access has switched whatever needed changing.
That is why I suggested that this type of "control" write accesses shouldn't be defined as bufferable, so you only get a BRESP when the "control" operation has been performed.
As for what qualifies as an "address overlap", I would expect this to be the whole address region defined by the AxADDR, AxSIZE, AxLEN and AxBURST controls.
Finally, the distinction between memory and peripheral regions in the spec is roughly what we have been discussing, namely that memory regions can rely on the AXI slave doing hazard checking against buffered write, but peripheral regions would be I/O type accesses where access ordering may be important with no address overlap detection occurring.
If you want to have some of the memory map as supporting bufferable accesses, you will need to programme this into the AXI master so that it knows what sort of access types it can use. This will normally be done in some sort of MMU or MPU inside the AXI master.
So the master AXI interface then does know the difference between peripheral and memory regions, and if it doesn't, it would have to assume all available memory space is non-bufferable to ensure correct ordering if it has RAW or WAW ordering requirements.
That's my thoughts anyway, maybe someone else will have a different view.
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