Scientists unveil chip which could make desktop computers 20 times faster

[Iruwen]

Scientists have created an ultra-fast computer chip which is 20 times faster than current desktop computers.
Modern PCs have a processor with two, four or sometimes 16 cores to carry out tasks.
But the central processing unit (CPU) developed by the researchers effectively had 1,000 cores on a single chip.
[...]
And the new 'super' computer is much greener than modern machines - using far less power - despite its high speed.
[...]
Scientists used a chip called a Field Programmable Gate Array (FPGA)
[...]
The team was led by Dr Wim Vanderbauwhede, of the University of Glasgow, and colleagues at the University of Massachusetts Lowell.
He said: 'FPGAs are not used within standard computers because they are fairly difficult to program but their processing power is huge while their energy consumption is very small because they are so much quicker - so they are also a greener option.'

Kompletter Artikel (http://www.dailymail.co.uk/sciencetech/article-1342100/Scientists-unveil-1-000-core-chip-make-desktop-machines-20-times-faster.html)

[Aquaschaf]

Nichts neues, und die Schlagzeile ist Blödsinn. Ein many-core-Prozessor würde Desktop-Computer eher in der Mehrzahl der Fälle langsamer machen, als schneller.

[Botcruscher]

Superrechner nein, da schon Manycore. Heimrechner niemals da das meiste nicht so weit parallelisierbar ist. Gleichzeitig wurde der Punkt zur Verfügung stehende und abgerufene Rechenleistung spätestens mit dem Aufkommen von Dualcores überschritten. Abgesehen von Spielen bleibt für Normalo nicht viel was limitieren kann.

[tomvos]

Es gibt durchaus viele Anwendungen, die sich durch FPGA gut beschleunigen lassen.

Z.B. hängt an meiner Octane2 eine Video Breakout Box (vbob) - auf der Adapterkarte sind alleine 7 Chips von Xilinx, in der vbob selbst dann nochmals viele Chips von Xilinx. Dadurch konnte dieser Rechner bereits im Jahr 2000 HD-Videomaterial unkomprimiert in Echtzeit einlesen und auch wieder rausschreiben. Obwohl die Haupt-CPU mit 400 MHz sicherlich weit jenseits von HD ready einzustufen ist.
Ein weiteres Feature an dieser Box ist, dass die Firmware auf den vbob an diverse Video Formate angepasst werden kann. Somit übernehmen die Xilinx Chips die Rolle von verschiedenen DSP Prozessoren, ohne für jedes Format einen eigenen DSP zu verbauen.


Aber: Es benötigt schon genau definierte Szenarien, damit ein FPGA sinnvoll eingesetzt werden kann. Zu spezifisch darf es dann aber wiederum auch nicht sein, denn dann ist ein dedizierter DSP schneller, günstiger und energiesparender.

Das zu lösende Problem ist also viel eher, Arbeitsschritte zu finden, bei denen die Rechenleistung für den Durchschnittsanwender nicht ausreichend ist. Auf dieser Suche sind auch NVidia, AMD und Intel mit ihrer GPU und Multicore Hardware.

[an.zgep]

gegen einen ASIC (= jeder in einem normalen PC/Smartphone/whatever vorhandene Chip) der das gleiche macht verliert ein FPGA immer - der ASIC ist weit billiger in der Massenproduktion, stromsparender, schneller taktbar, kleiner.

Dafür kann der ASIC allerdings dann auch nur ein bestimmtes Set an Aufgaben abarbeiten. Ein FPGA ist rekonfigurierbar, mit verschiedenen HDLs (Hardware Description Language) wie z.B. Verilog oder VHDL kann der Chip mehr oder minder frei umgebaut werden, aus einem Addierwerk aus Kombinatorikeinheiten lässt sich ein Multiplexer machen usw.

"Programmieren" ist das aber eigentlich nicht, man erstellt ja kein Programm sondern eine Schaltung mit Registern, Latches, logischen Verknüpfungen usw.
Man braucht dann erst recht wieder ein Programm, dass dann auf dieser Schaltung ausgeführt werden kann.

Als Ersatz für CPUs sind FPGAs völlig uninteressant, da der Zusatzaufwand bei der Entwicklung einer HDL-Beschreibung zusätzlich zu einem darauf optimierten Programms wohl in der Größenordnung 100x bis 1000x liegen dürfte (an meinem SPARC-Softcore bin ich ein Semester lang >10h/Woche gesessen, und das ist wirklich keine komplizierte Architektur, geschweige denn optimiert auf irgendwas...)

FPGAs sind da interessant, wo nur geringe Stückzahlen gefertigt werden (10k-100k), da man dann von der Stange irgendwelche Xilinx oder Altera Chips kaufen kann und die dann entsprechend konfiguriert -> billiger als ne ganze Fertigungsstraße hochzuziehen wie bei einem ASIC.

Die Artikelüberschrift ist demnach kompletter Murks.

[Coda]

Ich glaube es geht gar nicht um "echte" Cores, sondern darum Programmen zu Erlauben für ihre eigenen Algorithmen den eingebetteten FPGA zu programmieren.

Das ist nichts neues, scheitert aber meiner Meinung nach an der extrem hohen Komplexität. Das wäre vielleicht aber was für Konsolen. Bei Sony würde mich es zumindest nicht wundern ;)

