Multi-threaded processing design in architecture with multiple co-processors

RELATED APPLICATIONS

p-0002Benefit is claimed under 35 U.S.C. 119(e) to U.S. Provisional Application Ser. No. 60/570,720, entitled “Multi-threaded processing pipeline design for maximizing the multimedia encoding/decoding throughput in an architecture with multiple co-processors and/or hardware accelerators” by Shankaranarayanan Parameswaran et al, filed May 13, 2004, which is herein incorporated in its entirety by reference for all purposes.

FIELD OF THE INVENTION

p-0003This invention generally relates to multi-threaded pipeline design in data handling, and more particularly to multi-threaded pipeline design in multimedia codec architecture that uses multiple co-processors and optional hardware accelerators.

BACKGROUND OF THE INVENTION

p-0004Design engineering has advanced by leaps and bounds with the effort by semiconductor vendors supporting development of special purpose software and development of new firmware in operating systems. Even before the availability of ASICs (application specific integrated circuits), design engineers spared no effort in building prototype boards and to enable software engineers to build required codes and make innovations in how to use available resources efficiently. Another available tool for design engineers comprises hardware accelerators which have been used profusely to speed design and simulation work. With designs getting larger and more complex, there is now added impetus to use the SoC (system-on-a-Chip) approach to cater to increasing design needs and demands. Compelling advantages in terms of cost and flexibility offered by SoC solutions, that pack a DSP with multiple minimally programmable coprocessors or hardware accelerators under the control of that DSP, have made such SoCs very popular. Real time multimedia processing, which usually involves sequential data dependencies, poses technical challenges in realizing the design on such a multi-processor architecture owing to shared resource limitations (such as on-chip memory, DMA controller) and variations in the processing complexity from one processing stage to the other. In design efforts involving especially multimedia processing, where multiple co-processors and or hardware accelerators are used, there is a need to ensure that an efficient and flexible use of the resources is made in terms of the allocation of processing tasks and the time taken to complete the allocated tasks.

SUMMARY OF THE INVENTION

p-0005One embodiment of the invention resides in a method for designing a processing operation in an architecture that uses multiple processors, comprising the steps of: identifying a chronological sequence of processing stages for processing input data including identifying interdependencies of said processing stages; allotting each said processing stage to a processor; staggering the processing to accommodate said interdependencies; selecting a subset of possible pipelines that offer low average processing time, based on said allotment; and, choosing one design pipeline that offers overall timing reduction in presence of statistical variations to complete said processing operation.

p-0006A second embodiment of the invention resides in a method for achieving efficient parallel processing multi-thread-design-capability in architecture which uses multiple processor units and is capable of handling multi-media encoding/decoding, comprising the steps of: identifying different processing stages for and their interdependencies during processing input data; assigning each said processing stage to a suitable processing unit; staggering said processing stages to accommodate said interdependencies; assigning a buffer, by mapping, to each processing unit for each processing stage; ascertaining processing time needed, on respective mapped processing units, for fixed complexity processing stages and varying complexity processing stages; based on an average processing time and other predetermined constraints, selecting a subset of possible timelines that offer a best average processing time; and, from the subset of possible timelines, selecting a single design pipeline that offers the best timing.

p-0007Another embodiment resides in an article comprising a storage medium having instructions thereon that when executed by a computing platform, result in execution of a method as above. The invention can be applied in any scenario where multiple co-processors and/or accelerators are used. In particular, and as described hereinafter, the invention is applied in multimedia processing involving both video and audio processing, offering flexibility and ensuring efficient use of available resources to result in a minimum idle time for key processors.

