Titel : REKONFIGURIERBARE FLIESSKOMMA- UND BIT- EBENEN DATENVERARBEITUNGSEINHEIT

Beschreibung

Die vorliegende Erfindung betrifft die Datenverarbeitung und insbesondere, jedoch nicht ausschließlich, eine rekonfigu- rierbare Datenverarbeitungseinheit mit einer erfindungsgemäßen Erweiterung zur beschleunigten Verarbeitung von Floating- Point Zahlen sowie Verfahren zur Datenverarbeitung und/oder Bit Daten.

Datenverarbeitungsverfahren und eine entsprechende optimierte konventionelle Prozessoren.

Unter einer rekonfigurierbaren Architektur werden u. a. Bausteine (VPU) verstanden, die eine Vielzahl in Funktion und/oder Vernetzung im Betrieb, insbesondere, jedoch nicht ausschließlich ohne Störung anderer Einheiten und/oder Elemente zur Laufzeit veränderlicher Elemente aufweisen. Zu den Elementen können arithmetische Logikeinheiten, FPGA-Bereiche, Ein-Ausgabezellen, Speicherzellen, analoge Baugruppen usw. gehören. Bausteine dieser Art sind beispielsweise unter der Bezeichnung VPU bekannt. Diese umfaßt typisch als PAEs bezeichnete ein- oder mehrdimensional angeordnete arithmetische und/oder logische und/oder analoge und/oder speichernde und/oder vernetzende Baugruppen und/oder kommunikative peri- phere Baugruppen (10) , die direkt oder durch einen oder mehrere Bussysteme miteinander verbunden sind. Die PAEs sind in beliebiger Ausgestaltung, Mischung und Hierarchie angeordnet,

- l -

wobei die Anordnung als PAE-Array oder kurz PA bezeichnet wird. Es kann dem PAE-Array oder Teilen desselben eine konfigurierende Einheit zugeordnet sein. Prinzipiell sind neben VPU-Bausteinen auch systolische Arrays, neuronale Netze, Mehrprozessorsysteme, Prozessoren mit mehreren Rechenwerken und/oder logischen Zellen, Vernetzungs- und Netzwerkbausteine wie Crossbar- Schaltung usw. bekannt, genauso wie FPGAs, DPGAs, Transputer usw. Die erfindungsgemäßen Elemente, d.h. die beschriebenen Floating-Point-Anordnungen sind ohne Weite- res z.B. in Xilinx-Bausteine der jüngeren Virtex-Familie integrierbar und/oder in andere FPGAs bzw. DSPs bzw. Prozessoren.

Es wird darauf hingewiesen, daß wesentliche Aspekte der VPU- Technik in den folgenden Schutzrechten desselben Anmelders sowie den zugehörigen Nachanmeldungen zu den aufgeführten Schutzrechten beschrieben sind:

P 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 102 06 856.9, 60/317,876, DE 102 02 044.2, DE 101 29 237.6-53, DE 101 39 170.6, PCT/EP 03/09957, PCT/EP 2004/006547, EP 03 015 015.5, PCT/EP 2004/009640, PCT/EP 2004/003603, EP 04 013 557.6, PACT62, PACT68.

Es sei darauf hingewiesen, daß die vorgenannten Dokumente zu Offenbarungszwecken insbesondere hinsichtlich Besonderheiten und Details der Vernetzung, Konfiguration, Ausgestaltung von

Architekturelementen, Triggerverfahren usw. eingegliedert sind, ohne vorliegend beschränkend zu sein, insbesondere was dort enthaltene Definitionen und dergl . angeht

Figur 1 zeigt beispielhaft den Aufbau einer rekonfigurierba- ren Datenverarbeitungseinheit. Eine rekonfigurierbaren Datenverarbeitungseinheit kann beispielsweise ein FPGA (z.B. XI- LINX Virtex, ALTERA) , oder ein rekonfigurierbarer Prozessor (z.B. PACT XPP, AMBRIC, MATHSTAR, STRETCH) oder Prozessor (z.B. STRETCHPROCESSOR, CRADLE, CLEARSPEED, INTEL, AMD, ARM) sein oder auf dessen Basis aufgebaut oder an diesen angeschlossen sein. Reconfigurierbare, bevorzugt grobgranulare und/oder gemischt Grob-/Feingranulare Datenverarbeitungs- Zellen (0101) sind in einem 2- oder mehrdimensionalen Array (0103) angeordnet. Weiterhin befinden sich im Array, in einer möglichen Ausführung an den Kanten Speicher-Zellen (0102) . Jede Zelle einzeln, oder auch Gruppen von Zellen gemeinsam sind bevorzugt in ihrer Funktion zur Laufzeit konfigurierbar. Dabei ist es besonders vorteilhaft, wenn die Konfiguration und/oder Umkonfiguration zur Laufzeit ohne Beeinflussung nicht zu umzukonfigurierender Zellen erfolgt.

Die Zellen sind über ein Netzwerk (0104) miteinander verbunden, das Netzwerk ist bevorzugt ebenfalls zur Laufzeit in seiner Verbindungsstruktur und/oder Topologie frei konfigurierbar und/oder umkonfigurierbar. Dabei kann es vorteilhaft sein, wenn die Konfiguration und/oder Umkonfiguration zur Laufzeit ohne Beeinflussung nicht umzukonfigurierender Netzwerksegmente erfolgt . Der rekonfigurierbare Prozessor tauscht Daten und/oder Adressen mittels IO Einheiten (0105) , die Adressgeneratoren, FIFOs, Caches und der gleichen aufweisen können mit Peripherie und/oder Speicher aus.

