Mcmal16 32 64dma

IBM MCMAL 8/32/64 DMA for Cu-11 and Cu-08
Title Page
Core Databook
SA14-2653-01
Revision 1
March 13, 2007 - IBM Confidential
IBM ®
Copyright and Disclaimer

© Copyright International Business Machines Corporation 2002, 2007
All Rights Reserved

Printed in the United States of America March 2007
The following are trademarks of International Business Machines Corporation in the United States, or other countries, or
both.
CoreConnect, IBM, IBM Logo, ibm.com, PowerPC
Other company, product, and service names may be trademarks or service marks of others.
All information contained in this document is subject to change without notice. The products described in this document
are NOT intended for use in applications such as implantation, life support, or other hazardous uses where malfunction
could result in death, bodily injury, or catastrophic property damage. The information contained in this document does not
affect or change IBM product specifications or warranties. Nothing in this document shall operate as an express or implied
license or indemnity under the intellectual property rights of IBM or third parties. All information contained in this docu-
ment was obtained in specific environments, and is presented as an illustration. The results obtained in other operating
environments may vary.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS IS” BASIS. In no event will IBM be
liable for damages arising directly or indirectly from any use of the information contained in this document.
This document is VALID ONLY on the date printed.
This document can be printed. The responsibility for using the latest level of this document and for destroying down-level
versions lies with the user of the document. To request the most recent version of this document, contact your IBM repre-
sentative.
IBM Systems and Technology Group

2070 Route 52, Bldg. 330
Hopewell Junction, NY 12533-6351
The IBM home page can be found at ibm.com
The IBM semiconductor solutions home page can be found at ibm.com/chips
SA14-2653-01
March 13, 2007 - IBM Confidential
IBM Core Databook
Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08
Table of Contents
Contents
Preface ............................................................................................................................. 7
About this Book ....................................................................................................................................... 7
Who Should Use this Book ..................................................................................................................... 7
Summary of Changes ............................................................................................................................. 7
Notation Conventions .............................................................................................................................. 7
Notation Conventions .............................................................................................................................. 9
Terms and Abbreviations ........................................................................................................................ 9
1. Overview .................................................................................................................... 11
1.1 Introduction ..................................................................................................................................... 11
1.1.1 General Description ............................................................................................................... 11
1.2 Features .......................................................................................................................................... 11
1.2.1 Clocking Scheme ................................................................................................................... 12
1.2.2 Detailed Characteristics ......................................................................................................... 12
1.3 MCMAL - ComMac Structure .......................................................................................................... 14
1.3.1 Communication Core Specific Logic ...................................................................................... 14
1.3.2 Memory Access Layer ........................................................................................................... 14
1.4 Typical Application .......................................................................................................................... 14
1.5 References ...................................................................................................................................... 16
1.6 Additional Required Elements ......................................................................................................... 16
1.7 Related IBM Cores .......................................................................................................................... 16
2. Functional Description ............................................................................................. 17

2.1 Hardware Overview ......................................................................................................................... 17
2.1.1 MCMAL - Internal Structure ................................................................................................... 17
2.1.2 Usage of MCMAL - ComMac: Software Activation ................................................................ 18
2.1.3 Transmit and Receive Operation ........................................................................................... 19
2.2 ComMac-MCMAL Interface ............................................................................................................. 22
2.2.1 32-Bit OPB/128-Bit OPB ComMacs ...................................................................................... 23
2.2.2 ComMac-MCMAL Protocol .................................................................................................... 23
2.2.3 MCMAL Burst Length ............................................................................................................ 24
2.2.4 ComMac-MCMAL Sideband Signal Naming Convention and Description ............................ 25
2.2.5 ComMac-MCMAL TX Packet Transfer Flow ......................................................................... 33
2.2.6 ComMac-MCMAL RX Packet Transfer Flow ......................................................................... 36
2.2.7 ComMac-MCMAL Status/Control Exchange ......................................................................... 38
2.2.8 ComMac-MCMAL Protocol (Waveforms) .............................................................................. 41
2.3 128-Bit Extended OPB .................................................................................................................... 49
2.3.1 Introduction ............................................................................................................................ 49
2.3.2 Overview ................................................................................................................................ 49
2.3.3 Physical Implementation - Changes and Additions to the OPB Bus Version 1.4 .................. 50
2.3.4 EOPB Signals ........................................................................................................................ 50
2.3.5 MCMAL Burst Length - EOPB ............................................................................................... 55
2.4 Back-to-Back TX Status Mechanism ............................................................................................... 55
2.4.1 General .................................................................................................................................. 55
2.4.2 Description ............................................................................................................................. 55
SA14-2653-01
March 13, 2007 - IBM Confidential Page 3 of 132
Core Databook IBM
MCMAL 8/32/64 DMA for Cu-11 and Cu-08 Revision 1
2.5 MCMAL Operation on OPB and PLB .............................................................................................. 58

2.5.1 MCMAL Operation on the PLB .............................................................................................. 58
2.5.2 MCMAL Operation on the OPB .............................................................................................. 60
2.6 DCR MCMAL-CPU Interface ........................................................................................................... 61
2.6.1 DCR Interface Overview ........................................................................................................ 61
2.6.2 DCR Interface Implementation Notes .................................................................................... 62
2.7 MCMAL Arbitration Between ComMac Channels ........................................................................... 63
2.7.1 MCMAL Arbitration Algorithm ................................................................................................ 63
2.7.2 Arbitration Inside the Group ................................................................................................... 64
2.7.3 Arbitration Between the Groups ............................................................................................. 65
2.8 Arbitration Between Multiple MCMALs ............................................................................................ 67
2.9 Performance and Latency ............................................................................................................... 70
2.9.1 MCMAL Latencies in the Framework of a Packet Transfer ................................................... 70
2.9.2 Concurrent Rx and Tx Operation ........................................................................................... 77
2.9.3 Performance and Latency with Clock Ratio of 1:2 or 1:3 ....................................................... 79
2.9.4 Steps that will Increase Bandwidth ........................................................................................ 80
2.9.5 PLB, OPB and EOPB Utilization ............................................................................................ 81
3. Software Interface ..................................................................................................... 83

3.1 Buffer Descriptor ............................................................................................................................. 83
3.1.1 Transmit Software Interface ................................................................................................... 85
3.1.2 Receive Software Interface .................................................................................................... 87
3.1.3 Descriptor Buffer Status/Control Fields .................................................................................. 89
3.2 Software Initiating and Using MCMAL ............................................................................................. 92
3.2.1 Initiating MCMAL .................................................................................................................... 92
3.2.2 Channel Reset ....................................................................................................................... 93
3.2.3 Soft Reset .............................................................................................................................. 93
3.2.4 Interrupts ................................................................................................................................ 94
3.2.5 Error Handling ........................................................................................................................ 94
3.3 Registers ....................................................................................................................................... 100
3.3.1 MCMAL Configuration Register ........................................................................................... 104
3.3.2 Channel_Active Registers .................................................................................................... 106
3.3.3 End of Buffer Interrupt Status Registers .............................................................................. 106
3.3.4 MCMAL Error Registers ....................................................................................................... 107
3.3.5 PLB TAttribute Registers ..................................................................................................... 111
3.3.6 MCMAL Channel Table Pointer Registers ........................................................................... 111
3.3.7 RX-Channel-Buffer-Size Registers ...................................................................................... 113
4. Hardware Interface .................................................................................................. 115

4.1 Pin List - MCMAL .......................................................................................................................... 115
4.1.1 MCMAL Timing Definition .................................................................................................... 115
4.1.2 MCMAL Functional Pins ...................................................................................................... 115
4.1.3 MCMAL LSSD Pins .............................................................................................................. 121
5. Core Integration ....................................................................................................... 123

5.1 Configurability ................................................................................................................................ 123
5.2 Initialization Sequence .................................................................................................................. 124
5.2.1 Setting MCMAL Configuration ............................................................................................. 124
5.2.2 Setting a Channel’s Specific Configuration .......................................................................... 124
SA14-2653-01
Page 4 of 132 March 13, 2007 - IBM Confidential
IBM Core Databook
5.2.3 Channel Activation ............................................................................................................... 124

5.3 Clocking Guidelines ...................................................................................................................... 125
5.4 Signal Specifications ..................................................................................................................... 125
5.4.1 MCMAL Inputs that should be Hardwired at the Chip level ................................................. 125
5.4.2 MCMAL Inputs Ignored by MCMAL Logic ........................................................................... 125
5.4.3 MCMAL Outputs that are Constant Driven .......................................................................... 125
5.4.4 Signals that Change Behavior Based on Utilization ............................................................ 126
5.4.5 Connecting the External LPRAs .......................................................................................... 128
5.5 Test Interface Requirements ......................................................................................................... 130
5.6 Physical Design Requirements ..................................................................................................... 130
5.7 Cell Names and Associated Library Elements .............................................................................. 130
5.8 Performance and Operating Environment ..................................................................................... 131
5.8.1 Power Estimation ................................................................................................................. 131
5.8.2 Size ...................................................................................................................................... 131
5.8.3 Voltages and Temperature Ranges ..................................................................................... 131
5.9 Main changes from SA-27E version .............................................................................................. 132
SA14-2653-01
Core Databook IBM
SA14-2653-01
IBM Core Databook
Preface
About this Book

This book describes the theory of operation, registers, interfaces, signals, timing specifications, core integra-
tion, clocking guidelines, testing and physical design requirements, and the performance and operating envi-
ronment of the MCMAL 8/32/64 DMA for Cu-11 and Cu-08.
Who Should Use this Book

This book is for hardware, software, and application developers who need to understand the MCMAL 8/32/64
DMA for Cu-11 and Cu-08.
Summary of Changes
Date Version Description Page
March 13, 2007 Revision 1 Removed ‘Preliminary’ designation and added ‘Cu-08’ to technologies. —
Added note “RA mode can be READ_WRITE mode” to Section 5.4.5 Connecting
July 16, 2002 Preliminary Copy 128
the External LPRAs.
February, 2002 Preliminary Copy Initial release. —
Notation Conventions
Unless otherwise specified, the notation used throughout this document is consistent with IBM/PowerPC®
processor family notation. These conventions include the following:
Term Description
byte Refers to an 8-bit entity.
halfword Refers to a 16-bit entity.
fullword Refers to 32-bit entity. Note that the McMAL uses the term fullword for OPB 32-bit entities.
word Refers to a 32-bit entity.
doubleword Refers to a 64-bit entity.
quadword Refers to a 128-bit entity. Note that the McMAL uses the term quadword for both PLB 128-bit enti-
ties and OPB 128-bit entities.
most significant bit (MSb) When describing multiple bit entities, bit 0 refers to the most significant bit (MSb).
least significant bit (LSb) When describing multiple bit entities, the highest numbered bit is the least significant bit (LSb).
most significant byte (MSB) When referring to halfword (16-bit) entities, byte 0 refers to the most significant byte (MSB) or the
high byte of the halfword. It is accessed at an even address location.
least significant byte (LSB) When referring to halfword (16-bit) entities, byte 1 refers to the least significant byte (LSB) of the
halfword, or the low byte. It is accessed at an odd address location.
SA14-2653-01 Preface
Core Databook IBM
Term Description
byte significance - 32-bit entities For 32-bit entities, the byte significance is from most significant to least significant as follows:
Byte 0 (MSB)
Byte 1
Byte 2
Byte 3 (LSB)
See Figure below for notation convention description.
byte significance- 64-bit entities For 64-bit entities, the byte significance is from most significant to least significant as follows:
Byte 0 (MSB)
Byte 1
Byte 2
.
.
.
Byte 7 (LSB)
byte significance- 128-bit entities For 128-bit entities, the byte significance is from most significant to least significant as follows:
Byte 0 (MSB)
Byte 1
Byte 2
.
.
.
Byte 15 (LSB)
Preface SA14-2653-01
IBM Core Databook
Notation Conventions
0 127
quadword 0 1 2 ............. 15
0 63
doubleword 0 1 2 ............. 7
0 31
fullword 0 1 2 3
0 15
0 1
halfword
0 7
byte
Terms and Abbreviations
Term Definition
Buffer Descriptor A memory structure which points to a set of memory locations that are used for packet data storage.
BD
Communication Macro A logic section dealing in wired communication. All such macros share several features: data is
(ComMac) either transmitted or received from the media, data buffering elements are used for storing oncom-
ing and outgoing data, data reception or transmission may be accomplished successfully or may
encounter errors.
Device Driver The software layer that abstracts the McMAL and ComMac hardware. Device driver software is exe-
cuted by the 4XX CPU.
FIFO First-In First-Out memory element. Memory elements can be of various sizes and are used for data
buffering.
OPB On-Chip Peripheral Bus. A second level bus used within the 4XX embedded processor architecture.
PLB PowerPC 4XX Local Bus. A first level bus used within the 4XX embedded processor architecture.
RX Receive. Refers to the direction of data flow; from the media to our application.
TX Transmit. Refers to the direction of data flow; from our application to the media.
Side Band Signals A set of signals which accompany a given protocol (for example, the OPB) and provide additional
information or control fields.
Packet A unit of data and control signals that is transmitted as a composite whole.
Descriptor A variable that defines the characteristics of a data object (located in the system memory).
Buffer A portion of storage (in the system memory) used to temporarily hold data input or output.
SA14-2653-01 Preface
Core Databook IBM
Term Definition
Buffer Descriptor pointer A data element (in McMAL hardware) that indicates the location of the current buffer descriptor pro-
cessed by McMAL.
Buffer Descriptor A table (in McMAL register space) that contains pointers to the base address of the buffer descriptor
pointer table pointers.
Preface SA14-2653-01
IBM Core Databook
1. Overview
1.1 Introduction
This document provides a general description, major hardware features, and programming information for the
MCMAL 8/32/64 DMA for Cu-11 and Cu-08 (MCMAL), a multi-channel memory access layer core.
1.1.1 General Description
The MCMAL is a data engine layer that handles the transfer of data between a packet-oriented communica-
tion macros (for example, Ethernet and HDLC) and the buffer descriptor (BD) memory structure. It can handle
up to 64 memory channels, thereby dealing with up to 64 service requests. MCMAL performs functions such
as arbitration between service requests, handling of the buffer descriptor memory structure, and updating the
descriptor status/control field at the end of packet transfer.
MCMAL handles the data structure for all communication macros (ComMacs). Each ComMac is an indepen-
dent OPB slave device that handles a specific communication protocol. MCMAL is a shared data mover, used
by all ComMacs in the system to handle the BD memory structure located on the PLB. In MCMAL- based
architecture, MCMAL handles the memory structure so the ComMacs are not required to be aware of the
memory structure. The memory itself is either on-chip memory which is accessed directly, or off-chip memory
which is accessed through an external bus interface unit.
MCMAL provides a common software-hardware interface for all communication macros through a unified
structure of: descriptors, data buffers, interrupt scheme, error handling, and configuration. This interface mini-
mizes software intervention in the flow of data between the memory and the communication media. As a
result, the processor load is significantly reduced and the bandwidth between communication macros and
memory is increased.
MCMAL contains an internal synchronization mechanism that enables the MCMAL to operate on a PLB and
an OPB running at different frequencies. The OPB must operate at integer (N) divisions of the PLB clock
(when N=1, 2, 3).
1.2 Features
• The protocol MCMAL uses to transfer data minimizes software intervention in packet oriented devices.
MCMAL is tuned for high bus utilization of both the OPB and PLB. These features join to increase system
throughput when serving a large number of channels.
• Because MCMAL handles the data transfer between the BD memory structure and the ComMacs, an
identical buffer descriptor structure can be used for Transmit (TX) and Receive (RX) data transfers by all
the channels in the system.
• MCMAL is tuned for communication protocols. It provides features dedicated to communication proto-
cols:
— Capability of sending commands from the SW applications to the ComMacs.
— Capability of sending packet status from the communication macros to the SW application for every
processed packet.
— Capability of retransmitting the same packet.
— Configurable interrupt per data buffer, for simple and efficient SW-HW synchronization.
SA14-2653-01 Overview
Core Databook IBM
• MCMAL allows generic software control access for:

— Configuration sequence
— Activation commands
— Deactivation commands
— Media status handling
• The protocol between MCMAL and ComMacs on the OPB is identical for all the ComMacs. As a result, a
generic module may be used to implement MCMAL in different ComMac designs.
1.2.1 Clocking Scheme
MCMAL contains an internal synchronization mechanism that enables the MCMAL to operate on a PLB and
an OPB running at different frequencies. The OPB operates at integer (N) divisions of the PLB clock (when
N=1, 2 and 3).
The PLB and OPB clock must share the same clock phase, which means that the PLB and OPB clocks are
synchronized within the normal tolerance between clock edges of the same clock in a given system.
Note that the MCMAL internal synchronization mechanism is designed to support any number of integer
(N) (even more than 3), but the MCMAL core is verified only when N=1, 2 and 3.
1.2.2 Detailed Characteristics
MCMAL provides the following detailed characteristics:
• Soft core synthesized to Cu-11 and Cu-08 technology.
• Up to 166 MHz PLB clock frequency.
• Up to 166 MHz OPB clock frequency.
• OPB clock can operate at integer (N) divisions of the PLB clock (when N=1, 2, 3).
• Supports various sizes of external linear programmable arrays (LPRA), to allow trade-off between cell
count, power consumption and internal data storage space.
• Serves up to 64 channels (32 receive channels and 32 transmit channels).
• Supports different configurations: 8, 32, or 64 channels (minimize core cell count if the full configuration is
not required).
• Several MCMALs may operate in parallel, using a shared arbitration scheme, to increase the number of
channels.
• Handles buffer descriptor memory structure.
• Scatter/gather capability using data buffers and buffer descriptor structures for each channel.
• Programmable receive buffer size (per channel).
• No limitations on buffer alignment.
• Maximum buffer size of 4095 bytes (TX) or 4080 bytes (RX).
• Up to 256 descriptors in a descriptor table (per channel).
Overview SA14-2653-01
132
IBM Core Databook
• No limitation on minimum transmit buffer size.
• Buffer-based interrupt capabilities per channel.
• Descriptor status field is updated at the end of packet transfer, according to the status received from the
communication macro.
• Supports ComMac’s “back-to-back TX status mechanism” to allow ComMac’s increase in performance.
• Configures the ComMac according to commands in the descriptor status/control field.
• Packet retransmission capability.
• Concurrent operation of receive and transmit channels.
• Three-level internal arbitration to prioritize access between all the communication macros.
• Master on the OPB (both the 32-bit version and the 128-bit extended version).
• Burst operation with no wait states on both the PLB and OPB.
• PLB/OPB error detection.
• Supports PLB Specification version 4.3

— 128-bit master on the PLB.
— Supports a full 36-bit address space.
— Simultaneous read and write over the PLB.
— Supports PLB Fixed Length Burst Protocol.
— Maximum PLB burst size of 4, 8 or 16 quadword for both read and write access.
— Supports PLB address pipeline.
— Programmable PLB arbitration priority.
— Supports three-cycle arbitration timing.
— Supports only 128-bit PLB slaves.
• Configuration through the DCR bus.
• Backward compliancy
— MCMAL provides the same SW interface as MadMAL in terms of data structure, interrupt scheme,
error handling, activation and deactivation flow, and configuration. MCMAL differs from MadMAL in
the configuration register. The MCMAL configuration register contains some new bits that support the
simultaneous PLB read and write access feature.
— MCMAL supports a full 36-bit address space. If it’s configured in the same way MadMAL was, it will
automatically pad the smaller address space with zeroes at the MSbs.
— MCMAL supports all communication cores previously supported by MadMAL.
Core Databook IBM
1.3 MCMAL - ComMac Structure

MCMAL, together with a ComMac, provides a complete solution for the communication controller core. The
memory data structure is completely handled by MCMAL. MCMAL is a shared logic which allows simplicity of
the communication cores attached to it. The functionality is divided between MCMAL and the ComMac as
described below.
1.3.1 Communication Core Specific Logic
The ComMac section is protocol specific and typically contains:
• A protocol specific logic layer.
• Data buffers (FIFOs) of various depths.
• Control and status registers.
• An OPB target logic layer.
1.3.2 Memory Access Layer
MCMAL is a generic section which may be used by all ComMacs and provides the following features:
• Buffer descriptor handling and bookkeeping.
• OPB and PLB master capability for ComMac data handling.
• Status information forwarding from ComMac to BD via OPB.
• Command per packet information from BD to ComMac via OPB.
• Frees ComMac from interrupt handling. Interrupts are driven by MCMAL at the end of a buffer or at the
end of a packet.
The MCMAL section enables the device driver to handle all ComMac requests in a uniform manner.
Each ComMac can be designed as an OPB target in an independent manner. In this way, the ComMac can
be activated via the MCMAL or as a stand-alone OPB target (depending on how the ComMac is imple-
mented).
1.4 Typical Application

Figure 1 on page 15 shows a typical application illustrating a general system structure of an embedded
PowerPC®, integrated with a packet oriented communication core.
132
IBM Core Databook
Figure 1. Typical Application
Off-chip
memory
Memory Other
SRAM CPU
cntrl PLB
devices
PLB
MCMAL Bridge
OPB OPB
Ethernet HDLC
macro macro Other
Configuration
OPB
devices
The ComMac is configured and controlled by the 4XX (processor) via the OPB (in this case the ComMac
serves as an OPB target) without MCMAL’s involvement.
The data to be transmitted/received resides in buffers, usually in external memory. The descriptors for the
data buffers can be located on-chip, according to performance considerations. The various ComMacs all
share the same buffer descriptor format.
MCMAL is responsible for processing the buffer descriptor memory structure and provides all memory access
facilities to ComMac.
Each ComMac OPB slave may contain more than one transmit or receive channel. Transmit (TX) and
Receive (RX) may be performed simultaneously (full duplex). MCMAL logic is not aware of the ComMac as
an entity. The entities handled by MCMAL are the ComMac’s channels. Each channel has to request MCMAL
service by asserting a service request to MCMAL’s internal arbiter. When a channel wins the arbitration the
data is transferred between the system memory and the ComMac. Each TX/RX channel has its own dedi-
cated buffer descriptor table. A given packet (transmit and receive) may be constructed from several data
buffers (this is known as buffer chaining).
Core Databook IBM
1.5 References
Table 1. Related Documents

Document Abbreviation Version Issue Date
MadMAL Functional Specification MadMal Specification 1.5 03/29/9
PowerPc 4XX Local Bus Specification PLB Specification 4.3 03/00
On-Chip Peripheral Bus: Architecture Specifications OPB Specification 1.4 04/99
Device Control Register Bus Architecture DCR Specification 2.0 11/12/98
Soft Core Design Guidelines for IBM ASIC Cores Soft Core Design Guidelines 2.30 15/11/99
1.6 Additional Required Elements

MCMAL uses four external and four internal LPRAs.
For additional information see <Ital>Chapter 5, “Core Integration,” on page 123.
1.7 Related IBM Cores

• Ethernet ComMacs:
— EMAC3, EMAC4
• HDLC ComMacs:
— HDLCML, HDLC32EX
• Buses:
— PLB4 Arbiter, OPB Arbiter
132
IBM Core Databook
2. Functional Description
2.1 Hardware Overview
2.1.1 MCMAL - Internal Structure
Figure 2 illustrates MCMAL’s internal structure. In this figure, MCMAL is connected to three ComMacs. Each
one includes two channels, one for transmit and one for receive.
Note: This partitioning is for the purpose of illustrating MCMAL’s internal structure. It does not represent the
actual design partitioning.
Figure 2. MCMAL’s Internal Structure
DCR PowerPC 4XX local bus (PLB)

configuration
bus
PLB
MCMAL
Register master
map file
ComMac ComMac
ComMac RX TX ComMac
TX channel
RXRX channel
RXComMac
channel TxComMac
channel
handler
RXComMac
channel
handler
Common Common TxComMac
handler
channel
handler
RX channel Channel Channel TX channel
handler
handler handler
handler
logic logic
RX Channels TX Channels
arbiter arbiter
OPB
master
On-Chip peripheral bus (OPB)
RX TX
ComMac #1 RX TX
ComMac #2 RX TX
ComMac #3
Sideband signals (not an integral part of the OPB)
In this figure, ComMac #1 and ComMac #2 have one transmit and one receive channel each.
ComMac #3 has two transmit channels and two receive channels.
2.1.1.1 PLB Master
The PLB Master can access the internal and external memory arrays, and performs PLB transactions for
MCMAL. It is used to transfer data between the ComMacs and memory, and fetch buffer descriptors.
SA14-2653-01 Functional Description

Core Databook IBM
2.1.1.2 OPB Master
The OPB Master performs OPB transactions for MCMAL. It is used to transfer data between the ComMacs
and memory.
2.1.1.3 TX Channel Handler
The ComMac TX channel handler is a dedicated section provided for each TX ComMac channel. It keeps a
record of the descriptor information and the current state of each channel.
2.1.1.4 RX Channel Handler
The ComMac RX channel handler is a dedicated section provided for each RX ComMac channel. It keeps a
record of the descriptor information and the current state of each channel.
2.1.1.5 TX Channels Arbiter
The TX channels arbiter gets request lines from each TX channel. It then arbitrates between the TX channels
and decides which TX channel will gain access to the TX common channel logic.
2.1.1.6 RX Channels Arbiter
The RX channels arbiter gets request lines from each RX channel. It then arbitrates between the RX chan-
nels and decides which RX channel will gain access to the RX common channel logic.
2.1.1.7 TX Common Channel Logic
The TX common channel logic section is shared by all TX channels. It handles a single TX channel at a time,
according to the TX arbiter’s decision. This section activates the PLB and OPB masters for data and buffer
descriptor transactions.
2.1.1.8 RX Common Channel Logic
The RX common channel logic section is shared by all RX channels. It handles a single RX channel at a time,
according to the RX channels arbiter’s decision. This section activates the PLB and OPB masters for data
and buffer descriptor transactions.
2.1.1.9 Register Map File
The register map file is used to configure MCMAL and read its status registers. The software accesses the
MCMAL register file through the DCR configuration bus (defined in the PLB Specification).
2.1.2 Usage of MCMAL - ComMac: Software Activation
In order to understand this proposed communication core structure, this section elaborates on how a core is
monitored and activated by its device driver software running on the CPU.
Functional Description SA14-2653-01

132
IBM Core Databook
The following is a list of software requirements for all communication core designs:
• Data flow management should be similar for all ComMacs (regardless of protocol).
— A similar software mechanism can be used for all protocols, allowing reuse of software modules.
— Data buffer from one core can be easily passed to a different core.
• Core activation, termination and configuration, should be similar for all ComMacs. The following actions
should have the same mechanism in all cores:
— Transferring commands to a core (for example: stop-transmit).
— Configuring a core (all cores have various operational modes that are configured via configuration
registers).
— Acquiring status information regarding the core’s activity on the media.
— Interrupt generation and handling, following various media events.
All of the above requirements have the following advantages:
• From a core user perspective, all cores have the same activation method. All cores have the same “look
and feel” regardless of their origin.
• From a core designer perspective, there is no need to redesign the MCMAL section for each core. The
designer can concentrate on the protocol-specific sections.
• All cores can share a common memory resource, allowing effective memory allocation.
The MCMAL architecture addresses these requirements through the buffer descriptor mechanism. Each
buffer descriptor contains the following:
• Pointer to the actual data buffer location (generally in external memory).
• The actual length of the given buffer.
• Status/control fields.
2.1.3 Transmit and Receive Operation
The device driver is responsible for configuring MCMAL before the ComMacs can begin requesting that
MCMAL process packets of data. There is no prohibition mechanism for ComMac activity.Therefore, the
device driver should ensure that channels are programmed not to perform any kind of transactions during the
reconfiguration, otherwise a fatal error may occur.
For additional information on MCMAL software interface see Section 3.2, Software Initiating and Using
MCMAL, on page 92.
Figure 3 on page 20 describes the software and hardware operations involved in a typical transmit operation.
Note: This figure describes only the basic TX flow. There is an advanced flow as well that is not supported by
all ComMacs. For more information see Section 2.4, Back-to-Back TX Status Mechanism, on page 55.

Core Databook IBM
Figure 3. Software and Hardware Interaction for Transmit Operation
Protocol
XMIT
stack
1
Packet 2
CPU 10
(activated via “device driver”)
5
7
PLB
11
3 MCMAL
12
4 6
OPB
9 7
ComMac
Network
The numbered steps are described as follows:
1. Protocol stack (high-level software layer) initiates a transmit packet.
2. Software parses protocol stack buffer into descriptor table and buffers.
3. Software instructs ComMac to process a new packet.
4. ComMac channel requests MCMAL to process a new packet.
5. MCMAL fetches descriptor information.
6. MCMAL writes control information into ComMac and initiates data move.
7. Packet data fetched from memory into ComMac, according to ComMac’s request
(ComMac controls the pace of the data transfer).
8. Packet transmitted on the media (steps 7 and 8 can overlap).
9. ComMac requests that MCMAL read packet status.
10. Status read by MCMAL and written into buffer descriptor.

11. Software interrupted (if interrupt conditions are met) by ComMac or by MCMAL End of
buffer interrupt.
12. Software clears interrupt status bits in ComMac.

132
IBM Core Databook
Figure 4 describes the software and hardware receive operations involved in a typical packet reception.
Figure 4. Software and Hardware Interaction for Receive Operation
Protocol stack
Packet 11
1
CPU
(activated via “device driver”)
5
9
8
PLB
10
2 MCMAL
12
4 6
OPB
9 7
ComMac
3
Network
The numbered steps are described as follows:
1. Software initializes Receive Buffer Descriptors.
2. Software enables ComMac to process a new packet.
3. A packet is received from the network (steps 2 and 3 can change in order).
4. ComMac channel instructs MCMAL to process a new packet.
5. MCMAL fetches receive buffer information.
6. MCMAL writes control word to ComMac and initiates data move.
7. The ComMac channel fills its FIFO storage.
8. MCMAL stores the packet in system memory buffer(s).
9. Status is read by MCMAL and written to buffer descriptor.
10. Software interrupted (if interrupt conditions are met) by ComMac.
11. Receive packet is passed to protocol stack.
12. Software clears the receive buffer descriptor positions.
Note: The description in Figure 3 on page 20 and Figure 4 above is a general scheme for MCMAL operation
in the software environment. The device driver should only follow the recommendations from Section 3.2,
Software Initiating and Using MCMAL, on page 92.

Core Databook IBM
2.2 ComMac-MCMAL Interface

The ComMac is an OPB slave which communicates with the PLB memory through MCMAL. The ComMac
requests service from MCMAL using special sideband signals, and receives information regarding different
events by means of sideband signals driven by MCMAL.
Each ComMac can be accessed from the OPB for two types of transactions (depending on the type of OPB
master):
• MCMAL Transactions - MCMAL, an OPB master controlling the bus, transfers information to and from
the ComMac (an OPB slave). During MCMAL transactions, control words can be written to the ComMac,
status words can be read from the ComMac, or data can be transferred between MCMAL and the Com-
Mac. On TX channels, the data is transferred from MCMAL to the ComMac, while on RX channels the
data is transferred from the ComMac to MCMAL.
— In these transactions, MCMAL uses sideband signals to select the ComMac, so in this case the Com-
Mac does not have to decode the OPB address. Aside from address decoding, MCMAL performs
transactions depending on the protocol defined by the OPB Specification.
• Configuration Transactions - The ComMac configuration is done by the PLB-OPB bridge with no
MCMAL involvement. The PLB-OPB bridge performs standard OPB transactions. This indicates MCMAL
sideband signals are not used, and the ComMac functions as a standard OPB slave while performing the
OPB address decoding. The configuration cycles are used to write and read the ComMac configuration
status and control registers.
— We recommend using two OPB buses, the first for data transactions - in which MCMAL will be the
only Master, and a second OPB for configurations.
The following is a list of the information passed between the ComMac and MCMAL on the sideband dialogue:
• ComMac request for service.
• Definition of the type of information transferred between the ComMac and MCMAL (command, status or
data).
• Channel select indications. MCMAL issues this information so the ComMac can identify which channel is
targeted by the transaction.
• End of packet transfer - used by either MCMAL (for TX channels) or by ComMac (for RX channels) to
indicate the end of packet transfer (including information on the number of bytes valid in the last data
transfer).
• Start and End indications - a set of signals issued by MCMAL and ComMac to indicate the beginning and
end of the packet’s data transfer and provide status updates between MCMAL and ComMac.
• Special indications from MCMAL such as invalid descriptor or transfer status done. These indications are
detailed in Section 2.2.4.8 , Descriptor Not Valid (in TX Interface Only), on page 30 and Section 2.2.4.4 ,
Status Done, on page 27.
All sidebands signals are clocked by the OPB clock domain and will therefore be treated as synchronous
signals between MCMAL and ComMac.

132
IBM Core Databook
2.2.1 32-Bit OPB/128-Bit OPB ComMacs
MCMAL supports both 32-bit OPB slaves and 128-bit extended OPB slaves.
In order to provide higher bandwidth capabilities, MCMAL supports, in addition to the standard 32-bit OPB, a
128-bit width extended OPB (EOPB).
The extended OPB protocol and architecture are derived from:

• - The OPB Specification.
• - The MadMAL - ComMac protocol.
This interface is used, for example, by the Emac4 core.
Section 2.2, ComMac-MCMAL Interface, on page 22, provides details on the sideband signals and the
ComMac-MCMAL protocol. Unless otherwise indicated, this section describes both 32-bit OPB ComMacs
and 128-bit OPB ComMacs.
Section 2.3, 128-Bit Extended OPB, on page 49 describes specific features and signal behavior of the EOPB.
2.2.2 ComMac-MCMAL Protocol
2.2.2.1 Packet Transfer Flow
The packet transfer flow consists of three phases. These three phases are used to define the details of the
ComMac-MCMAL protocol.
1. Frame Phase
• The ComMac initiates a packet transfer operation. The packet transfer is started by a command
write. The command contains two parts: MCMAL indications (six bits) and ComMac control (10 bits).
These two parts are defined in the Command/Status field in the descriptor that is located in the sys-
tem’s memory. Following the command write, MCMAL begins the data transfer, during which MCMAL
transfers data between the buffers located in the system’s memory and the ComMac. In TX channels,
the data is transferred from the system’s memory to the ComMac (OPB write), while in RX channels,
the data is transferred from the ComMac to the system’s memory buffers (OPB read).
• The channel remains in the frame phase until the data transfer has been completed or a ready status
can be returned to MCMAL. The frame phase ends when the ComMac deasserts the FRAME signal
associated with the related channel.
• The frame phase is defined by an active FRAME signal. For more information, see Section 2.2.4.2 ,
Frame, on page 26.
2. Status Phase
• This is the second phase of the packet transfer. Following the deassertion of the FRAME signal, the
channel goes into the status phase. At this stage, a request for service is interpreted by MCMAL as a
request for status read (this request will be served by MCMAL when the channel wins the MCMAL
internal arbitration).
3. Idle Phase
• The channel moves into the idle phase following a reset or after status was transferred (end of status
phase). During the idle phase, the ComMac cannot send any signals to MCMAL, nor can MCMAL
send any active signals to the ComMac. The ComMac exits the idle phase by asserting the FRAME
signal (and entering the frame phase described above).
Figure 5 on page 24 illustrates the different phases in the ComMac-MCMAL communication.

Core Databook IBM
Figure 5. ComMac-MCMAL Communication Phases
FRAME
Frame Status Idle Frame

phase phase phase phase
Command Data Status

write transfer read
During the frame phase and during the status phase, the ComMac signals a request for service by driving its
arbitration signal level to a non-idle level. For more information, see Section 2.2.4.3 , Arbitration Level, on
page 26.
2.2.3 MCMAL Burst Length
The burst length is the number of data words (quadwords for EOPB) that is being transferred between
MCMAL and each ComMac channel on each request for service (for instance, a single transaction in one
arbitration cycle), which is not the last data request. The burst length for each channel is defined by a 3-bit
bus driven at the chip level with each bus named, one for TX_MAL_BURST_LENGTH and one for
RX_MAL_BURST_LENGTH (see Table 2 on page 25).
2.2.3.1 TX_MAL_BURST_LENGTH and RX_MAL_BURST_LENGTH Signals
The burst length signal names are:

TX_MAL_BURST_LENGTH0[0:31],
RX_MAL_BURST_LENGTH0[0:31],
RX_MAL_BURST_LENGTH1[0:31] and
RX_MAL_BURST_LENGTH2[0:31].
The TX_MAL_BURST_LENGTH and RX_MAL_BURST_LENGTH signals should be hardwired at the chip

level. The values of these signals define the burst length as one of seven options: 2, 4, 8,16, 32, 64, 128
words.

132
IBM Core Databook
Table 2. TX/RX_MAL_BURST_LENGTH Values

Supports Slave Supports LPRA
Number of 32-bit Slave 128-bit RA008x64D2P2W1R1M1 RA016x64D2P2W1R1M1 RA032x64D2P2W1R1M1
Bus Value
Words Slave
(EOPB)
000 2 Yes No Yes Yes Yes
001 4 Yes No Yes Yes Yes
010 8 Yes Yes Yes Yes Yes

101 64 Yes Yes No Yes Yes
110 128 Yes Yes No No Yes
111 Reserved No No No No No
Note: In order to avoid Rx under-runs the channel’s burst length must be smaller or equal to the ComMac’s receive low water mark.
Note: The values chosen for every channel must not be greater than the data buffer chosen (the external LPRAs).
A ComMac channel is committed for a transfer of the number of words specified by the burst length value
(unless it is the last data transaction in the packet).
2.2.4 ComMac-MCMAL Sideband Signal Naming Convention and Description
Table 3 shows naming conventions used for ComMac-MCMAL interface signals.
Table 3. ComMac-MCMAL Signal Naming Convention

Prefix Source Explanation
MAL_ MCMAL A signal common to all ComMac channels (TX and RX)
MAL_TX_ MCMAL A signal generated by a certain MCMAL TX/RX channel handler and is received by its
or matching ComMac channel.
MAL_RX_
COM_TX_ ComMac TX/RX A signal generated by a certain ComMac TX/RX channel and is received by its matching
or channel MCMAL channel handler.
COM_RX_
The ComMac-MCMAL interface is bus-format organized. All signals that are inputs or outputs of each one of
the ComMacs, are gathered into RX and TX buses. Each ComMac sideband signal should be connected
(during the stage of system integration) to the appropriate bit in its matching bus, according to the number of
channels. For example, the COM_RX_FRAME signal of channel RX5 should be connected to bit number 5 of
the MCMAL input bus COM_RX_FRAME.
Note: In the following descriptions, Signal_name_Bus[x] refers to the related sideband signal of channel x.
For example, MAL_TX_DSCR_NOT_VALID[x] (bit x of MAL_TX_DSCR_NOT_VALID MCMAL output bus),
refers to MAL_T[x]_DSCR_NOT_VALID signal of TX channel x.
OPB devices (slaves or masters), that are not connected to MCMAL as active ComMacs, have no interest in
these signals (except for the OPB address bus), and therefore should not be connected at all to these signals.

Core Databook IBM
2.2.4.1 Active
Signal name:
MAL_ACTIVE
This signal is issued by MCMAL to all ComMacs. It indicates that the current OPB transaction is initiated by
MCMAL for application to one of the ComMacs. MAL_ACTIVE is asserted throughout the OPB transaction
(as long as MAL_OPB_SELECT is asserted). When MCMAL asserts the MAL_ACTIVE signal, each
ComMac should monitor its Channel_Select signal to determine if it is the target of the current MCMAL trans-
action. During the same cycle, the ComMac should identify the type of operation to be performed, by
decoding the 3 least significant bits (LSbs) of the OPB address bus. For more information, see Section
2.2.4.6 , OPB Address Bus, on page 28 and Section 2.2.4.5 , Channel Select, on page 28.
2.2.4.2 Frame
Signal name:
COM_TX_FRAME[0:31]
COM_RX_FRAME[0:31]
FRAME is asserted in order to initiate a packet transfer and remains asserted until the packet transfer is
completed (during the frame phase).
FRAME may be asserted at any time during the idle phase (following system reset or after STATUS_DONE
was asserted).
FRAME is normally deasserted following the last data transfer. It may be deasserted in the case of early
packet termination (for more information see Section 2.2.5.4 , TX Early Packet Termination Initiated by
ComMac, on page 35 and Section 2.2.6.3 , RX Early Packet Termination Initiated by ComMac, on page 38)
or TX descriptor not valid (see Section 2.2.4.8 , Descriptor Not Valid (in TX Interface Only), on page 30). In
these cases the ComMac may deassert FRAME (the signal is sampled as deasserted by MCMAL) only
during one of the following timing cycles:
• Any cycle following the initial command write by MCMAL to ComMac.
• The cycle following the one in which ComMac sampled the active MAL_TX_DSCR_NOT_VALID[x] sig-
nal.
2.2.4.3 Arbitration Level
Signal names:
COM_TX_ARB_LEVEL0[0:31] / COM_TX_ARB_LEVEL1[0:31]
COM_RX_ARB_LEVEL0[0:31] / COM_RX_ARB_LEVEL1[0:31]
The arbitration level is a 2-bit bus driven by each ComMac channel to MCMAL. The arbitration level is used to
indicate a channel’s request for service. The request for service can be one of two types:
• A request for data transfer (or initiation of data transfer at the beginning of a packet transfer). This type
of request is activated during the frame phase, (for instance, alongside the FRAME signal, see Section
2.2.2.1 , Packet Transfer Flow, on page 23). The ComMac channel may assert the request or change an
asserted request to a more urgent one at any time. It may withdraw its request or change it to a less

132
IBM Core Databook
urgent one only when MAL_ACTIVE is asserted and that channel is being selected (the appropriate
CHANNEL_SELECT signal is active), or when it switches to the status phase.
• A request for status transfer at the end of a packet transfer operation. This type of request is activated
during the status phase (see Section 2.2.2.1 , Packet Transfer Flow, on page 23). This request is
asserted only once (since only one word read is performed), and in this case the ComMac, may not with-
draw its request. However, it may assert the request or change an asserted request to a more urgent one
at any time. It may change it to a less urgent one only when MAL_ACTIVE is asserted. Also, once status
has been read from it, and only then, the ComMac must deassert the request.
ARB_LEVEL has the following values [0:1]. One level is considered idle while all other levels of arbitration are
considered a request for service. The values in order of urgency, are:
• ‘00’ - Idle. ComMac has no need for additional data.
• ‘01’ - Low priority request. This is a “moderate” request.
• ‘10’ - High priority request. This is a higher level request then the Low priority request.
• ‘11’ - Urgent request. The ComMac urgently needs additional data. Normally, this indication is used when
a packet is about to be underrun (in TX channel) or overrun (in RX channel). Urgent requests are not con-
sidered normal events. It is recommended that this request priority will be used only in order to avoid
errors.
The number of words that will be fetched by MCMAL, as a result of any service request, no matter what the
level of the request is, will be the number of burst length words as defined by the
RX/TX_MAL_BURST_LENGTH signals. MCMAL fetches less than this amount of burst length words only in
the case of end of packet. Once a ComMac channel has asserted a service request, it is committed for a
transfer of at least the number of words defined by the burst length.
For further information on how MCMAL channel arbitration is implemented, see Section 2.7, MCMAL Arbitra-
tion Between ComMac Channels, on page 63.
The following information indicates the MCMAL input arbitration-related signal interconnections:
COM_TX_ARB_LEVEL0[0:31]:
• This MCMAL input bus is connected to the COM_T[x]_ARB_LEVEL[0] bit, of all TX channels
COM_TX_ARB_LEVEL1[0:31]:
• This MCMAL input bus is connected to the COM_T[x]_ARB_LEVEL[1] bit, of all TX channels.
COM_RX_ARB_LEVEL0[0:31]:
• This MCMAL input bus is connected to the COM_R[x]_ARB_LEVEL[0] bit, of all TX channels.
COM_RX_ARB_LEVEL1[0:31]:
• This MCMAL input bus is connected to the COM_R[x]_ARB_LEVEL[1] bit, of all TX channels.
2.2.4.4 Status Done
Signal names:
MAL_TX_STATUS_DONE[0:31]
MAL_RX_STATUS_DONE[0:31]

Core Databook IBM
MCMAL uses these signals to indicate that the status halfword it had read from the ComMac was written to
memory (memory write completed). ComMac can use these signals to synchronize the activation of an inter-
rupt with the end of packet reception. This “ordering” may be used to prevent the processor from accessing
the memory until the status is updated in memory.
ComMac may initiate a new packet transfer (entering a new frame phase) only after the STATUS_DONE indi-
cation was accepted. If there are no new requests, the ComMac-MCMAL interface of the related channel
reenters the idle phase.
These signals are asserted for a single clock cycle.
2.2.4.5 Channel Select
Signal names:
MAL_TX_CHANNEL_SELECT[0:31]
MAL_RX_CHANNEL_SELECT[0:31]
These signals are used by the ComMac to identify the selected channel during MCMAL transactions, and are
applied to the ComMac. When ComMac detects an asserted MAL_ACTIVE, it monitors its
CHANNEL_SELECT signals. If the CHANNEL_SELECT signal is asserted when MAL_ACTIVE is asserted,
then the specific channel is selected (for example, the selected mechanism inside each channel is imple-
mented by a logical ‘AND’ of MAL_ACTIVE and CHANNEL_SELECT).
The CHANNEL_SELECT signal is valid just when MAL_ACTIVE is asserted.
2.2.4.6 OPB Address Bus
Signal name:
MAL_OPB_ABUS
During MCMAL transactions applied to a ComMac, (the MAL_ACTIVE signal is asserted), all ComMacs must
decode OPB address bits 29 to 31 in order to identify the type of operation.
ComMacs that don’t use the CHANNEL_SELECT signal, must decode (when MAL_ACTIVE signal is
asserted) the OPB address bits 24 to 28 in order to identify the selected channel.
MCMAL drives the 24 most significant bits (MSbs) of the OPB to a value defined as “MCMAL OPB high
address” which defines the MCMAL space on the OPB. This allows the use of a ComMac-MCMAL address
space on the OPB which is not allocated as an address space to any other OPB slave. Care must be taken to
prevent other OPB targets, (not activated via MCMAL), from responding on the OPB (based on an OPB
address match during a MCMAL ComMac transaction).
OPB address bits 0 to 23:
• While driving the OPB address bus for ComMac transactions, MCMAL uses its HIGH_OPB_ADDRESS
hardwired input value (24 bits) to drive bits 0 to 23 of the OPB address bus.
• The OPB address bits 24 to 28 are used to decode a MCMAL access by the ComMac. A ComMac that
uses the CHANNEL_SELECT signal, in order to decode MCMAL access, should ignore these bits.

132
IBM Core Databook
These bits indicate the number of the addressed channel, or the channel number they represent:
• “00000” to “01110” represent the 15 TX channels (0 to 14, respectively).
• “10000” to “11110” represent the 15 RX channels (0 to 14 respectively).
Note: These bits support identification of TX channels 0 to 14 and RX channels 0 to 14. Only 30 channels
that don’t use the CHANNEL_SELECT signal can be connected to MCMAL.
• These three bits of the OPB address contain different information depending on whether a TX or RX
channel is being addressed.
While addressing a ComMac channel, bits 29 to 31 are used to indicate the values shown in Table 4.
Table 4. OPB Address Bits 29 to 31 - Values

Bit Value Channel Value
[29,30,31] Addressed
000 RX Indicates control or status transaction. MCMAL is either writing a control halfword to ComMac or
reading a status halfword from ComMac. It applies to both 32-bit slaves and 128-bit slaves.
001 RX MCMAL is reading packet data from the RX FIFO and into memory. It applies to both 32-bit slaves
and 128-bit slaves.
010 RX Reserved
011 RX Reserved
100 RX Reserved
101 RX Reserved
011 RX Reserved
111 RX Reserved
000 TX Indicates control or status transaction. MCMAL is either writing a control halfword to ComMac or
reading a status halfword from it. It applies to both 32-bit slaves and 128-bit slaves.
001 TX Indicates packet data, excluding the last word transfer. It applies to both 32-bit slaves and 128-bit
slaves.
010 TX Indicates last data transfer for 128-bit slaves. (for more details see Section 2.3, 128-Bit Extended
OPB, on page 49).
011 TX Indicates last data transfer, and there is no valid packet data-null transaction.
This option is used to transfer an empty packet. It is used with 32-bit slaves only.
100 TX Indicates last data transfer, and all four bytes contain valid packet data. It is used with 32-bit slaves
only.
101 TX Indicates last data transfer, and only bits 0 to 7 contain valid packet data. It is used with 32-bit slaves
only.
110 TX Indicates last data transfer, and only bits 0 to 15 contain valid packet data. It is used with 32-bit
slaves only.
111 TX Indicates last data transfer, and only bits 0 to 23 contain valid packet data. It is used with 32-bit
slaves only.

Core Databook IBM
2.2.4.7 Descriptor Error
Signal names:
MAL_TX_DSC_ERR[0:31]
MAL_RX_DSC_ERR[0:31]
MCMAL uses these signals to indicate a channel descriptor error. Following the assertion of the descriptor
error indication, MCMAL deactivates the corrupted channel and asserts an interrupt towards the SW. For
more details see Section 3.1.1.4 , Descriptor Not Valid/Descriptor Error for Transmit, on page 86 and Section
3.1.2.3 , Descriptor Error For Receive, on page 88. The descriptor error indication may be used by the
ComMac for better error resolution.
These signals are asserted for a single clock cycle.
2.2.4.8 Descriptor Not Valid (in TX Interface Only)
Signal name:
MAL_TX_DSCR_NOT_VALID[0:31]
MCMAL uses this signal to indicate that the new packet to be transmitted for the currently active channel is
not ready in memory. MCMAL determines whether the packet is ready or not by reading the READY bit of the
first buffer descriptor of the packet (the buffer descriptor bits are detailed in Section 3.1.3.3 , Status/Control
Field Format, on page 89), and by checking if the current transmitted packet is a retransmitted packet. If the
READY bit is clear (‘0’) and the packet is not a retransmission, then MCMAL asserts the descriptor not valid
indication.
Following the assertion of the descriptor not valid indication, MCMAL ends the service of the current channel
and starts to serve the next channel in the arbitration queue. The ComMac can either ‘give up’ the packet and
complete the handshake with MCMAL, or continue polling MCMAL until the packet will be ready (see Section
2.2.5.5 , TX Descriptor Not Valid and TX Descriptor Error, on page 35.) The TX Descriptor Not Valid signal is
asserted for a single clock cycle.
2.2.4.9 Last Data (in RX Interface Only)
Signal name:
COM_RX_LAST_DATA[0:31]
ComMac’s receive channel asserts this signal alongside the last data transfer acknowledge of a packet. This
signal is used by MCMAL to end the current packet data read. Once this indication is detected by MCMAL, it
terminates the OPB burst (if one was in progress) and treats the data presented on the bus as the last data
transfer of the current packet.
ComMac deasserts the FRAME signal along with the deassertion of the LAST_DATA signal.
The number of valid bytes in the last data transfer is signaled by the last data byte enable bus signal
(COM_RX_LAST_DATA_BE) or by the null transfer signal (COM_RX_NULL_TRANSFER).

132
IBM Core Databook
2.2.4.10 Last Data Byte Enable (in RX Interface Only)
Signal names:
COM_RX_LAST_DATA_BE0[0:31]
COM_RX_LAST_DATA_BE1[0:31]
Since MCMAL only performs fullword read transactions from ComMac, ComMac provides this 2-bit bus to
indicate how many valid bytes are contained in the last word. MCMAL samples this signal on the assertion of
COM_RX_LAST_DATA[x]. MCMAL ignores the data of the invalid bytes.
LAST_DATA_BE has the following values [0:1]:
• ‘00’ - all four bytes contain valid packet data.
• ‘01’ - only bits 0 to 7 contain valid packet data.
ComMac drives this bus during the same cycles in which it drives the transfer acknowledge (XFERACK) on
the OPB.
The ComMac RX last data signal lines are linked as follows:
COM_RX_LAST_DATA_BE0[0:31]:
• This MCMAL input bus is connected to COM_R[x]_LAST_DATA_BE[0] bit, of all RX channels.
COM_RX_LAST_DATA_BE1[0:31]:
• This MCMAL input bus is connected to COM_R[x]_LAST_DATA_BE[1] bit, of all RX channels.
2.2.4.11 Null Transfer (in RX Interface Only)
Signal name:
COM_RX_NULL_TRANSFER[0:31] (optional signal)
This signal is asserted when the data transfer does not include any valid data bytes. This signal should be
asserted only during the last data transfer, when COM_RX_LAST_DATA[x] is asserted.This signal may be
used to transfer empty packets.
A ComMac which doesn’t transfer zero length received packets, does not support this signal in its interface.
In this case, the related input to MCMAL must be connected to a constant value of zero.
ComMac drives this signal during the same cycles in which it drives the transfer acknowledge (XFERACK) on
the OPB.
2.2.4.12 ComMac-MCMAL TX Sideband Signal Summary
Figure 6 on page 32 illustrates the sideband signals used by MCMAL (the TX channel handler) and a single
TX ComMac channel.

Core Databook IBM
Figure 6. ComMac-MCMAL TX Sideband Signal
OPB address bus
32 29-31: Status/Data transfer

24-28: Channel identification
COM_TX_ARB_LEVEL0/1[x]
2 ComMac
MCMAL COM_TX_FRAME[x] TX
channel
MAL_TX_DSC_ERR[x]
MAL_TX_STATUS_DONE[x]
MAL_TX_DSCR_NOT_VALID[x]
MAL_TX_CHANNEL_SELECT[x]
MAL_ACTIVE To all ComMacs
2.2.4.13 ComMac-MCMAL RX Sideband Signal Description Summary
Figure 7 illustrates the sideband signals used by MCMAL (the RX channel handler) and a single RX ComMac
channel.
Figure 7. ComMac-MCMAL RX Sideband Signal
OPB address bus

32 29-31: Status/data transfer
24-28: Channel identification
2 COM_RX_ARB_LEVEL0/1[x]
COM_RX_LAST_DATA[x]
MCMAL COM_RX_LAST_DATA_BE0/1[x] ComMac
2
COM_RX_FRAME[x]
COM_RX_NULL_TRANSFER[x]
MAL_RX_DSC_ERR[x]
MAL_RX_STATUS_DONE[x]
MAL_RX_CHANNEL_SELECT[x]
MAL_ACTIVE To all ComMacs

132
IBM Core Databook
2.2.5 ComMac-MCMAL TX Packet Transfer Flow
2.2.5.1 Overview
The following sections describe the protocol for packet transfer (command data and status) between MCMAL
and the ComMacs. This protocol is based on the OPB protocol along with some additional sideband signals
required for ComMac-MCMAL cooperation. The text deals mainly with the description of the sideband
signals. Unless specified otherwise, all the OPB signals operate in the manner described by the OPB Specifi-
cation.
2.2.5.2 Normal Operation
As described in Section 2.2.2.1 , Packet Transfer Flow, on page 23, packet transmission starts in the frame
phase. ComMac asserts the COM_TX_FRAME[x] signal and asserts the COM_TX_ARB_LEVEL bus to a
request level (non-idle). These actions cause the channel to participate in the MCMAL internal arbitration.
When a channel wins the arbitration (internal to MCMAL), MCMAL reads the first descriptor word from the
memory and writes the Status/Control halfword into the ComMac through an OPB write transaction as
follows:
• MCMAL requests arbitration on the OPB (asserting MAL_OPB_REQ).
Note: In case MCMAL is the only OPB master (MCMAL parks on the OPB), there is no need for asserting
MAL_OPB_REQ.
• When it is granted arbitration by the bus, MCMAL initiates a standard OPB transaction.
• MCMAL asserts the MAL_ACTIVE signal (applied to all the ComMacs) during the assertion of
MAL_SELECT signal. The ComMac uses MAL_ACTIVE to indicate that the current OPB transaction is a
MCMAL transaction.
• During MCMAL transactions (MAL_ACTIVE is asserted), the CHANNEL_SELECT signal is used for
selecting the current channel, and MAL_OPB_ABUS [29:31] is used for transaction qualifiers. MCMAL
activates the current channel’s MAL_TX_CHANNEL_SELECT[x] and drives ‘000’ on OPB address bits
29 to 31 (indicating control halfword rather than data).
Note: All Status/Control transactions are word transactions. Valid data is presented on bits 0 to 15 of the
OPB. Bits 16 to 31 are driven low.
ComMac uses the control halfword for the packet transmission configuration.This is dependent on the
ComMac implementation.
Note: In the following description “TX_MAL_BURST_LENGTH” value is referred also as a Data Segment.
Following the control halfword, MCMAL fetches data segments from memory and writes them to ComMac.
The process described below is used whenever MCMAL fetches data and drives it to a ComMac’s channel.
MCMAL writes the data through an OPB write transaction as follows:
• When it is granted use of the bus, MCMAL initiates a standard OPB write transaction.
• MCMAL asserts the MAL_ACTIVE signal during the assertion of MAL_SELECT signal. ComMac uses
MAL_ACTIVE to indicate that the current OPB transaction is a MCMAL transaction.

Core Databook IBM
selecting the current channel, and MAL_OPB_ABUS [29:31] is used for transaction qualifiers. MCMAL
activates the current channel’s MAL_TX_CHANNEL_SELECT[x] and drives ‘001’ on OPB address bits
29 to 31 (indicating data write transfer).
In order to request MCMAL service for additional data segment words fetches, channels have to assert the
COM_TX_ARB_LEVEL bus to a request level. If ComMac’s current channel does not need additional data, or
is not able to get additional data from MCMAL, it may not make a request for service.
A ComMac may withdraw its request for service only when MAL_ACTIVE is asserted. If the ComMac channel
did not request service, it may assert the request at any time. For further information about request level
manipulation see Section 2.2.4.3 , Arbitration Level, on page 26.
The data to be transmitted will be aligned by MCMAL. All of MCMAL’s data transfers will be word OPB trans-
actions. A ComMac can control the pace of the data prefetch rate by changing the COM_TX_ARB_LEVEL.
Normally, it uses the “low priority” request. If the ComMac’s channel is about to be underrun, it should use the
“urgent request” as needed so that additional data will be provided by MCMAL in due time for media transmis-
sion.
2.2.5.3 Packet Ending
Throughout the data prefetching phase, MCMAL indicates that all bytes within the word contain valid data by
driving ‘001’ on OPB address bits 29 to 31.
On the last data transfer of the given packet, the value of the three least significant OPB address bits reflects
the number of valid bytes within the last word transaction (Section 2.2.4.6 , OPB Address Bus, on page 28).
ComMac uses this indication to mark the current entry as the last one in the current packet and to mark the
valid bytes within the last data transfer.
ComMac, once it detects the last data transfer, deasserts COM_TX_FRAME[x] in the cycle following the
assertion of the matching OPB_xferAck (last cycle of asserted MAL_ACTIVE). If the ComMac doesn’t have a
ready status at that time, it must drop its COM_TX_ARB_LEVEL to zero.
When COM_TX_FRAME[x] is deasserted, the channel enters the status phase. Assertion of a request for
service means that the ComMac channel has a valid packet status to be transferred to the packet’s last
descriptor in the memory. The ComMac TX channel must end every packet processing by a status transfer to
MCMAL (“status phase”).
Following the request for service during the status phase, the channel enters MCMAL’s internal arbitration.
When the channel has won the arbitration, MCMAL reads the status from the ComMac’s channel by an OPB
read transaction as follows:
Note: In the case that MCMAL is the only OPB master, and the OPB Arbiter parks on MCMAL, there is no
need for asserting MAL_OPB_REQ.
• When it is granted by the bus, MCMAL initiates a standard OPB transaction.
selecting the current channel and MAL_OPB_ABUS [29:31] is used for transaction qualifiers. MCMAL

132
IBM Core Databook
activates the current channel’s MAL_TX_CHANNEL_SELECT[x] signal and drives ‘000’ on OPB address
bits 29 to 31 (indicating status read transfer).
• MCMAL then writes the status register value upwards to memory (PLB transaction).
• Once the status halfword is written into memory, MCMAL asserts a MAL_TX_STATUS_DONE[x] side-
band signal.
Note: All Status/Control transactions are word transactions. Valid data will be presented on bits 0 to 15 of the
OPB with bits 16 to 31 driven low.
Once ComMac detects MAL_TX_STATUS_DONE[x] it can issue an interrupt (related to the packet transmis-
sion, if needed) and instruct MCMAL to proceed to the next packet (by reassertion of COM_TX_FRAME[x]).
ComMac must wait for MAL_TX_STATUS_DONE[x] before activating MCMAL for the next packet.
2.2.5.4 TX Early Packet Termination Initiated by ComMac
A TX ComMac can initiate an early packet termination, whereby it terminates the packet transmission before
MCMAL finishes transferring all the packet’s data from memory to the TX ComMac. This is typically used
when error conditions force the ComMac to abort the transmission.
Whenever a ComMac deasserts COM_TX_FRAME[x] before MCMAL indicates the transfer of the last packet
data segment, ComMac asks MCMAL to read the packet’s status and to end the transmission.
In the case of “descriptor not valid” the status written by the ComMac is not transmitted back to the descriptor
in the memory. The status transferred to MCMAL is used only as an end of packet qualifier.
A ComMac is not allowed to initiate such termination before the end of the packet transmission initiation.
ComMac is allowed to deassert its COM_TX_FRAME[x] only after MCMAL has written the control halfword to
the ComMac, or after the MCMAL asserted the MAL_TX_DSCR_NOT_VALID[x] signal.
2.2.5.5 TX Descriptor Not Valid and TX Descriptor Error
MCMAL accesses a new descriptor in memory in order to continue (or start) serving a ComMac’s channel
request for data transfer. MCMAL first examines the Ready bit (for a TX channel) in the descriptor in order to
check that the descriptor is valid. When the Ready bit is not set, it can be caused by one of two reasons:
either the device driver did not prepare a new buffer descriptor and MCMAL must stop processing the packet,
or the current transmitted packet is a retransmission. In this case, although the READY bit is not set, the
descriptor is valid and MCMAL can process it. There are two different cases of non-available descriptors
depending on the location of the non-available descriptor:
• The non-available descriptor is not the first one in the packet (Command was already written to the Com-
Mac).
• The non-available descriptor is the first one in the packet (Command was not transferred to the Com-
Mac).
The first case is considered an error by MCMAL - Descriptor Error. MCMAL disables the ComMac channel
within itself and may announce the software by a non-masked interrupt that a descriptor error has occurred
(see Section 3.2.5.2 , Error Detection, on page 94). MCMAL also informs the ComMac that Descriptor Error
has occurred by asserting MAL_TX_DSC_ERR[x] for a single clock cycle.

Core Databook IBM
In the second case, MCMAL informs ComMac that the descriptor is not available by asserting
MAL_TX_DSCR_NOT_VALID[x] for a single clock cycle. ComMac has two options to react to this:
1. ‘Give up’ the packet and complete the handshake with MCMAL, causing an early termination scenario by
deasserting the COM_TX_FRAME on the following cycle. In this case the ComMac must drop the
ARB_LEVEL signal to zero, in addition to the deassertion of the FRAME signal (see Section 2.2.5.4 , TX
Early Packet Termination Initiated by ComMac, on page 35).
2. Continue polling MCMAL until the packet will be ready in memory. In this case MCMAL will check the
descriptor each time the ComMac channel gains MCMAL arbitration. ‘Continue polling’ means that the
COM_TX_FRAME remains active and the TX_ARB_LEVEL signal may be either:
• Dropped to zero at the following cycle (no service request) and later reasserted for requesting service
again.
• Held in a non-zero value (request for service).
2.2.6 ComMac-MCMAL RX Packet Transfer Flow
2.2.6.1 Normal Operation
As described in Section 2.2.2.1 , Packet Transfer Flow, on page 23, packet reception starts in the frame
phase. A ComMac asserts the COM_RX_FRAME[x] signal, and asserts COM_RX_ARB_LEVEL bus to a
request level (non-idle). These actions cause the channel to participate in MCMAL internal arbitration. When
a channel wins the arbitration, MCMAL reads the first descriptor word from the memory and writes the
Status/Control halfword into the ComMac through an OPB write transaction as follows:
• MCMAL asserts the MAL_ACTIVE signal during the assertion of the MAL_SELECT signal. ComMac
uses MAL_ACTIVE to indicate that the current OPB transaction is a MCMAL transaction.
selecting the current channel and MAL_OPB_ABUS [29:31]are used for transaction qualifiers. MCMAL
activates the current channel’s MAL_RX_CHANNEL_SELECT[x] and drives ‘000’ on OPB address bits
29 to 31 (indicating control halfword rather than data).
Note: All Status/Control transactions are word transactions. Valid data is presented on bits 0 to 15 of the
OPB and bits 16 to 31 are driven low.
Note: In the following description, “RX_MAL_BURST_LENGTH” value is also referred to as a data segment.
Following the control halfword, MCMAL fetches data segments from the ComMac receive channel and trans-
fers the data to memory. The process described below is used whenever MCMAL fetches data from
ComMac’s channel and transfers it to memory. MCMAL reads the data through an OPB read transaction as
follows:

132
IBM Core Databook
• When it is granted by the bus, MCMAL initiates a standard OPB read transaction.
selecting the current channel, and MAL_OPB_ABUS[29:31] is used for transaction qualifiers. MCMAL
29 to 31 (indicating data read transfer).
In order to request MCMAL service for additional data segment fetch, the channel must assert
COM_RX_ARB_LEVEL bus to a request level. If the ComMac’s channel does not currently have an addi-
tional data segment (as indicated by the RX_MAL_BURST_LENGTH signal or end of packet) to be trans-
ferred to MCMAL, it must not send a request for service. ComMac may withdraw its request for service only
when MAL_ACTIVE is asserted. If the ComMac channel is not requesting service, it may assert the request
at any time.For further information about request level manipulation, see Section 2.2.4.3 , Arbitration Level,
on page 26.
The data to be driven by the ComMac must be aligned (all bytes on the fullword are valid, unless it is the end
of the packet). All read requests from MCMAL are fullword transactions. ComMac must respond as a fullword
device. ComMac can pace the data prefetch rate by changing the COM_RX_ARB_LEVEL. Normally, it uses
the “low priority” request. If the ComMac’s channel is about to be overrun, it should use the “urgent request”
to increase its service priority in MCMAL internal arbitration.
2.2.6.2 Last Data Transfer Signaling
As the last data entry is read out of the ComMac’s FIFO, the ComMac asserts COM_RX_LAST_DATA[x] and
drives COM_RX_LAST_DATA_BE to a valid value on the same cycle on which the transfer acknowledge
signal (xferAck) is asserted. In this manner, MCMAL always performs word OPB read transactions (even if
the last data transfer for the given packet does not contain all four bytes). If the last data transfer has no valid
data whatsoever, ComMac must assert COM_RX_NULL_TRANSFER[x].
Note: A ComMac may use COM_RX_NULL_TRANSFER[x] only during the last data transfer. Any data
transfer transaction can be the last data transfer, therefore it can be used to generate a null packet transfer.
Once the last data word is transferred, ComMac must deassert its COM_RX_FRAME[x] in the cycle following
the assertion of the matching OPB_xferAck. If ComMac doesn’t have a ready status to be transferred, it must
drop its COM_RX_ARB_LEVEL to zero.
At the deassertion of COM_RX_FRAME[x], the channel enters the status phase. Assertion of a request for
service means that the ComMac channel has a valid packet status to be transferred to the packet’s last
descriptor in the memory. The ComMac RX channel must end every packet processing by a status transfer to
MCMAL.
When the channel has won the arbitration, MCMAL reads the status from the ComMac’s channel through an
OPB read transaction (in the same process as for TX channels):

Core Databook IBM
• When it is granted use of the bus, MCMAL initiates a standard OPB transaction.
• MCMAL asserts the MAL_ACTIVE signal during the assertion of MAL_SELECT. ComMac uses
selecting the current channel and MAL_OPB_ABUS[29:31] is used for transaction qualifiers. MCMAL
29 to 31 (indicating status read transfer).
• MCMAL then writes the status register value into memory (PLB transaction).
• Once the status halfword is written to memory, MCMAL asserts MAL_RX_STATUS_DONE[x] sideband
signal.
Note: All Status/Control transactions are word transactions. Valid data will be presented on bits 0 to 15 of the
OPB and bits 16 to 31 are driven low. For more information on the Status/Control halfword format see Section
2.2.7, ComMac-MCMAL Status/Control Exchange, on page 38.
ComMac must wait for MAL_RX_STATUS_DONE[x] before activating MCMAL for the next packet.
2.2.6.3 RX Early Packet Termination Initiated by ComMac
Early packet termination occurs when packet reception is aborted (by ComMac) prematurely, before
ComMac completes the packet data transfer to MCMAL.
In this case, ComMac deasserts COM_RX_FRAME[x] to indicate that it has completed the reception and
processing of the current packet, and it asks MCMAL to read the packet’s status and end the reception (end
of frame phase).
A ComMac is not allowed to initiate such termination before the end of the packet reception initiation. In other
words, a ComMac is allowed to deassert its COM_RX_FRAME[x] only after MCMAL has written the control
halfword to the ComMac.
2.2.6.4 RX Descriptor Error
MCMAL accesses a new descriptor in memory in order to continue (or start) serving a ComMac’s channel
request for data transfer. MCMAL first examines the Empty bit (for RX channel) in the descriptor in order to
check that the descriptor is valid. When the Empty bit is not set, it means that the device driver did not
prepare a new buffer descriptor and MCMAL stops processing the packet.
A non-valid descriptor is an error. In response, MCMAL disables the ComMac channel (Channel Active
Register). A non-maskable interrupt is issued, indicating that a descriptor error has occurred. See Section
3.3.4.3 , Descriptor Error Interrupt Registers, on page 110. MCMAL also informs the ComMac that a
Descriptor Error has occurred by asserting MAL_TX_DSC_ERR[x] for a single clock cycle.
2.2.7 ComMac-MCMAL Status/Control Exchange
As described in Section 3.1.3.2 , Status/Control Field Handling, on page 89, while processing a packet,
MCMAL writes the Status/Control halfword to the ComMac channel (at the initiation of the packet handling)
and reads it back once it contains valid status fields (at the termination of the packet handling).

132
IBM Core Databook
The Status/Control halfword, written to a channel, is the exact same Status/Control halfword found in the
descriptor buffer. MCMAL simply copies the Status/Control halfword to ComMac.
The Status/Control halfword, written back to memory (containing valid status bits) has two fields: a MCMAL
field (in which MCMAL receives control bits and returns status) and a ComMac field (in which ComMac
receives control bits and returns status).
Since bits 0 to 5 of the Status/Control halfword are not used by ComMac (these bits form the MCMAL field),
ComMac uses these bits to transfer MCMAL-related information. These bits are then processed by MCMAL
(affecting its activities). MCMAL then replaces these bits with its own Status/Control field and writes the
complete Status/Control halfword to memory. Figure 8 illustrates the various Status/Control fields and the
manner in which they are manipulated.
Figure 8. Status/Control Fields - Manipulation
MCMAL ComMac
related related
fields fields
Descriptor buffer (in memory)
0 5 6 15
Manipulation Transparent
MCMAL
allowed exchange
0 5 6 15
ComMac
0 5 6 15
Note: The bit numbering in Figure 8 relates to the buffer descriptor’s fullword which contains both the Sta-
tus/Control and the length fields. The same bit ordering is true for the Status/Control OPB transactions
between MCMAL and a ComMac channel.
2.2.7.1 ComMac TX Channel Status Halfword Content
Figure 9. ComMac TX Channel Status Field
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P Res B Res Res Res * * * * * * * * * *
ComMac protocol specific status - for software handling

Core Databook IBM
Table 5. ComMac TX Channel Status Field Descriptions

Bit(s) MNE Name Description
0 P Bad Packet 0 - The transmission of the last packet has been completed without any error.
1 - Error was detected on the last transmitted packet.
MCMAL processes this bit internally. When this bit is set, MCMAL activates the
channel related bit in the TXEOBISR, causing the activation of a non-maskable
interrupt.
1 Reserved This bit is reserved, and should be set to zero by ComMac.
2 B 0 - The next packet to be transmitted is within the next descriptor buffer.

1 - The next packet to be transmitted is actually the same one we have just finished
transmitting.
MCMAL processes this bit internally. This bit instructs MCMAL as to which descrip-
tor buffer to use for the next packet. This bit is not propagated to the Status/Control
field within the descriptor buffer.
3:5 Reserved These bits are reserved, and should be set to zero by ComMac.
6:15 These bits are ComMac specific, they do not affect MCMAL’s functions. These bits
are propagated to the Status/Control field within the descriptor buffer.
2.2.7.2 ComMac RX Channel Status Halfword Content
Figure 10. ComMac RX Channel Status Field
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P Res Res Res Res Res * * * * * * * * * *
ComMac protocol-specific status - for software handling
Table 6. ComMac RX Channel Status Field Descriptions

0 P Bad Packet 0 - The transmission of the last packet has been completed without any error.
1 - Error was detected on the last transmitted packet.
MCMAL processes this bit internally. When this bit is set MCMAL activates the
channel related bit in the RXEOBISR, causing the activation of non-maskable inter-
rupt. This bit is not propagated to the Status/Control field within the descriptor buffer.
1:5 Reserved These bits are reserved and should be set to zero by ComMac.
6:15 These bits are ComMac specific, they do not affect MCMAL’s functions. These bits
are propagated to the Status/Control field within the buffer descriptor.

132
IBM Core Databook
2.2.8 ComMac-MCMAL Protocol (Waveforms)
The diagrams on the following pages are examples for the protocol between MCMAL and ComMac. See
Section 2.2.4, ComMac-MCMAL Sideband Signal Naming Convention and Description, on page 25 for side-
band signal protocol definition.
Dependencies between various events may occur as illustrated, or in later cycles. For example, in Figure 11
MAL_ACTIVE is asserted three cycles after COM_TX_FRAME[x] is asserted, when it takes more than a
single cycle to assert MAL_ACTIVE.
2.2.8.1 TX Channel - Beginning of Packet Transfer
Figure 11. TX Channel - Beginning of Packet Transfer
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OPB_CLK
COM_TX_FRAME(7)
COM_T7_ARB_LEVEL 01 01 00
MAL_ACTIVE
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_TX_CHANNEL_SELECT(7)
TX7_MAL_BURST_LENGTH 01
MAL_OPB_ABUS C DATA_WRITE
MAL_OPB_BUSLOCK
MAL_OPB_DBUSEN
MAL_OPB_DBUS C 1 2 3 4
COM_T7_XFERACK
Note: Actual delays between events may be different from the delays depicted in the figure.
Figure 11 shows a typical beginning of transmission of a packet. Channel 7 initiates the transmission by
asserting FRAME, and setting a request for service (assert COM_T7_ARB_LEVEL to ‘01’ on cycle 0). The
required data amount is 4 words (TX_MAL_BURST_LENGTH=’01’). MCMAL services the channel as it gains
internal arbitration, and starts a control write transaction after it has fetched the buffer descriptor over the PLB
(cycle 3).
After MCMAL has fetched 16 bytes of data over the PLB, it starts a data write of those bytes (cycles 13 to 16).
Cycles 13 to 16 (data write) are repeated until the end of packet.
The gray areas represent clock cycles in which a channel may negate the request for service.

Core Databook IBM
2.2.8.2 RX Channel - Beginning of Packet Transfer
Figure 12. RX Channel - Beginning of Packet Transfer
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
OPB_CLK
COM_RX_FRAME(18)
COM_R18_ARB_LEVEL 01 01 02
MAL_ACTIVE
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_RX_CHANNEL_SELECT(18)
RX18_MAL_BURST_LENGTH 01
MAL_OPB_ABUS Cntl DATA_READ

MAL_OPB_BUSLOCK
MAL_OPB_DBUSEN
MAL_OPB_DBUS Cntl
COM_R18_XFERACK 1 2 3 4
Figure 12 shows a typical beginning of packet reception. Channel 18 initiates the receive by asserting
FRAME, and setting a request for service (assert ARB_LEVEL to ‘01’ on cycle 0). The required data amount
is 4 words (RX_MAL_BURST_LENGTH=’01’). MCMAL gives that channel service as the channel gains
internal arbitration, and starts a control write transaction after it has fetched the buffer descriptor over the PLB
(cycle 3).
MCMAL then starts a data read of 16 bytes (cycle 8 to 15). In this scenario, the ComMac has a one cycle
response duration. Cycles 8 to 15 (data read) are repeated until the end of packet.

132
IBM Core Databook
2.2.8.3 TX Channel - Normal End of Packet Transfer
Figure 13. TX Channel - Normal End of Packet Transfer
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OPB_CLK
COM_TX_FRAME(7)
COM_T7_ARB_LEVEL 01 00 01 00
MAL_ACTIVE
MAL_TX_STATUS_DONE(7)
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_OPB_ABUS data write last

data STS
MAL_OPB_BUSLOCK
MAL_OPB_DBUSEN
MAL_OPB_DBUS 1 2 3
COM_T7_XFERACK
Figure 13 shows a typical end of packet transmission. MCMAL transmits the last word along with the last data
command on the address bus (cycle 6). The ComMac negates the request for service and FRAME on the
next cycle.
Upon request for service (when FRAME is de-asserted), MCMAL starts a status read (cycle 12). When
MCMAL writes the status on the PLB, it signals MAL_TX_STATUS_DONE (7) (cycle 17) so the channel can
start a request for new packet transmission.

Core Databook IBM
2.2.8.4 RX Channel - Normal End of Packet Transfer
Figure 14. RX Channel - Normal End of Packet Transfer
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
OPB_CLK
COM_RX_FRAME(18)
COM_R18_ARB_LEVEL 01 00 01 00
COM_R18_LAST_DATA
COM_R18_LAST_DATA_BE be
MAL_ACTIVE
MAL_RX_STATUS_DONE(18)
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_RX_CHANNEL_SELECT(18)
RX18_MAL_BURST_LENGTH 01
MAL_OPB_ABUS data read sts

MAL_OPB_BUSLOCK
COM_R18_XFERACK 1 2 3
Figure 14 shows a typical end of packet reception. MCMAL receives the last word when the channel signals
the LAST_DATA and gives the corresponding LAST_DATA_BE (cycle 7). The ComMac negates the request
for service and FRAME on the next cycle. MCMAL then writes those last words on the PLB.
MCMAL starts a status read (cycle 20) after a request for status read was initiated on cycle 14. After the
status is written on the PLB, MCMAL signals STATUS_DONE (cycle 24) which allows the channel to initiate a
request for a new packet transmission.

132
IBM Core Databook
2.2.8.5 Early Termination
Figure 15. Early Termination
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
OPB_CLK
COM_TX_FRAME(7)
COM_T7_ARB_LEVEL 01 01
MAL_ACTIVE
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_OPB_ABUS data STS

read
MAL_OPB_BUSLOCK
COM_T7_XFERACK
Figure 15 shows early termination in transmit and receive is the same. A channel negates its FRAME before
it gives the LAST_DATA signal in receive, or as it is shown in Figure 15, before MCMAL transmits the last
word (at cycle 5), the address bus does not imply a last data transfer.
Early termination may be invoked while MCMAL is serving a channel, as shown in this example. However, as
the dashed lines indicate, this is not necessarily the case. A channel may invoke the early termination while
MCMAL provides service to another channel, or even while it is idle, as long as it is invoked after the initial
command write by MCMAL to ComMac.
Following the deassertion of FRAME the channel must issue a request for service for status read (FRAME
should remain deasserted). When that channel gains internal arbitration, MCMAL reads its status (cycle 11).
Following that, MCMAL writes that status on the PLB, and signals the channel with STATUS_DONE (cycle
14).
The gray areas represent clock cycles in which a channel may negate the request for service without invoking
an early termination.

Core Databook IBM
2.2.8.6 Descriptor Not Valid
Figure 16. Descriptor Not Valid
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
CLK
COM_TX_FRAME(8)
COM_T8_ARB_LEVEL 02 02 00
MAL_ACTIVE
MAL_TX_DSCR_NOT_VALID(8) 1 2
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_OPB_ABUS sts
COM_T8_XFERACK
Figure 16 shows a case where the first buffer descriptor of a TX channel packet is not ready. Hence, MCMAL
does not write the control halfword to the channel. Instead it asserts MAL_TX_DSCR_NOT_VALID[x].
The channel can choose to hold the request for service as it does in cycle 7. In this case, when that channel
regains arbitration, MCMAL will try to fetch the buffer descriptor again.
On the other hand, it can de-assert the signals as it does after the second time that the buffer descriptor was
not valid (cycle 13). Next time the channel gains internal arbitration, MCMAL starts a status read (cycle 16).
Following that, MCMAL signals the channel with STATUS_DONE (cycle 20). In this case, MCMAL does not
write the status on the PLB, since the respective descriptor is not ready.
The gray area represents a clock cycle in which a channel may negate the request for service.

132
IBM Core Databook
2.2.8.7 TX Channel - Packet Transfer - Burst Length is 16 Words
Figure 17. TX Channel - Packet Transfer - Burst Length is 16 Words
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OPB_CLK
COM_TX_FRAME(2)
COM_T7_ARB_LEVEL 01 00
MAL_ACTIVE
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_OPB_ABUS DATA_WRITE
MAL_OPB_BUSLOCK
MAL_OPB_DBUSEN
MAL_OPB_DBUS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
COM_T2_XFERACK
Figure 17 shows a typical single write transaction. The control write transaction and the first data segment
write have been already written to the channel (not in the scope of this figure). The burst length is 16 words
(TX2_MAL_BURST_LENGTH=’11’). Channel 2 requests service of a another data segment (ARB_LEVEL
value is ‘01’). MCMAL services the channel as it gains internal arbitration. After MCMAL has fetched 16
words of data over the PLB, it starts a data write transaction of those words (cycles 2 to 17).
Cycles 2 to 17 (data write) are repeated until the end of packet.

Core Databook IBM
2.2.8.8 RX Channel - Packet Transfer - Burst Length Is Eight Words
Figure 18. RX Channel - Packet Transfer - Burst Length Is Eight Words
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OPB_CLK
COM_RX_FRAME(5)
COM_R5_ARB_LEVEL 01 00
MAL_ACTIVE
MAL_OPB_REQUEST
OPB_MAL_GRANT
MAL_OPB_SELECT
MAL_OPB_ABUS DATA_READ
MAL_OPB_BUSLOCK
MAL_OPB_DBUSEN
MAL_OPB_DBUS 1 2 3 4 5 6 7 8
COM_T5_XFERACK
Comment: Actual delays between events may be different from the delays depicted in the figure.
Figure 18 shows a typical single read transaction. The control write transaction and the first data segment
read have been already completed (not in the scope of this figure). The burst length is 8 words
(RX2_MAL_BURST_LENGTH=’10’). Channel 5 requests service of another data segment (ARB_LEVEL
value is ‘01’). MCMAL services the channel as it gains internal arbitration. MCMAL reads 8 words (cycles 2 to
9).
Cycles 2 to 9 (data read) are repeated until the end of packet.

132
IBM Core Databook
2.3 128-Bit Extended OPB
2.3.1 Introduction
Extended On-chip Peripheral Bus architecture (EOPB) is the interface between the MCMAL and the Ethernet
Media Access Controller version 4 (EMAC4) or any other 128-bit ComMac core. The EOPB is an extension of
the original 32-bit OPB, as described in the On-Chip Peripheral Bus: Architecture Specification version 1.4, to
a 128-bit wide data bus.
This section describes the additions to the OPB architecture, required for 128-bit data transfer.
This section describes specifically the interface between MCMAL and EMAC4. Note that the EOPB definition
is not limited to EMAC4. MCMAL can support any ComMac that implements the EOPB interface.
2.3.2 Overview
The EOPB bus 128 has the following features:
• 128 data bus.
• 32 address bus.
• Byte Enable Acknowledgment mechanism: This mechanism is used by ComMac to inform MCMAL which
of the bytes in the data bus are acknowledged by the ComMac. It is used only on OPB Read transactions,
when the MCMAL reads data from a ComMac.
• Byte Enable mechanism: This mechanism allows the MCMAL to inform the ComMac, which are the valid
bytes within the data bus. It is used only on OPB Write transactions, when the MCMAL writes data to a
ComMac.
• 32-bit OPB ComMacs that are compliant with the OPB Specification and the MadMAL /MadMAL 1/N
cores can be attached to MCMAL without any changes in their logic.
In this section the following notations are used:
• WRITE
— When MCMAL, as an EOPB master, performs a write operation towards a ComMac (EOPB slave).
May also be referred to as TRANSMIT.
• READ
— When MCMAL, as an EOPB master, performs a read operation from a ComMac (EOPB slave). May
also be referred to as RECIEVE.

Core Databook IBM
Figure 19. Physical Implementation of the EOPB
M0_request
OPB_M0Grant
M0_ABus
OPB
AND
M0_Select
OPB Arbiter Master
OPB_DBus
Bridge
M0_DBus
Device
AND
M0_DBusEn
OR
OPB_M1Grant
M1_Request
OPB_DBusExt OPB_DBusExt
OPB_DBus OPB_DBus
OPB_ABus
OR
MAL_ABus
AND
OPB_BE_Ext
MAL_Select
EMAC4
OR OR
AND
MCMAL
MAL_BE_Ext
OPB
OPB MAL_DBus EMAC_DBus
AND
Slave
AND
Master MAL_DBusEn EMAC_DBusEn

AND
AND
MAL_DBusExt EMAC_DbusExt
AND
OPB_BEAckExt
EMAC_BEAckExt
OR
BEAckExt from
Other Slaves
2.3.3 Physical Implementation - Changes and Additions to the OPB Bus Version 1.4
Figure 19 describes the implementation of the EOPB. This figure is based on OPB implementation. The
EOPB extension signals are indicated by a dashed line and labeled in italics with suffix Ext. MCMAL and
EMAC4 are presented with the additional logic that must be implemented to support the EOPB.
2.3.4 EOPB Signals
The following signals are changed or added to the original OPB Version 1.4 to support the Extended OPB.
For a detailed description of all other signals see the OPB Specification.

132
IBM Core Databook
2.3.4.1 OPB Data Bus
The OPB data bus consists of these signals:

• OPB_DBus[0:127]
• MAL_DBus[0:127]
• EMAC_DBus[0:127]
The OPB data bus is extended from 32 bits to 128 bits in the EOPB. The MSb is still bit 0.
The MCMAL data bus is divided into the original part (MAL_Dbus- 32 bits) and the extension (MAL_DbusExt-
96 bits). The data bus extension is gated just like the original part of the data bus (using the DBusEN signal).
A detailed description of the gating can be found in the OPB Specification.
The EMAC4 data bus is divided into the original part (EMAC_DBus- 32-bits) and the extension
(EMAC_DBusExt- 96 bits).
MAL_DbusExt and EMAC_DbusExt are ORed together to produce OPB_Dbus_Ext, as in the original part of
the OPB data bus.
If a 32-bit ComMac is attached to MCMAL, it uses only 32 bits of the data bus and should be connected to bits
0 to 31 of the data bus. In this case the COM_DBus[32:127] should be tied to zeros.
2.3.4.2 Master Byte Enable Signal - MAL_BE_Ext
Consists of these signals:

• MAL_BE_Ext[0:15]
• OPB_BE_Ext[0:15]
MCMAL uses MAL Byte Enable extension to indicate to EMAC4 which data bytes of the EOPB data bus are
valid during EOPB write operation. This signal is used only when MAL write data to a 128-bit slave.This signal
is not valid during OPB read operation.
On non last write transfer, the MCMAL always drives the MAL_BE_Ext to a value of “1111 1111 1111 1111”.
The non last write data transfer is indicated by MCMAL when the address bus[29:31]=”001”. SeeTable 4 on
page 29.
On last write transfer, the MAL_BE_Ext value determines which bytes are valid. The last write data transfer is
indicated by MCMAL when the address bus[29:31]=”010”. See Table 4 on page 29.
On write Control word transactions, the MCMAL always drives the MAL_BE_Ext to “1100000000000000”,
indicating that the control half word is located at MAL_DBus[0:127]. The write control word transfer is indi-
cated by MCMAL when the address bus[29:31]=”000”. See Table 4 on page 29.
The allowed combinations are listed in Table 7.
Table 7. MAL_BE_EXT Bus (for EOBP Write Transactions) (Page 1 of 2)

BE_Ext[0:15] Valid data Address bus Transfer Description
combination [29:31]
1100 0000 0000 0000 Bytes 0 to 1 are valid 000 Write control transfer
1111 1111 1111 1111 All bytes in the Data Bus 001 Non last write data transfer
1111 1111 1111 1111 All bytes in the Data Bus 010 Last write data transfer

Core Databook IBM
Table 7. MAL_BE_EXT Bus (for EOBP Write Transactions) (Page 2 of 2)

BE_Ext[0:15] Valid data Address bus Transfer Description
combination [29:31]
1111 1111 1111 1110 Bytes 0 to 14 are valid 010 Last write data transfer
1000 0000 0000 0000 Byte 0 is valid 010 Last write data transfer
0000 0000 0000 0000 None of the Bytes are valid - 010 Last write data transfer
A null transfer
Note: All other MAL_BE_EXT combinations are not valid.
2.3.4.3 Slave Byte Enable Acknowledge Signal - COM_BEAckExt
Consists of these signals:

• COM_BEAckExt[0:15]
• OPB_BEAckExt[0:15]
ComMac Byte Enable Acknowledge. The ComMac uses this signal to indicate to MCMAL which data bytes of
the current EOPB transfers are acknowledged. This signal is valid alongside the Com_XferAck signal. This
signal is used only when MCMAL reads data from a 128-bit slave.This signal is not valid during OPB write
operation.
On non last read data transfer, the ComMac always drives the COM_BEAckExt to “1111 1111 1111 1111”.
On last read data transfer the COM_BEAckExt value determines which bytes of the EMAC_Dbus are valid.
The last data transfer is indicating when the ComMac asserts its COM_RX_LAST_DATA signal.
On read status word for TX path, the COM_BEAckExt value determines whether the previous status, current
status, both, or none of them are valid. Refer to Section 2.4, Back-to-Back TX Status Mechanism, on page
55.
This signal is not used on read status word transactions for the RX path.
The allowed combinations for COM_BEAckExt are listed in Table 8 on page 53.

132
IBM Core Databook
Table 8. Com_BEAckExt (Page 1 of 2)

BE_Ack_Ext[0:15] Valid data Address bus [29:31] COM_RX_LAST DATA Transfer Description
is asserted
1100 000 0000 0000 Bytes 0 to 1 are valid; 000 No Status read data transfer - the
Bytes 2 to 15 are not valid current status is valid and the
previous status is not valid.
Used in TX only.
0011 000 0000 0000 Bytes 0 to 1 are not valid; 000 No Status read data transfer -the
Bytes 2 to 3 are valid; current status is not valid and
the previous status is valid.
Bytes 4 to 15 are not valid
Used in TX only.
1111 000 0000 0000 Bytes 0 to 3 are valid; 000 No Status read data transfer - the
Bytes 4 to 15 are not valid current status is valid and the
previous status is valid as well.
Used in TX only.
0000 000 0000 0000 Bytes 0 to 15 are not valid 000 No Status read data transfer - the
current status is not valid and
the previous status is not valid
as well.
Used in TX only.
1111 1111 1111 1111 All bytes in the Data Bus 001 No Non last read data transfer.
1111 1111 1111 1111 All bytes in the Data Bus 001 Yes Last read data transfer.
1111 1111 1111 1110 Bytes 0 to 14 are valid; 001 Yes Last read data transfer.
Byte 15 is not valid

Core Databook IBM
Table 8. Com_BEAckExt (Page 2 of 2)

BE_Ack_Ext[0:15] Valid data Address bus [29:31] COM_RX_LAST DATA Transfer Description
is asserted
1000 0000 0000 0000 Bytes 0 is valid; Bytes 1 to 001 Yes Last read data transfer.
15 are not valid
0000 0000 0000 0000 None of the bytes are valid 001 Yes Last read data transfer.
- null transfer Null transfer.
Note: All other COM_BEAckEXT combinations are not valid.
2.3.4.4 OPB Transfer Size
MAL_hwXfer and OPB_hwXfer, MAL_fwXfer and OPB_fwXfer signals exist in the OPB Specification. These
signals and their signals definitions remain unchanged (Not used in EOPB).
MAL_qwXfer and OPB_qwXfer are new signals. MAL_qwXfer is asserted by an EOPB master (MCMAL) to
indicate its transfer width - 128 bits.
Table 9 includes a description of the possible values of these signals and their interpretations.
Table 9. Bus Sizing - Master Side

