DP83266_技术文档

PRELIMINARY

October 1994

DP83266 MACSI^TMDevice

(FDDI Media Access Controller and System Interface)

Y

On-chip address bit swapping capability

General Description

The DP83266 Media Access Controller and System Inter-

Y

32-bit wide Address/Data path with byte parity

Y

Programmable transfer burst sizes of 4 or 8

face (MACSI) implements the ANSI X3T9.5 Standard Media

32-bit words

Access Control (MAC) protocol for operation in an FDDI

token ring and provides a comprehensive System Interface.

Y

Receive frame filtering services

Y

Frame-per-Page mode controllable on each

DMA channel

The MACSI device transmits, receives, repeats, and strips

tokens and frames. It produces and consumes optimized

data structures for efficient data transfer. Full duplex archi-

tecture with through parity allows diagnostic transmission

and self testing for error isolation and point-to-point connec-

tions.

Y

Demultiplexed Addresses supported on ABus

Y

New multicast address matching feature

Y

ANSI X3T9.5 MAC standard defined ring

service options

Y

Supports all FDDI Ring Scheduling Classes

(Synchronous, Asynchronous, etc.)

Supports Individual, Group, Short, Long and

External Addressing

The MACSI device includes the functionality of both the

DP83261 BMAC^TMdevice and the DP83265 BSI-2^TMdevice

with additional enhancements for higher performance and

reliability.

Y

Generates Beacon, Claim, and Void frames

Extensive ring and station statistics gathering

Extensions for MAC level bridging

Enhanced SBus compatibility

Features

Y

Over 9 kBytes of on-chip FIFO

Y

5 DMA channels (2 Output and 3 Input)

Y

Interfaces to DRAMs or directly to system bus

Supports frame Header/Info splitting

Programmable Big or Little Endian alignment

12.5 MHz to 25 MHz operation

Y

Full duplex operation with through parity

Y

Supports JTAG boundary scan

Y

Real-time Void stripping indicator for bridges

Block Diagram

TL/F/11705–1

FIGURE 1-1. FDDI Chip Set Block Diagram

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

TM

BMAC^TM, BSI-2^TM, MACSI^TMand PLAYER

are trademarks of National Semiconductor Corporation.

a

C

1995 National Semiconductor Corporation

TL/F/11705

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

Table of Contents

1.0 FDDI CHIP SET OVERVIEW

5.0 FUNCTIONAL DESCRIPTION (RING ENGINE)

(Continued)

2.0 GENERAL FEATURES

2.1 FDDI MAC Support

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

2.2 MAC Addressing Support

2.3 MAC Bridging Support

2.4 MAC Service Class Support

2.5 Diagnostic Counters

2.6 Management Services

2.7 Ring Parameter Tuning

2.8 Multi-Frame Streaming Interface

2.9 Beacon, Claim and Void Frames Generation

2.10 Self Testing

5.12 Handling Internal Errors

6.0 FUNCTIONAL DESCRIPTION (SERVICE ENGINE)

6.1 Overview

2.11 32-Bit Address/Data Path to Host Memory

2.12 Multi-Channel Architecture

2.13 Support for Header/Info Splitting

2.14 MAC Bridging Support

2.15 Address Bit Swapping

2.16 Status Batching Services

2.17 Receive Frame Filtering Services

2.18 Two Timing Domains

6.2 Operation

6.3 External Matching Interface

6.4 Bus Interface Unit

6.5 Enhanced ABUS Mode

7.0 CONTROL INFORMATION

7.1 Overview

7.2 Conventions

7.3 Access Rules

2.19 Clustered Interrupts

7.4 Ring Engine Operation Registers

7.5 MAC Parameters

2.20 FIFO Memory

2.21 Frame-per-Page-per-Channel

2.22 Copy All Multicast

7.6 Timer Values

7.7 Event Counters

2.23 Bridge Stripping Information

2.24 LED Status Control Outputs

2.25 JTAG Boundary Scan

7.8 Pointer RAM Registers

7.9 Limit RAM Registers

7.10 Descriptors

3.0 ARCHITECTURAL DESCRIPTION

3.1 Interfaces

7.11 Operating Rules

7.12 Pointer RAM Register Descriptions

7.13 Limit RAM Register Descriptions

3.2 Ring Engine

3.3 Data Structures

3.4 Service Engine

8.0 SIGNAL DESCRIPTIONS

8.1 Control Interface

8.2 PHY Interface

4.0 FDDI MAC FACILITIES

4.1 Symbol Set

8.3 External Matching Interface

8.4 LED Interface

4.2 Protocol Data Units

4.3 Frame Counts

4.4 Timers

8.5 ABus Interface

8.6 Electrical Interface

4.5 Ring Scheduling

9.0 ELECTRICAL CHARACTERISTICS

9.1 Absolute Maximum Ratings

5.0 FUNCTIONAL DESCRIPTION (RING ENGINE)

5.1 Token Handling

9.2 Recommended Operating Conditions

9.3 DC Electrical Characteristics

9.4 AC Electrical Characteristics

5.2 Servicing Transmission Requests

5.3 Request Service Parameters

5.4 Frame Validity Processing

10.0 PIN TABLE AND PIN DIAGRAM

2

1.0 FDDI Chip Set Overview

National Semiconductor’s FDDI chip set is shown in Figure

DP83266 MACSI Device

Media Access Controller and

System Interface

The MACSI device implements the Timed Token Media Ac-

cess Control protocol defined by the ANSI FDDI X3T9.5

MAC Standard as well as a high performance system inter-

face.

TM

a

consult the appropriate datasheet and application notes.

1-1. For more information about the PLAYER

device,

a

Device Physical Layer Controller

DP83256/56-AP/57 PLAYER

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 generation functions.

Features

Over 9 kBytes of on-chip FIFO

#

Features

Single chip FDDI Physical Layer (PHY) solution

5 DMA channels (2 Output and 3 Input)

#

12.5 MHz to 25 MHz operation

#

Integrated Digital Clock Recovery Module provides en-

hanced tracking and greater lock acquisition range

#

Full duplex operation with through parity

#

Supports JTAG boundary scan

#

Integrated Clock Generation Module provides all neces-

sary clock signals for an FDDI system from an external

12.5 MHz reference

#

Real-time Void stripping indicator for bridges

#

On-chip address bit swapping capability

#

32-bit wide Address/Data path with byte parity

#

Alternate PMD Interface (DP83256-AP/57) Supports

UTP twisted pair FDDI PMDS with no external clock re-

covery or clock generations functions required

#

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

Receive frame filtering services

No External Filter Components

#

Frame-per-Page mode controllable on each

DMA channel

Connection Management (CMT) Support (LEM, TNE,

PC React, CF React, Auto Scrubbing)

Demultiplexed Addresses supported on ABus

#

Ð Ð

Full on-chip configuration switch

#

New multicast address matching feature

Low Power CMOS-BIPOLAR design using a single 5V

supply

ANSI X3T9.5 MAC standard defined ring service options

Supports all FDDI Ring Scheduling Classes

(Synchronous, Asynchronous, etc.)

Full duplex operation with through parity

#

Separate management interface (Control Bus)

Supports Individual, Group, Short, Long and

External Addressing

#

Selectable Parity on PHY-MAC Interface and Control Bus

Interface

Generates Beacon, Claim, and Void frames

#

Two levels of on-chip loopback

4B/5B encoder/decoder

#

Extensive ring and station statistics gathering

Extensions for MAC level bridging

Framing logic

Enhanced SBus compatibility

Elasticity Buffer, Repeat Filter, and Smoother

Line state detector/generator

Interfaces to DRAMs or directly to system bus

Supports frame Header/Info splitting

Supports single attach stations, dual attach stations and

concentrators with no external logic

Programmable Big or Little Endian alignment

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

DP83257 for SAS/DAS single/dual path stations

#

In addition, the DP83257 contains an additional

PHY Data.request and PHY Data.indicate port required

Ð Ð

for concentrators and dual attach stations.

3

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.

2.0 General Features

The DP83266 MACSI device is a highly integrated FDDI

a

controller. Together with the DP83256/57 PLAYER de-

vice, it forms a full-featured, high performance FDDI chip set

useful for designing end station attachments, concentrators,

bridges, routers, and other FDDI connections. The MACSI

device provides all of the features and services of both the

DP83261 BMAC device and the DP83265 BSI-2 device with

enhanced performance and reliability.

2.5 DIAGNOSTIC COUNTERS

The MACSI device includes a number of diagnostic coun-

ters and timers that monitor ring and station performance.

These counters allow measurement of the following:

For system connection, the MACSI device provides a simple

yet powerful bus interface and memory management

scheme to maximize system efficiency and it is capable of

interfacing to a variety of host buses/environments. The

MACSI device provides a 32-bit wide data interface, which

can be configured to share a system bus to main memory or

to use external shared memory. Also provided are 28-bit

addresses multiplexed on the data pins as well as demulti-

plexed on dedicated pins. The system interface supports

virtual addressing using fixed-size pages.

Number of frames transmitted and received by the

station

#

Number of frames copied as well as frames not copied

#

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

#

Ring latency

#

Lost frames

For network connection, the MACSI device provides many

services which simplify network management and increase

system performance and reliability. The MACSI device is

capable of batching confirmation and indication status, fil-

tering MAC frames with the same Information field as well

as Void frames, and performing network monitoring func-

tions.

The size of these counters has been selected to keep the

frequency of overflow small, even under worst case operat-

ing conditions.

2.6 MANAGEMENT SERVICES

The MACSI 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 MACSI device.

2.1 FDDI MAC SUPPORT

The MACSI device implements the ANSI X3T9.5 FDDI MAC

standard protocol for transmitting, receiving, repeating and

stripping frames. The MACSI device provides all of the infor-

mation necessary to implement the service primitives de-

fined in the standard.

2.7 RING PARAMETER TUNING

The MACSI device includes settable parameters to allow

tuning of the network to increase performance over a large

range of network sizes.

The MACSI device supports systems of two stations with

little cable between them to ring configurations much larger

than the 1000 physical attachments and/or 200 kilometer

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

dard.

2.2 MAC ADDRESSING SUPPORT

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

ed simultaneously, for both Individual and Group addresses.

2.3 MAC BRIDGING SUPPORT

Several features are provided to increase performance in

bridging applications.

The MACSI device also handles frames larger than the

4500 byte default maximum frame size as specified in the

standard.

On the receive side, external address matching logic can be

used to examine the PH Indicate byte stream to decide

Ð

2.8 MULTI-FRAME STREAMING INTERFACE

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

and how to increment the counters.

The MACSI device provides an interface to support multi-

frame streaming. Multiple frames can be transmitted after a

token is captured within the limits of the token timer thresh-

olds.

On the transmit side, transparency options are provided on

the Source Address, the most significant bit of the Source

Address, and the Frame Check Sequence (FCS).

2.9 BEACON, CLAIM, AND VOID FRAMES GENERATION

In addition, support for an alternate stripping mechanism

(implemented using My Void frames) provides maximum

flexibility in the generation of frames by allowing the use of

Source Address Transparency (SAT).

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

essor intervention is required. The MACSI device automati-

cally generates the appropriate MAC frames.

Ð

2.4 MAC SERVICE CLASS SUPPORT

2.10 SELF TESTING

All FDDI MAC service classes are supported by the MACSI

device including Synchronous, Asynchronous, Restricted

Asynchronous, and Immediate service classes.

Since the MACSI device has a full duplex architecture, loop-

back testing is possible before entering the ring and during

normal ring operation.

For Synchronous transmission, one or more frames are

transmitted in accordance with the station’s synchronous

bandwidth allocation.

There are several possible loopback paths:

Internal to the MACSI device

#

a

Through the PLAYER device(s) using the PLAYER

configuration switch

a

#

For Asynchronous transmission, one programmable asyn-

chronous priority threshold is supported in addition to the

threshold at the Negotiated Target Token Rotation time.

a

Through the PLAYER Clock Recovery Module.

#

For Restricted Asynchronous transmission, support is pro-

vided to begin, continue and end restricted dialogues.

4

2.0 General Features (Continued)

These paths allow error isolation at the device level.

come 10:00:E8:43:85:C0). This option is selectable on a per

channel basis and is supported on all transmit and receive

channels. This is useful for bridging FDDI to Ethernet or for

swapping addresses for higher level protocols.

The MACSI device also supports through parity. Even when

parity is not used by the system, parity support can be pro-

vided across the PHY Interface.

2.16 STATUS BATCHING SERVICES

2.11 32-BIT ADDRESS/DATA PATH TO HOST MEMORY

The MACSI device provides status for transmitted and re-

ceived frames. Interrupts to the host are generated only at

status breakpoints, which are defined by the user on a per

DMA Channel basis. Breakpoints are selected when the

Channel is configured for operation. To allow batching, the

MACSI provides a status option called Tend, that causes

the device to generate a single Confirmation Message De-

scriptor (CNF) for one or more Request Descriptors (REQs).

The MACSI device provides a 32-bit wide synchronous data

interface, which permits connection to a standard multi-

master system bus operating from 12.5 MHz to 33 MHz, or

to local memory, using Big or Little Endian byte ordering.

Demultiplexed addresses are provided on dedicated pins.

Address information is also multiplexed on the data pins to

provide backward compatibility for designs based on the

BSI device. The local memory may be static or dynamic. For

maximum performance, the MACSI device uses burst mode

transfers, with four or eight 32-bit words to a burst. To assist

the user with the burst transfer capability, the three bits of

the address which cycle during a burst are output as demul-

tiplexed signals. Maximum burst speed is one 32-bit word

per clock, but slower speeds may be accommodated by in-

serting wait states.

The MACSI device further reduces host processing time by

separating received frame status from the received data.

This allows the CPU to scan quickly for errors when decid-

ing whether further processing should be done on received

frames. If status was embedded in the data stream, all data

would need to be read contiguously to find the Status Indi-

cator.

The MACSI device can operate within any combination of

cached, non-cached, paged or non-paged memory environ-

ments. To provide this capability, all data structures are con-

tained within a page boundary, and bus transactions never

cross page boundaries. The MACSI device performs all bus

transactions within aligned blocks to ease the interface to a

cached environment.

2.17 RECEIVE FRAME FILTERING SERVICES

To increase performance and reliability, the MACSI device

can be programmed to filter out identical MAC (same FC

and Info field) or SMT frames received from the ring. Void

frames are filtered out automatically. Filtering unnecessary

frames reduces the fill rate of the Indicate FIFO, reduces

CPU frame processing time, and reduces memory bus

transactions.

2.12 MULTI-CHANNEL ARCHITECTURE

The MACSI device provides three Input Channels and two

Output Channels, which are designed to operate indepen-

dently and concurrently. They are separately configured by

the user to manage the reception or transmission of a par-

ticular kind of frame (for example, synchronous frames

only).

2.18 TWO TIMING DOMAINS

To provide maximum performance and system flexibility, the

MACSI device uses two independent clocks, one for the

MAC (ring) Interface, and one for the system/memory bus.

The MACSI device provides a fully synchronized interface

between these two timing domains.

2.13 SUPPORT FOR HEADER/INFO SPLITTING

2.19 CLUSTERED INTERRUPTS

In order to support high performance protocol processing,

the MACSI device can be programmed to split the header

and information portions of (non-MAC/SMT) frames be-

tween two Indicate Channels. Frame bytes from the Frame

Control field (FC) up to the user-defined header length are

copied onto Indicate Channel 1, and the remaining bytes

(Info) are copied onto Indicate Channel 2. This is useful for

separating protocol headers from data and allows them to

be stored in different regions of memory to prevent unnec-

essary copying. In addition, a protocol monitor application

may decide to copy only the header portion of each frame.

The MACSI device can be operated in a polled or interrupt-

driven environment. The MACSI device provides the ability

to generate attentions (interrupts) at group boundaries.

Some boundaries are pre-defined in hardware; others are

defined by the user when the Channel is configured. This

interrupt scheme significantly reduces the number of inter-

rupts to the host, thus reducing host processing overhead.

2.20 FIFO MEMORY

The MACSI device contains over 9 kBytes of on-chip FIFO

memory. This memory includes separate 4.6 kByte FIFOs

for both the Transmit (Request) and Receive (Indicate) data

paths. These data FIFOs allow the MACSI device to support

over 370 ms of bus latency for both transmit and receive.

They also allow the MACSI device to buffer entire maximum

length FDDI frames on-chip for both transmit and receive

simultaneously. This allows lower cost systems by enabling

the MACSI device to reside directly on system buses with

high latency requirements.

2.14 MAC BRIDGING SUPPORT

Support for bridging and monitoring applications is provided

by the Internal/External Sorting Mode. All frames matching

the external address (frames requiring bridging) are sorted

onto Indicate Channel 2, MAC and SMT frames matching

the internal (Ring Engine) address are sorted onto Indicate

Channel 0, and all other frames matching the device’s inter-

nal address (short or long) are sorted onto Indicate

Channel 1.

These FIFOs support all of the features available in the orig-

inal BSI device including two transmit and three receive

channels to make efficient use of the FIFO resources. New

transmit thresholds are available to allow full use of the larg-

er transmit FIFO.

2.15 ADDRESS BIT SWAPPING

The MACSI contains the necessary logic for swapping the

address fields within each frame between FDDI and IEEE

Canonical bit order. This involves a bit reversal within each

byte of the address field (e.g., 08-00-17-C2-A1-03 would be-

5

2.0 General Features (Continued)

In addition to the 4.6 kByte data FIFOs, both the transmit

and receive data paths contain Burst FIFO Blocks, each of

which are organized as two banks of eight 32-bit words.

2.24 LED STATUS CONTROL OUTPUTS

The MACSI device (revision D and later) provides two out-

puts that give Transmit and Receive status information use-

ful for controlling LEDs. The MACSI asserts the TXLED pin

each time that it detects that the Request State machine

has entered the ‘‘sending’’ state, (once per transmitted

frame). Note that it will not assert TXLED for internally gen-

erated MAC frames. It asserts the RXLED pin each time it

detects the End Delimiter of a copied frame (VCOPY and

EDRCVD). Both of these pins use Open Drain output struc-

tures (this preserves pin compatibility with MACSI devices

prior to revision D). Therefore, they require pull-up resistors

when used for LED control information. To increase the LED

on-time for visibility, the User must supply one-shot circuits

triggered by TXLED and RXLED.

2.21 FRAME-PER-PAGE-PER-CHANNEL

The MACSI device has a feature which allows control of the

Frame-per-Page mode (available on the BSI device) on a

per-Channel basis. For example, this is useful in systems

where Frame-per-Page mode is used to speed up memory

space reclamation on an LLC channel, but where packing

multiple frames into each page is desired to save space on

the SMT channel.

2.22 COPY ALL MULTICAST

The MACSI provides a copy mode which allows all frames

which are addressed with multicast addresses to be copied.

Multicast addresses are those that have the Individual/

Group address bit (most significant bit of the FDDI address)

set. This simple scheme allows flexibility in the use of multi-

cast addresses. The MACSI device copies all multicast

frames and software makes the final determination as to

which multicast groups this station belongs.

2.25 JTAG BOUNDARY SCAN

The MACSI device supports the JTAG boundary scan stan-

dard (IEEE Std. 1149.1–1990).

3.0 Architectural Description

The MACSI is derived from the BMAC and BSI devices. The

MACSI is composed of the Ring Engine, the Service Engine,

and the Bus Interface Unit. The Ring Engine performs the

FDDI MAC Timed token protocol and contains the MAC

transmitter and receiver. The Service Engine implements

the Request and Indicate Data Services and contains the

Transmit and Receive Data FIFOs. The Bus Interface Unit

implements the high speed synchronous bus handshake

and contains the Burst FIFOs.

2.23 BRIDGE STRIPPING INFORMATION

The MACSI device provides an output designed to make it

easier to build transparent bridges. Source Address Trans-

parency features are provided as well as features to allow

these frames to be stripped from the ring. For transparent

bridges, it is important to know when the MACSI is using this

stripping feature to remove frames from the ring which were

forwarded by this bridge but with an unknown source ad-

dress, (i.e., Source Address Transparency enabled). This is

important because the bridge does not want to ‘‘learn’’

these addresses. This feature is provided by the MACSI in

the form of an output pin indicating which frames contain

addresses which should be added to the address filter table

(i.e. learned).

The MACSI device uses a full duplex architecture and pro-

vides sufficient bandwidth at the ABus for full duplex trans-

mission with support for through parity. Figure 3-1 shows

the MACSI device architecture.

TL/F/11705–2

FIGURE 3-1. MACSI Device Block Diagram

6

3.0 Architectural Description (Continued)

3.1 INTERFACES

During operation, the host uses the Control Bus to access

the device’s internal registers, and to manage the attention/

notify (interrupt) logic.

3.1.1 PHY Interface

The PHY Interface is a synchronous interface that provides

3.2 RING ENGINE

a

a byte stream to the PLAYER device (the PHY Request

byte stream, PHY Request), and receives a byte stream

The Ring Engine consists of four blocks: Receiver, Trans-

mitter, MAC Parameter RAM, and Counters/Timers as

shown in Figure 3-2.

Ð

a

from the PLAYER device (the PHY Indicate byte stream,

PHY Indicate).

Ð

The 10 bits 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.

3.2.1 Receiver

Ð

The Receiver accepts data from the PHY level device in

byte stream format (PH Indicate).

Ð

Upon receiving the data, the Receiver performs the follow-

ing functions:

3.1.2 ABus Interface

Determines the beginning and ending of a Protocol Data

Unit (PDU)

#

The ABus interface provides the high performance synchro-

nous Data and Control interface to the Host System and/or

local memory. Data and Descriptors are transferred via this

interface over the 32-bit Data bus (with byte parity). Both

multiplexed and non-multiplexed address information is

available on this bus. Arbitration and transfer control signals

are provided and minimize the requirements for external

glue logic.

Decodes the Frame Control field to determine the PDU

type (frame or token)

#

Compares the received Destination and Source Address-

es with the internal addresses

#

Processes data within the frame

#

Calculates and checks the Frame Check Sequence at

the end of the frame

3.1.3 Control Bus Interface

Checks the Frame Status field

#

And finally, the Receiver presents the data to the MAC Inter-

face along with the appropriate control signals

(MA Indicate).

Ð

The Control Interface implements the interface to the Con-

trol Bus which allows the user to initialize, monitor and diag-

nose the operation of the MACSI. The Control Interface is

an 8-bit interface. This reduces the pinout and minimizes

board space. All information that must be synchronized with

the data stream crosses the ABus Interface.

3.2.2 Transmitter

The Transmitter 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

The Control Bus is separated completely from the high per-

formance data path in order to allow independent operation

of the processor on the Control Bus. The Control Interface

provides synchronization between the asynchronous Con-

trol Bus and the synchronous operation of the device.

Transmitter block multiplexes data from the MA Request

Ð

Interface and data from the Receiver Block. During frame

transmission, data from the Request Interface is selected.

During frame repeating, data from the Receiver is selected.

TL/F/11705–3

FIGURE 3-2. Ring Engine Block Diagram

7

3.0 Architectural Description (Continued)

During frame transmission, the Transmitter performs the fol-

lowing functions:

Data and Descriptor objects may consist of one or more

parts, where each part is contiguous and wholly contained

within a memory page. Descriptor pages are selectable as

all 1 kBytes or all 4 kBytes. Data Units are described by

Descriptors with a pointer and a count. A single Data Unit

Captures a token to gain the right to transmit

#

Transmits one or more frames

#

Generates the Frame Check Sequence and appends it at

the end of the frame

#

may not cross

a 4k boundary. All Descriptors may be

marked as First, Middle, Last, or Only. Thus, multiple De-

scriptors may be combined to describe a single entity (i.e.

one frame). A single-part object consists of one Only Part; a

multiple-part object consists of one First Part, zero or more

Middle Parts, and one Last Part. In Descriptor names, the

object part is denoted in a suffix, preceded by a dot. Thus

an Input Data Unit Descriptor (IDUD), which describes the

last Data Unit of a frame received from the ring, is called an

IDUD.Last.

Generates the Frame Status field that is transmitted at

the end of the frame

#

Issues the token at the end of frame transmission

#

During frame repeating, the Transmitter performs the follow-

ing functions:

Repeats the received frame and modifies the Frame

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

standard

#

A Data Unit is stored in contiguous locations within a single

4 kByte page in memory. Multiple-part Data Units are stored

in separate, and not necessarily contiguous 4 kByte pages.

Descriptors are stored in contiguous locations in Queues

and Lists, where each Queue occupies a single 1 kByte or

4 kByte memory page, aligned on the queue-size boundary.

For Queues, an access to the next location after the end of

a page will automatically wrap-around and access the first

location in the page.

Whether transmitting or repeating frames, the Transmitter

also performs the following functions:

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

#

Generates Idle symbols between frames

#

Data is presented from the Transmitter to the PLAYER

a

device in byte stream format (PH Request).

Ð

3.2.3 MAC Parameter RAM

The MAC Parameter RAM is a dual port RAM that contains

MAC parameters such as the station’s short and long ad-

dresses. These parameters are initialized via the Control

Interface. Both the Receiver and Transmitter Blocks access

the RAM.

Data Units are transferred between the MACSI’s Service

Engine and Ring Engine via five simplex Channels, three

used for Indicate (receive) data and two for Request (trans-

mit) data. Parts of frames received from the ring and copied

to memory are called Input Data Units (IDUs); parts of

frames read from memory to be transmitted to the ring are

called Output Data Units (ODUs).

The Receiver uses these parameters to compare addresses

in incoming frames with the individual and group addresses

stored in the Parameter RAM.

Descriptors are transferred between the MACSI device and

Host via the ABus, whose operation is for the most part

transparent to the user. There are five Descriptor types rec-

ognized by the MACSI device: Input Data Unit Descriptors

(IDUDs), Output Data Unit Descriptors (ODUDs), Pool

Space Descriptors (PSPs), Request Descriptors (REQs),

and Confirmation Message Descriptors (CNFs).

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 on Claim and Beacon frames.

3.2.4 Counters/Timers

The Counter/Timer Block maintains all of the counters and

timers required by the ANSI X3T9.5 MAC standard.

Input and Output Data Unit Descriptors describe a single

Data Unit part, i.e., its address (page number and offset), its

size in bytes, and its part (Only, First, Middle, or Last).

Frames consisting of a single part are described by a Des-

criptor.Only; frames consisting of multiple parts are de-

scribed by a single Descriptor.First, zero or more Descrip-

tor.Middles, and a single Descriptor.Last.

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.

Every Output Data Unit part is described by an ODUD. Out-

put Data Unit Descriptors are fetched from memory so that

frame parts can be assembled for transmission.

The Token Rotation and Token Holding Timers which are

used to implement the Timed Token Protocol are contained

within the Timer Block.

Every Input Data Unit part is described by an Input Data Unit

Descriptor (IDUD). Input Data Unit Descriptors are generat-

ed on Indicate Channels to describe where the MACSI de-

vice wrote each frame part and to report status for the

frame.

3.3 DATA STRUCTURES

3.3.1 Data Types

The architecture of the MACSI device defines two basic

types of objects: Data Units and Descriptors. A Data Unit is

a group of contiguous bytes which forms all or part of a

frame. A Descriptor is a two-word (64-bit) control object that

provides addressing information and control/status informa-

tion about MACSI device operations.

Request Descriptors (REQs) are written by the user to spec-

ify the operational parameters for the MACSI device Re-

quest operations. Request Descriptors also contain the start

address of part of a stream of ODUDs and the number of

frames represented by the ODUD stream part (i.e., the num-

ber of ODUD.Last descriptors). Typically, the user will define

a single Request Object consisting of multiple frames of the

same request and service class, frame control, and expect-

ed status.

8

3.0 Architectural Description (Continued)

Confirmation Messages (CNFs) are created by the MACSI

device to record the result of a Request operation.

For each Queue Pointer Register there is a corresponding

Queue Limit Register in the Limit RAM Register file, which

holds the Queue’s limit as an offset value in units of 1 De-

scriptor (8 bytes). The address in the Queue Pointer is incre-

mented before a Descriptor is read and after a Descriptor is

written, then compared with the value in the corresponding

Queue Limit Register. When a Queue Pointer Register be-

comes equal to the Queue Limit Register, an attention is

generated, informing the host that the Queue is empty.

When a pointer value is incremented past the end of the

page, it wraps to the beginning of the page.

Pool Space Descriptors (PSPs) describe the location and

size of a region of memory space available for writing Input

Data Units.

Request (transmit) and Indicate (receive) data structures

are summarized in Figure 3-3.

3.3.2 Descriptor Queues and Lists

The MACSI device uses 10 Queues and two Lists which are

circular. There are six Queues for Indicate operations, and

four Queues and two Lists for Request operations. Each of

the three Indicate Channels has a Data Queue containing

Pool Space Descriptors (PSPs), and a Status Queue con-

taining Input Data Unit Descriptors (IDUDs). Each Request

Channel has a Data Queue containing Request Descriptors

(REQs), a Status Queue containing Confirmation Messages

(CNFs), and a List containing Output Data Unit Descriptors

(ODUDs).

3.3.3 Storage Allocation

The maximum unit of contiguous storage allocation in exter-

nal memory is a Page. All MACSI device addresses consist

of a 16-bit page number and a 12-bit offset.

The MACSI device uses a page size of 1 kByte or 4 kBytes

for storage of Descriptor Queues and Lists (as selected by

the user), and a page size of 4 kBytes for storage of Data

Units. A single page may contain multiple Data Units, and

multiple-part Data Units may span multiple, disjoint or con-

tiguous pages.

During Indicate and Request operations, Descriptor Queues

and Lists are read and written by the MACSI device, using

registers in the Pointer and Limit RAM Register files. The

Pointer RAM Queue and List Pointer Registers point to a

location from which a Descriptor will be read (PSPs and

REQs) or written (IDUDs and CNFs). All of the Queues and

Lists are strictly unidirectional. The MACSI consumes ob-

jects in those queues which are produced by the Host. The

Host consumes objects in those queues which are pro-

duced by the MACSI.

3.4 SERVICE ENGINE

The Service Engine, which manages the operation of the

MACSI, contains seven basic blocks: Indicate Machine, Re-

quest Machine, Status/Space State Machine, Pointer RAM,

Limit RAM, and Bus Interface Unit. An internal block dia-

gram of the Service Engine is shown in Figure 3-4.

3.4.1 Indicate Machine

The Indicate Block accepts Service Data Units (frames)

from the Ring Engine (MAC) in a byte stream format

(MA Indicate).

Ð

9

3.0 Architectural Description (Continued)

Request Data Structures

TL/F/11705–4

Indicate Data Structures

TL/F/11705–5

FIGURE 3-3. MACSI Device Data Structures

10

3.0 Architectural Description (Continued)

TL/F/11705–6

FIGURE 3-4. Service Engine/BIU Internal Block Diagram

Upon receiving the data, the Indicate Block performs the

following functions:

3.4.3 Status/Space Machine

The Status/Space Machine is used by both the Indicate Ma-

chine and the Request Machine.

Decodes the Frame Control field to determine frame type

#

Sorts received frames onto Channels according to the

Sort Mode

The Status/Space Machine manages all descriptor Queues

and writes status for received and transmitted frames.

#

Optionally Filters identical MAC frames

#

3.4.4 Bus Interface Unit

Filters Void frames

#

The Bus Interface Unit (BIU) is used by both the Indicate

and Request Blocks. It manages the ABus Interface, provid-

ing the MACSI device with a 32-bit data path to local or

system memory.

Copies the received frames to memory according to

Copy Criteria

Writes status for the received frames to the Indicate

Status Queue

#

The Bus Interface Unit controls the transfer of Data Units

and Descriptors between the MACSI device and Host mem-

ory via the ABus.

Issues interrupts to the host at host-defined status break-

points

#

Data and Descriptors are transferred between the MACSI

device and Host memory. Each Channel type handles a set

of Data and Descriptor objects. The three Indicate (Receive)

Channels use the following objects:

3.4.2 Request Machine

The Request Machine presents frames to the Ring Engine

(MAC) in a byte stream format (MA Request).

Ð

The Request Machine performs the following functions:

1. Input Data Units (written by MACSI)

Reads frames from host memory and assembles them

onto Request Channels

#

2. Input Data Unit Descriptors (written by MACSI)

3. Pool Space Descriptors (read by MACSI)

Prioritizes active requests

#

The two Request (Transmit) Channels each use the follow-

ing objects:

Transmits frames to the Ring Engine (MAC)

Optionally writes status for transmitted and returning

frames

#

1. Output Data Units (read by MACSI)

2. Output Data Unit Descriptors (read by MACSI)

3. Confirmation Message Descriptors (written by MACSI)

4. Request Descriptors (read by MACSI)

Issues interrupts to the host on user-defined group

boundaries

#

11

4.2 PROTOCOL DATA UNITS

3.0 Architectural Description

(Continued)

The Ring Engine recognizes and generates Tokens and

Frames.

Each Channel will only process one object type at a time.

The BIU arbitrates between the Channels and issues a Bus

Request when any Channel requests service. The priority of

Channel bus requests is as follows, from highest priority to

lowest priority:

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.

1. Indicate Data Unit writes (highest priority when not trans-

mitting)

TABLE 4-1. Symbol Pair Set

Type

Starting Delimiter

Ending Delimiter

Frame Status

Symbols

JK or IL

2. Output Data Unit fetches (highest priority when transmit-

ting)

3. Request Descriptor and Output Data Unit Descriptor

fetches

TT or TR or TS or TI

RR or RS or SR or SS

4. Input Data Unit Descriptor writes

5. Confirmation Message Descriptor writes

Idle

II or nI

nn

6. Next Pool Space Descriptor transfer to Current Pool

Space Descriptor (internal operation)

Data Pair

n represents any data symbol (0–F).

7. Pool Space Descriptor fetches

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

8. Limit RAM Operations (internal operation)

9. Pointer RAM Operations (lowest priority)

Additional information on the symbol pairs generated and interpreted by the

Ring Engine can be found in Section 8.2.1.

Addresses for Channel accesses are contained in the Point-

er RAM Registers.

TABLE 4-2. Frame Fields

3.4.5 Pointer RAM

Name

Description

Size

The Pointer RAM Block is used by both the Indicate and

Request Machines. It contains pointers to all Data Units and

Descriptors manipulated by the MACSI device, namely, In-

put and Output Data Units, Input and Output Data Unit De-

scriptors, Request Descriptors, Confirmation Message De-

scriptors, and Pool Space Descriptors.

SFS

Start of Frame

Sequence

PA

Preamble

8 or more Idle

symbol pairs

SD

FC

Starting Delimiter

Frame Control Field

Destination Address

Source Address

JK symbol pair

1 data symbol pair

2 or 6 symbol pairs

The Pointer RAM Block is accessed by clearing the PTOP

(Pointer RAM Operation) bit in the Service Attention Regis-

ter, which causes the transfer of data between the Pointer

RAM Register and a mailbox location in memory.

DA

SA

3.4.6 Limit RAM

The Limit RAM Block is used by both the Indicate and Re-

quest Machines. It contains data values that define the lim-

its of the ten Queues maintained by the MACSI device.

INFO

FCS

Information Field

Frame Check

Sequence

4 symbol pairs

Limit RAM Registers are accessed by clearing the LMOP

(Limit RAM Operation) bit in the Service Attention Register,

which causes the transfer of data between the Limit RAM

Register and the Limit Data and Limit Address Registers.

EFS

ED

End of Frame

Sequence

Ending Delimiter

at least 1 T symbol

for Frames;

4.0 FDDI MAC Facilities

4.1 SYMBOL SET

at least 2 T symbols

for Tokens

The Ring Engine (MAC) recognizes and generates a set of

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

FS

Frame Status

3 or more R or S

symbols

SFS

EFS

Additional information regarding the symbol set can be

found in the ANSI X3T9.5 PHY standard.

PA

SD

FC

ED

The Ring Engine expects that the Starting Delimiter will al-

ways be conveyed on an even symbol pair boundary (i.e.,

the JK symbol will always arrive as a byte, not split across

two bytes). Following the starting delimiter, data symbols

should always come in matched pairs. Similarly the Ending

Delimiter should always come in one or more matched sym-

bol pairs.

FIGURE 4-1. Token Format

Frames are used to pass information between stations. The

format of a frame is shown inFigure 4-2, with the field defini-

tions in Table 4-2.

SFS

Protected by FCS

DA SA INFO FCS

EFS

The symbol pairs conveyed at the PHY Interface are shown

in Table 4-1.

PA

SD

FC

ED

FS

FIGURE 4-2. Frame Format

12

4.0 FDDI MAC Facilities (Continued)

4.2.1 Frame Fields

TABLE 4-4. MAC/SMT Frame Types

Start of Frame Sequence (SFS)

CLFF

1000

1100

0L00

rZZZ

0000

Frame Type

Non-restricted Token

The Start of Frame Sequence consists of the Preamble (PA)

followed by the Starting Delimiter (SD).

Restricted Token

Void Frame

The Preamble is a sequence of zero or more Idle symbols

that is used to separate frames. The Ring Engine Receiver

can process and repeat a frame or token with no preamble.

The Ring Engine Transmitter generates frames with at least

8 bytes of preamble. The Ring Engine Transmitter also

guarantees that valid FDDl frames will never be transmitted

with more than 40 bytes of preamble.

0L00 0001 to 1110 SMT Frame

0L00

1L00

1111

0001

0010

0011

0100

SMT Next Station Addressing Frame

Other MAC Frame

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

frame. The Starting Delimiter is the JK Symbol pair.

MAC Beacon Frame

MAC Claim Frame

The Ring Engine expects the Starting Delimiter to be con-

veyed across the PH Indication Interface as a single byte.

MAC Purge Frame

Ð

Similarly, the Ring Engine only generates Starting Delimiters

aligned to the byte boundary.

1L00 0101 to 1111 Other MAC Frame

Frame Control (FC)

Destination Address (DA)

The Frame Control field is used to discriminate frames. For

tokens, the FC field identifies Restricted and Non-restricted

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

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

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

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

DA.lG 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

F

r

Z

FIGURE 4-3. Frame Control Field

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.

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

e

1).

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

