tRFC not showing correctly, instead tRFC2 is reported

[jlpetz]

Per my screenshot here https://github.com/irusanov/ZenTimings/issues/35#issuecomment-2964607792 on a ASRock B650M sporting a 8500G CPU. The tRFC=tRFC2, which is not correct. The correct value should be 850 per the bios. Will attach debug logs shortly.

Debug_Report_29163262.8399472.txt

[irusanov]

Thanks for the report, it might be helppful to solve the other issue with rank detection. As for the tRFC, I think it's the bios that reports it this way as the same value is reported on both places - tRFC register and AOD table.

[jlpetz]

I think this could be why https://forum-en.msi.com/index.php?threads/terminators-resistors-timings-etc-am5.407067/

"Or while we're on the subject of settings. Ryzen 7000 and 9000 do not use tRFC2 and tRFCsb, only the 8000 series does."

Also kindof aluded to by anta777 in response to question on tRFCsb in post 43 & 45 here https://www.overclock.net/posts/29069811/

I'm no expert on this topic. But I'm guessing from this that Ryzen 8000 series APUs has FGR and so use tRFC2 and tRFCsb, and that might explain why the '850' is not used and reported by the ASRock bios to Zentimings. Yet if it's a Ryzen 7000 and 9000 then it's the other way around and FGR (tRFC2 and tRFCsb) is not used and only tRFC is used?

[remittor]

Yet if it's a Ryzen 7000 and 9000 then it's the other way around and FGR (tRFC2 and tRFCsb) is not used and only tRFC is used?

The leaked Intel sources contain the following:

  if (Ddr5) {
    if (Inputs->FineGranularityRefresh) {
      // Fine Granularity Refresh mode uses tRFC2
      GetSetVal = TimingOut->tRFC2;
    } else {
      GetSetVal = TimingOut->tRFC;
    }
  } else {
    MathTemp = TimingOut->tRFC;
    if (Lpddr5) {
      MathTemp *= 4;
    }
    GetSetVal = MathTemp;
  }
  MrcGetSetMcCh (MrcData, Controller, Channel, GsmMctRFC, WriteToCache | PrintValue, &GetSetVal); 

FineGranularityRefresh = FGR FGR mode is always active when using DDR5.

Although there is an exception for older DDR5 modules:

              if ((DimmIn->Spd.Data.Ddr5.ManufactureInfo.DramIdCode.Data == 0xAD80) || (DimmIn->Spd.Data.Ddr5.ManufactureInfo.ModuleId.IdCode.Data == 0xAD80)) {
                DateCode = ((DimmIn->Spd.Data.Ddr5.ManufactureInfo.ModuleId.Date.Year << 8) | (DimmIn->Spd.Data.Ddr5.ManufactureInfo.ModuleId.Date.Week));
                if (DateCode < 0x2106) {
                  DEBUG ((DEBUG_INFO, "Disabling FGR and PBR for DDR5\n"));
                  Inputs->FineGranularityRefresh = FALSE;
                  Inputs->PerBankRefresh = FALSE;
                  Inputs->RefreshHpWm    = 4;
                  Inputs->RefreshPanicWm = 5;
                }
              } 

[gupsterg]

I think this could be why https://forum-en.msi.com/index.php?threads/terminators-resistors-timings-etc-am5.407067/

"Or while we're on the subject of settings. Ryzen 7000 and 9000 do not use tRFC2 and tRFCsb, only the 8000 series does."

Also kindof aluded to by anta777 in response to question on tRFCsb in post 43 & 45 here https://www.overclock.net/posts/29069811/

I'm no expert on this topic. But I'm guessing from this that Ryzen 8000 series APUs has FGR and so use tRFC2 and tRFCsb, and that might explain why the '850' is not used and reported by the ASRock bios to Zentimings. Yet if it's a Ryzen 7000 and 9000 then it's the other way around and FGR (tRFC2 and tRFCsb) is not used and only tRFC is used?

My belief is tRFC2 sets tRFC1 on 8000 series, this is a screenshot on my B650E-I with 8400F. I can set tRFC1 as 1, but what is set as tRFC2 is shown as in use for tRFC1.

tRFCsb is in use, as if set that as 1 my board will not complete POST, same way if tRFC2 is set to 1 it will not complete POST.

