System and method for reducing power consumption when transmitting data to a device

Abstract

A system, apparatus, and method are provided for moving data from memory to an I / O device in a computing system. The system includes a processor, memory, an I / O controller, and a power management circuit. An application stores data in memory that will eventually be transmitted to the I / O device. The I / O controller is configured to transmit the data to the I / O device according to a service interval. The I / O controller is configured to fetch a first data item from memory where it was stored by the application and prefetch one or more additional data items from the memory. The first data and the prefetched data are stored in a locally accessible buffer of the I / O controller. The I / O controller is then configured to transmit the first data and each of the one or more data items from the buffer to the I / O device at regular time intervals during a predetermined period before commencing fetching the additional data from the memory. During the predetermined period, the power management circuit is configured to cause at least the memory to enter a reduced power state.

Description

[Background technology]

[0001] Description of Related Art Many design factors must be considered during the design of a computer or other processor-based system. A successful design may require various trade-offs between power consumption, performance, heat output, etc. For example, a computer system design that emphasizes high performance may tolerate greater power consumption and heat output. Conversely, a portable computer system design, which may be battery-powered, may emphasize reduced power consumption, even at the expense of some performance. Whatever the specific design goals, a computing system typically has a predetermined amount of power available during operation. Managing power consumption in modern computing systems is becoming increasingly important, and designers are constantly seeking ways to make improvements.

[0002] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram of one embodiment of a computing system. [Figure 2] FIG. 1 is a block diagram of one embodiment of a computing system. [Figure 3] FIG. 1 illustrates data movement from memory to an I / O device. [Figure 4] FIG. 1 illustrates data movement from memory to an I / O device. [Figure 5] FIG. 1 illustrates the activity of computing system components during the movement of data from memory to an I / O device. DETAILED DESCRIPTION OF THE INVENTION

[0004] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, those skilled in the art should recognize that various embodiments may be practiced without these specific details. In some instances, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail to avoid obscuring the approaches described herein. It will be understood that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements.

[0005] Various systems, apparatuses, and methods are disclosed for moving data from memory devices to I / O devices in a computing system. In various embodiments, the timing of data movement from memory to an I / O interface is altered to allow for increased idle time of one or more components of the computing system. Increasing the idle time increases the chances that the component will enter a reduced power state in which it would otherwise consume less power. In one embodiment, a system includes a processor configured to service interrupts generated by an interrupt source. The interrupt source is configured to generate the interrupt to move data retrieved from memory to an input / output (I / O) device. To increase the amount of time the processor and / or memory are idle, the interrupt source is configured to alter the timing of interrupts that cause the retrieval of data from memory and to buffer the retrieved data before transmission to the I / O device. Additionally, a buffer is used to prefetch data from memory in a manner that increases the amount of time the memory subsystem is idle. Further details will be understood with reference to the following description.

[0006] 1, a block diagram of one embodiment of computing system 100 is shown. In one embodiment, computing system 100 includes at least processors 105A-105N, input / output (I / O) interface 120, a bus or data fabric 125 configured to enable movement of data between components within the system, memory controller 130, network interface 135, memory device 140, display controller 150, and display 155. In other embodiments, computing system 100 includes other components and / or is arranged differently. Processors 105A-105N represent any number of processors included in system 100. In various embodiments, multiple components shown (and / or different components) are integrated into a single chip, commonly referred to as a system on a chip (SoC).

