SMSC LAN9420 - Manual (Page 52)

Single-Chip Ethernet Controller with HP Auto-MDIX Support and PCI Interface
Datasheet
Revision 1.22 (09-25-08) 52 SMSC LAN9420/LAN9420i
DATASHEET
3.4.9 TX Buffer Fragmentation Rules
Transmit buffers must adhere to the following rules:
„ Each buffer can start and end on any arbitrary byte alignment
„ The first buffer of any transmit packet can be any length
„ Middle buffers (i.e., those with First Segment = Last Segment = 0) must be greater than, or equal
to 4 bytes in length
„ The final buffer of any transmit packet can be any length
Additionally, the MIL operates in store-and-forward mode and has specific rules with respect to
fragmented packets. The total space consumed in the TX FIFO (MIL) must be limited to no more than
2KB - 3 DWORDs (2,036 bytes total). Any transmit packet that is so highly fragmented that it takes
more space than this must be un-fragmented (by copying to a driver-supplied buffer) before the
transmit packet can be sent to LAN9420/LAN9420i.
One approach to determine whether a packet is too fragmented is to calculate the actual amount of
space that it will consume, and check it against 2,036 bytes. Another approach is to check the number
of buffers against a worst-case limit of 86 (see explanation below).
3.4.9.1 Calculating Worst-Case TX FIFO (MIL) Usage
The actual space consumed by a buffer in the MIL TX FIFO consists of any partial DWORD offsets in
the first/last DWORD of the buffer, plus all of the whole DWORDs in between. The worst-case
overhead for a TX buffer is 6 bytes, which assumes that it started on the high byte of a DWORD and
ended on the low byte of a DWORD. A TX packet consisting of 86 such fragments would have an
overhead of 516 bytes (6 * 86) which, when added to a 1514-byte max-size transmit packet (1516
bytes, rounded up to the next whole DWORD), would give a total space consumption of 2,032 bytes,
leaving 4 bytes to spare; this is the basis for the "86 fragment" rule mentioned above.
3.4.10 DMAC Interrupts
As described in earlier sections, there are numerous events that cause a DMAC interrupt. The
DMAC_STATUS register contains all the bits that might cause an interrupt. The DMAC_INTR_ENA
register contains an enable bit for each of the events that can cause a DMAC interrupt. The DMAC
interrupt to the Interrupt Controller is asserted if any of the enabled interrupt conditions are satisfied.
There are two groups of interrupts: normal and abnormal (as outlined in DMAC_STATUS). Interrupts
are cleared by writing a logic 1 to the bit. When all the enabled interrupts within a group are cleared,
the corresponding summary bit is cleared. When both the summary bits are cleared, the DMAC
interrupt is de-asserted.
Interrupts are not queued and if a second interrupt event occurs before the driver has responded to
the first interrupt, no additional interrupts will be generated. For example, Receive Interrupt (RI bit in
the DMAC_STATUS register) indicates that one or more frames was transferred to a Host memory
buffer. The driver must scan all descriptors, from the last recorded position to the first one owned by
the DMA controller.
An interrupt is generated only once for simultaneous, multiple events. The driver must scan the
DMAC_STATUS register for the interrupt cause. The interrupt is not generated again, unless a new
interrupting event occurs after the driver has cleared the appropriate DMAC_STATUS bit. For example,
the controller generates a receive interrupt (RI) and the driver begins reading DMAC_STATUS. Next,
a Receive Buffer Unavailable (RU) occurs. The driver clears the receive interrupt. DMA_INTR gets de-
asserted for at least one cycle and then asserted again for the RX buffer unavailable interrupt.
3.4.11 DMAC Control and Status Registers (DCSR)
Please refer Section 4.3, "DMAC Control and Status Registers (DCSR)," on page 103 to for a complete
description of the DCSR.