UPGRADE YOUR BROWSER

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

Design Advisory for Artix-7 FPGA GTP Transceivers: RX Reset Sequence Requirement for Production Silicon

Description

This answer record covers the RX reset sequence requirements for the Artix-7 GTP Transceiver Production Silicon.

Solution

The required sequences to follow for issuing GTRXRESET, RXPMARESET, or RXRATE in the Artix-7 GTP Production Transceivers are documented below. These reset sequences can be also used on General ES silicon but are not required.

These sequences are implemented in the wrapper generated by 7 Series FPGAs Transceivers Wizard v2.5 in the "ISE 14.4.1 Device Pack" or ISE 14.5/Vivado 2013.1 tool version. The reset sequences are added to v1.4 of the 7 Series FPGA GTP Transceiver User Guide (UG482).  Note, special care is needed in simulation.  Please see the "Additional Requirements for Simulation" section below.

In these sequences, "user_*" denotes user input. This signal was previously connected directly to the GT primitive. It will now trigger an alternative reset sequence as described below.
"gt_*" denotes connection to GT primitive. The following diagram indicates where this new sequence fits in.
"DRP wr" denotes the function of performing a DRP write to address 9'h011. The exact DRP transaction is not shown.


1) GTRXRESET:

The following reset sequence must be followed when the user wants to perform GTRXRESET.


 

Steps:

  1. User triggers a reset request by asserting user_GTRXRESET.
  2. Set and hold gt_GTRXRESET High. This will cause gt_RXPMARESETDONE to go Low.
  3. Issue DRP write to the GTPE2_CHANNEL primitive, DRP address 9'h011, and set bit[11] to 1'b0.
  4. In order to ensure only bit[11] of DRP address 9h'011 is modified, it is best to perform a read-modify-write function.
  5. Upon DRP write completion and user_GTRXRESET detected as Low, set and hold gt_GTRXRESET Low. If user_GTRXRESET remains asserted upon completion of the DRP write, continue to assert gt_GTRXRESET until user_GTRXRESET is Low.
  6. Wait for falling edge of gt_RXPMARESETDONE.
  7. Issue DRP write to the GTPE2_CHANNEL primitive, DRP address 9'h011, restoring the original setting for bit[11]. The completion of this DRP write must occur before gt_RXPMARESETDONE switches from Low to High. gt_RXPMARESETDONE will stay Low for a minimum of 0.66 us.

Notes:

  1. Make sure gt_GTRXRESET is output of a register.
  2. Make sure RXPMARESET_TIME is set to 5'h3. This should be the default setting.
  3. The sequence above will only simulate properly if SIM_GTRESET_SPEEDUP is set to FALSE. If SIM_GTRESET_SPEEDUP is set to TRUE, the above sequence must be bypassed.

2) RXPMARESET:

The following reset sequence must be followed when the user wants to perform RXPMARESET.


 

Steps:

  1. User triggers a RXPMARESET request by asserting user_RXPMARESET.
  2. Issue DRP write to the GTPE2_CHANNEL primitive, DRPADDR 9h011, and set bit[11] to 1b0.
  3. In order to ensure only bit[11] of DRPADDR 9h011 is modified, it is best to perform a read-modify-write function.
  4. Upon DRP write completion, set and hold gt_RXPMARESET High.
  5. Wait for RXPMARESETDONE to go Low.
  6. Issue DRP write to the GTPE2_CHANNEL primitive, DRPADDR 9h011, restoring the original setting for bit[11].
  7. Upon DRP write completion and user_RXPMARESET detected as Low, set and hold gt_RXPMARESET Low. If user_RXPMARESET remains asserted upon completion of the DRP write, continue to assert gt_RXPMARESET until user_RXPMARESET is Low.

Note: Make sure gt_RXPMARESET is output of a register.

3) RXRATE:

The following sequence must be followed when the user wants to trigger RX rate change via RXRATE.




Steps:

  1. User triggers a RX rate change request by changing user_RXRATE.
  2. Issue DRP write to the GTPE2_CHANNEL primitive, DRPADDR 9h011, set bit[11] to 1b0.
  3. In order to ensure only bit[11] of DRPADDR 9h011 is modified, it is best to perform a read-modify-write function.
  4. Upon DRP write completion, set gt_RXRATE to the value of user_RXRATE.
  5. Wait for RXPMARESETDONE to go Low
  6. Issue DRP write to the GTPE2_CHANNEL primitive, DRPADDR 9h011, restoring the original setting for bit[11]. The completion of this DRP write must occur before RXPMARESETDONE switches from Low to High. RXPMARESETDONE will stay Low for a minimum of 0.66 us.


Note:
The sequence above will only simulate properly if SIM_GTRESET_SPEEDUP is set to FALSE. If SIM_GTRESET_SPEEDUP is set to TRUE, the above sequence must be bypassed.  See the "Additional Requirements for Simulation" below.

GTP Attribute:

In addition to the required sequences above, the following attribute must be set correctly:

PMA_RSV2 = 32h'00002040.

Additional Requirements for Simulation

While these sequences are implemented in the wrapper generated by the 7 Series FPGAs Transceivers Wizard for proper hardware operation, users might see in simulation that the RXOUTCLK, RXUSRCLK, and RXUSRCLK2 run at the incorrect clock rates. 

For example, the clock rates are the GT rate divided by 16 instead of the correct divide rate of 20 for a configuration with 8b10b decoder enabled and an internal data width of 20.

To work around/bypass this behavior in simulation and generate the correct clock rates, step through the following:

  1. Set the DRP address (drpaddr_o) within the core_name_gtxreset_seq.v/.vhd to 2C. This DRP address is set to 11 by default which is the appropriate setting for hardware.
    A setting of 2C can be used as a work-around for simulation.
    For Verilog, see lines 251 and 324 in core_name_gtrxreset_seq.v.
    For VHDL, see line 244 in core_name_gtxreset_seq.vhd.
    Note: this needs to be defined for simulation only and not for hardware operation. For example, in Verilog define the 2C address within an `ifdef SIMULATION.

  2. Ensure that the EXAMPLE_SIM_GTRESET_SPEEDUP parameter is being pulled through the rtl hierarchery to the gt_channel level. This step is required in the GT Wizard example design.
  3. Ensure that the EXAMPLE_SIMULATION parameter is set to 1.

After these changes, the proper clock rates will be seen in simulation within ~20us of reset.

Revision History

02/14/2017Added Additional Requirements for Simulation
04/12/2013Updated the user guide version with the reset sequence
01/31/2013Initial release

Linked Answer Records

Master Answer Records

Associated Answer Records

AR# 53561
Date 02/17/2017
Status Active
Type Design Advisory
Devices
  • Artix-7
Page Bookmarked