JESD204B: What is deterministic latency? Why do I need it? How do I achieve it?

What is deterministic latency?

As I discussed in my last two blog posts, JESD204B: Understanding subclasses: Part 1 and Part 2, the JESD204B data converter interface standard provides two subclasses to achieve deterministic latency: subclass 1 and subclass 2. Most who are familiar with the standard would agree that the deterministic latency feature of JESD204B is one of the standard’s key advantages. But what is it? Why is it so important?

A deterministic system is one where no random processes are involved in the formation of a system’s future states. Therefore, given the same initial conditions, the final outcome will be the same every time.

Latency is defined as the time it takes to go from point A to point B. In a JESD204B link, latency occurs from the input to the TX block to the output of the RX block. This is called link latency, as shown in Figure 1. 

Figure 1. Block diagram of simplified latencies in a TX-RX JESD204B link. Deterministic link latency is achieved by using the elastic buffer with an appropriate data release point.

By definition, achieving deterministic link latency for a system means that the system will be able to have a fixed link latency from startup to system startup. You can calculate the total latency by adding the data converter latency (normally specified in the data sheet) with the deterministic link latency.

Why is deterministic latency important?

So why is it important to achieve deterministic latency? Some systems, such as feedback loops for digital pre-distortion and automatic gain control loops, are sensitive to latency variations, while other systems, such as defensive countermeasures used in military applications, are sensitive to total latency. Also, any system that requires multi-device synchronization, such as phased-array radars, beam-forming antennas or medical imaging equipment, will need to achieve a known, fixed deterministic latency for all devices to achieve synchronization.

How do you achieve deterministic latency using JESD204B?

There are two requirements to achieve deterministic latency from startup to startup:

  1. Alignment of all local multi-frame clocks (LMFCs) at the TX and RX devices
  2. Release point for the data set to after the latest arriving lane

To achieve alignment of all LMFCs at the TX and RX devices, you will need to reset and align the LMFCs using subclass 1 (SYSREF) or subclass 2 (SYNC), as provided by the standard and discussed in a previous blog post. The aligned LMFCs establish a common time reference and provide a fixed-phase offset for each of the devices.

Typically all of the lanes of a JESD204B link are buffered and aligned so they are released together at the next LMFC data release point. In most cases, this ensures the system is deterministic. However, there are cases where the total link delay for the lanes is very close to the LMFC edge, and with some system variations, the last lane may arrive after the LMFC edge. This would force all of the lanes to release at the next LMFC edge, which results in a latency that may vary by as much as 1 LMFC period and is not deterministic from startup to startup.

Figure 2. A non-deterministic latency case. Variations in the arrival time of the last lane may span past the LMFC edge, and the data release point may be off by as much as 1 LMFC period from startup to start up.

You can fix this problem by using the elastic buffer in the JESD204B receiver block. The release buffer delay (RBD) setting controls the elastic buffer and allows the user to select and set the number of frames (1 to K frames) after the LMFC edge as the data release point.

To do that, you must first calculate the maximum link latency, including possible variations across process, voltage and temperature. If there is enough margin away from the next LMFC edge, you can set RBD to K, which will release all of the aligned lanes on the next LMFC edge.

With system variations, the lane arrivals may span over the LMFC edge that defines the data release point. In this case, some number of frames may be chosen with the RBD setting to set the data release point to occur after the uncertainty of the arrival of the lanes. You can use the RBD setting to set the data release point to minimize latency or to provide more margin from the uncertainty caused by variations in the system.

Figure 3. Using RBD to set the release point later than LMFC to account for system variation guarantees the same latency in both cases.

The ability to delay the release of data to account for delays caused by system variations guarantees deterministic latency from startup to startup and over process, voltage and temperature.

Stay tuned for my blog post next month, which will explain how to calculate the expected link latency.

Additional resources: