New Contributor
New ContributorThank you yoichiK for your prompt reply,
So you confirm that Reordering and Starvation cannot be controlled !!!
For me it is a big problem because the host driving the AXI Write channel (the Writer) is fully independent from the host driving the AXI Read channel (the Reader). Moreover, the Reader cannot accept starvation because it drives a video sub-system with determinism and low-latency requirement.
By the way, it is not consistent/rational to handle reordering at EMIF side for effficiency reason and to ask my Reader to wait until the end of the Writer sequence.
Please, find below the Signal-Tap of the EMIF AXI4 R/W interface. On the below pattern, the Writer fully monopolizes the DDR during hundreds of commands (AWVALID/AWREADY). The Reader issue a few commands (ARVALID/ARREADY) then it waits for the data (RVALID) during around 2000 cycles (after the Writer stops), which is not acceptable.
In this use case, the only solution would be to stop the Writer each time the Reader issue a command, which leads to kill the overall efficiency...
If there is no workaround to control priority/reordering/starvation, I would be forced to conclude the Agilex 5 EMIF is not compatible with my need.
Thank you in advance if you have any suggestion...
ContributorI tried to replicate the issue at my side with Agilex5E devkit. and did similar data traffic on hardware.
I use async mode at AXI interface and burst length is 2 with consecutive write access. During consecutive write access one read access is issued and I see rvalid is returned before completion of consecutive write access.