[jlpetz]

My belief is tRFC2 sets tRFC1 on 8000 series, this is a screenshot on my B650E-I with 8400F. I can set tRFC1 as 1, but what is set as tRFC2 is shown as in use for tRFC1.

tRFCsb is in use, as if set that as 1 my board will not complete POST, same way if tRFC2 is set to 1 it will not complete POST.

I wasn’t sure if 8400f would be similar to the 8000Gs as technically it’s not a APU(lacks integrated GPU). But I guess it’s based on a similar laptop/mobile CPU designs adapted to desktop use from the Phoenix line of chips. See Wikipedia entry https://en.m.wikipedia.org/wiki/List_of_AMD_Ryzen_processors where it is listed seperate to APUs.

Can you add a screenshot of Zentiming and debug logs? From what you describe, I imagine the behaviour is the same as what I said. TRFC isnt used but seems to get populated to match trfc2 since it’s missing on the system and zentiming can’t read it.

Another way to prove it test your Ram with varying tRFC2 and tRFCsb, but you’ll need to use a converter as most tools/systems just use tRFC and if it’s not in use. So you need to instead benchmark tRFC2/sb(but compare it to the expected tRFC tables)

See tRFC tab for approx timing per type of memory IC https://docs.google.com/spreadsheets/u/0/d/16jMBDVEvNFkjkJ-RBW5hllsVdHgxVyaGMvY-Fz_ONtE/preview?pli=1#gid=1452003792

And row 74 section of the calculator (to get rfc2 and sb, from a trfc value) https://docs.google.com/spreadsheets/u/0/d/1TfGAex1K0_Af9idWtcgic1-IMY1D8fWn3IudKAZo43c/htmlview

By testing different values you’ll likely see that you get tRFC (per zenTimings) lower than should actually be possible to get per the IC memory charts. This is because it’s not using it and is instead using tRFC2/sb which because they are not doing a full refresh (tRFC) but instead Fine Grain Refresh (fgr), they can do it in a faster timeframe. Ie. your not actually getting faster timings, because trfc2/tRFCsb are not doing a full refresh like trfc and are not comparable, but Zentimmings seems to copy trfc2 to trfc and display the latency timing as if they are equal. Hence this bug report

[gupsterg]

@jlpetz

I believe tRFC1 is in use, I believe tRFC2 sets tRFC1 on 8000 series, read on and hopefully what I'm seeing, you may also.

In my previous comment the reason I showed the UEFI screenshot, was to show tRFC1 set to 1 nCK will POST and if UEFI shows read back of DRAM Timings in use, you can see tRFC2 sets tRFC1.

The UEFI screenshot was also shown to show that it's not only ZenTimings that reads back nCK of tRFC1 as set value of tRFC2. Even AMD Ryzen Master will show nCK for tRFC1 as what is set for tRFC2.

So this is not an issue with ZenTimings, it's how 8000 series works/reports tRFC.

A DRAM IC should use lower nCK for tRFC2 then tRFC1, but on 8000 series any DIMMs I use, tRFC2 will only be the nCK that the DIMM will use for tRFC1.

So I believe tRFC1 is in use, tRFC2 sets it on 8000 series.

tRFCsb I can use a lower nCK then tRFC1/2 and see a mild repeatable performance gain in some tests, so for in use, besides knowing setting to 1 nCK results in no POST on 8000 series.

We don't have access to tREFIsb, I believe tREFI is being used.

Debug report in other issue report for ZT.

[remittor]

By testing different values you’ll likely see that you get tRFC (per zenTimings) lower than should actually be possible to get per the IC memory charts. This is because it’s not using it and is instead using tRFC2/sb which because they are not doing a full refresh (tRFC) but instead Fine Grain Refresh (fgr), they can do it in a faster timeframe. Ie. your not actually getting faster timings, because trfc2/tRFCsb are not doing a full refresh like trfc and are not comparable, but Zentimmings seems to copy trfc2 to trfc and display the latency timing as if they are equal. Hence this bug report

I am of the same opinion.

ref: https://static6.arrow.com/aropdfconversion/fc2b144ccf061160504edd742d01cb58fdda91bb/ddr5_sdram_core.pdf