Figur 2 zeigt beispielhaft den Aufbau einer rekonfigurierbaren Zelle, die beispielsweise als grobgranulare Datenverarbeitungszelle (0101) oder Speicherzelle (0102) oder Logikver- arbeitungszelle (z.B. LUT basierende CLB, wie in der FPGA

Technik verwendet) implementiert sein kann. Die Zelle besitzt Anschlüsse an das Netzwerk (0104) derart, dass eine Einheit zum Abgriff von Operanden vom Netzwerk (0104a) und eine Einheit zum Aufschalten der Ergebniss auf das Netzwerk (0104b) vorgesehen ist. Die Zellen werden horizontal und/oder vertikal kaskadiert, sodass dabei die BusaufschaltVorrichtung (0104b) einer oben liegenden Zelle auf den Bus der Busabgriffseinheit (0104a) einer darunterliegenden Zelle aufschaltet.

Im Kern (0201) der Zelle befindet sich eine Einheit, die je nach Zellfunktion unterschiedlich ausgestaltet sein kann, z.B. als grobgranulare Recheneinheit, als Speicher, als Logikeinheit (FPGA) , oder als fest implementierter ASIC. Im Rahmen der vorliegenden Beschreibung wird es sich im folgenden typischerweise um eine 16-bit breite grobgranulare DSP- und/oder Prozessor-ähnliche Recheneinheit (ALU) handeln.

Bevorzugt ist zumindest dem Kern (0201) eine Steuereinheit zugeordnet (0204) , die den Ablauf der Datenverarbeitung steuert (0205) und/oder Statusinformation (TRIGGER) wie z.B. ü- bertrag (CARRY) , Vorzeichen (NEGATIVE) , Vergleichswerte (ZE- RO, GREATER, LESS, EQUAL) verarbeitet und/oder an den Kern zur Berechnung weitergibt (0205) und/oder von diesem entge- gennimmt (0205) . Die Steuereinheit (0204) kann TRIGGER vom Netzwerk abgreifen und/oder auf das Netzwerk aufschalten.

Parallel zum Kern (0201) sind bei einer möglichen Ausgestaltung Einheiten zur Datenübertragung vom darüberligenden Netzwerk auf das darunterliegende Netzwerk (0202) oder in umgekehrter Richtung (0203) vorgesehen, bevorzugt seitlich. Be- vorzugt befinden sich in den bevorzugt seitlichen Einheiten (0202 oder/und 0203) neben Datenweiterleitungsmitteln auch Datenverarbeitungsmittel, die z.B. Rechenoperationen (ALU- Operationen wie Addition, Subtraktion, Schieben) und/oder Datenverknüpfungsoperationen wie Multiplexe, Demultiplexen, Mergen, Swappen, Sortieren der durch die Einheiten übertragenen Datenströme ermöglicht. Die beiden Einheiten sind bevorzugt so ausgestaltet, dass sie zusätzlich zu ihren DATEN- Verarbeitungsfunktionen sowohl die Weiterleitung von TRIGGERN, als auch deren Verarbeitung, beispielsweise mittels FPGA-ähnlichen Look-up Tabellen (LUTs) ermöglichen.

Nachfolgend wird der Kern mit seinen zugeordneten Netzwerkanschlüssen auch als CORE bezeichnet. Die seitlichen Einheiten mit ihren zugeordneten Netzwerkanschlüssen werden auch als FREG bei Datenübertragung von oben nach unten bzw. als BREG bei Datenübertragung von unten nach oben bezeichnet .

Eine Zelle bestehend aus CORE, FREG und BREG wir als PAE (Processing Array Element) bezeichet. Weist der CORE bei- spielsweise ein Rechenwerk (ALU) auf, handelt es sich um eine ALU-PAE. Ist im CORE Speicher (RAM) implementiert, handelt es sich um eine RAM-PAE. Beliebige weitere CORE Implementierungen sind möglich, insbesondere FPGA-ähnliche logikverarbei- tungs-Einheiten (Logic Processing = LP), z.B. in LP-PAEs.

Bevorzugt wird das Netzwerk zur Synchronisation des Austausches von DATEN und/oder TRIGGERN mit Synchronisationsmitteln

ausgestaltet, z.B. Handshake Leitungen, Triggersignalübertragungen, insbesondere bevorzugt maskierbare Triggervektorsig- nalübertragungen etc. Es sei auf das RDY/ACK Protokoll der Anmelderin verwiesen.

Rekonfigurierbare Zellen nach dem Stand der Technik sind entweder zur Verarbeitung von einzelnen Signalen (bits) FPGA- ähnlich als Lookup Tabellen (LUTs) ausgestaltet und/oder weisen grobgranulare Rechenwerke auf, die typischerweise ganz- zahlige Werte (Fixpunkt Zahlen) berechnen, deren Breite typischerweise im Bereich von 4- bis 48-bit liegt. Die aufwendige Berechnung von Fließkomma- Zahlen wird von diesen Zellen nicht unterstützt, kann jedoch durch das konfigurierte Zusammenschalten einer Vielzahl von Zellen berechnet werden. Die kon- figurierte Zusammenschaltung der Zellen ist jedoch äußerst ineffizent, da eine große Anzahl von Zellen benötigt wird und viele Daten über das Netzwerk übertragen werden müssen. Dies führt zum Ansteigen des Stromverbrauchs und einer deutlich reduzierten Performance bei der Berechnung von Fließkommazah- len aufgrund der ineffizienten Zusammenschaltung vieler Zellen.

