Könnte mir bitte ein erfahrener FPGA-Entwickler einen Tipp geben, wie man die Rechenleistung eines FPGAs in Zahlen fassen kann, um sie mit Mikrocontrollern zu vergleichen? Angenommen, man baut einen FPGA zu einem SOC System um, müsste sich das doch machen lassen. Dann hätte man schon mal einen Mindestwert, unter der Annahme, dass ein reines SOPC System suboptimal ist für einen FPGA.
Hi Oliver, Ansich gibt's diese Vergleichsmöglichkeit nur an konkreten Beispielen zu Anwendung und Chip-Typ, sowie den Möglichkeiten zur Implementierung (spezifische Algorithmen). Bei einer CPU ist die Angabe MFLOPS meist auch sehr ungenau. Für Matrixoperationen z.B. ist es ohne weiteres möglich, einen Faktor 20 gegenüber einer klassischen i86-CPU hinzukriegen, nur eine Frage der verteilten (parallel arbeitenden) Resourcen. Auch beim SoC baut man sich typischerweise einen Coprozessor für die floating point sachen ran. Meiner Meinung nach lohnt es aber NICHT, einen klassischen Core mit generischem Float-Coproz nachzubauen. Und genau dann würde das FPGA auch gegenüber einem harten IP-Core absolut verlieren. Im Endeffekt entscheidet sich die Frage nach den MFLOPS nach folgenden Gesichtspunkten: - Wie schnell läuft mein Design? - Wieviele parallele Operationen bekomme ich hin (Float-Resourcen)? Danach wählt man sich dann auch meist sein FPGA aus (Anzahl Multiplikatoren, Memory, max. Takt). In einer SoC Anwendung habe ich einen 32-Bit CPU core und einen dedizierten, separaten (synchronen) Rechenknecht bei knapp 100 MHz am laufen. Datendurchsatz ist ca 60 MBs/s, pro Datenwert 25 parallele Ops, macht 25 * 60 = 1500 MFLOPS, wobei es in diesem Fall Fixpoint-Operationen sind. Ich würde tendentiell bei FPGA intern eher mit Fixpoint als Float arbeiten, sofern der Wertebereich absteckbar ist. Hoffe, das hilft Dir weiter.
Oliver schrieb: > Könnte mir bitte ein erfahrener FPGA-Entwickler einen Tipp geben, wie > man die Rechenleistung eines FPGAs in Zahlen fassen kann, um sie mit > Mikrocontrollern zu vergleichen? Erstmal geht das nur, indem eine konkrete Aufgabe gestellt wird. Und auch dann gibt es einige Randbedingungen, die die Ergebnisse stark kippen: Dein Beispiel mit dem softcore ist ein sehr nachteiliges für den FPGA, denn diese Cores sind von der Qualität (pipelining, Multi threading) den aktuellen MCUs unterlegen und auch nicht so schnell taktbar. Zwischen einem Soft-Core mit ALU im Durchschnitts-FPGA, der richtig Mathe rechnen soll und einer ordentlichen PC-Intel-CPU besteht ein Verhältnis von wenigstens 1:10. Die Rechenleistung des FPGA mit softcore ist bestenfalls einige %te! Und nun das gegenteilige Extrem: Eindimensionale iterative Schleifen konstanter Länge, die in Software komplett sequenziell gerechnet werden, können in FPGAs auf die Rechenzeit NULL zusammenschrumpfen, wenn sie in eine Pipeline überführt werden, die dann nur eine Latenz aufweist. Einlesen, Verrechnen und Ausgabe der Daten machen dann nur einige us, das war es. Das ist dann solange unabhängig von der Rechentiefe n (Iterationszahl x Kanalzahl), solange die Bandbreite des FPGA-Kanals nicht erreicht wird. Ab dann muss Architekturverdoppelung (mit Faktor k>n) her, die aber nur in den Fällen funktioniert, in denen die zu prozessierenden Daten unabhängig sind, also z.B. aus parallelen abgetasteten Kanälen stammen oder sich aus gleichen zeitlichen unabhängigen Rechenaufgaben ergeben. Dann kann man das soweit treiben, bis die Grenze der FPGA-Fläche erreicht ist und hat auch dann noch die Rechentiefe NULL + Latenz. In den anderen Fällen sinkt die effektive Bandbreite des FPGAs-Rechenkanals virtuell auf k/n ab. Das geht dann soweit, dass das FPGA irgendwann teilsequenziell arbeiten muss und damit stückweise so langsam wird, wie ein Prozessor. Da die Verarbeitungsgeschwindigkeit im FPGA auch immer ein Teiler der Taktfrequenz ist, geht es dann mindestens mit k/2n , k/3n, k/4n nach unten. Zudem gibt es noch Unsicherheiten bei der Taktfrequenz: Lokal arbeiten FPGAs mit einer maximalen Schaltfrequenz der Gatter / der Sonderlogik abzüglich etwas Routing. Global kommen sie da aber bei Weitem nicht dran. Da kann man auch noch einen Faktor 2 verlieren. Bei 2D-Aufgaben / Iterationen muss zumindest eine Dimension im FPGA voll sequenziell dargestellt werden und dann spätestens verschiebt sich das Verhältnis immer mehr zu Gunsten des Prozessors, bzw. dessen Nachteil wird immer geringer. Ich hatte mal so einen Vergleich für einen Audio-DSP-App gemacht, wenn Dir das was hilft: http://www.96khz.org/oldpages/fpgaadvantage.htm
Thread beobachten
Seitenaufteilung abschaltenBitte 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.