Forum: FPGA, VHDL & Co. Wann kommt FPGA Technik für Consumer Notebooks / PCs


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich wollte mal fragen ob jemand weiß ob es von der Industrie angedacht 
wird oder ob geforscht daran wird, dass FPGAs auf kurz oder lang Einzug 
in normale Haushalts - PCs/Notebooks/Tablets bekommen.

Nach oben hin soweit abstrahiert dass Ressourcenzuteilung vom OS 
gemanaged wird und man den VHDL Code in eine Software einbettet wird mit 
Zugriff über Standard-APIs.
Evtl. dann ein Speicherbereich angelegt wird der parallel von Software 
und FPGA genutzt wird.

So dass sehr rechenintensive Software einfach Teile auf den FPGA 
auslagern kann ohne dass irgendwelche Anpassungen an der Hardware von 
nöten sind.


Ich hoffe ihr versteht so ca wie ich das meine, sozusagen ein Xilinx 
ZYNQ nur statt mit einem Dual-Core ARM mit einem Intel I7 und mehr 
Abstraktion zum OS.

von Maik H. (littlechip)


Bewertung
4 lesenswert
nicht lesenswert
Gar nicht...

Im Consumerbereich erschlägt man einfach alles mit puren Ghz bzw wenn es 
wirklich mal Parallelverarbeitung gibt, dann halt mit CUDA o.ä.

Was du meinst sind schon wieder Spezialanwendungen wie sie im Bereich 
DataCenter oder SDN vorkommen. Da wird es bestimmt von Intel in Zukunft 
ein paar Chips mit integriertem FPGA geben, aber ich denke eher nicht, 
dass das für den breiten Markt interessant wird.

von Horst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bert schrieb:
> Ich hoffe ihr versteht so ca wie ich das meine, sozusagen ein Xilinx
> ZYNQ nur statt mit einem Dual-Core ARM mit einem Intel I7 und mehr
> Abstraktion zum OS.

Hardware gibt es doch schon, wie du es dir wünscht:

http://www.golem.de/news/broadwell-ep-intel-zeigt-xeon-e5-mit-arria-fpga-auf-einem-package-1603-119772.amp.html?client=safari

An der Abstraktion hapert es aber wohl noch..

von Stefan P. (form)


Bewertung
0 lesenswert
nicht lesenswert

von schotter (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das von Intel ist aber weit entfernt von "Consumer".
Sicher auch preislich. So ein Stratix 10 FPGA alleine kostet ja schon 
ein Vermögen, wenn dann noch ein Xeon mit dabei ist... ;-)

von Falk B. (falk)


Bewertung
4 lesenswert
nicht lesenswert
Reconfiguratable Computing als Idee gibt es seit über 20 Jahren, aber 
außerhalb einiger akademischer Spielereien und Nischenanwendungen ist 
daraus bisher nie was geworden. Eine CPU als ASIC ist halt billiger und 
kosteneffizenter als ein FPGA. Bestenfalls die GPUs von heute werden für 
einige wenige Sachen als Nicht-Grafikprozessor benutzt.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Reconfiguratable Computing als Idee gibt es seit über 20 Jahren,
> aber
> außerhalb einiger akademischer Spielereien und Nischenanwendungen ist
> daraus bisher nie was geworden. Eine CPU als ASIC ist halt billiger und
> kosteneffizenter als ein FPGA. Bestenfalls die GPUs von heute werden für
> einige wenige Sachen als Nicht-Grafikprozessor benutzt.

Tjo, das ist es wohl. Das einzige Consumer-Beispiel das mir gerade 
unterkommt, ist der ICE40 in einigen Smartphones. Ist aber nicht gerade 
das, was der Fragesteller im Sinn hatte, ne?
In den meisten Anwendungen, wo noch ein FPGA vonnöten ist, erledigt sich 
der Aspekt der Rekonfigurierbarkeit mit einfachen Microcode-Tricks in 
Anlehnung an gut etablierte DSP-Konzepte.
Bei Massenanwendungen wird aus sowas dann einfach eine weitere 
Opcode-Extension/Coproz. Für anderes sind die Tools einfach auch zu 
schwerfällig (zumindest, was unsereiner so zu Gesicht bekommt).

Im Beispiel von Intel ist es allerdings schon "hot", auf dem gleichen 
Chip die Synthese zu machen, mit deren Resultat sich der Chip dann 
selbst programmiert. (Und welche Möglichkeiten es gäbe, sich 
"auszusperren"...).

