Warum wird NOR-Speicher als XIP betrachtet und NAND-Speicher nicht?

Auf der Suche nach einer Antwort darauf, warum genau NOR ein XIP (eXecute In Place) ist und NAND nicht, habe ich mich mit NOR- und NAND-Erinnerungen beschäftigt . Obwohl beide Links äußerst informativ und gut geschrieben waren, befriedigte keiner ausdrücklich meine Neugier.

Ich glaube, ich verstehe die grundlegenden Vor- und Nachteile beider Arten. So wie ich es sehe, eignet sich NOR-Speicher für die Programmspeicherung anstelle der Datenspeicherung, da er schnelle Lesezeiten und schrecklich langsame Schreib- / Löschzeiten hat. Soweit klar. Außerdem bietet NOR echten wahlfreien Zugriff (aufgrund der NOR-Gatter, die im Wesentlichen parallel und nicht seriell sind, wenn ich es richtig verstanden habe), im Gegensatz zu NAND, das normalerweise auf der Ebene von Wörtern arbeitet, seriell, nicht einzelne Bits.

Dies ließ mich denken, dass der XIP-Teil irgendwie auf die Fähigkeit zurückzuführen ist, auf jedes einzelne Bit zuzugreifen, NOR ist zufällig. Ich bin jedoch nicht ganz davon überzeugt, dass dies so ist. Stimmt das oder erzähle ich Unsinn?

Ein Follow-up, wenn es tatsächlich so ist - ich habe den Eindruck, dass NAND tatsächlich so implementiert werden kann, dass ein wahlfreier Zugriff erreicht wird (obwohl es keinen wirklichen Grund dafür gibt, AFAIK) . Könnte XIP dann theoretisch auch mit solchen NAND-Speichern realisiert werden?

Liegt wohl an der Lesegeschwindigkeit.

Antworten (1)

XIP erfordert wahlfreien Zugriff – die CPU muss den Befehlsstrom lesen, während sie ihn ausführt. Wenn es eine Schleife gibt, müssen dieselben Anweisungen erneut gelesen werden (sofern sie nicht zwischengespeichert sind). Wenn es eine Verzweigung gibt, muss sie dieser ohne Verzögerung folgen.

NAND-Flash-Schnittstellen sind normalerweise so konzipiert, dass sie nur blockweisen Zugriff erlauben. Wenn Sie Code aus diesem Speicher ausführen möchten, lesen Sie entweder den gesamten Block und verwerfen alles außer der Anweisung, an der Sie interessiert sind (was schrecklich langsam wäre), oder Sie fügen einen Caching-Mechanismus hinzu.

Es gibt Implementierungen, die XIP in NAND implementieren, indem sie einen Seitenfehler abfangen, einen Block in den Cache lesen und den Cache dann an den virtuellen Adressraum anheften. Mit dafür optimierten Programmen (es gibt Compiler, die Seitenarchitekturen verstehen und wissen, wie Code so ausgerichtet werden kann, dass Funktionen, die sich gegenseitig aufrufen, auf derselben Seite landen) verlieren Sie nicht viel Leistung.

Beachten Sie, dass all diese Überlegungen für alles andere als große Produktionsläufe ziemlich obsolet sind. RAM ist billig genug, dass für ein paar tausend Einheiten der Unterschied in den Hardwarekosten immer noch geringer ist als der Unterschied im Entwicklungsaufwand.

Ah ich sehe. Und die Blöcke in NAND sind, was, im Kilobyte-Bereich? Außerdem eine Folgefrage zum "veralteten" Teil - ich habe darüber nachgelesen, weil es aufgetaucht ist, als ich etwas über die iPhone 1-Architektur gelernt habe. Ist es in Laptop/Desktop-Diskussionen obsolet (falls es überhaupt jemals anwendbar war) oder ist es auch in eingebetteten Systemen obsolet? Danke für eine knappe Antwort!
Normalerweise 512 Byte bis zu einigen Kilobyte. Alles mit genügend Speicher würde normalerweise XIP verwenden, um den RAM zu booten, und dann den Code kopieren, da der RAM immer noch schneller ist (für PCs wurde das "BIOS-Shadowing" genannt). Für Embedded ist es ebenfalls größtenteils veraltet, da moderne MCUs über eine Boot-Logik verfügen, die einen NAND-Block lesen, um den Speicher zwischenspeichern und ausführen kann.
Könnte die NAND-Blockgröße also auf ein einzelnes Byte reduziert werden und der Flash wäre dann XIP-kompatibel?
@Melab, ja, aber dann würde die Dichte unter die von NOR-Blitz sinken. Der Punkt von NAND-Flash ist, dass es billiger und dichter ist.