CD1865 Datasheet, PDF (26/150 Pages) Intel Corporation – Intelligent Eight-Channel Communications Controller

CD1865 — Intelligent Eight-Channel Communications Controller
5.3
5.3.1
Service Request and Interrupt Operation
The CD1865 enhances design efficiency, because it is an intelligent device that more closely
resembles an add-in controller board than a mere collection of TTL. Conventional UARTs are
basically passive, ‘dumb’ logic. For example, when polling a device for channels requiring service,
each channel is not individually tested. Because of this, certain restrictions are placed on when and
how FIFOs are accessed. The CD1865 processor must determine what the host is doing, and when
to manage the queue of events correctly and efficiently.
Interrupt-Driven Versus Polled
Choosing the software interface, interrupt-driven versus polled, is critical to overall system
performance. This choice also affects how the software is written. In hardware implementation, a
programmer has a choice of Mixed mode, that is, when to poll versus when to be interrupt-driven.
Mixed-mode operation allows a programmer to optimize the efficiency of the system according to
changing needs. The advantages of each method are discussed in Section 5.5.
Theory of Operation
The CD1865 has three independent service request levels, one for each of the three categories —
Receive, Transmit, and Modem signal change. The priority of these lines is not fixed, but can be
determined in one of the following three ways:
• It can be set within the CD1865 by the AutoPriority Option bits.
• A system designer can assign priorities by the manner in which the three service request lines
are connected to the host interrupt controller.
• Under software control, the host system can define and redefine the order of service requests.
The Service Request interface to the host is implemented with five signals — *, *, *, ACKIN*, and
ACKOUT*. *, *, and * are asserted when a service request is pending; ACKIN* is asserted during
service-acknowledgment cycles; and ACKOUT* is used in multiple CD1865 designs to share
service requests and daisy-chain acknowledgments.
Whenever the CD1865 processor determines that one or more channels need service from the host,
it loads the appropriate service-request state machine with the information about the type of
request. The service-request state machine for that level then asserts its request signal. Note that all
three request signals can be active at the same time. At this point, the CD1865 has not determined
which request should be handled first — it simply asserts any and all lines, as required by the status
of various channels. (This is true even if the AutoPri Option is enabled; AutoPri takes effect when
a service request is acknowledged, and at that time the CD1865 determines which is the most
important request.)
The host, after noticing that one or more of the three service request pins are active — either
because the host is interrupted or it polled an external or internal CD1865 status register — decides
which of the requests (if more than one is active) it services first. The host begins the service
operation by issuing a Service Acknowledge cycle. The purpose of this cycle is to cause the
CD1865 to set up its internal state for that type of request. (Note that if AutoPri is set, it is not
necessary for the host determine which level of service request to acknowledge; it simply
acknowledges the CD1865 request and the CD1865 returns the vector for the highest-priority
active request.)
26
Datasheet