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.
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..
https://www.heise.de/newsticker/meldung/Intel-Xeon-Prozessoren-bald-mit-programmierbaren-FPGAs-von-eASIC-2647823.html https://www.heise.de/newsticker/meldung/IDF-Die-Zukunft-von-Altera-FPGAs-bei-Intel-3300092.html
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.
:
Bearbeitet durch User
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 ;)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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 ;-)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.