Mastering High-Speed Signals: Implementing IDELAYE3 Xilinx IP for FMC Interfaces

‍

Mastering High-Speed Signals: 

Implementing IDELAYE3 Xilinx IP for FMC Interfaces

‍

Introduction

In modern high-speed digital systems, precise timing is critical, because signals arriving at the FPGA often exhibit jitter, a small, unintended variation in signal timing. This phenomenon can disrupt the reliability of data sampling, leading to errors in the data acquisition.

Our implementation is based on the FMC-01, a FMC board connected to a Zynq UltraScale+ FPGA, developed by Emtech that enables both signal capture and generation with an 8-channel/16-bit ADC (ISLA216P25) working at 200 MSPS and a dual-channel 16-bit DAC processing at 400 MSPS.

‍

The causes of jitter were typically attributed to several factors:

  • Imprecise Clock Sources: Variability in the system’s clock signal can lead to inconsistent timing margins. This can be addressed with logic tied to the same ADC’s generated clock and making sure that there is no phase-out. 
  • PCB Layout Issues: Crosstalk or impedance mismatches on high-speed traces can introduce signal distortions.
  • Electromagnetic Interference (EMI): External noise sources can influence signal integrity.

To address jitter effectively, examine the clock sources used for sampling the data. A stable and well-designed clock is the foundation of any high-speed system. However, applying solid timing constraints during the FPGA design process ensures the synthesized design meets timing requirements.When these measures do not fully resolve jitter issues, a more precise approach is using the IDELAYE3 IP from Xilinx. This blog details how we optimized interfaced data performance by implementing the Xilinx IDELAYE3 primitive and provides best practices for achieving robust system functionality.

Figure 4: FPGA internal connections

The ADC's data output is delivered in parallel using DDR format. Therefore, each bit pair is handled by instances of the IBUFDS, IDELAYE3, and IDDR1 primitives. Since the data is synchronous with the incoming clock, the input clock is used to prevent any phase misalignment.

Note: Remember that each MMCM should be configured with the “Phase Alignment” option enabled.

Lastly, the IDDRE1 primitive receives the delayed data and outputs a signal divided into rising and falling edges. This signal is then remapped and reconstructed to recover the original data.

‍

ADC Data Format & Timing

According to the device datasheet, the output data is transmitted using a Double Data Rate (DDR) format, where data transitions occur on both the rising and falling edges of the clock signal. Specifically, the odd-numbered data samples are transmitted on the rising edge of the clock, while the even-numbered data samples are transmitted on the falling edge.

At the electrical layer, the DDR interface uses Low-Voltage Differential Signaling (LVDS) to enable high-speed, reliable data transmission. This differential configuration provides significant advantages in minimizing electromagnetic interference (EMI).

Figure 1: ISLA216P timing diagram

Note: take into account the timing considerations that the ADC’s datasheet describes for this application. 

‍

What is IDELAYE3?

Figure 2: IDELAYE3 primitive instance

The IDELAYE3 IP is a primitive in Xilinx FPGAs that enables fine-tuning of signal timing by introducing precise delays to an input signal, measured in tap values. Its configuration requires careful consideration of attributes and parameters to achieve the desired functionality.

Figure 3: IDELAYE3 primitive inner diagram block

‍

How should we configure this IP?

The most critical features to consider are: 

  1. IDELAY Attributes
  2. EN_VTC pin handling

‍Note: These features are the primary sources of misconfiguration due to their dependency on both the FPGA family and the specific data path requirements. The following sections outline how we configured them correctly with a brief description of each attribute. 

‍

IDELAYE3 attributes 

DELAY_SRC

Possible values:

  • IDATA IN:

Used when the signal arrives directly from an IOB (Input/Output Block)

  • DATA IN:

Used when the signal arrives comes from internal logic (e.g. IBUFDS, ISERDES)Since the data goes through an IBUFDS primitive, we set the DELAY_SRC to DATAIN and tied the IDATAIN input to LOW.

DELAY_FORMAT

This attribute provides two operational modes, that depend on the REFCLK_FREQUENCY: 

  • TIME: 

In this mode, an IDELAYCTRL component must be used according to Xilinx guide, otherwise, Vivado will output an error message. This component will calibrate, control, and maintain the voltage and temperature of the delay line. For our design with eight IDELAYE3 instances, we instantiated a single IDELAYCTRL primitive.
The REFCLK_FREQUENCY attribute must reflect the clock frequency applied to the IDELAYCTRL component. When loading a new value in the IDELAYE3 primitive, take into consideration that 511 equals a delay of 1100ps (for UltraScale+) or 1250ps (for UltraScale)

  • COUNT: 

There is no need to use an IDELAYCTRL component because the delay line is used in the uncalibrated state without voltage and temperature compensation.
- The delay line must be used counting only taps and not counting delay/tap.
- The DELAY_VALUE is expressed as taps (0 to 511).
In this case, leave the REFCLK_FREQUENCY attribute at the default value (300.0 MHz)

The TIME mode is the one selected on the configuration.

DELAY_VALUE

This attribute depends on the DELAY_FORMAT attribute and the FPGA used:

  • In TIME mode, this attribute represents the desired value in ps. UltraScale devices support delays up to 1.25 ns. UltraScale+ devices support up to 1.1 ns.
  • In COUNT mode, this attribute indicates the desired value in taps from 0 to 511.

In our configuration, the DELAY_VALUE is set to 0. 

REFCLK_FREQUENCY

The REFCLK_FREQUENCY attribute specifies the reference clock of the IDELAYCTRL or BITSLICE_CONTROL frequency in MHz, except when DELAY_FORMAT is set to COUNT (when the attribute can be left at the default value).