MAL/OPB_hwXfer MAL/OPB_fwXfer MAL/OPB_qwXfer Interpretation
1 1 1 QuadWord transfer. EOPB transactions are supported. This

option always used in MCMAL -EMAC4 interface.
2.3.4.5 OPB Transfer Size Acknowledge
The following signals are not used in EOPB:

• OPB_hwAck
• Sln_hwAck
• OPB_fwAck
• Sln_fwAck
2.3.4.6 ComMac Bus Width
COM_TX_QW[0:31], COM_RX_QW[0:31]
This bus determines the bus width of each ComMac attached to MCMAL.
• When COM_TX_QW[x]=’1’ the TX ComMac is a 128-bit data bus ComMac (EOPB).
• When COM_TX_QW[x]=’0’ the TX ComMac is a 32-bit data bus ComMac.
• When COM_RX_QW[x]=’1’ the RX ComMac is a 128-bit data bus ComMac (EOPB).
• When COM_RX_QW[x]=’0’ the RX ComMac is a 32-bit data bus ComMac.

132
IBM Core Databook
2.3.5 MCMAL Burst Length - EOPB
MCMAL uses the same burst length mechanism to define the size of burst over the EOPB as it uses in the
OPB (32-bit). For more details see Section 2.2.3, MCMAL Burst Length, on page 24.
2.4 Back-to-Back TX Status Mechanism
2.4.1 General
The back-to-back TX status mechanism allows a TX ComMac channel to request a service from MCMAL, in
order to transmit a new packet from the memory towards the ComMac, although the current transmitted
packet hasn’t been fully transferred over the media. It means that the ComMac might request the next TX
service even if the status of the current packet is not ready to be written back to memory. This mechanism is
implemented only on the TX side. In order to support this mechanism the ComMac has four possibilities to
end a packet transfer: transfer the current packet status, transfer the previous packet status, transfer both the
current and previous packets status on the COM_OPB_DATA bus, or indicate to MCMAL that none of the
status conditions are valid.
This mechanism has been added to increase the overall ComMac- MCMAL performance.
2.4.2 Description
The following sections describe in detail the back-to-back TX status mechanism which is implemented in
MCMAL - 128-bit ComMac protocol. This mechanism is different from the ‘MCMAL - 32-bit ComMac’ protocol
only in the status phase. The frame phase, Idle to frame phase transition as well as frame to status phase
transition is identical in both 32-bit and 128-bit protocols.
When COM_TX_FRAME[x] is deasserted, the channel enters the status phase. The ComMac TX channel
must end every packet processing by a status transfer to MCMAL (“status phase”).
Note: A ComMac indication of status validity on the data bus is done via the OPB_MAL_BE_ACK_EXT[0:3]
signal, hence:
• “0000” - Non valid status of both current and previous.
• “0011”- Only previous status is valid.
• “1100” - Only current status is valid.
• “1111” - Both current and previous statuses are valid.
Note:
1. Status done signal appears between two data phases, regardless of using the back-to-back TX mecha-
nism. This is done in order to maintain the basic protocol.
2. MCMAL performs a status write back access (PLB write transaction) only after it gets a valid status
(whether previous or current).
Restrictions:
• When working with the back-to-back TX status mechanism, the ComMac isn’t allowed to ask for retrans-
mission (Retransmit bit in ComMac status field should be zero).
• If a TX channel’s descriptor table only has room for a single packet - this mechanism can’t be used.

Core Databook IBM
2.4.2.1 Normal Operation - Current Packet Status
In case the ComMac has a current valid status, it transfers it to the MCMAL indicating by the
COM_BEAckExt that the current status to be transferred on the COM_OPB_DATA bus is valid. Then MCMAL
writes the status into the last packet descriptor in the memory (OPB_MAL_BE_ACK_EXT[0:1] = “11”).
In case the ComMac doesn’t have a current valid status yet, it indicates to MCMAL that the current status
to be transferred on the COM_OPB_DATA bus is not valid, and status shouldn’t be written into the last packet
descriptor in the memory (OPB_MAL_BE_ACK_EXT[0:1] = “00”).
When the channel has won the arbitration, MCMAL reads the status (valid or not valid) from the ComMac’s
channel by an OPB read transaction as follows:
Note: In the case that MCMAL is the only OPB master, there is no need for asserting MAL_OPB_REQ.
selecting the current channel and MAL_OPB_ABUS [29:31] is used for transaction qualifiers. MCMAL
activates the current channel’s MAL_TX_CHANNEL_SELECT[x] signal and drives ‘000’ on OPB address
bits 29 to 31 (indicating status read transfer).
• In case of a current packet valid status (COM_BEAck_Ext [0:1] = “11”), the valid status of the current
packet is presented at COM_OPB_DATA[0:15].
• MCMAL writes the current status value upwards to memory (PLB transaction). Once the status is written
into memory, MCMAL asserts a MAL_TX_STATUS_DONE[x] sideband signal towards the ComMac.
Once ComMac detects MAL_TX_STATUS_DONE[x] it can issue an interrupt (related to the packet transmis-
sion, if needed) and instruct MCMAL to proceed to the next packet (by reassertion of COM_TX_FRAME[x]).
ComMac must wait for MAL_TX_STATUS_DONE[x] before activating MCMAL for the next packet.
2.4.2.2 Normal Operation - Previous Packet Status
In case the ComMac transferred a non valid status on the previous packet it must transfer the previous packet
status on the next packet status transfer.
ComMac isn’t allowed to hold back more than a single status at a time, hence if COM_BEAckExt[0:1] = “00”
then on the next status phase COM_BEAckExt[2:3] must be “11”. Also, each status must be validly trans-
ferred once and only once.
In case the ComMac has a previous valid status, it transfers it to the MCMAL indicating by the
COM_BEAckExt that the previous status to be transferred on the COM_OPB_DATA bus is valid. Then
MCMAL writes the status into the last descriptor of the previous packet in the memory
(OPB_MAL_BE_ACK_EXT[2:3] = “11”).

132
IBM Core Databook
In case the ComMac doesn’t have a previous valid status yet, it indicates to MCMAL that the previous
status to be transferred on the COM_OPB_DATA bus is not valid and status shouldn’t be written into the
memory (OPB_MAL_BE_ACK_EXT[2:3] = “00”).
2.4.2.3 Normal Operation - An Example
In the following example, there are three packets being transmitted through a single channel:
After the frame phase of the first packet, the ComMac hasn’t got the status ready, so it gives MCMAL an
invalid one, and starts working on the second packet (Thus, the first packet doesn’t block the second one).
By the time the second packet is in status phase, the ComMac has the status of the first packet (but not of the
second), so it passes an invalid current status and a valid previous one. MCMAL now updates the memory
and the first packet is ready for the processor.
By the time the third packet is in status phase, the ComMac has the status of both the second and third
packets, and MCMAL - after receiving those statuses (single OPB transaction), writes them both (chronologi-
cally) to the memory.
Note: This is one possible scenario.
Figure 20. Back-to-Back TX Status Mechanism
Status Status Status

FRAME phase phase Frame phase
Frame Frame
phase phase phase
OPB_MAL_BE_ACK_EXT(0 to 3)
OPB_MAL_XFER previous current

previous
Writing status to memory(PLB)
0000 0011
MAL_TX_STATUS_DONE
2.4.2.4 TX Early Packet Termination Initiated by ComMac
A TX ComMac can initiate an early packet termination, whereby it terminates the packet transmission before
MCMAL finishes transferring all the packet’s data from memory to the TX ComMac. This is typically used
when error conditions force the ComMac to abort the transmission.
In case the channel’s previous packet’s status is still missing:
• Any error in the transmission of a current packet should not affect the previous one. In this spirit, the
ComMac must issue a valid status for the previous packet no matter what happens to the current packet.
In case the current status is valid:
• When not working with “scroll descriptors” - the status is written to the terminated descriptor.

Core Databook IBM
• When working with “scroll descriptors” - MCMAL will write the status to the TX descriptor status control
field of all the packet’s descriptors between the terminated one and the last.
In case the current status is still missing:
• When not working with “scroll descriptors” - On the next status phase of this channel, the “previous” sta-
tus will belong to the early terminated one, and will be written to the terminated descriptor.
• When working with “scroll descriptors” - MCMAL will write zeroes to the TX descriptor status control field
of all the packet’s descriptors between the terminated one and the previous to last one (the last descriptor
must get its real status on the next status phase).
2.4.2.5 TX Descriptor Not Valid and TX Descriptor Error
If the channel’s previous packet hasn’t got a valid status yet, and the current packet has a descriptor problem,
once the channel’s frame is deasserted, MCMAL enters the status phase, and the previous status must be
valid.
2.5 MCMAL Operation on OPB and PLB

MCMAL operation on the OPB and PLB is compliant with the specifications of these buses. This section
describes the subset of bus master operations used by MCMAL and the different configuration options to
program MCMAL operation.
On the OPB, MCMAL uses some sideband signals to implement the protocol with the ComMacs. For defini-
tion of these sideband signals and the associated protocol see Section 2.2.4, ComMac-MCMAL Sideband
Signal Naming Convention and Description, on page 25.
2.5.1 MCMAL Operation on the PLB
Compliant with the PLB Specification version 4.3.
2.5.1.1 Type of Transactions
MCMAL as a PLB Master, provides 128-bit PLB separate read and write data paths. As a result MCMAL
supports simultaneous read and write transfers over the PLB, leading to better utilization of the PLB.
The MCMAL PLB master supports the following kinds of transactions:
• Single beat regular transfers, that is, transfers of 1 to 16 bytes per transfer for both read and write.
• Fixed length burst transfer, 2 to 16 quadwords in a burst transfer for both read and write.
• Address pipelining of burst transaction after single transaction in write transactions.
• Address pipelining of single transactions for both read and write.
• There is no address pipeline after burst transaction (that is, burst after burst or single after burst)
In the burst mode MCMAL initiates multiple-quadword burst transactions whenever it is possible (according to
the memory address, buffer size and state of internal buffers).

132
IBM Core Databook
In order to support a non-bursting slave, MCMAL can be configured to work in non-burst mode. In this case
all read and write transactions to and from the memory are single beat transfers. The burst mode is the
recommended mode for working on the PLB with MCMAL.
In Burst mode, MCMAL uses the Fixed Burst Length protocol, which indicates the number of data beats that
will be transferred on the current burst transaction. Slaves can take advantage of using this protocol and
improve their memory access performance.
MCMAL read transactions are always full quadword transactions (all byte enable signals are active) and
MCMAL ignores the invalid bytes within the quadword. During write transactions, MCMAL uses the byte
enable signals in order to avoid a distractive write.
2.5.1.2 Bus Arbitration
The priority of MCMAL as a PLB Master for bus arbitration is programmable. All MCMAL requests are of the
same priority, and this priority can be changed in the MCMAL Configuration Register (MCR). It is up to soft-
ware to decide what is the MCMAL priority on the bus, and the decision should be taken after a careful exam-
ination of the system implementation.
2.5.1.3 Maximum PLB Burst Size
MCMAL uses a programmable maximum burst size mechanism. This mechanism replaces the PLB Latency
Timer mechanism. This mechanism is used to control the maximum latency in a particular application.
MCMAL can be programmed to one of three maximum burst sizes: 4-, 8-, and 16-quadword PLB burst. If the
amount of data requested by ComMac to be transferred is larger than the configured maximum burst size,
MCMAL breaks the transfers into several burst transfers.
Note: On read transactions, when working with non quadword aligned addresses, there might be a perfor-
mance penalty when the Maximal PLB Burst size is too small. It is preferred that MCMAL will be configured to
the biggest Maximal PLB Burst size possible.
The length of the burst transactions is also limited by TX/RX_MAL_BURST_LENGTH regardless of the value
of Maximum PLB Burst size. For example, the burst length will be 4 when RX_MAL_BURST_LENGTH’=’011’
(for the specific values, see Section 2.2.3.1 , TX_MAL_BURST_LENGTH and RX_MAL_BURST_LENGTH
Signals, on page 24).
2.5.1.4 Programmable Options
The behavior of the following PLB master output signals is programmable and can be controlled by software
(in MCR):
• PLB_MAL_priority
• PLB_MAL_Attribute
• PLB_MAL_LockError
• PLB_MAL_Max_Burst_Size
• PLB_MAL_Burst (enable)
For further information see Section 3.3.1, MCMAL Configuration Register, on page 104.

Core Databook IBM
2.5.1.5 Buffer Access and Transaction Alignment
In order to allow flexibility for the device driver buffer management, MCMAL does not have any limitation on
the alignment or the length for the data buffers. The data buffer pointer in the descriptor can access any byte
address. The length of the transmitted buffers can be any length between zero and a maximum length of (4K-
1) bytes. The length of the received buffer is defined by the value of RX-Channel-Buffer-Size-Register
(RCBSR).
In order to properly utilize the bus and memory access, MCMAL implements the following rules when it
performs read transactions from the memory:
• All read transactions are full quadword transactions.
• MCMAL ignores the irrelevant bytes within the quadword that was read.
• In burst mode MCMAL always performs burst transactions - even when the first or last quadword is not
aligned (when PLB burst mode is enabled).
MCMAL implements the following rules when it performs write transactions to the memory:
• A single beat write transaction can be of any size from 1 byte to 16 byes. The bytes are in consecutive
locations in memory.
• In burst mode, there might be non-burst transactions because of alignment limitation.
2.5.2 MCMAL Operation on the OPB
OPB Specification version 1.4 compliant. Supports both 32-bit and128-bit OPB slaves.
2.5.2.1 Transaction Width
MCMAL transactions are always of fullwords (quadwords in EOPB) and for less than a 4-byte transfer. In
cases of less than four byte transfers, MCMAL uses the address on write transactions, and sideband signals
on read transactions, as byte enable (see Section 2.2.4, ComMac-MCMAL Sideband Signal Naming Conven-
tion and Description, on page 25).
Therefore, MCMAL does not implement bus sizing. MAL_fwXfer and MAL_hwXfer are always set, and
MCMAL expects ComMac to respond with COM_T/Rx_fwAck=’1’ and COM_T/Rx_hwAck=’0’. Another
response is considered an error.
2.5.2.2 Bus Lock
MCMAL can perform two kinds of data transactions: burst and non-burst.
1. When MCMAL is configured to work in a burst mode, it asserts the OPB’s BUSLOCK signal. This allows
continuous data transfers in a single bus request. Unless it is interrupted, MCMAL reads or writes in one
burst, a number of words which is equal to the ‘RX/TX_MAL_BURST_LENGTH’ signal value (or less, in
last data write to TX channels). MCMAL deasserts the MAL_OPB_BUSLOCK in the beginning of the last
data transaction cycle, to let the bus rearbitrate.
2. When MCMAL is configured to non-burst mode, it avoids locking the OPB. In this case every fullword
transaction is done in a separate bus request. MCMAL continuously requests the bus as long as there is
additional data to be transferred.

132
IBM Core Databook
2.5.2.3 Bus Arbitration
MCMAL supports bus parking. If the OPB arbiter parks on MCMAL, and MCMAL needs the bus, it will assert
its qualifiers and resume the next bus cycle without waiting to be granted. When MCMAL is parking on the
OPB it is capable of completing a data transfer with zero latency.
Note: When MCMAL is the only OPB master, it is recommended that the OPB arbiter will park on MCMAL.
2.5.2.4 Hardwired Configuration
MCMAL base address is the value of bits 0 to 23 on the OPB used by MCMAL (master on the bus). The value
of these bits is an input to MCMAL that can be hardwired (using input port MAL_HIGH_OPB_ADDR[0:23]).
2.6 DCR MCMAL-CPU Interface

This interface is DCR version 2.0 compliant.
2.6.1 DCR Interface Overview
The device control register (DCR) bus is a separate bus defined by the PLB Specification. On this bus, (see
Figure 21 on page 61) the 4XX is a master and all other devices are slaves. The DCR bus is used for MCMAL
configuration write and status read operations. All MCMAL registers are accessed though the DCR bus which
resets the registers and is used by the device driver to configure MCMAL. It also reads the error registers
when the ComMac sends out an error indication.
Figure 21. MCMAL - CPU Interface (via DCR)
CPU_exeMfDcr
CPU_exeMtDcr
MCMAL CPU_dcrAddr Core

DCR
target CPU_dcrData
MAL_dcrData
MAL_dcrAck
The DCR bus activity is performed in parallel with the functioning of the other buses. The device driver is
responsible for configuring MCMAL before it enables the ComMacs to begin requesting that MCMAL process
packets of data. There is no mechanism to prohibit the ComMacs normal course of activity. Therefore, the
device driver should ensure that channels are programmed not to perform any kind of transactions during the
reconfiguration, otherwise a fatal error might occur.
On the other hand, there is no limit regarding reading the contents of the registers, and read operations can
be done at the same time as any MCMAL transaction.

Core Databook IBM
2.6.2 DCR Interface Implementation Notes
The implementation of the DCR interface involves the following:
• Since MCMAL works at the same clock speed as the CPU, the protocol will be as described in the PLB
Specification. A latch is used to avoid future timing problems.
• To allow flexibility in defining the DCR address space used by MCMAL, the hardware integrator can
define the value of DCR address bits 0 to 2 (MSbs) by setting the value of MAL_DCR_BASE_ADDR[0:2]
input bus.
• The DCR acknowledge signal is driven by a common Address Decoder ORed with the previous device
acknowledge signal.
• MCMAL sets zeros on the MAL_dcrData line as long as the CPU_exeMfDcr is not set and the Address
Decoder does not detect that MCMAL was addressed.
• MCMAL adheres to the 16-cycle Acknowledge response.
• MCMAL does not implement any kind of interrupt mechanism. It is the device driver’s responsibility to
start configuring MCMAL once it is ready, after the reset.

132
IBM Core Databook
2.7 MCMAL Arbitration Between ComMac Channels

This section describes the arbitration between 64 channels (32 RX and 32 TX). In the case of a MCMAL that
supports 8 or 32 channels, the appropriate number of channels should be assumed.
MCMAL is designed to facilitate up to 32 TX channels and 32 RX channels. These channels may come from
different ComMacs, and may differ greatly in their data rates. At any point in time, there may be several
ComMac channels requesting MCMAL’s service. The arbiter is designed to service requests based on the
level of request driven by the ComMacs.
This chapter elaborates on the MCMAL arbitration scheme for rendering service to the various channels.
2.7.1 MCMAL Arbitration Algorithm
In order to minimize access latency, the MCMAL arbitration approach is access-based rather than time-slot
based. A channel presents a request for service by applying its arbitration level signals to MCMAL. The
request can be either for data transfer or status read. A channel can use four priority levels of arbitration
request.
The arbitration requests of the transmit channels are handled by the transmit arbiter. The arbitration requests
of the receive channels are handled by the receive arbiter. Each transmit and receive arbiters are considered
as a group arbiter. The group arbiter is described in Section 2.7.2, Arbitration Inside the Group, on page 64.
MCMAL has two independent internal controls and data paths for transmit packet handling, and receive
packet handling. At any given time, up to one transmit and one receive channel can be handled simulta-
neously. Since MCMAL has a single interface to both the PLB and OPB, the receive path and the transmit
path have to arbitrate (internally) for the usage of these shared resources. This arbitration is considered as
arbitration between groups. It is described in detail in Section 2.7.3, Arbitration Between the Groups, on page
65.
Note that the PLB and OPB are (optionally) shared resources of the system and may be accessed by other
bus masters. In this case MCMAL must gain control of the bus following an arbitration request to the external
bus. Arbitration on the external buses is beyond the scope of this section.
Figure 22 on page 64 gives a general description of the arbitration scheme. The transmit channels are arbi-
trating in the transmit group and the receive channels are arbitrating in the receive group. On each group, a
channel can drive idle, low, high or urgent levels of request. Urgent requests of both groups are served first. If
there are no other urgent requests, then high-level requests are served. Low-level requests are served only if
there are not higher-level requests. The receive and transmit request are toggled to gain access to the PLB
and OPB.

Core Databook IBM
Figure 22. General Arbitration Scheme
TX group RX group
Urgent
High
Low
Queued requests
No requests
2.7.2 Arbitration Inside the Group
The arbitration in the group level for the transmit and receive channels is identical. The description in this
chapter is related to both transmit group arbiter and receive group arbiter.
Each one of the 32 channels associated with a group drives its level of priority to be served. The decision on
when to drive each one of the levels is up to the ComMac definition. Therefore, care must be taken in the defi-
nition of the priority levels driven by a ComMac to avoid completely ignoring another ComMac limited to a
lower level of request. The different levels are coded on a two-bit arbitration bus:
COM_T/RX_ARB_LEVEL0[x], COM_T/RX_ARB_LEVEL1[x].
A dedicated arbitration bus connects each one of the ComMacs with the arbiter. The different levels are:
• Idle (coded as ‘00’ on the arbitration bus) - means that the channels don’t wait for service.
• Low (coded as ‘01’ on the arbitration bus) - means the channels wait for service in a low priority.
• High (coded as ‘10’ on the arbitration bus) - means the channels wait for service in a high priority.
• Urgent (coded as ‘11’ on the arbitration bus) - means the channels wait for service in an urgent priority.
Idle level on the arbitration bus means that the ComMac currently doesn’t require any service from MCMAL.
When a ComMac needs to be served by MCMAL it has to assert a Low request. If the urgency of service
becomes higher (for any reason defined by the ComMac - its FIFO threshold for example) the ComMac may
drive its request to a higher level (High request or Urgent request). Requests for service driven by the
ComMacs and applied to the arbiter are described as queued requests.
A queued request can win the arbitration in the group arbiter only if there is not any request in the group of a
higher priority. A request which had won the arbitration in the group arbiter is considered as a pending
request. The term “pending” is used, since the request can be held as a winner of the group arbitration
without being served. The pending request represents the highest priority channel at any time.

132
IBM Core Databook
On each level, the group arbiter maintains a cyclic queue according to the number of the channels. If channel
‘n’ is the last channel that won the arbitration, channel ‘n+1’ is the next one to win the arbitration. If channel
‘n+1’ doesn’t ask for service, the channel ‘n+2’ will be served. Note that the cyclic order means that channel
‘1’ follows channel ‘0’ and channel ‘0’ follows channel ‘15’. When there is a queued request in a higher level,
it is served first until there are no more queued requests at that level. Following the service of the higher level
priority, the cyclic queue continues from the channel following the last winning channel (as if the queue was
not interrupted by the higher level request). On each level, any requesting channel waits for service not more
than 32 arbitration cycles. This means that if channel ‘n’ requests service, no other requesting channel, at the
same request level, will be serviced twice before channel ‘n’ will be serviced.
2.7.2.1 Example A
In the following example (see Figure 23), all channels request in the same priority. It is assumed that the
channels participating in the group arbitrations are channel 0, channel 1, channel 2, and channel 3.
Figure 23. Example A
A D G
Channel 0
E H
Channel 1
B
Channel 2
C F
Channel 3
A - Channels 0 and 3 are asking for arbitration. Channel 0 is the first one
to be served.
B - Channel 2 is served according to the cyclic order since its request
was asserted before the service of channel 0 was ended.
Idle - no request C - Channel 3 is the next one in the cyclic order.
Queued request
D - Channel 0 is the next one in the cyclic order.
The request is pending/served
E - Channel 1 is the next one in the cyclic order.
F - Channel 3 is served following channel 1 since channel 2 is not asking
for service.
G - Channel 0 is the next one in the cyclic order.
H - Channel 1 is the next one in the cyclic order.
2.7.3 Arbitration Between the Groups
Both requests for service of the channel winning the transmit or receive arbitration groups, become pending
requests. A service of a channel can be started immediately or it can be delayed because of a contention on
access to the shared resources (PLB and OPB). A request which is currently activated on the PLB or OPB is
considered as a served request. Since MCMAL has a separate data and control path for the received and
transmit channels, up to two channels can be served simultaneously - one on the PLB and one on the OPB
interfaces (in this case there is not any pending request).

Core Databook IBM
A served request active on a bus causes a request from the other group trying to access the same bus to be
a pending request. When the served request ends its operation on the bus, the pending request becomes a
served request. The requests are served in the order of requesting the access to the shared resource. If both
pending requests (transmit and receive) are at the same arbitration level, the service will be in a flip-flop
manner.
If a new pending request has an arbitration level higher than the current pending request, it is served first. If
the low priority is already served, it will keep getting its service and then remain pending until the end of the
higher priority channel service.
A new pending request at a priority lower than a packet currently served, waits until the high priority request
completes its arbitration cycle (the whole operation both on the PLB and OPB is completed).
2.7.3.1 Example B
This example (see Figure 24) is for channels of the same arbitration priority level that are using the shared
resources for access to the PLB and OPB. When a channel is holding a bus (served request), the second
request is pending.
Figure 24. Example B
A B C
TX1 (low)
TX2 (low)
RX1 (low)
RX2 (low)
Idle - no request A - RX1 has finished its operation on PLB and it is pending until TX1 ends its
Queued request operation on the PLB.
Pending request B - TX2 becomes pending after TX1 has ended its arbitration cycle. It is now
Served request (PLB) waiting until RX1 releases the PLB.
Served request (OPB) C - RX1 has ended its service on the PLB and ended its arbitration cycle.
TX2 is moved from a pending to a served request after the PLB was
released.
In Figure 24 the TX channel processes requests first for the PLB and then for the OPB. The RX channel
processes requests first for the OPB and then for the PLB.
2.7.3.2 Example C
The following example (see Figure 25 on page 67) shows how a high level request (TX2) blocks a low level
pending request from becoming a served request.

132
IBM Core Databook
Figure 25. Example C
A B C D
TX1 (low)
TX2 (high)
RX1 (low)
RX2 (low)
A - TX1 is winning the arbitration on the transmit group. TX2 which will drive
Idle - no request a high level of request, is still idle when TX1 wins the arbitration.
Queued request B - TX2 a high level request becomes a pending request following the end of
Pending request TX1 service.
Served request (PLB)
C - TX2 has to wait until RX1, which is currently served, releases the PLB.
Server request (OPB)
D - RX2 which replaces RX1 at the receive arbitration group, is forced to
remain pending (avoid access to either PLB or OPB) until TX2 ends its
arbitration cycle.
In this example (Figure 25) the TX channel processes requests first for the PLB and then for the OPB. The
RX channel processes requests first for the OPB and then for the PLB.
2.8 Arbitration Between Multiple MCMALs

In order to serve more channels than the number of MCMAL supported channels, or in order to serve any
other number of channels that require the use of more than one MCMAL core in a system, MCMAL cores can
be cascaded. Each MCMAL works independently serving its own channels, but optionally all MCMALs can
share the same arbitration mechanism. This option allows a fairness service mechanism between all chan-
nels, no matter which MCMAL they are connected to.
In this algorithm each MCMAL sees another group of channels (in addition to the RX channels group and the
TX channels group). This group is called the external group, and it reflects the highest arbitration level of the
pending request of all other MCMAL channels (such as channels which are connected to other MCMALs).
MCMAL treats the external group as a regular group as defined in Section 2.7.3, Arbitration Between the
Groups, on page 65. In the case that the external pending request arbitration level is higher than the MCMAL
pending requests, MCMAL does not serve its own channels (no OPB or PLB request is issued by MCMAL). In
case that the external pending request arbitration level is equal to or lower than MCMAL pending requests,
MCMAL serves the pending requests according to their priorities as defined in Section 2.7.3, Arbitration
Between the Groups, on page 65. In that case both MCMAL and one or more of the external MCMALs can
compete for the shared resources (PLB and OPB).
Figure 26 describes the arbitration scheme that includes an external group.

Core Databook IBM
Figure 26. Arbitration Between Multiple MCMALs Scheme
TX group RX group External group
Urgent
High
Low
Queued requests
No requests
The arbitration mechanism is based on transferring information (between the different MCMALs) about the
arbitration level priority of the current served channel in each of the MCMALs. The MAL_ARB_URGNT signal
indicates that at least one of the current served channels (either RX or TX) has an “Urgent” arbitration level
request. The MAL_ARB_URGNT indicates that at least one of the current served channels (either RX or TX)
has a “High” arbitration level request and no channel has an “Urgent” request. When both signals are low, the
current served channels have a “Low” arbitration level request.
Figure 27 shows the connectivity between two MCMALs in one system.
Figure 27. Two MCMALs Connectivity
PLB
DCR
MCMAL1 MCMAL2
EXTR_MAL_ARB_URGNT MAL_ARB_URGNT
EXTR_MAL_ARB_HIGH MAL_ARB_HIGH
MAL_ARB_URGNT EXTR_MAL_ARB_URGNT
MAL_ARB_HIGH EXTR_MAL_ARB_HIGH
OPB
MCMAL1 MCMAL2
channels channels

132
IBM Core Databook
Figure 28 shows the connectivity between multiple MCMALs in one system.
Figure 28. Multiple MCMALs Connectivity
PLB
DCR
Logic OR
MCMAL1 urgent MCMAL2
arbitration
MAL_ARB_URGNT level MAL_ARB_URGNT
MAL_ARB_HIGH MAL_ARB_HIGH
EXTR_MAL_ARB_URGNT EXTR_MAL_ARB_URGNT
EXTR_MAL_ARB_HIGH EXTR_MAL_ARB_HIGH
MCMAL3 MCMAL4
EXTR_MAL_ARB_URGNT EXTR_MAL_ARB_URGNT
EXTR_MAL_ARB_HIGH EXTR_MAL_ARB_HIGH
MAL_ARB_URGNT MAL_ARB_URGNT
MAL_ARB_HIGH MAL_ARB_HIGH
Logic OR
high arbitration
level
OPB
MCMAL1
MCMAL2 MCMAL3 MCMAL4
channels
channels channels channels

Core Databook IBM
2.9 Performance and Latency

