FPGA-Firmware-Design: Wie groß ist zu groß?

Ich habe eine besonders große Signalverarbeitungstransformation, die von Matlab nach VHDL portiert werden muss. Es erfordert definitiv eine Art Ressourcenteilung. Ein bisschen rechnen hat mir folgendes gebracht:

  • 512 ffts mit 64 Punkten
  • 41210 Multiplizieren-Addieren-Operationen

Wenn man bedenkt, dass das größte Virtex 6 FPGA ungefähr 2000 DSP48E-Blöcke hat, weiß ich, dass ich Ressourcen teilen kann, um die Ressourcen mehrmals wiederzuverwenden. Die Ausführungszeit ist nicht wirklich ein Problem, die Verarbeitungszeit kann in FPGA-Begriffen relativ lang dauern.

Wenn ich die Ressourcennutzung betrachte, bekomme ich mit der Radix-2 Lite-Architektur 4dsp-Blöcke/FFT-Operation = 2048 DSP-Blöcke, insgesamt ~43k. Das größte Virtex-FPGA hat 2k-Blöcke oder 20 Operationen/Mux.

Offensichtlich wird das Einfügen solch großer Muxes in den Fabric auch Slices beanspruchen. Wo finde ich das obere Ende dieser Grenze? Ich kann die FPGA-Ressourcen nicht unendlich teilen. Ist 41210 Multiplikatoren zu groß? Wie berechne ich, was zu groß ist?

Ich habe mir auch andere Ressourcen angesehen (Slices, Brams usw.). Radix-2 Lite liefert auch 4 x 18k Brams/fft = 2048 Brams. Das größte Xilinx FPGA enthält 2128 Brams. sehr grenzwertig. Ich mache mir Sorgen, dass mein Design einfach zu groß ist.


AKTUALISIEREN:

Einige weitere Informationen zum Design selbst. Ich kann nicht ins Detail gehen, aber hier ist, was ich geben kann:

Initial conditions -> 512 ffts -> 40k multipliers ---------|----> output data to host 

                 ^------re-calculate initial conditions----|

Ausgabedatenratenspezifikation: "schneller als die Matlab-Simulation"

Rechentechnisch bin ich hier:

FFT-Stufe: einfach. Ich kann 1/2/4/8 FFTs implementieren, die Ergebnisse im SDRAM speichern und später darauf zugreifen. Relativ klein, auch wenn es lange dauert, ist es ok. Mit Radix-2 Lite kann ich 2 DSP48Es und 2 18k BRAMS/FFT erhalten. Streaming ergibt 6 DSP48Es 0BRAMS/FFT. In beiden Fällen ist die 64-Punkt-FFT in Bezug auf die FPGA-Ressourcen klein.

Multiplikatoren : Das ist mein Problem. Die Multiplikationseingaben werden entweder aus Nachschlagetabellen oder FFT-Daten genommen. Es ist wirklich nur eine ganze Reihe von Multiply-Adds. Da gibt es nicht viel zu optimieren. Kein Filter, hat aber ähnliche Eigenschaften wie ein Filter.

Betrachtet man die gemeinsame Nutzung von Ressourcen auf dem FPGA, funktioniert die Mathematik wie folgt: Ein LUT-6 kann als 4-Wege-Mux verwendet werden. Die Formel für einen N-Wege-M-Bit-Mux lautet wie folgt:

N*M/3 = number of luts, or N*M/12 = slices (4 LUTS/slice).

Das Knirschen der Zahlen für meine Implementierung ergibt keine guten Ergebnisse. 90 % der virtix-6-Familie haben nicht genug Slices, um ihre DSPs gemeinsam zu nutzen, um 40.000 Operationen auszuführen.

