When I read eth_rx_frame_count twice with certain delays in between, the second value is sometimes the same as the first value.
This problem occurs around 40% of the time upon re-programming.
It occurs only during the first second after the link is established. Once the link has survived the first second, the Ethernet feature works fine.
In the failed run, eth_rx_er is asserted even if everything looks correct at the RX side.
It can be reproduced on the KC705 hardware demo design.
How can I solve this problem?
When Ethernet RX is stuck, a TX Ethernet Reset is required after the CPRI link gets into state 0xf to prevent the generation of runt frames.
This issue was fixed in the Common Public Radio Interface (CPRI) core in Vivado 2014.2.
For other CPRI known issues, see (Xilinx Answer 54473).
|Boards & Kits||