This section describes MCMAL from a performance and latency point of view, and contains guidelines for the
system developer who uses MCMAL. Support from an FAE is required to evaluate the expected performance
of the MCMAL core in a particular system.
The performance and latency section describes five areas:
• The service of the channels one at a time, in order to establish the principles of MCMAL operation (See at
Section 2.9.1, MCMAL Latencies in the Framework of a Packet Transfer).
• The simultaneous service of two channels (receive and transmit) and possible assumptions (See Section
2.9.2, Concurrent Rx and Tx Operation).
• PLB-OPB clock ratios other than 1:1 (See Section 2.9.3, Performance and Latency with Clock Ratio of
1:2 or 1:3).
• Steps to increase performance (See Section 2.9.4, Steps that will Increase Bandwidth).
• PLB and EOPB utilization (See Section 2.9.5, PLB, OPB and EOPB Utilization).
Note:
• MCMAL is a master on both PLB and OPB, therefore its latencies arise from its operation on both buses.
• Given a set of ComMacs, MCMAL and PLB4 will achieve much higher bandwidth than the same Com-
Macs attached to MadMal and PLB3.
2.9.1 MCMAL Latencies in the Framework of a Packet Transfer
MCMAL may arbitrate up to a total of 64 requests for service for up to 32 transmit channels and up to 32
receive channels. When a channel gains MCMAL arbitration and it is being served, the number of words
specified by the RX_MAL_BURST_LENGTH and TX_MAL_BURST_LENGTH signals (the burst length) is
transferred from the ComMac to memory, or from memory to the ComMac (for receive or transmit channels,
respectively). If a packet is shorter than the burst length, a smaller number of words is transferred. The same
applies for the last transfer of data in a packet whose length is not an exact multiple of the burst length.
If the packet is longer than the burst length, it takes more than one arbitration cycle to transfer the whole
packet data.
An additional arbitration cycle is required for updating the packet status (read from the ComMac) into the
memory following the end of packet data transfer. Figure 29 illustrates a packet transfer that uses more than
one arbitration cycle.

132
IBM Core Databook
Figure 29. Channel Service
A channel’s request: Time
Request for
Idle Request for data transfer Idle Idle
status transfer
MCMAL service for a channel:
Command
Data Data Status
and data
Other channels might be served
The first time a channel requests service for a packet, MCMAL reads a descriptor from the memory on the
PLB and writes control to the ComMac on the OPB. Then, on the same MCMAL arbitration cycle, MCMAL
transfers the first number of bytes as defined by TX/RX_MAL_BURST_LENGTH between the memory
system and the ComMac. For a transmit channel, data is read from the memory (on the PLB) and then written
to the ComMac on the OPB. For a receive channel, data is read from the ComMac (on the OPB) and then
written to the memory on the PLB.
If the packet is longer than the burst length amount, MCMAL performs additional data transfers with the
channel until all data is transferred. If more than one channel is requesting service, then each channel
performs data transfers with MCMAL only in those cycles in which it gains MCMAL arbitration, that is, the
data transfer for each channel is executed with intervals, according to MCMAL arbitration.
At the end of every buffer, if packet transfer is not complete yet, MCMAL updates the descriptor’s status of
the current buffer and reads the next buffer’s descriptor (this is done during the same MCMAL arbitration
cycle).
Following the data transfer, the channel generates a status and requests service from MCMAL. When the
channel is served, a status is read from the channel (on the OPB) and written to the memory system on the
PLB.
Note that the status phase will differ slightly if the channel uses the back-to-back TX status mechanism. (See
Section 2.4, Back-to-Back TX Status Mechanism, on page 55).
2.9.1.1 Tuning for High Bus Utilization on the PLB and OPB
MCMAL is tuned for high bus utilization on both the PLB and OPB. On every access to the bus MCMAL opti-
mizes the access to the bus.
• During a PLB access, MCMAL receives and transmits data in burst transactions (unless configured oth-
erwise). Since buffers have no alignment restrictions, MCMAL will make up to two non-burst transactions
per a received buffer - the first and last quadwords.
Note: Using unaligned buffers is not recommended as it can decrease performance dramatically.

Core Databook IBM
• During an OPB access, MCMAL is capable of generating a zero wait state burst. The length of the burst
is the RX/TX_MAL_BURST_LENGTH value. If the access is the last access for a transmit channel, then
MCMAL transfers a number of quadwords (from one to the value of RX/TX_MAL_BURST_LENGTH) to
the channel, depending on the number of quadwords in its internal buffer.
• Bigger External LPRAs (MCMAL’s data buffers): The recommended configuration of MCMAL’s PLB
allows longer bursts of up to 16 QW each, which support better utilization of the PLB.
2.9.1.2 Model of System Delay
A master operation on a bus is dependent not only on the master characteristics, but also on the operation of
other masters on the bus, the bus arbiter, and the slave response. In order to calculate MCMAL’s latency the
delay model described in Figure 30 will be used.
Figure 30. Delay Model
Memory system
Memory
EBIU D + Md*(nplb-1)
PLB PAd
MCMAL MALd
OPB OAd
ComMac Cd+ CMd *(nopb-1)
The total delay of the MCMAL operation consists of the following delay elements:
• Memory system latency- The memory system latency includes the latency of the PLB bus access, the
memory controller and the memory itself from the request on the bus until the first data transfer is
acknowledged. From the model point of view it is considered as a single-delay element. The memory-
system delay consists of a delay which is independent of the number of quadwords on the memory trans-
action - D (Dr for PLB read and Dw for PLB write). The other element is dependent on the number of
quadwords on the memory access (MCMAL Burst Length nplb, also being referred as n). This parameter
Md (Mdr for PLB read and Mdw for PLB write), is multiplied by (n-1) in order to get the total delay for the
whole burst. If two different memories for the data and the descriptors are used, with different access
time, there are actually two sets of values of Dr and Dw. The proper value should be instantiated in each
formula, depending on whether it relates to data movement or descriptor transfer.
• PLB arbitration latency- The PLB arbitration latency, PAd, is the average number of cycles per MCMAL
arbitration on the PLB bus. In this model it is assumed that MCMAL uses burst transfers on the PLB, and
therefore a single arbitration cycle is required per n quadwords (burst length).

132
IBM Core Databook
• MCMAL delay - For each arbitration cycle MCMAL logic adds the following overhead (labeled MALd),
which is the sum of the following delays:
— MCMAL arbitration delay (MALarb): Whenever the arbitration slot for the current serviced channel is
finished, it stores the current channel information and fetches (from internal storage) the information
related to the next channel to be served. This delay is constant and equals three cycles.
— MCMAL OPB access delay (MALopb): When MCMAL performs a transaction on the OPB it adds a
delay at the beginning and the end of the transaction (caused by internal architecture). This delay
equals four cycles.
— MCMAL PLB access delay (MALplb): When MCMAL performs a transaction on the PLB it adds a
delay at the beginning and the end of the transaction (caused by internal architecture). This delay
equals four cycles.
• OPB arbitration latency - The OPB arbitration latency, OAd, is the average number of clock cycles per
MCMAL arbitration on the OPB bus. In this model it is assumed that MCMAL uses burst transfers on the
OPB and therefore a single arbitration cycle is required per n quadwords (burst length).
• ComMac latency - The number of cycles between the request on the bus until the first data transfer is
acknowledged, labeled Cd.
• ComMac delay - The number of cycles between two consecutive transactions, labeled CMd.
• nopb should reflect the same payload as nplb, hence nopb=nplb if the ComMac uses the EOPB, and
nopb =4*nplb if not.
Model’s Restriction:
Full symmetry between Rx and Tx is assumed: The same packet sizes, total payload, number of descriptors
per packet, etc.
• The model assumes the Rx and Tx data buffers are 16-byte aligned, thus there is no overhead of initial
access to non-aligned buffers.
• Rx packets, with sizes other than a multiplication of 16 bytes, need an additional single-beat PLB request,
as the model assumes all packet sizes are multiplications of 16 bytes.
Any diversion from the model’s assumptions will result in invalid results.
Note: Even if all restrictions are met, the model represents simplified calculations, and it is reasonable to
expect slight degradation in actual hardware performance.
2.9.1.3 Delays in a Basic Channel-Associated Data Transfer
MCMAL has three basic types of internal delays:
• Arbitration - Arbitration takes place whenever the MCMAL arbitration slot for the current serviced chan-
nel is finished. The arbitration always consumes three clock cycles (even if the new arbitration winner is
the same as in the previous arbitration cycle). MALarb=3 cycles.
• Access to the PLB bus - On every access to the PLB, MCMAL logic adds four overhead cycles. MAL-
plb=4 cycles.
• Access to the OPB bus - On every access to the OPB, MCMAL logic adds four overhead cycles.
MALopb=4 cycles.

Core Databook IBM
2.9.1.4 Delay Calculations
The following delay calculation is based on the definitions from Section 2.9.1.2 , Model of System Delay. The
calculation shows the average number of cycles per a single-burst transfer.
These calculations ignore the overhead associated with beginning of packet, end of packet, and buffer
switching during data transfer (see Section 2.9.1.5 , Descriptor Handling Overhead, on page 75).
The general case calculation for the number of cycles per MCMAL burst (single-arbitration cycle) is:
• Net payload’s PLB cycles = D+Md *(nplb-1) + PAd + MALplb
• Net payload’s OPB cycles = MALarb + MALopb + OAd +Cd+CMd*(nopb-1)
• MCMAL burst = PLB cycles + OPB cycles
• Net bandwidth = number of quadwords in packet * PLB clock frequency/MCMAL burst. (“Net bandwidth”
has no meaning in a real system and is only provided here for comparison reasons).
The following assumptions are used in all examples outlined below:
• Both OPB and PLB run at 133 MHz.
• Neither bus is busy.
Example A
The following example depicts calculation of the basic MCMAL bandwidth (service of one channel at a time),
for a typical system. These are theoretical values and do not include overheads such as descriptor move-
ments.
The example contains two different ComMacs; one uses the OPB and the other one uses the EOPB (the
128-bit wide Extended OPB).
The system parameters are:
Dr=13, Dw=3, PAd=3, Cd=2, CMd=1, Mdr=1, Mdw=1.
Table 10. Example A Values

Channel Does ComMac Use nplb Net payload’s PLB Net payload’s OPB Net bandwidth
EOPB? cycles cycles (MBps)
at 133 MHz
Tx Y 4 23 12 243
Rx Y 4 13 12 340
Tx N 4 23 24 181
Rx N 4 13 24 230
Tx Y 8 27 16 395
Rx Y 8 17 16 515
Tx N 8 27 40 254
Rx N 8 17 40 298
Tx Y 16 35 24 577
Rx Y 16 25 24 694
Tx N 16 35 72 318
Rx N 16 25 72 351

132
IBM Core Databook
2.9.1.5 Descriptor Handling Overhead
The data transfer performed by MCMAL has three elements of overhead:
• Opening a packet - The first descriptor of a packet is read and a control halfword is written to the Com-
Mac. At the same arbitration cycle MCMAL also performs the first data burst of transactions.
• Closing a packet - After the status is ready in the ComMac, it is read by MCMAL and written to the mem-
ory. This operation occupies a MCMAL arbitration cycle.
• Switching buffers - In case the packet includes more than one buffer, MCMAL has to close the current
buffer (update descriptor status) and open a new buffer (read the new buffer’s descriptor). This operation
is done when MCMAL needs more data to complete the channel’s service. It doesn’t require additional
arbitration cycles. On buffer switching, MCMAL writes one word (in receive) to the memory, or two bytes
(in transmit) to close the buffer, and then reads a quadword from the memory.
Figure 31 on page 75 describes the set of operations:
Figure 31. Descriptor Handling Overhead
Opening a packet
Arbitration Descriptor Command Data read (TX) Data write (TX)
read write
Closing a packet
Arbitration Status Descriptor
read write
Switching buffer
Arbitration Data read (Tx) Descriptor Descriptor Data read (Tx) Data write (TX)
write read (complete read of all
the MCMAL burst data)
Arbitration
Operation on the OPB
Operation on the PLB
MCMAL internal delay before and after bus accesses
The general case calculation for the number of cycles per MCMAL descriptor’s overhead is:
• Opening a packet:
— OPcyc on PLB (descriptor read) = MALplb+PAd+Dr
— OPcyc on OPB (command write) = MALopb+OAd+Cd
— OPcyc = OPcyc on PLB + OPcyc on OPB

Core Databook IBM
• Closing a packet
• CPcyc on OPB (status read) = MALopb+OAd+Cd
• CPcyc on PLB (descriptor write) = MALplb+PAd+Dw
• CPcyc = CPcyc on OPB + CPcyc on PLB
• Switching buffers:
— If there’s one descriptor per packet, the “switching buffers” overhead is zero cycles:
• SBcyc on PLB = (MALplb+PAd +Dw) + (MALplb+PAd+Dr)
• SBcyc on OPB = 0
• SBcyc = cycles for switching buffers = SBcyc on PLB
Where Dw = descriptor write, and Dr = descriptor read.
— When handling “m” buffers per packet, the total number of cycles for descriptor’s handling is:
• DOcyc = cycles of descriptors handling per packet = OPcyc + CPcyc + (m-1) SBcyc
Note: The descriptor handling overhead is reduced if the packet size is large and if the number of buffers in
each packet is small.
Example B
The following example depicts calculation of the descriptor handling overhead in a typical system. System
parameters are as in Example A:
Dr=13, Dw=3, PAd=3, Cd=2, CMd=1, Mdr=1, Mdw=1. All buffers are memory aligned.
From the above expressions we get the following values:

• OPcycl = (4+3+13) + (4+0+2) = 26
• CPcycl = (4+0+2) + (4+3+3) = 16
• SBcycl = (4+3+3) + (4+3+13) = 30
• Then DOcycl = 26 + 16 + 30*(m-1)
Table 11 includes the DOcycl according to the number of buffers in a packet, and the percentage of these
values in relation to the overall number of cycles.
Table 11. Example B Values

m DOcycl Number of cycles to transfer Descriptor’s overhead for a
(number of buffers (number of cycles) payload data of 1024 bytes 1024-byte packet (%)
in packet)
Rx 1 42 4*49 = 196 21.4
2 72 4*49 = 196 36.7

4 132 4*49 = 196 67.3
8 252 4*(49+3-1) = 204 123
Tx 1 42 4*59 = 236 17.7
2 72 4*59 = 236 30.5
4 132 4*59 = 236 55.9
8 252 4*(59+13-1) = 284 88.7

132
IBM Core Databook
2.9.2 Concurrent Rx and Tx Operation
The above analysis refers to MCMAL performance and latency as it services one channel at a time (MCMAL
operates only on one of the buses, OPB or PLB, at any given time). This section describes concurrent oper-
ation of both Rx and Tx channels.
Concurrent operation of Rx and Tx signifies simultaneous activity on both the PLB bus and the OPB bus. This
mode of operation saves bus access latency time and improves the overall performance, due to the overlap-
ping of MCMAL internal arbitration, PLB bus access, and OPB bus access.
• 0% overlap - The analysis presented so far.
• 100% overlap/full overlap - Assuming the Rx and Tx packet sizes are the same, we can manipulate the
number of cycles needed on the PLB and OPB according to the 0% overlap analysis, in order to use the
fact that MCMAL supports concurrences of Rx and Tx, and of OPB and PLB access. The full overlap
analysis doesn’t take into account the PLB’s and slave’s pipeline capabilities, and thus a more accurate
model would have shown slightly higher performance. In actuality, this is not important as the actual per-
centage of overlap is never 100%.
The 0% and 100% overlap formulas are:
• 0% overlap number of cycles per packet = 1/2 * [TXplb + TXopb + RXopb + RXplb]
• 100% overlap number of cycles per packet = 1/2 * [max(TXplb, RXopb) + max(TXopb, RXplb)]
• Bandwidth (Mbps) = clock frequency * bytes in packet * 1/number of cycles per packet
Where:
— Number of OPB cycles on Tx (including command and status overhead)= TXopb
— Number of OPB cycles on Rx (including command and status overhead)= RXopb
— Number of PLB cycles on Tx (including descriptor overhead)= TXplb
— Number of PLB cycles on Rx (including descriptor overhead)= RXplb
• Actual performance - In an actual system, the average overlap percentage is expected to be some-
where within the 0 - 100% range. The 0% and 100% analysis presented define the range of expected
performance. This range depends strongly on the model’s restrictions and assumptions. Breaking any of
these will change the range itself (and not just the overlap percentage within the range itself). The overlap
percentage derives from the simplicity of the model, and even though the actual percentage can’t be pre-
dicted, it is degraded by:
— A very loaded PLB
— Small packets
Figure 32. Actual Performance
100% overlap analysis 0% overlap analysis
Actual bandwidth

Core Databook IBM
Example C
The following example depicts calculation of MCMAL bandwidth in concurrent operation for a typical system,
with and without descriptor overhead.
System parameters are the same as in Example A:
Dr=13, Dw=3, PAd=3, Cd=2, CMd=1, Mdr=1, Mdw=1
Table 12. Example C Values (Without the descriptor overhead)

nplb Does Com- Cycles on Cycles on 100% overlap 0% overlap 100% overlap 0% overlap
Mac use PLB OPB cycles per packet cycles per packet Bandwidth Bandwidth
EOPB Tx/Rx Tx = Rx (MBps) (MBps)
at 133 MHz at 133 MHz
4 Y 23/13 12 18 30 472 283
8 Y 27/17 16 22 38 773 448

16 Y 35/25 24 30 54 1134 630
16*41 Y 140/100 96 120 216 1134 630
4 N 23/13 24 24 42 354 202
8 N 27/17 40 40 62 425 274
16 N 35/25 72 72 102 472 333

16*4 N 140/100 288 288 408 472 333
1. 16*4 stands for a packet of 1024 bytes which is transferred in 4 transfers of 16 QW each.
Table 13. Example C Values (With the descriptor overhead, assuming packet sizes 64/128/256/1024 bytes,
using a single descriptor)
nplb Does Cycles on Cycles on 100% overlap 0% overlap 100% overlap 0% overlap
ComMac use PLB OPB cycles per packet cycles per packet Bandwidth Bandwidth
4 Y 53/43 24 48 72 177 118
8 Y 57/47 28 52 80 327 212
16 Y 65/55 36 60 96 567 354
16*4 Y 170/130 108 150 258 907 527
4 N 53/43 36 48 84 177 101
8 N 57/47 52 54.5 104 312 163
16 N 65/55 84 84 144 405 236
16*4 N 170/130 300 300 450 453 302
Note: The bigger the packet is, the larger the bandwidth, as the descriptor overhead splits between more quadwords of data.
Example D
The following example depicts calculation of MCMAL bandwidth for a loaded PLB. System parameters are
the same as in Example C except PLB parameters:
Dr=70, Dw=10, PAd=10, Mdr=1, Mdw=1

132
IBM Core Databook
Still assuming small packets (64/128/256/1024 Bytes) using a single descriptor:
Table 14. Example D Values (Assuming packet sizes 64/128/256/1024 bytes, using a single descriptor)
4 Y 303/243 24 273 297 31 28
8 Y 307/247 28 277 305 61 55

16 Y 315/255 36 285 321 119 106
16*4 Y 504/264 108 384 492 354 276
4 N 303/243 36 273 309 31 27
8 N 307/247 52 277 329 61 51
16 N 315/255 84 285 369 119 92
16*4 N 504/264 300 402 684 338 199
2.9.3 Performance and Latency with Clock Ratio of 1:2 or 1:3
The OPB bus clock cycle time is an integer (N) multiplied by the PLB bus clock cycle time. N is the ratio:
OPB clock cycle time/PLB clock cycle time. This section details the changes in the “Model of system delay”
caused by the PLB and the OPB running at different frequencies.
2.9.3.1 Basic Delay Calculation
MCMAL’s basic delay calculation is still valid even if the OPB frequency is slower.
The way to approach the latency and performance calculation is to separate all calculations to PLB cycles
and OPB cycles, and at the end translate the OPB cycles to PLB cycles, and sum everything together.
PLB clock domain:

• Internal parameters: MALplb
• Memory parameters: D (both Dr and Dw), Md (both Mdr and Mdw)
• PLB arbitration parameters: PAd
OPB clock domain:

• Internal parameters: MALarb, MALopb
• ComMac parameters: Cd, CMd
• OPB arbitration parameters: OAd
— MCMAL burst (counted in PLB cycles) = PLBcycles + N*OPBcycles
2.9.3.2 MCMAL Concurrent Rx and Tx Operation
Since the PLB clock is at least two times faster than the OPB clock (N is 2 or 3), the bottleneck in most cases
will be the OPB bus. The bottleneck intensifies if the ComMacs are not using the EOPB.
The formulas are basically the same as before, with the only difference being “PLB cycles” (not “cycles”) are
compared, and thus wherever OPB cycles appear - they are multiplied by N:
• 0% overlap number of cycles per packet = 1/2 * [TXplb + N*TXopb + N*RXopb + RXplb]
• Full overlap number of cycles per packet = 1/2 * [max(TXplb, N*RXopb) + max(N*TXopb, RXplb)]

Core Databook IBM
• Bandwidth [Mbyte/sec] = PLB clock frequency * bytes in packet * 1/number of cycles per packet
Where:
— Number of OPB cycles on Tx = TXopb
— Number of OPB cycles on Rx = RXopb
— Number of PLB cycles on Tx = TXplb
— Number of PLB cycles on Rx = RXplb
Example E
The following example is an analysis of the same system shown in Example C, with the only difference being
the OPB clock frequency. System parameters are:
Dr=13, Dw=3, PAd=3, Cd=2, CMd=1, Mdr=1, Mdw=1)
Table 15 and Table 16 on page 80 already include the descriptor’s overhead.
Table 15. Example E Values (N = 133/66 MHz = 2)

EOPB? Tx/Rx Tx = Rx (MBps) (MBps)
at 133/66 MHz at 133/66 MHz
4 Y 43/43 24*2 50.5 96 168 88
8 Y 57/47 28*2 56.5 108 301 157
16 Y 65/55 36*2 72 132 472 257
4 N 43/43 36*2 72 120 118 70
8 N 57/47 52*2 104 156 163 109
16 N 65/55 84*2 168 228 202 149
Table 16. Example E Values (N = 133/44 MHz = 3)

EOPB? Tx/Rx Tx = Rx (MBps) (MBps)
at 133/66 MHz at 133/66 MHz
4 Y 43/43 36*3 72 120 118 70
8 Y 57/47 28*3 84 136 202 125
16 Y 65/55 36*3 108 168 315 202
4 N 43/43 36*3 108 156 78 54
8 N 57/47 52*3 156 208 109 81
16 N 65/55 84*3 252 312 135 109
2.9.4 Steps that will Increase Bandwidth
In general MCMAL has the maximal bandwidth when:

• The memory controller responds quickly.
• Transferred payloads are big.
• ComMacs use the EOPB (EMAC4).

132
IBM Core Databook
2.9.4.1 Integration Parameters
• Large external LPRAs (for example RA016X64D2P2W1R1M1).

• Channel’s R/TX_MAL_BURST_LENGTH[0:2] allow the largest transfers (for example “101”).
• MCMAL is the only master on its OPB.
• PLB and OPB clocks are at their maximal frequency - 133 or 166 MHz.
• Separate memories for the data buffers and the descriptor tables.
— The descriptor tables host single-beat operations, while the data movements are burst oriented.
Using an SRAM PLB slave for the descriptors and an SDRAM PLB slave for the data buffers is rec-
ommended.
2.9.4.2 Software Parameters
• Each packet is located in one data buffer, that is, each packet is pointed to by one descriptor.
• It is important that all data buffers be 16 byte aligned.
• Packet sizes are in QW, or preferably in 16 QW multiplications.
• MCMAL is configured to allow Rx and Tx PLB burst sizes of 16 QW.
• Configure MCMAL with a high PLB priority.
• Assure that the descriptors will be ready for MCMAL as soon as it needs them.
2.9.5 PLB, OPB and EOPB Utilization
In general, in order to calculate any bus utilization, the desired payload must be taken into account. Once the
desired payload is known, the descriptor’s overload can be added and the utilization can be calculated.
The utilization calculation presented in this section is derived from the model presented, and inherits its
restrictions and assumptions.
• EOPB- EOPB utilization has no meaning while using a “private EOPB” for MCMAL, as MCMAL is the only
master on that bus.
• PLB- The PLB actually contains 3 buses: Address bus, Read data bus, Write data bus. The numbers cal-
culated in the following formulas represent the handling of two packets: a Tx packet and an Rx packet.
(As in the model, both have the same size, use the same number of descriptors, etc.) As the formulas
include two packets, the results are for full duplex bandwidth.
— Thousands of packets in a second (Rx) = Thousands of packets in a second (Tx) = nPackets
— Full duplex payload [Gbps] = nPackets * packet size[QW] * 128/1,000,000
— Number of QW in a packet’s last transfer = packet size mod nplb = nplb_last
— Cycles per packet on the Address bus = PAd * 2 * [2*m + number of transfers per packet]
— Cycles per packet on the Read data bus = Dr* [2*m + number of Tx transfers] + Mdr* [number of full
Tx transfers *(nplb-1)+ nplb_last-1]
— Cycles per packet on the Write data bus = Dw* [2*m + number of Rx transfers] + Mdw* [number of full
Rx transfers*(nplb-1)+ nplb_last-1]
— Read/Write data bus utilization = (cycles per packet on the Read/Write data bus * nPackets)/(PLB
clock frequency[MHz] * 1000)
Example F
The following example shows the PLB utilization for packets of size 64, 256, and 1024 bytes, in the same
typical system shown in Example C. System parameters are:
Dr=13, Dw=3, PAd=3, Mdr=1, Mdw=1

Core Databook IBM
Note that the full duplex payload varies in Table 17 on page 82:
Table 17. Example F Values (PLB utilization for packet sizes 64/256/1024 bytes)
packet size nPackets Full duplex Address bus Read data bus Write data bus Read data bus Write data bus
[QW] payload (Rx+Tx cycles per (Rx+Tx cycles per (Rx+Tx cycles per utilization utilization
(bps) packet) packet) packet)
41 1954 1G 18 42 12 - -
16 489 1G 18 54 24 19.85% 8.82%
64 123 1G 36 138 78 12.76% 7.21%
4 196 100 M 18 42 12 6.19% 1.77%
16 49 100 M 18 54 24 1.99% 0.88%
64 13 100 M 36 138 78 1.35% 0.76%
1. The example doesn’t include 1 Gbps full duplex payload for packet size = 4 QW, as this bandwidth isn’t supported under the exam-
ple’s system parameters, thus making the utilization numbers non-valid.

132
IBM Core Databook
3. Software Interface
3.1 Buffer Descriptor

The software interface for buffer descriptor processing consists of a set of registers within MCMAL and a set
of circular queues in memory (internal or external). Each transmit and receive ComMac channel has a
descriptor table that contains packet location information allocated to the channel.
Note: Since MCMAL is using flat addressing on the PLB, the physical memories can be located anywhere on
the PLB address space. The only limitation MCMAL presents is that each data structure it works with (data
buffers and buffer descriptor tables) will not cross a 4 GB address border.
The software (device driver) fills the descriptor table with packets to be transmitted, or memory locations to be
filled with incoming packets for the ComMac channels. Meanwhile, the hardware processes these descriptors
and fills their status fields.
Each individual transmit or receive channel has a single table. These tables are managed independently of
each other. This section describes the individual transmit and receive interfaces.
Data associated with each ComMac transmit or receive channel is stored in buffers. Each buffer is referenced
by a buffer descriptor which is located in the PLB memory space (this can be internal or external memory).
The allocation of buffer descriptors to the various ComMacs (where each ComMac may have several TX and
RX channels), is defined by programming the MCMAL “channel BD table pointer” register associated with the
channel. The ComMac “channel BD table pointer” points to the head of the BD table in memory. The BD table
can start in the boundaries of 8-Byte aligned addresses.
The buffer descriptor table forms a circular queue with a programmable length. The last descriptor in the table
is defined by setting the Wrap bit in the status/control field (see Section 3.1.3.3 , Status/Control Field Format,
on page 89). If there is no Wrap bit set in the table, then MCMAL automatically wraps after processing 256
descriptors (the maximum number of available descriptors).
The format of the buffer descriptor (see Figure 33) is the same for all ComMacs, and has the same structure
for both transmit and receive:
- The most significant halfword in each buffer descriptor contains a status/control halfword. This field con-
tains two parts: the first part (6 bits) is BD handling information used by the MCMAL for descriptor pro-
cessing, the second field (10 bits) is content specific for each ComMac.
- The second halfword determines the 4 MSbs of the data buffer pointer and the data length (in bytes) ref-
erenced in this buffer descriptor.
- The second word in the buffer descriptor contains the 32 LSbs of the data buffer pointer that points to
the actual buffer in memory.
Figure 33. Buffer Descriptor Structure
0 15 16 20 31
Offset +0 Status/Control Buffer pointer Data length

(4 MSbs)
Offset +4 Buffer pointer (32 LSbs)
SA14-2653-01 Software Interface

Core Databook IBM
A packet may reside in as many buffers as necessary (transmit or receive). Each buffer has a maximum
length of (4 KB-16) bytes. In TX channels, the buffer descriptor’s length field is written by the device driver
and defines the number of bytes in the data buffer that is identified by the data buffer pointer. In RX channels,
the buffer descriptor’s length field is written by MCMAL, and defines the number of bytes written by MCMAL
to the buffer that is identified by the data buffer pointer (see Section 3.1.2, Receive Software Interface, on
page 87).
When processing a packet, MCMAL does not assume that all buffers of the current packet are already valid.
It expects the buffers to be ready in due time to be transmitted or received. (Failure of the software to provide
the descriptors in due time may result in an error.)
Figure 34 describes the structure of the packet in memory.
Figure 34. Packet Memory Structure
BD tables
(internal or external memory) Memory (internal or external)
Descriptor 0
Descriptor 1
MCMAL’s BD table
pointer register .......
Buffer pointer
Data buffer
ComMac channel 3
BD table pointer
W=1
Buffer pointer
* W=1 means the wrap bit is set for this descriptor
It is recommended, from a performance point of view, to keep all buffers 16 bytes aligned in address and size.
Software Interface SA14-2653-01

132
IBM Core Databook
3.1.1 Transmit Software Interface
MCMAL processes the TX buffer descriptors according to the transmission channel’s request. When a
ComMac TX channel requests that a new packet be processed, MCMAL begins processing the next
descriptor in the BD table. Once a channel is enabled in MCMAL, (this is done by setting the related bit in the
active channel registers, see Section 3.3.2, Channel_Active Registers, on page 106), a channel may request
MCMAL service. When a ComMac TX channel requests MCMAL service, MCMAL accesses the first buffer
descriptor in that channel’s buffer descriptor table. The ComMac channel table pointer register points to the
buffer descriptor table. If that descriptor is ready, it will start processing the buffer.
When MCMAL begins processing a packet, it writes the content of the status/control field into the ComMac.
This information, (depending on ComMac’s implementation), may be used by the ComMac to configure each
packet.
Once all data from the current buffer has been transferred to the channel, MCMAL moves on to the next
buffer descriptor in the table.
If a given buffer descriptor indicates that it contains the last section of the current packet, MCMAL informs the
channel that the last data transferred to the channel completed the transfer of a data packet. At this point, the
ComMac asks MCMAL to read the packet status and transfers it into the status/control field of the packet’s
last buffer descriptor.
The ComMac channel may ask MCMAL to process the next buffer descriptor and the same packet handling
process will be initiated. The first descriptor in the next packet follows the descriptor marked “last” in the
previous packet.
3.1.1.1 Wrapping the BD Table for Transmit
When MCMAL processes the buffer descriptor (while handling a packet for the ComMac channel), it may
encounter a Wrap indication within a buffer descriptor control field. This causes MCMAL to go back to the
beginning of the channel’s buffer descriptor table for the next descriptor buffer. (This will also happen when
MCMAL reaches the maximum number of descriptors.) The wrapping in the BD table, like all other BD table
handling processes, is transparent to the ComMac.
3.1.1.2 Continuous Mode for Transmit
After using a buffer descriptor, MCMAL sets the buffer descriptor control to the not-ready state. In this way,
MCMAL will not use the same buffer descriptor a second time until the software has processed the not-ready
buffer descriptor and changed it to be Ready again. While the Continuous Mode (CM) bit is set in the
status/control field, MCMAL will not clear the Ready bit. The Continuous Mode allows retransmission of the
current data buffer without software intervention. This mode is generally used by protocols in which frequent
retransmission is an integral part of the protocol itself. In such cases, retransmission can be performed
without software intervention.
3.1.1.3 Retransmit a Packet
MCMAL is capable of retransmitting the last packet following a request from ComMac. If retransmission is
requested by the ComMac, it must be assured that all the buffers of the retransmitted packet are available
and were not reprocessed by the device driver. In a regular operation, MCMAL resets the Ready bit of each
buffer descriptor, when finished with the processing of this descriptor. When MCMAL is requested by the
ComMac to retransmit the last packet (the retransmit bit, in the ComMac TX channel Status Halfword, is set),

