Integration dynamisch rekonfigurierbarer Funktionseinheiten in Prozessoren

Transkript

1 Integration dynamisch rekonfigurierbarer Funktionseinheiten in Prozessoren Thilo Pionteck, Thomas Stiefmeier, Thorsten Staake, Lukusa D. Kabulepa, Manfred Glesner Technische Universität Darmstadt Lehrstuhl für Mikroelektronische Systeme Karlstr. 15, D Darmstadt Abstract: Dieser Beitrag befaßt sich mit der Integration dynamisch rekonfigurierbarer Architekturen als Funktionseinheiten in RISC Prozessoren mit Befehls-Pipeline. Dabei wird insbesondere auf die Organisation der Konfigurationsdaten sowie die Kontrolle des eigentlichen Rekonfigurationsprozesses eingegangen. Es wird eine Architektur vorgeschlagen, welche leicht in eine Vielzahl von Prozessorarchitekturen integriert werden kann, ohne Änderungen an der Pipelinesteuerung vornehmen zu müssen. 1 Einleitung Die Integration rekonfigurierbarer Architekturen in Prozessoren eröffnet völlig neue Anwendungsbereiche für den Einsatz rekonfigurierbarer Logik. Eigneten sich bisher primär nur datenflußorientierte Anwendungen für eine Abbildung auf rekonfigurierbarer Logik, so vereinfacht die enge Kopplung von rekonfigurierbarer Logik mit einem Prozessor auch die Realisierung von kontrollflußorientierten Anwendungen auf solchen Systemen. Dabei übernimmt der Prozessor den kontrollflußdominierten Anteil der Anwendung, während der rechenintensive Anteil auf der rekonfigurierbaren Architektur abgebildet werden kann. Es existieren eine Reihe von unterschiedlichen Ansätzen zur Kombination von rekonfigurierbarer Logik mit einem Prozessor, wobei ein Großteil dieser Entwürfe die lose Anbindung der rekonfigurierbaren Einheit an den Prozessor mit Hilfe eines Prozessor- oder I/O- Busses bevorzugt. In solch einem System übernimmt die rekonfigurierbare Einheit aber primär die Aufgabe eines Koprozessors, statt eine Einheit aus Prozessor und rekonfigurierbarer Logik zu bilden. Eine engere Ankopplung kann erreicht werden, indem der rekonfigurierbare Block als Funktionseinheit in den Datenpfad des Prozessors integriert wird. Ein häufig genannter Nachteil einer solchen Integration ist, daß auf diese Art integrierte Funktionseinheiten oft nur Operationen von einem oder wenigen Taktzyklen ausführen können [Hj00]. Dies ist zum einen dadurch bedingt, daß rekonfigurierbare Funktionseinheiten oft keine eigenen Zustandsregister beinhalten, zum anderen kann es bei Operationen über mehrere Taktzyklen zu Konflikten in der Pipelineabarbeitung kommen. Ein weiteres Problem ist die Rekonfiguration. Da nur kleinere Aufgaben von der rekonfigurierbaren Funktionseinheit ausgeführt werden können, ist eine häufige Rekonfiguration notwendig. 155