[0007] In one embodiment, processor 105A is a general-purpose processor such as a central processing unit (CPU). In this embodiment, processor 105A executes drivers 110 (e.g., graphics drivers) for communicating with and / or controlling the operation of one or more of the other processors in system 100. Note that, depending on the embodiment, drivers 110 may be implemented using any suitable combination of hardware, software, and / or firmware. In one embodiment, processor 105N is a data-parallel processor with a highly parallel architecture, such as a chiplet graphics processing unit (GPU), that processes data, performs parallel processing of workloads, renders pixels for display controller 150 to drive display 155, and / or performs other workloads. In various embodiments, as used herein, the term “chiplet” refers to any device that includes, but is not limited to, the following characteristics: 1) Chiplets contain active silicon dies that contain portions of the computational logic used to solve a complete problem (i.e., the computational workload is distributed across multiple of these active silicon dies), 2) chiplets are packaged together as an integrated unit on the same substrate, and 3) the programming model does not violate the notion that these individual computational dies are a single integrated unit (i.e., each chiplet does not appear as a separate device to applications that use the chiplet to process computational workloads). Chiplet GPUs are complex integrated circuits that perform graphics processing tasks across multiple semiconductor dies. For example, GPUs perform graphics processing tasks required by end-user applications such as video game applications. GPUs are also increasingly being used to perform other tasks that are not related to graphics.Other data parallel processors that may be included in system 100 include digital signal processors (DSPs), field programmable gate arrays (FPGAs), and application specific integrated circuits (ASICs), etc. In some embodiments, processors 105A-105N include multiple data parallel processors.

[0008] Memory controller 130 represents any number and type of memory controller accessible by processors 105A-105N. While memory controller 130 is shown as separate from processors 105A-105N, it should be understood that this represents only one contemplated embodiment. In other embodiments, memory controller 130 may be incorporated into one or more of processors 105A-105N and / or memory controller 130 may be located on the same semiconductor die as one or more of processors 105A-105N. Memory controller(s) 130 couple to any number and type of memory device(s) 140. Memory device(s) 140 represent any number and type of memory devices. For example, types of memory in memory device 140 may include Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), NAND flash memory, NOR flash memory, Ferroelectric Random Access Memory (FeRAM), etc. Memory device 140 stores program instructions 145, which may include a first set of program instructions for a meta app, a second set of program instructions for a driver component, etc. Alternatively, program instructions 145 may be stored in memory or a cache device local to processor 105A and / or processor 105N.

