DP83261_技术文档

October 1994

DP83261 BMAC^TMDevice

(FDDI Media Access Controller)

General Description

The DP83261 BMAC device implements the Media Access

Features

Y

Full duplex operation with through parity

Y

Control (MAC) protocol for operation in an FDDI token ring.

The BMAC device provides a flexible interface to the

BSI-2^TMdevice. The BMAC device offers the capabilities

described in the ANSI X3T9.5 MAC Standard and several

functional enhancements allowed by the Standard.

Supports all FDDI ring scheduling classes (asynchro-

nous, synchronous, restricted asynchronous, and

immediate)

Y

Supports individual, group, short, long and external

addressing

The BMAC device transmits, receives, repeats, and strips

tokens and frames. It uses a full duplex architecture that

allows diagnostic transmission and self testing for error iso-

lation. The duplex architecture also allows full duplex data

service on point-to-point connections. Management soft-

ware is also aided by an array of on chip statistical counters,

and the ability to internally generate Claim and Beacon

frames without program intervention. A multi-frame stream-

ing interface is provided to the system interface device.

Generates Beacon, Claim and Void frames without

intervention

Y

Provides extensive ring and station statistics

Provides extensions for MAC level bridging

Provides separate management interface

Uses low power microCMOS

TL/F/10387–1

FIGURE 1-1. FDDI Chip Set Block Diagram

TRI-STATEÉis a registered trademark of National Semiconductor Corporation.

BSI-2^TM, BMAC^TM, PLAYER ^TM, CDD^TMand CRD^TMare trademarks of National Semiconductor Corporation.

a

C

1995 National Semiconductor Corporation

TL/F/10387

RRD-B30M105/Printed in U. S. A.

Table of Contents

1.0 FDDI CHIP SET OVERVIEW

6.0 CONTROL INFORMATION

6.1 Conventions

2.0 ARCHITECTURAL DESCRIPTION

6.2 Access Rules

2.1 Ring Engine

2.2 Interfaces

6.3 Operation Registers

6.4 Event Registers

6.5 MAC Parameters

6.6 Timer Thresholds

6.7 Event Counters

3.0 FEATURE OVERVIEW

4.0 FDDI MAC FACILITIES

4.1 Symbol Set

4.2 Protocol Data Units

4.3 Frame Counts

4.4 Timers

7.0 SIGNAL DESCRIPTIONS

7.1 Control Interface

7.2 PHY Interface

4.5 Ring Scheduling

7.3 MAC Indication Interface

7.4 MAC Request Interface

7.5 Electrical Interface

7.6 Pinout Summary

5.0 FUNCTIONAL DESCRIPTION

5.1 Token Handling

5.2 Servicing Transmission Requests

5.3 Request Service Parameters

5.4 Frame Validity Processing

5.5 Frame Status Processing

5.6 SMT Frame Processing

5.7 MAC Frame Processing

5.8 Receive Batching Support

5.9 Immediate Frame Transmission

5.10 Full Duplex Operation

5.11 Parity Processing

7.7 Pinout Diagram

8.0 ELECTRICAL CHARACTERISTICS

8.1 Absolute Maximum Ratings

8.2 Recommended Operating Conditions

8.3 DC Electrical Characteristics

8.4 AC Electrical Characteristics

APPENDIX A. RING ENGINE STATE MACHINES

A.1 Receiver

A.2 Transmitter

2

1.0 FDDI Chip Set Overview

National Semiconductor’s DP83200 FDDI chip set consists

of five components as shown in Figure 1-1. For more infor-

mation on the other devices of the chip set, consult the

appropriate datasheets and application notes.

DP83261 BMAC^TMDevice

Media Access Controller

The BMAC device implements the Timed Token Media Ac-

cess Control protocol defined by the ANSI X3T9.5 FDDI

MAC Standard.

TM

a

Device Physical Layer Controller

DP83256/56-AP/57 PLAYER

Features

All of the standard defined ring service options

a

The PLAYER

device implements the Physical Layer

#

(PHY) protocol as defined by the ANSI FDDI PHY X3T9.5

Standard, along with all the necessary clock recovery and

clock regeneration functions.

Full duplex operation with through parity

#

Supports all FDDI Ring Scheduling Classes (Synchro-

nous, Asynchronous, etc.)

#

Features

Single chip FDDI Physical Layer (PHY) solution

Supports Individual, Group, Short, Long, and External

Addressing

#

Integrated Digital Clock Recovery Module provides en-

hanced tracking and greater lock acquisition range

Generates Beacon, Claim, and Void frames internally

#

Extensive ring and station statistic gathering

Integrated Clock Generation Module provides all neces-

sary clock signals for an FDDI system from an external

12.5 MHz reference

#

Extensions for MAC level bridging

Separate management port that is used to configure and

control operation

Alternate PMD Interface (DP83256-AP/57) supports

UTP twisted pair FDDI PMDs with no external clock re-

covery or clock generation functions required

#

Multi-frame streaming interface

#

DP83265A BSI-2 Device

System Interface

The BSI-2 device implements an interface between the

No External Filter Components

#

Connection Management (CMT) Support (LEM, TNE,

PC React, CF React, Auto Scrubbing)

Ð Ð

Full on-chip configuration switch

BMAC device and a host system.

#

Low Power CMOS-BIPOLAR design using a single 5V

supply

Features

#

Fully software and pin compatible with the original BSI

device

Full duplex operation with through parity

#

Separate management interface (Control Bus)

Over 2 kbytes of on-chip FIFO

#

Selectable Parity on PHY-MAC Interface and Control Bus

Interface

Operates from 12.5 MHz to 33 MHz synchronously with

host system

Two levels of on-chip loopback

4B/5B encoder/decoder

#

Provides Address bit swapping capability

#

Reduces interface logic for SBus adapters

Framing logic

32-bit wide Address/Data path with byte parity

Elasticity Buffer, Repeat Filter and Smoother

Line state detector/generator

Programmable transfer burst sizes of 4 or 8 32-bit words

Interfaces to DRAMs or directly to system bus

Supports single attach stations, dual attach stations and

concentrators with no external logic

2 Output and 3 Input Channels

Supports Header/Info splitting

#

DP83256/56-AP for SAS/DAS single path stations

P83257 for SAS/DAS single/dual path stations

#

Bridging support

Programmable Big or Little Endian alignment

In addition, the DP83257 contains an additional

PHY Data.request and PHY Data.indicate port required

for concentrators and dual attach stations.

Full duplex data path

Ð

Receive frame filtering services

#

3

2.0 Architectural Description

The BMAC device receivers, transmits, and strips or repeats

Protocol Data Units (PDUs, i.e., Tokens and Frames) and

handles the token management functions required by the

timed token protocol in accordance with the FDDI MAC

Standard.

Source Address. Frames with a Source Address matching

one of the station individual addresses are stripped by the

Ring Engine. Status is available at the MAC interface for

every transmitted frame.

For reception, the Ring Engine sequences through the in-

coming byte stream, comparing received destination ad-

dresses against the station’s short or long address. The re-

sults of these comparisons are made available at the MAC

interface. The System Interface then decides how to handle

the frame. In the normal case, a frame with a Destination

Address matching one of the station addresses is copied

and passed to the system.

The BMAC device is comprised of the Ring Engine (RE) and

interfaces to the Control Bus (Control Interface), the

PLAYER device (PHY Interface) and a System Interface

such as the BSI device (MAC Interface) as shown in

Figure 2-1.

On transmission, the system interface prepares one or more

frames for transmission and requests a service opportunity.

Based on the requested service class and requested token

type, the Ring Engine waits for a token meeting the request-

ed criteria. When a token is captured, the Ring Engine sig-

nals the interface and soon thereafter transmission begins.

After traversing the ring, frames are stripped based on the

The BMAC device utilizes a full duplex, byte-wide (symbol

pair) architecture. There are two bytes of delay in the Trans-

mit path, three bytes of delay in Receive and Repeat paths,

and two bytes of delay in the Loopback path.

TL/F/10387–2

FIGURE 2-1. BMAC Device Interfaces

4

2.0 Architectural Description (Continued)

2.1 RING ENGINE

lected. During Frame Repeating, data from the Receiver

Block is selected.

The BMAC device is operated by the Ring Engine which is

comprised of four blocks: Receiver, Transmitter, MAC Pa-

rameter RAM, and Counters/Timers as shown inFigure 2-2.

During Frame Transmission, the Transmitter Block performs

the following functions:

Captures a token to gain the right to transmit

#

2.1.1 Receiver

Transmits one or more frames

#

The Receiver Block accepts data from the PLAYER device

in the byte stream format (PH Indicate).

Ð

Upon receiving the data, the Receiver Block performs the

following functions:

Generates the Frame Check Sequence during transmis-

sion and appends it at the end of the frame

Generates the Frame Status field that is transmitted at

the end of the frame

#

Determines the beginning and ending of a Protocol Data

Unit (PDU)

#

Issues the token at the end of frame transmission

#

During Frame Repeating, the Transmitter Block performs

the following functions:

Decodes the Frame Control field to determine the PDU

type (frame or token)

#

Repeats the received frame and modifies the Frame

Status field at the end of the frame as specified by the

standard

#

Compares the received Destination and Source Address-

es with the internal addresses

#

Processes data within the frame

#

Whether transmitting or repeating frames, the Transmitter

Block also performs the following functions:

Calculates and checks the Frame Check Sequence at

the end of the frame

Strips the frame(s) that are transmitted by this station

#

Checks the Frame Status field

#

And finally, the Receiver Block presents the data to the

MAC Interface along with the appropriate control signals

(MA Indicate).

Ð

Generates Idle symbols between frames

#

Data is presented from the Transmitter Block to the

PLAYER device in the byte stream format (PH Request).

Ð

2.1.3 MAC Parameter RAM

2.1.2 Transmitter

The MAC Parameter RAM block is a dual port RAM that

contains MAC parameters such as the station’s short and

long addresses. These parameters are initiallzed via the

Control Interface. Both the Receiver and Transmitter Blocks

may access the RAM.

The Transmitter Block inserts frames from this station into

the ring in accordance with the FDDI Timed Token MAC

protocol. It also repeats frames from other stations in the

ring. The Transmitter block multiplexes data from the MA

Ð

Request Interface and data from the Receiver Block. During

Frame Transmission, data from the Request Interface is se-

TL/F/10387–4

FIGURE 2-2. Ring Engine Overview Block Diagram

5

2.0 Architectural Description (Continued)

The Receiver uses these parameters to compare addresses

in incoming frames with its addresses stored in the Parame-

ter RAM.

The MAC Interface is synchronous and is divided into sepa-

rate MAC Request and MAC Indication interfaces.

Data is transferred from the system interface to the Ring

Engine via the MAC Request Interface. The MA Request

The Transmitter uses the Parameter RAM for generating the

Source Address for all frames (except when Source Ad-

dress Transparency is enabled) and for the Destination Ad-

dress and Information fields in Claim and Beacon frames.

Ð

Interface consists of a parity bit (Odd parity) and byte-wide

data along with the transmit parameters and handshake sig-

nals. The MAC Request Interface utilizes a handshake that

separates token capture from data transmisson. A captured

token may be held until it is no longer usable. Void frames

are automatically generated to allow data interface logic as

much time as it needs to prepare a transmission.

The MAC Parameter RAM block is described in greater de-

tails in Section 6.5.

2.1.4 Counter/Timer

The Counter/Timer block maintains all of the Counters and

Timers required by the Standard.

Data is transferred from the Ring Engine to the system inter-

face via the MAC Indication Interface. The MA Indicate

Ð

Events which occur too rapidly for software to count, such

as the various Frame Counts, are included in the Event

Counters. The size of the wrap around counters has been

chosen to require minimal software intervention even under

marginal operating conditions. Most of the Counters incre-

ment in response to events detected by the Receiver. The

Counters are readable via the Control Interface.

Interface consists of a parity bit (Odd parity) and byte-wide

data along with Addressing Flags and Frame Sequencing

signals. The Addressing Flags give the result of the address

comparisons performed by the Ring Engine. These are used

to decide whether to continue to copy or to reject frames.

The MAC Indication Interface also accepts inputs to deter-

mine how to set the control indicators and increment the

statistical counters based on external address comparison

logic and frame copying logic. Frames may also be stripped

based on external comparisons.

The Token Rotation and Token Holding Timers which are

used to implement the Timed Token Protocol are contained

within the Timer Block.

The Counters and Timers are described in detail in Sections

6.6 and 6.7.

2.2.3 Control Bus Interface

The Control Interface implements the interface to the Con-

trol Bus by which to initialize, monitor and diagnose the op-

eration of the BMAC device. The Control Interface is an

8-bit asynchronous interface in order to minimize pinout and

layout. All information that must be synchronized with the

data stream crosses the MAC Interface.

2.2 INTERFACES

2.2.1 PHY Interface

The PHY Intreface is a synchronous interface that provides

a

an encoded byte stream to the PLAYER device (the PHY

Request byte stream), and receives an encoded byte

a

stream from the PLAYER device (the PHY Indication byte

stream).

The Control bus is separated completely from the MAC and

PHY Interfaces in order to allow independent operation of

the processor on the Control Bus. The Control Interface

provides the synchronization between the Control Bus and

the Ring Engine.

a

The BMAC device connects to one or two PLAYER devic-

es via the PH Indicate and PH Request Interfaces.

Ð

a

Data is transferred from the PLAYER device to the Ring

3.0 Feature Overview

Engine via the PH Indicate Interface. Data is transferred

Ð

a

from the Ring Engine to the PLAYER device via the PH

Request Interface.

The BMAC device implements the standard FDDI MAC pro-

tocol. It also provides additional addressing, bridging, and

service class functions to allow maximal flexibility in design-

ing an FDDI station.

Ð

The 10-bit byte transferred in both directions across the

PH Indicate and PH Request interfaces consists of one

Ð

parity bit (Odd parity), one Control bit, and 8 bits of data.

The Control Bit determines if the 8 data bits are a data

symbol pair or a control symbol pair.

The BMAC device offers extensive diagnostic features in-

cluding a number of diagnostic counters, a dedicated inter-

face for control and configuration, and a capability to per-

form Self Testing. Furthermore, the BMAC device allows the

tuning of certain parameters to increase the performance of

the network.

2.2.2 MAC Interface

The MAC Interface provides the required information and

handshakes to allow a system interface (such as the

DP83265A BSI-2) to exploit the capabilities of the Ring En-

gine.

6

3.0 Feature Overview (Continued)

3.1 FDDI MAC SUPPORT

These counters allow measurement of the following:

The BMAC device implements the Standard ANSI X3T9.5

FDDI MAC protocol for transmitting, receiving, repeating

and stripping frames. Many of the capabilities defined in

MAC-2 are included in the BMAC device such as bridging

end station support for setting the control indicators, and

the statistic counters. The BMAC device provides all of the

information necessary to implement the service primitives

defined in the standard.

Number of frames transmitted and received by the sta-

tion

#

Number of frames copied as well as frames not copied

because of insufficient buffering

#

Frame error rate of an incoming physical connection to

the MAC

#

Load on the ring based on the number of tokens re-

ceived and the ring latency

#

The BMAC device also implements many of the permitted

extensions to the FDDI-MAC standard as captured in the

FDDI MAC-2 document. These include the extensions for

MAC level bridging, Group Addressing support that can be

used for SMT, reporting of additional events to aid the ring

management processes and enhanced versions of the state

machines.

Ring latency

#

Lost frames

The size of these counters has been selected to keep the

frequency of overflow small, even under worst case operat-

ing conditions.

3.6 MANAGEMENT SERVICES

3.2 MAC ADDRESSING SUPPORT

The BMAC device provides management services to the

Host System via the Control Bus Interface. This interface

allows access to internal registers to control and configure

the BMAC device.

Both long (48-bit) and short (16-bit) addressing are support-

ed simultaneously, for both Individual and Group addresses.

Up to 128 contiguous programmable group addresses and

up to 15 Fixed Group Addresses plus the universal/broad-

cast address are recognized. Limited operation with null ad-

dresses is supported. An interface to external address

matching logic is provided to augment the Ring Engine’s

addressing capabilities.

3.7 RING PARAMETER TUNING

The BMAC device includes settable parameters to allow

tuning of the network to increase performance over a large

range of network sizes.

The BMAC device supports systems of two stations with

little cable between them to ring configurations much larger

than the 1000 physical attachments and/or 200 km dis-

tance that are specified as the default values in the stan-

dard.

3.3 MAC BRIDGING SUPPORT

Several features are provided to aid in Bridging applications.

On the receive side, external address matching logic can be

used to examine the PH Indicate byte stream to decide

Ð

whether to copy a frame, how to set the control indicators

and how to increment the counters.

The BMAC device also handles frames larger than the 4500

byte default maximum frame size as specified in the Stan-

dard.

On the transmit side, transparency options are provided on

the Source Address, the most significant bit of the Source

Address, and the FCS.

3.8 MULTI-FRAME STREAMING INTERFACE

The BMAC device provides an interface to support a multi-

frame streaming interface. Multiple frames can be transmit-

ted after a token is captured within the limits of the token

timer thresholds.

In addition, support for an alternate Void stripping mecha-

nism provides maximal flexibility in the generation of frames.

3.4 MAC SERVICE CLASS SUPPORT

All of the FDDI MAC service classes are supported by the

BMAC device. These include the Synchronous, Asynchro-

nous, Restricted Asynchronous, and Immediate service

classes.

3.9 GENERATES BEACON, CLAIM,

AND VOID FRAMES INTERNALLY

For purposes of transient token and ring recovery, no proc-

essor intervention is required. The BMAC device automati-

cally generates the appropriate MAC frames.

For Synchronous transmission, one or more frames are

transmitted in accordance with the station’s synchronous

bandwidth allocation.

3.10 SELF TESTING

Because the BMAC device is full duplex, loopback testing is

possible before entering the ring and during normal ring op-

eration.

For Asynchronous transmission, one programmable asyn-

chronous priority threshold is supported in addition to the

threshold at the Negotiated Target Token Rotation time.

There are several posible loopback paths:

For Restricted Asynchronous transmission, support is pro-

vided to begin, continue and end restricted dialogues.

internal to the BMAC device

#

For Immediate transmissions, support is provided to send

frames from either the Data, Beacon or Claim states and

either ignore or respond to the received byte stream. After

an immediate transmission a token may optionally be is-

sued.

through the PLAYER device(s) using the PLAYER device

configuration switch

#

through the CRD device.

#

These paths allow error isolation down to the device level.

The BMAC device also supports through parity.

3.5 DIAGNOSTIC COUNTERS

The BMAC device includes a number of diagnostic counters

that monitor ring and station performance.

7

4.0 FDDI MAC Facilities

4.1 SYMBOL SET

4.2 PROTOCOL DATA UNITS

The Ring Engine recognizes and generates a set of sym-

bols. These symbols are used to convey Line States (such

as the Idle Line State), Control Sequences (such as the

Starting and Ending Delimiters) and Data.

The Ring Engine recognizes and generates two types of

Protocol Data Units (PDUs): Tokens and Frames.

The Token is used to control access to the ring. Only the

station that has captured the token has the right to transmit

new information. The format of a token is shown in Figure

4-1.

Additional information regarding the symbol set can be

found in the FDDI PHY Standard.

The Ring Engine expects that the Starting Delimiter will al-

ways be conveyed on an even symbol pair boundary. Fol-

lowing the starting delimiter, data symbols should always

come in matched pairs. Similarly the Ending Delimiter

should always come in one or more matched symbol pairs.

SFS

PA SD

EFS

FC

ED

FIGURE 4-1. Token Format

Frames are used to pass information between stations. The

format of a frame is shown in Figure 4-2 with the field defini-

tions in Table 4-2.

The symbol pairs conveyed at the PHY Interface are shown

in Table 4-1.

SFS

Protected by PCS

EFS

PA SD FC DA SA INFO FCS ED FS

FIGURE 4-2. Frame Format

TABLE 4-1. Symbol Pair Set

Type

Starting Delimiter

Ending Delimiter

Frame Status

Symbols

JK

TT or TR or TS or nT

RR or RS or SR or SS

ll or nl

Idle

Data Pair

nn

Note : n represents any data symbol (0–F).

Symbol pairs others than the defined symbols are treated as code violations.

Section 7.2 has additional information on the symbol pairs generated and interpreted by the Ring Engine.

TABLE 4-2. PDU Fields

Name

SFS

PA

Description

Start of Frame Sequence

Preamble

Size

8 or More Idle Symbol Pairs

JK Symbol Pair

SD

Starting Delimiter

FC

Frame Control Field

Destination Address

Source Address

1 Data Symbol Pair

2 or 6 Symbol Pairs

DA

SA

INFO

FCS

EFS

ED

Information Field

Frame Check Sequence

End of Frame Sequence

Ending Delimiter

4 Symbol Pairs

At Least 1T Symbol for Frames;

At Least 2T Symbols for Tokens

FS

Frame Status

3 or More R or S Symbols

8

4.0 FDDI MAC Facilities (Continued)

4.2.1 PDU Fields

TABLE 4-4. MAC/SMT Frames Types

Start of Frame Sequence

CLFF

1000

1100

0L00

rZZZ

0000

PDU Type

Non-Restricted Token

Restricted Token

Void Frame

The Start of Frame Sequence (SFS) consists of the Pream-

ble (PA) followed by the Starting Delimiter (SD).

The Preamble is a sequence of zero or more Idle symbols

that is used to separate the PDUs. The Ring Engine Receiv-

er can process and repeat a frame or token with no pream-

ble. The Ring Engine Transmitter generates frames with at

least 8 bytes of preamble. The Ring Engine Transmitter also

guarantees that valid FDDI frames will never be transmitted

with more than 40 bytes of preamble.

0001 to

1110

SMT Frame

0L00

1111

SMT Next Station

Addressing Frame

The Starting Delimiter is used to indicate the start of a new

PDU. The Starting Delimiter is the JK symbol pair.

1L00

0001

0010

0011

Other MAC Frame

MAC Beacon Frame

MAC Claim Frame

Other MAC Frame

The Ring Engine expects the Starting Delimiter to be con-

veyed across the PH Indication Interface as a single byte.

Ð

Similarly, the Ring Engine only generates Starting Delimiters

aligned to the byte boundary.

0100 to

1111

Frame Control

The Frame Control (FC) field is used to discriminate PDUs.

For tokens, the FC field identifies Restricted and Non-re-

stricted tokens. For frames, the FC field identifies the frame

types and format and how the frame is to be processed.

Destination Address

The Destination Address (DA) field is used to specify the

station(s) that should receive and process the frame.

The DA can be an Individual or Group address. This is de-

termined by the Most Significant Bit of the DA (DA.IG).

When DA.IG is 0 the DA is an Individual Address, when

DA.IG is 1 the DA is a Group Address. The Broadcast/Uni-

versal address is a Group Address.

The one byte FC field is formatted as shown in Figure 4-3.

C

L

FF

r

ZZZ

FIGURE 4-3. Frame Control Field

The C (Class) bit specifies the MAC Service Class as Asyn-

e

1).

The DA field can be a Long or Short Address. This is deter-

mined by the L bit in the FC field (FC.L). If FC.L is 1, the DA

is a 48-bit Long Address. If FC.L is 0, the DA is a 16-bit

Short Address.

e

chronous (C

0) or Synchronous (C

The L (Length) bit specifies the length of the MAC Address

e

1). A Short Address is a 16-

e

bit address. A Long Address is a 48-bit address.

as Short (L

0) or Long (L

The Ring Engine maintains both a 16-bit Individual Address,

My Short Address (MSA) and a 48-bit Individual Address,

My Long Address (MLA).

The FF (Format) bits specify the PDU types as shown in

Table 4-3.

The r (Reserved) bit is currently not specified and should

always be transmitted as Zero (Exception: SMT NSA

Frames).

On the receive side, if DA.IG is 0 the incoming DA is com-

e

0). If the

received DA matches MLA or MSA the frame is intended for

pared with MLA (if FC.L

1) or MSA (if FC.L

this station and the address recognized flag (A Flag) is set.

The ZZZ (Control) bits are used in conjunction with the C

and FF bits to specify the type of PDUs. These bits may be

used to affect protocol processing criteria such as the Priori-

ty, Protocol Class, Status Handling, etc.

Ð

If DA.IG is 1, the DA is a Group Address and is compared

with the set of Group Addresses recognized by the Ring

Engine. If a match occurs the address recognized flag

(A Flag) is set. The A Flag is used by system inter-

Ð

TABLE 4-3. Frame Control Format Bits

face logic as part of the criteria (with FC.L, DA.IG and

Flag) to determine whether or not to copy the frame. If

M

Ð

the A flag is set, the system interface will normally attempt

FC.FF

PDU Types

Ð

to copy the frame.

0

1

0

1

0

1

SMT/MAC

LLC

On the transmit side, the DA is provided by the system inter-

face logic as part of 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 also passed in the data stream.)

The Destination Address can be an Individual, Group, or

Broadcast Address.

Reserved for Implementer

Reserved for Future Standardization

When the Frame Control Format bits (FC.FF) indicate a

SMT or MAC PDU, the frame type is identified as shown in

Table 4-4.

Source Address

The Source Address (SA) field is used to specify the ad-

dress of the station that originally transmitted the frame.

9

4.0 FDDI MAC Facilities (Continued)

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).

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

Frame Status Indicators (FS).

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

Ð

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.

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.

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.

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

4.2.2 Token Formats

The Ring Engine supports non-restricted and restricted To-

kens. See Figures 4-4 and 4-5.

Engine provides a Void Stripping Option. See Section

7.4.2.4 for futher information.)

SFS

FC

EFS

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.

SD

80

ED

FIGURE 4-4. Non-Restricted Token Format

SFS

FC

ED

Information

SD

C0

ED

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.

FIGURE 4-5. Restricted Token Format

Non-Restricted

A non-restricted token is used for synchronous and non-re-

stricted asynchronous transmissions.

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.

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).

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.

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.

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.

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.

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.

4.2.3 Frame Formats

On the receive side, the Ring Engine checks the FCS to

determine whether the frame is valid or corrupted.

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.

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).

10

4.0 FDDI MAC Facilities (Continued)

Frames Generated Externally

Frames Generated by the Ring Engine

The Ring Engine transmits frames passed to it from the Sys-

tem Interface. The data portion of the frame is created by

the System Interface. This begins with the FC field and ends

with the last byte of the INFO field. The FC field is passed

transparently to the ring. The length bit in the FC field is

used to determine the length of the transmitted addresses.

The data is passed as a byte stream across the MAC Re-

quest Interface as shown in Table 4-5.

The Ring Engine generates and detects several frames in

order to attain and maintain an operational ring.

Void Frames

Void frames are used during normal operation. The Ring

Engine generates two types of void frames: regular Void

frames and My Void frames. See Table 4-6.

Ð

If short addressing is enabled, Void frames with the short

address are transmitted, otherwise Void frames with the

long address are transmitted.

Before the frame is transmitted, the Ring Engine inserts the

Start of Frame Sequence with at least 8 bytes of Preamble

but no more than 40 bytes of Preamble. The starting delimi-

ter is transmitted as a JK symbol pair. The Source Address

is normally transmitted by the Ring Engine since it uses the

Source Address to strip the frame from the ring. This can be

overridden by using the Source Address transparency capa-

bility. Similarly, the Frame Check Sequence (4 bytes) is nor-

mally transmitted by the Ring Engine. This can be overrid-

den with the FCS transparency capability. With FCS trans-

parency, the FCS is transmitted from the data stream. The

End of Frame Sequence is always transmitted by the Ring

Engine as TR RR.

Void frames are transmitted in order to reset the Valid

Transmission timers (TVX) in other stations in order to elimi-

nate an unnecessary entry to the Claim state. Stations are

not required to copy Void frames. Void frames are transmit-

ted by the Ring Engine in two situations:

1. While holding a token when no data is ready to be trans-

mitted.

2. After a frame transmission is aborted.

My Void frames are transmitted by the Ring Engine in

Ð

three situations:

1. After a request to measure the Ring Latency has been

made when the next early token is captured.

Frames transmitted by the Ring Engine must have a valid

DA and SA field. If the end of a frame is reached before a

valid length is transmitted, the frame will be aborted and a

Void frame will be transmitted.

2. After this station wins the Claim Process before the token

is issued.

3. After a frame has been transmitted with the STRIP option

before the token for that service opportunity is issued.

TABLE 4-5. Frame Formats

Field

PA

Size

MA Request

Ð

PH Request

Ð

Void frames are also detected by the Ring Engine. A Void

frame with a Source Address other than MSA or MLA is

considered an Other Void frame.

Ð

t

s

8; 40

Idle Pairs

JK

SD

1

Claim Frames

FC

DA

SA

FC

Claim frames are generated continuously with minimum pre-

amble while the Ring Engine is in the Transmit Claim state.

DA

SA

2 or 6

DA

The format of Claim frames generated by the Ring Engine is

shown in Table 4-7. When long addressing is enabled,

frames with the long address are transmitted, otherwise

frames with the short address are transmitted.

MSA, MLA,

or SA

t

INFO

FCS

ED

0

INFO

FCS

INFO

FCS

TR

The Ring Engine detects reception of valid Claim frames. A

comparison is performed between the (first) four bytes of

the received INFO field and TREQ in order to distinguish

Higher Claim, Lower Claim, and My Claim. Details are

4 if Present

1

Ð

FS

RR

given in Appendix A.

TABLE 4-6. Void Frames

Type

Enable

ESA

Size

Short

Long

Short

Long

SFS

FC

00

40

00

40

DA

Null

MSA

MLA

SA

FCS

EFS

Void

PA

SD

MSA

MLA

MSA

MLA

FCS

TRRR

Not ESA

ESA

My Void

Ð

My Void

Ð

Not ESA

TABLE 4-7. Claim Frames

Type

Enable

Not ELA

ELA

Size

SFS

FC

83

C3

DA

SA

INFO

FCS

EFS

My Claim

Ð

Short

Long

PA

SD

MSA

MLA

MSA

MLA

TREQ

FCS

TRRR

My Claim

Ð

11

4.0 FDDI MAC Facilities (Continued)

Beacon Frames

4.3.3 Lost Frame Count

Beacon frames are transmitted continuously with minimum

preamble when the Ring Engine is in the Transmit Beacon

state. The format of Beacon frames generated by the Ring

Engine is shown in Table 4-8. When long addressing is en-

abled, frames with the long address are transmitted, other-

wise frames with the short address are transmitted.

The Lost Frame Count (LFCT) is specified in the FDDI MAC

Standard, and is the count of all instances where a format

error is detected in a frame or token such that the credibility

of PDU reception is placed in doubt. The Lost Frame Count

is incremented when any symbol other than data or Idle

symbols are received between the Starting and Ending Del-

imiters of a PDU (this includes parity errors).

