11-07-2018 10:31 PM
I am having an issue with the Manual Phase alignment procedure with the 7 Series GTP Phy (Artix-7). Procedure is outlined on page 102 of the GTP datasheet, multi-lane mode (https://www.xilinx.com/support/documentation/user_guides/ug482_7Series_GTP_Transceivers.pdf). I am attempting to complete the phase alignment in actual hardware (which is confirmed functional - I am able to correctly send data via the FPGA GTP to a sink device, however I am getting the occasional bit error, which I believe may be related to the failure of the phase alignment. The protocol I am using dictates that the TX Buffer bypass must be enabled, so I believe the phase alignment must be done.
When I trigger the phase alignment process, the 'TXPHINITDONE' never asserts - please see below waveform, captured with an ILA.
- Used both the generated FSM from the GT wizard as well as written my own
- Confirmed that the GTP is not in reset (reset_done is asserted for all 4 lanes)
- Check the forums for similar issue, doesn't seem to be any of this specific case
- Double-checked my clocking topology of the GTP PHY, it is correct, with all BUFG etc in place.
11-07-2018 11:05 PM
did you set TXPHALIGNEN to high on all lanes?
does phase alignment work in simulation?
03-25-2019 12:53 AM
Sorry for lengthy delay,
I have tried simulation and gotten the same results (see attached image) the delays_reset_done assertion is fine, however I never receive a 'phy init done' from the PHY.
I have configured the simulation to be the same as my hardware setup - reset through to GTPCOMMON configuration, I have confirmed the PLLs lock and the pll clock, line rate etc are all correct.
03-25-2019 12:54 AM
03-25-2019 12:56 AM
03-25-2019 09:26 AM - edited 03-25-2019 09:40 AM
It works for me with the default artix settings changed to disable the TX buffer and use manual alignment. I get TXPHINITDONE going high at 172 us. Attach your *.xci file and I'll try it.
...Checkling further, I notice that the gt0_txphinitdone never goes high. I'm looking at the TXPHINITDONE right at the GTP channel. Could this be your problem? It looks like the manual alignment block resides in the example design but not all the signals are sent to the top level. I do see it working though for both phinitdone and phaligndone.
03-25-2019 05:11 PM
Thanks for the quick reply,
I did not use the wizard to instantiate the wrapper and GTP channels etc, I am instantiating the 4 GTP modules directly (and the instantiation is at least mostly correct - at least it is functional in hardware, I am able to correctly drive a display panel with a test pattern), so I am looking at the TXPHINITDONE directly at the GTP channel.
I will have a go at using the Wizard and setting up a testbench and see if I get TXPHINITDONE being asserted. If this is the case there must be some discrepancy between my implementation/instantiation and what the Wizard produces.
Will keep you posted,
03-25-2019 05:14 PM
03-26-2019 01:16 AM
@roymI have managed to get TXPHINITDONE asserting with the Xilinx example GTP design (generated from the 7 Series FPGA Transciever Wizard). Unfortunately I am not able to reproduce the results with my design - I thought it was my method of bringing the GTPs out of reset, so I integrated the Xilinx GT initialization FSMs ('gtwizard_0_TX_STARTUP_FSM' and 'gtwizard_0_TX_MANUAL_PHASE_ALIGN') into my project and had them bringup the GTPs (which they did, successfully) however the phase align module still fails to get TXPHINITDONE assertion.
I compared the configuration of the GTPs between my project and the Xilinx example project, they look pretty much identical..
03-26-2019 01:25 AM
Wizard wrapper is recommanded for you. it gets everything settled.
for the manual instantiation flow, which is not recommanded, you can check following items.
TXBUF_EN = FALSE
TX_XCLK_SEL = TXUSR
TXOUTCLKSEL = 3'b011 or 3'b100 to select the GTP transceiver reference clock as the source of TXOUTCLK
TXPHDLYRESET = 1'b0
TXDLYBYPASS = 1'b0
03-27-2019 06:30 PM
Hi @borisq ,
Got it working - the generics / ports you mentioned in your previous reply were already the same, however there were a bunch of other generics that did not match in my instantiation of the GT vs the one produced by the Wizard - basically what I did was to modify my instantiation to be the exact same as the one produced by the Wizard and it was all fine.
I agree - GT Wizard is the way to go,
Thanks for all your help.