Sortieren von Daten aus Anweisungen ( ARM I-Cache und D-Cache )

Einige ARM-Kerne wie die ARM9-Kernfamilie haben eine Harvard-Architektur, zumindest auf Cache-Ebene. Das heißt, sie greifen auf zwei separate Caches zu, einen I-Cache für Anweisungen und einen D-Cache für Daten (Beispiel ARM926EJ-S).

Die I & D-Caches werden jedoch extern mit Plain Vanilla SDRAM verbunden. Es scheint also, dass wir auf der RAM-Ebene wieder beim von Neumann-Design angelangt sind, bei dem ein Speicher ( SDRAM ) Anweisungen >und< Daten enthält.

In den Beispieldesigns, die ich gesehen habe, scheint es nur einen einzigen Bus zu geben, der das SDRAM mit dem SOC-Chip verbindet.

Wie werden die Anweisungen und Daten unterschieden, sortiert und von dem kombinierten Bus, der das externe SDRAM verbindet, zu den internen I- und D-Caches geleitet?

Antworten (2)

Die Steuerlogik zeichnet auf , warum sie einen bestimmten Abruf an eine bestimmte Adresse ausgegeben hat, damit sie mit dem Ergebnis etwas Sinnvolles tun kann. Es wird eine kleine Warteschlange mit ausstehenden Abrufen geben (denken Sie daran, dass das Abrufen aus dem DRAM Hunderte von Zyklen dauern kann). Wenn ein Wert ankommt, wird er an den Teil der Architektur zurückgeschrieben, der ihn angefordert hat, und der relevante Teil der Pipeline des Prozessors wird deaktiviert.

Der L1-Cache ist oft im Armkern, SRAM, sehr schnell, L2 ist möglicherweise außerhalb des Chips, möglicherweise nicht.

Die wirkliche Antwort auf Ihre Frage lautet: Gehen Sie zu infocenter.arm.com, gehen Sie dann zum AMBA-Link auf der linken Seite und laden Sie dann eine der AMBA- oder AXI-Spezifikationen herunter, selbst die älteste dort AMBA2 ist in Ordnung.

Wenn es im Kern einen L1-Cache gibt, weiß der Prozessor, ob ein Speicherzugriff ein Befehlsabruf oder Daten ist, und diese Informationen werden auf den internen Bus gelegt, und wenn der Cache aktiviert ist, wird er dieses Ergebnis nachschlagen, bevor er an den Rand geht der Kern. Der Rand des Kerns ist eine Art amba-, ahb- oder axi-Bus, der als eines der Bits auf dem Bus einen Zugriffstyp hat, der unter anderem zwischenspeicherbar oder nicht beinhaltet. Was auch immer darauf geklebt wird, insbesondere wenn der Anbieter L2-Cache-Logik von Arm zu Kleber auf diesen Kern gekauft hat, sucht diese L2-Logik unter Verwendung der Elemente auf dem Bus nach dem Ergebnis und gibt es möglicherweise an den Kern zurück. Gehen Sie andernfalls zum Hauptspeicher auf der anderen Seite des l2-Cache (auch ein amba/axi/whatever-Bus), um die Transaktion aufzulösen oder etwas zu entfernen, das zum Abschließen der Transaktion erforderlich ist usw.

Die Unterschiede in den Geschmacksrichtungen von ARM-Bussen oder -Versionen können/werden je nach Busdetails mehr oder weniger Informationen liefern. Aber wenn das System in der Lage ist, einen Cache zu haben, zeigt die Transaktion an, ob cachebar ist oder nicht, und zeigt auf irgendeine Weise Anweisungen von Daten an (wenn dieser Cache die beiden trennen kann, kann L1 dies möglicherweise tun und L2 möglicherweise nicht, z. B. L1 steuert in gewissem Maße was ist in L2)

Die Armbusse sind Harvard in dem Sinne, dass derselbe Adress- und Datenbus verwendet wird, aber die vielen anderen Felder auf dem Bus werden verwendet, um einen Zugriffstyp von einem anderen zu unterscheiden (es gibt viel mehr als 2), sodass Sie in diesem Sinne ein separates I haben und D-Transaktionen, obwohl sie sich alle denselben Bus teilen.
Sie sind nicht in dem Sinne harvard, dass Sie Daten in den RAM schreiben und dann zu diesem RAM verzweigen und die gerade geschriebenen Daten ausführen können (die Adressräume sind nicht getrennt).
Technisch gesehen kann man nicht einfach auf diesen RAM verzweigen. Es ist nicht garantiert, dass der Befehlscache kohärent ist. Bei den meisten Implementierungen von RISC-ISAs ist jeder separate Befehls-Cache nicht kohärent, und die Software muss die entsprechenden Cache-Blöcke explizit ungültig machen. Selbst mit einem kohärenten oder gemeinsam genutzten Cache erfordert ein RISC im Allgemeinen eine Pipeline-Synchronisation oder eine ähnliche Operation, da der Speicher im Back-End der Pipeline verarbeitet werden kann, nachdem die Verzweigung im Front-End angetroffen wird. x86 ist seltsam darin, aggressive Kohärenz und Konsistenz in Bezug auf selbstmodifizierenden Code zu unterstützen.
Wenn der i-Cache sicher eingeschaltet ist und Sie ihn nicht leeren. Wenn Sie einen Bootloader oder ein Betriebssystem erstellen, kümmern Sie sich im Allgemeinen darum. Der Punkt ist, dass sich Code und Daten im selben Adressraum auf demselben Bus befinden, was der Harvard-Architektur widerspricht.