![](http://datasheet.mmic.net.cn/350000/CD1865_datasheet_16531773/CD1865_28.png)
CD1865
—
Intelligent Eight-Channel Communications Controller
28
Datasheet
request stack. At this time the CD1865 is ready to be serviced on another of its outstanding
requests. If another request of the same level is pending, two clock periods after the write to are
required for the CD1865 to reassert the request line.
Because the CD1865 has a service request stack, it can support nested-service requests. For
example, the host can be in middle of a Transmit Service Request, detect that Receive Service
Request has asserted, process the Receive Service Request, and after exiting the receive service
routine, resume the Transmit Service Request. The CD1865 stack is three deep, so all three types
(one of each) can be nested if required. The current service request context (for example, the stack)
is readable in the Service Request Status register.
The Global Channel registers (GCR) are actually three registers that provide the number of the
channel requesting service. Reading any of these registers causes the CD1865 to mask in three bits,
specifying the channel number of the currently active channel. Normally these registers are read by
the host when it is handling a service request. In this case, the three bits are the number of the
channel requesting service. If any of the three GCR registers are read when the CD1865 is not in a
service-request context, the three bits are the current value in the CAR. The current channel
number is masked into the contents of bits 4:2 of this register by the CD1865 when it is read by the
host. The actual contents of the register are not modified.
These three registers are provided as a convenience to the user. In most applications, the user only
uses one of these locations, and set the register to some arbitrary value. However, it may be useful
to record information about the state of the CD1865 (or the software driving it) that is associated
with each of the three service-request types. In this case, the user can store whatever information is
required in the unused bits. Then, when entering a service routine, the software can check these bits
to find what state they were left in, and this could be used as a
‘
sub-vector
’
.
5.3.2
Internal Implementation of the Service Request Logic
As discussed above, the heart of each service request level is an asynchronous state machine. This
state machine has three inputs:
MATCH from the Priority Interrupt Level register comparator,
ACKIN* from the host system, and
INTERNAL_REQUEST from the CD1865.
Note:
Software acknowledgments (reads from the Service Request Acknowledge registers), in effect,
force the MATCH value true for their respective level.
It also has three outputs:
Svc_Req to the host system,
INTERNAL_GRANT to the CD1865, and
ACKOUT*, which is combined with the other two ACKOUT* signals to provide ACKOUT*
to the next CD1865 in the daisy chain.
Figure 5 on page 30
shows logic implemented by the state machine, which is described in
Table 3
.