EMIF Calibration FAQs, Known Issues and Checklist

Yes. Calibration is board specific and will need the board setting to be entered correctly. Run board trace simulation to determine the board traces delays and enter it correctly.

Choose the Setup and Hold Derating factor as what is specified on the memory vendor datasheet.

Yes. Calibration will fail if you have the incorrect addr/cmd skew. Calibration will fail at the first read stage.

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 specific operating speed of the design, not following the memory speed.

Yes, you should always regenerate the IP when moving from one version of Quartus Prime or Quartus II software 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.

No. But you can change the phase setting on the GUI to make the clock skew more balanced.

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.

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.
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” Both the setting and default value should be ‘off’.

Yes. Port definition and assignment are important in VHDL as wrong definition will cause the Quartus Prime or Quartus II software to be unable to connect the ports properly. And this might cause the design to be unable to come out of calibration.

Yes. Board layout which has been design badly will cause calibration failure. Follow the board layout guideline when designing the board.

Noise or jitter from other interface or operation can corrupt the interface signal. Always debug in quiet condition or switch off all the other operation on the board and run the standalone design which has the problem.

The CK needs to be longer than DQS because only the DQS signals can be adjusted (delayed) during calibration.

No. FPGA 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 aligned with JEDEC specifications.

If you are using 2 different memory devices (interchangeably) in the same board, use worst case value from both of the memory interfaces in the GUI parameters for memory device and PCB environment.

No. Please make sure the Vtt is terminated and de-coupled properly.

It might be. Please ensure that you have the latest silicon version which has the fPLL fix. Else, please check the PLL phasdone and lock signal. If that is stuck low, it is related to the PLL global issue.

It might be. This issue can cause failure in any stage of calibration process. This issue has been fixed in Quartus II version 13.1 and 14.0 via patches.

This issue has not caused any calibration failure before. To confirm, you have to route out the dll_delayctrlout 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 13.0SP1 DP5.

The HMC-IOREG read failure issue does not cause calibration failure. This issue has been fixed in the Quartus® II version 13.0SP1 DP5 (Arria® V and Cyclone® FPGA) and 13.1 ( Arria V SoC and Cyclone® V SoC) and onwards.

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 the Quartus Prime or Quartus II software v13.0 or higher to fix this issue.

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 fixed in Quartus II version 13.1.3.

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 the Quartus Prime or Quartus II software version 13.1 and higher.