04-24-2017 06:03 AM
I have a design which implements the 100 G CMAC core on a VCU108 board. If I insert a QSFP+ loopback module, the link comes up and I can send and receive packets correctly. If, however, I connect two boards together (running the same design) via a 100 G fibre, the link does not come up and the signal "stat_rx_internal_local_fault" is high.
Does anyone have any thoughts on how to debug this?
04-28-2017 01:21 PM
- Check QSFP+ and cable are rated for 100G
- Try issuing a core reset or gt rx datapath reset
- Try switching between LPM/DFE mode for the GT (this can be selected in the core GUI)
05-10-2017 07:47 AM
For the board to board testing is this two VCU108 boards connected together?
What is providing the GT refclk? If it is on board Si570, check that the GT refclk settings for the generated core match the Si570 clock frequency on the board. CAUI-4 refclk frequency defaults to 161.xMhz. The board clock defaults to 156.25, but core didn’t add 156.25Mhz clock support until 2017.1 release of core. If using an earlier version or different frequency from 156.25 clock will need to be reprogrammed via the system control documented in Appendix C instructions in the board PG1066. Also from a different design the board Si570 ref could be set to non default value.
Check stat_rx_block_lock, stat_rx_synced, stat_rx_aligned and stat_rx_hiber to see what is causing the local fault. Debug section in PG165 has some suggestions on what could be causing each.
07-25-2019 07:09 AM
I have the same problem with the following observation:
* stat_rx_synced_err is high
* stat_rx_synced is low
* stat_rx_internal_local_fault is high
The measured clock frequency of the gt is 156,253 MHz. (VCU 1525). Either the 300 MHz clock (I used as reference) is not working correctly or the 156.25 MHz clock is not perfectly ...
Can this cause the problem?
Anybody else who have solved the problem?
08-05-2019 11:49 PM
1. First, try near end loopback (GT PMA or external), make sure it works in the near end loopback test.
2. Try doing GT RXRESET in the IP core, if it can fix the issue
3. Run IBERT to test the link quality
09-06-2019 12:52 PM
Solved. In short:
1) with 156.25 MHz i was not able to activate AN in the IP core (timing violation)
2) but: AN of the communication partner (e.g. NIC or switch) MUST be disabled too.
after 2. i got a link immidiately.