ISO/IEC 10859:1997

INTERNATIONAL
ISO/IEC
STANDARD
First edition
1997-06
Information technology –
8-bit backplane interface: STEbus and mechanical
core specifications for microcomputers
Technologies de l'information –
Interface de fond de panier 8 bits – Bus STE

Reference number
ISO/IEC 10859: 1997(E)
INTERNATIONAL
ISO/IEC
STANDARD
First edition
1997-06
Information technology –
8-bit backplane interface: STEbus and mechanical
core specifications for microcomputers
Technologies de l'information –
Interface de fond de panier 8 bits – Bus STE

 ISO/IEC 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.

ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland

– 2 – 10859 © ISO/IEC:1997
CONTENTS
Page
FOREWORD . 3

IEEE STANDARD FOR A 8-BIT BACKPLANE INTERFACE: STEBUS

INTRODUCTION . 4

Clause
1 General . 5
2 Functional description. 9
3 Signal lines. 10
4 Arbitration. 16
5 Data transfer protocol . 18
6 Inter-board signalling . 32
7 Electrical specifications . 36
Appendices
A Applicable IEC specifications . 42
B Recommended bus termination arrangement . 43
MECHANICAL CORE SPECIFICATIONS FOR MICROCOMPUTERS
Page
INTRODUCTION . 45
Clause
1 Scope. 46
2 Object . 46
3 References. 46
4 General arrangement. 47
5 Euroboard matrix . 49
6 Euroboard sizes. 50
7 Position of plug-in unit mounted connectors (Board types and box type) . 55

8 Plug-in unit description . 58
9 Plug-in unit dimensions. 58
10 Backplane design and mounting positions . 59
11 Subracks . 83
12 Environmental specifications. 93

10859 © ISO/IEC:1997 – 3 –
Information technology –
8-bit backplane interface:
STEbus and mechanical core specifications

