Overview

Using a Xillyp2p IP Core mainly involves the following steps:

  • Choosing the physical link and its attributes: MGT, SERDES or plain wires. Also, whether the link is bidirectional or unidirectional. More about this below.
  • Creating an IP core at the IP Core factory, and setting up its streams for application data. Briefly explained below, and detailed on a separate guide.
  • Generating and downloading the custom IP core.
  • Creating an FPGA project and instantiating the different modules. A complete example for setting up Xillyp2p with a GTH transceiver on AMD (Xilinx) Kintex Ultrascale is available. Or the same for Kintex-7 and other 7-series FPGAs.
  • Solving possible problems with the physical link. Refer to this guide discussing this for help and suggestions.

Choosing the physical link: The basics

Xillyp2p is primarily intended to work with a multi-gigabit transceiver (MGT) – referred to as GTX, GTH, GTY etc. in AMD / Xilinx terminology. The physical connection between the MGTs can be implemented in various ways: via PCB traces, copper cables, or even fiber optics spanning several kilometers.

Xillyp2p's bandwidth efficiency is typically around 97%. Hence the bandwidth of the physical link needs to be slightly higher than the sum of data rates that are needed for application data at any given time. The IP core's application interfaces consume link bandwidth only when transmitting actual data; when idle, they impose no load.

Hotplugging is supported: The physical link can be connected or disconnected at any time. Such events cause a temporary pause in data transmission, after which communication resumes automatically.

Although Xillyp2p is intended for MGTs, it can operate over any physical link that uses a serializer/deserializer (SERDES) interface – even a single-bit link, with or without DDR. The only requirement is that the link is represented as a parallel word (a bit vector) containing the bits transmitted or received serially, with bit 0 corresponding to the first transmitted or received bit (LSb first). This convention is practically standard for MGT and SERDES units.

Note that for a bidirectional link, the clocks used with the parallel words in both directions must be equal (within a defined tolerance). Hence a bidirectional link with asymmetric data rates is achieved by choosing different parallel word widths.

The receiving MGT or SERDES is not required to resolve the word boundaries of the transmitted word: The Xillyp2p IP core on the receiving side can be fed with a parallel word that is bit-shifted in relation to the word that was submitted for transmission on the other side. A bit-slipping mechanism is not required on the MGT or SERDES either. The Xillyp2p IP core automatically detects and aligns the correct bit boundaries internally.

In summary, a plain SERDES is all that is required. When an MGT is used, it should act as a simple SERDES: All encoding / decoding functionalities should be turned off, as shown in this example for a GTH transceiver (or this example for a GTX).

Bidirectional vs. unidirectional physical link

Xillyp2p supports operation over a unidirectional physical link, which can simplify the system design and reduce costs when application data only needs to flow in one direction.

That said, a bidirectional link is recommended when possible. This allows Xillyp2p's protocol to transmit acknowledge packets and request retransmissions as necessary. In contrast, if a unidirectional physical link is chosen, the application data streams are halted before faulty data has a chance to reach the application logic. It's then the application logic's duty to request the resumption of the data flow. This possibility is acceptable when errors on the link are rare enough.

When the application data flows only in one direction, the physical link in the opposite direction can operate at a much lower bandwidth by choosing a narrower parallel word width. A bandwidth of 5% in the opposite direction is more than enough.

Despite the said above, a unidirectional physical link can be superior in certain situations, for example with security-related applications, where the physical link is used a safeguard for preventing leakage of data in the opposite direction.

Other options for the physical link

As the physical link is represented with a parallel word on both sides, it's also possible to connect the two Xillyp2p IP cores using a group of physical wires between the two FPGAs. In this use case, the parallel word itself constitutes the link.

In other applications, the parallel word connected to the Xillyp2p IP core can be the input or output of a gearbox or other logic that either accepts or conveys parallel data words. With such applications, there is not always a parallel word ready at the output of the gearbox on the receiving side on every clock cycle. Likewise, the gearbox on the transmitting side may not be ready to accept a new parallel word from the Xillyp2p IP core on every clock cycle.

To accommodate this, Xillyp2p provides two optional input ports:

  • "out_ready", on the transmitting side, which is asserted by the gearbox when there is a valid parallel word ready for transmission.
  • "in_valid", on the receiving side, asserted by the gearbox when it supplies a valid word received from the physical link.

In any case, note that if alignment of parallel words can't be guaranteed by the receiving gearbox (or other logic), the least significant bit must be transmitted and received first.

Creating an IP core at the IP Core factory

The IP Core Factory is a web-based tool that enables users to define, generate and download Xillyp2p IP cores (as well as other types of IP cores) according to specific requirements. Once the definition of an IP core is completed, the user submits it for generation. A netlist of the IP core can be downloaded soon thereafter as a ZIP file (typically within a few minutes).

More precisely, the ZIP file contains two complemtary IP cores, one for each side of the physical link (core A and core B).

The IP core that is downloaded is fully functional and production-ready, suitable for integration in real projects, and can be used indefinitely for evaluation purposes. A simple subscription to the service is required for the capability of generating and downloading IP cores, which only involves submitting a valid email address.

The configuration of an Xillyp2p IP core is done into two steps:

  • Configuration of the IP core's target FPGA family and the physical link's parameters: The physical word's widths, clock frequency and clock tolerance are defined, as well as possibly more refined features.
  • Configuration of the application data streams. The interface for each such stream is a standard FIFO on both sides, allowing the application logic an independent data flow for each stream. Virtually any number of independent application data streams can be defined.

For more information about the definition of an IP core, refer to this guide.

Unlike other IP cores offered by Xillybus, there is no sample project ("demo bundle") for Xillyp2p, as the needs for each real-life project vary considerably. It's hence up to the user to create two FPGA projects, one for each side, and instantiate the IP cores as necessary. That said, there are two complete design examples available, one for AMD Ultrascale FPGAs and another for Kintex-7 and other series-7 FPGAs.