I have a board we developed using an Arria10 and DDR4. Our project uses the HPS EMIF interface. But I created a standalone version and the operation appears to be the same. The EMIF interface is reporting calibration failure and the EMIF toolkit reports appear to fail at a catastrophic level.
The signals output from the standalone EMIF indicate the PLL is locked, and the cal fail is active.
I have recorded the power up reset and init sequence in a series of scope captures and tables. The first thing that seems incorrect - is a sequence of 11 reset pulses right at the start (and every time I issue the command "Rerun calibration" from the toolkit). The second is I cannot find any indication that the memory interface is commanding any periodic refresh (CKE never triggers and CS_n never triggers).
I have some files that I have created to provide the data I have assembled regarding the measurements of the power up reset and initialization sequence of the DDR4, but I would like to send them privately instead of on the public domain for company proprietary reasons. Please let me know how I can provide the data.
So you say that you've taken the HPS out of the equation by creating a standalone design, which is good. But is the standalone design your own design or are you generating the example design project from the EMIF IP parameter editor and using that design straight with no alteration (other than assigning to the appropriate I/O banks to connect to the external memory)? If it's not the example design, try the example design first and see if you're getting the same results.
If it is the example design and you're still running into issues, a good sanity check is to check your parameter settings one by one against the external memory requirements from the external devices specifications. It may seem tedious, but there are so many settings, it's very easy to make a mistake that prevents even basic operation of the interface.
Hi - thanks for the response.
Yes - I made the example design from the EMIF parameter editor.
And yes, I have already gone one by one through the memory timing compared to the datasheet.
Thank you for the response!
Yes, once the Clock (CK_t and CK_c) becomes active in the reset and init sequence, they stay active indefinitely.
Clarification regarding CKE and CS_n - I do see activity on these signals at power up and when I execute the "Rerun Calibration" command. But only then. If I just let the board sit powered on and do not initiate any commands, neither of these signals toggle at all.
Also - in the EMIF Toolkit Calibration Report, the VREFIN level looks like it is 1.10V - Is this correct? I would think it should be 0.6V.
I think that reason of CKE and CS_n does not toggle after rerun calibration is calibration is failing.
If the calibration passed the EMIF controller is open to the user interface , but the case of calibration is falling EMIF controller is closed to user interface.
For the VrefIN the voltage should be 0.6V as you mentioned.
Ok, if the EMIF report is saying that VREFIN is 1.1 and the via at VREFCA is measuring at 0.6V on all three DDR4 components, then what could be happening in the IP or the EMIF GUI that indicates a different value?
Arria10 DDR4 EMIF IP use the internal VREF for DDR4 interface. I presume that Device generates the Vref internally and EMIF GUI reports that Vref number. I am not sure why the 1.1v is generated for Vref.
Hi - all the relevant documents are attached to the open ticket instead of on the public forum for proprietary reasons. The ticket number is 04861227. If there is a better location to privately share the data, please let me know. Thank you.
I have reviewed the your Arria10 DDR4 debug data and I see that regardless of power up or rerun calibration from EMIF toolkit there is always 11 pulse of reset_n signal assertion from Arria10 DDR4 IP.
I am still checking it ,but assuming it is the EMIF IP calibration sequencer's expected behavior. Anyway after 11 pulse of reset_n assertion the calibration sequencer starts the calibration by toggling the ODT , BG0 , and other signals. However eventually calibration failed by some reason. I have reviewed the board schematic and have some question.
1. In the schematic address and command should be followed by tree topology. Is this topology really implemented on the board layout ? If so Arria10 DDR4 EMIF IP support only Fly-by topology.
2. Address and Command signals is not terminated at VTT ?
The layout really follows a tree topology. Because the Arria 10 physically has the memory pins split on opposite sides of the device, we went with this option. We followed the guidance in Micron's technical note (TN-40-40) which then referred the user to TN-41-13.
All addr/comm traces are matched to within 100mils - which should be less than 17ps between signals. It seems as though I should see something in the EMIF report output - even if it is terrible performance. Instead there is nothing - it looks as though the component is not even active.
Q1: If this tree topology/implementation is truly not supported by the IP, is there a way that I can verify that this is indeed what is causing the problem before I modify the layout?
Q2: Also - I understand what you mean about the VREF being internally generated for the DQ/DQS pins. If that is the case, why does the EMIF report say that VREFIN is 1.1V when it should be 0.6V?
1. Here is the DDR4 layout guideline from Intel and it says that DDR4 EMIF IP require the Fly-by topology for clock ,command and address signals
Can you create the only 16 bit DQ stand alone design with U66 DDR4 component. then the topology should not be matter because there is only one component used. Let 's see the result of the calibration.
2. The reason that VREFIN is reported as 1.1V is VREFIn calibration will be proceed in the later stage of calibration process and the calibration failed in the early stage, thus VREFIn calibration has not been completed and ended with default value with 1.1V. coping the calibration flow chart.
Thank you for the explanation!
Regarding the 16 bit version (single component) - I posted the cal report on the private service request. Originally, it failed the same as the 40 bit version. However, as I have been adding termination to the command lines, a few of them are now showing a calibration window.
Adress/Command calibration will be proceeded at early stage of calibration and looks like the calibration is failing at this stage due to the Adress/Command signal integrity issue.
Here is what we can try to help calibration result in different
1. Skip address command calibration. This is not usually recommended for robust access to the DDR4, but may help to calibration go to further stages. In the IP GUI there is Diagnostics tab check both skip address/command leveling /deskew calibration.
Hi - thanks for the info.
I added termination to all Addr/command lines and the standalone build is now working (and passing cal) with all three components even in the tree topology.
Thank you for your help - especially decoding some aspects of the EMIF toolkit.
I have another question with regard to this - in the calibration report, the CKE_0, CS_0, and ODT_0 signals all say "uncalibrated" in the “Address/Command Margins observed During Calibration”. But all the other signals have a margin reported. Is this correct, or a problem? Thank you