Pipeline vs. Parallelität

Sie haben ein Modul, das die Daten mehrmals hintereinander verarbeiten muss, um die Konvertierung abzuschließen. In dem „pipelined“-Beispiel füttern Sie einfach alle nacheinander. Dies hat eine gewisse Latenz, da die Daten einige Zeit brauchen, um von der Eingabe zur Ausgabe zu gelangen. Wenn die Blöcke jedoch wirklich per Pipeline verarbeitet werden, ist dies nur eine Latenz - Sie können bei jedem Zyklus ein neues Datenwort einspeisen, und es werden an jedem beliebigen Punkt mehrere Abtastungen in der Pipeline-Phase vorhanden sein, die am Ende den gleichen Durchsatz ermöglichen.

Ihr "paralleler" Fall ist nicht wirklich ein paralleler Fall. Es ist im Grunde der gleiche Pipeline-Fall, aber anstatt sie nacheinander zu kleben, erhalten Sie am Ende zusätzliche Logik, um die eingehenden Daten an jeden Block zu verteilen, und dann hat vermutlich jeder Block mehr Logik, um seine Ausgabe genügend oft durch sich selbst zu führen die Umstellung abschließen. Am Ende musst du sie dann alle neu kombinieren. Es ist im Grunde eine hässliche Methode, eine Pipeline-Berechnung durchzuführen.

Ich bin mir nicht sicher, woher Sie die Idee haben, dass Ihre Pipeline 2,4,8,16 Einheiten haben muss? Wenn Sie die Daten 7 Mal durch das Modul verarbeiten müssen, würden Sie einfach 7 hintereinander in die Pipeline stecken - jeder arbeitet mit dem Ausgang des letzten, sodass es keine Rolle spielt, ob es sich nicht um eine Zweierpotenz handelt .

Eine wirklich parallele Version wäre eine, bei der die Berechnung in Teiloperationen aufgeteilt werden kann. Angenommen, Sie wollten zwei 16-Bit-Zahlen multiplizieren, hatten aber nur einen 8x8-Multiplikatorblock, der einen Taktzyklus benötigt, um abgeschlossen zu werden. Sie könnten 4 in Reihe stecken und eine gewisse Akkumulation haben (dies wäre eine Pipeline-Operation), oder Sie könnten mehrere Instanzen des Multiplikators hinzufügen und sie parallel schalten. Parallel hätte das Ergebnis eine Latenz von 1 Taktzyklus, in Pipeline-Verarbeitung (seriell) hätte es eine Latenz von 4 Zyklen. Dies geht auf Kosten der Verwendung von 4-mal so viel Logik.

Ein weiteres Beispiel für echtes paralleles Verhalten ist, wenn Sie mehrere Wörter gleichzeitig und schneller verarbeiten müssen, als ein Block verarbeiten könnte. Angenommen, Sie hätten einen Block, der ein Datenwort nahm und es verschlüsselte. Der Baustein kann in jedem Taktzyklus nur ein Wort an seinem Eingang verarbeiten. Was ist nun, wenn Ihr eingehender Datenstrom aus vier Wörtern besteht, die alle im selben Taktzyklus ankommen, Ihr Verschlüsselungsblock jedoch nur jeweils eines verarbeiten kann. Der Durchsatz des Verschlüsselungsmoduls beträgt 1/4 dessen, was erforderlich ist. Wenn Sie nun vier Blöcke parallel schalten, können Sie jetzt jedes der vier Wörter gleichzeitig verarbeiten, was den erforderlichen Durchsatz ermöglicht - wiederum auf Kosten des vierfachen Bedarfs an Logik.

Es gibt einen Fall, in dem der zweite Ansatz tatsächlich gerechtfertigt ist. Angenommen, Sie müssen jedes Wort 8 Mal durch die Berechnungsphase verarbeiten, aber aufgrund der Größe der Berechnung haben Sie im FPGA nur Platz für beispielsweise 3 Durchgänge, dann bräuchten Sie eine Möglichkeit zur Wiederverwendung von Ressourcen. Sie versuchen, die Berechnung zu unterbrechen, um weniger Blöcke zu verwenden.

In dieser Situation ist es ziemlich vorteilhaft, eine Logik zu haben, um mehrmals durch denselben Block zu koppeln. Auf diese Weise können Sie dasselbe Modul wiederverwenden und so viel weniger Logikressourcen zur Verarbeitung der Berechnung verwenden. Dies geht jedoch zu Lasten des Durchsatzes. Wenn Sie dasselbe Datenwort 8 Mal durch denselben Block führen müssen, reduziert sich Ihr Durchsatz auf ein Achtel, da währenddessen keine neuen Wörter in den Block gelangen können.

Wenn Sie Platz für zusätzliche Blöcke (z. B. 3) haben, können Sie die Berechnung parallel für drei Datenwörter gleichzeitig durchführen. Sie instanziieren drei Kopien Ihrer Einzelblockschaltung und fügen zusätzliche Logik hinzu, um zu bestimmen, wann es Zeit für ein neues Wort ist, in jeden der Blöcke einzutreten. Dies wiederum gewinnt etwas Leistung zurück - es sind jetzt 3/8 von dem, was es war.

Ich kann die Antwort bei Bedarf mit einigen Diagrammen aktualisieren, aber hoffentlich ist die Erklärung ziemlich klar.

Mit einfachen Worten, eine einzelne Pipeline wird nur EINE Sache auf einmal tun. Wenn Sie Module in Reihe haben, muss jedes Modul warten, bis das vorherige Modul abgeschlossen ist.

Da alle Schritte identisch sind, ist dies nur ein Problem, bis die Pipeline voll ist.

Wenn es parallel gemacht wird, wird diese anfängliche Strafe negiert.

Hier sind die Unterschiede, die mir einfallen (nachdem ich die Frage geschrieben und gemäß den Kommentaren bearbeitet habe):

Die parallele Version benötigt mehr Logik (Multiplexer), um die Eingabe zu versenden und zu verfolgen, wie oft die Daten bereits durch das Modul gegangen sind.

Aber die parallele Version unterstützt auch eine beliebige* Anzahl von "Step-Modulen" (z. B. 7 von 9), während die Pipeline nicht so flexibel ist (streng abhängig von den Anforderungen des Algorithmus).

*Wenn man bedenkt, dass mein Algorithmus 8 Schritte benötigt , aber mein FPGA vielleicht nur Platz für 7 (oder 9) Schrittmodule hat, kann ich 7 (oder 9) parallele Versionen machen und der Durchsatz wird entsprechend erhöht.