AM79C90 Advanced Micro Devices, AM79C90 Datasheet - Page 59
![no-image](/images/manufacturer_photos/0/0/14/advanced_micro_devices_sml.jpg)
AM79C90
Manufacturer Part Number
AM79C90
Description
CMOS Local Area Network Controller for Ethernet (C-LANCE)
Manufacturer
Advanced Micro Devices
Datasheet
1.AM79C90.pdf
(62 pages)
Available stocks
Company
Part Number
Manufacturer
Quantity
Price
Company:
Part Number:
AM79C900AJC
Manufacturer:
AMD
Quantity:
5 510
Company:
Part Number:
AM79C900AJC
Manufacturer:
SIG
Quantity:
5 510
Company:
Part Number:
AM79C900JAJC
Manufacturer:
AMD
Quantity:
359
Company:
Part Number:
AM79C900JCDV
Manufacturer:
AMD
Quantity:
1 831
Part Number:
AM79C901AJC
Manufacturer:
AMD
Quantity:
20 000
Part Number:
AM79C901AVC
Manufacturer:
AMD
Quantity:
20 000
Part Number:
AM79C90JC
Manufacturer:
AMD
Quantity:
20 000
3. As mentioned in 7c), the window should end no
The C-LANCE device implements the heartbeat test in
full compliance with IEEE specifications. In the
d. IEEE specifications require that receive be blinded
8. “Heartbeat OK” (No CERR) Definition
The heartbeat test or Signal Quality Error (SQE) test is
performed to verify the ability of the AUI to pass the col-
lision (SQE) indication to the DTE. The LANCE and
C-LANCE devices indicate a heartbeat test failure by
setting the CERR bit in CSR0 (bit 13).
At the conclusion of each transmission, the DTE opens
a time window during which it expects to see a collision
indication. In the LANCE device, this window begins
immediately when TENA deasserts and ends 2.0 s
after RENA deasserts. The heartbeat signal is ex-
pected by the LANCE device even if the packet being
transmitted suffers a collision. This implementation vio-
lates IEEE requirements in three ways:
1. IEEE 802.3 specifications state that the heartbeat
2. If a collision occurs, the IEEE 802.3 specifications
C-LANCE device, the heartbeat window begins when
RENA deasserts and ends 4 s later. In addition, the
MAU must generate the collision signal within
0.6 s to 1.6 s after the end of the transmit packet,
which is typically early enough for the LANCE de-
vice to detect it, even with its non-compliant 2- s
window. However, to comply with IEEE standards,
the C-LANCE device implements an SQE test win-
dow of 4 s.
following transmit for 4 s to prevent the controller
from responding to any trash that may be generated
by the MAU when it generates the SQE test signal.
However, IEEE specifications do not state that the
receiver should be blinded following a receive. The
LANCE device implements a 4.1- s blinding time
following receive, violating IEEE specifications. This
was erroneously implemented in the LANCE device,
since it was thought to be a moot issue under the
assumption that there should be no valid data on
the wire within 4.1 s of the end of a receive anyway.
However, since two-part deferral after transmit and
receive are both optional, as mentioned in 7a), there
are rare situations where legal packets may arrive
with an IFS of less than 4.1 s. To better handle this
situation, the C-LANCE device reduces the blind
time following a receive to less than 500 ns. The
blind time allows time to store and then clear the
status that was generated by the ending reception.
window should begin when the input becomes idle
(RENA deasserts), not when the output becomes
idle (TENA deasserts).
indicate that the DTE should not look for the SQE
test signal.
earlier than 4.0 s after RENA deasserts.
Am79C90
C-LANCE device does not look for the heartbeat signal
whenever the packet being transmitted suffers a
collision.
The PCnet-ISA and MACE devices use the same
heartbeat OK definition as the C-LANCE device.
Details on the LANCE device’s violations of IEEE spec-
ifications: The consequences of the violations of the
standard by the LANCE device are insignificant in prac-
tice. Item 1 (window begins when TENA deasserts, not
RENA) actually prevents the LANCE from being penal-
ized by Item 2 (heartbeat expected following a colli-
sion). That is, if the LANCE device did not violate Item
1 and started its window when RENA deasserted in-
stead of TENA, then the LANCE device could get false
CERR indications when a packet it is transmitting suf-
fers a collision. This can happen as follows. In the event
of a collision, the network may remain active for a while
after one node stops transmitting its JAM sequence
(other nodes involved in the collision may still have their
JAM on the wire). At a node that ends its JAM se-
quence relatively early, the heartbeat signal can over-
lap with the collision or the end of the collision frag-
ment, since the MAU times the heartbeat signal
generation from when the controller stops transmitting.
If this node uses a LANCE device as its controller, the
LANCE device will see this heartbeat signal only be-
cause of the violation given in Item 1. If the LANCE
device started its window when RENA deasserted in-
stead of TENA, it would miss the heartbeat signal,
since the heartbeat passes by while the collision is still
on the wire. This would give false CERR indications.
Hence, the violation of Item 1 in the LANCE device is
not a problem. In fact, it makes the violation of Item 2
generally a non-issue.
Although the violation of Item 1 masks the violation of
Item 2 as just described, the violation of Item 2 (heart-
beat still expected by the LANCE device when collision
occurs) can still lead to false CERR indications when
the LANCE device is used with a non-802.3-compliant
MAU. The IEEE 802.3 specifications state that the MAU
is to generate the SQE test signal after every transmit,
even when the transmit suffers a collision. However,
some MAUs on the market have been found not to
comply with this requirement. When operating with a
non-compliant MAU that does not generate the heart-
beat signal after a collided transmission, the LANCE
device can give false CERR indications.
As mentioned in 7c), Item 3 is generally a non-issue.
9. Receive Lockup
The LANCE device has an erratum in which the re-
ceiver locks up when the system bus latency is very
high. This erratum is fixed in the C-LANCE device.
59