March 20, 1998
Sponsored By:
TM
RMII TM Specification
1.0Overview and Architecture
新年感悟
This document compris a low pin count Reduced Media Independent Interface TM
贾立群
(RMII TM) specification intended for u between Ethernet PHYs and Switch ASICs.
Under IEEE 802.3u [2] an MII comprid of 16 pins for data and control is defined. In
devices incorporating many MACs or PHY interfaces such as switches, the number of
pins can add significant cost as the port counts increa. Typical switch products in the
industry today offer 12 to 24 ports in a single device. At 6 pins per port and 1 pin per
switch ASIC, the propod RMII specification would save 119 pins plus the extra power
and ground pins to support tho additional pins for a 12 port switch ASIC.
The purpo of this interface is to provide a low cost alternative to the IEEE 802.3u [2]
MII as specified in Clau 22 (hereafter referred to as simply “MII”). Architecturally,
the RMII specification provides for an additional reconciliation layer on either side of
the MII but can be implemented in the abnce of an MII.
The management interface (MDIO/MDC) is assumed to be identical to that defined in
IEEE 802.3u [2]. It is assumed that the reader is familiar with IEEE 802.3 [1] and IEEE
802.3u [2].
The RMII specification has the following characteristics:
1.It is capable of supporting 10Mb/s and 100Mb/s data rates
2. A single clock reference is sourced from the MAC to PHY (or from an external
source)
3.It provides independent 2 bit wide (di-bit) transmit and receive data paths
4.It us TTL signal levels, compatible with common digital CMOS ASIC process Rev. 1.21 Copyright AMD Inc., Broadcom Corp., National Semiconductor Corp., and Texas Instruments Inc., 1997
See the RMII Consortium Addendum for a complete list of RMII Consortium members
Application
2.0Application
The RMII specification has been optimized for u in high port density interconnect
devices which require independent treatment of the data paths. The primary motivator is
a switch ASIC which requires independent data streams between the MAC and PHY.
Design considerations for repeaters have not been accounted for in this specification.
While repeaters are not precluded from using the RMII specification, no validation of
the feasibility of their implementation has gone into the definition.
The implementation of the interface is assumed to be a chip-to-chip interface imple-
mented with traces on a printed circuit board. While other implementations are not pre-
cluded, no provision is made in this document for an expod interface (i.e. no
connector is specified).
3.0Design Goals and Trade-offs
In choosing the signaling for the RMII specification, the following criteria was applied:
1.Clock frequency of 50 MHz or less to minimize EMI and IC I/O requirements
2.Pin count independent of port density of the PHY
3.Single synchronous clocking
4.Reduction of required control pins
By doubling the clock frequency 4 pins are saved on the data path alone without sub-
stantially impacting ASIC I/O capabilities or requiring clock frequencies of 100MHz
which can cau significant system level challenges with respect to EMI performance.
Further, as long as Start of Packet and End of Packet timing information is prerved
across the interface, the MAC is able to derive the COL signal from the receive and
transmit data delimiters. Of significant impact is prerving Start of Packet information
in both 10 and 100 Mb/s operation since there can be a relatively large delta between the
asrtion of CRS and RX_DV on the standard IEEE 802.3u MII [2]. However, CRS can
be collapd together with RX_DV if some additional reconciliation assumptions are
made.
RX_ER is important for meeting Hamming Distance requirements. However, PHYs
have the possibility of introducing data replacement to guarantee that the CRC offers
adequate protection. Similarly, in switch applications there is no need for TX_ER since
a MAC will never generate errored data. The one ca where TX_ER is ud is with
repeaters that need to ensure propagation of errors. When ud in conjunction with data
corruption by the PHY on RX_ER, this becomes a non-issue.
A single synchronous reference clock for transmit, receive, and control is ud. This
corresponds to one output from the switch ASIC. Alternatively, the clock reference
could be sourced from an external device and may correspond to one input to the switch
ASIC. Each PHY provides a clock reference input. However, only one input is required
for multiple PHYs on a single IC. PHYs must provide enough buffering to account for
worst ca variation between local and recovered clock.
2RMII TM Specification Rev. 1.2
Conformance
综合办公室Rev. 1.2RMII TM Specification 3
Since data is not looped back from transmit to receive, the codes corresponding to
RXD[1:0] values and TXD[1:0] while TX_EN and/or RX_DV are de-asrted may be ud for out of band MAC/PHY signalling.
FIGURE 1.Signal Reconciliation Map
4.0Conformance
This document follows IEEE 802 conventions in that the word “shall” indicates a
requirement for conformance to this specification. The word “may” indicates a choice
or an allowable implementation. All other text is background, explanatory, or recom-
mendation.TX_EN TXD[3:0]TX_ER TX_CLK COL CRS RX_DV RXD[3:0]RX_ER
RX_CLK
RMII PHY I/F to MII PHY I/F CRS_DV RXD[1:0]REF_CLK TXD[1:0]TX_EN 50 MHz Reference Clock
(Sourced externally or from Switch ASIC)
TX_EN
TXD[3:0]
TX_ER
TX_CLK
COL
最难忘的一件事作文400字CRS
祝福家庭的祝福语
RX_DV
RXD[3:0]
RX_ER
RX_CLK MII MAC I/F to RMII MAC I/F
RX_ER**Note:RX_ER is a required output of the PHY . The switch
ASIC may choo to u this input.
Signal Definition
4RMII TM Specification Rev. 1.2
麻酱火烧5.0Signal Definition
The PHY shall implement and conform to the requirements for REF_CLK, CRS_DV ,
RXD[1:0], TX_EN, TXD[1:0], and RX_ER. The MAC interface shall implement and
conform to the requirements for REF_CLK, CRS_DV , RXD[1:0], TX_EN and
盘存表
TXD[1:0].
5.1REF_CLK
Reference Clock
REF_CLK is a continuous clock that provides the timing reference for CRS_DV ,
RXD[1:0], TX_EN, TXD[1:0], and RX_ER. REF_CLK is sourced by the MAC or an
external source. Switch implementations may choo to provide REF_CLK as an input
or an output depending on whether they provide a REF_CLK output or rely on an exter-
nal clock distribution device. Each PHY device shall have an input corresponding to this
clock but may u a single clock input for multiple PHYs implemented on a single IC.
The REF_CLK frequency shall be 50 MHz +/- 50 ppm with a duty cycle between 35%
and 65% inclusive. It is assumed that the PHY us REF_CLK as the network clock
such that no buffering is required on the transmit data path.
While the PHY may recover clock from the incoming data stream, the receiver shall
account for differences between the local REF_CLK and the recovered clock through
u of sufficient elasticity buffering. The elasticity buffer design shall not affect the
Inter-Packet Gap (IPG) for received IPGs of 36 bits or greater. To tolerate the clock vari-
旌旗十万ations specified here for Ethernet MTUs, the elasticity buffer shall tolerate a minimum
of +/-10 bits.* This implies that the FIFO is at least 20 bits deep and does not transfer
recovered data onto RXD[1:0] until the FIFO is half full.*Note:Some vendors desire toleration of MTUs greater than the Ethernet MTU.
TABLE 1.RMII Specification Signals Signal
Name Direction (with respect to the PHY)Direction (with respect to the MAC)U
REF_CLK
Input Input or Output Synchronous clock reference for receive, transmit and control interface CRS_DV
Output Input Carrier Sen/Receive Data Valid RXD[1:0]
Output Input Receive Data TX_EN
Input Output Transmit Enable TXD[1:0]
Input Output Transmit Data RX_ER Output Input (Not
required)Receive Error
Signal Definition
5.2CRS_DV
Carrier Sen/Receive Data Valid
CRS_DV shall be asrted by the PHY when the receive medium is nonidle. The specif-
ics of the definition of idle for 10BASE-T and 100BASE-X are contained in IEEE 802.3
[1] and IEEE 802.3u [2]. CRS_DV is asrted asynchronously on detection of carrier
due to the criteria relevant to the operating mode. That is, in 10BASE-T mode, when
squelch is pasd or in 100BASE-X mode when 2 non-contiguous zeroes in 10 bits are
detected carrier is said to be detected.
Loss of carrier shall result in the deasrtion of CRS_DV synchronous to the cycle of
REF_CLK which prents the first di-bit of a nibble onto RXD[1:0] (i.e. CRS_DV is
deasrted only on nibble boundaries). If the PHY has additional bits to be prented on
RXD[1:0] following the initial deasrtion of CRS_DV, then the PHY shall asrt
CRS_DV on cycles of REF_CLK which prent the cond di-bit of each nibble and
deasrt CRS_DV on cycles of REF_CLK which prent the first di-bit of a nibble. The
result is: Starting on nibble boundaries CRS_DV toggles at 25 MHz in 100Mb/s mode
and 2.5 MHz in 10Mb/s mode when CRS ends before RX_DV (i.e. the FIFO still has
bits to transfer when the carrier event ends.) Therefore, the MAC can accurately recover
RX_DV and CRS.
During a fal carrier event, CRS_DV shall remain asrted for the duration of carrier
activity.
The data on RXD[1:0] is considered valid once CRS_DV is asrted. However, since the
asrtion of CRS_DV is asynchronous relative to REF_CLK, the data on RXD[1:0]
shall be “00” until proper receive signal decoding takes place (e definition of
RXD[1:0] behavior).
*Note:CRS_DV is asrted asynchronously in order to minimize latency of control signals through the PHY.
5.3RXD[1:0]
Receive Data [1:0]
RXD[1:0] shall transition synchronously to REF_CLK. For each clock period in which
CRS_DV is asrted, RXD[1:0] transfers two bits of recovered data from the PHY. In
some cas (e.g. before data recovery or during error conditions) a pre-determined value
for RXD[1:0] is transferred instead of recovered data. RXD[1:0] shall be “00” to indi-
cate idle when CRS_DV is deasrted. Values of RXD[1:0] other than “00” when
RX_DV as recovered from CRS_DV is deasrted are rerved for out-of-band signal-
ling (to be defined). Values other than “00” on RXD[1:0] while RX_DV as recovered
from CRS_DV is de-asrted shall be ignored by the MAC. Upon asrtion of CRS_DV,
the PHY shall ensure that RXD[1:0]=“00” until proper receive decoding takes place.
5.3.1RXD[1:0] in 100 Mb/s mode
For normal reception following asrtion of CRS_DV, RXD[1:0] shall be “00” until the
receiver has determined that the receive event has a proper Start of Stream Delimiter.
Rev. 1.2RMII TM Specification5
