Intel Corporation TK82380 Datasheet

November 1992 Order Number: 271070-006

M82380

HIGH PERFORMANCE 32-BIT DMA CONTROLLER WITH

INTEGRATED SYSTEM SUPPORT PERIPHERALS

Y

High Performance 32-Bit DMA
Controller
Ð 40 Mbytes/sec Maximum Data

Transfer Rate at 20 MHz

Ð 8 Independently Programmable

Channels

Y

20-Source Interrupt Controller
Ð Individually Programmable Interrupt

Vectors
Ð 15 External, 5 Internal Interrupts
Ð M8259A Superset

Y

Four 16-Bit Programmable Interval
Timers
Ð M82C54 Compatible

Y

Programmable Wait State Generator
Ð 0 to 15 Wait States Pipelined
Ð 1 to 16 Wait States Non-Pipelined

Y

DRAM Refresh Controller

Y

i386TMProcessor Shutdown Detect and
Reset Control
Ð Software/Hardware Reset

Y

High Speed CHMOS III Technology

Y

132-Pin PGA Package and 164-Pin Quad
Flat Pack

(See Packaging Specification OrderÝ231369)

Y

Optimized for use with the i386

TM

Microprocessor
Ð Resides on Local Bus for Maximum

Bus Bandwidth

Y

Available in Three Product Grades:
Ð MIL-STD-883,

b

55§Ctoa125§C(TC)

Ð Military Temperature Only,

b

55§Ctoa125§C(TC)

Ð Extended Temperature,

b

40§Ctoa110§C(TC)

The M82380 is a multi-function support peripheral that integrates system functions necessary in an i386
processor environment. It has eight channels of high performance 32-bit DMA with the most efficient transfer
rates possible on the i386 microprocessor bus. System support peripherals integrated into the M82380 provide
Interrupt Control, Timers, Wait State generation, DRAM Refresh Control, and System Reset logic.

The M82380’s DMA Controller can transfer data between devices of different data path widths using a single
channel. Each DMA channel operates independently in any of several modes. Each channel has a temporary
data storage register for handling non-aligned data without the need for external alignment logic.

271070–1

M82380 Internal Block Diagram

M82380

M82380

HIGH PERFORMANCE 32-BIT DMA CONTROLLER

WITH INTEGRATED SYSTEM SUPPORT PERIPHERALS

CONTENTS PAGE

1.0 FUNCTIONAL OVERVIEW

ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 6

1.1 M82380 Architecture ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 6

1.1.1 DMA Controller ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 7

1.1.2 Programmable Interval Timers ААААААААААААААААААААААААААААААААААААААААААААААААААААА 8

1.1.3 Interrupt Controller АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 9

1.1.4 Wait State Generator ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 10

1.1.5 DRAM Refresh Controller АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 10

1.1.6 CPU Reset Function ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 11

1.1.7 Register Map Relocation ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 11

1.2 Host Interface АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 11

2.0 i386TMPROCESSOR HOST INTERFACE ААААААААААААААААААААААААААААААААААААААААААААААА 12

2.1 Master and Slave Modes АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 13

2.2 M80386 Interface Signals ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 13

2.2.1 Clock (CLK2) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 13

2.2.2 Data Bus (D0– D31) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 13

2.2.3 Address Bus (A31– A2) ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 14

2.2.4 Byte Enable (BE3– BE0) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 14

2.2.5 Bus Cycle Definition Signals (D/C, W/R, M/IO) ААААААААААААААААААААААААААААААААААА 15

2.2.6 Address Status (ADS) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 15

2.2.7 Transfer Acknowledge (READY) ААААААААААААААААААААААААААААААААААААААААААААААААА 15

2.2.8 Next Address Request (NA) АААААААААААААААААААААААААААААААААААААААААААААААААААААА 15

2.2.9 Reset (RESET, CPURST) АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 15

2.2.10 Interrupt Out (INT) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 17

2.3 M82380 Bus Timing ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 17

2.3.1 Address Pipelining ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 17

2.3.2 Master Mode Bus Timing ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 17

2.3.3 Slave Mode Bus Timing АААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 20

3.0 DMA CONTROLLER АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 21

3.1 Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 22

3.2 Interface Signals АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 23

3.2.1 DREQn and EDACK (0–2) ААААААААААААААААААААААААААААААААААААААААААААААААААААААА 24

3.2.2 HOLD and HLDA ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 24

3.2.3 EOP ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 24

3.3 Modes of Operation ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 24

3.3.1 Target/Requester Definition АААААААААААААААААААААААААААААААААААААААААААААААААААААА 25

3.3.2 Buffer Transfer Processes АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 25

3.3.3 Data Transfer Modes ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 26

3.3.4 Channel Priority Arbitration ААААААААААААААААААААААААААААААААААААААААААААААААААААААА 30

3.3.5 Combining Priority Modes АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 32

3.3.6 Bus Operation ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 33

3.4 Bus Arbitration and Handshaking АААААААААААААААААААААААААААААААААААААААААААААААААААААА 34

3.4.1 Synchronous and Asynchronous Sampling of DREQn and EOP ААААААААААААААААААА 37

3.4.2 Arbitration of Cascaded Master Requests ААААААААААААААААААААААААААААААААААААААААА 39

3.4.3 Arbitration of Refresh Requests АААААААААААААААААААААААААААААААААААААААААААААААААА 41

2

M82380

CONTENTS PAGE

3.0 DMA CONTROLLER (Continued)

3.5 DMA Controller Register Overview

АААААААААААААААААААААААААААААААААААААААААААААААААААА 41

3.5.1 Control/Status Registers ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 41

3.5.2 Channel Registers ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 42

3.5.3 Temporary Registers ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 43

3.6 DMA Controller Programming ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 44

3.6.1 Buffer Processes ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 44

3.6.2 Data Transfer Modes ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 45

3.6.3 Cascaded Bus Masters ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 45

3.6.4 Software Commands ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 45

3.7 Register Definitions ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 46

4.0 PROGRAMMABLE INTERRUPT CONTROLLER АААААААААААААААААААААААААААААААААААААААА 53

4.1 Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 53

4.1.1 Internal Block Diagram ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 53

4.1.2 Interrupt Controller Banks АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 54

4.2 Interface Signals АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 55

4.2.1 Interrupt Inputs ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 55

4.2.2 Interrupt Output (INT) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 56

4.3 Bus Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 56

4.4 Mode of Operation АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 57

4.4.1 End-Of-Interrupt ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 57

4.4.2 Interrupt Priorities АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 58

4.4.3 Interrupt Masking АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 61

4.4.4 Edge Or Level Interrupt Triggering АААААААААААААААААААААААААААААААААААААААААААААААА 61

4.4.5 Interrupt Cascading АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 61

4.4.6 Reading Interrupt Status ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 62

4.5 Register Set Overview АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 62

4.5.1 Initialization Command Words (ICW) АААААААААААААААААААААААААААААААААААААААААААААА 64

4.5.2 Operation Control Words (OCW) ААААААААААААААААААААААААААААААААААААААААААААААААА 64

4.5.3 Poll/Interrupt Request/In-Service Status Register АААААААААААААААААААААААААААААААА 65

4.5.4 Interrupt Mask Register (IMR) АААААААААААААААААААААААААААААААААААААААААААААААААААА 65

4.5.5 Vector Register (VR) ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 65

4.6 Programming ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 65

4.6.1 Initialization (ICW) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 65

4.6.2 Vector Registers (VR) АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 66

4.6.3 Operation Control Words (OCW) ААААААААААААААААААААААААААААААААААААААААААААААААА 66

4.7 Register Bit Definition ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 67

4.8 Register Operational Summary АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 70

3

M82380

CONTENTS PAGE

5.0 PROGRAMMABLE INTERVAL TIMER

АААААААААААААААААААААААААААААААААААААААААААААААААА 71

5.1 Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 71

5.1.1 Internal Architecture ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 72

5.2 Interface Signals АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 73

5.2.1 CLKIN ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 73

5.2.2 TOUT1, TOUT2, TOUT3 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 73

5.2.3 GATE АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 73

5.3 Modes of Operation ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 74

5.3.1 Mode 0ÐInterrupt on Terminal Count АААААААААААААААААААААААААААААААААААААААААААА 74

5.3.2 Mode 1ÐGate Retriggerable One-Shot ААААААААААААААААААААААААААААААААААААААААААА 74

5.3.3 Mode 2ÐRate Generator АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 76

5.3.4 Mode 3ÐSquare Wave Generator АААААААААААААААААААААААААААААААААААААААААААААААА 77