Eine Implementierung von Fließkomma-Arithmetik in die einzelnen Zellen erweist sich als nicht sinnvoll, da die Arithmetik eine große Anzahl Hardwareresourcen erfordert und zudem

Fließkommazahlen breiter (single precision = 32bit, double precision = 64bit) als typische Festkommawerte (z.B. 16bit) sind. Damit müßten die Bussysteme auf die Breite der Floating-Point Zahlen angepaßt werden, was allerdings bei der ty- pischerweise häufigeren Berechnung von Festkommazahlen als äußerst flächenineffizient erweist. Selbst wenn eine rekonfi- gurierbare Datenverarbeitungseinrichtung hauptsächlich zur

Berechnung von Fließkommazahlen eingesetzt wird, wäre es immer noch ineffizient die Bussysteme für die Breite von Doub- le-Precision Floating-Point Zahlen auszubauen, da applikativ zumeist Single-Precision Zahlen verwendet werden. Im folgen- den wird eine Anordnung beschrieben, die unter anderem eine effizientere Nutzung der Bussysteme ermöglicht. Es soll ausdrücklich angemerkt sein, dass, obwohl die Beschreibung auf der Granularität von auf Festpunkt Zahlen optimierten PAEs aufbaut, die Erfindung auch auf Single-Precision Zahlen opti- mierte PAEs anwendbar ist, insbesondere dann, wenn die einzelne PAE zugleich für die jeweils SIMD-artige Berechnung mehrerer Fixedkomma-Zahlen ausgestaltet ist.

Die vorliegende Erfindung beschriebt die Implementierung ei- ner optimierten, resourcen- und leistungseffizienten Fließkommaverarbeitung .

Aufgabe der Erfindung ist es neues für die gewerbliche Nutzung zu schaffen.

Figur 3 zeigt beispielhaft den erfindungsgemäßen Aufbau, die hier aus den 4 ALU-PAEs (ALU-PAEl, ..., ALU-PAE4) zusammengesetzt ist, wobei hier jede ALU-PAE wiederum aus FREG, BREG, und CORE ( { FREGl , BREGl , COREl } , { FREG2 , BREG2 , CORE2 } , ... ) aufgebaut ist . In diesem Beispiel sind die einzelnen Datenworte 16-bit breit, es handelt sich folglich um 16-bit breite Busse, die Operanden und Ergebnisse der FREGs, BREGs, und CO- REs sind 16-bit oder Multiplikationsergebnissen 32-bit. (Dabei bleibt für Zwecke der vorliegenden Offenbarung unbe- rücksichtigt, dass der Datenbus breiter als die Datenworte sein kann, um etwa Synchronisations- , Triggersignale und - Informationen usw. mit übertragen zu können. Daß im übrigen

ein separates Synchronisations- und/oder Triggernetzwerk bzw. -leitungen vorgesehen sein können und/oder Schaltkreismittel zum Aufbau, z.B. rekonfigurierbaren Aufbau derselben sei erwähnt) . w sei die Breite einer in einer ALU-PAE berechenbaren Festkomma Zahl (beispielsweise 16-bit) . p sei die Breite einer zu implementierenden Fließkommaeinheit (z.B. p=32 fuer Single Precision, p=64 für Double Precision) .

ALU-PAEs weisen typischerweise mindesten zwei Operanden- Eingänge A und B auf . Die Breite der Eingänge entsprechen typischerweise, aber nicht zwingend der Breite der berechenbaren Festkomma- Zahlen.

Mehrere ALU-PAEs werden derart zu einer neuen Hierarchie (Box) zusammengefaßt, dass die die Summe der Breite ihrer A _f i _x bzw. B _fIx Operandeneingänge der erforderlichen Breite eines Operanden A _f i _oa t bzw. B _f i _oat der Fließkommaeinheit entspricht. Mit anderen Worten gilt n= Width(A _float ) / Width(A _int ) und somit Width(A _flOat ) = ∑ Width(A _int [0..n]) bzw. n= p / w und somit p = ∑ w[0.. n].

Innerhalb der neuen Hierarchie (Box) wird nunmehr ein Fließkommarechenwerk der Breite A _f i _oa t = P implementiert. Damit ergeben sich folgende Vorteile: 1. Die Resourcen eines Fließkomma-Rechenwerks verteilen sich auf n Festkomma Rechenwerke (ALU-PAEs) . Da in typischen Applikationen weniger Fließkomma- als Festkomma-Operationen benötigt werden, ergibt sich hieraus ein weitestgehend ideales Verhältnis bei optimaler Resourcenverwendung . 2. Das Festpunkt -Zahlen-Netzwerk implementiert für die Breite der Festkommaeinheiten (ALU-PAEs) kann unverändert für Fließkommazahlen genutzt werden, indem mehrer der Festkommanetz-

Werkverbindungen zu einer Fließkommaverbindung gebündelt werden.

