WO2007143972A2 - Prozessor mit internem raster von ausführungseinheiten - Google Patents

Prozessor mit internem raster von ausführungseinheiten Download PDF

Info

Publication number
WO2007143972A2
WO2007143972A2 PCT/DE2007/001022 DE2007001022W WO2007143972A2 WO 2007143972 A2 WO2007143972 A2 WO 2007143972A2 DE 2007001022 W DE2007001022 W DE 2007001022W WO 2007143972 A2 WO2007143972 A2 WO 2007143972A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
execution
configuration
execution units
alu
Prior art date
Application number
PCT/DE2007/001022
Other languages
English (en)
French (fr)
Other versions
WO2007143972A3 (de
Inventor
Sascha Uhrig
Original Assignee
Universität Augsburg
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
Application filed by Universität Augsburg filed Critical Universität Augsburg
Priority to US12/304,655 priority Critical patent/US20090249028A1/en
Publication of WO2007143972A2 publication Critical patent/WO2007143972A2/de
Publication of WO2007143972A3 publication Critical patent/WO2007143972A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7867—Architectures of general purpose stored program computers comprising a single central processing unit with reconfigurable architecture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3889—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by multiple instructions, e.g. MIMD, decoupled access or execute
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3893—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator
    • G06F9/3895—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator for complex operations, e.g. multidimensional or interleaved address generators, macros
    • G06F9/3897—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator for complex operations, e.g. multidimensional or interleaved address generators, macros with adaptable data path

Definitions

  • the present invention relates to a processor for processing sequential programs.
  • Such processors operate on a sequence of instructions that are executed sequentially.
  • the commands are individually decoded and then executed in so-called execution units.
  • the execution units are arranged one-dimensionally in conventional processors, for example in superscalar or VLIW processors. These execution units can therefore be assigned in a clock only commands that are completely independent of each other. Only after their execution dependent commands can be assigned in the next clock and therefore only then executed.
  • Tiled architectures combine the approach of a traditional processor with array structures of reconfigurable systems.
  • the array structures usually comprise a two-dimensional one
  • reconfigurable systems consist of a central, generally two-dimensional, more or less homogeneous arrangement of working elements.
  • the work items which are more or less specialized, are assigned a task during a configuration phase. Through data paths, the work items are linked together and can exchange data. These data paths are usually already set or programmed during the configuration phase.
  • the configuration data is read in advance in reconfigurable systems, i. H. already during the programming of the entire system, explicitly created. This is done manually in practice with the help of suitable synthesis tools. Through a special mechanism, the configuration data is loaded at runtime from a memory into the reconfigurable system at one go and remains there as long as this configuration is needed.
  • the reconfigurable systems generally work in parallel with a conventional processor whose program is kept separate from the configuration data.
  • the object of the present invention is to provide a processor which can be used both can be used efficiently in control flow as well as in data flow-oriented applications and offers performance advantages over known processors in the execution of control flow-oriented programs.
  • the present processor comprises a two-dimensional array of a plurality of rows of configurable execution units that may be arranged in columns and connectable by configurable data connections from row to row to multiple strings of execution units.
  • the arrangement has a feedback network, via which a data value output at the data output of the lowest execution unit of each chain can be transferred to a top register of the chain.
  • the execution units are designed so that during one or more execution phases they handle, ie process or pass, data applied to their data input in accordance with their current configuration and provide the processed data at their data output for the sequential execution unit in the chain.
  • a decoding and configuration unit provided as a frontend selects from a single one during a plurality of decoding phases separated by one or more execution phases incoming sequential instruction stream autonomously executes execution units, generates configuration data for the selected execution units, and configures the selected execution units through a configuration network to execute the instructions.
  • the decoding and configuration unit can also be composed of a decoding unit and a separate configuration unit.
  • the processor further includes at least one of the execution units
  • the central part of the processor architecture on which the proposed processor is based is a two-dimensional structure of simple working elements, the execution units which do not have their own processors.
  • the execution units are generally designed as arithmetic logic units (ALU), which in one embodiment of the processor form a grid of rows and columns, also referred to below as an ALU grid. Because of their preferred embodiment, the execution units are hereinafter referred to merely as ALUs, but without restricting these execution units to ALUs.
  • ALU arithmetic logic units
  • each column represents an architectural register.
  • the number of columns in this case is the same as the number of architectural registers of the underlying processor architecture, ie it depends on the selected assembler instruction set.
  • the number of lines depends on the available chip area. The higher the number of lines, the higher the expected performance. For example, a range between five and ten lines may be useful for use in a desktop PC.
  • the ALUs are dynamically assigned a specific function by the decoding and configuration unit via a configuration network. This programming of the ALUs is clock synchronous. Once programmed, the ALUs then operate asynchronously with the respective values present at their data inputs, i. H. they have no storage elements for the working data. The working data or a part thereof can also be assigned a fixed fixed value during the configuration.
  • a data exchange can take place between the ALUs, but this is always directed from top to bottom from the perspective of the column or chain and supplies the ALUs with working data.
  • a series of registers is arranged, referred to in the present application as a top register.
  • further rows of registers can be arranged between other rows.
  • these intermediate registers must be equipped with a bypass technique so that incoming data can be stored or directly looped through.
  • the data returns may optionally have data elsewhere in a column, e.g. B. the intermediate registers, tap and at the uppermost location of the column, e.g. into another intermediate register row, feed again.
  • each row of the ALU grid is assigned a specific number of memory access units.
  • each ALU has a special Predication input, through which it can be disabled while working. If an ALU is deactivated, it forwards the value above, ie at its data input, unchanged to its data output. The predication inputs are operated by the jump control unit. This allows so-called "predicated instructions" of the assembler instruction set to be mapped in the ALU grid, ie it is possible to execute individual instructions only under certain conditions.
  • the processor architecture underlying the new processor architecture thus has as its main feature an internal two-dimensional arrangement or a grid of execution units or ALUs, with the help of which sequential programs are processed.
  • the connections between the ALUs are automatically established dynamically at runtime via multiplexers.
  • a central decoding and configuration unit responsible for establishing the connections is a central decoding and configuration unit (frontend) that generates configuration data for the ALU grid at runtime from a stream of conventional or slightly modified commands.
  • This novel architecture, or proposed processor provides a middle ground between conventional processors and reconfigurable hardware. The former are better suited for control flow-oriented tasks, e.g. For example, control tasks while reconfigurable hardware have their power to solve data flow-oriented problems, e.g. In video and audio processing.
  • a unified architecture that works for both Types of problem is equally suitable, was not known.
  • both data and control flow-oriented tasks can be performed by means of a conventional programming language, e.g. C / C ++. When the program code is executed, the advantages of processors or of reconfigurable hardware then arise as required.
  • the basic idea with the present processor architecture or processor is to dynamically map the individual machine instructions of a sequential instruction stream to a reconfigurable multicell array of ALUs and thereby execute a conventional program. This technique offers besides the possibility of efficient use both in
  • Control flow as well as data flow-oriented application fields also have performance advantages conventional processors in the execution of pure control flow-oriented programs.
  • FIG. 1 is a block diagram of one embodiment of the proposed processor
  • 3 shows an example of an embodiment when using synchronous data flow tokens
  • FIG. 6 shows an example of the integration of complex execution units into the ALU grid
  • Fig. 7 shows another example of an allocation of the ALUs with the example program in a pipeline execution.
  • FIG. 1 shows an example of a possible embodiment of the processor as a block diagram.
  • the ALU grid can be recognized as a central component of the processor.
  • the frontend form a command shell unit, a decoder unit and a configuration unit.
  • the instruction cache, the data cache and the virtual memory management are also standard modules.
  • the ALUs are arranged in rows and columns in this example, with a corresponding top register being provided at the entrance of each column. Intermediate registers with bypass are also indicated between individual lines of the ALUs in the figure. About one
  • the ALUs are connected to a jump control unit as well as to multiple memory access units (load / store).
  • the configuration network and the predication network are not shown in this block diagram.
  • Figure 2 shows an example of the design of an ALU, as it can be used in the present processor.
  • the configuration data from the configuration unit are written to the configuration register of the ALU via the synchronous inputs and the configuration clock is transmitted.
  • the ALU receives the working data via the asynchronous Data inputs A and B from the top register or the preceding ALU in the column. Instead of the working data at the data input B, the ALU can also work with a fixed value defined during the configuration. If required, the configuration of one of the multiplexers (MUXs) can be used to ensure that the ALU only loopes through the data.
  • Figure 2 also shows the predication input through which each ALU can be deactivated by the jump control unit during work.
  • the basis for program execution on the proposed processor is a sequential stream of assembler instructions, for example RISC assembly instructions. These are loaded from memory into the processor, packet by packet (one or more instructions) from memory, and passed to the decode unit. This checks dependencies on previous commands and forwards the current commands together with the dependency information to the configuration unit.
  • the task of the configuration unit is to select an ALU for each command, allocate the corresponding functionality and correctly configure the multiplexers for the work data. If it is a jump or memory access instruction, special measures are taken which will be explained in more detail later.
  • the operation of the processor is divided into two parts, namely the command arrangement of the individual
  • Memory Access Instructions This includes all commands that require data access to the external memory, such as memory. Load, Store, Push, Pop. These commands will possibly. an address calculation arranged in the ALU grid; the actual memory access is based on one of the memory access units.
  • Jump commands Here again a distinction must be made between conditional and unconditional jumps. Unconditional jumps, unless they use indirect addressing, are handled directly in the decoder unit and are not relevant to the ALU grid. Conditional and indirect jumps are forwarded to the jump control unit. It processes the values obtained from the ALU grid and, if necessary, triggers an actual jump in the program code, ie new program instructions are arranged in the ALU grid. If no new commands are loaded, control signals are generated for the ALU grid so that they continue to operate according to the desired program progression (eg when returning within a loop). For this purpose, within the ALU grid, the Data returns are used to send the calculated results from the end of the grid to the top registers or the corresponding intermediate registers within the grid.
  • Arithmetic-logical commands This includes all other commands. These are each assigned to an ALU in the grid, i. H. a selected ALU is configured to perform the function of the corresponding command.
  • each column must have its own row and row determined for each operation. This is done according to the following scheme:
  • the column in which the instruction is to be executed is determined by the instruction's destination register.
  • the output of the selected ALU, after the operation, assumes the calculated value and passes it for further operations via a forward network, i. the data connections between the ALUs in the column direction, continue downwards.
  • the forward network of the selected column thus carries in sections the values corresponding to the corresponding one
  • the row in which the operation must be carried out is determined from the lowest point, ie the most advanced calculations, of all registers involved in the operation. This means that the new operation must be located below the last operation of the destination register column. Furthermore, all already assigned operations of the source register (s) must also be above the new ALU to be selected.
  • the horizontal network (line routing network) multiplexers must be switched so that the source register data is present at the new ALU. Likewise, care must be taken that the values of the source registers are passed unchanged to the desired line. If necessary, ALUs in the columns of the source register must be deactivated, provided that no data paths in the forward direction are provided in addition to the ALUs.
  • the selected ALU is configured to perform the operation of the current instruction. Through this scheme, the dataflow graph of the arranged arithmetic-logical assembler instructions is built up within the ALU grid.
  • the memory access instructions are placed next to the ALU grid in one of the memory access units. For this, only the selection of the line is of interest. This is selected to be equivalent to the arithmetic-logical commands, that is, depending on the source registers used (for the memory address and, if necessary, for the write data). A possibly. Address calculation to be executed (eg addition of two
  • Register or addition of an offset is placed equivalent to the arithmetic logic instructions in the ALU grid.
  • Branch instructions fulfill their function starting from the jump control unit.
  • Data lines from the ALU grid also lead line by line to the jump control unit. It checks the data lines depending on the jump command to be executed and, if necessary, generates corresponding control signals for both the processor frontend and the ALU grid. If the decoder or the configuration unit detects forward jumps over a short distance (a few commands), the skipped commands can in principle be arranged in the ALU grid.
  • the jump control unit controls via the predication network during the execution phase whether the corresponding commands are actually executed.
  • the initial values of all architecture registers are stored in the top registers.
  • the values travel immediately through the forward network into the predetermined ALUs. There, the desired
  • Control unit evaluated (that is, data possibly compared and calculated the jump destination) and one of the following actions:
  • the jump destination has not yet been integrated into the ALU grid: All data below the jump command in the forward network is copied to the top register of the respective column. Subsequently, a reset of the ALU grid is carried out, i. H. All functions of the ALUs are deleted and the connections are resolved. Likewise, all the memory access units as well as the jump control unit are reset. Thereafter, the front end of the processor is reactivated and new instructions are placed from the desired location of the program code in the ALU grid.
  • Tokens Using Delay Elements Each ALU is assigned a delay element which receives a corresponding delay value during ALU configuration. This must correspond to the maximum signal propagation time of the desired operation of the ALU. Likewise, the data lines receive another bit (token), which is looped through the delay elements. If the tokens of all the required operands arrive in an ALU, a token is generated at the output of the ALU in order to delay the corresponding maximum signal propagation time.
  • Run time counter During the assignment of the functions to the ALUs, the signal run times of all columns (in the form of so-called pico clocks, ie in
  • Synchronous tokens Tokens are also used for this purpose. However, tokens are not passed through asynchronous delay elements on each ALU but through registers with bypass on each ALU. By default, the tab is disabled, So the bypass is active. As with the previous variant, the signal propagation time of the data is counted in the configuration of the ALUs. If the counted signal delay time is greater than one cycle, the token register of the currently configured ALU is activated and the runtime counter is decremented by one cycle. In this technique, the token does not run synchronously with the data through the data flow graph, but does not advance more than one cycle ahead. This must be taken into account when performing synchronous operations.
  • FIG. 3 shows an example in which all three ALUs execute operations which have a signal transit time of half a machine cycle. The token registers of the two upper ALUs are bypassed while the lower ALU token register holds the token until the data is actually available.
  • a program is specified in an assembler code and mapped into an ALU grid processor without an intermediate register.
  • the task of the program is to sum up the amounts of a 15-element number vector.
  • the vector must already be present in the main memory connected to the ALU-Grid processor.
  • the program is executed in several decoding and execution phases. Likewise, several instruction loop cycles are required for each decode phase, but these are summarized here. move Rl, # 15; 15 data values move R2, # address; Start address of the vector move RO, # 0 / register for the sum to 0; put
  • This program piece takes place in two decoding phases and in a total of 15 execution phases.
  • the first decode phase all program instructions are placed in the ALU grid.
  • the decoder unit notices that the first jump instruction skips only a single arithmetic logic instruction.
  • This one command is arranged like any other arithmetic logic command in the ALU grid, except that the predication line of the corresponding ALU is connected to the jump control unit. This is configured so that In due course, it checks the value of R3 for a negative sign.
  • FIG. 4 in which only the registers or columns RO to R3 are sketched, shows the allocation of the ALUs, the jump control unit and the memory access units.
  • the numerical values recognizable in FIG. 4 indicate the time in machine cycles to which the corresponding value is valid.
  • a central time counter must be present, which counts the elapsed time since the beginning of the calculation. If a memory access generates a cache miss, this counter is paused until the desired date has been loaded from the memory. If tokens are used, no time counter is required. This leads to a much more flexible runtime behavior.
  • the first value of the vector is read from the memory and the jump control checks this to a negative sign. If the read value in register R3 is negative, then the neg command is executed, otherwise the corresponding ALU is output via the Predication signal is disabled and the input value passed unchanged to the output.
  • the execution of all mapped instructions is completed and the result of the last comparison operation can be considered.
  • the value taken in column R1 is 14, ie. H. not 0, and there is a jump.
  • the jump control unit registers that the jump destination was not mapped to a line with registers (top or intermediate registers).
  • all values at the bottom of the ALU grid are tapped and copied to the top registers.
  • all ALU configurations are reset and a new decode phase is started at the location of the jump destination in the program code.
  • the first instruction of the loop body is in the first row, just below the top registers.
  • the ALU grid now has the configuration shown in FIG.
  • the checking of the register R1, which this time has the value 13, is again carried out to the value 0.
  • the jump is recognized as "execute” and it is again checked whether The jump target already corresponds with the first command in the ALU grid, ie no new decoding phase is started, but only the values at the lower end of the ALU grid are Register is copied and then another execution phase is started. If the register Rl reaches the value 0, the jump at the end of the loop is evaluated as "not to be executed.” As a result, a new decoding phase is triggered, whereby the ALU grid is specified with additional commands (not shown in the example). equipped until the capacity of the ALU grid has been reached or another jump command appears in the program code.
  • the first of the execution phases shown above achieves an IPC (Instructions Per Cycle) of 2 (10 instructions in 5 clocks) and the second execution phase an IPC of 1.4 (7 instructions in 5 clocks). In each case 2 clocks alone account for the memory access.
  • a conventional (superscalar) processor would likely deliver significantly worse results here.
  • the ALU-Grid processor works without jump prediction. This branch prediction can cause further significant performance degradation in superscalar processors in case of false predictions.
  • the lack of branch prediction leads to predictable runtime behavior of the ALU-Grid processor.
  • the ALU grid is only used to a very small percentage. If the architecture registers are not mapped directly to the columns of the grid, but only a few ALUs integrated per line, which can be used by all register columns, the number of ALUs can be reduced. Likewise, it is also possible to specialize the ALUs so that not all ALUs have to be realized as complex multi-function ALUs. Possibly. In this case, a type of register renaming can be used, ie a column is not permanently assigned to a register, but the assignment changes from line to line.
  • each of the memory access units can only be allocated to one load / store instruction, the implementation of efficient streaming buffers directly in each memory access unit is advantageous. Even simply loading a complete cache line directly into a storage access unit can bring enormous performance benefits here.
  • the memory access units may also operate asynchronously on existing data, which in the previous example would cause the runtime of a loop pass to be shortened by 1-1.5 clocks.
  • the data return in this example is not from the end of the grid but from the intermediate registers to the Top Register must take place.
  • the decision on the end of the loop must nevertheless be made after the last pipeline stage. If the upper part of an iteration has already been executed, even though the loop condition is no longer fulfilled, then no further measures are required. the register necessary. Since only the values at the end of the grid continue to be processed, all intermediate results in the intermediate registers are automatically discarded. Conversely, if write accesses to the main memory occur in a line other than the last pipeline stage, then these must be suppressed until it is clear whether the respective iteration must be executed at all.
  • the ALU grid processor used in the example has intermediate registers.
  • data from the corresponding lines within the ALU grid can be tapped to decode further commands already during the runtime of the
  • the ALU-Grid processor does not necessarily require branch prediction: the two possible paths of a short jump can be arranged simultaneously with the predication technique in the ALU grid or there is the possibility of one Path (loop body) in the ALU grid, while the other path (following program code) is already placed below in the ALU grid for later use. This leaves only jumps over long distances, which are not assigned to a loop can, and unconditional jumps, but already resolved in the decoding phase.
  • the decoding and configuration unit can decode commands from all possible jump targets in advance and corresponding "theoretical" arrangements in a buffer, similar to a trace cache, caching If one of the jumps is taken then the calculated configuration can be loaded very quickly into the ALU grid and execution can continue very quickly, although the reconfiguration may take place more quickly, if not a central one Instead, the configuration registers in the ALU grid are multiple and arranged in so-called plans, whereby it is possible to work with a tarpaulin while another tarpaulin is simultaneously writing a new configuration one configuration to the next to be changed immediately.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Advance Control (AREA)
  • Devices For Executing Special Programs (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Die vorliegende Erfindung betrifft einen Prozessor, der als Hauptmerkmal ein internes Raster von ALUs aufweist, mit dessen Hilfe sequentielle Programme abgearbeitet werden. Die Verbindungen zwischen den ALUs werden automatisch dynamisch zur Laufzeit über Multiplexer hergestellt. Verantwortlich für das Herstellen der Verbindungen ist eine zentrale Dekodier- und Konfigurationseinheit, die aus einem Strom herkömmlicher Assembler-Befehle Konfigurationsdaten für das ALU-Grid zur Laufzeit erzeugt. Neben dem ALU-Grid ist eine spezielle Einheit für die Ausführung von Speicherzugriffen und eine weitere Einheit für die Behandlung von Sprungbefehlen vorhanden. Die dem Prozessor zugrunde liegende neuartige Architektur ermöglicht die effiziente Durchführung sowohl von Kontrollfluss- als auch von Datenfluss-orientieren Aufgaben.

Description

Prozessor mit internem Raster von Ausführungseinheiten
Technisches Anwendungsgebiet / Stand der Technik
Die vorliegende Erfindung betrifft einen Prozessor für die Abarbeitung sequentieller Programme. Derartige Prozessoren arbeiten mit einer Folge von Befehlen, die sequentiell abgearbeitet werden. Die Befehle werden einzeln dekodiert und anschließend in sog. Ausführungseinheiten zur Ausführung gebracht. Die Ausführungs- einheiten sind bei herkömmlichen Prozessoren, bspw. bei Superskalar- oder VLIW-Prozessoren, eindimensional angeordnet . Diesen Ausführungseinheiten können daher in einem Takt nur Befehle zugeordnet werden, die vollkommen unabhängig voneinander sind. Erst nach deren Ausführung können abhängige Befehle im nächsten Takt zugeordnet und demnach erst dann ausgeführt werden.
Sog. "Tiled Architectures" verbinden den Ansatz eines herkömmlichen Prozessors mit Array-Strukturen von rekonfigurierbaren Systemen. Die Array-Strukturen umfassen hierbei in der Regel eine zweidimensionale
Anordnung aus kleinen Prozessoren zur Abarbeitung der Befehle. In vielen Fällen ist zur zentralen Steuerung der kleinen Prozessoren noch ein weiterer Steuerprozessor außerhalb des Arrays vorhanden. Die Datenpfade zwischen den kleinen Prozessoren können von diesen meist selbständig gesteuert werden, so dass ein Datenaustausch zwischen den Prozessoren stattfinden kann. Die Programmierung dieser "Tiled Architectures" erfolgt in Form mehrerer sequentieller Befehlsströme, die den einzelnen Prozessoren zugeordnet werden können. Der Steuerprozessor arbeitet hierbei generell mit einem eigenen Befehlsstrom, ggf. sogar mit einem von den Array-Prozessoren verschiedenen Befehlssatz.
Neben den genannten Prozessoren bzw. Prozessorarchitekturen sind auch sog. rekonfigurierbare Systeme bekannt, die aus einer zentralen, in der Regel zweidimensionalen, mehr oder weniger homogenen Anordnung von Arbeitselementen bestehen. Bei diesen Systemen handelt es sich jedoch nicht um Prozessoren, sondern um Systeme, die zusätzlich zu Prozessoren eingesetzt werden. Den Arbeitselementen, die mehr oder weniger spezialisiert sind, wird während einer Konfigurations- phase eine Aufgabe zugeteilt . Über Datenpfade sind die Arbeitselemente miteinander verbunden und können Daten austauschen. Diese Datenpfade werden in der Regel auch während der Konfigurationsphase bereits gestellt bzw. programmiert . Die Konfigurationsdaten werden bei rekonfigurierbaren Systemen vorab, d. h. bereits bei der Programmierung des Gesamtsystems, explizit erstellt. Dies erfolgt in der Praxis manuell mit Hilfe von geeigneten Synthese-Werkzeugen. Durch einen speziellen Mechanismus werden die Konfigurationsdaten zur Laufzeit auf einmal aus einem Speicher in das rekonfigurierbare System geladen und verbleiben dort, solange diese Konfiguration benötigt wird. Die rekonfigurierbaren Systeme arbeiten in der Regel parallel zu einem herkömmlichen Prozessor, dessen Programm separat neben den Konfigurationsdaten gehalten wird.
Die Aufgabe der vorliegenden Erfindung besteht darin, einen Prozessor bereitzustellen, der sich sowohl effizient in Kontrollfluss- als auch in Datenfluss- orientierten Anwendungen einsetzen lässt und gegenüber bekannten Prozessoren Leistungsvorteile bei der Abarbeitung von Kontrollfluss-orientierten Programmen bietet.
Darstellung der Erfindung
Die Aufgabe wird mit dem Prozessor gemäß Patentanspruch 1 gelöst . Vorteilhafte Ausgestaltungen des Prozessors sind Gegenstand der Unteransprüche oder lassen sich der nachfolgenden Beschreibung sowie den Ausführungsbeispielen entnehmen.
Der vorliegende Prozessor umfasst eine zwei- dimensionale Anordnung aus mehreren Zeilen konfigurierbarer Ausführungseinheiten, die in Spalten angeordnet sein können und durch konfigurierbare Datenverbindungen von Zeile zu Zeile zu mehreren Ketten von Ausführungs- einheiten verbunden werden können. Die Anordnung weist ein Rückführungsnetzwerk auf, über das ein am Datenausgang der untersten Ausführungseinheit jeder Kette ausgegebener Datenwert an ein Top-Register der Kette überführt werden kann. Die Ausführungseinheiten sind dabei so ausgebildet, dass sie während ein oder mehrerer Ausführungsphasen an ihrem Dateneingang anliegende Daten entsprechend ihrer momentanen Konfiguration behandeln, d.h. verarbeiten oder durchleiten, und die behandelten Daten an ihrem Datenausgang für die in der Kette nachfolgende Ausführungseinheit bereitstellen. Eine als Frontend vorgesehene Dekodier- und Konfigurationseinheit wählt während mehrerer durch ein oder mehrere Ausführungs- phasen getrennte Dekodierphasen aus einem einzelnen eingehenden sequentiellen Befehlsstrom zur Laufzeit eigenständig Ausführungseinheiten aus, erzeugt Konfigurationsdaten für die ausgewählten Ausführungseinheiten und konfiguriert die ausgewählten Ausfüh- rungseinheiten über ein Konfigurationsnetzwerk zur Ausführung der Befehle. Die Dekodier- und Konfigurationseinheit kann sich dabei auch aus einer Dekodiereinheit und einer davon getrennten Konfigurations- einheit zusammensetzen. Der Prozessor weist weiterhin zumindest eine mit den Ausführungseinheiten über
Datenleitungen verbundene Sprung-Kontrolleinheit für die Behandlung von Sprungbefehlen sowie ein oder mehrere mit den Ausführungseinheiten über Datenleitungen verbundene Speicherzugriffseinheiten zur Ausführung von Speicherzugriffen auf.
Zentraler Teil der Prozessorarchitektur, die dem vorgeschlagenen Prozessor zugrunde liegt, ist eine zweidimensionale Struktur aus einfachen Arbeits- elementen, den Ausführungseinheiten, die keine eigenen Prozessoren aufweisen. Die Ausführungseinheiteή sind in der Regel als arithmetisch logische Einheiten (ALU) ausgebildet, die in einer Ausgestaltung des Prozessors ein Raster aus Zeilen und Spalten bilden, im Folgenden auch als ALU-Grid bezeichnet. Die Ausführungseinheiten werden im Folgenden aufgrund ihrer bevorzugten Ausgestaltung stellvertretend nur noch als ALUs bezeichnet, ohne diese Ausführungseinheiten jedoch damit auf ALUs einzuschränken. In der genannten Ausgestaltung mit dem internen Raster von ALUs repräsentiert jede Spalte ein Architekturregister. Somit ist die Anzahl der Spalten in diesem Fall genauso hoch wie die Anzahl der Architekturregister der zugrunde liegenden Prozessor- architektur, d. h. sie ist abhängig vom gewählten Assembler-Befehlssatz. Dies ist jedoch nicht in jedem Falle erforderlich, wie weiter unten näher erläutert wird. Die Anzahl an Zeilen ist abhängig von der zur Verfügung stehenden Chip-Fläche. Je höher die Zeilenanzahl, desto höher ist die zu erwartende Leistung. Für die Anwendung in einem Desktop-PC kann bspw. ein Bereich zwischen fünf und zehn Zeilen sinnvoll sein.
Die ALUs werden von der Dekodier- und Konfigurationseinheit dynamisch über ein Konfigurations- netzwerk einzeln mit einer bestimmten Funktion belegt. Diese Programmierung der ALUs geschieht Takt-synchron. Einmal programmiert, arbeiten die ALUs dann asynchron mit den jeweils an ihren Dateneingängen anliegenden Werten, d. h. sie besitzen keinerlei Speicherelemente für die Arbeitsdaten. Die Arbeitsdaten oder ein Teil davon können bei der Konfiguration auch mit einem festgelegten Festwert belegt werden.
Zwischen den ALUs kann ein Datenaustausch stattfinden, der aber immer aus Sicht der Spalte bzw. Kette von oben nach unten gerichtet ist und die ALUs mit Arbeitsdaten versorgt. Oberhalb der obersten Zeile ist eine Reihe von Registern angeordnet, in der vorliegenden Patentanmeldung als Top-Register bezeichnet. Zusätzlich können optional weitere Registerreihen zwischen anderen Zeilen angeordnet sein. Diese Zwischenregister müssen allerdings mit einer Bypass- Technik ausgestattet sein, so dass ankommende Daten gespeichert oder direkt durchgeschleift werden können. Im Folgenden wird bei der Beschreibung des Prozessors sowie bevorzugter Ausgestaltungen des Prozessors zur Vereinfachung nur der Begriff der Spalte benutzt. Selbstverständlich gelten jedoch sämtliche Ausführungen in gleicher Weise auch bei einer Verbindung der ALUs zu nicht geradlinig verlaufenden Ketten.
Zusätzlich zu den Datenpfaden, die (vorwärts) durch die ALUs führen und ein sog. Vorwärtsnetzwerk bilden, sind separate Datenrückführungen vorhanden, die die am Ende einer Spalte anliegenden Daten an den Anfang derselben Spalte, also in die Top-Register, zurückführen. Diese Datenrückführungen bilden ein sog. Rückführungsnetzwerk. Ebenso können die Datenrückführungen Daten optional an einer anderen Stelle innerhalb einer Spalte, z. B. den Zwischenregistern, abgreifen und an weiter oben liegender Stelle der Spalte, z.B. in eine andere Zwischenregisterreihe, wieder einspeisen.
Neben dem zentralen ALU-Grid sind ein oder mehrere Speicherzugriffseinheiten und eine Sprung-Kontroll- eihheit vorgesehen. Die Sprung-Kontrolleinheit stößt unter bestimmten Bedingungen die Rückführung von Daten über die Datenrückführungen von unten nach oben an. Die Speicherzugriffseinheiten erlauben die Ausführung von Speicherzugriffen, um Daten aus dem ALU-Grid in den Speicher bzw. Daten aus dem Speicher in das ALU-Grid zu transportieren. Dabei ist vorzugsweise jeder Zeile des ALU-Grid eine bestimmte Anzahl von Speicherzugriffs- einheiten beigeordnet. Vorzugsweise verfügt jede ALU über einen speziellen Predication-Eingang, über den sie während der Arbeit deaktiviert werden kann. Ist eine ALU deaktiviert, so leitet sie den oberhalb, d.h. an ihrem Dateneingang anliegenden Wert, unverändert an ihren Datenausgang weiter. Die Predication-Eingänge werden von der Sprung-Kontrolleinheit bedient. Dadurch können sog. "predicated instructions" des Assembler- Befehlssatzes im ALU-Grid abgebildet werden, d. h. es besteht die Möglichkeit, einzelne Befehle nur unter bestimmten Bedingungen auszuführen.
Die dem Prozessor zugrunde liegende neuartige Prozessorarchitektur besitzt somit als Hauptmerkmal eine interne zweidimensionale Anordnung bzw. ein Raster von Ausführungseinheiten oder ALUs, mit dessen Hilfe sequentielle Programme abgearbeitet werden. Die Verbindungen zwischen den ALUs werden automatisch dynamisch zur Laufzeit über Multiplexer hergestellt.
Verantwortlich für das Herstellen der Verbindungen ist eine zentrale Dekodier- und Konfigurationseinheit (Frontend) , die aus einem Strom herkömmlicher bzw. leicht modifizierter Befehle Konfigurationsdaten für das ALU-Grid zur Laufzeit erzeugt. Diese neuartige Architektur bzw. der vorgeschlagene Prozessor stellt einen Mittelweg zwischen herkömmlichen Prozessoren und rekonfigurierbarer Hardware dar. Erstere eignen sich besser für Kontrollfluss-orientierte Aufgaben, z. B. Steuerungsaufgaben, während rekonfigurierbare Hardware ihre Stärke bei der Lösung von Datenfluss-orientierten Problemen, z. B. bei der Video- und Audioverarbeitung, aufweist. Eine einheitliche Architektur, die für beide Arten der Problemstellung gleichermaßen geeignet ist, war bisher nicht bekannt . Mit der hier vorgeschlagenen Architektur können sowohl Daten- als auch Kontroll- fluss-orientierte Aufgaben mittels einer herkömmlichen Programmiersprache, z. B. C/C++, behandelt werden. Bei der Ausführung des Programmcodes ergeben sich dann je nach Bedarf die Vorteile von Prozessoren bzw. von rekonfigurierbarer Hardware .
Als Einsatzgebiete des neuen Prozessors kommen je nach Ausbaustufe alle Arten von Datenverarbeitungs- systemen in Betracht . In einer mächtigen Variante kann der Prozessor bzw. die zugrunde liegende Architektur in Datenbank- oder Compute-Servern Anwendung finden. In einer reduzierten Ausbaustufe besteht auch die
Möglichkeit des Einsatzes in mobilen Geräten. Da die Architektur in einer Richtung vollständig skalierbar ist, kann Software, die für eine Ausbaustufe entwickelt wurde, auch auf einer anderen Ausbaustufe ausgeführt werden. Es besteht also Kompatibilität in beiden
Richtungen (aufwärts und abwärts) .
Die grundsätzliche Idee bei der vorliegenden Prozessorarchitektur bzw. dem vorliegenden Prozessor besteht darin, die einzelnen Maschinenbefehle eines sequentiellen Befehlsstroms dynamisch auf ein rekonfigurierbares, mehrzelliges Raster aus ALUs abzubilden und dadurch ein herkömmliches Programm abzuarbeiten. Diese Technik bietet neben der Möglichkeit des effizienten Einsatzes sowohl in
Kontrollfluss- als auch Datenfluss-orientierten Anwendungsfeldern ebenfalls Leistungsvorteile gegenüber herkömmlichen Prozessoren bei der Abarbeitung reiner Kontrollfluss-orientierter Programme .
Im Gegensatz zu bekannten Prozessorarchitekturen ist es damit möglich, abhängige Befehle im selben Takt den Ausführungseinheiten zuzuordnen und ggf . auch in einem Takt auszuführen. Durch die vorerst nicht vorgesehene Sprungvorhersage entsteht kein "Miss- Prediction-Penalty" bei falsch vorhergesagten Sprüngen. Dennoch erlaubt die vorgestellte Architektur die effiziente Behandlung von Sprüngen, die bei der Ausführung von Schleifen ihre volle Leistungsfähigkeit entfaltet. Dabei entfällt die Dekodierung und Zuordnung neuer Befehle ins ALU-Grid und es erfolgt nur noch die Ausführung der bereits im ALU-Grid vorhandenen Befehle. Im ALU-Grid wird eine Schleife, nachdem diese als solche erkannt wurde, einmalig zugeordnet und verbleibt so lange im ALU-Grid, bis sie wieder verlassen wird. Die Dekodier- und Zuordnungseinheit kann somit in dieser Zeit deaktiviert werden. Demgegenüber muss jeder Befehl bei herkömmlichen Prozessoren pro Schleifendurchlauf bei der Abarbeitung von Schleifen einmal einer Ausführungseinheit zugeordnet werden. Somit ist die Zuordnungseinheit und bei Fehlen eines "Trace- Cache" auch die Dekodiereinheit in derartigen
Prozessoren durchgehend aktiv. Im Gegensatz zu ähnlich aufgebauten "Tiled Architectures" sind für die hier vorgestellte Architektur keine speziellen Compiler oder sonstigen Software-Entwicklungswerkzeuge erforderlich. Anders als bei einfachen rekonfigurierbaren Systemen erfolgt die Programmierung des ALU-Grid mit einem sequentiellen Befehlsstrom, der direkt vom Compiler stammt und die Form herkömmlicher Assembler-Befehle besitzt. Die Ausführungseinheiten des ALU-Grid werden mittels dieser Befehle konfiguriert und behalten diese Konfiguration meist nur sehr kurze Zeit, es sei denn, es wird gerade eine Schleife abgearbeitet . Die Konfiguration des gesamten ALU-Grid ergibt sich somit dynamisch aus der Reihenfolge der abgearbeiteten Befehle und nicht aus statisch generierten Konfigurationsdaten.
Kurze Beschreibung der Zeichnungen
Der vorliegende Prozessor bzw. die zugrunde liegende Prozessorarchitektur wird nachfolgend anhand von Ausführungsbeispielen in Verbindung mit den Zeichnungen nochmals näher erläutert. Hierbei zeigen:
Fig. 1 ein Blockschaltbild einer Ausgestaltungs- möglichkeit des vorgeschlagenen Prozessors;
Fig. 2 ein Beispiel für die Ausgestaltung einer ALU;
Fig. 3 ein Beispiel einer Ausgestaltung beim Einsatz synchroner Datenfluss-Token;
Fig. 4 ein Beispiel für eine erste Belegung der ALUs mit einem Beispielprogramm;
Fig. 5 ein Beispiel für eine zweite Belegung der ALUs mit dem Beispielprogramm;
Fig. 6 ein Beispiel für die Integration komplexer Ausführungseinheiten in das ALU-Grid; und Fig. 7 ein weiteres Beispiel für eine Belegung der ALUs mit dem Beispielprogramm bei einer Pipeline-Ausführung.
Wege zur Ausführung der Erfindung
Figur 1 zeigt ein Beispiel für eine mögliche Ausgestaltung des Prozessors als Blockschaltbild. In diesem Blockschaltbild ist das ALU-Grid als zentraler Bestandteil des Prozessors zu erkennen. Das Frontend bilden eine Befehlshole-Einheit , eine Dekodiereinheit sowie eine Konfigurationseinheit. Der ebenfalls eingezeichnete Befehls-Cache, der Daten-Cache sowie die virtuelle Speicherverwaltung sind Standard-Baugruppen.
Die ALUs sind bei diesem Beispiel zeilen- und spaltenweise angeordnet, wobei am Eingang jeder Spalte ein entsprechendes Top-Register vorgesehen ist. Auch Zwischenregister mit Bypass sind zwischen einzelnen Zeilen der ALUs in der Figur angedeutet. Über ein
Zeilen-Routing-Netzwerk sind die ALUs mit einer Sprung- Kontrolleinheit sowie mit mehreren Speicherzugriffseinheiten (Laden/Speichern) verbunden. Das Konfigurationsnetzwerk und das Predication-Netzwerk sind in diesem Blockschaltbild nicht eingezeichnet.
Figur 2 zeigt ein Beispiel für die Ausgestaltung einer ALU, wie sie im vorliegenden Prozessor zum Einsatz kommen kann. Über die synchronen Eingänge werden die Konfigurationsdaten von der Konfigurations- einheit in ein Konfigurationsregister der ALU geschrieben und der Konfigurationstakt übertragen. Die ALU erhält die Arbeitsdaten über die asynchronen Dateneingänge A und B vom Top-Register oder der in der Spalte vorangehenden ALU. Anstelle der Arbeitsdaten am Dateneingang B kann die ALU auch mit einem bei der Konfiguration festgelegten Festwert arbeiten. Über die Konfiguration eines der dargestellten Multiplexer (MUX) lässt sich bei Bedarf erreichen, dass die ALU die Daten nur durchschleift . Figur 2 zeigt auch den Predication- Eingang, über den jede ALU während der Arbeit von der Sprung-Kontrolleinheit deaktiviert werden kann.
Grundlage für die Programmausführung auf dem vorgeschlagenen Prozessor ist ein sequentieller Strom von Assembler-Befehlen, bspw. von RISC-Assembler- Befehlen. Diese werden paketweise (ein oder mehrere Befehle) von einer Befehlshole-Einheit aus dem Speicher in den Prozessor geladen und der Dekodiereinheit übergeben. Diese prüft Abhängigkeiten zu vorangegangenen Befehlen und gibt die aktuellen Befehle zusammen mit den Abhängigkeitsinformationen an die Konfigurationseinheit weiter. Aufgabe der Konfigurationseinheit ist es, für jeden Befehl eine ALU auszuwählen, dieser die entsprechende Funktionalität zuzuweisen und die Multiplexer für die Arbeitsdaten richtig zu konfigurieren. Handelt es sich um einen Sprung- oder Speicherzugriffsbefehl, so werden spezielle Maßnahmen ergriffen, die später genauer erläutert werden.
Die Arbeitsweise des Prozessors zerfällt in zwei Teile, nämlich die Befehlsanordnung der einzelnen
Assembler-Befehle im ALU-Grid (Dekodierphase) und die eigentliche Abarbeitung der Befehle innerhalb der Grid sowie der Sprung-Kontroll- und den Speicherzugriffs- einheiten (Ausführungsphase) . Im Folgenden werden die beiden Teile separat erläutert, wohingegen diese Vorgänge im Prozessor teilweise zeitlich überlappt ausgeführt werden können.
Prinzipiell werden bei der Befehlsanordnung immer Teile des sequentiellen Programms in das ALU-Grid übertragen. Dabei muss zwischen folgenden drei Befehlsgruppen unterschieden werden:
Speicherzugriffsbefehle: Darunter fallen alle Befehle, die einen Datenzugriff auf den externen Speicher verlangen, z. B. Load, Store, Push, Pop. Bei diesen Befehlen wird ggf . eine Adressberechnung im ALU- Grid angeordnet; der eigentliche Speicherzugriff erfolgt ausgehend von einer der Speicherzugriffseinheiten.
Sprungbefehle : Hier muss wiederum zwischen bedingten und unbedingten Sprüngen unterschieden werden. Unbedingte Sprünge werden, sofern sie nicht eine indirekte Adressierung verwenden, unmittelbar in der Dekodiereinheit behandelt und sind für das ALU-Grid nicht relevant . Bedingte und indirekte Sprünge werden an die Sprung-Kontrolleinheit weitergeleitet. Diese verarbeitet die aus dem ALU-Grid erhaltenen Werte und löst ggf. einen tatsächlichen Sprung im Programmcode aus, d. h. es werden neue Befehle des Programms im ALU- Grid angeordnet. Werden keine neuen Befehle geladen, so werden Steuersignale für das ALU-Grid erzeugt, so dass diese entsprechend des gewünschten Programmverlaufs weiter arbeitet (z. B. beim Rücksprung innerhalb einer Schleife) . Hierzu werden innerhalb des ALU-Grid die Datenrückführungen verwendet, um die berechneten Ergebnisse vom Ende des Grid an die Top-Register bzw. die entsprechenden Zwischenregister innerhalb des Grid zu senden.
Arithmetisch-logische Befehle: Hierunter fallen alle übrigen Befehle. Diese werden jeweils einer ALU im Grid zugeordnet, d. h. eine ausgewählte ALU wird so konfiguriert, dass sie die Funktion des entsprechenden Befehls ausführt.
Für die Anordnung der arithmetisch-logischen Befehle im ALU-Grid muss für jede Operation einzeln sowohl die Spalte als auch die Zeile im Grid bestimmt werden. Dies erfolgt nach folgendem Schema:
Auswahl der Spalte: Die Spalte, in der der Befehl zur Ausführung kommen soll, wird durch das Zielregister des Befehls bestimmt. Der Ausgang der ausgewählten ALU nimmt nach der Operation den berechneten Wert an und leitet diesen für weitere Operationen über ein Vorwärts-Netzwerk, d.h. die Datenverbindungen zwischen den ALUs in Spaltenrichtung, nach unten weiter. Das Vorwärts-Netzwerk der ausgewählten Spalte trägt somit abschnittsweise die Werte, die das entsprechende
Architekturregister zwischen den Berechnungen annehmen würde .
Auswahl der Zeile: die Zeile, in der die Operation ausgeführt werden muss, bestimmt sich aus dem tiefsten Punkt, also der am weitesten fortgeschrittenen Berechnungen, aller an der Operation beteiligten Register. Dies bedeutet, dass die neue Operation unterhalb der letzten Operation der Zielregister-Spalte angeordnet sein muss. Desweiteren müssen auch alle bereits zugeordneten Operationen des oder der Quellregister oberhalb der neu auszuwählenden ALU liegen.
Nach Auswahl der neu zu konfigurierenden ALU müssen die Multiplexer des horizontalen Netzwerks (Zeilen-Routing-Netzwerk) so geschalten werden, dass die Daten der Quellregister an der neuen ALU anliegen. Ebenso muss dafür Sorge getragen werden, dass die Werte der Quellregister unverändert bis zur gewünschten Zeile geleitet werden. Dazu müssen ggf. ALUs in den Spalten der Quellregister deaktiviert werden, sofern neben den ALUs keine Datenpfade in Vorwärts-Richtung vorgesehen sind. Die ausgewählte ALU wird derart konfiguriert, dass sie die Operation des aktuellen Befehls ausführt. Durch dieses Schema wird innerhalb des ALU-Grid der Datenflussgraph der angeordneten arithmetisch-logischen Assembler-Befehle aufgebaut.
Im Gegensatz zu den arithmetisch-logischen Befehlen werden die Speicherzugriffsbefehle neben dem ALU-Grid in einer der Speicherzugriffseinheiten untergebracht. Hierzu ist lediglich die Auswahl der Zeile von Interesse. Diese wird äquivalent zu den arithmetisch-logischen Befehlen, also abhängig von den verwendeten Quellregistern (für die Speicheradresse und ggf . für die Schreibdaten) ausgewählt . Eine ggf . auszuführende Adressberechnung (z. B. Addition zweier
Register oder Addition eines Offset) wird äquivalent zu den arithmetisch-logischen Befehlen in dem ALU-Grid angeordnet . Sprungbefehle erfüllen ihre Funktion ausgehend von der Sprung-Kontrolleinheit. Ebenfalls zeilenweise führen Datenleitungen aus dem ALU-Grid in die Sprung- Kontrolleinheit. Diese überprüft je nach auszuführendem Sprungbefehl die Datenleitungen und erzeugt ggf. entsprechende Steuersignale sowohl für das Prozessor- Frontend als auch das ALU-Grid. Werden von der Dekodier- bzw. der Konfigurationseinheit Vorwärts- sprünge über eine kurze Distanz (wenige Befehle) erkannt, so können die übersprungenen Befehle grundsätzlich im ALU-Grid angeordnet werden. Die Sprung-Kontrolleinheit steuert über das Predication- Netzwerk während der Ausführungsphase, ob die entsprechenden Befehle tatsächlich ausgeführt werden.
Nachdem ausreichend viele Befehle im ALU-Grid und den seitlich angrenzenden Einheiten angeordnet wurden, wird das Dekodieren neuer Befehle gestoppt und es beginnt die Befehlsausführungsphase.
Die Initialwerte aller Architektur-Register sind in den Top-Registern gespeichert. Die Werte wandern unverzüglich durch das Vorwärtsnetzwerk in die vorher bestimmten ALUs. Dort erfolgen die gewünschten
Operationen. Steht ein Speicherzugriffsbefehl an, so werden die benötigte Adresse und ggf. die Schreibdaten eingefangen und ein synchroner Speicherzugriff ausgeführt . Nach einem Lesezugriff werden die gelesenen Daten in das ALU-Grid geleitet und weiterverarbeitet.
Steht ein Sprungbefehl an, so werden die für den Sprungbefehl relevanten Datenworte in der Sprung- Kontrolleinheit ausgewertet (d. h. Daten ggf. verglichen und das Sprungziel berechnet) und eine der folgenden Aktionen ausgeführt:
- Das Sprungziel wurde noch nicht in das ALU-Grid integriert: Es werden alle Daten, die unterhalb des Sprungbefehls im Vorwärts-Netzwerk anliegen in das Top- Register der jeweiligen Spalte kopiert. Anschließend wird ein Reset des ALU-Grid durchgeführt, d. h. alle Funktionen der ALUs werden gelöscht und die Verbindungen aufgelöst. Ebenso werden sowohl alle Speicherzugriffseinheiten als auch die Sprung-Kontrolleinheit zurückgesetzt. Danach wird das Frontend des Prozessors reaktiviert und neue Befehle von der gewünschten Stelle des Programmcodes im ALU-Grid angeordnet .
- Das Sprungziel ist bereits im ALU-Grid vorhanden: in diesem Fall werden lediglich die Daten unterhalb des Sprungbefehls in die Register (Top- oder Zwischen- register) oberhalb der Stelle im Grid kopiert, an der das Sprungziel im Grid angeordnet ist. Danach erfolgt eine weitere Befehlsausführungsphase.
Stand während der Ausführungsphase kein Sprungbefehl an, so werden nach Ende der Ausführung alle Daten vom unteren Ende des ALU-Grid in die Top- Register kopiert; sie stellen jetzt die neuen Initialwerte für die später folgende nächste Ausführungsphase dar. Anschließend startet eine neue Dekodierphase .
Da die Ausführung der einzelnen Operationen in den ALUs asynchron erfolgt, kann ohne weitere Hilfsmittel das Ende einer Ausführungsphase bzw. der Zeitpunkt, an dem ein Speicherzugriff oder ein Sprung stattfinden kann, nicht bestimmt werden. Hierzu stehen drei verschiedene Techniken zur Auswahl :
Tokens unter Verwendung von Verzögerungselementen: Jeder ALU wird ein Verzögerungselement beigeordnet, das während der Konfiguration der ALU einen entsprechenden Verzögerungswert erhält . Dieser muss der maximalen Signallaufzeit der gewünschten Operation der ALU entsprechen. Ebenso erhalten die Datenleitungen ein weiteres Bit (Token) , das durch die Verzögerungselemente geschleift wird. Treffen die Tokens aller benötigten Operanden in einer ALU ein, so wird am Ausgang der ALU, um die entsprechende maximale Signallaufzeit verzögert, ein Token erzeugt.
Laufzeitzähler: Während der Zuordnung der Funktionen an die ALUs werden die Signallaufzeiten aller Spalten (in Form sog. Pico-Takte, also in
Bruchteilen eines Maschinen-Takts) mitgezählt. Die für synchrone Operationen relevanten Zeitpunkte werden in den jeweiligen Einheiten gespeichert. Zu den gegebenen Zeitpunkten werden dann die gewünschten Operationen angestoßen, d. h. jede synchrone Einheit wartet so lange ab, bis die benötigten Daten laut Laufzeitzähler bereit stehen.
Synchrone Tokens : Hierzu werden ebenfalls Token verwendet. Das Weiterreichen der Token erfolgt allerdings nicht durch asynchrone Verzögerungselemente an jeder ALU, sondern durch Register mit Bypass an jeder ALU. Standardmäßig ist das Register deaktiviert, also der Bypass aktiv. Wie bei der vorangehenden Variante wird die Signallaufzeit der Daten bei der Konfiguration der ALUs mitgezählt. Wird die gezählte Signallaufzeit größer als ein Takt, so wird das Token- Register der aktuell konfigurierten ALU aktiviert und der Laufzeitzähler um einen Takt dekrementiert . Das Token läuft bei dieser Technik nicht synchron zu den Daten durch den Datenflussgraph sondern eilt maximal einen Takt voraus. Dies muss bei der Ausführung synchroner Operationen berücksichtigt werden. Figur 3 zeigt ein Beispiel, bei dem alle drei ALUs Operationen ausführen, die eine Signallaufzeit von einem halben Maschinentakt besitzen. Die Token-Register der beiden oberen ALUs werden auf Bypass geschalten, während das Token-Register der unteren ALU das Token so lange aufhält, bis die Daten tatsächlich verfügbar sind.
Für die Funktion des ALU-Grid Prozessors muss lediglich eine der drei genannten Möglichkeiten zur Synchronisation realisiert werden. Die letzte Variante wird dabei aufgrund ihrer Flexibilität bevorzugt.
Im Folgenden wird als Beispiel ein Programm in einem Assembler-Code vorgegeben und in einen ALU-Grid Prozessor ohne Zwischenregister abgebildet. Aufgabe des Programms ist es, die Summe über die Beträge eines 15 Elemente langen Zahlenvektors zu bilden. Der Vektor muss dabei bereits in dem an den ALU-Grid Prozessor angeschlossenen Hauptspeicher vorhanden sein. Das Programm wird in mehreren Dekodier- und Ausführungsphasen abgearbeitet. Ebenso sind für jede Dekodierphase mehrere Befehlshole-Zyklen erforderlich, die hier aber zusammengefasst werden. move Rl, #15 ; 15 Datenwerte move R2,#adresse ; Startadresse des Vektors move RO, #0 /Register für die Summe auf 0 ; setzen
loop: load R3, [R2] ;ein Element aus dem
; Speicher lesen jmpnl R3,not_negativ ;ist dieser nicht negativ? neg R3 ;wenn negativ: negieren
not_negativ: add RO, R3 ; absoluten Wert zum
/Summenregister (RO) addieren add R2,#4 /Adresse für nächstes Element
; erhöhen sub Rl,#1 ;ein Datenelement wurde
; abgearbeitet jmpnz Rl, loop /noch mehr Datenwerte?
Die Abarbeitung dieses Programmstücks erfolgt in zwei Dekodierphasen und in insgesamt 15 Ausführungsphasen. In der ersten Dekodierphase werden alle Befehle des Programms im ALU-Grid angeordnet. Die Dekodiereinheit bemerkt dabei, dass der erste Sprungbefehl lediglich einen einzigen arithmetisch-logischen Befehl überspringt. Dieser eine Befehl wird wie jeder andere arithmetisch-logische Befehl im ALU-Grid angeordnet, mit dem Unterschied, dass die Predication-Leitung der entsprechenden ALU mit der Sprung-Kontrolleinheit verbunden wird. Diese wird derart konfiguriert, dass sie zu gegebener Zeit den Wert von R3 auf ein negatives Vorzeichen hin überprüft. Figur 4, in der nur die Register bzw. Spalten RO bis R3 skizziert sind, zeigt die Belegung der ALUs, der Sprung-Kontrolleinheit und der Speicherzugriffseinheiten. Dabei wurde angenommen, dass die Befehle add, sub und neg jeweils einen vollen Maschinentakt und die move-Befehle einen halben Maschinentakt zur Ausführung benötigen. Für einen Cache-Zugriff werden hier zwei Takte veranschlagt, jeder der beiden Vergleichsoperationen in der Sprung- Kontrolleinheit benötigt einen halben Takt. Diese Zeiten sind hier nur beispielhaft gewählt und müssen bei der tatsächlichen Implementierung genau bestimmt werden.
Die in der Figur 4 erkennbaren Zahlenwerte geben den Zeitpunkt in Maschinentakten an, zu dem der entsprechende Wert Gültigkeit erhält. Je nachdem, welches Verfahren zur Synchronisation verwendet wird, muss ein zentraler Zeitzähler vorhanden sein, der die verstrichene Zeit seit Berechnungsbeginn mitzählt. Erzeugt ein Speicherzugriff einen Cache-Miss, so wird dieser Zähler so lange angehalten, bis das gewünschte Datum aus dem Speicher geladen wurde . Werden Token verwendet, so ist kein Zeitzähler erforderlich. Dies führt zu einem deutlich flexibleren Laufzeitverhalten.
Zum Zeitpunkt 2,5 Maschinentakte ist der erste Wert des Vektors aus dem Speicher gelesen und die Sprung-Kontrolle überprüft diesen auf ein negatives Vorzeichen. Ist der gelesene Wert in Register R3 negativ, so wird der neg-Befehl ausgeführt, anderenfalls wird die entsprechende ALU über das Predication-Signal deaktiviert und der Eingangswert unverändert an den Ausgang weitergegeben.
Zum Zeitpunkt 5 Maschinentakte ist die Abarbeitung aller abgebildeten Befehle beendet und das Ergebnis der letzten Vergleichsoperation kann betrachtet werden. In diesem Fall ist der in Spalte Rl abgegriffene Wert 14, d. h. nicht 0, und es erfolgt ein Sprung. Die Sprung- Kontrolleinheit registriert, dass das Sprungziel nicht auf eine Zeile mit Registern (Top- oder Zwischenregister) abgebildet wurde. Dies hat zur Folge, dass alle Werte am unteren Ende des ALU-Grid abgegriffen und in die Top-Register kopiert werden. Danach erfolgt das Zurücksetzen aller ALU-Konfigurationen und es wird eine erneute Dekodierungsphase an der Stelle des Sprungziels im Programmcode gestartet . Nach Abschluss dieser Dekodierungsphase befindet sich der erste Befehl des Schleifenkörpers in der ersten Zeile, also direkt unter den Top-Registern. Das ALU-Grid besitzt jetzt die in Figur 5 gezeigte Konfiguration.
Nach der zweiten Ausführungsphase (4,5 Takte nach ihrem Beginn) erfolgt wieder die Überprüfung des Registers Rl, das diesmal den Wert 13 besitzt, auf den Wert 0. Somit wird der Sprung als „auszuführen" erkannt und es wird wieder geprüft, ob sich das Sprungziel bereits im ALU-Grid an passender Stelle befindet . Diesmal korrespondiert das Sprungziel mit dem ersten Befehl im ALU-Grid, d. h. es wird keine neue Dekodierungsphase gestartet, sondern es werden lediglich die Werte am unteren Ende des ALU-Grid in die Top-Register kopiert. Anschließend wird eine weitere Ausführungsphase gestartet . Erreicht das Register Rl den Wert 0, so wird der Sprung am Ende der Schleife als „nicht auszuführen" ausgewertet. Dies hat zur Folge, dass eine neue Dekodierungsphase angestoßen wird. Dabei wird das ALU- Grid mit weiteren Befehlen (nicht im Beispiel angegeben) bestückt, bis die Kapazität des ALU-Grid erreicht ist oder ein weiterer Sprungbefehl im Programmcode auftaucht .
Die erste der oben gezeigten Ausführungsphasen erreicht einen IPC (Instructions Per Cycle) von 2 (10 Befehle in 5 Takten) und die zweite Ausführungsphase einen IPC von 1,4 (7 Befehle in 5 Takten) . Dabei entfallen jeweils 2 Takte alleine auf den Speicherzugriff. Ein konventioneller (Superskalar-) Prozessor würde hier voraussichtlich deutlich schlechtere Ergebnisse liefern. Ebenso kommt hinzu, dass der ALU- Grid Prozessor ohne Sprungvorhersage arbeitet. Diese Sprungvorhersage kann in Superskalar-Prozessoren bei falschen Voraussagen weitere deutliche Leistungseinbußen verursachen. Außerdem führt das Fehlen der Sprungvorhersage zu vorhersagbarem Laufzeitverhalten des ALU-Grid Prozessors .
In dem vorherigen Beispiel ist zu erkennen, dass das ALU-Grid nur zu einem sehr geringen Prozentsatz ausgelastet ist. Werden die Architekturregister nicht direkt auf die Spalten des Grid abgebildet, sondern lediglich wenige ALUs pro Zeile integriert die von allen Registerspalten genutzt werden können, so lässt sich die Anzahl an ALUs reduzieren. Ebenso ist dadurch auch eine Spezialisierung der ALUs möglich, so dass nicht alle ALUs als komplexe Multi-Funktions-ALUs realisiert werden müssen. Evtl. kann hierbei eine Art Register-Renaming angewandt werden, d. h. eine Spalte ist nicht fest einem Register zugeordnet, sondern die Zuordnung wechselt von Zeile zu Zeile.
Weiterhin ist im vorherigen Beispiel zu sehen, dass die Dekodier- und Konfigurationseinheit sehr lange Zeit (13 von 15 Schleifendurchläufen) nicht benötigt wurde. Die Integration eines geeigneten Energiesparmechanismus, z. B. durch dynamische Abschaltung der Einheit (en) , ist hier möglich. Gleiches gilt für nicht benötigte ALU-Zeilen unterhalb der zuletzt benötigten ALU. Da die beschriebene Architektur in Bezug auf die Anzahl an Zeilen frei skalierbar ist, besteht die Möglichkeit einer Minimal-Implementierung mit zwei Zeilen für den Einsatz in mobilen (Kleinst-) Systemen oder durch Kontext-gesteuerte Abschaltung von Zeilen (z. B. wenige aktive Zeilen bei Batteriebetrieb und viele aktive Zeilen bei Netzbetrieb von Notebooks) .
Da jede der Speicherzugriffseinheiten nur einem Lade/Speicherbefehl zugeordnet werden kann, ist die Implementierung effizienter Streaming-Buffer direkt in jeder Speicherzugriffseinheit von Vorteil. Bereits das einfache Laden einer kompletten Cache-Line direkt in eine Speicherzugriffseinheit kann hier enorme Leistungsvorteile bringen. Die Speicherzugriffseinheiten können bei vorhandenen Daten ebenfalls asynchron arbeiten, was bei dem vorherigen Beispiel eine Verkürzung der Laufzeit eines Schleifendurchlaufs von 1-1,5 Takten bewirken würde. Auch die Nachteile des Zeitzähler-Verfahrens zur Synchronisation werden hier sichtbar: Erstens muss bei einem Cache-Miss die „Zeit" vollständig angehalten werden, d. h. Berechnungen, die gleichzeitig zum Hauptspeicher-Zugriff erfolgen könnten, können ihren Vorteil nicht ausspielen. Zweitens muss beim Zeitzähler-Verfahren immer mit dem schlechtesten Fall gerechnet werden, d. h. es muss immer damit gerechnet werden, dass alle zugeordneten Befehle auch ausgeführt werden müssen. Im Beispiel benötigten alle Schleifen- durchläufe dieselbe Zeit, egal ob die Negation ausgeführt werden muss oder nicht . Beide Probleme tauchen bei den beiden Token-Verfahren nicht auf .
Es ist nicht sinnvoll (und auch teilweise nicht möglich) , aufwendige Funktionen wie Divisionen oder Gleitkommaberechnungen direkt in den asynchronen ALUs zu integrieren. Wird eine Technik verwendet, bei der, wie weiter oben beschrieben, wenige ALUs pro Zeile von allen Spalten genutzt werden können, so können auch Spezial-Ausführungseinheiten eingesetzt werden, die lediglich eine Aufgabe erfüllen können (z. B. Division) . Hier ist es allerdings nicht sinnvoll, pro Zeile eine eigenständige Divisionseinheit zu realisieren. Vielmehr besteht die Möglichkeit, in jeder Zeile so genannte virtuelle Einheiten zu implementieren (siehe Figur 6) . Durch virtuelle Einheiten werden in jeder Zeile lediglich alle benötigten Anschlüsse (Ein- und Ausgänge) realisiert. Sind in einer Zeile alle Token vorhanden, d. h. die Arbeitsdaten stehen zur Verfügung, so kann die entsprechende Berechnung von einer mit der virtuellen Einheit verbundenen, zentralen (nunmehr getakteten) Spezial-Ausführungseinheit ausgeführt werden. Dabei kann die Berechnung auch gepipelined durchgeführt werden, so dass mehrere dieser Berechnungen zeitüberlappt stattfinden können. Diese Erweiterung kann nur sinnvoll integriert werden, wenn eines der beiden Token-basierten Synchronisations- verfahren zum Einsatz kommt.
Aus der Compiler-Technik ist ein Verfahren zur optimierten Verarbeitung von Schleifen bekannt, das sog. Software-Pipelining. Dabei wird der Programmcode eines Schleifenkörpers so gestaltet, dass bei der Abarbeitung einer Iteration bereits Berechnungen für die nächste Iteration durchgeführt werden. Dafür werden meist andere Register als die tatsächlich benötigten verwendet und die Ergebnisse zu gegebener Zeit in die relevanten Register kopiert.
Ist der realisierte ALU-Grid Prozessor mit Zwischenregistern ausgestattet, so bietet sich eine andere Art des Pipelining an: echtes Hardware-
Pipelining. Dabei können die Zwischenregister als Pipeline-Register genutzt werden. Diese Technik funktioniert allerdings nur, wenn das Ergebnis des kritischen Pfads einer Iteration nicht für die nächste Iteration benötigt wird. Damit der ALU-Grid Prozessor das Pipelining umsetzen kann, ist entweder eine Befehlssatz-Erweiterung oder eine Erweiterung der Dekodiereinheit erforderlich. In beiden Fällen muss die Konfigurationseinheit mitgeteilt bekommen, welche Register den nicht benötigten kritischen Pfad darstellen und dass Pipelining hier möglich ist. Dies wird am folgenden Beispiel deutlich: Würde das weiter oben beschriebene Beispielprogramm den Vektor nicht aufsummieren, sondern lediglich den Betrag jedes Elements wieder in den Speicher zurückschreiben, so wäre der kritische Pfad (im Beispiel RO) einer Iteration in der nächsten nicht relevant. Im Folgenden ist der abgewandelte Programmcode des Beispiels aufgeführt. Figur 7 zeigt eine mögliche Zuordnung (ab der zweiten Iteration) der Befehle für die Ausführung in Form einer Pipeline. Ein zusätzlicher Befehl für das Pipelining wurde hier nicht berücksichtigt.
raove Rl, #15 ;15 Datenwerte move R2,#adresse ; Startadresse des Vektors loop: load R3, [R2] ,-ein Element aus dem ,-Speicher lesen jmpnl R3,not_negativ ;ist dieser nicht negativ? neg R3 /wenn negativ: negieren not_negativ: move RO, R2 /Adresse für STORE / Zwischenspeichern add R2,#4 /Adresse für nächstes /Element erhöhen störe [RO] ,R3 /absoluten Wert wieder in /den Speicher schreiben sub Rl, #1 /ein Datenelement wurde / abgearbeitet jmpnz Rl, loop /noch mehr Datenwerte?
Bei der Pipeline-Ausführung muss beachtet werden, dass die Datenrückführung hier im Beispiel nicht vom Ende des Grid sondern von den Zwischenregistern in die Top-Register stattfinden muss. Die Entscheidung über das Schleifenende muss aber dennoch nach der letzten Pipelinestufe gefällt werden. Wurde der obere Teil einer Iteration bereits ausgeführt, obwohl die Schleifenbedingung nicht mehr erfüllt ist, so sind keine weiteren Maßnahmen bzgl . der Register notwendig. Da nur mit den Werten am Ende des Grid weitergearbeitet wird, werden automatisch alle Zwischenergebnisse in den Zwischenregistern verworfen. Erfolgen hingegen in einer anderen als der letzten Pipelinestufe Schreibzugriffe auf den Hauptspeicher, so müssen diese unterdrückt werden, bis klar ist, ob die jeweilige Iteration überhaupt ausgeführt werden muss .
Bei einer weiteren beispielhaften Ausgestaltung wird angenommen, dass der im Beispiel verwendete ALU- Grid Prozessor Zwischenregister besitzt. In diesem Fall können Daten aus den entsprechenden Zeilen innerhalb des ALU-Grid abgegriffen werden, um die Dekodierung weiterer Befehle schon während der Laufzeit der
Ausführungsphasen zu starten.
Jetzt wird deutlich, aus welchem Grund für den ALU-Grid Prozessor nicht unbedingt eine Branch- Prediction notwenig ist: die beiden möglichen Pfade eines kurzen Sprungs können gleichzeitig mit der Predication-Technik im ALU-Grid angeordnet werden oder es besteht die Möglichkeit, den einen Pfad (Schleifenkörper) im ALU-Grid auszuführen, während der andere Pfad (nachfolgender Programmcode) für die spätere Verwendung bereits unterhalb im ALU-Grid angeordnet wird. Es bleiben somit nur noch Sprünge über große Distanzen, die keiner Schleife zugeordnet werden können, und unbedingte Sprünge, die aber bereits in der Dekodierungsphase aufgelöst werden.
Wird eine Schleife mit mehreren Aussprung-Punkten (z. B. bei einer C-Break-Anweisung) im ALU-Grid ausgeführt, so kann die Dekodier- und Konfigurations- einheit Befehle von allen möglichen Sprungzielen vorab dekodieren und entsprechende „theoretische" Anordnungen in einem Zwischenspeicher, ähnlich einem Trace-Cache, Zwischenspeichern. Wird einer der Sprünge genommen, so -kann—d-i-e—berechnete Konfiguration sehr schnell in das ALU-Grid geladen und die Ausführung fortgesetzt werden. Noch schneller kann die Umkonfiguration stattfinden, wenn nicht ein zentraler Zwischenspeicher verwendet wird, sondern die Konfigurationsregister im ALU-Grid mehrfach vorhanden und in sog. Planes angeordnet sind. Dabei ist es möglich, bei der Ausführung mit einem Plane zu arbeiten, während in ein anderes Plane gleichzeitig eine neue Konfiguration geschrieben wird. Somit kann von einer Konfiguration zur nächsten unmittelbar gewechselt werden.
Bei dem Einsatz eines Trace-Konfigurations-Cache oder mehreren Konfigurations-Planes wird der Einsatz einer Art Branch-Prediction sinnvoll. Ihre Aufgabe besteht dabei aber nicht darin, eine Vorhersage darüber zu machen, ob ein spezieller Sprung genommen wird oder nicht, sondern darin, mit welchem Sprung eine Schleife voraussichtlich verlassen wird. Diese Vorhersage ist dafür interessant, welcher Programmcode zuerst dekodiert und im Trace-Cache oder einem anderen Plane abgelegt wird, damit er dann beim tatsächlichen Verlassen der Schleife zur Verfügung steht. Je länger eine Schleife ausgeführt wird, desto weniger wichtig wird diese Vorhersage, da immer mehr Aussprung-Punkte bis zum Verlassen dekodiert worden sind.

Claims

Patentansprüche
1. Prozessor, zumindest umfassend
- eine Anordnung aus mehreren Zeilen konfigurierbarer Ausführungseinheiten, die durch konfigurier- bare Datenverbindungen von Zeile zu Zeile zu mehreren Ketten von Ausführungseinheiten verbunden werden können, und jeweils zumindest einen Dateneingang und Datenausgang aufweisen, mit einem Rückführungsnetzwerk, über das ein am Datenausgang der untersten Ausführungseinheit jeder Kette ausgegebener Datenwert an ein Top-Register der Kette überführt werden kann, wobei die Ausführungseinheiten jeder Kette so ausgebildet sind, dass sie während Ausführungsphasen an ihrem Dateneingang anliegende Datenwerte entsprechend ihrer momentanen Konfiguration behandeln und die behandelten Datenwerte an ihrem Datenausgang für die in der Kette nachfolgenden Ausführungseinheiten bereitstellen, - eine zentrale Dekodier- und Konfigurations- einheit, die während mehrerer durch Ausführungs- phasen getrennter Dekodierphasen aus einem einzelnen eingehenden sequentiellen Befehlsstrom zur Laufzeit eigenständig Ausführungseinheiten auswählt, Konfigurationsdaten für die ausgewählten Ausführungseinheiten erzeugt und die ausgewählten Ausführungseinheiten über ein Konfigurations- netzwerk zur Ausführung der Befehle konfiguriert,
- eine mit den Ausführungseinheiten über Daten- leitungen verbundene Sprung-Kontrolleinheit für die Behandlung von Sprungbefehlen und - ein oder mehrere mit den Ausführungseinheiten über Datenleitungen verbundene Speicherzugriffseinheiten zur Ausführung von Speicherzugriffen.
2. Prozessor nach Anspruch 1, dadurch gekennzeichnet, dass zwischen allen oder einzelnen Zeilen der Anordnung Zwischenregister angeordnet sind, die mit einer Bypass-Technik ausgestattet sind, über die eingehende Datenwerte bei Bedarf auch ohne Speicherung durchgeschleift werden können.
3. Prozessor nach Anspruch 1 oder 2 , dadurch gekennzeichnet, dass Datenausgänge und Dateneingänge mehrerer Ausführungseinheiten jeder Kette und/oder gegebenenfalls vorhandene Zwischenregister mit dem Rückführungsnetzwerk verbunden sind, um an einer weiter unten liegenden Stelle der Ketten erhaltene Datenwerte an einer weiter oben liegenden Stelle der Ketten wieder einspeisen zu können.
4. Prozessor nach einem oder mehreren der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Ausführungseinheiten jeder Zeile über ein Zeilenrouting-Netzwerk miteinander verbunden sind, wobei jeder Zeile über das Zeilenrouting-Netzwerk ein oder mehrere Speicherzugriffseinheiten zugeordnet sind.
5. Prozessor nach einem oder mehreren der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Ausführungseinheiten mit der Sprung- Kontrolleinheit verbundene Predication-Eingänge aufweisen, über die die Sprung-Kontrolleinheit während der Ausführungsphasen steuert, ob die Befehle in den jeweiligen Ausführungseinheiten tatsächlich ausgeführt werden.
6. Prozessor nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass einige der Ausführungseinheiten mehreren Ketten zugeordnet werden können.
7. Prozessor nach Anspruch 6, dadurch gekennzeichnet, dass zumindest ein Teil der Ausführungseinheiten, die mehreren Ketten zugeordnet werden können, für spezielle Funktionen ausgebildete Ausführungseinheiten sind.
8. Prozessor nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass einige oder alle Zeilen eine virtuelle Ausführungseinheit aufweisen, die alle benötigten Anschlüsse für Dateneingang und Datenausgang bereitstellt und mit ein oder mehreren zentralen
Spezial-Ausführungseinheiten verbindbar ist, wobei die virtuelle Ausführungseinheit nur dazu dient, die am Dateneingang anliegenden Datenwerte von der Spezial-Ausführungseinheit behandeln zu lassen und den behandelten Datenwert an ihrem Datenausgang bereitzustellen.
9. Prozessor nach Ansprüche 8 , dadurch gekennzeichnet , dass virtuelle Ausführungseinheiten mehrerer Zeilen mit einem Arbiter verbunden sind, der den Zugriff auf die ein oder mehreren zentralen Spezial- Ausführungseinheiten steuert .
10. Prozessor nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der Prozessor einen Energiesparmechanismus aufweist, der die Dekodier- und Konfigurations- einheit und/oder nicht benötigte Zeilen der Anordnung während der Ausführungsphase abschaltet.
11. Prozessor nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die Speicherzugriffseinheiten Streaming-Buffer aufweisen.
12. Prozessor nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass ein zentraler Zwischenspeicher für Konfigurationsdaten vorgesehen ist und/oder jede Ausführungseinheit mehrere Konfigurationsregister für Konfigurationsdaten aufweist und die Dekodier- und Konfigurationseinheit so ausgebildet ist, dass sie bereits während der Ausführungsphasen weitere Befehle des sequentiellen Befehlsstroms vorab dekodiert und die zugehörigen Konfigurationen im Zwischenspeicher oder in für die momentane
Konfiguration nicht genutzten Konfigurations- registern ablegt, um die nächste Konfiguration bei Bedarf schnell bereitstellen zu können.
13. Prozessor nach Anspruch 12 , dadurch gekennzeichnet, dass die Dekodier- und Konfigurationseinheit so ausgebildet ist, dass sie bei der Ausführung einer Programmschleife mit mehreren möglichen Sprungzielen während der Ausführungsphase der Programmschleife Befehle der möglichen Sprungziele vorab dekodiert und die zugehörigen Konfigurationen im Zwischenspeicher oder in für die momentane Konfiguration nicht genutzten Konfigurations- registern ablegt, um die nächste Konfiguration bei Bedarf schnell bereitstellen zu können.
14. Prozessor nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass Mittel für den Einsatz von Tokens in den Ketten der Anordnung zur Synchronisation vorgesehen sind.
PCT/DE2007/001022 2006-06-12 2007-06-12 Prozessor mit internem raster von ausführungseinheiten WO2007143972A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/304,655 US20090249028A1 (en) 2006-06-12 2007-06-12 Processor with internal raster of execution units

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006027181A DE102006027181B4 (de) 2006-06-12 2006-06-12 Prozessor mit internem Raster von Ausführungseinheiten
DE102006027181.5 2006-06-12

Publications (2)

Publication Number Publication Date
WO2007143972A2 true WO2007143972A2 (de) 2007-12-21
WO2007143972A3 WO2007143972A3 (de) 2008-03-27

Family

ID=38663830

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2007/001022 WO2007143972A2 (de) 2006-06-12 2007-06-12 Prozessor mit internem raster von ausführungseinheiten

Country Status (3)

Country Link
US (1) US20090249028A1 (de)
DE (1) DE102006027181B4 (de)
WO (1) WO2007143972A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2095226A1 (de) * 2006-12-11 2009-09-02 Nxp B.V. Virtuelle funktionseinheiten für vliw-prozessoren
US20150052330A1 (en) * 2013-08-14 2015-02-19 Qualcomm Incorporated Vector arithmetic reduction
JP6553694B2 (ja) * 2017-09-25 2019-07-31 Ｎｅｃスペーステクノロジー株式会社 プロセッサエレメント、プログラマブルデバイス及びプロセッサエレメントの制御方法
US20230359558A1 (en) * 2022-05-09 2023-11-09 Advanced Micro Devices, Inc. Approach for skipping near-memory processing commands

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1577789A2 (de) * 2003-12-22 2005-09-21 Sanyo Electric Co., Ltd. Rekonfigurierbare Schaltung mit Verbindungseinrichtung

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023753A (en) * 1997-06-30 2000-02-08 Billion Of Operations Per Second, Inc. Manifold array processor
US6681341B1 (en) * 1999-11-03 2004-01-20 Cisco Technology, Inc. Processor isolation method for integrated multi-processor systems
JP2004334429A (ja) * 2003-05-06 2004-11-25 Hitachi Ltd 論理回路及びその論理回路上で実行するプログラム
JP4728581B2 (ja) * 2004-02-03 2011-07-20 日本電気株式会社 アレイ型プロセッサ
JP4275013B2 (ja) * 2004-06-21 2009-06-10 三洋電機株式会社 データフローグラフ処理装置、処理装置、リコンフィギュラブル回路。

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1577789A2 (de) * 2003-12-22 2005-09-21 Sanyo Electric Co., Ltd. Rekonfigurierbare Schaltung mit Verbindungseinrichtung

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
BRACY A ET AL: "Dataflow Mini-Graphs: Amplifying Superscalar Capacity and Bandwidth" MICROARCHITECTURE, 2004. MICRO-37 2004. 37TH INTERNATIONAL SYMPOSIUM ON PORTLAND, OR, USA 04-08 DEC. 2004, PISCATAWAY, NJ, USA,IEEE, 4. Dezember 2004 (2004-12-04), Seiten 18-29, XP010859309 ISBN: 0-7695-2126-6 *
BURGER D ET AL: "Scaling to the End of Silicon with EDGE Architectures" COMPUTER, IEEE SERVICE CENTER, LOS ALAMITOS, CA, US, Bd. 37, Nr. 7, Juli 2004 (2004-07), Seiten 44-55, XP011115169 ISSN: 0018-9162 *
CLARK N ET AL: "Application-Specific Processing on a General-Purpose Core via Transparent Instruction Set Customization" MICROARCHITECTURE, 2004. MICRO-37 2004. 37TH INTERNATIONAL SYMPOSIUM ON PORTLAND, OR, USA 04-08 DEC. 2004, PISCATAWAY, NJ, USA,IEEE, 4. Dezember 2004 (2004-12-04), Seiten 30-40, XP010859310 ISBN: 0-7695-2126-6 *
JONG-EUN LEE ET AL: "Evaluating memory architectures for media applications on coarse-grained reconfigurable architectures" APPLICATION-SPECIFIC SYSTEMS, ARCHITECTURES, AND PROCESSORS, 2003. PROCEEDINGS. IEEE INTERNATIONAL CONFERENCE ON 24-26 JUNE 2003, PISCATAWAY, NJ, USA,IEEE, 24. Juni 2003 (2003-06-24), Seiten 166-176, XP010645218 ISBN: 0-7695-1992-X *
JONG-EUN LEE ET AL: "Reconfigurable ALU Array Architecture with Conditional Execution" INTERNATIONAL SOC DESIGN CONFERENCE, XX, XX, 25. Oktober 2004 (2004-10-25), XP002376739 *
OZAWA M ET AL: "A CASCADE ALU ARCHITECTURE FOR ASYNCHRONOUS SUPER-SCALAR PROCESSORS" IEICE TRANSACTIONS ON ELECTRONICS, ELECTRONICS SOCIETY, TOKYO, JP, Bd. E84-C, Nr. 2, Februar 2001 (2001-02), Seiten 229-237, XP001044150 ISSN: 0916-8524 *
YEHIA S ET AL: "From sequences of dependent instructions to functions : an approach for improving performance without ilp or speculation" COMPUTER ARCHITECTURE, 2004. PROCEEDINGS. 31ST ANNUAL INTERNATIONAL SYMPOSIUM ON MUNCHEN, GERMANY JUNE 19-23, 2004, PISCATAWAY, NJ, USA,IEEE, 19. Juni 2004 (2004-06-19), Seiten 238-249, XP010769379 ISBN: 0-7695-2143-6 *

Also Published As

Publication number Publication date
DE102006027181B4 (de) 2010-10-14
DE102006027181A1 (de) 2007-12-13
WO2007143972A3 (de) 2008-03-27
US20090249028A1 (en) 2009-10-01

Similar Documents

Publication Publication Date Title
DE69228586T2 (de) Dynamischer, in einer Array-Architektur im Mehrfachmodus arbeitender Parallelprozessor
DE102018005181B4 (de) Prozessor für einen konfigurierbaren, räumlichen beschleuniger mit leistungs-, richtigkeits- und energiereduktionsmerkmalen
DE102018005172A1 (de) Prozessoren, verfahren und systeme mit einem konfigurierbaren räumlichen beschleuniger
DE102018006735A1 (de) Prozessoren und Verfahren für konfigurierbares Clock-Gating in einem räumlichen Array
DE69129569T2 (de) Maschine mit sehr langem Befehlswort für leistungsfähige Durchführung von Programmen mit bedingten Verzweigungen
DE69130723T2 (de) Verarbeitungsgerät mit Speicherschaltung und eine Gruppe von Funktionseinheiten
EP0961980B1 (de) Verfahren zur selbstsynchronisation von konfigurierbaren elementen eines programmierbaren bausteines
EP1228440B1 (de) Sequenz-partitionierung auf zellstrukturen
DE102018005169A1 (de) Prozessoren und verfahren mit konfigurierbaren netzwerkbasierten datenflussoperatorschaltungen
DE102018006889A1 (de) Prozessoren und Verfahren für bevorzugte Auslegung in einem räumlichen Array
DE69415126T2 (de) Gegenflusspipelineprozessor
DE112016001836T5 (de) Energieeffiziente Prozessorkernarchitektur für Bildprozessoren
DE3586603T2 (de) Datenprozessor fuer interpretierende und kompilierte sprache.
EP1537486A1 (de) Rekonfigurierbare sequenzerstruktur
DE112015005597T5 (de) Verknüpfungsfähige Parallelausführungs-Schicht einer Ausgabewarteschlange für einen Prozessor
DE4420703A1 (de) Mikrocomputer
DE19506990A1 (de) Einrichtung zur Datenumleitung in einem Prozessor mit mehreren Ausführungseinheiten
EP0825540B1 (de) Prozessor mit Pipelining-Aufbau
DE102006027181B4 (de) Prozessor mit internem Raster von Ausführungseinheiten
EP1472616B1 (de) Rekonfigurierbare elemente
EP1483682A2 (de) Reconfigurierbarer prozessor
EP1117037A2 (de) Datenverarbeitungsvorrichtung zum parallelen Verarbeiten von unabhängigen Prozessen (Threads)
DE19843663A1 (de) Konfigurierbarer Hardware-Block
DE102013114508B4 (de) Blockbasierte Signalverarbeitung
DE102010003512A1 (de) Geteilte zentrale Verarbeitung von Daten

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 12304655

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07764356

Country of ref document: EP

Kind code of ref document: A2