WO2007014404A1 - Digitale rechnereinrichtung mit parallelverarbeitung - Google Patents

Digitale rechnereinrichtung mit parallelverarbeitung Download PDF

Info

Publication number
WO2007014404A1
WO2007014404A1 PCT/AT2005/000311 AT2005000311W WO2007014404A1 WO 2007014404 A1 WO2007014404 A1 WO 2007014404A1 AT 2005000311 W AT2005000311 W AT 2005000311W WO 2007014404 A1 WO2007014404 A1 WO 2007014404A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
data
loop
parallel
processing
Prior art date
Application number
PCT/AT2005/000311
Other languages
English (en)
French (fr)
Inventor
Heinz Gerald Krottendorfer
Karl Heinz GRÄBNER
Manfred Riener
Original Assignee
On Demand Microelectronics 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
Application filed by On Demand Microelectronics Ag filed Critical On Demand Microelectronics Ag
Priority to PCT/AT2005/000311 priority Critical patent/WO2007014404A1/de
Priority to US11/997,874 priority patent/US20080320276A1/en
Publication of WO2007014404A1 publication Critical patent/WO2007014404A1/de

Links

Classifications

    • 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/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8007—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors single instruction multiple data [SIMD] multiprocessors
    • G06F15/8015—One dimensional arrays, e.g. rings, linear arrays, buses
    • 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/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • 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

