Vybrid LPDDR2 Init

[GordyCarlson]

Mark ( TheAdmiral,)

    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 ...   ericaverill​ ....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?

[TheAdmiral]

Hi Gordy,

I know we will talk tomorrow, but I am going to provide some quick answers to this thread:

RD_DL_SET in the PHY registers (PHY02, PHY18) is used to allow the FIFO coming directly from the PADS, clocked to the READ DQS time domain, to clock data into the SDCLK domain FIFOs. While the clocks are running at the same fequency, they are asynchronous (ie, at a different phase). So it looks like the customer design may have more of a phase delay between the Read clock and the SDCLK, so a larger time delay in this register may be required for the. Previously, I thought this was a loopback timing issue only, but it does look like to comes into play in real designs.

In PHY0 and PHY16 for DQ pads, and PHY1 and PHY17 for DQS pads, TSEL_START and TSEL_END are the fine tune adjusts for the termination resistance applied to the processor pads for the respective byte lanes. If you are really unsure what to use, you could try a value of 0x06 [15:8] which would have not delay in turning on the termination, but delay the turn off time by one and one-half clock cycles past the end of the calculated read burst, giving this amount of time as a fudge factor for the fact that you really don't know how long the round trip time delay is going to be. Anything less than two full cycles will not be a problem, since you designate in another register a minimum time between a Read and a Write command.

For PHY2[2:0], these bits are for a gross gate delay enable adjustment. Setting it to 3, and having it work, vs setting it to 0 and not having it work means that you probably do not have RDLAT_ADJ set correctly in register CR132. This setting controls the gate timing for the incomring read burst. What we are finding is that RDLAT_ADJ should probably be set to the CAS Latency value minus one clock cycle, because CAS Latency is the time delay until the first rising edge of the read strobe is issued, and you want to ungate before that time. So you set RDLAT_ADJ to one clock cycle less, then adjsut the RDLVL_GTDL_0/1 to adjust the delay by an added one-half clock cycle (more of less). Shouldn't be relying on the Gross Gate adjust setting.

For PHY2[4:3], these bits are for a gross delay in the gate signal end window. Pretty much same logic as above. The actual window is determined from the ungate point, waiting for the number of clock cycles to complete a full burst, plus any adjustments made to OE_START and OE_END for the DQS strobe only. Also, no real need to relay on this field. Other thing can be adjusted.

For PHY2[7:5], yes this is only for gate training. I causes an error flag to be sent if gate training did not detect the full number of strobe edges within the required time.

PHY11 and PHY12 are read only. But it sounds like the customer's really problem is that the DLL is not locking or is losing lock. We have other customers with the same issue. I think there is a little more clock jitter in some designs than other designs. This can be fixed with the following register adjustments:

PHY02[18:16], PHY18[18:16]  DLL_PHASE_DET (Only recently added to the latest revision RM Draft) This if for GATE signals.

Originally we thought 0x0 was the correct setting. We are going to change that to 0x2 based on the number of customers with issues. Jitter rejection by the DLL will be reduced a little, but at least the DLL will lock

PHY03[22:20], PHY19[22:20] DLL_PHASE_DET Same as above except for DQS OE.

Customers are okay with this at 0x0, but same sort of principle applies. Try adjusting up one or two if necessary for stable lock.

Cheers,

Mark

[GordyCarlson]

Thank You!

-G