DE112020000469T5 - Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet - Google Patents

Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet Download PDF

Info

Publication number
DE112020000469T5
DE112020000469T5 DE112020000469.4T DE112020000469T DE112020000469T5 DE 112020000469 T5 DE112020000469 T5 DE 112020000469T5 DE 112020000469 T DE112020000469 T DE 112020000469T DE 112020000469 T5 DE112020000469 T5 DE 112020000469T5
Authority
DE
Germany
Prior art keywords
test
chip system
automated
interface
software
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112020000469.4T
Other languages
English (en)
Inventor
Olaf Pöppe
Klaus-Dieter Hilliges
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advantest Corp
Original Assignee
Advantest Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advantest Corp filed Critical Advantest Corp
Publication of DE112020000469T5 publication Critical patent/DE112020000469T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31724—Test controller, e.g. BIST state machine
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31712—Input or output aspects
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31712—Input or output aspects
    • G01R31/31713—Input or output interfaces for test, e.g. test pins, buffers
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3177—Testing of logic operation, e.g. by logic analysers
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31905—Interface with the device under test [DUT], e.g. arrangements between the test head and the DUT, mechanical aspects, fixture
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31908—Tester set-up, e.g. configuring the tester to the device under test [DUT], down loading test patterns
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31917—Stimuli generation or application of test patterns to the device under test [DUT]
    • G01R31/31919—Storing and outputting test patterns
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31917—Stimuli generation or application of test patterns to the device under test [DUT]
    • G01R31/31926—Routing signals to or from the device under test [DUT], e.g. switch matrix, pin multiplexing
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/3193—Tester hardware, i.e. output processing circuits with comparison between actual response and known fault free response
    • G01R31/31935—Storing data, e.g. failure memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/273—Tester hardware, i.e. output processing circuits
    • G06F11/2733—Test interface between tester and unit under test
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Microcomputers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Eine automatisierte Testeinrichtung zum Testen eines Testobjekts weist ein Auf-Chip-System-Teststeuergerät auf. Das Auf-Chip-System-Teststeuergerät weist zumindest eine Debug-Schnittstelle oder Steuerschnittstelle auf, die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren. Das Auf-Chip-System-Teststeuergerät weist optional zumindest eine Schnittstelle mit hoher Bandbreite auf, die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren. Das Auf-Chip-System-Teststeuergerät ist dazu konfiguriert, einen Test eines Testobjekts zu steuern, bei dem es sich um ein Ein-Chip-System handelt.

