Scatter and gather streaming data through circular FIFO

Abstract

To provide a system, a device, and a method for performing scatter and gather direct memory access (DMA) streaming through a circular buffer.SOLUTION: In a system 300, after a producer DMA engine writes or skips over a given data chunk of a first frame to a buffer, the producer DMA engine sends, to a consumer DMA engine, an updated write pointer indicating that a data credit has been committed to the buffer and that the data credit is ready to be consumed. After the consumer DMA engine reads or skips over the given data chunk of the first frame from the buffer, the consumer DMA engine sends, to the producer DMA engine, an updated read pointer indicating that the data credit has been consumed and that space has been freed up in the buffer to be reused by the producer DMA engine.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The embodiments described herein relate to the field of computing systems, and more particularly to efficiently streaming data between multiple agents. [Background technology]

[0002] Direct memory access (DMA) is a feature of computer systems that allows hardware subsystems to access system memory independently of the main processor (e.g., the central processing unit (CPU)). The type of data transferred in a DMA access may vary from embodiment to embodiment. One common type of data transferred in computer systems is image data, although the techniques described herein are not limited to transferring image data. Transfers of other types of data may also benefit from the improved methods and mechanisms disclosed herein. However, for purposes of explanation, transfers of image data are used in many of the examples. These examples are merely illustrative and do not exclude the use of the described techniques with other types of data.

[0003] Computer systems (e.g., phones, tablets, laptops, desktops) often include or are connected to cameras or other image sensors for capturing image data, such as video or still images. Such image sensors may generate a stream of image data (commonly referred to as an "image data stream") that includes a series of individual pictures or frames. Each frame may include multiple lines of pixel data that specify the brightness and color of a given pixel. As used herein, the term "stream" is defined as a sequence of frames that may be subjected to any of various types and amounts of processing.

[0004] Before the image data stream is displayed on a monitor or other suitable display device, the data contained in the image data stream may be processed to adjust color values, rotate or scale images, etc. To facilitate such processing, the image data stream may be stored in memory so that a dedicated circuit block, such as a display processor, can operate on portions of particular frames of the image data stream. In some cases, the display processor may also store the processed image data stream back in memory for future use.

[0005] In some computer systems, a display processor, or other circuit block used to process image data, may wait until a complete frame of the image data stream is stored in memory before beginning to read the stored data and begin image processing operations. Waiting in such a manner may result in additional latency in the processing of the image data stream or inefficient use of memory. Summary of the Invention

[0006] Systems, apparatuses, and methods are contemplated for performing scatter and gather direct memory access (DMA) streaming through a circular first-in, first-out (FIFO) buffer. In one embodiment, the system includes a FIFO buffer, a producer DMA engine, and a consumer DMA engine. After the producer DMA engine writes a given data chunk of a data set (e.g., an image or video frame) to the buffer, the producer DMA engine sends an updated write pointer to the consumer DMA engine, indicating that data credits have been committed to the buffer and that the data credits are ready to be consumed. In some cases, multiple producer DMA engines are simultaneously transferring separate sections of the data set to the buffer. After the consumer DMA engine reads or skips a given data chunk of the data set from the buffer, the consumer DMA engine sends an updated read pointer to the producer DMA engine, indicating that data credits have been consumed and that space in the buffer has been freed up for reuse by the producer DMA engine. In some cases, multiple consumer DMA engines are simultaneously consuming different regions of the data set from the buffer.

[0007] These and other embodiments will be further understood with reference to the following description and drawings. [Brief explanation of the drawings]

[0008] The above and further advantages of the method and arrangement may be better understood by reference to the following description taken in conjunction with the accompanying drawings.

[0009] [Figure 1] FIG. 1 is a generalized block diagram of one embodiment of a SOC.

[0010] [Figure 2] FIG. 2 is a generalized block diagram illustrating one embodiment of a data manager.

[0011] [Figure 3] FIG. 1 is a block diagram of one embodiment of a remote companion DMA system.

[0012] [Figure 4] FIG. 1 is a block diagram of one embodiment of logical connectivity between producer router table entries and consumer router table entries.

[0013] [Figure 5] FIG. 10 is a block diagram of another embodiment of a remote companion DMA system.

[0014] [Figure 6] 1 is a table with route descriptor fields that may be used according to one embodiment.

[0015] [Figure 7] FIG. 1 illustrates an embodiment of a superframe produced by multiple producers and consumed by multiple consumers.

[0016] [Figure 8] FIG. 1 is a timing diagram for one embodiment of a companion DMA system.

[0017] [Figure 9] FIG. 1 is a timing diagram of one embodiment of the operation of a companion DMA system.

[0018] [Figure 10] FIG. 1 is a timing diagram of one embodiment of a companion DMA system having multiple producers and multiple consumers.

[0019] [Figure 11] FIG. 1 is a timing diagram of one embodiment of a companion DMA system having multiple producers and multiple consumers.

[0020] [Figure 12]FIG. 10 is a timing diagram of one embodiment of a multi-frame software sequencing routine for a companion DMA system.

[0021] [Figure 13] FIG. 10 is a timing diagram of one embodiment of a multi-frame software sequencing routine for a companion DMA system.

[0022] [Figure 14] 1 is a table with fields of a producer route table entry, according to one embodiment.

[0023] [Figure 15] 1 is a table with fields of a consumer route table entry according to one embodiment.

[0024] [Figure 16] 1 is a table with fields associated with a companion wrapper for a DMA engine, according to one embodiment.

[0025] [Figure 17] FIG. 1 is a flow diagram of one embodiment of a method for the operation of a producer DMA engine.

[0026] [Figure 18] FIG. 1 is a flow diagram of one embodiment of a method for operation of a consumer DMA engine.

[0027] [Figure 19] FIG. 10 is a flow diagram of one embodiment of a method for software to start a companion DMA chain.

[0028] [Figure 20] FIG. 1 is a flow diagram of one embodiment of a method for advancing a buffer by a programmable skip amount without consuming data credits.

[0029] [Figure 21] FIG. 10 is a flow diagram of one embodiment of a method for a producer DMA engine to generate frames.

[0030] [Figure 22] 1 is a flow diagram of one embodiment of a method for a consumer DMA engine to consume frames.

[0031] [Figure 23] FIG. 1 is a block diagram of one embodiment of a system.

[0032] While the embodiments described in this disclosure may be susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description relating to the drawings are not intended to limit the embodiments to the particular forms disclosed; rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the appended claims. As used throughout this application, the words "may" and "may" are used in their permissive sense (i.e., meaning having the possibility) rather than their obligatory sense (i.e., meaning must). Similarly, the words "include," "including," and "includes" mean including but not limited to.

[0033] Various units, circuits, or other components may be described as "configured to" perform a task or tasks. In such contexts, "configured to" is a broad description of structure that generally means "having circuitry" that performs a task or tasks during operation. Thus, a unit / circuit / component can be configured to perform a task even when the unit / circuit / component is not currently operating. In general, circuitry forming structure corresponding to "configured to" may include hardware circuitry. Similarly, various units / circuits / components may be described as performing a task or tasks for convenience of description. Such descriptions should be interpreted to include the phrase "configured to." It is expressly intended that a description of a unit / circuit / component configured to perform one or more tasks not invoke 35 U.S.C. 112(f) for that unit / circuit / component. DETAILED DESCRIPTION OF THE INVENTION

[0034] In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments described herein. However, those skilled in the art will understand that the embodiments may be practiced without these specific details. In some instances, well-known circuits, structures, and techniques are not shown in detail to facilitate illustration and avoid obscuring the description of the embodiments.