p-0008In video compression, as described in one embodiment, spatial and temporal prediction of coding parameters from already coded macroblock parameters is employed to reduce the redundancy and improve the compression efficiency. Such prediction steps introduce dependencies between the various processing stages. Given a heterogeneous set of co-processors and/or hardware accelerators that are well suited to perform specific processing stages respectively, one embodiment as described hereinafter provides a multi-threaded processing pipeline that offers a very high processing throughput. This requires ensuring that the co-processor(s) or accelerator(s) that is(are) on the critical path is(are) idle for as short a time as possible, while taking care of constraints due to spatial dependencies in the processing chain, internal memory available for buffering, shared memory design (e.g., a particular memory is single ported and can be accessed by only a single accelerator at a time, or a unit capable of parallel processing is restricted by the number of read/write ports), and cycle overheads involved in setting up each co-processor/accelerator.

p-0009In audio compression, redundancy is reduced by exploiting the frequency characteristics of audio data. The raw audio samples are grouped into frames and these frames of data are subject to frequency analysis to extract only those frequencies that would be perceptible to the user. Filtering techniques are employed to reduce the amount of audio data to be coded. This data is further compressed using transform-coding and variable length coding. Such a coding scheme has dependency between the various processing stages. Therefore on a multi-processor environment the challenge lies in designing a multi-threaded processing pipeline that increases the processing throughput. Also the above-mentioned constraints like shared memory design, minimal idle time of the various processing units need to be taken into account to design an efficient processing pipeline for audio processing.

p-0010Described hereinafter by way of example is an architecture that has a DSP (digital signal processor) sub system that consists of a master DSP controlling the co-processors/accelerators, a programmable co-processor with multiple multiply-and-accumulate (MAC) units that are suited for vector/array processing, an optional hardware accelerator tailored for variable length coding/decoding, an optional hardware accelerator tailored for quantization and dequantization of DCT (discrete cosine transform) coefficients, shared memory buffers, and a DMA engine that can move data from/to external memory to/from the shared memory buffers. In the described example, three shared memory buffers are assumed. In some cases, multiple shared memory buffers may all share the same address space, such that only one is visible from the processor/co-processor/DMA (direct memory access) engine.

p-0011It is understood that modifications in the method and the article containing a storage medium as depicted above are possible without departing from the thrust of the inventive process and are within the ambit of the invention. It is also to be understood that acronyms used herein are to be understood as explained in the text, and other acronyms should be understood as commonly known in the art.

BRIEF DESCRIPTION OF THE DRAWING

p-0012Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

p-0013<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a block diagram of a typical video decoder;

p-0014<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a block diagram of a typical video encoder;

p-0015<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a block diagram of a typical audio decoder;

p-0016<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a block diagram of a typical audio encoder;

p-0017<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a block diagram of pipeline flow for a video encoder;

p-0018<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a block diagram of pipeline flow for a video decoder;

p-0019<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a block diagram of pipeline flow for an audio decoder;

p-0020<figref idrefs="DRAWINGS">FIG. 8</figref> shows a general purpose computing arrangement applicable in the invention;

p-0021<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates a block diagram of pipeline flow for an audio encoder.

DETAILED DESCRIPTION OF THE INVENTION

p-0022The description that follows provides a detailed exemplary approach for designing a multi-thread processing operation in an architecture that uses multiple processors and/or hardware accelerators with a view to obtaining improved throughput from the process without foregoing the process requirements and predetermined constraints. Even though the inventive approach is applicable to any general situation wherein multiple processors are used, the embodiments described herein below are directed by way of example and not limitation, to a processing operation involving multimedia processing including video and audio processing.

p-0023<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a block diagram of a typical video decoder including an entropy decoder block <b>101</b> that receives bits. Processing continues with inverse quantization in block <b>102</b>, inverse transform in block <b>103</b>, and motion compensation in block <b>104</b>. Outputs from blocks <b>103</b> and <b>104</b> go to the adder at <b>109</b> and decoded frames <b>108</b> are put out. Decoded frames are also sent to the frame store <b>105</b>. A feedback from frame store <b>105</b> to the motion compensation block <b>104</b> is provided through feedback line <b>106</b>. Additional details of operation of the individual blocks should be intelligible to those skilled in the art.

