VMEbus

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.[3] The Motorola team brainstormed for days to select the name VERSAbus. VERSAbus cards were large, 370 by 230 mm (14+1⁄2 by 9+1⁄4 in), and used edge connectors.[2] Only a few products adopted it, including the IBM System 9000 instrument controller and the Automatix robot and machine vision systems.

VERSAbus memory card

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 (although some refer to it as Versa Module Europa).[2]

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.[2] Other associated standards have added hot-swapping (plug-and-play) 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.[2] 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.

In many ways the VMEbus is equivalent or analogous to the pins of the 68000 run out onto a backplane.

However, one of the key features of the 68000 is 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 is actually 24-bit and the data bus 16-bit (although it is 32/32 internally) but the designers were already looking towards a full 32-bit implementation.

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 (BR0 lowest, up to BR3 highest) 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 (BG0–BG3) 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 (BBSY*).

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 (or 64 in VME64). 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 (unlike synchronous buses such as PCI).

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 (RWD), 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 (ROR), 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 (BCLR*) is asserted by another master that wishes to arbitrate for the bus. Thus a master that 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 (to allow processors to distinguish between bus accesses by user-level or system-level software), 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 (IRQ1–IRQ7) 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 (e.g. if IRQ5 is being handled, then binary 101) 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 (usually a CPU) 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.

When developing and/or troubleshooting the VME bus, examination of hardware signals can be very important. Logic analyzers and bus analyzers are tools that collect, analyze, decode, store signals so people can view the high-speed waveforms at their leisure.

VITA offers a comprehensive FAQ to assist with the front end design and development of VME systems.

Computers using VMEbus include:

• HP 743/744 PA-RISC Single-board computer[4]
• 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
• Early Silicon Graphics MIPS-based systems including Professional IRIS, Personal IRIS, Power Series, and Onyx systems
• Convergent Technologies MightyFrame

Seen looking into backplane socket.[5][6]

P1

P2

P2 rows a and c can be used by a secondary bus, for example the STEbus.

• Data acquisition
• VPX
• VXS
• CompactPCI
• CAMAC
• FPDP
• List of device bandwidths

• VITA
• Next Generation VME
• VME bus pinout and signals