REGISTER  |  SIGN IN
United States Patent5784649
Begur , ; et al.July 21, 1998
Title
Multi-threaded FIFO pool buffer and bus transfer control system
Abstract
A bus transfer control system manages the transfer of multiple asynchronous data streams through a buffer pool. The bus transfer control system includes a buffer pool having a plurality of memory blocks, wherein each memory block provides for the storage of a plurality of data bytes and a plurality of data transfer devices coupled to the buffer pool to allow the transfer of segments of one or more data streams to be transferred between the plurality of data tranfer devices through the buffer pool. A transfer controller maintains status information relating to the status of data in the memory blocks and includes control logic for repeatedly evaluating the status information and providing for the prioritied selection of a first data transfer device and a predetermined one of the memory blocks.
Inventors:Begur; Sridhar (San Jose, CA), Gifford; James K.  (Danville, CA), Lewis; Adrian  (Fremont, CA), Spencer; Donald J.  (San Jose, CA), Kilbourn; Thomas E.  (Saratoga, CA), Gochnauer; Daniel B.  (Saratoga, CA)
Assignee:Diamond MultiMedia Systems, Inc. (San Jose, CA)
Appl. No.:614659
Filed:March 13, 1996
Current U.S. Class:710/52 709/231 710/310 
Field of Search:395/290,308,309,250,200.05,872,877,200.61,200.62,200.63
U.S. Patent Documents
4509119April 1985Gumaer et al.
4935894June 1990Ternes et al.
5161215November 1992Kouda et al.
5299313March 1994Petersen et al.
5317692May 1994Ashton et al.
5428609June 1995Eng et al.
5488694January 1996McKee et al.
5488724January 1996Firoozmand
5530871June 1996Abe
5586264December 1996Belknap et al.
Primary Examiner: Sheikh; Ayaz R.
Assistant Examiner: Pancholi; Jigar
Attorney, Agent or Firm:Fliesler, Dubb, Meyer & Lovejoy, LLP
Claims

We claim:
1. A bus transfer control system for managing the transfer of multiple continuous asynchronous data streams, said bus transfer control system comprising:
a) a buffer pool, definable as a plurality of memory buffers, capable of storing a plurality of data stream segments representing one or more data streams;
b) a plurality of data transfer devices coupled to said buffer pool and to a plurality of memory spaces, said data transfer devices supporting the iterative transfer of data stream segments between said memory buffers and said memory spaces, said data transfer devices providing requests for data stream segment transfers in response to the accessibility of said memory spaces to receive and provide data stream segments; and
c) a transfer controller, responsive to said requests and providing storage for status information as bus transfer units that define respective data streams, said transfer controller iteratively scanning said bus transfer units to select a first bus transfer unit and enable the transfer of a first predetermined data stream segment between said buffer pool and a first data transfer device specified by said first bus transfer unit in a predetermined scan iteration.

2. The bus transfer control system of claim 1 wherein said first data transfer device obtains a first predetermined portion of said status information stored by said first bus transfer unit by obtaining programming from said transfer controller, said first data transfer device updating said first predetermined portion of said status information upon transfer of said first predetermined segment of said first predetermined data stream between said buffer pool and a first memory space.

3. The bus transfer control system of claim 2 wherein said plurality of data transfer devices includes a second data transfer device coupleable to a second memory space and responsive to the access availability of said second memory space and wherein said second data transfer device obtains a second predetermined portion of said status information stored by a second bus transfer unit by obtaining programming from said transfer controller, said second data transfer device updating said second predetermined portion of said status information upon transfer of a second predetermined segment of a second predetermined data stream between said buffer pool and said second memory space.

4. The bus transfer control system of claim 3 wherein said first and second predetermined data streams are the same data stream.

5. The bus transfer control system of claim 3 or 4 wherein said status information is stored as a plurality of bus transfer units in a bus transfer table and includes prioritization and memory buffer information and wherein said transfer controller is coupled to said bus transfer table for iteratively selecting highest priority first and second bus transfer units for respective use by said first and second data transfer devices.

6. The bus transfer control system of claim 5 wherein said transfer controller maintains respective identifiers of said first and second bus transfer units for use in updating said first and second bus transfer units independent of a next iteration of selecting said highest priority first and second bus transfer units for respective use by said first and second data transfer devices.

7. A bus master data transfer control system for transferring data segments of multiple continuous transfer data streams between a memory accessible by said bus master data transfer control system over an arbitrated access data transfer bus and a buffer pool, said bus master data transfer control system comprising:
a) a buffer pool providing for the storage of a plurality of data packets;
b) a first bus master unit coupleable to a first arbitrated access data transfer bus that provides access to a first external memory space, said first bus master unit providing for the transfer of a first predetermined data packet between said first arbitrated access data transfer bus and a first bus master data packet buffer and between said first bus master data packet buffer and said buffer pool;
c) a second bus master unit coupleable to an second arbitrated access data transfer bus that provides access to a second external memory space, said second bus master unit providing for the transfer of a second predetermined data packet between said second arbitrated access data transfer bus and a second bus master data packet buffer and between said second bus master data packet buffer and said buffer pool; and
d) a bus transfer controller, responsive to the data segment present statuses of said first and second bus master data packet buffers, including a table for storing bus transfer control units including first and second predetermined bus transfer control units that respectively determine bus master data transfers by said first and second bus master units relative to said buffer pool, said bus transfer controller iteratively operative to select a prioritized bus transfer control unit from said table to enable a bus data transfer relative to said buffer pool.

8. The bus master data transfer control system of claim 7 wherein said first and second predetermined bus transfer control units are programmatically associated with said first and second bus master units and a predetermined memory block of said buffer pool.

9. The bus master data transfer control system of claim 8 further comprising an arbiter system for selecting either of said first and second bus transfer control units for use in programming a respective one of said first and second bus master units for the transfer of said first and second predetermined data packets.

10. The bus master data transfer control system of claim 9 wherein said bus transfer controller manages the transfer of said first and second data packets through said buffer pool and wherein said arbiter system is coupled to said bus transfer controller for determining the selection of said first and second bus transfer control units.

11. The bus master data transfer control system of claim 10 wherein said first and second predetermined data packets represent individual data packets within a first stream of data packets, and wherein a third bus transfer control unit stored in said table specifies a third bus master data transfer of a third predetermined data packet of a second stream of data packets.

12. An I/O channel controller supporting the asynchronous transfer of a plurality of continuous transfer data streams between a memory and a plurality of I/O interface units, said I/O channel controller comprising:
a) a FIFO pool buffer including a plurality of dynamically allocable FIFO buffers through which streams of data are asynchronously transferred;
b) a plurality of I/O interface units; and
c) a transfer control unit providing for the storage of one or more transfer control data units, said transfer control unit autonomously monitoring the amount of data buffered by any of said dynamically allocable FIFO buffers relative to a predetermined threshold amount and for selectively initiating the transfer of portions of said streams of data as defined by respective ones of said transfer control data units between said memory and said FIFO pool buffer.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to the following Applications, all assigned to the Assignee of the present Application:

1. Multiple Parallel Digital Data Stream Channel Controller, invented by Gifford, et al., Our ref.: DIAM 3000 GBR, application Ser. No. 08/614,729, filed Mar. 13, 1996.

2. Distributed Status Signaling System for Multi-threaded Data Stream Transport Control, invented by Lewis, et al, Our ref.: DIAM3005GBR, application Ser. No. 08/596,921, filed Mar. 13, 1996.

3. Method and Apparatus Supporting Demand Driven Multiple Parallel Digital Data Stream Transport, invented by Spencer, et al., Our ref.: DIAM3011GBR, application Ser. No. 08/615,682, filed Mar. 13, 1996.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to high-performance peripheral data interfaces and, in particular, to a multi-threaded, bus-mastering, input/output (I/O) channel controller architecture applicable to general purpose personal computers, computer workstations, and embedded communications and network data routing and conversion functions.

2. Description of the Related Art

The continuing development of typically multimedia, network and communications oriented applications for personal computers and computer workstations is fundamentally dependant on performing computationally intensive operations on high data throughput digital data streams. Typically required computationally intensive operations include three dimensional (3D) audio generation and manipulation, wavetable based audio synthesis, V.34 protocol serial data signal generation and detection, and analog speech filtering and compression These operations, if implemented in software, will conventionally consume between 20 and 40 million instruction cycles per second each (MIPS) when performed by the main or host processor of the personal computer or workstation system. In addition, supporting the associated high throughput data stream transfer to conventional peripheral coder/decoder chips (CODECs) will consume an additional one to two MIPS per digital data transfer stream.

However, conventional microprocessors found in personal computer and workstation systems are generally capable of upwards of only 60 MIPS sustained, and more typically 20 to 30 MIPS. Context switches, memory management, and peripheral wait states further operate to constrain the effective MIPS available to computationally process and transport digital data streams. Since, as a practical matter, significant host processor MIPS must be reserved for the execution of typically end-user applications concurrent with the performance of multimedia functions, the need for peripheral hardware support in processing digital data streams has been generally acknowledged.

In adding peripheral hardware support for multimedia, network and communications applications, both hardware and software interface considerations need to be addressed. Any peripheral hardware used needs to be cost effective in adding computational functions without, in turn, burdening the host processor with hardware service requirements. Any added support burden directly compromises the net effective MIPS gain obtained through the addition of the peripheral hardware.

Similarly, the software interface to the peripheral hardware needs to efficiently interface with the operating system executed by the host processor to enable effective sustained use of the peripheral hardware. An ineffective software interface results in an increased MIPS commitment by the host processor to communicate with the peripheral hardware. Again, any increased processing burden due to complexities in managing the software interface to the peripheral hardware results in a direct reduction in the effective sustained processing MIPS obtained by use of the peripheral hardware.

Conventional approaches to providing peripheral hardware support for multimedia, network and communications applications include providing various combinations of dedicated integrated circuits (chips) implementing substantially hardwired or only partially configuration programmable computational functions and highly software programmable digital signal processors (DSPs). Dedicated function chips typically implement a limited signal processing function or small set of related functions in a low cost tightly packaged form. The supported functions are typically of specific functional scope and programmability is mostly restricted to initial configuration options and modest, if any, dynamic controls.

As a hardware peripheral, dedicated function chips typically provide little or no direct support for managing continuous real-time signal processing of digital data streams, let alone support for multiple data stream transport. Such chips typically act as mere consumers or producers (sources or sinks) of a digital data stream that is pulled from or pushed to the chips at the available maximum or some desired rate determined by the host processor. Consequently, peripheral hardware utilizing dedicated function chips is subject to conventional data stream transfer interruptions and transport speed limitations due to, for example, excessive host processor interrupts, context switching, and various memory management kernel processing, as well as a fundamental competition for host processor CPU cycles with other applications being concurrently executed by the host processor. System wide competition or limited system hardware support for multiple logically concurrent direct memory access (DMA) data transfers will also reduce sustained data transfer rates to a dedicated function chip. Furthermore, the typically single stream nature of dedicated function chips directly requires a substantial involvement by the host processor in performing data stream initialization, transport control and any required data stream mixing or multiplexing operations. Consequently, while dedicated function chips can provide a significant increase in the multimedia and digital signal processing capabilities of a personal computer or workstation system, a substantial and generally unbounded processing burden remains with the host processor.

