The iLBX bus is a standardized execution bus which, when used with the Mul-tibus system bus, provides an architectural extension of the MulMul-tibus system bus.
A diagram of a typical Multibus bus system utilizing the iLBX bus is shown in Fig. 5-2. The key features of the iLBX bus are:
• Standardized controlled interface
• 16M-byte local memory expansion
• 8- or 16-bit data transfers
172 THE MULTIBUS FAMILY OF BUS STRUCTURES
• Primary and secondary master support
• Mechanical fit with existing Multibus system bus chassis and backplanes The maximum transfer rate for the bus is 9.5M bytes per second for 8-bit data transfers and 19M bytes per second for 16-bit data transfers. The bus sup-ports two to five devices and has a total address space of 16M bytes.
The bus uses a master-slave data transfer approach in that the master initiates address and command information for the data transfer and the slave responds to this information. One of the five devices that the bus supports must be the master. One to four slaves can be added to the bus depending on system mem-ory requirements. Figure 5-3 shows an example of the iLBX bus with several slave memory devices attached to it.
The master initiates the transfer by placing address-status information on the bus and generating an address valid signal. If the master is writing data, it will then place data on the bus and generate a data valid signal. The addressed slave responds to the data valid signal by generating an acknowledge signal (to the master) after it has received the data. If the master was reading data from the slave, the addressed slave will generate the acknowledge after it has placed valid data on the bus. This is the same type of asynchronous interlocked transfer scheme that is used by the Multibus system bus and the Multichannel bus. The asynchronous handshake between the master and the slave allows devices of varying speeds to coexist on the same bus. Slave memory device 1 in Fig. 5-3 can have a slower or faster access time with respect to slave memory device 2 and still accurately transfer data with the master.
5.2. 1 Bus Devices
The bus supports three device categories as follows:
• Primary master
• Secondary master
• Slave
In the following section the requirements and attributes of each device are explained. The system requirements of these devices also will be explored.
PRIMARY MASTER
The primary master is responsible for controlling all transfers over the iLBX bus and controlling the secondary master's access to the bus. The iLBX bus must contain one and only one primary master. In Fig. 5-3 the primary master is shown driving the address, status, and control lines to the slave devices. During
.. ....
w
DATA CONTROL STATUS COMMAND TRANSFER ACKNOWLEDGE BUS REQUEST BUS
ACKNOWLEDGE
r
PRIMARY MASTER SECONDARY MASTER
FIGURE 5-3 iLBX bus system implementation,
(DBO-DBI5) (BHEN, LOCK.,R/W) (ASTB·, DSTB.) (ACK·) (SMRQ·) (SMACK·)
SLAVE 1 SLAVE 2
174 THE MULTIBUS FAMILY OF BUS STRUCTURES
a read data transfer the slaves are driving the data lines, and during a write data transfer the primary master is driving the data lines.
The primary master drives all address, status, and command lines for iLBX bus data transfers. The bus supports a simple bus exchange mechanism for one additional master called a secondary master. To support this simple bus exchange capability, the primary master must monitor the bus request signal from a secondary master and drive the bus grant acknowledge signal when it is ready to give up the bus. The primary master must also supply the termina-tion for the required iLBX bus signal lines. A typical primary master is a Mul-tibus system bus iSBC that also contains an iLBX bus interface.
An allowed subset of the bus is a primary master that does not support a secondary master. In this case the master is called a limited primary master.
Normally a limited primary master is chosen for a system to lower the cost. By not supporting a ~econdary master, the limited primary master can replace three-state drivers with normal TTL and also simplify its control logic. The limited primary master does not monitor the bus request signals, nor does it drive the bus grant acknowledge signal.
SECONDARY MASTER
In many applications the primary master cannot supply all the functions or the data movement bandwidth required. For these applications a secondary master is used. An example of a secondary master is a hard disk controller that is allowed access to the memory resources on the iLBX bus. The secondary master has the same control features as a primary master but cannot access the bus until the primary master gives it the bus. The secondary master's purpose is to provide alternate access to the iLBX bus. As its name implies, the secondary master must totally rely on the primary master for bus access. The primary master is not required to give up the bus until all its requirements have been met. A drawback to the secondary master is that it prevents the primary master from using the bus once it is given control of the bus. If a secondary master has a high utilization of the iLBX bus, it may prevent the bus from meeting its primary requirement, which is high bandwidth execution.
The iLBX bus specification limits the bus to one optional secondary master.
The limit of two masters simplifies the bus arbitration to a basi~ centralized request-grant scheme. When the secondary master requires the bus (Fig. 5-3), it asserts the bus request line. When the primary master is ready to give up the bus, it asserts the bus grant acknowledge signal. The secondary master may keep the bus while it continues to assert the bus request signal. Once it removes the bus request signal, it must turn off all bus drivers. When the secondary master controls the bus, it must actively drive all the signal lines (except the data lines on a data read and the bus grant acknowledge line) until it releases the bus to the primary master. The secondary master must not provide any termination to the iLBX bus lines.
SLAVE
Slave devices have the memory resources that the primary and secondary mas-ter require. The iLBX bus supports a maximum of four slave devices with a combined addressable space of 16M bytes.
The slave monitors the address lines for a valid address and, depending on the control lines, will either read data from the bus and place the data in the addressed memory location or write data to the bus from the addressed memory location. The bus utilizes a positive acknowledge interlocked handshake between the master and the slave. When the master is performing a data read operation, the slave will drive the acknowledge line when it places valid data on the bus, thereby permitting it to control the access time. That is, when the master is performing a write operation, the slave will drive the acknowledge line when it has placed the data into its memory. A typical slave implementa-tion is shown in Fig. 5-3. The slave is responsible for driving the acknowledge line for each accessed data operation and driving the data lines during an accessed read operation.