Pinning down the acceptable level of jitter for your embedded design -

Pinning down the acceptable level of jitter for your embedded design


There are several clock jitter types, measurement methodologies, and corresponding specifications. But most hardware designers don’t have the time to research these, and the detailed nuances of clock jitter specifications can seem like trivial minutia to the board designer.

The designer is often more focused on the larger design task(s) at hand. Taking precedence are design tasks specific to FPGA logic, microprocessor complex, data plane switch fabric, control plane switch fabric, RF signal chain, power, interconnectivity issues, design simulation, modeling, etc.

So, the designer must assume that the reference clock jitter specifications from the various chip vendors are relevant for their intended use of these devices, and that they are also specified completely and correctly.

But without some basic guidelines to follow, the designer could over-specify the clock jitter requirements and add undue bill of material (BOM) cost to the design with more expensive clocks devices. Or, even worse, the clock jitter requirements could be under-specified and corresponding errors will increase beyond an acceptable error rate for the given application. This may not be determined until after performance metric testing of initial prototype boards very late in the development cycle, potentially impacting end product release schedules.

Most fundamental checkpoint
The first and most fundamental checkpoint for the designer to consider is the most relevant clock jitter type for the given application. Table 1 summarizes some jitter classifications by application type, and the corresponding specification qualifiers.

Table 1: Application relevance of jitter

Period jitter is the most intuitively understood jitter. It’s simply the deviation from the ideal (or mean) period, and it’s the relevant jitter type for synchronous interface and logic design. Some examples include a microprocessor (mP) interface with a synchronous memory or a synchronous state machine design inside an FPGA.

As the clock period shrinks or expands, it can have a dramatic impact on either setup or hold time for a synchronous design. That’s why period jitter is relevant for these types of applications.

High frequency jitter, and cycle-to-cycle (C2C) jitter in particular, is the relevant jitter type for spread-spectrum clocks. A spread spectrum clock has intentionally induced low-frequency jitter to alleviate EMI (electromagnetic interference) that traditionally is a concern in consumer electronics. But since spread spectrum is low-frequency jitter, it doesn’t impact a C2C jitter measurement. For this reason, C2C jitter specifications can be used to quantify the jitter performance of a spread spectrum clock.

A close look at frequency domain jitter
It’s important to pay special attention to frequency domain jitter and its applicability to high-speed serial communications. Specifically, the reference clock jitter requirement for high speed SerDes (serializer/deserializer) design is detailed. This is the least understood jitter type, and as a result the one most prone to some of the common board design pitfalls.

A phase noise (PN) plot, shown in Figure 1 , is typically generated by a spectrum analyzer that captures the spectral content of a clock signal – useful for seeing the frequency characteristics of clock jitter. It is also useful for describing the randomness of phase fluctuations, which implies random frequency fluctuations, and which in turn implies random period fluctuations.

Click on image to enlarge.

Figure 1: Phase Noise (PN) Plot is commonly used to represent the clock jitter in the Frequency Domain .

Therefore, a PN plot is a representation of random clock period jitter, but in the frequency domain. Mathematically, it is the power magnitude of the noise (i.e. jitter) of the clock signal relative to that of the clock’s fundamental frequency F0 at certain frequency offsets FC from the fundamental.

The power magnitude of the jitter at a particular frequency offset is a function of how often that jitter value occurs. So, a PN plot is an indication of how often a particular random frequency deviation occurs. The ratio of the jitter’s power to that of the carrier is expressed as dBc/Hz. And, the lower (i.e. more negative) the dBc/Hz the better, meaning less jitter power.

Root mean square (RMS) phase jitter is a quantification of jitter that is extrapolated from the PN plot. This is not to be confused with RMS period jitter, which is a time domain jitter specification. The conversion to an RMS phase jitter value is largely an integral function, which means its value depends on the area under the PN plot.

