01-26-2018 01:47 AM
We have a board with a ZU2CG and a 4Gbit LPDDR4 (Micron MT53B128M32D1NP-062 WT:A), 32bit width.
Clocks are 1.2GHz CPU and LPDDR4 at full speed (2.400 GT/s).
Using the provided memory test application (Vivado 2017.4: peripheral test, a.k.a. ZynqMP DRAM Diagnostics Test), we see the following results (see attachment for the full log):
- Memory tests runs error-free
- read eye test runs fine too
- write eye test heavily fails : with such a result, the memory tests before couldn't have worked...
- running the memory test again, shows many failures on the unused lanes (4-7).
Does anybody have an idea what is happening? Is the write eye test not suitable for LPDDR4 at full speed?
Thanks for any help!
01-29-2018 06:15 AM
Update: The test ist called DRAM test (not peripheral test).
Update2: With 1600 GT/s instead of 2400 GT/s, the write eye test shows normal (good) results with the LPDDR4. Still we do not have any problems at 2400 GT/s, but the test fails.
02-02-2018 02:08 AM
I need some additional information from your end on this issue which you have reported:
a) What is the ZU+ package used in your project?
b) Is the Micron part used Single Die or Dual Die part?
c) Instead of 1600Mb/s, try using 2133 Mb/s and observe the DRAM test results. I am guessing that you are using within our data sheet guidelines.
d) How are you verifying that the memory is working fine at 2400 Mb/s?
02-02-2018 02:39 AM
02-04-2018 11:35 PM - edited 02-04-2018 11:36 PM
Thanks, that is a good observation.
Again, please do provide a screenshot of the DDR Configuration page. I am hoping the DRAM settings are not limiting it to 2133 Mb/s.
The max speeds are listed in page-28 http://www.xilinx.com/support/documentation/data_sheets/ds925-zynq-ultrascale-plus.pdf
Kindly have a look at that. The maximum for a dual-die package is 2133 Mb/s.
Memory failures at a higher frequency usually denote to marginal timing issues which can be checked at PCB level. I hope you have followed all the required guidelines provided in the PCB guidelines: http://www.xilinx.com/support/documentation/user_guides/ug583-ultrascale-pcb-design.pdf. Can you confirm that also?
02-05-2018 02:11 AM
Please find the screenshot attached. The values are double checked and correct for 2400MT/s. Here, we have reduced the clock to 2133MT/s while keeping the RAStoCAS Delay and PrechargeTime.
Again, we have a SINGLE-die memory, not dual-die. Single die should support 2400MT/s.
If you look at the eye-pattern results for 2133MT/s, the eye opening width is excellent (like 80%). Our LPDDR4 is placed very close to the Zynq, the longest signal group has a length of approx 27mm, the shortest of 14mm. This includes lengths inside the Zynq.
We have closely followed the PCB guidelines you mentioned and the length groups are very closely matched (to within one mil), including the lengths inside the Zynq.
Please note: Even under long memory pattern tests, we do NOT see any bit errors at 2400MT/s. All the eye-tests are really perfect at 2133MT/s, read eye test at 2400MT/s is also perfect. Only the write-test fails, and it fails completely: There is _no_ eye opening at all. How can this be, we only changed the clock from 2133 to 2400 (13% higher).
02-05-2018 11:18 PM
Is there any indication of issues besides just the memory test? Be sure to use at least Vivado 2017.3 memory test, as we have fixed issues with the test, but there may be more.
02-09-2018 12:50 AM
Running the write-eye test first gives a very different but still bad picture: Lane0 shows two (sic!) eyes, Lane1's eye is small and asymmetric; Lane2 looks good, Lane3 is similar to Lane1.
After this, running the READ eye test shows Lane0 as a complete fail, Lane1 as bad and Lane2 and Lane3 as good.
Somehow the read and write eye test seem to influence each other, which shouldn't be...
02-09-2018 12:49 PM
02-14-2018 12:07 AM
You say that booting Linux is a "stronger test" than running the pattern tests? Really? Why? We are not using Linux and therefore we are only doing such tests when it is clear that it would really bring new insights in the problem. As stated before: We do not see any problems with our own software.
02-14-2018 12:43 AM
Booting linux has always been a tougher test than synthetic memory tests. There are many CPU accesses and the asynchronous nature of the execution flow tends to be fairly strong. Over the years, I've seen linux boot find failures on a marginal board that the normal memory tests did not.
Of course, building Linux has been harder than just downloading an example SDK test- but I think that has changed with Petalinux. I'd suggest doing a quick test of building and downloading linux via JTAG using the Petalinux tools. It accepts a .hdf export from Vivado to configure linux and will build and download the entire kernel and filesystem automatically over JTAG (albeit, somewhat slowly). A boot failure would again likely be a false negative, of linux configuration- but if it does boot I think you can be assured you have a fairly robust DRAM interface.
Perhaps I'll write an Answer Record next time for custom boards wanting to do a 1-time linux boot for memory test purposes.
03-06-2018 10:31 AM
Meanwhile we have Petalinux running on our board. LPDDR4 is at 2400MT/s (as with the stand-alone tests above). No memory problems detected so far...
So I think it is time for Xilinx to look into the eye test ... (and stop letting me make more and more time consuming tests).