re: Cyclone V 5CSXFC4C6U23C7N LPDDR2 Why an unexpected SDRAM refresh behavior?

[JFull1]

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.

Usage

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)

Comments

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.

My questions:

What is this 117.4ms waitreq/refresh?

How can we make it stop?

[BoonT_Intel]

Hi Sir,

The additional wait time might caused by DQS tracking feature of the IP.

See this document for details.

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/external-memory/emi_fd_uniphy.pdf#page=24

Please note that this document also include the step to disable the feature. But use it on your own risk.

Thanks

[JFull1]

BCT Thanks again, it was the DQS tracking feature that surprised us. We don't have a file like *_if0_c0.v but we found *_fmem_s0.v that works. I have two follow-on questions: 1.How can we permanently stop DQS tracking? We can stop it with this before compiling, but the file is overwritten by Qsys/Platform Designer: sth31_fmem_s0.v: sequencer_scc_mgr #( .USE_DQS_TRACKING (1), -> "0" BTW, I've found several other files that reference DQS_TRACKING that are overwritten by Qsys but hacking just them before compiling does not change the fmem dqs tracking behavior: sequencer\emif_pre.xml <sequencer> <define name="USE_DQS_TRACKING" value="1"/> -> "0" <controller> <define name="USE_HPS_DQS_TRACKING" value="true"/> -> false sth31_fmem_p0_altdqdqs.v defparam altdq_dqs2_inst.USE_DQS_TRACKING = "true"; -> "false" sth31_fmem_s0_make_qsys_seq.tcl lappend arg_list "--component-param=USE_DQS_TRACKING=true" -> "false" hps_sdram_p0_altdqdqs.v defparam altdq_dqs2_inst.USE_DQS_TRACKING = "true"; -> "false" [not fmem] 2.Disabling FORCE_DQS_TRACKING in .qsys before generating seems to stop normal refresh, as well as dqs_tracking. is this intended? (if so, the name is deceptive) Thanks in advance, John Den 2019-08-13 kl. 04:52, skrev Intel Forums:

[BoonT_Intel]

Hi John,

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.

[JFull1]

BCT

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.

Yours,

John