for microprocessors
FOREWORD
ISO (the International Organization for Standardization) and IEC (the International

Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committee established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC1. Draft International Standards adopted by the joint technical
committee are circulated to national bodies for voting. Publication as an International Standard
requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 10859 was prepared by joint technical committee
ISO/IEC JTC1, Information technology, SC 26: Microprocessor system.
This standard is a merging of IEEE Std 1000-1987 and IEEE 1101-1987. It has been submitted
to the National Committees for vote under the Fast Track Procedure.
The numbering of the original clauses remains unchanged.

– 4 – 10859 © ISO/IEC:1997
INTRODUCTION TO IEEE STANDARD
FOR AN 8-BIT BACKPLANE INTERFACE: STEBUS

The initial concept for STEbus was to produce a European version of the STDBus using the

Eurocard form factor with the DIN41612 connector. From that concept STE became known as

STD-European.
When IEEE formed Working Group P1000 the brief specified a Standard 8-Bit Backplane

Interface. At the inaugural meeting of Working Group P1000 it quickly became apparent that

the opportunity was there to create a completely new, modern, high-performance 8-Bit bus, and
all ideas of merely repinning the old STDbus were rapidly forgotten.

At the initial meeting of P1000 it was decided that the bus should be a part of the same family
as VMEbus and Futurebus and as such should be an asynchronous bus with multimaster
capability. Today it is often referred to as the baby brother of VMEbus. Unlike VMEbus though
it was to be processor and manufacturer independent. This has proven to be an excellent
decision as today there are many varied types of processor available on STEbus, from
microcontrollers such as 8031, through Intel's 8085, 8088, and 80188; National
Semiconductor's 32008 and 32016; Motorola's 6809, 68000, and 68008; Zilog's Z80 and Z280;
Hitachi's 64180, and the Inmos Transputer with the promise of more to come.
A presentation was made to a packed audience at the IEE in London, England in early 1983. It
met with critical acclaim. The first article about STEbus was also published about this time in
an international magazine (EDN May 26, 1983).
Work continued internationally and in late 1984 Draft D3.1 was produced. This draft eradicated
the daisy-chain bus request mechanism of D2.0 in favour of a simple solution that allowed
position independence of cards in the rack.
This was the first firm specification and encouraged more manufacturers to look at the bus
seriously. Among them were BICC-Vero, a major manufacturer of Eurocard enclosures and
backplanes, and British Telecom, the UK's Telephone Utility. Market ground zero was early
1985 and since this time the number of manufacturers has continued to grow from
18 companies in Spring 1986 to more than 30 in mid-1987, with over 700 products available.
Much credit and praise is due Tim Elsmore who first conceived the idea for STEbus during his
employment with GMT Electronic Systems Ltd. Paul Borrill was instrumental in negotiating with
IEEE the formation of Working Group P1000 and Bill Shields was appointed Chairman.
This standard was prepared by Working Group P1000 of the Microprocessor Standards
Committee.
10859 © ISO/IEC:1997 – 5 –
Information technology –
8-bit backplane interface:
STEbus and mechanical core specifications

for microprocessors
1 General
1.1 Scope
The overall level of performance that may be achieved by any computer system is determined,
in large part, by the system bus that is used to effect communication between the various
system elements. System performance characteristics, measured in terms of speed, reliability,
suitability to a variety of purposes, and adaptability to changing technology are ultimately
dependent on the particular bus structure that is used and its associated protocols.
This standard defines the IEEE Std 1000 Bus, which may be used to implement general
purpose, high-performance 8-bit microcomputer systems. Such a system may be used in a
stand-alone configuration, or in larger multiple-bus architectures, as a private (or secondary)
bus or a high-speed I/O channel. This standard is applicable to those systems and system
elements with the common commercial designation STEbus. It is intended for those users who
plan to evaluate, implement, or design various system elements that are compatible with the
IEEE 1000 Std Bus system structure.
The physical attributes and method of interconnect utilized by boards and modules conforming
to this standard are derived from several International Electrotechnical Commission (IEC)
standards. These standards, when implemented jointly in a systems environment, result in a
mechanical configuration commonly referred to as Eurocard. Appendix B lists such applicable
standards which, where referenced, are considered as if incorporated with this standard. In
particular, the connector used by IEEE Std 1000 Bus boards is a 64-pin male connector
utilizing the outside two rows (designated a and c rows), specified in IEC 60603-2, and the
mating female connector is used on IEEE Std 1000 Bus backplanes. The recommended size
for IEEE Std 1000 Bus boards is 100 mm × 160 mm (3,937 in × 6,299 in), commonly referred to
as a single height standard depth Eurocard.
The IEEE Std 1000 Bus structure is based on the master-slave concept in which a master,
having gained control of the bus, may address and command slaves. Masters and slaves
communicate with each other by use of an asynchronous interlocked handshake protocol. This
technique allows for the construction of computer systems that incorporate devices of widely
varying speeds. Multiple masters may be implemented within a single system.

Two independent address spaces are supported: memory and I/O. Memory transactions
reference a 1 megabyte physical address space, while I/O transactions reference a 4 kilobyte
physical address space. System integrity during all such transactions is enhanced by provision
of a transfer error signal.
Provision is made for interboard condition alerts such as interrupt requests, DMA requests,
system-specific error conditions, or other specialized status conditions. Within this scheme
eight prioritized attention request levels, each with vectored response capability, are available
for user assignation.
This standard deals only with those characteristics that must be specified so as to ensure the
successful design and implementation of compatible boards and systems. Issues relating to
individual design specifications, and performance or safety requirements are not addressed.

– 6 – 10859 © ISO/IEC:1997
1.2 Features
The fundamental features offered by IEEE Std 1000 Bus are as follows:

8-bit Data Field Width
1 Megabyte Memory Address Range

4 Kilobyte I/O Address Range
Asynchronous Data Transfer
Transfer Error Signal
Multiple Masters
Eight Attention Request Lines
IEC 603-2 Connector
Single or Double Eurocard Boards and Modules
5 V, ±12 V and Standby Power Supply Distribution
Total Position Independence of Boards and Modules in Backplane
Total Inter-Board Compatibility
Total Central Processing Unit (CPU) Generic Device Family Independence
Potential 5 Megabyte per Second Data Transfers
1.3 Objects
This standard is intended to
1) define a general purpose microcomputer board interface;
2) specify those device-independent electrical, mechanical, and functional interface
parameters that must be met so as to effect unambiguous communication between system
elements and to effect physical compatibility;
3) specify the terminology and definitions related to the specification;
4) enable the interconnection of a wide variety of independently manufactured boards within
a single functional system;
5) define a standard that places the minimum number of restrictions on the performance
characteristics of boards within a conforming system;
6) allow microcomputer system users of relatively modest experience to assemble
modularly expandable computer systems with a high probability of success.
1.4 Definitions
The following general definitions apply throughout this standard. Additional detailed definitions
are given where appropriate.
1.4.1 General system terms
compatibility: The degree to which boards may be interconnected and used without
modification when designed according to the specifications contained within this standard.
interface: A shared boundary between two or more systems, or between two or more elements
within a system, through which information is conveyed.
interface system: The device-independent electrical, mechanical, and functional interface
elements required for unambiguous communication between two or more devices. Typical
elements include:
10859 © ISO/IEC:1997 – 7 –
– driver and receiver circuitry;

