Forum Discussion
Occasional ContributorDDR4 EMIF VREF pins, Arria 10
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
Occasional ContributorThanks 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