General purpose digital signal processors have been implemented in peripheral hardware systems particularly where complex and high speed signal processing computations are required. Conventional DSP chips are capable of providing upwards of 50
MIPS in a computational architecture well suited for data stream processing. In general, such DSP chips are relatively expensive and require relatively intensive software development programs to implement the software algorithms needed to perform their intended functions. However, DSP chip architectures are generally not optimized for controlling extended data transfer operations or memory management functions. Rather, the architectures are typically optimized to read, process, and write data with respect to internal dedicated memory and external locally connected memory or directly connected dedicated function peripheral chips. Consequently, the host processor must again be substantially involved in data transfers to the memory space of a DSP implemented as peripheral hardware. Unfortunately, this generally results in the DSP being subject to the same limitations on the obtainable and sustainable performance of the host processor as in the case of dedicated function chips.

In order to bound interruptions in the transfer of data to multimedia peripheral hardware, and thereby improve the sustainable data transfer rate obtainable from a host processors, a conventional operating system executed by the host processor may be augmented with a small, preemptive real-time kernel, such as SPOX. This kernel can be implemented as a low-level device driver supporting the real-time interrupt and data transfer requirements of the multimedia peripheral hardware. While such a real-time kernel does tend to ensure execution of maximum sustained data transfers to and from the DSP memory space, the host processor incurs the same substantial overhead of managing the data stream transfers as well as the additional execution overhead of the real-time kernel itself.

Consequently, present multimedia, network and communications peripheral hardware subsystems implemented typically for personal computers and workstation systems do not well address the need to efficiently provide additional processing capability through the addition of the peripheral hardware.

Various host based signal processing architectures, such as native signal processing (NSP) and Direct-X, have been proposed and largely defined to address, among several objectives, the requirement that a well formed software interface be provided to the operating system for multimedia, network and related communications operations. A host based signal processing architecture relies on the specific use of the host processor itself to perform at least high level signal processing functions. Such architectures have at least two immediate benefits. The first benefit is that, by significantly processing data streams before transport ultimately to peripheral hardware, the data streams are mixed, multiplexed or computationally reduced to lighten the processing overhead involved in the data transport to the peripheral hardware. Thus, the effective processing performance of the personal computer or workstation system may be slightly to significantly improved

The second benefit is that a potentially comprehensive application programming interface (API) is presented to the operating system, thereby tending to virtualize particular implementations of the physical and functional peripheral hardware Multimedia, network and related communications applications can therefore effectively assume broader or simply different support for desired functions than actually provided by any particular implementation of peripheral hardware. Where direct support for a particular function is not directly provided by a particular instance of the peripheral hardware, the function is performed in software by the host processor, executing as the host based signal processor, down to a functional level that is supported by the particular instance of the peripheral hardware.

While host based signal processing can increase the efficiency of the personal computer or workstation system in performing multimedia, network and communications functions, many of the functions supported by host based signal processing are still quite computationally intensive. Thus, host based signal processing represents a most direct burden on the host processor. Furthermore, while host based signal processing does have the potential for significantly reducing the volume of data transported to or from the peripheral hardware, as a practical matter the computational burden on the host processor will not be substantially affected and, in any event, will remain quite significant.

SUMMARY OF THE INVENTION

Thus, a general purpose of the present invention is to provide a peripheral I/O controller supporting multiple, parallel variable bandwidth data streams over a high total bandwidth data transfer path established between a central processor and multiple multimedia, network and communications related peripheral devices.

This is achieved in the present invention through a bus transfer control system managing the transfer of multiple asynchronous data streams through a buffer pool. The bus transfer control system includes a buffer pool having a plurality of memory blocks, wherein each memory block provides for the storage of a plurality of data bytes and a plurality of data transfer devices coupled to the buffer pool to allow the transfer of segments of one or more data streams to be transferred between the plurality of data transfer devices through the buffer pool. A transfer controller maintains status information relating to the status of data in the memory blocks and includes control logic for repeatedly evaluating the status information and providing for the prioritied selection of a first data transfer device and a predetermined one of the memory blocks.

A computer system utilizing the multiple parallel digital data stream channel controller of the present invention can thus support the concurrent real-time transfer of a plurality of I/O data streams to and from an auxiliary data processing unit. The computer system can include a first processing unit including a first memory providing for the storage of a plurality of data streams characterized as each having a respective data transfer rate, a second processing unit providing for the manipulation of data within data segments of the plurality of data streams, and the channel controller coupled between the first and second processing units to provide for the transfer of the plurality of data streams between the first and second processors. The channel controller provides for the selective transfer of data segments of the plurality of data streams based on the respective data transfer rates of the data streams.

Thus, an advantage of the present invention is that it provides a dynamically allocated multi-channel control interface to a host processor system that, in turn, permits flexible programmability and control over the operation of the channel controller.

Another advantage of the present invention is that it minimizes host processor performance loading by performing substantial autonomous data transfer functions and dynamic flow management. The channel controller supports internal interrupt management that minimizes both host and DSP interrupt support burdens, thereby enabling and supporting real-time multiple parallel channel signal processing through a comprehensive interrupt source managed data stream channel connecting the host with auxiliary signal processing units.

A further advantage of the present invention is that it provides for the dynamic buffer sized, rate-controlled flow of multiple streams of data through the channel controller, optimally utilizing the maximum available peripheral I/O channel data bandwidth. Stream transfers are independent of stream data type. Each of the data stream channels of the channel controller exist as logically independent channels. The channels can be serially combined to provide discrete data routing paths through additional or on-board signal-processing circuitry as well as external peripheral signal processing units.

Still another advantage of the present invention is that the provided autonomous bus master operation removes the requirement for conventional direct memory access operation as well as host processor involvement in data transfers through the I/O channel controller. Interleaved transfer of segments of data streams enables the effectively concurrent parallel transfers of digital data streams to and through the channel controller. This substantially alleviates the need for host application context switches and most host user to interrupt kernel mode switches while providing real-time transport support for multiple concurrent data streams.

A yet further advantage of the present invention is that it provides dynamic support of variable rate real-time time signal processing by ensuring effectively continuous flows of data between data sources and sinks at the dynamic data rate established by the stream peripheral for each data transfer channel.

Yet still another advantage of the present invention is that it provides readily extensible support for auxiliary signal processing units including units that are fully programmable and others that provide only partially or even fully hardware implemented functions.

A still further advantage of the present invention is that the channel controller is programmable as a composite function peripheral that effectively moderates computer system cost by greatly expanding the independent and cooperative signal processing functionality of data intensive peripheral subsystems.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other advantages and features of the present invention will become better understood upon consideration of the following detailed description of the invention when considered in connection of the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof, and wherein:

FIG. 1a is a block diagram of a personal computer type system implementing a first embodiment of the I/O channel controller sub-system consistent with the present invention;

FIG. 1b is a block diagram of an I/O channel controller sub-system consistent with a second embodiment of the present invention;

FIG. 2 is a block diagram of a dedicated function embedded I/O Channel, based system consistent with an alternate preferred embodiment of the present invention;

FIG. 3 is a diagrammatic illustration of the software architecture relationship of an I/O channel controller sub-system in relation with an operating system and multiple external hardware interfaces;

FIG. 4 is a diagrammatic illustration of the high level control and physical data flow supported by an I/O channel controller consistent with the present invention established in relation to an operating system;

FIG. 5a is a detailed block diagram of a preferred embodiment of an I/O channel controller of the present invention;

FIG. 5b is a detailed block diagram of a preferred embodiment of a bus transfer control system of the present invention;

FIG. 5c is a detailed block diagram of a preferred CODEC embodiment of an integrated peripheral interface of the present invention;

FIG. 5d is a detailed block diagram of an interrupt controller integrated peripheral of a preferred embodiment of the present invention;

FIG. 6 is a detailed block diagram of a FIFO pool sub-system of an I/O channel controller constructed in accordance with a preferred embodiment of the present invention;

FIG. 7 is a detailed block diagram of a bus transfer unit controller sub-system of a preferred embodiment of the I/O channel controller of the present invention; and

FIGS. 8a-c are control flow diagrams illustrating preferred modes of operation of an I/O channel controller based system consistent with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

I. I/O Controller System Architecture

FIG. 1a provides a block diagram of a computer system 10, preferably implementing a personal computer architecture, that is coupled to a multi-function I/O peripheral controller hardware system (I/O channel controller) 22. A host processor 12, typically an Intel.RTM. Pentium.RTM. CPU, Motorola PowerPC.RTM. CPU, or the like, is coupled to a system main memory 14 via a processor bus 16. A conventional peripheral component interconnect (PCI) bridge interface 18 provides a high performance data and control connection between the processor bus 16 and a mezzanine PCI bus 20. The multi-function peripheral system 22 is coupled to the PCI bus 20 through a conventional PCI adapter bus connector 24. An I/O channel controller core 26 that is centrally responsible for managing data and control signal transfers with respect to the PCI bus 20 is also coupled to the adapter bus 24. The I/O channel controller core 26 operates as a substantially autonomous bus master peripheral controller supporting multiple concurrent data and control signal transfers between the PCI bus 20 and system 22. These concurrent transfers are preferably managed as independent pairs of data streams and control threads of execution where each stream is composed of discrete block transfers, consisting of one or more bytes of data, through the I/O channel controller 26. Data blocks of concurrently supported streams are interleaved among one another to effectively establish concurrent stream data transport.

In accordance with the present invention, the interleave of data blocks is determined by the controller sub-system 22 and, in general, independent of the execution of the host processor 12. The interleave of data blocks implemented by the I/O channel controller core 26 reflects the respective demand transport rates of the individual data streams as determined from the nature of the stream data transported. Consequently, where stream data represents a constant data frequency audio signal stream, the interleave of data blocks in the audio data stream may vary, though generally maintaining a fixed through-put rate reflective of the data stream transfer rate independently demanded by an audio stream coder/decoder (CODEC). Where the demanded data rate is not a constant, such as where variable rate audio or video compression is utilized, the data block interleave may further vary though again in accordance with the demanded data transfer rate appropriate for the compressed data stream.

In a preferred embodiment of the present invention, the I/O channel controller core 26 supports a number of directly connected serial bus peripherals 28. These serial bus peripherals 28 preferably include dedicated function chips that implement specific high speed, typically serially oriented data transport functions. A typical serial bus peripheral 28 includes a dedicated function chip providing high speed serial universal synchronous/asynchronous rate transfer (USART) function. Another possible serial bus peripheral 28 may implement a dedicated function chip set providing a low-cost hardware based audio sub-system.

