Products > Vintage Computing

Any VMEbus experts here? I have a question about bus access

(1/4) > >>

Hi all.

I have this idea to create a multi-processor VMEbus based system, just for a challenge and "beacause why not". ^-^ I have a subrack and backplane all ready to go, but the project is a bit of a long term thing, so Im not intending to jump straight in just yet...

I have a document that explains the bus and its protocols for acquiring the bus etc, and I feel quite confident that I will be able to implement the required logic in some CPLDs and GALs without any issue based on this document.

But there is one thing that I havent yet been able to figure out, and that is just how a CPU (or its software) actually goes about acquiring the bus. There are a few different ways I can think of, but Im not sure which (if any) was the "intended" mode of operation, and maybe someone that is familiar with VME bus can help me fill in this detail.

1. Software running on a CPU card knows that it needs to access a peripheral that is located on another card plugged into the bus, so it communicates the need for bus access to its own on-board bus controller (e.g. set a bit in a register to kick off the bus arbitration process), which requests the bus, and perhaps acknowledges that bus access has been obtained through an interrupt that can set a semaphore or release a mutex or something, or maybe the software can sit there and poll a register in the controller to see when bus access has been obtained. Once the software is done accessing the bus it can then reconfigure its bus controller to release the bus.

2. Software "assumes" that it always has access to the bus, and just attempts reads and writes to those peripherals as required. The on-board bus controller determines (e.g. via an address decoder) when bus access is required, obtains the bus, and holds on to it just for that bus transaction. In this mode, bus accesses are completely transparent to the software, and no consideration needs to be made for obtaining or releasing it.

3. Some kind of hybrid of the above. Maybe software at first assumes that it has bus access when ever it wants it, and upon trying to access an external peripheral the on-board bus controller gains access to the bus per #2, and it holds on to it indefinitely. When the software is done accessing the peripheral it reconfigures the bus controller to release the bus as per #1. This allows a CPU card to hold on to the bus until another card wants to access the bus and the bus arbiter signals the current owner to get off the bus.

#1 seems like it would work well in e.g. an RTOS type environment where you can put in a request for the bus and yield the task to go and do other things while bus access is obtained (or perhaps poll a couple of times in case it is acquired immediately), eventually returning to complete what ever it was that needed to be done once bus access is acquired.

#2 and the first part of #3 seems like they would have the potential to stall the CPU for large amounts of time, blocking the CPU from doing *anything* while bus access is obtained and the transaction complete. It would be very necessary to implement a timeout to assert BERR to end a bus transaction in error if the CPU has waited too long for the bus to be obtained, allowing the software to re-try the bus access, or at least allow it to defer the bus access for a little while and go and do other things.

Does anyone have any insight they could share?


The VME Bus is basically an extended m68k bus. In the simplest case, you only have one single bus master (the CPU card). In this case, the VME system works just like any 80th m68k home computer system.

If you have more than one single bus master, there is a bus arbiter that assigns each individual potential master a priority. Masters with higher priority can request the bus with their /BR line (that ends up on the /BR0../BR3 lines corresponding to its own priority). The arbiter sends a /BCLR to request the current master to release the bus which does so (usually after the end of the current cycle) and deasserts /BBSY. The arbiter than assigns /BG0../BG3 (depending on who is the new master), releases /BCLR, the new master owns the bus now until another master requests it.

/BR0../BR3 and /BG0../BG3 can be daisy-chained if you have more than 4 potential masters (those closer to the arbiter than get higher priority).

Thanks, but I feel as though you have missed the question that I am asking.  :)

The details of the backplane and the arbitration process are already known.

But exactly when/what/how/who starts the arbitration process is what I am trying to establish, as per the example scenarios in my first post.

I would start by defining a logical CPU address space that you would like to use that represents the physical address space of the VMEbus. From the CPU side, you have several options on how software talks to the VMEbus. You could abstract it and provide a register based controller that issues VMEbus I/O transactions, or you could use native load/store memory semantics and decode the CPU's physical address lines to select the VMEbus's arbitration logic that you implement. You'll need to decouple the CPU from the VMEbus with latches and data transceivers.

Perhaps looking at the (totally obsolete) MC68452 "Bus Arbitration Module" could give you a hint of the Motorola thinking:


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version