MC92500

MC92500 MOTOROLA | Alldatasheet

Document overview

• Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
• PDF pages: 42

Technical content

Ó MOTOROLA, INC. 1997 MOTOROLA SEMICONDUCTOR TECHNICAL DATA Order this document by MC92500/D REV 1.1 TM ATM Cell Processor The ATM Cell Processor (MC92500) is a peripheral device composed of dedicated high performance Ingress and Egress Cell Processors combined with UTOPIA Compliant PHY and Switch Interface ports (see Figure 1). MC92500 Features

• Full duplex operation at SONET STS-3c, SONET STS-1, DS3 PLCP, or any physical link running up to 155 Mbit/sec
• Implements ATM Layer functions for broadband ISDN according to ITU recommendations and ATM forum UNI specification
• Performs internal VPI and VCI address compression (with an option for external compression) for up to 64K VCs
• Supports up to 16 physical links using dedicated Ingress/Egress MultiPhy control signals
• Each physical link can be configured as either a UNI or NNI port
• Supports multicast, multiport address translation
• Maintains both virtual connection and physical link counters on both Ingress and Egress cell flows for detailed billing and diagnostics
• Provides a flexible 32 bit external memory port for context management
• Automated AIS, RDI, CC and Loopback functions with Performance Monitoring Block Test on up to 64 Bidirectional connections
• Programmable 32 bit microprocessor interface supporting either big- or little-endian bus formats
• Per-connection leaky-bucket based UPC or NPC design with up to four buckets per connection allows any combination of CLP-aware peak, average, and burst-length policing with programmable tag/drop action per policer
• Implements separate rate controlled cell insertion and priority based cell extraction queues accessible from all cell flows
• Supports a programmable number of additional switch overhead parameters allowing adaptation to any switch routing header format

Figure 1. Representative Block Diagram

Ordering Information

256 GTBGA

This document contains information on a new product. Specifications and information herein are subject to change without notice. ZQ SUFFIX GTBGA CASE 5203

1. ATM NETWORK 2. FUNCTIONAL DESCRIPTION

2.4.10 Forward Monitoring Cell Generation(FMC) 9

1. REGISTERS DESCRIPTION 4. EXTERNAL MEMORY DESCRIPTION 5. SIGNAL DESCRIPTION 6. INGRESS DATA PATH OPERATION 7. EGRESS DATA PATH OPERATION 8. SYSTEM OPERATION 9. ELECTRICAL CHARACTERISTICS 10. PACKAGE INFORMATION

1.1 ATM Network Description

level and are independent of the physical medium. Figure 2. MC92500 in an ATM Network Application

1.2 ATM Network Applications

layer cell processing and routing. vice accessed via the same external memory bus. ble for initializing and maintaining the external memory. Figure 3. Typical MC92500 Line Card Application

1. FUNCTIONAL DESCRIPTION

2.2 MC92500 Functional Description

• Implements ATM Layer functions for Broadband ISDN according to CCITT recommendations and ATM forum user network interface specifications
• Provides a throughput capacity of up to 155 Mbit/ sec in each direction
• Processes ATM cells from a SONET STS-3c, SONET STS-1, DS3 PLCP, or any other physical link running at up to 155 Mbit/sec
• Optionally supports up to 16 physical links
• Optionally configured as a User Network Interface (UNI) or Network Node Interface (NNI) on a per-link basis
• Operates in conjunction with an external memory (up to 16 MB) to provide context management for up to 64K Virtual Connections
• Provides explicit bank select signals to support up to four banks of external memory
• Provides per-connection cell counters with the abil- ity to maintain multiple copies of the counter tables and dynamically switch between them
• Provides per-link cell counters in both directions
• Provides per-connection Usage Parameter Control (UPC) or Network Parameter Control (NPC) using a leaky bucket design with up to four buckets per connection
• Provides support for Operation and Maintenance (OAM) Continuity Check function for all connec- tions
• Supports Virtual Path (VP) and Virtual Channel (VC) level Alarm Surveillance on all connections using an internal scan process to generate and insert OAM cells
• Supports OAM Fault Management Loopback test on all connections
• Supports bidirectional OAM Performance Monitor- ing on up to 64 connections
• Provides a slave microprocessor interface includ- ing a 32-bit data bus
• Provides byte-swapping on cell payloads to and from the microprocessor bus in order to support both big-endian and little-endian buses
• Supports cell insertion into the cell streams using direct access registers which may be written by the microprocessor or by a DMA device
• Supports copying cells from the cell streams using direct access registers which may be read by the microprocessor or by a DMA device
• Supports multicast operation

2.1 System Functional Description

A serial transmission link operating at up to 155.52Mbit/ sec (PHY) is coupled to the MC92500 via a byte-based interface. The transmission link timing is adapted to the MC92500 and switch timing by means of internal FIFO cell buffers. A common clock is used to supply both the PHY-IF and MC92500. The host microprocessor initializes and provides real- time control of the data-flow chips (PHY-IF and MC92500) using slave accesses. The MC92500 operates in conjunction with an external connection memory, which provides one context entry for each active connection. The entry consists of two types of context parameters: static and dynamic. The static parameters are loaded into the context memory when the VC is established, and are valid for the dura- tion of that connection. Included in the static parame- ters are traffic descriptors, OAM flags and parameters used by the ATM switch. The dynamic context parame- ters, which include cell counters, UPC/NPC fields and OAM parameters, may be modified as cells belonging to that particular connection are processed by the MC92500. The microprocessor also accesses the ex- ternal memory through the MC92500 from time to time to collect traffic statistics and to update the OAM pa- rameters. During normal cell processing, the MC92500 has exclusive access to the external memory. The con- text entries for the cells being processed are read and the updated dynamic parameters are written back. The MC92500 is responsible for the coherency of the exter- nal memory during this time. At user-programmable intervals the MC92500 provides the microprocessor with a “maintenance slot”, during which no cell processing is done, and relinquishes the external memory bus. The break in cell processing is made possible by the difference between the MC92500 cell-processing rate and the line rate. The maintenance slot shall be used by the micropro- cessor for one or more of the following tasks:

• Connection setup and tear down
• Statistics collection
• Updating OAM parameters of active connection The microprocessor is responsible for the coherency of the external memory at the end of each maintenance slot.

2.2.1 Ingress Cell Flow

