The GTY/GTYP transceivers in Versal™ ACAP are power-efficient transceivers that support line rates from 1.25 Gb/s to 32.75 Gb/s.

Versal GTY and GTYP transceivers introduce new design flows and features that allow the transceivers to be highly configurable and tightly integrated with the programmable logic resources and integrated hardblocks of the Versal architecture.  

This blog is intended to help users experienced with UltraScale+ GTY design efficiently with Versal GTY and GTYP.  The guide will cover key differences between the UltraScale+ and Versal IP including:

• Design flow considerations focusing on what’s new in Versal compared to previous families
• GT and REFCLK Pin Planning
• Swapping GT locations within a Quad
• Clocking and Reset considerations
• APB3 usage instead of the DRP Port used in previous families.  Access through the VIO or Processor
• AXI bus usage
• Runtime IBERT
• Relevant example designs and additional Information to help you get started designing with Versal GTY

1: Gb/s
2: Combined transmit and receive
3: Max transceiver count found across multiple device families

Table sourced from https://www.xilinx.com/products/technology/high-speed-serial.html#overview 

There are two main design tools when targeting Versal ACAP:

• Vivado Tools Design Flow to accelerate high-level FPGA design and verification
• Vitis Environment Design Flow to build accelerated applications

Note: all Versal ACAP designs require the CIPS IP as it contains the PMC used to boot the device. For more information, see the Control Interface and Processing System IP Product Guide (PG352). 

IP Integrator versus RTL Design Flows

In Versal ACAP, GT components are updated from Common/Channel to a GT Quad granularity.  This makes things like quad sharing easier but requires designers to move from RTL instantiation of the GT Wizard IP to IP Integrator flows. 

When designing with Versal GTY/GTYP, it is required to use the GT Wizard within IP Integrator (IPI) to build system designs that use single or multiple GT Quads as well as GT sharing use cases. The design entry for custom IP that connects to GT Quads is through the Bridge IP, which instantiates, configures, and connects single or multiple GT Quad-based IP through Block Automation. 

To walk through an example that builds the following block, visit GTY Example Design with Multi-Rate Configuration or create the example through the Vivado CED Store.

Purely RTL based flows are discouraged.  If the preferred IPI flow (shown above) is not feasible, the below Versal GT flow is instead recommended.  This flow can be compared to the UltraScale/UltraScale+ RTL flow where users would generate the GT Wizard IP through the IP Catalog and then use the top-level IP wrapper to instantiate the GT Wizard as a sub-module.  In this UltraScale/UltraScale+ flow, the top-level IP wrapper included the GT Wizard and the reset IP helper block.  

RTL Flow: Create a top-level HDL wrapper from a Versal GT Wizard Block Design

• Within Vivado, click on Create Block design under IP INTEGRATOR
• Add the Versal ACAPs Transceivers Bridge IP
• Configure the IP and make sure to enable “Pass Through Mode”.  This option exposes all relevant signals of the GT Quad to the application interface.

• Run Block Automation
• Validate the design (Tools > Validate Design)
• Go to the Sources tab, right click on design*.bd and Create HDL Wrapper

• The top-level HDL wrapper can be used to instantiate the GT wizard as a sub-module
  • The top-level wrapper will include the GT Wizard IP + Reset IP helper + BUFG_GT modules

IP to GT Integration

Xilinx “parent” IP cores that use GT components do not integrate the GT components within the IP. This is to better enable GT sharing.

Instead, add a Xilinx parent IP within Vivado IP integrator, then use Block Automation to connect the TX and RX data paths of the IP to the GT Wizard. If Vivado cannot pack the parent IP with existing GT Quad resources, a new GT Wizard Quad Base (gt_quad_base) will be launched. The tools will also use optional usrclk, outclk, REFCLK, and reset connections. In general, the parent IP design flow is as follows:

1. Add the Xilinx IP (for example, Aurora64B66B, PCIe, MRMAC, etc) in the IP Integrator canvas.
2. Configure the IP for number of lanes, line rates and so on.
3. Click Run Block Automation.
4. Perform steps 2 and 3 to add more IP instances based on your system need. You can also perform step 2 repeatedly before doing step 3. You can choose which IP to run block automation for in the block automation GUI.

Block Automation supports up to three options for datapath interface connections. Not every Xilinx parent IP supports all three options.

1. Auto: Block Automation chooses the optimal usage of the GT Quad resources. The tool’s decision is based on its knowledge of available clocking resources and REFCLK and PLL sharing rules.
2. Start_With_New_Quad: Block Automation instantiates a New GT Quad and makes the data path, clocks, and reset connections.

3. Customized_Connections: Users chooses which Quad and channel to connect for each channel in the IP.

   Note: in the Customized_Connections option, the new GT Quad base IP is not instantiated automatically if lanes are not available. You will have to manually add the GT quad base IP in the canvas before clicking Customized_Connections.

For an overview of creating a design with GT IP, see the Xilinx IP – GT Quad Integration section in the Versal ACAP Transceivers Wizard LogiCORE IP Product Guide (PG331).

Unlike in UltraScale+, the Versal GT Wizard does not add physical locations for GT Quads. Instead, the I/O Planner or Hard Block Planner are used to add physical GT locations and GT reference clock pin locations. After running synthesis:

