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

Suffice it to say that there is a reasonably good explanation why this became the industry-standard methodology. Thus, clock jitter analysis needs to be separated between input timings concerns (will the device function correctly?) and output timing concerns (will the data eye be big enough?)

Input Timings
DDR2/DDR3 input timings incorporate the clock jitter limits. As long as the clock jitter specifications are satisfied, all the input timings limits can be used; they do not require additional derating to account for the clock jitter. Thus, functionality is tested to ensure it is not adversely affected by clock jitter as long as the clock jitter is within specification limits.

Going back to the earlier example of a 3ns DDR2 SDRAM (DDR2-667) with a tCKavg(MIN) of 3ns and a ^tJITper limit of ±125ps results in a clock period as small as 2.875ps.

As far as the input timings are concerned, the maximum jitter values do not adversely affect DRAM functionality. Take the above example and assume it violated the ^tJITper MAX limit of +125ps with a maximum of 250ps. That is a serious violation, but in terms of the input timings, the only penalty is that the clock period is extended from 3ns to 3.25ns.

Thus, clock jitter that is greater than the minimum clock jitter specification limits—and even clock jitter that exceeds the maximum clock jitter specification limits—ensures proper functionality.

Clock jitter that violates one of the minimum clock jitter specification limits may not necessarily result in improper functionality. Unlike input timing limits that must be met to ensure proper functionality, most clock jitter violations against input timing limits can be neutralized, as will be discussed further on.

Considering that the clock jitter has a random distribution, it is likely that clock jitter specification limits will be violated in most cases. Neutralizing the clock jitter effects on the input timings will be required in many of these cases.

Output Timings
An often overlooked concern is that the output timings do not account for allowable clock jitter. Output timing specification limits are provided as if there is zero clock jitter. This means that the output timing specifications require that any clock jitter be derated from the output timing specification limits.

The DDR2/DDR3 specifications provide a specific derating factor for each affected output timing specification. Generally speaking, two times the amount of clock jitter that goes into the device must be derated at the outputs. It behooves the system designer to not simply meet the clock jitter specification limits but to keep them to the absolute minimum.

For example, consider a 3ns DDR2 SDRAM (DDR2-667) that has an actual ^tJITper of "100ps and +110ps versus a specification limit of ±125ps. Although the ^tAC specification limit is ±450ps; after derating to account for the clock jitter, the derated ^tAC specification limit is approximately "650ps ("450ps - 2*+100ps) and +670ps (+450ps - 2*"110ps).

The actual derating value is determined by the ^tERR5per parameter and not twice ^tJITper; however, the two are very close in value. For example, the DDR2-667 has a ^tJITper specification limit of ±125ps and a ^tERR5per specification limit of ±250ps.

It is worth noting that DDR3 requires the use of ^tERR10per instead of ^tERR5per and that the guideline is that two and one-half times the amount of clock jitter that goes into a DDR3 SDRAM must be derated at the outputs.