Wieviele MFLOPs sind realistisch?

> 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