The I/O channel controller core 26 also preferably provides a high speed, general data and control bus 30 in support of a wide range of data processing and transport peripherals. One or more digital signal processors (DSPs) 32, 36 and associated DSP RAM 34 can be attached to the bus 30 to provide high performance computational support for indirectly attached peripherals, such as the serial bus peripherals 28, a parallel bus peripheral 38 and the host processor 12. Although dependant on the particular implementation of the DSPs 32, 36, the DSP RAM 34 preferably exists internal to the DSPs 32, 36 and is mapped into an common address space accessible by the bus 30. The DSPs 32, 36 preferably also provide interface control support for directly connected peripherals, such as the serial bus peripherals 40, 42.

The DSPs 32, 36 permit a variety of different computational and control functions to be performed generally independently and in-parallel with respect to one another. Thus, for example, the digital signal processor 32 may implement a range of signal processing functions as appropriate to support a variety of telecommunications specific serial bus peripherals 40 Such a digital signal processor 32 can implement signal processing algorithms that perform the protocol and signal processing necessary to implement a high speed fax modem, an integrated services digital network (ISDN) connection, and a wireless data transceiver systems. The serial bus peripherals 40 directly connected to the digital signal processor 32 can appropriately include a plain old telephone system (POTS) interface, an ISDN interface and a low-power FCC compliant RF or IR data transceiver.

A second digital signal processor 36 can independently or cooperatively provide audio and video signal processing functions including 3D audio synthesis, wavetable based audio signal generation and mixing, speech and music reproduction, and speech recognition. The serial bus peripherals 42 directly connected to the digital signal processor 36 may then include appropriate CODECs and filters for performing high speed bi-directional digital-to-analog signal conversions.

Parallel bus peripherals 38 are preferably connected directly to the bus 30 to support high speed parallel functions. The supported parallel function may include conventional high speed bi-directional parallel data transfers, a high-speed Ethernet-type network interface, as well as conventional EIDE and SCSI interfaces to conventional disk drives, CD-ROM drives, and the like. The parallel bus peripherals 30 may also include a direct or indirect interface through a video controller to the frame buffer of a video display controller. An additional function of the parallel bus peripherals is to provide a simple parallel/serial conversion function via one or more serial control lines 41 connected directly to a CODEC that is otherwise supported as a directly connected serial bus peripheral 42. As a practical matter, the serial connection 41 permits relatively direct control access to the CODEC by either the other DSP 32 or more likely the host processor 12 through a pass through connection to the bus 30.

By the implementation of the I/O channel controller 26, contention for data transfers among the various serial and parallel bus peripherals 28, 38, 40, 42 and digital signal processors 32, 36 is minimized. The maximum data through-put supported by the multi-function peripheral system 22 is effectively limited foremost by the available data transport bandwidth between the PCI bus 20 and system memory 14.

A somewhat more practical limitation on the data through-put supportable by the peripheral system 22 is the computational performance available from the digital signal processors 32, 36. This limitation, however, can be overcome in a number of different ways including increasing the number of digital signal processors coupled to the bus 30 and distributing the computational load among the parallelled processors. Also, utilizing higher performance digital signal processors will provide greater computational through-put.

Referring now to FIG. 1b, an alternate preferred peripheral system 44 is shown. The I/O channel controller core 46 provides enhanced support for the digital signal processor 32 by further removing the digital signal processor 32 from the potentially time critical data transport path of the data streams flowing through the serial bus peripherals 28 and, potentially, the parallel bus peripherals 30. Thus, while the digital signal processor 32 may process a data stream coupled directly through the serial bus peripherals 40, utilizing the I/O channel controller core 46 itself to control all data transfers between the serial and parallel bus peripherals 28, 38 and the DSP RAM 34 removes many if not most of the memory management and repetitive data transport functions from the digital signal processor 32. The DSP 32 is, in turn, permitted to spend more time on computational operations rather than extended data transfer operations for which the digital signal processor 32 may not be optimally suited. Consequently, the digital signal processor 32 almost exclusively operates on data moved between the RAM 34 and digital signal processor 32 using simple memory load and store operations. The subsequent transfer of data processed by the digital signal processor 32 and stored in the RAM 34 is transported to the serial and parallel bus peripherals 28, 38 without requiring any significant additional processing by the digital signal processor 32.

An embedded application of the present invention is shown in FIG. 2. The system 10' may operate as an intelligent stand-alone or remotely managed data stream processor. An embedded processor 12', such as an Intel 80196, and a main memory 14', preferably composed of a combination of DRAM and Flash EPROM, are inter-connected by a processor bus 16'. An I/O channel controller core 26' supports the transport of one or more potential overlapping data streams between the processor bus 16' and an I/O bus 30'. One or more DSPs 32' and any number of network peripherals, such as the network controllers 38', 38" are preferably attached to the I/O Bus 30'. The DSP 32' can directly service interrupts generated by the network controllers 38', 38" in support of their respective network data stream transport functions. The DSP may utilize the I/O channel controller to actually control the transport of data over the I/O bus 30' and, as desired, through to the main memory 14'.

In one preferred embedded embodiment, the embedded system 10' functions as an intelligent high-performance network data router. The embedded CPU 12' executes a control program provided in the Flash EPROM of the main memory 14' that supports conventional SNMP router management functions, and data gathering and diagnostic functions. The DSP 32' executes a control program from internal DSP memory that is either down-loaded from main memory 14' by the embedded CPU 12' or is provided in Flash EPROM in or associated with the DSP 32'. The DSP control program provides for the establishment and management of data routing and filtering trees within the DSP memory. As data packets are received by a network controller 38', source and destination packet data is passed to and processed by the DSP 32' against the routing and filter trees to determine whether and how to forward the packet. Both the DSP 32' and embedded CPU 12' may be employed to perform protocol conversions and provide for the implementation of security protocols as desired

II. Software System Architecture

The operation of the I/O channel controller in terms of data flow as related to the major components of the computer system 10 is shown in the diagram 50 of FIG. 3. An outbound stream of data effectively originates with an application program executed in conjunction with an operating system by the host processor 12. The execution of an application within an application layer 52 results in a transfer of data 56 to a main memory storage space 54 within the memory 14. This data may be further manipulated under the direction of the application through the execution of the host processor 12 operating as a host-based signal processor. Thus, the data stream 60 may be iteratively transferred between the memory space 54 and the host signal processing layer 58. The particular signal processing actually performed by the host processor 12 is substantially determined by the various device drivers that together implement the full or available functionality of the particular implemented host based signal processor API (HBSP API). Directly or indirectly, HBSP API calls are eventually resolved to calls to an I/O channel controller device driver that initiates a data transfer control thread to transfer the data stream 64 from the main memory space 54 to the I/O channel controller core 62 for further transport and potential processing. Once the host processor 12, in executing the I/O channel controller device driver, has set up a control thread in the main memory space 54 defining the data stream transfer 64, the host processor 12 then operates to simply enable processing of the control thread on demand by the I/O channel controller 62. The I/O channel controller core 62 is thereafter responsible for actually performing the data stream transfer.

The host processor establishes a control thread in the main memory space 54 by constructing one or more linked bus transfer unit (BTU) control blocks to associate the stream data as provided in the main memory space 54 with the control thread. The host processor 12, in execution of the I/O channel controller device driver, initializes the I/O channel controller 62 with the initial BTU control block and programs certain configuration registers of the I/O channel controller 62 to configure the selection of a particular routing of the data stream through the I/O channel controller 62. Thereafter, the host processor 12 does not participate in the actual transfer of the data stream 64 to the I/O channel controller core 62. The data stream transfer is carried out under the direct control of the I/O channel controller core 62 as a bus master peripheral arbitrating with the host processor 12 for access to the main memory space 54. Consequently, the initiation and continued performance of multiple parallel data stream transfers to the I/O controller 62, as defined by respective control threads, are carried out effectively independent of one another and may be asynchronously initiated and completed by the I/O channel controller core 62.

Each bus transfer unit at least implicitly specifies the destination of an associated data stream. A data stream may be directed to the RAM memory space of a digital signal processor 68 or to a specific external hardware interface 74 of the various directly connected serial and parallel bus peripherals 28, 38. As a data stream 70 is processed by the digital signal processor 68, the resultant data 72 may be transferred to a directly connected external hardware interface 74 of a serial bus peripheral 40, 42. Alternately, resultant data may be stored back into the DSP RAM space. From the DSP RAM, the data stream 72 may be subsequently transferred again by the digital signal processor to any directly connected serial bus peripheral 40, 42.

Bus transfer unit control blocks that define a control thread for transferring the DSP RAM stored data stream 69, 80 can be provided in either system main or DSP memory 14, 34. Preferably, the DSP control thread bus transfer unit control blocks are established in system memory 14 by the host processor 12. Management of the DSP RAM 34 memory space is performed globally by the host processor 12 and thereby allows the DSPs 32, 36 to operate by definition independent of one another with respect to the use of the DSP RAM 34.

The DSP bus transfer unit control blocks are defined to control the transfer of one or more data streams through and under the control of the I/O channel controller core 62 to any of the external hardware interfaces 74 of the serial and parallel bus peripherals 28, 38 that are directly connected to the I/O channel controller 62. Alternately, the I/O channel controller core 62 may be directed to pass the processed datastream 84 back to the main memory space 54 potentially for further processing by the host based signal processor 58 or for use by an application 52.

The digital signal processor 68 and I/O channel controller core 62 receive inbound data streams 76, 82 from their directly connected external hardware interfaces 74. Where a data stream 76 is received directly by the digital signal processor 68, the data stream is preferably processed and stored to the DSP RAM 34. Subsequent transfers of the data so stored are coordinated by BTU control blocks provided preferably within the system main memory 14. This DSP BTU control thread directs the transfer of the data stream 69 to the I/O controller 62 for transfer as a stream 84 on to the main memory space 54 or to be redirected as a stream 80 to an the external hardware interface 74.

An inbound data stream 82 from an external hardware interface 74 connected directly to the I/O channel controller core 62 is redirected as a data stream 84 to the main memory space 54. Alternately, the data stream 82 may be directed as a stream
70 to the DSP RAM 34. In the latter instance, the data stream is typically processed by the digital signal processor 68 and provided either as a stream 72 directly to the external hardware interface 74 or as a stream 69 passed to the I/O channel controller 62 for return as a data stream 80 to an external hardware interface 74 or as a data stream 84 to the main memory space 54.

In general, an inbound data stream is ultimately routed to the main memory space 54. Once present in the main memory space 54, the data stream 60 may be further processed by the host based signal processor 58. Finally, a data stream 86
representing the fully processed inbound data stream maybe returned from the main memory space 54 by the operating system to an application program 52.

The data stream management system 50 of the present invention thus provides multiple data paths that may be flexibly defined and iteratively traversed to efficiently obtain a maximum processing of multiple effectively parallel data streams through an ordered combination or sub-combination of the host based signal processor 58, I/O channel controller 62, digital signal processor 68 and external hardware coupled through the external hardware interfaces 74.

