TMS320C6670: DDR3 Leveling Issues on migration from Micron MT41K256M16HA-125 to MT41K256M16TW-107

Kedric,

You have reviewed several posts.  You should have seen multiple that clearly recommend use of Partial Automatic Leveling.  This is because that is the simplest, it is the leveling method implemented in all sample code and GEL files and it has been successfully used by many, many customers.  Also in your research you will find many threads where customers encounter difficulty with Full Automatic Leveling.  I know that there are customers successfully using it but some had significant issues getting it robust.

Based on your questions, there is a lack of understanding about DDR3 leveling and the related errata.  The C6670 (all C667x) PHY supports three leveling steps.  These are write leveling, read 'eye' leveling and read 'gate' training.  The PHY implementation that has 2 parts to each: start-up leveling and incremental leveling.  Advisory 30 discusses a flaw in the read eye leveling portion of the start-up leveling.  The workaround recommended is implemented as Partial Automatic Leveling.  Advisory 31 discusses an implementation issue with the write leveling portion of the incremental leveling process.  The read eye and read gate portions of incremental leveling are unaffected.

The KeyStone I DDR3 Initialization Application Report (SPRABL2E) discusses the leveling process in significant detail and provides the proper command order and timing to enable the supported leveling modes.  It also links to two spreadsheet tools that must be completed to properly commission the DDR3 interface.  This wiki page also provides an overview of the commissioning steps:  http://processors.wiki.ti.com/index.php/KeyStone_I_DDR3_Interface_Bring-up

Your original issue was related to problems seen testing with a newer SDRAM that you assumed would be a drop-in replacement.  The newer device is assumed to meet the required timing since all of the timing parameters are same or shorter than the original part.  However, faster parts have faster slew rates.  This may cause an increase in overshoots and undershoots and may also cause additional timing jitter due to crosstalk.

I recommend that you revert to Partial Automatic Leveling to see if you get improvement.  You will also need to re-trace the commissioning steps listed in the wiki link.  Please post the files as you create/update them for review.

Tom

Tom,

Thanks for the response. My group is not new to the commissioning steps required for correct DDR3 operation and controller operation in TMS320C66xx parts. Over the years you and Bill Taboada have provided the most info on the subject of leveling in this family of DSPs and you also have provided responses our team members on legacy products targeting the slower Micron MT41K256M16HA-125 XIT DDR3 [see Bill’s May 2014 post on  DDR3 Initialization Process with Incremental Leveling in C6670].

We did try partial automatic leveling as you suggested. This works with no issues just as well as auto-leveling-followed-by-permanently-enabled-incremental-leveling approach that we originally tried.  The bootloader would load from FLASH, the DSPs would boot/load running out of DDR3, and then run Built-In Tests for memory for several thousands of cycles over temperature with no failures.

There were a couple of things I did notice after reviewing and redoing the spreadsheet calculations for our board:

1. Even though the Micron datasheets described the chips as backward compatible, timing parameters turned out to be slightly different for the -107 device. First, I matched timing as reported in the new chip’s datasheet.

2. The newer v11.0 of PHY Calc spreadsheet produced slightly different numbers for WRLVL_INIT_RATIOS and GTLVL_INIT_RATIOs. I don’t know if this was a difference in the underlying formulas but the decimal values changed (by up to 3 units) in the _INIT_RATIO registers.

I’m still curious as to the behavior difference of the permanently-enabled-incremental-leveling approach vs. disabling-incremental-leveling-after-completion approach.

--

Kedric