– signal line descriptions;
– timing and control conventions;

– communication protocols;
– functional logic circuits.
system: A set of interconnected boards that achieve a specified objective by the performance

of designated functions.
1.4.2 Signals and paths
address: The reference to a unit of data or the value represented by the address lines while
ADRSTB* is active.
addressed board: A board that recognizes its address while ADRSTB* is active.
arbitration: The means whereby masters compete for control of the bus and the process by
which a master is granted control of the bus.
backplane: A printed circuit board (pcb) on which connectors are mounted, into which boards
or plug-in units are inserted.
block transfer: A sequence of data transfers, in the same direction, that occur during a single
bus transaction.
board: A printed circuit board (pcb) that complies with this standard.
bus: A signal line or set of lines used by an interface system to connect a number of devices,
and over which information is conveyed.
byte: A set of eight signals, individually referred to as bits, which are operated on as a unit.
handshake: An interlocked sequence of signals between interconnected boards in which each
board waits for an acknowledgement of its previous signal before proceeding.
high state: The more positive voltage level used to represent one of two logical binary states.
low state: The more negative voltage level used to represent one of two logical binary states.

module: A plug-in unit consisting of one or more boards that contains at least one bus
interface conforming to this standard, which plugs into the backplane.
protocol: The signalling rules used to convey information or commands between boards
connected to the bus.
release: The action of a transmitter in ceasing to hold a signal line in the asserted state.
sequence: An indivisible bus transaction comprising one or more transfers.
settling time: The time taken for a signal line to settle unambiguously to a logical state when
making a transition from one state to another.
signal: The physical representation of data.

– 8 – 10859 © ISO/IEC:1997
signal level: The relative magnitude of a signal when considered in relation to an arbitrary

reference. The unit of representation used within this standard is the volt.

signal line: One of a set of signal conductors in an interface system used to transfer data

among interconnected boards.
signal parameter: That element of an electrical quantity whose values or sequence of values

convey information.
tenure: The time during which a master has control of the bus.

transaction: The combination of data transfer sequences controlled by a master during a
single bus tenure.
transfer: The movement of a single byte of data from the current master to the addressed
slave(s) or from the addressed slave to the master.
1.4.3 Generic signal names
Throughout this standard bus request and acknowledge signals and attention request signals
are sometimes referred to as BUSRQn*, BUSAKn*, and ATNRQn* respectively. Such general
references are equivalent to specific references RUSRQ0* or BUSRQ1* etc.
1.4.4 Notation for bus signals
Throughout this standard signals on a particular bus are referred to collectively using the form
A<19.0>. This notation should be taken as an abbreviation of all of the address bus signals
from A19 through to A0 inclusive.
In addition to the address bus signals, the notation is also used for the data lines (for example,
D<7.0>), the common lines (for example, CM<2.0>), the attention request lines (for example,
ATNRQ<7.0>*), the bus request lines (for example, BUSRQ<1.0>*) and the bus acknowledge
lines (for example, BUSAK< 1.0 >*).
1.5 Logical and electrical state relationships
Throughout this standard the term asserted is used to indicate the logical true state of the
particular signal referenced. The corresponding term negated, however, is not used because it
comprises a potentially ambiguous representation when describing signals, which may be low
or high true.
All signals that are low in their asserted state are designated by a nathan (asterisk), which

follows the signal name (for example, ADRSTB*). The correlation between the terms true:false,
high:low, and asserted:released is demonstrated in the following table, utilizing the signals
ADRSTB* and CM<2.0> as an example.
Function Electrical Logical State
CM<2.0> High 1 True Active, asserted
Low 0 False Active, released
High Z – Inactive
ADRSTB* Low 1 True Active, asserted
High 1 False Active, released
High Z – Inactive
10859 © ISO/IEC:1997 – 9 –
2 Functional description
This section describes the functional elements of IEEE Std 1000 Bus interface. They are

