DE60219990T2

DE60219990T2 - Speichertest-Schaltung

Info

Publication number: DE60219990T2
Application number: DE60219990T
Authority: DE
Inventors: Alan S. Fort Collins Krech; Stephen D. Fort Collins Jordan
Original assignee: Agilent Technologies Inc
Current assignee: Agilent Technologies Inc
Priority date: 2001-04-25
Filing date: 2002-03-22
Publication date: 2008-01-17
Anticipated expiration: 2022-03-23
Also published as: EP1253600A2; JP4194799B2; US6574764B2; EP1701359A1; EP1253600A3; KR100920277B1; DE60219990D1; JP2003007089A; EP1253600B1; US20020162046A1; TW583680B; KR20020082791A

Description

Der Gegenstand dieser Offenbarung betrifft einen Teil der Funktionsweise eines ziemlich großen und komplexen Systems zum Testen von Halbleiterspeichern. Der beschriebene Speichertester beinhaltet in sich ein umfassendes Speicherteilsystem als eine Komponente in dem Gesamtparadigma zum Durchführen von Tests. Bestimmte Fähigkeiten dieses Speicherteilsystems sind hier dahingehend von Interesse, als dass sie als die bevorzugte Basis für einen Teil des offenbarten Gegenstands dienen. Aus Gründen einer Wirtschaftlichkeit bei dem Produkt und begünstigt durch den Wunsch, größere Mengen an Speicher innerhalb des Testers verfügbar zu haben, wurde eine Weise entwickelt, um billigen Speicher (DRAM, der bei wahlfreiem Zugriff langsam ist) als Ersatz für teuren SRAM, der selbst bei wahlfreiem Zugriff schnell ist, zu verwenden. Das Ergebnis ist, bei Kombination mit verschiedenen anderen Speicherteilsystemmerkmalen, ein komplexes System, das ein Multiplexen unter Gruppen und ein Verschachteln unter Bänken beinhaltet, sowie ein Implementieren dieser Dinge als variable Wortbreite. Andererseits könnten die hierin offenbarten bestimmten Merkmale in einem System unter Verwendung von nur SRAM implementiert sein, mit einer wesentlichen Reduzierung an Komplexität, jedoch einem wesentlichen wirtschaftlichen Nachteil. Offenbart ist ein Mittelgebiet, bei dem das System nicht vollständig aus SRAM hergestellt ist, obwohl dies sicherlich funktionieren würde. Wir schließen die DRAM-Technik natürlich ein.
Die vorliegende Beschreibung und diejenige der oben erwähnten U.S.-Anmeldung können mit den folgenden Überlegungen kombiniert werden. Die oben erwähnte Offenbarung vertritt die Ansicht, dass die Gesamtheit des Speichers von Interesse Fehlerfang-RAM (ECR; ECR = Error Catch RAM) genannt wird, und dass dieser in Speichersätze (Memory Sets) unterteilt ist. Dies funktioniert nur mit Schwierigkeiten, da ein ECR nahezu die einzige Speicherfunktion von Interesse ist, auch wenn auf die Existenz anderer derartiger Funktionen hingewiesen wird. Bei der vorliegenden Anmeldung jedoch hat sich herausgestellt, dass es bequemer ist, die Gesamtheit von Speicher von Interesse unter Verwendung des Ausdrucks „innerer Testspeicher" zu beschreiben, der wiederum aus vier separaten und unabhängigen Speichersätzen besteht, innerhalb derer die verschiedenen Funktionsspeichermechanismen (einschließlich eines ECR) durch eine geeignete Konfiguration definiert sein könnten. So würde es in der oben erwähnte Offenbarung scheinen, dass Speichersätze in einem ECR beinhaltet sind, obwohl es hier genau andersherum ist. Trotzdem richten sich beide Offenbarungen auf Gegenstände, die in dem gleichen Gesamtsystem zu finden sind.
Elektronikvorrichtungen und -fähigkeiten sind im Alltag außerordentlich häufig geworden. Zusammen mit Personalcomputern zuhause tragen viele Personen aus verschiedenen und allerlei Gründen mehr als ein Produktivitätstool bei sich. Die meisten persönlichen elektronischen Produktivitätsvorrichtungen umfassen eine bestimmte Form eines nichtflüchtigen Speichers. Mobiltelefone verwenden nichtflüchtigen Speicher, um durch einen Benutzer programmierte Telefonnummern und Konfigurationen zu speichern und zu behalten, wenn die Leistung abgeschaltet wird. PCMCIA-Karten verwenden nichtflüchtigen Speicher, um Informationen selbst dann zu speichern und zu behalten, wenn die Karte aus ihrem Schlitz in dem Computer entfernt wird. Viele andere häufige elektronische Vorrichtungen profitieren auch von der Langzeitspeicherfähigkeit nichtflüchtigen Speichers in nicht mit Leistung versorgten Anordnungen.
Die Hersteller nichtflüchtiger Speicher, die an die Hersteller elektronischer Ausrüstung verkaufen, benötigen Tester, um den ordnungsgemäßen Betrieb der Speicher, die sie herstellen, zu prüfen und zu verifizieren. Aufgrund des Volumens nichtflüchtiger Speicher, die als durchgehend niederpreisig hergestellt und verkauft werden, ist es sehr wichtig, die Zeit zu minimieren, die der Test eines einzel nen Teils in Anspruch nimmt. Käufer nichtflüchtiger Speicher verlangen, dass Speicherhersteller aufgrund der Kosteneinsparungen, die der Praktizierung eines Beinhaltens der Speichervorrichtungen in teureren Anordnungen mit minimalem oder keinem Testen zugeordnet sind, große Versanderträge liefern. Entsprechend muss der Speichertestvorgang ausreichend effizient sein, um einen großen Prozentsatz nichtkonformer Teile und vorzugsweise aller nichtkonformer Teile in einem einzelnen Testvorgang zu identifizieren.
Mit größer, dichter und komplexer werdenden nichtflüchtigen Speichern müssen die Tester in der Lage sein, die erhöhte Größe und Komplexität zu handhaben, ohne die Zeit, die ein Testen derselben in Anspruch nimmt, wesentlich zu erhöhen. Speichertester laufen häufig kontinuierlich und Testzeit wird als ein Hauptfaktor bei den Kosten des letztendlichen Teils betrachtet. Mit sich entwickelnden und verbessernden Speichern muss der Tester in der Lage sein, die Veränderungen, die an der Vorrichtung durchgeführt werden, ohne weiteres unterzubringen. Ein weiteres Problem, das spezifisch für ein Testen nichtflüchtiger Speicher ist, ist, dass ein wiederholtes Schreiben in Zellen der Speicher das Gesamtlebensdauerverhalten des Teils verschlechtern kann. Die Hersteller nichtflüchtiger Speicher haben auf viele der Testprobleme reagiert, indem sie spezielle Testmodi in die Speichervorrichtungen bauen. Diese Testmodi werden durch den Käufer des Speichers überhaupt nicht verwendet, auf sie kann jedoch durch den Hersteller zugegriffen werden, um alle oder wesentliche Abschnitte der Speicher in so wenig Zeit wie möglich und so effizient wie möglich zu testen. Einige nichtflüchtige Speicher können auch während des Testvorgangs repariert werden. Der Tester sollte deshalb in der Lage sein, Folgendes zu identifizieren: einen Bedarf nach Reparatur; einen Ort der Reparatur; den Typ benötigter Reparatur; und muss dann die geeignete Reparatur durchführen können. Ein derartiger Reparaturvorgang erfordert einen Tester, der in der Lage ist, einen spezifischen nichtkon formen Abschnitt des Speichers zu erfassen und zu isolieren. Um vollen Nutzen aus den speziellen Testmodi sowie den Reparaturfunktionen zu ziehen, ist es von Vorteil, wenn ein Tester in der Lage ist, ein Testprogramm auszuführen, das basierend auf einer erwarteten Antwort von der Vorrichtung eine bedingte Verzweigung unterstützt.
Aus einer konzeptionellen Perspektive ist der Vorgang eines Testens von Speichern ein algorithmischer Vorgang. Typische Tests umfassen z. B. ein sequentielles Inkrementieren oder Dekrementieren von Speicheradressen, während Nullen und Einsen in die Speicherzellen geschrieben werden. Es ist üblich, sich auf eine Sammlung von Einsen und Nullen, die während eines Speicherzyklus geschrieben oder gelesen werden, als einen „Vektor" zu beziehen, während der Ausdruck „Muster" sich auf eine Sequenz von Vektoren bezieht. Es ist üblich, dass die Tests ein Schreiben von Mustern in den Speicherraum, wie z. B. Schachbrettmuster, laufende Einsen und Schmetterlingsmuster, umfassen. Ein Testentwickler kann ohne weiteres und effizient mit der Hilfe algorithmischer Konstrukte ein Programm erzeugen, um diese Muster zu erzeugen. Ein Testmuster, das algorithmisch kohärent ist, ist auch leichter einer Fehlersuche zu unterziehen und ermöglicht die Verwendung logischer Verfahren zum Isolieren von Abschnitten des Musters, die sich nicht wie erwartet verhalten. Ein Testmuster, das algorithmisch unter Verwendung von Instruktionen und Befehlen erzeugt wird, die in Programmierschleifen wiederholt werden, verbraucht weniger Raum in dem Testerspeicher. Entsprechend ist es wünschenswert, in einem Speicherteste über eine algorithmische Testmustererzeugungsfähigkeit zu verfügen.
Eine präzise Signalflankenplatzierung und -erfassung ist außerdem eine Überlegung bei der Wirksamkeit eines Testers nichtflüchtigen Speichers. Um Teile zu erfassen, die allgemein als ein Mittelwert konform sind, während sie mit den spezifizierten Rändern nicht konform sind, muss ein nichtflüchtiger Tester in der Lage sein, präzise jede Signal flanke zeitlich relativ zu einer anderen Signalflanke zu platzieren. Es ist auch wichtig, in der Lage zu sein, präzise zu messen, zu welchem Zeitpunkt eine Signalflanke empfangen wird. Entsprechend sollte ein Tester nichtflüchtigen Speichers über ausreichende Flexibilität und Steuerung der Zeitgebung und Platzierung von Stimuli und Antworten von dem zu testenden Bauelement (Speicher) verfügen.
Man sagt, dass Speichertester "Sende"-Vektoren, die an das DUT (Device under Test = zu testendes Bauelement) angelegt werden (Stimulus), und "Empfangs"-Vektoren, die zurück erwartet werden (Antwort), erzeugen. Die algorithmische Logik, die diese Vektoren erzeugt, kann dies allgemein tun, ohne sich selbst damit zu beschäftigen, wie ein bestimmtes Bit in einem Vektor zu oder von einer bestimmten Signalanschlussfläche in dem DUT gelangt, da der Speichertester Abbildungsanordnungen zum Führen von Signalen zu und von Anschlussstiften beinhaltet.
Speichertester weisen einen inneren Testspeicher auf, der verwendet wird, um den Testvorgang zu ermöglichen. Dieser innere Testspeicher könnte für mehrere Zwecke verwendet werden, unter denen ein Speichern von Sendevektoren vor der Zeit, im Gegensatz zu einem Erzeugen derselben in Echtzeit, ein Speichern von Empfangsvektoren und ein Speichern einer Vielzahl von Fehleranzeigen und anderer Informationen bezüglich eines DUT-Verhaltens, die während des Testens erhalten werden, sind. (Es gibt außerdem Systemverwaltungszwecke innerhalb der Operation des Speichertesters, die SRAM verwenden und die anscheinend in den Bereich der Phrase „innerer Speicher" fallen. Diese sind für die innere Operation des Testers vertraulich, neigen dazu, auf der algorithmischen Ebene nicht sichtbar zu sein, und sind mit inneren Steuerregistern vergleichbar. Dieser Speicher wird als „innerer Steuerspeicher" beschrieben und ist von dem ausgeschlossen, was hierin mit dem Ausdruck „innerer Testspeicher" gemeint wird, den wir verwenden, um Speicher zu beschreiben, der zur Speicherung von Bitmustern verwendet wird, die direkt auf den Stimulus und die Antwort von dem DUT bezogen sind.) Es ist ohne weiteres zu erkennen, dass dieser innere Testspeicher zumindest so schnell wie die gerade durchgeführten Tests arbeiten muss; ein sehr häufiges Paradigma ist, dass der innere Testspeicher (oder ein bestimmter Teil desselben) durch die gleiche Adresse (oder eine bestimmte Ableitung derselben) adressiert werden soll, wie auf das DUT angewendet wird. Was dann an diesem adressierten Ort in dem inneren Testspeicher gespeichert wird, ist etwas, was ein DUT-Verhalten während einer Testoperation, die an dem DUT an dieser Adresse durchgeführt wird, anzeigt. Algorithmische Überlegungen innerhalb des Testprogramms könnten bedeuten, dass die Sequenz von Adressen, die aufeinander folgenden Sendevektoren zugeordnet sind, willkürlich sein kann. So muss der innere Speicher die zwei Attribute hoher Geschwindigkeit und wahlfreier Adressierbarkeit besitzen. Was einem sofort zu SRAM einfällt, ist, dass er schnell, leicht zu steuern und tolerant gegenüber einer vollkommen wahlfreien Adressierung ist. Tatsächlich haben herkömmliche Speichertester SRAM als ihren inneren Testspeicher verwendet.
Leider ist SRAM ziemlich teuer und dies hat die Menge an innerem Testspeicher eingeschränkt, mit der Speichertester bisher arbeiten mussten. Das Ergebnis ist Begrenzungen für die Speichertesterfunktionalität, die durch einen Mangel an Speicher auferlegt werden. DRAM ist wesentlich billiger, kann jedoch kein wahlfreies Adressieren tolerieren und trotzdem mit hoher Geschwindigkeit arbeiten.
DRAM kann SRAM als den inneren Testspeicher in einem Speichertester ersetzen. Wie in einer vereinfachten Übersicht unten kurz beschrieben ist, kann das Problem einer Erhöhung der Geschwindigkeit eines DRAM-Betriebs zur Verwendung als innerer Testspeicher durch Erhöhen der verwendeten Menge an DRAM, anstelle eines Erhöhens seiner Geschwindigkeit gelöst werden. Anzahlen von identischen Bänken von DRAM werden wie Gruppen behandelt. Eine Kombination eines Verschachtelns von Signalen für unterschiedliche Bänke eines Speichers in einer Gruppe desselben und eines Multiplexens zwischen diesen Gruppen von Bänken verlangsamt den Speicherverkehr für eine bestimmte Bank herunter auf eine Rate, die durch die Bank gehandhabt werden kann. (Zur Annehmlichkeit für den Leser schließen wir hier eine sehr abgekürzte Zusammenfassung dieser Technik ein, da ein Großteil ihrer Strukturaufbausaspekte und zugeordnete Terminologie nützlich bei der folgenden Erläuterung des erfindungsgemäßen Gegenstandes sind.)
Ein Dreiwege-Multiplexen zwischen drei Gruppen von jeweils vier Bänken, kombiniert mit einem flexiblen Vierfachverschachtelungsschema für Signalverkehr zu einer Gruppe erzeugt einen Anstieg der Betriebsgeschwindigkeit, der sich einem Faktor zwölf annähert, während nur drei Speicherbusse benötigt werden. Eine zyklische Umlaufsstrategie (round robin) zum Auswählen der nächsten Gruppe für den Multiplexer ist einfach und stellt sicher, dass der Verschachtelungsmechanismus für jede Gruppe die Zeit hat, die er benötigt, um seine zuletzt zugewiesene Aufgabe abzuschließen. Alle verschachtelten Zugriffe innerhalb einer Gruppe werden an einer nächsten Bank (innerhalb dieser Gruppe) durchgeführt, die ebenso durch eine einfache zyklische Umlaufauswahl ausgewählt ist. Bei dieser Konfiguration stellt jede der zwölf Bänke eine Duplikatsinstanz des gesamten verfügbaren Adressraums dar und jeder einzelne Schreibzyklus könnte mit einem Zugreifen auf eine beliebige der zwölf Bänke enden. Eine Implikation ist die, dass bei Abschluss des Testens alle zwölf Bänke untersucht sein müssen, um daraus zu erfahren, welche Fehler während eines Testens des DUT geschehen sind, da die Historie einer beliebigen Adresse oder Sammlung von Adressen von Interesse über alle zwölf Bänke verteil sein wird. Ein bestimmter Kanal wird so durch zwölf Bits dargestellt (ein Bit von jeder Bank, und ihr Positionsbit innerhalb des Worts für diese Bank wird durch den Kanal bestimmt).
Es wäre jedoch unangenehm, (tatsächlich manuell) einzeln alle zwölf Bänke zu untersuchen, um Fehlerinformationen zu entdecken, so dass ein Hilfsprogrammmechanismus bereitgestellt wurde, um automatisch Ergebnisse aller zwölf Bänke während eines Lesezyklus bei einer Adresse in einvereintes Ergebnis, das in einer oder allen zwölf Bänken gespeichert sein kann, „zusammenzubauen" (zusammenzuführen). Dies ermöglicht es, dass zusammengesetzte Daten später mit voller Geschwindigkeit gelesen werden können. Volle Geschwindigkeit ist bei einem Ausführungsbeispiel eine Rate von 100 MHz für wahlfrei adressierte Speichertransaktionen.
Wenn 33 MHz schnell genug sind, kann der wahlfreie Zugriff mit nur dem Verschachteln und ohne Multiplexen unterstützt werden, wobei in diesem Fall der Zusammenbaumechanismus und das Speicheradressierschema geeignet angepasst werden. Das Adressierschema verändert sich, um zusätzliche Gruppenauswahlbits zu umfassen, die es ermöglichen, dass die Tiefe des Speichers dreimal tiefer sein kann als für einen zufälligen 100 MHz-Betrieb. Diese zwei Betriebsmodi werden R100 bzw. R33 bezeichnet. Es gibt außerdem einen L100-Modus eines 100 MHz-Betriebs für einzelne Bänke, der darauf beruht, dass gut funktionierende Adressen an den DRAM gesendet werden (ein absolutes Minimum an Zeilenadressveränderungen).
Auf der oberen Ebene einer Organisation des inneren Testspeichers gibt es vier Speichersätze, die jeweils ihren eigenen separaten und unabhängigen Adressraum aufweisen und angeforderte Speichertransaktionen durchführen. Zwei sind aus DRAM, wie oben beschrieben, und zwei sind aus SRAM. Jeder Speichersatz besitzt seine eigene Steuerung, an die Speichertransaktionen gerichtet sind. In Bezug auf äußerlich sichtbare Betriebsfähigkeiten sind alle vier Speichersätze im Wesentlichen identisch. Sie unterscheiden sich nur in ihrer Größe des Speicherraums und dadurch, wie sie intern implementiert sind: die SRAM-Speichersätze verwenden kein Multiplexen und Verschachteln, da sie zunächst schnell genug sind. Trotz ihrer Unabhängigkeit können Speichersätze des gleichen Typs (aus SRAM oder aus DRAM) „gestapelt" werden, was bedeutet, als ein größerer Adressraum behandelt werden. Dies geschieht auf der Ebene einer Steuerung über den Speichersätzen selbst, bei der algorithmischen Erzeugung der Adressen und der Entscheidung darüber, welchem Speichersatz tatsächlich eine Speichertransaktion gesendet werden soll. Dies ist nicht so automatisch wie die Weise, in der die Speichersätze und ihre Steuerungen Gruppen stapeln können, um den Adressraum zu verdreifachen, wie zwischen dem R100- und dem R33-Betriebsmodus. Für jede der Speichersatzsteuerungen gibt es keinen Hinweis, dass es überhaupt etwas wie einen weiteren Speichersatz mit einer weiteren Steuerung gibt.
Deshalb ist der innere Testspeicher des Testers in vier Speichersätze unterteilt, von denen zwei „innere" SRAMs sind und zwei „äußere" DRAMs sind. Sicherlich befindet sich dieser gesamte Speicher physisch innerhalb des Speichertesters; die Ausdrücke „innerer" und „äußerer" haben mehr mit einer Ebene an Integration zu tun. Die SRAMs sind einstückige Teile einer VLSI-Schaltung (VLSI = Very Large Scale Integration = Höchstintegration), die dem zentralen Funktionsschaltungsaufbau des Testers zugeordnet ist, während die DRAMs einzeln gehäuste Teile sind, die benachbart zu dem VLSI-Zeug befestigt sind. Die Menge an SRAM ist ziemlich klein (z. B. ein Megabit pro Speichersatz), während die Menge an DRAM beträchtlich und auswählbar ist (z. B. in dem Bereich von 128 bis 1.024 Megabits pro Speichersatz). Die SRAM-Speichersätze sind immer vorhanden und können für jeden geeigneten Zweck verwendet werden, wie z. B. Speichern des erwarteten Inhalts eines DUT, das ein ROM (Nur-Lese-Speicher) ist. Die DRAM-Speichersätze sind tatsächlich optional und werden typischerweise zum Erzeugen einer Spur zur nachfolgenden Analyse, die zu einer Reparatur führt, verwendet, obwohl es auch andere Verwendungen gibt. Der Tester setzt keine Unterscheidung zwischen den SRAM- und DRAM-Speichersätzen in Bezug auf unterschiedliche Zwecke, für die diese verwendet werden können, durch. Diese Unterscheidungen entstehen hauptsächlich aus der Größe. Die SRAM-Speichersätze sind klein, während die DRAM-Speichersätze möglicherweise riesig sind. Die Person oder Personen, die die Testprogrammierung erzeugen, treffen die Entscheidungen bezüglich dessen, wie die verschiedenen Speichersätze verwendet werden sollen.
Der Speichertester, den wir bisher beschrieben haben, wird stark pipelinemäßig betrieben. Mit Pipelinebetrieb meinen wir, dass eine Gesamtaufgabe oder -funktionalität über einen im Wesentlichen seriellen Pfad verteilt ist, der eine bestimmte Anzahl von Mechanismen (Stufen der Pipeline) aufweist, die jeweils sowohl Eingangsumstände annehmen als auch dann eine entsprechende Ausgabe mit einer üblichen Rate erzeugen können. So befindet sich Z. B. oben in der Pipeline, die „nach unten" zu dem DUT führt, ein Mikrosteuerungssequencer, der der algorithmisch programmierbare Ursprung einer Testprogrammausführung ist. Er erzeugt eine „rohe" Adresse oder Adresse auf „algorithmischer Ebene", die schließlich auf das DUT angewendet wird, vielleicht jedoch erst nach einer bestimmten beträchtlichen Manipulation. Diese Adressen und manchmal Daten laufen durch einige ALUs und (nur für Adressen) könnte ein Adressabbilder auf einen inneren Testspeicher und/oder einen Daten-MUX angewendet werden, und so auf eine SCHALTUNG EINES SENDENS VON VEKTORABBILDER/SERIALISIERER & EMPFANGEN VON VEKTORVERGLEICHSDATEN, einen Vektor-FIFO 45 und schließlich eine Zeitgebungs/Formatierungs- & Vergleichsschaltung, an der Sendevektoren ausgehen, um über bestimmte Anschlussstiftelektronik an das DUT angelegt zu werden. Nicht alle Stufen der Pipeline besitzen die gleiche Verzögerung. Komplexere Operationen in der Pipeline in Richtung des DUT benötigen unter Umständen mehr Zeit innerhalb ihrer zugeordneten Stufen. Wie bei allen verschiedenen Stufen jedoch sind dies feste Verzögerungen, die, sobald sie aufgetreten sind, die Gesamt-Rate von Ende zu Ende für die Pipeline nicht stören. Wir könnten sagen, dass es einen weiteren (und unterschied lichen) Pipeline-Pfad gibt, der Empfangsvektoren zurück „nach oben" in Richtung der Umgebung des ausführenden Testprogramms befördert.
Wenn der Speichertester in einer bestimmten Weise für ein bestimmtes Segment eines Testprogramms konfiguriert ist, im Gegensatz zu einem unterschiedlichen Segment in diesem gleichen Programm, kann die Veränderung an der Konfiguration Stufen in der Pipeline hinzufügen oder löschen, die Länge einer Pipelinestufe, die zu dieser Zeit in Verwendung ist, verändern, was alles eine gesamte kombinierte Pipelineverzögerung für dieses zugeordnete Segment des Testprogramms beeinflussen kann. Diese kombinierten Verzögerungen sind jedoch bekannt und sie verändern nicht die Dauer ihrer zugeordneten Testprogrammsegmente.
Wir haben bereits erwähnt, dass eine algorithmische Fähigkeit bei der Entwicklung und Beibehaltung der Testprogramme, die mit dem Speichertester ausgeführt werden sollen, wünschenswert war. Der Mikrosteuerungssequencer unterstützt eine kompakte Form eines Testprogramms mit Schleifen, die in Schleifen verschachtelt sind und sich auf Testergebnisse verzweigen. Die Verwendung einer Pipelinearchitektur jedoch verkompliziert bestimmte Fähigkeiten, an denen wir interessiert sind, insbesondere in der Weise, in der Fehler, die durch das DUT bewirkt werden, aufgefasst und gehandhabt werden.
Es wird das grundlegende Bedürfnis betrachtet, zu wissen, dass „an diesem Punkt in dem Programm der Ort ist, an dem diese/r und jene/r Fehlfunktion/unerwarteter Fehler aufgetreten ist." Wir nehmen an, dass wir die Testprogramm/DUT-Zyklus-Rate ausreichend langsam laufen ließen, dass die Pipelineverzögerung von dem Mikrosteuerungssequencer zu den Anschlussstiftelektroniken und dann wieder zurück einfach in die Flussrate einer Programmausführung gebündelt werden könnte. Es wäre noch nicht einmal nötig zu wissen, dass eine Pipeline vorliegt. Unter diesen theoretischen Umstän den treten der gegenwärtige Zustand des Testprogramms und die Aktivität an dem DUT nicht nur in einer bestimmten Zeit/Raten-Beziehung zueinander auf (synchronisiert), sondern auch in einem Zustand „sequentiellen Gleichklangs", in dem eine Ursache und ihre Wirkung nie durch einen Instruktionsabruf für das Testprogramm getrennt sind. Unter diesen Umständen kann, wenn das DUT ausfällt, der nächste Schritt in dem Programm eine Antwort auswerten und dann dort entscheiden, dass der vorausgegangene Schritt in dem Programm die Stelle ist, an der der Fehler aufgetreten ist. Was als nächstes getan wird, hängt von der Absicht des Programmierers ab. Er könnte einfach die grundlegenden Informationen für eine spätere Betrachtung oder Analyse sammeln wollen (berichten oder bewahren), wie Z. B. was die angewendeten Adressen waren, und andere relevante Stimulusinformationen, die zusätzlich dazu, dass man weiß, dass „es der Schritt in dem Programm war" (wie durch einen Programmzähler und vielleicht bestimmte Schleifenindizes angezeigt wird), wissen, wo der Fehler aufgetreten ist. Alternativ könnte der Programmierer antizipiert haben, dass dies geschehen könnte, und andere Testprogrammsegmente vorgesehen haben, deren Ausführung sich mit dem abgeben soll, was auch immer es ist. So würde sich das Programm an eine bestimmte Stelle verzweigen. Beide diese Aktionen sind bei diesem Beispiel tatsächlich möglich, da die Eigenschaft des „sequentiellen Gleichklangs" sicherstellt, dass eine Ursache (ein bestimmter Stimulus in dem Testprogramm) und seine Wirkung (ein bestimmtes entsprechendes Ergebnis von dem DUT) niemals durch einen Instruktionsabruf für das Testprogramm getrennt sind.
Zu testende DUTs jedoch sind allgemein nicht so langsam und der Bediener des Speichertesters möchte diese mit den Geschwindigkeiten testen, mit denen sie verwendet werden. Ferner fragt das Testprogramm unter Umständen nicht unmittelbar, ob ein früherer Stimulus einen zugeordneten Fehler erzeugt hat oder nicht. Außer einem Aufbauen einer superschnellen Hardware zum Erhalten der Eigenschaft des sequen tiellen Gleichklangs gibt es keine andere Wahl, als es zu erlauben, dass die Verzögerungen der Pipelines sichtbar werden. Der Preis ist der, dass die Antwort auf die grundlegende Frage „wo in dem Programm ist der Fehler aufgetreten..." viel schwieriger bereitzustellen ist, wie auch die Mechanismen, die benötigt werden, um die Aufgabe eines Verzweigens an einem Fehler zu ermöglichen. In jedem Fall hat sich das Testprogramm oben in der Pipeline bereits über den Ort hinaus weiterbewegt, an dem es den Stimulus bereitgestellt hat. Es könnte bereits mehrere derartige Stimuli bereitgestellt haben und es könnte seitdem bereits einer bedingten Verzweigung unterzogen worden sein. Selbst wenn ein Fehlerflag letztendlich gesetzt ist und später durch das Programm getestet wird, mit welchem ist es nun gerade korreliert? Und was waren die verschiedenen Adressen usw. zu diesem Zeitpunkt. Sie unterscheiden sich wahrscheinlich nun von dem, wie sie damals waren. Wie können wir effektiv mit der Tatsache umgehen, dass Ereignisse in dem Testprogramm den Wirkungen, die sie in dem DUT bewirken, vorauseilen? Wenn dies nicht gelöst werden kann, ist dies ein ziemlich beträchtliches Problem.
Das Problem ist eine Verzweigung zurück zu einem geeigneten Ort innerhalb eines Speichertester-Testprogramms und außerdem eine Wiederherstellung seines Zustands einer algorithmischen Steuerung, wenn ein Fehler, der demselben zugeordnet ist, zeitlich später an dem DUT auftritt. Aufgrund von Verzögerungen in einer Sendevektorpipeline, die Adress- und Datenstimuli von der Programmausführungsumgebung mit dem DUT verbindet, und außerdem aufgrund weiterer Verzögerungen in einer Empfangsvektorpipeline, die Antworten von dem DUT zurück mit der Ausführungsumgebung des Testprogramms verbindet, ermöglichen es diese Verzögerungen, dass das Programm sich willkürlich über einen Punkt weiterbewegt, an dem der Stimulus gegeben wurde. Der willkürliche Fortschritt macht es schwierig, die genauen Umstände zu bestimmen, die dem Fehler zugeordnet waren. Eine Verzweigung basierend auf dem Fehlersignal kann einen Abschnitt des Testprogramms neu starten, dies ist wahrscheinlich jedoch nur eine Schablone, die weitere Testalgorithmussteuerinformationen benötigt, die dynamisch variieren, wenn das Testprogramm ausgeführt wird.
Die EP 0356999 offenbart einen Speichertester, in dem Daten, die aus einer Adresse eines zu testenden Speichers ausgelesen werden, spezifiziert durch einen Mustererzeuger, mit einem erwarteten Wert verglichen werden und das Ergebnis des Vergleichs in einen Fehleranalysespeicher geschrieben wird. Eine Zyklusverzögerungsschaltung ist bereitgestellt, durch die die Adresse, die von dem Mustererzeuger an den Fehleranalysespeicher geliefert werden soll, synchron zu dem Takt um eine erwünschte Anzahl von Zyklen verzögert wird und die Adresse, die an den Fehleranalysespeicher angewendet werden soll, um die gleiche Anzahl von Zyklen verzögert wird wie diejenige, für die die ausgelesenen Daten des zu testenden Speichers verzögert werden.
Die vorliegende Erfindung möchte ein verbessertes Speichertesten bereitstellen.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren gemäß Anspruch 1, 5 und 7 bereitgestellt.
Das bevorzugte Ausführungsbeispiel stattet den Speichertester mit verschiedenen Historie-FIFOs aus, deren Tiefen angepasst werden, um die Summe der Verzögerungen der Sende- und Empfangsvektorpipeline zu berücksichtigen, bezogen auf den Ort dieses Historie-FIFO. Wenn das Fehlerflag erzeugt ist, sind der erwünschte Programmzustand und algorithmische Steuerinformationen unten in einem geeigneten Historie-FIFO vorhanden und können wie erwünscht verwendet werden. Diese Technik ist ohne weiteres auf den Fall anwendbar, in dem das Testprogramm eine ALU verwendet, um ihre eigenen DUT-Stimuli zu erzeugen (ist vollständig in sich abgeschlossen) sowie auf den Fall, in dem Testprogramm/ALU einen Zwischen-Pufferspeicher adressieren, dessen Inhalt zentral für die Natur des Testens ist, dem das DUT unterzogen werden soll. In dem ersten Fall liegt ein ALU-Historie-FIFO vor, während in dem zweiten ein Pufferspeicher-Historie-FIFO vorliegt. (Der Ausdruck "Historie-FIFO" ist eine Verallgemeinerung und der Name einer Klasse bestimmter FIFOs. Es gibt keine FIFO-Namen "Historie-FIFO"; es gibt nur die spezifischen Elemente der Klasse.)
Ferner würde es der Schreiber der Testprogramme sehr wahrscheinlich bevorzugen, sich nicht mit dem Entdecken der verschiedenen Pipelinetiefen befassen zu müssen, die sich aus unterschiedlichen Speichertesterkonfigurationen ergeben, die durch das Programm für unterschiedliche Tests angeordnet werden, die durchgeführt werden. Entsprechend gibt es einen Mechanismus, um eine Konfiguration zu verfolgen, wenn diese auftritt, und um die Tiefen der verschiedenen Historie-FIFOs entsprechend einzustellen. Außerdem muss es einen bestimmten "Start"-Mechanismus auf der Testprogrammebene geben, um anzuzeigen, wann ein Stimulus erteilt wird, für den es später eine Prüfung auf einen zugeordneten Fehler gibt, da der Grad, zu dem ein Historie-FIFO auf eine erwünschte verwendete Tiefe gefüllt ist, nach dieser "Start"-Anzeige bestimmt wird.
Das bevorzugte Testprogramm fragt unter Umständen für eine ziemliche Zeit nach dem zugeordneten Stimulus nicht nach, ob ein Fehler vorlag. Wenn ein Historie-FIFO zwischenzeitlich weiterhin neue Stimuli speichern darf, jedoch nachdem ein Fehler auftritt, geht die erwünschte Entsprechung verloren. Entsprechend gibt es einen Mechanismus, um den Inhalt eines Historie-FIFO nach der Erzeugung eines Fehlers einzufrieren.
ECRs (Error Catch RAMs = Fehlerfang-RAMs) werden oft während eines tatsächlichen DUT-Testens gefüllt und dann später mit einer weiteren Testprogrammaktivität erforscht, die nicht tatsächlich das DUT untersucht. Die verschiedenen Pipelineverzögerungen können es unangenehm machen, die Adresse zu bestimmen, die auf das DUT angewendet wurde, das eine bestimmte Fehleranzeige erzeugt hat, die in dem ECR protokolliert ist. Die herkömmlichen Hilfsprogrammoperationen, die hierfür bereitgestellt werden, sind zu langsam. Der Historie-FIFO-Mechanismus kann auf ECR-Untersuchungen angewendet werden und ein ECR-Historie-FIFO liefert die Antwort, ohne einen Zeitnachteil mit sich zu bringen.
Schließlich kann der zum Implementieren eines Historie-FIFO erforderliche Mehraufwand erweitert werden, um es zu ermöglichen, dass eine Verzweigungsinstruktion in dem Testprogramm nicht vorzeitig vor der Pipelineverzögerung, die für diesen zu bestimmenden Wert des Fehlerflags nötig ist, durch einen Grund, der sich in dem Testprogramm befindet, auf ein Fehlerflag anspricht.
Ausführungsbeispiele der vorliegenden Erfindung sind unten lediglich beispielhaft unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben. Es zeigen:
1 ein vereinfachtes Blockdiagramm eines Ausführungsbeispiels eines rekonfigurierbaren und algorithmisch getriebenen nichtflüchtigen Speichertests;
2 eine vereinfachte Blockdiagrammerweiterung des Testers aus 1;
3 eine Erweiterung von Abschnitten aus 2, die die Natur eines ALU-Historie-FIFOs und seines zugeordneten Steuerschaltungsaufbaus zeigt; und
4 ein vereinfachtes Blockdiagramm von Abschnitten aus 2, das die Natur eines Letzte-Fehlerdaten-Register, eines Pufferspeicher-Historie-FIFO und eines ECR-Historie-FIFO und deren zugeordneten Steuerschaltungsaufbau zeigt.
Bezug nehmend auf 1 ist ein vereinfachtes Blockdiagramm 1 eines Ausführungsbeispiels eines Testsystems eines nichtflüchtigen Speichers gezeigt. Insbesondere kann das gezeigte System gleichzeitig mit jeweils ganzen 64 Testpunkten bis zu 36 einzelne DUTs (zu testende Bauelemente) zu einer Zeit gleichzeitig testen, mit Maßnahmen für eine Neukonfiguration, um es zu ermöglichen, dass Elemente einer Sammlung von Testressourcen miteinander verbunden werden können, um DUTs mit mehr als 64 Testpunkten zu testen. Diese Testpunkte könnten Orte an einem Abschnitt eines Integrierte-Schaltung-Wafers sein, der noch nicht vereinzelt und gehäust wurde, oder sie könnten die Anschlussstifte eines gehäusten Teils sein. Der Ausdruck „Testpunkt" bezieht sich auf einen elektrischen Ort, an dem ein Signal angelegt werden kann (z. B. gelieferte Leistung, Takte, Dateneingänge), oder an dem ein Signal gemessen werden kann (z. B. Datenausgang). Wir folgen dem Industriestandard eines Bezeichnens der Testpunkte als „Kanäle". Die „Sammlung von Testressourcen, die miteinander verbunden werden "sollen", auf die oben Bezug genommen wurde, kann man sich als ganze 36 Testorte vorstellen, wobei jeder Testort eine Testortsteuerung (4), einen (64-Kanal-)DUT-Tester (6) und eine (64-Kanal-)Sammlung von Anschlussstiftelektroniken (9), die eine tatsächliche elektrische Verbindung zu einem DUT (14) herstellen, umfasst. In dem Fall, in dem ein Testen des DUT 64 oder weniger Kanäle benötigt, ist ein einzelner Testort ausreichend, um Tests" an diesem DUT durchzuführen, und wir sprechen z. B. davon, dass der Testort Nr. 1 (wie er in 1 erscheint) als eine "Einzelort-Teststation" gebildet ist oder arbeitet. Andererseits werden, wenn eine bestimmte Form der vorstehend genannten Neukonfiguration wirksam ist, zwei (oder mehr) Testorte miteinander „verbunden", um als ein größerer äquivalenter Testort mit 128 Kanälen zu fungieren. Entsprechend und wieder unter Bezugnahme auf ein in 1 gezeigtes Beispiel sprechen wir davon, dass die Testorte Nr. 35 und Nr. 36 eine "Zweiort-Teststation" bilden.
Um kurz einen entgegengesetzten Fall zu betrachten, sollte man nicht annehmen, dass ein vollständiger Testort benötigt wird, um ein einzelnes DUT zu testen, oder dass ein einzelner Testort mehr als ein einzelnes DUT testen kann. Es wird angenommen, dass ein Wafer zwei, drei oder vier (wahrscheinlich, jedoch nicht notwendigerweise benachbarte) Chips aufweist, wobei die Summe ihrer Testkanalanforderungen 64 Kanäle oder weniger wäre. Derartige DUTs (15a bis d) können gleichzeitig durch einen einzelnen Testort getestet werden (z. B. Testort Nr. 2, wie in 2 gezeigt ist). Was dies möglich macht, ist die Universalprogrammierbarkeit jedes Testorts, vergrößert durch bestimmte Hardwaremerkmale, die noch zu beschreiben sind. Im Prinzip könnte ein Testprogramm, das durch den Testort ausgeführt wird, derart geschrieben sein, dass ein Teil der Ressourcen des Testorts verwendet wird, um eines der DUTs zu testen, während ein anderer Teil verwendet wird, um das andere DUT zu testen. Schließlich würden wir annehmen, dass, wenn wir ein drittes DUT hätten, das eine logische Vereinigung der ersten beiden wäre, wir in der Lage wären, dieses dritte DUT mit einem einzelnen Testort zu testen, so dass wir in der Lage sein sollten, seine „Komponenten-DUTs" sozusagen ähnlich zu testen. Ein Hauptunterschied ist natürlich ein einzelnes Verfolgen dessen, welches der beiden „Komponenten-DUTs" besteht oder durchfällt, im Gegensatz zu einer einfachen vereinigten Antwort für das „dritte" DUT. Dies bedeutet, es gibt ein Problem in Bezug darauf, welcher Abschnitt des „dritten" DUT durchfiel. Es gibt auch weitere Probleme, einschließlich eines Entfernens oder Beschränkens der getriebenen Signale zu einem fehlerhaften DUT, eines Verzweigens innerhalb des Testprogramms basierend darauf, welches DUT einen Fehler anzeigt, während gleichzeitig verhindert wird, dass das Testprogramm hoffnungslos viele Teilprozesse bekommt. Bestimmte einfache Aspekte dieser „Mehr-DUT-Teststation"-Fähigkeit an einem einzelnen Testort sind ziemlich einfach, während andere komplex sind. Ein Mehr-DUT-Testen sollte nicht mit dem Begriff eines Verbin dens von zwei oder mehr Testorten miteinander verwechselt werden.
Bis auf diesen Begriff einer Testortneukonfiguration gäbe es keinen Unterschied zwischen einem Testort und einer Teststation und wir könnten auf einen der Ausdrücke verzichten. Jedoch ist ohne weiteres zu erkennen, dass die Anzahl von Teststationen nicht gleich der Anzahl von Testorten sein muss. In der Vergangenheit konnten die Anzahlen unterschiedlich sein, da Testorte manchmal aufgeteilt waren, um mehr Teststationen für ein einfaches Mehr-DUT-Testen zu erzeugen (DUTs, die nicht ausreichend komplex waren, um einen gesamten Testort zu verbrauchen). Nun jedoch könnte der Unterschied auch dadurch bedingt sein, dass Testorte miteinander verbunden wurden, um Mehrort-Teststationen zu bilden (DUTs, die für einen einzelnen Testort zu komplex sind).
Eine Testsystemsteuerung 2 ist durch einen Systembus 3 mit ganzen 36 Testortsteuerungen verbunden, deren Namen auf die Suffixe Nr. 1 bis Nr. 36. enden, z. B. (4a bis 4z). Die Testsystemsteuerung 2 ist ein Computer (z. B. ein PC, auf dem NT läuft), der ein geeignetes Testsystemsteuerprogramm ausführt, das zu der Aufgabe eines Testens nichtflüchtiger Speicher gehört. Das Testsystemsteuerprogramm stellt die höchste Ebene an Abstraktion in einer hierarchischen Unterteilung von Arbeit (und von Komplexität) zum Erzielen des gewünschten Testens dar. Die Testsystemsteuerung bestimmt, welche Programme durch die unterschiedlichen Testorte laufen gelassen werden, sowie ein Beaufsichtigen eines Robotertechniksystems (nicht gezeigt), das die Testsonden und DUTs wie erforderlich bewegt. Die Testsystemsteuerung 2 könnte in Weisen funktionieren, die die Vorstellung unterstützen, dass einige Testorte programmiert sind, um als Einzelort-Teststationen zu arbeiten, einige als Multi-DUT-Teststationen, während andere miteinander verbunden sind, um Multi-Ort-Teststationen zu bilden. Klar gibt es unter derartigen Umständen verschiedene gerade getestete Teile und es ist sehr wünschenswert, dass unterschiedliche Tests für die unterschiedlichen Teile verwendet werden. Ähnlich besteht kein Erfordernis, dass alle Einzelort-Teststationen den gleichen Stil eines Teils testen, noch besteht ein derartiges Erfordernis für Multi-Ort-Teststationen. Entsprechend ist die Testsystemsteuerung 2 programmiert, um die Befehle zu erteilen, um das erforderliche Testort-Verbinden zu erzielen und dann die geeigneten Testprogramme für die verschiedenen verwendeten Teststationen hervorzurufen. Die Testsystemsteuerung 2 empfängt außerdem Informationen über Ergebnisse, die von den Tests erhalten werden, so dass sie die geeignete Aktion für ein Verwerfen des fehlerhaften Teils unternehmen kann, und so dass sie Protokolle für die verschiedenen Analysen beibehalten kann, die verwendet werden können, um z. B. Herstellungsprozesse in einer Fabrikumgebung zu steuern.
Das Testsystem selbst ist ein ziemlich großes und komplexes System und es ist üblich, dass dasselbe ein Robotertechnik-Teilsystem zum Laden von Wafern auf einen Tisch verwendet, der dann nachfolgend einen oder mehrere zukünftige Chips unter Sonden positioniert, die mit den Anschlussstiftelektroniken 9 verbunden sind, woraufhin diese zukünftigen Chips (der Wafer wurde noch nicht vereinzelt) getestet werden. Das Testsystem kann außerdem verwendet werden, um gehäuste Teile zu testen, die auf einen geeigneten Träger geladen wurden. Es gibt (wie unten erläutert ist) zumindest eine Testortsteuerung, die jeder verwendeten Teststation zugeordnet ist, unabhängig davon, wie viele Testorte verwendet werden, um diese Teststation zu bilden, oder davon, wie viele Teststationen sich auf einem Testort befinden. Eine Testortsteuerung ist ein eingebettetes System, das ein i960-Prozessor von Intel mit 36 bis 64 MB eines kombinierten Programm- und Datenspeichers sein kann, auf dem ein geeignetes Betriebssystem läuft, das VOS (VersaTest O/S) genannt wird, das in früheren Produkten zum Testen nichtflüchtiger Speicher verwendet wurde (z. B. das Agilent V1300 oder V3300). Im Moment werden wir nur die Situation für Einzelort-Teststationen betrachten. Eines bestimmten Beispiels wegen wird angenommen, dass ein Testort Nr. 1 als Teststation Nr. 1 funktioniert, und dass diese das WHIZCO-Teil Nr. 0013 testen soll. Die Testvorgabe beinhaltet etwa 100 unterschiedliche Typen von Tests (Variieren und Überwachen von Spannungspegeln, Pulsbreiten, Flankenpositionen, Verzögerungen, sowie eine große Dosis einfachen Speicherns und dann Wiedergewinnens ausgewählter Informationsmuster), und jeder Testtyp beinhaltet viele Millionen einzelner Speicherzyklen für das DUT. Auf der höchsten Ebene weisen die Operatoren des Testsystems die Testsystemsteuerung 2 an, die Teststation Nr. 1 zu verwenden, um ein Testen von WHIZCO 0013 zu beginnen. Bald sagt die Testsystemsteuerung 2 der Testortsteuerung Nr. 1 (4a) (die ein eingebettetes (Computer-)System ist), das zugeordnete Testprogramm laufen zu lassen, z. B. TEST_WHIZ_13. Wenn dieses Programm bereits in der Umgebung der Testortsteuerung Nr. 1 verfügbar ist, wird es einfach ausgeführt. Falls nicht, wird es durch die Testsystemsteuerung 2 bereitgestellt.
Nun könnte im Prinzip das Testprogramm TEST_WHIZ_13 vollständig in sich geschlossen sein. Wenn das jedoch der Fall wäre, wäre es fast sicher ziemlich groß und es könnte für den Prozessor des eingebetteten Systems innerhalb der Testortsteuerung 4a schwierig sein, ausreichend schnell zu laufen, um die Tests mit der erwünschten Geschwindigkeit oder selbst mit einer Rate, die von einem DUT-Speicherzyklus zu dem nächsten einheitlich ist, zu erzeugen. Entsprechend werden Aktivitäten vom Typ einer Teilroutine auf niedriger Ebene, die Sequenzen von Adress- und zugeordneten Daten erzeugen, die geschrieben werden sollen oder von einer Leseoperation erwartet werden, wie erforderlich durch einen programmierbaren algorithmischen Mechanismus erzeugt, der sich in dem DUT-Tester 6 befindet, der jedoch synchron zu dem gerade durch das eingebettete System in der Testortsteuerung 4 ausgeführten Programm arbeitet. Dies kann man sich als Exportieren einer bestimmten Aktivität, die einer Teilroutine auf niedriger Ebene ähnelt, vorstellen, sowie die Aufgabe eines Einleitens von DUT-Speicherzyklen zu einem Mechanismus (dem DUT-Tester), der näher an der Hardwareumgebung des DUT 14 ist. Allgemein ausgedrückt liefert jedes Mal, wenn die Testsystemsteuerung 2 eine Testortsteuerung mit einem Testprogramm ausrüstet, diese auch dem zugeordneten DUT-Tester geeignete Implementierungsroutinen auf niedriger Ebene (vielleicht spezifisch für den gerade getesteten Speicher), die erforderlich sind, um die beschriebene oder durch die Programmierung für die Testortsteuerung erforderliche Gesamtaktivität zu erzielen. Die Implementierungsroutinen auf niedriger Ebene werden „Muster" genannt und sie sind allgemein benannt (wie auch Funktionen und Variablen in Programmiersprachen auf hoher Ebene Namen besitzen).
Jede Testortsteuerung Nr. n (4) ist mit ihrem zugeordneten DUT-Tester Nr. n (6) durch einen Testortbus Nr. n (5) gekoppelt. Die Testortsteuerung verwendet den Testortbus 5, um sowohl dem Betrieb des DUT-Testers zu steuern als auch Informationen über Testergebnisse von demselben zu empfangen. Der DUT-Tester 6 ist in der Lage, mit hoher Geschwindigkeit die verschiedenen DUT-Speicherzyklen zu erzeugen, die in der Testvorgabe beinhaltet sind, und er entscheidet, ob die Ergebnisse eines Speicherlesezyklus wie erwartet sind. Im Grunde spricht er auf Befehle oder Operationscodes („Muster mit Namen") an, die von der Testortsteuerung gesendet werden, indem entsprechende nützliche Sequenzen von DUT-Speicher-Lesen- und -Schreiben-Zyklen eingeleitet werden (d. h. er führt die entsprechenden Muster aus). Vom Konzept her ist die Ausgabe des DUT-Testers 6 Stimulusinformationen, die auf das DUT angewendet werden sollen, und nimmt außerdem Antwortinformationen von demselben an. Diese Stimulus-/Antwortinformationen 7a laufen zwischen dem DUT-Tester 6a und einer Anordnung 9a von Anschlussstiftelektroniken Nr. 1. Die Anschlussstiftelektronikanordnung 9a unterstützt bis zu 64 Sonden, die auf das DUT 14 angewendet werden können.
Die oben erwähnten Stimulusinformationen sind nur eine Sequenz paralleler Bitmuster (d. h. eine Sequenz von „Sendevektoren" und erwarteten „Empfangsvektoren"), die gemäß den Spannungspegeln einer bestimmten Familie von Logikbauelementen, die in dem DUT-Tester verwendet werden, ausgedrückt ist. Es besteht eine konfigurierbare Abbildung zwischen Bitpositionen innerhalb eines Stimulus-/Antwortelements und den Sonden, die zu dem Chip gehen, und diese Abbildung wird durch den DUT-Tester 6 verstanden. Die einzelnen Bits sind in Bezug auf ihre Zeitgebung und Flankenplatzierung korrekt, zusätzlich zu der Abbildung jedoch benötigen diese unter Umständen auch eine Spannungspegelverschiebung, bevor sie an das DUT angelegt werden können. Ähnlich benötigt eine Antwort, die von dem DUT nach einem Stimulus hervorgeht, unter Umständen ein Zwischenspeichern und (Rück-)Pegelverschieben, bevor sie als geeignet, um zurück zu dem DUT-Tester geführt zu werden, betrachtet werden kann. Diese Pegelverschiebungsaufgaben sind das Gebiet der Anschlussstiftelektroniken 9a. Die Anschlussstiftelektroniken-Konfiguration, die zum Testen eines WHIZCO 0013 erforderlicht ist, funktioniert wahrscheinlich nicht zum Testen eines Teils von der ACME Co. und vielleicht nicht einmal mit einem anderen WHIZ Co.-Teil. So ist zu erkennen, dass die Anschlussstiftelektronikanordnung auch konfigurierbar sein muss; eine derartige Konfigurierbarkeit ist die Funktion der PE-Konfig.-Leitungen 8a.
Obiges endet mit einer kurzen Aufbauübersicht dessen, wie ein einzelner Testort zum Testen eines DUT strukturiert ist. Wir wenden uns nun Problemen zu, die entstehen, wenn es viele Testorte gibt, mit denen gearbeitet werden muss. Zuvor werden wir ein bevorzugtes Ausführungsbeispiel zum Aufbauen eines Testsystems mit mehreren Testorten beschreiben.
Man hat das Gefühl, dass es nützlich ist, zumindest in einer allgemeinen Weise die größeren Umrisse der Hardware-Eigenschaften des Testsystems zu beschreiben. Obwohl einige dieser Eigenschaften abhängig sind, unterstützt eine Kenntnis derselben trotzdem ein Verständnis verschiedener Beispiele, die zur Darstellung der unten beschriebenen bevorzugten Ausführungsbeispiele verwendet werden.
Zu Beginn werden vier ziemlich große Kartenkäfige betrachtet. Jeder Kartenkäfig besitzt neben Leistungsversorgungen und Wasserkühlung (Lüfter können eine Verunreinigungsquelle in einer Reinraumumgebung sein und gekühltes Wasser ist billiger als Klimaanlagenbetrieb zur Ableitung der mehreren zehn Kilowatt dissipierter Wärme für ein vollständig beladenes System), eine Hauptplatine, eine Frontplatte und eine Rückplatte. In jeden Kartenkäfig können bis zu neun Anordnungen platziert werden. Jede Anordnung umfasst eine Testortsteuerung, einen DUT-Tester und Anschlussstiftelektroniken. Wir werden nun die allgemeinen Umrisse dessen beschreiben, wie Testortsteuerungen miteinander verbunden sind, was einige Busse beinhaltet, die zur Erzeugung von Prioritätsverkettungen bzw. Daisy Chain verwendet werden.
Eine kurze Abschweifung bezüglich des Ausdrucks „Prioritätsverkettung" bzw. Daisy Chain ist vielleicht angebracht. Es werden Systemelemente A, B, C und D betrachtet. Es wird angenommen, dass diese miteinander in dieser Reihenfolge prioritätsverkettet werden sollen. Wir könnten sagen, dass es einen Informations- oder Steuerpfad gibt, der A verlässt und in B geht, dass B selektiv Verkehr weiterleiten kann, der dann B verlässt und in C geht, und dass C selektiv Verkehr weiterleiten kann, der dann in D geht. Diese gleiche Art von Anordnungen kann auch für Verkehr in der anderen Richtung existieren. Prioritätsverkettungen werden oft verwendet, um Prioritätsschemata zu erzeugen; wir werden diese verwenden, um Master/Slave- bzw. Haupt/Neben-Beziehungen zwischen verschiedenen Testortsteuerungen zu erzeugen. Wir werden diese Kommunikationsanordnungen im prioritätsverketteten Stil mit dem Suffixnomen „DSY", anstelle von „BUS" bezeichnen. So können wir uns auf eine Befehls/Daten-DSY anstatt einen Befehls/Datenbus beziehen.
Nun könnte die Vorstellung, dass Informationen „in B eintreten und selektiv weitergeleitet werden", nahe legen, dass Verkehr auf einen separaten Satz von Leitern reproduziert wird, bevor er weitergeleitet wird. Es könnte so sein, aus Leistungsgründen jedoch ist dies eher wie ein regulärer Bus mit adressierbaren Entitäten. Mittels einer programmierbaren Adressabbildungsanordnung und der Fähigkeit, Abschnitte nachgeschalteter Testortsteuerungen „zum Schlafen" zu bringen, kann der einzelne Bus hergestellt werden, um logisch als eine Mehrzahl von Prioritätsverkettungen zu erscheinen (d. h. zu funktionieren). Schließlich wird zu erkennen sein, dass die Prioritätsverkettungen Hochleistungswege für Befehls- und Steuerinformationen sind, und dass, wenn dies nicht der Fall wäre, wir nicht erwarten könnten, dass eine Master/Slave-Kombination (Multi-Ort-Teststation) so schnell arbeiten könnte wie ein einzelner Testort. Zu Gunsten einer Prioritätsverkettungsleistung verlassen die verschiedenen DSY ihre jeweiligen Kartenkäfige nicht. Die Wirkung dieser Entscheidung besteht darin, bestimmte Begrenzungen darauf zu platzieren, welche Testorte (und so auch wie viele) miteinander verbunden werden können. Im Prinzip gibt es keinen grundlegenden Bedarf nach dieser Einschränkung, noch besteht ein echter Mangel an damit einhergehender technischer Praktikabilität (es könnte gemacht werden); man glaubt einfach, dass, da es bereits neun Testorte in einem Kartenkäfig gibt, ein Erweitern der DSY wesentliche Kosten für relativ wenig zusätzlichen Vorteil hinzufügt.
In Weiterführung unserer Erläuterung von 1 werden die verschiedenen Testortsteuerungen 4a bis 4z betrachtet, die die vier Kartenkäfige bestücken können, jeweils mit neun Testortsteuerungen. Wir wollen diese als 4a bis 4f, 4g bis 4m, 4n bis 4t und 4u bis 4z bezeichnen (obwohl diese nominell nur 26 Tiefstellungen sind, gibt es vorzugsweise 36 Steuerungen). Eine CMD/DAT-DSY 17a (Befehls- und Datenprioritätsverkettung) verbindet die Testortsteuerungen 4a bis 4f, die in einem Kartenkäfig sind, untereinander, während eine unterschiedliche CMD/DAT-DSY 17b die Testortsteuerungen 4g bis 4m in einem weiteren Kartenkäfig untereinander verbindet. Die gleiche Anordnung gibt es für die verbleibenden Kartenkäfige und Testortsteuerungen 4n bis 4t bzw. 4u bis 4z. Wir haben bereits gesagt, dass die DSY die Kartenkäfige nicht verlassen, dahingehend, dass das „Schwanzende" eines Bus, der tatsächlich die DSY bildet, einen Kartenkäfig nicht verlässt und der Kopf des nächsten Segments in einem weiteren Kartenkäfig wird. Stattdessen geht der Systembus 3 von der Testsystemsteuerung 2 zu allen Testortsteuerungen und jede ist in der Lage, ein Hauptelement an dem Kopf eines DSY-Segments zu werden, das den Kartenkäfig nicht verlässt.
Die CMD/DAT-DSY 17a bis d, die wir bereits erläutert haben, existieren zwischen den verschiedenen Testortsteuerungen 4a bis 4z. Es gibt eine ähnliche Anordnung für die SYNC/ERR-DSY 18a bis 18d und die DUT-Tester 6a bis 6z. Die Synchronisierungs- und Fehlerinformationen, die durch die SYNC/ERR-DSY 18 befördert werden, ermöglichen es, dass die DUT-Tester im Gleichklang funktionieren können. Diese beiden Prioritätsverkettungen (17 und 18) tragen etwas unterschiedliche Typen von Informationen, jede liegt jedoch als Teil des gleichen allgemeinen Mechanismus zum Verbinden eines oder mehrerer Testorte miteinander in eine Teststation vor.
Wir wenden uns nun einer Erläuterung von 2 zu, die eine vereinfachte Blockdiagrammerweiterung des DUT-Testers 6 aus 1 ist, von denen es ganze 36 geben könnte. Es ist momentan ausreichend, nur eine Instanz derselben zu beschreiben. Ein Blick auf 2 zeigt, dass diese ziemlich gut bestückt ist, insbesondere für ein „vereinfachtes" Blockdiagramm. Ein Teil von dem, was in dem DUT-Tester 6 ist und in dem Blockdiagramm dargestellt ist, ist funktionsmäßig ziemlich kompliziert und nicht in einer „Standard"-Form verfügbar. Es ist hier angebracht, zwei Punkte anzumerken. Erstens besteht der Hauptzweck einer Beinhal tung von 2 darin, die Basiseigenschaften einer wichtigen Betriebsumgebung innerhalb des gesamten Testsystems 1 eines nichtflüchtigen Speichers zu beschreiben. Das oder die Ausführungsbeispiele, die in Verbindung mit 3 und nachfolgenden Figuren ausführlich beschrieben sind, sind entweder Erweiterungen von Mechanismen, die in der folgenden Beschreibung von 2 dargelegt sind, oder sie sind neue Mechanismen, deren Motivationsvoraussetzungen in 2 zu finden sind. Der zweite Punkt ist der, dass das erweiterte oder ausgedehnte Material, während es in allgemeiner Gesamtübereinstimmung mit 2 ist, Informationen beinhalten könnte, die nicht genau mit der vereinfachten Version „übereinstimmen". Dies bedeutet nicht, dass ein Fehler vorliegt, oder dass Dinge inkonsistent sind; dies entsteht, weil es manchmal schwierig oder unmöglich ist, etwas derart zu vereinfachen, dass es das exakte Bild in Verkleinerung ist.
2 ist tatsächlich eine Vereinfachung, die auf mittlerer Abstraktionsebene arbeitet.
Wie in 1 gezeigt ist, ist die Haupteingabe in den DUT-Tester 6 eine Instanz des Testortbus 5, die von einer Testortsteuerung 4 ausgeht, die der Instanz des DUT-Testers 6 zugeordnet ist, die von Interesse ist. Der Testortbus 5 ist mit einer Multibussteuerung 88 gekoppelt, die Verkehr auf dem Testortbus in Verkehr auf einem Ringbus 85 oder einem VT-Bus 89 umwandelt. Der Ringbusverkehr kann auch in VT-Busverkehr umgewandelt werden, und umgekehrt. Fast alles in 2 ist Teil einer bestimmten großtechnischen integrierten Schaltung; die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 (unten beschrieben) ist tatsächlich acht derartige ICs, obwohl wir diese hier der Kürze halber als eine Entität zeigen. Bis auf die verschiedenen externen DRAMs (von denen einige auch Teil des inneren Testspeichers 87 sind – siehe 3) ist ein Großteil des Rests von 2 Teil einer weiteren großen IC, die APG (Automatic Pattern Generator = automatischer Mustererzeuger) genannt wird, Der Ringbus 85 ist ein Universal-Zwischenmechanismus-Kommunikationspfad zum Konfigurieren der Hauptelemente innerhalb des APG-Abschnitts des DUT-Testers 6 und zum Setzen von Betriebsmodi usw. Außerdem gibt es verschiedene zweckgebundene sehr breite und sehr hochgeschwindigkeitsmäßige Pfade zwischen verschiedenen Elementen des APG. Der VT-Bus 89 ist ein IC-zu-IC-Bus zur Verwendung innerhalb des DUT-Testers selbst.
Der Ringbus 85 ist der Mechanismus, durch den die Testortsteuerung mit dem APG-Abschnitt des DUT-Testers 6 kommuniziert. Der Ringbus 85 ist mit einem Mikrosteuerungssequencer 19 gekoppelt, der mit einem Spezial-Mikroprozessor verglichen werden kann. Unter Verwendung einer Adresse, die durch einen Nächste-Adresse-Berechner 102 erzeugt wird, holt er Instruktionen von einem Programm ab, das in einem Programmspeicher gespeichert ist, der entweder intern in dem Mikrosteuerungssequencer 19 (PGM-SRAM 20) oder extern zu demselben (EXT. DRAM 21) sein kann. Obwohl diese beiden Speicher scheinbar durch etwas adressiert werden, was im Wesentlichen eine logisch gemeinsame Adresse 63 ist, die als ein Programmzähler dient (oder Instruktionsabholadresse), und beide eine Quelle auszuführender Programmierung sein können, wird angemerkt, dass (1) nur einer der Speicher während einer beliebigen Zeitperiode Instruktionsabhol-Speicherzyklen durchführt, und dass (2) tatsächlich diese durch elektrisch unterschiedliche Signale adressiert werden. Der SRAM ist schnell und ermöglicht einen wahrhaftig wahlfreien Zugriff, verbraucht jedoch wertvollen Raum innerhalb der Mikrosequenzsteuerung 19 (die Teil der großen APG-IC ist), so dass seine Größe eingeschränkt ist. Der externe DRAM kann in einstellbaren Mengen beträchtlicher Größe vorgesehen sein, ist jedoch nur schnell, wenn auf ihn in sequentiellen Stücken zugegriffen wird, die eine lineare Ausführung und keine Verzweigung beinhalten. Ein Programmieren in dem SRAM 20 ist sehr häufig etwas, was algorithmisch aufwändig ist, während der EXT. DRAM 21 am besten geeignet für Material ist, das nicht ohne weiteres durch algorithmische Prozesse erzeugt wird, wie z. B. Initialisierungsroutinen und zufällige oder unregelmäßige Daten.
Der Nächste-Adresse-Berechner 102 kann ein Verzweigen in dem gerade ausgeführten Testprogramm implementieren, ansprechend auf unbedingte Sprunginstruktionen oder bedingte Sprung- oder bedingte Teilroutineninstruktionen, die auf verschiedenen PROGRAMMSTEUERFLAGS (25), ANDEREN FLAGS (55) bedingt sind, und bestimmte andere Signale, die zur Klarheit separat gezeigt sind (DEF 0:3 103 und DPE 0:3 104), und die für einen Multi-DUT-Betrieb vorgesehen sind.
Das Instruktionswort, das durch den Mikrosteuerungssequencer 19 abgeholt und ausgeführt wird, ist ziemlich breit: 208 Bits. Es besteht aus 13 16-Bit-Feldern. Diese Felder stellen oft abgeholte Instruktionsinformationen für Mechanismen dar, die außerhalb des passenden Mikrosteuerungssequencers sind. Derartige Felder sind zweckgebunden für ihre zugeordneten Mechanismen. Ein Satz von ALU-INSTRUKTIONEN 22 wird auf eine Sammlung von acht 16-Bit-ALUs 24 angewendet, während andere an verschiedene andere Mechanismen ansgelegt werden, die in dem gesamten DUT-Tester verteilt sind. Diese spätere Situation ist durch die Linien und die Legende „VERSCHIEDENE STEUERWERTE & INSTRUKTIONEN" 42 dargestellt.
Die acht 16-Bit-ALUs (24) weisen jeweils ein herkömmliches Repertoire arithmetischer Instruktionen auf, die um zugeordnete 16-Bit-Ergebnisregister gebaut sind (jede ALU hat auch mehrere andere Register). Drei dieser Ergebnisregister und ihre zugeordneten ALUs dienen zur Erzeugung von X-, Y- und Z-Adresse-Komponenten 27, die verschiedentlich in eine vollständige Adresse kombiniert werden, die an das DUT geliefert wird. Zwei weitere der acht ALU/Register (DH & DL) sind vorgesehen, um bei der algorithmischen Erzeugung von 32 Bitdatenmustern 28 zu helfen, die zwischen einen höchstwertigen Abschnitt (DH) und einen niederstwertigen Abschnitt (DL) unterteilt sind. Letzte drei ALU/Register (A, B, C) werden als Zähler verwendet und tragen zu der Erzeugung verschiedener PROGRAMMSTEUERFLAGS 25 bei, die eine Programmsteuerung und Verzweigung auf die Fertigstellung einer bestimmten programmatisch spezifizierten Anzahl von Iterationen oder eine andere numerische Bedingung hin unterstützen. Diese PROGRAMMSTEUERFLAGS 25 werden zurück zu dem Mikrosteuerungssequencer 19 gesendet, wo diese den Wert der Instruktionsabholadresse (durch Nächste-Adresse-Berechner 102 berechnet) in Weisen beeinflussen, die denjenigen vertraut sind, die etwas über mikroprogrammierte Ausführungsmechanismen verstehen. Es gibt auch verschiedene WEITERE FLAGS 55, die zur Bewirkung einer Programmverzweigung verwendet werden können. Diese stammen von verschiedenen der anderen Mechanismen innerhalb des DUT-Testers 66, die durch die unterschiedlichen Felder des abgeholten Instruktionsworts gesteuert werden. Ein spezifisches zusätzliches Flag ist ausdrücklich als ein separates Objekt gezeigt: PD_ERR 90. Es wird an den PGM-SRAM 20 geliefert, stammt von dem Post-Decodieren-Mechanismus 60 und zeigt an, dass der Post-Decodieren-Mechanismus 60 einen Fehler entdeckt hat. Ein weiteres derartiges zusätzliches Flag ist VEC_FIFO_FULL 26. In einer anderen Zeichnung mit etwas weniger Details könnte es sich mit den WEITEREN FLAGS 55 zusammen tun. Wir haben es abgetrennt, um eine Erläuterung eines Aspekts der Funktionsweise des Mikrosteuerungssequencers 19 zu unterstützen.
Was VEC_FIFO_FULL tut, ist ein (zeitweiliges) Anhalten einer weiteren Programmausführung durch den Mikrosteuerungssequencer 19. Es gibt viele Pipelinestufen zwischen den Instruktionen, die durch den Mikrosteuerungssequencer 19 abgeholt werden, und den Mechanismen, die letztendlich Testvektoren abgeben, die auf das DUT angewendet werden sollen. Zusätzlich ist ein Teil des Gepäcks, das einen Vektor begleitet, wenn sich dieser in Richtung einer Anwendung auf das DUT bewegt, Informationen bezüglich der Rate einer letztendlichen Vektoranwendung oder einer Dauer jedes Vektors. So muss die Rate einer Vektoranlegung an das DUT nicht konstant sein und insbesondere könnte eine Gruppe von Vektoren länger in der Anlegung brauchen, als die Erzeugung derselben gedauert hat. Der Mikrosteuerungssequencer führt einfach eine Programmierung mit seiner maximalen Rate aus. Klar ist im Durchschnitt die Rate des „Vektorverbrauchs" gleich der Rate einer „Vektorerzeugung", damit die Pipeline nicht nahezu ohne Beschränkung elastisch sein muss. Es gibt ein Vektor-FIFO 45 an dem Ausgang des Adressabbilders 29, der unten erläutert ist, und es dient als elastische Kapazität in der Pipeline. Das Signal VEC_FIFO_FULL wird verwendet, um ein Überrollen der beschränkten Anzahl von Stufen in der Pipeline zu verhindern, indem eine zeitweilige Einstellung der Produktion neuer Vektoren an dem Kopfende der Leitung bewirkt wird.
Die 48 Bits von X-, Y- und Z-Adresse-Komponenten 27 werden an einen Adressabbilder 29 angelegt, dessen Ausgang eine zuvor ausgewählte, fast willkürliche Neuanordnung der Adresswerte in dem geordneten 48-Bit-Adressraum ist. Als ein Ausgangspunkt zum Verständnis wird für einen Moment angenommen, dass der Adressabbilder 29 ein Speicher wäre, der einen 48-Bit-Adressraum vollständig bestückt, und dass er an jeder Adresse einen 48-Bit-Wert hält.
Unter Annahme eines derartigen Speichers könnte eine Nachschlagtabelle implementiert sein, die eine beliebige angelegte Adresse in einen anderen willkürlich ausgewählten 48-Bit-Wert abbilden könnte, der dann als eine Ersatzadresse verwendet werden könnte. Der Grund dafür, dass eine derartige Adressabbildung wünschenswert ist, ist der, dass die X-, Y- und Z-Adresse-Komponenten allgemein eine nützliche Bedeutung in dem Kontext einer bestimmten inneren Architektur eines DUT aufweisen, die wahrscheinlich nicht mit einem großen linearen Decodierer implementiert ist. Die Vorstellungen von Zeilen, Spalten und Schichten, Blöcken oder Seiten können für den Testingenieur sehr nützlich sein und Fehler, die an Orten auftreten, die physisch nahe beieinander sind, könnten eine entsprechende Nähe bei ihren X-, Y- und Z-Adressen umfassen. Derartige Muster in den Testergeb nissen können bei der Erkennung dessen wertvoll sein, was falsch ist, sowie bei dem Versuch einer Behebung, ob nun auf einer Entwurfsebene oder einer Produktionsebene einer Neuprogrammierung eines Teils, um den Betrieb eines defekten Abschnitts durch denjenigen eines Ersatzabschnitts zu überbrücken. Zwei Probleme entstehen aus einer derartigen Denkweise. Das erste ist ein Stutzen der 48 Bits herunter auf die tatsächliche Anzahl von Bis (z. B. 32 oder vielleicht 16), die an das DUT angelegt werden sollen. Wir werden hier kurz erwähnen, wie das Stutzen durchgeführt wird, und es ist zum Großteil eine Sache, so viele Bits von X zu nehmen, so viele von Y und den Rest von Z. Jedoch nicht vollständig, und dies ist das zweite Problem, da bestimmte Adressen innerhalb eines Schaltungsaufbaus liegen könnten, der ein Links-für-Rechts- (oder Links-für-Rechts- und Oben-für-Unten-)Spiegelbild eines anderen Abschnitts des Schaltungsaufbaus ist. Dies hat die Wirkung eines Neuanordnens von dem, was die Bits bedeuten, insoweit, als nachfolgende Adresswerte in einer physischen Reihenfolge innerhalb dieses Schaltungsaufbaus sind. Diese Chipentwurfseigenschaft kann viele Male auftreten und es kann gut der Fall sein, dass die Tatsache, wie eine Gruppe von Bits, z. B. Y, interpretiert wird, von dem begleitenden Wert bestimmter anderer, z. B. Z-Bits abhängt. Der Adressabbilder 29 ist vorgesehen, um es zu ermöglichen, dass die rohen X-, Y- und Z-Adressen sozusagen „neu gehäust" werden, um dies zum Nutzen derer wiederzuspiegeln, die Speicher mit derartigen inneren Architekturanordnungen testen würden. In Bezug darauf, wie dies tatsächlich durchgeführt wird, ist der Adressabbilder 29 aus einer ziemlich großen Anzahl untereinander verbundener Multiplexer aufgebaut. Er kann nicht das vollständig willkürliche Nachschlagtabellenverhalten eines Decodierschemas eines vollständig bestückten Speichers implementieren, wie zeitweilig oben zu Erläuterungszwecken angenommen wurde. Er kann jedoch Teilfelder der X-, Y- und Z-Adresse-Komponenten wie erforderlich neu anordnen, insbesondere, da wiederum ein weiterer Mechanismus vorliegt, der das Stutzen von 48 Bits auf die tatsäch liche erforderliche Anzahl durchführt. Der Adressabbilder 29 beinhaltet außerdem drei 16-Bit-(Adress-)Nachschlagtabellen, die es ihm ermöglichen, eine eingeschränkte willkürliche Abbildung innerhalb lokaler Bereiche durchzuführen.
Die abgebildete Adressausgabe 30 des Adressabbilders 29 wird als eine Adresse an verschiedene Pufferspeicher und/oder Etikett-RAMs 31A bis B und an einen Fehlerfang-RAM 1/2 (32A/B) angelegt, die, während sie separate Funktionen aufweisen, trotzdem als auswählbare Partitionen in den vier Speichersätzen implementiert sein könnten, die kollektiv der innere Testspeicher 87 sind. Die abgebildete Adressausgabe 30 wird außerdem als eine Eingabe an eine Adressbitauswahlschaltung 37 angelegt, deren Multiplexfunktion in Bälde beschrieben wird. Der innere Testspeicher kann konfiguriert sein, um viele Instanzen verschiedener Speicherstrukturen auf RAM-Basis, die für unterschiedliche Funktionen verwendet werden, zu beinhalten. Dies wird durch ein Angeben, dass bestimmte Abschnitte der unterschiedlichen Speichersätze für die zugeordneten Zwecke verwendet werden sollen, erzielt. Was in 2 gezeigt ist, ist eine derartige Anordnung; Anordnungen können mit fortschreitendem Testen verändert werden, und das gesamte Geschäft der Verwendung eines Speichersatzes sollte als sehr dynamisch betrachtet werden. Keiner der Bewohner des inneren Testspeichers (z. B. der Fehlerfang-RAMs 32A bis B) ist eine permanente Hardwarevorrichtung. Was permanent ist, sind die vier Speichersätze. Welcher Teil welches Speichersatzes ein Fehlerfang-RAM zu einer bestimmten Zeit ist (wenn tatsächlich überhaupt einer definiert ist), hängt davon ab, welche Konfiguration eingerichtet wurde.
Nun werden die Pufferspeicher 31A und 31B betrachtet. Ihre Funktionen bestehen darin, die Datenmuster 33 und Adressen 34 zu behalten, die an das DUT angelegt werden können. Diese sind tatsächlich separate Ausgaben aus ihren zugeordneten Pufferspeichern, obwohl diese Pufferspeicher keine Dual-„Tor-Speicher" sind, sondern vorzugsweise aus Abschnitten zweier unterschiedlicher Speichersätze zusammengesetzt sind. Hierbei bleibend wird es bevorzugt, dass gespeicherte Daten 33 in einem Speichersatz gehalten werden, während gespeicherte Adressen 34 in einem anderen gehalten werden. Außerdem haben wir keinen expliziten Mechanismus zum Schreiben in einen Pufferspeicher gezeigt. Eine Weise, in der dies erzielt werden kann, ist durch eine adressierte Busoperation, die durch eine Testortsteuerung 4 eingeleitet wird, auf Geheiß des Programms, das sie ausführt. Es gibt einen „unter den Bodenplatten"-, sozusagen „Hilfsprogrammdienste"-Bus, der Ringbus 85 genannt wird, der zu geradezu allem in 2 geht (ein Großteil der Besuche hiervon ist nicht gezeigt – dies würde die Zeichnung immens voll stopfen). Eine weitere und schnellere Weise zum Schreiben von Informationen in die Speichersätze ist in Verbindung mit 3 beschrieben.
Die Fehlerfang-RAMs 32A bis B werden durch die gleiche Adresse adressiert, die an die Pufferspeicher angelegt wird, und diese speichern entweder Informationen über Fehler oder gewinnen diese wieder, wobei diese Operationen in Verbindung mit einer Post-Decodieren-Schaltung durchgeführt werden, wie später erläutert werden wird. Wie bei den Pfaden 33 und 34 von den Pufferspeichern 31A bis B sind Pfade 62A bis D (von dem Fehlerfang-RAM1 32A) vorzugsweise einem MUX unterzogene Ausgaben von einem Abschnitt eines Speichersatzes (konfiguriert, um als ein Fehlerfang-RAM zu wirken) gemäß Konfigurationsinformationen, die durch den Ringbus (nicht gezeigt) verteilt werden.
Es wird angemerkt, dass der Daten-MUX 35 als Eingaben die GESPEICHERTE DATEN-Ausgabe 33 von dem Pufferspeicher 31A aufweist, sowie Daten 28 von den Registern DH und DL in der Sammlung 24 von ALUs. Der Daten-MUX 35 führt eine anfängliche Auswahl gemäß Werten 36, die in dem PGM-SRAM 20 gespeichert sind, welche dieser Eingaben (28, 32) an seinem Ausgang 38 vorgelegt werden sollen, durch, was dann, es sei denn, dies ist modifiziert, wie als nächstes beschrieben wird, als einer von zwei Vektorkomponenten an eine Schaltung zum Senden von Vektorabbilder/Serialisierer & Empfangen von Vektorvergleichsdaten 40 angelegt wird (die andere Komponente ist der Ausgang 39 der Adressbitauswahlschaltung 37).
Die Schaltung 40 kann drei vektorbezogene Funktionen durchführen: Zusammensetzen von Vektorkomponenten (38, 39) in eine geordnete logische Darstellung eines gesamten Vektors, der an das DUT angelegt (übertragen) werden soll; Anwenden einer willkürlichen dynamischen Korrespondenz (Abbildung) zwischen den geordneten Bits der logischen Darstellung des Sendevektors und der tatsächlichen physischen Kanalanzahl der Anschlussstiftelektroniken (d. h. welche Sondenspitze das DUT im Namen dieses Signals (d. h. dieses Bits in dem Vektor) berühren wird); und Zusammenarbeiten mit dem Kompilierer bei der Unterteilung eines gesamten logischen Vektors in Stücke, die separat angelegt werden sollen und in einer Reihenfolge (Serialisierung) für DUTs, die etwas derartiges zulassen. Welche dieser Funktionen durchgeführt wird, wird durch Steuersignale von einem SRAM 41 bestimmt, der auch gemäß einem Feld in den 208 Bits Instruktion adressiert wird, die durch den Mikrosteuerungssequencer 19 abgeholt wird.
Außerdem in der Schaltung 40 beinhaltet ist ein Abschnitt einer DUT-Deaktivieren-Logik 90. Ihr Zweck besteht darin, auf verschiedene Bedingungen, einige statisch, einige abhängig von Testergebnissen, jedoch alle programmatisch definiert, anzusprechen, die anzeigen, welches oder welche DUTs unter ganzen vier derselben deaktiviert werden sollen. Diese Anzeigen werden durch vier Signale DD 0:3 44b getragen (DUT-Deaktivieren für DUT Null, für DUT Eins usw.). Dies unterstützt ein Multi-DUT-Testen an einem Testort. Die Ausgabe der Schaltung 40 ist ein bis zu 64 Bit langer Vektor 44a, der gemeinsam mit den DUT-Deaktivieren-Signalen 44b an ein Vektor-FIFO 45 angelegt wird, das dann vollstän dig das Signal VEC_FIFO_FULL 26 erzeugt, dessen Bedeutung und Verwendung oben erläutert wurde. Der Vektor oben in dem Vektor-FIFO 45 wird auf den Empfang eines Signals VEC_FIFO_UNLOAD 47, das von einem Periodenerzeuger 49 (wird in Kürze erläutert) ausgeht, daraus entfernt. Derartige entfernte Vektoren (46) werden an eine Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 angelegt, die mit dem DUT über die zugeordnete Instanz von Anschlussstiftelektroniken 9 verbunden ist. Dies bedeutet, dass jede Instanz (unter den verschiedenen Testorten) von Anschlussstiftelektroniken 9 gesendete & empfangene Vektoren 7 und Anschlussstiftelektronik-Konfigurationsinformationen 8 von der zugeordneten Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 empfängt.
Die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 ist mit dem VT-Bus 89 gekoppelt, um Konfigurations- und Steuerinformationen zu empfangen. Es wird in Erinnerung gerufen, dass die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 tatsächlich acht ICs ist, die wir für unsere Zwecke als eine einzelne Entität behandeln.
Die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 weist einen internen SRAM 54 auf, der durch die gleiche Instruktionsadresse adressiert wird („A" in dem kleinen Kreis) wie der Programm-SRAM 20 des Mikrosteuerungssequencers 19. (Ein externer DRAM 53 könnte anstelle des internen SRAM 54 verwendet werden, wird jedoch lokal durch einen inkrementierten Zähler adressiert, der nicht gezeigt ist.) Der interne SRAM 54 (oder externe DRAM 53) unterstützt die Erzeugung von Treiber- und Vergleichszyklen, die zugeordnete Formate aufweisen. Treiberzyklen legen einen Sendevektor an das DUT unter Verwendung eines vorausgewählten Formats an, das durch einen der RAMs 54 oder 53 geliefert wird. Vergleichszyklen empfangen einen Vektor, der durch das DUT vorgelegt wird, und prüfen denselben, ebenso gemäß einem vorausgewählten RAM-gelieferten Format, um zu bestimmen, ob dies mit zuvor gelieferten Vergleichsdaten übereinstimmt.
Sowohl Treiber- als auch Vergleichszyklen sind in Bezug auf ihre Dauer einstellbar und in Bezug darauf geeignet einstellbar, ob und wann eine Last angelegt wird, wann Daten zwischengespeichert oder übernommen werden, ob ein Signal Rückkehr-zu-Null oder nicht ist, ob ein getriebenes Signal mit seinem Komplement zu umgeben ist usw. (Diese Optionen sind die oben erwähnten verschiedenen Formate).
Der Vergleich, der durch die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 erzeugt wird, umfasst Informationen, auf einer Pro-Kanal-Basis, darüber, ob ein Kanal ausgefallen ist, weil ein logischer Wert falsch war (ein Funktionsfehler) und/oder weil seine elektrischen Eigenschaften außerhalb annehmbarer Grenzen sind (ein Parameterfehler). Ferner ist, wenn ein Mehrfach-DUT-Testen durchgeführt wird, bekannt, welche Kanäle welchen DUTs zugeordnet sind. Dies erlaubt die Erzeugung der vier Signale DFE 0:3 (DUT Nr. Funktionsfehler) 103 und der vier Signale DPE 0:3 (DUT Nr. Parameterfehler) 104.
Der Vergleich, der durch die Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 durchgeführt wird, erzeugt außerdem einen 64-Bit-Wert 56, der an einen Empfangsvektor-Rückabbilder/Deserialisierer 57 angelegt wird, dessen Funktion als das logisch Inverse der Schaltung 40 betrachtet werden kann. (Der Betrieb der Schaltung 57 wird durch einen SRAM 58 gesteuert, der der Steuerung der Schaltung 40 durch den SRAM 41 entspricht.) Die Ausgabe 59 der Schaltung 57 wiederum wird an die Post-Decodieren-Schaltung 60 angelegt und außerdem an den Fehlerfang-RAM1 32A. Gegenwärtig ist es ausreichend zu sagen, dass die Post-Decodieren-Schaltung 60 über programmatische Kriterien sowohl eingehende Fehlerinformationen 59 als auch Fehlerinformationen, die zuvor in dem Fehlerfang-RAM1 32A gespeichert wurden, untersuchen kann, um komprimierte und besser interpretierbare Fehlerinformationen zu erzeugen, die dann in den anderen Fehlerfang-RAM2 32B über einen Pfad 61 zurück gespeichert werden können. Ein Beispiel wäre es, einen Zählwert dessen zu erzeugen, wie viele Male ein Fehler innerhalb eines bestimmten Bereichs von Adressen vorlag, welche Informationen nützlich sein können bei der Entscheidung, wann zu versuchen ist, sich mit einer chipinternen Reparatur zu beschäftigen, indem Ersatzschaltungen aktiviert werden.
Wir wenden uns nun dem Periodenerzeuger 49 und seinem zugeordneten Zeitgebungs-SRAM 51 zu. Diese sprechen auf ein Acht-Bit-Signal T_SEL 43 an, das für jede 208-Bit-Instruktion, die durch den Mikrosteuerungssequencer 19 abgeholt wird, eine Dauer für den zugeordneten Betrieb der Zeitgebungs-/Formatierungs- & Vergleichsschaltung 52 bestimmt. T_SEL 43 ist Element der verschiedenen Steuerwerte & Instruktionen 42, die durch die unterschiedlichen Felder innerhalb der abgeholten Instruktion dargestellt sind. Als ein Acht-Bit-Wert kann es 256 unterschiedliche Dinge darstellen oder codieren. In diesem Fall sind diese „Dinge" 28-Bit-Werte, die in dem Zeitgebungs-SRAM 51 gespeichert sind, und die durch T_SEL adressiert werden. Jeder adressierte 28-Bit-Wert (23) spezifiziert eine erwünschte Dauer mit einer Auflösung von 19,5 Pikosekunden. Die Sequenz von 28-Bit-Dauer-Werten (23), auf die zugegriffen wurde, ist in einem Perioden-FIFO 50 gespeichert, so dass die einzelnen Elemente dieser Sequenz synchron zu der Wiedergewinnung ihres beabsichtigten entsprechenden Vektors, der in dem Vektor-FIFO 45 gespeichert ist, wiedergewonnen und angelegt werden.
Ein Grobzeitgebungswertfeld in dem ältesten Eintrag in dem FIFO 50 befördert Dauerinformationen mit einer Auflösung von fünf Nanosekunden und erzeugt aus denselben ein Signal VEC_FIFO_UNLOAD 47, das den nächsten Sendevektor von dem Vektor-FIFO 45 zu der Zeitgebungs/Formatierungs- & Vergleichsschaltung 52 überträgt. Ein begleitendes Signal ZEITGEBUNGSREST 48 wird außerdem an die Schaltung 52 angelegt. Dort wird die letztendliche Auflösung von 19,5 Pikosekunden erzielt.
Nun wird Bezug auf 3 genommen, die ein vereinfachtes Blockdiagramm 64 einer Erweiterung eines Abschnitts des Blockdiagramms 6 aus 2 ist, um ein ALU-Historie-FIFO 69 und einen verwandten Steuerschaltungsaufbau zu umfassen. Der beste Ort, um zu beginnen, ist der Nächste-Adresse-Berechner 102, dessen Verantwortung darin besteht, die Sequenz von Adressen 63 zu erzeugen, die an den PGM-SRAM angelegt wird, der die tatsächlichen 208-Bit-Instruktionswörter speichert, die durch die Hardware ausgeführt werden. Dies bedeutet, dass der Nächste-Adresse-Berechner 102 der Halter des Programmzählers ist, der die Adresse anzeigt, von der das nächste Instruktionswort abgeholt werden soll. Das Signal PGM_STEP 83 wird jedes Mal angelegt, wenn eine neue gültige Adresse vorliegt.
Der Nächste-Adresse-Berechner 102 implementiert eine Verzweigung innerhalb des Testprogramms durch Ansprechen mit Adressen außerhalb der Sequenz (63), wenn ein gerade ausgeführtes Maschinenwort dies zulässt und das zugeordnete Flag (55), eine Programmsteuervariable (25) usw. vorhanden ist. Unter den Signalen von Interesse bei dieser Kapazität ist eines, das PD_ERROR 90 (Post-Decodieren-Fehler) genannt wird. Es stammt von der Post-Decodieren-Schaltung 60 aus 2 und wird in der aufgenommenen Anmeldung mit dem Titel MEMORY TESTER WITH ENHANCED POST DECODE ausführlich erläutert. Die kurze Antwort auf die Frage „Was bedeutet dies?" ist, dass Post-Decodieren bestimmt hat, dass bestimmte konfigurierbare (innerhalb der Post-Decodieren-Schaltung 60 selbst) Kriterien zum Erfassen eines Fehlers erfüllt wurden. Was uns gegenwärtig interessiert, ist, welcher Testprogrammort und welche relevanten Zustandsinformationen dem Einsetzen von PD_ERROR 90 zuzuordnen sind. Dies bedeutet, dass wir den Inhalt von X-, Y- und Z-Adressen des ALU-Registers, vielleicht den Inhalt des DH- und des DL-Registers (sie kombinieren sich, um 32 Bits Daten zu sein), und vielleicht auch den Inhalt des A-, Bund C-Registers (sie können als Schleifenindizes oder für anderes Testprogrammsteuern verwendet werden) kennen müs sen. Um in der Lage zu sein, den Inhalt dieser Register wiederzugewinnen, ist der Grund dafür, warum es ein ALU-Historie-FIFO 69 gibt. Bei einigen Ausführungsbeispielen könnte es ausreichend sein, nur die Adressregister zu beinhalten, während in anderen zusätzliche Register vorliegen könnten, die hier nicht erwähnt sind, deren Beinhaltung in dem ALU-Historie-FIFO 60 nützlich wäre.
Die Vorstellung ist die, dass das Testprogramm periodisch auf das PD_ERROR-Signal testet und voraussichtlich in der Lage sein wird, sein Vorliegen einem Bedarf nach einem SPRUNG an einen bestimmten Ort in dem Programm zuzuordnen. Es ist jedoch sehr wahrscheinlich, dass das Ziel des SPRUNGS tatsächlich nur eine Schablone, dies zu tun, ist, und dass, damit der SPRUNG sich wie beabsichtigt verhält, der Inhalt verschiedener Register wiederhergestellt werden muss (diejenigen, die in dem Historie-FIFO gespeichert sind). Das Ziel des SPRUNGS jedoch könnte nicht einmal der wahre Wert des Programmzeigers sein, dessen Instruktion später den PD_ERROR von Interesse „bewirkt" hat. In Verbindung mit diesen Gründen wird dann angemerkt, dass der Wert des Programmzeigers für den Nächste-Adresse-Berechner 102 nicht unter den Objekten ist, die in dem ALU-Historie-FIFO gespeichert sind. Im Gegensatz zu einem Kontextschalter in einem Mikroprozessor verlassen wir uns auf einen regulär programmierten SPRUNG, um zu bewirken, dass der Testprogrammort dort hingeht, wo er soll. Das ALU-Historie-FIFO stellt vielleicht unter Programmsteuerung oder vielleicht automatisch einen Kontext von DUT-Adressen, DUT-Daten und vielleicht Programmschleifensteuerindizes wieder her. Auf diese Weise kann das Ergebnis eines ALU-Historie-FIFO-Ereignisses flexibel durch die genaue Programmierung, die es bewirkt, geleitet werden.
Das 208-Bit-Instruktionswort 65, das von dem PGM-SRAM 20 abgeholt wird, umfasst für unsere aktuellen Zwecke einen n-Bit-Abschnitt, der ALU-INSTRUKTIONEN (22, 66) beschreibt, die zu einem ALU-Betrieb gehören (sprich: „algorithmische Steuerung von Testprogrammen"). Es gibt einen Ein-Bit-Abschnitt 68, der BEGIN_HIST genannt wird, dessen Bedeutung und Verwendung wir unten kurz beschreiben werden. Der verbleibende Abschnitt 67 ist das, was auch immer von den 208 Bits übrig bleibt, und geht verschiedentlich dort hin, wo dies beabsichtigt ist.
Die ALU-INSTRUKTIONEN (22, 66) werden auf eine Sammlung eines ALU-Instruktionsschaltungsaufbaus 70 angelegt, der geeignet mit einer Sammlung von ALU-Registern (71 bis 78) verbunden ist. Diese sind die gleichen, die in 2 gezeigt sind, und sind hier in 3 folgendermaßen genannt: A_ALU-Register 71; B_ALU-Register 72; C_ALU-Register 73; DH_ALU-Register 74; DL_ALU-Register 75; X_ALU-Register 76; Y_ALU-Register 77 und Z_ALU-Register 78. Es wird darauf verwiesen, dass der Kürze halber wir in 3 nicht alle Verbindungen zu diesen verschiedenen Registern gezeigt haben; sie sind weiterhin so verbunden, wie in 2 gezeigt ist. Es wird jedoch angemerkt, dass jedes Register als an einen Abschnitt des ALU-Historie-FIFO 69 angrenzend gezeigt ist; tatsächlich weist das ALU-Historie-FIFO 69 acht Spalten, Felder oder Abschnitte auf, wobei der Eingang zu jedem derselben eines der acht ALU-Register ist, die oben genannt sind. Da sie im Gleichklang betrieben werden, sind die Tiefen aller dieser FIFO-Abschnitte gleich. Eine Tiefe von 85 oder eine ähnliche Tiefe wird bevorzugt, wobei diese Zahl aus der Summe der Längen für die beiden Pipelines entsteht, was etwa jeweils 40 ist. Unten zeigt die dicke schwarze Linie 105 an, dass Ausgaben der acht FIFO-Abschnitte alle gesammelt werden und für den Rest des Systems über den Ringbus 85 verfügbar gemacht werden (während einer UNLOAD- bzw. ENTLADEN-Operation).
Das ALU-Historie-FIFO 69 weist vier Steuersignale auf, die von Interesse sind. Diese sind ein RESET-Signal 79, das einen (internen) FIFO-Laden-Zeiger und einen (internen) FIFO-Entladen-Zeiger auf einen Anfangswert setzt, und vielleicht den gesamten Inhalt herauslöscht. Es gibt ein LOAD- bzw. LADEN-Signal 81, das bewirkt, dass der Inhalt der acht zugeordneten Register 71 bis 78 in ihre jeweiligen FIFO-Abschnitte geladen wird und der FIFO-Laden-Zeiger weiterbewegt wird. Es gibt ein ENTLADEN-Signal 107, das bewirkt, dass die frühesten geladenen Werte aus dem FIFO extrahiert werden und der Wert des Entladen-Zeigers inkrementiert wird. Die Extraktion geschieht zu dem Ringbus und so zu einem bestimmten Zwischen- oder vielleicht Endziel. Eine Alternative zu einem direkten Entladen an den Ringbus wäre eine Speicherung in bestimmte zweckgebundene Halteregister (nicht gezeigt), deren Inhalt dann über den Ringbus zu einem beliebigen erforderlichen Ort befordert werden könnte, oder vielleicht über zweckgebundene Pfade schnell zurück in die passenden ALU-Register. Diese Anordnungen ermöglichen unter einer programmatischen Steuerung die Untersuchung (falls Bedarf besteht) und Wiederherstellung der Werte dieser ALU-Register von Interesse. Es wird angemerkt, dass ein ENTLADEN mehr Bits beinhaltet als die Breite des Ringbusses. Diese Situation könnte gehandhabt werden, indem zuerst zu den zugeordneten zweckgebundenen Halteregistern ENTLADEN wird (was schnell sein kann), wonach dann eine versetzte Übertragung der Halteregister zu dem Ringbus folgen könnte. Wenn ein ENTLADEN streng durchgeführt wird, um Daten herauszuschmeißen, kann deren zugeordnete versetzte Übertragung weggelassen werden.
Das verbleibende FIFO-Steuersignal ist FULL bzw. VOLL 80, das anzeigt, dass es keine entladenen Orte innerhalb des FIFO gibt, und dass mögliches weiteres Laden zu Verlustinformationen führen wird (wobei neue alte überschreiben). Wir wollen dies verhindern, da es dem Zweck des Historie-FIFO entgegenwirkt, und wir haben das FIFO ausreichend tief gemacht, um mit den Pipelines zusammenzupassen. Entsprechend wird das Signal VOLL invertiert und einer UND-Operation mit dem Quellensignal für LADEN unterzogen (was schließlich PGM_STEP 83 ist), um so zu verhindern, dass jedes Mal ein LADEN 81 auftritt, wenn VOLL 80 WAHR ist.
Diese UND-Verarbeitung wird durch ein UND-Gatter 82 durchgeführt.
Noch eine weitere Vorbereitung und wir nehmen das ALU-Historie-FIFO in Betrieb. Wie bereits erwähnt wurde, sind Pipelinetiefen nicht für alle Zeit fest, sondern variieren entsprechend der Betriebskonfiguration des Speichertesters, der für jeden bestimmten Bedarf erzeugt wird, wobei diese Variationen auf der Ebene aufeinander folgender Segmente eines Testprogramms auftreten könnten. Es gibt eine Organisationsfunktion, die durch Überwachungssoftware durchgeführt wird, die mit einem Laden und Ausführen von Testprogrammen verbunden ist, was sich darum kümmert, dass für jedes Segment eines Testprogramms bekannt ist, was die effektive Pipelinetiefe ist (dies ist bekannt, da dort auch eine Sammlung von Hilfsprogrammen zuhause ist, die verwendet wird, um mögliche Konfigurationsveränderungen durchzuführen, die durch das Testprogramm erforderlich sind). Dieser Wert wird durch diese Überwachungssoftware, zu Beginn und ansprechend auf mögliche Veränderungen an demselben, in ein Pipelinetiefenregister 84 gegeben. Von hier kann er auf das Auftreten des Signals BEGIN_HIST 68 hin, das außerdem das FIFO 69 rücksetzt, in einen Abwärtszähler 100a kopiert werden.
BEGIN_HIST 68 ist im Wesentlichen ein Flag, das in das Testprogramm eingebettet ist, das sich als ein Ein-Bit-Feld in dem 208-Bit-Instruktionswort zeigt. Seine Bedeutung ist, dass das Instruktionswort, von dem es ein Teil ist, oder dem es folgt, der Ort in dem Testprogramm ist, den das ALU-Historie-FIFO 69 später identifizieren soll, sollte ein nachfolgend nachgeprüftes Fehlerflag (PD_ERROR 90) WAHR sein. Ein weiterer Weg, es aufzufassen, besteht darin, dass wir bereit sind, mögliche frühere Historie herauszuschmeißen und eine neue zu starten. So wurde an diesem Punkt in dem Testprogramm BEGIN_HIST 68 angelegt und das FIFO 69 wird rückgesetzt und der Abwärtszähler 100a wird mit der effektiven Pipelinetiefe von dem Register 84a geladen. (Ein weiterer Abwärtszähler 110b wird auch von einem Pipelinetieferegister Nr. 2 geladen. Genauere Details folgen.) Es gibt, wenn weitere Instruktionen von dem PGM-SRAM 20 abgeholt und ausgeführt werden, entsprechende Einsätze für das Signal PGM_STEP 83. Diese bewirken entsprechende Instanzen von LADEN 81 für das FIFO (das FIFO ist noch nicht einmal annähernd voll) und entsprechende Instanzen eines Dekrementierens des Abwärtszählers 100a (es wird angemerkt, dass PGM_STEP 83 zu dem ZÄHLWERT-Anschluss des Abwärtszählers 100a, wie auch zu 100b geht). Schließlich erreicht der Zählwert in dem Abwärtszähler 100a Null und dies wird durch eine Ausgabe aus einer ZÄHLWERT Nr. 1 = Null-Schaltung 101a angezeigt, die mit dem Abwärtszähler 100a verbunden ist. Dieser Zustand bedeutet, dass die effektive Pipelinetiefe erreicht wurde, und dass wir nun die Anzahl von Einträgen in dem FIFO 69 zahlenmäßig nicht mehr ansteigen lassen sollten und damit beginnen sollen, die verwendete FIFO-Tiefe konstant zu halten. Auf diese Weise haben wir, wenn sich ein PD_FEHLER zeigt, das, was wir an dem „FO"-Ende des FIFO benötigen.
Wenn noch keine Instanz von PD_ERROR 90 vorlag, ist es sicher, das FIFO jedes Mal einmal zu entladen, wenn wir es mit einem neuen Wert beladen (eine unterschiedliche Sammlung von Werten besetzt das „FO"-Ende des Historie-FIFO 69). Was dies bedeutet, ist, dass das BEGIN_HIST-Signal früher als andernfalls war oder vielleicht, dass noch kein PD_ERROR vorlag (tatsächlich könnte es nie eines geben). Die LADEN/ENTLADEN-Operation verhindert in jedem Fall, dass das FIFO voll wird. Dennoch müssen wir noch sagen, wie ENTLADEN 107 erzeugt wird, und müssen kurz abschweifen.
Es gibt ein Ein-Bit-Historie-Modus-Latch 105, das über den Ringbus 85 gesetzt werden kann. Seine Bedeutung ist die, dass wir das gesamte Historie-FIFO-Steuerzeug aktivieren möchten, das wir im Moment beschreiben. Dem ALU-Historie-Modus-Latch 105 zugeordnet ist ein Setzen/Rücksetzen-Latch 98, das auch durch das Signal BEGIN_HIST 83 rückgesetzt wird. Was das Latch 98 zurücksetzt, ist das Signal PD_ERROR 90, jedes Mal, wenn das ALU-Historie-Modus-Latch 105 gesetzt wird. Dies wird durch das UND-Gatter 86 erzielt.
Weiter wird dann das FIFO 69 jedes Mal einem ENTLADEN unterzogen, wenn eine neue Instruktionsabholung vorliegt (Instanz von PGM_STEP 83), während die ZÄHLWERT Nr. 1 = NULL-Schaltung 101a anzeigt, dass das FIFO 69 nun die effektive Tiefe der Pipelines überspannt (der Zählwert ist Null), und dass noch keine Instanz von PD_ERROR vorlag. Unter Umständen gibt es niemals eine derartige Instanz, wir gehen nun jedoch davon aus, dass dies schließlich der Fall ist. Nun wird die Q-Ausgabe des Latch 98 gesetzt (ihr Signalname ist FREEZE_HIST 99) und ihre Inversion an dem Eingang des UND-Gatters 106 verhindert eine weitere Erzeugung des ENTLADEN-Signals 107. Wir haben nun die Werte von Interesse für die Register 71 bis 78 eingefangen; sie sind das, was wir erhalten, wenn wir das nächste ENTLADEN durchführen. (Was wahrscheinlich dann der Fall sein wird, wenn etwas Software dazukommt. Außerdem haben wir dies nicht gezeigt, aber die Software kann ein ENTLADEN an den Ringbus oder was auch immer erzwingen, um die erwünschten Werte zu erhalten.) Man könnte sich an diesem Punkt fragen, warum es nicht auch ratsam ist, nun auch ein LADEN zu deaktivieren. Die Antwort ist die, dass man dies tun könnte, dass es jedoch tatsächlich nicht von Belang ist, solange das Signal VOLL 80 die Erzeugung von LADEN deaktiviert, was durch das UND-Gatter 82 durchgeführt wird.
Man könnte sich auch fragen, was passiert, wenn PD_ERROR vor ZÄHLWERT Nr. 1 = NULL auftritt.... Die kurze Antwort ist die, dass dies niemals, NIEMALS(!) geschehen sollte. Falls dies geschieht, bedeutet dies, dass Unachtsamkeit bei der Art und Weise vorgelegen ist, in der die Instanzen von BEGIN_HIST (die bei dem Testprogrammabruf ausgehen) verwendet wurden, relativ zu einem Setzen des Historie-Modus-Latch 105 und einem Konfigurieren des Post-Decodieren- Schaltungsaufbaus 60, zur Erzeugung (oder vielleicht Rücksetzung) von PD_ERROR 90. Die Situation ähnelt etwas einem Kompilierer, der nach fehlangepassten Klammern in einem System sucht, das kein Verschachteln oder Überlappen von Klammerausdrücken erlaubt. (Schließlich gibt es nur den einen Satz von Historie-FIFOs.)
Da wir nun diesen ALU-Historie-FIFO-Mechanismus zum Korrelieren eines bereits existierenden Programmorts und -zustand mit einem Fehlerflag besitzen, sind wir versucht, denselben für einen zusätzlichen anderen Zweck als den zu verwenden, für den er ursprünglich beabsichtigt war. Um zu sehen, wie dies funktioniert, stellen wir die Frage „Warum sollte dieser prima Mechanismus darauf eingeschränkt sein, ALU-Bedingungen nur nach einem PD_ERROR wiederzugewinnen? Das ALU-Historie-FIFO beinhaltet eine Verzögerung, die die Pipeline anpasst, und es gibt einen Weg, wie wir dies verwenden können, um den Wert eines Fehlersignals oder Flags zu (oder sogar nach) der Zeit, zu der dies geschieht, genau zu testen, was ist die Pipelineverzögerung, nachdem die zugeordnete Instruktion abgeholt und ausgeführt wurde? Wir wissen bereits, wo wir gerade waren." In diesem Zusammenhang bedeutet „genau", dass wir auf kein Fehlersignal oder Flag ansprechen, das zu bald auftritt, d. h. das durch etwas bewirkt wurde, was einige Zyklen vor der Instruktion, an der wir interessiert waren, geschah. Die Antwort ist, dass wir dies können.
Die Fehlersignale oder Flags, an denen wir interessiert sind, sind die folgenden: FERR 113 (es bedeutet, dass ein Funktions-Fehler bzw. -ERROR vorlag); PERR 114 (es bedeutet, dass ein Parameter-Fehler bzw. -ERROR vorlag); und (noch einmal) PD_ERROR 90. Die genaue Natur dessen, wie die ersten beiden dieser Signale erzeugt werden, befindet sich in der aufgenommenen MEMORY TESTER TESTS MULTIPLE DUT'S PER TEST SITE. Siehe 5 dieses Falls dafür, wie pro DUT Instanzen von Funktionsfehler- und Parameterfehlersignalen erzeugt werden. Dann siehe 6, um zu sehen, wie das System konfigurierbar ist, um YDFE (Yes DUT-Funktionsfehler) und YDPE (Yes DUT Parameterfehler) zu erzeugen, die eine Vielzahl möglicher Kombinationen unter den zugeordneten Komponente-pro-DUT-Signalen darstellen können. Für unsere Zwecke ist ihr YDFE gleich unserem FERR und ihr YDPE ist gleich unserem PERR.
FERR und PERR haben wahrscheinlich die gleiche Pipelineverzögerung, die ihrem Erscheinen zugeordnet ist, die für PD_ERROR jedoch ist ziemlich wahrscheinlich unterschiedlich. In jedem Fall würde das Pipelinetieferegister Nr. 2 84b zuvor auf den geeigneten Wert für FERR und PERR gesetzt werden, während das Pipelinetieferegister Nr. 1 84a zuvor auf den geeigneten Wert für PD_ERROR gesetzt würde.
Nun wird bei einem bestimmten Schritt in dem Testprogramm ein Stimulus durchgeführt, der zu einem der vorstehend erwähnten Signale führen kann. Bei diesem gleichen Schritt gibt das Testprogramm BEGIN_HIST 68 aus. Dies lädt den Abwärtszähler 100b mit der Pipelinetiefe, die dann durch weitere Schritte in dem Programm nach unten gezählt wird (aufeinander folgende Instanzen von PGM_STEP 83). Schließlich geht ZÄHLWERT Nr. 2 = NULL 115 auf WAHR, was, wie angemerkt wird, die Auswahlen bestimmt, die durch zwei MUX 110 und 111 durchgeführt werden. Ein MUX 109 wird durch das Signal ZÄHLWERT Nr. 1 = NULL 108 gesteuert.
Wir wollen nun FERR 113 und seinen MUX 111 als ein Beispiel nehmen; die anderen sind in ihrer Funktionsweise gleich. Solange ZÄHLWERT Nr. 2 = NULL FALSCH ist, wählt der MUX 111 als seine Ausgabe (ein Bit einer Drei-Bit-Sammlung 112, gesendet an den Nächste-Adresse-Berechner zum Verzweigen an demselben) ein Signal <NO_ERROR> bzw. <KEIN_FEHLER> 116, das der elektrische Wert ist, der durch das Testsystem in Abwesenheit eines Fehlers zugeordnet ist. Jedoch ist es, sobald die Pipelineverzögerung gelaufen ist, fair zu fragen, was das echte FERR 133i ist. Dies ist, was geschieht, da ZÄHLWERT Nr. 2 = NULL WAHR wird, was bewirkt, dass der MUX 111 nun FERR auswählt, um an den Nächste-Adresse-Berechner 102 gesendet zu werden.
Ein Verzweigen an PERR funktioniert so wie für FERR, jedoch stattdessen unter Verwendung des MUX 110. Dieser Stil von Verzweigung an PD_ERROR 90 funktioniert wie die anderen beiden, mit der Ausnahme, dass es die Verzögerung für das ALU-Historie-FIFO (Pipelinetieferegister Nr. 1 84a) teilt, jedoch seinen eigenen MUX 109 aufweist, der durch das Signal ZÄHLWERT NR. 1 = NULL 108 gesteuert wird, das durch den „gemeinschaftlich verwendeten" Abwärtszähler Nr. 1 100a getrieben wird.
Um sicher zu gehen, muss das Testprogramm in einer Weise geschrieben sein, die dies korrekt nutzt; eine Schleife mit fester, jedoch ausreichender Verzögerung z. B. Aber zumindest wird uns garantiert, dass die Entsprechung korrekt ist. Wir können sogar wesentlich später als nach Ablauf der Pipelineverzögerung testen, unter der Voraussetzung, dass wir sicherstellen, dass kein Eindringungsgrund hinein kommt und eigenständig unser Signal setzt.
Es gibt weitere Historie-FIFOs, die nützlich sind, und dies ist der Gegenstand des vereinfachten Blockdiagramms 117 in 4. Allgemein arbeiten diese in Weisen, die der Weise des ALU-Historie-FIFO 69 ähneln, mit der Ausnahme, dass sie in einem anderen Teil des Aufbaus des Speichertesters angeordnet sind, und dass sie Antworten auf Fragen speichern, die sich von denjenigen unterscheiden, die durch das ALU-Historie-FIFO gespeichert werden. Ein FIFO zum Aufzeichnen der aktuellsten Vergleichsfehlerdaten ist so angeordnet, dass es nur eine Ebene tief sein muss, und ist so einfach ein Register und kein voll ausgebildetes FIFO. Und es gibt ein FIFO aus zwei Abschnitten zum Wiedergewinnen einer Pufferspeicher-Historie, das gemeinsam mit einem weiteren FIFO mit zwei Abschnitten zum Wiedergewinnen der ECR-Historie gesteuert wird.
Unter Bezugnahme auf 4 ist der einfachste Ort, mit dem zu beginnen ist, der linke Abschnitt. Es wird angemerkt, dass ein Teil der Post-Decodieren-Schaltung 60 gezeigt ist, und dass gemäß dem, was in 2 dargestellt ist, diese 32 Bits an Vergleichsdaten 59 von der EMPFANGSVEKTOR-RÜCKABBILDER/DESERIALISIERER-SCHALTUNG (57) erhält. Wir haben dem eines hinzugefügt: die Übertragung dieser 32 Bits wird durch ein DATA_VALID-Signal 118 begleitet.
Von dem Post-Decodieren gehen 32 Bits (verarbeitete) Fehlerdaten und ein DELAYED_DATA_VALID 128 aus (ist insgesamt (61)), um an ECR2 32B gesendet zu werden (siehe 2). Es wird auch angemerkt, dass Post-Decodieren dort ist, wo PD_ERROR 90 herkommt, und es wird in Erinnerung gerufen, wie dies in 3 gemeinsam mit BEGIN_HIST 83 verwendet wird, um FREEZE_HIST 99 zu erzeugen.
Die Aufgabe des Einfangens der Fehlerdaten 61, die einen PD_ERROR bewirkt haben, ist relativ einfach. Normalerweise ist FREEZE_HIST 99 FALSCH und seine Inversion an dem Eingang des UND-Gatters 129 ermöglicht es, dass DELAY-ED_DATA_VALID 128 ein Signal 131 erzeugt, das mit dem LADEN-Steuereingang eines Letzte_Fehler_Daten-Registers 132 gekoppelt ist. Der Dateneingang in dieses Register ist exakt die 32 Bits an Fehlerdaten, die an ECR2 gesendet werden, und wird so jedes Mal erfasst, wenn derartige Daten gesendet werden. Ein PD_ERROR bewirkt FREEZE_HIST 99, was wiederum ein Signal 131 und mögliche weitere Beladungen an das Register 132 verhindert. Das Letzte Fehler Daten-Register 132 ist mit dem Ringbus 85 gekoppelt, so dass sein Inhalt untersucht werden kann.
Wir wollen nun die Historie-FIFOs betrachten, die einer Pufferspeicher-Verwendung zugeordnet sind. Es wird in Erinnerung gerufen, dass die Pufferspeicher 31a und 31b für verschiedene Zwecke verwendet werden können, wie z. B. Speichern des erwarteten Inhalts eines ROM, Umwandeln einer angelegten Sequenz von Adressen in eine andere Sequenz usw.
In jedem Fall wird nach Ladung ein Pufferspeicher durch den Adressabbilder 29 adressiert, der durch die X-, Y- und Z-Adresse 27 getrieben wird, die durch die ALU erzeugt werden. Wir haben zwei Pufferspeicher-Historie-FIFOs (124 und 125), eines für jeden Pufferspeicher. Es ist ihre Aufgabe, uns korrekten pipelineverzögerten Pufferspeicher-Inhalt zu liefern, der der Erzeugung von PD_ERROR 90 zugeordnet ist. Diese beiden FIFOs sind das Pufferspeicher Nr. 1-Historie-FIFO (124), das dem Pufferspeicher 31A zugeordnet ist, und das Pufferspeicher Nr. 2-Historie-FIFO (125), das dem Pufferspeicher 31B zugeordnet ist. Diese beiden Pufferspeicher-Historie-FIFOs haben jeweils die gleiche Tiefe (vier ist eine gute Zahl), werden gemeinsam gesteuert und sind mit dem Ringbus verbunden (entweder direkt oder über Zwischenregister, wie für die Verbindung des ALU-Historie-FIFO mit dem Ringbus erläutert wurde). Sie sind Teil eines größeren Historie-FIFO-Mechanismus 123, der auch die ECR-Historie-FIFOs 126 und 127 umfasst, die nach der Erläuterung für die Pufferspeicher-Historie-FIFOs erläutert werden.
Vor einem Fortfahren wollen wir einige weitere Voraussetzungen darlegen. Es wird auf die vier FIFOs 131 bis 136 verwiesen, sowie darauf, dass ihre Ausgänge 62A bis D in 2 sind. Diese Ausgänge sind mit der Post-Decodieren-Schaltung 60 gekoppelt, in Übereinstimmung mit 2, es soll jedoch zu erkennen sein, dass die Eingaben für die Pufferspeicher-FIFOs 133 und 134 auch als GESPEICHERTE DATEN (33) und GESPEICHERTE ADRESSEN (34) an einen Schaltungsaufbau (35 und 37) gesendet werden, der Teil der ALU-zu-DUT-(Sendevektor-)Pipeline ist (siehe 2). Die FIFOs 133 und 134 für die Pufferspeicher sind ziemlich tief, z. B. etwa 30; ihre tatsächliche verwendete Tiefe ist konfigurierbar und ist für uns nicht von wesentlichem Belang, mit Ausnahme davon, dass wir gut daran tun, zu erkennen, warum es sie gibt. Tatsächlich wären sie selbst dann vorhanden, wenn es keine Pufferspeicher-Historie-FIFOs gäbe. Der Grund hierfür entsteht aus der Weise, in der Pufferspeicher verwendet werden. Sie sind eine alternative Quelle dafür, was andernfalls aus der ALU käme, und eine Kopie ihres Inhalts (33, 34) wird die ALU-zu-DUT-Pipeline „herunter" gesendet. Eine weitere Kopie kann jedoch an Post-Decodieren gesendet werden. Es würde nicht reichen, wenn diese andere Kopie sehr früh dort hin gelänge (d. h. weit vor Vergleichsdaten 57, die von dem DUT „nach oben" zurückkommen), so dass die FIFOs 133 und 134 die erforderliche Verzögerung bereitstellen und dies derart tun, dass Dinge, die gleichzeitig ankommen, tatsächlich einander entsprechen. Aus diesem Grund besitzen sie Tiefen bis zu etwa 30.
Und nun zu den Pufferspeicher-Historie-FIFOS 124 und 125. Eine Anzahl ihrer Funktionsmerkmale sind die gleichen wie für das ALU-Historie-FIFO 69: sie werden durch das BEGIN_HIST-Signal 68 rückgesetzt; sie werden durch das Anlegen eines Signals (DATA_VALID 118), das bedeutet, dass ein neuer Wert vorhanden ist und in das FIFO gegeben werden muss, einem LADEN unterzogen (über die Ausgaben der FIFOs 133 bzw. 134), jedoch mit dem Nicht-VOLL-Zustand (Signal 121) einer UND-Operation unterzogen (UND-Gatter 119). Sie werden in einem Schritt mit einer verzögerten Version von DATA_VALID (DELAYED_DATA_VALID 182) einem ENTLADEN unterzogen. Die zeitliche Verzögerung zwischen den beiden Versionen von DATA_VALID ist im Wesentlichen die Zeit, die Post-Decodieren braucht, um zu entscheiden, ob ein Fehler vorlag. Wenn kein Fehler vorlag, möchten wir die FIFOs ENTLADEN, wir müssen jedoch warten, um dies herauszufinden.
Ein Unterschied bei FIFO-Merkmalen ist, dass das Ereignis (Auftreten von PD_ERROR 90), das die Absonderung der Daten in dem FIFO bewirkt (was der Grund dafür ist, weshalb wir dies überhaupt haben), im Wesentlichen gleichzeitig (nicht durch Pipelineverzögerungen getrennt) mit dem Laufen der Daten durch das FIFO ist. So brauchen wir nicht die Dienste eines Pipelinetieferegister, Abwärtszählers usw. Es ist ausreichend, mit einem ENTLADEN nach FREEZE_HIST 99 aufzu hören, was eigentlich nur PD_ERROR ist, qualifiziert mit dem Historie-Modus-Latch 105. Entsprechend wird dann ENTLADEN 122 durch ein UND-Gatter 130 erzeugt, dessen Eingaben DELAYED_DATA_VALID 182 und eine invertierte Instanz von FREEZE_HIST 99 sind.
Die Funktionsweise der ECR-Historie-FIFOs 126 und 127 ist im Bezug darauf, was die Steuersignale anbelangt, gleich. Der Schlüssel für ein Erkennen, warum die dargestellte Anordnung nützlich ist, ist in der Kenntnis darüber zu finden, wie die ECRs zu verwenden sind. Es wird angemerkt, dass es in 2 eine Umgehung 59 um Post-Decodieren 60 gibt, die es ermöglicht, dass tatsächliche Daten von einem Livetest an einem DUT geradewegs in einen ECR gehen. Zu einer späteren Zeit können die in dem ECR gespeicherten Daten zurückgelesen und zur Durchführung verschiedener Analysen an Post-Decodieren angelegt werden. Nun stellen wir die Frage „Welche Daten, die in Post-Decodieren gehen, haben PD_ERROR bewirkt?" Das ist es, was die ECR-Historie-FIFOs beantworten können. Die FIFOs 135 und 136 können für diesen Prozess flach sein, da er „lokal" ist und ein Großteil des Rests der großen Pipelines nicht betroffen ist.

Claims

Ein Verfahren zum Bewahren des Werts eines Parameters, der einem Testen eines zu testenden Bauelements (DUT) zugeordnet ist, das folgende Schritte umfasst: (a) Ausführen eines Testprogramms, das bewirkt, dass Stimulussignalwerte (27, 28) durch eine Stimulus-Pipeline (35, 40, 45, 52) mit einer ersten Anzahl von Stufen zu einem DUT befördert werden, in einer Programmausführungsumgebung (19, 24); (b) Senden von Antwortsignalwerten, die durch ein Betreiben des DUT mit den beförderten Stimulussignalwerten erhalten werden, von dem DUT an die Programmausführungsumgebung und durch eine Antwort-Pipeline (52, 57, 60, 87) mit einer zweiten Anzahl von Stufen; (c) für jeden Ausführungszyklus des Testprogramms und von einem ausgewählten Ort in einer der Stimulus- und der Antwort-Pipeline, Speichern des Werts des Parameters, der wiedergewonnen werden soll, in einem Historie-FIFO-Puffer (91-98, 124-127); (d) Erzeugen eines Fehlersignals (90) innerhalb der Antwort-Pipeline, einschließlich an dem DUT, ansprechend auf eine ausgewählte Fehlerbedingung; (e) Einstellen (84) der Tiefe des Historie-FIFO-Puffers, um der Anzahl von Pipeline-Stufen zu entsprechen, die das Speichern in Schritt (c) und die Erzeugung einer zugeordneten Instanz des Fehlersignals in Schritt (d) trennen; und (f) ansprechend auf ein Fehlersignal, das durch Schritt (d) erzeugt wird, Bewahren (99) des Parameterwerts, der an der Tiefe, die bei Schritt (e) eingestellt wird, gespeichert ist, in dem Historie-FIFO-Puffer.
Ein Verfahren gemäß Anspruch 1, das folgenden Schritt umfasst: (g) nach Schritt (f), Wiedergewinnen des Werts des Parameters, der in dem Historie-FIFO-Puffer bewahrt wird.
Ein Verfahren gemäß Anspruch 2, bei dem der Schritt (a) die Erzeugung einer Pufferspeicheradresse (30) umfasst, und bei dem der Parameter der Schritte (c), (f) und (g) die Pufferspeicheradresse ist.
Ein verfahren gemäß Anspruch 2, bei dem der Parameter der Schritte (c), (f) und (g) Antwortsignalwerte (7, 56, 59) ist, die fehlerhaft sind.
Ein Verfahren zum Bewahren einer Fehleranzeige, die in einem Fehlerfang-RAM (ECR) gespeichert ist, während eines Testens eines zu testenden Bauelements (DUT), das die folgenden Schritte umfasst: (a) Ausführen eines Testprogramms, das bewirkt, dass Stimulussignalwerte (27, 28) durch eine Stimulus-Pipeline (35, 40, 45, 52) mit einer ersten Anzahl von Stufen zu einem DUT befördert werden, in einer Programmausführungsumgebung (19, 24); (b) Senden von Antwortsignalwerten, die durch ein Betreiben des DUT mit den beförderten Stimulussignalwerten erhalten werden, von dem DUT an die Programmausführungsumgebung und durch eine Ant wort-Pipeline (52, 57, 60, 87/32) mit einer zweiten Anzahl von Stufen; (c) nach Schritt (b), Speichern der Antwortsignalwerte in einem Zwischenspeicher (32A), der entlang der Antwort-Pipeline angeordnet ist; (d) nach den Schritten (a), (b) und (c), Lesen gespeicherter Antwortsignalwerte (62A-D) von Orten in dem Zwischenspeicher und Anlegen derselben an eine Nach-Decodieren-Schaltung (60), die Fehleranzeigen ausgewählter Typen von Fehlern erzeugt; (e) Speichern der Fehleranzeigen (61), die durch die Nach-Decodieren-Schaltung erzeugt werden, in einem ECR (32B); (f) Speichern der Fehleranzeigen, die in Schritt (e) gespeichert werden, in einem ECR-Historie-FIFO-Puffer (126, 127); (g) Erzeugen eines Fehlersignals (90) innerhalb der Nach-Decodieren-Schaltung ansprechend auf eine ausgewählte Fehlerbedingung in den gespeicherten Antwortsignalwerten, die in Schritt (d) gelesen und an die Nach-Decodieren-Schaltung angelegt werden; (h) Einstellen der Tiefe des ECR-Historie-FIFO-Puffers, um der Anzahl von Pipelinestufen zu entsprechen, die das Speichern in Schritt (f) und die Erzeugung einer zugeordneten Instanz des Fehlersignals, das in Schritt (g) erzeugt wird, trennen; und (i) ansprechend auf ein Fehlersignal, das durch Schritt (g) erzeugt wird, Bewahren (99) der Feh leranzeige, die bei der Tiefe, die bei Schritt (h) eingestellt wird, gespeichert ist, in dem ECR-Historie-FIFO-Puffer.
Ein Verfahren gemäß Anspruch 5, das folgenden Schritt umfasst: (j) nach Schritt (i), Wiedergewinnen des Werts der Fehleranzeige, die in dem ECR-Historie-FIFO-Puffer bewahrt wird.
Ein Verfahren zum Wiederherstellen von Algorithmussteuervariablen (71-78) eines Testprogramms, die sich auf das Testen eines zu testenden Bauelements (DUT) beziehen, das folgende Schritte umfasst: (a) Ausführen eines Testprogramms, das bewirkt, dass Stimulussignalwerte (27, 28), die gemäß den Algorithmussteuervariablen des Testprogramms bestimmt werden, durch eine Stimulus-Pipeline (35, 40, 45, 52) mit einer ersten Anzahl von Stufen zu einem DUT befördert werden, in einer Programmausführungsumgebung (19, 24); (b) Senden von Antwortsignalwerten, die durch ein Betreiben des DUT mit den beförderten Stimulussignalwerten erhalten werden, von dem DUT an die Programmausführungsumgebung und durch eine Antwort-Pipeline (52, 57, 60, 87) mit einer zweiten Anzahl von Stufen; (c) für jeden Ausführungszyklus des Testprogramms, Speichern der Werte der Algorithmussteuervariablen des Testprogramms, die wiederhergestellt werden sollen, in einem Historie-FIFO-Puffer (91-98); (d) Erzeugen eines Fehlersignals (90) innerhalb der Antwort-Pipeline, einschließlich an dem DUT, ansprechend auf eine ausgewählte Fehlerbedingung; (e) Einstellen (84) der Tiefe des Historie-FIFO-Puffers, um der Anzahl von Pipeline-Stufen zu entsprechen, die die Ausführung eines Schritts in dem Testprogramm und die Erzeugung einer zugeordneten Instanz des Fehlersignals in Schritt (d) trennen; (f) ansprechend auf ein Fehlersignal, das durch Schritt (d) erzeugt wird, Bewahren (99) der Algorithmussteuervariablen, die an der Tiefe, die bei Schritt (e) eingestellt wird, gespeichert sind, in dem Historie-FIFO-Puffer; (g) nach Schritt (f), Wiederherstellen der Werte der Algorithmussteuervariablen, um diejenigen zu sein, die in dem Historie-FIFO-Puffer bewahrt werden; und (h) Ausführen eines Schritts in dem Testprogramm, der einen Testprogrammfluss verändert, ansprechend auf das Vorliegen des Fehlersignals, das in Schritt (d) erzeugt wird.
Ein Verfahren gemäß Anspruch 7, das folgende Schritte umfasst: an einem ausgewählten Ort in dem Testprogramm, das in Schritt (a) ausgeführt wird, Setzen eines Pipeline-Verzögerungszählwerts (84), um der Anzahl von Pipelinestufen zu entsprechen, die die Ausführung dieses Schritts in dem Testprogramm und eine nachfolgende Erzeugung eines zugeordneten Fehlersignals trennen; für jeden Ausführungszyklus (83) des Testprogramms nach dem Setzen eines Verzögerungszählwerts (84) und für einen Nicht-Null-Wert des Pipeline-Verzögerungszählwerts, Dekrementieren des Werts des Pipeline-Verzögerungszählwerts um Eins; Erzeugen eines Ersatzqualifizierersignals (112), dessen Wert die Bedeutung „KEIN FEHLER" (116) aufweist, solange der dekrementierte Wert des Pipeline-Verzögerungszählwerts ungleich Null ist, und dessen Wert den tatsächlichen Wert des Fehlersignals aufweist, das erzeugt wird, wenn (115, 108) der dekrementierte Wert des Pipeline-Verzögerungszählwerts null ist; Ausführen (112) eines Schritts in dem Testprogramm, der einen Testprogrammfluss verändert, ansprechend auf den Wert des Ersatzqualifizierersignals.