NSC DP83266VF-MPC Datasheet

TL/F/11705

DP83266 MACSI Device (FDDI Media Access Controller and System Interface)

PRELIMINARY

October 1994

DP83266 MACSITMDevice (FDDI Media Access Controller and System Interface)

General Description

The DP83266 Media Access Controller and System Interface (MACSI) implements the ANSI X3T9.5 Standard Media Access Control (MAC) protocol for operation in an FDDI token ring and provides a comprehensive System Interface.

The MACSI device transmits, receives, repeats, and strips tokens and frames. It produces and consumes optimized data structures for efficient data transfer. Full duplex architecture with through parity allows diagnostic transmission and self testing for error isolation and point-to-point connections.

The MACSI device includes the functionality of both the DP83261 BMAC

device and the DP83265 BSI-2TMdevice with additional enhancements for higher performance and reliability.

Features

Over 9 kBytes of on-chip FIFO

5 DMA channels (2 Output and 3 Input)

12.5 MHz to 25 MHz operation

Full duplex operation with through parity

Supports JTAG boundary scan

Real-time Void stripping indicator for bridges

On-chip address bit swapping capability

32-bit wide Address/Data path with byte parity

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

Receive frame filtering services

Frame-per-Page mode controllable on each DMA channel

Demultiplexed Addresses supported on ABus

New multicast address matching feature

ANSI X3T9.5 MAC standard defined ring service options

Supports all FDDI Ring Scheduling Classes (Synchronous, Asynchronous, etc.)

Supports Individual, Group, Short, Long and External Addressing

Generates Beacon, Claim, and Void frames

Extensive ring and station statistics gathering

Extensions for MAC level bridging

Enhanced SBus compatibility

Interfaces to DRAMs or directly to system bus

Supports frame Header/Info splitting

Programmable Big or Little Endian alignment

Block Diagram

TL/F/11705– 1

FIGURE 1-1. FDDI Chip Set Block Diagram

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

, BSI-2TM, MACSITMand PLAYER

are trademarks of National Semiconductor Corporation.

1995 National Semiconductor Corporation RRD-B30M105/Printed in U. S. A.

Table of Contents

1.0 FDDI CHIP SET OVERVIEW

2.0 GENERAL FEATURES

2.1 FDDI MAC Support

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

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

2.19 Clustered Interrupts

2.20 FIFO Memory

2.21 Frame-per-Page-per-Channel

2.22 Copy All Multicast

2.23 Bridge Stripping Information

2.24 LED Status Control Outputs

2.25 JTAG Boundary Scan

3.0 ARCHITECTURAL DESCRIPTION

3.1 Interfaces

3.2 Ring Engine

3.3 Data Structures

3.4 Service Engine

4.0 FDDI MAC FACILITIES

4.1 Symbol Set

4.2 Protocol Data Units

4.3 Frame Counts

4.4 Timers

4.5 Ring Scheduling

5.0 FUNCTIONAL DESCRIPTION (RING ENGINE)

5.1 Token Handling

5.2 Servicing Transmission Requests

5.3 Request Service Parameters

5.4 Frame Validity Processing

5.0 FUNCTIONAL DESCRIPTION (RING ENGINE)

(Continued)

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

5.12 Handling Internal Errors

6.0 FUNCTIONAL DESCRIPTION (SERVICE ENGINE)

6.1 Overview

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

7.4 Ring Engine Operation Registers

7.5 MAC Parameters

7.6 Timer Values

7.7 Event Counters

7.8 Pointer RAM Registers

7.9 Limit RAM Registers

7.10 Descriptors

7.11 Operating Rules

7.12 Pointer RAM Register Descriptions

7.13 Limit RAM Register Descriptions

8.0 SIGNAL DESCRIPTIONS

8.1 Control Interface

8.2 PHY Interface

8.3 External Matching Interface

8.4 LED Interface

8.5 ABus Interface

8.6 Electrical Interface

9.0 ELECTRICAL CHARACTERISTICS

9.1 Absolute Maximum Ratings

9.2 Recommended Operating Conditions

9.3 DC Electrical Characteristics

9.4 AC Electrical Characteristics

10.0 PIN TABLE AND PIN DIAGRAM

1.0 FDDI Chip Set Overview

National Semiconductor’s FDDI chip set is shown in

Figure

1-1.

For more information about the PLAYER

device,

consult the appropriate datasheet and application notes.

DP83256/56-AP/57 PLAYER

Device Physical Layer Controller

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

Single chip FDDI Physical Layer (PHY) solution

Integrated Digital Clock Recovery Module provides enhanced tracking and greater lock acquisition range

Integrated Clock Generation Module provides all necessary clock signals for an FDDI system from an external

12.5 MHz reference

Alternate PMD Interface (DP83256-AP/57) Supports UTP twisted pair FDDI PMDS with no external clock recovery or clock generations functions required

No External Filter Components

Connection Management (CMT) Support (LEM, TNE, PCÐReact, CFÐReact, Auto Scrubbing)

Full on-chip configuration switch

Low Power CMOS-BIPOLAR design using a single 5V supply

Full duplex operation with through parity

Separate management interface (Control Bus)

Selectable Parity on PHY-MAC Interface and Control Bus Interface

Two levels of on-chip loopback

4B/5B encoder/decoder

Framing logic

Elasticity Buffer, Repeat Filter, and Smoother

Line state detector/generator

Supports single attach stations, dual attach stations and concentrators with no external logic

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.

DP83266 MACSI Device Media Access Controller and System Interface

The MACSI device implements the Timed Token Media Access Control protocol defined by the ANSI FDDI X3T9.5 MAC Standard as well as a high performance system interface.

Features

Over 9 kBytes of on-chip FIFO

5 DMA channels (2 Output and 3 Input)

12.5 MHz to 25 MHz operation

Full duplex operation with through parity

Supports JTAG boundary scan

Real-time Void stripping indicator for bridges

On-chip address bit swapping capability

32-bit wide Address/Data path with byte parity

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

Receive frame filtering services

Frame-per-Page mode controllable on each DMA channel

Demultiplexed Addresses supported on ABus

New multicast address matching feature

ANSI X3T9.5 MAC standard defined ring service options

Supports all FDDI Ring Scheduling Classes (Synchronous, Asynchronous, etc.)

Supports Individual, Group, Short, Long and External Addressing

Generates Beacon, Claim, and Void frames

Extensive ring and station statistics gathering

Extensions for MAC level bridging

Enhanced SBus compatibility

Interfaces to DRAMs or directly to system bus

Supports frame Header/Info splitting

Programmable Big or Little Endian alignment

2.0 General Features

The DP83266 MACSI device is a highly integrated FDDI controller. Together with the DP83256/57 PLAYER

device, 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.

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 demultiplexed on dedicated pins. The system interface supports virtual addressing using fixed-size pages.

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, filtering MAC frames with the same Information field as well as Void frames, and performing network monitoring functions.

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 information necessary to implement the service primitives defined in the standard.

2.2 MAC ADDRESSING SUPPORT

Both long (48-bit) and short (16-bit) addressing are supported simultaneously, for both Individual and Group addresses.

2.3 MAC BRIDGING SUPPORT

Several features are provided to increase performance in bridging applications.

