Write Data Interleaving - AXI

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

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