02-07-2018 11:51 PM
I am facing some data error when using UltraScale-DDR4. Could anyone give some valuable points about the problem. I shall list my observations.
Vivado 2017.1, UltraSclae, DDR4, Custom memory part, Bandwidth 2000 MT, Example design with ATG and VIO.
Calibration is success. There is no negative slack in design.
Observation during test.
|1||If Number of transfer is less than 63536, test always passes if address mode is linear
(irrespective of start address).
|2||If Number of transfer is more than 63536, test always fails.|
|3||If Address mode is PRBS, test always fails.|
|4||Always upper 128 bits of 'c0_ddr4_app_rd_data' are failing. ( D(511:448) & D(447:384) ).|
|5||When data pattern is changed, the immediate next test always fails. (for Transfers > 63536).
The point of first error indicate previously written pattern as read data.
|6||If linear, walking 1s and walking 0s data patterns are repeated , it becomes success after few trials.
(provided address mode is linear)
|7||PRBS data pattern always fails if repeated any number of trials (for Transfers > 63536)|
|8||Most time, Failing Address is in higher range ( greater than 0x1_0000)|
In addition, All test passes if I generate the IP with 1600 MT.
02-08-2018 08:50 AM
What board, what device? Is this PS DDR4 (Zynq MPSoC), or a MIG design in programmable logic?
I am assuming MIG in PL due to which board you chose to post, but I still would like to know the board/device. Is it your own design/layout? Which signal integrity tool did you use to validate the SI? (if it is your own board)
Have you observed the data eye pattern on a 'scope? Is it fully open? (as it should be)
What is your clock source? How much jitter does it have? What is the worst case slack in your timing report? What is your system jitter? Are the clock and system jitter values set properly in Vivado?
02-08-2018 06:20 PM
Thanks for your reply and interest to help in this problem.
Device is xcku040-ffva1156-1-i (not any MPSoC based). The board is a custom one. SI & total system jitter calculation and data eye pattern capture has not been done yet as it is newly arrived. I am just trying to find the maximum rate at which DDR4 can be accessed. If I get new information, I shall provide it.
Only below information are with me now.
Clock to the system(MIG) is a differential 200 MHz clock generated from a Low-Jitter Clock Generator on board. It's data sheet showing 0.73 as the RMS phase jitter at test condition 625 MHz (10 kHz to 20 MHz).
I have not given any input jitter or system jitter constraints. Vivado report 0.071 ns as total system jitter and 0.032 ns as worst negative slack.
Should I give total system jitter and input jitter constraints? How can I find them?
02-09-2018 07:09 AM
The input clock jitter in p-p, would be 14 times your RMS value. For system jitter, I would use the default for now (100ps p-p). In future, you need to measure it on a forwarded clock IO pin from the BUFG. Numbers like 300 ps p-p are not unusual if the device is doing a lot of switching. It can be worse if the power integrity engineering is poor (inadequate decoupling, poor layout -- did not follow pcb layout guidelines).
"maximum rate' tells you little about signal integrity (it is the edge rates, not the frequency), so I encourage you to first verify the SI against your pcb original SI simulations you did with your SI CAD tool before fabricating the board.
(And, if you did no SI CAD work, then it is more than likely your board will never work. The cost of the SI CAD tool license pays for itself with one board spin that wasn't needed. Designed wrong, nothing will fix broken SI.)
02-12-2018 05:52 PM
I gave input jitter as 0.01 ns (0.73 x 14) and system jitter as 0.2 (200 ps). But the problem still exist.
Are the values I gave correct? or do I need to try any other values?
Is there anything left which I can try in vivado implementation scope to rectify/isolate this problem?
(because PCB related and SI related validation are not in my scope. I need to pass this info to another team)
02-13-2018 07:31 AM
It is unlikely the jitter is ever lower than 20 ps P-P,
I did not mention that, but there is a floor in large CMOS parts like ours, and no matter how good the source, by the time it gets into the part, it is not going to be as good as 10ps. Anyway, your numbers are OK for the tools. What is the slack reported?
Have you looked at the system jitter as I suggested? That will reveal if you have too much jitter causing data errors. Otherwise, it is not a timing miss due to jitter that is your problem.
02-15-2018 09:51 PM
02-15-2018 11:16 PM
Thanks for the reply.
I understand that SI plays an important role here. But it will take some time to do.
I can share you some more information.
1. Please find attached margins for write and read with complex pattern(at 2000MT).
2. At 1800MT, Test failed.
3. At 1600MT, Test passed ( long run test with PRBS data covering all address space).
4. At 2000MT, long run test passed with PRBS data if transfer size is less than 65,536 irrespective of start address.
5. Only upper 128 bits of 512-bit app_data fails. Accumulated error becomes all F's after few comparison.
Please provide some information if you get any additional points with these observation.