[0009] I / O interface 120 represents any number and type of I / O interface (e.g., a peripheral component interconnect (PCI) bus, a PCI-Extended (PCI-X), a PCI Express (PCI Express) bus, a gigabit Ethernet (GBE) bus, or a universal serial bus (USB). Various types of peripheral devices (not shown) may be coupled to I / O interface 120. Such peripheral devices include, but are not limited to, a display, a keyboard, a mouse, a printer, a scanner, a joystick, other types of game controllers, headphones, a microphone, a media recording device, an external storage device, and the like. Network interface 135 may receive and transmit network messages over a network via either a wired and / or wireless connection.

[0010] In various embodiments, computing system 100 is a computer, a laptop, a mobile device, a game console, a server, a streaming device, a wearable device, or any of a variety of other types of computing systems or devices. It should be noted that the number of components of computing system 100 may vary from embodiment to embodiment. For example, in other embodiments, more or fewer components may be present than those shown in FIG. 1 . It should also be noted that in other embodiments, computing system 100 includes other components not shown in FIG. 1 . Additionally, in other embodiments, computing system 100 is structured in other ways than those shown in FIG. 1 .

[0011] Referring now to FIG. 2 , a block diagram illustrating a processing system 200 according to various embodiments is shown. In the illustrated example, system 200 includes a central processing unit (CPU) 205 for executing instructions. In various embodiments, CPU 205 is connected to system memory 230 via data fabric 240, which may be implemented using dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile RAM, etc. In one embodiment, system memory 230 includes buffers / data structures 235 (buffers) for storing data to be communicated to I / O devices 250. In various embodiments, the data and / or data structures in buffer 235 are generated by application 210. Any of various types of buffers may be used, such as a ring buffer, a ping-pong buffer, a double buffer, etc. As used herein, a “ring buffer” is a circular queue that does not itself have a head or tail, but instead uses pointers to keep track of the head and tail of the data stored in the buffer. A “ping-pong” buffer is a buffer that includes two parts. While a first portion of a ping-pong buffer is being filled, a second portion of the buffer may be read. The filling of the buffer and reading from the buffer may then switch such that the second portion is being filled while the first portion is being read. A "double buffer" is similar to a ping-pong buffer in that it contains two portions. However, in contrast to a ping-pong buffer, a double buffer always fills one portion and always reads from the other portion. Many such embodiments are possible and contemplated.

[0012] As shown, CPU 205 includes processes corresponding to one or more applications 210, an operating system 215, and user mode drivers 220 (or other drivers, such as kernel mode drivers). In various embodiments, one or more applications 210 include applications configured to cause the transmission of data to I / O devices 250. For example, in some embodiments, application 210 is associated with a game, a music playback application, video / audio conferencing, etc. In such embodiments, audio associated with the application is transmitted to I / O devices 250, which may include headphones, speakers, etc. In various embodiments, I / O device 250 is a USB device and I / O interface 252 is a USB host controller. The I / O interface includes a first interface 262 configured to retrieve data from memory 230 and a second interface 264 configured to transmit data to I / O devices 250. In some embodiments, application 210 is configured to cause the transmission of video / image data to the device via interface 252. In such cases, the device may be or include a display device, and interface 250 may be configured to support other, different communication protocols.

[0013] Additionally, in some embodiments, application 210 is configured to instruct I / O interface 252 how often to move data from memory to I / O device 250. In various embodiments, the I / O device is a Universal Serial Bus (USB) device, and I / O interface 252 is a USB host controller (e.g., an Extensible Host Controller Interface). In such embodiments, this data is moved from system memory 230 to USB device 250 via USB controller 252. This is often referred to as USB data reclamation. Whether in the USB context or not, in some embodiments, software 210 instructs I / O interface 252 how much data to move and how often to push data to the device (e.g., 100 B every 125 us). This data push rate may be determined by the device type. Many devices do not implement large buffering capabilities and may need to receive data frequently and as quickly as possible. This creates a situation where the data push rate results in an interrupt rate to the system memory that does not allow the system memory or processor (or other component) to enter the extended idle times and reduced power states that it would otherwise enter.

[0014] In some embodiments, application 210 utilizes an application programming interface (API) to invoke user mode driver 220. User mode driver 220 issues one or more commands to communicate with I / O interface 252. Based on instructions issued by application 210 to user mode driver 220, user mode driver 220 generates one or more commands specifying one or more operations for I / O interface 252 to perform. In some embodiments, user mode driver 220 is part of application 210 running on CPU 205. For example, user mode driver 220 may be part of a gaming application running on CPU 205. Similarly, a kernel mode driver (not shown) may be part of an operating system running on CPU 205.

[0015] Further to the above, CPU 205 is shown to include interrupt handler 260. In one embodiment, upon receiving an interrupt from within or coupled to the system (e.g., I / O interface 252), interrupt handler 260 forwards the interrupt to control software executing on CPU 205. In one embodiment, interrupt handler 260 generates data to forward along with the generated interrupt data. The data may include information such as an identifier (ID) of the entity that generated the interrupt and / or other data. Upon receiving an interrupt, CPU 205 responds by taking action required or otherwise indicated by the interrupt. For example, in various embodiments, application 210 is configured to generate an interrupt to cause data to be stored in memory 230, and I / O interface 252 is configured to generate an interrupt to cause data to be retrieved from memory 230 (e.g., if additional data from memory is needed).

[0016] As an example, application 210 may periodically (or aperiodically) generate an interrupt to store data in memory 230. For example, during a video conference, audio associated with the conference may be received and stored in buffer 235 in memory. I / O interface 252 is configured to retrieve data from buffer 235 and communicate it to I / O device 250. As shown in FIG. 2 , I / O interface 252 includes control circuitry 253 configured to control various functions, including at least initiating and managing the reception / retrieval of data, communicating the data to I / O device 250, and storing the data in buffer 255. While streaming audio data to I / O device 250, the data needed to continue the audio stream may not be available to I / O interface 252. In such cases, additional data must be retrieved from memory 230 to continue the audio stream without interruption. By generating an interrupt, I / O device 252 causes CPU 205 to initiate the process of moving data from memory 230 to I / O interface 252. To service an interrupt, CPU 205 must be awake. In other words, if CPU 205 is in a reduced power state in which it cannot service an interrupt, it must exit the reduced power state before it can service the interrupt. Consequently, servicing an interrupt has the side effect of requiring CPU 205 to consume more power than if it remained in the lower power state.

[0017] In alternative embodiments, I / O interface 252 may use direct memory access (DMA) to retrieve data from memory 230. In such embodiments, no interrupts are generated and the processor does not need to effect the movement of data from memory. Consequently, if the processor is in a reduced power state when the data is needed, the processor must exit the reduced state. However, memory 230 and the path between memory 230 and I / O interface 252 (e.g., fabric 240) must be awakened to allow the movement of data when in a reduced power state. Consequently, these components cannot be in a reduced power state while the data is being moved, regardless of whether an interrupt or DMA is used to move the data. Methods and mechanisms for enabling reduced power consumption while servicing interrupts are described in more detail below.

[0018] Also shown in FIG. 2 is power management circuitry 225. As discussed above, various components (e.g., CPU 205, fabric 240, memory 230, etc.) can enter reduced power states to conserve power. In various embodiments, power management circuitry 225 is configured to monitor the activity of components within system 200 and cause one or more components to enter and / or exit various power performance states. As an example, if CPU 205 is detected to be idle or otherwise having a reduced activity level, power management circuitry 225 may cause CPU 205 to enter a reduced power performance state such that CPU 205 consumes less power. Similarly, fabric 240 and memory 230 may be placed in reduced power states depending on the state of the system and various conditions. A variety of such mechanisms are known in the art and are contemplated.

[0019] Referring now to Figure 3, one embodiment of a system for moving data to an I / O device is shown. Figure 3 shows a timeline progressing from left to right. A legend in the lower right corner of the figure distinguishes between interrupts and data movement. The bottom half of the figure (302) shows the generation of an interrupt and the movement of data from memory to a host controller. The top half of the figure (300) shows the movement of data from the host controller to an I / O device.

[0020] As shown in the figure, interrupts (e.g., 310A-310B) are generated by software (e.g., application 210) or hardware (in the case of DMA-based embodiments) that cause data to be produced and stored in memory (e.g., buffer 235 in memory 230). In various embodiments, these interrupts (310) are generated at a rate determined by various factors. Such factors may include various data rates associated with generating or receiving data, buffer sizes in memory (e.g., 235) and elsewhere in the system, memory access latency, I / O device requirements, etc. As noted above, in certain embodiments, software instructs the I / O interface regarding the amount and frequency of data to be communicated to the device. For example, the software may access the I / O interface and write to one or more configuration registers to program the device with such information. Alternatively, the I / O interface may be programmed to access a location in memory that stores such information. Various such embodiments and combinations of such embodiments are possible and contemplated.

[0021] As shown in the example of FIG. 3, software-generated interrupts 310A-310B are shown to occur at a predetermined frequency 330. In various embodiments, the interrupt frequency 330 generally corresponds to the requirements associated with the application and I / O device. For example, in a scenario where audio data is being communicated to a USB device, the data transfers are isochronous in that they occur at a regular frequency 350, which may be referred to as a service interval. This may be required to meet certain quality of service (QoS) requirements. In other embodiments, the data transfers are not isochronous, and certain QoS requirements do not need to be met for a given scenario. As shown in FIG. 3, interrupt 310A occurs at a first time, followed by four data transfers from memory to the I / O interface, after which the next interrupt 310B occurs (shown along the bottom half of the diagram 302). As shown, after each transfer of data from memory to the I / O interface, the data is moved from the I / O interface to the I / O device (shown along the top half 300 of the diagram). Note that at startup, interrupt 310A may not be present. Rather, the corresponding application (e.g., application 210) may already have data stored in memory for retrieval by the I / O interface. In such a case, the first interrupt generated may be interrupt 310B when the I / O interface determines that additional data is needed. Figures 3 and 4 assume that this is not a start-up scenario, and that interrupt 310A (and 440A) is generated to retrieve the additional data.

[0022] In the embodiment shown in FIG. 3, when the I / O interface receives (or retrieves) data following interrupt 310, the data includes metadata indicating that additional data is available in memory. For example, when software stores data in memory, metadata associated with the data (e.g., in the form of a descriptor or other form) indicates one or more of: an identification of how much additional data is stored in memory; an identification of the location of the additional stored data (e.g., a pointer to or address of the next data item in the sequence); an indication of the order in which the data stored in memory will be communicated to the I / O device; and the rate at which the data will be communicated to the I / O device. Other information is possible and contemplated. In this example, following receipt or retrieval of data by the I / O interface (e.g., the first data transfer after interrupt 310A), the interface is notified by metadata received with the data regarding the additional data. Based on this additional information, the I / O interface receives / retrieves data from memory three more times before the next interrupt 310B occurs. For example, the additional accesses to memory are performed in the time necessary to satisfy the current requirements of the I / O device. Note that while reference is made to four data transfers between interrupts, this is for illustrative purposes only and the number of transfers can be any of a variety of numbers of transfers as appropriate for a given context or scenario.

[0023] The embodiment of FIG. 3 provides a consistent data stream to the I / O device, but includes multiple memory accesses spaced (in time) apart in such a way as to fix the maximum time that the memory and paths to the I / O device can potentially be idle 320. In the illustrated example, this predetermined period (potential idle time) 320 corresponds roughly to the service interval 350. If an interrupt-based mechanism is used, the processor handling the interrupt is also limited by this maximum time. In other words, because the paths and memory (and potentially the processor) must be awake to provide data, they can be idle for, at most, the time indicated by the potential idle time 320. As discussed above, increasing the idle time can be used to reduce power consumption. As shown, when the idle time is capped, the potential power consumption savings are likewise capped. With this in mind, alternative embodiments are described below.

[0024] FIG. 4 illustrates an embodiment in which potential idle time and power consumption savings are increased. Similar to FIG. 3, FIG. 4 illustrates data movement from memory to the I / O interface in the bottom half (402) of the diagram and data movement from the I / O interface to the device in the top half (400) of the diagram. In various embodiments, the I / O interface includes a buffer configured to store data received from memory. The size of the buffer is such that it can store a sufficient amount of data to avoid the need to retrieve additional data from memory for at least a predetermined period of time. In effect, the buffer functions as a prefetch buffer, storing data prefetched from memory ahead of the time the data is actually needed by the I / O device.

[0025] As shown in this example, interrupt 440A, which generally corresponds to interrupt 310A of FIG. 3, occurs at a predetermined rate 430. In various embodiments, this interrupt rate 430 is unchanged from that of interrupt rate 330 (as shown in FIG. 3). In other embodiments, it differs from the embodiment of FIG. 3. Interrupt 440A is configured to store data in memory. For example, as described above, interrupt 440A may be generated by software configured to store data in memory that is intended for eventual transmission to an I / O device. After the data is stored in memory, the I / O interface is configured to cause the movement of data from memory to the I / O interface and ultimately to the I / O device according to service interval 450. However, in contrast to the embodiment of FIG. 3, instead of the I / O interface causing the movement of data from memory to the I / O interface at the intervals shown in FIG. 3 (e.g., four separate data movements from memory to the I / O device following interrupt 310A), multiple movements of data are effectively coalesced.

[0026] For example, as shown in FIG. 4, data movement from memory to the I / O interface is coalesced (410) so that the movement occurs within a compressed time period compared to that of FIG. 3. In particular, after retrieval of a first item of data (shown as the first item of coalesced data 410), additional data items (e.g., the remaining three data items of data 410) are prefetched from memory. In some embodiments, each data item fetched from memory indicates the location of the next data item to be fetched. As explained above, in the embodiment of FIG. 4, the I / O interface includes a buffer of sufficient size to store the coalesced data. In various embodiments, the movement of data from memory to the I / O interface can be interrupt-driven, DMA-based, or via any other suitable mechanism or protocol. Similar to the movement of data from memory to the I / O interface in FIG. 3, the memory and the path between the memory and the I / O interface must be awake in order for data to be retrieved from memory and moved to the I / O interface. When moving data using an interrupt-driven mechanism, the processor similarly needs to be awake to service the interrupt. However, in contrast to FIG. 3, the movement of data from memory in FIG. 4 is compressed to a shorter period and accumulated in a buffer. Consequently, the period during which the memory and path (and potentially the processor) must be awake corresponds to the shorter period reflected by coalesced data 410. This increases the period during which the memory, path, and / or processor may be idle, as indicated by potential idle time 420. This potential idle time is longer than that described with respect to FIG. 3 (i.e., potential idle time 320). Additionally, while service interval 450 remains generally unchanged compared to service interval 350 in FIG. 3, potential idle time 420 does not correspond to service interval 450, as in FIG. 3. Consequently, each of the memory, path, and / or processor may idle for a longer period and enter a reduced power state, such that overall power consumption is potentially reduced.

[0027] Referring now to FIG. 5, a method for reducing power consumption and moving data to an I / O device is illustrated. As shown in this example, a method is shown corresponding to software application activity 510, memory / path / processor activity 520, and I / O controller activity 530. Generally speaking, the activities (510, 520, 530) occur simultaneously within a computing system. In a first block (510), a software application (e.g., 210) is configured to store data in memory for later transmission to an I / O device. As discussed above, the application may correspond to a video game, a videoconferencing application, or the like. As shown, the application generates an interrupt 511 when the data is stored in memory. The application then stores the data and associated metadata (e.g., a descriptor) in memory 512. If more data is to be stored in memory (514), an interrupt is generated (511) and the data is stored in memory.

[0028] Concurrent with the software activity, various system components (memory, data paths, processor) perform actions 520 associated with the movement of data to memory and I / O interfaces. As shown, if any of these components are in an idle state 522, they enter a low-power state 526 if they are not already in such a state. For example, in response to detecting an idle state of a component, power management circuit 225 may cause the corresponding component to enter a reduced power state. Otherwise, the component is active (524). At a predetermined point in time, a data movement is indicated (528). For example, the data movement is indicated by an application generating interrupt 511. If such an indication is detected, the processor exits low-power state 530 (if in such a state) and services interrupt 532. Otherwise, if no such movement of data is indicated (528), the method returns to block 522 and the process repeats.

[0029] Also concurrent with activities 510 and 520, the I / O controller performs activity 530 to support the movement of data to the I / O device. As shown in the example, after being programmed (e.g., by application 210) to service the I / O device, the I / O controller accesses memory to retrieve data stored by application 532. As described above, this access may be via interrupt, DMA, etc. If an interrupt is generated by the I / O interface, the processor, via detection of interrupt 528, services the interrupt as described in connection with activity 520. If the access is not interrupt generated (e.g., via DMA or otherwise), the processor does not need to service the request. However, components in the data path and memory must stay awake to service request 532 and, if necessary, exit low power state 530.

[0030] Following the access to memory 532, the I / O controller prefetches sufficient data from memory to service multiple transfers of data to the I / O device and stores the prefetched data in a buffer. In various embodiments, the buffer is local to the I / O interface, as shown in FIG. 2. In other embodiments, the buffer is coupled to the I / O interface in a manner such that accessing the buffer does not require traversing fabric 240 and / or does not otherwise require other system components to be awake (i.e., not in a reduced power state that would require them to terminate to service the access). After prefetching the data, the I / O controller communicates the data from the buffer to the I / O device at predetermined time intervals (538). In some embodiments, the time intervals are programmed by application 210. In other embodiments, the I / O device provides the I / O controller with initialization data indicating such intervals. Various such methods for determining such time intervals are known and contemplated.

[0031] In various embodiments, program instructions of a software application are used to implement the methods and / or mechanisms described herein. For example, program instructions executable by a general-purpose or special-purpose processor are contemplated. In various embodiments, such program instructions are expressed in a high-level programming language. In other embodiments, the program instructions are compiled from the high-level programming language into binary, intermediate, or other form. Alternatively, program instructions that describe the behavior or design of hardware are written. Such program instructions are expressed in a high-level programming language such as C. Alternatively, a hardware design language (HDL) such as Verilog is used. In various embodiments, the program instructions are stored on any of a variety of non-transitory computer-readable storage media. The storage medium is accessible by a computing system during use to provide the program instructions to the computing system for program execution. Generally speaking, such a computing system includes at least one or more memories and one or more processors configured to execute the program instructions.

[0032] It should be emphasized that the above-described embodiments are merely non-limiting examples of embodiments. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. 1. An apparatus comprising: a first interface configured to receive data from the memory; a second interface configured to communicate data to an input / output (I / O) device; a control unit; The control unit fetching a first data item from said memory; prefetching one or more data items from said memory; storing the first data item and the one or more data items in a buffer; communicating the first data and each of the one or more data items from the buffer via the second interface at time intervals during a predetermined period before commencing fetching of additional data items from the memory; configured to: Device.

2. the control unit is configured to both fetch the first data item and prefetch the one or more data items during a period shorter than any one of the time intervals.

10. The apparatus of claim 1.

3. each of the time intervals corresponds to a service interval; 10. The apparatus of claim 1.

4. the apparatus is a Universal Serial Bus (USB) controller, and the I / O device is a USB device; 4. The apparatus of claim 3.

5. the control unit is configured to fetch the first data item and the one or more data items from the memory using direct memory access; 10. The apparatus of claim 1.

6. the control unit is configured to fetch the first data item and the one or more data items from the memory using an interrupt-based mechanism.

10. The apparatus of claim 1.

7. the control unit is configured to generate an interrupt to fetch the first data item.

7. The apparatus of claim 6.

8. 1. A method comprising: an input / output (I / O) controller fetching a first data item from a memory via a first interface; the I / O controller prefetching one or more data items from the memory via the first interface; the I / O controller storing the first data item and the one or more data items in a buffer; the I / O controller communicating the first data item and each of the one or more data items from the buffer to an I / O device, said communicating occurring at time intervals during a predetermined period before fetching additional data items from the memory. method.

9. performing both fetching of the first data item and prefetching of the one or more data items during a period shorter than any one of the time intervals; 9. The method of claim 8.

10. each of the time intervals corresponds to a service interval; 9. The method of claim 8.

11. the I / O controller is a Universal Serial Bus (USB) controller, and the I / O device is a USB device; The method of claim 10.

12. fetching the first data item and the one or more data items from the memory using direct memory access.

9. The method of claim 8.

13. fetching the first data item and the one or more data items from the memory using an interrupt-based mechanism.

9. The method of claim 8.

14. the I / O controller is configured to generate an interrupt to fetch the first data item.

14. The method of claim 13.

15. 1. A system comprising: a processor; a power management circuit; an input / output (I / O) controller; The I / O controller Fetching a first data item from memory; prefetching one or more data items from said memory; storing the first data item and the one or more data items in a buffer; communicating the first data and each of the one or more data items from the buffer via the second interface at time intervals during a predetermined period before commencing fetching of additional data items from the memory; configured to: system.

16. the I / O controller is configured to both fetch the first data item and prefetch the one or more data items during a period shorter than any one of the time intervals; 16. The system of claim 15.

17. each of the time intervals corresponds to a service interval; 16. The system of claim 15.

18. the power management circuitry is configured to cause the memory to enter a reduced power state for the predetermined period of time.

16. The system of claim 15.

19. the I / O controller is configured to fetch the first data item and the one or more data items from the memory using direct memory access; 16. The system of claim 15.

20. the I / O controller is configured to generate an interrupt for servicing by the processor to fetch the first data item.

16. The system of claim 15.

Images