e

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

The Ring Engine maintains a 16-bit Individual Address (My

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

Long Address (MLA)).

as Short (L

0) or Long (L

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

Table 4-3.

On the receive side, if DA.lG 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

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

always be transmitted as Zero.

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 frames. These bits may be

used to affect protocol processing criteria such as the Priori-

ty, Protocol Class, Status Handling, etc.

If DA.lG 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 interface

Ð

logic as part of the criteria (with FC.L, DA.lG and M Flag)

Ð

to determine whether or not to copy the frame. lf the

TABLE 4-3. Frame Control Format Bits

A

Flag is set, the system interface will normally attempt to

copy the frame.

FC.FF

Frame Types

SMT/MAC

Ð

0

1

0

1

0

1

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.

LLC

reserved for implementer

reserved for future standardization

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

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

Table 4-4.

Source Address (SA)

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

dress of the station that originally transmitted the frame.

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

13

4.0 FDDI MAC Facilities (Continued)

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 MFlag is set. This

flag is used to indicate that the frame is recognized as hav-

ing been transmitted by this station and is stripped. The

most significant bit of the SA (SA.lG) is not evaluated in the

comparison.

End of Frame Sequence (EFS)

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 of Frame Status Indicators (FS).

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 ANSl X3T9.5 MAC standard.

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

Engine provides a Void Stripping Option; see Request

Channel 0 and 1 Configuration Registers 0 (R0CR0 and

R1CR0) for further information.)

4.2.2 Token Formats

The Ring Engine supports non-restricted and restricted To-

kens. See Figure 4-4 and Figure 4-5.

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 that would like to continue to

perform reliable stripping based on the SA. (When this op-

tion is used without SAT, the transmitted SA is generated by

the Ring Engine, as always.)

SFS

FC

EFS

SD

80

ED

FIGURE 4-4. Non-Restricted Token Format

SFS

FC

ED

Information (INFO)

SD

C0

ED

The Information field contains the data transferred between

peer users of the MAC data service (SMT, LLC, etc.). There

is no INFO field in a Token.

FIGURE 4-5. Restricted Token Format

Non-restricted

The INFO field contains zero or more bytes.

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

stricted asynchronous transmissions. Each time the non-re-

stricted token arrives, a station is permitted to transmit one

or more frames in accordance with its synchronous band-

width allocation regardless of the status of the token (late or

early).

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

ANSl X3T9.5 MAC standard.

The first 4 bytes of the INFO field of MAC frames 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

and both frames were MAC frames, 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

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 restricted token is used for synchronous and restricted

asynchronous transmissions only.

A station which initiates the restricted dialogue captures a

non-restricted token and releases a restricted token. Sta-

tions that participate in the restricted dialogue are allowed

to capture the restricted token. A station ends the restricted

dialogue by capturing the restricted token and releasing a

non-restricted token.

Frame Check Sequence (FCS)

The Frame Check Sequence is a 32-bit Cyclic Redundancy

Check that is used to check for data corruption in frames.

There is no FCS field in a Token.

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

determine whether the frame is valid or corrupted.

4.2.3 Frame Formats

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

The Ring Engine supports all of the frame formats permitted

by the FDDl standard. All frame types may be created ex-

temal to the Ring Engine and be passed through the MAC

Request Interface to the Ring. The Ring Engine also has the

ability to generate Void, Beacon, and Claim frames internal-

ly.

14

4.0 FDDI MAC Facilities (Continued)

Frames Generated Externally

Void Frames

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. The data portion 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 Request Interface as shown in Table 4-5.

Void frames are used during normal operation. The Ring

Engine generates two types of void frames: regular Void

frames and My Void frames.

Ð

If Short addressing is enabled, Void frames with the short

address (MSA) are transmitted. Otherwise, Void frames with

the long address (MLA) are transmitted. Table 4-6 shows

the Void frame format.

Void frames are transmitted in order to reset the Valid

Transmission timers (TVX) in other stations to eliminate un-

necessary entry to the Claim state. Stations are not required

to copy Void frames. Void frames are transmitted by the

Ring Engine in two situations:

TABLE 4-5. Frame Formats

Size

Field

MA Request

Ð

PH Request

Ð

(bytes)

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

mitted.

t

s

8; 40

PA

SD

Idle Pairs

1

JK

2. After a frame transmission is aborted.

FC

DA

FC

My Void frames are transmitted by the Ring Engine in

Ð

three situations:

DA

2 or 6

DA

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

made and the next early token is captured.

SA

MSA, MLA, or SA

t

2. After this station wins the Claim process and before the

token is issued.

INFO

FCS

ED

0

INFO

FCS

INFO

FCS

TR

4 if present

3. After a frame has been transmitted with the STRIP op-

tion and before the token for that service opportunity is

issued.

1

FS

RR

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.

Ð

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 determine when to strip a frame from the

ring. This can be overridden by using the Source Address

transparency capability. Similarly, the Frame Check Se-

quence (4 bytes) is normally transmitted by the Ring Engine.

This can be overridden with the FCS transparency capabili-

ty. With FCS transparency, the FCS is transmitted from the

data stream. The End of Frame Sequence is always trans-

mitted by the Ring Engine as TR RR.

Claim Frames

Claim frames are generated continuously with minimum pre-

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

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 (MLA) are transmitted. Other-

wise frames with the short address (MSA) are transmitted.

The Ring Engine detects reception of valid Claim frames. A

comparison is performed between the first four bytes of the

received INFO field and the value of TREQ programmed in

the parameter RAM in order to distinguish Higher Claim,

Ð

Frames Generated by Ring Engine

Lower Claim, Duplicate Claim, and My Claim.

Ð

The Ring Engine generates and detects several frames in

order to attain and maintain an operational ring.

Beacon Frames

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 (MLA) are transmitted.

Otherwise frames with the short address (MSA) are trans-

mitted.

15

4.0 FDDI MAC Facilities (Continued)

TABLE 4-6. Void Frames

Type

Void

Enable

ESA

Size

Short

Long

Short

Long

SFS

FC

00

40

00

40

DA

null

SA

FCS

EFS

PA

SD

MSA

MLA

MSA

MLA

TRRR

Void

not ESA

ESA

null

My Void

Ð

MSA

MLA

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

Ð

TABLE 4-8. Beacon Frames

Type

Enable

not ELA

ELA

Size

SFS

FC

82

C2

DA

null

SA

INFO

TBT

FCS

EFS

My Beacon

Ð

Short

Long

PA

SD

MSA

MLA

TRRR

My Beacon

Ð

When the Transmit Beacon State is entered from the Trans-

mit Claim State the first byte of the 4 byte TBT field is trans-

mitted as Zero.

4.3.2 Error lsolated Count (ElCT)

The Error lsolated Count is described in the FDDl MAC stan-

dard, and is the count of error frames detected by this sta-

tion and no previous station. It increments when:

Beacon frames that require alternative formats such as Di-

rected Beacons must be generated externally.

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

(Er) is not equal to S.

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

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

and Er is not equal to S.

Ð

other stations (Other Beacon).

Ð

3. Er is not R or S.

4.3 FRAME COUNTS

4.3.3 Lost Frame Count (LFCT)

To aid in fault isolation and to enhance the management

capabilities of a ring, the Ring Engine maintains several

frame counts. The Error and lsolated frame counts incre-

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

were previously undetected. The Ring Engine then modifies

the Error Control Indicator so that a downstream station will

not increment its count.

The Lost Frame Count is described in the FDDl MAC stan-

dard, and is the count of all instances where a format error

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

reception is placed in doubt. The Lost Frame Count is incre-

mented when any symbol other than data or Idle symbols is

received between the Starting and Ending Delimiters of a

frame (this includes parity errors).

The size of the counters has been chosen such that minimal

software intervention is required, even under marginal oper-

ating conditions.

4.3.4 Frame Copied Count (FCCT)

The Frame Copied Count is described in the FDDl MAC

standard, and is the count of the number of frames ad-

dressed to and copied by this station. The count is incre-

mented when an internal or external match occurs (when

Option.EMlND enabled) on the Destination Address, no er-

rors were detected in the frame and the frame was success-

fully copied (which the Service Engine communicates to the

Ring Engine via the internal VCOPY signal). Frames copied

promiscuously, 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 Frame Received

ElCT

Error lsolated

LFCT Lost Frame

FCCT Frames Copied with Ax set

FNCT Frames Not Copied with Ax set

FTCT Frames Transmitted

4.3.1 Frame Received Count (FRCT)

The Frame Received Count is described in the FDDl MAC

standard, and is the count of all complete frames received.

This count includes frames stripped by this station.

16

4.0 FDDI MAC Facilities (Continued)

4.3.5 Frames Not Copied Count (FNCT)

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

the ring became non-operational (with TMAX resolution) in

order to determine if it is necessary to invoke recovery pro-

cedures. When the ring becomes non-operational, there is

no way to know how long it will stay non-operational. There-

fore, a timer is necessary. If the Late Count were not provid-

ed, SMT would be forced to start a timer every time the ring

becomes non-operational even though it may seldom be

used. By using the provided Late Count, an SMT implemen-

tation may be able to alleviate this additional overhead.

The Frames Not Copied Count is specified in the FDDI MAC

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 external (when

Option.EMIND is enabled) Destination Address match oc-

curs, no errors were detected in the frame, and the frame

e

was not successfully copied (VCOPY

0). MAC frames,

Void frames, and NSA frames received with the A indicator

set are not included in this count.

4.4.4 Valid Transmission Timer (TVX)

4.3.6 Frames Transmitted Count (FTCT)

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

valid frame or token is received. TVX is used to increase the

responsiveness of the ring to errors. Expiration of the TVX

indicates that no frame or token has been received within

the timeout period and causes the Transmitter to invoke the

recovery (Claim) process.

The Frames Transmitted Count is specified in the FDDI

MAC standard, and is incremented every time a complete

frame is transmitted from the MAC Request Interface. Void

and MAC frames generated by the Ring Engine are not in-

cluded in the count.

4.4 TIMERS

The Value of TVX is also used as the Duplicate MAC frame

detection delay, DM MIN. This is the time after which a

4.4.1 Token Rotation Timer (TRT)

Ð

MAC frame will be suspected as being generated by anoth-

er station with this station’s address when the ring is non-

operational.

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.

4.4.5 Token Received Count (TKCT)

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.

The Token Received Count is incremented every time a val-

id token arrives. The Token Count can be used with the

Ring Latency Count to calculate the average network load

over a period of time. The frequency of token arrival is in-

versely related to the network load.

4.4.2 Token Holding Timer (THT)

The Token Holding Timer 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 cap-

tured token is (still) usable for asynchronous transmission. A

token is usable for asynchronous traffic if THT has not

reached the selected threshold. Two asynchronous thresh-

olds are supported; one that is fixed at the Negotiated Tar-

get Token Rotation Time (TNEG), and one that is program-

mable at one of 16 Asynchronous Priority Thresholds. Re-

quests to transmit frames at one of the priority thresholds

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

reached the selected threshold.

4.4.6 Ring Latency Count (RLCT)

The Ring Latency Count is a measurement of time for

frames to propagate around the ring. This counter contains

the last measured ring latency whenever the Ring Latency

Valid bit of the Token Event Register (TELR0.RLVLD) is

One.

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 accuracy of 1.2 ms. No

overflow or increment event is provided with this counter.

4.5 RING SCHEDULING

FDDI uses a timed token protocol to schedule 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 (LTCT)

The Late Count is implemented differently than suggested

by the MAC standard, but provides similar information. The

function of the Late Count is divided between the Late

Flag that is equivalent to the MAC standard Late Count with

a non-zero value and a separate counter. Late Flag 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 became non-operational. When the ring is

non-operational, Late Count indicates the time it has taken

(so far) to recover the ring.

Ð

Multiple classes of service can be accommodated by setting

different target token rotation times for each class of serv-

ice.

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.

The Late Count is incremented every time TRT expires

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

every TMAX).

Ð

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-

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.

17

4.0 FDDI MAC Facilities (Continued)

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

3. Termination of a Restricted dialogue:

Capture a Restricted Token

#

Transmit zero or more frames to continue the Restrict-

ed dialogue

#

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.

Issue a Non-Restricted Token to return to the Non-Re-

stricted service class

#

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.

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.

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 to-

kens. This is to ensure that the upper bound on the pres-

ence of a Restricted dialogue in the ring is limited to a single

dialogue.

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.

As suggested by the MAC-2 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 explicitly en-

abled by management software. Since the Claim process

results in the generation of a Non-restricted Token, this pre-

vents stations from initiating another restricted dialogue

without the intervention of management software.

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.5.4 Immediate Service Class

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.

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.

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

4.5.3 Restricted Asynchronous Service Class

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

(Ring Engine)

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 for 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:

Capture a Restricted Token

#

Stations negotiate for TTRT based on their TREQ that is

assigned to them upon initialization.

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

Issue a Restricted Token to allow other stations in the

dialogue to transmit frames

#

18

5.0 Functional Description (Continued)

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

process is invoked.

Required condition becomes true one byte time after TRT

expires (to promote interoperability with less careful imple-

mentations). When TRT expires and the ring is not opera-

tional, TRT is loaded with TMAX. TRT is also loaded with

TMAX on a MAC Reset.

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

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.

traffic is prioritized based on the Late Flag which denotes

Ð

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.

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.

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 can

increment every 80 ns. The Timers are reset by loading

TNEG or TMAX into the counters where TNEG and TMAX

are unsigned two’s complement numbers. This allows a

Carry flag to denote timer expiration.

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.

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.

Ð

The Beacon Process is used for fault isolation. A station

may invoke the Beacon Process through an

SM Control.request(Beacon). When a station enters the

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

these purposes, the token is considered late one byte be-

fore it is actually late (to promote interoperability with less

careful implementations).

Ð

Beacon Process, it continuously sends out Beacon Frames.

The Beacon Process is complete when a station receives its

own Beacon Frame. That station then enters the Claim pro-

cess, to re-initialize the ring.

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.

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

Ð

TMAX and the recovery process (Claim) is invoked (unless

the Inhibit Recovery Required option is set). The Recovery

TL/F/11705–7

FIGURE 5-1. Token Timing Logic

19

5.0 Functional Description (Ring Engine) (Continued)

A Service Opportunity begins when the criteria presented to

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

ed service class (sync, async, async priority, immediate) and

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

none).

TABLE 5-1. Beginning of Service Opportunity

Requested

Token

Requested

Service

Class

Received

Token

Criteria

Capture

Class

During a service opportunity, the Ring Engine guarantees

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

(unless Option.IRPT is set). When data is not ready to be

transmitted, Void frames are transmitted to reset the TVX

timers in all stations. During an immediate request from the

Claim or Beacon state, if the data for external Claim or Bea-

con frame is not ready to be transmitted, the Ring Engine

will transmit Claim or Beacon frames using the same inter-

nal data used for normal Claim and Beacon processing.

l

Asynchronous non-restricted THT THSH non-restricted

e

Priority

Late Flag

Ð

0

e

Ring Op

Ð

1

e

Asynchronous non-restricted Late Flag

Ð

0 non-restricted

0 restricted

any

e

Ring Op

Ð

1

e

Asynchronous restricted

Synchronous any

Late Flag

Ð

Ring Op

Ð

e

1

5.2.1 Service Opportunity while Ring Operational

Beginning of Service Opportunity

e

Ring Op

Ð

1

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.

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

valid token is received in order to begin a service opportuni-

ty when the ring is operational.

In addition to the criteria mentioned above, additional crite-

ria apply to the servicing of Synchronous and Restricted

Requests.

The type of token issued depends on the service class and

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

Synchronous Requests are not serviced if

e

#

5.2.2 Service Opportunity While Ring Not Operational

RELR.BCNR

1 (see Section 4.5.1).

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

curs if an immediate transmission is requested from the

transmitter Data, Claim or Beacon state, and the transmitter

is in the appropriate state.

Restricted requests are not serviced when

e

#

RELR.MACR

1. (see Section 4.5.3).

Restricted Dialogues may only begin when a non-restrict-

ed token has been received and transmitted (see Section

4.5.3).

The service opportunity continues until any one of the fol-

lowing conditions exist:

1. No (additional) frames are to be sent

2. Time TMAX elapses on this request

3. The transmitter exits the requested state

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:

4. The ring becomes operational while servicing an immedi-

ate request

1. It is no longer necessary to hold the token

5.2.3 Frame Transmission

All frames of all active requests have been transmitted

#

2. The token became unusable while servicing a request

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 band-

width and should be used judiciously.

Asynchronous Priority threshold reached (if an Async

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 being present:

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.

A MAC Reset

#

Reception of a valid MAC frame

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

tured)

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.

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.

Several errors can occur during a transmission. 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

20

5.0 Functional Description (Ring Engine) (Continued)

transmission is aborted due to an external error (and

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

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

aborted due to a transmission error, the service opportunity

is not automatically ended.

place of the MSA or MLA. The SAT option can be invoked

on a Request Object via the Request Configuration parame-

ters of the System Interface.

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

sary to rely on an alternate stripping mechanism since strip-

ping 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 external hard-

5.3 REQUEST SERVICE PARAMETERS

5.3.1 Request Service Class

ware that forces stripping using the EM (External M Flag)

Ð

signal is required.

The Requested Service corresponds to the Request Serv-

ice Class and the Token Class parameters of the

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

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.

Ð

primitives as specified in the Standard.

TABLE 5-2. Token Transmission Type

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. When SA Transparency is used with

externally generated Beacon Frames that are transmitted

from the Beacon state, the first 4 bytes of the INFO field are

passed transparently from the data stream instead of being

generated by the Ring Engine.

Token

Issued

Service Class

Non-restricted

Captured

Non-restricted Non-restricted

Non-restricted Restricted

Begin Restricted

Continue Restricted

End Restricted

Immediate

Restricted

None

Restricted

Non-restricted

None

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.

Immediate Non-restricted None

Immediate Restricted None

Non-restricted

Restricted

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.

Source Address Most Significant Bit Transparency

Requests are serviced on a Service Opportunity meeting

the requested criteria.

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 through the Request Channel Configura-

tion Registers in the Service Engine.

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-restrict-

ed upon completion of the request. A Token Issue Class of

rstr means that the Transmitter Token Class will be Re-

stricted upon completion of the request.

Unless the Source Address Transparency option is also se-

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

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 use Source Routing. In these applications,

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

when routing information is inserted into the data stream.

This allows the normal stripping to be accomplished in end

stations implementing Source Routing (without relying on

external software to not create no-owner frames).

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 the Ring Engine. The use of Source Address

Transparency has no effect on the sequencing of the inter-

face. 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 present.

Since the FCS is appended to the frame, when FCS trans-

parency is not used, no FCS bytes are present in the re-

quest stream.

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 frame returns (The Second My Void will

Ð

#

Ð

be stripped on the basis of the SA)

Source Address Transparency (SAT)

Normally, the SA field in a frame is generated by the Ring

Engine using either the MSA or MLA values programmed in

the parameter RAM. When the SA Transparency option is

selected, the SA from the data stream is transmitted in

A Token is received

#

An Other Void is received

Ð

A MAC frame other than My Claim is received

Ð

A MAC Reset occurs

21

5.0 Functional Description (Ring Engine) (Continued)

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 at the beginning of a frame trans-

mission.

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.

The receiving stations treat the last four bytes of the data

stream as the FCS.

Void Stripping is also automatically invoked by this station if

it wins the Claim token process before the initial token is

issued. This removes all fragments and ownerless frames

from the ring when the ring becomes operational.

This option may be useful for end to end FCS coverage

when crossing FDDI bridges, for diagnostic purposes, or in

Implementer frames.

5.4 FRAME VALIDITY PROCESSING

FCS Transparency

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.

Normally, the Ring Engine generates and transmits the

FCS. When the Frame Check Sequence Transparency op-

22

5.0 Functional Description (Ring Engine) (Continued)

TABLE 5-3. Request Service Classes

Token

Issue

RQRCLS

Name

Class

THT

Notes

Capture

0000

0001

None

Apri

1

Async

enabled

non-rstr

Ð

THSH1

0010

0011

0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111

Reserved

Sync

Reserved

Sync

disabled

enabled

disabled

any

none

non-rstr

rstr

captured

none

1

4

Imm

Immediate

Async

ImmN

ImmR

Async

Rbeg

non-rstr

rstr

non-rstr

rstr

Restricted

Async

2, 3

2

Rend

non-rstr

rstr

Rcnt

rstr

2

AsynD

RbeginD

RendD

RcntD

non-rstr

rstr

non-rstr

rstr

Restricted

2, 3

2

non-rstr

rstr

2

e

Note 1: Synchronous Requests are not serviced when RELR.BCNR

1.

e

Note 2: Restricted Requests are not serviced when RELR.MACR

1.

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.

On Transmit, 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 aborted 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 maximum al-

lowable length (4500 bytes).

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.

When Option.IRPT is set and SAT and SAIGT are selected

or when Mode.DIAG is set, the minimum frame length is one

data byte.

TABLE 5-4. Valid Frame Length

5.5 FRAME STATUS PROCESSING

Each frame contains three or more Control Indicators. The

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

Short

Long

Address Address

Frame

Types

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.

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

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.

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

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

23

5.0 Functional Description (Ring Engine) (Continued)

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 symbol is

received.

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

Frame Status processing is also a low probability event.

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.

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.

5.5.1 Odd Symbols Handling

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 signals this condition by sending

out the symbol sequence TSII. This indicates the end of

frame for a frame which had an error. Note that this is a low

probability error event.

TABLE 5-5. Control Indicator Processing

Flags

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

Copy

X

0

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

T

1

X

0

1

X

0

1

0

X

0

X

0

R

S

T

1

X

1

S

T

X

0

X

1

R

T

1

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 value of the internal A Flag or the external A Flag as indicated by the EA input signal (when Option.Emind is set).

Ð Ð

Ð

EC represents the value of the External C indicator Input Signal one byte time before then ending delimiter of the frame.

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

N

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.

Ð

X Represents a Don’t Care Condition.

24

5.0 Functional Description (Ring Engine) (Continued)

e

with an SM MA Control.request(Claim) which is accom-

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.

The Tx Claim state is entered (even if Option.IRR

Ð

1)

Ð Ð

plished by setting Function.CLM to 1.

While in the Tx Claim state:

Ð

Claim frames are transmitted continuously

#

5.7 MAC FRAME PROCESSING

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

Ð

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

#

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

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

repeats additional Higher Claim frames.

Ð

If a Lower Claim frame is received, this station contin-

ues to send its own Claim frames and remains in the

Claim state.

Ð

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

and Beacon frames are processed as defined in the MAC

Standard, unless explicitly inhibited by the bits in the Option

Register (e.g., Inhibit Recovery Required).

#

Ð

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-

5.7.1 Claim Token Process

Receive

Ð

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

to establish an Operational ring.

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

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

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

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

Ð

5.7.2 Beacon Process

Receive

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

INFO field is equal to this station’s TREQ.

Ð

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

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

A Higher 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 greater than this station’s

Ð

There are two types of Beacon frames: My Beacon and

Ð

Other Beacon.

Ð

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

Ð

dress that does not match this station address and the

A Beacon frame is considered a My Beacon if its Source

Ð

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

T

TREQ.

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

Ð

A Beacon frame is marked as Other Beacon if its Source

Ð

Address does not match this station’s address.

Transmit

Claim frames are transmitted continuously while in the

Tx Claim State.

Ð

Beacon frames are transmitted continuously while in the

Tx Beacon 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.

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.

For internally generated Claim frames, the Information field

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

tion Time.

For internally generated Beacon frames, the Ring Engine

uses the TBT in the Information field.

Beacon Protocol

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

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

Entry to the Tx Beacon state occurs under two conditions:

Ð

Engine implementation, TREQ is programmable with

20.48 ms resolution and a maximum value of 1.34 seconds.

a

A failed Claim Process (TRT expires during the Claim

process)

#

An SM MA Control.request(Beacon) which is accom-

Ð Ð

plished by setting Function.BCN to 1).

#

Claim Protocol

Entry to the Tx Claim state occurs whenever token recov-

Ð

ery is required. The Recovery Required condition occurs

when:

Beacon frames are then transmitted until the Beacon pro-

cess is completed.

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.

TRT expires and Late Flag is set

Ð

TVX expires

#

A Lower Claim frame or My Beacon frame is received

Ð

#

Entry to the TX Claim state may be blocked by enabling

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

Ð

the Inhibit Recovery Required option (bit Option.IRR).

back its own Beacon frame; thus successfully completing

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

cess.

25

5.0 Functional Description (Ring Engine) (Continued)

5.7.3 Handling Reserved MAC Frames

In addition to servicing an Immediate request from the Tx

Ð

Data State, it is also possible to service Immediate requests

A Reserved MAC frame is any MAC frame aside from Bea-

con and Claim frames. Tokens are not considered MAC

frames even though their Format bit (FC.FF) is the same as

for MAC frames.

from the Tx Claim or Tx Beacon State. When transmit-

Ð

ting from the Claim or Beacon state, in addition to request-

ing an Immediate Transmission Service Class, the RQCLM

or RQBCN signals must be asserted to indicate an Immedi-

ate Claim or Immediate Beacon request. These requests will

only be serviced when in the Claim or Beacon state. Entry to

the Tx Beacon State can be forced by setting bit BCN of

Ð

the Function Register to One. Entry to the Tx Claim State

Ð

can be forced by setting bit CLM of the Function Register to

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.

One.

While in the Tx Claim or Tx Beacon state, the Ring En-

Ð

gine will transmit internally generated Claim or Beacon

frames except when an Immediate Claim or Beacon request

is present at the MA Request Interface, signal RQCLM or

Ð

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.

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.

The SameSA signal is asserted when:

1. The current 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.

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

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

previous non-Void frame.

Ð

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.

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.

5.10 FULL DUPLEX OPERATION

The Same INFO signal is asserted when:

The Ring Engine supports full duplex operation by

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

MAC frames (not necessarily the same FC value).

1. Suspending the Token Management and Token Recov-

ery protocols (set Option.IRR).

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.

2. Inhibiting the repetition of all frames and tokens (set Op-

tion.IRPT).

3. Using the Immediate Service Class.

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

Frames of any size may be transmitted or received, subject

to the minimum length specified in Section 5.4.

5.9 IMMEDIATE FRAME TRANSMISSION

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

useful in full duplex applications. Immediate requests are

5.11 PARITY PROCESSING

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 Ring Engine (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.

serviced only when the station’s Ring Operational flag is

Ð

e

Zero (CTSR.ROP

0).

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

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

by the Ring Engine for its outputs may be ignored. For the

Ring Engine’s inputs, the result of the parity check is used

only if parity on that Interface is enabled.

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

Ð

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

comes non-operational as a result of a MAC Reset (Func-

tion.MCRST is set to One) or any of the conditions causing

the Reset or Recovery Actions to be performed.

Interface parity is enabled by setting the appropriate bit in

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

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

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

parity on all interfaces.

26

6.1.1 Indicate Machine

5.0 Functional Description

(Ring Engine) ^(Continued)

On the Receive side (from the ring) the Indicate Machine

sequences through the incoming byte stream from the Ring

Engine. Received frames are sorted onto Indicate Channels

and a decision is made whether or not to copy them to host

memory. The Indicate Machine uses the control signals pro-

vided by the Ring Engine Receive State Machine on the

MAC Indicate Interface to make this decision.

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). Odd parity is always gen-

erated for PRP. This allows through parity support at the

PHY interface even if parity is not used at the MAC inter-

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

6.1.2 Request Machine

On the Transmit side (to the ring) the Request Machine pre-

pares one or more frames from host memory for transmis-

sion to the Ring Engine. The Request Machine provides all

the control signals to drive the Ring Engine Request Inter-

face.

Through parity is not supported in the Control Interface Reg-

isters and the Parameter RAM. Parity is generated and

stripped at the Control Interface.

6.2 OPERATION

Handling Parity Errors

6.2.1 Indicate Operation

Parity errors are reported in the Exception Status Register

when parity on that interface is enabled.

The Indicate Block accepts data from the Ring Engine as a

byte stream.

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 token or frame reception, the

token or frame is stripped, a Format Error is signalled

(FOERROR) and the Lost Count is incremented.

Upon receiving the data, the Indicate Block performs the

following functions:

Decodes the Frame Control field to determine the frame

type

#

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.

Sorts the received frames onto Channels according to

the Sort Mode

#

Optionally Filters identical MAC frames

#

Filters Void frames

Copies the received frames to memory according to

Copy Criteria

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.

Writes status for the received frames to the Indicate

Status Queue

#

Issues interrupts to the host on host-defined status

breakpoints

#

5.12 HANDLING INTERNAL ERRORS

The Indicate Machine decodes the Frame Control (FC) field

to determine the type of frame. The following types of

frames are recognized: Logical Link Control (LLC), Restrict-

ed Token, Unrestricted Token, Reserved, Station Manage-

ment (SMT), SMT Next Station Addressing, MAC Beacon,

MAC Claim, Other MAC, and Implementer.

Errors internal to the Ring Engine cause a MAC Reset. This

includes detecting illegal states in the state machines. Inter-

nal Errors are reported in the Internal Error Latch Register

(IELR). After an internal state machine error is detected and

reported

(IELR.RSMERR

for

the

receiver

and

IELR.TSMERR for the transmitter), the current state regis-

ters continue to be updated as always.

The Indicate Machine sorts incoming frames onto Indicate

Channels according to the frame’s FC field, the state of the

AFLAG signal from the Ring Engine (which indicates that

the MACSI device had an internal address match), and the

host-defined sorting mode programmed in the Sort Mode

field of the Indicate Mode Register. SMT and MAC frames

are always sorted onto Indicate Channel 0. On Indicate

Channels 1 and 2, frames can be sorted according to

whether they are synchronous or asynchronous, or whether

they are high-priority asynchronous or low-priority asynchro-

nous. Frames can also be sorted by whether their address

matches an internal (MACSI device) or external address, or

based on header and Information fields for all non-MAC/

SMT frames.

In diagnose mode, 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).

6.0 Functional Description

(Service Engine)

6.1 OVERVIEW

The Service Engine consists of two major blocks: the Indi-

cate Machine and the Request Machine. These blocks

share the Bus Interface Unit, Status/Space Machine, Point-

er RAM, and Limit RAM blocks.

The Synchronous/Asynchronous Sort Mode is intended for

use in end-stations or applications using synchronous trans-

mission.

The Service Engine provides an interface between the Ring

Engine FDDI Media Access Control Protocol block and a

host system. The Service Engine transfers FDDI frames be-

tween the FDDI device and host memory.

27

6.0 Functional Description (Service Engine) (Continued)

Byte 0

Byte 3

Bit 0

With High-priority/Low-priority sorting, high-priority asyn-

chronous frames are sorted onto Indicate Channel 1 and

Bit 31

Big Endian Indicate Data Unit Format

low-priority asynchronous frames are sorted onto Indicate

Channel 2. The most-significant bit of the three-bit priority

field within the FC field determines the priority. This Mode is

intended for end stations using two priority levels of asyn-

chronous transmission. Synchronous frames are sorted to

Indicate Channel 1 in this mode.

FC

DA0

FC

SA1

DA1

SA0

Byte 3

Bit 0

Byte 0

Bit 31

Little Endian Indicate Data Unit Format

With External/Internal sorting, frames matching the internal

address (Individual or Group addresses in the MACSI de-

vice) are sorted onto Indicate Channel 1 and frames match-

ing an external address (when the ECOPY input is asserted)

are sorted onto Indicate Channel 2. Note that under some

conditions it is possible to sort internal address match and

SMT/MAC frames to Indicate Channel 2. Please see Sec-

tion 6.3 for full details on the External Matching Interface.

This sort mode is intended for bridges or ring monitors,

which would use the ECIP/ECOPY/EM pins with external

address matching circuitry. However, designers should be

aware of the functioning of the ECIP pin even if external

matching will not be used. If ECIP is left in an improper state

(e.g., floating or tied high), it will affect the operation of the

MACSI device even when External/Internal sorting is not

enabled.

FC

DA0

SA1

SA0

DA1

FIGURE 6-1. Indicate Data Unit Formats

(Short Address)

For each Input Data Unit, the Indicate Machine creates an

Input Data Unit Descriptor (IDUD), which contains status in-

formation about the IDU, its size (byte count), and its loca-

tion in memory. For IDUs that fit within the current Indicate

memory page, an IDUD.Only Descriptor is created. For IDUs

that span more than one memory page, a multi-part IDUD is

created. For example, when a frame crosses a page bound-

ary, the MACSI device writes an IDUD.First. If another page

is crossed, an IDUD.Middle will be written. At the frame end,

an IDUD.Last is written. IDUDs are written to consecutive

locations in the Indicate Status Queue for the particular Indi-

cate Channel, up to the host-defined queue limit.

With the Header/Info Sort Mode, Indicate Channels 1 and 2

receive all non-MAC/SMT frames that are to be copied, but

between them split the frame header (whose length is user-

defined) and the remaining portions of the frame (Info). Indi-

cate Channel 1 copies the initial bytes up until the host-de-

fined header length is reached. The remainder of the

frame’s bytes are copied onto Indicate Channel 2. Only one

IDUD stream is produced (on Indicate Channel 1), but both

Pool Space Pointer (PSP) Queues are used to determine

where the IDUs will be written. When a multi-part IDUD is

produced, the Indicate Status field is used to determine

which parts point to the header and which point to the Info.

This Mode is intended for high-performance protocol pro-

cessing applications.

The MACSI device has two modes for storing IDUs into Pool

Space Pages. In the first mode, the MACSI device will as-

semble as many frames into a 4 kByte page as will fit. Thus,

a single page of Pool Space memory may contain multiple

frames and have many IDUDs pointing to it. In the second

mode, the MACSI device forces a page break after the end

of each frame. This means that a single page of Pool Space

memory will have at most a single IDUD pointing to it. This

mode greatly simplifies space reclamation in those systems

which do not process incoming frames in order of receipt

and supports systems in which the cache line size is greater

than 32 bytes.

The Indicate Machine filters identical MAC and SMT frames

when the SKIP bit in the Indicate Mode Register is set and

the Indicate Configuration Register’s Copy Control field (2

bits) for Indicate Channel 0 is set to 01 or 10.

The Indicate Machine copies IDUs and IDUDs to memory as

long as there are no exceptions or errors and the Channel

has data and status space. When a lack of either data or

status space is detected on a particular Channel, the Indi-

cate Machine stops copying new frames for that Channel

(only). It will set the No Status Space attention bit in the No

Space Attention Register when it runs out of Status Space.

It will set the Low Data Space bit in the No Space Attention

Register when the last available PSP is prefetched from the

Indicate Channel PSP Queue. The host allocates more data

space by adding PSPs to the tail of the PSP Queue and then

updating the PSP Queue Limit Register, which causes the

MACSI device to clear the Low Data Space attention bit and

resume copying (on the same Channel). The user should

never clear the Low Data Space attention bits directly. The

host allocates more status space by updating the IDUD

Queue Limit Register and then explicitly clearing the Chan-

nel’s No Status Space bit, after which the Indicate Machine

resumes copying. Note that the No Status Space Attention

bit must be cleared after the appropriate limit register is

updated.

Received frames are copied to memory based on the

AFLAG, MFLAG, ECIP, ECOPY, and EM input signals from

external address matching logic, control signals from the

Ring Engine, as well as the Indicate Channel’s Copy Control

field. Received frames are written as a series of Input Data

Units to the current Indicate memory page defined by the

host via a PSP. Each frame is aligned to the start of a cur-

rently-defined burst-size memory block (16 or 32 bytes as

programmed in the Mode Register’s SMLB bit). The first

word written contains four copies of the FC byte. The IDUD

pointer points to the last FC byte so that host software sees

only a single FC byte as expected. The extra FC bytes have

the advantage of causing the INFO field to be aligned to a

32-bit word boundary. The format differs according to the

setting of the Mode Register’s BIGEND (Big Endian) bit, as

shown in Figure 6-1.

28

6.0 Functional Description (Service Engine) (Continued)

The MACSI device provides the ability to group incoming

frames and then generate interrupts (via attentions) at

group boundaries. To group incoming frames, the MACSI

device defines status breakpoints, which identify the end of

a group (burst) of related frames. Status breakpoints can be

enabled to generate an attention.

Descriptor is not the end (Last bit not set), the Request

Machine will fetch subsequent Descriptors until it detects

the end and then resume processing with the next Descrip-

tor.First or Descriptor.Only.

Requests are processed on both Request Channels simul-

taneously. Their interaction is determined by their priorities

(Request Channel 0 has higher priority than Request Chan-

nel 1) and the Hold and Preempt/Prestage bits in the Re-

quest Channel’s Request Configuration Register. An active

Request Channel 0 is always serviced first, and may be pro-

grammed to preempt Request Channel 1, such that uncom-

mitted Request Channel 1’s data already in the request

FIFO will be purged and then refetched after servicing Re-

quest Channel 0. When prestaging is enabled, the next

frame is staged before the token arrives. Prestaging is al-

