a) to allow communication between devices on the VMEbus without disturbing the internal activities of other devices interfaced to the VMEbus;

b) to specify the electrical and mechanical system characteristics required to design devices that will reliably and unambiguously communicate with other devices interfaced to the VMEbus;

c) to specify protocols that precisely define the interaction between the VMEbus and devices interfaced to it;

d) to provide terminology and definitions that describe the system protocol;

e) to allow a broad range of design latitude so that the designer can optimize cost and/or performance without affecting system compatibility;

f) to provide a system where performance is primarily device limited, rather than system interface limited.

Every SBus Card shall implement appropriate self-descriptive and initialization firmware using FCode, which is similar to the Forth programming language. The details of this firmware standard are beyond the scope of this standard.1) In addition, other software interfaces may be used for communication with SBus Cards.

SBus is intended to provide a high performance I/O bus interface with a small mechanical form factor. The small size, high levels of integration, and low power usage of SBus Cards enable them to be used in laptop computers, compact desktop computers, and other applications requiring similar characteristics. SBus Cards are mounted in a plane parallel to the motherboard of the computer system, allowing the computer system to have a low profile. SBus is not designed as a general purpose backplane bus.

SBus allows transfers to be in units of 8, 16, 32, or 64 bits. Burst transfers are allowed to further improve performance. SBus allows a number of SBus Master devices to arbitrate for access to the bus. The chosen SBus Master provides a 32-bit virtual address which the SBus Controller maps to the selection of the proper SBus Slave and the development of the 28-bit physical address for that Slave. The selected SBus Slave then performs the data transfers requested by the SBus Master. Simple SBus Cards may be designed to operate solely as Slaves on the SBus.

1.2 Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this International Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of IEC and ISO maintain registers of currently valid International Standards.

IEEE Std 1275:1994, IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices2)

1) A firmware interface standard is under consideration.

2) IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA (standards.ieee.org/).

The contents given in this specifications are as follows:

a) System bus interface signal provisions;

b) Bus operations and transfer protocol for each bus operation;

c) Copyback cache coherency control for maintaining consistency between a shared memory and a cache memory of each processor in a multiprocessor system;

d) Fault detection function using parity check and duplex configuration for control signals.

The object of this International Standard is to enable high-performance, scalable, modular, parallel systems to be constructed with low system integration cost; to support communications systems fabric; to provide a transparent implementation of a range of high-level protocols (communications, e.g. ATM, message passing, shared memory transactions, etc.), and to support links between heterogeneous systems.