We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 62267

7 Series GTX/GTH - Merging protocols within a GT Quad


Situations can occur where you are restricted to using more than one protocol over a single transceiver quad. 

These situations can occur due to MGT availability, or less commonly due to other reasons such as board layout optimization. 

This Answer Record contains a high level guide on implementing multiple protocols on a single transceiver quad to address most of the situations that might be encountered.


It is important to understand the architecture of the transceivers and their I/Os in order to determine what needs to be modified and what does not in this particular instance.

Please refer to (UG476) for additional information on this subject.

First lets take a look at what needs to be worked with, the transceiver quad for 7 Series GTX/GTH:


As seen above a GT quad consists of four transceivers, four CPLLs and a single QPLL.

Each quad is associated with two input differential clocks and their associated buffers, IBUFDS_GTE2_X. The diagram also lists the possible clock routing for one of the input reference clocks.

The same routing options can be used by the other reference clock as well, however they cannot overlap with the first reference clock routes.

This is where the major distinction is in terms of whether two protocols will be able to populate on the same quad.

Determining if your two protocols can be used in a single transceiver quad:

Considerations for merging two protocols within a single transceiver quad:

a) Protocol PLL usage

Since there are a limited number of PLLs per quad, particularly in the case of the QPLL, it is important to note that a single PLL cannot be used by multiple protocols unless their reference clock frequencies are the same.

b) PLL shared resources

In situations where a single PLL is used to drive the transceivers for two different protocols, shared resources might need to be taken into consideration. For example a PLL power down or reset applied to a QPLL will affect clocks to all four of the transceivers.

c) Other design restrictions

1) The below Xilinx articles need to be taken into account before designing with the transceivers. Some might apply to a specific version of silicon while others will depend on the user design. The main requirement that needs to be adhered to in merging protocols is the BIAS_CFG requirement. Please see the following Answer Records for more details:

2) Certain IP cores are encrypted and therefore might not be editable for this modification.

Steps to merge protocol core files into one design:

To merge the protocols you will need to combine the respective core files with a few edits. Most if not all the edits will need to be done in the files where the clocking logic is coded. Other files might also need to be modified depending on the design, for example if you are using a single PLL for both protocols as noted in consideration "c" above. Make sure when editing that the above considerations are taken into account and adjusted for.

1) Core generation

Generate the respective core files for each of the protocols using the Vivado IP Integrator interface. Make sure that the above considerations are taken into account when selecting the core settings.

2) Merging the core files

Generally one core file set is left alone while the other is edited then added to the original unedited core design. One COMMON block is needed per quad. Remove the additional COMMON block.

3) Behavioral verification via simulation

It is important that the adjustments made so far in combining the protocols in the file are verified in simulation before being put into action on the board.


Below is an example behavioral simulation output detailing the combined X2 Gen 2(@ 5.0Gbps) PCI-Express and Aurora 64B66B @ 10.0Gbps core files for GTX Quad 116 of a Kintex-7 KC705 board.

As you can see, both core interfaces are up and linked with their respective link partners. The PCIe final LTSSM state has been reached and the Aurora link has no errors.


AR# 62267
Date 05/18/2018
Status Active
Type Solution Center
  • FPGA Device Families
  • Kintex-7
  • Virtex-7
  • Vivado Design Suite - 2014.3
  • Vivado Design Suite - 2014.2
Boards & Kits
  • Virtex-7 Boards and Kits
  • Kintex-7 Boards and Kits
  • Zynq-7000 SoC Boards and Kits
Page Bookmarked