The VME (versa modular European) interface in the Challenge and POWER Challenge system supports all protocols defined in Revision C of the VME specification, plus the A64 and D64 modes defined in Revision D. For the acceptable VME address ranges, read the /var/sysgen/system/irix.sm file.
 | Note: The Challenge systems do not support VSBbus mode. In addition, unless otherwise stated, the term Challenge refers to both the Challenge and POWER Challenge systems. |
 | Warning: All board installations or removals should be performed only by personnel certified by Silicon Graphics. Unauthorized access to the cardcage area could result in system damage, or possible bodily harm, and could void the warranty for the system. |
This appendix provides information to help users integrate third-party VME boards into the Challenge and POWER Challenge rackmount systems. The information is divided into four major sections.
“VMEbus Architecture and Interface,” provides a detailed discussion of the VMEbus architecture in the Challenge 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 pin assignments, the VME slots, and VME backplane jumpering.
“Accessing Multiple VMEbuses,” discusses the multiple VMEbus capability with the optional cardcage 3.
“VMEbus Board Design Considerations,” provides third-party VME board design considerations and guidelines.
| Note: This appendix primarily provides VMEbus hardware-related information. For software-related information on VMEbus implementation, consult the IRIX Device Driver Programming Guide (P/N 007-0911-xxx). |
The VMEbus interface circuitry for the Challenge and POWER Challenge 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 cardcage (see Figure E-1). The VCAM is located on the master IO4 (in slot 15) and provides the VME connection for cardcage 2.
The IO4 board is the heart of the I/O subsystem. It 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 Interconnects (FCIs) for connection to the CC3
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 CHALLENGE/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) ASICs. 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 (if applicable) and any VMEbus boards in optional CC3 applications. 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.
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
A 16-entry deep PIO FIFO to smooth writing to the VMEbus from the host CPUs
A built-in VME interrupt handler and built-in VMEbus 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
Size
Term
A16 and D8 modes
Short
A24 and D16 modes
Standard
A32 and D32 modes
Extended
A64 and D64 modes
Long
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) take 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 flat cable interfaces (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); 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.
Both 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 Challenge and POWER Challenge 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/from main memory
The VMEbus 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.[1]
The VMEbus 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 VMEbus allows the master to broadcast addresses at any of these sizes. The VMEbus 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 Challenge and POWER Challenge systems, a DMA address from a VME controller goes through a two-level translation to generate an acceptable physical address for the R4400, R8000, and R10000. 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.
The second level mapping requires system memory to be reserved for the mapping tables. The 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 1 K mapping entries for the R4400 for each page and 8 K 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.
In the R10000 processor, the size of each page may be selected from a range between 4 KB to 16 MB, inclusive, in powers of 4 (that is, 4 KB, 16 KB, 64 KB, and so on). The virtual address bits that select a page (and thus are translated) are called the page address.
Page size is defined in each TLB entry's PageMask field. This field is loaded or read using the PageMask register (see the R10000 Microprocessor User's Manual from MIPS Technology for additional information). Translations are maintained by the operating system using page tables in memory. A subset of these translations are loaded into a hardware buffer called the translation-lookaside buffer or TLB.
The contents of this buffer are maintained by the operating system; if an instruction needs a translation which is not already in the buffer, an exception is taken so the operating system can compute and load the needed translation. If all the necessary translations are present, the program is executed without any delays.
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 VMEbuses. 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 2 of the 13 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) is appended to form a 40-bit address into the main memory table.
The main memory table then generates a 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:
write (non-block)
read (non-block)
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
Parameter | Number of Bits |
|---|---|
Byte | 8 bits |
Half-word | 16 bits |
Word | 32 bits |
Double or long word | 64 bits |
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 VMEbus 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 VMEbuses, adapter 0 has the highest priority; other adapters are prioritized in ascending order (after 0). |
No device can interrupt the VMEbus at the same level as an interrupt 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 steps and Figure E-5 outline how a VMEbus interrupt is generated.The step numbers correspond to the ordered numbers in the figure.
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 bused IACK (interrupt acknowledge) response and acquires the vector from the device. The 3-bit response identifies one of the seven VME address.
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 bused 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 Ibus 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 IP19/IP21 board.
The CC chip interrupts the R4400/R8000, 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 until a register on the board has been accessed or modified. Therefore, after the interrupt vector has been transferred, the device still asserts IRQ.
These VME interrupt problems can 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 expected response to the IACK takes place. This lack of a response from a VME board results in a timeout, causing the VMECC to issue 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 level, 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 provides VMEbus slot-specific information for the Challenge and POWER Challenge systems.
The Challenge 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 into the card guide. In addition, the center-to-center board spacing is 0.8 inch (20.3 mm).
| Note: If you wish to install a 6U form-factor VMEbus board into the system, you need to obtain a 6U-to-9U converter board from Silicon Graphics. See “Using a 6U-to-9U Converter Board”, for further information. |
Cardcage 2 (CC2) provides five 9U VME board slots and receives 1000 watts of 5 VDC power (see Table E-3) from the system. Approximately 200 watts of the 5 VDC power are reserved for the VME boards. Nominally, 40 watts are allowed per each of the five VME slots in cardcage 2. However, it is possible to exceed this power rating. See “Exceeding the Nominal VME Power Rating Per Slot” for further information
Cardcage 2 also receives approximately 200 to 250 linear feet per minute (LFM) of air flow.
| Note: There are no VME slots in cardcage 1 in the Challenge or POWER Challenge systems. |
The IO4, VCAM, and mezzanine boards all draw their power from the same source as the VME cards. The CPU boards (such as the IP19) and the MC3 memory boards draw 48 V power directly from the OLS's, and do not compete for power directly with the IO4, VCAM, mezzanine, and VME boards.
Table E-3. Power Specifications for Cardcage 2
Category | Parameter |
|---|---|
Total 5 V power available | 1000 watts |
Total 12 V power available | 200 watts |
Each IO4 draws | 64 watts (5 V); 20 watts (12 V) |
VCAM | 35 watts (5 V); 24 watts (12 V) |
Backplane requirement | 50 watts (5 V) |
Cardcage 3 (CC3), which is optional on the Challenge XL rackmount system, supplies up to 20 additional VME slots (see Figure E-8). The CC3 provides approximately 70 W of +5 V power per VME slot. This assumes the presence of three 505 power boards and one 512 power board (see Figure E-6). The power boards are included with the optional CC3 upgrade. Cardcage 3 also receives approximately 200 to 250 LFM of air flow through the chassis.
| Note: The CC3 provides the capability of having multiple VMEbuses for improved system throughput. See “Accessing Multiple VMEbuses”, for further information. |
Table E-4. Power Specifications for Cardcage 3
Category | Parameter |
|---|---|
Total 5 V power available | 1400 watts |
Total 12 V power available | 200 watts |
Remote VCAM | 35 watts (5 V); 24 watts (12 V) |
Backplane requirement | 50 watts (5 V) |
Use the information in Table E-3 and Table E-5 to help determine the power budget for your system. With this information, you should be able to calculate the power available for VME cards in your particular configuration, as required.
Table E-5. 5 VDC Power Consumption Chart for Various System Boards
Board Type | Power Consumption at 5 VDC |
|---|---|
Master IO4 board and VCAM | 130 watts |
Slave IO4 board | 47 watts |
Slave IO4 board with 2 Asynchronous Transfer Mode (ATM) mezzanine boards | 121 watts |
S1 mezzanine board | 20 watts |
SCIP mezzanine board | 20 watts |
F-chip mezzanine board | 35 watts |
FDDI mezzanine board | 25 watts |
ATM board | 37 watts |
HIPPI board | 75 watts |
As mentioned earlier, cardcage 1 has no available VME slots. See Figure E-7 and Figure E-8 for the location of the VME slots in cardcage 2 and the optional cardcage 3.
If a VME board requires more than the nominal slot power allotment (approximately 40 watts of +5 V power per slot in CC2 or approximately 70 watts in a cardcage 3), the board still can be used providing that the following cooling and power guidelines are met.
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-6 through Table E-8) 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.
In cardcage 2, you can install two 75-watt VME boards (providing the boards are sufficiently cooled). However, as a result, you cannot install any additional VME boards, since the VME power allotment would already be saturated. It is also possible to use a single 150-watt VMEbus board in cardcage 2, providing the remaining VME slots are not used.
In cardcage 3, you can install up to nine 150-watt boards, assuming that all potential power boards (three 505 and one 512) are installed (see Figure E-6). However, as a result, the remaining VME slots cannot then be used.
Table E-6 through Table E-8 list the pin assignments of the VME P1, P2, and P3 connectors. Table E-9 describes the pin signals.
| Note: No connections are made to rows A and C of connector P2. These lines are not bused across the backplane. The P3 connector uses the Sun power convention. In addition, the Challenge system does not generate ACFAIL* or SYSFAIL*. The SERCLK and SERDAT* are also unused. |
The Challenge system supplies the defined voltages to the bus, asserts SYSREST*, and drives SYSCLK (SYSCLK is driven at 16 MHz).
On the Challenge backplanes, the unused VME pins are no connects.
 | Caution: The Challenge system does not support VSBbus boards. |
