12-04-2018 02:13 AM
I am encountering a problem that I have not been able to solve, even after careful reading of multiple design notes and forum posts.
I am implementing the a simplex Aurora 64b66b receiver Vivado IP on a custom Kintex 7 board with 1.2825 GHz line rate and high quality external reference clock of 160.312 MHz.
The problem is the following:
After board power up I run the necessary reset and initialization sequences. I see that the GT lock is up, the txoutclk is around 40 Mhz and usr_clk is around 20 Mhz (=1.28 GHz/64) and the mmcm_not_locked signal of the clock_module is low. So everything is as expected and as it should be. The only problem is that I do not get any lane or channel up, so the receiver is not properly working.
If then, without power cycling, I load again the very same bit file and run the very same reset and initialization sequences, suddenly my txoutclk is 160 MHz, same as the reference clock and the usr_clk is 40 MHz (double as expected) and the mmcm_not_locked is asserted. Also I see that the usr_clk is slightly changing the frequency, so it is not stable.
But the weird thing is, that not I get lane and channel up and in deed I receive correct data! The rate of soft errors is quite high, probably due to the unstable clock, but the receiver works.
I do not know why after power up with the (actually) correct configuration the receiver does not work but after reloading the bitfile I have different frequencies for txoutclk and usr_clock and then it works (although not perfectly stable).
This happens for me for (a slightly modified) example design and custom reset logic. I am taking care that when asserting resets the reset_pb is asserted way before the pma_init and when deasserting resets pma_init is deasserted way before reset_pb.
I would be grateful for any tips and hits that lead to solving this problem.
12-04-2018 03:08 AM
I believe and assume your seeing lane and channel up issue on the hardware .
As the transceiver is the critical building block in the Aurora 64B/66B core, debugging and ensuring proper operation of the transceiver is extremely important can you let me know following information
what is status of
1. GT REFCLK and GT PLL
2. GT TX/RX RESETDONE
3.USER_CLK generation :
The transceiver generates txoutclk based on the line rate parameter. The user_clk signal is generated from txoutclk and the Aurora 64B/66B core uses it as an FPGA logic clock. Check that user_clk is generated properly with the expected frequency from txoutclk. If the user_clk frequency is not in the expected range, check the frequency of the transceiver reference clock and PLL attributes
4. MMCM Lock
Check Aurora 64B/66B cores expect all clocks to be stable. If clocks are generated using an MMCM, ensure the reset inputs are held High until the generated clock is stable. It is recommended to stop the output clock from the MMCM until it is locked. This can be accomplished by using a BUFGCE with the output clock where CE is driven by the MMCM lock output. If the MMCM_LOCK signal is toggling periodically, check if the TX_STARTUP_FSM is restarting and probe the signals and states of the FSM.
let me know you inputs
12-04-2018 08:51 PM
can you let me know your inputs on pervious reply .
12-05-2018 01:27 AM
GT REFCLK is always the correct and expected frequency and GT PLL LOCK is asserted in any case.
As I explained in my initial posting:
After board power up GT PLL locked is up, MMCM_NOT_LOCKED is low, so its correct. Also USR_CLK is 20 MHz, so its correct because 1.28/64 = 20 and TXOUTCLK is 40, so its correct. But I do not get lane up and channel up.
But after flashing again the same firmware, I get still GT PLL locked, GT Refclk is still correct, but MMCM_NOT_LOCKED is asserted. And USR_CLK is suddenly 40 MHz (double as expected) and TXOUTCLK is 160 MHz (4 times as expected!). So this is not correct. BUT, suddenly I get channel up and I can receive data. But the USR_CLK is very unstable and drifting so that I get a lot of soft errors!
I explained this in the initial post.
12-06-2018 12:31 AM
Also, I found out that in fact the MMCM_NOT_LOCKED signal from the clocking block as well as the SYNC_CLOCK which is generated there are not at all used anywhere in the example design!