In the Ingress direction, the MC92500 extracts cells from the FIFO in the PHY. Cell discrimination based on pre-defined header field values is performed to recog- nize unassigned and invalid cells. Cell rate decoupling is accomplished by discarding unassigned cells. Unas- signed and invalid cell slots may be used to insert OAM and messaging cells into the Ingress cell flow. For VCCs, the 28-bit VPI/VCI address space (32-bit Link/ VPI/VCI if multiple physical links are supported) needs to be compressed into a 16-bit Ingress Connection Identifier (ICI). The MC92500 provides a choice of two methods for performing VCC address compression to obtain the ICI: a table lookup based on reduced ad- dressing and an external address compression option. For VPCs, the VPI field is used for a lookup into the VP Table to obtain the ICI. The ICI is a pointer used to access the context parameters for the current Ingress cell from the external context memory. Included in these parameters are cell counters, UPC/NPC traffic descriptor, OAM parameters and switch parameters. The UPC/NPC mechanism entails counting the arriving cells and, using a flexible arrangement of traffic en- forcement algorithms, admitting cells that do not violate the traffic characteristics established for that connec- tion. Violating cells are tallied and may optionally be tagged or discarded (removed from the cell flow). The OAM flags are used to control when and how OAM cells are processed and to determine if the current user cell belongs to a connection that has been selected for a performance monitoring test. If the Ingress cell be- longs to such a connection, the OAM table in external memory contains the relevant parameters. Subsequent to the context processing, the Ingress cells are transferred to the Ingress switch interface. Option- ally, the associated switch context parameters may be added to the cell before the header or placed in the VPI/ VCI fields of the header. Ingress Features The Ingress section (Ingress refers to cells being trans- ferred from the physical interface to the switch):

• Interfaces to one or more physical interface chips via an 8-bit wide, parity-protected receive data bus using the UTOPIA standard
• Decouples PHY timing from switch timing using independent clocks and a FIFO in the physical interface
• Performs Ingress cell discrimination based on pre-assigned ATM cell header values
• Provides either a restricted address table lookup scheme for Ingress address compression or support for an external address compression mechanism
• Reads Virtual Connection related UPC/NPC, OAM and switch context parameters through a 32-bit wide interface to an external memory
• Provides per-connection usage count
• Provides per-connection option to copy cells to the microprocessor
• Provides per-connection UPC/NPC policing including detection/counting of violating cells
• Supports OAM continuity check, alarm surveillance and loopback test on all connections
• Provides OAM performance monitoring test capabilities for selected connections
• Supports insertion of cells into the ingress cell flow
• Optionally performs VPI/VCI translation
• Forwards the received ATM cells to the switch using a UTOPIA-style interface, optionally adding associated internal switch context parameters
• Delay of 3 - 5 cell times from the PHY to the switch

2.2.2 Egress Cell Flow

In the Egress direction, the MC92500 receives cells from the switch along with their associated parameters, if any. One of these parameters is the Egress Connec- tion Identifier (ECI), which is used for direct lookup into the context table located in external memory to obtain the VPI/VCI, cell counters, and OAM flags. If multicast translation is enabled, the Multicast Identifier (MI) is re- ceived from the switch instead of the ECI, and the ECI is found in the multicast translation table. Cells are sub- ject to processing as indicated by the OAM flags. If the Egress cell belongs to a connection that has been se- lected for a performance monitoring test, the OAM Ta- ble in external memory contains the relevant parameters. The Egress cell header is generated by inserting the VPI/VCI-field obtained from the Address Translation Table in the (GFC)/VPI/VCI position and modifying the PTI-field if and when so indicated by the switch or in case of an OAM cell. The cell is then forwarded to the PHY I/F queue. Cell rate decoupling is performed in the Egress direction, i.e. unassigned cells are optionally generated if no cells are available from the switch.

• Receives ATM cells and associated switch context parameters (including congestion notification) from the switch using a UTOPIA- style interface
• Provides optional multicast identifier to connection identifier translation
• Reads Egress context parameters from external memory using direct lookup
• Provides per-connection usage count
• Provides per-connection option to copy cells to the microprocessor
• Supports OAM continuity check, alarm surveillance and loopback test on all connections
• Provides OAM performance monitoring test capabilities for selected connections
• Supports insertion of cells into the egress cell flow
• Performs VPI/VCI translation
• Transfers ATM cells to one or more physical interfaces via an 8-bit wide, parity-protected transmit data bus using the UTOPIA standard
• Decouples PHY timing from switch timing using independent clocks and a FIFO in the physical interface
• Delay of 3 - 5 cell times from the switch to the PHY

2.3 Other Functions

register access to the MC92500. 1149.1 boundary scan test logic.

2.4 MC92500 Block Diagram

individual blocks will be described in this section. Figure 4. MC92500 Block Diagram

2.4.1 Ingress PHY Interface (IPHI)

The Ingress PHY Interface (IPHI) block receives cells on a byte basis from the ATM PHY layer using the UTOPIA standard interface. It assembles the cells and synchronizes their arrival to the MC92500 cell process- ing slots. Unassigned and invalid cells (Table 1 and Ta- ble 2) are removed to provide cell rate decoupling. Also, the MC92500 can process cells at a higher rate than the PHY provides them, thereby creating “holes” in the cell flow. These can be used for either cell insertion or for maintenance access (used by the microprocessor to maintain external memory).

2.4.2 Ingress Cell Processing Unit (IPU)

The Ingress Cell Processing Unit (IPU) operates at a rate of one cell per cell processing slot. The cell may have arrived from the IPHI block or may be inserted from the Microprocessor Interface or Internal Scan blocks. The Ingress OAM function may also insert PM Forward Monitoring cells into the Ingress cell flow. A cell may be inserted when an unused cell slot is avail- able, subject to pacing by a simple leaky bucket algo- rithm. The IPU performs address compression on cells that arrived from the IPHI block in order to associate the cell with Context Table records in External Memory. The address compression function detects inactive cells (cells with no corresponding records in the Context Ta- ble). UPC/NPC is performed on a connection basis or op- tionally on arbitrary groups of connections. The UPC/ NPC function may detect violating cells as dictated by the selected UPC/NPC algorithm. Violating cells will normally be tagged or discarded from the cell flow, but an option exists to perform the UPC/NPC algorithm for statistical purposes only without modifying or removing the cells. OAM processing is performed where appropriate. The Ingress OAM function records OAM alarm cells: Alarm Indication Signal/Remote Defect Indicator (AIS/RDI). OAM processing for user cells involved in a perfor- mance monitoring block test involves computing the Bit-Interleaved Parity (BIP) and updating the Total User Cells (TUC) count. For OAM cells the processing may include overwriting the values of specific fields and checking or generating the CRC-10 field. Switch-specific overhead information is read from the context entry and added to the cell before it is sent on to the switch interface block. Address translation may optionally be performed at this point. The IPU will remove from the cell flow any OAM cell that has reached its endpoint. Also, certain cells may be copied to the MPIF for transfer to the microprocessor.