Another view of the system 50, as shown in FIG. 4, illustrates the control and data flow paths established within the computer system 10 in accordance with the present invention. An application program layer 90 includes any number of co-executing applications 92, 94. These applications 92, 94 make application programming interface (API) calls into an operating system layer 96 that includes a base operating system 98 and operating extensions including, typically, MIDI 100, TAPI 102, and speech API 104 operating system extensions. Any number of additional or alternate APIs can be established within the operating system layer 96 consistent with, for example, the Direct-X API specification for Ring 3 operating system extensions. A memory block 106 is also shown as logically co-resident with the operating system 98 in the operating system layer 96 for convenience.

A device driver interface layer 108 includes the various Ring 0 device drivers needed to support the communications and data transfer between the operating system layer 96 and any components implemented as part of a peripheral layer 114. In particular, the device driver interface layer 108 includes an interrupt handler 110 and device driver 112 that provide, through execution by the host processor 12, support for an I/O channel controller 116 established within the peripheral controller layer 114.

Finally, in accordance with the present invention, a controller peripheral layer 118 is provided. This controller peripheral layer 118 includes generally a digital signal processor 120, a memory 122 accessible by the DSP 120 and dedicated function external hardware 124 potentially accessible by both the DSP 120 and I/O channel controller 116.

In a typical control flow, an Application A 92 establishes a data stream within the memory 106 through a conventional interaction with the operating system layer 96. As at least the initial portion of the data stream is constructed in the memory
106, the device driver 112 is called from the operating system layer 96 to prepare for a transfer of the data stream through the I/O channel controller 116 to the memory 122 or external hardware 124 of the controller peripheral layer 118. The device driver 112 establishes one or more BTU control blocks within the memory 106 defining a control thread necessary to implement the data stream transfer. The initial BTU of the control thread is programmed by the device driver 112 into the I/O channel controller 116 and a signal is provided to enable the operation of the I/O channel controller 116 with respect to the programmed BTU. The operation of the I/O channel controller 116 is, thereafter, substantially autonomous in completing the data stream transfer defined by the BTU programmed into the I/O channel controller 116 and any other BTUs in the memory 106 that are part of the control thread defining the data stream transfer.

Where the target of the data stream transfer is the memory 122, the device driver 112 will first establish another series of one or more BTU control blocks within the memory 106 to establish a control thread suitable for managing the DSP side transfer of a data stream. The initial BTU is programmed into the I/O channel controller 116 by the device driver 112. Next, the device driver 112 may post a command, specifying the desired function of the DSP, to the digital signal processor 120. Preferably, this command is posted through the use of programmed I/O (PIO) into one or more registers maintained by the I/O channel controller core 116 and readable by the digital signal processor 120 in response to a DSP interrupt signifying that a command message has been posted. In response to the posted command, the DSP 120 preferably initializes as necessary to perform the commanded function and then provides a signal 136 to the I/O channel controller 116 to enable the operation of the controller with respect to the pre-programmed BTU.

In response to having two enabled BTUs that are at least implicitly linked together, the I/O channel controller 116 initiates autonomous data transfers to retrieve a portion of the data stream defined by the host side BTU from the memory 106
directly 126, transiently store the data in an internal FIFO pool, and transfer the data autonomously to a sequence of locations in the memory 122 defined by the DSP side BTU. The autonomous operation of the I/O channel controller in accessing the memory 106 is preferably as a bus master device that participates directly in the memory cycle arbitration supported by the hardware bus management controller of the host processor 12 and PCI bridge interface 18. As a consequence, essentially no execution cycles of the host processor 12 need be utilized in actually performing the data transfer 126.

Execution cycles of the host processor 12 are effectively required to form the data stream in the memory 106 and, in typically executing the device driver 112, to initially establish and manage the series of one or more host side and DSP side BTUs that define the control thread for the data stream transfer. However, the execution cycles required in the creation and management of the BTUs by the host processor 12 are relatively minor in comparison to the execution cycles required to initially process and then store the data stream in the memory 106 under the control of an application 92, 94. Furthermore, the operation of the I/O channel controller 116 permits the formation of the data stream in the memory 106 to be loosely synchronous with the actual transfer of data 126 under the control of the I/O channel controller 116. Consequently, the limited execution of the device driver 112 by the host processor 12 in creation and management of host side BTUs need not be tightly coupled to the real time demand for data transfers through the I/O channel controller 116.

The loose synchronism in the execution of the host processor 12 in support of the I/O channel controller 116 is further facilitated by the autonomous demand driven operation and FIFO pool buffering functions of the I/O channel controller core 116
itself. The I/O channel controller core 116 is autonomously capable of fetching successive BTUs from both the memory 106 and memory 122, though preferably only from the memory 106, as a data stream transfer proceeds. Thus, as the portion of the data stream controlled by a BTU is completed, the I/O channel controller core 116 can fetch the next BTU in the control thread from memory and substitute the newly fetched BTU for the completed BTU. Thus, an outbound data stream directed to the memory 122 is transferred autonomously as long as successive source and destination control BTUs in the control thread are defined to provide for the ongoing transfer of the data stream. The rate that DSP side BTUs are completed, reloaded and re-enabled effectively reflects the data through-put rates demanded by the digital signal processor 120 in respective performance of each commanded function.

A simpler mode of operation occurs when the data stream destination is the external hardware 124. The I/O channel controller 116 provides limited but adequate buffering for data transferred to the external hardware 124 via the data path 130. As the external hardware 124 demands data from the I/O channel controller 116, a current BTU is utilized to control the transport of the data stream from the memory 106 to the I/O channel controller core 116. As the external hardware 124 draws down on the available data buffered by the I/O channel controller core 116, the controller 116 autonomously operates to refill the buffer from a location in memory 106 defined by the current BTU. As the data referenced by the current BTU is consumed by the external hardware 124, a next sequential BTU in the control thread is autonomously loaded by the I/O channel controller 116 from the memory 106 in order to maintain the transfer of the data stream 126

Incoming data streams are handled in a generally similar manner by the I/O channel controller core 116. A data stream received by the DSP 120 from directly connected external hardware may be processed by the DSP 120 and stored in the memory 122. Receipt of each incoming data stream is anticipated by the host processor 12 and a corresponding control thread of one or more DSP side BTUs is formed in the memory 106 with the initial BTU being programmed into the I/O channel controller core 116, subject to being subsequently enabled by the DSP 120. A control thread of one or more host side BTUs is also established in the memory 106 again with the initial BTU being programmed into the I/O channel controller core 116. Although empty, this initial host side BTU is preferably set to an enabled state.

A command message, specifying the function to be performed by the DSP 120, is then posted to a message storage register within the I/O channel controller core 116. Preferably, the message is acknowledged by the DSP 120, the requested function is initialized, a portion of the externally provided data stream is received and processed by the DSP 120 and stored in a known address block within the memory 122. An enable signal 136 is then provided to the I/O channel controller core 116 to enable the initial DSP side BTU and allow for the autonomous transfer of the received data stream. When the DSP side BTU specified data stream transfer has completed, the next DSP side BTU is loaded into the I/O channel controller core 116 and left disabled Meanwhile, a next portion of the externally provided data stream is received and processed into another known address block within the memory 122 that is referenced by the next DSP side BTU. Again, once this address block has been filled with processed data, the now current DSP side BTU is enabled in response to the enable signal 136. In general, the two address blocks in the memory 122 are successively alternatingly used in successive alternation for the processing of a single data stream.

When the address block specified by the current host side BTU in the memory 106 is filled by the processed incoming data stream, the BTU is complete and the I/O channel controller core 116 issues an interrupt 132 to the interrupt handler 110 that calls the device driver 112 to at least signal that the address block is available for host processing. Preferably, a next BTU specifying another address block in the memory 106 is also autonomously loaded in an enabled state by the I/O channel controller core 116 to continue the receipt of the processed incoming data stream.

Subject to the reasonable assumption that the transfer of data between the I/O channel controller core 116 and memory 106 is substantially faster than the rate that the DSP can receive, process and store data into the memory 122, minimal but adequate buffering within the I/O channel controller 116 can ensure that demand driven transfer of the data stream 128 occurs without data overrun.

The I/O channel controller core 116 also provides data buffering for any data stream received directly from the external hardware 124. In general, the external hardware 124 is enabled for operation in response to the host processor execution of the device driver 112. The I/O channel controller core 116 preferably provides a register interface to the device driver 112 that permits programmed I/O through to the programmable registers of the external hardware 124. Concurrent with the initialization of the external hardware 124, a BTU control thread is established in the memory 106 and an initial BTU is programmed into the I/O channel controller core 116 and enabled to control the receipt of data. A data stream 130 is buffered directly into the I/O channel controller core 116 at the externally demanded data transfer rate. In turn, the I/O channel controller 116 autonomously operates to transfer the received data stream to the memory 106 under control of the current BTU. Again reasonably assuming that the I/O channel controller core 116 can transfer data to the memory 106 at a rate greater, though preferably substantially greater, than that of the received data stream 130, data overrun is again effectively precluded.

III. I/O Channel Controller Architecture

The general architecture of an I/0 channel controller 140, constructed in accordance with a preferred embodiment of the present invention, is shown in FIG. 5a. The I/O channel controller 140 preferably employs three major internal buses, including a bus master program bus 142, a FIFO pool bus 144, and a PIO bus 146. The bus master program bus 142 provides a communication channel between any number of bus interface modules 148, 150 and a bus transfer control system 170. The FIFO pool bus 144 is a dedicated bus for typically high-speed burst data transfers between the bus interface modules 148, 150, a FIFO pool 172 and any number of integrated peripherals and peripheral interfaces 174-188. The PIO bus 146 provides a general purpose programmed I/O communications path between the bus interface modules 148, 150, the bus transfer control system 170, and the integrated peripherals and peripheral interfaces 174-188. A PIO bus access controller 151 operates as a PIO bus access arbiter between each of the bus interface modules 148, 150.

Each of the bus interface modules 148, 150 serve to connect the I/O channel controller core 140 with a respective external communications bus. The host interface module 148 serves to couple the I/O channel controller 140 to the external PCI bus
20 while the DSP bus interface module 150 similarly provides for an interface to the peripheral bus 30 that connects to the external digital signal processor 32 and DSP RAM 34.

The host interface module 148 connects to the address, data, and control (A/D/C) lines 154 of the bus 20 and provides an external interface for an interrupt line 156 driven by an interrupt controller internal to the I/O channel controller core
140. Within the host interface module 148, the address, data and control lines 154 connect to a host bus slave unit 158 and a host bus master unit 160. The host bus slave unit 158 provides a conventional register based programmed I/O interface to the PIO bus 146 so as to make the PIO bus 146 accessible to the host processor 12. The register interface also allows program access to and through the PIO bus 146 to programmable configuration and data registers of the various units internally connected to the PIO bus 146. The host bus slave unit 158 also provides an externally accessible register interface that permits programmed control of the host interface module 148. The host bus master unit 160 itself preferably includes the control logic appropriate to support conventional bus-master access arbitration on the PCI bus 20.