Figur 3 zeigt einen erfindungsgemäßen Aufbau bestehend aus 4 ALU-PAEs (ALU-PAEl = { FREGl, COREl, BREGl }, ALU-PAE2 =

{FREG2, CORE2, BREG2 },...) . In einer ersten Box (DOUBLEl), bestehend aus den zwei ALU-PAEs ALU-PAEl und ALU-PAE2 wird zusätzlich ein Single-Precision Floating-Point Rechenwerk (0301) implementiert. Dieses zusätzliche Floating-Point- Rechenwerk ist in herkömmlichen Array-Elementen nicht vorhanden. Es wird auch nicht durch reine Konfiguration aus ohnehin vorhandenen Schaltungen zusammengestellt, sondern es werden vielmehr nur für den Betrieb des zusätzlichen Floating-Point- Rechenwerkmittels vorhandene Schaltkreiselemente nutzbar ge- macht, die aber alleine, d.h. ohne die dedizierte zusätzliche Hardware des Floating-Point-Rechenwerkes nicht, jedenfalls nicht so gut für Floating-Point-Operationen einsetzbar wären. 0401 verwendet die Eingänge der ALU-PAEl und ALU-PAE2 als 0- perandeneingang und die Ausgänge der beiden ALUs als Ergebni- sausgäng. Das Floating-Point Zahlenformat (in diesem Beispiel 32-bit) wird über mehrere (in diesem Beispiel 2) zusammengefaßte Festkomma-Busse (in diesem Beispiel 16-bittig) übertragen.

In einer zweiten Box (DOUBLE2) sind - wie für DOUBLEl beschrieben - die ALU-PAEs ALU-PAE3 und ALU-PAE4 zu einem weiteren Single-Precision Floating-Point Rechenwerk zusammengefaßt (0302) , d.h. mit einem weiteren zusätzlichen Floating- Point -Rechenwerk versehen.

Weiterhin wird eine dritte Box (QUAD) gebildet, die aus den Boxen DOUBLEl und DOUBLE2 besteht. Diese Box besteht nunmehr

aus 4 ALU-PAEs und weist (in diesem Beispiel) jeweils 4 x 16- bit = 64-bit Eingänge für die Operanden A und B auf und entsprechend viele Ausgänge für die Ergebnisse. Die Breite der Operanden-Eingänge und Ergebnis-Ausgänge reicht nunmehr aus, um innerhalb des QUADs ein 64-bit Double Precision Floating- Point Rechenwerk zu implementieren. Dazu wird- neben den beiden single-precision-Rechenwerken, die hardwaremässig zusätzlich bereits in den Boxen erfindungsgemäß im beschriebenen Ausführungsbeispiel vorgesehen sind- ein weiteres, jetzt als Double-Precision-Rechenwerk ausgestaltetes, zusätzliches Floating-Point-Rechenwerk vorgesehen. Es sei erwähnt, dass eine Verschachtelung nicht zwingend ist. Wenn vorbekannt ist, dass nur und ausschliesslich Double-Precision-Rechenwerke benötigt werden, kann gegebenenfalls auch auf das Vorsehen der beiden Single-Precision-Rechenwerke in den Einzelboxen verzichtet werden und direkt und ausschliesslich ein Double-Precision- Rechenwerk vorgesehen werden. Das umgekehrte trifft gleichfalls zu. Auch sind innerhalb eines Zellfeldes Mischformen möglich. Bevorzugt ist es unter anderem, wenn zeilen- und/oder spaltenweise Floating-Point (d.h. Fliesskomma-) - Rechenwerke vorgesehen werden

Figur 3 zeigt nur einen Ausschnitt einer rekonfiguriebaren Datenverarbeitungseinheit nach Figur 1. Die hier aufgezeigte Struktur kann über die gesamte Datenverarbeitungseinheit skaliert werden, also sämtliche PAEs der Einheit sind entsprechend zu Boxen zusammengefaßt. Andererseits kann, sofern ap- plikativ weniger Floating-Point Leistung erforderlich ist, auch nur ein Teil oder Teile einer Datenverarbeitungseinheit die erfindungsgemäße Floating-Point Struktur aufweisen, dies geschieht dann bevorzugt spaltenweisen, d.h. PAEs werden spaltenweise entsprechend zusammengefaßt .

Dass den Floating-Point -Rechenwerken Statemachines zugeordnet werden, ist nicht zwingend erforderlich, wohl aber möglich. Statemachines sind aber besonders dann vorteilhaft, wenn Ite- rationen wie für Wurzelberechnungen und/oder Divisionen typisch erforderlich sind oder sein können. In einem solchen Fall werden die Floating-Point-Rechenwerke oder zumindest ein Teil davon bevorzugt Register oder andere Speicherzugriffsmöglichkeiten aufweisen, beispielsweise durch Zugriff auf Speicher-Elemente im Array, in denen Lookup-Tabellen für

(trigonometrische und/oder andere) Funktionen abgelegt sein können, und zwar konfigurierbar und/oder festintegriert. Vor allem, aber nicht nur wenn Iterationen und/oder andere, insbesondere sequenzerartige Verwendungen der oder eines Floa- ting-Point-Rechenwerkes vorgesehen werden, ist es überdies und/oder zusätzlich vorteilhaft, eine Rückkopplung der Operanden-Ausgänge an die Operanden-Eingänge vorzusehen. Dass gegebenenfalls auch Rückführungen für Statussignale möglich sind, sei erwähnt.

Zur besseren übersicht zeigt Figur 4a nochmals die in Figur 3 beschriebene und insoweit auch klar bevorzugte Anordnung, sowie die DOUBLE und QUAD Boxen.