[0035] Referring now to FIG. 1 , a block diagram of one embodiment of a system-on-a-chip (SOC) 100 is shown. SOC 100 is shown coupled to memory 135. As the name implies, the components of SOC 100 may be integrated on a single semiconductor substrate as an integrated circuit “chip.” In some embodiments, the components may be implemented on two or more separate chips within a system. However, SOC 100 will be used herein as an example. In the illustrated embodiment, the components of SOC 100 include a central processing unit (CPU) complex 120, on-chip peripheral components 140A-140B (or, more simply, “peripherals”), a memory controller (MC) 130, a video encoder 150 (which may itself be considered a peripheral component), and a communications fabric 110. Components 120, 130, 140A-140B, and 150 may all be connected to communications fabric 110. Memory controller 130 may be actively coupled to memory 135, and peripheral device 140B may be actively coupled to external interface 160. In the illustrated embodiment, CPU complex 120 includes one or more processors (P) 124 and a level 2 (L2) cache 122.

[0036] Peripherals 140A-140B may be any set of additional hardware functions included within SOC 100. For example, peripherals 140A-140B may include video peripherals such as image signal processors configured to process image capture data from a camera or other image sensor, display controllers configured to display video data on one or more display devices, graphics processing units (GPUs), video encoders / decoders, scalers, rotators, blenders, etc. Peripherals may include audio peripherals such as microphones, speakers, interfaces to microphones and speakers, audio processors, digital signal processors, and mixers. Peripherals may include peripheral interface controllers for various interfaces 160 external to SOC 100 (e.g., peripheral 140B), including interfaces such as Universal Serial Bus (USB), peripheral component interconnect (PCI), including PCI Express (PCIe), serial ports, and parallel ports. Peripherals may include network peripherals such as media access controllers (MACs), etc. Any set of hardware may be included.

[0037] In one embodiment, SOC 100 may include at least one instance of a video encoder 150 component. Video encoder 150 may be an H.264 video encoder device that may be configured to convert input video frames from an input format to the H.264 / AVC format described in the H.264 / AVC standard. In one embodiment, SOC 100 includes a CPU complex 120. CPU complex 120 may include one or more CPU processors 124 that function as the CPU of SOC 100. The CPU of a system includes a processor(s) that executes the system's main control software, such as an operating system. Generally, during use, the software executed by the CPU may control other components of the system to achieve the system's desired functionality. Processor 124 may also execute other software, such as application programs. Application programs may provide user functionality and may rely on the operating system for lower-level device control. Thus, processor 124 may also be referred to as an application processor.

[0038] CPU complex 120 may further include other hardware, such as an L2 cache 122 and / or interfaces with other components of the system (e.g., interfaces with communications fabric 110). Generally, a processor may include any circuitry and / or microcode configured to execute instructions defined in an instruction set architecture implemented by the processor. Instructions and data acted upon by the processor in response to executing instructions may generally be stored in memory 135, although specific instructions may similarly define direct processor accesses to peripheral devices. A processor may include a processor core implemented on an integrated circuit with other components as a system-on-chip or other level of integration. A processor may also include a separate microprocessor, a processor core and / or microprocessor integrated in a multi-chip module implementation, a processor implemented as multiple integrated circuits, etc.

[0039] Memory controller 130 generally may include circuitry for receiving memory operations from other components of SOC 100 and accessing memory 135 to complete the memory operations. Memory controller 130 may be configured to access any type of memory 135. For example, memory 135 may be static random access memory (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), including double data rate (DDR, DDR2, DDR3, etc.) DRAM, etc. Low-power / mobile versions of DDR DRAM (e.g., LPDDR, mDDR, etc.) may be supported. Memory controller 130 may include a queue of memory operations for ordering (and possibly reordering) the operations and presenting the operations to memory 135. Memory controller 130 may further include data buffers for storing write data waiting to be written to memory and read data waiting to be sent back to the sender of the memory operation.

[0040] Communications fabric 110 can be any communications interconnect and communications protocol for communicating between components of SOC 100. Communications fabric 110 can be bus-based, including shared bus configurations, crossbar configurations, and hierarchical buses with bridges. Communications fabric 110 can also be packet-based, hierarchical with bridges, crossbar, point-to-point, or other interconnects. Note that the number of components of SOC 100 (and the number of subcomponents of those shown in FIG. 1 , such as within CPU complex 120) can vary depending on the embodiment. The number of each component / subcomponent may be more or less than that shown in FIG. 1 .

[0041] Referring to FIG. 2, one embodiment of a block diagram of a data manager 200 is shown. In the illustrated embodiment, data manager 200 includes a processor 205, a direct memory access (DMA) engine 206, and a memory 207. Processor 205 and DMA engine 206 are coupled to a system bus 202. Processor 205 may correspond to a general-purpose processing core similar to processor 124 of FIG. 1 that performs computational operations. For example, processor 205 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or such device. Alternatively, in another embodiment, processor 205 may correspond to video encoder 150 of FIG. 1. In various embodiments, processor 205 may implement any suitable instruction set architecture (ISA).

[0042] In one embodiment, DMA engine 206 can transfer data from a source location to a destination location. The source and destination locations may be memory locations, such as memory 207 or memory block 135 of FIG. 1. In some embodiments, DMA engine 206 may be capable of performing scatter-gather or gather-scatter memory transfers. Scatter-gather refers to a memory transfer in which the source address is changed (e.g., "scattered") and the destination is a single address (e.g., "gathered"). Gather-scatter is therefore the reverse. Processor 205 can program DMA engine 206 for one or more data transfers at a time.

[0043] In one embodiment, memory 207 includes a media command queue from which processor 205 retrieves media commands. In some embodiments, memory 207 may be implemented as random access memory (RAM) and may include program instructions for operation of processor 205. In other embodiments, memory 207 may be a first-in, first-out (FIFO) buffer and may be reserved for use as a media command queue.

[0044] In one embodiment, processor 205 performs operations to manage the flow of data related to media, such as frames to be displayed, as the data is sent to various media agents before being sent to a display. In other embodiments, processor 205 manages the flow of other types of data. In one embodiment, processor 205 retrieves a first command from a media queue in memory 207 and determines, from the first command, a target media agent to execute the command. Based on the first command, processor 205 may set up DMA engine 206 to retrieve a first data set for the frame from another media agent or from a memory, such as memory 207. DMA engine 206 copies the first data set to the target media agent. Processor 205 sends the first command to the target media agent for execution. While the target media agent executes the first media command, processor 205 retrieves a second command from a media command queue in memory 207. The second command may correspond to a second data set for a second media agent, in which case processor 205 configures DMA engine 206 to copy the second data set to the second media agent while the first command continues to execute. This process can continue for any number of additional data sets and commands.

[0045] In one embodiment, the DMA engine 206 can operate in frame companion mode with one or more other DMA engines (not shown). As used herein, "frame companion mode" is defined as an operating mode in which producers and consumers communicate the state of a shared circular buffer between each other to implement flow control. The state of the shared circular buffer can be captured by the values ​​of the write and read pointers and by the positions of the write and read pointers relative to each other. In one embodiment, the shared circular buffer is smaller than a full frame transferred between the producer and consumer. Frame companion mode supports the consumer's ability to know when a credit's worth of data has been generated, and frame companion mode supports the producer's ability to be backpressured when there is not enough space available in the buffer. Additionally, frame companion mode supports the consumer's ability to read regions of data in random order and increment the read pointer when the data associated with a skipped write credit is no longer needed. This feature enables support for a warper read DMA engine that reads tiles according to a configurable mesh.