The DSP bus interface module 150 similarly connects the address, data, and control lines of the DSP bus 30. The address, data and control lines 162 connect to both a DSP bus slave unit 166 and a DSP bus master unit 168. The external interface for an interrupt line 164 driven by an interrupt controller internal to the I/O channel controller core 140 is also supported by the DSP bus interface module 150. The DSP bus slave unit 166 provides a programmable register interface that allows for programmable control of the DSP bus master unit 168 as well as supporting general programmed I/O access between the bus 30 and the PIO bus 146. The DSP bus master unit 168 also includes control logic appropriate to permit conventional bus-master access arbitration on the DSP bus 30.

Coordinated access to the PIO bus 146 by the host and DSP interface modules 148, 150 is controlled through the PIO controller 151. Each of the bus slave units 158, 166 must arbitrate for exclusive access to the PIO bus and through to any of the interface registers accessible by way of the PIO bus 146. In addition, the host bus slave unit 158 can request a PIO bus bypass to be established by the PIO controller 151. A bypass data path is established from the host process 12, through the host bus slave unit 158, the PIO bus 146 and the DSP bus slave unit 166. The host processor 12 is thus presented with a data path that allows all peripherals accessible via the DSP bus 30 to be controlled directly by the host processor 12. This is useful in simplifying the control over the operation of some of the parallel bus peripherals 38, for example, to directly set or read the control mode of a CODEC 42.

The bus transfer control system 170 operates as a central control system managing the transfer of burst data transfers between the host and DSP bus master units 160, 168, the FIFO pool 172 and the integrated peripherals and peripherals interfaces
174-183 that are connected to the FIFO pool bus 144. The bus transfer control system 170 maintains a programmable table of BTUs. In the preferred embodiment of the present invention, the BTU table provides simultaneous storage for 48 BTUs with each BTU occupying 16 consecutive bytes of storage. Table I provides a description of the preferred BTU structure.

TABLE I ______________________________________ Field Bytes Bits ______________________________________ Address 4 [31:0] Transfer Length 2 [15:0] Link Descriptor 2 [15:0] Control Word 2 [15:0] Status Word 2 [15:0] Reserved 4 [31:0] ______________________________________

The address field of a BTU structure defines the memory address used by the host and DSP bus master units 160, 168 for the transfer of data between the system main memory 14 and the I/O channel controller 26 and between the I/O channel controller
46 and DSP RAM 34. As a data transfer proceeds, the address field value of the BTU is updated to maintain the address value as a proper memory pointer. Conversely, the transfer length value is decremented as the transfer proceeds to maintain an accurate reflection of the remaining transfer length described by the BTU. In the preferred embodiment of the present invention, the host address space is treated as a flat 32 bit address field. The address field for purposes of DSP bus master transfers may be differently defined. As specified in Table II, a symmetric partition of the DSP RAM 34 can be readily enforced by definition of a high order bit or bits of the address field to selectively map the DSP RAM of multiple digital signal processors 32, 36 or other peripherals 38 that might provide or utilize a discrete storage area within the DSP RAM 34 into a common address space with respect to the I/O channel controller core 140.

TABLE II ______________________________________ Address (DSP only) Description Bit ______________________________________ DSP DSP#1 or DSP#0 31 DM Data (1) or Program (0) Memory 30 Reserved Reserved for future use [29:15] Address Byte Address [15:0] ______________________________________

The link descriptor field permits storage of an array pointer to a next sequential BTU in the current control thread. Preferably, the successive BTUs of a control thread not resident in the BTU storage space provided by the I/O channel controller 26 are stored in a table within system main memory 14, though BTUs can also be stored in DSP RAM 34. Where a BTU is stored in system main memory 14, a two-byte host base link address value is separately stored in a configuration register of the I/O channel controller core 140. This host base link address, effectively the base address of the BTU table in system main memory 14, is concatenated with the current BTU link descriptor value to provide a memory reference to a next linked BTU stored in system main memory 14. Conversely, the BTU link descriptor alone is sufficient to provide the entire address specification needed to access a linked BTU stored in the DSP RAM 34. The link descriptor field is utilized in the autonomous loading of a next linked BTU when the transfer length of a current BTU in the I/O channel controller core 26 is decremented to zero. Whether the link descriptor field is autonomously utilized to load a next BTU is determined by control bit values stored within a configuration control word register. Table III defines the preferred definition of the control word register

TABLE III ______________________________________ Control Word Description Bit ______________________________________ Bus Master Bus Master from DSP/Host memory 15 Interrupt Interrupt upon BTU completion [14:13] 00 No Interrupt 01 Host Interrupt 10 DSPA Interrupt 11 DSPB Interrupt Link Defined Link information is valid/not valid (i.e. wait) 12 Link Master Link to BTU link table [11:10] 00 No Link 01 Link from Host 10 Link from DSPA 11 Link from DSPB Data Conversion Select data transformation during transfer [9:8] Burst Length Burst 32/not 16 bytes at a time 7 Direction Transfer from/not to the FIFO 6 Reserved Reserved for internal use 5 FIFO Number Select FIFO from FIFO pool [4:0] ______________________________________

Within the control word field, the bus master bit defines whether the BTU corresponds to a host-side or DSP-side control thread. The interrupt sub-field defines whether and to whom an interrupt will be ultimately issued upon decrementing the BTU transfer length to zero. Encoding of an interrupt source vector and the actual generation of the external interrupt signal is controlled by an interrupt controller 188 internal to the I/O channel controller core 140. The link define bit specifies whether the link descriptor field maintains a valid value or not. The link master sub-field stores the base address location of the BTU link table in system main memory 14. The data conversion sub-field encodes a data transformation to be applied to the data as transferred, such as byte order reversal or byte/word conversion.

The burst length bit selects between 16 and 32 byte burst transfer lengths while the direction bit specifies the direction of the burst transfer. The FIFO number sub-field serves to identify the numeric identifier of a particular FIFO within the FIFO pool 172 that is to be used as either the source or destination of data transferred under the control of the current BTU.

Finally, the status word field of a BTU, as detailed in Table IV, defines individual bits that reflect whether a specific BTU is busy, such as during a BTU update operation that is autonomously performed by the I/O channel controller core 26, and whether the BTU is both valid and currently available, or enabled, for participation in the arbitration for a bus master access.

TABLE IV ______________________________________ Sub-Field Description Bit ______________________________________ Busy Bit BTU is busy transferring/linking (Read Only) 1 BTU Enable Allows BTU to arbitrate for Bus Master 0 ______________________________________

A multi-stage circular priority arbiter (CPA) is preferably implemented by the bus transfer control system 170 to continuously evaluate the currently enabled BTUs. The arbiter is coupled to the BTU table in a manner that allows direct identification of those BTUs that have their BTU Enable bit set. Within the identified set of enabled BTUs, the CPA operates to progressively select and stage BTUs for each of the host and DSP bus master units 160, 168.

The core algorithm implemented by the CPA operates in response to the set of access requests, further constrained to the identified set of enabled BTUs, that exist in an arbitration cycle. All possible requestors are ordered left to right in basic relative priority. The CPA of the present invention provides additional qualifications on the priorities of the enabled requestors. Specifically, the winning requestor of the immediately prior arbitration cycle effectively has no priority in the current cycle. The first enabled requestor, if any, to the right of the prior winning requestor is pushed to the highest priority in the current arbitration cycle with priority decreasing further to the right. If no enabled requestor exists in the current cycle to the right of the prior winning requestor, then the basic left to right relative priority of the enabled requestors is used to select a current winning requestor.

The decision matrix for the CPA is preferably implemented as a modified inverted binary tree. Additional control logic is provided to maintain state information that identifies the winning requestor of the immediately prior arbitration cycle. Also provided is state information that identifies the sub-trees that include the prior winning requestor and whether, at the lowest node in a sub-tree, the prior wining requestor is left or right relative to this lowest binary node. Consequently, an efficient mechanism is provided to ensure substantially fair arbitration among all potential requestors.

The bus transfer control system 170 is shown in greater detail in FIG. 5b. The bus transfer control system 170 includes the circular priority arbiter 190. Individual access requests for access to the BTU table 192 are received via control lines
194 from the devices connected directly to the bus master program bus 142 and the PIO bus 146. Data and BTU address portions of both the bus master program bus 142 and PIO bus 146 connect to the BTU table 192 to allow the reading and writing of BTUs. The bus master program bus 142 also connects to a BTU scanner 196 that is treated by the arbiter 190 as continually requesting access to the BTU table 192. The BTU scanner 196 operates to continually scan enabled BTUs stored in the BTU table 192 for the purpose of staging BTU identifiers and related data in host and DSP staging registers within a internal register set 198. The preferred BTU register array definition is provided in Table V.

TABLE V ______________________________________ Sub-Field Description Bytes ______________________________________ BTU Control Reset, single step scan, enable, and 2 remove valid for programming restriction Host Base Link Value host BTU table offset in main memory 2 Host Best BTU best BTU register 2 Host Current BTU current BTU register 2 Host Scan BTU scan BTU register 2 DSP Best BTU best BTU register 2 DSP Current BTU current BTU register 2 DSP Scan BTU scan BTU register
2 ______________________________________

Each access to the BTU table 192 is uniquely arbitrated through the operation of the arbiter 190. The bus master units 160, 168 each separately request access to the BTU table 192 whenever they are otherwise idle to obtain BTU stored data that will be programmed into the bus master unit 160, 168 to define a bus master burst data transfer. The bus master units 160, 168 also request access to the BTU table 192 following a burst data transfer to update the currently active BTU.

The bus slave units 158, 166 are permitted access to the BTU table 192 via the PIO bus 146. Such accesses are supported to typically allow the host processor 12 and DSPs 32, 36 to program initial BTUs into the BTU table 192 and to subsequently enable the BTUs. The PIO bus 142 can also be used to permit the host processor 12 to examine the state of the BTUs as needed to monitor data transfer progress at a low level and to analyze error conditions should they arise.

Essentially all other BTU table access cycles are made available to the BTU scanner 196. By considering only those BTUs that are enabled and thereby implicitly valid, the scan speed of the scanner 196 is maximized while reducing or minimizing the overall complexity of the scanner 196. As each valid and enabled BTU is scanned, the BTU scanner 196 also obtains supporting FIFO flag status information via the FIFO flag bus 171 for the FIFO referenced by the BTU being scanned. Consequently, the BTU scanner 196 makes effective and efficient of all accesses to the FIFO flag store.

Finally, the bus transfer control system 170 potentially generates interrupts depending on programmed controls upon each update operation of a BTU within the BTU table 192. Whether a particular update operation will result in the issuance of an interrupt is determined by whether the update operation signals a bus master transfer error, a BTU transfer complete, and the programmable interrupt specification bits within the control word of the BTU being updated. If an interrupt is to be generated, it is issued via control lines 200 to the interrupt controller internal to the I/O channel controller core 26.