Figur 4b zeigt das Mapping der Floating-Point Datenformate auf die Fixpunkt -Formate der ALU-PAEs. Dargestellt sind 4 ALU-PAEs (0410) und deren Wortformat von viermal 16-bit (0411) . Darunter (0411) wird die Wortbreite von zwei 32-bit Floating Point Zahlen gezeigt und darunter (0412) die Wort- breite von einer 32-bit Floating Point Zahl.

- li -

0414 zeigt das Mapping zweier 32-bit Single Precision Floating Point Zahlen und 0415 das entsprechende Mapping for eine 64-bit Double Precision Floating Point Zahl, s bezeichnet das Vorzeichen (Sign) .

Ein wesentliches Problem stellt der Umgang mit Fehlersignalen, wie z.B. überlauf, Unterlauf, Division durch null und fehlerhafte Zahlendarstellung (Not a Number = NaN) dar. Bei Prozessoren, die typischerweise nur ein Floating-Point Re- chenwerk aufweisen, wird typischerweise ein Interrupt ausgelöst, um das Auftreten eines Fehlers anzuzeigen. In einer Da- tenflußarchitektur, bei der eine Vielzahl von Floating-Point Rechenwerken in beliebiger Anordnung, Topoplogie und Reihenfolge mittels des Netzwerks zusammengeschaltet werden können, ist das Auslösen eines Interrupts bzw. die Feststellung der Fehlerquelle nicht ohne weiteres durchführbar.

Je nach Einsatzbereich werden erfindungsgemäß die folgenden Verfahren und Strukturen eingesetzt. Diese nachfolgend aufge- zeigten Varianten müssen nicht, insbesondere nicht alle implementiert sein, auch wenn dies ersichtlich vorteilhaft sein kann.

A) Die Fehleranzeigen sämtlicher Floating-Point Rechenwerke werden auf ein Leitungsnetz aufgeschaltet , das einer überge- ordneten Einheit das Auftreten eines Fehlers anzeigt. Dies kann durch Auslösen einer Interrupts bei einer übergeordneten, das Ergebnis weiterverarbeitenden Einheit erfolgen. Jedes Flaoting-Point Rechenwerk speichert den aufgetretenen Fehlerzustand, also z.B. überlauf, Unterlauf, Division durch Null und fehlerhafte Zahlendarstellung (Not a Number = NaN) . Dieser Speicher kann von einer übergeordneten, das Ergebnis weiterverarbeitenden Einheit abgefragt werden, typisch jeder-

zeit, bevorzugt jedoch im Ansprechen auf eine Fehlererkennung abgefragt werden. Dass anstelle eines passiven Vorhaltens von Fehlerrelevanten In formaqtionen zur Abfrage stattdessen und/oder zusätzlich auch eine aktive übertragung an relevante stellen erfolgen kann, sei erwähnt. Die Abfrage kann z.B. mittels JTAG erfolgenden, insbesondere kann eine auf der ü- bergeordneten oder externen Einheit ablaufende Debuggersoftware, die Fehlerzusände abfragt. B) Ein alternatives Verfahren ist die Aufschaltung von Feh- lersignalen (z.B. überlauf, Unterlauf, Division durch null und fehlerhafte Zahlendarstellung (Not a Number = NaN) ) auf das TRIGGER-Netzwerk innerhalb der rekonfigurierbaren Datenverarbeitungseinheit. Das TRIGGER-Netzwerk leitet die Fehlersignale an die nachfolgend die Daten verarbeitenden Floating- Point-Rechenwerke weiter, diese verODERn die eingehenden Fehlersignale z.B. mit in dem eigenen Rechenwerk auftretenden Fehlern und senden diese dann wieder auf dem TRIGGER-Netzwerk zusammen mit den Daten weiter. Bei diesem Verfahren wird also mit - bevorzugt jedem - auf dem DATEN Netzwerk übertragenen Floating-Point Datenwort eine Fehlerkennung auf dem TRIGGER Netzwerk mitübertragen. Dies muss nicht für alle Netzwerkverbindungen realisiert sein, es kann applikationsabhängig ausreichend sein, wenn diese Weiterleitung auf zumindest einigen der Datenverbindungen erfolgt. Mit (bevorzugt) jedem gene- rierten Rechenergebnis der reconfigurierbaren Datenverarbeitungseinheit wird sodann ein Fehlerzustand ausgegeben, der die Korrektheit / oder Fehlerhaftigkeit des Ergebnisses anzeigt. Bei Auftreten eines fehlerhaften Ergebnisses kann nunmehr ebenfalls ein Interrupt generiert bei einer übergeordne- ten, das Ergebnis weiterverarbeitenden Einheit werden und/oder der Ergebnisfehlerzustand kann von einer übergeord-

neten, das Ergebnis weiterverarbeitenden Einheit abgefragt werden.

Wie in Verfahren A) kann jedes Floating-Point Rechenwerk den aufgetretenen Fehlerzustand speichern, also z.B. überlauf,

Unterlauf, Division durch null und fehlerhafte Zahlendarstellung (Not a Number = NaN) . Dieser Speicher kann von einer ü- bergeordneten Einheit jederzeit, bevorzugt jedoch im Ansprechen auf das Auftreten eines als fehlerhaft gekennzeichneten Ergebnisses abgefragt werden. Dies kann z.B. mittels JTAG erfolgenden, insbesondere kann eine auf der übergeordneten oder externen Einheit ablaufende Debuggersoftware die Fehlerzusän- de abfragen .