Die effizienteste Form der gemeinsamen Nutzung von Ressourcen ist die teilweise Serialisierung, bei der Sie auf Daten zugreifen können, indem Sie den Speicher adressieren. Im Extremfall sind Sie natürlich wieder bei einem herkömmlichen Prozessor mit gespeicherten Programmen – das Fehlen harter Leistungsanforderungen deutet allmählich auf die Flexibilität einer Softwareimplementierung hin, die möglicherweise in einer Compute-Cloud ausgeführt wird.
Dies ist nicht Teil Ihrer Frage, aber in Ihrer Ressourcenberechnung haben Sie nicht angegeben, welche Größe der Operand hat. 512 FFTs x 64 Punkte x wie viele Bits? In einem FPGA liegt die Operandengröße ganz bei Ihnen, also müssen Sie sie bei der Berechnung der Größe Ihres Problems berücksichtigen.
Ich weiß nicht, ob Sie es bemerkt haben, aber diese großen FPGAs sind ziemlich teuer. Einige können über $5.000 liegen. Vielleicht sollten Sie das auch in Betracht ziehen, es sei denn, die Kosten spielen keine Rolle.
@ThePhoton: Ich habe den Kerngenerator verwendet, um die FFT-Ressourcennutzung zu schätzen, jede FFT besteht aus 64 Punkten, Festkomma und 32 Datenbits, 24 Phasendaten.
Leider bezweifle ich, dass wir neben den alternativen Lösungsvorschlägen, die Sie bisher in den Antworten erhalten haben, noch viel mehr für Sie tun können. Ich meine, Sie könnten nur einen FFT-Kern bauen und Ihre 512 Eingänge nacheinander durchlaufen lassen, und das würde offensichtlich sogar in ein ziemlich kleines FPGA passen. Irgendwo dazwischen und alles parallel zu tun ist das richtige Gleichgewicht zwischen Geschwindigkeit und Ressourcen für Ihre Anwendung ... aber es ist für niemanden außer Ihnen schwer zu sagen, wo dieses Gleichgewicht sein sollte.
Dies könnte die Art von Idee sein, die man eher im Chat als hier im Q&A-Bereich herumwirft ... aber ich glaube nicht, dass es ernsthafte digitale Gurus gibt, die regelmäßig im Chat sind.
Um die FFT mache ich mir ehrlich gesagt keine Sorgen. Mit etwas SDRAM kann ich die nacheinander durchgeführten FFT-Operationen speichern und die Daten später abrufen. Ich mache mir mehr Sorgen um die ~ 40.000 Multiplikationsoperationen. Bei jeweils 18 Bit und unter der Annahme von 2k-Multiplikatoren müsste ich jeden Multiplikator 20-fach muxen. Ein 20-Wege-18-Bix-Mux benötigt 7 LUT-6 / Bit oder 40 Slices. 40 x 2k = 80k. Gerade klein genug, um in die beiden größten Virtex 6 FPGAs zu passen :/
@StaceyAnneRieck, ich glaube, ich habe nicht verstanden, was Sie mit den Multiplikatoren gemeint haben. Ich dachte, die Multiplikationen wären diejenigen, die für die FFTs benötigt werden.
Ja, wenn ich es mir noch einmal ansehe - es ist ein bisschen zweideutig von meiner Seite. Die FFTs sind zusätzlich zu den Multiplikationsoperationen.
@ThePhoton Ich habe der Frage weitere Details zum Design hinzugefügt.
Haben Sie dafür eine Budgetnummer? Wie Gustavo betonte, sind High-End-FPGAs teuer, ebenso wie die Entwicklung einer Leiterplatte, auf der sie sitzen. Während eine bloße Verdoppelung (oder Vervierfachung oder ...) der Menge an Rechenhardware und die Weiterverwendung des vorhandenen, bewährten (?) Matlab-Codes die angegebene Geschwindigkeitsspezifikation wahrscheinlich erfüllen könnte.
"Ich bin ursprünglich davon ausgegangen, dass der Professor, der die Arbeit über den Algorithmus geschrieben hat, ihn so weit wie möglich optimiert hätte, ..." Können Sie einen Link zu der betreffenden Arbeit bereitstellen?
Wenn Sie eine neue Frage haben, posten Sie sie bitte als neue Frage, geben Sie die erforderlichen Details für die gewünschte spezifische Frage an und stellen Sie eine andere. Die Benutzer werden dies ebenfalls positiv bewerten, und es wird dazu beitragen, dass sich jede Frage auf ein einzelnes technisches Problem konzentriert.
Wenn Sie Multiplikatoreingänge immer in der gleichen Reihenfolge anordnen, können Sie mit Shiftern anstelle von Wide-Input-Muxen davonkommen. D. h., dass das Implementieren, mult_in <= mux[n]wo nin jedem Zyklus um eins erhöht wird, massiv minimiert werden kann.

