EISA System Architecture

Preemption

When one of the bus masters requires the use of the bus to communicate with another device, it must assert its request line (MREQn#) to the CAC (refer to figure 3-1). After deciding which device currently requesting the bus is next in the rotation, the CAC asserts the acknowledge line (MAKx#) associated with the bus master that currently owns the bus. In this way, the CAC preempts the current bus master, commanding it to relinquish control of the bus. Upon being preempted by removal of its acknowledge, the current bus master must relinquish control of the bus within a prescribed period of time. If the current bus master is an EISA bus master card, it must release the bus within 64 cycles of the bus clock signal (BCLK). Since BCLK has a nominal frequency of 8MHz, or 125ns per cycle, 64 BCLK cycles equates to eight microseconds. If the current bus master is a DMA channel programmed for one of the new EISA bus cycle types (rather than the ISA-compatible bus cycle), the DMA channel has 32 BCLKs , or four microseconds, to release the bus. DMA channels programmed to run ISA-compatible DMA bus cycles cannot be preempted. Care should therefore be taken when utilizing an ISA DMA channel to perform a block data transfer using either block or demand transfer modes. If the transfer is too long, other devices requiring the use of the bus, such as the refresh controller, may be forced to wait too long.

The current bus master indicates that it is relinquishing control of the bus by de-activating its CAC request line (MREQx#). If it doesn't relinquish control within eight microseconds, the CAC takes the following actions:

•asserts the reset signal on the EISA bus to force the current bus master off the bus

•asserts NMI to alert the main microprocessor that a bus timeout has occurred

•grants the bus to the main CPU so that it can respond to the NMI

If, on the other hand, the current bus master honors the preemption, relinquishing the bus and deasserting its request to the CAC, the CAC then grants the bus to the next bus master in the rotation that is requesting the use of the bus.

As illustrated in figure 3-1, the main CPU, refresh logic and the DMA controller each have a pair of request/acknowledge lines connecting it to the CAC. In addition, there is also a pair of request/acknowledge lines connected to each EISA connector in the system. The EISA specification provides support for up to fifteen EISA bus masters, numbered from zero to fourteen. MREQ0# and

28

Chapter 3: EISA Bus Arbitration

MAK0# are typically used to implement an EISA-style bus master that is embedded on the system board. MREQ1# and MAK1# are connected to EISA expansion connector one, MREQ2# and MAK2# to EISA connector two, etc. It should be noted, however, that the CAC encapsulated in the Intel 82350DT EISA chip set only has six pairs of EISA request/acknowledge lines and can therefore only support EISA bus master cards in a maximum of six EISA card connectors. This explains why some EISA machines with more than six EISA slots only support bus master cards in six of them.

If the current bus master is preempted during a multiple bus cycle transfer, it will give up the bus as described above, and, after waiting two BCLKs, it reasserts its request line to request the use of the bus again.

Example Arbitration Between Two Bus Masters

The timing diagram in the figure 3-4 illustrates bus arbitration between two Bus masters.

BCLK

Figure 3-4. Arbitration between Two Bus Masters

29

EISA System Architecture

The following steps define the sequence of events illustrated in figure 3-4. The step numbers correspond to the reference numbers in the illustration.

1.Initially, the main processor owns the bus.

2.The bus master in slot one requests the use of the bus by asserting MREQ1# (Master Request, slot 1) to the CAC.

3.After the CAC has removed ownership of the bus from the main processor and the main processor signals its willingness to give up ownership, the CAC grants ownership to bus master one by asserting MACK1# (Master Acknowledge, slot 1). Bus master one now owns the bus and can initiate one or more bus cycles.

4.The bus master in slot two signals its request for bus mastership by asserting MREQ2# to the CAC.

5.The CAC signals bus master one that it must give up bus mastership by removing MACK1#.

6.After detecting its MACK1# deasserted, bus master one has up to eight microseconds to release the bus. This gives it time to complete one or more bus cycles prior to release. Bus master one signals its release of the bus by deasserting MREQ1#.

7.The bus is granted to bus master two by the CAC when it asserts MACK2#.

8.Bus master one requires the use of the bus again to either complete its pre- viously-interrupted series of transfers or to initiate a new transfer. It signals its request to the CAC by asserting MREQ1#.

9.Bus master two has finished using the bus, so it voluntarily gives up ownership by deasserting MREQ2#.

10.The CAC removes ownership from bus master two by deasserting MACK2#.

11.The CAC grants the bus to bus master one again by asserting MACK1#.

Memory Refresh

The EISA system board incorporates a refresh controller that requests the use of the bus once every fifteen microseconds to refresh a row of DRAM memory. 16-bit ISA bus masters that hold the bus longer than fifteen microseconds must perform memory refresh bus cycles at the fifteen microsecond interval.

The EISA refresh controller includes a 14-bit row counter that drives its contents onto address lines 15:2 when the refresh controller becomes bus master. The refresh controller also places a value on BE#[3:0] to be transferred to A[1:0] and SBHE#.

30

Chapter 3: EISA Bus Arbitration

Each time that the refresh controller requests the use of the bus and the request is not granted within fifteen microseconds, the refresh controller increments its uncompleted refresh count. This counter can count up to four uncompleted refresh bus cycles. When the refresh controller succeeds in gaining control of the bus, it performs a refresh bus cycle and decrements the uncompleted refresh count by one. If more refreshes are queued up (the count isn't exhausted), the refresh controller immediately requests the use of the bus again without waiting the normal period of fifteen microseconds.

31

EISA System Architecture

32