1. Open Synthesized Design → Layout → I/O Planning.
2. Open Package Pins tab and provide GT Quad and GT reference clock locations in the corresponding MGT banks.
3. Once all the I/O Ports are assigned, click Run Implementation to implement the design.

For information on the Hard Block Planner, see the Vivado Design Suite User Guide: I/O and Clock Planning (UG899). For information on the full GT quad layout and supported configuration options, see the Versal ACAP GTY and GTYP Transceivers Architecture Manual (AM002).

REFCLK Sharing

The GT wizard allows six logical reference clock inputs R0 – R5. Based on user selection across various line rates, wizard assigns the sorted-out reference clock ports (GTREFCLK0-5) and frequency to be driven on these clock ports. Summary.log in the gt_quad_base IP Sources area provides the expected frequency for each MGTREFCLK port, and a table of CONFIG vs protocol parameters. This is generated per gt_quad_base. Here is a sample Summary.log:

Refclk forwarding is automatic through IPS and implied through pin planning. As part of block automation, GT Reference Clocks (GTREFCLK) are shorted across GT Quads for simple designs. For complex designs using Multiple IPs with Multiple GT Quads, system designers can short GTREFCLKs based on its frequency information, Quad placement and clock availability on the board. To help system designers to make an informed decision, GTREFCLK summary is provided for the whole system in the IP Integrator canvas. This table can be obtained by entering the following command in the Tcl console.

Upon executing the command, gt_refclk_summary.txt is generated in the below path, and reports GT Reference Clocks, its frequencies and its source.

Constraints

• MGTREFCLK create_clock constraint is required before running Synthesis.
• APB3CLK create_clock constraint is required if this clock is not derived.

Here is an example:

Reset Controller

Versal GTY/GTYP incorporates a master reset controller in the Quad instance. Previously in UltraScale+ GTY, the reset state machine in the GTY transceiver only reset the TX channel or RX channel, and the reset helper block in the wizard added the sequencing with PLL resets.

Versal GTY/GTYP’s master reset controller automatically steps through the reset of the LCPLL, RPLL, ILO, TX programmable divider, RX programmable divider, TX channel, and RX channel. By default, the master reset controller is used, and is set by the Master Reset Enable selection in the GUI.

The bridge_ip includes a reset FSM that provides different reset coverage. The port names and their functions are similar to UltraScale+ GTY.

• gtreset_in: reset the PLLs and active data directions of transceiver primitives
• reset_tx_pll_and_datapath_in: reset the TX and its associated PLLs
• reset_rx_pll_and_datapath_in reset the RX and its associated PLLs
• reset_tx_datapath_in: reset the TX
• reset_rx_datapath_in: reset the RX

• The APB3 specification is very similar to our former DRP interface specification.  There are online sources that spell out the APB3 interface specification and protocol.  In the example below an RTL source is provided that will handle the protocol and interface.  The address and data can be provided easily with a VIO as shown below.

To write data, put the address and data on VIO 1 output ports 3 and 4 and then pulse the VIO 1 write port 2.  To read data, put the address on VIO port 3 and then pulse enable.  The data is presented on input port 0.

The full design is shown below.  A second VIO module is used to reset and monitor the design, typically with a reset_tx_pll_and_datapath reset followed by a reset_rx_datapath.  Link status in this case will show when the design is running successfully.

• If you wish to control the design through the ARM processor, the design shown below can be used.  It replaces the VIO instances with AXI_GPIO’s followed by x_slice blocks. 
  In this example the GT interface is through the same APB3 RTL module as above but it is also possible to use the AXI_APB3 bridge.  The bridge makes for a simple Memory mapped interface to the GT.  When driven from the RTL, the APB3 is the preferred interface.  There is no particular preference between APB3 and AXI when the ARM is the driver but APB3 seems to be the preferred interface in our Xilinx IP.  Note that APB3 is equivalent to the DRP port of previous generations and to do rate changes in Versal you use only the rate port and the attribute changes are done automatically so that the APB3 bus would not be used.

The design above uses the Memory Map shown below.

The xslice_4 setup for resetting the TX datapath and PLL is shown here:

So, combined with the memory map above, the code for resetting the TX datapath and PLL and reading the GT status bits is as follows:

To use the AXI bus on the GT instead of the APB3:

1. Add a processor to the board design.  Double click on it and hit next.

2. Click on PS PMC

3. Choose clocking and add a 100 Mhz fabric clock

4. Choose PS PL interfaces and select a master AXI interface

Click finish.  This should give you the address map below.

The full design is shown below.

The code below accesses the TX and RX output dividers and changes a 5 Gbps design to 2.5 Gbps. (other attribute changes could be needed but this changes the 0x0CA0 address.  You have the shift the 0x0CA0 APB3 address from the Architecture manual 2 places left to get the AXI address.

The IBERT hooks are built into all Versal designs that contain GTs.

To use the IBERT simply click “create links” and the functionality from there is very similar to the UltraScale+ IBERT. 

In the example below I have selected to create 2 links and set it for internal loopback.

To see BER statistics you need to select PRBS data:

When that is done you should see the link and BER.

Run Serial I/O scans as normal.

Xilinx documentation is organized around a set of user design processes to help you find relevant content for your design needs.

Visit these Design Process Hubs for complete information related to your design process:

PlatoAi. Web3 Reimagined. Data Intelligence Amplified.
Click here to access.

Source: https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Differences-Designing-with-UltraScale-GTY-and-Versal-GTY-GTYP/ba-p/1271972