1) System Controller
2) Arbiter
3) Masters
4) Slaves
An individual board attached to IEEE Std 1000 Bus backplane may consist of one or more of

these elements.
2.1 System controller
Within any IEEE Std 1000 Bus system there shall be one, and only one, system controller. The
system controller provides essential facilities for the proper operation of IEEE Std 1000 Bus
systems. The system controller may be combined on a board with a master.
The system controller shall provide as a minimum the following requirements:
1) SYSCLK. A general-purpose clock signal in accordance with the specifications detailed in
Section 3 of this standard.
2) SYSRST*. An initial power-on system reset signal in accordance with the specifications
detailed in Section 3 of this standard.
3) TFRERR*. A transfer error signal in accordance with the specifications detailed in
Section 3 of this standard.
2.2 Arbiter
All bus allocation grants shall be provided by the arbiter in accordance with the protocol
described in Section 4 of this standard. There shall be one, and only one, arbiter within any
IEEE Std 1000 Bus system. The arbiter may be combined on a board with a master.
2.3 Masters
A master is a board that is capable of controlling the transfer of data on the bus, by means of
the protocols defined in Sections 4 and 5 of this standard. A master may contain a central
processing unit (cpu) or logic necessary to transfer data over the bus (for example, DMA
controller).
2.3.1 Master types
All masters must request allocation of IEEE Std 1000 Bus from the arbiter before they can
control data transfers except in the special case of a default master.
default master: A master that is allocated control of the bus by the arbiter whenever the bus is
not in use by another master. A default master is necessarily combined with the arbiter on the
same board and has the lowest priority for bus allocation. There can be only one default master
within a IEEE Std 1000 Bus system, though a IEEE Std 1000 Bus system need not include a
default master.
All other masters (termed potential masters) request allocation of bus control from the arbiter.
This request shall be made by asserting one of the two bus request (BUSRQn*) lines, or in the
case of a master that is on the same board as the arbiter but is not configured as a default
master, by asserting a third bus request line that is private to that board.
Multiple masters may exist within a system. The master's priority for bus control allocation and
the means by which such allocation is accomplished are as described in Section 4.

– 10 – 10859 © ISO/IEC:1997
2.3.2 Master modes
Masters may retain control for a period of time constrained only by the specific system

requirements. Two modes of operation may be used by masters.

1) Release-when-done. The master retains control of the bus until all desired transfers have

been accomplished.
2) Release-on-request. The master retains control of the bus indefinitely, relinquishing

control when it determines that another master requires allocation of the bus. This

determination may be made by several methods including receipt of an attention request

signal, hardware polling, or by detection of a BUSRQn* signal becoming active.

NOTE – By definition a default master always operates in release-on-request mode.

2.4 Slaves
Boards that are capable of being controlled over the IEEE Std 1000 Bus are designated slaves.
Slaves decode the address lines and act upon the command provided by the current master.
A slave may be combined with other functional elements on a board (for example, a board that
contains both a master and memory that is accessible by other masters within the system).
Figure 1 shows one possible system configuration that utilizes a variety of boards in
combination.
Figure 1 – Example of system configuration
3 Signal lines
This section provides specific definitions for all signal lines that are part of the IEEE Std 1000
Bus. Each of these signals has been assigned to one of five functional groups. These groups
are
(1) Information Lines
(a) Address Lines
(b) Data Lines
(c) Command Lines
(2) Synchronization Lines
(3) Attention Request Lines
(4) Bus Allocation Lines
(5) Utility lines
10859 © ISO/IEC:1997 – 11 –
3.1 Information lines
3.1.1 Address lines (A<19.0>)

These unidirectional lines specify the address of the referenced memory or I/O location or,

during a vector fetch response to an attention request, the level of the request being

acknowledged. The most significant bit is A19 and A0 is the least significant.

The following table details the usage of the address lines during various types of operations.

Operation Valid lines Total addressed range

Memory read or write A<19.0> 1 048 576 bytes