When the Transmit Beacon State is entered from the Trans-

mit Claim State the first byte of the 4 byte TBT Field is

transmitted as Zero.

4.3.4 Frame Copied Count

The Frames Copied Count (FCCT) is specified in the FDDI

MAC-2 Standard, and is the count of the number of frames

copied by this station. The count is incremented when an

internal or external match occurs (when Option.EMIND is

enabled) on the Destination Address, no errors were detect-

ed in the frame and the frame was successfully copied

e

formance statistics. Frames copied promiscuously, MAC

frames, Void frames and NSA frames received with the A

indicator set are not included in this count.

Beacon frames that require alternative formats such as Di-

rected Beacons must be generated externally.

The Ring Engine detects reception of valid Beacon frames

and distinguishes between Beacon frames transmitted by

this MAC (My Beacon) and Beacon frames transmitted by

Ð

other stations (Other Beacon). Details are given in Appen-

Ð

dix A.

(VCOPY

1). This can be used to accumulate station per-

4.3 FRAME COUNTS

To aid in fault isolation and to enhance the management

capabilities of a ring, the Ring Engine maintains several

frame counts. The Error and Isolated frame counts incre-

ment when a frame is received with one or more errors that

were previously undetected. The Ring Engine then corrects

the error such that a downstream station will not increment

its count.

4.3.5 Frames Not Copied Count

The Frames Not Copied Count (FNCT) is specified in the

FDDI MAC-2 Standard, and is the count of frames intended

for this station that were not successfully copied by this

station. The count is incremented when an internal or exter-

nal (when Option.EMIND is enabled) Destination Address

match occurs, no errors were detected in the frame, and the

The size of the counters has been chosen such that minimal

software intervention is required, even under marginal oper-

ating conditions.

e

frame was not successfully copied (VCOPY

0). This

count is an indication of insufficient buffering or frame pro-

cessing capability for frames addressed to the station. MAC

frames, Void frames and NSA frames received with the A

indicator set are not included in this count.

The following counts are maintained by the Ring Engine:

FRCT

EICT

Frame Received

Error Isolated

4.3.6 Frames Transmitted Count

LFCT

FCCT

FNCT

FTCT

Lost Frame

The Frames Transmitted Count (FTCT) is specified in the

FDDI MAC-2 Standard, and is incremented every time a

complete frame is transmitted from the MAC Request Inter-

face. The count is provided as an aid to accumulate station

performance statistics. Void and MAC frames generated by

the Ring Engine are not included in the count.

Frames Copied

Frames Not Copied

Frames Transmitted

4.3.1 Frame Received Count

The Frame Received Count (FRCT) is specified in the FDDI

MAC Standard, and is the count of all complete frames re-

ceived. This count includes frames stripped by this station.

4.4 TIMERS

4.4.1 Token Rotation Timer

4.3.2 Error Isolated Count

The Token Rotation Timer (TRT) times token rotations from

arrival to arrival. TRT is used to control ring scheduling dur-

ing normal operation and to detect and recover from serious

ring error situations.

The Error Isolated Count (EICT) is specified in the FDDI

MAC Standard, and is the count of error frames detected by

this station and no previous station. It increments when:

1. An FCS error is detected and the received Error Indicator

(Er) is not equal to S.

TRT is loaded with the maximum token rotation time, TMAX,

when the ring is not operational. TRT is loaded with the

negotiated Target Token Rotation Time, TNEG, when the

ring is operational.

2. A frame of invalid length (i.e., off boundary T) is received

and Er is not equal to S.

3. Er is not R or S.

TABLE 4-8. Beacon Frames

Type

Enable

Not ELA

ELA

Size

Short

Long

SFS

FC

82

C2

DA

Null

SA

INFO

TBT

FCS

EFS

My Beacon

Ð

PA

SD

MSA

MLA

TRRR

My Beacon

Ð

12

4.0 FDDI MAC Facilities (Continued)

4.4.2 Token Holding Timer

The Latency Counter increments every 16 byte times

(1.28 ms) and is used to measure ring latencies up to

1.3421772 seconds directly with an accuracy of 1.2 ms. No

overflow or increment event is provided with this counter.

The Token Holding timer (THT) is used to limit the amount

of ring bandwidth used by a station for asynchronous traffic

once the token is captured. THT is used to determine if the

captured token is (still) usable for asynchronous transmis-

sion. A token is usable for asynchronous traffic if THT has

not reached the selected threshold. Two asynchronous

thresholds are supported; one that is fixed at the Negotiated

Target Token Rotation Time (TNEG), and one that is pro-

grammable at one of 16 Asynchronous Priority Thresholds.

Requests to transmit frames at one of the priority thresholds

are serviced when the Token Holding Timer (THT) has not

reached the selected threshold.

4.5 RING SCHEDULING

FDDI uses a timed token protocol to schedule the use of the

ring. The protocol measures load on the network by timing

the rotation of the token. The longer the token rotation time

the greater the instantaneous load on the network. By limit-

ing the transmission of data when the token rotation time

exceeds a target rotation time, a maximum average token

rotation time is realized. The protocol is used to provide

different classes of service.

4.4.3 Late Count

Multiple classes of service can be accommodated by setting

different target token rotation times for each class of serv-

ice.

The Late Count (LTCT) is implemented differently than sug-

gested by the Standard, but provides similar information.

The function of the Late Count is divided beween the Late

Ð

The Ring Engine supports Synchronous, Non-Restricted

Asynchronous, Restricted Asynchronous, and Immediate

service classes. The Immediate service class is supported

when the ring is non-operational; the other classes are sup-

ported when the ring is operational.

Flag that is equivalent to the standard Late Count with a

non-zero value and a separate counter. Late Flag is main-

tained by the Ring Engine to indicate if it is possible to send

asynchronous traffic. When the ring is operational, Late

Count indicates the time it took the ring to recover the last

time the ring went non-operational. When the ring is non-op-

erational, Late Count indicates the time it has taken (so far)

to recover the ring.

4.5.1 Synchronous Service Class

The Synchronous service class may be used to guarantee a

maximum response time (2 times TTRT), minimum band-

width, or both.

The Late Count is incremented every time TRT expires

while the ring is non-operational and Late Flag is set (once

every TMAX).

Each time the token arrives, a station is permitted to trans-

mit one or more frames in accordance with its synchronous

bandwidth allocation regardless of the status of the token

(late or early; Restricted or Non-Restricted).

Ð

The Late Count is provided to assist Station Management,

SMT, in the isolation of serious ring errors. In many situa-

tions the ring will recover very quickly and late count will be

of marginal utility. However in the case of serious ring er-

rors, it is helpful for SMT to know how long it has been since

the ring went non-operational (with TMAX resolution) in or-

der to determine if it is necessary to invoke recovery proce-

dures. When the ring goes no operational there is no way to

know how long it will stay non-operational, therefore a timer

is necessary. If the Late Count were not provided, SMT

would be forced to start a timer every time the ring goes

non-operational even though it may seldom be used. By us-

ing the provided Late Count, an SMT implementation may

be able to alleviate this additional overhead.

Since the Ring Engine does not provide a mechanism for

monitoring a station’s synchronous bandwidth utilization,

the user must insure that no synchronous request requires

more than the allocated bandwidth.

To help ensure that synchronous bandwidth is properly allo-

cated after ring configuration, synchronous requests are not

serviced after a Beacon frame is received. After a major

reconfiguration has occurred, management software must

intervene to verify or modify the current synchronous band-

width allocation.

4.5.2 Non-Restricted Asynchronous Service Class

The Non-Restricted Asynchronous service class is typically

used with interactive and background traffic. Non-restricted

Asynchronous requests are serviced only if the token is ear-

ly and the Token Holding Timer has not reached the select-

ed threshold.

4.4.4 Valid Transmission Timer

The Valid Transmission Timer (TVX) is reset every time a

valid PDU is received. TVX is used to increase the respon-

siveness of the ring to errors. Expiration of the TVX indi-

cates that no PDU has been received within the timeout

period and causes the Transmitter to invoke the recovery

Claim Process.

Asynchronous service is available at two priority thresholds,

the Negotiated Target Token Rotation Time plus one pro-

grammable threshold. Management software may use the

priority thresholds to discriminate additional classes of traf-

fic based on current loading characteristics of the ring. The

priority thresholds may be determined using the current

TTRT and the Ring Latency. In this case, application soft-

ware is only concerned with the priority level of a request.

4.4.5 Token Received Count

The Token Received Count (TKCT) is incremented every

time a valid token arrives. The Token Count can be used

with the Ring Latency Count to calculate the average net-

work load over a period of time. The frequency of token

arrival is inversely related to the network load.

As an option, Asynchronous Requests may be serviced with

THT disabled. This is useful when it is necessary to guaran-

tee that a multi-frame request will be serviced on a single

token opportunity. Because of the possibility of causing late

tokens, this capability should be used with caution, and

should only be allowed when absolutely necessary.

4.4.6 Ring Latency Count

The Ring Latency Count (RLCT) is a measurement of time

for PDUs to propagate around the ring. This counter con-

tains the last measured ring latency whenever the Ring La-

tency Valid bit of the Token Event Register (TELR.RLVLD)

is one.

13

4.0 FDDI MAC Facilities (Continued)

4.5.3 Restricted Asynchronous Service Class

Immediate requests are only serviced when the ring is non-

operational. Immediate requests may be serviced from the

Transmitter Data, Claim, and Beacon states Options are

available to force the Ring Engine to enter the Claim or

Beacon state, to prohibit it from entering the Claim state, or

The Restricted Asynchronous service class is useful for

large transfers requiring all of the available Asynchronous

bandwidth. The Restricted Token service is useful for large

transfers requiring all of the available (remaining) asynchro-

nous bandwidth.

to remain in the Claim state when receiving My Claim.

Ð

On the completion of an Immediate request, a Token (Non-

restricted or Restricted) may optionally be issued. Immedi-

ate requests may also be used in non-standard applications

such as a full duplex point to point link.

The Restricted Token service may also be used for opera-

tions requiring instantaneous allocation of the remaining

synchronous bandwidth when Restricted Requests are

serviced with THT disabled. This is useful when it is neces-

sary to guarantee atomicity, i.e., that a multi-frame request

will be serviced on a single token opportunity.

5.0 Functional Description

5.1 TOKEN HANDLING

A Restricted dialogue consists of three phases:

1. Initiation of a Restricted dialogue:

5.1.1 Token Timing Logic

Capture a Non-Restricted Token

#

The FDDI Ring operates based on the Timed Token Rota-

tion protocol where all stations on the ring negotiate on the

maximum time that the stations have to wait before being

able to transmit frames. This value is termed the Negotiated

Target Token Rotation Time (TTRT). The TTRT value is

stored in the TNEG Register.

Transmit zero or more frames to establish a Restricted

dialogue with other stations

#

Issue a Restricted Token to allow other stations in the

dialogue to transmit frames

#

2. Continuation of a Restricted dialogue:

Stations negotiate for TTRT based on their TREQ that is

assigned to them upon initialization.

Capture a Restricted Token

#

Transmit zero or more frames to continue the Restrict-

ed dialogue

Each station keeps track of the token arrival by setting the

Token Rotation Timer (TRT) to the TTRT value. If the token

is not received within TTRT (the token is late), the event is

recorded by setting the Late Flag. If the token is not re-

Ð

ceived within twice TTRT (TRT expires and Late Flag is

Ð

set), there is a potential problem in the ring and the recovery

Issue a Restricted Token to allow other stations in the

dialogue to transmit frames

#

3. Termination of a Restricted dialogue:

Capture a Restricted Token

#

process is invoked.

Transmit zero or more frames to continue the Restrict-

ed dialogue

Furthermore, the Token Holding Timer (THT) is used to limit

the amount of ring bandwidth used by a station for Asyn-

chronous traffic once the token is captured. Asynchronous

Issue a Non-restricted Token to return to the Non-re-

stricted service class

#

traffic is prioritized based on the Late Flag which denotes

Ð

Initiation of a Restricted dialogue will prevent all Non-re-

stricted Asynchronous traffic throughout the ring for the du-

ration of the dialogue, but will not affect Synchronous traffic.

a threshold at TTRT and an additional Asynchronous Priori-

ty Threshold (THSH). The Asynchronous Threshold com-

parison (Apri 1) is pipelined, so a threshold crossing may not

be detected immediately; however, the possible error is a

fraction of the precision of the threshold values.

To ensure that the Restricted traffic is operating properly, it

is possible to monitor the use of Restricted Tokens on the

ring. When a Restricted Token is received, the event is

latched and under program control may generate an inter-

rupt. In addition, a request to begin a Restricted dialogue

will only be honored if both the previous transmitted Token

and the current received Token were Non-restricted tokens.

This is to ensure that the upper bound on the presence of a

Restricted dialogue in the ring is limited to a single dialogue.

The Token Timing Logic consists of two Timers, TRT and

THT, in addition to the TMAX and TNEG values loaded into

these counters (See Figure 5-1 ).

The Timers are implemented as count-up counters that in-

crement every 80 ns. The Timers are reset by loading TNEG

or TMAX into the counters where TNEG and TMAX are un-

signed twos complement numbers. This allows a Carry flag

to denote timer expiration.

As suggested by the MAC-2 Draft standard, to help ensure

that only one Restricted dialogue will be in progress at any

given time, Restricted Requests are not serviced after a

MAC frame is received until Restricted Requests are explic-

itly enabled by management software. Since the Claim Pro-

cess results in the generation of a Non-restricted Token,

this prevents stations from initiating another restricted dia-

logue without the intervention of management software.

On an early token arrival (Late Flag is not set), TRT is

Ð

loaded with TNEG and counts up. On a late token arrival

(Late Flag is set), Late Flag is cleared and TRT contin-

Ð

ues to count. When TRT expires and Late Flag is not set,

Ð

Late Flag is set and TRT is loaded with TNEG.

Ð

THT follows the value of TRT until a token is captured.

When a token is captured, TRT may be reloaded with TNEG

while THT continues to count from its previous value (THT

does not wrap around). THT increments when enabled. THT

is disabled during synchronous transmission and a special

class of asynchronous transmission. THT is used to deter-

mine if the token is usable for asynchronous requests.

4.5.4 Immediate Service Class

The Immediate service class facilitates several non-stan-

dard applications and is useful in ring failure recovery (e.g.,

Transmission of Directed Beacons). Certain ring failures

may cause the ring to be unusable for normal traffic, until

the failure is remedied.

14

5.0 Functional Description (Continued)

TL/F/10387–3

FIGURE 5-1. Token Timing Logic

If TRT expires while Late Flag is set, TRT is loaded with

Ð

own Beacon frame. That station then enters the Claim Pro-

cess, to re-initialize the ring.

TMAX and the recovery process (Claim) is invoked. When

TRT expires and the ring is not operational, TRT is loaded

with TMAX. TRT is also loaded with TMAX on a MAC Reset.

5.2 SERVICING TRANSMISSION REQUESTS

A Request to transmit one or more frames is serviced by the

Ring Engine. After a Request is submitted to the Ring En-

gine, the Ring Engine awaits an appropriate Service Oppor-

tunity in which to service the Request. Frames associated

with the Request are transmitted during the Service Oppor-

tunity. The definition of a Service Opportunity is different

depending on the operational state of the ring.

5.1.2 Token Recovery

While the ring is operational, every station in the ring uses

the Negotiated Target Token Rotation Time, TNEG. The

MAC implements the protocol for negotiation of this target

token rotation time (TTRT) through the Claim Process. The

shortest requested Token Rotation Time is used by all of

the stations in the ring as the TNEG.

A Service Opportunity begins when the criteria presented to

the Ring Engine are met. This criteria contains the request-

ed service class (synch, asynch, asynch priority, immediate)

and the type of token to capture (restricted, non-restricted,

any, none).

If TRT expires with Late Flag set, a token has not been

Ð

received within twice TTRT (Target Token Rotation Time). If

TVX (Valid Transmission Timer) expires, the station has not

received a valid token within TVX Max. Both these events

require token recovery and cause the Ring Engine to enter

the Claim Process.

During a service opportunity, the Ring Engine guarantees

that a valid frame is sent with at most 40 bytes of preamble.

When data is not ready to be transmitted, Void frames are

transmitted to reset the TVX timers in all stations. During an

immediate request while in the Claim or Beacon States,

when no Claim or Beacon frames are ready to be transmit-

ted, the internally generated Claim or Beacon frames are

transmitted.

In the Claim Process a MAC continuously transmits Claim

frames containing TREQ. Should the MAC receive a Claim

frame with a shorter TREQ (larger valueÐHigher Claim) it

leaves the Claim State. A station that receives its own Claim

frame gains the right to send the first token and make the

ring operational again. If the Claim Process does not com-

plete successfully, TRT will expire and the Beacon Process

is invoked.

Ð

5.2.1 Service Opportunity While Ring Operational

Beginning of Service Opportunity

The Beacon Process is used for fault isolation. A station

may invoke the Beacon Process through an SM Con-

trol.request(Beacon). When a station enters the Beacon

Process, it continuously sends out Beacon frames. The

Beacon Process is complete when a station receives its

Table 5-1 shows the conditions that must be true when a

valid token is received in order to begin a Service Opportu-

nity when the ring is operational.

Ð

TABLE 5-1. Beginning of Service Opportunity

Requested

Requested Token

Capture Class

Received

Criteria

Service Class

Token Class

l

THT THSH

Asynchronous Priority

non-restricted

e

Late Flag

Ð

Ring Op

0

1

Ð

e

Asynchronous

Synchronous

non-restricted

restricted

Late Flag

Ð

Ring Op

0

non-restricted

restricted

any

1

Ð

e

Late Flag

Ð

Ring Op

0

1

Ð

e

1

any

Ring Op

Ð

15

5.0 Functional Description (Continued)

In addition to the criteria mentioned above, additional crite-

ria apply to the servicing of Synchronous and Restricted

Requests.

transmitter Data, Claim or Beacon State, and the transmitter

is in the appropriate state.

The service opportunity continues until any one of the fol-

lowing conditions exist:

Synchronous Requests are not serviced if RELR.BCNR

is set (See Section 4.5.1).

#

1. No (additional) frames are to be sent

2. TMAX of time elapses on this request

3. The transmitter exits the requested state

Restricted requests are not serviced when RELR.BCNR,

RELR.CLMR, or RELR.OTRMAC are set. (See Section

4.5.3).

#

4. The ring becomes operational while servicing an immedi-

ate request

Restricted Dialogues may only begin when a non-restrict-

ed token has been received and transmitted (See Sec-

tion 4.5.3).

#

5.2.3 Frame Transmission

Frames associated with the current request may be trans-

mitted at any time during a Service Opportunity. In many

applications, data is ready to be transmitted when the re-

quest is presented to the interface. Soon after the Service

Opportunity begins, frame transmission begins. In other ap-

plications in order to minimize the effects of ring latency it is

desirable to capture the token when no data is ready to be

transmitted. This capability results in wasted ring bandwidth

and should be used judiciously.

End of Service Opportunity

The Service Opportunity continues until either a token is

issued or the ring becomes non-operational.

A token is issued after the current frame, if any, is transmit-

ted when:

1. It is no longer necessary to hold the token

All frames of all active requests have been transmitted

#

2. The token became unusable while servicing a request

During transmission, a byte stream is passed from the Sys-

tem Interface to the MAC Request Interface. The data is

passed through the Ring Engine and appears at the PHY

Request Interface two byte times later.

Asynchronous Priority threshold reached (If an Asynch

Priority Request is being serviced)

#

THT expired (if enabled)

#

When the ring becomes non-operational the current frame

transmission is aborted. The ring may go non-operational

while holding a token as a result of any one of the following

conditions:

While a frame is being transmitted, the request parameters

for the next request (if different) may be presented to the

interface. At the end of the current frame transmission, a

decision is made to continue or cancel the current service

opportunity based on the new request parameters.

A MAC Reset

#

During a transmission several errors can occur. A transmis-

sion may be terminated unsuccessfully because of external

buffering or interface parity errors, internal Ring Engine er-

rors, a MAC reset, or reception of a MAC frame. When a

transmission is aborted due to an external error (and Op-

tion.IRPT is not set), a Void frame is transmitted to reset the

TVX timers in all stations in the ring. When a frame is abort-

ed due to a transmission error, the Service Opportunity is

not automatically ended.

Reception of a valid MAC frame

#

TRT expiration, (TRT was reset when the token was cap-

tured)

Issue Token Type

The criteria presented to the Ring Engine to begin a Service

Opportunity, also contains the Issue Token Class. The Issue

Token Class is used if servicing of that request was com-

pleted (the last frame of that request was transmitted), oth-

erwise a token of the Capture Token Class is issued.

5.3 REQUEST SERVICE PARAMETERS

5.3.1 Request Service Class

When servicing multiple requests on a single service oppor-

tunity, the Issue Token Class of the previous class becomes

the capture class for the next request for purposes of deter-

mining usability.

The Request Service corresponds to the Request

Service Class and the token class parameters of the

(SM )MA DATA.request and (SM )MA Token.request

The type of token issued depends on the service class and

the type of token captured as shown in Table 5-2.

Ð

primitives as specified in the Standard.

14 useful combinations of the Requested Service Class

(Non-Restricted Asynchronous, Restricted Asynchronous,

Synchronous, Immediate), the Token Capture and Issue

Class, and THT Enable are supported by the Ring Engine as

shown in Table 5-3.

5.2.2 Service Opportunity while

Ring Not Operational

While the ring is not operational, a service opportunity oc-

curs if an immediate transmission is requested from the

TABLE 5-2. Token Transmission Type

Service Class

Non-Restricted

Token Captured

Token Issued

Non-Restricted

Restricted

Non-Restricted

Restricted

None

Begin Restricted

Continue Restricted

End Restricted

Restricted

Non-Restricted

None

Immediate

Immediate Non-Restricted

Immediate Restricted

None

Non-Restricted

Restricted

None

16

5.0 Functional Description (Continued)

TABLE 5-3. Request Service Classes

Token

Issue

RQRCLS

0000

Name

Class

THT

Notes

Capture

None

Async

0001

Apri

1

Enabled

Non-rstr

Ð

THSH1

0010

0011

0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111

Reserved

Syn

Reserved

Synch

Disabled

Enabled

Disabled

Any

None

Non-rstr

Rstr

Captured

None

1

4

Imm

Immediate

Asynch

ImmN

ImmR

Asyn

Non-rstr

Rstr

Non-rstr

Rstr

Rbeg

Restricted

Asynch

2, 3

2

Rend

Non-rstr

Rstr

Rcnt

Rstr

2

AsynD

RbeginD

RenD

RcntD

Non-rstr

Rstr

Non-rstr

Rstr

Restricted

2, 3

2

Non-rstr

Rstr

2

Note 1: Synchronous Requests are not serviced when bit BCNR of the Ring Event Latch Register is set.

Note 2: Restricted Requests are not serviced when bit BCNR, CLMR, or OTRMAC of the Ring Event Latch Register is set.

Note 3: Restricted Dialogues only begin when a Non-Restricted token has been received and transmitted.

Note 4: Immediate Requests are serviced when the ring is Non-Operational. These requests are serviced from the Data state if neither signal RQCLM nor RQBCN

is asserted. If signal RQCLM is asserted, Immediate Requests are serviced from the Claim State. If signal RQBCN is asserted, Immediate Requests are serviced

from the Beacon State. RQCLM and RQBCN do not cause transitions to the Claim and Beacon States.

Requests are serviced on a Service Opportunity meeting

the requested criteria.

Source Address Transparency

Normally the SA field in a frame is generated by the BMAC

device, using either the MSA or MLA. When the SA Trans-

parency option is selected, the SA from the data stream is

transmitted in place of the MSA or MLA. The SAT option

can be invoked on a per frame basis upon the assertion of

the SAT signal (Pin 12).

External support is required to limit the requests presented

to the MAC Interface by different MAC Users (SMT, LLC,

etc.).

A Token Capture Class of non-rstr indicates that the Trans-

mitter Token Class must be Non-Restricted to begin servic-

ing the request. A Token Capture Class of rstr indicates

that the Transmitter Token Class must be Restricted to be-

gin servicing the Request. A Token Issue Class of non-rstr

means that the Transmitter Token Class will be Non-Re-

stricted upon completion of the request. A Token Issue

Class of rstr means that the Transmitter Token Class will be

Restricted upon completion of the request.

When the SA Transparency option is selected, it is neces-

sary to rely on an alternate stripping mechanism because

stripping based on the returning SA only guarantees that

frames with MSA or MLA will be stripped. Either the Void

Stripping option (described below) may be invoked, or exter-

nal hardware that forces stripping using the EM (External

M

Flag) signal is required.

Ð

The MSB of the SA is not controlled by this option. It is

normally forced to Zero. It can be controlled using the

Source Address MSB Transparency option described be-

low.

5.3.2 Request Options

The Request Options provide the ability for Source Address

Transparency (SAT) and FCS Transparency (FCST). In both

cases, data from the request stream is transmitted in place

of data from either the Ring Engine. The use of Source Ad-

dress transparency has no effect on the sequencing of the

interface. When Source Address transparency is not used,

the SA from the internal parameter RAM is substituted for

the SA bytes in the request stream, which must still be pres-

ent. Since the FCS is appended to the frame, when FCS

transparency is not used, no FCS bytes are present in the

request stream.

SA Transparency is possible for all frames (including MAC

frames). External support is required to limit the use of SA

Transparency to certain MAC Users. SA Transparency

should not be used with externally generated MAC Frames

in order to maintain accountability, but this is not enforced

by the Ring Engine.

17

5.0 Functional Description (Continued)

SA Transparency also overrides the Long and Short Ad-

dressing enables. For example, if Long Addressing is not

enabled, it is still possible to transmit frames with Long Ad-

dresses. Similarly, if Short Addressing is not enabled, it is

still possible to transmit Frames with Short Addresses. This

may be useful in full duplex point to point applications and

for diagnostic purposes.

Void Stripping is also automatically invoked by this station if

it wins the Claim Process before the initial token is issued.

This removes all fragments and ownerless frames from the

ring when the ring becomes operational.

FCS Transparency

Normally, the BMAC device generates and transmits the

FCS. When the Frame Check Sequence Transparency op-

tion is selected, the Ring Engine device does not append

the FCS to the end of the Information field. This option is

selected by asserting signal FCST (Pin 14).

Source Address Most Significant Bit Transparency

With the Source Address MSB Transparency option, the

MSB of the SA is sourced from the data stream, as opposed

to being transmitted as Zero. The SA MSB Transparency

option is selected by asserting signal SAIGT (Pin 11).

The receiving stations treat the last four bytes of the data

stream as the FCS.

Unless the Source Address Transparency option is also se-

lected, the rest of the SA is generated by the Ring Engine.

This option may be useful for end to end FCS coverage

when crossing FDDI bridges, for diagnostic purposes, or in

Implementer frames.

The MSB of the SA is used to denote the presence of the

Routing Information Field used in Source Routing algo-

rithms (as in the IEEE 802.5 protocol). This option is useful

for stations that utilize Source Routing. In these applica-

tions, the SA can still be generated by the Ring Engine,

even when routing information is inserted into the data

stream.

5.4 FRAME VALIDITY PROCESSING

A valid frame is a frame that meets the minimum length

criteria and contains an integral number of data symbol

pairs between the Starting and Ending Delimiters as shown

in Table 5-4.

On the Transmit side, frames are checked to see that they

are of a minimum length. If the end of a frame is reached

before a valid length is transmitted, the frame will be abort-

ed and a Void frame will be transmitted (as with all aborted

frames). A MAC frame with a zero length INFO field will not

be aborted even though the Receiver will not recognize it as

a valid frame. Frame lengths are not checked for the maxi-

mum allowable length (4500 bytes).

Void Stripping

This option is useful for removing bridged and ownerless

frames and remnants (fragments) from the ring.

In the Void Stripping protocol, two My Void frames are

Ð

transmitted at the end of a service opportunity. Stripping

continues until one of the following conditions occur:

One My Void frames returns (The Second My Void

Ð

#

Ð

will be stripped on the basis of the SA)

Also on the Transmit side, the L bit in the FC field is

checked against the ESA and ELA bits in the Option Regis-

ter (if the SA Transparency option is not selected) to insure

that a frame of that address length can be transmitted. If the

selected address length is not enabled, the frame is aborted

at the beginning of the SA field. If SA Transparency is se-

lected, the frame is not aborted.

A Token is received

#

An Other Void is received

Ð

A MAC frame other than My Claim is received

Ð

A MAC Reset occurs

If any frame of a Service Opportunity requests this option,

then all frames on that service opportunity will be stripped

using this method. Void Stripping is invoked upon the asser-

tion of the STRIP signal (Pin 13) at the beginning of a frame

transmission.

TABLE 5-4. Valid Frame Length

Short Address

Frame Types

Long Address

Notes

(Minimum Number of Bytes)

Void

9

17

21

MAC

13

Including a 4 Byte

INFO Field

Non-MAC

9

17

Including a 0 Byte

INFO Field

18

5.0 Functional Description (Continued)

5.5 FRAME STATUS PROCESSING

The received value of the Control Indicators for every frame

received is reported at the MAC Indicate Interface on sig-

nals MID(7–0). On a frame transmitted by this station, the

returning Control Indicators give the transmission status.

Each frame contains three or more Control Indicators. The

FDDI Standard specifies three: the E, A, and C Indicators.

When a frame is transmitted, the Control Indicators are

transmitted as R (Reset) symbols. If an error is detected by

a station that receives the frame, the E Indicator is changed

to an S (Set) symbol. If a station recognizes the DA of a

frame as its own address (Individual, Group or Broadcast),

the A Indicator is changed to an S symbol. If that station

then copies the frame, the C Indicator is changed to an S

symbol.

The Ending Delimiter followed by the Frame Status Indica-

tors should begin and end on byte boundaries. Control Indi-

cators are repeated until the first non R, S, or T is received.

The processing of properly aligned E, A, and C indicators by

the Ring Engine is detailed in Table 5-5. Given the shown

received Control Indicator values and the settings of the

internal flags, the noted control indicator values will be

transmitted.

TABLE 5-5. Control Indicators Processing

Flags

Copy

Received Indicators

Transmitted Indicators

E

R

X

R

X

R

X

R

X

R

X

A

R

S

R

S

C

R

S

R

S

T

E

0

1

0

1

0

1

0

1

0

1

A

0

1

X

0

1

X

1

0

X

0

1

X

1

0

1

X

N

X

1

E

R

S

R

S

R

S

R

S

R

S

A

R

S

R

S

R

S

R

S

R

S

C

R

S

R

S

R

S

R

S

R

S

T

X

0

1

X

0

1

X

0

1

X

0

1

X

1

X

0

1

X

0

X

0

R

S

T

S

T

