Abstract: This article introduces the VICbus standard, applications, and the author's work in developing VICbus interface modules. Keywords: VICbus, VMEbus, tightly coupled multiprocessor system 1 Introduction VMEbus, a high-performance backplane bus for multiprocessor systems, is one of the most widely used buses in the computer field. With the expansion of multiprocessor systems, the need for tightly coupled connections between multiple VMEbus chassis has arisen. VICbus is a bus standard proposed to meet this requirement. It was jointly developed by CERN and CES Computer GmbH in Switzerland and became an international standard (ISO/IEC 26.11458) in 1993. Although VICbus was originally proposed as a standard for VMEbus chassis connections, with the expansion of its applications, it has become an interface bus for connecting various backplane buses. Currently, the following buses have implemented VICbus connections: VMEbus, Sbus (Sun Sparc workstations), NuBus (Macintosh microcomputers), EISAbus (IBM PC/AT microcomputers), FASTBUS, and CAMAC intelligent chassis controllers. These buses can be connected using the corresponding VICbus interface modules (i.e., circuit boards). Figure 1 shows an example of connecting different bus chassis using VICbus. In a VICbus system, one chassis is called one device, and up to 31 devices can be connected, numbered 1-31, which can be set by the panel switch of the interface module. In a VICbus system, the maximum working distance between devices is 100 meters, thus VICbus can be used to form a "distributed" tightly coupled system. 2. VICbus Bus Protocol VICbus is a 32-bit address/data multiplexed bus. It uses a flat cable consisting of 64 pairs of twisted pairs. Except for one pair used as ground, the remaining 63 pairs are differential signal lines. The bus can be functionally divided into the Data Transfer Bus (DTB), Arbitration Bus, Interrupt Bus, and Utility Bus. 2.1 Data Transmission Protocol VICbus is a 32-bit address/data multiplexed bus. Each data transmission consists of an address signal cycle and a data cycle. There are two data transmission modes: asynchronous (also known as forced mode) and synchronous (non-forced mode). In asynchronous mode, the WAIT signal is used as the slave device's acknowledgment signal to the master device. No acknowledgment is given during address strobe (AS), only after data strobe (DS). After address strobe, any amount of data, including mixed read and write operations, can be transmitted during the data cycle, but the address remains fixed. The slave device can use an internal address increment counter for block transfers. Synchronous data transmission is divided into two types: one is the so-called NC1 protocol. The master device directly enters the data signal cycle after the address signal cycle, without requiring any response from the slave device. This method is fast but less reliable and can only be used for "write" transfers from the master device to the slave device. The other synchronous data transmission protocol is the NC2 protocol. It uses a pipelined approach, employing a delayed slave device WAIT signal to respond to the master device. The WAIT signal is not used for timing; it is only used by the master device to confirm successful transmission. In this mode, a transmission can be either a read or a write. The signal lines used for data transmission are: AD31-AD00, for address/data lines; ID4-ID0, used to determine the slave device number (0-31); CL3-CL0, providing information about the protocol type and data byte alignment. 2.2 Bus Arbitration For cable-type buses, distributed arbitration cannot be used because the signal propagation time would be too long. VICbus uses the traditional Bus Request (BR)/Bus Enable (BG) mechanism and daisy-chain structure. Each master device in the system has an arbitrator function, operating in a rotating arbitration mode. When a master device gains bus control, it also gains bus arbitration rights. To achieve arbitrator rotation, the upstream device in the daisy chain must be able to receive the BG signal from the downstream current arbitrator. For this purpose, a BGLOOP signal line is used to connect the BGOUT terminal of the last device in the daisy chain to the BGIN terminal of the first device, forming a loop of the BG signal. When several devices in the system request the bus simultaneously, the current arbiter hands over bus control (and arbitration rights) to the nearest device that issued the BR bus request. The advantage of rotating arbitration is that it reduces the average arbitration time and prevents a single master device from excessively occupying the bus, while also avoiding system crashes due to the failure of a single arbiter. The bus has an "arbitration lock" (ALOCK) signal, which can be used to temporarily disable bus arbitration when a device dynamically joins or leaves the system connection. 2.3 Interrupts VICbus uses two 125kHz clock signals (named INTSEL0 and INTSEL1) to multiplex 32 interrupt request signals (MINT31-MINT0) onto 8 interrupt lines. That is, when INTSEL0 and INTSEL1 are 00, the 8 interrupt lines contain MINT0-MINT7 signals; when they are 01, they contain MINT8-MINT15 signals; when they are 10, they contain MINT16-MINT23 signals; and when they are 11, they contain MINT24-MINT31 signals. Each device can only send one interrupt request signal to the system. The response to the interrupt is through a dedicated "IACK" type DTB cycle. Many devices in the system can have INTSEL generators, but only one is active; this is called the system controller. If the current system controller fails, other devices immediately detect it and generate an ALOCK signal. When the ALOCK signal ends, each device with an INTSEL generator starts its own counter. If a device counts to a value equal to its device number, and no INTSEL signal appears on the bus, then that device's INTSEL generator starts working, becoming the system controller. Therefore, the device with the lowest device number in the system is always the system controller. The purpose of using multiplexed interrupts is to save on the number of bus signal lines. In VICbus, the functional module that issues an interrupt request is called an interrupt handler, and the module that receives and processes the interrupt request is called an interrupt processor. When one device needs to interrupt another, its interrupt handler sends an interrupt request signal to the bus. The interrupt handler designated to monitor this interrupt request can handle the interrupt in various ways, such as using a flag to generate a local interrupt, or transferring the interrupt vector from VICbus to the chassis's backplane bus. The interrupt vector can be 8-bit, 16-bit, or 32-bit; it is obtained from the data bus by the interrupt handler in IACK type data after receiving the interrupt request. 3 VICbus Interface Module Design During my time working in the Systems Department of CES in Switzerland, I participated in the development of the basic software for the VICbus interface module VIC8251 used for VMEbus. The following section provides a comprehensive introduction to the module's structure, working principle, software design, and existing problems. 3.1 Interface Functions of the VIC8251 Module The VIC8251 module can be functionally divided into many sub-modules. Among them, the sub-modules related to understanding the interface mainly include: VME master module, VME slave module, VIC master module, VIC slave module, VIC internal register module, MMU module, etc. Figure 2 illustrates the functions of the VIC8251 as a master device (chassis) interface and as a slave device (chassis) interface. When used as a master device interface, the VIC8251 displays one VME slave device and one VIC master device; when used as a slave device interface, it displays one VIC slave device and one VME master device. 3.2 VLC8251 Resources Figure 3 is an address mapping diagram of the VIC8251 register space, which only shows the parts we are interested in: the VIC master device control/status register of this module, the address table of the slave device register group of 31 devices in the whole system, and the page descriptor PD0/PD1 area used by the memory management unit (MMU) module. 3.2.1 The VIC master device CSR register group of this module uses four Zilog Z-CIO8536 chips. Chips 0 and 1 are used as master control/status registers to set various settings related to the VIC master device submodule, such as arbitration, arbitration requests, failure flags, and clearing, and to read mailbox flags, local memory (mirror memory) status information, etc. Chips 2 and 3 (Z-C108536) are used as VIC interrupt controllers to convert interrupt requests from the VICbus into VME interrupt requests from the local chassis. 3.2.2 Slave Device Register Address Table Each device chassis's VICbus module in the system has a set of slave device registers (VIC slave CSRs). The CSR1 register contains control/status information for the VIC slave device submodule of the VIC interface module, such as online status, arbitration and interrupt mode selection, broadcast and prefetch mode settings, and long/short cable mode selection. There are also an Online Status Register (OLR) and a Device Failure Status Register (DFR), which indicate the online/failure status of each device. Each bit in register RR is used to reset a device in the system. Returning to the VIC slave device submodule CSR register. Access can only be made via VICbus. Even for this set of registers within this interface module, the VIC master device submodule must be involved to set or read their status via VICbus. The slave device CSR address table maps the slave device CSR register addresses for the entire system (devices 0-31), as shown in Figure 4. Device 0 is used for broadcast setting. In the case where all devices in the VICbus system are VME chassis, broadcast setting can be used to set the same VIC slave device CSR for all slave devices in the entire system at once. 3.2.3 Page Descriptors PD0/PD1 The Memory Management Unit (MMU) uses PD0/PD1 to translate the VMEbus/VSBbus address (source address) of the master device chassis to the VMEbus/VSBus address (destination address) of the slave device chassis. The PD0 area is a 2Kx32b high-speed memory. A PD0 descriptor word contains information needed to complete one VIC cycle, such as access mode and mirror memory location (local, remote, or global). The PD1 area is a 2K×32b dual-port memory area. A PD1 descriptor word contains the target chassis device number, bits A31-A22 of the target address, and the AM code. The contents of PD0/PD1 are set during initialization as needed. The VIC8251 interface module of the master device chassis calculates the page number based on the source address received from the VMEbus. Then, based on the PD0/PD1 contents of that page number, it finds the device number of the target slave device and replaces the high-order bits of the source address with the high-order bits of the target address (A31-A22). This target address, along with the AM code, is then sent to the VMEbus of the slave device chassis via the VICbus. 3.2.4 The 4MB local memory of the VIC8251 is called mirror memory. It is a three-port memory accessible by VICbus, the local VMEbus, and VSBbus. It is paged in 4KB units, and each page is write-protected. The concept of mirror memory arose when a large data buffer needed to be shared by many processors distributed across several VME chassis. When a CPU writes data to its local mirror memory, this data is transparently broadcast to all devices in the VICbus system and simultaneously written to their respective mirror memories. When a CPU reads data from mirror memory, it only reads from its local mirror memory. That is, only the write cycle affects the entire system. This saves bus bandwidth, especially when using a synchronous write protocol (see Section 2.1). It can further improve the transmission rate; for a distance of 100 meters, a write rate of 10Mbytes/s and a read rate of 20Mbytes/s can be selected. 3.3 One method for implementing interrupts is as follows: After the VME interrupt request from the remote chassis is converted into a VIC interrupt request corresponding to its chassis number, it reaches the local chassis via the VICbus. The local VIC module then converts it into a VME interrupt request of a specified level and transmits it to the local VME master. The VME master performs a read operation on the VIACK register of the local VIC module, triggering an interrupt response signal. After conversion, it finally becomes the interrupt response signal VMEIACK from the remote VME. The remote VME then transmits the interrupt vector (STATUS/IC) to the local VME master for reading. Another method is to pre-set the interrupt vector values ​​for VIC interrupt requests numbered 1-31 in the interrupt controller of the local VIC module. After receiving the VIC interrupt request, the local VIC transmits the interrupt request to the local VME master, places the corresponding vector value in the local VMEbus for reading, and simultaneously sends an interrupt response signal to the remote VME. This method of providing the interrupt vector locally significantly shortens the interrupt response waiting time. 3.4 Each device added to the VICbus system must undergo complex initialization of its local chassis's VIC interface module, primarily involving the initialization of various resources in the register space described earlier. During initialization, the following aspects must be arranged system-wide to avoid conflicts: • Device number setting. • Address mapping relationship between each device and other devices, i.e., PD0/PD1 settings. • VIC slave device CSR settings for each device. This can be achieved by a single device (usually used as the system controller) setting all devices in the system at once, by each device adding to the system setting its own VIC slave device CSR, or a combination of both methods. 3.5 Application Software Design Considerations Due to the existence of two bus arbitration mechanisms in the system, an arbitration deadlock problem may occur, as shown in Figure 5. When the VME master device that has obtained VME bus control in the local chassis requests VIC bus control (VME cycle), if other devices simultaneously request VME bus control for this chassis via VICbus (VIC cycle), a deadlock occurs. When a deadlock occurs, the arbitration deadlock circuit of VIC8251 will stop the request of the local VME master and issue bus error (BERR) and retry (RETRY) signals on the VME bus. The application should be able to monitor the BERR and RETRY signals, handle the deadlock, give up the control of the VME bus, and let the remote VME master from VICbus control the local VME bus. Only after it finishes using and gives up the VME bus will the local VME master regain control of the VME bus and then request VICbus control. 4 Conclusion As a new bus standard, VICbus is still under development. At present, it is limited to the level of bus driver devices. The actual level that can be achieved is to connect 5 devices 100 meters apart and 24 devices 5 meters apart. VICbus was developed according to the needs of VME chassis interconnection, but in fact it is a general chassis cable bus. On the other hand, it also has good prospects as an interface bus between other backplane buses and VMEbus. This application is being explored. References [1] Vicbus Draft Specification VI l ISO／IEC 26.11458.1989 [align=center] INTER-CRATE BUS：VICBUS Liu Songqiang[/align] (University of Science and Technology of China, Hgfei 230027) Abstract: An introduction on the Inter-Crate Bus, i.e. VICbus (ISO／IEC 26.11485) standard, application and design of the bus interface module. Key words: VIC bus, VMEbus Tightly coupled multiprocessor system (Please click to download the original text: VICbus.pdf)