Proper EMAC/PHY design: RMII Timing Documentation Missing

[mikea101]

EMAC RMII Timing Documentation Missing
I have combed through the ESP32 and WROOM documentation and cannot find any information on the EMAC signal AC specifications such as:

• Clock-to-out timing of outputs such as transmit data TXD[0,1], TX_EN
• Input setup/hold times for input signals such as RXD[0,1], CRS_DV
• Clock spec for the ESP32 clock output on GPIO16 and GPIO17 (LAN8710AI requires < 50PPM drift and < 150ps jitter, does the ESP meet this spec?)

I have looked in:

• Technical Reference Manual V4.0
• ESP32 Datasheet V3.1
• ESP32-WROOM-32 Datasheet V2.8

This detailed timing information is required to ensure that the EMAC to PHY interface is going to work properly across all variations of voltage, temperature, silicon process (and PCB layout). I’m doing an industrial design and the timing of RMII is a little tight at worst/worst/worst case (setup time) and best/best/best (hold time).
There are designs out there that seem to “work” at typical/typical/typical and yet probably don’t meet timing requirements at one or the other corner cases.

One of the most extensive EMAC forum threads is: https://www.esp32.com/viewtopic.php?f=12&t=1178

However, NEVER is there any due diligence about interface timing. People try things, get it working on one board, and then declare it working. However, at least some of these designs are going to be marginal and will FAIL in mass production. For example, Olimex has two different boards (ESP32-EVB, ESP32-GATEWAY) and both have completely different clocking. Even on the same board, the clocking changes over different versions!

The 3 main strategies seem to be:

1. Use an external 50MHz clock
2. Use GPIO16 as a 50MHz clock output for the PHY
3. Use GPIO17 as a 50MHz clock output for the PHY (clock inverted)

The Espressif ESP32-Ethernet-Kit_A schematic shows option 1 and option 3.
For option 3 (GPIO17) this seems to be an inverted clock and yet the RMII spec requires both PHY and EMAC to be driven by the same clock phase. So how can this work across all variations of voltage, temperature, silicon process???

Could an authority from Espressif please provide the PROPER method of clocking the EMAC/PHY that meets the timing specifications across all conditions? Alternately, please provide the actual timing specification for your EMAC interface.

Thanks!

[AloyseTech]

From the latest documentation (https://docs.espressif.com/projects/esp ... t-kit.html) :

Note

• GPIO2 is used to enable external oscillator of the PHY.

• GPIO0 is a source of 50 MHz reference clock for the PHY. The clock signal is first inverted, to account for transmission line delay, and then supplied to the PHY.

• To prevent affecting the power-on state of GPIO0 by the clock output on the PHY side, the PHY external oscillator is enabled using GPIO2 after ESP32 is powered up.

• The ESP32 pins GPIO16 and GPIO17 are not broken out to the ESP32-WROVER-B module and therefore not available for use. If you need to use these pins, please solder a module without SPIRAM memory inside, e.g. the ESP32-WROOM-32D or ESP32-SOLO-1.

The phase inversion might be used to correct the GPIO internal line delay.

[ryankurte]

Howdy, just echoing @mikea101's sentiment that it would be great to have more documentation from the espressif for this, both in the timing requirements for the ESP32 and the design / assumptions in the example board. I'm still working through this so, please let me know if I've made any errors and hopefully this will be useful to others in the same (accursed) boat.

In practice you're trying to resolve the timing constraints for the MAC and PHY, on the PHY side this is generally well detailed in the respective datasheet. For the IP101 this is:
- A TX setup time of 4ns prior to the positive clock edge at RMII_CLK_IN with a hold time of 2ns, resulting in a minimum phase offset of 2ns and a maximum of 16ns between RMII_CLK_IN and TXD[0|1|EN]
- An RX delay of 6-16ns (10ns typical) following the positive clock edge at RMII_CLK_IN, effectively phase shifting the RX signal to the next clock cycle with a setup time of 14-4ns and proportionate hold time of 16-6ns

Assuming:
- the RMII (clock and data / control) traces are of similar length so propagate at the same speed
- the clock frequency is 50MHz (ie. 20ns period), fixed for RMII, with no delay at the origin of the clock
- the propagation delay between the MAC and PHY is Δt, trace lengths are short enough for this to be (mostly) elided
- the delay between the ESP32 receiving a clock edge and setting an output signal is d (including shift due to clock skew)


If the clock is generated by the phy, this would appear to lead to:

- A setup time of 10ns (6-16ns) on RX at the ESP32, which is about the best one could hope for at 50MHz
- A delay of 2Δt + d on TX at the PHY, if 2ns < (2Δt + d) < 16ns it should be possible to meet the 4ns setup and 2ns hold requirements

If we assume d is small it seems it would be possible to delaying the TX signal by >2ns to meet the minimum hold time for the next cycle either by:

- increasing the RMII track lengths so Δt > 1ns for all signals
- introducing a delay in the clock line to the ESP32 (note this is bounded by reductions to the RX setup time for the ESP32)

This is how the ESP32-Ethernet-Kit is configured by default, however, we have been unable to reproduce this on other hardware. Our best guess is that the resistor on the clock line acts with the input pin capacitance to effectively delay the clock signal.


Where the clock is generated on the ESP32 and inverted to output to the phy (effectively a phase shift of 10ns) this appears to result in:

- A TX setup time of 10ns - d at the PHY, which would seem to be fine so long as d < 6ns to maintain 4ns TX setup requirement
- An RX delay of 10ns + 6ns + 2Δt to 10ns + 16ns + 2Δt depending on the IP101, effectively a phase shift resulting in a setup time between 4ns and -6ns (0ns nominal).

Assuming Δt is small this would appear to be workable where the PHY RX delay is >12ns, but not for typical values between 6-12ns. Again it should be possible to correct for this by adding a further shift which must be balanced with the TX setup time requirement. I haven't worked out how the ESP32-Ethernet-Kit achieves this yet.


With the available information it does not appear possible to design circuits to reliably meet the timing constraints, which leads to a few questions:

- What is the RX setup time required by the ESP32 (duration from valid RX data to rising clock edge)?
- What is the TX delay imposed by the ESP32 (duration from rising clock edge to valid TX data)?
- What is the capacitance on the EMAC_CLK_IN input and does sampling this result in a phase shift?
- Does this differ for external and internal clock modes?

It'd also be great to understand the intent behind the ESP32-Ethernet-Kit, the ESP32 reference manual and online documentation leave much to be desired when describing the EMAC.

Cheers,

Ryan

[ESP_Lvxinyue]

Hi,

We've added relevant information to ESP32 TRM: https://www.espressif.com/sites/default ... ual_en.pdf
Can you please check section 10.6.4 and let me know if it answers your questions? Thanks.