03-17-2021 12:28 PM
I am trying to bypass the TX buffer in my design.
I have now access to these signals:
To start the transmitter buffer bypass procedure I send reset pulse on gtwiz_buffbypass_tx_reset_in(0), one clock cycle at tx_usrclk_2(0), and then I send a start pulse on gtwiz_buffbypass_tx_start_user_in(0), one clock cycle at tx_usrclk_2(0) .
I do this once the signal gtwiz_userclk_tx_active_out is high.
But, gtwiz_buffbypass_tx_done_out(0) remains low in my simulation.
Can you give more details on how to manage these four signals ?
03-18-2021 03:15 PM
I have a few comments/ideas that you can try. I will be referring to PG182.
All of the signals that you are referring to are listed there under Chapter 2.
To start the buffer bypass, the Tx reset process will need to be started prior.
Listed in Chapter 3: By default, the
reset helper block gtwiz_reset_tx_done_out output is wired to the transmitter buffer
bypass controller helper block gtwiz_buffbypass_tx_resetdone_in input. A rising
edge on this port automatically initiates the transmitter buffer bypass procedure.
Unless otherwise specified, the user should just enact the standard reset sequence, and it should be handled by the reset FSM. In the GT Wizard, did you specify any manual operations?
03-23-2021 10:48 AM
Even if the simulation did not work (gtwiz_buffbypass_tx_done_out did not rise after sending a pulse on gtwiz_buffbypass_tx_reset_in), I load the bitstream of my design in the FPGA (KCU105 + XM107 loopback card).
I connected a led to gtwiz_buffbypass_tx_done_out and I was able to see the led ON (meaning gtwiz_buffbypass_tx_done_out = '1' and gtwiz_buffbypass_tx_error_out = '0' ) and my serial link is working now.
So, I guess that the simulation time to see gtwiz_buffbypass_tx_done_out rise is long.
Do you have an idea of how long it takes to see this signal high after starting the TX buffer bypass procedure ?