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: > Habe jetzt immer schön mit x multipliziert und die > Koeffizienten und Werte weiterglatched, Ist damit das Horner-Schema gemeint?
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 :)
Hast Du die Möglichkeit, die Kennlinie in einem externen RAM auszulagern?
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?
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.