topic Re: i.MX53 - LPDDR2 DDR Stress Test in i.MX Processors

i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Mon, 22 Apr 2013 06:10:59 GMT

We have our custom design based on i.MX535 with Elpida EDB4032B2PB (512MB LPDDR2-S4) & Samsung KLM4G1FE3B-B001 (4GB eMMC Flash). The product is in the hardware bringup phase. To check the processor memory interface, the DDR Stress Test was performed and the result of the same is herewith attached.

1. Since there is no detailed user manual or guide for this stress test regarding the observation or results, Pls advice what does this result as per the attachment signify? Is there any way to identify where the problem exists?

2. Does DDR Stress Test carry out rigorous testcases with varying test patterns to validate the interface? Is there any document to understand or infer from the results? What is the procedure being adopted during the test?

3. Do we have any bare metal tests for i.MX535 Sabre/QSB interfaces to test via the JTAG Emulator?

Pls advice.

Re: i.MX53 - LPDDR2 DDR Stress Test

Yuri — Mon, 22 Apr 2013 07:46:10 GMT

Looks like memory is not good (write 0xFFFFFFFF, read 0x1). Is Your init script (init3.inc) correct for LPDDR2 ?

Re: i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Mon, 22 Apr 2013 08:18:12 GMT

It was editted as per datasheet. But may be something is wrong. Can you share a validated init script for i.MX535-LPDDR2?

Thanks.

Re: i.MX53 - LPDDR2 DDR Stress Test

Yuri — Mon, 22 Apr 2013 08:28:40 GMT

Please use the enclosed.

Re: i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Mon, 22 Apr 2013 11:14:28 GMT

Thanks Yuri. Electrical specifications are the same between the part that we have used & the one adviced in the init file.

1. Tried the test with this init file. Pls find the screenshot. Any feedback on this? Is it that the data written is 0xffedffff, but the read value is 0xffffffff?

2. Is it that the first address being written itself is 0x70800000?

3. Is there any way to change the test pattern to diagnose the problem?

4. Also would like to know the way the stress test is performed in terms of the patterns, sequence of test patterns used & the result that is expected, etc. In case of failure how to infer the result data? Do we have any document which can specify the same?

Re: i.MX53 - LPDDR2 DDR Stress Test

Yuri — Fri, 24 May 2013 05:39:54 GMT

Sorry for delay.

Looks like the memory is not working correctly.

As for the stress tests - usually sources are not provided (because of some internal reasons).
Nevertheless, hope the following may be helpful.

Below is a list of each sub test along with their respective definitions. Note the acronym

SSN stands for simultaneous switching noise.

t0: memcpy11 SSN test (DDRtest_memcpy11_SSN.c )

This test is similar to the memcpy11 random pattern test (described below) which

makes use of the custom written memcpy11 function. However, this test uses data

patterns to help root out SSN and does not increment the starting address. This test

also breaks up the total DDR density into four “banks”, where each bank contains a

different SSN data pattern.

t1: memcpy8 SSN test (DDRtest_SSN_memcpy_test.c)

This test performs “memcpy” bursts of various stress patterns (walking ones and

walking zeros, A’s followed by 5’s, etc) using copy_words_using_eight_registers to

help determine or weed out simultaneous switching signal noise.

t2: memcpy11 random pattern test (DDRtest_memcpy11_pseudo_random_with_offset.c)

This test utilizes a custom written memory copy function that issues 11-word load

and store multiple instructions, to test the bursting behavior of the DDR

interface. Each time through the memcpy11 test, the start address is incremented in

steps of four bytes to test different burst access types, especially important when

caches are enabled to initiate burst wraps for cache line fills. The data pattern used is

pseudo-random. This test also breaks up the total DDR density into four “banks”,

where each bank contains a different “seed” for each pseudo-random data

pattern.

t3: byte-wise SSN test (DDRtest_byte_SSN_test.c)

The purpose of this test is to root out any SSN within byte lanes. It accomplishes this

by writing byte-wise patterns to one location and the inverse of each byte to the

subsequent location. Each of the four bytes values are equal to one another and the

test increments the byte pattern as follows (with the inverse value in brackets:

0x00000000 [0xFFFFFFFF]; 0x01010101 [0xFEFEFEFE]; 0x02020202

[0xFDFDFDFD]; … 0xFFFFFFFF [0x00000000].

t4: IRAM_to_DDRv2 test (DDRtest_IRAM_to_DDRv2.c)

This test is similar to the IRAM_to_DDRv1 test, but instead transfers the data 1000

times per test to ensure that the data never changes to root out random glitches. Also,

the test uses different data patterns than the IRAM_to_DDRv1 test to further root out

SSN.

t5: IRAM_to_DDRv1 test (DDRtest_IRAM_to_DDR.c)

The purpose of this test is to root out any SSN and isolates the DDR read and write

accesses by using the IRAM as an intermediate data storage location. This test

moves a user defined length of data using the copy_words_using_eight_registers

function from DDR to IRAM and then from IRAM to a different DDR location, then

compares DDR location 1 and location 2. The data pattern used is pseudo-random.

t6: read noise walking ones and zeros test (DDRtest_read_noise_walking_test.c)

This test helps to identify if there any signal integrity issues or cross talk between

data lines or other control signals by doing four sets of test on both CSD0 and CSD1

(if CSD1 is populated).

Read from DDR walking ones – this test writes a set of 0xFFFFFFFF

followed by a walking ones pattern to memory and then reads it back in a

two word burst (if there are issues, the read will not return a one)

Read from DDR walking zeros test – this test writes a set of 0x00000000

followed by a walking zeros pattern to memory and then reads it back in

a two word burst (if there are issues, the read will not return zero)

Write to DDR walking ones test – this test will use an STM to write a two

word burst to memory a set of 0xFFFFFFFF followed by a walking ones

pattern and then reads it back non-burst (if there are issues, the read will

not return a one)

Write to DDR walking zeros test – this test will use an STM to write a

two word burst to memory a set of 0x00000000 followed by a walking

zeros pattern to memory and then reads it back non-burst (if there are

issues, the read will not return zero)

Re: i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Sat, 25 May 2013 07:08:56 GMT

Thanks Yuri for the clarification.

Sorry for not updating my results.

Well meanwhile tried bringing up another hardware. As per advice DDR stress test passes till 350MHz in this hardware. So DDR till 700MHz is fine. Happy that the basic hardware is fine & we have got the right configuration details as well. Thanks for the support.

But after 350MHz getting errors. Need to analyse this for better performance.

Thanks Yuri.

Re: i.MX53 - LPDDR2 DDR Stress Test

Yuri — Mon, 27 May 2013 05:23:19 GMT

Please verify if the PCB design meets design checklist recommendations.

Also, DDR calibration may be performed.

Re: i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Thu, 30 May 2013 05:42:34 GMT

Yes will do the same.

Do we have any references for LPDDR2 relevant pcb design checklist & for DDR calibration?

Re: i.MX53 - LPDDR2 DDR Stress Test

SrideviK — Sat, 13 Jul 2013 09:06:33 GMT

Thanks Yuri for the support.

The DDR relevant read & write delay lines were tuned to get the stress test working till 400MHz in our hardware platform.

Thanks.