2.4.3 Ingress Switch Interface (ISWI)

The ISWI block contains a cell FIFO. Cells are received from the IPU. When a full cell has been transferred, the overhead information needed by the switch (as pro- grammed by the user) is extracted from the internal data structure along with the ATM header and payload of the cell. This information is transferred to the switch at the rate of one byte per clock cycle.

2.4.4 Egress Switch Interface (ESWI)

The ESWI block contains a cell FIFO. Data is received from the switch at the rate of one byte per clock cycle. The data structure received from the switch includes overhead routing information in addition to the ATM cell. When a full cell has been transferred, it is trans- formed into an internal data structure and presented to the EPU for processing.

2.4.5 Egress Cell Processing (EPU)

The Egress Cell Processing Unit (EPU) operates at the rate of one cell per cell processing slot. The cell may arrive from the Egress Switch Interface Block or may be inserted from the Microprocessor Interface or Internal Scan Blocks. The Egress OAM function may also insert PM Forward Monitoring cells into the Egress cell flow. The cell insertion is paced by a simple leaky bucket al- gorithm. The first stage of the Egress cell processing is perform- ing multicast translation, if needed. Then the EPU per- forms OAM processing where appropriate. The Egress OAM function records OAM Alarm cells. OAM process- ing for user cells involved in a Performance Monitoring block test is limited to computing the bit-interleaved par- ity and updating the Total User Cells count. For OAM cells the processing may include over-writing the values of specific fields and checking or generating the CRC- 10 field. Address translation is performed to replace the address fields of the ATM cell header with the address of the outgoing link.The EPU will remove from the cell flow any OAM cell that has reached its endpoint. Also, cer- tain cells may be copied to the MPIF for transfer to the microprocessor.

2.4.6 Egress PHY Interface (EPHI)

The Egress PHY Interface (EPHI) block takes the pro- cessed cells from the EPU, disassembles them into bytes and transfers them to the physical layer using the UTOPIA standard interface. Unassigned cells may be inserted to provide cell rate decoupling.

2.4.7 External Memory Interface (EMIF)

The External Memory Interface (EMIF) block performs address generation for the MC92500 accesses to the external memory. It provides 32-bit data and 22-bit ad- dress lines along with standard memory control signals.

2.4.8 Microprocessor Interface (MPIF)

The Microprocessor Interface (MPIF) block provides for configuration of the MC92500, the transfer of cells be- tween the microprocessor and the MC92500, and the maintenance of external memory. A generic 68xxx - compatible 32-bit slave interface is provided for easy connection to a variety of microprocessor buses. Out- put signals are provided that can serve as request sig- nals for up to three DMA devices to improve system performance. A cell extraction queue is used to store cells that are di- rected to the processor. Cells in this queue are trans- ferred first to an internal cell buffer. Then they may be read by the processor. Cells to be inserted in the Ingress or Egress flows are transferred from the processor memory to an internal insertion queue.

2.4.9 Internal Scan (ISCAN)

The Internal Scan (ISCAN) block scans the external memory for connections on which AIS, RDI, or Continu- ity Check (CC) OAM cells must be inserted. When such a connection is found, the cells are generated and add- ed to the insertion queue for the cell flow in the appro- priate direction.

2.4.10 Forward Monitoring Cell Generation

(FMC) The Forward Monitoring Cell (FMC) Generation block keeps track of the connections on which FMCs are pending during the course of a Performance Monitoring block test and maintains a priority among them. When a hole in the cell flow is available, this block requests the insertion of an FMC on the highest-priority connec- tion. 3. REGISTERS DESCRIPTION

3.1 MC92500 Registers

The MC92500 registers are divided into several groups. The register groups are: Status Reporting Registers - these registers report on the MC92500 status, and generally may be read and written by the processor in either of the MC92500 modes of operation (Setup Mode or Operate Mode). Control Registers - these registers control the MC92500 operation, and may be read and written by the processor in either of the MC92500 modes of oper- ation (Setup Mode or Operate Mode). Configuration Registers - these registers are used to define the MC92500 configuration, and may be read by the processor in either of the MC92500 modes of oper- ation (Setup Mode or Operate Mode). These registers may be written by the processor only in Setup Mode of operation. Cell Insertion Registers - these registers are used for cell insertion into the MC92500 cell flow, and may be written by the processor when the MC92500 is in Oper- ate Mode. In order to improve performance, the MC92500 Cell Insertion Registers receive special treat- ment and may be accessed without wait states. Cell Extraction Registers - these registers are used for copying cells from the MC92500 cell flows, and may be read by the processor when the MC92500 is in Operate Mode. In order to improve performance, the MC92500 Cell Extraction Registers receive special treatment and may be accessed without wait states. Pseudo Registers - these registers are used to perform certain operations on the MC92500, and may be written by the processor in either of the MC92500 modes of op- eration (Setup Mode or Operate Mode).

4.1 MC92500 External Memory

The MC92500 uses external memory to store the data- base (context information) relating to the processing of cells on a per-connection basis. The MC92500 can ac- cess External Memory with 16- or 32-bit data.

4.1.1 Memory Partitioning

The External memory is partitioned into several tables: (see Figure 6)

