System and method for data pacing

[0002] Field of the Invention

[0003] The present invention relates in general to the transfer of data between a DSP in a modem and a host computer, and more particularly to a system and a method for pacing such transfer of data using a burst mode and a wait mode, to achieve optimal modem performance without impairing the overall operation of the host computer.

[0004] Data communication devices such as modems are important and ubiquitous devices that transmit and receive data. Data may include, for example, text, sound, images and video. In general, a modem operates by converting a digital data stream into a modulated analog signal for transmission over an analog telephone line. Because traditional analog telephone lines are designed to transmit analog information (such as voice), the modem ensures that the modulated analog signal conforms to the voice-like signal requirements of the analog telephone line. The modulation of digital data into an analog signal is typically done by a digital signal processor (DSP). The DSP also performs demodulation in which digital data is extracted from analog signals received over the telephone line. The DSP may also handle other tasks such as error detection and correction. In some cases, these other tasks can be performed by another device such as a microprocessor. Along with connecting to the telephone line, conventional modems also connect to a host computer, for example a personal computer (PC). Some type of hardware is required make this connection between the modem and the PC.

[0005] Modems can be divided into two categories based on how they are connected to a host computer, namely external modems and internal modems. In the most basic terms, this refers to whether or not the modem resides physically inside the host computer enclosure. External modems typically have their own enclosure and are connected to the host computer by a cable. At each end of this cable, there is usually a device called a universal asynchronous receiver-transmitter (UART). One UART is built into the host computer and a second UART is built in the modem. The first UART accepts information in a parallel format from the central processing unit (CPU) in the host computer. The UART rearranges this data into a serial format and transmits it across the cable to the modem. The UART in the modem converts the data back into a parallel format. The DSP (or other microprocessor) in the modem receives this data out of the UART and eventually the DSP modulates the data for transmission over the telephone line. Alternatively, data received from the telephone line is demodulated and sent to host computer in a similar manner using the same UARTs and cable.

[0006] Modems also can take the form of an add-in card that is installed in an expansion slot on the host computer. These can be classified as internal modems since they reside in the enclosure of the host computer. In this implementation, the modems typically connect directly to a parallel bus on the computer system. Using this parallel bus the CPU can transfer data to and from the modem without the need for rearranging the data into a serial format as is done with an external modem. Although the serialization is not required, many internal modems still include UART hardware without the serial elements. This hardware essentially replaces both UARTs and the cable used with an external modem as just described. As will be explained, this UART hardware is included so that internal type modems can be compatible with software written for use with an external modem.

[0007] A major factor in the design of personal computer systems is compatibility. Generally, new software should work with files created by older revisions of that software, new programs should work with existing hardware, and new hardware may have to work with existing software. Software running on the PC directs the modem operation and handles data movement in both directions. The first types of modems to become popular were external modems that employed a serial cable and a UART arrangement. Software that supported this hardware arrangement also became popular. Internal modems, which were subsequently developed, provided a UART interface to be compatible with the software that was written for external modems.

[0008] One important measure of modem performance is data transfer rate. The data transfer rate, also known as throughput, is the speed at which data can be transferred between devices. Data transfer rates are usually measured in kilobits (one thousand bits) or megabits (on million bits) per second. A higher data transfer rate means that more information can be transferred in a shorter period of time. A higher data transfer rate is desirable because network traffic, telephone toll changes, network access charges and download times are reduced.

[0009] Historically, data transfer rate was limited by the speed of the modulation techniques to send data over the analog telephone line. However, since modulation techniques have improved, the end-to-end speed of a modem connection is sometimes limited by the connection between the PC and the modem. For external modem UART hardware, the associated serialization of data causes this limitation. The inherent nature of this serialization paces the data so that data flows at a constant rate between the host computer and the modem. In the case of an internal modem, serialization is not necessary and UART hardware on these modems can support a much higher data rate. Unfortunately, the software that runs on the host or CPU expects to operate with a UART with serialization and the resultant data pacing. If data is allowed to flow through the UART without any type of pacing, the performance of the host computer can be adversely affected.

[0010] These performance problems can be understood by investigating in greater detail the operation of the host computer. Typically, the host computer includes software for communication over the modem. This software includes a special piece of code that is responsible buffering data and moving it in and out of the modem via the UART. One example of this type of code is an interrupt service routine (ISR.) In this case, the PC's CPU might be running a variety of tasks, when an interrupt signal is received by the modem. This interrupt indicates that a certain number of bytes of data have been received over the serial interface and stored in the UART. In response to this interrupt, the CPU suspends its main tasks and starts the ISR code. The ISR code reads bytes from the UART until it is empty and then the CPU goes back to its main tasks. The ISR routine itself is relatively simple and short, but the CPU uses many extra instructions and time suspending and restarting its main task. This extra time is referred to as interrupt overhead.