2 Dies kann zu relativ hohen Rekonfigurationskosten führen. Wie trotz dieser Probleme eine effiziente Integration einer rekonfigurierbaren Funktionseinheit in einen Prozessor erfolgen kann, wird im Laufe dieses Beitrags dargelegt. Die Gliederung des Beitrages ist folgende: Kapitel 2 befaßt sich mit den verschiedenen Ansätzen zur Integration rekonfigurierbarer Logik in Prozessoren. Kapitel 3 behandelt die Konfigurationssteuerung der in diesem Beitrag vorgestellten Architektur. Die Integration der rekonfigurierbaren Einheit in einen RISC-Prozessor wird im 4. Kapitel vorgestellt. Eine Bewertung der Architektur wird im Kapitel 5 vorgenommen. Zum Schluß erfolgt eine Zusammenfassung der Ergebnisse in Kapitel 6. 2 Ansätze zur Integration rekonfigurierbarer Logik in Prozessoren Für die Integration rekonfigurierbarer Hardware in Prozessoren gibt es drei unterschiedliche Ansätze. Die einfachste und flexibelste Methode ist die Anbindung einer rekonfigurierbaren Einheit über einen I/O Bus. Die Kopplung zwischen rekonfigurierbarer Einheit und Prozessor entspricht dabei der von Prozessoren in einem Multiprozessorsystem. Der größte Nachteil einer solchen Kopplung liegt in der langsamen Kommunikation zwischen Prozessor und rekonfigurierbarer Einheit, bedingt durch den I/O Bus. Ein solcher Systementwurf lohnt sich daher nur, wenn sehr rechenintensive Aufgaben auf die rekonfigurierbare Einheit ausgelagert werden können. Vorteile eines solchen Systems sind sein einfacher Entwurf, einfache Programmierung und ein hohes Maß an erreichbarer Parallelität [BLD02, CH02]. Beispiele für solche Architekturen sind unter anderem PipeRench [LTS9], Sonic [HCL00] und Splash2 [Aj93]. Eine engere Kopplung der rekonfigurierbaren Einheit mit dem Prozessor stellt die Anbindung als Koprozessor dar. Hier können Prozessor und rekonfigurierbare Einheit über einen schnellen Bus miteinander kommunizieren, so daß die Rekonfigurationskosten reduziert werden. Auch ist es der rekonfigurierbaren Einheit nun selbst möglich, auf den Datenspeicher zuzugreifen, was den Prozessor zusätzlich entlastet. Verglichen mit der Anbindung über einen I/O Bus eignet sich ein Koprozessor-System auf Grund der geringen Kommunikationskosten besser für die Bearbeitung feingranularer Befehlssequenzen. Exemplarisch für diese Form der Kopplung zwischen Prozessor und rekonfigurierbarer Einheit seien Garp [HW97], Napa-1000 [Rc98] und Remarc [MO98] genannt. Eine noch engere Kopplung kann durch die Integration der rekonfigurierbaren Einheit als Funktionseinheit in einen Prozessor erfolgen. Die rekonfigurierbare Funktionseinheit (RFU) wird dabei in den Datenpfad des Prozessors parallel zu den vorhandenen Funktionseinheiten eingefügt. Somit entstehen praktisch keine Kommunikationskosten zwischen Prozessor und RFU, da die RFU direkten Zugriff auf die Register des Prozessors besitzt. Probleme solch einer Architektur sind, wie bereits in der Einleitung erwähnt, die Beschränkung auf Operationen, welche nur einen oder wenige Taktzyklen benötigen sowie die Rekonfiguration und die Pipelineintegration. Beispiele solcher Architekturen sind P-RISC [RS94], OneChip98 [JC99] und Chimaera [Hc97]. 156

3 3 Konfigurationssteuerung In diesem Kapitel wird ein Lösungsansatz für die Probleme vorgestellt, welche im vorherigem Kapitel als Nachteil von RFUs genannt wurden, nämlich Rekonfiguration und die Beschränkung auf einen oder wenige Taktzyklen. Das Problem der Pipelineintegration wird anschließend im 4. Kapitel behandelt. Die Rekonfiguration kann insofern ein Problem darstellen, als daß sie durch den Prozessor gesteuert wird, der in dieser Zeit nicht seiner eigentlichen Aufgabe, der Programmabarbeitung, nachkommen kann. Es ist daher erstrebenswert, den Prozessor von der Rekonfigurationssteuerung zu entlasten. Die Rekonfigurationskosten können ebenfalls dadurch reduziert werden, daß mehrere Konfigurationen für die RFU in einem Konfigurationsspeicher vorgehalten werden. Mit Hilfe eines Befehles ist es dann möglich, die entsprechende Konfiguration auszuwählen und gleichzeitig die Daten an die RFU zu übertragen. Die Leistungsfähigkeit der RFU kann zusätzlich dadurch erhöht werden, daß ein automatisches Umschalten zwischen den einzelnen Konfigurationen im Konfigurationsspeicher ermöglicht wird, so daß autonom eine Sequenz von Konfigurationen abgearbeitet werden kann. extern Reconfiguration Memory Addr Data a b RFU out Addr prog. unit Configuration Tables Table 2 Table 3 Table 1 run unit Addr table select Table 4 Table 5 instruction word control signal from RFU Abbildung 1: Konfigurationssteuerung Eine Möglichkeit, solch ein System zu realisieren, ist in Abbildung 1 dargestellt. Die Konfigurationssteuerung teilt sich dabei in drei Bereiche auf: Konfigurationstabellen, Programmiereinheit und Ablaufsteuerung. Der Aufbau der RFU selbst ist unabhängig von der hier vorgeschlagenen Architektur und wird daher nicht weiter behandelt. Auch stellen die hier verwendeten Speichergrößen und Bitbreiten nur Beispielwerte dar. 157