Definitions

  • a common example of the multiple implementation of computational components is the so-called "superpipelining" calculator, where the calculator contains a chain of arithmetic units as computation levels, and it processes instructions not only one after the other, but interleaved in the individual computation stages, the so-called " pipeline stages ".
  • a command is only completed when all arithmetic unit processing steps have been completed.
  • the individual computation stages are decoupled in time, and therefore several instructions within the arithmetic unit can be processed simultaneously. For example, a new command is processed in the first stage of the calculation, the previous command is simultaneously edited in the second stage. level, etc .; However, full performance can only be obtained if all pipeline stages are filled with instructions.
  • PACT XPP architecture in which programmable cells, i. Objects are provided, cf. e.g. http; // www. pactcorp. com / xneu / download / xpp white_pa- per.pdf, The XPP White Paper, Release 2.1, A Technical Perspective, Copyright: PACT Informationstechnologie GmbH; March 27, 2002.
  • these objects are interconnected so that the respective desired application is displayed.
  • For this assignment of objects to each other is therefore a switchable, i. configurable data connection network required.
  • the present digital computing device is not only suitable for processing such vector algorithms, but also for processing scalar algorithms or combinations of scalar algorithms and vector algorithms.
  • the computer device which is in particular a program-controlled computer device, a plurality of arithmetic units are implemented, together with associated data memories, whereby parallel arithmetic units are obtained which can interact efficiently, so that paralleling actually achieves an increase in computation power corresponding to the outlay.
  • parallel arithmetic units are obtained which can interact efficiently, so that paralleling actually achieves an increase in computation power corresponding to the outlay.
  • parallel arithmetic units are obtained which can interact efficiently, so that paralleling actually achieves an increase in computation power corresponding to the outlay.
  • parallel processing units for this interaction of importance is a corresponding control in the form that not only within the individual arithmetic units, a data transfer between the arithmetic unit and the associated data storage is carried out, but also between the parallel processing units with each other a data transfer is made possible.
  • the present computer architecture enables the desired high computing power by a "massive" parallel processing, in which the parallel computing units work together optimally, so that the desired computing performance is actually achieved by the parallelization.
  • the data transfer rates ie the rates at which data runs into and out of a computer
  • the data transfer rates are becoming ever higher, although data transfers between the parallel computing units in the computer system are becoming increasingly common, but this is not a problem in the present computer architecture.
  • the multi-processor systems according to the prior art which are unsuitable for such applications, since they require too much additional temporal synchronization effort for data exchange between the processors.
  • each of the parallel-connected computation units is also assigned its own program memory, just as in the case of the provision of the global arithmetic unit the latter is preferably allocated its own program memory.
  • the global arithmetic unit is, in order to meet any computational requirements, preferably connected to both outputs and inputs of the parallel processing units.
  • FIG. 2 shows a similar block diagram of such a digital computing device, in which, compared to FIG. 1, the arithmetic units are shown in simplified form, but the program memories assigned to them separately are illustrated;
  • Fig. 5 is a block diagram similar to Figure 1, the computing device in the application in a real vector processing, the individual thereby active data bus connections, which illustrate the parallel operation of the individual arithmetic units are illustrated with reinforced lines.
  • Fig. 6 is a calculation scheme given in such a vector processing;
  • Fig. 7 is a diagram for illustrating the execution of a typical program in such a true vector processing.
  • FIGS. 8, 9 and 10 as well as FIGS. 11, 12 and 13 show similar block diagrams and diagrams as shown in FIGS. 5, 6, 7 for illustration of the operation with vector processing with scalar end result (FIGS. 8, 9 and 10) and FIGS in scalar processing ( Figures 11, 12 and 13).
  • a digital computing device 1 is shown with parallel processing, wherein a number N of mutually parallel computing units 2.1, 2.2, 2.3 2.N, also
  • Each parallel-connected arithmetic unit 2.i contains, as can be seen in particular in FIG. 1 in the first arithmetic unit 2.1, an arithmetic unit 5 which is connected to input registers 6 (input register A) and 7 (input register B) for the data to be processed. Furthermore, in each arithmetic unit 2.i, see the arithmetic unit 2.1 in FIG. 1, two data memories 8 (data memory A) and 9 (data memory B) are provided, from which the data to be processed are taken over into the input registers 6, 7 so that they can be processed in the arithmetic unit 5 in the desired manner.
  • a data bus system 10 is provided for internal data transfers between the data stores or input registers and the arithmetic units; Furthermore, a data bus system 11 for a data transfer between the individual arithmetic units 2.1, 2.2 ... 2.i ... 2.N provided, this data bus system 11 for the data transfer between the computing units comprises a global data bus 11.1, a register A data bus 12 and a register B data bus 14.
  • Another data bus system 15 is used for data transfer between the arithmetic units 2.i and the global unit 4; Finally, a general data bus system 16 is provided for external data inputs or data outputs, in order to supply data to be processed to the computer device 1 or to output the results of the calculations from the computer device 1.
  • the individual parallel computing units 2.1 operate as autonomous parallel units, each with its own, independent data memories 8, 9 together with integrated address generator and with its own program memory (as described below with reference to FIG explained) work together.
  • the central program sequence control 3 eliminates the need for a separate, temporal synchronization effort for data exchange between the arithmetic units 5 of the arithmetic units 2.i, so that no calculation clocks are required for the synchronization of data transfers. Instead, an efficient global coordination of all calculations in the arithmetic units 2.i simply follows that all actions in the computing device 1 are in a rigid temporal relationship to one another, which is given by the program run control 3. In this way, it is precisely defined at each point in time which data is present where in the computer device 1. By this parallel operation of the individual arithmetic units 2.i, the potential computing power of the computer device 1 can be increased by a factor of N.
  • a computational cycle consists of an arithmetic operation, each linking two values together, one of the two values usually being the data value of the data vector and the second value being a coefficient.
  • Each arithmetic unit 2.i includes, as mentioned, two independent data memories 8, 9. Thus, in a single cycle, an operation may be performed as required with two values.
  • the data bandwidth of the entire computer device 1 is thus optimized for vector algorithms. Since all assigned arithmetic units 2.i perform similar calculations in a vector processing, the computer resources of all arithmetic units 2.i are therefore always fully utilized.
  • Each arithmetic unit 2.i can be programmed independently, ie independently. Therefore, in the individual arithmetic units 2.i independent scalar algorithms can be processed.
  • a rigid synchronization of all the arithmetic units 2.i in the computer device 1 takes place.
  • this has the advantage that data transfers between individual scalar algorithms are processed in different arithmetic units 2.i. , No additional Calculation clocks (see the clock input CLK in Fig. 1) are necessary for synchronization.
  • the disadvantage is possibly that the efficient use of the computer device 1 requires a balanced distribution of the algorithms to be calculated on the arithmetic units 2.i.
  • the first arithmetic unit 2.1 is occupied by a first scalar algorithm requiring 100 cycles, the result of which is needed for a second scalar algorithm, which in turn is calculated in the second arithmetic unit 2.2 and requires only 10 cycles, the second arithmetic unit 2.2 used only in 10 cycles, and then it waits 90 cycles for the next result from the first arithmetic unit 2.1.
  • each arithmetic unit 2.i as already mentioned, its own program memory 17.1 ... 17. i ... 17. N is assigned, cf. Fig. 2, as well as the global unit 4 own program memory 17. G listened. In Fig. 1, these separate program memory 17.i are to be considered as contained in the program control 3 components.
  • the program sequence control 3 regulates the program sequence in a state machine 18. It determines when operations have to be executed ("executed") according to the software program and when a new command is fetched ("faked"). must become.
  • the program sequence control 3 controls the program processing as mentioned centrally for all arithmetic units 2.i. In the case of a special treatment in the computer device 1, the program sequence control 3 is stopped, and corresponding steps are initiated in a separate state machine. Examples of such special treatments are e.g.
  • the program scheduler 3 has the following states according to the state machine 18 of FIG. 3:
  • Loop state 25 (,, ST_LOOP ⁇ ): In this state 25 "ST_LOOP", the execution of a program loop takes place.From the state 25, “ST-LOOP” returns to state 21 only when the program loop is completely executed "ST_FEEX” jumped (see action 27) During state 25 "ST_LOOP", a program-defined number of successive commands is repeatedly executed. The number of cyclic repetitions of the program loop is also specified by a separate command per program.
  • Fig. 4 a normal program execution is illustrated in the left part, wherein according to the state ST_FE, s. Field 30, first the next instruction - according to block 31 - is fetched from the current address PC. The next command is then expected at the address PC + 1. Thus, the automatically fetched from this point command can be executed in the next cycle.
  • Such a program loop is triggered by the "START_LOOP" command, leaving state 34 "ST_FEEX” and, in the example of Fig. 4, jumping to the first loop as mentioned, starting with field 42 "ST_LOOP # 0" Value of the program counter PC and the current command stored to prepare for "enable” the command execution, s. Block 43 in FIG. 4. It should be noted here that at the end of a loop the first instruction within the loop is repeated, which corresponds to a program jump, since the next program line is not at the position PC + 1. Consequently, the next instruction would have to be fetched again in an extra cycle, as in jump instructions to state 34 "ST_FEEX", which cause an additional fetch state ST_FE according to field 30.
  • a total of three interleaved loops are provided, which are illustrated in FIG. 4, in the right half thereof, next to one another, each beginning with a field ST_LOOP # 0 or # 1 or # 2.
  • an interrogation field 44 is used to query whether an inner loop is to be started, and if not, a further interrogation field 45 queries whether the loop has ended; if not, the next instruction is fetched in block 46 and returned to the beginning of the loop, box 42. If, however, the loop has been processed, it is queried in accordance with an interrogation field 47 whether the last loop has already been reached, ie. if the loop counter is at the preset maximum value "LOOPMAX", and if not, the first instruction is fetched from the instruction register for the next loop as mentioned above, see block 48, and the loop counter is incremented by one.
  • STOP_LOOP the end of the loop is indicated by a "STOP_LOOP" command, which indicates that the loop has already passed enough times, which is the case when the loop counter, as noted, has the preprogrammed value "LOOPMAX " has reached. If this is the case, loop processing is considered completed and normal program execution continues at field 34 "ST_FEEX.” Otherwise, as mentioned, increasing the value of the loop counter starts the next loop pass.
  • Fig. 4 is also with compounds 51, 51 ', 51 "indicated that when the respective loop 50 etc. or 49 etc. or 42 etc. is processed, the next higher loop, namely to their respective Beginning according to field 49 or 42, or returned to field 32.
  • the computing device 1 described so far supports the efficient processing of three classes of algorithms, namely true vector processing, scalar end-result vector processing, and scalar processing; These processes will be explained in more detail below.
  • the input data each form a data vector, i. a set of individual data values, and the result is again a data vector, that is, a set of individual data values.
  • the N slices 2.i receive input data from the data memories 8, 9 or from outside via the external data input (bus system 16).
  • the data is transferred to the input registers 6, 7, which in turn serve the respective arithmetic unit 5, which performs corresponding arithmetic operations.
  • the result can be returned to the input registers 6, 7 again via a slice-internal data bus in order to allow an iterative calculation.
  • one of the two input registers 6 or 7 can also fetch data for the next processing cycle from the associated data memory 8 or 9. Thereafter, the calculation is again carried out in the arithmetic unit 5.
  • the final result can either be stored back into the data memories 8, 9 via the input registers 6, 7, or it is output via the external data output, ie the input / output bus system 16.
  • FIG. 7 shows the execution of a program typical for vector processing. Instructions that control the program scheduler 3 are taken from a common program memory 60 containing general instructions. The individual slices 2.i are controlled by their own program memories 17.i. The iterative calculation starts with the command "Loop Start”, see field 61 in Fig. 7) All commands (excluding the command line in which the command “Loop Start” is) to the command “Loop End” (see field The number of repetitions is given in a "LOOPMAX" register, the loading of which is shown schematically in block 63 in FIG. whereupon the "loop start” command follows to start the loop computation according to field 61.
  • All the program memories 17.i are driven via the common program counter (PC) .Therefore, the entire processing is always line by line, each individual program line being applied to the individual program memories 17 i and the general program memory 60. All the subprograms in the individual slices 2.i - precalculation 64. i, iterative calculation 65. i, postal costing 66. i - consist of freely selectable program instructions for each arithmetic unit 2.i. Only the program flow is centrally controlled For example, the number of iterative calculations is determined by loading the "LOOPMAX" register for all slices 2.i. According to block 67, it is checked in each case whether the loop count has reached the maximum loop number ("LOOPMAX”), and if not, the next loop is calculated (see also the "connection" 68 "next loop" in FIG.
  • PC common program counter
  • the input data forms a data vector (a set of individual data values), but the result is a scalar quantity, i.e., a set of individual data values. a single data value.
  • slices arithmetic units
  • a vector processing of the individual values of the data vector ensues, whereafter in the global unit 4 the formation of a scalar final result takes place.
  • This final result can be attributed to all Slices 2.i.
  • the processing of the input data vector is again as already described above with reference to FIGS. 5 to 7 and need not be further explained.
  • the partial results of the calculations which take place in the individual slices 2.i are transferred to the global unit 4.
  • This global unit 4 takes over the partial results of the slices 2.i and forms a single final result through arithmetic operations (for example, the global unit 4 the sum or a scalar product of all partial results).
  • This processing mixture is in turn, in a representation similar to FIG. 6, schematically illustrated in FIG. 9. It is shown how partial values T ⁇ are calculated from input values I 1 in a vector processing P 1 ; From these partial results T 1 , for example by product calculation, the scalar final result 0 is calculated in a global scalar calculation S.
  • FIG. 10 basically corresponds to FIG. 7, so that a further description, for example as regards the grinding operations, can be dispensed with.
  • Fig. 12 shows the calculation of a chain Al, A.2, A.3 ..A. N (generally Ai) of scalar algorithms, ie the total computation is subdivided into sub-computations Ai.
  • the individual calculation stages are processed in adjacent arithmetic units 2.1, 2.2, 2.3... 2N.
  • the transfer of the partial results is carried out by the data bus 11 or II 1 , which concatenates the input registers 6, 7 of the individual slices 2.i, cf. 11. If the partial results T1 have been completed, the final results of the individual partial calculations Ai are placed in the input registers 6, 7 of the individual slices 2.i.
  • Fig. 13 the execution of a typical program is shows, wherein the execution of the partial programs in the arithmetic units 2.i is controlled by the separate slice program memory 17. i.
  • the start values are taken from the respective left neighbor slice. This is done by programming all command registers as data sources to be assigned the slice input port, which is coupled to the command register output of the respective left neighbor slice, as illustrated in FIG.
  • the central program sequence control 3 makes it much easier to synchronously transfer data between all slices.
  • the synchronization is achieved by enabling the input register data buses 13, 14 in the same program line of each slice 2.i.
  • each arithmetic unit 2.i can be programmed completely independently.
  • the fact that data can be transferred from one arithmetic unit to the other via the register data bus 13 or 14 is merely determined by providing the data value in one slice 2. (il) in the same program line of the two affected slice subprograms and this is taken over in the second slice 2.i by switching the register bus 12 and 13 respectively.
  • the respectively affected slice pairs 2. (i-1), 2.i can freely choose whether and when a data transfer between the slices is established.
  • the different arithmetic units 2.i of the computer unit 1 can process different types of algorithms simultaneously; different types of algorithms can be treated in succession, and the computer device 1 can switch between the types of algorithms without requiring additional calculation clocks.
  • All arithmetic units 2.i can be programmed independently and therefore carry out calculations independently.
  • the interconnection of arithmetic units 2.i is done with the data bus structure, which supports the discussed algorithms optimally.
  • the arithmetic units 2.1 can also be different algorithms types are allocated for the calculation, which is made possible by the fact that both the operations performed in the arithmetic units 2.i operations and the interconnection of the data paths via a program can be flexibly defined and changed at any time.
  • all the arithmetic units 2.1 can be programmed separately, it is then possible that different types of algorithms can be processed in different arithmetic units at the same time.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Multi Processors (AREA)

Abstract

Beschrieben wird eine digitale Rechnereinrichtung (1) mit Parallelverarbeitung, mit mehreren parallel einsetzbaren Arithmetikeinheiten (5) und einer ihnen zugeordnete Steuereinheit, wobei die Arithmetikeinheiten (5) mit über Datenbus-Verbindungen (10) zugeordneten Datenspeichern (8, 9) zu parallel geschalteten Recheneinheiten (2.i) mit synchroner Befehlsabarbeitung zusammengefasst sind, denen als Steuereinheit eine zentrale Programmablaufsteuerungseinheit (3) zugeordnet ist.

Description

DIGITALE RECHNEREINRICHTUNG MIT PARALLELVERARBEITUNG
Die Erfindung betrifft eine digitale Rechnereinrichtung mit Parallelverarbeitung, mit mehreren parallel einsetzbaren Arithmetikeinheiten und einer ihnen zugeordneten Steuereinheit.
Parallelverarbeitende Rechnereinrichtungen oder Prozessoren werden immer häufiger für die verschiedensten Anwendungen benötigt; ein Beispiel für eine derartige Anwendung ist die digitale Signalverarbeitung in der Telekommunikation. Diese Anwendungen benötigen immer größere Rechenleistungen in den zur digitalen Verarbeitung vorgesehenen Schaltungen, auch als digitale Signalprozessoren (DSP) bezeichnet.
Im Prinzip gibt es, um die Rechen- oder Prozessorleistung für derartige rechenintensive Aufgaben zu erhöhen, zwei Möglichkeiten, nämlich einerseits das Erhöhen der Verarbeitungs-Taktfre- quenz und andererseits die Mehrfach-Implementierung von Rechnerkomponenten. Was die erste Möglichkeit betrifft, so ist die Erhöhung der Taktfrequenz ein allgemeines Ziel und durch die jeweilige aktuelle Technologie vorgegeben bzw. beschränkt. Eine hohe Taktfrequenz kann von einem Rechnerchip-Entwickler nur bedingt vorgesehen werden, um die Rechenleistung zu erhöhen, und diese Möglichkeit wird in der Regel naturgemäß voll ausgeschöpft. Ein von Chip-Entwicklern in größerem Ausmaß beeinflussbares Potential liegt hingegen in der zweiten Methode, der Mehr- fach-Implementierung von Rechnerkomponenten.
Ein übliches Beispiel für die Mehrfach-Implementierung von Rechnerkomponenten ist der so genannte „Superpipelining"-Rechner . Der Rechner enthält hier eine Kette von Arithmetikeinheiten als Rechenstufen, und er bearbeitet Instruktionen nicht nur hintereinander, sondern verschachtelt in den einzelnen Rechenstufen, den so genannten „Pipeline-Stufen". Ein Befehl ist erst dann vollständig abgearbeitet, wenn alle Rechenstufen der Arithmetikeinheit durchlaufen sind. Die einzelnen Rechenstufen sind zeitlich entkoppelt, und es können daher mehrere Befehle innerhalb der Arithmetikeinheit gleichzeitig bearbeitet werden. Beispielsweise wird ein neuer Befehl in der ersten Rechenstufe bearbeitet, der vorherige Befehl wird gleichzeitig in der zweiten Re- chenstufe bearbeitet usw.; die volle Leistungsfähigkeit kann man hier aber nur dann erhalten, wenn alle Pipeline-Stufen mit Instruktionen gefüllt sind. Ist jedoch im Programm, aus dem die Instruktionen bestehen, ein Sprung in einem anderen Programmteil vorgesehen, was relativ häufig vorkommt, so müssen erst alle Befehle, die in den einzelnen Stufen der Arithmetikeinheit bearbeitet werden, abgearbeitet werden, und erst danach kann zum neuen Programmteil gesprungen werden, wobei dann wieder die einzelnen Stufen der Arithmetik-Einheit gefüllt werden müssen. Erst danach ist wieder die volle parallele Rechenleistung nutzbar gemacht.
Bei einer anderen bekannten Rechnerarchitektur zur Erhöhung der Rechenleistung, dem so genannten „Superskalar^-Rechner, werden statt einer langen „Pipeline"-Kette (wie im „Superpipelining"- Rechner) kürzere, parallel angeordnete Rechenpfade, so genannte Pipelines, implementiert. Demgemäß werden hier tatsächlich Befehle parallel verarbeitet, anstatt nur verschachtelt hintereinander verarbeitet zu werden, wie in der vorher genannten Super- pipelining-Struktur . Von Nachteil ist hier jedoch, dass die einzelnen parallelen Einheiten, um die volle Rechenleistung nutzbar zu machen, nicht auf gleiche Ressourcen, wie auf gleiche Datenspeicher, zugreifen dürfen, was jedoch in der Praxis nicht ausgeschlossen werden kann.
Gemäß einem weiteren Vorschlag zur Erhöhung der Rechenleistung werden mehrere digitale Signalprozessoren verwendet, die über Datenschnittstellen miteinander synchronisiert werden. Die Synchronisation der digitalen Signalprozessoren erfolgt mittels eines Protokolls, welches gewährleistet, dass die völlig autark arbeitenden Signalprozessoren die normale Programmverarbeitung verlassen und in einen Zustand gebracht werden, in dem ihre Sendeseite bereit ist, Daten zu senden, und ihre Empfangsseite bereit ist, Daten zu empfangen. Es erfolgt dann der gewünschte Datenaustausch, mit einer nachfolgenden Quittierung der erfolgreichen Datenannahme. Im Anschluss daran können die Signalprozessoren wieder mit dem normalen Abarbeiten des Programms fortfahren. Diese Form der Synchronisation ist zeitaufwendig, ist jedoch notwendig, da die Signalprozessoren völlig autark arbeiten und daher am Beginn der Verarbeitung keine Information über den Zu- stand der jeweils anderen Signalprozessoren besitzen. Insgesamt vermindert somit die notwendige Synchronisation bei dieser Technik wesentlich die Prozessorleistung, wenn der Datendurchsatz zwischen den Signalprozessoren ansteigt.
Bekannt ist auch eine Technologie, PACT-XPP-Architektur genannt, bei der programmierbare Zellen, d.h. Objekte, vorgesehen sind, vgl. z.B. http; //www . pactcorp . com/xneu/download/xpp white_pa- per.pdf, The XPP White Paper, Release 2.1, A Technical Perspec- tive, Copyright: PACT Informationstechnologie GmbH; 27. März 2002. Durch entsprechende Konfiguration werden diese Objekte so miteinander verschaltet, dass die jeweils gewünschte Applikation abgebildet wird. Es müssen somit, damit eine funktionstüchtige Applikation erhalten wird, diese Objekte selbst untereinander richtig verschaltet ( = konfiguriert) sowie weiters entsprechend programmiert werden. Für diese Zuordnung der Objekte zueinander ist daher ein schaltbares, d.h. konfigurierbares Datenver- bindungs-Netzwerk erforderlich. Im Betrieb erfolgt dann eine Synchronisation über die zu verarbeitenden Datenpakete. Konkret erfolgt ein Datenaustausch zwischen den Objekten durch Datenpakete, d.h. ein Zielobjekt erhält alle Datenpakete von unterschiedlichen Sendeobjekten. Das Zielobjekt synchronisiert auf diese Datenpakete auf, d.h. es wartet solange, bis alle notwendigen Eingangsdaten vorhanden sind, die für die gewünschte Berechnung im Objekt erforderlich sind, und es führt erst dann die Berechnung durch.
Es ist nun Aufgabe der Erfindung, die bzw. zumindest einige der Nachteile des Standes der Technik zu vermeiden und eine digitale Rechnereinrichtung mit Parallelverarbeitung vorzuschlagen, die eine erhöhte Rechenleistung für rechenintensive Aufgaben aufweist, wobei durch das Parallelisieren eine tatsächliche, dem Aufwand entsprechende Rechenleistungssteigerung erzielt werden kann.
Zur Lösung der gestellten Aufgabe sieht die Erfindung eine digitale Rechnereinrichtung mit Parallelverarbeitung wie in Anspruch 1 angegeben vor. Vorteilhafte Ausführungsformen und Weiterbildungen sind in den Unteransprüchen definiert. Die vorliegende digitale Rechnereinrichtung kann zur Bearbeitung von rechenintensiven Algorithmen, beispielsweise in der Telekommunikation, eingesetzt werden, wie etwa im Zuge einer Bildkompression oder in der DSL-Technik (DSL-digital subscriber linedigitale Teilnehmerleitung) . Dabei ergibt sich, dass die zu implementierenden Algorithmen häufig aus so genannten Vektor-Algorithmen bestehen, d.h. aus Algorithmen, die nicht bloß einen einzelnen Datenwert, sondern eine Gruppe von Datenwerten, den so genannten Datenvektor, durch gleichartige Operationen verarbeiten. Vektor-Algorithmen stehen im Gegensatz zu skalaren Algorithmen, die ausgehend von einem einzelnen Datenwert wiederum einen einzelnen Datenwert berechnen. Die vorliegende digitale Rechnereinrichtung eignet sich jedoch nicht nur zur Bearbeitung derartiger Vektor-Algorithmen, sondern auch zur Verarbeitung von skalaren Algorithmen oder Kombinationen von skalaren Algorithmen und Vektor-Algorithmen. In der Rechnereinrichtung, die insbesondere eine programmgesteuerte Rechnereinrichtung ist, sind mehrere Arithmetikeinheiten implementiert, und zwar zusammen mit zugehörigen Datenspeichern, wodurch parallele Recheneinheiten erhalten werden, die effizient zusammenspielen können, so dass durch das Parallelisieren tatsächlich eine dem Aufwand entsprechende Rechenleistungssteigerung erzielt wird. Für dieses Zusammenspiel von Bedeutung ist eine entsprechende Ansteuerung in der Form, dass nicht nur innerhalb der einzelnen Recheneinheiten ein Datentransfer zwischen der Arithmetikeinheit und den zugehörigen Datenspeichern erfolgt, sondern auch zwischen den parallelen Recheneinheiten untereinander ein Datentransfer ermöglicht wird. Ferner ist selbstverständlich eine globale bzw. externe Dateneingabe und Datenausgabe mit Hilfe entsprechender Bus-Systeme gegeben, und im Fall des Vorsehens wenigstens einer globalen Recheneinheit sind auch die erforderlichen Bus-Verbindungen zwischen den parallelen Recheneinheiten und dieser globalen Recheneinheit vorhanden. Insgesamt ergibt sich dabei als besonders vorteilhaft und in optimaler Entsprechung zur gestellten Aufgabe, dass die geforderte Rechenleistung durch die vorgesehene Parallelverarbeitung geliefert wird, ohne dass Beschränkungen etwa durch Synchronisationsmaßnahmen über Datentransfer oder dgl. erforderlich wären, dass Vektor-Algorithmen effizient bearbeitet werden können, und dass selbstverständlich auch die Bearbeitung von skalaren Algorithmen wirksam unterstützt wird. Mit anderen Worten, die vorliegende Rechnerarchitektur ermöglicht die gewünschte hohe Rechenleistung durch eine „massive" Parallelverarbeitung, bei der die parallelen Recheneinheiten optimal zusammenarbeiten, so dass durch das Parallelisieren die gewünschte Rechenleistungssteigerung tatsächlich erzielt wird. Dies ist um so mehr von Bedeutung, als in modernen Applikationen insbesondere der Telekommunikation die Datentransferraten (also die Raten, mit denen Daten in einen Rechner hinein und aus einem Rechner heraus laufen) immer höher werden. Dabei sind auch Datentransfers zwischen den parallelen Recheneinheiten in der Rechnereinrichtung immer häufiger, was aber bei der vorliegenden Rechnerarchitektur unproblematisch ist, im Gegensatz zu den Multi-Pro- zessorsystemen gemäß Stand der Technik, die für solche Applikationen ungeeignet sind, da diese einen zu hohen zusätzlichen zeitlichen Synchronisationsaufwand zum Datenaustausch zwischen den Prozessoren benötigen.
Bei der vorliegenden Rechnereinrichtung werden keine Takte für die Synchronisation von Datentransfers benötigt, vielmehr erfolgt eine effiziente allgemeine Koordination aller Berechnungen in den Recheneinheiten. Dabei stehen bevorzugt alle Aktionen in der Rechnereinrichtung in einem starren zeitlichen Zusammenhang zueinander, und es ist zu jedem beliebigen Zeitpunkt exakt definiert, welche Daten gerade jetzt - und wo - im System vorhanden sind. Dies ist die Voraussetzung dafür, dass keine Taktzyklen für die Synchronisation von Datentransfers benötigt werden. Diese Koordination erfolgt bevorzugt durch die zentrale Programmablaufsteuerung, d.h. gesteuert durch die zentrale Programmablaufsteuerung stehen alle Operationen im Rechner in einem starren und eindeutigen zeitlichen Zusammenhang zueinander. Die Datentransfers zwischen den einzelnen Recheneinheiten können daher sofort, ohne zeitlichen Synchronisationsaufwand, erfolgen.
Bei der vorliegenden digitalen Rechnereinrichtung sind somit bevorzugt Datenbus-Verbindungen für interne Datentransfers innerhalb der einzelnen Recheneinheiten sowie Datenbus-Verbindungen für Datentransfers zwischen den parallel geschalteten Recheneinheiten, und weiters auch Datenbus-Verbindungen zur allgemeinen Daten-Ein- und Ausgabe in die bzw. aus der Rechnereinrichtung vorgesehen. Im Fall des Vorsehens einer globalen Recheneinheit für allgemeine Berechnungen sind Datenbus-Verbindungen auch zwischen dieser globalen Einheit und den parallel geschalteten Recheneinheiten vorgesehen.
Für die effiziente Parallelverarbeitung ist insbesondere jeder der parallel geschalteten Recheneinheiten auch ein eigener Progammspeicher zugeordnet, ebenso wie bevorzugt im Falle des Vorsehens der globalen Recheneinheit letzterer ein eigener Programmspeicher zugeordnet wird. Die globale Recheneinheit ist, um beliebigen Rechenanforderungen gerecht zu werden, bevorzugt sowohl mit Ausgängen als auch mit Eingängen der parallel geschalteten Recheneinheiten verbunden.
Die Erfindung wird nachfolgend an Hand von in der Zeichnung dargestellten bevorzugten Ausführungsbeispielen, auf die sie jedoch nicht beschränkt sein soll, noch weiter erläutert. Im einzelnen zeigen:
Fig. 1 schematisch in einem Blockschaltbild den Aufbau einer digitalen Rechnereinrichtung mit parallel geschalteten Recheneinheiten gemäß der Erfindung;
Fig. 2 in einem ähnlichen Blockschaltbild eine derartige digitale Recheneinrichtung, wobei im Vergleich zu Fig. 1 die Recheneinheiten vereinfacht dargestellt, jedoch die ihnen jeweils gesondert zugeordneten Programmspeicher veranschaulicht sind;
Fig. 3 in einem Zustandsdia-gramm die Wirkungsweise der bei der vorliegenden Recheneinrichtung vorgesehenen zentralen Programmablaufsteuerung;
Fig. 4 in einem vereinfachten Flussdiagramm die Wirkungsweise der Programmablaufsteuerung;
Fig. 5 in einem Blockschaltbild ähnlich Fig. 1 die Recheneinrichtung in der Anwendung bei einer echten Vektorverarbeitung, wobei die einzelnen dabei aktiven Datenbus-Verbindungen, die die parallele Arbeitsweise der einzelnen Recheneinheiten verdeutlichen, mit verstärkten Linien veranschaulicht sind; Fig. 6 ein bei einer derartigen Vektorverarbeitung gegebenes Berechnungsschema;
Fig. 7 ein Schema zur Veranschaulichung der Abarbeitung eines typischen Programms bei einer solchen echten Vektorverarbeitung; und
die Fig. 8, 9 und 10 sowie 11, 12 und 13 ähnliche Blockschaltbilder bzw. Schemata wie in den Fig. 5, 6, 7 gezeigt zur Veranschaulichung der Arbeitsweise bei einer Vektorverarbeitung mit skalarem Endergebnis (Fig. 8, 9 und 10) bzw. bei einer skalaren Verarbeitung (Fig. 11, 12 und 13) .
In Fig. 1 ist eine digitale Rechnereinrichtung 1 mit Parallelverarbeitung gezeigt, wobei eine Anzahl N von zueinander parallel geschalteten Recheneinheiten 2.1, 2.2, 2.3 2.N, auch
Slices genannt, vorgesehen ist. Diesen parallel geschalteten Recheneinheiten 2.1 bis 2.N, nachstehend kurz mit 2.i (i = 1 bis N) bezeichnet, ist eine zentrale, gemeinsame Programmablaufsteuerung 3 zugeordnet, und diese Programmablaufsteuerung 3 steuert auch eine globale Einheit 4 an, die mit den parallelen Recheneinheiten 2.i verbunden ist.
Jede parallel geschaltete Recheneinheit 2.i enthält, wie insbesondere in Fig. 1 bei der ersten Recheneinheit 2.1 ersichtlich ist, eine Arithmetikeinheit 5, die mit Eingangsregistern 6 (Eingangsregister A) und 7 (Eingangsregister B) für die zu verarbeitenden Daten verbunden ist. Weiters sind in jeder Recheneinheit 2.i, siehe die Recheneinheit 2.1 in Fig. 1, zwei Datenspeicher 8 (Datenspeicher A) und 9 (Datenspeicher B) vorgesehen, aus denen die zu verarbeitenden Daten in die Eingangsregister 6, 7 übernommen werden, damit sie in der Arithmetikeinheit 5 in der gewünschten Weise verarbeitet werden können.
Aus Vorstehendem ergibt sich bereits, dass innerhalb einer jeden der parallel geschalteten Recheneinheiten 2.i ein Datenbus-System 10 für interne Datentransfers zwischen den Datenspeichern bzw. Eingangsregistern und den Arithmetikeinheiten vorgesehen ist; weiters ist auch ein Datenbus-System 11 für einen Datentransfer zwischen den einzelnen Recheneinheiten 2.1, 2.2 ... 2.i ... 2.N vorgesehen, wobei dieses Datenbus-System 11 für den Datentransfer zwischen den Recheneinheiten einen globalen Datenbus 11.1, einen Register A-Datenbus 12 und einen Register B-Datenbus 14 umfasst. Ein weiteres Datenbus-System 15 dient zum Datentransfer zwischen den Recheneinheiten 2.i und der globalen Einheit 4; schließlich ist auch ein allgemeines Datenbus-System 16 für externe Dateneingänge bzw. Datenausgänge vorgesehen, um Daten, die verarbeitet werden sollen, der Rechnereinrichtung 1 zuzuführen bzw. die Ergebnisse der Berechnungen aus der Rechnereinrichtung 1 abzugeben.
Die einzelnen Datenbus-Systeme 10 bis 16 werden je nach Art der durchzuführenden Datenverarbeitungen nachfolgend an Hand der Fig. 5 bzw. 8 bzw. 11, mit den darin mit verstärkten Linien eingezeichneten Busverbindungen, noch näher erläutert werden.
Bei der so weit beschriebenen digitalen Rechnereinrichtung 1 arbeiten die einzelnen, zueinander parallelen Recheneinheiten 2.1 als autarke parallele Einheiten, wobei sie jeweils mit den eigenen, unabhängigen Datenspeichern 8, 9 samt integriertem Adressgenerator und mit einem eigenen Programmspeicher (wie nachfolgend an Hand der Fig. 2 erläutert) zusammenarbeiten. Über die zentrale Programmablaufsteuerung 3 wird ein eigener, zusätzlicher, zeitlicher Synchronisationsaufwand zum Datenaustausch zwischen den Arithmetikeinheiten 5 der Recheneinheiten 2.i erübrigt, so dass keine Rechentakte für die Synchronisation von Datentransfers erforderlich sind. Stattdessen folgt eine effiziente globale Koordination aller Berechnungen in den Recheneinheiten 2.i einfach dadurch, dass alle Aktionen in der Rechnereinrichtung 1 in einem starren zeitlichen Zusammenhang zueinander stehen, der durch die ProgrammabablaufSteuerung 3 gegeben ist. Auf diese Weise ist zu jedem Zeitpunkt genau definiert, welche Daten wo in der Rechnereinrichtung 1 vorhanden sind. Durch diese parallele Arbeitsweise der einzelnen Recheneinheiten 2.i kann die potentielle Rechenleistung der Rechnereinrichtung 1 um einen Faktor N erhöht werden.
Im Einzelnen kann bei der Abarbeitung von Vektor-Algorithmen, wie nachstehend an Hand der Fig. 5 ff. noch näher erläutert werden wird, für die effiziente Bearbeitung des Vektoralgorithmus letzterer gleichmäßig auf die zugeordneten Rechnerressourcen aufgeteilt werden, was in zwei Richtungen erfolgt:
a) Zuteilung von Architektur-Ressourcen: Die Berechnung des gesamten Datenvektors ausgehend von einzelnen Eingangs-Datenvekto- ren wird auf die parallelen Recheneinheiten 2.i aufgeteilt, welche dann jeweils Teilvektoren des gesamten Datenvektors berechnen.
b) Zuteilung von zeitlichen Ressourcen: In jeder Recheneinheit 2.i werden die einzelnen Datenwerte eines Teilvektors in einer Befehlsschleife abgearbeitet. Der Programmablauf wird zentral in der Programmablaufsteuerung 3 gesteuert, wodurch gewährleistet wird, dass die Berechnung des Vektoralgorithmus in allen Recheneinheiten 2.i synchron erfolgt.
In einer Vektorberechnung werden auf die einzelnen Datenwerte eines Datenvektors gleichartige Operationen ausgeführt. Üblicherweise besteht ein Rechenzyklus aus einer arithmetischen Operation, die jeweils zwei Werte miteinander verknüpft, wobei einer der beiden Werte meist der Datenwert des Datenvektors und der zweite Wert ein Koeffizient ist. Jede Recheneinheit 2.i beinhaltet wie erwähnt zwei unabhängige Datenspeicher 8, 9. Somit kann in einem einzigen Zyklus eine Operation wie gefordert mit zwei Werten durchgeführt werden. Die Datenbandbreite der gesamten Rechnereinrichtung 1 ist somit für Vektoralgorithmen optimiert. Da in einer Vektorverarbeitung immer alle zugeteilten Recheneinheiten 2.i gleichartige Berechnungen durchführen, werden die Rechnerressourcen aller Recheneinheiten 2.i daher auch immer voll ausgenutzt.
Jede Recheneinheit 2.i kann für sich, d.h. unabhängig, programmiert werden. Daher können in den einzelnen Recheneinheiten 2.i auch voneinander unabhängige skalare Algorithmen bearbeitet werden. Durch die zentrale Programmablaufsteuerung 3 erfolgt eine starre Synchronisierung aller Recheneinheiten 2.i in der Rechnereinrichtung 1. Bei der Berechnung mehrerer verketteter skala- rer Algorithmen hat dies den Vorteil, dass bei Datentransfers zwischen einzelnen skalaren Algorithmen, die in unterschiedlichen Recheneinheiten 2.i abgearbeitet werden, keine zusätzlichen Rechentakte (vgl. den Takteingang CLK in Fig. 1) zur Synchronisation nötig sind. Nachteilig ist unter Umständen, dass die effiziente Nutzung der Rechnereinrichtung 1 eine ausgewogene Aufteilung der zu berechnenden Algorithmen auf die Recheneinheiten 2.i erfordert. Ist z.B. die erste Recheneinheit 2.1 mit einem ersten skalaren Algorithmus, der 100 Zyklen benötigt, belegt, dessen Ergebnis für einen zweiten skalaren Algorithmus benötigt wird, der seinerseits in der zweiten Recheneinheit 2.2 berechnet wird und nur 10 Zyklen benötigt, so wird die zweite Recheneinheit 2.2 nur in 10 Zyklen genutzt, und sie wartet dann 90 Zyklen lang auf das nächste Ergebnis aus der ersten Recheneinheit 2.1. Die effektive Nutzung der Rechenressourcen beträgt dann nur (100+10) / (2x100) = 55 %. Allerdings gibt es gleich mehrere Freiheitsgrade in der Aufteilung von Algorithmenberechnungen auf die Recheneinheiten 2.i, so dass doch immer eine hohe Ausnutzung der parallelen Rechnerressourcen möglich sein sollte:
(a) Aufteilen von skalaren Algorithmen auf die einzelnen Recheneinheiten 2.i, so dass eine gleichmäßige Auslastung erfolgt. Dabei können einzelne Recheneinheiten 2.i eine unterschiedliche Anzahl von Algorithmen abarbeiten: berechnet eine Recheneinheit 2.x z.B. zwei Algorithmen, wobei der erste Algorithmus vier Rechenzyklen und der zweite fünf Rechenzyklen benötigt, und eine zweite Recheneinheit 2.y berechnet einen dritten skalaren Algorithmus, der neun Rechenzyklen benötigt, so sind beide Recheneinheiten 2.x und 2.y für insgesamt neun Zyklen voll ausgelastet.
(b) Mischen der Abarbeitung von skalaren Algorithmen mit Vektoralgorithmen, so dass wiederum alle Recheneinheiten 2.i gleichmäßig ausgelastet sind. Beispielsweise können bei einer Rechnereinrichtung 1 mit acht Recheneinheiten 2.1 bis 2.8 vier Recheneinheiten 2.1 bis 2.4 einen Vektoralgorithmus verarbeiten, während die restlichen vier Recheneinheiten 2.5 bis 2.8 skalare Algorithmen parallel, d.h. gleichzeitig, bearbeiten. Ebenso kann eine andere Aufteilung, z.B. im Verhältnis 6 : 2 gewählt werden.
In diesem Zusammenhang ist auch von Bedeutung, dass jeder Recheneinheit 2.i wie bereits erwähnt ein eigener Programmspeicher 17.1 ... 17. i ... 17. N zugeordnet ist, vgl. Fig. 2, ebenso wie auch der globalen Einheit 4 ein eigener Programmspeicher 17. G zugehört. In Fig. 1 sind diese gesonderten Programmspeicher 17.i als in der Programmablaufsteuerung 3 enthaltene Komponenten zu denken.
Die Programmablaufsteuerung 3 regelt, wie weiters aus Fig. 3 ersichtlich ist, den Programmablauf in einer Zustandsmaschine 18. Durch sie wird festgelegt, wann Operationen gemäß dem Softwareprogramm durchgeführt („exekutiert") werden müssen und wann ein neuer Befehl geholt („gefetcht") werden muss. Die Programmablaufsteuerung 3 steuert die Programmabarbeitung wie erwähnt zentral für alle Recheneinheiten 2.i. Im Fall einer Sonderbehandlung in der Rechnereinrichtung 1 wird die Programmablaufsteuerung 3 angehalten, und es werden entsprechende Schritte in einer eigenen Zustandsmaschine eingeleitet. Beispiele solcher Sonderbehandlungen sind z.B. die Behandlung eines „Debug Mode" (Testen von Programmen in der Rechnereinrichtung 1 durch schrittweise Programmverarbeitung) oder das Stoppen der Programmablaufsteuerung 3, bis neue Daten an die Rechnereinrichtung 1 geliefert werden, wobei ein Programm-Interrupt ausgelöst wird („Interrupt Mode"), wie in Fig. 3 bei 19 veranschaulicht ist.
Die Programmablaufsteuerung 3 hat gemäß der Zustandsmaschine 18 von Fig. 3 folgende Zustände:
(1) „Fetch"-Zustand 20 („ST_FE") : In diesem Zustand 20 „ST_FE" wird die Adresse des nächsten Programmbefehls aus einem (nicht näher dargestellten) PC-Register (PC: Programm Counter = Programmzähler; Adressierung des Programmspeichers) übernommen, und der dadurch adressierte Programmbefehl wird aus dem Programmspeicher 17. i geholt (="Fetch"). Dieser Programmbefehl liegt anschließend (also im darauffolgenden Takt) zur Durchführung
(="Execute") bereit.
(2) „Fetch & Execute"-Zustand 21 („ST_FEEX"): In diesem Zustand 21 wird ein neuer Programmbefehl aus dem Programmspeicher 17. i geholt; dieser Programmbefehl liegt anschließend (also im darauffolgenden Takt) zur Durchführung bereit. Der Programmzähler wird im „ST_FEEX"-Zustand 21 automatisch in jedem Taktzyklus in- kremeritiert. Damit steht die nächste Programmadresse sofort wieder zur Verfügung. Als neue Programmadresse wird also „PC + 1" angenommen, vgl. auch die Aktion 22 in Fig. 3. Mit dieser Aktion 22 wird weiters veranschaulicht, dass der im vorhergegangenen Takt geholte Befehl ausgeführt wird. Alle Recheneinheiten 2.i und die globale Einheit 4 werden aktiviert, und die den jeweiligen Recheneinheiten 2.i zugeordneten Programmbefehle werden ausgeführt.
In diesem Zustand 21 „ST_FEEX" wird ferner - s. die Aktionen 23, 24 - überprüft, ob ein Programmbefehl die Programmabfolge verändert. Das kann zwei mögliche Arten von Befehlen betreffen: 1. Schleifenbefehle: Wenn ein entsprechender Befehl den Beginn einer Programmschleife markiert, wird zu einem nachfolgend noch erläuterten Zustand 25 „ST_LOOP" gesprungen (s. Aktion 24), wo die Programmschleife abgearbeitet wird (s. Aktion 26 in Fig. 3) . 2. Befehle, die direkt das PC-Register verändern: Ein Sprung im Programm wird durch das Laden des PC-Registers mit der nächsten anzuspringenden Programmadresse ausgelöst. Somit steht der nächste auszuführende Befehl nicht an der nachfolgenden Adresse des soeben exekutierten Befehls. Daher muss der automatisch im Zustand 21 „ST_FEEX" von der Adresse PC+1 gefetchte Befehl verworfen werden. Um den tatsächlich als nächster zu exekutierenden Befehl aus dem Programmspeicher zu holen, wird vom Zustand 21 „ST_FEEX" zum Zustand 20 „ST_FE" gesprungen (s. Aktion 23).
(3) Schleifen-Zustand 25 (,,ST_LOOPλΛ) : In diesem Zustand 25 „ST_LOOP" erfolgt das Abarbeiten einer Programmschleife. Erst wenn die Programmschleife vollständig ausgeführt ist, wird vom Zustand 25 ,,ST-LOOP" wieder in den Zustand 21 „ST_FEEX" gesprungen (s. Aktion 27) . Während des Zustands 25 „ST_LOOP" wird eine per Programm definierte Anzahl von hintereinanderfolgenden Befehlen wiederholt ausgeführt. Die Anzahl der zyklischen Wiederholungen der Programmschleife wird ebenfalls durch einen eigenen Befehl per Programm vorgegeben.
Das Exekutieren von Programmbefehlen erfolgt demgemäß für die gesamte Rechnereinrichtung 1 in den Zuständen 21 „ST_FEEX" und während einer Programmschleife in den Zuständen 25 „ST_LOOP". Befindet sich die Zustandsmaschine 18 in einem dieser Zustände, so werden alle Recheneinheiten 2. i in der Rechnereinrichtung 1 aktiviert, und sie führen die durch das Programm vorgegebenen Befehle aus, vgl. im Übrigen auch die Angaben „Fetch" und „Exe- cute" sowie die Zustands-Angaben „ST_FEEX or ST_LOOP" bzw. „ST_FE or ST_FEEX" in Fig. 2.
In Fig. 4 ist ein Signalflussdiagramm der Programmablaufsteuerung 3 veranschaulicht, wobei die vorerwähnten Zustände 20 („ST_FE"), 21 („ST_FEEX") und 25 („ST_LOOP") - letzterer mit Verschachtelungen - ebenfalls veranschaulicht sind.
Die Programmablaufsteuerung 3 wird per Programm gesteuert. Im Detail werden anhand des Flussdiagramms von Fig. 4 beispielhafte Befehle der Programmablaufsteuerung 3 erläutert. Je nach Ausprägung der Rechnereinrichtung 1 kann es aber sinnvoll sein, weitere Befehle hinzuzufügen.
In Fig. 4 ist im linken Teil eine normale Programmabarbeitung veranschaulicht, wobei gemäß dem Zustand ST_FE, s. Feld 30, als erstes der nächste Befehl - gemäß Block 31 - von der aktuellen Adresse PC geholt wird. Der nächste Befehl ist dann an der Adresse PC+1 zu erwarten. Somit kann der automatisch von dieser Stelle gefetchte Befehl im nächsten Zyklus ausgeführt werden.
Im darauffolgenden Zustand 21 („ST_FEEX") gemäß Fig. 3 beginnt das Abarbeiten des Programms, s. Feld 32 in Fig. 4, wobei dann gemäß Block 35 die Ausführung des Befehls vorbereitet und hierzu alle Recheneinheiten 2.1 und die globale Einheit 4 aktiviert wird sowie der nächste Befehl an der Adresse PC+1 geholt wird. Dieser Befehl wird wieder verworfen, wenn kein kontinuierlicher Programmablauf vorliegt.
Sodann wird gemäß Feld 36 abgefragt, ob eine Sonderbehandlung (s. Sonderbehandlung 19 in Fig. 3) zu starten ist, und wenn ja, wird zum Sonderbehandlungs-Feld 37 weitergegangen. Danach wird gemäß Feld 38 zyklisch abgefragt, ob die Sonderbehandlung zu Ende ist, und wenn nein, wird die Sonderbehandlung gemäß Feld 37 fortgesetzt; wenn jedoch die Sonderbehandlung beendet ist (Ausgang JA des Feldes 38), so wird gemäß einem weiteren Feld 39 abgefragt, ob ein kontinuierlicher Programmablauf gegeben ist, wobei der nächste Befehl an der Adresse PC+1 betrachtet wird. Wenn ein kontinuierlicher Programmablauf gegeben ist, s. Ausgang JA des Feldes 39, wird zum „ST_FEEX"-Zustand gemäß Feld 34 übergegangen; wenn jedoch kein kontinuierlicher Programmablauf gegeben ist, s. Ausgang NEIN des Feldes 39, wird zum Ausgangszustand 20 „ST_FEλΛ gemäß Feld 30 zurückgekehrt.
Wenn im Abfrageschritt gemäß Feld 36 als Ergebnis erhalten wird, dass keine Sonderbehandlung durchzuführen ist, wird danach gemäß Feld 40 abgefragt, ob eine Programmschleife zu starten ist (d.h. in den Zustand 25 „ST_LOOP" zu springen ist) , und wenn nein, wird gemäß Feld 41 wiederum nach dem Vorliegen eines kontinuierlichen Programmablaufes abgefragt; zutreffendenfalls wird dann zum Zustand gemäß Feld 30 zurückgekehrt; wenn das Abfrageergebnis beim Feld 41 jedoch nein ist, wird die Befehlsadresse um „1" erhöht, und es wird zum Zustand „ST_FEEX" gemäß Feld 34 gesprungen.
Ergibt sich bei der Abfrage gemäß Feld 40, dass eine Programmschleife zu starten ist, wird zum Zustand 25 „ST_LOOPΛX, und zwar konkret im vorliegenden Beispiel gemäß Fig. 4, mit drei ineinander verschachtelten Schleifenmöglichkeiten, zur ersten, äußersten Schleife Nr. 0, gemäß Feld 42, übergegangen.
Eine solche Programmschleife wird durch den Befehl „START_LOOP" ausgelöst. Dabei wird der Zustand 34 „ST_FEEX" verlassen und im Beispiel gemäß Fig. 4 wie erwähnt zur ersten Schleife, beginnend mit dem Feld 42 „ST_LOOP#0" gesprungen. Sodann werden der aktuelle Wert des Programmzählers PC und der aktuelle Befehl abgespeichert, um ein Vorbereiten „Enable" der Befehlsausführung vorzusehen, s. Block 43 in Fig. 4. Hierzu ist auszuführen, dass am Ende einer Schleife der erste Befehl innerhalb der Schleife wiederholt wird, was einem Programmsprung entspricht, da die nächste Programmzeile nicht an der Stelle PC+1 steht. Folglich müsste der nächste Befehl in einem Extra-Zyklus erneut geholt werden, wie bei Sprungbefehlen in den Zustand 34 „ST_FEEX", die einen Zusatz-Fetch-Zustand ST_FE gemäß Feld 30 bewirken. Um die Schleifenabarbeitung, die gerade bei Vektor-Algorithmen besonders wichtig ist, zu optimieren, wird demgemäß ein derartiger zusätzlicher Zwischenschritt dadurch vermieden, dass der erste Befehl der Schleife samt dem Wert im Programmzähler (PC) zwischengespeichert wird und somit sofort zur Verfügung steht. Bei einer Schleifenabarbeitung gehen daher keine Zyklen beim Rücksprung zum Schleifenanfang verloren.
Beim Beispiel gemäß Fig. 4 sind wie erwähnt insgesamt drei ineinandergeschachtelte Schleifen vorgesehen, die in der Fig. 4, in der rechten Hälfte hievon, nebeneinander, jeweils beginnend mit einem Feld ST_LOOP #0 bzw. #1 bzw. #2, veranschaulicht sind. In der ersten Schleife, mit der Nr. #0, wird nun gemäß einem Abfragefeld 44 abgefragt, ob eine innere Schleife zu starten ist, und wenn nein, wird in einem weiteren Abfragefeld 45 abgefragt, ob die Schleife beendet ist; wenn nein, wird gemäß Block 46 der nächste Befehl geholt und zum Schleifenanfang, zum Feld 42, zurückgekehrt. Wenn jedoch die Schleife abgearbeitet ist, wird gemäß einem Abfragefeld 47 abgefragt, ob bereits die letzte Schleife erreicht wurde, d.h. ob der Schleifenzähler auf dem vorgegebenen maximalen Wert „LOOPMAX" steht, und wenn nein, wird wie erwähnt für die nächste Schleife der erste Befehl aus dem Befehlsregister geholt, s. Block 48, und der Schleifenzähler um 1 erhöht.
Im Einzelnen wird das Schleifenende durch einen Befehl „STOP_LOOP" angezeigt. Wenn auf diese Weise ein Schleifenende angezeigt wird, wird überprüft, ob schon genügend Durchläufe der Schleife erfolgt sind, was dann der Fall ist, wenn der Schleifenzähler wie erwähnt den vorprogrammierten Wert „LOOPMAX" erreicht hat. Wenn dies der Fall ist, gilt die Schleifenbearbeitung als beendet, und es wird die normale Programmabarbeitung beim Feld 34 „ST_FEEX" fortgeführt. Ansonsten wird wie erwähnt unter Erhöhung des Werts des Schleifenzählers der nächste Schleifendurchlauf gestartet.
Bei einem nochmaligen Auftreten Befehls „START_LOOP" im Zustand 25 „ST_LOOP" ist dies als Vorliegen einer eingenisteten Schleife zu verstehen, was in Fig. 4 beim Abfragefeld 44 festgestellt wird. Wenn eine solche eingenistete oder verschachtelte Schleife festgestellt wird, wird zu dieser eingenisteten Schleife, z.B. mit der Nr. #1 in Fig. 4, s. Feld 49, gesprungen, und es erfolgt dann eine Schleifenabarbeitung ganz analog zu der vorstehend be- schriebenen, wobei in Fig. 4 in dieser eingenisteten Schleife #1 die entsprechenden Felder' und Blöcke wie bei der äußersten Schleife #0 angegeben sind, und wobei sich eine neuerliche Erläuterung hievon erübrigen kann. Ähnliches gilt auch für die nächste eingenistete Schleife, die Schleife #2 gemäß Feld 50 in Fig. 4, wobei allerdings hier, da eine weitere eingenistete Schleife nicht mehr existiert, das Abfragefeld 44 wegfällt. In Fig. 4 ist dabei auch mit Verbindungen 51, 51', 51" angedeutet, dass dann, wenn die jeweilige Schleife 50 etc. bzw. 49 etc. bzw. 42 etc. abgearbeitet ist, zur jeweils nächsthöheren Schleife, und zwar zu deren Beginn gemäß Feld 49 bzw. 42, bzw. zum Feld 32 zurückgekehrt wird.
Bei der in Fig. 4 beispielhaft dargestellten und erläuterten Programmablaufsteuerung ist somit eine dreifach verschachtelte Schleife vorgesehen, wobei die innerste Schleife im Zustand ST_LOOP #2 (s. Feld 50) gesteuert wird. Dadurch, dass beim Sprung in die nächste Schleifenhierarchie der aktuelle Programmzähler-Wert sowie der aktuelle Befehl zwischengespeichert werden, wird wieder verhindert, dass bei einem Rücksprung auf den ersten Befehl der jeweiligen Schleife ein Zyklus durch einen zusätzlichen Programm-Fetch verlorengeht. Tritt der Befehl „STOP_LOOP" auf, so wird der nächste Schleifendurchlauf gestartet bzw. wird, wenn der Schleifenzähler den maximalen Schleifenwert „LOOPMAX" erreicht hat (s. Abfragefeld 47), in die nächsthöhere Schleifenhierarchie ober aber zum Feld 34 in Fig. 4 zurückgesprungen .
Damit alle Schleifenhierarchien (ST_LOOP #0 bis #2) voneinander unabhängig sind, werden entsprechend viele, hier drei, Schleifenzähler und „LOOPMAX"-Register vorgesehen. Ebenso gibt es für alle drei Schleifenhierarchien entsprechende Speicherplätze, um den jeweils ersten Befehl einer Schleife samt Programmzähler- Wert darin abzulegen.
Bei der vorliegenden Rechnereinrichtung 1, bei der der Programmablauf für alle Recheneinheiten 2.i synchron ist, betrifft eine Änderung des Programmflusses alle Recheneinheiten 2.i gleichzeitig. Das Holen von neuen Befehlen aus den unterschiedlichen Programmspeichern 17. i erfolgt zentral durch die Programmablaufsteuerung 3 im Zustand 20 oder 21 („ST_FE" oder „ST_FEEXW, wobei „Fetch" aktiviert ist) . Durch diese zentrale Kontrolle ist zu jedem Zeitpunkt endeutig festgelegt, welche Befehle in einem bestimmten Taktzyklus bearbeitet werden. Alle Recheneinheiten 2.i erhalten von der Programmablaufsteuerung 3 ein gemeinsames Aktivierungssignal. Dieses ist dann aktiv, wenn die Programmablaufsteuerung 3 im Zustand 21 „ST_FEEX" (normaler Programmablauf) oder im Zustand 25 „ST_LOOP" ist (Abarbeitung einer Programmschleife) , und es synchronisiert damit alle Operationen in der Rechnereinrichtung 1. Da sowohl der Befehls-Fetch als auch die Befehls-Exekution synchron erfolgt, ist die gesamte Verarbeitung in der Rechnereinrichtung 1 starr gekoppelt. Es ist daher zu jedem Zeitpunkt und für jede Recheneinheit 2.i festgelegt, welche Befehle gerade abgearbeitet werden. Durch diese starre Synchronisierung ist kein weiterer Aufwand nötig, um Datentransfers zwischen verschiedenen Recheneinheiten 2.i zu synchronisieren.
Die bisher beschriebene Rechnereinrichtung 1 unterstützt insbesondere die effiziente Bearbeitung von drei Klassen von Algorithmen, nämlich die echte Vektorverarbeitung, die Vektorverarbeitung mit skalarem Endergebnis und die skalare Verarbeitung; diese Verarbeitungen werden nachfolgend noch näher erläutert.
Bei der echten Vektorverarbeitung bilden die Eingangsdaten jeweils einen Datenvektor, d.h. ein Set von einzelnen Datenwerten, und das Ergebnis ist wieder ein Datenvektor, also ein Set von einzelnen Datenwerten. In der vorliegenden Rechnereinrichtung 1 erfolgt dabei eine autarke parallele Bearbeitung der einzelnen Werte der Eingangs-Datenvektoren in den einzelnen Recheneinheiten 2.i, die nachfolgend auch „Slices" genannt werden; dabei sind keine Datentransfers zwischen den Slices 2.i nötig, wie dies insbesondere aus Fig. 5 ersichtlich ist, wo die aktiven Bussysteme 10 innerhalb der Slices 2.i mit verstärkten Linien veranschaulicht sind.
Die N-Slices 2.i erhalten Eingangsdaten aus den Datenspeichern 8, 9 oder von außerhalb über den externen Dateneingang (Bussystem 16) . Die Daten werden den Eingangsregistern 6, 7 übergeben, die ihrerseits die jeweilige Arithmetikeinheit 5 bedienen, die entsprechende arithmetische Operationen ausführt. Das Ergebnis kann wieder über einen Slice-internen Datenbus an die Eingangsregister 6,7 zurückgeleitet werden, um eine iterative Berechnung zu ermöglichen. Alternativ kann sich eines der beiden Eingangsregister 6 oder 7 auch Daten für den nächsten Verarbeitungszyklus aus dem zugehörigen Datenspeicher 8 bzw. 9 holen. Danach erfolgt wieder die Berechnung in der Arithmetikeinheit 5. Das Endergebnis kann entweder über die Eingangsregister 6,7 in die Datenspeicher 8,9 zurückgespeichert werden, oder es wird über den externen Datenausgang, d.h. das Ein-/Ausgangs-Bussystem 16, ausgegeben.
Die Dauer der gesamten Verarbeitung wird durch die zentrale Programmablaufsteuerung 3 vorgegeben, die programmierbar ist. Somit ist die Dauer der Gesamtberechnung, d.h. die Anzahl der zu wiederholenden Rechenzyklen, per Programm festgelegt. Durch die starre Synchronisation über die zentrale Programmablaufsteuerung 3 kann genau festgelegt werden, wann die einzelnen Slices 2.i Ergebnisse liefern. Es ist daher kein weiterer Synchronisationsaufwand erforderlich, um z.B. eine Datenübergabe zu nachfolgenden bzw. weiterverarbeitenden Programmen zu synchronisieren.
Bei dieser echten Vektorverarbeitung, die auch schematisch in Fig. 6 veranschaulicht ist, in der bei I1 (mit i = 1, 2, 3...N) die Eingangswerte (also ingesamt der Eingangs-Datenvektor) , bei P1 die parallelen Bearbeitungen und bei O1 die Ergebnisse (der Ausgangs-Datenvektor) gezeigt sind, ist die globale Einheit 4 inaktiv.
In Fig. 7 ist die Abarbeitung eines für die Vektorverarbeitung typischen Programms gezeigt. Befehle, die die Programmablaufsteuerung 3 kontrollieren, werden einem gemeinsamen, allgemeine Befehle enthaltenden Programmspeicher 60, entnommen. Die einzelnen Slices 2.i werden über die eigenen Programmspeicher 17. i gesteuert. Die iterative Berechnung startet mit dem Befehl „Loop Start", s. Feld 61 in Fig. 7) . Alle Befehle (exklusive jener Befehlszeile, in der der Befehl „Loop Start" steht) bis zum Befehl „Loop End" (s. Feld 62) werden wiederholt ausgeführt. Die Anzahl der Wiederholungen wird in einem „LOOPMAX"-Register vorgegeben, dessen Laden in Fig. 7 schematisch beim Block 63 gezeigt ist, worauf gemäß dem Feld 61 der Befehl „Loop-Start" zum Starten der Schleifenberechnung folgt. Alle Programmspeicher 17. i werden über den gemeinsamen Programmzähler (PC) angesteuert. Daher erfolgt die gesamte Verarbeitung immer zeilenweise, wobei jede einzelne Programmzeile auf die einzelnen Programmspeicher 17. i und den allgemeinen Programmspeicher 60 aufgeteilt wird. Alle Teilprogramme in den einzelnen Slices 2.i - Prekalkulation 64. i, iterative Kalkulation 65. i, Postkalkulation 66. i - bestehen aus für jede Recheneinheit 2.i frei wählbaren Programmbefehlen, die dem jeweiligen Programmspeicher 17. i entnommen werden. Lediglich der Programmfluss wird zentral gesteuert. Beispielsweise wird die Anzahl der iterativen Berechnungen durch das Laden des „LOOPMAX"-Registers für alle Slices 2.i festgelegt. Gemäß Feld 67 wird jeweils überprüft, ob die Schleifenzählung die maximale Schleifenzahl („LOOPMAX") erreicht hat, und wenn nicht, wird die nächste Schleife gerechnet (s. auch die „Verbindung" 68 „next Loop" in Fig. 7) .
Als nächstes soll die Vektorverarbeitung mit skalarem Endergebnis anhand der Fig. 8 bis 10 erläutert werden. Bei dieser Bearbeitungsart bilden ebenfalls die Eingangsdaten einen Datenvektor (ein Set von einzelnen Datenwerten) , das Ergebnis ist jedoch eine skalare Größe, d.h. ein einzelner Datenwert. In den einzelnen Recheneinheiten (= Slices) 2.i erfolgt eine Vektorbearbeitung der einzelnen Werte des Datenvektors, wonach in der globalen Einheit 4 die Bildung eines skalaren Endergebnisses erfolgt. Dieses Endergebnis kann an alle Slices 2.i zurückgeführt werden. Diese Verarbeitungen bzw. die hiefür durchzuführenden Datenübertragungen ergeben sich aus Fig. 8, in der, wiederum ausgehend vom Schema von Fig. 1, die nun insbesondere aktiven Bussysteme 12 und 15 stark herausgezeichnet sind.
Die Verarbeitung des Eingangs-Datenvektors erfolgt wieder wie vorstehend bereits anhand der Fig. 5 bis 7 beschrieben und braucht nicht weiter erläutert zu werden. Anschließend an diese Vektorverarbeitung werden die Teilergebnisse der Berechnungen, die in den einzelnen Slices 2.i erfolgen, der globalen Einheit 4 übergeben. Diese globale Einheit 4 übernimmt die Teilergebnisse der Slices 2.i und bildet durch arithmetische Operationen ein einzelnes Endergebnis (zum Beispiel kann die globale Einheit 4 die Summe oder aber ein skalares Produkt aus allen Teilergebnissen bilden) .
Abgesehen davon, dass das Endergebnis wieder an die Eingangsregister 6, 7 der einzelnen Slices 2.i zurückgeführt werden kann, ist es selbstverständlich auch denkbar, das skalare Endergebnis über den externen Ausgang (also über das Bussystem 16) auszugeben.
Diese Bearbeitungs-Mischform ist wiederum, in einer Darstellung ähnlich Fig. 6, schematisch in Fig. 9 veranschaulicht. Dabei ist gezeigt, wie aus Eingangswerten I1 in einer Vektorverarbeitung P1 Teilergebnisse T± berechnet werden; aus diesen Teilergebnissen T1 wird, z.B. durch Produktberechnung, in einer globalen Skalar-Be- rechnung S das skalare Endergebnis 0 berechnet.
Die Fig. 10 zeigt hierzu mehr im Detail die Abarbeitung eines typischen Programms. Dabei erfolgt die iterative Berechnung wieder zentral für alle Slices 2.i. Im gezeigten Beispiel werden am Beginn der Berechnung die Ausgangswerte einer Berechnung der globalen Einheit 4 (der z.B. als globaler Addierer fungiert) entnommen. Da alle Recheneinheiten 2.i getrennt programmiert werden können, kann jede Recheneinheit 2.i die Ausgangsdaten aus einer anderen Quelle entnehmen. Beispielsweise wäre es auch möglich, dass nur die erste Recheneinheit 2.1 ihren Startwert von der globalen Einheit 4 entnimmt und andere Slices 2.i (itl) ihre Startwerte aus dem Datenspeicher oder von außerhalb (über das Bussystem 16) erhalten.
Gemäß Fig. 10 werden ausgewählte Werte in der globalen Einheit 4 am Ende der Berechnung aufsummiert, was durch eine Ansteuerung von Schaltern S.i veranschaulicht ist. Die Auswahl, welche SIi- ce-Werte aufsummiert werden, wird durch ein Register 69 „ADDER- MASK" festgelegt.
Im Übrigen entspricht Fig. 10 grundsätzlich der Fig. 7, so dass sich eine neuerliche Beschreibung, etwa was die Schleifenbearbeitungen betrifft, erübrigen kann.
Abschließend soll noch anhand der Fig. 11, 12 und 13 beispiel- haft eine rein skalare Verarbeitung erläutert werden. Hier sind die Eingangsdaten eine skalare Größe (ein einzelner Datenwert) , ebenso wie das Endergebnis und zwischendurch erhaltene Teilergebnisse skalare Größen (einzelne Datenwerte) sind. Die Gesamtberechnung wird in Teilberechnungen unterteilt, die parallel in den einzelnen Recheneinheiten 2.1, 2.2 ... 2.(N-I), 2.N erfolgen, und alle Teilergebnisse werden gleichzeitig an die jeweils rechte Nachbar-Recheneinheit 2.2 ... 2.N, 2.1 übergeben, wo die jeweilige weitere Berechnung erfolgt. In Fig. 11 ist mit einem Bussystem II1 gezeigt, dass insgesamt eine Ringstruktur gebildet ist, wobei sich ergibt, dass der „rechte" Nachbar der Recheneinheit 2.N die Recheneinheit 2.1 ist.
Die Fig. 12 zeigt die Berechnung einer Kette A.l, A.2, A.3 ..A. N (allgemein A.i) von skalaren Algorithmen, d.h. die gesamte Berechnung wird in Teilberechnungen A.i unterteilt. Die einzelnen Berechnungsstufen werden in benachbarten Recheneinheiten 2.1, 2.2, 2.3 ... 2N abgearbeitet. Die Übergabe der Teilergebnisse erfolgt durch den Datenbus 11 bzw. II1, der die Eingangsregister 6,7 der einzelnen Slices 2.i miteinander verkettet, vgl. Fig. 11. Sind die Teilergebnisse Tl. i fertiggerechnet, werden die Endergebnisse der einzelnen Teilberechnungen A.i in die Eingangsregister 6, 7 der einzelnen Slices 2.i gestellt. Das Eingangsregister 6 oder 7 der jeweils rechten Nachbar-Slices 2. (i+1) kann über den Datenbus 11 bzw. 11' auf dieses Ergebnis zugreifen und nutzt es als Startwert für den nächsten Berechnungszyklus. Somit ergibt sich die Gesamtberechnung aus einer Kette von Teilberechnungen Tl. i, T2.i,... wie oben dargestellt. Jeder Slice 2.i kann sich programmierbar in diese Kette hineinschalten. Durch die starre Synchronisation der einzelnen Slices 2.i durch die Programmablaufsteuerung 3 sind keine weiteren Rechentakte bei der Übergabe der Datenwerte zwischen den Slices 2.i erforderlich. Die Datenbusverbindung 11, 11' der Eingangsregister 6, 7 der Slices 2.i ist ringförmig zusammengeschaltet. Daher sind alle Slices 2.i gleichwertig, und kein Slice ist durch seine Position bevorzugt oder benachteiligt (Beispiel: der ganz rechte Slice 2.N besitzt als „logischen" rechten Nachbar den ersten Slice 2.1).
In Fig. 13 ist die Abarbeitung eines typischen Programms ge- zeigt, wobei die Abarbeitung der Teilprogramme in den Recheneinheiten 2.i durch die getrennten Slice-Programmspeicher 17. i gesteuert wird. Die Startwerte werden vom jeweiligen linken Nachbar-Slice übernommen. Dies geschieht, indem - wie in Fig. 13 bei 70. i veranschaulicht ist - per Programmierung alle Befehlsregister als Datenquelle den Slice-Eingangsport zugewiesen bekommen, der an den Befehlsregister-Ausgang des jeweiligen linken Nachbar-Slices gekoppelt ist. Die zentrale Programmablaufsteuerung 3 erleichtert dabei wesentlich die synchrone Datenübernahme zwischen allen Slices. Die Synchronisation wird dadurch erreicht, dass das Freischalten der Eingangsregister-Datenbusse 13, 14 in der jeweils gleichen Programmzeile eines jeden Slices 2.i erfolgt.
Hier dargestellt ist eine ringförmige Verkettung aller Befehlsregister in der ersten Programmzeile. Tatsächlich kann aber jede Recheneinheit 2.i völlig unabhängig programmiert werden. Dass Daten von einer Recheneinheit zur anderen über den Register-Datenbus 13 bzw. 14 übergeben werden können, wird lediglich dadurch festgelegt, dass in der gleichen Programmzeile der zwei betroffenen Slice-Teilprogramme im einen Slice 2.(i-l) der Datenwert zur Verfügung gestellt wird und dieser im zweiten Slice 2.i mittels Durchschalten des Registerbusses 12 bzw. 13 übernommen wird. Die jeweils betroffenen Slice-Paare 2.(i-l), 2.i können frei wählen, ob und wann ein Datentransfer zwischen den Slices aufgebaut wird.
Es ist auch ein Mischen der oben genannten Algorithmen-Typen möglich. Dabei können die verschiedenen Recheneinheiten 2.i der Rechnereinheit 1 unterschiedliche Algorithmen-Typen gleichzeitig bearbeiten; es können hintereinander unterschiedliche Algorithmen-Typen behandelt werden, und die Rechnereinrichtung 1 kann, ohne zusätzliche Rechentakte zu benötigen, zwischen den Algorithmen-Typen umschalten.
Alle Recheneinheiten 2. i können autark für sich programmiert werden und daher eigenständig Berechnungen durchführen. Das Zusammenschalten von Recheneinheiten 2.i erfolgt mit der Datenbusstruktur, welche die besprochenen Algorithmen optimal unterstützt. Grundsätzlich können den Recheneinheiten 2.1 auch ver- schiedene Algorithmen-Typen zur Berechnung zugeteilt werden, was dadurch ermöglicht wird, dass sowohl die in den Recheneinheiten 2.i ausgeführten Operationen als auch die Verschaltung der Datenpfade über ein Programm flexibel definiert und jederzeit geändert werden können. Da darüber hinaus alle Recheneinheiten 2.1 getrennt programmiert werden können, ist es dann möglich, dass in verschiedenen Recheneinheiten zur gleichen Zeit unterschiedliche Algorithmentypen verarbeitet werden können.

Claims

P a t e n t a n s p r ü c h e :
1. Digitale Rechnereinrichtung (1) mit Parallelverarbeitung, mit mehreren parallel einsetzbaren Arithmetikeinheiten (5) und einer ihnen zugeordnete Steuereinheit, dadurch gekennzeichnet, dass zumindest einige, vorzugsweise alle Arithmetikeinheiten
(5) , mit über Datenbus-Verbindungen (10) zugeordneten Datenspeichern (8, 9) zu parallel geschalteten Recheneinheiten (2.i) mit synchroner Befehlsabarbeitung zusammengefasst sind.
2. Rechnereinrichtung nach Anspruch 1, dadurch gekennzeichnet, dass zwischen den parallel geschalteten Recheneinheiten (2.i) Datenbus-Verbindungen (11) vorgesehen sind.
3. Rechnereinrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass den parallel geschalteten Recheneinheiten (2.i) als Steuereinheit eine zentrale Programmablaufsteuerungseinheit (3) zugeordnet ist.
4. Rechnereinrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass jeder der parallel geschalteten Recheneinheiten (2.i) ein eigener Programmspeicher (17. i) zugeordnet ist.
5. Rechnereinrichtung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass für allgemeine Berechnungen wenigstens eine globale Recheneinheit (4) vorgesehen ist, die mit den parallel geschalteten Recheneinheiten (2.i) verbunden ist.
6. Rechnereinrichtung nach Anspruch 5, dadurch gekennzeichnet, dass die globale Recheneinheit (4) sowohl mit Ausgängen als auch mit Eingängen der parallel geschalteten Recheneinheiten (2.i) über Datenbus-Verbindungen (15) verbunden ist.
7. Rechnereinrichtung nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass der globalen Recheneinheit (4) ein eigener Programmspeicher (17.G) zugeordnet ist.
PCT/AT2005/000311 2005-08-04 2005-08-04 Digitale rechnereinrichtung mit parallelverarbeitung WO2007014404A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/AT2005/000311 WO2007014404A1 (de) 2005-08-04 2005-08-04 Digitale rechnereinrichtung mit parallelverarbeitung
US11/997,874 US20080320276A1 (en) 2005-08-04 2005-08-04 Digital Computing Device with Parallel Processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/AT2005/000311 WO2007014404A1 (de) 2005-08-04 2005-08-04 Digitale rechnereinrichtung mit parallelverarbeitung

Publications (1)

Publication Number Publication Date
WO2007014404A1 true WO2007014404A1 (de) 2007-02-08

Family

ID=36084261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AT2005/000311 WO2007014404A1 (de) 2005-08-04 2005-08-04 Digitale rechnereinrichtung mit parallelverarbeitung

Country Status (2)

Country Link
US (1) US20080320276A1 (de)
WO (1) WO2007014404A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2516288B (en) 2013-07-18 2015-04-08 Imagination Tech Ltd Image processing system
US9348595B1 (en) 2014-12-22 2016-05-24 Centipede Semi Ltd. Run-time code parallelization with continuous monitoring of repetitive instruction sequences
US9135015B1 (en) 2014-12-25 2015-09-15 Centipede Semi Ltd. Run-time code parallelization with monitoring of repetitive instruction sequences during branch mis-prediction
US9208066B1 (en) 2015-03-04 2015-12-08 Centipede Semi Ltd. Run-time code parallelization with approximate monitoring of instruction sequences
US10296346B2 (en) 2015-03-31 2019-05-21 Centipede Semi Ltd. Parallelized execution of instruction sequences based on pre-monitoring
US10296350B2 (en) 2015-03-31 2019-05-21 Centipede Semi Ltd. Parallelized execution of instruction sequences
US9715390B2 (en) 2015-04-19 2017-07-25 Centipede Semi Ltd. Run-time parallelization of code execution based on an approximate register-access specification
JP2021039658A (ja) * 2019-09-05 2021-03-11 富士通株式会社 Ａｃ並列化回路、ａｃ並列化方法及び並列情報処理装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0724221A2 (de) * 1995-01-26 1996-07-31 International Business Machines Corporation Verfahren und Vorrichtung zur Ausführung unähnlicher Befehlsfolgen in einem Prozessor eines Einzelbefehl- und Mehrfahrdatenrechners (SIMD)
EP0726529A2 (de) * 1994-12-29 1996-08-14 International Business Machines Corporation System und Verfahren zur Topologierekonfiguration eines Arrayprozessors

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0726529A2 (de) * 1994-12-29 1996-08-14 International Business Machines Corporation System und Verfahren zur Topologierekonfiguration eines Arrayprozessors
EP0724221A2 (de) * 1995-01-26 1996-07-31 International Business Machines Corporation Verfahren und Vorrichtung zur Ausführung unähnlicher Befehlsfolgen in einem Prozessor eines Einzelbefehl- und Mehrfahrdatenrechners (SIMD)

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ACKLAND B ET AL: "A SINGLE-CHIP, 1.6-BILION, 16-B MAC/S MULTIPROCESSOR DSP", IEEE JOURNAL OF SOLID-STATE CIRCUITS, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, vol. 35, no. 3, March 2000 (2000-03-01), pages 412 - 422, XP000956951, ISSN: 0018-9200 *
FLYNN M J: "Very high-speed computing systems", PROCEEDINGS OF THE IEEE USA, vol. 54, no. 12, December 1966 (1966-12-01), pages 1901 - 1909, XP009064486 *
SANKARALINGAM K ET AL: "Universal mechanisms for data-parallel architectures", MICROARCHITECTURE, 2003. MICRO-36. PROCEEDINGS. 36TH ANNUAL IEEE/ACM INTERNATIONAL SYMPOSIUM ON 3-5 DEC. 2003, PISCATAWAY, NJ, USA,IEEE, 3 December 2003 (2003-12-03), pages 303 - 314, XP010674683, ISBN: 0-7695-2043-X *
SCHULTE M ET AL: "A low-power multithreaded processor for baseband communication systems", COMPUTER SYSTEMS: ARCHITECTURES, MODELING, AND SIMULATION. THIRD AND FOURTH INTERNATIONAL WORKSHOPS, SAMOS 2003 AND SAMOS 2004, PROCEEDINGS (LECTURE NOTES IN COMPUT. SCI. VOL.3133) SPRINGER-VERLAG BERLIN, GERMANY, 2004, pages 393 - 402, XP002374989, ISBN: 3-540-22377-0 *

Also Published As

Publication number Publication date
US20080320276A1 (en) 2008-12-25

Similar Documents

Publication Publication Date Title
WO2007014404A1 (de) Digitale rechnereinrichtung mit parallelverarbeitung
EP0907912B1 (de) Synchronisationsverfahren
EP1228440B1 (de) Sequenz-partitionierung auf zellstrukturen
DE3506749C2 (de)
DE102018126001A1 (de) Synchronisation in einem Multi-Kachel-Verarbeitungsarray
WO1998031102A1 (de) Umkonfigurierungs-verfahren für programmierbare bausteine zur laufzeit
DE3210816A1 (de) Datenverarbeitungssystem mit getrennten einrichtungen zur verarbeitung von skalar- und vektordaten
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
DE3400723C2 (de)
LU93299B1 (de) Ablaufsteuerung von Programmmodulen
DE3855524T2 (de) Arithmetik-Parallelverarbeitungseinheit und zugehöriger Kompilator
WO2008003427A2 (de) Verfahren zur prüfung der echtzeitfähigkeit eines systems
DE102009027627B3 (de) Simulation von Echtzeit-Software-Komponenten auf Basis der Logischen Ausführungszeit
EP2732347B1 (de) Verfahren und system zur dynamischen verteilung von programmfunktionen in verteilten steuerungssystemen
EP2386949B1 (de) Verfahren und Vorrichtung zum zuweisen einer Mehrzahl von Teilaufgaben einer Aufgabe zu einer Mehrzahl von Recheneinheiten einer vorgegebenen Prozessorarchitektur
EP3417373B1 (de) Verfahren und vorrichtung zum betreiben eines steuergeräts
DE2944757A1 (de) Prozessrechner
DE102017130552B3 (de) Verfahren zur Datenverarbeitung und speicherprogrammierbare Steuerung
EP1116129A2 (de) Konfigurierbarer hardware-block
DE4446988A1 (de) Schneller Testmustergenerator
EP1789889B1 (de) Rechnereinrichtung mit rekonfigurierbarer architektur zur aufnahme eines globalen zellularen automaten
DE102010064244A1 (de) Steuerarchitekturen für HF-Sende/Empfangsgeräte
AT501479A4 (de) Digitale rechnereinrichtung
DE60302103T2 (de) Steuerungsvorrichtung für eine Maschine
DE102017126094A1 (de) Verfahren zum Auslesen von Variablen aus einem FPGA

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC (EPO FORM 1205A DATED 10-04-08)

WWE Wipo information: entry into national phase

Ref document number: 11997874

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 05767890

Country of ref document: EP

Kind code of ref document: A1