SMSC LAN1198 Manual De Usuario
LAN9118 Family Programmer Reference Guide
SMSC AN 12.12
39
Revision 1.0 (12-14-09)
APPLICATION NOTE
:
Enabling a receive transfer requires setting up the RX_CFG register, shown in
(0x12), which gives the starting alignment of the MAC header which is needed to place the IP header
on the DWORD address of 0xb40020020. For PIO transfers, DWORD end alignment is sufficient, so
this field would be set with a value of ‘00’ to indicate such. But since we are doing this transfer using
a DMA controller capable of cache line bursting, we can set the RX End Alignment to reflect the
controller’s burst transfer ability, in this case 32-byte (‘10’ == 2) end alignment.
on the DWORD address of 0xb40020020. For PIO transfers, DWORD end alignment is sufficient, so
this field would be set with a value of ‘00’ to indicate such. But since we are doing this transfer using
a DMA controller capable of cache line bursting, we can set the RX End Alignment to reflect the
controller’s burst transfer ability, in this case 32-byte (‘10’ == 2) end alignment.
When the driver is written to work along with a DMA controller, it becomes necessary to coordinate
the completion of a transfer. Usually this coordination is based upon the DMA controller interrupting
on terminal count (all bytes transferred), but there are situations where we want the driver to continue
receive processing in parallel to the DMA operations, particularly if the DMA controller is descriptor-
based. The device will assert the RXD_INT interrupt to the host on terminal count by programming
the RX_CFG:RX DMA Count field with the transfer size. As this field is 12-bits wide and the count is
expressed in DWORDS, the driver can potentially start a series of transfers and continue only after
they have all completed. For this example we need to calculate the RX DMA Count by adding the
RX Data Offset preceding the start of the packet (0x12) to the Packet Length of 0x59 and finish by
adding the number of padding bytes implied by the RX End Alignment (from offset 0x6b through 0x7f
== 0x15) for a sum total of 18 + 89 + 21 == 128 bytes, or 32 DWORDS (0x20).
the completion of a transfer. Usually this coordination is based upon the DMA controller interrupting
on terminal count (all bytes transferred), but there are situations where we want the driver to continue
receive processing in parallel to the DMA operations, particularly if the DMA controller is descriptor-
based. The device will assert the RXD_INT interrupt to the host on terminal count by programming
the RX_CFG:RX DMA Count field with the transfer size. As this field is 12-bits wide and the count is
expressed in DWORDS, the driver can potentially start a series of transfers and continue only after
they have all completed. For this example we need to calculate the RX DMA Count by adding the
RX Data Offset preceding the start of the packet (0x12) to the Packet Length of 0x59 and finish by
adding the number of padding bytes implied by the RX End Alignment (from offset 0x6b through 0x7f
== 0x15) for a sum total of 18 + 89 + 21 == 128 bytes, or 32 DWORDS (0x20).
Having written the RX_CFG value we can enable the DMA controller to transfer 128 bytes from the
RX Data FIFO to the packet memory buffer beginning at address 0xb4002000. The device will handle
the correct data alignment for the transfer to result in the example shown in
RX Data FIFO to the packet memory buffer beginning at address 0xb4002000. The device will handle
the correct data alignment for the transfer to result in the example shown in
. Since we
assigned a non-zero value to the RX DMA Count, we are not counting on the controller to interrupt
us on its terminal count. The device will signal transfer complete by raising the RXD_INT interrupt.
us on its terminal count. The device will signal transfer complete by raising the RXD_INT interrupt.
7.2 Purging Receive Packets
There are valid reasons for throwing away data in the normal course of driver operations, such as
malformed data or a lack of data memory buffers in which to hold and process the data. Another
reasons is to do perfect multicast filtering, which is performed in software. Since only the destination
address is required for evaluation, the driver could read in 2 DWORDS, and decide whether or not to
bring the rest of the packet in. Another example is IEEE 802.3 frame size errors, where the MAC
header length/type field does not correspond with the value in the RxStatus:Packet Length field
malformed data or a lack of data memory buffers in which to hold and process the data. Another
reasons is to do perfect multicast filtering, which is performed in software. Since only the destination
address is required for evaluation, the driver could read in 2 DWORDS, and decide whether or not to
bring the rest of the packet in. Another example is IEEE 802.3 frame size errors, where the MAC
header length/type field does not correspond with the value in the RxStatus:Packet Length field
A packet is purged by setting the RX_DP_CTRL:RX_FFWD bit, and then polling it (read back and test
for bit reset to 0) until it has reset. If the packet is less than 4 DWORDS in length however, then the
for bit reset to 0) until it has reset. If the packet is less than 4 DWORDS in length however, then the
Table 7.3 RX End Alignment
ALIGNMENT REQUIREMENT
VALUE (31:30)
4-word alignment
0x0
16-word alignment
0x1
32-word alignment
0x2
(undefined, illegal)
0x3
Table 7.4 Receiver Configuration Word
RX_CFG
RX End Alignment
2
9
2
8
RX DMA
Count
1
5
1
4
1
3
RX Data Offset
7 6 5 4 3 2 1 0
0x2
0x20
0x12