X

1

R

T

X

E

A

Flag is set when the local FCS check fails or when the E Indicator is received as anything other than R.

Ð

Flag is the internal Flag or the external A Flag (pin EA) when Option.Emind is set.

Ð

The Copy Flag is a one cycle delayed version of the VCOPY input.

Flag indicates that an NSA frame is being received. This signal is sampled at the same time that the received A indicator is being investigated.

N

Ð

X Represents a Don’t Care Condition.

19

5.0 Functional Description (Continued)

5.5.1 Odd Symbols Handling

A Higher Claim frame is a Claim frame with a Source Ad-

Ð

dress that does not match this station address and the

When the first T symbol of a frame is received as the sec-

ond symbol of a symbol pair (the T symbol is received off-

boundary), the Ring Engine corrects this condition by send-

ing out the symbol sequence TSII. This symbol sequence

indicates the end of the frame and that an error has been

detected in the frame. Note that this is a low probability

error event.

T

TREQ.

Bid Rc in the INFO field is greater than this station’s

Ð

A Lower Claim frame is a Claim frame with a Source Ad-

Ð

dress that does not match this station address and the

T

TREQ.

Bid Rc in the INFO field is less than this station’s

Ð

Reception of symbols other than R, S, and T during the

Frame Status processing is also a low probability event.

This event is handled slightly differently on the first byte of

the Ending Frame Status.

Transmit

Claim frames are transmitted continuously while in the

Claim State.

Claim frames are generated by the Ring Engine, unless an

Immediate Claim Request is present at the MAC Request

Interface. Even if an Immediate Claim Request is present at

the MAC Request Interface, at least one Claim frame must

be generated by the Ring Engine before Claim frames from

the Interface are transmitted.

After the first byte of the Ending Frame Status, if either the

[

]

[

first symbol is not R or S or the second symbol is not R or

]

S or T , an Idle symbol pair (II) is transmitted.

5.6 SMT FRAME PROCESSING

All SMT frames are handled as all other frames with the

exception of the SMT Next Station Addressing (SMT NSA)

frame. NSA frames are used to announce this station’s ad-

dress to the next addressed station. The current SMT proto-

col requires stations to periodically (at least once every 30

seconds) transmit an NSA frame. Since the Broadcast ad-

dress is used, and every station is required to recognize the

broadcast address, the downstream neighbor will set the A

Indicator. A station can determine its upstream neighbor by

finding NSA frames received with the A Indicator received

as R. By collecting this information from all stations, a map

of the logical ring can be built.

For internally generated Claim frames, the Information field

is transmitted as the 4-byte Requested Target Token Rota-

tion Time.

The Information field of a Claim frame consists of the sta-

tion’s Requested Target Token Rotation Time. In the Ring

Engine implementation, TREQ is programmable with

20.48 ms resolution and a maximum value of 1.34 seconds.

Claim Protocol

Entry to the Claim state occurs whenever token recovery is

required. The Recovery Required condition occurs when:

TRT expires and Late Flag is set

Ð

TVX expires

#

Additionally, only the station that sets the A Indicator is per-

mitted to set the C Indicator on such frames. In this way, the

station that sends out the NSA frame can determine if the

next addressed station copied the frame by examining the

returning C Indicator.

A Lower Claim frame or My Beacon frame is received

Ð

#

Entry to the Claim state may be blocked by enabling the

Inhibit Recovery Required option (bit Option.ITR).

5.7 MAC FRAME PROCESSING

e

1) with a

The Claim state is entered (even if Option.IRR

SM MA Control.request (Claim) (Set Function.CLM to 1).

Upon the reception of a valid MAC frame (Claim, Beacon, or

Other), the Ring Operational flag is reset and the Ring En-

Ð Ð

While in the Claim state:

Ð

gine enters the Idle, Claim or Beacon State. Received Claim

and Beacon frames are processed as defined in the Stan-

dard (See Appendix A), unless inhibited by the bits in the

Option Register.

Claim frames are transmitted continuously

#

If a Higher Claim frame is received, the station exits the

Claim state and enters the IDLE state. In this state it then

repeats additional Higher Claim frames.

5.7.1 Claim Token Process

Receive

If a Lower Claim frame is received, this station continues

to send its own Claim frames and remains in the Claim

state.

#

When a Claim frame is received, its Frame Type is reported

(Claim frame) along with the type of Claim frame.

Eventually, if a logical ring exists, the station with the short-

est TREQ on the ring should receive its own Claim frames,

the My Claim frame. This completes the Claim Token Pro-

cess. This one station then earns the right to issue a token

to establish an Operational ring.

There are three types of Claim frames: My Claim,

Ð

Higher Claim, and Lower Claim.

Ð

A My Claim frame is a Claim frame with a Source Address

Ð

that matches this station address and the T Bid Rc in the

INFO field is equal to this station’s TREQ.

Ð

An option is provided to remain in the Claim state if this

station won the Claim Token Process by enabling the Inhibit

Token Release Option (bit Option.ITR).

20

5.0 Functional Description (Continued)

5.7.2 Beacon Process

5.8 RECEIVE BATCHING SUPPORT

The Ring Engine stores each received SA and compares

the incoming SA with the previous SA. This may be used to

batch status on frames received from the same station.

Receive

When a Beacon frame is received, its Frame Type is report-

ed (Beacon frame) along with the type of Beacon frame.

The SameSA signal is asserted when:

There are two types of Beacon frames: My Beacon and

Ð

Other Beacon.

Ð

A Beacon frame is considered a My Beacon if its Source

Ð

Address matches this station’s address (long or short).

1. The curent and previous non-Void frames were not MAC

frames

2. The size of the address of the current frame is the same

as the size of the address of the previous non-Void frame

A Beacon frame is marked as Other Beacon if its Source

Ð

Address does not match this station’s address.

3. The SA of the current frame is the same as the SA of the

previous non-Void frame.

Transmit

On MAC frames, the Information fields are compared. This

information may be useful to inhibit copying MAC frames

with identical information. This is particularly useful for copy-

ing Claim and Beacon frames when new information is pres-

ent.

Beacon frames are transmitted continuously while in the

Beacon state.

Beacon frames are generated by the Ring Engine, unless an

Immediate Beacon Request is present at the MAC Request

Interface. Even if an Immediate Beacon Request is present

at the MAC Request Interface, at least one Beacon frame

must be generated by the Ring Engine before Beacon

frames from the Interface are transmitted.

The Same INFO signal is asserted when:

1. The current and previous non-Void frames were both

MAC frames (not necessarily the same FC value).

2. The first four bytes of the INFO field of the current frame

is the same as the first four bytes of the INFO field of the

previous non-Void frame.

For internally generated Beacon frames, the Ring Engine

uses the TBT in the Information field.

Beacon Protocol

The size of the address of MAC frames is not checked.

Entry to the Beacon state occurs under two conditions:

5.9 IMMEDIATE FRAME TRANSMISSION

A failed Claim Process (TRT expires during the Claim

process)

#

Immediate requests are used when it is desirable to send

frames without first capturing a token. Immediate requests

are typically used as part of management processes for er-

ror isolation and recovery. Immediate requests are also use-

ful in full duplex applications. Immediate requests are serv-

An SM MA Control.request (Beacon)

Ð Ð

(Set Function.BCN to 1).

#

Beacon frames are then transmitted until the Beacon pro-

cess is completed.

iced only when the station’s Ring Operational flag is not

Ð

e

set (CTSR.ROP

0).

If an Other Beacon frame is received, this station exits the

Ð

Beacon state, stops sending its own Beacon frames, and

repeats the incoming Beacon frames.

To transmit an Immediate request, the request must first be

queued at the MA Request Interface. If the Ring is not

Ð

operational (Ring Operational flag is not set), the request

Ð

will be serviced immediately. If the Ring is operational

(Ring Operational flag is set), the request will be serviced

Ð

when the Ring becomes non-operational. The Ring be-

If a My Beacon frame is received, the station has received

Ð

back its own Beacon frame; thus successfully completing

the Beacon process. The station then enters the Claim Pro-

cess.

comes non-operational as

a result of a MAC Reset

5.7.3 Handling Reserved MAC Frames

(Function.MCRST is set to One) or any of the conditions

causing the Reset or Recovery Actions are performed.

A Reserved MAC frame is any MAC frame aside from the

Claim and Beacon frame. Tokens are not considered MAC

frames even though Format bit (FC.FF) are the same as for

MAC frames.

In addition to servicing an Immediate request from the

Tx Data State, it is also possible to service Immediate re-

Ð

quests from the Claim or Beacon State. When transmitting

from the Claim or Beacon state, in addition to requesting an

Immediate Transmission Service Class, the RQCLM or

RQBCN signals (pins 15 and 16) must be asserted to indi-

cate an Immediate Claim or Immediate Beacon request.

These requests will only be serviced when in the Claim or

Beacon state. Entry to the Beacon State can be forced

When a Reserved MAC frame (Other MAC) is received, it

Ð

is treated as a Higher Claim. If the Transmitter is in the

Claim state when a Reserved MAC frame is received, the

Transmitter returns to the Idle state and then repeats the

next Reserved MAC frame received. If the Transmitter is in

the Beacon state and a Reserved MAC frame is received,

the Transmitter continues to transmit Beacon frames. If the

Transmitter is in the Idle state, the Reserved MAC frame is

repeated.

21

5.0 Functional Description (Continued)

by setting bit Function.BCN to One. Entry to the Claim State

can be forced by setting bit Function.CLM to One.

When parity is not used on an Interface, the parity provided

by the BMAC device for its outputs may be ignored. For the

BMAC device’s inputs, the result of the parity check is used

only if parity on that Interface is enabled.

While in the Claim or Beacon state, the Ring Engine will

transmit internally generated Claim or Beacon frames ex-

cept when an Immediate Claim or Beacon request is pres-

Interface parity is enabled by setting the appropriate bit in

the Mode register: Mode.CBP for Control Bus Parity, Mo-

de.PIP for PHY Indication parity and Mode.MRP for MAC

Request Parity. A Master Reset (Function. MARST) disables

parity on all interfaces.

ent at the MA Request Interface, signal RQCLM or

Ð

RQBCN is asserted, and a frame is ready to be transmitted.

At least one internally generated Claim or Beacon frame

must be transmitted before an Immediate Claim or Beacon

request is serviced. It is possible for the internally generated

frame to return before the end of the requested frame has

been transmitted. To allow time for the requested frame(s)

to be transmitted before leaving the Claim or Beacon state,

bit ITR (for Claim) or bit IRR (for Beacon) of the Option

Register should be set to One.

On the PHY Request interface, parity is generated for inter-

nally sourced fields (such as the SA or FCS on frames when

not using SA or FCS transparency, and internally generated

Beacon, Claim and Void frames). In REV 1 of the BMAC

device, MRP is passed transparently to PRP for externally

sourced fields independent of the value of the Mode.MRP.

In all later revisions, correct Odd parity is always generated

for PRP. This allows through parity support at the PHY inter-

face even if parity is not used at the MAC interface. This is

very desirable since every byte of data that traverses the

ring travels across the PHY Interface which is actually part

of the ring.

While an Immediate request is being serviced (from any

state), if bit IRPT of the Option Register is set to One (Inhibit

Repeat option), all received frames (except Lower Claim

Ð

and My Beacon frames) are ignored and the Immediate

Ð

request continues. Lower Claim and My Beacon frames

Ð

can also be ignored by setting bit IRR of the Option Regis-

ter.

Through parity is not supported in the Control Interface Reg-

isters and the Parameter RAM. Parity is generated and

stripped at the Control Interface.

5.10 FULL DUPLEX OPERATION

The BMAC device supports full duplex operation by

Handling Parity Errors

1. Suspending the Token Management and Token Recov-

ery protocols (set Option.IRR)

Parity errors are reported in the Exception Status Register

when parity on that interface is enabled.

2. Inhibiting the repetition of all PDUs (set Option.IRPT)

3. Using the Immediate Service Class

A parity error at the PHY interface (when Mode.PIP is set) is

treated as a code violation and ESR.PPE is set. If the parity

error occurs in the middle of a PDU (token or frame) recep-

tion, the PDU is stripped,

(FOERROR) and the Lost Count is incremented.

Frames of any size may be transmitted or received, subject

to the minimum length specified in Section 5.4.

a Format Error is signaled

5.11 PARITY PROCESSING

The BMAC device contains five data interfaces as shown in

Table 5-6.

A parity error at the MAC Interface (when Mode.MRP is set)

during a frame transmission from the MAC interface (while

TXACK is asserted) causes the frame transmission to be

aborted. When a frame is aborted, a Void frame is transmit-

ted to reset every station’s TVX timer. A parity error (when

enabled) causes ESR.MPE to be set.

Through Parity is supported on the internal data paths be-

tween any Request interface and any Indicate interface.

Odd Parity is provided every clock on all data outputs and is

checked every clock on all data inputs. Parity errors are not

propagated through the BMAC device (from the MAC Re-

quest and PHY Indication interface to the PHY Request in-

terface or from the PHY Indication interface to the MAC

Indication interface). Parity errors are isolated and resolved.

A parity error at the Control Interface (when Mode.CBP is

set) will cancel the current write access. ESR.CPE is set to

indicate that a parity error occurred and ESR.CCE is set to

indicate that the write was not performed.

TABLE 5-6. BMAC Device Parity

Parity

On

Interface

Parity

Direction

MAC Request Interface

MAC Indication Interface

PHY Request Interface

MRD(7:0)

MID(7:0)

MRP

MIP

I

O

PRD(7:0),

PRC

PRP

O

PHY Indication Interface

Control Interface

PID(7:0),

PIC

PIP

I

CBD(7:0)

CBP

I/O

22

6.0 Control Information

The Control Information includes Operation, Event, Status

and Parameter Registers that are used to manage and op-

erate the Ring Engine. A processor on the external Control

Bus gains access to read and write these parameters via

the Control Interface.

6.2 ACCESS RULES

All parameters are accessible in Diagnose Mode. Reserved

address space is not accessible in any mode. Certain Status

and Parameter Registers are not accessible while in Run

mode.

The Control Information Address Space is divided into 4

groups as shown in Table 6-1. An information summary is

given for each group (see Tables 6-2 through 6-5) followed

by a detailed description of all registers.

All Control Interface accesses are checked against the cur-

rent operational mode to determine if the register is current-

ly accessible. If not currently accessible, the Control Bus

Interface access is rejected (and reported in an Event Reg-

ister). This means that all Control Bus Interface accesses

complete in a deterministic amount of time.

6.1 CONVENTIONS

When referring to multi-byte fields, byte 0 is always the most

significant byte. When referring to bits within a byte, bit (7) is

the most significant bit and bit (0) is the least significant bit.

The Exceptional Status Register can be checked to verify

that the operation terminated normally.

When referring to the contents of a byte, the most signficant

bit is always referred to first.

When referring to a bit within a byte the notation

register name.bit name is used. For example, Mode.RUN

Ð Ð

references the RUN bit in the Mode Register.

TABLE 6-1. Control Information Address Space

Address Range

00–07

Description

Operation Registers

Event Registers

Reserved

Read Conditions

Always (Note 2)

N/A

Write Conditions

Always (Note 2)

Always (Cond) (Note 2)

N/A

08–2F

30–3F

40–7F

MAC Parameters

Stop Mode

(Notes 1, 3)

Stop Mode

(Notes 1, 3)

80–BF

C0–FF

Counters/Timers

Reserved

Always

Stop Mode

(Note 1)

N/A

Note 1: An attempt to access a currently inaccessible location because of the current mode or because it is in a reserved address space will cause a command

error (bit CCE of the Exception Status Register is set to One).

Note 2: Read and write accesses to reserved location within the Operation and Event Address ranges cause a command error (bit CCE of the Exception Status

Register is set to One).

Note 3: The MAC Parameter RAM is also accessible when conditions a, b, and c are true. Otherwise accesses will cause a command error (ESR.CEE set to One)

and the access will not be performed.

a. The MAC Transmitter is in states T0, T1 or T3;

b. Bits ITC and IRR of the Option Register are set to One.

c. Bits CLM and BCN of the Function Register are not set to One.

TABLE 6-2. Operation Registers

Addr

Name

Mode

D7

DIAG

ITC

D6

ILB

D5

D4

D3

PIP

D2

MRP

ITR

D1

D0

RUN

Read

Always

N/A

Write

Always

N/A

0

1

RES

IFCS

RES

IRPT

CLM

RES

CBP

ELA

RES

Option

EMIND

RES

IRR

BCN

RES

ESA

2

Function

Reserved

Revision

RES

MCRST

RES

MARST

RES

3–6

7

REV(7–0)

Always

Note: Attempts to access reserved locations will result in Command Rejects (ESR.CCE set to ONE).

23

6.0 Control Information (Continued)

TABLE 6-3. Event Registers

Addr

8

Name

CMP

D7

D6

D5

D4

D3

D2

D1

D0

Read

Always

N/A

Write

Always

N/A

CMP(7–0)

9–B

C

Reserved

CRS0

RES

RFLG

RES

ROP

RES

RS2

RES

TS2

RES

RS1

RES

TS1

RES

RS0

RES

TS0

RES

RTS2

RES

RTS1

RES

RTS0

RES

Always

N/A

Ignore

N/A

D

Reserved

CTS0

RES

E

TTS3

RES

TTS2

RES

TTS1

RES

TTS0

RES

Always

N/A

Ignore

N/A

F

Reserved

RELR0

RES

PINV

10

DUP

ADD

OTR

MAC

CLMR

BCNR

RNOP

ROP

Always Condition

DUP

ADD

OTR

MAC

11

REMR0

RES

PINV

CLMR

BCNR

RNOP

ROP

Always

12

13

14

15

RELR1

REMR1

TELR0

TEMR0

LOCLM

RLVD

RES

HICLM

MYCLM

RES

MYBCN OTRBCN Always Condition

MYBCN OTRBCN Always Always

TKPASS TKCAPT CBERR DUPTKR TRTEXP TVXEXP ENTRMD Always Condition

TKPASS TKCAPT CBERR DUPTKR TRTEXP TVXEXP ENTRMD Always

Always

N/A

16–17 Reserved

RES

N/A

18

CILR

RES

TK

FR

FREI

FR

Always Condition

RCVD

TRX

NCOP

COP

LST

RCV

19

CIMR

RES

TK

FR

FREI

FR

Always

RCVD

TRX

NCOP

COP

LST

RCV

1A–1B Reserved

RES

N/A

1C

COLR

TK

FR

FREI

FR

Always Condition

RCVD

TRX

NCOP

COP

LST

RCV

1D

COMR

RES

TK

FR

FREI

FR

Always

N/A

Always

N/A

RCVD

TRX

NCOP

COP

LST

RCV

1E–27 Reserved

28 IELR

29–2B Reserved

RES

MPE

TSM

ERR

RSM

ERR

Always Condition

RES

CWI

RES

CCE

IERR

IER

RES

CPE

RES

COE

RES

CIE

RES

TTE

RES

PPE

RNG

N/A

2C

2D

2E

2F

ESR

EMR

ICR

Always Condition

ZERO

ESE

Always

Ignore

Always

IMR

ESE

CIE

Note 1: Attempts to access reserved locations will result in Command Rejects (ESR.CCE set to ONE).

Note 2: Bits in the conditional write registers are only written when the corresponding bit in the Compare Register is equal to the bit to be overwritten and the bit is

not changing in that cycle.

24

6.0 Control Information (Continued)

TABLE 6-4. MAC Parameter RAM

TABLE 6-4. MAC Parameter RAM (Continued)

Register

Address

Name

Address

Name

Contents

MLA(47–40)

MLA(39–32)

MLA(31–24)

MLA(23-16)

MLA(15–8)

MLA(7–0)

Contents

40

41

MLA0

MLA1

MLA2

MLA3

MLA4

MLA5

MSA0

MSA1

GLA0

60

61

62

63

64

65

66

67

68

69

6A

6B

6C

6D

6E

6F

70

71

72

73

74

75

76

77

78

79

7A

7B

7C

7D

7E

7F

PGM10

PGM11

PGM12

PGM13

PGM14

PGM15

PGM16

PGM17

PGM18

PGM19

PGM1A

PGM1B

PGM1C

PGM1D

PGM1E

PGM1F

PGM0

PGM(87–80)

PGM(8F–88)

PGM(97–90)

PGM(9F–98)

PGM(A7–A0)

PGM(AF–A8)

PGM(B7–B0)

PGM(BF–B8)

PGM(C7–C0)

PGM(CF–C8)

PGM(D7–D0)

PGM(DF–D8)

PGM(E7–E0)

PGM(EF–E8)

PGM(F7–F0)

PGM(FF–F8)

PGM(7–0)

42

43

44

45

46

MSA(15–8)

MSA(7–0)

47

48

GLA(47–40)

GLA(39–32)

GLA(31–24)

GLA(23–16)

GLA(15–8)

49

GLA1

4A

4B

4C

4D

4E

4F

50

GLA2

GLA3

GLA4

Reserved

GSA0

Reserved

TREQ0

TREQ1

TREQ2

TREQ3

TBT0

GSA(15–8)

TREQ(31–24)

TREQ(23–16)

TREQ(15–8)

TREQ(7–0)

TBT(31–24)

TBT(23–16)

TBT(15–8)

TBT(7–0)

51

PGM1

PGM(F–8)

52

PGM2

PGM(17–10)

PGM(1F–18)

PGM(27–20)

PGM(2F–28)

PGM(37–30)

PGM(3F–38)

PGM(47–40)

PGM(4F–48)

PGM(57–50)

PGM(5F–58)

PGM(67–60)

PGM(6F–68)

PGM(77–70)

PGM(7F–78)

53

PGM3

54

PGM4

55

TBT1

PGM5

56

TBT2

PGM6

57

TBT3

PGM7

58

FGM0

FGM1

RES

FGM(7–0)

PGM8

59

FGM(F–8)

PGM9

5A–5F

Reserved

PGMA

PGMB

PGMC

PGMD

PGME

PGMF

Note: The MAC Parameter RAM is accessible in Stop mode and in RUN

mode while the MAC Transmitter is in the states T0,T1 or T3; Option.ITC and

Option.IRR are set; and Function.BCN and Function.CLM are not set. Other-

wise a command reject is given (ESR.CCE) and the Parameter RAM will not

be read or written.

25

6.0 Control Information (Continued)

TABLE 6-5. MAC Counters and Timer Thresholds

Register

TABLE 6-5. MAC Counters and Timer Thresholds

(Continued)

Address

Name

Register

Contents

Address

Name

Contents

80–86

87

Reserved

THSH1

B0

B1

FNCT0

FNCT1

Zero(31–24)

Null(7–4),

THSH1(3–0)

FNCT(19–16)

88–92

93

Reserved

TMAX

B2

B3

B4

B5

FNCT2

FNCT3

FTCT0

FTCT1

FNCT(15–8)

FNCT(7–0)

Zero(31–24)

Null(7–4),

TMAX(3–0)

94–96

97

Reserved

TVX

Null(7–4),

TVX(3–0)

FTCT(19–16)

B6

B7

B8

B9

FTCT2

FTCT3

TKCT0

TKCT1

FTCT(15–8)

FTCT(7–0)

Zero(31–24)

98

99

TNEG0

TNEG1

TNEG2

TNEG3

Reserved

LTCT

TNEG(31–24)

TNEG(23–16)

TNEG(15–8)

TNEG(7–0)

Null(7–4),

9A

TKCT(19–16)

9B

BA

BB

BC

BD

TKCT2

TKCT3

RLCT0

RLCT1

TKCT(15–8)

TKCT(7–0)

Zero(31–24)

9C–9E

9F

Null(7–4),

LTCT(3–0)

Null(7–4),

A0

A1

FRCT0

FRCT1

Zero(31–24)

RLCT(19–16)

Null(7–4),

BE

BF

RLCT2

RLCT3

RLCT(15–8)

RLCT(7–0)

FRCT(19–16)

A2

A3

A4

A5

FRCT2

FRCT3

EICT0

EICT1

FRCT(15–8)

FRCT(7–0)

Zero(31–24)

Note: The MAC event counters and timer thresholds are always readable,

and are writable in Stop mode.

Note: Null(7–4) indicates that these bits are forced to zero on reads, and are

ignored on writes.

Note: The value obtained on reads from reserved locations is not specified.

Null(7–4),

EICT(19–16)

The Event Counters are 20-bit counters and are read

through three control accesses. In order to guarantee a

consistent snapshot, whenever byte 3 of an event counter is

read, byte 1 and byte 2 of the counters are loaded into a

holding register. Byte 1 and byte 2 may then be read from

the holding register. A single holding register is shared by all

of the counters but (for convenience) is accessible at sever-

al places within the address space. Consistent readings

across counters can be accomplished using the Counter

Increment Latch Register (CILR).

A6

A7

A8

A9

EICT2

EICT3

LFCT0

LFCT1

EICT(15–8)

EICT(7–0)

Zero(31–24)

Null(7–4),

LFCT(19–16)

AA

AB

AC

AD

LFCT2

LFCT3

FCCT0

FCCT1

LFCT(15–8)

LFCT(7–0)

Zero(31–24)

The Event Counters are not reset as a result of a Master

Reset. This may be done by either reading the counters out

and keeping track relative to the initial value read, or by

writing a value to all of the counters in stop mode. The

counters may be written in any order. With some excep-

tions, interrupts are available when the counters increment

or wraparound.

Null(7–4),

FCCT(19–16)

AE

AF

FCCT2

FCCT3

FCCT(15–8)

FCCT(7–0)

6.3 OPERATION REGISTERS

The Operation Registers are used to control the operation

of the BMAC device. The Operation Registers include the

following registers.

Mode Register (Mode)

#

Option Register (Option)

#

Function Register (Function)

#

Revision Register (REV)

#

26

6.0 Control Information (Continued)

Mode Register (Mode)

The Mode Register (Mode) contains the current mode of the BMAC device.

ACCESS RULES

Address

00h

Read

Write

Always

REGISTER BITS

D7

D6

D5

D4

D3

PIP

D2

D1

D0

DIAG

ILB

RES

MRP

CBP

RUN

Bit

D0

Symbol

Description

RUN

RUN/Stop:

0: Stop Mode

All state machines return to and remain in their zero state. All counters and timers are disabled. The Ring

Engine transmits Idle symbols.

1: Run Mode. Must be in Run Mode to achieve an operational Ring.

D1

CBP

Control Bus Parity: Enables Odd Parity checking on the Control Bus Data pins (CBD7–0) during write

accesses.

If a parity error occurs, the CPE bit of the Exception Status Register is set to One and an interrupt is

generated. The write data will not be deposited in the register. Parity is always generated on CBD7–0 during

read accesses

D2

D3

MRP

PIP

MAC Request Parity: Enables Odd Parity checking on the MAC Request Data pins (MRD7–0). A parity

error causes the transmission to be aborted. In REV 1 of the BMAC device MIP is always passed

transparently from PIP. In all later revisions correct Odd parity is always generated on MIP.

PHY Indicate Parity: Enables Odd Parity checking on the PHY Indicate Data pins (PID7–0). Parity errors

are treated as code violations and cause the byte in error to be replaced with Idle symbols. In REV 1 of the

BMAC device Parity is passed transparently between MRP and PRP during transmission. When repeating,

Parity is passed transparently from PIP to PRP. Odd Parity is generated for all internally generated fields. In

all later revisions correct Odd Parity is always generated on the PHY Request Data pins (PRD7–0).

D4–5

D6

RES

ILB

Reserved

Internal Loopback: Enables the internal loopback that connects PRP, PRC, and PRD7–0 to PIP, PIC, and

PID7–0 respectively. When enabled, the PHY Indicate Interface is ignored.

Since the Ring Engine Transmitter and Receiver work as independent processes, a ring can be made

operational in this mode, albeit consisting only of a single MAC. With an operational ring many diagnostic

tests can be performed to test out MAC level and system level diagnostics including: the Beacon Process,

the Claim Process, Ring Engine frame generation, token timers, event counters, transmission options, test

of event detection capabilities, test of addressing modes, test of state machine sequencing options, etc. In

addition, a large portion of the system interface logic can be tested, such as full duplex transmission to self

within the limits of the system interface performance constraints, status handling and generation, etc.

The same system tests can also be performed at different levels of loopback including through the various

paths within a station: through the PMD interface of the PLAYER device, and through the CRD device.

System level tests can also be performed through the ring during normal operation.

D7

DIAG

Diagnose Mode: Enables access to all BMAC device registers. When set, interoperability is not

guaranteed. This bit should only be set when the BMAC device is not inserted in a ring.

In diagnose mode, should an internal error occur the Current Receive and Transmit Status Registers are

frozen with the errored state until the internal state machine error condition is cleared (IELR.RSMERR

and/or IELR.TSMERR).

27

6.0 Control Information (Continued)

Option Register (Option)

The Ring Engine supports several options. These options are typically static during operation but may be altered during

operation. This register is initialized to Zero after a master reset.

ACCESS RULES

Address

01h

Read

Write

Always

REGISTER BITS

D7

D6

D5

IFCS

D4

D3

D2

D1

D0

ITC

EMIND

IRPT

IRR

ITR

ELA

ESA

Bit

Symbol

Description

D0

ESA

Enable Short Addressing: Enables the setting of A Flag on matches of received Short Destination

Ð

Addresses with MSA. Enables the setting of M Flag and stripping on matches of received Short Source

Addresses with MSA.

Ð

Permits transmission of frames with Short Addresses. Frames with Short Addresses can be transmitted when

Short Addressing is not enabled if the SA Transparency option is selected.

Void frames are sent with the Short Address if ESA is set to One. If ESA is Zero and ELA is One, Void frames

are sent with the Long Address.

When both the ESA and ELA bits are Zero, the ring is effectively interrupted at this station. The token capture

process and Error Recovery logic are suspended and no frames are repeated. Immediate requests are

serviced if the SA Transparency option is selected.

D1

ELA

Enable Long Addressing: Enables the setting of A Flag on matches of received Long Destination

Ð

Addresses with MLA. Enables the setting of M Flag and stripping on matches of received Long Source

Address with MLA.

Ð

Permits transmission of frames with Long Addresses. Frames with long addresses can be transmitted when

long addressing is not enabled if the SA transparency option is selected.

Claim and Beacon frames are sent with the Long Address if ELA is One. If ELA is Zero and ESA is One, Claim

and Beacon frames are sent with the Short Address.

When both ESA and ELA are Zero, the ring is effectively interrupted at this station. The token capture process

and Error Recovery logic are suspended and no frames are repeated. Immediate requests are serviced if the

SA Transparency option is selected.

D2

ITR

Inhibit Token Release: When bit ITR is set to One, the station will not issue a token after winning the Claim

Process. The station remains in the Claim state while the station’s Claim frames are returning to the station

and it has won the Claim Process. At this point the station is in control of the ring as long as no Higher Claim

Ð

or Beacon frames are received.

While in control of the ring, the station may transmit special Claim or Management frames for a variety of

implementation specific purposes. For example, the station might send out a Claim frame with a unique

identifier to make sure that another station with its address and TREQ is not also Claiming.

D3

IRR

Inhibit Recovery Required: When bit IRR is set to One, the Ring Engine does not take the transitions into the

Claim state (T4). This option inhibits all the recovery required transitions as defined in the FDDI MAC Standard.

This bit does not inhibit entry to the Claim state on a Claim Request generated at the MAC Request Interface

via the Function Register.

This option can be used to guarantee that implementation specific Beacon frames will be transmitted from the

Beacon state. It is also useful in systems where Local Address Administration is used, to prohibit stations with

the Null Address (or any address) from Claiming. The option could also be used to enable the use of the Ring

Engine in full duplex applications (in conjunction with the Inhibit Repeat option) to disable the recovery timers.

28

6.0 Control Information (Continued)

Option Register (Continued)

Bit

D4

Symbol

Description

IRPT

Inhibit Repeat: When enabled,

1. the Ring Engine cannot enter the Transmitter Repeat and Issue Token states. This causes all received

Ð

PDUs to be stripped and prevents tokens from being issued.

2. Void frames are not transmitted during a service opportunity.

3. Idle to Repeat transition is inhibited and all received tokens and MAC frames except Lower Claim and

Ð

My Beacon frames are ignored (Lower Claim and My Beacon frames may be ignored by setting

Ð

Option.IRR).

Ð

When the ring is operational, enabling this option causes the Reset actions to occur upon the completion of

the Service Opportunity, if any. When the ring is not operational, Immediate Requests are serviced and

continue to completion.

The Inhibit Repeat option can be used to scrub the ring for a period longer than the Ring Latency. The option is

also useful in full duplex applications.

e

10). When