4 Aufbauend auf der Beobachtung, daß je nach Anwendungung ein Teil der Konfigurationsbits mehrerer Konfigurationsvektoren gleich sind, wurde der Konfigurationsspeicher in mehrere Tabellen aufgeteilt. Wie der Abbildung 1 entnommen werden kann, besteht der Konfigurationsspeicher aus insgesamt fünf verschieden großen Tabellen, wobei die Tabellen 2/4 und 3/5 identisch sind. Mit Hilfe eines externen Steuersignals tab select kann zwischen diesen Tabellen umgeschaltet werden. Der Konfigurationsvektor setzt sich aus insgesamt drei Tabelleneinträgen entsprechend der folgenden Formel zusammen. con f ig vector = Tab1[i][2::0]&Tab Var[tab select][tab1[i][7::3]]&tab Const[tab select] Tab Const[tab select] bezeichnet wahlweise Tabelle 3 bzw. Tabelle 5. Diese Tabellen besitzen jeweils nur einen Eintrag und dienen zur Speicherung eines konstanten Bitvektors. Je nach Anwendung können diese Tabellen auch Informationen zur Kontrolle der Ablaufsteuerung enthalten. Tab Var[tab select][tab1[i][7..3]] selektiert einen Eintrag in der Tabelle 2 bzw. Tabelle 4, entsprechend der ersten acht Bit des von der Ablaufsteuerung ausgewählten Tabelleneintrages von Tabelle 1. Zusätzlich beinhaltet Tabelle 1 noch einige wenige Bits, die direkt dem Konfigurationsvektor hinzugefügt werden oder zur Kontrolle der Ablaufsteuerung verwendet werden. Die Tabelle 2 und Tabelle 4 dienen zur Speicherung der sich von einer zur nächsten Konfiguration ändernden Teile des Konfigurationsvektors. Das Laden der Tabellen wird durch die Programmiereinheit der Konfigurationssteuerung übernommen. Durch Vorgabe einer Speicheradresse im externen Konfigurationsspeicher, Angabe der Tabelle(n), Position und Länge der zu ladenden Konfiguration erfolgt das Laden unabhängig vom Prozessor. Somit ist nur ein Befehl zum Starten des Konfigurationsvorganges erforderlich, der Ladevorgang selbst erfolgt parallel zur normalen Programmabarbeitung. Auch ist ein Ladevorgang während des Betriebes der RFU möglich. Zu diesem Zweck ist die Tabelle mit dem variablem Anteil des Konfigurationsvektors sowie die Tabelle mit dem konstanten Konfigurationsvektor doppelt vorhanden (Tabellenpaare 2/3, 4/5). Während ein Tabellenpaar zur Konfiguration der RFU genutzt wird, kann das andere Tabellenpaar umgeladen werden. Somit ist eine echte dynamische Rekonfiguration der RFU möglich. Um auch komplexere Operationen auf der RFU realisieren zu können, ist es wichtig, Berechnungen über mehrere Taktzyklen hinweg durchführen zu können. Dabei soll nicht nur eine Konfiguration über mehrere Taktzyklen hinweg aktiv sein, sondern es soll auch ein dynamisches Umkonfigurieren zwischen den Taktzyklen möglich sein. Diese Aufgabe übernimmt die Ablaufsteuerung der Rekonfigurationssteuerung. Die wichtigste Eigenschaft der Ablaufsteuerung ist, daß sie ohne Kontrolle durch den Prozessor automatisch eine Sequenz von Konfigurationen an die RFU anlegen kann. Die einzelnen Betriebsarten der Ablaufsteuerung sind im Folgenden beschrieben. Das Ziel des Entwurfs war es, ausgehend vom Aufbau der Konfigurationstabellen mit möglichst einfacher Kontrolllogik eine flexible Konfigurationssteuerung zu entwickeln, die ggf. für andere Anwendungen angepasst werden kann. 158

