DDR2 highperformance controller local_init_done, s_tracking_setup deadlock

[Altera_Forum]

Dear all, 

 I'm using DDR2 hp memctrl IP within Stratix III, addressing 2 parallel HYB18T1G160C2F-3S (totaling to 32-bit data bus width), phy_clk = 200 MHz   I'm currently facing the issue, that local_init_done signal is not going high reliably (sometimes it does, sometimes it doesn't). I suspected something in the outputs (address, ba etc.) drive strength first, but increasing drive strength didn't help so far. When going a little into the initialisation process I found a state signal "s_tracking_setup" which stays forever (see ddr2Bad.jpg) where it goes on to "s_prep_customer_mr_setup" in the good case (ddr2Good.jpg).   According to the external memory debugging manual (http://www.altera.com/literature/hb/external-memory/emi_debug_hw.pdf), during "s_tracking_setup" is the state for (internal?) voltage and temperature initial tracking setup is done, which I to my interpretation is a purely FPGA internal subblock. I've seen a dependance on FPGA temperature (initialisation fails more often when FPGA gets warm/hot). What could go wrong here? Is this dependant of external (memory, PCB) timing, too (I wouldn't expect)? Any hint what other DDR2 HP CTRL internal signals to observe to find out more? Has anybody experienced similar behaviour? What parameters could be wrong?   Thanks for any hint! Regards, Peter   P.S.: In the good case, I see current consumption, which is higher than expected/estimated with the noted frequency. I know that FPGA @ 200 Mhz uses some power, too, but still uses 30-50% more than expected... ...could there be a relation?

[Altera_Forum]

It showed that it must actualy be a timing issue of some sort. A subsequent compilation (I just added some signals in the SignalTap) did not show the behaviour (no deadlock in DDR2 HPC initialisation). I had no timing analyzer warnings in all the versions (i.e. timing closed), and the DDR2 generated .sdc is in place where it should. Any hint in which direction to push? 

 Regards, Peter

[Altera_Forum]

If I understand your problem correctly, the PHY calibration doesn't always pass, thus the low local_init_done signal. 

 I have some question: - Is this hardware/simulation? - If this is hardware, I assume that in one compilation flow, calibration doesn't always pass. Am I correct? - If yes to above question, this is most probably calibration timing problem. Then you'll have to look at TimeQuest report, does your design pass timing marginally?  Hope that helps.

[Altera_Forum]

Hi Yuying 

 Concerning your assumptions: - It is hardware (using EP3SL50F780C2N FPGA) - Timing Analyzer does allways pass. However, I'll check the report in detail. Do you know which signal / signal groups are related to the s_tracking_setup state (I read about voltage/temperature compensation control in the manual, but have no clue which physical elements / signals are involved)?   Further more, I migrated the a primitive sample design to the Stratix III evaluation board (due to another reason), which is using EP3SL150F1152C2N. The same issue shows up there as well. And I have now even two error cases, one temperature-inverse (which puzzles me even more). I attached the demo case, with the two .sof error case files:   - good at low temperature, bad at high temperature (DevKit_100702_V02.sof) - bad at low temperature, good at low temperature (DevKit_100702_V03.sof)   Regards, Peter

[Altera_Forum]

Hi Peter, 

 I don't have a Stratix III Dev kit with me right now. From the temperature case which you described, it confirms my suspect on calibration failure.  - May I know which version of Quartus are you using? - Also, you might want to try out the ALTMEMPHY Debug Kit:  w_w_w.altera.com/literature/hb/external-memory/emi_debug_hw.pdf?GSA_pos=1&WT.oss_r=1&WT.oss=altmemphy%20debug%20RAM  (See chapter 4, sorry couldn't post links cause I don't have enough post counts, replace "w_w_w" with "www")  Most probably your problem is caused by "resynch clock phase", but those are only my guesses.  p/s: you'll have to look at the non-leveling calibration portion because this is DDR2.  Hope that helps.

[Altera_Forum]

I instrumented the design as required for the debugging tool, according to the emi debugging manual. Actually, I haven't seen the issue described above since instrumentation (which does not mean that it may still exist latently), but thats only the lesser thing right now: 

 Starting the debugger proves to be little difficult. I was using Quartus 9.0, the debug tool stated "the release of the debuggui does not match version of altmemphy used to generate hardware you are trying to connect to. this may not work. do you want to continue?" Actually it doesn't work (no output).   I downloaded the moste recent Quartus II 10.0, howver, the debug tool reacts with the same problem. So I proceeded and tried with 9.1, 9.1SP1, 9.1 SP2. Why is this SW not working?   What I noticed is: The "debug-toolkit.exe" as referenced to in the manual, is not part of the  debug-toolkit.zip package. The "debuggui.exe" (which starts a similar GUI as seen in the manual) produces the issues above. The "scan.exe" is not executabled (jtag_client.dll was not found). Any idea?  Regards, Peter

[Altera_Forum]

Some other ideas: 

 Have you added board trace models to Quartus so that it accurately sets the delay chains? Have you done a board sim to check SI? Have you set the address/command clock phase correctly?