D5

IFCS

Implementer FCS: Enables use of the standard CRC as the FCS on Implementer frames (FC.FF

enabled, Implementer frames are treated like all other frames. When Implementer frames are received with

e

bad FCS and Er R, the E Indicator is transmitted as S and EICT is incremented.

On Implementer frames, the Standard does not mandate the setting of the E Indicator on the result of the FCS

check. This allows Implementers to use alternate Frame Check Sequences aside from the standard 32-bit

CRC. Implementers may also choose not to use any FCS in applications such as packet voice.

If other stations in the ring are using Implementer frames with a non-standard FCS, if used, this option may

cause an interoperability problem.

D6

D7

EMIND

ITC

External Matching Indicators: Enables the setting of the transmitted A Indicator (Ax) as an S symbol when

the EA pin is set. Also enables the setting of the transmitted C Indicator (Cx) as an S symbol when the VCOPY

pin is set if the A Indicator is set as a result of an external match. The Copied/Not Copied Frame Counters are

also incremented as a result of external comparisons when this option is enabled.

Inhibit Token Capture: When enabled, the Ring Engine is prohibited from transmitting any (more) frames.

This option prohibits entry to the Transmit Void and Data states from the Idle state, and causes exit from the

Data state after the current frame has been transmitted.

When enabled, it is still possible to perform Immediate transmissions from the transmitter Claim and Beacon

states, but not from the Data state.

This option can be used to temporarily block normal data service. It can also be used in conjunction with the

Inhibit Recovery Required option to permit access via the Control Interface to the MAC Parameter RAM during

MAC operation.

29

6.0 Control Information (Continued)

Function Register (Function)

The Ring Engine performs the MAC Reset, Claim Request, and Beacon Request using the Function Register. The Register is

initialized to Zero after a master reset. A function is performed by setting the appropriate bit to One. When the function is

complete, the bit is cleared by the Ring Engine.

ACCESS RULES

Address

02h

Read

Write

Always

REGISTER BITS

D7

D6

D5

D4

D3

D2

MCRST

D1

D0

RES

CLM

BCN

RES

MARST

Bit

D0

Symbol

Description

MARST

Master Reset: Produces the functions of an SM CONTROL(MAC Reset) as specified by the FDDI MAC

Ð

Standard. Sets all internal state machines and registers to known values.

Master Reset causes the MCRST bit to be set. It also clears the Mode, Option, Event and Mask Registers.

The Timers are set to their defaults. The Event Counters are not cleared.

When the Master Reset function is complete, MARST is cleared. At this time, all bits in the Function

Register should be Zero.

D1

D2

RES

Reserved

MCRST

MAC Reset: Forces the Receiver to state R0 (Listen) and the Transmitter to state T0 (Idle).

TNEG (Registers 98–9B) is not loaded with TMAX (this operation can be performed as part of the MAC

Reset Request actions by writing to TNEG before the MAC Reset is initiated).

MCRST takes precedence over bits D3 (BCN) and D4 (CLM), but does not clear these bits.

A MAC Reset that occurs while a frame is being transmitted will cause the frame to be aborted. Frames

without the Frame Status are not transmitted by the Ring Engine. Whenever the byte with the Ending

Delimiter is transmitted, valid frame status is transmitted as well. If a MAC Reset occurs during the byte

where the Ending Delimiter and E Indicator should be transmitted, it will not be transmitted. If a MAC Reset

occurs on the cycle where the A and C Indicators are transmitted, they will still be transmitted.

D3

BCN

Beacon Request: Produces the functions of an SM CONTROL.request (Beacon) as required by the FDDI

Ð

MAC Standard. The Ring Engine Transmitter is forced to enter the Beacon State. Beacon frames are then

e

transmitted until the Beacon Process completes. The Beacon Process will not complete if Option.IRR 1.

Beacon frames are generated by the Ring Engine unless an Immediate Beacon Request is present at the

MAC Request Interface and a frame is ready to be transmitted. Even with an External Immediate Beacon

Request the Ring Engine transmits at least one Beacon frame before the Beacon frames from the MAC

Request Interface are transmitted.

If an external Beacon frame is to be transmitted, the Beacon frame should first be set up, then the request

should be given to the MAC Request Interface and then bit BCN should be set to One.

Writing to this bit also sets bit D2 (MCRST). This bit is cleared on entry to the Beacon state. If both bits D3

(BCN) and D4 (CLM) are set, bit D3 takes precedence.

D4

CLM

Claim Request: Produces the functions equivalent to an SM CONTROL.request (Claim) and causes entry

Ð

to the Claim State. The Ring Engine Transmitter is forced to enter the Claim State unless the Transmitter is

in the Beacon State or bit BCN is set to One. Claim frames are then transmitted until the Claim Process

e

completes. The Claim Process will not complete if Option.ITR 1.

A Claim Request is honored immediately from any state except the Beacon state. It is honored in the

e

Beacon state when a My Beacon returns. Claim requests are honored even when Option.IRR 1.

Ð

Claim frames are generated by the Ring Engine unless an Immediate Claim Request is available at the MAC

Request Interface. Even with an Immediate Claim Request at the interface, the Ring Engine transmits at

least one Claim frame before the Claim frames from the MAC Request Interface are transmitted.

If an external Claim frames is to be transmitted, the Claim frame should first be set up, then the request

should be given to the MAC Request Interface before the CLM bit is set to One.

The Claim bit is reset upon entry to the Claim or Beacon state.

D5–7

RES

Reserved

30

6.0 Control Information (Continued)

Revision Register (Rev)

The Revision Register (Rev) contains the revision number of the BMAC device.

ACCESS RULES

Address

07h

Read

Write

Always

Data Ignored

REGISTER BITS

D7

D6

D5

D4

D3

D2

REV2

D1

D0

REV7

REV6

REV5

REV4

REV3

REV1

REV0

Bit

D0–7

Symbol

Description

REV

Revision Number: Bits D0–7 contain the version ID of the BMAC device.

Software should consult this register for any software-specific issues related to the current version.

00h reserved

01h Initial Release

02h First Revision

Programmable Group Address Modification

#

e

Not copied count does not increment on reception of NSA frames with Ar

Detection of Idle on reception of nl

Generation of ODD Parity at all times

S

#

Reset of Latency Count on initiation of new measurement

31

6.0 Control Information (Continued)

6.4 EVENT REGISTERS

that have not changed since the last read can be written to

a new value.

The Event Registers record the occurrence of events or

series of events. Events are recorded and contribute to gen-

erating the Interrupt signal. There is a two-level hierarchy in

generating this signal.

Whenever a Condition Latch Register is read, its contents

are stored in the Compare Register. Each bit of the Com-

pare Register is compared with the current contents of the

Register that is to be written. Writing a bit with a new value

to a Condition Register is only possible when the corre-

sponding bit in the Compare Register matches the bit in the

Condition Register. For any bit that has not changed, the

new value of the bit is written into the Register. For any bit

that has changed, the writing of the bit is inhibited. The fact

that an attempt was made to change a modified bit in the

Register is latched in the Condition Write Inhibit bit in the

Exception Status Register (ESR.CWI).

At the first level of the hierarchy, events are recorded as bits

in the Latch Registers (e.g., Ring Event Latch Registers,

Counter Increment Latch Register). Each Latch Register

has a corresponding Mask Register (e.g., Ring Event Mask

Registers, Counter Increment Mask Register). When a bit in

the Latch Register is set to One and its corresponding bit in

the Mask Register is also set to One, a bit in the Interrupt

Condition Register is set to One.

At the second level of the hierarchy, if a bit in the Interrupt

Condition Register is set to One and the corresponding bit

in the Interrupt Mask Register is set to One, the Interrupt

signal is asserted.

In the BMAC device, the Compare Register is shared by all

of the Condition Latch Registers and always reflects the

most recent read of one of these registers. (In the

DP83251/5 PLAYER Device, there is a Compare Register

for every Event Register.) For the cases where more than

one register must be read before writing a new value, the

software may write the Compare Register with the most re-

cently read value before writing the register again. Alterna-

tively, the register may be read again before being written.

Bits in Conditional Write Registers (e.g., Ring Event Latch

Registers) are only written when the corresponding bits in

the Compare Register are equal to bits to be overwritten.

Servicing Interrupts

In the process of servicing an interrupt, a Management Enti-

ty may use one or both levels of condition masks to disable

new interrupts while one is being serviced. Soon after the

Management Entity has processed the interrupt to some ex-

tent, it is ready to rearm the interrupt in order to be notified

of the next condition.

The Event Registers include the following registers as:

Compare Register (CMP)

#

Current Receiver Status Register (CRS0)

#

Current Transmitter Status Register (CTS0)

#

Ring Event Latch Registers (RELR0–1)

#

The Interrupt Control Register always contains the merged

output of the masked Condition Registers as shown in Fig-

ure 6-1. It is only possible to remove a condition by setting

the corresponding Condition Latch Register bit to Zero. By

storing the events on-chip, and having the ability to selec-

tively set bits to Zero, the need for the software to maintain

a copy of the Event Registers is alleviated.

Ring Event Mask Registers (REMR0–1)

Token and Timer Event Latch Register (TELR0)

Token and Timer Event Mask Register (TEMR0)

Counter Increment Latch Register (CILR)

Counter Increment Mask Register (CIMR)

Counter Overflow Latch Register (COLR)

#

To prevent the overwriting and consequent missing of

events, an interlock mechanism is used. In the period be-

tween the Read of a Condition Latch Register, and the cor-

responding Write to reset the condition, additional events

can occur.

Counter Overflow Mask Register (COMR)

Internal Event Latch Register (IELR)

Exception Status Register (ESR)

Exception Mask Register (EMR)

#

In order to prevent software from overwriting bits which

have changed since the last read and losing interrupt

events a conditional write mechanism is employed. Only bits

Interrupt Condition Register (ICR)

Interrupt Mask Register (IMR)

TL/F/10387–7

FIGURE 6-1. Event Registers Hierarchy

32

6.0 Control Information (Continued)

Compare Register (CMP)

The Compare Register (CMP) is written with the contents of a conditional event latch registers when it is read. The Compare

Register may also be written to directly. During a write to any of the conditional write registers, the contents of the Compare

Register (CMP) is compared with bits D0–7 of the accessed register. Only bits for which the comparison matches can be written

to a new value.

ACCESS RULES

Address

08h

Read

Write

Always

REGISTER BITS

D7

D6

D5

CMP5

D4

D3

CMP3

D2

D1

D0

CMP7

CMP6

CMP4

CMP2

CMP1

CMP0

33

6.0 Control Information (Continued)

Current Receiver Status Register (CRS0)

The Current Receiver Status Register (CRS0) records the status of the Receiver state machine. It is continuously updated. It

remains stable when accessed.

When in Diagnose Mode, this register is frozen on an internal error until the internal error event is cleared by resetting the

RSMERR bit in the Internal Event Latch Register.

ACCESS RULES

Address

0Ch

Read

Write

Always

Data Ignored

REGISTER BITS

D7

D6

D5

D4

D3

D2

RTS2

D1

D0

RFLG

RS2

RS1

RS0

RES

RTS1

RTS0

Bit

Symbol

Description

D0–2

RTS(0–2)

Receive Timing State: RTS(0–2) represent the current state of the Receiver Timing state

machine. The encoding is shown below.

RTS2

RTS1

RTS0

Receive Timing State

0

1

0

1

0

1

0

1

0

1

x

Await SD

Ð

Check FC

Ð

Check SA

Ð

Check DA

Ð

Check INFO

Ð

Check MAC

Ð

Reserved

D3

RES

Reserved

D4–6

RS(0–2)

Receive State: RS(0–2) represent the current state of the Receive state machine that

implements the ANSI standard MAC Receive Functions. The encoding is shown below.

RS2

0

RS1

0

RS0

0

Receive State

Listen

0

1

Await SD

Ð

RC FR CTRL (Receive FC)

0

1

0

Ð

0

1

RC FR BODY (Rec FR Body)

Ð Ð

1

0

RC FR STATUS (A & C Ind)

Ð Ð

CHECK TOKEN (Check Token)

1

0

1

Ð

1

0

RC FR STATUS (Optional Ind)

Ð

Reserved

1

D7

RFLG

R Flag: Current value of the Restricted Flag. When not holding the token indicates the type of

Ð

the last valid token received. When holding the token indicates the type of token that will be

issued at the end of the current service opportunity.

0: Non-restricted

1: Restricted

34

6.0 Control Information (Continued)

Current Transmitter Status Register (CTS0)

The Current Transmitter Status Register (CTS0) records the status of the Transmitter state machine. It is continuously updated.

It remains stable when accessed. When in Diagnose Mode, this register is frozen on an internal error until the internal error

event is cleared by resetting the TSMERR bit of the Internal Event Latch Register.

ACCESS RULES

Address

0Eh

Read

Write

Always

Data Ignored

REGISTER BITS

D7

D6

D5

D4

D3

D2

TTS2

D1

D0

ROP

TS2

TS1

TS0

TTS3

TTS1

TTS0

Bit

Symbol

Description

D0–3

TTS(0–3)

TRANSMIT TIMING STATE: TTS(0–3) represent the current state of the Transmitter

Timing state machine. The encoding is shown below.

TTS3

TTS2

TTS1

TTS0

Transmit Timing State

Idle

Transmit Preamble

Wait for Data (FIFO)

Transmit SD & FC Fields

Transmit DA

Transmit SA

Transmit INFO

Transmit FCS

Transmit ED & FS

Reserved

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

9h–Fh

D4–6

TS(0–2)

Transmit State: TS(0–2) represent the current state of the Transmit state machine that

implements the ANSI standard MAC Transmit Functions. The encoding is shown below.

TS2

0

TS1

0

TS0

0

Transmit State

Idle

0

1

0

Repeat

Data

0

1

0

1

0

Issue Token

Claim

1

0

1

Beacon

Reserved

Void

1

0

1

D7

ROP

Ring Operational Flag: Indicates the current value of the local Ring Operational Flag.

35

6.0 Control Information (Continued)

Ring Event Latch Register (RELR0)

The Ring Event Latch Register 0 (RELR0) captures conditions that occur on the Ring including the receipt of Beacon and Claim

frames, transitions in the Ring Operational flag, and the receipt of duplicate addresses. Each bit may be masked via the Ring

Event Mask Register 0 (REMR0).

ACCESS RULES

Address

10h

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

PINV

D4

D3

D2

D1

D0

RES

DUPADD

OTRMAC

CLMR

BCNR

RNOP

ROP

Bit

Symbol

Description

D0

D1

D2

ROP

Ring Operational Set: Is set when the Local Ring Operational flag transitions from 0 to 1.

Ring Non-Operational Set: Is set when the Local Ring Operational flag transitions from 1 to 0.

RNOP

BCNR

Beacon Frame Received: Indicates that a valid Beacon frame was received. When set, restricted and

synchronous requests are not serviced. The type of Beacon frame received is given in Register RELR1.

D3

D4

D5

CLMR

Claim Frame Received: Indicates that a valid Claim frame was received. When set, restricted requests are

not serviced. The type of Claim frame received is given in Register RELR1.

OTRMAC

PINV

Other MAC Frame Received: Indicates that a MAC frame other than a Beacon or Claim frame was received.

When set, restricted requests are not serviced.

PHY Invalid Received: Indicates that a PHY Invalid was received. This could be the result of a PLAYER

Ð

device Reset operation.

PHY Invalid causes the MAC Receiver to enter state R0 (Listen).

Ð

D6

D7

DUPADD

RES

Duplicate Address Received: Indicates that a valid individual frame addressed to this station was received

with the A indicator set. This could be caused by either a MAC using the same address (duplicate address) or

a strip error at the Source (the frame was received twice).

Reserved

36

6.0 Control Information (Continued)

Ring Event Mask Register 0 (REMR0)

The Ring Event Mask Register 0 (REMR0) is used to mask bits in Register RELR0. If a bit in Register REMR0 is set to One, the

corresponding bit in Register RELR0 will be applied to the Interrupt Condition Register, which can then be used to generate an

interrupt.

ACCESS RULES

Address

11h

Read

Write

Always

REGISTER BITS

D7

D6

D5

PINV

D4

D3

D2

D1

D0

RES

DUPADD

OTRMAC

CLMR

BCNR

RNOP

ROP

Bit

Symbol

Description

D0

D1

D2

D3

D4

D5

D6

D7

ROP

Ring Operational Mask: This bit is used to mask RELR0.ROP.

Ring Non-Operational Mask: This bit is used to mask RELR0.RNOP.

Beacon Frame Mask: This bit is used to mask RELR0.BCNR.

Claim Frame Mask: This bit is used to mask RELR0.CLMR.

Other MAC Frame Mask: This bit is used to mask RELR0.OTRMAC.

RNOP

BCNR

CLMR

OTRMAC

PINV

PHY Invalid Mask: This bit is used to mask RELR0.PINV.

Ð

DUPADD

RES

Duplicate Address Mask: This bit is used to mask RELR0.DUPADD.

Reserved

37

6.0 Control Information (Continued)

Ring Event Latch Register 1 (RELR1)

The Ring Event Latch Register 1 (RELR1) captures the progress of the Beacon and Claim Processes. During the Beacon

Process, it records reception of an Other Beacon or a My Beacon. It also identifies Claim frames as Higher, Lower, or My

Claim. Each bit may be masked via the Ring Event Mask Register 1 (REMR1).

Ð

ACCESS RULES

Address

12h

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

D4

D3

D2

RES

D1

D0

LOCLM

HICLM

MYCLM

RES

MYBCN

OTRBCN

Bit

D0

Symbol

Description

OTRBCN

MYBCN

RES

Other Beacon Received: Indicates that an Other Beacon frame was received.

Ð Ð

D1

My Beacon Received: Indicates that a My Beacon frame was received.

Ð Ð

D2–4

D5

Reserved

MYCLM

My Claim Received: Indicates that a My Claim frame was received. (This includes the comparison

Ð Ð

between the T Bid Rec and TREQ as specified in the standard).

Ð

D6

D7

HICLM

Higher Claim Received: Indicates that a Higher Claim frame was received.

Ð Ð

LOCLM

Lower Claim Received: Indicates that a Lower Claim frame was received.

Ð Ð

38

6.0 Control Information (Continued)

Ring Event Mask Register 1 (REMR1)

The Ring Event Mask Register 1 (REMR1) is used to mask bits in Register RELR1. If a bit in Register REMR1 is set to One, the

corresponding bit in Register RELR1 will be applied to the Interrupt Condition Register, which can then be used to generate an

interrupt to the CPU.

All bits in this register are set to Zero upon reset.

ACCESS RULES

Address

13h

Read

Write

Always

REGISTER BITS

D7

D6

D5

D4

D3

RES

D2

D1

D0

LOCLM

HICLM

MYCLM

RES

MYBCN

OTRBCN

Bit

D0

Symbol

Description

OTRBCN

MYBCN

RES

Other Beacon Mask: This bit is used to mask RELR1.OTRBCN.

Ð

D1

My Beacon Mask: This bit is used to mask RELR1.MYBCN.

Ð

D2–4

D5

Reserved

MYCLM

HICLM

LOCLM

My Claim Mask: This bit is used to mask RELR1.MYCLM.

Ð

D6

Higher Claim Mask: This bit is used to mask RELR1.HICLM.

Ð

D7

Lower Claim Mask: This bit is used to mask RELR1.LOCLM.

Ð

39

6.0 Control Information (Continued)

Token and Timer Event Latch Register 0 (TELR0)

The Token and Timer Event Latch Register 0 (TELR0) informs software of expirations of the Token Rotation Timer (TRT) and

Valid Transmission Timer (TVX). The TELR0 Register also reports token events such as duplicate token detection, restricted

token reception, and general token capture and release. The completion of the Ring Latency measurement is also indicated in

the TELR0 Register. Each bit may be masked via the Token and Timer Event Mask Register (TEMR0).

ACCESS RULES

Address

14h

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RLVD TKPASS TKCAPT CBERR DUPTKR TRTEXP TVXEXP ENTRMD

Bit

Symbol

Description

D0

ENTRMD

Enter Restricted Mode: Indicates that a Restricted Token was received and that the R Flag transitioned

Ð

from 0 to 1.

D1

D2

D3

TVXEXP

TRTEXP

DUPTKR

TVX Expired: Indicates that a valid frame or token was not received in TVX time.

TRT Expired: Indicates that a valid token was not received within 2*TNEG.

Duplicate Token Received: Indicates that a valid token was received while the transmitter was in state T2

or T3.

D4

CBERR

Claim and/or Beacon Error: Indicates that the Claim and/or Beacon Process failed because TRT expired

while the Transmitter was in state T4 or T5.

D5

D6

TKCAPT

TKPASS

Token Captured: Indicates that a token has been captured.

Token Passed: Indicates that a valid token has been passed (without capturing it) or has been issued after a

service opportunity.

D7

RLVD

Ring Latency Valid:

0: This bit is set to Zero to request a new latency value from the Ring Engine. In Rev 01 and all future

Revisions, the Ring Latency count is set to zero before each measurement.

1: This bit is set to One when the Ring Latency measurement is complete.

This bit is written unconditionally and is not protected by the Compare Register.

40

6.0 Control Information (Continued)

Token and Timer Event Mask Register 0 (TEMR0)

The Token and Timer Event Mask Register 0 (TEMR0) is used to mask bits in Register TELR0. If a bit in Register TEMR0 is set

to One, the corresponding bit in Register TELR will be applied to the Interrupt Condition Register, which can then be used to

generate an interrupt.

All bits in this register are set to Zero upon reset.

ACCESS RULES

Address

Read

Write

15h

Always

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RLVD TKPASS TKCAPT CBERR DUPTOK TRTEXP TVXEXP ENTRMD

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

ENTRMD

TVXEXP

TRTEXP

DUPTOK

CBERR

TKCAPT

TKPASS

RLVD

Description

Enter Restricted Mode Mask: This bit is used to mask TELR0.ENTRMD.

TVX Expired Mask: This bit is used to mask TELR0.TVXEXP.

TRT Expired and Set Late Flag Mask: This bit is used to mask TELR0.TRTEXP.

Ð

Duplicated Token Received Mask: This bit is used to mask TELR0.DUPTOK.

Claim/Beacon Error Mask: This bit is used to mask TELR0.CBERR.

Token Captured Mask: This bit is used to mask TELR0.TKCAPT.

Token Passed Mask: This bit is used to mask TELR0.TKPASS.

Ring Latency Valid Mask: This bit is used to mask TELR0.RLVD.

41

6.0 Control Information (Continued)

Counter Increment Latch Register (CILR)

The Counter Increment Latch Register (CILR) records the occurrence of any increment to the Event Counters. Each bit

corresponds to a counter and is set when the corresponding counter is incremented. Each bit may be masked via the Counter

Increment Mask Register (CIMR).

ACCESS RULES

Address

18h

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RES TKRCVD FRTRX FRNCOP FRCOP FRLST FREI FRRCV

Bit

Symbol

Description

D0

FRRCV

Frame Received: Is set when the Frame Received Counter (FRCT) is incremented, indicating the reception

of a frame.

D1

D2

D3

D4

D5

D6

D7

FREI

Frame Error Isolated: Is set when the Error Isolated Counter (EICT) is incremented, indicating an error has

been insolated.

FRLST

FRCOP

FRNCOP

FRTRX

TKRCVD

RES

Frame Lost Isolated: Is set when the Lost Frame Counter (LFCT) is incremented, indicating a format error

has been detected in the frame.

Frame Copied: Is set when the Frame Copied Counter (FCCT) is incremented, indicating a frame has been

copied.

Frame Not Copied: Is set when the Frame Not Copied Counter (FNCT) is incremented, indicating a frame

could not be copied.

Frame Transmitted: Is set when the Frame Transmitted Counter (FTCT) is incremented, indicating a frame

has been transmitted.

Token Received: Is set when the Token Received Counter (TKCT) is incremented, indicating that a token

has been received.

Reserved

42

6.0 Control Information (Continued)

Counter Increment Mask Register (CIMR)

The Counter Increment Mask Register (CIMR) is used to mask bits from the Counter Increment Latch Register (CILR). If a bit in

Register CIMR is set to One, the corresponding bit in Register CILR will be applied to the Interrupt Condition Register, which can

then be used to generate an interrupt.

All bits in this register are set to Zero upon reset.

ACCESS RULES

Address

19h

Read

Write

Always

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RES TKRCVD FRTRX FRNCOP FRCOP FRLST FREI FRRCV

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

FRRCV

FREI

Description

Frame Received Counter Increment Mask: This bit is used to mask CILR.FRRCV.

Error Isolated Counter Increment Mask: This bit is used to mask CILR.FREI.

Lost Frame Counter Increment Mask: This bit is used to mask CILR.FRLST.

Frame Copied Counter Increment Mask: This bit is used to mask CILR.FRCOP.

Frame Not Copied Counter Increment Mask: This bit is used to mask CILR.FRNCOP.

Frame Transmitted Counter Increment Mask: This bit is used to mask CILR.FRTRX.

Token Received Counter Increment Mask: This bit is used to mask CILR.TKRCVD.

Reserved

FRLST

FRCOP

FRNCOP

FRTRX

TKRCVD

RES

43

6.0 Control Information (Continued)

Counter Overflow Latch Register (COLR)

The Counter Overflow Latch Register (COLR) records carry events from the 20th bit of the Event Counters. Each bit in the

COLR corresponds to an individual counter. Each bit may be masked via the Counter Overflow Mask Register (COMR).

ACCESS RULES

Address

1Ch

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RES TKRCVD FRTRX FRNCOP FRCOP FRLST FREI FRRCV

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

FRRCV

FREI

Description

Frame Received: Is set to One when the Frame Received Counter (FRCT) overflows.

Frame Error Isolated: Is set to One when the Error Isolated Counter (EICT) overflows.

Frame Lost Isolated: Is set to One when the Lost Frame Counter (LFCT) overflows.

Frame Copied: Is set to One when the Frame Copied Counter (FCCT) overflows.

Frame Not Copied: Is set to One when the Frame Not Copied Counter (FNCT) overflows.

Frame Transmitted: Is set to One when the Frame Transmitted Counter (FTCT) overflows.

Token Received: Is set to One when the Token Received Counter (TKCT) overflows.

Reserved

FRLST

FRCOP

FRNCOP

FRTRX

TKRCVD

RES

44

6.0 Control Information (Continued)

Counter Overflow Mask Register (COMR)

The Counter Overflow Mask Register (COMR) is used to mask bits from the Counter Overflow Latch Register (COLR). If a bit in

Register COMR is set to One, the corresponding bit in Register COLR will be applied to the Interrupt Condition Register, which

can then be used to generate an interrupt.

All bits in this register are set to Zero upon reset.

ACCESS RULES

Address

1Dh

Read

Write

Always

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

RES TKRCVD FRTRX FRNCOP FRCOP FRLST FREI FRRCV

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

FRRCV

FREI

Description

Frame Received Counter Overflow Mask: This bit is used to mask COLR.FRRCV.

Error Isolated Counter Overflow Mask: This bit is used to mask COLR.FREI.

Lost Frame Counter Overflow Mask: This bit is used to mask COLR.FRLST.

Frame Copied Counter Overflow Mask: This bit is used to mask COLR.FRCOP.

Frame Not Copied Counter Overflow Mask: This bit is used to mask COLR.FRNCOP.

Frame Transmitted Counter Overflow Mask: This bit is used to mask COLR.FRTRX.

Token Received Counter Overflow Mask: This bit is used to mask COLR.TKRCVD.

Reserved

FRLST

FRCOP

FRNCOP

FRTRX

TKRCVD

RES

45

6.0 Control Information (Continued)

Internal Event Latch Register (IELR)

The Internal Event Latch Register (IELR) reports internal errors in the BMAC device. These errors include MAC Parity errors and

inconsistencies in the Receiver and Transmitter state machines.

After an internal state machine is detected and reported (bit RSMERR for the receiver and TSMERR for the transmitter), the

Current Receive Status Register (CRS0) and Current Transmit Status Register (CTS0) continue to be updated as normal.

Errors internal to the BMAC device cause a MAC Reset.

Ð

ACCESS RULES

Address

28h

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

D4

D3

TSMERR

D2

D1

D0

RES

RSMERR

RES

MPE

Bit

D0

Symbol

Description

MPE

MAC Interface Parity Error: Indicates a Parity Error on the MAC Request Data pins (MRD7–0) when

parity is enabled on the MA Request Interface (bits MRP of the Mode Register is set and pin TXACK is

asserted).

Ð

D1

D2

RES

Reserved

RSMERR

Receive State Machine Error: Indicates inconsistency in the Receiver state machine. When set, causes

bit MCRST of the Function Register to be set.

D3

TSMERR

RES

Transmit State Machine Error: Indicates inconsistency in the Transmitter state machine. When set,

causes bit MCRST of the Function Register to be set.

D4–7

Reserved

46

6.0 Control Information (Continued)

Exception Status Register (ESR)

The Exception Status Register (ESR) reports errors to the software. Errors include PHY Interface Parity errors, illegal attempts

to access currently inaccessible registers, and writing to a conditional write location if a register bit has changed since it was last

read. Each bit may be masked via the Exception Mask Register (EMR).

ACCESS RULES

Address

2Ch

Read

Write

Always

Condition

REGISTER BITS

D7

D6

D5

CPE

D4

D3

D2

D1

D0

CWI

CCE

RES

PPE

Bit

D0

Symbol

Description

PPE

PHY Interface Parity Error: Indicates parity error detected on PID7–0. Parity errors are reported when

parity is enabled on the PHY Request Interface (bit PIP of the Mode Register is set).

Ð

D1–4

D5

RES

CPE

Reserved

Control Bus Parity Error: Indicates a Control Bus Parity Error was detected on the Control Bus Data pins

(CBD7–0) during a write operation to a register. Parity errors are reported if parity is enabled on the Control

Bus Interface (bit CBP of the Mode Register is set).

D6

D7

CCE

CWI

Control Bus Command Error: Indicates that a Control Bus command was not performed due to an error,

i.e., illegal command or a Control Bus Write Parity error. An illegal command is an attempt to access a

currently inaccessible register.

Conditional Write Inhibit: Indicates that at least one bit of the previous conditional write operation was not

written. This bit is set unconditionally after each write to a conditional write register if the value of the

Compare Register is not equal to the value of the register that was accessed for a write before it was

written. This may indicate that the accessed register has changed since it was last read.

This bit is cleared after a successful conditional write. This occurs when the value of the Compare Register

is equal to the value of the register that was accessed for a write before it was written.

CWI does not contribute to setting the ESE bit of the Interrupt Condition Register (it is always implicitly

masked).

47

6.0 Control Information (Continued)

Exception Mask Register (EMR)

The Exception Mask Register (EMR) is used to mask bits in the Exception Status Register (ESR). If a bit in Register EMR is set

to One, the corresponding bit in Register ESR will be applied to the Condition Register, which can then be used to generate an

interrupt.

All bits in this register are set to Zero upon request.

ACCESS RULES

Address

2Dh

Read

Write

Always

REGISTER BITS

D7

D6

D5

CPE

D4

D3

D2

D1

D0

ZERO

CCE

RES

PPE

Bit

D0

Symbol

Description

PPE

PHY Interface Parity Error Mask: This bit is used to mask ESR.PPE.

Reserved

D1–4

D5

RES

CPE

CCE

ZERO

Control Bus Parity Error Mask: This bit is used to mask ESR.CPE.

Control Bus Error Mask: This bit is used to mask ESR.CCE.

Zero: This bit is always Zero. This implies that the CWI bit never contributes to the Interrupt Signal.

D6

D7

48

6.0 Control Information (Continued)

Interrupt Condition Register (ICR)

The Interrupt Condition Register (ICR) collects unmasked interrupts from the Event Registers. Interrupts are categorized into

Ring Events, Token and Timer Events, Counter Events, and Error and Exceptional Status Events. If the bit in the Interrupt Mask

Register (IMR) and the corresponding bit in the ICR are set to One, the INT pin is forced low and thus triggers an interrupt.

Note: Bits are cleared ONLY by clearing underlying conditions (Mask bit and/or Event Bit) in the appropriate Event Register.

ACCESS RULES

Address

2Eh

Read

Write

Always

Data Ignored

REGISTER BITS

D7

D6

D5

D4

D3

D2

D1

D0

ESE

IERR

RES

COE

CIE

TTE

RNG

Bit

D0

Symbol

RNG

Description

Ring Event Interrupt: Is set if corresponding bits in the Ring Event Latch and Mask Registers are set.

D1

D2

D3

TTE

Token and Timer Event Interrupt: Is set if corresponding bits in the Token and Timer Event Latch and

Mask Registers are set.

CIE

Counter Increment Event Interrupt: Is set if corresponding bits in the Counter Increment Latch and Mask

Registers are set.

COE

Counter Overflow Event Interrupt: Is set if corresponding bits in the Counter Overflow Latch and Mask

Registers are set.

D4–5

D6

RES

IERR

ESE

Reserved

Internal Error Interrupt: Is set if any bits in the Internal Event Register are set.

D7

Exception Status Event Interrupt: Is set if corresponding bits in the Exception Status and Mask Registers

are set.

49

6.0 Control Information (Continued)

Interrupt Mask Register (IMR)

The Interrupt Mask Register (IMR) is used to mask bits in the Interrupt Condition Register (ICR). If a bit in Register IMR and the

corresponding bit in Register ICR are set to One, the INT pin is forced low and causes an interrupt. Each bit in the IMR

corresponds to an Event Register or a pair of Event Registers and associated bits.

ACCESS RULES

Address

2Fh

Read

Write

Always

REGISTER BITS

D7

D6

D5

RES

D4

D3

D2

D1

D0

ESE

IERR

RES

COE

CIE

TTE

RNG

Bit

D0

Symbol

RNG

TTE

Description

Ring Event Mask: This bit is used to mask ICR.RNG.

Token and Timer Event Mask: This bit is used to mask ICR.TTE.

Counter Increment Event Mask: This bit is used to mask ICR.CIE.

Counter Overflow Event Mask: This bit is used to mask ICR.COE.

Reserved

D1

D2

D3

CIE

COE

RES

IERR

ESE

D4–5

D6

Internal Error Mask: This bit is used to mask ICR.IERR.

Exception Status Event Mask: This bit is used to mask ICR.ESE.

D7

50

6.0 Control Information (Continued)

6.5 MAC PARAMETERS

The MAC Parameters are accessible in the Stop Mode. These parameters are also accessible in the Run Mode when the

following conditions are met:

a) the MAC Transmitter is in state T0, T1, or T3; and