On the receive side, external address matching logic can be used to examine the PHÐIndicate byte stream to decide whether to copy a frame, how to set the control indicators and how to increment the counters.

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

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

2.4 MAC SERVICE CLASS SUPPORT

All FDDI MAC service classes are supported by the MACSI device including Synchronous, Asynchronous, Restricted Asynchronous, and Immediate service classes.

For Synchronous transmission, one or more frames are transmitted in accordance with the station’s synchronous bandwidth allocation.

For Asynchronous transmission, one programmable asynchronous priority threshold is supported in addition to the threshold at the Negotiated Target Token Rotation time.

For Restricted Asynchronous transmission, support is provided to begin, continue and end restricted dialogues.

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

2.5 DIAGNOSTIC COUNTERS

The MACSI device includes a number of diagnostic counters and timers that monitor ring and station performance.

These counters allow measurement of the following:

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 received and the ring latency

Ring latency

Lost frames

The size of these counters has been selected to keep the frequency of overflow small, even under worst case operating 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.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 standard.

The MACSI device also handles frames larger than the 4500 byte default maximum frame size as specified in the standard.

2.8 MULTI-FRAME STREAMING INTERFACE

The MACSI device provides an interface to support multiframe streaming. Multiple frames can be transmitted after a token is captured within the limits of the token timer thresholds.

2.9 BEACON, CLAIM, AND VOID FRAMES GENERATION

For purposes of transient token and ring recovery, no processor intervention is required. The MACSI device automatically generates the appropriate MAC frames.

2.10 SELF TESTING

Since the MACSI device has a full duplex architecture, loopback testing is possible before entering the ring and during normal ring operation.

There are several possible loopback paths:

Internal to the MACSI device

Through the PLAYERadevice(s) using the PLAYER

configuration switch

Through the PLAYERaClock Recovery Module.

2.0 General Features (Continued)

These paths allow error isolation at the device level.

The MACSI device also supports through parity. Even when parity is not used by the system, parity support can be provided across the PHY Interface.

2.11 32-BIT ADDRESS/DATA PATH TO HOST MEMORY

The MACSI device provides a 32-bit wide synchronous data interface, which permits connection to a standard multimaster 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 demultiplexed signals. Maximum burst speed is one 32-bit word per clock, but slower speeds may be accommodated by inserting wait states.

The MACSI device can operate within any combination of cached, non-cached, paged or non-paged memory environments. To provide this capability, all data structures are contained 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.12 MULTI-CHANNEL ARCHITECTURE

The MACSI device provides three Input Channels and two Output Channels, which are designed to operate independently and concurrently. They are separately configured by the user to manage the reception or transmission of a particular kind of frame (for example, synchronous frames only).

2.13 SUPPORT FOR HEADER/INFO SPLITTING

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 between 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 unnecessary copying. In addition, a protocol monitor application may decide to copy only the header portion of each frame.

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 internal address (short or long) are sorted onto Indicate Channel 1.

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-

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.

2.16 STATUS BATCHING SERVICES

The MACSI device provides status for transmitted and received 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 Descriptor (CNF) for one or more Request Descriptors (REQs).

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 deciding 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 Indicator.

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.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.19 CLUSTERED INTERRUPTS

The MACSI device can be operated in a polled or interruptdriven 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 interrupts 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.

These FIFOs support all of the features available in the original 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 larger transmit FIFO.

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.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 multicast addresses. The MACSI device copies all multicast frames and software makes the final determination as to which multicast groups this station belongs.

2.23 BRIDGE STRIPPING INFORMATION

The MACSI device provides an output designed to make it easier to build transparent bridges. Source Address Transparency 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 address, (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).

2.24 LED STATUS CONTROL OUTPUTS

The MACSI device (revision D and later) provides two outputs that give Transmit and Receive status information useful 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 structures (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.25 JTAG BOUNDARY SCAN

The MACSI device supports the JTAG boundary scan standard (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.

The MACSI device uses a full duplex architecture and provides sufficient bandwidth at the ABus for full duplex transmission with support for through parity.

Figure 3-1

shows

the MACSI device architecture.

TL/F/11705– 2

FIGURE 3-1. MACSI Device Block Diagram

3.0 Architectural Description (Continued)

3.1 INTERFACES

3.1.1 PHY Interface

The PHY Interface is a synchronous interface that provides a byte stream to the PLAYER

device (the PHY Request byte stream, PHYÐRequest), and receives a byte stream 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.1.2 ABus Interface

The ABus interface provides the high performance synchronous 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.

3.1.3 Control Bus Interface

The Control Interface implements the interface to the Control Bus which allows the user to initialize, monitor and diagnose 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.

The Control Bus is separated completely from the high performance data path in order to allow independent operation of the processor on the Control Bus. The Control Interface provides synchronization between the asynchronous Control Bus and the synchronous operation of the device.

During operation, the host uses the Control Bus to access the device’s internal registers, and to manage the attention/ notify (interrupt) logic.

3.2 RING ENGINE

The Ring Engine consists of four blocks: Receiver, Transmitter, MAC Parameter RAM, and Counters/Timers as shown in

Figure 3-2.

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 following functions:

Determines the beginning and ending of a Protocol Data Unit (PDU)

Decodes the Frame Control field to determine the PDU type (frame or token)

Compares the received Destination and Source Addresses with the internal addresses

Processes data within the frame

Calculates and checks the Frame Check Sequence at the end of the frame

Checks the Frame Status field

And finally, the Receiver presents the data to the MAC Interface along with the appropriate control signals (MAÐIndicate).

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

3.0 Architectural Description (Continued)

During frame transmission, the Transmitter performs the following functions:

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

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 following functions:

Repeats the received frame and modifies the Frame Status field at the end of the frame as specified by the standard

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

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 addresses. These parameters are initialized via the Control Interface. Both the Receiver and Transmitter Blocks access the RAM.

The Receiver uses these parameters to compare addresses in incoming frames with the individual and group addresses stored in the Parameter RAM.

The Transmitter uses the Parameter RAM for generating the Source Address for all frames (except when Source Address Transparency is enabled) and for the Destination Address 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.

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 increment in response to events detected by the Receiver. The counters are readable via the Control Interface.

The Token Rotation and Token Holding Timers which are used to implement the Timed Token Protocol are contained within the Timer Block.

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 information about MACSI device operations.

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 may not cross a 4k boundary. All Descriptors may be marked as First, Middle, Last, or Only. Thus, multiple Descriptors 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.

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.

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

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

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 Descriptor.Only; frames consisting of multiple parts are described by a single Descriptor.First, zero or more Descriptor.Middles, and a single Descriptor.Last.

Every Output Data Unit part is described by an ODUD. Output Data Unit Descriptors are fetched from memory so that frame parts can be assembled for transmission.

Every Input Data Unit part is described by an Input Data Unit Descriptor (IDUD). Input Data Unit Descriptors are generated on Indicate Channels to describe where the MACSI device wrote each frame part and to report status for the frame.

Request Descriptors (REQs) are written by the user to specify the operational parameters for the MACSI device Request 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 number 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 expected status.

3.0 Architectural Description (Continued)

Confirmation Messages (CNFs) are created by the MACSI device to record the result of a Request operation.

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

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 objects in those queues which are produced by the Host. The Host consumes objects in those queues which are produced by the MACSI.

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 Descriptor (8 bytes). The address in the Queue Pointer is incremented 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 becomes 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.

3.3.3 Storage Allocation

The maximum unit of contiguous storage allocation in external 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 contiguous pages.

3.4 SERVICE ENGINE

The Service Engine, which manages the operation of the MACSI, contains seven basic blocks: Indicate Machine, Request Machine, Status/Space State Machine, Pointer RAM, Limit RAM, and Bus Interface Unit. An internal block diagram 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).

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

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:

Decodes the Frame Control field to determine frame type

Sorts 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

Writes status for the received frames to the Indicate Status Queue

Issues interrupts to the host at host-defined status breakpoints

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:

Reads frames from host memory and assembles them onto Request Channels

Prioritizes active requests

Transmits frames to the Ring Engine (MAC)

Optionally writes status for transmitted and returning frames

Issues interrupts to the host on user-defined group boundaries

3.4.3 Status/Space Machine

The Status/Space Machine is used by both the Indicate Machine and the Request Machine.

The Status/Space Machine manages all descriptor Queues and writes status for received and transmitted frames.

3.4.4 Bus Interface Unit

The Bus Interface Unit (BIU) is used by both the Indicate and Request Blocks. It manages the ABus Interface, providing the MACSI device with a 32-bit data path to local or system memory.

The Bus Interface Unit controls the transfer of Data Units and Descriptors between the MACSI device and Host memory via the ABus.

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:

1. Input Data Units (written by MACSI)

2. Input Data Unit Descriptors (written by MACSI)

3. Pool Space Descriptors (read by MACSI)

The two Request (Transmit) Channels each use the following objects:

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)