Figur 4c zeigt beispielhaft die Verknüpfung verschiedener Fehlerzustände (Events) in einem Floating-Point Rechenwerk. Intern auftretenden Fehler werden mit den jeweils eingehenden Fehlersignalen der jeweiligen Operanden (z.B. A und B) verknüpft und mit dem Ergebnis weitergeleitet.

Je nach Einsatzbereich der Architektur kann anstatt der Implementierung von zwei Single-Precision und/oder einem Double- Precision Floating-Point Rechenwerk je QUAD die Implementierung eines bzw. mehrerer SIMD Floating Point Rechenwerke von Vorteil sein, um eine Double- bzw. Multiple-Precision-

Floating Point Zahl oder per SIMD zwei Single (bzw. z.B. MuI- tiple-Halbe) Floating Point Zahlen berechnet. Es wird hierzu auf die Schrift "A New Archtecture For Multiple-Precision Floating-Point Multiply-Add Fused Unit Design", Libo Huang, Li Shen, Kaui Dai, Zhiying Wang, School of Computer, National University of Defense Technology, Changsha, 410073, P.R.China verwiesen, das zu Offenbarungszwecken vollumfänglich einge-

gliedert wird. Im Hinblick auf den Funktionsumfang der Fliesskommarechenwerke kann es ausreichend sein, wenn diese für Multiplikation, Addition und Subtraktion, bevorzugt auch Wurzelbildung und Division ausgelegt, was die Implementierung weiterer Funktionen in komplexeren Rechenwerken aber nicht ausschliessen soll und was im übrigen auch nicht ausschlies- sen soll, dass weitere, insbesondere vergleichende Funktionen wie größer, kleiner, gleich, grössernull, kleinernull, gleichnull usw. sowie insbesondere auch Formatkonversions- funktionen z.B. Double-Precision in Integer implementiert werden.

Weiterhin kann es in Einsatzbereichen von Vorteil sind, anstatt mehrere PAEs zu einem DOUBLE zusammenzufassen, die Ver- arbeitungsbreite innerhalb einer PAE und damit auch deren

Busbreite zu vergrößern und die Festkomme-Rechenwerke innerhalb einer PAE als SIMD Rechenwerke derart auszugestalten, dass entweder eine Berechnung voller Breite oder mehrere Berechnungen mit geringerer Breite zugleich ausgeführt werden können, beispielsweise eine 32-bit Berechnung oder 2 16-bit Berechnungen zugleich oder 1 16-bit und 2 8-bit Berechnungen zugleich oder 4 8-bit Berechnungen zugleich, etc..

Es sei hierzu auf Figur 5 verwiesen, in welcher die 16- bittige XPP-III Architektur der Anmelderin auf 32-bit mit

SIMD Fähigkeit erweitert wurde, wobei somit jede ALU-PAE auch eine Single Precision Floating Point Berechnung durchführen kann.

Weiterhin können auch bei diesem Verfahren ALU-PAEs zusammengefaßt werden um eine größere Verarbeitungsbreite zu ermöglichen, z.B. können mit zwei 32-bit SIMD/Single-Precision ALU-

PAEs ein 64-bit Double-Precision DOUBLE (vormals QUAD) gebildet werden .

Bevorzugt weisen die Floating-Point Rechenwerke eine oder mehrere interne Registerstufen, sogenannte Pipeline-Stages auf, die den Betrieb der Rechenwerke bei hohen Frequenzen ermöglichen. Dies ist insbesondere bei Datenflußarchitekturen wie bei der PACT XPP Technologie der Anmelderin von großem Vorteil, da diese Architekturen typischerweise keine oder nur wenig Pipeline-Stalls aufweisen. Weiterhin vermeidet das Prozessormodell weitestgehend Schleifen innerhalb einer Konfiguration, sodass es zu keinen Rückkopplungseffekten kommt, die sich negativ auf die Performance bei der Verwendung von Pipelines auswirken. Es sei in diesem Zusammenhang insbesondere auf die Compiler-bezogenen Patentanmeldungen der Anmelderin hingewiesen, die zu Offenbarungszwecken vollumfänglich eingegliedert sind.

Es sei darauf hingewiesen, dass bei der oben dargestellten bevorzugten Ausführungsform, die per se ohnhin benötigten Bus- bzw. Leitungsstrukturen auf einem integrierten Array- Schaltkreis bevorzugt am Ausgang von Boxen, bevorzugt jeder Box Multiplexer vorgesehen sind, mit denen alternativ Ausgangssignale von den herkömmlichen Rechenwerken, also den Fi- xed-Point -Rechenwerken, und den Fliesskommarechenwerken auf einen Bus oder ein anderes Ausgangselement wie einen Speicher, einen I/O-Port und dergl . geschaltet werden können. Dieser Mulitplexer kann in einer bevorzugten Variante entweder gespeist werden von den Integer-Rechenwerken in einer Einzelzelle, dem Single-Precision-Fliesskommarechenwerk einer zwei Einzelzellen zusammenfassenden Box oder dem Double- Precisionrechenwerk einer Doppelbox. Dass hierbei neben Daten

entsprechende Trigger- und/oder Synchronisations- und/oder Steuersignale auch mitmultiplexbar sind, sei erwähnt.

