There're a couple of common practices you should consider while developing a high-speed serial related application
Sometime, the application needs to move more data than a single serial link(lane) could fit. To achieve a higher data rate, the channel bonding technique uses a “parallel way” to bind multiple serial lanes together for data transmission as if it were transmitted over a single link.
Many high-speed serial protocols support multiple lanes transmission, and channel bonding is one of the key techniques underneath. It is quite common to see protocol configurations like Serial RapidIO x4, or Aurora x8 lane, etc and they all need multi-lanes support. Note that the multi-lanes support costs multiple MGTs on either transmitter end or receiver end. The following picture highlights some IPs' configuration that support multiple lanes:
NI High-Speed Serial Instruments only expose limited MGT resources so we need to be careful of dealing with the lane configuration for the protocols you are about to work with.
The suggestion is to read Transceiver Lane and Quad Mapping section for each module from NI High-Speed Serial Instruments User Manual and the IP documents that Xilinx or other vendor provide to make the configuration fit your application best.
Example 1: Module selection
If you want to develop an application that leverage Serial RapidIO x4 on PXIe-6592. First check out the Quad mapping of PXIe-6592:
There are only four GTX available on PXIe-6592. Theoretically Serial RapidIO x4 requires four GTX and the total number of GTXs available can meet the requirement. However, the quad mapping table shows each GTX is accessible from different connector (PORT0…3). This means user can only access one GTX from each physical port. This turns out a more realistic way to implement a Serial RapidIO x4 is to use other High-Speed Serial Instruments like PXIe-6591 or PXIe-7902 that expose four GTX per port.
Example 2: IP configuration
If you want to develop an application that leverage Aurora 8B/10B x4 on PXIe-6591. First checkout the Quad mapping for PXIe-6591:
Each one of PORT 0 and PORT 1 has four GTXs located on different Quad. You need to make sure the GT Selections on Xilinx® LogiCORE™ IP Aurora 8B/10B configuration dialog maps exactly to the quad mapping.
To use PORT 0, GTXQ3 must be selected and configured.
Reference clock routing
Reference clock is critical for MGT to work correctly. You should be very carefully dealing with the reference clock choosing or even routing. Please refer to Reference Clock Selection and Distribution section of Xilinx: 7 Series FPGAs GTX/GTH Transceivers and Xilinx: UltraScale Architecture GTY Transceivers. If reference clock and its routing are not designed correctly you may end with compilation failure or even the MGT failing to work.
Example 1: Sharing clock between protocol IP
Most of the high-speed serial protocol IPs Xilinx provide has an option that whether user needs to include everything in core or split out the “shared logic” if multiple IPs are included in design. This is what it usually looks like:
Assume you want to develop an application on PXIe-7902, and it will include two Xilinx LogiCORE™ IP Serial RapidIO Gen2, one IP(SRIO0 on the below diagram) should be connected to PORT0, the other IP(SRIO1 on the below diagram) should be connected to PORT2. If the IP on PORT0 is configured as Include Shared Logic In Core, and another IP on PORT2 is configured as Include Shared Logic In Example Design, it’s possible that user wire the IP in the design like
Due to the Quad mapping of PXIe-7902,
GTXs on PORT0 and PORT2 are on different Quad, so it is very likely you would get an Xilinx compilation error like
ERROR: [Place 30-140] Unroutable Placement! A GTXE_COMMON / GTXE_CHANNEL clock component pair is not placed in a routable site pair.
This solution is to redesign your reference clock routing scheme or configure both IPs as Include Shared Logic In Example Design.
Serial data pins of MGT are always differential. But sometimes the differential data traces on PCB are swapped due to certain reason. MGT is able to be configured to aware this polarity reverse and correct it within the transceiver. If polarity of those data pins are not configured correctly, the data transmission will be problematic.
For NI High-Speed Serial Instruments modules that need to correct polarity, NI provides access to MGT polarity info through Socketed Component-Level IP (CLIP) interface. Below is a table describing part of PXIe-7902 Socketed CLIP signals:
You can find a full list of Sockted CLIP signal descriptions on NI High-Speed Serial Instruments User Manual for each module. If your protocol IP needs to know the MGT polarity, you should wire the corresponding GtxRxPolarity_in or GtxTxPolarity_in signals, in HDL level, directly to the IP's corresponding polarity control signals.
For example, if you want to create a Xilinx LogiCORE™ IP Serial RapidIO Gen2 x4 protocol on PORT2 of PXIe-7902, to set the correct polarity, you may need to have the following port mapping in your HDL that directly instantiate the protocol IP.
gt_txpolarity_in => GtxTxPolarity_in(11 downto 8), -- indexes for GTX on PORT2
gt_rxpolarity_in => GtxRxPolarity_in(11 downto 8), -- indexes for GTX on PORT2
In the above VHDL code snippet, GtxtxPolarity_in(11 downto 8) and GtxRxPolarity_in(11 downto 8) are direct wiring to corresponding Socketed CLIP top level signals. (11 downto 8) are the indexes for GTX accessible from PORT 2 of PXIe-7902. But sometimes you need to do some trial to find the correct index sequence.
Debugging issues related to MGT requires deep understanding of digital design. To help customer with MGT debugging, NI develops NI MGT Debug Toolkit that could ease some pain during the debug process. It contains features like
- Eye Scan utilities to complement the Eye Scan IDL
- Custom bitfile that expose port signals and attributes of the MGTs
- GTX Toolkit for interacting with the Xilinx MGTs on the NI 6591R/6592R modules
- Several examples that illustrate how to use the Toolkit effectively
Note this toolkit only works for PXIe-6591/6592. For other modules, currently customers have to develop leveraging their VHDL and FPGA experience. Some functionality is available in the Aurora streaming example shipping with LabVIEW, such as the eye scan.
Another choice for debugging is to export your project to Vivado® Design Suite. The following debug work can be done within Vivado IDE.