• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 92 subscribers
  • Views 16747 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

    I was concerned about the ACACHE[C] bit for the read being set to 0 meaning that the read must not be prefetched.  I took this to mean that the read must come from the final destination and not an intermediate bridge that was "caching" the data due to a previous bufferable write.

    For example, could a device use a read (non-cacheable) to push a previous bufferable write to its final destination to know when it was safe to assert an interrupt, or would that device be required to use a non-bufferable write to achieve this?  It seems to me that using a cacheable read would obtain the new data, but that data could be forwarded by an intermediate bridge.  An interrupt could cause a processor to read the final destination and not see the new data due to the processor read taking a different path.  Does this make sense?

    Also, you bring up a point I was not aware of.  You're saying that a bridge taking a bufferable write must take ownership of RAW hazards for all masters, not just the issuing master.  Is this required behavior for AXI?  Statements about ordering in the spec are master-centric, so I assumed that RAW hazards only applied within a master.

    Once again, you've been very helpful.  Thanks!!!
Reply
  • 0
    Note: This was originally posted on 20th November 2007 at http://forums.arm.com

    I was concerned about the ACACHE[C] bit for the read being set to 0 meaning that the read must not be prefetched.  I took this to mean that the read must come from the final destination and not an intermediate bridge that was "caching" the data due to a previous bufferable write.

    For example, could a device use a read (non-cacheable) to push a previous bufferable write to its final destination to know when it was safe to assert an interrupt, or would that device be required to use a non-bufferable write to achieve this?  It seems to me that using a cacheable read would obtain the new data, but that data could be forwarded by an intermediate bridge.  An interrupt could cause a processor to read the final destination and not see the new data due to the processor read taking a different path.  Does this make sense?

    Also, you bring up a point I was not aware of.  You're saying that a bridge taking a bufferable write must take ownership of RAW hazards for all masters, not just the issuing master.  Is this required behavior for AXI?  Statements about ordering in the spec are master-centric, so I assumed that RAW hazards only applied within a master.

    Once again, you've been very helpful.  Thanks!!!
Children
No data