Selected papers from:
IBM RISC System/6000 Technology: Volume II
Sept. 23, 1993
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)
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.
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
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 .
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,