Receive Latency
The latency variation is critical for JESD204C systems. The receive latency through the IP core is fixed, although it can be varied under user control-- see Minimum Deterministic Latency Support for details, but the transceiver introduces some variation as the internal receive elastic buffer of the transceiver is included in the data path. The variation in latency is compensated automatically by the core to ensure that the overall end-to-end latency has no variation. Refer to the Latency calculations checklist (AR: 66143). The 8B10B and 64B66B receive data path latencies are shown in the following tables. They do not include the latency through the JESD204_PHY IP core if using UltraScale/UltraScale+, or the GT Quad/GT Wizard subsystem if using a Versal adaptive SoC (GTdelay).
If using UltraScale or UltraScale+, the receive latency through the JESD204_PHY IP core is equal to the latency through the GT (GTdelay). There is no additional latency added by the JESD204_PHY IP core. Refer to the relevant GT for the PHY latency values.
| GTME5 Transceiver 2 | All Other Transceivers | |
|---|---|---|
| TRXLMFc (octet clks) 1 | 32 | 16 |
| TRXIN | TRXLMFc + GTdelay 3 | TRXLMFc + GTdelay 3 |
| TRXOUT | 0 | 0 |
1 Latency values are given in 8b10b octet clocks. See RX End to End Latency for detailed use.
2 When using Versal adaptive SoC GTME5 transceivers, there is an additional latency in the receive data path because the 8b10b decoding function is performed external to the GT Quad/GT Wizard subsystem.
3 For more information on GT latency values, see GT documentation.
| GTME5 Transceiver 2 | All Other Transceivers | |||
|---|---|---|---|---|
| With FEC | Without FEC | With FEC | Without FEC | |
| TRXLEMC (core clks) 1 | 17 +/-1 3 | 15 +/-1 3 | 8 | 6 |
| TRXIN | TRXLMFc + GTdelay 4 | TRXLMFc + GTdelay 4 | TRXLMFc + GTdelay 4 | TRXLMFc + GTdelay 4 |
| TRXOUT | 0 | 0 | 0 | 0 |
1 Latency values are given in core clocks. See RX End to End Latency for detailed use.
2 When using Versal adaptive SoC GTME5 transceivers, there is an additional latency through the receive data path because the 64b66b decoding function is performed external to the GT Quad/GT Wizard subsystem.
3 When using Versal adaptive SoC GTME5 transceivers, there is an additional +/- 1 clock cycle of uncertainty due to the clock crossing from the rxsrclk to the rx_core_clk within the 64b66b decoder gearbox.
4 For more information on GT latency values, see GT documentation.
RX End to End Latency
Overall latency in a JESD204C system requires consideration of the various sources of fixed and variable latencies across the link.
8B10B Line Coding
ADC Timing
The key parameters of the ADC required to calculate end to end latency are:
- The fixed delay from SYSREF to LMFC (TTXLMFc)
- The fixed delay from analog input to LMFC (TTXIN)
- The delay from LMFC to JESD204C serial output (TTXOUT)
The delay from SYSREF to LMFC and analog data into LMFC must be fixed for a Subclass 1 device, but the delay from LMFC to JESD204C serial data out can vary because it is compensated for in the receiver during alignment to LMFC. See the following figure.
Core Timing
The key parameters of the FPGA receiver required to calculate end to end latency are:
- The fixed delay from SYSREF to LMFC (TRXLMFc)
- The delay from JESD204C input to LMFC (TRXIN)
- The fixed delay from LMFC to AXI Data output (TRXOUT)
The delay from SYSREF to LMFC and from LMFC to AXI Data output must be fixed for a Subclass 1 device, but the delay from JESD204C serial data in to LMFC can vary because the receiver buffer compensates for variations in end to end latency. In the latency calculations, TRXOUT = 0 and all the fixed delays are included in TRXLMFc. See the following figure.
Calculating End to End Latency
The end to end latency is always fixed and made up of a multiple number of LMFC periods plus the fixed TX and RX delays. To calculate the end to end latency, use the following steps, referring to the following figure.
Step 1: Determine How Many LMFC Periods are Required (N)
The delay between LMFC at TX and LMFC at RX (T) is an integer number (N) of LMFC periods adjusted by the internal delays from SYSREF to LMFC of TX and RX:
T = N * LMFC - TTXLMFc + TRXLMFc
To ensure the overall propagation delay is constant between system restarts, the maximum propagation delay must be less than T plus one LMFC period:
(TTXOUT(max) + TWIRE(max) + TRXIN(max)) < T + LMFC
The minimum propagation delay must also be greater than T:
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > T
Substituting (N * LMFC - TTXLMFc + TRXLMFc) for T gives:
(TTXOUT(max) + TWIRE(max) + TRXIN(max)) < ((N + 1) * LMFC - TTXLMFc + TRXLMFc)
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > (N * LMFC - TTXLMFc + TRXLMFc)
It is possible that no valid value for N can be found if the received data arrives close to an RX LMFC boundary and the variation in the link causes it to fall before or after the boundary after resetting the system. This would be seen as a jump in latency of exactly one LMFC period between system restarts. If no valid value can be found for N, then the SYSREF signals can be delayed relative to one another to move the RX LMFC boundary relative to the TX LMFC boundary. For each cycle of delay added to TX SYSREF add 4 to TTXLMFc. Additional delay can be added to the SYSREF processing in the JESD204C core to accomplish this; see Table 15.
Step 2: Calculate the End to End Latency Using N
The data is received after N LMFC periods and before N + 1 LMFC periods, so the minimum deterministic latency is T plus one LMFC plus the fixed input delay at the FPGA and the fixed output delay at the ADC:
TLAT = (T + LMFC) + TTXIN + TRXOUT
Substituting (N * LMFC - TTXLMFc + TRXLMFc) for T gives:
TLAT = ((N * LMFC - TTXLMFc + TRXLMFc) + LMFC) + TTXIN + TRXOUT = (N + 1) * LMFC - TTXLMFc + TRXLMFc + TTXIN + TRXOUT
Example
| JESD204C + GT Latency | Assume an ADC with Parameters | Assume |
|---|---|---|
| TRXLMFc = 16 | TXTIN = 14 | LMFC = 32 |
| TRXIN = 32 + 44 ± 4 = 76 ± 4 | TXTLMFc = 3 | TWIRE = 0 |
| TRXOUT = 0 | TXTXOUT = 6 |
Try N = 2
(TTXOUT(max) + TWIRE(max) + TRXIN(max)) < ((N + 1) * LMFC - TTXLMFc + TRXLMFc)
(6 + 0 + 80) < ((N + 1) * 32 - 3 + 16)
86 < 109 (margin = 23)
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > (N * LMFC - TTXLMFc + TRXLMFc)
(6 + 0 + 72) > (N * 32 - 3 + 16)
78 > 77 (margin = 1)
N=2 is OK, no need to skew SYSREF
The data is received after two LMFCs (N) and less than three LMFCs (N+1) so the latency is 3 * LMFC plus fixed delays:
TLAT = (N + 1) * LMFC - TTXLMFc + TRXLMFc + TTXIN + TRXOUT = 96 - 3 + 16 + 14 + 0 = 123
Note: In this case, the margin (how far after the RX LMFC the data arrives) is very small (1-byte period), any variation introduced by the ADC or connection between the ADC and FPGA could cause the data to be received early, causing the data to be received before the LMFC boundary. There is plenty of margin before the third LMFC so, in this case, it is advisable to delay the TX LMFC by one or two to increase the margin and therefore the reliability of the system.
If delaying the TX LMFC is not possible, then the RX LMFC can be delayed by five cycles and N reduced by one as follows:
TRXLMFc becomes 16 + 5 * 4 = 36
(TTXOUT(max) + TWIRE(max) + TRXIN(max)) < ((N + 1) * LMFC - TTXLMFc + TRXLMFc)
(6 + 0 + 80) < ((N + 1) * 32 - 3 + 36)
86 < 97 (margin 11 byte periods)
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > (N * LMFC - TTXLMFc + TRXLMFc)
(6 + 0 + 72) > (N * 32 - 3 + 36)
78 > 65 (margin 13 byte periods)
The margin numbers at min delay and max delay are closer in value, which means the system is operating with the received multiframe boundary close to the middle of the RX LMFC period; this reduces the chances of the latency changing due to delay variations in the link.
The data is received after one LMFCs (N) and less than two LMFCs (N+1) so, the latency is 2 * LMFC plus fixed delays:
TLAT = (N + 1) * LMFC - TTXLMFc + TRXLMFc + TTXIN + TRXOUT = 64 - 3 + 36 + 14 = 111
Note: GT latency is not accounted for these calculations.
64B66B Line Coding
ADC Timing
The key parameters of the ADC required to calculate end to end latency are:
- The fixed delay from SYSREF to LEMC (TTXLEMC)
- The fixed delay from analogue input to LEMC (TTXIN)
- The delay from LEMC to JESD204C serial output (TTXOUT)
The delay from SYSREF to LEMC and analogue data in to LEMC must be fixed for a Subclass 1 device but the delay from LEMC to JESD204C serial data out can vary because it is compensated for in the receiver during alignment to LEMC. See the following figure.
Core Timing
The key parameters of the FPGA receiver required to calculate end to end latency are:
- The fixed delay from SYSREF to LEMC (TRXLEMC)
- The delay from JESD204C input to LEMC (TRXIN)
- The fixed delay from LEMC to AXI Data output (TRXOUT)
The delay from SYSREF to LEMC and from LEMC to AXI Data output must be fixed for a Subclass 1 device, but the delay from JESD204C serial data in to LEMC can vary because the receiver buffer compensates for variations in end to end latency. In the latency calculations, TRXOUT = 0 and all the fixed delays are included in TRXLEMC. See the following figure.
Calculating End to End Latency
The end to end latency is always fixed and made up of one LEMC period plus the fixed TX and RX delays. To calculate the end to end latency, use the following steps, referring to the following figure.
Note: The following is valid for LEMCs of one and two multiblocks. For LEMCs of three or greater, see Receiver Elastic Buffer.
The delay between LEMC at TX and LEMC at RX (T) is the LEMC period adjusted by the internal delays from SYSREF to LEMC of TX and RX:
T = LEMC - TTXLEMC + TRXLEMC
To ensure the overall propagation delay is constant between system restarts, the maximum propagation delay must be less than T:
TTXOUT(max) + TWIRE(max) + TRXIN(max) < T
Substituting LEMC - TTXLEMC + TRXLEMC for T gives:
TTXOUT(max) + TWIRE(max) + TRXIN(max) < LEMC - TTXLEMC + TRXLEMC
Additional delay can be added to the SYSREF processing in the JESD204C core (see Table 15). For each cycle of delay added to TX SYSREF, add 1 to TTXLEMC.
The data is received after the fixed delays of TX and RX adjusted by the internal delays from SYSREF to LEMC of TX and RX. This value is also the minimum value for deterministic latency.
TLAT = TTXOUT(max) + TWIRE(max) + TRXIN(max) - TTXLEMC + TRXLEMC
Example
| JESD204C + GT Latency | Assume an ADC with Parameters | Assume |
|---|---|---|
| TRXLEMC = 6 | TXTIN = 4 | LEMC = 64 |
| TRXIN = 19 ± 1 | TXLEMC = 1 | TWIRE = 0 |
| TRXOUT = 0 | TXTXOUT = 1 |
TTXOUT(max) + TWIRE(max) + TRXIN(max) < LEMC - TTXLEMC + TRXLEMC 2 + 0 + 20 < 64 - 1 + 6 22 < 69
The data is received after the fixed delays of TX and RX adjusted by the internal delays from SYSREF to LEMC of TX and RX.
TLAT = TTXOUT(max) + TWIRE(max) + TRXIN(max) - TTXLEMC + TRXLEMC TLAT = 2 + 0 + 20 - 1 + 6 TLAT = 27 clock cycles
Note: GT latency is not accounted for these calculations.
Achieving Repeatable Latency
8B10B Line Coding
In some cases, it is not necessary to know the absolute magnitude of the end-to-end latency, but it is necessary to ensure this delay is robustly repeatable. Because high-speed transceiver-based links, such as those used for the physical layer in JESD204C, do not maintain the same data path latency through a reset or a power cycle, issues can arise in systems where the start data arrival at the receive core is very close to the LMFC boundary. Such systems might be unable to manage the small variability in delay through the link that can occur between restarts.
The following figure shows the start of sample data arriving "Just before" and "Just after" the LMFC boundary, illustrating the effect a restart can have. It can be seen that a very small difference in data arrival time at the core can cause a change in the timing of the output data equal to one LMFC period.
To protect against this problem, a margin must be introduced, around the LMFC boundary, which the start of data must avoid. The following figure shows this.
The LMFC is a periodic signal requiring a target window (TW) within which to aim. The following figure shows this. If data can start within this TW, link robustness is ensured.
The TW can generally be set reliably at between two CORE_CLK cycles before and two CORE_CLK cycles after an LMFC boundary.
This assumes that any variation in the output timing of the ADC is less than four octets. If the output variation is greater than four octets, the margin can be increased and the TW decreased accordingly.
The solution is to adjust the internal LMFC relative to the fixed data arrival such that arriving data falls within the target window shown in above figure (i.e., move the window).
This is achieved by starting the link, and using core registers to determine the amount of data which was buffered, then taking steps to adjust the LMFC boundary until acceptable values are attained. This process should only be required to be performed once during development as when the system has been adjusted to ensure the data arrival is within the target window, it should not require further adjustment.
The registers used during this process are:
BUFFER FILL LEVEL
Located in the STAT_RX_BUFF_LVL register (see Table 27). The JESD204C 8B10B core contains a readable BUFFER FILL LEVEL register for every JESD204C 8B10B lane. This register indicates how much data was in the lane alignment buffer for each lane at the LMFC boundary when the output data was released.
Note: The value in the BUFFER FILL LEVEL register might be different for each lane due to inter-lane skew on the link. The value of interest is the smallest value of all the lanes. This marks the starting point in time when all lanes had valid data. This is the point where the core was actually ready to release data. The value in this register is a count in octets, and there are four octets per CORE CLK cycle.
SYSREF DELAY
Located in the CTRL_SYSREF register (see Table 15). This register delays the internal LMFC boundaries relative to SYSREF by an integer number of CORE CLK cycles. Therefore, programming a SYSREF DELAY of 0x1 will cause the LMFC to be delayed by four octets.
Procedure - Achieving Repeatable Latency
- Calculate the Multi Frame (MF) size. MF = F * K (Where F = Frame Size and K = Number of Frames per Multi Frame.) The larger the value of MF, the greater the target window will be. It is recommended to pick a value for K that results in a MF of at least 32 octets.
- Calculate the TW maximum value in octets based on the MF size. This is: Max = (MF - 0x8) Min = 0x8. (0x8 = 2 CORE_CLK cycles)
- Configure the system and start the link. At this point, all delays can be unknown.
- Once the link is running, read the JESD204C 8B10B RX core BUFFER FILL LEVEL register for every JESD204C 8B10B lane in use. Select the smallest value read from the BUFFER FILL LEVEL register and call this value BUF_FILL.
- If BUF_FILL falls between the Min and Max values (calculated at step 2), the data arrival is within the safe TW and no further action is required. If however the BUF_FILL does not fall between the Min and Max values, then the following action should be taken.
a. Program the SYSREF DELAY register with a delay value calculated as follows:
- If the BUF_FILL value is low then the SYSREF DELAY value programmed should be increased by 1 or 2 as follows:
- If BUF_FILL < Min - 4. Then SYSREF DELAY should be increased by two.
- If BUF_FILL < Min but > Min - 4. Then SYSREF DELAY should be increased by one.
- If the buffer is almost full, then the SYSREF DELAY value programmed should be increased by three or four (i.e., 1 or 2 plus the low margin of 2) as follows: b. Reset the JESD204C receive core, and reinitialize the link. This step must be performed before the modified SYSREF_DELAY value will affect the LMFC. c. Re-read the BUFFER FILL LEVEL register for every lane to confirm the data arrival is now within the target window. The calculated SYSREF DELAY value should be stored for future use when configuring this link.
- If the BUF_FILL value is low then the SYSREF DELAY value programmed should be increased by 1 or 2 as follows:
64B66B Line Coding
In some cases, it is not necessary to know the absolute magnitude of the end-to-end latency, but it is necessary to ensure this delay is robustly repeatable. Because high-speed transceiver-based links, such as those used for the physical layer in JESD204C, do not maintain the same data path latency through a reset or a power cycle, issues can arise in systems where the start data arrival at the receive core is very close to the LEMC boundary. Such systems might be unable to manage the small variability in delay through the link that can occur between restarts.
The following figure shows the start of sample data arriving "Just before" and "Just after" the LEMC boundary, illustrating the effect a restart can have. It can be seen that a very small difference in data arrival time at the core can cause a change in the timing of the output data equal to one LEMC period.
To protect against this problem, a margin must be introduced around the LEMC boundary, which the start of data must avoid. The following figure shows this.
The LEMC is a periodic signal requiring a TW within which to aim. The following figure shows this. If data can start within this TW, link robustness is ensured.
- Calculate the TW max and min values in words based on the receive buffer size as follows. TW Max = 64 - 2 = 62. (In the case where EMB=1, TW Max is not applicable)
This assumes that any variation in the output timing of the ADC is less than one 64-bit word. If the output variation is greater than one word, the margin can be increased, and the TW decreased accordingly.
The solution is to adjust the internal LEMC relative to the fixed data arrival such that arriving data falls within the target window shown in the previous figure (i.e., move the window).
This is achieved by starting the link, and using core registers to determine the amount of data which was buffered, then taking steps to adjust the LEMC boundary until acceptable values are attained. This process should only be required to be performed once during development as when the system has been adjusted to ensure the data arrival is within the target window, it should not require further adjustment.
The registers used during this process are:
BUFFER FILL LEVEL
Located in the STAT_RX_BUFF_LVL register (see Table 27): The JESD204C 64B66B core contains a readable BUFFER FILL LEVEL register for every JESD204C 64B66B lane. This register indicates how much data was in the lane alignment buffer for each lane at the LEMC boundary when the output data was released.
The value in the BUFFER FILL LEVEL register might be different for each lane due to inter-lane skew on the link. There are two values of interest, the smallest and the largest values of all the lanes. The smallest value impacts the beginning of the TW, and the largest impacts the end. The value in this register is a count in 64-bit words and there is one word per CORE CLK cycle.
SYSREF DELAY
Located in the CTRL_SYSREF register (see Table 15). This register delays the internal LEMC boundaries relative to SYSREF by an integer number of CORE CLK cycles. Therefore, programming a SYSREF DELAY of 0x1 will cause the LEMC to be delayed by one word.
Procedure - Achieving Repeatable Latency
- Calculate the TW max and min values in words based on the receive buffer size as follows. TW Max = 64 - 2 = 62. (In the case where EMB=1, TW Max is not applicable)
- Configure the system and start the link. At this point, all delays can be unknown.
- Once the link is running, read the JESD204C 64B66B RX core BUFFER FILL LEVEL register for every JESD204C 64B66B lane in use. Select the smallest value read from the BUFFER FILL LEVEL register and call this value BUF_FILL.
- If BUF_FILL falls between the Min and Max values (calculated at step 2), the data arrival is within the safe TW and no further action is required. If however the BUF_FILL does not fall between the Min and Max values, then the following action should be taken.
a. Program the SYSREF DELAY register with a delay value calculated as follows:
- If the BUF_FILL value is low, then the SYSREF DELAY value programmed should be increased by one or two as follows:
- If BUF_FILL = 0. Then SYSREF DELAY should be increased by two.
- If BUF_FILL = 1. Then SYSREF DELAY should be increased by one.
- If the buffer is almost full, then the SYSREF DELAY value programmed should be increased by three or four (i.e., 1 or 2 plus the low margin of 2). b. Reset the JESD204C receive core and reinitialize the link. This step must be performed before the modified SYSREF_DELAY value will affect the LEMC. c. Re-read the BUFFER FILL LEVEL register for every lane to confirm the data arrival is now within the target window. When configuring this link, the calculated SYSREF DELAY value should be stored for future use.
- If the BUF_FILL value is low, then the SYSREF DELAY value programmed should be increased by one or two as follows:
Receiver Elastic Buffer
Lane alignment is achieved using 64B66B encoding in the following manner. Each lane has a receiver buffer, which is two multiblocks deep, 2 x 32 64-bit words.
Each lane's receive buffer starts buffering data when the EOEMB is received. When the last arriving lane has received its EOEMB, all lane receive buffers are released on the next LEMC, so that all lanes are aligned and released at the right time.
For designs where EMB > 2 MB, extra care should be taken to ensure the buffer does not overflow. The following figure shows an example where E = 3, i.e., there are three multiblocks in an EMB. The figure shows before and after an adjustment to the SYSREF_DELAY register has been made. In the before case, the LEMC boundaries straddle the receive buffer, so it is not released and the buffer overflows. In the after case, the LEMC boundary has been shifted by N clock cycles to place it in the safe TW allowing the buffer to be released correctly with no overflow.
Minimum Deterministic Latency Support
When the JESD204C link is first established in Subclass 1 and Subclass 2 devices, the receiver outputs data as shown in the following figure. Data is output on the LMFC crossing after valid data is detected in all lanes. It is possible to support minimum latency by adjusting the number of octets input on the BUFFER FILL LEVEL register.
An indication of the maximum allowable reduction of the latency is output on the BUFFER FILL LEVEL register. This provides an indication of the difference between the write and read pointers of the receiver elastic buffer in each lane. The number of octets output in each 10-bit value give an indication of the buffer fill level in each lane. The lowest number given can be used to calculate a value that can be programmed to the BUFFER FILL LEVEL register to reduce the overall latency by that number of octets. The maximum value programmed into the BUFFER FILL LEVEL register must take into account the eight octet margin described in Achieving Repeatable Latency, and therefore should not be greater than the lowest BUFFER FILL LEVEL value minus eight.
A reset of the JESD204C receive core and a full link resynchronization cycle must take place before the modified latency setting is acted upon. A minimum latency example is shown in the following figure.
Error Signaling Using the SYNC~ Interface (8B10B only)
In the JESD204C RX core, the SYNC~ signal can be deasserted for two frame periods at the end of each multiframe to indicate an error has occurred which does not require a full reinitialization of the link. This behavior is enabled by the deassertion of the disable_error_reporting control bit.
The SYNC~ signal is a 1-bit output; this enables the correct error output for a frame size of down to two octets. The signal is Low when the receiver has detected an error. An error occurs when an idle or an unexpected control character is received during normal frame transmission.
To give a frame-accurate SYNC~ output when the frame size is one octet, the SYNC~ signal should be asserted for only half a cycle of the device clock. This is not implemented in the core as it would require a dedicated clock (either twice the device clock speed or an inverted device clock). If accurate timing of SYNC~ assertion for error reporting is required, logic must be added externally to generate a half cycle pulse on the external SYNC~ pin if the core SYNC~ signal is asserted for a single cycle and F = 0.
Link Reinitialization (8B10B only)
In the JESD204C RX core, errors that require a full link re-initialization are signaled by deasserting SYNC~ for a period 16 frames. When this occurs, the transmitter should fall back out of data transmission mode and renegotiate the link as described in the previous device subclass sections.
The following error conditions require a full link reinitialization:
- Four consecutive 8B10B decoder errors (disparity or not in table).
- Four consecutive unexpected Kx.y characters (rxcharisk is expected only at the end of the frame).
- Eight consecutive alignment errors (multiframes not aligned to LMFC).
A TX might initiate a re-initialization using the data interface by sending four consecutive Kx.y characters. This causes the error condition above to be triggered in the receiver. K28.5 (0xBC) would normally be used for this.