• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 15009 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 Read/Write ordering

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

Hello,
   Section 8.6 of the AXI spec says that reads and writes have no ordering restrictions between them.  It then says that if a RAW dependency exists, the master must wait for the write to fully complete before issuing the read.  If the write is bufferable, the response comes from the AXI target.  If that target is a bridge to another I/O or host protocol, what should the master expect?  I can think of two answers:

a) Master must punctuate a series of bufferable writes with a non-bufferable write (same AWID) to ensure that all write data has reached the final destination.  Non-bufferable write response receipt indicates the read may then be issued.

-or-

b) Master assumes that the target device will maintain RAW ordering beyond AXI.  Master issues a series of bufferable writes (same AWID) and issues the read once the last bufferable write response has been received.  Writes are buffered in the target bridge and the read then causes the target bridge to flush out the bufferable writes before issuing the read on the other side.

The RAW dependency can be either an address collision with a previous write, or perhaps a previous write has side-effects that may affect the read, such as opening up a window of memory space for the read to access.  Is the type of RAW dependency expected to change the master's choice of bufferable vs. non-bufferable write?

Any comments?  What does AXI require here?

Thanks!
Randy
Parents
  • 0
    Note: This was originally posted on 25th October 2007 at http://forums.arm.com

    Hi Randy,

    All the AXI spec requires for RAW hazards is that the master waits until it has received a BRESP before issuing the READ access.

    If an intermediate AXI slave block has given a BRESP before the bufferable WRITE data reached the actual destination block, that intermediate block must take responsibility for any RAW hazard checking.

    I don't think then that it matters whether the master uses buffered or unbuffered WRITE transactions, it should be able to assume that when it sees a BRESP, it can then issue a READ transaction, and you certainly wouldn't want to force the master to use unbuffered WRITE transactions to ensure RAW hazard checking further down the line.

    As to how the slave does the hazard checking, I guess it can either check the READ address against entries in the WRITE data buffer, or, as you said, flush the WRITE buffer contents regardless of address before performing any READ.

    You did mention the possibility of a previous WRITE having side effects that may affect subsequent READs, but for this type of "control" WRITE access I would not expect it to be of type bufferable, so RAW hazards wouldn't apply.

    I/O or control WRITE accesses would almost certainly be unbuffered so that the master knows that the access is performed when it requests it, and not at some point later when a write buffer drains.

    Hope that helps,

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

    Hi Randy,

    All the AXI spec requires for RAW hazards is that the master waits until it has received a BRESP before issuing the READ access.

    If an intermediate AXI slave block has given a BRESP before the bufferable WRITE data reached the actual destination block, that intermediate block must take responsibility for any RAW hazard checking.

    I don't think then that it matters whether the master uses buffered or unbuffered WRITE transactions, it should be able to assume that when it sees a BRESP, it can then issue a READ transaction, and you certainly wouldn't want to force the master to use unbuffered WRITE transactions to ensure RAW hazard checking further down the line.

    As to how the slave does the hazard checking, I guess it can either check the READ address against entries in the WRITE data buffer, or, as you said, flush the WRITE buffer contents regardless of address before performing any READ.

    You did mention the possibility of a previous WRITE having side effects that may affect subsequent READs, but for this type of "control" WRITE access I would not expect it to be of type bufferable, so RAW hazards wouldn't apply.

    I/O or control WRITE accesses would almost certainly be unbuffered so that the master knows that the access is performed when it requests it, and not at some point later when a write buffer drains.

    Hope that helps,

    JD
Children
No data