p-0024<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a block diagram of a typical video encoder in the context of the invention. Input frames arrive at <b>211</b>, and are processed at motion estimation block <b>224</b>, motion compensation block <b>224</b>, forward transform at block <b>212</b>, quantization at block <b>213</b>, inverse quantization at block <b>217</b>, and inverse transform at block <b>219</b>. An adder/mixer at <b>220</b> receives signals from blocks <b>219</b> and <b>221</b> and sends an output to the frame store at <b>222</b>. The motion vector block provides a motion vector output at <b>223</b>. Variable length encoding shown at block <b>215</b> can happen at any stage following quantization and produces bits at <b>216</b>. Additional details of operation of the individual blocks should be intelligible to those skilled in the art.

p-0025<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a typical block diagram of a typical audio decoder wherein an input stream <b>301</b> is decoded at variable length decoding block <b>302</b>, subjected to inverse quantization at block <b>303</b> for further processing. PCM (pulse code modulation) samples are produced at output <b>307</b>. Additional details of operation of the blocks in <figref idrefs="DRAWINGS">FIG. 3</figref> should be intelligible to those skilled in the art.

p-0026<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a block diagram of a typical audio encoder in the context of the invention. Input samples arrive at <b>411</b> and undergo psycho-acoustic modeling at block <b>412</b>. In a parallel path, input samples undergo sub-band analysis at block <b>413</b> and stereo transformation at block <b>414</b>, to proceed to quantization at <b>415</b> and variable length encoding at <b>416</b>. Further details of the individual processes in the blocks of <figref idrefs="DRAWINGS">FIG. 4</figref> are intelligible to those skilled in the art.

p-0027<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an exemplary embodiment of a design pipeline flow for a video encoder showing motion estimation/motion compensation block <b>525</b>, forward transform block <b>526</b>, quantization block <b>528</b>, inverse quantization block <b>529</b>, and variable length encoder block <b>530</b>. <figref idrefs="DRAWINGS">FIG. 5</figref> also shows under direct memory access (DMA) <b>523</b>, three buffers <b>531</b>, <b>532</b>, and <b>533</b>, as well as a digital signal processor <b>524</b> showing rate control updates <b>534</b>. Further details of operation in the blocks of <figref idrefs="DRAWINGS">FIG. 5</figref> will be intelligible to those skilled in the art. The following exemplary design aspects of a video encoder are noted in the context of <figref idrefs="DRAWINGS">FIG. 5</figref>:

h-0007Design Constraints in Video Encoder:

p-0028<ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0027">1) The Motion Estimation for a macroblock can only happen after that of the macroblock preceding it. This is the case since the motion vectors of a macroblock are used as predictors in a succeeding macroblock.</li><li id="ul0002-0002" num="0028">2) In the illustrated example, the following sequence of operations have to occur in the order mentioned: <ul><li id="ul0003-0001" num="0029">Motion Estimation->Motion Compensation->Forward Transform->Quantization->Inverse Quantization->Inverse Transform->Reconstruction. However VL-Encode can happen at any stage following the quantization. <br /> Design of Multi-Thread Pipeline for Video Encoder: <br /> The following exemplary optimizations were carried out in designing the multi-thread pipeline: </li></ul></li><li id="ul0002-0003" num="0030">1) The minimum processing unit was converted to macroblock pairs instead of macroblocks. This step was motivated by two factors; the DMA load and stores from/to frame buffers would take the same time for two adjacent macroblocks or one macroblock. The other advantage gained was flexibility in the motion estimation process: less precise motion estimation could be carried out for every alternate macroblock and this could be configurable.</li><li id="ul0002-0004" num="0031">2) The rate control is used as a feedback mechanism. The bits consumed by a macroblock pair would be used to update the quantizer step-size for the next pair. However since this is the prerogative of the user and not dictated by standards, the feedback was delayed by one pair to allow for better pipeline flexibility.</li></ul></li></ul>

