The UniPHY (v16.1) DDR3 SDRAM controller in my Stratix V design a shows much larger than expected latency. The DDR3 refresh is not user controlled.
Largest read latency so far observed is around 1850 afi_clk cycles before rdata_valid is asserted after a single burst read request. This is in the order of 100 times larger than expected. I observe this both in simulation and on target, and i`m wondering how to resolve this. Hints welcome.
As i understand it, you are having problem with the read latency value which is much higher than expected on your controller. The latency is depend on how the traffic pattern and the controller operates.
However, seems like the current observed latency is too high as compared to the expected latency. So, I suggest you to generate the example design first and then, compare the parameter of your design and the golden design. You can refer to this handbook page 986 under chapter Uni-PHY Based Example Design.
For your reference, this is another design example for "Stratix V DDR3 SDRAM UniPHY 666MHz Quarter Rate". The wiki version is older and I recommended you to use the newer version.
Anyway, there is several technique and setting that can help to improve efficiency and latency of the IP. You can refer to page 593 under chapter “Ways to Improve Efficiency” in this shared link.
Hope this helps.
The last reference is about how to get a few cycles off on the average latency. The average latency is as expected, so that is fine. However at 50ms intervals (in that order) i see a latency which is about 100 times larger than average. This is a problem in my design. I wonder where this comes from. Refresh interval is in this order (32ms / 64ms), but should not take this long.
I`m not looking for a way reduce the average latency with 1 or 2 cycles, but i want to understand where the very high max latency comes from.
The additive latency of 1 or 2 cycles is expected to allows the device holds the commands internally for the duration of additive latency before executing. This explained in EMIF handbook (page 596).
All latency that documented is the predetermine latency. However, you might still see some additional latency in actual hardware. This is because when the controller is work in actual hardware, it might introduce the additional latency which take into account of board trace delays, different process, voltage and temperature scenarios. Other than that, the additive latency also might introduce by the traffic pattern on the master component.
I am really sorry to say that we do not have a latency specification for the controller, so it nothing else we can pursue here.