5.3.5 Mode 4ÐInitial Count Triggered Strobe ААААААААААААААААААААААААААААААААААААААААААА 79

5.3.6 Mode 5ÐGate Retriggerable Strobe АААААААААААААААААААААААААААААААААААААААААААААА 80

5.3.7 Operation Common to All Modes ААААААААААААААААААААААААААААААААААААААААААААААААА 81

5.4 Register Set Overview АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 81

5.4.1 Counter 0, 1, 2, 3 Registers ААААААААААААААААААААААААААААААААААААААААААААААААААААААА 82

5.4.2 Control Word RegisterI&II АААААААААААААААААААААААААААААААААААААААААААААААААААААА 82

5.5 Programming ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 82

5.5.1 Initialization АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 82

5.5.2 Read Operation АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 82

5.6 Register Bit Definitions АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 84

6.0 WAIT STATE GENERATOR ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 86

6.1 Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 86

6.2 Interface Signals АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 87

6.2.1 READY АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 87

6.2.2 READYO АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 87

6.2.3 WSC(0 –1) ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 87

6.3 Bus Function ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 88

6.3.1 Wait States in Non-Pipelined Cycle ААААААААААААААААААААААААААААААААААААААААААААААА 88

6.3.2 Wait States in Pipelined Cycle АААААААААААААААААААААААААААААААААААААААААААААААААААА 89

6.3.3 Extending and Early Terminating Bus Cycle ААААААААААААААААААААААААААААААААААААААА 90

6.4 Register Set Overview АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 91

6.5 Programming ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 92

6.6 Register Bit Definition ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 92

6.7 Application Issues АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 92

6.7.1 External ‘READY’ Control Logic АААААААААААААААААААААААААААААААААААААААААААААААААА 92

7.0 DRAM REFRESH CONTROLLER ААААААААААААААААААААААААААААААААААААААААААААААААААААААА 94

7.1 Functional Description АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 94

7.2 Interface Signals АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 94

7.2.1 TOUT1/REF ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 94

7.3 Bus Function ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 95

7.3.1 Arbitration ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 95

7.4 Modes of Operation ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 95

7.4.1 Word Size and Refresh Address Counter ААААААААААААААААААААААААААААААААААААААААА 95

7.5 Register Set Overview АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 96

7.6 Programming ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 96

7.7 Register Bit Definition ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 96

4

M82380

CONTENTS PAGE

8.0 RELOCATION REGISTER AND ADDRESS DECODE

ААААААААААААААААААААААААААААААААААА 96

8.1 Relocation Register ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 96

8.1.1 I/O-Mapped M82380 ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 97

8.1.2 Memory-Mapped M82380 АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 97

8.2 Address Decoding АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 97

9.0 CPU RESET AND SHUTDOWN DETECT АААААААААААААААААААААААААААААААААААААААААААААААА 97

9.1 Hardware Reset АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 97

9.2 Software Reset ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 97

9.3 Shutdown Detect ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 98

10.0 INTERNAL CONTROL AND DIAGNOSTIC PORTS АААААААААААААААААААААААААААААААААААА 98

10.1 Internal Control Port ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 98

10.2 Diagnostic Ports ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 98

11.0 INTEL RESERVED I/O PORTS АААААААААААААААААААААААААААААААААААААААААААААААААААААААА 99

12.0 MECHANICAL DATA ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 100

12.1 Pin Assignment ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 100

12.2 Package Dimensions and Mounting ААААААААААААААААААААААААААААААААААААААААААААААААА 102

13.0 ELECTRICAL DATA АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 104

13.1 Power and Grounding АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 104

13.2 Power Decoupling АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 104

13.3 Unused Pin Recommendations ААААААААААААААААААААААААААААААААААААААААААААААААААААА 104

13.4 ICETM-386 Support ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 104

13.5 Maximum Ratings АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 105

13.6 DC Specifications АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 106

13.7 AC Specifications ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА 107

APPENDIX AÐPorts Listed by Address ААААААААААААААААААААААААААААААААААААААААААААААААААА A-1

APPENDIX BÐPorts Listed by Function АААААААААААААААААААААААААААААААААААААААААААААААААА B-1

APPENDIX CÐPin Descriptions ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА C-1

APPENDIX DÐM82380 System Notes ААААААААААААААААААААААААААААААААААААААААААААААААААААА D-1

5

M82380

1.0 FUNCTIONAL OVERVIEW

The M82380 contains several independent function­al modules. The following is a brief discussion of the
components and features of the M82380. Each
module has a corresponding detailed section later in
this data sheet. Those sections should be referred
to for design and programming information.

1.1 M82380 Architecture

The M82380 is comprised of several computer sys­tem functions that are normally found in separate
LSI and VLSI components. These include: a high­performance, eight-channel, 32-bit Direct Memory
Access Controller; a 20-level Programmable Inter­rupt Controller which is a superset of the M8259A;
four 16-bit Programmable Interval Timers which are
functionally equivalent to the M82C54 timers; a
DRAM Refresh Controller; a Programmable Wait
State Generator; and system reset logic. The inter­face to the M82380 is optimized for high-perform­ance operation with the i386 microprocessor.

The M82380 operates directly on the i386 micro­processor bus. In the Slave Mode, it monitors the

state of the processor at all times and acts or idles
according to the commands of the host. It monitors
the address pipeline status and generates the pro­grammed number of wait states for the device being
accessed. The M82380 also has logic to reset the
i386 microprocessor via hardware or software reset
requests and processor shutdown status.

After a system reset, the M82380 is in the Slave
Mode. It appears to the system as an I/O device. It
becomes a bus master when it is performing DMA
transfers.

To maintain compatibility with existing software, the
registers within the M82380 are accessed as bytes.
If the internal logic of the M82380 requires a delay
before another access by the processor, wait states
are automatically inserted into the access cycle.
This allows the programmer to write initialization rou­tines, etc. without regard to hardware recovery
times.

Figure 1 shows the basic architectural components
of the M82380. The following sections briefly dis­cuss the architecture and function of each of the
distinct sections of the M82380.

271070–2

Figure 1. Architecture of the M82380

6

M82380

1.1.1 DMA CONTROLLER

The M82380 contains a high-performance, 8-chan­nel, 32-bit DMA controller. It is capable of transfer­ring any combination of bytes, words, and double
words. The addresses of both source and destina­tion can be independently incremented, decrement­ed or held constant, and cover the entire 32-bit
physical address space of the i386 microprocessor.
It can disassemble and assemble misaligned data
via a 32-bit internal temporary data storage register.
Data transferred between devices of different data
path widths can also be assembled and disassem­bled using the internal temporary data storage regis­ter. The DMA Controller can also transfer aligned
data between I/O and memory on the fly, allowing
data transfer rates up to 32 megabytes per second
for an M82380 operating at 16 MHz. Figure 2 illus­trates the functional components of the DMA Con­troller.

There are twenty-four general status and command
registers in the M82380 DMA Controller. Through
these registers any of the channels may be pro­grammed into any of the possible modes. The oper­ating modes of any one channel are independent of
the operation of the other channels.

Each channel has three programmable registers
which determine the location and amount of data to
be transferred:

Byte Count RegisterÐNumber of bytes to trans­fer. (24-bits)

Requester RegisterÐAddress of memory or pe­ripheral which is requesting DMA service. (32­bits)

Target RegisterÐAddress of peripheral or mem­ory which will be accessed. (32-bits)

There are also port addresses which, when ac­cessed, cause the M82380 to perform specific func­tions. The actual data written does not matter, the
act of writing to the specific address causes the
command to be executed. The commands which op­erate in this mode are: Master Clear, Clear Terminal
Count Interrupt Request, Clear Mask Register, and
Clear Byte Pointer Flip-Flop.

DMA transfers can be done between all combina­tions of memory and I/O; memory-to-memory, mem­ory-to-I/O, I/O-to-memory, and I/O-to-I/O. DMA
service can be requested through software and/or
hardware. Hardware DMA acknowledge signals are
available for all channels (except channel 4) through
an encoded 3-bit DMA acknowledge bus
(EDACK0– 2).

271070–3

Figure 2. M82380 DMA Controller

7

M82380

The M82380 DMA controller transfers blocks of data
(buffers) in three modes: Single Buffer, Buffer Auto­Initialize, and Buffer Chaining. In the Single Buffer
Process, the M82380 DMA Controller is pro­grammed to transfer one particular block of data.
Successive transfers then require reprogramming of
the DMA channel. Single Buffer transfers are useful
in systems where it is known at the time the transfer
begins what quantity of data is to be transferred, and
there is a contiguous block of data area available.