ways enabled for Request Channel 0, and is a programma-

ble option on Request Channel 1. The MACSI device will

process at most one Request per Channel per Service Op-

portunity.

The breakpoints for Indicate Channels are defined by the

host in the Indicate Mode, Indicate Notify, and Indicate

Threshold registers. Status breakpoints include Channel

change, receipt of a token, SA change, DA change, MAC

Info change, or a user-specified number of frames have

been copied on a particular Indicate Channel.

Status breakpoint generation may be individually enabled

for Indicate Channels 1 and 2 by setting the corresponding

Breakpoint bits (Breakpoint on Burst End, Breakpoint on

Service Opportunity, and Breakpoint on Threshold) in the

Indicate Mode Register, and enabling the breakpoints to

generate an attention by setting the corresponding Break-

point bit in the Indicate Notify Register.

The MACSI device contains an option bit which controls the

timing of Token capture. This bit is the Early Token Request

bit (ETR) which is in R0CR1 (for Request Channel 0) and

R1CR1 (for Request Channel 1). When the ETR bit is dis-

abled for a channel, the MACSI device will fetch a Request

descriptor and then fetch the first ODUD and begin filling

the transmit FIFO for that channel. When the FIFO thresh-

old is reached (R0CR0.TT or R1CR0.TT) the MACSI device

presents a Request Class to the Ring Engine which causes

the Ring Engine to capture a Token of the specified class.

When an Indicate exception occurs, the current frame is

marked complete, status is written into an IDUD.Last, and

the Channel’s Exception (EXC) bit in the Indicate Attention

Register is set.

When an Indicate error (other than a parity error) is detect-

ed, the Error (ERR) bit in the State Attention Register is set.

The host must reset the INSTOP Attention bit to restart pro-

cessing.

When parity checking is enabled and a parity error is detect-

ed in a received frame, it is recorded in the Indicate Status

field of the IDUD, and the Ring Engine Parity Error (REPE)

bit in the Status Attention Register is set.

When the ETR bit is enabled, a REQ.First is loaded, the

Request Machine commands the Ring Engine to capture a

token of the type specified in the REQ Descriptor, and con-

currently fetches the first ODUD. This mode is useful for

systems which need tight control of the Token capture tim-

ing (e.g., systems using Synchronous traffic). Note that use

of the Early Token Request mechanism may, under certain

circumstances, waste ring bandwidth (i.e., holding the To-

ken while filling the FIFO). Therefore, it should be enabled

only in those systems where the feature is specifically re-

quired.

A frame which is stripped after the fourth byte of the Infor-

mation Field (this may occur because an upstream station

detected an error within the frame) will be copied to memory

but the status will show that the frame was stripped.

6.2.2 Request Operation

The Request Block transmits frames from host memory to

the Ring Engine. Data is presented to the Ring Engine as a

byte stream.

If prestaging is enabled or a Service Opportunity exists for

this Request Channel, data from the first ODU is loaded into

the Request FIFO, and the MACSI device requests trans-

mission from the Ring Engine. When the Ring Engine has

captured the appropriate token and the frame is committed

to transmission (the FIFO threshold has been reached or

the end of the frame is in the FIFO), transmission begins.

The MACSI device fetches the next ODUD and starts load-

ing the ODUs of the next frame into the FIFO. This contin-

ues (across multiple service opportunities if required) until

all frames for that Request have been transmitted (i.e., an

REQ.ONLY or an REQ.LAST is detected) or an exception or

error occurs which prematurely ends the Request.

The Request Block performs the following functions:

Prioritizes active requests to transmit frames

#

Requests the Ring Engine to obtain a token

#

Transmits frames to the Ring Engine

#

Writes status for transmitted and returning frames

#

Issues interrupts to the host on user-defined group

boundaries

#

The Request Machine processes requests by first reading

Request Descriptors from the REQ Queue and then assem-

bling frames of the specified service class, Frame Control

(FC) and expected status for transmission to the Ring En-

gine. Request and ODUD Descriptors are checked for con-

sistency and the Request Class is checked for compatibility

with the current ring state. When an inconsistency or incom-

patibility is detected, the request is aborted.

The MACSI device will load REQ Descriptors as long as the

RQSTOP bit in the State Attention Register is Zero, the

REQ Queue contains valid entries (the REQ Queue Pointer

Register does not exceed the REQ Queue Limit Register),

and there is space in the CNF Queue (the MACSI device

has not detected equality of the CNF Queue Pointer Regis-

ter and the CNF Queue Limit Register).

When a consistency failure occurs, the Request is terminat-

ed and a Confirmation Descriptor (CNF) with the appropriate

status is generated. The Request Machine then locates the

end of the current object (REQ or ODUD). If the current

29

6.0 Functional Description (Service Engine) (Continued)

Request status is generated as a single confirmation object

(single- or multi-part) per Request object, with each confir-

mation object consisting of one or more CNF Descriptors.

The type of confirmation is specified by the host in the Con-

firmation Class field of the REQ Descriptor.

When a non-matching frame is received, the MACSI device

ends the Request, and generates the Request Complete

(RCM), Exception (EXC), and Breakpoint (BRK) attentions.

Any remaining REQs in the Request object are fetched until

a REQ.Last or REQ.Only is encountered. Processing then

resumes on the next REQ.First or REQ.Only (any other type

of REQ would be a consistency failure).

The MACSI device can be programmed to generate CNF

Descriptors at the end of the Request object (End Confirma-

tion), or at the end of each token opportunity (Intermediate

Confirmation), as selected in the E and I bits of the Confir-

mation Class Field of the REQ Descriptor. A CNF Descriptor

is always written when an exception or error occurs (regard-

less of the value in the Confirmation Class field), when a

Request is completed (for End or Intermediate Confirmation

Class), or when a Service Opportunity ends (Intermediate

Confirmation Class only).

Request errors and exceptions are reported in the State

Attention Register, Request Attention Register, and the

Confirmation Message Descriptor. When an exception or er-

ror occurs, the Request Machine generates a CNF and

ends the Request. The Unserviceable Request (USR) atten-

tion is set to block subsequent Requests once one be-

comes unserviceable.

6.2.3 State Machines

There are three basic types of confirmation: Transmitter,

Full, and None. With Transmitter Confirmation, the MACSI

device verifies that the Output Data Units were successfully

transmitted. With Full Confirmation, the Request Machine

verifies that the ODUs were successfully transmitted, that

the number of (returning) frames ‘‘matches’’ the number of

transmitted ODUs, and that the returning frames contain the

expected status. Full confirmation takes advantage of the

fact that the sending station also removes its frames from

the network. When the None Confirmation Class is select-

ed, confirmation is written only if an exception or error oc-

curs.

There are three state machines under control of the host:

the Request Machine, the Indicate Machine, and the

Status/Space Machine. Each Machine has two Modes:

Stop and Run. The Mode is determined by the setting of the

Machine’s corresponding STOP bit in the State Attention

Register. The STOP bits are set by the MACSI device when

an error occurs or may be set by the user to place the state

machine in Stop Mode.

The MACSI device Control Registers may be programmed

only when all Machines are in Stop Mode. When the Status/

Space Machine is in Stop Mode, only the Pointer RAM and

Limit RAM Registers may be programmed. When the Indi-

cate and Request Machines are in Stop Mode, all indicate

and request operations are halted. When the Status/Space

Machine is in Stop Mode, only the PTOP and LMOP service

functions can be performed.

For Full Confirmation, a matching frame must meet the fol-

lowing criteria:

1. The frame has a valid Ending Delimiter (ED).

2. The selected bits in the FC fields of the transmitted and

received frames are equal (the selected bits are speci-

fied in the FCT bit of the Request Configuration Regis-

ter).

6.3 EXTERNAL MATCHING INTERFACE

This interface consists of five pins (six on MACSI revision D

or later) that give the MACSI device additional status re-

garding address matches. Typical applications for this inter-

face include address matching for Bridge and Router devic-

es. The five pins include four inputs (ECIP, ECOPY, EA, and

EM) and one output (LEARN). MACSI revisions D or later

have an additional input pin (AFINHIB). ECIP provides tim-

ing information to the Sytem Interface. ECOPY and EM pro-

vide status to the System Interface on external Destination

and Source address matches respectively (most applica-

tions use ECOPY only). The Ring Engine uses EA and EM

for setting the A Indicator and frame stripping.

3. The frame is My SA (MFLAG or both SAT & EM assert-

Ð

ed).

4. The frame status indicators match the values in the Ex-

pected Frame Status Register.

5. FCS checking is disabled or FCS checking is enabled

and the frame has a valid FCS.

6. All bytes from FC to ED have good parity (when the

FLOW bit in the Mode Register is set, i.e., parity checking

is enabled).

The confirmed frame count starts after the first Request

burst frame has been committed by the Ring Engine, and

when a frame with My SA is received. Void and My Void

For the purposes of external matching, it is recommended

a

that the frame data be viewed at the PLAYER /MACSI

l

Ð

k

Receive interface, (PID 7:0 , PIP, PIC). In addition it is

recommended that the user design the circuit to detect the

frames are ignored by the MACSI device. The frame count

ends when any of the following conditions occur:

a

JK symbol at the MACSI/PLAYER interface to start ad-

dress matching.

1. All frames have been transmitted, and the transmitted

and confirmed frame counts are equal.

To instruct the MACSI device to copy a frame, the proper

use of the ECIP, ECOPY, and EM pins is as follows. Exter-

nal address matching circuitry must assert ECIP some time

from the arrival of the start delimiter (JK) to the 6th byte of

2. There is a MACRST (MAC Reset).

3. The state of the ring-operation has changed.

4. A stripped frame or a frame with a parity error is re-

ceived.

a

the INFO field (as measured at the PLAYER /MACSI inter-

face). Otherwise, the MACSI device assumes that no exter-

nal address comparison is taking place. ECIP must be nega-

ted for at least one cycle to complete the external compari-

son. If it has not been deasserted by the 2nd byte after the

End Delimiter (ED), the frame is not copied. ECOPY and EM

are sampled on the clock cycle after ECIP is negated. ECIP

is ignored after it is negated until the arrival of the next JK.

5. A non-matching frame is received.

6. A token is received.

When Source Address Transparency is selected (by setting

the SAT bit in the Request Configuration Register) and Full

confirmation is enabled, confirmation begins when a frame

end is detected with either MFLAG or EM asserted.

30

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–8

FIGURE 6-2. MACSI Device External Matching Interface Timing

Note that this design allows ECIP to be a positive or nega-

tive pulse. To confirm frames in this mode, (typically with

Source Address Transparency enabled), EM must be as-

serted within the same timeframe as ECOPY.

MACSI device will not sample it during these earlier periods.

T1’s timing is fixed as the fourth cycle following the FC data

a

byte at the PLAYER /MACSI interface.

T2 is the earliest cycle where the deassertion of ECIP will be

recognized. This can occur as soon as one cycle following

ECIP’s assertion. ECIP needs to be asserted for a minimum

of one full clock cycle.

The Ring Engine samples EA two byte-times after the end

a

delimiter (ED) is passed between the PLAYER device and

the MACSI device. If EA is asserted, the MACSI device will

transmit the A Indicator as an S. The Ring Engine samples

EM continuously and will begin to strip a frame three byte-

times after the assertion of EM. This implies that the user

must ground EM if not used. The Ring Engine does not use

the ECIP timing signal.

T3 is the latest cycle where the initial assertion of ECIP will

still be recognized. T3 must occur before the 6th byte of the

INFO field, not afterward. If ECIP is asserted later than this

cycle, an external match will not be recognized; i.e., the

frame will be copied only if it is an internal match. When

ECIP is not asserted until after T3, it is not recognized. This

is the only case where maintaining ECIP’s assertion during

the frame will have no effect at all.

It is important to note that ECIP functions as an indicator to

the internal MACSI device Indicate Machine to hold off the

copying of incoming data until the ECIP line is negated.

Therefore, even if a design does not intend to take advan-

tage of the MACSI device External Address Matching inter-

face, the user must still ensure that the ECIP signal line is

properly negated. Also important is the fact that the MACSI

device samples the ECIP signal line in order to detect just

two conditions. It looks at whether ECIP is asserted at any

time during the period between the start delimiter (JK) and

the 6th byte of the INFO field and then waits until the deas-

sertion of ECIP, at which point the MACSI device samples

the ECOPY and EM signal lines for their status on this par-

ticular frame.

T4 is the latest cycle where the deassertion of ECIP will be

recognized in ‘‘regular’’ fashion. That is, if ECIP is held as-

serted beyond T4, a special case is created within the MAC-

SI device when the external compare has persisted to the

point where it takes precedence over all other copy modes.

In this case, all frames which are copied, regardless of

whether it was an external match, internal match, or SMT

frame, are copied to ICHN2. Note that even if an internal

match has already occurred, ECIP must still become deas-

serted for the frame copy to complete.

It is important to note that the timing shown for T4 is depen-

dent on the setting of the SMLB bit of the MACSI device’s

System Interface Mode Register 0 (SIMR0). The timing

shown in Figure 6-2 is for frame copies in small-burst mode

only. T4 signifies the boundary condition internal to the

MACSI device where the first full burst of data has been

received. The ABus write access for this data will then auto-

matically default to ICHN2 if an external copy decision is still

pending, regardless of sort mode. When the SMLB bit is

not set, i.e., in large burst mode, T4 would occur 16 cycles

later than shown in Figure 6-2.

In the timing diagram (see Figure 6-2 ), the specific cycles

shown for the assertion and deassertion of ECIP comprise

only one possible valid timing. Other timings are valid as

well, within the limits of the timing parameters to be de-

scribed below. Shaded areas indicate cycles where the

MACSI device is not sampling the signal lines for this partic-

ular pattern. Note that the sampling of ECIP is level sensi-

tive and synchronous with LBC1.

Note that there are five timing parameters (T1–T5). T1 and

T3 are limits as to when the initial assertion of ECIP will be

recognized. Once ECIP is asserted, T2, T4, and T5 become

timing limits on the deassertion of ECIP. Once deasserted,

ECIP is not sampled further (until the start of the next

frame).

T5 is the final cycle where the deassertion of ECIP can be

recognized, and it occurs two cycles after the end delimiter

a

(ED) is transferred between the PLAYER and MACSI de-

vices. If ECIP is held high beyond this point, the frame will

not be copied at all, even if an internal match occurred.

Note that this is true even if Internal/External sorting is not

T1 is the earliest cycle where the assertion of ECIP will be

recognized. ECIP may be asserted earlier than this but the

31

6.0 Functional Description (Service Engine) (Continued)

enabled. Therefore, for applications which do not use exter-

nal address matching, ECIP should be tied low. Note also

that if ECIP remains asserted to the point where the incom-

ing frame data completely fills the MACSI device’s Indicate

Data FIFO (4608 bytes for a MACSI device), then the frame

will be dropped due to a FIFO overrun.

The AFLAG Inhibit (AFINHIB, available on MACSI revision D

and later) allows the User to suppress the internal Address

matching signal between the MAC and System Interface.

The MACSI will ignore the AFINHIB pin until the User sets

the AFLAG Inhibit Enable bit of the MAC Mode Register 2

(MCMR2.AFIE). To block an internal address match, the

User must assert the AFINHIB input before the 7th byte of

the INFO field as measured at the PID interface.

The LEARN pin provides MAC state machine information

and ring state information useful for building learning bridg-

es. The Receive logic of a bridge may wish to avoid copying

frames or learning the source address of frames put on the

ring by this same bridge. However, use of the Source Ad-

dress Transparency option (SAT) can make recognition of

frames sourced by this bridge difficult. The LEARN pin pro-

Normally, internal matches take precedence over external

matches. The User might use AFINHIB to defeat this prece-

dence and steer a frame that matches both an internal and

external address to the external sort channel. This pin also

provides an easy mechanism for suppressing the matching

of broadcast (and multicast) frames during bridging. For

these applications the User may connect the LEARN pin

directly to the AFINHIB pin. This will prevent internal ad-

vides a mechanism for the bridge to determine which

frames and addresses it should copy/learn.

The MACSI device deasserts the LEARN pin under the fol-

lowing conditions:

dress matches of any frame during My Void stripping.

Ð

1. Ring Non-Operational. The MACSI device will deassert

the LEARN pin whenever the ring is Non-Operational.

6.4 BUS INTERFACE UNIT

6.4.1 Overview

2. The Transmitter is holding the Token. While this station

holds the Token, the only valid frames it should receive

(other than MAC frames which indicate a fault, or no-

owner frames that should be ignored in this case), con-

sist of those frames that this station sent. Therefore, the

MACSI device deasserts the LEARN pin. (Actually, the

MACSI deasserts LEARN whenever the MAC transmitter

is in the ‘‘Repeat’’ state.)

The ABus provides a 32-bit wide synchronous multiplexed

address/data bus for transfers between the host system

and the MACSI device. The ABus uses a bus request/bus

grant protocol that allows multiple bus masters, supports

burst transfers of 16 and 32 bytes, and supports virtual and

physical addressing using fixed-size pages. The MACSI de-

vice is capable of operating directly on the system bus to

main memory or connected to external shared memory.

3. For the duration of ‘‘My Void Stripping’’. The My Void

Ð

All bus signals are synchronized to the master bus clock.

The maximum burst speed is one 32-bit word per clock, but

slower speeds may be accommodated by inserting wait

states. The user may use separate clocks for the ring (FDDI

MAC) and system (ABus) interfaces. The only restriction is

that the ABus clock must be at least as fast as the ring clock

(LBC). It is important to note that all ABus outputs change

and all ABus inputs are sampled on the rising edge of

Stripping mechanism allows the MACSI device to strip

frames from the ring that it sent using Source Address

Transparency. Before releasing the Token, the MACSI

device releases two My Void frames. It continues to

Ð

strip until the Receiver recognizes at least one My Void

Ð

(or other MAC) frame. LEARN will remain low during

My Void stripping.

Ð

4. The Source Address field equals ‘‘My Long Address’’

(MLA). If the internal address matching logic recognizes

the source address of the incoming frame as its own, the

MACSI device will deassert the LEARN pin.

AB CLK.

Ð

The MACSI device has two major modes of ABus operation.

The default, or ‘‘normal’’ mode, corresponds to the original

BSI device and is completely backward compatible. The

second mode is the Enhanced ABus mode. This mode is

intended to reduce the logic required to interface to the

SBus originally developed by Sun Microsystems, Inc. When

the enhanced mode is selected, the MACSI device timing

and interface signals are modified slightly to create a closer

fit to the SBus. This lowers the cost and eases design of

SBus FDDI adapter cards. This new mode is accessible by

5. Frames using short (16-bit) address. The MACSI deas-

serts the LEARN pin for all frames that use 16-bit ad-

e

dresses (FC.L

48-bit addresses.

0). Learning bridges usually work with

Thus, the MACSI device will only assert LEARN for 48-bit

addressed frames that this station did not source (Source

i

Address

while the ring is Operational.

MLA, and Not My Void stripping) received

Ð

e

1). This

programming a mode bit in a register (MR1.EAM

bit is set to an inactive state upon reset to maintain back-

ward compatibility with the original BSI device.

External logic monitoring the LEARN pin must sample it at

the appropriate point for each received frame. Measured at

a

the MACSI/PLAYER interface (PID), the LEARN pin be-

Addressing Modes

comes valid at the 4th byte of the Information Field (INFO3).

External logic may sample this pin at INFO3 or later.

In the default ABus mode, The Bus Interface Unit has two

Address Modes, as selected by the user: Physical Address

Mode and Virtual Address Mode. In Physical Address Mode,

the MACSI device emits the memory address and immedi-

ately begins transferring the data. In Virtual Address Mode,

the MACSI device inserts two clock cycles and

The MACSI device may or may not assert the LEARN pin at

the beginning of a frame (for the reasons given above) and

LEARN may change state up to INFO3 at the PID interface.

Normally, LEARN will remain stable during the body of a

frame (up to the End Delimiter). However, a MAC Reset, a

Master Reset, etc., may cause the MACSI to deassert the

LEARN pin anywhere within a frame. The Designer should

account for these exceptions when designing any logic that

relies on the LEARN pin.

TRI-STATE the address between emitting the virtual ad-

É

dress and starting to transfer the data. This allows virtual-to-

physical address translation by an external memory map-

ping unit (MMU).

32

6.0 Functional Description (Service Engine) (Continued)

The MACSI device has a mode for controlling the ABus Ad-

dress Strobe (AB AS). In the default mode, AB AS is

A Function Code identifying the type of transaction is output

by the MACSI device on the upper four address bits during

the address phase of a data transfer. This can be used for

more elaborate external addressing schemes such as di-

recting control information to one memory and data to an-

other (e.g., an external FIFO).

Ð Ð

driven active during the address cycle and remains low

e

throughout the access. In the second mode (SIMR1.ASM

1), AB AS is driven active during the address cycle and

Ð

driven inactive during the remainder of the access. This al-

lows AB AS to be used directly as a clock enable to the

Ð

address latching device which reduces the number of exter-

nal components.

Byte Ordering

The basic addressable unit is a byte so request data may be

aligned to any byte boundary in memory. All information is

accessed in 32-bit words, however, so the MACSI device

ignores unused bytes when reading.

In Enhanced ABus Mode (EAM), the MACSI device has

fixed address timing which is similar to the Physical address

timing described above. The SBus MMU does not require

extra cycles for the address translation.

Descriptors must always be aligned to a 32-bit word address

boundary. Input Data Units are always aligned to a burst-

size boundary. Output Data Units may be any number of

bytes, aligned to any byte-address boundary but operate

most efficiently when aligned to a burst-size boundary. Pool

Space Descriptors (PSPs) must point to a burst boundary or

the Receive data will not be written to memory correctly.

The MACSI device interfaces to byte-addressable memory,

but always transfers information in words. The MACSI de-

vice uses a word width of 32 data bits plus 4 (1 per byte)

parity bits. Parity may be ignored.

Bus Transfers

The ABus supports single word accesses and 4-word and

8-word bursts. Simple reads and writes involve a single ad-

dress and data transfer. Burst reads and writes involve a

single address transfer followed by multiple data transfers.

Burst sizes are selected dynamically by the MACSI device.

The user can disable 8-word bursts by setting MR0.SMLB to

a 1. This forces the MACSI device to use 1-word and 4-word

transactions only.

Burst transfers are always word-aligned on a 16- or 32-byte

(burst-size) address boundary. Burst transfers will never

cross a burst-size boundary. If a 32-byte transfer size is en-

e

abled (MR0.SMLB

0), the MACSI device will perform

both 16-byte and 32-byte bursts, whichever is most efficient

(least number of clocks to load/store all required data). If

the MACSI device has less than a full burst of data to com-

plete a frame, it will write a full burst. Random data is written

to the unused locations. The host uses the IDUD length field

to determine where the valid data bytes end.

The MACSI device provides the full de-multiplexed address

during an access. This includes the word address for each

[

]

word of a burst (AB A 4:2 ). To use the de-multiplexed

A 4:2 ) on MACSI revisions A, B, or C, the

The Bus Interface Unit can operate in either Big Endian or

Little Endian Mode. The bit and byte alignments for both

modes are shown in Figure 6-3. Byte 0 is the first byte re-

ceived from the ring or transmitted to the ring. This mode

affects the placement of frame data bytes but it does not

affect the order of Descriptor bytes.

Ð

[ ]

addresses (AB

Ð

Address Timing Mode bit (SIMR1.ATM) must be set equal to

one. This causes the word address to come out in the same

cycle as the word of data being accessed. The word ad-

[

dresses signals (AB A 4:2 ) may be used in the ‘‘look-

ahead’’ mode (SIMR1.ATM

]

Ð

e

0) if the user does address

Big-Endian Byte Order

[

]

de-multiplexing externally by latching AB A 27:5 external-

ly during the address cycle. For MACSI revisions D or later

Ð

[

D 31

]

[ ]

D 0

t

(SI revision

dress Timing Mode (SIMR1.ATM

0x00000058), the User may select either Ad-

e

Word

0 or 1) while using the

]

Halfword 0

Halfword 1