3.0 Architectural Description

(Continued)

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:

1. Indicate Data Unit writes (highest priority when not transmitting)

2. Output Data Unit fetches (highest priority when transmitting)

3. Request Descriptor and Output Data Unit Descriptor fetches

4. Input Data Unit Descriptor writes

5. Confirmation Message Descriptor writes

6. Next Pool Space Descriptor transfer to Current Pool Space Descriptor (internal operation)

7. Pool Space Descriptor fetches

8. Limit RAM Operations (internal operation)

9. Pointer RAM Operations (lowest priority)

Addresses for Channel accesses are contained in the Pointer RAM Registers.

3.4.5 Pointer RAM

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, Input and Output Data Units, Input and Output Data Unit Descriptors, Request Descriptors, Confirmation Message Descriptors, and Pool Space Descriptors.

The Pointer RAM Block is accessed by clearing the PTOP (Pointer RAM Operation) bit in the Service Attention Register, which causes the transfer of data between the Pointer RAM Register and a mailbox location in memory.

3.4.6 Limit RAM

The Limit RAM Block is used by both the Indicate and Request Machines. It contains data values that define the limits of the ten Queues maintained by the MACSI device.

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.

4.0 FDDI MAC Facilities

4.1 SYMBOL SET

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.

Additional information regarding the symbol set can be found in the ANSI X3T9.5 PHY standard.

The Ring Engine expects that the Starting Delimiter will always 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 symbol pairs.

The symbol pairs conveyed at the PHY Interface are shown in Table 4-1.

4.2 PROTOCOL DATA UNITS

The Ring Engine recognizes and generates Tokens and Frames.

The Token is used to control access to the ring. Only the station that has captured the token has the right to transmit new information. The format of a token is shown in

Figure

4-1.

TABLE 4-1. Symbol Pair Set

Type Symbols

Starting Delimiter JK or IL

Ending Delimiter TT or TR or TS or TI

Frame Status RR or RS or SR or SS

Idle II or nI

Data Pair nn

n represents any data symbol (0 –F).

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

Additional information on the symbol pairs generated and interpreted by the Ring Engine can be found in Section 8.2.1.

TABLE 4-2. Frame Fields

Name Description Size

SFS Start of Frame

Sequence

PA Preamble 8 or more Idle

symbol pairs

SD Starting Delimiter JK symbol pair

FC Frame Control Field 1 data symbol pair

DA Destination Address 2 or 6 symbol pairs

SA Source Address 2 or 6 symbol pairs

INFO Information Field

FCS Frame Check 4 symbol pairs

Sequence

EFS End of Frame

Sequence

ED Ending Delimiter at least 1 T symbol

for Frames;

at least 2 T symbols

for Tokens

FS Frame Status 3 or more R or S

symbols

SFS EFS

PA SD FC ED

FIGURE 4-1. Token Format

Frames are used to pass information between stations. The format of a frame is shown in

Figure 4-2,

with the field defini-

tions in Table 4-2.

SFS Protected by FCS EFS

PA SD FC DA SA INFO FCS ED FS

FIGURE 4-2. Frame Format

4.0 FDDI MAC Facilities (Continued)

4.2.1 Frame Fields

Start of Frame Sequence (SFS)

The Start of Frame Sequence consists of the Preamble (PA) followed by the Starting Delimiter (SD).

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.

The Starting Delimiter is used to indicate the start of a new frame. The Starting Delimiter is the JK Symbol pair.

The Ring Engine expects the Starting Delimiter to be conveyed across the PHÐIndication Interface as a single byte. Similarly, the Ring Engine only generates Starting Delimiters aligned to the byte boundary.

Frame Control (FC)

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 one byte FC field is formatted as shown in

Figure 4-3

CLFFrZZZ

FIGURE 4-3. Frame Control Field

The C (Class) bit specifies the MAC Service Class as Asynchronous (C

0) or Synchronous (Ce1).

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

0) or Long (Le1). A Short Address is a

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

The FF (Format) bits specify the frame types as shown in Table 4-3.

The r (Reserved) bit is currently not specified and should always be transmitted as Zero.

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 Priority, Protocol Class, Status Handling, etc.

TABLE 4-3. Frame Control Format Bits

FC.FF Frame Types

0 0 SMT/MAC

0 1 LLC

1 0 reserved for implementer

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

TABLE 4-4. MAC/SMT Frame Types

CLFF rZZZ Frame Type

1000 0000 Non-restricted Token

1100 0000 Restricted Token

0L00 0000 Void Frame

0L00 0001 to 1110 SMT Frame

0L00 1111 SMT Next Station Addressing Frame

1L00 0001 Other MAC Frame

1L00 0010 MAC Beacon Frame

1L00 0011 MAC Claim Frame

1L00 0100 MAC Purge Frame

1L00 0101 to 1111 Other MAC Frame

Destination Address (DA)

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 determined 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/Universal address is a Group Address.

The DA field can be a Long or Short Address. This is determined 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 Ring Engine maintains a 16-bit Individual Address (My Short Address (MSA)), and a 48-bit Individual Address (My Long Address (MLA)).

On the receive side, if DA.lG is 0 the incoming DA is compared with MLA (if FC.L

1) or MSA (if FC.Le0). If the received DA matches MLA or MSA the frame is intended for this station and the address recognized flag (AÐFlag) is set. 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 AÐFlag is set, the system interface will normally attempt to copy the frame.

On the transmit side, the DA is provided by the system interface 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.

Source Address (SA)

The Source Address (SA) field is used to specify the address 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).

4.0 FDDI MAC Facilities (Continued)

On the receive side, the incoming SA is compared with either 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 having been transmitted by this station and is stripped. The most significant bit of the SA (SA.lG) is not evaluated in the comparison.

On the transmit side, the station’s individual address is transmitted as the SA. Since the SA field is normally used for stripping frames from the ring, the SA stored by the Ring Engine normally replaces the SA from the data stream. The length of the address to be transmitted is determined by the L bit of the FC field. (The FC field is passed in the data stream.) The most significant bit of the SA (SA.IG) is normally transmitted as 0, independent of the value passed through the data stream.

As a transmission option, the SA may also be transmitted transparently from the data stream. When the SA Transparency 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.)

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 option is used without SAT, the transmitted SA is generated by the Ring Engine, as always.)

Information (INFO)

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.

The INFO field contains zero or more bytes.

On the receive side, the INFO field is checked to ensure that it has at least the minimum length for the frame type and contains an even number of symbols, as required by the 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.

On the transmit side, the Ring Engine does not limit the maximum size of the INFO field, but it does insure that frames are transmitted with a valid DA and SA.

Frame Check Sequence (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.

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

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

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 additional trailing control indicators.

For frames repeated by the Ring Engine, the E, A and C Indicators are handled as specified in the Standard. Additional trailing control indicators are repeated unmodified provided they are properly aligned. See Section 5.5 for details on Frame Status Processing.

4.2.2 Token Formats

The Ring Engine supports non-restricted and restricted Tokens. See

Figure 4-4

and

Figure 4-5

SFS FC EFS

SD 80 ED

FIGURE 4-4. Non-Restricted Token Format

SFS FC ED

SD C0 ED

FIGURE 4-5. Restricted Token Format

Non-restricted

A non-restricted token is used for synchronous and non-restricted asynchronous transmissions. Each time the non-restricted token arrives, a station is permitted to transmit one or more frames in accordance with its synchronous bandwidth allocation regardless of the status of the token (late or early).

Asynchronous transmissions occur only if the token is early (usable token) and the Token Holding Timer has not reached the selected threshold.

Restricted

A restricted token is used for synchronous and restricted asynchronous transmissions only.

A station which initiates the restricted dialogue captures a non-restricted token and releases a restricted token. Stations that participate in the restricted dialogue are allowed to capture the restricted token. A station ends the restricted dialogue by capturing the restricted token and releasing a non-restricted token.

4.2.3 Frame Formats

The Ring Engine supports all of the frame formats permitted by the FDDl standard. All frame types may be created extemal 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 internally.

4.0 FDDI MAC Facilities (Continued)

Frames Generated Externally

The Ring Engine transmits frames passed to it from the System 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.

TABLE 4-5. Frame Formats

Field

Size

MAÐRequest PHÐRequest

(bytes)

t8;s

40 Idle Pairs

SD 1 JK

FC 1 FC FC

DA 2 or 6 DA DA

SA 2 or 6 SA MSA, MLA, or SA

INFO

0 INFO INFO

FCS 4 if present FCS FCS

ED 1 TR

FS 1 RR

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 delimiter 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 Sequence (4 bytes) is normally transmitted by the Ring Engine. This can be overridden with the FCS transparency capability. With FCS transparency, the FCS is transmitted from the data stream. The End of Frame Sequence is always transmitted by the Ring Engine as TR RR.

Frames Generated by Ring Engine

The Ring Engine generates and detects several frames in order to attain and maintain an operational ring.

Void Frames

Void frames are used during normal operation. The Ring Engine generates two types of void frames: regular Void frames and MyÐVoid frames.

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 unnecessary entry to the Claim state. Stations are not required to copy Void frames. Void frames are transmitted by the Ring Engine in two situations:

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

mitted.

2. After a frame transmission is aborted.

MyÐVoid frames are transmitted by the Ring Engine in three situations:

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

made and the next early token is captured.

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

token is issued.

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

tion and before the token for that service opportunity is issued.

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.

Claim Frames

Claim frames are generated continuously with minimum preamble 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. Otherwise 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, LowerÐClaim, DuplicateÐClaim, and MyÐClaim.

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 enabled, frames with the long address (MLA) are transmitted. Otherwise frames with the short address (MSA) are transmitted.

4.0 FDDI MAC Facilities (Continued)

TABLE 4-6. Void Frames

Type Enable Size SFS FC DA SA FCS EFS

Void ESA Short PA SD 00 null MSA FCS TRRR

Void not ESA Long PA SD 40 null MLA FCS TRRR

MyÐVoid ESA Short PA SD 00 MSA MSA FCS TRRR

MyÐVoid not ESA Long PA SD 40 MLA MLA FCS TRRR

TABLE 4-7. Claim Frames

Type Enable Size SFS FC DA SA INFO FCS EFS

MyÐClaim not ELA Short PA SD 83 MSA MSA TREQ FCS TRRR

MyÐClaim ELA Long PA SD C3 MLA MLA TREQ FCS TRRR

TABLE 4-8. Beacon Frames

Type Enable Size SFS FC DA SA INFO FCS EFS

MyÐBeacon not ELA Short PA SD 82 null MSA TBT FCS TRRR

MyÐBeacon ELA Long PA SD C2 null MLA TBT FCS TRRR

When the Transmit Beacon State is entered from the Transmit Claim State the first byte of the 4 byte TBT field is transmitted as Zero.

Beacon frames that require alternative formats such as Directed Beacons must be generated externally.

The Ring Engine detects reception of valid Beacon frames and distinguishes between Beacon frames transmitted by this MAC (MyÐBeacon) and Beacon frames transmitted by other stations (OtherÐBeacon).

4.3 FRAME COUNTS

To aid in fault isolation and to enhance the management capabilities of a ring, the Ring Engine maintains several frame counts. The Error and lsolated frame counts increment 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 size of the counters has been chosen such that minimal software intervention is required, even under marginal operating conditions.

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.

4.3.2 Error lsolated Count (ElCT)

The Error lsolated Count is described in the FDDl MAC standard, and is the count of error frames detected by this station and no previous station. It increments when:

1. An FCS error is detected and the received Error Indicator (Er) is not equal to S.

2. A frame of invalid length (i.e., off boundary T) is received and Er is not equal to S.

3. Er is not R or S.

4.3.3 Lost Frame Count (LFCT)

The Lost Frame Count is described in the FDDl MAC standard, and is the count of all instances where a format error is detected in a frame or token such that the credibility of reception is placed in doubt. The Lost Frame Count is incremented when any symbol other than data or Idle symbols is received between the Starting and Ending Delimiters of a frame (this includes parity errors).

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 addressed to and copied by this station. The count is incremented when an internal or external match occurs (when Option.EMlND enabled) on the Destination Address, no errors were detected in the frame and the frame was successfully 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.

4.0 FDDI MAC Facilities (Continued)

4.3.5 Frames Not Copied Count (FNCT)

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 occurs, no errors were detected in the frame, and the frame 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.3.6 Frames Transmitted Count (FTCT)

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 included in the count.

4.4 TIMERS

4.4.1 Token Rotation Timer (TRT)

The Token Rotation Timer (TRT) times token rotations from arrival to arrival. TRT is used to control ring scheduling during normal operation and to detect and recover from serious ring error situations.

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.

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 captured token is (still) usable for asynchronous transmission. A token is usable for asynchronous traffic if THT has not reached the selected threshold. Two asynchronous thresholds are supported; one that is fixed at the Negotiated Target Token Rotation Time (TNEG), and one that is programmable at one of 16 Asynchronous Priority Thresholds. Requests to transmit frames at one of the priority thresholds are serviced when the Token Holding Timer (THT) has not reached the selected threshold.

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

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 situations the ring will recover very quickly and late count will be of marginal utility. However, in the case of serious ring er-

rors, it is helpful for SMT to know how long it has been since the ring became non-operational (with TMAX resolution) 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 were not provided, 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 implementation may be able to alleviate this additional overhead.

4.4.4 Valid Transmission Timer (TVX)

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 Value of TVX is also used as the Duplicate MAC frame detection delay, DMÐMIN. This is the time after which a MAC frame will be suspected as being generated by another station with this station’s address when the ring is nonoperational.

4.4.5 Token Received Count (TKCT)

The Token Received Count is incremented every time a valid 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 inversely related to the network load.

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

Multiple classes of service can be accommodated by setting different target token rotation times for each class of service.

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 supported when the ring is operational.

4.5.1 Synchronous Service Class

The Synchronous Service Class may be used to guarantee a maximum response time (2 times TTRT), minimum bandwidth, or both.

4.0 FDDI MAC Facilities (Continued)

Each time the token arrives, a station is permitted to transmit 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).

