DE112020007444T5

DE112020007444T5 - Automatische Testeinrichtung, Prozess und Computerprogramm zum Testen eines oder mehrerer zu testender Geräte, wobei unterschiedliche Testaktivitäten Teilsätze von Ressourcen des zu testenden Geräts nutzen

Info

Publication number: DE112020007444T5
Application number: DE112020007444.7T
Authority: DE
Inventors: Jochen Rivoir
Original assignee: Advantest Corp
Current assignee: Advantest Corp
Priority date: 2020-07-21
Filing date: 2020-07-21
Publication date: 2023-06-15
Also published as: KR20230038407A; CN114631031A; TWI781634B; US20220253375A1; TW202206835A; WO2022017589A1; JP7504283B2; JP2023534966A

Abstract

Ein Ausführungsbeispiel gemäß der vorliegenden Erfindung weist eine automatische Testeinrichtung zum Testen eines oder mehrerer zu testender Geräte auf. Die automatische Testeinrichtung ist dazu konfiguriert, automatisch auf dynamische Weise ein oder mehrere Testszenarien, vorzugsweise eine Mehrzahl von Testszenarien, zu erzeugen, die eine Mehrzahl von Testaktivitäten aufweisen. Unterschiedliche Testaktivitäten nutzen Teilsätze, die überlappen können, von Ressourcen der zu testenden Geräte. Die automatische Testeinrichtung ist dazu konfiguriert, eine Mehrzahl von Testszenarien zu erzeugen, so dass Ressourcen der zu testenden Geräte, die einer Mehrzahl von Testaktivitäten eines Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen.

Description