The Buffer Auto-Initialize Process allows the same
data area to be used for successive DMA transfers
without having to reprogram the channel.

The Buffer Chaining Process allows a program to
specify a list of buffer transfers to be executed. The
M82380 DMA Controller, through interrupt routines,
is reprogrammed from the list. The channel is repro­grammed for a new buffer before the current buffer
transfer is complete. This pipelining of the channel
programming process allows the system to allocate
non-contiguous blocks of data storage space, and
transfer all of the data with one DMA process. The
buffers that make up the chain do not have to be in
contiguous locations.

Channel priority can be fixed or rotating. Fixed priori­ty allows the programmer to define the priority of
DMA channels based on hardware or other fixed pa­rameters. Rotating priority is used to provide periph­erals access to the bus on a shared basis.

With fixed priority, the programmer can set any
channel to have the current lowest priority. This al-

lows the user to reset or manually rotate the priority
schedule without reprogramming the command reg­isters.

1.1.2 PROGRAMMABLE INTERVAL TIMERS

Four 16-bit programmable interval timers reside
within the M82380. These timers are identical in
function to the timers in the M82C54 Programmable
Interval Timer. All four of the timers share a common
clock input which can be independent of the system
clock. The timers are capable of operating in six dif­ferent modes. In all of the modes, the current count
can be latched and read by the i386 processor at
any time, making these very versatile event timers.
Figure 3 shows the functional components of the
Programmable Interval Timers.

The outputs of the timers are directed to key system
functions, making system design simpler. Timer 0 is
routed directly to an interrupt input and is not avail­able externally. This timer would typically be used to
generate time-keeping interrupts.

Timers 1 and 2 have outputs which are available for
general timer/counter purposes as well as special
functions. Timer 1 is routed to the refresh control
logic to provide refresh timing. Timer 2 is connected
to an interrupt request input to provide other timer
functions. Timer 3 is a general purpose timer/coun­ter whose output is available to external hardware. It
is also connected internally to the interrupt request
which defaults to the highest priority (IRQ0).

271070–4

Figure 3. Programmable Interval TimersÐBlock Diagram

8

M82380

1.1.3 INTERRUPT CONTROLLER

The M82380 has the equivalent of three enhanced
M8259A Programmable Interrupt Controllers. These
controllers can all be operated in the Master mode,
but the priority is always as if they were cascaded.
There are 15 interrupt request inputs provided for
the user, all of which can be inputs from external
slave interrupt controllers. Cascading M8259As to
these request inputs allows a possible total of 120
external interrupt requests. Figure 4 is a block dia­gram of the M82380 Interrupt Controller.

Each of the interrupt request inputs can be individu­ally programmed with its own interrupt vector, allow­ing more flexibility in interrupt vector mapping than
was available with the M8259A. An interrupt is pro­vided to alert the system that an attempt is being

made to program the vectors in the method of the
M8259A. This provides compatibility of existing soft­ware that used the M8259A with new designs using
the M82380.

In the event of an unrequested or otherwise errone­ous interrupt acknowledge cycle, the M82380 Inter­rupt Controller issues a default vector. This vector,
programmed by the system software, will alert the
system of unsolicited interrupts of the M80386.

The functions of the M82380 Interrupt Controller are
identical to the M8259A, except in regards to pro­gramming the interrupt vectors as mentioned above.
Interrupt request inputs are programmable as either
edge or level triggered and are software maskable.
Priority can be either fixed or rotating and interrupt
requests can be nested.

271070–5

Figure 4. M82380 Interrupt ControllerÐBlock Diagram

9

M82380

Enhancements are added to the M82380 for cas­cading external interrupt controllers. Master to Slave
handshaking takes place on the data bus, instead of
dedicated cascade lines.

1.1.4 WAIT STATE GENERATOR

The Wait State Generator is a programmable
READY generation circuit for the i386 processor
bus. A peripheral requiring wait states can request
the Wait State Generator to hold the processor’s
READY input inactive for a predetermined number of
bus states. Six different wait state counts can be
programmed into the Wait State Generator by soft­ware; three for memory accesses and three for I/O
accesses. A block diagram of the M82380 Wait
State Generator is shown in Figure 5.

The peripheral being accessed selects the required
wait state count by placing a code on a 2-bit wait
state select bus. This code along with the M/IO

sig­nal from the bus master is used to select one of six
internal 4-bit wait state registers which has been
programmed with the desired number of wait states.
From zero to fifteen wait states can be programmed
into the wait state registers. The Wait State Genera­tor tracks the state of the processor or current bus
master at all times, regardless of which device is the
current bus master and regardless of whether or not
the Wait State Generator is currently active.

The M82380 Wait State Generator is disabled by
making the select inputs both high. This allows hard­ware which is intelligent enough to generate its own
ready signal to be accessed without penalty. As pre-

viously mentioned, deselecting the Wait State Gen­erator does not disable its ability to determine the
proper number of wait states due to pipeline status
in subsequent bus cycles.

The number of wait states inserted into a pipelined
bus cycle is the value in the selected wait state reg­ister. If the bus master is operating in the non-pipe­lined mode, the Wait State Generator will increase
the number of wait states inserted into the bus cycle
by one.

On reset, the Wait State Generator’s registers are
loaded with the value FFH, giving the maximum
number of wait states for any access in which the
wait state select inputs are active.

1.1.5 DRAM REFRESH CONTROLLER

The M82380 DRAM Refresh Controller consists of a
24-bit refresh address counter and bus arbitration
logic. The output of Timer 1 is used to periodically
request a refresh cycle. When the controller re­ceives the request, it requests access to the system
bus through the HOLD signal. When bus control is
acknowledged by the processor or current bus mas­ter, the refresh controller executes a memory read
operation at the address currently in the Refresh Ad­dress Register. At the same time, it activates a re­fresh signal (REF

) that the memory uses to force a
refresh instead of a normal read. Control of the bus
is transferred to the processor at the completion of
this cycle. Typically a refresh cycle will take six clock
cycles to execute on an i386 processor bus.

271070–6

Figure 5. M82380 Wait State GeneratorÐBlock Diagram

10

M82380

The M82380 DRAM Refresh Controller has the high­est priority when requesting bus access and will in­terrupt any active DMA process. This allows large
blocks of data to be moved by the DMA controller
without affecting the refresh function. Also the DMA
controller is not required to completely relinquish the
bus, the refresh controller simply steals a bus cycle
between DMA accesses.

The amount by which the refresh address is incre­mented is programmable to allow for different bus
widths and memory bank arrangements.

1.1.6 CPU RESET FUNCTION

The M82380 contains a special reset function which
can respond to hardware reset signals from the
M82384, as well as a software reset command. The
circuit will hold the i386 processor’s RESET line ac­tive while an external hardware reset signal is pres­ent at its RESET input. It can also reset the i386
processor as the result of a software command. The
software reset command causes the M82380 to
hold the processor’s RESET line active for a mini­mum of 62 CLK2 cycles; enough time to allow an
M80386 to re-initialize.

The M82380 can be programmed to sense the shut­down detect code on the status lines from the
M80386. If the Shutdown Detect function is enabled,
the M82380 will automatically reset the processor. A
diagnostic register is available which can be used to
determine the cause of reset.

1.1.7 REGISTER MAP RELOCATION

After a hardware reset, the internal registers of the
M82380 are located in I/O space beginning at port
address 0000H. The map of the M82380’s registers
is relocatable via a software command. The default
mapping places the M82380 between I/O address­es 0000H and 00DBH. The relocation register allows
this map to be moved to any even 256-byte bounda­ry in the processor’s 16-bit I/O address space or any
even 16-Mbyte boundary in the 32-bit memory ad­dress space.

1.2 Host Interface

The M82380 is designed to operate efficiently on the
local bus of an M80386 microprocessor. The control

signals of the M82380 are identical in function to
those of the i386 processor. As a slave, the M82380
operates with all of the features available on the
i386 processor bus. When the M82380 is in the Mas­ter Mode, it looks identical to the i386 processor to
the connected devices.

The M82380 monitors the bus at all times, and de­termines whether the current bus cycle is a pipelined
or non-pipelined access. All of the status signals of
the processor are monitored.

The control, status, and data registers within the
M82380 are located at fixed addresses relative to
each other, but the group can be relocated to either
memory or I/O space and to different locations with­in those spaces.

