dp83261 National Semiconductor Corporation, dp83261 Datasheet - Page 10

• Manufacturer Part Number: dp83261
• Description: Bmac Device Fddi Media Access Controller
• Manufacturer: National Semiconductor Corporation

4 0 FDDI MAC Facilities
The Source Address has the same length as the Destination
Address (i e if the DA is a 16-bit Address the SA is a 16-bit
Address if the DA is a 48-bit Address the SA is a 48-bit
Address)
On the receive side the incoming SA is compared with ei-
ther MSA or MLA If a match occurs between the incoming
SA and this station’s MLA or MSA the M Flag is set This
flag is used to indicate that the frame is recognized as hav-
ing been transmitted by this station and is stripped The
most significant bit of the SA (SA IG) is not evaluated in the
comparison
On the transmit side the station’s individual address is
transmitted as the SA Since the SA field is normally used
for stripping frames from the ring the SA stored by the Ring
Engine normally replaces the SA from the data stream The
length of the address to be transmitted is determined by the
L bit of the FC field (The FC field is passed in the data
stream ) The most significant bit of the SA (SA IG) is nor-
mally transmitted as 0 independent of the value passed
through the data stream
As a transmission option the SA may also be transmitted
transparently from the data stream When the SA Transpar-
ency option is used an alternate stripping mechanism is
necessary to remove these frames from the ring (The Ring
Engine provides a Void Stripping Option See Section
7 4 2 4 for futher information )
As a separate and independent transmission option the
MSB of the SA may also be transmitted transparently from
the data stream This is useful for end stations participating
in the Source Routing protocol
Information
The Information field (Info) contains the Service Data Unit
(SDU) A SDU is the unit of data transfer between peer us-
ers of the MAC data service (SMT LLC etc) There is no
INFO field in a Token
The INFO field contains zero or more bytes
On the receive side the INFO field is checked to ensure
that it has at least the minimum length for the frame type
and contains an even number of symbols as required by the
Standard
The first 4 bytes of the INFO field of MAC frames (e g MAC
Beacon or MAC Claim) are stored in an internal register and
compared against the INFO field of the next MAC frame If
the data of the two frames match the SameInfo signal is
generated This signal may be used to copy MAC frames
only when new information is present
On the transmit side the Ring Engine does not limit the
maximum size of the INFO field but it does insure that
frames are transmitted with a valid DA and SA
Frame Check Sequence
The Frame Check Sequence (FCS) is a 32-bit Cyclic Redun-
dancy Check that is used to check for data corruption in
frames There is no FCS field in a Token
On the receive side the Ring Engine checks the FCS to
determine whether the frame is valid or corrupted
On the transmit side the FCS field is appended to the end
of the INFO field As a transmission option appending the
FCS to the frame can be inhibited (FCS Transparency)
(Continued)
10
Frame Status Indicators (FS)
End of Frame Sequence
The End of Frame Sequence (EFS) always begins with a T
symbol and should always contain an even number of sym-
bols For Tokens an additional T symbol is added For
frames the Ending Delimiter (ED) is followed by one or more
The Frame Status (FS) field is used to indicate the status of
the frame The FS field consists of three Indicators Error
Detected (E) Address Recognized (A) and Frame Copied
(C) These Indicators are created and modified as specified
in the Standard
For frames transmitted by the Ring Engine the E A and C
Indicators are appended to all frames and are transmitted
as R symbols No provisions are made to generate addition-
al trailing control indicators
For frames repeated by the Ring Engine the E A and C
Indicators are handled as specified in the Standard Addi-
tional trailing control indicators are repeated unmodified
provided they are properly aligned See Section 5 5 for de-
tails on Frame Status Processing
4 2 2 Token Formats
The Ring Engine supports non-restricted and restricted To-
kens See Figures 4-4 and 4-5
Non-Restricted
A non-restricted token is used for synchronous and non-re-
stricted asynchronous transmissions
Each time the non-restricted token arrives a station is per-
mitted to transmit one or more frames in accordance with its
synchronous bandwidth allocation regardless of the status
of the token (late or early)
Asynchronous transmissions occur only if the token is early
(usable token) and the Token Holding Timer has not
reached the selected threshold
Restricted
A restricted token is used for synchronous and restricted
asynchronous transmissions only
A station which initiates the restricted dialogue captures a
non-restricted token and releases a restricted token Sta-
tions that participate in the restricted dialogue are allowed
to capture the restricted token A station ends the restricted
dialogue by capturing the restricted token and releasing a
non-restricted token
4 2 3 Frame Formats
The Ring Engine supports all of the frame formats permitted
by the FDDI standard All frame types may be created exter-
nal to the BMAC device and be passed through the MAC
Request Interface to the Ring The BMAC device also has
the ability to generate Void Beacon and Claim frames inter-
nally
FIGURE 4-4 Non-Restricted Token Format
FIGURE 4-5 Restricted Token Format
SFS
SFS
SD
SD
FC
80
FC
C0
EFS
ED
ED
ED