But this area needs to be bounded by an integration range, or what is commonly known as the ‘mask’. The mask is specific to the particular application’s transfer function, and its intent is to restrict, or mask, the quantification of the jitter to a range of frequencies that the application’s transfer function does not filter. That means that any RMS phase jitter requirement must be qualified with the integration range of interest.

A PN plot, and the corresponding RMS phase jitter quantification, is the relevant clock jitter type for serializer-deserializer (SerDes) applications. Industry serial standards like Synchronous Digital Hierarchy (SDH), Synchronous Optical Network (SONET), Ethernet, PCI Express (PCIe), Serial RapidIO (SRIO), and SMPTE (Society of Motion Picture and Television Engineers) all make use of this clock jitter type for specifying the necessary reference clock jitter.

For reference, a representative SerDes communication channel is shown in Figure 2 . PLLs are inherently low pass filters of the input clock jitter. As such, the Tx SerDes clock multiplying unit (CMU) PLL acts as a low pass filter of the reference clock jitter.

Click on image to enlarge.

Figure 2: Representation of a high-speed serial communication channel

The high frequency jitter on this clock is not transferred to the output of that PLL, hence is not a contributing factor to the SerDes output jitter. This low pass filter characteristic of the Tx CMU PLL is what defines the upper corner frequency of the integration band of interest.

In similar fashion, the reference clock used for the Rx SerDes is multiplied by the internal Rx SerDes CMU PLL. This clock is then used for the phase interpolator based clock and data recovery (CDR) circuit, which acts as high pass filter of the reference clock jitter.

As such, the low frequency jitter on this clock is not transferred to the output of the phase aligner used for the CDR function. This high pass filter characteristic of the Rx phase interpolator is what defines the lower corner frequency of the integration band of interest.

Together these effects bound the SerDes transfer function for the given Serial Standard, and what effectively defines the integration band of interest, or mask, for example 1.875MHz to 20 MHz for 10G Ethernet.

Chipmaker specs don’t jibe
Aside from the many different jitter types and nuances, there is a lot of ambiguity with how chipmakers specify the required clock jitter for their devices. SerDes chip manufacturers specify the required reference clock jitter for their components. But device specifications for PHYs, FPGAs, and processors do not necessarily correlate to the methodologies and measurement particulars of the industry serial interface standards.

As an example, most network communication standards (i.e., GigE, 10GE, etc.) specify peak-to-peak (P2P) total jitter as a percentage of one unit interval (UI), where one UI is equivalent to a one-bit interval in time for the given serial standard. But P2P total jitter UI is actually a SerDes eye closure specification for compliance with the acceptable bit error rate (BER), which is often 10-12 depending on the industry serial standard.

The standards do not delineate the percentage of this total jitter UI budget that gets allocated to the interconnect, optics, SerDes, or the reference clock driving the SerDes. As a result, the board designer is left at the mercy of the SerDes chip vendor and the reference clock jitter specified in their data sheets. Often, these specifications are overly conservative, giving most of the jitter budget to the integrated SerDes and leaving only crumbs to the reference clock needed to drive the SerDes.

Exacerbating the problem, jitter specifications from clock chip vendors may be vague and incomplete. Clock specmanship from some vendors is often not appropriate for the targeted application, inconsistent, and missing key qualifiers for the given specifications.

Common jitter pitfalls
There are a number of pitfalls towhich board designers all too often fall victim. This section expands inmore detail on some of the common pitfalls listed below:

  • P2P random jitter specification without BER qualifier for the target application
  • Using communications-centric clock jitter specifications and methodology to PCIe ports
  • PN plot generation done with spurs turned off for a total phase jitter requirement – ignoring deterministic jitter by using a random RMS phase jitter measurement
  • Jitter measured/specified for a clock device, but not for the configuration specific to the use case of the given application (i.e. w/internal MultiSynth dividers in integer mode)
  • Additive RMS phase jitter measured as simple difference between input and output jitter, rather than the square-root of the difference of the squares of the input and output jitter

