LAN9118 Family Programmer Reference Guide
Revision 1.0 (12-14-09) 36 SMSC AN 12.12
APPLICATION NOTE
A receive process must signal the host that there are incoming packets to be read in, it must identify
the validity and length of each individual packet, copy the packet data from device to memory, hand
off the packet data memory to the protocol stack, maintain count statistics, and continue the application
when there are no more incoming packets. This is much like transmit processing in reverse, with the
difference mainly being one of synchronicity. The low-level transmit routine sends a packet whenever
the application offers it one; the transmitter is ready to accept the packet most of the time. The receive
processing on the other hand, does not know a priori when a packet is being received. Hence there
is a need to drive the process asynchronously via the device RX Status FIFO Level (RSFL) interrupt,
which signals the NOS that there are incoming packets to be serviced. Polling could be employed by
a thread to examine the same device status as that causing the interrupt, but it is better practice and
more efficient if the driver relies upon one of the available interrupts, either by detecting the change in
time, such as the GP Timer, or status change. Sometimes the underlying operating system can avail
the driver a useful polling API, such as NAPI under Linux, but in any case, the driver author can choose
from a variety of techniques to synchronize the ingress of packet data to the application.
The first information the driver needs for each packet arriving at the device is its associated receive
status word (RX Status). We are primarily concerned with the length of a packet (Packet Length)
and any indications of errors. Like the TX Status: E rror Status, the RX Status:Error Status bit is a
quick summation of typical receive errors, such as runts, frames too long, late collisions, and CRC
errors. Using the remaining status information allows a driver other options, including a quick
discrimination between Ethernet, 802.3, broadcast and multicast frames. While discussing the receive
status word, keep in mind that when the MAC_CR:PADSTR bit is set, the Packet Length reflects the
data actually sent across the wire, and CRC is stripped off of the packet (0x5ea). Otherwise packets
less than 64-bytes are padded out to 64-bytes and CRC is always appended.
To detect the presence of incoming packets, the receiver maintains a queue of status words, which
can be individually read from the RX Status FIFO port, each corresponding to a packet positioned in
the data queue. Each read pops a status word off the front of the queue. Some driver environments
may require the driver to examine the status before popping it off of the queue, and for this a RX
Status FIFO PEEK port is provided. At any given moment, the RX_FIFO_INF:RXSUSED register field
gives a current, reliable count of status words in the FIFO, and hence how many packets, good or bad,
are queued up for processing. This field has associated with it an RSFL_INT_EN interrupt bit and
threshold count FIFO_INT:RX Status Level register field, which can be programmed to signal the host
whenever the current count exceeds the threshold value.
The RSFL interrupt handler depicted in Figure 7.1, "Packet Reception", should acknowledge and
disable the interrupt, and then schedule a thread to run outside of interrupt state, to minimize the
amount of time interrupts are blocked in the application. When the thread has read in all of the pending
receive packets, the interrupt can again be enabled.
Table7.1 Receive Status Word
RX STATUS
31 30 Packet Length (29:16) Error
Status
14 13 12 11 10 9876543210
0x59 0