Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 163 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DRA829J-Q1: LPDDR4: DDRSS0 DRAM Temperature polling

Wolfram Stumpf
Intellectual 435 points
Part Number: DRA829J-Q1

Hello E2E-Experts,

according to SPRACU8B / 2.1.1 System Configuration / 11., enabling  "Enable DRAM Temperature Polling" in SPRACU8B_Jacinto7_DDRSS_RegConfigTool.xlsb leads to this:

Enabling this parameter ONLY allows the controller to periodically read MR4 of the LPDDR4. It does NOT change the refresh rate. A software interrupt service routine is required to service the changes in temperature.

According to Micron LPDDR4 data sheet, Mode register MR4 contains:

  • Refresh Rate in OP[2:0]
    • The refresh rate for each MR4 OP[2:0] setting applies to tREFI, tREFIpb, and tREFW. MR4 OP[2:0] = 011b corresponds to a device temperature of 85°C. Other values require either a longer (2x, 4x) refresh interval at lower temperatures or a shorter (0.5x, 0.25x) refresh interval at higher temperatures. If MR4 OP[2] = 1b, the device temperature is greater than 85°C.
  • Thermal offset-controller offset to TCSR in OP[6:5]
    • Configure expected temp gradient

I'm not sure, if I got this right. My understanding is the following:

  • The DDR4 module reads its internal temperature sensor in an interval t(TSI) derived. The length of this interval is affected by the gradient given in TCSR.
  • The DDR4 module derives one scaling factor (0.25, 0.5, 1, 2, 4) for all the refresh parameters (->t(REFI)) and sets MR OP[2:0] accordingly.
  • The DDRSS reads MR4 cyclically and generates an interrupt (on read or on change?)
  • SW gets these values by setting up an ISR to adapt DDRSS refresh configuration according to the value in MR4 OP[2:0]

My questions:

  • Did I get i right (at least basically)?
  • Is there some additional information about DDRSS behaviour regarding this topic? I could't find anything about it in SPRUI1C (MAR 22)
  • Is there more information for the registers DDRSS_CTL_124 - 127? All I found was permutations of these two details:
    • MRR temp check number of long counts until the [normal / high] priority request is asserted for frequency copy [0 / 1 / 2]
    • MRR temp check number of long counts until the timeout is asserted for frequency copy [0 / 1].
  • Does DDRSS generate the interrupt refered to in SPACU8B? If so:
    • What triggers the interrupt (MR4 read done or MR4 changed)?
    • Which interrupt is used? (nothing found in SPUIC1)
  • Is there some kind of example / reference implementation available? (e.g. SDK)
  • Is it mandatory to use this mechanism (speaking -40 / +85°C) or is it just necessary for temperatures above 85°C or an opportunity to gain performance by enlarging refresh below 85°C?

Maybe someone can shed some light on this.

Best regards

  Wolfram

  • 0
    TI__Mastermind 32065 points

    Hi,

    Yes, I think you have the basic concept understood. That is,

    • The LPDDR4 memory will update its MR4 register with the required refresh rate (which varies with temperature)
    • The TDA4 DDR controller has the hardware capability to periodically read the LPDDR4 MR4 value and generate an interrupt, implying that software does not need to trigger the MR4 read (this will happen automatically in the background when the feature is enabled)
    Wolfram Stumpf said:
    What triggers the interrupt (MR4 read done or MR4 changed)?

    My understanding is that the interrupt should occur when MR4 changes value. The ISR would then need to read the MR4 (from the DDR controller registers, which reflects the value read from the LPDDR4 memory).

    Wolfram Stumpf said:
    Is there some kind of example / reference implementation available? (e.g. SDK)

    There is some example in the PDK but I do not think it actually modifies refresh rates. Instead, I think the example just illustrates setting up the interrupt and reading the MR4 value.

    Wolfram Stumpf said:
    Is it mandatory to use this mechanism

    No it is not mandatory to dynamically change the refresh rate. You can use a static refresh rate that aligns to your system's worst case conditions. 

    Regards,
    Kevin

  • 0 in reply to Kevin S
    Intellectual 435 points

    HI Kevin,

    thank you for the information.

    I want to come back on these questions:

    • Is there some additional information about DDRSS behaviour regarding this topic? I could't find anything about it in SPRUI1C (MAR 22)
    • Is there more information for the registers DDRSS_CTL_124 - 127? All I found was permutations of these two details:
      • MRR temp check number of long counts until the [normal / high] priority request is asserted for frequency copy [0 / 1 / 2]
      • MRR temp check number of long counts until the timeout is asserted for frequency copy [0 / 1].
    • Does DDRSS generate the interrupt refered to in SPACU8B? If so:
      • What triggers the interrupt (MR4 read done or MR4 changed)?
      • Which interrupt is used? (nothing found in SPUIC1)

    I think this should be answered by some kind of data that has not made its way to the TRM by now. If you cannot provide this information in the scope of E2E yet, there shoud be a way via our associated FAE.

    Best Regards

       Wolfram