ISO/IEC 10857:1994

Information technology - Microprocessor systems - Futurebus+ - Logical protocol specification

Specifies the logical layer for a set of signal lines that constitute a multiple segment bus architecture, and for the interfacing of modules connected to a bus segment. Intended to be used as a component within a profile to build systems with higher levels of compatibility.

Technologies de l'information — Systèmes à microprocesseurs — Futurebus+ — Spécification du protocol logique

General Information

• Status: Withdrawn
• Publication Date: 14-Dec-1994
• Withdrawal Date: 14-Dec-1994
• ICS: 35.160 - Microprocessor systems
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 15-Oct-2005
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 11812:2001 - Small craft - Watertight cockpits and quick-draining cockpits
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO/lEC
STANDARD 10857
ANWIEEEE
Std 896.1
First edition
1994-04-27
Information technology -
Microprocessor Systems - Futurebus+ -
Logical protocol specification
Technologies de I ’information -
SystGmes G microprocesseurs - Futurebus+ -
Sp&7ica tion du pro tocole logique
Reference number
ISO/IEC 10857: 1994(E)
ANWIEEE
Std 896.1, 1994 Edition
Abstract: This International Standard provides a set of tools with which to implement a Futurebus+
architecture with Performance and tost scalability over time, for multiple generations of Single- and
multiple-bus multiprocessor Systems. Although this specification is principally intended for 64-bit
address and data Operation, a fully compatible 32-bit subset is provided, along with compatible ex-
tensions to support 128- and 256.bit data highways. Allocation of bus bandwidth to competing mod-
ules is provided by either a fast centralized arbiter, or a fully distributed, one or two pass, parallel
contention arbiter. Bus allocation rules are provided to suit the needs of both real-time (priority
based) and fairness (equal opportunity access based) configurations. Transmission of data over the
multiplexed address/data highway is governed by one of two intercompatible transmission meth-
ods: a) a technology-independent, compelled-protocol, supporting broadcast, broadcall, and trans-
fer intervention (the minimum requirement for all Futurebus+ Systems), and b) a configurable
transfer-rate, source-synchronized protocol suppotting only block transfers and source-synchro-
nized broadcast for Systems requiring the highest possible Performance. Futurebus+ takes its name
from its goal of being capable of the highest possible transfer rate consistent with the technology
available at the time modules are designed, while ensuring compatibility with all modules designed
to this Standard both before and after. The plus sign (+) refers to the extensible nature of the spec-
ification, and the hooks provided to allow futther evolution to meet unanticipated needs of specific
application architectures. lt is intended that this International Standard be used as a key component
of an approved IEEE Futurebus+ Profile.
Keywords: bus architecture, Futurebus+, logical protocol, multiprocessor Systems
Engineers, Inc.
The Institute of Electrical and Electronics
7-2394, USA
345 East 47th Street, New York, NY 1001
Copyright 0 1994 by the Institute of Electrical and Electronics Engineers, Inc.
Printed in the United States of America.
All rights reserved. Published 1994.
ISBN 1
-55937-373-3
No part of this publication may be reproduced in any ferm, in an electronie re trieval System OI- otherwise, without the Prior
written Permission of the publisher.
April 27, 1994 SH16816
ISO/IEC 10857 : 1994
[ANSMEEE Std 896.1,1994 Edition]
(Incorporates ANSVIEEE Std 896.14991 and
IEEE Std 896.1a-1993)
Information technology-
Microprocessor systems-
- Logical protocol
Futurebus+
specification
Sponsor
Bus Architecture Standards Committee
of the
IEEE Computer Society
Adopted as an International Standard by the
International Organization for Standardization
and by the
International Electrotechnical Commission
- American National Standard
Published by
The Institute of Electrical and Electronics Engineers, Inc.

Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized System for worldwide standard-
ization. National bodies that are members of ISO or IEC participate in the develop-
ment of International Standards through technical committees 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 nongovernmental, 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 JTC 1. Draft International Standards adopted by the joint tech-
nical committee are circulated to national bodies for voting. Publication as an Inter-
national Standard requires approval by at least 75% of the national bodies casting a
vote.
In 1993, ANSUIEEE Std 896.1-1991, together with IEEE Std 896.1a-1993, Errata,
Corrections and Clarijkations, was adopted by ISOIIEC JTC 1, as draft International
Standard ISO/IEC DIS 10857. This edition incorporates IEEE Std 896.1a-1993 into
the text of ANSUIEEE Std 896.1-1991.
International Organization for Standardization./International Electrotechnical Commission
l CH-1211 Geneve 20 l Switzerland
Case postale 56
IEEE Standards documents are developed within the Technical Committees of the
IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Board. Members of the committees serve voluntarily and without compensation.
They are not necessarily members of the Institute. The Standards developed within
IEEE represent a consensus of the broad expertise on the subject within the Institute
as well as those activities outside of IEEE that have expressed an interest in partici-
pating in the development of the Standard.
Use of an IEEE Standard is wholly voluntary. The existente of an IEEE Standard
does not imply that there are no other ways to produce, test, measure, purchase, mar-
ket, or provide other goods and Services related to the scope of the IEEE Standard.
Furthermore, the viewpoint expressed at the time a Standard is approved and issued is
subject to Change brought about through developments in the state of the art and
comments received from users of the Standard. Every IEEE Standard is subjected to
review at least every five years for revision or reaffirmation. When a document is
more than five years old and has not been reaffirmed, it is reasonable to conclude that
its contents, although still of some value, do not wholly reflect the present state of the
art. Users are cautioned to check to determine that they have the latest edition of any
IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested Party,
regardless of membership affiliation with IEEE. Suggestions for changes in docu-
ments should be in the form of a proposed Change of text, together with appropriate
supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions
of Standards as they relate to specific applications. When the need for interpretations
is brought to the attention of IEEE, the Institute will initiate action to prepare appro-
priate responses. Since IEEE Standards represent a consensus of all concerned inter-
ests, it is important to ensure that any interpretation has also received the concurrence
of a balance of interests. For this reason IEEE and the members of its technical com-
mittees are not able to provide an instant response to interpretation requests except in
those cases where the matter has previously received formal consideration.
Comments on Standards and requests for interpretations should be addressed to:
Secretary, IEEE Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855- 133 1
USA
IEEE Standards documents may involve the use of patented technology. Their
I I
approval by the Institute of Electrical and Electronics Engineers, Inc. does not mean
that using such technology for the purpose of conforming to such Standards is autho-
rized by the patent owner. It is the Obligation of the user of such technology to obtain
all necessary permissions.
Introduction
(This introduction is not a normative part of ISO/IEC 10857 : 1994, but is included for information only.)
The following is a list of those who were members of the IEEE Futurebus+ Working Group at the time
ANSUIEEE Std 896.1-1991 was approved:
Paul L. Borrill, Chair
Barbara Aichinger Joseph George Clarence Peckham
Ray Alderman Larry Gilbert Shlomo Pri-Tal
Hamid Amirazzi Jim Goodman Surinder Rai
Duane Anderson Robert Greiner Mike Raynham
Harrison Beasley David Gustavson Jack Regula
Janos Biri Emil Hahn Bill Ruszczyk
Martin Blake David Hartig Ali Sarabi
Richard Boberg David Hawley James Scaminaci
Lym Hevle Dennis Schmitz
Andy Bonafini
David Brash Billy Ho Craig Scott
Mike Humphrey Don Senzig
David Brearly
David Brewer John Hyde Lui Sha
Marc Briel Ed Jacques Dan Sieworek
Charles Brill David James Mike Snodgrass
Jim Brown Greg Jewell Michael Sweeney
Mark Bunker Anatol Kaganovich Fahad Tabrizzi
John Campbell Hans Karlsson Matthew Taub
Jay Cantrell David Kemp Mike Teener
S tephen Cecil Ralph Lachenmaier Judy Teske
Kirn Clohessy Subasis Laha Morton Thayer
Paul Cook Cees Lambretche John Theus
Dante Del-Corso Dick Lawrence Mike Thompson
Ernie Cracker Mike Lazar Nigel Topham
Jon Crowell Jim Leahy Mary Vernon
Steve Diess Kent Leung Harvey Walthersdorf
Paul Dixon Joel Liblove Eike Waltz
Thanos Mentzelonoulos Randy Weber
Ian Dobson
Klaus Müller Mike Wenzel
Emer Dooley
Chris Nichols Mike Wiles
Sam Duncan
Jim Nicholson Mark Williams
Chris Eck
Bill Evertz Ronald Niederhagen John Wise
Mira Pauker David Wright
Wayne Fischer
Chet Pawlowski Dale Younge
Mike Foster
iv
The following persons were on the balloting committee of ANSVIEEE Std 896.1-1991:
William B. Adams William Groseclose
Mira Pauker
Sid Ahuja David B. Gustavson
Donald Pavlovich
Mohammad Al-Malki Thomas W. Harkaway James M. Pexa
John Allen David Hawley
Arthur V. Pohm
Richard P Ames Herbert Hecht
Bruno R. Preiss
Duane L. Anderson Rick Henderson Shlomo Pri-tal
Jack Arabian Frank Horn
Greg Prom
R. V Balakrishnan Scott Hopkinson
Richard Rawson
David M. Barnum Zoltan R. Hunor Michael Raynham
Harrison A. Beasley Peter J. Ilieve
Ed Rodriquez
Janos Biri Bob Jacobsen
Tom Sakoda
Kyle M. Black Edgar Jacques
Debabrata Sarma
John Black David V. James
Carl Schmiedekamp
William P Blase Kenneth Jansen
Norman Schneidewind
Jack L. Blevins Jack R. Johnson
Eugene C. Sehramm
Anatol Kaganovich
David Brearley David Seraphin
Charles Brill Hans Karlsson
Philip Shutt
Lyle Burnett David Keeney
Michael R. Sitzer
Willis K. King
Luis-Felipe Cabrera Michael Smolin
Hubert Kirrman
Clyde Camp Benjamin Stoppe, Jr.
Donald Chi Ernst H. Kristiansen
Paul Sweazey
Kirn Clohessy Thomas M. Kurihara Daniel Tabak
Tuvia Lamdan
David Cohen Darius Tanksalvala
Glen Langdon
Paul D. Cook Daniel Tarrant
Robert Crowder Thomas Leonard Michael Teener
Jonathan C. Crowell Per Lindman Michael G. Thompson
William Lindow
Philip D ’Angelo Carsten Thomsen
Ana Maria Dealvare Rollins Linser Joseph P. Trainor
Stephen Deiss Wayne M. Loucks Robert Tripi
Dante Del Corso Anthony G. Lubowe Joseph G. Tront
Su Dongzhuang Andy J. Luque Robert J. Voight
Mike Dorsett Roy Maurer Eike Waltz
Samuel H. Duncan William McDonald David R. Weller
Sourav Dutta Darre11 B. McIndoe Walter L. Whipple
Jeffrey S. Ebeling Bruce Millard Thomas Wicklund
William P Evertz Lee Minsuk Hans A. Wiggers
Harry D. Feit James M. Moidel Mark Williams
Wayne Fischer James Moloney John S. Willy
Gordon Forte J.D. Nicoud Andrew Wilson
Andrew Fraser Tadahiko Nishimukai John Wise
Joseph D. George Duane J. Northcutt Joel Witt
Andy Glew Gregory C. Novak David L. Wright
Patrick Gonia Michael Orlovsky Qiufeng Wu
Willard Graves Jame R. Otto Oren Yuen
Dick Palmer
When the IEEE Standards Board approved ANSILIEEE Std 896.1-1991 on September 26, 1991, it had the
following membership:
Marco Migliaro, Chair Donald C. Loughry, Vice Chair
Andrew G. Salem, Secretary
Dennis Bodson Thomas L. Hannan John E. May, Jr.
Paul L. Borrill Donald N. Heirman Lawrence V. McCall
Clyde Camp Kenneth D. Hendrix Donald T. Michael*
James M. Daly John W. Horch Stig L. Nilsson
Donald C. Fleckenstein Ben C. Johnson John L. Rankine
Jay Forster* Ivor N. Knight Ronald H. Reimer
David F. Franklin Joseph L. Koepfinger* Gary S. Robinson
Ingrid Fromm Irving Kolodny Terrance R. Whittemore
Michael A. Lawler
*Member Emeritus
The following is a list of those who were members of the IEEE Futurebus+ Working Group at the time
IEEE Std 896.1a-1993 was approved:
Samuel H. Duncan, Chair
Harrison Beasley Joseph D. George Thanos Mentzelopoulos
Kirn Burris Claes-Goran Gustavsson Michael Munroe
Jay Cantrell Emil Hahn Robert Schetlick
Steve Cecil Peter Izzo Gene Sehramm
Steve DiCamillo Ed Jacques Richard Spratt
R. Paul Dixon Greg Jewell John Theus
Ian Dobson Jim Leahy Dean Van De Walker
Jeff Lear Robert Widlicka
Karl Franklin
The following persons were on the balloting committee of IEEE Std 896.1a-1993:
Wilhelm P Evertz Steve Quinton
Edward W. Aichinger
Wayne Fischer Michael L. Roby
Ray S. Alderman
Gordon Forte Frederick E. Sauer
Richard P. Ames
Paul Fulton Robert Schetlick
Keith D. Anthony
Juli0 Gonzalez-Sanz Don Denzig
Harrison A. Beasley
John Griffith Patricia Smith
John Black
Michael C. Hayward Joanne Spiller
Charles Brill
Edgar Jacques Richard Spratt
Andrew J. Brough
Ralph Lachenmaier Michael G. Thompson
Clyde Camp
Lak Ming Lam Joseph P. Trainor
Stephen J. Cecil
Michael Lambrou Robert Tripi
Andy Cheese
Yoshiaki Wakimura
Kirn Clohessy Karl E. McClure
Thanos Mentzelopoulos Eike Waltz
Steven Cobb
Bruce Millard Dave Wiekliff
David Cohen
Robert Widlicka
Steven R. Corbesero Brian D. Morrison
Joel Witt
Ian Dobson Klaus Dieter Mueller
Jean-Jacques Dumont Elwood Parsons Mark Woodbury
Samuel Duncan Chandresh J. Pate1 David L. Wright
Yoshio Yamaguchi
Christopher Eck
When the IEEE Standards Board approved IEEE Std 896.1a-1993 on September 15, 1993, it had the follow-
ing membership:
Wallace S. Read, Chair Donald C. Loughry, Vice Chair
Andrew G. Salem, Secretary
Jim Isaak Don T. Michael*
Gilles A. Baril
Ben C. Johnson Marco W. Migliaro
Jose A. Berrios de la Paz
Walter J. Karplus L. John Rankine
Clyde R. Camp
Lorraine C. Kevra Arthur K. Reilly
Donald C. Fleckenstein
E. G. “Al” Kiener Ronald H. Reimer
Jay Forster*
Ivor N. Knight Gary S. Robinson
David F. Franklin
Joseph L. Koepfinger* Leonard L. Tripp
Ramiro Garcia
D. N. “Jim” Logothetis Donald W. Zipse
Donald N. Heirman
*Member Emeritus
Also included are the following nonvoting IEEE Standards Board liaisons:
Satish K. Aggarwal
James Beall
Richard B. Engelman
David E. Soffrin
Stanley 1. Warshaw
IEEE Std 896.1-1991 was approved by the American National Standards Institute on April 28, 1992.

