DE60132830T2

DE60132830T2 - Neuartiges verfahren und struktur zur effizienten datenverifizierungsoperation für nichtflüchtige speicher

Info

Publication number: DE60132830T2
Application number: DE60132830T
Authority: DE
Inventors: Kevin M. San Jose Conley; Daniel Fremont GUTERMAN; Carlos Los Gatos GONZALEZ
Original assignee: SanDisk Corp
Current assignee: SanDisk Corp
Priority date: 2000-12-28
Filing date: 2001-12-28
Publication date: 2009-02-05
Anticipated expiration: 2021-12-29
Also published as: WO2002099806A2; ATE386329T1; JP2005507129A; US7170782B2; US20030174555A1; WO2002099806A3; EP1488429A2; KR20030068202A; KR100921763B1; AU2001297851A1; CN1620703A; DE60132830D1; JP4129428B2; US6560143B2; TWI241590B; US7376011B2; US20020126528A1; US20070109858A1; EP1488429B1; CN100474452C

Description

Die vorliegende Erfindung betrifft das Gebiet nichtflüchtiger Halbleiterspeicher-Architekturen und Betriebsverfahren für diese und findet Anwendung bei elektrisch löschbaren und programmierbaren Flash-Nur-Lese-Speichern (EEPROMs).
Eine übliche Anwendung von Flash-EEPROM-Bauelementen stellt ein Massendatenspeicher-Teilsystem für elektronische Geräte dar. Solche Teilsysteme werden üblicherweise entweder als entfernbare Speicherkarten implementiert, die in mehrere Hostsysteme eingefügt werden können, oder als ein nicht entfernbarer, eingebetteter Speicher in dem Hostsystem. Bei beiden Implementierungen umfasst das Teilsystem ein oder mehrere Flash-Bauelemente und oft einen Teilsystem-Controller.
Flash-EEPROM-Bauelemente bestehen aus einem oder mehreren Arrays aus Transistorzellen, wobei jede Zelle des nichtflüchtigen Speichers ein oder mehr Bit Daten speichern kann. Somit benötigen Flash-Speicher keinen Strom, um die in ihnen programmierten Daten zu halten. Wenn eine Zelle jedoch einmal programmiert ist, muss sie gelöscht werden, bevor sie mit einem neuen Datenwert neu programmiert werden kann. Diese Arrays aus Zellen sind in Gruppen unterteilt, um eine effiziente Realisierung von Lese-, Programmier- und Löschfunktionen zu bieten. Bei einer typischen Flash-Speicher-Architektur für Massenspeicher sind große Gruppen von Zellen zu löschbaren Blöcken gruppiert. Jeder Block ist weiter in einen oder mehrere adressierbare Sektoren unterteilt, welche die Basiseinheit für Lese- und Programmierfunktionen darstellen.
Der Teilsystem-Controller führt eine Reihe von Funktionen aus, darunter die Übersetzung der logischen Blockadresse (LBA) des Teilsystems in eine physische Chip-, Block- und Sektoradresse. Der Controller verwaltet außerdem über eine Reihe von Befehlen, die über einen Schnittstellenbus an die Flash-Speicher-Bauelemente ausgegeben werden, Flash-Schaltungsoperationen auf unterer Ebene. Eine weitere Funktion, die der Controller ausführt, besteht darin, die Integrität der in dem Teilsystem gespeicherten Daten über verschiedenen Mitteln aufrechtzuerhalten (z. B. unter Nutzung eines Fehlerkorrekturcodes, oder ECC).
1 zeigt eine typische interne Architektur 4000 eines Flash-EEPROM-Bauelements gemäß dem Stand der Technik. Die Schlüsselmerkmale sind ein E/A-Bus 411 sowie Steuersignale 412 zur Kopplung mit einem externen Controller, eine Speicher-Steuerschaltung 450 zum Steuern interner Speicheroperationen, mit Registern für Befehle, Adressen und Status, ein oder mehrere Arrays 400 aus Flash-EEPROM-Zellen, wobei jedes Array seinen eigenen Zeilen-Decoder (XDEC) 401 und Spalten-Decoder (YDEC) 402 aufweist, eine Gruppe aus Leseverstärkern und Programmiersteuerschaltungen (SA/PROG) 454 sowie ein Datenregister 404.
Wenn gewünscht, ist eine Mehrzahl von Arrays 400 vorhanden, zusammen mit zugehörigen X-Decodern, Y-Decodern, Programmier/Verifizier-Schaltungen, Datenregistern und dergleichen, wie beispielsweise in US-Patent 5,890,192 gelehrt wird, das am 30. März 1999 an die SanDisk Corporation, den Abtretungsempfänger der vorliegenden Anmeldung, erteilt worden ist.

Der externe Schnittstellen-E/A-Bus 411 und die Steuersignale 412 könnten mit folgenden Signalen konfiguriert werden:

CS – Chip-Auswahl	wird genutzt, um die Flash-Speicher-Schnittstelle zu aktivieren;
RS – Lese-Impuls	wird genutzt, um anzuzeigen, dass der AD-Bus für eine Datenleseoperation genutzt wird;
WS – Schreib-Impuls	wird genutzt, um anzuzeigen, dass der AD-Bus für eine Datenschreiboperation genutzt wird;
AS – Adress-Impuls	zeigt an, dass der AD-Bus genutzt wird, um Adressinformationen zu übertragen;
AD[7:0] – Adress/Datenbus	wird genutzt, um Daten zwischen dem Controller und den Befehls-, Adress- und Datenregistern des Flash-Speichers zu übertragen.

Diese Schnittstelle ist nur als ein Beispiel angegeben, da andere Signalkonfigurationen genutzt werden können, welche die gleiche Funktionalität ergeben. Das vorliegende Schema zeigt lediglich ein Flash-Speicher-Array 400 mit den mit diesem in Zusammenhang stehenden Komponenten, auf einem einzigen Flash-Speicher-Chip können aber auch mehrere Arrays vorhanden sein, die eine gemeinsame Schnittstelle und Speichersteuerschaltung gemeinsam nutzen, die aber eine separate XDEC-, YDEC-, SA/PROG- und DATA REG-Schaltung aufweisen, um parallele Lese- und Programmiervorgänge zu ermöglichen.
Daten von dem Datenregister 404 des EEPROM-Systems 4000 zu einem externen Controller werden über die Datenregister auf den E/A-Bus AD[7:0] 411 eingekoppelt. Das Datenregister 404 ist außerdem mit der Leseverstärker/Programmierschaltung 454 gekoppelt. Die Anzahl der Elemente des Datenregisters, die mit jedem Leseverstärker/Programmierschaltungselement gekoppelt sind, kann von der Anzahl der in jeder Flash-EEPROM-Zelle gespeicherten Bits abhängen. Jede Flash-EEPROM-Zelle kann eine Mehrzahl von Bits enthalten, beispielsweise 2 oder 4, wenn Mehrzustands-Speicherzellen zur Anwendung kommen.
Der Zeilen-Decoder 401 dekodiert Zeilenadressen für das Array 400, um den physischen Sektor auszuwählen, auf den zugegriffen wird. Der Zeilen-Decoder 401 empfängt Zeilenadressen über interne Zeilenadressleitungen 419 von der Speichersteuerlogik 450. Der Spalten-Decoder 402 empfängt Spaltenadressen über interne Spaltenadressleitung 429 von der Speichersteuerlogik 450.
2 zeigt eine typische Architektur einer Flash-Karte, die einen einzigen Controller 301 aufweist, der Host- und Speichersteuerungsfunktionen ausführt, sowie ein Flash-Speicher-Array, das aus einem oder mehreren Flash-Speicher-Bauelementen besteht. Der System-Controller und der Flash-Speicher sind durch einen Bus 302 verbunden, welcher es dem Controller 301 ermöglicht, Befehle und Adressen in das und von dem Flash-Speicher-Array zu laden und Daten von und zu diesem zu transferieren.
In der Praxis ist es üblich, dass in jedem Sektor an die in einen Sektor programmierten Host-Daten ein Fehlererkennungs- und -korrekturcode (ECC) angehängt wird, der genutzt wird, um die Gültigkeit der gespeicherten Daten beim Zurücklesen festzustellen. Einige solcher Systeme nutzen den Vorgang des Transfers von dem Speicherbauelement zu dem Controller als Gelegenheit, um die Gültigkeit der gelesenen Daten zu überprüfen, und zwar als eine Möglichkeit, um sicherzustellen, dass die Daten nicht korrumpiert sind.
Um die Gültigkeit der programmierten Daten sicherzustellen, werden bei einigen Systemen die Daten unmittelbar nachdem sie programmiert worden sind aus einem Sektor gelesen. Die Daten werden verifiziert, bevor die nächste Operation stattfindet, und zwar mithilfe eines ECC, Datenvergleichs oder eines anderen Mechanismus. Bei Systemen gemäß dem Stand der Technik erfolgt diese Datenverifizierung, wie Fachleuten auf dem Gebiet bekannt ist, während des Datentransfers, der nach dem Lesen stattfindet.
Somit verlängert sich die Zeit für die Ausführung eines Programmierungsvorgangs aufgrund des Hinzukommens einer Leseoperation und des Transfers der Daten von dem Flash-Speicher-Bauelement zu der Controllerschaltung, wo die Verifizierung tatsächlich stattfindet. Der Programmier-Verifizierungsvorgang zeigt an, ob sämtliche Zellen auf ihre gewünschten Pegel oder über diese hinaus programmiert worden sind oder nicht, und es wird im Allgemeinen nicht überprüft, ob die Zellen ihren Soll-Zustand überschritten haben, möglicherweise bis zu dem nächsten Zustand, im Falle eines Mehrzustandsspeichers, sondern nur, ob sie eine bestimmte Verifizierungsbedingung überschritten haben. Aufgrund der Gesamtgenauigkeit dieser Speicherbauelemente tritt während solcher Verifikationen selten ein Fehler auf.
3 zeigt ein Taktungsdiagramm eines Programmier/Verifizierungsvorgangs mit zwei Sektoren, bei welchem Daten an zwei Zieladressen (DST[N] und DST[N + 1]) programmiert werden und danach zur Verifizierung gelesen werden, und zwar vor dem Programmieren an der nächsten Zieladresse (DST[N + 2]). Das Signal READ zeigt an, dass ein Lesevorgang von dem Quellsektor stattfindet. Das Signal XFER zeigt einen Datentransfer zwischen dem Flash-Datenregister und dem Controller an. Das Signal R/W zeigt die Richtung des Transfers an (hoher Pegel bedeutet einen Lesevorgang von dem Flash-Speicher zu dem Controller und niedriger Pegel bedeutet einen Schreibvorgang von dem Controller auf den Flash-Speicher). Das Signal PROG gibt an, dass eine Programmieroperation auf die Zielspeicherseite erfolgt.
4 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Verifizierungsvorgangs erfolgen:

