JESD204B: How to measure and verify your deterministic latency

In my last post, I presented a three-step process for calculating the deterministic latency of a JESD204B link. In this post, I’ll explain: 1) how to choose your release buffer delay (RBD) to ensure a deterministic latency, and 2) how to measure and verify the expected deterministic latency. 

Choosing the appropriate RBD value

As discussed in my previous post, RBD=K is the default setting. This allows the initial lane alignment sequence to align all lanes and release them at the subsequent multiframe boundary. There are situations where system delays could cause the last arriving lane to straddle the data release point. In this case, the lanes may be released with a latency that varies by one multiframe period, depending on if the last lane arrives just before or just after the multiframe boundary. The choice of RBD is critical in this situation to provide enough margin to account for variations in the system delay while at the same time minimizing latency when the data is released.

Figure 1: Possible release points A: maximum margin, maximum delay versus B: minimum margin, minimum delay

As shown in Figure 1, an RBD=A setting would provide possible release points that would maximize the margin for variations in system delay. This also means, however, that the data must be delayed longer before it is released, resulting in a longer latency. A setting of RBD=B would release the data immediately after the last lane arrival, but some care is required to ensure that the selected delay allows enough margin to avoid possible issues with system variations.

Figure 2: Adjusting RBD to find a possible optimal release point 

One possible setting would be to offset the release point by the expected amount of system variation after the latest arriving lane. This may provide the appropriate trade-off between latency and margin to absorb possible system variations. This optimal data release point can be derived from the system parameters if those are readily available. For cases where the delay parameters are not readily available, you can derive the release point empirically.

First, start by using the default RBD=K setting. Then repeat the power cycle and adjust the delay until you observe full multiframe jumps in the measured latency. This is the upper range of the last lane arrival. As you continue to decrease the RBD value through the delays caused by system variation, you will notice the latency stabilize. This is the lower range of the last lane arrival. The difference between the upper and lower range is the system delay variation. Setting the RBD delay to this offset from the upper range is one possible optimal solution that would provide a margin against system variations while providing a consistent data release point.

Calculating, measuring and verifying your deterministic latency

A system consisting of the 16-bit, 370-MSPS ADC16DX370 and an FPGA was used to compare the measured latency with the expected latency from our calculations. The ADC16DX370 was connected to the FPGA mezzanine card (FMC) port of the FPGA platform. A pulse was generated and fed into the input of the analog-to-digital converter (ADC), as well as an oscilloscope. The ADC samples the input signal and passes this data to the FPGA through the JESD204B link. Upon receiving the ADC sample, the FPGA then sends the most significant bit (MSB) to an input/output (I/O) pin to be monitored by the oscilloscope. By factoring in the delays of the cables and board traces, and the time it takes for the input pulse signal to be sampled and passed through the link to the FPGA, it is possible to measure and confirm your latency.

The block diagram in Figure 3 shows the expected delays of the cables and traces for the various parts of the setup.

Figure 3: Additional non-device-related delays used in the delay calculation. A pulse is sent to the oscilloscope and the ADC. The MSB from the captured sample is compared against the pulse to measure the delay.

The following configuration was used on the ADC16DX370 and FPGA:

1. ADC device clock = 370MSPS (2.7ns period).
2. JESD204B parameters:
   1. L = 4, M = 2, F = 1, S = 1, K = 32.
   2. The frame cycle = 10*F/linerate = 10*1/3700MSPS = 2.7ns.
   3. LMFC cycle = frame cycle * K = 2.7ns*32 = 86.4ns.
3. FPGA device clock = 92.5MHz (10.8ns).
4. Link parameters (frame cycles):
   1. .
   2. N = 2, RBD = 28 (less than K).
5. Additional delays outside of the link latency (frame cycles):
   1. ADC core delay = 12.5.
   2. DEVCLK routing skew and MSB output cable/printed circuit board (PCB) routing delay = 3.8ns/2.7ns ~ 1.4.
   3. SYSREF/DEVCLK sampling skew within ADC = 1.5.
   4. FPGA receiver processing delays to latch the samples and send out the MSB = ~7.

As derived in my previous post, Equation 1 is:

Link latency = 116.5 frame cycles

Estimated total latency = link latency + additional delays = 116.5 + 12.5 + 1.4 + 1.5 + 7 = 138.9 cycles

The delay was measured over multiple power cycles between the signal pulse and the MSB from the FPGA. This gave a consistent latency result of 379.6ns, which equates to 140.4 frame cycles. This closely matches the estimated delay of 139 cycles based on the system parameters.

For additional advice about designing with for JESD204B, see the resources below:

• Take a deeper dive into JESD204B subclasses and deterministic latency in this training presentation.
• Download our JESD204B white paper for tips on what you need to know when transitioning to JESD204B.
• Read more JESD204B blogs.
• Learn about TI’s JESD204B ADCs, DACs, clocks and tools.