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

[TomS_]

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?

Thanks!

[mfro]

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

[TomS_]

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.

[x86guru]

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.

[Benta]

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

https://4donline.ihs.com/images/VipMasterIC/IC/MOTO/MOTOS12978/MOTOS12978-1.pdf?hkey=D9A213CC6FEE7D103EF6B88F2AEB20B8

[srb1954]

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.

Does anyone have any insight they could share?

Thanks!

Have you checked out the documentation available from VITA? They have a wealth of information on the VME bus and its extensions.

https://www.vita.com/.

Also it is worth looking out for the original VERSAbus specification document generated by Motorola from which the VME bus specification was developed. This is one of the finest engineering specification documents I have ever read. Very rarely do you see engineering documentation that is so expertly written to be so clear and easy to understand.

[mfro]

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.

Your questions implied that software on a card that acts as a VME bus master would have a choice to control the arbitration process.

At least in the original specification, it hasn't. In its simplest incarnation, a VME system would have an m68k CPU that presents its bus to the backplane and a memory card in another slot that understands the same bus protocol. When booting such a system, the m68k bus protocol would request memory contents from the slave card that would then answer with data on the bus and /DTACK asserted. If /DTACK wouldn't be asserted, the CPU would issue a bus error and stop. No choice for software to intercept or control this process.

In such a system, there is no "bus controller" that could be controlled by software because the VME bus *is* the CPU's bus in fact.

[TomS_]

Your questions implied that software on a card that acts as a VME bus master would have a choice to control the arbitration process.

Correct, for #1, but only in so far as initiating the arbitration process - no control otherwise over how it happens (except to release the bus when youre done with it). I had hoped that was reasonably well explained in that scenario.

[TomS_]

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.

Yup, that is a detail that I will figure out later. What I really want to know at the moment is how the arbitration process is kicked off - whether it is under direction of software when it knows it needs bus access, or happens transparently under the hood.

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.

Im aiming to do this without any further layers of abstraction. The CPUs will be isolated from the backplane via tri-state buffers, and only connected through once the bus has been granted to a master.

[mfro]

Yup, that is a detail that I will figure out later. What I really want to know at the moment is how the arbitration process is kicked off - whether it is under direction of software when it knows it needs bus access, or happens transparently under the hood.

IMO, it's the latter. Hardware would just issue a bus error when there is no answer from the bus (/DTACK) after a certain number of cycles.

[TomS_]

Have you checked out the documentation available from VITA? They have a wealth of information on the VME bus and its extensions.

I think I saw something about them in a document from CERN that said while the standard was open, it wasnt "free" as such.

Also it is worth looking out for the original VERSAbus specification document generated by Motorola from which the VME bus specification was developed. This is one of the finest engineering specification documents I have ever read. Very rarely do you see engineering documentation that is so expertly written to be so clear and easy to understand.

I'll take a look. Thanks! My experience so far seems to be that documentation focusses quite heavily on how to arbitrate the bus, but not what kicks it off on a master.

At the moment Im kind of thinking that I could potentially implement both transparent and also software initiated bus access. If I want to transfer a larger block of data (e.g. a sector off a hard disk) I could set a bit in the on-board bus controller to acquire the bus manually and then release it once the full sector has been transferred. That would at least stop another master from trying to access the hard disk half way through reading or writing a sector.

[TomS_]

IMO, it's the latter. Hardware would just issue a bus error when there is no answer from the bus (/DTACK) after a certain number of cycles.

Yeah, my developing feeling is that I can just handle it transparently in the bus controller on the master when I implement that, and as above I could also have a bit that I can set in a register to manually acquire it if I know I will need it for a larger transfer.

Im not planning on having any DMA controllers on my masters, at least not initially, so that bit would basically allow me to initiate a manual block transfer of sorts.

[mfro]

At the moment Im kind of thinking that I could potentially implement both transparent and also software initiated bus access. If I want to transfer a larger block of data (e.g. a sector off a hard disk) I could set a bit in the on-board bus controller to acquire the bus manually and then release it once the full sector has been transferred. That would at least stop another master from trying to access the hard disk half way through reading or writing a sector.

I understand you want to block the bus for exclusive access of a single master?

Not sure if this is a good idea as it probably would render the VME bus interrupt abilities useless?

[TomS_]

As I understand it, a bus master can hold the bus for as long as it wants, and has no particular requirements to vacate the bus within any particular amount of time even once BCLR is asserted. But naturally for cooperative purposes you should only hold it as long as you need it, and vacate as quickly as you can when you are done to allow other things to happen.

While the bus is occupied by one master, that does prevent other masters from servicing their interrupts, but that is I suppose a downside of a shared bus - it is a scarce resource and everything needs to cooperate to give everyone a fair chance at using it.

Example cases of where I would want to hold the bus exclusiely for a short while would be when interacting with a disk drive, like reading or writing a sector. This is a kind of operation that I would want to complete in one pass. e.g. you wouldnt want to start writing a sector, then stop half way through and have another master try to do something with the disk when it might result in data corruption.

[cruff]

Example cases of where I would want to hold the bus exclusiely for a short while would be when interacting with a disk drive, like reading or writing a sector. This is a kind of operation that I would want to complete in one pass. e.g. you wouldnt want to start writing a sector, then stop half way through and have another master try to do something with the disk when it might result in data corruption.

That depends on the disk controller if you can pause during a transfer or not. If the controller performs internal buffering before it writes to the media then you can tolerate interruption of the block transfer. As to another bus master interfering with the same controller, that is not usually a matter for bus lock out or arbitration, but a higher level mutual exclusion lock handled in software.

[cfbsoftware]

There's a ~40 page detailed discussion of the VMEbus in Chapter 10 Microcomputer Buses of Alan Clements' book Microprocessor Systems Design - 68000 Hardware, Software and Interfacing that may help answer some of your questions.

[jmelson]

There's a ~40 page detailed discussion of the VMEbus in Chapter 10 Microcomputer Buses of Alan Clements' book Microprocessor Systems Design - 68000 Hardware, Software and Interfacing that may help answer some of your questions.

This has all gotten SO much more complex since the 68K days.  VME handles 16, 32 and 64-bit data path, and 16, 24 and 32-bit addresses, at least.
I think there's a 5-bit field to identify what the data and address width are for each cycle.  We use VME to interface various data acquision boards, that are all FPGA-controlled.  We have a USB controller that has a list of words to collect, and grabs them at an insane rate, pacling them into USB packets at 10+ MB/second.

Jon