1. Transfer von Daten zu dem Master-Datenregister 403 von der externen Controllerschaltung (nicht gezeigt).
2. Transfer von Inhalten des Master-Datenregisters 403 zu dem Slave-Datenregister 404.
3. Programmieren der Daten von dem Slave-Datenregister 404 in das Flash-Speicher-Array 400.
4. Zurücklesen der Daten von dem Flash-Speicher-Array 400 in das Slave-Datenregister 404.
5. Transfer der Daten von dem Slave-Register 404 zu dem Master-Datenregister 403.
6. Transfer der Daten von dem Master-Datenregister 403 zu der externen Controller-Schaltung (nicht gezeigt) zur Validierung.

Die exakten Kosten dieser Verifizierungsvorgänge variieren in Abhängigkeit von der Dauer der verschiedenen Flash-Speicher-Operationen, der Größe der Datenmenge, der Größe des E/A-Busses und der Zykluszeit des E/A-Busses. Ein Beispiel, bei dem einige typische Werte genutzt werden, sei jedoch nachstehend aufgezeigt: TRD = 25 μs TX = 26,4 μs TPRG = 300 μs
Die Gesamtzeit zum Programmieren und Verifizieren eines einzelnen Sektors (wie in 4 gezeigt) beträgt: TPgm/Vfy = TX + TPRG + TRD + TX = 377 μs,was bedeutet, dass die Datenverifizierungszeit 14% des gesamten Programmier/Verifizierungsvorgangs ausmacht.
Ein allgemeiner Trend beim Entwurf nichtflüchtiger Speicher geht dahin, die Anzahl der Zellen zu erhöhen, die gleichzeitig programmiert und gelesen werden können, um das Leistungsverhalten beim Schreiben und Lesen dieser Bauelemente zu verbessern. Dies kann erreicht werden, indem die Anzahl der Speicherzellen-Arrays auf einem einzigen Chip erhöht wird, indem die Größe der Speicherseite in einer einzelnen Ebene erhöht wird, indem mehrere Chips parallel programmiert werden oder durch eine Kombination dieser drei Verfahren. Im Ergebnis dessen erhöht sich aufgrund der größeren Anzahl der programmierten oder gelesenen Zellen die Datentransferlänge, wobei sich die Programmier- und Lesezeiten geringfügig oder überhaupt nicht ändern. Somit ist der Aufwand für die Datenverifizierung in einem System mit einer solchen erhöhten Parallelität dementsprechend umso höher. Als Beispiel zeigen die gleichen Taktungswerte, die in dem obigen Beispiel genutzt wurden, die Auswirkung auf ein System mit einer vierfachen Erhöhung der Parallelität: TPgm/Vfy = 4·TX + TPRG + TRD + 4·TX = 526,4 μs,was bedeutet, dass die Datenverifizierungszeit 24% des gesamten Kopiervorgangs von vier Speicherseiten ausmacht.
Es wird ein Flash-Speicher-Bauelement offenbart, bei dem eine nach dem Programmieren erfolgende Verifizierungsoperation ausgeführt werden kann, ohne dass die Daten an eine externe Controllerschaltung übertragen werden, und bei welchem während dieser Programmier- oder Verifizierungsvorgänge ein Datentransfer von dem externen Controller möglich ist.
Entsprechend einem Aspekt der vorliegenden Erfindung wird ein nichtflüchtiges Speicherbauelement zur Verfügung gestellt, welche umfasst: ein Array aus nichtflüchtigen Speicherzellen, ein Master-Datenregister zum Empfangen von Daten, die in dem Array gespeichert werden sollen, ein Datenvergleichsregister zum Empfangen von Daten aus dem Master-Datenregister, ein Slave-Datenregister zum Empfangen von Daten aus dem Array und eine Vergleichsschaltung zum Vergleichen der in dem Slave-Datenregister und dem Datenvergleichsregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren. Das Bauelement ist dadurch gekennzeichnet, dass das Master-Datenregister dafür ausgelegt ist, einen nachfolgenden Satz Daten zur Programmierung in das Array zu empfangen und/oder zu halten, während der Vergleich erfolgt. Eine Kopie der zu programmierenden Daten wird in dem Speicherbauelement gehalten.
Nachdem die Programmierung abgeschlossen ist, werden die Daten zurückgelesen und mit der beibehaltenen Kopie verglichen, und zwar in einem Lese-Verifizierungsprozess nach dem Schreiben, der in dem Speicherbauelement selbst erfolgt.
Bei einer Gruppe von Ausführungsformen ist das nichtflüchtige Speichersystem mit Schaltungen entworfen, die drei Datenregister umfasst. Das erste Datenregister steuert die Programmierschaltung und speichert Daten von Lesevorgängen. Das zweite Datenregister hält eine Kopie der Programmierdaten für eine spätere Verifizierung. Das dritte Datenregister wird genutzt, um während Programmier-, Verifizierungs- und Lesevorgängen Daten zu transferieren. Dieser Prozess des Hereinholens des nächsten zu programmierenden Datensatzes, während ein aktueller Datensatz programmiert wird, kann als Stream-Programmierung bezeichnet werden. Vor einem Programmiervorgang werden Daten in das erste und das zweite Register transferiert. Nach dem Programmiervorgang werden die Daten aus den gerade programmierten Zellen zurückgelesen und in dem ersten Register gespeichert. Die Inhalte dieses Registers werden dann mit den Inhalten des zweiten Registers verglichen. Eine Übereinstimmung zwischen den beiden Datensätzen zeigt an, dass die Daten korrekt programmiert worden sind, und es wird ein Status erzeugt, der eine erfolgreiche Verifizierung anzeigt. Während der Programmier- und Verifizierungsvorgänge kann das dritte Datenregister genutzt werden, um den nächsten zu programmierenden Datensatz zu empfangen.
Entsprechend einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines nichtflüchtigen Speicherbauelements zur Verfügung gestellt, wobei das Verfahren folgende Schritte umfasst: Empfangen von Daten, die in einem Array aus nichtflüchtigen Speicherzellen gespeichert werden sollen, Speichern der Daten in einem Master-Datenregister, Speichern der Daten in einem Datenvergleichsregister, Programmieren der Daten in das Array, Lesen der Daten, so wie sie in dem Array gespeichert sind, Speichern der gelesenen Daten in einem Slave-Datenregister und Vergleichen der in dem Slave-Datenregister und in dem Datenvergleichsregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren. Das Verfahren ist dadurch gekennzeichnet, dass das Master-Datenregister gleichzeitig mit einem oder mehreren Schritten der Schritte Programmieren, Lesen und Vergleichen einen zweiten Satz Daten zur Programmierung in das Array empfängt und/oder hält.
Entsprechend einem weiteren Aspekt der vorliegenden Erfindung wird ein nichtflüchtiges Speicherbauelement zur Verfügung gestellt, welches umfasst: ein Array aus nichtflüchtigen Speicherzellen, ein Master-Datenregister zum Empfangen von Daten, die in dem Array gespeichert werden sollen, wobei das Master-Datenregister die Daten nach der Speicherung beibehält, ein Slave-Datenregister zum Empfangen von Daten aus dem Array und eine Vergleichsschaltung zum Vergleichen der in dem Slave-Datenregister und dem Master-Datenregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren.
Das Bauelement ist dadurch gekennzeichnet, dass das Master-Datenregister dafür ausgelegt ist, einen nachfolgenden Satz Daten zur Programmierung in das Array zu empfangen und/oder zu halten, während der Vergleich erfolgt.
Entsprechend einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines nichtflüchtigen Speicherbauelements zur Verfügung gestellt. Das Verfahren umfasst folgende Schritte: Empfangen von Daten, die in einem Array aus nichtflüchtigen Speicherzellen gespeichert werden sollen, Speichern der Daten in einem Master-Datenregister, Programmieren der Daten in das Array, während die Daten in dem Master-Datenregister beibehalten werden, Lesen der Daten, so wie sie in dem Array gespeichert sind, Speichern der gelesenen Daten in einem Slave-Datenregister und Vergleichen der in dem Slave-Datenregister und dem Master-Datenregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren.
Das Verfahren ist dadurch gekennzeichnet, dass das Master-Datenregister gleichzeitig mit einem oder mehreren Schritten der Schritte Programmieren, Lesen und Vergleichen einen zweiten Satz Daten zur Programmierung in das Array empfängt und/oder hält.
Eine alternative Gruppe von Ausführungsformen stellt eine Realisierung mit zwei Registern dar, bei welchen ein Master-Register die eingehenden Daten empfängt und eine Kopie der Daten nach deren Programmierung beibehält. Nachdem die Daten geschrieben sind, werden sie in ein zweites Register ausgelesen, dessen Inhalt dann mit den ursprünglichen Daten in dem Master-Register verglichen wird. Bei einer anderen Anordnung wird nur ein einziges Master-Register genutzt, wobei die Daten wiederum nach der Programmierung in dem Master-Register beibehalten werden und die gelesenen Daten direkt mit dem Inhalt des Master-Registers verglichen werden, während sie aus dem Array ausgelesen werden. Diese Varianten ermöglichen es, sowohl destruktive (bei denen die Daten in dem zur Programmierung genutzten Register beim Prozess der Programmier-Verifikation verloren gehen) als auch nicht-destruktive (bei denen die Daten durchgängig beibehalten werden) Programmierverfahren zu nutzen.
Bei sämtlichen Ausführungsformen kann der nach der Programmierung erfolgende Verifizierungsvorgang wiederholt werden, wobei zusätzliche Verifizierungen unter Nutzung anderer Lesebedingungen ausgeführt werden können, um sicherzustellen, dass die richtigen Werte für Lesegrenzen gegeben sind. Bei den verschiedenen Ausführungsformen können mehrere Datensektoren parallel geschrieben werden, wobei der nach der Programmierung erfolgende Verifizierungsvorgang in den unterschiedlichen Sektoren entweder seriell oder parallel ausgeführt wird. Die nach der Programmierung erfolgende Verifizierung kann einen automatischen Prozess in dem Speicherbauelement darstellen oder kann unter Ansprechen auf einen Befehl von dem Controller ausgeführt werden. Der Befehl kann die Art des bei der Verifizierung zu nutzenden Lesevorgangs spezifizieren oder kann Parameter, beispielsweise einen Satz von Grenzpegeln, die für das Lesen genutzt werden sollen, spezifizieren. Der Speicher kann entweder binäre oder Mehrzustands-Speicherzellen nutzen. Bei einer Mehrzustands-Ausführungsform kann die Adressierung auf Speicher-Ebene erfolgen.
Weitere Aspekte, Merkmale und Vorteile der vorliegenden Erfindung sind in der folgenden Beschreibung spezieller repräsentativer Ausführungsformen enthalten, wobei diese Beschreibung in Zusammenhang mit den beigefügten Zeichnungen betrachtet werden sollte.
1 zeigt ein Blockdiagramm eines typischen EEPROM gemäß dem Stand der Technik;
2 zeigt eine typische Architektur eines Flash-basierten Speicher-Teilsystems gemäß dem Stand der Technik;
3 zeigt ein Taktungsdiagramm eines Programmier/Verifizierungsvorgangs für zwei Sektoren gemäß dem Stand der Technik;
4 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Verifizierungsvorgangs in Systemen gemäß dem Stand der Technik auftritt;
5 zeigt eine schematische Darstellung eines nichtflüchtigen Halbleiterspeichers entsprechend einer Ausführungsform der vorliegenden Erfindung;
6 stellt ein Taktungsdiagramm für einen Programmier/Verifizierungsvorgang für zwei Sektoren gemäß einer Ausführungsform der vorliegenden Erfindung dar;
7 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Verifizierungsvorgangs bei einer Ausführungsform gemäß der vorliegenden Erfindung auftritt;
8 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Mehrfachverifizierungsvorgangs bei einer Ausführungsform gemäß der vorliegenden Erfindung auftritt;
9 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Mehrfachverifizierungsvorgangs bei einer Ausführungsform gemäß einer alternativen Ausführungsform der vorliegenden Erfindung auftritt;
10 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Mehrfachverifizierungsvorgangs bei einer weiteren alternativen Ausführungsform der vorliegenden Erfindung auftritt; die
11 und 12 stellen Taktungsdiagramme dar, welche die Nutzung der Stream-Programmierung veranschaulichen;
13 stellt schematisch Zellenpopulationen und Lese-Grenzbedingungen in einem Mehrzustandsspeicher dar;
14 zeigt eine mögliche Art des Änderns von Lesebedingungen;
15 stellt den Prozess des Adressierens von Speicherzellen durch ihren Zustand dar;
16 stellt ein Beispiel der Registernutzung bei einer Ausführungsform gemäß der vorliegenden Erfindung dar, wenn Speicherzellen über ihren Zustand adressiert werden.
Die vorliegenden Erfindung umfasst sowohl ein System als auch ein Verfahren zum Ausführen von Programmier/Verifizierungsvorgängen in einem Flash-Speicher-Bauelement, bei denen es nicht erforderlich ist, dass Daten aus dem Speicherbauelement transferiert werden, um einem externen Controller zu ermöglichen, gleichzeitig Daten für nachfolgende Programmiervorgänge in das Bauelement zu transferieren. Der nach der Programmierung erfolgende Lese/Verifizierungsprozess gemäß der vorliegenden Erfindung (nachstehend oft locker lediglich als Verifizieren oder Verifizierung bezeichnet, in Abhängigkeit vom Zusammenhang) muss von dem Programmier-Verifizierungsprozess unterschieden werden, der als Teil des eigentlichen Programmierprozesses erfolgt und gemäß dem Stand der Technik üblich ist. Entsprechend einem prinzipiellen Aspekt wird eine Kopie der Daten während der Programmierung in dem Speicherbauelement gehalten. Der Vergleichsprozess gemäß der vorliegenden Erfindung erfolgt getrennt von dem Programmierprozess und nach diesem und nutzt tatsächlich einen Leseprozess, um die Daten bereitzustellen, die mit der beibehaltenen Kopie verglichen werden. 5 zeigt ein Schema, das einen nichtflüchtigen Halbleiterspeicher darstellt, der entsprechend einer Ausführungsform der vorliegenden Erfindung aufgebaut ist. Die Beschreibung der jeweiligen Komponenten in diesem Schema entspricht der mit Bezug auf 1 beschriebenen, mit den folgenden Ausnahmen: Es sind ein zusätzliches Datenvergleichsregister 405 und eine zugehörige Vergleichslogik 430 zum Zwecke der Ausführung des Datenverifizierungsvorgangs vorhanden. Bei einer Ausführungsform dieser Erfindung ist das Register, das die gelesenen Daten speichert und die zu programmierenden Daten bereitstellt, in solcher Weise gestaltet, dass das Speicherelement für beide Vorgänge physisch dasselbe ist.
Eine solche Datenregisterschaltung, die zur Nutzung bei der vorliegenden Erfindung geeignet ist, ist detailliert in dem bereits erwähnten US-Patent 5,890,192 beschrieben. Eine geeignete Gruppe von Register/Datenzwischenspeicher-Schaltungen ist in einer US-Patentanmeldung mit dem Titel "Dynamic Column Block Selection" von Raul Adrian Cernea, eingereicht am 17. September 2001, (veröffentlicht als US 6,560,146 ) beschrieben. Entsprechend der beschriebenen Ausführungsform sind die verschiedenen Register, beispielsweise das Master-Datenregister 403, das Slave-Datenregister 404 und das Datenvergleichsregister 405 groß genug, um sämtliche parallel programmierte Daten zu halten, oder es gibt entsprechend viele Sätze relevanter Register pro Sektor, die parallel programmiert werden. 6 zeigt ein Taktungsdiagramm eines Programmier/Verifizierungsvorgangs für zwei Sektoren, bei welchem Daten an zwei Zieladressen (DST[N] und DST[N + 1]) programmiert werden und danach zum Verifizieren gelesen werden.
Gleichzeitig mit dem Lesevorgang erfolgen die Datentransfers für das nächste Paar Sektoren, die an die Adressen DST[N + 2] und DST[N + 3] geschrieben werden sollen. Das Signal READ zeigt an, dass die beiden Sektoren von den gerade programmierten Adressen parallel gelesen werden. Das Signal XFER zeigt einen Datentransfer zwischen dem Flash-Datenregister und dem Controller an. Das Signal R/W zeigt die Richtung des Transfers an (hoch bedeutet Transfer zu dem Controller, niedrig bedeutet zu dem Flash). Man beachte, dass das Signal R/W dauerhaft niedrig ist, da kein Datentransfer von dem Flash-Speicher zu dem Controller stattfindet. Das Signal PROG zeigt an, dass der Programmiervorgang auf die Zielspeicherseiten stattfindet.
7 stellt die Abfolge von Ereignissen dar, die während eines Programmier/Verifizierungsvorgangs entsprechend dieser Ausführungsform der Erfindung mit drei Registern auftreten. In 7 sind der Y-Decoder YDEC 402, die Lese/Programmierschaltung SA/PROG 454 und andere Elemente aus 5 unterdrückt, um die Diskussion zu vereinfachen. Der Prozess aus 7 umfasst:

1. Transfer von Daten von einer (nicht gezeigten) externen Controllerschaltung zu dem Master-Datenregister 403.
2. Transfer des Inhalts des Master-Datenregisters 403 zu dem Slave-Datenregister 404 und dem Datenvergleichsregister 405, zum Beispiel gleichzeitig.
3. Programmieren der Daten von dem Slave-Datenregister 404 in das Flash-Speicher-Array 400.
4. Zurücklesen der Daten aus dem Flash-Speicher-Array 400 in das Slave-Datenregister 404. Gleichzeitig beginnen die Datentransfers von dem externen Bus für den nächsten Programmiervorgang (Schritt 1) in das Master-Datenregister 403.
5. Vergleichen (430) der Daten in dem Slave-Register 404 mit denjenigen in dem Datenvergleichsregister 405. Das Ergebnis dieses Vergleichs wird in dem Statusregister 431 gespeichert, das beispielsweise von einem externen Controller gelesen werden kann.
6. Wenn der Vergleich nicht bestanden wird, kann der externe Controller die geeigneten Fehlerbehebungsmaßnahmen anwenden.

Bei einer alternativen Ausführungsform erfolgen Datentransfers von dem externen Bus zu dem Master-Datenregister 403 gleichzeitig mit einem oder mehreren Schritten der Schritte Programmieren, Zurücklesen von Daten und Vergleichen, und zwar in einem Prozess der "Stream-Programmierung". Es gibt viele alternative Möglichkeiten, Fehlerzustände zu behandeln. Diese können das Schreiben der Daten in einen anderen Bereich des Speichers und das Löschen des fehlerbehafteten Teils des Speichers oder Markieren desselben als schlecht, das Anwenden von mehr Impulsen ohne einen dazwischen erfolgenden Löschvorgang oder das Löschen und erneute Schreiben der Daten in denselben Bereich umfassen. Alternativ ist es möglich, keine Maßnahme zu ergreifen, wenn weniger als eine gewisse Anzahl von Fehlern vorhanden sind.
Die exakten Kosten, was die Zeitdauer und das Leistungsverhalten dieser Verifizierungsvorgänge betrifft, variieren in Abhängigkeit von der Dauer der verschiedenen Flash-Speicher-Vorgänge, der Größe des Datensatzes, der Breite des E/A-Busses und der Zykluszeit des E/A-Busses. Ein Beispiel für die Funktionsweise dieser Ausführungsform der Erfindung sei jedoch nachstehend unter Nutzung einiger typischer Werte gezeigt: TRD = 25 μs TX = 26,4 μs TPRG = 300 μs
Die Gesamtzeit zum Programmieren und Verifizieren eines einzelnen Sektors (wie in 4 gezeigt) beträgt: TPgm/Vfy = [TX + TPRG + TRD] = 351,4 μs
Dies stellt eine Verbesserung der Programmierzeit von 7% gegenüber dem Beispiel gemäß dem Stand der Technik mit einem einzigen Sektor dar.
Ein allgemeiner Trend beim Entwurf nichtflüchtiger Speicher geht dahin, die Anzahl der Zellen zu erhöhen, die gleichzeitig programmiert und gelesen werden können, um das Leistungsverhalten dieser Bauelemente hinsichtlich des Schreibens und Lesens zu verbessern. Dies kann erreicht werden, indem die Anzahl der Speicherzellen-Arrays auf einem einzigen Chip erhöht wird, indem die Größe der Speicherseite in einer einzelnen Ebene erhöht wird, indem mehrere Chips parallel programmiert werden oder durch eine Kombination dieser drei Verfahren. Infolgedessen erhöht sich aufgrund der größeren Anzahl der programmierten oder gelesenen Zellen die Datentransferlänge, wobei sich die Programmier- und Lesezeiten geringfügig oder überhaupt nicht ändern. Somit ist der Aufwand der Datenverifizierung in einem System mit einer solchen erhöhten Parallelität dementsprechend umso höher. Unter Nutzung des vorherigen Beispiels mit vier Sektoren ist TPgm/Vfy = 4·TX + TPRG + TRD = 426 μs
Dies stellt eine Verbesserung bezüglich der Programmierzeit von 20% gegenüber dem Beispiel gemäß dem Stand der Technik mit vier Sektoren dar.
7 stellt einen einzelnen, nach dem Programmieren erfolgenden Lese-Verifizierungsvorgang in den Schritten 4 und 5 dar. Dieser nach dem Programmieren erfolgende Lese- Verifizierungsvorgang muss von dem Verifizierungsprozess unterschieden werden, der als Teil des eigentlichen Programmierprozesses erfolgt und der gemäß dem Stand der Technik üblich ist. Der Vergleichsprozess aus 7 und gemäß den nachstehenden alternativen Ausführungsformen erfolgt getrennt von dem Programmierprozess und nach diesem, und dabei wird ein tatsächlicher Leseprozess genutzt, um die Daten bereitzustellen, die basierend auf dem Pegel der Zelle verglichen werden, wogegen bei dem Programmier-Verifizierungsprozess der Pegel der Zelle mit einem festen Sollwert verglichen wird.
Bei Programmier-Verifizierungsprozessen muss zwischen destruktiven und nicht-destruktiven Programmier-Verifizierungsschemata unterschieden werden. Bei einem destruktiven Programmier-Verifizierungsschema wird der Inhalt des Slave-Registers während des Programmier-Verifizierungsvorgangs korrumpiert, wenn die Speicherelemente auf den ordnungsgemäßen Pegel hin verifiziert werden. Der Inhalt des Registers wird als Rückkopplung für die Programmierschaltung genutzt, um anzuzeigen, ob für ein gegebenes Speicherelement eine weitere Programmierung erforderlich ist oder nicht; sobald der entsprechende Pegel verifiziert ist, wird der Inhalt des Registers, der dem verifizierten Speicherelement entspricht, gelöscht, um eine weitere Programmierung zu sperren. Der Programmiervorgang ist abgeschlossen, wenn sämtliche Inhalte des Slave-Registers gelöscht sind oder wenn der Verifizierungsstatus sämtlicher Speicherelemente eine erfolgreiche Programmierung anzeigt. Bei einem nicht-destruktiven Programmier-Verifizierungsschema wird der Inhalt des Slave-Registers nicht korrumpiert. Bei diesem Schema wäre es möglich, dass Speicherelemente weitere Programmierschritte erhalten, selbst nachdem für diese ein entsprechender Pegel verifiziert worden ist. Der Programmiervorgang würde enden, wenn sämtliche Speicherelemente einen programmierten Zustand erreicht hätten, wobei die Ermittlung dieses Zustands die Überwachung der Programmier-Verifizierungsergebnisse für sämtliche Speicherelemente erfordert, um einen Abschluss festzustellen. Gemäß dem Stand der Technik kommt bei Flash-Speicher-Bauelementen typischerweise ein destruktives Programmier-Verifizierungsschema zur Anwendung, und insbesondere in Mehrpegel-Bauelementen. Nicht-destruktive Verfahren können ebenfalls in Flash-Speicher-Systemen genutzt werden, wenn die Nutzung zusätzlicher Impulse die Verteilung der Zellenzustände nicht in übermäßigem Maße negativ beeinflusst. Nicht-destruktive Programmier-Verifizierungsschemata können auch in Speichersystemen mit anderen Formen von Speicherelementen, welche die zusätzliche Belastung tolerieren können, genutzt werden.
Die vorstehend mit Bezug auf 7 beschriebene Ausführungsform ermöglicht sowohl ein destruktives Programmier-Verifizierungsschema als auch eine Stream-Programmierung. Da eine Kopie der Daten in dem Vergleichsregister gespeichert ist, braucht das Slave-Register die Daten während der Programmierung nicht beizuhalten. Darüber hinaus ist das Master-Register, sobald es seinen Inhalt an das Vergleichs- und das Slave-Register transferiert hat, frei, um den nächsten Datensatz zu empfangen. Wenn auf eine Stream-Programmierung verzichtet wird, ein nicht-destruktives Programmier-Verifizierungsschema genutzt wird, oder beides, kann ein nach der Programmierung erfolgender Lese-Verifizierungsvorgang mit weniger Registern implementiert werden. Wenn bei dem Bauelement ein nicht-destruktives Programmier-Verifizierungsschema zur Anwendung kommt, wird das Vergleichsregister nicht benötigt, und die Daten in dem Slave-Register können direkt mit der Ausgabe des Leseverstärkers verglichen werden.
Bei einer alternativen Ausführungsform kann mehr als ein nach der Programmierung erfolgender Lese-Verifizierungsvorgang ausgeführt werden, zum Beispiel entweder nach jedem Schreibvorgang oder nur nach bestimmten Schreibvorgängen, die zum Beispiel durch die Anzahl der Schreibvorgänge spezifiziert werden, welche seit dem vorherigen Mehrfachverifizierungsvorgang erfolgt sind, in zufälliger Weise, basierend auf der seit dem vorherigen Mehrfachverifizierungsvorgang abgelaufenen Zeit, basierend auf einem Lösch-Verifizierungsfehler, basierend auf der Anzahl von Löschzyklen oder auf einem Programmier-Verifizierungsfehler. Die Verifizierungen können unter verschiedenen Bedingungen erfolgen, beispielsweise bei einem nominellen Spannungsschwellwert, einer unteren Toleranzgrenze eines Spannungsschwellwertes, einer oberen Toleranzgrenze eines Spannungsschwellwertes bei einem Spannungsmessschema, wie es später mit Bezug auf 13 beschrieben wird. Diese Nutzung unterschiedlicher Spannungspegel stellt einen weiteren Unterschied des nach dem Schreiben erfolgenden Lese-Verifizierungsprozesses gemäß der vorliegenden Erfindung zu dem herkömmlichen Verifizieren, das Teil des Programmiervorgangs ist, dar.
Ein Lösch-Verifizierungsfehler tritt auf, wenn von dem Speicher nach einem Löschvorgang ein Status Verifizierungsfehler zurückkommt, in welchem Fall der Löschvorgang wahrscheinlich fehlgeschlagen ist, wenngleich der Block hinreichend gelöscht sein kann, um ihn unter normalen Bedingungen zu nutzen. Dies ist auf die Tatsache zurückzuführen, dass bei der Lösch-Verifizierung für die Zellen möglicherweise überprüft wird, ob sie auf einen viel stärker gelöschten Zustand gelöscht sind als er eigentlich benötigt wird, wodurch ein breites Schutzband als für die normale Nutzung erforderlich bereitgestellt wird. Dies ist zum Beispiel in den US-Patenten 5,172,338 und 5,602,987 beschrieben. Eine alternative Möglichkeit zum Überprüfen, ob ein Block nach dem Löschen nutzbar ist oder nicht, besteht darin, nach dem Löschen einen Lesevorgang unter Bedingungen auszuführen, die darauf ausgerichtet sind, auf Löschfehler zu überprüfen, wobei die Grenzwerte generell so festgelegt sind, dass auf unzureichend gelöschte Zellen hin überprüft wird. Das Ausführen eines solchen Lesevorgangs nach jedem Löschen würde sich nachteilig auf das Leistungsverhalten des Systems auswirken, und somit wird es im Allgemeinen vermieden. Bei vielen Flash-Speichersystemen gemäß dem Stand der Technik wird der Verifizierungsstatus von Löschvorgängen ignoriert und es werden nur die Ergebnisse der nach dem Schreiben erfolgenden Lese-Verifizierungsvorgänge überprüft. Bei einer Ausführungsform gemäß der vorliegenden Erfindung wird nach dem Schreiben ein zusätzlicher Lese-Verifizierungsvorgang, der darauf ausgerichtet ist, auf unzureichend gelöschte Zellen hin zu überprüfen, nur für den Fall eines Status Lese-Verifizierungsfehler ausgeführt. Erfüllt der Block diese Lese-Verifizierungsbedingungen, wird der Block trotz des Lösch-Verifizierungsfehlers als unter normalen Bedingungen nutzbar betrachtet.
Das Aufrufen mehrerer Lese-Verifizierungsvorgänge basierend auf der Anzahl von Löschzyklen erfolgt analog dem Begründen der Entscheidung auf der Anzahl von Schreibvorgängen, die seit dem vorherigen Mehrfachverifizierungsvorgang erfolgt sind, da Löschvorgänge und Programmiervorgänge im Allgemeinen eins-zu-eins erfolgen. Bei einer Variante könnte die Nutzung mehrerer Verifizierungsvorgänge durch die Anzahl von Löschvorgängen ausgelöst werden, die seit dem vorherigen Mehrfachverifizierungsvorgang erfolgt sind, anstatt auf der Gesamtanzahl von Löschzyklen. US-Patent Nr. 5,095,344 diskutiert das Verfolgen der Anzahl von Löschzyklen in einem Flash-Speichersystem.
Was das Fehlerkriterium für die Programmier-Verifizierung zum Auslösen weiterer nach dem Schreiben erfolgender Lese-Vergleichsvorgänge betrifft, so sei erwähnt, dass die Programmier-Verifizierung den Status darstellt, der von dem Speicher nach einem Programmiervorgang zurückgesendet wird, welcher anzeigt, ob sämtliche Zellen auf den gewünschten Pegel oder über diesen hinaus programmiert worden sind oder nicht. Diese Programmier-Verifizierung unterscheidet sich von der nach dem Schreiben erfolgenden Lese-Verifizierung, die in der Erfindung spezifiziert wird, bei welcher es sich um ein tatsächliches Lesen der Zellen handelt, um deren spezifischen Zustand zu bestimmen. Bei der Programmier-Verifizierung wird generell nicht überprüft, ob die Zellen den Sollzustand überschritten haben, möglicherweise, im Falle von Mehrzustandsspeichern, bis hin zum nächsten Zustand.
8 stellt eine Implementierung mit drei Registern einer Ausführungsform mit zwei nach dem Schreiben erfolgenden Vergleichsverifikationen dar. Im Vergleich zu 7 sind die Schritte 6 und 7 hinzugekommen, für den zusätzlichen Vergleich. Der Prozess umfasst außerdem einen optionalen Transfer von Daten während Phase 3 (einen "Stream"-Programmierungsvorgang), der nicht explizit in 7 gezeigt ist, wenngleich er auch dort genutzt werden kann. Die Variante aus 8 unterscheidet sich außerdem von den vorherigen Sequenzen darin, dass die Einleitung eines Datentransfers für den nächsten Programmiervorgang mit der Einleitung des momentanen Programmiervorgangs anstatt mit der Lese-Verifizierung zusammenfällt. Wenn der Programmiervorgang länger dauert, ermöglicht dies eine längere Datentransferzeit parallel. Das entsprechende Taktungsdiagramm ist nachstehend in 12 dargestellt.
Die Abfolge der Ereignisse, die während eines Programmier/Verifizierungsvorgangs entsprechend der bevorzugten Ausführungsform der vorliegenden Erfindung auftritt, so wie sie in 8 gezeigt ist, umfasst:

1. Transfer von Daten von einer (nicht gezeigten) externen Controllerschaltung zu dem Master-Datenregister 403.
2. Transfer des Inhalts des Master-Datenregisters 403 zu dem Slave-Datenregister 404 und dem Datenvergleichsregister 405, zum Beispiel gleichzeitig. Alternativ kann das Datenvergleichsregister 405 nach dem Laden des Slave-Datenregisters 404, aber vor Schritt 5, geladen werden.
3. Programmieren der Daten von dem Slave-Datenregister 404 in das Speicher-Array 400. i. Sobald der Inhalt des Master-Datenregisters 403 in das Slave-Datenregister 404 und das Datenvergleichsregister 405 übertragen ist, beginnen Datentransfers von dem externen Bus für den nächsten Programmiervorgang (Schritt 1) in das Master-Datenregister 403. Diese können gleichzeitig mit der Programmierung beginnen.
4. Zurücklesen der Daten aus dem Speicher-Array 400 in das Slave-Datenregister 404 unter Bedingungen, die für die gegebene Iteration der Lese-Verifikation gewünscht werden.
5. Vergleichen (430) der Daten in dem Slave-Register 404 mit denjenigen in dem Datenvergleichsregister 405. Das Ergebnis dieses Vergleichs wird in dem Status- Register 431 gespeichert, welches beispielsweise von einem externen Controller gelesen werden kann.
6. Bestimmen, ob eine oder mehrere zusätzliche Lese-Verifizierungen erfolgen sollen, beispielsweise aufgrund eines der zuvor erwähnten Kriterien. Wiederholen der Schritte 4 bis 5 für sämtliche gewünschte Iterationen unter den gewünschten und möglicherweise anderen Lesebedingungen für jede Iteration.
7. Wenn der Vergleich nicht bestanden wird, kann der externe Controller die geeigneten Fehlerbehebungsmaßnahmen anwenden, wie zuvor beschrieben.