p-0029<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a block diagram of an exemplary embodiment of a design pipeline flow for a video decoder, showing a multi-MAC coprocessor <b>641</b>, and inverse transform/motion compensation buffer <b>645</b>. Also shown under accelerator <b>642</b>, is variable length decode buffer <b>646</b> and inverse quantization buffer <b>647</b>. Shown under DMA <b>643</b>, are buffer <b>648</b> for load reference for motion compensation, and buffer <b>649</b> for store-reconstructed MB. Under DSP <b>644</b> in <figref idrefs="DRAWINGS">FIG. 6</figref> are shown MB level parameter decoder <b>650</b> and motion vector decoder <b>651</b>. Further functional details of the foregoing components are intelligible to those skilled in the art. The following exemplary design aspects are noted for multi-thread pipeline design of video decoder of <figref idrefs="DRAWINGS">FIG. 6</figref>:

h-0008Design Constraints in Video Decoder:

p-0030<ul><li id="ul0004-0001" num="0000"><ul><li id="ul0005-0001" num="0033">1. The Bit-stream parsing for one macro-block can start only after the variable length decoding of the previous MB is done. Within an Intra macro-block the inverse DC-AC prediction for the blocks can not be done in parallel because the prediction depends on the blocks previously decoded</li><li id="ul0005-0002" num="0034">2. The following sequences of operations have to necessarily occur in the order mentioned: <ul><li id="ul0006-0001" num="0035">Seq1: MB-level Parameters Decode->Motion Vectors Decode->VL-Decode.</li><li id="ul0006-0002" num="0036">Seq2: Inverse Quantization->Inverse Transform->Motion Compensation.</li><li id="ul0006-0003" num="0037">Seq1 depends on the bit-stream parsing. So any operation in seq1 for one macro-block cannot be done until all operations in Seq1 for the previous macro-block are over. <br /> Design of multi-thread pipeline for video-decoder: (1). The design pipeline is spread over 3 MBs. (2). The various tasks have been scheduled on different processors as shown in <figref idrefs="DRAWINGS">FIG. 6</figref>. </li></ul></li></ul></li></ul>

p-0031<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a block diagram of an exemplary embodiment of a pipeline design flow for an audio decoder, showing under multi-MAC coprocessor <b>701</b>, three buffers, i.e., signal processing buffer <b>702</b>, IMDCT (inverse modified discrete cosine transform) and windowing buffer <b>703</b>, and sub-band synthesis group buffer <b>704</b>. Shown in <figref idrefs="DRAWINGS">FIG. 7</figref> under DMA <b>705</b> are three buffers, i.e., DMA for input stream buffer <b>706</b>, DMA for IMDCT Tables buffer <b>707</b>, and DMA fir Window for sub band synthesis buffer <b>708</b>. Also shown in <figref idrefs="DRAWINGS">FIG. 7</figref> under DSP <b>709</b> are buffers, Huffman decode granule <b>0</b> buffer <b>710</b>, re-quantize spectrum buffer <b>711</b>, alias reduction buffer <b>712</b>, recorder spectrum buffer <b>713</b>, and Huffman decode granule <b>1</b> buffer <b>714</b>. The functional details of the foregoing components will be intelligible to those skilled in the art. The following are exemplary design aspects of a design for a multi-thread pipeline design for an audio decoder of <figref idrefs="DRAWINGS">FIG. 7</figref>:

h-0009Design Constraints in Audio Decoder:

