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

Write Data Interleaving - AXI

Amaresh Chaligeri
Note: This was originally posted on 19th March 2009 at http://forums.arm.com

Hello,

Can anybody help me to understand the reasoning behind write data interleaving ordering restriction imposed by AXI spec.
[Chapter 8.5  Write data interleaving]

"The order in which a slave receives the first data item of each transaction must be the
same as the order in which it receives the addresses for the transactions."

Thanks in advance,
Amaresh
Parents
  • 0
    Note: This was originally posted on 20th March 2009 at http://forums.arm.com

    Hi Amaresh,

    The only reason I can think of for this rule could be to simplify slave designs where the slave can store a greater number of address transactions than it can accept interleaved write data for, i.e. it has a "write_acceptance_capability" greater than the "write_interleave_depth".

    I would expect the slave designer would want any interleaved write data to be for the earlier accepted addresses, so by insisting that the first write data follows the order of the addresses, the slave knows that any interleaved data following the first transfers will be for the oldest addresses, and once a data sequence completes, the slave can then move a stored address transaction parameters up to control the now free data receiving buffer.

    To try to give an example (as the above doesn't clearly explain what I'm thinking). imagine a slave with a "write_acceptance_capability" of 4 addresses (A,B,C and D received in that order), but only a "write_interleave_depth" of 2 transactions, I would think the slave design would use the A and B transaction details to setup the write data buffers, and store C and D controls elsewhere.

    By the protocol requirements, the first received data must be for A, for which a data buffer is already set aside.

    Then we can have further data for A (which the slave is ready for), or we can have the first data for B, again for which the slave has a data buffer for.

    From this point on, the "write_interleave_depth" parameter means only data for A or B can be received.

    When either A or B completes, the slave can move the control information stored for C up to a data buffer, and it is then prepared to receive first data from C.

    If we allowed data from any of A, B, C or D to come along first, the slave wouldn't know which address info to use for the buffer until this first data is seen.

    This solution also ensures that the older addresses do get completed before the newer addresses, so preserving some sort of system event order.

    I'm not saying that is how slaves MUST handle transactions, but it might apply for some slaves, and does then explain a reason for this protocol requirement.

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

    Hi Amaresh,

    The only reason I can think of for this rule could be to simplify slave designs where the slave can store a greater number of address transactions than it can accept interleaved write data for, i.e. it has a "write_acceptance_capability" greater than the "write_interleave_depth".

    I would expect the slave designer would want any interleaved write data to be for the earlier accepted addresses, so by insisting that the first write data follows the order of the addresses, the slave knows that any interleaved data following the first transfers will be for the oldest addresses, and once a data sequence completes, the slave can then move a stored address transaction parameters up to control the now free data receiving buffer.

    To try to give an example (as the above doesn't clearly explain what I'm thinking). imagine a slave with a "write_acceptance_capability" of 4 addresses (A,B,C and D received in that order), but only a "write_interleave_depth" of 2 transactions, I would think the slave design would use the A and B transaction details to setup the write data buffers, and store C and D controls elsewhere.

    By the protocol requirements, the first received data must be for A, for which a data buffer is already set aside.

    Then we can have further data for A (which the slave is ready for), or we can have the first data for B, again for which the slave has a data buffer for.

    From this point on, the "write_interleave_depth" parameter means only data for A or B can be received.

    When either A or B completes, the slave can move the control information stored for C up to a data buffer, and it is then prepared to receive first data from C.

    If we allowed data from any of A, B, C or D to come along first, the slave wouldn't know which address info to use for the buffer until this first data is seen.

    This solution also ensures that the older addresses do get completed before the newer addresses, so preserving some sort of system event order.

    I'm not saying that is how slaves MUST handle transactions, but it might apply for some slaves, and does then explain a reason for this protocol requirement.

    JD
Children
No data