As a Slave device, the M82380 monitors the con­trol/status lines of the CPU. The M82380 will gener­ate all of the wait states it needs whenever it is ac­cessed. This allows the programmer the freedom of
accessing M82380 registers without having to insert
NOPs in the program to wait for slower M82380 in­ternal registers.

The M82380 can determine if a current bus cycle is
a pipelined or a non-pipelined cycle. It does this by
monitoring the ADS

and READY signals and thereby
keeping track of the current state of the i386 proces­sor.

As a bus master, the M82380 looks like an i386
processor to the rest of the system. This enables the
designer greater flexibility in systems which include
the M82380. The designer does not have to alter the
interfaces of any peripherals designed to operate
with the i386 processor to accommodate the
M82380. The M82380 will access any peripherals on
the bus in the same manner as the i386 processor,
including recognizing pipelined bus cycles.

The M82380 is accessed as an 8-bit peripheral. This
is done to maintain compatibility with existing system
architectures and software. The i386 processor
places the data of all 8-bit accesses either on D (0 –

7) or D (8 – 15). The M82380 will only accept data on
these lines when in the Slave Mode. When in the
Master Mode, the M82380 is a full 32-bit machine,
sending and receiving data in the same manner as
the i386 processor.

11

M82380

2.0 i386TMPROCESSOR HOST
INTERFACE

The M82380 contains a set of interface signals to
operate efficiently with the i386 host processor.
These signals were designed so that minimal hard­ware is needed to connect the M82380 to the i386
processor.

Figure 6 depicts a typical system configuration with
the i386 processor. As shown in the diagram, the
M82380 is designed to interface directly with the
i386 bus.

Since the M82380 is residing on the opposite side of
the data bus transceiver (with respect to the rest of
the peripherals in the system), it is important to note

that the transceiver should be controlled so that
contention between the data bus transceiver and
the M82380 will not occur. In order to do this, port
address decoding logic should be included in the di­rection and enable control logic of the transceiver.
When any of the M82380 internal registers is read,
the data bus transceiver should be disabled so that
only the M82380 will drive the local bus.

This section describes the basic bus functions of the
M82380 to show how this device interacts with the
i386 processor. Other signals which are not directly
related to the host interface will be discussed in their
associated functional block description.

271070–7

Figure 6. i386TM/M82380 System Configuration

12

M82380

2.1 Master and Slave Modes

At any time, the M82380 acts as either a Slave de­vice or a Master device in the system. Upon reset,
the M82380 will be in the Slave Mode. In this mode,
the i386 processor can read/write into the M82380
internal registers. Initialization information may be
programmed into the M82380 during Slave Mode.

When DMA service (including DRAM Refresh Cycles
generated by the M82380) is requested, the M82380
will request and subsequently get control of the i386
processor local bus. This is done through the HOLD
and HLDA (Hold Acknowledge) signals. When the
i386 processor responds by asserting the HLDA sig­nal, the M82380 will switch into Master Mode and
perform DMA transfers. In this mode, the M82380 is
the bus master of the system. It can read/write data
from/to memory and peripheral devices. The
M82380 will return to the Slave Mode upon comple­tion of DMA transfers, or when HLDA is negated.

2.2 M80386 INTERFACE SIGNALS

As mentioned in the Architecture section, the Bus
Interface module of the M82380 (see Figure 1) con­tains signals that are directly connected to the i386
host processor. This module has separate 32-bit
Data and Address busses. Also, it has additional
control signals to support different bus operations
on the system. By residing on the i386 processor
local bus, the M82380 shares the same address,
data and control lines with the processor. The fol­lowing subsections discuss the signals which inter­face to the i386 host processor.

2.2.1 CLOCK (CLK2)

The CLK2 input provides fundamental timing for the
M82380. It is divided by two internally to generate
the M82380 internal clock. Therefore, CLK2 should
be driven with twice the i386’s frequency. In order to
maintain synchronization with the i386 host proces­sor, the M82380 and the i386 processor should
share a common clock source.

The internal clock consists of two phases: PHI1 and
PHI2. Each CLK2 period is a phase of the internal
clock. PHI2 is usually used to sample input and set
up internal signals and PHI1 is for latching internal
data. Figure 7 illustrates the relationship of CLK2
and the M82380 internal clock signals. The CPURST
signal generated by the M82380 guarantees that the
i386 processor will wake up in phase with PHI1.

2.2.2 DATA BUS (D0 –D31)

This 32-bit three-state bidirectional bus provides a
general purpose data path between the M82380 and
the system. These pins are tied directly to the corre­sponding Data Bus pins of the i386 processor local
bus. The Data Bus is also used for interrupt vectors
generated by the M82380 in the Interrupt Acknowl­edge cycle.

During Slave I/O operations, the M82380 expects a
single byte to be written or read. When the i386 host
processor writes into the M82380, either D0– D7 or
D8– D15 will be latched into the M82380, depending
upon how the Byte Enable (BE0

–BE3) signals are
driven. The M82380 does not need to look at D16 –
D31 since the i386 processor duplicates

271070–8

Figure 7. CLK2 and M82380 Internal Clock

13

M82380

the single byte data on both halves of the bus. When
the M80386 host processor reads from the M82380,
the single byte data will be duplicated four times on
the Data Bus; i.e., on D0 –D7, D8– D15, D16– D23
and D24– D31.

During Master Mode, the M82380 can transfer 32-,
16-, and 8-bit data between memory (or I/O devices)
and I/O devices (or memory) via the Data Bus.

2.2.3 ADDRESS BUS (A31 –A2)

These three-state bidirectional signals are connect­ed directly to the i386 Address Bus. In the Slave
Mode, they are used as input signals so that the
processor can address the M82380 internal ports/
registers. In the Master Mode, they are used as out­put signals by the M82380 to address memory and
peripheral devices. The Address Bus is capable of
addressing 4 G-bytes of physical memory space

(00000000H to FFFFFFFFH), and 64 K-bytes of I/O
addresses (00000000H to 0000FFFFH).

2.2.4 BYTE ENABLE (BE3

–BE0)

These bidirectional pins select specific byte(s) in the
double word addressed by A31–A2. Similar to the
Address Bus function, these signals are used as in­puts to address internal M82380 registers during
Slave Mode operation. During Master Mode opera­tion, they are used as outputs by the M82380 to ad­dress memory and I/O locations.

In addition to the above function, BE3

is used to
enable a production test mode and must be LOW
during reset. The i386 processor will automatically
hold BE3

LOW during RESET.

The definitions of the Byte Enable signals depend
upon whether the M82380 is in the Master or Slave
Mode. These definitions are depicted in Table 1.

Table 1. Byte Enable Signals

As INPUTS (Slave Mode):

BE3– BE0 Implied A1, A0

Data Bits Written

to M82380*

XXX0 00 D0– D7
XX01 01 D8 – D15

X011 10 D0– D7
X111 11 D8– D15

X–DON’T CARE
*During READ, data will be duplicated on D0 – D7, D8–D15, D16 – D23, and D24 – D31.
During WRITE, the M80386 host processor duplicates data on D0–D15, and D16 – D31, so that the
M82380 is concerned only with the lower half of the Data Bus.

As OUTPUTS (Master Mode):

Byte to be Accessed

Logical Byte Presented On

BE3

–BE0

Relative to A31– A2

Data Bus During WRITE Only*

D24–31 D16–23 D8–15 D0–7

1110 0 U U U A
1101 1 U U A A
1011 2 U A U A
0111 3 A U A A
1001 1, 2 U B A A
1100 0, 1 U U B A
0011 2, 3 B A B A
1000 0, 1, 2 U C B A
0001 1, 2, 3 C B A A
0000 0, 1, 2, 3 D C B A

UeUndefined
A

e

Logical D0 – D7

B

e

Logical D8 – D15

C

e

Logical D16 – D23

D

e

Logical D24 – D31

*Actual number of bytes accessed depends upon the programmed data path width.

14

M82380

2.2.5 BUS CYCLE DEFINITION SIGNALS (D/C,
W/R

, M/IO)

These three-state bidirectional signals define the
type of bus cycle being performed. W/R

distin-

guishes between write and read cycles. D/C

distin­guishes between processor data and control cycles.
M/IO

distinguishes between memory and I/O cy-

cles.

During Slave Mode, these signals are driven by the
i386 host processor; during Master Mode, they are
driven by the M82380. In either mode, these signals
will be valid when the Address Status (ADS

) is driven

LOW. Exact bus cycle definitions are given in Table

2. Note that some combinations are recognized as
inputs, but not generated as outputs. In the Master
Mode, D/C

