2. Support
  3. AR# 5202: LogiCORE PCI - How does the LogiCORE interface handle single-cycle grants? Does the assertion of M_ADDR_N always mean that a transaction is starting?
  4. AR# 52028: Zynq-7000 SoC, GigE - Receive Path Lock-Up Might Occur When a Large Number of Receive Resource Errors are Generated

AR# 52028

|

Zynq-7000 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.
Device Revision(s) Affected:All. No plan to fix. Refer to (Xilinx Answer 47916) Zynq-7000 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 the receive path and reset the RX channel by writing a 0 and then a 1 to the gem.net_ctrl [2] register bit.

Linked Answer Records

Master Answer Records

Answer Number Answer Title Version Found Version Resolved
47916 Zynq-7000 AP SoC Devices - Silicon Revision Differences N/A N/A
AR# 52028
Date 05/25/2018
Status Active
Type Design Advisory
Devices
People Also Viewed