Questions on i.MX6 DDR3 calibration (fly-by topology design)

[HectorPalacios]

Hello,

We have a design with i.MX6Q and 1GB DDR3. We use the same four Micron DDR3 chips than the SabreSD reference board, but we are not using the T topology. We are using 'fly-by' topology.

We have run the calibration utility using the SabreSD init script given with it (MX6Q_SabreSD_DDR3_register_programming_aid_v1.5.inc) and got different results on two identical boards (same layout).

I have some questions regarding the calibration process:

1) *Write leveling*

The calibration script says:

// write leveling, based on Freescale board layout and T topology

// For target board, may need to run write leveling calibration

// to fine tune these settings

// If target board does not use T topology, then these registers

// should either be cleared or write leveling calibration can be run

setmem /32 0x021b080c = 0x001F001F

setmem /32 0x021b0810 = 0x001F001F

setmem /32 0x021b480c = 0x001F001F

setmem /32 0x021b4810 = 0x001F001F

Considering our board's 'fly-by' topology, should we set these to 0x00000000 and then rerun the calibration?

Or should we use the values calculated in the first calibration (which ran with default value 0x001F001F) and then rerun the calibration?

The manual also states: "If write-leveling delay is larger than 0x2f, it is suggested to set the WALAT value on MMDCx_MDMISC register to 1 in the initialization script and re-run the DDR_Stress_Tester."

To begin with, I don't understand this note. 0x2f is around 1/5 of a cycle. If this register is capable of producing up to half a cycle skew, why does the calibration manual recommended to set WALAT to 1? The datasheet recommends to set WALAT if the delay is around half a

cycle, not around 1/5.

In the results from my first calibration, three bytes are slightly over this 0x2f value.

2) *MMDC Duty cycle fine tuning*

The SabreSD calibration script states:

//For i.mx6qd parts of versions A & B (v1.0, v1.1), uncomment the following lines. For version C (v1.2), keep commented

//setmem /32 0x021b08c0 = 0x24911492 // fine tune SDCLK duty cyc to low - seen to improve measured duty cycle of i.mx6

//setmem /32 0x021b48c0 = 0x24911492

How can I determine if my board needs such a fine tuning?

What can I expect to improve/worsen when playing with these settings?

3) *RALAT*

The SabreSD calibration script states:

//NOTE about MDMISC RALAT:

//MDMISC: RALAT kept to the high level of 5 to ensure stable operation at 528MHz.

//MDMISC: consider reducing RALAT if your 528MHz board design allow that. Lower RALAT benefits:

//a. better operation at low frequency

//b. Small performence improvment

How do I determine if a certain RALAT value improves or worsens the DDR3 behavior?

4) *Calibration*

After a first calibration, I must take the results, write them to the calibration script and rerun the calibration, right?

After the second calibration, should I do the same one more time? Twice more, three times? How do I know when to stop?

What if I see different values on different identical boards? How much difference in the calculated values is reasonable?

Should I always use the most conservative values (longest delays) among all the boards I calibrate? Or the average value?

Thank you for your help.

Kind regards,

--
Héctor Palacios

[HectorPalacios]

Hello,

I ran the calibration using the default SabreSD configuration file. Then I took the results and overwrote the configuration file with them.

I reran the calibration a second time and got new results.

After five iterations results converge.

Using these final calibration values I run the DDR3 stress test and I get failures.

Once I got one bit error:

Address of bank3 failure: 0x380599c0

Data was:                 0xAAAAAAABAAAAAAAA

But pattern was:          0xAAAAAAAAAAAAAAAA

But other times I got a failure although the patterns match:

Address of bank3 failure: 0x3802c7c0

Data was:                 0xAAAAAAAAAAAAAAAA

But pattern was:          0xAAAAAAAAAAAAAAAA

The stress test passed ok with default SabreSD values, but not with the values result of the calibration.

So how should I interpret this? Can't I trust the calibration results?

--

Hector Palacios

[jamesbone]

What version of the DDR Stress Tool are you using?  The latest one has some patch. that fixes this issue.

I do not want to say yet that it is a bug in the tool if I am not sure the version that you are using but seems that you can interpret that you do not having a failure.

[HectorPalacios]

I’m using V1.0.2. What is the latest version and where can I get it?

[YixingKong]

Hector

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

[HectorPalacios]

Yes, thank you. I think I have enough information now.

[peter_pinewski · Accepted solution]

Hi Hector,

The latest stress tool is v1.0.2

https://community.freescale.com/docs/DOC-96412

Also, from the design team, recommendations of using the stress tool and calibration is below.

1. FSL Design rules must be followed.
2. Please make sure DDR script are configured properly.(i.Mx6DQSDL DDR3 Script Aid can be as a reference)
3. Please use latest stress test tool version through below link.
4. Suggest sampling 5-10 boards and get calibration results(write leveling,DQS gating, read/write delay line) under corner temprature-high,low, room.
5. Balance all calibration result(normally average them) and write them into script.
6. Using above DDR configuration to do customer QA test-real OS on not less than 10 boards. (temprature press test, high loading etc.)
7. make sure i.Mx chip and DDR chip should be same batch. (new batch need redo above process.)
8. if any one step meet issue, need debug case by case.
9. i.Mx6DQSDL DDR3 Script Aid

https://community.freescale.com/docs/DOC-94917

1. i.MX6 DDR Stress Test Tool

https://community.freescale.com/docs/DOC-96412

One more comment I found:

WALAT should be 1 for any WL value > 0x2f. The reason is because the Write Postamble (Period of time that DQS strobe remains low before going to idle) must be greater than 0.4x the clock period (JEDEC Standard). Once the write burst begins, the DDR PHY does not keep track of how long the DQS strobes need to complete the write burst. The DDR PHY only counts whole cycles, and then takes back control of the DQS strobe lines (force to idle) when it thinks the burst is done. If WL = 0x00, this will be one-half clock period after the last falling edge of the DQS strobe. But for larger values of WL, the DDR PHY will place the strobe traces in idle closer and closer the last falling edge (making Postamble shorter and shorter). If WL =0x100 (one-half cycle), then the DDR PHY will return the DQS strobe to idle just as it is trying to complete the last falling edge. It is not that we are just meeting the JEDEC standard, but there does need to be a large enough time after the last falling edge so that the edge is clean and read correctly by the DDR device.

For MMD Cduty cycle fine tuning, you should run a scope on the SDCLK signals. 

Let me know if this helps.

Regards,

Peter

[Yuri]

In the mentioned AN4467, please use sections 11.2 (Hardware Write Leveling Calibration Sequence) and
19.1 (DDR3 Write Leveling Code Example)

[jamesbone]

You can take a look to the this Application Note

http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf

saludos