[

demultiplexed address pins AB A 27:0 .

Ð

Byte 0

Byte 1

Byte 2

Byte 3

On Indicate Channels, when 8-word bursts are enabled, all

transactions will be 8 words until the end of the frame; the

last transfer will be 4 or 8 words, depending on the number

of remaining bytes. If only 4-word bursts are allowed, all

Indicate Data transfers are 4 words.

Little-Endian Byte Order

Word

[

D 31

]

[ ]

D 0

On Request Channels, the MACSI device will use 4- or

8-word bursts to access all data up to the end of the ODU. If

8-word bursts are enabled, the first access will be an 8-word

burst if the ODU begins less than 4 words from the start of

an 8-word burst boundary. If 8-word bursts are not allowed,

or if the ODU begins 4 or more words from the start of an 8-

word burst boundary, a 4-word burst will be used. The

MACSI device will ignore unused bytes if the ODU does not

start on a burst boundary. At the end of an ODU, the MACSI

device will use the smallest transfer size (1, 4, or 8 words)

which completes the ODU read. To coexist in a system that

assumes implicit wrap-around for the addresses within a

burst, the MACSI device never emits a burst that will wrap

the 4- or 8-word boundary.

Halfword 1

Halfword 0

Byte 3

Byte 2

Byte 1

Byte 0

FIGURE 6-3. ABus Byte Orders

Bus Arbitration

The ABus is a multi-master bus, using a simple Bus Re-

quest/Bus Grant protocol that allows an external Bus Arbi-

ter to support any number of bus masters, using any arbitra-

tion scheme (e.g., rotating or fixed priority). The protocol

provides for multiple transactions per tenure and bus master

preemption.

The MACSI device asserts a Bus Request, and assumes

mastership when Bus Grant is asserted. If the MACSI de-

vice has another transaction pending, it will keep Bus Re-

quest asserted, or reassert it before the completion of the

33

6.0 Functional Description (Service Engine) (Continued)

current transaction. Note that Bus Request is guaranteed to

be de-asserted for at least two cycles when MR1.EAM is

enabled. It is a requirement of the SBus specification that

Bus Request be de-asserted between each transaction. If

Bus Grant is (re)asserted before the end of the current

transaction, the MACSI device retains mastership and runs

the next transaction. This process may be repeated indefi-

nitely.

Bandwidth

The ABus supports single reads and writes, and burst reads

and writes. With physical addressing, back-to-back single

reads/writes can take place every four clock cycles. Burst

transactions can transfer 8, 32-bit words (32 bytes) every 11

clock cycles. With a 25 MHz clock this yields a peak band-

width of 72.7 Mbytes/sec.

To allow the bus to operate at high frequency, the protocol

defines all signals to be both asserted and deasserted by

the bus master and slaves. Having a bus device actively

deassert a signal guarantees a high-speed inactive tran-

sition. If this were not defined, external pull-up resistors

would not be able to deassert signals fast enough. The pro-

tocol also reduces contention by avoiding cases where two

bus devices simultaneously drive the same line.

It is important to note that in default ABus mode (MR1.EAM

e

the assertion of Bus Grant. Therefore, the external interface

logic must not remove Bus Grant or latch addresses until a

signal such as Address Strobe is asserted indicating that

the MACSI device has recognized the Bus Grant.

0), the MACSI device may take up to two cycles to detect

If the Bus Arbiter wishes to preempt the MACSI device, it

deasserts Bus Grant. The MACSI device will complete the

current bus transaction, then release the bus. From preemp-

The MACSI device operates synchronously with the ABus

clock. In general, operations will be asynchronous to the

ring, since most applications will use a system bus clock

that is asynchronous to the ring. The MACSI device is de-

signed to interface either directly to the host’s main system

bus or to external shared memory. When interfaced to the

host’s bus, there are two parameters of critical interest: la-

tency and bandwidth.

a

tion to bus release is a maximum of (11 bus clocks

(8 times the number of memory wait states)) bus clocks. For

example, in a 1 wait-state system, the MACSI device will

release the bus within a maximum of 19 bus clocks.

Parity

The state of the FLOW bit in System Interface Mode Regis-

ter 0 (SIMR0.FLOW) controls two MACSI device modes:

one for systems using parity, the other for systems not using

parity.

Data moves between the Request and Indicate Channels

and the ABus via four FIFOs, two in the receive path (Indi-

cate) and two in the transmit path (Request). There are two,

1152 x 36-bit data FIFOs for Indicate and Request data

(4608 byte of data FIFO in each direction). On the ABus

Interface, there are two Burst FIFOs, each containing two

banks of 32 bytes which provide ABus bursting capability.

Regardless of the state of SIMR0.FLOW, the MACSI device

always provides odd parity on ABus address cycles, and

Control Bus read cycles. The MACSI device System Inter-

face does not check data parity on ABus read cycles. The

User may enable checking of read data parity at the Ring

Engine interface by setting the MAC Request Parity bit

(MCMR0.MRP). For MACSI revision D or later, the System

Interface will check parity on descriptor reads (when

The amount of latency covered by the Data FIFO plus one

of the banks of the Burst FIFO must meet the average and

maximum bus latencies of the external memory. With a new

byte every 80 ns from the ring, a 4608 byte FIFO provides

c

e

368.64 ms maximum latency. The two 32

byte burst FIFO in each direction provide an additional

4608

80 ns

e

SIMR0.FLOW

1) and report errors via the STAR.ERR bit.

The ABus data parity, (except for Descriptor data parity

which is generated internally) flows directly from the Ring

Engine interface. If parity checking is enabled within the

5.1 ms of latency.

To assist latency issues, the MACSI device can completely

empty or fill the Burst FIFO in one bus tenure by asserting

Bus Request for multiple transactions. Since one bank of

the Burst FIFO is 8 words deep, if 8-word bursts are en-

abled, that half of the Burst FIFO can be emptied in one

transaction. If the second half of the burst FIFO is also full, it

can be emptied in the same bus tenure by again granting

the bus to the MACSI device.

a

Ring Engine, parity flows up from the PLAYER interface.

If parity checking is disabled within the Ring Engine, good

parity is generated at the Ring Engine/Service Engine inter-

face.

For transmit frame data, the parity from the ABus flows di-

rectly to the Ring Engine interface when SIMR0.FLOW is

asserted. The data integrity across the ABus and through

the Service Engine may be checked by enabling parity

checking within the Ring Engine. If the SIMR0.FLOW bit is

deasserted, the MACSI device will generate good parity at

the transmit data (MR7–0) Ring Engine interface.

The MACSI device may be preempted at any time by remov-

ing Bus Grant, causing the MACSI device to complete the

current transaction and release the bus. There will be a

maximum of 11 clocks (plus any memory wait states) from

preemption to bus release (fewer if 8-word bursts are not

enabled).

When SIMR0.FLOW is enabled, parity is checked on Con-

trol Bus write operations. If a parity error is detected, the

write access is rejected and the STAR.CPE bit is asserted.

When SIMR0.FLOW is disabled Control Bus write parity is

ignored.

6.4.2 Bus States

An ABus Master has eight states: idle (Ti), bus request

(Tbr), virtual address (Tva), MMU translate (Tmmu), physical

address (Tpa), data transfer (Td), wait (Tw) and recovery

(Tr).

When SIMR0.FLOW is enabled, parity is checked on MAC

Indicate interface (receive data from the Ring Engine). If an

error is detected, the STAR.BPE will be asserted and the

IDUD for that frame will carry a status of ‘‘parity error’’.

When SIMR0.FLOW is disabled, the parity bit at the MAC

Indicate interface is ignored.

An ABus Slave has five states: idle (Ti), selected (Ts), data

transfer (Td), wait (Tw), and recovery (Tr).

34

6.0 Functional Description (Service Engine) (Continued)

Master States

Following the Tpa state, the BIU enters the Td state to

transfer data words. Each data transfer may be extended

indefinitely by inserting Tw states. A slave acknowledges by

asserting AB ACK and transferring data in a Td state (cy-

cle). If the slave can drive data at the rate of one word per

clock (in a burst), it keeps AB ACK asserted.

Ð

The Ti state exists when no bus activity is required. The BIU

does not drive any of the bus signals when it is in this state

(all are released). If the BIU requires bus service, it may

assert Bus Request.

Ð

When a transaction occurs, the BIU enters Tbr, asserts Bus

Request, and then waits for Bus Grant to be asserted.

Following the final Td/Tw state, the BIU enters a Tr state to

allow time to turn off or turn around bus transceivers.

The state following Tbr is either Tva or Tpa. In Virtual Ad-

dress Mode, the BIU enters Tva and drives the virtual ad-

dress and size lines onto the bus. In Physical Address

Mode, Tpa occurs next (see Section 6.4.3).

A bus retry request is recognized in any Td/Tw state. The

BIU will go to a Tr state and then rerun the transaction when

it obtains a new Bus Grant. The whole transaction is retried,

i.e., all words of a burst. Additionally, no other transaction

will be attempted before the interrupted one is retried. The

BIU retries indefinitely until either the transaction completes

successfully, or a bus error is signaled.

Following a Tva state is a Tmmu state. During this cycle the

external MMU is performing a translation of the virtual ad-

dress emitted during Tva.

Following a Tmmu state (when using virtual addressing) or a

Tbr state (when using physical addressing), is the Tpa state.

During the Tpa state, the MACSI device drives the read/

write strobes and size signals. In physical address mode, it

also drives AB AD with address. In virtual address mode,

Ð

the MACSI device TRI-STATEs AB BD so the host CPU or

Ð

MMU can drive the address.

Bus errors are recognized in Td/Tw states.

6.4.3 Physical Addressing Bus Transactions

Bus transactions in Physical Address Mode are shown in

Figure 6-4 through Figure 6-7. MACSI device signals are

defined in Section 8.

TL/F/11705–9

FIGURE 6-4. ABus Single Read: Physical AddressingÐ0 w/s, 1 w/s

35

6.0 Functional Description (Service Engine) (Continued)

Single Read

Single Write

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tpa within the next three clocks.

Ð

vice moves to Tpa within the next three clocks.

Tpa: MACSI device drives AB A and AB AD with the ad-

Ð Ð

dress, asserts AB AS, drives AB R/W and AB SIZ 2:0 ,

Tpa: MACSI device drives AB A and AB AD with the ad-

[ ]

dress, asserts AB AS, drives AB R/W and AB SIZ 2:0 ,

Ð Ð Ð

Ð

[

]

and negates AB BR if another transaction is not required.

Ð

and negates AB BR if another transaction is not required.

Ð

Td: MACSI device negates AB AS, asserts AB DEN, and

Ð

Td: MACSI device negates AB AS, asserts AB DEN,

Ð Ð

samples AB ACK and AB ERR. Slave asserts AB ACK,

Ð Ð

drives AB AD with the write data and starts sampling

Ð

drives AB ERR, drives AB AD (with data) when ready.

Ð

AB ACK and AB ERR. Slave captures AB AD data, as-

Ð Ð

The MACSI device samples a valid AB ACK, capturing the

Ð

Ð Ð

Ð

serts AB ACK, and drives AB ERR. Tw states may occur

Ð

read data. Tw states may occur after Td.

after Td if the slave deasserts AB ACK.

Ð

Tr: MACSI device negates AB R/W, AB DEN, and

Ð

[

]

AB SIZ 2:0 , and releases AB

deasserts AB ACK and AB ERR, and releases AB AD.

[ ]

AB SIZ 2:0 , and releases AB A, AB AD, and AB AS.

Ð Ð Ð Ð

A

and AB AS. Slave

Ð

Slave deasserts AB ACK and AB ERR and stops driving

Ð

Ð Ð

AB AD with data.

Ð

TL/F/11705–10

FIGURE 6-5. ABus Single Write: Physical AddressingÐ0 w/s, 1 w/s

36

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–11

FIGURE 6-6. ABus Burst Read: Physical AddressingÐ16 Bytes, 1 w/s

Burst Read

Burst Write

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tpa within the next three clocks.

Ð

vice moves to Tpa within the next three clocks.

Tpa: MACSI device drives AB A and AB AD with the ad-

Ð Ð

dress, asserts AB AS, drives AB R/W and AB SIZ 2:0 ,

Tpa: MACSI device drives AB A and AB AD with the ad-

[ ]

dress, asserts AB AS, drives AB R/W and AB SIZ 2:0 ,

Ð Ð Ð

Ð

[

]

and negates AB BR if another transaction is not required.

Ð

and negates AB BR if another transaction is not required.

Ð

Td: MACSI device asserts AB DEN, samples AB ACK

Ð

Td: MACSI device asserts AB DEN, drives AB AD with

Ð Ð

and AB ERR, and increments the address on AB A.

Ð

Ð Ð

Ð

the write data, samples AB ACK and AB ERR, and incre-

Ð Ð

Slave asserts AB ACK, drives AB ERR, and drives

ments the address on AB A. Slave captures AB AD data,

Ð Ð

AB AD (with data) when ready. MACSI device samples a

asserts AB ACK, drives AB ERR. MACSI device samples

Ð

Ð Ð

valid AB ACK to capture the read data. Tw states may

Ð

occur after Td. Td state is repeated four or eight times (ac-

a valid AB ACK. Tw states may occur after Td. Td state is

Ð

repeated as required for the complete burst. If SIMR1.ASM

e

cle. If SIMR1.ASM 1, the MACSI device will negate

cording to the burst size). If SIMR1.ASM

device negates AB AS in the last Td cycle. If SIMR1.ASM

0, the MACSI

0, the MACSI device negates AB AS in the last Td cy-

Ð

e

Ð

1, the MACSI device will negate AB AS in the first Td

e

cycle.

AB AS in the first Td cycle.

Ð

Tr: MACSI device negates AB R/W, AB DEN, and

Ð

[ ]

AB SIZ 2:0 , releases AB A and AB AS, and stops driv-

Ð Ð Ð

Tr: MACSI device negates AB R/W, AB DEN, and

Ð

[

]

AB SIZ 2:0 , and releases AB

deasserts AB ACK and AB ERR and releases AB AD.

A

and AB AS. Slave

Ð

ing AB AD with data. Slave deasserts AB ACK and

Ð

Ð Ð

AB ERR.

Ð

37

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–12

FIGURE 6-7. ABus Burst Write: Physical AddressingÐ16 Bytes, 1 w/s

6.4.4 Virtual Addressing Bus Transactions

Single Read

Td: MACSI device negates AB AS, asserts AB DEN, and

Ð Ð

samples AB ACK and AB ERR. Slave asserts AB ACK,

Ð

drives AB ERR, and drives AB AD (with data) when

Ð Ð

ready. MACSI device samples a valid AB ACK, and cap-

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

tures the read data. Tw states may occur after Td.

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tva within the next three clocks, and then

drives AB A and AB AD.

Tr: MACSI device negates AB R/W, AB DEN, and

Ð

Ð Ð

Tva: MACSI device drives AB A and AB AD with the vir-

[

]

AB SIZ 2:0 , and releases AB

deasserts AB ACK and AB ERR and releases AB AD.

A

and AB AS. Slave

Ð

Ð Ð

tual address for one clock, negates AB AS, asserts

Ð Ð Ð

Ð

AB R/W, drives AB SIZ 2:0 , and negates AB BR if an-

Single Write

[

]

other transaction is not required.

Ð

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Tmmu: Host MMU performs an address translation during

this clock.

Ð

vice moves to Tva within the next three clocks, and then

drives AB A and AB AD.

Ð Ð

Tva: MACSI device drives AB A and AB AD with the vir-

Tpa: Host MMU drives AB AD with the translated (physi-

Ð

cal) address.

Ð Ð

tual address for one clock, negates AB AS, negates

Ð

[

]

AB R/W, and drives AB SIZ 2:0 .

Ð

38

6.0 Functional Description (Service Engine) (Continued)

Tmmu: Host MMU performs an address translation during

this clock.

Tr: MACSI device negates AB R/W, AB DEN, and

Ð Ð

[

]

AB SIZ 2:0 , releases AB A, AB AD, and AB AS, and

stops driving AB AD with data. Slave deasserts AB ACK

Ð

Tpa: Host MMU drives AB AD with the address.

Ð

Td: MACSI device negates AB AS, asserts AB DEN,

Ð

and AB ERR.

Ð

drives AB AD with the write data and starts sampling

6.5 ENHANCED ABUS MODE

Ð

AB ACK and AB ERR. Slave captures AB AD data, as-

Ð

serts AB ACK, and drives AB ERR. MACSI device sam-

When the enhanced ABus mode is selected, several chang-

es occur. The timing of AB ACK is modified during read

Ð Ð

ples a valid AB ACK. Tw states may occur after Td.

Ð

accesses. In this mode, read data is expected one cycle

after the AB ACK signal (see Figure 6-8 and Figure 6-11 ).

Ð

Tr: MACSI device negates AB R/W, AB DEN, and

Ð Ð

AB SIZ 2:0 , and releases AB A, AB AD, and AB AS.

Ð

[

]

Slave deasserts AB ACK and AB ERR and stops driving

In addition, channel information is no longer supplied on the

upper four bits of the Address/Data lines during the address

cycle. Instead, the value of this nibble of address is supplied

from a programmable register within the MACSI device (for

a full description of these bits please see System Interface

Ð

AB AD with data.

Ð

Burst Read

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

Mode Register1 (SIMR1)). Finally, the AB DEN signal be-

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

comes an input in this enhanced mode. This signal, along

with AB ACK and AB ERR, are used to encode a subset

of the acknowledge, retry, and error functions supported on

vice moves to Tva within the next three clocks, and then

drives AB A and AB AD.

Ð

Ð Ð

Tva: MACSI device drives AB A and AB AD with the vir-

the SBus.

Ð Ð

tual address for one clock, negates AB AS, asserts

Ð

AB R/W, drives AB SIZ 2:0 , and negates AB BR if an-

These enhancements make it easier to connect the MACSI

device to the SBus as a bus master. However, a full FDDI

adapter design requires the design of a slave interface from

the SBus to the control bus of the MACSI device and the

other FDDI components.

[

]

other transaction is not required.

Ð

Tmmu: Host MMU performs an address translation during

this clock.

Tpa: Host MMU drives AB AD with the translated (physi-

Ð

cal) address.

6.5.1 Enhanced ABus Mode Bus Transactions

Bus transactions in the Enhanced Abus Mode are shown in

Figure 6-8 through Figure 6-11. In the Enhanced ABus

mode, the Bus Request signal (AB BR) will be deasserted

Td: MACSI device asserts AB DEN and samples

Ð

AB ACK and AB ERR. Slave asserts AB ACK, drives

Ð

AB ERR, and drives AB AD (with data) when ready.

Ð

Ð Ð

MACSI device samples a valid AB ACK, and captures the

after the bus is granted until the completion of the bus trans-

action. The only exception to this may occur when the

MACSI device is attempting back-to-back burst reads. In

this case AB BR may be deasserted for as few as two

Ð

cycles.

Ð

read data. Tw states may occur after Td. This state is re-

peated four or eight times (according to burst size). If

e

SIMR1.ASM

last Td cycle. If SIMR1.ASM

0 the MACSI device negates AB AS in the

e

Ð

1, the MACSI device will

Single Read

negate AB AS in the first Td cycle.

Ð

Tr: MACSI device negates AB R/W, AB DEN, and

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tma on the next cycle.

Ð

[

]

AB SIZ 2:0 , and releases AB

deasserts AB ACK and AB ERR and releases AB AD.

A

and AB AS. Slave

Ð

Tma: MACSI device drives AB A and AB AD with the

Ð

Ð Ð

AB SIZ 2:0 , and negates AB BR until the end of this

Ð

master address, asserts AB AS, drives AB R/W and

Burst Write

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

[

transaction.

]

Ð

vice moves to Tva within the next three clocks, and then

drives AB A and AB AD.

Tpa: The Physical address is asserted by the MMU.

Ð Ð

Tva: MACSI device drives AB A and AB AD with the vir-

Td: MACSI device negates AB AS and samples AB ACK,

Ð

AB ERR, and AB DEN. Slave asserts AB ACK,

Ð Ð

tual address for one clock, negates AB AS, negates

Ð

AB ERR, and AB DEN with the appropriate acknowledg-

Ð

Ð Ð

ment. The MACSI device samples a valid acknowledgment

[

]

AB R/W, drives AB SIZ 2:0 .

Ð

Tmmu: Host MMU performs an address translation during

this clock.

and moves to Tr. Tw states may occur after Td.

Tr: MACSI device negates AB R/W, AB DEN, and

Ð

AB SIZ 2:0 , releases AB A and AB AS, and samples

Tpa: Host MMU drives AB AD with the address.

Ð

Td: MACSI device asserts AB DEN, drives AB AD with

[

]

AB AD. Slave drives AB AD (with data), deasserts

Ð

the write data, and starts sampling AB ACK and

AB ACK, AB ERR, and AB DEN, and releases AB

Ð

AB ERR. Slave captures AB AD data, asserts AB ACK

Ð

AD.

Ð Ð

and drives AB ERR. MACSI device samples

Ð

a

valid

AB ACK. Tw states may occur after Td. Td is repeated as

Ð

required for the complete burst. If SIMR1.ASM

e

MACSI device negates AB AS in the last Td cycle. If

0, the

Ð

1, the MACSI device will negate AB AS in

e

SIMR1.ASM

the first Td cycle.

Ð

39

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–13

FIGURE 6-8. Enhanced ABus Read TimingÐ0 w/s, 1 w/s

TL/F/11705–14

FIGURE 6-9. Enhanced ABus Mode Write Timing

40

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–15

FIGURE 6-10. Enhanced ABus Mode Burst Write Timing

Single Write

Tpa: The Physical address is asserted by the MMU.

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tma in the next cycle.

Td: MACSI device negates AB AS, drives AB AD with the

Ð

write data and starts sampling AB ACK, AB ERR, and

Ð Ð

AB DEN. Slave captures AB AD data, and acknowledges

Ð Ð

with AB ACK, AB ERR, and AB DEN. Tw states may

Tma: MACSI device drives AB A and AB AD with the

Ð

occur after Td if the slave does not acknowledge.

Ð

Ð Ð

AB SIZ 2:0 , and negates AB BR until the end of this

Ð

master address, asserts AB AS, drives AB R/W and

[

transaction.

]

[ ]

Tr: MACSI device negates AB R/W, AB SIZ 2:0 , releas-

Ð Ð

Ð

es AB A, AB AD, and AB AS, and stops driving

Ð Ð Ð

AB AD with data. Slave deasserts AB ACK, AB ERR,

Ð

and AB DEN.

Ð

41

6.0 Functional Description (Service Engine) (Continued)

TL/F/11705–16

FIGURE 6-11. Enhanced ABus Mode Back-to-Back Read Timing

Burst Read

regranted in this cycle, the MACSI device will proceed di-

rectly to the Tma state of the next burst. The normal Tbr

state is skipped allowing back-to-back burst reads.

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tma in the next cycle. This cycle may be

skipped if AB BR was asserted during the previous ac-

Burst Write

Ð

cess. This allows for back-to-back burst reads.

Tbr: MACSI device asserts AB BR to indicate it wishes to

Ð

perform a transfer. Host asserts AB BG. The MACSI de-

Ð

vice moves to Tma in the next cycle.

Tma: MACSI device drives AB A and AB AD with the

Ð

Ð Ð

AB SIZ 2:0 , and negates AB BR for at least two cycles.

Ð

master address, asserts AB AS, drives AB R/W and

Tma: MACSI device drives AB A and AB AD with the

Ð

Ð Ð

AB SIZ 2:0 , and negates AB BR until this transaction is

Ð

master address, asserts AB AS, drives AB R/W and

[

]

Ð Ð

Tpa: The Physical Address is asserted by the MMU.

[

completed.

]

Ð

Td: MACSI device samples AB ACK, AB ERR, and

Ð

AB DEN, and increments the address on AB A. Slave

Ð Ð

acknowledges using AB ACK, AB ERR, and AD DEN.

Tpa: The Physical Address is asserted by the MMU.

Ð

MACSI device samples a valid AB ACK and latches data

Td: MACSI device drives AB AD with the write data, sam-

Ð

in the following cycle. Tw states may occur after Td. Td

ples AB ACK, AB ERR, and AB DEN, and increments

Ð

the address on AB A. Slave captures AB AD data and

Ð Ð

acknowledges using AB ACK, AB ERR, and AB DEN.

state is repeated four or eight times (according to the burst

e

1, the MACSI

Ð

MACSI device samples a valid acknowledge. Tw states may

size). If SIMR1.ASM

AB AS in the last Td cycle. If SIMR1.ASM

0, the MACSI device negates

e

Ð

device negates AB AS in the first Td cycle.

occur after Td. Td state is repeated as required for the com-

e

AB AS in the last Td cycle. If SIMR1.ASM

Ð

Tr: MACSI device negates AB R/W and AB SIZ 2:0 and

plete burst. If SIMR1.ASM

0, the MACSI device negates

e

[

]

releases AB A and AB AS. Slave drives AB AD (with

Ð

1, the MACSI

Ð

device negates AB AS in the first Td cycle.

Ð

data), deasserts AB ACK, AB ERR, and AB DEN. If an-

Ð

Tr: MACSI device negates AB R/W, AB SIZ 2:0 , releas-

Ð

other request is pending (AB BR asserted) and the Bus is

[

]

es AB A and AB AS, and stops driving AB AD with

Ð

data. Slave deasserts AB ACK, AB ERR, and AB DEN.

Ð

42

7.0 Control Information

7.1 OVERVIEW

lected. When CBA8 is 1, the internal BSI register block is

selected. The actual addresses within the MACSI device are

defined in Table 7-1 and Table 7-2.

The Control Information includes Operation, Event, Status

and Parameter Registers that are used to manage and op-

erate the MACSI Device. A controller on the external Con-

trol Bus gains access to read and write these parameters

via the Control Bus Interface.

All registers and control bits within the BSI register block of

the MACSI device have the same relative addresses and

functions as they do in the BSI device. All registers and

control bits within the BMAC register block of the MACSI

device have the same relative addresses and functions as

they do in the BMAC device. The only exceptions to this are

shown in the detailed register descriptions following the

memory map table. There are two registers which have new

features unique to the MACSI device or functions which are

slightly modified from the original BMAC or BSI device.

These are MCMR0 and MCMR2.

The MACSI device combines the functions of the original

DP83261 BMAC device and the DP83265 BSI device with

many enhanced capabilities. The MACSI device has addi-

tional Control Bus address lines compared to the BMAC and

BSI devices (CBA(8:0)). When the most significant address

bit (CBA8) is zero, the internal BMAC register block is se-

TABLE 7-1. MACSI Memory Map (BMAC Registers)

Access Rules

Reset

Value

Address

Register Name

MAC Mode Register 0 (MCMR0)

Read

Write

Always

N/A

000

001

Always

N/A

00

Option Register (Option)

002

Function Register (Function)

Reserved

003

004

Reserved

N/A

005

MAC Mode Register 2 (MCMR2)

Reserved

Always

N/A

Always

N/A

00

006

007

MAC Revision (MCRev)

Always

N/A

Data Ignored

Always

N/A

*

008

MAC Compare Register (MCCMP)

Reserved

00

009–00B

00C

Current Receiver Status Register (CRS0)

Reserved

Always

N/A

Data Ignored

N/A

00

00D

00E

Current Transmitter Status Register (CTS0)

Reserved

Always

N/A

Data Ignored

N/A

00F

010

Ring Event Latch Register 0 (RELR0)

Ring Event Mask Register 0 (REMR0)

Ring Event Latch Register 1 (RELR1)

Ring Event Mask Register 1 (REMR1)

Token and Timer Event Latch Register (TELR0)

Token and Timer Event Mask Register (TEMR0)

Reserved

Always

N/A

Conditional

Always

Conditional

Always

Conditional

Always

N/A

00

011

012

013

014

015

016–017

018

Counter Increment Latch Register (CILR)

Counter Increment Mask Register (CIMR)

Reserved

Always

N/A

Conditional

Always

N/A

00

019

01A–01B

01C

Counter Overflow Latch Register (COLR)

Counter Overflow Mask Register (COMR)

Reserved

Always

N/A

Conditional

Always

N/A

00

01D

01E–027

43

7.0 Control Information (Continued)

TABLE 7-1. MACSI Memory Map (BMAC Registers) (Continued)

Access Rules

Reset

Value

Address

Register Name

Internal Event Latch Register (IELR)

Read

Write

Conditional

N/A

028

029–02B

02C

Always

N/A

00

Reserved

Exception Status Register (ESR)

Exception Mask Register (EMR)

Interrupt Condition Register (ICR)

Interrupt Mask Register (IMR)

Reserved

Always

N/A

Conditional

Always

00

02D

02E

Data Ignored

Always

02F

030–03F

040–07F

080–0BF

0C0-0FF

N/A

MAC Parameters

Stop Mode

Always

N/A

Stop Mode

N/A

NA

Counters/Timers

Reserved

e

*

NA

Contains a MAC Revision code.

Not altered upon reset.

Not Applicable

N/A

Table 7-2. MACSI Memory Map (BSI Registers)

Register Name

Access Rules

Reset

Value

Address

Read

Write

Always

100

101

102

103

104

105

106

107

108

109

10A

10B

10C

10D

10E

10F

110

111

112

113

System Interface Mode Register 0 (SIMR0)

Always

00

NA

²

System Interface Mode Register 1 (SIMR1)

Pointer RAM Control and Address Register (PCAR)

Mailbox Address Register (MBAR)

Always

Master Attention Register (MAR)

Data Ignored

Always

00

07

00

0F

00

FF

00

NA

00

NA

Master Notify Register (MNR)

State Attention Register (STAR)

Conditional

Always

State Notify Register (STNR)

Service Attention Register (SAR)

Conditional

Always

Service Notify Register (SNR)

No Space Attention Register (NSAR)

No Space Notify Register (NSNR)

Conditional

Always

Limit Address Register (LAR)

Always

Limit Data Register (LDR)

Always

Request Attention Register (RAR)

Conditional

Always

Request Notify Register (RNR)

Request Channel 0 Configuration Register 0 (R0CR0)

Request Channel 1 Configuration Register 0 (R1CR0)

Request Channel 0 Expected Frame Status Register (R0EFSR)

Request Channel 1 Expected Frame Status Register (R1EFSR)

Always

44

7.0 Control Information (Continued)

Table 7-2. MACSI Memory Map (BSI Registers)

Access Rules

Write

Reset

Value

Address

Register Name

Indicate Attention Register (IAR)

Read

Always

114

115

116

Conditional

Always

00

Indicate Notify Register (INR)

Indicate Threshold Register (ITR)

INSTOP Mode

e

NA

or EXC

1 Only

117

Indicate Mode Configuration Register (IMCR)

Always

INSTOP Mode

Only

NA

118

119

Indicate Copy Configuration Register (ICCR)

Indicate Header Length Register (IHLR)

Always

NA

INSTOP Mode

e

or EXC

1 Only

11A

11B

Address Configuration Register (ACR)

Request Channel 0 Configuration Register 1 (R0CR1)

Request Channel 1 Configuration Register 1 (R1CR1)

Reserved

Always

N/A

Always

N/A

00

11C

11D–11E

11F

System Interface Compare Register (SICMP)

Reserved

Always

N/A

Always

N/A

NA

120–1FF

e

²

NA

Initialized to a System Interface Revision code upon reset. The System Interface Revision code remains until it is overwritten by the host.

Not altered upon reset.

Not Applicable

N/A

The MAC Control Information Address Space is divided into

4 groups as shown in Table 7-3. An information summary is

given for each group followed by a detailed description of all

registers.

ABus using the Pointer RAM Address and Control Register,

the Mailbox Address Register, and a mailbox location in

ABus memory. Descriptors are fetched (or written) by the

MACSI device across the ABus.

MAC Operation Registers (Table 7-4)

System Interface Registers (Table 7-8)

#

MAC Event Registers (Table 7-5)

#

7.2 CONVENTIONS

MAC Parameters (Table 7-6)

#

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.

When referring to the contents of a byte, the most signifi-

cant bit is always referred to first. When referring to a bit

MAC Counters/Timers (Table 7-7)

The System Interface Operation registers are accessed di-

rectly via the Control Bus. Limit RAM Registers are ac-

cessed indirectly via the Control Bus using the Limit RAM

Data and Limit RAM Address Registers. The Pointer RAM

Registers are accessed indirectly via the Control Bus and

within

used. For example, MCMR0.RUN references the RUN bit in

MAC Mode Register 0.

a byte the notation register name.bit name is

Ð Ð

45

7.0 Control Information (Continued)

TABLE 7-3. MAC Control Information Address Space

Address

Range

Read

Write

Description

Conditions

000–007 Operation Registers Always (Note 2) Always (Note 2)

008–02F Event Registers

030–03F Reserved

Always (Note 2) Always (cond) (Note 2)

N/A (Note 4)

040–07F MAC Parameters

Stop Mode

(Notes 1, 3)

Stop Mode

(Notes 1, 3)

080-0BF Counters/Timers

0C0-0FF Reserved

Always

Stop Mode (Note 1)

N/A (Note 4)

Note 1: An attempt to access a currently inaccessible MAC Control location because of the current

mode or because it is 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 locations within the Operation and Event Address

ranges of the MAC Control Information Space 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. Other-

wise accesses will cause a command error (bit CCE of the Exception Status Register is set to One)

and the access will not be performed.

a) The MAC Transmitter is in state T0 or T1 or T3;

e

1

e

b) Option.ITC

c) Function.BCN

1 and Option.IRR

e

0

0 and Function.CLM

Note 4: Reserved bits in registers are always read as 0 and are not writable.

TABLE 7-4. MAC Operation Registers

Addr

000

Name

MCMR0

Option

D7

DIAG

ITC

D6

ILB

D5

D4

D3

PIP

D2

MRP

D1

D0

RUN

Read

Always

N/A

Write

Always

N/A

RES

IFCS

RES

IRPT

CLM

RES

AFIE

RES

CBP

ELA

RES

001

EMIND

RES

IRR

ITR

ESA

002

Function

Reserved

MCMR2

Reserved

MCRev

RES

BCN

MCRST

RES

MARST

RES

003–004

005

RES

LLC MCE

RES

SMT MCE

RES

BOSEL

RES

Always

N/A

Always

N/A

006

007

REV(7–0)

Always

Ignored

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

Note 2: On Master Reset, all MAC Operation Registers are set to Zero except the Revision Register.

46

7.0 Control Information (Continued)

TABLE 7-5. MAC Event Registers

Addr

Name

D7

D6

D5

D4

D3

D2

D1

D0

Read

Always

N/A

Write

Always

N/A

008

MCCMP

MCCMP(7–0)

009–00B Reserved RES

RES

RS2

RES

TS2

RES

RS1

RES

RTS2

RES

RTS1

RES

RTS0

RES

TTS0

RES

ROP

00C

00D

00E

00F

010

011

012

013

014

015

CRS0

Reserved RES

CTS0 ROP

Reserved RES

RFLG

RS0

RES

Always

N/A

Ignored

N/A

RES

TS1

TS0

TTS3

RES

TTS2

RES

TTS1

RES

Always

N/A

Ignored

N/A

RES

RELR0

REMR0

RES DUP ADD

PINV

MYCLM

OTR MAC

RES

CLMR

RES

BCNR

RES

RNOP

Always Conditional

Always Always

RELR1 LOCLM HICLM

REMR1 LOCLM HICLM

MYBCN OTRBCN Always Conditional

MYBCN OTRBCN Always Always

RES

TELR0

TEMR0

RLVD TKPASS TKCAPT CBERR

DUPTKR TRTEXP TVXEXP ENTRMD Always Conditional

DUPTKR TRTEXP TVXEXP ENTRMD Always

Always

N/A

016–017 Reserved RES

RES

FR LST

RES

FREI

RES

FREI

RES

TTE

RES

N/A

018

019

CILR

RES

TK RCVD FR TRX FR NCOP FR COP

FR RCV Always Conditional

CIMR

FR RCV Always

RES N/A

Always

N/A

01A–01B Reserved RES

RES

01C

01D

COLR

RES

TK RCVD FR TRX FR NCOP FR COP

FR LST

RES

FR RCV Always Conditional

COMR

FR RCV Always

Always

N/A

01E–027 Reserved RES

028 IELR RES

029–02B Reserved RES

RES

CCE

IERR

RES

CPE

RES

MPE

RES

PPE

RNG

RES

N/A

TSM ERR RSM ERR

Always Conditional

N/A N/A

Always Conditional

RES

COE

RES

CIE

02C

02D

02E

02F

ESR

EMR

ICR

CWI

ZERO

ESE

Always

N/A

Always

Ignored

Always

N/A

IMR

ESE

CIE

TTE

030–03F Reserved RES

RES

Note 1: Attempts to access reserved locations within the MAC Event Registers 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.

Note 3: On Master Reset all Event Registers are reset to Zero.

7.3 ACCESS RULES

Status Register can be checked to verify that the operation

terminated normally.

For the Ring Engine (MAC), all Control Interface accesses

are checked against the current operational mode to deter-

mine if the register is currently accessible. If not currently

accessible, the Control Bus Interface access is rejected

(and reported in an Event Register). This means that the

Control Bus Interface completes all accesses in a determi-

nistic amount of time. Certain Status and Parameter regis-

ters are not accessible while in Run mode because the Ring

Engine might access those locations. The Exception

The Service Engine Registers are always accessible.

7.3.1 MAC Parameter RAM

The MAC parameter RAM is accessible in Stop mode and in

RUN mode while: the MAC Transmitter is in states T0, T1 or

T3; Option.ITC and Option.IRR are set; and Function.BCN

and Function.CLM are not set. Otherwise a command reject

is given (ESR.CCE) and the Parameter RAM will not be read

or written.

47

7.0 Control Information (Continued)

TABLE 7-6. MAC Parameter RAM

Addr

040

041

042

043

044

045

046

047

048

049

04A

04B

04C

04D

04E

04F

050

051

052

053

054

055

056

057

058

059

05A0–5F

060

061

062

Name

MLA0

Register Contents

MLA(47–40)

MLA(39–32)

MLA(31–24)

MLA(23–16)

MLA(15–8)

MLA(7–0)

Addr

063

064

065

066

067

068

069

06A

06B

06C

06D

06E

06F

070

071

072

073

074

075

076

077

078

079

07A

07B

07C

07D

07E

07F

Name

PGM13

PGM14

PGM15

PGM16

PGM17

PGM18

PGM19

PGM1A

PGM1B

PGM1C

PGM1D

PGM1E

PGM1F

PGM0

Register Contents

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)

MLA1

MLA2

MLA3

MLA4

MLA5

MSA0

MSA1

GLA0

MSA(15–8)

MSA(7–0)

GLA(47–40)

GLA(39–32)

GLA(31–24)

GLA(23–16)

GLA(15–8)

GLA1

GLA2

GLA3

GLA4

Reserved

GSA0

GSA(15–8)

PGM1

PGM(F–8)

Reserved

TREQ0

TREQ1

TREQ2

TREQ3

TBT0

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)

TREQ(31–24)

TREQ(23–16)

TREQ(15–8)

TREQ(7–0)

TBT(31–24)

TBT(23–16)

TBT(15–8)

TBT(7–0)

PGM3

PGM4

PGM5

PGM6

PGM7

TBT1

PGM8

TBT2

PGM9

TBT3

PGMA

PGMB

PGMC

PGMD

PGME

PGMF

FGM0

FGM1

Reserved

PGM10

PGM11

PGM12

FGM(7–0)

FGM(F–8)

PGM(87–80)

PGM(8F–88)

PGM(97–90)

7.3.2 MAC Counters/Timer Thresholds

The MAC event counters and timer thresholds are always

readable, and are writable in Stop mode.

48

7.0 Control Information (Continued)

TABLE 7-7. MAC Counters and Timer Thresholds

Addr

080–086

087

Name

Reserved

THSH1

Reserved

TMAX

Register Contents

Null(7–4), THSH1(3–0)

Null(7–4), TMAX(3–0)

Addr

0B0

0B1

0B2

0B3

0B4

0B5

0B6

0B7

0B8

0B9

0BA

0BB

0BC

0BD

0BE

0BF

Name

FNCT0

FNCT1

FNCT2

FNCT3

FTCT0

FTCT1

FTCT2

FTCT3

TKCT0

TKCT1

TKCT2

TKCT3

RLCT0

RLCT1

RLCT2

RLCT3

Register Contents

Zero(31–24)

Null(7–4), FNCT(19–16)

FNCT(15–8)

088–092

093

FNCT(7–0)

094–096

097

Reserved

TVX

Zero(31–24)

Null(7–4), TVX(3–0)

TNEG(31–24)

TNEG(23–16)

TNEG(15–8)

Null(7–4), FTCT(19–16)

FTCT(15–8)

098

TNEG0

TNEG1

TNEG2

TNEG3

Reserved

LTCT

099

FTCT(7–0)

09A

Zero(31–24)

09B

TNEG(7–0)

Null(7–4), TKCT(19–16)

TKCT(15–8)

09C–09E

09F

LTCT(7–0)

TKCT(7–0)

0A0

FRCT0

FRCT1

FRCT2

FRCT3

EICT0

Zero(31–24)

0A1

Null(7–4), FRCT(19–16)

FRCT(15–8)

Null(7–4), RLCT(19–16)

RLCT(15–8)

0A2

0A3

FRCT(7–0)

RLCT(7–0)

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

0A4

Zero(31–24)

are ignored on writes.

0A5

EICT1

Null(7–4), EICT(19–16)

EICT(15–8)

Note 2: The value obtained on reads from reserved locations is not speci-

fied.

0A6

EICT2

Note 3: On Master Reset, the event counters are not cleared.

0A7

EICT3

EICT(7–0)

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

0A8

LFCT0

LFCT1

LFCT2

LFCT3

FCCT0

FCCT1

FCCT2

FCCT3

Zero(31–24)

0A9

Null(7–4), LFCT(19–16)

LFCT(15–8)

0AA

0AB

LFCT(7–0)

0AC

Zero(31–24)

0AD

Null(7–4), FCCT(19–16)

FCCT(15–8)

0AE

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.

0AF

FCCT(7–0)

49

7.0 Control Information (Continued)

System Interface Registers

TABLE 7-8. System Interface Registers

Addr

100

101

102

103

104

105

106

107

108

109

10A

10B

10C

10D

10E

10F

110

111

112

113

114

115

116

Name

D7

D6

D5

D4

D3

D2

MRST

ASM

A2

D1

FABCLK

RES

D0

Read

Write

Always

SIMR0

SMLB

SMLQ

VIRT

BIGEND FLOW

TEST Always

SIMR1 AB A31 AB A30 AB A29 AB A28 ATM

Ð

EAM

A0

Always

Ð

PCAR

MBAR

MAR

MNR

STAR

STNR

SAR

BP1

BP0

PTRW

A4

A3

A1

Always

[

]

[

]

[

]

Mailbox Address 27:24 , 23:16 , 15:8 , 7:0

[

]

Always

STA

STAN

ERR

NSA

NSAN

BPE

SVA

SVAN

CPE

RQA

RQAN

CWI

INA

RES

Ignored

Always

INAN

CMDE SPSTOP RQSTOP INSTOP Always

Conditional

Always

ERRN

RES

BPEN

RES

CPEN

RES

CWIN CMDEN SPSTOPN RQSTOPN INSTOPN Always

RES

ABR0

ABR1

LMOP

LMOPN

LDI2

PTOP Always

PTOPN Always

NSI2 Always

NSI2N Always

LRD8 Always

LRD0 Always

BRKR1 Always

Conditional

Always

SNR

RES

ABR0N ABR1N

NSAR

NSNR

LAR

NSR0

NSR1

LDI0

NSI0

LDI1

LDI1N

LMRW

LRD3

NSI1

NSI1N

RES

Conditional

Always

NSR0N NSR1N LDI0N

NSI0N

LRA0

LRD4

LDI2N

RES

LRA3

LRD7

LRA2

LRD6

LRA1

LRD5

Always

LDR

LRD2

LRD1

EXCR1

Always

RAR

USRR0 RCMR0 EXCR0 BRKR0 USRR1 RCMR1

Conditional

Always

RNR USRR0N RCMR0N EXCR0N BRKR0N USRR1N RCMR1N EXCR1N BRKR1N Always

R0CR0

R1CR0

R0EFSR

R1EFSR

IAR

TT1

TT0

PRE

EE1

HLD

FCT

SAT

VST

FCS

EC0

Always

VDL

RES

THR7

VFCS

RES

EE0

EA1

EA0

EC1

Always

EE1

EE0

EA1

EA0

EC1

Always

EXCI0

BRKI0

EXCI1

BRKI1

EXCI2

EXC2N

THR1

BRKI2 Always

Conditional

Always

INR

RES

EXC0N BRK0N EXC1N BRK1N

BRK2N Always

e

1 Only

ITR

THR6

THR5

THR4

THR3

THR2

THR0 Always INSTOP

e

1 or

EXC

e

117

118

119

IMCR

ICCR

IHLR

SM1

HL7

SM0

HL6

SKIP

RES

HL5

FPP

BOT2

BOT1

RES

HL2

BOB

BOS

Always INSTOP

1 Only

Always

CC0

CC1

CC2

Always

e

1 Only

HL4

HL3

HL1

HL0

Always INSTOP

e

1 or

EXC

11A

11B

11C

ACR

PCKI2

EFT

PCKI1

RES

PCKI0 RSWP1 RSWP0

ISWP2

RES

ISWP1

RES

ISWP0 Always

Always

N/A

R0CR1

R1CR1

RES

ETR

RES

Always

N/A

EFT

RES

11D–11E Reserved RES

11F SICMP CMP7

120–1FF Reserved RES

RES

CMP6

RES

CMP5

RES

CMP4

RES

CMP3

RES

CMP2

RES

CMP1

RES

CMP0 Always

RES N/A

Always

N/A

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

overwritten.

50

7.0 Control Information (Continued)

Control Registers

Request Channel 0 Configuration Registers (R0CR1–

0) are used to program the operational parameters for

Request Channel 0.

#

The Control Registers are used to configure and control the

operation of the MACSI device.

Request Channel 1 Configuration Registers (R1CR1–

0) are used to program the operational parameters for

Request Channel 1.

The Control Registers include the following registers:

MAC Mode Registers (MCMR2–0) establish the major

operating parameters for the MAC portion of the MACSI

device.

#

Request Channel 0 Expected Frame Status Register

(R0EFSR) defines the expected frame status for frames

being confirmed on Request Channel 0.

Option Register (Option) selects major configuration

options for the MAC portion of the device.

#

Request Channel 1 Expected Frame Status Register

(R1EFSR) defines the expected frame status for frames

being confirmed on Request Channel 1.

Function Register (Function) initiates major MAC level

functions.

#

MAC Revision (MCRev) this register contains the silicon

revision code for the MAC state machines of this device.

#

Indicate Threshold Register (ITR) is used to specify a

maximum number of frames that can be copied onto an

Indicate Channel before a breakpoint is generated.

System Interface Mode Registers (SIMR1–0) estab-

lishes major operating parameters for the System Inter-

face.

#

Indicate Mode Configuration Register (IMCR) speci-

fies how the incoming frames are sorted onto Indicate

Channels, enables frame filtering, and enables break-

points on various burst boundaries.

Pointer RAM Control and Address Register (PCAR) is

used to program the parameters for the PTOP (Pointer

RAM Operation) service function.

#

Indicate Copy Configuration Register (ICCR) is used

to program the copy criteria for each of the Indicate

Channels.

#

Mailbox Address Register (MBAR) is used to program

the memory address of the mailbox used in the data

transfer of the PTOP service function.

#

Indicate Header Length Register (IHLR) defines the

length of the frame header for use with the Header/Info

Sort Mode.

Limit Address Register (LAR) is used to program the

parameters and data used in the LMOP (Limit RAM Op-

eration) service function.

#

Event Registers

Limit Data Register (LDR) is used to program the data

used in the LMOP service function.

#

The Event Registers record the occurrence of events or

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

erating Interrupt signals. There is a two-level hierarchy in

generating this signal, as shown in Figure 7-1.

TL/F/11705–17

FIGURE 7-1. Event Registers Hierarchy

51

7.0 Control Information (Continued)

The MACSI device has two interrupts signals. One provides

interrupts on those events generated by the MAC state ma-

chines (INT0) and the other provides interrupts on those

events generated by the System Interface state machines

(INT1). This partition maintains hardware and software com-

patibility with earlier designs based on the BMAC and BSI

devices.

Ð State Notify Register (STNR)

Ð Service Attention Register (SAR)

Ð Service Notify Register (SNR)

Ð No Space Attention Register (NSAR)

Ð No Space Notify Register (NSNR)

Ð Request Attention Register (RAR)

Ð Request Notify Register (RNR)

Ð Indicate Attention Register (IAR)

Ð Indicate Notify Register (INR)

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

in the Attention Registers (e.g., No Space Attention Regis-

ter). Each Attention Register has a corresponding Notify

Register (e.g., No Space Notify Register). When a bit in the

Attention Register is set to One and its corresponding bit in

the Notify Register is also set to One, the corresponding bit

in the Master Attention Register will be set to one.

Ð System Interface Compare Register (SICMP)

Servicing Interrupts

In the process of servicing an interrupt, the Host may use

one or both levels of condition masks to disable new inter-

rupts while one is being serviced. Soon after the Manage-

ment Entity has processed the interrupt to some extent, it is

ready to re-arm the interrupt in order to be notified of the

next condition.

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

Attention Register is set to One and the corresponding bit in

the Master Notify Register is set to One, the Interrupt signal

is asserted.

To ensure that events are not missed when updating the

attention registers, all attention registers are conditional

write registers. Bits in Conditional Write Registers (e.g., No

Space Attention Register) are only written when the corre-

sponding bits in the Compare Register are equal to the bits

to be overwritten. Read operations for conditional write reg-

isters automatically cause the Compare Register to be load-

ed with the contents of the conditional write register being

accessed. The MACSI device contains two compare regis-

ters. One is used for Ring Engine Event Registers (MCCMP)

and the other is used for System Interface Event Registers

(SICMP).

The Interrupt Control Register always contains the merged

output of the masked Condition Registers as shown in Fig-

ure 7-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 eliminated.

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.

Events are recorded in Attention Registers and contribute to

the Interrupt when the bit in the corresponding Notify Regis-

ter is set (see Figure 7-1 ). Bits in the Master Attention Reg-

ister (MAR) are not cleared directly. They are cleared by

clearing the lower level attention and/or notify register.

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 that have not changed since the last read can be written

to a new value.

The Event Registers include the following registers:

Ring Engine Event Registers (INT0):

#

Whenever a Condition Latch Register is read, its contents

are stored in the Compare Register. There is one Compare

Register for the Ring Engine Event Registers and one Com-

pare Register for the Service Engine Event Registers. Each

bit of the Compare 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 corresponding 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) for

Ring Engine Registers and in the State Attention Register

(STAR.CWI) for Service Engine Registers.

Ð MAC Compare Register (MCCMP)

Ð Current Receiver Status Register (CRS0)

