Moin, fuer ein Projekt brauche ich floating point Berechnungen und zwar ne ganze Menge. Allerdings ist der Algorithmus verhaeltnismassig simpel (soll eine gradient-descent-Identifikation einer 3x3 Homography werden), so dass ich ueberlegt habe, ob es statt mittels eines normalen Rechners auch embedded mit einem FPGA umsetzbar waere. Letztendlich waere es einfach nur eine sehr haeufige Berechnung einer Matrix-Vektor-Multiplikation. Wieviele MFLOPs sind denn realistisch mit einem FPGA, beispielsweise einem grossen SPARTAN, umsetzbar? Vielen Dank und Gruss, Joern
Im Datasheet zum Xilinx Floating-Point Operator findest du ausführliche Benchmarks: http://www.xilinx.com/products/ipcenter/FLOATING_PT.htm Wenn es um 0815-Vektormultiplikationen geht, dann würde ich aber keinen großen Vorteil gegenüber DSPs erwarten, die sind schließlich genau dafür optimiert.
> Letztendlich waere es einfach nur eine sehr haeufige > Berechnung einer Matrix-Vektor-Multiplikation. Wie gut parallelisierbar? Darauf kommt es bei FPGAs entscheidend an.
@Morin Das Ganze ist hochparallelisierbar. Letztendlich geht es um die Berechnung eines Fehlerfunktionals zur Optimierung des Reprojection-Errors. Dabei werden ungefaehr 20 bis 30 Punkte mit der vermuteten Homographie abgebildet und mit den tatsaechlichen Positionen verglichen. Im Prinzip lassen sich all diese Projektionen parallel machen und jede einzelne ist als Matrix-Vektor-Multiplikation selber parallelisierbar. Allerdings kann ich mir nicht vorstellen, dass die Parallelisierbarkeit wirklich so eine Rolle spielt, da das nur bei unbegrenzten Resourcen der Fall ist. Bei floating-point-Operationen sollte die Begrenzheit, beispielsweise der zur Verfuegung stehenden Multiplizierer eine sehr grosse Rolle spielen. @Andreas Danke, der Floating-Point-Operator ist bestimmt hilfreich. Ich hatte ihn auch schon gefunden, fragte mich aber, wieviele ich von denen wohl untergebracht bekomme und wie der Durchsatz ist (es ist nur ne Latency gegeben, kann man mit jedem Takt ne neue Operation starten?) Gegen DSP spricht, sich da wieder auf einer neuen Platform ganz von neuem einarbeiten zu muessen. Auch hoffte ich, dass ein so reduzierter Algorithmus vielleicht wirklich deutlich schneller auf einem FPGA liefe. Gruss, Joern
Was Du machen kannst - und was meiner Meinung das Sinnvollste ist - ist viele Pipelines paralell zu schalten. Du macht eine FP Operation also nicht in einem Takt (was auch gar nicht geht) sondern unterteilst sie in z.B. 10 Takte. In jedem Takt wird ein kleiner Teil der Gesammtoperation durchgeführt. Danach wird das Ergebnis zur nächsten Stufe gereicht. Damit ist die vorherige Verarbeitungsstufe frei und kann schon den nächsten Wert entgegennehmen. Damit erreichst Du dann virtuell pro Takt eine Operation. (Mit einer Latenz die der Länge der Pipeline entspricht.) Das ganze kannst Du dann noch paralell machen. Eine andere Option ist eine Alu zu bauen die kein Pipelinekonzept hat sondern z.B. 10 Takte pro Operation braucht. Davon kann man dann noch mehr paralell schalten weil sie weniger Resourcen braucht. Welches Konzept man benutzt kommt am Ende wohl darauf an wie viel Daten man paralell verarbeiten kann. Wenn man nur 20 Operationen pro Zeiteinheit hat lohnt es sich eher die Operationen schneller zu machen weil es nichts bringt wenn man auch 200 bearbeiten könnte was man aber nicht kann weil man die Daten einfach nicht hat. Wenn hingegen 2000 Operationen pro Zeiteinheit zu erledigen sind kann es durchaus besser sein die 2000 Operationen alle parallel zu erledigen - auch wenn es dann länger dauert. (Um beim Beispiel zu bleiben: Zwei Architekturen - die erste kann pro Takt 20 Operationen erledigen, die zweite 2000 Operationen in zehn Takten. Für die 2000 Operationen brauchst Du mit er ersten Variante 100 Takte, bei der zweiten aber nur 10.) Viele Grüße, Martin L.
Danke, nun hatte ich nur im schlimmsten Falle vor, die Floating-Point-Operationen selbst zu implementieren. Statt dessen wuerde ich gern das Xilinx Floating-Point Operator IP verwenden. (Ist ja letztendlich auch unwahrscheinlich, dass einem selbst eine gluecklichere Implementierung gelingt als den Jungs, die da an der Quelle sitzen.) Entsprechend fragte ich mich, in wie weit dieser Operator pipelinebar ist. Er benutzt Handshaking und ein Logik-Diagramm im Datenblatt legt nahe, dass er pipelinebar ist, allerdings nicht mit jedem einzelnen Takt. Das und die Frage, wieviele man von denen so auf einem Spartan unterbringen kann (Teilweise nutzen die die vohandenen Multiplier, koennen die aber auch selbst aus Logik erzeugen) interessiert mich. Davon haengt dann auch ab, ob man eine Matrix-Vektor-Multiplikation vollstaendig parallel abarbeiten kann (wenngleich hier pipelining sicherlich auch Sinn macht.). (waeren 9 Floating Point Multiplikationen und 9 Additionen, mit anschliessender Normierung eine zusaetzliche Division) Gruss, Joern
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.