
MD400184/A
13
84221
On the receive side for 100BaseTX operation,  the TX
receiver removes any high frequency noise from the input,
equalizes the input signal to compensate for the low pass
effects of the cable, and qualifies the data with a squelch
algorithm. The TX receiver then converts the data from
MLT3 coded twisted pair levels to internal digital levels.
The output of the receiver then goes to a clock and data
recovery block which recovers a clock from the incoming
data, uses the clock to latch in valid data into the device,
and converts the data back to NRZ data. The data is then
unscrambled and decoded by the 4B5B decoder and
descrambler, respectively, and output to an external
Ethernet controller by the controller interface. 
10 Mbps operation is similar to the 100 Mbps operation,
except:
 There is no scrambler/descrambler.
 The encoder/decoder is Manchester instead of 4B5B.
 The data rate is 10 Mbps instead of 100 Mbps.
 The twisted pair symbol data is two level Manchester 
instead of ternary MLT3.
The AutoNegotiation block automatically configures each
channel for either 100BaseTX or 10BaseT and either Full
or Half Duplex operation. This configuration is based on
the capabilities selected for the channel and capabilities
detected from the remote device connected to the
channel.
The Management Interface (the MI serial port) is a two pin
bidirectional link through which configuration inputs can be
set and channel status outputs  read.
Each block plus the operating modes are described in
more detail in the following sections. Since the 84221 can
operate as a 100BaseTX or a 10BaseT device, each of
the following sections describes the performance in both
100 and 10 Mbps modes. 
2.2  CONTROLLER INTERFACE (RMII)
2.2.1  General
The controller interface is the interface between the device
and an external Ethernet Media Access Controller (MAC).
The specific controller interface type implemented on the
device is the Reduced Pin Count Media Independent
Interface, also referred to as RMII.  The RMII is a two bit
wide packet data interface between an Ethernet PHY and
MAC that was defined by an industry group, the RMII Con-
sortium. The RMII is a reduced pin count version of the
IEEE 802.3 MII.  The 84221 meets all the RMII require-
ments outlined in the RMII Consortium specifications and
can directly connect to any Ethernet controller that also
complies with the RMII specifications.
2.2.2  100 Mbps
The RMII consists of eight signals:  (1) two transmit data
inputs (TXD[1:0]), (2) a transmit enable input (TXEN), (3)
two receive data outputs (RXD[1:0]), (4) a carrier sense/
data valid input (CRS), (5) a receive data error input
(RXER), and (6) global clock input (CLKIN).  The global
clock, CLKIN, is a common signal for all eight channels.
All other signals are replicated for each channel. CLKIN
operates at  a frequency of 50 MHz.
Data in RMII is transmitted/received in 2-bit wide word,
called di-bits, on TXD[1:0]/RXD[1:0], respectively.  The
RMII frame format and bit order is defined in the RMII
Consortium specifications and is also shown in Figure 3.
On the transmit side, the CLKIN input runs continuously at
50 MHz. When no data is to be transmitted, TXEN must
be deasserted. While TXEN is deasserted, TXD[1:0] are
ignored and no data is clocked into the device. When
TXEN is asserted, it is clocked in on the rising edge of
CLKIN along with the data on TXD[1:0]. TXD[1:0] input
data is two bit wide packet data whose format needs to be
the same as specified in the RMII Consortium specifica-
tion and also shown in Figure 3. When all packets have
been latched into the device, TXEN must be deasserted.
On the receive side, when no packets are being received,
CRS is deasserted and RXD[1:0] is held low. When the
start of packet is detected, CRS is asserted active high on
the rising edge of CLKIN and RXD[1:0]=00 until the
receive packet data is available to be output onto
RXD[1:0].   When the packet data is available to be output,
it is clocked out onto RXD[1:0] on rising edges of CLKIN
while CRS still remains asserted high. When the end of
packet is detected on the receive input, CRS toggles high
and low at a 25 MHz rate until all of the packet data has
been output onto the RXD[1:0] pins.   Once all of the
packet data has been output on RXD[1:0], then CRS is
deasserted on rising edges of CLKIN. If dribble bits occur
on the receive input, a non-integer number of data octets
will be output on RXD[1:0].  If the device is in the Link Fail
state, CRS always stays deasserted.  The packet data on
RXD[1:0] has the same frame structure and bit order as
the TXD[1:0] data and is specified in the RMII Consortium
specification and also shown in Figure 3. 
An elastic buffer is present in the receive data path
because the input receive data is referenced to the recov-
ered clock and the receive data output on RXD0 has to be
referenced to CLKIN.  The receive buffer is 32 bits in
length.  Receive input data fills the elastic buffer to a pre-
determined  threshold level before data is passed to the