• Ingress Billing Counters - consists of a record for each active connection. The record contains the cell counters that are used by the connection dur- ing the normal Ingress cell flow. This table is dy- namic and updated by the MC92500. The microprocessor is responsible for collecting the contents of the counters on a regular basis.
• Egress Billing Counters - consists of a record for each active connection. The record contains the counters that are used by the connection during the normal Egress cell flow. This table is dynamic and updated by the MC92500. The microprocessor is responsible for collecting the contents of the counters on a regular basis. Flags Table - consists of a record for each active connection. The record contains OAM flags that are used by all the connections during the normal cell flow. This table is dynamic and updated by the MC92500 . The microprocessor is responsible for checking the flags on a regular basis
• Context Parameters Table - consists of a record for each active connection. The record contains con- nection-specific information for processing and routing the cells belonging to the connection.
• Ingress Policing Counters - consists of a record for each active connection. The record contains the counters that are used to record the results of the UPC/NPC policing. This table is dynamic and up- dated by the MC92500. The microprocessor is re- sponsible for collecting the contents of the counters on a regular basis.
• VC Table - contains a list of all the Ingress Connec- tion Identifiers (ICIs) that have been defined by the microprocessor as active Virtual Channel Connec- tions. This table exists only if the Table Lookup method of Address Compression is used with VC Table Lookup enabled.
• Multicast Translation Table - contains the Egress Connection Identifiers (ECIs) associated with the multicast identifiers.
• OAM Table - contains the additional information required to run OAM Performance Monitoring.
• VP Table(s) - each record contains an Ingress Con- nection Identifier (ICI) that has been defined by the microprocessor as an active connection. The size and location of the VP Table(s) are determined by the Link Register. If multiple links are supported, each Link Register defines a separate VP Table. The multiple VP Tables are not required to be con- tiguous.
• Dump Vector Table - contains the dump vectors describing the recent history of the cell processing. This table is generally only used for debugging purposes.
• Egress Link Counters - consists of a record for each link. The record contains the cell counters that are used by the link during the normal Egress cell flow. This table is dynamic and updated by the MC92500. The microprocessor is responsible for collecting the contents of the counters on a regular basis.
• Ingress Link Counters - consists of a record for each link. The record contains the cell counters that are used by the link during the normal Ingress cell flow. This table is dynamic and updated by the MC92500. The microprocessor is responsible for collecting the contents of the counters on a regular basis.
• Virtual Bucket Table - each record in this table con- tains the information for the UPC/NPC enforce- ment. This is not a physical table, but a virtual one. Since the Parameters Table contains a full address for the location of the Bucket record of each con- nection, there is no need to put all the Bucket records in consecutive physical locations. Although the user can distribute the records in any manner. 4. EXTERNAL MEMORY DESCRIPTION

Figure 6. External Memory Partitioning

5.1 Functional Signal Groups

Figure 7. Each signal is explained briefly.

5.2 Ingress PHY Signals

Figure 7. Functional Signal Groups

Receive Data Bus (RXDATA0 - RXDATA7) This input data bus receives octets from the PHY chip. When RXENB is active, RXDATA is sampled into the MC92500. Receive Data Bus Parity (RXPRTY) This input is the odd parity over RXDATA. This in- put is ignored if RXENB was not active or the parity check is disabled. Receive Start Of Cell (RXSOC) This input, when high, indicates that the current RXDATA is the first byte of a cell. This input is sampled when RXENB is active. Receive PHY Empty (RXEMPTY ) This input, when low, indicates that currently the PHY chip has no available data. Receive Enable (RXENB) This output, when low, indicates that the MC92500 is ready to receive data. Receive PHY ID (RXPHYID0 - RXPHYID3) This input bus indicates the ID number of the PHY device currently transferring data to the MC92500. If only a single PHY device is supported, this bus should be tied low. This bus is sampled along with the first oc- tet of each cell.

5.3 Egress PHY Signals