Contents
PAGE
CLAUSE
..............................................................................................................................................
1. Overview
1.1 Scope .
‘3
...................................................................................................................
1.2 Normative references
......................................................................................................................
2. Definitions and structure
2.1 Special word usage .
....................................................................................................................................
2.2 Definitions
2.3 Signal conventions .
2.4 Document structure .
2.5 Futurebus+ logo .
2.6 Bus line description .
Attribute Cross reference .
2.7
Implementation mnemonics .
2.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Bus signaling environment
.................................................................................................................................
3.1 Description
..............................................................................................................................
3.2 Specification
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Centralized arbitration
.................................................................................................................................
4.1 Description
..............................................................................................................................
4.2 Specification
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Distributed arbitration and arbitrated messages
5.1 Description .
5.2 Specification .
6. Parallel protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Description .
6.2 Specification .
Buskystem management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Description .
7.2 Specification .
Cache coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Description .
8.2 Specification .
vii
PAGE
CLAUSE
Message passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.
9.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ANNEX
Annex A Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
Vlll
Information technology-Microprocessor
Systems-Futurebus+ - Logical protocol
specification
1 n Overview
1.1 Scope
This International Standard specifies the logical (relative timing and behavioral protocol) layer for a set of
Signal lines that constitute a multiple Segment bus architecture, and for the interfacing of modules connected
to a bus Segment. This International Standard is intended to be used as a component within a Profile (a col-
lection of related specifications that must be used together by a product in Order to Claim conformance to a
Standard) to build Systems with higher levels of compatibility.
Futurebus+ provides the means for the transfer of binary information between boards over one or more logi-
cal buses. Boards may contain any combination of one or more processors and local resources such as Cache,
memory, peripheral and communication controllers, etc. Figure 1 Shows a block diagram of a typical appli-
cation of Futurebus+.
Protocols are specified for the allocation of bus time to modules that need to conduct transactions with other
modules over the bus. However, this International Standard does not mandate the priority rules for modules
to use when competing for use of the bus. These are considered the privilege and responsibility of the System
integrator. The International Standard includes a complete set of signaling rules to be followed by all mod-
ules in both the distributed and centralized control acquisition processes leading to bus mastership (clauses 4
and 5). The International Standard also gives a comprehensive set of signaling rules for all modules partici-
pating in a bus transaction (clause 6).
Most of the transfer protocols in this International Standard are compeiled; that is, they are governed by a
pure Cause-and-effect relationship. This is what gives this International Standard its technology-independent
nature. The compelled signaling provides a designer with a logical simplicity for what takes place in the pro-
tocols. As a result, there will be maximum compatibility between products designed to this International
Standard throughout its operational lifetime.
With any bus, there is the dilemma of how much the Standard should specify. There must be a balance
between ensuring that all boards designed by a variety of manufacturers tan operate together, while not
restricting the users of the bus to any preconceived System design. Although the scope of this International
Standard has been restricted to exclude many of the System requirements associated with bus-based com-
Puter Systems, these are being addressed in companion Standards.
The common control and register interface to this series of Standards for the Futurebus+, and to other pro-
posed IEEE Standards (in particular, IEEE Std 1596-1992 [B12] ‘, IEEE P1014.1 [B2], and IEEE
in brackets correspond to those of the bibliography in annex A.
’ The numbers
ISO/IEC 10857 : 1994 (E)
[ANSI/1 EEE Std 896.1, 1994 Edition] MICROPROCESSOR SYSTEMS-
Pl394 [Bll]), is embodied in the unified CSR architecture Standard, IEEE Std 1212-1991 [B7], along with a
unified DMA architecture for moving data around a System without the need to pass through a processor
(IEEE Std 1212.1-1993 [B8]).
This set of protocols has been designed to be as close to technology-independent as possible while maintain-
ing a very high level of efficiency and Performance. The bus Signals may be implemented using any technol-
ogy (TTL, Backplane Transceiver Logic, ECL, CMOS, GaAs, etc.) so long as the Futurebus+ signaling
conditions are met (incident wave switching on the transmission-line signaling environment, along with the
constraints on skew, crosstalk, and transmission reliability). However, in the interest of maximum compati-
bility between product families, implernentations are expected to be associated with one or more IEEE
Futurebus+ profiles, which specify the physical layer and set of transactions to suit a particular family of
applications.
Processor Processor Processor Processor Processor Processor
I I I I I I I
I J 1 I 1
I I I I I I
I I I I I I
/ /
Cache Cache Cache Cache Cache Cache Cache Cache Cache Cache Cache Cache
Cache Cache
Bridge Bridge ’
Futurebus+
Cable
Processor
1 Futurebus+
1 Futurebus+ 1
Memory
I
I/O Processor Frame Buffer
c
I
SCSI 2 / IPI
I
HPPI
LAN
Disk Farm
Connection
to Supercomputer
Figure l-Interfaces in a family of typical Futurebus+ Systems