Antworten (4)

Ich frage mich, ob es eine andere Möglichkeit gibt, das Problem zu betrachten?

Wenn Sie Ihre Schätzung von 512 FFT-Operationen (jeweils 64 Punkte) und 42.000 MAC-Operationen ausspielen ... Ich nehme an, das ist es, was Sie für einen Durchgang durch den Algorithmus benötigen?

Jetzt haben Sie einen FFT-Kern gefunden, der 4 DSP-Einheiten verwendet ... aber wie viele Taktzyklen dauert es pro FFT? (Durchsatz, nicht Latenz)? Sagen wir 64 oder 1 Zyklus pro Punkt. Dann müssen Sie diese 42.000 Mac-Operationen in 64 Zyklen abschließen - vielleicht 1.000 MACs pro Zyklus, wobei jede MAC 42 Operationen verarbeitet.

Jetzt ist es an der Zeit, sich den Rest des Algorithmus genauer anzusehen: Identifizieren Sie nicht MACs, sondern Operationen auf höherer Ebene (Filterung, Korrelation, was auch immer), die wiederverwendet werden können. Erstellen Sie Kerne für jede dieser Operationen mit Wiederverwendbarkeit (z. B. Filter mit unterschiedlichen wählbaren Koeffizientensätzen) und bald werden Sie feststellen, dass zwischen relativ großen Kernen relativ wenige Multiplexer erforderlich sind ...

Ist auch eine Kraftreduzierung möglich? Ich hatte einige Fälle, in denen Multiplikationen in Schleifen erforderlich waren, um Quadrate (und höher) zu erzeugen. Ich entrollte sie und konnte sie iterativ ohne Multiplikation generieren: Ich war an dem Tag, als ich eine Differenz-Engine auf FPGA baute, sehr zufrieden mit mir!

Ohne die Anwendung zu kennen, kann ich keine weiteren Details geben, aber eine solche Analyse wird wahrscheinlich einige wesentliche Vereinfachungen ermöglichen.

Da es sich so anhört, als hätten Sie keine bestimmte Plattform im Sinn, überlegen Sie auch, ob Sie über mehrere FPGAs partitionieren können ... werfen Sie einen Blick auf dieses oder dieses Board , das mehrere FPGAs auf einer praktischen Plattform bietet. Sie haben auch ein Board mit 100 Spartan-3-Geräten ...

(ps Ich war enttäuscht, als die Software-Jungs diese andere Frage schlossen - ich denke, es ist dort mindestens genauso angebracht)

Bearbeiten: Bezüglich Ihrer Bearbeitung - ich denke, Sie fangen an, dorthin zu gelangen. Wenn alle Multiplikatoreingänge entweder FFT-Ausgänge oder "Nicht-Filter"-Koeffizienten sind, sehen Sie allmählich die Art von Regelmäßigkeit, die Sie ausnutzen müssen. Ein Eingang jedes Multiplizierers ist mit einem FFT-Ausgang verbunden, der andere Eingang mit einem Koeffizienten-ROM (BlockRam ist als konstantes Array implementiert).

Durch Sequenzieren verschiedener FFT-Operationen durch dieselbe FFT-Einheit werden die FFT-Ausgänge automatisch an diesem Multiplikator vorbei sequenziert. Das Sequenzieren der korrekten Koeffizienten in die andere MPY-Eingabe ist jetzt "nur" eine Frage des Organisierens der korrekten ROM-Adressen zur richtigen Zeit: ein organisatorisches Problem, eher als ein großes Kopfzerbrechen von MUXen.