p-0032<ul><li id="ul0007-0001" num="0000"><ul><li id="ul0008-0001" num="0039">1. The Bit-stream parsing for one frame/channel/granule can start after the variable length decoding of the previous frame/channel/granule is done.</li><li id="ul0008-0002" num="0040">2. The following sequences of operation have to occur in the order mentioned: <ul><li id="ul0009-0001" num="0041">Seq1: Header Parameters Decode->VL-Decode.</li><li id="ul0009-0002" num="0042">Seq2: Inverse Quantization->Inverse Transform->windowing.</li><li id="ul0009-0003" num="0043">Seq1 depends on the bit-stream parsing. So any operation in seq1 for one frame/channel/granule cannot be done until all operations in Seq1 for the previous frame/channel/granule are over. <br /> Design of Multi-Thread Pipeline: <br /> The following exemplary optimizations were carried out in designing the multi-thread pipeline: </li></ul></li><li id="ul0008-0003" num="0044">1) The minimum processing unit was converted to frames and the multi-threading was carried out at the level of granule or channel.</li></ul></li></ul>

p-0033Most of the filtering operations like polyphase filtering, windowing and inverse transform require staggered accesses of the input data and tables. These processing blocks were converted into a form where they can be written in the form of linear filters by either padding the coefficients to use circular addressing or by collapsing two processing stages to a single stage such that the access becomes linear or circular.

p-0034<figref idrefs="DRAWINGS">FIG. 9</figref> shows a block diagram of an audio encoder used in the context of the invention. As shown, the audio encoder has a co-processor <b>901</b>, psycho analysis buffer <b>902</b>, MDCT buffer <b>904</b>, and a stereo processing buffer <b>905</b>. The audio encoder includes a DMA having the components DMA i/p samples buffer <b>907</b>, DMA window coefficient buffer <b>908</b>, DMA MDCT coefficients buffer <b>909</b>, and a DMA Huffman tables buffer <b>910</b>. Also included in the audio encoder of <figref idrefs="DRAWINGS">FIG. 9</figref> are Huffman-encode-for previous frame buffer <b>912</b>, rate control <b>913</b> without a buffer, and a quantization buffer <b>914</b>. Functional details and typical architecture of the foregoing components are intelligible to those skilled in the art. With respect to an inventive embodiment directed to an audio encoder, the following design aspects applicable for multi-thread design pipeline are to be noted:

h-0010Design Constraints in Audio Encoder:

p-0035<ul><li id="ul0010-0001" num="0000"><ul><li id="ul0011-0001" num="0047">1. The bit allocation for one frame can happen only after the encoding of the previous frame has been completed.</li><li id="ul0011-0002" num="0048">2. The following sequence of operations have to necessarily occur in the order mentioned: <ul><li id="ul0012-0001" num="0049">Psycho acoustic modeling->Filtering (masking)->sub band decomposition->Transform->Quantization->VL encoding. <br /> Design of Multi-Threaded Pipeline for Audio Encoder: <br /> The following optimizations were carried out in designing the multi-thread pipeline: </li></ul></li><li id="ul0011-0003" num="0050">1) The minimum processing unit was converted to frames and the multi-threading was carried out at the level of granule or channel.</li><li id="ul0011-0004" num="0051">2) Most of the filtering operations like polyphase filtering, inverse transform and windowing require staggered accesses of the input data and tables. These processing blocks were converted into a form where they can be written in the form of linear filters by either padding the coefficients to use circular addressing or by collapsing two processing stages to a single one such that the access becomes linear or circular.</li></ul></li></ul>