[0046] It should be noted that the embodiment of data manager 200 shown in Figure 2 is by way of example only. The diagram of Figure 2 is simplified to highlight features relevant to the present disclosure. Various embodiments may include different configurations of functional blocks, including additional blocks.

[0047] Referring now to Figure 3, a block diagram of one embodiment of a remote companion DMA system 300 is shown. Remote companion DMA system 300 illustrates the connections and components of a system in which producer DMA engine 305 and consumer DMA engine 340 communicate remotely. This companion DMA system 300 can be referred to as a "remote" system because producer DMA engine 305 does not directly connect with consumer DMA engine 340. Note that companion DMA system 300 is an example of a remote companion DMA system according to one embodiment. Other embodiments can use other types of remote companion DMA systems with other types of components, other connections, and other suitable structures.

[0048] In one embodiment, pointers are exchanged between DMA engines 305 and 340 using fabric write requests that are routed between the DMA engines. These pointer exchanges virtualize the wires between the producer and consumer engines. Companion routers 365 and 370 are responsible for routing flow control information to DMA engines 305 and 340. In one embodiment, companion routers 365 and 370 use information stored in router table entries to route flow control pointers between producer and consumer DMA engines. Companion routers 365 and 370 are also responsible for handling multi-producer merge and multi-consumer broadcast functions in systems with multiple producers and / or multiple consumers. For example, in one embodiment, companion routers merge updates from multiple producer DMA engines into a single updated write pointer. In another embodiment, companion routers merge updates from multiple consumer DMA engines into a single updated read pointer.

[0049] In one implementation, companion router 365 contains control logic and routing tables of entries for producer DMA engine 305. Similarly, companion router 370 contains control logic and routing tables of entries for consumer DMA engine 340. The routing tables in each router are used by the router to exchange pointer updates with remote routers.

[0050] In one implementation, the route manager 375 manages the initialization and updating of routing tables in the local routers 365 and 370. As used herein, the term "route manager" is defined as a control unit (implemented using any suitable combination of software and / or hardware) that manages the initialization of route FIFOs 380A-N and routes in a router. There may be more than one route manager in a system, and these route managers may manage routes for any companion router in the system. Route FIFOs 380A-N represent any number of route FIFOs managed by the route manager 375. As used herein, the term "route FIFO" is defined as a FIFO queue of route descriptors that specify the serial sequence of frames in a stream. In some embodiments, the route manager 375 overprovisions route FIFOs 380A-N if one of the other subsystems that has a route FIFO is powered down. Note that the terms "route FIFO" and "route descriptor queue" may be used interchangeably herein.

[0051] Software running on a processor (e.g., processor 124 in FIG. 1) schedules frames by pushing route descriptors into the appropriate route FIFO of route manager 375. As used herein, the term "route descriptor" is defined as a field that specifies how flow control information is routed between producers and consumers. Each companion DMA subsystem has a producer route descriptor in each producer DMA and a consumer route descriptor in each consumer DMA. At a minimum, there is one producer route descriptor and one consumer route descriptor per companion DMA subsystem, but in general there can be any number of producer route descriptors and consumer route descriptors. Also, there is a 1:1 mapping from companion wrappers to DMA units, but there can be multiple companion wrappers for each companion router.

[0052] In one embodiment, route manager 375 pops route descriptors from route FIFOs and initializes route entries in the corresponding routers 365 and 370. As used herein, the term "route entry" is defined as a copy of the route descriptor as well as the active state of in-flight flow control information. Note that the terms "route entry" and "route table entry" may be used interchangeably herein. Route manager 375 also receives frame complete messages from routers 365 and 370. The frame complete messages are used to schedule descriptors for the next frame and to initialize pointers in the route entries to handle frame overlaps when a producer moves to the next frame while a consumer is finishing up the current frame.

[0053] Producer DMA engine 305 includes at least write DMA unit 310 and companion wrapper 315. As used herein, a "producer DMA engine" is defined as a write DMA channel that is writing data to a buffer in memory. A "producer DMA engine" is sometimes referred to herein as a "producer" for short. Companion wrapper 315 includes address wrapper 320 and pointer manager 325. Address wrapper 320 manages data writes to circular buffer 330 and the address wraparound case of circular buffer 332. Address wrapper 320 generates write requests (i.e., data writes) that are sent to circular buffer 332 in fabric and memory subsystem 330, and address wrapper 320 receives responses to the write requests from circular buffer 332. Pointer manager 325 manages flow control between producer DMA engine 305 and consumer DMA engine 320 via local and remote pointers.

[0054] Consumer DMA engine 340 includes at least read DMA unit 345 and companion wrapper 350, which includes address wrapper 355 and pointer manager 360. As used herein, a "consumer DMA engine" is defined as a read DMA channel that is reading data from a buffer in memory. A "consumer DMA engine" is sometimes referred to herein as a "consumer" for short. Companion wrapper 350 manages flow control for the DMA channel. When write DMA engine 310 finishes writing a data chunk to buffer 332, pointer manager 325 sends a buffer write pointer update to companion router 365. This update flows to pointer manager 360 via companion router 370. The buffer write pointer update indicates that a data credit has been committed to buffer 332 and is ready to be consumed. The size of the data chunk corresponding to a data credit can vary depending on the embodiment. In one embodiment, the size of the data chunk is measured in bytes of data. In another embodiment, the size of the data chunk is measured in terms of lines of a frame. In a further embodiment, the size of the data chunks is measured in terms of tiles or blocks of a frame.

[0055] When read DMA unit 345 consumes a data credit, pointer manager 360 sends a buffer read pointer update to companion router 370 indicating that the data credit has been consumed, freeing up space in buffer 332 for reuse by DMA producer engine 305. The buffer read pointer update continues to pointer manager 325 via companion router 365.

[0056] In one embodiment, buffer 332 is a circular buffer. In other embodiments, buffer 330 is another type of buffer. Note that buffer 332 supports random access by producers and consumers to chunks of data stored in buffer 332. This allows for random ordering of data production and consumption. Meanwhile, pointer updates are sequential but can often skip ahead by multiple increments. In one embodiment, buffer 330 is treated as a FIFO, where producers push credits of data into the buffer using an incrementing write pointer. Consumers consume credits of data from the buffer using an incrementing read pointer. The pointer address wraps at the size of the circular buffer. The pointer can be incremented by actual data access (read / write) or the pointer can be incremented when a credit is skipped. As used herein, the term "credit" is defined as a unit of flow control between a producer and a consumer. Depending on the embodiment, credits may be measured in terms of bytes of data, lines of uncompressed frame data, strips of frame data, tile rows of compressed data, etc. The circular buffer read and write pointers used for flow control are adjusted in units of credits. The parameter "SA-credits" measures the space available in the circular buffer in credits, and the parameter "DA-credits" measures the data available in the circular buffer in credits.

[0057] In one embodiment, the buffer write pointer points to the next location in the circular buffer where the producer will produce a credit's worth of data. Producing data can either be writing data or not writing data in the case of skipping a credit. In one embodiment, the buffer read pointer is the next location in the circular buffer where the consumer will consume a credit's worth of data. Consuming data means the consumer has completed the data, regardless of whether the consumer actually read the data or simply skipped the data.

