JESD204B: Understanding the protocol

I’ve learned a lot about the JESD204B interface standard while designing systems with our latest analog-to-digital converters (ADCs) and digital-to-analog converters (DACs), which use this protocol to communicate with FPGAs.  I’ve also read articles and other blog posts here on E2E that address some of the reasons why JESD204B is the successor to LVDS and CMOS interfaces.

A topic that hasn’t been discussed as much is the portion of the protocol that addresses the ADC-to-FPGA and the FPGA- to-DAC link, both of which are essentially the same TX-to-RX system. As an applications engineer, I needed to understand the nuances of this so I could take full advantage of the benefits JESD204B provides over existing LVDS and CMOS interfaces .

With JESD204B, you no longer:

  1. Need a data interface clock (embedded in the bit stream)
  2. Have to worry about lane skew (lane alignment fixes this)
  3. Need a large number of I/O (high speed SERDES for large through-puts)
  4. Have to worry about complex means to synchronize multiple ICs (subclasses 1 and 2)

Let’s consider the simple case where a digital source, such as an ADC, is transmitting digital data to an FPGA. Before data can be sent or received correctly, several things must occur, as outlined in Figure 1 and explained below.

Figure 1. JESD204B protocol state diagram

1. Code group synchronization (CGS) – Interface clocks are not required, so the RX must align its bit and word boundaries with the TX serial outputs. The RX sends a SYNC request to the TX to transmit a known repetitive-bit-sequence on all of its lanes, in this case, K28.5 /K/ characters. The exact bit sequence of the characters can be found in the standard. The RX will shift the bit data on each lane until it finds four consecutive K28.5 characters. At this point, it will know the bit and word boundaries and have achieved CGS. It can then de-assert the SYNC and both the TX and RX can drop into the next state – initial lane alignment sequence (ILAS).

2. ILAS – A nice feature of the JESD204B protocol allows for absorbing lane skew with some internal FIFO/buffers within the RX block. After CGS is achieved, the TX transmits a known set of frames of characters on each of the lanes – known as the lane alignment sequence (starts with K28.0 /R/ character, ends with K28.3 /A/ character). Upon receiving the alignment sequence, the RX will FIFO buffer the data until all lanes have received the entire alignment sequence.  Since the entire sequence is known, the lanes can then be re-aligned so that any lane skew is absorbed by the FIFO memories on each lane, and the lanes can then have the data released at the same point in time within the RX block. This alleviates the need for having a matched layout for the SERDES lanes, since lane skew is absorbed by the FIFO memory.

3. User data – Once the code groups have been synchronized and the lanes have been aligned, the user data can be correctly received. If during this last state when the user data is valid, there is a need to restart the process, the RX can send a request for SYNC, which will restart the process.

The idea of using a new technology for the first time can be daunting. Hopefully my simplified explanation of the protocol within JESD204B will help you feel a little more comfortable if you’re considering the interface for your next project.

Want to learn more about the benefits of the JESD204B? Here are some additional resources:

And be sure to check back in August for my next post on how to bring up your JESD204B link.