Version Found: DDR4 v2.2
Version Resolved: See (Xilinx Answer 69035)
In earlier versions of the AXI shim for the DDR4 controller there was a logic error that was not correctly tracking the Wait and Starve Limit counters.
This results in lower than expected performance with certain AXI arbitration settings when there are a stream of commands in one direction (Write or Read) and then a single command in the opposite direction is inserted.
When looking at the AXI traffic, this would manifest as the single write or read command taking much longer to complete.
The AXI arbitration settings that could potential run in to this issue are Read Priority (RD_PRI_REG) and Read Priority with Starve Limit (RD_PRI_REG_STARVE_LIMIT) when both Write and Read AXI commands are simultaneously issued to the controller.
In the specific instances where this long latency condition occurs there are a stream of AXI Write commands that have a smaller transaction length than the AXI Read commands.
During the stream of AXI Writes an AXI Read is issued but it takes much longer than the Wait or Starve limits for the AXI Read command to be serviced while multiple AXI Write commands are serviced.
The mechanism that caused this behavior was an issue with the Wait and Starve counter logic that would cause the Wait and Starve counters to be reset every time a new AXI Write command is accepted.
When the AXI Write command is accepted and then an AXI Read is accepted, the first AXI Write command data is received before the controller has the AXI Read data available.
When the Write data for the first AXI Write command is received, the arbitration logic then erroneously clears the Wait and Starve counters and then accepts a new AXI Write command.
This causes the AXI command arbiter to process many more AXI Write commands before eventually servicing the AXI Read command.
Because the arbitration logic error is present in both the AXI Write and Read Wait/Starve limit counter logic, the same condition described above can occur when there are a stream of AXI Read commands with small transaction lengths and an AXI Write command is inserted in to the stream of AXI Read commands.
In the 2018.1 release of Vivado (DDR4 v2.2 (Rev. 4)) the AXI shim command arbitration has been corrected so that the Wait and Starve limit counters are not reset every time a new Write or Read command is accepted.
This fixes the performance issues seen with Read Priority (RD_PRI_REG) and Read Priority with Starve Limit (RD_PRI_REG_STARVE_LIMIT) arbitration settings for the specific workloads that were described above.
During the test case where an AXI Read command was inserted into a stream of smaller continuous AXI Writes, the total amount of time from when the Read command was accepted to when the Read data was available was reduced to 55% of the original amount of time.
The resulting latency is expected based on the AXI Write access pattern and the DDR4 protocol latency to precharge and activate a new bank to service the AXI Read command.