ADRIAN@vax.oxford.ac.uk (03/01/89)
Latest NETBUS description
=========================
I have just mailed copies of the revised NETBUS document (draft 3.0).
If you would like a copy, and none arrives with a week or so, please
contact me.
I have since noticed various printing errors in some copies, mainly reversed
and disordered pages. Please ask if you need a better copy.
For those asking "What *is* NETBUS?", in brief it is a hardware standard for
building concurrent systems, especially those involving at least some
transputers. I have added a slightly expanded description below.
The main changes from the previous issue (draft 2.07) are the abolition of
NBC2, the reduction of NBC1 from 96 ways to 32, the introduction of the
link and power highways and a clock synchronization flag in the Global
command. There is now also the possibility of using a ZIF connector for the
system services.
Adrian Lawrence
----------------------------------------------------------------------------
ADRIAN @ UK.AC.OXFORD.VAX Microprocessor Unit, Oxford University,
13,Banbury Road, Oxford, Oxon. OX2 6NN. UK.
----------------------------------------------------------------------------
EARN/Bitnet: ADRIAN%UK.AC.OXFORD.VAX@AC.UK
{EARN node UKACRL}
ARPA: ADRIAN%VAX.OXFORD.AC.UK
ACSnet: adrian@vax.oxford.ac.uk@au.oz.munnari
[ean.ac.uk%nummari.cs.mu]
-----------------------------------------------------------------------------
Outline for new subscribers
===========================
NETBUS is an attempt to provide a standard for concurrent systems such as
exist in profusion for sequential systems. Examples of the latter are
Futurebus, VME, Multibus II, STD and your_own_favourite_bus.
As far as I am aware, there are no other such general standards.
To the best of my knowledge, and from memory, the nearest approaches are:
1) LINZ bus (Excellent when applicable.)
2) The 'industry standard' tree of up/down system/subsystem connections
for reset, analyse and error, with free trailing twisted pairs for links.
3) TRAM pin allocation.
4) Leon Heller's TRAM-like module pin out.
5) Various proprietry buses such as those used by Meiko and the Parsifal
project.
LINZ bus has less ambitious objectives than NETBUS.
The 'industry standard' tree which originated with INMOS evaluation boards
is only a very partial system, and has many limitations. It deals only
with three signals, forces a binary tree structure on the connections
preventing arbitrary resets and analysis, and specifies very little
about the hardware.
The TRAM specification is very local, and requires all error signals to
be 'OR'ed together.
In contrast, NETBUS attempts to specify sufficient details for complete
systems, and will be in the public domain.
It was presented at the 8th Occam User Group Technical Meeting at Sheffield,
1988. Some of the changes introduced in this new issue were as the result of
feedback from the Hardware SIG at that meeting.
NETBUS can be regarded under 4 main headings:
1) The system connector (NBC)
2) The link highway.
3) The (optional) power highway.
4) The system protocol (system services).
System connector (NBC)
======================
Netbus systems consist of one or more NETBUS *stacks*.
A netbus board carries a stacking connector which is usually a 32 way DIN
component, but may be a ZIF connector.
These stacked connectors form a 'backbone' for a stack, and carry the system
services. These include obvious signals such as a global reset, but more
importantly a general serial message passing system.
The system services are protocols applied to that channel; they are open-ended
and cater for arbitrary hardware. A NETBUS board may perhaps carry an SIMD
array, or a conventional sequential processor such as an i860 or an MC88000.
Link Highway
============
The link highway provides a standard way of connecting links using ground plane
ribbon cable. With active, passive or mixed routing boards, arbitrary networks
may be configured. Simple sytems without crosspoint switches can be routed
in seconds with routing plugs.
Power Highway (Optional)
========================
A specification for the location of power connectors and ordering of power
lines to facilitate power harnesses.
System Protocol
===============
The system services are open-ended messages specification. Messages from a
stack controller to a slave are generally commands or requests for a status
report. A basic slave reply is to identify itself. Apart from the global
command, the exact meaning of the other commands are a function of this
slave identity. So if a slave identifies itself as containing an AMD29000
processor, subsequent messages will be appropriate to that context.
Of course, there are standard recommendations for slaves containing
transputers and/or cross point switches.
Of course there are means for a board to attract the controller's attention:-
this might be set up on a particular slave to activate automatically on a
transputer error pin, or a memory parity error.
<---------------------------------------------->
Of course, all this has considerable relevance to some of the messages on this
mailing list about link switching......