Ð Current Transmitter Status Register (CTS0)

Ð Ring Event Latch Registers (RELR0–1)

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

Ð Counter Overflow Mask Register (COMR)

Ð Internal Event Latch Register (IELR)

Ð Exception Status Register (ESR)

In the MACSI device, two Compare Registers are shared by

a

Ð Exception Mask Register (EMR)

all of the Condition Latch Registers (In the PLAYER de-

Ð Interrupt Condition Register (ICR)

vice, 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 ap-

propriate Compare Register with the most recently read val-

ue before writing the register again. Alternatively, the Event

Register may be read again before being written.

Ð Interrupt Mask Register (IMR)

Service Engine Event Registers (INT1)

#

Ð Master Attention Register (MAR)

Ð Master Notify Register (MNR)

Ð State Attention Register (STAR)

52

7.0 Control Information (Continued)

7.4 RING ENGINE OPERATION REGISTERS

The Operation Registers are used to control the operation of the Ring Engine. The Operation Registers include the following

registers

MAC Mode Register (MCMR0, MCMR2)

#

Option Register (Option)

#

Function Register (Function)

#

MAC Revision Register (MCRev)

#

MAC Mode Register 0 (MCMR0)

The Mode Register contains the current mode of the Ring Engine.

Access Rules

Address

Read

Write

000h

Always

Register Bits

D7

D6

ILB

D5

RES

D4

D3

D2

D1

D0

DIAG

RES

PIP

MRP

CBP

RUN

Bit

Symbol

Description

D7

DIAG

Diagnose Mode: Enables access to all Ring Engine registers. When set, interoperability is not

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

Design Note: In diagnose mode, should an internal error occur the Current Receive and Transmit Status Registers are frozen with the

error state until the internal state machine error condition is cleared (IELR.RSMERR and/or IELR.TSMERR).

D6

ILB

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

a

paths within a station, through the Configuration Switch of the PLAYER device, and through the Clock

Recovery Module of the PLAYER device. System level tests can also be performed through the ring

a

during normal operation.

D5–D4

D3

RES

PIP

Reserved

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

repeating, Parity is passed transparently from PIP to PRP. Odd Parity is generated for all internally

generated fields. Odd Parity is always generated on the PHY Request Data pins (PRD7–0).

D2

D1

MRP

CBP

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

error causes the transmission to be aborted. Odd parity is always generated on MIP.

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

operations. This applies to both the System Interface block and the Ring Engine (MAC) block. Parity errors

e

Register (ESR 012Ch). Parity errors detected while writing to the System Interface block (CBA8

detected while writing to a MAC register (CBA8

0) are reported in the CPE bit of the Exception Status

e

1) are

reported in the CPE bit of the State Attention Register (STAR 106h). In either case, the write operation is

inhibited.

Parity is always generated on CBD7–0 during read accesses.

D0

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.

Enables operation as a MAC entity. The Ring Engine (MAC) must be in Run Mode to achieve an

operational Ring.

53

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

Read

Write

001h

Always

Register Bits

D7

D6

EMIND

D5

IFCS

D4

D3

D2

D1

D0

ITC

IRPT

IRR

ITR

ELA

ESA

Bit

Symbol

Description

D7

ITC

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.

D6

D5

EMIND

IFCS

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

pin is set. This bit also enables the setting of the transmitted C Indicator as an S symbol when the internal

VCOPY signal is asserted by the System Interface and the A Indicator is set as a result of an external match

(i.e., the User asserts the EA pin). The Copied/Not Copied Frame Counters also increment as a result of

external comparisons when this option is enabled.

e

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

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

10). When

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, this option may cause an

interoperability problem.

D4

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 non-FDDI applications to allow full duplex communication.

54

7.0 Control Information (Continued)

Bit

Symbol

Description

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 Tx 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

Tx 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 non-FDDI full duplex applications (in conjunction with the Inhibit Repeat option) to disable the

recovery timers.

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

D1

ELA

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

Ð

Addresses with MLA or any of the configured Group Addresses. 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.

D0

ESA

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

Ð

Addresses with MSA or any of the configured Group Addresses. 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.

55

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

Read

Write

002h

Always

Register Bits

D7

D6

RES

D5

D4

D3

D2

D1

D0

RES

CLM

BCN

MCRST

RES

MARST

Bit

D7–D5

D4

Symbol

Description

RES

CLM

Reserved

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

Ð

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

Ð Ð

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

Ð

until the Claim process completes. The Claim process will not complete if Option.ITR

e

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 frame 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 CLM bit is reset upon entry to the Claim or Beacon state.

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 Tx Beacon State. Beacon

Ð

frames are then transmitted until the Tx Beacon Process completes. The Beacon Process will not

Ð

e

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 via the System

Interface and then bit BCN should be set to One.

Setting this bit also sets bit D2 (MCRST). The BCN bit is cleared on entry to the Beacon state. If the User

programs both D3 (BCN) and D4 (CLM) simultaneously, bit D3 (BCN) takes precedence.

D2

MCRST

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

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

Reset Request actions by writing to TNEG Timers 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.

D1

D0

RES

Reserved

MARST

Master Reset: A Master Reset is functionally equivalent to a hardware reset of the Ring Engine (MAC). A

Master Reset sets all Ring Engine state machines and registers to default 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 Counters are not cleared.

When the Master Reset function is complete, bit D0 (MARST) is set to Zero. At this time, all bits in the

Function Register should be Zero.

56

7.0 Control Information (Continued)

MAC Mode Register 2 (MCMR2)

The Mode Register 2 (MCMR2) is used to program major operating parameters for the MAC portion of the MACSI device. This

register should be programmed only at power-on, or after a software or hardware Master Reset.

This register is cleared upon reset.

Access Rules

Address

Read

Write

005h

Always

Register Bits

D7

D6

RES

D5

D4

D3

D2

D1

D0

RES

AFIE

LLC MCE

SMT MCE

RES

BOSEL

Bit

D5–D7

D4

Symbol

RES

Description

Reserved

AFIE

AFLAG Inhibit Enable: For MACSI Revision D or later, this bit enables the recognition of the AFINHIB

input pin. When AFIE equals zero, the MACSI device will ignore the AFINHIB input. When AFIE equals

one, the MACSI will block the internal address recognition flag (AFLAG) between the MAC and System

Interface whenever the User asserts the AFINHIB pin. For MACSI Revision prior to D, this is a Reserved

bit.

D3

D2

LLC MCE

SMT MCE

LLC Multicast Enable (LLC MCE): When this bit is set, the MACSI device will attempt to copy any LLC

frame (as determined by the FC field) which also has the Individual/Group address bit set (i.e., is using a

multicast address). The MAC block will not set the A or C indicators and the copied/not copied counters

will not increment.

SMT/MAC Multicast Enable (SMT MCE): When this bit is set, the MACSI device will attempt to copy

any SMT or MAC frame (as determined by the FC field) which also has the Individual/Group address bit

set (i.e., is using a multicast address). The MAC block will not set the A or C indicators and the copied/

not copied counters will not increment.

D1

D0

RES

Reserved

BOSEL

Bridge Option Select (BOSEL): This bit controls the interconnect of the STRIP and SAT signals from

e

the System Interface block to the MAC block. When BOSEL

Interface is connected to SAT input of the MAC. When BOSEL

Interface is connected to the SAT input of the MAC.

0, the SAT output from the System

e

1, the STRIP output of the System

MAC Revision Register (MCRev)

The MAC Revision Register (MCRev) contains the revision number of the Ring Engine.

Access Rules

Address

Read

Write

007h

Always

Data Ignored

Register Bits

D7

D6

REV6

D5

D4

D3

D2

D1

D0

REV0

REV7

REV5

REV4

REV3

REV2

REV1

Bit

Symbol

Description

D7–D0

REV(7–0)

Revision Number: Bits D7–D0 contain the version ID of the MAC State Machines.

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

57

7.0 Control Information (Continued)

MAC Compare Register (MCCMP)

The Compare Register is written with the contents of a conditional event latch register when it is read. The Compare Register

may also be written to directly.

Access Rules

Address

Read

Write

008h

Always

Register Bits

D7

D6

CMP6

D5

CMP5

D4

D3

D2

D1

D0

CMP7

CMP4

CMP3

CMP2

CMP1

CMP0

Bit

Symbol

Description

D7–D0

CMP(7–0)

Compare Register: During a write to any of the conditional write registers in the Ring Engine

e

which the comparison matches can be written to a new value.

(CBA8

0), CMP(7–0) are compared bitwise with bits D0–D7 of the accessed register. Only bits for

This function ensures that new events are not lost when clearing status for old events which the event

handling has been completed.

58

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

Read

Write

00Ch

Always

Data Ignored

Register Bits

D7

D6

RS2

D5

D4

D3

D2

D1

D0

RFLG

RS1

RS0

RES

RTS2

RTS1

RTS0

Bit

Symbol

Description

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

D6–D4

RS(2–0)

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

ANSI X3T9.5 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 (Receive Frame Body)

Ð Ð

1

0

RC FR STATUS (A and C Indicators )

Ð Ð

CHECK TOKEN (Check Token)

1

0

1

Ð

1

0

RC FR STATUS (Optional Indicators)

Ð

Reserved

1

D3

RES

Reserved

D2–D0

RTS(2–0)

Receive Timing State: RTS(2–0) 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

0

1

x

Await SD

Ð

Check FC

Ð

Check SA

Ð

Check DA

Ð

Check INFO

Ð

Check MAC

Ð

Reserved

59

7.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 in the Internal Event Latch Register.

Access Rules

Address

Read

Write

00Eh

Always

Data Ignored

Register Bits

D7

D6

TS2

D5

D4

D3

D2

D1

D0

ROP

TS1

TS0

TTS3

TTS2

TTS1

TTS0

Bit

D7

Symbol

ROP

Description

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

D6–D4

TS(2–0)

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

ANSI X3T9.5 standard MAC Transmit Functions. The encoding is shown below.

TS2

0

TS1

0

TS0

0

Transmit State

Idle

0

1

Repeat

Data

0

1

0

1

Issue Token

Claim

1

0

1

0

1

Beacon

Reserved

Void

1

0

1

D3–D0

TTS(3–0)

Transmit Timing State: TTS(3–0) represent the current state of the Transmit Timing state machine.

The encoding is shown below.

TTS3 TTS2 TTS1 TTS0

Transmit Timing State

Idle

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

Transmit Preamble

Wait for Data (FIFO)

Transmit SD and FC Fields

Transmit DA

Transmit SA

Transmit INFO

Transmit FCS

Transmit ED and FS

Reserved

9h–Fh

60

7.0 Control Information (Continued)

Ring Event Latch Register 0 (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

Read

Write

010h

Always

Conditional

Register Bits

D7

D6

DUPADD

D5

D4

D3

D2

D1

D0

RES

PINV

OTRMAC

CLMR

BCNR

RNOP

ROP

Bit

D7

D6

Symbol

RES

Description

Reserved

DUPADD

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

D5

PINV

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

Ð

PLAYER device Reset operation.

a

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

Ð

D4

D3

D2

OTRMAC

CLMR

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.

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.

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.

D1

D0

RNOP

ROP

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

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

61

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

Read

Write

011h

Always

Register Bits

D7

D6

DUPADD

D5

PINV

D4

D3

D2

D1

D0

RES

OTRMAC

CLMR

BCNR

RNOP

ROP

Bit

D7

D6

D5

D4

D3

D2

D1

D0

Symbol

RES

Description

Reserved

DUPADD

PINV

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

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

Ð

OTRMAC

CLMR

BCNR

RNOP

ROP

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

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

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

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

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

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

Read

Write

012h

Always

Conditional

Register Bits

D7

D6

HICLM

D5

D4

D3

D2

D1

D0

LOCLM

MYCLM

RES

MYBCN

OTRBCN

Bit

D7

D6

D5

Symbol

LOCLM

HICLM

Description

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

Ð Ð

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

Ð Ð

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

Ð

D4–D2

D1

RES

Reserved

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

MYBCN

OTRBCN

Ð

D0

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

Ð Ð

62

7.0 Control Information (Continued)

Ring Event Mask Register 1 (REMR1)

Ring Event Mask Register 1 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

Read

Write

013h

Always

Register Bits

D7

D6

HICLM

D5

MYCLM

D4

D3

D2

D1

D0

LOCLM

RES

MYBCN

OTRBCN

Bit

D7

Symbol

LOCLM

HICLM

Description

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

Ð

D6

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

Ð

D5

MYCLM

RES

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

Ð

D4–D2

D1

Reserved

MYBCN

OTRBCN

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

Ð

D0

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

Ð

63

7.0 Control Information (Continued)

Token and Timer Event Latch Register 0 (TELR0)

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

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

ed 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

Read

Write

014h

Always

Conditional

Register Bits

D7

D6

TKPASS

D5

D4

D3

D2

D1

D0

RLVD

TKCAPT

CBERR

DUPTKR

TRTEXP

TVXEXP

ENTRMD

Bit

Symbol

Description

D7

RLVD

Ring Latency Valid:

0: This bit is set to Zero to request a new latency value from the Ring Engine. 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. Note that if a duplicate of this

station’s MAC address exisits on the ring, the Ring Latency Measurement will not complete. The Ring Engine

will restart the Ring Latency Measurement on each early Token arrival.

D6

TKPASS

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

service opportunity.

D5

D4

TKCAPT

CBERR

Token Captured: Indicates that a token has been captured.

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

while the Transmitter was in the Claim or Beacon state.

D3

DUPTKR

Duplicate Token Received: Indicates that a valid token was received while the Transmitter was in the

Transmit Data or Issue Token state.

D2

D1

D0

TRTEXP

TVXEXP

ENTRMD

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

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

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

Ð

from 0 to 1.

64

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

015h

Always

Register Bits

D7

D6

TKPASS

D5

TKCAPT

D4

D3

D2

D1

D0

RLVD

CBERR

DUPTKR

TRTEXP

TVXEXP

ENTRMD

Bit

D7

D6

D5

D4

D3

D2

D1

D0

Symbol

RLVD

Description

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

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

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

TKPASS

TKCAPT

CBERR

DUPTKR

TRTEXP

TVXEXP

ENTRMD

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

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

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

Ð

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

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

65

7.0 Control Information (Continued)

Counter Increment Latch Register (CILR)

The Counter Increment Latch Register (CILR) records the occurrence of any increment to the SMT Counters in the Ring Engine.

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

Read

Write

018h

Always

Conditional

Register Bits

D7

D6

TKRCVD

D5

D4

D3

D2

D1

D0

RES

FRTRX

FRNCOP

FRCOP

FRLST

FREI

FRRCV

Bit

D7

D6

Symbol

RES

Description

Reserved

TKRCVD

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

has been received.

D5

D4

D3

D2

D1

D0

FRTRX

FRNCOP

FRCOP

FRLST

FREI

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

has been transmitted.

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

could not be copied.

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

copied.

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

has been detected in the frame.

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

been isolated.

FRRCV

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

of a frame.

66

7.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 to the CPU.

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

Access Rules

Address

Read

Write

019h

Always

Register Bits

D7

D6

TKRCVD

D5

FRTRX

D4

D3

D2

D1

D0

RES

FRNCOP

FRCOP

FRLST

FREI

FRRCV

Bit

D7

D6

D5

D4

D3

D2

D1

D0

Symbol

RES

Description

Reserved

TKRCVD

FRTRX

FRNCOP

FRCOP

FRLST

FREI

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

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

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

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

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

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

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

FRRCV

67

7.0 Control Information (Continued)

Counter Overflow Latch Register (COLR)

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

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

Read

Write

01Ch

Always

Conditional

Register Bits

D7

D6

TKRCVD

D5

D4

D3

D2

D1

D0

RES

FRTRX

FRNCOP

FRCOP

FRLST

FREI

FRRCV

Bit

D7

D6

D5

D4

D3

D2

D1

D0

Symbol

RES

Description

Reserved

TKRCVD

FRTRX

FRNCOP

FRCOP

FRLST

FREI

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

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

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

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

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

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

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

FRRCV

68

7.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 to the CPU.

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

Access Rules

Address

Read

Write

01Dh

Always

Register Bits

D7

D6

TKRCVD

D5

FRTRX

D4

D3

D2

D1

D0

RES

FRNCOP

FRCOP

FRLST

FREI

FRRCV

Bit

D7

D6

D5

D4

D3

D2

D1

D0

Symbol

RES

Description

Reserved

TKRCVD

FRTRX

FRNCOP

FRCOP

FRLST

FREI

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

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

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

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

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

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

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

FRRCV

69

7.0 Control Information (Continued)

Internal Event Latch Register (IELR)

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

inconsistencies in the Receiver and Transmitter state machines.

After an internal state machine error 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.

e

the errored state until the internal state machine error condition is cleared (bit RSMERR and/or TSMERR is set to Zero).

In Diagnose mode (Mode.Diag

1), the Current Receive Status Register and Current Transmit Status Register are frozen with

Errors internal to the Ring Engine cause a MAC Reset.

Ð

Access Rules

Address

Read

Write

028h

Always

Conditional

Register Bits

D7

D6

RES

D5

D4

D3

D2

D1

D0

RES

TSM ERR

RSM ERR

RES

MPE

Bit

D7–D4

D3

Symbol

RES

Description

Reserved

TSMERR

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

causes bit MCRST of the Function Register to be set.

D2

RSMERR

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

causes bit MCRST of the Function Register to be set.

D1

D0

RES

MPE

Reserved

MAC Interface Parity Error: Indicates a Parity Error on the MAC Request Data bus (the internal bus

MRD (7:0) between the SI and MAC blocks) when parity is enabled on the MA Request Interface (bits

Ð

MRP of the MAC Mode Register 0 (MCMR0)) are set and pin TXACK is asserted).

70

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

Read

Write

02Ch

Always

Conditional

Register Bits

D7

D6

CCE

D5

D4

D3

D2

D1

D0

CWI

CPE

RES

PPE

Bit

Symbol

Description

D7

CWI

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

D6

D5

CCE

CPE

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.

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

D4–D1

D0

RES

PPE

Reserved

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

Ð

71

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

Access Rules

Address

Read

Write

02Dh

Always

Register Bits

D7

D6

CCE

D5

CPE

D4

D3

D2

D1

D0

ZERO

RES

PPE

Bit

D7

Symbol

ZERO

Description

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

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

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

Reserved

D6

CCE

CPE

RES

PPE

D5

D4–D1

D0

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

72

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

Read

Write

02Eh

Always

Data Ignored

Register Bits

D7

D6

IERR

D5

D4

D3

D2

D1

D0

ESE

RES

COE

CIE

TTE

RNG

Bit

D7

Symbol

Description

ESE

IERR

RES

COE

Exception Status Event Interrupt: Is set if any unmasked bits in the Exception Status Register are set.

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

Reserved

D6

D5–D4

D3

Counter Overflow Event Interrupt: Is set if any unmasked bits in the Counter Overflow Latch Register

are set.

D2

D1

D0

CIE

Counter Increment Event Interrupt: Is set if any unmasked bits in the Counter Increment Latch Register

are set.

TTE

RNG

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

Register are set.

Ring Event Interrupt: Is set if any unmasked bits in the Ring Event Latch Registers are set.

73

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

Read

Write

02Fh

Always

Register Bits

D7

D6

IERR

D5

RES

D4

D3

D2

D1

D0

ESE

RES

COE

CIE

TTE

RNG

Bit

D7

Symbol

Description

ESE

IERR

RES

COE

CIE

Exception Status Event Mask: This bit is used to mask ICR.ESE.

Internal Error Mask: This bit is used to mask ICR.IERR.

Reserved

D6

D5–D4

D3

Counter Overflow Event Mask: This bit is used to mask ICR.COE.

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

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

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

D2

D1

TTE

RNG

D0

74

7.0 Control Information (Continued)

7.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–F),

and Fixed Group Map (FGM0–1).

#

MAC Frame Information: Requested Target Token Rotation Time (TREQ0–3) and Transmit Beacon Type (TBT0–3)

#

7.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 registers 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 (MLA0–MLA5)

My Long Address (MLA0–MLA5) represent this station’s long 48-bit address.

Access Rules

Address

Read

Write

040–045h

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

MLA0

MLA1

MLA2

MLA3

MLA4

MLA5

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)

Note: MLA(47) should always be set to 0.

My Short Address (MSA0–MSA1)

My Short Address (MSA0–MSA1) represent this station’s short 16-bit address.

Access Rules

Address

Read

Write

046–047h

Stop Mode

Register Bits

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.

75

7.0 Control Information (Continued)

7.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 256 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) input signal.

Ð

Group Long Address (GLA0–GLA4)

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 One’s.

Access Rules

Address

Read

Write

048–04Ch

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

GLA0

GLA1

GLA2

GLA3

GLA4

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)

Note: GLA(47) should always be set to One.

Group Short Address (GSA0)

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

04Eh

Stop Mode

Register Bits

D7

GSA(15)

D6

GSA(14)

D5

D4

D3

D2

D1

D0

GSA0

GSA(13)

GSA(12)

GSA(11)

GSA(10)

GSA(9)

GSA(8)

Note: GSA(15) is not used in the comparison since the comparison will only be accomplished if the received DA(15) is a One.

76

7.0 Control Information (Continued)

Fixed Group Address MAP (FGM0–FGM1)

If the first 44 bits of a long DA, DA(47–4), or 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

hexadecimal equivalent of DA(3–0) can be used as the index. For example the broadcast address would index FGM(F).

Alternatively 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

058–059h

Stop Mode

Register Bits

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)

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.

Programmable Group Address MAP (PGM0–PGM1F)

If the first 40 bits of a long DA, DA(47–8), match the GLA or 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 hexadecimal 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 (1010 0010b) selects PGM14 bit 2.

It is possible to disable Long and Short Group Addressing by filling the Group Address Map with 0’s.

In the MACSI 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

070–07Fh

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

PGM0

PGM1

PGM2

PGM3

PGM4

PGM5

PGM6

PGM7

PGM8

PGM9

PGMA

PGMB

PGMC

PGMD

PGME

PGMF

PGM(7)

PGM(F)

PGM(6)

PGM(E)

PGM(5)

PGM(4)

PGM(3)

PGM(2)

PGM(1)

PGM(0)

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)

77

7.0 Control Information (Continued)

Access Rules

Address

Read

Write

060–06Fh

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

PGM10

PGM11

PGM12

PGM13

PGM14

PGM15

PGM16

PGM17

PGM18

PGM19

PGM1A

PGM1B

PGM1C

PGM1D

PGM1E

PGM1F

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)

7.5.3 Claim Information: Requested Target Token Rotation Time (TREQ)

The Requested Target Token Rotation Time 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. Bit TREQ(0) is transmitted last. TREQ is

therefore programmable with 20.48 ms resolution and a maximum value of 1.34 seconds.

Access Rules

Address

Read

Write

050–053h

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

TREQ0

TREQ1

TREQ2

TREQ3

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)

78

7.0 Control Information (Continued)

7.5.4 Beacon Information: Transmit Beacon Type (TBT)

Transmit Beacon Type 0 (TBT0) represents the Transmit Beacon Type to be transmitted in the Information field of a Beacon

frame. TBT1–TBT3 are not used by the Ring Engine.

When the Beacon state is reached as a result of a failed Claim process, the first byte of the Beacon Information field is forced to

Zero to produce a Beacon Type 0 as required by the MAC Standard.

When the Beacon state is reached as a result of a Beacon Request (when Function.BCN is set), bits TBT(31–24) are transmit-

ted as the Information field.

Access Rules

Address

Read

Write

054–057h

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

TBT0

TBT1

TBT2

TBT3

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)

7.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. These parameters are writable in Stop Mode.

The Timers include the following timers:

Asynchronous Priority Threshold (THSH1)

#

Maximum Token Rotation Time (TMAX)

#

Valid Transmission Timer (TVX)

#

Negotiated Target Rotation Time (TNEG0–3)

#

79

7.0 Control Information (Continued)

7.6.1 Asynchronous Priority Threshold (THSH1)

The Ring Engine currently supports one Asynchronous Priority Threshold in addition to the default threshold at TTRT. The

Asynchronous 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

087h

Always

Stop Mode

Register Bits

THSH1

D7

Zero

D6

Zero

D5

D4

D3

D2

D1

D0

Zero

THSH(3)

THSH(2)

THSH(1)

THSH(0)

THSH1(3–0)

Time remaining in THT 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.

80

7.0 Control Information (Continued)

7.6.2 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

For immediate transmissions from the transmit data state (T2), TMAX is always used to enforce an upper bound on the amount

of time a station may transmit. TRT is reset to TMAX on entry to state T2 on immediate requests.

Access Rules

Address

Read

Write

093h

Always

Stop Mode

Register Bits

TMAX

D7

Zero

D6

Zero

D5

D4

D3

D2

D1

D0

Zero

TMAX(3)

TMAX(2)

TMAX(1)

TMAX(0)

TMAX(3–0)

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

s

81

7.0 Control Information (Continued)

7.6.3 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

c

TVX has a maximum value of 1.34 seconds with a threshold of 40.96

2

ms. On a Master Reset TVX is set to the value of

6h which corresponds to 2.62 ms, the default specified by the FDDI MAC Standard.

Access Rules

Address

Read

Write

097h

Always

Stop Mode

Register Bits

D7

Zero

D6

D5

Zero

D4

D3

D2

D1

D0

TVX

Zero

TVX(3)

TVX(2)

TVX(1)

TVX(0)

TVX(3–0)

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

s

82

7.0 Control Information (Continued)

Negotiated Target Rotation Time (TNEG0–3)

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 (bit MARST in the Function Register 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

098–09Bh

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

TNEG0

TNEG1

TNEG2

TNEG3

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)

83

7.0 Control Information (Continued)

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

#

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

Since the Control Bus Interface is an 8-bit interface and the counters are 20 bits wide, a register holding scheme is implemented.

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 register 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/11705–45

FIGURE 7-2. Event Counters

84

7.0 Control Information (Continued)

