Part Number: AM6421
Hi team
We would like to seek your guidance regarding LPDDR4 refresh-rate management on the AM64 platform.
Background
Our product is based on AM64x and LPDDR4 memory. During product thermal validation, we observed that the LPDDR4 device temperature may approach or exceed the high-temperature operating region under certain ambient conditions.
According to the DDR configuration generated by TI tools, the high-temperature(above than 85℃) LPDDR4 configuration requires a significantly increased refresh rate. While this improves DDR reliability, we have also observed a considerable impact on DDR bandwidth and CPU loading during runtime.
To balance system performance and DDR reliability, we are evaluating the feasibility of dynamically adjusting LPDDR4 refresh parameters according to the memory thermal condition.
1. Current Status of MR4-Based Dynamic Refresh Management
We understand that the LPDDR4 JEDEC specification defines the use of MR4 as a temperature indication mechanism and that memory refresh requirements may vary according to the reported temperature range.
Could you please help clarify:
- Does the current AM64 DDR controller support any automatic temperature-dependent refresh-rate adjustment mechanism based on LPDDR4 MR4 reporting?
- If such functionality exists:
- Is it enabled by default?
- Is it supported by TI software releases and Linux SDKs?
- Are there any reference implementations or application notes available?
- If automatic MR4-based derating is currently not supported:
- Is there any planned support in future SDK or firmware releases?
- Has TI evaluated this feature internally on AM64 devices?
2. Dynamic Refresh Configuration Switching During Linux Runtime
We are also investigating a software-controlled solution to dynamically switch between the normal-temperature and high-temperature LPDDR4 refresh configurations during Linux runtime.
Our current understanding is that changing only the refresh interval register may not be sufficient, because additional timing parameters appear to be associated with the high-temperature configuration.
Therefore, we would appreciate TI's guidance on the following questions:
2.1 Runtime Reconfiguration Feasibility
- Is it officially supported to modify LPDDR4 refresh-related controller settings while Linux is running and code execution is taking place from external DDR memory?
- If supported, what restrictions or precautions should be considered?
2.2 Required DDR Controller Parameters
When switching between normal-temperature and high-temperature operation:
- Which DDR controller registers need to be updated?
- Besides tREFI-related parameters, are timing parameters such as:
- tRASmax
- tREFIab
- tREFIpb
- other Cadence DDR controller settings
required to be reconfigured as part of the transition?
2.3 Safe Runtime Update Procedure
If runtime switching is supported:
- Is there a recommended sequence for applying the parameter changes?
- Is DDR traffic quiescing required before modifying these registers?
- Is controller retraining, reinitialization, or self-refresh entry/exit required?
2.4 Temperature Source Recommendation
For runtime decision-making, which temperature source would TI recommend?
- LPDDR4 MR4 temperature indication
- AM64 internal junction temperature
- Combination of both
If AM64 temperature can be used as a proxy, is there any recommended guard band or threshold strategy available?
3. Expected Target Solution
Our preferred runtime behavior would be:
- Use normal-temperature DDR refresh parameters during typical operation to minimize refresh overhead and maximize performance.
- Switch to high-temperature refresh parameters only when LPDDR4 thermal conditions require it.
- Use hysteresis and thermal margins to avoid frequent switching.
4. Could TI provide an example or reference design demonstrating runtime LPDDR4 refresh configuration updates?
5. Could TI identify any risks related to the following parameters when DDR timing parameters are modified during runtime?
- Data corruption
- DDR controller instability
- Memory training invalidation
- Linux kernel crashes
We would greatly appreciate recommendations regarding the feasibility, limitations, and validation requirements of this approach.
Thank you very much for your support.
Zekun
