2. 技术支持
  3. AR# 34894: Design Assistant for PCI Express - Using trn_reset_n to debug link training issues

AR# 34894

|

Design Assistant for PCI Express - Using trn_reset_n to debug link training issues

描述

This Answer Record, discusses how to use trn_reset_n to debug link training issues.

NOTE: This Answer Record is part of the Xilinx Solution Center for PCI Express (Xilinx Answer 34536).

The Xilinx Solution Center for PCI Express is available to address all questions related to PCIe.

Whether you are starting a new design with PCIe or troubleshooting a problem, use the Solution Center for PCIe to guide you to the right information.

解决方案

The signal trn_reset_n asserts for the following reasons:

  • Fundamental reset which is indicated by the assertion of sys_reset_n.
  • Loss of Transceiver PLL Lock.
  • Loss of the fabric PLL lock.

At a high level, follow these steps to debug the reason why trn_reset_n is not deasserting.

Use ChipScope or probes to check the following:

  1. Ensure that sys_reset_n is released or asserted high.
  2. Check that the transceiver PLLLKDET output is asserted.
    There is one output per lane.
  3. Check that the fabric PLL (PLL or MMCM) is locked.
    Note that the reset to the PLL is tied to the PLLLKDET output of the transceivers, and if that signal is not asserted then the PLL will not lock.

Note that loss of PLLLKDET will cause the fabric PLL or MMCM to be reset, resulting in lock being lost.
If PLL lock is lost, ensure that it is not because the transceiver PLLKDET is deasserted.

The following two sections describe in more detail what controls trn_reset_n.

For in-depth analysis look at these signals.

Virtex-6
 
In Virtex-6 there are various signals that feed into the control of trn_reset_n.

The Integrated block for PCI Express in Virtex-6 has an input called SYSRSTN.

This input acts as a fundamental reset to the integrated block.

This input is driven by phy_rdy_n which is output from the GTX wrapper file pcie_gtx_v6.v[hd].

f you are doing in-depth debugging of why trn_reset_n is not asserting, and you have ruled out the higher level causes mentioned above, then it is worth looking at signals in pcie_gtx_v6.v[hd].

For trn_reset_n to eventually deassert then phy_rdy_n must assert to 0.

This is controlled by the following logic:
 

always @(posedge pipe_clk or negedge clock_locked) begin

if (!clock_locked) begin

phy_rdy_n <= #TCQ 1'b1;

end else begin

if (~&plllkdet[NO_OF_LANES-1:0])
phy_rdy_n <= #TCQ 1'b1;
else if (local_pcs_reset_done && RxResetDone && phy_rdy_n && SyncDone)
phy_rdy_n <= #TCQ 1'b0;

end

end


Note the key aspects of this as shown in the Verilog version:
 
  1. The signal clock_lock must first assert high.
    The signal clock_lock is from the MMCM.
    If this signal is not asserting then focus on why is the MMCM found in the pcie_clocking.v file not locking.
     
  2. If the MMCM is locked, then the RXPLLLKDET outputs of each transceiver must also be high or 1.
    The second step is to determine if all of these signals (plllkdet) are high.
    RXPLLLKDET indicates whether the transceiver PLL frequency is within the predetermined tolerance.
    See the Virtex-6 GTX User Guide (UG366) for more information on the meaning of RXPLLLKDET.
     
  3. The next step is to focus on the local_pcs_reset_done, RXResetDone, and SyncDone signals.
    The meanings of these signals are:
    • local_pcs_reset_done - Output of counters to remove uncertainty between the toggling of the transceiver locks and the MMCM lock signals.
    • RXResetDone - This signal goes high when the transceiver RX portion is finished resetting and ready for use.
    • SyncDone - This signal goes high when the TX synchronization process is complete.
      The TX synchronization module in the file tx_sync_gtp.v ensures minimal skew between transceiver lanes.

Once you know which of these signals is not behaving correctly, you will be able to focus on the root cause of why trn_reset_n is not deasserting.

Also, remember that sys_reset_n must deassert first before any of the above signals will work correctly, and that this signal should be monitored to ensure it is not toggling or the causing the problem.

Spartan-6

In the Spartan-6 FPGA Integrated Block for PCI Express, the reasons for trn_reset_n not asserting are simpler than in Virtex-6.

For trn_reset_n to deassert, the following must happen.
 
  1. The sys_reset_n signal must deassert.
  2. PLLLKDET of the transceiver must go high indicating that the transceiver PLL frequency is within the predetermined tolerance.
     
  3. The signal clock_lock from the fabric PLL must go high.
    Note that PLLLKDET feeds into the reset of the fabric PLL so if clock_lock is not asserting, check that the PLLLKDET is high.
  4. The RESETDONE signal from the transceiver must be high, indicating that the RX portion of the transceiver is finished resetting and ready for use.

If trn_reset_n is not asserting, look at these four signals to determine why.

Each of these signals can be found in the top level file in the source directory of the generated core.
 
This file has the same name as your generated core.
 
Look for gt_pllkdet_out, sys_reset_n, clock_lock and gt_reset_done.

Revision History
08/13/2010 - Initial Release

链接问答记录

相关答复记录

Answer Number 问答标题 问题版本 已解决问题的版本
34873 Design Assistant for PCI Express - Debugging System Recognition and Link Training Issues Using trn_lnk_up_n and trn_reset_n N/A N/A
AR# 34894
日期 06/10/2015
状态 Active
Type 综合文章
器件 More Less
IP
People Also Viewed