Zur Leistung: Ich denke, Dave Tweed war unnötig pessimistisch - die FFT nimmt n * log (n) Operationen, aber Sie können O (n) Butterfly-Einheiten und O (log N) Zyklen oder O (log N) Einheiten und O ( n) Zyklen oder eine andere Kombination, die Ihren Ressourcen- und Geschwindigkeitszielen entspricht. Eine solche Kombination kann die Post-FFT-Multiplikationsstruktur viel einfacher machen als andere ...

Eine FFT, die mit einem einzigen Hardware-Butterfly implementiert ist, wird NlogN Taktzyklen benötigen, um abgeschlossen zu werden; für 512 Punkte wären das 256*8 Schmetterlinge oder 2048 Uhren. Das bedeutet, dass die 41210 (oder 32768?) MACs nur 8-10 Hardware-Multiplikatoren benötigen würden, um in der gleichen Zeit fertig zu werden.
Ich meine, 16-20 Multiplikatoren.
Entschuldigung, ich habe gerade gemerkt, dass ich das falsch verstanden habe. Die individuellen FFTs sind 64 Punkte, so dass die Single-Butterfly-Implementierung 32*5 = 160 Takte erfordert. Die MACs können dann mit 200–250 Hardware-Multiplikatoren durchgeführt werden.
das ist es, was mich stutzig macht. Wie kann xilinx einen Kern entwerfen, der 16k/32k FFTs ausführen kann, die 400k Multiply-Add-Operationen (NlogN) erfordern, und dennoch habe ich Probleme mit meinen 41k? es muss einen Weg geben!
@Dave: Ich glaube, du meinst sicher 160 Multiplikationen, nicht 160 Zyklen? Es gibt nichts, was in einer FFT so von Natur aus serialisiert ist ...
Ein Basis-2-FFT-Schmetterling erfordert 4 Multiplikationen und zwei Additionen. Ich gehe davon aus, dass die vom OP erwähnte "Radix-2-Lite-Architektur" basierend auf den verwendeten Ressourcen in jedem Taktzyklus ein Ergebnispaar erzeugen kann. Das Sequenzieren der Eingangs-/Zwischendaten und Koeffizienten durch die Hardware wird dem Leser als Übung überlassen, ist aber für Pipelining gut zugänglich.

Wenn dieses Problem keine harten Echtzeitbeschränkungen hat und es sich so anhört, als ob es nicht so wäre – Sie möchten nur, dass es „schneller“ läuft, dann scheint es, als wäre es für die Beschleunigung auf einer oder mehreren GPUs ziemlich zugänglich. Es gibt mehrere Softwarebibliotheken, die dies zu einem relativ einfachen Vorschlag machen, und dies wäre um eine Größenordnung einfacher, als direkt zu benutzerdefinierter FPGA-Hardware zu gehen.

Googlen Sie einfach nach „GPU-fähige Bibliothek“ oder „GPU-beschleunigte Bibliothek“, um loszulegen.