b) bits ITC and IRR of the Option Register are set to One; and

c) bits CLM and BCN of the Function Register are set to Zero.

Otherwise read and write accesses will cause a command error (bit CCE of the Exception Status Register is set to One) and the

access will not be performed.

The MAC Parameters are stored in the MAC Parameter RAM. They include the following control information:

Individual Addresses: My Long Address (MLA0–5) and My Short Address (MSA0–1).

#

Group Addresses: Group Long Address (GLA0–4) and Group Short Address (GSA0), Programmable Group Map

(PGM0–1F), and Fixed Group Map (FGM0–1).

#

MAC Frame Information: Requested Target Token Rotation Time (TREQ0–3) and Transmit Beacon Type (TBT0–3).

#

6.5.1 Individual Addresses

The Ring Engine supports both Long and Short Individual Addresses simultaneously. The Station’s Long Address is stored in

registers MLA0–5. The Station’s Short Address is stored in register MSA0–1.

For received frames, MLA or MSA is compared with the received DA in order to set the Address recognized Flag (A Flag) and

compared with the received SA in order to set the My Address recognized Flag (M Flag). In transmitted frames, MLA or MSA

normally replaces the SA from the frame data stream (exception: when SA transparency is used).

Bits MLA(47) and MSA(15) are the most significant bits of the address and are transmitted and received first. Bits MLA(0) and

MSA(0) are the least significant bits of the address and are transmitted and received last.

MLA and MSA should be valid for at least 12 byte times before the Addressing Mode is enabled and should remain valid for at

least 12 byte times after the Addressing Mode is disabled in order to guarantee proper detection.

Bits ELA (Enable Long Addressing) and ESA (Enable Short Addressing) in the Option Register determine the address types that

may be recognized and generated by this MAC.

My Long Address

My Long Address (MLA0–MLA5) represent this station’s long 48-bit address.

ACCESS RULES

Address

Read

Write

40–45h

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

MLA0

MLA(47)

MLA(39)

MLA(31)

MLA(23)

MLA(15)

MLA(7)

MLA(46)

MLA(38)

MLA(30)

MLA(22)

MLA(14)

MLA(6)

MLA(45)

MLA(37)

MLA(29)

MLA(21)

MLA(13)

MLA(5)

MLA(44)

MLA(36)

MLA(28)

MLA(20)

MLA(12)

MLA(4)

MLA(43)

MLA(35)

MLA(27)

MLA(19)

MLA(11)

MLA(3)

MLA(42)

MLA(34)

MLA(26)

MLA(18)

MLA(10)

MLA(2)

MLA(41)

MLA(33)

MLA(25)

MLA(17)

MLA(9)

MLA(1)

MLA(40)

MLA(32)

MLA(24)

MLA(16)

MLA(8)

MLA(0)

MLA1

MLA2

MLA3

MLA4

MLA5

Note: MLA(47) should always be set to 0.

My Short Address

My Short Address (MSA0–MSA1) represent this station’s short 16-bit address.

ACCESS RULES

Address

Read

Write

46–47h

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

MSA0

MSA1

MSA(15)

MSA(7)

MSA(14)

MSA(6)

MSA(13)

MSA(5)

MSA(12)

MSA(4)

MSA(11)

MSA(3)

MSA(10)

MSA(2)

MSA(9)

MSA(1)

MSA(8)

MSA(0)

Note: MSA(15) should always be set to 0.

51

6.0 Control Information (Continued)

6.5.2 Group Addresses

The Ring Engine supports detection of Group Addresses within programmable and fixed blocks of consecutive addresses. The

algorithm used by the Ring Engine first performs a comparison between the most significant bits of the received DA with

programmable and fixed addresses. If the most significant bits match, the remaining bits are used as an index into a programma-

ble bit map. If the indexed bit is 1, the A Flag is set to 1; if the indexed bit is 0 the A flag remains 0.

One programmable block of 128 group addresses is supported for group long addresses (GLA) and one programmable block of

group addresses is supported for group short addresses (GSA). Both of the programmable ranges share the same programma-

ble group address map (PGM).

For short addresses, the first byte of a received DA is compared with GSA0 (bits GSA(15–8)). If they match then the second

byte is used as an index into the PGM. For long addresses the first 5 bytes of a received DA are compared with GLA0 through

GLA4 (bits GLA(47–8)). If all 5 of these bytes match the corresponding byte in the received DA, then the 6th byte of the

received DA is used as an index into the PGM. The last byte of the address is used as an index into the PGM in both long and

short group addressing.

A fixed block of 16 group addresses is supported for both long and short addresses at the end of the address space that

includes the Universal/Broadcast address (FF...FF). For short addresses, if the first 12 bits of the received DA are all 1’s then

the last 4 bits are used as an index into the 16-bit Fixed Group Map (FGM). Similarly, for long addresses if the first 44 bits are all

1’s, the last 4 bits are also used as an index into the 16-bit FGM.

The Group Addresses should be valid for at least 12 byte times before the Addressing Mode is enabled and should remain valid

for at least 12 byte times after the Addressing Mode is disabled in order to guarantee proper detection.

Bits ELA (Enable Long Addressing) and ESA (Enable Short Addressing) in the Option Register determine the address types that

will be recognized by this MAC.

Alternative group addressing schemes may be implemented using external matching logic that monitors the byte stream at the

PHY Interface. The result of the comparison is returned using the EA (External A Flag) pin.

Ð

Group Long Address

Group Long Address (GLA0–GLA4) represents the first 5 bytes of the long address, bit GLA(47) to bit GLA(8).

To disable Long Group Address matches, bits GLA(46–8) should be set to all 1’s.

ACCESS RULES

Address

Read

Write

48–4Ch

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

GLA0

GLA(47)

GLA(39)

GLA(31)

GLA(23)

GLA(15)

GLA(46)

GLA(38)

GLA(30)

GLA(22)

GLA(14)

GLA(45)

GLA(37)

GLA(29)

GLA(21)

GLA(13)

GLA(44)

GLA(36)

GLA(28)

GLA(20)

GLA(12)

GLA(43)

GLA(35)

GLA(27)

GLA(19)

GLA(11)

GLA(42)

GLA(34)

GLA(26)

GLA(18)

GLA(10)

GLA(41)

GLA(33)

GLA(25)

GLA(17)

GLA(9)

GLA(40)

GLA(32)

GLA(24)

GLA(16)

GLA(8)

GLA1

GLA2

GLA3

GLA4

Note: Bit GLA(47) should always be set to ONE.

52

6.0 Control Information (Continued)

Group Short Address

Group Short Address (GSA0) represents the station’s short 16-bit address, bit GSA(15) to bit GSA(8).

It is possible to disable Short Group Addressing by programming bits GSA(14–8) to all Ones.

ACCESS RULES

Address

Read

Write

4Eh

Stop Mode

D7

GSA(15)

D6

D5

D4

D3

D2

D1

D0

GSA4

GSA(14)

GSA(13)

GSA(12)

GSA(11)

GSA(10)

GSA(9)

GSA(8)

Design Note: GSA(15) is not used in the comparison since the comparison will only be accomplished if the received DA(15) is a One.

Fixed Group Address MAP (FGM0–FGM1)

If the first 44 bits of a long DA, DA(47–4), or if the first 12 bits of a short DA, DA(15–4) are 1, the last 4 bits of the DA, DA(3–0),

are used as an index into FGM.

The 4-bit index into FGM can be viewed in two different ways. It can be viewed as 4 bits selecting one of 16 bits where the

hexidecimal equivalent of DA(3–0) can be used as the index. For example the broadcast address would index FGM(F). Alterna-

tively it can be viewed as one bit, DA(3), selecting the byte (FGM0 or FGM1) and three bits, DA(2–0) selecting one of 8 bits

within a byte.

ACCESS RULES

Address

Read

Write

58–59h

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

FGM0

FGM1

FGM(7)

FGM(F)

FGM(6)

FGM(E)

FGM(5)

FGM(D)

FGM(4)

FGM(C)

FGM(3)

FGM(B)

FGM(2)

FGM(A)

FGM(1)

FGM(9)

FGM(0)

FGM(8)

Note: Bit FGM(F) must be set to One to ensure proper handling of frames with the Universal/Broadcast address including the SMT NSA frames. This is mandatory

for interoperability on an FDDI Ring.

53

6.0 Control Information (Continued)

Programmable Group Address MAP (PGM0–PGM1F)

If the first 40 bits of a long DA, DA(47–8), match the GLA or if the first 8 bits of a short DA, DA(15–8), match the GSA, the last 8

bits of the DA are used as an index into PGM.

The 8-bit index into PGM can be viewed in two different ways.

1. As 8 bits selecting one of 256 bits where the hexidecimal equivalent of DA(7–0) can be used as the index. For example a DA

with the last byte as A2h indexes PGM(A2).

2. As 5 bits, DA(7–3), selecting the byte (PGM0 to PGM1F) and three bits, DA(2–0) selecting one of 8 bits within a byte. For

example a DA with the last byte of A2h (10100010b) selects PGM14 bit 2.

It is possible to disable Long and Short Group Addressing by filling the Group Address Map with 0’s.

In REV 1 of the BMAC device, PGM(00) to PGM(7F) are hardwired to 0 and are not accessible via the Control Interface. This

e

implies that group addresses with DA(7)

0 can not be recognized.

In REV 2 of the BMAC device, PGM(00) to PGM(7F) are set equal to PGM(80) to PGM(FF) and are accessible via the Control

Interface. This implies that DA(7) of group addresses is a don’t care.

ACCESS RULES

Address

Read

Write

70–7Fh

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

PGM0

PGM(7)

PGM(6)

PGM(E)

PGM(5)

PGM(4)

PGM(3)

PGM(2)

PGM(1)

PGM(0)

PGM1

PGM2

PGM3

PGM4

PGM5

PGM6

PGM7

PGM8

PGM9

PGMA

PGMB

PGMC

PGMD

PGME

PGMF

PGM(F)

PGM(D)

PGM(15)

PGM(1D)

PGM(25)

PGM(2D)

PGM(35)

PGM(3D)

PGM(45)

PGM(4D)

PGM(55)

PGM(5D)

PGM(65)

PGM(6D)

PGM(75)

PGM(7D)

PGM(C)

PGM(14)

PGM(1C)

PGM(24)

PGM(2C)

PGM(34)

PGM(3C)

PGM(44)

PGM(4C)

PGM(54)

PGM(5C)

PGM(64)

PGM(6C)

PGM(74)

PGM(7C)

PGM(B)

PGM(A)

PGM(9)

PGM(8)

PGM(17)

PGM(1F)

PGM(27)

PGM(2F)

PGM(37)

PGM(3F)

PGM(47)

PGM(4F)

PGM(57)

PGM(5F)

PGM(67)

PGM(6F)

PGM(77)

PGM(7F)

PGM(16)

PGM(1E)

PGM(26)

PGM(2E)

PGM(36)

PGM(3E)

PGM(46)

PGM(4E)

PGM(56)

PGM(5E)

PGM(66)

PGM(6E)

PGM(76)

PGM(7E)

PGM(13)

PGM(1B)

PGM(23)

PGM(2B)

PGM(33)

PGM(3B)

PGM(43)

PGM(4B)

PGM(53)

PGM(5B)

PGM(63)

PGM(6B)

PGM(73)

PGM(7B)

PGM(12)

PGM(1A)

PGM(22)

PGM(2A)

PGM(32)

PGM(3A)

PGM(42)

PGM(4A)

PGM(52)

PGM(5A)

PGM(62)

PGM(6A)

PGM(72)

PGM(7A)

PGM(11)

PGM(19)

PGM(21)

PGM(29)

PGM(31)

PGM(39)

PGM(41)

PGM(49)

PGM(51)

PGM(59)

PGM(61)

PGM(69)

PGM(71)

PGM(79)

PGM(10)

PGM(18)

PGM(20)

PGM(28)

PGM(30)

PGM(38)

PGM(40)

PGM(48)

PGM(50)

PGM(58)

PGM(60)

PGM(68)

PGM(70)

PGM(78)

54

6.0 Control Information (Continued)

Programmable Group Address MAP (PGM0–PGM1F) (Continued)

ACCESS RULES

Address

Read

Write

60–6Fh

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

PGM10

PGM(87)

PGM(8F)

PGM(97)

PGM(9F)

PGM(A7)

PGM(AF)

PGM(B7)

PGM(BF)

PGM(C7)

PGM(CF)

PGM(D7)

PGM(DF)

PGM(E7)

PGM(EF)

PGM(F7)

PGM(FF)

PGM(86)

PGM(8E)

PGM(96)

PGM(9E)

PGM(A6)

PGM(AE)

PGM(B6)

PGM(BE)

PGM(C6)

PGM(CE)

PGM(D6)

PGM(DE)

PGM(E6)

PGM(EE)

PGM(F6)

PGM(FE)

PGM(85)

PGM(8D)

PGM(95)

PGM(9D)

PGM(A5)

PGM(AD)

PGM(B5)

PGM(BD)

PGM(C5)

PGM(CD)

PGM(D5)

PGM(DD)

PGM(E5)

PGM(ED)

PGM(F5)

PGM(FD)

PGM(84)

PGM(8C)

PGM(94)

PGM(9C)

PGM(A4)

PGM(AC)

PGM(B4)

PGM(BC)

PGM(C4)

PGM(CC)

PGM(D4)

PGM(DC)

PGM(E4)

PGM(EC)

PGM(F4)

PGM(FC)

PGM(83)

PGM(8B)

PGM(93)

PGM(9B)

PGM(A3)

PGM(AB)

PGM(B3)

PGM(BB)

PGM(C3)

PGM(CB)

PGM(D3)

PGM(DB)

PGM(E3)

PGM(EB)

PGM(F3)

PGM(FB)

PGM(82)

PGM(8A)

PGM(92)

PGM(9A)

PGM(A2)

PGM(AA)

PGM(B2)

PGM(BA)

PGM(C2)

PGM(CA)

PGM(D2)

PGM(DA)

PGM(E2)

PGM(EA)

PGM(F2)

PGM(FA)

PGM(81)

PGM(89)

PGM(91)

PGM(99)

PGM(A1)

PGM(A9)

PGM(B1)

PGM(B9)

PGM(C1)

PGM(C9)

PGM(D1)

PGM(D9)

PGM(E1)

PGM(E9)

PGM(F1)

PGM(F9)

PGM(80)

PGM(88)

PGM(90)

PGM(98)

PGM(A0)

PGM(A8)

PGM(B0)

PGM(B8)

PGM(C0)

PGM(C8)

PGM(D0)

PGM(D8)

PGM(E0)

PGM(E8)

PGM(F0)

PGM(F8)

PGM11

PGM12

PGM13

PGM14

PGM15

PGM16

PGM17

PGM18

PGM19

PGM1A

PGM1B

PGM1C

PGM1D

PGM1E

PGM1F

55

6.0 Control Information (Continued)

6.5.3 Claim Information: Requested Target Token Rotation Time (TREQ)

The Requested Target Token Rotation Time (TREQ) is stored in registers TREQ0–TREQ3. TREQ(31–0) is represented as a

negative two’s complement number. This value is transmitted in all Claim frames generated by the Ring Engine.

Bits TREQ(31–24) are always transmitted as and compared with FFh and bits TREQ(7–0) are always transmitted as and

compared with 00h, independent of the value stored in the MAC Parameter RAM. TREQ is therefore programmable with

20.48 ms resolution and a maximum value of 1.34 seconds.

ACCESS RULES

Address

Read

Write

50–53h

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

TREQ0

TREQ(31)

TREQ(23)

TREQ(15)

TREQ(7)

TREQ(30)

TREQ(22)

TREQ(14)

TREQ(6)

TREQ(29)

TREQ(21)

TREQ(13)

TREQ(5)

TREQ(28)

TREQ(20)

TREQ(12)

TREQ(4)

TREQ(27)

TREQ(19)

TREQ(11)

TREQ(3)

TREQ(26)

TREQ(18)

TREQ(10)

TREQ(2)

TREQ(25)

TREQ(17)

TREQ(9)

TREQ(1)

TREQ(24)

TREQ(16)

TREQ(8)

TREQ(0)

TREQ1

TREQ2

TREQ3

6.5.4 Beacon Information: Transmit Beacon Type (TBT)

Transmit Beacon Type 0–3 (TBT0–3) represents the Transmit Beacon Type to be transmitted in the information field of a

Beacon frame.

When the Beacon state is reached as a result of a failed Claim process, the first byte of the Beacon Information field, bits

TBT31–24, are forced to Zero to produce a Beacon Type 0 as required by the MAC Standard. Bits TBT(23–0) are transmitted

as the rest of the Information field.

When the Beacon state is reached as a result of a Beacon Request (when Function.BCN is set), bits TBT(31–0) are transmitted

as the Information field. Bit TBT(0) is transmitted last.

ACCESS RULES

Address

Read

Write

54–57h

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

TBT0

TBT(31)

TBT(23)

TBT(15)

TBT(7)

TBT(30)

TBT(22)

TBT(14)

TBT(6)

TBT(29)

TBT(21)

TBT(13)

TBT(5)

TBT(28)

TBT(20)

TBT(12)

TBT(4)

TBT(27)

TBT(19)

TBT(11)

TBT(3)

TBT(26)

TBT(18)

TBT(10)

TBT(2)

TBT(25)

TBT(17)

TBT(9)

TBT(1)

TBT(24)

TBT(16)

TBT(8)

TBT(0)

TBT1

TBT2

TBT3

56

6.0 Control Information (Continued)

6.6 TIMER VALUES

The Ring Engine stores several timer values and thresholds used in normal operation. With the exception of TNEG, the timers

use an exponential expansion on a 4-bit value to produce a negative twos complement 24-bit value used by the Timer Logic.

The timer values are always readable and are writable in Stop Mode.

Asynchronous Priority Threshold (THSH1)

The Ring Engine currently supports one Asynchronous Priority Threshold (THSH1) in addition to the one at TTRT. The Asyn-

chronous Priority Threshold is used in a magnitude comparison with THT when an Asynchronous Priority Request is presented

to the MAC Request Interface.

Bits 7–4 are always written to Zero and are always read as Zero.

When more than one threshold is used, the users of THSH1 have the lowest priority. All asynchronous transmissions are limited

by TTRT. If the Late Flag is set, no frames may be transmitted, regardless of the value of the Asynchronous Priority Threshold.

ACCESS RULES

Address

Read

Write

87h

Always

Stop Mode

D7

D6

Zero

D5

D4

D3

D2

D1

D0

THSH1

Zero

THSH(3)

THSH(2)

THSH(1)

THSH(0)

Time remaining in THT

THSH1(3–0)

when token becomes unusable

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

10.24 ms

20.48 ms

40.96 ms

81.92 ms

163.84 ms

327.68 ms

655.36 ms

1.3107 ms

2.6214 ms

5.2429 ms

10.486 ms

20.972 ms

41.943 ms (default)

83.886 ms

167.77 ms

335.54 ms

Warning: The default value may not be appropriate for all values of TNEG.

In some cases, this could result in a request that is NEVER serviced.

57

6.0 Control Information (Continued)

Maximum Token Rotation Time (TMAX)

The Maximum Token Rotation Time (TMAX) denotes the maximum Target Token Rotation Time supported by this station.

TMAX is stored as a 4-bit value that is expanded to a binary exponential value. Bits 7–4 are ignored during write operations and

are always read as Zero.

TMAX

c

to One), TMAX is set to the value of Ch which corresponds to 167.772 ms, the default specified by the FDDI MAC Standard.

TMAX has a maximum value of 1.34 seconds with a threshold of 40.96

2

ms. On a Master Reset (Function.MARST set

ACCESS RULES

Address

Read

Write

93h

Always

Stop Mode

D7

D6

Zero

D5

D4

D3

D2

D1

D0

TMAX

Zero

TMAX(3)

TMAX(2)

TMAX(1)

TMAX(0)

TMAX(0–3)

Time

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

40.96 ms

81.92 ms

163.84 ms

327.68 ms

655.36 ms

1.3107 ms

2.6214 ms

5.2429 ms

10.486 ms

20.972 ms

41.943 ms

83.886 ms

167.77 ms (default)

335.54 ms

671.09 ms

1.3422s

58

6.0 Control Information (Continued)

Valid Transmission Time (TVX)

The Valid Transmission Timer (TVX) is used to increase the responsiveness of the ring to errors that cause ring recovery. The

TVX value denotes the maximum time in which a valid frame or token should be seen by this station. TVX is stored as a 4-bit

value that is expanded to a binary exponential value. Bits 7–4 are ignored during write operations and read as Zero.

TVX

TVX has a maximum value of 1.34 seconds with a threshold of 40.96 X 2

ms. On a Master Reset (Function.MARST is set to

One), TVX is set to the value of 6h which corresponds to 2.62 ms, the default by the FDDI MAC Standard.

ACCESS RULES

Address

Read

Write

97h

Always

Stop Mode

D7

D6

Zero

D5

D4

D3

D2

D1

D0

TVX

Zero

TVX(3)

TVX(2)

TVX(1)

TVX(0)

TVX(0–3)

Time

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

40.96 ms

81.92 ms

163.84 ms

327.68 ms

655.36 ms

1.3107 ms

2.6214 ms (default)

5.2429 ms

10.486 ms

20.972 ms

41.943 ms

83.886 ms

167.77 ms

335.54 ms

671.09 ms

1.3422s

59

6.0 Control Information (Continued)

Negotiated Target Rotation Time (TNEG)

The Negotiated Target Rotation Time (TNEG0–3) is a 32-bit twos complement value. It is the result of the Claim Process. TNEG

is loaded either directly from the received Claim Information field (T Bid Rc) or via the Control Interface.

Ð

The first byte of TNEG (bits TNEG(31–24)) always contains FFh. TNEG has a maximum value of 1.34 seconds and a resolution

of 80 ns.

TRT is loaded with TNEG when the Ring Operational flag is set. TNEG is not automatically compared with TREQ when the

Ð

Ring Operational flag is set. This should be checked by software whenever the ring becomes operational to make sure that

Ð

TNEG is less than or equal to TREQ.

An implementation of the SM Control.Request (Reset) should load TNEG with TMAX to remove any possibility of the station

Ð

entering Claim early.

On a Master Reset (Function.MARST is set), TNEG is set to FFE00000, which corresponds to 167.772 ms, the default TMAX

specified by the FDDI MAC Standard.

ACCESS RULES

Address

Read

Write

98–9Bh

Always

Stop Mode

D7

D6

D5

D4

D3

D2

D1

D0

TNEG0

TNEG(31)

TNEG(23)

TNEG(15)

TNEG(7)

TNEG(30)

TNEG(22)

TNEG(14)

TNEG(6)

TNEG(29)

TNEG(21)

TNEG(13)

TNEG(5)

TNEG(28)

TNEG(20)

TNEG(12)

TNEG(4)

TNEG(27)

TNEG(19)

TNEG(11)

TNEG(3)

TNEG(26)

TNEG(18)

TNEG(10)

TNEG(2)

TNEG(25)

TNEG(17)

TNEG(9)

TNEG(1)

TNEG(24)

TNEG(16)

TNEG(8)

TNEG(0)

TNEG1

TNEG2

TNEG3

60

6.0 Control Information (Continued)

6.7 EVENT COUNTERS

The Event Counters are used to gain access to the internal 20-bit counters used to gather statistics.

The following event counters are included:

Frame Received Counter (FRCT1–3)

#

Error Isolated Counter (EICT1–3)

#

Lost Frame Counter (LFCT1–3)

#

Frame Copied Counter (FCCT1–3)

#

Frame Not Copied Counter (FNCT1–3)

#

Frame Transmitted Counter (FTCT1–3)

#

Token Received Counter (TKCT1–3)

#

Ring Latency Counter (RLCT1–3)

#

Late Count Counter (LTCT)

#

6.7.1 Processing Procedures

The counters are 20-bit wrap-around counters except for the Late Count Counter which is a 4-bit sticky counter (seeFigure 6-2 ).

Since the Control Bus Interface is an 8-bit interface and the counters are 20-bits wide, a register holding scheme is implement-

ed. In order to provide a consistent snapshot of a counter, while the least significant byte is read, the upper 12 bits are loaded

into a holding which can then be read. The least significant byte must be read first.

The Counters are always readable and are writable in Stop Mode. The Counters are not reset as a result of a Master Reset. This

may be done by either reading the Counters out and keeping track relative to the initial value read, or by writing a value (Zero) to

all of the Counters in Stop Mode. The Counters may be written in any order. Interrupts may be requested when the counters

increment (except for Ring Latency Counter) or wrap-around (except for Ring Latency Counter and Late Count Counter).

TL/F/10387–10

FIGURE 6-2. Event Counters

61

6.0 Control Information (Continued)

Frame Received Counter (FRCT)

The Frame Received Counter (FRCT) is specified in the FDDI MAC Standard. It is the count of all complete frames received

including MAC frames, Void frames and frames stripped by this station.

Interrupts are available on increment (CILR.FRRCV) and when the 20-bit counter overflows and wraps around (COLR.FRRCV).

ACCESS RULES

Address

Read

Write

A0–A3h

Always

Stop Mode

D7

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

FRCT0

FRCT1

FRCT2

FRCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

62

6.0 Control Information (Continued)

Error Isolated Counter (EICT)

The Error Isolated Counter (EICT) is specified in the FDDI MAC Standard. It is the count of all error frames detected by this

station and no previous station.

It is incremented when:

1) an FCS error is detected and the received Error Indicator (Er) is not equal to S; or

