am79c940 Advanced Micro Devices, am79c940 Datasheet - Page 35

no-image

am79c940

Manufacturer Part Number
am79c940
Description
Media Access Controller For Ethernet Mace
Manufacturer
Advanced Micro Devices
Datasheet

Available stocks

Company
Part Number
Manufacturer
Quantity
Price
Part Number:
am79c940AJC
Manufacturer:
AMD
Quantity:
1 831
Part Number:
am79c940BJC
Manufacturer:
AMD
Quantity:
8 831
Part Number:
am79c940BJCT
Manufacturer:
AMD
Quantity:
20 000
Part Number:
am79c940BJI
Manufacturer:
AMD
Quantity:
1 000
Part Number:
am79c940BKC
Quantity:
6 255
Part Number:
am79c940BKC
Manufacturer:
AMD
Quantity:
1 000
Part Number:
am79c940BKC
Manufacturer:
AMD
Quantity:
20 000
Part Number:
am79c940BNI
Manufacturer:
AMD
Quantity:
20 000
Part Number:
am79c940BVC
Manufacturer:
AMD
Quantity:
8 831
Part Number:
am79c940BVC
Manufacturer:
AMD
Quantity:
1 000
Part Number:
am79c940BVC
Manufacturer:
AMD
Quantity:
20 000
Part Number:
am79c940BVI
Manufacturer:
AMD
Quantity:
1 831
inability of the host to keep pace with the MACE device
activity.
On completion of transmission, the MACE device will re-
port the Transmit Frame Status for the frame. The exact
number of transmission retry attempts is reported
(ONE, MORE used with XMTRC, or RTRY), and
whether the MACE device had to Defer (DEFER) due to
channel activity. In addition, Loss of Carrier is reported,
indicting that there was an interruption in the ability of
the MACE device to monitor its own transmission. Re-
peated LCAR errors indicate a potentially faulty trans-
ceiver or network connection. Excessive Defer
(EXDEF) will be reported in the Transmit Retry Count
register if the transmit frame had to wait for an abnor-
mally long period before transmission.
Additional transmit error conditions are reported
through the Interrupt Register.
The Late Collision (LCOL) error indicates that the trans-
mission suffered a collision after the slot time. This is
indicative of a badly configured network. Late collisions
should not occur in normal operating network.
The Collision Error (CERR) indicates that the trans-
ceiver did not respond with an SQE Test message within
the predetermined time after a transmission completed.
This may be due to a failed transceiver, disconnected or
faulty transceiver drop cable, or the fact the transceiver
does not support this feature (or it is disabled).
In addition to the reporting of network errors, the MACE
device will also attempt to prevent the creation of any
network error caused by inability of the host to service
the MACE device. During transmission, if the host fails
to keep the Transmit FIFO filled sufficiently, causing an
underflow, the MACE device will guarantee the
message is either sent as a runt packet (which will be
deleted by the receiving station) or has an invalid FCS
(which will also allow the receiving station to reject the
message).
The status of each receive message is passed via the
Receive Frame Status bytes. FCS and Framing errors
(FRAM) are reported, although the received frame is still
passed to the host. The FRAM error will only be reported
if an FCS error is detected and there are a non integral
number of bytes in the message. The MACE device will
ignore up to seven additional bits at the end of a mes-
sage (dribbling bits), which can occur under normal net-
work operating conditions. The reception of eight
additional bits will cause the MACE device to de-serial-
ize the entire byte, and will result in the received mes-
sage and FCS being modified.
Received messages which suffer a collision after
64-byte times (after SFD) will be marked to indicate they
have suffered a late collision (CLSN). Additional count-
ers are provided to report the Receive Collision Count
Am79C940
and Runt Packet Count to be used for network statistics
and utilization calculations.
Note that if the MACE device detects a received packet
which has a 00b pattern in the preamble (after the first
8-bits which are ignored), the entire packet will be ig-
nored. The MACE device will wait for the network to go
inactive before attempting to receive additional frames.
Media Access Management
The basic requirement for all stations on the network
is to provide fairness of channel allocation. The
802.3/Ethernet protocols define a media access mecha-
nism which permits all stations to access the channel
with equality. Any node can attempt to contend for the
channel by waiting for a predetermined time (Inter Pack-
et Gap interval) after the last activity, before transmitting
on the media. The channel is a bus or multidrop commu-
nications medium (with various topological configura-
tions permitted) which allows a single station to transmit
and all other stations to receive. If two nodes simultane-
ously contend for the channel, their signals will interact
causing loss of data, defined as a collision. It is the re-
sponsibility of the MAC to attempt to avoid and recover
from a collision, to guarantee data integrity for the end-
to-end transmission to the receiving station.
Medium Allocation (Collision Avoidance)
The IEEE 802.3 Standard (ISO/IEC 8802-3 1990) re-
quires that the CSMA/CD MAC monitors the medium for
traffic by watching for carrier activity. When carrier is de-
tected, the media is considered busy, and the MAC
should defer to the existing message.
The IEEE 802.3 Standard also allows optional two part
deferral after a receive message.
(1) Upon completing a transmission, start timing the
(2) When timing an interFrame gap following reception,
reset the interFrame gap timing if carrierSense
becomes true during the first 2/3 of the interFrame gap
timing interval. During the final 1/3 of the interval the
timer shall not be reset to ensure fair access to the me-
interpacket gap, as soon as transmitting and
carrierSense are both false.
See ANSI/IEEE Std 802.3-1990 Edition, 4.2.3.2.1:
“NOTE : It is possible for the PLS carrier sense
indication to fail to be asserted during a collision
on the media. If the deference process simply
times the interFrame gap based on this indica-
tion it is possible for a short interFrame gap to
be generated, leading to a potential reception
failure of a subsequent frame. To enhance sys-
tem robustness the following optional meas-
ures, as specified in 4.2.8, are recommended
when interFrameSpacingPart1 is other than
zero:”
AMD
35

Related parts for am79c940