Using 5CSXFC4C6U23C7N CycloneV with
2x MT42L128M32D1LF-25 WT:A LPDDR2 Micron SDRAM: 4Gb (2Mx32b x 8bank)
Quartus Prime 18.1 Lite Edition
We have noticed a curious feature of the fpga SDRAM:
each 117.4ms the fpga bus towards the SDRAM MPFE is blocked by waitreq for about 8us.
We have setup SDRAM with Alteras default timing parameters, e.g.
(RFCab) = 75 to 130ns (Altera default=75, Micron 130ns)
t(REFIab) = 15.6us (I increased it to 21us for testing)
We can write/fill the SDRAM in about 1 sec.
(two people have written different fill programs)
We see that our bus is halted with waitreq each 15.6us for max 770ns as expected.
It varies if we change t(RFCab) or t(REFIab) as expected.
The wierd thing is the 8us waitreq:
it starts on the same 15.6us t(REFIab) interval as a normal, short refresh.
For example, if I change t(REFIab) to 21.0us, the normal and wierd refresh
each start on 21.0us or multiples.
t(RFCab) changes the short refresh length but has no effect on the wierd refresh length
Both "refresh" waitreq sequences start a random time after the fill begins, as expected since it is autonomous from when we start the fill program.
117.4ms is outside Microns spec: Micron requires refresh cycles to complete
within each 32ms window.
Since it is affected by changing t(REFIab) I presume it is caused by the Altera hard PHY SDRAM controller machine.
What is this 117.4ms waitreq/refresh?
How can we make it stop?
The additional wait time might caused by DQS tracking feature of the IP.
See this document for details.
Please note that this document also include the step to disable the feature. But use it on your own risk.
Yes, regenerate qsys will overwrite the hacking. I don't think we need to always re-generate the files.
I think we only need to hack the master file, for other file, it just a reference only.
I don't think it will disable the refresh as well. If without refresh, the memory module unable to retain the memory correctly.
Thanks for the speedy reply.
First, I'll disable it to determine if it is my problem.
Then we'll examine the LPDDR2 performance over temperature to see if we need to enable it.
It'll take a day or two before I can get back into the lab.