[=Floi=]

ist da der weg über eine GPGPU nicht einfacher und eleganter?! hier hat man einen variablen treiber und schnelle hardware.

[Baalzamon]

ist da der weg über eine GPGPU nicht einfacher und eleganter?! hier hat man einen variablen treiber und schnelle hardware.
Nein, FPGAs funktionieren anders.

[Coda]

GPGPU ist etwas völlig anderes. Da hat man keine programmierbare Hardware.

[Trap]

Ich mag den Begriff "programmierbare Hardware" nicht, "Hardware" ist eine sehr ungenaue Übersetzung von "gate array" und stiftet dadurch nur Verwirrung bei Leuten, die sich damit nicht auskennen. "Programmierbare Gattermatrix" wäre meiner Meinung nach eine bessere Bezeichnung.

Grundsätzlich ist ein FPGA als allgemeiner Anwendungsbeschleuniger technisch schon interessant, die Vorteile/Nachteile ergänzen sich gut mit CPU+GPGPU. Der Unterschied im Entwicklungsaufwand für die Anwendungsentwickler ist aber viel zu groß und wird es auch in absehbarer Zeit noch bleiben. Für in 10-15 Jahren kann man es im Auge behalten, die Forschung an C-zu-Hardware Compilern und verwandten Ideen könnte bis dahin zumindest für mutige Leute weit genug sein.

[Coda]

Leute die sich nicht damit auskennen können sowieso nichts damit anfangen. Egal wie man es nennt.

Der Unterschied zwischen fixer Hardware die sich programmieren lässt und reprogrammierbarer Hardware ist einem Laien fast nicht nahezubringen.

[Trap]

Leute die sich nicht damit auskennen können sowieso nichts damit anfangen. Egal wie man es nennt.
Es gibt sehr viele Leute, die wissen, was der Unterschied zwischen Hardware ohne Programmierung wie z.B. Addierern und Hardware mit Programmierung wie CPUs oder GPUs ist. Die können mit dem Begriff "programmierbare Hardware" etwas anfangen, aber nicht in dem Sinn wie es hier gemeint ist.

Das vermeidet man mit einem Begriff, der nicht so verwechselt werden kann.

[Wuge]

Mir hats gerade eröffnet, dass es programmierbare Hardware in der Form überhaupt gibt. nun folgt Recherche in die Richtung :) Also so unnütz war der Kommentar garnicht...

[Simon Moon]

Leute die sich nicht damit auskennen können sowieso nichts damit anfangen. Egal wie man es nennt.


Aber sie lesen gerne mit, wie ich z.b. :)

Ich freu mich daher auch, wenn sich Leute Mühe geben, die Begriffe für Laien wie mich plastischer darzustellen.

[GloomY]

Ich mag den Begriff "programmierbare Hardware" nicht, "Hardware" ist eine sehr ungenaue Übersetzung von "gate array" und stiftet dadurch nur Verwirrung bei Leuten, die sich damit nicht auskennen. "Programmierbare Gattermatrix" wäre meiner Meinung nach eine bessere Bezeichnung.Bei einem FPGA ist es aber nicht nur die Verbindungs-Matrix, die man programmieren kann. Wenn es nur das wäre, hätte man einen PLA oder einen PAL. Die haben programmierbare Matrizen und feste ODER- bzw. UND-Gatter, die durch die Programmierung der Matrix miteinander verbunden werden. Bei einem FPGA kann man aber hingegen auch die Logikfunktion (die LUT) und nicht nur die Verbindung programmieren.


