Mit traumwandlerischer Sicherheit hat mein Kollege, ein Design aus einer
anderen Abteilung an Land gezogen, wo die Herren Hardwerker nicht
weiterkommen und es mir zu Bearbeitung gegeben. Ich darf einen ALGO
einbauen, habe aber nur ein Micki-FPGA, das aber bei hoher Bandbreite
arbeiten muss.
Für eine einfache Kennlinienkorrektur benötige ich ich einen Grossteil
des Restplatzes im FPGA, in Worten steigt der Fullgrad von 45% slices
auf 75% und das timing ist kaum einzuhalten.
Der Formeltyp ist so etwa: f(a,b,c,d,e,x) = a+bx+cxx+dxxx+exxxx.
Habe jetzt immer schön mit x multipliziert und die Koeffizienten und
Werte weiterglatched, damit sie zum richtigen Zeitpunkt verknüpft werden
können, musste aber leider die Erfahrung machen, dass die Synthese 3
(Drei!) Zusatzregister hinter jedem Multiplier haben will, wodurch sich
das Ganze enorm in die Länge zieht. Die ganzen mitgeschleppten
Koeffizienten verbrauchen, da 32bit breit enorm Register. Einen muss ich
14 pipe steps mitschleppen.
Wie könnte man das anders lösen?
M. F. schrieb:> Für eine einfache Kennlinienkorrektur benötige ich ich einen Grossteil> des Restplatzes im FPGA, in Worten steigt der Fullgrad von 45% slices> auf 75% und das timing ist kaum einzuhalten.>> Der Formeltyp ist so etwa: f(a,b,c,d,e,x) = a+bx+cxx+dxxx+exxxx.>> Habe jetzt immer schön mit x multipliziert und die Koeffizienten und> Werte weiterglatched, damit sie zum richtigen Zeitpunkt verknüpft werden> können, musste aber leider die Erfahrung machen, dass die Synthese 3> (Drei!) Zusatzregister hinter jedem Multiplier haben will, wodurch sich> das Ganze enorm in die Länge zieht. Die ganzen mitgeschleppten> Koeffizienten verbrauchen, da 32bit breit enorm Register. Einen muss ich> 14 pipe steps mitschleppen.
Die piperegister nicht reseten, dann könnten statt auf FF-Stages auf
SRL16 Macros gemappt werden. Vorausgesetzt Dein FPGA ist ein Xilinx.
Oder aus RAM-Blöcken eine kleine FIFO zum shiften basteln.
MfG
Hallo, ja es ist ein Xilinx S6 und ich resette sie aus resourcen-Gründen
nicht. Ich schaue mal nach, was verwendet wurde. Das mit den BRAMs ist
mir nicht klar, wie Du das meinst.
>Horner-Schema
Nein, ich bin da frei in der Ausgestaltung.
M. F. schrieb:> Hallo, ja es ist ein Xilinx S6 und ich resette sie aus resourcen-Gründen> nicht. Ich schaue mal nach, was verwendet wurde. Das mit den BRAMs ist> mir nicht klar, wie Du das meinst.
aus Block oder distributed ram (dual port) baust du eine Fifo, also
eine seite schreibt rein, die andere liest, der adresscounter beim
shreiben beginnt mit 0, der beim lesen mit 1, die beiden addresscounter
laufen entsprechend der erfordlichen stage-anzahl wieder auf 0. Im
coreGen sollte noch ein shift register aus LUT stecken ->
http://www.xilinx.com/support/documentation/ip_documentation/shift_ram_ds228.pdf
MfG,
Die Info ist zu gring um alles zu erkennen. Der Verbrauch scheint sehr
hoch zu sein.
>>Die ganzen mitgeschleppten Koeffizienten verbrauchen, da 32bit breit enorm >>Register. Einen muss ich 14 pipe steps mitschleppen.
Der Wertebereich der Koeffizienten lässt sich sicher auf 16bit
reduzieren.
Meisten ist eine Bogenlampe in der Kennlinie gerade zu ziehen.
Da können die Koeffizienten keine utopischen Werte annehmen, irgendwo
muss der Sensor einem physikalschen Wirkprinziz gehorchen.
Es lässt sich auch die Kennlinie in mehrere Bereich teilen. Dabei kann
sich die Ordnung deines Polynoms reduzieren. Man hat damit neue
Stützstellen und muss nicht eine Taylorreihe von einem Punkt über die
gesamte Kennlinie zerren.
ja, aber das ändert doch nichts daran, dass ich für jeweils eine
Variable einen FifO brauche und der soviele RAM-Zellen enthalten muss,
wie es pipe stages gibt, also für einige ASpekte z.b. 3-4 für andere
über 10. Das ergibt bei distributed doch genau dieselbe Menge FFs, oder
nicht`?
Ok, ich könnte BRAM nehmen, wenn ich davon mehr über hätte. (hab ich
leider nicht).
M. F. schrieb:> ja, aber das ändert doch nichts daran, dass ich für jeweils eine> Variable einen FifO brauche und der soviele RAM-Zellen enthalten muss,> wie es pipe stages gibt, also für einige ASpekte z.b. 3-4 für andere> über 10. Das ergibt bei distributed doch genau dieselbe Menge FFs, oder> nicht`?>> Ok, ich könnte BRAM nehmen, wenn ich davon mehr über hätte. (hab ich> leider nicht).
Distributed memory ist nicht aus 1bit FF aufgebaut sondern aus LUT-M mit
16 (32) bit je LUT. Also statt 32*10 FF (32 bit stage tiefe 10) 320 die,
da 4 ff pro slice, 80 slices benötigen, brauchts nur noch 8 slices (4
luts pro slice) im Idealfall. Vorausgesetzt deine FF sind wirklich als
simple Schiebekette ohne zwischenabgriff verschaltet.
Die LUT's können als 1 bit schieberegister mit beliebiger Länge zwischen
1 und 16 (32) genutzt werden.
Schau mal im
http://www.xilinx.com/support/documentation/user_guides/ug384.pdf
das Bild auf seite ) und die Erklärung zu distributed RAM ab S. 15 resp
die zu Shiftregister ab S. 25.
Im FPGA gibt es mehrere Alternativen zum (normalen) Slice-FF:
-BlockRAM
-die LUT (als shiftreg oder als Distributed MEM)
-die FF im den IO-Zellen
diese Alternativen lassen sich nicht in jedem Fall einsetzen (asynchrone
Reset) und die 16 (32) bit einer LUT lassen sich nicht gleichzeitig
beschreiben/lesen wie 16 FF eines slices, aber falls es dir wirklich
nur um Verzögerung geht müsstest du etliche FF durch wenige LUTs
ersetzen können.
MfG,
> in Worten steigt der Fullgrad von 45% slices> auf 75% und das timing ist kaum einzuhalten.
Na und wo ist das Problem? 75% sind kleiner als 100% und wenn das Timing
kaum einzuhalten ist, wird es dennoch eingehalten :)
Ralle schrieb:> Hast Du die Möglichkeit, die Kennlinie in einem externen RAM> auszulagern?
Nein, schön wär's.
dagfagr schrieb:> Na und wo ist das Problem? 75% sind kleiner als 100% und wenn das Timing> kaum einzuhalten ist, wird es dennoch eingehalten :)
Es muss noch mehr rein ,,,
M. F. schrieb:> Der Formeltyp ist so etwa: f(a,b,c,d,e,x) = a+bx+cxx+dxxx+exxxx.>> Habe jetzt immer schön mit x multipliziert
Hast Du taktweise jeweils eine Potenz erhöht, um auf Xhoch4 zu kommen? -
So hört sich das an. Damit sparst Du nur Multiplier, erhöhst aber die
Pipeline Länge! Formuliere die Stränge mal komplett parallel und einmal
so, dass der Xhochn noch einen einen Takt mehr Zeit, als der Xhoch n-1
u.s.w. Dann kannst Du quasi-sequenziell über 5 Takte addieren und
brauchst die volle Breite der Vektoren nicht länger, als nötig.
Danke für den Tipp, hat ein bischen was gebracht. Die parallele Lösung
ist etwas kleiner geworden und auch kürzer. Hätte ich gar nicht gedacht.
Rettentut es mich aber nicht. Die Lösung des Problems sieht jetzt doch
so aus, dass nichts mehr eingebaut wird und es in der nächsten
Gerätegeneration einen neuen FPGA geben wird. Einen grösseren natürlich.
M. Fritsch schrieb:> Die Lösung des Problems sieht jetzt doch> so aus, dass nichts mehr eingebaut wird
In der Tat ein interessanter Lösungsansatz: Resourcenschonung durch
Nichtrealisation.
Mal im Ernst: Was spricht dagegen, das FPGA komplett zu füllen? Strom?
Und was ist das für ein Algorithmus, der da nicht mehr reinpasst?
