ESIstream example for the NI PXIe-6591R/92R and the NI PXIe-7902R

[TDavid1]

Overview

The example project attached to this document implements the ESIstream protocol on different NI High-Speed Serial Modules. ESIstream is an open, 14b/16b serial data transmission protocol, proposed by e2v. For more information refer to the protocol specification document located in the attached file, or visit www.esistream.com.

The ESIstream protocol transmits data between the transmitter and the receiver using one or more high-speed serial data lines and a SYNC signal. The protocol implements the link synchronization by transmitting a synchronization sequence on the serial data lines before transmitting the data. The synchronization sequence contains all the information required by the receiver to align to the transmitter and to decode the transmitted data bits. The link synchronization is initiated by the receiver: the receiver starts searching for the synchronization sequence in the data received on the serial data lines and sends the SYNC signal to the transmitter. When the transmitter receives the SYNC signal, it transmits the synchronization sequence and begins the data transmission. The receiver detects the synchronization sequence and begins the data reception. This example does not implement the SYNC signal. The ESIstream transmitter implemented in this example begins the transmission (of the synchronization sequence followed by the data) when it is started, without waiting for a SYNC signal. Achieving the link synchronization with the implementation used in this example requires the ESIstream receiver to be started first.

Hardware and Software Requirements

Hardware

• High-Speed Serial Module. The following modules are supported:
  • NI PXIe-6591R
  • NI PXIe-6592R
  • NI PXIe-7902R

Software

• LabVIEW 2016 (32-bit)
• LabVIEW FPGA 2016
• NI LabVIEW 2016 Instrument Design Libraries for High Speed Serial Instruments 16.1

Implementation

The supported high-speed serial devices are LabVIEW FPGA Targets, the ESIstream protocol is implemented on the FPGA.
The FPGA Target receives the data to transmit from the host, as a stream of 64-bit data elements. The data to transmit is stored in a FIFO implemented on the FPGA. Once the transmission is started, the synchronization sequence is transmitted on the high-speed serial lines, followed by the data provided by the host. The data provided by the host is encoded on the FPGA using the ESIstream protocol.
The data received on the high-speed serial lines is decoded by the FPGA using the ESIstream protocol, creating a stream of 64-bit data elements containing the received data bits only, without the protocol overhead. The data stream provided by the receiver is processed by an acquisition engine, capable to acquire finite length bursts from the received data stream. The acquired bursts are stored in a FIFO implemented on the FPGA until the host fetches them.

Key features

• Transmitting and receiving 64-bit data elements using the ESIstream protocol.
• Dynamically configurable device clocking (input clock source, input clock frequency, output clock frequency).
• Dynamically configurable line rate (supporting all the line rates listed in the device specification).
• Independent data transmitters and receivers per device port.
• The channels of a port are not independent, the channels of the same port transmit and/or receive data simultaneously.
• All channels and ports are configured for the same line rate.
• Transmit data clock shared between all ports: each port transmits at the exact same line rate.
• Separate receive data clocks per port: each port receives data using the data clock recovered from the data received on channel 0 of the port. Due to the clock data recovery, the receiver requires (random) data to be transmitted before the transmission begins (before the synchronization sequence is transmitted).
• If a port is receiving data, then channel 0 of the port must receive data.
• Independent FPGA FIFOs for buffering the data to transmit and the data received on the ports of the device.
• Automatic transmission of a PRBS sequence if no host provided data is available for transmission.
• Eye scan support.

For more information refer to the project documentation located in the attached file.

Reusable software components

Socketed CLIP: The socketed CLIP provides the connection between the high-speed serial data lines and the FPGA VIs. The socketed CLIP implements the logic required to reset and initialize the high-speed serial transceivers, to generate the transmit and received data clocks for the FPGA VI, but it does not implement any protocol specific features, the ESIstream protocol is implemented on the LV FPGA diagrams. The socketed CLIP provides the data bits received on the serial lines to the FPGA VI directly, without any modification. Similarly, the data bits provided by the FPGA VI to the socketed CLIP are transmitted directly on the serial lines, without any modification. You can use these CLIPs to implement custom high-speed serial protocols. When implementing custom protocols, make sure the transmitted data is “PRBS-like” (so the receiver can properly recover the data clock and the data) and make sure the protocol limits the running disparity of the transmitted data bits, that is, it transmits roughly the same amount of 0 bits and 1 bits (otherwise the received signal will be distorted because of the AC-coupling of the serial lines).

Dynamic device clocking configuration: The project contains a host library (Configure HSS Device Clocking.lvlib) containing code for the dynamic reconfiguration of the device clocking. Using this library you can dynamically change the input clock source used by the device, the input clock frequency, the frequency of the MGT reference clocks provided to the FPGA, the output clock frequency, and you can enable or disable the clock output. Note that this library cannot dynamically enable or disable the MGT_RefClk2 clock on the PXIe-6592R and it cannot be used to enable the CPRI output clock configuration on the PXIe-6592R. This library assumes that the FPGA Target has a register bus, implemented with the Instruction Framework, with access to the "Basecard Config Registers" subsystem. Refer to the description (context help) of the library for more information on how this subsystem can be added to an existing register bus. Also note that this library is password protected to avoid unintended modifications.