Noch mal was anderes: Viele Leute denken beim Wort FPGA vor allem an statische Rekonfiguration, d.h. die Rekonfiguration findet vor dem Starten des Tasks oder des Systems statt und ändert sich während der Ausführung nicht mehr bis der Task zu Ende ist. Was man mit einem FPGA vor allem auch machen kann und was mit den bereits erwähnten GPGPU eben nicht geht ist sich dynamisch zu rekonfigurieren, d.h. während der Laufzeit. Insbesondere partielle dynamische Rekonfiguration ist - wie ich finde - ein sehr interessantes (Forschungs-)Gebiet. Das System passt sich dabei automatisch ohne Eingreifen des Benutzers an die momentanen Gegebenheiten an. Natürlich nicht vollständig sondern nur zu einem gewissen Grad. So, wie es eben beim Systemdesign vorgesehen ist.

Ich glaube, dass partielle dynamische Rekonfiguration vor Allem in Zukunft eine Rolle spielen wird. Datenverarbeitung in Situationen, die sich im Voraus durch z.B. Profiling gut ermitteln lassen und dann nicht mehr ändern, kann man sehr gut parallel auf nicht-rekonfigurierbarer Hardware wie z.B. auf GPUs oder ASICs ausführen. Aber für Situationen, in denen die benötigte Schaltung variiert (z.B. weil sie hochgradig von den Eingabedaten zur Laufzeit abhängen), kann man sowas nicht gebrauchen oder man muss eben in den sauren Apfel beißen und alle Schaltungen auf dem Chip implementieren, was die Die-Größe und damit die Kosten enorm ansteigen lässt. Mit dynamischer Rekonfiguration kann man die Implementierung zur Laufzeit zur Verfügung stellen, die gerade benötigt wird.


edit: Zum Artikel: Witzig, dass sie das jetzt bringen. :|
FPGAs gibt's AFAIK seit 1986. Damit ist der Zeitungsartikel 25 Jahre oder ein Viertel-Jahrhundert zu spät.

[Coda]

Ja, das habe ich mir auch schon überlegt. Der FPGA-State müsste dann halt wie die Register vom Betriebssystem gespeichert und geladen werden bei einem Task-Switch.

Das würde alles funktionieren. Aber wie gesagt fände ich sowas nur für Konsolen interessant, weil sonst der Programmier- und Debugaufwand einfach enorm wäre. Die Schnittstelle wie die zusätzlichen Instructions eingebunden werden ist auch so eine Sache. Da bräuchte man dann mehrere Read/Write Ports zum FPGA usw. sollte damit Instructions definieren können per Microcode.

Was ich auch für ein riesiges Problem halte ist in dem FPGA-Teil eine Pipeline mit einzubauen. Gut. Könnte man auch bei der Microcode-Definition mitgeben (Latenz und Durchsatz) und dann einen dynamischen Scheduler bauen :ugly:. Wäre wohl eher was für In-Order. Außerdem muss gewährleistet sein, dass die Timings immer eingehalten werden. Race-Conditions ahoi. Debug-Hell.

Mich trotzdem wundert warum das noch nie kommerziell gemacht wurde. Oder irre ich mich da?

FPGAs gibt's AFAIK seit 1986. Damit ist der Zeitungsartikel 25 Jahre oder ein Viertel-Jahrhundert zu spät.
Ich denke es geht um die Integration. Wie gesagt ist mir da nichts bekannt.

[GloomY]

Ja, das habe ich mir auch schon überlegt. Der FPGA-State müsste dann halt wie die Register vom Betriebssystem gespeichert und geladen werden bei einem Task-Switch.

Das würde alles funktionieren.Ohhh, den FPGA-State zu speichern ist für einen Task-Switch viel zu viel. Nur mal als Größenordnung: Der Bitstream auf einem (der größten) Virtex4-FPGAs ist etwas mehr als 4 MB. Das willst du bei einem Task-Switch garantiert nicht mitsichern. ;)

