Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Interface

How to improve FPGA comms interface clock jitters

Posted: 16 Oct 2014 ?? ?Print Version ?Bookmark and Share

Keywords:FPGA? phase-locked loop? PLL? SerDes? IP?

Over a few short years, considerable progress has been made with regard to FPGA technology. These devices have become extremely complex. FPGA blocks continue to maintain the phase-locked loop (PLL) technology capable of generating clocks for applications clocking synchronous logic, memory, board peripheral, complex PLD, or a microprocessor (mP), and other uses typically demanding time domain jitter specs like cycle-to-cycle and period jitter.

However, it's a different story with high-speed interfaces such as communications for serial-deserialiser (SerDes), Gigabit Ethernet (GbE), 10 GbE, synchronous optical network/synchronous digital hierarchy (SONET/SDH), and Fibre Channel that have tight frequency domain jitter requirements.

To run properly, these high-speed interfaces rely on the low-frequency jitter component to be within spec. Existing PLLs in even the most advanced FPGAs don't have the quality to meet the jitter requirements for the most common transmitter SerDes eye specification.

Reasons for this shortcoming vary. Digital technology embedded in high-speed FPGAs doesn't provide the necessary performance for building a low noise PLL.

Considering that device geometries are approaching 20nm (nms) with extremely small but highly advanced transistors, a key factor is the quality of a PLL's inductor or what's known as the 'Q factor'. An ideal inductor would have no resistance or energy losses. The quality factor (Q) of an inductor is a measure of its efficiency. The higher the Q factor of the inductor, the closer it approaches the behaviour of an ideal lossless inductor.

From a PLL design perspective, it's essential to achieve good phase noise (PN) to meet demanding PN requirements of the transmitter SerDes for high-speed protocols. Achieving a high Q factor in a PLL design usually means some changes in metal layers, either a thicker metal or using another type of metal, for example, copper.

Figure 1: Common application protocol total, random, and deterministic jitter breakout.

It's a different process than what most typical FPGA IP blocks need, especially in the lower geometries. Plus, it's a more expensive process. Therefore, to design an ideal PLL, special processes are required, for example, some thicker metals to improve the quality of that inductor. At these extremely low geometries, most intellectual property (IP) blocks within the FPGA don't require this extra process. In the end, increasing the PLL's quality factor in an FPGA becomes more expensive, thus making an FPGA's overall process more expensive.

Further, transistor leakage becomes an issue with smaller geometries. It's difficult enough dealing with PLL analogue circuits. But when different metals and transistor leakage are factored in, the combination isn't ideal for an effective PLL design for an FPGA.

On the other hand, if FPGA vendors decided to overcome these issues and spend more dollars on the extra process, PLLs demanding low noise are still subjected to noisy environments within the FPGA that adversely affect performance. Moreover, internal PLL outputs have to be routed out to reach various SerDes blocks around the outside footprint, which is more difficult. As more and more IP finds its way into these large FPGAs, the routing becomes a major concern. In short, these represent the issues when providing low noise PLLs as IP blocks within an FPGA.

Getting around low noise issues
The answer to these clocking issues is to take low noise PLLs externally. Figure 1 shows common application protocol CHECK AGAINST FIGURE total, random, and deterministic jitter breakout for Gigabit Ethernet, 10 Gigabit Ethernet, Serial RapidIO (SRIO), and Fibre Channel protocols. These are just a small sampling of the more common high speed interfaces.

1???2???3???4?Next Page?Last Page

Article Comments - How to improve FPGA comms interface ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top