AXI4 Use of Device Memory Types - Write Burst How to perform a write burst on a memory device with AXI Interface?
Posted 18 June 2012 - 05:12 PM
I am using the AXI4 protocol to access a memory device.
The page 74 from the Specification, under the title "A4 Transaction Attributes" - "A4.9 Usage examples" is empty.
I am trying to solve the following problem: I need to transfer a burst of words from a FIFO into a memory device. However, I need to wait four cycles for each word to be ready. That means I cannot have the axi_wdata changing every cycle, and so axi_wvalid will not be asserted during the entire burst. This is possible, right?
I am seeing that axi_wvalid signal does not need to wait for awvalid signal. Does this mean that in a burst, I can perform all write channel transfers and only at the end to assert axi_awvalid, axi_awaddr, axi_awlen, etc? If so, how do I now that the internal fifos of the slave are full if the axi interface does not have such a specific signal? I see that bresp is used for such cases, but it also says that there is only one response for each burst and not for each transfer.
Additionally, I am looking at the memory types of the specification. I believe that my device is non-cacheable but bufferable, because it has internal fifos. In this case, it is stated the writes can be merged. Is merging of writes the process that I am describing above? If so, why can't reads be obtained from an intermediate point?
Looking forward for your answers.
Posted 19 June 2012 - 10:28 AM
Not in IHI 0022D.
Yes. However, I would suggest that you buffer data received from the FIFO somewhere, before writing to the destination in a contiguous burst. Since write interleaving is not legal in AXI4, you'd otherwise occupy the write channel for much longer than necessary. Another option would be to use single-item write transactions.
To answer your question: If an internal buffer ran full, the slave would simply deassert WREADY. But how would this unusual transaction scenario help with your issue above?
The master wouldn't know whether and how exactly the slave optimized the read access so it wouldn't know how to take things apart again.