For instance, Figure 3 shows that the skirts of the Gaussian distribution of random periodjitter extend forever. This is because random jitter is unbounded. Thus,absolute maximum P2P period jitter isn’t a practical measurement.However, a probability can be assigned to a jitter exceeding a point on aGaussian distribution. BER is application specific and is typicallyused for this purpose.

Click on image to enlarge.

Figure 3: Skirts of Gaussian distribution of random period jitter that go on forever

Withoutthe acceptable BER from the chip vendor, a P2P period jitter spec isuseless. Yet this qualifier is often missing from device datasheets. With a known acceptable BER for a given application, thenecessary RMS period jitter for the given application can then becalculated. So it is important that the designer knows the correct BERfor their application. Also, note that this methodology is not specificto period jitter, as it can be used to calculate various types of RMSjitter. As an example, an RMS phase jitter calculation is shown here:

   Given 10GE PHY required random phase jitter UI = 0.18 UI
      … one UI = 96.9pS since bit rate is 10.3125Gbps
      … assumed acceptable BER is 10-12 for the given application
   Then, the corresponding RMS phase jitter required is calculated as:
      [(0.18)*(96.9pS)]÷(14.069) = 1.24pS

PCIehas become a common control plane interface for communicationsapplications. Devices like Ethernet PHYs integrate PCIe ports forinterface to an out-of-band control plane micro. At least one notableEthernet PHY vendor is known to specify the RMS phase jitter for theirPCIe reference clock in a similar manner to how they specify it for theEthernet ports in the same device, effectively extrapolating from aphase noise plot generated by a spectrum analyzer. But this is notcompliant to the PCIe standard jitter methodology, as detailed in Figure 4 .

Click on image to enlarge.
Figure 4: Seven steps taken to measure the reference clock jitter per the PCIe Standard.
Instead,the PCIe methodology uses raw period samples measured with anoscilloscope and then applies an FFT, Filter, and iFFT steps to arriveat the appropriate RMS phase jitter measurement. It is important to notethat these two different methodologies can yield wildly differentresults.

As a result, the designer could be led to mistakenlybelieve that clock devices designed to meet/exceed the PCIe referenceclock jitter specifications, per the standard, are not adequate fordriving the PCIe ports because the PHY vendor is specifying thenecessary reference clock jitter using a different methodology and/orfilter.

As previously discussed, P2P total jitter (UI) isspecific to the SerDes data signal. This includes both deterministic andrandom jitter contributions to the data signal eye diagram. It iscommonly accepted that the deterministic jitter on a SerDes link islargely a function of the link and other system impairments.

Therandom jitter is mostly attributable to the SerDes external referenceclock and the PLLs inside the SerDes themselves. But, we know that thereference clock will have some amount of deterministic jitter aswell. Additionally, many PHY vendor datasheets do not break out random(vs.) deterministic jitter requirements for the reference clock drivingtheir SerDes. For these reasons, another common pitfall is the use of aPN plot to quantify the total phase jitter of a clock device, includingthe deterministic jitter, but with the spurs turned off. (‘spur’ isshorthand for ‘periodic spurious noise’, and is a representation of thedeterministic jitter of the clock.) This deterministic jitter canoriginate from the PCB design itself and/or the clock chips. Crosstalk,electro-magnetic interference (EMI), switching power supply noise, andPLL fractional feedback dividers can all be sources of thisdeterministic jitter.

For the example PN Plot shown in Figure 5 ,this particular board design has significant spurious content measuredat the PLL output. Unfortunately, the spurs are within the integrationrange of interest for this application, namely 12KHz to 20MHz. As aresult, the reference clock’s total phase jitter is outside the SerDeschip vendor’s specification and a high BER was a result. Root causeanalysis, making use of an EMI sniffer, allowed this spurious content tobe traced to the synchronous buck-switching regulator used to power thePLL. Layout modifications and passive component changes wereimplemented to alleviate the problem.

