Arm Community
Site
Search
User
Site
Search
User
Support forums
SoC Design and Simulation forum
More AXI write/read ordering
Jump...
Cancel
State
Not Answered
Locked
Locked
Replies
3 replies
Subscribers
92 subscribers
Views
9873 views
Users
0 members are here
AMBA
AXI
Bus Architecture
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
More AXI write/read ordering
Randy Pascarella
over 12 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
Randy Pascarella
over 12 years ago
Note: This was originally posted on 26th October 2007 at
http://forums.arm.com
Once again, thanks for your helpful responses. I am being more and more convinced that bufferable writes are akin to PCI Posted Writes in semantics (targeting memory regions, whether a memory controller or device memory with no side-effects) while non-bufferable writes are akin to PCI I/O or Config Writes in semantics (targeting peripheral regions like config space with side-effects), even though the ordering rules are somewhat different.
I had always thought that an AXI master would burst data to a memory region with the same AWID and issue a non-bufferable write on the last of the burst just to know that a dependent read could be issued (either a producer/consumer flag type of read or a read with address overlap) and to ensure that the writes made it to their destination.
Now I am assuming that this burst would typically be all bufferable, and the read would end up flushing out the bufferable writes just like PCI. I am also assuming that non-bufferable write usage would follow along the lines of PCI with, as you mentioned, "control" type semantics.
Let me know if I'm still off base here.
Thanks again, very helpful.
Randy
Cancel
Vote up
0
Vote down
Cancel
Reply
0
Randy Pascarella
over 12 years ago
Note: This was originally posted on 26th October 2007 at
http://forums.arm.com
Once again, thanks for your helpful responses. I am being more and more convinced that bufferable writes are akin to PCI Posted Writes in semantics (targeting memory regions, whether a memory controller or device memory with no side-effects) while non-bufferable writes are akin to PCI I/O or Config Writes in semantics (targeting peripheral regions like config space with side-effects), even though the ordering rules are somewhat different.
I had always thought that an AXI master would burst data to a memory region with the same AWID and issue a non-bufferable write on the last of the burst just to know that a dependent read could be issued (either a producer/consumer flag type of read or a read with address overlap) and to ensure that the writes made it to their destination.
Now I am assuming that this burst would typically be all bufferable, and the read would end up flushing out the bufferable writes just like PCI. I am also assuming that non-bufferable write usage would follow along the lines of PCI with, as you mentioned, "control" type semantics.
Let me know if I'm still off base here.
Thanks again, very helpful.
Randy
Cancel
Vote up
0
Vote down
Cancel
Children
No data