Core Databook IBM
MCMAL doesn’t reset the READY bit in the last processed buffer descriptor, activate the End of Packet inter-
rupt, nor write the status back to the descriptor in the memory. In this case of a retransmission request,
MCMAL doesn’t consider it as an End of Packet event.
On the next service request from this channel, MCMAL will start transmitting the packet again, starting from
the packet’s first descriptor.
Note: The last processed buffer descriptor can be either the last descriptor of the packet, or in case of early
packet termination, the buffer descriptor that was being processed when the transmit channel initiated an
early packet termination. MCMAL will retransmit the packet regardless of the Ready bit value.
During the retransmission of the packet, MCMAL may use descriptors on which the Ready bit was already
cleared. Therefore, the device driver should not reuse a packet’s descriptors before the Ready bit of the last
descriptor is cleared.
Note:
1. In the case of descriptor not valid, which is the first one in TX channel, ComMac is not allowed to return
a status that contains a retransmission request.
2. While using the back-to-back TX mechanism it is forbidden to ask for a retransmission.
3.1.1.4 Descriptor Not Valid/Descriptor Error for Transmit
When MCMAL accesses a buffer descriptor, it checks whether the Ready bit is set. If the Ready bit is not set,
two cases apply (special treatment of the READY bit is performed in a retransmit request of a packet):
For cases when the READY bit is not set:
Descriptor Not Valid
If the descriptor is the first descriptor of the packet, MCMAL informs the channel that data is currently
unavailable. Further handling of this scenario is ComMac specific. The channel might either instruct
MCMAL to access the same buffer descriptor periodically (by keeping its service request to MCMAL
active) until it becomes ready, or ‘give up’ on the descriptor, completing the end-of-packet protocol with
MCMAL. The channel might also indicate the buffer descriptor status to the device driver via an interrupt.
Anyway, in this case the ComMac should eventually complete the packet transfer protocol with MCMAL.
Following a descriptor not valid indication, MCMAL’s BD pointer continues pointing to the same location
in the BD table. The next time a descriptor read is initiated by the ComMac, MCMAL will search for the
buffer in the same location.
Descriptor Error
If the descriptor is not the first descriptor of the packet then this situation is treated as a descriptor error:
MCMAL deactivates the channel and from its point of view, the processing of the current packet has
ended. Software may learn about this situation from one of two MCMAL interrupts (or from both). The first
one is a non-maskable interrupt that indicates the number of the TX channel in which the descriptor error
had occurred (interrupt bit for each TX channel, see Section 3.3.4.3 , Descriptor Error Interrupt Registers,
on page 110). The second one is a maskable interrupt which indicates a descriptor error event, regard-
less of the channel number (one interrupt bit for all the channels, see Section 3.3.4.1 , Error Status Reg-
ister, on page 107). For more information about Error Handling, see Section 3.2.5, Error Handling, on
page 94.

132
IBM Core Databook
For the case of retransmission:
When the current transmitted packet is a retransmitted packet, all descriptors, except the last, are valid
even if the READY bit is not set. In this case, (not the last descriptor) MCMAL processes the packet
descriptors regardless of the READY bit value. If the READY bit of the last descriptor in the retransmitted
packet is not set, MCMAL treats it as a descriptor error. MCMAL handles the descriptor error, as
described above for the case that the packet isn’t a retransmitted one.
3.1.1.5 Scroll Descriptors for Transmit
MCMAL may be configured by software, in the case of early packet termination, to scroll in the buffer
descriptor table to the first descriptor of the next packet.
When a multiple-buffer packet is terminated early by the ComMac, while MCMAL processes a buffer which is
not the last in the packet, MCMAL can operate in one of the following ways:
The MAL_Scroll_Dsc in the configuration register is set:
In this case MCMAL will read the status word from the ComMac channel. Then MCMAL will reset the
READY bit in all the remaining buffer descriptors of the current packet. In addition, MCMAL will write the
status to all the buffer descriptors. On the next service of this channel, MCMAL will fetch the first descrip-
tor of the next packet.
The MAL_Scroll_Dsc in the configuration register is clear:
In this case MCMAL will read the Status word from the ComMac channel. Then MCMAL will terminate the
current channel service by resetting the READY bit of the last processed buffer descriptor (the one in
which there was an early termination) and will write the status only to this descriptor. On the next service
of this channel, MCMAL will fetch the next descriptor in the current packet. In this case, the software is
responsible to monitor MCMAL’s location in the buffer descriptor table.
In the case that the ComMac requests retransmit of the early terminated packet (when the “retransmit” bit in
the ComMac status is high), MCMAL will retransmit the packet regardless of the MAL_Scroll_Dsc bit.
3.1.2 Receive Software Interface
MCMAL uses the RX channel buffer descriptor in a manner similar to that used for transmission. Once an RX
ComMac channel requests that a new packet be processed, MCMAL starts processing the channel’s next
buffer descriptor in the table. Once a channel is enabled in MCMAL, the channel may request MCMAL
service. When it does, MCMAL accesses the first buffer descriptor (in that channel’s buffer descriptor table)
that is pointed to by the ComMac channel table pointer register. If that descriptor is ready (empty for RX),
MCMAL will start processing the buffer.
When it begins processing each packet, MCMAL writes the contents of the status/control field into the
ComMac. This information (defined by ComMac’s implementation), can be used by the ComMac for a per-
packet configuration.
Once data is received from the media, MCMAL moves the data from the RX channel FIFO into the data buffer
pointed to by the first buffer descriptor. The current buffer descriptor may be closed for two reasons: there is
no more room left in the buffer, or the ComMac channel indicated that the packet reception ended. If addi-
tional buffering space is needed for the current packet, MCMAL moves on to the next buffer descriptor. As
each buffer descriptor is closed, MCMAL updates the length field with the actual amount of bytes written into

Core Databook IBM
the buffer. The maximal length of the buffers for each channel is defined by a configuration register (see
Section 3.3.7, RX-Channel-Buffer-Size Registers, on page 113). The maximal receive buffer length is defined
per channel.
Once the ComMac channel indicates that the packet reception has ended, it is expected to request that
MCMAL update the received packet status in the BD status/control field. MCMAL updates the packet status
and notifies that ComMac. At this point the packet is considered received and the ComMac may request that
MCMAL begin the process of receiving a new packet. The first buffer of the next packet is the buffer in the BD
table that followed the last descriptor of the previous packet.
3.1.2.1 Wrapping the BD Table For Receive
When MCMAL processes the buffer descriptor, it may encounter a Wrap indication within a buffer descriptor
control field. This causes MCMAL to go back to the head of the channel’s buffer descriptor for the next buffer
descriptor. (This also happens when MCMAL reaches the maximal number of descriptors.)
3.1.2.2 Continuous Mode For Receive
After using a buffer descriptor, MCMAL sets the buffer descriptor control to the Not-Empty state. In this way,
MCMAL will not use the same buffer descriptor a second time until the software has processed the not-empty
buffer descriptor and set it to Empty again. MCMAL will not clear the Empty bit while the CM (Continuous
Mode) bit is set in the status/control field. The Continuous Mode is generally used by protocols where
frequent collisions are an integral part of the protocol itself (forcing the ComMac to abort a reception process
and restart). In such cases, re-reception can be performed without software intervention.
3.1.2.3 Descriptor Error For Receive
When MCMAL accesses a buffer descriptor it may find that the Empty bit is not set. In the case of an RX
channel descriptor, this situation is considered as a descriptor error. MCMAL deactivates the channel and
from its point of view, the processing of the current packet has ended. Software may learn about this situation
from one of two MCMAL interrupts (or from both). Non-maskable interrupt, which indicates the number of RX
channel, which is associated with the descriptor error (interrupt bit for each RX channel, see Section 3.3.4.3 ,
Descriptor Error Interrupt Registers, on page 110) or maskable interrupt which indicates descriptor error,
regardless of the channel number (one interrupt bit for all the channels, see Section 3.3.4.1 , Error Status
Register, on page 107). For more about Error Handling see Section 3.2.5, Error Handling, on page 94.
3.1.2.4 Buffer Length For Receive
The maximum length of a RX buffer descriptor is predetermined for all RX descriptors in each channel. The
data-length value is programmable through a set of MCMAL registers (see Section 3.3.7, RX-Channel-Buffer-
Size Registers, on page 113). The actual data length field within the RX buffer descriptor is written by
MCMAL. If the buffer is completely filled up, the value written will match the value programmed into the
matching RX-Channel-Descriptor data-length register. If the buffer is only partially filled up (for example,
when the RX packet ended before running out of buffer space), the actual amount of space filled is written
into the length field.

132
IBM Core Databook
3.1.3 Descriptor Buffer Status/Control Fields
The following section details the status/control field bits.
3.1.3.1 Status/Control Field Contents
The information fields within the status/control field can be divided as follows:
• Information from software directed to MCMAL and ComMac containing MCMAL-related buffer descriptor
processing information:
— Buffer Ready/Not Ready (determines the buffer’s validity)
— Wrap to top of table or continue to next descriptor
— In a transmit buffer descriptor - Is the current buffer the last one in the packet?
— Continuous or normal mode (that is, should MCMAL change the Ready/Not Ready value)
• ComMac Channel Configuration Information:

— Should the channel generate an interrupt following the end of packet processing
— Protocol specific configuration
• Information From MCMAL And ComMac Directed To Software with MCMAL generated status informa-
tion:
— Buffer Ready/Not Ready (passes the buffer handling to software)
— In receive buffer descriptor - Is the current buffer the first one in the packet
— In receive buffer descriptor - Is the current buffer the last one in the packet
• ComMac Channel Generated Status Information:

— Protocol specific error and status information (transmit and receive)
3.1.3.2 Status/Control Field Handling
When MCMAL accesses a new buffer descriptor, the status/control word is written to the ComMac channel.
This allows the channel to configure itself for the current packet.
For all “intermediate” buffer descriptors (all descriptors that do not contain the packet’s ending), the
status/control field is written by MCMAL (rather than the ComMac). In this case, the status/control field indi-
cates that the current buffer is not the last one in the current packet.
As MCMAL finishes processing the last buffer descriptor in a given packet, it reads the channel’s status (via
an OPB transaction) and writes it into the buffer descriptor’s status/control field.
In effect, since all of the various control and status fields do not overlap, the status/control halfword is
read/written as a whole. Each agent (MCMAL, ComMac channel and software) reads the entire status/control
halfword, relates to specific fields of interest, and updates another subset of fields within the same halfword.
While an agent modifies its related fields, all other fields remain unchanged.
3.1.3.3 Status/Control Field Format
The status/control halfword (see Figure 35) is divided into ComMac channel data and MCMAL related data.
As explained above, the MCMAL related fields are either aimed at controlling MCMAL or written by MCMAL
for use by the software. The MCMAL fields are of no interest to the ComMac (except the Ready and Empty
bits (in Figure 36 on page 91)).

Core Databook IBM
The same applies to the ComMac channel fields. The ComMac related fields are either aimed at controlling
the ComMac or written by ComMac for use by the software. These fields are of no interest to MCMAL.
MCMAL will not manipulate the ComMac related fields, and ComMac is not allowed to manipulate the
MCMAL related fields. For further explanations regarding the status/control halfword manipulations, see
Section 2.2.7, ComMac-MCMAL Status/Control Exchange, on page 38.
3.1.3.4 TX Status/Control Field Format
Figure 35. TX Status/Control Field
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
R W CM L Res I * * * * * * * * * *
MCMAL related data ComMac channel related data
* ComMac-specific control or status fields
Note: The bit numbering in Figure 35 relates to the buffer descriptor’s fullword which contains both the sta-
tus/control and the length fields.
Table 18. TX Status/Control Field Descriptions (Page 1 of 2)

0 R Ready This bit is set by the device driver and is cleared by MCMAL.
The device driver sets this bit after preparing the buffer for transmission.
MCMAL clears this bit when finished processing the buffer descriptor. MCMAL
doesn’t clear the Ready bit in the case of a Packet retransmission request and in
case of Continuous Mode (see Section 3.1.1.3 , Retransmit a Packet, on page 85
and Section 3.1.1.2 , Continuous Mode for Transmit, on page 85).
1 W Wrap 0 - This is not the last data buffer descriptor in the buffer descriptor table.
1 - This is the last data buffer descriptor in the buffer descriptor table. After this
buffer has been used, MCMAL will transmit data from the first descriptor buffer in
the table.
This bit is controlled by software only. It controls MCMAL activities, and does not
affect the ComMac channel.
2 CM Continuous 0 - Normal Operation

Mode 1 - Continuous Operation. After this buffer descriptor is closed, the R-bit is not
cleared by MCMAL. This ensures that the data buffer is ready for transmission
when MCMAL next accesses this buffer descriptor. However, the R-bit is cleared if
an error occurs during transmission.
This bit is controlled by software only. It controls MCMAL activities and does not
3 L Last 0 - This is not the last buffer in the current packet.

1 - This is the last buffer in the current packet.
This bit is controlled by software only. It controls MCMAL activities, and does not
4 Reserved This bit is reserved. It is assumed that this bit is set to zero by the software.

132
IBM Core Databook
Table 18. TX Status/Control Field Descriptions (Page 2 of 2)

5 I Interrupt 1 - After finish processing the current buffer, if this bit is ‘1’, the “End-of-Buffer” field
in the End Of Buffer interrupt status register is set and the End Of Buffer interrupt is
asserted.
0 - There is no action taken by MCMAL once it reaches the end of the current
buffer.
MCMAL asserts the End Of Buffer interrupt after it updates the buffer descriptor’s
status field.
This bit is controlled by software only. It controls the MCMAL activities and does not
affect the ComMac.
6:15 These bits are ComMac specific and may contain control fields generated by the
software in order to control the ComMac channel. They may also contain status
fields, generated by the ComMac channel, that will be processed by software.
3.1.3.5 RX Status/Control Field Format
Figure 36. RX Status/Control Field
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
E W CM L F I * * * * * * * * * *
MCMAL related data ComMac channel related data
* ComMac-specific control or status fields
Note: The bit numbering in Figure 36 relates to the buffer descriptor’s fullword which contains both the sta-
tus/control and the length fields.
Table 19. RX Status/Control Field Description (Page 1 of 2)

0 E Empty 0 - The data buffer associated with this buffer descriptor has been filled with received
data, or data reception has been aborted due to an error condition. Software is free to
examine or write to any fields of this buffer descriptor. While this bit is set to Not
Empty, MCMAL will not use this buffer descriptor again.
1 - The data buffer associated with this buffer descriptor is empty, or reception is cur-
rently in progress. This buffer descriptor and its associated receive buffer are owned
by MCMAL. Once the E-bit is set, software should not write to any fields of this RX
buffer descriptor.
MCMAL clears this bit after the buffer has been filled with received data or after an
error is encountered. Software sets this bit to Empty after preparing the buffer for
reception. This bit controls MCMAL and software activities. See “Continuous Mode”
description for Bit 2 in Table 19.
1 W Wrap 0 - This is not the last data buffer descriptor in the buffer descriptor table.
1 - This is the last data buffer descriptor in the buffer descriptor table. After this buffer
has been used, MCMAL will transfer data to the first buffer descriptor in the table.
This bit is controlled by software only. It controls MCMAL activities and does not affect
the ComMac channel.

Core Databook IBM
Table 19. RX Status/Control Field Description (Page 2 of 2)

2 CM Continuous 0 - Normal Operation
Mode 1 - Continuous Operation. After this buffer descriptor is closed, the E-bit is not cleared
by MCMAL. This ensures that the data buffer is ready to receive data when MCMAL
next accesses its buffer descriptor. However, the E-bit is cleared if an error occurs
during reception.
the ComMac channel.
3 L Last 0 - This is not the last buffer in the current packet.

1 - This is the last buffer in the current packet.
This bit is updated by MCMAL following the activity of the channel.
4 F First 0 - This is not the first buffer in the current packet.

1 - This is the first buffer in the current packet.
This bit is updated by MCMAL following the activity of the channel.
5 I Interrupt 1 - After finish processing the current buffer, if this bit is ‘1’, the “End-of-Buffer” field in
the End Of Buffer interrupt status register is set and the End Of Buffer interrupt is
asserted
0 - no action is taken by MCMAL at the end of the current buffer.
MCMAL asserts the End Of Buffer interrupt after updating the buffer descriptor’s sta-
tus field.
the ComMac.
6:15 These bits are ComMac specific, they may contain control fields generated by the
software in order to control the ComMac channel. They may also contain status fields,
generated by the ComMac channel, to be processed by software.
3.2 Software Initiating and Using MCMAL
3.2.1 Initiating MCMAL
MCMAL initialization includes two parts: configuration and channel activation.
The configuration includes two steps:

1. Setting MCMAL configuration - This step is done only following power on reset or after MCMAL soft reset.
MCMAL configuration includes setting the following registers:
• MCMAL Configuration Register (MCR). This register is used to define MCMAL operation on the PLB
and OPB.
• Interrupt Enable Register (IER). This register is used to enable error initiation interrupts. For a full
description of MCMAL registers see Section 3.3, Registers, on page 100.
2. Setting a channel’s specific configuration - This information may be changed at any time in which the
related channel is not active. (The related bit in the TX or RX Channel Active Set Register is cleared.) The
channel configuration is defined by the following registers:
• RCBSx - RX Buffer Size. This register defines the length of the RX buffers in the memory.
• Channel Table Pointer Registers:
— TX / RX Base address register - defines the channel’s buffer descriptor table pointer’s 4 MSbs.
— TXCTPxR or RXCTPxR - defines the channel’s buffer descriptor table pointer’s 32 LSbs.
For a full description of MCMAL registers see Section 3.3, Registers, on page 100.

132
IBM Core Databook
Setting the channel’s specific configuration can be done as part of MCMAL initialization or as part of the
ComMac initialization process. In order to activate a channel, the following actions should be taken:
• The channel has to be configured in MCMAL.
• The related bit in Channel Active Set Register (CASR) has to be set.
• The channel’s operation must be enabled (ComMac’s configuration).
3.2.2 Channel Reset
A channel may be reset by software at any time. The channel has to be deactivated first in MCMAL by writing
‘1’ to the channel-related bit in the Channels Active Reset Register (CARR), (see Table 22 on page 100).
Then the channel has to be reset in the ComMac (a ComMac specific action).
In order to reset a ComMac channel the software has to deactivate (reset) the channel in MCMAL before
resetting the ComMac. The reactivation of the channels is done in the same order - activating the channel in
MCMAL before enabling the ComMac’s channel.
A channel is reset by the hardware following indication of an error during a channel operation. For more infor-
mation on error processing, see Section 3.2.5, Error Handling, on page 94.
3.2.3 Soft Reset
3.2.3.1 Overview
Soft Reset is used to generate a general reset to MCMAL through a software command.
Following the soft reset process, MCMAL hardware (registers, interface and internal state machines) return to
the power on reset value.
MCMAL soft reset causes a clean exit from the PLB pipelining, while not ensuring the success of the current
packet being transferred (both RX and TX) or the previous TX packet as well, if working with the back-to-back
TX mechanism.
3.2.3.2 Soft Reset Flow
a. Whenever desired, the software can activate a soft reset by writing ‘1’ to the MCMAL Soft Reset bit (bit 0)
in the configuration register (for the exact address see <Ital>Chapter 3.3.1, “MCMAL Configuration Register,”
on page 104).
b. MCMAL starts its soft reset algorithm. This step will take several PLB cycles; the exact number depends on
other PLB inhabitants as well.
c. MCMAL clears the MCMAL Soft Reset bit (bit 0) in the configuration register when it’s done and ready.
d. Software must poll the register to check when the soft reset sequence is over.
e. Software configures MCMAL as described in the Section 3.2.1, Initiating MCMAL, on page 92.

