DDR on custom PCB (i.MX 8M Plus)

[melon87]

Custom PCB with DDR Tool reporting "Dbyte 0 couldn't find the rising edge of DQS during RxEn Training".

I have followed the advice on other forum posts:

- Account for DQ swaps

- Use spreadsheet to calculate correct parameters

- Following debugging advice in the manual. We werent entirely show how to tune the design...

Please what can we do next?

[JorgeCas]

Hello, I hope you are doing well.

According to internal team, when this issue is presented on DDR Tool, is recommended to check the conditions for DQS0 signals or maybe a DDR configuration that is not supported on the device (usually is the first).

Best regards.

[melon87]

@JorgeCas  thank you - I am well. You too I trust. Check the condition i.e. measure it on hardware?

[JorgeCas]

Yes, measure it on hardware.

Best regards. 

[melon87]

@JorgeCas it does look bad. Has a poor slew rate. What can we change on the NXP device?

@JorgeCas For DDR4 is CK_t_A the right thing to use or should it be CK_t_B?

Thank you

[JorgeCas]

Hello,

Could you please share me your DDR schematic? If there is no hardware issue you could try to fine tune.

ATxImpedance/ODTImpedance/TxImpedance parameters to find a reasonable window.

Please refer to RPA tool for the details and available options of the above parameters.

Best regards.

[melon87]

@JorgeCas  Sorry I can not share those. We have made some progress - there was a power supply issue with the PCB. So we now have RPA tool reporting a read skew error - are there parameters we can tune to resolve this? Thank you

[JorgeCas]

Got it, thank you for the feedback.

Which error are you getting?

Best regards.

[melon87]

@JorgeCas  error dbyte 0 lane 0 failed read deskew

[JorgeCas]

Thank you.

Essentially, the error message is saying that byte lane 0 bit-0 cannot pass fine turn adjust when running the training period for Read DQS. The trace itself is either too long or too short, and there are not enough calibration adjustments that can be made to bring it back in line, or there could be skew problem or noise.

Also, there is a possibility that the initialization file could has errors. I suggest you take a look on your RPA parameters or use config tools for i.MX with the parameters according for your DDR configuration.

Best regards.

[melon87]

@JorgeCas we managed to get u-boot working at DDR-1066 using the eval kit image for DDR4 default. Fails are higher speeds.

The MSCALE tool doesn't seem to work at speeds lower than 1200MHz - it just hangs on the first command. Is that a known issue or a sign that we have the wrong parameters? 

[JorgeCas]

Hello,

That behavior makes me think on signal integrity issues, as you mentioned before on your measures.

Since it is a custom board design and manufacturing technology are different from NXP reference board, and board related parameters may differ from initial DDR script, so please try tunning:

ODTImpedance

Desired ODT impedance in Ohm. Valid values for DDR4=240,120,80,60,40. Valid values for DDR3L=high-impedance,120,60,40. Valid values for LPDDR4=240,120,80,60,40

TxImpedance

Write Driver Impedance for DQ/DQS in ohm (Valid values for all DDR type= 240, 120, 80, 60, 48, 40, 34)

ATxImpedance

Write Driver Impedance for Address/Command (AC) bus in ohm (Valid values for all DDR type = 120, 60, 40, 30, 24, 20)

Did you check signal integrity with a lower clock speed?

Best regards.

[melon87]

@JorgeCas we have uboot running robustly at 533MHz clock (DDR-1066). It is a shame we cant get MSCALE to work at 533 so we can calibrate. Do we have any other options to generate the calibration data?

[JorgeCas]

Hello,

Available options to generate it are:

- MSCALE DDR Tool.

- Config Tools for i.MX.

Best regards.

[melon87]

@JorgeCas  Config Tools for i.MX seems a positive step forward. However, we find u-boot crashes when we add these training files. Is there a specific version of u-boot that is supported? We have taken the evaluation kit image - perhaps a mismatch?