ISO/IEC 10857 : 1994 (E)
FUTUREBUS+ - LOGICAL PROTOCOL SPECIFICATION [ANSVIEEE Std 896.1, 1994 Edition]
1.2 Normative references
The following Standards contain provisions which, through references in this text, constitute provisions of
this International Standard. At the time of publication, the editions indicated were valid. All Standards are
subject to revision, and Parties to agreements based on this International Standard are encouraged to investi-
gate the possibility of applying the most recent edition of the Standards listed below. Members of IEC and
ISO maintain registers of currently valid International Standards.
IEEE Std 896.2- 199 1, IEEE Standard for Futurebus+ - Physical Layer and Profile Specifications.2
IEEE Std 896.3-1993, IEEE Recommended Practices for Futurebus+.
2 IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 133 1, Piscataway,
NJ 088551331, USA.
3As this Standard goes to press, IEEE Std 896.3-1993 is not yet published. It is, however, available in manuscript form from IEEE.
Anticipated publication date is May 1994.

ISO/IEC 10857 : 1994 (E)
[ANSVIEEE Std 896.1, 1994 Edition] MICROPROCESSOR SYSTEMS-
2. Definitions and structure
2.1 Special word usage
2.1.1 may: A keyword indicating flexibility of choice with no implied preference.
2.1.2 shall: A keyword indicating a mandatory requirement. Designers must implement all such mandatory
requirements to ensure interoperability of ISO/IEC 10857 conformant products and Claim conformance to
this International Standard.
2.1.3 should: A keyword indicating flexibility of choice with a strongly preferred implementation. The
Phrase it is recommended is used interchangeably with the keyword should.
2.2 Definitions
2.2.1 activate: a) The action of applying a set of Signals to a of bus lines. b) The state of a group of
fw UP
bus lines when they carry Signals.
2.2.2 address-only transaction: A bus transaction that does not i nclude a data Phase. The only in formation
transferred is contained within the connection Phase and, in some cases, the disconnection Phase.
2.2.3 arbitration: The process of selecting the next bus master.
2.2.4 broadcast on the arbitrated message bus lines to all modules on the
arbitrated message: A number
bus.
2.2.5 assert: a) The action of applying a logic one Signal to a bus line. b) The state of a bus line when the
Signal it carries represents a logic one.
indicates that the logic one state of the
2.2.6 * (asterisk): When appended to a signal ’s name, the suffix “*”
Signal is such that it will override the logic zero state applied by any other module on that line.
2.2.7 beat: An event that begins with the transition on a synchronization line by the master, followed by the
release of an acknowledge line by one or more slaves. Command and data information may be transferred
from the master to one or more slaves in the first half of the beat. During the second half of the beat the
slaves may transfer capability, Status, and data information back to the master.
2.2.8 block copy: A block copy Operation is characterized by a long series of read or write transactions to
sequential memory locations.
2.2.9 bus bridge: A bus bridge is an interconnect between two or more buses that provides Signal and proto-
col translation from one bus to another. The buses may adhere to different bus Standards for mechanical,
electrical, and logical Operation (such as a bus bridge from Futurebus+ to VMEbus or to MULTIBUS 11).
2.2.10 bus line: The medium for the transmission of Signals. Since Futurebus+ requires drivers with wire-
OR capability, a bus line may be driven by several modules simultaneously. Therefore, the Signal carried by
the bus line is the combination of Signals applied to that line from each module.
2.2.11 bus tenure: The duration of a master ’s control of the bus; i.e., the time during which a module has the
right to initiate and execute bus transactions.
ISO/IEC 10857 : 1994 (E)
LOGICAL PROTOCOL SPECIFICATION
FUTUREBUS+ - [ANSMEEE Std 896.1, 1994 Edition]
2.2.12 bus transaction: An event initiated with a connection Phase and terminated with a disconnection
Phase. Data may or may not be transferred during a bus transaction. See.- transaction.
2.2.13 busy: If a Slave is unable to accept a bus transaction from a master, it may issue a busy Status to the
master of the transaction. The master must relinquish the bus and may reacquire the bus and retry the trans-
action after a suitable time interval.
2.2.14 byte: A set of eight adjacent binary digits.
2.2.15 byte lane: A data path formed by eight data lines and one parity line and used to carry a Single byte
between System modules.
2.2.16 Cache coherence: A System of caches is said to be coherent with respect to a Cache line if each Cache
and main memory in the coherence domain observes all modifications of that same Cache line. A modifica-
tion is said to be observed by a Cache when any subsequent read would return the newly written value.
2.2.17 Cache memory: A buffer memory inserted between one or more processors and the bus, used to hold
currently active copies of blocks from main memory. Cache memories exploit spatial locality by what is
brought into a Cache. Temporal locality is exploited by the strategy employed for determining what is
removed from the Cache.
2.2.18 coherence domain: A region in a multiple-Cache System, inside of which, Cache consistency mea-
sures are enforced. In a System that contains bus bridges, a coherence domain may or may not be extensible
beyond the local bus through a bus bridge to remote buses.
2.2.19 coherence line: A data block for which Cache consistency attributes are maintained.
2.2.20 compelled data transfer protocol: A technology-independent transfer mechanism in which the
Slave is compelled to provide a response before the master proceeds to the next transfer.
2.2.21 competitor: A module actively participating in the current control acquisition cycle of the arbitration
process.
transaction in which both the request and respon se are performed within
2.2.22 connected transaction: A
the same bus transaction.
2.2.23 connection Phase: A beat that begins with the assertion of the address synchronization line followed
by the release of an address acknowledge line. It is used to broadcast the address and command information.
Modules determine whether they wish to take part in the transaction based on this information.
2.2.24 control acquisition: The total of all bus activity associated with acquiring exclusive control of
the bus.
2.2.25 copyback Cache: A Cache memory scheme with the attribute that data written from the processor is
normally written to the Cache rather than the main memory. Modified data in the Cache is written to the main
memory to avoid loss of the data when a Cache line flush or replacement occurs.
2.2.26 CSR: Control and Status register.
2.2.27 CSRA: Control and Status register architecture. (See IEEE Std 1212- 1991 [B7].)
2.2.28 data Phase: A period within a transaction used to transfer data.

