Ethernet: Reduced Media Independent Interface (RMII)

• 2025 Feb 24
• Permalink
• 1838 words, 15 min read
• Series: Ethernet
• Tags: Embedded, Ethernet, Hardware, Network

One of the early complaints about MII was that it used too many pins. For a switch ASIC and external PHYs, it would require sixteen pins and two clock domains per port. For an eight port switch, that’s 128 pins and sixteen clock domains before power and other considerations. As silicon became cheaper, packaging started to be the dominant cost for low-end integrated circuits. In order to keep costs down, they needed a way to reduce the number of pins.

A group of silicon makers came together and formed the RMII Consortium to propose a new interface. As this was performed externally to the ethernet working group, this interface will not be found in IEEE 802.3. The standard needs to be sourced separately. As there is no clear restriction on distribution, a copy is mirrored locally: RMII Specification Rev 1.2.

Note: There is no relationship between RMII and RGMII. Implementations and concepts from one will not translate to the other.

Signaling (Clause 5) 🔗

In brief, RMII operates on a fixed 50 MHz system clock, sending two bits at a time instead of four. The RX_DV and CRS signals are merged into a combined CRS_DV while the error signals, RX_ER and TX_ER, are largely jettisoned. COL is derived in the reconciliation layer from CRS_DV and TX_EN. This derivation of the half-duplex signals from the receive and transmit enables will become increasingly common in xMII variants.

Transmit (Clause 5.5) 🔗

For 100 megabit transmit operation, RMII is largely equivalent to ordinary MII except by using two bits per clock cycle (di-bit) instead of four. As in keeping with Ethernet conventions, these bits are transmitted LSB first. For example, the example packet from the introduction (ends with FCS 69 70 39 BB) would be sent:

When the bus is idle, TXD is supposed to be zero. Non-zero values are reserved under Clause 9.1.

Receive (Clause 5.3) 🔗

For receive, CRS (Carrier Sense) and RX_DV (Receive Data Valid) are merged. This means that CRS_DV will assert asynchronously to REF_CLK and remain high prior to the appearance of received data on RXD. During this period of time, RXD will be zero until the PHY determines whether it’s a valid packet or not. If so, it will then immediately transition into sending the preamble.

If the PHY instead decides it is a false carrier, it will signal 10 on the receive interface instead.

As such, 00 should be interpreted as “MII bus idle, carrier sense high”; 01 as the beginning of the preamble; and the remaining two values as error indications.

Deassertion is a bit complicated and the notable difference between the two RMII revisions. In RMII version 1.0, CRS_DV will deassert normally at the end of the packet with the last di-bit. For example, the example packet from the introduction (ends with FCS 69 70 39 BB) would terminate:

However, it was considered a defect that the falling of carrier sense would be delayed until all data was clocked out of the PHY. So, in RMII revision 1.2, the CRS_DV deassertion pattern was changed to distinguish “MII bus active, carrier sense low” by toggling the CRS_DV line. For example, if carrier sense were to drop on the last two bytes of the packet:

The specification indicates that the first (low-order) di-bit of an MII nibble is to be low. The reconciliation layer can consider the carrierSense signal to be the logical AND of CRS_DV over the past two ticks while RX_DV is the logical OR of the two values.

As with the transmit interface, RXD is supposed to be zero when then the bus is idle (Clause 9.1). This is effectively required by the pseudo-asynchronous nature of CRS_DV.

10 Megabit Operation (Clause 5.3.2, Clause 5.5.2) 🔗

As the system clock is running continuously at 50 MHz, it cannot be reduced for 10 megabit operation. Instead, the system will simply hold the bus for ten cycles to provide a 10x reduction in datarate. For example, to send the value B (1011):

This also applies to the alternation of CRS_DV at the end of a packet in RMII revision 1.2.

Neither peer is required to align itself to the beginning of a packet. It is considered acceptable to simply sample every tenth cycle and ignore the other nine.

Clocking (Clause 5.1, Clause 7.4) 🔗

RMII uses a single, system synchronous clock domain. This clock is specified as 50 MHz ± 50 ppm (20 ns period) with a duty cycle between 35% and 65%. Clause 7.4 specifies a setup of 4 ns and hold of 2 ns for a total valid window of 6 ns (30% of the period), measured at the inputs of each component. All specifications are relative to the rising edge.

