• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 15843 views
  • Users 0 members are here
Options
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

AXI Cacheable vs. Bufferable

Randy Pascarella
Note: This was originally posted on 19th November 2007 at http://forums.arm.com

If an AXI slave acting as a bridge has accepted a bufferable (ACACHE[0]) and cacheable (ACACHE[1]) write and responded with BRESP, is it required to flush this buffered write when later accepting a read from the same AXI master that overlaps but is marked as not cacheable?

In other words, should the cacheable bit be used in determining when bufferable writes should be flushed, or is flushing only required as noted in the spec upon receipt of a non-bufferable write with matching AWID?
Parents
  • 0
    Note: This was originally posted on 20th November 2007 at http://forums.arm.com

    Hi Randy,

    I would think that a slave which decides to give a BRESP for a bufferable write before the write data reaches the eventual destination is taking responsibility for any hazard checking for subsequent reads or writes, from the same or different masters.

    A non-bufferable write would need to flush the write buffer to maintain the correct system event ordering, but a read could just be handled by forwarding write data from the write buffer if a hit is detected, rather than delaying the master while the write buffer is flushed.

    The cacheability (is that a real word ?) of the read shouldn't affect whether the buffer is flushed or not.

    Or am I missing a more subtle problem ?

    I guess if you wanted to make the system foolproof (and simpler), flushing the write buffer for any subsequent read access would ensure you are accessing the most recent data.

    JD
Reply
  • 0
    Note: This was originally posted on 20th November 2007 at http://forums.arm.com

    Hi Randy,

    I would think that a slave which decides to give a BRESP for a bufferable write before the write data reaches the eventual destination is taking responsibility for any hazard checking for subsequent reads or writes, from the same or different masters.

    A non-bufferable write would need to flush the write buffer to maintain the correct system event ordering, but a read could just be handled by forwarding write data from the write buffer if a hit is detected, rather than delaying the master while the write buffer is flushed.

    The cacheability (is that a real word ?) of the read shouldn't affect whether the buffer is flushed or not.

    Or am I missing a more subtle problem ?

    I guess if you wanted to make the system foolproof (and simpler), flushing the write buffer for any subsequent read access would ensure you are accessing the most recent data.

    JD
Children
No data