Ich verwende einen Freescale PowerPC Mikrocontroller. Beim Flash-Speichermodul im Datenblatt ist die Anzahl der „Wartezustände des Flash-Speicherzugriffs“ konfigurierbar.
Das Folgende ist der Teil des Datenblatts, der meine Frage aufgeworfen hat, er stammt aus der Registerbeschreibung der PFlash-Modulregister:
Dieses Feld muss auf einen Wert gesetzt werden, der der Betriebsfrequenz des PFlash und der tatsächlichen Lesezugriffszeit des PFlash entspricht. Höhere Betriebsfrequenzen erfordern Einstellungen ungleich Null für dieses Feld für einen ordnungsgemäßen Flash-Betrieb.
0 MHz, < 23 MHz, erforderliche Wartezustände = 0 ---
23 MHz, < 45 MHz, erforderliche Wartezustände = 1 ---
45 MHz, < 68 MHz, erforderliche Wartezustände = 2 ---
68 MHz, < 90 MHz, Wartezustände erforderlich = 3 ---
(PFlash ist ein Plattform-Flash-Controller-Modul)
Ich verstehe, dass der Prozessor schneller als der Flash ist, deshalb werden Wartezustände eingeführt. Was ich nicht verstehe, ist: Wenn der Prozessor schneller als Flash ist, muss der Prozessor verlangsamt werden, nicht der Flash, aber der obige Absatz sagt das Gegenteil (oder habe ich das nicht verstanden?), es sagt, wenn der Pflash mit hohen Frequenzen betrieben wird, müssen wir ihn verlangsamen, indem wir ihm zusätzliche Wartezustände hinzufügen !!
Was ist falsch an meinem Verständnis?
Vielen Dank
Um Stevenvhs Antwort zu verstärken, benötigt jede Art von Logik, wenn sie ein Eingangssignal erhält, einige Zeit, um ein Ausgangssignal zu erzeugen. Speicher ist im Vergleich zu anderer Logik oft sehr langsam. Oft gibt es eine Garantie, dass das Ausgangssignal innerhalb einer bestimmten Zeit gültig wird, aber das war es auch schon. Insbesondere ist es möglich, dass sich das Signal innerhalb dieses Intervalls mehrmals ändert, und es gibt vor dem Ende dieses Intervalls keinen Hinweis darauf, dass das Signal seinen endgültigen "richtigen" Wert erreicht hat.
Wenn ein typischer Mikrocontroller oder Mikroprozessor ein Byte (oder ein Wort oder eine beliebige Einheit) des Speichers liest, generiert er eine Adresse und betrachtet einige Zeit später den vom Speicher ausgegebenen Wert und reagiert darauf. Zwischen dem Zeitpunkt, zu dem die Steuerung die Adresse generiert, und dem Zeitpunkt, zu dem sie den Wert aus dem Speicher betrachtet, spielt es keine Rolle, wann oder ob sich die Ausgangssignale aus dem Speicher ändern. Wenn sich andererseits das Signal aus dem Speicher nicht auf seinen endgültigen Wert stabilisiert hat, wenn der Controller es betrachtet, liest der Controller den Speicher fälschlicherweise so, als hätte er den Wert gehalten, der in dem Moment ausgegeben wurde, in dem er es betrachtete. Normalerweise würde der Controller den Wert aus dem Speicher sehen, sobald er bereit wäre, etwas damit zu tun, aber wenn der Wert des Speichers dann nicht bereit wäre, könnte das nicht funktionieren. Folglich, Viele Controller haben die Möglichkeit, etwas länger zu warten, nachdem sie bereit sind, Daten aus dem Speicher zu verarbeiten, um sicherzustellen, dass die Ausgabe aus dem Speicher tatsächlich gültig ist. Beachten Sie, dass das Hinzufügen einer solchen Verzögerung die Dinge verlangsamt (der Controller hätte gerne früher auf die Daten aus dem Speicher reagiert), aber die Korrektheit des Betriebs nicht beeinträchtigt (es sei denn, die Dinge werden so sehr verlangsamt, dass andere Timing-Verpflichtungen nicht erfüllt werden können).
Wartezustände werden dem von der CPU initiierten Speicherzugriffszyklus hinzugefügt. Es ist also tatsächlich die CPU, die auf den langsameren Flash warten muss. Der Speichercontroller signalisiert der CPU für eine Anzahl von Zyklen (0 bis 3) "nicht bereit", während die CPU in ihrem aktuellen Zustand bleibt, dh die Flash-Adresse geschrieben, aber die Daten noch nicht gelesen hat. Nur wenn die Speichersteuerung "Daten bereit" signalisiert, liest die CPU vom Datenbus und setzt ihre Anweisung fort (Zwischenspeichern der Daten in einem Register oder im RAM).
Der Prozessor muss möglicherweise im Speicher hängen bleiben, aber ein cleveres Design muss das nicht.
Ich denke, die Schlüsseltechnologie, die Sie nicht kennen, ist der Zugriff im Burst-/Page-Modus . Dadurch kann die Bandbreite der Speicherzugriffe sehr nahe an der Prozessorgeschwindigkeit liegen (aber wahrscheinlich ist Flash immer noch der Engpass, da ich noch nie eine Flash-basierte MCU gesehen habe, die mit> 200 MHz läuft).
Die Latenz bleibt jedoch gleich. Zum Beispiel für die STM32F4-MCUs, die ich verwende, #wait states = floor(clockSpeed / 30MhZ). Das bedeutet, dass die Latenz unabhängig von der Taktrate immer 33 ns beträgt. Es gibt ein Sprichwort: "Geld kann Bandbreite kaufen, aber Latenz ist ewig ..."
Selbst wenn die Flash-Bandbreite nicht ausreicht, um die CPU auszulasten, können Sie einfach einen Code-Cache entwerfen, der Anweisungen speichert und vorab abruft, deren Ausführung erwartet wird. ST hat dazu einen Hinweis für seine STM32F4-MCUs (168 MhZ):
Dank des ART-Beschleunigers und des 128-Bit-Flash-Speichers wirkt sich die hier angegebene Anzahl von Wartezuständen nicht auf die Ausführungsgeschwindigkeit aus dem Flash-Speicher aus, da der ART-Beschleuniger es ermöglicht, eine Leistung zu erreichen, die der Programmausführung mit 0 Wartezuständen entspricht.
Eigentlich deutet die Aussage auch darauf hin, dass der Burst-Mode nicht nötig ist und auch ein sehr breites Speicherinterface ausreicht. Aber die Idee ist die gleiche (Verwendung von Parallelität, um Latenz zu verbergen). Auf dem Chip sind Kabel frei, daher wäre ein 128-Bit-Speicher sinnvoll.
Klatsch