Patent Grant
8732382
This invention relates to Direct Memory Access (“DMA”) engines. More particularly, the invention concerns an architected DMA that is part of the process state of a processor.
Traditionally, DMAs have been treated as peripheral devices. As peripheral devices, DMAs have not been considered or treated as a part of the architected state for a processor, such as a personal computer, personal data assistant (“PDA”), cell phone, or other device that is processor-based and typically would include one or more DMAs.
Since DMAs traditionally have been excluded from the architected state of a processor, in a multi-programmed environment, the DMA engine is not considered a part of the process state. Accordingly, the DMA must be accessed via a monitor, possibly within the operating system.
Accessing a DMA separately from other components included in the architected state increases the latency to access the DMA. As should be appreciated by those skilled in the art, an increase in latency for a device like a DMA makes the DMA impractical for use in a process, especially when the process incorporates small moves or operations. Simply, for small operations, the latency time associated with traditional DMA architecture may so greatly increase the overall processing time for an operation, that reliance on the DMA is impractical.
As should be appreciated by those skilled in the art, there is always a need in the computer processing art to increase processing efficiency.
The invention offers at least one approach to increasing processing efficiency.
Specifically, the invention offers an architected DMA that is part of the process state. The DMA may be stopped and restarted, permitting a copy operation to be halted and resumed without a significant detrimental processing effect on the DMA.
The invention provides a method of operating a direct memory access engine. In the method, copying is initiated for a first number of bytes. The first number of bytes are to be copied from first source memory locations to first destination memory locations. After initiating the copying, a halt instruction is issued before the first number of bytes are copied. In response to the halt instruction, the copying is stopped. As a result, a second number of bytes is established. The second number of bytes are those bytes remaining to be copied from the first number of bytes. After the transfer is halted, a quantity of the second number of bytes is identified. Quantity information, which provides the quantity of the second number of bytes, is then generated and stored. Second source memory locations also are identified. The second source memory locations identify where the second number of bytes are stored. Second source memory location information is then generated and stored. Second destination memory locations are then identified. The second destination memory locations identify where the second number of bytes are to be transferred. Second destination memory location information is then generated and stored.
In one contemplated variation of this method, the quantity information, the second source memory location information, and the second destination memory location information are retrieved from at least one register in the direct memory access engine. One register or several registers may be used. Where there are several registers, one may be a source register, another may be a destination register. A third register may be a quantity register.
The method may also include resuming the halted transfer by initiating copying of the second number of bytes from the second source memory locations to second destination memory locations using the quantity information, the second source memory location information, and the second destination memory location information.
With respect to this method, there are a number of variations contemplated for re-initiating the copy operation after issuance of the halt instruction.
In one contemplated embodiment, the method provides for determining a next address to read from the second source memory location information and determining a next address to write from the second destination memory location information. Then, the method flushes all pending reads and writes. The method proceeds by determining, from the next address to read and the next address to write, a decrement value. The decrement value identifies a number of bytes by which the next address to read is in advance of the next address to write. The method then decrements the next address to read by the decrement value to generate a decremented read address. Copying the second number of bytes from the second memory locations to the second memory then destinations then proceeds based at least upon the decremented read address, the next address to write, and the quantity information.
In a second contemplated variation, the method includes determining a next address to read from the second source memory location information and determining a next address to write from the second destination memory location information. The method tracks the number of bytes by which the next address to read is in advance of the next address to write and establishes a run-ahead value. The run-ahead value is stored so that the next address to read may be adjusted by the run-ahead value. This permits generation of an adjusted next address to read. Copying then proceeds based at least upon the adjusted next address to read, the next address to write, and the quantity information.
In a third contemplated variation, the method contemplates determining a next address to read from the second source memory location information and determining a next address to write from the second destination memory location information. Copying of the second number of bytes from the second memory locations to the second memory destinations proceeds using the next address to read, the next address to write, and the quantity information.
In a fourth contemplated variation of the method, an identification of the first source memory locations, an identification of the first destination memory locations, and a count of the first number of bytes are retained. After retrieving the quantity information, a next address to read is established, at least based upon the identification of the first source memory locations, the count of the first number of bytes, and the quantity information. Then, a next address to write is established at least based upon the identification of the first destination memory locations, the count of the first number of bytes, and the quantity information. Copying of the second number of bytes from the second memory locations to the second memory destinations relies at least upon the next address to read, the next address to write, the count of the first number of bytes, and the quantity information.
In a fifth contemplated variation, an indication of the next address to write is retained. After issuance of the halt instruction, reading of the first number of bytes from the first source memory locations is stopped. In addition, writing continues for any of the bytes that remain from the bytes read before stopping the reading. Then, a next address to read from the second source memory location information and a next address to write from the second destination memory location information are determined. Copying of the second number of bytes from the second memory locations to the second memory destinations relies at least upon the next address to read, the next address to write, and the quantity information.
Other aspects of the invention will be made apparent from the discussion that follows and from the drawings appended hereto.
The invention is described in connection with drawings that illustrate one or more aspects, in which:
The invention is described in connection with specific embodiments and examples detailed below. The invention, however, is not intended to be limited solely to the embodiments and examples discussed. To the contrary, the embodiments and examples are intended to define the broad scope of the invention. As should be appreciated by those skilled in the art, there are numerous equivalents and variations of the embodiments and examples that may be employed without departing from the scope of the invention. Those embodiments and variations are intended to be encompassed by the invention.
As a preliminary matter, and as should be appreciated by those skilled in the art, DMA engines are used to copy values from one location in memory to another. At their simplest, DMA engines copy values from some contiguous block of memory to some other block. One example of this basic copy function of a DMA engine is provided by Code Segment #1, below.
To use a simple DMA from a processor, typically the processor writes the source address, destination address, and the transfer size to selected registers. The processor then initiates the transfer by writing to a control register. When all the values have been copied, the DMA signals the completion of the transfer by writing to a control and/or a status register and/or triggering an interrupt in the processor.
More sophisticated DMAs are capable of operations such as “scatter” operations. “Scatter” refers to an operation whereby a single procedure call sequentially reads data from a single data stream to multiple buffers. A scatter operation may be written in code as set forth in Code Segment #2, below.
“SRC” refers to the address of the source. “DST” refers to the address of the destination. “OFF” refers to the address of the offset array.
In one contemplated embodiment, a scatter operation takes data from a plurality of source memory locations and “scatters” the data to a number of destination memory locations. As indicated above, a scatter operation also may operate from a single data stream, which streams data from a plurality of source memory locations. If so, the scatter operation may include a number of data manipulations. Specifically, such a scatter operation may: (1) read a sequential data stream of data to be copied, (2) read a sequential address stream or an index stream, and (3) if using an index stream, create an address stream by adding each index to a single base address. Each element in the data may then be copied to a corresponding address in the stream. It is noted that these operations are not required for all scatter operations but are provided merely as guidance for those skilled in the art and to assist with an understanding of one aspect of the invention.
More sophisticated DMAs also are capable of specific operations, referred to as “gather” operations. “Gather” operations are those operations where a single procedure call sequentially writes data from a multiple buffers to a single data stream. A gather operation may be written in code as set forth in Code Segment #3, below.
As with Code Segment #2, “SRC” refers to the address of the source. Similarly, “DST” refers to the address of the destination. Additionally, “OFF” refers to the address of the offset array.
With respect to “gather” operations, the information may be gathered from a plurality of source memory locations. The data may then be provided to a plurality of destination memory locations, perhaps via a scatter algorithm. Alternatively, the data may be gathered and funneled to a single data stream for further processing. As should be appreciated by those skilled in the art, a gather operation does the opposite of a scatter operation, at least in some ways. For example, a gather operation may: (1) read either an address stream or a an index stream and generate an address stream by adding it to a base, or (2) read the data from the locations in the address stream, creating a sequential data stream. The sequential data stream may then be copied sequentially to the destination(s). This discussion is provided to clarify at least this one aspect of the invention. It is not intended to be limiting of the invention.
In addition, more sophisticated DMAs are capable of “multi-level” operations. Multi-level operations are those where data from multiple sources are read from and/or written to multiple destinations. A multi-level operation may be written in code as set forth in Code Segment #4, below.
As with Code Segments ##2 and 3, “SRC” refers to the address of the source. “DST” refers to the address of the destination. “OFF” refers to the address of the offset array.
Scatter, gather, and multi-level operations may be combined to generate still further functions, as should be appreciated by those skilled in the art. Accordingly, further details concerning these functions are not provided here.
Context Switch
Once again with reference to the typical DMA engine, after the engine initiates a transfer, the engine runs to completion. The DMA engine then signals the processor that the transfer has been completed. Following this, the DMA engine executes a second transfer. The process is repeated as needed. As should be appreciated by those skilled in the art, this is but one way to describe the operation of a DMA engine.
There are other ways to setup DMAs and series of DMAs. For example, some DMAs support the use of “shadow registers”. A shadow register permits a DMA to be programmed with the next transfer while the current DMA transfer is “in-flight” or in process. The shadow register, therefore, facilitates the next transfer because the DMA may start the next transfer as soon as the current transfer is completed. Other DMAs support “chaining”. This approach differs from the shadow register approach. Instead of programming the DMA directly, a control block is written with the details of the transfer. The next transfer is written to a control block, and a location in the first control block is set to point to this next transfer. In this manner, a chain of transfers may be established. As soon as the DMA completes the transfer determined by a control block, it proceeds to execute the transfer determined by the next block in the chain.
As should be apparent to those skilled in the art, these alternative set-ups also suffer from the same problems noted with respect to DMAs generally. In particular, DMAs are not well suited to execute all types of operations because of several deficiencies, including the aforementioned latency issues. For example, the existing architecture for DMAs provides no mechanism to suspend an ongoing transfer, to program and execute a new transfer, and then to resume the suspended transfer. In addition, if multiple sources try to program a DMA engine, these sources must coordinate efforts to the DMA engine to prevent simultaneous access or to prevent multiple instructions from overwriting one another.
To facilitate understanding of the deficiencies in the prior art with respect to DMAs, the following example is provided. Specifically, the example encompasses an instance where the DMA is to be used to execute data transfers on a general purpose processor. To simplify the example, it is assumed that all memory accesses are in a real-mode. Real-mode operation is assumed to avoid the complications that arise when programming for virtual memory, as should be understood by those skilled in the art. Specifically, by ignoring virtual memory in this example, the complications introduced by virtual memory translation are also avoided. For this example, several problems arise, as detailed below.
The first problem may arise in the context of a transfer process that is interrupted and the context is switched to another transfer operation. Specifically, if the transfer process is interrupted during the interval when the DMA is being programmed but before the DMA writes to the control register, the DMA registers must be saved as part of the process state. As a result, before the transfer operation may be resumed, the DMA registers must be recreated (or “written back” to the appropriate addresses).
The second problem that may arise concerns processes that program long-running DMAs. As may be immediately apparent, when a process programs a long-running DMA and the process is then context-switched, the new process must await completion of the first transfer process before being executed. As a result, the execution of the first transfer operation stalls the execution of the second transfer operation.
A third problem that may arise with respect to DMA processing arises in the context of a multi-threaded or multi-processor environment. Specifically, in a multi-threaded or multi-processor machine, multiple processes simultaneously may try to reprogram the DMA. Since only one process may proceed at any given time, the multiple processes require execution of a mutual exclusion algorithm. As should be appreciated by those skilled in the art, mutual exclusion algorithms increase the latency period associated with programming the DMA.
The fourth problem that may arise concerns the generation of an interrupt signal by the DMA, which may be issued at the conclusion of a transfer operation. Specifically, when a DMA signals completion of a transfer operation by means of an interrupt, there is no guarantee that the process that programmed the DMA is the currently-running process. Consequently, when issued, the completion interrupt must be captured by a shared interrupt handler, which decides if the currently-running process is the process to which the interrupt must be delivered.
If the processor uses virtual memory, additional problems arise, because the DMA engine must translate between virtual and real addresses. It is contemplated that the operating system may be employed to translate the desired transfer into real addresses, and pin the source and target pages. However, reliance on the operating system for this translation dramatically increases the latency to initiate a DMA. Lighter-weight schemes (i.e., less latency-burdened schemes) typically rely on virtual addresses in the DMA. These schemes run the DMA transfer addresses through the processor's translation mechanism for operation. A problem with this approach is that, after a context switch, the processors translation mechanism may not be valid for the previous process. As a result, there must be a method for stopping the DMA to avoid conflicts in processing.
Each of these problems present challenges in the execution of transfer operations by a DMA. The invention offers solutions for these problems.
Restartable Stop
The present invention offers a restartable stop of a block-transfer DMA. A restartable stop of a block-transfer DMA is one where it is possible to stop the DMA in mid-transfer. Once the transfer has been stopped, it is then possible to determine: (1) how many bytes are left to be transferred, (2) the address of the next byte to be read, and (3) the address of the next byte to be written. This approach may be implanted simply by reading the control registers of the DMA. Other possible implementations are also contemplated.
Simple
The first variation presented by the invention is referred to as the “simple” implementation. In the simple implementation, copies of the initial values of the source, destination, and byte count are retained, along with a count of the number of the written bytes. Since this information is retained, a restart state of the DMA transfer operation may be determined by adding and/or subtracting the initial values to or from the transferred byte count. As should be appreciated by those skilled in the art, this simple approach is inefficient. One reason for this inefficiency is that the implementation of the DMA requires the system to keep track of the next byte to read and/or to write.
Drain
The second variation presented by the invention is referred to as the “drain” implementation. In this implementation, the DMA keeps a running count of the next address to read and/or to write. The DMA also keeps track of the number of bytes remaining to be read. When stopped mid-transfer, the DMA stops reading and waits for the bytes that have already been read to be written to memory. Once the bytes have been written to memory, the DMA is placed into a restartable state, from which the DMA may complete the transfer operation. As should be apparent, this implementation suffers from at least one disadvantage. Specifically, all pending reads must be written before the DMA is in a restartable state. This arrangement is likely to result in latencies during execution of the transfer operation.
Early Stop
The third variation presented by the invention is referred to as the “early stop” implementation. In this implementation, the DMA keeps a running count of the next address to read and/or to write. The DMA also retains the number of bytes left to write. When the DMA is stopped mid-transfer, the DMA stops writing and flushes all pending reads and/or writes. Generally, in this embodiment, the read address runs ahead of the write address (i.e., more bytes have been read than written). Consequently, the read address must be decremented by the amount of bytes that the read address is ahead of the write address. This approach does not suffer from the kinds of disadvantages discussed in connection with the first two approaches and, therefore, is proffered as one attractive approach for implementation of the present invention.
Run-Ahead
The fourth variation is referred to as the “run-ahead” implementation. This implementation is similar to the early stop implementation, except that a separate register (i.e., an extra register) is used to keep track of how far the read address is ahead of the write address (i.e., the difference between the number of bytes read and written). This value is referred to as the “run-ahead” value. Since the run-ahead value is generally small, the extra register may be implemented fairly easily and cheaply. In other words, although the extra register is required for the run-ahead approach, the additional register does not add significantly to the overall “cost” associated with operation of the DMA. In this implementation, to recover the restart state, the processor subtracts the run-ahead value from the read address to obtain the correct restart read address.
Offset State
As discussed above, DMAs may implement both scatter and gather operations. When a DMA is engaged in a scatter and/or a gather, the reading of the offsets tends to run ahead of the reads and/or writes of the data. To recover the restart state of the offset, then, it is necessary to use some variation of the early stop or run-ahead techniques described above.
Architected Registers
Traditionally, DMAs have been treated as peripherals, and consequently, the DMA registers have been accessed either through load and/or store operations or through special input and/or output instructions.
Since one goal of the invention is to make the DMA a part of the processor context, the DMA registers part are made a part of the architected register state of the processor. In the invention, the DMA registers are special-purpose registers accessible through the same instructions as other special purpose registers.
With respect to the various embodiments of the invention discussed above, reference is now made to the figures appended hereto. With respect to the figures, it is possible that any of the operations identified may encompass one or more steps. Moreover, different operations may be combined into a single step in some instances. These possibilities are intended to be encompassed by the invention.
As may be appreciated from
As a preliminary matter, the various embodiments of the restart operation encompass a continuation of the halted copying process. In this regard, the copying process continues as before. In the resumed copying operation, the second bytes are copied from the source locations to the destination locations. How the copying is resumed underlies aspects of the embodiments that are described in connection with
For the method 44, it is contemplated that the quantity information, the second source memory location information, and the second destination memory location information are read from at least one register in the direct memory access engine. Since the three types of information are being retrieved from a register, the DMA engine is not required to access a memory location. As a result, the DMA engine may proceed more rapidly to resume the halted copying operation than it would if memory locations were to be accessed. As should be apparent to those skilled in the art, efficient processors are designed to avoid memory accesses, where prudent. Access to memory typically accounts for the longest delays when executing instructions.
As noted above, the quantity information, the second source memory location information, and the second destination memory location information may be read from at least one register. In one contemplated embodiment, the three types of information may be read from a single register. However, other variations are also contemplated. For example, several registers may be employed. This includes two or more registers. The two or more registers may include at least one source register in which the first source memory locations are retained and at least one destination register in which the first destination memory locations are retained. In addition, the two or more registers may encompass a quantity register in which the quantity information is retained.
Returning to
As noted in the discussion above, there are several different embodiments by which copying of the bytes from the source locations to the destination locations may be made once the copying operation is resumed. The first embodiment refers the “early stop” method 58. A flow chart for the early stop method 58 is provided in
With reference to
The method 58 begins at 60. From 60, the method 58 proceeds to 62, where a next address to read from the second source memory location information is determined. The method 58 then proceeds to 64 where a next address to write from the second destination memory location information is determined. All pending reads and writes are then flushed at 66. This means that all of the pending reads and writes are deleted. From 66, the method 58 proceeds to 68, where a decrement value is determined from the next address to read and the next address to write. The decrement value identifies a number of bytes by which the next address to read is in advance of the next address to write. At 70, the next address to read is decremented by the decrement value, thereby generating a decremented read address. Once this decrement read address is determined, the copying operation may resume. Specifically, the second number of bytes may be copied from the second memory locations to the second memory destinations based at least upon the decremented read address, the next address to write, and the quantity information. The method 58 ends at 72.
In the method 74, tracking is provided for a run-ahead value. The run ahead value is the number of bytes by which the next address to read is in advance of the next address to write. By tracking this information, a run-ahead value may be established at 82. The run-ahead value is stored at 84. So that the DMA engine may resume the copying operation, the run-ahead value is retrieved at 86. Obviously this operation occurs at a subsequent time, when it is appropriate to resume the copying operation. Finally, at 88, the next address to read is adjusted by the run-ahead value, thereby generating an adjusted next address to read. Once the next address to read has been determined the method 74 may proceed to resume the halted copying operation. Copying of the second number of bytes from the second memory locations to the second memory destinations then proceeds based at least upon the adjusted next address to read, the next address to write, and the quantity information. The method 74 ends at 90.
With reference to
As illustrated in
As noted above, the method of the invention may be applied in the context of scatter and/or gather operations. In the gather context, the method may include an operation where the first number of bytes are retrieved from the first source memory locations, which are distributed in a plurality of buffers. Then, the first number of bytes may be buffered into a single data stream. A scatter operation may be employed after this. If so, the method may include the additional operation of providing the first number of bytes to the first destination memory locations from the single data stream. In this context, the first destination memory locations may be distributed in a plurality of buffers. Alternatively, a gather operation may pull information from a plurality of first destination memory locations directly. Distribution may then be directed to a plurality of buffers.
As noted above, the invention has been described in connection with several specific embodiments. It is not intended for the invention to be limited solely to the embodiments described. To the contrary, the invention is intended to encompass any equivalents and variations, as should be apparent to those skilled in the art.
The present application is the U.S. National Phase of International Application PCT/US2009/0052794, filed Aug. 5, 2009, which claims priority benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application Ser. No. 61/086,631, filed on Aug. 6, 2008, the contents of which are incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2009/052794 | 8/5/2009 | WO | 00 | 7/1/2011 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2010/017263 | 2/11/2010 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 5251312 | Sodos | Oct 1993 | A |
| 5325489 | Mitsuhira et al. | Jun 1994 | A |
| 5420984 | Good et al. | May 1995 | A |
| 5481756 | Kanno | Jan 1996 | A |
| 5497501 | Kohzono et al. | Mar 1996 | A |
| 5623622 | Yuki et al. | Apr 1997 | A |
| 5778002 | Werle | Jul 1998 | A |
| 5822553 | Gifford et al. | Oct 1998 | A |
| 6065071 | Priem et al. | May 2000 | A |
| 6330631 | Crosland | Dec 2001 | B1 |
| 6473780 | Barcelo | Oct 2002 | B1 |
| 6629213 | Sharma | Sep 2003 | B1 |
| 6842848 | Hokenek et al. | Jan 2005 | B2 |
| 6889278 | Hoerler et al. | May 2005 | B1 |
| 6904511 | Hokenek et al. | Jun 2005 | B2 |
| 6912623 | Hokenek et al. | Jun 2005 | B2 |
| 6925643 | Hokenek et al. | Aug 2005 | B2 |
| 6968445 | Hokenek et al. | Nov 2005 | B2 |
| 6971103 | Hokenek et al. | Nov 2005 | B2 |
| 6990557 | Hokenek et al. | Jan 2006 | B2 |
| 7251737 | Weinberger et al. | Jul 2007 | B2 |
| 7380114 | Sane et al. | May 2008 | B2 |
| 7428567 | Schulte et al. | Sep 2008 | B2 |
| 7475222 | Glossner et al. | Jan 2009 | B2 |
| 7593978 | Schulte et al. | Sep 2009 | B2 |
| 7797363 | Hokenek et al. | Sep 2010 | B2 |
| 8001430 | Shasha et al. | Aug 2011 | B2 |
| 20020062424 | Liao et al. | May 2002 | A1 |
| 20020176430 | Sangha et al. | Nov 2002 | A1 |
| 20040240486 | Venkatesh et al. | Dec 2004 | A1 |
| 20040243739 | Spencer | Dec 2004 | A1 |
| 20060095729 | Hokenek et al. | May 2006 | A1 |
| 20070040788 | Saha | Feb 2007 | A1 |
| 20070073925 | Lim et al. | Mar 2007 | A1 |
| 20090193279 | Moudgill et al. | Jul 2009 | A1 |
| 20090216917 | Shasha et al. | Aug 2009 | A1 |
| 20090235032 | Hoane | Sep 2009 | A1 |
| 20090276432 | Hokenek et al. | Nov 2009 | A1 |
| 20100031007 | Moudgill | Feb 2010 | A1 |
| 20100115527 | Kotlyar et al. | May 2010 | A1 |
| 20100122068 | Hokenek et al. | May 2010 | A1 |
| 20100138575 | Noyes | Jun 2010 | A1 |
| 20100199073 | Hokenek et al. | Aug 2010 | A1 |
| 20100199075 | Hokenek et al. | Aug 2010 | A1 |
| 20100241834 | Moudgill | Sep 2010 | A1 |
| 20100268892 | Luttrell | Oct 2010 | A1 |
| 20100293210 | Sima et al. | Nov 2010 | A1 |
| 20100299319 | Parson et al. | Nov 2010 | A1 |
| 20110169848 | Bratt et al. | Jul 2011 | A1 |
| 20110219150 | Piccirillo et al. | Sep 2011 | A1 |
| 20110241744 | Moudgill et al. | Oct 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 4306754 | Oct 1992 | JP |
| 5020263 | Jan 1993 | JP |
| 6131294 | May 1994 | JP |
| 9293044 | Nov 1997 | JP |
| 9293045 | Nov 1997 | JP |
| 11085671 | Mar 1999 | JP |
| 11110338 | Apr 1999 | JP |
| 2000227897 | Aug 2000 | JP |
| 2000353146 | Dec 2000 | JP |
| 2002251368 | Sep 2002 | JP |
| 2006186480 | Jul 2006 | JP |
| 2008097084 | Apr 2008 | JP |
| WO 9323810 | Nov 1993 | WO |
| WO 0215015 | Feb 2002 | WO |
| Entry |
|---|
| Analog Devices, Inc. “Blackfin® Embedded Processor: Preliminary Technical Data ADSP-BF522/525/527.” Rev. PrC, 2007. |
| A Method for Handling DMA greater than One Deep Preemption in One Deep Preemption DMA, IP.Com Journal, IP.Com Inc., West Henrietta, NY, US, May 29, 2007, XP013120721, ISSN: 1533-0001. |
| Supplementary European Search Report—EP09805483—Search Authority—Munich—Jun. 14, 2012. |
| Glossner et al., Sep. 2004, Sandblaster Low-Power Multithreaded SDR Baseband Processor, Proceedings of the 3rd Workshop on Applications Specific Processors (WASP'04), Stockholm, Sweden, pp. 53-58. |
| Balzola et al., Sep. 26, 2001, Design alternatives for parallel saturating multioperand adders, Proceedings 2001 International Conference on Computer Design, pp. 172-177. |
| Balzola, Apr. 2003, Saturating arithmetic for digital signal processors, PhD Thesis, Lehigh University. |
| Glossner et al, 2000, Trends in compilable DSP architecture, IEEE Workshop in Signal Processing Systems, pp. 1-19. |
| Glossner et al., Apr. 2001, Towards a very high bandwidth wireless battery powered device, IEEE Computer Society Workshop in VLSI, pp. 3-9. |
| Glossner et al., Nov. 2002, A multithreaded processor architecture for SDR, The Proceedings of the Korean Institute of Communication Sciences, 19(11):70-84. |
| Glossner et al., Nov. 11-12, 2002, Multi-threaded processor for software-defined radio, Proceedings of the 2002 Software Defined Radio Technical Conference, vol. 1, 6 pp. |
| Glossner et al., Jan. 2003, A software defined communications baseband design, IEEE Communications Magazine, 41(1):120-128. |
| Glossner et al., Sep. 22, 23, 2003, Multiple communication protocols for software defined radio, IEEE Colloquium on DSP Enable Radio, ISIL, Livingston, Scotland, pp. 227-236. |
| Glossner et al., Mar. 4, 2004, 6. The Sandbridge sandblaster communications processor, Software Defined Radio: Baseband Technologies for 3G Handsets and Basestations, John Wiley & Sons, Ltd., pp. 129-159. |
| Jinturkar et al., Mar. 31-Apr. 3, 2003, Programming the Sandbridge multithreaded processor, Proceedings of the 2003 Global Signal Processing Expo (GSPx) and International Signal Processing Conference (ISPC), Dallas, Tx. |
| Schulte et al., Nov. 19, 2000, Parallel saturating multioperand adders, Cases '00, pp. 172-179. |
| Schulte et al., Nov. 2004, A low-power multithreaded processor for baseband communication systems, Lecture Notes in Computer Science, 3133:393-402. |
| ISR and WO dated Sep. 23, 2009 in PCT/US09/52794. |
| IPRP dated Feb. 17, 2011 in PCT/US09/52794. |
| Number | Date | Country | |
|---|---|---|---|
| 20110252211 A1 | Oct 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61086631 | Aug 2008 | US |
