Forum: FPGA, VHDL & Co. FPGA Core in einer Desktop CPU?


von Zi3 (Gast)


Lesenswert?

Man liest manchmal davon dass bereits daran geforscht wird CPUs zu 
entwickeln die einen FPGA Kern besitzen.
Im Idealfall soll die CPU dabei für bestimmte Berechnungen eigenständig 
die Berechnung im FPGA Teil durchführen um die massiv parallele 
Verarbeitung nutzen zu können.

Dabei müsste das FPGA Kern sehr schnell rekonfigurierbar sein während 
die CPU weiter läuft.

Für wie realistisch haltet ihr diese Entwicklung? Welche großen Hürden 
gibt es?
Und mit welchen Leistungssteigerungen sind zu rechnen?

Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen 
automatisch erkennen und dann in FPGA implementieren kann.
Realistischer erscheint mir wenn es für so eine CPU neue Befehle gibt 
und eine einfache SDK für Anwendungsentwickler oder für 
Spieleentwickler.
So das die Entwickler selbst entscheiden können welche Berechnungen im 
FPGA Teil parallel stattfinden sollen.
Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form 
einer Hardwarebeschreibungssprache erfolgen.

von Mac G. (macgyver0815)


Lesenswert?

Xilinx ZYNQ macht das schon seit vielen Jahren zumindest so ähnlich.
Die Beschreibung geht auch per HLS also in C und nicht in VHDL.

Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM.

von Horst (Gast)


Lesenswert?

Mac G. schrieb:
> Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM.

Gibts bei den Xeons aber auch schon länger:
https://www.golem.de/news/broadwell-ep-intel-zeigt-xeon-e5-mit-arria-fpga-auf-einem-package-1603-119772.html

von Markus K. (markus-)


Lesenswert?

Zi3 schrieb:
> Man liest manchmal davon dass bereits daran geforscht wird CPUs zu
> entwickeln die einen FPGA Kern besitzen.

Vor einem Jahr hat Intel mit der Auslieferung begonnen:
http://www.eweek.com/servers/intel-begins-shipping-xeon-chips-with-fpga-accelerators

> Dabei müsste das FPGA Kern sehr schnell rekonfigurierbar sein während
> die CPU weiter läuft.

Man würde das wohl eher wie bei den GPUs machen und eine Aufgabe lange 
laufen lassen.

> Und mit welchen Leistungssteigerungen sind zu rechnen?
Kommt drauf an. Wie gut läßt sich der Algorithmus parallelisieren usw.

Zi3 schrieb:
> Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen
> automatisch erkennen und dann in FPGA implementieren kann

Das ist einfach zu beantworten: Gar nicht. Selbst die Parallelisierung 
durch die SIMD-Befehle (SSE, AVX) macht der Compiler (oder der 
Programmierer) und nicht die CPU.

von Mac G. (macgyver0815)


Lesenswert?

Horst schrieb:
> Mac G. schrieb:
>> Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM.
>
> Gibts bei den Xeons aber auch schon länger:
> https://www.golem.de/news/broadwell-ep-intel-zeigt...


Das sind allerdings ZWEI Chips in einem Modul.
Und das Ding ist auch eher nicht für "Desktop" gedacht.
Xeon E5 EP und Arria FPGA jeweils für sich alleine kosten schon einige 
tausend Euro, das ganze Modul dürfte so zwischen 4000 - 10000 Euro 
liegen, je nachdem welches FPGA genau verwendet wird ;-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Diese CPU sind für Telekom und Internet Anwendungen, wo man oft die 
Algorithmen ändert, weil wieder neue Kompressionsverfahren oder 
Routingstrategien ausprobiert bzw. implementiert werden sollen. Von 
"Desktop" sind wir da bei fast allen Parametern fast schon diametral 
entfernt...

: Bearbeitet durch Moderator
von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Zi3 schrieb:
> Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen
> automatisch erkennen und dann in FPGA implementieren kann.

Algorithmisch tut sich bei heutiger Consumer-Software nicht so viel dass 
sich der Overhead für rekonfigurierbare Logik lohnen würde. Bei der 
Kryptographie ist seit >10 Jahren AES der Standard, 
Videodekodier-Standards entwickeln sich auch nicht schneller, und alles 
aus dem Bereich Signalverarbeitung (Videoeffekte, Spracherkennung, 
Bilderkennung etc.) braucht nur schnelle Grundrechenarten auf großen 
Vektoren.

: Bearbeitet durch Admin
von C. A. Rotwang (Gast)


Lesenswert?

Zi3 schrieb:

> Realistischer erscheint mir wenn es für so eine CPU neue Befehle gibt
> und eine einfache SDK für Anwendungsentwickler oder für
> Spieleentwickler.

Perlen vor die Säue, Neuronale netzte wäre ein sinnvolleres 
Einsatzgebiet für FPGA-Beschleunige.

> So das die Entwickler selbst entscheiden können welche Berechnungen im
> FPGA Teil parallel stattfinden sollen.
Warum das?

> Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form
> einer Hardwarebeschreibungssprache erfolgen.
Warum das?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

C. A. Rotwang schrieb:
>> Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form
>> einer Hardwarebeschreibungssprache erfolgen.
> Warum das?
Der ewige Traum: weil man dann Softwareentwickler schnelle Hardware 
machen lassen könnte...

von Zi3 (Gast)


Lesenswert?

C. A. Rotwang schrieb:
>> Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form
>> einer Hardwarebeschreibungssprache erfolgen.
> Warum das?

Damit die Akzeptanz größer ausfällt und die Unternehmen ihre Software 
Teams nicht mit weiteren Fachkräften für die Entwicklung von 
Digitaltechnik aufstocken müssen.
Wobei sicher nichts dagegen spricht einfach verschiedene 
Abstraktionsebenen anzubieten.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

C. A. Rotwang schrieb:
> Neuronale netzte wäre ein sinnvolleres Einsatzgebiet für
> FPGA-Beschleunige.

Auch wenn es auf den ersten Blick naheliegend erscheint, in der Regel 
macht es keinen Sinn ein neuronales Netz in kombinatorischer Logik 
abzubilden. Die "Intelligenz" eines neuronalen Netzes steckt nicht in 
der Struktur, sondern in den Gewichtsmatrizen, deshalb wuerde man auch 
nicht viel von der flexibel konfigurierbaren Feinstruktur eines FPGAs 
profitieren. Die meiste Rechenzeit bei der Auswertung geht in die 
Multiplikation der Eingaenge eines Layers mit der Matrix der Gewichte – 
also klassische Vektorrechnung fuer die CPUs und GPUs heute eh schon 
optimiert sind. Google geht mit der TPU 
(https://en.wikipedia.org/wiki/Tensor_processing_unit) noch einen 
Schritt weiter und optimiert speziell Vektorrechnung mit niedriger 
Aufloesung (8 Bit). Dass solche Funktionen demnaechst auch in CPUs 
landen halte ich fuer eher denkbar (bei AVX ist m.W. nach unten hin bei 
16 Bit Aufloesung Schluss).

von rbx (Gast)


Lesenswert?

Denkbar wäre  ein neues Lisp-Machine-Design, wenn man an die vielen 
Lisp-Dialekte denkt ;)

von Dr. No (Gast)


Lesenswert?

Nvidia ist den Weg auch schon gegangen:

https://www.heise.de/newsticker/meldung/GTC-2017-Nvidias-Volta-Architektur-ein-Meilenstein-im-GPU-Design-3712206.html

Microsoft kommt allerdings auch zu interessanten Ergebnissen:

https://www.microsoft.com/en-us/research/publication/accelerating-deep-convolutional-neural-networks-using-specialized-hardware/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F240715%2Fcnn%2520whitepaper.pdf



