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# 31968

Virtex-5 GTX RocketIO - Rate change implementation steps

Description

Many protocols have the capability to negotiate the speed at which they can operate in a specific system. The GTX RocketIO Transceiver has the ability to dynamically change the line rate, internal divider settings, and many other functions to facilitate such rate changes. Since each system might require a different set of changes, this purpose of this Answer Record is to specify the steps required to implement such a setup, regardless of the specific protocol being implemented.

Solution

The GTX RocketIO Transceiver has Dynamic Reconfiguration Port (DRP) functionality which allows user logic to make changes to the attribute space of the GTX at run time. This allows you, once you have determined what attributes will be different between any two implementations, to make the necessary changes without having to reconfigure the FPGA. To correctly implement rate change logic, these distinct steps need to be followed:

1. Determine which attributes need to be changed.2. Determine the correct DRP address and bits where these attributes are located.3. Implement read-modify-write logic to modify the required attributes via DRP.4. Reinitialize modified GTX_DUALs.

Step 1:The RocketIO GTX Wizard generates all of the correct attribute settings for a single line rate and should always be used to determine what the correct settings are for any system using the GTX Transceiver. This holds true even when attempting to determine which attributes need to be modified.

One possible method for finding the specific attributes that need to be modified is to generate first the base instance which the FPGA will be configured with. Once the Wizard has been used to generate the necessary wrapper and attributes, begin a new CORE Generator project in a new folder and generate a new wrapper with the same name, but with the settings for the new line rate. This allows the use of any of a number of file comparison programs to easily pick out those specific attributes that will be updated between the base rate and the rate to be switched to.

Once these attributes have been identified, document which attributes were different and the new values for each. Please note that some of these settings will appear different than the binary value that needs to be written to the DRP. Refer to Appendix D of the Virtex-5 FPGA GTX RocketIO User's Guide (DRP Address Map of the GTX_DUAL Tile) for notes on which attributes need to be converted to binary and how to correctly do so. This user guide can be found at:http://www.xilinx.com/support/documentation/user_guides/ug191.pdf

Step 2:Now that you have a list of attributes that need to be modified and to what values, it is time to determine which locations those attributes need to be written to. Again, Appendix D contains all of the information necessary to determine the addresses and specific bits therein which need to be modified. It is important to note that some attributes are spread across multiple addresses, potentially necessitating multiple interactions with the DRP for a single attribute.

Step 3:Once you have all of the attributes that need to be changed (their values and locations), it is time to write the logic to implement the writes.

As mentioned, each attribute can occupy multiple address locations and, conversely, any single address location can contain bits for more than one attribute. Consequently, it is necessary to implement a read-modify-write strategy so that only the bits that need to be modified are altered.

Step 4:When all of the necessary attribute changes have been made, issue a GTXRESET to ensure that all attributes take effect and follow whatever initialization steps are required by the user application. Initialization steps that will need to be re-run may include: