Register-Read Acknowledgment and Prioritization for Integration With a Hardware-Based Interrupt Acknowledgment Mechanism

This invention relates generally to the architecture of computer systems. Particularly, it relates to the use of a host processor (or other common resource) for control/service of a potentially large number of devices such as peripherals, slave processors, or co-processors. For example, the invention can replace an architecture wherein numerous peripheral-device controllers make interrupt requests to a host processor with one wherein the host processor performs I/O reads and writes to a few service-request registers.

Often events occur in peripheral devices that require the attention of a host processor or CPU. Typically the intervention is provided by a control or service program executing on the host processor. An example of an event is when new data is available for transfer from a peripheral device to a host processor. Another example of an event is when a device is ready to accept new data for transfer from a host processor to the device. These service needs of peripheral devices must be communicated in a timely manner from the peripheral devices to the host processor. A specialized controller is sometimes used to communicate the service needs and may be quite specialized for that particular peripheral device. In addition, the service needs require timely communication between the host processor and the devices.

In the prior art, two basic approaches are known for communicating such service needs or requests from a device to a host processor. The first method is interrupts, wherein the regular sequence of instruction execution of the host processor is interrupted and control is transferred to a device service routine. Interrupts or interrupt requests typically involve dedicated hardware and control signals. The second method is polling, wherein the host processor frequently interrogates each device controller to obtain its current status. The host processor tests this status and then transfers control to a device service routine if required. Polling generally requires software executing on the host to check if a peripheral device has a service need.

One substantial drawback to interrupts is the overhead required to switch contexts between the regular sequence of instruction execution and the execution of an interrupt-driven routine to service the device. Context refers to the present state of registers and memory values that the host is presently operating with. The current values in all, or many, of the host processor's registers and counters are typically saved in main memory before control is transferred to the device service routine, thereby saving the present context before servicing an interrupt. In addition, these saved values are restored to the registers after the device service routine finishes and before control returns to point in the regular sequence of instructions where it was interrupted, thereby restoring the original context. Alternatively, a second set of hardware registers dedicated solely to interrupt service may be implemented. Either alternative requires additional hardware costs and complexity. Processor execution time is degraded by having to save the host context and then return to that context to proceed with further operations.

Another disadvantage to interrupts is the overhead that is required to identify which one of various devices requires service of the current interrupt request. It is common for an interrupt-driven service routine to poll, as its first task, the various device controllers it supports to determine which one initiated the current interrupt. One approach to reducing this time and complexity is to encode a vector in the hardware-level interrupt request. This vector specifies which type of interrupt, out of a handful of possible interrupt types or vector values, occurred. In such vectored interrupt systems, the overhead time between the interrupt occurrence and the start of the "useful" portion of the device service routine is reduced. This reduction in processing time occurs at the expense of additional hardware cost and complexity, thus the system architecture typically supports only a handful of possible values of interrupt vectors. In many systems, interrupt vectors are scarce resources that must be wisely allocated to optimize overall system performance. Due the limited number of different vector values, conflicts among various peripheral devices over the use of an interrupt vector are common occurrences when configuring or reconfiguring 286-based or 386-based personal computer systems. The drawbacks of vectored interrupts becomes onerous in data communications applications, where one may need to support 50 to 100 user terminals from a single host processor. Whether or not vectored interrupts are used, host processors that service a large number of communications channels must spend a significant fraction of their processor resources (e.g. CPU time) entering and exiting interrupt-driven device service routines, if support of the communications channels is solely through interrupts.

In contrast to the interrupt approach, some host processors poll the devices they support, i.e. they interrogate each of the device controller(s) they support to obtain the current status of the device(s) that the particular controller supports. The polling approach eliminates the host processor time required to enter and exit interrupt service routines and the hardware required to support interrupts. Nevertheless, polling typically requires that a significant, and possibly a very substantial, portion of the host processor time be spent polling, i.e. performing these interrogations and the associated tests of the status information obtained to see if any device requires service. In order to respond promptly to service requests when they do occur, the host processor must frequently interrogate each device controller such that it is unlikely that any particular interrogation reveals a service request.

Servicing the needs of peripheral devices also requires that appropriate priorities be established. For example, if a host processor supports a disk and a keyboard, then a delay of 100 ms in servicing an interrupt from the keyboard is likely to be imperceptible. However, a delay of 10 ms in servicing an interrupt from a disk may have an adverse effect such that the disk's continued rotation during the service delay has left the disk and read/write head mis-positioned for the present action requesting the interrupt or the next action. Appropriate prioritization of device service requests increases the hardware cost and complexity and/or increases the host processor time requirements. This applies both to interrupt-based and to polled architectures.

In the prior art, a major challenge for a computer system designer was to somehow transform a steady but unpredictable stream of service requests from a multitude of devices into something that the host processor can manage and control economically. FIG. 1 shows a prior-art solution to the device-service problem. One or more interrupt request lines from peripheral device(s) were connected to a hardware device called an interrupt controller. The interrupt controller could possibly consist of discrete logic or a separate monolithic integrated circuit. Interrupt controllers typically have the capacity to receive a handful of individual interrupt request inputs from peripheral devices. The interrupt request inputs are prioritized among potentially simultaneous requests according to some algorithm that is fixed within the controller hardware. In response to the assertion of an interrupt request, the controller asserts a master interrupt request signal to its host processor. On receipt of an interrupt acknowledgment signal from the host processor, the controller asserts an interrupt acknowledge signal to the specific peripheral device which is being acknowledged. The peripheral device responds to the acknowledgment by placing an interrupt vector on the data bus. The interrupt vector generally contained information of which peripheral or group of peripherals made the request so that the host knew which device to talk to. Depending on the function and sophistication of the peripheral device, the peripheral device (it) may enter a specific interrupt "context" or state to facilitate the performance by the host processor of the task that required service. To improve the process of a stream of interrupt requests from the same device, queues were introduced. A queue is a method of stacking many requests on top of one another. Thus the host processor can process a queued stack of interrupts from the same device or ensemble of devices. Since these am usually similar types of interrupts the host processor stays in the same context. Thus the efficiency of the interrupt handling is improved.

FIG. 2 shows another prior-art solution to improve the performance of handling interrupt requests. Using some discrete or "glue" logic in addition to interrupt control hardware, the interrupt request lines from the peripheral controller are OR'ed together and the result presented to the interrupt controller. This is done to conserve the limited interrupt request inputs to the controller. The controller responds to the interrupt request by interrupting its host processor. However, rather than provide an interrupt acknowledgment signal to the peripheral controller that causes the peripheral controller to provide an interrupt vector, the interrupt controller provides a vector to the host processor that sends it to a generic interrupt service routine. The host processor relies on additional features implemented in "glue" logic to read the individual status of the interrupt request lines from the peripheral controller. This enables the interrupt routine to determine which interrupt request signals are active and choose which one to acknowledge. The acknowledgment is provided by glue logic that decodes the processors attempt to read from a certain address or addresses and activates a selected interrupt acknowledgment signal to the peripheral controller. The controller responds to the acknowledge signal by driving an interrupt vector onto the data bus. The host processor receives this vector as the data resulting from this glue logic-based read operation.

All these prior art solutions have involved signals that form a sort of "handshake" that must be supported by external dedicated hardware elements within the system, called controllers. Because of this hardware, interrupt-handling systems have been inherently inflexible and dedicated to one users system. It is desirable to have a flexible system that is software programmable such that many users can reconfigure one chip in order that the desired interrupt interface can be easily supported and reconfigured.