Andreas S. schrieb:
> C. A. Rotwang schrieb:
>> Neuronale netzte wäre ein sinnvolleres Einsatzgebiet für
>> FPGA-Beschleunige.
>
> Auch wenn es auf den ersten Blick naheliegend erscheint, in der Regel
> macht es keinen Sinn ein neuronales Netz in kombinatorischer Logik
> abzubilden. Die "Intelligenz" eines neuronalen Netzes steckt nicht in
> der Struktur, sondern in den Gewichtsmatrizen, deshalb wuerde man auch
> nicht viel von der flexibel konfigurierbaren Feinstruktur eines FPGAs
> profitieren. Die meiste Rechenzeit bei der Auswertung geht in die
> Multiplikation der Eingaenge eines Layers mit der Matrix der Gewichte –
> also klassische Vektorrechnung fuer die CPUs und GPUs heute eh schon
> optimiert sind. Google geht mit der TPU
> (https://en.wikipedia.org/wiki/Tensor_processing_unit) noch einen
> Schritt weiter und optimiert speziell Vektorrechnung mit niedriger
> Aufloesung (8 Bit). Dass solche Funktionen demnaechst auch in CPUs
> landen halte ich fuer eher denkbar (bei AVX ist m.W. nach unten hin bei
> 16 Bit Aufloesung Schluss).

von J. S. (engineer) Benutzerseite


Lesenswert?

Zi3 schrieb:
> Wobei sicher nichts dagegen spricht einfach verschiedene
> Abstraktionsebenen anzubieten.

Diese Ebenen gibt es ja schon und sie werden auch bedient. Es geschieht 
nur eben nicht automatisch, wie es sich mancher Träumer vorstellt. Das 
Markante an der Problematik ist einfach, das es ja die typischen 
"Softwareaspekte" sind, die abstrahiert und "vereinfacht" werden 
(sollen).

Wenn da der Fokus liegt, geht das prima.

Es bleibt aber der Umstand, dass eine effektive Softwareentwicklung 
immer Kenntnisse der HW erfordert, d.h. eine bekannte Struktur 
voraussetzt.
Es läuft also immer wieder auf die Nutzung eines Cores hinaus, weil 
keiner ständig eine neu adaptierte HW bauen möchte.

Die über diese Anforderungen darüber hinaus noch zu implementierende 
Sonderhardwarefunktion erfordert aber immer wieder eine spezielle 
Schaltung, die sich eben nur zum Teil durch ihren Ablauf beschreiben und 
sich nicht aus der SW-Beschreibun ableiten lässt.

Das ist nun mal so und grundsätzlich niemals zu ändern.

Was sich nur ändert, ist nur der Fokus, also das Verhältnis von SW und 
HW bei einer APP: Man wird sich aus (kosten)technischen Gründen eher mal 
mit suboptimaler HW zufrieden geben und mehr in die SW verlagern, wenn 
die HW preiswerter wird und man etwas verschwenderischer damit umgehen 
kann.
Den Prozess haben wir ja heute schon. Es wird mit mehr Tempo und weniger 
Optimierungseinsatz entwickelt und zwar was HDL für FPGAs und auch CPP 
für MCUs angeht.

Was das muntere Austauschen von HW-Funktionen in FPGAs in Echtzeit 
angeht, sehe Ich da enge Grenzen:

FPGAs sind aufgrund der Universalität letztlich ziemlich langsam und 
profitieren von speziellen Strukturen, die nur bei bestimmten 
Randbedingungen wirklich effektiv sind. Besonders pipelines und 
multithreading FSMs liefern ganz bestimmte Soll-Verhältnisse für 
Kanalzahl, Frequenz und Zugriffsoptionen. Da lässt sich nur schwer was 
umändern, um dynamisch schneller zu werden.

Die FPGAs im Umfeld der CPUs haben mithin ihre Hauptbedeutung weiterhin 
darin, sich gegen Fehler bei Auslieferung zu schützen oder sich auf 
mögliche Änderungen der Funktion oder künftige, zum Zeitpunkt der 
Entwicklung noch unbekannte Peripherie vorbereiten zu können. Und genau 
das macht Intel.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.