If you have questions, want more information or need help, contact support:


FAQ-08: How to simulate ESIstream Serial interface with EV12AQ600 ADC?

Check this video to learn how to simulate the EV12AQ600 ADC ESIstream serial interface using Vivado simulator and testbench available in each ESIstream package (KU FPGA, Versal ACAP…).

FAQ-07: Which TCL script to use to generate an ESIstream Vivado project?

An ESIstream package can contain several TCL scripts. The number 16, 32 or 64 indicates the serialization or deserialization width used to configure the User data width parameter value of the Xilinx Gigabit transceiver IP, shown on the picture below.

The selection of user data width (16, 32 or 64) is a trade-off between minimum link latency, minimum logic resources, and frames rate in the FPGA.

  • The larger the user data width, the lower the frame rate. It allows to relax timing constraints in the FPGA.

  • The smaller the user data width, the less logic ressources are used.

  • The smaller the user data width, the shorter the latency of the link.

More details in ESIstream Xilinx package V3 - User guide section 1.2.2 Vivado projects Tcl scripts differences

FAQ-06: Why some HSSLs have a 2 ESIstream frames delay compare to other HSSLs after synchronization ?

Check your schematic or PCB layout. It is possible that the polarity of the HSSLs differential pairs have been swapped (inverted) to simplify the layout. In this case, the COMMA of the ESIstream Synchronization Sequence is inverted and it generates a shift of 2 ESIstream frames compared to other HSSLs at ESIstream receiver (RX) outputs.

It should be possible to compensate for this polarity swap in the FPGA, or in the ADC / DAC Gigabit Transceiver.

FAQ-05: How many logic resources does ESIstream RX IPs use ?

It depends on the implementation:

  • ESIstream RX IP running at a lane rate less than 6.25 Gbps can use a 16-bit user data path implementation in FPGA logic.

    • Using 16-bit implementation: 225 LUTs per lane & 231 FFs per lane with an output buffer using BRAMs.

  • ESIstream RX IP running at lane rate greater than 6.25 Gbps requires a 32-bit or a 64-bit user data path implementation in FPGA logic.

    • Using 32-bit implementation:

      • 444 LUTs per lane & 314 FFs per lane with an output buffer using BRAMs.

      • 495 LUTs per lane & 371 FFs per lane with an output buffer using shift registers instead of BRAMs.

    • Using 64-bit implementation:

      • 661 LUTs per lane & 527 FFs per lane with an output buffer using BRAMs.

Further optimization is possible using higher speed grade FPGA allowing removing some pipelining in the logic and so FFs utilization.

More details in the annex "Logic resources utilization, ESIstream_Xilinx_KU060_V2-2 package" and the table below in the ESIstream RX IP package documentation.

FAQ-04: How many logic resources does ESIstream need compared to JESD204B?

ESIstream uses few logic resource.

JESD204 v7.2 resource utilization link.

FAQ-03: Are there any limits in data rates supported by ESIstream?

The ESIstream protocol itself is not constrained, it runs well at lower data rates such as 3.125 Gbps and as low as 500 Mbps (e.g. shown on Microsemi RTG4 FPGA). Much higher data rates are supported by the latest industrial FPGAs from Xilinx and Intel as speed is determined by hardware & especially transceiver performances.

ESIstream is successfully implemented up to 12.8 Gbps on major platforms.

FAQ-02: Which FPGAs does ESIstream support?

ESIstream can be implemented on any FPGA integrating high-speed transceivers

• Xilinx (GTH, GTX, GTY...)

• Intel FPGA

• Microsemi FPGA

• NanoXplore FPGA

Transceiver specification determines the maximum achievable data rate.

FAQ-01: ESIstream - are there any risks with using it?

ESIstream has been developed with efficiency and simplicity in mind especially supporting Teledyne-e2v's traditional hi-rel markets. For reliable implementation, the right transceiver and good hardware design must be applied. As it is an open-source protocol, ESIstream allows users to modify and ruggedized protocol logic for harsh and high reliability environments.