is always HIGH.

2.2.6 ADDRESS STATUS (ADS)

This bidirectional signal indicates that a valid ad­dress (A2 – A31, BE0

–BE3) and bus cycle definition

(W/R

, D/C, M/IO) is being driven on the bus. In the
Master Mode, it is driven by the M82380 as an out­put. In the Slave Mode, this signal is monitored as an
input by the M82380. By the current and past status
of ADS and the READY input, the M82380 is able to
determine, during Slave Mode, if the next bus cycle
is a pipelined address cycle. ADS

is asserted during

T1 and T2P bus states (see Bus State Definition).

Note that during the idle states at the beginning and
the end of a DMA process, neither the i386 proces­sor nor the M82380 is driving the ADS

signal; i.e.,
the signal is left floated. Therefore, it is important to
use a pull-up resistor (approximately 10 KX)onthe
ADS

signal.

2.2.7 TRANSFER ACKNOWLEDGE (READY

)

This input indicates that the current bus cycle is
complete. In the Master Mode, assertion of this sig­nal indicates the end of a DMA bus cycle. In the
Slave Mode, the M82380 monitors this input and
ADS

to detect a pipelined address cycles. This sig-

nal should be tied directly to the READY

input of the

i386 host processor.

2.2.8 NEXT ADDRESS REQUEST (NA

)

This input is used to indicate to the M82380 in the
Master Mode that the system is requesting address
pipelining. When driven LOW by either memory or
peripheral devices during Master Mode, it indicates
that the system is prepared to accept a new address
and bus cycle definition signals from the M82380
before the end of the current bus cycle. If this input
is active when sampled by the M82380, the next ad­dress is driven onto the bus, provided a bus request
is already pending internally.

This input pin is monitored only in the Master Mode.
In the Slave Mode, the M82380 uses the ADS

and

READY

signals to determine address pipelining cy-

cles, and NA

will be ignored.

2.2.9 RESET (RESET, CPURST)

RESET

This synchronous input suspends any operation in
progress and places the M82380 in a known initial
state. Upon reset, the M82380 will be in the Slave
Mode waiting to be initialized by the i386 host

Table 2. Bus Cycle Definition

M/IO D/C W/R As INPUTS As OUTPUTS

0 0 0 Interrupt NOT GENERATED

Acknowledge
0 0 1 UNDEFINED NOT GENERATED
0 1 0 I/O Read I/O Read
0 1 1 I/O Write I/O Write
1 0 0 UNDEFINED NOT GENERATED
1 0 1 HALT if NOT GENERATED

BE(3–0)eX011

SHUTDOWN if

BE

(3–0)eXXX0
1 1 0 Memory Read Memory Read
1 1 1 Memory Write Memory Write

15

M82380

Table 3. Output Signals Following RESET

Signal Level

A2– A31, D0–D31, BE0–BE3 Float
D/C

, W/R, M/IO, ADS Float

READYO

‘1’

EOP

‘1’ (Weak Pull-UP)
EDACK2– EDACK0 ‘100’
HOLD ‘0’
INT UNDEFINED*
TOUT1/REF, TOUT2/IRQ3, TOUT3 UNDEFINED*
CPURST ‘0’

*The Interrupt Controller and Programmable Interval Timer are initialized by software commands.

processor. The M82380 is reset by asserting RESET
for 15 or more CLK2 periods. When RESET is as­serted, all other input pins are ignored, and all other
bus pins are driven to an idle bus state as shown in
Table 3. The M82380 will determine the phase of its
internal clock following RESET going inactive.

RESET is level-sensitive and must be synchronous
to the CLK2 signal. Therefore, this RESET input
should be tied to the RESET output of the Clock
Generator. The RESET setup and hold time require­ments are shown in Figure 8.

CPURST

This output signal is used to reset the i386 host
processor. It will go active (HIGH) whenever one of
the following events occurs: a) M82380’s RESET in­put is active; b) a software RESET command is is­sued to the M82380; or c) when the M82380 detects
a processor Shutdown cycle and when this detec­tion feature is enabled (see CPU Reset and Shut­down Detect). When activated, CPURST will be held
active for 62 CLK2 periods. The timing of CPURST is
such that the i386 processor will be in synchroniza­tion with the M82380. This timing is shown in
Figure 9.

271070–9
T30-RESET Hold Time
T31-RESET Setup Time

Figure 8. RESET Timing

271070–10

T33-CPU Reset from CLK2

Figure 9. CPURST Timing

16

M82380

2.2.10 INTERRUPT OUT (INT)

This output pin is used to signal the i386 host proc­essor that one or more interrupt requests (either in­ternal or external) are pending. The processor is ex­pected to respond with an Interrupt Acknowledge
cycle. This signal should be connected directly to
the Maskable Interrupt Request (INTR) input of the
i386 host processor.

2.3 M82380 Bus Timing

The M82380 internally divides the CLK2 signal by
two to generate its internal clock. Figure 7 shows the
relationship of CLK2 and the internal clock. The in­ternal clock consists of two phases: PHI1 and PHI2.
Each CLK2 period is a phase of the internal clock. In
Figure 7, both PHI1 and PHI2 of the M82380 internal
clock are shown.

In the M82380, whether it is in the Master or Slave
Mode, the shortest time unit of bus activity is a bus
state. A bus state, which is also referred as a
‘T-state’, is defined as one M82380 PHI2 clock peri­od (i.e., two CLK2 periods). Recall in Table 2, there
are six different types of bus cycles in the M82380
as defined by the M/IO

, D/C and W/R signals. Each
of these bus cycles is composed of two or more bus
states. The length of a bus cycle depends on when
the READY

input is asserted (i.e., driven LOW).

2.3.1 ADDRESS PIPELINING

The M82380 supports Address Pipelining as an op­tion in both the Master and Slave Mode. This feature
typically allows a memory or peripheral device to op­erate with one less wait state than would otherwise
be required. This is possible because during a pipe­lined cycle, the address and bus cycle definition of
the next cycle will be generated by the bus master
while waiting for the end of the current cycle to be
acknowledged. The pipelined bus is especially well
suited for interleaved memory environment. For

16 MHz interleaved memory designs with 100 ns ac­cess time DRAMs, zero wait state memory accesses
can be achieved when pipelined addressing is se­lected.

In the Master Mode, the M82380 is capable of initiat­ing, on a cycle-by-cycle basis, either a pipelined or
non-pipelined access depending upon the state of
the NA

input. If a pipelined cycle is requested (indi-

cated by NA

being driven LOW), the M82380 will
drive the address and bus cycle definition of the next
cycle as soon as there is an internal bus request
pending.

In the Slave Mode, the M82380 is constantly moni­toring the ADS

and READY signals on the processor
local bus to determine if the current bus cycle is a
pipelined cycle. If a pipelined cycle is detected, the
M82380 will request one less wait state from the
processor if the Wait State Generator feature is se­lected. On the other hand, during an M82380 inter­nal register access in a pipelined cycle, it will make
use of the advance address and bus cycle informa­tion. In all cases, Address Pipelining will result in a
savings of one wait state.

2.3.2 MASTER MODE BUS TIMING

When the M82380 is in the Master Mode, it will be in
one of six bus states. Figure 10 shows the complete
bus state diagram of the Master Mode, including
pipelined address states. As seen in the figure, the
M82380 state diagram is very similar to that of the
i386 processor. The major difference is that in the
M82380, there is no Hold state. Also, in the M82380,
the conditions for some state transitions depend
upon whether it is the end of a DMA process.

NOTE:

The term ‘end of a DMA process’ is loosely defined
here. It depends on the DMA modes of operation
as well as the state of the EOP

and DREQ inputs.
This is explained in detail in section 3ÐDMA Con­troller.

17

M82380

The M82380 will enter the idle state, Ti, upon RE­SET and whenever the internal address is not avail­able at the end of a DMA cycle or at the end of a
DMA process. When address pipelining is not used
(NA

is not asserted), a new bus cycle always begins
with state T1. During T1, address and bus cycle defi­nition signals will be driven on the bus. T1 is always
followed by T2.

If a bus cycle is not acknowledged (with READY

)

during T2 and NA

is negated, T2 will be repeated.
When the end of the bus cycle is acknowledged dur­ing T2, the following state will be T1 of the next bus
cycle (if the internal address latch is loaded and if
this is not the end of the DMA process). Otherwise,
the Ti state will be entered. Therefore, if the memory
or peripheral accessed is fast enough to respond
within the first T2, the fastest non-pipelined cycle will
take one T1 and one T2 state.

