Bus Interrupt Lines

AID

DRDY·

®

DACC·

FIGURE 3-5 Multichannel bus data cycle.

shown in Fig. 3-6. A bus controller, which is programmed to be a master, must monitor this signal to know when it may take control of the bus. Once it has assumed bus mastership, it must continue to monitor this signal while it is per-forming a bus transaction. Under normal conditions a supervisor will allow a bus controller master to finish its transaction before regaining control of the bus.

If an error occurs or a higher-priority transfer needs to take place, the supervisor can assert SA * prior to the transfer completion to take control of the bus. Once SA* has been asserted, the bus controller must turn off its bus drivers within a specified amount of time.

In Fig. 3-3, device 1, the bus supervisor, has programmed device 3 to take over the bus. Device 3 must monitor the SA * line to ensure the supervisor is no longer on the bus. If device 1 wants to regain the bus, it may assert the SA*

line. It is the responsibility of device 3 to remove itself from the bus.

3.3.3 Bus Interrupt Lines

The Multichannel bus supports two bus interrupts: supervisor take over (STO*) and service request (SRQ*). Both lines areJeceived exclusively by the supervisor and are driven by bus controllers and basic devices.

SUPERVISOR TAKE OVER

Supervisor take over (STO*) is an active-low signal driven by basic devices and bus controllers to inform the supervisor of two possible conditions: task comple-tion and bus error. A bus controller which has mastership of the bus uses STO*

to inform the supervisor that it has completed its current task. The STO* signal is also used whenever a bus error occurs. A bus error is defined as a device hardware failure (memory, disk, etc.) or a bus parity error. A device that has either of these failures asserts the STO* signal. On receipt of the STO* the supervisor will, at some time, poll and service the requesting device(s) on the bus until the STO* signal has been removed. Only the bus supervisor may act upon an STO*.

SERVICE REQUEST

Service request (SRQ*) is an active-low signal driven by a basic device or bus controller to inform the supervisor that it needs service. A supervisor may pro-gram a device to perform a task off line (e.g., a seek on a disk). The device will signal the supervisor that it is ready by asserting the SRQ* line. The service request should be used whenever service is required by a device. One desig-nated use for the SRQ* line is a power-up configuration signal to the bus

super-ADO*-AD15*

_w

,r--jK

I~ _J~

AID ;

__ -1 I

--,

,

R/W

,

DRDY*

AACC

SA*

1/

SUPERVISOR SUPERVISOR OFF BUS.

ADDRESSI INTELLIGENT

PROGRAMS INTELLIGENT CONTROLLER ADDRESSING

CONTROLLER DEVICE

FIGURE 3-6 Signal relations for SA*.

92 THE MUL TIBUS F AMIL Y OF BUS STRUCTURES

visor. The use of this signal is covered in Sec. 3-5, "Programming Information."

The supervisor has the option to mask this signal until it is ready to accept the signal. As with the STO* signal, the supervisor polls and services the requesting device(s) on the bus until the SRQ* signal has been removed.

3.3.4 Parity

The parity signal (PB*) is used to qualify the data integrity of the transfer and should be sampled by the listening device when DRDY* goes active. Parity is an active-low signal defined as follows:

1. When an odd number of AD lines are high during an address or data trans-fer, the parity line will be active (low).

2. When an even number of AD lines are high during an address or data trans-fer, the parity line will be inactive (high).

The parity signal is generated by the master for all addresses and by the talking device for all data transfers over the bus. When a listener detects a parity error, it must assert the STO* signal to the supervisor. The only exception to this rule occurs when the listener is the supervisor, in which case it will already be informed of the error.

The Multichannel bus allows certain subsets to the parity mode. The first subset is a no-parity mode. If the no-parity mode is selected, slaves must not sample parity during address transfers and listeners must not sample parity dur-ing data transfers. When a parity mode is selected, masters must generate parity during address transfers and talkers must generate parity during data tr~sfers.

Another subset is for 8-bit devices. When they are used in an 8-bit-only system, only 8-bit parity needs to be sent and received. If, however, 8- and 16-bit devices are on the same bus, the 8-bit slave must check 16-bit parity for address transfers. The 8-bit slave is only required to send and receive 8-bit parity for data transfers.

3.3.5 Reset*

The Multichannel bus supports a Reset* signal to bring the bus to a known state.

The supervisor is the only device that drives Reset*, but all other devices con-nected to the bus receive it. After power-up, the supervisor will hold this signal low for a minimum of 5 ms. This will guarantee that all devices are in a known state and ready for the supervisor's commands. If the supervisor needs to regain control of the bus rapidly during a transfer cycle, it may choose to assert Reset*

on the bus. This action will immediately stop any transaction on the bus. Cur-rent transfer and bus status data are lost when Reset* is used in this manner.