Wie zuvor variieren die exakten Kosten hinsichtlich Zeit/Leistungsverhalten dieser Verifikationsvorgänge; bei Verwendung derselben exemplarischen Werte wie zuvor für die Dauer der einzelnen Vorgänge ergibt sich jedoch für das Beispiel mit einem einzigen Sektor aus 4 gemäß dem Stand der Technik bei zwei Vergleichsverifikationen nach dem Schreiben: TPgm/Vfy = TX + TPRG + TRD + TX + TRD + TX = 429 μs
Für das Beispiel gemäß dem Stand der Technik mit vier parallelen Sektoren ergibt sich bei zwei Vergleichsverifikationen nach dem Schreiben: TPgm/Vfy = 4·TX + TPRG + TRD + 4·TX + TRD + 4·TX = 666 μs
Für die Ausführungsform gemäß der Erfindung, wie sie in 8 gezeigt ist, dem Beispiel mit einem einzigen Sektor, ergibt sich: TPgm/Vfy = TX + TPRG + TRD + TRD = 376 μs,und für den Fall des Beispiels mit vier parallelen Sektoren: TPgm/Vfy = 4·TX + TPRG + TRD + TRD = 455 μs
Dies stellt eine Verbesserung von 12% bzw. eine Verbesserung von 32% dar. Man beachte, dass bei diesen Einsparungen nicht die Verbesserungen im Leistungsverhalten aufgrund der Stream-Programmierung berücksichtigt sind, die erzielt werden, indem die in die nachfolgenden Sektoren zu programmierenden Daten während der Programmierung der momentanen Sektoren transferiert werden.
Bei den bis hierher beschriebenen Ausführungsformen werden überall getrennte Register genutzt, nämlich das Datenvergleichsregister 405, um eine Kopie der Daten zu speichern, und das Slave-Datenregister 404, um die zu der Lese/Schreibschaltung 454 und von dieser transferierten Daten zu halten. Bei einer alternativen Gruppe von Ausführungsformen wird bei einer Implementierung mit zwei Registern nur ein Master-Register und ein Slave-Register genutzt, wobei das Master-Register auch als Vergleichsregister dient. Bei einer solchen Ausführungsform ist es möglich, den Datenvergleich auszuführen es wäre aber nicht möglich, den nächsten Datentransfer von dem Host in den Flash-Speicher-Controller zu beginnen, bevor nicht der vollständige Programmier/Verifizierungsvorgang abgeschlossen ist.

Sowohl eine einzelne Vergleichsverifizierung nach dem Schreiben als auch eine mehrfache Vergleichsverifizierung nach dem Schreiben, die für die Ausführungsform mit drei Registern in den 7 bzw. 8 gezeigt sind, kann bei Ausführungsformen mit zwei und einem Register genutzt werden. Bei einer Ausführungsform mit zwei Registern wird entweder eine Stream-Programmierung ausgeschlossen oder es muss ein nicht-destruktives Programmier-Verifizierungsschema genutzt werden; bei einer Ausführungsform mit einem einzigen Register kommen beide Maßnahmen zur Anwendung, wie in der nachstehenden Aufstellung beschrieben ist.

Prog.-Verifizierg. Anz. d. Register	destruktiv	nicht-destruktiv
1	nicht möglich	keine Stream-Programmierung Vgl. MasterReg-Auslesung
2	keine Stream-Programmierung Vgl. MasterReg-SlaveReg oder Vgl. MasterReg-Auslesung	Stream-Programmierung Vgl. SlaveReg-Auslesung
3	Stream-Programmierung Vgl. VglReg-SlaveReg oder Vgl. VglReg-Auslesung	Stream-Programmierung Vgl. SlaveReg.-Auslesung Zusatzregister oder Vgl. SlaveReg-VglReg

Der erste Eintrag der Aufstellung in dem Block destruktiv für 3 Register stellt den mit Bezug auf die 7 und 8 beschriebenen Prozess dar. Bei einer Variante kann das Vergleichsregister (VglReg) direkt mit der Ausgabe des Leseprozesses verglichen werden, analog dem Prozess, der nachstehend für die nicht-destruktive Ausführungsform mit 1 Register beschrieben wird. Beim destruktiven Fall mit 2 Registern ist, da das Vergleichsregister (VglReg) nicht vorhanden ist, keine Stream-Programmierung möglich, da das Master-Register eine Kopie der Daten für den Vergleich mit entweder dem Slave-Register (SlaveReg) oder der Auslesung beibehält. Ein destruktiver Prozess mit 1 Register ist nicht möglich, da hier keine intakte Kopie der Daten in dem Speicher zur Nutzung für den Vergleich vorhanden sein wird.
In der Spalte nicht-destruktiv ermöglicht eine Ausführungsform mit 3 Registern eine Stream-Programmierung, da das Master-Register frei ist, sobald es den aktuellen Datensatz transferiert hat. In diesem Fall kann wie bei dem destruktiven Fall das Ergebnis der Programmierung gelesen werden und in dem Slave-Register gespeichert werden und mit dem Inhalt des Vergleichsregisters verglichen werden. Alternativ kann, da das Slave-Register eine Kopie der Daten hält, diese gespeicherte Kopie in dem Slave-Register direkt mit der Auslesung verglichen werden, in welchem Falle das Vergleichsregister redundant ist. Das Weglassen dieses nun redundanten Vergleichsregisters führt zu dem nicht-destruktiven Fall mit 2 Registern. Wenn anstatt der Nutzung eines Slave-Registers die nicht-destruktive Programmierung von Daten direkt von dem Master-Register aus erfolgt, ist eine Anordnung mit 1 Register möglich, wobei die in dem Master-Register beibehaltenen Daten direkt mit der Auslesung verglichen werden. Bei dieser Anordnung mit einem einzigen Register ist eine Stream-Programmierung nicht möglich. Man beachte zum Vorstehenden, dass der direkte Vergleich mit der Auslesung bei jedem Schema erfolgen kann.
9 zeigt ein Beispiel für eine Realisierung mit zwei Registern mit einer nicht-destruktiven Programmier-Verifizierung und zwei Schreib-Vergleichsverifizierungsvorgängen. Die Aufgaben des Master- und des Vergleichsregisters werden von einem einzigen Register gemeinsam ausgeführt, sodass 405 und 403 aus 5 nun dasselbe sind, wobei 430 nun an einem Eingang mit 404 und an dem anderen mit dem Master-Datenregister 403/405 verbunden ist. Das Master-Register behält die Daten nach der Programmierung bei, um den Vergleich auszuführen.
Der Prozess für die Ausführungsform aus 9 ähnelt dem mit Bezug auf 8 beschriebenen:

1. Transfer der Daten von einer (nicht gezeigten) externen Controllerschaltung zu dem Master-Datenregister 403.
2. Transfer des Inhalts des Master-Datenregisters 403 zu dem Slave-Datenregister 404. Die Daten werden in dem Master-Datenregister 403 beibehalten.
3. Programmieren der Daten von dem Slave-Datenregister 404 in das Speicher-Array 400. Da das Master-Datenregister 403 eine Kopie dieser Daten beibehält, kann in diesem Fall keine Stream-Programmierung erfolgen, es sei denn es stehen zusätzliche Register zur Verfügung.
4. Zurücklesen der Daten aus dem Speicher-Array 400 in das Slave-Register 404 unter Bedingungen, die für die gegebene Iteration der Lese-Verifikation gewünscht werden.
5. Vergleich (430) der in dem Slave-Register 404 vorhandenen Daten mit denen in dem Master-Datenregister 403. Das Ergebnis dieses Vergleichs wird in dem Statusregister 431 gespeichert, welches beispielsweise von einem externen Controller gelesen werden kann.
6, 7. Wenn eine oder mehrere zusätzliche Lese-Verifizierungen erfolgen sollen, beispielsweise aufgrund eines der zuvor erwähnten Kriterien, werden in den Schritten 6 und 7 die Schritte 4 und 5 für sämtliche gewünschten Iterationen unter den für die jeweilige Iteration gewünschten Lesebedingungen wiederholt. Wenn der Vergleich nicht bestanden wird, kann der externe Controller wie zuvor die geeigneten Fehlerbehebungsmaßnahmen anwenden.

