Wann treten in Pipeline-Architekturen strukturelle Gefahren auf?

Ich suche nach relativ einfachen Beispielen dafür, wann strukturelle Gefahren in einer Pipeline-Architektur auftreten.

Das einzige Szenario, an das ich denken kann, ist, wenn während verschiedener Phasen der Pipeline (dh der anfänglichen Befehlsabrufphase und der späteren Speicherlese- / Schreibphase) auf den Speicher zugegriffen werden muss.

Ich denke, dass komplexere Architekturen wie Superskalar viel mehr strukturelle Gefahren bergen. Wird es als strukturelle Gefahr eingestuft, wenn eine Anweisung an eine Ausführungseinheit gesendet wird, sich jedoch in einer Warteschlange befindet, weil die Einheit verwendet wird?

Wenn dies sehr architekturspezifisch ist, nehmen Sie einfach MIPS oder ähnliches an.

In einer skalaren Implementierung kann eine strukturelle Gefahr bestehen, wenn bestimmte Ausführungshardware nicht vollständig per Pipeline übertragen wird. Für einige Operationen (z. B. Multiplikation und insbesondere Division) werden die Kosten für die Implementierung einer vollständigen Pipeline möglicherweise für die erwartete Häufigkeit der Operation nicht als sinnvoll angesehen.

In einer superskalaren Implementierung kann eine strukturelle Gefahr bestehen, da nicht jede Ausführungseinheit jede Operation ausführen kann. Beispielsweise wäre die Unterstützung des Initiierens der Ausführung von vier Speicheroperationen oder vier Multiplikationen in jedem Zyklus relativ teuer, wenn sie auf ein vierfaches Problem beschränkt wäre, da wahrscheinlich eine andere Art von Operation verfügbar ist.

Die Grenzwerte für das Lesen und Schreiben von Registerdateien können auch strukturelle Gefahren mit sich bringen. Obwohl es möglich ist, genügend Lese- und Schreibports bereitzustellen, um den schlimmsten Fall zu unterstützen, können die Kosten für Registerdatei-Ports, um den schlimmsten Fall zu erfüllen (selbst mit dem Vorteil der Designkomplexität, dass keine Ausnahmefälle speziell behandelt werden müssen), als nicht wert angesehen werden die Vorteile, wenn die schlimmen Fälle ausreichend selten oder unkritisch sind. Beispielsweise verwenden einige Implementierungen außerhalb der Reihenfolge die Operandenerfassung (Abrufen von Operanden, die zwischen dem Zeitpunkt, zu dem die Operation in den Scheduler eintritt, und dem Zeitpunkt, zu dem sie ausgeführt werden soll, verfügbar werden) und bieten weniger Registerleseports als für eine Operation mit voller Breite erforderlich (unabhängig davon, ob Operanden) früher verfügbare werden gelesen, wenn die Operation in den Scheduler eingeht oder wenn die Operation zur Ausführung geplant ist).

(Selbst für eine Implementierung in der richtigen Reihenfolge könnten die Weiterleitung von Ergebnissen und die Verwendung von Operationen mit einem einzelnen Registerquellenoperanden die Unterstützung von vier Registerleseports für Zweiwegeprobleme weniger erforderlich machen.)

In ähnlicher Weise wird Banking häufig für Caches verwendet (und wurde für Registerdateien vorgeschlagen). Im allgemeinen Fall ist es beispielsweise unwahrscheinlich, dass zwei Zugriffe von 16 Banken derselben Bank zugeordnet werden. Bankspeicher sind wesentlich günstiger als das Hinzufügen von Zugangsports. Das Potenzial für Bankenkonflikte stellt eine strukturelle Gefahr dar.