Aber wie gesagt fände ich sowas nur für Konsolen interessant, weil sonst der Programmier- und Debugaufwand einfach enorm wäre. Die Schnittstelle wie die zusätzlichen Instructions eingebunden werden ist auch so eine Sache. Da bräuchte man dann mehrere Read/Write Ports zum FPGA usw. sollte damit Instructions definieren können per Microcode.Sowas ähnliches gibt es schon (http://ces.itec.kit.edu/RISPP/). Dabei wird der CPU-Befehlssatz erweitert und zur Laufzeit dann eine Implementierung eines Befehls auf dem FPGA hinzukonfigurieren. Die ist dann meistens ziemlich parallel in den Datenpfaden und somit ziemlich fix. Führt der Prozessor einen neuen Befehl aus, bei dem zum Zeitpunkt der Ausführung keine Hardware-Implementierung auf dem FPGA verfügbar ist, emuliert man ihn mit dem Basis-Befehlssatz. Dazu gibt es mehrere Möglichkeiten:

Beim Dekodieren wird geprüft ob es eine Hardware-Implementierung gibt und wenn nicht, wird der Befehl zu einem einfachen Sprungbefehl dekodiert, der den Kontrollfluss des Prozessors zu einer Software-Emulationsroutine lenkt.
Der Prozessor erzeugt einen "unimplemented-Instruction"-Trap und das Betriebssystem springt daraufhin zum Software-Emulierungscode. Das ist besonders auf Befehlssätzen geeignet, die solch einen Trap schon mitbringen (z.B. SPARC v8). Und man muss die Decode-Stage des Prozessors nicht ändern. :)

Ob ein Befehl dann nun in Hardware oder Software ausgeführt wird, ist weitgehend transparent für eine Applikation. Der Vorteil davon ist, dass man Instruktionen mit fester Semantik hat und man den Zustand des FPGAs beim Task-Wechsel nicht mitsichern muss (naja, nicht ganz: in unserem System gibt es dennoch ein paar Sachen, die da zusätzlich mitgesichert werden).



Mich wundert warum das noch nie kommerziell gemacht wurde. Oder irre ich mich da?Kommerziell meines wissens nicht, aber es gibt eine Menge Forschung dazu.

[Coda]

Ohhh, den FPGA-State zu speichern ist für einen Task-Switch viel zu viel. Nur mal als Größenordnung: Der Bitstream auf einem (der größten) Virtex4-FPGAs ist etwas mehr als 4 MB. Das willst du bei einem Task-Switch garantiert nicht mitsichern. ;)
Das ist natürlich ein Problem. Für Konsolen wäre es trotzdem interessant, weil es da nur eine App gibt die viel Leistung braucht :)

[GloomY]

Ich denke es geht um die Integration. Wie gesagt ist mir da nichts bekannt.Integration? Wovon? von CPU und FPGA?

In der Forschung gab's das bereits 1989 mit der SPLASH-Architektur (http://portal.acm.org/citation.cfm?id=103302). Da hat man einen FPGA mit einer Workstation über einen Bus verbunden (d.h. lose gekoppelt). Und dass man Befehlssatzerweiterungen für CPUs auf FPGAs implementiert (enge Kopplung) ist spätestens mit DISC (http://portal.acm.org/citation.cfm?id=875382) (Dynamic Instruction Set Computer) 1995 erfolgt, vielleicht aber auch früher (weiss ich jetzt gerade nicht ob die die ersten waren).

Und Intel forscht da auch gerade mächtig dran rum:
http://www.heise.de/ct/meldung/Atom-Prozessor-mit-Altera-FPGA-1140503.html
und
http://www.heise.de/ct/meldung/Intel-betaetigt-sich-als-Auftragsfertiger-Update-1128296.html


P.S.: Ja, ich kenne mich da ein wenig aus. Das Schreiben der "Related-Work"- Sektion meiner DA liegt nur ein paar Wochen hinter mir ;)

[Trap]

In Darmstadt wird da auch schon länger dran geforscht:
http://www.esa.informatik.tu-darmstadt.de/twiki/bin/view/Research/WebHomeDe.html#Adaptive_Rechensysteme_und_ihre

Dynamische Rekonfiguration ist für das grundlegende Problem "wie nutzt man einen FPGA zur Beschleunigung bestehender Software?" nicht so wichtig, es erweitert nur den Bereich den man umsetzen könnte, wenn man es überhaupt könnte.
Oder alternativ kann man damit bessere FPGAs bauen: http://www.tabula.com/technology/technology.php

[Coda]

Das Schreiben der "Related-Work"- Sektion meiner DA liegt nur ein paar Wochen hinter mir ;)
Okay, alles klar :D

[GloomY]