Sowohl der einzelne nach dem Schreiben erfolgende Vergleichsverifizierungsprozess als auch der mehrfache nach dem Schreiben erfolgende Vergleichsverifizierungsprozess können mit einem einzelnen Register ausgeführt werden, wenn ein nicht-destruktives Programmier-Verifizierungsschema genutzt wird. 10 stellt eine solche Anordnung für einen zweiteiligen Schreib-Vergleichsverifizierungsvorgang dar. Bei dieser Gruppe von alternativen Anordnungen erfolgt der Vergleich gleichzeitig mit dem Ende des Lese-prozesses, anstatt dass die Lesedaten in einem Register gespeichert werden und der gespeicherte Inhalt dieses Registers verglichen wird. Das Slave- und das Vergleichsregister (405 bzw. 404) aus 5 sind nun nicht vorhanden, wobei 430 nun an einem Eingang mit der Leseschaltung SA/PROG 454 und an dem anderen mit dem Master-Datenregister 403 verbunden ist. Wie bei 9 werden die Daten in dem Master-Datenregister 403 beibehalten; im Gegensatz zu 9 wird das Array von dem Master-Datenregister aus programmiert, ohne dass der Datensatz zerstört wird. Der Prozess für einen zweiteiligen nach dem Schreiben erfolgenden Vergleichsverifizierungsprozess in der in 10 gezeigten Ausführungsform läuft folgendermaßen ab:

1. Transfer der Daten von einer (nicht gezeigten) externen Controllerschaltung zu dem Master-Datenregister 403.
2. Programmieren der Daten aus dem Master-Datenregister 403 in das Speicher-Array 400. Die Daten werden in dem Master-Datenregister 403 beibehalten. Da das Master-Datenregister 403 eine Kopie dieser Daten beibehält, kann in diesem Fall keine Stream-Programmierung erfolgen, es sei denn es stehen zusätzliche Register zur Verfügung.
3. Zurücklesen der Daten aus dem Speicher-Array 400 unter Bedingungen, die für eine gegebene Iteration der Lese-Verifizierung gewünscht werden, und direkter Vergleich mit den Daten in dem Master-Datenregister 403. Das Ergebnis dieses Vergleichs wird in dem Status-Register 431 gespeichert, das beispielsweise von einem externen Controller gelesen werden kann.
4. Wenn eine oder mehrere zusätzliche Lese-Verifizierungen ausgeführt werden sollen, beispielsweise aufgrund eines der vorstehend erwähnten Kriterien, wird in Schritt 4 der Schritt 3 für sämtliche gewünschte Iterationen unter den für die jeweilige Iteration gewünschten Lesebedingungen wiederholt. Wenn der Vergleich nicht bestanden wird, kann der externe Controller wie zuvor die entsprechenden Fehlerbehebungsmaßnahmen anwenden.