von Martin (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Geht das überhaupt einen FPGA zu rekonfigurieren während andere Teile 
aktiv bleiben sollen?

User habe ich jetzt so verstanden:


1. User öffnet Windoof Programm
2. Programm reserviert sich Speicherbereich vom System
3. Progrmam öffnet über Standard-Windoof-Api irgendwas Datenintensives 
z.B. Videoquelle
4. Programm öffnet über Standard-Windoof-Api einen VHDL Code inkl. 
Übergabe der Adresse des Speicherbereich. Dadurch findet Datenaustausch 
und Konfiguration der HW-Register statt
6. (Parallel) FPGA überarbeitet Video im Speicher
7. Live-Video das durch FPGA gearbeitet wurde wird in einer GUI 
angezeigt.


8. User öffnet parallel zu laufendem Video-Programm parallel nächstes 
Programm das ebenfalls den FPGA nutzt und zur Laufzeit (nur zum Teil) 
umprogrammiert wird.

Würde vor allem dann voraussetzen dass man keine gerstellerspezifischen 
Blöcke auch hätte und wenn dann irgendwie vorher standardisiert werden 
müssten.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Bert schrieb:
> ich wollte mal fragen ob jemand weiß ob es von der Industrie angedacht
> wird oder ob geforscht daran wird, dass FPGAs auf kurz oder lang Einzug
> in normale Haushalts - PCs/Notebooks/Tablets bekommen.
Gar nicht. Viel zu teuer.
In einem vollständig vollen und fertig konfigurierten FPGA werden 
bestenfalls 25% (hoch gegriffen!) der darin eingebauten Ressourcen 
verwendet. Der Rest liegt mehr oder minder "brach". Das geth schon bei 
den Taktnetzen los, weil ja viele Taktnetze im FPGA sind, an 1 Flipflop 
aber nur 1 Takt angeschlossen werden kann. Allerdings müssen an den für 
das Flipflop nötigen Taktmultiplexer z.B. 4 der Taktnetze hingeführt 
werden --> Ausnutzung der verbauten Ressourcen = 25%. Und mehr ist an 
dieser Stelle gar nicht möglich. Das kann ein ASIC besser, da wird an 
jedes Flipflop nur der Takt geführt, den es braucht --> Ausnutzung 
100%...

Martin schrieb:
> Geht das überhaupt einen FPGA zu rekonfigurieren während andere Teile
> aktiv bleiben sollen?
Ja. Das Design muss es eben abkönnen. Allerdings ist hier wieder mal 
nicht die Hardware das Problem, sondern die Software.
So wie eben schon Horst schrieb:
>> An der Abstraktion hapert es aber wohl noch..

von Jürgen S. (engineer) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
FPGAs machen bei vielen PC-Apps praktisch keinen Sinn. Der Grund ist 
der, dass FPGAs ihren Hauptvorteil beim Streaming-Prozessieren haben, 
was bei PC-APPs kaum vorkommt. Im Gegenteil: PC sind auf Kosten hin 
optimiert und nehmen Bandbreitenverschwendung in Kauf, um z.B. Speicher 
zu sparen.

DDR-Speicher ist so ein typisches Thema: Theoretisch exorbitante Raten 
und real Nutzung im Prozentbereich. Bei Notebooks kommt noch der Punkt 
der Wärmeoptimierung hinzu. Mithin bewegen wir uns bei derselben 
Problematik wie bei den Smartphones: Ich kenne da eine Reihe von Spezis, 
die Riesen-Apps in der pipeline haben und alles Mögliche und Unmögliche 
auf den Smartphones machen wollen und damit kalkulieren, dass deren CPUs 
"immer leistungsfähiger werden" - sie verkennen aber, dass der Punkt 
längst überschritten ist und sowohl bei Notebooks als auch smart phones 
schon seit Langem nicht mehr das technische Machbare eingebaut wird, 
weil es zuviel Strom frisst. Was das Thema Performance/Power angeht, 
sind auch Grenzen gesetzt, was die Zukunft angeht. Es wären also nur 
Leistungsapplikationen interessant und da gibt es bei PC-Anwendungen 
einfach zu wenig Anforderungen für echte Echtzeitfähigkeit.

Einzig im Bereich Grafik gibt es da entsprechenden Bedarf aber der ist 
inzwischen mehr, als ausreichend durch die GrafikChips gedeckt und zwar 
sowohl in qualitativer als auch in quantitativer Hinsicht: Vieles von 
dem, was Grafikarten können, kann man in FPGAs nicht effektiv nachbauen 
und wenn, dann nur mit enormem Aufwand und Kosten. Um z.B. einen 
aktuellen mittelklassigen NVIDIA-CHIP abzubilden, braucht man schon 
einen Kintex, bzw gfs mehrere, um die dynamische Speicherbandbreite zu 
packen und den output zu transportieren. Und wenn man fertig ist, hat 
man wie bei vielen FPGA-Apps eine gewaltige Heizung!

------------------------------------------------------------------

Applikationen, in denen FPGAs verwendet werden, haben ganz spezifische 
Eigenschaften, wie z.B. eine lokal! und statisch hohe 
Speicherbandbreite, wegen einer hohen Zahl von sich in Echtzeit 
ändernden Parametern und / oder einer Spreizung der Rechenpfade besteht, 
gefolgt von einer massiven Datendezimierung, wie es z.B. bei der 
Regelungstechnik, bei neuronalen Netzen und Simulationen der Fall ist, 
die mit parallel mit leicht modifizierten Ansätzen rechnen. Auch 
Genauigkeitsüberabtastung durch verrauschtes Rechnen sind solche Themen. 
Die wohl besten praktischen Beispiele aus dem Consumerbereich sind Audio 
und Videodatentröme, die auffalten und wieder zusammengemischt werden, 
wie Videofilter mit großer Matrixbreite und eben Audio-Synthesizer, die 
wenige Audiodaten oder MIDI reinkriegen, intern breit parallel / mit 
vielen Kanälen arbeiten und dann mit wenigen Ausgängen wieder 
rauskommen. Das geht dann weder mit CUDA noch PCs sequenziell annährend 
effektiv.

Massgeblich ist dabei aber das Vorhandensein der internen 
Speicherelemente, also der FFs und der BRAMs! Damit lassen sich 
Speichertransaktionen bewerkstelligen, die über, das mit externen DDRx 
machbar ist, um zwei bis 3 Zehnerpotenzen übertreffen.

--------------------------------------------------------------------

Aber wie gesagt, das alles weit davon weg, was PCs machen.

Wo ich Bedarf und Optionen sehe, ist CUDA mit einer Extra-Grafikarte als 
Rechenknecht, die dynamische Gleichungen löst, um sie in Simulationen 
wie pSPICE, ModelSIM oder Ähnliches einschleifen zu können. Momentan 
braucht es zum Schnellsimulieren eine FPGA-App wie System-Generator, die 
C oder VHDL in ein offline rechnendes FPGA packt, das dann nur noch mit 
Vektoren versorgt wird. Das läuft sehr schnell - erfordert aber eine 
aufwändige und lange Synthese!

Da es sich aber bei ISIM und ModelSIM in beiden Fällen um eine 
compilierte Simulation handelt, könnte man die Software so konfigurieen, 
dass sie im Fall des Vorhandenseins einer CUDA-Einheit, Teile des Codes 
dort rechnen lässt. Der dafür nötige Code liesse sich sehr viel 
schneller erzeugen, als eine typische Synthese - zumal man man 
Object-Libs arbeiten könnte, die nur noch gelinkt werden müssten. Ich 
rechne damit, dass das eher in der Nähe des Bedarfs des C-Compilats 
läge, als bei dem Zeitbedarf der Synthese - wäre also sehr schnell 
übersetzt und einsetzbar.

Eine solche compilierte Simulation würde auf der Graka teilweise 
parallel laufen und die ganze Geschichte um Faktoren von gfs 2..10 
beschleunigen. Viel schneller ist die Co-Simulation mit MATLAB auch 
nicht, weil zwar der FPGA alles um (nach meinen Erfahrungen) Faktor 
100-1000 schneller macht, aber der Transport der Testvektoren und 
Ergebnisse zum Limiter wird. Ich hatte damals so durchschnittlich einen 
Faktor 5-15. Lohnen tat sich das dann ab Simulationslängen von etwa 
30min, die man auf 5min + 20min Synthese verkürzen konnte.

Mit Software in den CUDAs fiele die Compilation kürzer aus und wäre ohne 
große Umstände und Sonderhardware realisierbar. Eigentlich müsste man 
ein Projekt starten, um GDHL dahingehend fit zu machen! Wer dann 
VHDL-Simulation betreiben will, braucht nicht mehr den teuren 
Systemgenerator und MATLAB, sondern einfach ein paar Hunnies für eine 
weitere Grafikarte und ab geht die Post :D

VHDL-Beschreibungen bieten ja eine Reihe von Ansätzen zur parallelen 
Berechnung, die optimiert gerechnet werden können, sodass es sich lohnt, 
denn wie eingangs erklärt, sind es eben genau typische 
FPGA-Applikationen, die solche Erfordernisse haben, wie Parallelität, 
Aufspreizung von Rechenpfaden etc - daher kam man ja auf die Idee, 
FPGA-Simulationen durch FPGAs zu unterstützen :-)

Wir brauchen also nicht FPGAs in PCs, um schneller rechnen zu können, 
sondern CUDA in PCs, um schneller FPGAs bauen zu können :-)

von Rote T. (tomate)


Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es eigentlich mit der Sicherheit aus? Ich würde mal behaupten, 
das man Malware wunderbar in einem FPGA verstecken könnte.

Ausserdem könnte man doch vermutlich auch logische Crashs, wilde 
Oszillatoren oder Kurzschlüsse in die Config einbauen, die dann den FPGA 
grillen. Ein Traum eines jeden Malware-Programmierers, wenn die Hardware 
abraucht.

: Bearbeitet durch User
von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rote T. schrieb:
> Ich würde mal behaupten,
> das man Malware wunderbar in einem FPGA verstecken könnte.


Wo kann man denn Malware nicht wunderbar verstecken?
;-)

Zum Glück stürzen sich die Malware Entwickler aber eher auf "übliche" 
Ziele...

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Seit wieviel Jahren sind Multicore-Prozessoren üblich? 10 Jahre 
mindestens, eher mehr.

Dennoch sind auch heute noch sehr viele Applikationen nicht so 
programmiert daß sie davon Gebrauch machen. Daher hat Intel in den 
letzten CPU-Generationen extra einige Möglichkeiten eingebaut, um die 
Singlecore-Performance zu erhöhen wenn nur ein Core benötigt wird und 
die anderen im Leerlauf sind.

Der klare Engpass ist also die Schulung der Programmierer da draußen.

Und da willst Du jetzt FPGAs auf die loslassen? Vom Singlethread- zum 
Multithread-Programm ist der Lernaufwand machbar und das eine baut auf 
dem anderen auf. Aber eine Hardware-Beschreibungssprache für den FPGA 
ist quasi eine komplett neue Welt, Du musst ganz von vorne anfangen.

von Sigi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Und da willst Du jetzt FPGAs auf die loslassen? Vom Singlethread- zum
> Multithread-Programm ist der Lernaufwand machbar und das eine baut auf
> dem anderen auf. Aber eine Hardware-Beschreibungssprache für den FPGA
> ist quasi eine komplett neue Welt, Du musst ganz von vorne anfangen.

Je nach Philosophie falsche Sichtweise: Nimm z.B. Geräte
und ihre Treiber. Die meisten Progger sind ja auch nicht
in der Lage, Treiber zu schreiben. Die werden per OS
nachgeladen/installiert, der Anwender merkt davon nichts.
Genauso kann man es auch bei FPGA-Resourcen machen.
Schaut man sich aber z.B. unter Windows/DOS die geschichtliche
Entwicklung von Treibern an, bis ein "einfacher" Standard
geschaffen wurde .. na dann gute Nacht für FPGAs in PCs.

Und Btw: Einfach den Proggern nur Multithreading beizubringen
ist ja nur der kleinste Teil der Lösung. Das Anwenden des
Wissens ist ja auch mit Aufwand verbunden. Wer soll den dann
bitte bezahlen? Und das dann noch bei FPGA-Designs, das
lohnt dann nur bei kleinen hochspezialisierten Entwickergruppen
und sehr breiter Verwendung, also die wenigsten Apps.

