02-20-2017 06:01 AM
Hi. I have been trying to get the example project for the transceivers IP (4 x 10Gbit/s) working for too long now.
I have all four transceivers plugged into the SFP+ connectors with cables as loop-backs, and I have verified the modules settings, i.e., I2C from SFP modules and then I've forwarded that data by UART to my GUI on my computer.
I see that the example has the reset state machines connected to the SOFT_RESET signal, as do some other components, too.
In a process I assert the SOFT_RESET high for a few clocks and then release it to low again so the FSMs will start, but they never finish. I use some LEDs to show different reset signals and I get the following results:
gt0_txresetdone_i = '1'
gt0_rxresetdone_i = '1'
gt0_rx_reset_i2 = '0' (Reset for BLOCK_SYNC)
gt0_tx_system_reset_c = '1' (Reset for FRAME_GEN, waits for TX_FSM to be done)
gt0_rx_system_reset_c = '0' (Reset for FRAME_CHECK')
gt0_reset_r = '1' (Reset for SCRAMBLER)
gt0_not_block_lock_i = '1' (Reset for DESCRAMBLER, output from BLOCK_SYNC)
But I also see that the TX and RX USRCLK2 is running, so the QPLL seems to reset.
So my question is, how do I assert the SOFT_RESET correctly? Or, why are the FSMs never ready?
What could I try out next? As it is now, it does not start because there are resets still high because the TX_FSM is not ready.
I've searched the forum and seems the .xci file is often requested, so I add it here, just in case.
02-23-2017 11:36 PM
02-24-2017 12:34 AM
It seems that the core has not a valid applied DRP clock if your applied refclk is present and you can confirm it. If you are using Xilinx provided VC709 examples like loopback connectivity, you can configure related bit file and follow setup requirements steps and check your board true board bring-up configuration and connections and of course clock system and then after returning back to your project, simulate transceivers part of your design for mentioned clocks. Soft reset applying is very usual reset signal and probably your problem is not related to this software reset.
02-24-2017 02:47 AM
It was generated by the wizard and it did provide a 100MHz DRPCLK. But if we look at Fig. 5-2 in the wizard pdf, a diagram of the simplified FSM, it shows that since the PLL has locked, maybe the USRCLK isn't stable as that is the next state.
02-24-2017 04:45 AM
According to your post:"But I also see that the TX and RX USRCLK2 is running, so the QPLL seems to reset.", when USRCLK2 is running USRCLK is running as well as USRCLK2(as mentioned in 7 series transceiver document) otherwise the tx fsm loops to observe a stable clock.
02-24-2017 05:06 AM
Yes, you are right, names just confused me, and also(TX/RX)USRCLK is the same as (TX/RX)USRCLK2.
They have the same source in the usrclk_source.vhd module.
03-06-2017 01:56 AM
This still isn't working. Now I have tried using a push button for reset just as suggested in pg168 but strangely the TX and RX clocks only runs while reset is high/I'm holding down the button, but still the FSMs never finish either. At least when I did a reset with a process the clocks managed to stay on without reset being high. My example doesn't even have EXAMPLE_SIMULATION as pg168 says, but I think in my file it is replaced by EXAMPLE_USE_CHIPSCOPE. Still, it doesn't matter either. Is there no one here that has had similar problems trying to run the example?
03-07-2017 03:09 AM
One thing I haven't mentioned is the examples always gives the implementation error Rule violation (NSTD-1) Unspecified I/O Standard, about DRP_CLK_IN_P and DRP_CLK_IN_N. But I have solved it by setting their property to IOSTANDARD LVDS. Is that correct or could it cause my problems? My plan was to enable the onboard Si5324 after I got the example working, but maybe its essential at this moment already? Or could it run just to show it is working as it is now?