Description

  • Technisches Gebiet
  • Ausführungsbeispiele gemäß der vorliegenden Erfindung schaffen eine automatisierte Testeinrichtung.
  • Allgemein gesprochen schaffen Ausführungsbeispiele gemäß der Erfindung eine wirksame Testumgebung für Auf-Chip-System-Tests.
  • Weitere Ausführungsbeispiele gemäß der Erfindung schaffen einen Auf-Chip-System-Test.
  • Hintergrund der Erfindung
  • Im Folgenden werden einige technische Gebiete beschrieben, auf denen Ausführungsbeispiele gemäß der vorliegenden Erfindung verwendet werden können.
  • In den vergangenen Jahren gab es eine zunehmende Nachfrage nach einem Testen von Ein-Chip-Systemen (systems-on-a-chip, SOCs), Ein-Gehäuse-Systemen (systems-in-a-package, SIT) oder Modulen mit zumindest einem integrierten Prozessor. Es ist festzustellen, dass die folgende Offenbarung lediglich „SOC“ oder „DUT“ (device under test, Testobjekt) aufführt, aber auf höhere Integrationsebenen in einem Gehäuse oder auf jede Art von Modul anwendbar ist, das ein (Teil-)System implementiert.
  • Nachfolgend werden einige Trends bezüglich Ein-Chip-Systemen (SoC oder SOC) beschrieben. In letzter Zeit gibt es den Trend, dass Kerne von zentralen Verarbeitungseinheiten (CPU-Kerne) überall zu finden sind. Beispielsweise ist festzustellen, dass im vergangenen Jahr etwa 17 Milliarden Einheiten mit CPU-Kernen von ARM ausgeliefert wurden. Außerdem gibt es einen Trend, dass sich das reine Hardware-Design zum Hardware-/Software-Codesign wandelt.
  • Darüber hinaus gibt es einen Trend, dass IP-Ressourcen weit verbreitet sind. Dies ermöglicht zum Beispiel eine extrem hohe Integration auf neuen Prozessknoten. Darüber hinaus werden zum Beispiel gängige Auf-Chip-Verbindungs-Architekturen etabliert, um diesen Trend zu unterstützen. Ein weit verbreiteter Standard für diese Verbindungen ist beispielsweise AMBA für ARM.
  • Außerdem besteht ein Trend, dass mobile Anwendungen fortschrittliche Leistungsverwaltungstechnologien antreiben. Zum Beispiel ist es wünschenswert, Kerne mit optimalen Taktraten und Versorgungsspannungen auszuführen. Darüber hinaus ist es wünschenswert, Taktbereiche und Versorgungsspannungen dynamisch zu ändern. Weiterhin ist es wünschenswert, ungenutzte Kerne dynamisch abzuschalten.
  • Darüber hinaus gibt es einen Trend zu einer erhöhten Anzahl von Multi-Chip-Modul-Angeboten. Beispielsweise vereinfacht eine reduzierte Anzahl von Pins auf der Modulschnittstelle das Design einer gedruckten Schaltungsplatine (PCB-Design). Darüber hinaus ermöglichen 2½D- und 3D-Packaging-Technologien beispielsweise kleinere Formfaktoren für mobile Anwendungen.
  • Im Folgenden wird eine Anatomie eines typischen SoC kurz beschrieben. Es ist festzustellen, dass ein derartiges Ein-Chip-System beispielsweise unter Verwendung der hierin offenbarten Konzepte getestet werden kann.
  • 4 zeigt ein Blockschema eines Ein-Chip-Systems. Das System ist in seiner Gesamtheit mit 400 bezeichnet. Das System weist zum Beispiel einen Kern einer Zentralverarbeitungseinheit (CPU-Kern) 410, einen statischen Direktzugriffsspeicher (static random access memory, SRAM) 404, einen L2-Cache 408, einen nichtflüchtigen Direktzugriffsspeicher (nonvolatile random access memory, NVRAM) 412 und einen Nur-Lese-Speicher 416 auf. Der CPU-Kern 410, der SRAM, der L2-Cache, der NVRAM und der ROM können beispielsweise alle mit einer asynchronen Anwendungsverbindung 420 gekoppelt sein.
  • Darüber hinaus kann das System einen Zugriffsblock 430 für Debug (Fehlerbehebung)/ Design-for-Test (DFT, testgerechtes Design), einen Peripherieblock 440 und einen Coprozessor 450 aufweisen. Der Peripherieblock 440 und der Coprozessor 450 können beispielsweise auch seitens der asynchronen Anwendungsverbindung 420 gekoppelt sein.
  • Des Weiteren ist festzustellen, dass der Debug/DFT-Zugriffsblock 430 auch mit der asynchronen Anwendungsverbindung 420 gekoppelt sein kann, um Daten an jeden der Blöcke zu übertragen, die mit der asynchronen Anwendungsverbindung verbunden sind.
  • Des Weiteren können der CPU-Kern 410 und der Debug/DFT-Zugriffsblock 430 außerdem mit einer asynchronen Debug-Verbindung 460 gekoppelt sein. Der Peripherieblock 440 und der Coprozessor 450 können optional ebenfalls mit der asynchronen Debug-Verbindung 460 gekoppelt sein.
  • Ein Debug/DFT-Zugriffsblock 430 kann zum Beispiel mit einem dedizierten Eingang/Ausgang (input/output, I/O) für Debug-Zugriff gekoppelt sein. Der dedizierte Eingang/Ausgang für Debug-Zugriff kann beispielsweise eine JTAG-Schnittstelle oder Serial-Wire-Debug(SWD)-Schnittstelle sein.
  • Darüber hinaus weist das System 400 optional einen Eingang/Ausgang-Multiplexer (input/output multiplexer, I/O-Multiplexer) 470 auf, der zum Bestimmen konfiguriert sein kann, welche Eingangs-/Ausgangs-Leitungen des SoC 400 mit welchen Pins eines Gehäuses des SoC 400 verbunden sind. Beispielsweise kann das System 400 einen gemeinschaftlich verwendeten Eingang/Ausgang für Niedriggeschwindigkeits-Digital, Abtasten (z. B. Scan-Ketten zum Lesen und/oder Einstellen eines Registers) und Trace-Ausgabe aufweisen. Es ist jedoch festzustellen, dass es einen dedizierten Eingang/Ausgang für Debug-Zugriff geben kann und dass es außerdem einen dedizierten Eingang/Ausgang für analoge Signale, Hochfrequenz(HF)-Signale und/oder digitale Hochgeschwindigkeitssignale geben kann, die durch den einen oder die mehreren Peripherieblöcke 440 bereitgestellt und/oder durch den einen oder die mehren Peripherieblöcke 440 empfangen werden.
  • Des Weiteren ist festzustellen, dass der I/O-Multiplexer 470 beispielsweise mit dem Debug/DFT-Zugriffsblock gekoppelt sein kann, wobei der Debug/DFT-Zugriffsblock 430 beispielsweise die Funktionalität des I/O-Multiplexers steuern kann. Es kann jedoch auch ein Routing eines oder mehrerer Signale von oder zu dem Debug/DFT-Zugriffsblock 430 durch den I/O-Multiplexer 470 bestimmt werden.
  • Darüber hinaus ist festzustellen, dass es einen Abtastzugriff auf Signale (zum Beispiel auf Registerinhalte) innerhalb eines oder mehrerer der SoC-Blöcke geben kann, zum Beispiel auf Signale innerhalb des CPU-Kerns 410, auf Signale innerhalb des einen oder der mehreren Peripherieblöcke 440 und auf Signale innerhalb des einen oder der mehreren Coprozessoren 450. Der Abtastzugriff kann es beispielsweise ermöglichen, dass Signale (zum Beispiel Registerinhalte) in den Blöcken festgelegt werden und/oder Signale (z. B. von Registerinhalten) aus den Blöcken ausgelesen werden. Der Abtastzugriff kann beispielsweise durch den Debug/DFT-Zugriffsblock 430 gesteuert werden oder kann alternativ durch eines oder mehrere andere Signale gesteuert werden.
  • Es ist jedoch festzustellen, dass der SoC 400 lediglich als Beispiel zu betrachten ist.
  • 5 zeigt eine Anatomie eines typischen Moduls. Anders gesagt zeigt 5 ein Blockschema eines Moduls 500, das gemäß den hierin erörterten Konzepten oder durch die hierin offenbarte automatisierte Testeinrichtung getestet werden kann.
  • Das Modul 500 kann beispielsweise dem in Hinblick auf 4 beschriebenen SoC 400 ähnlich sein, so dass gleiche oder entsprechende Blöcke hier nicht erneut beschrieben werden. Vielmehr wird auf die obigen Erläuterungen Bezug genommen.
  • Das Modul 500 weist zum Beispiel einen CPU-Kern 510, einen SRAM 504, einen L2-Cache 508, einen nichtflüchtigen Direktzugriffsspeicher 512, einen Nur-Lese-Speicher 516, eine asynchrone Anwendungsverbindung 520, einen Debug/DFT-Zugriffsblock 530, einen oder mehrere Peripherieblöcke 540, einen oder mehrere Coprozessoren 550 und eine asynchrone Debug-Verbindung 560 auf. Die Blöcke 510, 504, 508, 512, 516, 520, 530, 540, 550, 560 können den Blöcken 410, 404, 408, 412, 416, 420, 430, 440, 450, 460 entsprechen.
  • Es ist jedoch zu festzustellen, dass das Modul 512 in einigen Fällen möglicherweise keinen Eingang/Ausgang-Multiplexer aufweist.
  • Andererseits weist das Modul 500 optional eine oder mehrere Host-Schnittstellen 580, eine oder mehrere Speichersteuerungen 584 und einen oder mehrere Flash-Steuerungen 588 auf. Die eine oder die mehreren Host-Schnittstellen 580 können beispielsweise mit der asynchronen Anwendungsverbindung 520 gekoppelt sein und können beispielsweise externe Schnittstellen mit hoher Bandbreite für das Modul (wie beispielsweise eine PCle-Schnittstelle, eine USB-Schnittstelle oder eine SDIO-Schnittstelle) bereitstellen. Der eine oder die mehreren Speichersteuerungen können beispielsweise mit der asynchronen Anwendungsverbindung 520 gekoppelt sein und können außerdem mit einem dynamischen Direktzugriffsspeicher (DRAM) gekoppelt sein. Dementsprechend kann der eine oder die mehreren Speichersteuerungen 584 einen vergleichsweise großen Speicher zur Verwendung durch den CPU-Kern bereitstellen.
  • Darüber hinaus kann der eine oder die mehreren Flash-Steuerungen 588 mit der asynchronen Anwendungsverbindung 520 gekoppelt sein und kann außerdem mit einem Flash-Speicher (z. B. NAND-Flash) gekoppelt sein. Dementsprechend kann der CPU-Kern 510 in der Lage sein, über den einen oder die mehreren Flash-Steuerungen 588 auf einen Flash-Speicher zuzugreifen.
  • Darüber hinaus ist festzustellen, dass die eine oder die mehreren Host-Schnittstellen 580, der eine oder die mehreren Speichersteuerungen 584 und der eine oder die mehreren Flash-Steuerungen 588 optional auch mit der asynchronen Debug-Verbindung 560 gekoppelt sein können, was beispielsweise ein Festlegen oder Debuggen von internen Signalen (oder internen Zuständen) der Blöcke 580, 584, 588 ermöglichen kann, was durch den Debug/DFT-Zugriffsblock 530 gesteuert werden kann.
  • Es hat sich jedoch herausgestellt, dass Testen und Validierung von SOCs eine Reihe von Herausforderungen mit sich bringt.
  • Zum Beispiel hat sich herausgestellt, dass asynchrone Kommunikationsfehler durch AC-Abtasten nicht ausreichend abgedeckt werden. Vielmehr hat sich herausgestellt, dass asynchrone Kommunikationskanäle funktional getestet werden sollten (oder in einigen Fällen sogar getestet werden müssen).
  • Darüber hinaus hat sich außerdem herausgestellt, dass Fehler in der dynamischen Leistungsverwaltung durch AC-Abtasten ebenfalls nicht ausreichend abgedeckt werden. Es wurde der Schluss gezogen, dass eine Auf-Chip-Leistungsverwaltung funktional getestet werden sollte (oder in einigen Fällen sogar getestet werden muss) (möglicherweise durch parametrisches DFT unterstützt).
  • Darüber hinaus hat sich herausgestellt, dass aufgrund der Komplexität und der asynchronen Strukturen die Reaktionen einer Vorrichtung nur mit Hilfe von Verhaltensmodellen bewertet werden können. Es hat sich außerdem herausgestellt und die Schlussfolgerung ergeben, dass eine herkömmliche ATE-Funktionsstruktur nicht mehr greift.
  • Darüber hinaus hat sich herausgestellt, dass als Ergebnis eine zunehmende Abdeckungslücke besteht. Es wurde geschlussfolgert, dass ATE-Tests durch Systemebenentests ergänzt werden, die die Anwendungsumgebung und -software nutzen.
  • Außerdem hat sich herausgestellt, dass mit der Anwendungsumgebung und -software nicht alle Ausnahmefälle abgedeckt werden. Es wurde geschlussfolgert, dass nach dem Systemebenentest (system level test, SLT) immer noch eine Abdeckungslücke besteht.
  • Es hat sich außerdem herausgestellt, dass Softwarefehler (software bugs) durch Design-Marginalisierungen aktiviert werden können. Es wurde geschlussfolgert, dass es nicht ausreicht, einige Stichproben der Post-Silizium-Validierung (post silicon validation) zu unterziehen, um alle relevanten Hardware- und Softwareprobleme zu finden.
  • Abschließend hat sich herausgestellt, dass es einen Bedarf an verbesserten Konzepten zum Testen von Ein-Chip-Systemen gibt.
  • Kurzdarstellunq der Erfindung
  • Ein Ausführungsbeispiel gemäß der Erfindung schafft eine automatisierte Testeinrichtung zum Testen eines Testobjekts (z. B. eines von Ein-Chip-Systems), wobei die automatisierte Testeinrichtung ein Auf-Chip-System-Teststeuergerät aufweist.
  • Das Auf-Chip-System-Teststeuergerät weist zumindest eine Debug-Schnittstelle oder Steuerschnittstelle auf (z. B. JTAG, SWD, SPI, I2C, UART), die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren. Das Auf-Chip-System-Teststeuergerät weist vorzugsweise, jedoch nicht unbedingt erforderlich, zumindest eine Schnittstelle mit hoher Bandbreite auf (z. B. USB oder PCI), die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren, und das Auf-Chip-System-Teststeuergerät ist dazu konfiguriert, einen Test (z. B. ein Hochladen eines Programms und/oder ein Ausführen eines oder mehrerer Abschnitte eines Testprogramms und/oder ein Erhalten von Ergebnisdaten und/oder ein Debugging) eines Testobjekts zu steuern, bei dem es sich um ein Ein-Chip-System handelt (z. B. um ein eher einfaches Testobjekt mit einem einzelnen eingebetteten Prozessor oder eine komplexe Vorrichtung mit mehreren Kernen). Es ist festzustellen, dass Ausführungsbeispiele gemäß der Erfindung für ein Testen mehrerer unterschiedlicher Testobjekttypen verwendet werden kann, solange dieselben einen eingebetteten Prozessor aufweisen, was sowohl eher einfache Vorrichtungen mit einem eingebetteten Prozessor (d. h. einfache SoCs) als auch Vorrichtungen mit mehreren Kernen (d. h. komplexe SoCs) umfasst.
  • Diese automatisierte Testeinrichtung basiert auf der Erkenntnis, dass ein Ein-Chip-System oder ein Modul mit einem guten Kompromiss zwischen Testaufwand, Testabdeckung und Testgeschwindigkeit unter Verwendung einer automatisierten Testeinrichtung getestet werden kann, die ein dediziertes Auf-Chip-System-Teststeuergerät aufweist, der dahingehend angepasst ist, mit dem Testobjekt sowohl über eine Debug-Schnittstelle oder Steuerschnittstelle als auch optional über eine Schnittstelle mit hoher Bandbreite zu kommunizieren (wobei festzustellen ist, dass viele Aspekte der Erfindung ohne eine HSIO implementiert werden können und funktionieren werden, wobei die gesamte Steuerung über Debug-Schnittstellen und/oder Steuerschnittstellen erfolgt).
  • Durch ein derartiges dediziertes Auf-Chip-System-Teststeuergerät ist es beispielsweise möglich, sowohl die Fähigkeiten der Debug-Schnittstelle oder Steuerschnittstelle des Testobjekts als auch die Geschwindigkeitsvorteile der Schnittstelle mit hoher Bandbreite zu nutzen, während Engpässe vermieden werden, die bei herkömmlichen Testgerätkonfigurationen auftreten können.
  • Beispielsweise ist es unter Verwendung der Debug-Schnittstelle oder Steuerschnittstelle möglich, sehr grundlegende Anpassungen (z. B. von CPU-Registerinhalten oder Speicherinhalten) an dem Testobjekt vorzunehmen, ohne auf irgendeine Software auf dem Testobjekt zurückzugreifen.
  • Im Gegensatz dazu ermöglicht die optionale Schnittstelle mit hoher Bandbreite einen sehr schnellen Datenaustausch zwischen der automatisierten Testeinrichtung und dem Testobjekt, wobei typischerweise ein Betriebssystem oder eine Treibersoftware, die auf dem Testobjekt ausgeführt wird, die Kommunikation unterstützt.
  • Dementsprechend kann die automatisierte Testeinrichtung, die das Auf-Chip-System-Teststeuergerät aufweist, grundlegende Hardwaretests, die zum Beispiel unter Verwendung einer Abtastkette des Testobjekts durchgeführt werden können, und Systemebenentests, bei denen ein Austausch einer großen Datenmenge zwischen dem Testobjekt und der automatisierten Testeinrichtung stattfindet, effizient durchführen. Die Debug-Schnittstelle kann zum Beispiel dazu verwendet werden, Tests zu konfigurieren und einen grundlegenden Testablauf zu steuern. Bei einem einfachen Ausführungsbeispiel, bei dem es keine Schnittstelle mit hoher Bandbreite gibt, kann die Debug-Schnittstelle auch dazu verwendet werden, größere Testprogramme und/oder Testdaten und/oder Testparameter über die Debug-Schnittstelle oder Steuerschnittstelle hochzuladen.
  • Falls das Auf-Chip-System-Teststeuergerät jedoch auch die optionale Schnittstelle mit hoher Bandbreite aufweist, können größere Testprogramme und/oder Testdaten über die Schnittstelle mit hoher Bandbreite kommuniziert werden, wodurch die Testeffizienz erhöht und die Testzeit reduziert wird.
  • Es ist an dieser Stelle festzustellen, dass die Schnittstelle mit hoher Bandbreite beispielsweise in der Lage sein kann, eine Datenrate zu verarbeiten, die zumindest 10-mal höher als eine (maximale) Datenrate der Debug-Schnittstelle oder der Steuerschnittstelle ist und die in einigen Fällen sogar zumindest 100-mal schneller als eine (maximale) Datenrate sein kann, die seitens der Debug-Schnittstelle oder der Steuerschnittstelle verarbeitet wird. Jedoch ist das dedizierte Auf-Chip-System-Teststeuergerät typischerweise so konzipiert, dass derselbe die sehr hohen Datenraten der Schnittstelle mit hoher Bandbreite problemlos verarbeiten kann, während derselbe über die Debug-Schnittstelle oder die Steuerschnittstelle immer noch „vollen Zugriff“ auf das Testobjekt hat.
  • Bei einem bevorzugten Ausführungsbeispiel ist die automatisierte Testeinrichtung dazu konfiguriert, die Debug-Schnittstelle oder die Steuerschnittstelle oder die Schnittstelle mit hoher Bandbreite variabel einer Testobjektschnittstelle zuzuweisen.
  • Durch variables Zuweisen der Debug-Schnittstelle oder der Steuerschnittstelle oder der Schnittstelle mit hoher Bandbreite zu einer Testobjektschnittstelle ist die automatisierte Testeinrichtung dazu konfigurierbar, beliebige Testobjekte und/oder beliebige Loadboards zu verarbeiten. Zum Beispiel kann die automatisierte Testeinrichtung so gestaltet sein, dass es möglich ist, die Debug-Schnittstelle oder die Steuerschnittstelle unterschiedlichen Pins einer Testobjektschnittstelle zuzuweisen (z. B. unter der Steuerung von Testkonfigurationsinformationen), und die automatisierte Testeinrichtung kann außerdem dahingehend angepasst sein, die Schnittstelle mit hoher Bandbreite unterschiedlichen Pins der Testobjektschnittstelle zuzuweisen (z. B. unter der Steuerung von Testkonfigurationsinformationen). Auf diese Weise wird ein hohes Maß an Flexibilität erreicht.
  • Bei einem bevorzugten Ausführungsbeispiel ist die automatisierte Testeinrichtung dazu konfiguriert, eine oder mehrere parametrische Testressourcen variabel dem Testobjekt zuzuweisen.
  • Durch variables Zuweisen einer oder mehrerer parametrischer Testressourcen zu dem Testobjekt, z. B. unter der Steuerung des Auf-Chip-System-Teststeuergeräts, kann eine Testabdeckung erheblich erhöht werden.
  • Die eine oder die mehreren parametrischen Testressourcen können beispielsweise eine oder mehrere einstellbare Leistungsversorgungen der Vorrichtung und/oder eine oder mehrere einstellbare Taktquellen aufweisen. Dementsprechend kann das Testobjekt über einen sehr weiten Bereich von Bedingungen getestet werden, was es ermöglicht, eine große Anzahl von Fehlern oder Problemen des Testobjekts zu identifizieren. Darüber hinaus kann die eine oder die mehreren parametrischen Testressourcen außerdem Signalgeneratoren aufweisen, die zum Beispiel dem Testobjekt analoge Signale oder Hochfrequenzsignale unter Verwendung von einstellbaren Parametern bereitstellen können. Dementsprechend kann das Testobjekt mit verschiedenen Stimuli unter der Steuerung des Auf-Chip-System-Teststeuergeräts getestet werden, der einen Testablauf unter Verwendung der Debug-Schnittstelle oder der Steuerschnittstelle und auch unter Verwendung der Schnittstelle mit hoher Bandbreite steuern kann. Darüber hinaus kann die eine oder die mehreren parametrischen Testressourcen außerdem eine oder mehrere Messvorrichtungen aufweisen, die analoge Eigenschaften von Signaleingängen des Testobjekts und/oder von Signalausgängen des Testobjekts und/oder von Signalen, die durch das Testobjekt erzeugt werden, charakterisieren können. Dementsprechend kann das Auf-Chip-System-Teststeuergerät beispielsweise ein Hochladen von Testprogrammen in das Testobjekt, ein Ausführen von Testprogrammen auf dem Testobjekt und außerdem eine Variation von Betriebsbedingungen (beispielsweise einer Versorgungsspannung oder einer Taktfrequenz) des Testobjekts steuern. Auf diese Weise können die Auswirkungen von geänderten Betriebsbedingungen auf das Testobjekt untersucht werden, und analoge (parametrische) Testergebnisse können synchron zu der Ausführung eines Testprogramms auf dem Testobjekt erhalten werden.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, einen Softwarestapel auszuführen, der ein Betriebssystem, eine Auf-Chip-System-Testdienstsoftware und einen oder mehrere Treiber zum Kommunizieren mit dem Testobjekt über die Schnittstellen aufweist.
  • Durch die Verwendung eines Betriebssystems, einer Auf-Chip-System-Testdienstsoftware und von Treibern zum Kommunizieren mit dem Testobjekt über die Schnittstellen kann das Auf-Chip-System-Teststeuergerät sehr effizient an variierende Anforderungen angepasst werden. Die Verwendung eines Betriebssystems ermöglicht eine sehr effiziente Softwareentwicklung, und die Verwendung von Treibern zum Kommunizieren mit dem Testobjekt über die Schnittstellen bringt eine sehr hohe Leistung mit sich und ermöglicht außerdem eine Anpassung an unterschiedliche Schnittstellentypen bei moderatem Aufwand und ohne erneutes Gestalten der vollständigen Softwareumgebung.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, anwendungsspezifische Routinen durchzuführen, die durch einen Benutzer bereitgestellt werden (die z. B. über das Betriebssystem hinausgehen und die an ein bestimmtes Testobjekt angepasst sind).
  • Indem die Ausführung von anwendungsspezifischen Routinen ermöglicht wird, die durch einen Benutzer der automatisierten Testeinrichtung bereitgestellt werden können, kann dem Benutzer ein sehr hoher Freiheitsgrad geboten werden. Insbesondere kann der Benutzer nicht nur anwendungsspezifische Routinen entwickeln, die auf dem Testobjekt laufen, sondern auch anwendungsspezifische Routinen, die durch das Auf-Chip-System-Teststeuergerät ausgeführt werden. Auf diese Weise kann der Benutzer der automatisierten Testeinrichtung Routinen erzeugen, die durch das Auf-Chip-System-Teststeuergerät ausgeführt werden und die mit Routinen, die auf dem Testobjekt laufen, in Kommunikation sind, zum Beispiel unter Verwendung der Schnittstelle mit hoher Bandbreite des Auf-Chip-System-Teststeuergeräts. Auf diese Weise können Tests deutlich verbessert werden, und der Benutzer der automatisierten Testeinrichtung verfügt über einen sehr flexiblen Zugriff auf beliebige Hardwareressourcen, die durch das Auf-Chip-System-Teststeuergerät gesteuert werden.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, eine Auf-Chip-System-Testumgebung (z. B. eine Software, die eine Ausführung eines oder mehrerer Auf-Chip-System-Tests steuert, die beispielsweise Treiber für den Zugriff auf Schnittstellen des DUT bereitstellen kann) auf ein Testobjekt zu laden (z. B. über eine oder mehrere Testobjektschnittstellen). Beispielsweise ist die Auf-Chip-System-Testumgebung, z. B. ein Programm, das die Auf-Chip-System-Testumgebung implementiert, in einem Speicher des Auf-Chip-System-Teststeuergeräts gespeichert.
  • Alternativ oder zusätzlich ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, einen Auf-Chip-System-Test (z. B. ein individuelles Auf-Chip-System-Testprogramm zum Durchführen eines Testschritts aus einer Mehrzahl von Testschritten) auf ein Testobjekt zu laden (z. B. über eine oder mehrere Testobjektschnittstellen). Beispielsweise ist der Auf-Chip-System-Test, z. B. ein Programm, das den Auf-Chip-System-Test implementiert, in einem Speicher des Auf-Chip-System-Teststeuergeräts gespeichert.
  • Alternativ oder zusätzlich ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, eine Auf-Chip-System-Testumgebung auf einem Testobjekt zu initialisieren.
  • Durch Laden einer Auf-Chip-System-Testumgebung auf ein Testobjekt kann das Auf-Chip-System-Teststeuergerät das Testobjekt für das Testen konfigurieren. Beispielsweise kann die Auf-Chip-System-Testumgebung eine Software sein, die mit dem Auf-Chip-System-Teststeuergerät in Kommunikation ist, so dass das Auf-Chip-System-Teststeuergerät eine Auswirkung auf die Ausführung von Tests auf dem Testobjekt hat. Darüber hinaus ist festzustellen, dass das Hochladen einer derartigen Auf-Chip-System-Testumgebung von einem Speicher des Auf-Chip-System-Teststeuergeräts typischerweise sehr schnell ist, wobei festzustellen ist, dass die Auf-Chip-System-Testumgebung eine erhebliche Datenmenge aufweisen kann. Somit können durch direkte Nutzung des Speichers des Auf-Chip-System-Teststeuergeräts Engpässe bei einer automatisierten Testeinrichtung vermieden werden, insbesondere beim Testen mehrerer Testobjekte, da das Auf-Chip-System-Teststeuergerät typischerweise direkten Zugriff auf die Debug-Schnittstelle oder die Steuerschnittstelle und auf die Schnittstelle mit hoher Bandbreite hat. Dementsprechend kann das Auf-Chip-System-Teststeuergerät sogar die Schnittstelle mit hoher Bandbreite zum Hochladen der Auf-Chip-System-Testumgebung auf das Testobjekt verwenden.
  • Zusammenfassend lässt sich sagen, dass bei Verwendung eines derartigen Konzepts ein gleichzeitiges Testen mehrerer Testobjekte ermöglicht wird und eine enge Kooperation zwischen dem Testobjekt und dem Auf-Chip-System-Teststeuergerät erreicht werden kann.
  • In ähnlicher Weise ermöglicht das Hochladen eines einzelnen Auf-Chip-System-Tests auf das Testobjekt unter der Steuerung des Auf-Chip-System-Teststeuergeräts es, die Testprozedur feingranular anzupassen. Auf diese Weise kann das Auf-Chip-System-Teststeuergerät beispielsweise einen neuen Auf-Chip-System-Test laden (d. h. ein individuelles Auf-Chip-System-Testprogramm zum Durchführen eines Testschritts aus einer Mehrzahl von Testschritten) und optional deren Testparameter immer dann laden, wenn ein vorheriger Testschritt abgeschlossen wurde.
  • Der Auf-Chip-System-Test kann optional bestimmen, dass der Auf-Chip-System-Test bereits geladen wurde, und kann lediglich neue Testparameter für den Auf-Chip-System-Test festlegen.
  • Optional kann das Auf-Chip-System-Teststeuergerät außerdem den Auf-Chip-System-Test, die auf das Testobjekt geladen wird, gemäß vorherigen Testergebnissen dynamisch anpassen, was einen besonders gut angepassten Test ermöglicht.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät durch Initialisieren der Auf-Chip-System-Testumgebung auf dem Testobjekt das Testobjekt für das Testen vorbereiten und einen Testablauf konfigurieren. Darüber hinaus kann das Auf-Chip-System-Teststeuergerät durch Initialisieren der Auf-Chip-System-Testumgebung beispielsweise eine Zeitsteuerung (Timing) der Tests steuern, beispielsweise, um ein Testen mehrerer Testobjekte zu synchronisieren.
  • Bei einem bevorzugten Ausführungsbeispiel der automatisierten Testeinrichtung ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, einen Parametersatz, der einen Auf-Chip-System-Test parametrisiert, auf ein Testobjekt hochzuladen. Beispielsweise kann das Auf-Chip-System-Teststeuergerät außerdem dazu konfiguriert sein, eine erneute Ausführung eines zuvor hochgeladenen Auf-Chip-System-Tests (der seitens des Testobjekts ausgeführt wurde, bevor ein anderer Parametersatz verwende wurde) unter Verwendung des neu hochgeladenen Parametersatzes zu initiieren, um auf diese Weise eine Ausführung des Auf-Chip-System-Tests mit unterschiedlichen Parametersätzen zu bewirken.
  • Dementsprechend kann ein Auf-Chip-System-Test mehrere Male mit unterschiedlichen Parametersätzen ausgeführt werden, ohne den gesamten Auf-Chip-System-Test mehrere Male auf das Testobjekt hochzuladen. Vielmehr wird ein Programmcodeabschnitt des Auf-Chip-System-Tests lediglich einmal auf das Testobjekt hochgeladen, und ein Parametersatz, der zum Parametrisieren der Ausführung des Auf-Chip-System-Tests verwendet wird, wird nach der Ausführung des Auf-Chip-System-Tests aktualisiert. Jedoch ist eine Datenmenge (z. B. Parameterwerte), die den Datensatz ausmacht, typischerweise viel kleiner als eine Datenmenge (z. B. Programmcode), die den Auf-Chip-System-Test selbst ausmacht. Darüber hinaus ist festzustellen, dass die Parametersätze, die den Auf-Chip-System-Test parametrisieren, ansprechend auf Ergebnisdaten von dem Testobjekt vorbestimmt (z. B. durch einen Testablauf vorbestimmt) oder dynamisch angepasst (z. B. durch das Auf-Chip-System-Teststeuergerät) werden können. Auf diese Weise kann eine typische Prozedur ein Hochladen eines Auf-Chip-System-Tests auf das Testobjekt, ein Hochladen eines ersten Satzes von Parametern auf das Testobjekt, ein Ausführen des Auf-Chip-System-Tests auf dem Testobjekt unter Verwendung des ersten Parametersatzes, ein Bereitstellen von Ergebnisinformationen für das Auf-Chip-System-Teststeuergerät, ein Hochladen eines zweiten Parametersatzes (eines zweiten Satzes von Parametern) auf das Testobjekt, ein erneutes Ausführen des Auf-Chip-System-Tests auf dem Testobjekt (ohne erneutes Hochladen des Auf-Chip-System-Tests) unter Verwendung des zweiten Parametersatzes und ein weiteres Bereitstellen von Ergebnisinformationen für das Auf-Chip-System-Teststeuergerät aufweisen.
  • Die Parametersätze können beispielsweise einen oder mehrere Parameter aufweisen, die eine Menge von Daten, die bei einer Ausführen eines Auf-Chip-System-Tests verarbeitet werden sollen, und/oder eine Anzahl von Testobjektkomponenten, die gleichzeitig aktiviert werden sollen (was eine Belastung definiert, die an das Testobjekt angelegt wird), und/oder eine Datenrate von Daten, die über eine Schnittstelle übertragen werden, und/oder Parameter einer analogen Schnittstelle (z. B. Frequenzparameter oder Modulationsparameter einer Hochfrequenzschnittstelle) und/oder andere Parameter, die eine Belastung beschreiben, die während der Ausführung eines Auf-Chip-System-Tests erzeugt wird, und/oder Parameter, die eine Testabdeckung von DUT-Komponenten während der Ausführung eines Auf-Chip-System-Tests beschreiben, oder dergleichen definieren.
  • Abschließend lässt sich sagen, dass es gemäß einem Aspekt der Erfindung möglich ist, Testparameter unabhängig von einem Laden des Auf-Chip-System-Tests selbst auf das Testobjekt zu laden: z. B. kann ein OCST (on-chip-system test, Auf-Chip-System-Test) (z. B. ein zuvor geladener OCST) geladen bleiben, aber vor seiner nächsten Ausführung (z. B. erneuter Ausführung) können die Parameter geändert werden. Dies ist effizienter und erfolgt typischerweise dann, wenn ein OCST charakterisiert wird.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, einen Auf-Chip-System-Test (z. B. einen spezifischen OCST), der auf einem Testobjekt geladen ist, zu starten (beispielsweise unter Verwendung einer Kommunikation mit der Auf-Chip-System-Testumgebung oder unter Verwendung einer Debug-Schnittstelle).
  • Durch Starten eines Auf-Chip-System-Tests kann das Auf-Chip-System-Teststeuergerät ein hohes Maß an Kontrolle über den Testablauf ausüben. Beispielsweise kann das Auf-Chip-System-Teststeuergerät den Auf-Chip-System-Test unter Verwendung der Debug-Schnittstelle (oder der Steuerschnittstelle) oder sogar unter Verwendung einer Datenübertragung über die Schnittstelle mit hoher Bandbreite starten. Dementsprechend kann das Auf-Chip-System-Teststeuergerät eine Ausführung eines Tests von mehreren Testobjekten koordinieren, und das Auf-Chip-System-Teststeuergerät kann außerdem eine Ausführung eines Auf-Chip-System-Tests auf einem Testobjekt mit anderen Testgerätressourcen koordinieren.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, den Test des Testobjekts auf Basis eines gesamten Testausführungsprogramms (z. B. durch einen Benutzer programmiert) in einer Testsequenzierungssprache (z. B. einer universalen Testsequenzierungssprache) zu steuern.
  • Durch Steuern des Tests des Testobjekts auf der Basis eines gesamten Testausführungsprogramms kann das Auf-Chip-System-Steuergerät beispielsweise eine Ausführung mehrerer Auf-Chip-System-Tests leiten, wobei beispielsweise bestimmte Abbruchkriterien evaluiert werden können, um weitere Tests zu vermeiden, falls ein vorheriger Test fehlgeschlagen ist. Darüber hinaus ist durch Verarbeiten eines gesamten Testausführungsprogramms in einer Testsequenzierungssprache ein hohes Maß an Flexibilität bei der Konfiguration des gesamten Testablaufs verfügbar.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, eine oder mehrere analoge Testressourcen (z. B. eine Testobjekt-Leistungsversorgung und/oder eine analoge Messeinheit) beispielsweise direkt zu steuern, beispielsweise ohne Kommunikation mit einer Software höherer Ebene, die dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren analogen Testressourcen untergeordnet ist (oder die hierarchisch über dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren analogen Testressourcen steht).
  • Alternativ oder zusätzlich ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, zusätzlich zu den Schnittstellen eine oder mehrere digitale Testressourcen (z. B. einen digitalen Ausgang oder einen digitalen Eingang) beispielsweise direkt zu steuern, beispielsweise ohne Kommunikation mit einer Software höherer Ebene, die dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren digitalen Testressourcen untergeordnet ist (oder die hierarchisch über dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren digitalen Testressourcen steht).
  • Alternativ oder zusätzlich ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, eine oder mehrere analoge Testressourcen (z. B. eine Testobjekt-Leistungsversorgung und/oder eine analoge Messeinheit) beispielsweise direkt zu synchronisieren, beispielsweise ohne Kommunikation mit einer Software höherer Ebene, die dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren analogen Testressourcen untergeordnet ist (oder die hierarchisch über dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren analogen Testressourcen steht).
  • Alternativ oder zusätzlich ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, zusätzlich zu den Schnittstellen eine oder mehrere digitale Testressourcen (z. B. einen digitalen Ausgang oder einen digitalen Eingang) beispielsweise direkt zu synchronisieren, beispielsweise ohne Kommunikation mit einer Software höherer Ebene, die dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren digitalen Testressourcen untergeordnet ist (oder die hierarchisch über dem Auf-Chip-System-Teststeuergerät und der einen oder den mehreren digitalen Testressourcen steht).
  • Durch direkte Steuerung einer oder mehrerer analoger Testressourcen oder einer oder mehrerer digitaler Testressourcen ohne Kommunikation mit einer Software höherer Ebene können Engpässe vermieden werden, was besonders dann wichtig ist, wenn mehrere Testobjekte gleichzeitig getestet werden. Dementsprechend kann das Auf-Chip-System-Teststeuergerät zumindest Abschnitte eines Testablaufs ohne Interaktion mit einer Software höherer Ebene ausführen (die zum Beispiel auf einer Workstation (Arbeitsplatzrechner) läuft, die den gesamten Testprozess steuert). Beispielsweise kann das Auf-Chip-System-Teststeuergerät mit einer oder mehreren digitalen Testressourcen und/oder mit einer oder mehreren analogen Testressourcen gekoppelt sein, unter Verwendung von Verbindungsressourcen, die dem Auf-Chip-System-Teststeuergerät „dediziert“ sind oder die nicht gemeinschaftlich von verschiedenen Auf-Chip-System-Teststeuergeräten verwendet werden. Alternativ kann das Auf-Chip-System-Teststeuergerät mit einer oder mehreren analogen Testressourcen und/oder mit einer oder mehreren digitalen Testressourcen gekoppelt sein, unter Verwendung von Verbindungsressourcen, die gemeinschaftlich mit einem oder mehreren anderen Auf-Chip-System-Teststeuergeräten verwendet werden, die jedoch unter der Steuerung des Auf-Chip-System-Teststeuergeräts verwendet werden können, ohne dass eine Komponente auf höherer (hierarchischer) Ebene oder eine Software höherer Ebene (hierarchischer) Ebene beteiligt ist. Dadurch kann die Testgeschwindigkeit erhöht werden, und es kann ein Engpass vermieden werden.
  • Auf ähnliche Weise kann durch ein Auf-Chip-System-Teststeuergerät, das dazu konfiguriert ist, eine oder mehrere digitale Testressourcen und/oder eine oder mehrere analoge Testressourcen zu synchronisieren, das vollständige Testen eines Testobjekts mit hoher zeitlicher Genauigkeit durchgeführt werden. Insbesondere kann, mit Hilfe der Funktionalität zum Synchronisieren einer oder mehrerer analoger Testressourcen und/oder einer oder mehrerer digitaler Testressourcen, das Auf-Chip-System-Teststeuergerät einen Test des Testobjekts durchführen, wobei ein Anpassen einer Erzeugung von analogen Qualitäten oder einer Messung von analogen Quantitäten oder einer Erzeugung von digitalen Stimulussignalen oder einer Erfassung von digitalen Ausgangssignalen (die durch die eine oder die mehreren analogen Testressourcen und/oder die eine oder die mehreren digitalen Testressourcen durchgeführt werden kann) eng zeitsynchronisiert mit einer Ausführung eines oder mehrerer Auf-Chip-System-Tests durchgeführt werden, die ebenfalls (zumindest teilweise) durch das Auf-Chip-System-Teststeuergerät gesteuert werden. Anders gesagt kann das Auf-Chip-System-Teststeuergerät als dezentrale Steuer-Entität agieren, die sich in der Nähe des einzelnen Testobjekts befindet und sowohl eine Programmausführung auf dem Testobjekt als auch zusätzliche Testressourcen (analoge Testressourcen und/oder digitale Testressourcen) genau synchronisieren kann.
  • Bei einem bevorzugten Ausführungsbeispiel weist das Auf-Chip-System-Teststeuergerät eine lokale Kommunikationsschnittstelle auf, um eine oder mehrere analoge Testressourcen und/oder eine oder mehrere digitale Testressourcen zu steuern. Alternativ oder zusätzlich weist das Auf-Chip-System-Teststeuergerät eine lokale Synchronisationsschnittstelle auf, um eine oder mehrere analoge Testressourcen und/oder eine oder mehrere digitale Testressourcen zu synchronisieren (z. B. durch direktes Verbinden des Auf-Chip-System-Teststeuergeräts mit den analogen Testressourcen und/oder den digitalen Testressourcen).
  • Durch Verwendung einer lokalen Kommunikationsschnittstelle und/oder einer lokalen Synchronisationsschnittstelle, die beispielsweise nicht gemeinschaftlich mit anderen Auf-Chip-Teststeuergeräten verwendet wird, kann eine hohe zeitliche Genauigkeit gewährleistet und eine Beeinflussung zwischen unterschiedlichen Auf-Chip-System-Teststeuergeräten, die gleichzeitig unterschiedliche Testobjekte Testen können, vermieden werden. Folglich kann ein hohes Maß an zeitlicher Genauigkeit und Reproduzierbarkeit erreicht werden.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, Befehle und/oder Daten von einem Auf-Chip-System-Test zu empfangen, der auf dem Testobjekt läuft, und einen Testausführungsablauf in Abhängigkeit von den empfangenen Befehlen und/oder den empfangenen Daten anzupassen.
  • Durch Anpassen eines Testausführungsablaufs an Befehle und/oder Daten des Auf-Chip-System-Tests, der auf dem Testobjekt läuft, kann die Entwicklung des Testprogramms erleichtert werden, da die Kontrolle über den Testablauf zumindest in einem gewissen Maß in dem Programm beinhaltet sein kann, das auf dem Testobjekt läuft. Andererseits kann der Testablauf auch dynamisch an eine nicht deterministische Ausführung des Programms, das auf dem Testobjekt läuft, angepasst werden. Insbesondere beim Testen von Ein-Chip-Systemen, die Testprogramme ausführen, ist ein Timing des Testablaufs nicht mehr ohne weiteres vorhersagbar. Indem dem Testobjekt die Möglichkeit gegeben wird, eine gewisse Kontrolle über den Testablauf auszuüben, indem Befehle an die Auf-Chip-System-Teststeuergeräten zur Verfügung gestellt werden, kann erreicht werden, dass die automatische Testeinrichtung sich an die nicht deterministische Ausführung eines Programms auf dem Testobjekt anpasst. Folglich kann die automatisierte Testeinrichtung dem Testobjekt die entsprechenden Eingangssignale zum richtigen Zeitpunkt zur Verfügung stellen und/oder kann zum richtigen Zeitpunkt Messungen von Signalen durchführen, die durch das Testobjekt bereitgestellt werden.
  • Bei einem bevorzugten Ausführungsbeispiel ist das Auf-Chip-System-Teststeuergerät dazu konfiguriert, Befehle und/oder Daten von einem Auf-Chip-System-Test zu empfangen, der auf dem Testobjekt läuft, und Testressourcen (z. B. analoge Quantitäten, beispielsweise eine oder mehrere Versorgungsspannungen oder ein oder mehrere Stimulussignale, die dem Testobjekt bereitgestellt werden, oder ein oder mehrere Evaluierungsparameter, z. B. Schwellenwerte, zum Beurteilen von Signalen, die durch das Testobjekt bereitgestellt werden) in Abhängigkeit von den empfangenen Befehlen und/oder den empfangenen Daten anzupassen.
  • Durch Anpassen von Testressourcen ansprechend auf ein Empfangen von Befehlen und/oder Daten von dem Testobjekt (das ein Testprogramm, d. h. einen Auf-Chip-System-Test, ausführen kann) kann eine gute Koordination zwischen der typischerweise nicht deterministischen Ausführung des Programms auf dem Testobjekt und den Aktivitäten der automatisierten Testeinrichtung (z. B. Bereitstellen von Versorgungsspannungen oder Stimulussignalen oder Evaluierung von Signalen von dem Testobjekt) erzielt werden.
  • Bei einem bevorzugten Ausführungsbeispiel weist das Auf-Chip-System-Teststeuergerät eine Zentraleinheit (z. B. einen System-SOC) auf, die dazu konfiguriert ist, eine Eingebettete-Software-Umgebung und einen oder mehrere Schnittstellenblöcke bereitzustellen, die die Debug-Schnittstelle und/oder die Steuerschnittstelle und/oder die Schnittstelle mit hoher Bandbreite implementieren.
  • Das Auf-Chip-System-Teststeuergerät weist eine Front-End-Elektronik zum Bereitstellen eines oder mehrerer Signale für das Testobjekt und zum Empfangen eines oder mehrerer Signale von dem Testobjekt auf.
  • Das Auf-Chip-System-Teststeuergerät weist außerdem eine oder mehrere Back-End-Schnittstellen auf, die dazu konfiguriert sind, mit einer oder mehreren anderen Komponenten der automatisierten Testeinrichtung zu kommunizieren und/oder mit einer oder mehreren anderen Komponenten der automatisierten Testeinrichtung zu synchronisieren.
  • Durch Bereitstellen einer Zentraleinheit, einer Front-End-Elektronik und außerdem von einer oder mehreren Back-End-Schnittstellen auf dem Auf-Chip-System-Teststeuergerät kann das Auf-Chip-System-Teststeuergerät zumindest einen Teil eines Testablaufs unabhängig von einer Steuerung auf höherer Ebene effizient ausführen. Beispielsweise kann das Auf-Chip-System-Teststeuergerät von einer Steuerung auf höherer Ebene Konfigurationsinformationen über eine der Back-End-Schnittstellen empfangen und außerdem eine oder mehrere andere Testgerätressourcen steuern, beispielsweise eine Leistungsversorgung einer Vorrichtung und/oder einen oder mehrere digitale Kanäle und/oder eine oder mehrere analoge Signalerzeugungsvorrichtungen und/oder eine oder mehrere analoge Messvorrichtungen. Aufgrund des Vorhandenseins einer Front-End-Elektronik auf dem Auf-Chip-System-Teststeuergerät kann das Auf-Chip-System-Teststeuergerät beispielsweise die meisten zeitkritischen Signale direkt von dem Testobjekt empfangen und/oder die meisten zeitkritischen Signale direkt an das Testobjekt senden, ohne beliebige andere Komponenten zu beteiligen. Anders gesagt ist das oben beschriebene Auf-Chip-System-Teststeuergerät in der Lage, einige grundlegende Testfunktionalitäten unabhängig von anderen Testressourcen auszuführen, ist aber dennoch in der Lage, derartige zusätzliche Testressourcen dahingehend zu steuern, dass dieselben aufwändigere Tests durchführen (zum Beispiel Variieren einer Leistungsversorgungsspannung des Testobjekts oder einer Taktfrequenz, die an das Testobjekt angelegt ist, oder andere zusätzliche Parameter). Zusammenfassend lässt sich sagen, dass das hier beschriebene Auf-Chip-System-Teststeuergerät unabhängig einen großen Teil eines Testablaufs, der dazu verwendet wird, ein Testobjekt zu testen, bei dem es sich um ein Ein-Chip-System handelt, durchzuführen (oder zumindest zu steuern).
  • Bei einem bevorzugten Ausführungsbeispiel weist die automatisierte Testeinrichtung eine Schnittstelle zu einer oder mehreren Entwicklungs- und Debug-Umgebungen auf.
  • Durch Bereitstellen einer Schnittstelle zu einer oder mehreren Entwicklungs- und Debug-Umgebungen kann eine Entwicklung eines Testprogramms erleichtert werden. In dieser Hinsicht ist festzustellen, dass eine Entwicklung eines Testprogramms für ein Ein-Chip-System sehr herausfordernd ist, da typischerweise ein derartiges „Testprogramm“ sowohl einen Testprogrammabschnitt, der auf dem Testobjekt ausgeführt werden soll, als auch einen Testprogrammabschnitt aufweist, der durch die automatisierte Testeinrichtung oder durch das Auf-Chip-System-Teststeuergerät der automatisierten Testeinrichtung ausgeführt werden soll. Dementsprechend ist es wünschenswert, da ein Programmcode für zwei physische Entitäten (DUT und automatisierte Testeinrichtung) entwickelt werden muss, eine derartige Entwicklung zu unterstützen, die häufig zumindest teilweise unter Verwendung von Drittanbietersoftware seitens der automatisierten Testeinrichtung durchgeführt wird.
  • Die Schnittstelle zwischen der automatisierten Testeinrichtung und der einen oder den mehreren Entwicklungs- und Debug-Umgebungen kann es beispielsweise einer Entwicklungs- und Debug-Umgebung eines Drittanbieters ermöglichen, ein Programm unter Verwendung des Auf-Chip-System-Teststeuergeräts (oder allgemein gesagt, unter Verwendung der Hardware der automatisierten Testeinrichtung) auf das Testobjekt hochzuladen, und kann es der Entwicklungs- und Debug-Umgebung außerdem ermöglichen, über das Auf-Chip-System-Teststeuergerät (oder allgemein gesagt unter Verwendung der Hardware der automatisierten Testeinrichtung) Debug-Informationen von dem Testobjekt zu erhalten. Darüber hinaus kann die Schnittstelle zwischen der automatisierten Testeinrichtung und der Entwicklungs- und Debug-Umgebung außerdem die Entwicklungs- und Debug-Umgebung mit Informationen über die Testgerätressourcen und/oder die Anwendungsprogrammierschnittstellen versorgen, um eine oder mehrere Ressourcen (z. B. analoge Ressourcen oder digitale Ressourcen) der automatisierten Testeinrichtung zu steuern. Allgemein gesagt kann die Schnittstelle zwischen der automatisierten Testeinrichtung und der Entwicklungs- und Debug-Umgebung die Entwicklungs- und Debug-Umgebung mit einem oder mehreren oder sogar beliebigen der (Software-)Module (wie beispielsweise APIs) versorgen, die zum Zugreifen auf Testgerätressourcen oder zum Koordinieren von Aktivitäten des Testobjekts mit Aktivitäten der automatisierten Testeinrichtung erforderlich sind. Darüber hinaus kann ein Zugriff auf Programmhochladefunktionalitäten und/oder Debug-Informationen des Testobjekts durch die Schnittstelle bereitgestellt werden, so dass Software-Entwicklung und -Debugging unter Verwendung der Entwicklungs- und Debug-Umgebung des Drittanbieters effizient durchgeführt werden können.
  • Bei einem bevorzugten Ausführungsbeispiel weist die automatisierte Testeinrichtung eine Entwicklungs- und Debug-Umgebung auf, die dahingehend angepasst ist, sowohl eine Auf-Chip-System-Testsoftware zur Ausführung auf dem Testobjekt als auch ein Testprogramm, das durch die automatisierte Testeinrichtung ausgeführt werden soll, zu entwickeln und zu debuggen.
  • Durch Bereitstellen einer Entwicklungs- und Debug-Umgebung als Teil der automatisierten Testeinrichtung, die dahingehend angepasst ist, sowohl die Auf-Chip-System-Testsoftware zur Ausführung auf dem Testobjekt als auch ein Testprogramm, das durch die automatisierte Testeinrichtung ausgeführt werden soll, zu entwickeln und zu debuggen, kann eine Entwicklung von Testsoftware erheblich erleichtert werden. Insbesondere wird eine gemeinschaftliche Entwicklungs- und Debug-Umgebung bereitgestellt, die entsprechende (zusammenpassende) Routinen für einen Austausch von Steuerinformationen oder Daten zwischen der automatisierten Testeinrichtung und dem Testobjekt vorsieht. Da die gemeinschaftliche Entwicklungs- und Debug-Umgebung die Schnittstellen zwischen der automatisierten Testeinrichtung und dem Testobjekt kennen kann, kann die gemeinschaftliche Entwicklungs- und Debug-Umgebung sogar Zugriff auf dieselben Variablen ermöglichen, sowohl auf der Seite des Testobjekts als auch auf der Seite der automatisierten Testeinrichtung, wobei eine Kommunikation dieser Variablen von dem Testobjekt zu der automatisierten Testeinrichtung oder umgekehrt automatisch durch die gemeinsame Entwicklungs- und Debug-Umgebung durchgeführt werden kann, beispielsweise durch Einfügen von entsprechenden Kommunikationscodeabschnitten in die Auf-Chip-System-Testsoftware zur Ausführung auf dem Testobjekt und in das Testprogramm, das durch die automatisierte Testeinrichtung ausgeführt werden soll. Somit kann bei Durchführen einer Softwareentwicklung für beide Seiten einer Kommunikationsbeziehung (d. h. für das Testobjekt und für die automatisierte Testeinrichtung) in einer gemeinschaftlichen Entwicklungs- und Debug-Umgebung ein Entwicklungsprozess erheblich vereinfacht werden, und ein Softwareentwickler kann mit einer homogenen Umgebung, die gemeinsame Variablennamen, Schnittstellennamen usw. verwendet, ausgestattet werden.
  • Insbesondere kann die gemeinschaftlichen Debug- und Entwicklungsumgebung Werkzeuge bereitstellen, um Codeabschnitte für eine einzelne Aktion (zum Beispiel Kommunikation von Daten von dem Testobjekt zu der automatisierten Testeinrichtung) ansprechend auf eine einzelne Benutzerinteraktion einführen, die angibt, dass eine derartige Aktion erwünscht ist. Folglich ist es für einen Softwareentwickler nicht länger erforderlich, zwischen separaten Entwicklungsumgebungen unter Verwendung unterschiedlicher Programmierkonzepte, variablen Namen, APIs usw. umschalten zu müssen.
  • Des Weiteren kann, wann immer eine Debug-Funktionalität (zum Debuggen von Code auf dem Testobjekt) erwünscht ist, die gemeinschaftliche Entwicklungs-Debug-Umgebung automatisch einen Codeabschnitt für ein Testprogramm erzeugen, das auf der automatisierten Testeinrichtung ausgeführt werden soll, um die Debug-Informationen von dem Testobjekt abzurufen und die Debug-Informationen an die gemeinschaftliche Entwicklungs- und Debug-Umgebung weiterzuleiten. Folglich kann der Entwickler sich auf die Frage konzentrieren, welche Debug-Funktionalität für das Testobjekt erwünscht ist, und die gemeinschaftliche Entwicklungs- und Debug-Umgebung erzeugt automatisch einen Programmcode für die automatisierte Testeinrichtung, die die Debug-Informationen von dem Testobjekt an die Entwicklungs- und Debug-Umgebung weiterleitet (z. B. über das Auf-Chip-System-Teststeuergerät).
  • Zusammenfassend lässt sich sagen, dass die Verwendung einer Entwicklungs- und Debug-Umgebung, die sowohl auf die Auf-Chip-System-Testsoftware als auch auf das Testprogramm abzielt, das durch die automatisierte Testeinrichtung ausgeführt werden soll (z. B. durch das Auf-Chip-System-Teststeuergerät), eine höchst effiziente Softwareentwicklung ermöglicht, während eine Entwicklung von sowohl einer Auf-Chip-System-Testsoftware zum Ausführen auf dem Testobjekt als auch eines Testprogramms, das durch die automatisierte Testeinrichtung ausgeführt werden soll, herkömmlicherweise sehr schwer für den Test-Engineer wäre.
  • Bei einem bevorzugten Ausführungsbeispiel ermöglicht die Entwicklungs- und Debug-Umgebung einen Zugriff auf Testressourcen der automatisierten Testeinrichtung (stellt z. B. eine Schnittstelle oder API bereit), während Entwicklung und Debugging einer Auf-Chip-System-Testsoftware, die auf dem Testobjekt ausgeführt werden soll, durchgeführt werden.
  • Das Ermöglichen eines Zugriffs auf Testressourcen der automatisierten Testeinrichtung unterstützt das Entwickeln und/oder Debuggen von Auf-Chip-System-Testsoftware stark, da ein Zugriff auf Testressourcen der automatisierten Testeinrichtung ein Hochladen von Programmcodes auf das Testobjekt, ein Hochladen von Testparametern, ein Herunterladen von Ergebnisinformationen und ein Streamen von Traces von dem Testobjekt in die Entwicklungs- und Debug-Umgebung, eine Koordination zwischen einer Programmausführung auf dem Testobjekt und einer Umgebung, die dem Testobjekt durch die automatisierte Testeinrichtung bereitgestellt wird, unterstützen kann usw. Zum Beispiel kann die Entwicklungs- und Debug-Umgebung eine Schnittstelle oder eine Anwendungsprogrammierschnittstelle (API) bereitstellen, die, wenn dieselbe in einem Programm beinhaltet ist, das auf einem Testobjekt läuft, es dem Testobjekt ermöglicht, auf die Testgerätressourcen zuzugreifen und/oder mit der automatisierten Testeinrichtung zu kommunizieren.
  • Folglich kann die Funktionalität der automatisierten Testeinrichtung beim Testen eines DUT effizient ausgenutzt werden, und das DUT kann außerdem eine gewisse Kontrolle (oder sogar vollständige Kontrolle) über die Testressourcen der automatisierten Testeinrichtung gewinnen, so dass eine Entwicklung eines Testprogramms, das durch die automatisierte Testeinrichtung ausgeführt werden soll, wenn das Testobjekt getestet wird, vereinfacht oder sogar vermieden werden kann.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung einen Programmcode auf, um einen Zugriff auf einen Speicherinhalt (z. B. eines Speichers der automatisierten Testeinrichtung) von dem Auf-Chip-System über eine Schnittstelle (z. B. HSIO) der automatisierten Testeinrichtung zu ermöglichen.
  • Durch Bereitstellen eines Programmcodes, der einen Zugriff auf einen Speicherinhalt von dem Auf-Chip-System (von dem Testobjekt) über eine Schnittstelle der automatisierten Testeinrichtung ermöglicht, kann das Vorhandensein eines Speichers emuliert werden. Dies ist in Fällen hilfreich, in denen das Testobjekt normalerweise mit einem bestimmten externen Speicher betrieben würde, der in der eigentlichen Testumgebung nicht vorhanden ist. In diesem Fall kann das Testobjekt durch den Programmcode, der durch die Entwicklungs- und Debug-Umgebung bereitgestellt wird, aktiviert werden, um auf einen Speicher der automatisierten Testeinrichtung (z. B. des Auf-Chip-System-Teststeuergeräts) zuzugreifen, um einen Speicher, der normalerweise direkt mit dem Testobjekt verbunden sein sollte, wirksam zu ersetzen. Dementsprechend kann das Testobjekt immer noch in vernünftiger Weise betrieben werden, selbst in Situationen, in denen es nicht möglich ist, einen eigentlichen Speicher bereitzustellen, der direkt mit dem Testobjekt gekoppelt ist, wobei der Programmcode, der einen Zugriff auf den Speicherinhalt eines Speichers der automatisierten Testeinrichtung über die Hochgeschwindigkeits-I/O-Schnittstelle oder über die Schnittstelle mit hoher Bandbreite ermöglicht, als Treiber funktionieren kann, um den fehlenden physischen Speicher zu emulieren. Insbesondere weiß der Programmcode typischerweise, wie auf den Speicherinhalt, der typischerweise in dem Speicher des Auf-Chip-System-Teststeuergeräts gespeichert ist, über die Schnittstelle (z. B. Hochgeschwindigkeits-IO oder Schnittstelle mit hoher Bandbreite) zugegriffen werden kann (z. B. derselbe adressiert werden kann) und ermöglicht es damit dem Testobjekt, auf den Speicherinhalt korrekt zuzugreifen, wenn der Programmcode auf dem Testobjekt ausgeführt wird. Folglich ist die Emulation des Speichers für einen Programmierer, der ein Programm für das Testobjekt entwickelt, im Wesentlichen offensichtlich, da die Entwicklungs- und Debug-Umgebung der automatisierten Testeinrichtung für das Bereitstellen eines geeigneten Emulationsprogrammcodes verantwortlich ist.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung eine Schnittstelle auf, um es einer Debug-Software zu ermöglichen, ein Hochladen eines Programms auf das Testobjekt (z. B. auf ein Auf-Chip-System) zu steuern.
  • Durch Bereitstellen einer Schnittstelle zum Ermöglichen, dass eine Debug-Software ein Hochladen eines Programms auf das Testobjekt steuern kann, kann eine Drittanbieter-Entwicklungssoftware oder Debug-Software verwendet werden, die dem Software-Engineer, der einen Programmcode für das Testobjekt entwickelt, vertraut sein kann. Dementsprechend kann der Software-Engineer eine Software für das Testobjekt selbst dann Testen und debuggen, wenn das Testobjekt in der Testumgebung platziert ist (d. h. mit dem Auf-Chip-System-Teststeuergerät gekoppelt ist).
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung eine Schnittstelle auf, um es einer Debug-Software zu ermöglichen, auf eine Debug-Schnittstelle (z. B. JTAG) des Testobjekts (z. B. auf ein Auf-Chip-System) zuzugreifen.
  • Durch Bereitstellen einer Schnittstelle, um es einer Debug-Software zu ermöglichen, auf eine Debug-Schnittstelle des Testobjekts zuzugreifen, kann ein Debuggen unter Verwendung einer Drittanbieter-Debug-Software in einem Fall aktiviert werden, dass das Testobjekt in der eigentlichen Testumgebung platziert ist (z. B. mit dem Auf-Chip-System-Teststeuergerät gekoppelt ist). Somit kann das Debuggen eines Auf-Chip-System-Tests, der durch das Testobjekt ausgeführt werden soll, unter realen Testbedingungen durchgeführt werden.
  • Bei einem bevorzugten Ausführungsbeispiel ist die Entwicklungs- und Debug-Umgebung dazu konfiguriert, einer Debug-Software direkten Zugriff (z. B. unter Vermeidung oder Umgehung der Entwicklungs- und Debug-Schnittstelle) auf eine Debug-Schnittstelle (z. B. JTAG) des Testobjekts (z. B. auf einem Auf-Chip-System) bereitzustellen. Der direkte Zugriff kann z. B. durch Schalten einer JTAG-Verbindung des DUT zwischen einem Weg durch das Auf-Chip-System-Teststeuergerät und die Entwicklungs- und Debug-Umgebung und einem direkten Weg, z. B. unter Umgehung des Auf-Chip-System-Teststeuergeräts und der Entwicklungs- und Debug-Umgebung, in Richtung der Debug-Software bereitgestellt werden.
  • Durch Bereitstellen eines direkten Zugriffs auf die Debug-Schnittstelle können beliebige Latenzen, die durch ein Weiterleiten der Debug-Schnittstelle durch das Auf-Chip-System-Teststeuergerät bewirkt werden, vermieden werden. Außerdem kann auch eine Debug-Software verwendet werden, die nicht in der Lage ist, mit einer Schnittstelle der automatisierten Testeinrichtung umzugehen, um auf die Debug-Schnittstelle des Testobjekts zuzugreifen. Anders gesagt kann durch Bereitstellen von Zugriff auf die Debug-Schnittstelle des Testobjekts, wobei das Auf-Chip-System-Teststeuergerät und die Entwicklungs- und Debugging-Umgebung der automatisierten Testeinrichtung umgangen werden, eine maximale Kompatibilität mit der Drittanbieter-Debug-Software aufrechterhalten werden.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung eine Anwendungsprogrammierschnittstelle zur Nutzung in einer Umgebung von Auf-Chip-System-Software auf, um eine Kommunikation zwischen dem Testobjekt und Testressourcen der automatisierten Testeinrichtung zu ermöglichen, wenn die entwickelte Auf-Chip-System-Testsoftware auf dem Testobjekt ausgeführt wird (um z. B. Testparameter von der automatisierten Testeinrichtung zu empfangen und/oder um Steuerbefehle an die automatisierte Testeinrichtung oder an das Auf-Chip-System-Teststeuergerät zu senden).
  • Durch Bereitstellen einer derartigen Anwendungsprogrammierschnittstelle in der Debug-Umgebung ist es leicht möglich, eine Auf-Chip-System-Testsoftware zu entwickeln, die auf dem Testobjekt ausgeführt wird und die mit der automatisierten Testeinrichtung kommuniziert. Auf Basis des Wissens über das Verhalten der Testressourcen der automatisierten Testeinrichtung kann die Anwendungsprogrammierschnittstelle derart bereitgestellt werden, dass die Anwendungsprogrammierschnittstelle perfekt zu den Testressourcen der automatisierten Testeinrichtung passt. Somit muss ein Entwickler einer Auf-Chip-System-Testsoftware, die auf dem Testobjekt ausgeführt werden soll, nicht über detailliertes Wissen bezüglich der automatisierten Testeinrichtung verfügen, sondern kann sich einfach auf die Anwendungsprogrammierschnittstelle verlassen, die die Testressourcen der automatisierten Testeinrichtung auf abstrakte Weise repräsentiert. Außerdem können Details der Testressourcen der automatisierten Testeinrichtung ohne erneutes Gestalten der Auf-Chip-System-Testsoftware modifiziert werden. Vielmehr ist es in einem derartigen Fall lediglich erforderlich, die Anwendungsprogrammierschnittstelle anzupassen. Darüber hinaus kann leicht zwischen unterschiedlichen Schnittstellen zwischen dem Testobjekt und der automatisierten Testeinrichtung geschaltet werden, beispielsweise falls die Anwendungsprogrammierschnittstellen dahingehend gestaltet sind, von der eigentlichen physischen Implementierung der Schnittstelle unabhängig zu sein, oder falls Anwendungsprogrammierschnittstellen, die unterschiedlichen Schnittstellentypen zugeordnet sind, ähnlich sind. Dementsprechend wird die Entwicklung einer Auf-Chip-System-Testsoftware erleichtert, was ebenfalls Kosten spart.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung außerdem eine Testgerätsoftware auf, um eine Kommunikation der automatisierten Testeinrichtung mit einem Testobjekt zu unterstützen, auf dem die entwickelte Auf-Chip-System-Testsoftware läuft (die die Anwendungsprogrammierschnittstelle nutzt).
  • Indem außerdem eine Testsoftware zum Unterstützen einer Kommunikation der automatisierten Testeinrichtung mit dem Testobjekt bereitgestellt wird, ermöglicht die Debug- und Entwicklungsumgebung eine einfache Kommunikation zwischen dem Testobjekt und der automatisierten Testeinrichtung. Insbesondere können auf gut synchronisierte Weise leicht eine Auf-Chip-System-Testsoftware, die auf dem Testobjekt ausgeführt werden soll, und auch eine Testgerätsoftware entwickelt werden. Insbesondere ist festzustellen, dass eine Kommunikation zwischen dem Testobjekt und der automatisierten Testeinrichtung ein „Zusammenpassen“ von Auf-Chip-System-Testsoftware, die auf dem Testobjekt ausgeführt werden soll, und von Testgerätsoftware erfordert, die beispielsweise durch das Auf-Chip-System-Teststeuergerät ausgeführt werden soll. Insbesondere kann die Entwicklungs- und Debug-Umgebung derartige „zusammenpassende“ Softwarekomponenten sowohl für das Testobjekt als auch für die automatisierte Testeinrichtung bereitstellen und deshalb eine schnelle Entwicklung einer funktionalen Testsoftware ermöglichen.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung ein Programm (z. B. einen „OCST-Test-Runner“) zur Verwendung bei einer Entwicklung von Auf-Chip-System-Testsoftware (z. B. zur Aufnahme in die Auf-Chip-System-Testsoftware) auf, um ein Hochladen weiterer Software (z. B. weiterer Auf-Chip-System-Testsoftware) von der automatisierten Testeinrichtung auf das Testobjekt zu ermöglichen und/oder um in Steuern einer Programmausführung auf dem Testobjekt (z. B. einer Auf-Chip-System-Testsoftware) durch die automatisierte Testeinrichtung zu steuern.
  • Durch Bereitstellen eines Programmcodes, der ein Hochladen weiterer Software von der automatisierten Testeinrichtung auf das Testobjekt ermöglicht und/oder der ein Steuern einer Programmausführung auf dem Testobjekt ermöglicht, können mehrere Probleme gelöst werden, die beim Testen eines Ein-Chip-Systems auftreten. Beispielsweise gibt es typischerweise nicht genügend Speicher auf dem Testobjekt, um die vollständige Auf-Chip-System-Testsoftware (die auf dem Testobjekt ausgeführt werden soll) in einem einzigen Schritt hochzuladen. Dementsprechend kann durch Bereitstellen eines Programms, das ein „dynamisches“ Laden von Software auf das Testobjekt durchführt (von einem Speicher der automatisierten Testeinrichtung, z. B. des Auf-Chip-System-Teststeuergeräts), ein Testen des Testobjekts unterstützt werden. Indem eine derartige Softwareroutine durch die Debug- und Entwicklungsumgebung bereitgestellt wird, kann ein Software-Engineer, der die Auf-Chip-System-Testsoftware entwickelt, sich vollständig auf die eigentlichen Auf-Chip-System-Testroutinen konzentrieren. Darüber hinaus kann, indem außerdem ein Programm bereitgestellt wird, das ein Steuern einer Programmausführung auf dem Testobjekt durch die automatisierte Testeinrichtung ermöglicht, eine Gesamtsteuerung der Testausführung durch die automatisierte Testeinrichtung durchgeführt werden (z. B. durch das Auf-Chip-System-Teststeuergerät). Somit kann das Auf-Chip-System-Teststeuergerät die Ausführung von Auf-Chip-System-Testsoftware auf dem Testobjekt mit zusätzlichen Funktionalitäten der automatisierten Testeinrichtung (z. B. analogen Testressourcen und/oder digitalen Testressourcen) leicht koordinieren. Insbesondere muss, indem derartige Softwaremodule in der Entwicklungs- und Debug-Umgebung der automatisierten Testeinrichtung bereitgestellt werden, ein Software-Engineer, der die Auf-Chip-System-Testsoftware entwickelt, keine Details bezüglich der Mechanismen zum Steuern des Testobjekts durch die automatisierte Testeinrichtung kennen, was eine Softwareentwicklung erleichtert und beschleunigt.
  • Bei einem bevorzugten Ausführungsbeispiel weist die Entwicklungs- und Debug-Umgebung ein Programm (z. B. einen „OCST-Test-Runner“) zur Verwendung bei einer Entwicklung von Auf-Chip-System-Testsoftware (z. B. zur Aufnahme in die Auf-Chip-System-Testsoftware) auf, um eine Programmausführung auf dem Testobjekt (z. B. einer Auf-Chip-System-Testsoftware) zu überwachen, beispielsweise durch Implementieren einer Watchdog-Funktionalität und optional, um ein Ansprechverhalten des Testobjekts zu sicherzustellen.
  • Indem ein Programm zum Überwachen einer Programmausführung auf dem Testobjekt bereitgestellt wird, können Fehlfunktionen des Testobjekts leicht erfasst werden. Beispielsweise kann das Programm, das durch die Entwicklungs- und Debug-Umgebung zur Verwendung bei einer Entwicklung einer Auf-Chip-System-Testsoftware bereitgestellt wird, die Funktionalität eines „Watchdogs“ übernehmen, d. h. erkennen, falls ein Auf-Chip-System-Testprogramm, das auf dem Testobjekt ausgeführt wird, „hängenbleibt“, d. h. nicht mehr ordnungsgemäß funktioniert. Ein derartiges Abbrechen der Programmausführung kann ein Problem des Testobjekts anzeigen, und das Watchdog-Programm kann ein derartiges Ereignis beispielsweise an die automatisierte Testeinrichtung signalisieren. Dementsprechend kann die automatisierte Testeinrichtung entsprechend antworten, beispielsweise indem ein Test des Testobjekts abgebrochen wird und indem das Testobjekt als fehlerhaft markiert wird. Auf diese Weise kann Testzeit eingespart werden, indem ein Testobjektversagen unter Verwendung eines derartigen Überwachungsprogramms oder Watchdog-Programms schnell erkannt wird. Ein Software-Engineer muss sich auch hier keine Sorgen über Details machen, da das Programm seitens der Entwicklungs- und Debug-Umgebung der automatisierten Testeinrichtung bereitgestellt wird.
  • Bei einem bevorzugten Ausführungsbeispiel ist die automatisierte Testeinrichtung dazu konfiguriert, eine oder mehrere Testgerätressourcen, das Auf-Chip-System-Teststeuergerät und einen Auf-Chip-System-Test, der auf dem Testobjekt ausgeführt wird, zu synchronisieren.
  • Durch Synchronisieren einer oder mehrerer Testgerätressourcen, des Auf-Chip-System-Teststeuergeräts und eines Auf-Chip-System-Tests, der auf dem Testobjekt ausgeführt wird, kann ein Test durchgeführt werden, der eine Kooperation zwischen dem Auf-Chip-System-Teststeuergerät, einer oder mehreren zusätzlichen Testgerätressourcen und dem Testobjekt ausnutzt. Anders gesagt können Ressourcen der automatisierten Testeinrichtung angewendet werden, wenn der Auf-Chip-System-Test durchgeführt wird, was zu einem besonders gründlichen Testen führt.
  • Bei einem bevorzugten Ausführungsbeispiel ist die automatisierte Testeinrichtung dazu konfiguriert, bedingte Sprünge (z. B. in einem Testprogramm, das durch die automatisierte Testeinrichtung durchgeführt wird) ansprechend auf Steuerinformationen durchzuführen, die seitens des Auf-Chip-System-Tests bereitgestellt werden, der auf dem Testobjekt läuft.
  • Indem bedingte Sprünge ansprechend auf Steuerinformationen durchgeführt werden, die seitens des Auf-Chip-System-Tests bereitgestellt werden, der auf dem Testobjekt läuft, kann der Betrieb der automatisierten Testeinrichtung an ein nicht deterministisches Verhalten (z. B. nicht deterministisches oder nichtvorhersagbares Timing) des Auf-Chip-System-Tests, der auf dem Testobjekt läuft, angepasst werden. Beispielsweise kann nicht bekannt sein, in welcher Reihenfolge die Abschnitte eines Auf-Chip-System-Tests, der auf dem Testobjekt läuft, ausgeführt werden, da dies von Faktoren abhängig sein kann, die schwer vorherzusagen oder sogar unmöglich vorherzusagen sind. Dementsprechend kann das Testobjekt der automatisierten Testeinrichtung Steuerinformationen bereitstellen, um Details bezüglich der Ausführung des Auf-Chip-System-Tests zu signalisieren, um auf diese Weise zu ermöglichen, dass die automatisierte Testeinrichtung entsprechend antwortet (durch Bereitstellen von geeigneten Stimulussignalen).
  • Auf diese Weise kann die automatisierte Testeinrichtung sich gut an die nicht deterministische Natur des Auf-Chip-System-Tests anpassen.
  • Bei einem bevorzugten Ausführungsbeispiel ist die automatisierte Testeinrichtung dazu konfiguriert, auf ein Abschließen eines Auf-Chip-System-Tests zu warten, der auf dem Testobjekt läuft.
  • Durch Warten auf das Abschließen eines Auf-Chip-System-Tests, der auf dem Testobjekt läuft, kann eine Synchronizität zwischen der (typischerweise nicht deterministischen) Ausführung des Auf-Chip-System-Tests und der Funktionalität der automatisierten Testeinrichtung erzielt werden.
  • Figurenliste
  • Ausführungsbeispiele gemäß der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf die beigefügten Figuren beschrieben, wobei Folgendes gilt:
    • 1 zeigt ein Blockschema einer automatisierten Testeinrichtung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
    • 2 zeigt ein Blockschema einer automatisierten Testeinrichtung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
    • 3 zeigt eine schematische Darstellung einer Entwicklungs- und Debug-Umgebung zur Verwendung bei der automatisierten Testeinrichtung gemäß 2;
    • 4 zeigt ein Blockschema eines Ein-Chip-Systems, das unter Verwendung der hier offenbarten automatisierten Testeinrichtung getestet werden kann;
    • 5 zeigt ein Blockschema eines Moduls, das unter Verwendung der hier beschriebenen automatisierten Testeinrichtung getestet werden kann;
    • 6 zeigt eine schematische Darstellung eines Auf-Chip-System-Tests;
    • 7 zeigt eine schematische Darstellung eines ersten Szenarios, bei dem ein analoger Test und/oder ein HF-Empfänger-Test durchgeführt wird;
    • 8 zeigt eine schematische Darstellung eines zweiten Szenarios, bei dem ein analoger Test und/oder ein HF-Sender-Test durchgeführt wird;
    • 9 zeigt eine schematische Darstellung eines dritten Szenarios, bei dem ein parametrischer Hochgeschwindigkeits-I/O(HSIO)-Test durchgeführt wird;
    • 10 zeigt eine schematische Darstellung eines vierten Szenarios, bei dem ein Hochgeschwindigkeits-I/O(HSIO)-Protokoll-Engine-Test durchgeführt wird;
    • 11 zeigt eine schematische Darstellung eines fünften Szenarios, bei dem ein Verbindungsbelastungstest durchgeführt wird;
    • 12 zeigt eine schematische Darstellung eines Auf-Chip-System-Tests (OCST) mit einer Betriebssystemumgebung;
    • 13 zeigt eine schematische Darstellung einer Boot-Sequenz eines eingebetteten Betriebssystems;
    • 14 zeigt eine schematische Darstellung eines Auf-Chip-System-Tests mit einer Bare-Metal-Umgebung;
    • 15 zeigt eine schematische Darstellung eines Eingebettetes-Bare-Metal-Boot über einen Debug-Port; und
    • 16 zeigt ein Blockschema eines physischen OCST-Steuergeräts.
  • Ausführliche Beschreibung der Ausführungsbeispiele
  • Automatisierte Testeinrichtung gemäß Fig. 1
  • 1 zeigt ein Blockschema einer automatisierten Testeinrichtung 100 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Es ist festzustellen, dass die automatisierte Testeinrichtung 100 dahingehend angepasst ist, ein Testobjekt 104 zu test, bei dem es sich beispielsweise um ein Ein-Chip-System (SoC) handeln kann.
  • Die automatisierte Testeinrichtung 100 weist ein Auf-Chip-System-Teststeuergerät 110 auf. Das Auf-Chip-System-Teststeuergerät 110 weist zumindest eine Debug-Schnittstelle oder Steuerschnittstelle 112 auf, die dazu konfiguriert ist, mit dem Testobjekt 104 zu kommunizieren. Darüber hinaus weist das Auf-Chip-System-Teststeuergerät 110 außerdem optional zumindest eine Schnittstelle mit hoher Bandbreite 114 auf (die beispielsweise eine USB-Schnittstelle oder eine PCI-Schnittstelle oder eine PCI-express-Schnittstelle oder eine PCI-express-kompatible Schnittstelle oder eine Thunderbolt-Schnittstelle oder eine Ethernet-Schnittstelle oder eine IEEE-1394-Schnittstelle oder eine SATA-Schnittstelle oder eine IEEE-1149-Schnittstelle oder eine IEEE-1500-Schnittstelle oder eine IEEE-1687-Schnittstelle sein kann).
  • Darüber hinaus ist festzustellen, dass das Auf-Chip-System-Teststeuergerät 110 dazu konfiguriert ist, den Test des Testobjekts 104 zu steuern, bei dem es sich um ein Ein-Chip-System handelt.
  • Da zwei oder mehr unterschiedliche Schnittstellen für eine Kommunikation mit dem Testobjekt 104 zur Verfügung stehen, kann das Auf-Chip-System-Teststeuergerät 110 in der Lage sein, das Testobjekt 104 auf einer sehr niedrigen Ebene, z. B. einer Hardwareebene, zu steuern (zum Beispiel über eine Debug-Schnittstelle, die direkten Zugriff auf eine Hardwarekomponente des Testobjekts hat), und das Auf-Chip-System-Teststeuergerät ist außerdem in der Lage, große Mengen von Programmcode oder Daten mit hoher Geschwindigkeit über die Schnittstelle mit hoher Bandbreite in Richtung des Testobjekts 104 zu kommunizieren. Auf diese Weise kann das Auf-Chip-System-Teststeuergerät sowohl Testaufgaben, die einen Hardwarezugriff zu dem Testobjekt auf niedriger Ebene erfordern (vorzugsweise unter Verwendung der Debug-Schnittstelle oder Steuerschnittstelle 112), als auch Testaufgaben verwalten, die eine Kommunikation mit hoher Bandbreite erfordern, die typischerweise durch eine Software (zum Beispiel ein Auf-Chip-System-Testprogramm) gesteuert wird, die auf dem Testobjekt 104 ausgeführt wird. Somit kann das Testobjekt unter der Steuerung des Auf-Chip-System-Teststeuergeräts 110 mit hoher Abdeckung getestet werden.
  • Darüber hinaus können durch Verwendung eines dedizierten Auf-Chip-System-Teststeuergeräts 110, der zum Steuern des Tests die Debug-Schnittstelle oder Steuerschnittstelle 112 und die Schnittstelle mit hoher Bandbreite 114 aufweist, Engpässe bei der automatisierten Testeinrichtung vermieden werden und ein hohes Synchronisationsmaß zwischen einer Steuerung, die unter Verwendung der Debug-Schnittstelle oder der Steuerschnittstelle 112 ausgeübt wird, und einem Datenaustausch unter Verwendung einer Schnittstelle mit hoher Bandbreite 114 erzielt werden. Auf diese Weise wird mit einem Auf-Chip-System-Teststeuergerät 110, das sowohl die Schnittstelle 112 als auch die Schnittstelle 114 aufweist, eine hocheffiziente Struktur bereitgestellt.
  • Darüber hinaus ist festzustellen, dass die automatisierte Testeinrichtung 100 optional durch beliebige Funktionen, Funktionalitäten und Details, die hierin offenbart sind, sowohl individuell als auch in Kombination ergänzt werden kann.
  • Automatisierte Testeinrichtung gemäß Fig. 2
  • 2 zeigt ein Blockschema einer automatisierten Testeinrichtung 200 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
  • Die automatisierte Testeinrichtung 200 weist ein Auf-Chip-System-Teststeuergerät 210 auf, der beispielsweise dem Auf-Chip-System-Teststeuergerät 110 entsprechen kann. Darüber hinaus weist die automatisierte Testeinrichtung 200 eine Testobjektschnittstelle 216 auf, die beispielsweise die Funktionalität der Schnittstellen 112, 114 kombinieren kann. Die automatisierte Testeinrichtung 200 weist ferner eine oder mehrere parametrische Testressourcen oder analoge Testressourcen 220 und eine oder mehrere digitale Testressourcen 230 auf. Die automatisierte Testeinrichtung weist ferner eine Entwicklungs- und Debug-Umgebung 240 auf.
  • Im Folgenden wird das Auf-Chip-System-Teststeuergerät 210 ausführlicher beschrieben. Das Auf-Chip-System-Teststeuergerät 210 weist beispielsweise eine Zentraleinheit 250 auf, die beispielsweise ein Ein-Chip-System sein kann. Jedoch kann die Zentraleinheit 250 auch unter Verwendung eines Mikroprozessors, unter Verwendung einer anwendungsspezifischen individuellen Schaltung oder unter Verwendung eines feldprogrammierbaren Gatterarrays implementiert sein. Das Auf-Chip-System-Teststeuergerät 210 weist ferner eine Debug-Schnittstelle 252, eine Steuerschnittstelle 254 und optional eine Schnittstelle mit hoher Bandbreite 256 auf. Darüber hinaus weist das Auf-Chip-System-Teststeuergerät einen Softwarestapel 258 auf, der durch die Zentraleinheit 250 oder sogar durch mehrere Zentraleinheiten oder Zentralverarbeitungseinheiten ausgeführt werden kann. Darüber hinaus kann das Auf-Chip-System-Teststeuergerät 210 ein Software-Repository 260 aufweisen, das DUT-Software aufweist, d. h. Software, die durch eine Zentralverarbeitungseinheit des Testobjekts ausgeführt werden soll.
  • Es ist jedoch festzustellen, dass das Auf-Chip-System-Teststeuergerät nicht unbedingt alle Komponenten 250, 252, 254, 256, 258, 260 aufweisen muss. Vielmehr kann optional eine oder mehrere der genannten Komponenten weggelassen oder geändert werden.
  • Im Folgenden werden einige zusätzliche Details der unterschiedlichen Komponenten beschrieben.
  • Insbesondere ist festzustellen, dass Signale, die durch die Debug-Schnittstelle 252 dem Testobjekt bereitgestellt werden, oder Signale, die durch die Debug-Schnittstelle 252 von dem Testobjekt empfangen werden, variabel der Testobjektschnittstelle 216 zugewiesen werden können, beispielsweise unter Verwendung einer konfigurierbaren Routingmatrix. Auf ähnliche Weise kann ein oder mehrere Signale, die durch die Steuerschnittstelle 254 dem Testobjekt bereitgestellt werden, und/oder ein oder mehrere Signale, die durch die Steuerschnittstelle 254 von dem Testobjekt empfangen werden, der Testobjektschnittstelle 216 variabel zugewiesen werden. In ähnlicher Weise kann ein oder mehrere Signale, die durch die Schnittstelle mit hoher Bandbreite 256 dem Testobjekt bereitgestellt werden, und/oder ein oder mehrere Signale, die durch die Schnittstelle mit hoher Bandbreite 256 von dem Testobjekt empfangen werden, der Testobjektschnittstelle 216 variabel zugewiesen werden. Dementsprechend kann das Auf-Chip-System-Teststeuergerät (oder allgemein die automatisierte Testeinrichtung) einen oder mehrere Testobjekt-Ports der Debug-Schnittstelle 252 und/oder der Steuerschnittstelle 254 und/oder der Schnittstelle mit hoher Bandbreite 256 variabel Pins der Testobjektschnittstelle 216 zuweisen, beispielsweise unter Verwendung einer einstellbaren Routingmatrix.
  • Der Softwarestapel 258, der beispielsweise durch die Zentraleinheit 250 ausgeführt werden kann, kann eine Mehrzahl von Schichten aufweisen. Beispielsweise kann der Softwarestapel ein Betriebssystem, eine Auf-Chip-System-Testdienstsoftware und Treiber zum Kommunizieren mit dem Testobjekt aufweisen. Beispielsweise kann das Betriebssystem die Gesamtausführung der Software steuern. Die Auf-Chip-System-Testdienstsoftware kann beispielsweise eine Kommunikation mit anderen Testgerätressourcen (oder Testressourcen) steuern und/oder mit einem Höhere-Hierarchische-Ebene-Steuergerät (beispielsweise einer Workstation, die einen gesamten Testvorgang steuert). Die Auf-Chip-System-Testdienstsoftware kann beispielsweise eine Evaluierung von Testergebnissen auf Basis der von dem Testobjekt erhaltenen Daten durchführen.
  • Die Treiber, die auch Teil des Softwarestapels 258 sind, können beispielsweise eine Kommunikation mit dem Testobjekt über die Debug-Schnittstelle 252 und/oder über die Steuerschnittstelle 254 und/oder über die Schnittstelle mit hoher Bandbreite 256 steuern. In einigen Fällen können die Treiber sogar so gestaltet sein, dass dieselben in Abhängigkeit von dem eigentlichen Typ der physischen Schnittstelle eine gemeinsame Schnittstelle für Software auf hoher Ebene bereitstellen. Auf diese Weise kann ein Treiber beispielsweise den eigentlichen Typ einer Schnittstelle mit hoher Bandbreite gegenüber der Software höherer Ebene „verbergen“, so dass es nicht nötig ist, eine Software höherer Ebene an einen bestimmten Typ von Schnittstelle mit hoher Bandbreite anzupassen. Dementsprechend helfen die Treiber dabei, eine Softwareentwicklung einfach zu halten und zu vermeiden, dass der Softwaredesigner Details über die physische Schnittstelle zwischen dem Auf-Chip-System-Teststeuergerät und dem Testobjekt kennen muss. Darüber hinaus kann der Softwarestapel 258 außerdem eine oder mehrere anwendungsspezifische Routinen aufweisen, die durch einen Benutzer bereitgestellt werden. Die anwendungsspezifischen Routinen, die durch den Benutzer bereitgestellt werden, können an einen Test eines bestimmten Testobjekttyps angepasst werden. Die anwendungsspezifischen Routinen, die durch einen Benutzer bereitgestellt werden, können auf Funktionen beruhen, die durch das Betriebssystem bereitgestellt werden, und können außerdem in der Lage sein, unter Verwendung der Treiber des Softwarestapels mit dem Testobjekt zu kommunizieren.
  • Es ist festzustellen, dass das Auf-Chip-System-Teststeuergerät 210 ein hohes Maß an Interaktion und Kommunikation mit dem Testobjekt durchführen kann, beispielsweise unter Verwendung des Softwarestapels 258. Beispielsweise kann das Auf-Chip-System-Teststeuergerät 210 ein oder mehrere Programme und/oder Testparametersätze auf das Testobjekt hochladen, wobei die Debug-Schnittstelle 252 und/oder die Steuerschnittstelle 254 und/oder die Schnittstelle mit hoher Bandbreite 256 dazu verwendet werden können, ein oder mehrere Programme und/oder Testparametersätze über die Testobjektschnittstelle 216 auf das Testobjekt hochzuladen. Beispielsweise kann das eine oder die mehreren Programme und/oder Testparametersätze, die auf das Testobjekt hochgeladen werden sollen, aus dem Software-Repository 260 entnommen werden, das Teil des Auf-Chip-System-Teststeuergeräts sein kann und das eine DUT-Software speichern kann. Beispielsweise kann das Auf-Chip-System-Teststeuergerät dazu konfiguriert sein, eine Auf-Chip-System-Testumgebung auf das Testobjekt hochzuladen, und kann außerdem dazu konfiguriert sein, einen oder mehrere Auf-Chip-System-Tests über die Testobjektschnittstelle 216 auf das Testobjekt hochzuladen. Beispielsweise kann die Auf-Chip-System-Testumgebung die Rolle eines Betriebssystems auf dem Testobjekt übernehmen und kann beispielsweise einen oder mehrere Treiber auf dem Testobjekt bereitstellen, um mit der automatisierten Testeinrichtung zu kommunizieren. Darüber hinaus können die individuellen Auf-Chip-System-Tests beispielsweise Schritte (oder Teilschritte) einer gesamten Testprozedur definieren, die zum Testen des Testobjekts ausgeführt wird.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät 210 beispielsweise einen oder mehrere Auf-Chip-System-Tests starten, wobei unterschiedliche Konzepte angewendet werden können. Der eine oder die mehreren Auf-Chip-System-Tests können beispielsweise durch einen Hardwarezugriff auf das Testobjekt ausgelöst (oder gestartet) werden, der beispielsweise über die Debug-Schnittstelle 252 durchgeführt werden kann (und der beispielsweise ein oder mehrere Register einer CPU des Testobjekts betreffen kann). Alternativ kann ein oder mehrere Auf-Chip-System-Tests gestartet werden, indem ein entsprechender Befehl an die Auf-Chip-System-Testumgebung bereitgestellt wird, die anfänglich auf das Testobjekt hochgeladen wird und auf dem Testobjekt läuft.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät außerdem einen Test des Testobjekts steuern, beispielsweise auf der Basis eines gesamten Testausführungsprogramms. Beispielsweise kann das Auf-Chip-System-Teststeuergerät 210 Parameter für die Auf-Chip-System-Testprogramme anpassen, eine Ausführung einer Mehrzahl von Auf-Chip-System-Testprogrammen zeitlich planen, eine Ausführung eines oder mehrerer Auf-Chip-System-Testprogramme unterbrechen, falls angemessen, und so weiter.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät 250 außerdem weitere Auf-Chip-System-Testprogramme hochladen, ansprechend auf ein Abschließen eines oder mehrerer zuvor ausgeführter Auf-Chip-System-Testprogramme.
  • Die Steuerung des Tests des Testobjekts kann über einen Hardwareebenenzugriff auf das Testobjekt (zum Beispiel über die Debug-Schnittstelle) und/oder unter Verwendung von Befehlen durchgeführt werden, die an eine Auf-Chip-System-Testumgebung gesendet werden, die auf dem Testobjekt läuft.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät 210 außerdem Befehle und/oder Steuerinformationen von dem Testobjekt über eine der Schnittstellen 252, 254, 256 empfangen und auf die Befehle und/oder Steuerinformationen reagieren. Beispielsweise kann das Testobjekt eine Anpassung von bestimmten Testbedingungen anfordern (zum Beispiel eine Versorgungsspannung oder eine Taktfrequenz) und das Auf-Chip-System-Teststeuergerät 210 kann auf derartige Befehle oder Steuerinformationen antworten, indem die Testumgebung entsprechend angepasst wird.
  • Darüber hinaus kann das Auf-Chip-System-Teststeuergerät 210 außerdem Daten von dem Testobjekt empfangen (beispielsweise unter Verwendung einer der Schnittstellen 252, 254, 256). Das Auf-Chip-System-Teststeuergerät 210 kann die Daten für die Entscheidung verwenden, ob das Testobjekt die Anforderung erfüllt (d. h. um zu entscheiden, ob das Testobjekt als akzeptabel oder als fehlerhaft eingeordnet werden soll). Darüber hinaus kann das Auf-Chip-System-Teststeuergerät außerdem die von dem Testobjekt empfangenen Daten verwenden, um einen Testausführungsablauf in Abhängigkeit von den Daten anzupassen. Beispielsweise kann ein Testausführungsablauf ansprechend auf einen Vergleich der Daten, die von dem Testobjekt empfangen werden, mit Referenzdaten angepasst werden. Beispielsweise können die von dem Testobjekt empfangenen Daten eine Testausführung charakterisieren und können beispielsweise Charakteristika von Signalen beschreiben, die von dem Testobjekt empfangen werden (beispielsweise ein Signal-Rauschen-Verhältnis, eine Bit-Fehler-Rate oder dergleichen). Beispielsweise kann die Anpassung des Testablaufs durch die anwendungsspezifischen Routinen durchgeführt werden, die durch den Benutzer bereitgestellt werden. Jedoch sind abhängig von den Daten, die von dem Testobjekt empfangen werden, unterschiedliche Konzepte zum Anpassen des Testausführungsablaufs möglich.
  • Es ist jedoch festzustellen, dass das Auf-Chip-System-Teststeuergerät 210 nicht unbedingt alle hierin beschriebenen Funktionalitäten implementieren muss. Vielmehr kann es bei einigen Ausführungsbeispielen ausreichend sein, wenn das Auf-Chip-System-Teststeuergerät eine oder mehrere der hier beschriebenen Funktionalitäten implementiert. Andererseits könnte das Auf-Chip-System-Teststeuergerät auch über verschiedene Funktionalitäten verfügen, die hier nicht beschrieben sind.
  • Darüber hinaus ist festzustellen, dass das Auf-Chip-System-Teststeuergerät außerdem eine oder mehrere zusätzliche Testressourcen steuern und/oder synchronisieren kann. Beispielsweise kann das Auf-Chip-System-Teststeuergerät eine oder mehrere parametrische Testressourcen oder analoge Testressourcen 220, beispielsweise eine Leistungsversorgung, eine Spannungsquelle, eine Stromquelle, eine Spannungsmessvorrichtung oder eine Strommessvorrichtung, steuern und/oder synchronisieren. Beispielsweise kann das Auf-Chip-System-Teststeuergerät die eine oder die mehreren parametrischen Testressourcen abhängig von einem Programm steuern, das durch die Zentraleinheit 250 des Auf-Chip-System-Teststeuergeräts ausgeführt wird. Das Auf-Chip-System-Teststeuergerät kann beispielsweise selbst entscheiden, wie die eine oder die mehreren parametrischen Testressourcen festgelegt werden, oder das Auf-Chip-System-Teststeuergerät kann die eine oder die mehreren parametrischen Testressourcen abhängig von Befehlen oder Steuerinformationen festlegen, die von dem Testobjekt empfangen werden (d. h. ansprechend auf eine Anforderung von dem Testobjekt). Es ist jedoch festzustellen, dass die parametrischen Testressourcen oder analogen Testressourcen außerdem ein Erzeugen von Hochfrequenzsignalen oder ein Empfangen und/oder eine Evaluierung von Hochfrequenzsignalen aufweisen können. Ähnlich weisen die parametrischen Testressourcen somit ein Erzeugen oder ein Empfangen oder eine Evaluierung von optischen Signalen auf, die beim Testen des Testobjekts verwendet werden.
  • Auf ähnliche Weise kann das Auf-Chip-System-Teststeuergerät eine oder mehrere digitale Testressourcen 230 steuern und/oder synchronisieren, die beispielsweise digitale Stimulussignale zum Testen des Testobjekts bereitstellen, und/oder digitale Antwortsignale von dem Testobjekt evaluieren. Es ist jedoch festzustellen, dass die parametrischen Testressourcen/analogen Testressourcen 220 und die digitalen Testressourcen 230 außerdem mit der Testobjektschnittstelle 216 unter Verwendung einer variablen Zuweisung gekoppelt sein können, so dass die parametrischen Testressourcen/analogen Testressourcen und/oder die digitalen Testressourcen auf variable Weise mit unterschiedlichen Pins der Testobjektschnittstelle 216 gekoppelt werden können.
  • Jedoch kann das Auf-Chip-System-Teststeuergerät 210 dazu konfiguriert sein, die parametrischen Testressourcen/analogen Testressourcen 220 und/oder die digitalen Testressourcen 230 unter Verwendung einer oder mehrerer „lokaler“ Kommunikationsschnittstellen zu steuern und/oder zu synchronisieren, die nicht gemeinschaftlich mit anderen Auf-Chip-System-Teststeuergeräten verwendet werden, die in der automatisierten Testeinrichtung vorhanden sein können. Dementsprechend kann das Auf-Chip-System-Teststeuergerät eine sehr gute Echtzeitfähigkeit aufweisen, wenn die parametrischen Testressourcen/analogen Testressourcen 220 und/oder die digitalen Testressourcen 230 gesteuert und/oder synchronisiert werden.
  • Darüber hinaus ist festzustellen, dass die automatisierte Testeinrichtung eine Synchronisation des Auf-Chip-System-Teststeuergeräts des Testobjekts und der zusätzlichen Testressourcen 220, 230 vorsehen kann. Beispielsweise kann eine andere Komponente der automatisierten Testeinrichtung Synchronisationssignale für das Auf-Chip-System-Teststeuergerät, das Testobjekt und die anderen Testressourcen 220, 230 bereitstellen. Dementsprechend kann ein hohes Maß an Synchronisation erreicht werden.
  • Im Folgenden wird die Entwicklungs- und Debug-Umgebung 240, die optional in der automatisierten Testeinrichtung 200 beinhaltet sein kann, unter Bezugnahme auf 3 beschrieben.
  • Die Entwicklungs- und Debug-Umgebung 240 kann beispielsweise dahingehend angepasst sein, sowohl eine Auf-Chip-System-Testsoftware zur Ausführung auf dem DUT, die beispielsweise in dem Software-Repository 260 gespeichert sein kann, als auch ein Testprogramm zur Ausführung auf der automatisierten Testeinrichtung bereitzustellen (beispielsweise zur Ausführung in dem Softwarestapel 258). Jedoch kann die Entwicklungs- und Debug-Umgebung auch Steuerinformationen bereitstellen, die durch das Auf-Chip-System-Teststeuergerät 210 berücksichtigt werden können.
  • Die Entwicklungs- und Debug-Umgebung 240 kann beispielsweise eine Benutzerschnittstelle aufweisen, um es einem Software-Engineer zu ermöglichen, eine Auf-Chip-System-Testsoftware und/oder Testprogramme zu entwickeln. Außerdem kann die Entwicklungs- und Debug-Umgebung optional eine Schnittstelle 242 aufweisen, die dahingehend angepasst ist, es einer Debug-Software zu ermöglichen, ein Hochladen eines Programms auf das Testobjekt zu steuern. Somit kann die Entwicklungs- und Debug-Umgebung 240 mit einer Drittanbieter-Debug-Software kooperieren, um ein effizientes Debuggen einer Auf-Chip-System-Testsoftware zu ermöglichen. Darüber hinaus weist die Entwicklungs- und Debug-Umgebung 240 außerdem eine Schnittstelle 244 auf, um es einer Debug-Software zu ermöglichen, auf eine Debug-Schnittstelle des DUT zuzugreifen. Beispielsweise kann der Zugriff auf die Debug-Schnittstelle des DUT über das Auf-Chip-System-Teststeuergerät erfolgen, das direkten Zugriff auf die Debug-Schnittstelle 252 hat.
  • Darüber hinaus kann die Entwicklungs- und Debug-Umgebung einen Software-Engineer sowohl bei der Entwicklung einer Auf-Chip-System-Testsoftware, die auf dem Testobjekt ausgeführt werden soll, als auch bei der Entwicklung eines Testprogramms zur Ausführung auf der automatisierten Testeinrichtung unterstützen.
  • Zu diesem Zweck kann die Entwicklungs- und Debug-Umgebung einen Programmcode aufweisen, um einen Zugriff auf Testressourcen der ATE bereitzustellen. Beispielsweise kann der Programmcode 246a es einem Testobjekt ermöglichen, über das Auf-Chip-System-Teststeuergerät auf Testressourcen der ATE zuzugreifen, so dass beispielsweise das Testobjekt Charakteristika der Testressourcen 220 und/oder 230 unter Verwendung eines Funktionsaufrufs an das Programm 246a ändern kann, der auf die Anforderung eines Software-Engineers hin durch die Entwicklungs- und Debug-Umgebung in die Auf-Chip-System-Testsoftware aufgenommen werden kann.
  • Darüber hinaus kann die Entwicklungs- und Debug-Umgebung auch ein Programm 246b aufweisen, um ein Hochladen weiterer Software von der automatisierten Testeinrichtung auf das Testobjekt zu ermöglichen. Beispielsweise kann das Programm 246b eine Schnittstelle mit hoher Bandbreite des Testobjekts dazu konfigurieren, einen Programmcode zu empfangen, der auf dem Testobjekt ausgeführt werden soll. Dieses Programm 246b kann auf die Anforderung eines Software-Engineers hin in die Auf-Chip-System-Testsoftware aufgenommen werden. Dementsprechend kann die Entwicklungs- und Debug-Umgebung ein Programm, das ein Hochladen weiterer Software von der automatisierten Testeinrichtung (z. B. von dem Software-Repository des Auf-Chip-System-Teststeuergeräts) auf das Testobjekt ermöglicht, in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung (zum Beispiel auf dem Auf-Chip-System-Teststeuergerät) aufnehmen. Dementsprechend kann die Entwicklungs- und Debug-Umgebung zusammenpassende Programmcodes zur Aufnahme in die Auf-Chip-System-Testsoftware und in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung umfassen.
  • Darüber hinaus weist die Entwicklungs- und Debug-Umgebung ein Programm 246c auf, um eine Steuerung einer Programmausführung auf dem Testobjekt zu ermöglichen. Beispielsweise kann das Programm 246c auf die Anforderung eines Software-Engineers hin in die Auf-Chip-System-Testsoftware aufgenommen werden. Das Programm 246c kann beispielsweise dahingehend angepasst werden, Programmsteuerbefehle von dem Auf-Chip-System-Teststeuergerät über eine der Schnittstellen des Testobjekts zu empfangen.
  • Jedoch kann die Auf-Chip-System-Testsoftware beispielsweise ein entsprechendes Programm in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung aufnehmen. Dementsprechend kann die Ausführung eines Programms auf dem Testobjekt von der Seite des Auf-Chip-System-Teststeuergeräts aus gesteuert werden, wobei es „zusammenpassende“ Programmmodule gibt, die auf die Anfrage des Software-Engineers hin in die Auf-Chip-System-Testsoftware und in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung aufgenommen werden.
  • Darüber hinaus weist die Entwicklungs- und Debug-Umgebung ein Programm 246d auf, das dahingehend angepasst ist, eine Programmausführung auf dem Testobjekt zu überwachen. Beispielsweise kann das Programm 246d auf die Anforderung eines Software-Engineers hin in die Auf-Chip-System-Testsoftware aufgenommen werden. Das Programm 246d kann beispielsweise überwachen, ob die Auf-Chip-System-Testsoftware korrekt ausgeführt wird oder ob die Auf-Chip-System-Testsoftware in einem Ausfallzustand ist. Dementsprechend kann das Programm 246d das Auf-Chip-System-Teststeuergerät darüber informieren, ob die Software, die auf dem Testobjekt läuft, in einem Ausfallzustand ist, und das Auf-Chip-System-Teststeuergerät kann entsprechend reagieren (beispielsweise, indem eine Vorrichtung als fehlerhaft eingeordnete wird oder das Testobjekts zurückgesetzt wurde oder eine neue Auf-Chip-System-Testsoftware auf dem Testobjekt hochgeladen oder gestartet wird).
  • Die Entwicklungs- und Debug-Umgebung weist außerdem ein Programm 246e auf, um einen Zugriff auf einen Speicherinhalt (z. B. der ATE) von dem Auf-Chip-System über eine Schnittstelle der automatisierten Testeinrichtung zu ermöglichen. Dieses Programm kann auf die Aufforderung eines Software-Engineers hin in die Auf-Chip-System-Testsoftware aufgenommen werden. Dementsprechend kann das Testobjekt Daten aus einem Speicher der automatisierten Testeinrichtung auslesen (z. B. aus einem Speicher des Auf-Chip-System-Teststeuergeräts), indem der Programmcode 246e aufgerufen wird. Alternativ oder zusätzlich kann das Testobjekt Daten in den Speicher der automatisierten Testeinrichtung (z. B. des Auf-Chip-System-Teststeuergeräts) schreiben, indem der Programmcode 246e aufgerufen wird. Darüber hinaus kann die Entwicklungs- und Debug-Umgebung außerdem ein Programm oder Konfigurationsinformationen für das Auf-Chip-System-Teststeuergerät bereitstellen, um diesen Zugriff des Testobjekts auf den Speicher der automatisierten Testeinrichtung zu unterstützen, wobei sichergestellt werden kann, dass der Programmcode, der in die Auf-Chip-System-Testsoftware (zur Ausführung auf dem DUT) aufgenommen wurde, und die Konfigurationsinformationen des Auf-Chip-System-Teststeuergeräts übereinstimmen.
  • Die Entwicklungs- und Debug-Umgebung kann außerdem eine Anwendungsprogrammierschnittstelle 246f aufweisen, die eine Kommunikation zwischen dem Testobjekt und Testressourcen (z. B. Testressourcen 220, 230) der automatisierten Testeinrichtung ermöglicht. Dementsprechend kann durch Verwendung dieser Anwendungsprogrammierschnittstelle 246f auf die Anforderung des Software-Engineers hin das Testobjekt in die Lage versetzt werden, Testressourcen der automatisierten Testeinrichtung zu steuern.
  • Darüber hinaus weist die Entwicklungs- und Debug-Umgebung außerdem eine Testgerätsoftware 246g auf, um eine Kommunikation der automatisierten Testeinrichtung mit dem Testobjekt zu unterstützen. Diese Testgerätsoftware 246g kann beispielsweise auf die Aufforderung eines Software-Engineers hin in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung aufgenommen werden und die Kommunikation zwischen der automatisierten Testeinrichtung und dem Testobjekt unterstützen.
  • Darüber hinaus weist die Entwicklungs- und Debug-Umgebung außerdem ein Programm 246h auf, um ein Hochladen eines Parametersatzes von der ATE auf ein DUT zu ermöglichen. Dementsprechend können Parameter für eine Ausführung eines Auf-Chip-System-Tests (z. B. unter Verwendung von Programm 246d hochgeladen und durch Programm 246c gestartet) aktualisiert werden, z. B. zwischen aufeinanderfolgenden Ausführungen des Auf-Chip-System-Tests, um auf diese Weise die Notwendigkeit von mehreren Hochladevorgängen ähnlicher Auf-Chip-System-Tests zu überwinden, die sich lediglich durch eine Anzahl von Parametern unterscheiden.
  • Abschließend lässt sich sagen, dass die Entwicklungs- und Debug-Umgebung 240 eine Anzahl von Softwareblöcken 246a bis 246h aufweisen kann, die die Entwicklung einer Auf-Chip-System-Testsoftware und außerdem eines Testprogramms zur Ausführung auf der automatisierten Testeinrichtung unterstützen. Beispielsweise können zusammenpassende Softwarekomponenten automatisch durch die Entwicklungs- und Debug-Umgebung sowohl in die Auf-Chip-System-Testsoftware als auch in das Testprogramm zur Ausführung auf der automatisierten Testeinrichtung eingeführt werden, wobei beispielsweise Parametersätze der Komponenten ebenfalls automatisch durch die Entwicklungs- und Debug-Umgebung auf geeignete Werte eingestellt werden können.
  • Es ist jedoch festzustellen, dass die Entwicklungs- und Debug-Umgebung nicht unbedingt erfordert, dass alle hierin beschriebenen Softwareabschnitte 246a bis 246g enthalten sind. Vielmehr reicht es in einigen Fällen aus, dass die Entwicklungs- und Debug-Umgebung 240 einen oder mehrere der Softwareabschnitte aufweist.
  • Gemäß einem anderen Aspekt können Testparameter unabhängig von einem Laden des Auf-Chip-System-Tests selbst (z. B. um einen Parametersatz auf das Testobjekt hochzuladen) auf das Testobjekt geladen werden. Ein Auf-Chip-System-Test (OCST) kann beispielsweise geladen bleiben, jedoch müssen vor seiner nächsten Ausführung die Parameter geändert werden. Dies ist effizienter und geschieht typischerweise dann, wenn ein OCST charakterisiert wird.
  • Darüber hinaus ist festzustellen, dass die automatisierte Testeinrichtung 200, die hierin beschrieben wird, optional durch beliebige der in diesem Dokument beschriebenen Merkmale, Funktionalitäten und Details ergänzt werden kann, sowohl individuell als auch in Kombination.
  • Auf-Chip-System-Tests gemäß Fig. 6
  • 6 zeigt eine schematische Darstellung eines Auf-Chip-System-Tests gemäß einem Ausführungsbeispiel der Erfindung.
  • Der Auf-Chip-System-Test gemäß 6 basiert auf drei Hauptkomponenten, einer Workstation 610, einem Testsystem 620 und einem SoC 630. Beispielsweise kann der SoC 630 dem in 4 gezeigten SoC 400 entsprechen, so dass Bezug auf die obigen Erläuterungen genommen wird.
  • Die Workstation 610, die Teil der automatisierten Testeinrichtung sein kann, weist beispielsweise eine integrierte Entwicklungsumgebung 612 und einen integrierten Testausführer 614 auf.
  • Beispielsweise kann die integrierte Entwicklungsumgebung 612 Entwicklung, Debugging und Ausführung eines Programms für eine automatisierte Testeinrichtung aufweisen und kann außerdem Entwicklung, Debugging und Ausführung einer eingebetteten Software aufweisen. Beispielsweise kann die integrierte Entwicklungsumgebung 612 die Funktionalität der Entwicklungs- und Debug-Umgebung 240 aufweisen. Es ist jedoch festzustellen, dass ein wichtiger Unterschied zu herkömmlichen Entwicklungsumgebungen besteht, die die angegebene Entwicklungsumgebung 612 für Entwicklung, Debugging und Ausführung von eingebetteter Software zulässt, d. h. von Software, die auf dem Testobjekt 630 läuft.
  • Darüber hinaus kann der integrierte Testausführer 614 beispielsweise ein ATE-Testprogramm aufweisen und kann mit dem Testsystem 620 kooperieren. Beispielsweise kann der integrierte Ausführer ein ATE-Testprogramm ausführen, wobei das ATE-Testprogramm die Funktionalität des Testsystems 620 steuern kann und Daten (z. B. Testergebnisinformationen) von dem Testsystem 620 empfangen kann.
  • Das Testsystem 620, das typischerweise auch Teil der automatisierten Testeinrichtung ist, weist ein oder mehrere Auf-Chip-System-Teststeuergeräte 622 auf, die beispielsweise dem Auf-Chip-System-Teststeuergerät 110 oder dem Auf-Chip-System-Teststeuergerät 210 entsprechen können.
  • Das Testsystem 620 weist außerdem ein oder mehrere digitale Eingabe/Ausgabe-Instrumente (I/O-Instrumente) 624 auf, die beispielsweise den zuvor beschriebenen digitalen Testressourcen 230 entsprechen können. Darüber hinaus weist das Testsystem 620 auch ein oder mehrere analoge/Hochfrequenz (HF)-/Hochgeschwindigkeits-I/O (HSIO)-Instrumente 626 auf, die beispielsweise den parametrischen Testressourcen 220 entsprechen können.
  • Das Testsystem 620 weist außerdem ein oder mehrere digitale I/O-Instrumente 628 auf, die beispielsweise auch den digitalen Testressourcen 230 entsprechen können. Darüber hinaus weist das Testsystem 620 ein oder mehrere Vorrichtungs-Leistungsversorgungsinstrumente 629 auf, die beispielsweise den parametrischen Testressourcen 220 entsprechen können. Darüber hinaus weist das Testsystem 620 einen Synchronisationsbus 629a auf, wobei der eine oder die mehreren Auf-Chip-System-Teststeuergeräte 622, das eine oder die mehreren digitalen I/O-Instrumente 624, das eine oder die mehreren analogen/HF/HSIO-Instrumente 626, das eine oder die mehreren digitalen I/O-Instrumente 628 und das eine oder die mehreren Vorrichtungs-Leistungsversorgungsinstrumente 629 auf, die alle mit dem Synchronisationsbus 629 gekoppelt sind. Dementsprechend kann das Auf-Chip-System-Teststeuergerät 622 beispielsweise die Instrumente 624, 626, 628, 629 synchronisieren, die beispielsweise die Rolle der parametrischen Testressourcen 220 und der digitalen Testressourcen 230 übernehmen, die oben beschrieben sind.
  • Beispielsweise kann das digitale I/O-Instrument 624 mit dem Eingang/Ausgang-Multiplexer des SoC 630 gekoppelt sein und kann dem SoC ein oder mehrere digitale Signale bereitstellen und/oder ein oder mehrere digitale Signale von dem SoC 630 empfangen. Die analogen/HF/HSIO-Instrumente 626 können beispielsweise mit einer oder mehreren Peripherieschnittstellen des SoC gekoppelt sein.
  • Das eine oder die mehreren digitalen I/O-Instrumente 628 kann beispielsweise zusätzliche Signale wie ein Taktsignal, ein Rücksetzsignal und dergleichen für den SoC bereitstellen und kann außerdem dabei helfen, die Testprozedur zu steuern. Die eine oder die mehreren Vorrichtungs-Leistungsversorgungen 629 können eine oder mehrere Versorgungsspannungen für den SoC bereitstellen und können beispielsweise dazu verwendet werden, die Testumgebung des SoC zu variieren, um den SoC auf unterschiedliche Versorgungsspannungen unter der Steuerung des Auf-Chip-System-Teststeuergeräts 622 zu testen.
  • Der integrierte Testausführer 614 kann beispielsweise einen gesamten Testablauf steuern, der durch die automatisierte Testeinrichtung durchgeführt wird, und kann beispielsweise das Auf-Chip-System-Teststeuergerät 622 dazu konfigurieren, einen bestimmten Testablauf durchzuführen. Beispielsweise kann der integrierte Testausführer 614 das Auf-Chip-System-Teststeuergerät initialisieren, wobei das Auf-Chip-System-Teststeuergerät nachfolgend den Testprozess autonom durchführt und steuert. Jedoch kann der integrierte Testausführer 614 auch eine gewisse Kontrolle über die Testausführung ausüben, die durch das Auf-Chip-System-Teststeuergerät durchgeführt wird.
  • Beispielsweise kann der integrierte Testausführer 614 das Auf-Chip-System-Teststeuergerät dahingehend anweisen, eine Auf-Chip-System-Testsoftware auf das Testobjekt 640 hochzuladen, beispielsweise über eine Debug-Schnittstelle des SoC. Dementsprechend kann ein Auf-Chip-System-Testcode (auch als Auf-Chip-System-Testprogramm oder kurz als Auf-Chip-System-Test bezeichnet) auf dem Testobjekt 30 ausgeführt werden, wobei die Ausführung durch den CPU-Kern des SoC durchgeführt werden kann, unter Verwendung der Speicher des SoC (zum Beispiel unter Verwendung des SRAM, des L2-Cache und des NVRAM).
  • Der Auf-Chip-System-Testcode, der durch den SoC ausgeführt wird, kann beispielsweise in der integrierten Entwicklungsumgebung 612 entwickelt und einem Debugging unterzogen werden und kann unter der Steuerung des integrierten Testausführers über das OCST-Steuergerät 622 und die Debug-Schnittstelle des SoC auf den SoC hochgeladen werden.
  • Abschließend lässt sich sagen, dass die hierin beschriebene automatisierte Testeinrichtung einen Test eines SoC (oder allgemein gesagt eines Testobjekts) durchführen kann, wobei das OCST-Steuergerät einen wichtigen Teil bei der Steuerung des Tests übernimmt und für eine Synchronisation eines oder mehrerer Instrumente verantwortlich sein kann. Das OCST-Steuergerät kann außerdem eine Auf-Chip-System-Testsoftware auf das Testobjekt hochladen, wobei eine Entwicklung der Auf-Chip-System-Testsoftware („eingebettete Software“) beispielsweise unter Verwendung der Workstation 612 durchgeführt wird, die Teil der automatisierten Testeinrichtung ist. Ein gesamter Testablauf kann durch ein ATE-Testprogramm gesteuert werden, das ebenfalls durch die Workstation 610 unter Verwendung eines integrierten Testausführers 614 ausgeführt wird.
  • Da ein OCST-Steuergerät 622 vorhanden ist, das für die direkte Kommunikation mit dem Testobjekt und außerdem (optional) für die Synchronisation einer Mehrzahl von Instrumenten verantwortlich ist, können Kommunikationsengpässe vermieden und ein hoher Durchsatz erzielt werden, was für viele moderne Testobjekte wünschenswert ist, die Schnittstellen mit hoher Bandbreite verwenden.
  • Es ist jedoch festzustellen, dass der in 6 gezeigte Auf-Chip-System-Test optional durch beliebige der hierin offenbarten Merkmale, Funktionalitäten und Details ergänzt werden kann, sowohl individuell als auch in Kombination.
  • Kernkonzepte eines Auf-Chip-System-Tests
  • Nachfolgend werden einige Kernkonzepte eines Auf-Chip-System-Tests beschrieben, die optional in einer der hier beschriebenen automatisierten Testeinrichtungen implementiert sein können.
  • Gemäß einem ersten Aspekt kann eine Entwicklungs-, Debug- und Deployment-Umgebung für eingebettetes Software in eine bestehende ATE-Teststeuergerät-Software aufgenommen werden.
  • Gemäß einem zweiten Aspekt ist es wünschenswert, eine Laufzeit und API für Testprogrammfragmente bereitzustellen, die auf der CPU bzw. den CPUs des DUT laufen.
  • Gemäß einem dritten Aspekt ist es wünschenswert, Möglichkeiten zu einer Synchronisation und einem Datentransfer zwischen den Haupttestprogrammfragmenten und dem Haupt-ATE-Testprogramm bereitzustellen, das die ATE-Instrumente steuert.
  • Gemäß einem vierten Aspekt ist es wünschenswert, dies für durchschnittliche Test-Engineers (oder Software-Engineers) leicht durchführbar zu machen. Beispielsweise ist es wünschenswert, dies für dieselben leicht durchführbar zu machen, um die erforderliche DUT-spezifische Software von der Validierungs- oder Software/Firmware-Entwicklungsgruppe derselben zu bekommen.
  • Gemäß einem fünften Aspekt ist es wünschenswert, die Umgebung in die Lage zu versetzen, auf begrenzten Ressourcen zu laufen (z. B. fehlender Speicherplatz bei dem Wafer-Sort-Test).
  • Gemäß einem sechsten Aspekt ist es wünschenswert, einsatzbereite Testprogrammfragmente für allgemeine Testherausforderungen auf einer weit verbreiteten Infrastruktur (z. B. AMBA-Bus-Belastungstest) bereitzustellen.
  • Abschließend lässt sich sagen, dass beliebige der oben beschriebenen Aspekte optional in die hierin beschriebene automatisierte Testeinrichtung eingeführt werden können, sowohl individuell als auch in Kombination.
  • Anwendungen
  • Nachfolgend werden einige Anwendungen unter Bezugnahme auf 7 bis 11 beschrieben.
  • 7 zeigt eine schematische Darstellung eines ersten Szenarios, bei dem ein analoger/HF-Empfänger-Test durchgeführt wird. In diesem Fall wird eine automatisierte Testeinrichtung verwendet, die eine Workstation 710 aufweist, die beispielsweise der Workstation 610 entsprechen kann und die außerdem ein Testsystem 720 aufweist, das beispielsweise dem Testsystem 620 entsprechen kann. Darüber hinaus kann das Testobjekt 730 beispielsweise dem Testobjekt 630 entsprechen.
  • Wie ersichtlich ist, gibt das Programm der automatisierten Testeinrichtung, das beispielsweise durch den integrierten Testausführer durchgeführt wird, dahingehend Anweisungen an das Auf-Chip-System-Teststeuergerät, einen Auf-Chip-System-Testcode auf das Testobjekt hochzuladen, der einen analogen/HF-Empfänger-Test ermöglicht. Beispielsweise kann der Auf-Chip-System-Testcode, der auf dem Testobjekt ausgeführt wird, die Peripherieschnittstelle des Testobjekts 730 für ein Empfangen von analogen Signalen oder Hochfrequenzsignalen konfigurieren.
  • Darüber hinaus kann der integrierte Testausführer einen analogen/HochfrequenzGenerator des Testsystems 720 dahingehend steuern, ein analoges Signal oder ein Hochfrequenzsignal für die Peripherieschnittstelle des Testobjekts 730 bereitzustellen. Beispielsweise können der integrierte Testausführer und die Workstation 710 den analogen/Hochfrequenz-Generator direkt steuern. Bei einem bevorzugten Ausführungsbeispiel steuert und synchronisiert das Auf-Chip-System-Teststeuergerät jedoch tatsächlich den analogen/Hochfrequenz-Generator des Testsystems. Folglich erzeugt die Peripherieschnittstelle des Testobjekts typischerweise digitale Informationen, die das empfangene analoge Signal oder Hochfrequenzsignal reflektieren (das durch die Peripherieschnittstelle empfangen wird), und der Auf-Chip-System-Testcode kann beispielsweise die digitalen Daten evaluieren, die durch die Peripherieschnittstelle bereitgestellt werden, und/oder die digitalen Daten, die von der Peripherieschnittstelle empfangen werden, für eine Evaluieren (beispielsweise durch das OCST-Steuergerät) an das Testsystem weiterleiten. Dementsprechend können Testergebnisse dem integrierten Testausführer durch das OCST-Steuergerät bereitgestellt werden, was es ermöglicht, das Testobjekt beispielsweise als okay oder als fehlerhaft zu bewerten.
  • Abschließend lässt sich sagen, dass ein analoger/HF-Empfänger-Test des Testobjekts durchgeführt werden kann, der durch einen Auf-Chip-System-Testcode unterstützt werden kann, der auf dem Testobjekt ausgeführt wird und der außerdem durch das OCST-Steuergerät unterstützt werden kann, die beispielsweise den Auf-Chip-System-Testcode auf das Testobjekt hochladen kann, den analogen/Hochfrequenz-Generator steuern kann und außerdem ein Erhalten von Ergebnisinformationen von dem Testobjekt und ein Weiterleiten von Ergebnisinformationen an die Workstation 710 durchführen kann.
  • 8 zeigt eine schematische Darstellung eines zweiten Szenarios, bei dem ein analoger/Hochfrequenz-Sender-Test durchgeführt wird.
  • In dem zweiten Szenario gibt es eine Workstation 810, die der Workstation 610 oder der Workstation 710 entsprechen kann, ein Testsystem 820, das dem Testsystem 720 oder dem Testsystem 620 entsprechen kann, und es gibt ein Testobjekt 830, das dem Testobjekt 730 oder dem Testobjekt 630 entsprechen kann. Insbesondere ist festzustellen, dass das zweite Szenario dem ersten Szenario sehr ähnlich ist.
  • Jedoch wird in dem zweiten Szenario ein Auf-Chip-Testcode auf das Testobjekt 830 (z. B. über das OCST-Steuergerät) hochgeladen, was bewirkt, dass das Testobjekt 830 ein analoges Signal oder ein Hochfrequenzsignal über eine Peripherieschnittstelle sendet. Beispielsweise werden Daten, die über die Peripherieschnittstelle des Testobjekts 830 gesendet werden sollen, durch den Auf-Chip-Testcode bereitgestellt, der auf dem Testobjekt 830 läuft. Darüber hinaus empfängt eine analoge Abtasteinrichtung/Hochfrequenz-Abtasteinrichtung des Testsystems 820 das analoge Signal oder das Hochfrequenzsignal, das durch das Testobjekt 830 erzeugt wird. Informationen über das analoge Signal oder das Hochfrequenzsignal, das durch das Testsystem 820 von dem Testobjekt 830 empfangen wird, können beispielsweise durch das OCST-Steuergerät evaluiert werden oder können an den integrierten Testausführer auf der Workstation 810 weitergeleitet werden, beispielsweise durch das OCST-Steuergerät. Dementsprechend kann beurteilt werden, beispielsweise durch das OCST-Steuergerät oder durch den integrierten Testausführer, der auf der Workstation 810 läuft, ob das analoge Signal, das durch das Testobjekt bereitgestellt wird, die Erwartungen oder Anforderungen erfüllt. Dementsprechend kann entschieden werden, ob das Testobjekt als ok oder als fehlerhaft eingeordnet werden soll.
  • Es ist festzustellen, dass hier eine Kooperation zwischen der automatisierten Testeinrichtung (die die Workstation 810 und das Testsystem 820 aufweist) und dem Testobjekt 830 gibt. Auf-Chip-Testcode (oder Auf-Chip-System-Testsoftware), der auf das Testobjekt 830 hochgeladen wird, steuert das Bereitstellen des analogen Signals oder des Hochfrequenzsignals, und das Testsystem empfängt und evaluiert das analoge Signal, vorzugsweise unter der Kontrolle des OCST-Steuergeräts, das typischerweise eine schnelle und direkte Schnittstelle zu der analogen/Hochfrequenz-Abtasteinrichtung aufweist. Da das OCST-Steuergerät typischerweise auch in der Lage ist, mit dem Testobjekt 830 auf eine sehr direkte Art zu kommunizieren, kann das OCST-Steuergerät auch über ein gewisses Maß an Kontrolle über das analoge Signal, das durch das Testobjekt bereitgestellt wird, und über das Timing, wann das analoge Signal bereitgestellt wird, verfügen.
  • Abschließend lässt sich sagen, dass die hierin offenbarte automatisierte Testeinrichtung optional dahingehend angepasst werden kann, das zweite Szenario durchzuführen.
  • 9 zeigt eine schematische Darstellung eines dritten Szenarios, bei dem ein parametrischer Hochgeschwindigkeits-I/O(HSIO)-Test durchgeführt wird. In dem dritten Szenario werden eine Workstation 910 und ein Testsystem 920 verwendet, um ein Testobjekt 930 zu testen, wobei die Workstation 910 den zuvor beschriebenen Workstations 610, 710, 810 entsprechen kann und wobei das Testsystem 920 den zuvor beschriebenen Testsystemen 620, 720, 820 entsprechen kann.
  • Jedoch kann in dem dritten Szenario ein Hochgeschwindigkeits-I/O-Instrument des Testsystems 920 dazu verwendet werden, Daten an das Testobjekt zu senden und Daten von dem Testobjekt zu empfangen. Beispielsweise kann das Hochgeschwindigkeits-I/O-Instrument des Testsystems 920 mit einer Peripherieschnittstelle (z. B. einer HSIO-Peripherieschnittstelle) des Testobjekts gekoppelt werden. Beispielsweise kann das Testsystem über die HSIO-Schnittstelle des Testsystems 920 dem Testobjekt 930 Daten bereitstellen, wobei die Daten durch das ATE-Testprogramm bestimmt werden können, das auf dem integrierten Testausführer läuft. Beispielsweise kann die Kontrolle über das Senden von Daten an das Testobjekt über die Hochgeschwindigkeits-I/O-Schnittstelle des Testsystems 920 durch das OCST-Steuergerät ausgeübt werden, das die Daten von dem ATE-Testprogramm empfängt, das auf dem integrierten Testausführer läuft.
  • Die Peripherieschnittstelle des DUT 930 kann beispielsweise die durch das Testsystem bereitgestellten Daten in Rückschleife führen, beispielsweise durch eine geeignete Konfiguration der Peripherieschnittstelle (z. B. unter Ausnutzung eines bestimmten testgerechten Designs der Peripherieschnittstelle). Jedoch kann die Rückschleifen-Funktionalität auch durch den Auf-Chip-Testcode bereitgestellt werden, der die empfangenen Daten aus der Peripherieschnittstelle lesen und die gelesenen Daten zurück zu einem Ausgabepuffer der Peripherieschnittstelle kopieren kann.
  • Das Testsystem 920 kann die Daten, die durch die Peripherieschnittstelle des Testobjekts 930 gesendet werden, empfangen und die empfangenen Daten können durch das OSCT-Steuergerät evaluiert und/oder an das ATE-Testprogramm weitergeleitet werden, das auf dem integrierten Testausführer läuft. Dementsprechend kann die Hochgeschwindigkeits-I/O-Schnittstelle des Testobjekts 930 getestet werden, wobei Parameter der Übertragung durch das Hochgeschwindigkeits-I/O-Instrument des Testsystems 920, beispielsweise unter der Kontrolle des OSCT-Steuergeräts, angepasst werden können, so dass Parameter der Hochgeschwindigkeits-I/O-Schnittstelle des Testobjekts 930 bestimmt werden können. Darüber hinaus wird beispielsweise eine besonders hohe Effizienz erzielt, wenn das OSCT-Steuergerät die Übertragung von Daten an die Peripherieschnittstelle des Testobjekts und auch das Empfangen von Daten von der Peripherieschnittstelle sowie ferner die Konfiguration des Testobjekts steuert. Dementsprechend kann der Hochgeschwindigkeits-I/O-Test auf höchst effiziente Weise durchgeführt werden.
  • 10 zeigt eine schematische Darstellung eines vierten Szenarios, bei dem ein HSIO-Protokoll-Engine-Test durchgeführt wird. In dem vierten Szenario werden eine Workstation 1010 und ein Testsystem 1020 verwendet, um ein Testobjekt 1030 zu testen, wobei die Workstation 1010 den Workstations 610, 710, 810, 910 entsprechen kann, wobei das Testsystem 1020 den Testsystemen 620, 720, 820, 920 entsprechen kann und wobei das Testobjekt 1030 den Testobjekten 630, 730, 830, 930 entsprechen kann.
  • In dem vierten Szenario kann eine Peripherieschnittstelle des Testobjekts 1030 dazu konfiguriert sein, sich in einem Rückschleifen-Modus zu befinden, was beispielsweise unter Verwendung einer Design-for-Test-Schaltungsanordnung erzielt werden kann. Dementsprechend kann die automatisierte Testeinrichtung einen Auf-Chip-Testcode auf das Testobjekt 1030 hochladen, der die Peripherieschnittstelle dazu konfiguriert, sich im Rückschleifen-Modus zu befinden und der Daten an die Peripherieschnittstelle sendet und der Daten empfängt und evaluiert, die seitens der Peripherieschnittstelle in Rückschleife geführt werden. Beispielsweise kann der Auf-Chip-Testcode, der auf dem Testobjekt ausgeführt wird, sogar evaluieren, ob die Daten, die von der Peripherieschnittstelle n Rückschleife geführt werden, mit den erwarteten Daten übereinstimmen. Dementsprechend kann die Protokoll-Engine der Hochgeschwindigkeits-I/O-Schnittstelle getestet werden. Insbesondere kann der Auf-Chip-Testcode auch Protokollinformationen evaluieren, die durch die Peripherieschnittstelle bereitgestellt werden.
  • Abschließend lässt sich sagen, dass in dem vierten Szenario das Auf-Chip-System-Teststeuergerät beispielsweise lediglich für das Hochladen eines geeigneten Auf-Chip-Testcodes auf das Testobjekt 1030 und für das Empfangen von Ergebnisinformationen von dem Testobjekt und für das Weiterleiten der Ergebnisinformationen an die Workstation (beispielsweise an den integrierten Testausführer) verantwortlich sein kann. Dementsprechend kann ein Hochgeschwindigkeits-I/O-Protokoll-Engine-Test mit hoher Effizienz durchgeführt werden.
  • 11 zeigt eine schematische Darstellung eines fünften Szenarios, in dem ein Verbindungsbelastungstest durchgeführt wird. In dem fünften Szenario werden eine Workstation 1110 und ein Testsystem 1120 verwendet, um ein Testobjekt 1130 zu testen. Beispielsweise ist die automatisierte Testeinrichtung, die die Workstation 1110 und das Testsystem 1120 aufweist, dazu konfiguriert, einen Auf-Chip-Testcode auf das Testobjekt hochzuladen, das dazu konfiguriert ist, einen Datentransfer zwischen unterschiedlichen Blöcken des Testobjekts durchzuführen, um auf diese Weise die asynchrone Anwendungsverbindung zu „belasten“. Auf diese Weise kann ein Datentransfer zwischen dem CPU-Kern und dem SRAM, zwischen einem Peripherieblock des Testobjekts und dem SRAM und zwischen einem Coprozessor des Testobjekts und dem SRAM erfolgen. Beispielsweise kann der Auf-Chip-Testcode dazu konfiguriert sein, einen derartigen „belastenden“ Datenverkehr über die asynchrone Anwendungsverbindung zu initiieren und kann außerdem eine Integrität des Datentransfers überwachen. Dementsprechend kann das OCST-Steuergerät des Testsystems 1120 von dem Testobjekt 1130 Ergebnisinformationen erhalten, beispielsweise über die Debug-Schnittstelle, und kann beispielsweise die Ergebnisinformationen an das Testprogramm der automatisierten Testeinrichtung weiterleiten, das auf dem integrierten Testausführer läuft. Dementsprechend kann die Verbindung des Testobjekts 1130 effizient getestet werden, wobei die Last des Testsystems vergleichsweise klein ist.
  • Betriebsmodi des Testobjekts (SoC)
  • Im Folgenden werden unterschiedliche Modi zum Betreiben des Testobjekts beschrieben. Außerdem werden einige Details bezüglich eines Bootvorgangs und optionale Details bezüglich der automatisierten Testeinrichtung erörtert.
  • OCST mit einer Betriebssystemumgebung
  • Im Folgenden wird beschrieben, wie ein Auf-Chip-System-Test mit einer Betriebssystemumgebung durchgeführt werden kann. 12 zeigt eine schematische Darstellung eines derartigen Auf-Chip-System-Tests mit einer Betriebssystemumgebung.
  • Wie in 12 ersichtlich ist, kann die automatisierte Testeinrichtung beispielsweise eine Workstation 1210 und eine Automatisierte-Testeinrichtung-Hardware 1220 aufweisen. Die Workstation 1210 kann beispielsweise den oben beschriebenen Workstations 610, 710, 810, 910, 1010, 1110 entsprechen, und die Automatisierte-Testeinrichtung-Hardware kann beispielsweise den Testsystemen 620, 720, 820, 920, 1020, 1120 entsprechen. Jedoch kann die automatisierte Testeinrichtung 1002 beispielsweise einige oder alle der hier offenbarten Funktionalitäten der automatisierten Testeinrichtung aufweisen. Alternativ kann jedoch jede der hier bezüglich der automatisierten Testeinrichtung beschriebenen Funktionalitäten optional in jede der anderen hier offenbarten automatisierten Testeinrichtungen übernommen werden, sowohl individuell als auch in Kombination.
  • Es ist festzustellen, dass die Workstation 1210 typischerweise eine Anzahl von Softwaremodulen ausführt. Beispielsweise kann die Workstation dazu konfiguriert sein, eine integrierte Entwicklungsumgebung 1212 auszuführen, die beispielsweise der zuvor beschriebenen Entwicklungs- und Debug-Umgebung 240 entsprechen kann. Die integrierte Entwicklungsumgebung kann einen Eingebettete-Software-Debugger 1214a und einen ATE-Debugger 1214b aufweisen oder mit demselben kooperieren. Beispielsweise kann der Eingebettete-Software-Debugger dahingehend angepasst sein, eine „eingebettete Software“, d. h. Software, die auf dem Testobjekt ausgeführt werden soll (hier auch kurz als „Chip-System-Test“ bezeichnet), zu debuggen. Der ATE-Debugger 1214b kann beispielsweise dazu konfiguriert sein, eine Automatisierte-Testeinrichtung-Software zu debuggen, beispielweise einen ATE-Ablauf 1216, der beispielsweise durch den Benutzer bereitgestellt sein kann. Die integrierte Entwicklungsumgebung 1212 kann beispielsweise dazu konfiguriert sein, mit dem Eingebettete-Software-Debugger 1214a sowie mit dem Automatisierte-Testeinrichtung-Debugger 1214b zu kommunizieren und um den ATE- Ablauf 1216 zu bearbeiten. Darüber hinaus kann der ATE-Debugger 1214b dazu konfiguriert sein, den ATE-Ablauf 1216 zu evaluieren. Der Eingebettete-Software-Debugger 1214a kann beispielsweise über die Workstation 1210 und die ATE-Hardware 1220 mit dem Testobjekt kommunizieren. Darüber hinaus gibt es außerdem eine Automatisierte-Testeinrichtung-Testsuite 1218, die auf der Workstation läuft, sowie eine Automatisierte-Testeinrichtung-Laufzeitumgebung 1219. Beispielsweise ist die Automatisierte-Testeinrichtung-Laufzeitumgebung 1219 eine Softwareschicht, die sich zwischen der Workstation (oder dem Betriebssystem der Workstation) und der ATE-Testsuite 1218a befindet. Darüber hinaus ist festzustellen, dass die ATE-Testsuite 1218 typischerweise den ATE-Ablauf 1217 ausführt und mit dem ATE-Debugger 1214b kooperiert.
  • Abschließend lässt sich sagen, dass die integrierte Entwicklungsumgebung 1212 beispielsweise Zugriff (z. B. für einen Benutzer) auf den Eingebettete-Software-Debugger 1214, auf den ATE-Debugger 1214b bieten kann und ferner es ermöglicht, die Ausführung des ATE-Ablaufs zu steuern.
  • Darüber hinaus kann die Testobjekthardware 1230 außerdem eine Vielzahl von Softwaremodulen ausführen. Beispielsweise gibt es einen Betriebssystemkernel 1232, der einen oder mehrere Gerätetreiber 1234a, 1234b verwendet, um auf Hardware (zum Beispiel eine oder mehrere Schnittstellen) des Testobjekts zuzugreifen. Darüber hinaus kann der Betriebssystemkernel auf einen „Gerätebaum“ (device tree) 1236 zugreifen, der beispielsweise die Schnittstellen der DUT-Hardware und möglicherweise auch zusätzliche Speicher definieren kann, die mit der DUT-Hardware gekoppelt sind. Darüber hinaus gibt es typischerweise einen „OCST-Runner“ 1238, der beispielsweise die Ausführung eines Auf-Chip-Testcodes 1240 steuert. Der Auf-Chip-Testcode 1240 kann beispielsweise eine Auf-Chip-System-Testlaufzeitumgebung 1242 verwenden, die beispielsweise einige Funktionen bereitstellen kann. Die OCST-Laufzeitumgebung 1242 ist dazu konfiguriert, mit dem Betriebssystemkernel 1232 (z. B. durch Aufrufen von Funktionen des OS-Kernels 1232) zu kooperieren. Darüber hinaus ist festzustellen, dass der OCST-Runner 1238 auch in direkter Kommunikation mit der DUT-Hardware sein kann, beispielsweise um eine direkte Kommunikation zwischen der ATE-Hardware und dem OCST-Runner 1238 zu ermöglichen. Darüber hinaus ist festzustellen, dass der Auf-Chip-Testcode 1240 beispielsweise direkt auf Funktionen des OS-Kernels 1232 zugreifen kann und außerdem auf Funktionen der OCST-Laufzeitumgebung 1242 zugreifen kann, die wiederum auf Funktionen des OS-Kernels 1232 zugreift. Darüber hinaus kann der OS-Kernel 1232, zusätzlich zu einem Zugreifen auf DUT-Hardware über den einen oder die mehreren Gerätetreiber 1232a, 1232b beispielsweise in direkter Kommunikation mit der DUT-Hardware sein.
  • Es ist festzustellen, dass jedes der Softwaremodule, die auf der Testobjekthardware 1230 ausgeführt werden, beispielsweise durch eine Entwicklungs- und Debug-Umgebung der automatisierten Testeinrichtung wie hierin beschrieben bereitgestellt werden kann. Somit kann die Entwicklungs- und Debug-Umgebung ein oder mehrere Programme aufweisen, die die Softwaremodule 1232, 1232a, 1232b, 1238, 1244 definieren, wobei der Auf-Chip-Testcode 1240 typischerweise auf einer Benutzereingabe an die Entwicklungs- und Debug-Umgebung basiert.
  • Boot-Sequenz eines eingebetteten Betriebssystems
  • Nachfolgend wird ein Beispiel für eine Boot-Sequenz eines eingebetteten Betriebssystems unter Bezugnahme auf 13 beschrieben, die eine schematische Darstellung einer derartigen Boot-Sequenz eines eingebetteten Betriebssystems zeigt. 13 zeigt ein Testobjekt, z. B. ein SoC 1310, das den zuvor beschriebenen Testobjekten ähnlich sein kann. Wie ersichtlich ist, weist das Ein-Chip-System 1310 einen CPU-Kern 1320, einen SRAM 1322, einen L2-Cash 1324, einen NVRAM 1326 und einen ROM 1328 auf, die alle mit einer synchronen Anwendungsverbindung gekoppelt sind. Darüber hinaus kann das Ein-Chip-System 1310 eine Peripherieschnittstelle 1330 und einen Speichersteuerungen 1332 aufweisen, wobei die Peripherieschnittstelle beispielsweise dahingehend angepasst sein kann, auf unterschiedliche Typen von Flash-Speicher zuzugreifen und/oder über direkten Speicherzugriff (z. B. PCle DMA) auf einen Speicher zuzugreifen. Darüber hinaus kann die Speichersteuerung 1332 beispielsweise dazu konfiguriert sein, auf einen dynamischen Direktzugriffsspeicher DRAM zuzugreifen.
  • In der Boot-Sequenz kann ein primärer Bootloader, der beispielsweise in dem ROM 1328 gespeichert ist, ein Laden eines sekundären Bootloaders in den SRAM 1322 über die Peripherieschnittstelle 1330 bewirken. Darüber hinaus kann der sekundäre Bootloader anschließend ein Kopieren eines Betriebssystemprogramms von einem Flash-Speicher oder von einem anderen „externen“ Speicher in den DRAM bewirken, wobei auf den Flash-Speicher oder den externen Speicher über die Peripherieschnittstelle 1330 zugegriffen wird und wobei auf den DRAM über die Speichersteuerung 1332 zugegriffen wird. Dementsprechend wird das Betriebssystem in den DRAM kopiert, auf den typischerweise ein viel schnellerer Zugriff möglich ist als auf den externen Speicher (Flash-Speicher oder Speicher, der über direkten Speicherzugriff DMA zugänglich ist). Nachfolgend kann das Betriebssystemprogramm durch den CPU-Kern 1320 ausgeführt werden, wobei der L2-Cash 1324 Abschnitte des Betriebssystemprogramms gemäß einer Cache-Strategie zwischenspeichern kann. Es ist jedoch festzustellen, dass die Ausführung von herkömmlichen Betriebssystemen typischerweise das Vorhandensein eines DRAM erfordert, was bei manchen Testumgebungen nicht garantiert werden kann. Insbesondere ist das Bereitstellen eines DRAM bei einigen Testumgebungen schwierig.
  • Nachfolgend ist eine kurze Diskussion eines OS-Kandidaten, nämlich Linux auf SoC, vorgesehen.
  • Dieser OS-Kandidat wird auf einer großen Vielzahl von eingebetteten CPU-Kernen unterstützt und ist außerdem gut dokumentiert.
  • Der OS-Kandidat nutzt einen Gerätebaum, um übliche Variationen von eingebetteten CPUs zu beschreiben. Dies erleichtert die Anpassung an eine neue CPU-Variante.
  • Der oben erwähnte OS-Kandidat führt die grundlegende Systemkonfiguration (d. h. Initialisieren der Speichersteuerung) nicht durch. Vielmehr verlässt sich der OS-Kandidat auf den Bootloader, um dies zu übernehmen.
  • Für den oben erwähnten OS-Kandidaten ist eine einsatzbereite Unterstützung für mehrere CPU-Kerne und für eine Speichervirtualisierung vorhanden.
  • Darüber hinaus ist für den oben erwähnten OS-Kandidaten eine Trennung von Kernel- und Benutzerraum vorhanden.
  • Von dem Benutzerraum aus wird über eine gemeinsame abstrakte API auf die gesamte Hardware zugegriffen.
  • Darüber hinaus weist der oben erwähnte OS-Kandidat einen modularen Hardwaretreiber auf. Viele Treiber sind mit der Kernelcodeverteilung leicht verfügbar. Außerdem können kundenspezifische Treiber leicht integriert werden.
  • Darüber hinaus ist für den oben erwähnten OS-Kandidaten ein Software-Debug ohne Hardware-Debug-Unterstützung (GDB) möglich.
  • Für den oben erwähnten OS-Kandidaten erfordert ein Debugging über JTAG/SWD einen Debugger, der die Adressübersetzungs- und Verarbeitungstabellen des Kernels kennt (z. B. von Lauterbach).
  • Hinsichtlich des oben erwähnten Betriebssystemkandidaten ist außerdem festzustellen, dass mit der (Open Source) Build-Root-Umgebung leicht ein „abgespecktes“ Linux-System gebaut werden kann, das lediglich aus dem Kernel, den erforderlichen Hardwaretreibern und einem einzelnen Benutzerraumprogramm besteht. Es hat sich gezeigt, dass ein derartiges System in wenigen Sekunden booten kann.
  • Abschließend lässt sich sagen, dass festgestellt wurde, dass Linux auf SoC als Betriebssystem verwendet werden könnte, beispielsweise zur Ausführung des Testobjekts.
  • OCST mit einer Bare-Metal-Umgebung
  • Im Folgenden wird ein Auf-Chip-System-Test mit einer Bare-Metal-Umgebung („blankes Metall“, d. h. direkt auf der Hardware ausgeführt) (unter Bezugnahme auf 14 beschrieben, die eine schematische Darstellung eines derartigen Auf-Chip-System-Tests mit einer Bare-Metal-Umgebung zeigt.
  • Hinsichtlich dieses Themas ist festzustellen, dass die automatisierte Testeinrichtung 1402, die eine Workstation 1410 und eine Automatisierte-Testeinrichtung-Hardware 1420 aufweist, generell mit der automatisierten Testeinrichtung 1202 identisch sein kann. Außerdem kann die integrierte Entwicklungsumgebung 1412 der integrierten Entwicklungsumgebung 1212 entsprechen, der Eingebettete-Software-Debugger 1414a kann dem Eingebettete-Software-Debugger 1214a entsprechen, der ATE-Debugger 1414b kann dem ATE-Debugger 1214b entsprechen, die ATE-Testsuite 1418 kann der ATE-Testsuite 1218 entsprechen, und die ATE-Laufzeitumgebung 1419 kann der ATE-Laufzeitumgebung 1219 entsprechen. Es ist jedoch festzustellen, dass die Softwaremodule 1412, 1414a, 1414b, 1418, 1419 dahingehend angepasst werden können, zu reflektieren, dass kein Betriebssystem vorhanden ist, das auf dem Testobjekt läuft.
  • Bezüglich der Testobjekthardware 1430 ist festzustellen, dass in diesem Szenario keine Betriebssystemkernelsoftware auf der Testobjekthardware ausgeführt wird. Vielmehr gibt es eine OCST-Laufzeitumgebung 1442, die direkt auf die DUT-Hardware 1430 zugreifen kann. Die OCST-Laufzeitumgebung 1442 kann beispielsweise durch einen Gerätebaum 1444 unterstützt werden, der beispielsweise die Schnittstellen der DUT-Hardware 1430 definieren kann. Darüber hinaus ist ein Auf-Chip-Testcode 1440 vorhanden, der auf Funktionen der OCST-Laufzeitumgebung 1442 zugreifen kann und der außerdem direkt auf die DUT-Hardware 1430 zugreifen kann. Darüber hinaus gibt es einen OCST-Runner 1438, der beispielsweise mit dem Auf-Chip-Testcode 1440 kommunizieren (oder denselben steuern) kann. Der OCST-Runner 1438 kann außerdem in direkter Kommunikation mit der DUT-Hardware 1430 sein und kann beispielsweise Steuerbefehle direkt von der DUT-Hardware 1430 empfangen (wobei die Steuerbefehle beispielsweise durch das Auf-Chip-System-Teststeuergerät der automatisierten Testeinrichtung bereitgestellt werden). Somit kann der Auf-Chip-System-Test-Runner 1438 die Ausführung des Auf-Chip-Testcodes 1440 steuern, und der Auf-Chip-Testcode 1440 kann die Auf-Chip-System-Testlaufzeitumgebung 1442 verwenden, wenn ein Test der DUT-Hardware 1430 durchgeführt wird.
  • Abschließend lässt sich sagen, dass ein Auf-Chip-System-Test auch durchgeführt werden kann, ohne ein Betriebssystem auf dem Testobjekt auszuführen, vorausgesetzt, dass die Auf-Chip-System-Testlaufzeitumgebung einen Zugriff auf die DUT-Hardware unterstützt.
  • Eingebetteter Bare-Metal-Boot über Debug-Port
  • Im Folgenden wird ein Konzept zum Booten eines Testobjekts (SoC) beschrieben, das kein Betriebssystem (Bare Metal) ausführt. 15 zeigt ein Blockschema eines derartigen eingebetteten Bare-Metal-Boots über einen Debug-Port.
  • Es ist festzustellen, dass das Testobjekt 1510 beispielsweise jedem anderen der hier beschriebenen Testobjekte ähnlich sein kann.
  • Jedoch weist das Testobjekt 1510 einen primären Bootloader auf, der typischerweise in dem ROM gespeichert ist.
  • Wenn jedoch ein Bare-Metal-Boot über den Debug-Port verwendet wird, wird der primäre Bootloader typischerweise nicht verwendet. Vielmehr wird die Vorrichtung unter Verwendung der Debug-Schnittstelle konfiguriert, beispielsweise unter der Kontrolle des Auf-Chip-Testsystemsteuergeräts. Zum Beispiel kann das Auf-Chip-System-Teststeuergerät über die Debug-Schnittstelle (z. B. eine JTAG-Schnittstelle oder eine SWD-Schnittstelle) auf den CPU-Kern zugreifen und kann den CPU-Kern dazu konfigurieren, das Bare-Metal-Programm in den SRAM zu kopieren. Beispielsweise kann das Auf-Chip-System-Teststeuergerät geeignete Debug-Befehle oder Abtastinformationen bereitstellen, um zu bewirken, dass der CPU-Kern das gewünschte Bare-Metal-Programm in den SRAM kopiert. Alternativ kann das Auf-Chip-System-Teststeuergerät jedoch außerdem über die Debug-Schnittstelle direkt auf den SRAM zugreifen, falls dies im Hinblick auf das Design des Testobjekts möglich ist. Wenn dieses Hochladen des Bare-Metal-Programms erfolgt, kann das Auf-Chip-System-Teststeuergerät beispielsweise die Ausführung des primären Bootloaders stoppen. Darüber hinaus kann das Auf-Chip-System-Teststeuergerät den CPU-Kern außerdem dahingehend anweisen, das Bare-Metal-Programm auszuführen, das in den SRAM gespeichert wurde, beispielsweise indem ein Programmzähler des CPU-Kerns über den Debug-Port auf eine geeignete Speicheradresse des SRAM gesetzt wird. Ein derartiges Konzept kann vorteilhaft sein, da das möglicherweise nicht deterministische Verhalten des Betriebssystems, das unter Umständen nicht gut dokumentiert ist, vermieden wird. Vielmehr wird ein Bare-Metal-Programm bereitgestellt, das von dem Softwareengineer genauer verstanden werden kann und das deshalb in manchen Fällen besser reproduzierbare Testergebnisse bieten kann.
  • Außerdem kann der Einsatz eines Bare-Metal-Programms den Vorteil haben, dass das Programm viel „schlanker“ ist, so dass die Verwendung eines externen DRAM unter Umständen nicht erforderlich ist.
  • Bare-Metal-Kandidat eines U-BOOT-Bootloaders
  • Es hat sich herausgestellt, dass der sogenannte Bootloader vom Typ „U-Boot“ ein guter Kandidat auf einem Systemchip sein kann.
  • Es hat sich herausgestellt, dass dieser Bare-Metal-Kandidat ein am häufigsten verwendeter Bootloader auf einem SoC ist.
  • Darüber hinaus hat sich herausgestellt, dass der Bare-Metal-Kandidat einen Gerätebaum einsetzt, um übliche Variationen von eingebetteten CPUs zu beschreiben. Dies erleichtert das Anpassen an neue CPU-Varianten.
  • Darüber hinaus führt der oben erwähnte Bare-Metal-Kandidat die grundlegende Hardwareinitialisierung durch.
  • Ferner hat sich herausgestellt, dass der oben erwähnte Bare-Metal-Kandidat keine Speichervirtualisierung verwendet und einen minimalen Speicherbedarf hat.
  • Des Weiteren wurde festgestellt, dass der oben erwähnte Bare-Metal-Kandidat im einsatzbereiten Zustand lediglich auf einer einzigen CPU läuft - selbst auf einem Multi-Kern-System. Jedoch unterstützt der oben erwähnte Bare-Metal-Kandidat einen Basissatz von lokalen und Netzwerkschnittstellen für ein OS-Laden.
  • Der oben erwähnte Bare-Metal-Kandidat bietet eine Befehlszeilenschnittstelle, die über die Serienschnittstelle zugänglich ist.
  • Es hat sich herausgestellt, dass der oben erwähnte Bare-Metal-Kandidat im Millisekundenbereich bootet.
  • Darüber hinaus ist der oben erwähnte Bare-Metal-Kandidat vom Open-Source-Typ und erweiterbar. Dementsprechend kann der Bootloader als Basis für eine eingebettete Testlaufzeitumgebung verwendet werden, indem fehlende Merkmale (z. B. Multi-CPU-Unterstützung) hinzugefügt werden.
  • Eingebettetes Testrahmenwerk: OS kontra Bare-Metal
  • Nachfolgend werden einige Vorteile der Verwendung eines Betriebssystems und einige Vorteile der Verwendung von Bare-Metal (z. B. ohne ein Betriebssystem) beschrieben.
  • OS-Vorteile:
    1. 1. Bestehender Gerätetreiber kann so wie er ist verwendet werden. Für die meisten gängigen Peripherieschnittstellen sind bereits Gerätetreiber verfügbar.
    2. 2. Einsatzbereite Unterstützung für Multitasking auf mehreren CPUs
    3. 3. Speichervirtualisierung verbirgt das physische Speicherlayout. Dies vereinfacht das Programmieren und die Fehlersuche.
  • Bare-Metal-Vorteile:
    1. 1. Bootzeit von Sekunden auf Mikrosekunden reduziert
    2. 2. Erheblich reduzierter Speicherbedarf
    3. 3. Vollständige Hardwarekontrolle aufgrund eines Zugriffs auf niedriger Ebene. Dies verbessert Testabdeckung und Wiederholbarkeit.
    4. 4. Leichter an unvollständige Hardwareressourcen wie fehlender DRAM anpassbar
  • Zusammenfassend lässt sich sagen, dass ein Bare-Metal-Ansatz für einen eingebetteten Test bei einem Wafer-Sort-Test am besten geeignet ist. Darüber hinaus kann zusammenfassend gesagt werden, dass der OS-Ansatz ein vereinfachtes Nutzungsmodell anbietet. Es hat sich herausgestellt, dass erweiterte Bootzeit und größerer Speicherbedarf verfügbar sein können - insbesondere für eine Post-Silizium-Validierung.
  • Physisches OCST-Steuergerät
  • Im Folgenden wird ein Ausführungsbeispiel eines physischen Auf-Chip-System-Teststeuergeräts beschrieben. Es ist jedoch festzustellen, dass das hierin beschriebene physische Auf-Chip-System-Teststeuergerät optional durch beliebige der hierin bezüglich eines Auf-Chip-System-Teststeuergeräts beschriebenen Merkmale, Funktionalitäten und Details ergänzt werden kann, sowohl individuell als auch in Kombination. Darüber hinaus ist festzustellen, dass beliebige der bezüglich des Auf-Chip-System-Teststeuergeräts von 16 beschriebenen Merkmale, Funktionalitäten und Details optional in ein beliebiges anderes Auf-Chip-System-Teststeuergerät übernommen werden können, sowohl individuell als auch in Kombination.
  • 16 zeigt eine schematische Darstellung eines physischen Auf-Chip-System-Teststeuergeräts, der Teil einer automatisierten Testeinrichtung sein kann. Darüber hinaus zeigt 16 außerdem eine schematische Darstellung einer Workstation, die mit dem physischen Auf-Chip-System-Teststeuergerät kooperiert. Anders gesagt weist die automatisierte Testeinrichtung eine Workstation-Hardware 1610 und eine Auf-Chip-System-Teststeuergerät-Hardware 1620 auf.
  • Die Workstation-Hardware 1610 ist dahingehend angepasst, eine Workstation-Software 1612 auszuführen, und die Auf-Chip-System-Teststeuergerät-Hardware 1620 ist dazu konfiguriert, eine Auf-Chip-System-Teststeuergerät-Software 1622 auszuführen. Die Workstation-Software 1612 kann beispielsweise eine integrierte Entwicklungsumgebung 1612a aufweisen, die beispielsweise der Entwicklungs- und Debug-Umgebung 240 entsprechen kann, die oben beschrieben wurde. Alle Merkmale, Funktionalitäten und Details dieser Workstation-Software 1610 können jedoch optional auch in der Entwicklungs- und Debug-Umgebung 240 beinhaltet sein.
  • Insbesondere weist die Workstation-Software einen eingebetteten Debugger 1612b auf, der beispielsweise dem Eingebettete-Software-Debugger 1214a entsprechen kann. Darüber hinaus kann die Workstation-Software auch einen ATE-Debugger 1612c aufweisen, der beispielsweise dem ATE-Debugger 1214b entsprechen kann. Die Workstation-Software 1612 kann ferner einer ATE-Testsuite 1612d entsprechen, die beispielsweise der ATE-Testsuite 1218 entsprechen kann. Die Workstation-Software 1612 kann ferner eine ATE-Laufzeitumgebung 1612e aufweisen, die beispielsweise der ATE-Laufzeitumgebung 1219 entsprechen kann.
  • Darüber hinaus kann die Workstation-Software beispielsweise in einem Kernelraum eine Linuxkernel 1612f aufweisen, auf den beispielsweise durch die ATE-Laufzeitumgebung 1612e über einen Sockel zugegriffen werden kann. Auf ähnliche Weise kann der eingebettete Debugger 1612b, der außerdem eine Hardware-Schnittstellenabstraktion aufweisen kann, mit dem Linuxkernel 1612f über einen Sockel des Linuxkernels kommunizieren.
  • Darüber hinaus kann der Linuxkernel einen sogenannten „Testdatenbustreiber“ 1612g verwenden, der eine Kommunikation mit OCST-Steuergerät-Hardware ermöglichen kann. Es könnte jedoch auch jeder beliebige andere Treiber verwendet werden, der eine Kommunikation mit der OCST-Steuergerät-Hardware ermöglicht.
  • Darüber hinaus weist die OCST-Steuergerät-Software 1622 einen sogenannten OCST-Daemon 1622a auf, der beispielsweise in einem Benutzerraum ausgeführt wird. Darüber hinaus weist die OCST-Steuergerät-Software 1622 außerdem einen Linuxkernel 1622b auf, der zum Beispiel in einem Kernelraum ausgeführt werden kann. Eine Kommunikation zwischen dem OCST-Daemon 1622a und dem Linuxkernel 1622b kann beispielsweise unter Verwendung eines oder mehrerer Sockel des Linuxkernels durchgeführt werden.
  • Darüber hinaus kann die OCST-Steuergerät-Software 1622 eine Mehrzahl von Treibern aufweisen, beispielsweise einen JTAG-Treiber 1622c, einen PCIe-Treiber 1622d, einen „Testdatenbustreiber“ 1622e und einen Synchronisationsbustreiber 1622f. Der Testdatenbustreiber 1622e kann beispielsweise eine Kommunikation mit der Workstation unterstützen. Jedoch wäre auch jeder beliebige andere Treiber, der eine Kommunikation mit der Workstation ermöglicht, geeignet. Der Synchronisationsbustreiber 1622f ermöglicht einen Zugriff auf einen Synchronisationsbus, was eine Synchronisation mit anderen Testressourcen ermöglicht (beispielsweise die oben beschriebenen Testressourcen 220, 230). Darüber hinaus ermöglicht der JTAG-Treiber (oder allgemein jeder Debug-Schnittstellentreiber) eine Kommunikation mit dem Testobjekt über eine Debug-Schnittstelle. In ähnlicher Weise ermöglicht der PCIe-Treiber (oder jeder andere Treiber einer Schnittstelle mit hoher Bandbreite) eine Kommunikation mit dem Testobjekt über eine Schnittstelle mit hoher Bandbreite.
  • Im Folgenden werden Hardwaremerkmale des physischen OCST-Steuergeräts ebenfalls beschrieben. Beispielsweise kann das physische OCST-Steuergerät ein feldprogrammierbares Gatterarray 1640 aufweisen, das zum Beispiel dazu konfiguriert sein kann, eine oder mehrere Zentralverarbeitungseinheiten CPU zu implementieren. Darüber hinaus kann das feldprogrammierbare Gatterarray 1640 dazu konfiguriert sein, mit einem beliebigen internen oder externen Direktzugriffsspeicher, beispielsweise einem DRAM 1642, zu kommunizieren. Das feldprogrammierbare Gatterarray 1640 kann beispielsweise mit einem Synchronisationsbus 1644 gekoppelt sein, der zum Beispiel auch mit anderen ATE-Instrumenten gekoppelt sein kann. Der Synchronisationsbus kann beispielsweise eine Synchronisation zwischen dem physischen Auf-Chip-System-Teststeuergerät und anderen Testressourcen ermöglichen, beispielsweise parametrischen Testressourcen und/oder digitalen Testressourcen (zum Beispiel wie oben beschrieben). Darüber hinaus ist das feldprogrammierbare Gatterarray 1640 außerdem mit einem Datenbus (oder allgemein gesagt mit einer Datenschnittstelle) 1646 gekoppelt, was eine Kommunikation mit der Workstation 1610 ermöglicht. In dem bereitgestellten Beispiel wird ein sogenannter „Testdatenbus“ verwendet, jedoch können auch andere Schnittstellen zu der Workstation verwendet werden.
  • Das Auf-Chip-System-Teststeuergerät weist ferner eine Mehrzahl von Pegelumsetzern 1650 auf und weist außerdem optional eine physische PCle-Schnittstelle 1652 und eine physische USB-Schnittstelle 1654 (z. B. eine physische USB3-Schnittstelle) auf. Die Pegelumsetzer 1650 sind beispielsweise mit allgemein verwendbaren Eingangs/Ausgangs-Pins des feldprogrammierbaren Gatterarrays 1640 gekoppelt. Auf der anderen Seite können die optionale physische PCIe-Schnittstelle und die optionale physische USB-Schnittstelle mit Hochgeschwindigkeitspins (z. B. LVDS-Pins) des feldprogrammierbaren Gatterarrays 1640 gekoppelt sein.
  • Geräteseitige Pins des Pegelumsetzers 1650, der physischen PCIe-Schnittstelle 1652 und der physischen USB-Schnittstelle 1654 können beispielsweise mit einer DUT-Schnittstelle über eine Mehrzahl von Eingang/Ausgang-Multiplexern 1660a, 1660b (optional), 1660c (optional) gekoppelt werden.
  • Unter Verwendung der Eingang/Ausgang-Multiplexer 1660a, 1660b, 1660c können der Pegelumsetzer 1650, die physische PCIe-Schnittstelle und die physische USB-Schnittstelle 1654 mit geeigneten Pins des Testobjekts gekoppelt werden. Die Signale, die durch den Pegelumsetzer 1650 bereitgestellt werden, können zum Beispiel vorzugsweise mit einer Debug-Schnittstelle oder Steuerschnittstelle des Testobjekts gekoppelt werden, beispielsweise mit einer JTAG-Schnittstelle, einer SWD-Schnittstelle, einer UART-Schnittstelle, einer TWI-Schnittstelle oder dergleichen. Jedoch sind die Signale, die durch die physische PCIe-Schnittstelle bereitgestellt werden, typischerweise mit einer PCle-Schnittstelle des Testobjekts über den jeweiligen Eingang/Ausgang-Multiplexer 1660b gekoppelt, und die Signale, die durch die physische USB-Schnittstelle 1654 bereitgestellt werden, sind typischerweise mit einer USB-Schnittstelle (z. B. einer USB3-Schnittstelle) des Testobjekts über den jeweiligen Eingang/Ausgang-Multiplexer 1660c gekoppelt. Darüber hinaus können die Eingang/Ausgang-Multiplexer 1660a, 1660b, 1660c dazu konfiguriert sein, eine parametrische Messeinheit 1670 mit einem oder mehreren Pins des Testobjekts auf eine einstellbare (variable) Weise zu koppeln. Dementsprechend können analoge Charakteristika der jeweiligen Pins des Testobjekts durch die physische Messeinheit 1670 charakterisiert werden.
  • Abschließend lässt sich sagen, dass eine beispielhafte Implementierung eines physischen OCST-Steuergeräts unter Bezugnahme auf 16 beschrieben wurde. Die in 16 beschriebene Auf-Chip-System-Teststeuergerät-Hardware kann beispielsweise optional dazu verwendet werden, einen beliebigen der hierin beschriebenen Auf-Chip-System-Teststeuergeräte zu implementieren. Optional können jedoch eine oder mehrere Komponenten des Auf-Chip-System-Teststeuergeräts gemäß 16 in einem beliebigen der hierin offenbarten Auf-Chip-System-Teststeuergeräte verwendet werden.
  • Darüber hinaus ist festzustellen, dass die hier beschriebene automatisierte Testeinrichtung optional durch beliebige der hier offenbarten Merkmale, Funktionalitäten und Details ergänzt werden kann, sowohl individuell als auch in Kombination.
  • Diskussion angesichts alternativer Lösungen
  • Nachfolgend werden einige alternative Lösungen erörtert, und Vorteile bei der Verwendung eines Auf-Chip-System-Teststeuergeräts werden aufgezeigt.
  • Die erste alternative Lösung besteht darin, einen Systemebenentest durchzuführen. Bei diesem Ansatz wird ein bestehendes Evaluations-Board genommen oder eine spezielle Version daraus abgeleitet. Zur Bereitstellung der externen Umgebung wird Bench-Equipment verwendet. Für die Testautomatisierung wird spezialisiertes Systemebenentest-Equipment verwendet. Vorhandene Verifizierungstests für die Anwendung werden ausgeführt, und eine Überprüfung auf korrekte Ausführung wird durchgeführt.
  • Dieser Ansatz hat eine Reihe von Vorteilen. Beispielsweise wird eine native Umgebung für Designer und Validierungs-Engineers verwendet. Bestehende Anwendungen/Validierungssoftware wird ausgenutzt. Der Ansatz ist für das Modultesten gut etabliert, und es sind originäre Lösungen sind verfügbar. Der Ansatz funktioniert auch mit einer kostengünstigen Ausrüstung.
  • Jedoch hat dieser Ansatz auch eine Reihe von Nachteilen, die nachfolgend aufgeführt werden. Beispielsweise besteht eine schlechte Wiederholbarkeit und Beobachtbarkeit aufgrund der Verwendung des Anwendungs-Boards. Darüber hinaus bestehen lange Testzeiten und eine fragwürdige Abdeckung, wenn die Anwendungssoftware verwendet wird. Maximale Belastungsbedingungen können nicht angewendet werden oder können lediglich angewendet werden, wenn Takte und Versorgungsspannung auf dem Anwendungs-Board gesteuert werden können. Dies ist in der Regel nicht der Fall. Darüber hinaus kann der Ansatz nicht bei dem Wafer-Sort-Test eingesetzt werden. Typischerweise gibt es technische Schwierigkeiten, das Anwendungs-Board mit dem Wafer-Prober zu integrieren. Darüber hinaus bestehen kommerzielle Probleme mit langen Testzeiten auf einer teuren Sondenausrüstung. Darüber hinaus erfordert der Ansatz typischerweise einen zusätzlichen Testschritt im späteren Verlauf des Herstellungsprozesses.
  • Darüber hinaus kann ein sogenannter „Ende-zu-Ende-Test“ als weiterer Ansatz betrachtet werden. Dieser Ansatz verwendet eine ATE mit spezialisierten „protokollfähigen“ Instrumenten. Die internen Signalwege des DUT werden mit Ende-zu-Ende-Kommunikation getestet.
  • Ein derartiger Ansatz hat eine Reihe von Vorteilen. Beispielsweise unterstützt der Ansatz das klassische ATE-Denken, die Geräteschnittstelle zu beobachten. Darüber hinaus deckt der Ansatz interne Verbindungsstrukturen, Protokoll-Engines und analoge Schnittstellenschaltungen in einem Vorgang ab. Der Ansatz ermöglicht es, Takt- und Versorgungsspannungsbelastung anzulegen. Darüber hinaus eliminiert der Ansatz eine erhebliche Menge bereits während des Wafer-Sort-Tests. Der Ansatz ermöglicht eine Post-Silizium-Validierung während des Wafer-Sort-Tests und ermöglicht ein frühes Feedback an das Design.
  • Jedoch weist der Ende-zu-Ende-Testansatz auch eine Reihe von Nachteilen auf. Insbesondere ist der Ansatz ungenügend, um die interne Verbindung bei maximalem Datenverkehr zu belasten, da die interne Verbindung in der Regel schneller als die Schnittstellen ist. Darüber hinaus kann ein Hochgeschwindigkeitsdatenverkehr nicht mit allgemeinen ATE-Instrumenten abgedeckt werden, da eine Echtzeit-Protokollverarbeitung in der Regel dedizierte ASIC-Designs erfordert. Darüber hinaus decken Validierungstestfälle höchstwahrscheinlich keine Ende-zu-Ende-Kommunikation ab, da sie aus der Perspektive eines White-Box-Tests nicht effektiv sind. Testfälle müssen von Anfang an durch Test-Engineers erzeugt werden.
  • Im Folgenden wird ein Ansatz mit „statistischer Korrelation“ beschrieben. Bei diesem Ansatz werden im Produktionsanlauf nahezu alle verfügbaren Abtastvektoren unter verschiedenen Takt- und Spannungsbelastungsbedingungen bei dem Wafer-Sort-Test durchlaufen. Es werden jedoch nur Testobjekte, die unter Nennbedingungen ausfallen, ausgesondert. Darüber hinaus werden SLT-Tests durchgeführt, um Ausreißer bei dem Wafer-Sort-Test zu identifizieren. Darüber hinaus werden die insgesamt ausgefallenen DUTs mit ausgefallenen Abtastvektoren unter Belastungsbedingungen korreliert. Diese fehlgeschlagenen Tests werden in dem endgültigen Herstellungssortierungsprogramm hinzugefügt, um SLT zu eliminieren.
  • Dieser Ansatz hat den Vorteil, dass der Triage-Prozess vollständig automatisiert werden kann und keine menschliche Interaktion erforderlich ist.
  • Jedoch weist dieser Ansatz einige Nachteile auf, die im Folgenden beschrieben werden. AC-Abtastmethodiken sind dazu ausgelegt, Haft- und Verzögerungsfehler abzudecken. Es ist unklar, ob die Test-Ausreißer wirklich diesen Kategorien zuzuordnen sind - auch unter Spannungs- und Taktbelastungsbedingungen. Darüber hinaus stellt der Ansatz nicht sicher, dass die Drittanbieter-Peripherie-IP innerhalb der Spezifikationen arbeitet. Außerdem könnte es sein, dass Benutzer den Abtastvektoren nicht vertrauen, die mit dieser IP bereitgestellt werden. Darüber hinaus erfordert der Ansatz zusätzliche Abtastvektoren und das Umschalten von Testbedingungen in dem endgültigen Testprogramm. Dies führt zu einer erhöhten Testzeit bei dem Wafer-Sort-Test.
  • Im Folgenden wird der Ansatz des Auf-Chip-System-Tests (OCST) beschrieben. Der Ansatz nutzt die eingebettete CPU des DUT, um Teile des Testprogramms auszuführen. Außerdem ist eine Laufzeitumgebung für diese Fragmente als Teil des ATE-Produkts bereitgestellt.
  • Der Ansatz weist eine Anzahl von Vorteilen auf. Beispielsweise deckt der Ansatz interne Verbindungsstrukturen, Protokoll-Engines und analoge Schnittstellenschaltungen in einem Vorgang ab. Außerdem ermöglicht der Ansatz es, Takt- und Versorgungsspannungsbelastungen anzulegen. Der Ansatz spricht darüber hinaus alle Klassen von potenziellen Test-Ausreißern während des Wafer-Sort-Tests an. Darüber hinaus kann der Ansatz einen leicht modifizierten Kern-Logik-Test von der Validierung aus ausführen. Der Ansatz arbeitet mit standardisierten flexiblen ATE-Instrumenten. Darüber hinaus ermöglicht der Ansatz eine Post-Silizium-Validierung während des Wafer-Sort-Tests und ermöglicht außerdem ein frühes Feedback an das Design.
  • Jedoch weist der Ansatz auch einige Nachteile auf. Insbesondere ist der Ansatz ein neuer Ansatz außerhalb des MPU-Geschäfts. Der Ansatz setzt die Test-Engineers einer Eingebettete-Software-Lösung, Designer und Validierungs-Engineers einer ATE aus. Darüber hinaus müssen Testfälle manuell erzeugt werden, sofern nicht standardisierte Testfälle „aus der Konserve“ bereitgestellt werden können. Die Testabdeckung hängt von der Qualität dieser Fälle ab. Darüber hinaus beruht der Ansatz auf DFT (design for test), um den Bedarf an spezialisierten HSIO-Instrumenten zu eliminieren.
  • Im Folgenden wird ein Vergleich zwischen unterschiedlichen Ansätzen vorgenommen.
  • Es ist festzustellen, dass SLT und Ende-zu-Ende-Test zwei Ansätze sind, mit denen viele Benutzer, insbesondere Validierungs-Engineers, vertraut sind.
  • Außerdem ist festzustellen, dass SLT eine zusätzliche Testeinfügung erfordert - eine Kombination mit einem beliebigen ATE-Testschritt ist kommerziell nicht sinnvoll.
  • Darüber hinaus ist festzustellen, dass ein Ende-zu-Ende-Test in andere ATE-Test-Setups integriert werden kann. Allerdings erfordert dies „protokollfähige“ ATE-Instrumente. Außerdem ist es sehr schwer, das DUT in einen Zustand maximaler Belastung zu versetzen.
  • Darüber hinaus ist die statistische Korrelation zu einem Abtastmuster einer Timing-Ebene-Belastungsbedingung ein interessanter Ansatz, um Lücken in einem herkömmlichen Abtastmuster abzudecken. Allerdings basiert der Abtasttest auf einem bestimmten Fehlermodell. Es ist unklar, ob ATE-Ausreißer von heute überhaupt auf diese Weise abgedeckt werden können.
  • Mit einem eingebetteten Test ist es möglich, die Test-Ausreißer von heute auf einer ATE bereits während des Wafer-Sort-Tests zu identifizieren. Der Bedarf an neuen spezialisierten ATE-Instrumenten kann nur mit einem entsprechenden DFT eliminiert werden. Um dies erfolgreich anzuwenden, ist ein DUT-Wissen erforderlich, das nicht im Test-Engineering verfügbar ist, sondern in der Validierung und im Design.
  • Es wird angenommen, dass auf lange Sicht eingebettete Tests der richtige Weg sein werden.
  • Schlussfolgerungen - Teil 1
  • Im Folgenden werden einige Schlussfolgerungen gezogen.
  • Es hat sich herausgestellt, dass mit zunehmender Komplexität von SoC-Designs eine Konvergenz zwischen Post-Silizium-Validierung und ATE-Test stattfindet:
    1. 1. ATE-Fähigkeiten sind erforderlich, um Ausnahmefälle in der Hardware/Software-Interaktion bei der Validierung zu finden; und
    2. 2. Tests, die auf der eingebetteten CPU laufen, sind erforderlich, um Ausnahmefallfehler zu identifizieren.
  • Das Ausführen von Eingebettete-Software-Tests auf ATE bietet deshalb große Vorteile sowohl für die Validierung als auch für die Gerätefertigung. Da jedoch die Anwendungsumgebung auf ATE unvollständig ist, gibt es eine hohe Einstiegsbarriere.
  • Dies eröffnet eine Chance für einen neuen Typ von ATE-Produkten: eine Auf-Chip-System-Testumgebung.
  • Es hat sich herausgestellt, dass technologische Komponenten für derartige Umgebungen verfügbar sind, die meisten Teile des bestehenden ATE-Ökosystems ausgenutzt werden können.
  • Es hat sich außerdem herausgestellt, dass eine Konvergenz von SoC-Komponenten es ermöglicht, sich auf ein standardisiertes Produkt zu konzentrieren. Die Dominanz von ARM auf dem Markt erlaubt es sogar, sich anfangs auf eine bestimmte Architektur zu konzentrieren.
  • Zusammenfassend lässt sich sagen, dass Ausführungsbeispiele gemäß der Erfindung zum Testen von Ein-Chip-Systemen in effizienter Weise verwendet werden können und deshalb gegenüber anderen Konzepten vorteilhaft sind.
  • Schlussfolgerungen - Teil 2
  • Lösungen im Stand der Technik
  • Im Folgenden werden einige herkömmliche Lösungen beschrieben und erörtert, und es werden Hintergrundinformationen bereitgestellt, die optional auch bei erfindungsgemäßen Ausführungsbeispielen Anwendung finden können.
  • Auf-Chip-System-Tests (OCST) bezieht sich auf einen Funktionstest eines oder mehrerer Blöcke oder einer oder mehrerer Schnittstellen eines SoC mit Hilfe einer eingebetteten Software, die auf eingebetteten Prozessorkernen dieses SoC läuft. Die eingebettete Software kann den Teststimulus direkt erzeugen und die Testantwort empfangen und/oder das Test-Setup (z. B. Registerprogrammierung) oder Testanalyse und -berichterstattung steuern: z. B. Analysieren von Testantworten und Speichern/Kommunizieren der Ergebnisse, so dass die Außenseite (z. B. ein Testgerät) auf die Testergebnisse zugreifen kann.
    • - Lösungen im Stand der Technik beruhen auf einem Entwickeln und Debuggen des Tests in einer Systemumgebung für Eingebettete-Software-Entwicklung, aber nicht in der Testumgebung. In der Testumgebung ist keine beziehungsweise nur wenig Debug-Unterstützung vorhanden: z. B. Drucken von Zwischenwerten und Textzeichenfolgen durch seriellen Port.
    • - Lösungen im Stand der Technik beruhen auf dem OCST, um proprietäre Wege zum Empfangen von Teststeuerungs-/Bedingungsbefehlen zu verwenden und um Testergebnisse nach außen zu kommunizieren. Dies erfordert außerdem proprietäre Lösungen für die Testumgebung, um diese Befehle/Ergebnisse zu senden/empfangen. Häufig erfordert dies ein mühsames Programmieren auf niedriger Ebene von Testgerätressourcen (z. B. für UART, SWD, l2C oder proprietäre GPIO-Komm.) beziehungsweise dedizierte Testgerätsteuergerätschnittstellen (z. B. falls der USB-Port desselben verwendet wird), um die Kommunikation und Steuerung zwischen der Testgerätumgebung mit dem OCST zu ermöglichen. Dies erhöht den Entwicklungsaufwand und begrenzt die Wiederverwendbarkeit von OCST.
    • - Bisherige Lösungen beruhen auf einem Speichern des OCST (d. h. Testinhalts) auf einem nicht flüchtigen Speicher, der für den SoC in der Testumgebung verfügbar ist, um den OCST zu laden. Die Herausforderungen sind:
      • ◯ Der NV-Speicher ist typischerweise in der Softwareentwicklungsumgebung programmiert und wird dann auf die Testumgebung übertragen.
      • ◯ Der NV-Speicher kann mit Hilfe des SoC in der Testumgebung programmiert werden, ist jedoch eine proprietäre Lösung, die nicht auf andere SoC-Typen anwendbar ist.
      • ◯ Erneutes Programmieren des NV-Speichers ist ein ungewöhnlicher, ineffektiver, fehleranfälliger Prozess in der Fertigungsumgebung.
    • - Lösungen im Stand der Technik speichern häufig eine Suite von OCSTs, die in einem Ausführungslauf ausgeführt werden, anstelle eine Kontrolle individueller OCSTs zu ermöglichen, was es schwer macht, jeden Test zu debuggen, zu charakterisieren und ein-/auszuschalten (was eine typische Anforderung an ein Testsystem ist).
    • - Lösungen im Stand der Technik können auf einem großen RAM zum Ausführen von OCSTs beruhen, der unter Umständen nicht verfügbar ist (z. B. für einen Sondentest). Ein typischer Fall ist das Booten eines umfangreichen OS, was dann die Grundlage für weitere OCSTs ist.
  • Ausführungsbeispiele gemäß der Erfindung lösen vollständig alle oder mildern zumindest alle (oder einige) der zuvor in der Beschreibung der herkömmlichen Lösungen genannten Nachteile.
  • Probleme, die durch Ausführungsbeispiele der Erfindung gelöst werden.
  • Im Folgenden werden einige Vorteile von Ausführungsbeispielen der Erfindung gegenüber herkömmlichen Lösungen diskutiert. Es ist jedoch festzustellen, dass es nicht erforderlich ist, dass erfindungsgemäße Ausführungsbeispiele einige oder alle der Vorteile, die im Folgenden genannt werden, aufweisen.
  • Einige Ausführungsbeispiele gemäß der Erfindung lösen vollständig alle oder mildern alle Nachteile, die in der Beschreibung der vorteilhaften Lösung aufgeführt sind.
  • Weiterhin ermöglichen Ausführungsbeispiele gemäß der beschriebenen Erfindung optional zukünftige Lösungen:
    • - Durch Definieren von Standardschnittstellen ermöglicht die Erfindung einen automatisierten Ablauf von SoC-Verifizierungstests (die als eingebettete Software implementiert sind) für eine Testumgebung zur effektiven Ausführung und Qualifizierung jedes Tests.
    • - Fortgeschrittene Test- und Diagnosemethodiken, die sich auf Tracing und Dumping von DUT-Zuständen mit hoher Bandbreite stützen: z. B. statistische Ansätze, wie sie in „Bug Positioning Systems“ beschrieben sind, um ein gültiges Ausführungsverhalten zu beschreiben und fehlerhafte Bereiche für die Ursachenanalyse zu identifizieren.
    • - Durch Bereitstellen einer effektiven funktionalen Schnittstelle zwischen der Testumgebung und dem SoC können andere Testmethodiken profitieren: z. B. flexibles Zuführen von strukturellen Teststimuli in das DUT beziehungsweise Empfangen derselben.
  • Vorteile der Erfindung gegenüber dem bisher Dagewesenen
  • Ausführungsbeispiele gemäß der Erfindung etablieren eine effektive Testumgebung für Auf-Chip-System-Tests, indem die DUT-spezifische Natur des OCST selbst von der Infrastruktur und den Fähigkeiten getrennt werden, die zum Testen erforderlich sind. Dementsprechend werden flexible Lösungen für OCST als neuer Testtyp vorgeschlagen, für den eine Testumgebung alle standardmäßigen Testanwendungsfälle unterstützen muss, z. B.:
    • - Entwicklung
    • - Debugging
    • - Charakterisierung
    • - Effiziente Ausführung
    • - Datenaufzeichnung
    • - Einsatz in der Fertigung
  • Dies ermöglicht eine effektive Zusammenarbeit zwischen dem OCST-Entwickler (typischerweise ein Design-, Bench- oder Eingebettete-Software-Entwickler) und dem Test-Engineer. Jeder Benutzer kann intuitiv in seiner Umgebung weiterarbeiten, z. B.:
    • - Der OCST-Entwickler findet eine produktive Entwicklungs- und Debug-Umgebung auf dem Testgerät vor. Dies ist besonders kritisch während des Hochdruck-Erstes-Silizium-Einschaltens (high pressure first-silicon turn-on).
    • - Der Test-Engineer kann jeder OCST auf dieselbe Weise wie bei anderen Testtypen charakterisieren: z. B. Sweep Vdd zur Bestimmung von Vmin.
    • - Beim Einsatz eines OCST in der Fertigung ist kein zusätzlicher Schritt durch die Bedienperson erforderlich, um die Installation eines OCST auf einem NV-Speicher zu installieren, der sich auf dem Loadboard befindet.
  • Darüber hinaus ist es möglich, für jedes oben genannte Problem einen Vorteil aufzuführen.
  • Beschreibung der Konstruktion und des Betriebs von erfindungsgemäßen Ausführungsbeispielen
  • Im Folgenden wird eine Beschreibung des Konstruktionsbetriebs einiger Ausführungsbeispiele gemäß der Erfindung bereitgestellt. Es ist jedoch festzustellen, dass die im Folgenden beschriebenen Ausführungsbeispiele einzeln verwendet werden können. Es ist jedoch auch festzustellen, dass Merkmale, Funktionalitäten und die Details der im Folgenden erwähnten Ausführungsbeispiele in jedes der anderen Ausführungsbeispiele eingeführt werden können, sowohl individuell als auch in Kombination.
  • Auf der höchsten Ebene schlägt die Lösung folgende Schlüsselkomponenten vor, die für eine effektive OCST-Umgebung kombiniert werden (wobei die Komponenten auch einzeln verwendet werden können):
    1. 1. OCST-Teststeuergerät:
      1. a. Eine neuartige Testkomponente, die die folgenden Fähigkeiten bietet (oder bei einigen Ausführungsbeispielen eine oder mehrere der folgenden Fähigkeiten):
        1. i. Kommunikation mit dem DUT über die physischen Schnittstellen desselben, z. B.:
          1. 1. Debug- und Steuerschnittstellen mit niedriger Latenz, z. B. JTAG, SWD, SPI, I2C, UART
          2. 2. Funktionsschnittstellen mit hoher Bandbreite, z. B. USB, PCI
        2. ii. Flexible Zuweisung der korrekten Kommunikationsschnittstelle zu der DUT-Schnittstelle oder Zuweisen von parametrischen Testressourcen, die typischerweise zum Testen von Kontakt und DC der physischen DUT-Schnittstelle verwendet werden.
        3. iii. Ausführen eines versatilen Softwarestapels, der typischerweise umfasst: ein OS (z. B. eingebettetes Linux), allgemeine Dienste für OCST, Treiber für die Kommunikation über die physischen Schnittstellen mit dem DUT, anwendungsspezifische Setups und Routinen (d. h. ausführbarer Code), die von dem Benutzer bereitgestellt werden.
        4. iv. Fähigkeit, die OCST-Umgebung auf dem DUT und der DUT-Schnittstelle zu laden beziehungsweise zu initialisieren. Diese wird z. B. als Teil des Testprogramms vorbereitet und gepflegt und zur schnellen Initialisierung jedes DUT in dem Speicher des OCST-Teststeuergeräts gespeichert.
        5. v. Fähigkeit, einen OCST in den DUT-RAM, DUT-NV-Speicher oder NV-Speicher auf der DUT-Schnittstelle zu laden. Beispielsweise wird jeder OCST als Teil des Testprogramms vorbereitet und gepflegt und zum schnellen Laden in jedes DUT in dem Speicher des OCST-Teststeuergeräts gespeichert.
        6. vi. Fähigkeit, einen OCST-Parametersatz in den DUT-RAM, DUT-NV-Speicher oder NV-Speicher auf der DUT-Schnittstelle zu laden. Beispielsweise wird jeder OCST-Parametersatz als Teil des Testprogramms vorbereitet und gepflegt und zum schnellen Laden in jedes DUT in dem Speicher des OCST-Teststeuergeräts gespeichert.
        7. vii. Fähigkeit, einen spezifischen OCST zu starten, der auf dem DUT geladen ist.
        8. viii. Steuerung der gesamten Testausführung wie von dem Benutzer in einer universellen Testsequenzierungssprache programmiert, die für alle Testgerätressourcen gilt: z. B. die Betriebssequenz, die von 93000 SmarTest 8 verwendet wird.
        9. ix. Effiziente Steuerung und Synchronisation anderer Testressourcen: Z. B. kann das OCST-Teststeuergerät die an den DUT angelegte Leistung direkt steuern. Vorzugsweise erfordert die Ausführung dieser Aktionen keine Kommunikation mit der Software höherer Ebene, die typischerweise auf einem Testgerätsteuergerät läuft. Stattdessen wird diese zum Beispiel durch lokale Kommunikations- und Synchronisationsschnittstellen implementiert, die die Testgerätressourcen direkt verbinden.
        10. x. Fähigkeit, Befehle und Daten von dem OCST, die auf dem DUT läuft, zu empfangen, um den Ablauf der Testausführung und die beteiligten Testressourcen zu steuern, z. B. Implementieren einer bedingten Ausführung oder Variieren von externen Testbedingungen abhängig von Beobachtungen, die durch den OCST erfolgen, die auf dem DUT läuft.
      2. b. Sowohl eine physische als auch eine virtuelle Implementierung ist möglich, mit verschiedenen Vor- und Nachteilen, z. B.:
        1. i. Physisch: Vorzugsweise in einem vielseitigen dedizierten Testgerätteilsystem implementiert, das beispielsweise Folgendes umfasst:
          1. 1. Einen System-SOC (z. B. Xilinx Zync), der eine Eingebettete-Software-Umgebung, einen FPGA-Block sowie verschiedene physische Instanzen zur Kommunikation (z. B. USB, GPIO) bereitstellt; alternativ kann als weiteres Beispiel ein x86-eingebetteter PC verwendet werden.
          2. 2. Front-End-Elektronik in Richtung des DUT: z. B. eine PMU für DC-Messungen, Schalter für Routing, Pegelumsetzer zum Anpassen an den spezifischen Schnittstellenstandard.
          3. 3. Back-End-Schnittstellen zur Kommunikation und Synchronisation mit anderen Testgerätkomponenten.
        2. ii. Virtuell: Vorzugsweise implementiert durch erneutes Verwenden eines Allzweck-Testmoduls (z. B. einer digitalen Testgerätkarte). Typischerweise können Front-End- und Back-End-Fähigkeiten dieser Karte für OCST verwendet werden. Jedoch müssen die folgenden Fähigkeiten eventuell hinzugefügt werden:
          1. 1. Ein effektives Programmiermodell auf hoher Ebene zum Kommunizieren mit dem DUT (OCST) über die physischen Schnittstellen desselben. Dies kann hinsichtlich Geschwindigkeit und Funktionalität durch das erweiterte Testmodul begrenzt sein.
          2. 2. Die Möglichkeit, den OCST-Softwarestapel aufzuteilen, damit derselbe entweder direkt auf dem Modul (unter Annahme eines verfügbaren eingebetteten Prozessors) oder auf dem Testgerätsteuergerät läuft.
    2. 2. OCST-Entwicklungs- und Debug-Werkzeuge (optional; ein oder mehrere der Merkmale können implementiert sein)
      1. a. Werkzeugsätze:
        1. i. Typischerweise verfügt der Eingebettete-Software-Entwickler, der zum Entwickeln eines OCST verantwortlich ist, über eine bevorzugte oder vorbestimmte Entwicklungs- und Debug-Umgebung. Die vorgeschlagene Lösung bietet beispielsweise Schnittstellen zum Unterstützen verschiedener Werkzeugsätze an.
        2. ii. Die Lösung bietet eine spezifische OCST-Entwicklungs- und Debug-Umgebung, die in die Testgerätumgebung integriert ist (z. B. Eclipse Work Center von 93000).
          1. 1. Dies erleichtert die konsistente Benennung und Verwendung von Komponenten in dem OCST-Quellcode und dem Testprogramm, das auf dem Testgerät läuft: z. B. können OCST-Entwicklungs- und Debug-Werkzeuge Testgerätressourcen kennen, auf die der OCST-Quellcode (über die OCST-Laufzeitumgebung) zugreifen kann, z. B. Testgrenzen, Testbedingungen oder Ergebnisse anderer Tests.
          2. 2. Unterstützt ein Mapping des kompilierten Codes auf die verfügbaren begrenzten Speicherressourcen, z. B.: integrierten SRAM, L2-Cache. Umfasst bei Bedarf Code zur Konditionierung des Speicherteilsystems des SOC.
      2. b. Schnittstellen zwischen der Debug-Software, der Testgerätumgebung und dem DUT
        1. i. Schnittstellen zwischen der Debug-Software und der Testgerätumgebung:
          1. 1. Fernsteuerung: Während der Debug- und Testausführung kann die Testumgebung die Debug-Software (typischerweise von einem Drittanbieter oder Open Source) verwenden, um spezifische Vorgänge durchzuführen, für die dieselbe entwickelt wurde: z. B. Laden eines OCST auf das DUT. Die Testumgebung stützt sich auf eine „Remote Control API“, um die Debug-Umgebung für diese Zwecke zu verwenden.
          2. 2. DUT-Treiber: Während der Debug- und Testausführung kann die Debug-Software unter Umständen Zugriff auf das DUT über die physischen Schnittstellen desselben benötigen: z. B. JTAG. Anstatt eine eigene physische Schnittstelle zu dem DUT zu haben, kann sich die Debug-Software auf die Schnittstelle des OCST-Teststeuergeräts zu dem DUT stützen. Dementsprechend implementiert die Testumgebung einen DUT-Treiber, der die Funktionen der Debug-Software unterstützt.
        2. ii. Physische Schnittstellen zwischen der Debug-Software und dem DUT
          1. 1. Direkter physischer Zugriff auf die Umgebung: z. B. auf den JTAG-Port, der auf dem Loadboard geschaltet werden kann.
          2. 2. Verwendung des OCST-Teststeuergeräts als Kommunikationskanal.
    3. 3. Softwarekomponenten und Umgebung, die eine effektive Verwendung von OCST ermöglichen.
      1. a. Verteilte Umgebung zum Unterstützen der nahtlosen Entwicklung und Ausführung einer Testmethodik, die aus Test-Setup und Code besteht, der in der Testgerätumgebung (d. h. Teststeuergerät-Workstation und OCST-Teststeuergerät) und in der DUT-Umgebung läuft (d. h. der OCST selbst sowie andere Komponenten auf der DUT-Schnittstelle, z. B. NV-Speicher). Dieselbe ist unabhängig von variierenden Kommunikationsschnittstellen zwischen dem OCST-Teststeuergerät und dem DUT.
        1. i. OCST-Laufzeitumgebung (auf dem DUT):
          1. 1. APIs und Dienste, auf die sich ein OCST stützen kann, um mit der Testgerätumgebung allgemein (z. B. um Testparameter zu empfangen und Steuerbefehle an das OCST-Steuergerät zu senden) und mit dem spezifischen Testverfahren, das auf der Testgerätumgebung läuft (z. B. um zwischen Variablen auszutauschen, die die höhere Rechenleistungsfähigkeiten einer Testgerät-Workstation nutzen), zu kommunizieren.
          2. 2. Die OCST-Laufzeitumgebung ist standardisiert, um die erneute Verwendung von OCST über verschiedene DUTs hinweg zu ermöglichen. Dies wird durch darunterliegende Schichten von Software ermöglicht, die die variierende Hardwareumgebung abstrahieren: z. B. unter Verwendung eines Linux-Gerätebaums, der die Hardwareunterschiede beschreibt.
        2. ii. OCST-Test-Runner auf dem DUT:
          1. 1. Programm (vorzugsweise als separater Prozess ausgeführt), das mit der Testgerätumgebung zusammenarbeitet, um OCSTs zu laden und auszuführen. Dasselbe kann auch als Watchdog dienen, der die fortgesetzte Ausführung und das Ansprechverhalten auf die Testgerätumgebung unabhängig von einem teilweise defekten DUT oder einem defekten OCST sicherstellt.
          2. 2. Dies ist optional, da eine kritische Funktion desselben auch von der Testgerätumgebung unter Verwendung der Debug-Schnittstelle des DUT ausgeführt werden kann.
        3. iii. Testgerätlaufzeitumgebung, erweitert für OCST:
          1. 1. APIs und Dienste, auf die sich das Testverfahren des Benutzers stützen kann, um das OCST-Teststeuergerät einzurichten und mit demselben zu kommunizieren.
          2. 2. APIs und Dienste, auf die sich das Testverfahren des Benutzers stützen kann, um den OCST, der auf dem DUT läuft, einzurichten und mit derselben zu kommunizieren.
        4. iv. Synchronisation von Testgerätressourcen, OCST-Teststeuergerät und OCST:
          1. 1. Aktionen, die das OCST-Teststeuergerät während der Testausführung zur Unterstützung des OCST durchführen kann, z. B.: bedingte Sprünge abhängig von Steuerinformationen, die von dem OCST kommen.
          2. 2. Erweiterungen der Fähigkeiten des Testgerätmoduls oder eines Aktionssatzes, um OCST zu unterstützen: z. B. Warten auf das Abschließen des OCST.
          3. 3. Erforderliche Hardwareinfrastruktur zur effizienten Signalisierung und Kommunikation über Testgerätressourcen und OCST-Teststeuergeräte hinweg, ohne dass eine Testgerätsteuergerät-Workstation-Software erforderlich ist.
      2. b. Alternative Softwareumgebung
        1. i. Unter Verwendung eines OCST-Betriebssystems: Vorausgesetzt, dass eine umfangreiche Ausführungsumgebung (z. B. ausreichend RAM) vorhanden ist, kann das DUT ein OS und die erforderlichen Gerätetreiber laden. Dies kann die Testabdeckung erhöhen und fortgeschrittene Dienste für einen OCST, die OCST-Laufzeitumgebung und den OCST-Runner bieten: z. B. Zugriff auf ein Dateisystem.
          1. 1. Das OCST-OS ist eine spezifische Version eines OS, das auf einer beschränkten Systemumgebung des DUT beruht: z. B. ohne eine physische Anzeige. Dementsprechend ist der Satz von Standardgerätetreibern begrenzt und kann konfiguriert werden.
          2. 2. Das OCST-OS ist standardisiert, um eine erneute Verwendung von OCST über verschiedene DUTs hinweg zu ermöglichen. Dies wird durch darunter liegende Schichten von Software ermöglicht, die die variierende Hardwareumgebung abstrahieren: z. B. unter Verwendung eines Linux-Gerätebaums, der die Hardwareunterschiede beschreibt.
          3. 3. Das OCST-OS unterstützt DUT oder anwendungsspezifische Gerätetreiber.
        2. ii. Bare Metal. Die Ausführungsumgebung des DUT könnte eingeschränkt sein und keine fortgeschrittenen OS-Dienst erfordern. Daher wird das OCST-Betriebssystem möglicherweise nicht verwendet, und die Funktionen der OCST-Laufzeitumgebung werden direkt auf der Hardware implementiert (vergleichbar mit der Umgebung eines Bootloaders).
  • Für Details, die alle als optional zu betrachten sind, wird auf die vollständige Beschreibung verwiesen.
  • Ausführungsbeispiele gemäß der vorliegenden Erfindung können beispielsweise bei dem Testen von SOCs, SIPs oder Modulen mit zumindest einem eingebetteten Prozessor verwendet werden. Die folgende Offenbarung führt lediglich „SOC“ oder „DUT“ auf, ist jedoch auf höhere Integrationsebenen in einem Paket oder auf jede Art von Modul, das ein (Teil-)System implementiert, anwendbar.
  • Ausführungsbeispiele der Erfindung können beispielsweise in einem 93000-Chip-Testgerät eingesetzt werden, können aber allgemein als Erweiterung zu jeder Testlösung verwendet werden.
  • Implementierunqsalternativen
  • Obwohl manche Aspekte im Zusammenhang mit einem Apparat beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, wobei ein Block oder ein Bauelement auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem Verfahrensschritt beschrieben werden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals eines entsprechenden Apparats dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat oder unter Verwendung eines Hardware-Apparats, zum Beispiel eines Mikroprozessors, eines programmierbaren Computers oder einer elektronischen Schaltung, ausgeführt werden. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen derartigen Apparat ausgeführt werden.
  • 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, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, durchgeführt werden, 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 weisen einen Datenträger mit elektronisch lesbaren Steuersignalen auf, 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 ein Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahingehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer läuft. Der Programmcode kann beispielsweise auf einem maschinenlesbaren Träger gespeichert sein.
  • Andere Ausführungsbeispiele weisen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren auf, das 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 lä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 aufgezeichnete Medium sind üblicherweise greifbar und/oder nichtflüchtig.
  • 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 beispielsweise dahingehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, übertragen zu werden.
  • Ein weiteres Ausführungsbeispiel weist eine Verarbeitungseinrichtung auf, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahingehend konfiguriert oder angepasst ist, 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 weist einen Apparat oder ein System auf, der bzw. das dazu konfiguriert ist, ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren an einen Empfänger zu übertragen (z. B. elektronisch oder optisch). Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder dergleichen sein. Der Apparat oder das System kann beispielsweise einen Dateiserver zur Übertragung des Computerprogramms an den Empfänger aufweisen.
  • 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 vorzugsweise seitens eines beliebigen Hardware-Apparats durchgeführt.
  • Der hierin beschriebene Apparat kann seitens eines Hardware-Apparats oder eines Computers oder einer Kombination aus einem Hardware-Apparat und einem Computer implementiert werden.
  • Der hierin beschriebene Apparat oder beliebige Komponenten des hierin beschriebenen Apparats kann bzw. können zumindest teilweise in Hardware und/oder in Software implementiert werden.
  • Die hier beschriebenen Verfahren können seitens eines Hardware-Apparats oder eines Computers oder einer Kombination aus einem Hardware-Apparat und einem Computer durchgeführt werden.
  • Die hierin beschriebenen Verfahren oder beliebige Komponenten des hierin beschriebenen Apparats können zumindest teilweise durch Hardware und/oder durch Software ausgeführt werden.
  • Die oben beschriebenen Ausführungsbeispiele sind für die Prinzipien der vorliegenden Erfindung lediglich veranschaulichend. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Details für andere Fachleute auf dem Gebiet offensichtlich sind. Es ist daher beabsichtigt, dass dieselben lediglich durch den Schutzumfang der anstehenden Patentansprüche und nicht durch die spezifischen Details eingeschränkt sind, die anhand der Beschreibung und Erläuterung der Ausführungsbeispiele hierin präsentiert werden.

Claims (29)

  1. Eine automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) zum Testen eines Testobjekts (104; 400; 500; 630; 730; 830; 930; 1030; 1130; 1230; 1310; 1430; 1510), wobei die automatisierte Testeinrichtung ein Auf-Chip-System-Teststeuergerät (110; 210; 1620) aufweist, wobei das Auf-Chip-System-Teststeuergerät zumindest eine Debug-Schnittstelle (112; 252; 1650) oder eine Steuerschnittstelle (112; 254; 1650) aufweist, die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren; und wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, einen Test eines Testobjekts zu steuern, bei dem es sich um ein Ein-Chip-System handelt.
  2. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß Anspruch 1, wobei das Auf-Chip-System-Teststeuergerät zumindest eine Schnittstelle mit hoher Bandbreite (114; 256; 1652, 1654) aufweist, die dazu konfiguriert ist, mit dem Testobjekt zu kommunizieren.
  3. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß Anspruch 1 oder 2, wobei die automatisierte Testeinrichtung dazu konfiguriert ist, die Debug-Schnittstelle (112; 252; 1650) oder die Steuerschnittstelle (114; 254; 1650) oder die Schnittstelle mit hoher Bandbreite (114; 256; 1652, 1654) variabel einer Testobjektschnittstelle (216) zuzuweisen.
  4. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 3, wobei die automatisierte Testeinrichtung dazu konfiguriert ist, eine oder mehrere parametrische Testressourcen (220; 626, 629) variabel dem Testobjekt zuzuweisen.
  5. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 4, wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, einen Softwarestapel (258; 1622) auszuführen, der ein Betriebssystem (1622b), eine Auf-Chip-System-Testdienstsoftware (1622a), einen oder mehrere Treiber (1622c, 1622d, 1622e, 1622f) zum Kommunizieren mit dem Testobjekt über die Schnittstellen (112, 114; 252, 254, 256; 1650, 1652, 1654) aufweist.
  6. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 5, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) dazu konfiguriert ist, anwendungsspezifische Routinen durchzuführen, die durch einen Benutzer bereitgestellt werden.
  7. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 6, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) dazu konfiguriert ist, eine Auf-Chip-System-Testumgebung (246a, 246b, 246c, 246d, 246e, 246f; 1232, 1232a, 1232b, 1236, 1238, 1242; 1438, 1440) auf ein Testobjekt zu laden; und/oder wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, einen Auf-Chip-System-Test (1240; 1440) auf ein Testobjekt zu laden; und/oder wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, eine Auf-Chip-System-Testumgebung (246a, 246b, 246c, 246d, 246e, 246f; 1232, 1232a, 1232b, 1236, 1238, 1242; 1438, 1440) auf einem Testobjekt zu initialisieren.
  8. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 7, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) dazu konfiguriert ist, einen Parametersatz, der einen Auf-Chip-System-Test parametrisiert, auf ein Testobjekt hochzuladen.
  9. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 8, wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, einen Auf-Chip-System-Test (1240; 1440) zu starten, der auf ein Testobjekt geladen ist.
  10. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 9, wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, den Test des Testobjekts auf Basis eines gesamten Testausführungsprogramms in einer Testsequenzierungssprache zu steuern.
  11. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 10, wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, eine oder mehrere analoge Testressourcen (220; 626, 629) zu steuern; und/oder wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, zusätzlich zu den Schnittstellen (112, 114; 252, 254, 256; 1650, 1652, 1654) eine oder mehrere digitale Testressourcen (230, 624, 628) zu steuern; und/oder wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, eine oder mehrere analoge Testressourcen (220; 626, 629) zu synchronisieren; und/oder wobei das Auf-Chip-System-Teststeuergerät dazu konfiguriert ist, zusätzlich zu den Schnittstellen eine oder mehrere digitale Testressourcen (230, 624, 628) zu synchronisieren.
  12. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 11, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) eine lokale Kommunikationsschnittstelle aufweist, um eine oder mehrere analoge Testressourcen (220; 626, 629) und/oder eine oder mehrere digitale Testressourcen (230, 624, 628) zu steuern; und/oder wobei das Auf-Chip-System-Teststeuergerät eine lokale Synchronisationsschnittstelle aufweist, um eine oder mehrere analoge Testressourcen (220; 626, 629) und/oder eine oder mehrere digitale Testressourcen (230, 624, 628) zu synchronisieren.
  13. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 12, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) dazu konfiguriert ist, Befehle und/oder Daten von einem Auf-Chip-System-Test (1240; 1440) zu empfangen, der auf dem Testobjekt läuft, und einen Testausführungsablauf in Abhängigkeit von den empfangenen Befehlen und/oder den empfangenen Daten anzupassen.
  14. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 13, wobei das Auf-Chip-System-Teststeuergerät (110; 210; 1620) dazu konfiguriert ist, Befehle und/oder Daten von einem Auf-Chip-System-Test (1240; 1440) zu empfangen, der auf dem Testobjekt läuft, und Testressourcen (220, 230; 624, 626, 628, 629) in Abhängigkeit von den empfangenen Befehlen und/oder den empfangenen Daten anzupassen.
  15. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 14, wobei das Auf-Chip-System-Teststeuergerät eine Zentraleinheit (250; 1640) aufweist, die dazu konfiguriert ist, eine Eingebettete-Software-Umgebung und einen oder mehrere Schnittstellenblöcke bereitzustellen, die die Debug-Schnittstelle und/oder die Steuerschnittstelle und/oder die Schnittstelle mit hoher Bandbreite implementieren; und wobei das Auf-Chip-System-Teststeuergerät eine Front-End-Elektronik (252, 254, 256; 1650, 1652, 1654) aufweist, um dem Testobjekt ein oder mehrere Signale an das Testobjekt bereitzustellen und um ein oder mehrere Signale von dem Testobjekt zu empfangen; und wobei das Auf-Chip-System-Teststeuergerät eine oder mehrere Back-End-Schnittstellen aufweist, die dazu konfiguriert sind, mit einer oder mehreren anderen Komponenten der automatisierten Testeinrichtung zu kommunizieren und/oder mit einer oder mehreren anderen Komponenten der automatisierten Testeinrichtung zu synchronisieren.
  16. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 15, wobei die automatisierte Testeinrichtung eine Schnittstelle (242, 244) zu einer oder mehreren Entwicklungs- und Debug-Umgebungen aufweist.
  17. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 16, wobei die automatisierte Testeinrichtung eine Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) aufweist, die dahingehend angepasst ist, sowohl eine Auf-Chip-System-Testsoftware zur Ausführung auf dem Testobjekt als auch ein Testprogramm, das durch die automatisierte Testeinrichtung ausgeführt werden soll, zu entwickeln und zu debuggen.
  18. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß Anspruch 17, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) einen Zugriff auf Testressourcen (220, 230; 624, 626, 628, 629) der automatisierten Testeinrichtung ermöglicht, wenn eine Auf-Chip-System-Testsoftware (1240; 1440), die auf dem Testobjekt ausgeführt werden soll, in der Entwicklung und/oder im Debugging ist.
  19. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß Anspruch 17 oder Anspruch 18, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) einen Programmcode (246e) aufweist, der einen Zugriff auf einen Speicherinhalt von dem Auf-Chip-System (104; 400; 500; 630; 730; 830; 930; 1030; 1130; 1230; 1310; 1430; 1510) über eine Schnittstelle (112, 114; 252, 254, 256; 1650, 1652, 1654) der automatisierten Testeinrichtung ermöglicht.
  20. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 19, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) eine Schnittstelle (242) aufweist, um es einer Debug-Software zu ermöglichen, ein Hochladen eines Programms und/oder eines oder mehrerer Parametersätze auf das Testobjekt zu steuern.
  21. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 20, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) eine Schnittstelle (244) aufweist, um es einer Debug-Software zu ermöglichen, auf eine Debug-Schnittstelle des Testobjekts zuzugreifen.
  22. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 21, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) dazu konfiguriert ist, einer Debug-Software direkten Zugriff auf eine Debug-Schnittstelle des Testobjekts bereitzustellen.
  23. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 22, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) eine Anwendungsprogrammierschnittstelle (246f) zur Verwendung bei Entwicklung einer Auf-Chip-System-Software aufweist, um eine Kommunikation zwischen dem Testobjekt und Testressourcen (220, 230; 624, 626, 628, 629) der automatisierten Testeinrichtung zu ermöglichen, wenn die entwickelte Auf-Chip-System-Testsoftware auf dem Testobjekt ausgeführt wird.
  24. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß Anspruch 23, wobei die Entwicklungs- und Debug-Schnittstelle (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) außerdem eine Testgerätsoftware (246g) aufweist, um eine Kommunikation der automatisierten Testeinrichtung mit einem Testobjekt zu unterstützen, das die entwickelte Auf-Chip-System-Testsoftware ausführt.
  25. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 24, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) ein Programm (246b, 246c) zur Verwendung bei Entwicklung einer Auf-Chip-System-Testsoftware (1240; 1440) aufweist, um ein Hochladen weiterer Software von der automatisierten Testeinrichtung auf das Testobjekt zu ermöglichen und/oder ein Steuern einer Programmausführung auf dem Testobjekt seitens der automatisierten Testeinrichtung zu ermöglichen.
  26. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 17 bis 25, wobei die Entwicklungs- und Debug-Umgebung (240; 612, 614; 1412, 1414a, 1414b, 1418, 1419; 1612a, 1612b, 1612c, 1612e, 1612f) ein Programm (246d) zur Verwendung bei Entwicklung einer Auf-Chip-System-Testsoftware aufweist, um eine Programmausführung auf dem Testobjekt zu überwachen.
  27. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 26, wobei die automatisierte Testeinrichtung dazu konfiguriert ist, eine oder mehrere Testgerätressourcen, das Auf-Chip-System-Teststeuergerät und einen Auf-Chip-System-Test zu synchronisieren, der auf dem Testobjekt ausgeführt wird.
  28. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 27, wobei die automatisierte Testeinrichtung dazu konfiguriert ist, bedingte Sprünge ansprechend auf Steuerinformationen durchzuführen, die seitens des Auf-Chip-System-Tests (1240; 1440) bereitgestellt werden, der auf dem Testobjekt läuft.
  29. Automatisierte Testeinrichtung (100; 200; 610, 620; 710, 720; 810, 820; 910, 920; 1010, 1020; 1110, 1120; 1210, 1220; 1410, 1420) gemäß einem der Ansprüche 1 bis 28, wobei die automatisierte Testeinrichtung dazu konfiguriert ist, auf ein Abschließen eines Auf-Chip-System-Tests zu warten, der auf dem Testobjekt läuft.
