2    VMEbus Architectures

The VMEbus is an industry-standard high-performance bus that supports 8-, 16-, and 32-bit transfers over a nonmultiplexed 32-bit data bus. In addition, the VMEbus supports 16-, 24-, and 32-bit addressing over a separate 32-bit address bus. This chapter discusses the following:

• VMEbus hardware architecture

• VMEbus software architecture

For detailed information on the VMEbus architecture, see the IEEE Standard for a Versatile Backplane Bus: VMEbus ANSI/IEEE Std 1014-1987.

2.1    VMEbus Hardware Architecture

The VMEbus, like other buses, is a computer architecture that defines a computer data path. Unlike other buses, the VMEbus is microprocessor independent, is easily upgraded from 16-bit to 32-bit processors, and is suitable for a vendor to build compatible products. The following VMEbus hardware architecture topics are relevant to the device driver writer:

• Address spaces

• Data sizes

• Byte ordering

• Interrupt vectors

• Interrupt priorities

2.1.1    Address Spaces

The VMEbus hardware makes no distinction between I/O space and memory space. The device driver writer must understand which address space the board uses. The VMEbus hardware architecture includes three address spaces:

• 16-bit (A16)

• 24-bit (A24)

• 32-bit (A32)

These address spaces are overlapping and can be unique in the Digital UNIX model; that is, an address (for example, 0xC0) points to the same location in all three address spaces. Some VMEbus devices can respond to address requests in any of the address spaces.

2.1.2    Data Sizes

The VMEbus supports 8-bit (D08), 16-bit (D16), and 32-bit (D32) data sizes. A VMEbus device can operate in more than one data space at one time. For example, a VMEbus device may have D16 control registers and D32 memory.

2.1.3    Byte Ordering

While the VMEbus does not specify any particular byte ordering, most devices use the Motorola model, which is big endian. Because the Digital model is little endian, two mechanisms are provided to accomplish byte swapping:

• VMEbus adapter

  Some VMEbus adapters provide hardware byte swapping. Digital's adapters provide hardware assist for all direct memory access (DMA) transfers and may provide hardware assist for programmed I/O (PIO) transfers on an adapter-dependent basis.

• Software interfaces

  Kernel interfaces and library calls accomplish the byte swapping. Writing Device Drivers: Reference presents, in reference (man) page style, descriptions of the following byte-swapping interfaces: swap_lw_bytes, swap_word_bytes, and swap_words.

2.1.4    Interrupt Vectors

VMEbus interrupt vectors range from 0x00 to 0xff, inclusive. Some of these vectors are consumed by the bus adapter and not available for use by device drivers. Interrupt vectors that a controller can use are VMEbus adapter specific. See the adapter-specific documentation for more information.

You specify interrupt vectors in the system configuration file or config.file file fragment.

2.1.5    Interrupt Priorities

The VMEbus provides for seven interrupt priorities (IRQ 1 through IRQ 7, with IRQ 7 the highest priority). On some host implementations, fewer than seven levels may be provided. On those implementations, the VMEbus priorities are mapped to the available host priority levels.

Digital UNIX allows the adapter to handle any or all of the VMEbus interrupt levels. In general, you will want the adapter to handle all seven levels. If, however, there is another processor on the VMEbus that you want to handle VMEbus interrupts, you can selectively enable the interrupts. The mechanism for accomplishing this is adapter specific. See the documentation supplied with the adapter for information on how to accomplish this.

Note

VMEbus IRQs must be unique to a system. This means that other systems cannot use the IRQs owned by a specific system.

2.2    VMEbus Software Architecture

Before writing device drivers that operate on the VMEbus, you need to consider the following topics associated with the VMEbus software architecture:

• VMEbus address space

• Direct memory access (DMA) support

• Input/output (I/O) access

• Writes to the hardware device register

2.2.1    VMEbus Address Space

The VMEbus supports as many as 64 different address spaces. Specific VMEbus adapter implementations usually support a subset of these address spaces. In many of these implementations, the address spaces overlap such that an address in one space is synonymous with an address in a different space. For this reason, Digital UNIX overmaps these address spaces onto a 4-gigabyte (GB) (32 address bits) space as shown in Figure 2-1.

VMEbus adapter-specific implementations can constrain DMA allocations and I/O allocations for different address spaces within the 4 GB overmapped region.

During device autoconfiguration, the VMEbus configuration code maps the VMEbus IRQ level to a system priority level (spl). The VMEbus configuration code uses the priority member of the controller structure pointer associated with the device to store the spl.

Figure 2-1: VMEbus Address Space

The figure shows the following overmapped address spaces:

• A 16-bit address space (A16) of 64 kilobytes (KB)

  Valid VMEbus CSR addresses for the A16 space range from 00000000 to 0000FFFF, inclusive.

• A 24-bit address space (A24) of 16 megabytes

  Valid VMEbus CSR addresses for the A24 space are from 00000000 to 00FFFFFF, inclusive.
  

• A 32-bit address space (A32) of 0 GB to 4 GB

  Valid VMEbus CSR addresses for the A32 space are from 00000000 to FFFFFFFF, inclusive.

Note

The bus adapter hardware constrains the A32 address space to an addressing window. Usually, the window is 128 MB and can be positioned anywhere within the 4 GB VMEbus address space on a 128 MB aligned boundary.