Since the Ring Engine does not provide a mechanism for monitoring a station’s synchronous bandwidth utilization, the user must insure that no synchronous request requires more than the allocated bandwidth.

To help ensure that synchronous bandwidth is properly allocated 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 bandwidth allocation.

4.5.2 Non-Restricted Asynchronous Service Class

The Non-Restricted Asynchronous service class is typically used with interactive and background traffic. Non-Restricted Asynchronous requests are serviced only if the token is early and the Token Holding Timer has not reached the selected threshold.

Asynchronous service is available at two priority thresholds, the Negotiated Target Token Rotation Time plus one programmable threshold. Management software may use the priority thresholds to discriminate additional classes of traffic 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 software is only concerned with the priority level of a request.

As an option, Asynchronous Requests may be serviced with THT disabled. This is useful when it is necessary to guarantee that a multi-frame request will be serviced on a single token opportunity. Because of the possibility of causing late tokens, this capability should be used with caution, and should only be allowed when absolutely necessary.

4.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) asynchronous bandwidth.

The Restricted Token service may also be used for operations requiring instantaneous allocation of the remaining synchronous bandwidth when Restricted Requests are serviced with THT disabled. This is useful when it is necessary to guarantee atomicity, i.e., that a multi-frame request will be serviced on a single token opportunity.

A Restricted dialogue consists of three phases:

1. Initiation of a Restricted dialogue:

Capture a Non-restricted Token

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

Transmit zero or more frames to continue the Restricted dialogue

Issue a Restricted Token to allow other stations in the dialogue to transmit frames

3. Termination of a Restricted dialogue:

Capture a Restricted Token

Transmit zero or more frames to continue the Restricted dialogue

Issue a Non-Restricted Token to return to the Non-Restricted service class

Initiation of a Restricted dialogue will prevent all Non-Restricted Asynchronous traffic throughout the ring for the duration of the dialogue, but will not affect Synchronous traffic.

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 interrupt. In addition, a request to begin a Restricted dialogue will only be honored if both the previous transmitted Token and the current received Token were Non-Restricted tokens. This is to ensure that the upper bound on the presence of a Restricted dialogue in the ring is limited to a single dialogue.

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 enabled by management software. Since the Claim process results in the generation of a Non-restricted Token, this prevents stations from initiating another restricted dialogue without the intervention of management software.

4.5.4 Immediate Service Class

The Immediate Service Class facilitates several non-standard 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 nonoperational. 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 to remain in the Claim State when receiving MyÐClaim.

On the completion of an Immediate request, a Token (Nonrestricted or Restricted) may optionally be issued. Immediate requests may also be used in non-standard applications such as a full duplex point to point link.

5.0 Functional Description (Ring Engine)

5.1 TOKEN HANDLING

5.1.1 Token Timing Logic

The FDDI Ring operates based on the Timed Token Rotation 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.

Stations negotiate for TTRT based on their TREQ that is assigned to them upon initialization.

Each station keeps track of the token arrival by setting the Token Rotation Timer (TRT) to the TTRT value. If the token

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 received within twice TTRT (TRT expires and LateÐFlag is set), there is a potential problem in the ring and the recovery process is invoked.