Interessanterweise erwähnte ich GPUs gegenüber dem Kunden, als ich von diesem Projekt hörte, und er war nicht interessiert.
@StaceyAnneRieck: Hat er gesagt warum?
Er sagte nicht wirklich warum, nur dass er sich damit befasst hatte, bevor die Verwendung eines FPGA anscheinend weniger Arbeit zu sein schien. Ich muss es nochmal hochholen.
@stanri: Selbst wenn Sie letztendlich in einer FPGA-Implementierung landen, scheint mir, dass die GPU eine gute Möglichkeit ist, die gesamte Systemarchitektur zu "Breadboard" zu machen. Haben Sie eine Art High-Level-Datenflussdiagramm für den Algorithmus (und könnten Sie es teilen?), und können Sie uns eine Vorstellung von der Menge der beteiligten Daten geben? Ohne Antworten auf Fragen wie diese wird es wirklich schwierig sein, Ihnen etwas anderes als sehr allgemeine Ratschläge zu geben.
Es ist eigentlich ein sehr, sehr einfacher Algorithmus, es ist nur die Größenordnung, die ihn so kompliziert macht. Im Grunde wie folgt: Anfangsbedingungen -> 512 ffts parallel -> 32768 Multiplikationsoperationen am FFT-Ausgang -> Anfangsbedingungen anpassen -> spülen und wiederholen
Die Tatsache, dass dieselbe FFT -> Multiplikator-Schleife wiederholt auftritt, macht diese spezielle Implementierung besonders geeignet für ein FPGA, jedoch nur, wenn das Design passt.
Das bedeutet, dass Sie für jede Iteration des Algorithmus 512 * 32 * 5 = 81920 Schmetterlinge ausführen müssen. Wenn Sie ein FPGA beispielsweise mit zwei Hardware-Schmetterlingen und einem MAC zusammenstellen, könnten Sie eine Iteration mit etwa 40000 Taktzyklen oder 4 ms bei einem konservativen Takt von 100 MHz abschließen. 32 Schmetterlinge (eine Iteration einer vollständigen Reihe einer FFT) und 16 MACs würden dies in 2560 Taktzyklen erledigen. Wie breit sind die Datenworte? Ob Sie in externen Speicher puffern müssen oder nicht, bestimmt, wie weit Sie die Leistung praktisch steigern können.
Auch dies klingt nach einer wirklich guten Passform für die GPU-Beschleunigung.

Wie wenig stört uns die Ausführungszeit?

Dies scheint wirklich eine Situation zu sein, in der Sie wirklich eine Soft-MCU, ein FPGA mit einer integrierten Hard-MCU oder sogar ein separates MCU-Gerät implementieren und alle Ihre Operationen serialisieren sollten.

Vorausgesetzt, Sie haben die Ausführungszeit, ist das Ausführen Ihrer FFTs in Software sowohl viel einfacher zu debuggen als auch wahrscheinlich viel einfacher zu entwerfen.

Schwere Berechnungen in einer Softcore-CPU auf einem FPGA durchzuführen, ist albern; Wenn Sie die Berechnung in einer gespeicherten Programmarchitektur durchführen (was in Betracht gezogen werden sollte), sollten Sie sie auf Hochleistungs-/Dollar-Festplatten-CPUs ausführen, bei denen Sie nicht die Geschwindigkeitsstrafe flexibler Logik gegenüber vergleichbarer Leistung zahlen müssen. Generation harte Logik.
@ChrisStratton - Guter Punkt. Dazu einen zusätzlichen Hinweis hinzugefügt.
Selbst die eingebauten Hard-CPUs werden konventionellen Prozessoren/GPUs für softwarebasierte Aufgaben nicht das Wasser reichen und drastisch mehr kosten.
@ChrisStratton - Ich dachte, die gängigsten integrierten Hart-CPU-Architekturen wären entweder ARM oder POWER? In diesem Fall handelt es sich im Grunde um eine Commodity-CPU.
Nicht von der Art, die jemand für eine rechengesteuerte Aufgabe verwenden würde. Ich weiß nicht, ob Amazon Details über die Hardware veröffentlicht, die sie für ihre Compute Cloud kaufen, aber eine solche Installation (gemeinsam oder privat) wird eine sorgfältige Abwägung der Schnittmenge von Leistungssteigerungen in den neuesten Angeboten, Anschaffungskosten und Leistung sein Betriebskosten. Eine CPU, die in eine Ecke eines FPGA-Dies gesteckt wird, wird in Bezug auf Kosten oder Leistung nicht annähernd das erreichen, was Sie tun können, wenn Sie sich aussuchen, was der drastisch größere Allzweck-Computing-Markt an einem bestimmten Tag zu bieten hat.
@ChrisStratton - Ich denke, wir denken an radikal unterschiedliche Rechenskalen. Wenn Sie viel Crunch wollen (z. B. eine moderne GPU oder X86-CPU), liegen Sie richtig, dass Sie einen separaten Prozessor benötigen. Ein System zu entwerfen, das solche Prozessoren verwendet, wird jedoch äußerst schwierig und unmöglich sein. Wenn Sie so viel Crunch brauchen, ist es besser, einfach einen Desktop-PC zu kaufen und Ihr FPGA-Gerät zu einer PCIe-Karte zu machen.
Ich sage, dass die Ausführungszeit kein Problem ist, weil ich keine Daten über das FPGA streame, sondern sie auf dem FPGA erzeuge. Derzeit dauert die PC-Implementierung Stunden. Leider sind GPU oder CPU hier keine Option, der Kunde besteht auf FPGA.
Ich weiß nicht, was ich dir dann sagen soll. Es hört sich so an, als wäre Ihr Projekt ideal für eine GPGPU-Implementierung geeignet. Ist Ihr Kunde völlig widerspenstig?
Angesichts Ihrer anderen FPGA-Frage ist der Aufbau des FPGA-Boards wahrscheinlich eine Lernerfahrung, die einiges mehr kosten wird als geschätzt. Ich denke, an dieser Stelle wäre es an dieser Stelle, dem Kunden einige harte Preis-/Leistungszahlen aus Probe-Compute-Cloud-Läufen (die schließlich zu gekaufter Hardware werden könnten) zu geben, im Vergleich zu einer Vorstellung vom höheren Preis und dem viel höheren Risiko des FPGA-Aufwands .

