GTS JESD204C Intel® FPGA IP User Guide

Download PDF
ID 813959
Date 4/01/2024
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. About the GTS JESD204C Intel® FPGA IP User Guide 2. Overview of the GTS JESD204C Intel® FPGA IP 3. Functional Description 4. Getting Started 5. Designing with the GTS JESD204C Intel® FPGA IP 6. GTS JESD204C Intel® FPGA IP Parameters 7. Interface Signals 8. Document Revision History for the GTS JESD204C Intel® FPGA IP User Guide
2. Overview of the GTS JESD204C Intel® FPGA IP x
2.1. Release Information 2.2. Device Family Support 2.3. GTS JESD204C Intel® FPGA IP Features 2.4. Performance and Resource Utilization
3. Functional Description x
3.1. Clocks 3.2. Local Extended Multiblock Clock 3.3. CRC Encoding/Decoding 3.4. Scrambler/Descrambler
3.1. Clocks x
3.1.1. Device Clock 3.1.2. Frame Clock and Link Clock 3.1.3. GTS Reset Sequencer Intel® FPGA IP Clock
3.2. Local Extended Multiblock Clock x
3.2.1. LEMC Counter
4. Getting Started x
4.1. Installing and Licensing Intel® FPGA IP Cores 4.2. Intel® FPGA IP Evaluation Mode 4.3. IP Catalog and Parameter Editor 4.4. GTS JESD204C IP Component Files 4.5. Creating a New Quartus® Prime Project 4.6. Parameterizing and Generating the IP 4.7. Compiling the GTS JESD204C IP Design 4.8. Programming an FPGA Device
5. Designing with the GTS JESD204C Intel® FPGA IP x
5.1. Configuring the GTS Reset Sequencer Intel® FPGA IP 5.2. Reset Initialization 5.3. Configuration Phase 5.4. Link Reinitialization 5.5. SYSREF Sampling 5.6. Interrupt and Error Handling 5.7. Multi-Device Synchronization 5.8. Deterministic Latency
5.2. Reset Initialization x
5.2.1. GTS JESD204C TX Reset Sequence 5.2.2. GTS JESD204C RX Reset Sequence
5.6. Interrupt and Error Handling x
5.6.1. Interrupt Configuration for TX and RX 5.6.2. Interrupt Top Half ISR Handler 5.6.3. Interrupt Bottom Half ISR Handler
5.7. Multi-Device Synchronization x
5.7.1. Multi-Device DAC Application for Subclass 1 5.7.2. Multi-Device ADC Application for Subclass 1
5.8. Deterministic Latency x
5.8.1. RBD Tuning Mechanism
7. Interface Signals x
7.1. Transmitter Signals 7.2. Receiver Signals
1. About the GTS JESD204C Intel® FPGA IP User Guide
2. Overview of the GTS JESD204C Intel® FPGA IP
3. Functional Description
4. Getting Started
5. Designing with the GTS JESD204C Intel® FPGA IP
6. GTS JESD204C Intel® FPGA IP Parameters
7. Interface Signals
8. Document Revision History for the GTS JESD204C Intel® FPGA IP User Guide

5.8. Deterministic Latency

To achieve optimal performance for deterministic latency, Intel recommends that you follow the guidelines provided.

The JESD204C Specifications states the following requirements to achieve optimal performance for deterministic latency:
  • Length of extended multiblock size must be larger than the maximum possible delay variation across any link.
  • Value of RX buffer delay (RBD) in terms of link cycles must be larger than possible delay across any link.

These two requirements ensure that the RBD is large enough to guarantee the TX data reaches the RX buffers before the RX elastic buffer is released. The IP releases the RX elastic buffer at the assertion of the SYSREF signal. You could set the IP to release the RX elastic buffer earlier to reduce latency.

The GTS JESD204C TX and RX cores run on a link clock with 64-bit data width, and support a configurable E parameter. These settings enable the IP to tune the RBD release in the link clock domain instead of the frame clock domain. The effective frame clock period changes depending on the F parameter.

