HP DDR2 Controller fails Calibration/Initialization

[Altera_Forum]

Hye all, 

 I'm trying to get a DDR2 HP Controller running on some custom hardware, but it fails during calibration..  Target is an ArriaIIGX (EP2AGX45CU17C6), RAM is a single Micron MT47H64M16HR-3E. I'm running Quartus 10.1SP1 paid version..  Simulation passes although I have only used the generic altera model included from the MegaWizard.  I don't have information about the board traces so i couldn't enter this information :(  I've run the debug tool and this reports a failure during 'tracking':  Calibration Failed An error occurred during Tracking. Please contact Altera. The checksum of the calibration process is 0x72077310  If I check the debug-tool tab 'Vizualization' it reports a message "Warning: The IRAM data for this calibration stage appears to be inconsistent, please contact Altera" on the bottom of the screen..  How likely is it that this is a timing problem? I've seen in some other post a reply suggesting timing problems would more likely cause read/write inconsistencies and not calibration failures.  I've measured the clock to check for jitter but it seems fine.  Any suggestion in what direction i should search? Besides faulty hardware i'm running out of ideas..  Thanks!  Olaf   Update:   It seems the initialization runs fine till the state s_tracking_setup, in this state the PLL is stepping to find the best data window i guess, the dgrb_ctrl.command_error flag is set with an dgrb_ctrl.command_error of 0x07, indicating an error in the data gather read bias block.  Sadly there is no information available about this error (command_error 0x07).

[Altera_Forum]

Update: 

 I may have found a possible error (and possible cause for problem described above) in the circuit:  VREF for bank 8 is not connected, at first I thought this wouldn't be a problem because all inputs that use the SSTL 18 CLASS I i/o standard are connected to bank 7 of which the VREF pin is connected.  The DDR2 CLK is connected to bank 8 and I realized that the DDR2 controller IP uses the input buffer to read back the clock to compensate for delays (MIMIC path), so VREF for this bank should also be connected. I think this would explain the initialization failure..  Now I'll just have to wait for the boardrevision to come in.  I'll post a confirmation when I've confirmed that this was the problem.  Cheers,  Olaf

[Altera_Forum]

Indeed what was described above was the issue, got my new hardware revision and everything is operational now! :D 

 Grtz,  Olaf

[Altera_Forum]

We had the very same problems and it turned out that it is the same root cause. Thanks for sharing your thoughts and solution with this issue! 

 Since we cannot wait for the next HW revision, I had to find a simple fix for our stock boards: For the moment I instantiate a second pair of differential clocks on unused pins of the primary bank, which already manages DQ with a proper reference voltage. Next I made these clocks the ‘main’ clocks mem_clk[0]/mem_clk_n[0]. My non-readable clock pins, that are actually connected to the memory devices, are now specified as a second pair mem_clk[1]/mem_clk_n[1] in MegaWizard. In this way, the unconnected pins can be used for calibration tasks, and the connected pins drive the memory. This worked out of the box. I will use a lower clock as I expect the calibration to be less accurate if the pins used for calibration don’t have any load.  What puzzles me is that the HPC II memory controller from Quartus II 9.1 SP2 worked without this trick, but from a quick code inspection I would reckon that this version uses the clock pin mem_clk[0] as an input, too. So the question is, why it works in 9.1 but not in 10 onwards. We already considered going back to 9.1 for this very reason, but I feel much more comfortable using this hack on a more recent Quartus release with final Arria II GX support than the old 9.1 with just preliminary timing. Well … HPC II itself still has preliminary support on Arria II GX, but in general we don’t want to trust 9.1 regarding timing.

[Altera_Forum]

--- Quote Start ---  We had the very same problems and it turned out that it is the same root cause. Thanks for sharing your thoughts and solution with this issue!  --- Quote End ---   I agree :). Posting stuff like this is very helpful for others (like me). I just got a board back with the same problem. Apparently the .pin file will not tell you to connect VREF to 0.75V if mem_clk, but no other SSTL "inputs", are in a bank. Anyway, we found another workaround that I am attaching to this post. (BTW our design uses DDR3 not DDR2.)  There must be a reason for them using the single ended buffer, so I don't think this workaround is good forever, but it is acceptable for testing your design until you get your re-worked board.  Regards, Keith