AMI for DDR5 Made Easy

In a post last week, I covered IBIS and AMI. One big change that is happening is that the DDR5 standard will (indirectly) mandate using AMI models.

DDR5

In the DDR5 standard, which is expected to be published in summer 2018, DRAM will be specified to include DFE (decision feedback equalization) capability. Modeling DFE means, in practice, creating and using AMI models. In effect, the techniques used for the last decade or so to analyze serial links are being extended to parallel memory interfaces.

However, the nature of SerDes and DRAM means that there are some differences. Serial lines are often long and lossy. However, DRAM is shorter and less lossy. Low loss sounds like a good thing, and in some ways it is, but reflections remain bouncing around for a long time in a low-loss link, whereas reflections in longer serial links are rapidly attenuated due to the high loss. This is the motivation for using DFE, which squelches errors and addresses reflections. In SerDes there is one transmitter and one receiver. But systems like PCs and servers often have multiple DIMMs on the same bus, and sometimes unpopulated sockets, all of which make the reflection problem worse.

Although DDR5 is not finalized by JEDEC yet, our design IP group can't wait that long, and nor can DRAM suppliers, nor can our groups working on next-generation signal integrity (SI) methodology, mostly delivered in the Sigrity product line. They need to get the development going and make any changes necessary to hit the moving target of the final standard.

AMI Builder

The goal of AMI Builder is to enable users to quickly build IBIS-compliant AMI models from known good AMI module libraries, rather than starting from scratch with an empty text editor and writing inevitably buggy code. If you don't have good software development expertise in a language like C, then the learning curve is even steeper.

The basic approach is to have building blocks such as FFE (feed forward equalization) for the transmitter. These wizards then allow you to set, or in some cases will automatically calculate the parameters. For example, above shows setting the parameters for the FFE and then having it calculate the values for the taps. Graphs can be plotted direct from the wizard without needing to go and run simulation.

The receiver path looks like the picture above. As a reminder, AGC is automatic gain control, CTE (or CTLE) is continuous time (linear) equalizer, and DFE is decision feedback equalization. The signal comes in on the left out of the channel, and on the right, the receiver delivers the data and the recovered clock.

Once the wizards have been used to set up the various options, the model is instantly compiled into a DLL and made available for simulation and testing. During testing, blocks can be enabled, disabled, edited or deleted as required. The big advantage of this process is that the user can focus on the architecture and not on code writing. It is also quick, with push-button model creation once the choices have been made.

AMI modeling and the AMI Builder technology were originally developed for SerDes applications, but have been extended into DDR applications.

AMI for DDR4

DDR4 already brought some new challenges, in particular, DQ mask compliance checking, which is making sure that the eye stays outside the mask to ensure the system works without errors. This is illustrated above where the mask is the rectangular box in the middle that the signals successfully stay out of, meaning that the eye is open "enough" to meet the standard.

There was also a requirement for bit error rate (BER) analysis, which required channel simulation and bathtub curves. Note that these bathtub curves are nothing to do with the identically named reliability bathtub curves that show high failure rates at the beginning and end of life of a semiconductor (infant mortality, and aging). A signal integrity bathtub curve is created by injecting jitter and noise into the input. The center pane of the above image is the bathtub curve. There are two bathtubs, one using the jitter to get a horizontal (timing) bathtub, and one using the noise to get a vertical (signal level) bathtub.

The simulation required to estimate the BER is only really feasible using an IBIS-AMI model due to the number of bits required (hundreds of thousands or millions). Cadence delivered the first IBIS-AMI model for DDR4 in summer last year, and presented it at DesignCon earlier this year.

Another change with DDR (versus a serial link) is due to it being a parallel interface, so there is crosstalk between bits and simultaneous switching noise. These both need to be captured in the bus characterization simulation.

AMI for DDR5

First caveat is that JEDEC has not finalized the DDR5 standard, so don't blame me if they change anything. But it's getting close to final so I doubt that anything major like the data rate will change. But here is what it's looking like:

• mask-based compliance checking (as in DDR4 and discussed earlier) will continue
• supply voltage will drop from 1.2V for DDR4 to 1.1V for DDR5
• data rates will run up to 6.4 Gbps
• on-die termination (pulled-up VDDQ) will be available for address buses, not just data buses
• FFE, CTLE, and DFE is expected at the controller side for data buses (see my earlier post for more details on these equalization approaches)
• DFE is expected on the memory side too, for data buses

In the context of this post, what this means is that channel simulation and AMI Builder will be key capabilities, especially for the new wave of engineers who need to create AMI models for the first time. 

Micron collaborated with Cadence to deliver the industry's first IBIS-AMI model for (provisional) DDR5 in early 2017. This was also presented at DesignCon earlier this year.

Video

This video doesn't cover any of the DDR5 stuff since it was made a couple of years ago, but it goes over much of the content of this post:

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.