I/O read or write A<11.0» 4 096 locations
Vector-fetch A<2.0» 8 levels
3.1.2 Data lines (D<7.0>)
These eight bidirectional lines carry information between masters and slaves. The most
significant bit is D7 and D0 is the least significant.
3.1.3 Command lines (CM<2.0>)
These signals are used by the current master to convey coded data to the slave describing the
type of the current data transfer according to table 1.
Command codes marked reserved shall not be used, and IEEE Std 1000 boards shall not
respond to or utilize these codes for any purpose so as to be considered in compliance with
this standard. This is to guarantee compatibility with boards that may be designed to conform
to future revisions of this standard.
Table 1 – Command codes
CM2 CM1 CM0 Transfer
0 0
0 Reserved
0 0
1 Reserved
0 1
0 Reserved
0 1
1 Vector-fetch
1 0
0 I/O write
0 1 I/O read
1 0 Memory write
1 1 Memory read
3.2 Synchronization lines
The following signals are classified as synchronization lines:
Signal Function
ADRSTB* Address strobe
DATSTB* Data strobe
DATACK* Data transfer acknowledge
TFRERR* Transfer error
– 12 – 10859 © ISO/IEC:1997
3.2.1 Address strobe (ADRSTB*)

This signal indicates the presence of valid data on the address lines.

3.2.2 Data strobe (DATSTB*)
This signal indicates the presence of valid data on the command lines CM<2.0>. During a
read, or vector-fetch transfer, this signal indicates that the addressed slave may place data on

the data lines. During a write transfer this signal indicates the presence of valid data on the

data lines.
3.2.3 Data transfer acknowledge (DATACK*)

This signal is used to indicate to the master that the command has been performed: that data
have been placed on, or accepted from, the data lines.
3.2.4 Transfer error (TFRERR*)
This signal may be asserted by any board to indicate an error during the current transfer.
Specific timing requirements for this signal are detailed in Section 5 of this standard.
3.3 Attention request lines (ATNRQ<7.0>*)
These signals are configured for indicating user-specific events when a IEEE Std 1000 Bus
system is commissioned. Such events may include, but are not limited to, interrupt requests,
DMA requests, or notification of conditions, which exist either at the board or system level (for
example, failure). Eight attention request lines are available. Three optional response protocols
are described in Section 6 of this standard for the use of attention request lines as traditional
interrupts.
These signals may be used by any board to request the attention of other boards within IEEE
Std 1000 Bus systems. Any board within the system may be connected to any of the eight
attention request lines. Multiple boards may be connected to the same attention request line
allowing for the broadcast of events to one or more boards within a system. There is an implied
priority with ATNRQ7* having highest priority and ATNRQ7* having the lowest.
3.4 Bus allocation lines
The bus allocation lines are:
Signal Function
BUSRQ<1.0>* Bus request lines
BUSAK<1.0>* Bus acknowledge lines

3.4.1 Bus request lines (BUSRQ<1.0>*)
These signals may be asserted by any potential master that desires allocation of the IEEE Std
1000 Bus. In systems utilizing prioritized arbitration, BUSRQ0* shall have priority over
BUSRQ1*.
3.4.2
Bus acknowledge lines (BUSAK<1.0>*)
These signals are used by the arbiter to indicate to a master requesting bus allocation that it
may take control of the bus. BUSAK1* indicates a grant to the master requesting by way of
BUSRQ1*, and BUSAK0* indicates a grant to the master requesting by way of BUSRQ0*.

10859 © ISO/IEC:1997 – 13 –
3.5 Utility lines
The following signals are classified as utility lines:

Signal Function
SYSCLK System clock
SYSRST* System reset
3.5.1 System clock (SYSCLK)
The system clock is a periodic signal of constant frequency that may be used as a generalized
facility by masters or slaves. The system clock is independent of the protocol of any other bus
signals, and is provided by the system controller. Figure 2 contains timing waveforms for
SYSCLK.
3.5.2 System reset (SYSRST*)
The system reset signal is used to place the system in a known initial state. While SYSRST* is
active all boards shall inhibit any access to the system bus. SYSRST* may be driven by any
board. It is recommended that during a power-up sequence, any board capable of performing
on-board diagnostic self-tests hold SYSRST* active until the successful completion of such
tests.
The system controller shall provide an initial power-on system reset signal that is not <200 ms
and not >500 ms in duration, measured from the point at which the +5 V d.c. supply reaches its
designated minimum specification (see Section 7). The system controller also shall assert
SYSRST* at any time that the system supply falls below its minimum specified tolerance, and
shall continue to assert it for the entire period during which the supply is out of tolerance. The
rise time of this signal shall not exceed 100 ns (10 %-90 %).
A recommended power-fail protocol, for implementation of systems where an early indication of
primary power supply failure is available, is provided in Section 7.

