Was ist der Unterschied zwischen "normalem Lesen" und "schnellem Lesen" im Flash A25L032


9

Der Flash A25L032 verfügt über einen normalen Lesemodus und einen schnellen Lesemodus. Es hat auch Dual- und Quad-Lesemodi, die selbsterklärend sind. Der Unterschied zwischen dem normalen und dem schnellen Modus ist jedoch überhaupt nicht klar.

Was macht den schnellen Modus schnell? da beide sowieso ein einziges MISO von SPI verwenden? Ihre Zeitdiagramme sind unten:

Geben Sie hier die Bildbeschreibung ein

Schnell lesen:

Geben Sie hier die Bildbeschreibung ein

Antworten:


12

Was macht den schnellen Modus schnell?

Der Unterschied ist sicherlich gut versteckt :-) Schauen Sie sich die Tabelle mit den AC-Eigenschaften im Datenblatt an . Es heißt, dass der normale READ Befehl (03h) eine maximale Taktfrequenz von 65 MHz hat. Während alle anderen Befehle, einschließlich des FAST_READBefehls (0Bh), eine maximale Taktfrequenz von 100 MHz haben:

A25L032 AC-Eigenschaften

Aus diesem Grund FAST_READkann es abhängig von der tatsächlich gewählten Taktfrequenz schneller gehen.

Aber aufgrund des Dummy - Byte erforderlich ist, wenn die Verwendung FAST_READBefehl (aber nicht , wenn der normalen Verwendung READBefehls), dann , wenn die beiden Befehle zur Verwendung von vielen kleinen liest mit einer Taktfrequenz von <= 65 MHz, dann Durchsatz die Daten würden tatsächlich sein langsamer , wenn Verwenden von FAST_READBefehlen im Vergleich zum Verwenden von READBefehlen aufgrund des Overheads aller Dummy-Bytes (eines pro FAST_READan das Gerät gesendeten Befehl).

Wenn eine schnellere Taktfrequenz (> 65 MHz) verwendet wird und weniger, aber größere FAST_READBefehle verwendet wurden (weil der Dummy-Byte-Overhead "pro Befehl" ist), würde der größere Durchsatz den Overhead der Dummy-Bytes überwiegen.

Warum nicht einfach einen einzigen Modus haben, der bis zu 100 MHz arbeiten kann?

Dies gerät in den Bereich der Spekulation - ich vermute, dass eine interne Mindestlatenz erforderlich ist, um den Datenlesevorgang zu starten (möglicherweise das Laden der internen Ladungspumpe?).

Meine Hypothese ist, dass die Latenz hinter der Zeit "verborgen" sein könnte, die erforderlich ist, um den READBefehl bei <= 65 MHz zu empfangen (dh relativ langsame Geschwindigkeiten), aber die erforderliche Latenz (vor dem Beginn des Lesens) ist länger als die Zeit, die zum Empfangen von a benötigt wird READBefehl bei> 65 MHz (dh relativ schnellere Geschwindigkeiten). Dies könnte erklären, warum ein anderes Befehlsprotokoll (das vor Beginn der Datenlesephase ein zusätzliches Byte hinzufügt) für ein schnelleres Lesen erforderlich ist. Für die Befehle und ist ein Dummy-Byte FAST_READund für die FAST_READ_DUAL_OUTPUTBefehle ein Modusbyte erforderlichFAST_READ_DUAL_INPUT_OUTPUTBefehl. Diese Bytes dienen alle dazu, den Start der Datenausgabephase zu verzögern, was mir eine feste interne Latenzanforderung nahe legt - etwas, das ich zuvor bei anderen Geräten gesehen habe. Die eigentliche Antwort müsste natürlich vom Hersteller kommen :-)


was? Aha. Warum gibt es diesen "schnellen Modus" Ihrer Meinung nach als eigenständigen Betriebsmodus im Gerät? Warum nicht einfach einen einzigen Modus haben, der bis zu 100 MHz arbeiten kann?
Quantum231

2
Siehe mein späteres Update - ich habe es geschrieben, als Sie den Kommentar geschrieben haben :-) Ich denke, das beantwortet die Frage - FAST_READ ist nicht immer schneller, aufgrund des Overheads des "Dummy-Bytes", das für jeden FAST_READ-Befehl gesendet werden muss. Wenn die Taktfrequenz <= 65 MHz ist, ist das normale READ schneller (es wird kein Dummy-Byte (pro Befehl) benötigt).
SamGibson

Würde es einen Software-Overhead geben, um Taktfrequenzen zu verschieben? Es scheint, dass FAST_READ bestenfalls magere Vorteile hat.
Sparky256

