AM79C940JC/W AMD [Advanced Micro Devices], AM79C940JC/W Datasheet - Page 34

• Manufacturer Part Number: AM79C940JC/W
• Manufacturer: AMD [Advanced Micro Devices]

impact on the perceived latency that the Receive FIFO
provides to the host system. The description and table
below outline the point at which RDTREQ will be
asserted when the first duration of the packet has been
received and when any subsequent transfer of the
packet to the host system is required.
No preamble/SFD bytes are loaded into the Receive
FIFO. All references to bytes pass through the receive
FIFO. These references are received after the pream-
ble/SFD sequence.
The first assertion of RDTREQ for a packet will occur
after the longer of the following two conditions is met:
Receive FIFO—Burst Operation
The RCVFIFO also provides a burst mode capability,
programmed by the RCVBRST bit in the FIFO Config-
uration Control register, to modify the operation of
RDTREQ.The assertion of RDTREQ will occur accord-
ing to the programming of the RCVFW bits. RDTREQ
will be de-asserted when the RCVFIFO can only pro-
vide a single read cycle (one word read). This allows
the external device to burst data from the RCVFIFO
once RDTREQ is asserted, and stop when RDTREQ
is deasserted.
Receive FIFO—Low Latency Receive Operation
The LOW Latency Receive mode can be programmed
using the Low Latency Receive bit (LLRCV in the
Receive Frame Control register). This effectively
causes the assertion of RDTREQ to be directly coupled
to the low watermark of 12 bytes in the RCVFIFO.
Once the 12-byte threshold is reached (plus some
internal synchronization delay of less than 1 byte),
RDTREQ will be asserted, and will remain active until
the RCVFIFO can support only one read cycle
(one wor d of data), as in the bur st oper ati on
described earlier. The exception is the case where 4-8
bytes of padding is required by the FIFO design, unless
it is the end of the packet.
The intended use for the Low Latency Receive mode is
to allow fast forwarding of a received packet in a bridge
application. In this case, the receiving process is made
aware of the receive packet after only 9.6 s, instead of
waiting up to 60.8 s (76-bytes) necessary for the initial
34
RCVFW
64-bytes have been received (to assure runt pack-
ets and packets experiencing collision within the
slot time will be rejected).
[1-0]
00
01
10
11
Bytes Required for
First Assertion of
RDTREQ
XX
64
64
76
Receive FIFO Watermarks, RDTREQ Assertion and Latency
After First Assertion
Bytes of Latency
of RDTREQ
XX
64
64
52
Am79C940
assertion of RDTREQ. An Ethernet-to-Ethernet bridge
employing the MACE device (on all the Ethernet
connections) with the XMTSP of all MACE controller
XMT FIFOs set to the minimum (4-bytes), forwarding of
a receive packet can be achieved within a sub 20 s
delay including processing overhead.
Note, however, that this mode places significant bur-
den on the host processor. The receiving MACE device
will no longer delete runt packets. A runt packet will
have the Receive Frame Status appended to the re-
ceive data which the host must read as normal. The
MACE device will not attempt to delete runt packets
from the RCVFIFO in the Low Latency Receive mode.
Collision fragments will also be passed to the host if
they are detected after the 12-byte threshold has been
reached. If a collision occurs, the Receive Frame Sta-
tus (RCVFS) will be appended to the data successfully
received in the RCVFIFO up to the point the collision
was detected. No additional receive data will be written
to the RCVFIFO. Note that the RCVFS will not become
available until after the receive activity ceases. The col-
lision indication (CLSN) in the Receive Status
(RCVSTS) will be set, and the Receive Message Byte
Count (RCVCNT) will be the correct count of the total
duration of activity, including the period that collision
was detected. The detection of normal (slot time) colli-
sions versus late collisions can only be made by
counting the number of bytes that were successfully re-
ceived prior to the termination of the packet data.
In all cases where the reception ends prematurely (runt
or collision), the data that was successfully received
access is guaranteed. They are required for all
The RCVFW threshold is reached plus an additional
12 bytes. The additional 12 bytes are necessary to
ensure that any permutation of byte/word read
threshold values, but in the case of the 16 and
32-byte thresholds, the requirement that the slot time
criteria is met dominates. Any subsequent assertion
of RDTREQ necessary to complete the transfer of
the packet will occur after the RCVFW threshold is
reached plus an additional 12 bytes. The table below
also outlines the latency provided by the MACE de-
vice when the RDTREQ is asserted.
Subsequent Assertion
Bytes Required for
of RDTREQ
XX
28
44
76
Bytes of Latency After
Subsequent Assertion
of RDTREQ
100
XX
84
52