Table E-6. P1 VME Pin Assignments
Pin | Row A | Row B | Row C |
|---|---|---|---|
1 | D00 | BBSY* | D08 |
2 | D01 | BCLR* | D09 |
3 | D02 | ACFAIL | D10 |
4 | D03 | BG01N* | D11 |
5 | D04 | BG0OUT* | D12 |
6 | D05 | BG1IN* | D13 |
7 | D06 | BG1OUT* | D14 |
8 | D07 | BG2IN* | D15 |
9 | GND | BG2OUT* | GND |
10 | SYSCLK | BG3IN* | SYSFAIL* |
11 | GND | BG3OUT* | BERR* |
12 | DS1 | BR0* | SYSRESET* |
13 | DS0 | BR1 | LWORD* |
14 | WRITE* | BR2* | AM5 |
15 | GND | BR3* | A23 |
16 | DTACK* | AM0 | A22 |
17 | GND | AM1 | A21 |
18 | AS* | AM2 | A20 |
19 | GND | AM3 | A19 |
20 | IACK* | GND | A18 |
21 | IACKIN* | SERCLK | A17 |
22 | IACKOUT* | SERDAT* | A16 |
23 | AM4 | GND | A15 |
24 | A07 | IRQ7* | A14 |
25 | A06 | IRQ6* | A13 |
26 | A05 | IRQ5* | A12 |
27 | A04 | IRQ4* | A11 |
28 | A03 | IRQ3* | A10 |
29 | A02 | IRQ2* | A09 |
30 | A01 | IRQ1* | A08 |
31 | -12V | +5VSTDBY | +12V |
32 | +5V | +5V | +5V |
Table E-7. P2 VME Pin Assignments
Pin | Row A (Note: This row is user-defined.) | Row B | Row C (Note: This row is user-defined). |
|---|---|---|---|
1 |
| +5V |
|
2 |
| GND |
|
3 |
| RESERVED |
|
4 |
| A24 |
|
5 |
| A25 |
|
6 |
| A26 |
|
7 |
| A27 |
|
8 |
| A28 |
|
9 |
| A29 |
|
10 |
| A30 |
|
11 |
| A31 |
|
12 |
| GND |
|
13 |
| +5V |
|
14 |
| D16 |
|
15 |
| D17 |
|
16 |
| D18 |
|
17 |
| D19 |
|
18 |
| D20 |
|
19 |
| D21 |
|
20 |
| D22 |
|
21 |
| D23 |
|
22 |
| GND |
|
23 |
| D24 |
|
24 |
| D25 |
|
25 |
| D26 |
|
26 |
| D27 |
|
27 |
| D28 |
|
28 |
| D29 |
|
29 |
| D30 |
|
30 |
| D31 |
|
31 |
| GND |
|
32 |
| +5V |
|
Table E-8. P3 VME Pin Assignments
Pin | Row A | Row B | Row C |
|---|---|---|---|
1 through 25 | +5 V | Not connected | GND |
26, 27 | +12 V | Not connected | +12V |
28, 29 | -12 V | Not connected | -12V |
30 through 32 | -5 V | Not connected | -5V |
| Note: In the Challenge VME backplanes, P3B is used for Silicon Graphics purposes. |
Signal Name | Definition |
|---|---|
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. |
DS0, DS1 | Data Strobe lines. Asserted by the MASTER and indicate stable data on the data bus. |
AS | Address strobe. Asserted by the MASTER and indicates a stable address is present on the address lines. |
BR0 through BR3 | Bus request lines. MASTER requests a busy bus via these prioritized levels. |
BG0IN through BG3IN | Bus grant in (daisy-chained). |
BG0OUT through BG3OUT | Bus grant out (daisy-chained). |
BBSY | Bus busy. |
BCLR | Bus clear. (Hint to bus master: VME MASTERs are not required to comply.) |
IRQ1 - IRQ7 | Interrupt request lines. |
IACK | Interrupt acknowledge. Asserted by MASTER to indicate the VME interrupt level to be serviced. |
IACKIN | Interrupt acknowledge in (daisy-chained). |
IACKOUT | Interrupt acknowledge out (daisy-chained). |
DTACK | Data transfer acknowledge. Asserted by SLAVE to indicate a successful bus transfer. |
WRITE | Write not or read. |
LWORD | Indicates long word transfer (D32). |
SYSCLK | 16 MHz system clock. (Does not control bus timing.) |
SERCLK | Serial data clock. |
SERDAT | Serial data line. |
BERR | Bus error line. |
SYSFAIL | Indicates a board has failed. |
ACFAIL | AC power failure notify line. |
SYSRESET | Reset signal for VMEbus. |
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: If you install the VME boards in order (from left to right), then no jumpering is required. In addition, if you have no VME boards installed, you do not need to install any jumpers. |
The general guideline is to have jumpers in the jumper banks correspond to the VME slot number that you are skipping (see Table E-10). For example, if you are skipping VME slot 17, you need to insert five jumpers into jumper bank 1 (see Figure E-9).
Table E-10. Correspondence of VME Jumpers to VME Slots
Jumper Bank | Cardcage 2 VME Slot |
|---|---|
1 | 17 |
2 | 18 |
3 | 19 |
4 | 20 |
See the following examples:
If you are skipping the first two VME slot and wish to use the third VME slot, you must place jumpers in jumper banks 1 and 2 (see Figure E-9).
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 (see Figure E-10).
The optional cardcage 3 VMEbus backplane does not have jumper banks as the midplane does. Skipped VMEbus slots in cardcage 3 are jumpered using PCA CC3 VME jumper board (p/n 030-0516-001) from the cardcage side.
| Caution: You must install this board only in the top VME connector, P1, or damage may occur to the system. Bus jumpers are signals on the P1 connector. |
Some third-party VMEbus boards have a 6U form factor and require a Silicon Graphics 6U-to-9U converter (or extender) board assembly to be used in the Challenge or POWER Challenge system (see Figure E-11).
| Note: Contact your Silicon Graphics sales office to obtain a 6U converter board (p/n 030-0519-001). |
The cardcage 3 (CC3) option allows access to up to four additional VMEbuses on a Challenge and POWER Challenge system to help increase overall system throughput.
| Note: The system can have a maximum of five VMEbuses (four from the third cardcage option, plus the primary VMEbus). |
Your system must already have the cardcage 3 (CC3) option and other associated hardware installed, before you can access multiple VMEbuses. If you do not know whether your system has been configured with the CC3 option, type hinv at an IRIX prompt. You should get a display similar to the following:
VME bus: adapter 0 mapped to adapter 45 VME bus: adapter 37 VME bus: adapter 36 VME bus: adapter 45 |
| Note: The adapter numbers may be different in your system. |
The CC3 must be installed by a Silicon Graphics system support engineer (SSE). Contact your Silicon Graphics sales office to order this option.
If your system already has the CC3 option, and you wish to you add a third-party VME board on a secondary VMEbus, follow these guidelines.
As superuser, open the /var/sysgen/system/irix.sm file.
Locate the appropriate vector statement in the file. Be sure the board controller number matches the vector line you modify. See the following example:
VECTOR: bustype=VME module=jag ipl=1 ctlr=0 adapter=0 iospace=(A16S, 0, 0x800) probe_space=(A16S, 0, 1)
Note: During this procedure, you will change the adapter number (that is, adapter=0) to reflect the position of the F Mezz board on the IO4 board. The adapter number, 0, designates the primary bus in the midplane. Determine the slot position of the IO4 board that has the targeted
F Mezz board mounted on it using the hinv -v -b command. See Figure E-7 as required.Determine the adapter position(s) of the F Mezz board that you are using through the hinv -v -b command.
Translate the adapter position number into its corresponding virtual adapter number using Table E-11. For example, physical adapter 5 translates to position 2 and adapter 6 translates to position 3.
| Note: The software requires this virtual translation to help determine the corresponding VMEbus bank. |
You can now determine and change the adapter number (that is, adapter=0) in the vector statement by using the following formula and entering the values just derived:
adapter number = [IO4 slot# x (multiplied by) 4] + translated adapter_position
As an example, say you to wish to enable a separate VMEbus for VME boards attached through Short F Mezz board connector 6 on an IO4 board in slot 15. According to the formula, take the IO4 slot number 15, multiply it by 4, and then add the translated adapter position number 3 to obtain a value of 63.
Then change the default adapter number, 0 (that is, adapter=0) to a value of 63. This tells the driver where its controller can be found.
If applicable, remove the * (asterisk) from the desired vector line and edit the statement with the new adapter number value.
If you wish to add another VME device or enable another VMEbus, edit the next vector line with the desired adapter number.
Reboot the system. During power-on, you should see a message similar to the following:
... automatically reconfiguring the system ...
If you do not see this message, either the hardware was not properly configured or that the software file was not properly modified.
| Note: The hinv command does not display non-Silicon Graphics boards. |
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 Challenge system.
Devices in Slave mode must not require address modifiers, other than Supervisory/Nonprivileged data access.
While in VME Master mode, devices must only access the system memory using 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 Challenge 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 Challenge system does not support VSBbus boards. In addition, there are not any 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. If you don't place boards this way, the interrupt acknowledge and bus arbitration schemes breaks.
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 I/O bulkhead.
Note: In some VME enclosures, these plates supply the required additional EMI shielding. However, the Challenge 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 VMEbus master for the Challenge and POWER Challenge systems.
The first word of a:
read is delivered to the master in 3 to 8 μsec.
write is retrieved from the master in 1 to 3 μsec.
The VME spec has a burst length of:
265 bytes in D08, D16, and D32 modes
2 KB in D64 mode
The Challenge 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-12 illustrates the VME handshake.
Parts 1 and 3 are controlled by the slave, the Challenge and POWER Challenge hardware.
Parts 2 and 4 are controlled by the master, the VME controller board.
| Note: Part 1 is about 40 ns and Part 3 is about 20 to 25 ns. The total Challenge and POWER Challenge 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 VMEbus specifications, it is recommended that you place a field in a control register on your VME board that enables/disables this feature. This allows you to put the board in standard mode so it can be used on other VME systems. |
[1] 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.