Forum Discussion

R_G's avatar
R_G
Icon for New Contributor rankNew Contributor
2 years ago

Arria 10 Custom Board EMIF Settings

Hi,

I am having trouble with memory verification checks (write of a pattern followed by a readback) that are failing for the external DDR4 memory of our Arria 10 custom designed board. This is preventing U-boot from being loaded onto the board. My team suspects that there are incorrect settings for our memory in the EMIF IP of our Quartus project. We have checked them over and the settings see to be correct, but we wanted to get an Intel EMIF expert to review them so I am posting our settings to this forum for feedback. Here is some info regarding our setup:

1) FPGA: Arria 10 PN 10AS066K4F40I3SG
2) Memory: Micron PN MT40A1G16TB-062E IT:F
3) The current settings pass the EMIF Debug Toolkit calibration tests when used in the stand-alone EMIF IP Debug design.
4) The current settings don't seem to work with a simplified Quartus test design that is based on our full Quartus design. The U-boot log indicates a verification failure mentioned previously when doing a memory size/sanity check.
5) I have uploaded the following documents:
A) Screenshots of the EMIF settings in Platform Designer (DDR4_933MHz_EMIF_Memory_Config.7z).
B) Datasheet for the Micron memory being used (Micron_Datasheet_16gb_ddr4_sdram.pdf). We are using the settings in Table 158: DDR4-3200 Speed Bin running at 1866 MT data rate.
C) A schematic screenshot of the memory (Memory_Schematic.JPG) as it is connected on the board.
D) The U-boot log (u-boot_log.txt) showing the memory size/sanity check error that results from a failed verification check. The failure message is "DDR: SDRAM size check failed!" found toward the end of the log.
E) The U-boot source code (sdram_arria10.c) that produces the log error. Note that sdram_size_check() calls get_ram_size_hdmrps() which performs a write/readback test to determine a valid memory size.

If you need more information, please let me know. Any help is appreciated.

Thanks,

Richard

Memory

5 Replies

  • AdzimZM_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Richard,


    I think the error may relate to memory density mismatch between the EMIF IP and the device tree.

    What is the memory density that has been set in the device tree?



    Regards,

    Adzim


    • R_G's avatar
      R_G
      Icon for New Contributor rankNew Contributor
      2 years ago

      Hi Adzim,

      Thanks for your response. The memory density of the preloader (or SPL) and U-boot is set to 1GB (0x40000000):

      From preloader dts file (my_u-boot-spl.txt):

      memory@0 {
      device_type = "memory";
      reg = <0x00 0x40000000>;
      };

      From U-boot dts file (my_u-boot.txt):

      memory@0 {
      device_type = "memory";
      reg = <0x00 0x40000000>;
      bootph-all;
      };

      I have uploaded the dts files for the preloader and U-boot for your reference. I believe these values are correct though. Is there any more information you would like me to provide?

      Thanks,

      Richard

  • AdzimZM_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Richard,


    I've checked the memory density in EMIF IP and the device tree.

    Both have been configured to use 1GB.


    For the EMIF IP setting, you may change the tRFC value in Mem Timing tab to 260 because it's only use 4Gb.

    If the density is changes to 8Gb and 16Gb, you need to change the tRFC value to 350.


    I have a few questions that need your clarification: -

    1. Is there any change that has been done to sdram_arria10.c?
    2. Are you able to enter the u-boot space after the ddrcal?
    3. Do you know where the sdram_size_check get the information from?
    4. Have you tested the board with fabric EMIF IP design example to check the DDR4 status?
      1. If no, I suggest you test the board with fabric EMIF IP design example and check the calibration status of the DDR4 interface.
      2. You refer to this link for Arria 10 EMIF Design Example User Guide: https://www.intel.com/content/www/us/en/docs/programmable/683842/21-1-19-2-0/design-example-quick-start-guide-for.html



    Regards,

    Adzim


    • R_G's avatar
      R_G
      Icon for New Contributor rankNew Contributor
      2 years ago

      Hi Adzim,

      Thanks for your response. I changed the tRFC value to 350ns (was 550ns) to match our 16Gb density. This did not fix the problem though. The verify error - read following write of a known value - is still there in the debugger log. I also tried changing the tRFC vaue to 260, but that did not help either. I have included the u-boot log (u-boot_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt) and debugger log (debugger_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt) from the Quartus build with the tRFC value set to 350ns. I have also uploaded the debugger script (run-u-boot-three-spl-pass.txt) that drives the U-boot load operation.

      Here are the answers to your questions:

      1) Is there any change that has been done to sdram_arria10.c?
      We have added some debug printouts that are prefixed with "HD MRPS" that can be seen in the u-boot_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt file, but that's it.

      2) Are you able to enter the u-boot space after the ddrcal?
      No, the debugger tries to load u-boot image into the external DDR4 memory space that seems to pass U-boot checks, but fails out due to the verify error from the Arm Development Studio "restore" command that can be seen in the debugger script run-u-boot-three-spl-pass.txt file. The debugger log debugger_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt shows the "verify error" that results from the restore command of that debugger script. The verify error always occurs at address 0x0106C1B0 on different runs by the way.

      3) Do you know where the sdram_size_check get the information from?
      It looks like sdram_size_check() calls get_ram_size_hdmrps() - which is a duplicate of the U-boot default get_ram_size() function except for "HD MRPS" debug print statements that we added. This function tests the memory region defined by the passed in parameters of base address and size by writing and reading back known values in that region. This U-boot write/readback test passes though. It's the load of the U-boot image into the DDR4 RAM by the debugger "restore" command that fails on a write of the U=boot image block followed by a read back.

      4) Have you tested the board with fabric EMIF IP design example to check the DDR4 status?
      Yes, it passes calibration with the stand-alone EMIF IP design example. Also, the DDR4 calibration passes according to the U-boot log for our design.

      Thanks,

      Richard

  • AdzimZM_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Richard,


    Thank you for your feedback.


    I have looked into the u-boot_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt and found that the ddr size check is now passing.


    I don't think you have stated the "The verify error - read following write of a known value - is still there in the debugger log" before.

    This issue might be specific to u-boot area.

    So I encourage you to open a new forum for this issue on u-boot debug section.



    Regards,

    Adzim