Technisches Gebiet
Ausführungsbeispiele gemäß der Erfindung beziehen sich auf eine automatische Testeinrichtung. Weitere Ausführungsbeispiele gemäß der Erfindung beziehen sich auf Tests auf Systemebene. Weitere Ausführungsbeispiele gemäß der Erfindung beziehen sich auf Auf-Chip-Systemtests. Ausführungsbeispiele gemäß der Erfindung beziehen sich auf Abdeckung von Tests.
Hintergrund der Erfindung
Es ist eine empirische Beobachtung oder Wahrheit, dass einige Geräte Tests auf Systemebene (SLT, System Level Tests) nicht bestehen, obwohl sie strukturelle und/oder parametrische Tests bestehen. Dies wird für gewöhnlich unrealistischen Testbedingungen während der strukturellen Tests zugeschrieben.
Im Vergleich zu Tests auf Systemebene unterscheidet sich ein Aktivitätsmuster über die Halbleiterchipfläche während struktureller Tests beispielsweise stark. Strukturelle Tests verbringen die meiste Zeit mit Verschiebungsoperationen, wobei die Frequenz sehr gering ist, die Musteraktivität jedoch sehr hoch ist. Dies führt zu einer unnatürlichen Belastung von Leistungsversorgungen und daher zu unrealistischen Spannungsprofilen gegenüber von Position auf dem Halbleiterchip und Zeit.
Ein weiteres Beispiel besteht darin, dass die Leistungsbereichsübergänge und/oder Taktbereichsübergänge aufgrund von Schwierigkeiten in der Erzeugung von Mustern für automatische Tests oft nicht in strukturellen Tests enthalten sind. Fehler in diesem Bereich werden weder erfassbar gemacht (bzw. sensibilisiert) noch detektiert.
Strukturelle Tests leiden unter unrealistischen Testbedingungen, sie sind für ausgezeichnete Fehlerdetektionsfähigkeiten optimiert. Im Gegensatz dazu besteht SLT ausschließlich aus echten Nutzerszenarien. Ohne ein Fehlermodell zu kennen, besteht Übereinstimmung oder allgemeiner Glaube dahingehend, dass ein durchgefallener SLT ein wirklich schlechtes Gerät identifiziert.
Tests auf Systemebene haben bestimmte Nachteile, etwa dass ein SLT keineswegs vollständig ist, da ein zu testendes Gerät (DUT, Device Under Test) lediglich einen kleinen Teilsatz von möglichen Nutzungen und Szenarien lediglich in einer ausgewählten Umgebung durchspielt, etwa Versorgungsspannungen, Frequenzen und Temperatur.
Ein weiterer Nachteil besteht darin, dass es schwierig ist, SLT-Fehler zu korrigieren, da die Zeit zwischen der Fehlsensibilisierung (bzw. fault sensitization) und -detektion extrem lang sein kann und/oder eine genaue Reihenfolge aller Aktivitäten unbekannt ist und/oder eine Simulationszeit für SLT viel zu lang sein würde.
Ferner weisen SLTs sehr lange Laufzeiten auf, zehn Minuten oder mehr sind keine Ausnahme.
Außerdem ist es schwierig, SLTs in Prüflaboren einzusetzen, da für jedes DUT eine große Anzahl von Systemplatinen unterhalten werden muss.
Es besteht ein Bedarf für eine Verbesserung des Tests auf Systemebene, welche einen besseren Kompromiss zwischen möglichen Nutzerszenarien, Dauer von Laufzeiten und Durchführbarkeit bereitstellt.
Kurzdarstellung der Erfindung
Ein Ausführungsbeispiel gemäß der vorliegenden Erfindung weist eine automatische Testeinrichtung zum Testen eines oder mehrerer zu testender Geräte (DUT, Device Under Test) auf, z. B. ein System-Auf-Chip (SOC, System On A Chip, bzw. Ein-Chip-System). Die automatische Testeinrichtung (ATE, Automated Test Equipment) ist dazu konfiguriert, automatisch auf dynamische Weise ein oder mehrere Testszenarien, vorzugsweise eine Mehrzahl von Testszenarien, zu erzeugen, die eine Mehrzahl von Testaktivitäten aufweisen. Unterschiedliche Testaktivitäten, z. B. A1, A2, A3, nutzen Teilsätze der DUT-Ressourcen, die überlappen können, z. B. A1: CPU2, Mem3, A2: Mem3, A3: MPEG. Die automatische Testeinrichtung ist dazu konfiguriert, eine Mehrzahl von Testszenarien zu erzeugen, so dass Ressourcen des DUT, die einer Mehrzahl von Testaktivitäten eines Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen.
Es kann erwartet werden, dass ein Auf-Chip-Systemtest (OCST, On-Chip System Test) mehr relevante Probleme als ein SLT findet, da er das DUT einer größeren Vielzahl von echten Testbedingungen aussetzt, als es der SLT tut. Ein Problem kann als relevant angesehen werden, wenn es während einer Kombination von Testaktivitäten auftritt, welche einen echten Anwendungsfall simulieren oder Teil davon sein können.
OCST kann externe Testbedingungen variieren, etwa Versorgungsspannungen und Frequenzen, um Fehler erfassbar zu machen, und/oder interne Testbedingungen variieren, etwa die Intensität von Testaktivitäten, z. B. Geschwindigkeit von Datenbewegungen, um arbeitsbelastungsbezogene Fehler erfassbar zu machen. Sobald ein Fehler erfassbar gemacht ist, bietet OCST eine gute Beobachtbarkeit, um ein fehlerhaftes Verhalten zu detektieren.
Ein OCST kann seine Effektivität unter Beweis stellen, indem er zeigt, welchen Teilsatz von SLT-Fehlschlägen er finden kann. Mit anderen Worten kann der OCST dazu in der Lage sein, den fehlgeschlagenen Teilsatz des SLT zu finden.
Idealerweise können OCST-Tests in einer Simulationsumgebung reproduziert werden, beispielsweise zur Fehlerkorrektur. OCST sollte auch bestehende Auf-Chip-Ressourcen ausnutzen, etwa testgerechter Entwurf (DFT, Design For Test), Entwurf zur Fehlerkorrektur (DFD, Design For Debug), Scanketten, in Logik eingebaute Selbsttests (LBIST, Logic Built-In Self-Tests) und/oder in Speicher eingebaute Selbsttests (MBIST, Memory Built-In Self-Tests). Außerdem kann der Mehrwegbetrieb (bzw. multi-threading) an Schnittstellen zwischen Mehrkern-DUT-Ressourcen und mehreren ATE-Ressourcen unterstützt werden.
Bei einem bevorzugten Ausführungsbeispiel ist die Mehrzahl von Testaktivitäten eines gegebenen Testszenarios dazu konfiguriert, gleichzeitig ausgeführt zu werden.
Die ATE ist dazu konfiguriert, Testszenarien zu erzeugen, in denen die Testaktivitäten nichtüberlappende DUT-Ressourcen nutzen, so dass Testaktivitäten eines Testszenarios nicht miteinander in Konflikt stehen. Das heißt, das Testen kann beschleunigt werden, indem die Testaktivitäten eines gegebenen Testszenarios gleichzeitig ausgeführt werden.
Eine allgemeine Idee der Erfindung besteht darin, eine große Anzahl von einfachen, realistischen, selbstprüfenden Testaktivitäten auf DUTs unter Verwendung von DUT-Ressourcen wie etwa Datenblockbewegungen oder eingebauten Selbsttests in einer variierenden Kombination von Testaktivitätsintensität und -gleichzeitigkeit durchzuführen. Jede Testaktivität kann ausgewählte oder beteiligte IP-Blöcke prüfen, trägt durch eine Belastung von Versorgungen, Taktbäumen und thermischer Kopplung jedoch auch zu den Testbedingungen anderer Blöcke bei.
Gemäß einem Ausführungsbeispiel sind eine oder mehrere Testaktivitäten zu einem oder mehreren Testparametern zugeordnet, etwa Spannung, Geschwindigkeit, Größe von Datentransfers, Zeiten zwischen Datentransfers, Blockgröße, in die der Gesamtdatentransfer unterteilt wird, usw. Testparameter steuern das Verhalten von Testaktivitäten. Die Testparameter sind durch jeweilige Parameterwerte gekennzeichnet, etwa Ein/Aus, 5 V, 50 GB/s, usw., und/oder sind einer oder mehreren Einschränkungen oder Begrenzungen zugeordnet, z. B. zur dynamischen Erzeugung von Testparameterwerten.
Dieselben Testaktivitäten mit unterschiedlichen Parameterwerten können in einer Testsequenz ausgeführt werden, die ein oder mehrere Testszenarien aufweist. Testaktivitäten können mehr als einem Testparameter und/oder einer Einschränkung zugeordnet sein. Beispielsweise kann sich ein Testparameterwert, welcher ein Wert eines Testparameters ist, etwa eine Spannung, von Testaktivität zu Testaktivität unterscheiden. Testaktivitäten können auch einige Einschränkungen oder Begrenzungen aufweisen, beispielsweise um das DUT oder die DUT-Ressourcen zu schützen, oder um Szenarien zu vermeiden, die bei echter Nutzung nicht auftreten werden. Solch eine Einschränkung kann eine begrenzte Schreibgeschwindigkeit, eine Temperaturgrenze, eine begrenzte Nutzung von Speicher, usw. sein.
Gemäß einem Ausführungsbeispiel sind eine oder mehrere der Testaktivitäten durch einen oder mehrere Testparameterwerte außerhalb vordefinierter Begrenzungen oder außerhalb einer Chip-Spezifikation gekennzeichnet, etwa zu geringe Spannungswerte und/oder zu schnelle Frequenzen.
Ergebnisse des Testens von DUTs außerhalb oder leicht außerhalb der vordefinierten Begrenzungen oder Chip-Spezifikationen können mit der Leistung der DUTs in den vordefinierten Begrenzungen oder Chip-Spezifikationen korrelieren. Das heißt, DUTs mit guten Testergebnissen außerhalb der Chip-Spezifikationen können auf eine gute Leistung der DUTs in den Chip-Spezifikationen hindeuten. Im Gegensatz dazu ist ein Fehlschlagen des Tests außerhalb der Chip-Spezifikation nicht als unumstößlicher Hinweis oder Beweis eines fehlgeschlagenen Tests in der Chip-Spezifikation zu betrachten, deutet jedoch auf eine Schwäche hin.
Gemäß einem Ausführungsbeispiel wird die Mehrzahl der Testaktivitäten eines gegebenen Testszenarios zufällig ausgewählt, unter den Einschränkungen, dass Ressourcen des zu testenden Geräts, die der Mehrzahl von Testaktivitäten des gegebenen Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen, um in Konflikt stehende Anforderungen in Bezug auf die Nutzung oder Testparameterwerte aus unterschiedlichen Testaktivitäten zu vermeiden.
Eine zufällige Mischung von Testaktivitäten in einem Testszenario ist erforderlich zum Testen unbekannter Interaktionen zwischen Aktivitäten oder Testaktivitäten, die in einer echten Arbeitsumgebung auftreten. Einer Randomisierung von parametrisierbaren Testaktivitäten deckt viele Kombinationen lokaler Arbeitslasten ab und stellt somit eine große Anzahl von realistischen Arbeitslastmustern nach, die als für viele Systemebene-Fehlschläge verantwortlich angesehen werden.
Bei einem bevorzugten Ausführungsbeispiel weist die automatische Testeinrichtung einen Einschränkungslöser zum Erzeugen von Testszenarien auf, um ein Auftreten von Konflikten zwischen den Ressourcen des zu testenden Geräts zu verhindern.
Jede Testaktivität kann Testparameter und optionale Einschränkungen aufweisen. Beispielsweise kann eine Testaktivität des Schreibens und Zurücklesens eines Datenblocks die Testparameter anfängliche Zeitverzögerung, Blockgröße, Startadresse, Teilblockgröße, Zeitverzögerung vor dem Zurücklesen aufweisen. Einschränkungen können auch auf der Testszenarioebene vorhanden sein, welche Testparameter aus mehreren Testaktivitäten beinhalten.
Eine Arbeitsstation oder eine Steuerung, etwa eine Auf-Chip-OCST-Steuerung oder eine OCST-Karte, kann einen Einschränkungslöser verwenden, um Testszenarien automatisch aus Testaktivitäten zu erzeugen. Der Einschränkungslöser stimmt Testaktivitäten miteinander ab, die gleichzeitig koexistieren können, ohne gegen Ressourceneinschränkungen zu verstoßen.
Bei einem bevorzugten Ausführungsbeispiel weisen eine oder mehrere der Testaktivitäten ein Aktivieren eines Belastungsgenerators auf, der auf dem zu testenden Gerät angeordnet ist, z. B. ein Auf-Chip-Belastungsgenerator, etwa ein Datenverkehrsgenerator zu internen und/oder externen Bussen.
Beispielsweise kann eine bestehende oder neue Testgerechter-Entwurf-(DFT, Design For Test)-Struktur eine kontrollierte Belastung erzeugen und eine Beobachtbarkeit erhöhen, um die Wahrscheinlichkeit einer Detektion (oder zur wahrscheinlicheren Detektion eines Fehlschlages) zu erhöhen. Der Belastungsgenerator kann einen Datenverkehrsgenerator zu internen Bussen und/oder einen Datenverkehrsgenerator zu externen Eingängen aufweisen, um Datenverkehr von fehlenden externen Geräten nachzuahmen. Der Belastungsgenerator ermöglicht es, eingebaute Selbsttests (BIST, Built-In Self-Tests) auszuführen, etwa in Speicher oder Logik eingebaute Selbsttests (MBIST, Memory Built-In Self-Tests - LBIST, Logic Built-In Self-Tests) in ausgewählten umhüllten IP-Blöcken. Ferner kann der Belastungsgenerator Eingang/Ausgang-(I/O, Input/Output)-Rückschautests ausführen. Außerdem kann der Belastungsgenerator IP-Blöcke unter Verwendung eines Umhüllers (bzw. Wrappers) isolieren, z. B. ein IEEE 1500 Wrapper, und seine Scanketten in ein lineares rückgekoppeltes Schieberegister (LFSR, Linear-Feedback Shift Register) umschalten.
Gemäß einem Ausführungsbeispiel ist die automatische Testeinrichtung dazu konfiguriert, eine Testsequenz zu erzeugen, z. B. eine Sequenz von Testschritten von Testszenarien.
Eine Testsequenz von Testszenarien wird erzeugt, um unterschiedliche Mischungen von gleichzeitigen Testaktivitäten zu testen, um mögliche realistische Arbeitslastkombinationen nachzuahmen.
Gemäß einem Ausführungsbeispiel weist die Testsequenz zwei oder mehr Testszenarien mit denselben Testaktivitäten auf, wobei sich die Testszenarien um zumindest einen Testparameterwert unterscheiden.
Testsequenzen können Testszenarien mit denselben Testaktivitäten mit unterschiedlichen Testparameterwerten aufweisen, um die Wirkung der Testparameter auf das Testergebnis zu testen. Das Ändern lediglich eines Testparameterwerts eines IP-Blocks des DUT kann auch einen anderen IP-Block des DUT beeinflussen oder sich auf diesen auswirken.
Ferner kann das Ausführen von Testszenarien mit denselben Testaktivitäten und unterschiedlichen Testparameterwerten dabei helfen, einen fehlerhaften IP-Block in dem Testauswertungsprozess zu lokalisieren.
Bei einem bevorzugten Ausführungsbeispiel wird die Mehrzahl der Szenarien der Testsequenzen zufällig ausgewählt und/oder geordnet, um realistische Arbeitslastmuster nachzuahmen, z. B. durch die automatische Testeinrichtung oder durch eine Steuerung.
Eine Randomisierung der Testszenarien der Testsequenzen verbessert den Testprozess weiter, indem eine realistische Arbeitslast geschaffen oder erzeugt wird. Idealerweise sind die Testszenarien unabhängig voneinander, das heißt, es wird nicht erwartet, dass eine Änderung der Reihenfolge der Ausführung der Testszenarien das Verhalten des DUT ändert. Eine Randomisierung der Reihenfolge der Ausführung dieses Szenarios kann beispielsweise testen, ob Restwärme oder Restdaten aus vorherigen Testszenarien das aktuelle Testszenario beeinflussen können.
Bei einem bevorzugten Ausführungsbeispiel ist die automatische Testeinrichtung dazu konfiguriert, die Testsequenz so zu erzeugen, dass die Testsequenz dazu konfiguriert ist, durch eine Steuerung ausgeführt zu werden, um Testdaten zu sammeln.
Die erzeugten Testsequenzen werden durch die Steuerung oder die OCST-Steuerung ausgeführt. Die Aufgabe der Steuerung besteht darin, eine Ausführung von mehreren Testaktivitäten auszulösen und die Testergebnisse auszulesen, etwa Bestehen/Fehlschlag-Ergebnisse und/oder Messergebnisse. Die Steuerung weiß, welches Testszenario mit welchen Testparameterwerten ausgeführt wird. Dies ist notwendig zur Fehlerkorrektur, wenn ein Fehler auftritt.
Gemäß einem Ausführungsbeispiel ist die Steuerung ein Auf-Chip-Prozessor, z. B. zusammen mit einem Betriebssystem, oder eine Steuerungskarte, z. B. als Teil der automatischen Testeinrichtung, dazu konfiguriert, mit der automatischen Testeinrichtung und mit dem zu testenden Gerät zu kommunizieren.
Die Steuerung führt die Testsequenzen auf DUTs aus und stellt Messdaten oder Messergebnisse an die ATE bereit. Der Auf-Chip-Prozessor mit dem Betriebssystem oder die Steuerungskarte in der ATE kommuniziert die Messwerte oder Testergebnisse oder gesammelten Daten von dem DUT zu der ATE.
Bei einem bevorzugten Ausführungsbeispiel weist die Steuerung eine oder mehrere Schnittstellen auf, die dazu konfiguriert sind, DUT-Daten auszulesen, etwa Speicherdaten und/oder Sensordaten des zu testenden Geräts, z. B. Auf-Chip-Sensordaten. Demgemäß ist die ATE dazu konfiguriert, die Steuerung dahingehend einzustellen, DUT-Daten und/oder DUT-Sensordaten auszulesen.
Das Auslesen von DUT-Testdaten und/oder DUT-Sensordaten über eine Schnittstelle verbessert die Tests weiter, indem es ermöglicht, die Ergebnisdaten und/oder Ergebnissensordaten mit den erwarteten Ergebnisdaten oder erwarteten Sensordaten zu vergleichen. Die Steuerung, die OCST-Steuerung ist vorzugsweise ein Auf-Chip-Prozessor zusammen mit einem optionalen Testbetriebssystem, welcher mit Auf-Chip-IJTAG gekoppelt ist, um Auf-Chip-Sensordaten auszulesen.
Gemäß einem Ausführungsbeispiel ist die Steuerung mit einem oder mehreren Sensoren gekoppelt, die über die Fläche des zu testenden Geräts verteilt sind, so dass die Steuerung dazu konfiguriert ist, Sensortestdaten des einen oder der mehreren Sensoren auszulesen. Demgemäß ist die automatische Testeinrichtung dazu konfiguriert, die Steuerung dahingehend einzustellen, Sensortestdaten des einen oder der mehreren Sensoren auslesen, die über die Fläche des zu testenden Geräts verteilt sind, welche von der Steuerung einbezogen wird.
Egal ob die Steuerung ein Auf-Chip-Prozessor oder eine OCST-Steuerkarte ist, die mit dem DUT oder der ATE-Arbeitsstation kommuniziert, die Steuerung kann zusätzliche Sensoren aufweisen, die über die Halbleiterchipfläche des DUT verteilt sind, um lokale Anomalitäten zu detektieren. Eingesetzte Sensoren können beispielsweise Temperatur-, Strom- und/oder Spannungssensoren beinhalten.
Bei einem bevorzugten Ausführungsbeispiel ist die Steuerung dazu konfiguriert, zu reagieren, beispielsweise zusätzliche Daten zu sammeln, etwa gespeicherte Systemdaten, Programmzähler- oder Speicherregisterinformationen, falls die gesammelten Testdaten eine vorbestimmte Bedingung erfüllen, etwa eine oder mehrere vordefinierte Schwellen überschreiten. Demgemäß ist die automatische Testeinrichtung dazu konfiguriert, die Steuerung dahingehend einzustellen, zu reagieren, falls die gesammelten Testdaten vorbestimmte Bedingungen erfüllen.
Beispielsweise kann eine Steuerung mit einem oder mehreren Sensoren mit optionalen geschwellten Alarmfähigkeiten für einen Temperaturwert, etwa eine aktuelle/maximale/minimale Spitzentemperatur, für einen Spannungswert, etwa eine aktuelle/maximale/minimale Spitzenspannung, und/oder Zeitsteuerungsverletzungen, beispielsweise in Razor-Schaltungen, gekoppelt sein. Die Alarmfähigkeiten können beispielsweise eine Speicherung von wichtigen Systemdaten, etwa Programmzählern, Speichersteuerungsregistern, auslösen, um die Fehlerkorrektur zu vereinfachen.
Gemäß einem Ausführungsbeispiel ist die Steuerung dazu konfiguriert, die gesammelten Testdaten an die automatische Testeinrichtung zu kommunizieren.
Egal ob es Testergebnisdaten oder gemessene Daten oder irgendwelche gesammelten Daten sind, die durch gemessene Daten oder Testergebnisdaten ausgelöst werden, die gesammelten Testdaten werden durch die Steuerung an die ATE bereitgestellt.
Gemäß einem Ausführungsbeispiel ist die Steuerung oder die automatische Testeinrichtung dazu konfiguriert, Testparameterwerte auf Basis der Testaktivitätsbeschränkungen und/oder auf Basis von gesammelten Testdaten zu erzeugen.
Die gesammelten Testdaten können während des Testprozesses durch die ATE oder die Steuerung analysiert werden, um bestehende Testparameterwerte zu modifizieren oder ein oder mehrere Testszenarien zu der Testsequenz mit neuen Testparameterwerten hinzuzufügen. Die Erzeugung neuer Testparameterwerte kann die Einschränkungen der gegebenen Testaktivitäten berücksichtigen.
Bei einem bevorzugten Ausführungsbeispiel ist die Steuerung oder die automatische Testeinrichtung dazu konfiguriert, die gesammelten Testdaten zu analysieren, um Testsequenzen zu optimieren, beispielsweise um das Mindestmengenüberdeckungsproblem zu lösen, Redundanzen zu reduzieren und/oder niemals fehlschlagende Testaktivitäten.
Die gesammelten Testdaten werden nicht nur dazu verwendet, auf dynamische Weise Testparameterwerte zu erzeugen, sondern auch Testsequenzen zu optimieren. Eine allgemeine Idee des Testens besteht darin, diejenigen Testparameter zu identifizieren, die das Auftreten von Testfehlschlägen beeinflussen. Redundante Testaktivitäten können dabei helfen, die Wirkung beispielsweise von einzelnen oder kleinen Gruppen von Testparametern auszuwerten. Nach dem Identifizieren der am stärksten beeinflussten Testaktivitäten und/oder Testszenarien kann die Anzahl von Testszenarien oder Testaktivitäten in den Testszenarien auf einen Mindestsatz von Testaktivitäten reduziert werden, um die Laufzeit der Testsequenz zu reduzieren.
Gemäß einem Ausführungsbeispiel ist die Steuerung der automatischen Testeinrichtung dazu konfiguriert, die Korrelationen von Ergebnissen von Tests auf Systemebene in der vordefinierten Begrenzung mit den gesammelten Testdaten, z. B. Daten des zu testenden Geräts, Sensordaten des zu testenden Geräts, Sensortestdaten, in oder außerhalb der vordefinierten Begrenzung zu vergleichen oder zu berechnen, um die Testzeit zu optimieren.
Tests werden außerhalb der vordefinierten Begrenzungen oder Spezifikation des DUT ausgeführt und mit den Tests auf Systemebene in den vordefinierten Begrenzungen verglichen. Testaktivitäten mit positiven Testergebnissen außerhalb der vordefinierten Begrenzungen können darauf hindeuten, dass ein Test auf Systemebene in der vordefinierten Begrenzung bestanden wird. Der Vergleich der Testergebnisse in den vordefinierten Begrenzungen mit Testergebnissen außerhalb der vordefinierten Begrenzungen kann dabei helfen, die Anzahl von Testszenarien und/oder Testaktivitäten in den Testszenarien zu reduzieren. Es kann auch dabei helfen, zu identifizieren oder zu entscheiden, in welchem Ausmaß Testparameterwerte außerhalb der vordefinierten Begrenzung liegen können, um eine gute Korrelation zwischen Tests bereitzustellen, die innerhalb und außerhalb der vordefinierten Begrenzungen ausgeführt werden.
Bei einem bevorzugten Ausführungsbeispiel weist die automatische Testeinrichtung eine Künstliche-Intelligenz-Einheit oder eine Maschinelles-Lernen-Einheit auf, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, die Künstliche-Intelligenz-Einheit oder die Maschinelles-Lernen-Einheit mit Ergebnissen von Tests auf Systemebene und/oder mit den gesammelten Testdaten und/oder mit dem Vergleich der Tests auf Systemebene und der gesammelten Testdaten zu trainieren, um Testsequenzen zu optimieren.
Ferner ist bei einem bevorzugten Ausführungsbeispiel die trainierte Künstliche-Intelligenz-Einheit oder Maschinelles-Lernen-Einheit dazu konfiguriert, die Ergebnisse von Tests auf Systemebene auf der Basis der gesammelten Testdaten vorauszusagen.
Die Künstliche-Intelligenz-Einheit oder Maschinelles-Lernen-Einheit kann mit dem Ergebnis von Tests auf Systemebene in Kombination mit den gesammelten Testdaten und/oder mit gesammelten Sensordaten trainiert werden, um die Ergebnisse von Tests auf Systemebene mit den gesammelten Testdaten zu vergleichen, um die Ergebnisse der Tests auf Systemebene auf der Basis der gesammelten Testdaten oder Messdaten vorauszusagen.
Die Verwendung einer Vorhersage der Ergebnisse der Tests auf Systemebene auf der Basis gesammelter Testdaten kann ferner die Anzahl von Testszenarien und/oder die Anzahl von Testaktivitäten in einem Testszenario der Testsequenz reduzieren.
Bei einem bevorzugten Ausführungsbeispiel ist die Steuerung oder die automatische Testeinrichtung dazu konfiguriert, die gesammelten Testdaten zu analysieren, um ein Testergebnis zu erhalten, z. B. um ein fehlerhaftes zu testendes Gerät und/oder eine fehlerhafte Ressource eines zu testenden Geräts zu identifizieren, und/oder ein zu testendes Gerät zu klassifizieren.
Das Analysieren der gesammelten Testdaten durch die Verwendung beispielsweise von statistischen Verfahren muss möglicherweise den fehlerhaften IP-Block des DUT definieren oder einen IP-Block des DUT klassifizieren.
Bei einem bevorzugten Ausführungsbeispiel ist die trainierte Künstliche-Intelligenz-Einheit oder Maschinelles-Lernen-Einheit dazu konfiguriert, die gesammelten Testdaten zu analysieren, um Testsequenzen und/oder ein erhaltenes Testergebnis zu optimieren.
Die bereits trainierte Maschinelles-Lernen-Einheit kann die Testsequenz weiter verbessern und/oder das statistische Verfahren verbessern, um die IP-Blöcke des DUT zu klassifizieren und/oder fehlerhafte IP-Blöcke des DUT zu definieren.
Weitere Ausführungsbeispiele gemäß der Erfindung schaffen entsprechende Verfahren und entsprechende Computerprogramme.
Es ist jedoch zu beachten, dass die Verfahren auf denselben Betrachtungen wie die entsprechenden automatischen Testeinrichtungen basieren. Ferner können die Verfahren durch jegliche der Merkmale, Funktionalitäten und Details, die hierin in Bezug auf die automatischen Testeinrichtungen beschrieben sind, sowohl einzeln als auch in Kombination ergänzt werden.
Figurenliste
Ausführungsbeispiele gemäß der vorliegenden Anmeldung werden im Folgenden unter Bezugnahme auf die beigefügten Figuren beschrieben, wobei:

1 eine schematische Darstellung einer Testanordnung zeigt, die eine automatische Testeinrichtung zum Testen eines oder mehrerer zu testenden Geräte aufweist, gemäß einem Ausführungsbeispiel;
2 ein Blockdiagramm zeigt, das einen Testprozess beschreibt, der durch eine Testanordnung ausgeführt wird, gemäß einem Ausführungsbeispiel;
3 eine exemplarische Testaktivitätstabelle als Eingabe eines Einschränkungslösers zeigt, gemäß einem Ausführungsbeispiel;
4 eine exemplarische Ressourcenkonflikttabelle zeigt, die durch einen Einschränkungslöser verwendet wird, gemäß einem Ausführungsbeispiel;
5 eine exemplarische Testszenariotabelle zeigt, die durch einen Einschränkungslöser verwendet wird, gemäß einem Ausführungsbeispiel;
6 eine exemplarische Testschritttabelle zeigt, die durch einen Einschränkungslöser verwendet wird, gemäß einem Ausführungsbeispiel;
7 eine leere Testergebnistabelle mit einer exemplarischen Testsequenz zeigt, die durch einen Einschränkungslöser erschaffen wird, gemäß einem Ausführungsbeispiel;
8 eine exemplarische Tabelle zu Fehlschlag pro Testschritt zeigt, die zum Optimieren der Anzahl von Testschritten verwendet wird, gemäß einem Ausführungsbeispiel;
9 eine Vergleichstabelle zwischen dem SLT-Testen und dem OCST-Testen gemäß einem Ausführungsbeispiel zeigt;
10 eine Tabelle zeigt, die die gesammelten Testdaten mit SLT-Ergebnissen kombiniert, die als Trainingsdatensatz für ein Maschinelles-Lernen-Modul verwendet werden, gemäß einem Ausführungsbeispiel;
11 eine Tabelle zeigt, die die gesammelten Testdaten mit OCST-Ergebnissen kombiniert, die als Trainingsdatensatz für ein Maschinelles-Lernen-Modul verwendet werden, gemäß einem Ausführungsbeispiel.

