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?
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).
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.
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?