Each BTU access arbitration cycle can be viewed as beginning when a BTU controlled bus master burst transfer completes by either the host or DSP bus master unit 160, 168. The corresponding BTU is updated and a next BTU, selected as a product of prior arbitration cycle, is used as the source of data for programming a bus master unit 160, 168 for the next bus master burst transfer. The data transfers specified by individual BTUs are not processed until complete, but rather segmented or partitioned on burst length boundaries and interleaved with the data transfers specified by other BTUs.

The next BTU is immediately available for use in programming a bus master cycle due to the pre-staging of arbitrated BTUs. Thus, when a next BTU is staged down for programming into either the host or DSP bus master units 160, 168, the circular priority arbiter operates to select and stage a new next BTU before the current bus master burst transfer completes. Consequently, the maximum potential data bandwidth supportable by the I/O controller is limited only by the potential bus master transfer speeds supportable between the I/O channel controller 26 and the system main memory 14 and RAM 34.

Table VI describes the bus master programming address and control interface employed by both the host and DSP bus master units 160, 168.

TABLE VI ______________________________________ Bus Master Address Bus Descriptions Bit ______________________________________ Address Start Address for Transfer [31:0] ______________________________________ Bus Master Xfer Control Descriptions Bit ______________________________________ Link Link rather than transfer 18 Transfer done Send TD to FIFO after transfer 17 BTU done Send BTUD to FIFO after transfer 16 FIFO Byte Enables FIFO byte enables (encoded) [15:14] Burst Number of bytes to transfer [13:8] Data Conversion Bytes swapping during transfer [7:6] (from BTU) Direction Transfer from/not the FIFO [5] FIFO Number FIFO from FIFO pool [4:0] ______________________________________

To program a bus master 160, 168 for a data burst transfer, an address portion of the bus master program bus 142 is provided with the memory address for the data transfer as maintained in the address field of the BTU. A transfer control bus portion of the bus master program bus transfers the control signals described in Table V to the bus master units 160, 168. The link control bit will specify that the current bus master burst transfer is for data and not a changed or linked-to BTU. The transfer done and BTU done control signals allow stream status information to be effectively encoded into FIFO data streams. The FIFO byte enables sub-field provides an encoded value of the ordered byte position of data within a four byte word that is being transferred in the current bus master data burst. The burst sub-field specifies the number of bytes to transfer as part of the program burst data transfer. The data conversion sub-field reflects the desired data conversion to be applied to the data transfer. The direction control bit identifies the direction of the burst data transfer. Finally, the FIFO number specifies the FIFO within the FIFO pool that is to participate in the burst transfer.

Once programmed, the host and DSP bus master units 160; 168 autonomously operate to arbitrate for and perform sufficient bus access cycles to carry out the programmed burst data transfer. Where the burst data transfer is into the I/O channel controller 26, the burst data is temporarily stored in a FIFO within the bus master units 160, 168. A separate, request acknowledge arbitration is then performed by the bus master units 160, 168 to gain access to and through the FIFO pool bus 144 to the FIFO pool 172. Data from the internal FIFOs is then transferred to the FIFO pool 172 and specifically to the FIFO specified by the FIFO identifier of the current BTU.

For data that is outbound from the I/O channel controller 26, the bus master units 160, 168 initially arbitrate for access to the FIFO pool 172 and pre-load their internal FIFOs with the burst length number of bytes from the FIFO specified by the BTU provided FIFO identifier. An autonomous bus master operation then proceeds to perform a burst data transfer from the internal FIFOs out from the host or DSP bus master units 160, 168.

A slightly different programming of the bus master units 160, 168 is utilized to retrieve a linked to next BTU in autonomously continuing, or at least preparing to continue either a host side or DSP side control thread. On completion a full data transfer specified by a BTU with a valid and enabled link descriptor, the BTU is cycled through the circular priority arbiter until the BTU is again selected to control a bus master burst data transfer. The zero transfer length of the BTU causes the link descriptor to be passed via the low order portion of the bus master program bus to the host or DSP bus master unit 160, 168, as appropriate. Where the BTU is stored in system main memory 14, the high order address portion of the bus master program bus is used to simultaneously provide the host based link descriptor to the host bus master unit 160. The BTUs in the RAM 34 are stored within the address scope of the link descriptor alone. In all events, the link control bit is set to signal that a linked-to BTU transfer burst is being programmed. Preferably, the internal FIFOs of the host and DSP bus masters 160, 168 have a depth at least equal to the size of a BTU. Thus, a single bus master burst transfer can be utilized to retrieve the desired BTU from either the system main memory 14 or DSP RAM 34. Once the desired BTU has been stored in a bus master internal FIFO, the host or DSP bus master unit 160, 168 requests access to the bus master program bus 142 to transfer the BTU to the bus transfer control system 170. Access is requested by the assertion of a request control signal on the bus master program bus 142. An acknowledge signal generated by the bus transfer control system 170 grants unique access to a word-wide update/link data bus 173 provided generally in connection with the FIFO pool bus 144.

TABLE VII ______________________________________ FIFO Update Bus Descriptions Bits ______________________________________ Update Flag indicates an Update cycle 1 FIFO Number number of the FIFO being updated 5 Read Size number of data bytes in FIFO 6 Write Size number of open bytes in FIFO 6 Read Byte Enables read byte selection within FIFO 4 Write Byte Enables write byte selection within FIFO 4 BTU Done BTU Done flag to Flag Store 1 Transfer Done signals transfer done 1 Space Available is space available in the FIFO 1 Data Available is data available in the FIFO 1 ______________________________________

A two-bit bus master link address bus is driven by the bus transfer control system 170 to coordinate the preferably three update/link data bus access cycles necessary to transfer the complete BTU to the BTU table within the bus transfer control system 170; the fourth byte is currently reserved and not transferred. The effectively linked-from BTU is overwritten with the linked-to BTU. The location in the BTU table of the current BTU is maintained by the bus transfer control system to permit a status update operation on the BTU following each bus master burst data transfer. Where the current BTU is also a linked-from BTU, the update operation directly provides for the in-place overwriting of the linked-from BTU with the linked-to BTU. The linked-to BTU is then cycled into the ongoing arbitration operation of the circular priority arbiter.

IV. Distributed Status and Control System

The bus transfer control system 170 generally serves to manage the transfer of data through the bus master interfaces 148, 150 with respect to the FIFO pool 172. However, the FIFO pool 172 itself implements access control logic that serves to centrally control the grant of data access cycles to the FIFO pool bus 144. As detailed in Table VII, the FIFO pool bus 144 preferably includes a 32-bit wide data bus, a five-bit wide address bus, and unique access request and grant control lines that allow each of the bus master interfaces 148, 150 and the integrated peripherals and peripheral interfaces 174-182 to individually request access to the FIFO pool bus 144 and to receive individual access acknowledged signals.

TABLE VIII ______________________________________ FIFO Pool Bus Descriptions Bits ______________________________________ Request request lines for FIFO pool access 10 Request Done last request to FIFO pool for this transfer 10 Acknowledge acknowledge lines for FIFO pool access 10 FIFO Number number of FIFO being accessed 5 Byte Enables byte selection within FIFO 4 Data In data from device to FIFO pool 32 Data Out data from FIFO pool to device 32 Direction data transfer direction 1 BTU Done BTU Done flag to Flag Store 1 Data Available is data available in the FIFO 1 ______________________________________

Associated with and generally part of the FIFO pool bus is the FIFO update bus (Table VI). The FIFO update bus preferably includes a five-bit FIFO status bus that is used to broadcast the FIFO identifier of a FIFO within the FIFO pool 172 to at least all of the integrated peripherals and peripheral interfaces 174-183 that are coupled to the FIFO pool bus 144. A FIFO identifier is broadcast over the update bus whenever data is added to or drawn from the corresponding FIFO in the FIFO pool 172. By effectively broadcasting notice of changes in the state of the FIFOs within the FIFO pool 172, the FIFO pool implicitly simplifies the necessary operation of the circular priority arbiter implemented within the FIFO pool 172 as well as the corresponding control logic necessary within each of the integrated peripherals and peripheral interfaces 174-183.

Distributed control logic is provided with each of the integrated peripherals and peripherals interfaces 174-183 that connect to the FIFO pool bus 144. Each of these integrated peripherals and peripherals interfaces 174-183 are preferably programmable with one or more FIFO identifiers, corresponding to the number of FIFOs in the FIFO pool 172 that are needed to support their respective functions. Each FIFO supports a unidirectional data stream, so pairs of FIFOs are required for full-duplex communication. The distributed logic in each of the integrated peripherals and peripheral interfaces 174-182 monitors the FIFO identifiers broadcast over the FIFO status bus for matches with their pre-programmed identifiers. When an identifier match is found, the integrated peripheral or peripheral interface 174-183 may then issue a control signal request for a data transfer cycle on the FIFO pool bus 144. A unique acknowledge signal is subsequently issued by the FIFO pool 172 to grant access to the FIFO pool bus. Thus, the circular priority arbiter of the FIFO pool 172 need only consider access requests from integrated peripherals and peripheral interfaces 174-183 for which a real data transfer can be performed. Furthermore, as there may be any number and combination of types of integrated peripherals and peripheral interfaces 174-183, the circular priority arbiter of the FIFO pool 172 is effectively isolated from needing to consider any specialized aspects of a data transfer cycle requested by any particular one of the integrated peripherals and peripheral interfaces 174-183. Specifics of operation that might affect the appropriateness of requesting a memory access cycle on the FIFO pool bus 144 is managed internally by each of the integrated peripherals and peripheral interfaces 174-182 as appropriate to their specific function. Consequently, substantial portion of the access determination and arbitration control logic is effectively distributed throughout the I/O controller 140. The control logic associated with the circular priority arbiter of the FIFO pool 172 need not be fundamentally or even significantly modified should the type, number or function of any of the integrated peripherals or peripheral interfaces 174-183 change between different specific implementations of the I/O channel controller core 140.

V. Integrated Peripherals and Interfaces

The integrated peripherals and peripheral interfaces 174-188 each preferably present a register based interface via the PIO bus 146 to the remainder of the I/O channel controller core 140. Each of these register interfaces are thereby accessible by the host processor 12 and digital signal processors 32, 36 by way of the host and DSP bus slave units 158, 166. The register interface to the PIO bus provided by each instance of the integrated peripherals and peripheral interfaces 174-188 may vary from simple to significantly complex. In general, the register interface is required to permit programming of the desired operation of the peripheral 174-188, to permit a reset of the peripheral 174-188, to specify the conditions upon which interrupts may be generated and the external processor to which the interrupt will be issued, and, where the peripheral 174-183 also connects to the FIFO pool bus 144, storage for a FIFO identifier for each concurrent data stream supportable by the particular peripheral 174-188.

In addition, each of the integrated peripherals and peripheral interfaces 174-183 include a data staging FIFO providing for the transient storage of data being transferred to or from the FIFO pool bus 144. Preferably, the depth of this internal FIFO is sufficient to protect against data under-runs and over-runs in view of the throughput data rate anticipated to be supported by the integrated peripheral or peripheral interface 174-183 and the worst case bus data transfer latency between the FIFO pool 172 and particular integrated peripheral or peripheral interface 174-183. Where the anticipated data transfer rate through an integrated peripheral or peripheral interface is sufficiently low, the internal FIFO may be implemented simply as a single buffer register. Peripheral internal FIFOs are, however, typically two to four bytes in depth.

