The full guideline and checklist can be downloaded here.
The guideline will be separated into 5 categories:
1. Quartus II related parameter impact
2. Basic board design impact
4. Known issues
5. Known HPS issues
1. What is the basic UniPHY IP related parameters that will impact calibration?
i. Will the calibration fail if board parameter settings not enter correctly?
A: Yes. Calibration is board specific and will need the information on the board setting tab to be entered correctly. Run board trace simulation to determine the board traces delays and entered it correctly.
Choose the Setup and Hold Derating factor as what is specified on the memory vendor datasheet.
ii. How important is the timing parameter in calibration issue?
A: Incorrect timing parameters such as CAS latency, address and command to write data alignment may cause calibration to fail. It will fail during write latency calibration stage for UniPHY.
Memory parameter will need to follow the information on the vendor datasheet.
iii. Should I regenerate the IP if I’ve just upgraded the Quartus II version? (14.1 to 15.0?)
A: Yes, you should always regenerate the IP when moving from one version of Quartus II to another. This is to ensure the project has the correct version of UniPHY and controller. You will have the latest UniPHY but you still have the old controller if the IP is not regenerated.
iv. Will implementing over constraints cause calibration failure?
A: It could be. Please ensure that you fully understand the impact of the specific over constraints to the EMIF functionality before implementing the constraint on the design.
v. How do I check for the release clears before tri-states setting?
A: Release clear before tri-states setting will affect calibration failure for non V series devices. To check for release clear before tri-state setting: Assembler>Settings>release clears before tri-states
Both the setting and default value should be ‘off’
If this is not at ‘off’ stage, please add the below assignment in the QSF file:
“set_global_assignment -name RELEASE_CLEARS_BEFORE_TRI_STATES OFF”
vi. Does port definition important in VHDL?
A: Yes. Port definition and assignment are important in VHDL as wrong definition will cause Quartus II unable to connect the ports properly. And this might cause the design unable to come out of calibration.
vii. Will operating out of product specification cause calibration failure?
A: I might be. Always refer to the supported configuration and frequency on the spec estimator.
2. What are the basic board designs that will impact calibration?
i. Why does the CK signal needs to be longer than DQS signals on the PCB?
A: The CK needs to be longer than DQS because only the DQS signals can be adjusted (delayed) during calibration.
ii. Will DQ/DQS, addr/cmd, RZQ, RREF terminations and pull-up/down resistor on power rail have an impact on calibration?
A: Yes. Signal termination is important in ensuring signal quality and signal integrity.
iii. How do I check if it is noise/jitter from other part of the board cause the calibration failure?
A: Noise or jitter from other interface or operation can corrupt the interface signal. Always debug in quiet condition or switching off all the other operation on the board and run the standalone design which has the problem.
iv. Can I use 2 different memory devices interchangeably on the same board?
A: If you are using 2 different memory devices (interchangeably) in the same board, compile 2 different designs with the specific memory parameter for each of the memory device that you are using.
v. Can I have the mem_reset_n signal terminated to Vtt on the board?
A: No. Altera recommends not terminate mem_reset_n at all. The Micron spec does not mention any pull-ups or pull-downs either. Please confirm the board termination is align with JEDEC specifications.
vi. Can I remove the Vtt termination on the Addr/Cmd signals?
A: No. Please make sure the Vtt is terminated and de-coupled properly.
3. Does design with timing not close on all corners may cause calibration failure?
i. Will there be calibration failure if timing is not close on all corners?
A: It might be. Quartus II design must have timing close on all corners .
4. What are the FIXED known issues that caused calibration failure?
i. Will this be related to the PLL global issue?
A: It might be. Have you check the PLL phasdone and lock signal? If that is stuck low, it is related to the PLL global issue.
ii. Will this be related to the DQS global issue?
A: It might be. To confirm, you have to monitor the dll_delayctrl signal in Signal Tap and observed the transition when Read data from Read FIFO is corrupted. This issue is fixed in the Quartus® II version 14.1.
iii. Will this be related to the HMC-IOREG global issue?
A: The HMC-IOREG global issue does not cause calibration failure. This issue is fix in the Quartus version 13.0SP1 DP5 (Arria V and Cyclone FPGA) and 13.1 ( Arria V SoC and Cyclone V SoC) and onwards.
iv. Will it be related the DM calibration issue?
A: Maybe. Older calibration sequence for the DM pin is not optimum and this may cause calibration failure. Check the calibration report for the data valid window for the DM pins. If the data valid window is zero, then it is related to this issue. Update to Quartus® II 13.0 and onwards for the fix for this issue.
5. What are the FIXED known HPS issue which has been fix in the latest Quartus® II verison?
i. HPS SDRAM calibration failure in Quartus® II version 13.1.1 and 13.1.2
A: It might be. Customer using Quartus® II version 13.1.1 and 13.1.2 will encounter SDRAM calibration failure in Stage1, Sub-stage 1. This issue is fix in Quartus® II version 13.1.3 and onward.
ii. High current drawn on Vref pins for HPS DDR3
A: It might be. This issue can cause failure in calibration process when customer is using Quartus® II version 13.0 or 13.0SP1. This issue has been fixed in Quartus® II version 13.1 and onward
iii. Will this be related to the HPS PLL lock issue?
A: It might be. This issue can cause failure in any stage of calibration process. This issue has been fixed in Quartus® II version 14.1. Also, patches are available for customer using Quartus® II version 13.1 and 14.0. This issue has been fixed in Quartus® II version 14.1 and onward
5. What are the additional information should I submitted in the Service Request for further assistance from the factory application team?
i. Basic design/project information with archive project attached.
ii. List out the failing condition.
iii. Prepare a SignalTap2 which has the required signals.
A. Trigger calibration fail signal for the design that fails calibration.
B. Trigger the status fail signal for the design that fail read/write test.
iv. Use the debug toolkit to check on the margin/window. Generate the debug report on debug toolkit.
v. List out any changes done to the default UniPHY constraints in the Service Request.
Check list for troubleshooting calibration failure.
|Does the design able to close timing in Quartus II with the DDR timing clean?
|The board layout is following the board layout guideline on the EMI handbook?
|The pin placement in the design is following the pin guidelines.?
|The device and interface can support the configuration as stated in spec estimator?
|The memory parameter in Quartus II accurately represents the operation configuration and condition?
|The OCT and ODT settings are correct?
|For single rank DDR3, set the GUI setting to "Dynamic ODT Off"?
|The correct memory timing parameter for the interface that you are using is input into Quartus II?
|Do you have the accurate board skews are input into the Quartus II MegaWizard?
|Does the problem exist in the previous version of Quartus II?
|Regenerate the IP when upgrading Quartus II version?
|Ensure all pin are connected properly on both FPGA and interface side.
|Did you try using RTL sequencer if Nios II sequencer failed for RLDRAM II or QDR II interface?
|Have you check the voltage supply to make sure all the voltage levels are correct? List of voltage are:
|Are the Addr/Cmd signal terminations done correctly?
|Are the Addr/Cmd signal center aligned to the memory clock on the memory side?
|Do you have a floating DM pins?
|Are the OCT pin connections and OCT rules are followed on your board?
|Are the Rup and Rdn or Rzq pin connected properly on both FPGA and interface side on your board?
|Did you modify any UniPHY default constraints?
|Does the problem exist on just this PCB or a number of PCBs?
|Does the design pass at different operating temperature?
|Are the skew between signals within each DQ group 50ps or less?
|Check on the warning message on the Quartus II report?
|Does the design pass when running at a lower operating frequency?
|Does the design pass while using memory with faster memory part?
|Run the standalone interface that has problem and power down all the other interfaces. Does it pass?
|Generate an example design with the same device and memory settings and apply the same pin assignment. Does it pass?
UniPHY, EMIF, Calibration, troubleshoot
Community support is provided during standard business hours (Monday to Friday 7AM - 5PM PST). Other contact methods are available here.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
For more complete information about compiler optimizations, see our Optimization Notice.