Use of the address pipelining feature allows the
M82380 to enter three additional bus states: T1P,
T2P, and T2i. T1P is the first bus state of a pipelined
bus cycle. T2P follows T1P (or T2) if NA

is asserted
when sampled. The M82380 will drive the bus with
the address and bus cycle definition signals of the
next cycle during T2P. From the state diagram, it can
be seen that after an idle state Ti, the first bus cycle
must begin with T1, and is therefore a non-pipelined
bus cycle. The next bus cycle can be pipelined if NA
is asserted and the previous bus cycle ended in a
T2P state. Once the M82380 is in a pipelined cycle
and provided that NA

is asserted in subsequent cy­cles, the M82380 will be switching between T1P and
T2P states. If the end of the current bus cycle is not
acknowledged by the READY

input, the M82380 will
extend the cycle by adding T2P states. The fastest
pipelined cycle will consist of one T1P and one T2P
state.

271070–11

NOTE:

ADAVÐInternal Address Available

Figure 10. Master Mode State Diagram

18

M82380

The M82380 will enter state T2i when NA is assert­ed and when one of the following two conditions
occurs. The first condition is when the M82380 is in
state T2. T2i will be entered if READY

is not assert­ed and there is no next address available. This situa­tion is similar to a wait state. The M82380 will stay in
T2i for as long as this condition exists. The second
condition which will cause the M82380 enter T2i is
when the M82380 is in state T1P. Before going to

state T2P, the M82380 needs to wait in state T2i
until the next address is available. Also, in both cas­es, if the DMA process is complete, the M82380 will
enter the T2i state in order to finish the current DMA
cycle.

Figure 11 is a timing diagram showing non-pipelined
bus accesses in the Master Mode. Figure 12 shows
the timing of pipelined accesses in the Master Mode.

271070–12

Figure 11. Non-Pipelined Bus Cycles

271070–13

Figure 12. Pipelined Bus Cycles

19

M82380

2.3.3 SLAVE MODE BUS TIMING

Figure 13 shows the Slave Mode bus timing in both
pipelined and non-pipelined cycles when the
M82380 is being accessed. Recall that during Slave
Mode, the M82380 will constantly monitor the ADS
and READY signals to determine if the next cycle is
pipelined. In Figure 13, the first cycle is non-pipe­lined and the second cycle is pipelined. In the pipe­lined cycle, the M82380 will start decoding the ad-

dress and bus cycle signals one bus state earlier
than in a non-pipelined cycle.

The READY

input signal is sampled by the M80386
host processor to determine the completion of a bus
cycle. This occurs during the end of every T2 and
T2P state. Normally, the output of the M82380 Wait
State Generator, READYO

, is directly connected to

the READY

input of the i386 host processor and the

M82380. In such case, READYO

and READY will be

identical (see Wait State Generator).

271070–14

NOTE:

NA

is shown here only for timing reference. It is not sampled by the M82380 during Slave Mode.
When the M82380 registers are accessed, it will take one or more wait states in pipelined and two or more wait states in
non-pipelined cycle to complete the internal access.

Figure 13. Slave Read/Write Timing

20

M82380

3.0 DMA CONTROLLER

The M82380 DMA Controller is capable of transfer­ring data between any combination of memory and/
or I/O, with any combination (8-, 16-, or 32-bits) of
data path widths. Bus bandwidth is optimized
through the use of an internal temporary register
which can disassemble or assemble data to or from
either an aligned or a non-aligned destination or

source. Figure 14 is a block diagram of the M82380
DMA Controller.

The M82380 has eight channels of DMA. Each
channel operates independently of the others. With­in the operation of the individual channels, there are
many different modes of data transfer available.
Many of the operating modes can be intermixed to
provide a very versatile DMA controller.

271070–15

Figure 14. M82380 DMA Controller Block Diagram

21

M82380

3.1 Functional Description

In describing the operation of the M82380’s DMA
Controller, close attention to terminology is required.
Before entering the discussion of the function of the
M82380 DMA Controller, the following explanations
of some of the terminology used herein may be of
benefit. First, a few terms for clarification:

DMA PROCESSÐA DMA process is the execution
of a programmed DMA task from beginning to end.
Each DMA process requires initial programming by
the host M80386 microprocessor.

BUFFERÐA contiguous block of data.

BUFFER TRANSFERÐThe action required by the
DMA to transfer an entire buffer.

DATA TRANSFERÐThe DMA action in which a
group of bytes, words, or double words are moved
between devices by the DMA Controller. A data
transfer operation may involve movement of one or
many bytes.

BUS CYCLEÐAccess by the DMA to a single byte,
word, or double word.

Each DMA channel consists of three major compo­nents. These components are identified by the con­tents of programmable registers which define the
memory or I/O devices being serviced by the DMA.
They are the Target, the Requester, and the Byte
Count. They will be defined generically here and in
greater detail in the DMA register definition section.

The Requester is the device which requires service
by the M82380 DMA Controller, and makes the re­quest for service. All of the control signals which the
DMA monitors or generates for specific channels
are logically related to the Requester. Only the Re­quester is considered capable of initiating or termi­nating a DMA process.

The Target is the device with which the Requester
wishes to communicate. As far as the DMA process
is concerned, the Target is a slave which is incapa­ble of control over the process.

The direction of data transfer can be either from Re­quester to Target or from Target to Requester; i.e.,
each can be either a source or a destination.

The Requester and Target may each be either I/O
or memory. Each has an address associated with it
that can be incremented, decremented, or held con­stant. The addresses are stored in the Requester
Address Registers and Target Address Registers,

respectively. These registers have two parts: one
which contains the current address being used in the
DMA process (Current Address Register), and one
which holds the programmed base address (Base
Address Register). The contents of the Base Regis­ters are never changed by the M82380 DMA Con­troller. The Current Registers are incremented or
decremented according to the progress of the DMA
process.

The Byte Count is the component of the DMA pro­cess which dictates the amount of data which must
be transferred. Current and Base Byte Count Regis­ters are provided. The Current Byte Count Register
is decremented once for each byte transferred by
the DMA process. When the register is decremented
past zero, the Byte Count is considered ‘expired’
and the process is terminated or restarted, depend­ing on the mode of operation of the channel. The
point at which the Byte Count expires is called ‘Ter­minal Count’ and several status signals are depen­dent on this event.

Each channel of the M82380 DMA Controller also
contains a 32-bit Temporary Register for use in as­sembling and disassembling non-aligned data. The
operation of this register is transparent to the user,
although the contents of it may affect the timing of
some DMA handshake sequences. Since there is
data storage available for each channel, the DMA
Controller can be interrupted without loss of data.

The M82380 DMA Controller is a slave on the bus
until a request for DMA service is received via either
a software request command or a hardware request
signal. The host processor may access any of the
control/status or channel registers at any time the
M82380 is a bus slave. Figure 15 shows the flow of
operations that the DMA Controller performs.

At the time a DMA service request is received, the
DMA Controller issues a bus hold request to the
host processor. The M82380 becomes the bus mas­ter when the host relinquishes the bus by asserting a
hold acknowledge signal. The channel to be serv­iced will be the one with the highest priority at the
time the DMA Controller becomes the bus master.
The DMA Controller will remain in control of the bus
until the hold acknowledge signal is removed, or un­til the current DMA transfer is complete.

While the M82380 DMA Controller has control of the
bus, it will perform the required data transfer(s). The
type of transfer, source and destination addresses,
and amount of data to transfer are programmed in
the control registers of the DMA channel which re­ceived the request for service.

22

M82380

271070–16

Figure 15. Flow of DMA Controller Operation

At completion of the DMA process, the M82380 will
remove the bus hold request. At this time the
M82380 becomes a slave again, and the host re­turns to being a master. If there are other DMA
channels with requests pending, the controller will
again assert the hold request signal and restart the
bus arbitration and switching process.

3.2 Interface Signals

There are fourteen control signals dedicated to the
DMA process. They include eight DMA Channel Re­quests (DREQn), three Encoded DMA Acknowledge
signals (EDACKn), Processor Hold and Hold Ac­knowledge (HOLD, HLDA), and End-Of-Process
(EOP

). The DREQn inputs and EDACK(0 –2) outputs
are handshake signals to the devices requiring DMA
service. The HOLD output and HLDA input are hand­shake signals to the host processor. Figure 16
shows these signals and how they interconnect be­tween the M82380 DMA Controller, and the Re­quester and Target devices.

271070–17

Figure 16. Requester, Target, and DMA Controller Interconnection

23

M82380