ISO/IEC 10857 : 1994 (E)
[ANSVIEEE Std 896.1, 1994 Edition] MICROPROCESSOR SYSTEMS-
2.2.29 deadlock: A state that occurs when modules are awaiting actions that tan only be performed by those
waiting, and those waiting cannot perform the actions.
2.2.30 disconnection Phase: A period within a transaction used to return the bus Signals to their quiescent
state. In addition, this Phase might be used to transfer additional information required to perform or abort the
requested Operation.
2.2.31 doublet: A set of two adjacent bytes.
2.2.32 entrant: A live inserted module in the process of aligning itself with the arbitration protocol.
2.2.33 forward progress: A state in which a module is not blocked from performing the tasks necessary to
achieve its goal. Forward progress is guaranteed only in the absence of deadlock or starvation.
2.2.34 geographical address: A unique identifier assigned to each physical module slot on the bus and
assumed by any module connected to that slot.
2.2.35 global identification: A unique identifier assigned to each physical module slot in a System. This
identifier would typically include both a bus identifier and a slot identifier. IEEE Std 1212-1991 [B7] speci-
fies the format for such a global identifier.
2.2.36 intervening Slave: The participating Slave that, although not the repository of last resort of the
requested data, finds it necessary to prevent the repository of last resort from providing the requested data.
Having done so, the intervening Slave provides the data instead.
some modules acquire and release resources in such a way
2.2.37 livelock: A metastable Situation in which
that none of them makes forward progress.
2.2.38 locking: A facility whereby a module is requested to guarantee exclusive access to addressed data,
blocking other modules from accessing that data. This allows indivisible operations to be performed on
addressed resources.
2.2.39 A module that has acquired control of the bus through the control acquisi tion procedure.
master:
2.2.40 master elect: A module that has won the most recent arbitration competition.
2.2.41 module: A collection of circuitry designed to perform specific functions that include an interface to
Futurebus+.
2.2.42 monarch processor: The processor selected to manage the. configuration and initialization of all
modules on one logical bus. Also: monarch. An emperor processor is the monarch processor selected to
direct the configuration and initialization of an entire System with multiple interconnected logical buses.
2.2.43 octlet: A set of eight adjacent bytes.
2.2.44 packet data transfer protocol: A very fast but technology-dependent noncompelled transfer mecha-
nism that uses a compelled protocol over the entire packet to provide flow control.
2.2.45 parallel contention arbitration: A process whereby modules assert their unique arbitration number
on a parallel bus and release Signals according to an algorithm such that after a period of time the winner ’s
number appears on the bus.
2.2.46 participating Slave: A Slave involved in a transaction as a selected Slave, an intervening Slave, a
broadcast Slave, or a Slave involved in multiple packet mode.