p-0036In light of the foregoing illustrations and description, an exemplary method for selecting a multi-threaded processing pipeline design for architecture as described above works as follows: <ul><li id="ul0013-0001" num="0053">1. The various processing stages that need to happen on a basic processing unit are identified along with their inter-dependencies. Multiple mutually exclusive modes are identified at this stage and are statistically characterized in terms of how often they occur. Data movements from external memory to the shared buffers are modeled as processing stages that will happen on the DMA unit. For example, <figref idrefs="DRAWINGS">FIGS. 1 and 2</figref> show the various processing stages for a video decoder and a video encoder respectively, where the basic processing unit is a macroblock. An example of mutually exclusive modes is, in a video decoder, whether a macroblock is intra-coded or inter coded, which will decide whether AC/DC prediction should happen or motion compensation processing should happen. Similarly in audio decoding the joint stereo processing modes may be absent or may be based on based on the modes that may go through a different processing stage. <figref idrefs="DRAWINGS">FIGS. 3 and 4</figref> show the basic processing blocks for an audio decoder and encoder respectively.</li><li id="ul0013-0002" num="0054">2. Each processing stage is assigned to a particular processing unit (DSP/co-processor/hardware accelerator) based on the suitability and flexibility. Multiple candidates, if found suitable, are identified for later flexibility in scheduling. For example, a multi-MAC co-processor may be ideally suited for computations such as filtering, transforms, mean squared error computation, etc. Similarly from the flexibility point of view, frozen (or normative) parts of a compression standard, can be implemented in a hardware accelerator and non-normative parts (where newer algorithms can be invented) can be kept on a programmable co-processor.</li><li id="ul0013-0003" num="0055">3. Given the inter-dependency between the processing stages, stagger the processing such that all algorithmic dependencies are handled. This means that stages down in the dependency chain may be made to work on past basic units while the stages up in the dependency chain are working on newer basic units. For example, in video encoding, this would mean that motion estimation could be applied on macroblock N, while quantization of DCT coefficients is applied on macroblock N-1, and so on. Similarly for audio decoding the various processing operations like poly-phase filtering, transform, windowing can be applied for left channel/granule when Huffman decoding is applied for right channel/granule.</li><li id="ul0013-0004" num="0056">4. Each processing stage on each processing unit is assigned a suitable buffer, for example, based on the constraints that (a) no two units can access the same buffer at the same time and (b) of the three buffers, two buffers are visible mutually exclusively (i.e., each unit can see only one of these two at a given time).</li><li id="ul0013-0005" num="0057">5. For some stages, the complexity is fixed and hence the time taken will be the same. For other stages, the complexity can vary and hence the time taken will also vary. The time taken for the fixed complexity stages and the average time and range of time taken for the varying complexity stages are measured on the respective mapped processing units. Depending on the number of read and write ports on each shared buffer, the time taken will be affected if both read and write happen from the same buffer.</li><li id="ul0013-0006" num="0058">6. Explore the granularity of processing in multiples of the basic unit and select the one that gives the best performance while meeting the platform constraints and dependency constraints. The factors that would influence this include, the savings stemming from going to that granularity, the ability to exploit statistical properties in a reasonably straight-forward fashion, and the amount of memory required in the shared buffers. For example, in video, the granularity could be, say, a macroblock or a group of macroblocks. Similarly in audio, the granularity could be at the level of a frames or channels or granules.</li><li id="ul0013-0007" num="0059">7. Identify the several variations in the staggering that are possible without breaking the dependencies and platform constraints. Some changes in the buffer assignments from step <b>4</b> above and the multiple processing unit options for performing a particular processing stage are attempted at this stage. These changes will affect the average timing for processing and need to be properly accounted for. Select a subset of these possible pipelines that offer the best timing (based on the average processing time) for processing at the chosen granularity.</li><li id="ul0013-0008" num="0060">8. Of these selected pipelines, a single pipeline is chosen based on its ability to offer the best overall timing in the presence of statistical variations. For instance, when a particular processing stage has to process N units of data, the worst case may be where the average number of units is m (m=N/2). In a particular pipeline, there may be certain other processing stages scheduled on the other processing units in parallel to the above such that it would not matter whether m units or N units need to be processed. On the other hand, there could be a pipeline where there was processing only in parallel with the first N/2 units and hence can translate to an overall timing reduction on the average.</li><li id="ul0013-0009" num="0061">9. On the chosen pipeline, identify the processing unit that is on the critical path and, if possible, move some tasks that are currently scheduled on this unit and that could be performed on other units.</li></ul>

p-0037The following advantageous features of the embodiments described hereinabove are to be noted:

p-0038Common to Audio and Video Encoder and Decoders: <ul><li id="ul0014-0001" num="0000"><ul><li id="ul0015-0001" num="0064">1. Multi-threaded pipeline spanning multiple macroblocks (or frame/channel/granule for audio)—setting up dependent data flow over time, breaking up of the various tasks at a sufficient granularity, mapping specific tasks to suitable co-processors (either based on the speedup it offers or the idle time available for further processing), moving around independent tasks to suitable slots in the pipeline to minimize the idle time of co-processors or accelerators on the critical path.</li><li id="ul0015-0002" num="0065">2. Some processing blocks take the same number of cycles every time. However, several processing blocks take a variable number of cycles depending on the complexity of the coding mode. Design of an efficient multi-threaded pipeline in the presence of such variability by (a) pairing tasks on the different units such that the load is roughly balanced, (b) reducing the variability (algorithmically or structurally), is possible.</li><li id="ul0015-0003" num="0066">3. Pre-fetching the necessary data from external memory over DMA to reduce the waiting time.</li><li id="ul0015-0004" num="0067">4. Optimal management of the two image-buffers and the coefficient buffer, given the data dependencies, access constraints and conflict factors. <ul><li id="ul0016-0001" num="0068">Given a limited size for these buffers, designing a desirable macroblock pipeline depth.</li><li id="ul0016-0002" num="0069">Trading off redundant data movements for efficient relocation of processing tasks.</li><li id="ul0016-0003" num="0070">Trading losses in conflict factor for keeping more processing units active at a given time.</li></ul></li><li id="ul0015-0005" num="0071">5. Data arrangements (packed/unpacked, raster-scanned blocks, coefficient preparation for edge handling through reflection, padding, or circular access, etc.) to exploit the order in which the multiple MACs access data like padding the filter coefficients to map from staggered addressing to a regular circular addressing for audio decode.</li><li id="ul0015-0006" num="0072">6. Creating pre-determined sets of command sequences for the programmable co-processor to reduce dynamic setup overhead costs. <ul><li id="ul0017-0001" num="0073">Minimize the number of setups needed from the master DSP by manipulating the control sequence on the co-processors without DSP intervention.</li><li id="ul0017-0002" num="0074">Minimize the number of setup parameters by only configuring the parameter that changes over time.</li></ul></li></ul></li></ul>

p-0039Advantageous Features Applicable to the Pipeline Design Video Encoder Include: <ul><li id="ul0018-0001" num="0000"><ul><li id="ul0019-0001" num="0076">1. Conditional pipeline that is able to realize an overall processing throughput gain even though certain processing steps are skipped on only one or two co-processors or accelerators (e.g., 3-step ME, CBP-based IDCT or inverse quantization, predicted-as-not-coded, and based skipping).</li><li id="ul0019-0002" num="0077">2. Modifying the macroblock level rate control to run with the multi-threaded macroblock pipeline assumptions (bits consumed from 2 processing units behind, cycle reduction through less precise divisions).</li><li id="ul0019-0003" num="0078">3. Modifying motion estimation to suit the processing constraints (e.g., alternate MB processing, half-pel off, etc.) and memory constraints (e.g. filling entire image buffer with search area for 2 MBs, incremental DMA with circular addressing, and using both image buffers to expand search range.)</li></ul></li></ul>

