SMSC LAN1198 Manual De Usuario
LAN9118 Family Programmer Reference Guide
Revision 1.0 (12-14-09)
44
SMSC AN 12.12
APPLICATION NOTE
Some other useful error interrupts to be aware of include:
TXSO
TDFO
TSFF – TX status FIFO full
RSFF – RX status FIFO full
8.5 Integrating the Driver: Early Testing
When the driver development has come to the point where it is being integrated into the protocol stack,
a basic integration test which is useful for shaking out the data flows is to send the host a stream of
ICMP ping request packets, while looking for the ping responses. Once this basic skill is mastered by
the driver, the test should advance by varying the packet size through all possible values (64 – 1518
bytes). A PC could be used in this case, although the standard ping program supplied does not
automatically change the size of the packets sent. A better choice in this regard would be a packet
tester, such as those made by SmartBits or iXia. Continuing the advance, the testing should add faulty
packets injected at random points in the ping packet stream. Faulty packets should include, but not
be limited to runts, jabbers, and CRC errors.
a basic integration test which is useful for shaking out the data flows is to send the host a stream of
ICMP ping request packets, while looking for the ping responses. Once this basic skill is mastered by
the driver, the test should advance by varying the packet size through all possible values (64 – 1518
bytes). A PC could be used in this case, although the standard ping program supplied does not
automatically change the size of the packets sent. A better choice in this regard would be a packet
tester, such as those made by SmartBits or iXia. Continuing the advance, the testing should add faulty
packets injected at random points in the ping packet stream. Faulty packets should include, but not
be limited to runts, jabbers, and CRC errors.
When the ping responses coming back from the host maintain their correct sequence, this verifies to
a large extent that the low-level receive operation is working, that the packets are transferred and
aligned into the packet memory buffers correctly, and that the protocol stack can identify the packets
correctly as being of type ICMP. It also verifies that the low-level transmit routine basically works, too.
Adding in the random faulty packet errors validates the data error processing, as well as showing that
the low-level receive operation is not deterred by bad packets. This can be most important when using
DMA for receive data transfers, as the driver will need to interleave its “dialogues” with both the device
and the DMA engine. At this point in the testing the management features can also be verified by
comparing the packet statistics derived from the driver to the values generated by the ping stream
request source.
a large extent that the low-level receive operation is working, that the packets are transferred and
aligned into the packet memory buffers correctly, and that the protocol stack can identify the packets
correctly as being of type ICMP. It also verifies that the low-level transmit routine basically works, too.
Adding in the random faulty packet errors validates the data error processing, as well as showing that
the low-level receive operation is not deterred by bad packets. This can be most important when using
DMA for receive data transfers, as the driver will need to interleave its “dialogues” with both the device
and the DMA engine. At this point in the testing the management features can also be verified by
comparing the packet statistics derived from the driver to the values generated by the ping stream
request source.
The rate of the ping packets should be well within the abilities of the host hardware. Emphasis should
be on the correctness of the response sequence initially, not the data rate of the packet stream. Ideally
the test is striving for a data rate that manages to keep at least a few packets in the Rx FIFO while
the device is under test, and this can really only be determined by the hardware.
be on the correctness of the response sequence initially, not the data rate of the packet stream. Ideally
the test is striving for a data rate that manages to keep at least a few packets in the Rx FIFO while
the device is under test, and this can really only be determined by the hardware.
9 Power Management Events
LAN9118 Family members support power-down modes to allow the application to minimize power
consumption. These modes operate via the PME Block to control the necessary internal signals for
reduced power modes.
consumption. These modes operate via the PME Block to control the necessary internal signals for
reduced power modes.
9.1 System Description
There is one normal operating power state, D0 and there are two power saving states: D1 and D2.
Upon entry into any of the three power management states, only the PMT_CTRL register is accessible
for read operations. Reads of any other addresses are forbidden until the READY bit is set. All writes,
with the exception of the wakeup write to BYTE_TEST register, are also forbidden until the READY bit
is set. Only when in the D0 (Normal) state, when the READY bit is set, can the rest of the device be
accessed.
Upon entry into any of the three power management states, only the PMT_CTRL register is accessible
for read operations. Reads of any other addresses are forbidden until the READY bit is set. All writes,
with the exception of the wakeup write to BYTE_TEST register, are also forbidden until the READY bit
is set. Only when in the D0 (Normal) state, when the READY bit is set, can the rest of the device be
accessed.
Entering power saving states involves setting the desired power management state in the
PMT_CTL:PM_MODE field. If the PM interrupt is enabled, the device can be woken up by writing to
the BYTE_TEST register.
PMT_CTL:PM_MODE field. If the PM interrupt is enabled, the device can be woken up by writing to
the BYTE_TEST register.