How is a bus request initiated on the VME bus?

Question

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?

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.