Prior to DDR2 technology, the expectation was that clock jitterspecifications could be absorbed by the DRAM timing specifications.DDR2's faster clock rates and on-chip delay locked loop (DLL) changedall that, and industry-standard clock jitter specifications became arequirement for users and suppliers, and some, such as Micron, actuallystarted specifying clock jitter specifications with the release of DDRmemory.
Despite the fact that there seemed to be enough timing margin withDDR, the inclusion of the DLL begged for clock jitter guidance. Now,even though both DDR2 and DDR3 have clock jitter specifications, fewDRAM users understand how to apply them or how to determine if theirsystem clock violates the specification limits and what action to takeif it does.
This series of three articles explores DDR2/DDR3 clock jitterspecifications and provides guidance to embedded systems developers onhow to apply them and how to deal with violations since many systemswill unintentionally encounter them. (Note that statements made areequally applicable to DDR2 and DDR3 SDRAM, unless stated otherwise.)
Defining Clock Jitter
Clock jitter in DDR2/DDR3 systems is bound by clock jitterspecifications in both positive and negative directions; the negativedirection corresponds to a smaller clock period and the positivedirection corresponds to a larger clock period. The specifications alsolimit the allowable clock jitter to Gaussian (or normal) distribution.If the clock jitter is not Gaussian in nature, then the clock violatesthe timing specifications.
What does Gaussian “in nature” mean? “In nature” is meant to conveythat it is unlikely that the clock's profile will reveal a perfectGaussian distribution; however, it should be close. How close? One wayto answer that is to check for deterministic clock jitter. Ifdeterministic clock jitter is observed, then it is likely not Gaussianenough.
The two primary modes of operation are when the DLL is locking andwhen the DLL is locked. Each is associated with one set of concerns andcriteria during initialization and another set of concerns and criteriaduring operation.
Random Clock Jitter
It is well understood that any clocked system will have some amount ofrandom variability with its clock period. Even though good designpractices can keep this skew to a minimum, there will always be someclock jitter. The benefit of restricting clock jitter to a Gaussiandistribution is that the minimum and maximum clock pulse widths willonly 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 onfunctionability. This is important because several timing parametersand commands require multiple clocks to occur.
|Figure1: Standard Normal Distribution|
Non-Gaussian Clock Jitter
If consecutive clocks are allowed to be at or near t CKabs(MIN)and or t CKabs(MAX) in value, as would be the case withbimodal distribution (Figure 2 below ),then the DRAM would need a specification relaxation and/or the abilityto allow less clock jitter; or manufacturers would have to deal withlower yields and higher costs. Even at that, extremely complex DLLlocking circuitry would be required.
|Figure2: Bimodal Distribution|
If the clock jitter is not Gaussian but it's close, technically, itwould be a specification violation. However, in many cases, it will notadversely affect the DRAM's ability to function correctly.
For example, if the DLL is locked and the clock jitter yields adistribution like the one in Figure 3below , as long as the t CKabs(MIN) specificationlimit is not violated, the bulk of the non-Gaussian distribution isadding time to most of the clock pulses, relative to t CKavg,and does not hurt the DRAM's ability to function correctly. The onecaveat is that as the clock jitter distribution becomes less Gaussian,the more difficult it will be for the DLL to get a good lock.
|Figure3: Non-Gaussian Distribution with MAX Skew|
Conversely, if the DLL is locked and the clock jitter yields adistribution like the one in Figure 4below , even if the t CKabs(MIN) specification limitis not violated, the non-Gaussian distribution is losing time to mostof the clock pulses relative to tCKavg and could prevent the DRAM fromfunctioning correctly.
|Figure4: Non-Gaussian Distribution with MIN Skew|
The best way to determine the level of risk from a clock jitterspecification violation (after first minimizing the clock jitterviolation as much as possible, of course) is to work with the DRAMsupplier. In most cases, the DRAM supplier should be able to helpdetermine whether the existing design is relatively safe or that theclock jitter violation(s) need to be minimized or fixed.
Clock Jitter Specifications
Typically, clock generator specifications state the clock jitter limitsin RMS terms, while DDR2/DDR3 SDRAM states clock jitter limits inabsolute terms. These are not the same conditions. It is worth notingthat random jitter is unbounded (which is why the issuer uses an RMSvalue), and DRAM clock jitter specifications are absolute values(because the memory supplier cannot test to an RMS limit.)
This means that at some point, just about every memory clock willviolate clock jitter specifications. Fortunately, in most cases theseviolations will be in the range of an SER event; that is, so small thatit is not an issue. A clock jitter violation does not mean that theDRAM will necessarily fail.
Certain facts, like the fact that clock jitter is unbounded and thatthe DRAMs' clock jitter specifications are absolute, are oftenoverlooked. It is not unusual for users to measure clock jitter for asmall period of time, determine the minimum and maximum clock pulses,and declare a clock jitter value. Yet, there is no mention of how manysamples were taken or, more importantly, what the standard deviationwas.
Until a statistically sound standard deviation value for the clockjitter is obtained, the results are incomplete and can be grosslymisleading. Furthermore, the system needs a pass/fail bit error rate(BER) target before a solid risk assessment can be made. For example,with a 3ns DDR2 SDRAM (DDR2-667) that has a t CKavg of 3.05nsand a clock period jitter (t JITper) of ±125ps (thespecification limit is 125ps), are there clock jitter specificationviolations?
If there are violations, is the system likely to see errors? Unlessthe ±125ps clock jitter was measured over infinity in time,sooner or later the clock jitter will violate the DRAM'sspecifications. More importantly, it is impossible to determine therisk level of the clock jitter without knowing what the clock jitterstandard deviation is and what the acceptable BER targets are.
Deterministic Clock Jitter
Deterministic clock jitter is predictable and reproducible (Figure 5 below ) and has specificcauses. DDR2/DDR3 performance, and hence yields, would be adverselyimpacted if deterministic clock jitter was allowed in thespecification.
When the industry-standard clock jitter specifications were beingdefined, various system data indicated that the clock jitter should berandom and fit a Gaussian distribution. Additionally, it was believedthat users should be able to remove deterministic clock jitter fromtheir systems; therefore, no form of deterministic clock jitter isallowed by specification.
|Figure5: Deterministic Clock Jitter|
While any form of deterministic clock jitter is considered aspecification violation, not all deterministic clock jitter willadversely affect DDR2/DDR3 performance. Once the DLL is locked, mostforms of positive deterministic clock jitter should not adverselyaffect the DRAM's ability to function correctly, provided the clockrate is not near the maximum clock period and cycle-to-cycle jitter (t JITcc) is not violated.
Conversely, if the DLL is locked, most forms of negativedeterministic clock jitter could adversely affect the DRAM's ability tofunction correctly. Even if the t CK(abs) MIN specificationlimit is not violated, the negative deterministic clock jitterdistribution could prevent the DRAM from functioning correctly.
DLL Locking vs. Locked
As previously mentioned, the two primary modes of DDR2/DDR3 operationare (1) when the DLL is locking and (2) when the DLL is locked, andeach has different clock jitter concerns and, of course, differentspecifications.
When analyzing clock jitter, it is important to investigate eachmode of operation separately. That is to say, cycle-to-cycle clockjitter should be measured twice: once during DLL locking time and onceduring memory accessing. Using the value for one condition or the otherwill provide a faulty analysis.
When the DRAM is powered up and initialized, the DLL must be set andlocked. This means the internal delay loop must be locked to theexternal clock rate. It should be evident how sensitive this operationis to clock jitter. How can a DLL lock to a moving target? If the clockdistribution was bimodal instead of Gaussian, what would the DLL lockto? How does it know where the nominal clock is? Gaussian-based clockjitter is a must for obtaining a good DLL lock.
Clock jitter specifications are tighter when the DLL is locking thanafter the DLL is locked. The tighter limits are necessary to ensure agood lock point. Fortunately, most systems have significantly lessclock jitter during initialization, when the DLL is locking, thanduring normal operation.
During initialization, power busing in the memory controller isfairly quiet. During intensive memory operations, however, power busingin the memory controller can get fairly noisy, which in turn can causethe clock generator to increase variation, resulting in increased clockjitter.
Although there are about 17 clock jitter specifications, themajority of them are either not applicable or they have a minimaleffect on the DLL's ability to get a good lock.
On a first order, as long as the cycle-to-cycle jitter is small (andmaintains a Gaussian distribution), the DLL should be able to get agood lock. If deterministic clock jitter is present during the DLLlocking period, it will be problematic because it is unlikely that theDLL will be able to find the nominal frequency.
After the DLL is locked, clock jitter takes on a new light. First ofall, the DLL becomes fairly immune to cycle-to-cycle clock jitterbecause the DLL filters out random clock jitter that is Gaussian sincethe internal loop delay remains constant. The variations in clock pulsewidths due to clock jitter will pass through to the outputs, so tospeak; however, the delay itself will not change due to cycle-to-cycleclock jitter.
It is interesting to note that during the DLL locking period, theDRAM is rather sensitive to cycle-to-cycle clock jitter; but after theDLL is locked, the DRAM is rather impervious to cycle-to-cycle clockjitter. Of course, this is assuming that the clock jitter has a goodGaussian distribution.
Clock jitter specifications that have minimal impact during the DLLlocking stage are critical to the DRAM's functionability after the DLLis locked. Clock period jitter, t JITper, and the duty cyclejitter, t JITdty, are the two clock jitter specificationsthat play key roles after the DLL has been locked, when the DRAM isbeing accessed.
The various t ERRnper jitter specifications play a lesserrole. In fact, if the clock jitter is close to a Standard Normaldistribution and the t JITper limits are not violated, thevarious tERRnper jitter specifications are all but guaranteed to besatisfied.
Next in Part 2: DDR2/DDR3Functionality
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.