Sign in

Language

Documentation

Downloads enter keywords

Contact Us

Advanced Search

Innovation

Products

Applications

Support

Buy

About Xilinx

Connectivity
Register Sign In Help Xilinx User Community Forums Reply Topic Options Intellectual Property Connectivity

Board Virtex6 Aurora64b66b ML605 eval board, issue imple... Message Listing

Search Advanced Go To

Previous Topic

Next Topic

stanstanev
Visitor

Virtex6 Aurora64b66b ML605 eval board, issue implementing example design

07-15-2010 05:09 PM

Options

Posts: 3 Registered: 07-15-2010

Hi, I am attempting to run the Aurora64b66b example design on the Virtex6 ML605 eval board but I am having issues. -For the IP core generator wizard I selected the 1.25Gbps line speed for a single lane duplexAurora core. -I am using the GTX transceiver GTXE1_X0Y18 that has the RX and TX lines hooked up to SMAconnectors (J28 and J29) on the eval board. -The reference clock for the GTX is the 125MHz clock that is connected to the H5 and H6 pins of the GTX core. -I have simulated the example design and it works. TX_OUT_CLK starts up, then MMCM_LOCK gets asserted, then USER_CLK is generated, CHANNEL_UP gets asserted, and then TX starts sending and RX starts receiving user data. Here is the issue -When I implement the example design on the board it does not work. -TX_OUT_CLK starts up, but MMCM_LOCK (pll_lock_i) never gets asserted. MMCM_LOCK is the PLLLKDET signal from the GTX -As a result, USER_CLK doesn't get generated, and CHANNEL_UP never gets asserted. Any help would be greatly appreciated as I have struggled to find out the issue for over a week now.

Message 1 of 5 (896 Views)

Reply

hagmeier
Xilinx Employee

Re: Virtex6 Aurora64b66b ML605 eval board, issue implementing example design
07-16-2010 02:26 AM

Options

Posts: 96 Registered: 08-10-2007

This is a known issue related to the resets in the V6. An answer record will be publicised on this soon. I added the contents of it below. Please keep in mind that it is still preliminary, but it should help you to continue with your design for now.
The Virtex-6 GTX Tra ns ceiver ca n experience erra nt beha vior of the TX PMA clock if TXUSRCLK2 is not toggling when GTXTXRESET is a s s erted a nd de-a s s erted. The res ults of this beha vior a re tha t the interna l res et s ta te ma chine will not complete a nd TXRESETDONE will not a s s ert or tha t TXOUTCLK ma y be the incorrect frequency or a t lined. Commonly this occurs when us ing TXOUTCLK to genera te USRCLK a nd USRCLK2 with TXOUTCLK_CTRL = TXOUTCLKPCS, TXOUTCLKPMA_DIV1, or TXOUTCLKPMA_DIV2 a nd TX/RXPLL_DIVSEL_OUT = 2 or 4. There a re a number of wa ys to work a round this limita on: 1) A s ma ll a mount of logic ca n be a dded to puls e GTXTEST[1] twice to re-ini a lize the PLL output dividers . This requires logic clocked by a free running clock (MGTREFCLK ca n be us ed a er going through either a BUFG or BUFR) to genera te 2 puls es on GTXTEST[1] 1024 cycles a er TX/RXPLLLKDET a s s erts . Ea ch puls e s hould be 256 cycles long with 256 cycles between puls es .

