DDR4 EMIF VREF pins, Arria 10

[Ju-Ti]

Hi,

DDR4 calibration is failing intermittently on some units of our Arria 10 based product. We use Hard PHY and hard controller. Results from EMIF debug toolkit suggest it is always the per-bit write or read deskew which fails. Sometimes, just as few as 5 calibrations out of 1000 fail, but when it happens, all eight DQ groups of total eight or at least seven of them fail.

So far I have two findings that I'm not sure if they are relevant, so I'd need help:

1) DDR4 banks (three banks for 64 bit data) have their VREF pins connected to DDR4 devices' VrefCA reference voltage of 0.6 Volts instead of GND. Quartus pin report orders GND here and documents mention that FPGA's internal VREF calibration does not need external VREFs. Question 1: could this non-zero VREF voltage have effect on calibration?

2) DDR4 alert signal from DRAM devices has a pull-up of 50 ohms instead of suggested 10k, which is probably a misunderstanding. Question 2: Is it possible that Address/Command phase of calibration is disturbed due to this, and causes later rd/wr data deskewing to fail? Address/Command calibration result is always good. I haven't yet changed this resistor or even measured the signal as it is not well accessible.

Toolkit report data when calibration fails:
+--------------------------------------------------------------+
; Address/Command Margins Observed During Calibration ;
+----------+--------------+------------------------------------+
; Pin ; Margin (ps) ; Delay Setting (Output delay steps) ;
; ADD_16 ; -576 to 566 ; 130 ;    <-- all ok and close to this

; Read Data Valid Windows ;

All DQ and DQS  ; -625 .. [0 .. 0] .. 625 ;   <-- all fail

; Write Data Valid Windows ;
All DQ and DQS ; -625 .. [0 .. 0] .. 625 ;   <-- all fail
All DM ; -625 .. [-283 .. 283] .. 625 ;  <-- small variation, but all DMs are good

Thanks,
Ju-Ti

[Ju-Ti]

Interestingly, checking "Skip address/command leveling calibration" box on Diagnostics tab of parameter editor seems to make calibrations fully succesful. Just Address/command margin for CS_0 in the report changes from e.g.
; CS_0 ; -1503 to 1494 ; 153 ;
to
; CS_0 ; Uncalibrated ; 128 ;

[AdzimZM_Intel]

Hi,

We sincerely apologize for the inconvenience caused by the delay in addressing your Forum queries. Due to an unexpected back-end issue in our system, your Forum case, did not reach us as intended. As a result, we have a backlog of cases that we are currently working through.

Please be assured that we are doing everything we can to resolve this as quickly as possible. This will take some time, and we appreciate your patience and understanding during this period of time. Thank you again for your patience and understanding, and we are committed to provide you with the best possible support.

I saw that you have resolved your issue.

Do you still need help on this forum?

Regards,

Adzim

[Ju-Ti]

Thanks for the update, it's OK.

Problem itself is more or less solved, but answers to those two questions, marked 1) and 2), shown in the original posting would still be very much welcome.

For records and others interested: it was possible to hide the issue from showing up by using "Skip address/command leveling calibration", but that was not the actual solution. I ended up changing several EMIF IP parameters, including drive strengths, skew and impedance matching related ones. It is unclear how the original parameter set in .ip file had been developed.

While investigating, it was interesting that on all tested units, read or write per-bit (data) deskew failed if preceding addr/cmd calibration stage had found a magic result 208. This happened before final good parameters were found.
; CKE_0 ; Uncalibrated ; 208 ;
; ODT_0 ; Uncalibrated ; 208 ;
; RESET ; Uncalibrated ; 208 ;
; CS_0 ; -97 to 87 ; 208 ;
Unfortunate value was always 208. When delay result was something else, per-bit data deskewing succeeded and overall status was Pass.

As said the fix included so many parameter changes that listing them is pointless I think.

BR,

Ju-Ti

[AdzimZM_Intel · Accepted solution]

Hi Ju-Ti,

"Question 1: could this non-zero VREF voltage have effect on calibration?"

• It's may and may not affect calibration process since it's supply to voltage source not to GND. As you can see, the calibration can pass after changing some parameters.
• But it's better to follow the guideline to avoid any conflict in the functionality.

"Question 2: Is it possible that Address/Command phase of calibration is disturbed due to this, and causes later rd/wr data deskewing to fail? "

• It's may not affect the calibration process because I think the alert_n is not used during the calibration.
• Besides, the alert_n signal has been terminated.
• I would say that this might not be the root cause but you can follow the recommendation for the new board.

Regards,

Adzim

[AdzimZM_Intel]

Hi Ju-Ti,

Do you have any further questions in this thread?

Regards,

Adzim

[Ju-Ti]

Hi Adzim,

thank you for the answers. Useful when designing the next board revision, or modifying component values. No further questions.

Regads Ju-Ti

[AdzimZM_Intel]

As we do not receive any response from you on the previous reply that we have provided, I now transition this thread to community support. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.