alexforencich
Receiving broken packets in U50
Hello,
I'm adapting AU50 design in my application and when I send packets with tcpreplay in the interface connected to the board with lower rates, the data is received correctly in rx_axis_tdata. When I increase for like 50,000 pps, I get correct data 99% of the time, but from time to time, it completely messes up some packet and breaks my logic. rx_axis_tvalid remains high and no error signal is asserted, even rx_axis_tuser indicates the data is correct for this broken packet.
Do you know why this happens or how to debug this issue properly?
Thank you, Eduardo
Collect 4 cross-triggered ILA captures, one each on the RX serdes interface, one on the RX XGMII interface, and one each on the RX AXI stream interface before and after the FIFO. You'll need two ILA instances due to the two clock domains. You should be able to use hierarchical references to connect the ILAs to the various signals so you don't need to edit the actual modules to bring out the signals. You may also need to write a bit of HDL to generate the trigger signal, I suggest a counter that increments when tvalid is high and resets when it is low or when tlast is high. Capture that on the ILA and trigger based on the counter value. Cross-connect the trigger in and out on the ILA so they can trigger each other. Get a decent capture of the problem with sufficient pre-trigger capture, export VCD files, and post those here.
I was actually triggering the wrong packet, data was correct for all packets. What was breaking our logic is that rx_axis_tvalid didn't go down between some packets. I solved this issue by removing rx_fifo. Now I am searching a way to determine the link status. Do you know any signal that might indicate whether it's up or down?
Thank you, Eduardo
The only thing guaranteed between packets is tlast = 1. I do not recommend removing the RX FIFO as then you will see any packets with invalid FCS that would otherwise be dropped out of the FIFO. Currently, the only signal that indicates link status is the block lock signal from the PHY, but even that is not 100% reliable as it is only looking at the sync headers and it can sometimes be fooled by the transceiver DFE when there is no input signal present. Improving that is on my to-do list.
Are the packets with invalid FCS signaled with tuser = 1? If that's the case it wouldn't be a problem for me.