Furthermore, the Token Holding Timer (THT) is used to limit the amount of ring bandwidth used by a station for asynchronous traffic once the token is captured. Asynchronous traffic is prioritized based on the LateÐFlag which denotes a threshold at TTRT and an additional Asynchronous Priority Threshold (THSH). The Asynchronous Threshold comparison (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.

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.

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 continues to count. When TRT expires and LateÐFlag is not set, LateÐFlag is set and TRT is loaded with TNEG.

THT follows the value of TRT until a token is captured. When a token is captured, TRT may be reloaded with TNEG while THT continues to count from its previous value (THT does not wrap around). THT increments when enabled. THT is disabled during synchronous transmission and a special class of asynchronous transmission. THT is used to determine if the token is usable for asynchronous requests. For these purposes, the token is considered late one byte before it is actually late (to promote interoperability with less careful implementations).

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

Required condition becomes true one byte time after TRT expires (to promote interoperability with less careful implementations). When TRT expires and the ring is not operational, TRT is loaded with TMAX. TRT is also loaded with TMAX on a MAC Reset.

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

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.

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 complete successfully, TRT will expire and the Beacon Process is invoked.

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 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 process, 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 Engine, the Ring Engine awaits an appropriate Service Opportunity in which to service the Request. Frames associated with the Request are transmitted during the Service Opportunity. The definition of a Service Opportunity is different depending on the operational state of the ring.

TL/F/11705– 7

FIGURE 5-1. Token Timing Logic

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 requested service class (sync, async, async priority, immediate) and the type of token to capture (restricted, non-restricted, any, none).

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 Beacon frame is not ready to be transmitted, the Ring Engine will transmit Claim or Beacon frames using the same internal data used for normal Claim and Beacon processing.

5.2.1 Service Opportunity while Ring Operational

Beginning of Service Opportunity

Table 5-1 shows the conditions that must be true when a valid token is received in order to begin a service opportunity when the ring is operational.

In addition to the criteria mentioned above, additional criteria apply to the servicing of Synchronous and Restricted Requests.

Synchronous Requests are not serviced if RELR.BCNR

1 (see Section 4.5.1).

Restricted requests are not serviced when RELR.MACR

1. (see Section 4.5.3).

Restricted Dialogues may only begin when a non-restricted token has been received and transmitted (see Section

4.5.3).

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 transmitted when:

1. It is no longer necessary to hold the token

All frames of all active requests have been transmitted

2. The token became unusable while servicing a request

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:

A MAC Reset

Reception of a valid MAC frame

TRT expiration (TRT was reset when the token was captured)

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 completed (the last frame of that request was transmitted). Otherwise, a token of the capture token class is issued.

TABLE 5-1. Beginning of Service Opportunity

Requested

Received

Service

Token

Criteria Token

Class

Capture

Class

Asynchronous non-restricted THTlTHSH non-restricted Priority LateÐFlag

RingÐOp

Asynchronous non-restricted LateÐFlage0 non-restricted

RingÐOp

Asynchronous restricted LateÐFlage0 restricted

RingÐOp

Synchronous any RingÐOpe1 any

When servicing multiple requests on a single service opportunity, the issue token class of the previous class becomes the capture class for the next request for purposes of determining usability.

The type of token issued depends on the service class and the type of token captured as shown in Table 5-2.

5.2.2 Service Opportunity While Ring Not Operational

While the ring is not operational, a service opportunity occurs if an immediate transmission is requested from the transmitter Data, Claim or Beacon state, and the transmitter is in the appropriate state.

The service opportunity continues until any one of the following conditions exist:

1. No (additional) frames are to be sent

2. Time TMAX elapses on this request

3. The transmitter exits the requested state

4. The ring becomes operational while servicing an immediate request

5.2.3 Frame Transmission

Frames associated with the current request may be transmitted at any time during a Service Opportunity. In many applications, data is ready to be transmitted when the Request is presented to the interface. Soon after the Service Opportunity begins, frame transmission begins. In other applications, in order to minimize the effects of ring latency, it is desirable to capture the token when no data is ready to be transmitted. This capability results in wasted ring bandwidth and should be used judiciously.

During transmission, a byte stream is passed from the System 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.

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.

Several errors can occur during a transmission. A transmission may be terminated unsuccessfully because of external buffering or interface parity errors, internal Ring Engine errors, a MAC reset, or reception of a MAC frame. When a

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.

5.3 REQUEST SERVICE PARAMETERS

5.3.1 Request Service Class

The Requested Service corresponds to the Request Service Class and the Token Class parameters of the (SMÐ)MAÐDATA.request and (SMÐ)MAÐToken.request primitives as specified in the Standard.

TABLE 5-2. Token Transmission Type

Service Class

Token Token

Captured Issued

Non-restricted Non-restricted Non-restricted

Begin Restricted Non-restricted Restricted

Continue Restricted Restricted Restricted

End Restricted Restricted Non-restricted

Immediate None None

Immediate Non-restricted None Non-restricted

Immediate Restricted None 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.

Requests are serviced on a Service Opportunity meeting the requested criteria.

A Token Capture Class of non-rstr indicates that the Transmitter Token Class must be Non-Restricted to begin servicing the request. A Token Capture Class of rstr indicates that the Transmitter Token Class must be Restricted to begin servicing the Request. A Token Issue Class of non-rstr means that the Transmitter Token Class will be Non-restricted upon completion of the request. A Token Issue Class of rstr means that the Transmitter Token Class will be Restricted upon completion of the request.

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 interface. When Source Address transparency is not used, the SA from the internal parameter RAM is substituted for the SA bytes in the request stream, which must still be present. Since the FCS is appended to the frame, when FCS transparency is not used, no FCS bytes are present in the request stream.

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

place of the MSA or MLA. The SAT option can be invoked on a Request Object via the Request Configuration parameters of the System Interface.

When the SA Transparency option is selected, it is necessary to rely on an alternate stripping mechanism since stripping based on the returning SA only guarantees that frames with MSA or MLA will be stripped. Either the Void Stripping option (described below) may be invoked, or external hardware that forces stripping using the EM (External MÐFlag) signal is required.

The MSB of the SA is not controlled by this option. It is normally forced to Zero. It can be controlled using the Source Address MSB Transparency option described below.

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.

SA Transparency also overrides the Long and Short Addressing enables. For example, if Long Addressing is not enabled, it is still possible to transmit frames with Long Addresses. 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.

Source Address Most Significant Bit Transparency

With the Source Address MSB Transparency option, the MSB of the SA is sourced from the data stream, as opposed to being transmitted as Zero. The SA MSB Transparency option is selected through the Request Channel Configuration Registers in the Service Engine.

Unless the Source Address Transparency option is also selected, 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 algorithms (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).

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)

A Token is received

An OtherÐVoid is received

A MAC frame other than MyÐClaim is received

A MAC Reset occurs

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 assertion of the STRIP signal at the beginning of a frame transmission.

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.

FCS Transparency

Normally, the Ring Engine generates and transmits the FCS. When the Frame Check Sequence Transparency op-

tion is selected, the Ring Engine device does not append the FCS to the end of the Information field. This option is selected by asserting signal FCST.

The receiving stations treat the last four bytes of the data stream as the FCS.

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

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.

5.0 Functional Description (Ring Engine) (Continued)

TABLE 5-3. Request Service Classes

RQRCLS Name Class THT

Token Token

Notes

Capture Issue

0000 None None

0001 ApriÐ1 Async enabled non-rstr non-rstr

THSH1

0010 Reserved Reserved

0011 Reserved Reserved

0100 Sync Sync disabled any captured 1

0101 Imm Immediate disabled none none 4

0110 ImmN Immediate disabled none non-rstr 4

0111 ImmR Immediate disabled none rstr 4

1000 Async Async enabled non-rstr non-rstr

1001 Rbeg Restricted enabled non-rstr rstr 2, 3

1010 Rend Restricted enabled rstr non-rstr 2

1011 Rcnt Restricted enabled rstr rstr 2

1100 AsynD Async disabled non-rstr non-rstr

1101 RbeginD Restricted disabled non-rstr rstr 2, 3

1110 RendD Restricted disabled rstr non-rstr 2

1111 RcntD Restricted disabled rstr rstr 2

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

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

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 allowable length (4500 bytes).

TABLE 5-4. Valid Frame Length

Frame

Types

Short Long

Notes

Address Address

(minimum number

of bytes)

Void 9 17

MAC 13 21 including a 4 byte

INFO field

non-MAC 9 17 including a 0 byte

INFO field

Also on the Transmit side, the L bit in the FC field is checked against the ESA and ELA bits in the Option Regis-

ter (if the SA Transparency option is not selected) to insure that a frame of that address length can be transmitted. If the selected address length is not enabled, the frame is aborted at the beginning of the SA field. If SA Transparency is selected, 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.

5.5 FRAME STATUS PROCESSING

Each frame contains three or more Control Indicators. The FDDI Standard specifies three: the E, A, and C Indicators.

When a frame is transmitted, the Control Indicators are transmitted as R (Reset) symbols. If an error is detected by a station that receives the frame, the E Indicator is changed to an S (Set) symbol. If a station recognizes the DA of a frame as its own address (Individual, Group, or Broadcast), the A Indicator is changed to an S symbol. If that station then copies the frame, the C Indicator is changed to an S symbol.

The received value of the Control Indicators for every frame received is reported at the MAC Indicate Interface on signals MID(7 –0). On a frame transmitted by this station, the returning Control Indicators give the transmission status.

5.0 Functional Description (Ring Engine) (Continued)

The Ending Delimiter followed by the Frame Status Indicators should begin and end on byte boundaries. Control Indicators are repeated until the first non R, S, or T symbol is received.