Ein weiterer Aspekt der Erfindung bezieht sich auf eine effi- zente Einheit zur Bearbeitung von boolschen Operationen (BPU Bit Processing Unit) . Applikativ sind beispielsweise die folgenden Berechnungen für die Einheit von besonderer Bedeutung: Implementierung von Zustands-Maschinen (Statemachines) Implementierung von Decodern und Encodern Durchführung von Permutationen auf Bit -Ebene, wie z.B. für DES/3DES erforderlich

Implementierung von serieller Bit -Arithmetik wie z.B. Pseudo- Noise-Generators

Grobgranulare Rechenwerke, wie ALUs eignen sich für die beispielhaft genannten Anwendungen schlecht, das sehr viele Rechenschritte zur Berechnung eines einzelnen Bits notwendig sind, zugleich wird oftmals von einem breiten Datenwort (z.B. 16-bit) nur wenige Bits, im typischen Fall sogar nur eines, tatsächlich verwendet.

FPGA Technologien nach dem Stand der Technik (z.B. XILINX, ALTERA) sind zwar in der Lage alle beispielhaft genannten Funktionen auszuführen, jedoch vergleichsweise ineffizient in Hinsicht auf die notwendige Fläche, die Anzahl von Konfigurationsbits und den Stromverbrauch.

Die erfindungsgemäße BPU soll in ihrer Ausführung weniger eine beliebige Einsetzbarkeit für Logik-Netzwerke aufweisen, sondern besonders auf folgende Funktionalität spezalisiert sein: 1. Aufbau von Statemachines

2. Aufbau von Zählern und Schiebern

3. Aufbau von Bit -Permutatoren (z.B. für DES)

4. Aufbau von Bedingten Multiplexern

5. Aufbau von dichten und effizenten Bit-seriellen Operatio- nen (z.B. für Pseudo-Noise Generatoren)

Ein erster wesentlicher Aspekt der vorliegenden Erfindung liegt in der Implementierung von Hardware-Elementen zur Ausführung von dichten und effizenten Bit-seriellen Operationen.

Insbesondere im Ansatz bedingte Multiplexer direkt in Hardware zu unterstützen wird ein weiterer wesentlicher Aspekt der Erfindung gesehen. Neben der besonderen Wichtigkeit beliebige Multiplex-Funktionallität auf Bit Ebene zu gewähr- leisten, z.B. für beliebige Bit Permutationen, Extraktionen oder Zusammenführungen, kann jedes beliebige Combinatorische Netzwerk auf Multiplexern aufgebaut werden. Hardware Design Sprachen (HDLs) wie Verilog oder VHDL basieren im wesentlichen auf der Verwendung von bedingten Multiplex Operationen, die dann von Synthese Tools in Gatternetzlisten übertragen werden .

Die nachfolgend beschriebene Architektur ermögliche eine einfacherer und schnellere Abbildung von HDL Konstrukten. Syn- these Tools für FPGA Architekturen nach dem Stand der Technik weisen mittlerweile Laufzeiten von mehreren Stunden bis Tagen auf, sodass eine schnellere Abbildbarkeit von erheblichem Vorteil ist.

Insbesondere ist die HDL auch optimaler vom Programmierer beschreibbar, da er ein einfaches und grundlegendes Verständnis für die darunterliegende Hardware besitzt und somit seinen

Code, die Arithmetik/Architekture und Implementierung erheblich besser optimieren kann. Synthese Tools nach dem Stand der Technik bieten zwar zumeist recht gute automatische Optimierungstechniken, die häufig jedoch an besonders kritischen und relevanten Codestellen versagen; zugleich nehmen die Synthesetools jedoch jede direkte Einflußmöglichkeit auf die Hardware, sodass eine optimale Implementierung häufig kaum möglich ist.

Der bedingte Multiplexer ist ein typischen Konstrukt in HDLs und bildet zugleich das wesentliche Modell komplexe Logik auszudrücken : varl = if (bool_funcl) ? (bool_func2) : (bool_func3) Ist die Boolsche Funktion bool_funcl wahr wird der Variable varl die Boolsche Funktion bool_func2 zugewiesen, ansonsten bool_func3.

Erfindungsgemäß weisen Logikverarbeitungseinheiten nunmehr einen Vergleicher auf, der die logische Wahrheit bzw den lo- gischen Wert von bool_funcl evaluiert . Dies erfolgt bevorzugt über einen gewöhnlichen schnellen Vergleicher, z.B. aus verknüpften XOR Gattern aufgebaut. Das Evaluationsergebnis (TRUE/FALSE <=> 1/0) wird an einen oder mehrere Multiplexer weitergeleitet, die je nach Ergebnis bool_func2 (wenn TRUE = 1) oder bool_func3 (wenn FALSE = 0) auf den Ausgang varl auf- schalten. Die Multiplexer können dabei 1 bit breit oder mehrere bit breit sein, bevorzugt wird die Hardware- Impelementierung eine optimierte Mischung zulassen.

Weiterhin bevorzugt wird die HardwareImplementierung Mittel vorsehen um vor dem Multiplexer einfache logische Verknüpfungen (boolsche Funktionen) zu ermöglichen. Beispielsweise kann

vor jedem Multiplexer-Eingang eine 2 -fach Look-Up Tabelle implementiert sein, die die beliebige boolsche Verknüpfung zweier Eingangssignale, oder das direkte Weiterleiten nur eines der Signale ermöglicht.