von Codix (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Sigi schrieb:
> Proggern nur Multithreading beizubringen

Das kann wirklich nur eine Hand voll, das ist das Problem.
Wie man mit einer Multi-Core Architektur wirklich nutzt, das
wissen nicht einmal die Jungs bei Google, die das Android OS verbrechen.

von Kest (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Meine bescheidene Meinung:
in 5 Jahren ist ein FPGA in jeder CPU mit drin -- Intel hat da was, AMD 
baut da was (sogar auch in der Grafikkarte). Alleine die Größe des FPGAs 
ist noch unklar.

Intel stattet ganze Serverfarmen von Microsoft (Project 
Catapult)/Google/Facebook und Amazon mit Xeons mit FPGA (auch mit PCIe 
FPGA-Karten). Sobald man da große Stückzahlen erreicht hat, werden die 
CPUs dann auch beim Consumer ankommen -- das ist sicher.
Es muss nicht gleich Stratix 10 sein. Irgendwas Einfaches mit 
Speicheranbindung reicht schon. Erst wird man sich mit diversen Tools 
rumschlagen müssen (Synthese), aber auch dann irgendwann mal kommt 
lang-Compiler, der bit-Code für beliebige FPGAs rausspuckt (so wie jetzt 
OpenCL Compiler für Altera FPGAs).

Ab da kommt jedes Programm mit einem eigenen FPGA-Code/Bit-File, was 
dann beliebig optimiert werden kann -- genauso wie jetzt Programme mit 
CUDA oder OpenCL-Unterstützung.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Kest schrieb:
> Meine bescheidene Meinung:
> in 5 Jahren ist ein FPGA in jeder CPU mit drin
Ich halte dagegen und sage, dass auch in 5 Jahren FPGAs in "normalen" 
CPUs eine Randerscheinung im untersten Prozentbereich sind. Bestenfalls 
Nischenmärkte werden da eine höhere Dichte erreichen. Und nur so wird 
auch in den meisten Berichten zu diesen Prozessorkonzepten von "Data 
Center" oder "Server Farm" gesprochen.

Aber wenigstens hat Intel noch das Geld, solche Märkte ohne Gewinn zu 
versorgen, sonst wird das Konzept weiter in Nischen herumdümpeltn, wie 
das hier:
http://www.heise.de/newsticker/meldung/CPU-heiratet-FPGA-97619.html

Mal sehen, ob der Ansatz "CPU mit FPGA" besser läuft als das 20 Jahre 
alte Konzept "FPGA mit CPU", das am Markt nie so richtig der Hit war:
https://www.xilinx.com/products/silicon-devices/soc.html

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kest schrieb:
> Erst wird man sich mit diversen Tools
> rumschlagen müssen (Synthese), aber auch dann irgendwann mal kommt
> lang-Compiler, der bit-Code für beliebige FPGAs rausspuckt (so wie jetzt
> OpenCL Compiler für Altera FPGAs).
>
> Ab da kommt jedes Programm mit einem eigenen FPGA-Code/Bit-File, was
> dann beliebig optimiert werden kann -- genauso wie jetzt Programme mit
> CUDA oder OpenCL-Unterstützung.

Ich denke, da wird es noch ein paar Technologiesprünge geben. Irgendwie 
muss es in Richtung einer gut funktionierenden HLS gehen, die auch 
einigermassen "on-the-fly" synthetisierbaren Code generiert.
CUDA ist mal so ein Beispiel, wo der Technologiesprung vor >15 Jahren 
erfolgt ist, aber die Tools etwas länger gebraucht haben.
Die HDL-Welt kommt mir noch schwerfälliger vor, da hätten wir eigentlich 
schon längstens den Sprung nötig, den GCC für die SW-Entwicklung hatte.
Lichtblicke gibt's zwar schon, seien es die div. pfiffigen HDL-Ansätze 
per Python, oder die yosys-Toolchain. Irgendwie muss nur noch ein 
besseres Verständnis für OpenSource in der HDL-Welt geschaffen werden.
Wüsste zwar nicht, wer dort den Stallman mimen sollte, der Geist der 
80er ist irgendwie verflogen.

Und dann gibts sicher auch noch ganz pragmatische Probleme zu lösen, wie 
FPGA- und CPU-Technik plus ev. noch Analog in Technologie X auf dasselbe 
Die zu klatschen, m.W ist das bei der Intel-Lösung nicht der Fall.
Ich bin mal gespannt, wie GoWin das in Zukunft löst, aber von denen war 
noch nix in die Finger zu kriegen. Leaks, anyone?
Schön wäre ja so ein kleiner stromsparender MIPS mit FPGA Fabric an 
verschiedenen Peripherie-Bussen, gut verteilt und unabhängig (und bitte 
ohne den AXI-Overhead :-) )

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>
> Aber wenigstens hat Intel noch das Geld, solche Märkte ohne Gewinn zu
> versorgen, sonst wird das Konzept weiter in Nischen herumdümpeltn, wie
> das hier:
> http://www.heise.de/newsticker/meldung/CPU-heirate...
>

Die Jungs von Stretch haben doch immerhin einen erwerbbaren Prozessor 
gebaut, war das nicht für Videokram vorgesehen? Abschreckend war nur die 
Xtensa-Architektur... (und juhu, mit dem ESP8266 wieder omnipräsent).

> Mal sehen, ob der Ansatz "CPU mit FPGA" besser läuft als das 20 Jahre
> alte Konzept "FPGA mit CPU", das am Markt nie so richtig der Hit war:
> https://www.xilinx.com/products/silicon-devices/soc.html

Ich weiss ja nicht, wie die Fachwelt das so generell sieht, aber diese 
SoC-Konzepte haben immer irgendwie das "Keep it simple"-Konzept 
verletzt, oder waren einfach zu high-end/zu teuer, um gegen eine simple 
DSP-Lösung anzustinken. Wenn die Bastion mal gebrochen wird, könnte es 
schon wieder anders aussehen.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Wenn die Bastion mal gebrochen wird, könnte es schon wieder anders
> aussehen.
Ja, eben bisher wurde bei der Kombi "FPGA mit CPU" immer eher auf das 
FPGA abgehoben und die Toolchain war von einem Hardwarebauer 
geschrieben. Mal sehen, ob die "Prioritäteninversion" im Sinne von "CPU 
mit FPGA" und der softwarenahe Ansatz den richtigen Hebel findet...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Der erste Schritt ist ja getan, indem man auf die etablierten 
ARM-Strukturen setzt. Ob das allerdings eine wirkliche 
Schwerpunktverschiebung ist ... ?

Wenn der Schwerpunkt eines Systems nicht auf dem FPGA liegt, dann 
braucht man in der Regel keines und auch keines mit Prozessoren, sondern 
eben einfach Prozessoren (und vielleicht ein MINI-FPGA davor). Schon aus 
Kostengründen. In der Gesamtschau von Entwicklungsaktivitäten mit 
Validierung, Verfikation, Inbetriebnahme und Test sind FPGA-Systeme nun 
mal generell aufwändiger, als eine konventionelle 
Programmierertoolchain.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Der erste Schritt ist ja getan, indem man auf die etablierten
> ARM-Strukturen setzt. Ob das allerdings eine wirkliche
> Schwerpunktverschiebung ist ... ?
>

Hmm. Ich kenne mehr Leute, die Soft-Cores einsetzen als 
Zynq-Plattformen...
Mag vielleich daran liegen, dass die volle Simulationskette eine Menge 
Schotter kostet.

> Wenn der Schwerpunkt eines Systems nicht auf dem FPGA liegt, dann
> braucht man in der Regel keines und auch keines mit Prozessoren, sondern
> eben einfach Prozessoren (und vielleicht ein MINI-FPGA davor). Schon aus
> Kostengründen. In der Gesamtschau von Entwicklungsaktivitäten mit
> Validierung, Verfikation, Inbetriebnahme und Test sind FPGA-Systeme nun
> mal generell aufwändiger, als eine konventionelle
> Programmierertoolchain.

Ich würde das nicht mehr unbedingt unterschreiben. Ich hatte die letzten 
Jahre einige Anwendungen (mit Soft-core), wo das exakte Simulieren des 
Szenarios viel Zeit gespart hat gegenüber der uC-Lösung, wo das genaue 
Verhalten der Peripherie nicht bis ins letzte Detail dokumentiert ist, 
oder sogar in Einzelfällen nicht so funktioniert hätte (Toll, wenn man 
die Erkenntnis Wochen nach der 0-Serie hat...)
Damit meine ich jetzt nicht mal sicherheitsrelevante Geschichten, wo man 
die einfache State-Machine für die Safety besser zertifiziert bekäme 
(auch da gibt es offenbar völlig unterschiedliche Ansichten bis 
Fa(r)cetten), rein die Angst, nach Auslieferung noch monatelang 
nachbessern zu müssen, zwingt einen schon mal zur beweisbar 
vollständigen "Coverage".

Die Zeit fürs Aufbauen der Toolchain habe ich nicht eingerechnet, aber 
die kann bei frischem uC-Silicon auch schon mal ein halbes Jahr 
hinmachen, besonders, wenn die Bugs erst gefunden werden müssen.

von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Jürgen S. schrieb:
>> Der erste Schritt ist ja getan, indem man auf die etablierten
>> ARM-Strukturen setzt. Ob das allerdings eine wirkliche
>> Schwerpunktverschiebung ist ... ?
>>
>
> Hmm. Ich kenne mehr Leute, die Soft-Cores einsetzen als
> Zynq-Plattformen...
> Mag vielleich daran liegen, dass die volle Simulationskette eine Menge
> Schotter kostet.


... oder daran, dass die Zynqs ansich eine Menge Schotter kosten ;-)
Softcores bekommt man ja auch in 10 Euro FPGAs rein.

von Falk B. (falk)


Bewertung
2 lesenswert
nicht lesenswert
@Zorg (Gast)

>... oder daran, dass die Zynqs ansich eine Menge Schotter kosten ;-)
>Softcores bekommt man ja auch in 10 Euro FPGAs rein.

Sicher, aber vergleiche mal die Leistung eines Softcores in einem 10 
Euro FPGA mit einem 10 Euro uC. . . .
Außer in Spezialfällen, wo eine sehr angepasste Kopplung von 
selbstgestrickten IO-Modulem mit der CPU sinnvoll und nötig ist, gewinnt 
der Standard uC . . .

von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klar sind richtige Mikrocontroller einem Softcore überlegen.
Wenn man ein FPGA einsetzt dann jedoch meistens aus einem bestimmten 
Grund, also würde ein µC alleine wohl nicht reichen - man hat das FPGA 
also so oder so auf der Platine. Aber dann kann es sinnvoller sein 
(Platzbedarf, I/O Pins, Bandbreite zur CPU...) den Controller ins FPGA 
zu integrieren und nicht extern dran zu flanschen - auch wenn ein 
Softcore nicht so gut/schnell ist wie ein externer...

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Bert schrieb:
> ich wollte mal fragen ob jemand weiß ob es von der Industrie angedacht
> wird oder ob geforscht daran wird, dass FPGAs auf kurz oder lang Einzug
> in normale Haushalts - PCs/Notebooks/Tablets bekommen.

Das sollte realisierbar sein mit:
https://www.pi-top.com/product/pi-top
und
https://shop.trenz-electronic.de/en/detail/index/sArticle/2524/sCategory/350

Eine solche Variante finde ich interessant.

> Ich hoffe ihr versteht so ca wie ich das meine, sozusagen ein Xilinx
> ZYNQ nur statt mit einem Dual-Core ARM mit einem Intel I7 und mehr
> Abstraktion zum OS.

Das wäre dann eine PCIE-Karte oder eine ExpressCard.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Hmm. Ich kenne mehr Leute, die Soft-Cores einsetzen als
> Zynq-Plattformen...
> Mag vielleich daran liegen, dass die volle Simulationskette eine Menge
> Schotter kostet.
Ich glaube eher, dass es damit zu tun hat, dass Zynq neu ist und 
Softcores seit 15 Jahren im Gebrauch sind.


Lars R. schrieb:
> https://www.pi-top.com/product/pi-top

Bizarr, ein Bastel-Laptop?  Ich weiß nicht, ich fände es billiger und 
zielführender, einen normalen Lappy und externes Equipment zu nehmen, 
das über USB drankkommt.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Lars R. schrieb:
>> https://www.pi-top.com/product/pi-top
>
> Bizarr, ein Bastel-Laptop?  Ich weiß nicht, ich fände es billiger und
> zielführender, einen normalen Lappy und externes Equipment zu nehmen,
> das über USB drankkommt.

Warum bizarr? Wenn die Idee "dynamische (Teil)-Rekonfiguration in 
Symbiose mit dem Betriebssystem (Kernelmodule zur Laufzeit dazu laden)" 
lautet, dann fallen mir keine passenderen Komponenten ein. Allerdings 
weiß ich nicht, ob der Zynq dynamische Rekonfiguration beherrscht. 
Außerdem wäre mehr RAM gut und dass die Xilinx-SW prinzipiell auf dem 
Zynq-ARM laufen kann. Mit der übernächsten Generation geht es bestimmt 
;)

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Im Servermarkt werden FPGAs in die CPUs einziehen, und in 5-10 Jahren 
wird das dann auch nicht mehr nur das rechtsunten-Modell sein. Dafür 
besteht zu viel Interesse daran, mit großen Datenmengen zu hantieren.

Intels Konzept zielt ja nicht auf "hey wir haben einen FPGA dabei" ab, 
sondern auf "hey, wir haben einen FPGA dabei, der cache-kohärent am 
gleichen Speicherbus sitzt wie die CPU selbst, inklusive MMU" (evtl. 
auch Kontext). Das macht das Konzept so interessant für Firmen wie 
Google, Facebook, Banken, ISPs oder jedem anderen, der mit vielen Daten 
hantieren muss.

Ich würde einen Teufel tun und einen Algorithmus komplett in einen FPGA 
stecken, wenn der Datentransport nur noch einen L1-Cache-Miss kostet. 
Viele Algorithmen würden ja prima auf einer CPU funktionieren, wenn da 
die eine dicke Matrixmultiplikation o.ä. nicht wäre... und mit dem 
Ansatz sind weder Synthese noch Verifikation so extrem.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Im Servermarkt werden FPGAs in die CPUs einziehen, und in 5-10 Jahren
> wird das dann auch nicht mehr nur das rechtsunten-Modell sein. Dafür
> besteht zu viel Interesse daran, mit großen Datenmengen zu hantieren.

Dann muss man sich aber früher oder später mal von den zahlreichen 
CACHE-Leveln und ihrem verkomplDas ist doch momentan DIE Bremse für hohe 
Bandbreiten und Durchsätze. Da hilft es m.E. wenig, in die CPU einen 
FPGA einzuführen, wenn der Flaschenhals an anderer Stelle sitzt.

Der FPGA hat für mich den Vorteil, daß man gfs sein System auf Streaming 
anforderungen hin tweaken könnte, wenn es eine Anwendung erfordert und 
man dann zu einem balanced Modell zurückkehrt, daß parallele Prozesse 
fahren soll. Da entstünde also eine gewisse Dynamik.

Ansonsten wird man FPGAs vielleicht noch im Bereich flexible DMA 
einsetzen können, wenn irgenwoher massiv Messdaten eintrudeln, die ohne 
CPU-Last ins RAM müssen.

Ich verspreche mir von FPGAs aber letztlich keinen großen 
Performance-Schub, wenn man nicht an der PC Architektur grundsätzlich 
schraubt.

Wo man mal ranmüsste, sind die RAMs: Echte bidirektional schreib- und 
lesefähig RAMs mit breiter Datenanbindung so in Richtung 1024 Bit gleich 
zeitig weg und wieder herbei, statt immer längere 8 bit bursts mit DDR6 
und Latenzen in der Größenordnung von 50 Takten, in denen man ganze 
Faltungen machen könnte.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oh, da ist was verschwunden! Gemeint war:

... früher oder später mal von den zahlreichen CACHE-Leveln und ihrem 
verkomplizierenden Zugriffsaspekten trennen, denn DAS ist die Bremse 
....

Noch ein inhaltlicher Nachtrag:

Server sind eine Sache, Desktops eine andere. Desktops verschwinden, wie 
die Notebooks und werden durch tabletts ersetzt. Was man bei denen nicht 
brauchen kann, sind stromhungrige FPGAs. Die Performance, die man also 
mit FPGAs in die Computers stecken wird können, wird minimal sein, egal, 
wofür sie gedacht sind.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, du missverstehst das Ziel von dem Kram.

Was Intel tut ist, den FPGAs ein QPI-Interface zu geben. Damit hat der 
FPGA exakt den gleichen Zugang zum Speichersystem wie alle anderen 
CPU-Cores auch, und damit fällt der Datenverkehr zwischen RAM und FPGA 
komplett aus.

Weil zudem alles kohärent ist und nahezu ohne Performanceverlust (nur 
L1-Miss) abläuft, kann der FPGA direkt transparent auf den 
Datenstrukturen der CPU arbeiten. Teile der Web-Applikation, der 
Datenbank oder von PHP können dann im FPGA implementiert werden.

Intel hat als Demonstration einen Sudoku-Solver vorgeführt.
(a) Der C-Code legt die Matrix in den Speicher,
    löst das Sudoku
    und zeigt die Matrix dann an.
(b) Der C-Code legt die Matrix in den Speicher,
    triggert den FPGA mit dem Pointer,
    wartet kurz
    und zeigt die Matrix dann an.

Das schmeckte schon ein bisschen nach Multithreading mit einem 
Fixed-Function-Thread.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@S. R. (svenska)

>Intel hat als Demonstration einen Sudoku-Solver vorgeführt.

..

>Das schmeckte schon ein bisschen nach Multithreading mit einem
>Fixed-Function-Thread.

Gähn

Solche Spielereien gibt es seit über 20 Jahren in den verschiedensten 
Formen, sei es als uC + FPGA in getrennten ICs, FPGA+Soft oder Hardcore 
in einem IC und nun als CPU + FPGA. Das Grundprinzip haben wir glaube 
ich schon lange verstanden ;-)
Der Knackpunkt ist doch, das macht man in der REALEN (Geschäfts)welt 
nicht zum Selbstzweck, sondern um ordentlich PS auf die Straße zu 
bekommen, sprich RECHENLEISTUNG!!! Und wenn da Intel nicht mal in ein 
richtig fette Demonstation hinbekommt und nur ein lahmes Sudoku 
"präsentiert", muss man sich über die ausbleibende Resonanz nicht 
wundern . . .

Vor ein paar Jahren hat man mit FPGA-Gräbern Bitcoins berechnet, heute 
machen das schon lange Spezial-ASICs in 1000er Farmen (u.a. in Island). 
Über den Sinn und Unsinn von Bitcoin soll hier nicht diskutiert werden.
Das FPGA war nur das Sprungbrett, die schnelle Entwicklerplattform, 
wofür es logischerweise perfekt geeignet ist.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Solche Spielereien gibt es seit über 20 Jahren in den verschiedensten
> Formen, sei es als uC + FPGA in getrennten ICs, FPGA+Soft oder Hardcore
> in einem IC und nun als CPU + FPGA.
Das ist der Punkt. Solange die CPU da mitrauscht und umgekehrt, nicht 
gewaltige FPGAs mitreden, ist da wenig zu bestellen, was angebliche 
zusätzliche Performance leisten könnte. Woher sollte die auch kommen?

Es ist doch vielmehr so, daß Applikationen, die man früher in Hardware 
machen musste, heute dank der CPU-Power eher noch in SW zu machen sind. 
Daher wäre es ehr so, dass früher noch FPGA Sinn gemacht hätten, deren 
Wert sich heute so langsam relativiert.

Ein Beispiel sind die Grafikarten. Viele Anwendungen aus der Ecke 
bedurften früher Spezialchips, heute macht es die CPU nebenläufig mit.

Was will man denn genau mit FPGAs machen? Welche Daten kommen woher in 
welcher Breite, dass sie eines FPGAs bedürfen?


> Über den Sinn und Unsinn von Bitcoin soll hier nicht diskutiert werden.
Besonders nicht, weil eine Währung, die man mit Rechenleistung selber 
drucken kann, keine wertstabile sein kann :-)

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #4775858:
> Es ist doch vielmehr so, daß Applikationen, die man früher in Hardware
> machen musste, heute dank der CPU-Power eher noch in SW zu machen sind.

Und inzwischen, da die CPUs nicht mehr nennenswert schneller werden, das 
Wachstum eingeht. Kapitalismus braucht Wachstum. Also folgt der Wunsch 
nach Aktualisierbarkeit wie Software, aber Geschwindigkeit wie Hardware, 
insbesondere in Rechenzentren, wo genug Strom vorhanden ist.

Falk B. schrieb:
> Der Knackpunkt ist doch, das macht man in der REALEN (Geschäfts)welt
> nicht zum Selbstzweck, sondern um ordentlich PS auf die Straße zu
> bekommen, sprich RECHENLEISTUNG!!!

Intel hat Altera sicher nicht gekauft, weil's ne coole Firma war. Die 
versprechen sich schon was davon. Und wenn das Militär der einzige 
Abnehmer ist, dann hat sich das für die schon gelohnt. Die sind 
jedenfalls sehr daran interessiert.

> Und wenn da Intel nicht mal in ein richtig fette Demonstation
> hinbekommt und nur ein lahmes Sudoku "präsentiert",
> muss man sich über die ausbleibende Resonanz nicht wundern . . .

Ich bezweifle, dass auf einer simplen Konferenz die fetten Demos 
ausgepackt werden... außerdem ist das schon über ein Jahr her und deren 
Software war da alles andere als ausgereift.

> Vor ein paar Jahren hat man mit FPGA-Gräbern Bitcoins berechnet, heute
> machen das schon lange Spezial-ASICs in 1000er Farmen (u.a. in Island).

