Issues with KSZ9031RNX
Posted: Mon Dec 14, 2020 3:06 pm
Hi All,
I'm designed a board were KSZ9031RNX ethernet PHY was used in replacement of AR8035.
Our design worked smootly at 100Mbit rate but won't work reliably at Gibgabit rate!
In particular with a simple TCPIP stack including only an ICMP server on the XMOS we lost about 40% of ping from a directly connected PC.
Using loopback features and injecting / reading ethernet frames on XMOS side we verified that severe corruption happen randomly between PHY and XMOS, thus RGMII signals integrity or timing seems the issue.
From the following dicussion viewtopic.php?f=37&t=5778 I understood that many had success with KSZ9031RNX, thus would be great to know if you implemented RGMII track in a similar way as me, if you experienced similar issue and how was hard for you to tune RGMII signals delays (or other PHY features).
Attached a pdf including relevant schematic and PCB track...
As you can see from our schematic we omitted by mistake the series termination resistor on all RGMII signal except for TXCLK and RXCLK.
Do all you have series resistor on all RGMII?
We routed track very short, trying to equalize length of each set:
- RX signals are routed on TOP with length between 725 to 825 mils
- Due to pin disposition TX signals are routed trough BOT layer, all have 2 vias and length between 1125 to 1131 mils
- PCB is 4 layer and under TOP there is solid GND, whilst under BOT solid 3V3 plane
Do all you have solved the routing in a similar way?
Attached also the phy driver code, largely derived from github slicekit appnote code...
We implemented in the driver following delay settings:
+0.36ns on RXCLK to achieve in addition to 1.2ns natively present in KSZ9031RNX RXCLK path a total shift between RXCLK and RX signals of about 1.6ns
-0.3ns on RXD3 to better match delay of other lines (however I think this is not essential)
Effectiveness of driver setup is confirmed by scope capture (350MHz) I included in the folder that shown alignement as expected and good signal aspect, depite missing series resistor.
On the TX path we rely on the 2ns nominal delay included by XMOS ETH block with standard library settings.
We have poor accessibility to TX path signal, thus at the moment we check only TXEN vs TXCLK that looks as expected.
Have you probed RGMII signals with a high freq scope? Does your signals looks as mine?
Many thanks for any hits could point me in the right direction
Lorenzo
I'm designed a board were KSZ9031RNX ethernet PHY was used in replacement of AR8035.
Our design worked smootly at 100Mbit rate but won't work reliably at Gibgabit rate!
In particular with a simple TCPIP stack including only an ICMP server on the XMOS we lost about 40% of ping from a directly connected PC.
Using loopback features and injecting / reading ethernet frames on XMOS side we verified that severe corruption happen randomly between PHY and XMOS, thus RGMII signals integrity or timing seems the issue.
From the following dicussion viewtopic.php?f=37&t=5778 I understood that many had success with KSZ9031RNX, thus would be great to know if you implemented RGMII track in a similar way as me, if you experienced similar issue and how was hard for you to tune RGMII signals delays (or other PHY features).
Attached a pdf including relevant schematic and PCB track...
As you can see from our schematic we omitted by mistake the series termination resistor on all RGMII signal except for TXCLK and RXCLK.
Do all you have series resistor on all RGMII?
We routed track very short, trying to equalize length of each set:
- RX signals are routed on TOP with length between 725 to 825 mils
- Due to pin disposition TX signals are routed trough BOT layer, all have 2 vias and length between 1125 to 1131 mils
- PCB is 4 layer and under TOP there is solid GND, whilst under BOT solid 3V3 plane
Do all you have solved the routing in a similar way?
Attached also the phy driver code, largely derived from github slicekit appnote code...
We implemented in the driver following delay settings:
+0.36ns on RXCLK to achieve in addition to 1.2ns natively present in KSZ9031RNX RXCLK path a total shift between RXCLK and RX signals of about 1.6ns
-0.3ns on RXD3 to better match delay of other lines (however I think this is not essential)
Effectiveness of driver setup is confirmed by scope capture (350MHz) I included in the folder that shown alignement as expected and good signal aspect, depite missing series resistor.
On the TX path we rely on the 2ns nominal delay included by XMOS ETH block with standard library settings.
We have poor accessibility to TX path signal, thus at the moment we check only TXEN vs TXCLK that looks as expected.
Have you probed RGMII signals with a high freq scope? Does your signals looks as mine?
Many thanks for any hits could point me in the right direction
Lorenzo