2) a frame of invalid length (i.e., off-boundary T) is received and Er is not equal to S; or

3) Er is not R or S

Interrupts are available on increment (CILR.FREI) and when the 20-bit counter overflows and wraps around (COLR.FREI).

ACCESS RULES

Address

Read

Write

A4–A7h

Always

Stop Mode

D7

Zero

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

EICT0

EICT1

EICT2

EICT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

63

6.0 Control Information (Continued)

Lost Frame Counter (LFCT)

The Lost Frame Counter (LFCT) is specified in the FDDI MAC Standard. It is the count of all instances where a Format Error is

detected in a frame or token such that the credibility of the PDU reception is in doubt.

The Lost Frame Counter is incremented when any symbol other than a data or Idle symbol is received between the Starting and

Ending Delimiters of a PDU (this includes parity errors).

Interrupts are available on increment (CILR.FRLST) and when the 20-bit counter overflows and wraps around (COLR.FRLST).

ACCESS RULES

Address

Read

Write

A8–ABh

Always

Stop Mode

D7

Zero

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

LFCT0

LFCT1

LFCT2

LFCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

In REV 1 of the BMAC device the Lost Count includes frames stripped on an ODD symbol boundary. This may cause larger than

expected counts in Rings where an upstream station produces valid remnants that begin on an ODD symbol boundary. (The

Ring Engine converts these remnants to byte aligned remnants, so that only the downstream station would increment its Lost

Count.) In subsequent revisions remnants that begin on an odd symbol boundary are not considered lost frames and do not

cause the Lost Count to increment.

64

6.0 Control Information (Continued)

Frame Copied Counter (FCCT)

The Frame Copied Counter (FCCT) maintains the count of the number of frames successfully copied by this station. This

counter can be used to accumulate station performance statistics.

The Frame Copied Counter is incremented when an internal or external match occurs on the Destination Address, no errors

were detected in the frame, and the frame was successfully copied (VCOPY signal is asserted). Copied MAC and Void frames

are not included in this count.

For SMT NSA frames, the Frame Copied Count only increments for NSA frames received with the A Indicator as an R symbol for

which the frame was copied. SMT NSA frames received with the A Indicator as an S do not cause this count to increment, even

if the frame is successfully copied.

Increments are available on increment (CILR.FRCOP) and when the 20-bit counter overflows and wraps around (COLR.FRC-

OP).

ACCESS RULES

Address

Read

Write

AC–AFh

Always

Stop Mode

D7

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

FCCT0

FCCT1

FCCT2

FCCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

65

6.0 Control Information (Continued)

Frame Not Copied Counter (FNCT)

The Frame Not Copied Counter (FNCT) maintains a count of the number of frames intended for this station that were not

successfully copied by this station. This count can be used to accumulate station performance statistics such as insufficient

buffering or deficient frame processing capabilities for frames addressed to this station.

The Frame Not Copied Counter is incremented when an internal or external match (when Option.EMIND enabled) occurs on the

Destination Address, no errors were detected in the frame, and the frame was not successfully copied (VCOPY signal not

asserted). Not Copied MAC frames and Void frames are not included in this count.

Interrupts are available on increment (CILR.FRNCOP) and when the 20-bit counter overflows and wraps around (COLR.FRN-

COP).

ACCESS RULES

Address

Read

Write

B0–B3h

Always

Stop Mode

D7

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

FNCT0

FNCT1

FNCT2

FNCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

In REV 1 of the BMAC device, the Frame Not Copied Counter does increment for all NSA frames received with the A indicator

as an S symbol, if it was copied or not. This will result in higher than expected values in the Not Copied Counter. To obtain a

more accurate value with REV 1 of the BMAC device, the number of copied NSA frames received with the A Indicator set should

be subtracted from the value in the Not Copied Counter.

In subsequent revisions of the BMAC device, NSA frames received with the A Indicator as S that are not copied will not be

counted.

In REV 2 the handling of SMT NSA has been modified in accordance with the MAC-2 Draft Standard. For SMT NSA frames, the

Frame Not Copied Count only increments for NSA frames received with the A Indicator as an R symbol for which the frame was

not copied. SMT NSA frames received with the A Indicator as an S do not cause this count to increment, even if the frame is not

successfully copied. Group addressed frames transmitted by this station and recognized by this station that are not copied will

also cause this counter to increment.

66

6.0 Control Information (Continued)

Frame Transmitted Counter (FTCT)

The Frame Transmitted Counter (FTCT) maintains the count of frames transmitted successfully by this station. The counter can

be used to accumulate station performance statistics.

The Frame Transmitted Counter is incremented every time a complete frame is transmitted from the MAC Request Interface.

MAC and Void frames generated by the Ring Engine are not included in the count.

Interrupts are available on increment (CILR.FRTRX) and when the 20-bit counter overflows and wraps around (COLR.FRTRX).

ACCESS RULES

Address

Read

Write

B4–B7h

Always

Stop Mode

D7

Zero

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

FTCT0

FTCT1

FTCT2

FTCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

67

6.0 Control Information (Continued)

Token Received Counter (TKCT)

The Token Received Counter (TKCT) maintains the count of valid tokens received by this station. The counter can be used with

the Ring Latency Counter to calculate the average network load over a period of time. The frequency of token arrival is inversely

related to the network load.

The Token Received Counter is incremented every time a valid token arrives.

Interrupts are available on increment (CILR.TKRCVD) and when the 20-bit counter overflows and wraps around

(COLR.TKRCVD).

ACCESS RULES

Address

Read

Write

B8–BBh

Always

Stop Mode

D7

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

TKCT0

TKCT1

TKCT2

TKCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

68

6.0 Control Information (Continued)

Ring Latency Counter (RLCT)

The Ring Latency Counter (RLCT) is a measurement of time for PDUs to propagate around the ring. This counter contains the

last measured ring latency whenever the RLVD bit of the Token and Timer Event Latch Register (TELR.RLVD) is One.

The current ring latency is measured by timing the propagation of a My Void frame around the ring. A new latency measure-

Ð

ment can be requested by clearing the Ring Latency Valid bit of the Token Event Register (TELR.RLVLD).

When the ring is operational, the next early token is captured. Before the token is re-issued, a My Void frame is transmitted and

Ð

the Ring Latency Counter (RLCT) is reset. The token will not be captured if the Inhibit Token Option (Option.ITC) is set and the

ring latency will not be measured.

When the ring is not operational, ring latency timing will commence at the end of the next immediate request. A My Void is

Ð

transmitted and RLCT is reset. This could be used to time how long the ring is non-operational since the My Void frame will not

Ð

return.

The Ring Latency Counter increments once every 16 byte times from when the Ending Delimiter of the My Void frame is

Ð

transmitted, until the Ending Delimiter of the My Void frame returns. When the My Void frame returns, the ring latency valid bit

Ð

(TELR.RLVLD) is set and may cause an interrupt. When set, RELR.RLVLD indicates that RLCT will be valid within 1.28 ms. The

Ring Latency Counter can measure ring latencies up to 1.3421772 seconds with accuracy of 1.28 ms.

The ring latency timing function is automatically disabled when exceptions are detected and retried at the next opportunity.

Since a Master Reset (Function.MARST) causes TELR.RLVLD to be cleared, the ring latency will automatically be measured on

the first opportunity (at the end of the first immediate request or with the first early token).

ACCESS RULES

Address

Read

Write

BC–BFh

Always

Stop Mode

D7

D6

Zero

D5

Zero

D4

Zero

D3

D2

D1

D0

RLCT0

RLCT1

RLCT2

RLCT3

Zero

CT(19)

CT(11)

CT(3)

CT(18)

CT(10)

CT(2)

CT(17)

CT(9)

CT(1)

CT(16)

CT(8)

CT(0)

CT(15)

CT(7)

CT(14)

CT(6)

CT(13)

CT(5)

CT(12)

CT(4)

In REV 1 of the BMAC device, the Latency Counter is not reset to Zero when a new latency measurement is initiated. The

latency count will be the difference between the value of RLCT after the measurement is complete and the value of RLCT

before the measurement was initiated.

If a new latency measurement causes the latency counter to overflow, the new latency value will be less than the previous value.

In this case, no subtraction is necessary. The new value is equal to the ring latency. This is because the Ring Engine recognizes

the overflow condition and restarts the latency count from zero.

e

It is not possible to reset the Latency counter in software once the BMAC device has been put into RUN mode (Mode.Run 1).

e

This counter is only writable while in STOP mode (Mode.Run 0).

69

6.0 Control Information (Continued)

Late Count (LTCT)

The Late Count Counter (LTCT) is implemented differently than suggested by the FDDI MAC Standard, but provides similar

information. The function of the Late Count Counter is divided between the Late Flag and a separate counter. The Late Flag

Ð

is equivalent to the Standard Late Count with a non-zero value. It is maintained by the Ring Engine to indicate if it is possible to

send asynchronous traffic. When the ring is operational, Late Count indicates the time it took the ring to recover the last time the

ring went non-operational. When the ring is non-operational, Late Count indicates the time it has taken (so far) to recover the

ring.

Late Count is provided to assist Station Management in the isolation of serious ring errors. In many situations, it is helpful for

SMT to know how long it has been since the ring went non-operational in order to determine if it is necessary to invoke recovery

procedures. When the ring becomes non-operational, there is no way to know how long it will stay non-operational, therefore a

timer is necessary. If the Late Count Counter is not provided, SMT would be forced to start a timer every time the ring goes non-

operational even though it may seldom be used. By using the provided Late Count Counter, an SMT implementation may be able

to alleviate this additional overhead.

Late Count is incremented every time TRT expires while the ring is non-operational and Late Flag is set (once every TMAX).

Ð

This counter is never writable, not even in Stop Mode. The counter is set to Zero as a result of a MAC Reset when a Beacon or

Claim Request is not also present (Function.MCRST is set and Function.BCN and Function.CLM are not set) and every time the

ring becomes non-operational. The Late Count Counter is a sticky counter at 15.

Events reported in the Token and Timer Event Latch Register (TELR.CBERR, TELR.TRTEXP) can be used to determine that

Late Count Counter has incremented. No overflow event is provided.

ACCESS RULES

Address

Read

Write

9Fh

Always

n/a

D7

D6

D5

D4

D3

D2

D1

D0

LTCT

Zero

CT3

CT2

CT1

CT0

70

7.0 Signal Descriptions

Interface Organization

The BMAC device signals are organized into five Interfaces:

Control Interface: Used for processor access to the BMAC device.

PHY Interface: Interface signals to the DP83251/55 PLAYER device.

MAC Indicate Interface: Signals for receiving and processing incoming frames.

MAC Request Interface: Signals used to capture tokens and transmit frames.

Electrical Interface: Signals associated with power supply and clocking.

Application Note 689, BMAC Device Hardware Design Guide, provides a discussion of design considerations and tradeoffs for

using the BMAC Device.

7.1 CONTROL INTERFACE

The Control Interface operates asynchronous to the operation of the data services. During an access, the external Control Bus

is synchronized with the internal Control Bus.

The ACK and INT signals are open drain signals to allow wire ORing several such signals.

Ý

Symbol

I/O

Description

CBP

10

I/O Control Bus Parity: Odd parity on CBD7–0.

CBD7–0 9–6, 3–1, I/O Control Bus Data

132

CBA7–0 131–129,

127–123

I

Control Bus Address: Address of a particular register.

CE

120

119

122

I

Control Bus Enable: Handshake signal used to begin a Control Interface access. Active low signal.

E

Read/ Write: Determines current direction of a Control Interface access.

R/W

ACK

E

Acknowledge: Acknowledges that the Control Interface access has been performed. Active low,

open drain signal.

OD

E

Interrupt: Indicates presence of one or more enabled condition(s) from the Event Registers.

Active low, open drain signal.

INT

121

OD

71

7.0 Signal Descriptions (Continued)

7.2 PHY INTERFACE

The PHY Interface signals transfer symbol pairs between the BMAC and PLAYER devices. Transfers are synchronous using the

12.5 MHz Local Byte Clock signal (signal provided by the Clock Distribution Device).

A control bit is used to indicate if a Data symbol pair or Control symbol pair or a mixed Control/Data symbol pair are being

transferred.

Parity is generated on the PHY Indicate and MA Indicate data. Parity is checked on the PHY Request and MA Request

Ð

data.

Symbol

PRP

Ý

114

112

I/O

O

Description

PHY Request Parity: Odd parity for PRC and PRD7–0.

PRC

O

PHY Request Control:

0: Indicates PRD7–0 contains a Data symbol pair.

1: Indicates PRD7–0 contains a Control or mixed Control/Data symbol pair.

PRD7–0 110, 108,

105, 103,

O

PHY Request Data: Contains a Data or Control symbol pair.

99, 97,

95, 92

PIP

PIC

115

113

I

PHY Indicate Parity: Odd parity for PIC and PID7–0.

PHY Indicate Control:

0: Indicates PID7–0 contains a Data symbol pair.

1: Indicates PID7–0 contains a Control or mixed Control/Data symbol pair.

PID7–0

111, 109,

107, 104,

102, 98,

96, 93

I

PHY Indicate Data: Contains a Data or a mixed Control/Data symbol pair.

72

7.0 Signal Descriptions (Continued)

7.2.1 PHY Interface Codes

The DP83251/155 PLAYER device converts the Standard 4B/5B FDDI symbol code to the internal code used at the PHY

Interface. The PH DATA.Indication table shows how the Ring Engine interprets the codes generated by the PLAYER device

Ð

and the PH DATA. Request table shows the codes generated by the Ring Engine.

Ð

The internal code is actually an 8B/9B code with parity where one bit is used to determine whether the symbol pair contains two

data symbols or at least one control symbol.

PH DATA.Indication

Ð

The Ring Engine interprets the byte stream the PLAYER device as defined in Table 7-1.

TABLE 7-1. Internal PHY Indicate Coding

Value

PIP

1

PIC

0

:

PID(7–4)

0000

:

PID(3–0)

0000

0001

:

Type

0

1

:

Data Symbol Pair

:

0

:

254

0

1

0

1

1111

1101

x011

10xx

0000

0110

0111

0101

0000

????

1110

1111

xxxx

Data Symbol Pair

Start Delimiter

255

1

JK

P

PI

x1xx

xx1x

xxxx

PH Invalid

Ð

PI

PH Invalid

Ð

II

Idle Symbols

nI

10xx

0110

0111

0101

0111

0110

0101

xxxx

Data/Idle Symbol

Frame Status

RR

RS

Frame Status

RT

Frame Status

SS

Frame Status

SR

Frame Status

ST

Frame Status

SX

Frame Status

TX

xxxx

Ending Delimiter

Mixed Symbol Pair

Code Violation

TR

0110

0111

0101

????

TS

TT

nT

E

Parity Error

Otherwise

P

?

Else

where:

PIP

PHY Indicate Parity bit, ODD parity

PHY Indicate Control bit:

PIC

l

e

0

1

data byte,

control/mixed byte

PID(7–0) PHY Indicate Data(7–0)

E

P

represents ODD Parity ( P is Bad Parity)

represents a don’t care and is not decoded

represents a 1 or 0 but not both.

x–

?

The PLAYER device aligns the received JK to a byte boundary. Thus, no provision is made in the internal code or by the Ring

Engine for off boundary JKs.

The Idle and PH Invalid encodings overlap. Idle symbols received while the PLAYER device is in Active Line State (ALS) or Idle

Ð

Line State (ILS) are not considered PH INVALID. Idle symbols received while the PLAYER device is in states other than ALS or

ILS are treated as PH Invalid.

Ð

73

7.0 Signal Descriptions (Continued)

PH DATA.Request

Ð

The Ring Engine generates the 10 bit byte stream as defined in Table 7-2. Note that all symbol pairs are either control or data

symbol pairs. Mixed data/control symbol pairs are never generated or repeated by the Ring Engine.

TABLE 7-2. Internal PHY Request Coding

Value

0

PRP

1

PRC

0

PRD(7–4)

0000

:

PRD(3–0)

0000

0001

:

Type

Data Symbol Pair

:

1

0

:

254

255

JK

II

0

1111

1101

1010

0110

0111

0101

1110

1111

1101

1010

0110

0111

0101

0111

0110

0101

0110

0111

0101

Data Symbol Pair

Start Delimiter

Idle Symbols

Frame Status

Ending Delimiter

1

0

1

0

1

RR

RS

RT

SS

SR

ST

TR

TS

TT

0

1

0

1

0

1

0

1

0

1

Where:

PRP

PHY Request Parity bit, parity for all symbol pairs is ODD

PHY Request control bit:

PRC

l

e

0

1

data byte

control byte

PRD(7–0) PHY Request Data (7–0)

The Ring Engine can repeat the RS, RT and ST symbol pairs but does not create them.

74

7.0 Signal Descriptions (Continued)

7.3 MAC INDICATION INTERFACE

The MAC Indication Interface provides a delayed version of the byte stream presented to the Ring Engine at the PHY Indication

Interface. Every byte of all incoming frames is presented at the MAC Indication Interface. Every byte time (80 ns) one byte of

data with Odd parity is presented at the MAC Indication Interface. This byte stream is interpreted by the system interface logic

using the control signals that are provided in parallel with the byte stream. These control signals are used to determine frame

boundaries in the byte stream, determine whether or not to (continue to) copy a frame, and to provide status on received PDUs.

In the following sections, an overview of the signals is provided (Section 7.3.1) as well as a detailed explanation (Section 7.3.2)

with several example timing scenarios (Section 7.3.3).

7.3.1 Overview

The MAC Indication Interface is divided into one group of data signals and five groups of control signals.

The data signals consist of the 8 bits of MAC Indicate Data (MID) with parity.

The control signals consist of 5 groups:

PDU Sequencing to aid in delimiting PDUs from the byte stream and sequencing through fields in the received PDUs.

#

PDU Flags to aid in the decision of whether or not to continue to copy a PDU.

#

Termination Event to determine when and how a PDU terminated.

#

Termination Status to provide status on received frames.

#

External Flags to allow external address comparison and copy information to be conveyed back to the Ring Engine.

#

The PDU Sequencing signals are asserted at different points within a PDU.

RCSTART when the Starting Delimiter is present on MID

FCRCVD when the Frame Control Field is on MID

DARCVD when the last byte of the DA is on MID until the next Starting Delimiter

SARCVD when the last byte of the SA is on MID until the next Starting Delimiter

INFORCVD when the fourth byte of the info field is on MID until the next Starting Delimiter

Not all of the sequencing signals would be used in a typical implementation.

The PDU Flags provide the input for potential copy criteria and status breakpoints. The results of the comparisons between the

station’s long or short address and the frame’s source and destination addresses are provided in the AFLAG and MFLAG

signals. The sequencing information is used to determine when this information is valid. Since the Ring Engine is capable of

accomplishing four internal comparisons on any given frame, two signals give the internal comparison that was accomplished.

AFLAG

Internal DA Match. There are actually four AFLAGs as determined by the two signals: FCSLÐShort/Long, DAIGÐ

Individual/Group. Valid with DARCVD.

MFLAG

Internal SA Match. There are actually two MFLAGs as determined by the values of FCSL. Valid with SARCVD.

SAMESA SA same as in previous frame. Valid with SARCVD on Non-MAC frames. Can be used by external logic to batch

status or reduce the number of interrupts when multiple frames are received from the same station.

SAMEINFO First four bytes of Info same as in previous frame. Valid with INFORCVD on MAC frames. Can be used to inhibit

copying of identical MAC frames.

No temporary buffering is provided in the Ring Engine. The system interface must provide this buffering while the decision is

made on whether or not to continue to copy the frame.

Termination Event: One of these signals is asserted at the end of every PDU:

EDRCVD when the Ending Delimiter is on MID until the end of the Frame Status (typically asserted for two byte times)

TKRCVD when the Ending Delimiter of a token is on MID

FRSTRP when the first Idle byte of a stripped frame is on MID

FOERROR when the byte with the format error is on MID

MACRST when a MACRST occurs or Ring Engine in Stop Mode

75

7.0 Signal Descriptions (Continued)

Termination Status: These signals provide status on reception of a valid ending delimiter on a frame.

VDL

Valid Data Length.

Criteria:

1. more than the minimum number bytes

2. integral number of symbol pairs.

Valid with EDRCVD

VFCS

Valid FCS Criteria: Received FCS matches with standard CRC polynomial.

Valid with EDRCVD

External Flags: These signals are used for setting the outgoing control indicators, the interface accepts:

EA

For external address matches for the setting of the A indicator (bridging, Group addressing, Aliasing)

For the setting of the C Indicator when AFLAG or EA is set.

VCOPY

76

7.0 Signal Descriptions (Continued)

7.3.2 Signals

All output signals change relative to the rising edge of the Local Byte Clock signal (provided by the Clock Distribution Device)

and are active high.

7.3.2.1 Indication Data

Ý

Symbol

I/O

O

Description

MIP

73

MAC Indicate Parity: Odd parity on MID7–0. Only valid with Data and Status Indicators.

MID7–0 74–76,

79–83

O

MAC Indicate Data:

Data: Indicates data is being presented on MID7–0 between the rising edge of Frame Control Receive

FCRCVD and the rising edge of one of the following signals:

Ending Delimiter Received (EDRCVD),

Token Received (TKRCVD),

Format Error (FOERROR),

Frame Strip (FRSTRP),

or MAC Reset (MACRST).

Status: Indicates Status Indicators are being presented on MID7–0 while Ending Delimiter Received

(EDRCVD) or Token Received (TKRCVD) is asserted.

The Contents and interpretation of MID7–0 are given in Table 7-3.

TABLE 7-3. MAC Indication Coding

Contents

Value

MID(7–4)

MID(3–0)

Condition

Data

0

:

0

1

2

:

Between RCSTART and

EDRCVD or

1

2

:

TKRCVD or

FRSTRP or

:

FOERROR or

MACRST

254

255

F

E

F

Status

TT

TR

TS

TX

nT

5

0

6

7

5

with EDRCVD or TKRCVD

with EDRCVD

6

7

ⁱ5, 6 or 7

5

6

7

5

6

7

RT

RR

RS

ST

SR

SS

undefined

otherwise

x

otherwise

77

7.0 Signal Descriptions (Continued)

7.3.2.2 PDU Sequencing

The PDU Sequencing signals apply to the data and status available at the MAC Indicate Interface. They are used to determine

the validity of the data (MID7–0) and parity (MIP). In addition the sequencing signals are used to determine the validity of the

Addressing Flags, and the Frame Status such as the Control Indicators. All timing is explained relative to the byte present on the

MAC Indicate Interface.

Ý

Symbol

51

I/O

Description

RCSTART

O

Receive Start: Indicates that a MAC PDU Starting Delimiter has been received. It is asserted when

the Starting Delimiter is present at the MAC Indicate Interface.

FCRCVD

DARCVD

52

55

O

Frame Control Received: Indicates that the Frame Control field is present. It is asserted when the

Frame Control field is present at the MAC Indicate Interface.

Destination Address Received: Indicates that the Destination Address has been received. It is

asserted on the last byte of the Destination Address and remains asserted until the next PDU Starting

Delimiter is received.

SARCVD

59

62

O

Source Address Received: Indicates that the Source Address has been received. It is asserted on

the last byte of the Source Address and remains asserted until the next PDU Starting Delimiter is

received.

INFORCVD

Information Field Received: Indicates that four bytes of the Information field have been received. It

is asserted on the fourth byte of the INFO field and remains active until the next PDU Starting

Delimiter is received.

78

7.0 Signal Descriptions (Continued)

7.3.2.3 PDU Flags

The PDU flags may be used with the received Frame Control field to determine if an attempt should be made to copy the frame.

Ý

Symbol

56

I/O

Description

AFLAG

O

My Destination Address Recognized: Indicates that an internal address match occurred on the

Destination Address field. The internal address (MSA, MLA, GSA, GLA) match is indicated by the

assertion of FCSL and DAIG. AFLAG is asserted along with DARCVD. It is reset when the next PDU

Starting Delimiter is received.

DAIG

FCSL

54

53

O

Individual/Group Address Flag: Indicates the address type. Valid on the first byte of the Destination

Address.

0: Individual Address

1: Group Address

Short/Long Address Flag: Indicates the size of the Destination Address. Signal is valid when

FCRCVD is asserted.

0: Short Address

1: Long Address

Used in conjunction with TKRCVD to indicate the type of token received.

0: Non-restricted token

1: Restricted token

MFLAG

60

61

O

My Source Address Recognized: Indicates that the received Source Address field matched the

MLA or MSA. SA.IG is ignored in the comparison. MFLAG is asserted along with SARCVD. It is reset

when the next PDU Starting Delimiter is received.

SAMESA

Same Source Address: Indicates three conditions:

1. The Source Address of the current frame is the same as the Source Address of the previous frame

AND

2. The current and previous frames were not MAC frames AND

3. The current and previous frames have the same address field size.

SAMESA is asserted along with SARCVD. It is reset when the next PDU starting delimiter is received.

SAMEINFO

63

O

Same MAC Information: Indicates two conditions:

1. The first 4 bytes of the information field of the current frame are identical to the first 4 bytes of the

previous non-Void frame AND

2. The current and previous non-Void frames were MAC frames.

SAMEINFO is asserted along with INFORCVD. It is reset when the next PDU Starting Delimiter is

received.

Note that the FC field is not checked to insure that it is the same as in the previous frame. This

includes the address size comparison.

In REV1 of the BMAC Device Void frames are not ignored as stated in 1 and 2 above.

79

7.0 Signal Descriptions (Continued)

7.3.2.4 Termination Event

The terminating event for all PDUs is provided in the PDU Status signals.

When a token is terminated by a valid Ending Delimiter (TT symbol pair), the TKRCVD signal is asserted. When a frame is

terminated by a valid Ending Delimiter, the EDRCVD is asserted and remains asserted until all frame status has been passed to

the MA Indicate Interface. Every PDU is terminated by one of the following:

Ð

1. A valid Ending Delimiter (TKRCVD or EDRCVD)

2. An IDLE symbol indicating that the frame was stripped by another station (FRSTRP)

3. A symbol other than data, Idle or an Ending Delimiter indicating that a Format Error occurred (FOERROR)

4. A MAC Reset (MACRST)

Ý

Symbol

TKRCVD

EDRCVD

I/O

O

Description

69

Token Received: Indicates that the Ending Delimiter for a valid token is being received.

66

71

70

72

O

Ending Delimiter Received: Indicates that the Ending Delimiter for a frame is being received. The

values of the received Status Indicators are available through the MID byte stream on this and

subsequent cycles while this signal is asserted.

FRSTRP

O

Frame Stripped: Indicates that an Idle symbol was received while expecting part of a PDU. This

usually indicates that the PDU was stripped by an upstream station. This signal may be asserted

anytime during reception of a frame after RCSTART is asserted.

FOERROR

MACRST

Format Error: Indicates that a Format Error (non-DATA, IDLE or Ending Delimiter Symbol) was

detected. This signal may be asserted anytime during reception of a frame including with RCSTART

for the next frame.

MAC Reset: Indicates that a MAC Reset has been issued. This signal is asserted as a result of a

software or hardware reset, or internal errors. This signal is asserted whenever bit MCRST of the

Function Register is set. This signal may be asserted anytime.

7.3.2.5 Termination Status

When a valid Ending delimiter is received after a valid starting delimiter, the termination status signals provided the results of the

Frame validity check and the Frame Check Sequence Check.

The received values of the control indicators are presented in the data stream while EDRCVD is asserted.

Ý

Symbol Pin

I/O

Description

VDL

68

O

Valid Data Length: Indicates that a frame meeting the minimum length requirements of the Standard

and of an even number of symbols was received. This signal is valid with EDRCVD.

VFCS

67

O

Valid Frame Check Sequence: Indicates that a frame with the standard CRC was received. This signal

is valid with EDRCVD.

80

7.0 Signal Descriptions (Continued)

7.3.2.6 External Flags

The External Flags provide input to the Ring Engine in order to set the A and C indicators or in order to initiate stripping based on

external logic.

Ý

Symbol Pin

I/O

Description

EA

38

I

External A Flag: Indicates that an external address match occurred. The value of EA is used to alter

Ð

the values of the transmitted A and C Indicators (Ax and Cx). EA must be valid one byte time before

EDRCVD is asserted. When the EMIND bit in the Option Register is set, the A Indicator is repeated as set

(S symbol) and either the Copied or Not Copied Frame Counter is incremented depending on the value of

VCOPY.

EM

39

I

External M Flag: Indicates that the current frame should be stripped. Three byte times after the EM

Ð

signal is asserted, the Ring Engine begins to source Idle symbols and the frame is stripped.

VCOPY

85

Valid Copy: Indicates that the C Indicator (Cx) should be repeated as an S symbol for received frames

when VCOPY is asserted, the received frame is not an SMT NSA frame received with the A indicator as

Set and

1. the internal A flag is set or

Ð

e

2. Option.EMIND 1 and the external A flag (EA) is set;

Ð

See Section 5.5 for a complete description of the setting of the control indicators.

VCOPY must be valid one byte time before EDRCVD is asserted and remain asserted until EDRCVD is

asserted.

The sampled value of VCOPY with EDRCVD also affects the incrementing of the frame copied and frame

not copied counters. See the description of the event counters for more information.

81

7.0 Signal Descriptions (Continued)

7.3.3 Timing Examples

The following examples show the sequencing of signals at the MAC Indicate Interface for well formed frames, for stripped

frames and for several special cases. The diagrams show the logical operation of the interface with 0 ns delays. The actual

delays are specified in Section 8. Also, in place of specifying the actual values for the flags and inputs, the cycles where they are

valid (for outputs) or must be valid (for inputs) are shown.

Frame Reception

The examples shown in Figures 7-1 through 7-3 display normal frame reception for a frame with a Short Address and a frame

with a Long Address.

TL/F/10387–5

FIGURE 7-1. Frame Reception with Short Address

82

7.0 Signal Descriptions (Continued)

83

7.0 Signal Descriptions (Continued)

TL/F/10387–8

FIGURE 7-3. Token Reception

Remnant Reception

In these examples, the remnants of frames that were stripped by an upstream station are received. Examples are shown for

frames where the strip point occurred at an upstream station before, during and after the SA field. (SeeFigures 7-4 through7-6.)

TL/F/10387–9

FIGURE 7-4. Frame Stripped before SA Field

84

7.0 Signal Descriptions (Continued)

85

7.0 Signal Descriptions (Continued)