[0058] Referring now to Figure 4, a block diagram of one embodiment of the logical connectivity between producer router table entries and consumer router table entries (RTEs) is shown. In some embodiments, there may be multiple producers supplying data to a single or multiple consumers. In the embodiment shown in Figure 4, there are three producers supplying a single consumer. Three producer DMA engines 405, 410, and 415 are shown on the left side of Figure 4. Each producer DMA engine 405, 410, and 415 has a corresponding RTE entry 420, 425, and 430, respectively. Each producer RTE 420, 425, and 430 has a logical connection to a corresponding consumer RTE 435, 440, and 445, respectively. Consumer RTEs 435, 440, and 445 allow data to be returned from the corresponding producer to consumer DMA engine 450. It should be understood that other embodiments may have other numbers of logical connections between RTEs for other numbers of producers and / or consumers.

[0059] Referring now to FIG. 5, a block diagram of another embodiment of a remote companion DMA system 500 is shown. DMA system 500 includes a producer DMA engine 505, a companion wrapper 507, a fabric and memory subsystem 510, a consumer DMA engine 515, a companion wrapper 517, companion routers 520 and 525, and route managers 530A-N. Each route manager 530A-N includes one or more corresponding route descriptor queues (Desc.Q) 530. Note that route managers 530A-N may be collectively referred to as route managers. Depending on the embodiment, a single route manager or multiple route managers may manage multiple route descriptor queues 535A-N. An example of a route descriptor queue is shown expanded from the dashed line connected to route descriptor queue 535A. The root descriptor is labeled with a producer identifier (ID) (e.g., P1, P2), a frame ID (e.g., F0, F1), and an indication of whether the descriptor is the last descriptor of the frame. It should be understood that this example of a root descriptor queue 535A is just one example of a root descriptor queue and the descriptors stored therein. In other embodiments, other types of descriptors may be used.

[0060] In one embodiment, route managers 530A-N support multiple streams of frames simultaneously through multiple route descriptor queues 535A-N, one route descriptor queue for each stream. Frames for a stream are scheduled by software, which pushes route descriptors into the corresponding route descriptor queue. If a single frame involves multiple DMAs, software pushes a separate route descriptor for each DMA participating in the frame. In one embodiment, if there is space in the route descriptor queue, as indicated by an occupancy register (not shown), software pushes the route descriptor associated with the frame into the desired route descriptor queue by writing to the appropriate register. In one embodiment, a low watermark threshold register stores the threshold value. When the number of entries in the corresponding route descriptor queue falls below the threshold value, an interrupt is generated to software indicating there is space in the route descriptor queue.

[0061] In one embodiment, descriptors for a frame are grouped together with the last descriptor in the group, and the last bit set indicates to the route manager that there is a full frame's worth of descriptors in the route descriptor queue. When the previous frame finishes, the route manager pops the next frame's worth of route descriptors from the head of the route descriptor queue and sends a corresponding update message to the appropriate router. Once the route table entries in the router are initialized by the route manager, the router gets updates from the local DMA and then routes flow control messages to other routers. When the DMA engine finishes a frame, the DMA engine notifies its companion wrapper, which in turn notifies the router. In response to receiving notification that the DMA engine has finished a frame, the router sends a corresponding frame complete message to the route manager. The route manager then proceeds to the next frame.

[0062] In one embodiment, DMA system 500 can accommodate multi-plane frame transfers. In this embodiment, each plane of a multi-plane frame is treated as a separate companion DMA with its own credits and peers. Also, in one embodiment, frame overlap is supported by DMA system 500. Frame overlap allows producer DMA engine 505 to begin processing the next (N+1) frame while consumer DMA engine 515 is still reading the current (N) frame. In one embodiment, overlapping frames have the same bytes per credit. However, overlapping frames may have a different number of credits per frame. In other words, overlapping frames may have different frame sizes. In one embodiment, overlapping frames are associated with the same root descriptor queue.

[0063] In another embodiment, DMA system 500 supports a single producer feeding multiple consumers in a broadcast fashion. In a further embodiment, DMA system 500 supports multiple producers feeding one consumer for superframe or multiplexing scenarios. In one embodiment, multiple frame producers are concatenated both horizontally and vertically. Also, superframe contents may vary from frame to frame. Also, in a further embodiment, DMA system 500 supports multiple producers feeding multiple consumers via a single superframe. Producers can write regions of any size and alignment within consumed frames. Similarly, consumers can read regions of any size and alignment within produced frames.

[0064] Referring now to FIG. 6, a table 600 having route descriptor fields that may be used in accordance with one embodiment is shown. Table 600 includes example route descriptor fields that may be included in a route descriptor pushed onto a route descriptor queue (e.g., route descriptor queue 535A of FIG. 5). For example, field 605 indicates whether the route descriptor entry is associated with a producer. In one embodiment, field 605 is a single bit where a 1 indicates that the entry is associated with a producer and a 0 indicates that the entry is associated with a consumer. Last field descriptor field 610 indicates whether this descriptor is the last routing descriptor for a given frame. Router ID field 615 identifies the producer router, and DMA ID field 620 identifies the producer DMA engine. Same buffer indicator 625 indicates whether this frame uses the same buffer as the previous frame. It should be understood that table 600 represents route descriptor fields that may be used in one particular embodiment. In other embodiments, other route descriptor fields may be defined for route descriptor queue entries.

[0065] Referring now to FIG. 7, a diagram of one embodiment of a superframe 700 is shown, which is produced by multiple producers and consumed by multiple consumers. In one embodiment, superframe 700 is produced and forwarded by multiple DMA producers P1-P9 and consumed by multiple DMA consumers C1-C3. The relationship between regions and the producers and consumers is indicated by the arrows between the producer and consumer blocks and the respective regions. For example, DMA producers P1 and P2 forward regions 705 and 710 to DMA consumers C1-C3, respectively. DMA producers P3 and P4 also forward regions 715 and 720, respectively, to DMA consumer C1. DMA producers P5, P6, P7, and P8 also forward regions 725, 730, 735, and 740, respectively, to DMA consumer C1.

[0066] It should be understood that the superframe 700 and configuration of producers and consumers shown in Figure 7 represent only one particular embodiment. In other embodiments, the superframe 700 may have other configurations of regions, other numbers of producers may produce different regions, and / or other numbers of consumers may consume different regions. For example, the size and shape of the regions within the superframe may differ from those shown in Figure 7, and the size, shape, and number of regions will vary according to the embodiment.

[0067] 8, one embodiment of a timing diagram 800 for a companion DMA system is shown. Timing diagram 800 illustrates an example sequence of events for a companion DMA system with two producers and one consumer. Rectangular blocks 805, 810, 815, and 820 at the top of timing diagram 800 represent producer 0, producer 1, the route manager, and consumer 0. For the transfer of frame 0 (or F0), producer 0 is transferring frame 0 to consumer 0. The transfer process begins with the route manager sending a route pointer update to producer 0 and consumer 0 at the start of the frame. Next, a flow control initialization message is sent from producer 0 to consumer 0 with the write pointer value, and a flow control initialization message is sent from consumer 0 to producer 0 with the read pointer value. Dashed line 825 indicates when producer 0 has finished forwarding frame 0, which is acknowledged by producer 0 sending a frame complete message to consumer 0 and the route manager.