In previous versions of the operating system, you allocate the VMEbus address space for direct memory access operations by calling vballoc or vbasetup. For this version of Digital UNIX, you must use the following interfaces:

• dma_map_alloc

  Allocates resources for DMA data transfers

• dma_map_load

  Loads and sets allocated DMA resources and sets up a DMA data path for DMA data transfers

You can also use vba_set_dma_addr to specify a VMEbus address and DMA flags for dma_map_alloc and dma_map_load.

The values that dma_map_alloc and dma_map_load return are different than those that vballoc and vbasetup return. See Section 5.1 for examples of how to use dma_map_alloc and dma_map_load.

Note

The dma_map_alloc and dma_map_load interfaces replace the vballoc and vbasetup interfaces that VMEbus device drivers used in previous versions of the operating system.

2.2.2    Direct Memory Access Support

Some VMEbus devices can perform direct memory access (DMA). The host processor informs the device controller about the following when performing DMA:

• The address in the VMEbus address space where a data transfer occurs

• The length of the data to be transferred

• When to start the data transfer

The host processor makes no further intervention during the transfer of the data. Upon completion of the data transfer, the device controller interrupts to indicate that the transfer has successfully completed. This is usually referred to as inbound transfers of DMA read and write operations. The device initiates the transfer of data and contains a DMA engine.

Consider the following when working with the VMEbus and DMA:

• VMEbus-to-host DMA (inbound transfer with respect to the CPU)

• VMEbus device-to-device DMA

• Rules for performing DMA on multiple VMEbus adapters

2.2.2.1    VMEbus-to-Host DMA

Figure 2-2 shows VMEbus-to-host DMA and VMEbus-from-host DMA.

Figure 2-2: VMEbus-to-Host DMA (Read and Write Operations)

The figure depicts the following typical VMEbus environment:

• A host CPU and its attendant memory

• The buffer cache

• I/O space

• An adapter that contains the mapping registers

• The VMEbus address space

• One or more devices represented by Device 1 through Device n

The figure uses two arrows to indicate that the device initiates the DMA data transfer operation: in one case a read operation and in the other a write operation. In both cases, the host memory is mapped into the A32 space. The transfer continues through the adapter into the host memory. Some memory space in the CPU is mapped to the A32 DMA space.

In the case of the read operation, the device reads from the A32 mapped space and the data is fetched by the device from mapped host memory.

Not all adapters provide the ability to perform DMA to the entire address range.

2.2.2.2    VMEbus Device-to-Device DMA

In addition to VMEbus-to-host DMA (inbound transfer with respect to the CPU), there is VMEbus device-to-device DMA. The VMEbus address space may have holes that are created by device registers and onboard memory. VMEbus device-to-device DMA on the current bus adapter must reside outside of any system's inbound DMA configured window.

2.2.2.3    Rules for Performing DMA on Multiple VMEbus Adapters

The following list describes rules for performing DMA operations on multiple VMEbus adpaters:

• You define the DMA inbound window base in the bus adapter-specific data structure. One example of a bus adapter-specific data structure is xviadata. The size of the DMA inbound window base is either implicit or explicit. If the size is explicit, the bus adapter-specific data structure defines a member to store it. Some bus adapter implementations permit separate specification of the A24 and A32 window size and base. Many bus adapter implementations impose alignment and size constraints on these DMA windows. See the bus adapter-specific software documentation for any alignment and size constraints.

• I/O allocations made with vba_map_csr can be subject to address space- and address-specific constraints. Addresses already allocated to the inbound DMA window must not be allocated to outbound I/O read/write access.

• The inbound DMA window must not have an overmapped addressing conflict with another VME controller or bus adapter.

2.2.3    I/O Access

Applications access I/O devices through memory locations in the physical address space of the CPU. A programmed I/O (PIO) mechanism is provided for transferring data as the result of a data transfer request from an application. Figure 2-3 shows programmed I/O.

Figure 2-3: Programmed I/O

In the PIO mechanism, the device driver performs the data transfer. The VMEbus address space for the CSRs or onboard memory is mapped during VMEbus configuration when the device is configured. The sizes and address spaces for the mapped areas are set in the following members of the driver structure: addr1_size, addr2_size, addr1_atype, and addr2_atype. Section 4.2 describes these members as they apply to the VMEbus. Digital UNIX passes the information contained in these members to the device driver through the driver's probe interface. Section 3.2.1 shows how to set up a probe interface for a VMEbus device driver.

VMEbus device drivers can map outbound VMEbus address space by calling the vba_map_csr interface.

2.2.4    Writes to the Hardware Device Register

Whenever a VMEbus device driver writes to a hardware device register, the write might be delayed by the system write buffer that is used to synchronize the CPU. A subsequent read of that register does not wait for the write to be completed. In previous versions of the operating system, you use VMEbus-specific interfaces to accomplish all accesses to VMEbus address space. The vme_read_byte, vme_read_word, vme_read_long, vme_write_byte, vme_write_word, and vme_write_long interfaces let you read or write a byte, word, or longword from or to the VMEbus address space.

Digital UNIX provides the following generic CSR I/O access interfaces to read from and write to the device's CSR addresses: read_io_port and write_io_port. Digital recommends that all new VMEbus device drivers call the read_io_port and write_io_port interfaces. The previously listed VMEbus-specific interfaces are obsolete and no longer available. See Writing Device Drivers: Tutorial for descriptions and examples of read_io_port and write_io_port.