Hi，
In AMBA® AXI Protocol Specification(IHI0022K, A3.4), how to understand the following sentences:
1. When a Manager issues a write request, it must be able to provide all write data for that transaction, without dependency on other transactions from that Manager.
2. When a Manager has issued a write request and all write data, it must be able to accept all responses for that transaction, without dependency on other transactions from that Manager.
3. When a Manager has issued a read request, it must be able to accept all read data for that transaction, without dependency on other transactions from that Manager.
– Note that a Manager can rely on read data returning in order from transactions that use the same ID, so the Manager only needs enough storage for read data from transactions with different IDs.
For question 1, When the Manager issues a write request, does it have to pull WVALID up until the burst is completed?
For question 3, When the Manager issues a read request, does it have to pull RREADY up until the burst is completed? If the answer is yes, then what is the function of RREADY?
For example, if a Manager needs to read 16 pieces of data, increment each by 1, and then write them back, can it first issue a burst read request for 16, then after receiving and processing the first data piece, store it for one clock cycle and then issue a burst write request of 16? In this case, if the Subordinate cannot return the read data, then the Manager will pull WVALID low, and if the Subordinate cannot accept write data, then RREADY will also be pulled low. Does this behavior comply with the protocol requirements?
The answer to both your questions is "no".For the write transaction the protocol is stating that the manager must be able to provide all the write data for the indicated transaction length, but there could be stalled cycles in that series of write transfers when WVALID is driven low. The reason for this text is to avoid stalling the downstream logic for excessively long periods of time if the write data is relying on other transactions completing first. The manager doesn't know when those other transactions will complete, so it shouldn't issue the transaction until it knows all the write data is available (the transfers that data availablity relies on have completed). For example the write data could be coming through a clock domain crossing bridge, which adds delays while each write data transfer is synchronised. The data will be coming, and isn't reliant on other transactions completing first, so there will be "bubbles" in the write data stream when WVALID goes low, but not massive delays that could be seen if the delay was waiting for other system events to complete.
And on a similar note, the manager must be able to accept all the read data it has requested. If the manager has limited data storage and is relying on write transactions emptying that storage while the read data is coming in, it should issue shorter read transactions matching the available read data storage space. If we did allow the manager to rely on other transactions (write transactions in this example) to complete before some of the read transfers can compete, this again could have big latency impacts on the downstream logic. So you can see RREADY go low during read transaction sequences, but this should only be as a result of small delays on this timing path (again the example of a clock domain crossing adding "bubbles" to the data flow), and not significant delays caused waiting for other transactions to complete to allow this read transaction to continue.
So your described example would fail those requirements as there is a very clear dependency between the read and write transactions. The manager in this example would need to be able to store the 16 data values being read, and only commit to write them out when all 16 have been received.
Thank you very much for your answer