[0068] For the purposes of this explanation, assume that Producer 1 forwards Frame 1 to Consumer 0. Consumer 0 may still be consuming Frame 0 when the forwarding of Frame 1 begins. The Route Manager sends a route pointer update to Producer 1, and the Route Manager sends a route update for Frame 1 to Consumer 0. Producer 1 sends an Initialize message to Consumer 0, then forwards Frame 1 to a buffer. When the forwarding of Frame 1 is complete, Producer 1 sends a Frame Complete message to Consumer 0. The dashed line labeled 830 indicates when Consumer 0 finishes consuming Frame 0 and moves on to Frame 1. Consumer 0 sends a Frame Complete message to Producer 1 and to the Route Manager. Consumer 0 then receives a router pointer update for Frame 1 from the Route Manager. Consumer 0 sends an Initialize message to Producer 1, then Consumer 0 begins consuming Frame 1. When the consumption of Frame 1 is complete, Consumer 0 sends a Frame Complete message to Producer 1 and to the Route Manager.

[0069] Referring now to Figure 9, a timing diagram 900 of one embodiment of the operation of a companion DMA system is shown. Timing diagram 900 shows the sequence of events in a companion DMA system having two producers 905 and 910, a route manager 915, and a consumer 920. Producers 905 and 910 are also referred to as producers 0 and 1, or P0 and P1, respectively. Consumer 920 is also referred to as consumer 0 or C0 in diagram 900. Frame 0 (or F0) is sent from producer 0 to consumer 0. At the beginning of frame 0, route manager 915 sends a route pointer update to producer 0 and consumer 0. Flow control messages are then exchanged between producer 0 and consumer 0 to provide updated write and read pointer values. When producer 0 finishes writing frame 0 to its buffer, a frame done message is sent to consumer 0 and route manager 915 along with the write pointer update. The dashed line 925 indicates when the buffer is full.

[0070] For the purposes of this explanation, assume that producer 1 is sending frame 1 to consumer 0. Thus, after route manager 915 receives a frame done message from producer 0 for frame 0, route manager 915 sends a route pointer update for frame 1 to producer 1. Producer 1 then sends a flow control update for frame 1 to consumer 0. At this point, consumer 0 is still consuming frame 0's data from its buffer, and producer 1 has not yet received the updated read pointer value from consumer 0 because consumer 0 is sending these updates to producer 0. When consumer 0 finishes consuming frame 0 from its buffer, consumer 0 sends a frame done message to producer 0 and route manager 915. Consumer 0 then sends a flow control message for frame 1 to producer 1 with the updated read pointer value. This flow control message allows consumer 0 to communicate its starting state to producer 1.

[0071] Dashed line 930 represents the point in time when producer 1 receives an updated read pointer value indicating that more space is available in the buffer to write the data for frame 1. When producer 1 has written the entirety of frame 1 to the buffer, producer 1 sends a frame done message to consumer 0 and route manager 915. When consumer 0 has consumed the entirety of frame 1 from the buffer, consumer 0 sends a frame done message to producer 1 and route manager 915.

[0072] Referring now to Figure 10, a timing diagram 1000 is shown for one embodiment of a companion DMA system with multiple producers and multiple consumers. Timing diagram 1000 illustrates the sequence of events for a companion DMA system with three producers 1005, 1010, and 1015, a route manager 1020, and three consumers 1025, 1030, and 1035. Producers 1005, 1010, and 1015 are also referred to as producers 0, 1, and 2, or P0, P1, or P2, respectively. Consumers 1025, 1030, and 1035 are also referred to in diagram 1000 as consumers 0, 1, and 2, or C0, C1, and C2, respectively. Frame 0 (or F0) is transmitted from producers 0 and 1 to consumers 0 and 1. The start of the transfer of Frame 0 is indicated by dashed line 1040. At the start of frame 0, route manager 1015 sends route pointer and read and write pointer updates to producers 0 and 1 and consumers 0 and 1. Flow control messages are then exchanged between producers 0 and 1 and consumers 0 and 1 to provide updated write and read pointer values. When producers 0 and 1 finish writing frame 0 to their buffers, a frame complete message is sent to consumers 0 and 1 and route manager 1015 along with the write pointer update. Dashed line 1045 indicates when the producers can move on to the next frame (i.e., frame 1) after all producers have finished forwarding their respective portions of frame 0. After dashed line 1045, because producers 0 and 2 are on frame 1 and consumers 0 and 1 are still on frame 0, an intermediate route is created between producers 0 and 2 and consumers 0 and 1. This allows producers 0 and 2 and consumers 0 and 1 to continue exchanging credits. The intermediate route has flow control messages being exchanged between producers and consumers, even if they are on different frames.When consumers 0 and 1 finish consuming frame 0 from their buffers, they send a frame done message with a read pointer update to producers 0 and 2. Note that the description of Figure 10 continues with the description of Figure 11.

[0073] Referring now to Figure 11, a timing diagram 1100 of one embodiment of a companion DMA system with multiple producers and multiple consumers is shown. The companion DMA system shown in Figure 11, with three producers 1005, 1010, and 1015, a route manager 1020, and three consumers 1025, 1030, and 1035, is intended to represent the same companion DMA system shown in Figure 10. Thus, timing diagram 1100 is a continuation of the sequence of events shown in timing diagram 1000 (of Figure 10). At the top of timing diagram 1100, after consumers 0 and 1 finish consuming frame 0 data from the buffer, consumers 0 and 1 send a frame done message with a read pointer update to route manager 1020.

[0074] Dashed line 1105 represents the start of the consumption of frame 1. For the purposes of this explanation, assume that producers 0 and 2 are forwarding frame 1 to consumers 0 and 2. Thus, at the start of frame 1, route manager 1020 sends a route pointer update for frame 1 to producers 0 and 2, and route manager 1020 sends a route update for frame 1 to consumers 0 and 1. Route manager 1020 then sends a route pointer update for frame 1 to consumers 0 and 2. The route pointer update sent by route manager 1020 also includes an indication of the write pointer value and the read pointer value. Route manager 1020 also sends a route update for frame 1 to producers 0 and 2. During the forwarding of frame 1, flow control messages are exchanged between producers 0 and 2 and consumers 0 and 2. These flow control messages include write pointer updates or read pointer updates. Then, once the entirety of Frame 1 has been transferred to the buffer, Producers 0 and 2 send Frame Complete messages to Consumers 0 and 2 and to Route Manager 1020. Note that although these messages are not shown in timing diagram 1100, additional messages may be sent by Consumers 0 and 2 when they finish consuming the data for Frame 1. Subsequent frames may also involve message exchanges similar to those shown for Frames 0 and 1 in timing diagrams 1000 and 1100.

[0075] Timing diagrams 1000 and 1100 illustrate the exchange of pointers between producers and consumers according to one embodiment. One advantage of using pointers is that producer pointers can be sent to consumers that have not yet started. These consumers can drop flow control messages, which are treated as future write pointer updates from the producer arriving at the consumer whenever the consumer is configured, including after the producer has completely finished a frame.

[0076] 12, a diagram 1200 of one embodiment of a multi-frame software ordering routine for a companion DMA system is shown. At the start of the routine, producers 1205 and 1210, consumer 1215, and route manager 1220 are taken out of reset. Note that producers 1205 and 1210 are also referred to as P0 and P1, and consumer 1215 is also referred to as C0. After producers 1205 and 1210, consumer 1215, and route manager 1220 are taken out of reset, software running on the system pushes the route descriptor associated with frame 0 to the appropriate route descriptor queue. In one embodiment, software pushes the route descriptor to route manager 1220 by writing to the corresponding route descriptor queue register. Also, after producers 1205 and 1210 and consumer 1215 are taken out of reset, software pushes the DMA configuration data for frame 0 into the shadow DMA registers. The software ordering routine for frame 0 is repeated for frame 1.