Late Count Counter (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.

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

The Late Count Counter 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. Late Count Counter is a sticky counter at 15.

Events reported in the Token and Timer Event Latch Register (TELR0.CBERR, TELR0.TRTEXP) can be used to determine that

Late Count Counter has incremented. No overflow event is provided.

Access Rules

Address

Read

Write

09Fh

Always

N/A

Register Bits

D7

Zero

D6

D5

D4

D3

D2

D1

D0

LTCT

Zero

CT3

CT2

CT1

CT0

85

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

0A0–0A3h

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

FRCT0

FRCT1

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

FRCT2

FRCT3

CT15

CT7

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

0A4–0A7h

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

EICT0

EICT1

EICT2

EICT3

Zero

CT15

CT7

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

86

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

0A8–0ABh

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

LFCT0

LFCT1

LFCT2

LFCT3

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

CT15

CT7

Frame Copied Counter (FCCT)

The Frame Copied Counter (FCCT) maintains the count of the number of frames addressed to this station and successfully

copied. This counter can be used to accumulate station performance statistics.

The Frame Copied Counter is incremented when a frame which contains no errors and is addressed to this station is successful-

ly copied. Copied MAC and Void frames are not included in this count.

When Option.EMIND is set, this count also includes frames copied as a result of external matches as indicated by EA.

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 symbol do not cause this count to

increment, even if the frame is successfully copied.

Note that when in a promiscuous copy mode, this count will not increment for every frame copied, only for frames addressed to

this station that are copied.

Interrupts are available on increment (CILR.FRCOP) and when the 20-bit counter overflows and wraps around (COLR.FRCOP).

Access Rules

Address

Read

Write

0AC–0AFh

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

FCCT0

FCCT1

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

FCCT2

FCCT3

CT15

CT7

87

7.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 match occurs on the Destination Address, no errors were

detected in the frame, and the frame was not successfully copied (internal VCOPY signal not asserted by the System Interface).

Not Copied MAC frames and Void frames are not included in this count.

When Option.EMIND is set this count also includes frames not copied on external matches indicated by EA.

The handling of SMT NSA frames follows 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 symbol do not cause this count to increment, even if the frame is not successfully copied.

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

0B0–0B3h

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

FNCT0

FNCT1

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

FNCT2

FNCT3

CT15

CT7

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

0B4–0B7h

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

FTCT0

FTCT1

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

FTCT2

FTCT3

CT15

CT7

CT14

CT6

88

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

0B8–0BBh

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

TKCT0

TKCT1

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

TKCT2

TKCT3

CT15

CT7

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 (TELR0.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 (TELR0.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 Capture 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

Ð

(TELR0.RLVLD) is set and may cause an interrupt. When set, RELR.RLVLD indicates that RLCT will be valid to 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 TELR0.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). Note that if a duplicate of this MAC

address exists on the ring, the My Void frame will be stripped and the ring latency measurement will never complete.

Ð

Access Rules

Address

Read

Write

0BC–0BFh

Always

Stop Mode

Register Bits

D7

D6

D5

D4

D3

D2

D1

Zero

CT17

CT9

CT1

D0

Zero

CT16

CT8

CT0

RLCT0

RLCT1

Zero

CT14

CT6

Zero

CT13

CT5

Zero

CT12

CT4

Zero

CT19

CT11

CT3

Zero

CT18

CT10

CT2

RLCT2

RLCT3

CT15

CT7

89

7.0 Control Information (Continued)

System Interface Mode Register 0 (SIMR0)

The System Interface Mode Register 0 (SIMR0) is used to program major operating parameters for the System Interface of the

MACSI device. This register should be programmed only at power-on, or after a software Master Reset.

This register is cleared upon reset.

Access Rules

Address

Read

Write

100h

Always

Register Bits

D7

D6

D5

D4

D3

FLOW

D2

D1

D0

SMLB

SMLQ

VIRT

BIGEND

MRST

FABCLK

TEST

Bit

Symbol

Description

D0

TEST

Test Mode: Enables test logic, in which the transmitted frames counter will cause a service loss after four

frames, instead of 255 frames.

D1

FABCLK

Fast ABus Clock: For any AB CLK frequency greater than LBC (12.5 MHz), this bit must be zero. For an

Ð

AB CLK frequency equal to LBC, the User may optionally set this bit. Setting this bit causes a slight

Ð

e

LBC

optimization of the internal MACSI synchronization timing valid only for the case where AB CLK

Ð

12.5 MHz. National recommends that all users leave this bit as zero.

D2

D3

MRST

FLOW

Master Reset: When this bit is set, the indicate, Request, and Status/Space Machines are placed in Stop

Mode, and System Interface registers are initialized to the values shown in Table 7-2. This bit is cleared after

the reset is complete.

Flow Parity: When this bit is set, parity checking is enabled at the MAC Indicate Data (Receive Data)

interface. The MACSI device uses Odd parity at all interfaces. The System Interface reports parity errors in the

STAR.BPE bit (for receive data from the MAC) or the STAR.ERR (for descriptor fetch parity errors). Data

parity does not get checked at the ABus Interface. When this bit is set, the parity bit for each ABus data byte

flows with the data byte through the internal FIFO and across the MAC Request (Transmit) interface where it

is checked by the Ring Engine. Good parity is always generated on ABus. If this bit is reset, good parity is

generated at the MAC Request interface. For the MAC Indicate Data interface, the parity check includes the

frame’s FC through ED fields. When this bit is Zero, no parity is checked on the MAC Indicate Data interface.

In the BSI device, this bit also controlled the Control Bus Parity. In the MACSI device, Control Bus Parity is

enabled using the MCMode.CBP bit (see ‘‘MAC Mode Register 0 (MCMR0)’’).

For systems using parity on the ABus, the User must initialize the Receive burst FIFO RAM after reset by

doing a send-to-self of a frame at least 64 bytes in length.

e

1) data

D4

D5

D6

D7

BIGEND

VIRT

Big Endian Data Format: Selects between the Little Endian (BIGEND

format. SeeFigure 6-1.

0) or Big Endian (BIGEND

e

Virtual Address Mode: Selects between virtual (VIRT

ABus.

1) or physical (VIRT

0) address mode on the

SMLQ

SMLB

Small Queue: Selects the size of all Descriptor queues and lists. When SMLQ

e

0, the size is 4 kBytes; when

SMLQ

1, the size is 1 kBytes. Note that data pages are always 4 kBytes.

e

Small Bursts: Selects size of bursts on ABus. When SMLB

e

0, the MACSI device uses 1-, 4-, and 8-word

1, the MACSI device uses 1- and 4-word transfers.

transfers. When SMLB

90

7.0 Control Information (Continued)

System Interface Mode Register1 (SIMR1)

The System Interface Mode Register 1 (SIMR1) is used to program major operating parameters for the System Interface of the

MACSI device. This register should be programmed only at power-on, or after a software Master Reset.

This register is cleared upon reset. Access Rules

Address

Read

Write

101h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

AB A31

Ð

AB A30

Ð

AB A29

Ð

AB A28

Ð

ATM

ASM

RES

EAM

Bit

Symbol

EAM

Description

D0

Enhanced ABus Mode: This bit controls the Enhanced ABus Mode (EAM). This enhanced mode is

intended to reduce the amount of logic required to interface to the SBus. When this bit is reset, the

ABus operates as it does on the original BSI device (normal ABus mode). When this bit is set,

the AB A(31:28) bits within this register are sourced on the upper nibble of the address/data lines

Ð

during the address cycle. Read Data is strobed the cycle after the assertion of AB ACK. The AB BR

Ð Ð

signal is guaranteed to be deasserted for at least two cycles (seeFigure 6-8 through Figure 6-11 ). The

AB DEN pin becomes an input and the Error/Acknowledgment combinations are re-encoded.

Ð

e

1

EAM

AB ACK

0

EAM

AB ERR

Ð

AB ACK

Ð

AB DEN

Ð

AB ERR

Ð

Function

Ð

Ack(2)*

Ack(1)*

Ack(0)*

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

Wait Cycle

0

1

Word Acknowledgement

Retry

Error

Not Supported

D1

D2

RES

ASM

Reserved

Address Strobe Mode: The ASM bit controls the Address Strobe Mode. When this bit is reset, the

AB AS signal operates as it does on the BSI device. When this bit is set, the MACSI device generates

Ð

an AB AS signal which is designed to drive an address latch control line without additional logic (see

Ð

Figure 6-6 andFigure 6-7 ).

D3

ATM

Address Timing Mode: The ATM bit controls the Address Timing Mode. When this bit is reset, the

AB A(4:2) lines operate as they do on the BSI. These lines provide the demultiplexed address of the

Ð

next word to be accessed on the ABus. When the ATM bit is set, the MACSI device provides the

address of thecurrent word being accessed on the ABus (seeFigure 6-6 andFigure 6-7 ). To use the

demultiplexed address pins AB A (27:2) on MACSI revision A through C, the User must set the ATM

Ð

t

bit. For MACSI revision D and later (SI revision 0x00000058), the User may use the demultiplexed

address pins AB A (27:2) with ATM set or reset.

Ð

e

information on the upper nibble of the AB AD bus during the address cycle. In Enhanced ABus mode

D7–D4

AB A(31:28)

Ð

AB Address(31:28): In normal operation (MR1.EAM

Ð

0), the MACSI device encodes channel

Ð

1), the upper nibble of the address lines are driven with the data pattern which the user

e

(MR1.EAM

has stored in these four bits, AB A(31:28).

Ð

91

7.0 Control Information (Continued)

Pointer RAM Control and Address Register (PCAR)

The Pointer RAM Control and Address Register (PCAR) is used to program the parameters for the PTOP (Pointer RAM

Operation) service function, in which data is written to or read from a Pointer RAM Register.

This register is not altered upon reset.

Access Rules

Address

Read

Write

102h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

BP1

BP0

PTRW

A4

A3

A2

A1

A0

Bit

Symbol

Description

D4–D0

A4–A0

Pointer RAM Address: These five bits contain the Pointer RAM Register address for a subsequent

PTOP service function.

D5

PTRW

PTOP Read/Write: This bit determines whether a PTOP service function will be a read from the Pointer

e

RAM Register to the mailbox in memory (PTRW

e

1), or a write to the Pointer RAM Register from the

mailbox (PTRW

0).

D7–D6

BP1–BP0

Byte Pointer: These two bits are used to program an internal byte pointer for accesses to the 28-bit

Mailbox Address Register. They are normally set to Zero to initialize the byte pointer for four successive

writes (most-significant byte first) and are automatically incremented after each write. Because this

register is not altered upon reset, it is important that these bits be explicitly configured before accessing

the Mailbox Address Register.

Mailbox Address Register (MBAR)

The Mailbox Address Register (MBAR) is used to program the word-aligned 28-bit memory address of the mailbox used in the

data transfer of the PTOP (Pointer RAM Operation) service function.

The address of the register is used as a window into four internal byte registers. The four byte registers are loaded by successive

writes to the address after first setting the BP1–0 bits in the Pointer RAM Control and Address Register to Zero. The bytes must

be loaded most-significant byte first. The MACSI device increments the byte pointer internally after each write or read. Mailbox

Address bits 0 and 1 forced internally to Zero.

The four internal byte registers are initialized to a 28-bit System Interface Revision code upon reset. The System Interface

Revision code remains until it is overwritten by the host. The BP1–0 bits in the PCAR must be initialized before accessing the

MBAR to fetch the System Interface Revision code.

Access Rules

Address

Read

Write

103h

Always

Register Bits

7

0

[

Mailbox Address 27:24

]

[

Mailbox Address 23:16

[

Mailbox Address 15:8

]

[

Mailbox Address 7:0

]

92

7.0 Control Information (Continued)

Master Attention Register (MAR)

The Master Attention Register (MAR) collects enabled attentions from the State Attention Register, Service Attention Register,

No Space Attention Register, Request Attention Register, and Indicate Attention Register. If the Notify bit in the Master Notify

Register and the corresponding bit in the MAR are set to One, the INT1 pin is forced to LOW and thus triggers an interrupt.

Writes to the Master Attention Register are permitted, but do not change the contents.

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

Access Rules

Address

Read

Write

104h

Always

Data Ignored

Register Bits

D7

D6

D5

D4

D3

INA

D2

D1

D0

STA

NSA

SVA

RQA

RES

Bit

D2–D0

D3

Symbol

Description

RES

INA

Reserved

Indicate Attention Register: Is set if any bit in the Indicate Attention Register is set.

Request Attention Register: Is set if any bit in the Request Attention Register is set.

Service Attention Register: Is set if any bit in the Service Attention Register is set.

No Space Attention Register: Is set if any bit in the No Space Attention Register is set.

State Attention Register: Is set if any bit in the State Attention Register is set.

D4

RQA

SVA

NSA

STA

D5

D6

D7

Master Notify Register (MNR)

The Master Notify Register (MNR) is used to enable attentions in the Master Attention Register (MAR). If a bit in Register MNR

and the corresponding bit in Register MAR are set to One, the INT1 signal is asserted to cause an interrupt.

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

Access Rules

Address

Read

Write

105h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

STAN

NSAN

SVAN

RQAN

INAN

RES

Bit

D2–D0

D3

Symbol

RES

Description

Reserved

INAN

Indicate Attention Register Notify: This bit is used to enable the INA bit in Register MAR.

Request Attention Register Notify: This bit is used to enable the RQA bit in Register MAR.

Service Attention Register Notify: This bit is used to enable the SVA bit in Register MAR.

No Space Attention Register Notify: This bit is used to enable the NSA bit in Register MAR.

State Attention Register Notify: This bit is used to enable the STA bit in Register MAR.

D4

RQAN

SVAN

NSAN

STAN

D5

D6

D7

93

7.0 Control Information (Continued)

State Attention Register (STAR)

The State Attention Register (STAR) controls the state of the Indicate, Request, and Status/Space Machines. It also records

parity, internal logic and ABus transaction errors. Each bit may be enabled by setting the corresponding bit in the State Notify

Register.

This register is set to the value 07h upon reset.

Access Rules

Address

Read

Write

106h

Always

Conditional

Register Bits

D7

D6

D5

D4

D3

CMDE

D2

D1

D0

ERR

BPE

CPE

CWI

SPSTOP

RQSTOP

INSTOP

Bit

Symbol

Description

D0

INSTOP

Indicate Stop: This bit is set by the host to place the Indicate Machine in Stop Mode. It is also set upon reset.

Three different conditions cause the MACSI device to set this bit. The first is an internal error. This is caused

by a bad tag read out of the Indicate Data FIFO. This is a hardware error. The next condition is an invalid

state. This is a hardware error where the Indicate Machine state bits contain an illegal pattern. The final

condition is when the user programs an illegal header length for Header/Info sorting mode. An invalid value is

any value less than four words.

This bit is set by serious hardware failures or illegal software operations. Therefore it is recommended that

the entire MACSI device be reset if this bit should get set during normal operation.

D1

D2

RQSTOP

SPSTOP

Request Stop: This bit is set by the host to place the Request Machine in Stop Mode. It is also set upon

reset. The MACSI device will set this bit if it detects that the Request Machine has entered an illegal state.

This is a hardware error. The MACSI device will also set this bit if an ABus error is detected during any

Request Operation. This includes REQ, ODUD, and ODU fetches, and CNF writes.

This bit is set by serious hardware failures or ABus errors. Therefore it is recommended that the entire MACSI

device be reset if this bit should get set during normal operation

Status/Space Stop: This bit is set by the host to place the Status/Space Machine in Stop Mode. It is also set

upon reset. In addition, the MACSI device will set this bit upon detecting an unrecoverable error. An

unrecoverable error is an ABus error during a PSP fetch or a Pointer RAM Operation, (PTOP). In STOP Mode,

only PTOP or LMOP service functions may be performed.

This bit is set by ABus errors during critical Status/Space operations. Therefore it is recommended that the

entire MACSI device be reset if this bit should get set during normal operation. This reset should include

reloading of Pointer RAM values and restarting the PSP queues.

D3

D4

CMDE

Command Error: Indicates that the host performed an invalid operation. This occurs when an invalid value is

loaded into the Indicate Header Length Register (which also sets the INSTOP attention). This bit is cleared

upon reset.

This bit is set when software performs an illegal operation. This indicates either a software bug or the

improper operation of the processor. Therefore it is recommended that the entire MACSI device be reset if

this bit should get set during normal operation.

CWI

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. It is also set when 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. CWI bit does not contribute to setting the STA bit of the Master

Attention Register because its associated Notify bit is always 0. This bit is cleared upon reset.

D5

D6

D7

CPE

BPE

ERR

Control Bus Parity Error: Indicates a parity error detected on CBD7–0. If there is a Control Bus parity error

during a host write, the write is suppressed. Control Bus parity errors are reported when flow-through parity is

enabled (the FLOW bit of the Mode Register is set). This bit is cleared upon reset.

BMAC Device Parity Error: Indicates parity error detected on MID7–0. This bit is cleared upon reset. This bit

is only set if FLOW (parity enable) is set and the error occurred on a frame that the MACSI device has

decided to copy or if it occurred before the copy decision was made.

Error: This bit is set by the MACSI device when a non-recoverable error occurs. This includes any ABus

transaction error or an internal state machine error. For MACSI revision D or later, a descriptor fetch parity

error will also set this bit if the User has enabled parity checking via the SIMR0.FLOW bit. This bit is cleared

upon reset.

94

7.0 Control Information (Continued)

State Notify Register (STNR)

The State Notify Register (STNR) is used to enable bits in the State Attention Register (STAR). If a bit in the STNR is set to One,

the corresponding bit in Register STAR will be applied to the Master Attention Register, which can be used to generate an

interrupt to the host.

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

Access Rules

Address

Read

Write

107h

Always

Register Bits

D7

D6

D5

D4

D3

CMDEN

D2

D1

D0

ERRN

BPEN

CPEN

CWIN

SPSTOPN

RQSTOPN

INSTOPN

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

INSTOPN

RQSTOPN

SPSTOPN

CMDEN

CWIN

Description

Indicate Stop Notify: This bit is used to enable the INSTOP bit in Register STAR.

Indicate Stop Notify: This bit is used to enable the RQSTOP bit in Register STAR.

Status/Space Stop Notify: This bit is used to enable the SPSTOP bit in Register STAR.

Command Error Notify: This bit is used to enable the CMDE bit in Register STAR.

Conditional Write Inhibit Notify: This bit is always Zero. CWI is always masked.

Control Bus Parity Error Notify: This bit is used to enable the CPE bit in Register STAR.

BMAC Device Parity Error Notify: This bit is used to enable the BPE bit in Register STAR.

Error Notify: This bit is used to enable the ERR bit in Register STAR.

CPEN

BPEN

ERRN

95

7.0 Control Information (Continued)

Service Attention Register (SAR)

The Service Attention Register (SAR) is used to present the attentions for the service functions. Each bit may be enabled by

setting the corresponding bit in the State Notify Register.

This register is set to the value 0Fh upon reset.

Access Rules

Address

Read

Write

108h

Always

Conditional

Register Bits

D7

D6

D5

D4

D3

ABR0

D2

D1

D0

RES

ABR1

LMOP

PTOP

Bit

Symbol

PTOP

Description

D0

Pointer RAM Operation: This bit is cleared by the host to cause the MACSI device to transfer data

between a Pointer RAM Register and a predefined mailbox location in memory. The Pointer RAM Control

and Address Register contains the Pointer RAM Register address and determines the direction of the

transfer (read or write). The memory address is defined via the Mailbox Address Register. This bit is set by

the MACSI device after it performs the data transfer.

e

Address Register.

While PTOP

0, the host must not alter the Pointer RAM Address and Control Register or the Mailbox

D1

LMOP

Limit RAM Operation: This bit is cleared by the host to cause the MACSI device to transfer data between

a Limit RAM Register and the Limit Data and Limit Address Registers. The Limit Address Register

contains the Limit RAM Register address and determines the direction of the transfer (read and write).

This bit is set by the MACSI device after it performs the data transfer.

e

While LMOP

0, the host must not alter either the Limit Address or Limit Data Register.

D2

D3

ABR1

ABR0

RES

Abort Request RCHN1: This bit is cleared by the host to abort a Request on RCHN1. This bit is set by the

MACSI device when RQABORT ends a request on RCHN1. The host may write a 1 to this bit, which may

or may not prevent the request from being aborted. When this bit is cleared by the host, the USR1 bit in

the Request Attention Register is set and further processing on RCHN1 is halted.

Abort Request RCHN0: This bit is cleared by the host to abort a Request on RCHN0. This bit is set by the

MACSI device when RQABORT ends a request on RCHN0. The host may write a 1 to this bit, which may

or may not prevent the request from being aborted. When this bit is cleared by the host, the USR0 bit in

the Request Attention Register is set and further processing on RCHN0 is halted.

D7–D4

Reserved

96

7.0 Control Information (Continued)

Service Notify Register (SNR)

The Service Notify Register (SNR) is used to enable attentions in the Service Attention Register (SAR). If a bit in Register SNR is

set to One, the corresponding bit in Register SAR will be applied to the Master Attention Register, which can be used to

generate a interrupt to the host.

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

Access Rules

Address

Read

Write

109h

Always

Register Bits

D7

D6

D5

D4

D3

ABRON

D2

D1

D0

RES

ABR1N

LMOPN

PTOPN

Bit

D0

Symbol

PTOPN

Description

Pointer RAM Operation Notify: This bit is used to enable the PTOP bit in Register SAR.

Limit RAM Operation Notify: This bit is used to enable the LMOP bit in Register SAR.

Abort Request RCHN1 Notify: This bit is used to enable the ABR1 bit in Register SAR.

Abort Request RCHN0 Notify: This bit is used to enable the ABR0 bit in Register SAR.

Reserved

D1

LMOPN

ABR1N

ABR0N

RES

D2

D3

D4–D7

97

7.0 Control Information (Continued)

No Space Attention Register (NSAR)

The No Space Attention Register (NSAR) presents the attentions generated when the CNF, PSP, or IDUD Queues run out of

space. The host may set any attention bit to cause an attention for test purposes only, though this should not be done during

normal operation.

The No Data Space attentions are set and cleared by the MACSI device automatically. The No Status Space attentions are set

by the MACSI device, and must be cleared by the host.

Upon reset this register is set to 0xff.

Access Rules

Address

Read

Write

10Ah

Always

Conditional

Register Bits

D7

D6

D5

D4

D3

LDI1

D2

D1

D0

NSR0

NSR1

LDI0

NSI0

NSI1

LDI2

NSI2

Bit

Symbol

Description

D0

NSI2

No Status Space on ICHN2: This bit is set by the MACSI device upon a Reset, or when an IDUD has been

written to the next-to-last available entry in the Indicate Channel’s IDUD Status Queue. When this occurs, the

MACSI device stops copying on ICHN2 and the last IDUD is written with special status. This bit must be

cleared by the host before the MACSI device will resume copying on this Channel. Note that this bit should

only be cleared after the appropriate limit register has been updated to give the MACSI more status space.

D1

LDI2

Low Data Space on ICHN2: This bit is set by the MACSI device upon Reset, or when a PSP is prefetched

from ICHN2’s last PSP Queue location (as defined by the PSP Queue Limit Register). Note that the amount of

warning is dependent on the length of the frame. There will always be one more page (4 kBytes) available for

the MACSI device when this attention is generated. Another FDDI maximum-length frame (after the current

one) will not fit in this space. If PSP fetching was stopped because there were no more PSP entries, fetching

will resume automatically when the PSP Queue Limit Register is updated. This bit will be cleared automatically

when the new PSP Descriptors are fetched. This bit should never be cleared directly by software. Clearing this

bit can cause the MACSI device to fetch invalid PSP descriptors.

D2

D3

NSI1

LDI1

No Status Space on ICHN1: This bit is set by the MACSI device upon a Reset, or when an IDUD has been

written to the next-to-last available entry in the Indicate Channel’s IDUD Status Queue. When this occurs, the

MACSI device stops copying on ICHN1 and the last IDUD is written with special status. This bit must be

cleared by the host before the MACSI device will resume copying on this Channel. Note that this bit should

only be cleared after the appropriate limit register has been updated to give the MACSI device more status

space.

Low Data Space on ICHN1: This bit is set by the MACSI device upon Reset, or when a PSP is prefetched

from ICHN1’s last PSP Queue location (as defined by the PSP Queue Limit Register). Note that the amount of

warning is dependent on the length of the frame. There will always be one more page (4 kBytes) available for

the MACSI device when this attention is generated. Another FDDI maximum-length frame (after the current

one) will not fit in this space. If PSP fetching was stopped because there were no more PSP entries, fetching

will resume automatically when the PSP Queue Limit Register is updated. This bit will be cleared automatically

when the new PSP Descriptors are fetched. This bit should never be cleared directly by software. Clearing this

bit can cause the MACSI device to fetch invalid PSP descriptors.

98

7.0 Control Information (Continued)

Bit

Symbol

Description

D4

NSI0

No Status Space on ICHN0: This bit is set by the MACSI device upon a Reset, or when an IDUD has been

written to the next-to-last available entry in the Indicate Channel’s IDUD Status Queue. When this occurs, the

MACSI device stops copying on ICHN0 and the last IDUD is written with special status. This bit must be

cleared by the host before the MACSI device will resume copying on this Channel. Note that this bit should

only be cleared after the appropriate limit register has been updated to give the MACSI device more status

space.

D5

LDI0

Low Data Space on ICHN0: This bit is set by the MACSI device upon Reset, or when a PSP is prefetched

from ICHN0’s last PSP Queue location (as defined by the PSP Queue Limit Register). Note that the amount of

warning is dependent on the length of the frame. There will always be one more page (4 kBytes) available for

the MACSI device when this attention is generated. Another FDDI maximum-length frame (after the current

one) will not fit in this space. If PSP fetching was stopped because there were no more PSP entries, fetching

will resume automatically when the PSP Queue Limit Register is updated. This bit will be cleared automatically

when the new PSP Descriptors are fetched. This bit should never be cleared directly by software. Clearing this

bit can cause the MACSI device to fetch invalid PSP descriptors.

D6

NSR1

No Status Space on RCHN1: This bit is set by the MACSI device upon a Reset, or when it has written a CNF

Descriptor to the next-to-last Queue location. Due to internal pipelining, the MACSI device may write up to two

more CNFs to the Queue after this attention is generated. Thus the Host must set the CNF Queue Limit

Register to be one less than the available space in the Queue. This bit (as well as the USR attention bit) must

be cleared by the Host before the MACSI device will continue to process requests on RCHN1. Note that this

bit should only be cleared after the appropriate limit register has been updated to give the MACSI device more

status space.

D7

NSR0

No Status Space on RCHN0: This bit is set by the MACSI device upon Reset, or when it has been written a

CNF Descriptor to the next-to-last Queue location. Due to internal pipelining, the MACSI device may write up to

two more CNFs to the Queue after this attention is generated. Thus the Host must set the CNF Queue Limit

Register to be one less than the available space in the Queue. This bit (as well as the USR attention bit) must

be cleared by the Host before the MACSI device will continue to process requests on RCHN0. Note that this

bit should only be cleared after the appropriate limit register has been updated to give the MACSI device more

status space.

99

7.0 Control Information (Continued)

No Space Notify Register (NSNR)

The No Space Notify Register (NSNR) is used to enable attentions in the No Space Attention Register (NSAR). If a bit in

Register NSNR is set to One, the corresponding bit in Register NSAR will be applied to the Master Attention Register, which can

be used to generate an interrupt to the host.

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

Access Rules

Address

Read

Write

10Bh

Always

Register Bits

D7

D6

D5

D4

D3

LDI1N

D2

D1

D0

NSR0N

NSR1N

LDI0N

NSI0N

NSI1N

LDI2N

NSI2N

Bit

Symbol

NSI2N

LDI2N

NSI1N

LDI1N

NSI0N

LDI0N

NSR1N

NSR0N

Description

D0

D1

D2

D3

D4

D5

D6

D7

No Status Space on ICHN2 Notify: This bit is used to enable the NSI2 bit in Register NSAR.

Low Data Space on ICHN2 Notify: This bit is used to enable the LDI2 bit in Register NSAR.

No Status Space on ICHN2 Notify: This bit is used to enable the NSI1 bit in Register NSAR.

Low Data Space on ICHN2 Notify: This bit is used to enable the LDI1 bit in Register NSAR.

No Status Space on ICHN2 Notify: This bit is used to enable the NSI0 bit in Register NSAR.

Low Data Space on ICHN2 Notify: This bit is used to enable the LDI0 bit in Register NSAR.

No Status Space on ICHN2 Notify: This bit is used to enable the NSR1 bit in Register NSAR.

Low Data Space on ICHN2 Notify: This bit is used to enable the NSR0 bit in Register NSAR.

Limit Address Register (LAR)

The Limit Address Register (LAR) is used to program the parameters for an LMOP (Limit RAM Operation) service function.

This register is not altered upon reset.

Access Rules

Address

Read

Write

10Ch

Always

Register Bits

D7

D6

D5

D4

D3

LMRW

D2

D1

D0

LRA3

LRA2

LRA1

LRA0

RES

LRD8

Bit

Symbol

LRD8

Description

D0

Limit RAM Data Bit 8: This bit contains the most-significant data bit read or written from the

addressed limit RAM Register. Bits LDR8 and LDR7 are ‘‘don’t cares’’ when using small (1 kByte)

queues.

D2–D1

D3

RES

Reserved

LMRW

LMOP Read/Write: This bit determines whether a LMOP service function will be a read

e

0).

e

(LMRW)

1) or write (LMRW

D4–D7

LRA3–LRA0

Limit RAM Register Address: Used to program the Limit RAM Register address for a subsequent

LMOP service function.

100

7.0 Control Information (Continued)

Limit Data Register (LDR)

The Limit Data Register (LDR) is used to hold the 8 least-significant Limit RAM data bits transferred in an LMOP service function.

(The most-significant data bit is in the Limit Address Register.)

This register is not altered upon reset.

Access Rules

Address

Read

Write

10Dh

Always

Register Bits

D7

D6

D5

D4

D3

LRD3

D2

D1

D0

LRD7

LRD6

LRD5

LRD4

LRD2

LRD1

LRD0

Bit

Symbol

Description

D7–D0

LRD7–0

Limit RAM Data Bit 7–0: This bit contains the least-significant data bit read or written from or to a Limit

RAM Register in an LMOP service function. Bit LDR7 is a ‘‘don’t care’’ when using small (1 kByte)

queues.

101

7.0 Control Information (Continued)

Request Attention Register (RAR)

The Request Attention Register (RAR) is used to present exception, breakpoint, request complete, and unserviceable request

attentions generated by each Request Channel. Each bit may be enabled by setting the corresponding bit in the Request Notify

Register.

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

Access Rules

Address

Read

Write

10Eh

Always

Conditional

Register Bits

D7

D6

D5

D4

D3

USRR1

D2

D1

D0

USRR0

RCMR0

EXCR0

BRKR0

RCMR1

EXCR1

BRKR1

Bit

Symbol

Description

D0

BRKR1

Breakpoint on RCHN1: Is set by the MACSI device when a CNF Descriptor is written on RCHN1. No action is

taken by the MACSI device if the host sets this bit.

D1

EXCR1

Exception on RCHN1: Is set by the MACSI device when an exception occurs on RCHN1. An exception

condition consists of one of the following events: ABus Error, Consistency Failure (REQ or ODUD), BMAC

MAC Reset, Timeout (TRT expires), BMAC abort (MAC frame received or FC/Request Class inconsistency),

RINGOP change, host abort (via SAR register), FIFO underrun, or confirmation exception (for full

Confirmation). No action is taken by the MACSI device if the host sets this bit.

This bit indicates that a request on RCHN1 did not complete normally. This implies that an exception event

occurred or that the Request is improperly formed. The corresponding Confirmation (CNF) Descriptor will give

more status about the failure. The additional information in the CNF descriptor should be used to make a

decision about the severity of the error. If the exception was caused by an ABus error, the RQSTOP will also

be set.

D2

D3

RCMR1

USRR1

Request Complete on RCHN1: Is set by the MACSI device when it has completed processing a Request

object on RCHN1 (note that the MACSI may set this bit before writing the CNF descriptor to the CNF queue).

This completion may be a normal completion where a request object was transmitted without error. It may also

be an abnormal completion due to one of the exception conditions listed above in EXCR1. No action is taken if

the Host sets this bit.

Unserviceable Request on RCHN1: Is set by the MACSI device when a Request cannot be processed on

RCHN1. This occurs when the Request Class is inappropriate for the current ring state (e.g., Asynchronous

e

transmission while RINGOP

0), or when there is no CNF status space, or when the host aborts a request by

clearing the ABR bit in the Service Attention Register. While this bit is set, no requests will be processed on

RCHN1.

The host must clear this bit to resume request processing. If the USRR1 was set due to lack of CNF space, this

condition must be corrected by giving the MACSI device more CNF space before restarting the channel. If it

was due to a request class/RINGOP incompatibility, then the reason for the incompatibility must be resolved.

D4

BRKR0

Breakpoint on RCHN0: Is set by the MACSI device when a CNF Descriptor is written on RCHN0. No action is

taken by the MACSI device if the host sets this bit.

102

7.0 Control Information (Continued)

Bit

Symbol

Description

D5

EXCR0

Exception on RCHN0: This bit is set by the MACSI device when an exception occurs on RCHN0. An

exception condition consists of one of the following events: ABus Error, Consistency Failure (REQ or ODUD),

BMAC MAC Reset, Timeout (TRT expires), BMAC abort (MAC frame received or FC/Request Class

inconsistency), RINGOP change, host abort (via SAR register), FIFO underrun, or confirmation exception (for

full Confirmation). No action is taken by the MACSI device if the host sets this bit.

This bit indicates that a request on RCHN0 did not complete normally. This implies that an exception event

occurred or that the Request is improperly formed. The corresponding Confirmation (CNF) Descriptor will give

more status about the failure. The additional information in the CNF descriptor should be used to make a

decision about the severity of the error. If the exception was caused by an ABus error, the RQSTOP will also

be set.

D6

D7

RCMR0

USRR0

Request Complete on RCHN0: Is set by the MACSI device when it has completed processing a Request

object on RCHN0. This completion may be a normal completion where a request object was transmitted

without error. It may also be an abnormal completion due to one of the exception conditions listed above in

EXCR0. This bit, (together with the Breakpoint bit BRKR0) indicates that there are CNF descriptors to be

processed. No action is taken if the Host sets this bit.

Unserviceable Request on RCHN0: This bit is set by the MACSI device when a Request cannot be

processed on RCHN0. This occurs when the Request Class is inappropriate for the current ring state (e.g.,

e

Asynchronous transmission while RINGOP

0), or when there is no CNF status space, or when the host

aborts a request by clearing the ABR bit in the Service Attention Register. While this bit is set, no requests will

be processed on RCHN0.

The host must clear this bit to resume request processing. If the USRR0 was set due to lack of CNF space, this

condition must be corrected by giving the MACSI device more CNF space before restarting the channel. If it

was due to a request class/RINGOP incompatibility, then the reason for the incompatibility must be resolved.

103

7.0 Control Information (Continued)

Request Notify Register (RNR)

The Request Notify Register (RNR) is used to enable attentions in the Request Attention Register (RAR). If a bit in Register

RNR is set to One, the corresponding bit in Register RAR will be applied to the Master Attention Register, which can be used to

generate an interrupt to the host.

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

Access Rules

Address

Read

Write

10Fh

Always

Register Bits

D7

D6

D5

D4

D3

USRR1N

D2

D1

D0

USRR0N

RCMR0N

EXCR0N

BRKR0N

RCMR1N

EXCR1N

BRKR1N

Bit

D0

D1

D2

D3

D4

D5

D6

D7

Symbol

BRKR1N

EXCR1N

RCMR1N

USRR1N

BRKR0N

EXCR0N

RCMR0N

USRR0N

Description

Breakpoint on RCHN1 Notify: This bit is used to enable the BRKR1 bit in Register RAR.

Exception on RCHN1 Notify: This bit is used to enable the EXCR1 bit in Register RAR.

Request Complete on RCHN1 Notify: This bit is used to enable the RCMR1 bit in Register RAR.

Unserviceable Request on RCHN1 Notify: This bit is used to enable the USRR1 bit in Register RAR.

Breakpoint on RCHN0 Notify: This bit is used to enable the BRKR0 bit in Register RAR.

Exception on RCHN0 Notify: This bit is used to enable the EXCR0 bit in Register RAR.

Request Complete on RCHN0 Notify: This bit is used to enable the RCMR0 bit in Register RAR.

Unserviceable Request on RCHN0 Notify: This bit is used to enable the USRR0 bit in Register RAR.

104

7.0 Control Information (Continued)

Request Channel 0 and 1 Configuration Registers 0 (R0CR0 and R1CR0)

The two Request Configuration Registers 0 (R0CR0 and R1CR0) are programmed with operational parameters for each of the

Request Channels. Additional Request Channel parameters are configured in Request Configuration Registers 1. These regis-

ters may only be altered between Requests, i.e., while the particular Request Channel does not have a Request loaded.

These registers are not altered upon reset.

Access Rules

Address

Read

Write

110–111h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

TT1

TT0

PRE

HLD

FCT

SAT

VST

FCS

Bit

Symbol

Description

D0

FCS

Frame Check Sequence Disable: When this bit is set, the MACSI device asserts the FCST signal throughout

the request. This drives the Ring Engine FCST signal. This bit is used to program the Ring Engine (MAC) not to

concatenate its generated FCS to the transmitted frame. The Valid FCS bit in the Expected Frame Status

Register independently determines whether a frame needs a valid FCS to meet the matching frame criteria.

D1

D2

VST

SAT

Vold Stripping: When this bit is set, the MACSI device asserts the STRIP signal out throughout the request.

This drives the Ring Engine STRIP (Void Strip) signal. The STRIP signal may also drive the Ring Engine SAT

signal, depending on the state of the BOSEL bit. See ‘‘MAC Mode Register 2 (MCMR2)’’.

Source Address Transparency: When this bit is set, the MACSI device asserts the SAT output signal

throughout the request. This drives the Ring Engine SAIGT signal. It may optionally drive the SAT signal

depending upon the setting of the BOSEL bit. See ‘‘MAC Mode Register 2 (MCMR2)’’. When SAT is set, Full

Confirmation requires the use of the EM (External SA Match) signal.

D3

FCT

Frame Control Transparency: When this bit is set, the FC will be sourced from the ODU (not the REQ.First or

e

1, only the C, L and r bits must match.

REQ.Only Descriptor). When Full Confirmation is enabled and FCT

e

0, all bits of the FC in returning frames

must match the FC field in the REQ Descriptor; if FCT

Note that since the MACSI device decodes the REQ.F Descriptor FC field to determine whether to assert

RQCLM/RQBCN, FC transparency may be used to send Beacons or Claims in any ring non-operational state,

as long as the FC in the REQ Descriptor is not set to Beacon or Claim. By programming a Beacon or Claim FC

in the REQ Descriptor, then using FC transparency, any type of frame may be transmitted in the Beacon or

Claim state.

D4

HLD

Hold: When this bit is set, the MACSI device will not end a service opportunity until the Request is complete.

When this bit is Zero, the MACSI device ends the service opportunity on the Request Channel when all of the

following conditions are met:

1. There is no valid request active on the Request Channel.

2. The service class is non-immediate.

3. There is no data in the FIFO.

4. There is no valid REQ fetched by the MACSI device.

e

RCHN1, regardless of the state of the PRE bit (except for Immediate service classes). When HLD

This bit also affects Prestaging on RCHN1 (Request Channel 1). When HLD

0, prestaging is enabled on

e

1,

prestaging is determined by the PRE bit. This option can potentially waste ring bandwidth, but may be required

(particularly on RCHN0, Request Channel 0) if a guaranteed service time is required.

When using the Repeat option, HLD is required for small frames. If HLD is not used, the other Request

Channel will be checked for service before releasing the token between frames. This may not be the desired

action, particularly if there is a request on RCHN1 that needs servicing after the completion of RCHN0’s

Repeated Request.

105

7.0 Control Information (Continued)

Bit

Symbol

Description

D5

PRE

Preempt/Prestage: When this bit is set, preemption is enabled for RCHN0, and prestaging is enabled for

RCHN1 (prestaging is always enabled for RCHN0). When this bit is Zero, preemption is disabled and

Prestaging is enabled on the RCHN0.

When preemption is enabled, RCHN0 preempts a (non-committed) frame of RCHN1 already in the FIFO,

causing it to be purged and refetched after RCHN0’s request has been serviced. When the Request

Machine servicing on RCHN1 and a request on RCHN0 becomes active, if preemption is enabled on

RCHN0, the Request Machine will finish transmitting the current frame on RCHN1, then release the token

and move back to the start state. This has the effect of reprioritization of the Request Channels, thus

ensuring that frames on RCHN0 are transmitted at the next service opportunity. When RCHN0 has been

serviced, transmission will continue on RCHN1 with no loss of data.

When prestaging is enabled, the next frame for RCHN1 is staged (ODUs are loaded into the FIFO before

the token arrives). If prestaging is not enabled, the Request Machine waits until the token is captured

before staging the first frame. Once the token is captured, the Request Machine begins fetching data, and

when the FIFO threshold has been reached, transmits the data on the Request Channel. For requests with

an Immediate service class, prestaging is not applicable.

When this bit is Zero, preemption is disabled for RCHN0, and request on RCHN1 will not be prestaged

unless the HLD bit is Zero, in which case RCHN1 will prestage data regardless of the setting of the PRE

bit.

Note that when prestaging is not enabled on RCHN1, data is not staged until the token is captured. Since

there is no data in the FIFO (if there is no active request on RCHN0), the MACSI device will immediately

release the token if the HLD option is not set.

D7–D6

TT1–0

Transmit Threshold: These bits in conjunction with the EFT bit, determine the threshold on the output

data FIFO before the MACSI device requests transmission. See ‘‘Request Channel 0 and 1 Configuration

Registers 1 (R0CR1 and R1CR1)’’.

TT1

0

TT0

0

Threshold Value

8 Words or 512 Words

16 Words or Reserved

128 Words or Reserved

256 Words or End of Frame

0

1

0

1

106

7.0 Control Information (Continued)

Request Channel 0 and 1 Expected Frame Status Registers (R0EFSR and R1EFSR)

The Expected Frame Status Registers (R0EFSR and R1EFSR) define the matching criteria used for Full Confirmation of

returning frames on each Request Channel. A returning frame must meet the programmed criteria to be counted as a matching

returning frame on each Request Channel. A returning frame must meet the programmed criteria to be counted as a matching

returning frame.

These registers are not altered upon reset.

Access Rules

Address

Read

Write

112–113h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

VDL

VFCS

EE1

EE0

EA1

EA0

EC1

EC0

Bit

Symbol

EC1–0

Description

D1–D0

Expected C Indicator:

EC1

EC0

Value

Any

R

0

1

0

1

0

1

S

R or S

D3–D2

EA1–0

Expected A Indicator:

EA1

EA0

Value

Any

R

0

1

0

1

0

1

S

R or S

D5–D4

EE1–0

Expected E Indicator:

EE1

0

EE0

0

Value

Any

R

0

1

0

S

1

R or S

D6

D7

VFCS

VDL

Valid FCS: When this bit is set, returning frames must have a valid FCS field to meet the confirmation

criteria.

Valid Data Length: When this bit is set, returning frames must have a valid VDL field to meet the

confirmation criteria.

107

7.0 Control Information (Continued)

Indicate Attention Register (IAR)

The Indicate Attention Register (IAR) is used to present exception and breakpoint attentions generated by each Indicate

Channel. An Attention bit is set by hardware when an exception or breakpoint occurs on the corresponding Indicate Channel.

Each bit may be enabled by setting the corresponding bit in the Indicate Notify Register.

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

Access Rules

Address

Read

Write

114h

Always

Conditional

Register Bits

D7

D6

D5

D4

D3

EXCI1

D2

D1

D0

RES

EXCI0

BRKI0

BRKI1

EXCI2

BRKI2

Bit

Symbol

BRKI2

Description

D0

Breakpoint on ICHN2: This bit is set when a breakpoint is detected on Indicate Channel 2. No action is

taken if the host sets this bit.

D1

EXCI2

Exception on ICHN2: While this bit is set, copying is disabled on ICHN2. This bit is set by the MACSI

device when an exception occurs on Indicate Channel 2. An exception consists of an ABus error during an

IDU or IDUD write for ICNH2. It may be set by the host to disable copying on ICHN2, which is convenient

when updating the Indicate Header Length and Indicate Threshold register.

When this bit is set by the device it signifies that the last frame received on this channel had an ABus

error. It is the last frame because the setting of this bit disables further copying on this channel. The last

frame should be discarded.

D2

D3

BRKI1

EXCI1

Breakpoint on ICHN1: This bit is set when a breakpoint is detected on Indicate Channel 1. No action is

taken if the host sets this bit.

Exception on ICHN1: While this bit is set, copying is disabled on ICHN1. This bit is set by the MACSI

device when an exception occurs on Indicate Channel 1. An exception consists of an ABus error during an

IDU or IDUD write for ICNH1. It may be set by the host to disable copying on ICHN1, which is convenient

when updating the Indicate Header Length and Indicate Threshold register.

When this bit is set by the device it signifies that the last frame received on this channel had an ABus

error. It is the last frame because the setting of this bit disables further copying on this channel. The last

frame should be discarded.

D4

D5

BRKI0

EXCI0

Breakpoint on ICHN0: This bit is set when a breakpoint is detected on ICHN0. No action is taken if the

host sets this bit. The User must set IMCR.BOS to use the BRKI0 breakpoint.

Exception on ICHN0: While this bit is set, copying is disabled on ICHN0. This bit is set by the MACSI

device when an exception occurs on Indicate Channel 0. An exception consists of an ABus error during an

IDU or IDUD write for ICNH0. It may be set by the host to disable copying on ICHN0.

When this bit is set by the device it signifies that the last frame received on this channel had an ABus

error. It is the last frame because the setting of this bit disables further copying on this channel. The last

frame should be discarded.

D7–D6

RES

Reserved

108

7.0 Control Information (Continued)

Indicate Notify Register (INR)

The Indicate Notify Register (INR) is used to enable attentions in the Indicate Attention Register (IAR). If a bit in Register INR is

set to One, the corresponding bit in Register IAR will be applied to the Master Attention Register, which can be used to generate

an interrupt to the host.

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

Access Rules

Address

Read

Write

115h

Always

Register Bits

D7

D6

D5

D4

D3

EXC1N

D2

D1

D0

RES

EXC0N

BRK0N

BRK1N

EXC2N

BRK2N

Bit

D0

Symbol

BRK2N

Description

Breakpoint on ICHN2 Notify: This bit is used to enable the BRK2 bit in Register IAR.

Exception on ICHN2 Notify: This bit is used to enable the EXC2 bit in Register IAR.

Breakpoint on ICHN1 Notify: This bit is used to enable the BRK1 bit in Register IAR.

Exception on ICHN1 Notify: This bit is used to enable the EXC1 bit in Register IAR.

Breakpoint on ICHN0 Notify: This bit is used to enable the BRK0 bit in Register IAR.

Exception on ICHN0 Notify: This bit is used to enable the EXC0 bit in Register IAR.

Reserved

D1

EXC2N

BRK1N

EXC1N

BRK0N

EXC0N

RES

D2

D3

D4

D5

D7–D6

Indicate Threshold Register (ITR)

The Indicate Threshold Register (ITR) specifies the maximum number of frames that can be received on Indicate Channel 1 or

Indicate Channel 2 before an attention will be generated. This register may be written only when the INSTOP bit in the State

Attention Register is set, or when the Indicate Channel’s corresponding EXC bit in the Indicate Attention Register is set.

This register is not altered upon reset.

Access Rules

Address

Read

Write

e

116h

Always

INSTOP Mode or EXC

1 Only

Register Bits

D7

D6

D5

D4

THR4

D3

D2

D1

D0

THR7

THR6

THR5

THR3

THR2

THR1

THR0

Bit

Symbol

Description

D7–D0

THR7–0

Threshold Data Bits 7–0: The value programmed in this register is loaded into an internal counter every

time the Indicate Channel changes. Each valid frame copied on the current Channel decrements the

counter. When the counter reaches Zero, a status breakpoint attention is generated (i.e., the Channel’s

BRK bit in the Indicate Attention Register is set) if the Channel’s Breakpoint on Threshold (BOT) bit in the

Indicate Mode Register is set. Loading the Indicate Threshold Register with Zero generates a breakpoint

after 256 consecutive frames are received on any one Indicate Channel.

109

7.0 Control Information (Continued)

Indicate Mode Configuration Register (IMCR)

The Indicate Mode Configuration Register (IMCR) defines configuration options for all three indicate Channels, including the sort

mode, frame filtering, and status breakpoints.

This register may be written only when the INSTOP bit in the State Attention Register is set. It may be written with its current

value any time, which is useful for one-shot sampling.

This register is not altered upon reset.

Access Rules

Address

Read

Write

117h

Always

INSTOP Mode Only

Register Bits

D7

D6

D5

D4

FPP

D3

D2

D1

D0

SM1

SM0

SKIP

BOT2

BOT1

BOB

BOS

Bit

Symbol

Description

D0

BOS

Breakpoint on Service Opportunity: Enables the end of a service opportunity to generate an Indicate

breakpoint attention (i.e., set the Channel’s BRK bit in the Indicate Attention Register). Service opportunities

include receipt of a Token, a MAC Frame, or a ring operational change following some copied frames. This bit

should be set to 1 if BRKI0 will be used.

D1

BOB

Breakpoint on Burst: Enables the end of a burst to generate an Indicate breakpoint attention (i.e., set the

Channel’s BRK bit in the Indicate Attention Register). End of burst includes Channel change, DA change, SA

change, or MAC INFO change. A Channel change is detected from the FC field of valid, copied frames. A DA

change is detected when a frame’s DA field changes from this station’s address to any other. An SA change is

detected when a frame’s SA field is not the same as the previous one. A MAC INFO change occurs when a

MAC frame does not have the identical first four bytes of INFO as the previous frame. This breakpoint always

sets the BRK bit (i.e., this breakpoint is always enabled).

D2

D3

D4

BOT1

BOT2

FPP

Breakpoint on Threshold for ICHN1: Enables the value in the Indicate Threshold Register to be used to

generate an Indicate breakpoint attention on Indicate Channel 1 (i.e., set the BRK1 bit in the Indicate Attention

Register).

Breakpoint on Threshold for ICHN2: Enables the value in the Indicate Threshold Register to be used to

generate an Indicate breakpoint attention on Indicate Channel 2 (i.e., set the BRK2 bit in the Indicate Attention

Register).

Frame-per-Page: This bit controls how received frames are packed into the Pool Space Pages which are

provided via the PSP Descriptors. When this bit is reset, the MACSI device assembles multiple frames into a

single page of Pool Space when possible (i.e., the frames are smaller than the 4 kByte page size). When this

bit is set, the MACSI device will force a page break and fetch a new PSP for each frame received. This

guarantees that no page will contain more than one frame. When FPP is set, Frame packing can be re-enabled

on individual channels. See ‘‘Address Configuration Register (ACR)’’.

This mode is useful for systems where received frames are not processed in order of receipt. This is because

space reclamation is greatly simplified. A side affect of this mode is that no frame will span more than two

pages (i.e., a frame will have at most two IDUDs).

D5

SKIP

Skip Enable: Enables filtering on Indicate Channel 0 when the Copy Control field for ICHN0 in the Indicate

Configuration Register is set to 01 or 10. When this bit is set, only the unique MAC frames received on Indicate

Channel 0 will be copied to memory (i.e., those having an FC field or first four bytes of the Information field that

differs from the previous frame). When this bit is 0, the MACSI will copy all MAC frames that meet the Copy

Criteria. When this bit changes from a 0 to a 1, the MACSI will copy the next MAC frame, even if it is the same

as the previous frame. Note that the ‘‘Promiscuous’’ Copy Mode overrides this SKIP mode (when the User

selects Promiscuous copy and the SKIP mode, the MACSI will copy all MAC frames).

110

7.0 Control Information (Continued)

Bit

Symbol

Description

D7–D6

SM1–0

Sort Mode: These bits determine how the MACSI device sorts Indicate data onto Indicate Channels 1

and 2.

SM1

SM0

ICHN2

Asynchronous

External

ICHN1

Synchronous

Internal

0

1

0

1

0

1

Info

Header

Low Priority

High Priority

The Synchronous/Asynchronous Sort Mode is intended for use in end-stations or applications using

synchronous transmission.

The Internal/External Sorting Mode is intended for bridging or monitoring applications. MAC/SMT frames

matching the internal Ring Engine (MAC) address are sorted onto ICHN0, and all other frames matching

the Ring Engine’s internal address (short or long) are sorted onto ICHN1. All frames matching the external

address (frames requiring bridging) are sorted onto ICHN2. This sorting mode uses the EM, ECOPY, and

ECIP input signals with external address matching circuitry. See the section on External address matching

for a full description of the timing required on these signals (Section 6.3). Promiscuous mode on ICHN2

does not require any external matching logic to copy frames.

The Header/Info Sort Mode is intended for high performance protocol processing. MAC/SMT frames are

sorted onto ICHN0, while all other frames are sorted onto ICHN1 and ICHN2. Frame bytes from the FC up

to the programmed header length are copied onto ICHN1. The remaining bytes(info) are copied onto

ICHN2. Only one stream of IDUDs is produced (on ICHN1), but both Indicate Channel’s PSP queues are

used for space (i.e., PSPs from ICHN1 for header space, and PSPs from ICHN2 for info space). Frames

a

may comprise a header only, or a header info. For frames with info, multi-part IDUD objects are

produced. For multi-part IDUDs, the Indicate Status field in the IDUD is used to determine which part of the

IDUD object points to the end of the header. The remainder of the IDUD is used to determine which part of

the IDUD object points to the end of the header. The remainder of the IDUD object points to the Info. If

Pool Space is only declared for ICNH1, then only the Headers will be written to memory. This is useful for

protocol monitor applications.

For example, if page crosses occur while writing the header and while writing out the Info, the MACSI

device will generate a four part IDUD object (IDUD.First, IDUD.Middle, IDUD.Middle, IDUD.Last). The

IDUD.First will have a status of ‘‘page cross’’. The first IDUD. Middle will have a status of ‘‘end of header’’.

The next IDUD.Middle will have a status of ‘‘page cross’’. The IDUD.Last will have an ‘‘end of frame’’

status.

The High Priority/Low Priority Sort Mode is intended for end stations using two priority levels of

asynchronous transmission. The priority is determined by the most-significant z-bit of the FC (zzz

e

high priority). Synchronous frames are sorted onto ICHN1 and MAC/SMT

e

0xx

e

frames are sorted onto ICHN0.

low-priority; zzz

1xx

111

7.0 Control Information (Continued)

Indicate Copy Configuration Register (ICCR)

The Indicate Copy Configuration Register (ICCR) is used to program the copy criteria for each of the Indicate Channels.

This register is not altered upon reset.

Access Rules

Address

Read

Write

118h

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

CC0

RES

CC1

RES

CC2

Bit

Symbol

Description

D1–D0

CC2

Copy Control ICHN2:

D1

0

D0

0

Copy Mode

Do Not Copy

E

ECIP & ECOPY)) & MFLAG

