MCA Features
Selected papers from: IBM RISC System/6000 Technology: Volume II Sept. 23, 1993
Page 84-87

"Micro Channel Features" by Dan M. Neal and James O. Nicholson

The IBM Micro Channel interface is a general purpose computer interface intended to
support the use of I/O and feature cards in electronic data processing equipment. It was
originally introduced with the IBM Personal System/2 series of products and is also
utilized in the IBM RISC System/6000 (RS/6000), other IBM products, and other
manufacturers’ product lines.

The Micro Channel bus has been designed to allow use across a broad product spectrum.
Enhanced features of the Micro Channel architecture provide higher levels of
performance and error reporting and are fully compatible with the base Micro Channel
architecture. This article describes those features supported on the RISC System/6000
family of products. These include:
  » Streaming Data procedure (32–bit and 64–bit at 10 MHz)
  » Address and data parity Synchronous exception signalling

Streaming Data Procedure
   Streaming Data is a procedure that provides the ability to transfer multiple data cycles
within one bus envelope. The Streaming Data procedure amortizes device selection
overhead across the total packet, significantly increasing the performance capability of the
Micro Channel bus. Sustainable performance is a function of the total packet length and is
illustrated in Figure 1.

Figure 2 illustrates the procedures used in basic transfer and 10 MHz streaming data
cycles. A basic transfer cycle is initiated by a bus master placing an address on the bus,
and then activating one of the status signals, –S(0,1). A typical bus master will allow
100 ns for device selection, then activate the command (–CMD) signal for 100 ns to control
the data transfer. A streaming data cycle is similar, but instead of a word of data, a block
of data is transferred while the –CMD signal is active. The address specifies only the
starting address of the block.

Streaming Data Request (SDR)
  Three signals, streaming data request 0 and 1 (–SDR (0,1)) and streaming data strobe –SD_STROBE (–STB), mediate 16–bit and 32–bit streaming data cycles. The –SDR (0,1) signals are driven by the bus slave following activation of the address data latch (–ADL) signal to indicate that it supports streaming data. The –STB signal is driven by the bus master and serves as a bus clock delimiting words in the data transfer. Each negative transition of the –STB signal defines a new word. The –SDR(0,1) and –STB signals use tri–state drivers and require resistive pullups on card inputs to hold the signals high when not being driven. At the end of a streaming data cycle, the deactivation of the –CMD signal serves as the last bus clock

The –SDR(0,1) signals are coded to indicate the performance capabilities of the slave. This information is used by the bus master for speed matching to ensure that it does not exceed the maximum clocking rates of the slave. A master can perform streaming data transfers at 10 MHz when –SDR(0,1) is a binary 00, 01, or 10. A master can perform streaming data transfers at 20 MHz when –SDR(0,1) is a binary 00 or 10. The valid streaming data signal combinations from the selected slave are shown in Table 1.

At 10 MHz, the period of the –STB clock signal is 100 ns minimum. At 20 MHz, the period of the –STB clock signal is 50 ns minimum. The streaming data procedures are fully downward compatible. Masters and slaves that support 20 MHz streaming data must also support 10 MHz streaming data and Basic transfers. Likewise, Masters and slaves that support 10 MHz streaming data must also support Basic Transfers. The –SDR(0,1) signals do not have to be valid for a bus master to indicate streaming data support. Instead, a bus master normally activates the –STB signal concurrently with the –CMD signal and samples the –SDR(0,1) signals just before the deactivation of the –STB signal. If the –SDR(0,1) signals are not active at that time, the bus master deactivates the –S(0,1) signals and completes the cycle as a basic transfer. This provides relaxed timing requirements for the –SDR(0,1) signals.

The Streaming Data procedure for 16–bit and 32–bit transfers includes synchronous data pacing using the card channel ready (CD_CHRDY) and channel ready return (CHRDYRTN) signals. The slave indicates that it is not ready to complete a particular data cycle by activating the CD_CHRDY signal (RDY) after the –STB signal is activated. This is propagated to the CHRDYRTN signal by a logical AND operation on the system planar for sampling by the bus master. The bus master is required to repeat the data cycle if the CHRDYRTN signal is inactive (low) on the next transition of the –STB signal. The –STB signal must continue cycling until the slave activates the CD_CHRDY signal.

Termination controls are symmetric so that either the bus master or slave can end a streaming data cycle. The procedure is synchronous and is illustrated in Figure 3 for 10 MHz streaming data transfers.

Bus masters request termination by synchronously deactivating the –S(0,1) signal coincident with activation of the –STB signal, while slaves request termination by synchronously deactivating the –SDR(0,1) signals following the activation of the –STB signal. Bus masters should not terminate the cycle until the –SDR(0,1) signals are deactivated. If a slave is not ready when a master deactivates the –S(0, 1 ) signal, the slave should set the CD_CHRDY signal low and hold the –SDR(0,1) signals active until the cycle in which the CD_CHRDY signal will be set high. Although not illustrated, the architecture also supports the ability to defer initiation of streaming data cycles using the CD_CHRDY signal.

The termination procedures for 10 MHz and 20 MHz streaming data transfers are similar, but have differences. The primary difference is that the request for termination occurs on the data transfer before the desired stopping point for 10 MHz streaming data, while the termination request occurs on the next–to–last negative transition of –STB for 20 MHz streaming data transfers. For more detail on streaming data termination, the reader should refer to the Micro Channel architecture specification [1].