[0077] Referring now to FIG. 13, a diagram 1300 of one embodiment of a multi-frame software ordering routine for a companion DMA system is shown. Diagram 1300 is intended to be a continuation of the routine shown in diagram 1200 (FIG. 12). At the top of diagram 1300, Frame 2 has different producers P0 and P2 compared to Frame 1, which had producers P0 and P1. Producers P0 and P2 are also referred to as producers 1305 and 1310. Consumer 1315, also referred to as C0, is the only consumer in this example, and route manager 1320 is intended to represent route manager 1220. As shown in diagram 1300, there is an overlap between the configurations of the Frame 1 and Frame 2 producers being generated. For both producers P0 and P2, software pushes route descriptors for Frame 2 to route manager 1320, and software pushes DMA configuration data into the shadow DMA registers. Note that this software sequencing routine can continue for any number of subsequent frames.

[0078] Referring now to FIG. 14, a table 1400 is shown having fields of a producer route table entry according to one embodiment. Entry 1405 of table 1400 corresponds to the active field of the producer route table entry. The active field indicates whether the entry is actively routing credits. Entry 1410 represents a "Producer?" field that indicates whether this route table entry is associated with a producer. In one embodiment, the "Producer?" field is 1 if the route table entry is associated with a producer, and the "Producer?" field is 0 if the route table entry is associated with a consumer. Entry 1415 corresponds to a local DMA ID field that identifies the local credit wire associated with the route table entry. Entry 1420 indicates a destination router ID field that contains the ID of the remote peer router table to which the credits are sent via fabric write. In one embodiment, the address of the remote router mailbox is stored in a remote router address register.

[0079] Entry 1425 corresponds to a destination DMA ID field that stores an identifier for the DMA engine in the destination router. Entry 1430 indicates a route manager ID field that identifies the route manager that initiated and manages this route. In one embodiment, the low-order bits of the route manager ID field identify the corresponding route descriptor queue in the route manager. Entry 1435 corresponds to a buffer write pointer field that contains a producer write pointer to the location of the next credit to be written to the circular buffer. Entry 1440 indicates a buffer read pointer field that stores a pointer to the next credit to be consumed by the consumer.

[0080] Referring now to Figure 15, a table 1500 is shown having fields of a consumer route table entry according to one embodiment. Entries 1505, 1510, 1515, 1520, 1525, and 1530 are the same as entries 1405, 1410, 1415, 1420, 1425, and 1430, respectively, of table 1400 (of Figure 14). Entry 1535 indicates a buffer read pointer field that stores a pointer to the next credit to be consumed by the consumer. Entry 1540 corresponds to a buffer write pointer field that contains a producer write pointer to the location of the next credit to be written to the circular buffer. Entry 1535 is the same as entry 1440 in table 1400, and entry 1540 is the same as entry 1435 in table 1400, but the order of the consumer route table entries is reversed.

[0081] Referring now to Figure 16, a table 1600 with fields of a companion wrapper for a DMA engine is shown according to one embodiment. Entry 1605 corresponds to a buffer write pointer field that contains a producer write pointer to the location of the next credit to be written to the circular buffer. Entry 1610 indicates a buffer read pointer field that stores a pointer to the next credit to be consumed by the consumer. Buffer size field 1615 specifies the size of the circular buffer in terms of number of credits. In another embodiment, buffer size field 1615 specifies the size of the circular buffer in terms of number of bytes. In this embodiment, a conversion can be performed to convert the value in buffer size field 1615 to a number of credits.

[0082] For a producer DMA engine, the frame pointer field 1620 points to the next credit within a frame that the producer DMA engine writes to the buffer. For a consumer DMA engine, the frame pointer field 1620 points to the next credit within a frame that the consumer DMA engine reads from the buffer. The frame size field 1625 specifies the total frame size in credits, including the start increment, mid-increment, and end increment. A DMA engine is considered complete after processing a number of credits equal to the value specified in the frame size field 1625. The frame start increment field 1630 specifies the number of credits to increment at the start of a frame. The frame start increment field 1630 allows a producer to skip credits that it does not generate. The frame mid-increment field 1635 specifies the number of credits to increment within a frame. The frame mid-increment field 1635 allows subsampling or skipping of credits written to the buffer. The Frame Done Increment field 1640 specifies the number of credits to send to the consumer when the producer frame is completed. The Frame Done Increment field 1640 allows the producer to skip credits that it does not generate. The Start Offset field 1645 specifies the value of Space Available Credits that must be reached at the beginning of the frame before data can be produced. The Disable Remote field 1650 specifies whether to disable remote flow control messages to support the NULL connection feature. The NULL connection feature allows the link to be disabled while still processing the remainder of the frame as if all remote credits had been received.

[0083] Referring now to Figure 17, a generalized flow diagram of one embodiment of a method 1700 for producer DMA engine operation is shown. For purposes of explanation, the steps of this embodiment (as well as Figures 18-22) are shown sequentially. However, in other embodiments, some steps may be performed in a different order than shown, some steps may occur simultaneously, some steps may be combined with other steps, and some steps may be absent.

[0084] Before starting to transfer at least a portion of a frame to the buffer, the producer DMA engine determines whether there is space in the buffer in memory (block 1705). While method 1700 is described in the context of a frame being transferred, it should be understood that this is only one possible implementation of method 1700. In other embodiments, the producer DMA engine may transfer other types of data sets other than image or video frames. If there is no space in the buffer (conditional block 1710, "No" branch), the producer DMA engine waits to receive a pointer update from the consumer DMA engine (i.e., indicating that data credits have been consumed and space is available in the buffer) (block 1715). If there is space in the buffer (conditional block 1710, "Yes" branch), the producer DMA engine writes the given portion of the frame to the buffer (block 1720). When the producer DMA engine finishes writing a given portion of the frame to a buffer in memory, the producer sends the status of its updated producer write pointer to the consumer DMA engine, indicating that the credit for the data has been committed to memory and is ready to be consumed (block 1725). For purposes of this discussion, we assume that the size of the portions of data referenced in blocks 1720 and 1725 corresponds to a single credit's worth of data.

[0085] If the producer DMA engine has finished writing all portions of the frame to its buffer (conditional block 1730, "yes" branch), the producer DMA engine generates a producer frame done message (block 1735). After block 1735, method 1700 ends. Alternatively, after block 1735, another instance of method 1700 is launched for each producer DMA engine that is generating the next frame in the video sequence. Note that a new instance of method 1700 may be launched for a producer DMA engine to generate a new frame while the consumer DMA engine is still consuming the previous frame. If the producer DMA engine has not finished writing all portions of the frame to its buffer (conditional block 1730, "no" branch), method 1700 returns to conditional block 1710.

[0086] Referring now to FIG. 18, a generalized flow diagram of one embodiment of a method 1800 for the operation of a consumer DMA engine is shown. The consumer DMA engine determines whether data credits have been committed to a buffer in memory before beginning to consume at least a portion of a frame from the buffer (block 1805). While method 1800 is described in the context of frames being consumed, it should be understood that this is only one possible implementation of method 1800. In other embodiments, the consumer DMA engine may consume other types of data sets other than image or video frames. If data credits have not been committed to the buffer (conditional block 1810, “No” branch), the consumer DMA engine waits to receive a pointer update from the producer DMA engine (i.e., indicating that data credits have been committed to the buffer and are ready to be consumed) (block 1815). If data credits have been committed to the buffer (conditional block 1810, “Yes” branch), the consumer DMA engine consumes or skips a portion of the frame from the buffer (block 1820). When the consumer DMA engine finishes consuming or skipping a given portion of the frame from the buffer in memory, the consumer sends the status of its updated consumer read pointer to the producer DMA engine to indicate that the credit for data has been consumed and the space in the buffer has been freed (block 1825). For purposes of this discussion, it is assumed that the size of the portions of data referenced in blocks 1820 and 1825 corresponds to a single credit's worth of data.

