Patent Grant
11055103
This invention relates in general to programming multiple processor systems and more specifically to a hardware task manager that efficiently utilizes parallel programming constructs incorporating both streams and threads.
A common limitation to processing performance in a digital system is the efficiency and speed of transferring instruction, data and other information among different components and subsystems within the digital system. For example, the bus speed in a general-purpose Von Neumann architecture dictates how fast data can be transferred between the processor and memory and, as a result, places a limit on the computing performance (e.g., million instructions per second (MIPS), floating-point operations per second (FLOPS), etc.).
Other types of computer architecture design, such as multi-processor or parallel processor designs require complex communication, or interconnection, capabilities so that each of the different processors can communicate with other processors, with multiple memory devices, input/output (I/O) ports, etc. With today's complex processor system designs, the importance of an efficient and fast interconnection facility rises dramatically. However, such facilities are difficult to design to optimize goals of speed, flexibility and simplicity of design.
Currently, parallel programming is based on threads as the central, organizing principle of computing. However, threads are seriously flawed as a computation model because they are wildly nondeterministic and rely on programming style to constrain that non-determinism to achieve deterministic aims. Test and verification become difficult in the presence of this wild non-determinism. One solution has been suggested by GPU (Graphics Processing Unit) vendors is to narrow the forms of parallelism expressible in the programming model. Their focus on data parallelism, however, ties the hands of programmers and prevents exploiting the full potential of multi-core processors.
Further, threads do not just run on a bank of identical cores. A modern computer (supercomputer, workstation, desktop and laptops) contains a bewildering array of different heterogeneous cores all requiring separate programming models to program. For example, a motherboard may have one to four main CPUs (central processing units e.g., Pentium Processor) each having on-die 1 to 6 CPU cores with an on-die or on-package GPU (Graphics Processing Unit—e.g. NVIDIA GPU) which itself contains 16 to 256 GPU cores along with several discrete video & audio encode & decode cores (for the encoding and decoding of a multiplicity of video standards—e.g. MPEG2, MPEG4, VC-1, H.264 etc.). Also on the motherboard are from 1 to 4 discrete high end GPUs each containing 16 to 1024 GPU cores along with several discrete high-end configurable (meaning the core can be selected to encode/decode a variety of pre-existing standards) video/audio encode & decode cores (for the encoding and decoding of a multiplicity of video standards—e.g. MPEG2, MPEG4, VC-1, H.264 etc., at very high resolutions and with multiple channels of sound). Additional subsystems composed of processing cores are added to the motherboard in the form of communications cores (e.g. TCP/IP offload cores which themselves are typical built from one or more CPU cores and one or more packet processing cores. WiFi cores, Blue Tooth cores, WiMax cores, 3G cores, 4G cores which are from one or more CPU cores and one or more broadband/baseband processing cores).
Current high end of the spectrum devices such as supercomputers add an additional processor in the form of one to four FPGAs (field programmable gate array) per motherboard. Each FPGA is itself composed of hundreds of thousand to tens of millions of very simplistic CLB processing cores along with multiple hard IP or Soft IP CPU core and multiple DSP cores). Then these motherboards themselves are then replicated and interconnected in the hundreds to thousands to produce a modern supercomputer. These systems (either the desktops/workstations/laptops and/or the supercomputers) and then interconnected via the Internet to provide national and global computing capabilities.
The complexity of “managing” and “programming” such a diverse series of cores is a severe problem. Most programmers do not even attempt this and just settle for programming just one CPU core ignoring the rest of the cores. There are a certain number of algorithms know in the industry as “embarrassingly parallel problems” (e.g. the Google Search algorithm for example is simple to spread across multiple CPUs due to the fact that there is very little to no interactivity across the parallel threads). Unfortunately the vast majority of problems do not have these characteristics, they require a high degree of interactivity and synchronization across the multiple threads.
It would therefore be desirable to incorporate multithreading, unrestricted parallelism and deterministic behavior such as in modern programming language streams. Streams date at least to the introduction of the C programming language in 1978, and have been incorporated into such languages as C++, Java, Visual Basic and F#. However, in these languages, streams are relegated to a rather narrow role of providing a framework for I/O and file access. It is therefore desirable to expand the role of streams in parallel programming to first-class objects, a status roughly comparable to that of variables.
According to one example, a programmable core based computing device is disclosed. The computing device includes a plurality of processing cores coupled to each other. A memory stores stream-domain code including a stream defining a stream destination module and a stream source module. The stream source module places data values in the stream and the stream conveys data values from the stream source module to the stream destination module. A runtime system detects when the data values are available to the stream destination module and schedules the stream destination module for execution on one of the plurality of processing cores.
Additional aspects of the invention will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments, which is made with reference to the drawings, a brief description of which is provided below.
In a preferred embodiment, the ACE 100 does not utilize traditional (and typically separate) data, DMA, random access, configuration and instruction busses for signaling and other transmission between and among the reconfigurable matrices 150, the controller 120, and the memory 140, or for other input/output (“I/O”) functionality. Rather, data, control and configuration information are transmitted between and among these matrix 150 elements, utilizing the matrix interconnection network 110, which may be configured and reconfigured, in real-time, to provide any given connection between and among the reconfigurable matrices 150, including those matrices 150 configured as the controller 120 and the memory 140.
The matrices 150 configured to function as memory 140 may be implemented in any desired or exemplary way, utilizing computational elements (discussed below) of fixed memory elements, and may be included within the ACE 100 or incorporated within another IC or portion of an IC. In the exemplary embodiment, the memory 140 is included within the ACE 100, and preferably is comprised of computational elements which are low power consumption random access memory (RAM), but also may be comprised of computational elements of any other form of memory, such as flash, DRAM, SRAM, MRAM, ROM, EPROM or E2PROM. In the exemplary embodiment, the memory 140 preferably includes direct memory access (DMA) engines, not separately illustrated.
The controller 120 is preferably implemented, using matrices 150A and 150B configured as adaptive finite state machines (FSMs), as a reduced instruction set (“RISC”) processor, controller or other device or IC capable of performing the two types of functionality discussed below. Alternatively, these functions may be implemented utilizing a conventional RISC or other processor. The first control functionality, referred to as “kernel” control, is illustrated as kernel controller (“KARC”) of matrix 150A, and the second control functionality, referred to as “matrix” control, is illustrated as matrix controller (“MARC”) of matrix 150B. The kernel and matrix control functions of the controller 120 are explained in greater detail below, with reference to the configurability and reconfigurability of the various matrices 150, and with reference to the exemplary form of combined data, configuration and control information referred to herein as a “silverware” module.
The matrix interconnection network 110 of
It should be pointed out, however, that while any given switching or selecting operation of, or within, the various interconnection networks may be implemented as known in the art, the design and layout of the various interconnection networks, in accordance with the present invention, are new and novel, as discussed in greater detail below. For example, varying levels of interconnection are provided to correspond to the varying levels of the matrices, computational units, and elements. At the matrix 150 level, in comparison with the prior art FPGA interconnect, the matrix interconnection network 110 is considerably more limited and less “rich,” with lesser connection capability in a given area, to reduce capacitance and increase speed of operation. Within a particular matrix or computational unit, however, the interconnection network may be considerably more dense and rich, to provide greater adaptation and reconfiguration capability within a narrow or close locality of reference.
The various matrices or nodes 150 are reconfigurable and heterogeneous, namely, in general, and depending upon the desired configuration: reconfigurable matrix 150A is generally different from reconfigurable matrices 150B through 150N; reconfigurable matrix 150B is generally different from reconfigurable matrices 150A and 150C through 150N; reconfigurable matrix 150C is generally different from reconfigurable matrices 150A, 150B and 150D through 150N, and so on. The various reconfigurable matrices 150 each generally contain a different or varied mix of adaptive and reconfigurable nodes, or computational units; the nodes, in turn, generally contain a different or varied mix of fixed, application specific computational components and elements that may be adaptively connected, configured and reconfigured in various ways to perform varied functions, through the various interconnection networks. In addition to varied internal configurations and reconfigurations, the various matrices 150 may be connected, configured and reconfigured at a higher level, with respect to each of the other matrices 150, through the matrix interconnection network 110. Details of the ACE architecture can be found in the related patent applications, referenced above.
Another example of an adaptive computing machine 160 that may use the parallel computational model is shown in
The nodes 180 are each grouped in a quadtrees such as the quadtree 182. The quadtrees such as the quadtree 182 are implemented using 5-ported switch elements 184, each connected to a single parent and up to four children nodes 180. The switch elements implement a fair, round-robin arbitration scheme and provide pipelining with multi-level look-ahead for enhanced performance. In this example, the width of all paths is constant (51 bits), but the option is available to widen pathways as a tree is ascended, in the style of Leiserson's fat trees, in order to increase network bandwidth.
In this example all traffic on the network 162 is in the form of 51-bit network words as shown in the network word 188 shown in
In a preferred embodiment, each node wrapper includes a hardware task manager (HTM) 200. Node wrappers also include data distributor 202, optional direct memory access (DMA) engine 204 and data aggregator 206. The HTM coordinates execution, or use, of node processors and resources, respectively. The HTM does this by processing a task list and producing a ready-to-run queue. The HTM is configured and controlled by a specialized node referred to as a K-node 178 in
The node wrapper in
The execution unit 212 in
The nodal memory 210 is accessible to both the node wrapper and the execution unit 212. The nodal memory 210 is where the node wrapper deposits incoming streaming data and where the execution unit 212 accesses that data. A node's own memory 210, however, is typically not where the execution unit 212 sends output data. To minimize memory accesses, output data is usually sent directly to the node(s) requiring that data: the consumer node(s). Nodal memory 210 is also used to store task parameters and is available to tasks for temporary (scratchpad) storage.
In a multi-node system such as the ACM 160 in
The ACM 160 provides, via the Point-to-Point protocol, and the node wrapper in
Streaming data is transferred between two nodes 180 (points) via a point-to-point channel (point-to-point stream) 250 as shown in
The consumer task 264 receives PTP data from the PTP channel 252 via the input port on the consumer node 258. The circular input buffer 262 in the nodal memory of the consumer node 258 stores the incoming PTP data. A consumer task such as the consumer task 264 runs on the execution unit of the consumer node 258 and consumes a finite amount of the PTP data residing in the circular input buffer 262 per task activation (Task 2 in
Data is conveyed over the PTP channel 252 when the producer task 254 transfers a 50-bit point-to-point word 270 as shown in
The ACM 160 includes mechanisms for task management, flow control and load balancing. There is an input buffer associated with each input port. There is also a two's-complement signed count associated with each port, both input and output.
For an input port, the count is referred to as a consumer count since it reflects the amount of data in that port's input buffer that is available to be consumed by the associated task. A consumer count is enabled when its value is non-negative—that is, when its sign bit is 0. An enabled consumer count indicates that the associated input buffer has the minimum amount of data required by an activation of the associated task. At system initialization, or upon reconfiguration, a consumer count is typically reset to −C, where C is the minimum number of 32-bit words required per task activation.
For an output port, the count is referred to as a producer count since it reflects the amount of available space in the downstream input buffer to accept the data that is produced by the associated task. A producer count is enabled when its value is negative—that is, when its sign bit is 1. An enabled producer count indicates that the downstream input buffer has space available to accommodate the maximum amount of data produced per activation of the associated task. At system initialization, or upon reconfiguration, a producer count is typically reset to P−S−1, where P is the maximum number of 32-bit words produced per task activation and S is the size of the downstream input buffer in 32-bit words.
Both consumer counts and producer counts are typically initialized to negative values, causing the consumer counts start out disabled while producer counts start out enabled. This initial state reflects the fact that input buffers are usually empty at system initialization/reconfiguration.
Consumer and producer counts are updated by a system of credits and debits in the form of forward acknowledgements and backward acknowledgements. Both types of acknowledgements are network words such as the acknowledgment network word 280 shown in
The sequence of acknowledgements that a task performs at the end of each activation is described below. For each output port of the task, a forward acknowledgement is sent to the consumer node specifying the consumer input port and the consumer task. The Ack Value is the number of PTP words the task just sent to the consumer input port. A backward acknowledgement (a self ack) is sent to the node on which the task resides specifying the output port and the task. The Ack Value is the number of PTP words the task just sent via the output port.
For each input port of the task, a backward acknowledgement is sent to the producer node specifying the producer output port and producer task. The Ack Value is minus the number of 32-bit words the task just consumed from the input port's buffer. A forward acknowledgement (a self ack) is sent to the node on which the task resides indicating the input port and the task. The Ack Value is minus the number of 32-bit words the task just consumed from the input port's buffer.
The hardware task manager 200 shown in
Incoming acknowledgements update various counts and cause tasks to be launched as follows. If a forward acknowledgement is received, the specified port is interpreted as an input port, and Ack Value is added to the corresponding consumer count. If the consumer count makes a transition from disabled to enabled (enabled to disabled), then the input count of the specified task is incremented (decremented) by 1. If a backward acknowledgement is received, the specified port is interpreted as an output port, and the Ack Value is added to the corresponding producer count. If the producer count makes a transition from disabled to enabled (enabled to disabled), then the output count of the specified task is incremented (decremented) by 1. If after a forward or backward acknowledgement is received, the specified task's input and output counts are both enabled, then the task is placed on the ready-to-run queue if it is not already on the queue. The task is launched when it reaches the head of the queue.
These actions embody the firing rule for tasks. They cause a task to be placed on the ready-to-run queue and ultimately executed when a sufficient number of consumer counts and a sufficient number of producer counts are enabled. What those sufficient numbers are is determined by the initial values of a task's input count and output count. If I (O) is the number of input (output) ports associated with a task and ICinitial (OCinitial) is the initial value of the task's input (output) count, and if it is assumed all consumer counts are initially disabled and all producer counts are initially enabled as discussed above, then a task fires when
For example, for I=4,
For O=4,
The programming of the multi-processor system such as the ACE 100 in
In a Stream C program, there is only one mechanism for expressing concurrency: through the concurrent operation of the program's modules (and module-like stream expressions). Syntactically, modules are very similar to C functions, but semantically, they are different. A C function (subroutine) initiates activity only when it is called. In a call, control is passed to the C function, usually together with some input arguments. The C function then performs a task/computation, and when finished, returns control together with any output result. Unlike C functions, modules are not called nor is control passed to or returned from modules. Instead, modules carry on ongoing interactions with other modules and the outside world though their input and output ports. Through these ports, a module receives streams of input values and emits streams of output values.
The syntax of a module prototype is identical to that of a C function prototype, with three exceptions. First, the keyword, stream, precedes a module prototype. This tells the compiler/linker that each module input and module output is associated with a stream of values of the specified type, not an individual value. Second, to permit a module to have multiple output streams, the module return type may be replaced by a parentheses-delimited list that is identical in syntax to the input parameter list. Third, to extend the notion of an array to modules, a square-bracket-delimited list of array indices may be inserted immediately after the module name and before the input argument list. The module arrays are discussed below.
The following are two examples of module declarations:
Parameter names have been omitted here since they are not required in a module declaration (in contrast to a module definition or module instantiation), but Parameter names may be included at the programmer's discretion, usually as a mnemonic aid, for inputs and, when there are multiple outputs, for the outputs as well. The two declarations, for example, might then be expressed as:
The first declaration indicates that moduleA has two input streams, both of integer type, and a single output stream, also of integer type. The second declaration indicates that moduleB has two input streams, both of integer type, and two output streams, also both of integer type.
Like the definition of a C function, the definition of a module has a body delimited by curly braces ({ and}). Also as in the definition of a C function, each module input (and output in the case of multiple outputs) is assigned an identifier. The following are two examples of module definitions:
A module instantiation is the module counterpart to a C function call. Like a function call, a module instantiation is where a module gets used. While the syntax of these two types of expressions are similar, the semantics are different. A fragment of C code may be expressed as:
The first statement declares that x and y are integers, while the second declares that F is a function with two integer parameters and an integer result. The last statement is an assignment containing the function call F(4, x+5*y), which has two arguments, the expressions 4 and x+5*y, corresponding to the two parameters of F.
The stream version of this code fragment is as follows:
In the stream version, each of the statements above is prefaced with the keyword stream. The change in syntax produces a dramatic change in semantics. Instead of individual values, streams of values are used. Thus the first statement declares that x and y are integer streams, while the second declares that F is a module with two integer-stream inputs and an integer-stream output. The last statement is now an assignment containing the module instantiation F(4, x+5*y), which has two arguments, the stream expressions 4 and x+5*y, corresponding to the two parameters of F.
In the case of the function call, each execution of the assignment z=F(4, x+5*y) causes expressions 4 and x+5*y to be evaluated and the two resulting values to be supplied as parameters in a call to function F. After some period of time, F returns a value. In the case of the module instantiation, there is no execution of the assignment z=F(4, x+5*y) and no call to module F. Instead, an instance of module F is created (instantiated) at system initialization, just before the Stream C program begins execution, thereby making the instance ready to receive streams of integers on its two input ports and produce a stream of integers on its output port. And once program execution commences, the instance of F remains operative until program termination i.e., the instance of F is persistent.
This simple example illustrates the general mechanism used in Stream C to create a community of interacting modules. Each module instantiation causes a separate module instance to be created at system initialization. Once created (instantiated), a module instance is ready to receive streams of values on its input ports and produce streams of values on its output ports. Furthermore, once program execution commences, the module instance remains operative until program termination.
The general form of the instantiation of a module with multiple output ports is:
(<identifier-list>)<module-identifier>(<expression-list>)
While the input arguments are expressions, the output arguments are identifiers. These identifiers serve to name the otherwise nameless output streams. The stream assignment statement above plays the same role by assigning the name z to the otherwise nameless output stream of F(4, x+5*y). For example:
As before, F has two integer-stream inputs, but in contrast to the earlier example, F now has two integer-stream outputs. Those two output streams appear in the instantiation of F as the list of identifiers (w, z), which serves to give the two output streams the names w and z.
Statements within a module body fall into two categories (or domains), stream statements that involve only streams and thread statements that include the entire range of C statements as well as statements that allow a thread to read from and write to streams. Because each module instantiation causes a separate module instance to be created at system initialization, Stream C does not allow a module to have within its body, or within the body of a submodule, an instantiation of itself. In other words, circularity in module references is not allowed. This prohibition helps avoid the difficult task of instantiating an infinite number of module instances.
In a Steam C module, there is no notion of returning control, and so the return statement is inappropriate. In a module, output values are simply inserted into a module output stream. But in order to do that, the output stream must have a name. For modules with a parentheses-delimited list of named output streams, that's not a problem. It is a problem, however, when the module prototype provides only the type of the module's sole output stream. In that case, code in the module's body, either in the stream domain or thread domain, can use the keyword out as the name of the default module output stream. This usage is illustrated in the following code fragment.
Modules and the streams they are partnered with provide the framework for the web of interactions and concurrent activity typical of a Stream C program, while functions provide the computational building blocks of a program. Although modules deal with streams of values, that does not prevent modules from accessing individual values within a stream and supplying those values to a function. Likewise, a module can access the output value of a function and insert that value into a stream. A function, on the other hand, cannot reference a module because there is no mechanism within a function for such interaction. Because of this asymmetry in capabilities, modules are found at the higher levels of a program hierarchy, while functions are found at the lower levels.
While the differences between modules and functions are substantial, there is one area in which they are similar. They both support side effects, that is, they both may manipulate external data structures independently of their input and output ports. This stems from the fact that modules may contain threads that may have side effects.
A variety of different algorithms can be used to perform the Module to Core Mapping. These may include cache proximity where modules which share the greatest number of streams are placed in cores which share a L1 cache followed by a shared L2 cache followed by a shared L3 cache followed by a shared DRAM. They may also include a physical proximity algorithm where modules which share the greatest number of streams are placed in cores which are physically adjacent to each other. For example the algorithm may start with the die and then the integrated circuit on the motherboard, then the motherboard in the rack, then the rack in the floor of the building, then the building geographically adjacent. Another algorithm may be the next available free where modules are allocated to cores based on the next “free” core based on either CPU usage (current or average weighted over time) or the next sequentially available core. Another algorithm may be a predictive load that selects the modules and cores based on estimated statistical sampling. A running average of core utilization is used to load modules to the lightest loaded core. Another algorithm may be user specified where a user specified virtual core ID is used to place all modules onto a physical core ID. When the number of virtual core ID's exceeds the physically available cores then multiple modules are evenly loaded across all available physical cores.
The term stream in the Stream C programming language refers to a sequence of data values, all of the same type and typically made available over time. In Stream C, however, streams provide much more than a framework for input and output. Streams are elevated to first-class objects, a status roughly comparable to that of variables. This means that a stream may be bound to an identifier (i.e., it can be named), an input parameter of a function (i.e., an input parameter of a module), the output of a function (i.e., an input parameter of a module), a parameter within an expression and the output of an expression
A stream conveys values of a single type from one or more stream sources to one or more stream destinations. The precise details of how this transport is accomplished is implementation dependent, and depends upon, among other things, whether the stream is confined to a single semiconductor die or whether the stream spans several meters or possibly even thousands of kilometers. Except when dealing with performance issues, a programmer need not be concerned with those details, and need only be concerned with those aspects of a stream that relate to four stream attributes: the stream type, the stream name, the stream sources and the stream destinations.
The stream type indicates the type of values being conveyed. The type which may be any legitimate C type, including pointers and types defined via typedef, may be specified implicitly by context for example, by appearing as a module input or output parameter or explicitly using a stream declaration as described below.
The stream sources are the points at which values are placed into the stream. Possible stream sources are include an input parameter of a module definition, an output of a module instantiation, the output of a stream expression and a thread (discussed below). The stream destinations are the points to which the stream conveys values. Possible stream destinations include an output parameter of a module definition, an input argument of a module instantiation, an input of a stream expression and a thread. An optional stream name is a name/identifier is assigned to a stream when the stream appears as a module input or output parameter or when it is introduced in a stream declaration. An example of an unnamed stream is the output stream of a stream expression that has not been assigned a name via a stream assignment.
The notion of stream attributes is illustrated in the following code fragment containing a declaration of a function F and a partial definition of a module M.
There are three named streams here: xStrm, yStrm and zStrm, all of type int. xStrm and yStrm each have a single source: an input parameter of module M. The destinations of xStrm and yStrm are represented by the two instances of xStrm and yStrm, respectively, appearing in the assignment expression in the body of M. (Recall that, in C, an assignment is also an expression.) Those instances represent inputs to the assignment expression. xStrm and yStrm thus each have a single source and two destinations.
A stream expression is identical to a C expression, except that in place of variables, there are now input streams. A stream expression also has an output stream, which carries the results from expression evaluations. By default, this output stream is nameless, but it can be assigned a name using a stream assignment, which is just what we've done in the above assignment. Thus the output stream of the stream expression
xStrm*yStrm+F(xStrm,yStrm)
is assigned the name zStrm by the stream assignment
zStrm=xStrm*yStrm+F(xStrm,yStrm)
Either of these two expressions may be considered the source of zStrm. The destination of zStrm is the output stream of module M, which is denoted by the output parameter zStrm of module M.
stream(int zStrm) M(int xStrm, int yStrm)
xStrm thus has a single source and a single destination.
The most crucial properties of a stream relate to the stream's role as a conveyor of values. There are four such properties: a) values do not enter a stream except at stream sources or at system initialization using the initialize ( ) function; b) Values entering a stream at a single source are totally ordered in time; c) once entered into a stream, a value is eventually delivered to all stream destinations; if there are multiple destinations, then a separate copy of the value is delivered to each destination; and d) values from a single source are received at each stream destination in the same order in which they entered the stream i.e., there is no leapfrogging of values in a stream. These four properties are the only guarantees that a stream provides regarding the transport of values. Any other property that does not follow as a logical consequence from these four is not a general stream property.
Because a stream is obliged to only deliver values eventually, the latency of a stream, the time it takes a value to travel from a stream source to a stream destination, is indeterminate. In fact, the latency may vary with time and between different source-destination pairs of the same stream. Fixed or at least, bounded latencies, however, can still be achieved by relying upon guarantees provided by the system implementation (rather than the programming model). A source-destination pair confined to a single semiconductor die, for example, will usually have bounds on its latency.
The above four properties also have implications for stream determinacy and indeterminacy (non-determinism). For a stream with a single source, the four properties ensure deterministic stream behavior. That means that the order in which values are placed into a single-source stream completely determines the order in which values are delivered to all stream destinations. For a stream with multiple sources, however, the situation is very different. To illustrate the issues arising from multiple stream sources, consider the following adaption of the code fragment from the preceding section. (out is the default output stream of a single-output module).
The two input parameters of module M are the same: xStrm. From the four properties, values entering xStrm through the first input parameter of module M will be received at each of the three destinations of xStrm in the same order in which they entered the stream. Values entering xStrm through the second input parameter of module M will be received at each of the three destinations of xStrm in the same order in which they entered the stream. That means that the two streams of values are merged or interleaved before reaching each destination of xStrm.
How interleaving is carried out is influenced, in general, by program structure. The missing parts of the program above, for example, may be structured in a way that leads to an interleaving that strictly alternates between parameter-one and parameter-two values. So, for example, if the integers arriving on the two input parameters (streams) xStrm of module M begin with the sequences:
then the sequence arriving at each of the three destinations of xStrm in the expression
out=xStrm*xStrm+F(xStrm)
might begin with
Such program-imposed determinism though is not always the case, and there are situations in which values from multiple steam sources are interleaved non-deterministically. Moreover, depending on the target system, those nondeterministic interleavings may differ from one stream destination to another. Thus, for example, if the values arriving on the two input parameters (streams) of module M are the same as above, then the sequence arriving at the three destinations of xStrm might begin with:
This indeterminacy in order of arrival of values at the destinations of a multi-source stream contrasts with the fixed order of arrival across all destinations of a single-source stream. That fixed arrival order allows adopting notation that is useful in below. For a single-source stream ssStrm and a non-negative integer
When a value arrives at a stream destination, if the destination is an output parameter of a module definition or an input argument of a module instantiation, then the value is handed over to a stream on the other side of a module boundary. The value thus remains in transit. If the destination is an input of a stream expression or a thread then the value comes to rest in a FIFO queue.
To illustrate remaining in transit, the following code fragment is shown.
The code fragment includes two modules, module1 and module2, each with a single input stream and single output stream and two named streams, xStrm and yStrm, both within the definition (body) of module2. The sole destination of xStrm: module1(xStrm) is an input argument of an instantiation of module1. A value arriving at this destination is simply passed across module1's boundary to an internal stream of module1. The situation is similar for values arriving at the sole destination of yStrm:
stream (int yStrm) module2(int xStrm)
Since this destination is an output parameter of a module2, arriving values are simply passed across module2's boundary to a stream external to module2.
Another example is the case where a stream destination is an input of a stream expression such as the following code fragment.
Within the body of module M is the stream expression
xStrm*yStrm+F(xStrm,yStrm)
which contains two destinations of xStrm and two destinations of yStrm. It also contains the two operators * and + and the function F, which are ordinary C constructs. That means that in order to evaluate this expression, the two operators and the function F must be supplied with individual values.
The queues are automatically inserted by the Stream C linker/loader and are managed by the Stream C runtime. Among the responsibilities of the runtime is signaling when a queue is empty and ensuring that no queue ever overflows. Each queue is guaranteed to have a capacity of at least two values of the associated data type, although a programmer may request a specific amount via a pragma as described below. In the stream of this example, there are four queues, one for each of the four stream destinations (stream expression inputs). These queues are largely invisible to the programmer.
Once a Stream C program begins executing (operating), the only way for a value to enter a stream is through a stream source. One of more streams may form a directed cycle which requires a value already in the stream. The simplest such cycle occurs when a stream appears on both sides of a stream assignment as in:
xStrm+=yStrm
which is equivalent to
xStrm=xStrm+yStrm
Another issue relates to changing the offset of one single-source stream relative to another single-source stream. For example, if aStrm and bStrm are both inputs to the same module or stream expression, as in
aStrm+bStrm
which is represented graphically in
The solution to both issues is provided by the stream initialization statement, which has the form
<stream-identifier>.initialize(<value-list>);
When the Stream C compiler/linker/loader encounters this statement, it takes the statement as a directive to insert a FIFO queue at each destination of <stream-identifier> whether the destination is an output parameter of a module definition, an input argument of a module instantiation, an input of a stream expression or a thread; size the queue at each stream destination so that it is sufficient to hold at least n+1 values of type T, where n is the number of values in <value-list> and T is the type of <stream-identifier>; and place the values in <value-list> into the queue in order, with the first value in <value-list> placed at the front (head) of the queue.
For example, in
xStrm.initialize(0);
This statement causes two FIFO queues to be created, one for each destination of xStrm. (the queue at the destination of the feedback path will already have been inserted as described in the preceding section). Assuming that xStrm is of type int, then the size of each queue is at least 2*sizeof(int), and at the head of each queue at system initialization is the int value 0. This is illustrated graphically in the flow diagram 402 in
Changing the offset of aStrm relative to bStrm in a second graphic representation 412 in
aStrm.initialize(1, 2);
The effects of this initialization are illustrated graphically in the representation 412 in
As is the case for C variables, all streams must be declared before being used, although certain stream declarations are made implicitly by context, for example, by appearing as module input or output parameters. For explicit stream declarations, the syntax follows that for C variable declarations, but with the declaration now beginning with the keyword stream:
stream <storage-class-specifier>optional <type> <identifier-list>;
Some examples of stream declarations without a storage class specifier are:
Of the five storage class specifiers in C-auto, register, static, extern and typedef—only static is permitted in a stream declaration, as in
stream static int xStrm, yStrm;
The semantics of a static, as well as a non-static, stream declaration is determined by the context in which the declaration appears. There are three such contexts, each with its own scope rule. In each case, the stream-declaration scope rule is identical to that of the variable-declaration counterpart. For a stream declaration, with no storage class specifier and appearing inside a module, the declaration scope extends from the declaration to the end of the module. For a stream declaration, with no storage class specifier and appearing outside all modules (and functions), the declaration scope is global—that is, it is visible to the entire program. For a stream declaration, with the static storage class specifier and appearing outside all modules (and functions), the declaration scope extends from the declaration to the end of the source file in which the declaration appears.
Absent from this list are several declaration forms involving storage class specifiers that pertain to variables but not streams. In C, automatic variables, those variables declared with the auto storage class specifier or with no specifier at all, lose their values between function invocations. But since streams do their work only within modules and since modules are not invoked (they are always active), automatic streams are an incongruous concept. The auto storage class specifier is therefore not applied to stream declarations.
A variable declaration with the static specifier and appearing inside a function indicates that the declared variable retains its value between function calls (function invocations). In the case of modules, however, there is no notion of a call, and so the static specifier has no meaning inside a module. The static specifier is therefore not used within module scope.
For variable declarations, the extern storage class specifier helps to distinguish those declarations of global variables that act as declarations and definitions from those that act as merely declarations. In the case of streams, however, a declaration is never a definition because a stream declaration never causes storage to be set aside. Storage is allocated only at stream destinations as described below in the section on Stream FIFOs. The register and typedef storage class specifiers have no relevance to streams and do not appear in stream declarations.
Stream expressions are the stream counterpart to ordinary C expressions. Apart from substituting input streams for all variables and an output stream for the result, the two types of expressions are very similar. Expressions combine variables and constants to produce new values while stream expressions combine streams and constants to produce new streams. The structure of C expressions and stream expressions are nearly identical. All C operators are valid operators in stream expressions. The same operator precedence applies in both C expressions and stream expressions. C function calls are permitted in stream expressions, just as they are in C expressions. Instantiations of modules with a single output stream are permitted in stream expressions, and are treated similarly to function calls.
The differences between C expressions and stream expressions lie primarily in when and how they are evaluated. A C expression is evaluated when the thread of control reaches the statement containing the expression. The evaluation is carried out by first replacing each variable by its current value and then performing the requisite operations according to the rules of operator precedence. The value returned by the final operation is then supplied as the evaluation result.
Unlike evaluation of C expressions, evaluation of stream expressions in the C Stream programming language is not tied to a thread of control. Instead, stream expressions are evaluated opportunistically. As before, evaluation is carried out by performing the requisite operations according to the rules of operator precedence. Instead of substituting values for variables, a value is consumed (popped) from each FIFO queue belonging to an expression input. A FIFO queue is inserted at all stream destinations that are inputs of stream expressions. The evaluation is opportunistic because it is performed whenever there is at least one value in each input FIFO queue of the expression. The result produced by the evaluation, as before, is the value returned by the final operation of the evaluation. That result, however, is handled differently from the C expression case. For a C expression, the use to which the result is put is determined by the context of the expression. For a stream expression, the result is simply placed into the expression's output stream (which may or may not have a name, depending upon whether the expression is an assignment).
An example of the stream expression may be shown in the following expression in which xStrm, yStrm and zStrm are all streams of type int.
xStrm*yStrm+5*zStrm
The values arriving on the three streams begin as follows:
The first three values placed into the (unnamed) output stream of xStrm*yStrm+5*zStrm are then:
Among stream expressions, stream assignments are of special interest. There are two types of such stream assignments, the first type has the form
<stream-identifier>=<stream-expression>
Like their C counterparts, assignments to variables, stream assignments of this type have a side effect. In addition to supplying values to its output stream, a stream assignment makes the output of the right-hand-side (RHS) expression a source of the left-hand-side (LHS) stream, and in the process makes the output stream of the RHS expression the output stream of the assignment. The stream assignment also gives a name to the otherwise nameless output stream of the RHS expression. Although a name is not needed for the output stream of a subexpression of a larger expression, a name is essential when the output stream must be directed to a destination outside any enclosing superexpression.
The stream assignment statement in the following code fragment is an example. A stream expression, assignment or otherwise, becomes a stream statement when it is followed by a semicolon.
The expression, F(xStrm, G(yStrm)) and the subexpression, G(yStrm) each have an output stream as stream expressions. In the case of G(yStrm), the output stream is unnamed since the destination of the stream is clear from the context of the expression: the destination is the second input argument of the function F in the superexpression F(xStrm, G(yStrm)). In the case of the output stream of F(xStrm, G(yStrm)), however, a name is required since the destination is outside the expression. That name is assigned in the assignment expression
out=F(xStrm,G(yStrm))
With this assignment, the output of F(xStrm; G(yStrm)) becomes a source of zStrm, which has a single destination, the output parameter of Module M.
The second type of stream assignment is of the form
(<comma-separated-list-of-stream-identifiers>)=<module-instantiation>
It arises when it is desirable to make the outputs of a multi-output module the sources of multiple named streams. To illustrate, the following multi-output module:
stream (int, int) tap(int, int, int);
If the first output of tap is the source of int stream x, and the second output of tap is the source of int stream y. That is accomplished with the stream assignment
(int x, int y)=tap(arg1, arg2, arg3);
The assignment makes the ith output of the module a source of the ith stream and gives names to the otherwise nameless output streams of the module.
Statements within the body of a module fall into two categories (domains), thread and stream. Stream statements deal with streams but not variables. Thread statements deal with variables, and, in a few cases, with streams as well. Statements in the thread domain are mostly C statements, and like C statements, they are imperative (procedural) in nature defining a step-by-step procedure. Associated with such a procedure is a sequential flow of control, often called a thread, which governs the order in which statements are executed. Stream statements, in contrast, are declarative. Each such statement makes a declaration about the streams appearing in the statement. There is no notion of a step-by-step procedure, as there is in the thread domain, and the order of stream statements within a module body is therefore immaterial with one exception. Just as variables must be declared before being used, so too streams must be declared before being used.
Because of the nature of the stream domain, there are no counterparts to those C statements that deal with control flow, specifically, if-else, else-if, switch, for, while, do-while, break, continue, goto and return. In fact, the only statement type in the stream domain is the stream counterpart to the C expression statement, and, as in C, the most common expression statement is the assignment statement. A stream expression statement has one of the two forms
while a stream assignment statement has one of the two forms
An example application using modules, stream initialization, stream declarations, stream expressions and stream statements is a finite-impulse-response (FIR) filter, a commonly used construct in digital signal processing. A FIR filter transforms a discrete-time input signal into a discrete-time output signal.
A discrete-time signal is represented as a stream of samples. The multipliers 508 and adders 510 are each represented as a stream expression. The unit delay is represented by stream initialization. By initializing one stream with one or more values, the values are offset (delay) in that stream relative to the values in a second stream. This is the principle underlying operation of the UnitDelay module.
In the body of unit Delay, the stream assignment statement
out=x;
makes X, the input stream of Unit Delay, the source of out, the default output stream of UnitDelay, while the stream initialization statement:
out.initialize(0);
inserts the value 0 into out at system initialization. This initial value in out has the effect of offsetting (delaying) all subsequent values in out by one value.
The following is a Stream C implementation of a 5-tap FIR filter such as the filter 500 in
This implementation exhibits concurrency but does so without any explicit concurrency constructs. The concurrency simply falls out from code that, except for the multiple, named outputs of tap, resembles ordinary sequential code. In place of variables, there are now streams.
Each of the four instantiations of tap within the body of FIR5 is computing its own copy of the formula
yIn+h*xOut
concurrently with the three other instantiations of tap. That is made possible by the opportunistic nature of stream expressions and by the continuing arrival of new input values to each of the instantiations of tap. Those new values are supplied by seven internal streams of FIR5.
X conveys values from the input of FIR5 to inputs of the first tap
x2 and y2 convey values from outputs of the first tap to inputs of the second tap
x3 and y3 convey values from outputs of the second tap to inputs of the third tap
x4 and y4 convey values from outputs of the third tap to inputs of the fourth tap
The h input of each instantiation of tap is replaced by a constant. That causes the Stream C compiler to replace all instances of h within a tap instantiation with the constant. All of the computations performed by the instantiations of tap are in service to the transformation of FIR5 input values into FIR5 output values. Those final output values are supplied by the default output stream of FIR5.
out conveys values from an output of the fourth tap to the output of FIR5
This implementation is an example of how many digital-signal-processing functions are dealt with in Stream C.
In the FIR-filter example above, the five coefficients, 10, 20, 30, 40, 50, are known at compile time. However, if the FIR5 coefficients aren't known at compile time or if the coefficients, although constant for extended periods, do change from time to time, another technique needs to be employed. In such a case, these quasi-constants are not true constants because they do change, and they are not true streams because their values are not consumed (popped from a FIFO queue) by a stream expression or by a thread.
A quasi-constant stream is similar to an ordinary stream in several respects. It has a type, one or more sources, one or more destinations and a name. It conveys values of the specified type from the specified sources to the specified destinations. However, a quasi-constant stream differs from an ordinary stream in several ways. Where an ordinary stream would have a FIFO queue, a quasi-constant stream has storage for one value of the specified type (much like the storage associated with a variable). The value residing in that storage is neither popped nor consumed when accessed by a stream expression or thread, but instead remains resident in storage. The stored value is updated when a new value enters the stream through one of the stream sources. When that happens, the new value simply overwrites the old value. Because this updating is typically done asynchronously with system operation, the point at which the update is recognized at the stream destination is, in general, indeterminate. The declaration of a quasi-constant stream must specify an initial value to be stored at each stream storage location at system initialization.
A quasi-constant stream is declared, either in a standalone declaration or in the input or output parameter list of a module, using the following syntax.
const<stream-type><stream-identifier>=<initial-value>
The existing C keyword const, which ordinarily applies only to variables, indicates that the stream being declared is a quasi-constant stream. (The use of const saves having to introduce a new keyword).
These ideas are illustrated in the following modification of the FIR5 module. Here, the five coefficients 10, 20, 30, 40 and 50 of the original example have been replaced by the five quasi-constant streams h0, h1, h2, h3 and h4. Since the initial values inserted into these streams at system initialization are the same as the original coefficients, the new FIR5 starts operation with the same coefficients as the original. With the new FIR5, however, those coefficients may be updated if conditions warrant.
An example of a high level scheduling algorithm for the input stream FIFO as in
An example of a high level scheduling algorithm for the output stream FIFO as in
An example of a high level scheduling algorithm for input and output stream FIFO as in
Threads provide capabilities crucial to making Stream C a complete and well-rounded language. Threads may appear either within the body of a C function (i.e., a function whose inputs are individual values and whose output is a single value) or within the body of a module (i.e., a function whose inputs and outputs are streams of values). The two types of threads are identical except that threads in the body of a module may, and usually do, access Stream C streams, and for that reason they usually do not terminate. Also, threads in the body of a C function do not access Stream C streams, and like all (well-behaved) C threads they do terminate.
The distinguishing characteristic of a Stream C thread is its complete decoupling from concurrency issues. There are no concurrency constructs, no direct interactions with other threads and no spawning of new threads. A Stream C thread is thus oblivious to the fact that, in general, it is operating in a multi-threaded environment. A programmer working in the thread domain can therefore focus on a strictly sequential problem.
Function declarations and function definitions in Stream C have the same syntax and semantics as their counterparts in C. For a function call in Stream C, the syntax and semantics depend upon whether the call appears in: (a) the body of a function or (b) a stream expression. A Stream C function call in the body of the same (recursive) function or the body of another function has the same syntax and semantics as a regular C function call. A Stream C function call in a stream expression has the same syntax as a C function call but with streams replacing variables in the function-call arguments. The semantics of such a call are similar, but not identical, to those of a regular function call. The differences relate to how each evaluation (call) of the function is performed. More specifically, they concern: (1) how values are obtained for the parameters (streams) appearing in the function-call arguments, (2) the destination of the function-call output, and (3) how control is handled.
In C, the parameters appearing in the arguments of a function call are all variables, and the value substituted for each such function input variable is the current value of that variable. In Stream C, the parameters appearing in the arguments of a stream-expression function call are all streams, and the value substituted for each such function input stream is either: (a) the value popped (consumed) from the FIFO queue at that stream destination, in the case of a regular stream, or (b) the current value at that stream destination, in the case of a quasi-constant stream.
In C, the value returned by a function call is passed to the caller. In Stream C, the value returned by a stream-expression function call is placed into the function-call output stream, which may be either named or unnamed. As a stream expression itself, a stream-expression function call always has an output stream. The destinations of the output value are determined by the destinations of the stream.
In C, a function is called when the thread of control encounters a call to that function. In Stream C, a stream-expression function call is evaluated (i.e., the function is called), without regard to a thread of control. Instead the function is called opportunistically whenever there is at least one value in the FIFO queue of each regular input stream of the function call. Quasi-constant input streams are always prepared to supply a value, and so they never block a function call or evaluation of a stream expression.
Apart from these three differences, the semantics of regular C function calls and stream-expression function calls are identical. That means that in both cases, the usual thread-based semantics applies to function execution.
An example of threads in C Stream may be shown with the following definitions of the function GCD and the module GCD4.
GCD, a classic example of a recursive function, returns the greatest common divisor of two integers. It has two integer inputs, a and b, and returns an integer result. GCD4, is a module with four integer-stream inputs, w, x, y and z, and an integer-stream output. Within the body of GCD4, is the stream-expression statement
out=GCD(GCD(w,x),GCD(y,z));
and within this statement is the stream expression
GCD(GCD(w,x),GCD(y,z))
Since this expression contains the destinations of streams w, x, y and z, there is a FIFO queue at each of those four destinations. Those queues permit the function calls GCD(w, x) and GCD (y, z) to be evaluated (executed) opportunistically and concurrently as described above. Like these two calls, the third call to GCD is performed opportunistically with input values being obtained from the FIFO queues of its two input streams. Those input streams originate as the output streams of the two other calls to GCD, the FIFO queues on those two streams allowing the third call to GCD to be performed concurrently with the first two. The output stream of this third function call is directed by means of the stream assignment to out, the output stream of GCD4. This arrangement of function calls to GCD, which is represented as a data-flow graph in
From the stream point of view, it's immaterial how a module transforms input stream values into output stream values. All that matters are the transformation(s) from inputs to outputs (and any side effects). In the examples presented so far, these transformations have been represented in terms of stream expressions, expressions which may be implemented using application-specific hardware, reconfigurable hardware (such as that in
These transformations may be represented explicitly as sequential code residing in the body of a module. Such code executes on a stored-program sequential processor, and exists in what may be referred to as the thread domain. Although the body of a module will typically contain statements exclusively in either the stream domain or the thread domain, that does not preclude the presence of both types of statements in the same module body. In that case, the two domains operate side by side (i.e., concurrently).
The syntax and semantics of the thread domain are a superset of C as defined informally by Brian W. Kernighan and Dennis M. Ritchie, “C Programming Language,” (1978) and formally by the ISO C standard ISO/IEC 9899. The additions to standard C involve operations that allow a thread to access those streams that are visible to the thread, either module input streams, module output streams, streams internal to the module body or global streams. Those stream-access operations are divided into two categories: blocking and non-blocking. To understand those operations, the mechanisms used to regulate the flow of values in streams and the mechanisms for managing tasks (a task is equivalent to a module instance) are significant as described above with reference to the node wrapper in
Flow control and task management are key services provided by the Stream C run-time-support system. Flow control prevents FIFO queue overflow (i.e., the writing of data to a queue that is already full) and FIFO queue underflow (i.e., the reading of data from a queue that is empty). Task management controls when tasks are placed into execution and, in some cases, when task execution is terminated. There are three key elements of the Stream C flow control and task management systems: consumer counts, producer counts, and task managers.
An integer consumer count is associated with each FIFO queue of a regular (non quasi-constant) stream. All reads by a particular thread of a particular stream access the same FIFO queue and, therefore, the same consumer count. The consumer count sign bit indicates whether the FIFO queue is empty. A sign bit of 1 (the consumer count is negative) indicates that the queue is empty. A sign bit of 0 (the consumer count is non-negative) indicates that the queue is nonempty.
An integer producer count is associated with each source of each regular (non quasi-constant) stream. The producer count sign bit indicates whether there is space available in all downstream FIFO queues to receive a value inserted at this stream source. A sign bit of 0 (the producer count is non-negative) indicates that not all downstream queues have space to receive a value this output stream. A sign bit of 1 (the producer count is negative) indicates that all downstream queues have space to receive a value this output stream.
Each processing core such as the nodes 180 in
Blocking stream-access operations allow a thread appearing in a module body to access streams visible to the thread such as module input streams, module output streams, streams internal to the module body and global streams. These are the preferred methods for accessing streams because, unlike their non-blocking brethren, they introduce no non-determinism. The blocking and unblocking of such operations is handled automatically by a processing core's task manager.
There are three such operations, each patterned after a similar operation in C++. The >> operator is used to pop (consume) a single value from a stream FIFO queue and assign that value to a variable. It is used in statements of the form
<stream-identifier>>><variable-identifier>;
The statement causes a single value to be popped from the stream on the left and assigned to the variable on the right. If, however, the FIFO queue for the stream is empty as indicated by the sign bit of the stream's consumer count, the statement blocks (stalls) and remains blocked until queue becomes nonempty again, as indicated by the sign bit of the stream's consumer count.
The <<operator is used to place the current value of a variable into a stream. It is used in statements of the form
<stream-identifier><<<variable-identifier>;
The statement causes the current value of the variable on the right to be placed into the stream on the left. If, however, one or more downstream queues do not have space to receive such a value, as indicated by the sign bit of producer count at the stream source, the statement blocks (stalls) and remains blocked until all downstream queues have space to receive the value again, as indicated by the sign bit of the stream's producer count.
The peek operator is used to obtain the value at the head of a stream FIFO queue without popping (consuming). It is used in expressions of the form
Like their blocking cousins, non-blocking stream-access operations allow a thread appearing in a module body to access streams visible to the thread such as module input streams, module output streams, streams internal to the module body and global streams. However, unlike blocking operations, non-blocking operations typically involve race conditions that affect the outcome of the operations and therefore introduce non-determinism. There are two such operations:
An expression of the form
An expression of the form
While threads within module bodies may take many different forms, many will be variations of the following typical form.
Here, moduleA is a module with one or more input streams and a single output stream. The input and output stream types are arbitrary chosen to be integers. The first thing the thread within the body of moduleA does is declare a variable for each input stream and a variable for the single output stream. The thread then enters an infinite loop in which each iteration involves: (a) reading in (consuming) a value from each input stream, (b) computing (producing) a result and (c) placing that result into the output stream.
As in other languages, arrays play an important role in Stream C, but not just arrays of data elements, but also stream arrays and module arrays. Arrays of actual data values (not pointers to arrays of data values) are conveyed concurrently over multiple streams. Stream arrays are especially valuable when used in conjunction with arrays of modules.
Stream C inherits its syntax and semantics for data arrays from C. That means that when the name of an array is used as (a function) argument, the value passed to the function is the location or address of the beginning of the array, there is no copying of array elements. The same is true for the stream inputs (arguments) and outputs of a module. To illustrate, the GCD4 module from above may be used.
Instead of supplying GCD4 with four separate integer-stream arguments, it is supplied with a single stream argument in which each value is an array of four integers. GCD4 would then be transformed into:
In accordance with C conventions, the single argument of GCD4 is of type int*, that is, a pointer to an integer, and in this case, the first integer in an array of four integers. Those four integers are accessed within the body of GCD4 using the standard C operator [ ]. Supplying C-type data arrays to a module is one way to deal with arrays in the context of streams.
For some applications, supplying a module with a stream of array pointers is insufficient to fully exploit the concurrency inherent in the application. An array of streams, rather than a stream of arrays therefore permits arrays of actual data values, not pointers to arrays of data values, to be conveyed concurrently over multiple streams. Declaring a stream array is identical to declaring a regular C array, with two differences, the keyword stream precedes declaration and the size of the array must be known at compile time. This restriction is necessary since, like modules, all streams within an application are instantiated at compile time.
Examples of stream-array declarations are:
The first declaration declares array1D to be a one-dimensional array of 4 integer streams. Similarly, array2D is declared to be two-dimensional array of 64 integer streams, and array3D a three-dimensional array of 576 integer streams. Individual streams of a stream array are accessed in the same way as individual elements of a data array. For example,
Once a stream array is declared, the entire array, subarrays of the array or individual streams within the array may be referenced. These three cases are illustrated in the following code fragment.
Here, declarations for moduleA, moduleB and moduleC, and a partial definition of moduleD are shown. The input types of the four modules are:
The input arguments supplied to the instantiations of moduleA, moduleB and moduleC within the body of moduleD are as follows.
In each case, the module-instantiation argument type matches the module input type, and each module instantiation therefore satisfies the strong-typing requirement of Stream C.
Accessing individual streams of a stream array within a stream expression is also straightforward, as illustrated in this example of a complex-multiply module.
Because operators within stream expressions are concurrently active, the four multiplies, one addition and one subtraction in the stream expressions X[0]*Y[0]−X[1]*Y[1] and X[0]*Y[1]+X[1]*Y[0] are evaluated concurrently.
Data parallelism, one of the more popular approaches to parallel processing, is a form of parallelism in which the same task is performed concurrently (in parallel) on different pieces of the same data structure, which is typically an array. In Stream C, data parallelism is supported by module arrays.
A module array is, as its name implies, an array of modules. It is declared by inserting the array dimensions, in square brackets, between the module name and the list of inputs parameters. The following are two examples of module-array declarations:
In both cases, the array dimensions are 3×4.
Like the definition of an ordinary (standalone) module, the definition of a module array has a body delimited by curly braces ({ and}). The following are two examples of module-array definitions. The first has a single (default) output stream, while the second has two named output streams.
Once a module array is declared (either in a declaration or a definition), the entire array, subarrays of the array or individual modules within the array may be instantiated within a stream statement in the same manner as data arrays and stream arrays. These three cases are illustrated here for moduleA[3][4].
The key attribute of a module array comes to the fore when the array is instantiated at system initialization. Each element of a module array is instantiated as a separate module instantiation, thereby permitting all array elements to operate concurrently. ModuleA[3][4] is an example of this concept. When the module is instantiated, 12 (=3×4) separate instantiations of moduleA are created, each operating concurrently with the 11 other instantiations. Furthermore, this multiplication of instantiations applies to each instance of moduleA[3][4]. Thus if there are three instances of moduleA[3][4], then 36 (=3×12) separate instantiations of moduleA are created.
The personalization of a module-array instantiation determines what data the instantiation operates upon. The instantiation may be personalized by supplying each module instantiation with its own unique data through the instantiation's input streams. The instantiation may also be personalized by allowing each module instantiation to identify its array indices using the index operator, thereby enabling the instantiation to access its own unique part of a global array.
The first type of personalization is illustrated below, where the stream arrays may be used to supply unique data to each element of a module array. The second type of personalization exploits the fact that the array indices of each array-module instantiation are known at compile time. To access those indices, the programmer uses an operator with the following syntax:
int index(int i)
where i is an integer expression that evaluates to a constant at compile time. At compile time, index (i) is replaced the ith index of the instantiation. A compile-time or run-time error occurs if i is outside array bounds.
Stream arrays and module arrays find their greatest utility when they are coupled using a special array-coupling feature of Stream C. There are three requirements for a coupling: a) the stream array and module array must have the same dimensions; b) the stream array must be connected (coupled) to a module-array input or output; and c) the stream-array type must match the module input/output type.
When such a coupling occurs, each individual stream in the stream array is connected (coupled) to the input/output stream of the individual module in the module array with the same indices. Thus, if the stream array S[D1][D2] . . . [Dn] is coupled to an input/output of the module array M[D1][D2] . . . [Dn], then each individual stream S[i1][i2] . . . [in] is connected to an input/output of the individual module M[i1][12] . . . [in] for 0≤i1<D1, 0≤i2<D2 . . . 0≤in<Dn.
The following is an example of a stream array coupled to the output of one module array and the input of another module array:
Here, the output stream of moduleA[3][2] is coupled to cStrm[3][2], and cStrm[3][2] is coupled to the input stream of moduleB[3][2]. The two couplings are legal because:
The following table lists for each individual stream in cStrm[3][2]: (a) the module whose output is the stream source, (b) the individual stream in cStrm[3][2] and (c) the module whose input is the stream destination.
There are situations when a module needs to notify another module that a particular operation, a side effect, performed by the module has been completed. For example, when a module performs an operation on a data structure in global memory, perhaps as one of many modules performing similar operations on the same data structure, that module typically needs to notify a downstream module that the operation has been completed so that a downstream operation or task may be initiated. In these situations, there is no need to return a value, just a signal that a particular task has been completed. For these situations where a signal, but no value, is needed, Stream C provides the ping data type. Pings (values of type ping) are featureless and completely indistinguishable from one another.
Pings are used in conjunction with three operators: (1) the join operator to provide synchronization of tasks, (2) the >> stream-access operator and (3) the <<stream-access operator. The first use involves just streams, while the last two uses involve a stream and a thread.
The ping keyword is used to declare one or more streams of type ping. For example, the following statement declares that pStrm0, pStrm1 and pStrm2 are streams of type ping:
stream ping pStrm0, pStrm1, pStrm2;
The ping keyword is also used in a module prototype/definition to declare that a module input or output stream is of type ping, as in:
stream ping moduleName(int, ping);.
The first use of pings involves the join operator, which serves to join a ping stream with one or more other streams to produce a single output stream. This operator is similar to the rendezvous operation found in some other computing models. Expressions containing the join operator take one of two forms:
As with all stream expressions, each evaluation of an expression in one of these forms consumes a single value/ping from each input stream and produces a single value/ping on the expression's (unnamed) output stream. If an input stream is empty (devoid of values), evaluation stalls (blocks) until all input streams have at least one value/ping. There is no need for an explicit join operation for non-ping expressions since the effect of a join operation is already subsumed by the semantics of expression evaluation.
When an expression of the first type is evaluated, a single ping is consumed from each stream in the array of ping streams, and a single ping is emitted on the expression's output stream.
An evaluation of an expression in the second form entails the consumption of a single ping from <pingStream> and the evaluation of <streamExpression>. The stream expression <streamExpression> may be of arbitrary type, including ping. The value that results from the evaluation of <streamExpression> is emitted on the output stream of the join operation. If the expression is of type ping, the expression evaluates to a single ping. The ping stream thus acts as a gatekeeper—much like the >> operation described above, allowing an evaluation to proceed only when a ping is present in <pingStream>.
The two forms of the join operation are represented graphically as shown in
One example of the join operation may include a Data Structure X on which two operations, Operation A and Operation B, are performed. These operations meet the following requirements: a) neither Operation A nor Operation B is performed except in response to a go signal; b) when a go signal is received, Operation A and Operation B are performed concurrently; and c) before either Operation A or Operation B can be initiated, both operations performed in response to a preceding go signal must be completed.
A simple solution to this problem employs two instances of the join operator:
moduleA and moduleB encapsulate Operation A and Operation B, respectively. Each has an input ping stream, which initiates one operation per ping, and an output ping stream, which confirms completion of one operation per ping. moduleC contains one instance of both moduleA and moduleB, and receives go signals via the goStrm input ping stream.
The six statements in moduleC play the following roles:
stream ping startStrm=goStrm.join(doneStrm);
joins goStrm and doneStrm to produce startStrm. A ping is thus placed into startStrm when there is a ping on goStrm (i.e., a go signal) and a ping on doneStrm, which, indicates completion of A and B operations performed in response to the preceding go signal.
stream ping StrmA=moduleA(startStrm);
connects startStrm to the input ping stream of moduleA, and connects the output ping stream of moduleA to StrmA. That means that Operation A is performed in response to a go signal, but only after both operations associated with the preceding go signal have been completed.
stream ping StrmB=moduleB(startStrm);
is similar to the preceding statement. It ensures that Operation B is performed in response to a go signal, but only after both operations associated with the preceding go signal have been completed. There are, however, no restrictions on the order in which Operations A and B are performed. In other words, they are performed concurrently.
stream ping doneStrm=StrmA.join(StrmB);
joins strmA, the output ping stream of moduleA, and StrmB, the output ping stream of moduleB. A ping is thus placed onto doneStrm when both operations performed in response to the preceding go signal have been completed.
doneStrm.initialize(ping);
places a single ping into doneStrm at system initialization. This indicates that all previous operations, of which there are none, have been completed. Without this statement, moduleC would deadlock and no operations would ever be performed.
out=doneStrm;
connects doneStrm to out, the default output steam of moduleC. Each ping on this stream confirms that the Operation A and Operation B performed in response to a go signal have been completed. The behavior of moduleC may be summed up as a go signal (ping) on the input port of moduleC causing Operation A and Operation B to be performed concurrently on Data Structure X, but only after previous operations have been completed. When both Operation A and Operation B are completed, moduleC sends a ping on its output port as confirmation.
A statement of the form
pingStrm >> ping;
where pingStrm is a stream of type ping, serves to synchronize execution of a thread with the pings in pingStrm. When the statement is encountered in a thread, a single ping is read (consumed) from pingStrm. If pingStrm is empty (i.e., there are no pings in pingStrm), then the statement blocks (stalls) until a ping becomes available. The statement thus acts as a gatekeeper, allowing a thread to proceed only when a ping is present in pingStrm. There is no variable involved in this operation, on the right of the >> operator, where a variable would ordinarily be expected, is just the keyword ping.
A statement of the form
pingStrm <<ping;
where pingStrm is a stream of type ping, allows a thread to signal interested parties that a certain operation, or operations, have been completed. When the statement is encountered in a thread, a single ping is written to (placed in) pingStrm. Unlike the first statement above, this statement never blocks.
These two forms of stream/thread interaction involving pings are illustrated in the following code fragment:
moduleA has a single input port and a single output port, both of type ping. Within moduleA is a thread containing an infinite loop, each iteration of which begins with the statement
pStrm >> ping;
This statement serves to synchronize the iterations of the loop with the pings in the module input stream pStrm. It blocks when pStrm is empty and consumes a single ping from pStrm when pStrm is non-empty. Following that statement are statements associated with an activity that invariably involves side effects. If there were no side effects, moduleA would be equivalent to a no-op. At the end of each iteration is the statement
out <<ping;
which signals through moduleA's standard output port that another loop iteration has been completed.
The join operator is useful when working entirely within the stream domain. There may be situations, however, in which it is more convenient to do the join within a thread. Consider, for example, joining the individual streams of
stream ping pingStrm[32];
within a thread. That can be accomplished by embedding a for loop within a thread:
This loop blocks a thread until one ping has been consumed from each of the 32 streams in pingStrm. An output stream corresponding to the output stream of pingStrm[ ].join( ) is produced by following the for loop with the statement
joinStrm <<ping;
To create a module that mimics the behavior of pingStrm[ ].join( ), these two code fragments are embedded in a while (true) loop, and the loop is placed in a module:
A module with embedded thread may be used to mimic the behavior of pingStrm.join(expr), where expr is an expression. In this case, however, the module needs an input stream not only for pingStrm, but also for each input stream of expr. So, for example, if expr is the expression X*Y+Z, where X, Y and Z are integers, then the module that implements pingStrm.join(expr) looks like:
A pixel-processing example illustrates the use of pings, stream arrays and module arrays in implementing data parallelism, a form of parallelism in which the same task is performed concurrently (in parallel) on different pieces of the same data structure such as an array. The example consists of a module array and a module.
The two-dimensional module array, doPixel[64][256], is sized to match the size of a two-dimensional array of pixels. The base addresses of the pixel arrays on which doPixel[64][256] operates are supplied by the input stream baStrm. The x coordinate of the pixels upon an individual doPixel module operates is obtained by multiplying index(0), the x index of the individual doPixel module (see Section 5.3), by the global constant xScaleFactor. The y coordinate of the pixels upon an individual doPixel module operates is obtained by multiplying index(1), the y index of the individual doPixel module, by the global constant yScaleFactor. The processing of each pixel begins by setting the variable baStrm to the current value in baStrm. What follows are computations performed on baStrm[x][y] and its neighbors. When processing is done, the individual doPixel module signals completion by emitting a ping.
The parentModule is responsible for broadcasting pixel-array base addresses to the individual modules in doPixel[64][256]. This is done via the statement:
xStrm[ ][ ]=doPixel[ ][ ](jStrm.join(baStrm));
Here, the expression jStrm.join(baStrm) in the input argument list of doPixel acts as a gate, allowing a value in baStrm to pass only when there is a ping in jStrm. An initial ping inserted into jStrm by the statement
jStrm.initialize(ping);
allows the very first base address to pass unimpeded. After that, pings are inserted into jStrm by the statement
jStrm=xStrm[ ][ ].join( );
where xStrm[64][256] is the array of ping streams produced by the individual modules in doPixel[64][256]. A new ping is therefore inserted into jStrm only when all modules in doPixel[64][256] have signaled completion of their previous computation by emitting a ping. This ensures that all computations on a pixel array are completed before computations on the next array are begun.
There is a significant advantage to using pings rather than a standard C data type. With a C data type, a first-in-first-out queue (FIFO) is needed for data values at every destination of a C-data-type stream, that is, everywhere that the stream is an input to an expression. But because pings are indistinguishable from one another, all that is needed at each destination of a ping stream is a counter to tell the number of pings queued up. This results in a significant cost savings over a first-in-first-out queue for data values.
Pragmas are directives to the Stream C compiler/linker/loader. The directive #pragma InitializeCount(m, p, n) initializes the consumer/producer count of input/output port p of module m to n. The Pragma must immediately follow the module definition #pragma FwrdsAckValue(m, s, n). This definition specifies n as the forwards acknowledgement value for the point-to-point connection starting at output stream s of module m. The Pragma must immediately follow the module definition #pragma BwrdsAckValue(m, s, n) specifies n as the backwards acknowledgement value for the point-to-point connection starting at output stream s of module m. The Pragma must immediately follow the module definition.
Some example benefits of the above described concepts are support of threads and multi-threading i.e., the concurrent execution of multiple threads. Also, all forms of parallelism are expressible such as SIMD, MIMD, Instruction-Level, Task-Level, Data-Parallel, Data-Flow, and Systolic. Deterministic behavior is the default. Non-determinism is explicitly added to programs, and only where needed, as it is in sequential programming which makes software testability and reliability more efficient. The concepts described above have no explicit parallelism constructs. Parallelism falls out from code in the stream domain that—syntactically, at least—resembles ordinary sequential code. A programmer working in the thread domain can therefore focus on a strictly sequential problem. The programming model lends itself to model-based design and model-based testing and scales to an arbitrary number of processing cores. The programming model is equally applicable whether the distances separating processing cores are measured in nanometers or thousands of kilometers. There are no foreground or background tasks, just tasks, and there are no interrupts or message passing, just streams.
Although the invention has been described with respect to specific embodiments, thereof, these embodiments are merely illustrative, and not restrictive of the invention. For example, any type of processing units, functional circuitry or collection of one or more units and/or resources such as memories, I/O elements, etc., can be included in a node. A node can be a simple register, or more complex, such as a digital signal processing system. Other types of networks or interconnection schemes than those described herein can be employed. It is possible that features or aspects of the present invention can be achieved in systems other than an adaptable system, such as described herein with respect to a preferred embodiment.
This application is a continuation application of Ser. No. 14/492,705, filed on Sep. 22, 2014; U.S. application Ser. No. 14/492,705 is a continuation of U. S. application Ser. No. 13/011,763 filed on Jan. 21, 2011, all of which claim priority to Provisional Application Ser. No. 61/297,139 filed Jan. 21, 2010. This application is related to U.S. patent application Ser. No. 09/815,122, filed on Mar. 22, 2001, now U.S. Pat. No. 6,836,839 entitled “ADAPTIVE INTEGRATED CIRCUITRY WITH HETEROGENEOUS AND RECONFIGURABLE MATRICES OF DIVERSE AND ADAPTIVE COMPUTATIONAL UNITS HAVING FIXED, APPLICATION SPECIFIC COMPUTATIONAL ELEMENTS”; U.S. patent application Ser. No. 10/384,486, now U.S. Pat. No. 7,325,123 entitled HIERARCHICAL INTERCONNECT FOR CONFIGURING SEPARATE INTERCONNECTS FOR EACH GROUP OF FIXED AND DIVERSE COMPUTATIONAL ELEMENTS”; and U.S. patent application Ser. No. 10/443,501, now U.S. Pat. No. 7,609,297 entitled “HARDWARE TASK MANAGER.” All of these applications are hereby incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3409175 | Byrne | Nov 1968 | A |
| 3666143 | Weston | May 1972 | A |
| 3938639 | Birrell | Feb 1976 | A |
| 3949903 | Benasutti | Apr 1976 | A |
| 3960298 | Birrell | Jun 1976 | A |
| 3967062 | Dobias | Jun 1976 | A |
| 3991911 | Shannon | Nov 1976 | A |
| 3995441 | McMillin | Dec 1976 | A |
| 4076145 | Zygiel | Feb 1978 | A |
| 4143793 | McMillin | Mar 1979 | A |
| 4172669 | Edelbach | Oct 1979 | A |
| 4174872 | Fessler | Nov 1979 | A |
| 4181242 | Zygiel | Jan 1980 | A |
| RE30301 | Zygiel | Jun 1980 | E |
| 4218014 | Tracy | Aug 1980 | A |
| 4222972 | Caldwell | Sep 1980 | A |
| 4237536 | Enelow | Dec 1980 | A |
| 4252253 | Shannon | Feb 1981 | A |
| 4302775 | Widergren | Nov 1981 | A |
| 4333587 | Fessler | Jun 1982 | A |
| 4354613 | Desai | Oct 1982 | A |
| 4377246 | McMillin | Mar 1983 | A |
| 4393468 | New | Jul 1983 | A |
| 4413752 | McMillin | Nov 1983 | A |
| 4458584 | Annese | Jul 1984 | A |
| 4466342 | Basile | Aug 1984 | A |
| 4475448 | Shoaf | Oct 1984 | A |
| 4509690 | Austin | Apr 1985 | A |
| 4520950 | Jeans | Jun 1985 | A |
| 4549675 | Austin | Oct 1985 | A |
| 4553573 | McGarrah | Nov 1985 | A |
| 4560089 | McMillin | Dec 1985 | A |
| 4577782 | Fessler | Mar 1986 | A |
| 4578799 | Scholl | Mar 1986 | A |
| RE32179 | Sedam | Jun 1986 | E |
| 4633386 | Terepin | Dec 1986 | A |
| 4649512 | Nukiyama | Mar 1987 | A |
| 4658988 | Hassell | Apr 1987 | A |
| 4694416 | Wheeler | Sep 1987 | A |
| 4711374 | Gaunt | Dec 1987 | A |
| 4713755 | Worley, Jr. | Dec 1987 | A |
| 4719056 | Scott | Jan 1988 | A |
| 4726494 | Scott | Feb 1988 | A |
| 4747516 | Baker | May 1988 | A |
| 4748585 | Chiarulli | May 1988 | A |
| 4760525 | Webb | Jul 1988 | A |
| 4760544 | Lamb | Jul 1988 | A |
| 4765513 | McMillin | Aug 1988 | A |
| 4766548 | Cedrone | Aug 1988 | A |
| 4781309 | Vogel | Nov 1988 | A |
| 4800492 | Johnson | Jan 1989 | A |
| 4811214 | Nosenchuck | Mar 1989 | A |
| 4824075 | Holzboog | Apr 1989 | A |
| 4827426 | Patton | May 1989 | A |
| 4850269 | Hancock | Jul 1989 | A |
| 4856684 | Gerstung | Aug 1989 | A |
| 4901887 | Burton | Feb 1990 | A |
| 4921315 | Metcalfe | May 1990 | A |
| 4930666 | Rudick | Jun 1990 | A |
| 4932564 | Austin | Jun 1990 | A |
| 4936488 | Austin | Jun 1990 | A |
| 4937019 | Scott | Jun 1990 | A |
| 4960261 | Scott | Oct 1990 | A |
| 4961533 | Teller | Oct 1990 | A |
| 4967340 | Dawes | Oct 1990 | A |
| 4974643 | Bennett | Dec 1990 | A |
| 4982876 | Scott | Jan 1991 | A |
| 4993604 | Gaunt | Feb 1991 | A |
| 5007560 | Sassak | Apr 1991 | A |
| 5021947 | Campbell | Jun 1991 | A |
| 5040106 | Maag | Aug 1991 | A |
| 5044171 | Farkas | Sep 1991 | A |
| 5090015 | Dabbish | Feb 1992 | A |
| 5129549 | Austin | Jul 1992 | A |
| 5139708 | Scott | Aug 1992 | A |
| 5156301 | Hassell | Oct 1992 | A |
| 5156871 | Goulet | Oct 1992 | A |
| 5165575 | Scott | Nov 1992 | A |
| 5190083 | Gupta | Mar 1993 | A |
| 5190189 | Zimmer | Mar 1993 | A |
| 5193151 | Jain | Mar 1993 | A |
| 5193718 | Hassell | Mar 1993 | A |
| 5202993 | Tarsy | Apr 1993 | A |
| 5203474 | Haynes | Apr 1993 | A |
| 5240144 | Feldman | Aug 1993 | A |
| 5261099 | Bigo | Nov 1993 | A |
| 5263509 | Cherry | Nov 1993 | A |
| 5269442 | Vogel | Dec 1993 | A |
| 5280711 | Motta | Jan 1994 | A |
| 5297400 | Benton | Mar 1994 | A |
| 5301100 | Wagner | Apr 1994 | A |
| 5303846 | Shannon | Apr 1994 | A |
| 5325525 | Shan | Jun 1994 | A |
| 5335276 | Thompson | Aug 1994 | A |
| 5339428 | Burmeister | Aug 1994 | A |
| 5343716 | Swanson | Sep 1994 | A |
| 5361362 | Benkeser | Nov 1994 | A |
| 5367651 | Smith | Nov 1994 | A |
| 5367687 | Tarsy | Nov 1994 | A |
| 5368198 | Goulet | Nov 1994 | A |
| 5379343 | Grube | Jan 1995 | A |
| 5381546 | Servi | Jan 1995 | A |
| 5381550 | Jourdenais | Jan 1995 | A |
| 5388212 | Grube | Feb 1995 | A |
| 5392960 | Kendt | Feb 1995 | A |
| 5428754 | Baldwin | Jun 1995 | A |
| 5437395 | Bull | Aug 1995 | A |
| 5450557 | Kopp | Sep 1995 | A |
| 5454406 | Rejret | Oct 1995 | A |
| 5465368 | Davidson | Nov 1995 | A |
| 5479055 | Eccles | Dec 1995 | A |
| 5490165 | Blakeney, II | Feb 1996 | A |
| 5491823 | Ruttenberg | Feb 1996 | A |
| 5507009 | Grube | Apr 1996 | A |
| 5515519 | Yoshioka | May 1996 | A |
| 5517600 | Shimokawa | May 1996 | A |
| 5519694 | Brewer | May 1996 | A |
| 5522070 | Sumimoto | May 1996 | A |
| 5530964 | Alpert | Jun 1996 | A |
| 5534796 | Edwards | Jul 1996 | A |
| 5542265 | Rutland | Aug 1996 | A |
| 5553755 | Bonewald | Sep 1996 | A |
| 5555417 | Odnert | Sep 1996 | A |
| 5560028 | Sachs | Sep 1996 | A |
| 5560038 | Haddock | Sep 1996 | A |
| 5570587 | Kim | Nov 1996 | A |
| 5572572 | Kawan | Nov 1996 | A |
| 5590353 | Sakakibara | Dec 1996 | A |
| 5594657 | Cantone | Jan 1997 | A |
| 5600810 | Ohkami | Feb 1997 | A |
| 5600844 | Shaw | Feb 1997 | A |
| 5602833 | Zehavi | Feb 1997 | A |
| 5603043 | Taylor | Feb 1997 | A |
| 5607083 | Vogel | Mar 1997 | A |
| 5608643 | Wichter | Mar 1997 | A |
| 5611867 | Cooper | Mar 1997 | A |
| 5619695 | Arbabi | Apr 1997 | A |
| 5623545 | Childs | Apr 1997 | A |
| 5625669 | McGregor | Apr 1997 | A |
| 5626407 | Westcott | May 1997 | A |
| 5630206 | Urban | May 1997 | A |
| 5635940 | Hickman | Jun 1997 | A |
| 5646544 | Iadanza | Jul 1997 | A |
| 5646545 | Trimberger | Jul 1997 | A |
| 5647512 | Assis Mascarenhas de Oliveira | Jul 1997 | A |
| 5667110 | McCann | Sep 1997 | A |
| 5684793 | Kiema | Nov 1997 | A |
| 5684980 | Casselman | Nov 1997 | A |
| 5687236 | Moskowitz | Nov 1997 | A |
| 5694613 | Suzuki | Dec 1997 | A |
| 5694794 | Jerg | Dec 1997 | A |
| 5699328 | Ishizaki | Dec 1997 | A |
| 5701482 | Harrison | Dec 1997 | A |
| 5704053 | Santhanam | Dec 1997 | A |
| 5706191 | Bassett | Jan 1998 | A |
| 5706976 | Purkey | Jan 1998 | A |
| 5712996 | Schepers | Jan 1998 | A |
| 5720002 | Wang | Feb 1998 | A |
| 5721693 | Song | Feb 1998 | A |
| 5721854 | Ebicioglu | Feb 1998 | A |
| 5732563 | Bethuy | Mar 1998 | A |
| 5734808 | Takeda | Mar 1998 | A |
| 5737631 | Trimberger | Apr 1998 | A |
| 5742180 | DeHon | Apr 1998 | A |
| 5742821 | Prasanna | Apr 1998 | A |
| 5745366 | Highma | Apr 1998 | A |
| RE35780 | Hassell | May 1998 | E |
| 5751295 | Becklund | May 1998 | A |
| 5754227 | Fukuoka | May 1998 | A |
| 5758261 | Weideman | May 1998 | A |
| 5768561 | Wise | Jun 1998 | A |
| 5771362 | Bartkowiak | Jun 1998 | A |
| 5778439 | Trimberger | Jul 1998 | A |
| 5784636 | Rupp | Jul 1998 | A |
| 5784699 | McMahon | Jul 1998 | A |
| 5787237 | Reilly | Jul 1998 | A |
| 5790817 | Asghar | Aug 1998 | A |
| 5791517 | Avital | Aug 1998 | A |
| 5791523 | Oh | Aug 1998 | A |
| 5794062 | Baxter | Aug 1998 | A |
| 5794067 | Kadowaki | Aug 1998 | A |
| 5802055 | Krein | Sep 1998 | A |
| 5802278 | Isfeld | Sep 1998 | A |
| 5818603 | Motoyama | Oct 1998 | A |
| 5819255 | Celis | Oct 1998 | A |
| 5822308 | Weigand | Oct 1998 | A |
| 5822313 | Malek | Oct 1998 | A |
| 5822360 | Lee | Oct 1998 | A |
| 5828858 | Athanas | Oct 1998 | A |
| 5829085 | Jerg | Nov 1998 | A |
| 5835753 | Witt | Nov 1998 | A |
| 5838165 | Chatter | Nov 1998 | A |
| 5838894 | Horst | Nov 1998 | A |
| 5845815 | Vogel | Dec 1998 | A |
| 5860021 | Klingman | Jan 1999 | A |
| 5862961 | Motta | Jan 1999 | A |
| 5870427 | Teidemann, Jr. | Feb 1999 | A |
| 5873045 | Lee | Feb 1999 | A |
| 5881106 | Cartier | Mar 1999 | A |
| 5884284 | Peters | Mar 1999 | A |
| 5886537 | Macias | Mar 1999 | A |
| 5887174 | Simons | Mar 1999 | A |
| 5889816 | Agrawal | Mar 1999 | A |
| 5889989 | Robertazzi | Mar 1999 | A |
| 5890014 | Long | Mar 1999 | A |
| 5892900 | Ginter | Apr 1999 | A |
| 5892961 | Trimberger | Apr 1999 | A |
| 5894473 | Dent | Apr 1999 | A |
| 5901884 | Goulet | May 1999 | A |
| 5903886 | Heimlich | May 1999 | A |
| 5907285 | Toms | May 1999 | A |
| 5907580 | Cummings | May 1999 | A |
| 5910733 | Bertolet | Jun 1999 | A |
| 5912572 | Graf, III | Jun 1999 | A |
| 5913172 | McCabe | Jun 1999 | A |
| 5917852 | Butterfield | Jun 1999 | A |
| 5920801 | Thomas | Jul 1999 | A |
| 5931918 | Row | Aug 1999 | A |
| 5933642 | Greenbaum | Aug 1999 | A |
| 5940438 | Poon | Aug 1999 | A |
| 5949415 | Lin | Sep 1999 | A |
| 5950011 | Albrecht | Sep 1999 | A |
| 5950131 | Vilmur | Sep 1999 | A |
| 5951674 | Moreno | Sep 1999 | A |
| 5953322 | Kimball | Sep 1999 | A |
| 5956518 | DeHon | Sep 1999 | A |
| 5956967 | Kim | Sep 1999 | A |
| 5959811 | Richardson | Sep 1999 | A |
| 5959881 | Trimberger | Sep 1999 | A |
| 5963048 | Harrison | Oct 1999 | A |
| 5966534 | Cooke | Oct 1999 | A |
| 5970254 | Cooke | Oct 1999 | A |
| 5987105 | Jenkins | Nov 1999 | A |
| 5987611 | Freund | Nov 1999 | A |
| 5991302 | Berl | Nov 1999 | A |
| 5991308 | Fuhrmann | Nov 1999 | A |
| 5993739 | Lyon | Nov 1999 | A |
| 5999734 | Willis | Dec 1999 | A |
| 6005943 | Cohen | Dec 1999 | A |
| 6006249 | Leong | Dec 1999 | A |
| 6016395 | Mohamed | Jan 2000 | A |
| 6018783 | Chiang | Jan 2000 | A |
| 6021186 | Suzuki | Feb 2000 | A |
| 6021492 | May | Feb 2000 | A |
| 6023742 | Ebeling | Feb 2000 | A |
| 6023755 | Casselman | Feb 2000 | A |
| 6028610 | Deering | Feb 2000 | A |
| 6036166 | Olson | Mar 2000 | A |
| 6039219 | Bach | Mar 2000 | A |
| 6041322 | Meng | Mar 2000 | A |
| 6041970 | Vogel | Mar 2000 | A |
| 6046603 | New | Apr 2000 | A |
| 6047115 | Mohan | Apr 2000 | A |
| 6052600 | Fette | Apr 2000 | A |
| 6055314 | Spies | Apr 2000 | A |
| 6056194 | Kolls | May 2000 | A |
| 6059840 | Click, Jr. | May 2000 | A |
| 6061580 | Altschul | May 2000 | A |
| 6073132 | Gehman | Jun 2000 | A |
| 6076174 | Freund | Jun 2000 | A |
| 6078736 | Guccione | Jun 2000 | A |
| 6085740 | Ivri | Jul 2000 | A |
| 6088043 | Kelleher | Jul 2000 | A |
| 6091263 | New | Jul 2000 | A |
| 6091765 | Pietzold, III | Jul 2000 | A |
| 6094065 | Tavana | Jul 2000 | A |
| 6094726 | Gonion | Jul 2000 | A |
| 6111893 | Volftsun | Aug 2000 | A |
| 6111935 | Hughes-Hartogs | Aug 2000 | A |
| 6115751 | Tam | Sep 2000 | A |
| 6120551 | Law | Sep 2000 | A |
| 6122670 | Bennett | Sep 2000 | A |
| 6128307 | Brown | Oct 2000 | A |
| 6134605 | Hudson | Oct 2000 | A |
| 6134629 | L'Ecuyer | Oct 2000 | A |
| 6138693 | Matz | Oct 2000 | A |
| 6141283 | Bogin | Oct 2000 | A |
| 6150838 | Wittig | Nov 2000 | A |
| 6154492 | Araki | Nov 2000 | A |
| 6154494 | Sugahara | Nov 2000 | A |
| 6157997 | Oowaki | Dec 2000 | A |
| 6175854 | Bretscher | Jan 2001 | B1 |
| 6175892 | Sazzad | Jan 2001 | B1 |
| 6181981 | Varga | Jan 2001 | B1 |
| 6185418 | MacLellan | Feb 2001 | B1 |
| 6192070 | Poon | Feb 2001 | B1 |
| 6192255 | Lewis | Feb 2001 | B1 |
| 6192388 | Cajolet | Feb 2001 | B1 |
| 6195788 | Leaver | Feb 2001 | B1 |
| 6198924 | Ishii | Mar 2001 | B1 |
| 6199093 | Yokoya | Mar 2001 | B1 |
| 6199181 | Rechef | Mar 2001 | B1 |
| 6202130 | Scales, III | Mar 2001 | B1 |
| 6219697 | Lawande | Apr 2001 | B1 |
| 6219756 | Kasamizugami | Apr 2001 | B1 |
| 6219780 | Lipasti | Apr 2001 | B1 |
| 6223222 | Fijolek | Apr 2001 | B1 |
| 6226387 | Tewfik | May 2001 | B1 |
| 6230307 | Davis | May 2001 | B1 |
| 6237029 | Master | May 2001 | B1 |
| 6246883 | Lee | Jun 2001 | B1 |
| 6247125 | Noel-Baron | Jun 2001 | B1 |
| 6249251 | Chang | Jun 2001 | B1 |
| 6258725 | Lee | Jul 2001 | B1 |
| 6263057 | Silverman | Jul 2001 | B1 |
| 6266760 | DeHon | Jul 2001 | B1 |
| 6272579 | Lentz | Aug 2001 | B1 |
| 6281703 | Furuta | Aug 2001 | B1 |
| 6282627 | Wong | Aug 2001 | B1 |
| 6289375 | Knight | Sep 2001 | B1 |
| 6289434 | Roy | Sep 2001 | B1 |
| 6289488 | Dave | Sep 2001 | B1 |
| 6292822 | Hardwick | Sep 2001 | B1 |
| 6292827 | Raz | Sep 2001 | B1 |
| 6292830 | Taylor | Sep 2001 | B1 |
| 6301653 | Mohamed | Oct 2001 | B1 |
| 6305014 | Roediger | Oct 2001 | B1 |
| 6311149 | Ryan | Oct 2001 | B1 |
| 6321985 | Kolls | Nov 2001 | B1 |
| 6346824 | New | Feb 2002 | B1 |
| 6347346 | Taylor | Feb 2002 | B1 |
| 6349394 | Brock | Feb 2002 | B1 |
| 6353841 | Marshall | Mar 2002 | B1 |
| 6356863 | Sayle | Mar 2002 | B1 |
| 6356994 | Barry | Mar 2002 | B1 |
| 6359248 | Mardi | Mar 2002 | B1 |
| 6360256 | Lim | Mar 2002 | B1 |
| 6360259 | Bradley | Mar 2002 | B1 |
| 6360263 | Kurtzberg | Mar 2002 | B1 |
| 6363411 | Dugan | Mar 2002 | B1 |
| 6366999 | Drabenstott | Apr 2002 | B1 |
| 6377983 | Cohen | Apr 2002 | B1 |
| 6378072 | Collins | Apr 2002 | B1 |
| 6381735 | Hunt | Apr 2002 | B1 |
| 6385751 | Wolf | May 2002 | B1 |
| 6405214 | Meade, II | Jun 2002 | B1 |
| 6408039 | Ito | Jun 2002 | B1 |
| 6410941 | Taylor | Jun 2002 | B1 |
| 6411612 | Halford | Jun 2002 | B1 |
| 6421372 | Bierly | Jul 2002 | B1 |
| 6421809 | Wuytack | Jul 2002 | B1 |
| 6430624 | Jamtgaard | Aug 2002 | B1 |
| 6433578 | Wasson | Aug 2002 | B1 |
| 6434590 | Blelloch | Aug 2002 | B1 |
| 6438737 | Morelli | Aug 2002 | B1 |
| 6446258 | McKinsey | Sep 2002 | B1 |
| 6449747 | Wuytack | Sep 2002 | B2 |
| 6456996 | Crawford, Jr. | Sep 2002 | B1 |
| 6459883 | Subramanian | Oct 2002 | B2 |
| 6467009 | Winegarden | Oct 2002 | B1 |
| 6473609 | Schwartz | Oct 2002 | B1 |
| 6507947 | Schreiber | Jan 2003 | B1 |
| 6510138 | Pannell | Jan 2003 | B1 |
| 6510510 | Garde | Jan 2003 | B1 |
| 6538470 | Langhammer | Mar 2003 | B1 |
| 6556044 | Langhammer | Apr 2003 | B2 |
| 6563891 | Eriksson | May 2003 | B1 |
| 6570877 | Kloth | May 2003 | B1 |
| 6577678 | Scheuermann | Jun 2003 | B2 |
| 6587684 | Hsu | Jul 2003 | B1 |
| 6590415 | Agrawal | Jul 2003 | B2 |
| 6601086 | Howard | Jul 2003 | B1 |
| 6601158 | Abbott | Jul 2003 | B1 |
| 6604085 | Kolls | Aug 2003 | B1 |
| 6604189 | Zemlyak | Aug 2003 | B1 |
| 6606529 | Crowder, Jr. | Aug 2003 | B1 |
| 6611908 | McAllister | Aug 2003 | B2 |
| 6615333 | Hoogerbrugge | Sep 2003 | B1 |
| 6618434 | Heidari-Bateni | Sep 2003 | B2 |
| 6618777 | Greenfield | Sep 2003 | B1 |
| 6640304 | Ginter | Oct 2003 | B2 |
| 6647429 | Semal | Nov 2003 | B1 |
| 6653859 | Sihlbom | Nov 2003 | B2 |
| 6675265 | Barroso | Jan 2004 | B2 |
| 6684319 | Mohamed | Jan 2004 | B1 |
| 6691148 | Zinky | Feb 2004 | B1 |
| 6711607 | Goyal | Mar 2004 | B1 |
| 6711617 | Bantz | Mar 2004 | B1 |
| 6718182 | Kung | Apr 2004 | B1 |
| 6718541 | Ostanevich | Apr 2004 | B2 |
| 6721286 | Williams | Apr 2004 | B1 |
| 6721884 | De Oliveira Kastrup Pereira | Apr 2004 | B1 |
| 6732354 | Ebeling | May 2004 | B2 |
| 6735621 | Yoakum | May 2004 | B1 |
| 6738744 | Kirovski | May 2004 | B2 |
| 6748360 | Pitman | Jun 2004 | B2 |
| 6754470 | Hendrickson | Jun 2004 | B2 |
| 6760587 | Holtzman | Jul 2004 | B2 |
| 6760833 | Dowling | Jul 2004 | B1 |
| 6766165 | Sharma | Jul 2004 | B2 |
| 6778212 | Deng | Aug 2004 | B1 |
| 6785341 | Walton | Aug 2004 | B2 |
| 6807590 | Carlson | Oct 2004 | B1 |
| 6819140 | Yamanaka | Nov 2004 | B2 |
| 6823448 | Roth | Nov 2004 | B2 |
| 6829633 | Gelfer | Dec 2004 | B2 |
| 6832250 | Coons | Dec 2004 | B1 |
| 6836839 | Master | Dec 2004 | B2 |
| 6865664 | Budrovic | Mar 2005 | B2 |
| 6871236 | Fishman | Mar 2005 | B2 |
| 6883074 | Lee | Apr 2005 | B2 |
| 6883084 | Donohoe | Apr 2005 | B1 |
| 6894996 | Lee | May 2005 | B2 |
| 6901440 | Bimm | May 2005 | B1 |
| 6907598 | Fraser | Jun 2005 | B2 |
| 6912515 | Jackson | Jun 2005 | B2 |
| 6983460 | Goire | Jan 2006 | B1 |
| 6985517 | Matsumoto | Jan 2006 | B2 |
| 6986021 | Master | Jan 2006 | B2 |
| 6988139 | Jervis | Jan 2006 | B1 |
| 7032229 | Flores | Apr 2006 | B1 |
| 7044741 | Leem | May 2006 | B2 |
| 7082456 | Mani-Meitav | Jul 2006 | B2 |
| 7139910 | Ainsworth | Nov 2006 | B1 |
| 7142731 | Toi | Nov 2006 | B1 |
| 7243333 | Gschwind | Jul 2007 | B2 |
| 7249242 | Ramchandran | Jul 2007 | B2 |
| 7503048 | Sheets | Mar 2009 | B1 |
| 7620678 | Master | Nov 2009 | B1 |
| 8108845 | Little | Jan 2012 | B2 |
| 8214808 | Day | Jul 2012 | B2 |
| 8601458 | Andrade | Dec 2013 | B2 |
| 8621446 | Archer | Dec 2013 | B2 |
| 8645934 | Fontenot | Feb 2014 | B2 |
| 20010003191 | Kovacs | Jun 2001 | A1 |
| 20010023482 | Wray | Sep 2001 | A1 |
| 20010029515 | Mirsky | Oct 2001 | A1 |
| 20010034795 | Moulton | Oct 2001 | A1 |
| 20010039654 | Miyamoto | Nov 2001 | A1 |
| 20010048713 | Medlock | Dec 2001 | A1 |
| 20010048714 | Jha | Dec 2001 | A1 |
| 20010050948 | Ramberg | Dec 2001 | A1 |
| 20020010848 | Kamano | Jan 2002 | A1 |
| 20020013799 | Blaker | Jan 2002 | A1 |
| 20020013937 | Ostanevich | Jan 2002 | A1 |
| 20020015435 | Rieken | Feb 2002 | A1 |
| 20020015439 | Kohli | Feb 2002 | A1 |
| 20020023210 | Tuomenoksa | Feb 2002 | A1 |
| 20020024942 | Tsuneki | Feb 2002 | A1 |
| 20020024993 | Subramanian | Feb 2002 | A1 |
| 20020031166 | Subramanian | Mar 2002 | A1 |
| 20020032551 | Zakiya | Mar 2002 | A1 |
| 20020035623 | Lawande | Mar 2002 | A1 |
| 20020041581 | Aramaki | Apr 2002 | A1 |
| 20020042907 | Yamanaka | Apr 2002 | A1 |
| 20020046400 | Burch | Apr 2002 | A1 |
| 20020061741 | Leung | May 2002 | A1 |
| 20020069282 | Reisman | Jun 2002 | A1 |
| 20020072830 | Hunt | Jun 2002 | A1 |
| 20020078337 | Moreau | Jun 2002 | A1 |
| 20020083305 | Renard | Jun 2002 | A1 |
| 20020083423 | Ostanevich | Jun 2002 | A1 |
| 20020087829 | Snyder | Jul 2002 | A1 |
| 20020089348 | Langhammer | Jul 2002 | A1 |
| 20020101909 | Chen | Aug 2002 | A1 |
| 20020107905 | Roe | Aug 2002 | A1 |
| 20020107962 | Richter | Aug 2002 | A1 |
| 20020119803 | Bitterlich | Aug 2002 | A1 |
| 20020120672 | Butt | Aug 2002 | A1 |
| 20020138716 | Master | Sep 2002 | A1 |
| 20020141489 | Imaizumi | Oct 2002 | A1 |
| 20020147845 | Sanchez-Herrero | Oct 2002 | A1 |
| 20020159503 | Ramachandran | Oct 2002 | A1 |
| 20020162026 | Neuman | Oct 2002 | A1 |
| 20020168018 | Scheuermann | Nov 2002 | A1 |
| 20020181559 | Heidari-Bateni | Dec 2002 | A1 |
| 20020184291 | Hogenauer | Dec 2002 | A1 |
| 20020184498 | Qi | Dec 2002 | A1 |
| 20020191790 | Anand | Dec 2002 | A1 |
| 20030007606 | Suder | Jan 2003 | A1 |
| 20030012270 | Zhou | Jan 2003 | A1 |
| 20030018446 | Makowski | Jan 2003 | A1 |
| 20030018700 | Giroti | Jan 2003 | A1 |
| 20030023830 | Hogenauer | Jan 2003 | A1 |
| 20030026242 | Jokinen | Feb 2003 | A1 |
| 20030030004 | Dixon | Feb 2003 | A1 |
| 20030046421 | Horvitz | Mar 2003 | A1 |
| 20030061260 | Rajkumar | Mar 2003 | A1 |
| 20030061311 | Lo | Mar 2003 | A1 |
| 20030063656 | Rao | Apr 2003 | A1 |
| 20030076815 | Miller | Apr 2003 | A1 |
| 20030088755 | Gudmunson | May 2003 | A1 |
| 20030099223 | Chang | May 2003 | A1 |
| 20030102889 | Master | Jun 2003 | A1 |
| 20030105949 | Master | Jun 2003 | A1 |
| 20030110485 | Lu | Jun 2003 | A1 |
| 20030131162 | Secatch | Jul 2003 | A1 |
| 20030142818 | Raghunathan | Jul 2003 | A1 |
| 20030154357 | Master | Aug 2003 | A1 |
| 20030163723 | Kozuch | Aug 2003 | A1 |
| 20030172138 | McCormack | Sep 2003 | A1 |
| 20030172139 | Srinivasan | Sep 2003 | A1 |
| 20030200538 | Ebeling | Oct 2003 | A1 |
| 20030212684 | Meyer | Nov 2003 | A1 |
| 20040006584 | Vandeweerd | Jan 2004 | A1 |
| 20040010645 | Scheuermann | Jan 2004 | A1 |
| 20040015970 | Scheuermann | Jan 2004 | A1 |
| 20040015973 | Skovira | Jan 2004 | A1 |
| 20040025159 | Scheuermann | Feb 2004 | A1 |
| 20040057505 | Valio | Mar 2004 | A1 |
| 20040062300 | McDonough | Apr 2004 | A1 |
| 20040081248 | Parolari | Apr 2004 | A1 |
| 20040083462 | Gschwind | Apr 2004 | A1 |
| 20040093479 | Ramchandran | May 2004 | A1 |
| 20040133745 | Ramchandran | Jul 2004 | A1 |
| 20040168044 | Ramchandran | Aug 2004 | A1 |
| 20040181786 | Allison | Sep 2004 | A1 |
| 20050038984 | Heidari-Bateni | Feb 2005 | A1 |
| 20050044327 | Howard | Feb 2005 | A1 |
| 20050044344 | Stevens | Feb 2005 | A1 |
| 20050166033 | Jacob | Jul 2005 | A1 |
| 20050166038 | Wang | Jul 2005 | A1 |
| 20050166073 | Lee | Jul 2005 | A1 |
| 20050183091 | Van Eijndhoven | Aug 2005 | A1 |
| 20050198199 | Dowling | Sep 2005 | A1 |
| 20060031660 | Master | Feb 2006 | A1 |
| 20060150165 | Hooper | Jul 2006 | A1 |
| 20060174234 | Arenburg | Aug 2006 | A1 |
| 20070038987 | O'hara | Feb 2007 | A1 |
| 20070157166 | Stevens | Jul 2007 | A1 |
| 20070169027 | Drepper | Jul 2007 | A1 |
| 20070294512 | Crutchfield | Dec 2007 | A1 |
| 20070294696 | Papakipos | Dec 2007 | A1 |
| 20080134158 | Salz | Jun 2008 | A1 |
| 20080301694 | Mattson | Dec 2008 | A1 |
| 20090282408 | Joffe | Nov 2009 | A1 |
| 20090300615 | Andrade | Dec 2009 | A1 |
| 20100312801 | Ostrovsky | Dec 2010 | A1 |
| 20110131558 | Young | Jun 2011 | A1 |
| 20110271263 | Archer | Nov 2011 | A1 |
| 20110296423 | Elnozahy | Dec 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 0749597 | Oct 2003 | EP |
| 03-102431 | Apr 1991 | JP |
| Number | Date | Country | |
|---|---|---|---|
| 20190004813 A1 | Jan 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61297139 | Jan 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14492705 | Sep 2014 | US |
| Child | 16126918 | US | |
| Parent | 13011763 | Jan 2011 | US |
| Child | 14492705 | US |