5 3.1 Einfache Operation Diese Betriebsart wird bei Operationen verwendet, die nur einen Taktzyklus benötigen. Durch Auswahl eines Eintrages aus Tabelle 1 wird ein Konfigurationsvektor durch die anderen Tabellen zusammengesetzt und im gleichen Takt zur Konfiguration der RFU verwendet, die ebenfalls im gleichem Takt die Berechnung ausführt. In dieser Betriebsart entspricht die hier vorgestellte Konfigurationssteuerung der vieler anderer Architekturen. 3.2 Sequenz von Operationen Bei dieser Betriebsart kommt der Vorteil des Aufteilens des Konfigurationsspeichers in einzelne Tabellen zum Tragen. Ausgehend von einem durch den Prozessor vorgegebenen Eintrag wählt die Ablaufsteuerung nacheinander alle Einträge der Tabelle 1 aus. Dieser Vorgang wird erst durch einen zweiten Befehl des Prozessors gestoppt. Somit kann eine Sequenz von Konfigurationsvektoren an die RFU angelegt werden und dadurch auch komplexere Berechnungen über mehrere Taktzyklen hinweg von der RFU ausgeführt werden. Nun ist es auch bei komplexeren Operationen nicht immer notwendig, daß pro Takt eine neue Konfiguration erfolgen muß. Eine komplexe Operation kann in mehrere Operationen unterteilt sein, die jede für sich mehrere Taktzyklen benötigt. Würde nun für jeden Takt der gesamte Konfigurationsvektor gespeichert, so wäre der Speicheraufwand für dieses Verfahren sehr hoch. Bei der hier vorgestellten Konfigurationssteuerung wird dieses Problem umgangen, indem im Falle eines zeitweise konstanten Konfigurationsvektors die einzelnen Einträge in Tabelle 1 auf den gleichen Eintrag in Tabellen 2/4 zeigen. Somit ist es möglich, wesentlich längere Konfigurationssequenzen zu erzeugen als Einträge in den Tabellen 2/4 vorhanden sind. 3.3 Schleifen Für komplexere Berechnungen kann es auch notwendig sein, sich wiederholende Konfigurationsequenzen in Schleifen zu realisieren. Wird dieser Mechanismus benötigt, werden die zur Adressierung von Tabelle 2/4 überzähligen Bits der Einträge von Tabelle 1 nicht zum Konfigurationsvektor hinzugefügt, sondern zur Kontrolle der Ablaufsteuerung verwendet. Somit können in der Tabelle 1 auch Schleifen kodiert werden. Die Anzahl der Schleifendurchläufe und die Sprungsadresse ist in der Tabelle 3/5 festgelegt. Je nach Größe der Tabelle 3/5 und Anzahl der zur Verfügung stehenden Bits in Tabelle 1 können mehrere Schleifen in einer Sequenz von Konfigurationen realisiert werden. 159

6 3.4 Sprünge Entsprechend dem Mechanismus zur Realisierung von Schleifen können auch bedingte und unbedingte Sprünge innerhalb von Tabelle 1 realisiert werden. Im Falle von bedingten Sprüngen müssen entsprechende Kontrollsignale von der RFU zur Ablaufsteuerung transferiert werden. Bedingte Sprünge stellen somit den einzigen Fall dar, bei dem die RFU an die hier vorgestellte Konfigurationssteuerung angepasst werden muß. 4 Prozessorintegration Die Integration der im vorangegangenen Kapitel vorgestellten Konfigurationssteuerung in die Pipelinestruktur eines Prozessors wird im Folgendem exemplarisch anhand eines RISC-Prozessors mit fünf Pipelinestufen vorgestellt. Zu diesem Zweck wird die JAM CPU [LTN02] verwendet, ein 32-Bit RISC-Prozessor, welcher der DLX-Architektur von Hennessy und Patterson [HP96] entspricht. start address dest src 1 src 2 t table (a) Operation über einen Takt src 1 src 2 # instructions t start address table (b) Operation über mehrere Takte RU table # words to start addr start address ROM sel. select load table (c) Laden der Konfigurationstabellen Abbildung 2: Befehlsformate Der Befehlssatz des Prozessors wurde um insgesamt drei Befehle erweitert; einen zum Laden der Konfigurationstabellen und zwei zur Ausführung von Operationen in der RFU. Der Aufbau der drei neuen Befehle ist in Abbildung 2 dargestellt. Die beiden Befehle zum Betrieb der RFU unterscheiden sich in der Länge der auszuführenden Operation. Abbildung 2(a) zeigt den Befehl zur Ausführung einer Operation von der Dauer eines 160