These are the possible values: 

  • 200.0–800.0 (UltraScale IDELAYCTRL)
  • 300.0–800.0 (UltraScale+ IDELAYCTRL) 
  • 200.0–2400.0 (UltraScale BITSLICE_CONTROL)
  • 300.0–2666.7 (UltraScale+ BITSLICE_CONTROL)

Note: The input number, is a float with 1 significant digit.

DELAY_TYPE

There are three possibilities for this attribute: FIXED, VAR_LOAD, or VARIABLE

  • FIXED: it is determined by the DELAY_VALUE and DELAY_FORMAT attributes.
    •  When DELAY_FORMAT is set to TIME, the value loaded in the delay line is in ps. When the DELAY_FORMAT is set to COUNT, the delay value loaded in the delay line is the number of taps.
  •  When DELAY_FORMAT is TIME, EN_VTC must be pulled High so that the delay automatically changes the number of taps over voltage and temperature to ensure the delay stays at the requested time in ps.
  • With DELAY_FORMAT set to COUNT, EN_VTC must be Low in Count mode. Then the delay is not compensated for voltage and temperature.
  • VARIABLE: In this mode, you will use the pins INC and CE to manually change the taps number used by the IDELAYE3 primitive. To increase the tap’s value, set CE = INC = 1, and to decrease CE=1 and INC=0.

    Note: that these changes will take place with the rising edge of CLK input.
  • VAR_LOAD: The VAR_LOAD method is suitable for both COUNT and TIME mode usage of the delay line. You can change the Tap Delay Value in the same way as in VARIABLE mode with the CE and INC inputs, or with the CNTVALUEIN and LOAD inputs.

    Note: The procedure to calculate the value to update the delay line is different for IDELAY and ODELAY, and different for TIME and COUNT mode.

    In our configuration, we selected the VAR_LOAD. 

UPDATE_MODE

This attribute determines when the delay value is updated by the IDELAYE3.

  • ASYNC: Update independently of the received data.
  • SYNC: Update with the DATAIN or IDATAIN edge.
  • MANUAL: Requires two LOAD pin assertions to update the delay value

Based on the primitive component guide, we used the ASYNC mode to minimize logic complexity.

SIM_DEVICE

We set this attribute to ULTRASCALE_PLUS, matching our FPGA family.

CASCADE

As the maximum delay of 1.1 ns per IDELAYE3 primitive is sufficient for our design, we set this parameter to NONE. For larger delays, providing cascading configurations are recommended.

Other attributes

When instantiating the IDELAYE3 primitive, you will see another 2 attributes:

  • IS_CLK_INVERTED
  • IS_RST_INVERTED

These attributes were configured based on the logic requirements. We tied IS_CLK_INVERTED LOW and IS_RST_INVERTED HIGH.Here is the final configuration for our component: 

‍

Driving the EN_VTC pin

The EN_VTC pin handling depends on the DELAY_TYPE and DELAY_FORMAT settings, therefore an FSM (Finite State Machine) RTL is appropriate to handle this configuration.

Here are the steps to take into account when dealing with the EN_VTC signal with DELAY_TYPE = VAR_LOAD and DELAY_FORMAT = TIME:

  1. Wait for IDELAYCTRL RDY output to be asserted.
  2. De-assert EN_VTC pin.
  3. Wait for at least 10 clock cycles.
  4. Read CNTVALUEOUT and check if an update is necessary.
  5. Set the new Tap Delay Value by writing it on the CNTVALUEIN input port.
  6. Wait at least one clock cycle and tie HIGH the LOAD pin for one clock cycle.

Note: If there are multiple updates, wait at least 5 cycles and repeat the last 2 steps with the 5 clock waiting until you reach the desired value.

  1. Wait at least 10 clock cycles
  2. Assert EN_VTC pin
Figure 4: IDELAY3 interconnection

‍

Fine-tuning of incoming signals

Once all the components are in place, the ADC Device provides an internal custom pattern option configurable via SPI, through the TEST_IO register, to properly calibrate the signals is recommended to use the following patterns: 

  1. Midscale and Pos/Neg Full Scale Pattern as starting point.
  2. User Patterns that alternate most of the bitfields between 0’s and 1’s transition. For example:
    Custom Pattern 1: 0xAAAA_5555 & Custom Pattern 2: 0x5555_AAAA.
  3. Ramp pattern that acts as a final check. 

For last here is a small description of each register map: 

Note: For more information about this configuration, check the ADC (ISLA216P25) datasheet.

Below, we present the results of an experiment with a sine wave signal before and after calibration. 

Initially, the signal exhibits significant jitter, as expected, due to the absence of manual calibration (Figure 5). The calibration process involves transmitting various test patterns, as described earlier, to detect bit errors and their respective positions, adding the correspondent delays. 

Figure 5: ADC with a sinewave before calibration
Figure 6: ADC with a sinewave post-calibration

As you may see, the sine wave significantly increases its precision and shows as in the Figure 6. However certain values still need appropriate compensation, which will be the focus of the next blog.
We'll explore how to address this through a software-based solution and eventually achieve the following results:

Figure 7: ADC with a sinewave post-calibration with SW Layer applied

‍

Conclusion

This article introduced how to configure an IDELAYE3 instance and its practical applications. We also shared best practices for addressing timing challenges in high-speed systems, particularly when working with ADC data.

‍

Key Lessons Learned

  • Custom patterns should toggle all bits to ensure thorough testing.
  • Adjusting delays for individual bits may require iterative tuning to avoid introducing errors in adjacent bits.

‍

References

Developed board:

Xilinx Documentation: