Forum Discussion

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

Arria 10 HPS EMIF DDR3 Calibration Failure

I am bringing up a custom Arria 10 SX board and have been running into issues with getting my DDR3 SODIMM to calibrate when connected to the HPS EMIF conduit. The EMIF example design calibrates pro...
AdzimZM_Altera's avatar
AdzimZM_Altera
Icon for Regular Contributor rankRegular Contributor
2 years ago

Hi Greg,


Thank you for the update.


1. We are currently testing with a memory clock of 400MHz (DDR3-800) with the thought that slowing down the memory interface would give us the best chance of successful calibration. Is this a good idea, or should we run at the rated DDR3-1600 speed of the SODIMM?

  • Yes it's sometimes can pass the calibration at lower frequency.
  • Have you tried to run at 800MHz? This may need to change some settings that related to memory clock frequency.


2. Are the settings you provided taking into account our memory clock of 400MHz, or should we make additional adjustments (such as dropping our CAS latency to 6 and write CAS latency to 5)?

  • Yes I have used the memory clock of 400MHz to set the tIS, tIH, tRRD, tFAW, tWTR, tRTP.
  • The CAS latency and write CAS latency have been taken from Speed Bin table for DDR3-1600.


3. For tRRD, tWTR, and tRTP, you changed the values from 4 cycles to 3. Is this correct per pg. 81 of the memory datasheet? Also, would you set tFAW to 50ns for DDR3-800 or 40ns for DDR3-1600 since we're using x16 devices?

  • My understanding on the datasheet that you have given that the base device is configured with 256Meg x 8.
  • Then the page size for this configuration is 1KB.
  • Therefore I have referred to DDR3-1600 Speed grade column and 1KB page size row.
  • The cycle values are been calculated based on the memory clock of 400MHz.



4. Since the EMIF example design passes calibration, are there things specific to the GHRD that we should be looking at (e.g. reset, PLL lock status, any debug registers, etc) to let us know the status of the calibration?

  • The HPS EMIF is a harden IP that is not exposed to user logic.
  • The status signal is not provided from the IP to analyze the calibration status.
  • That's why we used FPGA EMIF that placed at similar pin location and have similar EMIF IP configuration to debug the interface.
  • But currently the calibration is okay at the FPGA EMIF.


Since you have the skew information, are you seeing any timing violation in the design after finishing compilation process?


Thanks.

Regards,

Adzim


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

Hi Adzim,

Thank you for the information.

I don't see any timing violations in the HPS or EMIF example designs with or without the board skew being applied.

Given that the EMIF example design passes calibration (at least per the local_cal_status_pass signal), can you think of anything that would cause the HPS to fail other than something in the HPS design structure, timing errors, or the U-Boot SPL bootloader configuration?

Does the HPS calibration do anything different that what occurs during the EMIF example design calibration (e.g. the EMIF always exercises the same address, but the HPS does a more exhaustive memory test)?

Or should any DDR3 memory configuration that passes calibration for the EMIF example design always pass when combined with the HPS EMIF conduit?

For the HPS test, I am programming the full FPGA bitstream (i.e. not using Early Release mode) via JTAG and then running the ARM DS bootloader script from RocketBoards to load and execute the SPL initialization code. Does this seem like the best way to test the HPS calibration, or should I try another method?

Thanks,

Greg