7 Taktes, während Abbildung 2(b) den Befehl zur Starten einer Sequenz von Operationen darstellt. Während die Realisierung von einfachen Operationen (ein Taktzyklus) mit Hilfe der RFU bezüglich einer Pipelineintegration kein Problem darstellt, kann es bei der Realisierung einer Sequenz von Operationen zu Pipelinekonflikten kommen. Bild 3 zeigt solch einen Fall. In diesem Beispiel führt die RFU eine Berechnung über vier Tayktzyken durch. Nach Beendigung der vierten EX-Phase kann es bei den darauf folgenden MEM- und WB-Phasen zu Ressourcenkonflikten mit den korrespondierenden Phasen der kommen. Bei der hier vorgestellten Implementierung wird dieses Problem umgangen, indem der Befehl zur Ausführung von Operationen über mehrere Taktzyklen keine MEM- und WB-Phase enthält, daher ist auch keine Zieladresse im Befehlsformat von Abbildung 2(b) enthalten. Das Ergebnis einer Berechnung über mehrere Takte muß von einem Befehl zur Ausführung einer einfachen Operation gelesen werden. Dadurch wird auch gleichzeitig die Abarbeitung einer Sequenz von Konfigurationen unterbrochen. Abbildung 4 verdeutlicht diese Vorgehensweise. RFU IF ID EX EX EX EX MEM WB Abbildung 3: Pipelinekonflikte RFU RFU IF ID EX EX EX EX EX Abbildung 4: Vermeidung von Ressourcekonflikten Die Integration einer RFU mit der beschriebenen Konfigurationssteuerung in den Datenpfad der JAM-CPU ist in Abbildung 5 dargestellt. Alle Änderungen gegenüber dem normalen Datenpfad sind im Bild hervorgehoben. In diesem Beispiel wurde der externe Konfigurationsspeicher in den Befehlsspeicher des Prozessors integriert, so daß dieser Speicher zwei gleichzeitige Lesezugriffe unterstützen muß. Die RFU befindet sich in der gleichen Pipelinestufe wie die und verfügt auch über die gleichen Anbindungen an 161

8 die Registerbänke. Lediglich eine Rückkopplung des Ausgangs der RFU auf ihren Eingang ist nicht vorgesehen, da dies durch die Unterstützung von Operationen über mehrere Taktzyklen innerhalb der RFU erfolgen sollte. IF ID EX MEM WB Instruction Decode CTRL CTRL CTRL IM / CM extern PC 4 IWord PC RCU Run Control RCU Config. Control IX REGISTERS Config. Tables reg a reg b imm PC dest RFU FUs PSW OUT IN res reg PC dest DM extern 31 mem reg dest 0 Abbildung 5: Integration der Konfigurationssteuerung und RFU im RISC Prozessor 5 Ergebnisse Die hier vorgestellte Konfigurationssteuerung wurde zusammen mit einer RFU zur Unterstützung von rechenintensiven Aufgaben (Verschlüsselung, Fehlerkorrektur) innerhalb des MAC (Medium Access Control)-Layers von OFDM-basierten WLANs realisiert [Tp04]. Als Prozessormodell wurde die bereits erwähnte JAM-CPU verwendet. Die Syntheseergebnisse zeigen, daß nur ungefähr 6.5% der Gesamtfläche für die Konfigurationssteuerung benötigt werden. Von diesen 6.5% der Gesamtfläche entfallen 33% auf die Kontrolllogik (Ablaufsteuerung und Programmiereinheit) und 67% auf die Konfigurationstabellen. Die Realisierung des Speichers erfolgte dabei unter Verwendung von RAM-Makroblöcken. Die Zahlen verdeutlichen, daß der Rekonfigurationsaufwand auf ein akzeptables Maß reduziert werden konnte. Die Architektur unterstützt auch eine gute Ausnutzung der Parallelität zwischen RFU und anderen Funktionseinheiten des Prozessors. Obwohl bei der Ausführung eines Befehls über mehrere Taktzyklen sowohl die zu verarbeitenden Daten als auch das Ergebnis der Berechnung mit Hilfe von zusätzlichen Befehlen zu bzw. von der 162

