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.
?
Ich weiß ja nicht, welche Bitbreiten Du hast und wie variabel Divisor und Dividend sind. Ggf. bietet sich eine Lookup-Tabelle an. Duke
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.
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.