[0011] In the case of a UART interface without serialization, it is possible that the DSP on the modem might be sending data to the DSP side of the UART as fast and the Host CPU can read them out. Despite the fact that the modem can only receive data from the telephone line at a limited rate, a large amount of data could be transmitted from the DSP to the host for each interrupt. This is possible because the DSP typically implements a large buffer in its memory and the entire buffer could be emptied at once. While this data is being moved, other tasks (including interrupts from other devices) are blocked. If other tasks are block for too long, the performance of the host computer is severely impacted. For instance, the movement of the mouse cursor across the monitor screen is noticeably slowed when the modem interrupt monopolizes the CPU on the host computer.

[0012] Notwithstanding the foregoing, it is possible it to achieve a high data transfer rate on an internal modem because there is no need to serialize the data. It is possible to increase the data transfer rate between a modem and a host computer by techniques not employing a UART, such as direct memory access or high speed serial connections. These approaches can increase data throughput and reduce the interrupt overhead. These approaches also require that compatibility to existing software be sacrificed.

[0013] Thus, there exists a need for a system and method of transferring data between a host computer and a modem that has an increased data transfer rate without seriously impairing (and perhaps improving) the performance of the host computer while remaining compatible with existing software.

[0014] The present invention increases data transfer rate and reduces interrupt latency while avoiding a concomitant increase in interrupts to the host by pacing the data flow between the UART and DSP using burst modes and wait modes. In order to pace the data transfer rate between the UART and DSP, a UART-to-DSP Interface (hereinafter “UDIF”) controls the flow of data between the UART and the DSP by alternatively bursting and halting data transfers.

[0015] During the burst mode, data is transferred across the interface at the maximum speed of the DSP (a “burst”) until the number of characters transferred reaches a predetermined burst count. During the wait mode, data transfer is suspended for the duration of a wait count. Data pacing control for the receive operation and for the transfer operation is independent.

[0016] The UDIF has at least one transmit channel and one receive channel and a plurality of registers for the implementation of the parallel to parallel UART to DSP mode. The registers contain information defining the number of character transfers of the burst mode and the duration of the wait mode.

[0017] These registers may be loaded by the DSP. Optimal wait and burst times for efficient data pacing may be selected. For example, a typical data rate used on modems such as 115.2 kilobits per second can be achieved by programming the registers. Optionally, the registers can be reprogrammed to double or quadruple that data rate without significant impact to the performance or the cost of the computer.

[0018] The present invention can be further understood by reference to the following description and attached drawings that illustrate the preferred embodiment.

[0019] FIG. 1 is a block diagram illustrating a system incorporating the present invention.

[0020] FIG. 2A illustrates a UDIF in the system of FIG. 1 in accordance with one embodiment.

[0021] FIG. 2B illustrates a UDIF in the system of FIG. 1 in accordance with another embodiment.

[0022] FIG. 3 is a functional diagram illustrating the operation of a transmit channel of the present invention.

[0023] FIG. 4 is a functional diagram illustrating the operation of a receive channel of the present invention.

[0024] In the following description of the invention, reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration specific examples whereby the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the invention.

[0025] The present invention seeks to overcome the limitations in a UART operating in a parallel-to-parallel mode with a DSP, by utilizing data pacing to increase the data transfer rate and reduce interrupt latency at the host without increasing the frequency of interrupts to the host. The data pacing features of the invention guaranty periods of inactivity in which the host can perform other tasks.

[0026] The present invention uses a data pacing protocol in the UDIF, the interface between the DSP and the UART. The data pacing protocol of the invention employs “burst” and “wait” modes on the DSP side of the UDIF to control when data is transferred.

[0027] In data “burst” mode, data is moved across the UDIF interface into UART buffers as fast as possible either in a transmit channel or a receive channel. In the transmit channel the data is moved from UART buffers to UDIF buffers, while in the receive channel data moves from the UDIF to the UART. The burst mode in either channel continues until the number of characters transferred across the interface reaches a predetermined character count. In “wait” mode, data movement between the UDIF buffers and the UART buffers is suspended for a predetermined duration. Consequently, no new interrupts are asserted to the host. This allows a period of time when the host is able to service other interrupts that are not associated with the modem.

