JESD204B is a 12.5 Gbps serial interface standard for high speed, high resolution data converters. Already, devices from converter manufacturers are beginning to make their way into the market, and it is expected that the number of JESD204B-enabled products will increase tremendously in the near future. The primary value of the JESD204B interface is a reliable increase in the data transfer bandwidth between a converter and a logic device (such as an FPGA or ASIC).
As with any new interface, JESD204B brings new challenges. For system developers, the challenges are how to best implement JESD204B from a PCB design standpoint and how to debug a system if something isn’t initially working right. For component manufacturers, challenges involve testing new JESD204B devices. Testing not only ensures that specifications are being met in a relatively ideal environment, but it also ensures successful JESD204B operation in end system environments.
This article discusses the JESD204B specification, reviews the tests needed to validate JESD204B devices, and outline methods used to replicate end system environments.
JESD204B—A Natural Evolution for Data Converters
Data converters (digital-to-analog and analog-to-digital) are used in many applications ranging from audio and music to test instrumentation. The world of data converters is evolving. As the bit depth and sample rate go up, getting data in and out becomes increasingly difficult. A decade or two ago, with sample rates for high speed converters limited to 100 MSPS and below, using TTL or CMOS parallel data busses was sufficient. For example, a 12-bit converter with 12 pins dedicated to the data could be implemented with reasonable setup and hold times with respect to the clock.
As speeds increased above 100 MSPS, setup and hold times for single-ended signals could no longer be maintained. To boost speeds, high speed converters moved to differential signaling but at the cost of increased pin counts. For example, a 12-bit converter now would need 24 pins dedicated to data. To address the pin count issue, serial data interfaces were adopted. A converter data interface with 6× serialization now allows that same 12-bit converter to transfer the data with just two differential I/Os (only four pins). Fast forwarding to today, data converters are now being developed using the JESD204B specification for the data interface.
The JEDEC standards organization has published two versions of the JESD204 high speed serial digital interface specification. The first version, the JESD204 2006 specification, brought the advantages of SerDes-based high speed serial interfaces to data converters with a 3.125 Gbps maximum speed rating. It was revised in 2008 (JESD204A 2008 specification) and added important enhancements including support for multiple data lanes and lane synchronization. The second version of the specification, JESD204B, was developed by an international JEDEC JC-16 task group (Project 150.01) comprised of about 65 members from 25 companies. It provided a number of major enhancements including a higher maximum lane rate, support for deterministic latency through the interface, and support for harmonic frame clocking.
Lack of an Official Compliance Test Specification
Unlike many other high speed serial interface standards, the JESD204B standard does not include an official compliance test specification. A test specification is doubly valuable because it lists the tests which must be performed to ensure compatibility, as well as the procedures for doing those tests. Having consistent procedures used by different manufacturers help ensure a common understanding of the specification and eliminate differences in assumptions. The lack of an official compliance test specification does not mean that all is lost. All of the information needed to develop a set of tests and procedures can be found in the JESD204B specification and the specifications it refers to. It is left up to the individual chip manufacturers and system developers to pull together that information.
Physical Layer Testing
Physical layer, or PHY, tests are related to the individual data lane driver and receiver circuitry: in other words, the analog tests of a link. They do not include digital functionality or procedural tests. Working toward the goal of developing a thorough list of PHY tests, a list of recommendations, SerDes PHY tests can be obtained from the OIF-CEI-02.0 specification, section 1.7. The JESD204B specification closely follows those recommendations, but does include a few modifications. For example, JESD204B does not specify random jitter as a standalone test item, but chooses to include it under total jitter. Also, JESD204B specifies JSPAT, JTSPAT, and modified RPAT as recommended test patterns, whereas the OIF-CEI-02.0 specifies using the PRBS31 pattern.
Above and beyond the required PHY tests, there are additional PHY tests that could be performed which are not listed in the OIF-CEI-02.0 specification or in the PHY section of the JESD204B specification. One can look to other SerDes compliance test specifications for examples and find tests such as intrapair skew (for a transmitter) and intrapair skew tolerance (for a receiver). In bringing these up, it is not the intention to recommend that these tests be added to the JESD204B specification. Additional PHY tests are not required to ensure JESD204B compatibility. The intention is to note that if a particular PHY test is failing, other PHY tests can be used to help gain insight as to why.
Once the list of tests is set, limits for those tests can be obtained from the JESD204B specification. Just keep in mind that there are three sets of limits: LV-OIF-11G-SR, LV-OIF-6G-SR, and LV-OIF-SxI5. A particular JESD204B device may support more than one set of limits. In that case, the component should be tested against all of the sets of limits that are supported.
One point of potential confusion with JESD204B PHY testing is jitter terminology. The JESD204B and OIF-CEI-02.0 specifications use different terminology from what the test equipment vendors use. The typical jitter map is shown in Figure 1. Test equipment makers base their terminology on the industry standard dual-Dirac jitter model. This difference in terminology is a point of potential problems in test procedures, as jitter is quite a tricky topic. Table 1 shows our translation of the jitter terminology (the JESD204B specification uses different terminology for jitter from that used by test equipment vendors).
|JESD204B Jitter Term||JESD204B Jitter Name||Test Equipment Jitter and Translation|
|T_UBHPJ||Transmit uncorrelated bounded high probability jitter||BUJ (PJ and NPJ)|
|T_DCD||Transmit duty cycle distortion||DCD|
|T_TJ||Transmit total jitter||TJ|
|R_SJ-HF||Receive sinusoidal jitter, high frequency||PJ > 1/1667 × BR|
|R_SJ-MAX||Receive sinusoidal jitter, maximum||PJ < 1/166,700 × BR|
|Receive bounded high probability jitter—correlated||DDJ|
|R_BHPJ||Receive bounded high probability jitter—uncorrelated||NPJ|
|R_TJ||Receive total jitter||TJ|
Another point of potential confusion with JESD204B PHY testing is the eye mask for data rates above 11.1 Gbps. The JESD204B specification says that for data rates greater than 11.1 Gbps to use a normalized bit time of 11.1 Gbps. So, if running at 12.5 Gbps (with an 80 ps bit period), it says to use the bit period for 11.1 Gbps (90.9 ps). The issue at hand here is that eye masks can be built by starting either at the edge of the UI or from the center of the UI, and the JESD204B does not clearly state which reference point to start from. If the reference point is the center of the UI, then the eye mask is bigger than normal at 12.5 Gbps, making it harder for a transmitter to pass but easier for a receiver to work. If the reference point is the edge of the UI, then the eye mask is smaller than normal at 12.5 Gbps, making it easier for a transmitter to pass but hard for a receiver to work. Ultimately, until this question is resolved, it is recommended to test against each of the two mask options in order to ensure compatibility.
Coming up with a thorough list of timing tests for JESD204B is not an easy task. There are at least dozen timing diagrams throughout the specification, and it’s not immediately apparent which apply to the transmitter, the channel, or the receiver. Also, some are only applicable to a particular subclass (0, 1, or 2). An official compliance test specification would be especially helpful here if it were to simply consolidate the timing specifications into a single table. Once time is taken to methodically go through the timing specifications, there is no confusion about them.
One nice thing about timing for system developers is that specifying timing for a JESD204B component turns out to be easier than is immediately apparent from the specification. For Subclass 0 and 2, only device clock-to-SYNC~ timing must be specified. For Subclass 1, only device clock-to-SYSREF timing must be specified.
As with the PHY tests, there is no official list of JESD204B protocol tests. Therefore, it is left to each user to scour through the specification and compile a list of functions to test. This section lists many of the suggested protocol tests and briefly describes them.
One category of protocol tests are the test sequences. For PHY testing, JESD204B transmitters must be able to output JSPAT and modified RPAT patterns. From a protocol standpoint, there’s a need to validate that those patterns are correct. The same is true with JESD204B receivers and the JTSPAT pattern. Optionally, if they support PRBS patterns, those need to be validated as well. Next are the short and long transport layer patterns. These are included to help system developers debug their systems by proving that the link is working correctly through the transport layer. From a component manufacturer standpoint, those transport layer patterns have to be validated for every mode of operation that the device supports, which, considering the number of link configuration variables, ends up being a lot of cases.
One question that comes up regarding protocol testing is how to do it at 12.5 Gbps. One recommended solution is to use a high speed oscilloscope with a serial data decoder. Many higher end oscilloscopes are now equipped with a dedicated trigger chip for triggering on 8B/10B data such as that used in JESD204B. Figure 3 shows serial decode of a JESD204B data lane at 6 Gbps at the beginning of the initial lane alignment sequence (ILAS).
Another group of protocol tests can be built around the ILAS. The ILAS as a whole is fairly complex, so breaking it down into its individual components can make protocol testing more meaningful. The following are some examples of tests that can be measured on a transmitter to validate its operation. Is the multiframe length correct? Does each multiframe start with an /R/ control code and end with an /A/ control code? Is the /Q/ control code in the right location? Is the link configuration data correct and in the right location? The ILAS contains data; is that correct? How many multiframes does the ILAS last? Is the ILAS the same on all lanes? Clearly, there is a lot of potential for protocol testing around the ILAS sequence.
JESD204B does not have a lot of handshaking, but what it does have can be tested. Depending on the subclass, a number of tests can be performed. Since the SYNC~ signal can be used for initial handshaking, error reporting, and link reinitialization, do the transceiver and receiver components do their part accordingly? Does the receiver assert SYNC~ starting at the right time and for the right duration? Does the transceiver react correctly based on the duration of SYNC~ assertion? Since the data sent over the link also plays a part in the handshaking (that is, the ILAS), is it correct for its content and with respect to SYNC~ timing?
Next, there are a number of smaller digital functions that need to be tested as part of protocol, including scrambling, 8B/10B encoding/decoding, skew and skew tolerance, control bits, tail bits, SYNC~ signal combining, frame alignment monitoring, and correction. All of these functions need to be validated.
Lastly, there is the category of protocol tests called error handling. The specification includes a minimum set of errors that must be detected and reported: disparity errors, not-in-table errors, unexpected control character errors, and code group synchronization errors. But there are many more potential errors that could be detected and reported. For each and every type that is detectable by a JESD204B component, there should be a protocol test. These types of protocol tests can be a bit of a challenge to test and validate because a properly working link will never exercise them. They generally will require specialized test equipment. A BERT pattern generator can be used for many tests by creating a pattern that includes an error. Error cases can also be generated using an FPGA with code modified to specifically generate those errors.
Emphasis and Equalization Testing
The JESD204B specification talks very little about emphasis and equalization. There are a few comments like “pre-emphasis might be required” and “equalization might need to be implemented” from which one can determine that the specification allows them but does not give any additional guidance. When using a converter with JESD204B that includes emphasis or equalization, how does one go about determining whether or not to turn it on, and, if so, how much to turn it on? To answer that question, it is first best to understand the type of jitter called intersymbol interference (ISI). ISI is the name for the variation in edge timing that is caused by the filtering effects of a transmission line. Mathematically, it can be simply modeled as a low-pass filter. When sending high speed serial data down a transmission line, the filtering results in a distorted signal. Emphasis and equalization counteract the filtering effects of ISI with the goal of bringing the frequency response at the end of the channel back to as close to flat over frequency as possible, thus resulting in a signal that is not distorted by ISI.
With a basic understanding of emphasis and equalization and ISI, the next step is setting them. What many people ask first is how long of a trace can be driven with and without emphasis/equalization. Real-world PCB designs have too many variables that can affect ISI to be able to specify the channel in terms of trace length. Variables like trace width, trace length, vias vs. no vias, dielectric material, connectors vs. no connectors, trace material, corners, passive components, and distance to ground plane can all affect channel performance. So, how can channel characteristics ever be correlated to emphasis/equalization? The solution is to specify the channel in terms of insertion loss. Insertion loss is described in the JESD204B specification as a measure of the power loss of a signal over frequency. Emphasis, equalization, and PCB channel can all be related in terms of insertion loss (and gain). Using a relevant frequency (the JESD204B specification lists a three-quarter baud rate) and an insertion loss limit (JESD204B lists −6 dB), the gain provided by emphasis and/or equalization can be selected to bring the frequency response at the selected frequency up above the loss limit. For example, a PCB channel with −12 dB of loss at +9 GHz would need +6 dB of emphasis/equalization gain to bring the total back up to −6 dB.
Alternatively, converter manufacturers can provide a table of emphasis/equalization settings vs. PCB insertion loss. This method can result in a better solution, as it does not depend on as many assumptions. To build such a table for a transmitter (and to emulate end system designs), a set of test evaluation boards can be built with varying trace lengths.
The eye diagram at the end of the PCB trace can be directly measured and compared against the JESD204B receiver mask. By trying various PCB trace lengths, there will be one that results in the eye just barely passing the receiver mask. Since the insertion loss of that specific trace can be measured, the drive capability for a specific emphasis setting is known. Compare Figure 3, which shows an eye diagram at the end of an ISI PCB, to Figure 4, which shows the eye diagram going into an ISI PCB In this case, the data rate is 5 Gbps, the ISI PCB has 8 dB of insertion loss at 4 GHz, and emphasis is off.
Repeating this process vs. emphasis settings will result in a table of emphasis settings vs. insertion loss. A similar approach can be done on a receiver with equalization. Start with a BERT generator that is outputting the maximum allowed total jitter (except for ISI jitter). Using the same set of ISI test boards with varying trace lengths, test with longer and longer traces until the receiver starts to get errors that exceed the target bit error rate (1 × 10–15). Measure the insertion loss of the PCB trace. Repeat for every equalizer setting. In summary, if a JESD204B device manufacturer provides only emphasis/equalization gain, the first method can be used to pick settings. The best method is if the manufacturer provides a table of settings vs. channel insertion loss.
Should emphasis or equalization be used? From a frequency response correction standpoint, there’s no clear reason to use one instead of the other. However, in most cases, emphasis can generate a certain amount of gain with less power. If system power is important, that could be a reason to choose emphasis over equalization. Another advantage of choosing emphasis over equalization is that the effect on the signal can be directly measured with an oscilloscope.
It can be common to have both a JESD204B transmitter with emphasis and a receiver with equalization. How would you determine when to turn on both? Simply, if the insertion loss of the channel cannot be overcome by just emphasis or just equalization, then it’s time to turn on both. As for how much gain to set each of them to, one advantage of specifying response in terms of insertion loss (and gain) is that it’s additive. For example, at the frequency of interest: a PCB trace with −20 dB of loss, a transmitter with +6 dB of emphasis, and an receiver with +8 dB of equalization can be represented as −20 dB + 6 dB + 8 dB = −6 dB total.
Emulating System Environments—Noise and Jitter
No end system design is free of noise and jitter. Emulating system jitter is fully specified in the JESD204B specification, but voltage noise is not. To emulate voltage noise in end system designs, component manufacturers can perform noise tolerance tests. One such test is power supply noise tolerance. For this test, noise is injected onto the components’ various power supply domains. The amplitude of the noise is increased until the first compliance test fails (often the first test to fail on a SerDes will be jitter). This test is repeated over the frequency range at which PCB noise is typically present (a few Hz to around 100 MHz). A plot of maximum power supply noise tolerated vs. frequency is generated. The same test can be performed on all other pins. The end result of all this testing is typically a set of practical PCB design recommendations, such as “keep a particular supply domain separated,” “use a bypass capacitor on this pin,” or “don’t route any signals near this pin.”
Maintain Signal Integrity when Measuring
As with any high speed serial test application, a number of best practices apply to ensure accurate measurement results, and you must be sure that your instrumentation offers sufficient performance and signal integrity to deliver accurate measurement results. The following are a few considerations:
Dynamic range: in general, it is best to use the full range of your oscilloscope’s analog-to-digital dynamic range without clipping the amplifier. Although clipping might be acceptable when looking at a clock signal, doing this will hide ISI issues when evaluating data signals and can also affect the instrument’s edge interpolation algorithm.
Sample rate: setting the oscilloscope to the highest sample rate provides the best timing resolution for the most accurate signal and jitter measurement. One exception would be if you are looking over longer time windows at lower timing accuracy.
Capture window: analyzing signals over a longer time window allows you to see low frequency modulation effects like power supply coupling and spread-spectrum clocking. Increasing the capture window unfortunately increases the analysis processing time. On SerDes systems, there is often no need to look at modulation effects below the loop bandwidth of the CDR that are tracked and rejected.
Test point access and de-embedding: ensure that you employ a mechanism for keeping the probe as close to the transmitter test point as possible and as close to the receiver test point as possible. High speed signaling test, timing, and amplitude measurements can seriously impact margin test results if the measurement process introduces unwanted signal discontinuity from long traces and/or fixturing from the actual transmitter/receiver test points.
In some cases, the probe access point could be at a location where the signal is degraded due to the transmission line length. In this case, you might have to de-embed the transmission line to see what the real signal is. De-embedding involves recreating a model (using a linear method with S parameters) of the measurement channel between the instrument and the targeted test point. This model can be applied to acquired waveform data in the oscilloscope to account for those transmission line degradations (see Figure 5).
By practicing good signal integrity in your measurement techniques, you’ll be better equipped to evaluate and characterize high speed technologies like JESD2024B.
The recently released JESD204B interface can reliably increase data transfer bandwidth between a converter and a logic device, and a number of new devices using this interface are making their way to market. Unlike many other high speed serial interface standards, the JESD204B standard does not include an official compliance test specification, creating a number of challenges for system designers who must thoroughly test and debug their designs. Fortunately, the specification includes sufficient information to develop testing procedures, including PHY, timing, and protocol tests.
In addition to validating performance and compliance to the specification, testing can help determine the need for emphasis or equalization in a system design and help to identify unwanted sources of noise and jitter. As with any high speed serial testing effort, best practices for instrument selection, setup, and probing should be followed to ensure consistent and accurate results.