Ausführliche Beschreibung der Ausführungsbeispiele
Im Folgenden werden unterschiedliche Ausführungsbeispiele und Aspekte gemäß der Erfindung beschrieben. Außerdem sind weitere Ausführungsbeispiele durch die beigefügten Patentansprüche definiert.
Es ist zu beachten, dass jegliche wie durch die Patentansprüche definierten Ausführungsbeispiele durch jegliche der hierin beschriebenen Details, Merkmale und Funktionalitäten ergänzt werden können. Außerdem können die hierin beschriebenen Ausführungsbeispiele einzeln verwendet werden und können optional durch jegliche der in den Patentansprüchen enthaltenen Details, Merkmale und Funktionalitäten ergänzt werden. Es ist außerdem zu beachten, dass hierin beschriebene einzelne Aspekte einzeln oder in Kombination verwendet werden können. Somit können Details zu jedem der einzelnen Aspekte hinzugefügt werden, ohne Details zu einem anderen der Aspekte hinzuzufügen. Es ist außerdem zu beachten, dass die vorliegende Offenbarung explizite und implizite Merkmale beschreibt, die in einer automatischen Testeinrichtung nutzbar sind. Somit können jegliche der hierin beschriebenen Merkmale im Kontext einer automatischen Testeinrichtung verwendet werden.
Ferner können hierin offenbarte Merkmale und Funktionalitäten, die sich auf ein Verfahren beziehen, auch in einer Vorrichtung verwendet werden, die dazu konfiguriert ist, solch eine Funktionalität auszuführen. Ferner können hierin offenbarte Merkmale und Funktionalitäten in Bezug auf eine Vorrichtung auch in einem entsprechenden Verfahren verwendet werden. Mit andern Worten können die hierin offenbarten Verfahren durch jegliche der in Bezug auf die Vorrichtungen beschriebenen Merkmale und Funktionalitäten ergänzt werden.
Die Erfindung wird aus der im Folgenden angegebenen ausführlichen Beschreibung und den beigefügten Zeichnungen der Ausführungsbeispiele der Erfindung umfassend verständlich, die jedoch nicht dahingehend anzusehen sind, dass sie die Erfindung auf spezifische beschriebene Ausführungsbeispiele beschränken, sondern dienen lediglich zur Erläuterung und zum Verständnis.
Ausführunqsbeispiele gemäß Fig. 1
1 zeigt eine schematische Darstellung einer Testanordnung 100, die eine automatische Testeinrichtung (ATE, Automated Test Equipment) 110 zum Testen eines oder mehrere zu testender Geräte (DUT, Devices Under Test) 120 aufweist. 1 weist ferner ein exemplarisches DUT 120 auf, das eine Mehrzahl von DUT-Ressourcen 130a-e aufweist. Die DUT-Ressourcen 130a-e können unterschiedliche IP-Blöcke aufweisen, etwa CPU, Speicher MPEG, usw.
Die ATE 110 ist dazu konfiguriert, eine Mehrzahl von Testszenarien 140a-c zu erzeugen, die jeweils eine Mehrzahl von Testaktivitäten aufweisen. Beispielsweise weisen die Testszenarien 140c die Testaktivitäten 150a-c auf.
Jede Testaktivität ist dazu konfiguriert, eine oder mehrere DUT-Ressourcen 130a-e zu nutzen. Beispielsweise ist die Testaktivität 150a dazu konfiguriert, die DUT-Ressource 130e zu nutzen. Oder die Testaktivität 150b ist beispielsweise dazu konfiguriert, die DUT-Ressourcen 130c und 130d zu nutzen. Ein weiteres Beispiel kann die Testaktivität 150c sein, die dazu konfiguriert ist, die DUT-Ressourcen 130a und 130b zu nutzen.
Die automatische Testeinrichtung 110 ist dazu konfiguriert, die Mehrzahl von Testszenarien zu erzeugen, etwa die Testszenarien 140a-c, so dass die DUT-Ressourcen, etwa die DUT-Ressourcen 130a-e, die der Mehrzahl von Testaktivitäten, etwa den Testaktivitäten 150a-c, zugeordnet sind, nicht miteinander in Konflikt stehen. Beispielsweise sind die Testaktivitäten 150a-c zu dem Testszenario 140c gruppiert, so dass die DUT-Ressourcen 130a-e der Testaktivitäten 150a-c nicht in Konflikt stehen, was eine gleichzeitige Ausführung der Testaktivitäten 150a-c des gegebenen Testszenarios 140c ermöglicht.
Eine allgemeine Idee von Auf-Chip-Systemtests (OCST, On-Chip-System Tests) besteht darin, eine große Anzahl von einfachen realistischen Testaktivitäten gleichzeitig auf DUTs 120 unter Verwendung von DUT-Ressourcen 130a-e auszuführen, wobei Kombinationen und/oder Intensitäten der gleichzeitigen Testaktivitäten variieren. Jede Testaktivität kann involvierte IP-Blöcke prüfen, trägt durch eine Belastung von Versorgungen, Taktbäumen und thermischer Kopplung jedoch auch zu den Testbedingungen anderer IP-Blöcke bei. Beispiele von Testaktivitäten können eine Bewegung von Datenblöcken oder eine Ausführung von eingebauten Selbsttests aufweisen, etwa in Speicher eingebaute Selbsttests (MBIST, Memory Built-In Self Test) oder in Logik eingebaute Selbsttests (LBIST, Logic Built-In Self Tests).
Beispielsweise führt die OCST-Steuerung strukturelle Tests, etwa LBIST, MBIST, usw. auf lokaler Weise in einigen IP-Blöcken aus. Diese Testaktivitäten sind selbstverständlich selbstprüfend, können jedoch auch als Belastungsgenerator dienen, um die Testbedingungen anderer simultan ablaufender Testaktivitäten zu steuern. In Testszenarien führen einige IP-Kerne strukturelle Tests aus, während andere Kerne sich beispielsweise mit Codebasierten Testaktivitäten befassen.
Die involvierten IP-Blöcke können Testgerechter-Entwurf-(DFT, Design For Test)-Strukturen oder -techniken einsetzen, etwa das Erzeugen von Belastung, um Fehler erfassbar zu machen und/oder eine Beobachtbarkeit zu erhöhen, so dass erfassbar gemachte Fehler wahrscheinlicher detektiert werden und/oder einen Zugriff auf bestehende Strukturen zur Fehlerbehebung oder zu Tests im System bereitzustellen.
Eine Randomisierung von Testaktivitäten oder parametrisierbaren Testaktivitäten deckt zahlreiche Kombinationen von lokalen Arbeitslasten ab und ahmt somit eine große Anzahl von realistischen Arbeitslastmustern nach, die als verantwortlich für zahlreiche Fehler auf Systemebene betrachtet werden. Bestehende oder neue Testgerechter-Entwurf-(DFT)-Strukturen können eine kontrollierte Belastung erzeugen und die Beobachtbarkeit erhöhen, um die Wahrscheinlichkeit einer Fehlerdetektion (oder zur wahrscheinlicheren Fehlerdetektion) zu erhöhen.
DFT-Strukturen können die Beobachtbarkeit beispielsweise dadurch verbessern, dass die Auf-Chip-OCST-Steuerung mit Auf-Chip-IJTAG kommuniziert, um Auf-Chip-Sensordaten auszulesen.
Beispielsweise können zusätzliche Sensoren mit optionalen Schwellalarmfähigkeiten für aktuelle / Maximalspitzen- / Minimalspitzen-Temperatur und/oder für aktuelle / Maximalspitzen- / Minimalspitzen-Spannung und/oder Zeitsteuerungsverletzung, beispielsweise in Razor-Schaltungen, die Beobachtbarkeit weiter verbessern. Der Alarm kann eine Speicherung oder Aufbewahrung eines wichtigen Systemstatus auslösen, etwa Programmzähler, Speichersteuerungsregister, um eine Fehlerkorrektur zu vereinfachen.
Die Beobachtbarkeit kann durch zusätzliche Sensoren, die über die Halbleiterchipfläche verteilt sind, weiter verbessert werden, um lokale Anomalitäten zu detektieren. Oder durch das Verbinden eines Prozessors, um einen Speicher nachzuverfolgen, wobei sein Inhalt mit Erwartungen verglichen wird. Ferner können Bestätigungsprüfer hinzugefügt werden, etwa Protokollprüfer, oder CRC, oder Busdatenverkehrsaufzeichner, um eine Abdeckung zu messen und bei der Fehlerkorrektur zu unterstützen.
Die Testaktivitäten werden beispielsweise auf kontrollierte auf einer Auf-Chip-Systemtest-(OCST)-Steuerung Weise orchestriert, so dass die effektivsten Testbedingungen bestimmt werden können, und Nichtbestehen zu spezifischen Testaktivitäten und deren Testparameterwerten zugeordnet werden kann.
Ausführungsbeispiele gemäß Fig. 2
2 zeigt ein Blockdiagramm 200, das einen Testprozess beschreibt, welcher durch eine Testanordnung ausgeführt wird, die der Testanordnung 100 aus 1 ähnelt.
Das Blockdiagramm 200 startet mit einer Testaktivitätstabelle 210. Die Testaktivitätstabelle 210 weist eine Spalte von Testaktivitäten 212 auf, wobei jede Testaktivität 212 eine oder mehrere DUT-Ressourcen 214 verwenden kann. Die entsprechenden DUT-Ressourcen 214 sind in einer Spalte der DUT-Ressourcen 214 bereitgestellt. Ferner können die Testaktivitäten 212 entsprechende Testparameter 216 und/oder Einschränkungen 218 aufweisen, die in separaten Spalten bereitgestellt sind. Einschränkungen können auf der Testszenarioebene sowie Referenztestparameter aus mehreren Testaktivitäten sein.
Die Testaktivitätstabelle 210 wird dem Einschränkungslöser (bzw. Constraint Solver) 250 zugeführt. Der Einschränkungslöser 250 kann in einer ATE 220 bzw. in einer Steuerung 270 enthalten sein oder kann eine separate Entität sein, wie in 2 gezeigt ist. Der Einschränkungslöser 250 aus 2 weist einen Eingang und einen Ausgang auf. Der Eingang des Einschränkungslösers 250 wird von der Testaktivitätstabelle 210 zugeführt. Der Ausgang des Einschränkungslösers ist eine Testsequenztabelle 260.
Die Testsequenztabelle 260 weist Testszenarien 262 auf, die den Testszenarien 140a-c aus 1 ähneln. Die Testszenarien können eine oder mehrere Testaktivitäten 212a-e aufweisen, wobei jede Testaktivität 212 a-e Testparameterwerte 216a-e aufweisen kann. Die Testsequenztabelle 260 wird der ATE 220 oder der Steuerung 270 bereitgestellt.
Beispielsweise kann das erste Szenario eine erste Testaktivität 212a mit den Testparametern P1 216a, P2 216b und die Testaktivität 212b mit den Testparametern P3 216c und P4 216d aufweisen. Das zweite Szenario kann die zweite Testaktivität 212b mit den Testparametern P3 216c und dem Testparameter P4 216d aufweisen. Ein drittes Szenario kann eine dritte Testaktivität 212c mit den Testparametern P3 216c und P5 216e aufweisen. Ein viertes Szenario kann eine vierte Testaktivität 212d mit dem Testparameter P2 216b und dem Testparameter P4 266d aufweisen.
Die Steuerung 270 nimmt die Testsequenztabelle 260 als Eingang und gibt eine Testergebnistabelle 280 aus. Die Testergebnistabelle 280, die durch den Testblock 270 bereitgestellt wird, weist die Testergebnisse 288 der einen oder der mehreren Testaktivitäten 212 der Testszenarien 262 auf, die auf den DUTs 282 ausgeführt werden. Die Testergebnistabelle 280 wird in die ATE 220 und/oder zurück in die Steuerung 270 eingespeist.
Die ATE 220 oder die Steuerung 270 akzeptiert die Testergebnistabelle 280 als Eingang und stellt eine verbesserte Testsequenztabelle 260 und/oder eine Ergebnistabelle 292 als Ausgang bereit.
Die verbesserte Testsequenztabelle 260 kann ferner als Eingang der Steuerung 270 verwendet werden, um eine neue Testergebnistabelle 280 bereitzustellen, die zurück in die ATE 220 oder in die Steuerung 270 eingespeist werden kann.
Die durch die ATE 220 oder die Steuerung 270 bereitgestellte Ergebnistabelle 292 weist Bestanden-/Durchgefallen-Testergebnisse 298 der DUT-Ressourcen 296 auf. Zusätzlich oder alternativ dazu kann die Ergebnistabelle 292 eine Klassifizierung der DUT-Ressourcen 296 aufweisen.
Die Testaktivitätstabelle 210 mit Einschränkungen 218, Testparametern 216 und Ressourcen 214, die von den Testaktivitäten 212 benötigt werden, wird dem Einschränkungslöser 250 bereitgestellt. Die Testaktivitätstabelle 210 oder eine Bibliothek von Testaktivitäten kann ferner eine Sammlung von Codes für die Steuerung 270 oder die OCST-Steuerung 270 aufweisen, um Testaktivitäten 212 zu aktivieren oder auszuführen. Die Bibliothek kann auch wissen, welche DUT- oder Auf-Chip- und ATE-Ressourcen durch eine gegebene Testaktivität 212 verwendet werden.
Der Einschränkungslöser 250 ist dazu konfiguriert, eine Testsequenztabelle 260 aus der Testaktivitätstabelle 210 zu erzeugen. Die Testsequenztabelle 260 weist Testszenarien 262 auf, wobei die Testszenarien 262 eine oder mehrere Testaktivitäten 212a-e aufweisen, die koexistieren oder gleichzeitig ausgeführt werden können, ohne Ressourcenbeschränkungen 218 zu verletzen. Die Testszenarien 262 werden automatisch von dem Einschränkungslöser 250 erzeugt, der auf der Arbeitsstation und/oder auf der Steuerung 270 abläuft, etwa eine OCST-Karte oder eine Auf-Chip-OCST-Steuerung. Die Einschränkungen können in PSS moduliert werden.
Die Testsequenztabelle 260, die von dem Einschränkungslöser 250 bereitgestellt wird, weist die Szenarien 262 auf, wobei eine oder mehrere Testaktivitäten 212a-d, die dem einen oder den mehreren Testparametern 216a-e zugeordnet sind, gleichzeitig ausgeführt werden können. Die Testparameterwerte, die die jeweiligen Testparameter 214a-e charakterisieren, werden zufällig ausgewählt oder dahingehend ausgewählt, dass eine Betonung auf Extremwerten liegt. Die Reihenfolge der Testszenarien 262 wird beispielsweise zufällig erzeugt, um eine echte Arbeitslast zu simulieren.
Die erzeugte Testsequenztabelle 260 wird der Steuerung 270 bereitgestellt, etwa einer Auf-Chip-OCST-Steuerung, die dazu konfiguriert ist, die Testszenarien 262 der Testsequenztabelle 260 auszuführen, um Testdaten 280 zu sammeln. Die Steuerung 270 kann Schnittstellen, um mit der ATE zu kommunizieren, und/oder Schnittstellen aufweisen, um mit dem DUT zu kommunizieren.
Die Steuerung 270 kann DUT-Testdaten und/oder DUT-Sensordaten auslesen, und/oder die Steuerung kann Sensoren über der DUT-Fläche oder Halbleiterchipfläche aufweisen, um lokale Anomalitäten zu detektieren. Die gemessenen Werte oder gesammelten Daten 280 können die Steuerung 270 dahingehend auslösen, weitere Informationen wie etwa Speicherinformationen oder Statusinformationen des DUT zu sammeln, falls die Messwerte und/oder Sensorwerte bestimmte vordefinierte Bedingungen erfüllen.
Die Steuerung 270 ist dazu konfiguriert, die gesammelten Testdaten 280 oder Testergebnisse 288 von Testaktivitäten 212 der Szenarien 262 an die ATE 220 zu kommunizieren. Die ATE 220 oder die Steuerung 270 ist dazu konfiguriert, den Testprozess weiter zu verbessern und/oder eine Fehlerkorrektur oder Diagnose des DUT auszuführen.
Die Steuerung 270, etwa eine Auf-Chip-OCST-Steuerung oder eine OCST-Karte, oder eine ATE 220 ist dazu konfiguriert, den Satz von Testparametern der Testszenarien, die Einschränkungen erfüllen können und es ermöglichen können, aktuelle Testparameter zur Fehlerkorrektur zu kennen, auf dynamische Weise zu erzeugen oder zu modifizieren. Verfahren zum Erzeugen von Testparameterwertsätzen für Testaktivitäten 212 umfassen eine Randomisierung, die einer gewünschten Verteilung folgt, mit optionaler Betonung von Extremwerten betont, beispielsweise unter Verwendung eines Einschränkungslösers, um eine Abdeckung zu maximieren, oder beispielsweise unter Verwendung von verschachtelten Schleifen für eine umfassende Abdeckung von einigen wenigen Testparametern.
Um die Testumgebung weiter zu verbessern, kann eine Testlernumgebung erforderlich sein. Umfassende Charakterisierungstests sind die Basis für das Testlernen, wobei viele DUTs gegenüber vielen Testschritten oder vielen Testszenarien ausgesetzt werden. Vorzugsweise werden nicht alle DUTs 282 gegenüber denselben Testschritten oder Testszenarien ausgesetzt, um eine große Menge an Kombinationen von Testparametern 216 abzudecken. Um eine Verzerrung von Testszenarien hin zu bestimmten DUTs 282 zu vermeiden, werden Testschritte oder Testszenarien in einer zufälligen Permutationsreihenfolge ausgeführt.
Die ATE 220 oder die Steuerung 270 kann Maschinelles-Lernen-Module oder KI-Module verwenden, die mit den gesammelten Testergebnisdaten 280 oder den Systemebene-Testergebnissen trainiert werden. Das Maschinelles-Lernen-Modul kann die gesammelten Testergebnisdaten 280 und das Systemebene-Testergebnis analysieren und kann Systemebene-Testergebnisse auf der Basis eines neuen Satzes gesammelter Testdaten 280 vorhersagen.
Das KI-Modul kann ferner durch gemessene Ergebnisdaten ohne Spezifikationsbegrenzungen trainiert werden, etwa Auf-Chip-Sensordaten, oder durch Testparameter außerhalb von Spezifikationsgrenzen, etwa zu geringe Spannungen oder zu schnelle Frequenzen, um Nichtbestehen von Tests auf Systemebene aus den Testergebnissen vorherzusagen. Nichtbestandene Testschritte oder Testaktivitäten außerhalb von Spezifikationsgrenzen sind kein Beweis für schlechte DUTs.
Jedoch können Maschinelles-Lernen-Module oder -modelle dahingehend konstruiert werden, Systemebenen-Testergebnisse aus einem Testschritt oder Testaktivitätsergebnis vorherzusagen, darunter gemessene Ergebnisse ohne oder außerhalb von Spezifikationsgrenzen und Testschritte oder Szenarien mit außerhalb von Spezifikationsgrenzen liegenden Testparametern und Testschritte- oder Szenarien-bezogene Eigenschaften, etwa involvierte Testaktivitäten und Testressourcen.
Solche Modelle können mit hoher Wahrscheinlichkeit einige der zuvor nicht erfassten nichtbestandenen SLTs, es können jedoch auch einige DUTs nicht bestehen, die SLT bestehen und alle anderen legitimen OCST-Tests bestehen. Diese Fälle können als Ertragsverlust durch Testen betrachtet werden und müssen vorsichtig gegen zusätzlich gefundene nichtbestandene SLTs aufgewogen werden, vorzugsweise auf der Basis eines Kostenmodells. Lediglich diejenigen zusätzlichen Testschritte und Szenarien können in Produktionsschritten enthalten sein, die von solchen Modellen benötigt werden. Zusätzliche Testschritte können erneut entfernt werden.
Die ATE 220 oder die Steuerung 270 kann ferner dazu konfiguriert sein, bei der DUT eine Fehlerkorrektur und/oder Diagnose auszuführen. Da die Testergebnistabelle 280 Ergebnisse 288 von gleichzeitig ausgeführten Testaktivitäten 212 von Testszenarien 262 aufweist, besteht ein Bedarf für weitere Analysen der gesammelten Testdaten 280, um fehlerhafte DUTs oder DUT-Ressourcen zu identifizieren und/oder zu klassifizieren.
Die allgemeine Idee zur Fehlerkorrektur oder Diagnose besteht darin, diejenigen Testparameter 216 zu identifizieren, die das Auftreten von nichtbestandenen OCSTs am meisten beeinflussen. Testparameter 216, die mit Testaktivitäten 212 in Verbindung stehen, welche bestimmte Aktionen in spezifischen IP-Blöcken involvieren, stellen informative Hinweise zur Fehlerkorrektur bereit.
Ein Maschinelles-Lernen-Modul, das mittels einer Tabelle, die Testschritte oder Szenarien mit Testaktivitäten, DUT-Ressourcen, Testparametern, Testergebnissen und einem allgemeinen OCST-Ergebnis kombiniert, trainiert wird, optional für mehrere DUTs, kann dazu verwendet werden, fehlerhafte DUT-Ressourcen zu klassifizieren oder zu identifizieren. Das Maschinelles-Lernen-Modul oder der Maschinelles-Lernen-Merkmalsauswahlalgorithmus kann identifizieren, welche Testaktivitäten, Test- oder DUT-Ressourcen und Testergebnisse wichtig sind, um OCST-Ergebnisse zu erläutern, die zum Auftreten von nichtbestandenen OCSTs beitragen.
Mit anderen Worten steuert die Steuerung 270 den Testprozess. Die Steuerung, bzw. die OCST-Steuerung, ist vorzugsweise ein Auf-Chip-Prozessor gemeinsam mit einem optionalen Testbetriebssystem, kann jedoch auch eine OCST-Karte sein, die mit dem DUT oder der ATE-Arbeitsstation kommuniziert.
Eine Aufgabe der OCST-Steuerung kann beispielsweise darin bestehen, eine Ausführung von mehreren Testaktivitäten auszulösen und deren Bestanden-/Durchgefallen-Ergebnisse und/oder Messergebnisse auszulesen. Die Testaktivitäten können eine Kombination von optionaler Belastungserzeugung und/oder optionaler Fehlerdetektion umfassen.
Weitere Beispiele von Testaktivitäten sind im Folgenden aufgelistet:

• Die ATE setzt externe Testbedingungen des DUT fest, z. B. eine DUT-Versorgungsspannung oder -frequenz, d. h. die OCST-Steuerung kann ATE-Ressourcen steuern.
• ATE führt Messungen aus, z. B. Versorgungsstrommessungen.
• Datenblöcke werden zwischen IP-Kernen bewegt und der Inhalt wird vor und/oder danach überprüft.
• Speichertests laufen auf Auf-Chip-CPUs ab.
• Speicherselbsttests laufen ab.
• Bilder werden komprimiert und dekomprimiert und die Differenz zwischen dem ursprünglichen und dem dekomprimierten Bild wird geprüft. (Belastung und Prüfung)
• I/O-Schleifenschaltung-Tests laufen ab.
• Belastungserzeugung wird unter Verwendung von DFT-Techniken angewendet.
• Jegliche der Beobachtbarkeit-Strukturen wird/werden unter Verwendung von DFT-Techniken aktiviert und ausgelesen.

Die Steuerung weiß immer, welches Testszenario mit welchen Test-(Aktivitäts-)-Parametern ausgeführt wird, was notwendig zur Fehlerkorrektur ist, wenn Fehler auftreten.
Ferner könnte die Steuerung oder die OCST-Steuerung Testaktivitätsparameter auf der Basis von Einschränkungen dynamisch erzeugen oder modifizieren, und/oder könnte dieselben aus vorberechneten Listen bearbeiten oder importieren. Außerdem könnte die Steuerung, oder der den OCST-Steuerungscode ausführende Prozessor, auch Testaktivitäten erzeugen.
Exemplarische Testaktivitätstabelle gemäß Fig. 3
3 zeigt eine exemplarische Testaktivitätstabelle 300 gemäß einem Ausführungsbeispiel. Die Testaktivitätstabelle 300 ähnelt der Testaktivitätstabelle 210 aus 2 oder ist ein Beispiel derselben.
Die Testaktivitätstabelle 300 weist Spalten von Testaktivitäten, Ressourcen, Testparametern und möglichen Ergebnissen auf. Die Testaktivitätstabelle ist dazu konfiguriert, alle möglichen auf einem DUT auszuführenden Tests mit den erforderlichen Ressourcen, einstellbaren Parametern und möglichen Resultaten oder Ergebnissen aufzulisten.
Die Testaktivitätstabelle 300 kann einen Einschränkungslöser, etwa einen Einschränkungslöser 250 aus 2, als Eingang verwenden, um Testsequenzen zu erzeugen. Eine Testsequenz kann definieren, welche Testaktivität mit welchen Testparametern auf welchem DUT in welcher Reihenfolge ausgeführt wird.
Die Testaktivitätstabelle 300 kann übliche Testaktivitäten oder DUT-spezifische Testaktivitäten aufweisen. Einige Beispiele von Testaktivitäten sind in der beispielhaften Testaktivitätstabelle 300 enthalten.
Beispielsweise kann eine erste Testaktivität A1 eine Verarbeitungseinheit 2 (CPU2) aufweisen, die Daten in den Speicher 3 (MEM3) schreibt und den Inhalt von MEM3 prüft. Die Aktivität A1 erfordert die Ressourcen R1: CPU2, R2: MEM3, R3: ATE DPS zur Kernversorgung. Die einstellbaren Testparameter von Testaktivität A1 sind: P1: Bandbreite, P2: DPS-Spannung. Ergebnisse können zwei Werte r1, welcher ein Bestanden-/Durchgefallen-Wert ist, und r2 umfassen, welcher ein elektrischer Stromwert ist.
Beispielsweise ist eine Testaktivität A2 ein in einen Speicher eingebauter Selbsttest (MBIST) des MEM3, welcher die Ressource R2 erfordert, also MEM3, ohne einstellbare Parameter und mit einem Ergebnis eines Bestanden-/Durchgefallen-Werts als Ergebnis.
Beispielsweise ist eine Testaktivität A3 ein MPEG-Selbsttest, der eine MPEG-Ressource mit einstellbaren Blockgrößen als Testparameter P3 erfordert, mit einem Resultat eines Bestanden-/Durchgefallen-Wertes.
Ressourcenkonflikttabelle gemäß Fig. 4
4 zeigt eine Ressourcenkonflikttabelle 400, die von dem Einschränkungslöser 250 aus 2 verwendet und/oder erzeugt werden könnte. Die Ressourcenkonflikttabelle 400 weist eine Testaktivitätsspalte und eine Spalte für jede Ressource des DUT auf. Jede Testaktivität der Tabelle 400 verwendet ein oder mehrere DUT-Testressourcen, die durch ein „X“ in der jeweiligen Ressourcenspalte dargestellt sind.
Ein Einschränkungslöser, wie der Einschränkungslöser 250 aus 2, kann eine Testaktivitätstabelle, etwa die Tabelle 300 aus 3, als Eingang verwenden, um eine Testsequenz zu erzeugen. Ein Schritt des Erzeugens einer Testsequenz besteht darin, eine Ressourcenkonflikttabelle, etwa eine Ressourcenkonflikttabelle 400, zu erzeugen. Die Ressourcenkonflikttabelle 400 zeigt, welche Testaktivitäten dieselben DUT-Ressourcen verwenden und welche Testaktivitäten daher nicht gleichzeitig ablaufen können.
Beispielsweise zeigt die Ressourcenkonflikttabelle 400 in Konflikt stehende Ressourcen der Testaktivitäten der Testaktivitätstabelle 300. Beispielsweise verwendet die Testaktivität A1 die Ressourcen R1, R2, R3 und verwendet R4 nicht. Beispielsweise verwendet die Testaktivität A2 lediglich R2 als Ressource. Beispielsweise verwendet die Testaktivität A3 die DUT-Ressource R4.
Wie die Ressourcenkonflikttabelle 400 zeigt, sind die Testaktivität A1 und die Testaktivität A2 in Konflikt stehende Testaktivitäten, da beide die Testressource R2 erfordern. Testaktivitäten A1 und A2 erfordern die Testressource R2 und können daher nicht gleichzeitig ablaufen. Das heißt, die Testaktivität A1 und die Testaktivität A2 können nicht gleichzeitig ablaufen, sie können beispielsweise nicht in dasselbe Testszenario gesetzt werden. Die Aktivitäten ohne Ressourcenkonflikte können zu Testszenarien kombiniert werden.
Testszenariotabelle gemäß Fig. 5
5 zeigt eine Testszenariotabelle 500, die von einem Einschränkungslöser 250 aus 2 verwendet oder erzeugt werden könnte. Die Testszenariotabelle 500 weist eine Testszenariospalte und eine Spalte für jede bereitgestellte Testaktivität auf. Die Testszenariotabelle 500 weist alle möglichen Testszenarien auf. Die eine oder die mehreren Testaktivitäten der Testszenarien werden gleichzeitig ausgeführt.
Die Testszenariotabelle 500 zeigt alle Testszenarien, die aus Testaktivitäten, wie etwa den Testaktivitäten A1, A2 und A3 der Testaktivitätstabelle 300 aus 3, erzeugt werden könnten. Es ist erforderlich, dass die Testaktivitäten eines Testszenarios nicht in Konflikt stehen. In Konflikt stehende Testaktivitäten sind in einer Ressourcenkonflikttabelle gezeigt, ähnlich zu der Ressourcenkonflikttabelle 400 aus 4. Das Ausschließen der Testszenarien mit in Konflikt stehenden Testaktivitäten, übernommen aus der Ressourcenkonflikttabelle, aus allen möglichen Testszenarien hat die Testszenariotabelle mit nicht in Konflikt stehenden Testaktivitäten zur Folge, etwa die Testszenariotabelle 500.
Beispielsweise weist die Testszenariotabelle 500 die Testszenariospalte und eine Spalte für jede Testaktivität auf, etwa A1, A2, A3. Gemäß der Ressourcenkonflikttabelle 400 aus 4 verwenden A1 und A2 dieselbe Ressource R2, daher können die Testaktivität A1 und die Testaktivität A2 nicht gleichzeitig ablaufen und können nicht in demselben Testszenario sein.
Beispielsweise sind die Testszenarien der exemplarischen Testaktivitäten aus 3 das Testszenario S1 mit der Testaktivität A1, das Testszenario S2 mit der Testaktivität A2, das Testszenario S3 mit der Testaktivität A3, das Testszenario S4 mit den gleichzeitigen Testaktivitäten A1, A3, und das Testszenario S5 mit den gleichzeitigen Testaktivitäten A2, A3. Aufgrund von Ressourceneinschränkungen führt kein Testszenario die Testaktivitäten A1 und A2 gleichzeitig aus.
Ob Testaktivitäten wirklich gleichzeitig ablaufen, kann von Testparametereinstellungen und anderen unbekannten Faktoren abhängen. Eine Testsequenz oder Testsammlung besteht aus mehreren Testschritten, die ein gegebenes Testszenario mit spezifizierten Testparameterwerten für deren Testaktivitäten ausführen.
Testschritttabelle gemäß Fig. 6
6 zeigt eine Testschritttabelle 600, die von einem Einschränkungslöser 250 aus 2 verwendet oder erzeugt werden kann. Die Testschritttabelle weist Spalten für Testschritte, Testszenarien, Testaktivitäten und Spalten für Testparameter, die Testaktivitäten entsprechen, auf.
Die Testschrittspalte der Testschritttabelle 600 weist eine fortlaufende Ziffer auf, um die unterschiedlichen Testschritte zu identifizieren. Die Testszenariospalte kann alle möglichen Testszenarien zumindest einmal aufweisen. Die Testszenarien können mehr als einmal mit mehreren unterschiedlichen Testparametern getestet werden. Ähnlich zu der Testszenariotabelle 500 aus 5 werden die Testaktivitäten der Testszenarien durch ein „X“ in der entsprechenden Testaktivitätsspalte dargestellt.
Falls das Testszenario Testaktivitäten aufweist, weisen die entsprechenden Testparameterspalten die Testparameterwerte auf. Testparameterwerte werden vorzugsweise zufällig erzeugt, optional einer vordefinierten Verteilung folgend und/oder optional mit einem bestimmten Prozentsatz bestimmt, der sich auf Extremwerte konzentriert, die dazu tendieren, mehr Probleme als zufällig erzeugte Testparameterwerte hervorzurufen.
Eine Testsequenz, etwa die Testsequenztabelle 260 aus 2, wird aus der Testschritttabelle 600 erzeugt, indem Testschritte der Testschritttabelle 600 zufällig auf DUTs abgebildet werden, oder einer vordefinierten Verteilung folgend, um mehr Probleme als eine zufällig abgebildete Testsequenz hervorzurufen.
Die Testszenariospalte weist alle möglichen Testszenarien auf, etwa die Testszenarien S1 bis S5 aus der Testszenariotabelle 500, wobei die Testszenarien mit mehreren unterschiedlichen Testparametern getestet werden können.
Beispielsweise kann ein erster Testschritt das erste Testszenario S1 mit einer Testaktivität A1, entsprechend dem Testparameter P1, Bandbreite von 10 GB/s, und Testparameter P2, DPS-Spannung von 0,9 V, sein. Beispielsweise weist ein Testschritt S2 dasselbe Testszenario S1 mit unterschiedlichem Testparameter P1, Bandbreite von 20 GB/s, und P2, DPS-Spannung von 0,86 V, auf.
Beispielsweise weist ein Testschritt 3 das Testszenario S2 auf, welches eine Testaktivität A2 ohne einstellbare Testparameter aufweist.
Beispielsweise weist ein Testschritt 4 das Testszenario S3 mit einer Testaktivität A3 auf, wobei das Testparameter P3 eine Blockgröße von 128 kB ist. Beispielsweise weist ein Testschritt 5 dasselbe Szenario S3 mit einem Testparameter P3 einer Blockgröße von 1 MB auf.
Beispielsweise weist ein Testschritt 6 das Testszenario S4 mit den Testaktivitäten A1 und A3 auf, mit dem Testparameter P1, Bandbreite von 50 DB/s, P2, DPS-Spannung von 1,4 V und Testparameter P3, Blockgröße von 6 MB, auf. Beispielsweise weist ein Testschritt 7 dasselbe Szenario S4 mit dem Testparameter P3, Bandbreite von 3 GB/s, P2, DPS-Spannung von 0,97 V, und P3, Blockgröße von 500 KB, auf. Beispielsweise weist ein Schritt 8 dasselbe Szenario S4 mit dem Testparameter P1, Bandbreite von 27 GB/s, P2, DPS-Spannung von 0,88 V, und P3, Blockgröße von 21 MB, auf.
Beispielweise weist ein Testschritt 9 ein Testszenario S5 mit einer Testaktivität A2 ohne Testparameter und der Testaktivität A3 mit einem Testparameter P3, Blockgröße von 7 MB, auf. Beispielsweise weist ein Testschritt 10 dasselbe Testszenario wie S5 mit einem Testparameter P3, Blockgröße von 780 KB, auf. Beispielsweise weist in Schritt 11 dasselbe Testszenario wie S5 mit einem Testparameter P3, Blockgröße von 13 MB, auf.
Testerqebnistabelle gemäß Fig. 7
7 zeigt eine leere Testergebnistabelle 700, die von der Steuerung nach dem Ausführen von Testaktivitäten der Testsequenztabelle 260 aus 2 gefüllt werden könnte. Die Testergebnistabelle weist Spalten für DUTs, Testschritte, Testergebnisse von Testaktivitäten und eine Gesamttestergebnisspalte auf.
Die Testergebnistabelle 700 weist die Testsequenz auf, etwa die Testsequenztabelle 260 aus 2. Die ersten zwei Spalten der Testergebnistabelle 700, die DUT- und die Testschrittspalte, definieren, welcher Testschritt auf welchem DUT ausgeführt wird. Die Testsequenz wird aus der Testschritttabelle 600 aus 6 erzeugt, indem Testschritte der Testschritttabelle 600 auf DUTs zufällig abgebildet werden, oder einer vordefinierten Verteilung folgend, und/oder unter Erfüllung von definierten Bedingungen, um mehr Probleme als die zufällig abgebildete Testsequenz hervorzurufen.
Eine exemplarische Testsequenz kann beispielsweise eine DUT1, die durch die Testschritte 6, 11, 7, 1 und 8 getestet wird, und eine DUT2 aufweisen, die durch die Testschritte 5, 2, 10, 4 und 9 getestet wird.
Die Steuerung, etwa eine Auf-Chip-Steuerung oder eine Steuerungskarte, führt die Tests gemäß der Testsequenz aus. Die Ergebnisse der Testaktivitäten, dargestellt durch die Spalten r1 (#durchgefallen), r2 (Strom), r3 (#durchgefallen), r4 (b/d) von der Steuerung gesammelt. Das Gesamt-OCST-Ergebnis kann auf all den Ergebnissen der Testaktivitäten oder auf einem Teilsatz der Testaktivitätsergebnisse basieren. Zusätzlich oder alternativ dazu kann das OCST-Ergebnis eine Klassifizierung des DUT auf der Basis der Testaktivitätsergebnisse oder einiger Testaktivitätsergebnisse aufweisen.
Bei diesem Beispiel wird das Gesamt-OCST-Ergebnis aus den Ergebnissen r1, r3 und r4 berechnet, das gemessene Ergebnis r2 trägt also nicht zu dem Gesamttestergebnis bei, da es bei diesem Beispiel keine Spezifikationsbegrenzungen aufweist.
Tabelle zu Durchgefallen pro Testschritt gemäß Fig. 8
8 zeigt eine Tabelle zu Durchgefallen pro Testschritt 800, die eine DUT-Spalte und Spalten für alle Testschritte aufweist. Die getesteten DUTs sind in der DUT-Spalte aufgelistet. Eine Zeile eines getesteten DUT weist einen Buchstaben „B“ in einer gegebenen Testschrittspalte auf, falls die DUT den gegebenen Testschritt bestanden hat, und einen Buchstaben „D“ mit einem hinterlegten Hintergrund auf, falls die DUT durch den gegebenen Testschritt durchgefallen ist.
Die Steuerung oder die ATE ist dazu konfiguriert, die Tabelle zu Durchgefallen pro Testschritt 800 dazu zu verwenden, die Anzahl von Testschritten zu optimieren, vorzugsweise zu reduzieren. Beispielsweise kann die Anzahl von niemals durchgefallenen Tests und/oder redundanten Testschritten reduziert werden. Die Aufgabe der Steuerung oder der ATE kann ein Auswählen eines Mindestsatzes von Testschritten aufweisen, was als das Mindestmengenüberdeckungsproblem bekannt ist, welches eine bekannte Lösung aufweist.
Beispielsweise kann in diesem Fall die Tabelle zu Durchgefallen pro Testschritt 800 die Testergebnisse von vier DUTs, DUT 1-4, aufweisen. Beispielsweise kann DUT 1 alle Testschritte außer Testschritt 6 bestehen. Beispielsweise kann DUT 2 alle Testschritte außer den Testschritten 2 und 4 bestehen. Beispielsweise kann DUT 3 alle Testschritte außer den Testschritten 1 und 6 bestehen. Beispielsweise kann DUT 4 alle Testschritte außer Testschritt 8 bestehen.
Während die Steuerung oder die ATE die Tabelle zu Durchgefallen pro Testschritt 800 analysiert, kann die Steuerung beispielsweise zu dem Schluss kommen, dass die Testschritte 3, 5 und 7 niemals durchfallen und daher aus den Produktionstests entfernt werden können. Ferner ist Testschritt 4 redundant zu Testschritt 2 und kann auch entfernt werden.
Vergleich von OCST und SLT gemäß Fig. 9
9 zeigt eine exemplarische Vergleichstabelle 900 zwischen den OCST-Testergebnissen und den SLT-Testergebnissen. Die exemplarische Vergleichstabelle 900 zeigt Unterschiede, die auftreten können, wenn derselbe Satz von DUTs mit OCST- und SLT-Testverfahren getestet wird.
Bei diesem Beispiel haben 9900 Geräte beide Testverfahren, OCST und SLT, bestanden und 70 sind durchgefallen. 25 Geräte oder DUTs sind durch den OCST-Test durchgefallen, haben jedoch den SLT-Test bestanden, während lediglich 5 DUTs den OCST-Test bestanden haben und durch den SLT-Test durchgefallen sind.
Mit anderen Worten übersieht OCST bei dem obigen Beispiel 5 Geräte, die durch SLT durchfallen, findet jedoch Probleme in 25 DUTs, die SLT nicht gefunden hat, was unter der Annahme, dass alle Testschritte realistische Szenarien mit realistischen Testparameterwerten beschreiben, eine gute Balance darstellt.
Traininqstabelle, die Testergebnisse mit SLT-Ergebnissen kombiniert, gemäß Fig. 10
10 zeigt eine Trainingstabelle 1000, die die gesammelten Testdaten mit den SLT-Ergebnissen kombiniert. Die Trainingstabelle 1000 ist dazu konfiguriert, als Trainingstabelle oder Trainingsdatensatz für ein Maschinelles-Lernen-Modul oder Kl-Modul verwendet zu werden. Die Trainingstabelle 1000 kann alle Testaktivitäten, Testressourcen und Testergebnisse von Testschritten, die auf DUTs mit entsprechenden SLT-Ergebnissen ausgeführt werden, aufweisen. Die Trainingstabelle 1000 kann mehrere Testschritte aufweisen, die auf mehreren DUTs ausgeführt werden.
Die Trainingstabelle 1000 kann Testdaten aufweisen, die außerhalb oder leicht außerhalb der Spezifikation der DUTs kombiniert mit SLT-Ergebnissen gesammelt werden, wobei die SLT-Tests in der Spezifikation der DUTs ausgeführt wurden. Beispielsweise ist in diesem Fall ein durchgefallenes OCST-Ergebnis nicht als starkes Zeichen eines durchgefallenen DUT angesehen, jedoch kann ein bestandener OCST-Test außerhalb der Spezifikationsbegrenzungen als starkes Zeichen eines guten DUT angesehen werden und kann zur Folge haben, dass das DUT als qualitativ hochwertiges DUT klassifiziert wird.
Die ATE oder die Steuerung kann eine Maschinelles-Lernen-Einheit oder ein KI-Modul aufweisen, die bzw. das durch die Trainingstabelle 1000 trainiert werden kann und dazu konfiguriert sein kann, das SLT-Ergebnis aus einem neu ausgeführten Testschritt auf einem DUT vorherzusagen. Die Maschinelles-Lernen-Einheit kann dazu verwendet werden, diesen Testprozess zu verbessern.
Traininqstabelle mit Testergebnissen gemäß Fig. 11
11 zeigt eine Trainingstabelle 1100, die die gesammelten Testdaten und die gesamten OCST-Ergebnisse aufweist. Die Trainingstabelle 1100 ist dazu konfiguriert, als Trainingstabelle oder Trainingsdatensatz für ein Maschinelles-Lernen-Modul oder Kl-Modul verwendet zu werden. Die Trainingstabelle 1100 kann Testaktivitäten, Testressourcen und Testergebnisse von Testschritten, die auf DUTs mit entsprechenden Gesamt-OCST-Ergebnissen ausgeführt werden, aufweisen.
Die Tabelle 1100 wird zum Zweck der Fehlerkorrektur und Diagnose verwendet. Eine allgemeine Idee der Fehlerbehebung besteht darin, diejenigen Testparameter zu identifizieren, die das Auftreten von OCST-Ausfällen am stärksten beeinflussen. Die ATE oder die Steuerung kann die Kl- oder Maschinelles-Lernen-Einheit aufweisen, um häufig durchfallende DUT-Ressourcen oder DUTs zu identifizieren und/oder zu klassifizieren. Aus Gründen der Effizienz kann die Tabelle auf durchfallende Geräte beschränkt sein. Die Analysatoren können über mehrere DUTs ausgeführt werden, um häufig auftretende Fehlermechanismen zu identifizieren.
Die Maschinelles-Lernen-Einheit oder das Maschinelles-Lernen-Modul kann durch die Testergebnistabelle 1100 trainiert werden, um das durchfallende DUT oder die durchfallende DUT-Ressourcen vorauszusagen.
I mplementierungsalternativen
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, wobei ein Block oder ein Bauelement einem Verfahrensschritt oder einem Merkmal eines Verfahrensschrittes entspricht. Analog dazu stellen Aspekte, die im Zusammenhang mit einem Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Elementes oder Merkmals einer entsprechenden Vorrichtung dar.
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray-Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken (oder zusammenwirken können), dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.
Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahingehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft. Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist.
Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.
Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist. Der Datenträger, das digitale Speichermedium oder das computerlesbare Medium sind typischerweise gegenständlich und/oder nichtvergänglich bzw. nichtvorübergehend.
Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise konfiguriert sein, um über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die konfiguriert oder angepasst ist, um eines der hierin beschriebenen Verfahren durchzuführen.
Ein weiteres Ausführungsbeispiel weist einen Computer auf, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das konfiguriert ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen (beispielsweise elektronisch oder optisch). Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder dergleichen sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.
Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt
Die hierin beschriebenen Vorrichtungen können beispielsweise unter Verwendung einer Hardware-Vorrichtung, oder unter Verwendung eines Computers, oder unter Verwendung einer Kombination einer Hardware-Vorrichtung und eines Computers implementiert werden.
Die hierin beschriebenen Vorrichtungen, oder jedwede Komponenten der hierin beschriebenen Vorrichtungen können zumindest teilweise in Hardware und/oder in Software implementiert sein.
Die hierin beschriebenen Verfahren können beispielsweise unter Verwendung einer Hardware-Vorrichtung, oder unter Verwendung eines Computers, oder unter Verwendung einer Kombination einer Hardware-Vorrichtung und eines Computers implementiert werden.
Die hierin beschriebenen Verfahren, oder jedwede Komponenten der hierin beschriebenen Verfahren können zumindest teilweise durch Hardware und/oder durch Software ausgeführt werden.

Claims

Eine automatische Testeinrichtung (110, 220) zum Testen eines oder mehrerer zu testender Geräte (120, 282), wobei die automatische Testeinrichtung dazu konfiguriert ist, ein oder mehrere Testszenarien (140a-c, 262) zu erzeugen, die eine Mehrzahl von Testaktivitäten (150a-c, 212, 212a-d) aufweisen; wobei unterschiedliche Testaktivitäten Teilsätze von Ressourcen des zu testenden Geräts (130a-e, 214) nutzen; wobei die automatische Testeinrichtung dazu konfiguriert ist, die Mehrzahl von Testszenarien derart zu erzeugen, dass Ressourcen des zu testenden Geräts, die einer Mehrzahl von Testaktivitäten eines Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen.
Die automatische Testeinrichtung gemäß Anspruch 1, wobei die Mehrzahl von Testaktivitäten eines gegebenen Testszenarios dazu konfiguriert ist, gleichzeitig ausgeführt zu werden.
Die automatische Testeinrichtung gemäß Anspruch 1 oder 2, wobei eine oder mehrere der Testaktivitäten zu einem oder mehreren Testparametern (216, 216a-e) zugeordnet sind, die durch jeweilige Testparameterwerte charakterisiert sind, und/oder zu einer oder mehreren Einschränkungen (218) zugeordnet sind.
Die automatische Testeinrichtung gemäß einem der vorhergehenden Ansprüche, wobei eine oder mehrere der Testaktivitäten durch einen oder mehrere Testparameterwerte außerhalb vordefinierter Begrenzungen charakterisiert sind.
Die automatische Testeinrichtung gemäß einem der vorhergehenden Ansprüche, wobei die Mehrzahl von Testaktivitäten aus einem Testszenario zufällig ausgewählt wird, unter den Einschränkungen, dass Ressourcen des zu testenden Geräts, die der Mehrzahl von Testaktivitäten des Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen.
Die automatische Testeinrichtung gemäß einem der vorhergehenden Ansprüche, wobei die automatische Testeinrichtung einen Einschränkungslöser (250) zum Erzeugen von Testszenarien aufweist, um ein Auftreten von Konflikten zwischen den Ressourcen des zu testenden Geräts zu verhindern.
Die automatische Testeinrichtung gemäß einem der vorhergehenden Ansprüche, wobei eine oder mehrere der Testaktivitäten ein Aktivieren eines Belastungsgenerators, der auf dem zu testenden Gerät angeordnet ist, aufweisen.
Die automatische Testeinrichtung gemäß einem der vorhergehenden Ansprüche, wobei die automatische Testeinrichtung dazu konfiguriert ist, eine Testsequenz von Testszenarien zu erzeugen.
Die automatische Testeinrichtung gemäß Anspruch 8, wobei die Testsequenz zwei oder mehr Szenarien mit denselben Testaktivitäten aufweist, wobei die Testszenarien sich um zumindest einen Testparameterwert unterscheiden.
Die automatische Testeinrichtung gemäß Anspruch 8 oder 9, wobei die Mehrzahl von Testszenarien der Testsequenz zufällig ausgewählt und/oder geordnet wird.
Die automatische Testeinrichtung gemäß einem der Ansprüche 7 bis 10, wobei die automatische Testeinrichtung dazu konfiguriert ist, die Testsequenz derart zu erzeugen, dass die Testsequenz dazu konfiguriert ist, durch eine Steuerung (270) ausgeführt zu werden, um Testdaten zu sammeln.
Die automatische Testeinrichtung gemäß Gruppe 11, wobei die Steuerung ein Auf-Chip-Prozessor oder eine Steuerungskarte ist, die dazu konfiguriert ist, mit der automatischen Testeinrichtung und mit dem zu testenden Gerät zu kommunizieren.
Die automatische Testeinrichtung gemäß Anspruch 11 oder 12, wobei die Steuerung eine oder mehrere Schnittstellen aufweist, die dazu konfiguriert sind, Daten des zu testenden Geräts und/oder Sensordaten des zu testenden Geräts auszulesen.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 13, wobei die Steuerung einen oder mehrere Sensoren aufweist, die über die Fläche des zu testenden Geräts verteilt sind, so dass die Steuerung dazu konfiguriert ist, Sensortestdaten des einen oder der mehreren Sensoren auszulesen.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 14, wobei die Steuerung dazu konfiguriert ist, zu reagieren, falls die gesammelten Testdaten (280) eine vorbestimmte Bedingung erfüllen.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 15, wobei die Steuerung dazu konfiguriert ist, die gesammelten Testdaten an die automatische Testeinrichtung zu kommunizieren.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 16, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, Testparameterwerte auf der Basis der Testaktivitätseinschränkungen und/oder auf der Basis der gesammelten Testdaten dynamisch zu erzeugen.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 17, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, die gesammelten Testdaten zu analysieren, um Testsequenzen zu optimieren.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 18, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, Ergebnisse von Tests auf Systemebene in den vordefinierten Begrenzungen mit den gesammelten Testdaten innerhalb und/oder außerhalb der vordefinierten Begrenzungen zu vergleichen, um Testsequenzen zu optimieren.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 19, wobei die automatische Testeinrichtung eine Künstliche-Intelligenz-Einheit oder eine Maschinelles-Lernen-Einheit aufweist, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, die Künstliche-Intelligenz-Einheit oder die Maschinelles-Lernen-Einheit mit Ergebnissen von Tests auf Systemebene und/oder mit den gesammelten Testdaten und/oder mit dem Vergleich der Tests auf Systemebene und den gesammelten Testdaten zu trainieren, um Testsequenzen zu optimieren.
Die automatische Testeinrichtung gemäß Anspruch 20, wobei die trainierte Künstliche-Intelligenz-Einheit oder Maschinelles-Lernen-Einheit dazu konfiguriert ist, die Ergebnisse von Tests auf Systemebene auf der Basis der gesammelten Testdaten vorherzusagen.
Die automatische Testeinrichtung gemäß einem der Ansprüche 11 bis 21, wobei die Steuerung oder die automatische Testeinrichtung dazu konfiguriert ist, die gesammelten Testdaten zu analysieren, um ein Testergebnis zu erhalten.
Die automatische Testeinrichtung gemäß einem der Ansprüche 17 bis 22, wobei die trainierte Künstliche-Intelligenz-Einheit oder Maschinelles-Lernen-Einheit dazu konfiguriert ist, die gesammelten Testdaten zu analysieren, um Testsequenzen zu optimieren und/oder Testergebnisse zu erhalten.
Ein Prozess zum Testen eines oder mehrerer zu testender Geräte durch eine automatische Testeinrichtung, wobei die automatische Testeinrichtung ein oder mehrere Testszenarien erzeugt, die eine Mehrzahl von Testaktivitäten aufweisen, wobei unterschiedliche Testaktivitäten Teilsätze von Ressourcen des zu testenden Geräts nutzen; wobei die automatische Testeinrichtung die Mehrzahl von Testszenarien derart erzeugt, dass Ressourcen des zu testenden Geräts, die einer Mehrzahl von Testaktivitäten eines Testszenarios zugeordnet sind, nicht miteinander in Konflikt stehen.
Ein Computerprogramm zum Implementieren des Verfahrens gemäß Anspruch 24, wenn dasselbe auf einem Computer oder Signalprozessor abläuft.