[0028] A system programmer may exploit the versatility of the invention. A desired data transfer rate, for instance a rate commonly used on a serial UART connection, can be achieved by adjusting the amount of data sent in burst mode (i.e., the burst mode's character count) and the corresponding duration of the wait mode. The data transfer rate can be improved by increasing the data sent in each burst and keeping the wait period constant. This has marginal impact on the host computer since there is optimally only one interrupt for each burst period. By affording this data pacing versatility, the system can be streamlined to provide efficient throughput with guaranteed periods of inactivity while asserting a minimal number of interrupts to the host, thus allowing the host computer to service other system devices without being unduly burdened by the modem.

[0029] Structural Overview

[0030] FIG. 1 shows a block diagram illustrating a system incorporating the present invention. The system includes a host computer 100 connected to a modem 110 by means of connection well known in the art, including by way of example and not by way of limitation, ISA, EISA, PCI, AGP, SCSI and PCMCIA. The modem 110 is connected by conventional means, such as through an RJ-11 jack 130 and a telephone cable, to a typical telephone jack 140. The telephone jack 140 is connected to a network 150, a part of which is connected to a remote computer 160, thus allowing for communication between the host computer 100 and the remote computer 160.

[0031] Modem

[0032] The modem 110 includes a host interface 112 which communicates directly with the host computer 100. The host interface 112 is connected to a UART 114 for the receipt of data from, and transfer of data to, the host computer 100. The UART 114, which will be described in greater detail below, is connected to the UDIF 116, and serves as the interface between the UART 114 and the DSP 118. The DSP 118 receives and transmits signals from/to a digital/analog converter (“DAC”) 120, which in turn receives and transmits signals from/to the RJ-11 connection 130.

[0033] UART and UDIF

[0034] Referring to FIG. 2A, in a preferred embodiment, the receive channel includes a DSP bus 200, connected to a UDIF receive buffer 202 (hereinafter “UDIF Rx Buffer”), the UDIF Rx Buffer 202 being connected to a UART Receive buffer 204 (hereinafter “UART Rx Buffer”), which is in turn connected to a UART parallel interface 206. The transmit channel includes the UART parallel interface 206, connected to a UART Transmit buffer 208 (hereinafter “UART Tx Buffer”), which is connected to a UDIF Transmit buffer 210 (hereinafter “UDIF Tx Buffer”), which is in turn linked to the DSP bus 200.

[0035] A Receive Transfer Controller 220 (hereinafter “Rx Transfer Controller”) outputs a read signal 222 to the UDIF Rx Buffer 202, and a write signal 224 to the UART Rx Buffer 204. The Rx Transfer Controller 220 paces the receive data in accordance with the contents of three registers, namely a Receive Character Pacing Count Register 226 (hereinafter “Rx Character Pacing Count Register”), a Receive Pacing Burst Count Register 228 (hereinafter “Rx Pacing Burst Count Register”), and a Receive Pacing Wait Count Register 230 (hereinafter “Rx Pacing Wait Count Register”). These registers are preferably loaded by the DSP 118 via the DSP bus 200.

[0036] A Transmit Transfer Controller 240 (hereinafter “Tx Transfer Controller”) outputs a read signal 242 to the UART Tx Buffer 208, and a write signal 244 to the UDIF Tx Buffer 210. The Controller 240 paces the transmit data in accordance with the contents of three registers, namely a Transmit Character Pacing Count Register 246 (hereinafter “Tx Character Pacing Count Register”), a Transmit Pacing Burst Count Register 248 (hereinafter “Tx Pacing Burst Count Register”), and a Transmit Pacing Wait Count Register 250 (hereinafter “Tx Pacing Wait Count Register”). These registers are preferably loaded by the DSP 118 via the DSP bus 200.

[0037] It should be noted that the various buffers 202, 204, 208 and 210 are buffers well known in the art. The memory and word size of these buffers depend upon design considerations, and the input/output queuing format may be of a type well known in the art such as FIFO, FILO, LIFO or LILO.

[0038] In a preferred embodiment, the Rx Character Pacing Count Register 226 and the Tx Character Pacing Count Register 246 contain the same value, the Rx Pacing Burst Count Register 228 and the Tx Pacing Burst Count Register 248 contain the same value, and the Rx Pacing Wait Count Register 230 and the Tx Pacing Wait Count Register 250 contain the same value. Thus the three registers 226, 228 and 230 associated with the Rx Transfer Controller 220 and the three registers 246, 248 and 250 associated with the Tx Transfer Controller 240 can be structurally implemented as a single set of registers, namely a Character Pacing Count Register 270, a Pacing Burst Count Register 272 and a Pacing Wait Count Register 274, as shown in FIG. 2B.

[0039] Referring again to FIG. 2A, the Pacing Wait Count Registers 230, 250 store data which sets the wait count for pacing in the receive and transmit channels, respectively. This count determines the number of character times that the UDIF and/or UART will wait during wait mode. One character time is the time required to transmit a single character of data. During wait mode, the character count is the number of elapsed character times.

[0040] The Pacing Burst Count Registers, 228, 248 store data which sets the burst count in both the receive and transmit operations. This count is the number of characters transferred during one burst mode from the UART to UDIF or vice versa.

[0041] The duration in DSP clock counts of one character time is stored in each character pacing count register 226, 246. This information permits each controller 220, 240 to count character times during wait mode using the DSP clock. Thus, for example, the duration in DSP clock cycles of the wait mode in the receive channel is the product of the contents of the registers 226 and 230.

[0042] Functional Overview

[0043] 1. Transmit Channel

[0044] FIG. 3 shows a process implemented by the Tx Transfer Controller 240 for the implementation of data pacing in the transmit channel. The design of the Tx Transfer Controller 240 is achieved using conventional logic design techniques well known in the art, so as to enable the controller to carry out the process of FIG. 3.

[0045] The parallel interface 206 receives data from the host computer via the host bus 252. In Block 300 of FIG. 3, the Tx Transfer Controller 240 determines if there is data available in the UART Tx Buffer 208. If there is no data available, the Tx Transfer Controller 240 continues to wait for data (NO branch of Block 300). If there is data available (YES branch of Block 300), the transmit channel of the UDIF enters burst mode.

[0046] In burst mode, the Tx Transfer Controller 240 enables interrupts to the host by disabling the Tx Interrupt Inhibit signal 254, asserts a read signal 242 to the UART Tx Buffer 208 and a write signal 244 to the UDIF Tx Buffer 210, and begins a character count (Block 302) by counting the number of data characters actually transferred across the interface. The UDIF Tx Buffer 210 is written with data read from the UART Tx Buffer 208, while the Tx Transfer Controller 240 keeps track of the total number of characters transferred across the interface in burst mode, in units of character counts (Block 302).

[0047] In Block 304, the Tx Transfer Controller 240 senses when the total number of characters transferred reaches the value stored in the pacing burst count register 248. If the character count has not yet reached this value (NO branch of Block 304), the UDIF continues data transfer from the UART Tx Buffer 208 to the UDIF Tx Buffer 210 (Block 302).

[0048] Following the NO branch of Block 304, in Block 306 the Tx Transfer Controller 240 determines whether there have been N interrupts asserted to the host requesting additional data. In a preferred embodiment, N=1. An interrupt is asserted whenever the UART Tx buffer 208 becomes empty. If N interrupts have been asserted (YES branch of Block 306), the Tx Transfer Controller 240 inhibits further interrupts to the host by enabling the Tx Interrupt Inhibit signal 254 (Block 308). Otherwise (NO branch of Block 306), interrupts are not inhibited.

[0049] The UART Tx buffer 208 is of the conventional type which has associated with it an external register 208acontaining a status field which indicates whether the buffer 208 is empty. The external register 208ais accessed by the host via the host bus 252. Typically, the host computer is programmed in the conventional manner to monitor the status field of the register 208aand to re-fill the buffer 208 whenever the status field indicates the buffer is empty. As a result, the host refills the buffer 208 many times for each assertion of the interrupt to the host. In the preferred embodiment, N=1, so that there is a single interrupt the first time the buffer 208 is emptied during one burst mode, but the host refills the buffer 208 many times thereafter during that same burst mode. This behavior by the host, stimulated by the data pacing of the invention, enhances the data transfer rate, a significant advantage.

[0050] Once the character count finally reaches the value stored in the pacing burst count register 248 (YES branch of 304), the Tx Transfer Controller 240 enters wait mode (Block 310). In wait mode the controller 240 refrains from asserting the UART Tx Buffer read signal 242 and the UDIF Tx Buffer write signal 244. Also, at this point, the controller 240 begins a new character count based upon elapsed time (in DSP clock cycles) rather than the number of characters transferred (as no data is transferred across the interface during wait mode).

[0051] While in wait mode, with each new count the Tx Transfer Controller 240 determines once each character time if the character count is equal to the value stored in the pacing wait count register 250 (Block 312). If the character count is not equal to the pacing wait count (NO branch of Block 312), the controller 240 remains in wait mode (Block 310). If the character count is equal to the pacing wait count (YES branch of Block 312), the controller 240 returns to a step in which it checks the UART Tx Buffer 208 for available data (Block 300).

[0052] 2. Receive Channel

[0053] FIG. 4 shows a receive process implemented by the Rx Transfer Controller 220 of FIG. 2A for the implementation of data pacing in the receive channel. The design of the Rx Transfer Controller 220 is achieved using conventional logic design techniques well known in the art, so as to enable the controller to carry out the process of FIG. 4.

[0054] The DSP bus 200 receives data from the remote computer 160 and deposits this data in the UDIF Rx Buffer 202. In Block 400 of FIG. 4, the Rx Transfer Controller 220 determines whether there is data available in the UDIF Rx Buffer 202.

[0055] If there is no data available, the Rx Transfer Controller 220 continues to wait for data to become available (NO branch of Block 400). If data is available for transfer to the host in the UDIF Rx Buffer 202 (YES branch of Block 400), the Rx Transfer Controller 220 determines if the UART Rx Buffer 204 is full (Block 402).

[0056] If the UART Rx Buffer 204 is full or, alternatively, partially full (YES branch of Block 402), the Rx Transfer Controller 220 sends an interrupt to the host to service this buffer (Block 404). After the interrupt is asserted, the Rx Transfer Controller 220 again determines if the UART Rx Buffer 204 is full. This single interrupt is held until the host responds by beginning to empty the UART Rx buffer 204.

[0057] Once the host responds to the interrupt and begins emptying the UART Rx Buffer 204, the UART Rx Buffer 204 is no longer full (NO branch of block 402), and the Rx Transfer Controller 220 goes into burst mode (Block 406). In burst mode, the Rx Transfer Controller 220 enables a read signal 222 in the UDIF Rx Buffer 202 and a write signal 224 to the UART Rx Buffer 204, and begins a character count of the number of data characters actually transferred across the interface. Data is read from the UDIF Rx Buffer 202 and written to the UART Rx Buffer 204.

[0058] During burst mode, the host will empty the UART Rx buffer 204 many times. The UART Rx buffer 204 is of the conventional type which has associated with it an external register 204acontaining a status field which indicates whether the buffer 204 contains data. This external register is accessed by the host via the host bus 252. Typically, the host computer is conventionally programmed to monitor the status field of the register 204aand to empty the buffer 204 whenever the status field indicates the buffer contains data. As a result, the host empties the buffer 204 many times following the single assertion of the interrupt to the host at the beginning of burst mode. This behavior by host, stimulated by the data pacing of the invention, enhances the data transfer rate, a significant advantage.

[0059] While in burst mode, the Rx Transfer Controller 220 counts the number of characters actually transferred across the interface, and compares this character count with the value stored in the pacing burst count register 228 (Block 408). If the character count is not equal to the pacing burst count (NO branch of Block 408), the Rx Transfer Controller 220 remains in burst mode. When the character count is equal to the pacing burst count (YES branch of Block 408), the Rx Transfer Controller 220 enters wait mode (Block 410).

[0060] In wait mode, the Rx Transfer Controller 220 refrains from asserting the read signal 222 to the UDIF Rx Buffer 202 and the write signal to the UART Rx Buffer 204, and begins a new character count based upon elapsed time (in DSP clock cycles) rather than the number of characters transferred, since no data is transferred during wait mode. While in wait mode, the Rx Transfer Controller 220 determines once each character count that whether the latest character count is equal to the value stored in the pacing wait count register 230 (Block 412). If the character count is not equal to the pacing wait count (NO branch of Block 412), the Rx Transfer Controller 220 remains in wait mode. When the character count is equal to the pacing wait count (YES branch of Block 412), the Rx Transfer Controller 220 returns to Block 400 to determine if there is data available in the UDIF Rx Buffer 202.

[0061] While the invention has been described in detail with reference to its implementation in a modem, the data pacing protocol of the invention is useful for realizing the above-described advantages in any other similar digital communication device having, for example, a UART interface.

[0062] While the invention has been described in detail by specific reference to preferred embodiments, it is understood that variations and modification thereof may be made without departing from the true spirit and scope of the invention.