3.2.1 DREQn and EDACK(0 –2)

These signals are the handshake signals between
the peripheral and the M82380. When the peripheral
requires DMA service, it asserts the DREQn signal
of the channel which is programmed to perform the
service. The M82380 arbitrates the DREQn against
other pending requests and begins the DMA pro­cess after finishing other higher priority processes.

When the DMA service for the requested channel is
in progress, the EDACK(0– 2) signals represent the
DMA channel which is accessing the Requester.
The 3-bit code on the EDACK(0 – 2) lines indicates
the number of the channel presently being serviced.
Table 4 shows the encoding of these signals. Note
that Channel 4 does not have a corresponding hard­ware acknowledge.

The DMA acknowledge (EDACK) signals indicate
the active channel only during DMA accesses to the
Requester. During accesses to the Target,
EDACK(0– 2) has the idle code (100). EDACK(0– 2)
can thus be used to select a Requester device dur­ing a transfer.

Table 4. EDACK Encoding

During a DMA Transfer

EDACK2 EDACK1 EDACK0 Active Channel

000 0
001 1
010 2
011 3
1 0 0 Target Access
101 5
110 6
111 7

DREQn can be programmed as either an Asynchro­nous or Synchronous input.

The EDACKn signals are always active. They either
indicate ‘no acknowledge’ or they indicate a bus ac­cess to the requester. The acknowledge code is ei­ther 100, for an idle DMA or during a DMA access to
the Target, or ‘n’ during a Requester access, where
n is the binary value representing the channel. A
simple 3-line to 8-line decoder can be used to pro­vide discrete acknowledge signals for the peripher­als.

3.2.2 HOLD and HLDA

The Hold Request (HOLD) and Hold Acknowledge
(HLDA) signals are the handshake signals between

the DMA Controller and the host processor. HOLD is
an output from the M82380 and HLDA is an input.
HOLD is asserted by the DMA Controller when there
is a pending DMA request, thus requesting the proc­essor to give up control of the bus so the DMA pro­cess can take place. The M80386 responds by as­serting HLDA when it is ready to relinquish control of
the bus.

The M82380 will begin operations on the bus one
clock cycle after the HLDA signal goes active. For
this reason, other devices on the bus should be in
the slave mode when HLDA is active.

HOLD and HLDA should not be used to gate or se­lect peripherals requesting DMA service. This is be­cause of the use of DMA-like operations by the
DRAM Refresh Controller. The Refresh Controller is
arbitrated with the DMA Controller for control of the
bus, and refresh cycles have the highest priority. A
refresh cycle will take place between DMA cycles
without relinquishing bus control. See the Arbitration
of Refresh Requests for a more detailed discussion
of the interaction between the DMA Controller and
the DRAM Refresh Controller.

3.2.3 EOP

EOP is a bidirectional signal used to indicate the end
of a DMA process. The M82380 activates this as an
output during the T2 states of the last Requester bus
cycle for which a channel is programmed to execute.
The Requester should respond by either withdraw­ing its DMA request, or interrupting the host proces­sor to indicate that the channel needs to be pro­grammed with a new buffer. As an input, this signal
is used to tell the DMA Controller that the peripheral
being serviced does not require any more data to be
transferred. This indicates that the current buffer is
to be terminated.

EOP

can be programmed as either an Asynchro­nous or a Synchronous input. Details on synchro­nous versus asynchronous operation of this pin are
described later in this data sheet.

3.3 Modes of Operation

The M82380 DMA Controller has many independent
operating functions. When designing peripheral in­terfaces for the M82380 DMA Controller, all of the
functions or modes must be considered. All of the
channels are independent of each other (except in
priority of operation) and can operate in any of the
modes. Many of the operating modes, though inde­pendently programmable, affect the operation of
other modes. Because of the large number of com-

24

M82380

binations possible, each programmable mode is dis­cussed here with its affects on the operation of other
modes. The entire list of possible combinations will
not be presented.

Table 5 shows the categories of DMA features avail­able in the M82380. Each of the five major
categories is independent of the others. The sub­categories are the available modes within the major
function or mode category. The following sections
explain each mode or function and its relation to oth­er features.

Table 5. DMA Operating Modes

I. Target/Requester Definition

a. Data Transfer Direction

b. Device Type

c. Increment/Decrement/Hold

II. Buffer Processes

a. Single Buffer Process

b. Buffer Auto-Initialize Process

c. Buffer Chaining Process

III. Data Transfer/Handshake Modes

a. Single Transfer Mode

b. Demand Transfer Mode

c. Block Transfer Mode

d. Cascade Mode

IV. Priority Arbitration

a. Fixed

b. Rotating

c. Programmable Fixed

V. Bus Operation

a. Fly-By (Single-Cycle)/Two-Cycle

b. Data Path Width

c. Read, Write, or Verify Cycles

3.3.1 TARGET/REQUESTER DEFINITION

All DMA transfers involve three devices: the DMA
Controller, the Requester, and the Target. Since the
devices to be accessed by the DMA Controller vary
widely, the operating characteristics of the DMA
Controller must be tailored to the Requester and
Target devices.

The Requester can be defined as either the source
or the destination of the data to be transferred. This
is done by specifying a Write or a Read transfer,
respectively. In a Read transfer, the Target is the
data source and the Requester is the destination for

the data. In a Write transfer, the Requester is the
source and the Target in the destination.

The Requester and Target addresses can each be
independently programmed to be incremented, dec­remented, or held constant. As an example, the
M82380 is capable of reversing a string or data by
having a Requester address increment and the Tar­get address decrement in a memory-to-memory
transfer.

3.3.2 BUFFER TRANSFER PROCESSES

The M82380 DMA Controller allows three program­mable Buffer Transfer Processes. These processes
define the logical way in which a buffer of data is
accessed by the DMA.

The three Buffer Transfer Processes include the Sin­gle Buffer Process, the Buffer Auto-Initialize Pro­cess, and the Buffer Chaining Process. These pro­cesses require special programming considerations.
See the DMA Programming section for more details
on setting up the Buffer Transfer Processes.

SINGLE BUFFER PROCESS

The Single Buffer Process allows the DMA channel
to transfer only one buffer of data. When the buffer
has been completely transferred (Current Byte
Count decremented past zero or EOP

input active),
the DMA process ends and the channel becomes
idle. In order for that channel to be used again, it
must be reprogrammed.

The single Buffer Process is usually used when the
amount of data to be transferred is known exactly,
and it is also known that there is not likely to be any
data to follow before the operating system can
reprogram the channel.

BUFFER AUTO-INITIALIZE PROCESS

The Buffer Auto-Initialize Process allows multiple
groups of data to be transferred to or from a single
buffer. This process does not require reprogram­ming. The Current Registers are automatically repro­grammed from the Base Registers when the current
process is terminated, either by an expired Byte
Count or by an external EOP

signal. The data trans­ferred will always be between the same Target and
Requester.

The auto-initialization/process-execution cycle is re­peated, with a HOLD/HLDA re-arbitration, until the
channel is either disabled or re-programmed.

25

M82380

BUFFER CHAINING PROCESS

The Buffer Chaining Process is useful for transfer­ring large quantities of data into non-contiguous
buffer areas. In this process, a single channel is
used to process data from several buffers, while
having to program the channel only once. Each new
buffer is programmed in a pipelined operation that
provides the new buffer information while the old
buffer is being processed. The chain is created by
loading new buffer information while the M82380
DMA Controller is processing the Current Buffer.
When the Current Buffer expires, the M82380 DMA
Controller automatically restarts the channel using
the new buffer information.

Loading the new buffer information is done by an
interrupt routine which is requested by the M82380.
Interrupt Request 1 (IRQ1) is tied internally to the
M82380 DMA Controller for this purpose. IRQ1 is
generated by the M82380 when the new buffer infor­mation is loaded into the channel’s Current Regis­ters, leaving the Base Registers ‘empty’. The inter­rupt service routine loads new buffer information into
the Base Registers. The host processor is required
to load the information for another buffer before the
current Byte Count expires. The process repeats un­til the host programs the channel back to single buff­er operation, or until the channel runs out of buffers.

The channel runs out of buffers when the Current
Buffer expires and the Base Registers have not yet
been loaded with new buffer information. When this
occurs, the channel must be reprogrammed.

If an external EOP

is encountered while executing a
Buffer Chaining Process, the current buffer is con­sidered expired and the new buffer information is
loaded into the Current Registers. If the Base Regis­ters are ‘empty’, the chain is terminated.

