WO2003017095A2 - Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen - Google Patents

Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen Download PDF

Info

Publication number
WO2003017095A2
WO2003017095A2 PCT/EP2002/010065 EP0210065W WO03017095A2 WO 2003017095 A2 WO2003017095 A2 WO 2003017095A2 EP 0210065 W EP0210065 W EP 0210065W WO 03017095 A2 WO03017095 A2 WO 03017095A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
memory
configuration
configurations
memories
Prior art date
Application number
PCT/EP2002/010065
Other languages
English (en)
French (fr)
Other versions
WO2003017095A3 (de
Inventor
Martin Vorbach
Frank May
Armin NÜCKEL
Original Assignee
Pact Xpp Technologies Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/967,847 external-priority patent/US7210129B2/en
Priority claimed from PCT/EP2002/002398 external-priority patent/WO2002071248A2/de
Priority to EP02774585A priority Critical patent/EP1493084A2/de
Priority to CA002458199A priority patent/CA2458199A1/en
Priority to AU2002340879A priority patent/AU2002340879A1/en
Priority to US10/486,771 priority patent/US7996827B2/en
Priority to JP2003521938A priority patent/JP2005508029A/ja
Application filed by Pact Xpp Technologies Ag filed Critical Pact Xpp Technologies Ag
Publication of WO2003017095A2 publication Critical patent/WO2003017095A2/de
Priority to US10/508,559 priority patent/US20060075211A1/en
Priority to PCT/DE2003/000942 priority patent/WO2003081454A2/de
Priority to AU2003223892A priority patent/AU2003223892A1/en
Priority to EP03720231A priority patent/EP1518186A2/de
Priority to AU2003286131A priority patent/AU2003286131A1/en
Priority to PCT/EP2003/008081 priority patent/WO2004021176A2/de
Priority to EP03776856.1A priority patent/EP1537501B1/de
Priority to US10/523,764 priority patent/US8156284B2/en
Priority to AU2003260323A priority patent/AU2003260323A1/en
Priority to JP2005506110A priority patent/JP2005535055A/ja
Priority to EP03784053A priority patent/EP1535190B1/de
Priority to PCT/EP2003/008080 priority patent/WO2004015568A2/en
Publication of WO2003017095A3 publication Critical patent/WO2003017095A3/de
Priority to US12/570,943 priority patent/US8914590B2/en
Priority to US12/621,860 priority patent/US8281265B2/en
Priority to US12/729,090 priority patent/US20100174868A1/en
Priority to US12/729,932 priority patent/US20110161977A1/en
Priority to US12/947,167 priority patent/US20110238948A1/en
Priority to US13/177,820 priority patent/US8869121B2/en
Priority to US14/162,704 priority patent/US20140143509A1/en
Priority to US14/540,782 priority patent/US20150074352A1/en
Priority to US14/923,702 priority patent/US10579584B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/447—Target code generation

Definitions

  • the present invention relates to the preamble claimed.
  • the present invention addresses the question of how reconfigurable architectures can be optimally used and, in particular, how instructions in a given high-level language can be optimally executed in reconfigurable architectures.
  • compilers In order to implement instructions for handling data (programs) written in so-called high-level languages in a respective architecture used for data handling, so-called compilers are known which translate the high-level language instructions into instructions which are better adapted to the architecture used. Compilers that particularly support highly parallel architectures are accordingly parallelizing compilers.
  • Prior art parallelizing compilers typically use special constructs such as semaphores and / or other methods of synchronization.
  • Technology-specific processes are typically used.
  • Known methods are not suitable for combining functionally specified architectures with the associated time behavior and imperatively specified algorithms. Therefore, the methods used only provide satisfactory results in special cases
  • Compilers for reconfigurable architectures in particular for reconfigurable processors, usually use macros that have been created specifically for the specific reconfigurable hardware, with hardware description languages such as Verilog, VHDL or System-C being mostly used for the creation of the macros. These macros are then called from an ordinary high-level language (eg C, C ++) from the program flow (instantiated).
  • an ordinary high-level language eg C, C ++
  • Compilers for parallel computers which map program parts onto several processors on a coarse-granular structure, mostly based on complete functions or threads.
  • vectorizing compilers which support extensive linear data processing, e.g. Convert calculations of large expressions into a vectorized form and thus enable calculation on superscalar processors and vector processors (e.g. Pentium, Cray).
  • VPUs basically consist of a multidimensional homogeneous or inhomogeneous, flat or hierarchical arrangement (PA) of cells (PAEs) that perform any functions, i.b. can perform logical and / or arithmetic functions and / or storage functions and / or network functions.
  • a charging unit (CT) is typically assigned to the PAEs, which determines the function of the PAEs through configuration and, if necessary, reconfiguration.
  • the method is based on an abstract parallel machine model which, in addition to the finite automaton, also integrates imperative problem specifications and enables an efficient algorithmic derivation of an implementation on different technologies.
  • Vectorizing compilers build largely linear code that is tailored to special vector computers or highly pipelined processors. These compilers were originally available for vector computers such as CRAY. Due to the long pipeline structure, modern processors like Pentium require similar processes. Since the individual calculation steps are vectorized (pipe- lined), the code is much more efficient. However, the conditional jump poses problems for the pipeline. Therefore, a jump prediction makes sense that assumes a jump target. If the assumption is incorrect, the entire processing pipeline must be deleted. In other words, every jump is problematic for these compilers, parallel processing in the actual sense is not given. Jump predictions and similar mechanisms require a considerable amount of additional hardware.
  • Coarse-grained parallel compilers hardly exist in the actual sense, the parallelism is typically marked and managed by the programmer or the operating system, for example with MMP computer systems such as different IBM architectures, ASCI Red, etc. mostly carried out at thread level.
  • a thread is a largely independent program block or even another program. Coarsely granular threads are therefore easy to parallelize. Synchronization and data consistency must be ensured by the programmer or the operating system. This is difficult to program and requires a significant proportion of the computing power of a parallel computer.
  • this rough parallelization means that only a fraction of the parallelism that is actually possible can actually be used.
  • Fine-granular parallel (eg VLIW) compilers try to map the parallelism in fine gray in VLIW arithmetic units, which can perform several arithmetic operations in parallel in one cycle but have a common register set.
  • This limited register set is a major problem because it has to provide the data for all computing operations.
  • data dependencies and inconsistent read / write operations make parallelization difficult.
  • Reconfigurable processors have a large number of independent arithmetic units, which are typically arranged in one field. These are typically not linked together by a common register set, but rather by Bifsse. On the one hand, this makes it easy to set up vector arithmetic units, and on the other hand, simple parallel operations can also be carried out. Contrary to conventional register concepts, data dependencies are resolved by the bus connections.
  • the object of the present invention is to provide something new for commercial use.
  • a significant advantage is that the compiler does not need to be mapped to a fixed hardware structure, but the hardware structure can be configured with the erf indungswashen- process so that it is optimally suited for imaging the j ehyroid compiled ⁇ algorithm.
  • the finite state machine is used as the basis for processing practically every methodology for specifying algorithms.
  • the structure of a finite automaton is shown in FIG. 1 displayed.
  • a simple finite state machine breaks down into a combinatorial network and a register stage for the temporary storage of data between the individual data processing cycles.
  • a finite automaton performs a number of purely combinatorial (e.g. logical and / or arithmetic) data manipulations in order to then achieve a stable state, which is represented in a register (set). Based on this stable state, a decision is made as to which next state is to be reached in the next processing step and thus also which combinatorial data manipulations are to be carried out in the next step.
  • purely combinatorial e.g. logical and / or arithmetic
  • a processor or sequencer represents a finite state machine.
  • data can be subtracted.
  • the result is saved.
  • a jump can be made based on the result of the subtraction, which, depending on the sign of the result, leads to a further processing.
  • the finite state machine enables complex algorithms to be mapped to any sequential machine, as shown in FIG. 2.
  • the complex finite automaton shown consists of a complex combinatorial network, a memory for storing data and an address generator for addressing the data in the memory.
  • any sequential program can be interpreted fundamentally as a finite automaton, but mostly a very large combinatorial network is created.
  • the combinatorial operations are therefore given in a sequence of individual, simple, fixed instructions Operations (OpCodes) broken down into internal CPU registers.
  • This decomposition creates states for controlling the combinatorial operation broken down into a sequence, but these are not present per se within the original combinatorial operation or are not required. Therefore, the states of a Neumann machine to be processed must be fundamentally distinguished from the algorithmic states of a combinatorial network, i.e. the registers of finite automata.
  • VPU technology (as essentially defined by some or all of PACT01, PACT02, PACT03, PACT04, PACT05, PACT08, PACT10, PACT13, PACT17, PACT18, PACT22, PACT24) is defined by reference fully integrated), in contrast to the rigid OpCodes of CPUs, enables complex instructions to be compiled in according to an algorithm to be mapped, as in flexible configurations.
  • the compiler furthermore generates the finite automaton preferably from the imperative source text in such a way that it is particularly well adapted to the respective PAE matrix, that is to say operations are provided which contain the typically coarse-grained logic circuits (ALUs, etc.) and possibly also fine-grained ones Use elements (FPGA cells in the VPU, state machines etc.) particularly efficiently.
  • the compiler-generated finite state machine is then broken down into configurations.
  • Processing interpreting the finite automaton takes place on a VPU in such a way that the generated configurations are successively mapped onto the PAE matrix and the work data and / or states that are to be transferred between the configurations are stored in memory
  • the method or the corresponding architecture known from PACT04 can be used.
  • This memory is determined or provided by the compiler.It represents a configuration, a plurality of instructions, and a configuration simultaneously determines the mode of operation of the PAE matrix for a large number of cycles, during these cycles
  • a large amount of data is processed in the matrix and comes from a VPU external source and / or an internal memory and is written to an external source and / or an internal memory, the internal memories replacing the register set of a CPU according to the prior art Technology such that, for example, a register major ch represents a memory, not one data word per register being saved, but an entire data record per memory.
  • a significant difference from compilers that parallelize on an instruction basis is that the method configures and reconfigures the PAE matrix in such a way that a configured sequence of combinatorial networks is emulated on a VPU, while conventional compilers load sequences of instructions (OpCodes). combine, one Instruction can be viewed as a combinatorial network.
  • An instruction or a sequence of instructions can be mapped onto a combinatorial network using the compiler method described.
  • Figure 3a shows a combinatorial network with the associated variables.
  • address generators For addressing, reading the operands and storing the results, address generators can now be synchronized with the combinatorial network of the assignment. Corresponding new addresses for operands and results are generated with each processed variable (FIG. 3c).
  • the type of address generator is arbitrary and depends on the addressing scheme of the compiled application. Common, combined or completely independent address generators can be implemented for operands and results.
  • a plurality of data are processed within a specific configuration of the PAEs.
  • the compiler is therefore preferably designed for the simple FIFO mode which is possible in many if not most applications and which is at least applicable to the data memories which, within this description, are used for storing data and data processing states (as a replacement for an ordinary register set, as it were) conventional CPUs).
  • memories are used to temporarily store variables between configurations.
  • a configuration is similar to an instruction of a normal processor and the memories (in particular a plurality) are comparable to the register set of a normal processor.
  • WHILE xl ⁇ 10 DO xl: xl + 1;
  • the figure generates an additional PAE for processing the comparison.
  • the comparison result is represented by a status signal (see trigger in PACT08), which is generated by the the instruction processing PAEs and the address generators are evaluated.
  • WHILE generally and obviously other instructions such as IF; CASE can be implemented
  • a status is generated which can be made available to the subsequent data processing (DE 197 04 728.9) and / or to the CT or a local Charging control (DE 196 54 846.2) can be sent, which derives information about the further program flow and possibly upcoming reconfigurations.
  • each program is mapped into a system that is structured as follows:
  • Optional address generator (s) for controlling the memories according to 1 and 2.
  • states are usually represented by status signals (e.g. trigger in PACT08) and / or handshakes (e.g. RDY / ACK in PACT02).
  • states can be determined by any signals, Signal bundles and / or registers are shown.
  • the compilation method disclosed can also be applied to such, although essential parts of the description preferably focus on the VPU.
  • Irrelevant states are only necessary locally and / or temporally locally and therefore do not have to be saved.
  • a sequential divider is created, for example, by mapping a division command onto hardware that only supports sequential division. This creates a state that identifies the calculation step within the division. This state is irrelevant since the algorithm only requires the result (ie the division performed). In this case, only the result and the time information (i.e. availability) are required.
  • the compiler differentiates detects such relevant and irrelevant states preferably from each other.
  • the time information is available, for example, in the VPU technology according to PACT01, 02, 13 through the RDY / ACK handshake.
  • the handshake also does not represent a relevant state, since it only signals the validity of the data, which in turn reduces the remaining relevant information to the existence of valid data.
  • the implicit time information of sequential languages is mapped in a handshake protocol in such a way that the handshake protocol (RDY / ACK protocol) transmits the time information and in particular guarantees the sequence of the assignments.
  • Bus transfers are broken down into internal and external transfers, btl) External read accesses (load operation) are separated, in one possible version also preferably translated into a separate configuration.
  • the data is transferred from an external memory to an internal one.
  • External write accesses (store operation) are separated, in a preferred possible embodiment also translated into a separate configuration.
  • the data is transferred from an internal memory to an external one.
  • btl, bt2, bt3 - i.e. the loading of the data (Load), the processing of the data (data processing and bt2) and the writing of the data (bt3) - can be translated into different configurations and, if necessary, into one run at different times.
  • example # dload Loads the data from external (memory, peripherals, etc.) and writes it to internal memory. Internal memories are marked with r # and the name of the original variable.
  • exampletprocess Corresponds to the actual data processing. This reads the data from internal operands and writes the results back to internal memory.
  • example # dstore writes the results from the internal memory to external (memory, peripherals, etc.).
  • a procedure can be used that reloads the operands or calls the results externally if necessary using subroutine calls.
  • the states of the FIFOs can be queried: 'empty' if the FIFO is empty, and 'fill' if the FIFO is full.
  • the program flow reacts according to the conditions. It should be noted that certain variables (e.g. ai, bi, xi) are globally defined. To optimize performance, a scheduler can already execute the configurations example # dloada, example # dloadb before calling example # process, so that data is already preloaded.
  • Example # dstore (n) can also be called after scheduling example # process to empty r # x.
  • the subroutine calls and the management of the global variables are comparatively complex for reconfigurable architectures. Therefore, in a preferred embodiment, the subsequent optimization can be carried out, in which all configurations run largely independently and terminate after complete processing (terminate). Since the data b [j] are required several times, example # dloadb must be repeated several times. For example, two alternatives are presented:
  • example # dloadb terminates after each run and is reconfigured by exampletprocess for each restart.
  • configurations can also be scheduled as soon as they can no longer carry out their task temporarily.
  • the corresponding configuration is removed from the reconfigurable module, but remains in the scheduler.
  • the 'reenter' command is used for this below.
  • the relevant variables are saved before scheduling and restored during repeated configuration:
  • More complex high-level language functions such as loops, are typically implemented using macros.
  • the macros are specified by the compiler and instantiated at translation time. (see Figure 4).
  • the macros are either made up of simple language constructs of the high-level language or at assembly level. Macros can be parameterized to a simple adaptation to the beschie- surrounded algorithm allows t s, (see FIG. 5, 0502).
  • the macros are also to be integrated here.
  • Imaging an algorithm in a combinatorial network can result in undelayed feedback that oscillates in an uncontrolled manner.
  • instantaneous feedback can be determined by graph analysis of the resulting combinatorial network.
  • Registers for decoupling are then inserted into the data paths in which there is an undelayed feedback.
  • the compiler can thus manage register or storage means.
  • the compilation described does not execute an OpCode sequentially, but rather complex configurations. While an opcode typically processes a data word in CPUs, a plurality of data words (a data packet) are processed by one configuration in VPU technology. This increases the efficiency of the reconfigurable architecture through a better relationship between reconfiguration effort and data processing.
  • VPU technology a memory is used instead of a register, since it is not data words but data packets that are processed between the configurations.
  • This memory can be designed as a random access memory, stack, FIFO or any other memory architecture, with a FIFO typically giving the best and easiest to implement option.
  • Data is now processed by the PAE matrix in accordance with the configured algorithm and saved in one or more memories.
  • the PAE matrix is reconfigured and the new configuration takes the intermediate results from the memory (s) and continues the execution of the program.
  • new data from external memories and / or the peripherals can also be included in the calculation, and results can also be written to external memories and / or the peripherals.
  • the typical course of data processing is the reading out of internal RAMs, the processing of the data in the matrix and the writing of data into the internal memories, and any external sources or destinations for data transfers in addition to or instead of the internal memories for data processing can be used.
  • the information when and / or how to sequence, i.e. Which next configuration is to be configured can be represented by various information that can be used individually or in combination.
  • the following strategies for deriving the information alone and / or in combination or alternatively make sense: a) defined by the compiler at translation time; b) defined by the event network (trigger, DE 197 04 728.9), the event network being able to represent internal and / or external states; c) by the filling level of the storage
  • a simple example is intended to show a distinguishing feature for locally relevant states: a) A branching of the type "if () then ... eise " fits completely into a single configuration, ie both data paths (branches) are together completely within the configuration displayed. The state that results from the comparison is relevant, but local, since it is no longer required in the subsequent configurations. b) The same branch is too large to fit completely in a single configuration. Several configurations are necessary to map the complete data paths. In this case, the status is globally relevant and must be saved and assigned to the respective data, since the following configurations are used for further processing. the current state of the comparison.
  • operating systems use task schedulers to manage multiple tasks (tasks) to provide multitasking.
  • Task schedulers cancel tasks at a certain point in time, start other tasks and return after processing to continue processing the canceled task. If it is ensured that a configuration - which here can correspond to the processing of a task - only after complete processing - i.e. if all data and states to be processed within this configuration cycle are saved - terminated, locally relevant states can remain unsaved.
  • This procedure ie the complete processing of a configuration and the subsequent task switch, is the preferred method for the operation of reconfigurable processors and essentially corresponds to the sequence in a normal processor, which also processes the instructions currently being processed and then changes the task.
  • a particularly short reaction to a task change request is required, for example in real-time applications. It can make sense to cancel configurations before they are completely processed. If the task scheduler cancels configurations before they are fully processed, local states and / or data must be saved. This is also advantageous if the processing time of a configuration cannot be predicted. In connection with the known halting problem and the risk that a configuration (e.g. due to an error) This does not seem to be a good idea at all, in order to prevent the entire system from being deadlocked. Therefore, taking into account task changes, relevant states are also to be regarded as a surface that are necessary for a task change and a new correct start of data processing.
  • the memory for results and possibly also the memory for the operands must be saved and restored at a later point in time, i.e. when the task is returned. This can be done comparable to the PUSH / POP commands and methods according to the prior art.
  • the state of the data processing must also be saved, i.e. the pointer to the last operands that were completely processed. Special reference is made to PACT18.
  • a particularly preferred variant for managing relevant data is provided by the context switch described below.
  • changing tasks and / or when executing configurations and changing them see, for example, patent application DE 102 06 653.1, which is fully incorporated for disclosure purposes
  • it may be necessary to store data or states that are typically not stored together with the working data are stored, since they merely mark a final value, for example, assure for subsequent 'configuration.
  • the context switch which is preferably implemented according to the invention is carried out in such a way that a first configuration is removed and the data to be backed up remain in corresponding memories (REG) (memories, registers, counters, etc.).
  • REG memories, registers, counters, etc.
  • a second configuration can then be loaded, this connects the REG with one or more global memories in a suitable manner and in a defined sequence.
  • the configuration can use address generators to access the global memory (s). It is therefore not necessary to have each individual memory location determined in advance by the compiler and / or to access REG configured as a memory.
  • the contents of the REG are written into the global memory in a defined order, the respective addresses being specified by address generators.
  • the address generator generates the addresses for the global memory (s) in such a way that the described memory areas (PUSHAREA) of the remote first configuration can be clearly assigned.
  • the configuration corresponds to a PUSH of ordinary processors.
  • a third configuration is started beforehand, which connects the REG of the first configuration with one another in a defined sequence.
  • the configuration can in turn use address generators, for example, to access the global memory (s) and / or to access REGs configured as memories.
  • An address generator preferably generates addresses in such a way that correct access to the PUSHAREA assigned to the first configuration takes place.
  • the generated addresses and the configured sequence of the REG are such that the data of the REG are written from the memories into the REG in the original order.
  • the configuration corresponds to a POP of ordinary processors.
  • a context switch preferably such carried out that work by loading particular configurations which operate like PUSH / POP known processor architectures exchanged data to be backed with a 'global store.
  • This data exchange via global storage using push / pop exchange configurations is considered to be particularly relevant.
  • the function should be illustrated in an example:
  • a function adds 2 rows of numbers, the length of the rows was not started at translation time, but only at runtime.
  • a, b, x are at this time in accordance with the invention in memories, i and possibly. length must, however, be saved.
  • the configuration example is terminated, the register contents are retained and a configuration push is started, which reads i and length from the registers and writes them to a memory.
  • Control structures are separated from algorithmic structures by the described translation process. For example, a loop breaks down into a body (WHILE) and an algorithmic structure (instructions).
  • WHILE body
  • instructions instructions
  • the algorithmic structures can now preferably be optionally optimized by an additional tool connected after the separation.
  • a downstream algebra software can optimize and minimize the programmed algorithms.
  • Such tools are e.g. known as AXIOM, MARBLE, etc. By minimizing, a faster execution of the algorithm and / or a significantly reduced space requirement can be achieved.
  • Line 4 may only be calculated if i is correctly defined, that is after line 1 has been processed.
  • Line 2 must also only be defined after i has been correctly defined (ie after processing) from line 1) are processed.
  • Line 3 requires the results from line 2 (variable a) and can therefore only be calculated after it has been correctly defined. This results in a data dependency but no special conditions.
  • VEC means that everyone through '; 'Separate expression is processed one after the other, whereby the expressions within the curly brackets can in principle be pipelined. Preferably, all calculations must be carried out and completed at the end of VEC ⁇ so that the data processing can continue after VEC.
  • Line 4 gives a simple vector:
  • VEC ⁇ j i * i ⁇
  • PAR means that every expression separated by ' ⁇ .. ⁇ ' can be processed at the same time. Preferably, all calculations must be carried out and completed at the end of PAR ⁇ so that the data processing continues after PAR.
  • Example B shows a real state.
  • line 6 can only be executed after the calculation of line 2 and line 3. Alternatively, rows 4 and 6 are calculated. So the state of row 3 is relevant for further data processing (relevant state).
  • Conditional states can be expressed in a transformation by IF:
  • Line 3 may only be executed after the loop is terminated. So there are relevant conditions for conditional jumps.
  • a first transformation of the loop results in:
  • Lines 3 and 4 can be calculated in parallel since line 4 does not depend on the result of line 3: '
  • Line 5 results in a vector with the generated PAR, since it is only allowed to jump back into the loop after the values have been fully calculated (there is a time dependency here).
  • VEC ⁇ PAR ⁇ a a * i ⁇ ⁇ i ++ ⁇ ; jump loop ⁇
  • Line 6 is again a vector with the condition that a as
  • ⁇ i> 100 ⁇ ⁇ jump exit ⁇ ⁇ VEC ⁇
  • VEC ⁇ and PAR ⁇ can be viewed as purely combinatorial networks.
  • VEC and PAR ale Petri network are preferably designed to control the further processing after complete processing of the respective contents, as preferred.
  • VEC and PAR as a purely combinatorial network creates the need to secure the loop status. In this case, it is actually necessary to create a finite automaton.
  • the REG ⁇ instruction saves variables in a register.
  • the use of the combinatorial networks VEC and PAC in conjunction with the register REG thus creates a finite state machine that is constructed exactly according to the algorithm:
  • ⁇ i> 100 ⁇ ⁇ jump exit ⁇ ⁇ VEC ⁇
  • VPU technology provides for input and / or output registers on the PAEs and that the correctness in time and the availability of data are provided by an integrated handshake protocol (RDY / ACK). is ensured.
  • RY / ACK integrated handshake protocol
  • the request to leave VEC ⁇ or PAR ⁇ to have completed their internal data processing is automatically fulfilled for all subsequent variables used (if the data processing had not ended, the subsequent calculation steps would have to do with the termination and the Wait for the data to arrive).
  • the integrated registers also prevent oscillating feedback.
  • VEC ⁇ PAR ⁇ a a * i ⁇ ⁇ i ++ ⁇ ; jump loop ⁇
  • VEC ⁇ PAR ⁇ a a * i ⁇ ⁇ i ++ ⁇ ; REG ⁇ a i ⁇ ; jump loop ⁇
  • REG can be used within the combinatorial networks VEC and PAR. Strictly speaking, VEC and PAR lose the property of combinatorial networks. In abstract terms, however, REG can be viewed as a complex element (REG element) of a combinatorial network that is based on its own processing time. The processing of the subsequent elements is made dependent on the completion of the calculation of the REG element.
  • REG element complex element
  • Each sub-algorithm represents a configuration for the reconfigurable processor.
  • the sub-algorithms are configured successively, that is to say sequentially, on the processor, the results of the previous configuration (s) serving as operands for the respective new configuration.
  • the reconfiguration results in a finite state machine that processes and stores data at a time t and, at time t + 1, possibly after a configuration, processes the stored data differently and stores it again if necessary. It is essential that t is not defined in the classic sense by measures or commands, but by configurations.
  • the processor model presentation (PACT, October 2000, San Jose) is particularly referenced here.
  • a configuration consists of a combinatorial network of VEC and / or PAR, the results of which are stored (REG) in order to be used in the next configuration:
  • Configuration 1 VEC ⁇ Operands; ⁇ VEC
  • VEC, PAR and REG can be carried out on different levels of a compilation process. The most obvious at first is during a preprocessor run based on the source code as described in the previous examples. However, a specially adapted compiler is required for further compilation.
  • compilers mostly optimize code automatically (e.g. in loops).
  • An efficient decomposition of the code only makes sense after the optimization runs, especially if compilers (such as SUIF, Stanford University) are already optimizing the code for parallelization and / or vectorization.
  • the method that is particularly preferred is the integration of the analyzes into the backend of a compiler.
  • the backend translates an internal compiler data structure to the commands of a target processor.
  • Pointer structures such as DAGs / GAGs, trees or 3-address codes are mostly used as compiler-internal data structures
  • the method preferred according to the invention is based on the further processing of graphs, such as preferably trees.
  • Data dependencies and possible parallelism in accordance with the method described above can easily be recognized automatically based on the structure within Trees.
  • Known and established methods of graph analysis can be used for this purpose, for example.
  • an algorithm can be examined for data dependencies, loops, jumps, etc. using appropriately adapted parsing methods.
  • a method similar to evaluating expressions in compilers can be used.
  • VPU processor architecture
  • XPP X-programmable gate array
  • mechanism 1 is the generally typical case to be used.
  • Mechanism 2 is already very complex or cannot be implemented in most technologies and case 3 is only known from the applicant's VPU technology.
  • the execution method to be selected depends on the complexity of the algorithm, the required data throughput (performance) and the exact design of the target processor (e.g. number of PAEs). Examples:
  • Mechanism 1 creates a globally relevant state, since the complete configuration that follows depends on it.
  • Mechanisms 2 and 3 only result in a locally relevant state, as this is no longer required beyond the calculation - which is fully implemented.
  • the local or global relevance of states can also depend on the chosen mapping to the processor architecture.
  • a state that is relevant beyond a configuration and thus beyond the combinatorial network of the finite machine representing a configuration (that is, is required by subsequent finite machines) can in principle be regarded as global.
  • the diffuse terminology used in the term combinatorial network should be pointed out again.
  • a processor model for reconfigurable processors is created, which includes all essential commands:
  • Arithmetic / logical commands are mapped directly into the combinatorial network.
  • Jumps (Jump / Call) are either rolled out directly into the combinatorial network or realized through reconfiguration.
  • Condition and control flow commands (if, etc) are either completely resolved and processed in the combinatorial network or forwarded to a higher-level configuration unit, which then carries out a reconfiguration according to the status that has arisen.
  • Load / store operation ions are preferably mapped in separate configurations and implemented by address generators similar to the known DMAs, which write internal memories (REGO) to external memories by means of address generators or load them from external memories and / or peripherals. However, they can also be configured and work together with the data processing configuration.
  • REGO internal memories
  • Register-Move-OperatJonen are implemented in the combinatorial network by buses between the internal memories (REGO).
  • Push / pop operations are implemented by separate configurations that, if necessary, write certain internal registers in the combinatorial network and / or the internal memories (REG ⁇ ) to external memories or read from external memories using address generators, and preferably before or after the actual ones data processing configurations.
  • REG ⁇ internal memories
  • Figure la shows the structure of a conventional finite state machine, in which a combinatorial network (0101) is linked to a register (0102). Data can be sent directly to 0101 (0103) and 0102 (0104). Feedback (0105) of the register to the combinatorial network enables the processing of a state depending on the previous the conditions possible. The processing results are represented by 0106.
  • Figure 1b shows a representation of the finite state machine by a reconfigurable architecture according to PACT01 and PACT04 (PACT04 Fig. 12-15).
  • the combinatorial network from FIG. 1a (0101) is replaced by an arrangement of PAEs 0107 (0101b).
  • the register (0102) is executed by a memory (0102b) which can store several cycles.
  • the feedback according to 0105 is carried out by 0105b.
  • the inputs (0103b or 0104b) are equivalent to 0103 or 0104. Direct access to 0102b can be realized via a bus through the array 0101b.
  • Output 0106b is again equivalent to 0106.
  • FIG. 2 shows the mapping of a finite automaton onto a reconfigurable architecture.
  • 0201 (x) represent the combinatorial network (which can be designed as PAEs according to FIG. 1b).
  • An address generator (0204, 0205) is assigned to each of the memories.
  • the operand and result memories (0202, 0203) are physically or virtually coupled to one another in such a way that, for example, the results of one function or an operation of another can serve as operands and / or both results and newly added operands of a function of another as operands can serve.
  • Such a coupling can be established, for example, by bus systems or by a (re) configuration by which the function and networking of the memories with the 0201 is reconfigured.
  • Figure 3 shows various aspects of dealing with variables.
  • 0306 and 0304 must be interchanged to get a complete finite state machine.
  • 0305 represents the address generators for memories 0304 and 0306.
  • Figure 4 shows implementations of loops.
  • the hatched modules can be generated by macros (0420, 0421). 0421 can also be inserted by analyzing the graph for undelayed feedback.
  • 0402 is a multiplexer which initially leads the start value from xl (0403) to 0401 and then causes the feedback (0404a, 0404b) for each iteration.
  • a register (see REG ⁇ ) (0405) is inserted in the feedback to prevent an undelayed and thus uncontrolled feedback of the output from 0401 to its input.
  • 0405 is clocked with the work cycle of the VPU and thus determines the number of iterations per time. The respective meter reading would be available on 0404a or 0404b.
  • the loop does not terminate.
  • the multiplexer 0402 realizes a macro that was created from the loop construct. p * as macro is instantiated by the translation of WHILE.
  • Register 0405 is either also part of the macro or, according to a graph analysis according to the prior art, is inserted exactly where and where there is undelayed feedback in order to switch off the tendency to oscillate.
  • a circuit is shown that checks the validity of the result (0410) and only forwards the signal from 0404a to the subsequent functions (0411) when the abort criterion of the loop has been reached.
  • the termination criterion is determined by comparison xl ⁇ 10 (comparison level 0412).
  • the relevant status flag (0413) is passed to a multiplier 0402 for controlling the loop and the functions 0411 for checking the continuation of the result.
  • the status flag 0413 can be implemented, for example, by triggers according to DE 197 04 728.9.
  • the status flag means 0413 can also be sent to a CT, which then recognizes the termination of the loop and carries out a reconfiguration.
  • the basic function corresponds essentially to FIG. 4b, which is why the references have been adopted.
  • Function block 0501 calculates the multiplication.
  • the FOR loop is replaced by a 4b implemented further loop and is only indicated by block 0503.
  • Block 0503 supplies the status of the comparison to the termination criterion. The status is used directly to control the iteration, which means that the average 0412 (represented by 0502) is largely omitted.
  • Figure 6 shows the execution of a WHILE loop acc. Figure 4b over several configurations.
  • the state of the loop (0601) is a relevant state here, since this has a significant influence on the function in the following configurations.
  • the calculation spans 4 configurations (0602,
  • 0603, 0604, 0605 The data are stored in memories (see REGO) (0606, 0607). 0607 also replaces 0405.
  • the fill level of the memories can be used as a reconfiguration criterion, indicated via 0606, 0607: memory full / empty and / or 0601, which indicates the termination of the loop.
  • the fill level generates the memory triggers (cf. PACT01, PACT05, PACT08, PACT10), which are sent to the configuration unit and trigger a reconfiguration.
  • the state of the loop (0601) can also be sent to the CT.
  • the CT can then configure the following algorithms, or, if necessary, initially the remaining parts of the loop (0603,
  • FIG. 6 shows potential limits of the parallelizability.
  • the loop can be carried out in blocks, i.e. can be calculated by filling the memory 0606/0607. This ensures a high degree of parallelism.
  • the analysis of the calculation times can either take place in the compiler at the translation time in accordance with the following section and / or be measured empirically at or during a runtime in order to bring about a subsequent optimization, which leads to a learnable, in particular self-learning compiler. Analysis and parallelization methods are important for the invention.
  • Functions to be mapped are represented by graphs (cf. PACT13; DE 199 26 538 .0), whereby an application can be composed of any number of different functions.
  • the graphs are examined for their parallelism, whereby all methods of optimization can be used in advance.
  • ILP expresses which commands can be executed at the same time (see PAR ⁇ ). Such an analysis is easily possible based on the dependency of nodes on a graph. Corresponding methods are sufficiently known per se in the prior art and in mathematics; for example, reference should be made to VLIW compilers and synthesis tools.
  • an empirical analysis can also be carried out at runtime.
  • PACT10, PACT17 methods are known which allow statistics on program behavior to be generated at runtime. So z. For example, a maximum parallelizability can be assumed.
  • the individual paths return messages to a statistical unit (e.g. implemented in a CT or another stage, see PACT10, PACT17, but units according to PACT04 can also be used in principle) about each run.
  • a statistical unit e.g. implemented in a CT or another stage, see PACT10, PACT17, but units according to PACT04 can also be used in principle.
  • This type of path usage notification is not mandatory, but is advantageous.
  • the value PAR (p) used in the following indicates to clarify which parallelism at instruction level, i.e. H . how much ILP can be reached at a certain level (p) within the data flow graph transformed from the function (FIG. 7a).
  • Vector parallelism is also important (cf. VEC ⁇ ).
  • Vector parallelism can be used when larger amounts of data have to be processed.
  • linear sequences of operations can be vectorized, i.e. all operations can process data simultaneously, typically each separate operation processing a separate data word.
  • the graph of a function can be expressed by a Petri net.
  • Petri nets have the property that the results are passed on by nodes in a controlled manner, which means that loops can be modeled, for example.
  • the data throughput is determined by the feedback of the result in a loop. Examples:
  • the result determines the termination of the loop, but is not included in the calculation of the results: feedback is not necessary. Possibly. If wrong (too many) values run into the loop, the output of the results can be interrupted as soon as the end condition is reached at the end of the loop.
  • VEC used in the following for clarification can illustrate the degree of vectorizability of a function.
  • VEC shows how many data words can be processed simultaneously within a set of operations.
  • VEC 1 (FIG. 7b).
  • VEC can be calculated for an entire function and / or for partial sections of a function. Both variants can be advantageous for the compiler according to the invention, as is generally advantageous for determining and evaluating VEC.
  • PAR (p) is determined for every line of a graph, as advantageously as possible.
  • a line of a graph is defined by executing it within a clock unit. The number of operations depends on the implementation of the respective VPU.
  • PAR (p) corresponds to the number of nodes in line p, all nodes can be executed in parallel. If PAR (p) is smaller, certain nodes are only executed alternatively.
  • the alternative versions of a node are summarized in a PAE.
  • a selection device enables the activation of the alternative corresponding to the status of the data processing at runtime, as described for example in PACT08.
  • sequencer structures for mapping reentrant code can be generated.
  • the synchronizations required for this can be carried out, for example, using the TimeStamp method described in PACT18 or preferably using the trigger method described in PACT08.
  • sequencers or sequential parts are mapped to a PA, it is preferred for power consumption reasons to coordinate the performance of the individual sequencers. This can be done particularly preferably in such a way that the operating frequencies of the sequencers are matched to one another. Methods are known from PACT25 and PACT18, for example, which allow individual clocking of individual PAEs or PAE groups. The frequency of a sequencer can be determined on the basis of the number of cycles it typically needs to process the function assigned to it.
  • clock For example, if it needs 5 clock cycles to process its function while the rest of the system needs exactly one clock cycle to process assigned tasks, its clock should be 5 times higher than the clock of the rest of the system. Different clock cycles are possible with a large number of sequencers. A clock multiplication and / or a clock division can be provided.
  • some VPUs offer the option of differential reconfiguration. This can be used if only relatively few changes within the arrangement of PAEs are necessary for a reconfiguration. In other words, only the changes in a configuration compared to the current configuration are reconfigured. In this case, the partitioning can be such that the (differential) configuration following a configuration only contains the necessary reconfiguration data and does not represent a complete configuration.
  • the compiler of the present invention is preferably designed to recognize and support this.
  • the reconfiguration can be scheduled by the status, which reports the function (s) to a loading unit (CT), which in turn selects and configures the next configuration or partial configuration based on the incoming status. riert.
  • CT loading unit
  • the scheduling can support the possibility of preloading configurations during the runtime of another configuration.
  • Several configurations can possibly also be preloaded speculatively, ie without ensuring that the configurations are needed at all. This is particularly preferred if With longer data streams that can be processed without configuration, the CT is at least largely unloaded and, in particular, is not or only slightly burdened by tasks. ,
  • the local sequencers can also be controlled by the status of their data processing, as is known, for example, from DE 196 51 075.9-53, DE 196 54 846.2-53, DE 199 26 538.0.
  • Another dependent or independent status can be reported to the CT (see, for example, PACT04, LLBACK).
  • FIG. 8a shows the mapping of the graph according to FIG. 7a to a group of PAEs with the maximum achievable parallelism. All operations (instruction il-il2) are shown in individual PAEs.
  • FIG. 8b shows the same graph, for example with maximum usable vectorizability.
  • a status signal for each data word in each stage selects the operation to be carried out in the respective PAE.
  • the * PAEs are networked as a pipeline (vector) and each PAE carries out an operation on different data words for each cycle.
  • PAE1 calculates data and passes it on to PAE2. Together with the data, it passes on a status signal that indicates whether il or i2 should be executed.
  • PAE2 further calculates the data from PAE1.
  • the operation to be performed is based on the incoming status signal
  • PAE2 forwards a status signal to PAE3, which indicates whether (i4 v i5) v (i6 v i7 v i8) should be executed.
  • PAE3 further calculates the data from PAE2.
  • the operation (i4 v i5) v (i6 v i7 v i8) is selected and calculated in accordance with the incoming status signal. According to the calculation, PAE3 passes a status signal to PAE4, which indicates whether i9 v ilO v ill should be carried out.
  • PAE4 further calculates the data from PAE3.
  • the operation i9 v ilO v ill to be carried out is selected and calculated in accordance with the incoming status signal.
  • PAE5 further calculates the data from PAE4.
  • FIG. 8c again shows the same graph.
  • PAR (p) is high, which means that a large number of operations can be carried out simultaneously within one line.
  • the PAEs are networked in such a way that they can exchange any data with each other.
  • the individual PAEs only carry out operations if there is an ILP in the corresponding cycle, otherwise they behave neutrally (NOP), whereby clocking down and / or a clock and / or current shutdown can take place to minimize the power loss.
  • NOP neutrally
  • PAE2 works in the first cycle and passes the data on to PAE2 and PAE3.
  • PAE2 and PAE3 work in parallel and pass on their data to PAE1, PAE2, PAE3, PAE4, PAE5.
  • PAE1, PAE2, PAE3, PAE4, PAE5 work and pass the data on to P ⁇ E2, PAE3, PAE5.
  • PAE2, PAE3, PAE5 work and pass the data on to PAE2. Only PAE2 works in the fifth cycle.
  • the function therefore requires 5 cycles for the calculation.
  • the corresponding sequencer should therefore work at 5 times the beat in relation to its surroundings in order to achieve a corresponding performance.
  • PACT02 Figures 19, 20 and 21
  • PACT04 and PACT10, 13 also describe generally usable but more complex methods. Other methods and / or hardware can be used.
  • FIG. 8d shows the graph according to FIG. 7a in the event that there is no usable parallelism. To calculate a data word, each stage must be run through one after the other. In- Only one of the branches is processed within the stages.
  • the corresponding sequencer should therefore work at 5 times the beat in relation to its surroundings in order to achieve a corresponding performance.
  • Such a function can be mapped, for example, similar to FIG. 8c, using a simple sequencer according to PACT02 (FIGS. 19, 20 and 21).
  • PACT04 and PACT10, 13 also describe generally usable but more complex methods.
  • FIG. 9a shows the same function in which the paths (i2 ⁇ (i4 v i5) ⁇ i9) and (i3 ⁇ (i ⁇ v i7 v 18) ⁇ (i9 v ilO)) can be carried out in parallel.
  • (i4 v i5), i ⁇ v 17 v i8), (i9 v ilO) are alternative.
  • the function can still be vectorized.
  • a pipeline can thus be built up, in which the respective function to be carried out is determined for 3 PAEs (PAE4, PAE5, PAE7) on the basis of status signals.
  • FIG. 9b shows a similar example in which vectorization is not possible.
  • the paths (il ⁇ ⁇ 2 ⁇ (i4 v i5) ⁇ 19 ⁇ il2) and (i3 ⁇ (i ⁇ v i7 v i8) ⁇ (ilO v ill)) are parallel.
  • the PAEs are synchronized with one another by status signals, which are preferably generated by PAE1, since this calculates the start (il) and the end (il2) of the function.
  • SMP symmetrically parallel processor model
  • the individual registers that can be selected by the triggers are basically independent and therefore allow independent configuration, especially in the background. Jumps within the registers are not possible, the selection is made exclusively via the trigger vectors.
  • An essential factor for evaluating the efficiency of PAR and VEC is the type of data processed by the respective structure. For example, it is worth rolling out a structure, i.e. pipelining * and or parallelizing, that processes a large amount of data; as is the case with video data or telecom data, for example. Structures that process little data (eg keyboard input, mouse, etc.) are not worth rolling out, on the contrary, they would only block the resources of other algorithms.
  • the data type (arrays, streams, for example, should rather be rolled out than individual characters, for example due to the large amount of data).
  • the type of source and / or destination (keyboard and mouse, for example, have a data rate that is too low to be rolled out efficiently, whereas, for example, the data rate for network and / or video sources or destinations is significantly higher).
  • Irrelevant state State that is irrelevant for the actual algorithm and is also not described in the algorithm, but which is required by the executing hardware depending on the implementation

Abstract

Die Erfindung betrifft die Datenverarbeitung mit multidimensionalen Feldern und gibt an, wie hierfür vorteilhaft Hochsprachencodes einsetzbar sind.

Description

Titel: Verfahren zum Übersetzen von Programmen für rekon- figurierbare Architekturen
1. Einleitung
Die vorliegende Erfindung betrifft das Oberbegrifflich Beanspruchte. Damit befaßt sich die vorliegende Erfindung mit der Frage, wie rekonfigurierbare Architekturen optimal verwendet werden können und insbesondere damit, wie Anweisungen in einer gegebenen Hochsprache in rekonfigurierbaren Architekturen optimal zur Ausführung gebracht werden können.
Um in sog. Hochsprachen geschriebene Anweisungen zur Handhabung von Daten (Programme) in einer jeweiligen, zur Datenhandhabung verwendeten Architektur zur Ausführung zu bringen, sind sog. Compiler bekannt, die die Anweisungen der Hochsprache in an die verwendete Architektur besser angepaßte Anweisungen übersetzen. Compiler, die dabei hochparallele Architekturen besonders unterstützen, sind demgemäß parallelisierende Compiler.
Parallelisierende Compiler nach dem Stand der Technik verwenden für gewöhnlich spezielle Konstrukte wie Semaphore und/oder andere Verfahren zur Synchronisation. Dabei werden typischerweise technologiespezifische Verfahren verwendet. Bekannte Verfahren sind nicht geeignet, um funktional spezifizierte Architekturen mit dem zugehörigen Zeitverhalten und imperativ spezifizierte Algorithem zu kombinieren. Daher liefern die verwendeten Methoden nur in Spezialfallen zufriedenstellende
Lösungen. Compiler für rekonfigurierbare Architekturen, insbesondere für rekonfigurierbaren Prozessoren, verwenden für gewöhnlich Makros, die speziell für die bestimmte rekonfigurierbare Hardware erstellt wurden, wobei für die Erstellung der Makros zumeist Hardwarebeschreibungssprachen wie z.B. Verilog, VHDL oder System-C verwendet werden. Diese Makros werden dann von einer gewöhnlichen Hochsprache (z.B. C, C++) aus dem Programm- fluss heraus aufgerufen (instantiiert) .
Compiler für Parallelrechner sind bekannt, die auf einer grob- granularen Struktur, zumeist basierend auf kompletten Funktionen oder Threads Programmteile auf mehrere Prozessoren abbilden.
Weiterhin sind vektorisierende Compiler bekannt, die eine weitgehende lineare Datenverarbeitung, wie z.B. Berechnungen großer Ausdrücke in eine vektorisierte Form umwandeln und damit die Berechnung auf superskalaren Prozessoren und Vektorprozessoren (z.B. Pentium, Cray) ermöglichen.
Vorliegend wird ein Verfahren zur automatischen Abbildung von funktional oder imperativ formulierten Rechenvorschriften auf unterschiedliche Zieltechnologien beschrieben, insbesondere auf ASICs, rekonfigurierbare Bausteine (FPGAs, DPGAs, VPüs, ChessArray, KressArray, Cha eleon, etc.; im folgenden unter dem Begriff VPÜ zusammengefaßt) , sequentielle Prozessoren (CISC-/RISC-CPÜS, DSPs, etc.; im folgenden unter dem Begriff CPU zusammengefaßt) und parallele Rechnersysteme (SMP, MMP, etc.) . Hingewiesen wird insbesondere in diesem Zusammenhang auf die folgenden Schutzrechte und Patentanmeldungen desselben Anmelders: p 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516,
EP 01 102 674.7, PACT13, PACT17, PACT18, PACT22, PACT24, PACT25, PACT26US, PACT02, PACT04, PACT08, PACT10, PACT15, PACTl8(a), PACT 27, PACT19. Dά/ese sind hiermit zu Offenbarungszwecken vollumfänglich eingegliedert.
VPUs bestehen grundsätzlich aus einer mehrdimensionalen homogenen oder inhomogenen, flachen oder hierarchischen Anordung (PA) von Zellen (PAEs) , die beliebige Funktionen, i.b. logische und/oder arithmetische Funktionen und/oder Speicherfunktionen und/oder Netzwerkfunktionen ausführen können. Den PAEs ist typisch eine Ladeeinheit (CT) zugeordnet, die die Funktion der PAEs durch Konfiguration und ggf. Rekonfiguration bestimmt.
Das Verfahren basiert auf einem abstrakten parallelen Maschinenmodell, das neben dem endlichen Automaten auch imperative Problemspezifikationen integriert und eine effiziente algorithmische Ableitung einer Implementierung auf unterschiedliche Technologien ermöglicht.
Folgende Compilerklassen sind nach dem Stand der Technik bekannt :
Klassische Compiler, die häufig Stack-Maschinen-Code generieren und für sehr einfache Prozessoren geeignet waren, die im Wesentlichen als normale Sequenzer ausgestaltet sind. (vgl. N.Wirth, Compilerbau, Teubner Verlag) .
Vektorisierender Compiler bauen weitgehend linearen Code, der auf spezielle Vektorrechner oder stark gepipelinte Prozessoren abgestimmt ist. ursprünglich waren diese Compiler für Vektorrechner wie CRAY verfügbar. Moderne Prozessoren wie Pentium benötigen aufgrund der langen Pipelinestruktur ähnliche Verfahren. Da die einzelnen Rechenschritte vektorisiert (gepipe- lined) ablaufen ist der Code sehr viel effizienter. Allerdings bereitet der bedingte Sprung Probleme für die Pipeline. Daher ist eine Sprungvorhersage sinnvoll, die ein Sprungziel annimmt. Ist die Annahme falsch,,'' uss jedoch die gesamte Verarbeitungspipeline gelöscht werden. Mit anderen Worten ist jeder Sprung für diese Compiler problematisch, eine Parallelverarbeitung im eigentlichen Sinn ist nicht gegeben. Sprungvorhersagen und ähnliche Mechanismen erfordern einen erheblichen Zusatzaufwand an Hardware.
Grobgranulare parallele Compiler existieren im eigentlichen Sinne kaum, die Parallelität wird typischerweise durch den Programmierer oder das Betriebssystem markiert und verwaltet, also beipielsweise bei MMP-Computersysteme wie verscheiden IBM Architekturen, ASCI Red, etc. zumeist auf Thread-Ebene durchgeführt. Ein Thread ist ein weitgehend unabhängiger Programmblock oder gar ein anderes Programm. Threads sind daher grob- granular einfach zu parallelisieren. Die Synchronisation und Datenkonsistenz ist vom Programmierer bzw. dem Betriebssystem sicherzustellen. Dies ist aufwendig zu programmieren und erfordert einen wesentlichen Anteil der Rechenleistung eines Parallelrechner. Zudem ist durch diese grobe Parallelisierung nur ein Bruchteil der eigentlich möglichen Parallelität tat- sächtlich nutzbar.
Feingranulare parallele (z.B. VLIW) Compiler versuchen die Parallelität feingraunlar in VLIW Rechenwerke abzubilden, die mehrere Rechenoperationen in einem Takt parallel ausführen können aber einen gemeinsamen Registersatz besitzen. Ein wesentliches Problem stellt dieser limitierte Registersatz dar, da er die Daten für sämtliche Rechenoperationen bereitstellen muss. Zudem erschweren Datenabhängigkeiten und inkonsistente Lese/Schreiboperationen (LOAD/STORE) die Parallelisierung. Rekonf igurierbare Prozessoren weisen eine große Anzahl an unabhängigen Rechenwerken auf , die typisch in einem Feld angeordnet sind . Diese sind typisch nicht durch einen gemeinsamen Registersatz , sondern durch Bifsse miteinander verbunden . Dadurch lassen sich einerseits leicht Vektorrechenwerke aufbauen, andererseits können auch einfach parallele Operationen durchgeführt werden . Durch die Busverbindungen werden entgegen der herkömmlichen Registerkonzepte Datenabhängigkeiten aufgelöst .
Die Aufgabe der vorliegenden Erfindung besteht darin, Neues für die gewerbliche Anwendung bereitzustellen .
Die Lösung dieser Aufgabe wird in unabhängiger Form beansprucht . Bevorzugte Aus führungs formen finden sich in den Unteransprüchen .
Es wird also vorgeschlagen, für einen Compiler für rekonfigu- rierbare Prozessoren die Konzepte von vektorisierenden Compilern und parallelisierenden ( z . B . VLIW) Compilern zugleich anzuwenden und somit auf feingranularer Ebene zu Vektorisieren und parallelisieren .
Ein wesentlicher Vorteil besteht darin, dass der Compiler nicht auf eine fest vorgegebene Hardwarestruktur abbilden muss , sondern die Hardwarestruktur mit dem erf indungsgemäßen- Verfahren so konfiguriert werden kann, dass sie optimal für die Abbildung des j eweiligen compilierten Algorithmus ■ geeignet ist .
2. Beschreibung
Als Grundlage zur Abarbeitung praktisch j eder Methodik zur Spezifizierung von Algorithmen wird der endliche Automat genutzt . Die Struktur eines endlichen Automaten ist in Figur 1 abgebildet. Ein einfacher endlicher Automat zerfällt in ein kombinatorisches Netz und eine Registerstufe zum Zwischenspeichern von Daten zwischen den einzelnen Datenverarbeitungszyklen.
Ein endlicher Automat führt eine Anzahl rein kombinatorischer (also z.B. logischer und/oder arithmetischer) Datenmanipulationen aus, um danach einen stabilen Zustand zu erreichen, der in einem Register (satz) repräsentiert wird. Basierend auf diesem stabilen Zustand wird entschieden, welcher nächste Zustand im nächsten Verarbeitungsschritt erreicht werden soll und somit auch, welche kombinatorischen Datenmanipulationen im nächsten Schritt durchgeführt werden sollen.
Beispielsweise repräsentiert ein Prozessor oder Sequenzer einen endlichen Automaten. In einem ersten Verarbeitungsschritt kann eine Subtraktion von datendurchgeführt werden. Das Ergebnis wird gespeichert. Im nächsten Schritt kann basierend auf dem Ergebnis der Subtraktion ein Sprung durchgeführt werden, der je nach Vorzeichen des Ergebnisses in eine andere Weiterverarbeitung führt.
Der endliche Automat ermöglicht die Abbildung komplexer Algorithmen auf beliebige sequentielle Maschinen, wie in Figur 2 abgebildet. Der dargestellte komplexe endliche Automat besteht aus einem komplexen kombinatorischen Netz, einem Speicher zum Ablegen von Daten und einem Adressgenerator zum Adressieren der Daten im Speicher.
Nun kann jedes beliebige sequentielle Programm grundlegend als endlicher Automat interpretiert werden, wobei aber zumeist ein sehr großes kombinatorisches Netz entsteht . Bei der Programmierung klassischer "von Neumann"-Architekturen - also bei allen CPUs - werden daher die kombinatorischen Operationen in eine Folge von j eweils einzelnen einfachen, fest vorgegebenen Operationen (OpCodes) auf CPU-interne Register zerlegt. Durch diese Zerlegung entstehen Zustände zur Steuerung der in eine Folge zerlegten kombinatorischen Operation, die aber innerhalb der ursprünglichen kombinatorischen Operation per se nicht vorhanden sind, bzw. nicht benötigt werden. Daher sind jedoch die abzuarbeitenden Zustände einer von Neumann Maschinen grundsätzlich von den algorithmischen Zuständen eines kombinatorischen Netzes, also den Registern endlicher Automaten zu unterscheiden.
Es wurde nun erkannt, dass die VPU-Technologie (wie sie im Wesentlichen durch einige oder alle der Schriften PACT01, PACT02, PACT03, PACT04, PACT05, PACT08, PACT10, PACT13, PACT17, PACT18, PACT22, PACT24 definiert ist, die durch Bezugnahme vollumfänglich eingegliedert sind) im Gegensatz zu den starren OpCodes von CPUs ermöglicht, komplexe Instruktionen entsprechend eines abzubildenden Algorithmus wie in flexiblen Konfigurationen hineinzukompilieren.
2.1 Arbeitsweise des Compilers
Besonders vorteilhaft ist bei der Arbeitsweise des Compilers, wenn die komplexen Instruktionen derart generiert werden, daß diese möglichst lange in der PAE-Matrix ohne Rekonfiguration ausgeführt wird.
Der Compiler generiert weiterhin den endlichen Automaten bevorzugt aus dem imperativen Quelltext derart, daß er der jeweiligen PAE-Matrix besonders gut angepasst ist, also solche Operationen darin vorgesehen werden, die die typisch grobgra- nularen Logikkreise (ALUs etc.), gegebenenfalls auch vorhandene feingranulare Elemente (FPGA-Zellen in der VPU, statemachi- nes etc.) besonders effizient nutzen. Der compilererzeugte endliche Automat wird dann in Konfigurationen zerlegt.
Das Abarbeiten (Interpretieren^ des endlichen Automaten geschieht auf einer VPU derart, daß die generierten Konfigurationen succesive auf die PAE-Matrix abgebildet werden und die Arbeitsdaten und/oder Zustände, die zwischen den Konfigurationen zu übertragen sind, in Speicher abgelegt werden. Dazu kann das aus PACT04 bekannte Verfahren bzw. die entsprechende Architektur verwendet werden. Dieser Speicher wird vom Compiler bestimmt beziehungsweise vorgesehen. Es repräsentiert eine Konfiguration dabei eine Mehrzahl von Instruktionen; eine Konfiguration bestimmt zugleich für eine Vielzahl von Takten die Arbeitsweise der PAE-Matrix, während dieser Takte wird eine Vielzahl von Daten in der Matrix verarbeitet; diese stammen aus einer VPU externen Quelle und/oder einem internen Speicher und werden an eine externe Quelle und/oder einen internen Speicher geschrieben. Die internen Speicher ersetzen dabei den Registersatz einer CPU nach dem Stand der Technik derart, daß z.B. ein Register durch einen Speicher repräsentiert wird, wobei nicht ein Datenwort je Register gespeichert wird, sondern ein gesamter Datensatz je Speicher.
Wesentlich kann auch sein, daß die Daten und/oder Zustände der Verarbeitung einer ablaufenden Konfiguration compilerbestimmt in die Speicher abgelegt werden und somit der nächsten ablaufenden Konfiguration zur Verfügung stehen.
Ein bedeutender Unterschied zu Compilern, die auf Instruktionsbasis parallelisieren, besteht somit darin, daß das Verfahren die PAE-Matrix derart konfiguriert und rekonfiguriert, dass eine konfigurierte Folge von kombinatorischen Netzen auf einer VPU emuliert wird, während herkömmliche Compiler geladene Folgen von Instruktionen (OpCodes) kombinieren, wobei eine Instruktion als ein kombinatorisches Netz betrachtet werden kann.
2.2 Ausführungsbeispiel WHILE-Sprache
Im Folgenden soll die Funktionsweise des Compilers anhand einer einfachen Sprache beispielhaft verdeutlicht werden. Dabei wird von einer Sprache ausgegangen, die in ihren Grundlagen bereits bekannt ist, wobei in einer bekannten Veröffentlichung [Referenz "Doktorarbeit Armin Nuckel"] jedoch lediglich die Abbildung einer Funktion auf ein statisches kombinatorisches Netz beschrieben wird, während mit der Erfindung nun die Abbildung auf Konfigurationen erfolgt, die dann in einer zeitlichen Reihenfolge entsprechend des Algorithmus und der sich während der Verarbeitung ergebenden Zustände auf die PAE- Matrix abgebildet werden.
Die Programmiersprache geht davon aus, dass neben einfachen logischen und/oder arithmetischen Verknüpfungen ein Befehl "WHILE" existiert, der mit folgender Syntax definiert ist: WHILE ...
Mögliche Konstrukte sind damit: Anweisung
Folge von Anweisungen Schleife
Eine Anweisung oder eine Folge von Anweisungen ist durch das beschriebene Compiler-Verfahren auf ein kombinatorisches Netz abbildbar.
Figur 3a zeigt ein kombinatorisches Netz mit den dazugehörenden Variablen. Dabei kann sich der Inhalt ein und derselben Variable (z.B. xl) von einer Stufe (0301) des Netzes zur nächsten (0302) ändern. Diese Veränderung ist beispielsweise für die Zuweisung xl := xl + 1 in Figur 3b dargestellt.
Zur Adressierung zum Lesen der Operanden und zum Speichern der Ergebnisse können nun Adressgeneratoren mit dem kombinatorischen Netz der Zuweisung synchronisiert werden. Mit jeder verarbeiteten Variable werden entsprechende neue Adressen für Operanden und Ergebnisse generiert (Figur 3c) . Die Art des Adressgenerators ist prinzipiell beliebig und hängt von den Adressierungsschematas der compilierten Applikation ab. Für Operanden und Ergebnisse können gemeinsame, kombinierte oder vollständig unabhängige Adressgeneratoren implementiert werden.
Typischerweise werden bei der Datenverarbeitung wie im vorliegenden Datenverarbeitungsmodell eine Mehrzahl von Daten innerhalb einer bestimmten Konfiguration der PAEs verarbeitet. Bevorzugt ist der Compiler daher für die in vielen, wenn nicht den meisten Anwendungen möglichen einfachen FIFO-Modus ausgelegt, der zumindest- für die Datenspeicher anwendbar ist, die innerhalb dieser Beschreibung zum Speichern von Daten und Zuständen der Datenverarbeitung (quasi als Ersatz eines gewöhnlichen Registersatzes herkömmlicher CPUs) dienen. Mit anderen Worten dienen Speicher der temporären Speicherung von Variablen zwischen den Konfigurationen. Auch hier ist eine Konfiguration ähnlich einer Instruktion eines normalen Prozessors und die Speicher (insbesondere eine Mehrzahl) sind vergleichbar mit dem Registersatz eines normalen Prozessors.
2.2.3 Folgen von Anweisungen
Eine Folge der beispielhaften Zuweisung läßt sich wie folgt generieren (Figur 4a) : xl := 0;
WHILE TRUE DO xl := xl + 1; Diese Folge läßt sich nunmehr /mittels einer Zuweisung gemäß 2.2.1 und Adressgeneratoren für Operanden und Ergebnisse abbilden.
Endliche Folgen
Der Vollständigkeit halber soll eine besondere Ausgestaltung von Folgen abseits der definierten Konstrukte der WHILE Sprache diskutiert werden. Eine endliche Folge der beispielhaften Zuweisung läßt sich wie folgt generieren: FOR i:=l TO 10 xl := xl + 1; Eine derartige Folge läßt sich durch zwei Arten implementieren: a) Durch Generierung eines Addierers zur Berechnung von i entsprechend des WHILE-Konstruktes (siehe 2.2.4) und eines weiteren Addierers zur Berechnung von xl. Die Folge wird als Schleife abgebildet und iterativ berechnet (Figur 5a) . b) Durch Auswalzen der Schleife, wodurch die Berechnung von i als Funktion entfällt. Die Berechnung von xl wird i-mal in- stantiiert und als Pipeline aufgebaut, wodurch i nacheinander geschaltete Addierer entstehen (Figur 5b) .
2.2.4 Bedingungen
Bedingungen lassen sich mittels WHILE ausdrücken. Beispielsweise: xl := 0;
WHILE xl < 10 DO xl := xl + 1; Die Abbildung generiert eine zusätzliche PAE zur Verarbeitung des Vergleiches. Das Vergleichsergebnis wird durch ein Statussignal repräsentiert (vgl. Trigger in PACT08), das von den die Anweisung verarbeitenden PAEs und den Adressgeneratoren ausgewertet wird.
Die resultierende Abbildung ist in Figur 4b dargestellt.
Durch die Auswertung der Bedingung (hier WHILE, generell und einleuchtenderweise auch andere Anweisungen wie IF; CASE realisierbar) wird ein Status generiert, der der nachfolgenden Datenverarbeitung zur Verfügung gestellt werden kann (DE 197 04 728.9) und/oder an die CT oder eine lokale Ladesteuerung (DE 196 54 846.2) gesendet werden kann, die daraus Information über den weiteren Programmfluß und evtl. anstehende Rekonfigu- rationen ableitet.
2.2.5 Grundlegendes Verfahren
Entsprechend den vorherigen Verfahren wird jedes Programm in ein System abgebildet, das wie folgt aufgebaut ist:
1. Speicher für Operanden (vgl. Register einer CPU)
2. Speicher für Ergebnisse (vgl. Register einer CPU)
3. Netzwerk aus a) Zuweisungen und/oder b) Vergleichen- Anweisungen, also Bedingungen wie z.B. IF, CASE, Schleifen
(WHILE, FOR, REPEAT)
4. Optionalen Adressgenerator (en) zur Ansteuerung der Speicher nach 1 und 2.
2.2.6 Umgang mit Zuständen
Es wird nun für die Zwecke des beschriebenen Compilers zwischen algorithmisch relevanten und irrelevanten Zuständen unterschieden. Zustände werden in der VPU-Technologie für gewöhnlich durch Statussignale (z.B. Trigger in PACT08) und/oder Handshakes (z.B. RDY/ACK in PACT02) dargestellt. Generell können Zustände (v.a. in anderen Technologien, wie FPGAs, DPGAs, Chameleon-Bausteinen, Morphics, etc.) durch beliebige Signale, Signalbündel und/oder Register dargestellt werden. Das offenbarte Compilierverfahren kann auch auf solche angelegt werden, obwohl wesentliche Teile der Beschreibung bevorzugt auf die VPU fokussieren.
Relevante Zustände sind innerhalb des Algorithmus notwendig um dessen korrekte Funktion zu beschreiben. Sie sind für den Algorithmus wesentlich.
Irrelevante Zustände entstehen durch die verwendete Hardware und/oder die gewählte Abbildung oder aus anderen sekundären Gründen. Sie sind damit für die Abbildung (also die Hardware) wesentlich.
Lediglich die relevanten Zustände müssen mit den Daten erhalten werden. Daher werden diese zusammen mit den Daten in den Speichern abgelegt, da sie entweder als Ergebnis der Verarbeitung mit den Daten auftraten oder als Operanden mit den Daten für den nächsten Verarbeitungszyklus notwendig sind.
Irrelevante Zustände sind dagegen nur örtlich und/oder zeitlich lokal notwendig und müssen daher nicht gespeichert werden.
Beispiel: a) Die Zustandsinformation eines Vergleichs ist für die weitere Verarbeitung der Daten relevant, da dieser die auszuführenden Funktionen bestimmt. b) Angenommen, ein sequentieller Dividierer entsteht beispielsweise durch Abbildung eines Divisionsbefehles auf eine Hardware, die nur die sequentielle Division unterstützt. Dadurch entsteht ein Zustand, der den Rechenschritt innerhalb der Division kennzeichnet. Dieser Zustand ist irrele- vant, da für den Algorithmus nur das Ergebnis (also die ausgeführte Division) erforderlich ist. In diesem Fall werden also lediglich das Ergebnis und die Zeitinformation (also die Verfügbarkeit) benötigt. Der Compiler unterschei- det solche relevante und irrelevante Zustände bevorzugt voneinander.
Die Zeitinformation ist beispielsweise in der VPU-Technologie nach PACT01, 02, 13 durch das RDY/ACK Handshake erhältlich. Hierzu ist jedoch besonders anzumerken, dass das Handshake ebenfalls keine relevanten Zustand darstellt, da es lediglich die Gültigkeit der Daten signalisiert, wodurch sich wiederum die verbleibende relevante Information auf die Existenz gültiger Daten reduziert.
2.2.7 Umgang mit Zeit
In vielen Programmiersprachen, besonders in sequentiellen wie z.B. C, wird eine exakte zeitliche Reihenfolge implizit durch die Sprache vorgegeben; bei sequentiellen Programmiersprachen geschieht dies beispielsweise durch die Reihenfolge der einzelnen Anweisungen. Sofern dies durch die Programmiersprache und/oder den Algorithmus erforderlich ist, wird das Compilierverfahren so ausgeführt, dass sich die Zeitinformation auf Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK oder ein Time-Stamp-Verfahren nach DE 101 10 530.4 abbilden lässt.
Mit anderen Worten wird die implizite Zeitinformation von sequentiellen Sprachen in ein Handshake Protokoll derart abgebildet, dass das Handshake Protokoll (RDY/ACK-Protokoll) die Zeitinformation überträgt und insbesondere die Reihenfolge der Zuweisungen garantiert.
Beispielsweise wird die nachfolgende for-Schleife nur dann durchlaufen und iteriert, wenn die Variable inputstream je Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird der Schleifendurchlauf bis zum Eintreffen von RDY angehalten, while TRUE s : = 0 for i : = 1 to 3 s := s + inputstream;
Die Eigenschaft der sequentiellen Sprachen, nur von der Befehlsverarbeitung gesteuert zu werden, wird somit bei der Com- pilierung mit dem Datenflußprinzip, die Verarbeitung durch den Datenstrom, bzw. die Existenz von Daten zu steuern verbunden. Mit anderen Worten wird ein Befehl und/oder eine Anweisung (z.B. s := s + inputstream;) nur verarbeitet, wenn die Operation ausgeführt werden kann und die Daten verfügbar sind.
Bemerkenswert ist, daß dieses Verfahren gewöhnlicherweise zu keiner Änderung der Syntax oder Semantik einer Hochsprache führt. Es kann also vorhandener Hochsprachencode durch Neucom- pilierung problemfrei zur Ausführung auf einer VPU gebracht werden.
2.2.8 Laden und Speichern von Daten
Für die Grundlagen der Load/Store Operationen ist folgendes beachtlich.
Die nachfolgenden Adressierungsarten werden unterschiedlich behandelt :
1. externe Adressierung, also die Datentransfers mit externen Baugruppen
2. interne Adressierung, also die Datentransfers zwischen PAEs, i.b. zwischen RAM-PAEs und ALU-PAEs
Desweiteren kann die zeitliche Entkopplung der Datenverarbei- tung und dem Laden und Speichern der Daten besondere Beachtung finden. Bustransfers werden in interne und externe Transfers zerlegt, btl) Externe Lesezugriffe (Load Operation) werden separiert, in einer möglichen Ausführung auch bevorzugt in eine separate Konfiguration übersetzt. Die Daten werden von einem externen Speicher in einen internen transferiert.
bt2) Interne Zugriffe werden mit der Datenverarbeitung gekoppelt, d.h. die internen Speicher (Register Operation) werden für die Datenverarbeitung gelesen, bzw. beschrieben.
bt3) Externe Schreibzugriffe (Store Operation) werden separiert, in einer bevorzugten möglichen Ausführung auch in eine separate Konfiguration übersetzt. Die Daten werden von einem internen Speicher in einen externen transferiert.
Wesentlich ist, dass die btl, bt2, bt3 - also das Laden der Daten (Load) , das Verarbeiten der Daten (Datenverarbeitung und bt2) und das Schreiben der Daten (bt3) - in unterscheidliche Konfigurationen übersetzt werden können und diese ggf. zu einem unterschiedlichen Zeitpunkt ausgeführt werden.
Das Verfahren soll an dem nachfolgenden Beispiel verdeutlicht werden:
function example (a, b : integer) -> x : integer for i:= 1 to 100 for j := 1 to 100 x[i] := a[i] * b[j]
Die Funktion kann vom Compiler in drei Teile, bzw. Konfigurationen (subconfig) transformiert: example#dload: Lädt die Daten von extern (Speicher, Peripherie, etc.) und schreibt diese in interne Speicher. Interne Speicher sind mit r# und dem Namen der ursprünglichen Variable gekennzeichnet . exampletprocess : Entspricht der eigentlichen Datenverarbeitung. Diese liest die Daten aus internem Operanden und schreibt die Ergebnisse wieder in interne Speicher. example#dstore: schreibt die Ergebnisse aus dem internen Speicher nach extern (Speicher, Peripherie, etc.).
function example# (a, b : integer) -> x : integer subconfig example#dload for i := 1 to 100 r#a[i] := a[i] for j := 1 to 100 r#b[j] := b[j]
subconfig example#process for i := 1 to 100 for j := 1 to 100 r#x[i] := r#a[i] * r#b[j]
subconfig exampletdstore for i := 1 to 100 x[i] := r#x[i]
Ein wesentlicher Effekt des Verfahrens ist, dass anstatt i*j = 100 * 100 = 10.000 externe Zugriffe nur i+j = 100 + 100 = 200 externe Zugriffe zum Lesen der Operanden ausgeführt werden. Diese Zugriffe sind zudem noch vollkommen linear, was die Transfergeschwindigkeit bei modernen Bussystemen (Burst) und/oder Speichern (SDRAM, DDRAM, RAMBUS, etc) erheblich beschleunigt.
Die internen SpeicherZugriffe erfolgen parallel, da den Ope- randen unterschiedliche Speicher zugewiesen wurden. Zum Schreiben der Ergebnisse sind i = 100 externe Zugriffe notwendig, die ebenfalls wieder linear mit maximaler Performance erfolgen können.
Wenn die Anzahl der Datentransfers vorab nicht bekannt ist (z.B. WHILE-Schleifen) oder sehr groß ist, kann ein Verfahren verwendet werden, das bei Bedarf durch Unterprogrammaufrufe die Operanden nachlädt bzw. die Ergebnisse nach extern schreibt. Dazu können in einer bevorzugten Ausführung (auch) die Zustände der FIFOs abgefragt werden: 'empty' wenn das FIFO leer ist, sowie 'füll' wenn das FIFO voll ist. Entsprechend der Zustände reagiert der Programmfluß. Zu bemerken ist, dass bestimmte Variablen (z.B. ai, bi, xi) global definiert sind. Zu Performanceoptimierung kann ein Scheduler entsprechend der bereits beschriebenen Verfahren die Konfigurationen examp- le#dloada, example#dloadb bereits vor dem Aufruf von examp- le#process bereits ausführen, sodass bereits Daten vorgeladen sind. Ebenso kann example#dstore (n) nach der Terminierung von example#process noch aufgerufen werden um r#x zu leeren.
subconfig example#dloada (n) while !full(r#a) AND ai<=n r#a[ai] := a[ai] ai++
subconfig example#dloadb (n) while !full(r#b) AND bi<=n r#b[bi] := b.[bi] bi++
subconfig example#dstore (n) while ! empty (r#x) AND xi<=n x[xi] := r#x[xi] xi++ subconfig example#process for i := 1 to n for j := 1 to m if empty (r#a) then examplefttdloada (n) if empty (r#b) then example#dloadb (m) if full(r#x) then example#dstore (n)
r#x[i] := r#a[i] * r#b[j] bj := 1
Die Unterprogrammaufrufe und das Verwalten der globalen Variablen sind für rekonfigurierbare Architekturen vergleichsweise aufwendig. Daher kann in einer bevorzugten Ausführung die nachfolgende Optimierung durchgeführt werden, in welcher sämtliche Konfigurationen weitgehend unabängig ablaufen und nach vollständiger Abarbeitung terminieren (terminate) . Da die Daten b[j] mehrfach erforderlich sind, muß example#dloadb entsprechend mehrfach durchlaufen werden. Dazu werden beispielsweise zwei Alternativen dargestellt:
Alternative 1: example#dloadb terminiert nach jedem Durchlauf und wird von exampletprocess für jeden Neustart neu konfiguriert.
Alternative 2 : example#dloadb läuft unendlich und wird von ex- ample#process terminiert.
Während 'idle' ist eine Konfiguration untätig (wartend).
subconfig example#dloada (n) for i:= 1 to n while full(r#a) idle r#a[i] := a[i] terminate
subconfig example#dloadb (n) while 1 // ALTERNATIVE 2 for i : = 1 to n while full (r#b) idle r#b[i] := a[i] terminate
subconfig example#dstore (n) for i:= 1 to n while empty (r#b) idle x[i] := r#x[i] terminate
subconfig example#process for i := 1 to n for j := 1 to m while empty (r#a) or empty (r#b) or full(r#x) idle r#x[i] := r#a[i] * r#b[j] config example#dloadb (n) // ALTERNATIVE 1 termina te examplejdloadb (n) // ALTERNATIVE 2 terminate
Zur Vermeidung von Wartezyklen können Konfigurationen auch terminiert werden, sobald sie ihre Aufgabe temporär nicht weiter erfüllen können. Die entsprechende Konfiguration wird von dem rekonfigurierbaren Baustein entfernt, verbleibt jedoch im Scheduler. Hierzu wird im Folgenden der Befehl 'reenter' verwendet. Die relevanten Variablen werden vor der Terminierung gesichert und bei der wiederholten Konfiguration wiederhergestellt:
subconfig example#dloada (n) for ai:= 1 to n if full(r#a) reenter r#a[ai] := a[ai] terminate
subconfig example#dloadb (n) while 1 // ALTERNATIVE 2 for bi:= 1 to n if full(r#b) reenter r#b[bi] := a[bi] terminate
subconfig example#dstore (n) for xi:= 1 to n if empty (r#b) reenter x[xi] := r#x[xi] terminate
subconfig example#process for i := 1 to n for j := 1 to m if empty (r#a) or empty (r#b) or full(r#x) reenter r#x[i] := r#a[i] * r#b[j] config exampleidloadb (n) // ALTERNATIVE 1 terminate example#dloadb (n) // ALTERNATIVE 2 terminate
2.3 Makros
Komplexere Funktionen einer Hochsprache, wie z.B. Schleifen, werden typisch durch Makros realisiert. Die Makros werden dabei vom Compiler vorgegeben und zur Übersetzungszeit instanti- iert. (vgl. Figur 4). Die Makros sind entweder aus einfachen Sprachkonstrukten der Hochsprache oder auf Assemblerlevel aufgebaut. Makros können parametrisiert sein, um eine einfache Adaption an den beschie- benen Algorithmus zu ermöglichten, (vgl. Figur 5, 0502) . Die Makros sind auch vorliegend einzugliedern.
2.4 Feedback Loops und Register
Innerhalb der Abbildung eines Algorithmus in ein kombinatorisches Netz können unverzögerte Rückkopplungen entstehen, die unkontrolliert schwingen.
In praktisch implementierten VPU-Technologien gemäß PACT02 wird dies durch einen Aufbau der PAE verhindert, bei welchem mindestens ein Register zur Entkopplung, etwa fest in den PAEs, definiert ist.
Generell sind unverzögerte Rückkopplungen durch Graphenanalyse des entstandenen kombinatorischen Netzes feststellbar. In die Datenpfade, in denen eine unverzögerte Rückkopplung besteht, werden daraufhin gezielt Register zur Entkopplung eingefügt. Der Compiler kann somit Register- beziehungsweise Speichermittel verwalten.
Durch die Verwendung von Handshake-Protokollen (z.B. RDY/ACK gem. 2.2.7) ist die korrekte Funktion der Berechnung auch durch das Einfügen von Registern sichergestellt.
2.5 Prozssormodell / Time Domain Multiplexing (TDM) Grundsätzlich besitzt jede praktisch realisierte PAE-Matrix lediglich eine endliche Größe. Daher muß im folgenden Schritt eine Partitionierung des Algorithmus nach 2.2.5 Abs. 4 a/b in eine Mehrzahl von Konfigurationen durchgeführt werden, die nacheinander in die PAE-Matrix konfiguriert werden. Ziel ist typisch, möglichst viele Datenpakete in dem Netzwerk zu berechnen, ohne umkonfigurieren zu müssen. Zwischen den Konfigurationen wird eine Zwischenspeicherung vorgenommen, wobei der Zwischenspeicher - ähnlich eines Registers bei CPUs - die Daten zwo/sehen den einzelnen sequentiell ausgeführten Konfigurationen speichert.
Somit wird durch das Rekonfigurieren von Konfigurationen, der Datenverarbeitung in der PAE-Matrix und der Zwischenspeicherung in den Speichern ein sequentielles Prozessormodell aufgebaut.
Mit anderen Worten wird in der VPU-Technologie durch die beschriebene Compilierung nicht ein OpCode sequentiell ausgeführt, sondern komplexe Konfigurationen. Während bei CPUs ein Opcode typischerweise ein Datenwort bearbeitet, werden in der VPU-Technologie eine Mehrzahl von Datenworten (ein Datenpaket) von einer Konfiguration bearbeitet. Dadurch steigt die Effizienz der rekonfigurierbaren Architektur durch ein besseres Verhältnis zwischen Rekonfigurationsaufwand und Datenverarbeitung.
In der VPU-Technologie wird zugleich anstatt eines Registers ein Speicher verwendet, da nicht Datenworte, sondern Datenpakete zwischen den Konfigurationen bearbeitet werden.
Dieser Speicher kann als Random-Access Memory, Stack, FIFO oder als beliebige andere Speicherarchitektur ausgestaltet sein, wobei typischerweise mit einem FIFO die beste und am einfachsten zu realisiernde Möglichkeit gegeben ist.
Daten werden nunmehr durch die PAE-Matrix, entsprechend des konfigurierten Algorithmus, bearbeitet und in einem oder meh- reren Speichern gespeichert. Die PAE-Matrix wird nach der Bearbeitung einer Menge von Daten umkonfiguriert und die neue Konfiguration entnimmt die Zwischenergebnisse aus dem/den Speicher (n) und setzt die Ausführung des Programmes fort. Da- bei können durchaus auch neue Daten von externen Speichern und/oder der Peripherie zusätzlich in die Berechnung einfließen, ebenso können Ergebnisse an externen Speichern und/oder der Peripherie geschrieben werden.
Mit anderen Worten ist der typische Ablauf einer Datenverarbeitung das Auslesen von internen RAMs, das Verarbeiten der Daten in der Matrix und das Schreiben von Daten in die internen Speicher, wobei- zur Datenverarbeitung auch beliebige externe Quellen oder Ziele für Datentransfers zusätzlich oder anstelle der internen Speicher verwendet werden können.
Während "sequencen" bei CPUs als das Neuladen eines OpCodes definiert ist, wird nach dem Vorstehenden "sequencen" von VPUs also als das (Re) konfigurieren von Konfigurationen definiert. Dies bedeutet allerdings nicht, daß nicht unter bestimmten Bedingungen Teile des Feldes als Sequenzer im herkömmlichen Sinne betrieben werden könnten.
Die Information, wann und/oder wie gesequenzt wird, d.h. welche nächste Konfiguration konfiguriert werden soll, ist durch verschiedene Informationen darstellbar, die einzeln oder kombiniert verwendet werden können. Z. B. sind folgende Strategien zur Ableitung der Information allein und/oder in Kombination bzw. alternativ sinnvoll: a) durch den Compiler zur Übersetzungszeit definiert; b) durch das Event-Netzwerk definiert (Trigger, DE 197 04 728.9), wobei das Eventnetzwerk interne und/oder externe Zustände repräsentieren kann; c) durch den Füllgrad der Speicher
(Trigger, DE 197 04 728.9, DE 196 54 846.2-53).
2.5.1 Einfluß des TDM auf das Prozessormodell Die Partitionierung des Algorithmus bestimmt entscheidend die relevanten Zustände, die in den Speichern zwischen den verschiedenen Konfigurationen abgelegt werden. Sofern ein Zustand nur innerhalb einer Konfiguration relevant ist (lokal relevanter Zustand) , ist es nicht notwendig, diesen zu speichern, was vom Compilierverfahren bevorzugt berücksichtigt wird.
Zu Zwecken des Debuggings des auszuführenden Programmes kann es aber sinnvoll sein, diese Zustände dennoch zu speichern, um dem Debugger einen Zugriff auf diese zu ermöglichen. Auf die DE 101 42 904.5 wird verwiesen; diese ist hiermit vollumfänglich zu Offenbarungszwecken eingegliedert.
Weiterhin können zusätzlich Zustände relevant werden, wenn ein Taskswitch-Mechanismus (z.B. durch ein Betriebssystem oder Interruptquellen) verwendet wird und aktuelle ausgeführte Konfigurationen unterbrochen werden, andere Konfigurationen geladen werden und/oder zu einem späteren Zeitpunkt die abgebrochene Konfiguration fortgesetzt werden soll. Eine detailliertere Beschreibung folgt im nachfolgenden Abschnitt.
Ein einfaches Beispiel soll ein Unterscheidungsmerkmal für lokal relevante Zustände aufzeigen: a) Eine Verzweigung des Types "if () then ... eise ..." paßt vollständig in eine einzige Konfiguration, d.h. beide Datenpfade (Zweige) sind gemeinsam vollständig innerhalb der Konfiguration abgebildet. Der sich beim Vergleich ergebende Zustand ist relevant, jedoch lokal, da er in den nachfolgenden Konfigurationen nicht mehr benötigt wird. b) Dieselbe Verzweigung ist zu groß, um vollständig in eine einzige Konfiguration zu passen. Mehrere Konfigurationen sind notwendig, um die vollständigen Datenpfade abzubilden. In diesem Fall ist der Zustand global relevant und muß gespeichert und den jeweiligen Daten zugeordnet werden, da die nachfolgenden Konfigurationen bei der Weiterverarbei- tung der Daten den jeweiligen Zustand des Vergleichs benötigen.
2.6 Task-Switching
Einen zusätzlichen Einfluß auf die Betrachtung und den Umgang mit Zuständen hat der mögliche Einsatz eines Betriebssystemes . Betriebssysteme verwenden beispielsweise Task-Scheduler zum Verwalten mehrere Aufgaben (Tasks) , um ein Multitasking zur Verfügung zu stellen.
Task-Scheduler brechen Tasks zu einem bestimmten Zeitpunkt ab, starten andere Tasks und kehren nach deren Abarbeitung zur Weiterbearbeitung des abgebrochenen Tasks zurück. Sofern sichergestellt ist, daß eine Konfiguration - die hier der Abarbeitung eines Tasks entsprechen kann - nur nach der kompletten Abarbeitung - d.h. wenn alle innerhalb dieses Kon- figurationszyklusses zu bearbeitende Daten und Zustände gespeichert sind - terminiert, können lokal relevante Zustände ungespeichert bleiben. Dieses Verfahren, also das komplette abarbeiten einer Konfiguration und der nachfolgende Taskswitch ist die bevorzugte Methode für den Betrieb von rekonfigurier- baren Prozessoren und entspricht im Wesentlichen dem Ablauf in einem normalen Prozessor, der auch zunächst die aktuell bearbeiteten Instruktionen abarbeitet und dann den Task wechselt.
Für manche Anwendungen ist jedoch eine besonders kurze Reaktion auf eine Taskwechselsanforderung erforderlich, z.B. in Realtime-Anwendungen. Hier kann es sinnvoll sein Konfigurationen vor deren kompletter Abarbeitung abzubrechen. Sofern der Task-Scheduler Konfigurationen vor deren vollständiger Abarbeitung abbricht, müssen lokale Zustände und/oder Daten gespeichert werden. Weiterhin ist dies von Vorteil, wenn die Abarbeitungszeit einer Konfiguration nicht vorhergesagt werden kann. In Verbindung mit dem bekannten Halteproblem und dem Risiko, daß eine Konfiguration (z.B. durch einen Fehler) gar nicht terminiert, erscheint dies weiterhin sinnvoll, um damit einen Deadlock des gesamten Systems zu verhindern. Daher sind vorliegend, unter Berücksichtung von Taskwechseln, relevante Zustände auch als sςflche anzusehen, die für einen Taskwechsel und ein erneutes korrektes Aufsetzen der Datenverarbeitung notwendig sind.
Bei einem Taskswitch ist somit der Speicher für Ergebnisse und ggf. auch der Speicher für die Operanden zu sichern und zu einem späteren Zeitpunkt, also bei der Rückkehr zu diesem Task, wieder herzustellen. Dies kann vergleichbar zu den PUSH/POP Befehlen und Verfahren nach dem Stand der Technik erfolgen. Weiterhin ist der Zustand der Datenverarbeitung zu sichern, also der Zeiger auf die zuletzt vollständig bearbeiteten Operanden. Es sei hier besonders auf PACT18 verwiesen.
Abhängig von der Optimierung des Taskswitches gibt es beispielsweise zwei Möglichkeiten: a) Die abgebrochene Konfiguration wird neu konfiguriert und nur die Operanden werden geladen. Die Datenverarbeitung beginnt so von neuem, als ob die Bearbeitung der Konfiguration noch gar nicht begonnen wurde. Mit anderen Worten werden einfach alle Datenberechnungen von vorne an ausgeführt, wobei ggf. Berechnungen bereits zuvor durchgeführt wurden. Diese Möglichkeit ist einfach, aber nicht effizient.
b) Die abgebrochene Konfiguration wird neu konfiguriert, wobei die Operanden und die bereits berechneten Ergebnisse in die jeweiligen Speicher geladen werden. Die Datenverarbeitung wird bei den Operanden fortgesetzt, die nicht mehr vollständig berechnet wurden. Dieses Verfahren ist sehr viel effizienter, setzt aber voraus, daß ggf. zusätzliche Zustände, die während der Verarbeitung der Konfiguration entstehen, relevant werden, etwa wenn zumindest ein Zeiger auf die zuletzt vollständig verrechneten Operanden gesichert werden muss, damit bei deren Nachfolgern nach erfolgter neuer Konfiguration neu aufgesetzt werden kann.
2.7 Kontext Switch
Eine besonders bevorzugte Variante zur Verwaltung von relevanten Daten wird durch den nachfolgend beschriebenen Kontext Switch zur Verfügung gestellt. Bei Task-Wechseln und/oder bei der Ausführung von Konfigurationen und derem Wechsel (siehe beispielsweise Patentanmeldung DE 102 06 653.1, die zu Offenbarungszwecken vollumfänglich eingegliedert ist) kann es erforderlich sein, Daten oder Zustände, die typischerweise nicht zusammen mit den Arbeitsdaten in die Speicher abgelegt werden, da sie beispielsweise lediglich einen Endwert markieren, für eine nachfolgende' Konfiguration zusichern.
Der erfindungsgemäß bevorzugt implementierte Kontext Switch wird derart durchgeführt, dass eine erste Konfiguration entfernt wird und die zu sichernden Daten in entsprechenden Speichern (REG) (Speicher, Register, Zähler, etc) verbleiben.
Dann kann eine zweite Konfiguration geladen werden, diese verbindet die REG in geeigneter Weise und definierter Reihenfolge mit einem oder mehreren globalen Speicher (n). Die Konfiguration kann beispielsweise Adressgeneratoren verwenden, um auf den/die globalen Speicher zuzugreifen. Es ist also nicht erforderlich, vorab jeden einzelnen Speicherplatz durch den Compiler festlegen zu lassen und/oder auf als Speicher ausgestaltete REG zuzugreifen.
Entsprechend der konfigurierten Verbindung zwischen den REG werden die Inhalte der REG in einer definierten Reihenfolge in den globalen Speicher geschrieben, wobei die jeweiligen Adressen von Adressgeneratoren vorgegeben werden. Der Adressgenerator generiert die Adressen für den/die globalen Speicher (n) derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der entfernten ersten Konfiguration eindeutig zugeordnet werden können.
Es werden somit bevorzugt für unterschiedliche Konfigurationen unterschiedliche Adressenräume'' vorgesehen. Die Konfiguration entspricht dabei einem PUSH gewöhnlicher Prozessoren.
Danach verwenden andere Konfigurationen die Ressourcen.
Nun soll die erste Konfiguration wieder gestartet werden. Zuvor wird eine dritte Konfiguration gestartet, die die REG der ersten Konfiguration in einer definierten Reihenfolge miteinander verbindet.
Die Konfiguration kann wiederum beispielsweise Adressgeneratoren verwenden um auf den oder die globalen Speichern zuzugreifen und/oder um auf als Speicher ausgestaltete REG zuzugreifen.
Ein Adressgenerator generiert dabei Adressen bevorzugt derart, dass ein korrekter Zugriff auf die der ersten Konfiguration zugeordnete PUSHAREA erfolgt. Die generierten Adressen und die konfigurierte Reihenfolge der REG sind derart, dass die Daten der REG in der ursprünglichen Ordnung aus den Speichern in die REG geschrieben werden. Die Konfiguration entspricht einem POP gewöhnlicher Prozessoren.
Nun wird die erste Konfiguration wieder gestartet.
Zusammengefaßt wird ein Kontext Switch bevorzugt derart durchgeführt, dass durch das Laden besonderer Konfigurationen, die ähnlich von PUSH/POP bekannter Prozessorarchitekturen arbeiten, die zu sichernden Daten mit einem' globalen Speicher ausgetauscht werden. Dieser Datenaustausch über globale Speicher mittels von Push/Pop-Austauschkonfiguationen wird als besonders relevant angesehen. Die Funktion soll in einem Beispiel verdeutlicht werden :
Eine Funktion addiert 2 Zahlenreihen, die Länge der Reihen ist zur Übersetzungszeit nicht begannt, sondern erst zur Laufzeit .
proc example while i<length do x [i] = a [i] + b [i] i = i + 1
Die Funktion wird nun während ihrer Ausführung unterbrochen, beispielsweise durch einen Task-Switch, oder weil der für x vorgesehene Speicher voll ist . a, b, x befinden sich zu diesem Zeitpunkt erfindungsgemäß in Speichern , i und ggf . length müssen j edoch gesichert werden.
Dazu wird die Konfiguration example terminiert, wobei die Registerinhalte erhalten bleiben und eine Konfiguration push gestartet, die i und length aus den Registern liest und in einen Speicher schreibt .
proc push mem[<push_adr_example>] = i push_adr_example++ mem[<push_adr_example>] = length
Nach der Ausführung wird push terminiert und die Registerinhalte können gelöscht werden.
Andere Konfigurationen werden ausgeführt. Nach einiger Zeit wird die Konfiguration example wieder gestartet. Zuvor wird eine Konfiguration pop gestartet, die die Registerinhalte wieder aus dem Speicher liest.
proc pop i = mem[<push_adr_example>] push_adr_example++ length = mem[<push adr example>]
Nach der Ausführung wird pop terminiert und die Registerinhalte bleiben bestehen. Die Konfiguration example wird wieder gestartet.
2.8 Algorithmische Optimierung
Durch das beschriebene Übersetzungsverfahren werden Kontrollstrukturen von algorithmischen Strukturen getrennt. Beispielsweise zerfällt eine Schleife in einen Rumpf (WHILE) und eine algorithmische Struktur (Anweisungen) .
Die algorithmischen Strukturen lassen sich nunmehr bevorzugt optional durch ein zusätzliches, der Trennung nachgeschaltetes Werkzeug optimieren.
Beispielsweise kann eine nachgeschaltetes Algebra-Software die programmierten Algorithmen optimieren und minimieren. Derartige Tools sind z.B. unter Bezeichnungen wie AXIOM, MARBLE, etc. bekannt. Durch die Minimierung kann eine schnellere Ausführung des Algorithmusses und/oder ein erheblich verringerter Platzbedarf erreicht werden.
Das Ergebnis der Optimierung wird danach wieder in den Compiler geführt und entsprechend weiterverarbeitet. Es soll zudem angemerkt sein, dass moderne Compiler (- Frontends) bereits eine Anzahl von Optimierungen für Algo- rithemen (auch z.T. algebraische) implementiert haben, die selbstverständlich im Rahmen des hier beschriebenen Verfahrens weiterhin nutzbar sind.
Es soll ausdrücklich erwähnt sein, dass die beschriebenen Verfahren, insbesondere jedoch die Abschnitte 2.2.7 "Umgang mit Zeit" und 2.3 "Makros" auch auf Compiler nach PACT20 angewendet werden können. PACT20 wird diesbezüglich zu Offenbarungszwecken vollumfänglich in diese Patentanmeldung einbezogen. 3. Anwendbarkeit für Prozessoren nach dem Stand der Technik, insbesondere mit VLIW-Architektur
Es soll besonders angemerkt werden, daß anstatt einer PAE- Matrix auch eine Anordnung von arithmetisch logischen Einheiten nach dem Stand der Technik (ALUs) , wie beispielsweise in VLIW-Prozessoren üblich, und/oder eine Anordnung von kompletten Prozessoren, wie beispielsweise in Multiprozessorsystemen üblich, verwendet werden kann. Ein Sonderfall stellt dabei die Verwendung einer einzelnen ALU das, sodaß das Verfahren auch für normale CPUs verwendbar ist.
In der Dissertation [Referenz Dissertation Armin Nuckel] wurde ein Verfahren entwickelt, das die Übersetzung der WHILE- Sprache in semantisch korrekte endliche Automaten ermöglicht. Darüber hinaus kann ein endlicher Automat als "Unterprogramm" verwendet werden und umgekehrt. Dadurch entsteht die Möglichkeit, eine Konfiguration auf unterschiedliche Implementierungstechnologien abzubilden, wie z.B. CPUs; symmetrische Mul- tiprozessoren; FPGÄs; ASICs; VPUs.
Insbesondere ist es möglich, Teilen einer Applikation die jeweils optimal geeignete Hardware zuzuordnen bzw. eine jeweilie Eignung zu bestimmen und anhand der mehr oder weniger guten Eignung die optimale Hardware zuzuordnen. Dabei sind bevorzugt auch temporäre Ressourcenverteilungen und -reservierungen erfaßbar. Mit anderen Worten würde beispielsweise eine Daten- flußstruktur einer Datenflußarchitektur zugeordnet werden, während eine sequentielle Struktur auf einen Sequenzer abgebildet wird, sofern diese vorhanden und/oder verfügbar sind.
Die entstehende Problemstellungen der Ressourcenzuweisungen für die einzelnen Algorithmen können z.B. durch einen "Job As- signment"-Algorithmus zur Verwaltung der Zuordnung gelöst werden.
4. Implementierung
Die Implementierung eines erfindungsgemäßen Compilers soll von eine "normalen" sequentiellen Programmiersprache ausgehen, also z.B. C oder Pascal. Diese Sprachen weisen die Eigenschaft auf, dass durch ihren sequentiellen Charakter eine zeitliche Abfolge implizit und künstlich durch die Sprachendefinition an sich generiert wird. Beispiel A:
Zeile 1 i++ Zeile 2 a = i * b Zeile 3 x = p - a Zeile 4 j = i * i
Durch die Sprachdefinition ist fest vorgegeben, dass Zeile 1 vor Zeile 2 vor Zeile 3 vor Zeile 4 ausgeführt wird. Allerdings könnte Zeile 4 auch direkt nach Zeile 1 ausgeführt werden und somit parallel zu Zeile 2 und 3 bearbeitet werden.
Mit anderen Worten werden durch sequentielle Sprachen weitere künstliche und nicht algorithmisch bedingte Zustände eingebaut. Wichtig ist lediglich die korrekte zeitliche Abfolge der Berechungen in Beispiel A. Zeile 4 darf erst berechnet werden, wenn i korrekt definiert ist, also nach der Abarbeitung von Zeile 1. Auch Zeile 2 darf erst nach der korrekten Definition von i (also nach der Abarbeitung von Zeile 1) verarbeitet werden. Zeile 3 benötigt die Ergebnisse von Zeile 2 (die Variable a) und darf daher erst nach derer korrekten Definition berechnet werden. Somit ergibt sich eine Datenabhängigkeit aber kei- ne besonderen Zustände.
Anhand der Datenabhängigkeiten der Variable a in Zeile 2 und 3 (Zeile 3 verwendet a als Operand, a ist das Ergebnis von Zeile 2) kann automatisch durch den Compiler folgende Transformation zur Repräsentation der Parallelisier- bzw. Vektorisierbarkeit (ParVec-Transformation) durchgeführt werden:
Zeile 2: VEC{a = i * b; Zeile 3: x = p - a}
VEC bedeutet, dass jeder durch ' ; ' getrennte Ausdruck nacheinander abgearbeitet wird, wobei die Ausdrücke innerhalb der geschweiften Klammern grundsätzlich gepipelinet werden können. Bevorzugt müssen sämtliche Berechnungen am Ende von VEC{ } durchgeführt und abgeschlossen sein, damit die Datenverarbeitung hinter VEC fortgesetzt wird.
Besser wird in einer internen Repräsentation der Datenstrukturen im Compiler die beiden Berechnungen als ein Vektor markiert:
VEC{a=i*b; x=p-q}
Zeile 4 ergibt einen einfachen Vektor:
VEC{j = i*i}
Da sich Zeile 4 gleichzeitig zu Zeile 2 und 3 berechnen lässt kann die Parallelität folgendermassen ausgedrückt werden:
PAR{{VEC{a=i*b; x=p-a} ;VEC{ j=i*i} }
PAR bedeutet, dass jeder durch '{..}' getrennte Ausdruck zeitgleich abgearbeitet werden kann. Bevorzugt müssen sämtliche Berechnungen am Ende von PAR{ } durchgeführt und abgeschlossen sein, damit die Datenverarbeitung hinter PAR fortgesetzt wird.
Wird Zeile 1 mit einbezogen, ergibt sich: VEC{i++; PAR{{VEC{a=i*b; x=p-a} } {VEC{ j=i*i } } } }
Da VEC{j=i*i} ein Vektor mit nur einem Element darstellt, kann auch wir folgt geschrieben werden:
VEC{i++; PAR{{VEC{a=i*b; x=p-a} } { j=i*i} } }
Ein weiteres Beispiel zeigt einen echten Zustand. Beispiel B:
Zeile 1 i++ Zeile 2 a = i * b Zeile 3 if a < 100 { Zeile 4 x = p - a Zeile 5 } eise { Zeile 6 = 1 i }
Jetzt kann Zeile 6 nur noch nach der Berechnung von Zeile 2 und Zeile 3 ausgeführt werden. Die Berechnung von Zeile 4 und 6 findet alternativ statt. Also ist der Zustand von Zeile 3 für die weitere Datenverarbeitung relevant (relevanter Zustand) .
Bedingte Zustände können bei einer Transformation durch IF ausgedrückt werden:
Zeile 1-2: VEC{i++; a=i*b}
Zeile 3: IF{ {a<100 } { zeile4} { zeile6} }
Zeile 4: VEC{x=p-a}
Zeile 6: VEC{j=i*i}
Zusammengefaßt ergibt das
VEC{i++; a=i*b; IF{ {a<100} {VEC{x=p-a} } {VEC{ j=i*i} } } } Weitere relevante Zustände werden durch Schleifen erzeugt : Beispiel C :
Zeile 1 for (i = 1, i < 10/0, i++) Zeile 2 a = a * i Zeile 3 q = p / a
Zeile 3 darf erst ausgeführt werden, nachdem die Schleife terminiert ist. Also bestehen bei bedingten Sprüngen relevante Zustände.
Eine erste Transformation der Schleife ergibt:
Zeile 1 i=l; Zeile 2 loop: if i >= 100 then exit Zeile 3 a = a * i Zeile 4 i++ Zeile 5 jump loop Zeile 6 exit : q = p / a
Zeile 3 und 4 können parallel berechnet werden, da Zeile 4 nicht vom Ergebnis von Zeile 3 abhängt:'
PAR{{a=a*i}{i++}}
Zeile 5 ergibt einen Vektor mit dem generierten PAR, da erst nach vollständiger Berechnung der Werte wieder in die Schleife gesprungen werden darf (hier liegt also eine zeitliche Abhängigkeit vor) .
VEC{PAR{ {a=a*i}{i++} }; jump loop}
Somit ergibt sich für die Bedingung: loop: IF{ {i>-100} {jump exit} {VEC{PAR{{a=a*i}{i++}}; jump loop}}} Die Zeile 1 ist ein Vektor mit der Bedingung, da diese vor der
Bedingung ausgeführt werden muss (IF verwendet i als Operand, i ist das Ergebnis von Zeile 1) .
Zeile 6 ist wiederum ein Vektqr mit der Bedingung, da a als
Operand verwendet wird und a das Ergebnis der Bedingung ist.
Somit ergibt sich (in übersichtlicher Schreibweise) : VEC{ i++; loop: IF{
{i>=100} {jump exit} {VEC{
PAR{
{a=a*i} {i++} }; jump loop } } }; exit: q=p/a }
Die Inhalte von VEC{} und PAR{ } können als rein kombinatorische Netze betrachtet werden.
Bevorzugt wird VEC und PAR ale Petri-Netz ausgestaltet, um wie bevorzugt die Weiterverarbeitung nach kompletter Verarbeitung der jeweilgen Inhalte zu steuern.
Durch die mögliche Betrachtung von VEC und PAR als rein kombi- natorisches Netz entsteht die Notwendigkeit den Schleifenzustand zu sichern. D.h. in diesem Fall ist es tatsächlich notwendig einen endlichen Automaten zu schaffen. Die Anweisung REG{ } speichert dazu Variablen in einem Register. Somit entsteht durch die Verwendung der kombinatorischen Netze VEC und PAC in Verbindung mit dem Register REG ein endlicher Automat, der exakt entsprechend des Algorithmus aufgebaut ist:
VEC{ i++; loop: IF{
{i>=100} { jump exit } {VEC{
PAR{
{a=a*i} U++} };
REG{a ;i } j ump loop } } } ; exit : q=p/a }
Es soll besonders darauf hingewiesen werden, dass in der VPU Technologie des Anmelders (vgl. PACT21) Ein- und/oder Ausgangsregister an den PAEs vorgesehen sind und die zeitliche Korrektheit und die Verfügbarkeit von Daten durch ein integriertes Handshake-Protokoll (RDY/ACK) sichergestellt ist. Insoweit wird die Forderung bevorzugt beim Verlassen von VEC{} oder PAR{ } deren interne Datenverarbeitung abgeschlossen zu haben automatisch für alle nachfolgend verwendeten Veriablen erfüllt (wäre die Datenverarbeitung nicht beendet, würden nachfolgende Berechnungsschritte auf die Beendigung und das Eintreffen der Daten warten) . Durch die integrierten Register sind auch schwingende Rückkopplungen ausgeschlossen.
Insoweit ist nachfolgender Term. für diese Technologie korrekt: VEC{PAR{{a=a*i}{i++}}; jump loop}
Für andere Technologien, die die o.g. Ausgestaltungen nicht oder nur teilweise aufweisen, sollte der Term folgendermassen formuliert werden: VEC{PAR{{a=a*i}{i++}}; REG{a;i}; jump loop}
Es soll darauf hingewiesen werden, dass diese Form auf jeden Fall auch in der VPU-Technologie des Anmelders zu einer korrekten und optimalen Abbildung des Algorithmus auf den rekon- figurierbaren Prozessor führt.
REG kann innerhalb der kombinatorischen Netze VEC und PAR verwendet werden. Streng betrachtet verlieren dadurch VEC und PAR die Eigenschaft der kombinatorischen Netze. Abstrakt kann jedoch REG als ein komplexes Element (REG-Element) eines kombinatorischen Netzes betrachtet werden, dem eine eigene Abarbeitungszeit zugrunde liegt. Die Bearbeitung der nachfolgenden Elemente wird vom der Beendigung der Berechnung des REG- Elementes abhängig gemacht.
In dem Bewusstsein dieser begrifflichen Ungenauigkeit wird eine Verwendung von REG innerhalb von VEC und PAR im Weiteren zugelassen und ist insbesondere auch notwendig.
Wie bereits vorstehend erwähnt, ist die Verwendung von REG typischerweise innerhalb einer Konfiguration einer VPU des Anmelders nicht erforderlich, sondern explizit immer nur dann, wenn die Berechnungsergebnisse einer Konfiguration abgespeichert werden, sodass REG ein diesem Anwendungsfall tatsächlich dem expliziten Register eines endlichen Automaten entspricht. Neben der Synthese von endlichen Automaten für Schleifen, sind insbesondere in einem weiteren Fall endliche Automaten erforderlich:
Ist ein Algorithmus zu groß, um komplett innerhalb der PAEs eines rekonfigurierbaren Prozessors abgearbeitet zu werden, muß er in mehrere Teilalgorithmen zerlegt werden. Jeder Teilalgorithmus stellt eine Konfiguration für den rekonfigurierbaren Prozessor dar. Nacheinander, also sequentiell, werden die Teilalgorithmen auf den Prozessor konfiguriert, wobei die Ergebnisse der jeweils vorhergehenden Konfiguration (en) für die jeweils neue Konfiguration als Operanden dienen.
Mit anderen Worten entsteht durch die Rekonfiguration ein endlicher Automat, der zu einem Zeitpunkt t Daten bearbeitet und speichert und zu einem Zeitpunkt t+1, möglicherweise nach einer Konfiguration, die gespeicherten Daten ggf. anders verarbeitet und wieder speichert. Wesentlich ist, dass t nicht im klassischen Sinn durch Takte oder Befehle definiert wird, sondern durch Konfigurationen. Hierzu sein besonders die Präsentation Prozessormodell (PACT, Oktober 2000, San Jose) referen- ziert .
Mit noch anderen Worten besteht eine Konfiguration aus einem kombinatorischen Netz aus VEC und/oder PAR, dessen Ergebnisse gespeichert werden (REG) , um in der nächsten Konfiguration weiterverwendet zu werden:
Konfiguration 1: VEC{Operands; {VEC| PAR} ;REG{Resultsl} } Konfiguration 2: VEC{Resultsl; {VEC| PAR} ;REG{Results2 } }
Zum einfacheren Verständnis haben die obigen Beispiels und Beschreibungen die Konstrukte VEC, PAR und REG in der Hochsprachen eingeführt und diese dadurch strukturiert. Typischerweise und bevorzugt wird diese Strukturierung erst aber auf der Ebene der Zwischensprache (siehe Principles of Compiler Design (Red Dragon) , Aho, Sethi, Ullmann) eingeführt.
Es soll besonders darauf hingewiesen werden, dass die Strukturierung von Algorithmen mit VEC, PAR und REG typischerweise vollkommen automatisch durch den Compiler durch Methoden wie z.B. Graphenanalyse durchführbar ist.
Insbesondere ist es aber auch denkbar und teilweise von Vorteil dem Programmierer selbst die Strukturierungsmöglichkeit in der Hochsprache dadurch zu ermöglichen, dass VEC, PAR und REG wie oben aufgezeigt direkt in der Hochsprache beschreibbar sind.
Generierung
Die automatische Erstellung von VEC, PAR und REG kann auf unterschiedlichen Ebenen einen Compilierungsvorganges durchgeführt werden. Die zunächst einleuchtendste ist während eines Präprozessor-Durchlaufes auf Basis des Source-Codes wie in den vorigen Beispielen beschrieben. Für die weitere Compilierung ist danach allerdings ein speziell angepasster Compiler erforderlich.
Ein weiterer Aspekt ist, dass Compiler zumeist automatische Optimierungen von Code vornehmen (z.B. in Schleifen). Eine effiziente Zerlegung des Codes ist daher erst nach den Optimierungsläufen sinnvoll, insbesondere wenn Compiler (wie z.B. SUIF, Universität Stanford) bereits den Code für Parallelisi- serung und/oder Vectorisierung hin optimieren.
Die daher besonders bevorzugte Methode ist die Einbindung der Analysen in das Backend eines Compilers. Das Backend übersetzt eine compilerinterne Datenstruktur auf die Befehle eines Zielprozessors. Als compilerinterne Datenstrukturen werden zumeist Zeigerstrukturen wie DAGs/GAGs, Trees oder 3-Adress-Codes verwendet
(siehe Principles of Compiler Design (Red Dragon) , Aho, Sethi, Ullmann) . Teilweise werden auch Stack-Machine-Codes verwendet
(siehe Compiler selbstgeschneidert, C'T 1986 1-5) . Da die Datenformate prinzipiell äquivalent sind und ineinander transformiert werden können, setzt die erfindungsgemäß bevorzugte Methode auf der Weiterverarbeitung von Graphen, wie bevorzugt Trees, auf.
Datenabhängikeiten und mögliche Parallelitäten entsprechend dem vorstehend beschriebenen Verfahren sind innerhalb von Trees einfach auf Basis der Struktur automatisch zu erkennen. Hierzu können beispielsweise bekannte und etablierte Verfahren der Graphenanalyse eingesetzt werden. Alternativ oder optional kann durch entsprechend adaptierte Parsingmethoden ein Algorithmus auf Datenabhängikeiten, Schleifen, Sprünge etc. hin untersucht werden. Dabei kann ein Verfahren ähnlich dem der Auswertung von Ausdrücken in Compilern verwendet werden.
Abbildung
Die weitere Transformation des Algorithmus ist nunmehr stark von der Zielarchitektur abhängig. Beispielsweise bietet die Prozessorarchitektur des Anmelders (VPU, XPP) automatische Datensynchronisation in Hardware. Das bedeutet, dass die korrekte zeitliche Abfolge von Datenabhängigkeiten automatisch in der Hardware gehandhabt wird. Andere Architekturen benötigen zum Teil zusätzlich die Synthese geeigneter Zustandsmaschinen für die Steuerung es Datentransfers.
Besonders interessant ist die Handhabung bedingter Sprünge. Beispielswiese stellt die Prozessorarchitektur des Anmelders mehrere Mechanismen zu derer Abbildung und Ausführung zur Verfügung:
1. Rekonfiguration des Prozessors oder Teilen des Prozessors durch eine übergeordnete Konfigurationseinheit (vgl. Patentanmeldungen) PACT01, 04, 05, 10, 13, 17)
2. Auswalzen der Funktion in das Array aus PAEs (vgl. Patentanmeldung PACT08), dabei werden z.B. beide möglichen Zweige eines Vergleiches zugleich auf das Array abgebildet.
3. Wave Rekonfiguration nach Patentanmeldung (en) PACT08, 13, 17), dabei wird den unterschiedlich zu bearbeitenden Daten ein Token mitgegeben, das die jeweils gültige Konfiguration wählt.
Es soll erwähnt sein, dass der Mechanismus 1 der allgemein typisch anzuwendende Fall ist. Der Mechanismus 2 ist bereits bei den meisten Technologien sehr aufwendig oder gar nicht implementierbar und der Fall 3 ist bislang nur aus der VPU- Technologie des Anmelders bekannt.
Die jeweils zu wählende Ausführungsmethode hängt von der Komplexität des Algorithmus, dem erforderlichen Datendurchsatz (Performance) und der exakten Ausgestaltung des Zielprozessors ab (z.B. Anzahl der PAEs) . Beispiele:
Ein einfacher Vergleich soll folgendes Berechnen: if i < 0 then a=a*(-i) eise a=a*i
Eine Rekonfiguration des Prozessors (Mechanismus 1) je nach Ergebnis des Vergleichs scheint wenig sinnvoll zu sein. Das Auswalzen beider Zweige in das Array (Mechanismus 2) ist Grundsätzlich möglich. Je nach Ergebnis des Vergleichs werden entweder die a=a*(-i) oder a=a*i berechnenden PAEs angesteuert (vgl. PACT08) .
Besonders platzeffizient ist das Überlagern der beiden Berechnungen (Mechanismus 3) , wodurch nach dem Vergleich unabhängig vom Ergebnis dieselbe (n) PAEs die Daten weiterverarbeiten, die Daten aber mit einem Token versehen sind, das sodann in Abhängigkeit vom Vergleich lokal in den jeweils nachfolgenden die Daten verarbeitenden PAEs entweder die Funktion a=a*(-i) oder a=a*i auswählt, (vgl. PACT08, 13, 17) .
Nach Mechanismus 1 entsteht ein global relevanter Zustand, da die komplette folgende Konfiguration davon abhängig ist.
Nach Mechanismus 2 und 3 entstehen nur ein lokal relevanter Zustand, da dieser über die Berechnung hinaus - die vollständig implementiert ist - nicht mehr benötigt wird.
Mit anderen Worten kann die lokale oder globale Relevanz von Zuständen auch von der gewählten Abbildung auf die Prozessorarchitektur abhängen.
Ein Zustand der über eine Konfiguration hinaus und somit über das kombinatorische Netz des eine Konfiguration repräsentierenden endlichen Automaten hinaus relevant ist (also von nachfolgenden endlichen Automaten benötigt wird) , kann grundsätzlich als global betrachtet werden. Es soll nochmals auf die verwendete diffuse Terminologie des Begriffes kombinatorisches Netz hingewiesen werden.
Befehlsmodell des entstandenen Prozessors
Entsprechend der vorliegenden Erfindung entsteht ein Prozessormodell für rekonfigurierbare Prozessoren, das alle wesentlichen Befehle umfaßt :
Arithmetisch/logische Befehle werden direkt in das kombinato- rische Netz abgebildet.
Sprünge (Jump/Call) werden entweder direkt in das kombinatorische Netz ausgewalzt oder durch Rekonfiguration realisiert. Bedingung und Kontrollflußbefehle (if, etc) werden entweder im kombinatorischen Netz vollständig aufgelöst und bearbeitet oder an eine übergeordnete Konfigurationseinheit weitergeleitet, die sodann entsprechend des entstandenen Status eine Rekonfiguration durchführt.
Load/Store-OperatJonen werden bevorzugt in separate Konfigurationen abgebildet und durch Adressgeneratoren ähnlich den bekannten DMA's realisiert, die internen Speicher (REGO) mittels Adressgeneratoren in externe Speicher schreiben oder diese von externen Speichern und/oder Peripherie laden. Sie können aber auch zusammen mit der datenverarbeitenden Konfiguration konfiguriert sein und arbeiten.
Register-Move-OperatJonen werden im kombinatorischen Netz durch Busse zwischen den internen Speichern (REGO) realisiert.
Push/Pop-Operationen werden durch separate Konfigurationen realisiert, die ggf. bestimmte interne Register im kombinatorischen Netz und/oder die internen Speicher (REG{}) mittels Adressgeneratoren in externe Speicher schreiben oder aus externen Speichern lesen und die bevorzugt vor oder nach den eigentlichen datenverarbeitenden Konfigurationen ausgeführt werden.
5. Beschreibung der Figuren
Die nachfolgenden Figuren zeigen Implementierungs- und Ausgestaltungsbeispiele des Compilers.
Figur la zeigt den Aufbau eines gewöhnlichen endlichen Automaten, bei welchem ein kombinatorisches Netz (0101) mit einem Register (0102) verknüpft ist. Daten können direkt an 0101 (0103) und 0102 (0104) geführt werden. Durch eine Rückkopplung (0105) des Registers auf das kombinatorische Netz ist die Verarbeitung eines Zustandes in Abhängigkeit des/der vorhergehen- den Zustände möglich. Die Verarbeitungsergebnisse werden durch 0106 dargestellt.
Figur 1b zeigt eine Repräsentation des endlichen Automaten durch eine rekonfigurierbare Architektur nach PACT01 und PACT04 (PACT04 Fig. 12-15) . Das kombinatorischen Netz aus Figur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt (0101b) . Das Register (0102) wird durch einen Speicher (0102b) ausgeführt, der mehrere Zyklen speichern kann. Die Rückkopplung gemäß 0105 erfolgt durch 0105b. Die Eingänge (0103b bzw. 0104b) sind äquivalent 0103 bzw 0104. Der direkte Zugriff auf 0102b kann ggf. durch einen Bus durch das Array 0101b realisiert werden. Der Ausgang 0106b ist wiederum äquivalent 0106.
Figur 2 zeigt die Abbildung eines endlichen Automaten auf eine rekonfigurierbare Architektur. 0201 (x) repräsentieren das kombinatorische Netz (das entsprechend Figur lb als PAEs ausgestaltet sein kann) . Es existieren ein oder mehrere Speicher für Operanden (0202) und ein oder mehrere Speicher für Ergebnisse (0203) . Zusätzliche Daten Ein-/Ausgänge gem. 0103b, 0104b, 0106b) sind der Einfachheit halber nicht dargestellt. Den Speichern zugeordnet ist jeweils ein Adressgenerator (0204, 0205) .
Die Operanden- und Ergebnisspeicher (0202, 0203) sind physikalisch oder virtuell derart miteinander verkoppelt, daß beispielsweise die Ergebnisse einer Funktion bzw. einer Operation einer anderen als Operanden dienen können und/oder sowohl Ergebnisse als auch neu zugeführte Operanden einer Funktion einer anderen als Operanden dienen können. Eine derartige Kopplung kann beispielsweise durch Bussysteme hergestellt werden oder durch eine (Re) Konfiguration durch welche die Funktion und Vernetzung der Speicher mit den 0201 neu konfiguriert wird. Figur 3 zeigt verschiedene Aspekte zum Umgang mit Variablen.
In Figur 3a zeigen 0301, 0302, 0303 verschiedene Stufen der Berechnung. Diese Stufen können rein kombinatorisch oder auch über Register voneinander getrennt sein, fl, f2, f3 sind Funktionen, xl ist eine Variable gemäß Patentbeschreibung. Figur 3b zeigt die Verwendung einer Variablen xl in der Funktion xl := xl + 1.
Figur 3c zeigt das Verhalten eines endlichen Automaten zur Berechnung von xl := xl + 1 innerhalb einer Konfiguration. In der nächsten Konfiguration sind 0306 und 0304 zu vertauschen um einen vollständigen endlichen Automaten zu erhalten. 0305 repräsentiert die Adressgeneratoren für die Speicher 0304 und 0306.
Figur 4 zeigt Implementierungen von Schleifen. Die schraffierten Module können durch Makros generiert werden (0420, 0421) . 0421 kann auch durch Analyse des Graphen auf unverzögerte Rückkopplungen eingefügt werden.
Figur 4a zeigt die Implementierung einer einfachen Schleife der Art WHILE TRUE DO xl := xl + 1; Im Kern der Schleife liegt der Zähler +1 (0401) . 0402 ist ein Multiplexer, der zu Beginn den Startwert von xl (0403) auf 0401 führt und sodann bei jeder Iteration die Rückkopplung (0404a, 0404b) bewirkt. In die Rückkopplung ist ein Register (vgl. REG{}) (0405) eingesetzt, um eine unverzögerte und damit unkontrollierte Rückkopplung des Ausgangs von 0401 auf dessen Eingang zu verhindern. 0405 wird mit dem Arbeitstakt der VPU getaktet und bestimmt damit die Anzahl der Iterationen pro Zeit. Der jeweilige Zählerstand wäre an 0404a oder 0404b ab- greifbar. Je nach Definition der Hochsprache terminiert die Schleife jedoch nicht. Beispielsweise wäre in einer HDL (nach dem Stand der Technik (z.B. VHDL, Verilog) das Signal auf 0404 nutzbar, während es in einer sequentiellen Programmiersprache (z.B. C) 0404 nicht nutzbar ist, da die Schleife nicht terminiert und somit keinen Exit-Wert liefert.
Der Multiplexer 0402 realisiert ein Makro, das aus dem Schlei- fenkonstrukt entstanden ist. p*as Makro wird durch die Übersetzung von WHILE instantiiert .
Das Register 0405 ist entweder ebenfalls Teil des Makros oder wird entsprechend einer Graphenanalyse nach dem Stand der Technik exakt dann und dort eingefügt, wo eine unverzögerte Rückkopplung existiert, um so die Schwingneigung auszuschalten.
Figur 4b zeigt den Aufbau einer echten Schleife der Art WHILE xl < 10 DO xl := xl + 1; Der Aufbau entspricht im Kern der Figur 4a, weshalb dieselben Referenzen verwendet wurden.
Zusätzlich ist eine Schaltung dargestellt, die die Gültigkeit des Ergebnisses kontrolliert (0410) und das Signal von 0404a nur dann an die nachfolgenden Funktionen (0411) weiterleitet, wenn das Abbruchkriterium der Schleife erreicht ist. Das Abbruchkriterium wird durch den Vergleich xl < 10 festgestellt (Vergleichsstufe 0412) . Als Ergebnis des Vergleiches wird das betreffende Statusflag (0413) an ein Multipliziermittel 0402 zur Steuerung der Schleife und die Funktionen 0411 zur Kontrolle der Ergebnisweiterführung geleitet. Das Statusflag 0413 kann beispielsweise durch Trigger gemäß DE 197 04 728.9 implementiert sein. Ebenfalls kann das Statusflagmittel 0413 an eine CT gesendet werden, die daraufhin die Terminierung der Schleife erkennt und eine Rekonfiguration durchführt.
Figur 5a zeigt die iterative Berechnung von FOR i:=l TO 10 xl := xl * xl; Im wesentlichen entspricht die Grundfunktion Figur 4b, weshalb die Referenzen übernommen wurden. Der Funktionsblock 0501 berechnet die Multiplikation. Die FOR-Schleife wird durch eine weitere Schleife entsprechend Figur 4b implementiert und ist lediglich durch Block 0503 angedeutet. Block 0503 liefert den Status des Vergleiches auf das Abbruchkriterium. Der Status wird direkt zur Ansteuerung det Iteration verwendet, wodurch das Mittel 0412 (dargestellt durch 0502) weitgehend entfällt.
Figur 5b zeigt das Auswalzen der Berechnung von FOR i:=l TO 10 xl := xl * xl; Da die Anzahl der Iterationen zur Übersetzungszeit exakt bekannt ist, kann die Berechnung in eine Folge von i Multiplizierern (0510) abgebildet werden.
Figur 6 zeigt die Ausführung einer WHILE-Schleife gem. Figur 4b über mehrere Konfigurationen. Hier ist der Zustand der Schleife (0601) ein relevanter Zustand, da dieser die Funktion in den nachfolgenden Konfigurationen maßgeblich beeinflußt. Die Berechnung erstreckt sich über 4 Konfigurationen (0602,
0603, 0604, 0605) . Zwischen den Konfigurationen werden die Daten in Speichern (vgl. REGO) abgelegt (0606, 0607). 0607 ersetzt dabei ebenfalls 0405.
Als ein Rekonfigurationskriterium kann der Füllstand der Speicher dienen, angedeutet über 0606, 0607: Speicher voll/leer und/oder 0601, das den Abbruch der Schleife anzeigt. Mit anderen Worten werden durch den Füllstand der Speicher Trigger generiert (vgl. PACT01, PACT05, PACT08, PACT10) , die an die Konfigurationseinheit gesendet werden und eine Rekonfiguration auslösen. Auch der Zustand der Schleife (0601) kann an die CT gesendet werden. Daraufhin kann die CT bei Erreichen des Ab- bruchkriteriums die nachfolgenden Algorithmen konfigurieren, bzw. ggf. zunächst die restlichen Teile der Schleife (0603,
0604, 0605) abarbeiten und danach die nachfolgenden Konfigurationen laden. 6. Parallelisierbarkeit
Figur 6 zeigt potentielle Grerzen der Parallelisierbarkeit auf.
Sofern die Berechnung der Operanden unabhängig von der Rückkopplung 0608 ist, kann die Schleife blockweise, d.h. jeweils durch Füllen der Speicher 0606/0607 berechnet werden. Damit wird ein hoher Grad an Parallelität erreicht.
Sofern die Berechnung eines Operanden abhängig von dem Ergebnis der vorherigen Berechnung ist, also eine Rückkopplung oder dergleichen 0608 in die Berechnung einfließt, wird das Verfahren ineffizienter, da jeweils nur ein Operand innerhalb der Schleife berechnet werden kann.
Ist der nutzbare ILP (Instruktionslevel Parallelismus) innerhalb der Schleife hoch und die Zeit für die Rekonfiguration nieder (vgl. PACT02, PACT04, PACT13, PACT17) , kann eine auf PAEs ausgewalzte Berechnung auf einer VPU weiterhin effizient sein.
Ist dies nicht der Fall, ist es sinnvoll, die Schleife auf eine sequentielle Architektur (vom PA separater Prozessor oder Implementierung innerhalb des PA entsprechend DE 196 51 075.9- 53, DE 196 54 846.2-53 und insbesondere DE 199 26 538.0 (Fig. 5, 11, 16, 17, 23, 30, 31, 33)) abzubilden.
Die Analyse der BerechnungsZeiten kann entweder im Compiler zur Übersetzungszeit gemäß dem nachfolgenden Abschnitt erfolgen und/oder empirisch zu der oder einer Laufzeit gemessen werden, um eine nachträgliche Optimierung herbeizuführen, was zu einem lernfähigen, insbesondere selbstlernenden Compiler führt. Für die Erfindung sind Analyse- und Parallelisierungsverfahren von Bedeutung .
Verschiedene Verfahren nach dem Stand der Technik stehen für die Analyse und Durchführung der Parallelisierung zur Verfügung .
Ein bevorzugtes Verfahren soll im Folgenden beschrieben werden.
Abzubildende Funktionen werden durch Graphen dargestellt (vgl . PACT13; DE 199 26 538 .0 ) , wobei eine Applikation aus beliebig vielen unterschiedlichen Funktionen zusammengesetzt sein kann . Die Graphen werden auf die in ihnen enthaltene Parallelität untersucht, wobei vorab sämtliche Methoden der Optimierung zum Einsatz kommen können .
Beispielsweise sollen folgende Untersuchungen durchgeführt werden :
6.0. 1 ILP ( Instruction Level Parallelism)
ILP drückt aus , welche Befehle zeitgleich ausgeführt werden können (vgl . PAR{ } ) . Eine derartige Analyse wird auf Basis der Betrachtung von Abhängigkeiten von Knoten in einem Graphen einfach möglich. Entsprechende Verfahren sind nach dem Stand der Technik und in der Mathematik per se hinreichend bekannt, es soll beispielsweise auf VLIW-Compiler und Synthesetools verwiesen werden.
Besondere Beachtung benötigen aber z . B . gegebenenfalls verschachtelte bedingte Ausführungen ( IF) , da eine korrekte Aussage der parallel ausführbaren Pfade oftmals kaum oder nicht zu treffen ist, da eine starke Abhängigkeit vom Werteraum der einzelnen Parameter besteht, der oftmals nicht oder nur unzureichend bekannt ist. Auch kann eine exakte Analyse derart viel Rechenzeit in Anspruch nehmen, daß sie nicht mehr sinnvoll durchführbar ist. In derartigen Fällen kann beispielsweise die Analyse durch Hinweise vom Programmierer vereinfacht werden und/oder es kann anhand entsprechender Compilerschalter derart gearbeitet werden, daß im Zweifelsfall entweder von einer hohen Parallelisierbarkeit (ggf. unter Verschwendung von Ressourcen) oder von einer niederen Parallelisierbarkeit (ggf. unter Verschwendung von Performance) ausgegangen werden soll.
Ebenfalls kann in diesen Fällen eine empirische Analyse zur Laufzeit durchgeführt werden. Nach PACT10, PACT17 sind Verfahren bekannt, die zur Laufzeit die Erstellung von Statistiken über das Programmverhalten erlauben. Derart kann z. B. zunächst von einer maximalen Parallelisierbarkeit ausgegangen werden. Die einzelnen Pfade geben Meldungen an eine Statistikeinheit (z. B. implementiert in einer CT oder einer anderen Stufe, vgl. PACT10, PACT17, grundsätzlich können aber auch Einheiten nach PACT04 verwenden werden) über jeden Durchlauf zurück. Mittels statistischer Maßnahmen ist nunmehr auswertbar, welche Pfade tatsächlich parallel durchlaufen werden. Weiterhin ergibt sich die Möglichkeit, anhand der Daten zur Laufzeit zu bewerten, welche Pfade häufig oder selten oder nie parallel durchlaufen werden. Diese Art der Pfadnutzungsmeldung ist nicht zwingend, aber vorteilhaft.
Dementsprechend kann die Ausführung bei einem nächsten Programmaufruf optimiert werden. Daß dazu die Statistikinformation insbesondere nichtflüchtig, wie auf eine Festplatte weggeschrieben werden kann, sei erwähnt. Aus PACT22, PACT24 ist bekannt, daß mehrere Konfigurationen entweder zugleich konfiguriert werden können und danach durch Trigger (PACT08) angesteuert werden oder nur eine Untermenge konfiguriert ist und die restlichen Konfigurationen bei Bedarf dadurch nachgeladen werden, daß die entsprechenden Trigger an eine Ladeeinheit
(CT, PACT10 ) gesendet werden.
Der im folgenden gebrauchte Wert PAR (p) gibt zur Verdeutlichung an, welche Parallelität auf Instruktionsniveau, d. h . wieviel ILP bei einer bestimmten Stufe (p) innerhalb des aus der Funktion transformierten Datenflußgraphen erreichbar ist (Figur 7a) .
Gleichfalls bedeutsam ist Vektorparallelität (vgl. VEC{}). Vektorparallelität ist nutzbar, wenn größere Datenmengen zu verarbeiten sind. In diesem Fall sind lineare Folgen von Operationen vektorisierbar, d.h. alle Operationen können gleichzeitig Datenverarbeiten, wobei typischerweise jede separate Operation ein separates Datenwort bearbeitet.
Innerhalb von Schleifen ist dieses Vorgehen teilweise nicht möglich. Daher sind Analysen und Optimierungen notwendig. Beispielsweise kann der Graph einer Funktion durch ein Petri- netz ausgedrückt werden. Petri-Netze besitzen die Eigenschaft, daß die Ergebnisweitergabe von Knoten kontrolliert erfolgt, wodurch beispielsweise Schleifen modelliert werden können. Durch die Rückkopplung des Ergebnisses in einer Schleife wird der Datendurchsatz bestimmt. Beispiele:
• Das Ergebnis der Berechnung n wird für die Berechnung n+1 benötigt: Nur eine Berechnung kann innerhalb der Schleife ausgeführt werden.
• Das Ergebnis der Berechnung n wird für die Berechnung n+m benötigt: m-1 Berechnungen können innerhalb der Schleife ausgeführt werden.
• Das Ergebnis bestimmt den Abbruch der Schleife, geht aber nicht in die Berechnung der Ergebnisse ein: Eine Rückkopplung ist nicht notwendig. Ggf. laufen zwar falsche (zuviel) Werte in die Schleife, jedoch kann die Ausgabe der Ergebnisse direkt bei Erreichen der Endbedingung am Schleifenende unterbrochen werden.
Vor der Analyse von Schleifen können diese nach dem Stand der Technik optimiert werden. Beispielsweise können bestimmte In- struktionen aus der Schleife herausgezogen werden und vor oder nach die Schleife gestellt werden .
Der im Folgenden zur Verdeutlichung gebrauchte Wert VEC kann den Grad der Vektorisierbarkeit einer Funktion veranschaulichen . Mit anderen Worten zeigt VEC an, wieviele Datenworte zugleich innerhalb einer Menge von Operationen bearbeitet werden können . VEC kann beispielsweise aus der Zahl der benötigten Rechenwerke für eine Funktion nnodes und der zugleich innerhalb des Vektors berechenbaren Daten ndata berechnet werden, z . B . durch VEC = nnθdes / ndata
Ist eine Funktion beispielsweise auf 5 Rechenwerke abbildbar (nnodes = 5 ) und in j edem der Rechenwerke können zugleich Daten bearbeitet werden (n ata = 5 ) ist VEC = 1 ( Figur 7b ) . Ist eine Funktion dagegen beispielsweise auf 5 Rechenwerke abbildbar (nnodes = 5 ) und nur in einem Rechenwerk können j eweils Daten bearbeitet werden, z . B . aufgrund einer Rückkopplung der Ergebnisse der Pipeline auf den Eingang (ndata = 5 ) , so ist VEC = 1/5 ( Figur 7c) .
VEC kann für eine gesamte Funktion und/oder für Teilausschnitte einer Funktion berechnet werden . Für den erfindungsgemäßen Compiler können beide Varianten vorteilhaft sein, wie generell die Bestimmung und Auswertung von VEC vorteilhaft ist .
Gemäß Figur 7a wird PAR (p) für j ede Zeile eines Graphen bestimmt, wie vorteilhaft möglich . Eine Zeile eines Graphen ist dadurch definiert, daß sie innerhalb einer Takteinheit ausgeführt wird. Die Anzahl der Operationen ist von der Implementierung der j eweiligen VPU abhängig .
Entspricht PAR (p) der Anzahl der Knoten in der Zeile p, so können alle Knoten parallel ausgeführt werden . Ist PAR(p) kleiner, werden bestimmte Knoten nur alternativ ausgeführt. Die alternativen Ausführungen jeweils eines Knotens werden in jeweils einer PAE zusammengefaßt. Eine Selektionsvorrichtung ermöglicht die Aktivierung der, dem Status der Datenverarbeitung entsprechenden, Alternative zur Laufzeit wie beispielsweise in PACT08 beschrieben.
VEC wird ebenfalls jeder Zeile eines Graphen zugeordnet. Ist für eine Zeile VEC = 1, bedeutet dies, daß die Zeile als Pipelinestufe bestehen bleibt. Ist eine Zeile kleiner 1, so werden alle nachfolgenden Zeilen, die ebenfalls kleiner 1 sind zusammengefaßt, da ein Pipelining nicht möglich ist. Entsprechend der Reihenfolge der Operationen werden diese zu einer Sequenz zusammengefaßt, die dann in eine PAE konfiguriert wird und zur Laufzeit sequentiell abgearbeitet wird. Entsprechende Verfahren sind beispielsweise aus PCT/DE 97/02949 und/oder PCT/DE 97/02998 bekannt.
Durch das beschriebene Verfahren lassen sich durch Gruppierungen von Sequenzern beliebig komplexe Parallelprozessormodelle aufbauen. Insbesondere sind Sequenzerstrukturen zur Abbildung von reentrantem Code generierbar.
Die dazu jeweils notwendigen Synchronisationen können beispielsweise durch das in PACT18 beschriebene TimeStamp- Verfahren oder bevorzugt durch das in PACT08 beschriebene Triggerverfahren durchgeführt werden.
Werden mehrere Sequenzer oder sequentielle Teile auf ein PA abgebildet, ist es aus Leistungsverbrauchsgründen bevorzugt, die Leistung der einzelnen Sequenzer aufeinander abzustimmen. Dies kann besonders bevorzugt derart geschehen, daß die Arbeitsfrequenzen der Sequenzer aneinander angepaßt werden. Aus PACT25 und PACT18 sind beispielsweise Verfahren bekannt, die eine individuelle Taktung von einzelnen PAEs oder PAE-Gruppen zulassen. Die Frequenz eines Sequenzers kann dabei anhand der Anzahl von Zyklen bestimmt werden, die er typischerweise zur Abarbeitung der ihm zugewiesenen Funktion benötigt.
Benötigt er beispielsweise 5 Taktzyklen zur Abarbeitung seiner Funktion während das restliche System genau einen Taktzyklus benötigt, um zugewiesene Aufgaben abzuarbeiten, sollte seine Taktung 5-mal höher sein als die Taktung des restlichen Systems. Bei einer Vielzahl von Sequenzern sind jeweils unterschiedliche Taktzyklen möglich. Es kann eine Taktvervielfachung und/oder eine Taktteilung vorgesehen werden.
Funktionen werden entsprechend des vorgenannten Verfahrens partitioniert . Beim Partitionieren werden entsprechend Speicher für Daten und relevanten Status eingefügt. Weitere alternative und/oder weitergehende Verfahren sind aus PACT13 und PACT18 bekannt.
Manche VPUs bieten nach PACT01, PACT10, PACT13, PACT17, PACT22, PACT24 die Möglichkeit der differentiellen Rekonfiguration. Diese kann angewendet werden, wenn nur verhältnismäßig wenige Änderungen innerhalb der Anordnung von PAEs bei einer Rekonfiguration notwendig werden. Mit anderen Worten werden nur die Veränderungen einer Konfiguration gegenüber der aktuellen Konfiguration rekonfiguriert. Die Partitionierung kann in diesem Fall -dergestalt sein, daß die auf eine Konfiguration folgenden (differentielle) Konfiguration nur die notwendigen Rekonfigurationsdaten enthält und keine vollständige Konfiguration darstellt. Der Compiler der vorliegenden Erfindung ist bevorzugt dazu ausgebildet, dies zu erkennen und zu unterstützen.
Das Scheduling der Rekonfiguration kann durch den Status erfolgen, der Funktion (en) an eine Ladeeinheit (CT) meldet, welche ihrerseits auf Basis des eingehenden Status die nächste Konfiguration oder Teilkonfiguration auswählt und konfigu- riert. Im Detail sind derartige Verfahren aus PACT01, PACT05,
PACT10, PACT13, PACT17 bekannt.
Weiterhin kann das Scheduling die Möglichkeit des Vorladens von Konfigurationen während de"r Laufzeit einer anderen Konfiguration unterstützen. Dabei können mehrere Konfigurationen möglicherweise auch spekulativ vorgeladen werden, d.h. ohne daß sichergestellt ist, daß die Konfigurationen überhaupt benötigt werden. Dies ist besonders dann bevorzugt, wenn die CT etwa bei längeren, konfigurationsfrei abarbeitbaren Datenströmen zumindest weitgehend unbelastet ist und insbesondere nicht oder nur wenig aufgabenbelastet ist. Durch Selektionsmechanismen wie etwa nach DE 197 04 728.9 werden dann zur Laufzeit die zu verwendenden Konfigurationen ausgewählt (siehe auch Beispiel NLS in PACT22/24) .
Ebenfalls können die lokalen Sequenzer durch den Status ihrer Datenverarbeitung gesteuert werden, wie etwa aus DE 196 51 075.9-53, DE 196 54 846.2-53, DE 199 26 538.0 bekannt. Zur Durchführung ihrer Rekonfiguration kann ein weiterer abhängiger oder unabhängiger Status an die CT gemeldet werden (siehe beispielsweise PACT04, LLBACK) .
Das Vorstehende wird nun mit Bezug auf weitere Figuren beschrieben. Dabei werden im folgenden folgende Zeichen zur Vereinfachung der Schreibung verwendet: v oder, Λ und.
Figur 8a zeigt die Abbildung des Graphens nach Fig. 7a auf eine Gruppe von PAEs bei maximaler erreichbarer Parallelität. Sämtliche Operationen (Instruktion il-il2) sind in einzelne PAEs abgebildet.
Figur 8b zeigt denselben Graphen, beispielsweise mit maximaler nutzbarer Vektorisierbarkeit . Jedoch sind die Mengen von Operationen V2={il, i3}, V3={i4, i5, i6, i7, i8}, V4={i9, ilO, ill} nicht parallel par (par ( {2, 3, 4 } ) = 1. Damit lassen sich Ressourcen einsparen, indem jeweils eine Menge P2, P3, P4 von Operationen einer PAE zugeordnet wird. Ein Statussignal zu jedem Datenwort in jeder Stufe wählt die auszuführende Operation in der jeweiligen PAE aus. Die* PAEs sind als Pipeline (Vektor) vernetzt und jede PAE führt je Takt eine Operation über jeweils unterschiedliche Datenwort aus.
Es ergibt sich folgender Ablauf:
PAE1 berechnet Daten und gibt diese an PAE2 weiter. Zusammen mit den Daten gibt sie ein Statussignal weiter, das anzeigt, ob il oder i2 ausgeführt werden soll.
PAE2 berechnet die Daten von PAE1 weiter. Entsprechend des eingehenden Statussignals wird die auszuführende Operation
(il, i2) ausgewählt und berechnet. Entsprechend der Berechnung gibt PAE2 ein Statussignal an PAE3 weiter, das anzeigt, ob (i4 v i5) v (i6 v i7 v i8) ausgeführt werden soll.
PAE3 berechnet die Daten von PAE2 weiter. Entsprechend des eingehenden Statussignals wird die auszuführende Operation (i4 v i5) v (i6 v i7 v i8) ausgewählt und berechnet. Entsprechend der Berechnung gibt PAE3 ein Statussignal an PAE4 weiter, das anzeigt ob i9 v ilO v ill ausgeführt werden soll.
PAE4 berechnet die Daten von PAE3 weiter. Entsprechend des eingehenden Statussignals wird die auszuführende Operation i9 v ilO v ill ausgewählt und berechnet.
PAE5 berechnet die Daten von PAE4 weiter.
Ein mögliches entsprechendes Verfahren und Hardware, die eine besonders günstige Umsetzung des beschriebenen erlaubt, ist in DE 197 04 728.9 (Figuren 5 und 6) beschrieben; auch PACT04 und PACT10, PACT13 beschreiben allgemein nutzbare, jedoch aufwendigere Verfahren.
Figur 8c zeigt wiederum denselben Graphen. In diesem Beispiel ist eine Vektorisierung nicht möglich, jedoch ist PAR(p) hoch, was bedeutet, daß innerhalb einer Zeile jeweils eine Vielzahl von Operationen gleichzeitig ausgeführt werden kann. Die parallel durchführbaren Operationen sind P2 = {il Λ i2}, P3 = {i4 Λ i5 Λ i6 Λ i7 Λ i8}, P4 =± {i9 Λ ilO Λ ill}. Die PAEs sind derart vernetzt, daß sie beliebige Daten beliebig untereinander austauschen können. Die einzelnen PAEs führen nur dann Operationen durch, wenn im entsprechenden Zyklus ein ILP besteht, ansonsten verhalten sie sich neutral (NOP) , wobei ggf. Heruntertaktung und/oder eine Takt- und/oder Stromabschaltung zur Minimierung der Verlustleistung erfolgen kann. Es ist dabei folgender Ablauf vorgesehen:
Im ersten Zyklus arbeitet nur PAE2 und gibt die Daten an PAE2 und PAE3 weiter.
Im zwei ten Zyklus arbeiten PAE2 und PAE3 parallel und geben ihre Daten an PAE1, PAE2, PAE3, PAE4, PAE5 weiter. Im dritten Zyklus arbeiten PAE1, PAE2, PAE3, PAE4, PAE5 und geben die Daten an PÄE2, PAE3, PAE5 weiter.
Im vierten Zyklus arbeiten PAE2, PAE3, PAE5 und geben die Daten an PAE2 weiter. Im fünften Zyklus arbeitet nur PAE2.
Die Funktion benötigt somit 5 Zyklen zur Berechnung. Der entsprechende Sequenzer sollte also mit dem 5-fachen Takt im Verhältnis zu seiner Umgebung arbeiten, um eine entsprechende Performance zu erzielen.
Ein mögliches entsprechendes Verfahren ist in PACT02 (Figuren 19, 20 und 21) beschrieben; auch PACT04 und PACT10, 13 beschreiben allgemein nutzbare, jedoch aufwendigere Verfahren. Weitere Verfahren und/oder Hardware sind verwendbar.
Figur 8d zeigt den Graphen nach Fig. 7a für den Fall, daß keinerlei nutzbare Parallelität besteht. Zur Berechnung eines Datenwortes muß jede Stufe nacheinander durchlaufen werden. In- nerhalb der Stufen wird immer nur genau einer der Zweige verarbeitet.
Die Funktion benötigt ebenfalls 5 Zyklen zur Berechnung, cyl = (il), cy2 = (i2 v i3) , cy3 = fi4 v i5 v iβ v i7 v i8), cy4 = (i9 v ilO v ill) , cy5 = (il2) . Der entsprechende Sequenzer sollte also mit dem 5-fachen Takt im Verhältnis zu seiner Umgebung arbeiten, um eine entsprechende Performance zu erzielen.
Eine derartige Funktion ist beispielsweise ähnlich Fig. 8c durch einen einfachen Sequenzer nach PACT02 ( Figuren 19, 20 und 21) abbildbar. Auch PACT04 und PACT10, 13 beschreiben allgemein nutzbare, jedoch aufwendigere Verfahren.
Die in Figur 8 dargestellten Abbildungen sind beliebig mischbar und gruppierbar. In Figur 9a ist beispielsweise dieselbe Funktion dargestellt, bei welcher die Pfade (i2 Λ (i4 v i5) Λ i9) und (i3 Λ (iβ v i7 v 18) Λ (i9 v ilO)) parallel ausführbar sind. (i4 v i5) , iβ v 17 v i8), (i9 v ilO) sind jeweils alternativ. Die Funktion ist weiterhin vektorisierbar. Damit last sich eine Pipeline aufbauen, in welcher für 3 PAEs (PAE4, PAE5, PAE7) jeweils anhand von Statussignalen die jeweilig auszuführende Funktion bestimmt ist.
Figur 9b zeigt ein ähnliches Beispiel, bei dem eine Vektori- sierung nicht möglich ist. Allerdings sind die Pfade (il Λ ±2 Λ (i4 v i5) Λ 19 Λ il2) und (i3 Λ (iβ v i7 v i8) Λ (ilO v ill)) parallel. Damit läßt sich die optimale Performance durch den Einsatz von zwei PAEs erzielen, die bei die parallelen Pfade auch parallel abarbeiten. Die Synchronisation der PAEs untereinander erfolgt durch Statussignale, die vorzugsweise von PAE1 generiert werden, da diese den Beginn (il) und das Ende (il2) der Funktion berechnet. Es soll besonders darauf hingewiesen werden, daß sich aus einer mehrfachen Anordnung von Sequenzern ein symetrisch paralleles Prozessormodell (SMP) oder ähnliche, heute verwendete Mehrprozessormodelle ergeben können.
Weiterhin soll darauf hingewiesen werden, daß sämtliche Konfigurationsregister für das Scheduling auch im Hintergrund und/oder während der Datenverarbeitung mit neuen Konfigurationen geladen werden können.
Es ist dies etwa möglich, wenn die Hardware wie nach DE 196 51 075.9-53 bekannt aufgebaut ist. Es stehen dann unabhängige Speicherbereiche oder Register zur Verfügung, die unabhängig angesprochen werden können. Auf bestimmte Stellen wird durch eingehende Trigger gesprungen, ebenfalls kann mittels Sprungbefehlen (JMP, CALL/RET) , die ggf. auch bedingt durchführbar sind gesprungen werden.
Gemäß DE 196 54 846.2-53 stehen unabhängige Schreib- und Lesezeiger zur Verfügung, wodurch grundsätzlich eine Unabhängigkeit und somit die Möglichkeit des Zugriffes im Hintergrund gegeben ist. Insbesondere ist es möglich, die Speicher zu seg- mentieren, wodurch eine zusätzliche Unabhängigkeit gegeben ist. Mittels Sprungbefehlen (JMP, CALL/RET), die ggf. auch bedingt durchführbar sind, kann gesprungen werden.
Nach DE 197 04 728.9 sind die einzelnen Register, die durch die Trigger gewählt werden können, grundsätzlich unabhängig und erlauben daher eine unabhängige Konfiguration, insbesondere im Hintergrund. Sprünge innerhalb der Register sind nicht möglich, die Auswahl erfolgt ausschließlich über die Triggervektoren. Ein wesentlicher Faktor zur Bewertung der Effizienz von PAR und VEC ist die Art der Daten die durch die jeweilige Struktur verarbeitet werden. Beispielsweise ist es lohnen eine Struktur auszuwalzen, also zu pipelinen* und oder parallelisieren, die eine große Menge von Daten verarbeitet; wie es z.B. bei Videodaten oder Telekomdaten der Fall ist. Strukturen die wenige Daten verarbeiten (z.B. Tastatureingabe, Maus, etc.) lohnen sich nicht ausgewalzt zu werden, im Gegenteil sie würden nur anderen Algorithmen die Ressourcen blockieren.
Somit wird vorgeschlagen anhand unterschiedlicher Hinweise nur die Algorithmen, Strukturen oder Teile von Algorithmen zu par- allelisiern und vektorisieren, die entsprechend große Datenmengen Verarbeiten. Derartige Hinweise können beispielsweise sein:
1. Der Datentyp (Arrays, Streams sollten z.B. aufgrund der hohen Datenmenge eher ausgewalzt werden als z.B. einzelne Zeichen) .
2. Die Art des Zugriffes (lineare Programmabfolgen sollten z.B. in Sequenzer abgebildet werden, während Schleifen sich z.B. aufgrund der hohen Anzahl von Durchläufen zum Auswalzen lohnen.
3. Die Art der Quelle und/oder des Ziels (Tastatur und Maus haben z.B. eine zu geringe Datenrate um effizient ausgewalzt zu werden, dagegen ist z.B. die Datenrate bei Netzwerk und/oder Video Quellen oder Zielen deutlich höher) .
Für die Analyse können dabei eine beliebige Menge dieser Hinweise hinzugezogen werden.
7. Begri fsdefinition lokal relevanter Zustand Zustand, der nur innerhalb einer bestimmten Konfiguration relevant ist;
global relevanter Zustand Zustand, der in mehreren Konfigurationen relevant ist und zwischen den Konfigurationen ausgetauscht werden muß;
relevanter Zustand Zustand, der innerhalb eines Algorithmus zu dessen korrekter Ausführung dessen benötigt wird und somit durch den Algorithmus beschrieben ist und davon verwendet wird;
irrelevanter Zustand Zustand, der für den eigentlichen Algorithmus ohne Bedeutung ist und auch nicht im Algorithmus beschrieben ist, der jedoch von der ausführenden Hardware implementierungsabhängig benötigt wird

Claims

Patentansprüche
1. Verfahren zum Übersetzen on Hochsprachen auf rekonfigurierbare Architekturen, dadurch gekennzeichnet, daß ein endlicher Automat zur Berechnung derart aufgebaut wird, daß ein komplexes kombinatorisches Netz aus einzelnen Funktionen gebildet wird und dem Netz Speicher zur Speicherung der Operanden und Ergebnissen zugeordnet sind.
2. Verfahren zum Datenbe- und/oder Verarbeitung mit einem multidimensionalen Feld mit rekonfigurierbaren ALUs, dadurch gekennzeichnet, daß ein Hochsprachencode vorgesehen und derart übersetzt wird, daß ein endlicher Automat zur Berechnung aufgebaut wird, wobei ein komplexes kombinatorisches Netz aus einzelnen Funktionen gebildet und dem Netz Speicher zur Speicherung der Operanden und/oder Ergebnisse zugeordnet werden.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das komplexe kombinatorische Netz so aufgebaut und/oder zerlegt wird, daß die PAE-Matrix möglichst lange ohne Rekonfiguration betrieben wird.
4. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß komplexe Instruktionen bestimmt werden, um das komplexe kombinatorische Netz so aufzubauen und/oder zu zerlegen, daß die PAE-Matrix 'möglichst lange ohne Rekonfiguration betrieben wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein endlicher Automat direkt aus imperativem Quelltext aufgebaut wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein endlicher Automat aus an grobgranu- lare Logikkreise und/oder an vorhandene feingranulare Elemente (FPGA-Zellen in der /VPU, statemachines etc.) angepaßte Operationen aufgebaut wird, insbesondere ausschließlich an solche.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein endlicher Automat dann in Konfigurationen zerlegt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß generierte Konfigurationen succesive auf die PAE-Matrix abgebildet werden und Arbeitsdaten und/oder Zustände, die zwischen den Konfigurationen zu übertragen sind, in Speicher abgelegt werden.
9. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß der Speicher vom Compiler bestimmt beziehungsweise vorgesehen wird.
10. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß während einer Konfiguration Daten aus einer VPU externen Quelle und/oder einem internen Speicher verarbeitet und an eine externe Quelle und/oder einen internen Speicher geschrieben werden.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein Speicher für einen gesamten Datensatz vorgesehen wird, der umfangreicher als ein einzelnes Datenwort ist.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei Verarbeitung einer ablaufenden Kon- figuration Daten compilerbestimmt in die Speicher abgelegt werden.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein Speicher für Operanden, ein Speicher für Ergebnisse und ein Netzwerk aus Zuweisungen und/oder Vergleichen-Anweisungen, also Bedingungen wie z.B. IF, CASE, Schleifen (WHILE, FOR, REPEAT) sowie optionalen Adressgenerator (en) zur Ansteuerung der Speicher mit dem Automaten vorgesehen werden.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß Zuständen wie erforderlich Speicher zugeordnet werden, und hierbei zwischen algorithmisch relevanten und irrelevanten Zuständen unterschieden wird, insbesondere solchen relevanten Zuständen, die innerhalb des Algorithmus notwendig um dessen korrekte Funktion zu beschreiben und solchen irrelevante Zustände, die durch die verwendete Hardware und/oder die gewählte Abbildung oder aus anderen sekundären Gründen entstehen.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß Load/Store Operationen unter Vorsehen einer externen Adressierung, also des Datentransfers mit externen Baugruppen und einer interne Adressierung, also die Datentransfers zwischen PAEs, i.b. zwischen RAM-PAEs und ALU-PAEs vorgesehen werden.
16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei der Datenverarbeitung eine erste Konfiguration entfernt wird und die zu sichernden Daten in entsprechenden Speichern (REG) (Speicher, Register, Zähler, etc) verbleiben.
17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die erste Konfiguration wieder geladen wird und auf die zuvor gesicherterten, ihr zugeordnete Daten zugreift.
18. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß für den Zugriff auf zuvor gesicherterte Daten eine zweite Konfiguration geladen wird, die die REG in geeigneter Weise und definierter Reihenfolge mit einem oder mehreren globalen Speicher (n) verbindet, insbesondere, um unter Verwendung von Adressgeneratoren auf den/die globalen Speicher zuzugreifen, wobei der Adressgenerator die Adressen für den/die globalen Speicher (n) bevorzugt derart generiert, dass die beschriebenen Speicherbereiche (PUSHAREA) der entfernten ersten Konfiguration eindeutig zugeordnet werden können.
19. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß automatisch Transformation zur Repräsentation der Parallelisier- bzw. Vektorisierbarkeit (Par- Vec-Transformation) durchgeführt werden und/oder VEC und PAR-Anteile als Petri-Netz ausgestaltet werden, um wie bevorzugt die Weiterverarbeitung nach kompletter Verarbeitung der jeweiligen Inhalte zu steuern.
20. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß arithmetisch/logische Befehle direkt in das kombinatorische Netz abgebildet werden und/oder
Sprünge (Jump/Call) entweder direkt in das kombinatorische Netz ausgewalzt und/oder durch Rekonfiguration realisiert werden und/oder
Bedingungen und Kontrollflußbefehle (if, etc) entweder im kombinatorischen Netz vollständig aufgelöst und /oder bearbeitet werden und/oder an eine übergeordnete Konfigurati- onseinheit weitergeleitet werden, die sodann entsprechend des entstandenen Status eine Rekonfiguration durchführt und/oder
Load/Store-Operationen in /separate Konfigurationen abgebildet und/oder durch Adressgeneratoren realisiert werden, die internen Speicher (REGO) mittels Adressgeneratoren in externe Speicher schreiben und/oder diese von externen Speichern und/oder Peripherie laden und/oder Register-Move-Operationen im kombinatorischen Netz durch Busse zwischen den internen Speichern (REGO) realisiert werden und/oder
Push/Pop-Operationen durch separate Konfigurationen realisiert werden, die bestimmte interne Register im kombinatorischen Netz und/oder die internen Speicher (REGO) mittels Adressgeneratoren in externe Speicher schreiben oder aus externen Speichern lesen und die bevorzugt vor oder nach den eigentlichen datenverarbeitenden Konfigurationen ausgeführt werden.
PCT/EP2002/010065 2001-08-16 2002-08-16 Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen WO2003017095A2 (de)

Priority Applications (26)

Application Number Priority Date Filing Date Title
EP02774585A EP1493084A2 (de) 2001-08-16 2002-08-16 Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen
CA002458199A CA2458199A1 (en) 2001-08-16 2002-08-16 Method for the translation of programs for reconfigurable architectures
AU2002340879A AU2002340879A1 (en) 2001-08-16 2002-08-16 Method for the translation of programs for reconfigurable architectures
US10/486,771 US7996827B2 (en) 2001-08-16 2002-08-16 Method for the translation of programs for reconfigurable architectures
JP2003521938A JP2005508029A (ja) 2001-08-16 2002-08-16 リコンフィギュアラブルアーキテクチャのためのプログラム変換方法
EP03720231A EP1518186A2 (de) 2002-03-21 2003-03-21 Verfahren und vorrichtung zur datenverarbeitung
AU2003223892A AU2003223892A1 (en) 2002-03-21 2003-03-21 Method and device for data processing
US10/508,559 US20060075211A1 (en) 2002-03-21 2003-03-21 Method and device for data processing
PCT/DE2003/000942 WO2003081454A2 (de) 2002-03-21 2003-03-21 Verfahren und vorrichtung zur datenverarbeitung
AU2003286131A AU2003286131A1 (en) 2002-08-07 2003-07-23 Method and device for processing data
PCT/EP2003/008081 WO2004021176A2 (de) 2002-08-07 2003-07-23 Verfahren und vorrichtung zur datenverarbeitung
EP03776856.1A EP1537501B1 (de) 2002-08-07 2003-07-23 Verfahren und vorrichtung zur datenverarbeitung
EP03784053A EP1535190B1 (de) 2002-08-07 2003-07-24 Verfahren zum gleichzeitigen Betreiben eines sequenziellen Prozessors und eines rekonfigurierbaren Arrays
US10/523,764 US8156284B2 (en) 2002-08-07 2003-07-24 Data processing method and device
PCT/EP2003/008080 WO2004015568A2 (en) 2002-08-07 2003-07-24 Data processing method and device
AU2003260323A AU2003260323A1 (en) 2002-08-07 2003-07-24 Data processing method and device
JP2005506110A JP2005535055A (ja) 2002-08-07 2003-07-24 データ処理方法およびデータ処理装置
US12/570,943 US8914590B2 (en) 2002-08-07 2009-09-30 Data processing method and device
US12/621,860 US8281265B2 (en) 2002-08-07 2009-11-19 Method and device for processing data
US12/729,090 US20100174868A1 (en) 2002-03-21 2010-03-22 Processor device having a sequential data processing unit and an arrangement of data processing elements
US12/729,932 US20110161977A1 (en) 2002-03-21 2010-03-23 Method and device for data processing
US12/947,167 US20110238948A1 (en) 2002-08-07 2010-11-16 Method and device for coupling a data processing unit and a data processing array
US13/177,820 US8869121B2 (en) 2001-08-16 2011-07-07 Method for the translation of programs for reconfigurable architectures
US14/162,704 US20140143509A1 (en) 2002-03-21 2014-01-23 Method and device for data processing
US14/540,782 US20150074352A1 (en) 2002-03-21 2014-11-13 Multiprocessor Having Segmented Cache Memory
US14/923,702 US10579584B2 (en) 2002-03-21 2015-10-27 Integrated data processing core and array data processor and method for processing algorithms

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
DE10139170.6 2001-08-16
DE10139170 2001-08-16
DE10142903 2001-09-03
DE10142903.7 2001-09-03
DE10144732.9 2001-09-11
DE10144732 2001-09-11
DE10145792 2001-09-17
DE10145792.8 2001-09-17
US09/967,847 US7210129B2 (en) 2001-08-16 2001-09-28 Method for translating programs for reconfigurable architectures
US09/967,847 2001-09-28
DE10154260 2001-11-05
DE10154260.7 2001-11-05
DE10207225.6 2002-02-21
DE10207225 2002-02-21
PCT/EP2002/002398 WO2002071248A2 (de) 2001-03-05 2002-03-05 Verfahren und vorrichtungen zur datenbe- und/oder verarbeitung
EPPCT/EP02/02398 2002-03-05
EP0209131 2002-08-15
EPPCT/EP02/09131 2002-08-15

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10486771 A-371-Of-International 2002-08-16
US13/177,820 Continuation US8869121B2 (en) 2001-08-16 2011-07-07 Method for the translation of programs for reconfigurable architectures

Publications (2)

Publication Number Publication Date
WO2003017095A2 true WO2003017095A2 (de) 2003-02-27
WO2003017095A3 WO2003017095A3 (de) 2004-10-28

Family

ID=41210636

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2002/010065 WO2003017095A2 (de) 2001-08-16 2002-08-16 Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen

Country Status (4)

Country Link
JP (1) JP2005508029A (de)
AU (1) AU2002340879A1 (de)
CA (1) CA2458199A1 (de)
WO (1) WO2003017095A2 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AT501479B1 (de) * 2003-12-17 2006-09-15 On Demand Informationstechnolo Digitale rechnereinrichtung
EP2043000A2 (de) 2002-02-18 2009-04-01 PACT XPP Technologies AG Bussysteme und Rekonfigurationsverfahren
US9037807B2 (en) 2001-03-05 2015-05-19 Pact Xpp Technologies Ag Processor arrangement on a chip including data processing, memory, and interface elements
US9075605B2 (en) 2001-03-05 2015-07-07 Pact Xpp Technologies Ag Methods and devices for treating and processing data

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6542998B1 (en) 1997-02-08 2003-04-01 Pact Gmbh Method of self-synchronization of configurable elements of a programmable module
US7996827B2 (en) 2001-08-16 2011-08-09 Martin Vorbach Method for the translation of programs for reconfigurable architectures
US8914590B2 (en) 2002-08-07 2014-12-16 Pact Xpp Technologies Ag Data processing method and device
DE102005005073B4 (de) * 2004-02-13 2009-05-07 Siemens Ag Rechnereinrichtung mit rekonfigurierbarer Architektur zur parallelen Berechnung beliebiger Algorithmen
JP5141151B2 (ja) * 2007-09-20 2013-02-13 富士通セミコンダクター株式会社 動的再構成回路およびループ処理制御方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999000731A1 (en) * 1997-06-27 1999-01-07 Chameleon Systems, Inc. Method for compiling high level programming languages
US6058469A (en) * 1995-04-17 2000-05-02 Ricoh Corporation System and method for dynamically reconfigurable computing using a processing unit having changeable internal hardware organization

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6058469A (en) * 1995-04-17 2000-05-02 Ricoh Corporation System and method for dynamically reconfigurable computing using a processing unit having changeable internal hardware organization
WO1999000731A1 (en) * 1997-06-27 1999-01-07 Chameleon Systems, Inc. Method for compiling high level programming languages

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ATHANAS P M ET AL: "An adaptive hardware machine architecture and compiler for dynamic processor reconfiguration" PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON COMPUTER DESIGN - VLSI IN COMPUTERS AND PROCESSORS. CAMBRIDGE, MA., OCT. 14 - 16, 1991, LOS ALAMITOS, IEEE. COMP. SOC. PRESS, US, 14. Oktober 1991 (1991-10-14), Seiten 397-400, XP010025243 ISBN: 0-8186-2270-9 *
BAUMGARTE V ET AL: "PACT XPP - A Self-Reconfigurable Data Processing Architecture" ., 25. Juni 2001 (2001-06-25), XP002256066 *
CARDOSO J M P ET AL: "Macro-based hardware compilation of Java<TM> bytecodes into a dynamic reconfigurable computing system" FIELD-PROGRAMMABLE CUSTOM COMPUTING MACHINES, 1999. FCCM '99. PROCEEDINGS. SEVENTH ANNUAL IEEE SYMPOSIUM ON NAPA VALLEY, CA, USA 21-23 APRIL 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 21. April 1999 (1999-04-21), Seiten 2-11, XP010359161 ISBN: 0-7695-0375-6 *
WEINHARDT M: "ÜBERSETZUNGSMETHODEN FÜR STRUKTURPROGRAMMIERBARE RECHNER" DISSERTATION UNIVERSITY KARLSRUHE, XX, XX, Juli 1997 (1997-07), Seiten 1-134, XP002254220 *
YE Z A ET AL: "A C COMPILER FOR A PROCESSOR WITH A RECONFIGURABLE FUNCTIONAL UNIT" FPGA'00. ACM/SIGDA INTERNATIONAL SYMPOSIUM ON FIELD PROGRAMMABLE GATE ARRAYS. MONTEREY, CA, FEB. 9 - 11, 2000, ACM/SIGDA INTERNATIONAL SYMPOSIUM ON FIELD PROGRAMMABLE GATE ARRAYS, NEW YORK, NY : ACM, US, Bd. CONF. 8, 9. Februar 2000 (2000-02-09), Seiten 95-100, XP000970736 ISBN: 1-58113-193-3 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9037807B2 (en) 2001-03-05 2015-05-19 Pact Xpp Technologies Ag Processor arrangement on a chip including data processing, memory, and interface elements
US9075605B2 (en) 2001-03-05 2015-07-07 Pact Xpp Technologies Ag Methods and devices for treating and processing data
EP2043000A2 (de) 2002-02-18 2009-04-01 PACT XPP Technologies AG Bussysteme und Rekonfigurationsverfahren
AT501479B1 (de) * 2003-12-17 2006-09-15 On Demand Informationstechnolo Digitale rechnereinrichtung
AT501479B8 (de) * 2003-12-17 2007-02-15 On Demand Informationstechnolo Digitale rechnereinrichtung

Also Published As

Publication number Publication date
WO2003017095A3 (de) 2004-10-28
JP2005508029A (ja) 2005-03-24
AU2002340879A1 (en) 2003-03-03
CA2458199A1 (en) 2003-02-27

Similar Documents

Publication Publication Date Title
EP2224330B1 (de) Verfahren und gerät zum partitionieren von grossen rechnerprogrammen
EP1228440B1 (de) Sequenz-partitionierung auf zellstrukturen
US7996827B2 (en) Method for the translation of programs for reconfigurable architectures
DE69826700T2 (de) Kompilerorientiertes gerät zur parallelkompilation, simulation und ausführung von rechnerprogrammen und hardwaremodellen
DE102018005172A1 (de) Prozessoren, verfahren und systeme mit einem konfigurierbaren räumlichen beschleuniger
DE102018126650A1 (de) Einrichtung, verfahren und systeme für datenspeicherkonsistenz in einem konfigurierbaren räumlichen beschleuniger
US7870556B2 (en) Managing computing resources in graph-based computations
DE102018006735A1 (de) Prozessoren und Verfahren für konfigurierbares Clock-Gating in einem räumlichen Array
DE102018006889A1 (de) Prozessoren und Verfahren für bevorzugte Auslegung in einem räumlichen Array
DE102018005216A1 (de) Prozessoren, Verfahren und Systeme für einen konfigurierbaren, räumlichen Beschleuniger mit Transaktions- und Wiederholungsmerkmalen
DE102018005169A1 (de) Prozessoren und verfahren mit konfigurierbaren netzwerkbasierten datenflussoperatorschaltungen
DE102018005181A1 (de) Prozessoren, Verfahren und Systeme für einen konfigurierbaren, räumlichen Beschleuniger mit Leistungs-, Richtigkeits- und Energiereduktionsmerkmalen
DE102018126150A1 (de) Einrichtung, verfahren und systeme für multicast in einem konfigurierbaren räumlichen beschleuniger
DE10028397A1 (de) Registrierverfahren
DE102005021749A1 (de) Verfahren und Vorrichtung zur programmgesteuerten Informationsverarbeitung
DE102008005515A1 (de) Virtuelle Architektur und virtueller Befehlssatz für die Berechnung paralleler Befehlsfolgen
DE19926538A1 (de) Hardware und Betriebsverfahren
EP1518186A2 (de) Verfahren und vorrichtung zur datenverarbeitung
WO2003017095A2 (de) Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen
Kirchhoff et al. A real-time capable dynamic partial reconfiguration system for an application-specific soft-core processor
EP1116129A2 (de) Konfigurierbarer hardware-block
EP1483682A2 (de) Reconfigurierbarer prozessor
EP1493084A2 (de) Verfahren zum übersetzen von programmen für rekonfigurierbare architekturen
WO2003071418A2 (de) Übersetzungsverfahren
Luk Customising processors: design-time and run-time opportunities

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ CZ DE DE DK DK DM DZ EC EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GM HR HU ID IL IN IS JP KE KG KP KZ LC LK LR LS LT LU LV MA MD MK MN MW MX MZ NO NZ OM PH PT RO RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG AE AG AL AM AT AZ BA BB BG BR BY BZ CA CH CN CO CR CZ DE DK DM DZ EC EE ES FI GB GD GE GM HR HU ID IL IN IS JP KE KG KP KR KZ LK LR LS LT LU LV MA MD MG MK MN MX MZ NO NZ OM PH PL PT RO RU SD SE SI SK SL TJ TM TN TR TT TZ UA UG UZ VC YU ZA ZM ZW GH GM KE LS MW MZ SL SZ TZ UG ZM ZW

121 Ep: the epo has been informed by wipo that ep was designated in this application
REEP Request for entry into the european phase

Ref document number: 2002774585

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2002774585

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2458199

Country of ref document: CA

Ref document number: 2003521938

Country of ref document: JP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 10486771

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2002774585

Country of ref document: EP