The following signals relate to the PHY interface that is connected to the PHY chip(s) using the UTOPIA stan- dard. All of the input signals are sampled at the rising edge of ACLK, and all of the output signals are updated at the rising edge of ACLK. Transmit Data Bus (TXDATA0-TXDATA7) This output data bus transmits octets to the PHY chip. When TXENB is active, TXDATA contains a valid octet for the PHY. Transmit Data Bus Parity (TXPRTY) This output signal is the odd parity over TXDATA. When TXENB is active, TXPRTY is a valid parity bit for the PHY. Transmit Enable (TXENB) This output signal, when low, indicates that TXDATA, TXPRTY, and TXSOC are valid data for the PHY. Transmit Start Of Cell (TXSOC) This output signal indicates, when high, that the current data on TXDATA is the first byte of a cell. TXSOC is valid when TXENB is asserted. Transmit PHY Full (TXFULL) This input signal indicates, when low, that the PHY device is full. Transmit Cell Clear (TXCCLR) This input signal indicates, when low, that the cur- rent cell should be cleared from the Egress PHY inter- face. Transmit PHY ID (TXPHYID0 - TXPHYID3) This output bus indicates the ID number of the PHY device to which either the current cell or the next cell is directed. Transmit Next PHY ID Valid (TXPHYIDV This output signal, when low, indicates that TX- PHYID (when configured as the next cell’s ID) is valid. If TXPHYID is configured to refer to the current cell, TXPHYIDV is not used.

5.3.1 Ingress Switch Interface Signals

The following signals relate to the Ingress switch inter- face. All of the input signals are sampled at the rising edge of SRXCLK, and all of the output signals are up- dated at the rising edge of SRXCLK. Receive Clock (SRXCLK) This input signal is used to clock the ingress switch interface signals. Receive DATA BUS (SRXDATA0-SRXDATA7) This 3-state output data bus transmits bytes to the switch. When SRXENB is active, SRXDATA contains valid data for the switch. This bus is updated on the ris- ing edge of SRXCLK. Receive Data Bus Parity (SRXPRTY) This 3-state output is the parity protection of SRX- DATA transmitted to the switch. It is output on the rising edge of SRXCLK.

Receive Start Of Cell (SRXSOC) This 3-state output, when high, indicates that the current data on SRXDATA is the first byte of a cell structure (including the overhead bytes). It is output on the rising edge of SRXCLK. Receive Switch Cell Available (SRXCLAV) This output, when asserted, indicates that the MC92500 has a cell ready to transfer to the switch. When negated, it indicates that currently there is no data available for the switch. It is output on the rising edge of SRXCLK. Receive Enable (SRXENB This input, when low, enables new values on SRX- DATA, SRXPRTY and SRXSOC. This input is sampled on the rising edge of SRXCLK.

5.3.2 Egress Switch Interface Signals

The following signals relate to the Egress switch inter- face. All of the input signals are sampled at the rising edge of STXCLK, and all of the output signals are up- dated at the rising edge of STXCLK. Transmit Clock (STXCLK) This input signal is used to clock the egress switch interface signals. Transmit Data Bus (STXDATA0 - STXDATA7) This input data bus receives bytes from the switch. When STXENB is asserted, STXDATA is sampled into the MC92500 on the rising edge of STXCLK. Transmit Data Bus Parity(STXPRTY) This input is the parity over STXDATA. This input is ignored if STXENB is negated or the parity check is disabled. It is sampled on the rising edge of STXCLK. Transmit Start Of Cell (STXSOC) This input indicates, when high, that the current data is the first byte of a cell structure (including the overhead bytes). This input is sampled on the rising edge of STXCLK when STXENB is asserted. Transmit Enable (STXENB) This input, when low, enables STXDATA, STXPRTY, and STXSOC. It is sampled on the rising edge of STXCLK. Transmit Cell Available (STXCLAV) This output, when asserted, indicates that the MC92500 is prepared to receive a complete cell. It is output on the rising edge of STXCLK.

5.4 External Memory Signals

The following signals relate to the External memory in- terface. External Memory Data Bus (EMDATA0-EMDATA31) This three-state bidirectional bus provides the data path between the MC92500 and the External Memory. External Memory Address Bus (EMADD2- EMADD23) This output bus provides the general address bus which is used by the MC92500 in its accesses to the External Memory. External Memory Write (EMWR This output signal indicates that the current cycle to the External Memory is a write cycle. This signal is active low and is asserted within the cycle. External Memory Bank Select High (EMBSH0 EMBSH3 ) These output signals are used to select the high word of the appropriate memory bank. One or more of these signals is asserted for each External Memory ac- cess according to the value of EMADD. During a main- tenance write access from the microprocessor, the value detected on MWSH is driven on the appropriate EMBSH signal. These signals are active low. External Memory Bank Select Low (EMBSL0 - EMBSL3 ) These output signals are used to select the low word of the appropriate memory bank. One or more of these signals is asserted for each External Memory ac- cess according to the value of EMADD.During a main- tenance write access from the microprocessor, the value detected on MWSL is driven on the appropriate EMBSL signal. These signals are active low. External Address Compression Enable (EACEN) This output signal is asserted when data is being written to or read from an external address compres- sion device using the External Memory Data Bus. This signal is active low.

5.4.1 Control Signals

These signals are used to control the MC92500. ATMC Power-Up Reset (ARST ) This input signal is used for power-up reset of the entire chip. It must be asserted for at least the time re- quired by the PLL to lock. Enable IDD (ENID) This input is a dedicated test signal which must be grounded during normal system operation. ATMC Mode (AMODE0-AMODE1) These inputs are dedicated test signals which must be grounded during normal system operation.

5.4.2 Microprocessor Signals (MP)

The following signals relate to the microprocessor interface. MP Clock (MCLK) This input signal is used as the Microprocessor clock inside the MC92500. This signal drives the micro- processor interface logic in the MC92500. The duty cy- cle should be in the range of 40-60%. MP Data Bus (MDATA0-MDATA31) This 3-state bidirectional bus provides the general data path between the MC92500 and the microproces- sor. MP Address Bus (MADD2-MADD25) This input bus contains the address which is used by the microprocessor to define the register being ac- cessed. This bus is used by the MC92500 at the asser- tion of MSEL and sampled on the falling edge of MCLK. MP Select (MSEL) This input signal is used to determine that the cur- rent access to the MC92500 is valid. This signal is ac- tive low and sampled by the MC92500 on the falling edge of MCLK. MP Data Select (MDS This input signal is used to indicate when the data on MDATA is valid during a write access to the MC92500. This signal is active low and sampled by the MC92500 on the falling edge of MCLK. MP Write (MWR This input signal is used to determine whether the MP is reading from the MC92500 or writing to it. This signal is active low and sampled by the MC92500 on the falling edge of MCLK. The MC92500 will drive MDATA when MSEL = 0 and MWR = 1. MP Word Select High (MWSH) This input signal indicates that the high word is be- ing accessed. During a maintenance access, the value detected on MWSH is driven on the appropriate EMBSH signal. This signal is active low and sampled by the MC92500 on the falling edge of MCLK. MP Word Select Low (MWSL ) This input signal indicates that the low word is be- ing accessed. During a maintenance write access, the value detected on MWSL is driven on the appropriate EMBSL signal. This signal is active low and sampled by the MC92500 on the falling edge of MCLK. Note: All Cell Extraction Register, Cell Insertion Register, and General Register accesses are long-word (32-bit) accesses, so both MWSH and MWSL should be asserted low for these accesses. MP Data Acknowledge (MDTACK ) This three-state output signal is used to indicate when the data on MDATA is valid during a read access from the MC92500 or when the data has been sampled during a write access to the MC92500. At the end of each access, this signal is actively pulled up and then 3-stated (Hi -Z). The user may program the MC92500 not to drive MDTACK during certain types of accesses. This signal is active low and is output asynchronously to MCLK. MP Interrupt (MINT This output signal is used to notify the micropro- cessor of the occurrence of interrupting events. This signal is asserted on the rising edge of ACLK (asyn- chronous with respect to MCLK). MP Cell In Request (MCIREQ This output signal may be used by an external DMA device as a control line indicating when to start a new cell insertion cycle into the MC92500. This signal is asserted whenever the Cell Insertion Register array is available to be written. This signal is active low and is output on the falling edge of MCLK.

MP Cell Out Request (MCOREQ) This output signal may be used by an external DMA device as a control line indicating when to start a new cell extraction cycle from the MC92500. This out- put is asserted whenever the Cell Extraction Register array is available to be read. This signal is active low and is output on the falling edge of MCLK. External Memory Maintenance Request (EMMREQ This output signal is asserted a programmable number of clock cycles before the start of an external memory maintenance cycle. It is negated after a pro- grammable number of maintenance accesses have been performed. This signal is active low and is output on the falling edge of MCLK.

5.4.3 Clock Signals

The following signals are connected to the analog PLL which is used in the MC92500 ACLK. ATMC Master Clock (ACLK) This input signal is used by the PLL to generate the internal master clock of MC92500. The duty cycle should be in the range of 40-60%. TESTSEL This input is a dedicated test signal which must be grounded during normal system operation. TESTOUT This 3-state output is a dedicated test signal which must be grounded during normal system operation. VCOCTL This is a dedicated test signal which must be con- nected to the analog ground (AVSS) during normal sys- tem operation.

5.4.4 JTAG Interface Test Signals

Test Clock (TCK) This input pin is the JTAG clock. The TDO, TDI, and TMS pins are synchronized by this pin. Test Mode Select (TMS) This input pin is sampled on the rising edge of TCK. TMS is responsible for the state change in the test access port state machine. Test Data Input (TDI) This input pin is sampled on the rising edge of TCK. TDI is the data to be shifted toward the TDO output. Test Data Output (TDO) This 3-state output pin changes its logical value on the falling edge of TCK. Test Reset (TRST This input pin is the JTAG asynchronous reset. When asserted low, the test access port is forced to the Test_Logic_Reset state. When JTAG is not being used, this signal should be tied to ARST or hard-wired to GND. 6. INGRESS DATA PATH OPERATION

6.1 Ingress Data Path

The ingress data path includes the following steps: 1. Cell assembly from physical layer 2. Address compression 3. Context Table lookup 4. Cell counting 5. UPC/NPC processing 6. Cell insertion 7. OAM processing 8. Appending switch overhead information and address translation 9. Transfer to switch The cell flow through these steps is shown in Figure 8. Each step is described in the subsections below. Dur- ing the processing, the decision can be made to re- move a cell from the cell flow based on the connection parameters or the OAM processing, among other rea- sons. Such a cell may be copied to the cell extraction queue.

Figure 8. Ingress Data Path

6.2 Interface to Physical Layer - Cell

per cell slot by the cell processing block. Table 1. Pre-assigned Header Values at the UNI Table 2. Pre-assigned Header Values at the NNI

6.3 Address Compression

The purpose of the ingress address compression is to map the address field(s) in the header of the received cell into a pointer to the entry in the Context Table that relates to the cell’s virtual connection. The MC92500 supports two types of service, Virtual Path switching service and Virtual Channel switching service. For VP switching the address is the Virtual Path Identifier (VPI) field of the cell header. For VC switching the address consists of both the VPI and the Virtual Channel Identifier (VCI) fields of the cell header. When the MC92500 supports multiple PHY layer devices, the mapping of ATM addresses to Context Table entries must be done separately for each PHY layer link. For this purpose, the number of the link from which a cell arrived can be treated as an additional ad- dress field. In this case, a VP switching address con- sists of the Link/VPI fields and a VC switching address consists of the Link/VPI/VCI fields. Cells that are inactive, i.e. for which no valid connection is found during address compression, are removed from the cell flow and copied to the Cell Extraction Queue. Address Compression Options The MC92500 supports two methods for performing address compression: 1. Table lookup using restricted address spaces 2. External address compression Table Lookup When some of the bits of the VPI and/or VCI are not allocated, the address range can be reduced enough to make a table lookup scheme practical. External Address Compression The external address compression method allows the user total flexibility in performing the ingress address compression.

6.4 Cell Counting

If the processed cell was received from the physical layer (not inserted internally), one of the existing con- nection cell counters from the Ingress Billing Counters Table and one of the existing link cell counters from the Ingress Link Counters Table is incremented. The ap- propriate counter is chosen based on the CLP bit and whether the cell is an OAM cell. UPC/NPC One of the major advantages of ATM is the ability to dynamically distribute the available bandwidth among many connections. However, it is this feature that makes congestion in an ATM network difficult to pre- dict. In order to make the network management feasi- ble, limits are imposed on the traffic parameters of each connection. Typically, the maximum average band- width and the maximum burstiness may be defined. Even when the usage parameters have been defined, a single user that does not stick to the agreed-upon parameters can cause congestion which will lead to a reduction in the quality of service provided to the other users. Therefore, the usage parameters should be en- forced at the entrance to the network in such a way that the violating user is the one who suffers reduced quality of service. This enforcement is called Usage Parameter Control (UPC) at a User-Network Interface (UNI) and is called Network Parameter Control (NPC) at a Network- Network Interface (NNI). The MC92500’s UPC/NPC algorithm, based on the concept of “leaky buckets”, detects cells that violate the traffic agreement and optionally tags (i.e. changes CLP-field from 0 to1) or discards (removes from the cell flow) violating cells. A flexible arrangement of leaky buckets (0 to 4 per connection), leaky bucket parame- ters and UPC/NPC enforcement algorithms is provided for all connections. At connection set-up time a set of bucket characteristics is loaded into the Bucket Table section of context memory. This defines the expected cell arrival pattern on a particular connection, and it is used by the UPC/NPC function as a means of enforcing the agreed-upon user traffic. Note: For constant bit rate and variable bit rate connections the bucket characteristics are nor- mally defined when the connection is setup and remain constant. However, other types of con- nections may require dynamic UPC/NPC enforc- ers where the processor updates these values while the connection is active. Caution is advised when doing so in order to maintain consistency among the various parameters of the enforcer. All user data cells that have not been removed from the cell flow are subject to UPC/NPC processing according to the parameters of their connection. Counts of the cells that have been discarded or tagged are optionally maintained per connection in the Ingress Policing Counters Table.

A “don’t touch” option is provided to apply the UPC/ NPC algorithm for statistical purposes without tagging or discarding the violating cells. A UPC/NPC mechanism can be used to enforce the sum of several connections. This method is likely to be used at the boundary point where many VCCs are com- bined into a VPC.

6.5 Ingress Cell Insertion

The MC92500 makes use of the holes in the cell flow provided by the IPHI block (whether due to the differ- ence between the cell processing and arrival rates or the reception of unassigned or invalid cells) to insert cells into the ingress cell flow. The cell insertion rate is paced by a single leaky bucket to ensure that the switch is not flooded with inserted cells beyond its capacity. The types of cells that can be inserted in the ingress cell flow are:

• OAM cells generated internally by the MC92500 including: - AIS cells - RDI cells - Continuity Check cells - PM Forward Monitoring cells
• OAM cells generated by the microprocessor
• Other cells generated by the microprocessor The various types of cells that can be inserted in the in- gress cell flow are classified by their insertion priority and held in separate queues. The insertion priorities are (from highest to lowest): 1. PM Forward Monitoring cells generated inter- nally by the MC92500 2. Cells from the microprocessor 3. AIS, RDI, and CC cells generated internally by the MC92500

6.6 Switch Overhead Information

The MC92500 optionally performs address translation on the Ingress cell flow. The new address fields are tak- en from the Ingress Translation Address word of the Context Parameter Table in the External Memory. The source of the switch overhead information provid- ed by the MC92500 is the Context Parameters Table entry for the connection. The overhead bytes are trans- ferred before the cell, most-significant byte first. If any of the switch parameter words are not provided, the val- ues of the corresponding overhead bytes added to the cell are undefined. The MC92500 can add up to 16 bytes of switch overhead information.

6.7 Transfer to Switch

The Ingress Switch Interface (ISWI) block receives cells from the Cell Processing block, queues them, and transfers the data structure to the switch. The switch interface signals are identical to the UTOPIA Level 1 Receive Interface with the MC92500 playing the role of the PHY layer and the switch playing the role of the ATM layer. The switch interface signals are clocked by an independent clock signal, SRXCLK. The switch is required to accept cells from the MC92500 when they are presented on the interface with a delay of up to one cell slot for synchronization. Note that the cells may be presented at a higher rate than they are received from the PHY layer due to cell insertion. The switch must be capable of receiving the cells at a sustained rate of one cell per cell slot. Other- wise, the cells may back up in the MC92500, process- ing will be halted, and cells will not be accepted from the PHY layer. Although the maximum sustained rate is one cell per cell slot, the rate can be limited by the in- sertion pacing mechanism. 7. EGRESS DATA PATH OPERATION

7.1 Egress Data Path

The egress data path includes the following steps: 1. Transfer from switch 2. Multicast identifier translation (if necessary) 3. Cell insertion 4. Context Table lookup 5. OAM processing 6. Address translation 7. Cell Counting 8. Transmission to the physical layer The cell flow through these steps is shown in Figure 9. Each step is described in the subsections below. Dur- ing the processing, the decision can be made to re- move a cell from the cell flow for any of several reasons. Such a cell may be copied to the Cell Extraction Queue.

7.1.1 Transfer from Switch

are clocked by an independent clock signal, STXCLK. curs on a payload byte, the cell is optionally discarded. rent cell is discarded and the error is reported. Figure 9. Egress Data Path from the switch is programmable.

1. ATM Cell Header (4 bytes; PTI, CLP valid; VCI
2. HEC octet (provided only if ESHF is set) - this
3. ATM cell payload (48 bytes)

• Egress Connection Identifier (ECI) / Multicast Identifier (MI)
• Multicast bit (M)
• Explicit Forward Congestion Indication (EFCI)
• Multicast Translation Table Section (MTTS) The location of these fields in the overhead, header and HEC bytes is programmable. Once the valid fields have been retrieved, the remaining overhead bytes received from the switch will be discarded since they are of no use to the MC92500 and are not transferred to the PHY layer.

7.1.2 Multicast Identifier Translation

Multicasting involves copying a cell that arrived at the switch and transmitting it on multiple physical links. In the general case the ECI of the connection to which the cell belongs will be different on each link. If the switch can provide the correct ECI to each MC92500 device, the multicast operation is transparent to the MC92500. However, if the switch cannot provide separate ECIs for each link, a common multicast identifier may be provid- ed to all of the MC92500 devices. Each MC92500 will translate the multicast identifier into the ECI for its phys- ical link.

7.1.3 Egress Cell Insertion

In order to insert cells into the egress cell flow, the MC92500 creates holes in the cell flow received from the switch interface block by not taking a cell from the FIFO. Inserting many cells in a short period of time may overload the switch’s queueing capability. Therefore, the cell insertion rate is regulated by a leaky bucket. The types of cells that can be inserted in the egress cell flow are:

• OAM cells generated internally by the MC92500 including: - AIS cells - RDI cells - Continuity Check cells - PM Forward Monitoring cells
• OAM cells generated by the microprocessor
• Other cells generated by the microprocessor The various types of cells that can be inserted in the egress cell flow are classified by their insertion priority and held in separate queues. The insertion priorities are (from highest to lowest): 1. PM Forward Monitoring cells generated inter- nally by the MC92500 2. Cells from the microprocessor 3. AIS, RDI, and CC cells generated internally by the MC92500

7.1.4 Address Translation

The address fields of the cell header are optionally re- placed by the outgoing address of the outgoing link as read from the Egress Translation Address word of the Context Parameter Table. If the cell belongs to a VPC, only the VPI field is replaced. If the cell belongs to a VCC, both the VPI and VCI fields are replaced. The MC92500 sets the middle bit of the PTI on cells whose received PTI is 000 or 001 when the EFCI bit re- ceived from the Egress switch interface block is set.

7.1.5 Cell Counting

For each cell transmitted to the PHY layer, one of the counters from the Egress Billing Counters Table for this connection is incremented, unless the table does not exist. One of the link cell counters from the Egress Link Counters Table is also incremented if the table exists. The appropriate counter is chosen based on the CLP bit and whether the cell is an OAM cell. Cells that are removed from the cell flow are not included in the usage counts. Inserted cells and internally generated cells are included in the usage counts.

7.1.6 Transmission to Physical Layer

The Egress Physical-Layer Interface (EPHI) block re- ceives cells from the Cell Processing block, queues them, and transmits the cell data to the physical layer using the UTOPIA standard interface. The cells are then stored in a FIFO and are disassem- bled into bytes for transmission to the physical layer. The size of the FIFO is programmable to either 2 or 4 cells. If the EPHI FIFO is empty, the MC92500 option- ally fills the hole with a cell to provide a continuous cell flow at the physical layer bit rate. The type of cell used to fill the holes in either “unassigned” (an ATM layer cell) or “Idle” (a physical layer cell). If multiple physical links are supported, the generation of these cells is not supported and should not be enabled. Since the MC92500 processes cells at a higher rate than they are transmitted to the physical layer, the EPHI block cannot transfer a cell during every cell processing slot. Over time, cells may accumulate in the EPHI FIFO until it is full. When this happens, the MC92500 will not process a cell during the next cell processing slot, al- lowing the FIFO to drain to the physical layer. TXPRTY is always driven with odd parity over TXDA- TA, regardless of whether or not parity checking is en- abled on the Ingress PHY Interface. The fifth octet of the transmitted cell (the HEC field) is always transmitted as zero, regardless of the value passed to the MC92500 by the switch interface block.

8.1 MC92500 Modes of Operation

writing to a pseudo-register.

8.1.1 Setup Mode

these registers in Operate Mode is forbidden. is not allowed in Setup Mode. hardware or software reset is performed.

8.1.2 Operate Mode

but not written, when the MC92500 is in Operate Mode.

8.1.3 Reset

the reset, the MC92500 will be in setup mode.

8.2 Data Path Clock Configuration

figuration is shown in Figure 10. Figure 10. MC92500 Clock Configuration

1. ELECTRICAL CHARACTERISTICS

9.1 Electrical Specifications

9.1.1 Clocks

Figure 11. Clocks Timing

9.1.2 Microprocessor Interface Timing

The timing diagrams in this section are intended to con- vey setup and hold values for input signals and propa- gation delay values for output signals. The diagrams are NOT intended to convey cycle based behavior. a. refers only to the first falling edge of MCLK in each access at which MSEL is asserted c. TD = External Memory access time + 18 ns d. TR = 4 * ACLK period + 20 ns e. This is for a 50 pF load. f. T RD = 4 * ACLK period + 11 ns g. TWD is measured from the MCLK falling edge at which MDS is sampled as asserted. TWD = 4 * ACLK period + 11 ns h. TW is measured from the MCLK falling edge at which MDS is sampled as asserted. TW = 4 * ACLK period. Note that the setup and hold times with respect to MCLK (timing values 1 and 2) still apply. Num Characteristics Min Max Unit

1 MSEL setup time before MCLK falling edge 5 ns

2 MSEL hold time after MCLK falling edge 1 ns

3 MADD/MWR setup time before MSEL assertion 5 ns

4 MADD/MWR hold time after MCLK falling edgea 3n s

5 MDS setup time before MCLK falling edge 5 ns

6 MDS hold time after MCLK falling edge 1 ns

7 MDATA setup time before MCLK falling edge 4 ns

8 MDATA hold time after MCLK falling edge 1 ns

9 MSEL

assertion to MDATA active 0 ns

11 MCLK falling edge to MDATA valid for CER Accessesb 26 ns

12 MSEL negation to MDATA invalid 1 ns

13 MSEL negation to MDATA inactive 11 ns

14 MWR assertion to MDATA invalid 1 ns

15 MWR assertion to MDATA inactive 11 ns

16 MCLK rising edge to MDATA valid for Maintenance Accessesb,

17 MCLK falling edge to MDATA valid for General Register Accessesb,

19 MSEL assertion to MDTACK active 0 ns

20 MCLK falling edge to MDTACK inactive 12 ns

21 MSEL assertion to MDTACK assertede 9n s

22 MSEL negation to MDTACK negatede 13 ns

23 MCLK rising edge to MDTACK assertede 13 ns

24 MWSH , MWSL setup time before MCLK falling edgea 2n s

25 MWSH , MWSL hold time after MCLK falling edgea 3n s

26 MCLK falling edge to REQ valid 0 14 ns

27 MCLK falling edge to MDTACK asserted for General Register Read Accessese,

28 MCLK falling edge to MDTACK asserted for General Register Write Accessese,

29 Access width (MCLK falling edge to MSEL negation) for General Register Write Accessesh TW ns

Figure 12. Cell Extraction Register Read Access Timing

Figure 13. Maintenance Read Access Timing

Figure 14. General Register Read Access Timing

Figure 15. Cell Insertion Register Write Access / Maintenance Write Access Timing

Figure 16. General Register Write Access Timing

Figure 17. DMA Request Signals Timing

9.1.3 PHY Interface Timing

Figure 18. Receive PHY Interface Timing Figure 19. Transmit PHY Interface Timing

9.1.4 Switch Interface Timing

Figure 20. Ingress Switch Interface Timing Figure 21. Egress Switch Interface Timing

64 SRXCLK rising edge to outputs active 1 ns

65 SRXCLK rising edge to outputs inactive 1 16 ns

9.1.5 External Memory Interface Timing

9.1.6 Write Cycle Timing

Figure 22. External Memory Write Access Timing a. A write occurs during the overlap of EMBSH0-3, EMBSL0-3 , EACEN low and EMWR low. for the External Memory interface pins.

9.1.7 Read Cycle Timing

Figure 23. External Memory Read Access Timing a. A RAM with hold time from address change to data change is required. b. Failure to meet this value may result in contention on EMDATA if a write access follows.

9.1.8 DC Electrical Characteristics

Table 3. Preliminary Electrical Characteristics Note: Maximum ratings are those values beyond which damage to the device may occur.

1. All parameters are characterized for DC conditions after thermal equilibrium has been established.
2. Unused inputs must always be tied to an appropriate logic voltage level (e.g., either V
3. This device contains circuitry to protect the inputs against damage due to high static voltages or electric fields; how-

ages to this high impedance circuit.

1. All input, bidirectional, and MDT

constrained to 0 < (Vin,Vout) < 5.5 V.

1. SRXDATAx, SRXSOC, SRXPRTY , TDO 3-State outputs must be constrained to 0 < Vout < VDD in Hi-Z State.

Table 4. Preliminary DC Electrical Characteristics (Ta = 0˚C to 70˚C) VDD =3.3V–0.3V

• Inputs may be modified to include pull resistors at any time.

10.1 Pin Assignment

Table 5. Functional Pin Assignment

256 PBGA Pin Diagram/Power Pin Assignment (Bottom View)

Table 6. Signal Pin Allocation Table 7. Power Pin Allocation

10.2 256 PBGA Case Outline (Preliminary Drawing) OMPAC - (used for Production) ZP Package GTPAC - (used for Prototype and Production) ZQ Package Dimensions for OMPAC Dimensions for GTPAC NOTE:

256 OMPAC package thickness is subject to change to

reflect substrate standardization, consult factory for status. DIM MILLIMETERS INCHES DIM MILLIMETERS INCHES MIN MAX MIN MAX MIN MAX MIN MAX G 1.27 BSC .050 BSC G 1.27 BSC .050 BSC K C D 0.15 (0.006) -T- G J256X O H 19 17 15 13 11 9 7 5 3 1 A B C D E F G H J K L M N P R T U V W Y M S S0.50 (0.020) S RT A B E F -S- -R--R - 20 18 16 14 12 10 8 6 4 2 M S S0.50 (0.020) S RT -S- -R--R - 10. PACKAGE INFORMATION

Notes:

How to reach us: USA/EUROPE/Locations not listed: Motorola Literature Distribution; JAPAN: Nippon Motorola Ltd.; Tatsumi-SPD-JLDC, P .O. Box 20912; Phoenix, Arizona 85036. 1-800-441-2447 or 6F Seibu-Butsuryu-Center, 3-14-2 Tatsumi Koto-Ku, Tokyo 135, Japan. 03-81-3521-8315 602-303-5454 INTERNET: http://Design-NET.com 51 Ting Kok Road, Tai Po, N.T., Hong Kong. 852-26629298 Motorola reserves the right to make changes without further notice to any products herein. Motorola makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does Motorola assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. “Typical” parameters can and do vary in different applications. All operating parameters, including “Typicals” must be validated for each customer application by customer’s technical experts. Motorola does not convey any license under its patent rights nor the rights of others. Motorola products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the Motorola product could create a situation where personal injury or death may occur. Should Buyer purchase or use Motorola products for any such unintended or unauthorized application, Buyer shall indemnify and hold Motorola and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that Motorola was negligent regarding the design or manufacture of the part. Motorola and b are registered trademarks of Motorola, Inc. Motorola, Inc. is an Equal Opportunity/Affirmative Action Employer.