For the GTS JESD204C IP, Subclass 1 modes support deterministic latency. Use the following guidelines for Subclass 1 deterministic latency tuning.

  • The JESD204C Specifications only describes the tuning of the RBD release on the left side of the SYSREF. The GTS JESD204C RX core allows the tuning for RBD release on both left and right sides of the SYSREF tick, as long the tuning does not violate the multiframe buffer.
  • Different ADC/DAC vendors have different variations. The SYSREF offset depends on how precise the system is set up and minimized.
  • In a multipoint link, all IP cores within that multipoint link must use the same SYSREF signal to ensure that the LEMC counters in each core are aligned.
  • The converter device and the FPGA devices must always sample the SYSREF signal before deterministic latency can be achieved. If there is race condition, do a link reinitialization so that all transactions are based on the LEMC counters sampled with SYSREF instead of the free-running LEMC counters in both the devices.
  • Upon the detection of the SYSREF edge, the GTS JESD204C TX core transmits the SH data when the next LEMC counter is 0. Subsequently, the core indicates the end of an extended multiblock (EoEMB) after E number of block has been sent.
  • The GTS JESD204C RX core implements the RX elastic buffer (per lane) that is large enough to store all multiblocks. The RX elastic buffer is 1024 deep with a single multiblock. This buffer size allows the tolerance of lane skew between the earliest possible data arrival to the latest lane arrival to the release opportunity. Release opportunity should never be set before the earliest arrival data.
  • The release opportunity in GTS JESD204C specification indicates the range that covers the full size of RX elastic buffer or at least one LEMC cycle, which ever is smaller. For GTS JESD204C RX core, the release opportunity is either LEMC or RBD offset (whichever is earlier). Due to the limit of elastic buffer size, GTS JESD204C RX core does not tolerate the condition where ((E*32) – rbd_count_early) and rbd_offset has the delta of more than 1024.
  • Latency incurred by TX and RX should be repeatable. Upon resets, there is also latency variation in the RX SERDES contributed from the phase compensation FIFOs, gearbox, and word aligner.
  • By choosing a RBD release which can tolerate the cumulative latency variation from the transmit path to the receiver path, there is always a fixed number of latency from transmit to release path. This creates the deterministic latency.
  • RBD count reflects on which LEMC count the latest arrival lane is. RBD offset is a user-defined value to indicate on which LEMC count the RBD is released. All lanes are aligned when RBD is released.
  • RBD count may vary slightly upon multiple resets. The worst possible value is 2 link clock counts in a single direction. RBD count reflects on which LEMC count the latest lane arrived, thus it always is any legal value from 0 to E*32 – 1.
  • RBD offset is a user-defined register. Legal value for specific point of tuning has to be 0 to (E*32) – 1. However, if you set any value larger than (E*32) – 1, this is interpreted as immediate RBD release which is equivalent to the RBD count on the latest lane arrival. Alternatively, the control and status registers provide an additional bit which can be set to indicate RBD immediate release.
  • If there are multiple lanes, setting RBD offset as RBD count minus 1 is illegal and causes LEMC align error. This setting violates the internal buffer.
  • For example, in a system where E=1; legal value of RBD count is from 0 to 31. During the first reset, if the RBD count reported is 8, do not set RBD offset 2 link clock counts before and after RBD count. This is because in a multiple reset scenario, you do not know if the RBD count varies forwards or backwards. For the actual count, you need to wrap around the count. For the actual point of release:
    • ((E*32) – RBD offset) value which is larger than RBD count means RBD release on the right side of the LEMC tick.
    • ((E*32) – RBD offset) value which is smaller than RBD count means that RBD release on the left side of the LEMC tick.
  • After identifying the correct RBD offset value to set, set this value to all the links in the multipoint link.

Section Content
RBD Tuning Mechanism

Level Two Title