Even if no failures are detected, the results might highlight a weakness in the design.

In the last two articles (June 2016 and July 2016, respectively), we discussed critical signal integrity concerns that engineers face designing the DDR bus, and points to consider while setting up the simulation. We covered how understanding the requirements, and then simulating correctly, increases the odds the board will be functional from the start. This results in reducing the number of spins required for the design, while shortening the time to release. In this third part of the series, we bring the first two parts together by discussing what to look for in the results of the simulation.

The first step after executing a set of DDR simulations is to review the requirements of the bus. To recap from the previous article,¹ this comes down to understanding the receiver requirements of the controller (during read transactions) and of the DRAMs (during write and command/address transactions). The information for the controller is in the datasheet of the controller. Jedec (jedec.org) or the DRAM vendor’s website are good resources for the requirements of the DRAM. The reason this step is critical is that while looking at simulations, the user can understand the subtleties of the results only if the fundamental requirements are known.

One way to ensure the results can be well-understood is to work with a simulator that gives easy-to-understand results, and using the tools provided by the simulator to focus on what is important. The DDR bus is a very wide bus, with each signal containing many bits of transition information, with each transition having a tremendous amount of measurements. These data can be overwhelming. Use the tools at the simulator’s disposal to filter the information and prioritize the order of what needs further analysis. Usually, the worst-behaving signals are a good start.

Worst-case nets can be defined as nets showing the lowest margins on at least one measurement parameter. For example, a signal that has the lowest setup time of all the nets can be considered a worst-case net. It is usually a good idea to analyze the worst-behaving nets regardless of whether they are failing. Even if there is no failure in the simulation, the results might be marginal enough to highslight a weakness in the design. This might manifest itself as a failure, often intermittent, in the real system, which can subsequently take significant effort to debug. This is especially true when one signal has an abnormally low margin for any given measurement. For example, if DQ0 has a 5ps setup time margin, while all the other signals have at least say 40ps margin, it might be worth taking a closer look at DQ0 (and its corresponding strobe).

Several phenomena can see this bad behavior of signals, with different root causes. Often, either the setup or hold time margin may be very low. If it is seen in such cases that one (say setup) is low while the other (in this case hold time) is high, then this implies the strobe (or clock) is not well-aligned with the DQ (or address). In such cases, the remedy is often within the feature-set of the controller if it permits calibration of each individual bit. If so, then the simulation can be redone (automatically if the simulation tool supports this) with the appropriate delays for the signal bits. If the controller does not support calibration of each bit, then this might imply some of the signal bits need a larger or smaller electrical delay while routing.

Another common result is excessive ringing. This can cause violations of multiple parameters, including excessive maximum overshoot, excessive overshoot area, or setup/hold violations. Some violations, such as overshoot, might cause damage to the chips. This damage might not always occur on the first bring-up, but rather might happen over a longer duration of time. So, knowing about such violations early on can save significant costs downstream. Ringing is often caused by improper termination. This can usually be remedied by trying different ODT settings at the receiver until it comes down to an acceptable level. In FIGURE 1, the signal is shooting beyond the Vdd threshold (1.5V) for some duration of time. It is not overshooting so much as to cause a peak amplitude violation. (It would have to go past 1.9V to do so.) However, the voltage-time area, shown in the red area of Figure 1, might be enough to violate the “maximum overshoot area” requirement in the Jedec spec.

Figure 1. Overshoot area.

A third common issue is excessive noise on the signals. This can happen when too much crosstalk energy is injected into a signal from a nearby switching signal. This can be fixed by separating the signals spatially from each other.

Another common issue is the presence of stubs in the channel (FIGURE 2). Stubs in the channel that cause reflections often look like “steps” in the waveform (FIGURE 3). If the stubs can be shortened, such as with test points, it will help clean up the SI. Often, the step seen in the waveform is because the measurement was made on read transactions at the pin of the controller. This can quickly be remedied by shifting the point of measurement at the controller to the die instead of the pin. This measurement issue is caused because often the IBIS file for the controller does not explicitly call out a measurement at the die.

Figure 2. Stub in system.

Figure 3. Reflection effect from stub.

After identifying the issues and their root cause(s), the next step is to fix them on the board, and execute a subsequent simulation. On these “post-fix” simulations, it is often better to first simulate only the section changed so as to save time. Only after the local fixes have been done adequately can an entire board/system be simulated.

Finally, once the board gets manufactured, the simulated waveforms can be compared with waveforms obtained by oscilloscope measurements. With oscilloscopes, it is often not practical to measure every signal on the bus. So, if a few signals measured on the oscilloscope can be validated with the measurements made by simulation, this will increase the confidence of a correct simulation setup.

With a good setup, and proper analysis, simulation can help decrease the overall time required to design a high-speed DDR subsystem.

References
1. Nitin Bhagwath, “Preparing to Simulate DDR Memory Bus Interfaces,” PCD&F, July 2016.

Nitin Bhagwath is technical marketing engineer at Mentor Graphics (mentor.com); This email address is being protected from spambots. You need JavaScript enabled to view it..