Up to this point, the discussion started in
Suffice it to say that there is a reasonably good explanation whythis became the industry-standard methodology. Thus, clock jitteranalysis needs to be separated between input timings concerns (will thedevice function correctly?) and output timing concerns (will the dataeye be big enough?)
DDR2/DDR3 input timings incorporate the clock jitter limits. As long asthe clock jitter specifications are satisfied, all the input timingslimits can be used; they do not require additional derating to accountfor the clock jitter. Thus, functionality is tested to ensure it is notadversely affected by clock jitter as long as the clock jitter iswithin specification limits.
Going back to the earlier example of a 3ns DDR2 SDRAM (DDR2-667)with a tCKavg(MIN) of 3ns and a t JITper limit of±125ps resultsin a clock period as small as 2.875ps.
As far as the input timings are concerned, the maximum jitter valuesdo not adversely affect DRAM functionality. Take the above example andassume it violated the t JITper MAX limit of +125ps with amaximum of250ps. That is a serious violation, but in terms of the input timings,the only penalty is that the clock period is extended from 3ns to3.25ns.
Thus, clock jitter that is greater than the minimum clock jitterspecification limits—and even clock jitter that exceeds the maximumclock jitter specification limits—ensures proper functionality.
Clock jitter that violates one of the minimum clock jitterspecification limits may not necessarily result in improperfunctionality. Unlike input timing limits that must be met to ensureproper functionality, most clock jitter violations against input timinglimits can be neutralized, as will be discussed further on.
Considering that the clock jitter has a random distribution, it islikely that clock jitter specification limits will be violated in mostcases. Neutralizing the clock jitter effects on the input timings willbe required in many of these cases.
An often overlooked concern is that the output timings do not accountfor allowable clock jitter. Output timing specification limits areprovided as if there is zero clock jitter. This means that the outputtiming specifications require that any clock jitter be derated from theoutput timing specification limits.
The DDR2/DDR3 specifications provide a specific derating factor foreach affected output timing specification. Generally speaking, twotimes the amount of clock jitter that goes into the device must bederated at the outputs. It behooves the system designer to not simplymeet the clock jitter specification limits but to keep them to theabsolute minimum.
For example, consider a 3ns DDR2 SDRAM (DDR2-667) that has an actualt JITper of “100ps and +110ps versus a specification limit of±125ps. Although the t AC specification limit is±450ps;after derating to account for the clock jitter, the derated t ACspecification limit is approximately “650ps (“450ps – 2*+100ps) and+670ps (+450ps – 2*”110ps).
The actual derating value is determined by the t ERR5perparameterand not twice t JITper; however, the two are very close invalue. Forexample, the DDR2-667 has a t JITper specification limit of±125ps and a t ERR5per specification limit of±250ps.
It is worth noting that DDR3 requires the use of t ERR10perinsteadof t ERR5per and that the guideline is that two and one-halftimes theamount of clock jitter that goes into a DDR3 SDRAM must be derated atthe outputs.
Clock Jitter Derating
DDR2/DDR3 input timings do not require derating as long as the clockjitter specifications are not violated. If the clock jitterspecification limits are exceeded, the violations may be neutralized orthe input timings may be derated to render the DRAM fully functionalagain. Even though the clock jitter specifications are violated, theDRAM functionality can be maintained, provided the violations can beadjusted for.
The one exception is cycle-to-cycle clock jitter during DLL locking;this condition cannot be neutralized against clock jitter. Fortunately,clock jitter is usually small during DLL locking time. That being said,the closer the cycle-to-cycle clock jitter distribution is to aStandard Normal distribution, the more robust the DLL will be inlocking to the nominal clock rate.
DDR2/DDR3 output timings require derating if any clock jitter ispresent. In theory, this means every design's output timing shouldaccount for some form of derating when analyzing the timing budgets.Examples of each case are provided below and assume the DLL is in thelocked state.
Clock Jitter Violations on InputTiming
When clock jitter specifications are violated, the DRAM's functionalityis at risk because the input timing parameters are compromised. It ispossible to offset the clock jitter by derating all the input timingsby the amount of the clock jitter violation.
Since the clock jitter distribution is Gaussian and the DLL islocked, the t ERRnper and t JITcc specificationscangenerally beignored. This leaves t JITper and t JITdty thatrequire attention. Wheninvestigating input timing parameters for clock jitter violations, thepositive violations are of no concern because the positive violationsactually add margin to the DDR2/DDR3 input timing requirements.
The negative clock jitter violations, on the other hand, steal timeand must be accounted for to ensure proper functionality. Inputderating/neutralizing clock jitter violations assume negative clockjitter violations, unless stated otherwise.
Input timings fall in to three classes: setup/hold parameters,time-based parameters (require a time value converted in to wholeclocks), and n-clock period parameters (require a specific number ofclocks to satisfy.)
Input timing parameters that are a setup or hold specification arenot sensitive to clock jitter because they are referenced to a clockedge that moves. Thus, clock jitter violations do not adversely affectparameters such as address setup (t IS) and hold (t IH.)
Time-based parameters and n-clock parameters are sensitive to clockjitter violations. Time-based parameters, such as write recovery (t WR),can be derated by the amount that t JITper violates thespecificationlimit or it can be neutralized by reducing the clock rate by the amountthat t JITper(MIN) violates the specification limit.
Unlike time-based parameters, n-clock parameters, such as t CKE,cannot be derated to account for clock jitter violations because theyare specified in clock ticks; however, they can be neutralized byreducing the clock rate by the amount that t JITper(MIN)violates thespecification limit.
Neutralizing Clock Jitter on InputTiming Example
To see how clock jitter violations can be neutralized by reducing theclock rate by the amount t JITper(MIN) violates thespecification limit,we can use the same 3ns DDR2 SDRAM (DDR2-667) example as before withthe following specifications:
Assume the clock actually has t JITper(MIN) of “225ps andt JITdty(MIN) of “200ps. These values violate the clockjitterspecifications by 100ps and 75ps, respectively. (DDR3 does not specifyt JITdty; instead, it relies on meeting t CHabsand t CLabslimits).
If the input clock rate (t CKavg) is increased from 3ns to3.1ns andthe minimum half-period clock pulse is increased by 75ps, or untilt CHabs(MIN) and t CLabs(MIN) are no less than1.315ns, the clock jitterviolations will have been and the DRAM can be expected to functioncorrectly, with one caveat: is the standard deviation larger than 10″20ps? If so, more work may need to be done. The importance of the clockjitter's standard deviation and how to apply it is addressed Part 3 inthis series on Clock Jitter and Statistics.
Derating Output Timing Due to ClockJitter
DDR2/DDR3 output timings should always be derated to account for clockjitter because output timing specifications are applicable when thereis zero clock jitter. The only difference between passing and failingclock jitter values is the amount that the output timings need to bederated by.
Unlike input timings, both positive and negative clock jitterviolations are of concern because the positive violations increase thelevel of uncertainty regarding the positive output timing requirements,as shown in Table 1 below.
|Table1: DDR2/DDR3 Output Derating Factors|
Output timings that require derating fall into one of three types:DLL-derived, full-clock, and half-clock. DLL-derived parameters aresignificantly affected by clock jitter. The amount of clock jitterbasically gets doubled at the output for DLL-derived parameters; DDR2derating is t ERR5per, or approximately 2 * t JITper,andDDR3 deratingis t ERR10per, or approximately 2.5 * t JITper.Thus,whatever clockjitter goes into the DRAM, the DLL-derived output parameters require atleast double that in output derating.
Using the previous 3ns DDR2 SDRAM (DDR2-667) example, the tDQSCKspecification limit is ±400ps, the t JITper limit is±125ps, and the t ERR5per limit is ±250ps.(Note: t ERR5peris two times t JITper.) With a measured t JITperof ±100ps, whichis not a violation of the clock jitter specifications, tDQSCK wouldneed to be derated to approximately ±600ps; the minimum is(“400ps) – 200ps = “600ps and the maximum is 400ps – (“200ps) = 600ps.
Full-clock output parameters require derating by t JITper.Half-clockoutput parameters require derating by t JITdty, which in thecase ofDDR3, would be the larger result of 0.47 * t CK – t CHabsor 0.47 * t CK –t CLabs. Table 1 above summarizes which output parameters getderatedand by which clock jitter specification. When developing the timingbudget, the clock jitter specification limits should be used; but whensystem timings are being verified, the actual measured clock jittervalues should be used.
When the clock rate is adjusted to neutralize the effects that clockjitter violations have on input timing specifications, the amount thatthe clock period is increased by adds margin to the data-eye,offsetting the amount by which the output timings need to be derated.
If the derated output timings do not allow the data-eye to close thetiming budget, the clock period can be further increased until enoughmargin is acquired to close the timing.
|Table2: DDR2/DDR3 Output Timing Derating Example|
Example of Derating Output TimingDue to Clock Jitter
Table 2 above shows the outputderating required for two conditionsusing the previous 3ns DDR2 SDRAM (DDR2-667) example and the formulasin Table 1 for both timing budget analysis (derate tospecifications) and a case of measured clock jitter values. The timingbudget analysis uses the specification limits of ±125ps fort JITper and t JITdty and ±250ps fort ERR5per.
The measured analysis uses passing clock jitter specification valuesof “50ps and +75ps for t JITper and t JITdty and±150ps fort ERR5per, but uses the parameter specification limit. Themeasuredderating could likely have smaller values if actual measured values areused.
After reviewing the results in Table2 above , it should be readilyapparent how important it is to keep clock jitter to an absoluteminimum. Simply meeting the clock jitter specification limits can becostly to the output timings.
Next in Part 3: Clock Jitter andStatistics
To read Part 1, go to “Defining clock jitter.“
Scott Schaefer is a SeniorApplications Engineer for MicronTechnology's DRAM group. Mr. Schaefer joined Micron in 1989 and hasspent his Micron career focused on the field of DRAM applications.Prior to Micron, he worked for Synertek and IMP. Mr. Schaefer has over25 years of experience in the electronics industry and has over 50DRAM-related patents.