Core Databook IBM
3.2.4 Interrupts
MCMAL has five interrupt lines. Two interrupt lines, one for TX and one for RX (TX End of Buffer interrupt
(TXEOB) and RX End of Buffer interrupt (RXEOB), are used for interrupt events on the packet flow. An addi-
tional two interrupt lines, one for TX and one for RX (TX Descriptor Error (TXDE) and RX Descriptor Error
(RXDE)), are used to report descriptor errors on a per channel basis. The fifth interrupt (System Error (SERR)
interrupt) is used to report system errors. The interrupt lines may be connected to different interrupt bits in the
system interrupt controller, or joined together into a single interrupt (logical OR).
• TXEOB interrupt line is used to report end of buffer or end of packet for a specific TX channel. A bit for
the related channel is asserted in the TXEOBISR (see Section 3.3.3, End of Buffer Interrupt Status Reg-
isters, on page 106).
• RXEOB interrupt line is used to report end of buffer or end of packet for a specific RX channel. A bit for
the related channel is asserted in the RXEOBISR (see Section 3.3.3, End of Buffer Interrupt Status Reg-
isters).
• TXDE interrupt line is used to indicate a descriptor error event in a specific TX channel table pointer. A bit
for the related channel is asserted in the TXDEIR (see Section 3.3.4.3 , Descriptor Error Interrupt Regis-
ters, on page 110).
• RXDE interrupt line is used to indicate a descriptor error event in a specific RX channel table pointer. A bit
for the related channel is asserted in the RXDEIR (see Section 3.3.4.3 , Descriptor Error Interrupt Regis-
ters, on page 110).
• SERR interrupt is used to report a system error indicated by MCMAL. For more information on handling
the SERR interrupts, see Section 3.2.5, Error Handling, on page 94 and Section 3.3.4, MCMAL Error
Registers, on page 107.
3.2.5 Error Handling
3.2.5.1 Overview
MCMAL has an error handling mechanism which handles errors on a channel basis. Within a ComMac
channel, errors may arise from the ComMac (detected as an OPB error) or from the memory access opera-
tions involved in MCMAL activity (detected as a PLB/descriptor error).
When a bus error occurs, MCMAL is prompted with an OPB/PLB error signal. The errors sensed by MCMAL
are OPB errors and PLB errors. Almost every “error” is related to a channel and therefore channel operation
is stopped. MCMAL cannot allocate the channel related to a PLB Mirq, and therefore channel operation is not
stopped.
Another kind of error is a descriptor error. Each descriptor is related to a channel, and therefore channel oper-
ation is stopped.
MCMAL keeps a record of the channels in which errors were encountered and are now inactive. It also keeps
a record of the characteristics of the first (or last) error detected.
3.2.5.2 Error Detection
The MCMAL communication, both with ComMacs and with memory, is carried out via the OPB or PLB. As
long as this bus communication is error-free and no descriptor error is detected, MCMAL maintains normal
activity with the channels set by 4XX as active in the Channel Active Register (CAR).

132
IBM Core Databook
When an error is detected while performing a transfer for a channel, MCMAL asserts a maskable interrupt
signal (MAL_SERR_INT). If the identity of the channel is known, then MCMAL immediately halts the dialogue
with the channel. No further transactions are made, and that channel is registered by MCMAL as a non-active
channel. MCMAL resets the channel by resetting its active bit in the Channel Active Register. Software must
access the Channel Active Register in order to reactivate the channel.
If the identity of the channel which is causing the error is not known (as is the case for PLB Mirq), then
MCMAL continues to work normally. Error resolution and channel de-activation are in the software’s respon-
sibility.
3.2.5.3 Indicated Errors
Error description is stored in the Error Status Register (ESR), (see Section 3.3.4.1 , Error Status Register, on
page 107).
Descriptor Error
The descriptor error is indicated when a descriptor data error was recognized during access to the descriptor
table. The error can occur during TX or RX transmission.
During RX transmission, a descriptor error is indicated when MCMAL accesses a descriptor in which the
Empty bit is cleared.
During TX transmission, a descriptor error is indicated when MCMAL accesses a descriptor in which the
Ready bit is cleared, except for the following cases:
• On access to the first buffer descriptor in a TX packet.
• On access to a buffer descriptor which is not the last in the retransmitted packet.
As a result of this error, the following actions are taken by MCMAL:
• The Active bit of the related channel is reset and the channel activity is halted until software initiates the
channel activity.
• The TX Descriptor Interrupt Error Register (TXDEIR) bit of the related TX channel, or RX Descriptor Error
Register (RXDEIR) bit of the related RX channel, is set, causing the rise of non-maskable TXDE interrupt
or RXDE interrupt respectively.
• MAL_TX_DSC_ERR or MAL_RX_DSC_ERR is asserted towards the ComMac for single cycle clock.
• When the channel is reactivated, MCMAL points to the descriptor at the head of the DB (data buffer)
table.
OPB Time-Out Error
This error indicates that an OPB time-out error was reported by the OPB arbiter.
Following this error, the active bit of the related channel is reset and the channel activity is halted until it is
initiated by the software. When the channel is reactivated, MCMAL points to the descriptor at the head of the
DB table.

Core Databook IBM
OPB Error
This error signifies that an OPB error was indicated.
DB table.
PLB Read Error
This error signifies that a PLB read error was indicated (from the PLB slave).
DB table.
PLB Write Error
This error signifies that a PLB write error was indicated (from the PLB slave).
DB table.
PLB Mirq
This error signifies that a PLB interrupt was indicated (from the PLB slave).
Since in this case MCMAL cannot determine which channel caused the interrupt, operation is not halted for
any of the channels. MCMAL indicates this has occurred (via MAL_SERR_INT) and it is the software’s
responsibility to handle it.
PLB Time-Out Error
This error signifies that a PLB time-out was reported by the PLB arbiter.
DB table.
3.2.5.4 Error Handling Registers
MCMAL error handling logic includes two registers (see Figure 37 on page 97).
Error Status Register (ESR)
This register (see Figure 37 on page 97) holds the information about the error that occurred and the interrupts
status. The register includes the following fields:

132
IBM Core Databook
Error status - This field holds the error information. The information includes the number of the channel on
which the error occurred (if known) and the type of the error. The error can be either the last detected error or
a locked error if “Locked error mode” is active. See Section 3.2.5.5 , Operational Error Modes, on page 97 for
description of the Locked error mode.
The error status field includes an “Error Valid” bit which indicates whether there is valid error information in
the error status field or not. The error status field is not valid when the “Error Valid” bit is cleared (by writing ‘1’
to this bit).
Interrupt status - Every error detected by MCMAL sets a related bit in the interrupt status field. The interrupt
status bits may be cleared by software by writing ‘1’ to the bit to be cleared. The bits in this field are accumu-
lative. This indicates more than one interrupt may be indicated in the register.
Figure 37. Error Status Register Field
Error status bits Interrupt status bits
Non-accumulative field Accumulative field

overwritten in non-locked mode
locked in locked mode
Valid bit for
error status bits
Interrupt Enable Register (IER)
This register is used to enable assertion of the MAL_SERR_INT signal when there is an active bit in the
ESR’s interrupt status field. Generation of the interrupt line executes the following logic: perform an AND
between each interrupt status bit and the related bit in IER, and then OR together all the results.
For more information about the Error registers see Section 3.3.4.1 , Error Status Register, on page 107.
3.2.5.5 Operational Error Modes
MCMAL can operate in two different error handling modes:
• Locked Error Mode: When an error occurs, the information about that error is written in the Error Status
Register, and the Valid bit in that register is set. In locked mode, the information which is in the Error Sta-
tus field in that register, stays locked until the device driver unlocks it by resetting the error Valid bit.
— The Error Interrupt Bits field of the Error Description Register is not locked in this mode. Hence, soft-
ware can find out if more errors occur. However, the Error Description field information would be valid
only for the first error, which is locked.
• Non Locked Error Mode: In non locked mode, when an error occurs, information about the error is writ-
ten in the Error Status Register, and the error Valid bit is set. Each new error will be overwritten, so the
information in the Error Status Field is valid only for the last error that occurred.
In both modes, each error written in the error description field will set the error Valid bit, and it is the soft-
ware’s responsibility to reset this bit.
The error handling mode is programmed by bit 30 of the MCMAL Configuration Register (see Table 23 on
page 104).

Core Databook IBM
3.2.5.6 Resolution Of An Error Situation
When MCMAL encounters an error, it:
• Writes information about the error in the Error Status Register (ESR). This information includes the chan-
nel ID of the channel which caused the error (if known), the bus on which the error occurred, and the kind
of error that occurred.
• It resets the channel that caused the error (if known) in the Channel_Active Register (CAR).
• It updates the Interrupt Status bits in the ESR. Then, depending on the mask defined in IER (Interrupt
Enable Register), it may send an interrupt to software.
After receiving an interrupt from MCMAL, software can analyze the error information read from the Error
Status Register. Software must reinitiate the activity of the channel by activating the related bit in the
Channel_ Active register.
When a channel is reset and reactivated, MCMAL starts processing descriptors from the first descriptor in the
channel’s descriptor table. Therefore, software may also update the value of the channel’s related registers
(see Section 3.3.6.2 , Channel Table Pointer Registers, on page 112), in order to continue from the same
buffer in memory.
In the case of PLB Mirq, MCMAL does not know which channel caused this error. It is the software’s respon-
sibility to analyze the MCMAL error registers, and the PLB slave’s error registers, to determine which channel
caused the error. Software should then reset this channel within MCMAL, resolve the problem, and then reac-
tivate the channel.
Note: It is essential that the slave de-asserts the PLB_MIRQ signal prior to MCMAL’s reactivation.
See Figure 38 on page 99 for a flow chart illustrating the steps MCMAL performs for resolution of an error
situation.
3.2.5.7 Interrupts To Software
MCMAL sends an interrupt for each non-masked error that occurred. The interrupt signal (MAL_SERR_INT)
is held asserted until the device driver resets the interrupt status indication. Figure 38 on page 99 describes
MCMAL actions once an error is detected. Note that the actual decisions MCMAL takes may be in another
order than represented by this figure. In any case, the device driver should consider all these MCMAL actions
as performed at the same time.

132
IBM Core Databook
Figure 38. MCMAL Resolution Of An Error Situation
AnAn
Error was
Error detected
was detected
No
Is it a PLB Mirq?
Yes
No channel is associated Disable the channel in the

with the error, therefore no Channels Active register.
channel is disabled.
Update
update relevantinterrupt
relevant interrupt
bit in ESR.
Are interrupts enabled for this No

type of error in IER ?
Yes
Assert MAL_SERR_INT
Assert MAL_SERR_INT No interrupt
No interrupt
signal
Signal
No
Error mode = locked?
Yes
No
Is the Error valid bit in ESR set?
Yes
Error status bits free. Error status bits locked, update Error status bitsbits
Update Error status
Update Error status bits
update Error status bits do do
notnot update
update them.
them and
andset
setError
Errorvalid
validbitbittoto‘1’‘1.’
and
andset
setError
Errorvalid
validbitbit
toto‘1’‘1’
Resume operation
Resume operation

Core Databook IBM
3.3 Registers
Access to MCMAL registers is possible only from the DCR interface. These registers are mapped in the DCR
space. Each DCR address represents a word-wide (32-bit) register.
• Unless otherwise specified, all register fields are initialized (at Chip reset) to zero.
• All reserved fields are read as zeros and must be written as zeros.
All addresses for the following registers are in the 10 bit address space of the DCR bus. To allow flexibility in
defining the DCR address space used by MCMAL, the hardware integrator can define the value of DCR
address bits 0 to 2 (3 MSbs) by setting the value of MAL_DCR_BASE_ADDR[0:2] input bus at the core
boundaries. The other 7 LSbs represent the offset value of MCMAL registers.
Note: Table 22 on page 100 refers to 64 channel MCMAL DCR Register offsets. The same DCR Register
offsets are used for all MCMAL configurations (64, 32 and 8 channels).
Unused registers in each configuration shouldn’t be written. Writing to unused register will cause a register’s
override (override the used registers).
Unused bits, in each configuration, are read as zeros.
Table 20 list the unused registers in 8- and 32-channel MCMALs.
Table 20. Unused Registers in the Different Configurations

MCMAL8 MCMAL32
TXCTP4R to TXCTP31R TXCTP16R to TXCTP31R

RXCTP4R to RXCTP31R RXCTP16R to RXCTP31R
RCBS4 to RCBS31 RCBS16 to RCBS31
Table 21 list the unused bits in 8 and 32 channel MCMALs.
Table 21. Unused Bits in the Different Configurations

Register Name MCMAL8 MCMAL32
Unused Bits Unused Bits
TXCASR 4 to 31 16 to 31
TXCARR 4 to 31 16 to 31
XEOBISR 4 to 31 16 to 31
TXDEIR 4 to 31 16 to 31
DCR Register offsets are as described in Table 22.
Table 22. MCMAL Internal Registers (Page 1 of 5)

DCR Offset Register Name Reference Table
MCMAL Configuration Register
0h MCR - MCMAL-Configuration Register Table 23 on page 104
MCMAL General Error Handling Registers
1h ESR - Error Status Register Table 27 on page 109

132
IBM Core Databook

2h IER - Interrupt Enable Register Table 28 on page 110
TX Channel Configuration Registers
4h TXCASR - TX Channel_Active Register (Set) Table 24 on page 106
5h TXCARR - TX Channel_Active Register (Reset) Table 25 on page 106
6h TXEOBISR - TX End of Buffer Interrupt Status Register Table 26 on page 107
TX Channel Descriptor Error Register
7h TXDEIR - TX Descriptor Error Interrupt Register Table 29 on page 111
TX PLB Attribute Register
8h TXTATTRR - TX PLB TAttribute Register Table 30 on page 111
TX Base Address Register
9h TXBADDRR - TX Descriptor Base Address Register Table 23 on page 93
10-Fh Reserved
RX Channel Configuration Registers
10h RXCASR - RX Channel_Active Register (Set) Table 24 on page 106
11h RXCARR - RX Channel_Active Register (Reset) Table 25 on page 106
12h RXEOBISR - RX End of Buffer Interrupt Status Register Table 26 on page 107
RX Channel Descriptor Error Register
13h RXDEIR - RX Descriptor Error Interrupt Register Table 29 on page 111
RX PLB Attribute Register

14h RXTATTRR - TX PLB TAttribute Register Table 30 on page 111
RX Base Address Register
15h RXBADDRR - RX Descriptor Base Address Register Table 23 on page 93

16-1Fh Reserved
TX Channels Table Pointer Registers
20h TXCTP0R - Channel TX 0 Channel Table Pointer Register All

Table 32 on page 113
21h TXCTP1R - Channel TX 1 Channel Table Pointer Register


2Ah TXCTP10R - Channel TX 10 Channel Table Pointer Register
2Bh TXCTP11R - Channel TX 11 Channel Table Pointer Register

Core Databook IBM

2Ch TXCTP12R - Channel TX 12 Channel Table Pointer Register
2Dh TXCTP13R - Channel TX 13 Channel Table Pointer Register
2Eh TXCTP14R - Channel TX 14 Channel Table Pointer Register

2Fh TXCTP15R - Channel TX 15 Channel Table Pointer Register

39h TXCTP25R -Channel TX 25 Channel Table Pointer Register
3Ah TXCTP26R - Channel TX 26 Channel Table Pointer Register
3Bh TXCTP27R - Channel TX 27 Channel Table Pointer Register
3Ch TXCTP28R - Channel TX 28 Channel Table Pointer Register
3Dh TXCTP29R - Channel TX 29 Channel Table Pointer Register
3Eh TXCTP30R - Channel TX 30 Channel Table Pointer Register
3Fh TXCTP31R - Channel TX 31 Channel Table Pointer Register
RX Channels Table Pointer Registers
40h RXCTP0R - Channel RX 0 Channel Table Pointer Register All

41h RXCTP1R - Channel RX 1 Channel Table Pointer Register


4Ah RXCTP10R - Channel RX 10 Channel Table Pointer Register
4Bh RXCTP11R - Channel RX 11 Channel Table Pointer Register
4Ch RXCTP12R - Channel RX 12 Channel Table Pointer Register

4Dh RXCTP13R - Channel RX 13 Channel Table Pointer Register
4Eh RXCTP14R - Channel RX 14 Channel Table Pointer Register

132
IBM Core Databook

4Fh RXCTP15R - Channel RX 15 Channel Table Pointer Register

5Ah RXCTP26R - Channel RX 26 Channel Table Pointer Register

5Bh RXCTP27R - Channel RX 27 Channel Table Pointer Register
5Ch RXCTP28R - Channel RX 28 Channel Table Pointer Register
5Dh RXCTP29R - Channel RX 29 Channel Table Pointer Register
5Eh RXCTP30R - Channel RX 30 Channel Table Pointer Register
5Fh RXCTP31R - Channel RX 31 Channel Table Pointer Register
RX-Channel-Buffer-Size Registers
60h RCBS0 - Channel RX 0 - Channel-Buffer_Size Register All

61h RCBS1 - Channel RX 1- Channel-Buffer_Size Register


6Ah RCBS10 - Channel RX 10- Channel-Buffer_Size Register
6Bh RCBS11 - Channel RX 11- Channel-Buffer_Size Register
6Ch RCBS12 - Channel RX 12- Channel-Buffer_Size Register

6Dh RCBS13 - Channel RX13- Channel-Buffer_Size Register
6Eh RCBS14 - Channel RX 14- Channel-Buffer_Size Register
6Fh RCBS15 - Channel RX 15- Channel-Buffer_Size Register


Core Databook IBM


7Ah RCBS26 - Channel RX 26- Channel-Buffer_Size Register
7Bh RCBS227 - Channel RX 27- Channel-Buffer_Size Register
7Ch RCBS28 - Channel RX 28- Channel-Buffer_Size Register
7Dh RCBS29 - Channel RX29- Channel-Buffer_Size Register

7Eh RCBS30 - Channel RX 30- Channel-Buffer_Size Register
7Fh RCBS31 - Channel RX 31- Channel-Buffer_Size Register
3.3.1 MCMAL Configuration Register
This register (see Table 23) is used to define the operational mode of MCMAL. Unless a configuration change
is required during system operation, the configuration register needs to be set only once (during the system
initialization process).
Offset address offset = 0h
Reset value = ‘00004080’h
Table 23. MCMAL Configuration Register (Page 1 of 2)

Bit(s) Field Name Read/Write Description
0 MCMAL soft reset RW Software Reset.
This bit is used to generate a general reset to MCMAL through a soft-
ware command.
Following setting this bit, MCMAL hardware (registers, interface and
internal state machines) return to the power on reset value.
The software writes ‘1’ to this bit in order to drive MCMAL to the reset
state. The bit is cleared by the hardware when the reset is completed
(several PLB clocks).
It is the software’s responsibility to poll this register and continue only
after this bit is cleared.
1-7 Reserved
8-9 RD_PLB_priority RW Read PLB Priority.

Determines the priority of MCMAL requests on the PLB for Read trans-
action.
(8,9)=’11’ highest
(8,9)=’10’
(8,9)=’01’
(8,9)=’00’ lowest

132
IBM Core Databook
Table 23. MCMAL Configuration Register (Page 2 of 2)

10-11 RD_Max_Burst_Size RW Max PLB Burst size for read transaction.
Determines the maximum data transfers (RdDacks) per read burst
transaction.
(10,11)=’00’ - max burst size of 4.
(10,11)=’1x’ - max burst size of 16
Note that ‘11’ is the recommended value.
12-13 WR_PLB_priority RW Write PLB Priority.

Determines the priority of MCMAL requests on the PLB for Write trans-
action.
(12,13)=’11’ highest
(12,13)=’10’
(12,13)=’01’
(12,13)=’00’ lowest
14-15 WR_Max_Burst_Size RW Max PLB Burst size for write transaction.

Determines the maximum data transfers (WrDacks) per write burst
transaction.
(14,15)=’1x’ - max burst size of 16
Note that ‘11’ is the recommended value.
16 PLB_LockError RW PLB Lock Error for both read and write.

When this bit is set, MCMAL applies the LOCKERROR signal to the
PLB slave (PLB_LockError) when it is the initiator during PLB transac-
tions.
17 PLB Burst RW PLB burst operation.

When this bit is reset, MCMAL is not allowed to perform burst transac-
tions.
18-23 Reserved
24 OPB_Bus_Lock RW OPB Lock.
When this bit is set, MCMAL locks the OPB during data transfer to and
from the ComMacs.
25-28 Reserved
29 EOP_Int_Enable RW End of packet interrupt enable.

When this bit is set, an interrupt is generated on every end of packet
(both transmit and receive).
When clear, end of packet/buffer interrupt is generated only if the
buffer’s I bit is set (‘1’).
Note: An interrupt is generated for every descriptor on which the I bit is
set no matter what the state of the EOP_Int_Enable bit is.
30 Locked_Error_Active RW Locked Error Active.

Determines MCMAL’s error handling mode. When this bit is set,
MCMAL will handle errors in the locked mode, otherwise it will handle
errors in a non-locked mode.
31 MAL_Scroll_Dsc RW Scroll Descriptor.

Determines whether or not MCMAL should scroll to the first descriptor
of the next packet, following an early packet termination initiated by the
related ComMac.
When set, Scrolling mode is active.

Core Databook IBM
3.3.2 Channel_Active Registers
For the TX Channel_Active and the RX_Channel_Active registers (see Table 24 on page 106), each bit
represents its related channel (bit 0 for channel 0 etc.). When the bit is set to ‘1’, channel operation is
enabled.
TX Channel_Active register contains the Channel_Active bits for the 32 TX channels. RX Channel_Active
register contains the Channel_Active bits for the 32 RX channels. The mechanism (as described below) for
both RX and TX registers is the same.
When a channel’s enable bit is cleared (set to ‘0’), MCMAL ignores arbitration requests from the channel. If
the channel is active when its enable bit is cleared, MCMAL stops processing the packet.
After the channel’s enable bit is cleared, MCMAL goes back to the top of the channel descriptor table (pointed
to by the Channel Table Pointer register).
MCMAL hardware clears the enable bit of a channel following an indication of an error associated with the
channel. The software can activate (enable) and deactivate (disable) channel operation through a write to the
set or reset Channel_Active registers. Writing ‘1’ to a bit in the set register causes the related bit to be
enabled. Writing ‘1’ to the reset register causes the related bit to be disabled. Writing ‘0’ has no meaning.
More than one channel can be enabled or disabled in a single write operation. Since both addresses of the
set and the reset register are physically mapped to the same register, a read from these two registers gives
the same result (‘1’ is read for each bit which is currently active).
Offset address for TX Channel_Active Set Register = 4h
Offset address for RX Channel_Active Set Register = 10h
Table 24. TX Channel_Active Set Register, RX Channel_Active Set Register

0-31 Channel Active Set RW Each bit represents its related channel (bit 0 for channel 0 etc.). When ‘1’ is
written to the bit, channel operation is enabled.
Offset address for TX Channel_Active Reset Register = 5h
Offset address for RX Channel_Active Reset Register = 11h
Table 25. TX Channel_Active Reset Register, RX Channel_Active Reset Register

0-31 Channel Active Reset RW Each bit represents its related channel (bit 0 for channel 0 etc.). When ‘1’ is
written to the bit, channel operation is disabled.
3.3.3 End of Buffer Interrupt Status Registers
Each bit in the TX End of Buffer Interrupt Status and RX End of Buffer Interrupt Status registers (see Table 26
on page 107) is related to a channel’s descriptor buffer table.

132
IBM Core Databook
The TX End of Buffer Interrupt Status register contains the End_of_Buffer_Status bits for the 32 TX channels.
The RX End of Buffer Interrupt Status register contains the End_of_Buffer_Status bits for the 32 RX chan-
nels. The mechanism (as described below) for both RX and TX registers is the same.
MCMAL sets a channel’s bit in one of the following conditions:
• When MCMAL finishes the processing of a buffer (writes back the status to the current descriptor), the
related bit in this register is set if the I bit in the descriptor status is set.
• When MCMAL finishes the processing of a packet (writes back the status of the packet’s last buffer) and
bit 29 (EOP_Int_Enable) in MCR is set.
Note: In the case that MCMAL finishes the processing of a retransmitted packet, MCMAL doesn’t con-
sider it as an End of Packet. Therefore, MCMAL will not set the appropriate channel bit in the End of
Buffer register.
• When the Bad Packet bit is set in the ComMac channel Status halfword.
The device driver resets the interrupt by writing a ‘1’ to the related bit. Writing a ‘0’ has no effect. When one or
more of the TX End Of Buffer interrupt status registers is set, then the MAL_TX_BUFF_INT bit is set. When
one or more of the RX End Of Buffer interrupt status registers is set, then the MAL_RX_BUFF_INT bit is set.
Offset address for TX End Of Buffer Interrupt Status register = 6h
Offset address for RX End Of Buffer Interrupt Status register = 12h
Table 26. TX End Of Buffer Interrupt Status Register, RX End Of Buffer Interrupt Status Register
0-31 Channel End of buffer RW Each bit represents its related channel (bit 0 for channel 0 etc.). When one or
interrupt. more bits are set, MAL_BUFF_INT is set. Writing ‘1’ to a bit resets it.
3.3.4 MCMAL Error Registers
The following paragraphs describe MCMAL error registers. For more information about MCMAL errors see
Section 3.2.5, Error Handling, on page 94.
3.3.4.1 Error Status Register
This register (see Table 27 on page 109) holds the information about the error that occurred and the inter-
rupts status. The register includes the following fields:
• Error status bits. These fields hold the error information. The information includes the number of the
channel on which the error occurred (if known) and the type of the error. The error can be either the last
detected error or a locked error if “Locked error mode” is active. (See Section 3.2.5.5 , Operational Error
Modes, on page 97 for description of the Locked error mode.)
The error status fields include an “Error Valid” bit which indicates whether there is an error information in the
error status field or not. The error status bits are not valid when the “Error Valid” bit is cleared (by writing ‘1’ to
this bit).

Core Databook IBM
• Interrupt status bits. Every error detected by MCMAL sets a related bit in the interrupt status fields. The
interrupt status bits may be cleared by software by writing ‘1’ to the bit to be cleared. The bits in these
fields are accumulative (more than one interrupt may be indicated here). These bits are masked by the
IER (Interrupt Enable Register) to create a maskable interrupt, which is implemented by the
MAL_SERR_INT signal.
Note: In order to reset the interrupt status bits and the Error valid bit in the Error Status register, ‘1’ must be
written to the related bit. Writing ‘0’ has no effect.
More than one bit can be cleared at a time, and only R/W bits can be reset.
Offset address for Error Status Register = 1h

132
IBM Core Databook
Table 27. Error Status Register (Page 1 of 2)

0 Error valid bit RW Error valid bit.

When this bit is set, bits 1-6 include the ID of the error generating channel.
Bits 8 -15 indicate the type of error.
In non-locked mode, the error indication describes the last error that had
occurred. In locked mode, the error is the first one that had occurred after this
bit was cleared.
This bit is set when an error occurs, and remains set until reset by the soft-
ware. In locked mode, new errors cannot be latched in the error lock indica-
tion fields if this bit is set.
1-6 Channel ID RO This field contains the number of the channel which caused the locked error.
Bit 1 indicates whether the channel ID represents RX channel or TX channel.
Channel ID(1)=’0’ - TX Channels
Channel ID(1)=’1’ - RX Channels
Bits 2-6 indicate the number of the channel that caused the error.
7 Reserved RO
8 PLB Time Out error RO A PLB Timeout Error has occurred (Error Status bit).
9 PLB Read error RO A PLB Read Error has occurred (Error Status bit).
10 PLB Write error RO A PLB Write Error has occurred (Error Status bit).
11 Descriptor Error RO Descriptor error (Error Status bit).

Indicates that the error is a non-valid descriptor, which is not the first descrip-
tor in a TX packet.
12 Reserved RO
13 OPB Time Out error RO An OPB Time Out Error has occurred (Error Status bit).
14 OPB Slave Error RO An OPB Slave Error has occurred (Error Status bit).
15 PLB MIRQ RO A PLB MIRQ has occurred (Error Status bit).

16-23 Reserved RO
24 PLB Time Out error RO PLB Time Out Error (Interrupt Status bit).
Interrupt This bit is set following a PLB Timeout error indication.
Set condition for this bit generates a maskable interrupt.
25 PLB Read error RO PLB Read Error (Interrupt Status bit).
Interrupt This bit is set following a PLB Read error indication.
26 PLB Write error RO PLB Write Error (Interrupt Status bit).

Interrupt This bit is set following a PLB Write error indication.
27 Descriptor Error RW Descriptor error (Interrupt Status bit).

Interrupt A descriptor data error was recognized during access to the descriptor table.
This error indication is asserted when a non valid descriptor was accessed,
which is not the first descriptor in a TX packet.
28 Reserved RW
29 OPB Time Out Error RW OPB slave time out error indication status bit (Interrupt Status bit).
Interrupt This bit is set following an OPB time out error indication.

Core Databook IBM
Table 27. Error Status Register (Page 2 of 2)

30 OPB Slave Error RW OPB slave error indication status bit (Interrupt Status bit).
Interrupt This bit is set following an OPB error indicated by the slave.
31 PLB MRQ RW PLB MRQ Indication (Interrupt Status bit).

Interrupt This bit is set following an PLB MRQ signal.
3.3.4.2 Interrupt Enable Register
Each bit in this register (see Table 28), when it is set, enables assertion of interrupt signal (MAL_SERR_INT)
when the related bit in the ESR (Interrupt bit) is set.
Offset address for Interrupt Enable Register = 2h
Table 28. Interrupt Enable Register

0-23 Reserved RO
24 PLB_Time_Out_Int_Enable RW When set, this bit enables PLB Time out error interrupt.
25 PLB_Rd_Err_Int_Enable RW When set, this bit enables PLB Read error interrupt.
26 PLB_Wr_Err_Int_Enable RW When set, this bit enables PLB Write error interrupt.
27 Desc_Error_Int_Enable RW When set, this bit enables the descriptor error (descriptor not valid)
interrupt.
28 Reserved RW
29 OPB_Time_Out_Int_Enable RW When set, this bit enables OPB time out error interrupt.
30 OPB_Err_Int_Enable RW When set, this bit enables the OPB Slave error interrupt.
31 MRQ_Int_Enable RW When set, this bit enables the MRQ interrupt.
3.3.4.3 Descriptor Error Interrupt Registers
Each bit in the TX Descriptor Error Interrupt Register and RX Descriptor Error Interrupt Register (see Table
29 on page 111) is related to a channel descriptor buffer table. Each bit indicates a descriptor data error
related to a certain channel.
The TX Descriptor Error register contains the Descriptor errors bits of the 32 TX channels. The RX Descriptor
Error register contains the Descriptor errors bits of the 32 RX channels. The mechanism (as described below)
for both RX and TX registers is the same.
MCMAL sets a channel’s bit when a descriptor data error was recognized during access to the descriptor
table of a specific channel (see Section 3.2.5.3 , Indicated Errors, on page 95).

132
IBM Core Databook
The device driver resets the interrupt by writing a ‘1’ to the related bit. Writing a ‘0’ has no effect. When one or
more of the TX Descriptor Error Interrupt bits is set, then the MAL_TX_DESC_ERR_INT bit is set. When one
or more of the RX Descriptor Error Interrupt bits is set, then the MAL_RX_DESC_ERR_INT bit is set.
Offset address for TX Descriptor Error Interrupt Register = 7h
Offset address for RX Descriptor Error Interrupt Register = 13h
Table 29. TX Descriptor Error Interrupt Register, RX Descriptor Error Interrupt Register
0-31 Channel Desc_Err_Int RW Each bit represents its related channel (bit 0 for channel 0 etc.). When one or
more bits are set, MAL_DESC_ERR_INT is set. Writing ‘1’ to a bit resets it.
3.3.5 PLB TAttribute Registers
These registers (see Table 30 on page 111) define the specific transfer information driven by MCMAL
towards the PLB slaves. For specific details about each bit, refer to the Mn_TAttribute signal (section 2.5.7) in
the PLB Specification.
Offset address for TX PLB TAttribute Register = 8h
Offset address for RX PLB TAttribute Register = 14h
Table 30. TX PLB TAttribute Register, RX PLB TAttribute Register

0-15 PLB TAttribute RW PLB TAttribute

16-31 Reserved RO
3.3.6 MCMAL Channel Table Pointer Registers
MCMAL works on a 36-bit address space.
As the DCR bus is only 32 bits wide, each channel’s table pointer should be configured in two DCR accesses:
1. Configure the 4 MSbs, using a common register (TX/RX Base Address register).
2. Configure the 32 LSbs, using a channel private register (TX/RX CTPR).
3.3.6.1 Base Address Registers
The TX and RX Base Address registers use the same format.
The Base Address register is a gateway for updating/reading to/from all channels, and MCMAL determines
which channel should be used according to the specific TX/RX CTPR used.
The following steps describe the flow of programming a table pointer address of 36 bits.

Core Databook IBM
Writing flow:
Repeat the following steps for each channel:

1. Write the 4 addresses’ MSbs to the appropriate (RX/TX) Base Address Register (If this step isn’t done
MCMAL will use the default, “0000”).
2. Write the 32 LSbs to the specific channel’s address register (the CTPR).
3. MCMAL will store the full 36-bit address combined from the above two DCR accesses in its internal mem-
ory.
Reading flow:
1. Read the 32 LSbs of the specific channel’s address register.
2. MCMAL updates the (RX/TX) Base Address Register according to the channel read in phase 1.
3. Read the 4 addresses’ MSbs from bits 28 to 31 in the common Base Address Register.
Offset address for TX Base Address Register = 9h
Offset address for RX Base Address Register = 15h
Reset value = “0000 0000”h
Table 31. TX Base Address Register, RX Base Address Register

0-27 Reserved RO
28-31 Descriptor Base Address RW Descriptor Base Address
MCMAL’s table pointers can be configured using MadMAL (previous MAL core) software, and MCMAL will
use “0000” as the default of the address’s MSbs.
3.3.6.2 Channel Table Pointer Registers
The TX Channel Table Pointer (TX CTPR), and RX Channel Table Pointer (RX CTPR) registers (see Table
32 on page 113) use the same format.
MCMAL uses 32 RX Channel Table Pointer registers, one for each RX channel, and 32 TX Channel Table
Pointer registers, one for each TX channel. The Channel Table Pointer Registers point to the base address,
in memory, of the descriptor buffer table used by each channel.
Although MCMAL supports a full 36-bit address space:

1. No data buffer is allowed to cross a 32-bit address space border.
2. No buffer descriptor table is allowed to cross a 32-bit address space border.
Note: The MadMAL’s joint addresses’ 13 MSbs limitation no longer exists in MCMAL.
The TX and RX Channel Table Pointer Registers have identical formats as shown in Table 32 on page 113:
The offset address for the TX Channel Table pointer registers = 20h-3Fh
The offset address for the RX Channel Table pointer registers = 40h- 5Fh
Power on Reset value = Undefined

132
IBM Core Databook
Note: As MCMAL’s address space is 36 bits, but the DCR is only 32 bits wide, it is important to configure the
table pointer registers correctly in order to ensure appropriate read/write operations. (See Section 3.3.6,
MCMAL Channel Table Pointer Registers, on page 111).
Table 32. TX Channel Pointer Register, RX Channel Table Pointer Register

Bits Number Field Name Read/Write Description
0-31 Channel table pointer RW Pointer to the base address in memory of the buffer descriptor table used
by the channel. The value entered should be a pointer to a location in mem-
ory accommodating an aligned double fullword (this requires the three LSBs
of this pointer must be ‘000’).
Note: The table pointer registers preserve their old values following SoftReset or Channel Reset.
3.3.7 RX-Channel-Buffer-Size Registers
Each RX channel has a fixed buffer length. The RX-Channel-Buffer-size registers (see Table 33 on page 113)
are configured by the device driver to determine the length of the buffer. This size is the maximum number of
bytes that can be stored in the buffer. More than one buffer is used to store the incoming packet in case the
length of the incoming packet data is more than the channel’s buffer length (as defined by the channel’s
related register).
The buffer length for a given channel can be from 16 bytes to (4 KB-16) bytes (in 16-byte steps). This length
is represented by a 8 bit field. The buffer size in bytes is calculated as described below:
RX_Buffer_Size_Field * 16
Offset address for RX-Buffer-Size-X = 60h-7Fh
Power on Reset value = Undefined
Table 33. RX-Buffer-Size-X

0-23 Reserved RO
24-31 Channel X buffer size. RW RX_Buffer_Size_Field
1. The RX-Buffer-Size=X registers preserve their old value following SoftReset or Channel Reset.
2. RX_Buffer_Size=’0000’ is NOT a legal value.

Core Databook IBM

132
IBM Core Databook
4. Hardware Interface
4.1 Pin List - MCMAL
4.1.1 MCMAL Timing Definition
This section defines the timing parameters of MCMAL in Cu-11 and Cu-08 technologies, when the PLB is
running at 166 MHz and the OPB is running at 166 MHz.
The timing parameters are defined according to the PLB (4.3), OPB (1.4) and DCR (2.0) Specifica-
tions.Timing parameters for MCMAL are shown in Table 34. The value in the timing column represents the
time during which the signal is valid, expressed as a percentage of one complete clock cycle.
Timing signals for the PLB support three-cycle arbitration timing, according to the PLB Specification version
4.3 timing guidelines:
• The maximum input capacitance on all MCMAL input ports is 0.2 pF.
• The maximum capacitance load limit of all MCMAL output ports is 0.3 pF for worst case and 0.1 pF for
best case.
• The functional CLK slew rate is 1 ns for late mode and 0.1 ns for early mode.
• All Input signals’ slew rate is 1 ns for late mode and 0.1 ns for early mode.
• Wire Load Model is 5.3-mm chip - 5MZC4P package.
• Latch to Latch timing, capacitance model and other synthesis requirements are according to the Soft
Core Design Guidelines version 2.30.
Table 34 describes the functional behavior and timing of MCMAL input and output signals.
4.1.2 MCMAL Functional Pins
Table 34. MCMAL Pin List (Page 1 of 7)

Signal Type Wide Timing Description
PLB Interface
PLB_MAL_ADDRACK In 1 50% Indicates that the slave has acknowledged the address.
PLB_MAL_TIMEOUT In 2 15% Indicates an address phase timeout.
PLB_MAL_REARBITRATE In 1 -- Indicates that the slave cannot respond to the request.

This signal is not used by MCMAL’s logic.
PLB_MAL_SSIZE In 2 -- Indicates the slave data bus size.

This bus is not used by MCMAL’s logic.
PLB_MAL_BUSY In 1 -- Indicates that the PLB slave is busy.

PLB_MAL_RDERR In 1 30% Indicates slave’s error in Read transfer.
PLB_MAL_WRERR In 1 30% Indicates slave’s error in Write transfer.
PLB_MAL_MIRQ In 1 30% Master interrupt request signal.
SA14-2653-01 Hardware Interface

Core Databook IBM

PLB_MAL_RDPENDREQ In 1 -- Indicates that a master has a read request pending on
the PLB.
PLB_MAL_WRPENDREQ In 1 -- Indicates that a master has a write request pending on

the PLB.
PLB_MAL_RDPENDPRI In 2 -- Indicates the highest priority of any active read request.

PLB_MAL_WRPENDPRI In 2 -- Indicates the highest priority of any active write request.
PLB_MAL_WRDACK In 1 50% Indicates that the data of the current transfer is no longer
required.
PLB_MAL_WRBTERM In 1 50% Write Burst termination signal.
PLB_MAL_RDDACK In 1 50% Indicates that the data is valid on PLB.

PLB_MAL_RDBTERM In 1 50% Read Burst termination signal.
PLB_MAL_RDWDADDR In 4 -- In read operations, indicates the word address within the

line of the data word which is currently on the PLB.
PLB_MAL_RDDBUS In 128 50% Read data bus.
MAL_PLB_REQUEST Out 1 15% A request from the master to transfer data on the PLB.
MAL_PLB_PRIORITY Out 2 15% Indicates the priority of the request.

MAL_PLB_RNW Out 1 15% Indicates if the master is requesting read or write action.
MAL_PLB_BUSLOCK Out 1 -- Locking the Arbiter for granting the present Master.
Constant driven to ‘0’.
MAL_PLB_BE Out 16 15% Indicates a non-line transfer.
MAL_PLB_SIZE Out 4 15% Indicates the size of the transfer being requested.
MAL_PLB_TATTRIBUTE Out 16 15% Represents specific transfer information to the slave.
MAL_PLB_TYPE Out 3 -- Indicates the type of the transfer which is being

requested.
Constant driven to “000”, indicating memory transfer.
MAL_PLB_MSIZE Out 2 -- Indicates the master data bus size.

Constant driven to “10”, indicating a 128-bit data bus
size.
MAL_PLB_LOCKERROR Out 1 15% Indicates to slaves whether or not to lock the SEAR and
SESR registers.
MAL_PLB_ABUS Out 32 15% Indicates the address of the data for read write opera-
tions.
MAL_PLB_UABUS Out 32 15% Upper address bus.

The 28 MSbs are constant driven to zero (MCMAL drives
a total address space of 36 bits).
MAL_PLB_WRDBUS Out 128 15% Write data bus.
MAL_PLB_WRBURST Out 1 15% Indicates a write burst.
MAL_PLB_RDBURST Out 1 15% Indicates a read burst transfer.
Hardware Interface SA14-2653-01

132
IBM Core Databook

MAL_PLB_ABORT Out 1 15% Indicates that the master no longer requires the data
transfer that is being requested.
OPB Interface
OPB_MAL_GRANT In 1 68% When asserted, indicates that MCMAL has control of the
bus at the rise of the OPB clock.
OPB_MAL_XFERACK In 1 53% Indicates that the OPB slave has completed the transfer
on the bus.
OPB_MAL_ERRACK In 1 53% When asserted, indicates that the OPB slave has
encountered an error in performing the requested trans-
fer.
OPB_MAL_RETRY In 1 53% When asserted, indicates that the OPB slave is unable to
perform the requested transfer.
OPB_MAL_TIMEOUT In 1 43% Indicates that a timeout error has occurred.
OPB_MAL_DBUS In 128 68% Data bus for the OPB. Used by MCMAL on OPB reads.
The 32 MSbs are used by 32-bit OPB ComMacs. The
entire 128-bit bus is used by 128-bit OPB ComMacs.
MAL_OPB_REQUEST Out 1 8% Asserted by MCMAL to request control of the bus.

MAL_OPB_BUSLOCK Out 1 8% Asserted by MCMAL when controlling the current bus
cycle in order to lock bus arbitration.
MAL_OPB_SELECT Out 1 8% Driven by MCMAL in the cycle following its

OPB_MAL_Grant assertion, to assume control of the bus
and to indicate that a valid data transfer cycle is in
progress.
MAL_OPB_RNW Out 1 8% (Read Not Write) Indicates the direction of a data trans-
fer. When high, request is for the ComMac OPB slave to
supply data to be read into the master.
MAL_OPB_HWXFER Out 2 8% Indicates the size of the requested transfer. In MCMAL
and communication with ComMacs, these signals will always
indicate a fullword transaction. The appropriate values
MAL_OPB_FWXFER
are: MAL_OPB_hwXfer = ‘1’, MAL_OPB_fwXfer = ‘1’.
MAL_OPB_SEQADDR Out 1 -- When asserted, indicates that the transfer being per-
formed will be followed with a transfer to the next
sequential address. Is always used in conjunction with
MAL_OPB_busLock.
MAL_OPB_ABUS Out 32 8% Address bus for the OPB. Used by MCMAL for transac-
tion qualifiers.
MAL_OPB_DBUS Out 128 18% Data bus for the OPB. Used by MCMAL to write data to
an OPB slave. The 32 MSbs are used by 32-bit OPB
ComMacs. The entire 128-bit bus is used only by 128-bit
OPB ComMacs.
MAL_OPB_DBUSEN Out 1 18% Enable bit for MAL_OPB_DBus, the two are ANDed.
MAL_HIGH_OPB_ADDR In 24 -- High OPB Address bits.

When MCMAL initiates a transaction on the OPB, it
drives the value of this bus on bits 0-23 of the OPB
address bus.
This bus should be a hardwired input at the chip level.
EOPB Interface

Core Databook IBM

OPB_MAL_BE_ACK_EXT In 16 60% Indicates to MCMAL which bytes are valid on the current
OPB transfer. This bus is valid alongside the
OPB_MAL_XFERACK signal.
If such a bus does not exist in the ComMac, it should be
hardwired to:
for RX: zeroes.
for TX: “11” at the MSbs and zeroes elsewhere.
MAL_OPB_BE_EXT Out 16 18% Indicates to the ComMac which bytes are valid on the
current OPB transfer. This bus is valid alongside the
MAL_OPB_SELECT signal.
MAL_OPB_QWXFER Out 1 -- Indicates the size of the requested transfer. In MCMAL

communication with ComMacs, this signal will always
indicate a quadword transaction.
TX ComMac Channels Interface
COM_TX_FRAME1 In 32 50% Indicates an ongoing session between ComMac and

MCMAL.
COM_TX_ARB_LEVEL01 In 32 50% Bit 0 of the 2-bit Arb_Level bus, which indicates Com-
Mac’s internal flow status.
COM_TX_ARB_LEVEL11 In 32 50% Bit 1 of the 2-bit Arb_Level bus, which indicates Com-
MAL_TX_STATUS_DONE1 Out 32 25% Indicates that the status word read by MCMAL from
ComMac has been posted to memory.
MAL_TX_DSCR_NOT_VALID1 Out 32 25% Indicates that MCMAL has encountered a buffer descrip-
tor which was not ready.
MAL_TX_DSCR_ERR1 Out 32 25% Indicates that MCMAL has encountered a buffer descrip-
tor error.
MAL_TX_CHANNEL_SELECT1 Out 32 18% Used by MCMAL to select a unique TX OPB slave

attached to the OPB.
MAL_ACTIVE Out 1 8% Indicates that the current OPB transaction is initiated by
MCMAL and applied to one of the ComMacs. This signal
is common to all ComMacs (including the RX channels).
TX_MAL_BURST_LENGTH01 In 32 -- Bit 0 of 3-bit BURST_LENGTH bus indicates the

requested amount of data to be transferred between
MCMAL and a ComMac channel in a single transaction.


COM_TX_QW1 In 32 -- Indicates the slave’s device width. If this bit is ‘1’ the TX
ComMac is 128-bit OPB slave. If the bit is ‘0’ the TX
ComMac is 32-bit OPB slave.
RX ComMac Channels Interface

132
IBM Core Databook

COM_RX_FRAME1 In 32 50% Indicates a continuous session between ComMac and

MCMAL.
COM_RX_ARB_LEVEL01 In 32 50% Bit 0 of the 2-bit Arb_Level bus, which indicates Com-
COM_RX_ARB_LEVEL11 In 32 50% Bit 1 of the 2-bit Arb_Level bus, which indicates Com-
COM_RX_LAST_DATA1 In 32 60% Asserted in conjunction with the last data transfer in a

given packet.
COM_RX_LAST_DATA_BE01 In 32 60% Bit 0 of the 2-bit LAST_DATA_BE bus, which indicates

how many valid bytes are in the last data word.
COM_RX_LAST_DATA_BE11 In 32 60% Bit 1 of the 2-bit LAST_DATA_BE bus, which indicates

how many valid bytes are in the last data word.
COM_RX_NULL_TRANSFER1 In 32 60% Indicates that the current transaction on the OPB doesn’t
contain any bytes of valid data.
MAL_RX_STATUS_DONE1 Out 32 25% Indicates that the status word read by MCMAL from
ComMac has been posted to memory.
MAL_RX_DSCR_ERR1 Out 32 25% Indicates that MCMAL has encountered a buffer descrip-
tor error.
MAL_RX_CHANNEL_SELECT1 Out 32 18% Used by MCMAL to select a unique RX OPB slave

attached to the OPB.
MAL_ACTIVE Out 1 8% Indicates that the current OPB transaction is initiated by
MCMAL and applied to one of the ComMacs (the same
signal as in the TX channels).
RX_MAL_BURST_LENGTH01 In 32 -- Bit 0 of 3-bit BURST_LENGTH indicates the requested

amount of data to be transferred between MCMAL and a
ComMac channel in a single transaction.


COM_RX_QW1 In 32 -- Indicates the slave’s device width. If this bit is ‘1’ the RX
ComMac is 128-bit OPB slave. If the bit is ‘0’ the RX
ComMac is 32-bit OPB slave.
DCR Interface
CPU_dcrAddr In 10 18% DCR address bus.

CPU_dcrData In 32 18% Source of data for DCR write operation.
CPU_exeMtDcr In 1 18% Control signal indicating DCR write operation.
CPU_exeMfDcr In 1 18% Control signal indicating DCR read operation.
MAL_dcrData Out 32 68% Return path for DCR read operation.
MAL_dcrAck Out 1 68% DCR acknowledge signal indicating MCMAL has recog-
nized Mt/Mf DCR.

Core Databook IBM

MAL_DCR_BASE_ADDR In 3 -- To allow flexibility in defining the DCR address space
used by MCMAL, the hardware integrator can define the
value of DCR address bits 0 to 2 (MSbs) by setting the
value of this bus.
External Data Buffers Interface
TX_LPRA_DATA In 128 72% Read data from TX Data Buffer.
RX_LPRA_DATA In 128 72% Read data from RX Data Buffer.
MAL_TX_LPRA_DATA_OUT Out 128 2.2 ns Write data to TX Data Buffer.
MAL_TX_LPRA_DATA_OUT_WE Out 1 2.2 ns Write enable to TX Data Buffer.
MAL_TX_LPRA_WR_ADDR Out 6 1 ns Address write to TX Data Buffer.

(address is in quadwords)
MAL_TX_LPRA_RD_ADDR Out 6 1 ns Address read from TX Data Buffer.
MAL_RX_LPRA_DATA_OUT Out 128 2.2 ns Write data to RX Data Buffer.
MAL_RX_LPRA_DATA_OUT_WE Out 4 2.2 ns Write enable to RX Data Buffer.
MAL_RX_LPRA_WR_ADDR Out 6 1 ns Address write to RX Data Buffer.

MAL_RX_LPRA_RD_ADDR Out 6 1 ns Address read from RX Data Buffer.

External MCMALs Interface
EXTR_MAL_ARB_HIGH In 1 35% When asserted, indicates that the highest arbitration

level value of a channel that is being served in external
MCMAL(s) is ‘High’.
EXTR_MAL_ARB_URGNT In 1 35% When asserted, indicates that the highest arbitration
level value of a channel that is being served in external
MCMAL(s) is ‘Urgent’.
MAL_ARB_HIGH Out 1 8% When asserted, indicates that the highest arbitration

level value of a channel that is being served in
MCMAL(s) is ‘High’.
MAL_ARB_URGNT Out 1 8% When asserted, indicates that the highest arbitration

level value of a channel that is being served in
MCMAL(s) is ‘Urgent’.

132
IBM Core Databook

Miscellaneous Interface
PLB_CLK In 1 - PLB domain clock input - used for PLB interface.

See Section 4.1.3, MCMAL LSSD Pins, on page 121 for
additional information.
OPB_CLK In 1 - OPB domain Clock input - used for OPB and DCR inter-
face.
See Section 4.1.1, MCMAL Timing Definition, on page
115 for additional information.
PLB_RST In 1 - System Reset.

When PLB_RESET is sampled active (high) on a clock
rising edge, all MCMAL interfaces are deactivated and all
internal state machines switch to an idle state.
This Signal must be activated for at least 3 PLB cycles.
MAL_SERR_INT Out 1 28% System Error Interrupt line - Used for MCMAL error indi-
cations (level).
For more information see Section 3.2.4, Interrupts, on
page 94.
MAL_TXEOB_INT Out 1 28% TX End Of Buffer (packet) interrupt line (level).

This interrupt line is used to signal End Of Buffer or End
of Packet of TX channel.
MAL_RXEOB_INT Out 1 28% RX End Of Buffer (packet) interrupt line (level).

This interrupt line is used to signal End Of Buffer or End
of Packet of RX channel.
MAL_TXDE_INT Out 1 28% TX descriptor error interrupt line (level).

This interrupt line is used to signal Descriptor Error in TX
channel BD table.
MAL_RXDE_INT Out 1 28% RX descriptor error interrupt line (level).

This interrupt line is used to signal Descriptor Error in RX
channel BD table.
1. The bus width is changed according to the number of supported channels. (For example, the width of this bus is 4 bits in MCMAL8
and 16 bits in MCMAL32).
4.1.3 MCMAL LSSD Pins
This section includes the LSSD pins for MCMAL.
Table 35. MCMAL LSSD Pin List

Signal Type Description
System Clocks
PLB_CLK In PLB Clock - used for PLB interface.
OPB_CLK In OPB Clock - used for OPB and DCR interface.

Core Databook IBM

132
IBM Core Databook
5. Core Integration
The MCMAL core is designed for use in a CoreConnect™ architecture based ASIC.
There are three MCMAL cores available for Cu-11 and Cu-08 technologies: MCMAL8, MCMAL32, MCMAL64
(which support 8, 32, or 64 channels).
MCMAL has the following interfaces:
• PLB 4.3
• OPB 1.4 (and its extension to a width of 128 bits - EOPB)
• DCR bus. ComMacs - TX channel sideband signals
• RX channel sideband signals
• External data buffer interface
• Miscellaneous
For related cores, see Section 1.7, Related IBM Cores, on page 16.
5.1 Configurability
The following are the basic system configuration issues that influence the MCMAL and the ComMacs perfor-
mance:
• External Data Buffers:

— MCMAL uses external RAs (see Table 36) to hold the data transferred. One of two RA types can be
chosen, according to the expected packet payload and required bandwidth.
Table 36. RAs

RA Amount
RA008x64D2P2W1R1M1 4
RA016x64D2P2W1R1M1 4
Note: RA032x64D2P2W1R1M1 can also be attached to MCMAL. This will increase the PLB utilization when unaligned data is being
read/write from/to memory.
• MCMAL operations on the OPB:

— Each RX and TX Channel should configure its own OPB burst size.
Note: TX and RX_MAL_BURST_LENGTH[0:2] must be smaller or equal to the data buffer size (con-
structed from the external RAs).
• MCMAL burst operation on the PLB:

— MCMAL burst operation on the PLB is recommended, but can be disabled in order to support non-
burst devices. In order to increase MCMAL bandwidth on the PLB, it is recommended to program the
MAX_BURST_LENGTH to its maximal value.
• In High bandwidth applications it is recommended that:

— PLB Arbiter:
SA14-2653-01 Core Integration

Core Databook IBM
— The PLB arbiter should be programmed to give MCMAL the highest priority on the bus, since a
delay in MCMAL operation can cause overflow or underflow in the ComMacs data buffers.
— OPB Arbiter:
— It is recommended to use 2 OPB buses - the first OPB for RX and TX data movements; MCMAL
is a single master on this OPB. The second OPB is for ComMacs configuration. This OPB can be
the regular CoreConnect OPB.
5.2 Initialization Sequence

MCMAL initialization includes two parts: Configuration and channel activation:
5.2.1 Setting MCMAL Configuration
This step is done only following reset (power on reset or soft reset). MCMAL configuration includes setting the
following registers:
• MCR (MCMAL Configuration Register): this register is used to define MCMAL operation on the PLB and
OPB bus.
• IER (Interrupt Enable Register). This register is used to enable error initiation interrupts.
Note: A reset caused by the PLB_RST signal requires at least 3 PLB cycles in which the signal is asserted.
5.2.2 Setting a Channel’s Specific Configuration
This information may be changed at any time in which the related channel is not active. (The related bit in TX
or RX Channel Active Set Register, is cleared.)
• RCBSx (RX Buffer Size Register). This register defines the length of the RX buffer in the memory.
• TXCTPxR, TXBADDRR or RXCTPxR, RXBADDRR (Channel Table Pointer Registers). These registers
define the address of the channel’s buffer descriptor tables.
The setting of the channel’s specific configuration can be done as part of MCMAL initialization or as part of
the ComMac initialization process.
5.2.3 Channel Activation
In order to activate a channel the following actions should be taken:
• The channel has to be configured in MCMAL.
• The related bit in CASR (Channel Active Set Register) has to be set.
• Enabling the channel’s operation (ComMac’s configuration).
Core Integration SA14-2653-01

132
IBM Core Databook
5.3 Clocking Guidelines

MCMAL works in two clock domains: The PLB clock domain and the OPB clock domain.
The clock ratio between the PLB and the OPB clocks might be 1:1, 2:1 or 3:1 (hence the PLB clock is never
slower than the OPB clock).
There is no need to provide MCMAL with any information about the PLB/OPB clock ratio.
The maximal frequency allowed for the PLB clock is 166 MHz.
The maximal frequency allowed for the OPB clock is 166 MHz.
In general, the timing parameters are defined according to the PLB, DCR and OPB Specifications. The
MCMAL - ComMac interface, inherited the timing parameters of the MadMAL interface.
5.4 Signal Specifications

The following sections provide the system integrator specific information about MCMAL inputs and outputs.
5.4.1 MCMAL Inputs that should be Hardwired at the Chip level
• MAL_HIGH_OPB_ADDR[0:23] = depends on the system architecture:

— 24 zeroes when MCMAL is located on private OPB as the only OPB master.
— Meaningful value to define the MCMAL address space, when MCMAL is located on a shared OPB
and there is another OPB master on the OPB.
• MAL_DCR_BASE_ADDR[0:2] = The hardware integrator should define the value of DCR address MSbs
by setting the value of this bus.
5.4.2 MCMAL Inputs Ignored by MCMAL Logic
• PLB_MAL_REARBITRATE
• PLB_MAL_SSIZE[0:1]
• PLB_MAL_BUSY
• PLB_MAL_RDPENDREQ
• PLB_MAL_WRPENDREQ
• PLB_MAL_RDPENDPRI
• PLB_MAL_WRPENDPRI
• PLB_MAL_RDWDADDR[0:3]
All the above signals/buses should be driven to ‘0’(s) at the chip level.
5.4.3 MCMAL Outputs that are Constant Driven
• MAL_PLB_BUSLOCK = ‘0’
• MAL_PLB_TYPE[0:2] = “000”

Core Databook IBM
• MAL_PLB_MSIZE[0:1] = “10”
• MAL_PLB_UABUS[0:27] = “0000000000000000000000000000”
• MAL_PLB_ABORT = ‘0’
• MAL_OPB_HWXFER = ‘1’
• MAL_OPB_FWXFER = ‘1’
• MAL_OPB_SEQADDR = ‘0’
• MAL_OPB_QWXFER = ‘1’
5.4.4 Signals that Change Behavior Based on Utilization
5.4.4.1 Used/Unused Channels
All the inputs of unused channels should be hardwired to zero at the chip level.
• TX:
— COM_TX_FRAME
— TX_MAL_BURST_LENGTH[0:2] (*)
— COM_TX_QW
— COM_TX_ARB_LEVEL[0:1] (*)
• RX:
— COM_RX_FRAME
— RX_MAL_BURST_LENGTH[0:2] (*)
— COM_RX_QW
— COM_RX_ARB_LEVEL[0:1] (*)
— COM_RX_LAST_DATA
— COM_RX_LAST_DATA_BE[0:1]
— COM_RX_NULL_TRANSFER
Note: Input buses indicated with (*) are located on several separated MCMAL inputs, for example
TX_MAL_BURST_LENGTH[0:2] of channel 5 will map to TX_MAL_BURST_LENGTH0(5),
TX_MAL_BURST_LENGTH1(5) and TX_MAL_BURST_LENGTH2(5).
All the outputs of unused channels should be terminated at the chip level.
• TX:
• MAL_TX_STATUS_DONE
• MAL_TX_DSCR_NOT_VALID
• MAL_TX_DSCR_ERR
• MAL_TX_CHANNEL_SELECT

132
IBM Core Databook
• RX:
— MAL_RX_STATUS_DONE
— MAL_RX_DSCR_ERR
— MAL_RX_CHANNEL_SELECT
5.4.4.2 ComMac’s Width (32 or 128)
In the case that all ComMacs are 32 bits wide:

— OPB_MAL_DBUS[32:127] should be hardwired to zero.
— OPB_MAL_BE_ACK_EXT[0:15] should be hardwired to “1100 0000 0000 0000”.
— MAL_OPB_DBUS[32 to 127] aren’t needed and can be put in terminators.
— MAL_OPB_BE_EXT[0:15] aren’t needed and can be put in terminators.
— MAL_OPB_QWXFER isn’t needed and can be put in terminators.
In the case that there are ComMacs of both 32 and 128 bits wide:
• RX channels in a 32-bit wide ComMac:

— COM_RX_QW = ‘0’.
— add a BE_ACK_EXT[0:15] of “0000000000000000” to the EOPB (*)
• TX channels in a 32-bit wide ComMac:

— COM_TX_QW = ‘0’.
— Add a BE_ACK_EXT[0:15] of: “1100000000000000” to the EOPB. (*)
Note: For the (*) designated signals see Figure 19 on page 50.
5.4.4.3 RX Channels that Do Not Support Null Transfers
In the case that channel x doesn’t support null transfers, COM_RX_NULL_TRANSFER[x] must be hardwired
to ‘0’.
5.4.4.4 MCMAL Parks On the OPB
• OPB_MAL_GRANT should be hardwired to ‘1.’
5.4.4.5 Using Several Cascaded MCMAL Cores In a System
Note: The term “cascaded MCMAL cores” refer to the case where several MCMAL are connected together in
order to increase the number of supported channels and all channels share the same arbitration mechanism.
In case of several MCMAL cores in a system where each one of them is referred to as an independent
MCMAL, please refer to each one of them as a Single MCMAL. For more information see Section 2.8, Arbitra-
tion Between Multiple MCMALs, on page 67.
• If there is a single MCMAL in the system:

— Both inputs (MAL_ARB_HIGH and MAL_ARB_URGNT) should be hardwired to zero, and both out-
puts (EXTR_MAL_ARB_HIGH and EXTR_MAL_ARB_URGNT) should be terminated.

Core Databook IBM
• If there are two cascaded MCMALs in the system:

— The first MCMAL’s output MAL_ARB_HIGH should be the input of the second MCMAL’s
EXTR_MAL_ARB_HIGH.
— The first MCMAL’s output MAL_ARB_URGNT should be the input of the second MCMAL’s
EXTR_MAL_ARB_URGNT and vice versa.
• If there are more than two MCMALs:

— This pattern should continue, each MCMAL should get an “OR” of all the other MCMALs outputs, for
example, if there are 3 MCMALs in the system (Mal1, Mal2 and Mal3), then Mal2 inputs will be:
– MAL_ARB_HIGH = EXTR_MAL_ARB_HIGH of MAL1 OR EXTR_MAL_ARB_HIGH of MAL3
– MAL_ARB_URGNT = EXTR_MAL_ARB_URGNT of MAL1 OR EXTR_MAL_ARB_URGNT of
MAL3.
See Figure 26 on page 68.
5.4.4.6 Optional Outputs to ComMacs
In the case that the ComMac being used does not use the following outputs, they need to be put in termina-
tors:
• MAL_RX_DSCR_ERR
• MAL_TX_DSCR_ERR
5.4.5 Connecting the External LPRAs
The four external LPRAs are used in pairs. Two form an RX data buffer of 128 bits; these should work in the
OPB clock domain (RXDB_1 and RXDB_2). Two form a TX data buffer of 128 bits; these should work in the
PLB clock domain (TXDB_1 and TXDB_2).
Notes:
• MCMAL signals are little-endian and LPRA signals are big-endian.
• Terminate unused output. For example, terminate MAL_TX_LPRA_RD_ADDR[1] when using
RA016x64D2P2W1R1M1.
• When using wrappers:
— Rx needs word resolution; Tx permits quadword resolution.
— It is best to constantly drive the WEP1 input of the wrapper with '1'.
— RA mode can be READ_WRITE mode.

132
IBM Core Databook
Table 37. External LPRA Signal Connections

Connect MCMAL Signals To External LPRA Signals
External MCMAL Product Number MCMAL Product Number

LPRA Signal Name -----x64D2P2W1R1M1 Signal Name -----x64D2P2W1R1M1
RA032 RA016 RA008 RA032 RA016 RA008
TX_LPRA_DATA 0:63 DO_RP1 63:0
MAL_TX_LPRA_RD_ADDR 1:5 2:5 3:5 A_RP1 4:0 3:0 2:0
TXDB_1 MAL_TX_LPRA_WR_ADDR 1:5 2:5 3:5 A_WP1 4:0 3:0 2:0

MAL_TX_LPRA_DATA_OUT_WE1 BW_WP1 63:0
MAL_TX_LPRA_DATA_OUT 0:63 DI_WP1 63:0
TX_LPRA_DATA 64:127 DO_RP1 63:0

MAL_TX_LPRA_RD_ADDR 1:5 2:5 3:5 A_RP1 4:0 3:0 2:0
TXDB_2 MAL_TX_LPRA_WR_ADDR 1:5 2:5 3:5 A_WP1 4:0 3:0 2:0

1
MAL_TX_LPRA_DATA_OUT_WE BW_WP1 63:0
MAL_TX_LPRA_DATA_OUT 64:127 DI_WP1 63:0

RX_LPRA_DATA 0:63 DO_RP1 63:0
MAL_RX_LPRA_RD_ADDR 1:5 2:5 3:5 A_RP1 4:0 3:0 2:0
MAL_RX_LPRA_WR_ADDR 1:5 2:5 3:5 A_WP1 4:0 3:0 2:0

RXDB_1
MAL_RX_LPRA_DATA_OUT_WE1 0 BW_WP1 63:32
MAL_RX_LPRA_DATA_OUT 0:63 DI_WP1 63:0

RX_LPRA_DATA 64:127 DO_RP1 63:0
MAL_RX_LPRA_RD_ADDR 1:5 2:5 3:5 A_RP1 4:0 3:0 2:0
MAL_RX_LPRA_WR_ADDR 1:5 2:5 3:5 A_WP1 4:0 3:0 2:0

RXDB_2
MAL_RX_LPRA_DATA_OUT 64:127 DI_WP1 63:0
1. It is necessary to duplicate these signals before connecting them.

Core Databook IBM
5.5 Test Interface Requirements

The test scheme must be added by the user.
5.6 Physical Design Requirements

As MCMAL is a soft core, the netlist has pseudo-latches and idealized clocks. The clock tree must be added
by the user.
5.7 Cell Names and Associated Library Elements
Table 38 lists the RAs used in the different MCMAL configurations.
Table 38. Internal RAs in MCMAL

MCMAL RA Amount
Configuration
MCMAL8 WRAP7A_RA008x61D2P2W1R1M1 4

132
IBM Core Databook
5.8 Performance and Operating Environment

See Section 2.9, Performance and Latency, on page 70 for further MCMAL performance and latency details.
5.8.1 Power Estimation
Table 39 lists the power estimation for the different MCMAL configurations.
Table 39. Power Estimation for the Different Configurations

MCMAL Technologies Worst case Power Estimation
Configuration (mW)
MCMAL8 Cu-11 and Cu-08 67
These numbers represent a worst case estimation model, with the 133 clocks and a switching factor of 0.15.
5.8.2 Size
MCMAL has three cores available in order to minimize core cell count if full configuration is not required.
Table 40. Size for the Different Configurations

MCMAL Technologies Size1
Configuration (K cells)
1. The size listed includes the internal RAs, but not the external ones.
5.8.3 Voltages and Temperature Ranges
MCMAL supports extended voltages and extended temperature ranges, verified using the following parame-
ters during static timing analysis.
Table 41. Extended Voltages and Extended Temperature Ranges

Technologies Worst/Best case Vdd Temperature Wireload Package Wireload Model Wireload Mode
Cu-11 and Cu-08 Worst case 1.4 v 125 °C 6lmc4a 1M_cells Top
Best case 1.6 v -40 °C 6lmc4ap 1M_cells Top

Core Databook IBM
5.9 Main changes from SA-27E version

In general, MCMAL in Cu-11 and Cu-08 is a technology remap of MCMAL in SA-27E, However, some modifi-
cations were made:
• PLB and E/OPB maximal frequencies allowed were increased to 166 Mhz.
• The entire test interface was removed. Ports that were removed:
• CLKA, CLKB, CLKC, CLK_C_SPLITTER.
• MCMAL_CHIP_AUTO_SCANIN 1 to 16.
• MCMAL_CHIP_AUTO_SCANOUT1 to 16.
• TEST1, WE, QW.
• Timing definition changed. Especially:
• MAL_TX_CHANNEL_SELECT and MAL_RX_CHANNEL_SELECT.
• OPB_MAL_GRANT.
• PLB_RST.
• The DCR interface.
• External RA timings.
• The Internal LPRAs were replaced with standard wrappers.

132

Mcmal16 32 64dma

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mcmal16 32 64dma

Uploaded by

Copyright:

Available Formats

IBM MCMAL 8/32/64 DMA for Cu-11 and Cu-08

Copyright and Disclaimer

All Rights Reserved

CoreConnect, IBM, IBM Logo, ibm.com, PowerPC

This document is VALID ONLY on the date printed.

IBM Systems and Technology Group

The IBM home page can be found at ibm.com

The IBM semiconductor solutions home page can be found at ibm.com/chips

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

2. Functional Description ............................................................................................. 17

2.5 MCMAL Operation on OPB and PLB .............................................................................................. 58

3. Software Interface ..................................................................................................... 83

4. Hardware Interface .................................................................................................. 115

5. Core Integration ....................................................................................................... 123

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

5.2.3 Channel Activation ............................................................................................................... 124

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

About this Book

Who Should Use this Book

Date Version Description Page

February, 2002 Preliminary Copy Initial release. —

halfword Refers to a 16-bit entity.

word Refers to a 32-bit entity.

doubleword Refers to a 64-bit entity.

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

Terms and Abbreviations

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

1.1.1 General Description

• MCMAL allows generic software control access for:

1.2.1 Clocking Scheme

1.2.2 Detailed Characteristics

MCMAL provides the following detailed characteristics:

• Soft core synthesized to Cu-11 and Cu-08 technology.

• Up to 166 MHz PLB clock frequency.

• Up to 166 MHz OPB clock frequency.

• Serves up to 64 channels (32 receive channels and 32 transmit channels).

• Handles buffer descriptor memory structure.

• Programmable receive buffer size (per channel).

• No limitations on buffer alignment.

• Maximum buffer size of 4095 bytes (TX) or 4080 bytes (RX).

• Up to 256 descriptors in a descriptor table (per channel).

Revision 1 MCMAL 8/32/64 DMA for Cu-11 and Cu-08

• No limitation on minimum transmit buffer size.

• Buffer-based interrupt capabilities per channel.

• Supports ComMac’s “back-to-back TX status mechanism” to allow ComMac’s increase in performance.

• Configures the ComMac according to commands in the descriptor status/control field.

• Packet retransmission capability.

• Concurrent operation of receive and transmit channels.

• PLB/OPB error detection.

• Supports PLB Specification version 4.3

• Configuration through the DCR bus.

1.3 MCMAL - ComMac Structure

1.3.1 Communication Core Specific Logic

The ComMac section is protocol specific and typically contains:

• A protocol specific logic layer.

• Data buffers (FIFOs) of various depths.

• Control and status registers.

• An OPB target logic layer.

1.3.2 Memory Access Layer

• Buffer descriptor handling and bookkeeping.

• OPB and PLB master capability for ComMac data handling.

• Status information forwarding from ComMac to BD via OPB.

• Command per packet information from BD to ComMac via OPB.