ISO/IEC 10857 : 1994 (E)
LOGICAL PROTOCOL SPECIFICATION
FUTUREBUS+ - [ANSVIEEE Std 896.1, 1994 Edition]
2.2.47 preemption: The release of the bus by the current bus master due to the request of another module.
NOTE-In some Systems, any module may Cause preemption; in others, only a module with a higher priority request
may Cause preemption.
2.2.48 quadlet: A set of four adjacent bytes.
2.2.49 release: a) The action of applying a logic zero Signal to a bus line. b) The state of a bus line when the
Signal it carries represents a logic Zero.
location
2.2.50 repository of last resort: In a hierarchical memory (or Cache-based) environment, a storage
that “owns” the only, or last remaining, copy of sharable data.
NOTE-It may be a unique Source, an ultimate destination, or simply a “Safe” repository of data that may not be invali-
dated, unless action is taken to preserve a copy of that data at some higher level in the memory (or Cache) hierarchy. In a
Cache-only Futurebus+ System (e.g., one where even the main DRAM storage is also designed as a hardware Cache), the
repository of last resort begins life as the binding of an address to a physical location in one of the caches, along with the
creation of the data by initialization, a copy from some higher level in the memory hierarchy, or by its arrival from some
I/O device. This data may migrate around the System, and be owned by different caches at different times, provided no
less than one copy of that data is maintained somewhere. A repository of last resort may end its life by an explicit
instruction to “destroy” the data by rnigration to a higher level in the memory (or Cache hierarchy), or by transfer of
ownership through some I/O device to another System, storage device, or display.
2.2.51 request: A command, generated by a requester, to initiate an action on a responder. For a processor-
to-memory read transaction, for example, the request transfers the memory address and command from the
processor to memory. In the case of a Split transaction, the request would be a separate bus transaction. In
the case of a connected transaction, the request would be the connection Phase of a bus transaction.
2.2.52 requester: A module that initiates a transaction by sending a request (containing address, command,
and sometimes data).
2.2.53 responder: A module that completes a transaction sending a response (containing the completion
bY
Status and sometimes data).
2.2.54 response: A reply, generated by a responder, to complete a transaction initiated by a requester. For a
processor-to-memory read transaction, for example, the response returns the data and Status from the mem-
ory to the processor. In the case of a Split transaction, the response would be a separate bus transaction. In
the case of a connected transaction, the response would be the data and disconnection phases of a bus
transaction.
2.2.55 round robin: A bus allocation rule where, after a module acquires and uses the bus, it will not be
granted use of the bus again until all other modules currently requesting the bus at the same priority level
have had control of the bus.
its
2.2.56 selected Slave: A Slave is selected during the connection Phase by the master when it recognizes
address on the bus lines.
2.2.57 shared memory: The address space in the System accessible to all caching modules.
2.2.58 Signal names: Where a group of bus lines are represented by the same letters, the lines within the
group are numbered; e.g., ADO*, ADl*, AD2*, etc. In Order to represent a group of lines or Signals in more
convenient form, notation such as AD[63.0]* is used. Also, in these examples, the notation AD[ ]* is used
to refer to all of the lines within the group.
2.2.59 skew: The differente between the propagation delays of two or more Signals on any bus line.