Figur 6 zeigt eine weitere Variante einer erfindungsgemäßen BPU. Dargestellt ist ein 4x4 Ausschitt eines konfigurierbaren Logikfeldes (Field Programmable Gate Array, FPGA) . Jedes Gatter basiert auf einer 3-Input zu 3 -Output Lookup Tabelle (LUT, 0601) , die eine unabhängige Lookup-Funktion für jeden der drei Ausgänge je auf Basis aller 3 Eingänge berechnet. Im Gegensatz zu FPGAs nach dem Stand der Technik weisen die einzelnen Zellen keine Register Funktion auf, sondern einer Menge von Zellen (in diesem Beispiel einer 4x4 Matrix) sind Re- gister an den Kanten zugeordnet (in diesem Beispiel an der

Süd- und Ost-Kante) . Jedem Ausgang der Kanten LUTs (0602) ist ein Register (0603) konfigurierbar zugeordnet, das entweder zugeschaltet werden kann, um das Ausgangssignal registerverzögert weiterzuleiten, oder mittels einer Multiplexer- Funktion umgangen werden kann, was einer unverzögerten Weiterleitung des Ausgangssignals entspricht.

Die LUTs erhalten die Eingangssignale von einem übergeordneten Bussystem konfigurierbar über Multiplexer (0604) . Weiter- hin ist eine Rückkopplung der Registerwerte (f [0..2] [0..2]) auf die LUT-Eingänge ebenfalls konfigurierbar über die Multiplexer (0604) möglich.

Die gezeigte 4x4 Matrix ist frei kaskadierbar, wodurch große konfigurierbare Logikfelder aufgebaut werden können.

Ein wesentlicher Aspekt der erfindungsgemäßen BPU ist die verbesserte Vorhersage des Timings und der Schutz vor sogenannten undelayed-feedback-loops, die aufgrund einer asynchronen Rückkopplung zur physikalischen Zerstörung der Schal - tung führen können. Hierzu wird die folgende Regel implementiert: Daten werden nur in eine der Himmelsrichtungen Nord- Süd und eine der Himmelsrichtungen Ost-West durch das Logikfeld geleitet.

Im Beispiel nach Figur 6 ist die Hauptsignallaufrichtung in einer Spalte von Nord nach Süd, für überträge können Signale innerhalb einer Reihe von West nach Ost übertragen werden. Eine diagonale Signalübertragung ist in Nord-Süd Richtung e- benfal1s möglich .

Figur 7 zeigt ein Integrationsbeispiel der erfindungsgemäßen BPU nach Figur 6 in die VPU Architektur der Erinderin. Hierzu sind alle bestehenden Patentanmeldung der Erfinderin aus Offenbarungszwecken vollumfänglich eingegliedert. Die Schaltung weist ein Buseingangsinterface (0701) auf, das Daten und/oder Trigger von einem konfigurierbaren Bussystem erhält. Ein Busausgangsinterface (0702) schaltet die von dem einem Logikfeld (0703) generierten Signale auf Daten- und/oder Trigger-Busse. Das Logikfeld 0703 umfaßt eine Mehrzahl von BPUs nach Fig. 6, die gekachelt mehrdimensional angeordnet sind. Die Pfeile verdeutlichen die Laufrichtungen der Signale innerhalb des Logikarray, entsprechend der Beschreibung in Figur 6.

Den Businterfacen und dem Logikfeld ist eine frei program- mierbare Statemachine (0704) zugeordnet, die die Ablaufsteuerung der Bustransfers und/oder Generierung von Steuersignalen und/oder Synchronisierungsaufgaben übernimmt.

Wie unter anderem aus PACT02 und PACTO8 bekannt, weist die VPU Technologie Handshake Protokolle zur automatischen Synchronisation von Daten- und/oder Trigger-übertragungen auf. Beim Einsatz der erfindungsgemäßen BPU in der VPU Technologie, verwaltet die Statemachine (0704) zudem und insbesondere die Handshakes (RDY/ACK) der Busprotokolle des Eingangs- und/oder Ausgangs-Busses.

Die Signale vom Buseingangsinterface (0701) und/oder Busausgangsinterface (0702) werden zur Steuerung an die Statemachine geleitet, diese generiert Steuersignale zur Steuerung der Datenübertragungen für die entsprechenden Interface. Weiterhin erhält die Statemachine Signale von dem Logikfeld (0703) , um auf dessen interne Zustände reagieren zu können. Umgekehrt kann die Statemachine Steuer-Signale an das Logikfeld übermitteln.

Die Statemachine ist bevorzugt in einem weiten Bereich pro- grammierbar, um eine maximale Flexibilität für den Einsatz des Logikfeldes zu gewährleisten. Bevorzugt sind jedoch funktionskritisch Teile der Statemachine fest implementiert, wie z.B. die Handshake Protokolle der Busse. Damit ist sichergestellt, dass die Basisfunktionallität einer BPU auf System- ebene sichergestellt ist. Sämtliche Bustransfers laufen auf Systemebene per Definition durch den fest implementierten Teil der Statemachine korrekt ab. Dies erleichtert die Programmierung und das Debuggen auf Systemebene erheblich.

Diesem fest implementierten Teil der Statemachine (0704) ist der frei programmierbare Teil zugeordnet, in welchem der Pro-

grammierer jeweils applikationsabhängig die Steuerung des Logikfeldes implementieren kann.