1
@ Sparky256 - Hallo, ich schlage einen internen Hardware -Overhead im Flash-Chip vor (ich habe zuvor ein ähnliches Verhalten gesehen). Betreff: die Vorteile - für große Befehle (dh viele Bytes / Befehl) wäre der Overhead für das Dummy-Byte minimal. Daher FAST_READprofitieren große Befehle mit hoher Taktfrequenz (>> 65 MHz) am meisten und könnten sich der Verbesserung des Durchsatzes nur aufgrund der Erhöhung der FAST_READTaktrate über 65 MHz im Vergleich zu READBefehlen mit 65 MHz nähern (z. B. wenn das gesamte Gerät eingelesen wird) ein Befehl, dann ist der Overhead nur ein Dummy-Byte!).
SamGibson

1
Dummy-Byte wurde aus zeitlichen Gründen hier bestätigt: flashmemorysummit.com/English/Collaterals/Proceedings/2011/…
MarcH

1

Nachdem eine bestimmte Anzahl von Adressbits empfangen wurde, kann ein Flash-Chip den Prozess des Lesens einer Zeile einleiten. Dieser Vorgang kann gleichzeitig mit dem Empfang der nächsten Bits der Adresse durchgeführt werden. Wenn es dem Master gelingt, das Senden der Adresse zu beenden und mit dem Ausstempeln von Daten zu beginnen, bevor das Gerät bereit ist, kann das Gerät keine gültigen Daten ausstempeln (da sie an der Ausgangslogik nicht verfügbar wären) und würde stattdessen möglicherweise ausstempeln. fehlerhafte Daten.

Wenn der Master zwischen dem Senden der ansteigenden Flanke für das letzte Bit der Adresse und der abfallenden Flanke zum Lesen des ersten Wortes der Daten ausreichend pausieren würde, wäre es dem Gerät wahrscheinlich egal, ob die Adresse und die Daten mit der 100-MHz-Rate oder getaktet würden die langsamere 65MHz Rate. In vielen Fällen ist es für einen Busmaster jedoch einfacher, ein zusätzliches Wort auszustempeln, als um eine kurze gemessene Zeitspanne zu verzögern. Geben Sie daher zwei Möglichkeiten zum Auslesen von Daten an (verwenden Sie eine Datenrate, die langsam genug ist, um die Notwendigkeit zu beseitigen Eine Pause oder das Einfügen eines Dummy-Bytes, um effektiv eine Pause von 80 ns zu erzeugen, die beide mit Uhren mit gleichmäßiger Geschwindigkeit erreicht werden können, machte die Spezifikation einfacher als es gewesen wäre, wenn eine Mindestzeit zwischen dem Empfang eines bestimmten Adressbits und dem Auslesen des ersten Datenbits. In den meisten Fällen, in denen ein System Daten schneller als 65 MHz empfangen kann, kann es den Hochgeschwindigkeits-Lesebefehl mit zusätzlichem Byte in kürzerer Zeit senden, als dies zum Senden des Langsamgeschwindigkeitsbefehls mit 65 MHz erforderlich wäre. Es gibt zwar einige Fälle, in denen die Hardware zum Senden eines Befehls auf 65 MHz beschränkt ist, die Hardware zum Ausstempeln von Daten jedoch 100 MHz (*) leisten kann, und es wäre möglicherweise nützlich gewesen, wenn die Spezifikation für dieses Szenario dies angegeben hätte Der Befehl könnte Daten mit 100 MHz takten, sobald der Befehl selbst vollständig übertragen wurde. Ich würde nicht denken, dass es selbst in diesem Fall schwierig wäre, den zusätzlichen Dummy zu takten.

(*) Dieses Szenario wäre hauptsächlich in Fällen relevant, in denen die Daten direkt einem anderen Gerät zugeführt wurden. Als einfaches Beispiel könnte ein Gerät zum Ausgeben von statischen zusammengesetzten Videoanzeigen, die im ROM gespeichert sind, Daten verwenden, die als gepackte Sechs-Bit-Abtastwerte gespeichert sind, um mit einer Rate von vier Abtastwerten pro 3.579.545,45-Hz-Chroma-Zyklus (einer Datenrate von ungefähr 85.909.090,9 Bit / s) getaktet zu werden. -schneller als 65 MHz). Wenn der Mikrocontroller mit dieser Taktrate betrieben würde, könnte sein SPI-Port möglicherweise nur mit der halben Geschwindigkeit laufen, aber er könnte möglicherweise die Taktquelle des Flash-Chips zwischen dem SPI-Takt und dem rohen 85,9-MHz-Takt umschalten.


0

Die interne Erfassungsschaltung benötigt etwa 15 bis 20 ns (1 bis 1,5 Zyklen), um Daten zu unterscheiden. Bei der Wortdatenerfassung verwendet die interne Schaltung den A0-Eingangszyklus, um die Kerndaten zu erfassen und dann herauszufinden, auf was A0 zeigt. Daher benötigt <65MHz keine Dummy-Zyklen. Wenn 65 MHz überschritten werden, benötigt der interne Schaltkreis einen Exta-Takt, um Daten vorzubereiten.

Wenn dieses Chip-Design einen doppelten Wortsinn hat, können Sie READ mit einer schnelleren Uhr versuchen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.