Receiver requirements in DDR design

Once we have a topology for the data and address busses in mind or have them laid out on the board (as discussed in my last blog, ‘What causes undesirable SI in DDR designs?’, how do we know whether it will work – and with how much margin?

To figure this out, we first need to know the requirements of the endpoints. Fundamentally, for any communication channel, the receiver has some requirements that must be met in order to successfully communicate. Say, for example, you’re talking to a friend. In order for him or her to understand what you’re saying, the sound must reach a minimum volume. What that volume is depends on their ear-drum sensitivity. Once you know what this receiver requirement is, you can predict the functionality of the channel after measuring the actual signal at the receiver.

To this end, we need to better understand the receiver requirements at both the controller and the DRAM.

Controller requirements

The controller is not defined by any standards committee. It is defined by the marketing and engineering decisions of that controller vendor’s company. They might create a very sensitive, but expensive, chip based on their market demands. Or they might create a not-so-sensitive (but inexpensive) chip based on what they decide.

So, from the controller requirements perspective, the only place to get the requirements is from the controller vendors themselves. Usually, the datasheet contains the information needed. If it doesn’t, you’ll have to contact the Applications Engineer of the company to get more information.

The basic information you’re looking for are the high and low threshold levels for the Data signals and the allowable DQS/DQ skew tolerance limits when the controller reads data from the DRAM. Additionally, you could look up the output uncertainties of the address and data busses. Other characteristics to investigate are whether the controller supports leveling (to be discussed) and de-skew functions.

DRAM requirements

DRAM requirements are defined more consistently by the JEDEC standards committee. There are actually dozens of measurement requirements specified in the documentation. Because it is often unfeasible to go through the entire set manually, an automated simulation tool such as the HyperLynx® DDRx Wizard helps out immensely. Below are a couple of more critical criteria.

Possibly the most critical requirements of the DRAMs are the setup and hold time requirements for DDR3 and the eye-mask requirement for DDR4 (to be covered in a separate blog post). The setup/hold requirements are comprised of a base requirement and an additional “derating” offset.

The base requirement depends on the speed grade of the DRAM and the threshold level selected. A higher threshold requires the voltage to swing more but allows for a smaller time-based (setup/hold) requirement. A lower threshold allows shorter voltage swings but requires more setup/hold time to pass.

The derating offset to the base depends on the received slew rate of the data and the strobe (or the address and clock for the address bus). There are tables available in both the JEDEC spec as well as in datasheets that allow for a lookup of the slew rates with the derating offset.

Additional requirements are:

• The timing relation requirement between the received clock and the strobe must be met for proper functionality. This relates to the need for “leveling,” which we’ll discuss in a future post.
• Signals cannot exceed the rail voltage, or go below the ground voltage more than a specified amount, for a specified duration.
• A relation between the P and N signals of the differential strobe and clocks.
• Threshold levels for the single-ended signals of the strobe and clock.
• Many other nuanced measurements that are best left automated!

For a deeper perspective, refer to my article in PCD&F.