Patent Grant
7966481
1. Field of the Invention
The present invention relates to the field of computers and computer processors, and more particularly to a method and means for allowing a computer to execute instructions as they are received from an external source without first storing said instructions, and an associated method to facilitate communications between computers and the ability of a computer to use the available resources of another computer. The predominant current usage of the present inventive direct execution method and apparatus is in the combination of multiple computers on a single microchip, wherein operating efficiency is important not only because of the desire for increased operating speed but also because of the power savings and heat reduction that are a consequence of the greater efficiency.
2. Description of the Background Art
In the art of computing, processing speed is a much desired quality, and the quest to create faster computers and processors is ongoing. However, it is generally acknowledged in the industry that the limits for increasing the speed in microprocessors are rapidly being approached, at least using presently known technology. Therefore, there is an increasing interest in the use of multiple processors to increase overall computer speed by sharing computer tasks among the processors.
The use of multiple processors creates a need for communication between the processors. Therefore, there is a significant portion of time spent in transferring instructions and data between processors. Each additional instruction that must be executed in order to accomplish this places an incremental delay in the process which, cumulatively, can be very significant. The conventional method for communicating instructions or data from one computer to another involves first storing the data or instruction in the receiving computer and then, subsequently calling it for execution (in the case of an instruction) or for operation thereon (in the case of data).
In the prior art it is known that it is necessary to “get the attention” of a computer from time to time. Even though a computer may be busy with one task, another time-sensitive task requirement can occur that may necessitate temporarily diverting the computer away from the first task. Examples include, but are not limited to, providing input to a computer. In such cases, the computer might need to temporarily acknowledge the input and/or react in accordance with the input. Then, the computer will either continue what it was doing before the input or else change what it was doing based upon the input. Although an external input is used as an example here, the same situation occurs when there is a potential conflict for the attention of the arithmetic logic unit (ALU) between internal aspects of the computer, as well.
When receiving data and changes in status from input/output (I/O) ports, there have been two methods available in the prior art. One has been to “poll” the port, which involves reading the status of the port at fixed intervals to determine whether any data has been received or a change of status has occurred. However, polling the port consumes considerable time and resources. A better alternative has often been the use of “interrupts”. When using interrupts, a processor can go about performing its assigned task and then, when an I/O port/device needs attention or the status changes, it sends an Interrupt Request (IRQ) to the processor. Once the processor receives an Interrupt Request, it will, for example, finish its current instruction, place a few things on the stack, and then execute the appropriate Interrupt Service Routine (ISR). Once the ISR has finished, the processor returns to where it left off. When using this method, the processor doesn't have to waste time, looking to see if the I/O device is in need of attention, but rather the device will only service the interrupt when it needs attention. However, the use of interrupts is far less than desirable in many cases, since there can be a great deal of overhead associated with the use of interrupts. For example, each time an interrupt occurs, a computer may have to temporarily store certain data relating to the task it was previously trying to accomplish, then load data pertaining to the interrupt, and then reload the data necessary for the prior task once the interrupt is handled.
An improvement to the above systems can be found using a system based on the Forth computer language. Forth systems have been able to have more than one “thread” of code executing at one time. This is often called a cooperative round-robin. The order in which the threads get a turn using the central processing unit (CPU) is fixed; for example, thread 4 always gets its turn after thread 3 and before thread 5. Each thread is allowed to keep the CPU as long as it wants to, and then relinquish it voluntarily. The thread does this by calling the word PAUSE. Only a few data items need to be saved during a PAUSE function in order for the original task to be restored, as opposed to large contexts that need to be saved during an interrupt function.
Each thread may or may not have work to do. If task 4 has work to do and the task before it in the round-robin (task 3) calls PAUSE, then task 4 will wake up and work until it decides to PAUSE again. If task 4 has no work to do, it passes control on to task 5. When a task calls a word which will perform an input/output function, and will therefore need to wait for the input/output to finish, a PAUSE is built into the input/output call.
The predictability of PAUSE allows for very efficient code. Frequently, a Forth based cooperative round-robin can give every existing thread a turn at the CPU in less time than it would take a pre-emptive multitasker to decide who should get the CPU next. However, a particular task may tend to overwhelm or overtake the CPU.
Another area of operating efficiency can be found by minimizing leakage current in a computer system. In the quest to make devices smaller, leakage current increases as insulation layers become thinner. In the near future, leakage power could reach as high as 50% of the active power. One attempt to curb leakage current can be found by utilizing sleep transistors. Sleep transistors act like a switch by isolating or disconnecting the power supply and blocks of logic when they are not needed. This can reduce leakage power by a factor of 2-1000 times, as disclosed in an article entitled How to Provide a Power-Efficient Architecture, by Bob Crepps, published in Embedded.com, Jul. 24, 2006.
However, there are several drawbacks in using sleep transistors. Many factors need to be considered in a system in order to incorporate efficient use of these transistors. The threshold voltage of a sleep transistor needs to be large; otherwise, the sleep transistor will have a high leakage current. This requires modification in the complementary metal-oxide semiconductor (CMOS) technology process to support both a high threshold voltage device for the sleep transistor and a low threshold voltage device for the logic gates. In addition, a large sleep transistor increases the area overhead and the dynamic power consumed for turning the transistor on and off.
To guarantee the proper functionality of a circuit, the sleep transistors have to be carefully sized to decrease their voltage drop while they are on. Two gates that switch at different times can share a sleep transistor. However, this is not practical for large circuits. Algorithms are necessary to determine the best implementation of sleep transistors for large circuits.
Other problems associated with sleep transistors include generating noise in the circuits, and a loss of data when used to disconnect flip flops from ground or supply voltage, as disclosed in an article entitled Standby and Active Leakage Current Control and Minimization in CMOS VLSI Circuits, by Farzan Fallah, et al., published in 2004. A method and/or apparatus is needed to reduce leakage current and provide a more efficient and less problematic computer processor system.
It would be useful to reduce the number of steps required to transmit, receive, and then use information in the form of data or instructions between computers. It would also be desirable to reduce or eliminate the time and resources consumed during an interrupt. In addition, it would be advantageous to expand the PAUSE function beyond one CPU. However, to the inventor's knowledge, no prior art system has streamlined the above described processes in a significant manner.
A computer processor array is disclosed in which power usage and heat dissipation are minimized, and computing efficiency is maximized. This is realized in part by a computer processor array, in which processors, also called nodes or cores become inactive but alert when not in an operating mode. The inactive node or core consumes essentially no power while inactive, and becomes active when an adjacent node or pin attempts to communicate with it. After execution of an incoming task, the node will go back to an inactive state until another task is sent to the node.
Array efficiency is also realized when a core is currently executing code or instructions, and a neighboring core communicates to the executing core. Rather then interrupting the executing core as in a conventional computing system, cores can be programmed to occasionally pause to check for incoming messages. If an incoming message awaits, then the executing core can act on the incoming message after pausing, and then continue with its original task.
These and other objects and advantages of the present invention will become clear to those skilled in the art in view of the description of modes of carrying out the invention, and the industrial applicability thereof, as described herein and as illustrated in the several figures of the drawings. The objects and advantages listed are not an exhaustive list of all possible advantages of the invention. Moreover, it will be possible to practice the invention even where one or more of the intended objects and/or advantages might be absent or not required in the application.
Further, those skilled in the art will recognize that various embodiments of the present invention may achieve one or more, but not necessarily all, of the described objects and/or advantages. Accordingly, the objects and/or advantages described herein are not essential elements of the present invention, and should not be construed as limitations.
a is a partial view of
This invention is described with reference to the figures, in which like numbers represent the same or similar elements. While this invention is described in terms of modes for achieving this invention's objectives, it will be appreciated by those skilled in the art that variations may be accomplished in view of these teachings without deviating from the spirit or scope of the presently claimed invention.
The embodiments and variations of the invention described herein, and/or shown in the drawings, are presented by way of example only and are not limiting as to the scope of the invention. Unless otherwise specifically stated, individual aspects and components of the invention may be omitted or modified for a variety of applications while remaining within the spirit and scope of the claimed invention, since it is intended that the present invention is adaptable to many variations.
The following invention describes processors (also called computers, nodes, or cores) that operate in a mode referred to as “asleep but alert” or “inactive but alert” which both refer to a mode of operation in which the processor's functions have been temporarily suspended, halted, or ceased where essentially no power is being utilized. At the same time, the processor is alert or in a state of readiness to immediately begin processing functions when instructed to do so. When the inactive processor receives processing instructions, it is referred to as “being awakened” or “becoming activated.”
A mode for carrying out the invention is given by an array of individual computer processors. The array is depicted in a diagrammatic view in
One skilled in the art will recognize that there will be additional components on the die 14 that are omitted from the view of
Processor 12e is an example of one of the processors 12 that is not on the periphery of the array 10. That is, processor 12e has four orthogonally adjacent processors 12a, 12b, 12c and 12d, although it is within the scope of this invention that more than four adjacent processors could be utilized. This grouping of processors 12a through 12e will be used, by way of example, hereinafter in relation to a more detailed discussion of the communications between the processors 12 of the array 10. As can be seen in the view of
According to one aspect of the present inventive method, a processor 12, such as the processor 12e can set high one, two, three or all four of its read lines 18 such that it is prepared to receive data from the respective one, two, three or all four adjacent processors 12. Similarly, it is also possible for a processor 12 to set one, two, three or all four of its write lines 20 high.
When one of the adjacent processors 12a, 12b, 12c or 12d sets a write line 20 between itself and the processor 12e high, if the processor 12e has already set the corresponding read line 18 high, then a word is transferred from that processor 12a, 12b, 12c or 12d to the processor 12e on the associated data lines 22. Then, the sending processor 12 will release the write line 20 and the receiving processor (12e in this example) pulls both the write line 20 and the read line 18 low. The latter action will acknowledge to the sending processor 12 that the data has been received. Note that the above description is not intended necessarily to denote the sequence of events in order. In actual practice, the receiving processor may try to set the write line 20 low slightly before the sending processor 12 releases (stops pulling high) its write line 20. In such an instance, as soon as the sending processor 12 releases its write line 20, the write line 20 will be pulled low by the receiving computer 12e. It is important to note that when the write line 20 of the sending processor 12 goes high, the data or code is already transferred; therefore, the receiving processor (12e in this instance) merely needs to latch the data/code for an essentially instantaneous response.
If the processor 12e were attempting to write to the processor 12a, then processor 12e would set the write line 20 between processor 12e and processor 12a to high. If the read line 18 between processor 12e and processor 12a has then not already been set to high by processor 12a, then processor 12e will simply wait until processor 12a does set that read line 20 high. When both of a corresponding pair of write line 18 and read line 20 are set high, then the data awaiting to be transferred on the data lines 22 is transferred. Thereafter, the receiving processor 12 (processor 12a, in this example) sets both the read line 18 and the write line 20 between the two processors (12e and 12a in this example) to low as soon as the sending processor 12e releases the write line 18.
Whenever a processor 12 such as the processor 12e has set one of its write lines 20 high in anticipation of writing it will simply wait, using essentially no power, until the data is “requested”, as described above, from the appropriate adjacent processor 12, unless the processor 12 to which the data is to be sent has already set its read line 18 high, in which case the data is transmitted immediately. Similarly, whenever a processor 12 has set one or more of its read lines 18 to high in anticipation of reading, it will simply wait, using essentially no power, until the write line 20 connected to a selected processor 12 goes high to transfer an instruction word between the two processors 12.
As discussed above, there may be several potential means and/or methods to cause the processors 12 to function as described. However, in this present example, the processors 12 so behave simply because they are operating generally asynchronously internally (in addition to transferring data there-between in the asynchronous manner described). That is, instructions are generally completed sequentially. When either a write or read instruction occurs, there can be no further action until that instruction is completed (or, perhaps alternatively, until it is aborted, as by a “reset” or the like). There is no regular clock pulse, in the prior art sense. Rather, a pulse is generated to accomplish a next instruction only when the instruction being executed either is not a read or write type instruction (given that a read or write type instruction would require completion, often by another entity) or else when the read or write type operation is, in fact, completed.
Other basic components of the processor 12 are a return stack 28 (including an R register 29, discussed hereinafter), an instruction area 30, an arithmetic logic unit (“ALU” or “processor”) 32, a data stack 34, a decode logic section 36 for decoding instructions, and a slot sequencer 42. One skilled in the art will be generally familiar with the operation of stack based computers such as the processors 12 of this present example. The processors 12 are dual stack processors having the data stack 34 and the separate return stack 28.
In this embodiment of the invention, the processor 12 has four communication ports 38 for communicating with adjacent processors 12. The communication ports 38 are tri-state drivers, having an off status, a receive status (for driving signals into the processor 12) and a send status (for driving signals out of the processor 12). If the particular processor 12 is not on the interior of the array (
In the presently described embodiment, the instruction area 30 includes a number of registers 40 including, in this example, an A register 40a, a B register 40b and a P register 40c. In this example, the A register 40a is a full eighteen-bit register, while the B register 40b and the P register 40c are nine-bit registers. An I/O register 47 (18 bit) is located between the memory (ROM 26 and RAM 24) and the communication ports 38. The I/O register 47 will be disclosed in greater detail hereinafter.
Although the invention is not limited by this example, the present processor 12 is implemented to execute native Forth language instructions. As one familiar with the Forth computer language will appreciate, complicated Forth instructions, known as Forth “words” are constructed from the native processor instructions designed into the processor. The collection of Forth words is known as a “dictionary”. As will be described in greater detail hereinafter, the processor 12 reads eighteen bits at a time from RAM 24, ROM 26 or directly from one of the data buses 16 (
In addition to the registers previously discussed herein, the instruction area 30 also has an 18 bit instruction register 30a for storing the instruction word 48 that is presently being used, and an additional 5 bit opcode register 30b for the instruction in the particular instruction word presently being executed.
As discussed above, the i4 bit 66 of each instruction 52 is set according to whether or not that instruction is either of a read or a write type of instruction, as opposed to that instruction being one that requires no input or output. The remaining bits 50 in the instruction 52 provide the remainder of the particular opcode for that instruction. In the case of a read or write type instruction, one or more of the bits may be used to indicate where data is to be read from, or written to, in that particular processor 12. In the present example of the invention, data to be written always comes from the T register 44 (the top of the data stack 34); however data can be selectively read into either the T register 44 or else the instruction area 30 from where it can be executed. In this particular embodiment of the invention, either data or instructions can be communicated in the manner described herein and instructions can therefore, be executed directly from the data bus 16.
One or more of the bits 50 will be used to indicate which of the ports 38, if any, is to be set to read or write. This later operation is optionally accomplished by using one or more bits to designate a register 40, such as the A register 40a, the B register 40b, or the like. In such an example, the designated register 40 will be preloaded with data having a bit corresponding to each of the ports 38 (and, also, any other potential entity with which the processor 12 may be attempting to communicate, such as memory (RAM 24 or ROM 26), an external communications port 39, or the like.) For example, each of four bits in the particular register 40 can correspond to each of the up port 38a, the right port 38b, the left port 38c or the down port 38d. In such case, where there is a ‘1’ at any of those bit locations, communication will be set to proceed through the corresponding port 38. In the present embodiment of the invention, it is anticipated that a read opcode might set more than one port 38 for communication in a single instruction.
The immediately following example will assume a communication wherein processor 12e is attempting to write to processor 12c, although the example is applicable to communication between any adjacent processors 12. When a write instruction is executed in a writing processor 12e, the selected write line 20 (in this example, the write line 20 between processors 12e and 12c) is set high; if the corresponding read line 18 is already high then data is immediately sent from the selected location through the selected communications port 38. Alternatively, if the corresponding read line 18 is not already high, then processor 12e will simply stop operation until the corresponding read line 18 does go high.
As for how the operation of the processor 12e is resumed when a read or write type instruction is completed, the mechanism for that is as follows. When both the read line 18 and the corresponding write line 20 between processors 12e and 12c are high, then both lines 18 and 20 will be released by each of the respective processors 12 that is holding it high. (In this example, the sending processor 12e will be holding the write line 18 high while the receiving processor 12c will be holding the read line 20 high). Then the receiving processor 12c will pull both lines 18 and 20 low. In actual practice, the receiving processor 12c may attempt to pull the lines 18 and 20 low before the sending processor 12e has released the write line 18. However, since the lines 18 and 20 are pulled high and only weakly held (latched) low, any attempt to pull a line 18 or 20 low will not actually succeed until that line 18 or 20 is released by the processor 12 that is holding it high.
When both lines 18 and 20 in a data bus 16 are pulled low, this is an “acknowledge” condition. Each of the processors 12e and 12c will, upon the acknowledge condition, set its own internal acknowledge line high.
As can be appreciated in light of the above discussion, the operations are essentially the same whether processor 12e attempts to write to processor 12c first, or whether processor 12c first attempts to read from processor 12e. The operation cannot be completed until both processors 12e and 12c are ready and, whichever processor 12e or 12c is ready first, that first processor 12 simply “becomes inactive” until the other processor 12e or 12c completes the transfer. Another way of looking at the above described process is that, actually, both the writing processor 12e and the receiving processor 12c become inactive when they execute the write and read instructions, respectively, but the last one to enter into the transaction reactivates nearly instantaneously when both the read line 18 and the write line 20 are high, whereas the first processor 12 to initiate the transaction can stay inactive nearly indefinitely until the second processor 12 is ready to complete the process.
The inventor believes that a key feature for enabling efficient asynchronous communications between devices is a type of acknowledge signal or condition. In the prior art, most communication between devices has been clocked and there is no direct way for a sending device to know that the receiving device has properly received the data. Methods such as checksum operations may have been used to attempt to insure that data is correctly received, but the sending device has no direct indication that the operation is completed. The present inventive method, as described herein, provides the necessary acknowledge condition that allows, or at least makes practical, asynchronous communications between the devices. Furthermore, the acknowledge condition also makes it possible for one or more of the devices to “become inactive” until the acknowledge condition occurs. An acknowledge condition could be communicated between the processors 12 by a separate signal being sent between the processors 12 (either over the interconnecting data bus 16 or over a separate signal line), and such an acknowledge signal would be within the scope of this aspect of the present invention. However, according to the embodiment of the invention described herein, it can be appreciated that there is even more economy involved here, in that the method for acknowledgement does not require any additional signal, clock cycle, timing pulse, or any such resource beyond that described, to actually affect the communication.
Since four instructions 52 can be included in an instruction word 48 and since, according to the present invention, an entire instruction word 48 can be communicated at one time between processors 12, this presents an ideal opportunity for transmitting a very small program in one operation. For example most of a small “For/Next” loop can be implemented in a single instruction word 48.
The FOR instruction 102 pushes a value onto the return stack 28 representing the number of iterations desired. That is, the value on the T register 44 at the top of the data stack 34 is pushed onto the R register 29 of the return stack 28. The FOR instruction 102 can be located in any slot 54. Where the FOR instruction 102 is not located in slot three 54d, then the remaining instructions 52 in that instruction word 48 will be executed before going on to the micro-loop 100, which will generally be the next loaded instruction word 48.
According to the presently described embodiment of the invention, the NEXT instruction 104 depicted in the view of
It should be noted that micro-loops 100 can be used entirely within a single processor 12. Indeed, the entire set of available machine language instructions is available for use as the operation instructions 106, and the application and use of micro-loops is limited only by the imagination of the programmer. However, when the ability to execute an entire micro-loop 100 within a single instruction word 48 is combined with the ability to allow a processor 12 to send the instruction word 48 to a neighbor processor 12 to execute the instructions 52 therein essentially directly from the data bus 16, this provides a powerful tool for allowing a processor 12 to utilize the resources of its neighbors.
The small micro-loop 100, all contained within the single instruction word 48, can be communicated between processors 12, as described herein and it can be executed directly from the communications port 38 of the receiving processor 12, just like any other set of instructions contained in an instruction word 48, as described herein. While there are many uses for this sort of “micro-loop” 100, a typical use would be where one processor 12 wants to store some data onto the memory of a neighbor processor 12. It could, for example, first send an instruction to that neighbor processor telling it to store an incoming data word to a particular memory address, then increment that address, then repeat for a given number of iterations (the number of data words to be transmitted). To read the data back, the first processor would just instruct the second processor (the one used for storage here) to write the stored data back to the first processor, using a similar micro-loop.
By using the micro-loop 100 structure in conjunction with the direct execution aspect described herein, a processor 12 can use an otherwise resting neighbor processor 12 for storage of excess data when the data storage need exceeds the relatively small capacity built into each individual processor 12. While this example has been described in terms of data storage, the same technique can equally be used to allow a processor 12 to have its neighbor share its computational resources—by creating a micro-loop 100 that causes the other processor 12 to perform some operations, store the result, and repeat a given number of times. As can be appreciated, the number of ways in which this inventive micro-loop 100 structure can be used is nearly infinite.
As previously mentioned herein, in the presently described embodiment of the invention, either data or instructions can be communicated in the manner described herein and instructions can, therefore, be executed essentially directly from the data bus 16. That is, there is no need to store instructions to RAM 24 and then recall them before execution. Instead, according to this aspect of the invention, an instruction word 48 that is received on a communications port 38 is not treated essentially differently than it would be were it recalled from RAM 24 or ROM 26.
One of the available machine language instructions is a FETCH instruction. The FETCH instruction uses the address on the A register 40a to determine from where to fetch an 18 bit word. Of course, the program will have to have already provided for placing the correct address on the A register 40a. As previously discussed herein, the A register 40a is an 18 bit register, such that there is a sufficient range of address data available that any of the potential sources from which a fetch can occur can be differentiated. That is, there is a range of addresses assigned to ROM, a different range of addresses assigned to RAM, and there are specific addresses for each of the ports 38 and for the external I/O port 39. A FETCH instruction always places the 18 bits that it fetches on the T register 44. An important advantage exists here in that there are no instruction fetches inside the loop. Therefore, there is approximately a 30% increase in efficiency, with a corresponding decrease in power consumption.
In contrast, as previously discussed herein, executable instructions (as opposed to data) are temporarily stored in the instruction register 30a. There is no specific command for “fetching” an 18 bit instruction word 48 into the instruction register 30a. Instead, when there are no more executable instructions left in the instruction register 30a, then the processor will automatically fetch the “next” instruction word 48. Where that “next” instruction word is located is determined by the “program counter” or “pc”, herein called the P register 40c. The P register 40c is often automatically incremented, as is the case where a sequence of instruction words 48 is to be fetched from RAM 24 or ROM 26. However, there are a number of exceptions to this general rule. For example, a JUMP or CALL instruction will cause the P register 40c to be loaded with the address designated by the data in the remainder of the presently loaded instruction word 48 after the JUMP or CALL instruction, rather than being incremented. When the P register 40c is then loaded with an address corresponding to one or more of the ports 38, then the next instruction word 48 will be loaded into the instruction register 30a from the ports 38. The P register 40c also does not increment when an instruction word 48 has just been retrieved from a port 38 into the instruction register 30a. Rather, it will continue to retain that same port address until a specific JUMP or CALL instruction is executed to change the P register 40c. That is, once the processor 12 is told to look for its next instruction from a port 38, it will continue to look for instructions from that same port 38 (or ports 38) until it is told to look elsewhere, such as back to the memory (RAM 24 or ROM 26) for its next instruction word 48.
As noted above, the processor 12 knows that the next eighteen bits fetched is to be placed in the instruction register 30a when there are no more executable instructions left in the present instruction word 48. By default, there are no more executable instructions left in the present instruction word 48 after a JUMP or CALL instruction (or also after certain other instructions that will not be specifically discussed here) because, by definition, the remainder of the 18 bit instruction word following a JUMP or CALL instruction is dedicated to the address referred to by the JUMP or CALL instruction. Another way of stating this is that the above described processes are unique in many ways, including but not limited to the fact that a JUMP or CALL instruction can, optionally, be to a port 38, rather than to just a memory address, or the like.
It should be remembered that, as discussed previously herein, the processor 12 can look for its next instruction from one port 38 or from any of a group of the ports 38. Therefore, addresses are provided to correspond to various combinations of the ports 38. When, for example, a processor is told to FETCH an instruction from a group of ports 38, then it will accept the first available instruction word 48 from any of the selected ports 38. If no neighbor processor 12 has already attempted to write to any of those ports 38, then the processor 12 in question will “become inactive”, as described in detail above, until a neighbor does write to the selected port 38.
In a “jump” decision operation 134, it is determined if one of the operations in the instruction word 48 is a JUMP instruction, or other instruction that would divert operation away from the continued “normal” progression as discussed previously herein. If yes, then the address provided in the instruction word 48 after the JUMP (or other such) instruction is provided to the P register 40c in a “load P register” operation 136, and the sequence begins again in the “fetch word” operation 122, as indicated in the diagram of
The above description is not intended to represent actual operational steps. Instead, it is a diagram of the various decisions and operations resulting there from that are performed according to the described embodiment of the invention. Indeed, this flow diagram should not be understood to mean that each operation described and shown requires a separate distinct sequential step. In fact many of the described operations in the flow diagram of
Each processor 12 is programmed to JUMP to an address when it is started. That address will be the address of the first instruction word 48 that will start that particular processor 12 on its designated job. The instruction word can be located, for example, in the ROM 26. After a cold start, a processor 12 may load a program, such as a program known as a worker mode loop. The worker mode loop for center processors 12, edge processors 12, and corner processors 12 will be different. In addition, some processors 12 may have specific tasks at boot-up in ROM associated with their positions within the array 10. Worker mode loops will be described in greater detail hereinafter.
While there are numerous ways in which this feature might be used, an example that will serve to illustrate just one such “computer alert method” is illustrated in the view of
In an “activate” operation 154, the inactive processor 12 is caused to resume operation because the neighboring processor 12 or external device 39 has completed the transaction being awaited. If the transaction being awaited was the receipt of an instruction word 48 to be executed, then the processor 12 will proceed to execute the instructions therein. If the transaction being awaited was the receipt of data, then the processor 12 will proceed to execute the next instruction in queue, which will be either the instruction in the next slot 54 in the present instruction word 48, or else the next instruction word 48 will be loaded and the next instruction will be in slot 0 of that next instruction word 48. In any case, while being used in the described manner, then that next instruction will begin a sequence of one or more instructions for handling the input just received. Options for handling such input can include reacting to perform some predefined function internally, communicating with one or more of the other processors 12 in the array 10, or even ignoring the input (just as conventional prior art interrupts may be ignored under prescribed conditions). The options are depicted in the view of
One skilled in the art will recognize that this above described operating mode will be useful as a more efficient alternative to the conventional use of interrupts. When a processor 12 has one or more of its read lines 18 (or a write line 20) set high, it can be said to be in an “alert” condition. In the alert condition, the processor 12 is ready to immediately execute any instruction sent to it on the data bus 16 corresponding to the read line or lines 18 that are set high or, alternatively, to act on data that is transferred over the data bus 16. Where there is an array of processors 12 available, one or more can be used, at any given time, to be in the above described alert condition such that any of a prescribed set of inputs will trigger it into action. This is preferable to using the conventional interrupt technique to “get the attention” of a processor, because an interrupt will cause a processor to have to store certain data, load certain data, and so on, in response to the interrupt request. According to the present invention, a processor can be placed in the alert condition and dedicated to awaiting the input of interest, such that not a single instruction period is wasted in beginning execution of the instructions triggered by such input. Again, note that in the presently described embodiment, processors in the alert condition will actually be “inactive”, meaning that they are using essentially no power, but “alert” in that they will be instantly triggered into action by an input. However, it is within the scope of this aspect of the invention that the “alert” condition could be embodied in a processor even if it were not “inactive”. The described alert condition can be used in essentially any situation where a conventional prior art interrupt (either a hardware interrupt or a software interrupt) might have otherwise been used.
Regarding the processor 12f and the “enter inactive but alert status” operation 152, the “activate” operation 154, and the “act on input” operation 156 each are accomplished as described previously herein in relation to the first example of the processor alert method 150. However, because this example anticipates a possible need for interaction between the processors 12f and 12g, then following the “act on input” operation 156, the processor 12f enters a “send info?” decision operation 158 wherein, according to its programming, it is determined if the input just received requires the attention of the other processor 12g. If no, then the processor 12f returns to inactive but alert status, or some other alternative such as was discussed previously herein. If yes, then the processor 12f initiates communication with the processor 12g as described in detail previously herein in a “send to other” operation 160. It should be noted that, according to the choice of the programmer, the processor 12f could be sending instructions such as it may have generated internally in response to the input from the external device 82. Alternatively, the processor 12f could pass on data to the processor 12g and such data could be internally generated in processor 12 or else “passed through” from the external device 82. Still another alternative might be that the processor 12f, in some situations, might attempt to read from the processor 12g when it receives an input from the external device 82. All of these opportunities are available to the programmer.
The processor 12g is generally executing code to accomplish its assigned primary task, whatever that might be, as indicated in an “execute primary function” operation 162. However, if the programmer has decided that occasional interaction between the processors 12f and 12g is desirable, then the programmer will have provided that the processor 12g occasionally pause to see if one or more of its neighbors has attempted a communication, as indicated in a “look for input” operation 166. An “input?” decision operation 168 is made in the event that there is a communication waiting (as, for example, if the processor 12f has already initiated a write to the processor 12g). If there has been a communication initiated (yes), then the processor 12g will complete the communication, as described in detail previously herein, in a “receive from other” operation 170. If no, then the processor 12g will return to the execution of its assigned function, as shown in
In the example of
It should be noted that, according to the embodiment of the invention described herein, a given processor 12 need not be interrupted while it is performing a task because another processor 12 is assigned the task of monitoring and handling inputs that might otherwise require an interrupt. However, it is interesting to note also that the processor 12 that is busy handling another task also cannot be disturbed unless and until its programming provides that it look to its ports 38 for input. Therefore, it will sometimes be desirable to cause the processor 12 to pause or suspend its current task to look for other inputs. The concept of “Pause” and how it is used will be discussed in greater detail later.
Each port 38 between processors 12 comprises data lines 22 and one read line 18 and one write line 20, which inclusively make up the data bus 16. In addition to the data bus 16, each port 38 also comprises handshake control signals. The data lines 22 connect between the ports 38 of two adjacent processors 12. For example, a word or op code may reside in the T register 44 of processor 12e during a STORE (write) instruction; the write line 20 of processor 12e would then be set high. When the read line 18 of processor 12c is set high, then data is transferred into the T register 44 of processor 12c in a FETCH (read) instruction. After the transaction is complete, both the read line 18 and the write line 20 are set low. In this example, this data becomes an instruction when it is read by the P register 40c.
When a processor 12 reads a message, the message could be in the form of data, instructions, or signals. Instructions may be stored into memory and used later by the same processor 12, or stored into and executed directly from a port 38 by a different processor 12. If a processor 12 is reading from memory using its P register 40c, it will either immediately execute the instruction by putting the instruction into the instruction register 30a, or it will read the message as data and put it into the T register 44. A FETCH instruction will read a message as data when the FETCH instruction is directed or addressed to a port 38. If a JUMP or CALL instruction is to a port 38, or a RETURN instruction is to a port 38 address, then the P register 40c will read what is written to the port 38 as instructions and the instruction will be treated as executable code.
A receiving processor 12 could read a message as data and then write a message as data. A message that is routed (i.e. sent from one processor 12 to a non-adjacent processor 12 through intermediary processors 12) is interpreted as data and read into the T register 44 of each successive processor 12 until the intended recipient is reached, then the message is interpreted as code (read from the P register 40c) and then executed. Therefore, if a message is read during FETCH A (defined as reading the contents of memory specified by the A register 40a) or FETCH A+ (defined as reading the contents of memory specified by the A register 40a, and adding one to the A register 40a) or FETCH P+ (defined as reading the contents specified by the P register 40c, and adding one to the P register 40c), then the message is transferred into the T register 44 of the processor 12 doing the reading. If the processor 12 is reading the message from the P register 40c, then the message is transferred into the instruction register 30a of the receiving processor 12.
In order to have a way to refer to directions within the array 10a that does not change according to which way the processors 12 therein are mirrored, the inventors have chosen to use the terminology North, South, East and West (NSEW) The directions of North, South, East, and West maintain their relative directions, even with mirroring. This is relevant during routing, which was previously described as sending a message from a processor 12 to another non-adjacent processor 12 through intermediary processors 12. Directions (NSEW) are in a table located in ROM 26.
Left ports 38c and up ports 38a do not connect to anything internal to the array 10a when they are on the outside border of the array 10a although, as discussed previously herein, they will probably connect to an external I/O port 39 (
Each processor 12 has an 18 bit I/O register 47, as shown in
The following example with reference to
As discussed earlier, PAUSE causes a processor 12 to temporarily suspend its processing tasks or remain inactive in order to check for incoming data or instructions. There are two instances for using a PAUSE routine. The first instance occurs after a processor 12 becomes activated from a previous inactive state. The second instance occurs when a processor 12 is executing a program but takes a break, or pause, to look for an incoming message.
A NOP (also referred to as a “no-op”) is a no operation instruction, and is designated by four dots ( . . . ) in the instruction code. With reference back to
A processor 12 can be designated as primarily a worker or “production type” processor 12. In the absence of any other instructions, this processor 12 can become a worker by default, and perform a worker mode loop 200 as in
In a “begin pause” operation 213, the worker processor 12 is absent of any processing activities, in order to prepare for the next step of “check the appropriate port(s)” operation 214, according to the contents of the I/O register 47 that were read in the previous step 212. The step of “execute message(s)” operation 215 from the appropriate port(s) occurs next. After all of the incoming message(s) have been executed, PAUSE will end in an “end pause” operation 216. At this point, the worker processor 12 will become inactive in an “asleep/inactive” operation 217, and wait until another message header arrives to activate or wake the worker processor 12.
In summary, all worker processors 12 sleep and PAUSE. The worker processor 12 sleeps, wakes up and reads the I/O register 47 where all neighbor processor 12 write requests are checked, begins PAUSE, and then executes the incoming message. At the end of an incoming message, there is a return (;), or a JUMP to a port 38 with a return (;). The worker processor 12 then goes back to the PAUSE routine, checks the next bit in the I/O register 47 for another message, executes the message, if any, then returns to the worker loop and goes to sleep waiting for more messages.
Messages are treated as tasks. PAUSE treats incoming messages that are present as waking tasks, and treats ports 38 with nothing on them as sleeping tasks.
The second occurrence of using PAUSE is shown in
Most of the time, communicated sequential processes on different processors 12 is performed by a group of processors 12. If an adjacent processor 12 is not ready to accept a message, then the transmitting processor 12 will go to sleep, or work on another task and will need to poll the I/O register 47 to look for messages. However, most of the time when a group is doing communicated sequential processes on different processors 12, a processor 12 just writes to a port 38 and the adjacent processor 12 just reads from its port 38. A read from all four ports 38 can be performed by a processor 12, then the processor 12 goes to sleep until any one of the four neighbor processors 12 writes; the reading processor 12 needs to check the I/O register 47 to see which processor 12 wrote after being awakened. That processor 12 wakes up with a data read. The processor 12 can read with the A register 40a (data) or the B register 40b (data), or the P register 40c (data or code); reading a whole message with the P register 40c means it will execute an entire message including the four NOPs.
A processor 12 can read all four ports 38 as a worker, then go to sleep if no message is waiting (
Processors with I/O pins connected have bits in the I/O port 39 that set and show the status of those pins. Some pins are read-only and can be read by reading a bit in an I/O port 39. Some pins are read/write and can be read or written by reading or writing bits in the I/O register 47. After a read or write has been completed, the handshake signals are gone and are not readable in the I/O register 47. Pins connected to the wake-up pin handshake circuit of an unconnected port will not be visible in the I/O register 47. If an address that includes a wake-up pin is read, then the processor 12 will wake up when a signal appears on the pin, but if the I/O register 47 is read, then the processor 12 won't see the wake-up handshake. A pin wake-up is connected only to the wake-up circuit, not to the I/O register 47. Therefore, a pin has to be read directly to know if the pin awakened the processor 12. If the pin reads as 0 (zero), then one of the other ports 38 awakened the processor 12. This is how the ROM code in the serial worker processor functions.
Serial processors have their serial input pin connected to an I/O register bit (bit 17) where they can be read as data, but they are also connected to the handshake line of an unconnected corn port. A processor 12 that reads that unconnected corn port will wake up when data on the pin tells the processor 12 that a write to the pin or phantom port is taking place. When a real port 38 is read, the processor 12 will sleep until it gets the write handshake signal and will then wake up reading the data. The ROM code distinguishes between a processor 12 being awakened by a pin and being awakened by a port 38 by reading the pin after the processor 12 is awake. If the pin is low, the processor 12 reads the I/O register 47 and pauses. If the pin is high, the processor 12 performs serial boot code.
When a read or write is started, a read or write handshake bit is raised. When the paired read or write handshake bit is raised by the other processor 12, all bits raised by that processor 12 are lowered, the processors 12 wake up, and the data is transferred. After the data is transferred, any read/write handshake flag bits that were raised are lowered.
If a processor 12 JUMPs to RDLU (the name of the address of four neighbor ports 38), it tries to read and raises read flags on all four ports 38. It then goes to sleep in essentially a no power mode. When a neighbor(s) writes to one or more of these ports 38 and raises the write flag(s), all port 38 flags are reset and the first processor 12 wakes up. The same thing happens if the processor 12 reads the address using the A register 40a or the B register 40b and a data FETCH or STORE. It goes to sleep until one of the four (or three or two) neighbors wakes it up with data.
If a wake-up pin is read as part of an address four port 38 read and the pin is not high, then the processor 12 knows that the wake-up came from one of the other three neighbors. Serial boots in ROM on serial boot processors 12 come from a pin which wakes up the processor 12; if the pin is high, then code is loaded from the serial pin and booted by the processor 12.
There is a path of recommended routes that won't conflict with anything by using X0 packets. X0 stands for execute on the 0 node of the RAM server; messages headed for node 0 on certain paths are defined in ROM. One must not route messages against each other. PAUSE allows messages to be routed safely. A RAM server buffer (on node 6, a node next to the RAM server) allows incoming messages to node 0 of the RAM server to be buffered in RAM on node 6 so that they do not back up and block messages sent out from the RAM server. This is the recommended routing path that doesn't conflict with X0.
It is important to realize that what is being described here is “cooperative multi-tasking” between several processors 12. A set of tasks resides on a port 38 or ports 38 and local memory. FETCH B and PAUSE will sequentially examine all ports 38 for incoming executable code and treat ports 38 as tasks. Instructions on a port 38 can be executed directly from the port 38 without loading into the processor's RAM first.
Although the PAUSE routine between multiple processors 12 has been disclosed herein with reference to Forth, all of the concepts of the PAUSE routine between multiple processors 12 could be applied to other programming languages as well.
All of the above examples are only some of the examples of available embodiments of the present invention. Those skilled in the art will readily observe that numerous other modifications and alterations may be made without departing from the spirit and scope of the invention. Accordingly, the disclosure herein is not intended as limiting and the appended claims are to be interpreted as encompassing the entire scope of the invention.
This application claims priority to provisional application No. 60/849,498, entitled “SEAForth Applications Guide,” filed Sep. 29, 2006, and also claims priority to provisional application No. 60/818,084, filed Jun. 30, 2006; and is a continuation-in-part of the application entitled, “Method and Apparatus for Monitoring Inputs to a Computer,” Ser. No. 11/441,818, filed May 26, 2006; and claims priority to provisional application No. 60/797,345, filed May 3, 2006, and also claims priority to provisional application No. 60/788,265, filed Mar. 31, 2006; and is a continuation-in-part of the application entitled, “Asynchronous Power Saving Computer,” Ser. No. 11/355,513, filed Feb. 16, 2006. All of the cited applications above are incorporated herein by reference in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3757306 | Boone | Sep 1973 | A |
| 3868677 | Kidd | Feb 1975 | A |
| 4107773 | Gilbreath et al. | Aug 1978 | A |
| 4215401 | Holsztynski et al. | Jul 1980 | A |
| 4215422 | McCray et al. | Jul 1980 | A |
| 4298932 | Sams | Nov 1981 | A |
| 4462074 | Linde | Jul 1984 | A |
| 4589067 | Porter et al. | May 1986 | A |
| 4591980 | Huberman et al. | May 1986 | A |
| 4593351 | Hong et al. | Jun 1986 | A |
| 4665494 | Tanaka et al. | May 1987 | A |
| 4672331 | Cushing | Jun 1987 | A |
| 4739474 | Holsztynski | Apr 1988 | A |
| 4742511 | Johnson | May 1988 | A |
| 4789927 | Hannah | Dec 1988 | A |
| 4821231 | Cruess et al. | Apr 1989 | A |
| 4868745 | Patton et al. | Sep 1989 | A |
| 4942517 | Cok | Jul 1990 | A |
| 4943909 | Huang | Jul 1990 | A |
| 4961167 | Kumanoya et al. | Oct 1990 | A |
| 4984151 | Dujari | Jan 1991 | A |
| 5021947 | Campbell et al. | Jun 1991 | A |
| 5029124 | Leahy et al. | Jul 1991 | A |
| 5053952 | Koopman, Jr. et al. | Oct 1991 | A |
| 5159338 | Takahashi | Oct 1992 | A |
| 5218682 | Frantz | Jun 1993 | A |
| 5317735 | Schomberg | May 1994 | A |
| 5319757 | Moore et al. | Jun 1994 | A |
| 5359568 | Livay et al. | Oct 1994 | A |
| 5375238 | Ooi | Dec 1994 | A |
| 5377333 | Nakagoshi et al. | Dec 1994 | A |
| 5386585 | Traylor | Jan 1995 | A |
| 5390304 | Leach et al. | Feb 1995 | A |
| 5396609 | Schmidt et al. | Mar 1995 | A |
| 5410723 | Schmidt et al. | Apr 1995 | A |
| 5434989 | Yamaguchi | Jul 1995 | A |
| 5440749 | Moore et al. | Aug 1995 | A |
| 5475856 | Kogge | Dec 1995 | A |
| 5485624 | Steinmetz et al. | Jan 1996 | A |
| 5535393 | Reeve et al. | Jul 1996 | A |
| 5535417 | Baji et al. | Jul 1996 | A |
| 5550489 | Raab | Aug 1996 | A |
| 5551045 | Kawamoto et al. | Aug 1996 | A |
| 5581767 | Katsuki et al. | Dec 1996 | A |
| 5630154 | Bolstad et al. | May 1997 | A |
| 5649198 | Shibata et al. | Jul 1997 | A |
| 5657485 | Streitenberger et al. | Aug 1997 | A |
| 5673423 | Hillis | Sep 1997 | A |
| 5692197 | Narad et al. | Nov 1997 | A |
| 5706491 | McMahan | Jan 1998 | A |
| 5717943 | Barker et al. | Feb 1998 | A |
| 5727194 | Shridhar et al. | Mar 1998 | A |
| 5737628 | Birrittella et al. | Apr 1998 | A |
| 5740463 | Oshima et al. | Apr 1998 | A |
| 5752259 | Tran | May 1998 | A |
| 5765015 | Wilkinson et al. | Jun 1998 | A |
| 5784602 | Glass et al. | Jul 1998 | A |
| 5826101 | Beck et al. | Oct 1998 | A |
| 5832291 | Rosen et al. | Nov 1998 | A |
| 5867330 | Tanaka | Feb 1999 | A |
| 5893148 | Genduso et al. | Apr 1999 | A |
| 5911082 | Monroe et al. | Jun 1999 | A |
| 5937202 | Crosetto | Aug 1999 | A |
| 5944814 | McCulloch et al. | Aug 1999 | A |
| 6003128 | Tran | Dec 1999 | A |
| 6023753 | Pechanek et al. | Feb 2000 | A |
| 6038655 | Little et al. | Mar 2000 | A |
| 6057791 | Knapp | May 2000 | A |
| 6081215 | Kost et al. | Jun 2000 | A |
| 6085304 | Morris et al. | Jul 2000 | A |
| 6092183 | Takewa et al. | Jul 2000 | A |
| 6094030 | Gunthorpe et al. | Jul 2000 | A |
| 6101598 | Dokic et al. | Aug 2000 | A |
| 6112296 | Witt et al. | Aug 2000 | A |
| 6145072 | Shams et al. | Nov 2000 | A |
| 6148392 | Liu | Nov 2000 | A |
| 6154809 | Ikenaga et al. | Nov 2000 | A |
| 6173389 | Pechanek et al. | Jan 2001 | B1 |
| 6178525 | Warren | Jan 2001 | B1 |
| 6192388 | Cajolet | Feb 2001 | B1 |
| 6219685 | Story | Apr 2001 | B1 |
| 6223282 | Kang | Apr 2001 | B1 |
| 6232905 | Smith et al. | May 2001 | B1 |
| 6233670 | Ikenaga et al. | May 2001 | B1 |
| 6236645 | Agazzi | May 2001 | B1 |
| 6279101 | Witt et al. | Aug 2001 | B1 |
| 6307425 | Chevallier et al. | Oct 2001 | B1 |
| 6308229 | Masteller | Oct 2001 | B1 |
| 6353880 | Cheng | Mar 2002 | B1 |
| 6367005 | Zahir et al. | Apr 2002 | B1 |
| 6381705 | Roche | Apr 2002 | B1 |
| 6388600 | Johnson et al. | May 2002 | B1 |
| 6404274 | Hosono et al. | Jun 2002 | B1 |
| 6404663 | Shinozaki | Jun 2002 | B2 |
| 6427204 | Arimilli et al. | Jul 2002 | B1 |
| 6449709 | Gates | Sep 2002 | B1 |
| 6460128 | Baxter et al. | Oct 2002 | B1 |
| 6502141 | Rawson, III | Dec 2002 | B1 |
| 6507649 | Tovander | Jan 2003 | B1 |
| 6507947 | Schreiber et al. | Jan 2003 | B1 |
| 6522282 | Elbornsson | Feb 2003 | B1 |
| 6542105 | Sakuragi | Apr 2003 | B2 |
| 6560716 | Gasparik et al. | May 2003 | B1 |
| 6598148 | Moore et al. | Jul 2003 | B1 |
| 6636122 | Tsyrganovich | Oct 2003 | B2 |
| 6647027 | Gasparik et al. | Nov 2003 | B1 |
| 6657462 | Dobberpuhl | Dec 2003 | B2 |
| 6665793 | Zahir et al. | Dec 2003 | B1 |
| 6671112 | Murakami et al. | Dec 2003 | B2 |
| 6725361 | Rozas et al. | Apr 2004 | B1 |
| 6732253 | Redford | May 2004 | B1 |
| 6825843 | Allen et al. | Nov 2004 | B2 |
| 6826674 | Sato | Nov 2004 | B1 |
| 6845412 | Boike et al. | Jan 2005 | B1 |
| 6898721 | Schmidt | May 2005 | B2 |
| 6930628 | Reinhold et al. | Aug 2005 | B2 |
| 6937538 | Terzioglu et al. | Aug 2005 | B2 |
| 6959372 | Hobson et al. | Oct 2005 | B1 |
| 6966002 | Torrubia-Saez | Nov 2005 | B1 |
| 6970895 | Vaidyanathan et al. | Nov 2005 | B2 |
| 7028163 | Kim et al. | Apr 2006 | B2 |
| 7079046 | Tanaka | Jul 2006 | B2 |
| 7084793 | Elbornsson | Aug 2006 | B2 |
| 7089438 | Raad | Aug 2006 | B2 |
| 7131113 | Chang et al. | Oct 2006 | B2 |
| 7136989 | Ishii | Nov 2006 | B2 |
| 7155602 | Poznanovic | Dec 2006 | B2 |
| 7157934 | Teifel et al. | Jan 2007 | B2 |
| 7162573 | Mehta | Jan 2007 | B2 |
| 7197624 | Pechanek et al. | Mar 2007 | B2 |
| 7249357 | Landman et al. | Jul 2007 | B2 |
| 7255476 | Franch et al. | Aug 2007 | B2 |
| 7263624 | Marchand et al. | Aug 2007 | B2 |
| 7265640 | Nix | Sep 2007 | B1 |
| 7269805 | Ansari et al. | Sep 2007 | B1 |
| 7319355 | Wu et al. | Jan 2008 | B2 |
| 7380100 | Shimura et al. | May 2008 | B2 |
| 7386689 | Kirsch | Jun 2008 | B2 |
| 7403055 | Minzoni | Jul 2008 | B2 |
| 7471643 | Stansfield | Dec 2008 | B2 |
| 7512728 | Tseng | Mar 2009 | B2 |
| 7528756 | Moore et al. | May 2009 | B2 |
| 20020004912 | Fung | Jan 2002 | A1 |
| 20020010844 | Noel et al. | Jan 2002 | A1 |
| 20020019951 | Kubo et al. | Feb 2002 | A1 |
| 20020186159 | Reinhold et al. | Dec 2002 | A1 |
| 20030005168 | Leerssen et al. | Jan 2003 | A1 |
| 20030009502 | Katayanagi | Jan 2003 | A1 |
| 20030028750 | Hogenauer | Feb 2003 | A1 |
| 20030035549 | Bizjak et al. | Feb 2003 | A1 |
| 20030065905 | Ishii | Apr 2003 | A1 |
| 20030113031 | Wal | Jun 2003 | A1 |
| 20030135710 | Farwell et al. | Jul 2003 | A1 |
| 20030179123 | DeVilbiss | Sep 2003 | A1 |
| 20030217242 | Wybenga et al. | Nov 2003 | A1 |
| 20040003219 | Uehara | Jan 2004 | A1 |
| 20040030859 | Doerr et al. | Feb 2004 | A1 |
| 20040059895 | May et al. | Mar 2004 | A1 |
| 20040095264 | Thomas | May 2004 | A1 |
| 20040098707 | Tang et al. | May 2004 | A1 |
| 20040107332 | Fujii et al. | Jun 2004 | A1 |
| 20040143638 | Beckmann et al. | Jul 2004 | A1 |
| 20040215929 | Floyd et al. | Oct 2004 | A1 |
| 20040250046 | Gonzalez et al. | Dec 2004 | A1 |
| 20050015572 | Tanaka et al. | Jan 2005 | A1 |
| 20050027548 | Jacobs et al. | Feb 2005 | A1 |
| 20050034029 | Ramberg et al. | Feb 2005 | A1 |
| 20050114565 | Gonzalez et al. | May 2005 | A1 |
| 20050149693 | Barry | Jul 2005 | A1 |
| 20050182581 | Hashemian | Aug 2005 | A1 |
| 20050196060 | Wang et al. | Sep 2005 | A1 |
| 20050206648 | Perry et al. | Sep 2005 | A1 |
| 20050223204 | Kato | Oct 2005 | A1 |
| 20050228904 | Moore | Oct 2005 | A1 |
| 20050237083 | Bakker et al. | Oct 2005 | A1 |
| 20050257037 | Elwood et al. | Nov 2005 | A1 |
| 20050262278 | Schmidt | Nov 2005 | A1 |
| 20060059377 | Sherburne | Mar 2006 | A1 |
| 20060082445 | O'Toole et al. | Apr 2006 | A1 |
| 20060097901 | Draxelmayr et al. | May 2006 | A1 |
| 20060101238 | Bose et al. | May 2006 | A1 |
| 20060149925 | Nguyen et al. | Jul 2006 | A1 |
| 20060212867 | Fields et al. | Sep 2006 | A1 |
| 20060218375 | Swarztrauber | Sep 2006 | A1 |
| 20060224831 | Yoshikawa | Oct 2006 | A1 |
| 20060248317 | Vorbach et al. | Nov 2006 | A1 |
| 20060248360 | Fung | Nov 2006 | A1 |
| 20060259743 | Suzuoki | Nov 2006 | A1 |
| 20060271764 | Nilsson et al. | Nov 2006 | A1 |
| 20060279445 | Kinyua et al. | Dec 2006 | A1 |
| 20060279969 | Leung et al. | Dec 2006 | A1 |
| 20060279970 | Kernahan | Dec 2006 | A1 |
| 20070035611 | Wu | Feb 2007 | A1 |
| 20070036150 | Pounds et al. | Feb 2007 | A1 |
| 20070041438 | Mogi et al. | Feb 2007 | A1 |
| 20070070079 | Chung et al. | Mar 2007 | A1 |
| 20070113058 | Tran et al. | May 2007 | A1 |
| 20070153953 | Garzarolli et al. | Jul 2007 | A1 |
| 20070192504 | Moore | Aug 2007 | A1 |
| 20070192566 | Moore et al. | Aug 2007 | A1 |
| 20070192570 | Moore | Aug 2007 | A1 |
| 20070192575 | Moore et al. | Aug 2007 | A1 |
| 20070192646 | Moore | Aug 2007 | A1 |
| 20070226457 | Moore et al. | Sep 2007 | A1 |
| 20080270648 | Rible | Oct 2008 | A1 |
| 20080270751 | Montvelishsky et al. | Oct 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 1051995 | Jun 1991 | CN |
| 3937807 | May 1990 | DE |
| 0156654 | Oct 1985 | EP |
| 0227319 | Jul 1987 | EP |
| 0724221 | Jul 1996 | EP |
| 0992896 | Apr 2000 | EP |
| 1182544 | Feb 2002 | EP |
| 2154343 | Sep 1985 | GB |
| 2299422 | Oct 1996 | GB |
| 60-183645 | Sep 1985 | JP |
| 3-500585 | Feb 1991 | JP |
| 5-81216 | Apr 1993 | JP |
| 6-243113 | Sep 1994 | JP |
| 2509678 | Apr 1996 | JP |
| 8-161282 | Jun 1996 | JP |
| 8-288768 | Nov 1996 | JP |
| 10-1999-0036970 | May 1999 | KR |
| 10-2005-0112523 | Nov 2005 | KR |
| 10-2007-0048540 | May 2007 | KR |
| 10-2007-0052461 | May 2007 | KR |
| WO9715001 | Apr 1997 | WO |
| WO0042506 | Jul 2000 | WO |
| WO0212999 | Feb 2002 | WO |
| WO0250700 | Jun 2002 | WO |
| WO02088936 | Nov 2002 | WO |
| WO03019356 | Mar 2003 | WO |
| WO2005091847 | Oct 2005 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20070226457 A1 | Sep 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60788265 | Mar 2006 | US | |
| 60797345 | May 2006 | US | |
| 60818084 | Jun 2006 | US | |
| 60849498 | Sep 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11355513 | Feb 2006 | US |
| Child | 11653187 | US | |
| Parent | 11441818 | May 2006 | US |
| Child | 11355513 | US |