DE112020000469.4T 2019-01-22 2020-01-22 Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet Pending DE112020000469T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962795456P 2019-01-22 2019-01-22
US62/795,456 2019-01-22
PCT/EP2020/051538 WO2020152230A1 (en) 2019-01-22 2020-01-22 Automated text equipment using an on-chip-system test controller

Publications (1)

Publication Number Publication Date
DE112020000469T5 true DE112020000469T5 (de) 2021-10-07

Family

ID=69192062

Family Applications (3)

Application Number Title Priority Date Filing Date
DE112020000469.4T Pending DE112020000469T5 (de) 2019-01-22 2020-01-22 Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet
DE112020000036.2T Pending DE112020000036T5 (de) 2019-01-22 2020-01-22 Automatisierte prüfeinrichtung zum prüfen eines oder mehrerer prüfobjekte, verfahren zum automatisierten prüfen eines oder mehrerer prüfobjekte und computerprogramm unter verwendung eines pufferspeichers
DE112020000035.4T Pending DE112020000035T5 (de) 2019-01-22 2020-01-22 Automatisierte prüfeinrichtung zum prüfen eines oder mehrerer prüfobjekte, verfahren zum automatisierten prüfen eines oder mehrerer prüfobjekte und computerprogramm zur handhabung von befehlsfehlern

