The controller can again receive frames after a flush and reset of the receive logic.
Impact: |
Minor.It is a rare occurrence and there is a workaround to reset the channel. |
Work-around: |
Software can monitor the Rx channel for inactivity and reset the controller. Refer to Work-around Details. |
Configurations Affected: |
Systems using the Ethernet controller. The issue can be reproduced at 1 Gigabit Ethernet mode, but can theoretically occur at all 3 speeds. |
| Device Revision(s) Affected: |
All. No plan to fix. Refer to (Xilinx Answer 47916) Zynq-7000 AP SoC Silicon Revision Differences Answer Record. |
Work-around Details:
Programming Steps:
1)For every resource error (receive buffer not available error), the software must flush a packet from the Rx channel as soon as possible, by writing a 1 to the gem.net_ctrl [18] register bit. This reduces the rate at which resource errors are generated under heavy traffic.
2)Software can monitor the Rx channel for non-activity on the receive path and reset the controller when needed. Use a timer to periodically (typically every 100 ms) check the statistic register, gem.frames_rx, for a count of successfully received frames.
3)If the statistics counter does not increment for two consecutive reads, then software should assume inactivity on receive path and reset the Rx channel by writing a 0 and then a 1 to the gem.net_ctrl [2] register bit.