The processing of properly aligned E, A and C indicators by the Ring Engine is detailed in Table 5-5. Given the shown received Control Indicator values and the settings of the internal flags, the noted control indicator values will be transmitted.

5.5.1 Odd Symbols Handling

When the first T symbol of a frame is received as the second symbol of a symbol pair (the T symbol is received offboundary), 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.

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 address to the next addressed station. The current SMT protocol requires stations to periodically (at least once every 30 seconds) transmit an NSA frame. Since the Broadcast address 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.

TABLE 5-5. Control Indicator Processing

Received Indicators Flags Transmitted Indicators

E A C E A Copy N E A C

RRR0 0 X XRRR

RRR0 1 0 XRSR

RRR0 1 1 XRSS

XRR1XXXSRR

RRS00 X XRRS

RRS01 0 X RSR

RRS01 1 X RSS

XRS1XXXSRS

RSR0X X 1RSR

RSR0X 0 0RSR

RSR01 1 0RSR

RSR00 X XRSS

RSS0 X X XRSS

XSS1XXXSSS

RRT 0 0 X XRRT

RRT 0 1 0 X RSR

RRT 0 1 1 X RSS

XRT1XXXSRT

RST01 1 0RS S

RST00 X XRST

RST01 0 XRSR

RST01 1 1RSR

XST1XXXSST

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

AÐ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.

5.0 Functional Description (Ring Engine) (Continued)

Additionally, only the station that sets the A Indicator is permitted 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.

5.7 MAC FRAME PROCESSING

Upon the reception of a valid MAC frame (Claim, Beacon, or Other), the RingÐOperational flag is reset and the Ring Engine 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).

5.7.1 Claim Token Process

Receive

When a Claim frame is received, its Frame Type is reported (Claim frame) along with the type of Claim frame.

There are three types of Claim frames: MyÐClaim, Higher

Claim, and LowerÐClaim.

AMyÐClaim frame is a Claim frame with a Source Address that matches this station address and the TÐBidÐRc in the INFO field is equal to this station’s TREQ.

A HigherÐClaim frame is a Claim frame with a Source Address that does not match this station address and the TÐBidÐRc in the INFO field is greater than this station’s TREQ.

A LowerÐClaim frame is a Claim frame with a Source Address that does not match this station address and the TÐBidÐRc in the INFO field is smaller than this station’s TREQ.

Transmit

Claim frames are transmitted continuously while in the TxÐClaim State.

Claim frames are generated by the Ring Engine unless an Immediate Claim Request is present at the MAC Request Interface. Even if an Immediate Claim Request is present at the MAC Request Interface, at least one Claim frame must be generated by the Ring Engine before Claim frames from the Interface are transmitted.

For internally generated Claim frames, the Information field is transmitted as the 4-byte Requested Target Token Rotation Time.

The Information field of a Claim frame consists of this station’s Requested Target Token Rotation Time. In the Ring Engine implementation, TREQ is programmable with a

20.48 ms resolution and a maximum value of 1.34 seconds.

Claim Protocol

Entry to the TxÐClaim state occurs whenever token recovery is required. The Recovery Required condition occurs when:

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 the Inhibit Recovery Required option (bit Option.IRR).

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

1) with an SMÐMAÐControl.request(Claim) which is accomplished by setting Function.CLM to 1.

While in the TxÐClaim state:

Claim frames are transmitted continuously

If a HigherÐClaim frame is received, the station exits the Claim state and enters the IDLE state. In this state it then repeats additional HigherÐClaim frames.

If a LowerÐClaim frame is received, this station continues to send its own Claim frames and remains in the Claim state.

Eventually, if a logical ring exists, the station with the shortest TREQ on the ring should receive its own Claim frames, the MyÐClaim frame. This completes the Claim Token Process. This one station then earns the right to issue a token to establish an Operational ring.

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

5.7.2 Beacon Process

Receive

When a Beacon frame is received, its Frame Type is reported (Beacon frame) along with the type of Beacon frame.

There are two types of Beacon frames: MyÐBeacon and OtherÐBeacon.

A Beacon frame is considered a MyÐBeacon if its Source Address matches this station’s address (long or short).

A Beacon frame is marked as OtherÐBeacon if its Source Address does not match this station’s address.

Transmit

Beacon frames are transmitted continuously while in the TxÐBeacon state.

Beacon frames are generated by the Ring Engine, unless an Immediate Beacon Request is present at the MAC Request Interface. Even if an Immediate Beacon Request is present at the MAC Request Interface, at least one Beacon frame must be generated by the Ring Engine before Beacon frames from the Interface are transmitted.

For internally generated Beacon frames, the Ring Engine uses the TBT in the Information field.

Beacon Protocol

Entry to the TxÐBeacon state occurs under two conditions:

A failed Claim Process (TRT expires during the Claim process)

An SMÐMAÐControl.request(Beacon) which is accomplished by setting Function.BCN to 1).

Beacon frames are then transmitted until the Beacon process 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.

IfaMyÐBeacon frame is received, the station has received back its own Beacon frame; thus successfully completing the Beacon process. The station then enters the Claim Process.

5.0 Functional Description (Ring Engine) (Continued)

5.7.3 Handling Reserved MAC Frames

A Reserved MAC frame is any MAC frame aside from Beacon and Claim frames. Tokens are not considered MAC frames even though their Format bit (FC.FF) is the same as for MAC frames.

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.

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.

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.

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 copying Claim and Beacon frames when new information is present.

The Same INFO signal is asserted when:

1. The current and previous non-Void frames were both MAC frames (not necessarily the same FC value).

2. The first four bytes of the INFO field of the current frame is the same as the first four bytes of the INFO field of the previous non-Void frame.

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

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 Error Isolation and Recovery. Immediate requests are also useful in full duplex applications. Immediate requests are serviced only when the station’s RingÐOperational flag is 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 (RingÐOperational flag is set), the request will be serviced when the Ring becomes non-operational. The Ring becomes non-operational as a result of a MAC Reset (Function.MCRST is set to One) or any of the conditions causing the Reset or Recovery Actions to be performed.

In addition to servicing an Immediate request from the Tx

Data State, it is also possible to service Immediate requests from the TxÐClaim or TxÐBeacon State. When transmitting from the Claim or Beacon state, in addition to requesting an Immediate Transmission Service Class, the RQCLM or RQBCN signals must be asserted to indicate an Immediate 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 One.

While in the TxÐClaim or TxÐBeacon state, the Ring Engine 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 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.

While an Immediate request is being serviced (from any state), if bit IRPT of the Option Register is set to One (Inhibit Repeat option), all received frames (except LowerÐClaim and MyÐBeacon frames) are ignored and the Immediate request continues. LowerÐClaim and MyÐBeacon frames can also be ignored by setting bit IRR of the Option Register.

5.10 FULL DUPLEX OPERATION

The Ring Engine supports full duplex operation by

1. Suspending the Token Management and Token Recovery protocols (set Option.IRR).

2. Inhibiting the repetition of all frames and tokens (set Option.IRPT).

3. Using the Immediate Service Class.

Frames of any size may be transmitted or received, subject to the minimum length specified in Section 5.4.

5.11 PARITY PROCESSING

