MOTOROLA
MC68838 USER’S MANUAL
3- 11
LOSE_CLAIM—Lose Claim
The transmitter always loses the claim bidding process.
0 = The transmitter works normally.
1 = The transmitter treats all Lower_Claim frames as Higher_Claim frames and all
My_Beacon frames as Other_Beacon frames (the receiver operation is
unaffected). All other Recovery_Required conditions are ignored (i.e., TVX
expiration, TRT expiration when LATE_CT > 0, and T_Opr < target request time
register when RING_OPERATIONAL is one) while in any of the states from which
the Recovery_Required transitions originate (i.e., Tx_Idle, Tx_Repeat, Tx_Data,
Tx_Token, or Tx_Void states). Because the Recovery_Required transitions
cannot occur, the transmitter will never enter the Tx_Claim or TX_Beacon states,
except upon a MAC_RESET/CLAIMING, MAC_RESET/BEACONING, or upon
TRT expiration while already in Tx_Claim (MAC then goes to Tx_Beacon).
However, once it is in these states (e.g., if this bit is set while in Tx_Claim), the
MAC can stay in any of these states.
RESET_FIELD—Reset Field
This field, which includes various types of MAC resets, is used to apply general signals
to the whole of the chip. The idea of a signal is that it only lasts for a single BYTCLK
cycle, unlike the regular control bits whose effect continues as long as the bit is set.
00 = Normal operation and no MAC_RESET occurs.
01 = A regular FDDI-specified MAC_RESET occurs.
10 = A combined MAC_RESET/BEACONING action occurs (i.e., a MAC_RESET
followed by the transmitter going to the Tx_Beacon state). This action is
equivalent to an SA_MA_CONTROL request (beacon) service primitive.
11 = A combined MAC_RESET/CLAIMING action occurs (i.e., a MAC_RESET
followed by the transmitter going to the Tx_Claim state).
When the MAC is off (MAC_ON = 0), this bit field retains its last written value (i.e., it is
not cleared upon the next rising edge of BYTCLK), and it has no effect until the MAC is
subsequently turned on.
FSI_BEACON—Transmit Beacons from the FSI
0 = If FSl_BEACON is zero, there are no queued FSI frames, or the BCN_FRAME bit
of the queued frame is zero, then the MAC sends internally created beacon
frames with an INFO field consisting of four bytes of zeros (i.e., BEACON_TYPE
is unsuccessful claim). The MAC will not attempt to skip over FSI generated
frames whose BCN_FRAME is zero to find later frames with a BCN_FRAME of
one. Also, a frame with a BCN_FRAME of one will only be sent once. Hence, for
the MAC to continue to send FSI generated beacon frames, new frames need to
be continually queued up to the MAC chip.
1 = The MAC allows the FSI to send beacon frames that have been generated by
upper level software. Whenever the MAC is in the beacon state (T5), a frame is
available to transmit at the MAC/FSI interface, and the BCN_FRAME bit is set in
its packet request header, the MAC will send this frame.
ARCHIVE INFORMA
TION
ARCHIVE INFORMA
TION
Summary of Contents for MC68838
Page 20: ...2 8 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...
Page 63: ...5 4 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...
Page 65: ...6 2 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...
Page 82: ...9 6 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...
Page 86: ...10 4 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...
Page 98: ...12 6 MC68838 USER S MANUAL MOTOROLA ARCHIVE INFORMATION ARCHIVE INFORMATION ...