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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor creuenx
Visitor
1,015 Views
Registered: ‎09-06-2018

TXOUTCLK output stop after reconfguration

Jump to solution

Dear support,

 

We are currently facing an issue using a Kintex 7 160. The design uses the GTX output transceivers with dynamic reconfiguration. 

 

The FPGA reprograms itself on time to time, using Program_b pin. After a few reprogramming the TXOUTCLK do not restart properly.

We have setup a hardware test bench to get more information on this issue. According to our tests, the GTX initialization run properly but after a few clock cycle the TXOUTCLK stop. Attach are a few screenshots from our hardware test bench.

 

Thank you for your help.

 

Regards,

 

Xavier CREUEN

cpll_recover.jpg
cpll_reset.jpg
overview.jpg
overview_cpll_reset.jpg
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
930 Views
Registered: ‎03-30-2016

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @creuenx

Thank you very much for sharing your information.

 

1. Your Vivado version is too old. We do not recommend to use this Vivado version on a new design.

 

2. Our recommendation is to migrate to the latest Vivado version.

    Easier said than done. Yes, we know that it requires a lot of effort,

    But we strongly recommended this option, since we have a lot of parameter/attributes update on our GTX since 2015.*

   

3. If you cannot migrate to the latest Vivado version, could you try the following experiment on your board.

    (a) Could you please set your TXCLKOUT_BUFG_INST (bufg) disable at default setting (after configuration)

    (b) Enable your bufg, only after you can ensure that TXOUTCLK is stable.

         ( for example implement a counter using TXOUTCLK, wait 1us, then enable your bufg )

 

Best regards

Leo

7 Replies
Xilinx Employee
Xilinx Employee
949 Views
Registered: ‎03-30-2016

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @creuenx

 

1. What is your Vivado version. Are you using the latest version ? (2018.1 or 2018.2)

2. Do you have multiple boards ? Are these behavior seen on all boards ?

3. I can see that your CPLL is locked. Perhaps it is not CPLL issue.

    And I can also see your TXRESETDONE is asserted.

4. How do you supply TXUSRCLK/TXUSRCLK2 of your GTX ? ( Could you share a simple block diagram for this ? )

5. If you are supplying TXUSRCLK/TXUSRCLK2 from MMCM.

    Could you please confirmed that your MMCM is locked ?

 

Thanks & regards

Leo

 

0 Kudos
Visitor creuenx
Visitor
943 Views
Registered: ‎09-06-2018

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @karnanl

 

Thank you for your answer.

 

1. What is your Vivado version. Are you using the latest version ? (2018.1 or 2018.2)

 

The design is running done on Vivado 2015.3. But the GTX IP is custom made. So it already implement the retry on TXRESET

 

2. Do you have multiple boards ? Are these behavior seen on all boards ?

 

We have a few boards running 24/7 and it happen on some of those. I can't tell if there is boards that do not failed but there is more than one board which failed.

 

3. I can see that your CPLL is locked. Perhaps it is not CPLL issue.

    And I can also see your TXRESETDONE is asserted.

 

Yes, every signal coming from the GTX seems to be right but the clock stop toggling after a while. Right now, I've implemented a work around for this failure. From my point of view, this issue is similar to the one we've before implementing the timeout on the TXRESETDONE (added by Xilinx in GTX IP on vivado 2016.4). Except that the CPLL toggle long enough to assert the TXRESETDONE before failing.

 

4. How do you supply TXUSRCLK/TXUSRCLK2 of your GTX ? ( Could you share a simple block diagram for this ? )

 

There is nothing tricky on that side, I supply gtxrefclock with an external oscillator. And my TXUSRCLKs are directly connectect to the txoutclk.

 

TXCLKOUT_BUFG_INST: bufg
port map (
I => gt_txoutclk,
O => clk_sys_i
);

clk_sys <= clk_sys_i;
gt_txusrclk <= clk_sys_i;
gt_txusrclk2 <= clk_sys_i;

 

5. If you are supplying TXUSRCLK/TXUSRCLK2 from MMCM.

    Could you please confirmed that your MMCM is locked ?

So no MMCM in the way.

 

I hope those answer will help you in finding a correct solution.

 

Regards,

 

Xavier CREUEN

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
931 Views
Registered: ‎03-30-2016

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @creuenx

