Other Parts Discussed in Thread: AM3352
I am working on a design that is based around the AM3358. We have been trying for some time to get gigabit Ethernet working but haven’t had any luck. We are using Microchip’s/Micrel’s KSZ9031RNX PHY, and it talks to the AM3358 over RGMII. When we do throughput testing with a 1 Gb link, we often only see ~1 Mbps. With a 10/100 link, we see speeds in line with what we’d expect. Our thought is that something is off with our skew values that is causing issues at gigabit speeds.
Though it would have been helpful to find this in the datasheet prior to laying out and assembling boards, we found a TI forum post that recommends 1.8 ns of delay on the receive and transmit clocks; this post uses an AM3352 (instead of our AM3358) but the same PHY as us.
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/334206/1166129
With that target in mind, we modified the PHY skew registers to get as close as we could, taking into account our actual trace lengths on the board (see the spreadsheet below). On the receive side (inputs from the perspective of the processor), the PHY already has 1.2 ns default delay on the receive clock pad. So, we added 0.6 ns delay (via the registers) to reach the recommended 1.8 ns. On the transmit side, there isn’t a default delay, so we had to adjust the skew for the clock, data, and control lines (+ skew for clock and – for data and control). With the max delays in both directions, we could only get to 1380 ps with the registers, so we had to add ~420 ps to our clock signal on the board. This took the form of a 3.1” wire that was added to the board as shown below.
Even with these changes, we are still seeing many retries in the transmit direction. The receive path doesn’t have this problem.
Could an apps engineer:
- Confirm 1.8 ns delay is the recommended delay.
- Suggest next steps for debugging this problem.
Thanks!
Matt