2) If there a re mul ple pos s ible VCO ra tes for the ta rget line ra te, us e the VCO ra te tha t us es TXPLL_DIVSEL_OUT = 1. For exa mple, a t 2.5Gb/s the VCO ra te could be 2.5GHz or 1.25Ghz. The higher VCO ra te requires DIVSEL_OUT = 2 to genera te the correct da ta ra te (reca lling tha t the GTX tra ns mits da ta DDR). Plea s e us e the Wiza rd a nd the s upported VCO ra tes in the Virtex-6 FPGA Da ta Sheet to s ee if this op on is va lid for a pa r cula r s etup. If this method is us ed, GTXRX/TXRESET will need to be toggled (a s s erted a nd de-a s s erted) following congura on. 3) If a n MMCM is us ed to genera te USRCLK a nd USRCLK2 or if the reference clock is the s a me ra te a s TXOUTCLK, the free running reference clock ca n be us ed ins tea d of the PLL genera ted PMA clock. To do this , the reference clock ca n either be routed directly from the dedica ted IBUFDS_GTXE1 to the MMCM or the TXOUTCLK port on the GTX ca n be us ed with TXOUTCLK_CTRL = TXPLLREFCLK_DIV1/2. Since the reference clock is free running, this s olves the problem of USRCLK2 not toggling when the GTX is res et. 4) If USRCLK2 needs to be derived from a non-free running clock, a BUFGMUX ca n be us ed to s witch between a free running clock, s uch a s the reference clock, a nd the s ource for USRCLK2 once it is va lid. The free running clock needs to be toggling when the device completes congura on. Note: In ISE 12.1, the inverter between the TX/RXPLLLKDET port on the GTX a nd the MMCM ma y be op mized out s o a keep cons tra int s hould be us ed to ens ure the MMCM is res et correctly. For exa mple: NET *mmcm_res et KEEP or NET *mmcm_res et S
Message 2 of 5 (883 Views)

Reply

stanstanev

Re: Virtex6 Aurora64b66b ML605 eval board, issue implementing example design

Options

Visitor

Re: Virtex6 Aurora64b66b ML605 eval board, issue implementing example design
07-16-2010 11:22 AM

Options

Posts: 3 Registered: 07-15-2010

Thank you for the response. Although, I am not exactly sure that the solutions given are directly related to my issue. The problem is that TXOUTCLK was toggling out of the aurora block but the pll_lock_i (PLLLKDET_OUT) was never getting asserted. I think I figured out the source of the problem but maybe you can help me understand why this is happening. The following two lines are inside the aurora wrapper module PLLLKDET_OUT <= tx_plllkdet_i and rx_plllkdet_i; plllkdet_i <= tx_plllkdet_i and rx_plllkdet_i; While monitoring tx_plllkdet_i and rx_plllkdet_i on Chipscope I found out that only rx_plllkdet_i is asserted, while tx_plllkdet_i stays at 0. plllkdet_i is the input reset signal to an MMCM in the wrapper module. I made the following modifications to the code PLLLKDET_OUT <= rx_plllkdet_i; plllkdet_i <= rx_plllkdet_i; Now the system works!! CHANNEL_UP, and LANE_UP is asserted and data is transferred on the TX/RX lines. Please explain to me why tx_plllkdet_i does not get asserted (whereas rx_plllkdet_i does). And is that the source of the issue, or possibly something else?

Message 3 of 5 (871 Views)

Reply

killi
Xilinx Employee

Re: Virtex6 Aurora64b66b ML605 eval board, issue implementing example design
07-19-2010 03:38 AM

Options

Posts: 69 Registered: 12-02-2009

Your observations for the issue that you reported and proposed modifications are correct. Reason is Virtex-6 GTX configured to use RXPLL for TX GTX clock source as well. This is controlled by TX_CLK_SOURCE attribute. Refer 366 for more info. So, tx_plllkdet_i will not be asseted in hardware. This attribute is overridden by GTX_TX_CLK_SOURCE in _wrapper.v[hd] file. Hope this helps

Message 4 of 5 (844 Views)

Reply

stanstanev
Visitor

Re: Virtex6 Aurora64b66b ML605 eval board, issue implementing example design
07-19-2010 07:53 AM

Options

Posts: 3 Registered: 07-15-2010

Great, thank you for the explanation! I appreciate the prompt responses.

0
Message 5 of 5 (841 Views)

Reply

Message Listing

Previous Topic

Next Topic

Xilinx, Inc. Engineering Innovation

Company
About Us Investor Relations Xilinx in the News Xcell Journal Jobs at Xilinx

Support
Documentation Downloads Licensing Training Solution Centers

Connect With Us
Contact Us Connect with us on Facebook Follow us on Twitter Connect with us on LinkedIn Watch us on YouTube Join our Community Subscribe to Newsletter

Copyright 2011 Xilinx Inc. | Privacy | Trademarks | Legal | Site Map