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

XAUI v10.4 and earlier - Virtex-6 devices - TX lanes sometimes do not align successfully

Description

If targeting Virtex-6 devices on startup of the XAUI core, the transmit lanes sometimes do not align resulting in the link partner receiver not aligning.

Issuing a reset to the XAUI core can result in successful alignment of the link partner.

In the example_design.v/vhd wrapper file in the latest v10.4 core (and previous version using the MMCM), reset156 does not wait until after the MMCM has locked.

Also, the Tx phase alignment circuit could start before the MMCM has locked and the 156 userclk is valid.

Solution

To correct this, make the following changes:

Verilog:

1) To ensure that the clock input to the MMCM is valid, the MMCM reset should be driven by the GTX PLLLKDET.

In <core_name>example_design.v for the mmcm_txoutclk instantiation, change: 
 

      .LOCKED()    
       ...
      .RST(reset)


To:
 

      .LOCKED(MMCM_locked),
       ...
      .RST(~txlock)


2) To ensure that the 156MHz clock is valid, the 156_reset should be driven by the lock from the MMCM (the MMCM lock should also drive the DCM_locked signal on the 10GEMAC if used).

In <core_name>example_design.v, create signal MMCM_locked, make the above change to the MMCM instantiation, and change:
 

      reset156_r1 <= ~txlock;


To:
 

      reset156_r1 <= ~MMCM_locked;


3) Currently, the <core_name>_block.v contains the following that holds the tx sync reset until the PLL has locked, but not until the MMCM has locked:
 

  assign reset_txsync = mgt_reset_terms || ~lock;
  assign mgt_reset_terms = reset || mgt_powerdown_falling;


To incorporate the MMCM locked, change from:
 

  assign reset_txsync = mgt_reset_terms || ~lock;


To:
 

  assign reset_txsync = reset156 || mgt_powerdown_falling;



VHDL:

1) To ensure that the clock input to the MMCM is valid, the MMCM reset should be driven by the GTX PLLLKDET.

In <core_name>example_design.vhd for the mmcm_txoutclk instantiation, change: 
 

         LOCKED      => open,
        ....
         RST         => reset


To:
 

       LOCKED      => MMCM_locked,
        ....
         RST         => (not txlock)



2) To ensure that the 156MHz clock is valid, the 156_reset should be driven by the lock from the MMCM (the MMCM lock should also drive the DCM_locked signal on the 10GEMAC if used).

In <core_name>example_design.vhd, create signal MMCM_locked, make the above change to the MMCM instantiation, and change:
 

      reset156_r1 <= not txlock;


To:
 

      reset156_r1 <= not MMCM_locked;


3) Currently, <core_name>_block.vhd contains the following that holds the tx sync reset until the PLL has locked, but not until the MMCM has locked:
 

   reset_txsync <= mgt_reset_terms or (not lock);
   mgt_reset_terms <= soft_reset or reset or  mgt_powerdown_falling;


To incorporate the MMCM locked, change from:
 

  reset_txsync <= mgt_reset_terms or (not lock);

To:
 

  reset_txsync <= reset156 or mgt_powerdown_falling;

AR# 43215
Date Created 07/20/2011
Last Updated 12/19/2014
Status Active
Type General Article
IP
  • XAUI