9 RFU transportiert werden müssen, ist in den meisten Fällen eine Auslastung der RFU und der anderen Funktionseinheiten des Prozessors von über 90% gegeben. Da das Laden der Konfigurationstabellen zu 90% parallel zum Betrieb der RFU und der anderen Funktionseinheiten erfolgen kann, reduziert eine dynamische Änderung der Konfigurationstabellen die Auslastung der einzelnen Funktionsblöcke in nur geringem Maße. 6 Zusammenfassung In diesem Beitrag wurde eine Konfigurationssteuerung für rekonfigurierbare Funktionseinheiten in Prozessoren vorgestellt. Das hier vorgeschlagene Verfahren ermöglicht eine problemlose Integration von rekonfigurierbaren Funktionseinheiten auch in Prozessoren mit Befehls-Pipeline, ohne daß dabei die Pipelinesteuerung verändert werden muß. Durch ein geschicktes Aufteilen der Konfigurationsdaten wurde der dafür benötigte Speicherplatz minimiert. Mit Hilfe einer einfachen Ablaufsteuerung ist es möglich, nahezu beliebig lange Sequenzen von Konfigurationen abzuarbeiten, so daß eine rekonfigurierbare Funktionseinheit auch komplexere Berechnungen über mehrere Taktzyklen hinweg durchführen kann. Literatur [Hj00] [CH02] [BLD02] [LTS9] [HCL00] [Aj93] [HW97] Hauser, John R.: Augmenting a Microprocessor with Reconfigurable Hardware, Ph.D. Thesis, University of California, Berkeley, 2000 Compton, Katherine; Hauck, Scott: Reconfigurable Computing: A Survey of Systems and Software, ACM Computing Surveys, vol. 34, no. 2, June 2002 Barat, Francisco.; Lauwereins, Rudy; Deconinck, Geert: Reconfigurable Instruction Set Processors from a Hardware/Software Perspective, IEEE Transaction on Software Engineering, vol. 28, issue 9, September 2002 Laufer, Ronald; Taylor, R. Reed; Schmit, Herman: PCI-PipeRench and SwordAPI: A system for Stream-based Reconfigurable Computing, Proceeding of the IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM 99), April 1999 Haynes, Simon D.; Cheung, Peter Y.K.; Luk, Wayne: Video Image Processing with the Sonic Architecture, Computer: Innovative Technology for Computer Professionals, vol. 33, no.4, IEEE Computer Society, April 2000 Arnold, Jeffrey M.; Buell, Duncan A.; Hoang, Dzung T.; Pryor, Daniel V.; Shirazi, Nabeel; Thistle, Mark R.: The Splash 2 Processor and Applications, Proceeding of the IE- EE International Conference on VLSI in Computers and Processors (ICCD 93), Oktober 1993 Hauser, John R.; Wawrzynek, John; GARP: A MIPS Processor with a Reconfigurable Coprocessor, Proceedings of the IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM 97), April

10 [Rc98] [MO98] Rupp, Charle R.; Landguth Mark; Garverick, Tim; Gomersall, Edson; Holt, Harry; Arnold, Jeffrey M; Gokhale, Maya: The NAPA Adaptive Processsing Architectures, IEEE Symposium on Field Programmable Custom Computing Machines, 1998 Miyamori, Takashi; Olukotun, Kunle: A Quantitative Analysis of Reconfigurable Coprocessors for Multimedia Applications, Proceedings of the IEEE Symposium on Field- Programmable Custom Computing Machines (FCCM 98), April 1998 [RS94] Razdan, Rahule; Smith, Michael D.: A High-Performance Microarchitecture with Hardware-Programmable Functional Units, Proceedings of the 27th Annual International Symposium on Microarchitecture, November 1994 [JC99] Jacob, Jeffrey A.;Chow, Paul: Memory Interfacing and Instruction Specification for Reconfigurable Processors, Proceedings of the ACM/SIGDA International Symposium on Field Programmable Gate Arrays (FPGA 99), 1999 [Hc97] Hauck, Scott; Fry, Thomas W.; Hosler, Matthew M.; Kao, Jeffrey P.: The Chimaera Reconfigurable Function Unit, Proceedings of the IEEE Symposium on Field- Programmable Custom Computing Machines (FCCM 97), April 1997 [LTN02] [HP96] [Tp04] Lindström, Anders; Thelin, John E.; Nordseth, Michael: JAM CPU Core - A RISC CPU core written in VHDL, e8mn/web/jam/index.html, 2002 Hennessy, John L.; Patterson, David A.: Computer Architecture: A Quantitative Approach, Morgan Kaufmann Publishers, 1996 Pionteck, Thilo; Staake, Thorsten; Stiefmeier, Thomas, Kabulepa, Lukusa D.; Glesner, Manfred: Design of a Reconfigurable AES Encryption/Decryption Engine for Mobile Terminals, accepted for publication at IEEE International Symposium on Circuits and Systems (ISCAS 2004), Mai