Click on image to enlarge.
Figure 5: Example PN plot with spurs
However,some of the spurious content comes from the PLL clock device itself.It’s important to keep in mind that any clock synthesizer device cancreate an array of unwanted sum and difference frequencies. These may beenough in power magnitude to show up as significant spurs on a PN plot.

Today’s elegant PLL designs employ advanced silicon designtechniques. These advances help to minimize intrinsically generatedrandom and deterministic (spurious) jitter. But for jitter-criticalboard clocks, it’s incumbent on the designer to verify with timingdevice vendors that corresponding phase jitter specifications for agiven clock device are based on PN plots with spurs turned-on.

A flow chart to get you on the right track
The flow chart in Figure 6 is intended to guide the board designer to the right jitterspecification for his application, and thus the selection of the rightclock chip(s).

Click on image to enlarge.
Figure 6: A flow chart helps to specify the right jitter for your application
First,determine the application type. Is it a synchronous interface orsynchronous logic design, a microprocessor reference clock specificationor spread spectrum clock, a high-speed serial communication or SerDesdesign? In many board designs, often all of these application types needto be addressed, and all have different jitter requirements.

Fora synchronous interface or synchronous logic design, you should bedealing with period jitter. Are you working from a P2P period jitterspecification? If so, then you need to be certain of two key qualifiers:First, the P2P period jitter you’re using from the chip is based on a10K sample size, per JEDEC (Joint Electronic Device EngineeringCouncil). Second, the chip vendor provides you the assumed BER for theirspecification. With those two qualifiers, you can arrive at acorresponding RMS period jitter specification for selecting anappropriate clock device.

If it’s a consumer electronicsapplication implementing spread spectrum, then you probably should beusing a C2C jitter specification. The assumption is that C2C jitter ismeasured across 1,000 consecutive cycles per the JEDEC Standard. Youneed to confirm, and if that is the case, then you have a valid C2Cjitter specification to qualify the corresponding clock chips.

Ifit’s a high-speed serial communication design, then you should firstask if the serial standard makes use of the traditional spread spectrumanalyzer methodology for quantifying phase noise. Also, it is importantto note exactly what the PHY vendors provide for a specification. Is itP2P total jitter UI, or P2P random jitter UI?

Keep in mind thatRMS is only specific to random jitter, where one needs to divide therandom jitter requirement by the BER multiplier to knock that down tothe corresponding RMS random jitter UI. For random jitter, you can use aPN plot with spurs turned off and then integrate to arrive at an RMSphase jitter value. But, when we take a PN plot with spurs turned on tocapture the deterministic jitter and then integrate per the mask, thenthe corresponding value is no longer RMS and is instead total phasejitter.

The intent of this flow chart is to walk you through asystematic approach for specifying the right jitter for yourapplication. It is designed to eliminate common board design pitfallsdetailed in this article.

A useful clock device specification isone that delineates the different output structures and correspondingjitter capabilities of each. It also provides the specifications for thedifferent jitter types outlined in this article so that the designercan qualify for their given application. As an example, consider theUniversal Frequency Translator (UFT) shown in Figure 7 .

Click on image to enlarge.
Figure 7: IDT 8T49N28X universal frequency translator
Thisconfigurable clock device has several advanced features ideally suitedfor communications line-card applications. It provides an impressive mixof high performance (e.g., low phase noise) and flexibility in onedevice. To provide this flexibility, the device employs a mix of bothinteger- and fractional-based output dividers, with corresponding RMSphase jitter differences noted for each output type, as shown in this device spec. Also, this device datasheet breaks out PCIe phase jitter performance, per the previously noted PCISIG methodology, in a separate table, thereby recognizing the difference in methodology for that serial interface standard. 

It’simportant to recognize that not all use case permutations could ever becaptured in a configurable clock datasheet. As a result, the designer isencouraged to request the corresponding jitter performance for theirgiven use case, because results can vary slightly.

Dean Smith is a Senior Field Applications Engineer at Integrated Device Technology(IDT). Dean received his BSEE from Rochester Institute ofTechnology. He can be reached at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.