AM6412: LPDDR4 test failed with SR2.0 devices

Hi James,

Thanks for your feedback on the spreadsheet.
Could you also give me feedback to below two points?

#1: CKE behavior at the initialization.

JJD said:

I think the small pulse on CKE may be expected, i will have to ask the IP vendor.  

#2: Any parameters in sysconfig or dtsi file to modify read/write margin. 

Koichiro Tashiro said:

In this case, are there any parameters in sysconfig or *.dtsi file which can be modified to add read or write margin?
(ex. slightly add or reduce DQS falling/rising timing vs DQ )

Thanks and regards,
Koichiro Tashiro

Koichiro,

#1 i still need to get comments from the IP vendor.  At this point, i don't think it is an issue since we have seen this on our EVM and these have been proven to work

#2 as stated before, we should not go down the path of trying to manually change the training results.  There is nothing that can be done to "add" margin, this is taken care of by the training procedure.  If the design is marginal, there is nothing you can do in training or manually to "add" margin.  We need to try to understand why the design has these intermittent failures.  Ultimately, if the data eye opening is small, no amount of manual adjustments are going to add margin

Can you try the tests with the latest configurations i sent?  There were some adjustments that need to be made for the Nanya memory.  Do they see failures with the Micron memory on the boards built with PG2.0 AM64x?

Are you successful in connecting to JTAG on the HSFS device?

Regards,

James

Hi James,

JJD said:

Can you try the tests with the latest configurations i sent?  There were some adjustments that need to be made for the Nanya memory. 

The customer tried the latest configurations you provided, but the issue is still there.

JJD said:

Do they see failures with the Micron memory on the boards built with PG2.0 AM64x?

Do you mean the Micron memory and the Nanya memory is Pin-to-pin compatible? The customer only uses the Nanya memory on their boards. 

JJD said:

Are you successful in connecting to JTAG on the HSFS device?

Not yet. I will check it tomorrow as I am visiting customers today.

Thanks and regards,
Koichiro Tashiro

Hi Koichiro

Koichiro Tashiro said:

Do you mean the Micron memory and the Nanya memory is Pin-to-pin compatible? The customer only uses the Nanya memory on their boards. 

Yes, the memories should be pin to pin compatible.  Would be a good test to see if these boards work with Micron memory.  

Regards,

James

Hi James,

I will aske them to try the Micron memory, but most probably they do not have them.
Do we have a few Micron memory available to ship the customer?

BTW, the customer reported below statements were wrong. They did further tests and found 1066MTs configurations are still failing.
>The customer tried some modification in sysconfig parameters and found two working configuration with 1066MTs.
So please ignore it. Sorry for confusion.

Do you get any feedback from IP vender? If not, please push them to reply back asap.

Thanks and regards,
Koichiro Tashiro

Hi Koichiro, still trying to get feedback.  Let's keep trying to debug, i don't think it is affecting the errors.  

Regards,

James

Hi James,

JJD said:

still trying to get feedback.  Let's keep trying to debug, i don't think it is affecting the errors. 

I understood it, but the customer wants to make sure the reset behavior is not real root cause. So confirmation from the IP vender is important for them.

Thanks and regards,
Koichiro Tashiro 

Koichiro, i got confirmation that the CKE behavior is normal.  CKE will go low for command bus training and will be high for training at operating frequencies.  So CKE goes high initially for boot frequency training, low for CBT, and high again to complete the training at operating frequency.

Regards,

James

Hi James,

I think the CBT is below circle, correct?

Description is below:

And Section 4.28 says:

Does it means the LPDDR4 switch to FSP0(50MHz) to FSP1(800MHz) here?

Thanks and regards,
Koichiro Tashiro 

Yes, FSP-OP0 will start off by default in an unterminated state which is suitable for the boot frequency of 50MHz.  It will then use FSP-OP1 as the high speed operating state and performing training in that FSP.  Once establishing a known good state for FSP-OP1, it can reuse FSP-OP0 as a secondary operating frequency and train that at, for example, a lower operating frequency for lower power operation

Regards,

James

Hi James,

Thanks for clarification.

The customer has some questions to your previous comments to sysconfig settings.

>tFAW(tCK): this can stay at 0.  There is no tFAW definition in clock cycles, so the tool only uses the ns definition

Do you mean there is no tFAW(tCK) definition for LPDDR4? If so, why we have such parameter in sysconfig.
This is confusing...

>tRASmin(ns): derating will automatically be added if the temp setting is above 85C.  So this setting should remain at 42ns

>tRAMmax(ns): this should be set to 9*tREFI=35100 if operating below 85C

It needs to be clarified in sysconfig that these values do not include derating and applicable below 85C.

Thanks and regards,
Koichiro Tashiro

Koichiro, i agree tFAW(tCK) is confusing.  i will remove it in the next revision.  I will also consider your other comments in the next revision. 

Thanks for your inputs, please don't hesitate to offer more improvements for the tool.

Regards,

James

Hi James,

As I informed offline, changing DQ/DM pull-down value to 34.3 Ohm solved all memtester issues.
Thanks so much for your persistent supports on this issue!

BTW, the customer reported another boot issue discussed below E2E.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1263955/am6412-boot-stops-at-u-boot/4786493#4786493
It does not seem to related to DDR, but just in case, if LPDDR4 training failed at boot, what happens?
Does u-boot come up?

Thanks and regards,
Koichiro Tashiro