AnsweredAssumed Answered

Vybrid LPDDR2 Init

Question asked by Gordy Carlson Employee on Sep 15, 2015
Latest reply on Sep 16, 2015 by Gordy Carlson

Mark ( Mark Middleton,)

 

    Per request, this is a new thread that continues from a previous thread that was answered/closed.  For background...that previous thread is at...Vybrid LPDDR2 Configuration

 

 

 

New from customer ...   Eric Averill ....on Sept 11th...

Sorry it's been a while and I'm now trying to finally wrap this up. I believe I have all the registers except for CR105 and CR110. The fields you mentioned above in these registers are both set to 0x2020 which I believe comes from the tower configuration. Per the description in the datasheet however this would correspond to a delay of 64.25 clock cycles which does not seem correct. The datasheet does also not provide guidance for the setting of this register field. The register configuration spreadsheet I have indicates that a stress test should be used to find the correct value for this parameter however the DDRv tool only appears to be supported for 32-bit operating systems which we don't have available. Is there any guidance for setting this register value outside of the stress test program?

 

--------------------------------------------------------------------------------------------------------------

Mark Middleton response via email

 

For RDLVL_DL_0 and RDLVL_DL_1 (CR105[23:8], CR110[15:0]), a value of 0x2020 really does not make sense. The field for RDLVL is defined by the DFI standard (that governs the IP for all controllers and all PHYs) as 16 bits wide. How that equates to fractions of a clock cycle is all up to the PHY. Some PHYs may use fractions of 1/128, others 1/256, and others 1/512 (although I don’t have any examples of 1/512, probably overkill). My point, however, is that anything over a value of 0x003F is useless because you would never adjust for more than ½ a clock cycle. I don’t know whether the PHY actually tries to use the upper bits. The PHY certainly does not have 64 clocks worth of delay elements. But it could be that any full clock cycle less than 64 results in a maximum delay, and that at 64 full clocks, the PHY computation algorithm resets back to zero, allowing a value of 64.25 clock cycles to look exactly like 0.25 clock cycles.

 

The value of 0x2020 was originally chosen by the contract engineer employed by the Automotive division when they developed the Vybrid part. Once the i.MX team started digging into it, it became apparent that many of the settings, while they may work, are far from being optimized.

 

The actual default target setting should be 0.25 clock cycles. This parameter delays the Read DQS strobe by ¼ clock cycle into the middle of a valid data window that lasts approximately ½ clock cycle long.

 

By using Processor Expert, we have found that an even better value for this field is 0x0018 on the tower board, which is 3/16 of a clock cycle. In the absence of a calibration routine (which is probably not necessary at 400 MHz), any value between and including 0x0018 – 0x0020 should work just fine.

 

I think what really concerns me more is that, if you are still using a very old value for RDLVL (which is probably not the source of your problem), what other very old values are you using that could be the real source of your problem.

 

I am attaching a spreadsheet with the latest recommended settings for each register. By latest, I mean that I have updated a couple of fields after sending it out as Rev 0.3, but have not officially sent it out as Rev 0.4 yet.

 

I recommend that you double check all your DDR initialization registers against this spreadsheet, make the appropriate changes, and see if this improves DDR operations for you. If you have a specific question about a register, you can ask it in this thread. (Note: There is a new register field in the spread sheet not in the current revision of the Reference Manual. Extremely unlikely that it would apply to you. Also, the description fields are all old and need to be updated, so ignore them).

 

Hopefully I have answered your direct question.

 

Let me know if you have any more.

 

----------------------------------------------------------------------------------------------------------------------------------

From Eric Averill  Sept 14th...

 

This helps (it’s a newer version of a spreadsheet I already have) but not completely. This configuration has defaults for DDR3 at 400 MHz, we are implementing LPDDR2 at 306 MHz. I think I’ve worked out a lot of the timing registers for the clock rate difference, however, there are many differences in the configuration for DDR3 vs. LPDDR2. Some of these were issues we’ve brought up in the past where the setting (including settings in an older version of this spreadsheet) indicated it was for DDR3 only but the setting did in fact end up applying to LPDDR2.

 

What I’m really asking for is an example of a LPDDR2 configuration. We were sent one in the past but at this point I know it had errors (as that’s what are configuration was based off of) so I was wondering if there was an updated version.

 

A couple of notes/questions from my investigations today which I’ve been focused on the PHY registers:

 

  • In the PHY2 register the recommended setting for RD_DL_SET is 0x4. This does not seem to work with our configuration. 5, 6, or 7 do but not 4, is that telling us something?
  • We were using 0x00000013 for PHY0 and 0x00000017 for PHY1. I updated these to the recommended settings of 0x00002613 and 0x00002615. This didn’t seem to help but it didn’t seem to hurt either.
  • In the PHY2 register the recommended setting has bits 8:0 set to 0 and it states that these are for gate training only. In our configuration they are set to 0x43 and setting them to 0 doesn’t work. What exactly are these bits doing?
  • After configuration our PHY11 register is 0x00FF5201 and PHY12 register is 0x000F000E.
    • I notice that if I reread the PHY11 register occasionally we lose some of the lock bits (23:16). I can improve this via the settings in PHY3 (going from 0x0011012A to 0x0032012A helps). Is it normal to see the occasional lost lock bit or should this field always be 0xFF under normal conditions?
    • Bit 0 in PHY11 and PHY12 is suppose to indicate DLL locked, but it always seems to be 1 in PHY11 and 0 in PHY12, any idea what’s going on?
    • Per the reference manual bits 7:1 in PHY12 are read only and are suppose to return 0 but above bits 3:1 are 1, does this mean something?

Outcomes