In Darmstadt wird da auch schon länger dran geforscht:
http://www.esa.informatik.tu-darmstadt.de/twiki/bin/view/Research/WebHomeDe.html#Adaptive_Rechensysteme_und_ihreEs ist definitiv ein interessanter Ansatz Teile des Codes automatisch beim Übersetzen in HW auszuführen. Das kann man dann aber leider nur in der Hochsprache nutzen und nicht in Assembler.

Eine andere Frage ist hierbei, wie gut die HW/SW-Partitionierung funktioniert und wie gut man das Identifizieren von "lohnenswerten" Blöcken vorhersagen kann. Hat man das gemacht, ist die Partitionierung fix und man kann sie nie wieder ändern. Zumindest bei diesem Ansatz:
Welche Teile eines Programms als Hardware oder Software ausgeführt werden, entscheidet der Compiler aufgrund verschiedener Programminformationen. [...] Deswegen eignen sich vor allem häufig benutzte Schleifen für eine Hardware-Implementierung. Um diese herauszufinden, wird ein dynamisches Profiling eingesetzt. Die Ausführungsfrequenz wird hierbei durch einfaches Ausführen des Programms und Zählen des Ausführens von einzelnen Anweisungen ermittelt.Ich glaube das ist definitiv eine Beschränkung dieses Ansatzes. Laufzeit-Aspekte werden nicht berücksichtigt.

Nur zum Vergleich: Bei RISPP werden die Teile, die möglicherweise in HW ausgeführt werden können, auch im Vorraus identifiziert (als zusätzliche Spezialbefehle), aber ob sie tatsächlich in HW ausgeführt werden, wird erst zur Laufzeit entschieden. Und diese Entscheidung kann auch wieder revidiert werden, wenn das Laufzeitsystem es für sinnvoller hält, die FPGA-Fläche für andere Berechnungen herzunehmen. Um das beurteilen zu können, hat das Laufzeitsystem zwei Größen zur Verfügung: Man baut Programmvorhersagen über die Nutzung und Häufigkeit vom Spezialbefehlen in das Programm ein. Und zum anderen zählt man jede tatsächliche Ausführung zur Laufzeit und passt damit dann wieder die Vorhersage an, wenn sie zu stark daneben lag. Und wie stark diese Anpassung der Vorhersagehäufigkeit geschieht, ist wiederum per Parameter zur Laufzeit anpassbar (wird aber meist auf einem konstanten Wert gelassen).

So kann man sich den tatsächlichen Begebenheiten zur Laufzeit seht gut anzupassen.

Dynamische Rekonfiguration ist für das grundlegende Problem "wie nutzt man einen FPGA zur Beschleunigung bestehender Software?" nicht so wichtig, es erweitert nur den Bereich den man umsetzen könnte, wenn man es überhaupt könnte.Was willst du damit sagen? Es geht doch bereits jetzt.

Oder alternativ kann man damit bessere FPGAs bauen: http://www.tabula.com/technology/technology.phpWow. Ich dachte erst, das sei Blödsinn, aber es hat vielleicht wirklich eine Existenzberechtigung. Es hat wohl viel damit zu tun, dass man die Daten an seinem Platz lässt und nicht quer über den Chip routen muss. Man spart sich das Routing-Delay, welches ja schon in CPUs deutliche Anstrengungen bedarf, um es in Grenzen zu halten.

[Trap]

Es ist definitiv ein interessanter Ansatz Teile des Codes automatisch beim Übersetzen in HW auszuführen. Das kann man dann aber leider nur in der Hochsprache nutzen und nicht in Assembler.
Meinst du, dass das eine echte Einschränkung ist? Man kann ziemlich problemlos Assembler in völlig unlesbaren C-Code wandeln, der das gleiche macht.
Was willst du damit sagen? Es geht doch bereits jetzt.
Nicht in einer Art, die für den Softwareentwickler ähnlich komfortabel wie OpenMP oder OpenCL ist. Herstellerübergreifend und mit Infrastruktur zum Aufteilen der FPGA Ressourcen auf verschiedene laufende Programme.

[Coda]

OpenCL würde ich nicht gerade als komfortabel bezeichnen. Das aber generell für GPGPU.

FPGA ist natürlich nochmal ne schlimmere Angelegenheit ;)

[GloomY]

