RT1060 SDRAMCR2 configuration in DCD within SDK examples, seems to not be right

[Pencioner]

Hi!

I've had a look at some SDK examples i downloaded some time ago, and found out that SEMC_SDRAMCR2 value was set to 0x00010920 which decodes to very small Active to Active SDRAM delay which is out of spec of SDRAM datasheet used in the board:

/* #1.106, command: write_value, address: SEMC_SDRAMCR2, value: 0x10920, size: 4 */
0x40, 0x2F, 0x00, 0x48, 0x00, 0x01, 0x09, 0x20,

Is this 'acceptable' overclocking or just a mistake nobody noticed for long time somehow?(i had copied this to use with other board which has similar SDRAM chip by other vendor but it even passed the tests despite this too small ACT2ACT value btw so i'm really curious about this configuration value)

By my calculation, f.e. for 60ns delay (as per datasheet) ACT2ACT bits should be set to 0x07 for 133Mhz chip operation (giving 8 cycles 7.5 ns each)

I really want to know is this an error in SDK examples or some errata case in RT1062 Reference Manual

Thanks is advance!

[Pencioner]

Sorry for "speaking with myself" (second answer on own message), but together with some examples which has DCD data setting ACT2ACT to 2 clocks (as in original post) i also found that some examples which use the SEMC_ConfigureSDRAM() call, populate the semc_sdram_config_t structure with the value of 60ns... and as it has both variants of interpretation in the examples, the answer is much desired, because different examples in SDK are contradicting each other. Of course, leaving higher value is safest but this drops performance of memories, nobody wants it.

F.e.:

nxp/SDK_2_16_100_MIMXRT1062xxxxB/boards/evkbmimxrt1060/driver_examples/semc/sdram/semc_sdram.c:    sdramconfig.tAct2Act_Ns            = 60;
nxp/SDK_2_16_100_MIMXRT1062xxxxB/devices/MIMXRT1062/drivers/fsl_semc.c:    timing |= SEMC_SDRAMCR2_ACT2ACT(SEMC_ConvertTiming(config->tAct2Act_Ns, clkSrc_Hz)) | SEMC_SDRAMCR2_ITO(idle);
nxp/SDK_2_16_100_MIMXRT1062xxxxB/devices/MIMXRT1062/drivers/fsl_semc.h:    uint8_t tAct2Act_Ns;                          /*!< Active to active wait time in unit of nanosecond. */

[EdwinHz]

Hi @Pencioner,

Could you please confirm if I am understanding correctly your main inquiry? From your previous comments, I understood a concern about the very small Active to Active SDRAM delay. However, you also found that this delay is different in different SDK examples. Where exactly do you see these differences?

I can't assure how the design team was designing these examples, but as you mention, incrementing the delay is safest, but not fastest. It is likely that a weighing process was considered to achieve a compromise between speed and reliability, and that is what they arrived to.

BR,
Edwin.

[Pencioner]

Hi Edwin,

I'll sum up because yes with my own comments over the post, it became a little bit messy.

So, SDK examples for RT1062 EVK board specify SDRAM timing in two places:
1) DCD, if you define some variables, the build script will include DCD into the image. And, by the way, i used those slightly modified DCD values in my SDRAM initialization, including the ACT2ACT specified as 2 (CR2 value 0x01090A) and it passed memory tests with a bunch of static and LFSR patterns, so i believe this value is correct (and in W9825G6JB datasheet there is a timing called Active(a) to Active(b) which is 2 tCK, as opposed to Ref/Active to Ref/Active time which is 60ns)
2) in the semc_sdram.c file where it fills up the semc_sdram_config_t struct, and calls an SDK function, but there they set a tAct2Act_Ns member to 60 so then it calculates the ACT2ACT as for 60ns which is higher like 5 times or so. And now i believe this is a mistake, which comes from slightly confusing description in Winbond datasheet

And while of course safe values is good so maybe 60ns which translates to 10 tCK clocks is OK for examples but this effectively kills performance, so i'd rather set the value which is correct for the chip

I assume as the memory of whole 32Mbytes of SDRAM pass 64 complex pattern tests using the SDRAMCR2 value of 0x01090A, then 60ns as in semc_sdram.c is wrong and 2 clocks setting as in DCD is right. But i'd like you to have a look and maybe fix the SDK examples (or, if you can confirm that DCD value iw wrong, then fix the dcd.c files in examples)

[EdwinHz · Accepted solution]

Hi @Pencioner,

Thanks for clearing things up!

I understand your concerns. I will pass them on to the SDK, since it makes sense that there could've been a misunderstanding between the "Active(a) to Active(b) which is 2 tCK" and the "Ref/Active to Ref/Active time which is 60ns". 

That said, it is also likely that the code for the semc example was designed with evaluation in mind, not performance. Especially because these values are exemplified in a manner that the developer can easily adjust them to their needs, by just changing the value of "sdramconfig.tAct2Act_Ns" in BOARD_InitSEMC().

Either way, thank you for reporting this!

BR,
Edwin.

[Pencioner]

Thanks! One more tiny thing to add to it - the Reference Manual especially notes that ACT2ACT bits "helps to meet tRRD timing requirement", and of course tRRD is "Active (a) to Active (b)"

Is it OK to mark your answer as accepted solution? Or should I wait for SDK team?

[EdwinHz]

Hi @Pencioner,

Got it, tiny but very relevant detail!

If you don't have any more inquiries or suggestions, I invite you to mark the case as solved. It is quite unlikely that a revision of the SDK that implements this suggestion is released in the near future, since each revision undergoes a series of validations and tests that require time.

BR,
Edwin.

[Pencioner]

Okay i can see that maybe this is a confusion, like, i have taken the Ref/Active to Ref/Active though, not Active(a) to Active(b) (see screenshot from datasheet), so maybe this is all right. Would still like to have this confirmed