A register-based computer architecture is particularly suited for using a common resource, such as a host processor or CPU, to respond to multiple devices such as co-processors, slave processors, or peripherals via service requests initiated by these devices. The invention's register acknowledgment and service prioritizing features are preferably added to, and integrated with, a prior-art, hardware-based interrupt acknowledgment mechanism, thus providing enhanced flexibility and performance. This architecture includes features for enhancing the support of a service-request based or queue-driven interface between the host processor and the supported devices, including a Service Request Status Register, a Service Request Configuration Register, and Service Request Acknowledge Register(s). From the point of view of the host processor, these registers are accessed as normal input/output read/write operations. From the point of view of the supported devices, such register operations appear to be interrupt acknowledgment operations. This transformation is effected by special-purpose logic within the architecture. The invention is preferably embodied in a monolithic integrated circuit that supports control by the host processor of a potentially large number of data communications ports. These features can be incorporated in pin compatible new versions of existing devices so as to be backwards compatible with the existing devices, thus allowing end users to gracefully upgrade their systems with minimal effort.

It is an object of the invention to provide a register-based acknowledgment mechanism and a traditional hardware-based mechanism in the same device. This combination supports a variety of hardware-based and software-based acknowledgment strategies to be employed by the host CPU in its interactions with the device.

A related object of the invention is to permit the enabling and disabling of the daisy-chain capability of the service acknowledgment mechanism under host software control, thus providing for backwards compatibility and a graceful introduction of the above-mentioned combination into existing designs or actual systems.

Another object of the invention is to provide features for prioritizing service requests by the device, either with regard to the types of requests which it may itself be asserting, or with regard to the shared requests made by an ensemble of devices. The sharing of requests of like type is typically performed by a wired-OR connection of like service requests. The device prioritizes those requests according to user selectable options, and assigns the highest priority available request to the next received service acknowledgment. Upon receiving a prioritizable acknowledgment, the device either accepts the acknowledgment indicating by the modified service vector the type of request for which the acknowledgment is accepted or passes the acknowledgment down the daisy-chain to a device having the highest priority available request.

A related object of the invention is to permit the wired-OR sharing of request types of unlike type with predictable and usable results by means of the above-mentioned auto-prioritization mechanism.

Another object of the invention is to provide a new service acknowledgment vector type to be used by the device when the daisy-chaining of service acknowledgments is disabled by the host. This new acknowledgment vector type is used by the device to indicate to the host device that an attempted service acknowledgment was not accepted by the device because the device had no service request pending which was a suitable match to the type of service acknowledgment it received at the time of receiving the service acknowledgment.

FIG. 1 illustrates the prior art method of an interrupt controller handling multiple interrupt request signals from N peripheral devices.

FIG. 2 illustrates the prior art method of ORing interrupt request signals so that a greater number of peripheral devices can share the limited capacity of the interrupt controller.

FIG. 3 illustrates the block diagram of the monolithic device described in Wishneusky U.S. Pat. No. 4,975,828 that is improved by this invention.

FIG. 4 illustrates the Service Request Control Register

FIG. 5 illustrates the Service Request Acknowledge Registers titled Modem Request Acknowledge Register, Transmit Request Acknowledge Register, and Receive Request Acknowledge Register.

FIG. 6 illustrates the Service Request Status Register.

FIG. 7 illustrates the block diagram of the present invention.

FIG. 8 illustrates how the invention allows the CL-CD1864 to be daisy chained together to support more than eight peripheral devices.

FIG. 9 illustrates the Global Service Vector Register with the five most significant bits user modified. The lower three bits [IT2, IT1, IT0] are supplied upon a read operation only. Combining the five most significant bits of the Global Service Vector Register with the IT2, IT1, and IT0 bits represents the Modified Service Vector provided onto the data bus during addressing as if reading one of the Service Request Acknowledge Registers.

FIG. 10 illustrates the Modem Service Match Register.

FIG. 11 illustrates the Transmit Service Match Register.

FIG. 12 illustrates the Receive Service Match Register.

FIG. 13 illustrates the End of Service Routine Register.

The preferred embodiment of the present invention is realized in a monolithic integrated circuit (IC). The IC that first embodied the present invention is known as the CL-CD1864. It is an intelligent eight-channel communications controller manufactured by Cirrus Logic, Inc. assignee of the present invention. It is described in Appendix I, entitled "CL-CD1864 Preliminary Data Sheet", which is also incorporated herein by reference. Further details of the portions of the CL-CD1864 containing the present invention are given in Appendix II, entitled "Register Acknowledge and Auto Priority Design Notes", which is hereby incorporated by reference. In some cases, the exact terminology, representations and level of detail used in these appendices varies from that used in this disclosure.

The CL-CD1864 is controlled by an external host processor or CPU, which may support a potentially large number of data communications channels. A data communications channel is also referred to as a communication port. The present invention includes an improvement over prior art methods by providing a novel interface between the external host processor and the CL-CD1864 that supports service requests. The present invention includes an improvement in the Bus Interface Logic (BIL) in FIG. 2 of Wishneusky U.S. Pat. No. 4,975,828, reproduced herein as FIG. 3. The CL-CD1864 is designed to interface and process signals from eight modem-like devices. It will be obvious to one skilled in the art that the present invention can be readily adapted to interface with other quantities and with other types of peripheral devices, particularly serial I/O devices.

A "Service Request" to the host represents more than an Interrupt Request. An "Interrupt Request" (IREQ) is a general single interrupt signal that a dedicated hardware interrupt controller would receive from a peripheral Input/Output device. The Interrupt Request conveys no information regarding what the peripheral I/O device desires. A Service Request is a term that embodies applications and situations that not only use a dedicated hardware interrupt controller, but also include various methods of direct host processor involvement requiring the recognition of a particular type of service request and a response to it. This invention provides for three basic types of service requests. These are Receive Service Request (RREQ*), Transmit Service Request (TREQ*), and Modem Signal Change Service Request (MREQ*) which can be programed to generate service requests for various reasons. The Receive Service Request tells the host processor that either the CL-CD1864 has received a programmable level of valid data (Receive Good Data) or that an error or other special condition has occurred in receiving the data (Receive Exception). A Transmit Service Request tells the host processor that either the CL-CD1864 has completely transmitted all characters or that the internal 8 byte Transmitter FIFO is empty and can now be filled. A Modem Signal Change Service Request tells the host that one of the modem control signal inputs (DSR,CD,CTS) has changed its logic level. The term Service Request is used throughout and shall refer to RREQ*, TREQ*, MREQ*, as well as future service requests that are obvious to those skilled in the art.