Es ist möglich, eine spezielle Hardware oder ein FPGA (oder sogar ein CPLD) zu verwenden, um bestimmte Arten von mathematischen Operationen stark zu beschleunigen. Wenn Sie versuchen, Hardware (Schaltkreise oder FPGA-Logik) zu entwerfen, um mathematische Operationen zu beschleunigen, müssen Sie unbedingt herausfinden, welche Auftragsdaten in Ihr Gerät ein- und ausgehen müssen. Ein Gerät mit einem effizienten E/A-Layout bietet möglicherweise eine viel bessere Leistung als eines mit einem ineffizienten Layout, selbst wenn das letztere Gerät viel mehr Schaltungen erfordert.

Ich habe nicht versucht, ein hardwareunterstütztes Design für eine FFT auszuarbeiten, aber eines, das ich mir angesehen habe, ist die Hardwareunterstützung für große Multiplikationsoperationen (wie sie für die RSA-Verschlüsselung verwendet werden könnten). Viele Mikrocontroller, selbst solche mit spezieller Schnellmultiplikationshardware, sind bei solchen Operationen nicht besonders effizient, da sie eine Menge Register-Shuffling erfordern. Hardware, die entwickelt wurde, um das Austauschen von Registern zu minimieren, könnte mit multipräzisen Multiplikationsoperationen eine viel bessere Leistung erzielen, selbst wenn die Hardware selbst nicht so ausgefeilt wäre. Zum Beispiel kann Hardware, die eine 16xN-Multiplikation im Pipeline-Verfahren mit jeweils zwei Bits gleichzeitig durchführen kann (Verschieben von zwei unteren Bits von Multiplcand und Herausschieben von zwei oberen Bits des Ergebnisses), eine bessere Leistung erzielen als Hardware, die eine 8x8-Multiplikation in einem Zyklus durchführen kann. obwohl erstere möglicherweise weniger Schaltkreise benötigen (und aufgrund von Pipelining einen kürzeren kritischen Datenpfad haben). Der Schlüssel liegt darin, herauszufinden, wie die „innere Schleife“ des erforderlichen Codes aussehen wird, und herauszufinden, ob es Ineffizienzen gibt, die leicht beseitigt werden können.

Welche Arten von Operationen eignen sich besonders für diese Form der Optimierung? Ich habe die obige Frage bearbeitet, um etwas mehr über die Art der Multiplikationsoperation zu erfahren. Hardware-unterstütztes Design klingt wirklich interessant!