86

7.0 Signal Descriptions (Continued)

Frame Stripping

87

7.0 Signal Descriptions (Continued)

88

7.0 Signal Descriptions (Continued)

Abnormal Termination Conditions

89

7.0 Signal Descriptions (Continued)

TL/F/10387–17

e

*MAC Reset can be asserted at any time. When MODE0.RUN

0 MACRST is asserted and remains asserted.

FIGURE 7-10. MAC Reset

90

7.0 Signal Descriptions (Continued)

7.4 MAC REQUEST INTERFACE

The MAC Request Interface is used to gain access to the ring and to transmit data into the ring. After a Request is submitted to

the interface, the Ring Engine awaits for an appropriate Service Opportunity in which to service the Request. Frames associated

with the Request are transmitted during an appropriate Service Opportunity. Sections 5.2 and 5.3 provide important information

related to the functional operation of the interface.

In the following sections, an overview (Section 7.4.1) and detailed signal description (Section 7.4.2) are provided. The detailed

description includes a signal by signal description followed by a state diagram that details the operation of the handshaking

signals. Finally several example timing scenarios are shown (Section 7.4.3).

7.4.1 Overview

The MAC Request Interface signals provide the Request and Frame level handshakes required to transmit frames.

The MAC Request Interface is divided into one group of data signals and four groups of control signals.

The data signals consist of the 8 bits of MAC Request data with optional parity.

The control signals consist of:

Handshake signals that implement a Request level and Frame level handshake. The state machines that specify the

interface handshake are provided and described in detail in Section 7.4.3.

#

Service Parameters that convey the requested type of Service Opportunity.

#

Frame Options that convey the special transmission options. These are especially useful for MAC level bridging applica-

tions.

#

Transmission Status that report the success and/or failure of the transmission.

#

7.4.2 Signals

Request Data

The MRD7–0 signals change on the rising edge of the Local Byte Clock signal (provided by the Clock Distribution Device).

Ý

Symbol

I/O

Description

MAC Request Parity: Odd parity on MRD7–0.

MRP

41

I

MRD7–0 42–49

MAC Request Data: Data byte conveyed for transmission while the Transmit Acknowledge (TXACK)

signal is asserted.

91

7.0 Signal Descriptions (Continued)

Handshake

The Handshake signals control the Request Interface handshaking process. They are used for token capture and transmission

of PDUs.

Ý

Symbol

I/O

Description

TXPASS

28

O

Transmit Pass: Indicates the absence of a Service Opportunity. This could result from an unusable

request class, waiting for a token, timer expiration or MAC Reset. TXPASS is always asserted between

service opportunities. It is deasserted when TXRDY signal is asserted at the beginning of a Service

Opportunity.

TXRDY

29

O

Transmit Ready: Indicates that the Transmitter is ready for another frame. For a non-immediate

request, a usable token must be held in order to transmit frames. TXRDY is asserted when:

a) A usable token is being held or

b) An immediate request becomes serviceable or

c) After frame transmission if the current Service Opportunity is still usable for another frame.

It is deasserted when the TXPASS or TXACK signal is asserted.

RQRDY

23

24

I

Request Ready: Indicates that the Transmitter should attempt to provide a Service Opportunity as

indicated by the RQRCLS(3–0) signals one cycle before RQRDY is asserted. The Service Opportunity

will be maintained as long as possible. If RQRDY is asserted within 6 byte times after TXRDY signal is

asserted, the Transmitter will wait at least L Max plus one Void frame (4.16 ms or 4.80 ms) for

Ð

RQSEND to be asserted before releasing the token.

RQSEND

Request Send: Indicates that the Transmitter should send the next frame. The MRD(7–0) signals

convey the FC byte when the RQSEND signal is asserted. If RQSEND is asserted within 6 byte times

after the TXRDY signal is asserted, the Transmitter will send the frame with a minimum length

preamble. If RQSEND is not asserted within L Max plus one Void frame after RQRDY signal has been

Ð

asserted (4.16 ms or 4.60 ms), the token may become unusable (due to a timer expiration).

For Immediate transmissions from the Claim or Beacon State (when RQCLM or RQBCN is asserted),

RQSEND must be asserted no later than 8 byte times after TXRDY is asserted.

RQSEND may only be asserted when TXRDY and RQRDY signals are asserted and RQFINAL is

deasserted. RQSEND must be deasserted not later than one byte time after TXRDY is deasserted.

TXACK

30

0

Transmit Acknowledge: Indicates that the Transmitter is ready for the next data byte. TXACK is

asserted when the FC byte is accepted on MRD7–0, and remains asserted for each additional data

byte accepted. It is deasserted one byte time after RQEOF ro RQABT is asserted. The signal is also

deasserted when TXABORT or TXPASS is asserted.

RQEOF

RQABT

RQFINAL

25

27

26

I

Request End of Frame: Indicates that MRD7–0 conveys the last data byte when asserted. Normally,

this is the last byte of the INFO field of the frame (exceptions: FCS transparency, invalid frame length).

RQEOF causes TXACK to be deasserted and is ignored if TXACK is not asserted.

Request Abort: Indicates that the current frame should be aborted. Normally this causes the

Transmitter to generate a Void, Claim, or Beacon frame. RQABT causes TXACK to be deasserted and

will prevent TXACK assertion. The BMAC will ignore RQABT if asserted with RQEOF.

Request Final: Indicates that the final frame of the request has been presented to the MAC Interface.

When asserted, the Issue Token Class (as opposed to the Capture Token Class) becomes the new

Token Class (TXCLASS). RQFINAL may only be asserted when RQRDY is asserted and RQSEND is

deasserted. RQFINAL is ignored unless RQRDY has been asserted for at least one byte time and the

service parameters have been valid for at least three byte times. RQFINAL must be deasserted not

later than two byte times after RQSEND is deasserted.

92

7.0 Signal Descriptions (Continued)

Service Parameters

The Service Parameters define the Service Request. They must be valid for at least one byte time before the RQRDY signal is

asserted and must not change while RDRDY remains asserted. See Section 5.3.1 for the encoding of RQRCLS.

The Requested Service corresponds to the Request Service Class and the Token Class parameters of the

(SM )MA DATA.request and (SM )MA Token.request primitives as specified in the Standard.

Ð

Encoded into each of the 14 possible values of RQRCLS in the Service Class (Non-Restricted Asynchronous, Restricted

Asynchronous, Synchronous, Immediate), the Token Capture and Issue Class, and THT Enable.

Requests are serviced on a Service Opportunity meeting the requested criteria.

External support is required to limit the requests presented to the MAC Interface by different MAC Users (SMT, LLC, etc.).

Ý

Symbol

I/O

Description

RQRCLS(3–0) 19–22

I

Request Class: Indicates the Service Class parameters for this request (see Section 5.3.1).

l

When RQRCLS 0, the Transmitter will capture a usable token (for non-immediate requests)

and assert TXRDY. The Service Opportunity continues as long as the token is usable with the

current service parameters, even if RQRDY is not asserted. If RQRCLS indicates a service class

that is not serviceable for any cycle of a service opportunity, the service opportunity will conclude

after the current frame and a token of the issue token class will be issued.

e

issued (even if RQRCLS subsequently becomes non-zero). See Table 5-3.

If RQRCLS

0, the Service Opportunity will terminate after the current frame and a token will be

RQCLM

RQBCN

15

16

I

Request Claim: Indicates that this request is to be serviced in the Claim state. Ignored for non-

immediate requests.

Request Beacon: Indicates that this request is to be serviced in the Beacon state. Ignored for

non-immediate requests.

Frame Options

The Frame Options signals are selected for each frame. They must be valid while the RQSEND signal is asserted. These

options are typically used in bridging applications.

Ý

Symbol Pin

I/O

Description

STRIP

13

I

Void Strip: Forces two My Void frames to be transmitted on end of current Service Opportunity.

Ð

Stripping continues until a My Void frame returns. If any frame of a Service Opportunity requests this

Ð

option, then all frames on that Service Opportunity will be stripped using this method.

SAT

12

I

Source Address Transparency: When SA transparency is selected, the SA from the data stream is

transmitted in place of the internal MSA or MLA stored in the MAC Parameter RAM.

SAIGT

FCST

11

14

Source Address I/G Transparency: With this option, the MSB of the SA is sourced from the data

stream, as opposed to being forced to zero.

Frame Check Sequence Transparency: When selected, the Ring Engine generated FCS is not

appended to the end of the Information field.

93

7.0 Signal Descriptions (Continued)

Transmission Status

Ý

Symbol

TXED

I/O

Description

31

O

Transmitted Ending Delimiter: Indicates that the Transmitter completed transmission of the current

or previous PDU. TXED is asserted when the current PHY Request byte is a transmitted (not

repeated) Ending Delimiter. It remains asserted until the beginning of either the next transmitted (not

repeated) PDU or the next Service Opportunity. TXED is cleared by the Master Reset (bit MARST of

the Function Register).

TXABORT

32

O

Transmission Aborted: Indicates that the Transmitter aborted transmission of the current or

previous PDU before the Ending Delimiter, or that the current Service Opportunity was aborted by

Reset or Recovery actions. TXABORT is asserted when the current transmitted (not repeated) PDU

has been aborted, and remains valid until the end of the transmitted Void frame.

TXABORT is cleared by Master Reset (bit MARST of the Function Register). It is also cleared when

an Immediate Claim or Beacon Service Opportunity is terminated by My Claim or My Beacon

received (i.e., when transition T(47) or T(54) occurs during an Immediate Service Opportunity).

Ð

TXRINGOP

TXCLASS

37

35

O

Ring Operational: Indicates the current value of the Ring Operational flag.

Ð

Token Class: Indicates the class of the current or previous token in the Transmitter. TXCLASS is set

to R Flag when a valid token is received. TXCLASS is set to the Issue Token Class when the

Ð

RQRDY and RQFINAL signals are asserted (before Token FC time) for the current Service

Opportunity. It is cleared by Reset and Recovery actions.

THTDIS

36

O

Token Holding Timer Disabled: Indicates that the Token Holding Timer was disabled when the

current PHY Request byte was generated. THTDIS only changes between frames. When either signal

TXRDY or TXPASS is asserted after a frame, THTDIS reflects the THT usage for that frame for at

least two byte times. When TXPASS is asserted while THTDIS is asserted it indicates that TRT

expired.

94

7.0 Signal Descriptions (Continued)

7.4.3 Operation

The MAC Request Interface has three logical states as determined by TXRDY and TXPASS. The interface state machine is

shown in Figure 7-11 followed by a description of the conditions, states and transitions.

State

Description

TXRDY

TXPASS

MR0: Not Ready

MR1: Ready

MR2: Sending

Ring Engine is not ready to service a request

Ring Engine is ready to transmit a frame

Ring Engine is sending a frame

0

1

0

1

0

TL/F/10387–18

FIGURE 7-11. MAC Request Interface State Machine

Conditions

Send Frame

A frame can be sent from the interface when at least 8 bytes of preamble have been transmit-

ted, TXRDY, RQRDY and RQSEND are asserted, and RQFINAL has not yet been asserted for

this request.

Service Opportunity

A Service Opportunity occurs when it is possible to service the current request, as defined by

the current service parameters (RQRCLS, RQCLM and RQBCN). The rules for servicing re-

quests are described in Section 5.2.

Continue Service Opportunity A Service Opportunity is continued after the current frame if valid service parameters continue

to be presented during the frame, and the timer(s) used for the (next) requested service class

have not reached their threshold.

End of Service Opportunity

The end of a Service Opportunity occurs when it is no longer necessary or possible to continue

the Service Opportunity. The service parameters are continuously compared with the current

state of the Transmitter. If an unserviceable request is presented or any timer threshold is

reached, the Service Opportunity will not continue after the current frame (if any).

Table 7-4 shows the timer thresholds used to determine if a Service Opportunity is possible for each service class.

TABLE 7-4. Thresholds Used to Determine Service Opportunities

Request Service Class

All Requests

Threshold

TRT Expiration

All Requests with THT Enabled

Priority Asynchronous Requests

THT Expiration

Asynchronous Priority Threshold

95

7.0 Signal Descriptions (Continued)

State Descriptions

The send window is held open until

MR0: Not Ready

1) RQSEND or RQFINAL is asserted or

In this state the Ring Engine does not have a Service Op-

portunity. If RQRCLS is not zero, the Ring Engine is trying to

secure a Service Opportunity meeting the requested service

parameters.

2) until L Max has expired (3.20 ms), a Void frame has

been sent (0.96 ms or 1.60 ms), and 7 more bytes of

preamble have been sent (0.56 ms). (When Op-

Ð

e

tion.IRPT

1 this condition does not apply.)

On a valid Service Opportunity, the MR(01) transition is tak-

en. The status signals TXED and TXABORT are cleared and

TXRDY is set to indicate that the Transmitter is ready to

service a request.

At any time after RQRDY has been asserted and the final

frame of the request has been sent, RQFINAL may be as-

serted to indicate that a token of the Issue Token Class

should be transmitted at the end of the current Service Op-

portunity. If the MR(10) transition occurs while RQFINAL is

asserted, and all the other conditions for accepting RQFI-

NAL hold, the transmitted token will be of the Issue Token

Class.

MR1: Ready

In this state the Ring Engine has secured a Service Oppor-

tunity and is ready to service the current request. The Trans-

mitter is sourcing Preamble, Fill or internally generated Void

(from the Data state), Claim (from the Claim state) or Bea-

con (from the Beacon state) frames.

After RQFINAL has been asserted, no more frames can be

sent until RQRDY has been deasserted and then reassert-

ed. RQRDY should be deasserted and the service parame-

ters updated to reflect the next request (if any) as soon as

possible, to allow the Ring Engine to make better ring

scheduling decisions. If RQRDY is not deasserted by the

end of the last frame of a Service Opportunity, a Void frame

will be transmitted before the token.

The Service Opportunity is governed by the requested serv-

ice parameters. If an unserviceable request is presented for

one or more cycles the Service Opportunity ends. If THT

expires or a priority threshold is reached, the Service Oppor-

tunity will end immediately or after the next frame, depend-

ing on the state of the send window.

When the Service Opportunity ends, the MR(10) transition is

taken and TXPASS is asserted to indicate the end of the

current Service Opportunity. RQFINAL (and RQRDY) must

be asserted not later than one byte time after TXPASS to

insure that a token of the appropriate issue class is issued.

The send window is an opportunity to send a frame without

being interrupted by time thresholds. The Service Opportu-

nity may end during a send window if the service parame-

ters change.

The send window opens each time TXRDY is asserted (en-

try to MR1). It remains open for a minimum of 6 byte times.

The send window also opens if RQRDY is asserted while

TXRDY is asserted, and if TXPASS is not asserted within

one byte time after RQRDY is asserted.

When a frame can be sent from the interface, the MR(12)

transition is taken and TXACK is set to indicate that the

Transmitter is sending the frame.

The state diagram for the internal substates within state

MR1 is shown in Figure 7-12.

TL/F/10387–19

FIGURE 7-12. MR1 Substate Diagram

96

7.0 Signal Descriptions (Continued)

SUBSTATE MRR0: Preamble

On entry to MR2 TXACK is asserted. It remains asserted

while data is being accepted from the interface. RQSEND

must be deasserted within one byte time after entering

MR2.

Upon entry to MR1, 8 bytes of Preamble (Idles) are transmit-

ted in substate MRR0.

After the Preamble, if a frame can be sent from the inter-

face, transition MR12 occurs. The frame options are

latched, TXED is cleared and TXACK is asserted.

At any time after RQSEND is deasserted for the final frame

of a request, RQFINAL may be asserted to indicate that a

token of the Issue Token Class should be transmitted at the

end of the current Service Opportunity. If the MR(20) tran-

sition occurs while RQFINAL is asserted, and all the other

conditions for accepting RQFINAL hold, the transmitted to-

ken will be the issue token class.

If a frame cannot be sent from the interface, either Fill (addi-

tional Idles) or an internally generated frame (Void, Claim, or

Beacon) is transmitted.

SUBSTATE MRR1: Fill

For requests, if RQRDY is asserted (indicating that the cur-

rent request has been selected for service) or Option.IRPT

is set (indicating that the ring is being interrupted), additional

fill bytes (Idles) are transmitted in substate MRR1.

After RQFINAL has been asserted, no more frames can be

sent until RQRDY has been deasserted and then reassert-

ed. RQRDY should be deasserted and the service parame-

ters updated to reflect the next requests (if any) as soon as

possible, to allow the Ring Engine to make better ring

scheduling decisions.

Fill continues until:

1) a frame can be sent from the interface, or

2) the Service Opportunity ends, or

The last byte of data at the interface is indicated by RQEOF,

which must be asserted with the last byte of data. After the

Ending Delimiter of a frame is transmitted, TXED is assert-

ed. When not using FCS transparency, TXED is asserted 7

byte times after RQEOF is asserted. When using FCS trans-

parency, it is asserted 3 byte times after RQEOF is assert-

ed. TXACK is deasserted no later than one byte time after

RQEOF is asserted.

3) 32 bytes of Idles are transmitted or RQRDY is deas-

serted. After that, an internal Void frame is generated

in substate MRR2. (If Option.IRPT is set Void frames

are not generated.)

If RQRDY is not asserted, if RQCLM or RQBCN is asserted,

or (unless Option.IRPT is set) if the previous frame in the

current Service Opportunity was aborted, an internal Void,

Claim or Beacon frame is generated in substate MRR2.

At any time during frame transmission, TXABORT may be

asserted. This indicates that the frame was aborted due to

internal errors, buffering errors, parity errors, RQABT, MAC

reset, reception of a MAC frame etc. TXACK is deasserted

no later than TXABORT is asserted. When a transmission is

aborted due to an error (and Option.IRPT is not set), a Void

frame is transmitted to reset the TVX timers in all stations in

the ring.

At the end of an internal frame, TXED is set, TXABORT is

cleared and another preamble is generated in substate

MRR0.

MR2: Sending

In this state the Ring Engine is transmitting a frame from the

MAC Request Interface. While the frame is being sent, if an

unserviceable request is presented or any timer threshold is

reached, the Service Opportunity will end after the current

frame.

After a successful or unsuccessful frame transmission, if the

current Service Opportunity can be continued transition

MR(21) occurs and TXRDY is asserted; otherwise transition

MR(20) occurs and TXPASS is asserted.

This implies that a Service Opportunity is never longer than

TMAX plus one maximum length frame interval for Immedi-

ate Requests (unless Option.IRPT is set), or TNEG plus one

maximum length frame interval for Non-immediate Re-

quests. The maximum length of the frame interval is the

maximum send window open time (4.64 ms–5.28 ms) plus

If at any time during a frame transmission, the end of Serv-

ice Opportunity condition is detected, transition MR(20) will

occur after the current frame transition.

F

ing 2 bytes of Preamble. The default value of F max for

max. F max is the maximum length of a frame, includ-

Ð

e

FDDI is 4500 bytes

360.00 ms.

97

7.0 Signal Descriptions (Continued)

7.4.3.3 Transmission Status

an over-allocation of synchronous bandwidth or a station

used more than it was allocated. The ring will likely be claim-

ing when this occurs.

Upon leaving MR2, transmission status is available after

TXRDY or TXPASS is asserted. TXED and TXABORT are

normally valid for at least 9 byte times (exception: 2 byte

times when an Immediate Service Opportunity ends without

issuing a token, and another Service Opportunity begins im-

mediately upon return to state MR0). THTDIS is valid for at

least 2 byte times. When TXPASS is deasserted and for at

least two byte times after is reasserted, TXCLASS denotes

the token that will be issued at the end of the current Serv-

ice Opportunity.

7.4.4 Timing Examples

Several example sequences of the MAC Request Interface

are provided. While this in no way is an exhaustive list of

sequences, several likely sequences are shown. It is useful

to follow the state diagrams of Section 7.4.3 (Figures 7-11

and 7-12 ) while examining the scenarios.

The timing is shown for all signals available at the MAC

Interface.

TXED indicates that the Ending Delimiter of the previous

PDU was transmitted. TXABORT indicates that the previous

frame was aborted as a result of a request abort (RQABT),

an internal error or the Reset or Recovery Required condi-

tions became true.

The data shown in MRD and PRD are the data at those

interfaces.

The data at PRD is duplicated with the TXED to show its

relationship with the transmitted Ending Delimiter.

If TXED is asserted, TXABORT may also be asserted (within

9 byte clocks) if this station backed off to another station

after a complete Claim frame was transmitted.

TXPASS and TXRDY show the relationship to the data at

the transmitter. This is one byte time before the data is

transmitted. The relationship to incoming tokens is shown

explicitly.

When transmitting Claim/Beacon frames from the Transmit-

ter Claim or Beacon, if TXPASS is asserted the Claim or

Beacon Process has completed. In this case, TXABORT

RQRCLS contains the Requested service class. In several

examples this is shown as generic requests (r1, r2) to make

the examples more general purpose. The RQCLM and

RQBCN signals are not shown, but have the same timing as

the RQRCLS signals.

e

1) the Claim or Beacon process.

indicates if this station won (TXABORT

e

0) or lost

