ALTMEMPHY - No Clocks - RefClk Slew Rate Requirements?

[Altera_Forum]

I'm debugging a Cyclone IV E design. The DDR2 interface is dead in hardware but simulates okay. Signaltap shows two out of three DIMM clocks dead. I scoped the 50 MHz reference clock and the rise and fall times are larger than the high and low time (about 5ns each). The external oscillator drives six (!) clock inputs so rather heavily loaded. 

 Would an ALTPLL instance have trouble locking onto a reference clock with too low slew rate? I have not been able to find any official information directly from the Altera documentation.  Also, the engineer has incorrectly assigned the clock locations. The positive and negative signals in the pairs are not in adjacent locations giving these warnings in Quartus II:  Warning (176684): Unable to place CK/CKn pair mem_clk[2] and mem_clk_n[2] on a differential pin pair because they have been assigned to incompatible pins not belonging in the same pair Warning (176684): Unable to place CK/CKn pair mem_clk[1] and mem_clk_n[1] on a differential pin pair because they have been assigned to incompatible pins not belonging in the same pair Warning (176684): Unable to place CK/CKn pair mem_clk[0] and mem_clk_n[0] on a differential pin pair because they have been assigned to incompatible pins not belonging in the same pair  I'm trying to figure out if the current board can be made to work or if the engineer has to re-spin the board with corrected clock locations.  Thanks!

[Altera_Forum]

Yes - a number of the factors you mention may adversely affect the ability of the PLL to lock. A poor slew rate will affect the perceived high/low time ratio the PLL sees, which it will care about. Point of note: is your oscilloscope up to measuring this accurately? Using a scope with an unsuitably low bandwidth will also have this effect, even if the wave shape is in fact good. 

 Having six loads on the oscillator is also going to affect the wave shape and could easily cause the PLL further locking problems.  Does the PLL report it has lock? You can implement the PLL with such an output signal, typically available by default.  Try unloading the oscillator. Can you remove some of the loads? This will need to be done carefully so as not to leave stubs. You may end up having to cut tracks to do this effectively.  As for the poor clock pair selection - only a re-spin is going to solve that. However, a bit of a long shot but - depending on the signalling standard of your clock source, you may find that one half of your differential clock could be used as a single ended input clock to the FPGA.  Cheers, Alex

[Altera_Forum]

Thanks Alex for the response. It looks like the ALTMEMPHY/HPCII Controller PLLs lock since I'm actually seeing the correct clock frequency being output onto the DIMM connector.  

 Edit: I have confirmed via signaltap that the PLL locks onto the reference clock right before the test_status transitions from 00h to 01h.  There are however a few strange behaviors I have not seen in my prior ALTMEMPHY DDR2 interface design:  1) I cannot see more than one of the three DDR2 clocks in signaltap (six when counting the negative signals, too). Upon inspection of the schematics, the clock signal that is seen (clk0+) is connected to a pin part of a DQ group, while the other five (clk0-, clk1+, clk1-, clk2+, clk2-) are connected to regular I/O pins. Surely, it is not a coincidence that the only clock seen in STP is the one connected to a DQ-capable pin? Also, note that all six of these clock signals output correct SSTL-18 frequencies (I've tested 125 MHz as well as 133 MHz).  2) The ALTMEMPHY Debug Toolkit cannot connect to the ALTMEMPHY instance. I have enabled the 'debug port' per the ALTMEMPHY IP User Guide (adding alt_jtagavalon instance to the Megawizard top-level design). When spawning the ALTMEMPHY debug toolkit it doesn't show any instance to connect to. I've in the past done this successfully for an ALTMEMPHY-based DDR2 HPCII controller for Arria II so should work for Cyclone IV too?  3) No activity can be seen in the signaltap trace except for the test_status changing from 0 to 1 half-way in the trace.   4) Everything else works properly on this board (lots of I/Os, Ethernet interface etc) so it is clear that the FPGA is functioning. I'm strongly suspecting the incorrectly placed clock pins to be the culprit but can't prove this. It would be unfortunate to re-spin this expensive board without knowing the exact cause (and cure) of the issue.  Finally; I have a good scope. A 2.5 GHz active probe was used and the scope is a 13 GHz Agilent Infiniuum. Also, the 50 MHz reference clock tree can't be cut on the board since routed on inner layers.

[Altera_Forum]

I have, via Signaltap, traced the error to a failure in the below altmemphy state: 

 State.s_rrp_seek Read resynchronization phase setup stage: set PLL to center of valid window. dgrb_ctrl.command_err Error in the data gather read bias block. dgrb_ctrl.command_result[7..0] Data gather read block (DGRB) error code.  The error code is 05h.  Can anyone shed some light on what, exactly, this means?  I will do my best to Google for an answer...  STP screenshot attached.  Thanks!

[Altera_Forum]

Please disregard; I found the error. The HPCII controller was configured for two chip select signals while the DIMM only uses one! The calibration and sample test now work fine.