each packet to be transmitted and resides in the buffer memory at the beginning of each
packet. Only the MAC and user software, not the FSI, need to know where the packet
request header ends and the FC of the frame starts. The packet request header contains
MAC control information such as token class, frame type, etc., and is absolutely
transparent to the FSI.
The normal sequence of transfers is as follows:
1. Zero or more FILLERs
2. One TX_START
3. Many TX_DATAs
The entire sequence is repeated for following frames. No FILLERs should come between
TX_START and TX_END. If there is a following frame, the FSI will insert ≤ 8 FILLERs
before the subsequent TX_START. This causes the MAC to consider sending it with this
token in the case where the MAC does not generate the CRC field, especially if the M-bit
The MAC is free either to ignore the M-bit in the TX_END or to insert a limited number of
additional IDLEs while waiting for the next TX_START. The FSI should set the M-bit only
if it has an additional packet queued that it believes it can pass to the MAC in a short time
(less than 16 FILLERs maximum). The M-bit is considered merely a hint; the FSI is
allowed to not subsequently deliver a TX_START since the MAC always sends at least
eight IDLE symbol pairs between frames.
When the FSI detects that TXRDY has not been asserted, the FSI should repeat the
present TX_DATA transfer until TXRDY has been asserted (high). Once TXRDY is
asserted, the next TX_DATA transfer should be initiated. TXRDY only applies to
TX_DATA transfers; the FSI can, for example, send TX_END or TX_START at any time
regardless of the value of TXRDY.
Figure 8-1 illustrates the functional relationship between BYTCLK, TXRDY, and the
packet request header bytes when TXRDY is not asserted for the first packet request
header byte. This configuration causes the second packet request header byte to be
held until TXRDY is detected (on the falling edge of SYMCLK when BYTCLK is low).
Figure 8-1. TXRDY and Packet Request Header Timing
MC68838 USER'S MANUAL