t
= 62,5 ns ± 1 ns (16,00 MHz)
cycle
t = 31,25 ns ± 10 ns
high
t
= 31,25 ns ± 10 ns
low
Figure 2 – SYSCLK timing
– 14 – 10859 © ISO/IEC:1997
3.6 IEEE Std 1000 Bus connector pin allocations

3.6.1 Connector type
The IEEE Std 1000 Bus connector pair shall be C064 from IEC 60603-2. The male connector

shall be on the board and the female connector shall be on the backplane.

3.6.2 Connector pin allocation

The allocation of the signals described in this standard to pins on the IEEE Std 1000 Bus

connector are in figure 3.
The backplane tracking arrangement shown is recommended so as to allow the signal 0 V
return traces to provide guard track protection between strobes and signal sets.

10859 © ISO/IEC:1997 – 15 –
Figure 3 – IEEE Std 1000 Bus connector

– 16 – 10859 © ISO/IEC:1997
4 Arbitration
This section defines the protocol that is used by IEEE Std 1000 Bus masters to gain control of

the IEEE Std 1000 Bus.
The following signals are used to effect allocation of bus control within IEEE Std 1000 Bus

systems:
BUSRQ<1.0>*
BUSAK<1.0>*
4.1 Arbitration algorithm
On power-up, or following a system reset, the arbiter shall have control of the bus. All masters
(except default masters) must request and receive a control allocation grant from the arbiter
prior to controlling the bus. Only the arbiter may effect a change in allocation of bus control
within an IEEE Std 1000 Bus system.
Any algorithm may be used by the arbiter to determine which of the bus request levels will be
granted when the current master releases the bus, although, by convention, the
BUSRQ0*/BUSAK0*, request/grant pair have priority over BUSRQ1*/BUSAK1*. The arbiter may
award preference to one requesting level on a priority basis, a round-robin basis, or by means
of any other algorithm implementable within the control transfer protocol.
4.2 Bus requests
A Bus request may be initiated by any master within an IEEE Std 1000 Bus system at any time
by asserting one of the BUSRQ* lines. Bus requests are level-triggered, meaning that a
requesting condition is indicated by the relative voltage level present on a BUSRQ
n* line rather
than by the active transition from one state to another.
A master, having asserted one of the BUSRQn* lines, shall continue to assert it for the entire
period during which it desires to control the bus.
NOTE – Multiple masters may be connected to a single BUSRQn* line only when it can be assured that more
than one master cannot request the bus at the same time, on the same requesting level.
4.3 Bus grants
BUSAK0* or BUSAK1 * are asserted by the arbiter in response to the corresponding requests,
BUSRQ0* and BUSRQ1*. The arbiter shall not assert either of these grant lines in the absence
of a corresponding bus request. In addition, the arbiter shall not assert both bus acknowledge
lines simultaneously under any circumstances.

A master asserting a bus request line and detecting the corresponding bus acknowledge line
asserted may assume control of the bus. The arbiter, having asserted a bus acknowledge line,
shall continue to assert it for the entire period during which the current master continues to
assert the corresponding bus request line.
4.4 Control allocation sequence
Figure 4 shows the handshake-signal flow during an allocation of bus control. The sequence of
events for all allocations of bus control shall conform to the following description:
A master may request allocation of the IEEE Std 1000 Bus at any time by asserting one of the
BUSRQ* lines except that a master may not assert BUSRQn* until the corresponding BUSAKn*
has been released from a previous cycle.

10859 © ISO/IEC:1997 – 17 –
The arbiter, upon detecting BUSRQn* active, and having first assured that the bus is available,

shall assert BUSAKn* indicating that the bus is available for use by the requesting master. The

arbiter shall not assert BUSAKn* in the absence of a corresponding BUSRQn*. The bus is

available for arbitration if the arbiter is not issuing a bus grant to any master, either by

asserting BUSAKn* or by granting to the bus to its own on-board master (if one is present).

The requesting master, upon detecting that BUSAKn* has been made active, shall assume
control of the bus.
Upon completing the desired data transfer sequences, the current master shall cease driving
all bus lines and shall then release BUSRQn*.

The arbiter, upon detecting that the BUSRQn* is no longer asserted, shall release BUSAKn*.

Figure 4 – Control transfer flow diagram

– 18 – 10859 © ISO/IEC:1997
Figure 5 – Example of multiple master implementation
5 Data transfer protocol
This section defines the protocol and timing requirements necessary to effect data transfer
sequences across the IEEE Std 1000 Bus. All data are transferred as single bytes using an
asynchronous interlocked handshake. The asynchronous nature of the protocol allows
communication between masters and slaves of widely differing speeds, and is essentially
self-adaptive to changing system configurations.
Indivisible read-modify-write sequences are accommodated within the protocol, allowing
synchronization of tasks in a multiple processor system by use of lock variables.
A high-speed burst mode of data transfer is also specified, allowing for rapid movement of
contiguous data blocks between boards.
Figure 6 illustrates the various types of sequences accommodated by the IEEE Std 1000 Bus

data transfer protocol.
The signals used for data transfer sequences are
Signal Source
A<19.0> Master
D<7.0> Master during write, slave during read, and vector-fetch
CM<2.0> Master
ADRSTB* Master
DATSTB* Master
DATACL* Slave
TFRERR* Any board
10859 © ISO/IEC:1997 – 19 –
Throughout this section the word master implies current master, that is, it is assumed that the

master discussed has been allocated control of the IEEE Std 1000 Bus by means of the

protocol described in Section 4 of this standard.

Figure 6 – IEEE Std 1000 Bus data transfer sequences
5.1 Read sequence
Data transfers from slave to master are designated read sequences. Figure 7 illustrates the
handshake-signal flow, and figure 10 specifies the signal timing parameters for a read
sequence. Read sequences shall conform to the following description:
1) The master places the address of the targeted memory or I/O location on the address
lines.
NOTE – The master may assert the appropriate command code at this time.

– 20 – 10859 © ISO/IEC:1997
Figure 7 – Read sequence flow diagram
2) After a setup time, during which the address lines become valid, and having ensured that
DATACK* is released from the previous cycle, the master shall assert ADRSTB*.
3) The master shall activate the command lines, CM<2.0>, to indicate the type of transfer.
CM2 CM1 CM0 Transfer
1 0 1 I/O read
1 1 1 Memory read
4) After a setup time during which the command lines become valid, the master shall assert
DATSTB* indicating the presence of valid data on the command lines, and that it is ready to
accept data.
5) The addressed slave shall enable its data bus drivers, placing requested data on the data
lines.
6) After a setup time, during which the data lines become valid, the addressed slave shall
assert DATACK* indicating that the data is available.
7) In response to DATACK* the master shall accept the data and shall release DATSTB*
indicating to the slave that it must remove the data from the data lines.
8) Upon detecting either DATSTB* or ADRSTB* released, the slave disables its data bus
drivers and releases DATACK* indicating that the sequence is complete.

10859 © ISO/IEC:1997 – 21 –
5.2 Write sequence
Data transfers from masters to slaves are designated write sequences. Figure 8 illustrates the

handshake signal flow, and figure 11 specifies the signal timing parameters for a write
sequence. Write sequences shall conform to the following description:

1) The master places the address of the targeted memory or I/O location on the address

lines.
NOTE – The master may assert the appropriate command code at this time.

2) After a setup time, during which the address lines become valid, and having ensured

DATACK* is released from the previous cycle, the master shall assert ADRSTB*.

3) The master shall activate the command lines, CM<2.0>, to indicate the type of transfer,
and shall place the data to be transferred on the data lines.
CM2 CM1 CM0 Transfer
1 0 0 I/O write
1 1 0 Memory write
4) After a setup time, during which the data lines and the command lines become valid, the
master shall assert DATSTB* indicating the presence of valid data on the data and
command lines.
5) The addressed slave shall accept the data and shall assert DATACK* to indicate that the
transfer may be terminated.
6) In response to DATACK* the master shall release ADRSTB* and DATSTB*.
7) Upon detecting either DATSTB* or ADRSTB* released, the slave shall release DATACK*
indicating that the sequence is complete.

– 22 – 10859 © ISO/IEC:1997
Figure 8 – Write sequence flow diagram
5.3 Read-modify-write sequence
Sequences during which the data is transferred to the master, operated on by the master, and
subsequently transferred from the master to the same address, in a single indivisible sequence
are designated read-modify-write sequences. Figure 9 illustrates the handshake signal flow,
and figure 12 specifies the signal timing parameters for a read-modify-write sequence.
Read-modify-write sequences shall conform to the following description:

1) The master places the address of the targeted memory or I/O location on the address
lines.
NOTE – The master may assert the appropriate command code at this time.
2) After a setup time, during which the address lines become valid, and having ensured
DATACK* is released from the previous cycle, the master shall assert ADRSTB*.
3) The master shall activate the command lines, CM<2.0>, to indicate the type of transfer.
CM2 CM1 CM0 Transfer
1 0 1 I/O read
1 1 1 Memory read
10859 © ISO/IEC:1997 – 23 –
4) After a setup time during which the command lines become valid the master shall assert

DATSTB* indicating the presence of valid data on the command lines, and that it is ready to

accept data.
5) The addressed slave shall enable its data bus drivers, placing the requested data on the

data lines. A slave shall not respond to DATSTB* unless ADRSTB* is asserted.

6) After setup time, during which the data lines become valid, the addressed slave shall

assert DATACK* indicating that the data is available.

7) In response to DATACK* the master shall accept the data and shall release DATSTB*,

indicating to the slave that it must remove the data from the data lines.

8) Upon detecting DATSTB* released, the slave disables its data bus drivers and releases
DATACK* indicating that the read transfer is complete.

9) After operating on the data and detecting DATACK* released, the master shall activate
command line CM0 logic 0), indicating a write command, and shall place the modified data
to be transferred on the data lines.
10) After a setup time, during which the data lines and command line CM0 become valid,
the master shall assert DATSTB* indicating the presence of valid data on the data and
command lines.
11) The addressed slave shall accept the data and shall assert DATACK* to indicate that
the transfer may be terminated.
12) In response to DATACK* the master shall release ADRSTB* and DATSTB*.
13) Upon detecting either DATSTB* or ADRSTB* released, the slave shall release
DATACK* indicating that the sequence is complete.

– 24 – 10859 © ISO/IEC:1997
Figure 9 – Read-modify-write sequence flow diagram

10859 © ISO/IEC:1997 – 25 –
Figure 9 (continued) – Read-modify-write sequence flow diagram

– 26 – 10859 © ISO/IEC:1997
Figure 10 – Read sequence timing diagram

10859 © ISO/IEC:1997 – 27 –
Figure 11 – Write sequence timing diagram

– 28 – 10859 © ISO/IEC:1997
Figure 12 – Read-modify-write sequence timing diagram

10859 © ISO/IEC:1997 – 29 –
5.4 Vector-fetch
In responding to an attention request as described in Section 6 of this standard, a master may

perform a vector-fetch sequence. The protocol and signal timing parameters of a vector-fetch
sequence are identical to those of a read sequence except that only address lines A<2.0> are
valid and the command code is:

CM2 CM1 CM0 Transfer
0 1 1 Vector-fetch
5.5 Burst transfer sequences
A special form of either read, write, or vector-fetch sequence may be supported by IEEE Std
1000 Bus boards. This is referred to as burst transfer mode. During a burst data transfer the
operation proceeds according to the previously described protocols except that multiple
DATSTB*-DATACK* handshakes occur between the master and the addressed slave.
ADRSTB* and all used address lines shall remain stable throughout the sequence. The
command lines shall remain stable throughout the sequence.
A slave board may be configured to participate in burst-mode transfer sequences by including
logic that auto-increments or auto-decrements the onboard address on active edges of
DATSTB*, or by use of a first-in, first-out (FIFO) register array.
Figure 13 specifies the signal timing parameters for burst-mode transfer sequences.

– 30 – 10859 © ISO/IEC:1997
Figure 13 – Burst mode transfer sequence timing diagram
Read cycles illustrated
10859 © ISO/IEC:1997 – 31 –
5.6 General data transfer rules

1) A master shall not assert DATSTB* while ADRSTB* is released.

2) A slave shall not respond to DATSTB* while ADRSTB* is released.

3) A slave shall not assert TFRERR* and DATACK* simultaneously.

4) All address lines used in any transfer sequence shall be valid when ADRSTB* is
asserted, and shall remain valid until ADRSTB* is released.

5) All command lines shall be valid when DATSTB* is asserted, and shall remain valid until

DATSTB* is released.
6) During read transfers all data lines shall be valid when DATACK* is asserted, and shall

remain valid until DATSTB* is released.
7) During write transfers all data lines shall be valid when DATSTB* is asserted, and shall
remain valid until DATSTB* is released.
5.7 Transfer error
A slave that determines the current address to be within its range but locally detects a problem
with the transfer, such as an illegal access or a parity fail, m
...