The RMII specification expects that REF_CLK is generated by the MAC or a shared system clock; however, some PHYs provide modes where the PHY will generate the reference clock. The later is generally intended for embedded applications where RMII is chosen to keep the pin count minimized. An example SDC would be:

# Requirements from RMII 1.2
set refclk_period 20
set rmii_setup 4
set rmii_hold 2

# Routing latencies of REF_CLK and the data signals
# TODO: Update these for your PCB
# - REF_CLK source to PHY (0 if sourced by PHY)
set refclk_phy_min 0
set refclk_phy_max 0
# - REF_CLK source to MAC (0 if sourced by MAC)
set refclk_mac_min 0
set refclk_mac_max 0
# - Routing from MAC to/from PHY
set rmii_min 0
set rmii_max 0

# Select Appropriate Clock Source
if $REFCLK_SYSTEM {
  # External Source (e.g. System, PHY)
  create_clock -name REF_CLK -period $refclk_period [get_ports REF_CLK]
  create_clock -name REF_CLK_sys -period $refclk_period
} else if $REFCLK_LOCAL {
  # Generated Locally
  # TODO: Update source and division to match logic
  create_generated_clock -name REF_CLK_sys [get_ports REF_CLK] \
      -source [get_pins */REF_CLK_GEN/C] -divide_by 1
}

# Input Constraints
set_input_delay -clock REF_CLK_sys \
    -min [expr {$rmii_min + $refclk_phy_min - $refclk_mac_max + $rmii_hold}] \
    [get_ports {CRS_DV RXD[*]}]
set_input_delay -clock REF_CLK_sys \
    -max [expr {$rmii_max + $refclk_phy_max - $refclk_mac_min - $rmii_setup + $rmii_period}] \
    [get_ports {CRS_DV RXD[*]}]

# Output Constraints
set_output_delay -clock REF_CLK_sys \
    -min [expr {$rmii_min + $refclk_mac_min - $refclk_phy_max - $rmii_hold}] \
    [get_ports {TX_EN TXD[*]}]
set_output_delay -clock REF_CLK_sys \
    -max [expr {$rmii_max + $refclk_mac_max - $refclk_phy_min + $rmii_setup}] \
    [get_ports {TX_EN TXD[*]}]

As CRS_DV asserts asynchronously, the receive path should include extra flip-flops to serve as a synchronizer for this signal.

Data Errors (Clause 5.5.3, Clause 5.7) 🔗

RMII does not have any equivalent to TX_ER. This means that the MAC cannot spoil a packet except to explicitly corrupt its FCS. It also means that transmitting control codes (e.g. LPI, PLCA) is impossible.

It does, however, provide RX_ER to indicate coding errors; however, it treats RX_ER as do-not-care when CRS_DV is low. As such, it also should not be used to indicate control controls.

Half-Duplex 🔗

Half-Duplex is the same as ordinary MII. The standard CRS signal is derived from CRS_DV as per the receive discussion. The standard COL signal is generated from AND’ing that derived CRS with TX_EN.

Link Configuration 🔗

The fundamental properties when configuring the interface, be it manually or through autonegotiation, are the following:

• Link Speed. As 10 megabit is generated by simply sampling at a reduced rate, it is essential that the MAC be aware of the negotiated rate. Failure to do so will result in complete failure of the link.
• Link Duplex. Half-duplex requires the implementation of CSMA/CD on the part of the MAC.
• Energy Efficient Ethernet. Due to the lack of TX_ER, LPI cannot be signaled in-band. If an RMII PHY supports LPI (e.g. TI DP83836), it will be controlled through the management interface.

These properties are not available in-band and need to be accessed through the management interface.

Crossover 🔗

Crossover in this context refers to connecting two devices of the same class (PHY or MAC) directly. For example, connecting the TX of one MAC directly to the RX of a second MAC without an intervening PHY, or using a pair of PHYs as a media converter.

For MACs using an external clock, crossing them over is fairly straightforward (assuming they follow the same RMII version). The only difficulty for PHYs is in the combined CRS_DV of the receive interface. This may raise prior to the availability of data and alternates at the end of the packet, both of which lead to a corrupted packet. Many PHYs, as a result, include a feature where an MII-compliant RX_DV can be provided instead.