Family Applications After (2)

Application Number Title Priority Date Filing Date
DE112020000036.2T Pending DE112020000036T5 (de) 2019-01-22 2020-01-22 Automatisierte prüfeinrichtung zum prüfen eines oder mehrerer prüfobjekte, verfahren zum automatisierten prüfen eines oder mehrerer prüfobjekte und computerprogramm unter verwendung eines pufferspeichers
DE112020000035.4T Pending DE112020000035T5 (de) 2019-01-22 2020-01-22 Automatisierte prüfeinrichtung zum prüfen eines oder mehrerer prüfobjekte, verfahren zum automatisierten prüfen eines oder mehrerer prüfobjekte und computerprogramm zur handhabung von befehlsfehlern

Country Status (7)

Country Link
US (3) US11385285B2 (de)
JP (3) JP7058759B2 (de)
KR (3) KR102604010B1 (de)
CN (2) CN111989580B (de)
DE (3) DE112020000469T5 (de)
TW (3) TW202202865A (de)
WO (3) WO2020152231A1 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11204849B2 (en) 2020-03-13 2021-12-21 Nvidia Corporation Leveraging low power states for fault testing of processing cores at runtime
US11809570B2 (en) * 2020-10-06 2023-11-07 Newae Technology Inc Method and apparatus for analyzing side channel-related security vulnerabilities in digital devices
US11719749B1 (en) * 2020-10-22 2023-08-08 Cadence Design Systems, Inc. Method and system for saving and restoring of initialization actions on dut and corresponding test environment
US20220155370A1 (en) * 2020-11-17 2022-05-19 Synopsys, Inc. Device under test synchronization with automated test equipment check cycle
US11836059B1 (en) 2020-12-14 2023-12-05 Sanblaze Technology, Inc. System and method for testing non-volatile memory express storage devices
CN112597006B (zh) * 2020-12-14 2023-10-03 中国航发控制系统研究所 一种嵌入式软件集成测试自动化执行系统及方法
US11431379B1 (en) * 2021-03-31 2022-08-30 Teradyne, Inc. Front-end module
CN115391108A (zh) * 2021-05-25 2022-11-25 爱德万测试股份有限公司 自动测试设备系统及其自动测试设备方法
CN113572661B (zh) * 2021-07-28 2022-12-27 迈普通信技术股份有限公司 一种测试多激活检测性能的系统和方法
CN113836060B (zh) * 2021-09-24 2024-05-28 北京机电工程研究所 一种适用于仿真模型及流程模型的分布式实时仿真平台
CN113961405B (zh) * 2021-09-30 2022-10-28 北京百度网讯科技有限公司 状态切换指令验证方法、装置、电子设备及存储介质
CN114167258B (zh) * 2021-11-29 2024-03-22 上海御渡半导体科技有限公司 一种ate测试系统的数据存储和读取装置及方法
CN113904970B (zh) * 2021-12-09 2022-03-01 伟恩测试技术(武汉)有限公司 一种半导体测试设备的传输系统及方法
CN114461150A (zh) * 2022-02-09 2022-05-10 马来西亚明试国际有限公司 一种用于自动测试设备数据聚合的方法、系统及存储介质
KR102461404B1 (ko) * 2022-04-08 2022-10-31 주식회사 세미파이브 시스템 온 칩과 메모리 사이의 통신을 위한 ｉｏ 파라미터를 설정하는 방법 및 장치
US11853251B2 (en) * 2022-05-04 2023-12-26 Qualcomm Incorporated On-die chip-to-chip (C2C) link state monitor
CN116340191B (zh) * 2023-05-31 2023-08-08 合肥康芯威存储技术有限公司 一种存储器固件的测试方法、装置、设备及介质
CN117290278A (zh) * 2023-10-10 2023-12-26 合芯科技有限公司 芯片内硬件互联结构、芯片、服务器及方法

