We are currently working on write leveling, gate training and read leveling on a Vybrid-based board with external DDR3 memory (Micron MT41K256M16HA-125 AIT:E). Unfortunately, we are unable to obtain any values for the rising edge using the procedures described in chapter 10.1.16 of the Vybrid Reference Manual (rev. 8).
First of all; it is not clear about the order of these procedures. Assuming that the manual list the procedures in the correct order, we have focused on getting the rising edge in write-leveling first.
It seems that, using table 10-25 (page 1593), we keep adjusting WRLVL_DL_X for data slices 0 and 1 until they reach zero. At this point, we terminate the leveling procedure, using 0x00 for the write leveling delay. The board boots with with this value, but it also boots without any leveling/training at all.
Any help would be greatly appreciated.
We are already familiar wit the top two links, and they seem to focus on the DDR validation tool in Processor Expert. This tool is of no interest to us.
The two latter threads you are referencing are not accessible to us, stating "Unauthorized: Access to this place or content is restricted. If you think this is a mistake, please contact your administrator or the person who directed you here."
If you think these threads would be useful to our situation, could you the provide us access to these threads?
Please pay attention on the Mark Middleton comments in
Vybrid: About DDR leveling feature on DDRMC.
"First, I want to make sure that we correctly define and understand the different timing parameters, because the IP we are using in Vybrid uses confusing terms:
To help understand this last point, I am attaching an explanation I recently wrote that discusses Write and Read Latency timings and the settings used both for the DDR devices and for the PHY.
Second, the Vybrid DDR controller only supports training using a software mode controlled by the Memory Controller (Hardware Training is not supported by the PHY). NXP does not have any SW to perform Write Leveling because we do not expect customers to use memory in a Fly-By Topology. The total memory address space supported by Vybrid is easily accommodated by one or two DDR devices. Fly-By Topology is typically used for x64 and x128 bus widths.
Nevertheless, if the customer really wants to configure DDR3 in a Fly-By Topology, they can manually enter delay values into the WRLVL_DL_0/1 fields based on trace length differences from their layout. Mismatches up to 25% or tCK (clock period) are allowed, so the value in the filed doesn’t have to be very accurate."
As for the DDR Stress test tuning - I will send You recommendations via e-mail.
Our apologies if we did not make ourselves clear.
As mentioned: We are familiar with the comment and thread you are referencing. Hence we have updated our training-routines to reflect the corrections made in said thread, yet we still do not see any change in our results.
We are also familiar with the document you sent me by e-mail. However this document is lacking the details we need to progress.
Part of the motivation for us to implement the calibration routines in question was to help with some issues discovered on two of our boards. We have ten boards in total, seven of which are passing all memory tests and do not show any signs of issues, one which is untested and two which have failing memory-tests during cold-boot. The two boards in question do function properly after pushing the reset-button, at which point they show no sign of memory-issues what so ever, even when stress-testing (using a run-time memory testing suite within our test application).
Let's consider section 10.1.6.16.1 (Detailed Software Leveling Procedure) of the Vybrid RM :
To run leveling mode operations, the MMDC and PHY should be initialized, and the
appropriate delay parameters should be written with the value of delay that is needed for
each data slice X in the PHY. The delay parameters used by the software leveling option
• Write Leveling: WRLVL_DLL_X bits
• Gate Training: RDLVL_GTDL_X bits
• Read Leveling: WRLVL_DL_X bits
At this point, the software should set the CR93[SWLVL_LOAD] to ’b1. This action will
trigger the MC to de-assert the CR94[SWLVL_OP_DONE]and the MC will initiate a
loading of the delay values into the data slices. The MC will then wait for the load
operation to complete, and initiate a write level strobe or a read burst. The MC will wait
for the response from the memory and save the response into the
CR94[SWLVL_RESP_2], CR95[SWLVL_RESP_1],CR94[SWLVL_RESP_0] for each
slice X. Once all responses are saved, the MC will assert the CR94[SWLVL_OP_DONE]
and generate an interrupt. This informs the user that the response data is available for the
initial delay values.
The software should use the response values CR94[SWLVL_RESP_2],
CR95[SWLVL_RESP_1],CR94[SWLVL_RESP_0] to determine the next operation. For
MC Evaluation mode, the response will indicate if the delay is appropriate, or must be
increased or decreased. If the delay must be changed, the new delay value should be
written to the associated parameter and the load sequence should be performed again.
Is it possible to look at log of testing procedure for this case : what values are loaded to the registers,
what are responses ?
Our leveling procedures are based on the procedures described in the Reference Manual, including the section you are referring to.
Here are the logs you asked for:
Each calibration is run after a forced ZQ-calibration. The top two lines state the ZQ PU- and PD-legs respectively.
A few observations:
thanks for the data. Note :the fact, that leveling calibration procedures
cannot obtain values may mean some inaccuracy in PCB design : please check DRAM
trace lengthes - if they meet recommended rules.
Also, are prime data bits (DQ0/8) are connected properly ?
Our HW engineer is ensuring us that the D0/8 is connected properly.
Regarding the trace lengths:
Net | Total Etch Length (mm)
DDR_A0 | 19.2536
DDR_A1 | 19.4868
DDR_A2 | 19.3504
DDR_A3 | 19.4200
DDR_A4 | 19.2596
DDR_A5 | 19.3363
DDR_A6 | 19.2846
DDR_A7 | 19.4457
DDR_A8 | 19.3298
DDR_A9 | 19.4759
DDR_A10 | 19.3770
DDR_A11 | 19.3899
DDR_A12 | 19.2149
DDR_A13 | 19.3452
DDR_A14 | 19.2646
DDR_BA0 | 19.4322
DDR_BA1 | 19.4387
DDR_BA2 | 19.4652
DDR_CASN | 19.5484
DDR_CKE0 | 20.5000
DDR_CLK0 | 24.7779
DDR_CLK0N | 24.8694
DDR_CS0N | 19.1552
DDR_DM0 | 23.8669
DDR_DM1 | 23.0069
DDR_DQS0 | 23.3302
DDR_DQS0N | 23.4173
DDR_DQS1 | 23.1457
DDR_DQS1N | 23.1168
DDR_D0 | 22.9372
DDR_D1 | 23.8522
DDR_D2 | 23.2087
DDR_D3 | 23.9195
DDR_D4 | 22.8930
DDR_D5 | 22.9457
DDR_D6 | 22.8074
DDR_D7 | 23.5879
DDR_D8 | 23.1138
DDR_D9 | 22.8126
DDR_D10 | 23.1966
DDR_D11 | 22.7116
DDR_D12 | 23.4505
DDR_D13 | 22.9836
DDR_D14 | 23.1454
DDR_D15 | 22.9478
DDR_ODT | 19.2805
DDR_RASN | 19.3943
DDR_RESETN | 16.8666
DDR_WEN | 19.2984
Generally DRAM signals traces meet recommendations.
Is it possible to provide simulation of the signals on the board,
in order to take into account real design (say, vias) ?
We did actually find an issue with the trace lengths, with the address lines being marginally too short. As such, we have created a separate thread on this:
We would like this thread to continue discussing the SW leveling features, described in the RM. As mentioned above, the RM does contain several inaccuracies, and therefore ask that you provide a complete and correct descriptions of this feature.
as I know there are no plans to modify the RM, at least, right now (because of
resources lack) General recommendation from Mark Middleton : "[...] if the customer
really wants to configure DDR3 in a Fly-By Topology, they can manually enter delay
values into the WRLVL_DL_0/1 fields based on trace length differences from their
layout. Mismatches up to 25% or tCK (clock period) are allowed, so the value in the
filed doesn’t have to be very accurate"
I'm sorry if I was unclear in my previous post.
Please understand that we need a complete and correct description of the SW leveling procedure containing descriptions of edge-cases. As mentioned earlier, the procedure described in the RM is inaccurate and contains several mistakes.
In particular, we need an answer to the following questions:
* How do we handle cases where the calculated delay values reach maximum/minimum? In the case of write leveling, the write level delay cycles = WRLVL_CLKDL + 0.5 x SW_HALF_CYCLE_SHIFT + WLLVK_DL_<X>/128 (from RM:p1498 - typo?), so we assume WRLVL_CLKDL can be adjusted if min/max is reached. Does read leveling and gate training have similar options?
* Generally what should we handle instances where no values are found? What adjustments should be made for the leveling procedures to be able to fund values?
We are also aware of the DRAM Calibration Tool mentioned in the thread you are referring to. This SW is not an option to us, but were are insterested in a detailed description of the calibration procedure used. Is this something you can share with us?
To get reprocessed, detailed description of SW leveling procedure, may be
as special app note, with corresponding SW tool, helping in this - some
additional resources should be involved here. Please escalate your request to
I hope the following helps.
Have a great day,
Note: If this post answers your question, please click the Correct Answer button. Thank you!