National Semiconductor PC16552C, Manual

Page: 7 / 24

The INTR GAL É on the PC16552C Adapter drives the IRQ3
and IRQ4 signals. INTR inputs the interrupt signals from the
PC16552C (INTR1 and INTR2) and the TC interrupt (see
DMA Interface). INTR will assert IRQ3 if a TC interrupt is
generated or if a UART channel configured as COM2 – 8
generates a serial interrupt. It will assert IRQ4 if it receives a
serial interrupt from a channel configured as COM1. INTR
decodes the serial interrupts by using POS102 bits 5 and 2
which store address bit A8 for channels 1 and 2 respective-
ly. A8 is used because it is a 1 if COM1 is being used and a
0 if any other COM port is used. See the included INTR.ABL
listing for the GAL equations.
MICRO CHANNEL BUS ARBITRATION
The PC16552C Dual Serial/DMA Adapter implements the
logic necessary to interface a DMA slave device to the Mi-
cro Channel’s bus arbitration system and DMA controller. A
DMA slave adapter must contain a Local Arbiter, as defined
by IBM, in order to compete for the bus and communicate
with the system’s Central Arbiter. The adapter must also
contain any logic necessary to directly support the device
requesting DMA service.
The following material on the DMA Interface discusses the
function of the Central Arbiter and the bus arbitration pro-
cess, Local Arbiters and DMA interface design considera-
tions. It then describes in detail the functions of the DMA
interface logic implemented on the PC16552C Adapter.
Central Arbiter
The Central Arbiter exists on all of IBM’s Micro Channel
machines and gives intelligent subsystems the ability to
share and control the system. It supports up to 16 arbitrating
devices, such as a DMA slave, a bus master and the system
microprocessor.
The Central Arbiter is located on the system board of the
Micro Channel machines and uses seven Micro Channel
signals to control arbitration between devices. The seven
signals are PREEMPT, ARB/GNT, BURST and ARB3 – 0.
ARB/GNT may only be driven by the Central Arbiter. The
rest of the signals may be driven by any device on the Chan-
nel and therefore must be connected to open-collector driv-
ers.
Any device requesting control of the bus asynchronously
drives PREEMPT active. The Central Arbiter responds by
initiating an arbitration cycle after the device currently using
the Channel has completed. The Central Arbiter indicates
the arbitration cycle by driving the ARB/GNT signal high
into the arbitration state. Requesting devices then drive their
assigned 4-bit arbitration vector onto the ARB3 – 0 bus.
These vectors are prioritized with 0000 being the highest
and 1111 being the lowest priority. Each competing device
compares the vector it is driving onto the ARB pins with the
level already on the bus. If it finds a level that has a higher
priority it stops driving its vector onto the bus, thus leaving
the highest priority vector on the bus. When the Central
Arbiter ends the arbitration period by changing the ARB/
GNT signal to the grant state, the device driving the winning
vector assumes control of the bus.
Devices requiring multiple data transfers must notify the
central arbiter by driving the BURST signal until all transfers
are complete. A bursting device may also stop transfers
if another device drives PREEMPT active, thus postponing
any further transfers until it wins the system channel again.
IBM
É
requires a bursting device not to ignore an active
PREEMPT for more than 7.8 m s (thus 7.8 m s is the maxi-
mum time allowed for a single BURST transfer). At this time
the Central Arbiter forcibly takes control away from the
bursting device by raising the ARB/GNT signal. The system
will also generate an error indication and NMI.
The Central Arbiter recognizes the end of a transfer when
both status signals (S0 and S1) are inactive (signifying the
end of a bus cycle) and BURST or CMD go inactive, which-
ever occurs last. Arbitration then begins for the next highest
priority requesting device. The system CPU, which is as-
signed the lowest priority arbitration vector 1111, will re-
sume control of the system bus if no other devices are re-
questing the bus.
A programmable (through POS) fairness feature prevents
high priority devices from locking out lower priority devices.
If fairness is active, a device that has control of the bus
cannot compete again for the bus until all other competing
devices have been allowed to run their cycles. This ensures
that all arbitrating devices will be serviced in order of priority
before the same device can gain control of the channel
again.
The system DMA controller is an integral part of the Central
Arbiter. The controller has 8 channels (0 – 7) which corre-
spond to arbitration vectors 0000 – 0111. A device request-
ing DMA service competes for the system bus with the vec-
tor corresponding to the DMA channel previously pro-
grammed to perform the desired transfer. The DMA control-
ler assumes control of the bus when the highest priority
requesting DMA wins the arbitration cycle. The controller
will execute single byte transfers unless the DMA slave as-
serts the BURST signal. In this case, the controller will exe-
cute a burst cycle, executing transfers until the BURST sig-
nal is deasserted or the controller’s Terminal Count (TC) is
reached. See the Software section of this document for de-
tails on the operation and programming of the DMA control-
ler.
Local Arbiter
Devices requesting control of the Micro Channel must im-
plement logic known as a Local Arbiter. The Arbiter logic
must drive the arbitration bus in a manner that allows all
competing devices to recognize a winner.
When the Central Arbiter starts an aribtration, a competing
local arbiter drives its vector onto the ARB bus. At the same
time, it compares that vector to the value appearing on the
bus on a bit-by-bit basis beginning with the most significant
bit, ARB3. If it finds a mismatch on one of the bits, it will
cease driving that bit and all lower order bits. If it subse-
quently finds a match on that bit, it will continue driving low-
er order bits until another mismatch is detected. The arbitra-
tion bus must be driven by open collector drivers so that
multiple devices may drive the bus and compete for service.
The following is an example of a bus arbitration:
1. Devices A and B, with arbitration levels 1001 and 0110
respectively, compete for the channel. Both devices drive
their vectors onto the ARB bus which then appears as
0000.
7