Family Cites Families (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2966417B2 (ja) * 1988-09-05 1999-10-25 株式会社アドバンテスト 論理集積回路試験装置
US7328387B2 (en) * 2004-12-10 2008-02-05 Texas Instruments Incorporated Addressable tap domain selection circuit with selectable ⅗ pin interface
US5103450A (en) * 1989-02-08 1992-04-07 Texas Instruments Incorporated Event qualified testing protocols for integrated circuits
US5321702A (en) * 1989-10-11 1994-06-14 Teradyne, Inc. High speed timing generator
JP3114753B2 (ja) * 1991-10-31 2000-12-04 九州日本電気株式会社 Ｌｓｉテスト方法
JPH07244130A (ja) * 1994-03-02 1995-09-19 Sony Tektronix Corp テストパターン発生器
JPH08129508A (ja) * 1994-10-31 1996-05-21 Toshiba Corp コンピュータシステム及びその共有メモリ制御方法
JPH10240560A (ja) * 1997-02-26 1998-09-11 Toshiba Corp 波形信号処理装置
GB9805054D0 (en) * 1998-03-11 1998-05-06 Process Intelligence Limited Memory test system with buffer memory
AU9654198A (en) 1998-06-29 2000-01-17 Iliya Valeryevich Klochkov A skew calibration means and a method of skew calibration
US6452411B1 (en) * 1999-03-01 2002-09-17 Formfactor, Inc. Efficient parallel testing of integrated circuit devices using a known good device to generate expected responses
JP2001210685A (ja) 1999-11-19 2001-08-03 Hitachi Ltd テストシステムおよび半導体集積回路装置の製造方法
US6424926B1 (en) 2000-03-31 2002-07-23 Intel Corporation Bus signature analyzer and behavioral functional test method
KR100374328B1 (ko) * 2000-06-03 2003-03-03 박현숙 칩 설계 검증 및 테스트 장치 및 방법
JP2002156404A (ja) 2000-11-20 2002-05-31 Seiko Epson Corp 半導体測定方法及び半導体測定装置
JP2002311095A (ja) * 2001-04-12 2002-10-23 Tritec:Kk Ｌｓｉ検査装置
US6988232B2 (en) 2001-07-05 2006-01-17 Intellitech Corporation Method and apparatus for optimized parallel testing and access of electronic circuits
JP2003121499A (ja) * 2001-10-09 2003-04-23 Hitachi Ltd 組込みテスト機能付き半導体集積回路、テストコード生成プログラムから成る電子設計データを保存する記憶媒体、該半導体集積回路のテスト方法、テストコード生成自動化方法及びそのプログラム
WO2003096039A1 (en) * 2002-05-08 2003-11-20 Nptest, Inc. Tester system having a multi-purpose memory
JP2004030765A (ja) 2002-06-25 2004-01-29 Fujitsu Ltd 自己診断機能内蔵の半導体記憶装置
JP3614838B2 (ja) * 2002-09-19 2005-01-26 Ｎｅｃエレクトロニクス株式会社 半導体検査システム及び半導体デバイスの検査方法
US7131046B2 (en) * 2002-12-03 2006-10-31 Verigy Ipco System and method for testing circuitry using an externally generated signature
US7310752B2 (en) * 2003-09-12 2007-12-18 Micron Technology, Inc. System and method for on-board timing margin testing of memory modules
JP4602004B2 (ja) * 2004-06-22 2010-12-22 株式会社東芝 テストパターン作成装置、テストパターン作成方法及びテストパターン作成プログラム
US7627798B2 (en) 2004-10-08 2009-12-01 Kabushiki Kaisha Toshiba Systems and methods for circuit testing using LBIST
US7437517B2 (en) 2005-01-11 2008-10-14 International Business Machines Corporation Methods and arrangements to manage on-chip memory to reduce memory latency
US20070168809A1 (en) 2005-08-09 2007-07-19 Naoki Kiryu Systems and methods for LBIST testing using commonly controlled LBIST satellites
CN1925384A (zh) * 2005-09-02 2007-03-07 上海乐金广电电子有限公司 数字广播信息流传输错误检测装置及方法
US7562271B2 (en) 2005-09-26 2009-07-14 Rambus Inc. Memory system topologies including a buffer device and an integrated circuit memory device
US7389461B2 (en) * 2005-09-28 2008-06-17 Teradyne, Inc. Data capture in automatic test equipment
CN1987236A (zh) * 2005-12-22 2007-06-27 乐金电子(天津)电器有限公司 空调器的错误记录管理控制装置及其管理控制方法
US7552370B2 (en) 2006-03-31 2009-06-23 Robert Pochowski Application specific distributed test engine architecture system and method
ATE476741T1 (de) * 2006-04-06 2010-08-15 Advantest Corp Testvorrichtung und testverfahren
CN101512362A (zh) * 2006-07-10 2009-08-19 阿斯特瑞昂公司 自动测试设备的数字波形产生及测量
US7698088B2 (en) * 2006-11-15 2010-04-13 Silicon Image, Inc. Interface test circuitry and methods
US7486205B2 (en) * 2006-11-28 2009-02-03 Samplify Systems, Inc. Compression and decompression of stimulus and response waveforms in automated test systems
KR100897681B1 (ko) * 2007-04-05 2009-05-14 베리지 (싱가포르) 피티이. 엘티디. 테스트 프로그램 적응 시스템 및 자동화 테스트 시스템
US20090112548A1 (en) * 2007-10-30 2009-04-30 Conner George W A method for testing in a reconfigurable tester
US7717752B2 (en) 2008-07-01 2010-05-18 International Business Machines Corporation 276-pin buffered memory module with enhanced memory system interconnect and features
US20100023294A1 (en) * 2008-07-28 2010-01-28 Credence Systems Corporation Automated test system and method
US20100229058A1 (en) 2009-03-04 2010-09-09 Suresh Goyal Method and apparatus for system testing using scan chain decomposition
US8195419B2 (en) * 2009-03-13 2012-06-05 Teradyne, Inc. General purpose protocol engine
US8170828B2 (en) 2009-06-05 2012-05-01 Apple Inc. Test method using memory programmed with tests and protocol to communicate between device under test and tester
US8386867B2 (en) * 2009-07-02 2013-02-26 Silicon Image, Inc. Computer memory test structure
US8261119B2 (en) 2009-09-10 2012-09-04 Advantest Corporation Test apparatus for testing device has synchronization module which synchronizes analog test module to digital test module based on synchronization signal received from digital test module
US20110273197A1 (en) * 2010-05-07 2011-11-10 Qualcomm Incorporated Signal generator for a built-in self test
JP2011248597A (ja) 2010-05-26 2011-12-08 Yokogawa Electric Corp テスタシミュレーション装置、テスタシミュレーションプログラムおよびテスタシミュレーション方法
CN103038751B (zh) * 2010-05-28 2016-04-27 爱德万测试公司 具有可变并行性和固件可升级性的灵活存储接口测试器
US8598898B2 (en) 2010-10-05 2013-12-03 Silicon Image, Inc. Testing of high-speed input-output devices
US9043665B2 (en) * 2011-03-09 2015-05-26 Intel Corporation Functional fabric based test wrapper for circuit testing of IP blocks
US20120324302A1 (en) 2011-06-17 2012-12-20 Qualcomm Incorporated Integrated circuit for testing using a high-speed input/output interface
US9470759B2 (en) 2011-10-28 2016-10-18 Teradyne, Inc. Test instrument having a configurable interface
TW201337236A (zh) 2012-03-15 2013-09-16 Le & Der Co Ltd 流體自動化採樣控制裝置
US9606183B2 (en) * 2012-10-20 2017-03-28 Advantest Corporation Pseudo tester-per-site functionality on natively tester-per-pin automatic test equipment for semiconductor test
US9026869B1 (en) * 2012-11-01 2015-05-05 Amazon Technologies, Inc. Importance-based data storage verification
US9959186B2 (en) * 2012-11-19 2018-05-01 Teradyne, Inc. Debugging in a semiconductor device test environment
US9183952B2 (en) * 2013-02-20 2015-11-10 Micron Technology, Inc. Apparatuses and methods for compressing data received over multiple memory accesses
US10162007B2 (en) * 2013-02-21 2018-12-25 Advantest Corporation Test architecture having multiple FPGA based hardware accelerator blocks for testing multiple DUTs independently
US20140236527A1 (en) * 2013-02-21 2014-08-21 Advantest Corporation Cloud based infrastructure for supporting protocol reconfigurations in protocol independent device testing systems
US20140237292A1 (en) 2013-02-21 2014-08-21 Advantest Corporation Gui implementations on central controller computer system for supporting protocol independent device testing
US10161993B2 (en) * 2013-02-21 2018-12-25 Advantest Corporation Tester with acceleration on memory and acceleration for automatic pattern generation within a FPGA block
US11009550B2 (en) * 2013-02-21 2021-05-18 Advantest Corporation Test architecture with an FPGA based test board to simulate a DUT or end-point
US9952276B2 (en) * 2013-02-21 2018-04-24 Advantest Corporation Tester with mixed protocol engine in a FPGA block
US9810729B2 (en) 2013-02-28 2017-11-07 Advantest Corporation Tester with acceleration for packet building within a FPGA block
US9310427B2 (en) * 2013-07-24 2016-04-12 Advantest Corporation High speed tester communication interface between test slice and trays
US20150153405A1 (en) 2013-12-04 2015-06-04 Princeton Technology Corporation Automatic testing system and method
CN104808133B (zh) 2014-01-24 2018-02-06 矽创电子股份有限公司 自动测试设备和升级自动测试设备的集成电路测试界面
US9934831B2 (en) * 2014-04-07 2018-04-03 Micron Technology, Inc. Apparatuses and methods for storing and writing multiple parameter codes for memory operating parameters
US9811420B2 (en) * 2015-03-27 2017-11-07 Intel Corporation Extracting selective information from on-die dynamic random access memory (DRAM) error correction code (ECC)
JP6458626B2 (ja) 2015-05-07 2019-01-30 富士通株式会社 デバッグ回路、半導体装置及びデバッグ方法
KR102377362B1 (ko) * 2015-07-08 2022-03-23 삼성전자주식회사 보조 테스트 장치, 그것을 포함하는 테스트 보드 및 그것의 테스트 방법
JP6386434B2 (ja) 2015-10-08 2018-09-05 株式会社アドバンテスト 試験装置、試験信号供給装置、試験方法、およびプログラム
US10395748B2 (en) * 2016-06-15 2019-08-27 Micron Technology, Inc. Shared error detection and correction memory
JP2018006406A (ja) 2016-06-28 2018-01-11 東京エレクトロン株式会社 基板検査装置
JP6686769B2 (ja) * 2016-07-27 2020-04-22 富士通株式会社 テストパタン生成装置及びテストパタン生成方法
US11309056B2 (en) 2017-01-31 2022-04-19 Octavo Systems Llc Automatic test equipment method for testing system in a package devices
JP6878071B2 (ja) 2017-03-21 2021-05-26 株式会社東芝 半導体集積回路及び半導体集積回路の診断方法
US10580200B2 (en) 2017-04-07 2020-03-03 Intel Corporation Virtual reality apparatus and method including prioritized pixel shader operations, alternate eye rendering, and/or augmented timewarp
CN107390109B (zh) * 2017-06-09 2019-12-24 苏州迅芯微电子有限公司 高速adc芯片的自动测试平台及其软件架构设计方法

Also Published As

Publication number Publication date
KR102591340B1 (ko) 2023-10-20
JP7058759B2 (ja) 2022-04-22
WO2020152232A1 (en) 2020-07-30
WO2020152230A1 (en) 2020-07-30
WO2020152231A1 (en) 2020-07-30
TW202202865A (zh) 2022-01-16
US20210073094A1 (en) 2021-03-11
US11913990B2 (en) 2024-02-27
TW202202864A (zh) 2022-01-16
JP7101814B2 (ja) 2022-07-15
KR102604010B1 (ko) 2023-11-20
JP2021520570A (ja) 2021-08-19
JP2021520001A (ja) 2021-08-12
TW202132793A (zh) 2021-09-01
CN112703409B (zh) 2024-06-14
CN111989580B (zh) 2023-06-30
JP7295954B2 (ja) 2023-06-21
CN111989580A (zh) 2020-11-24
CN113330322A (zh) 2021-08-31
US20210025938A1 (en) 2021-01-28
US11415628B2 (en) 2022-08-16
JP2022517513A (ja) 2022-03-09
DE112020000035T5 (de) 2020-12-31
KR102569335B1 (ko) 2023-08-22
CN112703409A (zh) 2021-04-23
KR20210116604A (ko) 2021-09-27
US11385285B2 (en) 2022-07-12
US20210055347A1 (en) 2021-02-25
KR20210079347A (ko) 2021-06-29
DE112020000036T5 (de) 2021-01-21
KR20210079348A (ko) 2021-06-29

Similar Documents

Publication Publication Date Title
DE112020000469T5 (de) Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet
DE602004012714T2 (de) Verfahren und Struktur zum Entwickeln eines Prüfprogramms für Halbleiterschaltkreise
KR101414079B1 (ko) 네트워킹된 테스트 시스템
DE602004007498T2 (de) Testemulationseinrichtung
DE602005003225T2 (de) Verfahren und system zum simulieren eines modularen testsystems
DE10010043C2 (de) Halbleitervorrichtung-Simulationseinrichtung und zugehörige Halbleitertestprogramm-Debugging-Einrichtung
EP1720100B1 (de) Verfahren und Vorrichtung zur Emulation einer programmierbaren Einheit
DE602004011320T2 (de) Verfahren und struktur zur entwicklung eines testprogramms für integrierte halbleiterschaltungen
DE60208442T2 (de) Topologierekonfiguration einer prüfschaltung und verwendungsverfahren
DE102005025744A1 (de) Verfahren und Vorrichtung zum automatisierten Testaufbau
KR102024416B1 (ko) 반도체 테스트를 위한 본연적으로 핀당 테스터인 자동 테스트 장비 상의 의사 사이트당 테스터 기능
US20020163351A1 (en) Method for producing test patterns for testing an integrated circuit
CN103412817A (zh) 自动化测试脚本脱机调试方法及系统
DE10004198C2 (de) System und Verfahren für eine intelligente Analysesonde
JP2014532861A (ja) プログラム可能な試験機器
WO2004049159A2 (de) Einrichtung und verfahren zur analyse von eingebetteten systemen
DE112020007444T5 (de) 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
DE112019007610T5 (de) Eine automatische testausrüstung zum testen eines testobjekts, das eine verarbeitungseinheit und einen programm- und/oder datenspeicher aufweist, eine automatische testausrüstung, die eine teststeuerung, eine oder mehrere schnittstellen zu dem testobjekt und einen gemeinschaftlich verwendeten speicher aufweist, und ein verfahren zum testen eines testobjekts
EP1469320B1 (de) Verfahren zur Generierung von Testersteuerungen
DE102006040794A1 (de) Softwareprogramm mit alternativen Funktionsbibliotheken
CN106650006B (zh) 可编程逻辑器件的调试方法、系统及电子设计自动化终端
BE1029108B1 (de) System und verfahren zur prototypenverifikation für integrierten schaltkreis auf der grundlage von fpga
CN207946806U (zh) 一种调试器和调试装置
CN117407229A (zh) 一种同步网络验证方法、装置、计算机设备及存储介质
EP2977894B1 (de) Erstellen eines FPGA-Codes mit automatisch eingefügter Beeinflussungsstruktur

Legal Events

Date Code Title Description
R012 Request for examination validly filed