Solution

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 trn_reset_n is not deasserting. Use Chipscope or probes to check the following steps:

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 tranceivers, 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, so if PLL lock is lost then ensure its not because the transceiver PLLKDET is deasserted.

The following two sections describe more details of 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 intergrated block. This input is driven by phy_rdy_n which an output from the GTX wrapper file pcie_gtx_v6.v[hd]. If you are doing in-depth debug of why trn_reset_n is not asserting, and you have ruled out the higher level causes mentioned above, then its 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 tranceiver must also be high or 1. So the second step is to detemine if all of these signals (plllkdet) are high. RXPLLLKDET indicates the transceiver PLL frequency is within the predetermined tolerance. See the Virtex-6 GTX User Guide (UG 366) 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 teh TX synchronization process is complete. The TX synchronization module in the file tx_sync_gtp.v ensures mimimal skew between transceiver lanes.

Once you know which of these siganls 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 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 simplier 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 tranceiver must go high indicating 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 also check that the PLLLKDET is high.
4. The RESETDONE signal from the transceiver must be high indicating the RX portion of the transceiver is finshed 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