text:
|Publication number
|Publication type
|Application number
|PCT number
|Publication date
|Feb 21, 2006
|Filing date
|Jun 13, 2001
|Priority date
|Jun 13, 2000
|Fee status
|Also published as
|Publication number
|Martin Vorbach, Volker Baumgarte, Gerd Ehlers, Frank May, Armin Nückel
|Original Assignee
|Pact Xpp Technologies Ag
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (114), Non-Patent Citations (47), Referenced by (38), Classifications (18), Legal Events (8)
|External Links: USPTO, USPTO Assignment, Espacenet
Example embodiments of the present invention include methods which permit efficient configuration and reconfiguration of one or more reconfigurable subassemblies by one or more configuration units (CT) at high frequencies. An efficient and synchronized network may be created to control multiple CTs.
A subassembly or cell may include conventional FPGA cells, bus systems, memories, peripherals and ALUs as well as arithmetic units of processors. A subassembly may be any type of configurable and reconfigurable elements. For parallel computer systems, a subassembly may be a complete node of any function, e.g., the arithmetic, memory or data transmission functions.
The example method described here may be used in particular for integrated modules having a plurality of subassemblies in a one-dimensional or multidimensional arrangement, interconnected directly or through a bus system.
"Modules" may include systolic arrays, neural networks, multiprocessor systems, processors having multiple arithmetic units and logic cells, as well as known modules of the types FPGA, DPGA, XPUTER, etc.
For example, modules of an architecture whose arithmetic units and bus systems are freely configurable are used. An example architecture has been described in German Patent 4416881 as well as PACT02, PACT08, PACT10, PACT13. This architecture is referred to below as VPU. This architecture may include any desired arithmetic cells, logic cells (including memories) or communicative (IO) cells ("PAEs"), which may be arranged in a one-dimensional or multidimensional matrix "processing array" or "PA". The matrix may have different cells of any design. The bus systems may also have a cellular structure. The matrix as a whole or parts thereof may be assigned a configuration unit (CT) which influences the interconnections and function of the PA.
A special property of VPUs is the automatic and deadlock-free reconfiguration at run time. Protocols and methods required for have been described in PACT04, 05, 08, 10 and 13, the full content of which is included here through this reference. The publication numbers for these internal file numbers can be found in the addendum.
Example Initial States of PAEs and Bus Protocol of the Configuration
Each PAE may be allocated states that may influence configurability. These states may be locally coded or may be managed through one or more switch groups, in particular the CT itself. A PAE may have at least two states:
It will be appreciated that there may be a separation between data and/or triggers for processing on the one hand and data and/or triggers for configuration of one or more cells on the other hand.
During configuration, the CT may send, together with a valid configuration word (KW), a signal indicating the configuration word's validity (RDY). This signal may be omitted if validity is ensured by some other means, e.g., in the case of continuous transmission or by a code in the KW. In addition, the address of the PAE to be configured may be coded in a KW.
According to the criteria described below and in the patent applications referenced, a PAE may decide whether it can accept the KW and alter its configuration or whether data processing must not be interrupted or corrupted by a new configuration. Information regarding whether or not configurations are accepted may be relayed to the CT if the decision has not already been made there. The following protocol may be used: If a PAE accepts the configuration, it sends an acknowledgment ACK to the CT. If the configuration is rejected, a PAE will indicate this by sending REJ (reject) to the CT.
Within the data processing elements (PAEs), a decision may be made by one or more of the elements regarding whether they can be reconfigured because the data processing is concluded or whether they are still processing data. In addition, no data is corrupted due to unconfigured PAEs.
Example Approach to Deadlock Freedom and Correctness of the Data
FILMO Principle
Efficient management of a plurality of configurations, each of which may be composed of one or more KWs and possibly additional control commands may be provided. The plurality of configurations may be configured overlappingly on the PA. When there is a great distance between the CT and the cell(s) to be configured, this may be a disadvantage in the transmission of configurations. It will be appreciated that no data or states are corrupted due to a reconfiguration. To ensure this, the following rules, which are called the FILMO principle, may be defined:
Methods which meet most or all of the requirements listed above are described in PACT05 and PACT10.
Management of the configurations, their timing and arrangement and the design of the respective components, e.g., the configuration registers, etc., may be used to provide the technique described here, however, and possible improvements over known related art are described below.
To ensure that requirement e) is met as needed, the triggers received, which pertain to the status of a SubConf and a cell and/or reconfigurability, may be stored in the correct sequence by way of a simple FIFO, e.g., a FIFO allocated to the CT. Each FIFO entry include the triggers received in a clock cycle. All the triggers received in one clock cycle may be stored. If there are no triggers, no FIFO entry is generated. The CT may process the FIFO in the sequence in which the triggers were received. If one entry contains multiple triggers, the CT may first process each trigger individually, optionally either (I) prioritized or (ii) unprioritized, before processing the next FIFO entry. Since a trigger is usually sent to the CT only once per configuration, it may be sufficient to define the maximum depth of the FIFO relative to the quantity of all trigger lines wired to the CT. As an alternative method, a time stamp protocol as described in PACT18 may also be used. Two basic types of FILMO are described in PACT10:
Example methods, according to the present invention, may be applied to both types of FILMO or to one type.
2.2. Example Differential Reconfiguration
With many algorithms, it may be advisable only to make minimal changes in configuration during operation on the basis of certain events represented by triggers or by time tuning without completely deleting the configuration of the PAEs. This may apply to the wiring of the bus systems or to certain constants. For example, if only one constant is to be changed, it may be advisable to be able write a KW to the respective PAE without the PAE being in an "unconfigured" state, reducing the amount of configuration data to be transferred. This may be achieved with a "differential reconfiguration" configuration mode, where the KW contains the information "DIFFERENTIAL" either in encoded form or explicitly in writing the KW. "DIFFERENTIAL" indicates that the KW is to be sent to a PAE that has already been configured. The acceptance of the differential configuration and the acknowledgment may be inverted from the normal configuration; e.g., a configured PAE receives the KW and sends an ACK. An unconfigured PAE rejects the KW and sends REJ because the prerequisite for "DIFFERENTIAL" is a configured PAE.
There may be various approaches to performing a differential reconfiguration. The differential reconfiguration may forced without regard for the data processing operation actually taking place in a cell. In that case, it is desirable to guarantee accurate synchronization with the data processing, which may be accomplished through appropriate design and layout of the program. To relieve the programmer of this job, however, differential reconfigurability may also be made to depend on other events, e.g., the existence of a certain state in another cell or in the cell that is to be partially reconfigured. It may be advantageous to store the configuration data, e.g., the differential configuration data, in or on the cell, e.g., in a dedicated register. The register contents may be called up, depending on a certain state, and entered into the cell. This may be accomplished, for example, by switching a multiplexer.
The wave reconfiguration methods described below may also be used. A differential configuration may be made dependent on the results (ACK/REJ) of a configuration performed previously in the normal manner. In this case, the differential configuration may be performed only after arrival of ACK for the previous nondifferential configuration.
An variant of synchronization of the differential configuration may be used, depending on how many different differential configurations are needed. The differential configuration is not. prestored locally. Instead, on recognition of a certain state, e.g., the end of a data input, a signal may be generated with a first cell, stopping the cell which is to be differentially reconfigured. Such a signal may be a STOP signal. After or simultaneously with stopping data processing in the cell which is to be reconfigured differentially, a signal may be sent to the CT, requesting differential reconfiguration of the stopped cell. This request signal for differential reconfiguration may be generated and sent by the cell which also generates the STOP signal. The CT may then send the data needed for differential reconfiguration to the stopped cell arid may trigger the differential reconfiguration. After differential reconfiguration, the STOP mode may be terminated, e.g., by the CT. It will be appreciated that Cache techniques may also be used in the differential reconfiguration method.
3. Example Function of Triggers
Triggers may be used in VPU modules to transmit simple information. Examples are listed below. Triggers may be transmitted by any desired bus system (network), e.g., a configurable bus system. The source and target of a trigger may be programmed.
A plurality of triggers may be transmitted simultaneously within a module. In addition to direct transmission from a source to a target, transmission from one source to multiple destinations or from multiple sources to one destination may also be provided.
Triggers transmissions may include:
Triggers may be generated by any cells and may be triggered in the individual cells by events. For example, the status register and/or the flag register may be used by ALUs or processors to generate triggers. Triggers may also be generated by a CT and/or an external unit arranged outside the cell array or the module.
Triggers may be received by any number of cells and may be analyzed in any manner. For example, triggers may be analyzed by a CT or an external unit arranged outside the cell array or the module.
Triggers may be used for synchronization and control of conditional executions and/or sequence controls in the array. Conditional executions and sequence controls may be implemented by sequencers.
3.1. Example Semantics of Triggers
Triggers may be used for actions within PAEs, for example:
For example, a first audio data packet may be processed with first filter coefficients; after running through the first audio data packet, a partial reconfiguration may take place, and then a different audio data packet may be processed with a second set of filter coefficients. To do so, the new reconfiguration data, e.g., the second filter coefficients, may be deposited in or at the cell, and the reconfiguration may be prompted automatically on recognition of the end of the first data packet without requiring further intervention of a CT or another external control unit.
Recognition of the end of the first data packet, e.g., the time when the reconfiguration is to be performed, may be accomplished by generating a wave reconfiguration trigger. The trigger may be generated, for example, in a cell which recognizes a data end. Reconfiguration then may run from cell to cell with the trigger as the cells finish processing of the first data packet, comparable to a "wave" running through a soccer stadium.
For example, a single cell may generate the trigger and send it to a first cell, for to indicate to the first cell that the end of a first packet has been run through. This first cell to be reconfigured, addressed by the wave trigger generating cell, may also relay the wave trigger signal simultaneously with the results derived from the last data of the first packet, which may be sent to one or more subsequently processing cells, sending the signal to these subsequently processing cells. The wave trigger signal may also be sent or relayed to those cells which are not currently involved in processing the first data packet and/or do not receive any results derived from the last data. Then the first cell to be reconfigured, which is addressed by the wave trigger signal generating cell, is reconfigured and begins processing the data of the second data packet. During this period of time, the subsequent cells may still be processing the first data packet. It should be pointed out that the wave trigger signal generating cell may address not only individual cells, but also multiple cells which are to be reconfigured. This may result in an avalanche-like propagation of the wave configuration.
Data processing may be continued as soon as the wave reconfiguration has been configured completely. In WAVE, it is possible to select whether data processing is continued immediately after complete configuration or whether there is a wait for arrival of a. STEP or GO.
Triggers are used for the following actions within CTs, for example:
Incoming triggers may reference a certain configuration. The corresponding method is described below.
Semantics need not be assigned to a trigger signal in the network. Instead, a trigger may represent only a state. How this state may be utilized by a respective receiving PAE may be configured in the respective receiving PAE. For example, a sending PAE may send only its status, and the receiving PAE generates the semantics valid for the received status. If several PAEs receive one trigger, different semantics may be used in each PAE, e.g., a different response may occur in each PAE. For example, a first PAE may be stopped, and a second PAE may be reconfigured. If multiple PAEs send one trigger, the event generating the trigger may be different in each PAE.
It should be pointed out that a wave reconfiguration and/or a partial reconfiguration can also take place in bus systems and the like. A partial reconfiguration of a bus can take place, for example, in reconfiguration by sections.
3.2. Example System Status and Program Pointer
A system may include a module or an interlinked group of modules, depending on the implementation. For managing an array of PAEs, which is designed to include several modules in the case of a system, it may not be necessary to know the status or program pointer of each PAE. Several cases are differentiated below in order to explain this further:
The interaction among PAEs may yield a common status which may be analyzed, e.g., in the CT, to determine how a reconfiguration is to take place. The analysis may include the instantaneous configuration of the network of lines and/or buses used to transmit the triggers if the network is configurable.
The array of PAEs (PA) may have a global status. Information may be sent through certain triggers to the CT. The CT may control the program execution through reconfiguration based on these triggers. A program counter may be omitted.
4. Example (Re)Configuration
VPU modules may be configured or reconfigured on the basis of events. These events may be represented by triggers (CONFIG) transmitted to a CT. An incoming trigger may reference a certain configuration (SubConf) for certain PAEs. The referenced SubConf may be sent to one or more PAES. Referencing may take place by using a conventional lookup system or any other address conversion or address generation procedure. For example, the address of the executing configuration (SubConf) may be calculated as follows on the basis of the number of an incoming trigger if the SubConfs have a fixed length:
offset+(trigger number*SubConf length).
VPU modules may have three configuration modes:
A configuration may include a set of configuration words (KWs). Each configuration may be referenced by a reference number (ID), which may be unique.
A set of KWs identified by an ID is referred to below as a subconfiguration (SubConf). Multiple SubConfs, which may run simultaneously on different PAEs, may be configured in a VPU. These SubConfs may be different or identical.
A PAE may have one or more configuration registers, one configuration word (KW) describing one configuration register. A KW may be assigned the address of the PAE to be configured. Information indicating the type of configuration may also be assigned to a KW. This information may be implemented using various methods, e.g., flags or coding. Flags are described in detail below.
4.1. Example ModuleID
For some operations, it may be sufficient for the CT to know the allocation of a configuration word and of the respective PAE to a SubConf. For more complex operations in the processing array, the ID of the SubConf assigned to an operation may be stored in each PAE.
An ID stored in the PA is referred to below as moduleID to differentiate the IDs within the CTs. There are several reasons for introducing moduleID, some of which are described here:
The moduleID may also be identical to the ID stored in the CT.
The moduleID may be written into a configuration register in the respective PAE. Since IDs may have a considerable width, e.g., more than 10 bits in most cases, it may not be efficient to provide such a large register in each PAE. Alternatively, the moduleID of the respective SubConf be derived from the ID. The alternative module ID may have a small width and may be unique. Since the number of all modules within a PA is typically comparatively small, a moduleID width of a few bits (e.g., 4 to 5 bits) may be sufficient. The ID and moduleID can be mapped bijectively on one another. In other words, the moduleID may uniquely identify a configured module within an array at a certain point in time. The moduleID may be issued to a SubConf before configuration so that the SubConf is uniquely identifiable in the PA at the time of execution. A SubConf may be configured into the PA multiple times simultaneously (see macros, described below). A unique moduleID may be issued for each configured SubConf for unambiguous allocation.
The transformation of an ID to a moduleID may be accomplished with lookup tables or lists. Since there are numerous conventional mapping methods for this purpose, only one is explained in greater detail here:
A list whose length is 2ModuleID contains the number of all IDs configured in the array at the moment, one ID being allocated to each list entry. The entry "0" characterizes an unused moduleID. If a new ID is configured, it must be assigned to a free list entry, whose address yields the corresponding moduleID. The ID is entered into the list at the moduleID address. On deletion of an ID, the corresponding list entry is reset at "0".
It will be appreciated that other mapping methods may be employed.
4.2. Example PAE States
Each KW may be provided with additional flags which may be used to check and control the status of a PAE:
If the PAE is in the "configured" or "allocated" state, the KW is not accepted. The rejection may be acknowledged with REJ.
After receipt of CHECK, a PAE may be switched to an "allocated" state. Any additional CHECK is rejected, but data processing is not started.
When the WAVE trigger is received, the configuration characterized with the WAVE flag may be loaded into the PAE. If WAVE configuration is performed before receipt of the trigger, the KWs characterized with the WAVE flag remain stored until receipt of the trigger and become active only with the trigger. If the WAVE trigger is received before the KW which has the WAVE flag, data processing is stopped until the KW is received.
At least CHECK or DIFFERENTIAL must be set for each KW transmitted. However, CHECK and DIFFERENTIAL are not allowed at the same time. CHECK and GO or DIFFERENTIAL and GO are allowed and will start data processing.
In addition, a flag which is not assigned to any KW and is set explicitly by the CT may also be implemented:
Thus, according to the FILMO principle, a change may be allowed in FILMO only during certain states. As discussed above, the FILMO state machine controls the transition to the "not configured" state through LOCK.
Depending on the implementation, the PAE may transmit its instantaneous status to a higher-level control unit (e.g., the respective CT) or stores it locally.
Example Transition Tables
A simple implementation of a state machine for observing the FILMO protocol is possible without using WAVE or CHECK/DIFFERENTIAL. Only the GO flag is implemented here, a configuration being composed of KWs transmitted together with GO. The following states may be implemented:
Current PAE status
Next status
not configured
GO flag
Local Reset Trigger
wait for lock
wait for lock
LOCK flag
not configured
A completed state machine according to the approach described here makes it possible to configure a PAE which requires several KWs. This is the case, for example, when a configuration which refers to several constants is to be transmitted, and these constants are also to be written into the PAE after or together with the actual configuration. An additional status is required for this purpose.
A corresponding transition table is shown below; WAVE is not included:
Current PAE status Event Next status not configured CHECK flag allocated not configured GO flag configured allocated GO flag configured configured Local Reset Trigger wait for lock wait for lock LOCK flag not configured
4.2.1. Example Implementation of GO
GO may be set immediately during the configuration of a PAE together with the KW in order to be able to start data processing immediately. Alternatively, GO may be sent to the respective PAEs after conclusion of the entire SubConf.
The GO flag may be implemented in various ways, including the examples described below:
a) Register
Each PAE may have a register which is set at the start of processing. The technical implementation is comparatively simple, but a configuration cycle may be required for each PAE. GO is transmitted together with the KW as a flag according to the previous description.
If it is important in which order PAEs of different PACs belonging to one EnhSubConf are configured, an alternative approach may be used to ensure that this chronological dependence is maintained. Since there are also multiple CTs when there are multiple PACs, the CTs may notify one another regarding whether all PAEs which must be configured before the next in each PAE have already accepted their GO from the same configuration.
One possibility of resolving the chronological dependencies and preventing unallowed GOs from being sent is to reassign the KWs. With reassignment, a correct order may ensured by FILMO. FILMO then marks, e.g., by a flag for each configuration, whether all GOs of the current configuration have been accepted. If this is not the case, no additional GOs of this configuration are sent. Each new configuration may have an initial status indicating all GOs have been accepted.
To increase the probability that some PAEs are no longer being configured during the configuration, the KWs of an at least partially sequential configuration can be re-sorted. The re-sorting permits the configuration the KWs of the respective PAEs at a later point in time. Certain PAEs may be activated sooner, e.g., by rearranging the KWs of the respective configuration so that the respective PAEs are configured earlier. These approaches may be used if the order of the KWs is not already determined completely by time dependencies that must be maintained after resorting.
b) Wiring by Conductor
As is the case in use of the local reset signal, PAEs may be combined into groups which are to be started jointly. Within this group, all PAEs are connected to a line for distribution of GO. If one group is to be started, GO is signaled to a first PAE. The signalling may be accomplished by sending a signal or setting a register (see a)) of the first PAE. From the first PAE, GO may be relayed to the other PAEs. One configuration cycle may be necessary for starting. For relaying, a latency time may be needed to bridge great distances.
c) Broadcast
An alternative to a) and b) offers a high performance (only one configuration cycle) with a comparatively low complexity.
All modules may receive a moduleID which may be different from the SubConfID.
It will be appreciated that it may be desirable to keep the size of the moduleID as small as possible. A width of a few bits (3 to 5) may be sufficient. The use of moduleID is explained in greater detail below.
During configuration, the corresponding moduleID may be written to each PAE.
GO is then started by a broadcast, by sending the moduleID together with the GO command to the array. The command is received by all PAEs, but is executed only by the PAEs having the proper moduleID.
4.2.2. Locking the PAE Status
The status of a PAE may need to be prevented from changing from "configured" to "not configured" within a configuration or a FILMO run. Example: Two different SubConfs (A, D) share the same resources, in particular, a PAE X. In FILMO, SubConf
A precedes SubConf D in time. SubConf A must therefore occupy the resources before SubConf D. PAE X is "configured" at the configuration time of SubConf A, but it changes its status to "not configured" before the configuration of SubConf D. This may result in a deadlock situation, because now SubConf A can no longer configure PAE X, but SubConf D can no longer configure the remaining resources which are already occupied by SubConf A. Neither SubConf A nor SubConf D can be executed. As mentioned previously, LOCK may ensure that the status of a PAE does not change in an inadmissible manner during a FILMO run. For the FILMO principle it is irrelevant how the status is locked. Several possible locking approaches are discussed below:
Basic LOCK
Before beginning the first configuration and with each new run of FILMO, the status of the PAEs is locked. After the end of each run, the status is released again. Thus, certain changes in status may be allowed only once per run.
Explicit LOCK
The lock signal is set only after the first REJ from the PA since the start of a FILMO run. This is possible because previously all the PAEs could be configured and thus already were in the "unconfigured" state. Only a PAE which generates a REJ could change its status from "configured" to "not configured" during the additional FILMO run. A deadlock could occur only after this time, namely when a first KW receives a REJ and a later one is configured. However, the transition from "configured" to "not configured" is prevented by immediately setting LOCK after a REJ. With this approach, during the first run phase, PAEs can still change their status, which means that they can change to the "unconfigured" state. If a PAE thus changes from "configured" to "not configured" during a run before a failed configuration attempt, their it can be configured in the same configuration phase.
Implicit LOCK
A more efficient extension of the explicit LOCK is the implicit handling of LOCK within a PAE.
In general, only PAEs which have rejected (REJ) a configuration may be affected by the lock status. Therefore, it is sufficient during a FILMO run to lock the status only within PAEs that have generated a REJ. All other PAEs may remain unaffected. LOCK is no longer generated by a higher-level instance (CT). Instead, after a FILMO run, the lock status in the respective PAEs may be canceled by a FREE signal. FREE can be broadcast to all PAEs directly after a FILMO run and can also be pipelined through the array.
Example Extended Transition Tables for Implicit LOCK;
A reject (REJ) generated by a PAE may be stored locally in each PAE (REJD=rejected). The information is deleted only on return after "not configured."
Current PAE status
Next status
not configured
CHECK flag
not configured
GO flag
GO flag
Local reset trigger
Wait for free
and reject (REJD)
Local reset trigger
not configured
and no reject (not
wait for free
FREE flag
not configured
It will be appreciated that the transition tables are given as examples and that other approaches may be employed.
4.2.3. Example Configuration of a PAE
An example configuration sequence is described again in this section from the standpoint of the CT. A PAE shall also be considered to include parts of a PAE if they manage the states described previously, independently of one another.
If a PAE is to be reconfigured, the first KW may need to set the CHECK flag to check the status of the PAE. A configuration for a PAE is constructed so that either (a) only one KW is configured:
or (b) multiple KWs are configured, with CHECK being set with the first KW and DIFFERENTIAL being set with all additional KWs.
(X) set, (—) not set, GO is optional (*).
If CHECK is rejected (REJ), no subsequent KW with a DIFFERENTIAL flag is sent to the PAE. After CHECK is accepted (ACK), all additional CHECKs are rejected until the return to the state "not configured" and the PAE is allocated for the accepted SubConf. Within this SubConf, the next KWs may be configured exclusively with DIFFERENTIAL. It will be appreciated that this is allowed because it is known by CHECK that this SubConf has access rights to the PAE.
4.2.4. Resetting to the Status "Not Configured"
With a specially designed trigger (e.g., local reset), a signal which triggers local resetting of the "configured" state to "not configured" is triggered in the receiving PAEs. This occurs, at the latest, after a LOCK or FREE signal is received. Resetting may also be triggered by other sources, such as a configuration register.
Local reset can be relayed from the source generating the signal over all existing configurable bus connections, e.g., all trigger buses and all data buses, to each PAE connected to the buses. Each PAE receiving a local reset may in turn relay the signal over all the connected buses.
However, it may be desirable to prevent the local reset trigger from being relayed beyond the limit of a local group. Each cell may be independently configured. Each cell configuration may indicate whether and over which connected buses the local reset is to be relayed.
22.214.171.124. Deleting an Incompletely Configured SubConf
It may be found that the SubConf is not needed during configuration of a SubConf. For example, local reset may not change the status of all PAEs to "not configured" because the bus has not yet been completely established. Two alternative approaches are proposed. In both approaches, the PAE which would have generated the local reset sends a trigger to the CT. Then the CT informs the PAEs as follows:
126.96.36.199. When Using moduleID
If a possibility for storage of the moduleID is provided within each PAE, then each PAE can be requested to go to the status "not configured" with this specific ID. This may be accomplished with a simple broadcast in which the ID is also sent.
126.96.36.199. When Using the GO Signal
If a GO line is wired in exactly the order in which the PAEs are configured, a reset line may be assigned to the GO line. The reset line may set all the PAEs in the state "not configured."
184.108.40.206. Explicit Reset by the Configuration Register
In each PAE, a bit or a code may be defined within the configuration register. When this bit or code is set by the CT, the PAE is reset in the state "not configured."
4.3. Holding the Data in the PAEs
It is advantageous to hold the data and states of a PAE beyond a reconfiguration. Data stored within a PAE may be preserved despite reconfiguration. Appropriate information in the KWs, may define for each relevant register whether the register is reset by the reconfiguration.
For example, if a bit within a KW is logical 0, the current register value of the respective data register or status register may be retained. A logical 1 resets the value of the register. A corresponding KW may then have the following structure:
Input register
Output register
Status flags
Whether or not the data will be preserved, may then be selected with each reconfiguration.
4.4. Setting Data in the PAEs
Date may be written into the registers of the PAEs during reconfiguration of the CT. The relevant registers may be addressed by KWs. A separate bit may indicate whether the data is to be treated as a constant or as a data word.
The bus protocol may be extended by also pipelining the KWs and ACK/REJ signals through registers.
One KW or multiple KWs may be sent in each clock cycle. The FILMO principle may be maintained. An allocation to a KW may be written to the PA in such a way that the delayed acknowledgment is allocated subsequently to the KW. KWs depending on the acknowledgment may be re-sorted so that they are processed only after receipt of the acknowledgment.
Several alternative approaches are described below:
5.1. Example Lookup Tables (STATELUT)
Each PAE may send its status to a lookup table (STATELUT). The lookup table may be implemented locally in the CT. In sending a KW, the CT may check the status of the addressed PAE via a lookup in the STATELUT. The acknowledgment (ACK/REJ) may be generated by the STATELUT.
In a CT, the status of each individual PAE may be managed in a memory or a register set. For each PAE there is an entry indicating in which mode ("configured," "not configured") the PAE is. On the basis of this entry, the CT checks on whether the PAE can be reconfigured. This status is checked internally by the CT, e.g., without checking back with the PAEs. Each PAE sends its status independently or after a request, depending on the implementation, to the internal STATELUT within the CT. When LOCK is set or there is no FREE signal, no changes in status are sent by the PAEs to the STATELUT and none are received by the STATELUT.
The status of the PAEs may be monitored by a simple mechanism, with the mechanisms of status control and the known states that have already been described being implemented.
Setting the "Configured" Status
When writing a KW provided with a CHECK flag, the addressed may be marked as "allocated" in the STATELUT.
Several methods may be used, depending on the application and implementation:
To check the status of a PAE during configuration, the STATELUT may be queried when the address of the target PAE of a KW is sent. An ACK or REJ may be generated accordingly. A KW may be sent to a PAE only if no REJ has been generated or if the DIFFERENTIAL flag has been set.
This approach ensures the chronological order of KWs. Only valid KWs are sent to the PAEs. One disadvantage here is the complexity of the implementation of the STATELUT and the resending of the PAE states to the STATELUT. Bus bandwidth and running time may also be required for this approach.
5.2. Example Re-sorting the KWs
The use of the CHECK flag for each first KW (KW1) sent to a PAE may be needed in the following approach.
The SubConf may be resorted as follows:
Upon receipt of ACK for a KW1, all additional KW1s for the corresponding PAE may be configured. If the PAE acknowledges this with REJ, no other KW pertaining to the PAE may be configured.
This procedure guarantees that the proper order will be maintained in configuration.
A disadvantage of this approach is that the optimum configuration speed may not be achieved. To maintain the proper order, the waiting time of an atom may optionally have to be filled with dummy cycles (NOPs), so the usable bandwidth and the size of a SubConf are increased by the NOPs.
This restriction on the configuration speed may be difficult to avoid. To minimize the amount of configuration data and configuration cycles, the number of configuration registers may need to be minimized. At higher frequencies, DELAY necessarily becomes larger, so this collides with the requirement that DELAY be used appropriately by filling up with KW.
Therefore, approach is most appropriate for use in serial transmission of configuration data. Due to the serialization of KWs, the data stream is long enough to fill up the waiting time.
5.3. Analyzing the ACK/REJ Acknowledgment with Latency (CHECK, ACK/REJ)
The CHECK signal may be sent to the addressed PAE with the KWs over one or more pipeline stages. The addressed PAE acknowledges (ACK/REJ) this to the CT, also pipelined.
In each cycle, a KW may be sent. The KW's acknowledgment (ACK/REJ) is received by the CT n cycles later. The KW and its acknowledgment may be analyzed. However, during this period of time, no additional KWs are sent. This results in two problem areas:
The requests described here may be implemented as follows: Another memory (RELJMP) which has the same depth as the FILMO may be assigned to the FILMO. A first counter (ADR_CNT) points to the address in the FILMO of the KW currently being written into the PAE array. A second counter (ACK/REJ_CNT) points to the position in the FILMO of the KW whose acknowledgment (ACK/REJ) is currently returning from the array. A register (LASTREJ) stores the value of ACK/REJ_CNT which points to the address of the last KW whose configuration was acknowledged with REJ. A subtractor calculates the difference between ACK/REJ_CNT and LASTREJ. On occurrence of a REJ, this difference is written into the memory location having the address LASTREJ in the memory RELJMP.
RELJMP thus contains the relative jump width between a rejected KW and the following KW.
The memory location of the first address of a SubConf is occupied by a NOP in the FILMO. The associated RELJMP contains the relative jump to the first KW to be processed.
It will be appreciated that other approaches to coding various conditions may be employed.
5.3.2. Observing the Sequence (BARRIER)
The method described in section 5.3, may not guarantee a certain configuration sequence. This method only ensures the FILMO requirements according to 2.1 a)-c).
In certain applications, it is relevant to observe the configuration sequence within a SubConf (2.1 e)) and to maintain the configuration sequence of the individual SubConfs themselves (2.1 d)).
Observing sequences may be accomplished by partitioning SubConf into multiple blocks. A token (BARRIER) may be inserted between individual blocks, and can be skipped only if none of the preceding KWs has been rejected (REJ).
If the configuration reaches a BARRIER, and REJ has occurred previously, the BARRIER must not be skipped. A distinction is made between at least two types of barriers:
Considerations on optimization of the configuration speed: It is not normally necessary to observe the sequence of the configuration of the individual KWs. However, the sequence of activation of the individual PAEs (GO) may need to be observed exactly. The speed of the configuration can be increased by re-sorting the KWs so that all the KWs in which the GO flag has not been set are pulled before the BARRIER. Likewise, all the KWs in which the CHECK flag has been set may need to be pulled before the BARRIER. If a PAE is configured with only one KW, the KW may need to be split into two words, the CHECK flag being set before the BARRIER and the GO flag after the BARRIER.
At the BARRIER it is known whether all CHECKS have been acknowledged with ACK. Since a reject (REJ) occurs only when the CHECK flag is set, all KWs behind the barrier are may be executed in the correct order. The KWs behind the barrier may be run through only once, and the start of the individual PAEs occurs properly.
5.3.3. Garbage Collector
Two different implementations of a garbage collector (GC) are suggested for the approach described in to 5.3.
Alternative to 5.3 may be used. The disadvantage of this alternative approach is the comparatively long latency time, corresponding to three times the length of the pipeline.
The addresses and/or flags of the respective PAEs to be configured may be sent on a separate bus system before the actual configuration. The timing may be designed so that at the time the configuration word is to be written into a PAE, its ACK/REJ information is available. If acknowledged with ACK, the CONFIGURATION may be performed; in the case of a reject (REJ), the KWs are not sent to the PAE (ACK/REJ-PREFETCH). FILMO protocol, in particular LOCK, ensures that there will be no unallowed status change of the PAEs between ACK/REJ-PREFETCH and CONFIGURATION.
5.4.1. Structure of FILMO
FILMO may function as follows: KWs may be received in the correct order, either (i) from the memory of the CT or (ii) from the FILMO memory.
The PAE addresses of the KWs read out may be sent to the PAEs, pipelined through a first bus system. The complete KWs may be written to a FIFO-like memory having a fixed delay time (e.g., a shift register).
The respective PAE addressed may acknowledges this by sending ACK or REJ, depending on the PAE's status. The depth of the FIFO corresponds to the number of cycles that elapse between sending the PAE address to a PAE and receipt of the acknowledgment of the PAE. The cycle from sending the address to a PAE until the acknowledgment of the PAE is received is known as prefetch.
Due to the certain delay in the FIFO-like memory, which is not identical to FILMO here, the acknowledgment of a PAE may be received at the CT exactly at the time when the KW belonging to the PAE appears at the output of the FIFO. Upon receipt of ACK, the KW may be sent to the PAE. Here, no acknowledgment is expected. The PAE status has not changed in an admissible manner in the meantime, so that acceptance is guaranteed.
Upon receipt of REJ, the KW is not sent to the PAE but instead may be written back into the FILMO memory. An additional pointer is available for this, which points to the first address at the beginning of linear readout of the FILMO memory. The counter may be incremented with each value written back to the memory. In this way, rejected KWs are automatically packed linearly, which corresponds to an integrated garbage collector run (see also 5.3).
5.4.2. Sending and Acknowledging Over a Register Pipeline
The approach described here may be used to ensure a uniform clock delay between messages sent and responses received if different numbers of registers are connected between one transmitter and multiple possible receivers of messages. One example of this would be if receivers are located at different distances from the transmitter. The message sent may reach nearby receivers sooner than more remote receivers.
To achieve the same transit time for all responses, the response is not sent back directly by the receiver. Instead the response is sent further, to the receiver at the greatest distance from the sender. This path must have the exact number of receivers so that the response will be received at the time when a response sent simultaneously with the first message would be received at this point. From here out, the return takes place exactly as if the response were generated in this receiver at the greatest distance from the sender.
It will be appreciated that it does not matter here whether the response is actually sent to the most remote receiver or whether it is sent to another chain having registers with the same time response.
6. Hierarchical CT Protocol
As described in PACT10, VPU modules may be scalable by constructing a tree of CTs, the lowest CTs (low-level CTs) of the PAs being arranged on the leaves. A CT together with the PA assigned to the CT is known as a PAC. In general, any desired data or commands may be exchanged between CTs. Any technically appropriate protocol can be used for this purpose.
However, if the communication (inter-CT communication) causes SubConf to start on various low-level CTs within the CT tree (CTTREE), the requirements of the FILMO principle should be ensured to guarantee freedom from deadlock.
In general, two cases are to be distinguished:
The protocol described in PACT10 may be inefficient as soon as a pipelined transmission at higher frequencies is necessary. This is because bus communication is subject to a long latency time.
An alternative approach is described in the following sections.
A main function of inter-CT communication is to ensure that SubConfs involving multiple PACs are started without deadlock. Enhanced subconfiguration ("EnhSubConfs") are SubConfs that are not just executed locally on one PAC but instead may be distributed among multiple PACs. An EnhSubConf may include multiple SubConfs, each started by way of low-level CTs. A PAC may include a PAE group having at least one CT.
In order for multiple EnhSubConfs to be able to run on identical PACs without deadlock, a prioritization of their execution may be defined by a suitable mechanism (for example, within the CTTREE). If SubConfs are to be started from multiple different EnhSubConfs running on the same PACs, then these SubConfs may be started on the respective PACs in a chronological order corresponding to their respective priorities.
Example: Two EnhSubConfs are to be started, namely EnhSubConf-A on PACs 1, 3, 4, 6 and EnhSubConf-B on PACs 3, 4, 5, 6. It is important to ensure that EnhSubConf-A is always configured on PACs 3, 4 and 6 exclusively either before or after EnhSubConf-B. For example, if EnhSubConf-A is configured before EnhSubConf-B on PACs 3 and 4, and if EnhSubConf-A is to be configured on PAC 6 after EnhSubConf-B, a deadlock occurs because EnhSubConf-A could not be started on PAC 6, and EnhSubConf-B could not be started on PACs 3 and 4. Such a case is referred to below as crossed or a cross.
To prevent deadlock, it is sufficient to prevent EnhSubConfs from crossing. If there is an algorithmic dependence between two EnhSubConfs, e.g., if one EnhSubConf must be started after the other on the basis of the algorithm, this is normally resolved by having one EnhSubConf start the other.
Example Protocol
Inter-CT communication may distinguish two types of data:
Inter-CT communication may differentiate between the following transmission modes:
Examples of the structure of SubConf have been described in patent applications PACT05 and PACT10.
The approach discussed here includes separate handling of call-up of SubConf by ID chains. An ID chain is a SubConf having the following property:
Individual SubConfs may be stored within the CTTREE, e.g., by caching them. A SubConf need not be reloaded completely, but instead may be sent directly to the lower-level CT from a CT which has cached the corresponding SubConf. In the case of an ID chain, all the lower-level CTs may need to be loaded from a central CT according to the protocol described previously. It may be efficient if the CT at the lowest level in the CTTREE, which still has all the PACs listed in the ID chain as leaves, has the ID chain in its cache. CTs at an even lower level may need to not store anything in their cache, because they are no longer located centrally above all the PACs of the ID chain. Higher-level CTs may lose efficiency because a longer communication link is necessary. If a request reaches a CT having a complete ID chain for the EnhSubConf requested, this CT may trigger GRANTs to the lower-level CTs involved. The information may be split out of the ID chain so that at least the part needed in the respective branches is transmitted. To prevent crossing in such splitting, it may be necessary to ensure that the next CT level will also trigger all GRANTs of its part of the EnhSubConf without being interrupted by GRANTs of other EnhSubConfs. One approach to implementing this is to transmit the respective parts of the ID chain "atomically." To control the caching of ID chains, it may be useful to mark a split ID chain with a "SPLIT" flag, for example, during the transmission.
An ID chain may be split when it is loaded onto a CT which is no longer located centrally within the hierarchy of the CTTREE over all the PACs referenced within the ID chain. In this case, the ID chain may no longer be managed and cached by a single CT within the hierarchy. Multiple CTs may process the portion of the ID chain containing the PACs which are leaves of the respective CT. A REQUEST may need to be relayed to a CT which manages all the respective PACs. It will be appreciated that the first and most efficient CT in terms of hierarchy (from the standpoint of the PACs) which can convert REQUEST to GRANT may be the first CT in ascending order, starting from the leaves, which has a complete, unsplit ID chain. Management of the list having allocations of PAC to ID does not require any further explanation. The list can be processed either by a program running within a CT or it may be created from a series of assembler instructions for controlling lower-level CTs.
A complete ID chain may then have the following structure: IDEnhSubConf} ID chain{SPLIT, (PAC1:IDSubConf1), (PAC2: IDSubConf2), (PAC3:IDSubConf3) . . . (PACn:IDSubConfn)}
6.1. Example Procedure for Precaching SubConfs
Within the CTTREE, SubConfs may be preloaded according to certain conditions, e.g., the SubConfs may be cached before they are actually needed. This method may greatly improve performance within the CTTREE.
A plurality of precache requests may be provided. These may include:
The SubConf to be loaded may be cached without being started. The start may take place at the time when the SubConf would have been started without prior caching. The difference is that at the time of the start request, the SubConf is already stored in the low-level CT or one of the middle-level CTs and either may be configured immediately or may be loaded very rapidly onto the low-level CT and then started. This may eliminate a time-consuming run-through of the entire CTTREE.
A compiler, which generates the SubConf, makes it possible to decide which SubConf is to be cached next. Within the program sequence graphs, it may be possible to see which SubConfs could be executed next. These are then cached. The program execution decides in run time which of the cached SubConfs is in fact to be started.
A preloading mechanism may be provided which removes the cached SubConf to make room in the memory of the CT for other SubConfs. Like precaching, deletion of certain SubConfs by the compiler can be predicted on the basis of program execution graphs.
Mechanisms for deletion of SubConfs as described in PACT10, (e.g., the one configured last, the one configured first, the one configured least often (see PACT10)) may be provided in the CTs in order to manage the memory of the CT accordingly. It will be appreciated that not only explicitly precached SubConfs can be deleted, but also any SubConf in a CT memory generally be deleted. If the garbage collector has already removed a certain SubConf, the explicit deletion becomes invalid and may be ignored.
An explicit deletion can be brought about through a command which may be started by any SubConf. This includes any CT within the tree, its own CT or explicit deletion of the same SubConf (e.g., deletion of its own Subconf in which the command stands, in which case correct termination must be ensured).
Another possibility of explicit deletion is to generate, on the basis of a certain status within the PAs, a trigger which is relayed to the CT and analyzed as a request for explicit deletion.
6.2. Interdependencies Among PAEs
For the case when the sequence in which PAEs of different PACs belonging to one EnhSubConf are configured is relevant, an alternative procedure may be provided to ensure that this chronological dependence is maintained. Since there may be multiple CTs in the case of multiple PACs, these CTs may exchange information to determine whether all PAEs which must be configured before the next PAE in each PAC have already accepted their GO from the same configuration. One possibility of breaking up the time dependencies and preventing unallowed GOs from being sent is to exchange the exclusive right to configuration among the CTs. The KWs may be recognized so that a correct order is ensured through the sequence of their configurations and the transfer of the configuration rights. Depending on how strong the dependencies are, it may be sufficient if both CTs configure their respective PA in parallel up to a synchronization point. The CTs may then wait for one another and continue configuring in parallel until the next synchronization point. Alternatively, if no synchronization point is available, the CTs may continue configuring in parallel until the end of the EnhSubConf.
7. Example SubConf Macros
It will be appreciated that caching of SubConf may be especially efficient if as many SubConfs as possible can be cached. Efficient use of caching may be particularly desirable with high-level language compilers, because compilers often generate recurring routines on an assembler level, e.g., on a SubConf level in VPU technology.
In order to maximize reuse of SubConf, special SubConf macros (SubConfM) having the following properties may be introduced:
With a special SubConf macros, the absolute addresses are not calculated until the time when the SubConf is loaded into the PA. Parameters may be replaced by their actual values. To do so, a modified copy of the original special SubConf may be created so that either (I) this copy is stored in the memory of the CT (integrated FILMO) or (ii) it is written immediately to the PA, and only rejected KWs (REJ) are written into FILMO (separate FILMO). It will be appreciated that in case (ii), for performance reasons, the address adder in the hardware may sit directly on the interface port of the CT to the PA/FILMO. Likewise, hardware implementations of parameter transformation may also me employed, e.g., through a lookup table which is loaded before configuration.
8. Re-storing Cache Statistics
International Patent WO 99/44120 (PACT10) describes application-dependent cache statistics and control. This method permits an additional data-dependent optimization of cache performance because the data-dependent program performance is expressed directly in cache optimization.
One disadvantage of the known method is that cache performance is optimized only during run time. When the application is restarted, the statistics are lost. When a SubConf is removed from the cache, its statistics are also lost and are no longer available, even when called up again even within the same application processing.
In an example embodiment according to the present invention, on termination of an application or removal of a SubConf from the cache, the cache statistics may be sent first together with the respective ID to the next higher-level CT by way of the known inter-CT communication until the root CT receives the respective statistics. The statistics may be stored in a suitable memory, e.g., in a volatile memory, a nonvolatile memory or a bulk memory, depending on the application. The memory may be accessed by way of a host. The statistics may be stored so that they are allocated to the respective SubConf. The statistics may also be loaded again when reloading the SubConf. In a restart of SubConf, the statistics may also be loaded into the low-level CT.
The compiler may either compile neutral blank statistics or generates statistics which seem to be the most suitable statistics for a particular approach. These statistics preselected by the compiler may then be optimized in run time according to the approach described here. The preselected statistics may also be stored and made available in the optimized version the next time the application is called up.
If a SubConf is used by several applications or by different low-level CTs within one application (or if the SubConf is called up from different routines), then it may not be appropriate to keep cache statistics because the request performance and run performance in each case may produce different statistics. Depending on the application, either no statistics are used or a SubconfM may be used.
When using a SubConfM, the transfer of parameters may be extended so that cache statistics are transferred as parameters. If a SubConfM is terminated, the cache statistics may be written back to the SubConf (ORIGIN) which previously called up the SubConfM. In the termination of ORIGIN, the parameters may then be stored together with the cache statistics of ORIGIN. The statistics may be in a subsequent call-up and again be transferred as parameters to the SubConfM.
Keeping and storing application-based cache statistics may be also be suitable for microprocessor, DIPS, FPGA and similar modules.
9. Structure of the Configuration Bus System
PACT07 describes an address—and pipeline-based data bus system structure. This bus system is suitable for transmitting configuration data.
In an example embodiment of the present invention, in order to transmit data and configurations over the same bus system, status signals indicating the type of data transmitted may be introduced. The bus system may be designed so that the CT can optionally read back configuration registers and data registers from a PAE addressed previously by the CT.
Global data as describe in PACT07 as well as KWs may be transmitted over the bus system. The CT may act as its own bus node. A status signal may be employed to characterize the transmission mode. For example, the following structure is possible with signals S0 and S1:
Write data
Read data
Write a KW and/or a PAE address
Return a KW or any register from the addressed PAE
The REJ signal may be added to the bus protocol (ACK) according to PACT07 to signal rejects to the CT describe in FILMO protocol.
10. Example Procedure for Combining Individual Registers
Independent configuration registers may be used for a logical separation of configuration data. The logical separation may be needed for the differential-configuration because logically separated configuration data is not usually known when carrying out a differential configuration. This may result in a large number of individual configuration registers, each individual register containing a comparatively small amount of information. In the following example, the 3-bit configuration values KW-A, B, C, D can be written or modified independently of one another:
Such a register set may be inefficient, because only a fraction of the bandwdith of the CT bus is used.
The structure of configuration registers may be greatly optimized by assigning an enable to each configuration value, indicating whether the value is to be overwritten in the current configuration transfer.
Configuration values KW-A, B, C, D of the above example are combined in one configuration register. An enable is assigned to each value. For example, if EN-x is logical "0," the KW-x is not changed in the instantaneous transfer; if EN-x is logical "1," KW-x is overwritten by the instantaneous transfer.
En-A KW-A En_B KW-B En-C KW-C En-D KW-D
11. Wave Reconfiguration (WRC)
PACT13 describes a reconfiguration method ("wave reconfiguration "or" "WRC") in which reconfiguration is synchronized directly and chronologically with the data stream See, e.g.,
The proper functioning of Wave reconfiguration, may require that unconfigured PAEs can neither accept nor send data or triggers. This means that an unconfigured PAE behaves completely neutrally. This may be provided in VPU technology by using handshake signals (e.g., RDY/ACK) for trigger buses and data buses (see, e.g., U.S. Pat. No. 6,425,068). An unconfigured PAE then generates
This mode of functioning is not only helpful for wave reconfiguration, but it is also one of the possible bases for run time reconfigurability of VPU technology.
An extension of this approach is explained below. Reconfiguration may be synchronized with ongoing data processing. Within data processing in the PA, it is possible to decide
The decision as to which configuration is loaded may be made based on conditions and is represented by triggers (wave configuration preload=WCP).
Linking of the data packets to the KWs of a SubConf may be ensured by the data bus protocol (RDY/ACK) and the CT bus protocol (CHECK, ACK/REJ). An additional signal (wave configuration trigger=WCT) may indicate in which data packet (ChgPkt) reconfiguration is to be performed and optionally which new configuration is to be carried out or loaded. WCT can be implemented through simple additional lines or the trigger system of the VPU technology. Multiple VPUs may be used simultaneously in the PA, and each signal may control a different reconfiguration.
11.1. Example Procedure for Controlling the Wave Reconfiguration
It will appreciated that a distinction may be made between two application-dependent WRCs:
During data processing, the WRCRegs that are valid at that time may be selected by one or more WCTs.
The effects of wave reconfiguration on the FILMO principle are discussed below.
11.1.1. Performing WRC According to A1
Reconfiguration by WRC may be possible at any time within a SubConf (A1). First, the SubConf may be configured normally, so the FILMO principle is ensured. During program execution, WRCs may need to use only resources already allocated for the SubConf.
Case I1)
WRC may performed by differential configuration of the respective PAEs. WCP may be sent to the CT. Depending on the WCP, there may be a jump to a token within the configured SubConf:
An example code is given below:
begin SubConf
. . .
PAE n, CHECK&GO
set TriggerPort 1 // WCT 1
set TriggerPort 2 // WCT 2
on TriggerPort 1, do main1 // jump depending on WCT
on TriggerPort 2, do main2 // jump depending on WCT
wait for trigger
. . .
PAE n, DIFFERENTIAL&GO
wait for trigger
. . .
PAE n, DIFFERENTIAL&GO
wait for trigger
end SubConf
The interface (TrgIO) between CT and WCP may be configured by "set Triggerport." According to the FILMO protocol, TrgIO behaves like a PAE with respect to the CT, e.g., TrgIO corresponds exactly to the CHECK, DIFFERENTIAL, GO protocol and responds with ACK or REJ for each trigger individually or for the group as a whole.
If a certain trigger has already been configured, it may Despond with REJ.
If the trigger is ready for configuration, it responds with ACK.
Upon receipt of WCT, the respective PAE may start the corresponding configuration.
Case I2)
If the WRCRegs have already been written during the configuration, the WCP may be omitted because the complete SubConf has already been loaded into the respective PAE
Alternatively, depending on certain WCPs, certain WRCs may be loaded by the CT into different WRCRegs defined in the WRC. This may be necessary when, starting from one SubConf, it branches off into more different WRCs due to WRTs than are present as physical WRCRegs.
The trigger ports within the PAEs may be configured so that certain WRCRegs are selected due to certain incoming WRTs:
begin SubConf main: PAE1_TriggerPort 1 PAE1_TriggerPort 2 PAE1_WRCReg1 PAE1_WRCReg2 PAE1_BASE, CHECK&GO . . . PAE2_TriggerPort 1 PAE2_TriggerPort 2 PAE2_WRCReg1 PAE2_WRCReg2 PAE2_BASE, CHECK&GO . . . PAEn_TriggerPort 1 PAEn_TriggerPort 2 PAEn_WRCReg1 PAEn_WRCReg2 PAEn_BASE, CHECK&GO endSubConf
11.1.2. Performing WRC According to A2
Case I1)
The CT performing a WRC between different SubConfs corresponds in principle to A1/I1. The trigger ports and the CT-internal sequencing may need to correspond to the FILMO principle. KWs rejected by the PAEs (REJ) may be written to FILMO. These principles have been described in PACT10.
All WCPs may be executed by the CT. It will be appreciated that this may guarantee a deadlock-free (re)configuration. Likewise, the time of reconfiguration, which may be marked by WCT, may be sent to the CT and may be handled atomically by the CT. For example, all PAEs affected by the reconfiguration may receive the reconfiguration request through WCT either simultaneously or at least without interruption by another reconfiguration request. It will be appreciated that this approach may guarantee freedom from deadlock.
Case I2)
If the WRCRegs are already written during the configuration the WCP may be omitted because the complete SubConf is already loaded into the respective PAE.
Alternatively, depending on certain WCPs, WRCs determined by the CT may be loaded into different WRCRegs defined in the WRC. It will be appreciated this approach may be necessary when, starting from a SubConf, branching off into more different WRCs due to WRTs than there are physical WRCRegs.
Several WCTs being sent to different PAEs at different times may need to be prevented because this may result in deadlock.
For example: WCT1 of a SubConf SA reaches PAE p1 in cycle t1, and WCT2 of a SubConf SB reaches PAE p2 at the same time. The PAEs are configured accordingly. At time t2, WCT1 reaches p2 and. WCT2 reaches p1. A deadlock has occurred. It should also be pointed out that this example can also be applied in principle to A2-I1. It will be appreciated that, this is why WCT there may be sent through the trigger port of the CT and may be handled by the CT.
A deadlock may also be prevented by the fact that the WCTs generated by different PAEs (sources) are prioritized by a central instance (ARB). This permits exactly one WCT is sent to the respective PAEs in one cycle. Various approaches to prioritization may be used. Example prioritization approaches are listed below.
Suitable relaying of WCTs from ARB to the respective PAEs may ensure that prioritized WCTs are received by the PAEs in the correct order. An example approach to ensuring this order is for all triggers going from ARB to the respective PAEs to have exactly the same length and transit time. This may be ensured by suitable programming. This may also be ensured by a suitable layout through a router, e.g., by adjusting the wiring using registers to compensate for latency at the corresponding points. To ensure correct relaying, the procedure described in PACT18 may also be used for time synchronization of information.
No explicit prioritization of WCPs may be needed because the WCPs sent to the CT may be processed properly by the FILMO principle within the CT. It may be possible to ensure that the time sequence is maintained, e.g., by using the FILMO principle (see 2.1e).
11.1.3. Note for all Cases
The additional configuration registers of the PAEs for wave reconfiguration may be configured to behave according to the FILMO principle, i.e., the registers may support the states described and the sequences implemented and respond to protocols such as CHECK and ACK/REJ.
11.2. Example Reconfiguration Protocols and Structure of WRCReq
The wave reconfiguration procedure will now be described in greater detail. Three alternative reconfiguration protocols are described below.
Normal CT protocol: The CT may reconfigure each PAE individually only after receipt of a reconfiguration reques. For example, the CT may receive a reconfiguration request for each PAE reached by ChgPkt. This approach may not be efficient because it entails a very high communication complexity, e.g., for pipelined bus systems.
Synchronized pipeline: This protocol may be much more efficient. The pipelined CT bus may be used as a buffer. The pipeline register assigned to a PAE may store the KWs of this PAE until the PAE can receive the KWs. Although the CT bus pipeline (CBP) is blocked, it can be filled completely with the KWs of the wave reconfiguration.
Synchronized shadow register: (This protocol may be the most efficient). Immediately after selection of the SubConf (I) and before receipt of ChgPkt (ii), the CT may write new KWs into the shadow registers of all PAEs. The shadow registers may be implemented in any embodiment. The following possibilities are suggested in particular: a) a register stage connected upstream from the actual configuration register, b) a parallel register set which is selected by multiplexers, c) a FIFO stage upstream from the actual configuration registers. At the time when ChgPkt (ii) is received by a PAE, it copies the shadow register into the corresponding configuration register. In the optimum case, this copying may take place in such a way that no working cycle is lost. If no writing into the shadow register takes place (e.g., if it is empty) despite the receipt of ChgPkt, data processing may stop until the KW is received by the shadow register. If necessary, the reconfiguration request may be relayed together with ChgPkt from one PAE to the next within a pipeline.
12. Forms of Parallelism and Sequential Processing
Due to a sufficiently high reconfiguration performance, sequential computational models can be mapped in arrays. Pro example, the low-level CTs may represent a conventional code fetcher. The array may operate with microprogrammable networking as a VLIW-ALU. Different forms of parallelism may be mapped in arrays of computing elements. Examples may include:
With a sufficient number of PAEs, all the essential parts of conventional microprocessors may be configured on the PA. This may allow sequential processing of a task even without a CT. The CT need not become active again until the configured processor is to have a different functionality, e.g., in the ALU, or is to be replaced completely.
13. Exemplary Embodiments and Diagrams
It will be appreciated that in configuring a PAE X a check may first be performed then, receipt of ACK/REJ may be waited on. A PAE that has already been checked may be configured further during this period of time, or NOPs must be introduced. PAE X may then be configured further. Example: Check of PAE (0302), continuation of configuration (0306). At 0307, NOPs may need to be introduced after a check because no differential configurations are available. Points 0308 illustrate the splitting of configurations over multiple blocks (three in this case), with one check being omitted (0309).
Local reset and LAST can also be sent by the CT through a broadcast (see moduleID).
The CT may write KWs (0510) first into a register (0507). At the same time, a lookup may performed under the address (#) of the PAE pertaining to the respective KW in the STATELUT (0505). If the status of the PAE is "not configured," the CT may receive an ACK (0509), otherwise a REJ. A simple protocol converter (0508) converts an ACK into a RDY in order to write the KW to the PA, and REJ is converted to notRDY to prevent writing to the PA.
It will be appreciated that relaying LOCK, RDY and KW to the PA and in the PA, like the acknowledgment of the status of the PAEs by the PA, may be pipelined, e.g., by running through registers.
The KW being configured at the moment may be rejected (REJ, 0708. Then, the difference between 0703 and 0704, may be calculated by a subtractor (0705. The difference may be stored in RelJmp, e.g., at the address of the KW rejected last and stored in 0704. The current value of 0703 may be stored in 0704. Then the value stored in 0702 at the address to which 0703 points may be added to 0703. This yields a relative jump. Control may be assumed by a state machine (0709). The state machine may be implemented according to the sequence described here. The address for RelJmp may be determined by the state machine 0709, e.g., using a multiplexer (0710). Depending on the operation, the address may be selected from 0703 or 0704. To address 0701 and 0702 efficiently and differently at the same time, 0702 may be physically separated from 0701, so that there are two separate memories which can be addressed separately.
0711 illustrates the functioning of the relative addressing. The address pointing at an entry in RelJmp may be added to the content of RelJmp, yielding the address of the next entry.
The FIFO may be implemented as a shift register. The depth of the memory is exactly equal to the number of cycles elapsing from sending a KW to the PA until receipt of the acknowledgment (RDY/ACK, 0806).
It will be appreciated that this procedure may result in a new linear sequence of rejected KWs in the FILMO. The FILMO may be implemented as a dual-ported RAM with separate read and write ports.
The KW (0902) to be written into the PA (0901) may be addressed by a read pointer (0909) in FILMO (0910). The address and flags (0902 a) of the PAE to be configured may be sent to the PA as a test. The KW having the address of the PAE to be configured may be written to a FIFO-like memory (0903). It will be appreciated that this FIFO may correspond to 0805. 0902 a may be transmitted to the PA in a pipeline. Access is analyzed and acknowledged in the PAE addressed. Acknowledgment (RDY/ACK) may also be sent back pipelined (0904). 0903 delays exactly for as many cycles as have elapsed from sending 0902 a to the PA until receipt of the acknowledgment (RDY/ACK, 0904).
0904 may be converted here by a simple protocol converter (0911) (i) into a write signal for the PA (RDY) in the case of ACK and (ii) into a write signal 0901 for the FILMO (WR) in the case of REJ.
It will be appreciated that a new linear sequence of rejected KWs may be stored in the FILMO. The FILMO may be implemented as a dual-ported RAM with separate read and write ports.
Then CT 1002b may send GRANT to CT 1003c and CT 1003d as an atom, e.g., without interruption by another GRANT. The ID chain may be split here and sent to two different CTs, so none of the receivers may be a common arbiter of all leaves. The SPLIT flag may be set; the receivers and all lower-level CTs can no longer cache the ID chain. CT 1003c and CT 1003d again send GRANT to low-level CTs 1004f and 1004g as an atom. The low-level CTs store the incoming GRANT directly in a suitable list, indicating the order of SubConf to be configured. This list may be designed to be separate, or it may be formed by performing the configuration directly by optionally entering the rejected KWs into FILMO.
Two example variants for the low-level CTs:
After receipt of a GRANT, the received GRANT may need to be executed before any other GRANT. For example, if GRANT A is received before GRANT B, then GRANT A may need to be 30 configured before GRANT B. This may also be needed if the SubConf of GRANT A needs to be loaded first while the SubConf of GRANT B would be cached in the low-level CT and could be started immediately. The order of incoming GRANTs may need to be maintained, because otherwise a deadlock can occur among the EnhSubConf.
In an alternative embodiment of the procedure described here,
CTs of the CTTREE may directly access configurations without including the higher-level CTs. The CTs may have a connection to any type of volatile memory, nonvolatile memory or bulk memory. For example, this memory may be an SRAM, DRAM, ROM, flash, CDROM, hard drive or server system, which may be connected via a network (WAN, LAN, Internet). It will be appreciated that a CT may directly access a memory for configuration data, bypassing the higher-level CTs. In such a case, the configuration may be synchronized within the CTTREE, including higher-level CTs, e.g., with EnhSubConf.
The example in
Likewise, GRANTs of 1230 and 1231 are also chronologically reversed in CTs 1204 and 1205. This also may result in a deadlock for the same reasons.
A corresponding KW may be structured as follows:
X address
Y address
Address for
X address
Y address
If MUX=1, then a lookup may be performed in 1409. If MUX=0, data may be relayed directly to 1414.
The next possible nodes (1 . . . 13) of the graph may be preloaded (prefetch), and preceding nodes and unused jumps may be deleted (delete). Within a loop, the nodes of the loop are not deleted (10, 11, 12), and corresponding nodes are removed only after termination. Nodes may be loaded only if they are not already present in the memory of the CT. Therefore, multiple processing of 11 need not result in multiple loading of 12 or 10; e.g., "delete 8, 9" is ignored in 11 if 8 and/or 9 has already been removed.
1601 may be called up. The KWs may be transmitted to 1605, 1606 and 1607. These elements operate as follows: Based on a lookup, the corresponding content of 1605 is linked again (1606) to the KWs. The KW is sent to the PA (1608) after the multiplexer 1413 (1607) selects whether the original KW is valid or whether a lookup has been performed.
One row of PAEs from the matrix of all PAEs of a VPU is shown as an example. The states in the cycles after cycle t are shown with a delay of one cycle each.
Although at first only a small portion of the PAEs is reconfigured or is waiting for reconfiguration, this area becomes larger over time, until all the PAEs have been reconfigured. The increase in size of this area (1702) shows that, due to the time delay in reconfiguration, more and more PAEs are waiting for reconfiguration. This may result in lost computing performance.
A broader bus system may be used between the CT (in particular, the memory of the CT) and the PAEs, providing enough lines to reconfigure several PAEs at the same time within one cycle.
Wave reconfiguration
Differential wave
Normal configuration
In A1-I1, a next configuration may be selected within the same SubConfs by a first trigger WCP. This configuration may use the same resources, alternative resources may be used that already prereserved and are not occupied by any other SubConfs except for that optionally generating the WCP. The configuration may be loaded by the CT (1801). In the example shown here, the configuration is not executed directly, but instead is loaded into one of several alternative registers (1802). By a second trigger WCT, one of the alternative registers is selected at the time of the required reconfiguration. This causes the configuration previously loaded on the basis of WCP to be executed.
It will be appreciated that a certain configuration may be determined and preloaded by WCP. The time of the actual change in function corresponding to the preloaded reconfiguration may be determined by WCT.
WCP and WCT may each be a vector, so that one of several configurations may be preloaded by WCT(v1). The configuration to be preloaded may be specified by the source of WCP. Accordingly, WCT(v2) may select one of several preloaded configurations. In this case, a number of configuration registers 1802 corresponding to the quantity of configurations selectable by v2 may be needed. The number of such registers may be fixedly predetermined so that v2 corresponds to the maximum number.
An example version having a register set 1803 with a plurality of configuration registers 1802 is shown in A1-I2. If the number of registers in 1803 is large enough that all possible following configurations can be preloaded directly, the WCP can be eliminated. In this case, only the time of the change of function as well as the change itself may need to be specified by WCT(v2).
A2-I1 illustrates an example WRC where the next configuration does not utilize the same resources or whose resources are not prereserved or are occupied by another SubConf in addition to that optionally generating the WCP(v1) The freedom from deadlock of the configuration may be guaranteed by the FILMO-compliant response and the configuration on WCP(v1). The CT also may start configurations by WCT(v2) (1806) through FILMO-compliant atomic response to the receipt of triggers (ReconfReq) characterizing a reconfiguration time.
In A2-I2, all the following SubConfs are either preloaded into configuration register 1803 with the first loading of a SubConf. Alternatively, if the number of configuration registers is not sufficient, the following SubConfs may be re-loaded by the CT, e.g., by way of running a WCP(v1).
The triggers (ReconfReq, 1809) which may determine a reconfiguration time and trigger the actual reconfiguration may first be isolated in time by way of a suitable prioritizer (1810). The triggers may then be sent as WCT(v2) to the PAEs so that exactly only one WCT(v2) is always active on one PAE at a time, and the order of incoming WCT(v2)s is always the same with all the PAEs involved.
In the case of A2-I1 and A2-I2, an additional trigger system may be used. In processing of WCT by CT 1801, i.e., in processing by 1810, there may be a considerable delay until relaying to PAE 1804. However, the timing of ChgPkt may need to be rigorously observed because otherwise the PAEs may process the following data incorrectly. Therefore, another trigger (1811, WCS=wave configuration stop) may be used. The WCS trigger only stops data processing of PAEs until the new configuration has been activated by arrival of the WCT. WCS is may be generated within the SubConf active at that time. The ReconfReq and WCS may be identical, because if ReconfReq is generated within the SubConf currently active, this signal may indicate that ChgPkt has been reached.
The CT may be linked to PAEs 2004 by a pipelined bus system, 2002 representing the pipeline stages. 2002 may include a register (2003 b) for the configuration data (CW) and another register (2003 a) having an integrated decoder and logic. Register 2003 a may decode the address transmitted in CW and sends a RDY signal to 2004 if the respective local PAE is addressed. Register 2003 a may send a RDY signal to the next step 2002, if the local PAE is not addressed. Accordingly, 2003 a may receive the acknowledgment (GNT), from 2002 or 2004, e.g., as a RDY/ACK. This results in a pipelined bus which transmits the CW from the CT to the addressed PAE and its acknowledgment back to the CT.
When WCT is active at 2004, pending CWs which are characterized with WAVE as part of the description may be configured in 2004. Here, GNT may acknowledged with ACK. If WCT is not active but CWs are pending for configuration, then GNT may not be acknowledged. The pipeline may be blocked until the configuration has been performed.
If 2005 is expecting a wave reconfiguration, characterized by an active WCT, and no CWs characterized with WAVE are already present at 2004, then 2004 may acknowledge with WAIT. This may put the PAE (2005) in a waiting, non-data-processing status until CWs characterized with WAVE have been configured in 2004. CWs that have not been transmitted with WAVE may be rejected with REJ during data processing.
It will be appreciated that optimization may be performed by special embodiments for particular applications. For example, incoming CWs characterized with WAVE and the associated reconfiguration may be stored temporarily by a register stage in 2004, preventing blocking of the pipeline if CWs sent by the CT are not accepted immediately by the addressed 2004. For further illustration, 2010 and 2011 may be used to indicate the direction of data processing. If data processing proceeds in direction 2010, a rapid wave reconfiguration of the PAEs is possible as follows. The CT may send CWs characterized with WAVE into the pipeline so that first the CWs of the most remote PAE are sent. If CWs cannot be configured immediately, the most remote pipeline stage (2002) may be blocked. Then, the CT may send CWs to the PAE which is then the most remote and so forth, until the data is ultimately sent to the next PAE.
As soon as ChkPkt runs through the PAEs, the new CWs may be configured in each cycle. It will be appreciated that this approach may also be efficient if ChgPkt is running simultaneously with transmission of CWs from the CT through the PAEs. In this case, the respective CW required for configuration may also be pending at the respective PAE in each cycle.
If data processing proceeds in the opposite direction (2011), the pipeline may optionally be configured from the PAE most remote from the CT to the PAE next to the CT. If ChgPkt does not take place simultaneously with data transmission of the CWs, the method may remain optimal. On occurrence of ChgPkt, the CWs may be transmitted immediately from the pipeline to 2004.
However, if ChgPkt appears simultaneously with CWs of wave reconfiguration, this may result in waiting cycles. For example, PAE B is to be configured on occurrence of ChgPkt in cycle n. CWs are pending and are configured in 2004. In cycle n+1, ChgPkt (and thus WCT) are pending at PAE C. However, in the best case, CWs of PAE C are transmitted only to 2002 of PAE B in this cycle, because in the preceding cycle, 2002 of PAE B was still occupied with its CW. Only in cycle n+2 are the CWs of PAE C in 2002 and can be configured. A waiting cycle has occurred in cycle n+1.
A data stream is to be calculated (2301) in an array (2302) of PAEs (2304-2308). A CT (2303) assigned to the array is responsible for its reconfiguration. 2304 is responsible for recognition of the end state of data processing which makes reconfiguration necessary. This recognition is signaled to the CT. 2306 marks the beginning and 2309 the end of a branch represented by 2307 a, 2307 b or 2307 ab. PAEs 2308 are not used. The various triggers are represented by 2309.
The following signals trigger may trigger a change of status:
There are three possible embodiments for 2511:
This principle was described generally PACT13. However, the example embodiment of the present invention may include extensions of the router and placer (2505).
The code (2501) may first be separated in a preprocessor (2502) into data flow code (2516) and ordinary sequential code (2517). The data flow code may be written in a special version of the respective programming language optimized for data flow. 2517 may be tested for parallelizable subalgorithms (2503) and the sequential subalgorithms may be sorted out (2518). Parallelizable subalgorithms may be placed and routed as macros on a provisional basis.
In an iterative procedure, the macros may be placed, routed and partitioned (2505) together with the data flow-optimized code (2513). Statistics (2506) evaluate the individual macros as well as their partitioning with regard to efficiency, with the reconfiguration time, and the complexity of the reconfiguration. Inefficient macros may be removed and sorted out as sequential code (2514).
The remaining parallel code (2515) may be compiled and assembled (2507) together with 2516. VPU object code may be output (2508). Statistics regarding the efficiency of the code generated as well as individual macros (including those removed with 2514) may be output (2509). It will be appreciated that the programmer thus receives important information regarding optimization of the speed of the program.
Each macro of the remaining sequential code may be tested for its complexity and requirements (2520). The suitable sequencer in each case may be selected from a database, which depends on the VPU architecture and the computer system (2519). The selected sequencer may output as VPU code (2521). A compiler (2521) may generate the assembler code of the respective macro for the respective sequencer selected by 2520. The assembler code may then be output (2511). 2510 and 2520 are closely linked together. Processing may proceed iteratively to find the most suitable sequencer having the fastest and minimal assembler code.
A linker (2522) may compile the assembler codes (2508, 2511, 2521) and generate executable object code (2523).
Definition of Terms
Configurable element: An element whose function may be determined by a configuration from a range of possible function. For example, a configurable element may be designed as a logical function unit, arithmetic function unit, memory, peripheral interface or bus system; this includes in particular elements of known technologies such as FPGA (e.g., CLBs), DPGAs, VPUs and other elements known under the term "reconfigurable computing." A configurable element may also be a complex combination of multiple different function units, e.g., an arithmetic unit with an integrated allocated bus system.
|Cited Patent
|Filing date
|Publication date
|Mar 20, 1931
|Jan 12, 1937
|Allis Chalmers Mfg Co
|May 23, 1963
|Mar 29, 1966
|Wolf Electric Tools Ltd
|Electrically driven equipment
|Nov 13, 1970
|Aug 1, 1972
|Marconi Co Ltd
|Fault location and reconfiguration in redundant data processors
|Nov 22, 1971
|Sep 11, 1973
|Bhs Bayerische Berg
|Solar and planetary gear system with load pressure compensation
|Jun 11, 1973
|Dec 17, 1974
|Texas Instruments Inc
|Power saving circuit for calculator system
|Jul 26, 1982
|Feb 5, 1985
|General Electric Company
|System for polynomial division self-testing of digital networks
|Apr 18, 1983
|Jan 21, 1986
|International Business Machines Corporation
|Parallel-shift error reconfiguration
|Aug 25, 1983
|May 27, 1986
|Nec Corporation
|Data-flow-type digital processing apparatus
|Oct 14, 1983
|May 5, 1987
|Tandem Computers Incorporated
|Multiprocessor multisystem communications network
|Dec 6, 1984
|Jul 21, 1987
|American Telephone & Telegraph Co., At&T Bell Lab.
|Queue administration method and apparatus
|Feb 27, 1985
|Nov 10, 1987
|Xilinx, Inc.
|Configurable logic element
|Sep 17, 1985
|Jan 19, 1988
|The Johns Hopkins University
|Memory-linked wavefront array processor
|Mar 10, 1983
|Apr 19, 1988
|Martin Marietta Corporation
|Geometric-arithmetic parallel processor
|Jul 11, 1984
|Aug 2, 1988
|Prime Computer, Inc.
|Data processing system and method having an improved arithmetic unit
|Nov 14, 1986
|Mar 7, 1989
|Princeton University
|Multinode reconfigurable pipeline computer
|May 20, 1987
|Jul 25, 1989
|Hewlett-Packard Company
|Daisy-chain bus system with truncation circuitry for failsoft bypass of defective sub-bus subsystem
|Dec 12, 1985
|Jul 25, 1989
|Itt Corporation
|Single instruction multiple data (SIMD) cellular array processing apparatus employing a common bus where a first number of bits manifest a first bus portion and a second number of bits manifest a second bus portion
|Sep 2, 1986
|Aug 22, 1989
|The Trustees Of Columbia University In The City Of New York
|Binary tree parallel processor
|Feb 19, 1988
|Sep 26, 1989
|Xilinx, Inc.
|Configurable electrical circuit having configurable logic elements and configurable interconnects
|Oct 27, 1987
|Jan 2, 1990
|Reconfigurable computing device
|Aug 19, 1988
|Feb 13, 1990
|General Electric Company
|Multiple function data processor
|Sep 2, 1986
|Mar 20, 1990
|General Electric Company
|Distributed processing system including reconfigurable elements
|Nov 18, 1988
|Oct 30, 1990
|E-Systems, Inc.
|Adaptive processing system having an array of individually configurable processing components
|Oct 14, 1988
|May 7, 1991
|Compaq Computer Corporation
|Dynamically configurable portable computer system
|Mar 7, 1990
|May 14, 1991
|Advanced Micro Devices, Inc.
|Multiple array high performance programmable logic device family
|Jan 30, 1990
|Jun 4, 1991
|Hughes Aircraft Company
|Data-flow multiprocessor architecture with three dimensional multistage interconnection network for efficient signal and data processing
|Oct 15, 1990
|Jun 11, 1991
|Intel Corporation
|Software programmable logic array utilizing "and" and "or" gates
|Sep 21, 1989
|Aug 27, 1991
|Siemens Aktiengesellschaft
|Circuit arrangement for telecommunications exchanges
|Dec 2, 1988
|Sep 10, 1991
|Mitsubishi Denki Kabushiki Kaisha
|Feb 22, 1991
|Nov 12, 1991
|The Secretary Of State For Defence In Her Britannic Magesty's Government Of The United Kingdom Of Great Britain And Northern Ireland
|Processing cell for fault tolerant arrays
|Jan 2, 1991
|Jan 14, 1992
|National Semiconductor Corp.
|Method for operating a multiple page programmable logic device
|May 22, 1989
|Apr 28, 1992
|Ge Fanuc Automation North America, Inc.
|Apparatus with reconfigurable counter includes memory for storing plurality of counter configuration files which respectively define plurality of predetermined counters
|Jun 4, 1990
|May 12, 1992
|Echelon Corporation
|Input/output section for an intelligent cell which provides sensing, bidirectional communications and control
|Oct 19, 1988
|May 19, 1992
|Sharp Kabushiki Kaisha
|Multistage data flow processor with instruction packet, fetch, storage transmission and address generation controlled by destination information
|Mar 5, 1990
|Jun 16, 1992
|Thinking Machines Corporation
|Parallel processor including a processor array with plural data transfer arrangements including (1) a global router and (2) a proximate-neighbor transfer system
|Feb 2, 1990
|Jun 30, 1992
|Isco, Inc.
|Pumping system
|Aug 8, 1991
|Jul 7, 1992
|Sgs-Thomson Microelectronics, Inc.
|Logic block for programmable logic devices
|Mar 29, 1990
|Aug 25, 1992
|Ge Fanuc Automation North America, Inc.
|Method for converting a programmable logic controller hardware configuration and corresponding control program for use on a first programmable logic controller to use on a second programmable logic controller
|Nov 2, 1990
|Sep 1, 1992
|Concurrent Logic, Inc.
|Programmable logic cell and array
|May 29, 1990
|Mar 9, 1993
|Wavetracer, Inc.
|Processor array with relocated operand physical address generator capable of data transfer to distant physical processor for each virtual processor while simulating dimensionally larger array processor
|May 2, 1989
|Apr 13, 1993
|Horst Robert W
|Cell structure for linear array wafer scale integration architecture with capability to open boundary i/o bus without neighbor acknowledgement
|Apr 10, 1992
|Apr 20, 1993
|Fuji Xerox Co., Ltd.
|Programmable fuzzy logic circuits
|Jan 7, 1992
|May 4, 1993
|Washington Research Foundation
|Field programmable gate array
|Aug 21, 1987
|Jul 6, 1993
|Compaq Computer Corp.
|Programmable logic system for filtering commands to a microprocessor
|Oct 30, 1989
|Aug 3, 1993
|Advanced Micro Devices, Inc.
|Programmable gate array with improved interconnect structure, input/output structure and configurable logic block
|Feb 9, 1990
|Sep 21, 1993
|Ewert Alfred P
|Parallel digital processor including lateral transfer buses with interrupt switches to form bus interconnection segments
|Sep 28, 1990
|Dec 28, 1993
|Intergraph Corporation
|High speed redundant rows and columns for semiconductor memories
|Aug 22, 1990
|Feb 15, 1994
|Tandem Computers Incorporated
|Memory system using linear array wafer scale integration architecture
|Sep 28, 1992
|Mar 15, 1994
|Taylor Made Golf Company, Inc.
|Vibration-damping device for a golf club
|Jan 16, 1991
|Apr 5, 1994
|Walker-Estes Corporation
|Mixed-resolution, N-dimensional object space method and apparatus
|Jan 29, 1991
|Apr 5, 1994
|Analogic Corporation
|Multibus sequential processor to perform in parallel a plurality of reconfigurable logic operations on a plurality of data sets
|Feb 16, 1988
|Apr 12, 1994
|Array Microsystems
|Pipelined combination and vector signal processor
|Feb 8, 1993
|Aug 9, 1994
|National Semiconductor Corporation
|Configuration features in a configurable logic array
|Jul 15, 1991
|Sep 13, 1994
|International Business Machines Corporation
|Self-parallelizing computer system and method
|May 20, 1993
|Sep 20, 1994
|Princeton Gamma Tech, Inc.
|Highly sensitive nuclear spectrometer apparatus and method
|Apr 23, 1991
|Oct 4, 1994
|Compaq Computer Corporation
|Interactive method for configuration of computer system and circuit boards with user specification of system resources and computer resolution of resource conflicts
|Dec 11, 1992
|Nov 1, 1994
|Gilson Kent L
|Integrated circuit computing device comprising a dynamically configurable gate array having a microprocessor and reconfigurable instruction execution means and method therefor
|Jun 7, 1994
|Jan 3, 1995
|Hughes Aircraft Company
|Array of one-bit processors each having only one bit of memory
|May 21, 1993
|Apr 25, 1995
|Deutsche Itt Industries Gmbh
|Wavefront array processor for blocking the issuance of first handshake signal (req) by the presence of second handshake signal (ack) which indicates the readyness of the receiving cell
|Jun 11, 1992
|May 23, 1995
|Flavors Technology Inc.
|Parallel processor cell computer system
|Sep 23, 1992
|May 30, 1995
|Martin Marietta Corporation
|Parallel data processor
|Jul 7, 1994
|Jun 6, 1995
|Advanced Micro Devices, Inc.
|Programmable gate array device having cascaded means for function definition
|Sep 18, 1992
|Jun 13, 1995
|Quickturn Design Systems, Inc.
|Method and apparatus for debugging reconfigurable emulation systems
|Apr 20, 1994
|Jun 20, 1995
|Xilinx, Inc.
|Programmable logic device which stores more than one configuration and means for switching configurations
|Feb 3, 1993
|Jun 27, 1995
|Flood; Mark A.
|Programmable controller with time periodic communication
|Apr 1, 1994
|Jul 4, 1995
|Xilinx, Inc.
|Programmable logic device including a parallel input device for loading memory cells
|Mar 9, 1993
|Aug 8, 1995
|Actel Corporation
|Logic module with configurable combinational and sequential blocks
|Sep 23, 1993
|Aug 8, 1995
|Massachusetts Institute Of Technology
|Communication system with redundant links and data bit time multiplexing
|Mar 9, 1994
|Aug 15, 1995
|The Trustees Of Princeton University
|Optimizing compiler for computers
|Jul 8, 1993
|Aug 22, 1995
|Altera Corporation
|PLD with selective inputs from local and global conductors
|Mar 16, 1994
|Sep 5, 1995
|Fuji Xerox Co., Ltd.
|Field-programmable gate array
|Dec 6, 1993
|Oct 3, 1995
|Intelligent Logic Systems, Inc.
|Hierarchically-structured programmable logic array and system for interconnecting logic elements in the logic array
|Aug 20, 1993
|Oct 10, 1995
|Actel Corporation
|Field programmable digital signal processing array integrated circuit
|Jan 14, 1993
|Nov 7, 1995
|France Telecom
|Multiprocessor system with cascaded modules combining processors through a programmable logic cell array
|Oct 18, 1994
|Dec 5, 1995
|Altera Corporation
|Programmable logic device having fast programmable logic array blocks and a central global interconnect array
|Feb 3, 1995
|Dec 5, 1995
|Sgs-Thomson Microelectronics Limited
|Programmable logic device with memory that can store routing data of logic data
|Feb 24, 1992
|Dec 12, 1995
|Siemens Aktiengesellschaft
|Programmable control system including a logic module and a method for programming
|Jul 10, 1992
|Dec 12, 1995
|Lsi Logic Corporation
|Method for 2-D affine transformation of images
|Oct 17, 1994
|Dec 12, 1995
|International Business Machines Corporation
|Dynamic multi-mode parallel processing array
|Mar 9, 1995
|Jan 9, 1996
|International Business Machines Corp.
|Learning machine synapse processor system apparatus
|Dec 15, 1994
|Jan 16, 1996
|Altera Corporation
|Programmable logic array with local and global conductors
|Jan 18, 1995
|Jan 16, 1996
|Advanced Micro Devices, Inc.
|Logic allocator for a programmable logic device
|Aug 3, 1992
|Feb 6, 1996
|Advanced Micro Devices, Inc.
|Flexible synchronous/asynchronous cell structure for a high density programmable logic device
|Mar 31, 1995
|Feb 13, 1996
|Xilinx, Inc.
|Configurable cellular array
|Jan 31, 1995
|Feb 20, 1996
|Motorola, Inc.
|Circuit and method of configuring a field programmable gate array
|Sep 28, 1993
|Mar 5, 1996
|Giga Operations Corporation
|Video processing module using a second programmable logic device which reconfigures a first programmable logic device for data transformation
|Jun 17, 1994
|Apr 9, 1996
|Fujitsu Limited
|Parallel data processing system using a plurality of processing elements to process data and a plurality of trays connected to some of the processing elements to store and transfer data
|Jun 21, 1995
|Apr 23, 1996
|Actel Corporation
|Reconfigurable programmable interconnect architecture
|Jan 5, 1994
|Apr 23, 1996
|Ricoh Co., Ltd.
|Programmable logic array and data processing unit using the same
|Sep 28, 1994
|Apr 30, 1996
|International Business Machines Corporation
|Method and system for dynamically reconfiguring a register file in a vector processor
|Jan 19, 1995
|May 28, 1996
|Xilinx, Inc.
|Timing driven method for laying out a user's circuit onto a programmable integrated circuit device
|Jun 22, 1994
|May 28, 1996
|Texas Instruments Incorporated
|Reconfigurable multi-processor operating in SIMD mode with one processor fetching instructions for use by remaining processors
|Aug 2, 1993
|Jun 25, 1996
|Hudson Soft Co. Ltd.
|Method and apparatus for processing interruption
|Oct 28, 1994
|Jun 25, 1996
|Dell Usa, L.P.
|Processor failure detection and recovery circuit in a dual processor computer system and method of operation thereof
|Jun 13, 1994
|Jul 2, 1996
|Advanced Hardware Architectures
|Adaptive data compression system with systolic string matching logic
|Jan 31, 1995
|Jul 2, 1996
|Texas Instruments Incorporated
|Field reconfigurable logic/memory array
|Dec 29, 1993
|Jul 9, 1996
|Kolchinsky; Alexander
|Virtual processor module including a reconfigurable programmable matrix
|Feb 14, 1995
|Jul 16, 1996
|Altera Corporation
|Programmable logic array device with grouped logic regions and three types of conductors
|Jul 11, 1994
|Jul 16, 1996
|Hitachi, Ltd.
|Programmable digital signal processor for performing a plurality of signal processings
|Jul 27, 1994
|Feb 4, 1997
|Metalithic Systems Incorporated
|Integrated circuit computing device comprising a dynamically configurable gate array having a microprocessor and reconfigurable instruction execution means and method therefor
|Aug 21, 1996
|Nov 17, 1998
|Chatter; Mukesh
|High performance self modifying on-the-fly alterable logic FPGA, architecture and method
|Jun 20, 1997
|Mar 23, 1999
|Mirage Technologies, Inc.
|Dynamically reconfigurable hardware system for real-time control of processes
|Jul 20, 1998
|Nov 2, 1999
|Xilinx, Inc.
|Method of time multiplexing a programmable logic device
|Jun 13, 1997
|Jan 4, 2000
|Xilinx, Inc.
|Field programmable gate array with dedicated computer bus interface and method for configuring both
|Mar 11, 1996
|Feb 1, 2000
|Altera Corporation
|Partially reconfigurable programmable logic device
|Feb 28, 1997
|Nov 21, 2000
|Actel Corporation
|Enhanced field programmable gate array
|Feb 16, 2000
|Nov 21, 2000
|Xilinx, Inc.
|Rapidly reconfigurable FPGA having a multiple region architecture with reconfiguration caches useable as data RAM
|Jun 25, 1997
|May 29, 2001
|Sun Microsystems, Inc.
|Apparatus for dynamically reconfiguring a processor
|Jun 23, 1999
|Jun 11, 2002
|Fujitsu Limited
|Chain-connected shift register and programmable logic circuit whose logic function is changeable in real time
|Jun 6, 2001
|Nov 12, 2002
|Xilinx Inc.
|Method of time multiplexing a programmable logic device
|Feb 7, 2000
|Dec 17, 2002
|Xilinx, Inc.
|Supporting multiple FPGA configuration modes using dedicated on-chip processor
|Jul 25, 2000
|Mar 9, 2004
|Sun Microsystems, Inc.
|Method and apparatus for executing standard functions in a computer system using a field programmable gate array
|Mar 28, 2002
|Apr 6, 2004
|Infineon Technologies Ag
|Reconfigurable gate array
|Jun 24, 1991
|Aug 31, 1993
|Xilinx, Inc.
|Configurable electrical circuit having configurable logic elements and configurable interconnects
|Ade et al., "Minimum Memory Buffers in DSP Applications," Electronics Letters, vol. 30, No. 6, Mar. 17, 1994, pp. 469-471.
|Alexandre F. Tenca et al., "A Variable Long-Precision Arithmetic Unit Design for Reconfigurable Coprocessor Architectures", University of California, Los Angeles, 1998, pp. 216-225.
|Andreas Koch et al, "Practical Experiences with the SPARXIL Co-Processor", 1998, IEEE, pp. 394-398.
|Arabi et al., "PLD Integrates Dedicated High-speed Data Buffering, Complex State Machine, and Fast Decode Array," conference record on WESCON '93, Sep. 28, 1993, pp. 432-436.
|Athanas, Peter et al., "An Adaptive Hardware Machine Architecture and Compiler for Dynamic Processor Reconfiguration", IEEE, Laboratory for Engineering Man/Machine Systems Division of Engineering, Box D, Brown University Providence, Rhode Island, 1991, pp. 397-400.
|Athanas, Peter et al., "IEEE Symposium on FPGAs For Custom Computing Machines,"IEEE Computer Society Press, Apr. 19-21, 1995, pp. i-vii, 1-222.
|Baumgarte, V., et al., PACT XPP "A Self-reconfigurable Data Processing Architecture," PACT Info. GMBH, Munchen Germany 2001.
|Becker, J. et al., "Parallelization in Co-compilation for Configurable Accelerators-a Host/accelerator Partitioning Compilation Method," proceedings of Asia and South Pacific Design Automation Conference, Yokohama, Japan, Feb. 10-13, 1998.
|Bittner, Ray A. Jr., "Wormhole Run-time Reconfiguration: Conceptualization and VLSI Design of a High Performance Computing System,"Dissertation, Jan. 23, 1997, pp. I-XX, I-415.
|Cadambi et al., "Managing Pipeline-reconfigurable FPGAs," ACM, 1998, pp. 55-64.
|Cardoso, J.M.P., "Compilation of Java(TM)Algorithms onto Reconfigurable Computing Systems with Exploitation of Operation-Level Parallelism," Ph.D. Thesis, Universidade Tecnica de Lisboa (UTL), Lisbon, Portugal Oct. 2000 (English Abstract included).
|Christian Siemers, "Rechenfabrik Ansaetze Fuer Extrem Parallele Prozessoren", Verlag Heinze Heise GmbH., Hannover, DE No. 15, Jul. 16, 2001, pp. 170-179.
|Ferrante J. et al., "The Program Dependence Graph and its Use in Optimization ACM Transactions on Programming Languages and Systems," Jul. 1987, USA, [online] Bd. 9, Nr., 3, pp. 319-349, XP002156651 ISSN: 0164-0935 ACM Digital Library.
|Fineberg, Samuel et al., "Experimental Analysis of a Mixed-Mode Parallel Architecture Using Bitonic Sequence Sorting", vol. 11. No. 3, Mar. 1991, pp. 239-251.
|Forstner, Peter "Wer Zuerst Kommt, Mahlt Zuerst!: Teil 3: Einsatzgebiete und Anwendungsbeispiele von FIFO-Speichem", Elektronik, Aug. 2000, pp. 104-109.
|Gokhale M. B. et al., "Automatic Allocation of Arrays to Memories in FPGA processors with Multiple Memory Banks", Field-Programmable Custom Computing Machines, 1999, IEEE, pp. 63-67.
|Hammes, Jeff et al., "Cameron: High Level Language Compilation for Reconfigurable Systems," Department of Computer Science, Colorado State University, Conference on Parallel Architectures and Compilation Techniques, Oct. 12-16, 1999.
|Hauck "The Roles of FPGA's in Reprogrammable Systems," IEEE, Apr. 1998, pp. 615-638.
|Hong Yu Xu et al., "Parallel QR Factorization on a Block Data Flow Architecture" Conference Proceeding Article, Mar. 1, 1992, pages 332-336 XPO10255276, page 333, Abstract 2.2, 2.3, 2.4-page 334.
|Hwang L. et al., "Min-cut Replication in Partitioned Networks" IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, [online] Bd. 14, Nr. 1, Jan. 1995, pp. 96-106, XP00053228 USA ISSN: 0278-0070 IEEE Xplore.
|Isshiki, Tsuyoshi et al., "Bit-Serial Pipeline Synthesis for Multi-FPGA Systems with C++Design Capture," 1996 IEEE, pp. 38-47.
|Jantsch, Axel et al., "A Case Study on Hardware/software Partitioning," Royal Institute of Technology, Kista, Sweden, Apr. 10, 1994 IEEE, pp. 111-118.
|John R. Hauser et al., "Garp: A MIPS Processor with a Reconfigurable Coprocessor", University of California, Berkeley, IEEE, 1997, pp. 12-21.
|Jorg Donandt, "Improving Response Time of Programmable Logic Controllers by Use of a Boolean Coprocessor", AEG Research Institute Berlin, IEEE, 1989, pages 4-167-4-169.
|K. Wada et al., "A Performance Evaluation of Tree-based Coherent Distributed Shared Memory" Proceedings of the Pacific RJM Conference on Communications, Comput and Signal Processing, Victoria, May 19-21 1993.
|Kung, "Deadlock Avoidance for Systolic Communication", 1988 Conference Proceedings of 15<SUP>th</SUP>Annual International Symposium on Computer Architecture, May 30, 1988, pp. 252-260.
|Lizy John et al., "A Dynamically Reconfigurable Interconnect for Array Processors", vol. 6, No. 1, Mar. 1998, IEEE, pp. 150-157.
|M. Morris Mano, "Digital Design," by Prentice Hall, Inc., Englewood Cliffs, New Jersey 07632, 1984, pp. 119-125, 154-161.
|M. Saleeba, "A Self-Contained Dynamically Reconfigurable Processor Architecture," Sixteenth Australian Computer Science Conference, ASCS-16, QLD, Australia, Feb., 1993.
|Markus Weinhardt et al., "Pipeline Vectorization for Reconfigurable Systems", 1999, IEEE, pp. 52-60.
|Maxfield, C. "Logic that Mutates While-U-Wait" EDN (Bur. Ed) (USA), EDN (European Edition), Nov. 7, 1996, Cahners Publishing, USA.
|Miller, Michael J. et al., "High-Speed FIFOs Contend with Widely Differing Data Rates: Dual-port RAM Buffer and Dual-pointer System Provide Rapid, High-density Data Storage and Reduce Overhead", Computer Design, Sep. 1, 1985, pp. 83-86.
|Mirsky, E. DeHon, "MATRIX: A Reconfigurable Computing Architecture with Configurable Instruction Distribution and Deployable Resources," Proceedings of the IEEE Symposium on FPGAs for Custom Computing Machines, 1996, pp. 157-1666.
|Myers, G. "Advances in Computer Architecture," Wiley-Interscience Publication, 2nd ed., John Wiley & Sons, Inc. pp. 463-494, 1978.
|Nilsson et al., "The Scalable Tree Protocol-A Cache Coherence Approaches for Large-Scale Multiprocessors" IEEE, pp. 498-506, Dec. 1992.
|Norman, Richard S., "Hyperchip Business Summary, The Opportunity," Jan. 31, 2000, pp., 1-3.
|Pedro Diniz et al., "Automatic Synthesis of Data Storage and Control Structures for FPGA-based Computing Engines", 2000, IEEE, pp. 91-100.
|Tau, Edward et al., "A First Generation DPGA Implementation,"FPD'95, pp. 138-143.
|TMS320C54X DSP: CPU and Peripherals, Texas Instruments, 1996, pp. 6-26 to 6-46.
|TMS320C54x DSP: Mnemonic Instruction Set, Texas Instruments, 1996, p. 4-64.
|Villasenor, John et al., "Configurable Computing Solutions for Automatic Target Recognition,"IEEE, 1996 pp. 70-79.
|Villasenor, John et al., "Configurable Computing,"Scientific American, vol. 276, No. 6, Jun. 1997, pp. 66-71.
|Weinhardt, M. "Compilation Methods for Structure-programmable Computers", dissertation, ISBN 3-89722-011-3, 1997.
|Weinhardt, Markus, "Ubersetzingsmethoden fur strukturprogrammierbare rechner," Dissertation for Doktors der Ingenieurwissenschaften der Universitat Karlsruhe: Jul. 1, 1997.
|Wittig et al., "OneChip: An FPGA Processor with Reconfigurable Logic" IEEE, 1996 pp. 126-135.
|Wu et al., "A New Cache Directory Scheme", IEEE, pp 466-472, Jun. 1996.
|XLINX, "Logic Cell Array Families: XC4000, XC4000A and XC4000H", product description, pages 2-7 to 2-15, Additional XC3000, XC31000 and XC3100A Data, pages 8-16 and 9-14.
|Citing Patent
|Filing date
|Publication date
|Jun 1, 2005
|Nov 11, 2008
|Microsoft Corporation
|Computing system and method that determines current configuration dependent on operand input from another configuration
|Sep 29, 2003
|Mar 10, 2009
|Nvidia Corporation
|System and method using embedded microprocessor as a node in an adaptable computing machine
|Oct 9, 2001
|Sep 22, 2009
|Nvidia Corp.
|Predictive resource allocation in computing systems
|Jan 10, 2003
|Nov 10, 2009
|Nvidia Corporation
|Method and system for providing an excitation-pattern based audio coding scheme
|Jun 12, 2003
|Nov 17, 2009
|Nvidia Corporation
|Method and system for reducing the time-to-market concerns for embedded system design
|Nov 22, 2003
|Nov 24, 2009
|Nvidia Corporation
|Input/output controller node in an adaptable computing environment
|Jul 18, 2002
|Jan 5, 2010
|Nvidia Corporation
|Consumer product distribution in the embedded system market
|Jun 1, 2005
|Apr 27, 2010
|Microsoft Corporation
|Conditional execution via content addressable memory and parallel computing execution model
|Jun 1, 2005
|Sep 7, 2010
|Microsoft Corporation
|Content addressable memory architecture
|Nov 1, 2002
|Sep 21, 2010
|Nvidia Corporation
|Secure storage of program code for an embedded system
|Jun 7, 2007
|May 17, 2011
|Nvidia Corporation
|Extrapolation texture filtering for nonresident mipmaps
|Jun 7, 2007
|May 24, 2011
|Nvidia Corporation
|Extrapolation of nonresident mipmap data using resident mipmap data
|Jun 21, 2006
|Jul 12, 2011
|Nvidia Corporation
|Method for estimating cost when placing operations within a modulo scheduler when scheduling for processors with a large number of function units or reconfigurable data paths
|Apr 17, 2007
|Jul 26, 2011
|Nvidia Corporation
|Automatic quality testing of multimedia rendering by software drivers
|Dec 10, 2007
|Aug 16, 2011
|Nvidia Corporation
|Methods and systems for reusing memory addresses in a graphics system
|May 9, 2005
|Sep 13, 2011
|Nvidia Corporation
|Processor for video data
|May 9, 2005
|Mar 6, 2012
|Nvidia Corporation
|Processor for video data encoding/decoding
|Apr 10, 2007
|May 1, 2012
|Nvidia Corporation
|Graphics processing unit stiffening frame
|Sep 9, 2004
|Oct 23, 2012
|Nvidia Corporation
|Internal synchronization control for adaptive integrated circuitry
|Apr 18, 2007
|Oct 29, 2013
|Nvidia Corporation
|Method and system for upgrading software in a computing device
|Jun 4, 2007
|May 13, 2014
|Nvidia Corporation
|Deadlock avoidance skid buffer
|Feb 13, 2003
|Feb 3, 2015
|Nvidia Corporation
|Arithmetic node including general digital signal processing functions for an adaptive computing machine
|Dec 25, 2009
|Apr 28, 2015
|Nec Corporation
|Indirect designation of physical configuration number as logical configuration number based on correlation information, within parallel computing
|Oct 9, 2001
|Apr 10, 2003
|Ian Hirschsohn
|Predictive resource allocation in computing systems
|Jul 18, 2002
|Jul 8, 2004
|Rubin Owen Robert
|Consumer product distribution in the embedded system market
|Sep 29, 2003
|Jul 22, 2004
|Quicksilver Technology, Inc.
|System and method using embedded microprocessor as a node in an adaptable computing machine
|Nov 22, 2003
|Sep 16, 2004
|Quicksilver Technology, Inc.
|Input/output controller node in an adaptable computing environment
|Sep 9, 2004
|Feb 17, 2005
|Quicksilver Technology, Inc.
|Internal synchronization control for adaptive integrated circuitry
|Feb 13, 2003
|Jan 19, 2006
|Quicksilver Technology, Inc.
|Arithmetic node including general digital signal processing functions for an adaptive computing machine
|Mar 9, 2005
|Apr 13, 2006
|Uli Electronics Inc.
|Sound effect processing circuit
|Jun 1, 2005
|Dec 7, 2006
|Microsoft Corporation
|Execution model for parallel computing
|Jun 1, 2005
|Jan 11, 2007
|Microsoft Corporation
|Content addressable memory architecture
|Jun 21, 2006
|Jan 11, 2007
|Quicksilver Technology, Inc.
|Method for estimating cost when placing operations within a modulo scheduler when scheduling for processors with a large number of function units or reconfigurable data paths
|Jul 9, 2004
|Feb 15, 2007
|Tatsuo Hiramatsu
|Processing device with reconfigurable circuit, integrated circuit device and processing method using these devices
|Nov 9, 2006
|May 15, 2008
|Scheuermann W James
|Processor for video data
|May 9, 2005
|Jun 5, 2008
|Quicksilver Technology, Inc.
|Processor for video data encoding/decoding
|Jun 7, 2007
|Dec 11, 2008
|Newhall Jr William P
|Extrapolation of nonresident mipmap data using resident mipmap data
|Dec 25, 2009
|Dec 29, 2011
|Takeshi Inuo
|Parallel computing device, information processing system, parallel computing method, and information processing device
|U.S. Classification
|International Classification
|Cooperative Classification
|European Classification
|Jun 6, 2003
Owner name: PACT XPP TECHNOLOGIES AG, GERMANY
Free format text: CHANGE OF NAME;ASSIGNOR:PACT GMBH;REEL/FRAME:014137/0154
Effective date: 20020827
|Jan 2, 2007
|Certificate of correction
|Jul 22, 2009
|Fee payment
Year of fee payment: 4
|Feb 2, 2010
Owner name: RICHTER, THOMAS, MR.,GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PACT XPP TECHNOLOGIES AG;REEL/FRAME:023882/0403
Effective date: 20090626
Owner name: KRASS, MAREN, MS.,SWITZERLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PACT XPP TECHNOLOGIES AG;REEL/FRAME:023882/0403
Effective date: 20090626
Owner name: RICHTER, THOMAS, MR., GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PACT XPP TECHNOLOGIES AG;REEL/FRAME:023882/0403
Effective date: 20090626
Owner name: KRASS, MAREN, MS., SWITZERLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PACT XPP TECHNOLOGIES AG;REEL/FRAME:023882/0403
Effective date: 20090626
|Aug 16, 2010
Owner name: PACT INFORMATIONSTECHNOLOGIE AG, GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VORBACH, MARTIN;BAUMGARTE, VOLKER;EHLERS, GERD;AND OTHERS;SIGNING DATES FROM 20030121 TO 20030212;REEL/FRAME:024838/0827
Owner name: PACT XPP TECHNOLOGIES AG, GERMANY
Free format text: CHANGE OF NAME;ASSIGNOR:PACT INFORMATIONSTECHNOLOGIE AG;REEL/FRAME:024838/0848
Effective date: 20020625
|Jul 24, 2013
|Fee payment
Year of fee payment: 8
|Feb 8, 2014
Owner name: PACT XPP TECHNOLOGIES AG, GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RICHTER, THOMAS;KRASS, MAREN;REEL/FRAME:032225/0089
Effective date: 20140117
|Aug 10, 2017
|Fee payment
Year of fee payment: 12