ECIP & ECOPY))

0

1

Copy if (AFLAG

(

l

E

Copy Promiscuously

1

0

(

1

D2

RES

CC1

Reserved

Copy Control ICHN1:

D4–D3

D4

0

D3

0

Copy Mode

Do Not Copy

E

ECIP & ECOPY)) & MFLAG

ECIP & ECOPY))

0

1

Copy if (AFLAG

(

l

1

0

1

Copy Promiscuously

D5

RES

CC0

Reserved

Copy Control ICHN0:

D7–D6

D7

0

D6

0

Copy Mode

Do Not Copy

E

ECIP & ECOPY)) & MFLAG

ECIP & ECOPY))

0

1

Copy if (AFLAG

(

l

1

0

1

Copy Promiscuously

112

7.0 Control Information (Continued)

Indicate Header Length Register (IHLR)

The Indicate Header Length Register (IHLR) defines the length (in words) of the frame header, for use with the Header/Info Sort

Mode.

The Indicate Header Length Register must be initialized before setting the Sort Mode in Header/Info. This register may be

changed while the INSTOP bit in the State Attention Register or the EXC bit in the Indicate Attention Register is set.

This register is not altered upon reset.

Access Rules

Address

Read

Write

e

119h

Always

INSTOP Mode or EXC

1 Only

Register Bits

D7

D6

D5

D4

HL4

D3

D2

D1

D0

HL7

HL6

HL5

HL3

HL2

HL1

HL0

Bit

Symbol

HL7–0

Description

D7–D0

Header Length: Specifies the length (in words) of the frame header, for use with the Header/Info Sort

Mode. The frame FC is written as a separate word, and thus counts as one word. For example, to split

after eight bytes of FDDI INFO in a frame with long addresses, this register is programmed with the value

06 (1 word FC, 1.5 DA, 1.5 SA, 2HDR DATA). IHLR must not be loaded with a value less than 4. If it is,

Ð

the MACSI device sets the Command Error (CMDE) and Indicate Stop (INSTOP) attentions. This Register

only affects the Header/Info sort mode.

113

7.0 Control Information (Continued)

Address Configuration Register (ACR)

This register contains bits for configuring the address swapping logic.

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

Access Rules

Address

Read

Write

11Ah

Always

Register Bits

D7

D6

D5

D4

D3

RSWP0

D2

D1

D0

PCKI2

PCKI1

PCKI0

RSWP1

ISWP2

ISWP1

ISWP0

Bit

Symbol

Description

D0

D1

D2

D3

D4

D5

ISWP0

Indicate Swap 0: This bit controls the address swapping logic for Indicate Channel 0 (ICHN0). If this bit is

reset, no address swapping takes place. If this bit is set, both Destination (DA) and Source address (SA) fields

are swapped from FDDI bit ordering to canonical bit ordering. This involves a bit reversal within each byte.

ISWP1

ISWP2

RSWP0

RSWP1

PCKI0

Indicate Swap 1: This bit controls the address swapping logic for Indicate Channel 1 (ICHN1). If this bit is

reset, no address swapping takes place. If this bit is set, both Destination (DA) and Source address (SA) fields

are swapped from FDDI bit ordering to canonical bit ordering. This involves a bit reversal within each byte.

Indicate Swap 2: This bit controls the address swapping logic for Indicate Channel 2 (ICHN2). If this bit is

reset, no address swapping takes place. If this bit is set, both Destination (DA) and Source address (SA) fields

are swapped from FDDI bit ordering to canonical bit ordering. This involves a bit reversal within each byte.

Request Swap 0: This bit controls the address swapping logic for Request Channel 0 (RCHN0). If this bit is

reset, no address swapping takes place. If this bit is set, both Destination (DA) and Source address (SA) fields

are swapped from canonical bit ordering to FDDI bit ordering. This involves a bit reversal within each byte.

Request Swap 1: This bit controls the address swapping logic for Request Channel 1 (RCHN1). If this bit is

reset, no address swapping takes place. If this bit is set, both Destination (DA) and Source address (SA) fields

are swapped from canonical bit ordering to FDDI bit ordering. This involves a bit reversal within each byte.

Pack Frames on ICHN0: This bit controls the packing of Frames into Pool Space Pages for Indicate

Channel 0 (ICHN0). When the Frame-Per-Page (FPP) bit is set (see ‘‘Indicate Mode Configuration Register

(IMR)’’), the MACSI device will cause a page break and start each new Frame in a new Pool Space Buffer.

Setting the PCKI0 bit selectively disables the Frame-Per-Page mode for ICHN0. If the FPP bit is zero, this

PCKI0 bit has no effect.

D6

D7

PCKI1

PCKI2

Pack Frames on ICHN1: This bit controls the packing of Frames into Pool Space Pages for Indicate

Channel 1 (ICHN1). When the Frame-Per-Page (FPP) bit is set (see ‘‘Indicate Mode Configuration Register

(IMR)’’), the MACSI device will cause a page break and start each new Frame in a new Pool Space Buffer.

Setting the PCKI1 bit selectively disables the Frame-Per-Page mode for ICHN1. If the FPP bit is zero, this

PCKI1 bit has no effect.

Pack Frames on ICHN2: This bit controls the packing of Frames into Pool Space Pages for Indicate

Channel 2 (ICHN2). When the Frame-Per-Page (FPP) bit is set (see ‘‘Indicate Mode Configuration Register

(IMR)’’), the MACSI device will cause a page break and start each new Frame in a new Pool Space Buffer.

Setting the PCKI2 bit selectively disables the Frame-Per-Page mode for ICHN2. If the FPP bit is zero, this

PCKI2 bit has no effect.

114

7.0 Control Information (Continued)

Request Channel 0 and 1 Configuration Registers 1 (R0CR1 and R1CR1)

The two Request Configuration Registers 1 (R0CR1 and R1CR1) are programmed with additional operational parameters for

each of the Request Channels. Other Request Channel parameters are configured in Request Configuration Registers 0. These

registers may only be altered between Requests, i.e., while the particular Request Channel does not have a Request loaded.

All bits in these registers are set to Zero upon reset.

Access Rules

Address

Read

Write

11B–11Ch

Always

Register Bits

D7

D6

D5

D4

D3

D2

D1

D0

EFT

RES

ETR

Bit

Symbol

Description

D0

ETR

Early Token Request: When this bit is set, the MACSI device attempts to capture a token as soon as a

valid Request Descriptor (REQ) is fetched for this channel. This allows the user to maintain tight control

over the Token access timing by pacing REQ availability. This is useful for certain models of Synchronous

traffic use. If this bit is reset, the MACSI device will not capture a Token until enough data for this request

has been fetched to reach the Transmit Data FIFO threshold or the end-of-frame is fetched into the FIFO.

This bit should normally be reset because this will save ring bandwidth.

D6–D1

D7

RES

EFT

Reserved

Extended FIFO Threshold: This bit is used to extend the number of FIFO thresholds available with the

[

]

TT 1:0 bits in R0CR0 and R1CR0. See ‘‘Request Channel 0 and 1 Configuration Registers 0 (R0CR0 and

R1CR0)’’. The table below shows the thresholds available. The MACSI device Transmit Data FIFO is large

enough to hold an entire maximum length FDDI frame. The ‘‘End of Frame’’ threshold is used to tell the

MACSI device not to start transmitting until the entire frame has been staged in the FIFO.

[ ]

TT 1

[ ]

TT 0

EFT

Threshold

0

1

0

1

0

1

0

1

0

1

0

1

0

1

8 words

16 words

128 words

256 words

512 words

Reserved

End of Frame

115

7.0 Control Information (Continued)

System Interface Compare Register (SICMP)

The System Interface Compare Register (SICMP) is used in comparison with a write access of a conditional write register. The

System Interface Compare Register is loaded on a read of any of the system interface conditional event Attention Registers or

by directly writing to it.

This register is not altered upon reset.

Access Rules

Address

Read

Write

11Fh

Always

Register Bits

D7

D6

D5

D4

D3

CMP3

D2

D1

D0

CMP7

CMP6

CMP5

CMP4

CMP2

CMP1

CMP0

Bit

Symbol

Description

D7–D0

CMP7–CMP0

Compare: These bits are compared to bits D7–D0 of the accessed System Interface register. Only

the bits in the System Interface Attention Register that have the same current value as the

corresponding bit in the Compare register will be updated with the new value.

7.8 POINTER RAM REGISTERS

memory external to the MACSI device and accessed by the

MACSI device via the ABus. Descriptors include the follow-

ing: Input Data Unit Descriptors (IDUDs) specify the loca-

tion, size, part, and status information for Input Data Units.

Output Data Unit Descriptors (ODUDs) specify the location

and size of Output Data Units. For multi-ODUD frames, they

also specify which part of the frame is pointed to by the

ODUD. Pool Space Descriptors (PSPs) describe the loca-

tion and size of a region of memory space available for writ-

ing Indicate data. Request Descriptors (REQs) describe the

location of a stream of Output Data Unit Descriptors and

contain operational parameters. Confirmation Status Mes-

sages (CNFs) describe the result of a Request operation.

Pointer RAM Registers contain pointers to all data and De-

scriptors manipulated by the MACSI device, namely, Input

and Output Data Units, Input and Output Data Unit Descrip-

tors, Request Descriptors, Confirmation Messages, and

Pool Space Descriptors. Pointer RAM Registers are shown

in Figure 7-3.

7.9 LIMIT RAM REGISTERS

The Limit RAM Registers are used by both the Indicate and

Request machines. Limit RAM Registers contain data val-

ues that define how far the MACSI device may advance in

each of its ten queues. The Limit RAM Registers do not

define the wrap point for each queue which is fixed at either

1 kByte or 4 kBytes. Limit RAM Registers are shown in Fig-

ure 7-4.

7.11 OPERATING RULES

Multi-Byte Register Ordering

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.

When referring to the contents of a byte, the most signifi-

cant bit is always referred to first.

7.10 DESCRIPTORS

Descriptors are used to observe and control the operation

of the MACSI device. They contain address, status, and

control information about Indicate and Request operations.

Descriptors are stored in lists and wrap-around queues in

116

7.0 Control Information (Continued)

7.12 POINTER RAM REGISTER DESCRIPTIONS

PSP Queue Pointer Register: Points to the next available

PSP. Initialized by the host with the start address of the PSP

Queue. As each PSP is read from memory, this register is

incremented.

The Pointer RAM Register set contains 32, 28-bit registers.

Registers 23 through 31 are reserved, and user access of

these locations produces undefined results. Pointer RAM

Registers are read and written by the host using the Pointer

RAM Operation (PTOP) service function and are accessed

directly by MACSI device hardware during Indicate and Re-

quest operations. After initialization, the Pointer RAM Regis-

ters are maintained by the MACSI device and do not require

host intervention.

Next PSP Register: Written by the MACSI device with the

PSP fetched from the PSP Queue.

Indicate Shadow Register: Written by the MACSI device

with the start address of the last IDU copied to memory.

Request Shadow Register: Written by the MACSI device

with the address of the current ODUD.

During Indicate and Request operations, Pointer RAM regis-

ters are used as addresses for ABus accesses of data and

Descriptors, i.e., the subchannel addresses for loads

(reads) of streams of PSPs, ODUs, ODUDs, and REQs, and

for stores (writes) of streams of IDUs, IDUDs, and CNFs.

See Figure 7-3 for Summary including address and access

rules.

7.13 LIMIT RAM REGISTER DESCRIPTIONS

The Limit RAM Register set contains 16, 9-bit registers.

Registers 11 through 15 are reserved, and access of these

locations produces undefined results.

Pointer RAM Registers include the following:

ODU Pointer: Contains the address of an Output Data Unit.

During Request operations, this register is loaded by the

MACSI device from the Location Field of its Output Data

Unit Descriptor.

The Limit RAM registers contain data values that define the

limits of each of the ten queues maintained by the MACSI

device.

ODUD List Pointer: Loaded by the MACSI device from the

Location Field of the REQ Descriptor when it is read from

memory. The address is incremented by the MACSI device

as each ODUD is fetched from memory.

Limit RAM Registers are read and written by the host using

the Limit RAM Operation (LMOP) service function when the

Status/Space Machine is in STOP Mode, and are read di-

rectly by MACSI device hardware during Indicate and Re-

quest operations.

CNF Queue Pointer: Contains the current CNF Status

Queue address. This register is written by the user after he

has allocated space for the CNF Queue. During Request

operations, this register is incremented by the MACSI de-

vice after each CNF is written to the CNF Queue.

Limit RAM Registers include the following:

REQ Queue Limit: Defines the last valid REQ written by the

host.

CNF Queue Limit Register: Defines the last Queue loca-

tion where a CNF may be written by the MACSI device. Due

to pipelining, the MACSI device may write up to two CNFs

after it detects a write to the next-to-last CNF entry (and

generates a No Status Space Attention). For this reason,

the host must always define the CNF queue limit to be one

Descriptor less than the available space.

REQ Queue Pointer: Initialized by the host with the start

address of the REQ Descriptor Queue after the Queue has

been initialized. During Request operations, the address is

incremented by the MACSI device as each REQ is fetched.

IDU Pointer: Written by the MACSI device with the Location

Field of the PSP Descriptor when it is loaded from the PSP

pre-fetch register.

IDUD Queue Limit Register: Defines the last Queue loca-

tion where an IDUD may be written by the MACSI device.

IDUD Queue Pointer: Points to the Queue location where

IDUDs will be stored. Written by the user after he has allo-

cated space for the IDUD Status Queue. Incremented by

the MACSI device as IDUDs are written to consecutive loca-

tions in the Queue.

PSP Queue Limit: Defines the last valid PSP written by the

host.

See Figure 7-4 for Summary including address and access

rules.

117

7.0 Control Information (Continued)

Access Rules

Read Write

Group Address

Register Name

00

01

ODU Pointer RCHN1 (OPR1)

Always Always

ODUD List Pointer RCHN1 (OLPR1)

02

CNF Queue Pointer RCHN1 (CQPR1) Always Always

REQ Queue Pointer RCHN1 (RQPR1) Always Always

03

04

ODU Pointer RCHN0 (OPR0)

Always Always

05

ODUD List Pointer RCHN0 (OLPR0)

06

CNF Queue Pointer RCHN0 (CQPR0) Always Always

REQ Queue Pointer RCHN0 (RQPR0) Always Always

07

08

IDU Pointer ICHN2 (IPI2)

Always Always

09

IDUD Queue Pointer ICHN2 (IQPI2)

PSP Queue Pointer ICHN2 (PQPI2)*

Next PSP ICHN2 (NPI2)

0A

0B

0C

0D

0E

0F

10

IDU Pointer ICHN1 (IPI1)

IDUD Queue Pointer ICHN1 (IQPI1)

PSP Queue Pointer ICHN1 (PQPI1)*

Next PSP ICHN1 (NPI1)

IDU Pointer ICHN0 (IPI0)

11

IDUD Queue Pointer ICHN0 (IQPI0)

PSP Queue Pointer ICHN0 (PQPI0)*

Next PSP ICHN0 (NPI0)

12

13

14

IDUD Shadow Register (ISR)

ODUD Shadow Register (OSR)

Reserved

15

16–1F

N/A

*Note: Bit position D2 of these Pointer RAM Locations is always forced to a 1,

(The first word of a PSP is not fetched).

FIGURE 7-3. Pointer RAM Registers

Access Rules

Read Write

Group Address

Register Name

0

1

REQ Queue Limit RCHN1 (RQLR1) Always Always

CNF Queue Limit RCHN1 (CQLR1) Always Always

REQ Queue Limit RCHN0 (RQLR0) Always Always

CNF Queue Limit RCHN0 (CQLR0) Always Always

2

3

4

IDUD Queue Limit ICHN2 (IQLI2)

PSP Queue Limit ICHN2 (PQLI2)

IDUD Queue Limit ICHN1 (IQLI1)

PSP Queue Limit ICHN1 (PQLI1)

IDUD Queue Limit ICHN0 (IQLI0)

PSP Queue Limit ICHN0 (PQLI0)

Reserved

Always Always

5

6

7

8

9

A-F

N/A

FIGURE 7-4. Limit RAM Registers

118

7.0 Control Information (Continued)

Input Data Unit Descriptor (IDUD)

Input Data Unit Descriptors (IDUDs) are generated on Indicate Channels to describe where the MACSI device wrote each frame

part and to report status for the frame.

For multi-part IDUDs, intermediate status is written in each IDUD, and when a status event occurs, definitive status is written in

the last IDUD.

A detailed description of the encodings of the Indicate Status bits is given in Figure 7.5.

16 15 14 13 12

31 30 29 28 27

24 23

0

IS

FRA

FRS

VC RES

CNT

Word 0

Word 1

F-L

RES

LOC

Bit

Symbol

Description

Word 0

D12–D0

CNT

Byte Count: Number of bytes in the IDU to which this IDUD points. This count includes the FDDI

Frame Check Sequence (4 byte FCS) but it does not include the three FC pad bytes which are

written.

D14–D13

D15

RES

VC

Reserved

VCOPY: Reflects the state of the internal VCOPY signal sent to the Ring Engine by the System

Interface for this frame.

0: VCOPY was negated

1: VCOPY was asserted

D23–D16

FRS

C

Frame Status: This C, E, and A fields are valid only if the frame ended with an ED.

D17–D16

C Indicator:

00: none

01:

10:

11:

R

S

T

D19–D18

D21–D20

A

E

A Indicator:

00: none

01:

10:

11:

R

S

T

E Indicator:

00: none

01:

10:

11:

R

S

T

D22

D23

VFCS

VDL

Valid FCS:

0: FCS field was invalid

1: FCS field was valid

Valid Date Length:

0: Data length was invalid

1: Data length was valid

119

7.0 Control Information (Continued)

Bit

Symbol

Description

Word 0 (Continued)

D27–D24

FRA

TC

Frame Attributes: This field gives termination and address information.

D25–D24

Termination Condition:

00: Other (e.g., MAC Reset/token).

01: ED

10: Format error.

11: Frame stripped.

D26

D27

AFLAG

MFLAG

IS

AFLAG: Reflects the state of the AFLAG input signal, which is sampled by the MACSI device at

INFORCVD.

0: External DA match.

1: Internal DA match.

MFLAG: Reflects the state of the MFLAG input signal, which is sampled by the MACSI device at

INFORCVD.

0: Frame sent by another station.

1: Frame sent by this station.

D31–D28

Indicate Status: The values in this field are prioritized, with the highest number having the

highest priority. A detailed description of the encodings are given inFigure 7-5.

IS3

IS2

IS1

IS0

Meaning

D31

D30

D29

D28

Non-end Frame Status

0

1

0

1

0

1

Last IDUD of queue, page-cross.

Page boundary crossed.

End of header.

Page-cross with header-end.

Normal-end Frame Status

0

1

0

1

0

1

0

1

Intermediate (no breakpoints).

Burst boundary.

Threshold.

Service opportunity.

Copy Abort due to No Space

1

0

1

0

1

0

1

No data space.

No header space.

Good header, info not copied.

Not enough info space.

Error

1

0

1

0

1

0

1

FIFO overrun.

Bad frame (no VDL or no VFCS).

Parity error.

Internal error.

Word 1

D27–D0

LOC

Location: 28-bit memory address of the start of an IDU. For the first IDU of a frame, the address

e

]

[

is of the fourth FC byte of the burst-aligned frame (i.e., bits 1:0

11). For subsequent IDUs, the

e

]

[

address is of the first byte of the IDU (i.e, bits 1:0

00).

D29–D28

D31–D30

RES

F-L

Reserved

e

First,

First/Last Tag: Identifies the IDU object part, i.e., Only, First, Middle, or Last. FL

e

10

e

Last, FL 11-Only.

FL

00

Middle, FL

01

120

7.0 Control Information (Continued)

NON-END FRAME STATUS

[

]

0000

Last IDUD of Queue, with a Page Cross: The last available location of the ICHN’s IDUD queue was written. Since

there was a page cross, there was more data to be written. Since there was no more IDUD space, the remaining data

was not written. Note that this code will not be written in an IDUD.Middle, so that a Zero IS field with Zero F-L tags can

be used by software as a null descriptor.

[

]

0001

Page Cross: Must be an IDUD.First or IDUD.Middle. This is part of a frame that filled up the remainder of the current

page, requiring a new page for remainder of the data.

[

]

0010

Header End: This refers to the last IDU of the header portion of a frame.

0011

Page Cross and Header End: The occurrence of a page cross and header end.

NORMAL-END FRAME STATUS

[

]

0100

0101

0110

Intermediate: A frame ended normally, and there was no breakpoint.

Burst Boundary: A frame ended normally, and there was a breakpoint because a burst boundary was detected.

Threshold: The copied frame threshold counter was reached when this frame was copied, and the frame ended

normally.

[

]

0111

Service Opportunity: This (normal end) frame was preceeded by a token or MACRST, a MAC frame was received, or

there was a ring-op change. Any of these events marks a burst boundary.

NO SPACE COPY ABORT

[

]

1000

1001

1010

1011

Insufficient Data Space: Not all the frame was copied because there was insufficient data space. This code is only

written in non-Header/Info Sort Mode.

Insufficient Header Space: The frame copy was aborted because there was insufficient header space (in Header/Info

Sort Mode0.

Successful Header Copy, Frame Info Not Copied: There was sufficient space to copy the header, but insufficient

data space to copy info, or insufficient IDU space (on ICHN2), or both. No info was copied.

No Info Space: The frame’s header was copied. When copying the data, there was insufficient data and/or IDU space.

ERROR

[

]

1100

1101

1110

1111

FIFO Overrun: The Indicate FIFO had an overrun while copying this frame. This exception is caused when the memory

interface does not allow the MACSI device to empty the data FIFO as quickly as it is being filled. This frame should not

be processed because data has been lost.

Bad Frame: This exception is caused when the incoming frame contains an invalid data length (too short or an odd

number of symbols), or an invalid Frame Check Sequence (FCS). This implies that the frame was not a valid FDDI

frame. Therefore, this frame should not be processed.

Parity Error: This exception is caused when the MACSI device detects an internal parity error at the System Interface-

Ring Engine interface (the MR.FLOW bit must be set to enable parity checking). This implies a data corruption error

within the frame. Therefore, this frame should not be processed.

Internal Error: This exception is caused when the MACSI device detects an internal hardware error (e.g. illegal state

machine state), in the receive logic while receiving a frame. This implies that the frame data may have been corrupted.

Therefore, this frame should not be processed. In addition, the MACSI device should be reset and reinitialized.

FIGURE 7-5. Indicate Status Field (IS) of IDU Descriptor

121

7.0 Control Information (Continued)

REQ Descriptor (REQ)

Request Descriptors (REQs) contain the part, byte address, and size of one or more Output Data Unit Descriptors. They also

contain parameters and commands to the MACSI device associated with Request operations.

Multiple REQ Descriptors (parts) may be grouped as one Request Descriptor object by the host software, with the REQ.First

defining the parameters for the entire Request object. Also multiple Output Data Unit Descriptors may be grouped contiguously,

to be described by a single REQ Descriptor.

Each REQ part is fetched by the MACSI device from the Request Channel’s REQ Descriptor Queue, using the REQ Queue

Pointer Register. Each Request Channel processes one Request Object (REQ.Only or REQ.First to REQ.Last set), per service

opportunity.

The MACSI device checks for the following inconsistencies when the REQ is loaded from memory:

1. REQ.First with invalid Confirmation Class (as shown in the Figure 7-7 ).

e

2. REQ.First with Request Class

0.

3. REQ.First, when the previous REQ was not a REQ.Last or REQ.Only.

4. REQ which is not a REQ.First or REQ.Only when the previous REQ was a REQ.Last or a REQ.Only

When an inconsistency is detected, the MACSI device aborts the Request, and reports the exception in the Request Status field

of the CNF Descriptor.

The encodings of the RQCLS and CNFCLS bits are described in more detail in Figure 7-6 and Figure 7-7 respectively.

31 30 29 28 27

24 23

16 15

12 11

8

7

0

RES

F-L

UID

SIZE

CNFCLS

LOC

RQCLS

FC

Word 0

Word 1

RES

Bit

Symbol

Description

Word 0

D7–D0

FC

Frame Control: This specifies the Frame control field to be used unless FC transparency is enabled.

This field is decoded to determine whether to assert RQCLM or RQBCN. This decoding is always

active, i.e., regardless of frame control transparency. This field is also used for comparing received

frames when confirming (without FC transparency).

D8–D11

RQCLS

Request/Release Class: This field encodes the Request Class for the entire Request object, and is

thus only sampled on a REQ.First or REQ.Only. The field is asserted on the RQRCLS signals to the

Ring Engine when requesting a token. If the Request Class is incompatible with the current ring state,

the MACSI device sets the RCHN’s USR bit in the Request Attention Register. The encoding of this

field is shown inFigure 7-6.

D15–D12

D12

CNFCLS

E

Confirmation Class: This field encodes the Confirmation Class for the entire Request object, and is

only sampled on a REQ.First or REQ.Only. The encoding of this field is shown inFigure 7-7.

End: Enables confirmation on completion of request.

0: CNFs on completion disabled.

1: CNFs on completion enabled.

D13

D14

I

Intermediate: Enables Intermediate (at the end of each Service Opportunity) Confirmation.

0: Intermediate CNFs disabled.

1: Intermediate CNFs enabled.

F

Full/Transmitter: Selects between Transmitter and Full Confirmation.

0: Transmitter confirm.

1: Full confirm.

122

7.0 Control Information (Continued)

Bit

Symbol

Description

Word 0 (Continued)

D15–D12

D15

CNFCLS

Confirmation Class: (Continued)

R

Repeat: Enables repeated transmission of the first frame of the request until the request is aborted.

This may be used when sending Beacon or Claim frames.

0: Fetch all frames of REQ.

1: Repeat transmission of first frame of REQ.

A Request may use Repeat on RCHN1, and have a Request loaded on RCHN0, but not vice-versa.

Specifically, when a Request with the Repeat option is loaded on RCHN0, RCHN1 must not have any

REQs active or visible to the MACSI device. Thus REQs on RCHN1 may be queued externally but the

queue’s Limit Register must not be set at or after that point. Requests with the Repeat option should

only be used on one Request Channel at a time, and preferably on RCHN0.

Note that the Repeat Option requires a REQ.First Descriptor. The Repeat Option will not work on a

REQ.Only Descriptor.

D23–D16

SIZE

Size: Count of number of frames represented by the ODUD stream pointed to by REQ.LOC field.

Descriptors with a null frame count are permitted, and are typically used to end a Request, without

e

the Request Machine to command the Ring Engine to capture and release the specified classes of

having to send data. For example, to end a restricted dialogue, a REQ.Last with SIZE

0 will cause

e

token. The response of the MACSI device to REQs with SIZE

0 is as follows:

1. REQ.First: MACSI device latches the REQ Descriptor fields, then fetches the next REQ.

RQRCLS is asserted, but RQRDY remains deasserted.

2. REQ.Middle: MACSI device fetches the next REQ.

3. REQ.Only: MACSI device requests the capture of the appropriate token. When it is captured, the

MACSI device asserts RQFINAL and ends the request.

4. REQ.Last: MACSI device captures the token, asserts RQFINAL, then marks the request

complete.

D29–D24

D31–D30

UID

User Identification: Contains the UID field from the current REQ.First or REQ.Only.

RES

Reserved

Word 1

[

]

[

Location: Bits 27:2 are the memory word address of the ODUD stream. Bits 1:0 are expected to

]

D27–D0

LOC

be 00, and are not checked.

D29–D28

D31–D30

RES

F-L

Reserved

e

First, FL

First/Last Tag: Identifies the REQ stream part, i.e., Only, First, Middle, or Last. FL

e

10

e

Last, FL 11-Only.

00

Middle, FL

01

123

7.0 Control Information (Continued)

RQCLS

Value

RQCLS

Name

Class

Type

Token

Issue

THT

Notes

Capture

0000

0001

0010

0011

0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111

None

Apr1

None

Async pri1

Reserved

Sync

none

non-r

none

non-r

E

Reserved

Syn

D

any

capt

none

non-r

restr

non-r

restr

non-r

restr

non-r

restr

non-r

restr

1

4

Imm

Immed

D

none

non-r

restr

non-r

restr

ImmN

ImmR

Asyn

Immed

D

Immed

D

Async

E

Rbeg

Restricted

Async

E

2, 3

2

Rend

E

Rcnt

E

2

AsynD

RbegD

RendD

RcntD

D

Restricted

D

2, 3

2

D

2

e

restricted, capt captured

E

enabled, D

disabled, non-r

non-restricted, restr

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 unless the Request contains a

Beacon or Claim FC. If a Claim FC is used, Immediate Requests are serviced from the Claim State. If a Beacon FC is used, Immediate Request are serviced from

the Beacon State.

FIGURE 7-6. REQ Descriptor Request Class Encoding

[

]

[ ]

[

]

R

x

F

I

E

0

1

0

1

Confirmation Class

0

x

0

1

0

1

0

1

0

1

0

1

Invalid (consistency failure)

x

Invalid (consistency failure)

0

1

0

1

0

1

None: Confirmation only on exception

Trend: Transmitter confirm, CNF on exception or completion

Tint: Transmitter confirm, CNF on exception, completion, or intermediate

Fend: Full Confirm, CNF on exception or completion

Fint: Full Confirm, CNF on exception, completion, or intermediate

NoneR: Confirmation only on exception, repeat frame

TendR: Transmitter confirm, CNF on exception or completion, repeat frame

TintR: Transmitter confirm, CNF on exception, completion, or intermediate, repeat frame

FendR: Full confirmation, CNF on exception or completion, repeat frame

FintR: Full Confirmation, CNF on exception, completion, or intermediate, repeat frame

FIGURE 7-7. REQ Descriptor Confirmation Class Field Encodings

124

7.0 Control Information (Continued)

Output Data Unit Descriptor (ODUD)

An Output Data Unit Descriptor (ODUD) contains the part, byte address and size of an Output Data Unit. During Request

operations, ODUDs are fetched by the MACSI device from a list in memory, using the address in the ODUD List Pointer Register

(in the Pointer RAM).

ODUD.Firsts and ODUD.Middles may have a zero byte count, which is useful for fixed protocol stacks. One layer may be called,

and if it has no data to add to the frame, it may add an ODUD with a zero byte count to the list. ODUD.Onlys and ODUD.Lasts

may not have a zero byte count.

The MACSI device checks for the following inconsistencies when an ODUD is loaded from memory:

1. ODUD.First, when previous ODUD was not an ODUD.Last or ODUD.Only.

2. ODUD which is not an ODUD.First, when the previous ODUD was ODUD.Last or ODUD.Only.

3. ODUD.Last or ODUD.Only with a zero byte count.

When an inconsistency is detected, the MACSI device aborts the Request, and reports the exception in the Request Status field

of the CNF Descriptor.

The entire ODUD object must contain at least 4 bytes (for short addresses).

31 30 29 28 27

13 12

0

RES

CNT

Word 0

Word 1

F-L

RES

LOC

Bit

Symbol

Description

Word 0

D12–D0

CNT

RES

Byte Count: Number of bytes in the ODU. For an ODUD.First or ODUD.Middle the size may be Zero,

which is useful for fixed protocol stacks.

D31–D13

Word 1

Reserved

D27–D0

D29–D28

D31–D30

LOC

RES

F-L

Location: Pointer to the first byte of the corresponding ODU.

Reserved

e

First,

First/Last Tag: Identifies the Output Data Unit part, i.e., Only, First, Middle, or Last. FL

e

10

e

Last, FL 11-Only.

FL

00

Middle, FL

01

125

7.0 Control Information (Continued)

Confirmation Status Message Descriptor (CNF)

A Confirmation Status Message (CNF) describes the result of a Request operation.

A more detailed description of the encoding of the RS bits is given in Figure 7-8.

31 30 29 28 27

24 23

16 15

8

7

0

RS

FRA

FRS

FC

TFC

CS

CFC

RES

Word 0

Word 1

F-L

UID

Bit

Symbol

Description

Word 0

D7–D0

CFC

TFC

Confirmed Frame Count: Number of confirmed frames. Valid only for Full Confirmation. This

count is cumulative for Fint.

D15–D13

Transmitted Frame Count: Number of frames successfully transmitted by the MACSI device.

Valid for all confirmation classes. This count is cumulative for Tint and Fint.

D23–D16

FRS

C

Frame Status: This field is valid only for Full Confirmation, and if the frame ended with an ED.

D17–D16

C Indicator:

00: none

01:

10:

11:

R

S

T

D19–D18

D21–D20

A

E

A Indicator:

00: none

01:

10:

11:

R

S

T

E Indicator:

00: none

01:

10:

11:

R

S

T

D22

D23

VFCS

VDL

Valid FCS:

0: FCS field was invalid

1: FCS field was valid

Valid Date Length:

0: Data length was invalid

1: Data length was valid

126

7.0 Control Information (Continued)

Bit

Symbol

Description

Word 0 (Continued)

D27–D24

FRA

TC

Frame Attributes: This field is valid only for Full Confirmation.

D25–D24

Termination Condition:

00: Other (e.g., MAC Reset/token).

01: ED

10: Format error.

11: Frame stripped.

D26

D27

AFLAG

MFLAG

RS

AFLAG: Reflects the state of the AFLAG input signal, which is sampled by the MACSI device at

INFORCVD.

0: No DA Match.

1: DA Match.

MFLAG: Reflects the state of the MFLAG input signal, which is sampled by the MACSI device at

INFORCVD.

0: Frame Sent by another station.

1: Frame Sent by this station.

D31–D28

Request Status: This field represents a priority encoded status value, with the highest number

having the highest priority. This field is described inFigure 7-8.

RS3

RS2

RS1

RS0

Meaning

D31

D30

D29

D28

Intermediate

0

1

0

1

0

None

Preempted

Part Done

Breakpoints

0

1

0

1

0

Service Loss

Reserved

Completion

0

1

0

1

0

Completed Beacon

Completed OK

Exception Completion

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

Bad Confirmation

Underrun

Host Abort

Bad Ringop

MAC Abort

Timeout

MAC Reset

Consistency Failure

Error

1

Internal or Fatal ABus Error

127

7.0 Control Information (Continued)

Bit

Word 1

Symbol

Description

D7–D0

RES

CS

Reserved

D15–D8

Confirmation Status

D9–D8

FT

Frame Type: This field reflects the type of frame that ended Full Confirmation.

00: Any Other.

01: Token.

10: Other Void.

11: My Void.

D10

D11

F

Full Confirm: This bit is set when the Request was for Full Conformation.

U

Unexpected Frame Status: This bit is set when the frame status does not match the value

programmed in the Request Expected Frame Status Register. This applies only to Full

Confirmation.

D12

D13

P

E

Parity: This bit is set when a parity error is detected in a received frame. Parity is checked from FC

to ED inclusive if the FLOW bit in the Mode Register is set.

Exception: This bit is part of the MACSI’s hierarchical status reporting. It is set when an exception

occurs during confirmation. An exception is any one of the nine error or exception codes described

in the RS Field. The RCHN’s EXC bit in the Request Attention Register is also set.

D14

D15

R

T

Ring-Op: This bit is set when the ring changes operational state after transmission but before all

returning frames have been confirmed.

Transmit Class:

0: Restricted.

1: Non-Restricted.

D23–D16

FC

Frame Control: Frame Control field of the last frame of the last confirmed burst. Valid only for Full

Confirmation.

D29–D24

D31–D30

UID

F-L

User Identification: Contains the UID field copied from the current REQ.First or REQ.Only.

e

First, FL 00

First/Last Tag: Identifies the CNF part, i.e., Only, First, Middle, or Last. FL

e

10

e

Last, FL 11-Only.

Middle, FL

01

128

7.0 Control Information (Continued)

INTERMEDIATE

[

]

0000

0001

0010

NONE: Non status is written. This may be used by software to identify a NULL or invalid CNF.

Preempted: RCHN1 was preempted by RCHN0. RCHN1 will be serviced following RCHN0.

Part None: The MACSI device is servicing a Request, but it cannot hold onto a token, and the last frame of a

Request.part has been transmitted.

BREAKPOINTS

[

]

0011

Service Loss: The THT expired during a Request with THT enabled. Only Occurs for Intermediate Confirmation.

0100

Reserved

COMPLETION

[

]

0101

Completed Beacon: When transmitting from the Beacon state, this status is returned when the Ring Engine receives a

My Beacon. When transmitting from the Claim state, this status is returned when the Ring Engine wins the Claim

Ð

process.

[

]

0110

Completed OK: Normal completion with good status.

EXCEPTION COMPLETION:

In all of the exception and error cases it is likely that at least some of the frames from the associated request were not

[

]

transmitted properly. Therefore, retransmission may be required. In the case of bad confirmation 0111 , the frames

may have been transmitted properly but lost on the ring. A consistency failure 1110 means that there is a problem in

[

]

[

]

the request queues. It is recommended that they be reinitialized. The Internal or Abus error code 1111 is very severe

and it recommended that the MACSI device be reinitialized.

[

]

0111

Bad Confirmation: This status is reported when there was an error during confirmation. For confirmation, the MACSI

device compares the returning frame to the Expected Frame Status (EFS). If these values do not match, the ‘‘Bad

Confirmation’’ value is returned in the RS field. If the transmitted frame does not return, (My Void, Other Void, or

Ð

Token received instead) or if the ring state changes, (MAC Reset or the Ring Operational flag changes), the Bad

Ð

Confirmation value is also returned.

[

]

1000

1001

1010

Underrun: This exception is caused when the memory interface does not allow the MACSI device to fill the transmit

data FIFO as quickly as it is being emptied. It implies that the frame was aborted during transmission.

Host Abort: This exception is caused when the host software clears the SAR.ABT bit to force an abort or when there is

not enough space in the confirmation (CNF) queue. This implies that the Request did not complete normally.

Bad Ringop: This exception is reported when the Request Class for a Request object is incompatible with the current

ring state, (i.e. Immediate class with an operational ring or Async, Sync, or restricted class when the ring state is non-

operational). The Request was aborted.

[

]

1011

1100

MAC Device Abort: This exception indicates that the MACSI device aborted the Request and asserted TXABORT.

This could be from an interface parity error, or because the transmitted frame failed the FC check, or because the

MACSI device received a MAC frame while transmitting in the DATA state. This status is also returned when the MACSI

device receives an Other Beacon while transmitting in the Beacon state, or when the Claim process is lost while

Ð

transmitting in the Claim state. It implies that the Request did not complete normally.

]

Timeout: This exception code indicates that the TRT timer expired during the transmission of a Request with THT

disabled. Normally the Ring Engine will finish the current frame and release the Token when the Token Holding Timer

(THT) expires. However, for certain requests, the THT can be disabled. In this case, the Token Rotation Timer (TRT)

may expire because the station has made the Token Late. The Ring Engine will abort the request and a Timeout will be

signaled to the System Interface.

[

]

1101

MAC Reset: This code indicates that the MACSI underwent a MAC Reset during this request. A MAC Reset can be

generated by software, (i.e. requested via the control bus), or caused by hardware, (the MACSI state machines entered

and illegal state). In either case the Request is aborted.

1110

Consistency Failure: This code indicates that the MACSI device detected an inconsistency in the REQ or ODUD

descriptor queues. For example, if a frame started with on ODUD.First it should be followed by an ODUD.Middle or

ODUD.Last. If the next ODUD was another ODUD.First this would be a consistency error. The Request is aborted when

a consistency error is detected.

ERROR

[

]

1111

Internal or Fatal ABus Error: This exception is caused when the MACSI device detects an internal hardware error

(e.g. illegal state machine state), in the transmit logic while transmitting a frame. It is also set when an ABus error

occurs during frame transmission. It implies that the frame data may not have been transmitted properly.

FIGURE 7-8. Request Status Field (RS) of CNF Descriptor

129

7.0 Control Information (Continued)

Pool Space Descriptor (PSP)

Pool Space Descriptors (PSPs) contain the address of a free space in host memory available for writing Input Data Units. The

count field is not used. The space is assumed to end at the next 4 kByte boundary. When PSPs are read by the MACSI device,

the address field of the PSP is loaded into the Indicate Channel’s IDU Pointer Register, and is used as the address for the IDU

memory write.

31 30 29 28 27

13 12

0

RES

CNT

Word 0

Word 1

F-L

RES

LOC

Bit

Symbol

Description

Word 0

D12–D0

CNT

Byte Count: Number of bytes of available memory area (this field is currently not used by the MACSI

device). To ensure software compatibility with future devices which may use this field, this field may be

written with the number of bytes from PSP.LOC to the next 4 kByte boundary.

D31–D13

Word 1

RES

LOC

Reserved

D27–D0

Location: Memory byte address of memory area available for writing IDUs. Normally the page offset will

be Zero to simplify space management. Must be burst aligned to the size of the largest burst enabled (4

word or 8 word).

D29–D28

D31–D30

RES

F-L

Reserved

e

First/Last Tag: Identifies the PSP part, should be PSP.Only (i.e F-L

11).

130

8.0 Signal Descriptions

The DP83266 MACSI device is packaged in a 160-pin Plastic Quad Flat Pack. The signals are divided into the following

interfaces:

Control Interface:

PHY Interface:

Used for microprocessor access to the Ring Engine and Service Engine.

a

Interface signals to the DP83251/55 PLAYER or DP83256/57 PLAYER

.

External Matching

Interface:

Interface signals used for external address matching.

Used to control status LEDs.

LED Interface:

ABus Interface:

Electrical Interface:

Multiplexed Address/Data System Interface.

Signals associated with power supply and clocking.

8.1 CONTROL INTERFACE

The Control Interface operates asynchronously 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 a wired-OR connection of several such signals.

Ý

Symbol

CBP

I/O

I

Description

Control Bus Parity: Odd parity on CBD7–0.

155

CBD7–0

CBA8–0

CE

154–147

144–136

130

Control Bus Data: Bidirectional Data bus.

Control Bus Address: Address of a particular MACSI device register.

I

Control Bus Enable: Handshake signal used to begin a Control Interface access. Active low

signal.

R/W

ACK

129

133

I

Read/Write: Determines current direction of a Control Interface access.

OD

Acknowledge: Acknowledges that the Control Interface access has been performed. Active

low, open drain signal.

INT1–0

131, 132

OD

Interrupt: Indicates presence of one or more enabled conditions in the Event Registers. One

Interrupt signal is provided as an indication to management services and one is provided as an

indication to data services. These can be tied together externally to create a single interrupt

signal if desired. Active low, open drain signal.

131

8.0 Signal Descriptions (Continued)

8.2 PHY INTERFACE

a

The PHY Interface signals transfer symbol pairs between the MACSI and PLAYER devices. Transfers are synchronous using

a

the 12.5 MHz Local Byte Clock signal (signal provided by the PLAYER 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 PH Indicate and MA Indicate data. Parity is checked on the PH Request and MA Request data.

Ð

Ý

Symbol

PRP

122

120

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–PRD0

118, 116, 114,

110, 108, 106,

104, 102

O

PHY Request Data: Contains a Data or Control symbol pair.

PIP

PIC

123

121

I

PHY Indicate Parity: Odd parity for PIC and PID7–0.

PHY Indicate Control:

0: Indicates PRD7–PRD0 contains a Data symbol pair.

1: Indicates PRD7–PRD0 contains a Control or mixed Control/Data symbol pair.

PID7–PID0

119, 117, 115,

111, 109, 107,

105, 103

I

PHY Indicate Data: Contains a Data or a mixed Control/Data symbol pair.

132

8.0 Signal Descriptions (Continued)

8.2.1 PHY Interface Codes

a

The DP83256/57 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

a

Ð

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 8-1.

a

TABLE 8-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

Ð

I I

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

Parity Error

Other wise

Else

where:

PIP

PHY Indicate Parity bit, ODD parity

PHY Indicate Control bit:

PIC

t

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

133

8.0 Signal Descriptions (Continued)

a

The Idle and PH Invalid encodings overlap. Idle symbols received while the PLAYER device is in Active Line State (ALS) or

Idle Line State (ILS0 are not considered PH INVALID). Idle symbols received while the PLAYER device is in states other

Ð

a

Ð

than ALS or ILS are treated as PH Invalid.

Ð

PH DATA.Request

Ð

The Ring Engine generates the 10-bit byte stream as defined in Table 8-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 8-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

I I

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

t

0

1

data byte

control byte

PRD(7–0) PHY Request Data (7–0)

The Ring Engine can repeat the RT and ST symbol pairs but will not generate them.

134

8.0 Signal Descriptions (Continued)

8.3 EXTERNAL MATCHING INTERFACE

The External Matching Interface provides the means to add external address recognition logic. The results of these address

comparisons are conveyed on the appropriate signals.

Ý

Symbol

I/O

Description

ECIP

86

I

External Compare In Progress: This signal is asserted to indicate that external address

comparison has begun. It is deasserted to indicate that the comparison has completed. ECOPY

and EM are sampled on the rising edge of LBC1 after the deassertion of ECIP. ECIP must be

asserted before the seventh byte of the INFO field in order for the MACSI device to recognize an

external comparison. It must be deasserted for at least one cycle for the external comparison to

complete. If ECIP has not been deasserted before two bytes after the End Delimiter (ED, from the

a

PLAYER device), the MACSI device will not copy this frame. ECIP may be implemented as a

positive or negative pulse. Note that ECIP will affect the operation of the MACSI device even if the

external copy mode is not specifically selected. See Section 6.3 on page 30 for more details on the

external matching interface.

ECOPY

EA

84

85

I

External Copy: Indicates that the current frame should be copied, if possible. Sampled on the

rising edge of LBC1 after ECIP is deasserted.

External Destination Address Match: Indicates that an explicit match occurred on the current

frame. This affects the setting of the A indicator for this frame. Sampled one byte time before ED is

received by the Ring Engine.

EM

87

90

I

External Source Address Match: Indicates that the current frame was transmitted by this station

and should be stripped. The Ring Engine will begin stripping three byte times after the assertion of

EM. The Service Engine samples EM on the rising edge of LBC1 after the deassertion of ECIP.

LEARN

O

Learn: Provided for transparent bridging applications. Indicates that the current frame should be

copied and the Source Address be added to the address filter database if not already present. This

signal is asserted for Long Address frames which were not sourced by this station. If frames are

sent using Source Address Transparency (SAT) using the My Void stripping mechanism, Learn

Ð

will be false from the transmission of the first SAT frame until after the My Void frame is received.

Ð

Learn is valid at the ‘‘INFO Received’’ point for each frame. This is when the fourth byte of INFO

field passes between the Ring Engine and the System Interface. This occurs three byte-times after

a

the fourth byte of the INFO field passes between the PLAYER device and the MACSI device.

AFINHIB

26

I

AFLAG Inhibit: For MACSI Revision D or later, this pin allows the User to suppress internal

address recognition on individual frames. By asserting this pin before the 7th byte of the INFO field

(as measured at the PID interface), the User can block the AFLAG signal between the MAC and

the System Interface. For the MACSI to recognize this pin, the User must assert the MAC Mode

Register 2, AFLAG Inhibit Enable bit (MCMR2.AFIE). For MACSI Revision prior to D, this is a No

Connect pin.

8.4 LED INTERFACE

These signals provide a means for controlling status LEDs to give a visual indication of transmit and receive activity. Since the

LED control pins use open-drain output structures, the User must supply pull-up resistors. This interface is only available on

MACSI Revision D or later.

Ý

Symbol

I/O

Description

TXLED

98

OD

Transmit LED: The MACSI will assert this pin when it detects that the Request State machine has

entered the ‘‘sending’’ state, (once per transmitted frame). Note that the MACSI device will not

assert TXLED for internally generated MAC frames. This pin will not drive an LED directly. The User

must supply a one-shot circuit to create a pulse long enough to make the LED visible.

RXLED

99

OD

Receive LED: The MACSI will assert this pin when it detects the End Delimiter of a copied frame

(VCOPY and EDRCVD). This pin will not drive an LED directly. The User must supply a one-shot

circuit to create a pulse long enough to make the LED visible.

135

8.0 Signal Descriptions (Continued)

8.5 ABus INTERFACE

The ABus interface signals provide a 28-bit address 32-bit data bus for transfers between the host system and the MACSI

device. The ABus uses a bus request/bus grant protocol that allows for multiple bus masters, supports burst transfers of 4 or 8

32-bit words, and permits both physical and virtual addressing using fixed-size pages.

Address and Data:

Ý

Symbol

I/O

Description

AB BP3–0

Ð

50, 61, 72, 83

I/O

ABus Byte Parity: These TRI-STATE signals contain the parity for each address

and data byte of AB AD, such that AB BP0 is the parity for AB AD7-0, AB BP1

Ð

is the parity for AB AD15-8, etc.

Ð

AB AD31–0

Ð

40–42, 45–49,

51–53, 56–60,

62–65, 68–71,

73–76, 79–82

I/O

ABus Address and Data: These TRI-STATE signals are the multiplexed ABus

address and data lines. During the address phase of a cycle, AB AD27-0 contain

Ð

e

by the user (by programming SIMR1.AB A31–27) during the address cycle. When

the 28-bit address. When SIMR1.EAM

1, AB AD31-28 contain a value specified

Ð

0, AB AD31-28 contain a 4-bit function code identifying the type of

e

SIMR1.EAM

transaction, encoded as follows:

Ð

[

AB AD 31:28

]

Transaction Type

RCHN1 ODU Load

Ð

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

RCHN1 ODUD Load/CNF Store

RCHN1 REQ Load

RCHN0 ODU Load

RCHN0 ODUD Load/CNF Store

RCHN0 REQ Load

ICHN2 IDU Store

ICHN2 IDUD Store

ICHN2 PSP Load

ICHN1 IDU Store

ICHN1 IDUD Store

ICHN1 PSP Load

ICHN0 IDU Store

ICHN0 IDUD Store

ICHN0 PSP Load

PTR RAM Load/Store

AB A27–2

Ð

25–19, 16–5,

2–1, 160–156

O

ABus Demultiplexed Address: These TRI-STATE signals contain the word

address during ABus accesses. They are driven from Tpa to the last Td state,

negated in the following Tr state, then released. Note that the timing of these signals

is under software control via the System Interface Mode Register 1 (SIMR1). For

MACSI revision A through C, the User must set SIMR1.ATM to one for the

demultiplexed address pins AB A (27:2) to work properly. For MACSI revision D

Ð

and later (SI revision 0x00000058), the User may use the demultiplexed address

t

pins AB A (27:2) with SIMR1.ATM set to one or zero. Since the MACSI device

Ð

makes only word (4 byte) accesses on the ABus, the device does not include pins

for AB A (1:0). These pins would drive a zero for every access.

Ð

136

8.0 Signal Descriptions (Continued)

Bus Control:

Ý

Symbol

I/O

Description

AB AS

Ð

39

O

ABus Address Strobe: When first asserted, this TRI-STATE signals indicates that address on

AB AD is valid. When this signal is inactive and AB ACK is asserted, the next cycle is a Recovery

Ð

State (Tr), in which the bus arbiter can sample all bus requests, then issue a bus grant in the

following cycle. Note that the timing of this signal is under software control via Mode Register 1

(MR1).

AB R/W

Ð

35

34

O

ABus Read/Write: This TRI-STATE signal determines the current direction of an ABus access. A

high level indicates a read access and a low level indicates a write access.

AB DEN

Ð

I/O ABus Data Enable: In normal ABus mode, this TRI-STATE signal indicates that data on

AB AD31–0 is valid. In the enhanced ABus mode for SBus, this signal is an additional

Ð

Acknowledgment input.

AB SIZ2–0 31-29

Ð

O

ABus Size: These TRI-STATE signals indicate the size of the transfer on AB AD31-0, encoded as

Ð

follows:

Transfer

AB SIZ2 AB SIZ1 AB SIZ0

Ð

Size

Ð

0

Ð

0

4 Bytes

0

1

0

1

0

1

0

1

0

1

0

1

Reserved

16 Bytes

32 Bytes

Reserved

AB ACK

Ð

37

36

I

ABus Acknowledge: Indicates a bus slave’s response to a bus master. The meaning of this signal

depends on the state of ABus Error (AB ERR) as well as the ABus mode selected (normal or

Ð

enhanced). The exact function is described below.

AB ERR

Ð

ABus Error: In normal ABus mode, this signal is asserted by a bus slave to cause a transaction

retry or transaction abort. In the enhanced ABus mode for SBus, this signal together with

AB ACK and AB DEN encode the acknowledgment type. The encoding is as follows:

Ð

e

AB ACK AB ERR AB ACK AB DEN AB ERR

e

1

EAM

0

EAM

Function

Ð

Ack(2)*

Ð

Ack(1)*

Ð

Ack(0)*

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

Wait Cycle

0

1

Word Acknowledgement

Retry

Error

Not Supported

Bus Arbitration:

Ý

Symbol

I/O

O

Description

AB BR

Ð

28

ABus Bus Request: This signal is used by the MACSI device to request use of the ABus.

ABus Grant: This signal is asserted by external bus arbitration logic to grant use of the ABus to

the MACSI device. If AB BG is asserted at the start of a transaction (Tbr), the MACSI device will

AB BG

Ð

27

38

I

Ð

e

up to two cycles to respond to AB BG. Therefore, AB BG should not be removed until the

run a transaction. Note that in normal ABus mode (MR1.EAM

0), the MACSI device may take

Ð Ð

MACSI device has indicated that it has sampled AB BG and taken the bus, (this can be

Ð

determined with AB AS for example).

Ð

AB CLK

Ð

I

ABus Clock: All ABus operations are synchronized to the rising edge of AB CLK.

Ð

137

8.0 Signal Descriptions (Continued)

8.6 ELECTRICAL INTERFACE

Ý

Symbol

I/O

Description

a

LBC5, 3

125, 126

I

Local Byte Clock: 12.5 MHz clocks with a 50/50 duty-cycle, generated by the PLAYER

device.

a

LBC1

LSC

127

124

I

Local Byte Clock: 12.5 MHz clock with a 50/50 duty-cycle, generated by the PLAYER

.

a

Local Symbol Clock: 25 MHz clock with a 40/60 duty-cycle, generated by the PLAYER

device.

RST

128

I

Reset: Active Low input which resets the Internal State Machines and most Registers. This

signal must be asserted for at least five clock cycles. When asserted, all bidirectional signals

are at TRI-STATE.

TCK

TMS

TDI

95

94

93

92

91

I

TCK: JTAG Scan Clock

TMS: JTAG Mode Select

I

TDI: JTAG Data In

TDO

TRST

O

I

TDO: JTAG Data Out

TRST: JTAG Reset. Active low signal.

Positive Power Supply: 5V, 10% relative to GND.

[

]

V

CC

11

3, 17, 32,

43, 54,

66, 77,

97, 113,

135, 146

[

GND 11

]

4, 18, 33,

44, 55,

Ground: Power Supply Return.

67, 78,

96, 112,

134, 145

RSRVD0

N/C

88,

I

Reserved 0: Must be connected to ground.

No Connect: Must be left unconnected.

100, 101

89

138

9.0 Electrical Characteristics

9.1 ABSOLUTE MAXIMUM RATINGS

Symbol

Parameter

Supply Voltage

Conditions

Min

Typ

Max

7.0

a

Units

b

V

CC

0.5

V

b

DC

T

Input Voltage

V

0.5

IN

CC

a

CC

Output Voltage

OUT

b

Storage Temperature

Lead Temperature

65

150

230

C

§

STG

T

L

Soldering, 10 Sec.

(IR or Vapor)

C

§

(Phase Reflow)

ESD Protection

2000

V

9.2 RECOMMENDED OPERATING CONDITIONS

Symbol

Parameter

Supply Voltage

Conditions

Min

4.75

0

Typ

Max

5.25

70

Units

V

T

V

CC

Operating Temperature

Power Dissipation

C

§

A

e

PD

C

L

50 pf,

945

mW

e

AB CLK

LBC

12.5 MHz,

e

25 MHz

Ð

9.3 DC ELECTRICAL CHARACTERISTICS

The DC characteristics are over the operating range, unless otherwise specified.

Symbol

Parameter

Conditions

e b

Min

Typ

Max

Units

V

Output High Voltage

Output Low Voltage

I

8 mA

2.4

V

OH

OL1

OL2

IH

OH

OL

e

0.4

Output Low Voltage for INT0, INT1, and ACK (open drain)

Input High Voltage

8 mA

V

2.0

V

Input Low Voltage

0.8

V

IL

e

b

a

g

I

Input Low Current

V

GND

10

mA

IL

IN

Input High Current

V

CC

IH

IN

TRI-STATE Leakage

OZ1

OZ2

CC

TRI-STATE Leakage for INT0, INT1, and ACK (open drain)

Dynamic Supply Current

e

C

50 pf,

180

L

e

AB CLK

LBC

12.5 MHz,

e

25 MHz

Ð

139

9.0 Electrical Characteristics (Continued)

9.4 AC ELECTRICAL CHARACTERISTICS

The AC Electrical characteristics are over the operating range, unless otherwise specified.

AC Characteristics for the Control Bus Interface

Symbol

T1

Parameter Descriptions

CE Setup to LBC

Min

15

Max

Units

ns

T2

LBC Period

80

T3

LBC1 to ACK Low

45

540

60

T4

CE Low to ACK Low

290

T5

LBC1 Low to CBD(7-0) and CBP Valid

LBC1 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

T6

5

T7

225

265

35

475

515

45

T8

T9

T10

T11

T12

T13

T14

T15

T16

T17

T18

T19

T20A

T20B

T20C

T21

LBC Pulse Width Low

35

45

CE High to ACK High

45

R/W, CBA(7-0), CBD(7-0) and CBP Set up to CE Low

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 to LBC1 Setup Time

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

5

0

20

0

20

55

0

CBD(7-0) Valid to ACK Low Setup

LBC1 to R/W Hold Time

20

10

20

LBC1 to CBA Hold Time

LBC1 to CBD and CBP Hold Time

LBC1 to INT0, INT1 Low

55

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

140

9.0 Electrical Characteristics (Continued)

TL/F/11705–18

FIGURE 9-1. Asynchronous Control Bus Write Cycle Timing

TL/F/11705–19

FIGURE 9-2. Asynchronous Control Bus Read Cycle Timing

141

9.0 Electrical Characteristics (Continued)

TL/F/11705–20

FIGURE 9-3. Control Bus Synchronous Write Cycle Timing

TL/F/11705–21

FIGURE 9-4. Control Bus Synchronous Read Cycle Timing

142

9.0 Electrical Characteristics (Continued)

AC Characteristics for the Clock Interface Signals

Symbol

T51

Parameter

Min

13

29

5

Typ

Max

19

Units

ns

LBC1 to LBC3 Lead Time

T52A

T52B

T53

LBC1 to LBC5 Lead Time

35

ns

LBC5 Rising to LBC1 Falling Lead Time

LBC1, LBC3, and LBC5 Period

LBC1, LBC3, and LBC5 Pulse Width High

LBC1, LBC3, and LBC5 Pulse Width Low

8

12

ns

80

ns

T54

35

45

6

ns

T55

ns

b

²

T56

LSC to LBC1 Lead Time (Skew Left)

LSC Pulse Width High

3

ns

T57

12

21

ns

T58

LSC Pulse Width Low

ns

a

Note that the capacitive loading on PLAYER LSC output must not exceed the loading on the LBC1 output.

²

TL/F/11705–22

FIGURE 9-5. Clock Interface Timing Diagram

143

9.0 Electrical Characteristics (Continued)

AC Characteristics for Port A Interface and Port B Interface for MACSI Revision C

Symbol

Parameter

Min

Typ

Max

Units

T26

PHY Data Inputs, ECIP, ECOPY, EM, EA

Setup to LBC1

20

ns

T27

T28

T29

T32

T33

T34

T35

T36

T37

PHY Data Inputs, ECIP, ECOPY, EM, EA

Hold from LBC1

2

8

ns

PHY Data Outputs, LEARN

Sustain from LBC1

PHY Data Outputs, LEARN

LBC1 to Data Valid

35

20

ABus Outputs

AB CLK to TRI-STATE

Ð

AB AD(31:0), AB BP Output

Ð Ð

AB CLK to Data Valid

Ð

AB AD(31:0), AB BP Output

Ð Ð

Sustain from AB CLK

5

15

7

Ð

AB AD(31:0), AB BP Input

Ð

Setup to AB CLK

Ð

AB AD(31:0), AB BP Input

Ð

Hold from AB CLK

Ð

AB ACK, AB BG

Ð Ð

Setup to AB CLK

20

7

Ð

²

T38

T39

T40

T41

T42

F1

AB ACK, AB BG

Ð Ð

Hold from AB CLK

Ð

AB ERR, AB DEN

Ð Ð

Setup to AB CLK

20

7

Ð

AB ERR, AB DEN

Ð Ð

Hold from AB CLK

Ð

AB AS, AB SIZ(2:0), AB RW, AB DEN

20

25

Ð

AB BR, AB A, Data Valid from AB CLK

Ð

AB AS, AB SIZ(2:0), AB RW, AB DEN

5

Ð

AB BR, AB A, Data sustain from AB CLK

Ð

AB CLK Frequency

Ð

12.5

MHz

e

²

This specification applies to ‘‘normal’’ ABus Mode only (SIMR1.EAM

0). For information regarding the Enhanced ABus Mode specification (SIMR1.EAM

1),

please contact National Semiconductor.

TL/F/11705–23

FIGURE 9-6. PHY Interface Timing

144

9.0 Electrical Characteristics (Continued)

AC Characteristics for Port A Interface and Port B Interface for MACSI Revision D

Symbol

Parameter

Min

Typ

Max

Units

T26

PHY Data Inputs, ECIP, ECOPY, EM, EA, AFINHIB

Setup to LBC1

TBD

ns

T27

T28

T29

T32

T33

T34

T35

T36

T37

T38

T39

T40

T41

T42

F1

PHY Data Inputs, ECIP, ECOPY, EM, EA, AFINHIB

Hold from LBC1

TBD

ns

MHz

PHY Data Outputs, LEARN

Sustain from LBC1

PHY Data Outputs, LEARN

LBC1 to Data Valid

ABus Outputs

AB CLK to TRI-STATE

Ð

AB AD(31:0), AB BP Output

Ð Ð

AB CLK to Data Valid

Ð

AB AD(31:0), AB BP Output

Ð Ð

Sustain from AB CLK

Ð

AB AD(31:0), AB BP Input

Ð

Setup to AB CLK

Ð

AB AD(31:0), AB BP Input

Ð

Hold from AB CLK

Ð

AB ACK, AB BG

Ð Ð

Setup to AB CLK

Ð

AB ACK, AB BG

Ð Ð

Hold from AB CLK

Ð

AB ERR, AB DEN

Ð Ð

Setup to AB CLK

Ð

AB ERR, AB DEN

Ð Ð

Hold from AB CLK

Ð

AB AS, AB SIZ(2:0), AB RW, AB DEN

Ð

AB BR, AB A, Data Valid from AB CLK

Ð

AB AS, AB SIZ(2:0), AB RW, AB DEN

Ð

AB BR, AB A, Data sustain from AB CLK

Ð

AB CLK Frequency

Ð

145

9.0 Electrical Characteristics (Continued)

TL/F/11705–24

FIGURE 9-7a. ABus Read Cycle Timing Diagram

146

9.0 Electrical Characteristics (Continued)

TL/F/11705–25

Figure 9-7b. ABus Write Cycle Timing Diagram

147

9.0 Electrical Characteristics (Continued)

AC Signal Testing

TL/F/11705–26

FIGURE 9-8. AC Signal Testing

TL/F/11705–27

FIGURE 9-9. TRI-STATE Timing

Test Conditions for AC Testing

V

3.0V

0.0V

1.5V

IH

IL

OH

OL

C

L

50 pF

148

9.0 Electrical Characteristics (Continued)

Test Equivalent Loads

TL/F/11705–28

TL/F/11705–29

TL/F/11705–30

TL/F/11705–31

TL/F/11705–32

FIGURE 9-10. Test Equivalent Loads

149

10.0 Pin Table and Pin Diagram

Pin Description I/O

1

2

AB A7

Ð

O

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

AB AD30

Ð

I/O

81 AB AD1

Ð

I/O

121 PIC

122 PRP

123 PIP

I

AB A8

Ð

AB AD29

Ð

82 AB AD0

Ð

I/O

O

3

V

CC

83 AB BP0

Ð

I/O

I

CC

4

GND

84 ECOPY

85 EA

I

124 LSC

125 LBC5

126 LBC3

127 LBC1

128 RST

129 R/W

130 CE

I

5

AB A9

Ð

O

AB AD28

Ð

I/O

I

6

AB A10

Ð

AB AD27

Ð

86 ECIP

87 EM

I

7

AB A11

Ð

AB AD26

Ð

I

8

AB A12

Ð

AB AD25

Ð

88 RSRVD0

89 N/C

90 LEARN

91 TRST

92 TDO

93 TDI

9

AB A13

Ð

AB AD24

Ð

I

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

AB A14

Ð

AD BP3

Ð

I

AB A15

Ð

AB AD23

Ð

131 INT1

132 INT0

133 ACK

134 GND

OD

O

AB A16

Ð

AB AD22

Ð

O

I

AB A17

Ð

AB AD21

Ð

AB A18

Ð

V

CC

94 TMS

95 TCK

96 GND

I

AB A19

Ð

GND

I

135

V

CC

AB A20

Ð

AB AD20

Ð

I/O

136 CBA0

137 CBA1

138 CBA2

139 CBA3

140 CBA4

141 CBA5

142 CBA6

143 CBA7

144 CBA8

145 GND

I

V

AB AD19

Ð

97

V

CC

GND

AB AD18

Ð

98 TXLED*

99 RXLED*

100 RSRVD0

101 RSRVD0

102 PRD0

103 PID0

OD

AB A21

Ð

O

I

AB AD17

Ð

OD

I

AB A22

Ð

AB AD16

Ð

AB A23

Ð

AD BP2

Ð

I

AB A24

Ð

AB AD15

Ð

O

I

AB A25

Ð

AB AD14

Ð

AB A26

Ð

AB AD13

Ð

104 PRD1

105 PID1

O

I

AB A27

Ð

AB AD12

Ð

AFINHIB*

V

CC

106 PRD2

107 PID2

O

I

146

V

CC

AB BG

Ð

I

GND

147 CBD0

148 CBD1

149 CBD2

150 CBD3

151 CBD4

152 CBD5

153 CBD6

154 CBD7

155 CBP

I/O

O

AB BR

Ð

O

AB AD11

Ð

I/O

108 PRD3

109 PID3

O

I

AB SIZ0

Ð

AB AD10

Ð

AB SIZ1

Ð

AB AD9

Ð

110 PRD4

111 PID4

O

I

AB SIZ2

Ð

AB AD8

Ð

V

CC

AB BP1

Ð

112 GND

GND

AB AD7

Ð

113

V

CC

AB DEN

Ð

I/O

AB AD6

Ð

114 PRD5

115 PID5

116 PRD6

117 PID6

118 PRD7

119 PID7

120 PRC

O

I

AB R/W

Ð

O

AB AD5

Ð

AB ERR

Ð

I

AB AD4

Ð

O

I

156 AB A2

Ð

AB ACK

Ð

V

CC

157 AB A3

Ð

O

AB CLK

Ð

I

GND

O

I

158 AB A4

Ð

O

AB AS

Ð

O

I/O

AB AD3

Ð

I/O

159 AB A5

Ð

O

AB AD31

Ð

AB AD2

Ð

O

160 AB A6

Ð

O

* For MACSI revisions A through C, these three pins had the following functions: Pin 26ÐN/C, Pins 98 and 99ÐRSRVD0. Note that since TXLED and RXLED use

open-drain output structures, the new pinout remains backward compatible with earlier MACSI devices.

150

10.0 Pin Table and Pin Diagram (Continued)

The pinout of the MACSI device is shown in the diagram below.

TL/F/11705–33

FIGURE 10-1. DP83266 Pinout

151

Physical Dimensions millimeters

Plastic Quad Flat Pack (VUL)

Order Number DP83266VF

NS Package Number VUL160A

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.


型号：	DP83266
厂家：	National Semiconductor
描述：	MACSITM Device (FDDI Media Access Controller and System Interface) MACSITM设备（ FDDI的媒体访问控制器和系统接口）控制器
文件：	总152页 (文件大小：1136K)
中文：	中文翻译
下载：	下载PDF数据表文档文件

DP83266 [NSC]

相关型号：

DP83266VF

DP83266VF-MPC

DP83290EB

DP83291EB

DP8340J

DP8340J/A+

DP8340N

DP8340N/A+

DP8340N/B+

DP8340V

DP8340VX

DP8341J