The channel uses the Base Target Address Register
as an indicator of whether or not the Base Registers
are full. When the most significant byte of the Base
Target Register is loaded, the channel considers all
of the Base Registers loaded, and removes the in­terrupt request. This requires that the other Base
Registers (Base Requester Address, Last Byte
Count) must be loaded before the Base Target Ad­dress Register. The reason for implementing the re-

loading process this way is that, for most applica­tions, the Byte Count and the Requester will not
change from one buffer to the next, and therefore do
not need to be reprogrammed. The details of pro­gramming the channel for the Buffer Chaining Pro­cess can be found in the section of DMA program­ming.

3.3.3 DATA TRANSFER MODES

Three Data Transfer modes are available in the
M82380 DMA Controller. They are the Single Trans­fer, Block Transfer, and Demand Transfer Modes.
These transfer modes can be used in conjunction
with any one of three Buffer Transfer modes: Single
Buffer, Auto-Initialized Buffer, and Buffer Chaining.
Any Data Transfer Modes can be used under any of
the Buffer Transfer Modes. These modes are inde­pendently available for all DMA channels.

Different devices being serviced by the DMA Con­troller require different handshaking sequences for
data transfers to take place. Three handshaking
modes are available on the M82380, giving the de­signer the opportunity to use the DMA Controller as
efficiently as possible. The speed at which data can
be presented or read by a device can affect the way
a DMA controller uses the host’s bus, thereby affect­ing not only data throughput during the DMA pro­cess, but also affecting the host’s performance by
limiting its access to the bus.

SINGLE TRANSFER MODE

In the Single Transfer Mode, one data transfer to or
from the Requester is performed by the DMA Con­troller at a time. The DREQn input is arbitrated and
the HOLD/HLDA sequence is executed for each
transfer. Transfers continue in this manner until the
Byte Count expires, or until EOP

is sampled active. If
the DREQn input is held active continuously, the en­tire DREQ-HOLD-HLDA-DACK sequence is repeat­ed over and over until the programmed number of
bytes has been transferred. Bus control is released
to the host between each transfer. Figure 17 shows
the logical flow of events which make up a buffer
transfer using the Single Transfer Mode.

26

M82380

271070–18

Figure 17. Buffer Transfer in

Single Transfer Mode

The Single Transfer Mode is used for devices which
require complete handshake cycles with each data
access. Data is transferred to or from the Requester
only when the Requester is ready to perform the
transfer. Each transfer requires the entire DREQ­HOLD-HLDA-DACK handshake cycle. Figure 18
shows the timing of the Single Transfer Mode cy­cles.

BLOCK TRANSFER MODE

In the Block Transfer Mode, the DMA process is ini­tiated by a DMA request and continues until the Byte
count expires, or until EOP

is activated by the Re­quester. The DREQn signal need only be held active
until the first Requester access. Only a refresh cycle
will interrupt the block transfer process.

Figure 19 illustrates the operation of the DMA during
the Block Transfer Mode. Figure 20 shows the tim­ing of the handshake signals during Block Mode
Transfers.

271070–19

Figure 18. DMA Single Transfer Mode

27

M82380

271070–20

Figure 19. Buffer Transfer in

Block Transfer Mode

DEMAND TRANSFER MODE

The Demand Transfer Mode provides the most flex­ible handshaking procedures during the DMA pro­cess. A Demand Transfer is initiated by a DMA re­quest. The process continues until the Byte Count
expires, or an external EOP

is encountered. If the
device being serviced (Requester) desires, it can in­terrupt the DMA process by de-activating the
DREQn line. Action is taken on the condition of
DREQn during Requester accesses only. The ac­cess during which DREQn is sampled inactive is the
last Requester access which will be performed dur­ing the current transfer. Figure 21 shows the flow of
events during the transfer of a buffer in the Demand
Mode.

271070–21

Figure 20. Block Mode Transfers

28

M82380

271070–22

Figure 21. Buffer Transfer in

Demand Transfer Mode

When the DREQn line goes inactive, the DMA con­troller will complete the current transfer, including
any necessary accesses to the Target, and relin­quish control of the bus to the host. The current pro­cess information is saved (byte count, Requester
and Target addresses, and Temporary Register).

The Requester can restart the transfer process by
reasserting DREQn. The M82380 will arbitrate the
request with other pending requests and begin the
process where it left off. Figure 22 shows the timing
of handshake signals during Demand Transfer Mode
operation.

Using the Demand Transfer Mode allows peripherals
to access memory in small, irregular bursts without
wasting bus control time. The M82380 is designed to
give the best possible bus control latency in the De­mand Transfer Mode. Bus control latency is defined
here as the time from the last active bus cycle of the
previous bus master to the first active bus cycle of
the new bus master. The M82380 DMA Controller
will perform its first bus access cycle two bus states
after HLDA goes active. In the typical configuration,
bus control is returned to the host one bus state
after the DREQn goes inactive.

There are two cases where there may be more than
one bus state of bus control latency at the end of a
transfer. The first is at the end of an Auto-Initialize
process, and the second is at the end of a process
where the source is the Requester and Two-Cycle
transfers are used.

When a Buffer Auto-Initialize Process is complete,
the M82380 requires seven bus states to reload the

271070–23

Figure 22. Demand Mode Transfers

29

M82380

Current Registers from the Base Registers of the
Auto-Initialized channel. The reloading is done while
the M82380 is still the bus master so that it is pre­pared to service the channel immediately after relin­quishing the bus, if necessary.

In the case where the Requester is the source, and
Two-Cycle transfers are being used, there are two
extra idle states at the end of the transfer process.
This occurs due to housekeeping in the DMA’s inter­nal pipeline. These two idle states are present only
after the very last Requester access, before the
DMA Controller de-activates the HOLD signal.

3.3.4 CHANNEL PRIORITY ARBITRATION

DMA channel priority can be programmed into one
of two arbitration methods: Fixed or Rotating. The
four lower DMA channels and the four upper DMA
channels operate as if they were two separate DMA
controllers operating in cascade. The lower group of
four channels (0 – 3) is always prioritized between
channels 7 and 4 of the upper group of channels (4–

7). Figure 23 shows a pictorial representation of the
priority grouping.

The priority can thus be set up as rotating for one
group of channels and fixed for the other, or any
other combination. While in Fixed Priority, the pro­grammer can also specify which channel has the
lowest priority.

271070–24

Figure 23. DMA Priority Grouping

The M82380 DMA Controller defaults to Fixed Priori­ty. Channel 0 has the highest priority, then 1, 2, 3, 4,
5, 6, 7. Channel 7 has the lowest priority. Any time
the DMA Controller arbitrates DMA requests, the re­questing channel with the highest priority will be
serviced next.

Fixed Priority can be entered into at any time by a
software command. The priority levels in effect

after the mode switch are determined by the current
setting of the Programmable Priority.

Programmable Priority is available for fixing the prior­ity of the DMA channels within a group to levels oth­er than the default. Through a software command,
the channel to have the lowest priority in a group
can be specified. Each of the two groups of four
channels can have the priority fixed in this way. The
other channels in the group will follow the natural
Fixed Priority sequence. This mode affects only the
priority levels while operating with Fixed Priority.

For example, if channel 2 is programmed to have the
lowest priority in its group, channel 3 has the highest
priority. In descending order, the other channels
would have the following priority: (3, 0, 1, 2), 4, 5, 6,
7 (channel 2 lowest, channel 3 highest). If the upper
group were programmed to have channel 5 as the
lowest priority channel, the priority would be (again,
highest to lowest): 6, 7, (3, 0, 1, 2), 4, 5. Figure 24
shows this example pictorially. The lower group is
always prioritized as a fifth channel of the upper
group (between channels 4 and 7).

High Priority

Low Priority

271070–25

Figure 24. Example of Programmed Priority

The DMA Controller will only accept Programmable
Priority commands while the addressed group is op­erating in Fixed Priority. Switching from Fixed to Ro­tating Priority preserves the current priority levels.
Switching from Rotating to Fixed Priority returns the
priority levels to those which were last programmed
by use of Programmable Priority.

Rotating Priority allows the devices using DMA to
share the system bus more evenly. An individual
channel does not retain highest priority after being
serviced, priority is passed to the next highest priori­ty channel in the group. The channel which was
most recently serviced inherits the lowest priority.
This rotation occurs each time a channel is serviced.
Figure 25 shows the sequence of events as priority
is passed between channels. Note that the lower
group rotates within the upper group, and that serv­icing a channel within the lower group causes rota­tion within the group as well as rotation of the upper
group.

30