This appendix provides information to help users integrate third-party VME boards into the Onyx and POWER Onyx deskside systems.
The following information is divided into three major sections.
“VMEbus Architecture Interface,” provides a detailed discussion of the VMEbus architecture in the Onyx system. This section also briefly describes the overall bus structure, VME interrupt generation, and address mapping.
“Hardware Considerations,”discusses pertinent physical and electrical requirements and issues such as the required board dimensions, available power, airflow, VME pins assignments, the VME slots, and VME backplane jumpering.
“VMEbus Boards Design Considerations,” provides third-party VME board design considerations and guidelines.
|Warning: All board installations or removals should be performed only by personnel trained, certified, or approved by Silicon Graphics. Unauthorized access to the card cage area could result in system damage, or possible bodily harm, and could void the warranty for the system.|
The VME interface in the Onyx system supports all protocols defined in Revision C of the VME specification, plus the A64 and D64 modes defined in Revision D. The D64 modes allows DMA bandwidths of up to 60 MB.
|Note: The Onyx system does not support VSBbus mode.|
For the acceptable VME address ranges, read the /var/sysgen/system file.
The VMEbus interface circuitry for the Onyx and POWER Onyx systems resides on a mezzanine board called the VMEbus channel adapter module (VCAM) board. The VCAM board is standard in every system and mounts directly on top of the IO4 board in the system card cage (see Figure E-1). The VCAM is located on the master IO4 (in slot 4) and provides the VME connection.
The IO4 board is the heart of the I/O subsystem. The IO4 board supplies the system with a basic set of I/O controllers and system boot and configuration devices such as serial and parallel ports, and Ethernet.
In addition, the IO4 board provides these interfaces:
two flat cable interfaces (FCIs) for graphics data transfer
two SCSI-2 cable connections
two Ibus connections
See Figure E-2 for a functional block diagram of the IO4 board.
This section describes the bus structure of the system.
The main set of buses in the Onyx/Onyx system architecture is the Everest address and data buses, Ebus for short. The Ebus provides a 256-bit data bus and a 40-bit address bus that can sustain a bandwidth of 1.2 GB per second.
The 256-bit data bus provides the data transfer capability to support a large number of high-performance RISC CPUs. The 40-bit address bus is also wide enough to support 16 GB of contiguous memory in addition to an 8 GB I/O address space.
The 64-bit Ibus (also known as the HIO bus) is the main internal bus of the I/O subsystem and interfaces to the high-power Ebus through a group of bus adapters. The Ibus has a bandwidth of 320 MB per second that can sufficiently support a graphics subsystem, a VME64 bus, and as many as eight SCSI channels operating simultaneously.
Communication with the VME and SCSI buses, the installed set or sets of graphics boards, and Ethernet takes place through the 64-bit Ibus (see Figure E-2). The Ibus interfaces to the main system bus, the 256-bit Ebus, through a set of interface control devices, an I address (IA) and four I data (ID). The ID ASICs latch the data, and the IA ASIC clocks the data from each ID to the flat cable interface (FCI) through the F controller (or F chip).
Two FCI controllers (or F controllers) help handle the data transfers to and from an internal graphics board set. The SCSI-2 (S1) controller serves as an interface to the various SCSI-2 buses. The Everest peripheral controller (EPC) device manages the data movement to and from the Ethernet, a parallel port, and various types of on-board PROMs and RAM.
The VCAM board provides the interface between the Ebus and the VMEbus and manages the signal-level conversion between the two buses. The VCAM also provides a pass-through connection that ties the graphics subsystem to the Ebus.
All board installations or removals should be performed only
by personnel trained, certified, or approved by Silicon Graphics.
Unauthorized access to the card cage area could result in system damage,
or possible bodily harm, and could void the warranty for the system.The VCAM can operate as either a master or a slave. It supports DMA-to-memory transactions on the Ebus and programmed I/O (PIO) operations from the system bus to addresses on the VMEbus. In addition, the VCAM provides virtual address translation capability and a DMA engine that increases the performance of non-DMA VME boards.
The VMECC (VME cache controller) gate array is the major active device on the VCAM. The VMECC interfaces and translates host CPU operations to VMEbus operations (see Figure E-3). The VMECC also decodes VMEbus operations to translate them to the host side.
The VMECC provides the following features:
an internal DMA engine to speed copies between physical memory and VME space
|Note: For information on DMA memory mapping, see “DMA Multiple Address Mapping”.|
a 16-entry deep PIO FIFO to smooth writing to the VME bus from the host CPU board
a built-in VME interrupt handler and built-in VME bus arbiter
an explicit internal delay register to aid in spacing PIOs for VME controller boards that cannot accept back-to-back operations
A16, A24, A32, and A64 addressing modes (see Table E-1) that can be issued as a bus master with PIOs
single item transfers (D8, D16, D32, and D64) that can be issued as a bus master with PIOs
A24, A32, and A64 addressing modes that can be responded to as a memory slave to provide access to the Ebus
single item transfers (D8, D16, and D32) that can be responded to as a memory slave to provide access to the Ebus
block item transfers (D8, D16, D32, and D64—see Table E-1) that can be responded to as a memory slave
Table E-1. Supported Address and Data Sizes
A16 and D8 modes
A24 and D16 modes
A32 and D32 modes
A64 and D64 modes
The VMECC also provides four levels of VMEbus request grants, 0-3 (3 has the highest priority), for DMA arbitration. Do not confuse these bus request levels with the interrupt priorities described in “VMEbus Interrupts.” Bus requests prioritize the use of the physical lines representing the bus and are normally set by means of jumpers on the interface board.
Data transfers between VME controller boards and the host CPU(s) takes place through the VMECC on the VCAM board, then through a flat cable interface (FCI), and onto the F controller ASIC.
The F controller acts as an interface between the Ibus and the FCIs. This device is primarily composed of FIFO registers and synchronizers that provide protocol conversion and buffer transactions in both directions and translate 34-bit I/O addresses into 40-bit system addresses.
Two configurations of the F controller are used on the IO4 board; the difference between them is the instruction set they contain. One version is programmed with a set of instructions designed to communicate with the GFXCC (for graphics); while the other version has instructions designed for the VMECC. All communication with the GFXCC or VMECC ICs is done over the FCI, where the F controller is always the slave.
All versions of the F controller ASICs have I/O error-detection and handling capabilities. Data errors that occur on either the Ibus or the FCI are recorded by the F controller and sent to the VMECC or GFXCC.
ICs must report the error to the appropriate CPU and log any specific information about the operation in progress). FCI errors are recorded in the error status register. This register provides the status of the first error that occurred, as well as the cause of the most recent FCI reset.
The Onyx and POWER Onyx VMEbus interface supports all protocols defined in Revision C of the VME specification plus the A64 and D64 modes defined in Revision D. The D64 mode allows DMA bandwidths of up to 60 MB. This bus also supports the following features:
seven levels of prioritized processor interrupts
16-bit, 24-bit, and 32-bit data addresses and 64-bit memory addresses
16-bit and 32-bit accesses (and 64-bit accesses in MIPS III mode)
8-bit, 16-bit, 32-bit, and 64-bit data transfer
DMA to and from main memory
The VME bus does not distinguish between I/O and memory space, and it supports multiple address spaces. This feature allows you to put 16-bit devices in the 16-bit space, 24-bit devices in the 24-bit space, 32-bit devices in the 32-bit space, and 64-bit devices in 64-bit space.
The VME bus provides 32 address bits and six address-modifier bits. It supports four address sizes: 16-bit, 24-bit, 32-bit, and 64-bits (A16, A24, A32, and, A64). The VME bus allows the master to broadcast addresses at any of these sizes. The VME bus supports data transfer sizes of 8, 16, 32, or 64 bits.
|Note: To best understand the VME-bus addressing and address space, think of the device as consisting of two halves, master and slave. When the CPU accesses the address space of a device, the device acts as a VME slave. When the VME device accesses main memory through direct memory access operations, the VME device acts as a VME master.|
In the Onyx and POWER Onyx systems, a DMA address from a VME controller goes through a two-level translation to generate an acceptable physical address. This requires two levels of mapping. The first level of mapping is done through the map RAM on the IO4 board. The second level is done through the map tables in system memory. This mapping is shown in Figure E-4.
|Note: The second level mapping requires system memory to be reserved for the mapping tables. The current limit on the number of pages that is allocated for map tables is 16 pages and the maximum memory allotted for the map tables is 64 KB. The R4400 provides a 4 KB page size for 16 pages |
(4 KB * 16 pages= 64 KB). The R8000 provides an 8 KB page size for 8 pages (8 KB * 8 pages = 64 KB).
The R4400 pointer size is 4 bytes and the R8000 pointer size is 8 bytes. There are 1K mapping entries for the R4400 for each page and 8K mapping entries in the R8000. In the R4400, if you divide the amount of memory allocated for the map tables (64 KB) by the pointer size (4 B) and then multiply it by the page size (4 KB), you derive 64 MB of VME DMA mapping. This is the maximum allowed by IRIX. The 64 MB address space applies to the R8000, as well.
Referring to the top of Figure E-4, bits 32 and 33 from the IBus address come from the VMECC. These two bits determine a unique VMEbus number for systems with multiple VMEbusses. Of the remaining 32 bits (31 to 0), 12 are reserved for an offset in physical memory, and the other 20 bits are used to select up to 220 or 1 million pages into the main memory table. However, as stated earlier, only 64 KB is allocated for map tables.
As shown in Figure E-4, 13 bits go to the static RAM table. Recall that two of the thirteen bits are from the VMECC to identify the VMEbus number. The static RAM table then generates a 29-bit identifier into the main memory table. These 29 bits select a table in the main memory table. An additional 9 bits select an entry or element within the table. A 00 (two zeros) are appended to form a 40-bit address into the main memory table.
The main memory table then generates 28-bit address which is then appended to the 12-bit offset of the IBus to form the final 40-bit physical address.
|Note: Address conflicts with other boards in the system should not be a problem as long as the drivers and the VME controllers adhere to the semantics for DMA mapping defined in the IRIX Device Driver Programming Guide (P/N 007-0911-xxx).|
This section describes the VMEbus operation for the following address and data cycles:
read-modify-write (issued only by the VMECC)
Table E-2 shows the word length conventions used in this document.
Table E-2. Word Length Conventions
Number of Bits
Double or long word
The write cycle begins when the master gets the bus and asserts WRITE*. The master places the address on the address bus (A01 to A31) and also places the address modifier on the bus (AM0 through AM5) to indicate the type of access and address space (for example A16, A24, A32, or A64). The address strobe (AS*) is then asserted to indicate a stable address.
The master then places the data on the data bus (D00 through D31) and asserts the data strobes DS0* AND DS1* and LWORD*. This combination determines the data size (for example, D32, D16, or D8).
The slave takes the data and responds by asserting the DTACK* line. When the master releases the data strobes, (DS0* and DS1*), the slave releases DTACK* and the cycle is completed, as the AS* signal is released. If a mismatch in the data transfer size or other errors occur, the slave asserts BERR* and the bus error terminates the cycle.
The read cycle is the same as the write cycle except that the slave places the data on the data bus (D00 through D31) in response to data strobes and long word combinations (DS0, DS1, and LWORD) from the host CPU. The slave asserts DTACK* when the data is driven and the master reads it. The master then releases the strobe and the slave releases DTACK* and AS, and the cycle is completed.
The read-modify-write (or RMW) allows a master to read data, modify it, and write it back without releasing the bus. This bus cycle allows users to read and change the contents of a device register or memory location in a single atomic operation. Although this feature is typically used to implement synchronization primitives on VME memory, you may occasionally find this feature useful for certain devices.
|Note: Silicon Graphics products do not support VME read-modify-write operations initiated by a VME master to host memory.|
The VME bus supports seven levels of prioritized interrupts, 1 through 7 (where 7 has the highest priority). The VMECC has a register associated with each level. When the system responds to the VMEbus interrupt, it services all devices identified in the interrupt vector register in order of their VMEbus priority (highest number first). The operating system then determines which interrupt routine to use, based on the interrupt level and the interrupt vector value.
|Note: On systems equipped with multiple VME buses, adapter 0 has the highest priority; other adapters are prioritized in ascending order (after 0).|
No device can interrupt the VME bus at the same level as an interrupt currently being serviced by the CPU because the register associated with that level is busy. A device that tries to post a VMEbus interrupt at the same VMEbus priority level as the interrupt being serviced must wait until the current interrupt is processed.
|Note: All VME interrupt levels map into one CPU interrupt level through IRIX.|
The following text and Figure E-5 outline, how a VMEbus interrupt is generated.
A VME controller board asserts a VME interrupt.
The built-in interrupt handler in the VMECC chip checks if the interrupt level is presently enabled by an internal interrupt mask.
The interrupt handler in the VMECC issues a bussed IACK (interrupt acknowledge) response and acquires the vector from the device. The 3-bit response identifies one of the seven VME addresses.
|Note: Once an interrupt is asserted and the bus is granted to the handler, a 3-bit code that identifies the interrupt level being acknowledged is placed on address bits 1 to 3 and IACK* and AS* are asserted.|
If multiple VME boards are present, the bussed IACK signal is sent to the first VME controller as an IACKIN. As shown in Figure E-5, since the first controller is not the requesting master, it passes the IACKIN signal to the next board (in the daisy chain) as IACKOUT.
|Note: Each board compares the interrupt level with the interrupt level it may or may not have asserted. If the board did not generate an interrupt, or if the interrupt level does not match its own level, the board passes on the IACKOUT signal to the next board.|
In addition, the board closest to the master IO4 normally wins access to the bus.
The requesting board responds by issuing a DTACK* (data acknowledge signal), blocking the IACKOUT signal to the next board in line (if present), and placing an 8-bit status word on the data bus.
After acceptance and completion through the VMECC, the interrupt signal is sent over the FCI interface to the F-chip and is queued awaiting completion of other F-chip tasks.
The F-chip (or F controller ASIC) requests the I-bus and sends the interrupt to the IA chip.
The IA chip requests the Ebus and sends the interrupt over the Ebus to the CC chip on the CPU board.
The CC chip interrupts the microprocessor, provided that the interrupt level is not masked.
While the interrupt handler is executing, it prevents another interrupt at an equal or lower level from being serviced. Furthermore, all pending interrupts that are equal to or higher than the priority of a new interrupt must complete execution before the new interrupt is serviced.
The time for this to complete is normally less than 3 microseconds, but will be queued to await completion of other VME activities.
VME boards have two methods of interrupt acknowledge:
release on acknowledge of interrupt
release on register acknowledge of interrupt
The first release policy is where the interrupting device removes the IRQ request once the VMECC acknowledges the interrupt. In other words, the VME board assertion of the IRQ line is dropped when the board transfers its interrupt vector to the VMECC.
The second release policy occurs when the interrupting VME board does not drop the IRQ line the until a register on the board has been accessed or modified. Therefore, after the interrupt vector has been transferred, the device still asserts IRQ.
The following outlines VME interrupt problems that could result in VME interrupt error messages, such as: WARNING: stray VME interrupt, vector=0xff.
Noise occurs on one of the IRQ lines. If the noise pulse (signal) is wider than 20 ns, then the VMECC attempts to issue an IACK cycle. If the signal is just noise and not an actual interrupt, no expectant response to the IACK takes place. This lack of a response from a VME board results in a timeout causing the VMECC issues an eventual error message.
A VME board accidentally asserts an IRQ line and doesn't respond.
One of the boards in front of the requesting board improperly blocks the IACKIN signal and doesn't respond.
The VMECC responds only to those interrupt levels that it is configured to recognize. You can therefore prevent the VMECC from responding to particular interrupt levels. For example, if the kernel is configured to have two VME devices configured at ipl=3 and 4, then the VMECC responds to interrupt levels 3 and 4 only. The VMECC does not respond to any other interrupt levels, thereafter.
The VMEbus supports two arbitration schemes priority and round robin. The VMECC designates the highest priority to its internal bus masters, the interrupt handler and the PIO master. These two bus masters have a higher priority than the four backplane request levels (BRQ3 through BRQ0). BRQ3 has the highest priority level. BRQ2 through BRQ0 use round-robin arbitration.
The master relinquishes the bus based on an internal policy of release on request or release when done. Most VME masters can set their arbitration scheme through jumper selectors or by software.
In round-robin scheduling, the arbitration keeps track of the history of the bus grants to different levels. The last bus request level to have the bus becomes the lowest priority. For example, if the bus current request level is 1, all bus request level 1s are pushed back to the end of the queue, after a bus grant. The bus request level that is adjacent to the lowest priority then becomes the highest priority.
As an example, at a given time, say that level 3 is currently the highest priority. After a bus grant takes place, level 3 then becomes the lowest priority, and level 2 (since it was previously adjacent to level 3) is now the highest bus level priority.
This section defines physical and electrical parameters for implementing VMEbus boards and also provides VMEbus slot-specific information for the Onyx and POWER Onyx systems.
The Onyx board slots have a 9U (vertical) form factor and measure 15.75 inches (400 mm) horizontally. The board edges must also be less than or equal to 0.062 inches (1.57 mm). If the board is thicker, the edge of the board must be milled to fit in the card guide. In addition, center-to-center board spacing is 0.8 inch (20.3 mm).
The deskside Onyx RealityEngine2 provides three 9U VME slots. The system supplies approximately 40 watts of +5-V power per VME slot (nominally). You may use up to a maximum of 150 watts of +5-V power if you follow the rules in the next sections carefully. The system also provides approximately 0.5 amps (or 6 watts) of +12 V per VME slot. The VME power for the Onyx deskside InfiniteReality or i-Station system (see Table E-4), is variable. Depending on the line voltage and type of power boards used, the VME wattage available may be greater or less than that in RE2.
Table E-3 shows an example of wattage used by two different Silicon Graphics VME-based boards. Using both of these boards in the Onyx deskside system (at the same time) would exceed the alloted maximum VME wattage for most deskside Onyx systems (see Table E-4).
Table E-3. Deskside Onyx VME Power Use Example
Watts used at +5 V
VME Watts Available for Other Boards
VME Sirius (VO2)
Table E-4. Onyx InfiniteReality and i-Station VME Power
Configuration, Voltage, and Power Boards Used
Total +5V Available for VME and IO4 mezz boards[a]
Total +12V Available for VME boards
110VAC with 1 RM6 using two 303s and a 512T
26 amps (130 watts)
5.7 amps (68 watts)
110VAC with 1 RM6 using a 303, a 305, and a 512T
34 amps (170 watts)
5.7 amps (68 watts)
220VAC with 2 RM6s using two 303s and a 512T
26 amps (130 watts)
5.7 amps (68 watts)
220VAC with 2 RM6s using a 303, a 305, and a 512T
86 amps (430 watts)
5.7 amps (68 watts)
[a] You should assume an average use of 25 watts for each IO4 mezzanine board installed.
|Note: Power output is insufficient using 100V Japanese line voltages. Only 220V InfiniteReality or i-Station systems are supported for use in Japan.|
The deskside chassis circulates approximately 150 to 250 linear feet per minute (LFM) of air flow through the chassis (depending on the ambient temperature).
If a VME board requires more than the normal slot power allotment (approximately 40 watts of +5-V power per slot), the board still can be used, providing that the following cooling and power guidelines are met.
|Caution: Be sure to check the VME board's installation or user's guide for information on +5-V wattage required. Subtract that number from VME watts available for use. Never install a combination of boards that exceeds the available wattage limit.|
The user needs to ensure that the board has the proper air flow (for cooling purposes) and sufficient available power. To help maintain proper cooling (according to manufacturer's specifications), the board may need special custom baffles or a set of non-component enclosure boards to surround the VME board with sufficient air flow.
|Note: These custom air flow devices must be supplied by the customer.|
To use a third-party VME board that requires more than the normal VME slot power, be sure to observe these guidelines:
The board does not draw more than the amount of power allocated for VME board use.
The board does not exceed the power rating for the VME pins (approximately 200 watts).
The board uses all three “P” connectors on the system backplane, the P1, P2, and P3. (See Table E-7 through Table E-9 for pinout information.)
If these guidelines are followed along with the proper cooling requirements, a single VME board can draw as much as 150 watts of +5-V power.
For example, you can install two 75-watt VME boards in a deskside system (providing the boards were sufficiently cooled). However, as a result, you could not install any additional VME boards, since the VME power allotment would be saturated. In addition, it is also possible to use a single 150-watt VME board, providing the remaining VME slots are also not used.
Table E-5 and Figure E-6 show the board slot locations for RealityEngine2 and VTX Onyx deskside systems.
Table E-5. Onyx RealityEngine2 and VTX Deskside Board Slot Locations
IO4 base board (Note: An IO4 must reside in slot 3.)
GE10 (Geometry Engine) board
DG2 (Display Graphics) board
Third or fourth RM4 (Raster Manager) board
Second RM4 (Raster Manager) board
Third or fourth RM4 (Raster Manager) board
First RM4 (Raster Manager) board
Table E-5 and Figure E-7 show the slot assignments for InfiniteReality and i-Station deskside systems.
Table E-6. Onyx InfiniteReality and i-Station Deskside Board Slot Locations
IO4 base board (Must be F3-based)
GE12 (Geometry Engine) board
First RM6 (Raster Manager) board
Second RM6 (Raster Manager) board
DG4 (Display Graphics) board
Table E-7 through Table E-9 list the pin assignments of the VME P1, P2, and P3 connectors. Table E-10 describes the pin signals.
|Note: No connections are made to rows A and C of connector P2. These lines are not bussed across the backplane. The P3 connector uses the Sun power convention. In addition, the Onyx system does not generate ACFAIL* or SYSFAIL*. The SERCLK and SERDAT* are also unused.|
The Onyx system supplies the defined voltages to the bus, also asserts SYSREST*, and drives SYSCLK (SYSCLK is driven at 16 MHz).
On the Onyx backplanes, the unused VME pins are no connects.
|Caution: The Onyx system does not support VSBbus boards.|
Table E-7. P1 VME Pin Assignments
Table E-8. P2 VME Pin Assignments
Row B a
[a] This row of pins is user defined.
Table E-9. P3 VME Pin Assignments
1 through 25
30 through 32
|Note: In the Onyx VME backplanes, P3B is used for Silicon Graphics purposes.|
Table E-10. Signal Definitions
D00 through D31
Data lines. These lines are tri-stated and are not defined until the data strobes (DS0* and DS1*) are asserted by the MASTER.
A00 through A31
Address lines. These lines are tri-stated and are not defined until the address strobe (AS*) is asserted by the MASTER.
AM0 through AM5
Address modifier lines. Asserted by the MASTER and indicate the type of data transfer to take place. VME SLAVEs look at the lines to determine if they will respond and what type of response to make.
Data Strobe lines. Asserted by the MASTER and indicates stable data on the data bus.
Address strobe. Asserted by the MASTER and indicates a stable address is present on the address lines.
BR0 through BR3
Bus request lines. MASTER request a busy bus via these prioritized levels.
BG0IN through BG3IN
Bus grant in (daisy-chained).
BG0OUT through BG3OUT
Bus grant out (daisy-chained).
Bus clear. (Hint to bus master: VME MASTERs are not required to comply.)
IRQ1 - IRQ7
Interrupt request lines.
Interrupt acknowledge. Asserted by MASTER to indicate the VME interrupt level to be serviced.
Interrupt acknowledge in (daisy-chained).
Interrupt acknowledge out (daisy-chained).
Data transfer acknowledge. Asserted by SLAVE to indicate a successful bus transfer.
Write not or read.
Indicates long word transfer (D32).
16 MHz system clock. (Does not control bus timing.)
Serial data clock.
Serial data line.
Bus error line.
Indicates a board has failed.
AC power failure notify line.
Reset signal for VME bus.
Skipping a slot is occasionally required to fit oversized VME boards or to improve air flow. A slot can be skipped if jumper blocks are placed on the appropriate VME jumper block pins.
|Note: The general guideline is to insert jumpers into the jumper banks corresponding to the VME slot number that you are skipping. For example, if you are skipping the first VME slot, you need to insert jumpers into jumper bank 1. See the following additional examples:|
If you are skipping the first VME slot (slot 5 in an Onyx deskside system) to use the next VME slot, you must place five jumpers in the jumper bank, designated as slot 1 (see Figure E-8).
If you are skipping the first two VME slots and wish to use the third VME slot, you must place jumpers in jumper banks 1 and 2.
If you wish to skip over VME slots, for example, from the first VME slot over to the third VME slot, you must place jumpers in bank 2.
This section provides design guidelines for implementing third-party VME boards. Be sure to observe these general rules to avoid possible damage to the VMEbus and system.
Devices should require 8-bit interrupt vectors only. This is the only interrupt vector size that is recognized by the IRIX kernel.
Devices must not require UAT (unaligned transfers or tri-byte) access from the Onyx system.
Devices in Slave mode must not require address modifiers, other than Supervisory/Nonprivileged data access.
While in VME Master mode, devices must access the system memory using only Nonprivileged data access or Nonprivileged block transfers.
Devices must have the ability to be configured so that their address range does not conflict with those used by the Onyx system. The device should also be able to respond to addresses generated by the system. See the /var/sysgen/system/irix.sm file for acceptable ranges.
The Onyx system does not support VSBbus boards. In addition, there are not pins on the back of the VME backplane. This area is inaccessible for cables or boards.
Be sure to place boards starting in the first VME slot, or jumper the daisy-chained signals across the empty slots. Otherwise, this will break the interrupt acknowledge and bus arbitration schemes.
Metal face plates or front panels on VME boards may need to be removed. The plate could prevent the I/O door from properly closing and possibly damage the I/O bulkhead.
|Note: In some VME enclosures, these plates supply the required additional EMI shielding. However, the Onyx chassis already provides sufficient shielding for boards inside the chassis, so these plates are not necessary.|
This section presents basic timing numbers to aid in designing a VME bus master for the Onyx and POWER Onyx systems.
The first word of a read is delivered to the master in 3 to 8 microseconds. The first word of a write is retrieved from the master in 1 to 3 microseconds.
The VME spec has a burst length of 265 bytes in D08, D16, and D32 modes, and 2 KB in D64.
The Onyx hardware has a 20-bit counter for a burst length of 2 MB in all sizes. The burst length occurs in bytes and not transfer cycles.
Figure E-9 illustrates the VME handshake.
Parts 1 and 3 are controlled by the slave, the Onyx or POWER Onyx workstation hardware.
Parts 2 and 4 are controlled by the master, the VME controller board.
|Note: Part 1 is approximately 40 ns and Part 3 is approximately 20 to 25 ns. The total Onyx and POWER Onyx contribution is about 60 to 65 ns.|
The F controller does the mapping from A32 mode into system memory and automatically crosses the page boundaries. You do not have to have AS go high and then low on 4 KB boundaries.
If you use A64 addressing, then you may have to change the address on the 4 KB boundaries and cause a transition on AS low to high, and then back to low. This incurs the delays mentioned at the beginning of this section, “Design Guidelines.”
|Note: The delays are averages and may occasionally be longer. The system design does not have any guaranteed latency. For this reason, longer transfers are better than shorter ones. If you decide to exceed the VME bus specifications, it is recommended that you place a field in a control register on your VME board that enables or disables this feature. This allows you to put the board in standard mode so it can be used on other VME systems.|
 64-bit data transfers, accesses, and memory addresses do not depend on a 64-bit IRIX kernel, so they can be mapped to all MIPS R4000 and R8000 series platforms.