This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: DDR Subsystem Register Configuration updates/changes/versioning

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Dear TI team,

we've been working on the AM64x for quite some time now, and in the process have seen the DDR config tools versions 0.03.00, 0.08.00 and 0.08.10 so far.

With every new tool version, the generated output is slightly different. Combined with the lack of proper documentation for the AM64x DDR controller registers (they're missing from the AM64x TRM, but something similar is documented in the J7200 TRM) it is a very tedious task figuring out what changes, and if these changes are desirable.

Would it be possible to document changes between DDR config tool versions, so that we know whether there's anything useful changed for us?

One issue seems to be that the tool only stores settings that differ from the "default", but these defaults appear to have changed between versions, e.g. for our LPDDR4 ODT_ca used to be RZQ/6. That was the default for version 0.03.00, but since 0.08.10 the default is RZQ/4. If I open our old .syscfg with the newer version, the new default is used, because the value isn't stored in the .syscfg file.

What are TI's recommendations for handling DDR config tool version updates?

I've downloaded all versions of the tool via dev.ti.com/tirex for offline use, because in my opinion relying on a cloud-based tool for product development is just asking for problems a few years down the road. I'm pretty sure that in the past I've been able to select older versions of the DDR config tool, but now there's only 0.08.10 available.

Is there an archive of previous DDR config tool versions available somewhere?

I'm able to open my older .syscfg file with the current version, but there seems to be an issue with the downloaded versions. It shows me all my settings, but the new "DBI" configuration option is missing, and the "Generated Files" section only lists the .syscfg file. After opening the .syscfg file via the cloud based version and exporting it from there I'm able to fully use it in the downloaded version, too.

Are there any known limitations when using downloaded versions of the DDR config tool?

The reason why I'm looking into this at all is an issue that we're seeing with U-Boot and our custom board (I'll create a different thread for this).

I'm basically wondering why U-Boot works at all for the SK-AM64 (which has LPDDR4, like our custom board) and wanted to see if maybe there have been any changes in the DDR config tool that could explain why my configuration (based on an older version) has problems.

After managing to open our existing config and exporting the .dtsi file I found 13 changed registers when diffing our old .dtsi with the newly generated.

I managed to look up the affected registers in the header files in the source code (the old PDK had a DDR4 driver that we based our MCU+ SDK LPDDR4 driver on), and with the J7200 TRM that uses a similar DDR controller (but different register numbers) I was able to understand most of the changes, but that's a huge amount of manual work.

The changes that I can't make any sense of are these:

#define DDRSS_PHY_91_DATA 0x0100C0C0 -> 0x0000C0C0
#define DDRSS_PHY_347_DATA 0x0100C0C0 -> 0x0000C0C0

#define DDRSS_PHY_1375_DATA 0x030207AA -> 0x03020000

The first two appear to be internal to the DDR4 controller and phy connection.

The last change appears to be related to some Vref pad settings, but even the J7200 manual only says "Pad VREF control settings for the address/control".

It's worrying me if some settings change that we've been using for 6+ months. There could be good reasons for these changes, maybe explaining some odd behavior that we haven't been able to pinpoint yet, but then I believe it's equally likely that changes like these introduce new problems that we haven't seen before.

What effect should these changes have? In which case are they necessary?

Best Regards,

Dominic

  • Dominic, thanks for the inputs. 

    Would it be possible to document changes between DDR config tool versions, so that we know whether there's anything useful changed for us?

    The changes we have made to the sysconfig tool to this point have been to optimize the configuration for our EVMs or add new configurable features.  The intention is for customers to use the latest version, as that will have the latest updates and most optimal settings.  I will try to put together a short description of the changes in the versions you mention, and have that kind of revision history in future versions in the sysconfig readme. 

    What are TI's recommendations for handling DDR config tool version updates?

    At this point, the strategy has been to just expose the latest version of the tool on sysconfig, and deprecate previous versions, so as to not confuse customers with multiple versions.  If documenting the changes as mentioned above would be satisfactory 

    Is there an archive of previous DDR config tool versions available somewhere?

    Not for public consumption, as we were not planning to support multiple versions.  The intention was to be able to open up a .syscfg file in the new version to "pull in" the customer configuration.  If this isn't working correctly (cloud based), let me know.  

    Are there any known limitations when using downloaded versions of the DDR config tool?

    We weren't expecting customers to download each version, so i can't speak to the compatibility across versions that were downloaded, or the limitations

    Can you post the different output files that you are comparing across tool versions?  That way i can do a diff and try to explain the specific differences you are seeing.  Note that some differences may be board related and not applicable for your design (eg, we increased the ODT_ca impedance after fine tuning our SI simulations for the SK EVM)

    Regards,

    James 

  • Hello James,

    thanks for your reply. Documenting the changes would be great.

    What I fear most is having to make a minor change at some point in the future, e.g. due to obsolete parts or because of a need to tweak some detail. For example in the past we had a project where we reduced the self-refresh period to accomodate for higher temperatures, years after the initial development. Being able to reproduce previous DDR configurations would be essential in this case, and using a downloaded version is the only way to have reproducible results. Maybe you could give some more thought to that use case.

    It would be great if you could comment on how the tool doesn't write "default" settings to the .syscfg file. For example you wrote that ODT_ca impedance was only changed to accomodate simulation results for your SK EVM, yet the new setting of RZQ/4 is also applied to our custom board, that we used to run with RZQ/6. In my opinion this is unncessarily error prone, and from what I can tell this is only due to how the tool handles defaults. The current situation somewhat defeats the "import into latest version" approach.

    I've spent some more time looking into the issue with offline versions, and noticed that this is actually not a problem with the DDR config tool but with the TI System Config tool version used. The attached custom_lpddr4_0_03.syscfg can be opened in an offline sysconfig version 1.8.0/1.8.1 and the DDR config tool 00.03.0 and 0.08.0 and I'm able to export the .dtsi file. If I open the same file with sysconfig version 1.9.0 and DDR config tool 00.03.0 or 0.08.0 I'm unable to export the .dtsi file. DDR config tool 0.08.10 is incompatible with sysconfig < 1.9.0, so I can't test that.

    The cloud version is able to open the same file AND export the .dtsi file (as well as a .syscfg file that I can then re-open in the offline sysconfig 1.10 w/ DDR tool 0.08.10). The .syscfg files are exactly the same, yet the .dtsi files contain a number of changes. I believe these are mostly due to changed defaults for DBI, ODT_ca and runtime write DQ leveling, but I can't make sense of the changed PHY registers. It would be great if you could comment on those.

    custom_lpddr4_0_03_vs_0_08_10.zip

    Best Regards,

    Dominic

  • Hi Dominic, i have attached a diff report with comments to describe each change  I will eventually get version of this in the tool as a revision history

    Unfortunately, i can't speak to the compatibility of the sysconfig versions.  That's an under the hood thing which i don't have much control over.  I will take your point about being able to access older versions, and about the "default" settings consistency across versions.  Admittedly, these are some growing pains with this new tool, as we are trying to get away from maintaining a cumbersome xls spreadsheet.

    ./cfs-file/__key/communityserver-discussions-components-files/791/Report.txt 

    Regards,

    james

  • Hello James,

    thanks for going through the diff in so much detail.

    You've confirmed all the differences that I identified myself, and you've answered my questions regarding the three DDRSS_PHY_* changes:

    ------------------------------------------------------------------------
    #define DDRSS_PHY_91_DATA 0x0100C0C0   <> #define DDRSS_PHY_91_DATA 0x0000C0C0
    [James] This was a power optimization.  This disables the "always on" mode of the input enables for data byte 0
    ------------------------------------------------------------------------
    ------------------------------------------------------------------------
    #define DDRSS_PHY_347_DATA 0x0100C0C0  <> #define DDRSS_PHY_347_DATA 0x0000C0C0
    [James] Same as above for data byte 1
    ------------------------------------------------------------------------
    ------------------------------------------------------------------------
    #define DDRSS_PHY_1375_DATA 0x030207AA <> #define DDRSS_PHY_1375_DATA 0x03020000
    [James] This is also a power optimization.  This disables VREF controller for addr/cmd signals.  VREF is not used in the PHY for addr/ctrl
    ------------------------------------------------------------------------
    

    If we could at least have the change log in future versions that would be great. I guess we can deal with the other issues, especially since now I know that I need to archive DDR config tool versions along with the matching SysConfig version.

    Thanks for your support!

    Regards,

    Dominic