Thank you very much for sharing your information.

 

1. Your Vivado version is too old. We do not recommend to use this Vivado version on a new design.

 

2. Our recommendation is to migrate to the latest Vivado version.

    Easier said than done. Yes, we know that it requires a lot of effort,

    But we strongly recommended this option, since we have a lot of parameter/attributes update on our GTX since 2015.*

   

3. If you cannot migrate to the latest Vivado version, could you try the following experiment on your board.

    (a) Could you please set your TXCLKOUT_BUFG_INST (bufg) disable at default setting (after configuration)

    (b) Enable your bufg, only after you can ensure that TXOUTCLK is stable.

         ( for example implement a counter using TXOUTCLK, wait 1us, then enable your bufg )

 

Best regards

Leo

Visitor creuenx
Visitor
876 Views
Registered: ‎09-06-2018

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @karnanl,

 

Thank you for your answer, I applied your last suggestion.

 

The clock buffer is disable and txuserrdy is low after reprogramming. Once the CPLL is locked the system checks its clock consistency for 3,5 us. If the clock is running it enable the clock buffer and assert the txuserrdy.

I haven't had any issue for more than 48h after I implemented this fix.

 

Thanks again.

 

Xavier CREUEN

Visitor creuenx
Visitor
868 Views
Registered: ‎09-06-2018

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @karnanl,

 

I'm wondering. Does this problem is present in all the Xilinx 7 series family or only on the Kintex 7?

 

Thank you,

 

Xavier CREUEN

0 Kudos
Xilinx Employee
Xilinx Employee
844 Views
Registered: ‎03-30-2016

Re: TXOUTCLK output stop after reconfguration

Jump to solution

Hello @creuenx

Thank you for sharing your result. I am glad to hear that.

 

If you are using the latest Vivado and your board powerrail are clean, I do not think you will get this problem.
I saw similar transceiver behavior on a few customer systems. (using old Vivado 2015.*)

 

1. One customer agreed to upgrade to 2017.4 and everything works fine.
   We have a lot of parameter tuning in our transceiver since Vivado 2015.* ,
   This is the main reason we encourage customer to use the latest Vivado.
  
2. Then I saw similar problem with customer that cannot upgrade their Vivado for some reason.

    The problem occured on some of their boards.
    I suspected the root-cause was their board power-rail ( it does not meet our requirement ), but they cannot fix it too.
    We figure this workaround when doing some modification on their system reset sequence.
    We found that this problem does not appear if we delayed the TXOUTCLK.
    They reported no issue using this workaround. ( But our recommendation is to use the latest Vivado )
  
Best regards
Leo

0 Kudos
Newbie vladimirspb
Newbie
175 Views
Registered: ‎05-29-2019

Re: TXOUTCLK output stop after reconfguration

Jump to solution

We have exactly the same problem. We use Kintex 7 GTX, Vivado 2018.2, Aurora64b66 IP core in Simplex RX mode. The problem appears in cases:

1) after few power-up cycles (approx every 10-50 cycle);

2) after few boot cycles (using "Boot from configuration memory device" Vivado option);

3) after few resets of GTX trancsceiver using VIO (pma_init signal of aurora IPcore).

In all cases behaviour is the same - there is no TXOUTCLK. TXOUTCLK is going to CLKIN of MMCM inside aurora IP core, and also it comes outside throught ODDR buffer to check it with oscilloscope.

Aurora64b66 is configured to 6.25G baudrate and works fine (we can see channels up and stable data exchange with TX-side of another FPGA), except cases when there is no TXOUTCLK.

I suspect there is wrong reset in IP-core, because all signals of TX-side of GTX used is only TXOUTCLK. Signals like TXRESETDONE and others are not connected. Therefore reset of TX-side of GTX is implemented incorrectly. Am i right?

gtx_tx.png

 

Another information: CPLL in all cases is locked. In cases when TXOUTCLK stops, it generates about 3600-3700 cycles before. After that it disappears. Sometimes these 3600-3700 cycles of TXOUTCLK is enough for MMCM to lock and system if working fine (while there is still no TXOUTCLK).

Also I see that there is no QPLL COMMON reset in the aurora example's support module:

common.png

Is that correct?

0 Kudos