p-0040Various embodiments of the present subject matter can be implemented in software, which may be run in the exemplary environment shown in <figref idrefs="DRAWINGS">FIG. 8</figref> (to be described below) or in any other suitable computing environment. The embodiments of the present subject matter are operable in a number of general-purpose or special-purpose computing environments. Some computing environments include personal computers, general-purpose computers, server computers, hand-held devices (including, but not limited to, telephones and personal digital assistants (PDAs of all types), laptop devices, multi-processors, microprocessors, set-top boxes, programmable consumer electronics, network computers, minicomputers, mainframe computers, distributed computing environments and the like to execute code stored on a computer-readable medium. The embodiments of the present subject matter may be implemented in part or in whole as machine-executable instructions, such as program modules that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures and the like, to perform particular tasks or to implement particular abstract data types. In a distributed computing environment, program modules may be located in local or remote storage devices.

p-0041<figref idrefs="DRAWINGS">FIG. 8</figref> shows an example of a suitable computing system environment for implementing embodiments of the present subject matter. <figref idrefs="DRAWINGS">FIG. 8</figref> and the following discussion are intended to provide a brief, general description of a suitable computing environment in which certain embodiments of the inventive concepts contained herein, and particularly, multi-threaded processing pipeline design in an architecture using multiple coprocessors may be implemented.

p-0042A general computing device in the form of a computer <b>810</b> may include a processing unit <b>802</b>, memory <b>804</b>, removable storage <b>812</b>, and non-removable storage <b>814</b>. Computer <b>810</b> additionally includes a bus <b>805</b> and a network interface (NI) <b>801</b>. Computer <b>810</b> may include or have access to a computing environment that includes one or more user input devices <b>816</b>, one or more output devices <b>818</b>, and one or more communication connections <b>820</b> such as a network interface card or a USB (universal serial bus) connection. The one or more user input devices <b>816</b> can be a touch-screen or a stylus and the like. The one or more output devices <b>818</b> can be a display device of computer, computer monitor, TV screen, plasma display, LCD display, display on a touch screen, display on an electronic tablet, and the like. The computer <b>810</b> may operate in a networked environment using the communication connection <b>820</b> to connect to one or more remote computers. A remote computer may include a personal computer, server, router, network PC, a peer device or other network node, and/or the like. The communication connection may include a Local Area Network (LAN), a Wide Area Network (WAN), and/or other networks.

p-0043The memory <b>804</b> may include volatile memory <b>806</b> and non-volatile memory <b>808</b>. A variety of computer-readable media includes the memory elements of computer <b>810</b>, such as volatile memory <b>806</b> and non-volatile memory <b>808</b>, removable storage <b>812</b> and non-removable storage <b>814</b>. Computer memory elements can include any suitable memory device(s) for storing data and machine-readable instructions, such as read only memory (ROM), random access memory (RAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), hard drive, removable media drive for handling compact disks (CDs), digital video disks (DVDs), diskettes, magnetic tape cartridges, memory cards, Memory Sticks™, and the like. Alternatively, it can be chemical storage, biological storage, or other types of data storage.

p-0044“Processor” or “processing unit,” as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, explicitly parallel instruction computing (EPIC) microprocessor, a graphics processor, a digital signal processor, or any other type of processor or processing circuit. The term also includes embedded controllers, such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, smart cards, and the like.

p-0045Embodiments of the present subject matter may be implemented in conjunction with program modules, including functions, procedures, data structures, application programs, etc., for performing tasks, or defining abstract data types or low-level hardware contexts. Machine-readable instructions stored on any of the above-mentioned storage media are executable by the processing unit <b>802</b> of the computer <b>810</b>. For example, a computer program <b>825</b> may include machine-readable instructions capable of implementing multi-thread processing pipeline design according to the teachings and herein described embodiments. In one embodiment, the computer program <b>825</b> may be included on a CD-ROM and loaded from the CD-ROM to a hard drive in non-volatile memory <b>308</b>. The machine-readable instructions cause the computer <b>810</b> to decode according to the various embodiments of the present subject matter.

p-0046The various embodiments of the multi-threaded processing pipeline design approach described herein are applicable generally to any parallel processing system, and the embodiments described herein are in no way intended to limit the applicability of the invention. In addition, the techniques of the various exemplary embodiments are useful to the design of any hardware implementations of software, firmware, and algorithms in the context of processing design in general. Many other embodiments will be apparent to those skilled in the art. The scope of this invention should therefore be determined by the appended claims as supported by the text, along with the full scope of equivalents to which such claims are entitled.