Wann und wie werden Steuer- und Datenpfade für Hardwaredesigns getrennt?

Müssen wir bei der Hardwareprogrammierung immer Steuer- und Datenpfad trennen? Gibt es Vorteile? Wenn ja, was ist die grundlegende Methodik für diese Strategie? Ich versuche, eine SDHC-Karte mit FPGA zu verbinden und bin verwirrt bei der Implementierung des Protokolls mit separaten Daten- und Steuerpfaden.

Es hängt alles von Ihrer Anwendung ab...

Antworten (1)

Ja, Sie sollten diese beiden Teile in Ihren Entwürfen immer trennen.
(Übrigens würde ich nicht von diesen beiden sprechen, wenn wir über einfache Module sprechen.)

Die Aufteilung von Datenpfad und Steuerung hat folgende Vorteile:

  • bessere Wartbarkeit
    • Der Datenpfad ist leichter zu verstehen, da es sich um einen Fluss- / gerichteten Graphen handelt
    • FSMs sind leichter zu verstehen, da sie nicht mit Daten überfüllt sind
  • "schnellere" Entwicklung
    • Delegieren Sie die Entwicklung an mehrere Entwickler
    • Datapath-Module können in demselben oder in anderen Projekten wiederverwendet werden.
      Wenn beide miteinander verflochten sind, ist ein Datenpfadmodul nicht universell und verbietet die Wiederverwendung von Code/Modul
  • bessere Prüfbarkeit
    • Testen Sie Datenpfadmodule unabhängig von der Steuerung
    • Teststeuerung (hauptsächlich ein oder mehrere FSMs) unabhängig voneinander
    • Verwenden Sie Dummy-Architekturen im Datenpfad, während Sie die Berechnung des Hosting-Moduls testen

Die Aufteilung von Datenpfad und Steuerung impliziert auch die Aufteilung von Teilen der Steuerung in Untersteuereinheiten wie Unter-FSMs, Zähler, ...

Always ist stark übertrieben, es kann durchaus triftige Gründe geben, beides zu kombinieren. Stellen Sie sich etwas wie einen Xilinx-IP-Block vor, in der 7er-Serie haben diese tendenziell AXI IO, das Benutzerdaten enthalten kann, die gerade durchgereicht werden (mit der richtigen Latenz, um der Latenz des Kerns zu entsprechen), kann dies ein RIESIGER Gewinn sein Dies bedeutet, dass Sie die Pipeline-Latenzen nicht erneut berücksichtigen müssen, wenn Sie den Kern neu konfigurieren. Es erschwert jedoch die Trennung von Steuerung und Daten, aber manchmal lohnt es sich, dies in einer weitgehend datenflussgesteuerten Anwendung zu tun.
In Ihrem Beispiel handelt es sich bei den Steuerinformationen tatsächlich um Daten, die verzögert werden. Der IP-Core interpretiert solche Daten nur verzögert.
Mein Punkt ist, dass Sie normalerweise möchten, dass Kontrollübergänge die Datenverzögerungen respektieren, und dass es ein großer Gewinn sein kann, sie zusammenzuschreiben, damit Sie die in die IP-Kerne integrierten Verzögerungsketten verwenden können (und somit automatisch die Latenzen anpassen). Ich werde nervös, wenn Arbeiten wie Always zur Beschreibung von Designansätzen verwendet werden, weil es normalerweise Ausnahmen gibt und die absolute Einstellung zu solchen Dingen eine Reihe von manchmal nützlichen Optionen entfernt.
Beeinflusst diese Aufteilung auch die Hardware-Implementierung oder -Synthese?
Nicht wirklich, es ist ein Programmier- und Designstil.
Wann und wie werden Steuer- und Datenpfade für Hardwaredesigns getrennt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v