Dynamic line rate configuration: To configure any arbitrary line rate, you need access to the DRP ports of the GTXE2_COMMON and GTXE2_CHANNEL primitives instantiated by the socketed CLIP, and the socketed CLIP must support the dynamic switching between the QPLL and CPLL clocking of the GTX transceivers. You can use the Get Reference Clock Rate for Line Rate.vi to get a list of the MGT reference clock rates with which a specified line rate can be achieved, then you can use the Validate Line Rate Configuration.vi and the Apply Line Rate Configuration (no lock).vi to configure the line rate of the GTX transceivers assuming a fixed MGT reference clock rate. These VIs are located under the Device Control\SubVIs folder in the project tree. These VIs can be also used for socketed CLIPs supporting only CPLL or QPLL clocking (or both). The Configure Device Clocking and Line Rate.vi can be used to configure both the device clocking and the line rate.

64-bit LabVIEW support

This project uses some driver provided VIs and DLLs for the clocking configuration, which are available for the 64-bit version of LabVIEW starting from the 18.0 version of the Instrument Design Libraries for High Speed Serial Instruments.

[topkinschen]

Hi TDavid1

    Thanks for sharing. Great job done.

     I have some question , would you give me some help.

    In your post:

"Separate receive data clocks per port: each port receives data using the data clock recovered from the data received on channel 0 of the port. Due to the clock data recovery, the receiver requires (random) data to be transmitted before the transmission begins (before the synchronization sequence is transmitted)."

    Does this because you disabled 8b/10b encoding in GTX IP?

    I need to work without  8b/10b encoding to acquire high speed pulse signal. if I transfer a continues 12.5Gbps "0101...0101" on channel0 of port1( in order to recover data clock  from the data received on channel 0),   and use this recovered data clock to sample other high speed signals on channel1~channel3. can this be done. signals on channel1~channel3 pattern like this"00000000000011000000000000000000000..0000000011000000000000000000"

   thanks again.

[Chris.N]

Hi @topkinschen,

It sounds like you'd prefer to not have a protocol or any encoding implemented, and for that case it may be best to check out the IP in our MGT debug example: https://forums.ni.com/t5/Examples-and-IP-for-Software/NI-MGT-Debug-for-the-NI-PXIe-6591R-92R/ta-p/35... If you look at the socketed CLIP signals exposed to LVFPGA, we did leave the clock and data signals available to the user (even though they're not used in the LVFGPA diagram).  With LVFPGA code, you could get the raw control of the MGT data that you're looking for.  Keep in mind that the MGT debug example has VI's to dynamically change clock settings, so while your host code is configuring those, the clock domain for the MGT may not be stable and your code shouldn't be trying to access logic in that clock domain at that time.

Even with all this, though, I think you will have trouble with your application.  Both the TX and RX lanes are AC-coupled, and intended to be used with DC-balanced signals.  The pattern you described for pulses are not DC balanced, which will cause the data on that line to drift away from center and be sampled at incorrect levels (due to the coupling capacitors).  To get an accurate sample of those short pulses, I believe you will need a DC coupled instrument.  

[topkinschen]

Hi @Chris

    Thanks for help.

    You said "Both the TX and RX lanes are AC-coupled",  Is the "AC couple" implemented by PXIe-6592 board OR by the FPGA GTX transceiver?

    Thanks again.

[TDavid1]

Hi @Topkinschen,

You are correct, the random data is required because in this example the GTX receiver CDR is enabled and no encoding is used. The CDR extracts the transmitter clock and data from the incoming data stream, and it requires "frequent" line transitions to lock on the incoming data (in this example the random data provides these line transitions prior the actual transmission). Using 8B/10B (or 64B/66B) encoding the encoded characters provide sufficient line transitions for the clock recovery (and also result in a DC balanced signal) regardless of the input sequence provided on the input of 8B/10B encoder, but since no 8B/10B encoding is used in this example, random data has to be transmitted before the actual data transmission. The "0101..." sequence may work for the CDR, but I would rather use a PRBS7 (or higher order polynomial) sequence as recommended by the Xilinx 7 Series FPGAs GTX/GTH Transceivers User Guide. Keep in mind though, that in this example the channel 0 provides only the user clock to the other channels in the quad, the CDR is enabled for the other channels as well, so the "randomness" is required on all channels. If you want to sample pulses only, then you may better disable the CDR (by driving the RXCDRHOLD port of the corresponding GTXE2_CHANNEL high). In this case the GTX receiver will use it's own internal reference clock to sample the incoming data. You may also want to consider disabling the RX Equalizer (auto adaptation feature).

With respect to the DC coupling: in case of the 6592R there are no capacitors between the FPGA MGT pins and the SFP+ port data pins, as per the SFP+ MSA the coupling capacitors are in the transceiver module (plugged into the ports). Just a side note: in case of the 6591R there _are_ capacitors on the board between the FPGA MGT pins and the front-end port pins.

As @Chris.N already pointed out, the patterns you would like to sample are not DC balanced, so it is not straightforward to sample such signals using the high-speed serial ports of the 6592R. You may need a custom SFP module with DC coupling (the industry standard is AC coupling), and you may also have to configure the GTX transceivers properly (refer to the Xilinx XAPP1096). I would also recommend using a DC-coupled instrument to sample such short pulses.

[topkinschen]

Hi @TDavid1

     Thanks for help. your info helps me.

[topkinschen]

Hi @TDavid1，@Chris

   I tried disable RX CDR ,but received data not right.

   Both of you mentioned "DC-coupled instrument", can you give me more details, which company make such instrument, what model...

   Great thanks.