Meinst du, dass das eine echte Einschränkung ist? Man kann ziemlich problemlos Assembler in völlig unlesbaren C-Code wandeln, der das gleiche macht.Hmm, na gut.

Auf den zweiten Blick sieht es sogar halbwegs sinnvoll aus, das Extrahieren der FPGA-Funktionen aus den Datenpfaden in den C-Übersetzungslauf zu integrieren. Die Datenflussgraphen, die der C-Compiler für diverse interne Operationen benötigt, werden ja schließlich auch für die High-Level Synthese der FPGA-Routinen benötigt. Insgesamt sind diese Operationen ja ziemlich ähnlich. Der C-Compiler nutzt diese für Register-Allokation (Register im Sinn von Befehlssatz-Registern) und Instruktions-Scheduling und das Synthese-Tool für Register-Allokation (Flip-Flops) und Funktions-Einheit-Scheduling.

Nicht in einer Art, die für den Softwareentwickler ähnlich komfortabel wie OpenMP oder OpenCL ist. Herstellerübergreifend und mit Infrastruktur zum Aufteilen der FPGA Ressourcen auf verschiedene laufende Programme.Das stimmt. Der Entwicklungsaufwand ist mit FPGAs immer noch enorm. Das hat teilweise aber auch damit zu tun, dass es keine Standards gibt. Jeder Hersteller macht es so, wie er will, man benötigt die entsprechenden Tools von ihm und es gibt keine einheitlichen Schnittstellen.

Ich könnte mir durchaus vorstellen, dass man in einigen Jahren auch FPGA-Bitströme in ein Programm-Binary miteinbaut, um einige Funktionen von der CPU auf einen FPGA auszulagern. Dafür müsste es aber einheitliche Standards für die FPGA-Architektur, aber auch die HW-SW Interaktion geben. Von beidem sind wir noch weit entfernt.

[Charakterlos]

Intel will ja den "Stellarton" rausbringen, einen Atom + (Altera)FPGA

Jetzt kann man auf dem FPGA z.b. SHA/AES Krypto co-processoren integrieren. Ist eine super sache! Wenn man Daten verschlüsseln will.
Oder erweiterte Video-Codec processoren die das Umwandeln schneller ermöglicht, oder einen speziellen Datenbankprozessor der meinetwegen Microsofts SQL Datenbank beschleunigt, oder 7-zip die algorythmen zum ent-/packen von daten unterstützen...

software demanded programmed hardware processors on the fly...

Solange der FPGA im speziellen, dafür generierten Task schneller ist als die CPU...

[Senior Sanchez]

Wow. Ich dachte erst, das sei Blödsinn, aber es hat vielleicht wirklich eine Existenzberechtigung. Es hat wohl viel damit zu tun, dass man die Daten an seinem Platz lässt und nicht quer über den Chip routen muss. Man spart sich das Routing-Delay, welches ja schon in CPUs deutliche Anstrengungen bedarf, um es in Grenzen zu halten.

Hab ich das richtig verstanden, dass die im Grunde ständig die Konfiguration des FPGAs ändern, um dann in-place die Daten zu bearbeiten?

Klar kann man dann den FPGA ständig rekonfigurieren, aber bringt das außer Platzersparnis überhaupt etwas? Schneller kanns ja eigentlich nicht sein, da ich mir nicht vorstellen kann, dass man einen FPGA schneller rekonfigurieren kann als die Daten im FPGA hin und her zu schieben.

[Trap]

Klar kann man dann den FPGA ständig rekonfigurieren, aber bringt das außer Platzersparnis überhaupt etwas?
Platzersparnis hat viele weitere Auswirkungen. Das Routing ist einfacher wenn die Ziele näher dran sind, die Latenz bei kurzem Routing ist besser.
Schneller kanns ja eigentlich nicht sein, da ich mir nicht vorstellen kann, dass man einen FPGA schneller rekonfigurieren kann als die Daten im FPGA hin und her zu schieben.
Es ist ja auch keine Rekonfiguration wie bei den aktuellen FPGAs, sondern es werden alle möglichen Konfigurationen gleichzeitig bei der Konfiguration auf den Chip geladen. Bei jedem Takt wird nur die als aktiv geschaltete Variante gewechselt. Es könnten zum Beispiel Barrelshifter sein, von dem immer der vorderste Eintrag die aktuell gültige Konfiguration enthält.

[Senior Sanchez]

Ah, okay, das macht Sinn. :)

Klingt interessant!