A preferred MIDI interface peripheral interface 174 implements a relatively simple register interface to the PIO bus 146. The preferred control registers implemented by the MIDI interface peripheral 174 include a transmit control register and a receive control register. The register interface is detailed in Table IX.

TABLE IX ______________________________________ MIDI XMit Control Register Descriptions Bit ______________________________________ Reserved Not used or test values [31:7] Transmit Enable Enable MIDI transmit 6 Reset Reset the MIDI transmit port 5 FIFO Number FIFO from FIFO pool [4:0] ______________________________________ MIDI Receive Control Register Descriptions Bit ______________________________________ Reserved Not used or test values [31:10] Interrupt Select 00 => no interrupt generated [9:8] 01 => interrupt host CPU 10 => interrupt DSP 1 11 => interrupt DSP 2 Receive Enable Enable MIDI receiver 7 Reset Reset the MIDI transmit port 6 FIFO Number FIFO from FIFO pool [5:0] ______________________________________

The transmit control register includes a five bit FIFO ID field, a reset bit and a transmit enable bit. The receive control register preferably includes a five bit FIFO ID field, a reset bit, a receive enable bit, and a two bit interrupt field that encodes whether an interrupt is to be generated in response to an error condition coincident with the receipt of a data byte or word through the external interface or MIDI interface peripheral 174 and, if so, the intended destination of the interrupt. Interrupts are preferably generated by this peripheral 174 only on error conditions. Logically connected immediate transfer ports are preferably used to generate data transmitted/received interrupts that serve to control the flow of data through the MIDI interface peripheral 174.

The register interface to the CODEC peripheral interface 176 may be significantly more complex than that of the MIDI interface 174. Where a conventional external CODEC is to be attached to the CODEC interface 176, the register interface needs to provide access to the control and data registers of the external CODEC itself. Alternately, the CODEC peripheral interface 176 may itself implement part or all of the functionality of a conventional CODEC, thereby limiting the required external components connected to the CODEC peripheral interface 176 to comparatively minimal analog components. In this latter instance, the CODEC interface 176 is then a fully integrated peripheral that directly presents CODEC control registers to the PIO bus
146. In either instance, the CODEC interface 176 includes the logic necessary to permit the CODEC interface 176 to arbitrate for access on the FIFO pool bus 144 and to monitor for changes in the status of a FIFO pool 172 FIFO corresponding to a FIFO identifier programmed into a register of the CODEC interface 176.

FIG. 5c shows the preferred implementation of the CODEC interface 176 as used to support an external CODEC, such as an Analog Devices 1843 CODEC. The essential CODEC interface data path and control logic 180 provides support for multiple, essentially bidirectional data streams to be passed over the data portion of the FIFO pool bus 144 between respective pairs of FIFOs potentially allocated within the FIFO pool 172 and FIFO pairs internal to the CODEC interface 176. Preferably up to four outbound data streams are buffered through four internal FIFOs 210-212. A data multiplexer 216 provides for the selection of eight or 16-bit data variously from the FIFOs 210-214 in correspondence with the control mode established in the external CODEC. The byte or word data stream is passed through a clocked latch and serializer 218 under the control of a register interface and I/O control unit 220. Clock and control signals are provided by the register interface and I/O control unit 220 via the clock and control lines 222. The register interface and I/O control unit 220 coordinates the transfer of data with the external CODEC through the exchange of clocking and control signals on lines 224. Thus, subject to the operation of the register interface and I/O control unit 220, serialized data is provided on a serial data out line 226 to the external CODEC.

CODEC mode commands and command related data are also provided to the external CODEC on the serial data out line 226. Mode commands and data is preferably provided via the PIO bus 146 to the register interface and I/O control unit 220. The mode commands and data are then routed, via lines 214, through the multiplexer 216 and latch 218 while a command mode transaction is signaled via lines 224.

Serial data from the external CODEC is received on line 226 by a clocked de-serializer and latch 230. Depending on the current command mode of the external CODEC, status information and related data is provided through a de-multiplexer 232 and over lines 234 to the register interface and I/O control unit 220. Other byte or word wide data is provided from the de-multiplexer 232 selectively to any of four internal FIFOs 236-238 under the control of the register interface and I/O control unit
220.

The register interface and I/O control unit 220 also provides the request and acknowledge control logic to support data transfers over the FIFO pool bus 144. The register interface and I/O control unit 220 preferably provides register storage for up to eight FIFO identifiers. Each FIFO identifier permits a particular internal FIFO to be uniquely associated with any one of the FIFOs in the FIFO pool 172. The FIFO update portion of the PIO bus 144 is continually monitored by the register interface and I/O control unit 220 to identify when the status of an identified FIFO changes. The register interface and I/O control unit 220 typically issues a FIFO pool access request on behalf of the internal FIFO whose FIFO identifier matches the FIFO identifier broadcast over the update bus.

The FIFO identifier registers and other CODEC interface control registers are accessible typically by the host processor 12 via the PIO bus 146. The preferred CODEC register interface presented to the PIO bus 146 is provided in Table X.

TABLE X ______________________________________ CODEC Registers Descriptions Bit ______________________________________ Master Control DAC/ADC control [15] Audio Command command to Audio CODEC [14:9] Audio Data mode set data to Audio CODEC [8:3] Telephony Command command to Telephony CODEC 2 Telephony Status mode set data to Telephony CODEC 1 Status Command read-only CODEC status bits 8 Status Data read-only mode set data FIFO Number 0 FIFO enable bit and pool number 8 . . . . . . 8 FIFO Number 7 FIFO enable bit and pool number 8 Clock clock counter control 16 Host Mask host interrupt mask value 12 DSP Mask DSP interrupt mask value 12 Interrupt Control transfer done, under/over run bits 12 ______________________________________ Master Control Descriptions Bit ______________________________________ CODEC Reset resets all CODEC related logic [15] DAC Mode set DAC0,1 operating modes [14:9] ADC Mode set ADC0,1 operating modes [8:3] Audio Enable audio CODEC reset 2 Telephony Enable telephone CODEC reset 1 CODEC Identifier type of external CODEC 0 ______________________________________ Interrupt Control Descriptions Bit ______________________________________ Transfer Done FIFO 0 transfer done interrupt bit 1 . . . Transfer Done FIFO 3 transfer done interrupt bit 1 Under Run FIFO 0 under run interrupt bit (DAC1) 1 . . . Under Run FIFO 3 under run interrupt bit (DAC4) 1 Over Run FIFO 4 over run interrupt bit (ADC5) 1 . . . Over Run FIFO 7 over run interrupt bit (ADC8) 1 ______________________________________

A joystick peripheral and potentially associated control console may be supported through the digital joy stick interface 178. The peripheral joy stick typically provides resistances that are proportional to the physical position of the joy stick. The digital joy stick interface 178 preferably implements a timer and capacitor that, combined with the resistances presented by the joystick peripheral, permit digital values representing the position of the joystick to be repeatedly developed autonomously by the digital joystick interface. The host processor 12 is thereby relieved of the need to set and function as a timer to determine the position of the joy stick. Preferably, the digital joystick interface 174 can be programmed to signal an interrupt that is passed to the host processor 12 or a DSP 32, 36 whenever the determined digital values change. Even where an interrupt is not generated, the digital values are continually made accessible via the PIO bus 146 through the register interface presented by the digital joy stick interface 178.

Depending on the configuration and data requirements of any associated control console, as may be developed in support of various gaming and control applications, a data stream may be passed through the FIFO pool 172 and digital joystick interface 178. Where the data stream transfer rate is generally low and latency is a issue, a logically connected immediate transfer port is preferably used to generate interrupts to the host processor 12 or either of the DSPs 32, 36 as data is transferred to or from the digital joystick interface 178. Where latency is not a significant issue or where the required data rate is relatively high, full bus master data transfers through the FIFO pool 172 can be used.

Another type of integrated peripheral or peripheral interface is represented by the general purpose interface ports 180. In a preferred embodiment, the interface ports 180 may implement a high speed, very wide parallel port suitable for interfacing to video controller or directly to a video frame buffer. Successive double word wide data transfers from the FIFO pool bus 144 may be buffered into a 64 bit, 128 bit or larger words that are transferred in parallel to the video controller or frame buffer. In this instance, one or more video words may be register buffered within the interface port 180 so as to permit an optimal matching of the timing of the word transfer to the controller or frame buffer.

The interface ports 180 may also be utilized to read a video controller or frame buffer at high speed. One, though preferably two or more frame words may be read in successive parallel read operations from the video controller or frame buffer into a wide buffer register, also configurable as an internal FIFO relative to the FIFO pool bus 144. Double word wide sections of the frame words can then be transferred to and through the FIFO pool 172.

The immediate transfer port integrated peripheral 182 is provided to establish high-speed, low latency connections through the FIFO pool 172 for typically low-bandwidth, latency sensitive data streams. The immediate transfer port integrated peripheral 182 provides preferably six independent transfer ports. Each transfer port is represented by a control register and a data register accessible via the PIO bus 146. The control register definition is provided in Table XI.

TABLE XI ______________________________________ Immed. Transfer Port Ctl. Descriptions Bit ______________________________________ Space/Data Available set if space/data is available 15 Enable transfer port enabled flag 14 Reset reset transfer port 13 Data Width 8 or 16 data transfer 9 Direction transfer relative to FIFO 8 Interrupt Select 00 => no interrupt generated [7:6] 01 => interrupt host CPU 10 => interrupt DSP 1 11 => interrupt DSP 2 FIFO Number number of the pool FIFO [4:0] ______________________________________ Immed. Transfer Port Data Descriptions Bit ______________________________________ High Byte upper byte of word data [15:8] Low Byte lower or only byte of data [7:0] ______________________________________

The control register for an immediate transfer port permits the port to be programmed with a FIFO identifier, an interrupt target, a data transfer direction, the data byte or word width, a reset bit, an enable bit, and a space or data available bit.

The typical operation of an immediate transfer port is to monitor the update bus portion of the PIO bus 146 for any status change of an identified FIFO and to immediately issue an interrupt to the host processor 12 or DSP 32, 36 based on the programmed interrupt selection bits. A data stream transfer path is constructed between two processors utilizing 2 immediate transfer ports and a single FIFO in the FIFO pool 172. One of the immediate transfer ports is preferably programmed to issue a host interrupt whenever space is available in the identified FIFO. The second immediate transfer port is programmed to emit a DSP interrupt whenever data is available in the same identified FIFO. To initiate the data stream transfer and subsequently in response to host interrupts, the host processor 12 provides for the transfer of data through the host bus slave unit 158 and the PIO bus 146 to the I/O data register of the immediate transfer port associated with the host processor 12. The immediate transfer port places the received data in the identified FIFO of the FIFO pool 172.