Bei einer Variante der Anordnung mit einem einzigen Register gemäß 10 kann ein zweites Register 403 bereitgestellt werden, sodass dieses in einem Stream-Prozess mit den nächsten Daten geladen werden kann, während unter Nutzung des ersten Master-Datenregisters 403 die Schritte 1–4 ausgeführt werden. Nachdem der Prozess für das erste Register 403 abgeschlossen ist, wird die Rolle der beiden Master-Datenregister 403 vertauscht.
Die 11 und 12 stellen zwei Taktungsdiagramme dar, um die Nutzung der Stream-Programmierung zu veranschaulichen, nämlich den Vorgang, Daten auszugeben, die für die Programmierung nachfolgender Sektoren bestimmt sind, während die momentan in den Registern befindlichen Daten programmiert werden, und zwar bei Ausführungsformen, die diesen Prozess ermöglichen.
Das Diagramm aus 11 zeigt ein gemäß dem Stand der Technik bekanntes Beispiel eines parallelen Programmiervorgangs für zwei Sektoren, auf den jeweils ein einzelner Lesevorgang folgt und der auf einem anderen Protokoll basiert, als es in den 3 und 6 genutzt wird. Das exemplarische Protokoll aus 11 und auch das nachstehende aus 12 sind flexibler und anschaulicher, sodass eine einfachere Erklärung der Konzepte möglich ist. Um kurz die dargestellte Schnittstelle zu erklären, sei gesagt, dass die Leitung ALE aktiv hoch ist, wenn eine Adresse an den Speicher ausgegeben wird, die Leitung CLE aktiv hoch ist, wenn ein Befehl an den Speicher ausgegeben wird, die Leitung WE Daten, Adressen und Befehle taktet, die in den Speicher geschrieben werden, die Leitung RE Daten, Adressen und Befehle taktet, die aus dem Speicher gelesen werden, die Leitung R/B aktiv niedrig ist, wenn das Speicherbauelement einen Lese-, Schreib- oder Löschvorgang an dem Speicher-Array ausführt. Die Sequenzen C1.A und C1.B stellen Leseprozesse dar, bei denen die Daten von dem Speicherbauelement herunter transferiert werden, und zwar bei DATA N bzw. DATA N + 2 auf der Leitung I/O, wenn RE niedrig wird. Die Ausführungsform aus 11 kann auf einen Fall mit zwei Lesevorgängen für jeden Sektor erweitert werden, indem zum Beispiel die Sequenzen C1.A und C1.B wiederholt werden und indem jede Gruppe von Sequenzen mit einem anderen Befehl begonnen wird. Zum Beispiel können die Sequenzen einmal ausgegeben werden, wobei sie jeweils mit einem Befehl READ1 CMD beginnen, und dann erneut mit READ2 CMD, um andere Lesebedingungen anzuzeigen. Eine alternative Ausführungsform kann das Ausgeben eines gewissen Satzes von Parametern in Form von Daten vor jedem Lesebefehl beinhalten.
Bei gemäß dem Stand der Technik bekannten Implementierungen einer ähnlichen Schnittstelle wie der in 11 dargestellten bleibt wird jede Aktivität über die Schnittstelle ignoriert, während der Teil belegt ist, wenngleich es für den Aspekt der Implementierung der Stream-Programmierung der vorliegenden Erfindung erforderlich wäre, dass das Speicherbauelement dies gestattet. Die Diagramme aus den 11 und 12 stellen eine mögliche Implementierung im Rahmen der Schnittstelle dar, und andere Taktungsdiagramme sind möglich. Mit XFER CMD wird ein Datentransfer zu dem Speicherbauelement eingeleitet, und mit CACHE CMD wird ein Datentransfer zu dem Speicher abgeschlossen. PGM CMD kann genutzt werden, um den Transfer von Daten aus dem Master-Register zu dem Slave- und dem Vergleichsregister auszulösen. Sowohl die ADDR-Phase als auch die DATA-Phase werden in der Praxis aus mehreren Zyklen bestehen. Nach dem Datenschreibvorgang, welcher erfolgt, wenn die Leitung R/B zum ersten Mal niedrig wird, liefern STAT CMD und STAT den Status der Programmiervorgänge, einschließlich der Programmier-Verifizierungsphase, bei welcher festgestellt wird, ob die Soll-Pegel erreicht worden sind. Wiederum findet die Verifizierung, die als Teil des Programmierungsvorgangs erfolgt, getrennt von dem Prozess gemäß der vorliegenden Erfindung statt, welcher auf einem Lesevorgang basiert und nach dem Abschluss des Schreibprozesses erfolgt.
12 zeigt ein partielles Taktungsdiagramm für ein Beispiel eines parallelen Programmiervorgangs für zwei Sektoren mit "Stream-Programmierung", auf welche eine einzige Vergleichsverifizierung für jeden Sektor folgt. Dieses Basisdiagramm enthält die Elemente für eine Reihe von unterschiedlichen Ausführungsformen, wenn die verschiedenen Elemente umgeordnet, geändert und wiederholt werden oder weggelassen werden.
Bei einer ersten Gruppe von Ausführungsformen erfolgt eine parallele Programmierung zweier Sektoren, eine Stream-Programmierung und eine einzige Vergleichsverifizierung nach dem Schreiben. Dies ist das Beispiel, das in 12 gezeigt ist. Nach dem Transfer der ersten beiden Datensektoren (N und N + 1) werden diese beiden Sektoren in das Speicher-Array programmiert, wenn R/B niedrig ist. Während diese Sektoren geschrieben werden, werden die nächsten beiden Sektoren (N + 2 und N + 3) in das Master-Datenregister transferiert, in der Sequenz C2.A. (Für diese spezielle Variante würde man eine Implementierung mit drei Registern oder eine nicht-destruktive Implementierung mit zwei Registern, bei welcher die Ausgabe des Arrays direkt mit dem Register verglichen wird, nutzen.) Darauf folgt eine Sequenz C2.B, in welcher die an der Adresse N gespeicherten Daten gelesen und verglichen werden, und eine Sequenz C2.C, in welcher die an der Adresse N + 1 gespeicherten Daten gelesen und verglichen werden. Der Rest der Sequenz C2.C, der sich über den in dem Diagramm gezeigten Teil hinaus fortsetzt, wird wie in Sequenz C2.B beendet.
Es kann gewählt werden, an welcher Stelle in der Sequenz der neue Datentransfer der Sequenz C2.A begonnen wird. Die in den 3 und 6 gezeigten Beispiele zeigen, dass der Datentransfer nach dem eigentlichen Programmiervorgang und während der nachfolgenden Lese-Verifizierung beginnt. Da die Lesevorgänge im Vergleich zu der Gesamtdauer mehrerer Datentransfers, die für einen parallelen Programmiervorgang erforderlich sind, relativ kurz dauern, würde ein Teil der Datentransferzeit nicht parallel zu dem Flash-Speicher-Betrieb erfolgen. Jede Datentransferzeit zusätzlich zu der Speicher-Betriebszeit wird das Leistungsverhalten im Vergleich zu dem Fall, bei dem alles parallel erfolgt, verschlechtern. Die 11 und 12 zeigen, dass der Datentransfer während des Programmiervorgangs beginnt. Da der Programmiervorgang lange dauert und auf diesen die Lese-Verifizierungsvorgänge folgen, wird ein viel größerer Anteil der Datentransferzeit parallel zu den Speicheroperationen liegen. Dies wird zu einer geringeren Verschlechterung des Leistungsverhaltens, wenn überhaupt, führen. In 12 müssen die Signale STAT CMD und STAT, die zwischen der Sequenz C2.A und der Sequenz C2.B auftreten, von den Signalen STAT CMD und STAT unterschieden werden, die innerhalb der Sequenz C2.B und der Sequenz C2.C auftreten. STAT CMD und STAT zwischen den Sequenzen C2.A und C2.B liefern den Status der Programmiervorgänge, die ausgeführt werden, während das Signal R/B niedrig ist, einschließlich der Programmier-Verifizierungsphase, bei welcher ermittelt wird, ob die Sollpegel erreicht worden sind. STAT CMD und STAT, die Teil der Sequenzen C2.B und C2.C sind, liefern den Status der nach dem Schreiben erfolgenden Lese-Verifizierungsvorgänge gemäß der vorliegenden Erfindung. Allgemeiner gesagt können bei alternativen Ausführungsformen unterschiedliche Befehle verwendet werden, wovon der eine Befehl für den Programmier-Verifizierungsstatus und der anderen für den Lese-Verifizierungsprozess bestimmt ist. Beim Vergleich der Sequenz C2.B aus 12 mit der Sequenz C1.A sollte beachtet werden, dass die Sequenz C1.A damit endet, dass Daten aus dem Speicher transferiert werden, während bei der Sequenz C2.B nur der Status übertragen wird. Bei einer alternativen Ausführungsform können die Daten parallel verglichen werden, und die Sequenz C2.B kann derart geändert werden, dass beide Adressen ausgegeben werden. Zum Beispiel könnte die kombinierte Sequenz C2.B/C2.C lauten: CMP1 CMD, ADDR N, ADDR N + 1, CMP EXEC CMD, STAT CMD, STAT, wobei der zusätzliche Befehl CMP EXEC CMD genutzt wird, um anzuzeigen, dass sämtliche zu vergleichende Adressen ausgegeben worden sind.
Bei einer weiteren alternativen Ausführungsform kann der Speicher die Vergleichssequenzen automatisch nach einem Programmiervorgang ausführen, sodass die Sequenzen C2.B und C2.C nicht erforderlich sind, in welchem Falle die Statusphase nach dem Programmiervorgang den Status des Vergleichs umfassen würde.
Bei einer weiteren Gruppe von Ausführungsformen erfolgt eine parallele Programmierung zweier Sektoren, eine Stream-Programmierung sowie mehrere Vergleichsverifizierungen nach dem Schreiben. Diese Sequenz kann auf den Fall zweier Vergleiche für jeden Sektor erweitert werden, z. B. durch Wiederholen der Sequenzen C2.B und C2.C und indem jeder Satz von Sequenzen mit einem anderen Befehl begonnen wird. Zum Beispiel werden die Sequenzen erstellt, indem einmal mit einem Befehl CMP1 CMD begonnen wird, und dann erneut mit CMP2 CMD, um andere Lesebedingungen anzuzeigen. Eine alternative Ausführungsform kann das Ausgeben eines gewissen Satzes von Parametern beinhalten, beispielsweise Spannungspegelwerten, die für das Lesen genutzt werden sollen, und zwar in Form von Daten vor jedem Lesebefehl. Bei einer weiteren Ausführungsform kann der Speicher die nach dem Schreiben erfolgenden Vergleiche auto matisieren, wie vorstehend beschrieben, wobei die Statusphase der Programmierung den Status des Vergleichs umfassen würde.
Bei einer noch weiteren Gruppe von Ausführungsformen erfolgt eine Programmierung zweier Sektoren, keine Stream-Programmierung, und eine beliebige Anzahl von Vergleichsverifizierungen nach dem Schreiben. Diese Ausführungsformen können bei den Anordnungen mit zwei oder einem Register aus den 9 und 10 implementiert werden. Die Sequenz kann geändert werden, sodass die Programmierung ohne Stream-Programmierung erfolgt, indem die Sequenz C2.A von ihrem Platz in dem Diagramm entfernt wird. Die Daten, die für die nachfolgenden Sektoren bestimmt sind, würden in einer Sequenz wie in der modifizierten 12 ausgegeben, aber mit den Adressen N + 2 und N + 3. Alle zuvor beschriebenen alternativen Ausführungsformen gelten.
Wie bereits erwähnt, können unterschiedliche Lesebedingungen für den Leseprozess der nach dem Schreiben erfolgenden Vergleichsverifizierung genutzt werden. Für Ausführungsformen, bei denen mehrere Vergleichsverifizierungen genutzt werden, kann jeder der mehreren einzelnen Lesevorgänge, die für die mehreren Vergleiche genutzt werden, mit einer unterschiedlichen Lesegrenzbedingung erfolgen. Die folgende Diskussion erfolgt anhand von nichtflüchtigen Mehrzustands-Speichereinheiten, wobei der binäre Fall in einfacher Weise daraus folgt. Obgleich außerdem in den Beispielen ein paralleler Betrieb für zwei Sektoren gezeigt ist, gilt die Erfindung auch für den Fall nur eines Sektors oder einer beliebigen Anzahl paralleler Sektoren.
13 stellt eine exemplarische Verteilung von Zellenpopulationen und Lesegrenzbedingungen in einem Vierzustands-Speicher dar und zeigt zwei mögliche Sätze von Lesegrenzbedingungen, einen, der zu hoch programmierten Zuständen hin ausgerichtet ist, und einen, der zu niedrig programmierten Zuständen hin ausgerichtet ist. Weitere Details zu den verschiedenen Grenzpegeln und deren Anwendung sind in US-Patent Nr. 5,532,962 und in der US-Patentanmeldung Nr. 09/671,793, eingereicht am 27. September 2000 und als US 6,538,922 veröffentlicht, angegeben.
Das in 13 gezeigte Beispiel stellt das eines Strommess-Speichersystems dar, bei welchem die Stromstärke der Speichereinheit unter bestimmten Lesebedingungen mit einem Satz von Referenzstromstärken verglichen wird. Bei anderen Speichersystemen kann der Zustand einer Speichereinheit mithilfe einer Reihe anderer Parameter ermittelt werden. Bei den nachstehenden Beispielen kann die Ermittlung des gespeicherten Ladungspegels einer Zelle durch Stromstärkemessung erfolgen, wobei die Stärke der Leitfähigkeit der Zelle unter Anwendung festgelegter Vorspannungsbedingungen ermittelt wird. Alternativ kann diese Ermittlung über die Ermittlung einer Schwellspannung erfolgen, wobei das Einsetzen einer solchen Leitfähigkeit unter Nutzung variierender Steuergate-Vorspannungsbedingungen ermittelt wird. Diese Verfahren stellen eine Reihe der standardmäßigeren Ansätze dar.
Alternativ könnte die Ermittlung dynamisch erfolgen, indem man die Entladungsrate eines dynamisch gehaltenen (z. B. durch einen Vorladekondensator) Leseknotens von der durch den Ladungspegel der Zelle bestimmte Ansteuerstärke steuern lässt. Durch Ermitteln der Zeit bis zum Erreichen eines gegebenen Entladungspegels wird der gespeicherte Ladungspegel bestimmt. In diesem Fall stellt der den Zustand der Zelle anzeigende Parameter eine Zeit dar. Dieser Ansatz ist in US-Patent Nr. 6,222,762 und in der US-Patentanmeldung mit dem Titel "Sense Amplifier for Multilevel Non-Volatile Integrated Memory Devices" von Shahzad Khalid, eingereicht am 20. November 2001, beschrieben. Ein weiteres alternatives Verfahren ist ein solches, bei dem der Zustand der Speichereinheiten unter Nutzung einer Frequenz als Parameter ermittelt wird, ein Ansatz, der in US-Patent Nr. 6,044,019 beschrieben ist.
Derzeitige Leseansätze sind eingehender in US-Patent 5,172,338 und in der US-Patentanmeldung mit dem Aktenzeichen 08/910,947 (veröffentlicht als US 6,222,762 ) ausgeführt und können bei den verschiedenen beschriebenen Ausführungsformen der vorliegenden Erfindung angewendet werden. Der Ansatz mit Ermittlung der Schwellspannung V_th (alternativ als Spannungseingrenzung bezeichnet) kann in einigen Fällen vorzuziehen sein, da bei diesen die Leseauflösung verbessert wird, die Stromstärke und folglich die mit massiven parallelen Lesevorgängen in Zusammenhang stehende Leistungsaufnahme niedrig gehalten werden und die Empfindlichkeit gegenüber einem hohen Bitleitungswiderstand minimiert wird. Der Ansatz mit Ermittlung von V_th, oder Spannungseingrenzung, ist vollständiger in US-Patent Nr. 6,222,762 ausgeführt. Ein weiteres Verfahren der Spannungsermittlung, bei dem die Spannung an der Source-Elektrode für eine feststehende Drain-Spannung unter Ansprechen auf eine gegebene Gate-Spannung ermittelt wird, ist die Source-Folgetechnik, die zum Beispiel in der US-Patentanmeldung mit dem Aktenzeichen 09/671,793 (veröffentlicht als US 6,538,922 ) beschrieben ist.
14 stellt eine exemplarische Möglichkeit für das Ändern der Lesebedingungen dar. Dieses Beispiel zeigt ein Stromstärkeermittlungsverfahren, bei welchem eine Grenzstrom stärke zu der Referenzstromstärke addiert wird, wobei die Summe aus diesen mit der Ausgangsstromstärke der Zelle verglichen wird. Das Beispiel zeigt einen parallelen Lesevorgang für die drei Messpunkte und erfordert, dass alle Referenzpegel gleichzeitig präsentiert werden, wogegen das Lesen bei einer anderen Ausführungsform mehrere Stufen einer Durchsuchung des Referenzraums mit einer einzelnen Referenzspannung oder Stromstärke beinhalten kann. Bei einem mehrfachen Vergleichsprozess könnten sich die Stromstärkegrenzwerte für die unterschiedlichen Vergleiche ändern. Die Art des Lesevorgangs wird von dem speziellen Schema abhängen. Bei der exemplarischen Ausführungsform aus 14 werden drei Referenzstromstärken genutzt, um die vier Zustände zu unterscheiden, während bei anderen Ausführungsformen vier Referenzstromstärken genutzt werden könnten, wie eingehender in den US-Patenten Nr. 5,172,338 und 5,095,344 ausgeführt ist.
Die verschiedenen Aspekte der vorliegenden Erfindung können auch für den Fall einer Adressierung durch Pegel in Mehrzustands-Speichersystemen genutzt werden. Dieses Schema beinhaltet das Abbilden zweier separat adressierbarer Host-Datensektoren, die als "obere Speicherseite" und "untere Speicherseite" bezeichnet werden, auf denselben Satz von Zellen in einem Vier-Zustands-Speicher. Bei diesem Schema wird jedes Bit Daten der unteren Speicherseite auf einen von zwei Zellenzuständen einer gegebenen Zelle programmiert, und jedes Bit Daten der oberen Speicherseite wird derart programmiert, dass der Zustand der jeweiligen gegebenen Zelle basierend auf dem Wert des gegebenen Bits modifiziert wird. Dieses Schema lässt sich auf eine höhere Anzahl von Zuständen pro Zelle erweitern. Dies ist vollständiger in der US-Patentanmeldung mit dem Aktenzeichen 09/893,277, eingereicht am 27. Juni 2001 (veröffentlicht als US 6,522,580 ) beschrieben und wird hier kurz dargestellt. 15 zeigt eine solche Ausführungsform einer Zustandszuweisung für eine Vier-Zustands-Zelle sowie die Nutzung in einem solchen Schema mit exemplarischen Spannungswerten.
16 zeigt eine Registernutzung für eine Implementierung der vorliegenden Erfindung in einem Schema mit Adressierung über Zustand. In dem Diagramm ist gezeigt, dass es zum Lesen der untere Speicherseite erforderlich ist, zunächst mit der Granularität der oberen Speicherseite (Unterscheidungspunkt 0,8 V in 15) zu lesen und die Ergebnisse in einem Register, dem Register 1 (404a) zu speichern. Schritt 1 stellt einen normalen Lesevorgang der oberen Speicherseite dar, und Schritt 2 nutzt die zuvor gelesenen Daten der oberen Speicherseite, um die Bedingung für den nachfolgenden Lesevorgang der unteren Speicherseite festzulegen. Die untere Speicherseite wird während der zweiten Lesestufe in ein zweites Register, das Register 2 (404b) gelesen, wobei die Daten der oberen Speicherseite zurück in die Leseschaltung geführt werden, um die geeigneten Lesebedingungen auf bitweiser Basis festzulegen. Somit sind für einen einzigen Lesevorgang effektiv zwei Register erforderlich. Man beachte jedoch, dass nur eines der beiden Register für den Vergleich mit dem Vergleichsregister erforderlich ist, da es die fraglichen Daten enthalten wird. Für einen Lesevorgang der oberen Speicherseite sind nur eine Lesestufe und ein Register erforderlich. Um die Fähigkeiten zur Stream-Programmierung zu ergänzen, wird ein viertes Register, ein Register 4 (403), als Master-Register hinzugefügt. Einige Speicher können sowohl mit zwei als auch mit vier Zuständen betrieben werden. Bei einem Zwei-Zustands-Modus kann der Speicher das zusätzliche Register, das Register 1 (404a), das im Mehrzustands-Modus für den Lesevorgang der ersten Phase erforderlich ist, für andere Zwecke nutzen, beispielsweise zur Stream-Programmierung.
Im Vier-Zustands-Betrieb dienen das Register 1 (404a) und das Register 2 (404b) beide als Slave-Register, das Register 3 (405) stellt ein Vergleichsregister dar, und das Register 4 (403) dient als das Master-Register. Bei einem Betriebsmodus mit zwei Zuständen können die Register bezogen auf die vorherigen Diagramme folgendermaßen beschrieben werden: das Register 1 (404a) wäre das Slave-Register, das Register 4 (403) wäre das Master-Register, das Register 3 (405) wäre das Vergleichsregister, und für das Register 2 (404b) ist momentan keine Nutzung geplant. Bei einer Implementierung gemäß dem Stand der Technik, bei dem das vorstehende Leseschema mit oberer Speicherseite/unterer Speicherseite genutzt wird, fehlen das Register 3 (405) und das Register 4 (403), und es sind nur die beiden Register 1 (404a) und Register 2 (404b) vorhanden. Das Register 3 (405) und das Register 4 (403) werden für die Zwecke der Erfindung ergänzt.
Viele Aspekte der vorliegenden Erfindung beziehen sich nicht speziell auf die Details des Typs von Speichereinheit, der in dem Speicher-Array genutzt wird. Wenngleich die Diskussion bis hierher auf Ausführungsformen konzentriert war, bei denen ein Ladung speicherndes Bauelement, beispielsweise EEPROM- oder Flash-Zellen mit Floating-Gate, für das Speicherbauelement genutzt wird, kann die Erfindung auf Speichersysteme angewandt werden, bei denen andere Formen von Speichereinheiten genutzt werden. Die vorliegende Erfindung kann in Speichersystemen genutzt werden, die Sub-0,1 μm-Transistoren, Einzelelektronentransistoren, Nanotransistoren auf organischer/Kohlenstoffbasis und Molekulartransistoren enthalten, aber nicht ausschließlich. Zum Beispiel könnten auch solche NROM- und MNOS-Zellen genutzt werden, wie sie in US-Patent 5,768,192 von Eitan und in US-Patent 4,630,086 von Sato et al. beschrieben sind, oder solche magnetischen RAM- und FRAM-Zellen, wie sie in US-Patent 5,991,193 von Gallagher et al. bzw. in US-Patent 5,892,706 von Shimizu et al. beschrieben sind. Für diese anderen Zellentypen können die speziellen Mechanismen der Lese- und Schreibprozesse abweichen, die Erweiterung der verschiedenen Aspekte gemäß der vorliegenden Erfindung auf diese folgt jedoch in einfacher Weise aus den vorstehenden Beispielen.
Es sollte verstanden werden, dass, wenngleich zahlreiche Merkmale und Vorteile bestimmter Ausführungsformen der vorliegenden Erfindung in der vorstehenden Beschreibung ausgeführt worden sind, zusammen mit Details bezüglich der Struktur und Funktion verschiedener Ausführungsformen der Erfindung, diese Offenbarung lediglich der Veranschaulichung dient, und dass im Rahmen der Prinzipien der vorliegenden Erfindung in ihrem vollen Umfang, der durch die breite allgemeine Bedeutung der in den anhängenden Ansprüchen ausgedrückten Festlegungen angegeben ist, Änderungen im Detail, insbesondere hinsichtlich der Struktur und Anordnung von Teilen, vorgenommen werden können. Wenngleich zum Beispiel die vorliegend beschriebene bevorzugte Ausführungsform auf Speicher ausgerichtet ist, bei denen Festkörper-Mikroelektronik auf Halbleiterbasis genutzt wird, wird für Fachleute auf dem Gebiet zu erkennen sein, dass die Lehren der vorliegenden Erfindung auf andere Speicher angepasst werden können, die organische oder chemische Schalter im molekularen Maßstab nutzen. Der Schutzumfang der anhängenden Ansprüche soll also nicht auf die vorliegend beschriebenen bevorzugten Ausführungsformen beschränkt sein.

