VMEbus is a computer bus standard, originally developed for the Motorola
68000 line of CPUs, but later widely used for many applications and
standardized by the IEC as ANSI/IEEE 1014-1987. It is physically based on
Eurocard sizes, mechanicals and connectors, but uses its own signalling
system, which Eurocard does not define. It was first developed in 1981 and
continues to see widespread use today. History
In 1979, during development of the Motorola 68000 CPU, one of their
engineers, Jack Kister, decided to set about creating a standardized bus system
for 68000-based systems. The Motorola team brainstormed for days to select the
name VERSAbus. VERSAbus cards were large, 14.5" by 9.25", and used edge
connectors. Only a few products adopted it, including the IBM System 9000
instrument controller and the Automatix robot and machine vision systems.
Kister was later joined by John Black, who refined the specifications and
created the VERSAmodule product concept. A young engineer working for Black,
Julie Keahey designed the first VERSAmodule card, the VERSAbus Adaptor
Module, used to run existing cards on the new VERSAbus. Sven Rau and Max
Loesel of Motorola-Europe added a mechanical specification to the system,
basing it on the Eurocard standard that was then late in the standardization
process. The result was first known as VERSAbus-E but was later renamed to
VMEbus, for VERSAmodule Eurocard bus. At this point, a number of other
companies involved in the 68000's ecosystem agreed to use the standard,
including Signetics, Philips, Thomson, and Mostek. Soon it was officially
standardized by the IEC as the IEC 821 VMEbus and by ANSI and IEEE as ANSI/IEEE
1014-1987. The original standard was a 16-bit bus,
designed to fit within the existing Eurocard DIN connectors. However, there
have been several updates to the system to allow wider bus widths. The current
VME64 includes a full 64-bit bus in 6U-sized cards and 32-bit in 3U cards.
The VME64 protocol has a typical performance of 40 MB/s. Other associated
standards have added hot-swapping in VME64x, smaller 'IP' cards that plug
into a single VMEbus card, and various interconnect standards for linking VME
systems together. In the late 1990s, synchronous protocols
proved to be favourable. The research project was called VME320. The VITA
Standards Organization called for a new standard for unmodified VME32/64
backplanes. The new 2eSST protocol was approved in ANSI/VITA 1.5 in 1999.
Over the years, many extensions have been added to the VME interface,
providing 'sideband' channels of communication in parallel to VME itself.
Some examples are IP Module, RACEway Interlink, SCSA, Gigabit Ethernet on
VME64x Backplanes, PCI Express, RapidIO, StarFabric and InfiniBand.
VMEbus was also used to develop closely related standards, VXIbus and VPX. The
VMEbus had a strong influence on many later computer buses such as STEbus.
Some people argue that VMEbus will be replaced by CompactPCI as the dominant
OEM bus. Others argue that VME systems will continue to be the dominant OEM bus
for the foreseeable future. = VME Early Years =
The architectural concepts of the VMEbus are based on VERSAbus, developed in the
late 1970s by Motorola. Motorola's European Microsystems group in Munich,
West Germany, proposed the development of a VERSAbus-like product line based on
the Eurocard mechanical standard. To demonstrate the concept, Max Loesel and
Sven Rau developed three prototype boards: a 68000 CPU board; a dynamic
memory board; a static memory board. They named the new bus VERSAbus-E. This
was later renamed "VME", short for Versa Module European, by Lyman Hevle, then a
VP with the Motorola Microsystems Operation.. In early 1981, Motorola,
Mostek and Signetics agreed to jointly develop and support the new bus
architecture. These companies were all early supporters of the 68000
microprocessor family. John Black of Motorola, Craig MacKenna
of Mostek and Cecil Kaplinsky of Signetics developed the first draft of
the VMEbus specification. In October 1981, at the System '81 trade show in
Munich, West Germany, Motorola, Mostek, Signetics/Phillips, and Thomson CSF
announced their joint support of the VMEbus. They also placed Revision A of
the specification in the public domain. In August 1982, Revision B of the VMEbus
specification was published by the newly formed VMEbus Manufacturers' Group. This
new revision refined the electrical specifications for the signal line
drivers and receivers and brought the mechanical specification further in line
with the developing IEC 297 standard. In latter 1982, the French delegation of
the International Electrotechnical Commission proposed Revision B of the
VMEbus as an international standard. The IEC SC47B subcommittee nominated Mira
Pauker of Phillips, France, the chairperson of an editorial committee,
thus formally starting international standardization of the VMEbus.
In March 1983, the IEEE Microprocessor Standards Committee requested
authorization to establish a working group that could standardize the VMEbus
in the US. This request was approved by the IEEE Standards Board and the P1014
Working Group was established. Wayne Fischer was appointed first chairman of
the working group. John Black served as chairman of the P1014 Technical
Subcommittee. The IEC, IEEE and VMEbus Manufacturers Group distributed copies
of Revision B for comment and received the resulting requests for changes to
the document. These comments made it clear that it was time to go past
Revision B. In December 1983, a meeting was held that included John Black, Mira
Pauker, Wayne Fischer and Craig MacKenna. It was agreed that a Revision
C should be created and that it should take into consideration all the comments
received by the three organizations. John Black and Shlomo Pri-Tal of
Motorola incorporated the changes from all sources into a common document. The
VMEbus Manufacturers Group labelled the document Revision C.1 and placed it in
the public domain. The IEEE labelled it P1014 Draft 1.2 and the IEC labelled it
IEC 821 Bus. Subsequent ballots in the IEEE P1014 Working Group and the MSC
resulted in more comments and required that the IEEE P1014 draft be updated.
This resulted in the ANSI/IEEE 1014-1987 specification.
In 1989, John Peters of Performance Technologies Inc. developed the initial
concept of VME64: multiplexing address and data lines on the VMEbus. The
concept was demonstrated the same year and placed in the VITA Technical
Committee in 1990 as a performance enhancement to the VMEbus specification.
In 1991, the PAR for P1014R was granted by the IEEE. Ray Alderman, Technical
Director of VITA, co-chaired the activity with Kim Clohessy of DY-4
Systems. At the end of 1992, the additional
enhancements to VMEbus required more work to complete this document. The VITA
Technical Committee suspended work with the IEEE and sought accreditation as a
standards developer organization with the American National Standards
Institute. The original IEEE Par P1014R was subsequently withdrawn by the IEEE.
The VITA Technical Committee returned to using the public domain VMEbus C.1
specification as their base-level document, to which they added new
enhancements. This enhancement work was undertaken entirely by the VITA
Technical Committee and resulted in ANSI/VITA 1-1994. The tremendous
undertaking of the document editing was accomplished by Kim Clohessy of DY-4
Systems, the technical co-chair of the activity, with great help from Frank Hom
who created the mechanical drawings and exceptional contributions by each
chapter editor. Additional enhancements proposed to the
VME64 Subcommittee were placed in the VME64 Extensions Document. Two other
activities began in late 1992: BLLI and VSLI.
In 1993, new activities began on the base-VME architecture, involving the
implementation of high-speed serial and parallel sub-buses for use as I/O
interconnections and data mover subsystems. These architectures can be
used as message switches, routers and small multiprocessor parallel
architectures. VITA's application for recognition as an
accredited standards developer organization of ANSI was granted in June
1993. Numerous other documents have been placed with VITA as the Public Domain
Administrator of these technologies. A more detailed timeline of VMEbus
history can be found at the VITA website [1]
Description In many ways the VMEbus is equivalent or
analogous to the pins of the 68000 run out onto a backplane. In many cases this
could be considered a bad design. One is in theory limited to chipset buses
similar to the 68000. However, one of the key features of the
68000 was a flat 32-bit memory model, free of memory segmentation and other
"anti-features". The result is that, while VME is very 68000-like, the 68000
is generic enough to make this not an issue in most cases.
Like the 68000, VME uses separate 32-bit data and address buses. The 68000
address bus was actually 24-bit and the data bus 16-bit but the designers were
already looking towards a full 32-bit implementations.
In order to allow both bus widths, VME uses two different Eurocard connectors -
P1 and P2. P1 contains three rows of 32 pins each, implementing the first 24
address bits, 16 data bits and all of the control signals. P2 contains one
more row, which includes the remaining 8 address bits and 16 data bits.
The bus is controlled by a set of nine lines, known as the arbitration bus. All
communications are controlled by the card in slot one of the Eurocard
chassis, known as the arbiter module. Two arbitration modes are supported -
Round Robin and Prioritized. Regardless of the arbitration mode, a
card can attempt to become the bus master by holding one of the four Bus
Request lines low. With round robin arbitration, the arbiter cycles amongst
Bus Request lines BR0-BR3 to determine which of the potentially simultaneous
requesters will be granted the bus. With priority arbitration, BR0-BR3 use a
fixed priority scheme and the arbiter will grant the bus to the highest
priority requestor. When the arbiter has determined which of
the bus requests to grant, it asserts the corresponding Bus Grant line for the
level that won bus mastership. If two masters simultaneously request the bus
using the same BR line, a bus grant daisy-chain effectively breaks the tie
by granting the bus to the module closest to the arbiter. The master
granted the bus will then indicate that the bus is in use by asserting Bus Busy.
At this point, the master has gained access to the bus. To write data, the
card drives an address, an address modifier and data onto the bus. It then
drives the address strobe line and the two data strobe lines low, to indicate
the data is ready, and drives the write pin to indicate the transfer direction.
There are two data strobes and an *LWORD line, so the cards can indicate if the
data width is 8, 16, or 32 bits. The card at the bus address reads the data
and pulls the data transfer acknowledge low line when the transfer can complete.
If the transfer cannot complete, it can pull the bus error line low. Reading
data is essentially the same but the controlling card drives the address bus,
leaves the data bus tri-stated and drives the read pin. The slave card
drives read data onto the data bus and drives the data strobe pins low when the
data is ready. The signalling scheme is asynchronous, meaning that the transfer
is not tied to the timing of a bus clock pin.
A block transfer protocol allows several bus transfers to occur with a single
address cycle. In block transfer mode, the first transfer includes an address
cycle and subsequent transfers require only data cycles. The slave is
responsible for ensuring that these transfers use successive addresses.
Bus masters can release the bus in two ways. With Release When Done, the master
releases the bus when it completes a transfer and must re-arbitrate for the
bus before every subsequent transfer. With Release On Request, the master
retains the bus by continuing to assert BBSY* between transfers. ROR allows the
master to retain control over the bus until a Bus Clear is asserted by another
master that wishes to arbitrate for the bus. Thus a master which generates
bursts of traffic can optimize its performance by arbitrating for the bus
on only the first transfer of each burst. This decrease in transfer latency
comes at the cost of somewhat higher transfer latency for other masters.
Address modifiers are used to divide the VME bus address space into several
distinct sub-spaces. The address modifier is a 6 bit wide set of signals
on the backplane. Address modifiers specify the number of significant
address bits, the privilege mode, and whether or not the transfer is a block
transfer. Below is an incomplete table of address modifiers:
VME also decodes all seven of the 68000's interrupt levels onto a 7-pin
interrupt bus. The interrupt scheme is one of prioritized vectored interrupts.
The interrupt request lines prioritize interrupts. An interrupting module
asserts one of the interrupt request lines. Any module on the bus may
potentially handle any interrupt. When an interrupt handling module recognizes
an interrupt request at a priority it handles, it arbitrates for the bus in
the usual fashion described above. It then performs a read of the interrupt
vector by driving the binary version of the IRQ line it handles onto the address
bus. It also asserts the IACK line, along with the appropriate data transfer
strobes for the width of the status/ID being read. Again, LWORD*, DS0* and DS1*
allow status/ID read cycles to be 8, 16, or 32 bit wide transfers but most
existing hardware interrupters use 8 bit status/IDs. The interrupter responds by
transferring a status/ID on the data bus to describe the interrupt. The interrupt
handling module will usually use this status/ID number to identify and run the
appropriate software interrupt service routine.
On the VME bus, all transfers are DMA and every card is a master or slave. In
most bus standards, there is a considerable amount of complexity added
in order to support various transfer types and master/slave selection. For
instance, with the ISA bus, both of these features had to be added alongside
the existing "channels" model, whereby all communications was handled by the
host CPU. This makes VME considerably simpler at a conceptual level while
being more powerful, though it requires more complex controllers on each card.
Development tools When developing and/or troubleshooting
the VME bus, examination of hardware signals can be very important. Logic
analyzers and bus analyzers are tools which collect, analyze, decode, store
signals so people can view the high-speed waveforms at their leisure.
Computers using a VMEbus Computers using VMEbus include
HP 743/744 PA-RISC Single-board computer Sun-2 through Sun-4
HP 9000 Industrial Workstations Atari TT030 and Atari MEGA STE
Motorola MVME Symbolics
Advanced Numerical Research and Analysis Group's PACE.
ETAS ES1000 Rapid Prototyping System several Motorola 88000 based Data
General AViiON computers See also
Data acquisition VPX
VXS CompactPCI
CAMAC FPDP
List of device bandwidths References
External links VITA
Next Generation VME VME bus pinout and signals