ISO/IEC 10857 : 1994 (E)
[ANSVIEEE Std 896.1, 1994 Edition] MICROPROCESSOR SYSTEMS-
2.2.60 Slave: A module that tan be addressed and is capable of participating in bus transactions.
module when it takes a
2.2.61 snarf: The action taken by a a of data passi ng by on the bus, even
COPY
though it did not request it.
2.2.62 snoop: The action taken by a module on a transaction when it is not the master that originated the
transaction or the repository of last resort for the data, but it still monitors the transaction. Cache memories
snoop transactions to maintain coherence.
2.2.63 spatial locality: The tendency for a program to reference closely related clusters of memory
addresses over short time intervals.
2.2.64 Split transaction: A System transaction in which the request is transmitted in one bus transaction and
the response is transmitted in a separate subsequent bus transaction.
starvation: A System condition that occurs when one or more module( s) perform(s ) no useful work
2.2.65
ack of access to the bu .s or other stem resources.
for an indefinite period of time due to 1
SY
2.2.66 strong sequential consistency: A state exhibited by a System when each participating Cache in the
System observes all modifications to lines within itself in the Same Order as all other participating caches in
the System. See also: weak sequential consistency.
NOTE-Futurebus+ allows modules to issue transactions that dynamically choose between following a weakly consis-
tent behavior model (which implies greater concurrency and hence higher Performance) and strongly consistent behav-
ior models (which may be necessary to ensure correct Operation of an algorithm written by a programmer not cognizant
of the concurrency possible in different Parts of a System).
2.2.67 System transaction: A complete Operation, such as a memory read or write, as viewed from the initi-
ating unit. A System transaction tan be translated into one or more bus transactions by the Futurebus+ inter-
face to complete the Operation.
2.2.68 temporal locality: The tendency for a program to reference the same memory locations over short
time intervals.
2.2.69 transaction: An event initiated with a connection Phase and terminated with a disconnection Phase.
Data may or may not be transferred during a transaction. Often used instead of the more precise Phrase “bus
transaction” for the sake of brevity. See: bus transaction; System transaction.
2.2.70 unselected Slave: A Slave that does not recognize its address on the bus lines during the connection
Phase of a bus transaction.
2.2.71 weak sequential consistency: A state exhibited by a System when references to global synchronizing
variables exhibit strong sequential consistency, and if no reference to a synchronizing variable is issued by
any processor until all previous modifications to global data have been observed by all caches, and if no ref-
erence to global data is issued by any processor until all previous modifications to synchronizing variables
have been observed by all caches. See also: strong sequential consistency.
2.3 Signal conventions
Figure 2 Shows an example of the Signal conventions used in this International Standard. The example is
shown with open collector technology (although this International Standard is independent of this logic fam-
ily). The Signal that a specific module applies to the input of its driver is designated by a lowercase label;
e.g., ai. The Signal that a specific module applies to a bus line is designated by a lowercase label with an
ISO/IEC 10857 : 1994 (E)
FUTUREBUS+ - LOGICAL PROTOCOL SPECIFICATION [ANSVIEEE Std 896.1, 1994 Edition]
asterisk; e.g., ai *. The Signal that appears on a bus line as the result of the combined Signals applied to it by
all modules is designated by an uppercase label with an asterisk; e.g., AI*.
When appended to a Signal name, the suffix “f’ (filtered) refers to the bus line Signal after it has passed
through a receiver and a wire-OR glitch filter (integrator). For example, AIf refers to the Signal on the AI*
line, after it has passed through an inverting receiver to become AI and a wire-OR glitch filter to
become AIf.
In a label with an appended asterisk (e.g., WR*), a “0” would mean the Signal was released. A “1” would
mean an asserted Signal.
ai
Alf
Integrator -
,
Al
Figure 2-Signal conventions
2.4 Document st
...