For compatibility reasons, all 16–bit and 32–bit streaming data cycles must be initiated on 4–byte address boundaries. This is because the Micro Channel architecture includes a byte–steering function to facilitate transfers between 16–bit bus masters and 32–bit bus slaves. This steering function is latched at the time the –CMD signal is activated and remains static throughout the data transfer envelope. As such, it would not properly steer the data when operating with 16–bit streaming masters. Specifying streaming data to begin on 4–byte address boundaries disables the steering controls, but results in the requirement that 32–bit slaves provide their own byte steering when engaged in data streaming operations with 16–bit masters.

Another streaming data capability includes use of the address bus to transfer data. Since only a single address cycle is provided by the master during a streaming data operation, the address bus can be made available (multiplexed) during the data portion of the cycle to transfer data. This allows a ”doubling” of the available bandwidth by transferring 64–bits of data each data cycle instead of only 32–bits. An additional Streaming Data signal is used to indicate that the operation will include 64–bit data transfers, ”Multiplexed Streaming Data Request” (–MSDR). This signal is driven by the slave to indicate to the controlling master that it supports 64–bit streaming data transfers.

The 64–bit streaming data transfers can only be performed between 64–bit streaming masters and 64–bit streaming data slaves. A 64–bit streaming data cycle is initiated as a 32–bit basic transfer cycle, and all the rules associated with this procedure applies. The selected slave activates –MSDR to indicate that it supports 64–bit streaming data operations. The data rate requested by the slave is indicated by –SDR(0,1). The –BE(0–3) signals are driven inactive by the master to indicate a 64–bit streaming data procedure will be used. During the transfer to the slave, the master starts –STB and gates the data onto the data and address buses. During a transfer to the master, the master tri–states the address bus after activating –CMD, and, after the trailing edge of –BE(0–3), the slave gates the data onto the data and address buses.

If 20 MHz streaming data is supported by both the master and the slave, both must execute at least 4 streaming data ”data cycles”. The master indicates 20 MHz streaming data transfers by driving the second Status line active. Figure 4 illustrates the 20 MHz streaming data procedure with 64–bit transfers. 20 MHz streaming data is currently not supported in the RS/6000 Systems.

Though a slave may delay the start of streaming data transfers using the CD_CHRDY signal, data pacing is not supported during 64–bit streaming data operations, and is not supported during 20 MHz streaming data operations.

Address and Data Parity
Address and Data Parity are provided to improve error detection characteristics of the Micro Channel architecture. These mechanisms are particularly well suited to detecting typical errors such as card–seating problems and electromagnetic interference.

Address parity and data parity support are optional and independent, and mixtures of  parity and non–parity devices are permitted. Address parity is controlled by a signal driven by the bus master called address parity enable (–APAREN). Normally, a slave device responds to a valid address by activating the card selected feedback (–CD_SFDBK) signal. If the –APAREN signal is active, all slave devices supporting address parity check address parity and, if incorrect, activate the channel check (–CHCK) signal as described in ”Synchronous Exception Signaling.” A slave should not become selected or activate the –CD SFDBK signal if address parity is incorrect and should not set any internal error status as the error may not have affected it. The bus master is then expected to suspend operations, set internal error status indicating that a –CHCK occurred with no –SFDRKRTN signal, and interrupt the system.

Data parity checking is controlled by the data parity enable (–DPAREN) signal. If a parity error is detected during a write operation, and the –DPAREN signal is active, slave devices supporting data parity activate the –CHCK signal as described in ”Synchronous Exception Signaling”. If the bus master detects a read data parity error and the –DPAREN signal is active, it is expected to suspend operations, set internal error status indicating that a read parity error occurred, and interrupt the system.

Synchronous Exception Signaling
The Micro Channel architecture provides for exception signaling with the –CHCK signal. Initial use of the –CHCK signal was asynchronous in the Personal System/2 products. The use of the –CHCK signal was enhanced to support the signaling of synchronous events such as page faults, write parity errors, and command queue overflows. Synchronous exception signaling simply allows the pulsing of the –CHCK signal in the same bus cycle that caused the exception. This feature is key to meeting system data integrity and error recovery requirements of the RS/6000 system.


Three features of the Micro Channel architecture have been discussed. These features: increasing the ”peak” bandwidth capabilities first from 20M bytes/sec to 40M bytes/sec, then to 80M bytes/sec, and most recently to 160M bytes/sec; addition of parity checking as an optional feature; and support of synchronous exception signaling, broaden the characteristics of that bus to support advanced I/0 devices or systems. These features retain compatibility with existing card and planar board designs. These features are implemented in the RS/6000 family of products and are key factors in meeting the performance, data integrity, and error recovery goals of that system.


The Micro Channel architecture was jointly developed with Boca Raton architecture and
various product development groups worldwide. B.M. Bass, D.M. Desai, J.K. Langgood, S. Dhawan, R.A. Kelley, L.F. McDermott, D.M. Neal, J.O. Nicholson, J.D. Reid, F.E. Strietelmeier, J.D. Touchton, R.K. Arimilli, D.W. Siegel, and L.P. Vergari provided substantial contribution to the Micro Channel features described in this article and their contributions are appreciated.

1. IBM Personal System/2 Hardware Interface Technical Reference – Architectures Manual, IBM Corporation.

9595 Main Page