[For Cirrus Logic Inc. data communication controllers, the act of service request or interrupt acknowledgment causes the controller to enter an internal "context" wherein the parameters of a specific service request are made specifically available for the duration of the service. These parameters include the channel requiring service (affects device addressing automatically selecting the appropriate channel's registers), pointer(s) to the appropriate FIFO(s), channel status, data transfer counts, etc.]

Different external host processors accept interrupt signals in varying ways. Devices manufactured by Cirrus Logic such as the CL-CD180 and CL-CD2401 support multiple distinct request types, each having a different system level priority. However, Intel bus based systems have a limited number of interrupt request types available. This forces a compromise to be made in that several different request types are funneled into a common request signal in order to conserve scarce interrupt request resources. Typically interrupt requests were acknowledged by a single signal.

This preferred embodiment of the invention provides for any of the three types Service Requests RREQ*, TREQ*, MREQ* to be acknowledged by reading a respective Service Request Acknowledge Register or by the traditional acknowledgment input signal, ACKIN*. The following describes how the host interfaces with the invention.

When a CL-CD1864 is not daisy chained to further devices (such as CL-CD1864 chips), the host processor may assert a chip select of a particular CL-CD1864 and read one of the Service Request Acknowledge Registers of the particular CL-CD1864 by asserting the unique address of the particular register onto the address bus to find local status of the device. The Service Request Acknowledge Registers represent pseudo-registers that can only be read to provide a Modified Service Vector onto the data bus. FIG. 9 illustrates the Global Service Vector Register. The Modified Service Vector is an eight bit value with the upper 5 bits from the upper five bits of the Global Service Vector Register and the lower three bits respectively being the bits IT2, IT1, and IT0. The ITn bits (IT2, IT1, and IT0) may vary depending on which Service Request Acknowledge Register is addressed as described below in the hardware description. The host reading one of the Service Request Acknowledge Registers (MRAR, TRAR, RRAR) is analogous to a traditional interrupt acknowledgment by the host processor. Even though daisy chaining is not being used, a Modified Service Vector is read out onto the data bus just as if a conventional interrupt acknowledge cycle were performed.

In the case that daisy chaining is being used the preferred embodiment of the invention supports global service request acknowledgment by addressing as if reading the Service Request Acknowledge Registers from one particular device.

While the prior art interrupt controller devices have allowed daisy chaining (also known as cascading) via hardware, the present invention offers the flexibility of using daisy chaining for register based acknowledgments of the CL-CD1864 by programing a Service Request Configuration Register as well as using the traditional hardware acknowledgment via ACKIN*. For register based acknowledgments the preferred embodiment of the invention further allows the daisy chaining to be turned on and off by a control bit within the Service Request Configuration Register, disabling the generation of ACKOUT* in response to the host addressing as if reading a Service Acknowledge Register and no local Service Request pending such that the device wants to pass. Configuring the connections of a number of CL-CD1864 devices for daisy chaining is illustrated by FIG. 8. Using software, a single bit (DaisyEn) can be toggled within the Service Request Configuration Register in order to turn daisy chaining on or off. Via this register the host processor can easily vary its configuration for handling Service Requests. In the daisy chain configuration each CL-CD1864 within a chain has a unique vector 5 bit chip ID that was programed into its Global Service Vector Register by the host upon initialization. These five bits of chip ID and three other bits (IT2, IT1, and IT0), representing the Modified Service Vector, are supplied to the host on the data bus by one CL-CD1864 in the chain in response to a service request acknowledgment that is performed by the host.

A second daisy chaining bit can be used to further control the daisy chain by turning on and off the ACKIN* signal from generating ACKOUT*. This would allow the host to further balance the work load received from various devices. Also the host can reconfigure the service request system if an upgrade is required for the addition of different peripheral and CL-CD1864 devices.

In the prior art prioritization was either fixed in the hardware via the configuration of peripheral devices with the interrupt controller or was controlled by the software interrupt routines used by the host. The present invention offers the flexibility of assignment of priorities for the automatic prioritization of either global external service requests across an ensemble of daisy chained devices or the automatic prioritization of local service requests for that particular device only.

In the case of global external service requests, multiple CL-CD1864 devices are daisy chained together, each generating service requests. If autoprioritization is selected within each CL-CD1864 that is daisy chained, then the host need only acknowledge one of the CL-CD1864's in the chain (typically the first in the chain) and the CL-CD1864 in the chain with the highest-priority service request will answer the service request acknowledgment given by the host. The answer from the CL-CD1864 is an eight bit value representing the Modified Service Vector. The five upper bits of the Modified Service Vector are from the upper five bits of the Global Service Vector Register and represent the chip ID of the CL-CD1864 that is answering the host's acknowledgment. The lower three bits (IT2, IT1, IT0) of the Modified Service Vector ignore the lower three bits of the Global Service Vector Register and indicate the type of service request with the highest priority that is presently pending in the answering CL-CD1864. To acknowledge a service request, the host processor usually addresses the first CL-CD1864 device in a chain via its chip select (CS*) signal and performs a read operation as if reading one of its three Service Request Acknowledge Registers. The answering device may be different from that which the host has addressed with the chip select signal. The answer in response to the acknowledgment, the Modified Service Vector, is driven onto the external data bus by the answering CL-CD1864. The host processor then interprets this answer to address the appropriate device and service the request.

In a daisy chain configuration, each CL-CD1864 must determine the current highest priority service request. To do this, each device monitors the Service Request outputs (MREQ*, RREQ*, TREQ*) to determine what type of requests are pending. Each device also knows its pending local Service Requests. By default a Modem Signal Change Service Request is defined to have the lowest priority. The priority of Transmit Service Request over Receive Service Request or visa-versa is set by the PdSel bit of the Service Request Configuration Register within each CL-CD1864. Upon receiving an acknowledgment, each CL-CD1864 if it does not have this request pending passes on answering the service acknowledgment using the daisy chain signals ACKIN* and ACKOUT* until the device (or the first of the devices) with the highest priority answers. Typically the host would select to read the chip at the beginning of the chain by asserting CS* of that device as if reading the Service Request Acknowledge Register of that chip. If the first chip is not currently asserting the highest priority service request it asserts its ACKOUT* signal that drives the next device's ACKIN*. Thus whichever device is asserting the highest priority service request will receive the acknowledgment and answer by driving the data bus lines with the Modified Service Vector.

In the case that daisy chaining is disabled, autoprioritization can be utilized to prioritize the local service requests. This is useful in systems where a host processor may only have one priority level interrupt input pin and has wired-OR together the separate Service Request pins. An example of a CPU that has a limited interrupt resource is an Intel 8086. Thus the host will receive the priority level from the lower three bits of the Modified Service Vector in answer to its acknowledgment. The user or host can set the PriSel bit of the Service Request Configuration Register to determine the highest level priority between Transmit Service Requests and Receive Service Requests locally to each individual CL-CD1864. Those of skill in the art can recognize that a more general system can be implemented to provide a wider variety of priority level selections.

When the host acknowledges a Service Request by addressing in a read operation one of the Service Request Acknowledge Registers and daisy chaining is enabled, a CL-CD1864 with the appropriate level of priority of pending service request will answer. In a system that does not use daisy chaining, a host can poll each device to determine if a Service Request is pending by simply addressing in a read operation one of the Service Request Acknowledge Registers (Modem Request Acknowledge Register, Transmit Request Acknowledge Register, Receive Request Acknowledge Register). In the case that daisy chaining is turned off (DaisyEn=0), the host reads the Service Request Acknowledge Register and if no corresponding Service Request is pending, the polled device answers with its Modified Service Vector such that the lower three bits are all zero. That is [IT2, IT1, IT0]="000". This is the only case where in the preferred embodiment the polled device answers with the lower three bits of its Modified Service Vector equal to zero. This method of polling to determine if a Service Request is pending typically saves the host at least one read cycle. In the prior art the host would normally poll the status register of an interrupt controller to determine if an interrupt were pending. The host would then have to go and poll each device. In this preferred embodiment the invention allows the host to directly poll a register to determine if a service request is pending. The host can then "fish" for a service request by polling one of the three Service Request Acknowledge Registers of each CL-CD1864 device that it selects. For example if the host wants to fish for Modem Change Service Requests ignoring Transmit Service Requests and Receive Service Requests (assuming autoprioritization is off), the host can address each device and its Modem Request Acknowledge Register as if reading the register to determine if the lower three bits on the data bus are all zero or if the value is 001 representing a Modem Change Service Request pending within that specifically addressed device.

The invention hardware embedded within a CL-CD1864 consists of a set of global registers and other logic that is shown in FIG. 7. (Details of the control logic blocks of FIG. 7 are provided within appendix II as well as being described below.) The information that is presented by these registers may vary by whether the host is performing a read or write operation. These registers are named the Service Request Control Register (SRCR), Service Request Status Register (SRSR), Modem Request Acknowledge Register (MRAR), Transmit Request Acknowledge Register (TRAR), Receive Request Acknowledge Register (RRAR), and the Global Service Vector Register (GSVR). Other registers are also and are defined below. The following is a detailed description of each register and the values or function that each performs.

FIG. 4 illustrates the Service Request Control Register that configures the CL-CD1864 to handle service requests. The user sets these bits depending on the type of method chosen to handle service requests.

While the CL-CD1864 provides for the "traditional" interrupt-based service request acknowledgments, the Service Request Control Register allows the user to provide for software based service requests in addition to the traditional hardware based service requests. The register further provides for picking two different methods of priority. This register also controls the operation of Fair Share for Service Requests. This register is downwardly compatible with software written for the prior art integrated circuit known as the CL-CD180. Thus both the traditional interrupt-based service request acknowledgments and service request acknowledgment via registers are simultaneously supported.

The two different types of priority methods are selected in the following manner. Setting the AutoPd bit enables the priority scheme. The user then selects PriSel and GlobPri to define the specific type of priority desired to be used.

The following is a detailed functional description of the control and option bits within the Service Request Configuration Register (SRCR):

This register configures the CL-CD1864 depending on the method chosen for handling service requests. In addition to the `traditional` interrupt-based host interface, writing the appropriate bits in this register provides for software-based rather than hardware-based service request acknowledgments and fixes service request priorities in either of two ways. This register preserves compatibility with existing CL-CD180 software. For this reason, this register defaults to all zeroes and each new feature must be enabled as desired.

RegAckEn and DaisyEn Bits are related to each other, and perform service-request acknowledgments by accessing registers within the CL-CD1864 instead of asserting hardware signals.

Service requests are prioritized by three other bits. AutoPri enables the priority scheme; PriSel and GlobPri determine the specific priority to be used.

FIG. 5 illustrates the three Service Request Acknowledge Registers referred to as Modem Request Acknowledge Register (MRAR), Transmit Request Acknowledge Register (TRAR), and the Receive Request Acknowledge Register (RRAR). These are read-only registers that return an appropriate Modified Service Vector when read by the host. The act of reading one of these registers (usually) produces a Service Request acknowledge cycle in the affected CD1864 (not necessarily the one addressed, it might be one further down a daisy chain). For these registers to operate properly RegAckEn of the Service Request Control Register must be set.

FIG. 6 illustrates the Service Request Status Register (SRSR). The i-level bits, ilvl[1], ilvl[0], are the current internal context code from the Context Stack 717 of FIG. 7. The i-level bits, ilv[1:0], are encoded as follows:

An accepted Service Request acknowledge cycle pushes a new context onto the stack.

Note, the external and internal Service Request status bits are positive true. The external Service Request lines (MREQ*, TREQ*, RREQ*) are, of course, negative true. The internal Service Request Status bits mreq, rreq, and treq are signals within the device that are being read representing a local Service Request (also referred to as internal Service Request) is pending. The external Service Request status bits RREQ, TREQ, MREQ are values representing the respective condition on the external pins RREQ*, TREQ*, and MREQ* as a result of a wire-OR'ed function. In Appendix II the internal signals and the bits in the Service Request Status Register referred to as rreq, treq, and mreq respectively correspond to the bits and signals referred to as IREQ3int, IREQ2int, IREQ1int as defined in Appendix I.

FIG. 9 illustrates the Global Service Vector Register (GSVR) with the bits defined as follows:

FIG. 10 illustrates the Modem Service Match Register (MSMR). This register must contain the value for Modem Signal Change Service Requests that will be presented on the Address Bus A0-A6 by the host to indicate the type of service request being acknowledged when ACKIN* is asserted. This register along with the other two Match Registers, is compared to the value on the Address Bus during acknowledgment cycles so that the CL-CD1864 can determine the service request being acknowledged by the host.

Bit 7 must be programmed to a `1`. The CL-CD1864 compares all eight bits internally, but there are only seven address lines. Bits 6:0 of the register are compared to A6:A0 of the Address Bus. Bit 7 of the register is compared with a logic `1`.

Within any one CL-CD1864, the three Match Registers must have unique values. In multiple CL-CD1864 designs where service acknowledgments are cascaded, all Match Registers of the same type (e.g., Modem) must have the same value.

In designs using register-based service acknowledgments (RRAR, TRAR, and MRAR), the addresses of these registers must be placed in the equivalent Match Register, so that MSMR contains $F5 (hexadecimal).

FIG. 11 illustrates the Transmit Service Match Register (TSMR). This register must contain the value for Transmit Data Service Requests that will be presented on the Address Bus A0-A6 by the host to indicate the type of service request being acknowledged when ACKIN* is asserted. This register, along with the other two Match Registers, is compared to the value on the Address Bus during acknowledgment cycles so that the CL-CD1864 can determine the service request being acknowledged by the host.

Bit 7 must be programmed to a `1`. The CL-CD1864 compares all eight bits internally, but there are only seven address lines. Bits 6:0 of the register are compared to A6:A0 of the Address Bus. Bit 7 of the register is compared with a logic `1`.

Within any one CL-CD1864, the three Match Registers must have unique values. In multiple-CL-CD1864 designs where service acknowledgments are cascaded, all Match Registers of the same type (e.g., Transmit) must have the same value.

In designs using register-based service acknowledgments (RRAR, TRAR, and MRAR), the addresses of these registers must be placed in the equivalent Match Register, so that TSMR contains $F6 (hexadecimal).

FIG. 12 illustrates the Receive Service Match Register (RSMR). This register must contain the value for Receive Data Service Requests that will be presented on the Address Bus A0-A6 by the host to indicate the type of service request being acknowledged when ACKIN* is asserted. This register, along with the other two Match Registers, is compared to the value on the Address Bus during acknowledgment cycles so that the CL-CD1864 can determine the service request being acknowledged by the host.

Bit 7 must be programmed to a `1`. The CL-CD1864 compares all eight bits internally, but there are only seven address lines. Bits 6:0 of the register are compared to A6:A0 of the Address Bus. Bit 7 of the register is compared with a logic `1`.

Within any one CL-CD1864, the three Match Registers must have unique values. In multiple-CL-CD1864 designs where service acknowledgments are cascaded, all Match Registers of the same type (e.g., Receive) must have the same value.

In designs using register-based service acknowledgments (RRAR, TRAR, and MRAR), the addresses of these registers must be placed in the equivalent Match Register, so that RSMR contains $F7 (hexadecimal).

FIG. 13 illustrates the End of Service Routine Register (EOSRR). This is a dummy register, and must be written to by the host's service request routine to signal to the CL-CD1864 that the current service-request service is concluded. This must be the last access to the CL-CD1864 during a service-request routine. Writing to this register will generate an internal End-of-Service Signal, which `pops` the CL-CD1864's context stack, allowing the CL-CD1864 to resume normal processing and also service other channels. Service-request contexts may be nested, as explained in Appendix I Section 2.4, i.e., one can respond to and service a higher-priority event while in the middle of a lower-priority service request routine (as when nesting subroutine calls within other subroutines). Any attempt to read from this register will cause unpredictable results.

FIG. 7 represents the improvements added to the devices of the Wishneusky U.S. Pat. No. 4,975,828, the disclosure of which is incorporated herein by reference. FIG. 7 is a block diagram that represents the upper level functionality of the circuitry in each CL-CD1864 to support the preferred embodiment. Not all signals are shown in FIG. 7. Only those of importance to the description of the preferred embodiment are represented. For example each block of FIG. 7 has access to an internal data and address bus but it is not shown for purposes of clarity. Further the blocks of FIG. 7 do not necessarily operate independent of the RISC processor but many portions of the preferred embodiment of the invention do operate independently. Also the CL-CD1864 externally interfaces to the host data bus which is not shown in FIG. 7. The preferred embodiment of the invention communicates to the host by use of the external address and data bus as well as other control signals. References in this description to the address and data bus refer to the external address and data bus and generally not to the internal address and data bus of a CL-CD1864.

Referring to FIG. 7 the Interrupt Acknowledge Recognition CAM 713 contains the Match Registers (Modem Service Match Register, Transmit Service Match Register, Receive Service Match Register). The Match Registers allow the host to support the traditional hardware interrupts as depicted in Appendix I Sections 2.5, 2.5.1, 2.5.2, 2.5.3. In this case mixed-mode service request acknowledgments are described. Mixed-mode refers to using both a traditional hardware interrupt (ACKIN* in conjunction with the Service Request Match Registers) acknowledgment mechanism and a register based (Modem Request Acknowledge Register, Transmit Request Acknowledge Register, Receives Request Acknowledge Register) acknowledgment mechanism to process Service Requests.

In the case of traditional hardware interrupt acknowledgments, the host is first notified of a Service Request (Receive Service Request, Transmit Service Request, Modem Change Service Request). The host then acknowledges the Service Request by asserting ACKIN* 728 and DS* 721 while placing onto the external address bus 724 a match value or the type of Service Request being acknowledged by the host. Upon initialization the Service Request Match Registers were loaded with the respective address values of the Service Request Acknowledge Registers as described above. For example the host acknowledges a Transmit Service Request and writes $76 (hexadecimal) onto the address bus. The Interrupt Acknowledge Recognition CAM 713 compares the contents of the external address bus 724 with the contents of the Match Registers within the CL-CD1864 to detect what service request the host is acknowledging. If a Receive Service Request is acknowledged signal 752 (match3) is asserted. If a Transmit Service Request is acknowledged, signal 751 (match 2) is asserted. If a Modem Change Service Request is acknowledged, signal 750 (match 1) is asserted. This first service request is handled by the host in the traditional way of servicing interrupts. When the host completes handling the first Service Request it notifies the CL-CD1864 by writing to the End of Service Routine Register at address $7F (hex). Since other Service Requests may be pending within the same device it is wise to keep the host in its present context servicing this device. Thus after finishing the service of the first Service Request the host should read the Service Request Status Register 718 in order to determine if other service requests are pending. If the bits rreq, treq, or mreq are set it indicates that another service request is pending internally within this CL-CD1864. Thus if another service request is pending the host can now use a software, register based acknowledgment method supported by the invention. The host can acknowledge the internal pending Service Request (also referred to as local pending Service Request) by addressing the appropriate Service Request Acknowledge Register. For example, assume a Transmit Service Request is pending internally within the same CL-CD1864. The host acknowledges the service request by placing onto the address bus 724 the value $76 (hex) as if reading the Transmit Request Acknowledge Register. This addresses the Transmit Request Acknowledge Register, which is not a real register in the sense that it is made of memory elements. Addressing as if reading activates combinatorial logic to assert internal control signals such that the Modified Service Vector is written onto the external data bus (not shown) by the respective CL-DC1864. Other internal control signals such as regack 766 (register acknowledge) and signal 748 (txregack) are asserted in response to the read of the Transmit Request Acknowledge Register by the host processor. If the host were to read the Modem Request Acknowledge Register similar internal control signals would be generated except that instead of txregack 748 being asserted signal 747 (mdmregack) would be asserted. If the host were to read the Receive Request Acknowledge Register then instead of txregack 748 being asserted, signal 749 (rxregack) would be asserted. The combinatorial logic for generating these control signals is within the Register Acknowledge Recognition block 712 as depicted in FIG. 7. The host can continue to poll the Service Request Status Register 718 to determine if any further Service Requests are pending within the same device and acknowledge those requests by reading the Service Request Acknowledge Registers (MRAR, TRAR, RRAR).Thus the support of a mixed-mode acknowledgment (traditional interrupt and registered based acknowledgment) allows the host to remain in its same context in order to handle service requests from the same device or other devices in the daisy chain.

In order to support the multiple Service Requests within the same device, the service requests must be queued up internally and the internal context must be saved. The Service Request Queue Controller 716 has three queue controllers within this block. Each queue controller is dedicated to one type of Service Request (Modem Change Service Request, Transmit Service Request, Receive Service Request) that needs support. Each dedicated queue controller may store context information for multiple pending requests. Appendix II provides a detailed truth table of the logic for the queue controller. The internal context for each type of Service Request that is queued up is stored within the Service Request Queue Controller 716. A context saved in a queue controller becomes active when its pending Service Request is acknowledged by the host. The Context Stack 717 records current and nested active context and allows for host initiated nesting of separate queue controller contexts. The signals acklvl[1:0] 735 from the daisy chain controller are pushed onto the Context Stack when the device accepts a service acknowledgment. The Context Stack is popped when the host signals the end of a service context by writing to the End of Service Routine Register.

In the case that multiple devices are daisy chained together (illustrated by FIG. 8) and an external Service Request signal is asserted such as RREQ* 744, TREQ* 745, or MREQ* 746 the host may acknowledge this signal by reading a Service Request Acknowledge Register within the first device in the chain. This generates the signal ACKOUT* 727 such that it propagates from the first device to the ACKIN* 728 of the second device provided the first device did not have a Service Request pending and did not accept the acknowledgment. Similarly ACKOUT* of the second device is connected to the ACKIN* of the third device in the daisy chain. The daisy chain is presently limited to 32 devices because there are only 5 bits available within the Global Service Vector Register to uniquely define a Chip ID for each device in the daisy chain. However more channels can be supported by the same host by connecting multiple strings of daisy chains to perhaps an interrupt controller. Another limit to the length of a daisy chain is the speed at which the ACKOUT* signal can propagate through the devices in the chain and how long the host processor will wait for the propagation delay.

In essence this invention allows the host to selectively turn on and off the daisy chain for register acknowledgments of global Service Requests by setting a bit within the service control register. With daisy chaining disabled, an ACKIN* signal is still able to be passed to the ACKOUT* signal in the case of a traditional interrupt acknowledgment if the device has no pending local Service Requests. The host writes to the Service Request Configuration Register by asserting R/W* 722, CS* 720, and then places the address $66 (hex) onto the address bus AD[6:0] 724. The host places on the external data bus the same values previously stored in the Service Request Configuration Register with the exception of the DaisyEn bit, bit 6 of FIG. 4. DaisyEn bit is changed to a zero to disable the generation of ACKOUT in response to a register based acknowledgment. DaisyEn register value is changed to a one in order to enable daisy chaining. Daisy chaining of global register based acknowledgments is typically disabled for systems that were wired for the traditional interrupt acknowledgment configuration. These systems can take advantage of the local register acknowledgment mechanism but can not support the global register acknowledgment because the Service Match Registers can not be appropriately set. In other systems the host may choose to turn off daisy chaining in order to selectively reconfigure the system in how it handles service requests.

Within the Daisy Chain Control Logic 715 is combinatorial logic that determines whether to keep the acknowledgment or to pass the acknowledgment down the chain to other devices. This decision depends on a number of factors which are further discussed below. When daisy chaining is disabled the DaisyEn bit is a zero. The combinatorial logic that generates the signal ACKOUT* 727 is as follows (Internal to the device the signal name is ACKOUT that is an active true signal and has the reverse polarity of the output signal ACKOUT* which is active low.):

Thus if daisy chaining is disabled the ACKOUT* signal is only generated when the pass signal results from ACKIN* 728 being asserted. The pass signal in this case results from the device having no pending request of the type being acknowledged. With daisy chaining disabled ACKOUT is never active if the host is attempting to acknowledge a Service Request by addressing the Service Request Acknowledge Register. In other words, disabling the daisy chain mechanism only disables the register based acknowledgment for global service request acknowledgements. The register based acknowledgment still functions for local service request acknowledgments. Daisy chaining disabled still allows for the traditional methods of interrupt acknowledgments via the Service Request Match Registers and the acknowledgment input signal ACKIN*. This provides compatibility with the prior art devices.

This invention supports both Global and Local prioritization of Service Requests while daisy chaining is enabled. The discussion above described how to turn on and off daisy chaining. We now turn to issues of how Service Requests of different levels and the acknowledgment of those service requests can be automatically prioritized by the invention.

Assume for this discussion that the desired configuration for handling Service Requests is by a daisy chain configuration. Upon initialization of a system, the user has the host initialize the set of CL-CD1864 devices within the daisy chain. The host writes to the Service Request Configuration Register(SRCR) 711 and sets the bits accordingly within this register. For the purposes of discussing global autoprioritization assume that the SRCR 711 is written with 01110010. Thus daisy chaining, register based service acknowledgments, global priority, and autoprioritization am all enabled. We choose for the moment that Receive Service Requests have the highest priority level via the PriSel bit. Therefor Transmit Service Requests have the next highest priority level. Modem Change Service Requests by default have the lowest prioritization.

In this configuration the RREQ* 744 signals of all devices in a daisy chain are wire-ORed together, the TREQ* 745 signals of all devices are wire-ORed together and the MREQ* signals of all devices are wire-ORed together. For this purpose the outputs of inverters 760, 762, and 764 are open drain devices that facilitate the wire-OR configuration. Of course a pull up resistor must be placed on each wire-ORed output.

Thus when a CL-CD1864 within the daisy chain of devices asserts one of the Service Request Outputs (744, 745, or 746) the host initially does not know which device is requesting service. The host would then proceed to acknowledge the request when it is ready to handle the request. Usually the host would acknowledge the first device in the chain by either addressing any one of the three Service Request Acknowledge Registers in a read operation or by performing the traditional method of interrupt acknowledgment by addressing the appropriate value stored in a Service Match Register and asserting the ACKIN* input of the first device. As discussed previously the Register Acknowledge Recognition 712 generates the following signals: regack 766 and one of mdmregack 747, txregack 748, or rxregack 749 in response to a Service Request Acknowledge Register of the device being read by the host. The Interrupt Acknowledgment Recognition CAM 713 generates match1 750, match2 751, or match3 752 in response to the host asserting ACKIN* together with an address code matching the contents of one of the service match registers. Signal match1 is ORed with mdmregack 747 by OR gate 781 generating newmatch1 729. Signal match2 751 is ORed with txregack 748 by OR gate 782 generating newmatch2 730. Signal match3 752 is ORed with rxregack 749 by OR gate 783 generating newmatch3 731. Thus either a register based acknowledgment or an interrupt based acknowledgment can start the autoprioritization logic. Note that the first device that the host acknowledges does not necessarily have a Service Request pending. For example devices that are fifth and seventeenth in the chain may be the devices asserting Service Requests.

Generally the Register Acknowledge (Regack) Prioritization Logic 714 within each CL-CD1864 in conjunction with its associated Daisy Chain Controller 715 prioritizes the Service Requests that are pending either globally amongst devices in a daisy chain or locally within a device. The Service Acknowledge Prioritization Logic 714 particularly determines if the local Service Requests that may be queued and currently pending are of an appropriate level in order that the device containing the Service Acknowledge Prioritization Logic should answer the host's acknowledgment. External Service Request signals RREQ* and TREQ* are sensed in order to determine globally if a different chip is asserting a more appropriate level of Service Request than what is pending locally.

Appendix II, page 14 illustrates the detailed logic of the Service Acknowledge Prioritization Logic 714. The signals action@3 and action@2 are generated if an internal service request local to the device is pending or if global prioritization is enabled and an external Service Request at another device is pending. The signal action@3 responds to Receive Service Requests and action@2 responds to Transmit Service Requests. Initially PriSel bit of the Service Request Configuration Register steers the priority by the use of transfer gates into the signals action@hi and action@med. In our example PriSel is set to a zero. Thus action@3 is steered into action@hi and action@2 is steered into action@med. Thus the Receive Service Requests are steered into the action@hi. Next the equations for accept@hi, accept@med, and accept@lo are evaluated and enabled by the AutoPri bit from the Service Request Configuration Register. If AutoPri is set to a zero all the remaining logic evaluates to a zero and does not effect the daisy chain. For AutoPri set to a one the accept@ equations are evaluated. If action@hi is true then accept@hi is true and accept@med and accept@lo are both false. Thus in our example the Receive Service Request either locally or externally asserted would exclude the other lower Service Request. However if action@hi is false and action@med is true then accept@med is true to the exclusion of accept@hi and accept@lo. Thus in this example no Receive Service Request is pending but a Transmit Service Request is pending. For accept@lo to be true neither a Receive Service Request nor a Transmit Service Request is pending. The signals accept@hi and accept@med must be correctly steered back into the Transmit Service Request Logic or the Receive Service Request Logic by the second level of transfer gates controlled by the PriSel bit. Now that the priority is set, the Daisy Chain Controller Logic determines if the host's service acknowledgment shall affect the daisy chain by generating the ACKOUT signal telling other devices that the present device will pass the acknowledgment or if the device will accept the acknowledgment as "mine" and answer the host.

The signals newmatch1, newmatch2, and newmatch3 were generated as described above and represent a register based service acknowledgment or a traditional interrupt acknowledgment to this device. If a low priority Service Request is pending then accept@lo is true. The host can choose to ignore this lower priority Service Request by acknowledging a higher level Service Request. Thus the host can acknowledge a Receive Service Request while a global or local Modem Change Service Request is pending and those devices will not answer. The devices with the Modem Change Service Requests will pass.

In the case that the host acknowledges with a lowest priority Service Acknowledgment (Modem Service Request) and a higher level of Service Request is pending in a device in the daisy chain, the first of the devices with the highest level of pending Service Request will answer. The device that answers may be the first or any other device in the chain that has a level higher than a Modem Service Request pending. However if there are equivalent levels of priority pending in the daisy chain, the first device with that level in the chain will answer first. In the logic diagram in Appendix II, Page 14, one of the pmatch (pmatch2 or pmatch3) signals is generated and passed to the Daisy-Chain controller 715 under these conditions. For example, assume that a Transmit Service Request is pending externally and causes the signal accept@med to be generated in the current device. Assume the host acknowledges the request by addressing as if reading the Modem Request Acknowledge Register in the current device. This generates the newmatch1 signal from the equation newmatch1=match1+mdmregack. The signal newmatch1 is ANDed with the value from the second multiplexer. In this example the second level multiplexer is set so that accept@med is passed to the pmatch2 logic chain. Thus newmatch1 is ANDed with accept@med signal generating the signal pmatch2. The pmatch2 signal is passed to the Daisy-Chain Controller 715 to determine if the present device should answer the host and "accept" the Service Request or "pass" the acknowledgment down the daisy chain to the next device.

In the preferred embodiment, when the host acknowledges the second level priority, that level of Service Request is answered even though a higher level of priority Service Request is pending. Only in the case of the host acknowledging the lowest level of Service Request does a device answer that has a higher priority pending. For example if the signal newmatch2, representing a Transmit Request Acknowledgment, is asserted then the autoprioritization logic is bypassed and the signal pmatch2 is generated. If the signal newmatch3, representing a Receive Request Acknowledgment, is asserted then similarly the autoprioritization logic is bypassed and the signal pmatch3 is generated.

Once the Service Request Acknowledgment has been autoprioritized a device in the daisy chain must determine if it should accept and answer ("accept") the acknowledgment, provided directly by the host or through other devices in the chain, or if it should pass the acknowledgment to the next device. For each level of service request there is a daisy chain controller in each CL-CD1864. Thus the Daisy-Chain Controller block 715 contains three individual daisy-chain controllers. In Appendix II Page 11 there is a Karnaugh map describing the input signals and states that each daisy-chain controller goes through.

The PASSn state and the MINEn state are of interest. In the PASSn state the daisy chain controller recognizes the type of acknowledge to be that which it could accept but that there is no internal Service Request (also referred to as local Service Request) pending. Thus it should pass the acknowledge to the next device in the daisy chain. In the MINEn state the acknowledgment is a type that the controller should accept and answer the host processor because it has a matching request pending. Thus it will not pass the acknowledge to the next device and should not generate an ACKOUT signal.

Assume that global prioritization, daisy chaining, and autoprioritization is enabled and the PdSel bit is set to zero as in the example above. In the Karnaugh map for the daisy chain controller, illustrated in Appendix II Page 11, the initial states are IDLE1 and IDLE0. Upon initialization the devices of the invention start in the IDLE0 state. Assume no local Service Requests for any level are initially pending within the first device of a set of devices in a daisy chain. Also assume that an external Service Request from another device down the chain is sensed by the first device and the service acknowledge prioritization logic generates a corresponding action@ signal within the first device. Simultaneously all other devices in the daisy-chain have recognized the Service Request signal and generated a corresponding action@ signal within their own service acknowledge prioritization logic. The host can then acknowledge the service request in two ways. The first method is by asserting ACKIN* to the first device in the chain and placing a value on the address bus which will match the stored value in the corresponding service match register. The second method of host acknowledgment is by reading one of the Service Request Acknowledge Registers of the first device in the daisy chain. In the first method, all devices in the chain will have sensed the external address value corresponding to a match signal. In the second method, the register acknowledge recognition logic in the first device has recognized the read operation to the Service Request Acknowledge Register and produces a corresponding match signal. Since daisy chaining is enabled, the other devices in the chain must be programmed with Service Match Register values which correspond to Service Request Acknowledge Register addresses, so the Interrupt Acknowledge Recognition CAM logic in those devices will produce a match signal as well.

The match signals produced in each device are presented to the daisy-chain controllers. The active match signal will send the corresponding controller from the IDLE state to the intermediate state.

In the first device there was no local Service Request pending so its daisy chain controller is moved by the match signal to the intermediate state between IDLE0 and PASSn. In the devices which have the service request pending, the match signal moves their daisy-chain controllers to the intermediate state between IDLE1 and MINEn.

In the first device, the signal regack is generated by the Register Acknowledge Recognition logic. This signal causes the daisy-chain controller, activated by the match signal, to transition from the intermediate state to the PASSn state. Since daisy-chaining is enabled, the effect of the register acknowledge is to cause the controller to assert the ACKOUT* signal. The next device in the chain sees the ACKIN* signal (also known as ackin signal internally within the device). Assuming this device does not have the corresponding service request pending, the controller will proceed to the PASSn state. Thus the device will also pass down the chain the acknowledgment input signal received from the first device. This cycle is repeated down the chain until the ACKIN* signal reaches a device having an internal Service Request (also referred to as local Service Request) pending of an appropriate level such that it can accept the acknowledgment from the host. The controller in that device will be sent to the MINEn state by the receipt of ACKIN*. It will not pass the acknowledgment but will assert the internal signal ack-taken 725. This causes the new service context code to be pushed on the Context Stack 717, the Vector Modification logic 780 to generate a Modified Service vector, and the Bus Interface Logic 710 to perform a bus read operation that places the Modified Service Vector on the external data bus and generates the data transfer acknowledge signal (DTACK*) to indicate to the host that valid data has been placed on the data bus.

All other devices further down the chain received no acknowledgment signal. Their daisy-chain controllers which were activated by the match signal, will transition directly back to the IDLE0 or IDLE1 state when the match signal is removed by the end of the host bus read or bus acknowledge signals.

In each device, all daisy-chain controller PASS signals are ORed together to generate the overall PASS signal. Similarly each controller's MINE signals are ORed together to generate the overall MINE signal. These equations are illustrated on Page 12 of Appendix II. To answer the host and prepare the Service Request Queue Controllers 716, the signal ack-taken 725 is generated. The signals acklv11 and acklvl0 (signal bus 735) carry a binary encoded value which corresponds to the asserted match signal, this indicates the type of acknowledgment being accepted. It may correspond exactly to the type of acknowledgment issued by the host, or if autoprioritization was performed, the acklvl type may be different. The acklvl signals are used by the Vector Modification Logic 780 together with optional sub-type information from the corresponding Service Request Queue Controller 716 to produce the Modified Service Vector. The signal ack-taken 725 tells the bus interface logic 710 to write the modified Service Vector onto the external data bus in answer to the host acknowledgment. This indicates which device the host should service and what type of service is required. The PASS signal further generates the ACKOUT* signal to offer the next device in the chain the opportunity to answer the acknowledgment.

In the design of the priority logic, the requirements for loading the Match Registers insures that only one match signal can be generated at a time. Thus the PASS signal and MINE signal can not both be asserted at the same time. All daisy-chain controllers which have received an acknowledge signal (either regack or ackin) and moved to the PASSn or MINEn states will make the transition back to the IDLE0 or IDLE1 state when the acknowledge signal is removed. The first device in the chain will recognize the removal of the acknowledge signal, of either type, first. It will remove its ACKOUT* signal. Subsequent devices in the chain will recognize the removal of the ACKIN* signal and remove their ACKOUT* signal, until ACKIN* is removed from the device in the chain that accepted the acknowledgment.

We next describe a method for the host to "fish" by issuing a Register Acknowledgment to a CL-CD1864 without knowledge of its currently pending service requests. This method may be used when daisy chaining is disabled and register acknowledgment is enable (DaisyEn=0, RegAckEn=1). If a suitable request is pending, the device will reply with a modified Service Vector indicating the type of service to be performed. The successful acknowledgment will cause the CL-CD1864 to enter a new service context just as it would if the host had prior knowledge that a suitable service request was pending. If a suitable service request is not pending, the CL-CD1864 will reply with a modified Service Vector containing the reserved modification code "000" indicating that no suitable request was pending. In this instance, the CL-CD1864 does not enter a new service context. If the autoprioritization feature is used, any pending request(s) will cause the CL-CD1864 to reply with a modified Service Vector indicating a new service context for the highest priority pending request has been entered.

This was accomplished by the host addressing one of the Service Request Acknowledge Registers and monitoring the lower three bits of the modified Service Vector that were provided on the data bus from the CL-CD1864. Normal processing of the match signal occurs in the CL-CD1864, selecting one of the daisy-chain controllers to await the acknowledgment. In response to the regack acknowledgment signal from the Register Acknowledge Recognition logic (and passed through the Service Acknowledge Prioritization Logic), the activated daisy-chain controller will make the usual transition to either the MINEn or the PASSn state. If the state entered is the MINEn state, a service acknowledgment has been performed and the modified Service Vector indicates the type to the host. However, if the state entered is the PASSn state, the signal ACKOUT* will not be asserted. Recall that the equation for ACKOUT is:

The signal pass is true, but the signals DaisyEn and regack* are false. The equation for the ack-taken signal from Appendix II is:

In this case mine is false but pass, DaisyEn* and regack are all true, so the ack-taken signal is asserted. The equations for the acklvl signals from Appendix II are:

Since only a pass signal and no mine signals are active, both acklvl signals are false. The combination of an ack-taken signal with both acklvl signals false inhibits the entering of a new service context by inhibiting the pushing of the Context Stack 717, and causes the Vector Modification Logic 780 to place the reserved "000" code in the Modified Service Vector.

FIG. 9 illustrates the Global Service Vector Register. The lower three bits in the data sheet description are named IT2, IT1, and IT0. The modified Service Vector response to a service acknowledgment is composed by two pieces of hardware. The five user defined bits are stored as a register value within a RAM which is not shown in FIG. 7. These bits are read from the RAM and presented to the Vector Modification Logic 780 during the service acknowledgment cycle. The bits IT1 and IT0 are produced by the acklvl[1:0] bits from the Daisy-chain Controllers. The bit IT2 is generated from the Service Request Queue Controller 716. The bit IT2 768 is separately generated denoting the specific sub type of Receive Service Request pending. The Vector Modification Logic 780 joins these bits with the five user defined bits from the Global Service Vector Register to generate the Modified Service Vector.

The autoprioritization as previously described may vary the values of IT2, IT1, and IT0 presented on the data bus from the implicit type of the service acknowledgment performed by the host. In the case where the Service Acknowledgment Prioritization Logic has converted the match type of the service acknowledgment from the host to a different match type presented to the daisy-chain controllers, the acklvl signals from the daisy-chain controllers will reflect the converted match type and cause the IT2, IT1, and IT0 values supplied within the modified Service Vector to correspond to the type of request autoprioritization caused to be acknowledged.

The embodiment of the invention in the CL-CD1864 does not permit the use of the "fishing" type acknowledgment with daisy-chaining because the present implementation of the DaisyEn control bit disables only the passing of register acknowledgments. Devices further down the daisy-chain see only the traditional acknowledgments signalled by ACKIN*. ACKIN* acknowledgments will produce an ACKOUT* signal if a suitable service request is not pending. It will be obvious to one skilled in the art that a further control bit providing for the disabling of ACKIN* acknowledgments or the broadening of the DaisyEn control function to include ACKIN* acknowledgments could be readily implemented. With such an extension to the control of daisy-chaining, fishing would be supported over an entire daisy-chain. In this case, the last device in the daisy chain must have its ability to pass an acknowledgment disabled. In the event that a "fishing" type acknowledgment found no device in the chain with a suitable service request pending, the acknowledgment would be passed to the last device in the chain. That device, having no suitable service request pending and with daisy-chaining inhibited, would be obliged to respond with a modified Service Vector containing the reserved type code "000".

The extension of the Daisy-chain disabling mechanism as just described, together with the register acknowledgment invention would permit several novel and useful host software manipulations of a hardware daisy chain. The daisy chain can be dynamically partitioned at arbitrary points by disabling daisy chaining at any device or devices at which the host wished to partition the chain. By use of the direct addressing that is possible with the register acknowledgment invention, service acknowledgments can be issued to the devices at the head of the chains so partitioned. A circular daisy-chained ring of devices can be implemented in hardware and arbitrarily defined to end and begin with any 2 successive devices in the ring. The circular daisy-chained ring can be partitioned at multiple points to produce several smaller daisy-chains.

This invention differs from the register support for service requests in the prior art device know as the CL-CD1400 in several ways. First, the user can view the service request state of the chip AND of the ensemble of chips sharing a set of service request lines. This latter facility means that by reading one register on one chip, the host or user knows if there are ANY service requests pending on any chips.

The second major difference is in the mapping of the Service Request acknowledge mechanism into reads of special registers. Here, the user may issue an acknowledge to the chip at the head of the chain. With DAISYEN set, that chip will treat the register-based acknowledge as a daisy chainable, validated Service Request acknowledge. That is, if it has the corresponding service request pending, it treats the register-based acknowledge as an acknowledgment of its pending service request. However, if it does not have the corresponding request pending, it passes the register-based acknowledge on down the chain by asserting ACKOUT*. CL-CD1864's down the chain see the ACKIN* as valid acknowledgment of the proper type, because they have their Service Match Registers (Modem Service Match Register, Transmit Service Match Register, Receive Service Match Register) programmed (by the user) to the addresses used for the Service Request Acknowledge Registers.

Note the user doesn't have to employ the register based acknowledge mechanism in a daisy chained mode. The user can reserve daisy chaining for use with an external interrupt controller using whatever acknowledge codes (Service Match Register values) are chosen. The user can use the new register based support on a chip by chip basis that does not conflict with the existing lACK mechanism.

It is legal to "fish" for acknowledgments with the RegAckEn-1, and DaisyEn=0. A vector with a modification code of zero indicates no Service Request was pending to "take" the acknowledge. This differs from "normal" interrupt acknowledge behavior in that the chip addressed will respond to the host whether it has an appropriate service request pending or not. In the "normal" case of the prior art, a chip receiving a service acknowledgment (its ACKIN* pin is asserted) will respond on the bus with a (possibly modified) vector only if it has an appropriate service request pending. If it does not have a request pending, it will assert ACKOUT*. The host is not guaranteed a response (vector) from the chip.

The third difference is in the option to have the CL-CD1864 assign the priority to a generic interrupt acknowledge given either through the ACKIN* mechanism or the register-based acknowledge mechanism. The AutoPri and the PriSel bits control this. The AutoPri bit enables the CL-CD1864 prioritizing mode and the PriSel bit chooses whether the Receive or the Transmit requests is to be of the highest priority. The user also selects whether the prioritization is to be done globally (over all chips in a daisy chain sharing IREQ lines) or locally to the specific chip receiving the acknowledgment.

While the preferred embodiment of the invention supports control by a host processor of a potentially very large number of data communications ports, it is obvious to those skilled in the art that the invention is applicable to other architectures. In particular, the invention is applicable to computer architectures in which a common resource (such as a host processor) controls, services, or communicates with multiple resources or devices (such as co-processors, slave processors, or peripheral devices). ##SPC1##