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.
|Boards & Kits||