(TXABORT

The interpretation of TXED and TXABORT is given in Table

7-5.

The Frame Options are grouped together since they have

the same timing. These include the SAT, SAIGT, FCST and

STRIP options.

TABLE 7-5. Transmission Status

TXED TXABORT

Condition

Single Frame Transmission with Prestaging

0

After a Master Reset or frame

aborted during successful

immediate Claim or Beacon

Prestaging refers to the staging of data before the Service

Opportunity begins. Prestaging occurs in interfaces where

data is loaded into a FIFO or dedicated memory used as a

FIFO before the token arrives.

service due to My Claim or

Ð

My Beacon.

Ð

In Figure 7-13 RQRDY is asserted one byte time after

RQRCLS has been passed to the interface. At this point the

Ring Engine is awaiting an appropriate Service Opportunity.

Upon capture of a usable token, TXRDY is asserted.

TXRDY causes RQSEND to be asserted.

1

0

1

0

1

Complete frame transmitted.

Frame aborted.

Complete frame transmitted,

followed by reset or recovery

actions or unsuccessful immediate

Claim or Beacon service due to

timeout.

RQSEND causes TXRDY to be deasserted, which in turn

causes RQSEND to be deasserted.

Notice that after RQSEND is deasserted, RQFINAL is as-

serted for one cycle to indicate that the issue token class

should be used for the token. RQRDY is then deasserted

and RQRCLS is set to zero. Since RQRCLS goes to zero,

the end of Service Opportunity condition becomes true and

the token is issued at the end of the current frame.

If TXPASS is asserted and THT was disabled during the last

frame that was transmitted (THTDIS is asserted), TRT has

expired. This is a serious error and indicates that there was

98

7.0 Signal Descriptions (Continued)

99

7.0 Signal Descriptions (Continued)

If RQRCLS remained asserted the token would be held as

In Figure 7-16 the MAC Reset occurs while the Ending Del-

imiter is being transmitted. InFigure 7-17 the boundary case

is shown where the MAC Reset occurs during the Frame

Status. Note that the Ending Delimiter of the frame is trans-

mitted with the frame status. TXRDY is asserted for one

cycle followed by TXPASS with TXABORT.

In this case the TXRDY

x

u u v

RQSEND handshake for the beginning of each

RQSEND

^{long as possible and multiple frames could}x^{be trans}T^mXⁱR^tteD^dY^.

x

v

frame remains identical.

Single Frame Transmission without Prestaging

Synchronous Request followed by Asynchronous

Request

In Figure 7-14, prestaging is not used. Multiple requests are

present at the interface, of which only the highest priority

request is presented to the interface. RQRCLS is changing

because higher priority requests become ready to be serv-

iced. The scheduling decision is made until a Service Op-

portunity occurs. Once TXRDY is asserted, RQRDY is as-

serted and the r6 request is serviced.

In Figure 7-18, frames from two requests are serviced on

the same Service Opportunity. Once the synchronous frame

is being transmitted, the RQRCLS is changed to that for the

asynchronous frame. At the end of the synchronous frame

TXRDY is asserted since the token is still usable for the

asynchronous request. RQRDY is then asserted and the

Asynchronous frame is then transmitted.

When the data associated with r6 is ready to be transmitted,

RQSEND is asserted. This in turn causes TXRDY to be

deasserted when transmission begins (entrance to MR2).

The deassertion of TXRDY causes RQSEND to be deas-

serted.

Notice that the value of THTDIS changes after the Frame

Status for the synchronous frame is transmitted. THT is dis-

abled for synchronous transmission and enabled for normal

asynchronous transmission.

During the first frame of the request, the end of Service

Opportunity condition becomes true as a result of:

Restricted Begin

THT reaching the THT priority threshold if the request

was an asynchronous priority request,

THT expiration if the request was an asynchronous re-

quest or

TRT expiration if the request was a synchronous request.

In Figure 7-19, a restricted dialogue is begun. A non-restrict-

ed Token is captured, a single frame is transmitted and a

Restricted Token is issued.

An Rbeg Request is a request to capture a Non-restricted

Token and issue a Restricted Token. Since there is only one

frame in this example, RQFINAL is asserted during the first

frame. In the example, RQFINAL is asserted one byte time

after RQSEND is deasserted while RQRDY is still asserted,

but it may be asserted anytime while RQRDY is asserted.

Notice that TXCLASS changes to restricted after RQFINAL

is asserted.

TXPASS is asserted to indicate that this Service Opportunity

is complete.

If RQRCLS remains greater than 0, the next usable token

will be captured and servicing of the request will continue. If

RQRCLS remained asserted the token would be held as

long as possible and multiple frames could be transmitted.

In

case

v

the

TXRDY

x

RQSEND

x

TXR^thD^isYx RQSEND handshake for the beginning of

u

Immediate Claim

v

In Figure 7-20, an immediate Claim frame is transmitted

from the Claim state.

each frame remains identical.

Aborted Frame Transmission

A Lower Claim frame is received from an upstream station,

Ð

A transmission as in Figure 7-14 is started. During the trans-

mission, an interface error occurs (for example) and RQABT

is asserted to cause the current frame to be aborted (see

Figure 7-15 ). TXACK is then deasserted and TXABORT is

asserted to indicate that the frame was aborted as a result

of a FIFO underrun or an equivalent reason. This is signaled

with RQABT. After the frame is aborted, TXRDY is asserted

to indicate that another frame may be transmitted. Since no

frames are ready to be transmitted a Void fill frame is trans-

mitted. During the Void frame transmission, the interface

then sets RQRCLS to zero to indicate that the Token should

be issued. TXPASS is then asserted once the Ending Delim-

iter of the Void frame is transmitted.

causing this station to enter its Claim state and deassert

TXRINGOP.RQRCLS is set to immediate and RQCLM is as-

serted.

An internally generated Claim frame is first transmitted (at

least one internally generated Claim or Beacon frame is al-

ways transmitted upon entry to the Claim or Beacon state).

After the internally generated Claim frame is transmitted,

TXRDY is asserted since the transmitter is still in the Claim

state (the ring can hold more than one Claim frame). The

frame is then transmitted following the normal handshake.

Similar timing applies for externally generated Beacon

frames.

Remember that for Immediate Requests from the Claim and

Beacon States, RQSEND must be asserted no later than

8 byte times after TXRDY is asserted. This guarantees that

a minimum size preamble will be generated.

In this scenario the transmitted Void frame serves two pur-

poses. It is transmitted because the interface was stalling

waiting for another frame and also in response to the abort-

ed frame. A Void frame is transmitted every time a transmis-

sion is aborted.

After the frame is transmitted, TXRDY is asserted again

since the transmitter is still in the Claim state.

MAC Reset

If this station wins the Claim Process TXPASS is asserted

without TXABORT. If another station causes this station to

backoff (this station receives a Higher Claim), TXPASS is

In Figure 7-16, a MAC reset occurs during a frame transmis-

sion. This causes the current frame to be aborted and the

Ring Operational Flag (TXRINGOP) to be deasserted.

TXPASS is asserted with TXABORT after the frame is abort-

ed. Since the ring is not operational, no Void frames are

transmitted.

Ð

asserted with TXABORT.

100

7.0 Signal Descriptions (Continued)

101

7.0 Signal Descriptions (Continued)

102

7.0 Signal Descriptions (Continued)

TL/F/10387–23

FIGURE 7-16. MAC Reset

103

7.0 Signal Descriptions (Continued)

TL/F/10387–24

FIGURE 7-17. MAC Reset at End of Frame

104

7.0 Signal Descriptions (Continued)

105

7.0 Signal Descriptions (Continued)

106

7.0 Signal Descriptions (Continued)

107

7.0 Signal Descriptions (Continued)

7.5 ELECTRICAL INTERFACE

The Electrical Interface signals comprise all of the clocking, power supply, and ground pins.

Ý

Symbol

LSC

87

I/O

Description

I

Local Symbol Clock: 25 MHz clock with a 40/60 duty-cycle. Typically generated by the CDD.

LBC

86

Local Byte Clock: 12.5 MHz clock 50/50 duty-cycle in phase with LSC. Typically generated by the

CDD.

RST

118

I

Master Reset: Equivalent to setting the Master Reset bit in the Function Register. An asynchronous

input that must be asserted for at least 5 LSC clock cycles. When asserted, all bi-directional signals

are tri-stated. Active low signal.

g

Positive Power Supply: 5V, 5% relative to GND.

V

[

CC 11

4, 17, 34

58, 78

]

94, 100

106, 117

[

GND 11

]

5, 18, 33

57, 77,

88–91,

101,

I

Power Supply Return

116, 128

7.6 PINOUT SUMMARY

TABLE 7-6. Pinout Summary

Signal Name

Ý

1

Symbol

CBD1

I/O

Control Bus Data 1

Control Bus Data 2

Control Bus Data 3

Positive Power Supply

Ground

I/O

2

CBD2

I/O

3

CBD3

I/O

4

V

CC

I

5

GND

I

6

Control Bus Data 4

Control Bus Data 5

Control Bus Data 6

Control Bus Data 7

Control Bus Parity

CBD4

CBD5

CBD6

CBD7

CBP

I/O

7

I/O

8

I/O

9

I/O

10

11

12

13

14

15

16

17

18

19

I/O

Source Address I/G Transparency

Source Address Transparency

Void Strip

SAIGT

SAT

I

STRIP

FCST

RQCLM

RQBCN

Frame Check Sequence Transparency

Request Claim

Request Beacon

Positive Power Supply

Ground

V

CC

GND

Request Class 3

RQRCLS3

108

7.0 Signal Descriptions (Continued)

7.6 PINOUT SUMMARY (Continued)

TABLE 7-6. Pinout Summary (Continued)

Signal Name

Request Class 2

Ý

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

Symbol

RQRCLS2

RQRCLS1

RQRCLS0

RQRDY

RQSEND

RQEOF

RQFINAL

RQABT

I/O

I

Request Class 1

Request Class 0

Request Ready

I

Request Send

I

Request End of Frame

Request Final

I

Request Abort

I

Transmit Pass

TXPASS

TXRDY

O

I

Transmit Ready

Transmit Acknowledge

Transmit Ending Delimiter

Transmit Abort

TXACK

TXED

TXABORT

GND

Ground

Positive Power Supply

Token Class

V

CC

I

TXCLASS

THTDIS

TXRINGOP

EA

O

I

Token Holding Timer Disabled

Ring Operational

External A Flag

Ð

External M Flag

Ð

EM

I

Positive Power Supply

MAC Request Parity

MAC Request Data 7

MAC Request Data 6

MAC Request Data 5

MAC Request Data 4

MAC Request Data 3

MAC Request Data 2

MAC Request Data 1

MAC Request Data 0

Ground

V

CC

I

MRP

I

MRD7

MRD6

MRD5

MRD4

MRD3

MRD2

MRD1

MRD0

GND

I

Receive Start

RCSTART

FCRCVD

FCSL

O

I

Frame Control Recevied

Short/Long Address Flag

Individual/Group Address Flag

Destination Address Received

My Destination Address Recognized

Ground

DAIG

DARCVD

AFLAG

GND

Positive Power Supply

Source Address Received

V

CC

I

SARCVD

O

109

7.0 Signal Descriptions (Continued)

7.6 PINOUT SUMMARY (Continued)

TABLE 7-6. Pinout Summary (Continued)

Ý

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

Signal Name

My Source Address Recognized

Same Source Address

Information Field Received

Same MAC Information

Ground

Symbol

MFLAG

I/O

O

I

SAMESA

INFORCVD

SAMEINFO

GND

Positive Power Supply

Ending Delimiter Received

Valid Frame Check Sequence

Valid Data Length

Token Received

V

CC

I

EDRCVD

VFCS

O

I

VDL

TKRCVD

FOERROR

FRSTRP

MCRST

MIP

Format Error

Frame Stripped

Media Access Control Reset

MAC Indicate Parity

MAC Indicate Data 7

MAC Indicate Data 6

MAC Indicate Data 5

Ground

MID7

MID6

MID5

GND

Positive Power Supply

MAC Indicate Data 4

MAC Indicate Data 3

MAC Indicate Data 2

MAC Indicate Data 1

MAC Indicate Data 0

Ground

V

CC

I

MID4

MID3

MID2

MID1

MID0

GND

VCOPY

LBC

O

I

Valid Copy

I

Local Byte Clock

I

Local Symbol Clock

Ground

LSC

I

GND

PRD0

PID0

I

Ground

I

Ground

I

Ground

I

PHY Request Data 0

PHY Indicate Data 0

Positive Power Supply

PHY Request Data 1

PHY Indicate Data 1

PHY Request Data 2

PHY Indicate Data 2

PHY Request Data 3

O

I

V

CC

I

PRD1

PID1

O

I

PRD2

PID2

O

I

PRD3

O

110

7.0 Signal Descriptions (Continued)

7.6 PINOUT SUMMARY (Continued)

TABLE 7-6. Pinout Summary (Continued)

Ý

Signal Name

Positive Power Supply

Ground

Symbol

I/O

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

V

CC

I

GND

PID3

PRD4

PID4

PRD5

I

PHY Indicate Data 3

PHY Request Data 4

PHY Indicate Data 4

PHY Request Data 5

Positive Power Supply

PHY Indicate Data 5

PHY Request Data 6

PHY Indicate Data 6

PHY Request Data 7

PHY Indicate Data 7

PHY Request Control

PHY Indicate Control

PHY Request Parity

PHY Indicate Parity

Ground

I

O

I

O

V

CC

I

PID5

PRD6

PID6

PRD7

PID7

PRC

PIC

I

O

I

O

I

O

I

PRP

PIP

O

I

GND

I

Positive Power Supply

Master Reset

V

CC

I

RST

I

E

Read/ Write

R/W

CE

I

E

Control Bus Enable

I

E

Interrupt

INT

O

E

Acknowledge

ACK

O

Control Bus Address 0

Control Bus Address 1

Control Bus Address 2

Control Bus Address 3

Control Bus Address 4

Ground

CBA0

CBA1

CBA2

CBA3

CBA4

GND

CBA5

CBA6

CBA7

CBD0

I

Control Bus Address 5

Control Bus Address 6

Control Bus Address 7

Control Bus Data 0

I

I/O

111

7.0 Signal Descriptions (Continued)

7.7 PINOUT DIAGRAM

TL/F/10387–11

FIGURE 7-21. DP83261 132-Pin PQFP Pinout

Order Number DP83261AVF

See NS Package Number VF132A

112

8.0 Electrical Characteristics

8.1 ABSOLUTE MAXIMUM RATINGS

If Military/Aerospace specified devices are required, please contact the National Semiconductor Sales Office/

Distributors for availability and specifications.

Symbol

Parameter

Supply Voltage

Conditions

Min

Max

7.0

a

Units

b

V

T

0.5

V

CC

b

DC Input Voltage

V

0.5

IN

CC

a

DC Output Voltage

OUT

CC

b

a

Storage Temperature Range

Lead Temperature

65

150

C

§

STG

L

T

Soldering, 10 sec.

230

C

§

(IR or Vapor) (Phase Reflow)

e

ESD Rating

R

C

1.5k,

ZAP

800

V

120 pF

ZAP

8.2 RECOMMENDED OPERATING CONDITIONS

Symbol

Parameter

Supply Voltage

Power Dissipation

Operating Temp

Conditions

Min

Max

5.25

400

70

Units

V

CC

4.75

V

PD

T

mW

0

C

§

8.3 DC ELECTRICAL CHARACTERISTICS

Symbol

Parameter

Conditions

Min

Max

Units

e

50 pF

V

OH1

V

OH2

V

OL1

V

OL2

V

OL3

Minimum High Level

Output Voltage

C

L

b

V

CC

0.5

V

e b

2 mA

Minimum High Level

Output Voltage

I

OH

2.4

e

Maximum Low Level

Output Voltage

C

L

50 pF

4 mA

8 mA

0.4

e

Maximum Low Level

Output Voltage

I

OL

e

Maximum Low Level

Output Voltage INT

and ACK (Open Drain)

0.4

V

Minimum High Level

Input Voltage

IH

2.0

V

Maximum Low Level

Input Voltage

IL

0.8

a

b

I

Input High Current

Input Low Current

10

mA

IH

IL

TRI-STATE Leakage for

CBD(7–0) and CBP

OZ1

g

10

mA

I

TRI-STATE Leakage for

OZ2

OZ3

mA

INT and ACK (Open Drain)

e

Dynamic Supply Current

C

L

50 pF, 12.5 MHZ

70m

mA

113

8.0 Electrical Characteristics (Continued)

8.4 AC ELECTRICAL CHARACTERISTICS

See Figures 8-8 and 8-9 for AC Signal and TRI-STATE Testing Criteria.

8.4.1 Control Bus Interface

Symbol

T1

Parameter

CE Setup to LBC

Min

15

Max

Units

ns

T2

LBC Period

80

ns

T3

LBC to ACK Low

45

540

60

ns

T4

CE Low to ACK Low

290

ns

T5

LBC Low to CBD(7–0) and CBP Valid

LBC to CBD(7–0) and CBP Active

CE Low to CBD(7–0) and CBP Active

CE Low to CBD(7–0) and CBP Valid

LBC Pulse Width High

ns

T6

60

ns

T7

225

265

35

475

515

45

ns

T8

ns

T9

ns

T10

T11

T12

LBC Pulse Width Low

35

45

ns

CE High to ACK High

45

ns

R/W, CBA(7–0), CBD(7–0) and

CBP Set up to CE Low

5

0

ns

T13

T14

CE High to R/W, CBA(7–0),

CBD(7–0) and CBP Hold Time

R/W, CBA (7–0), CBD(7–0)

and CBP Setup to LBC

20

T15

T16

T17

T18

T19

T20

ACK Low to CE High Lead Time

CE Minimum Pulse Width High

CE High to CBD(7–0) and CBP TRI-STATE

ACK High to CE Low

0

ns

20

55

0

CBD(7–0) Valid to ACK Low Setup

LBC to INT Low

20

Asynchronous Definitions

a

T4 (min)

T4 (max)

T7 (min)

T7 (max)

T8 (min)

T8 (max)

T1

(3 * T2)

(6 * T2)

(2 * T2)

(5 * T2)

(2 * T2)

(5 * T2)

T3

T6

T9

T1

a

T5

e

T10 40 ns.

Note: Min/Max numbers are based on T2

80 ns and T9

114

8.0 Electrical Characteristics (Continued)

TL/F/10387–28

FIGURE 8-1. Control Bus Interface Write Cycle

TL/F/10387–29

FIGURE 8-2. Control Bus Interface Read Cycle

115

8.0 Electrical Characteristics (Continued)

TL/F/10387–30

FIGURE 8-3. Control Bus Interface Synchronous Write Cycle

TL/F/10387–31

FIGURE 8-4. Control Bus Interface Synchronous Read Cycle

116

8.0 Electrical Characteristics (Continued)

8.4.2 Clock Signals

Symbol

T21

Parameter

LSC to LBC Lead Time (Skew Left)

LSC Pulse Width High

Min

Max

Units

ns

b

4

6

T22

12

21

35

ns

T23

LSC Pulse Width Low

ns

T24

LBC Pulse Width High

LBC Pulse Width Low

45

ns

T25

ns

TL/F/10387–32

FIGURE 8-5. Clock Signals

8.4.3 PHY Interface

Symbol

T26

Parameter

Min

15

5

Max

Units

ns

PHY Data Input Setup

PHY Data Input Hold

PHY Data Sustain

PHY Data Valid

T27

ns

T28

10

ns

T29

45

ns

TL/F/10387–33

Note: All setup and hold testing is done on single edges only (i.e., no combined setup/hold testing is done for pulse signals. This implies that the signal makes only

one low to high or high to low transition per cycle).

FIGURE 8-6. PHY Interface Timing

117

8.0 Electrical Characteristics (Continued)

8.4.4 MAC Interface

Pin Groups

Ý

Group

I/O

Pins

1

2

3

4

5

6

I

SAIGT, SAT, STRIP, EA, VCOPY, RQEOF, RQSEND, RQFINAL

RQRDY

I

FCST, RQBCN, RQCLS(3–0), EM, RQABT

I

RQCLM

I

MRD(7–0), MRP

O

TXPASS, TXED, TXABORT, RCSTART, FCRCVD, SAMESA, INFORCVD, SAMEINFO, TXRDY, TXACK,

TXCLASS, THTDIS, TXRINGOP, DIAG, DARCVD, AFLAG, SARCVD, MFLAG, EDRCVD, VFCS, VDL, TKRCVD,

FOERROR, FRSTRIP, MACRST

7

O

MID(7–0), MIP

Symbol

T30

T31

T32

T33

T34

T35

T36

T37

T38

T39

Parameter

Min

15

30

2

Max

Units

ns

Ý

MAC Control Setup (Groups 1 and 3 and 4)

Ý

MAC Control Setup (Group 2)

ns

Ý

MAC Control Hold (Group 3)

ns

Ý

MAC Control Hold (Groups 1 and 2 and 4)

5

ns

Ý

MAC Data Setup (Group 5)

15

6

ns

Ý

MAC Data Hold (Group 5)

ns

Ý

MAC Control Sustain (Group 6)

15

ns

Ý

MAC Control Valid (Group 6)

45

ns

Ý

MAC Data Sustain (Group 7)

15

ns

Ý

MAC Data Valid (Group 7)

ns

TL/F/10387–34

Note: All setup and hold testing is done on single edges only (i.e., no combined setup/hold testing is done for pulse signals. This implies that the signal makes a

single low to high or high to low transition per cycle).

FIGURE 8-7. MAC Interface Timings

118

8.0 Electrical Characteristics (Continued)

Test Conditions for AC Testing

V

3.0V

IH

0.0V

IL

1.5V

OH

OL

1.5V

I

8.0 mA (ACK, INT)

50 pF

OL

C

L

AC Signal Testing

TL/F/10387–35

Note: All setup and hold testing is done on single edges only (i.e., no combined setup/hold testing is done for pulse signals. This implies that the signal makes only

one single low to high or high to low transition per cycle).

FIGURE 8-8. A.C. Signal Testing

TRI-STATE Timing

TL/F/10387–36

FIGURE 8-9. TRI-STATE Timing

119

8.0 Electrical Characteristics (Continued)

Test Equivalent Loads

V

Testing

V

OH2

Testing

OL2

TL/F/10387–38

TL/F/10387–37

Tlo-tri

Thi-tri

TL/F/10387–40

TL/F/10387–39

Open Drain V Testing

OL

AC, V , V Testing

OL1 OH1

TL/F/10387–42

TL/F/10387–41

FIGURE 8-10. Test Equivalent Loads

120

Appendix A. Ring Engine State Machines

A.1 RECEIVER

A.1.1 MAC Receiver State Diagram

TL/F/10387–43

FIGURE A-1. Ring Engine Receiver State Diagram

121

Appendix A. Ring Engine State Machines (Continued)

A.1.2 MAC RECEIVER FOOTNOTES

A1.2.1 Internal Conditions

(1) ESA:

Option.Enable Short Address

(2) ELA:

Option.Enable Long Address

(3) IRR:

Option.Inhibit Recovery Required (nESA & nELA)

l

(4) IFCS:

Option.Implementer FCS

(5) EMIND:

Option.External Matching Indicators

(6) MAC Reset:

Ð

Function.MAC Reset nMode.Run

l

A.1.2.2 Transition Conditions

(1) PH Invalid:

Ð

See encoding of PH Invalid in Section 7.2.1.1

(2) PH Indication (S1 S2):

Ð

S1 is the first symbol received, S2 is the second symbol received. See encoding of

PH Indication in Section 7.2.1.1

(3) Transition R(12):

This Transition may be a 0 time transition from any state except R0:Listen

A.1.2.3 Actions

1. DA Actions:

Ð

IF FC.L 4 0 CLEAR FCSL ;short address

ELSE SET FCSL ;long address

After DA0r

IF DA.IG 4 0 CLEAR DAIG ;individual address

ELSE SET DAIG ;group address

IF FCSL 4 0 ;short address

After DA1r

SIGNAL DARCVD

e

THEN IF DAr is contained in set of Group Addresses

IF DAIG

1

THEN SET A Flag

IF DAIG 4 0

THEN IF DAr 4 MSA

THEN SET A Flag

IF FCSL 4 1 ;long address

After DA5r

SIGNAL DARCVD

IF DAIG 4 1

THEN IF DAr is contained in set of Group Addresses

THEN SET A Flag

IF DAIG 4 0

THEN IF DAr 4 MLA

THEN SET A Flag

NOTE: A Flag may be set on reception of VOID frames.

122

Appendix A. Ring Engine State Machines (Continued)

2. SA Actions:

Ð

IF FCSL 4 0; short address

After SA1r

SIGNAL SARCVD

IF ESA

THEN IF SAr 4 MSA

THEN SET MFLAG, Signal FR Strip

l

SET HFLAG

ELSE IF SAr

MSA THEN

ELSE SET LFLAG

IF ((SAr 4 previous SAr) & (previous FCSL 4 0) &

(FC.FF 4 nMAC & previous FC.FF 4 nMAC) THEN

SIGNAL SAMESA

IF FCSL 4 1; long address

After SA5r

SIGNAL SARCVD

IF ELA

THEN IF SAr 4 MLA

THEN SET MFlag, Signal FR Strip

l

ELSE IF SAr

MLA

THEN SET H Flag

ELSE SET L Flag

IF ((SAr 4 previous SAr) & (previous FCSL 4 1) &

(FC.FF 4 nMAC & previous FC.FF 4 nMAC)

THEN SIGNAL SAMESA

NOTE: A station with a null address may not win Claim when Option.IRR is set..

3. CT Actions:

Ð

After 4 Info Octets

If FCr 4 Claim

i

IF T Bid Rc

CLEAR MFLAG

TREQ

l

IF T Bid Rc

THEN IF L Flag

SET H Flag

CLEAR L Flag

ELSE IF H Flag

SET L Flag

CLEAR H Flag

IF L Flag

SIGNAL FR Strip

IF ((INFOr 4 previous INFO) & (FCSL 4 previous FCSL) &

(FC.FF 4 MAC & previous FC.FF 4 MAC)

THEN SIGNAL SAMEINFO

4. TK Received Actions:

Ð

IF Token Class 4 Restricted

THEN IF nR Flag

THEN SET R Flag

SET TELR.ENTRMD Entered Restricted Mode

ELSE RESET TVX

CLEAR R Flag

SIGNAL TK Received

À

Ó

À

Ó

INC TKCT token count

À

SET CILR.TKRCVD Token Received

Ó

123

Appendix A. Ring Engine State Machines (Continued)

5. ED Actions:

Ð

À

INC FRCT Frame Received Ct

SIGNAL FR Received, EDRDVD

Ó

SET CILR.FRRCV

If Valid Data Length & (Valid FCS Rc (FCr 4 Void)

(FCr 4 Implementer and n(Option.IFCS))

THEN RESET TVX;

l

IF (A Flag (EA & Option.EMIND)) & VCOPY

l

THEN SET C Flag

À

Ó

ELSE SET E Flag This E Flag is used during rest of the ED Actions

CLEAR A Flag, M Flag, H Flag, L Flag

i

IF Er

S & E Flag

THEN INC EICT Error Ct

À

Ó

SET CILR.FREI Frame Error Isolated

À

Ó

IF Er 4 R & nE Flag

THEN

IF FCr 4 Claim

THEN SET RELR.CLM

IF A Flag & M Flag

THEN SIGNAL My Claim

SET RELR.MYCLM

CLEAR R Flag

SET TNEG 4 T Bid Rc

IF H Flag

THEN SIGNAL Higher Claim

SET RELR.HICLM

CLEAR R Flag

SET TNEG 4 T Bid Rc

IF L Flag

THEN SIGNAL Lower Claim

SET RELR.LOCLM

CLEAR R Flag

IF FCr 4 Beacon

THEN SET RELR.BCN

IF M Flag

THEN SIGNAL My Beacon

SET RELR.MYBCN

CLEAR R Flag

IF n(M Flag E Flag)

l

THEN SIGNAL Other Beacon

SET RELR.OTRBCN

CLEAR R Flag

IF FCr 4 Other MAC

THEN SIGNAL Other MAC

SET RELR.OTRMAC

IF FCr 4 VOID

THEN

IF M Flag & A Flag & nDAIG

SIGNAL My Void

ELSE IF nA Flag

SIGNAL Void

ELSE IF nM Flag

SIGNAL Other Void

124

Appendix A. Ring Engine State Machines (Continued)

6. Ar Actions:

Ð

After Ar

IF Ar 4 R

THEN CLEAR N Flag

IF A Flag & Ar 4 S & DA.IG 4 0 & nE Flag

À

Ó

THEN SET RELR.DUPADD Duplicate Address Strip Error detected

l

i

IF REV1 & nE Flag & (A Flag (EA & EMIND)) & FCr

(MAC Void)

l

i

IF (VCOPY & FCr

NSA) (VCOPY & FCr 4 NSA & Ar 4 R)

l

THEN SET CILR.FRCOP

À

Ó

INC FCCT Frame Copied Ct

ELSE IF nVCOPY (FCr 4 NSA & Ar 4 S)

l

SET CILR.FRNCOP

À

INC FNCT Frame Not Copied Ct

Ó

i

IF REV2 & nE Flag & (A Flag (EA & EMIND)) & FCr

NSA & Ar 4 S)

(MAC Void) & n(FCr 4

l

IF VCOPY

THEN SET CILR.FRCOP

À

Ó

INC FCCT Frame Copied Ct

ELSE SET CILR.FRNCOP

À

INC FNCT Frame Not Copied Ct

Ó

125

Appendix A. Ring Engine State Machines (Continued)

A.2 TRANSMITTER

A.2.1 MAC Transmitter State Diagram

TL/F/10387–44

FIGURE A-2. Ring Engine Transmitter State Diagram

126

Appendix A. Ring Engine State Machines (Continued)

A.2.2 MAC TRANSMITTER FOOTNOTES

A.2.2.1 Internal Conditions

(1) ESA:

Option.Enable Short Address

(2) ELA:

Option.Enable Long Address

(3) IRPT:

Option.Inhibit Repeat (nESA & nELA)

l

(4)ITC:

Option.Inhibit Token Capture

(5)IRR:

Option.Inhibit Recovery Required (nESA & nELA)

l

(6)ITR:

Option.Inhibit Token Release

(7) IFCS:

Option.Implementer FCS

(8) EMIND:

Option.External Matching Indicators

(9) MAC Reset:

Ð

Function.MAC Reset nMode.Run

l

(10) Beacon Request:

Function.Beacon Request & nMAC Reset

(11) Claim Request:

Ð

Function.Claim Request & nBeacon Request & nMAC Reset

A.2.2.2 Transition Conditions

(1) Usable Token:

Ð

Ring Operational & nRQ.Send &

e

((RQ.Class

(RQ.Class

n(RQ.Class

synchronous & nRELR.Beacon Received)

l

e

asynchronous & nLate & RQ.Class.Capture

FCr.L &

k

T Pri RQ.Class.Priority ) &

i

[

]

priority TRT

l

e

restricted &

(RELR.Beacon Received RELR.Claim Received

l

e

(RQ.Class.Capture

nonrestricted & nRbeginOK)))))

(2) Capture TK:

Ð

nITC & nIRPT & (Usable Token

l

(Ring Operational & nTELR.Ring Latency Valid & nLate & nFCr.L))

(3) Immediate Request:

e

RQ.Class

immediate & nRQ.Claim & nRQ.Beacon

(4) Usable Immediate:

Ð

e

nRing Operational & TX.Class

none &

n(TK Received & nIRPT) & nRQ.Send & Immediate Request

(5) Send Void:

Ð

TX.Abort

l

(After FSx &

((TX.Ready &

(nRQ.Ready ((Immediate Request Lmax expired) & nRQ.Send))

(TX.Pass &

l

(Void Strip (nTELR.Ring Latency Valid & Early)

l

n(TX.ED TX.Class 4 none))

l

127

Appendix A. Ring Engine State Machines (Continued)

(6) Another Void:

Ð

After FSx & TX.Pass & Void Strip & nVsent

(7) Reset Required:

Ð

MAC Reset

l

(nIRPT & (Higher Claim Other Beacon Other MAC))

l

i

(IRPT & (T3 (T0 & (Ring Operational TX.Class

none nLate))))

l

Note: Any other MAC frame received while RING Operational must be a My Claim or a bad frame. These frames are ignored here.

Ð Ð

(8) Recovery Required:

Ð

Claim Request

l

(nIRR &

(Lower Claim My Beacon TVX expires

l

(TRT expires & Late & n((T0 T1) & TK Received))))

l

Req) must be detected by software!

Ð

k

Note: (Ring Operational & T Opr

Ð Ð

T

A.2.2.3. Transition Actions

(1) Pass Actions:

Ð

CLEAR TX.Ready, Void Strip;

IF T1 THEN SET RbeginOK 4 nFCr.L;

SET TX.Class 4 FCr.L; SET TX.Pass, TELR.Token Passed;

If Ring Operational

THEN IF nLate

THEN RESET TRT 4 T Opr

ELSE CLEAR Late

ELSE SET T Opr 4 T Neg; RESET TRT 4 T Opr; SET Late;

SET RELR.Ring Operational Set, Ring Operational

(2) Capture Actions:

Ð

CLEAR TX.ED, TX.Abort, TX.Pass, Void Strip;

SET TX.Class 4 FCr.L; SET TX.Ready, TELR.Token Captured;

RESET Lmax;

IF nLate

THEN SET Early; SET THT 4 TRT; RESET TRT 4 T Opr

ELSE CLEAR Early, Late

(3) Immediate Actions:

Ð

CLEAR TX.ED, TX.Abort, TX.Pass, Void Strip;

SET TX.Class 4 none; SET TX.Ready;

SET Early; RESET TRT 4 T Opr; CLEAR Late

(4) Reset Actions:

Ð

IF T4 T5 (T2 & nTX.Ready & nTX.Pass & nTX.ED)

l

THEN SET TX.Abort

CLEAR TX.Ready, TX.Ack, Void Strip;

SET TX.Class 4 none; SET TX.Pass;

SET T Opr 4 T Max; RESET TRT 4 T Opr; SET Late;

IF Ring Operational

THEN SET RELR.Ring Operational Reset

IF MAC Reset Ring Operational

l

CLEAR Late Count, Ring Operational, Function.MAC Reset

128

Appendix A. Ring Engine State Machines (Continued)

(5) Recovery Actions:

Ð

IF T2 & nTX.Ready & nTX.Pass & nTX.ED

THEN SET TX.Abort

IF T5

THEN CLEAR TX.Abort

CLEAR TX.Ready, TX.Ack, Void Strip;

SET TX.Class 4 nonrestricted; SET TX.Pass;

SET T Opr 4 T Max; RESET TRT 4 T Opr; SET Late;

IF Ring Operational

THEN SET RELR.Ring Operational Reset;

CLEAR Late Count, Ring Operational

(6) Start Actions:

Ð

CLEAR TX.Ready, TX.Ack, TX.Abort; SET Void Strip, TX.Pass;

RESET TRT 4 T Opr

(7) Issue Actions:

Ð

IF nRing Operational

THEN SET T Opr 4 T Neg; RESET TRT 4 T Opr; SET Late

IF TX.Class 4 nonrestricted & nR Flag

THEN SET RbeginOK

ELSE CLEAR RbeginOK

A.2.2.4 State Actions

(1) TRT Actions:

Ð

Always:

IF TRT expires

THEN RESET TRT 4 T Opr;

IF n((T0 T1) & TK Received & nIRPT)

l

THEN IF nLate

THEN SET Late

ELSE SET TELR.TRT Expired;

IF nRing Operational

THEN INCREMENT Late Count

IF (T4 & n(My Claim & nITR & nIRPT))

l

(T5 & n(My Beacon & (Claim Request nIRR)))

l

THEN SET TELR.Recovery Failed

(2) RLCT Actions:

Ð

Always:

IF TELR.Ring Latency Valid MAC Reset (nESA & nELA)

l

(TRT expires & Late) PH Invalid

l

Lower Claim My Beacon Higher Claim

l

Other Beacon Other MAC TK Received Other Void

l

THEN DISABLE Latency Count

IF My Void & Latency Count enabled

THEN SET TELR.Ring Latency Valid

(3) TX Idle Actions (T0):

Ð

Always:

PH Data.request(II);

IF My Void Other Void

l

THEN CLEAR Void Strip

129

Appendix A. Ring Engine State Machines (Continued)

(4) Repeat Actions (T1):

Ð

IF nIRPT & (Higher Claim Other Beacon Other MAC) &

l

i

(Ring Operational TX.Class

none nLate)

l

THEN SET TX.Class 4 none;

SET T Opr 4 T Max; RESET TRT 4 T Opr; SET Late;

IF Ring Operational

THEN SET RELR.Ring Operational Reset;

CLEAR Late Count, Ring Operational

Still Usable:

Ring Operational & nRQ.Send &

((RQ.Class 4 synchronous & nRELR.Beacon Received)

(RQ.Class 4 asynchronous & nLate & RQ.Capture 4 FCr.L &

l

i

k

T Pri RQ.Class.Priority ) &

[

]

(RQ.Class

n(RQ.Class 4 restricted &

(RELR.Beacon Received RELR.Claim Received

priority TRT

l

(RQ.Class.Capture 4 nonrestricted & nRbeginOK)))))

(5) TX Data Actions (T2):

Ð

IF Lmax 4 expired & RQ.Ready

THEN RESET Lmax; SET Used

IF nRQ.Ready

THEN RESET Lmax; CLEAR Used

IF Abort

THEN SET TX.Abort;

IF Still Usable

THEN SET TX.Ready

ELSE SET TX.Pass

After ED

SET TX.ED;

IF Still Usable

THEN SET TX.Ready

ELSE SET TX.Pass

(6) Issue TK Actions (T3):

Ð

Always:

IF My Void

THEN CLEAR Void Strip

(7) Claim TK Actions (T4):

Ð Ð

CLEAR Function.Claim Request

(8) TX Beacon Actions (T5):

Ð Ð

CLEAR Function.Beacon Request

(9) TX Void Actions (T7):

Ð

Always:

IF My Void & Vsent

THEN CLEAR Void Strip

130

131

Physical Dimensions inches (millimeters)

132-Pin PQFP

Order Number DP83261AVF

NS Package Number VF132A

LIFE SUPPORT POLICY

NATIONAL’S PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPORT

DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF NATIONAL

SEMICONDUCTOR CORPORATION. As used herein:

1. Life support devices or systems are devices or

systems which, (a) are intended for surgical implant

into the body, or (b) support or sustain life, and whose

failure to perform, when properly used in accordance

with instructions for use provided in the labeling, can

be reasonably expected to result in a significant injury

to the user.

2. A critical component is any component of a life

support device or system whose failure to perform can

be reasonably expected to cause the failure of the life

support device or system, or to affect its safety or

effectiveness.

National Semiconductor

Corporation

National Semiconductor

Europe

National Semiconductor

Hong Kong Ltd.

National Semiconductor

Japan Ltd.

a

1111 West Bardin Road

Arlington, TX 76017

Tel: 1(800) 272-9959

Fax: 1(800) 737-7018

Fax:

(

49) 0-180-530 85 86

@

13th Floor, Straight Block,

Ocean Centre, 5 Canton Rd.

Tsimshatsui, Kowloon

Hong Kong

Tel: (852) 2737-1600

Fax: (852) 2736-9960

Tel: 81-043-299-2309

Fax: 81-043-299-2408

Email: cnjwge tevm2.nsc.com

a

Deutsch Tel:

English Tel:

Fran3ais Tel:

Italiano Tel:

(

49) 0-180-530 85 85

49) 0-180-532 78 32

49) 0-180-532 93 58

49) 0-180-534 16 80

National does not assume any responsibility for use of any circuitry described, no circuit patent licenses are implied and National reserves the right at any time without notice to change said circuitry and specifications.


型号：	DP83261
厂家：	National Semiconductor
描述：	BMAC Device (FDDI Media Access Controller) BMAC设备（ FDDI的媒体访问控制器）控制器
文件：	总132页 (文件大小：1112K)
中文：	中文翻译
下载：	下载PDF数据表文档文件

DP83261 [NSC]

相关型号：

DP83261AVF

DP83261VF

DP83265

DP83265A

DP83265AVF

DP83265BSI

DP83265VF

DP83266

DP83266VF

DP83266VF-MPC

DP83290EB

DP83291EB