Through Parity is supported on the internal data paths between 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 Request and PHY Indication interface to the PHY Request interface or from the PHY Indication interface to the MAC Indication interface). Parity errors are isolated and resolved.

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.

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.

5.0 Functional Description (Ring Engine)

(Continued)

On the PHY Request interface, parity is generated for internally 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 generated for PRP. This allows through parity support at the PHY interface even if parity is not used at the MAC interface. This is very desirable since every byte of data that traverses the ring travels across the PHY Interface which is actually part of the ring.

Through parity is not supported in the Control Interface Registers and the Parameter RAM. Parity is generated and stripped at the Control Interface.

Handling Parity Errors

Parity errors are reported in the Exception Status Register when parity on that interface is enabled.

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.

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 transmitted to reset every station’s TVX timer. A parity error (when enabled) causes ESR.MPE to be set.

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.

5.12 HANDLING INTERNAL ERRORS

Errors internal to the Ring Engine cause a MAC Reset. This includes detecting illegal states in the state machines. Internal 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 registers continue to be updated as always.

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 Indicate Machine and the Request Machine. These blocks share the Bus Interface Unit, Status/Space Machine, Pointer RAM, and Limit RAM blocks.

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 between the FDDI device and host memory.

6.1.1 Indicate Machine

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 provided by the Ring Engine Receive State Machine on the MAC Indicate Interface to make this decision.

6.1.2 Request Machine

On the Transmit side (to the ring) the Request Machine prepares one or more frames from host memory for transmission to the Ring Engine. The Request Machine provides all the control signals to drive the Ring Engine Request Interface.

6.2 OPERATION

6.2.1 Indicate Operation

The Indicate Block accepts data from the Ring Engine as a byte stream.

Upon receiving the data, the Indicate Block performs the following functions:

Decodes the Frame Control field to determine the frame type

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

Writes status for the received frames to the Indicate Status Queue

Issues interrupts to the host on host-defined status breakpoints

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), Restricted Token, Unrestricted Token, Reserved, Station Management (SMT), SMT Next Station Addressing, MAC Beacon, MAC Claim, Other MAC, and Implementer.

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

The Synchronous/Asynchronous Sort Mode is intended for use in end-stations or applications using synchronous transmission.

6.0 Functional Description (Service Engine) (Continued)

With High-priority/Low-priority sorting, high-priority asynchronous frames are sorted onto Indicate Channel 1 and 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 asynchronous transmission. Synchronous frames are sorted to Indicate Channel 1 in this mode.

With External/Internal sorting, frames matching the internal address (Individual or Group addresses in the MACSI device) are sorted onto Indicate Channel 1 and frames matching 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 Section 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.

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 userdefined) and the remaining portions of the frame (Info). Indicate Channel 1 copies the initial bytes up until the host-defined 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 processing applications.

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.

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

Byte 0 Byte 3

Bit 31 Bit 0Big Endian Indicate Data Unit Format

FC FC FC FC

DA0 DA1 SA0 SA1

Byte 3 Byte 0

Bit 0 Bit 31Little Endian Indicate Data Unit Format

FC FC FC FC

SA1 SA0 DA1 DA0

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 information about the IDU, its size (byte count), and its location 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 boundary, 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 Indicate Channel, up to the host-defined queue limit.

The MACSI device has two modes for storing IDUs into Pool Space Pages. In the first mode, the MACSI device will assemble 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 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 Indicate 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 Channel’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.

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.

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 Breakpoint bit in the Indicate Notify Register.

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 detected, the Error (ERR) bit in the State Attention Register is set. The host must reset the INSTOP Attention bit to restart processing.

When parity checking is enabled and a parity error is detected 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.

A frame which is stripped after the fourth byte of the Information 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.

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 assembling frames of the specified service class, Frame Control (FC) and expected status for transmission to the Ring Engine. Request and ODUD Descriptors are checked for consistency and the Request Class is checked for compatibility with the current ring state. When an inconsistency or incompatibility is detected, the request is aborted.

When a consistency failure occurs, the Request is terminated 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

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 Descriptor.First or Descriptor.Only.

Requests are processed on both Request Channels simultaneously. Their interaction is determined by their priorities (Request Channel 0 has higher priority than Request Channel 1) and the Hold and Preempt/Prestage bits in the Request Channel’s Request Configuration Register. An active Request Channel 0 is always serviced first, and may be programmed to preempt Request Channel 1, such that uncommitted Request Channel 1’s data already in the request FIFO will be purged and then refetched after servicing Request Channel 0. When prestaging is enabled, the next frame is staged before the token arrives. Prestaging is always enabled for Request Channel 0, and is a programmable option on Request Channel 1. The MACSI device will process at most one Request per Channel per Service Opportunity.

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 disabled 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 threshold 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 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 concurrently fetches the first ODUD. This mode is useful for systems which need tight control of the Token capture timing (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 Token while filling the FIFO). Therefore, it should be enabled only in those systems where the feature is specifically required.

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 transmission 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 loading the ODUs of the next frame into the FIFO. This continues (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 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 Register and the CNF Queue Limit Register).

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 confirmation object consisting of one or more CNF Descriptors. The type of confirmation is specified by the host in the Confirmation Class field of the REQ Descriptor.

The MACSI device can be programmed to generate CNF Descriptors at the end of the Request object (End Confirmation), or at the end of each token opportunity (Intermediate Confirmation), as selected in the E and I bits of the Confirmation Class Field of the REQ Descriptor. A CNF Descriptor is always written when an exception or error occurs (regardless 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).

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 selected, confirmation is written only if an exception or error occurs.

For Full Confirmation, a matching frame must meet the following 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 specified in the FCT bit of the Request Configuration Register).

3. The frame is MyÐSA (MFLAG or both SAT & EM asserted).

4. The frame status indicators match the values in the Expected 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 frames are ignored by the MACSI device. The frame count ends when any of the following conditions occur:

1. All frames have been transmitted, and the transmitted and confirmed frame counts are equal.

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

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.

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

Request errors and exceptions are reported in the State Attention Register, Request Attention Register, and the Confirmation Message Descriptor. When an exception or error occurs, the Request Machine generates a CNF and ends the Request. The Unserviceable Request (USR) attention is set to block subsequent Requests once one becomes unserviceable.

6.2.3 State Machines

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

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 regarding address matches. Typical applications for this interface include address matching for Bridge and Router devices. 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 timing information to the Sytem Interface. ECOPY and EM provide status to the System Interface on external Destination and Source address matches respectively (most applications use ECOPY only). The Ring Engine uses EA and EM for setting the A Indicator and frame stripping.

For the purposes of external matching, it is recommended that the frame data be viewed at the PLAYER

/MACSI

Receive interface, (PID

7:0l, PIP, PIC). In addition it is recommended that the user design the circuit to detect the JK symbol at the MACSI/PLAYER

interface to start ad-

dress matching.

To instruct the MACSI device to copy a frame, the proper use of the ECIP, ECOPY, and EM pins is as follows. External address matching circuitry must assert ECIP some time from the arrival of the start delimiter (JK) to the 6th byte of the INFO field (as measured at the PLAYER

/MACSI interface). Otherwise, the MACSI device assumes that no external address comparison is taking place. ECIP must be negated for at least one cycle to complete the external comparison. 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.

+ 122 hidden pages