I am looking into creating a multi-processor "VME-like" system as a challenge and "because why not". I say VME-like because it probably wont be a strict VMEbus implementation, but rather something heavily inspired by it. I'll be creating my own peripherals as part of the project, so I’m not worried if I couldn’t plug in a commercial VME module and have it work (although I guess that could be a bonus).

I have a document that describes the VME bus, its signals and what they do, and outlines the arbitration protocol/process, and I feel as though I have a good understanding of VMEbus on the bus side between masters and slaves. I have a decent amount of familiarity with CPLDs, so I will use these to implement the arbiters (for the system à la slot 1, and on the masters).

But what I am not sure about is how the arbitration process is kicked off on a master that wants to acquire the bus in order to talk to a peripheral.

There are a few different scenarios that I can think of, but I am not sure which is the "intended" mode of operation, and none of the documents that I have read so far seem to talk about the portion of the system between the CPU and the bus — maybe this is somewhat deliberate?

  1. The arbitration process is initiated in software. When software knows that it wants to access a peripheral, it "configures" its requester to start arbitrating for the bus. The requester could either signal back to the CPU via interrupt and/or by setting a bit in a register that the software can read to determine when it has acquired the bus. When the software is done accessing the bus, it once again configures its requester to release the bus (e.g. clear a bit).

  2. The arbitration process is handled entirely "in hardware". The software just assumes that it always has access to the bus and goes about doing reads/writes to peripherals. An on-board address decoder sets an output when an access is being made to an address that is mapped out to the bus, this feeds into the requester which then starts arbitrating for the bus. While the arbitration process is ongoing, the CPU is essentially stalled until DTACK or BERR is asserted. At the end of the bus cycle the requester releases the bus automatically.

  3. Some kind of hybrid of the above. Perhaps the software initially assumes it has access to the bus and goes about doing reads/writes while the requester automatically acquires the bus in the background. Once the software has finished with its reads/writes it can then configure the requester to release the bus. This could also potentially be tied in with #1 so both manual and automatic arbitration could be initiated.

#1 sounds like it would be best in an environment where you’re running some kind of (RT)OS, as you could initiate bus arbitration, yield your task and then come back once you have acquired the bus, thus allowing the software to do other things in the mean time.

#2 sounds like it has the potential to stall the CPU for periods of time, during which almost nothing can happen. BERR can be used to signal a timeout if the bus arbitration is taking too long, and the software would then just need to retry its request.

Is it simply "up to the implementation" to define how bus arbitration is initiated (while obviously the bus arbitration protocol itself is defined by the standard)?

Is anyone able to share some insight?

  • 1
    Regarding #2: DTACK/BERR do not indicate the end of bus occupancy for a master. A master can keep BBSY* asserted for multiple cycles, to implement atomic operations such as test-and-set, etc. Bus ownership only changes when the current master releases BBSY*. Note that this also means that arbitration for the next master can be overlapped with the cycles being run by the current master.
    – Dave Tweed
    Dec 16, 2021 at 13:54
  • Yeah, thats kind of why I thought about #1 and #3. The 68000 and '010 dont have a way to signal that a read/modify/write is in progress (you'd have to have hardware to decode the instruction stream to work that out I suppose), but the '020 and above have a pin called "RMC" that does, and that could be used to continue to hold the bus until it is also released.
    – Tom S
    Dec 18, 2021 at 14:01

1 Answer 1


Although I don't have a deep VMEbus experience, maybe I can share some helpful aspects.

I've never seen a system bus arbitration initiated by software. A system bus like VME is meant to connect the processor to its peripherals or even to RAM banks. Forcing the processor to software-announce a potential RAM access in advance would be more than weird.

System busses are designed to not get in the way of the CPU's programming model, so that a RAM or peripheral access can happen without regard for the data path between the CPU and tha target RAM or peripheral, be it through a "direct" connection or through the system bus.

Of your scenarios, only #2 fulfills that requirement, and that's the way system busses work. Arbitration is done in pure hardware.

You are right that this approach has the potential to stall a CPU for some time, but only if some other device (CPU / DMA-capable peripheral) blocks the bus for an extended period without releasing it. As the bus is a resource that can only do one transfer at a time, all devices competing for the bus access should behave as good citizens and only block the bus during the actual data transfer cycle, typically something well below a microsecond.

So, design the bus arbitration hardware in a way to make sure:

  • a device requests and blocks the bus only when it accesses an address mapped onto the bus,
  • it releases the bus immediately after the data transfer cycle (unless it wants to do the next read/write immediately) - don't hold the bus during idle time,
  • DMA-capable peripherals should buffer their data, so they can either cope with delays caused by bus arbitration (preferred) or at least do idle-time-free block transfers.

If, following these guidelines, you still experience stalls, then you are simply exceeding the bus capacity, and you should redesign your system to make more read/writes card-local, not needing the bus.

Regarding your #1 and

#1 sounds like it would be best in an environment where youre running some kind of (RT)OS, as you could initiate bus arbitration, yield your task and then come back once you have acquired the bus, thus allowing the software to do other things in the mean time.

If your bus is blocked for a timespan that allows for two task switches plus some useful work of the other task, then you have a serious problem.

And if you plan to use a modern-ish, multi-core or hyper-threading CPU, it will make good use of the time when one thread stalls, by still executing the other threads.

  • (1/3) Thanks, this is great information, and confirms a bit of a hunch I was developing. The only time I would really want to block the bus for an extended period of time would be e.g. if I was reading/writing a sector from a disk. I would want to complete that in one pass without interruption. I guess it is debatable whether a disk should be connected to the backplane rather than on a master, but I suppose that is also part of the challenge and seeing how things interact and making the most of what is available.
    – Tom S
    Dec 10, 2021 at 12:56
  • (2/3) My CPLDs wont be big enough to buffer any amount of data, so they are simply going to have to acquire the bus before anything can happen across it, and the CPU will just have to wait until the bus is acquired. That is a limitation I will have to live with given the limited hardware I will have available. I can implement appropriate mutexes and semaphores/flags in software such that a BERR can be generated to signal to the software that the bus wasnt acquired promptly, it could then choose to defer or retry the access I suppose. It will be a bit of a hardware and software dance.
    – Tom S
    Dec 10, 2021 at 12:56
  • (3/3) So my feeling now is to implement a bit of a combination of #1 and #2. Under normal conditions I would rely on #2 to automatically acquire and release the bus on a per-CPU-bus-cycle basis, but if I want to do a "pseudo DMA" operation (such as read/write a sector from disk in software) then having a means to manually acquire and release the bus will be available. It might be abnormal, but Im not building this to fly a rocket or anything. :-) I dont plan to have any hardware DMA initially, but #1 would lend itself to hardware DMA in the future.
    – Tom S
    Dec 10, 2021 at 12:56
  • Im planning on using Motorola 68000 or maybe 68020 processors since I have some of these laying around, so no multithreading etc going on.
    – Tom S
    Dec 10, 2021 at 13:00
  • Quite interesting project. If you don't have a real DMA, the only CPUs will acquire the bus, and only for the one short cycle to read/write a byte or word (unless your peripheral inserts wait states, which I'd try to avoid). What about having a CPU on the disk controller board to do things like buffering? Dec 10, 2021 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .