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.
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.
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... ;-)
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.
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"...).
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.
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..
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 :-)
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.
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...
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.
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.
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.
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.
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
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 :-) )
>> 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.
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...
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.
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.
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.
@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 . . .
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...
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.
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.
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
;)
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.
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.
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.
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.
@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.
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 :-)
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.
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...
@ 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.
@ 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.
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...
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.
