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

CD1865 — Intelligent Eight-Channel Communications Controller
Note that thirty-two CD1865s is the logical limit per daisy chain. Since it takes over 1000 ns for an
acknowledgment to ripple down 32 devices, it may not be efficient to have one long chain in
heavy-traffic applications.
Note:
In some systems that daisy chain many CD1865 devices, a potential timing hazard exists if the host
processor does not allow sufficient time for the removal of the ACKIN*/ACKOUT* daisy-chain
signal to propagate through all devices. In the event that the host processor begins I/O operations
with another section of logic and applies DS* (RD* or WR* in an Intel environment) while an
active ACKIN* is being applied to a CD1865 due to propagation delay time, unpredictable results
can occur. This constitutes an illegal acknowledge cycle. The failure mode is most often a cessation
of service requests from the device, especially of the type that is being serviced when the illegal
access occurs. Take care to ensure that the 35-ns propagation delay per device is included in any
wait-state generation.
5.5.7
Multiple CD1865s without Cascading
It is possible to interface several CD1865s without using the cascade feature. There is an advantage
to this because as there is less delay incurred while waiting for the service acknowledgment to
ripple down a chain of devices. There are two possible disadvantages. If each of the CD1865’s
three service request lines has a separate input to the interrupt controller, the interrupt controller is
more complex, and the fair-share feature does not work. If the service request lines are wire-
OR’ed, fair share works, but the host has to test each CD1865 in turn to see which one generated
the service request. To implement this method, simply connect the CD1865 address and data lines
in the usual manner.
5.5.8
Acknowledging Service Requests
As mentioned in Section 5.5 on page 35, two different methods are used to acknowledge a service
request. One method is hardware-based, and the other is software-based. The hardware-based
mechanism is a specific type of bus cycle that uses the ACKIN* and ACKOUT* signals and the in
the CD1865. An acknowledge cycle is defined where ACKIN* and DS* are active and CS* is
inactive. This method is used by processors that perform interrupt acknowledge cycles, such as the
680X0.
The software-based mechanism uses three registers — Receive Request Acknowledge register,
Transmit Request Acknowledge register, and Modem Request Acknowledge register. Reading any
of these registers has the effect of acknowledging a service request, and the data read is the
appropriate vector, that is, the contents of the Global Interrupt Request Vector register. The low-
three bits of this register are modified to indicate the specific type of interrupt being acknowledged.
If the host reads these registers when no service request is pending, either of two things can
happen. If daisy chaining of acknowledgments is enabled, the ACKOUT* pin of the CD1865
asserts. If daisy chaining is not enabled, the part supplies a vector with the low-three bits set to a
‘0’. Thus, it is possible to ‘fish’ for service requests, that is, to acknowledge each CD1865 in turn
until a non-zero vector is received.
‘Fishing’ is not usually an efficient software technique, but can be useful in some circumstances.
For example, in systems that are normally interrupt-driven, but where interrupts are not available
for diagnostics or other reasons, the host can determine if a service request is pending by reading
the appropriate Request Acknowledge register. The CD1865 must be configured not to daisy chain;
in this case it returns a vector if a request is pending, or ‘00’ if no request is pending. The host can
try all three levels of request in turn. This method works for either single CD1865s or multiple
44
Datasheet