Claims

Nichtflüchtiges Speicherbauelement, umfassend: ein Array (400) aus nichtflüchtigen Speicherzellen; ein Master-Datenregister (403) zum Empfangen von Daten, die in dem Array gespeichert werden sollen; ein Datenvergleichsregister (405) zum Empfangen von Daten aus dem Master-Datenregister; ein Slave-Datenregister (404) zum Empfangen von Daten aus dem Array; und eine Vergleichsschaltung (430) zum Vergleichen der in dem Slave-Datenregister und dem Datenvergleichsregister gespeicherten Daten, um die korrekte Programmierung von Daten in dem Array zu verifizieren; dadurch gekennzeichnet, dass das Master-Datenregister dafür ausgelegt ist, einen nachfolgenden Satz Daten zur Programmierung in das Array zu empfangen und/oder zu halten, während der Vergleich erfolgt.
Nichtflüchtiges Speicherbauelement, umfassend: ein Array (400) aus nichtflüchtigen Speicherzellen; ein Master-Datenregister (403) zum Empfangen von Daten, die in dem Array gespeichert werden sollen, wobei das Master-Datenregister die Daten nach der Speicherung beibehält; ein Slave-Datenregister (404) zum Empfangen von Daten aus dem Array; und eine Vergleichsschaltung (430) zum Vergleichen der in dem Slave-Datenregister und dem Master-Datenregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren; dadurch gekennzeichnet, dass das Master-Datenregister dafür ausgelegt ist, einen nachfolgenden Satz Daten zur Programmierung in das Array zu empfangen und/oder zu halten, während der Vergleich erfolgt.
Bauelement nach Anspruch 1 oder Anspruch 2, wobei die Speicherzellen Flash-Speicherzellen umfassen.
Bauelement nach Anspruch 1 oder Anspruch 2, wobei die Speicherzellen Mehrzustands-Speicherzellen darstellen.
System, welches ein Speicherbauelement entsprechend einem der vorhergehenden Ansprüche sowie einen Controller (301) umfasst, der dafür ausgelegt ist zu bewirken, dass Daten unter Ansprechen darauf, dass der Vergleich einen Fehler anzeigt, erneut in das Array geschrieben werden.
System, umfassend: ein Speicherbauelement gemäß einem der Ansprüche 1 bis 5 sowie einen Controller (301), wobei die Vergleichsschaltung dafür ausgelegt ist, einen Vergleich in einem Prozess auszuführen, der von dem Speicherbauelement unabhängig von dem Controller initiiert wird.
Verfahren zum Betreiben eines nichtflüchtigen Speicherbauelements, welches folgende Schritte umfasst: Empfangen von Daten, die in einem Array aus nichtflüchtigen Speicherzellen gespeichert werden sollen; Speichern der Daten in einem Master-Datenregister; Speichern der Daten in einem Datenvergleichsregister; Programmieren der Daten in das Array; Lesen der Daten, wie sie in dem Array gespeichert sind; Speichern der gelesenen Daten in einem Slave-Datenregister; und Vergleichen der in dem Slave-Datenregister und in dem Datenvergleichsregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren; dadurch gekennzeichnet, dass das Master-Datenregister gleichzeitig mit einem oder mehreren der Schritte des Programmierens, Lesens und Vergleichens einen zweiten Satz Daten zur Programmierung in das Array empfängt und/oder hält.
Verfahren zum Betreiben eines nichtflüchtigen Speicherbauelements, welches folgende Schritte umfasst: Empfangen von Daten, die in einem Array aus nichtflüchtigen Speicherzellen gespeichert werden sollen; Speichern der Daten in einem Master-Datenregister; Programmieren der Daten in das Array, während die Daten in dem Master-Datenregister beibehalten werden; Lesen der Daten, so wie sie in dem Array gespeichert sind; Speichern der gelesenen Daten in einem Slave-Datenregister; und Vergleichen der in dem Slave-Datenregister und dem Master-Datenregister gespeicherten Daten, um die korrekte Programmierung der Daten in dem Array zu verifizieren; dadurch gekennzeichnet, dass das Master-Datenregister gleichzeitig mit einem oder mehreren der Schritte des Programmierens, Lesens und Vergleichens einen zweiten Satz Daten zur Programmierung in das Array empfängt und/oder hält.
Verfahren nach Anspruch 7 oder Anspruch 8, wobei die Daten vor dem Schritt des Programmierens von dem Master-Datenregister zu dem Slave-Datenregister übertragen werden.
Verfahren nach einem der Ansprüche 7 bis 9, welches, wenn ein Ergebnis des Vergleichsschritts die unrichtige Programmierung der Daten in dem Array anzeigt, den zusätzlichen Schritt der erneuten Programmierung der Daten in das Array umfasst.
Verfahren nach Anspruch 10, welches den Schritt umfasst, nach dem erneuten Programmierungsschritt die Schritte des Lesens und Vergleichens zu wiederholen.
Verfahren nach einem der Ansprüche 7 bis 9, welches, wenn ein Ergebnis des Vergleichsschritts die unrichtige Programmierung von Daten in dem Array anzeigt, den zusätzlichen Schritt umfasst, Fehlerbehebungsmaßnahmen auszuführen.
Verfahren nach Anspruch 12, welches nach dem Schritt des Ausführens von Fehlerbehebungsmaßnahmen das Wiederholen der Schritte des Lesens und Vergleichens umfasst.