JESD204B: How to bring up your link


In my previous post, Understanding the protocol, I took a high-level functional look at the three states within the JESD204B protocol that are critical to establish a valid data link between the TX and RX portion of the link: code group synchronization (CGS), initial lane alignment sequence (ILAS) and user data.  Today, I’m exploring the signaling that must occur between the TX and RX to complete the required steps needed to establish a valid link.

Let’s assume you’ve made the required electrical connections between the TX and RX, as shown in Figure 1 below. Note that arrows show the directionality of the signals. 

Figure 1 – Signal connections for the JESD204B TX to RX link

The signals going from the TX (tx_dataout) to the RX are the SERDES lanes comprising the data link. These signals do not need to be skew aligned.  The signal from RX back to TX is the SYNCn request signal. 

The clock chip, typically an LMK04828 ultra-low-jitter synthesizer and jitter cleaner, provides a device clock to the txlink_clk and rxlink_clk. It also provides a SYSREF to synchronize the TX and RX time domains. 

The transmitter and complementary receiver include the 8b/10b coding, the data link layer, scrambler and transport layer. Let’s assume that both the transmitter and receiver are configured with the same LMFS configuration and PLL settings. 

To examine the signals as we progress through the various states of the JESD204B protocol, you may use the signal analysis tools from your FPGA vendor.

The first step to establish a JESD204B link is for the RX to signal the TX to start Code Group Synchronization (CGS):

a.) RX toggles SYNC  low to the TX to request start of CGS.

b.) TX will respond by starting to transmit K28.5 characters (0xBC hex prior to 8b/10b encoding).

c.) After the RX receives and is able to decode a minimum of 4 K28.5 characters, it will raise the SYNC signal to tell the TX to start transmitting the ILAS sequence.

Figure 2 – a) SYNC low request from RX to TX; b) TX responds with K28.5 (0xBC octets); c) after RX receives the K28.5 characters the SYNC is brought high, causing the TX to start sending ILAS

The next step is initial lane alignment sequence (ILAS):

d.) Once the SYNC goes high, the TX will start to transmit the ILAS on each of its lanes at the rising edge of the LMFC (local multi-frame clock – LMFC is not shown in the plot).  All of the lanes will be source-aligned to this LMFC edge.

e.) The ILAS will always consist of 4 multi-frames of data. Each multi-frame will start with a K28.0 and end with a K28.3 character. Link configuration data is transmitted on the 2nd multiframe at the start of the 3rd octet.

 

Figure 3 – d) SYNC is raised by RX to indicate to TX to start ILAS; e) ILAS is transmitted on all of the lanes

f.) Figure 4 outlines the structure of the ILAS multiframes. This can be confirmed in the ILAS octet stream from the TX. The K28.0=R and K28.3=A characters are used to align all of the lanes in a multi-point link.

Figure 4. ILAS structure

Following the ILAS,  the TX transmits valid user data via the serial lanes.

g.) Inside the RX, each lane will store the last A character of the ILAS sequence and any user data following it in per lane elastic buffers. The release point of the user data in the elastic buffers is typically at the next rising edge of the LMFC following the detection of the last A character in each per lane elastic buffer. The user data that is received will need to go through the reverse of the transport layer as on the TX side to re-arrange the serial bits into meaningful parallel samples.

h.) This lane alignment feature ensures that all of the data from each of the lanes is aligned. It also absorbs any lane skew caused by physical layout. This is one of the key features used in achieving deterministic latency – a topic I’ll cover in a future blog post.

Stay tuned for my next post – determining your JESD204B link parameters from your signal chain frequency plan.

 

  • Dear Ken

    I would like to see a reference design from TI based on a KeyStone II processor that is capable to do:

    - 500 MSPS (8 bit or more) ADC Data to CPU

    - 100 MSPS (8 bit or more) DAC Output

    - An MRAM Interface would be nice

    - Ethernet / USB is a must

    Can you please show us how to do this?

    I think that there is a gap between the ADC / DAC high speed world witch requires FPGAs and the high performance CPUs from TI that can't handle the data streams and compute the data. This leads to more costs.

    From my point of view the Keystome II Technology is a step into the right direction.

    It would be great to see a reference design for this purpose

    Thank you in advance

    Martin

  • Martin,

    Thanks for your interest in JESD204B.  High speed data converters in general are moving to this interface mainly for throughput and synchronization purposes.  You are correct that in the past most applications would require some form of FPGA to implement the JESD204B protocol.  However there are some processors that exist today that have the JESD204B IP embedded on chip, removing the need for an interface FPGA.  I have contacted the Processor team to respond to your request and they will be in touch shortly.

    Ken