

Specifying a PLL Part 3: Jitter Budgeting for SynthesisBy Julian Jenkins, Perceptia Devices 1 Introduction This white paper is aimed at system architects and physical implementation leaders working on the design of SoCs. It can be confusing to understand the impact of different jitter sources and how to calculate a jitter budget when specifying a digital system. This white paper explains how jitter changes the period of a clock and how to ensure that jitter has correctly been accounted for in the calculations for timing closure. 2 Review This article follows on from the article “Specifying a PLL Part 2: Jitter Basics” and expands on the requirements for digital timing closure. The following terms were defined in that article and are used again here:
3 Jitter and Timing Closure 3.1Timing Closure Figure 1: Typical Register to Register Logic Figure 1 shows a typical configuration for register to register logic. Signals originate at a set of registers, are combined by a cloud of logic and are captured by another (or the same) register. For system & physical implementation purposes, the clock cycle time defines the amount of work we can allocate to the circuits within that cycle. Controlling the logic depth and ensuring that the propagation delays fit within the defined clock period is the job of the physical implementation flow and is known as timing closure, which is defined by the ability of the destination registers to capture the correct result. This means that the correct result must have propagated to the input of the destination register ahead of the capture instant of that register. Figure 2 shows an example timing diagram for the circuit of Figure 1:
Figure 2: Example Timing For the circuit to work correctly the input data to the destination register must be valid before it is sampled: (1) Where is the time at which the destination register captures its input. The propagation time() is the time taken from the clock edge causing the source register to change () to the arrival time at the destination register (). (2) The capture time is earlier than the time the destination register is clocked by the setup time. (3) We must also account for the skew () between the time of these clocks. In addition it is good practice to add a small margin () to account for errors in the calculations and factors that are difficult to account for individually. Looking at Figure 2 we can see that the time available for a given operation can be determined from the clock period: (4) Putting this together we can see that the effective time available for the circuits to do their work is set by the effective clock period for timing closure (). The physical implementation flow must ensure that timing closure is met such that: (5) In order for the logic to be able to operate correctly, the sum of the propagation and setup times must be less than the clock period for timing closure. Fortunately, the tools for the physical implementation are able to track the propagation, setup and skew times associated with every path in the design. This means that we do not need to calculate this every time. These tools only need the correct information on the period, and margin to ensure timing closure for the whole design by modifying the circuits to control and . Hold times are not considered in this article as jitter is not a factor in their calculation. 3.2 Jitter As described in “Specifying a PLL Part 2: Jitter Basics”, it is critical to know the period jitter of a clock source in order to achieve timing closure as this can change the amount of time available to complete a unit of work. As we have shown above, the primary requirement for timing closure constraint development and analysis is to know the period of a clock source as this materially affects the amount of time available to complete a unit of work. In the article, “Specifying a PLL Part 2: Jitter Basics” we showed that the most important type of jitter to consider in this situation is period jitter as this directly reduces the effective period of the clock.
Figure 3 reproduces the figure from the jitter basics article showing that there will be some variance in the period of any clock in the real world. Variances that change the period of the current cycle, compared to the previous cycle (cycletocycle jitter) and the variance in timing between one cycle’s period and another cycle’s period many thousands of cycles later (long term jitter) is not relevant in digital clocking systems and is not considered in this article. Thus the following analysis will focus solely on period jitter calculations. The system and physical implementation timing budgets now need to account for the various timing uncertainties by ensuring that is always long enough to ensure timing closure as described above. For this to be true: (6) Where:
In the simplest terms, this means that must be shorter than the shortest clock period expected for a given amount of jitter. The following sections examine how to specify and budget for the clock jitter associated with a PLL clock source (though it may also be a useful aid for other types of clock sources). 3.3 Jitter for MultiCycle Paths In some designs, it is not possible to constrain a path so that less than than . In these circumstances, it is possible to add special circuitry to only sample the data when it is valid and timing closure can be achieved across multiple periods of the clock. This is called a multicycle path and the logic is constrained so that: (7) For a predetermined number (N) of clock cycles. When multicycle paths are used, the jitter across all each of the clock cycles that are used to make the calculation must be added to get the overall jitter across the total evaluation time. In many circumstances, there is a strong correlation between the jitter of nearby cycles, so the overall jitter can be near to worst case for several cycles in a row. For example, jitter from low frequency modulations, like that resulting from the ripples from a switched mode power supply output, will have almost the same effect for multiple cycles. As a result of this, the only safe way to account for jitter over multicycle paths, is to assume the jitter is the same on all cycles use in the multipath and: (8) So the jitter (in seconds) will be increased by multiplying it by the number of cycles used in the multi cycle path. This will be the same percentage of the multicycle path as it was of the simple single clock cycle path. 4 Calculating Jitter Requirements Figure 4: Clock Budgeting To calculate your jitter requirements, follow these steps:
NOTE: clock tree jitter is primarily due to power supply variation at the local clock tree buffers. Since CMOS logic delays are directly proportional to the supply, variance or noise on the power supply to the clock tree gates will cause variance in the root to leaf delay of the clock tree. This is generally accounted for within the physical implementation tools and lumped into the leaftoleaf skew margin number generated internally by the clock tree synthesis tools. Examples are given in Section 7. 5 Datasheet Jitter Parameters A typical datasheet will give you a number of parameters from which the total jitter can be calculated. The exact parameters will depend on the particular supplier. Perceptia specifies the following parameters which can be used to calculate the jitter:
These are parameters that the designer of the designer of a digital system has control over. The designer may tune by choosing a different switched mode power supply or adjusting the amount of logic sharing a supply with the PLL. The designer also has the ability to tune by changing the clock skew between the inputs to different PLLs that share a single reference clock. The examples below demonstrate how changing these parameters can have a significant impact on the jitter of a system. 6 Improving Jitter There are a number of ways to improve the jitter if a given setup does not meet you requirements:
See the examples below for an indication of the effects of these strategies. 7 Jitter Calculation Examples The table below shows four example calculations of the jitter:
8 Conclusion Clock jitter is a key parameter for digital designs and all designers should have an understanding of its effect on timing closure and the measures available to them in order to control it. In the overall jitter of any system can be set by the correct choice of PLL and the correct setup of that PLL. This article has attempted to give designers a better insight into how to best achieve this. 9 About the Author Julian Jenkins, is the CEO and CTO of Perceptia Devices. As CTO, he is the architect of all of Perceptia’s PLL IP where he been among the pioneers in the development of all digital PLLs. Julian has several US and international patents as a result of this work. He has participated in an impressive list of highspeed analog and mixedsignal ICs that are in commercial production. Feel free to contact Julian if you have questions about this topic. Perceptia Devices is an IP and design services provider, based in Sydney, Australia and Silicon Valley. It is focused on PLLs for RF systems and other demanding clocking applications. If you wish to download a copy of this white paper, click here

Home  Feedback  Register  Site Map 
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. 