[0087] If the consumer DMA engine has finished consuming all portions of the frame from the buffer (conditional block 1830, "yes" branch), the consumer DMA engine generates a consumer frame done message (block 1835). After block 1835, method 1800 ends. Alternatively, after block 1835, another instance of method 1800 is launched for each consumer DMA engine that is consuming the next frame in the video sequence. If the consumer DMA engine has not finished consuming all portions of the frame from the buffer (conditional block 1830, "no" branch), method 1800 returns to conditional block 1810. In that regard, method 1800 can be performed in combination with method 1700 (see FIG. 17). For example, a separate instance of method 1700 can be executed by each producer DMA engine that is transferring data to the buffer, in parallel with a separate instance of method 1800 being executed by each consumer DMA engine that is consuming data from the buffer.

[0088] Referring now to FIG. 19, one embodiment of a method 1900 for software to start a companion DMA chain is shown. Software executing on one or more processors takes all subsystems of the companion DMA chain and the companion router out of reset (block 1905). When all subsystems of the companion DMA chain and the companion router are out of reset and the software is ready to schedule the next frame, the software pushes route descriptors for the next frame into a single route descriptor queue in the route manager (block 1910). The software also pushes the DMA configuration into a configuration FIFO and / or shadow registers (block 1915). Note that block 1915 may be executed before block 1910 in some embodiments. In other words, no ordering is required for blocks 1910 and 1915; they may be executed in any order or simultaneously. For subsequent frames, software pushes route descriptors into a single route descriptor queue per frame and pushes each DMA configuration into a configuration FIFO and / or shadow register (block 1920). By executing block 1920, this ensures that the route manager and DMA engine are ready to process subsequent frames as they begin to flow through the chain. After block 1920, method 1900 ends. Note that software can push route descriptors and DMA configurations at any time before the associated frame starts, including several frames in advance.

[0089] Referring now to FIG. 20, one embodiment of a method 2000 for advancing a buffer by a programmable skip amount without consuming data credits is shown. The programmable credit skip amount is specified during the transfer of a given frame from a producer DMA engine to a consumer DMA engine (block 2005). The programmable credit skip amount indicates how far ahead in the buffer the consumer DMA engine will jump while consuming credits from the buffer. Multiple different programmable credit skip amounts can be specified per frame. In one embodiment, the programmable credit skip amount is specified in response to detecting a time warp condition. For example, a time warp condition includes updating the image presented to the user if the user's head moves after frame rendering has begun. In one embodiment, the application includes eye tracking that allows the consumer to retrieve a subset or sub-frame of a rendered frame based on the user's point of gaze within that frame. In other embodiments, a programmable credit skip amount is specified for other scenarios, such as during the generation of a superframe.

[0090] The consumer DMA engine then consumes data from a buffer location that is one or more credits ahead of the current position of the read pointer (block 2010). In one embodiment, the consumer DMA engine selects a buffer location to read from in block 2010 based on a programmable credit skip amount. The consumer DMA engine then increments the read pointer by multiple credits in response to consuming data from the buffer location that is one or more credits ahead of the current position of the read pointer (block 2015). The consumer DMA engine then sends the updated read pointer to the producer DMA engine (block 2020). After block 2020, method 2000 ends. By performing method 2000, the consumer DMA engine allows the producer DMA engine to continue making progress in transferring frames, alleviating potential backpressure on the producer DMA engine.

[0091] Referring now to FIG. 21, one embodiment of a method 2100 for a producer DMA engine to generate a frame is shown. At the start of a frame, the producer DMA engine receives or retrieves an indication of the total frame size in credits for the frame, potentially including the beginning, middle, and / or completion increments (block 2105). The producer DMA engine skips the number of credits specified by the Frame Start Increment field (block 2110). Block 2110 allows the producer to skip credits that it does not create. Note that the Frame Start Increment field may be equal to 0, meaning that the producer DMA engine does not skip credits. If the Space Available credits are greater than or equal to the Starting Offset field (conditional block 2115, "Yes" branch), the producer begins generating data for the frame (block 2120). Note that "generating data" is defined as writing or skipping data. Otherwise, if the space available credits are less than the starting offset field (condition block 2115, "No" branch), method 2100 remains in condition block 2115 until the consumer consumes enough data for the space available credits to reach the value specified by the starting offset field.

[0092] After block 2120, the producer continues generating data until it reaches a specified internal point within the frame (block 2125). The producer then increments the number of credits by the amount specified by the frame intermediate increment field (block 2130). Block 2130 allows for subsampling or skipping of credits written to the buffer. Note that blocks 2125 and 2130 are optional and may be skipped in some embodiments. Alternatively, in other embodiments, blocks 2125 and 2130 may be repeated multiple times for multiple different internal points within the frame. The producer then continues generating the remaining data for the frame (block 2135). If the producer has processed a number of credits equal to the total frame size minus the frame done increment (conditional block 2140, "yes" branch), the producer sends the number of credits specified by the frame done increment field to the consumer (block 2145). The producer then generates a producer frame done message (block 2150). After block 2150, method 2100 ends. Otherwise, if the producer has not processed a number of credits equal to the total frame size minus the frame done increment (conditional block 2140, "No" branch), method 2100 returns to block 2135.

[0093] Referring now to FIG. 22, one embodiment of a method 2200 for a consumer DMA engine to consume a frame is shown. At the start of a frame, the consumer DMA engine receives or retrieves an indication of the total frame size in credits for the frame, potentially including the beginning, middle, and / or end increments (block 2205). The consumer DMA engine skips the number of credits specified by the Frame Start Increment field (block 2210). Block 2210 allows the consumer to skip credits that it does not consume. Note that the Frame Start Increment field may be equal to 0, meaning that the consumer DMA engine does not skip credits. If the Data Available Credits are greater than or equal to the Starting Offset field (conditional block 2215, "Yes" branch), the consumer begins consuming the frame's data (block 2220). Note that "consuming data" is defined as reading or skipping data. Otherwise, if the data available credits are less than the starting offset field (condition block 2215, "No" branch), method 2200 remains in condition block 2215 until the producer generates enough data for the data available credits to reach the value specified by the starting offset field.

[0094] After block 2220, the consumer continues consuming data until it reaches a specified internal point within the frame (block 2225). The consumer then increments the number of credits by the amount specified by the frame intermediate increment field (block 2230). Block 2230 allows for subsampling or skipping of consumed credits from the buffer. Note that blocks 2225 and 2230 are optional and may be skipped in some embodiments. Alternatively, in other embodiments, blocks 2225 and 2230 may be repeated multiple times for multiple different internal points within the frame. The consumer then continues consuming the remaining data for the frame (block 2235). If the consumer has consumed a number of credits equal to the total frame size minus the frame done increment (conditional block 2240, "yes" branch), the consumer sends the number of credits specified by the frame done increment field to the producer (block 2245). The consumer then generates a consumer frame done message (block 2250). After block 2250, method 2200 ends. Otherwise, if the consumer has not consumed a number of credits equal to the total frame size minus the frame done increment (conditional block 2240, "No" branch), method 2200 returns to block 2235.

