Dealing with clock jitter in embedded DDR2/DDR3 DRAM designs: Part 1

Scott Schaefer

November 24, 2008

Scott SchaeferNovember 24, 2008

Prior to DDR2 technology, the expectation was that clock jitter specifications could be absorbed by the DRAM timing specifications. DDR2's faster clock rates and on-chip delay locked loop (DLL) changed all that, and industry-standard clock jitter specifications became a requirement for users and suppliers, and some, such as Micron, actually started specifying clock jitter specifications with the release of DDR memory.

Despite the fact that there seemed to be enough timing margin with DDR, the inclusion of the DLL begged for clock jitter guidance. Now, even though both DDR2 and DDR3 have clock jitter specifications, few DRAM users understand how to apply them or how to determine if their system clock violates the specification limits and what action to take if it does.

This series of three articles explores DDR2/DDR3 clock jitter specifications and provides guidance to embedded systems developers on how to apply them and how to deal with violations since many systems will unintentionally encounter them. (Note that statements made are equally applicable to DDR2 and DDR3 SDRAM, unless stated otherwise.)

Defining Clock Jitter
Clock jitter in DDR2/DDR3 systems is bound by clock jitter specifications in both positive and negative directions; the negative direction corresponds to a smaller clock period and the positive direction corresponds to a larger clock period. The specifications also limit the allowable clock jitter to Gaussian (or normal) distribution. If the clock jitter is not Gaussian in nature, then the clock violates the timing specifications.

What does Gaussian "in nature" mean? "In nature" is meant to convey that it is unlikely that the clock's profile will reveal a perfect Gaussian distribution; however, it should be close. How close? One way to answer that is to check for deterministic clock jitter. If deterministic clock jitter is observed, then it is likely not Gaussian enough.

The two primary modes of operation are when the DLL is locking and when the DLL is locked. Each is associated with one set of concerns and criteria during initialization and another set of concerns and criteria during operation.

Random Clock Jitter
It is well understood that any clocked system will have some amount of random variability with its clock period. Even though good design practices can keep this skew to a minimum, there will always be some clock jitter. The benefit of restricting clock jitter to a Gaussian distribution is that the minimum and maximum clock pulse widths will only occur once in a while and not over back-to-back clock cycles (Figure 1 below.)

Because clock jitter is random and can fit a Gaussian profile, tERRnper specifications can be supported to minimize the effect on functionability. This is important because several timing parameters and commands require multiple clocks to occur.

Figure 1: Standard Normal Distribution

Non-Gaussian Clock Jitter
If consecutive clocks are allowed to be at or near tCKabs(MIN) and or tCKabs(MAX) in value, as would be the case with bimodal distribution (Figure 2 below), then the DRAM would need a specification relaxation and/or the ability to allow less clock jitter; or manufacturers would have to deal with lower yields and higher costs. Even at that, extremely complex DLL locking circuitry would be required.

Figure 2: Bimodal Distribution

If the clock jitter is not Gaussian but it's close, technically, it would be a specification violation. However, in many cases, it will not adversely affect the DRAM's ability to function correctly.

For example, if the DLL is locked and the clock jitter yields a distribution like the one in Figure 3 below, as long as the tCKabs(MIN) specification limit is not violated, the bulk of the non-Gaussian distribution is adding time to most of the clock pulses, relative to tCKavg, and does not hurt the DRAM's ability to function correctly. The one caveat is that as the clock jitter distribution becomes less Gaussian, the more difficult it will be for the DLL to get a good lock.

Figure 3: Non-Gaussian Distribution with MAX Skew

Conversely, if the DLL is locked and the clock jitter yields a distribution like the one in Figure 4 below, even if the tCKabs(MIN) specification limit is not violated, the non-Gaussian distribution is losing time to most of the clock pulses relative to tCKavg and could prevent the DRAM from functioning correctly.

Figure 4: Non-Gaussian Distribution with MIN Skew

The best way to determine the level of risk from a clock jitter specification violation (after first minimizing the clock jitter violation as much as possible, of course) is to work with the DRAM supplier. In most cases, the DRAM supplier should be able to help determine whether the existing design is relatively safe or that the clock jitter violation(s) need to be minimized or fixed.

< Previous
Page 1 of 3
Next >

Loading comments...