Gibt es eigentlich (schon) FPGAs mit integrierten embedded divider?
Ich habe mal wieder so eine Applikation mit fortgesetzten Berechnungen,
wo ich auf n x Latenz des dividers komme, was sich ganz schön aufbläht.
Ich muss die pipeline Funktion verwenden und den divider mehrfach
nutzen, weil ich sonst viel zu viele davon bräuchte.
Damit habe ich über alle Rechenstufen eine gehörige Latenz, was mir die
Regelungsgeschwindigkeit herabsetzt. Ich hätte das gern etwas schneller.
Gute Frage. Meines Wissens nicht. Allerdings gehe ich davon aus, dass es
die bald gibt, weil es heute keine DSP-Applikation mehr gibt, die nicht
in Real oder VarInt rechnet wo sich einige Divisionen tummeln.
Langfristig wird es die wohl geben schätze ich.
Gibt es eigentlich (schon) FPGAs mit integrierten embedded divider?
Das weiß ich nicht, aber Xilinx mit DSP Slices gibt es. Schaue dir
außerdem den LogiCORE IP Divider Generator an. Pipelined 1div /clock
>Pipelined 1div /clock
Das bedeutet ja nur, dass ein Ergebnis je Takt rauskommt. Die Latzenz
ist trotzdem da, wie auch die Diagramme zeigen. Man kann zwar auf bis zu
8 Takte je Schritt steigern und Resourcen sparen aber ich brauche es
halt in die andere Richtung, als "schneller". Die Latenzen liegen je
nach Divisorbreite auch bei der schnelleren Implementierungsvariante
zwischen der halben und vollen Bitbreite des Eingangsvektors.
Sieht jemand eine Art "look ahead"-Technologie, bei der man unter
verschiedenen Annahmen parallel rechnen kann und Zeit einspart?
Vom Gefühl her müsste es möglich sein, die typische
Teilerimplementierung, die ja immer ein Bit je Takt vergleicht, auf z.B.
4,8 Fälle aufzubohren, die gleich 2,3 Bits vergleicht und Ergebnisse in
die nächste Stufe presst, um dann aufgrund des tatsächlichen Ergebnisses
in der Vorstufe eine Auswahl zu treffen.
Man berechnet also nicht den Rest fürs Weiterrechnen, sondern
unterstellt 4,8 mögliche Versionen und schiebt sie direkt weiter.
Dadurch, dass die Stufen mit Konstanten rechnen, sollten sie sich auch
vereinfachen.
Vom Gefühl her meine ich, dass man ab 3 Bit einen Zeitvorteil erhalten
müsste. Man zieht natürlich den Flächenbedarf hoch, was in gewissen
Grenzen akzeptabel ist.
?
Ja, überlegt schon, aber das liefe auf ein gewaltiges externes RAM
hinaus. Ich brauche mitunter 64 Bit, also wenigstens 32Bit in 2 Stufen
(Restbehandlung). Leider ist die Dynamik sehr hoch und der Wert erst
nach der Division einigermassen "skaliert" d.h. er ist im Rahmen. Vorher
wird schonmal 45 Bit durch 40 Bit geteilt. Der Wert ist z.B. ein
Korrekturwert, der zwischen 0,9 und 1,1 liegt und sehr genau (>16 Bit)
sein muss. In einem anderen Fall ist das Ergebnis sehr gross. Man kann
also nicht vorher einfach die beiden Werte durch Bitwegschneiden
runterskalieren. Oder ich müsste verschiedene Divider bauen und mit
Hinblick auf das Ergebnis wegcutten. Das spart mir nicht wirklich was
ein.
Das Problem ist auch nicht, ob es 30 oder 40 Takte dauert, sondern ob es
4 Takte dauert :-)
Ich probiere es mal mit der Synthese für den Virtex 6 und seine DSPs.
Zieht natürlich wieder Kosten nach sich...
Eine Division schneller als mit einem Bit pro Takt durchzuführen ist
kein Problem und seit langer Zeit im Einsatz. Wie man das macht, wenn
auch falsch, zeigte übrigens Intels berühmter Divisionsfehler beim
Pentium, der 2 Bits pro Takt dividerte. Da war eine dafür verwendete ~1K
grosse Tabelle ein bisschen falsch.
http://de.wikipedia.org/wiki/SRT-Division
Naja, die Frage ist, auf welchen Takt man sich dabei bezieht, wenn man
mehr,als einen Schritt je Takt machen will. Wenn ich in einem FPGA für
die Korrekturen jeweils nochmal ins Blockram greifen muss, habe ich
wieder Laufzeiten und Taktverzögerung, weil das wiederum nicht in einem
Schritt geht. Bei hohen Tatkfrequenzen braucht es dann 2 Takte Latenz
aus dem RAM und es ist nichts gewonnen.
> Teilerimplementierung, die ja immer ein Bit je Takt vergleicht,> auf z.B. 4,8 Fälle aufzubohren, die gleich 2,3 Bits vergleicht und> Ergebnisse in die nächste Stufe presst,
So ähnlich, ja:
Beitrag "Re: Division in VHDL"
Aber Gewinn ich nicht viel zu erzielen. irgendwann wird die Geschichte
dann auch wieder so aufwändig, dass man mit einem gepipelineten CORDIC
besser fährt.
>embedded divider
Die müssten dann wie Multiplier als optimierte Logik auf Transistorebene
laufen. Das brächte sicher einen Faktor 3-5 aber dann stellt sich die
Frage nach der Breite! Divider sind nicht so einfach zu kaskadieren und
wenn solche Viecher irgendwo im FPGA vergraben wären, müsste man auch
wieder dort hin routen und es stellt sich dasselbe Taktproblem, wie bei
den BRAM-Überlegungen oben.
Die Apps, die ich so kenne, die so aufwändige Divisionen haben, werden
meist auf parall existenten DSPs gemacht. Diese Art der Lösung ist als
Silizium erheblich billiger.