[0095] 23 , a block diagram of one embodiment of a system 2300 is shown. As shown, the system 2300 may represent chips, circuits, components, etc. within a desktop computer 2310, a laptop computer 2320, a tablet computer 2330, a cellular or mobile telephone 2340, a television 2350 (or a set-top box configured to connect to a television), a watch or other wearable item 2360, or others. Other devices are possible and contemplated. In the illustrated embodiment, the system 2300 includes at least one instance of a SOC 100 coupled to one or more peripheral devices 2304 and an external memory 2302. A power source 2306 is also provided, which provides a supply voltage to the SOC 100 and one or more supply voltages to the memory 2302 and / or the peripheral devices 2304. In various embodiments, the power source 2306 may represent a battery (e.g., a rechargeable battery in a smartphone, laptop, or tablet computer). In some embodiments, more than one instance of device 100 may be included (and more than one external memory 2302 may also be included).

[0096] Memory 2302 can be any type of memory, such as dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM (including mobile versions of SDRAM, such as mDDR3, and / or low-power versions of SDRAM, such as LPDDR2), RAMBUS DRAM (RDRAM), static RAM (SRAM), etc. One or more memory devices can be connected to a circuit board to form a memory module, such as a single in-line memory module (SIMM), a dual in-line memory module (DIMM), etc. Alternatively, devices can be mounted on SOC 100 in a chip-on-chip configuration, a package-on-package configuration, or a multi-chip module configuration.

[0097] The peripherals 2304 may include any desired circuitry depending on the type of system 2300. For example, in one embodiment, the peripherals 2304 may include devices for various wireless communications, such as Wi-Fi, Bluetooth, cellular, global positioning systems, etc. The peripherals 2304 may also include additional storage, such as RAM storage, solid-state storage, or disk storage. The peripherals 2304 may also include user interface devices, such as a display screen, including a touch or multi-touch display screen, a keyboard or other input device, a microphone, a speaker, etc.

[0098] In various embodiments, the methods and / or mechanisms described above may be implemented using program instructions from a software application. The program instructions may describe the behavior of the hardware in a high-level programming language such as C. Alternatively, a hardware design language (HDL) such as Verilog may be used. The program instructions may be stored on a non-transitory computer-readable storage medium. Many types of storage media are available. The storage medium may be accessible during use by a computer to provide the computer with the program instructions and associated data for program execution. In some embodiments, a synthesis tool reads the program instructions to generate a netlist, including a list of gates, from a synthesis library.

[0099] It is emphasized that the above-described embodiments are merely non-limiting examples of implementations. Many 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 buffer, a producer direct memory access (DMA) engine; a consumer DMA engine; In response to producing a given data chunk of a data set, the producer DMA engine is configured to send an updated write pointer to the consumer DMA engine indicating that data credits have been committed to the buffer and that the data credits are ready to be consumed; in response to consuming the given data chunk of the data set from the buffer, the consumer DMA engine is configured to send an updated read pointer to the producer DMA engine indicating that the data credit has been consumed and that space in the buffer has been freed up to be reused by the producer DMA engine.

2. The data set is a first frame of a video sequence, the size of the buffer is smaller than the size of the first frame, and the producer DMA engine: writing data to a first buffer location one or more data credits ahead of the current position of the updated write pointer; 2. The apparatus of claim 1, configured to increment the write pointer by a number of data credits after writing data to the first buffer location.

3. The consumer DMA engine comprises: reading data from a second buffer location one or more data credits ahead of the current position of the updated read pointer, the second buffer location being specified by a programmable skip amount; 3. The apparatus of claim 2, configured to increment the read pointer by a number of data credits after reading data from the second buffer location.

4. a route manager, Manages the initialization and updating of routing tables in a plurality of local routers; 4. The apparatus of claim 3, further comprising a route manager configured to pop a route descriptor for the first frame from a corresponding route descriptor queue and initialize route entries in the plurality of local routers.

5. a plurality of producer DMA engines configured to transfer distinct portions of the first frame to the buffer; 4. The apparatus of claim 3, further comprising: a companion router configured to merge updates from the plurality of producer DMA engines into the updated write pointer.

6. The apparatus of claim 3 , further comprising a plurality of consumer DMA engines configured to consume distinct portions of the first frame from the buffer.

7. 4. The apparatus of claim 3, wherein the producer DMA engine is configured to generate a portion of a second frame before the consumer DMA engine has finished consuming all portions of the first frame.

8. 1. A method comprising: generating a given data chunk of the data set by a producer direct memory access (DMA) engine; In response to generating the given data chunk of the data set, sending an updated write pointer to a consumer DMA engine indicating that data credits have been committed to a buffer and that the data credits are ready to be consumed; consuming, by the consumer DMA engine, the data credits corresponding to the given data chunk of the data set; in response to consuming the given data chunk of the data set from the buffer, sending an updated read pointer to the producer DMA engine indicating that the data credits have been consumed and that space in the buffer has been freed up to be reused by the producer DMA engine.

9. The data set is a first frame of a video sequence, and the size of the buffer is smaller than the size of the first frame, and the method comprises: writing, by the producer DMA engine, data to a first buffer location one or more data credits ahead of the current position of the updated write pointer; 9. The method of claim 8, further comprising: after writing data to the first buffer location, incrementing the write pointer by a number of data credits.

10. reading, by the consumer DMA engine, data from a second buffer location one or more data credits ahead of the current position of the updated read pointer, the second buffer location specified by a programmable skip amount; incrementing the read pointer by a number of data credits after reading data from the second buffer location; The method of claim 9 further comprising:

11. managing, by a route manager, the initialization and updating of routing tables in a plurality of local routers; popping a route descriptor for the first frame from a corresponding route descriptor queue; and initializing route entries in the plurality of local routers; The method of claim 10 further comprising:

12. transferring, by a plurality of producer DMA engines, separate corresponding portions of the first frame to the buffer; merging, by a companion router, updates from the plurality of producer DMA engines into the updated write pointer; The method of claim 10 further comprising:

13. 11. The method of claim 10, further comprising consuming separate portions of the first frame from the buffer by a plurality of consumer DMA engines.

14. 11. The method of claim 10, further comprising: writing, by the producer DMA engine, a portion of a second frame to the buffer before the consumer DMA engine has finished consuming all portions of the first frame.

15. 1. A system comprising: A buffer, a producer direct memory access (DMA) engine; In response to producing a given data chunk of a data set, the producer DMA engine is configured to generate an updated write pointer indicating that data credits have been committed to the buffer and that the data credits are ready to be consumed.

16. 16. The system of claim 15, further comprising a consumer DMA engine, wherein in response to consuming the given data chunk of the data set from the buffer, the consumer DMA engine is configured to send an updated read pointer to the producer DMA engine indicating that the data credit has been consumed and that space in the buffer has been freed up to be reused by the producer DMA engine.

17. 17. The system of claim 16, wherein the data set is a first frame of a video sequence, and the size of the buffer is less than the size of the first frame.

18. The producer DMA engine writing data to a first buffer location one or more data credits ahead of the current position of the updated write pointer; 20. The system of claim 17, further configured to increment the write pointer by a number of data credits after writing data to the first buffer location.

19. In response to receiving an indication of a given condition, the consumer DMA engine: reading data from a second buffer location one or more data credits ahead of the current position of the updated read pointer, the second buffer location being specified by a programmable skip amount; 20. The system of claim 18, further configured to increment the read pointer by a number of data credits after reading data from the second buffer location.

20. a route manager, Manages the initialization and updating of routing tables in a plurality of local routers; 20. The system of claim 17, further comprising a route manager configured to pop a route descriptor for the first frame from a corresponding route descriptor queue and initialize route entries in the plurality of local routers.

Images