ASICs sind kein genereller Ersatz für FPGAs. Und wäre Bitcoin 
rechtzeitig gescheitert, hätte es auch nie ASICs dafür gegeben.

: Bearbeitet durch User
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Denke in Haushalts PCs wird das keinen Einzug erhalten, seit Cuda und 
OpenCL ist der Markt dafür praktisch tot.
Warum sollte man sich auch einen FPGA ans Bein (bzw. an die CPU) binden 
wenn man einfach die ohnehin vorhandene Grafikkarte dafür nutzen kann; 
einfacher zu Programmieren ist die auch noch...

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Weltbester FPGA-Pongo (Gast)

>Es ist doch vielmehr so, daß Applikationen, die man früher in Hardware
>machen musste, heute dank der CPU-Power eher noch in SW zu machen sind.

Jain. Das gilt vielleicht für MP3 Dekodierung etc. aber nicht für . . .

>Ein Beispiel sind die Grafikarten. Viele Anwendungen aus der Ecke
>bedurften früher Spezialchips, heute macht es die CPU nebenläufig mit.

GAAAANZ schlechtes Beispiel ;-)
Nimm mal einem aktuellem PC seine hochspezialisierte Grafikkarte und 
schau mal was dabei rauskommt . . .

Eine GPU ist ein hochspezialisierter ASIC, der aber ggf. auch ein klein 
wenig interdisziplinär arbeiten kann. Aber auch das ist bisher nur ein 
kleines, experimentelles Feld.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ S. R. (svenska)

>Und inzwischen, da die CPUs nicht mehr nennenswert schneller werden, das
>Wachstum eingeht. Kapitalismus braucht Wachstum. Also folgt der Wunsch
>nach Aktualisierbarkeit wie Software, aber Geschwindigkeit wie Hardware,
>insbesondere in Rechenzentren, wo genug Strom vorhanden ist.

Dafür gibt es Multicore CPUs, auch wenn deren Anwendung in der Praxis 
bisher noch suboptimal sind.

>Intel hat Altera sicher nicht gekauft, weil's ne coole Firma war. Die
>versprechen sich schon was davon.

Jaja, Versprechen und Wunschdenken.

> Und wenn das Militär der einzige
>Abnehmer ist, dann hat sich das für die schon gelohnt. Die sind
>jedenfalls sehr daran interessiert.

Auch das ist bisher rein experimentell. Wir reden hier über eine 
massentaugliche Anwendung.

>Ich bezweifle, dass auf einer simplen Konferenz die fetten Demos
>ausgepackt werden...

Wann dann? Mein Gott, gerade die Amis sind doch verkaufs- und 
präsentationaorientiert wie kein Anderer.

> außerdem ist das schon über ein Jahr her und deren
>Software war da alles andere als ausgereift.

Also eine bleierne Ente. Sehr überzeugend. Gähn

>> Vor ein paar Jahren hat man mit FPGA-Gräbern Bitcoins berechnet, heute
>> machen das schon lange Spezial-ASICs in 1000er Farmen (u.a. in Island).

>ASICs sind kein genereller Ersatz für FPGAs.

Hat dau einer behauptet?

> Und wäre Bitcoin
>rechtzeitig gescheitert, hätte es auch nie ASICs dafür gegeben.

Anders herum wird ein Schuh draus. Bitcoin hat sich stabiliesiert und 
etabliert, sodaß sogar ASICs mit "langer Entwicklungszeit" sinnvoll 
wurden.

Also, nicht jammern und bleierne Enten schreicheln, sondern mit 
Killerapplikationen überzeugen! Alles andere sind nur Schlaflieder.

von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Eine GPU ist ein hochspezialisierter ASIC, der aber ggf. auch ein klein
> wenig interdisziplinär arbeiten kann. Aber auch das ist bisher nur ein
> kleines, experimentelles Feld.


Definierem mal "klein" ;-)
Ist schon etwas mehr als "ein klein wenig interdisziplinär" was man 
damit alles machen kann - Physiksimulationen, Neuronale Netze, 
Bildverarbeitung, Videobearbeitung, Statistik, Kryptographie...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Für spezialisierte Anwendungen, die PC-Strukturen erfordern, gibt es 
bekanntlich entsprechende Plattformen, die über entsprechende 
Möglichkeiten verfügen, mehr, als eine CPU aufzunehmen, eine Anzahl von 
PCIe-Karten vertragen und genügend viele Lanes bieten und eben auch 
Grafikkarten beinhalten.

Das gilt sowohl für HPC, Audio und Video als auch besagte Simulations 
und Rechenknechte. Das sind alles spezialisierte Workstations, in denen 
dann passende Karten stecken (gfs mit FPGAs) und die passend 
konfiguriert sind. Das betrifft die Optimierung sowohl in Richtung 
Performance, Noise, Sealing und Power. Beispiele sind Systeme für den 
Betrieb in großer Hitze, in explosionsgefährdeten Bereichen, bzw 
hermetisch abgeschirmte Rechner für Operationsräume oder besonders leise 
Systeme für Tonstudios.

Oft sind das Industrie-PC-Plattformen, Server-Plattformen, die für den 
jeweiligen Anwendungsfall optimiert sind, also in der Niesche sitzen und 
dennoch preislich akzeptabel sind. Das sind aber alles weit und breit 
keine Consumer-Applikationen und um die ging es ja.

von schotter (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Zorg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
schotter schrieb:
> https://www.kickstarter.com/projects/802007522/up-...


Ist der kleinste Typ, das reicht für einfache I/O Geschichten, aber bei 
weitem nicht für die hier in dem Thread diskutierten Dinge. Zumal da 
auch die Bandbreite zur CPU fehlen dürfte ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.