In response to the FIFO identification broadcast by the FIFO pool 172 on the FIFO status bus, the second immediate transfer port issues a DSP interrupt. In response, a DSP 32, 36 accesses the I/O data register of the immediate transfer port. Data is read from the FIFO in the FIFO pool 172 and transferred to the DSP 32, 36 to be processed and, typically, written to the RAM 34.

Immediate transfer ports can be used in various combinations with the bus master interfaces 148, 150 and other integrated peripherals and peripheral interfaces 174-183 that access the FIFO pool 172. For example, the outbound data stream through the MIDI interface peripheral 174 may be transferred to a FIFO in the FIFO pool 172 by the host processor 12. When the change in the FIFO status in broadcast over the update bus, the MIDI interface peripheral 174 places a request for access to the FIFO pool 172 with the FIFO pool arbiter. As soon as access is granted, data from the FIFO pool 172 is transferred to the internal FIFO of the MIDI interface peripheral 174 and promptly output.

When data is removed from the identified FIFO in the FIFO pool 172, another immediate transfer port that has been programmed to respond to updates to the same identified FIFO preferably does not generate a host interrupt. In this instances the host processor 12 determines the timing for writes of MIDI data to the identified FIFO. When the host processor 12 determines to write MIDI data, the new data is written into the identified FIFO by staging the data through the data register of the host associated immediate transfer port. Where data is to be output at the maximum MIDI data rate, the host processor 12 can write more than a single byte or word of data into the FIFO of the FIFO pool. Thereafter, the host processor 12 can resume the output of MIDI data based on the time schedule determined by the host processor. Consequently, a low and substantially fixed latency cycle of transferring data from main memory 14 to the MIDI interface peripheral 174 can be sustained.

Inbound data through the MIDI interface peripheral 174 needs to be stored in system main memory 14 or RAM 34 with time stamp data. This time stamp data needs to be applied to the inbound data with a minimum and regular latency from the actual time of receipt by the MIDI interface peripheral 174. Consequently, an immediate transfer port is preferably associated with the MIDI input data FIFO in the FIFO pool 172 and programmed to issue an interrupt to either the host 12 or DSP 32 as data becomes available within the identified FIFO.

A DSP accelerator integrated peripheral 183 can also be provided as part of the I/O channel controller 140. In general form, the DSP accelerator 183 preferably implements a register interface available via the PIO bus 146 that supports connection with one or more input FIFOs from the FIFO pool 172 and one or more output FIFOs to return data to the FIFO pool 172 via the FIFO pool bus 144. Internally, the DSP accelerator 183 may implement dedicated hardware, a microcontroller, or both configured to perform, subject to programmable control register configuration, any of a number of computationally intensive data processing operations such as digital signal filtering, mixing and modulation. The number of FIFOs of the FIFO pool 172
connectable to the DSP accelerator 183 is therefore dependant on the particular functions potentially implementable by the DSP accelerator 183.

The message port integrated peripheral 184 provides a simple data path for transferring small quantities of data between the host and DSP processors connected to the I/O channel controller 140. In the preferred embodiment of the present invention, three message ports, each dedicated to source use by a particular host processor 12 or DSP 32, 36, are provided within the message port integrated peripheral 184. Each of the source dedicated message ports are represented as two 16 bit registers accessible from the PIO bus 146. Table XII describes the message port set and the control and data registers of each message port.

Table XII ______________________________________ Message Port Description ______________________________________ Port 0 host message send port Port 1 DSP 1 message send port Port 2 DSP 2 message send port ______________________________________ Message Port Control Register for Port # Descriptions Bit ______________________________________ Reset reset transfer port 15 Interrupt Select 00 => no interrupt generated [14:13] 01 => interrupt host CPU 10 => interrupt DSP 1 11 => interrupt DSP 2 Access Pointer word offset pointer in message [7:0] ______________________________________ Message Port Data Register for Port # Descriptions Bit ______________________________________ Data read/write data register [15:0] ______________________________________

The access pointer field operates as an auto increment pointer into a eight word (8.times.16-bit) deep message FIFO maintained internal to the message port. To send a message, the source processor clears the access pointer field, writes up to eight data words to the data register of the message port and then programs an interrupt to specify the destination processor for the message. The interrupt is effectively issued on setting the interrupt select field to a non-zero state.

To read a message in response to a message interrupt, the destination processor may read the appropriate access pointer field to identify the message length, set the access pointer field to zero to read the message from the beginning and then read the access pointer specified number of data words from the data register of the message port. Once the message data has been read, the interrupt select sub-field can be simply reset to zero. Alternately, the sub-field can be reset to a value specifying the message source processor with a zero length message has to act as an acknowledge of the receipt of a message. An acknowledge or return message can also be written to the message FIFO before setting the interrupt select sub-field to specify the source processor. In all events, the destination processor can uniquely identify the source processor by recognition of the particular message port utilized to send a message, since each message port is uniquely associated with a source processor.

A timer integrated peripheral 186 is provided to support both general purpose and special function time based operations. In a preferred embodiment of the present invention, three double word registers are presented by the timers peripheral 186
to the PIO bus 146, as detailed in Table XIII.

TABLE XIII ______________________________________ Timer Source Register Descriptions Bit ______________________________________ Timer Reset reset all timers 31 Count Value sets base frequency of source clk. [30:16] Count Down count down register [15:0] ______________________________________ Timer 0 Register Descriptions Bit ______________________________________ Enable timer enable 31 Mode multishot/single shot mode 19 Clear Interrupt clear interrupt timer state 18 Interrupt Select 00 => no interrupt generated [17:16] 01 => interrupt host CPU 10 => interrupt DSP 1 11 => interrupt DSP 2 Timer Value timer count down value [15:0] ______________________________________ Host Latency Timer Descriptions Bit ______________________________________ Timer Value timer count down value [15:0] ______________________________________

The first of these control registers provides for a 15- bit free running counter that serves a programmable time base for the other timer functions. The timer source register preferably includes a 15-bit down count field that ticks with each cycle of the system clock applied to the I/O controller 140. A 15-bit count value field stores a static base clock count value that is used to re-initialize the count-down sub-field each time the count-down sub-field reaches a value of zero. A single bit is provided as a reset control for the entire timers peripheral 186.

A general purpose timer zero register is provided to generate an interrupt on each expiration of the 16 bit count-down timer driven from the timer base clock. A timer zero register includes a 16 bit timer value that is decremented with each complete cycle of the timer base clock. A two-bit sub-field is provided to specify the processor to be interrupted on expiration of the timer zero value. Interrupt clear and timer enable bits are also provided. Finally, a mode control bit is provided to specify whether the timer zero is to act as a multi-shot timer or as a single shot timer. In the multi-shot mode, an expiration of the timer value an interrupt is generated and the timer value is reloaded. A second interrupt will only be issued only after a prior interrupt has been cleared. In single shot mode, the timer simply stops once an interrupt has been generated

A specialized host interrupt latency timer is also implemented. This timer is a count-up timer driven from the timer base clock. A 16-bit timer value increments from zero beginning with the assertion of an interrupt to the host processor 12. The host interrupt latency timer is stopped and the timer value is cleared when the timer value sub-field of the host interrupt latency timer register is read. This specialized timer permits the I/O controller core 140 to support analysis typically by the host processor 12 of the effective performance of the host interrupt service routine in responding to interrupts generated by the I/O channel controller 140.

Finally, an interrupt controller integrated peripheral 188 is provided to support management of the many different sources of interrupts generated by the I/O channel controller 140 during typical operation. In order to efficiently use the interrupt inputs available on the host and DSP processors, the I/O controller 140 preferably issues a single vectored interrupt to each of the processors. As shown in FIG. 5d, an interrupt register 242 generates, in the preferred embodiment, a host interrupt on line 156', a first DSP interrupt on line 164' and a second DSP interrupt on line 165'. The inputs 244 to the interrupt register 246 are received from either individual interrupt sources within the I/O controller 140 or from group interrupt registers 246, 250. The group interrupts can be read from the interrupt register 242 via the PIO bus. Table XIV provides the preferred definition of the group interrupts.

TABLE XIV ______________________________________ Group Interrupt Register Descriptions Bit ______________________________________ Timer Mask enable interrupt source 12 Imm. XFer Port Mask enable interrupt source 11 Message Mask enable interrupt source 10 Peripheral Mask enable interrupt source 9 BTU Mask enable interrupt source 8 Timer Interrupt group interrupt active bit 4 Imm. XFer Port Interrupt group interrupt active bit 3 Message Port Interrupt group interrupt active bit 2 Peripheral Interrupt group interrupt active bit 1 BTU Interrupt group interrupt active bit 0 ______________________________________

Preferably, the interrupt register 242 permits each of the group interrupts to be masked. Where an interrupt group is enabled by application of the interrupt mask to generator an interrupt, the selection of a specific interrupt target 156',
164', 165', is determined by the interrupt target information provided with the group interrupt signals 244. Consequently, the individual interrupt source is determinative of the particular interrupt destination though the interrupts are grouped through the interrupt register 242.

Where a large number of interrupts may be generated by a single component of the I/O controller 140, such as the bus transfer control system 170, or where many related components can be conveniently grouped together, the interrupt request lines
248, 252 can be directed to second level group registers 246, 250. In a preferred embodiment of the present invention, a number of the integrated peripheral and peripheral interfaces 174-186 are routed through a peripheral group interrupt register 246
to provide a single group interrupt to the interrupt register 242. Internal peripherals, such as the MIDI interface 174, and external peripherals such as those provided on the DSP bus 30 can each be a source of peripheral group interrupt. Table XV provides a preferred definition of the group mask and interrupt state register accessible via the PIO bus 146.

TABLE XV ______________________________________ Group Interrupt Register Descriptions Bit ______________________________________ Interrupt 7 Mask enable interrupt source 7 15 . . . . . . Interrupt 1 Mask enable interrupt source 1 9 MIDI Mask enable MIDI interrupt source 8 External Interrupt 7 external interrupt 7 active bit 7 . . . . . . External Interrupt 1 external interrupt 1 active bit 1 MIDI Interrupt peripheral interrupt active bit 0 ______________________________________

The group interrupt register 250 preferably provides a immediate port index field that reflects the interrupt state of each of the immediate transfer port interrupts. A single bit flag is used to mark whether the current readable index is valid or not. The immediate transfer port register (Table XVI) is accessible via the PIO bus 146.

TABLE XVI ______________________________________ ITP Interrupt Register Descriptions Bit ______________________________________ ITP Index Invalid valid/invalid flag; write to invalidate 7 ITP Index index of ITP in ITP array [2:0] ______________________________________

Finally, a BTU group interrupt register 254 provides a control register (Table XVII) that includes a BTU index field for identifying a specific BTU that is the source of an interrupt signal 256.

TABLE XVII ______________________________________ BTU Interrupt Register Descriptions Bit ______________________________________ BTU Index Invalid valid/invalid flag; write to invalidate 7 Transfer Done BTU transfer is complete 6 BTU Index index of BTU in BTU table [5:0] ______________________________________

A separate transfer done