We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome,
Firefox,
Internet Explorer 11,
Safari. Thank you!

AR# 52028

Zynq-7000 AP SoC, GigE - Receive Path Lock-Up Might Occur When a Large Number of Receive Resource Errors are Generated

Description

Under heavy traffic of small sized Ethernet frames (~64 bytes) and when the controller encounters a large number of resource errors, there is a rare chance that the receive logic will completely lock down the receive path.

The controller can again receive frames after a flush and reset of the receive logic.

Solution

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.

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.

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.

If the statistics counter does not increment for two consecutive reads, then software should assume inactivity on the receive path and reset the Rx channel by writing a 0 and then a 1 to the gem.net_ctrl [2] register bit.