A10 DDR4 fails calibration

Hi Sir,

You interface is 800MHz with one CS. By right, this speed do not need to turn on board deskew.

I am also curious about the debug results, which says that calibration failed on write deskew; does this mean that everything before write deskew (address/cmd leveling, address/cmd deskew, read deskew, etc.) passed?

Answer: Not necessary. Sometime, the previous calibration will create some flaw and cause current stage unable to calibration successful. And this time, I will suggest you to give this a try - https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/fb292783.html

Try turn on both of the option as below:

Skip address/command leveling calibration

Skip address/command deskew calibration

Thanks

Regards,

Aida

Hi Sir,

Welcome to Intel Community.

Please check, seem like the table in the attachment is broken. I don't see the value of the setting.

One thing to confirm is are you using the default skew parameter or you calculated it based on your board trace?

Thanks

Regards,

Aida

I have always had trouble attaching files with this interface, so corruption is no surprise.

I used skew and delay values calculated by the excel-based Board Skew Parameter Tool. But I am not confident that I got good numbers from that tool.

There are a several issues:

• there are two checkboxes concerning package deskew - one for the DQS groups and one for the address/command bus (corresponding checkboxes are found in the board tab of the Qsys configuration tool). When we originally configured the memory controller, the DQS group package deskew was selected, but the address/command package deskew was not selected. The result is that the CK package skew is not included in the pin file, and its value is apparently not accounted for, either in routing the design, or in the calculations done by the spreadsheet. Because of this, the calculated delay of CK at the first DRAM chip in the array is less than the calculated delay of the DQS pair (which includes the package skew) at the first chip. This is a violation of the timing requirements for CK and DQS routing (CK must be later than DQS at every DRAM chip to allow write leveling). Maybe having just one of those boxes chacked is a problem?
• The spreadsheet produces clearly incorrect results, such as a value of 0 for 'Maximum DQS delay to DIMM/device'; I am pretty sure infinite propagation delay has not been developed yet.
• There is a parameter for 'Maximum CK delay to DIMM/device', but the only CK delay entered in the spreadsheet is for DIMM/Device 0; how would the tool know the maximum CK delay?
• I am also puzzled by "Average delay difference between DQS and CK'; the description of the equation used for this is unclear, and again, since the only delay information for CK is for the delay to the first device in the array,, I don't see how the average difference can be calculated

I am also curious about the debug results, which says that calibration failed on write deskew; does this mean that everything before write deskew (address/cmd leveling, address/cmd deskew, read deskew, etc.) passed?

Thanks.