DE102020104840A1

DE102020104840A1 - Programmatisches generieren von software-test-bibliotheken für funktionale sicherheit

Info

Publication number: DE102020104840A1
Application number: DE102020104840.8A
Authority: DE
Inventors: Krishnan Anandh; Richard Bousquet; Vyasa Sai; Andrea Kroll; Mauro Pipponzi
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-03-29
Filing date: 2020-02-25
Publication date: 2020-10-01
Also published as: US20190227915A1; US10866885B2

Abstract

Verfahren, Systeme und Vorrichtungen können Technologien vorsehen, die einen Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator anwenden, eine Ausgabe des Hardwareebene-Simulators automatisch in eine Software-Test-Bibliothek (Software Test Library, STL) kompilieren und iterativ verifizieren, dass sich die Diagnosedeckung der STL-Datei der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.

Description

TECHNISCHES GEBIET
Ausführungsformen betreffen allgemein Funktionssicherheitstests. Insbesondere betreffen Ausführungsformen das programmatische Generieren von Software-Test-Bibliotheken für funktionale Sicherheit.
HINTERGRUND
Funktionale Sicherheit ist ein relevanter Bereich in autonomen Plattformen, da die Plattformen naturgemäß unbemannt sind, und aufgrund des potenziellen Risikos, das die Plattformen für Endbenutzer darstellen. Um eine funktionale Sicherheit zu gewährleisten, kann eine Software-Test-Bibliothek (Software Test Library, STL) verwendet werden, um das Vorliegen von Fehlern in einer Plattform beim Start und zur Laufzeit zu prüfen. Die Erstellung von STLs kann jedoch beinhalten, dass ein Computerprogrammierer die STL manuell schreibt. Tatsächlich kann der manuelle Prozess eine experimentelle Systemanalyse, Deckungstests und so weiter beinhalten. Dementsprechend können herkömmliche Lösungen für das Erstellen von STLs unter einem relativ hohen Overhead und mangelnder Eindeutigkeit leiden.
Figurenliste
Die verschiedenen Vorteile der Ausführungsformen werden für den Fachmann aus dem Studium der nachfolgenden Beschreibung und der beigefügten Ansprüche sowie anhand der nachfolgenden Zeichnungen ersichtlich, wobei gilt:

1 ist ein Blockschaltbild einer beispielhaften Computerarchitektur gemäß einer Ausführungsform;
2 ist ein Blockschaltbild einer beispielhaften Ausgabe, die unter Verwendung von Funktionssicherheitstests während einer Hardwarevalidierung gemäß einer Ausführungsform generiert wird.
3 ist ein Flussdiagramm eines beispielhaften Verfahrens zum programmatischen Identifizieren der Diagnosedeckung von STLs gemäß einer Ausführungsform;
4 ist ein Blockschaltbild eines beispielhaften Compilers und Optimierers gemäß einer Ausführungsform;
5 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Kompilieren der Ausgabe eines Hardwareebene-Simulators bei Funktionssicherheitstests für eine STL gemäß einer Ausführungsform;
6 ist ein Blockschaltbild eines beispielhaften Fehlersimulators gemäß einer Ausführungsform;
7 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Optimieren der Diagnosedeckung einer STL gemäß einer Ausführungsform;
8 ist ein Blockschaltbild eines beispielhaften Computersystems gemäß einer Ausführungsform; und
9 ist eine Darstellung einer beispielhaften Halbleitervorrichtung gemäß einer Ausführungsform.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
1 zeigt eine Computerarchitektur 10 mit geschlossenem Regelkreis, die für das programmatische Generieren einer STL-Bereitstellungsdatei 12 mit einer gezielten Diagnosedeckung verwendet werden kann. In dem dargestellten Beispiel wird ein Hardwaresystem von einem Hardwareebene-Simulator 14 emuliert (z. B. einem Verilog Logic Simulator, auf dem ein Registertransferebene (Register Transfer Level, RTL)- oder ein „IP-Block“-Ebene-Gattermodell des Hardwaresystems ausgeführt wird). Das Hardwaresystem könnte Teil einer autonomen Plattform (z. B. eines Fahrzeugs, eines Roboters oder einer Drohne) sein, bei der es Bedenken und/oder Anforderungen hinsichtlich der funktionalen Sicherheit gibt. In dem dargestellten Beispiel wird ein Funktionssicherheitstest-Stimulus 16 (z. B. eine Befehlsstromdatei, bei der es sich um einen existierenden Verifizierungstest-Stimulus mit hoher Diagnosedeckung handelt) für den Hardwareebene-Simulator 14 bereitgestellt, welcher eine Ausgabe 18 generiert. Wie an späterer Stelle noch ausführlicher beschrieben wird, kann die Ausgabe 18 des Hardwareebene-Simulators 14 eine Speicherverfolgungsdatei, eine Deckungsdatei (z. B. Code- und/oder Umschaltdeckung), eine erweiterte Wertänderungs-Speicherauszugsdatei (Enhanced Value Change Dump file, EVCD-Datei) und so weiter beinhalten.
In dem dargestellten Beispiel kompiliert ein Compiler 20 die Ausgabe 18 des Hardwareebene-Simulators 14 automatisch in eine STL-Zwischendatei 22. Im Allgemeinen optimiert der Compiler 20 die STL-Zwischendatei 22 adaptiv hinsichtlich Codedichte, Latenz und Diagnosedeckung. Die STL-Zwischendatei 22 und wenigstens ein Teil der Ausgabe 18 können an einen Fehlerinjektor 24 weitergeleitet werden, wobei der Fehlerinjektor 24 die Diagnosedeckung (Diagnostic Coverage, DC) der STL-Zwischendatei 22 bestimmt. In einer Ausführungsform wird eine angepasste Kostenfunktion für den Compiler 20 als Rekompilierungsfeedback 26 bereitgestellt, und der Compiler 20 rekompiliert die Ausgabe 18 des Hardwareebene-Simulators 14 basierend auf dem Feedback 26. Sobald die STL-Zwischendatei 22 die Diagnosedeckungsanforderungen erfüllt, wird die STL-Bereitstellungsdatei 12 ausgegeben und verwendet, um das Vorliegen von Fehlern (z. B. permanente Fehler wie etwa fehlerhafte Transistoren und/oder transiente Fehler, die aus Phänomenen wie etwa kosmischer Strahlung resultieren) in dem Hardwaresystem beim Start und zur Laufzeit (z. B. auf Intervallbasis) zu prüfen. Das automatische Generieren der STL-Bereitstellungsdatei 12 verbessert die Leistung durch Reduzierung des Overheads (z. B. experimentelle Systemanalyse und/oder Gleitkommatests) bei der Erstellung der STL-Datei 12 und durch Reduzierung des Overheads in der STL-Bereitstellungsdatei 12 bei einer bekannten Diagnosedeckung.
2 zeigt einen Hardwareebene-Simulator 30, der eine Befehlsstromdatei 35 empfängt (z. B. ein binäres Großobjekt/blob, das für einen Funktionssicherheitstest-Stimulus steht) und eine künstliche Arbeitslast 32 ausführt. Der Hardwareebene-Simulator 30, der leicht den Hardwareebene-Simulator 14 (1) ersetzen kann, emuliert ein Hardwaresystem, bei dem es Bedenken und/oder Anforderungen hinsichtlich der funktionalen Sicherheit gibt. In dem dargestellten Beispiel beinhaltet eine Ausgabe 34 (34a-34c) des Simulators 30 eine Speicherverfolgungsdatei 34b, eine Deckungsdatei 34c (z. B. Code-/Umschaltdeckung) und eine EVCD-Datei 34d. In einer Ausführungsform ist die Befehlsstromdatei 34a eine Aub-Datei, gibt die Deckungsdatei 34c die Diagnosedeckung der künstlichen Arbeitslast 32 an und beinhaltet die EVCD-Datei 34d Signalstärke- und Direktionalitätsdaten.
3 zeigt ein Verfahren 40 zum programmatischen Generieren von STLs. Das Verfahren 40 kann allgemein in einer Computerarchitektur wie etwa beispielsweise der bereits besprochenen Architektur 10 (1) implementiert sein. Spezieller kann das Verfahren 40 als ein oder mehrere Module in einem Satz von Logikbefehlen implementiert sein, der auf einem nicht-transitorischen maschinen- oder computerlesbaren Datenspeichermedium gespeichert ist, wie etwa einem Direktzugriffsspeicher (Random Access Memory, RAM), Festwertspeicher (Read-Only Memory, ROM), programmierbaren ROM (PROM), Firmware, einem Flash-Speicher usw., in konfigurierbarer Logik, wie zum Beispiel programmierbaren logischen Anordnungen (Programmable Logic Arrays, PLAs), feldprogrammierbaren Gatteranordnungen (Field Programmable Gate Arrays, FPGAs), komplexen programmierbaren Logikbausteinen (Complex Programmable Logic Devices, CPLDs), in Hardwarelogik mit fester Funktionalität unter Verwendung von Schaltungstechnologie wie zum Beispiel anwendungsspezifischen integrierten Schaltungen (Application-Specific Integrated Circuits, ASICs), komplementärer Metalloxid-Halbleiter- (Complementary Metal Oxide Semiconductor, CMOS) oder Transistor-Transistor-Logik- (TTL) Technologie, oder einer beliebigen Kombination davon.
Beispielsweise kann ein Computerprogrammcode zum Ausführen von Operationen, die in Verfahren 40 gezeigt werden, in jeder beliebigen Kombination von einer oder mehreren Programmiersprache(n), einschließlich einer objektbezogenen Programmiersprache wie JAVA, SMALLTALK, C++ oder desgleichen sowie herkömmlichen prozeduralen Programmiersprachen wie die Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben sein. Zusätzlich könnten Logikbefehle Assemblerbefehle, Befehlssatzarchitektur (Instruction Set Architecture, ISA)-Befehle, Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen, Statusinformationen, die elektronische Schaltungen personalisieren und/oder andere Strukturbauteile, die der Hardware eigen sind (z. B. Host-Prozessor, zentrale Verarbeitungseinheit (Central Processing Unit, CPU), Mikrocontroller etc.) beinhalten.
Der dargestellte Verarbeitungsblock 42 sieht das Anwenden eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator vor, wobei eine Ausgabe des Hardwareebene-Simulators bei Block 44 in eine STL-Datei kompiliert wird. Block 46 verifiziert, dass sich eine Diagnosedeckung der STL-Datei der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert (z. B. diese umfasst, größer oder gleich ist, damit übereinstimmt und/oder diese spiegelt). Das dargestellte Verfahren 40 verbessert die Leistung durch Reduzieren des Overheads bei der Erstellung der STL-Datei und Reduzieren des Overheads in der STL-Datei selbst.
4 zeigt einen Compiler 50, der leicht den bereits besprochenen Compiler 20 (1) ersetzen kann. In dem dargestellten Beispiel empfängt ein Parser 54 eine Befehlsstromdatei 52 (z. B. ein blob von einem Hardwareebene-Simulator) und extrahiert einen Opcode-Strom aus der Befehlsstromdatei. In einer Ausführungsform generiert der Parser 54 einen abstrakten Syntaxbaum (Abstract Syntax Tree, AST), um den Opcode-Strom zu extrahieren. Ein Disassembler 56 kann den Opcode-Strom von dem Parser 54 empfangen und die Bits des Opcode-Stroms in Assemblercode übersetzen. Zusätzlich generiert ein Datenflussanalysator 58 einen oder mehrere Flussgraphen (z. B. Steuerflussgraphen und/oder Datenflussgraphen) basierend auf dem Assemblercode. Im Allgemeinen rekonstruiert der bzw. rekonstruieren die Flussgraph(en) Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus, der in den Hardwareebene-Simulator eingegeben wurde. Insbesondere kann der optimierte AST in eine Zwischendarstellung (Intermediate Representation, IR) konvertiert werden. In einem solchen Fall werden mehrere Optimierungsdurchläufe in der IR durchgeführt, was eine Kopierausbreitung, eine Eliminierung von totem Code und lokale, globale und interprozedurale Optimierungen unter Verwendung von Steuerflussgraphen (Control Flow Graphs, CFGs) beinhaltet. In einer Ausführungsform verwendet der Datenflussanalysator 58 eine multivariate Kostenfunktion, um die DC zu optimieren und gleichzeitig die Zykluszahl zu minimieren und die IR-Optimierungen des Compilers 50 zu führen.
Wie bereits angemerkt, kann die Ausgabe des Hardwareebene-Simulators auch eine Speicherverfolgungsdatei 60 beinhalten. Dementsprechend umfasst der dargestellte Compiler 50 auch einen Speicherzuordner 62, der Zeigerwerte zuweist und eine relative Adressierung durchführt (z. B. mit Indexregister-Versätzen), basierend auf der Speicherverfolgungsdatei 60. Zusätzlich kann ein Codegenerator 64 STL-Code 66 basierend auf dem bzw. den Flussgraphen von dem Datenflussanalysator 58 und der Ausgabe des Speicherzuordners 62 generieren.
5 zeigt ein Verfahren 70 zum Kompilieren der Ausgabe eines Hardwareebene-Simulators in eine STL-Datei. Das Verfahren 70, welches sich leicht in den bereits besprochenen Block 44 (3) integrieren lässt, kann von einem Compiler, beispielsweise dem Compiler 20 (1) und/oder dem Compiler 50 (4), automatisch durchgeführt werden. Darüber hinaus kann das Verfahren 70 in einem oder mehreren Modulen als Satz von Logikbefehlen implementiert sein, die in einem maschinen- oder computerlesbaren Datenspeichermedium wie etwa RAM, ROM, PROM, Firmware, Flash-Speicher, etc. gespeichert sind, in konfigurierbarer Logik wie beispielsweise PLAs, FPGAs, CPLDs, in Hardwarelogik mit fester Funktionalität unter Verwendung von Schaltungstechnologien wie beispielsweise der ASIC-, CMOS-, TTL-Technologie oder einer beliebigen Kombination davon.
Der dargestellte Verarbeitungsblock 72 sieht das Extrahieren eines Opcode-Stroms aus einer Befehlsstromdatei vor. In einer Ausführungsform beinhaltet Block 72 das Generieren eines AST. In einem Beispiel wird der Opcode-Strom bei Block 74 in Assemblercode übersetzt. Ein oder mehrere Flussgraphen werden bei Block 76 basierend auf dem Assemblercode generiert, wobei der bzw. die Flussgraph(en) Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren. Zusätzlich kann die STL-Datei bei Block 78 basierend auf dem bzw. den Flussgraph(en) und einer Speicherverfolgungsdatei generiert werden.
Es wird nun Bezug genommen auf 6; gezeigt wird ein Fehlersimulator 80, in dem ein eigenständiger Prüfstand 82 einen EVCD-Stimulus 84 auf eine Grafiknetzliste 86 anwendet, welche die Konnektivität des Hardwaresystems beschreibt. Der Prüfstand 82 kann auch die STL-Datei als ein oder mehrere Fehler 88 in die stimulierte Grafiknetzliste 86 injizieren, was es ermöglicht, die Diagnosedeckung der STL-Datei zu messen und/oder zu bestimmen.
7 zeigt ein Verfahren 90 zum Verifizieren der Diagnosedeckung einer STL-Datei. Das Verfahren 90, welches sich leicht in den bereits besprochenen Block 46 (3) integrieren lässt, kann von einer Computerarchitektur, beispielsweise der bereits besprochenen Architektur 10 (1), automatisch durchgeführt werden. Darüber hinaus kann das Verfahren 90 in einem oder mehreren Modulen als Satz von Logikbefehlen implementiert sein, die in einem maschinen- oder computerlesbaren Datenspeichermedium wie etwa RAM, ROM, PROM, Firmware, Flash-Speicher, etc. gespeichert sind, in konfigurierbarer Logik wie beispielsweise PLAs, FPGAs, CPLDs, in Hardwarelogik mit fester Funktionalität unter Verwendung von Schaltungstechnologien wie beispielsweise der ASIC-, CMOS-, TTL-Technologie oder einer beliebigen Kombination davon.
Der dargestellte Verarbeitungsblock 92 wendet eine erweiterte Wertänderungs-Speicherauszugsdatei und die STL-Datei auf einen Fehlersimulator an, wobei die Ausgabe des Fehlersimulators bei Block 94 mit einer Deckungsdatei verglichen wird. Wie bereits angemerkt, kann die Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angeben. Zusätzlich kann die Deckungsdatei die Diagnosedeckung des Funktionssicherheitstest-Stimulus angeben. Dementsprechend kann bei Block 96 bestimmt werden, ob sich die Diagnosedeckung der STL-Datei der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert. Block 96 kann beispielsweise das Bestimmen beinhalten, ob bestimmte Gatter, Blöcke, Schaltungen und/oder Teile des Hardwaresystems beim Start und/oder zur Laufzeit in ähnlicher Weise durch die STL-Datei und den Funktionssicherheitstest-Stimulus auf Fehler (z. B. permanente und/oder transiente Fehler) getestet werden. Falls die Fehlersimulator-Ausgabe nicht die erforderliche Diagnosedeckung erreicht oder überschreitet, passt Block 98 eine Kostenfunktion des Compilers in einem adaptiven Prozess an, damit die erforderliche Diagnosedeckung erreicht wird.
In einer Ausführungsform weist die Kostenfunktion des Compilers drei Komponenten auf: a) Codedichtekosten (z. B. eine quantitative Messung des STL-Codes, der von dem AUB->STL-Compiler generiert wird); b) Latenzkosten (z. B. die Menge von Taktzyklen, die benötigt wird, um den STL-Code auszuführen); und c) Diagnosedeckungsmessung. Während anfänglicher Iterationen der adaptiven Schleife können die Gewichtungen für Komponente a) und Komponente b) über die Gewichtung von Komponente c) dominieren. Bis die gewünschte Diagnosedeckung erzielt ist, wird der iterative Prozess wiederholt. Bei jeder Iteration kann die Gewichtung für Komponente c) wie folgt aktualisiert werden: $\begin{array}{l} Gewichtung (Iterationszahl i + 1) = alpha* \\ Gewichtung (Iterationszahl i) \end{array}$
Hierbei ist alpha eine reale Zahl größer 1,0, die basierend auf einem Zeitplan aktualisiert wird, der mit der Anzahl von Iterationen zunimmt. Mit zunehmendem Iterationsfortschritt kann ein einfacher geometrischer Zeitplan für das Aktualisieren von alpha gewählt werden.
In einer Ausführungsform beinhaltet Block 98 daher das Initiieren und/oder Wiederholen des bereits besprochenen Verfahrens 70 (5) mit der angepassten Kostenfunktion als Eingabe. Infolgedessen wird der Compiler iterativ geführt, um eine bessere Diagnosedeckung zu erzeugen. Falls bei Block 96 bestimmt wird, dass sich die Ausgabe des Fehlersimulators der Deckungsdatei annähert, wird das dargestellt Verfahren 90 beendet.
8 zeigt ein Computersystem 150, das allgemein Teil eines Elektronikgeräts/eines elektronischen Systems sein kann, das Rechenfunktionalität (z. B. persönlicher digitaler Assistent/PDA, Notebook-Computer, Tablet-Computer, konvertierbares Tablet, Server), Kommunikationsfunktionalität (z. B., Smartphone), Bildgebungsfunktionalität (z. B. Kamera, Camcorder), Medienwiedergabefunktionalität (z. B. Smart-TV), Tragbarkeitsfunktionalität (z. B. Uhr, Brille, Kopfbekleidung, Fußbekleidung, Schmuck), Fahrzeugfunktionalität (z. B. Auto, Motorrad), Roboterfunktionalität (z. B. autonomer Roboter) etc. oder eine beliebige Kombination davon aufweist. In dem dargestellten Beispiel beinhaltet das System 150 einen Grafikprozessor 152 (z. B. eine Grafikverarbeitungseinheit (Graphics Processing Unit, GPU) und einen Host-Prozessor 154 (z. B. eine zentrale Verarbeitungseinheit (Central Processing Unit, CPU)) mit einem integrierten Speichercontroller (Integrated Memory Controller, IMC) 158, der mit einem Systemspeicher 160 gekoppelt ist.
Zusätzlich beinhaltet das dargestellte System 150 ein Eingabe/Ausgabe (E/A)-Modul 162, das zusammen mit dem Host-Prozessor 154 und dem Grafikprozessor 152 auf einem SoC 164 (z. B. einem Halbleiterplättchen) implementiert ist. In einem Beispiel kommuniziert das E/A-Modul 162 mit einer Anzeige 166 (z. B. Berührungsschirm, Flüssigkristallanzeige (Liquid Crystal Display, LCD), Leuchtdioden (Light Emitting Diode, LED)-Anzeige, einem (z. B. drahtgebundenen und/oder drahtlosen) Netzwerk-Controller 168 und einem Massendatenspeicher 170 (z. B. Festplattenlaufwerk (Hard Disk Drive, HDD), optische Platte, Festkörperlaufwerk (Solid State Drive, SSD), Flash-Speicher).
Der dargestellte Host-Prozessor 154 umfasst einen Hardwareebene-Simulator 175 und Logik 174 (z. B. Logikbefehle, konfigurierbare Logik, Hardwarelogik mit fester Funktionalität etc. oder eine beliebige Kombination davon), um einen oder mehrere Aspekte des Verfahrens 40 (3), des Verfahrens 70 (5) und/oder des Verfahrens 90 (7), die bereits besprochen wurden, durchzuführen. Die Logik 174 kann auch den Compiler 20 (1) und den Fehlerinjektor 24 (1) der Architektur 10 mit geschlossenem Regelkreis (1) ersetzen, die bereits besprochen wurden. Somit kann die Logik 174 einen Funktionssicherheitstest-Stimulus auf den Hardwareebene-Simulator 175 anwenden, eine Ausgabe des Hardwareebene-Simulators 175 in eine STL-Datei kompilieren und verifizieren, dass sich eine Diagnosedeckung der STL-Datei der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert. Die Ausgabe des Hardwareebene-Simulators 175 kann eine Befehlsstromdatei beinhalten.
In einer Ausführungsform beinhaltet die Ausgabe des Hardwareebene-Simulators 175 eine EVCD-Datei und eine Deckungsdatei, wobei das Verifizieren der Diagnosedeckung der STL-Datei das Anwenden der EVCD-Datei auf einen Fehlerinjektor und das Vergleichen einer Ausgabe des Fehlerinjektors mit der Deckungsdatei beinhaltet. In einem solchen Fall rekompiliert der Compiler die Ausgabe des Hardwareebene-Simulators mit einer angepassten Kostenfunktion, falls sich die Ausgabe des Fehlersimulators nicht der Deckungsdatei annähert. Das dargestellte System 150 zeigt daher eine verbesserte Leistung durch Reduzieren des Overheads bei der Erstellung der STL-Datei und eine Reduzierung des Overheads in der STL-Datei bei einer bekannten Diagnosedeckung. Auch wenn die Logik 174 in dem Host-Prozessor 154 gezeigt wird, kann sich die Logik 174 auch an einer anderen Stelle im System 150 befinden.
9 zeigt eine Halbleitervorrichtung 180 (z. B. einen Chip, ein Halbleiterplättchen, ein Gehäuse). Die dargestellte Vorrichtung 180 weist ein oder mehrere Substrate 182 (z. B. Silizium, Saphir, Gallium-Arsenid) und Logik 184 (z. B. eine Transistoranordnung oder andere integrierte Schaltung/IC-Komponenten) auf, die mit dem/den Substrat(en) 182 gekoppelt sind. In einer Ausführungsform implementiert die Logik 184 einen oder mehrere Aspekte des Verfahrens 40 (3), des Verfahrens 70 (5) und/oder des Verfahrens 90 (7), die bereits besprochen wurden. Somit kann die Logik 184 einen Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator anwenden, eine Ausgabe des Hardwareebene-Simulators in eine STL-Datei kompilieren und verifizieren, dass sich eine Diagnosedeckung der STL-Datei der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Die Logik 184 kann wenigstens teilweise in konfigurierbarer Logik oder Hardwarelogik mit fester Funktionalität implementiert sein. In einem Beispiel weist die Logik 184 Transistorkanalregionen auf, die innerhalb des/der Substrate(s) 182 angeordnet (z. B. eingebettet) sind. Somit stellt die Schnittstelle zwischen der Logik 184 und dem/den Substrat(en) 182 unter Umständen keinen abrupten Übergang dar. Die Logik 184 kann auch betrachtet werden als eine Epitaxieschicht aufweisend, die auf einem anfänglichen Wafer des/der Substrate(s) 182 aufgewachsen ist.
Zusätzliche Anmerkungen und Beispiele:
Beispiel 1 beinhaltet ein leistungsverbessertes Computersystem, umfassend einen Netzwerk-Controller, einen Prozessor, der mit dem Netzwerk-Controller gekoppelt ist, und einen Speicher, der mit dem Prozessor gekoppelt ist, wobei der Speicher Befehle beinhaltet, die, wenn sie von dem Prozessor ausgeführt werden, das Computersystem veranlassen, einen Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator anzuwenden, der für ein leistungsverbessertes Computersystem steht, eine Ausgabe des Hardwareebene-Simulators in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei zu kompilieren und eine Diagnosedeckung der STL-Datei zu verifizieren.
Beispiel 2 beinhaltet das Computersystem aus Beispiel 1, wobei die Ausgabe des Hardwareebene-Simulators eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, einen Opcode-Strom aus der Befehlsstromdatei zu extrahieren, den Opcode-Strom in Assemblercode zu übersetzen und einen oder mehrere Flussgraphen basierend auf dem Assemblercode zu generieren, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Beispiel 3 beinhaltet das Computersystem aus Beispiel 2, wobei die Ausgabe des Hardwareebene-Simulators ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Befehle, wenn sie ausgeführt werden, ferner das Computersystem veranlassen, die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei zu generieren.
Beispiel 4 beinhaltet das Computersystem aus Beispiel 2, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Beispiel 5 beinhaltet das Computersystem aus einem der Beispiele 1 bis 4, wobei die Ausgabe des Hardwareebene-Simulators eine erweiterte Wertänderungs-Speicherauszugsdatei beinhalten soll, und eine Deckungsdatei, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, die erweiterte Wertänderungs-Speicherauszugsdatei und die STL-Datei auf einen Fehlersimulator anzuwenden, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und die Ausgabe des Fehlersimulators mit der Deckungsdatei zu vergleichen.
Beispiel 6 beinhaltet das Computersystem aus Beispiel 5, wobei die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, die Ausgabe des Hardwareebene-Simulators mit einer angepassten Kostenfunktion zu rekompilieren, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 7 beinhaltet eine Halbleitervorrichtung, umfassend ein oder mehrere Substrate und Logik, die mit den ein oder mehreren Subtraten gekoppelt ist, wobei die Logik wenigstens teilweise in einem oder mehreren von konfigurierbarer Logik oder Hardwarelogik mit fester Funktionalität implementiert ist, wobei die mit den ein oder mehreren Substraten gekoppelte einen Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator anwenden soll, eine Ausgabe des Hardwareebene-Simulator in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei kompilieren soll und verifizieren soll, dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 8 beinhaltet die Halbleitervorrichtung aus Beispiel 7, wobei die Ausgabe des Hardwareebene-Simulators eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Logik einen Opcode-Strom aus der Befehlsstromdatei extrahieren soll, den Opcode-Strom in Assemblercode übersetzen soll und einen oder mehrere Flussgraphen basierend auf dem Assemblercode generieren soll, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Beispiel 9 beinhaltet die Halbleitervorrichtung aus Beispiel 8, wobei die Ausgabe des Hardwareebene-Simulators ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Logik die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei generieren soll.
Beispiel 10 beinhaltet die Halbleitervorrichtung aus Beispiel 8, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Beispiel 11 beinhaltet die Halbleitervorrichtung aus einem der Beispiele 7 bis 10, wobei die Ausgabe des Hardwareebene-Simulators eine erweiterte Wertänderungs-Speicherauszugsdatei beinhalten soll, und eine Deckungsdatei, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Logik die erweiterte Wertänderungs-Speicherauszugsdatei und die STL-Datei auf einen Fehlersimulator anwenden soll, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und die Ausgabe des Fehlersimulators mit der Deckungsdatei vergleichen soll.
Beispiel 12 beinhaltet die Halbleitervorrichtung aus Beispiel 11, wobei die Logik die Ausgabe des Hardwareebene-Simulators mit einer angepassten Kostenfunktion rekompilieren soll, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 13 beinhaltet wenigstens ein computerlesbares Datenspeichermedium, das einen Satz von Befehlen umfasst, die, wenn sie von einem Computersystem ausgeführt werden, das Computersystem veranlassen, einen Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator anzuwenden, eine Ausgabe des Hardwareebene-Simulators in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei zu kompilieren und zu verifizieren, dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 14 beinhaltet das wenigstens eine computerlesbare Datenspeichermedium aus Beispiel 13, wobei die Ausgabe des Hardwareebene-Simulators eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, einen Opcode-Strom aus der Befehlsstromdatei zu extrahieren, den Opcode-Strom in Assemblercode zu übersetzen und einen oder mehrere Flussgraphen basierend auf dem Assemblercode zu generieren, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Beispiel 15 beinhaltet das wenigstens eine computerlesbare Datenspeichermedium aus Beispiel 14, wobei die Ausgabe des Hardwareebene-Simulators ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators zu kompilieren, die Befehle, wenn sie ausgeführt werden, ferner das Computersystem veranlassen, die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei zu generieren.
Beispiel 16 beinhaltet das wenigstens eine computerlesbare Datenspeichermedium aus Beispiel 14, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Beispiel 17 beinhaltet das das wenigstens eine computerlesbare Datenspeichermedium aus einem der Beispiele 13 bis 16, wobei die Ausgabe des Hardwareebene-Simulators eine erweiterte Wertänderungs-Speicherauszugsdatei beinhalten soll, und eine Deckungsdatei, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, die erweiterte Wertänderungs-Speicherauszugsdatei und die STL-Datei auf einen Fehlersimulator anzuwenden, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und die Ausgabe des Fehlersimulators mit der Deckungsdatei zu vergleichen.
Beispiel 18 beinhaltet das wenigstens eine computerlesbare Datenspeichermedium aus Beispiel 17, wobei die Befehle, wenn sie ausgeführt werden, das Computersystem veranlassen, die Ausgabe des Hardwareebene-Simulators mit einer angepassten Kostenfunktion zu rekompilieren, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 19 beinhaltet ein Verfahren umfassend das Anwenden eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator, das Kompilieren einer Ausgabe des Hardwareebene-Simulators in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei und das Verifizieren, dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 20 beinhaltet das Verfahren aus Beispiel 19, wobei die Ausgabe des Hardwareebene-Simulators eine Befehlsstromdatei beinhaltet und wobei das Kompilieren der Ausgabe des Hardwareebene-Simulators das Extrahieren eines Opcode-Stroms aus der Befehlsstromdatei, das Übersetzen des Opcode-Stroms in Assemblercode und das Generieren eines oder mehrerer Flussgraphen basierend auf dem Assemblercode beinhaltet, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequenziellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Beispiel 21 beinhaltet das Verfahren aus Beispiel 20, wobei die Ausgabe des Hardwareebene-Simulators ferner eine Speicherverfolgungsdatei beinhaltet und wobei das Kompilieren der Ausgabe des Hardwareebene-Simulators ferner das Generieren der STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei beinhaltet.
Beispiel 22 beinhaltet das Verfahren aus Beispiel 20, wobei das Extrahieren des Opcode-Stroms aus der Befehlsstromdatei das Generieren eines abstrakten Syntaxbaums basierend auf der Befehlsstromdatei beinhaltet.
Beispiel 23 beinhaltet das Verfahren aus einem der Beispiele 19 bis 22, wobei die Ausgabe des Hardwareebene-Simulators eine erweiterte Wertänderungs-Speicherauszugsdatei beinhaltet, und eine Deckungsdatei, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei das Verifizieren der Diagnosedeckung der STL-Datei das Anwenden der erweiterten Wertänderungs-Speicherauszugsdatei und der STL-Datei auf einen Fehlersimulator, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und das Vergleichen der Ausgabe des Fehlersimulators mit der Deckungsdatei beinhaltet.
Beispiel 24 beinhaltet das Verfahren aus Beispiel 23, ferner beinhaltend das Rekompilieren der Ausgabe des Hardwareebene-Simulators mit einer angepassten Kostenfunktion, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Beispiel 25 beinhaltet Mittel zum Durchführen des Verfahrens aus einem der Beispiele 19 bis 24.
Die hier beschriebene Technologie reduziert daher deutlich den STL-Entwicklungsaufwand und Overhead für generierte STLs. Zusätzlich verfügt die generierte STL über eine gemessene Hardwaredeckung, die auf der eingesetzten Plattform lauffähig ist. Die Bibliotheken haben einen hohen Wert, insbesondere wenn sie über bekannte Werte für eine mit ihnen verknüpfte Gatterdeckung verfügen.
Ausführungsformen sind für eine Verwendung mit allen Arten von Halbleiterchips für integrierte Schaltkreise (Integrated Circuits, ICs) anwendbar. Beispiele für diese IC-Chips beinhalten unter anderem, sind aber nicht beschränkt auf, Prozessoren, Controller, Chipsatzkomponenten, programmierbare logische Anordnungen (Programmable Logic Arrays, PLAs), Speicherchips, Netzwerkchips, Ein-Chip-Systeme (Systems-on-Chip, SoCs), SSD-/NAND-Controller-ASICs (Application-Specific Integrated Circuits, anwendungsspezifische integrierte Schaltungen) und dergleichen. Darüber hinaus werden in einigen Zeichnungen Signalleiterbahnen durch Linien dargestellt. Einige können unterschiedlich sein, um mehrere einzelne Signalwege anzugeben, eine numerische Kennzeichnung aufweisen, um eine Anzahl von einzelnen Signalwegen anzugeben, und/oder an einem oder mehreren Enden Pfeile aufweisen, um die Hauptrichtung des Informationsflusses anzuzeigen. Dies sollte jedoch nicht in einschränkender Weise ausgelegt werden. Vielmehr kann ein solches zusätzliches Detail im Zusammenhang mit einer oder mehreren beispielhaften Ausführungsformen genutzt werden, um eine Schaltung verständlicher zu machen. Alle dargestellten Signalleitungen, sei es mit oder ohne zusätzliche Informationen, können tatsächlich ein oder mehrere Signale umfassen, die sich in mehrere Richtungen ausbreiten, und können mit jeder geeigneten Art von Signalschema, z. B. digitale oder analoge Leitungen, die mit Differentialpaaren, Glasfaserleitungen und/oder Leitungen mit einseitigem Anschluss implementiert sind, implementiert werden.
Beispiele für Größen/Modelle/Werte/Bereiche können angeführt worden sein, obwohl die Ausführungsformen nicht auf diese beschränkt sind. Da die Herstellungstechniken (z. B. Fotolithografie) mit der Zeit immer ausgereifter werden, ist zu erwarten, dass Bauelemente mit geringerer Größe hergestellt werden könnten. Außerdem können ausreichend bekannte Strom-/Erdungsverbindungen mit IC-Chips und anderen Komponenten der Einfachheit der Darstellung und Erörterung halber, sowie um die Verständlichkeit bestimmter Aspekte der Ausführungsformen nicht zu beeinträchtigen, in den Figuren gezeigt oder nicht gezeigt werden. Ferner können Anordnungen in Form von Blockschaltbildern gezeigt werden, um zu vermeiden, dass die Verständlichkeit von Ausführungsformen beeinträchtigt wird, und auch im Hinblick auf die Tatsache, dass spezifische Merkmale in Bezug auf die Implementierung solcher Anordnungen von Blockschaltbildern in hohem Maße von der Plattform abhängig sind, auf der die Ausführungsform implementiert werden soll, d. h. solche spezifischen Merkmale sollten innerhalb des Kenntnisbereichs eines Fachmanns auf diesem Gebiet liegen. Dort, wo spezielle Einzelheiten (z. B. Schaltungen) dargelegt werden, um beispielhafte Ausführungsformen zu beschreiben, sollte für den Fachmann offenkundig sein, dass Ausführungsformen ohne diese oder mit Abänderungen dieser speziellen Einzelheiten realisiert werden können. Somit ist die Beschreibung als veranschaulichend und nicht als einschränkend zu verstehen.
Der Begriff „gekoppelt“ wird hier unter Umständen verwendet, um auf jede Art von direkter oder indirekter Beziehung zwischen den betreffenden Komponenten Bezug zu nehmen, und kann auf elektrische, mechanische, fluide, optische, elektromagnetische, elektromechanische oder andere Verbindungen zutreffen. Weiterhin werden die Begriffe „erster/es/e“, „zweiter/es/e“ usw. hier nur verwendet, um eine Erörterung zu erleichtern, und haben keine besondere zeitliche oder chronologische Bedeutung, soweit nicht anders angegeben.
Wie in dieser Anmeldung und in den Ansprüchen verwendet, kann eine Liste von Positionen mit dem Ausdruck „ein/eine/eines oder mehrere von“ jede Kombination der aufgeführten Ausdrücke bedeuten. Beispielsweise können die Formulierung „ein oder mehrere von A, B und C“ und die Formulierung „ein oder mehrere von A, B oder C“ beide A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
Fachleute auf diesem Gebiet werden aus der vorstehenden Beschreibung erkennen, dass die umfassenden Techniken der Ausführungsformen in vielfältigen Formen implementiert werden können. Daher soll, obwohl die Ausführungsformen in Verbindung mit bestimmten Beispielen derselben beschrieben wurden, der tatsächliche Schutzumfang der Ausführungsformen nicht auf diese beschränkt sein, da für den Fachmann nach dem Studium der Zeichnungen, der Beschreibung und der nachfolgenden Ansprüche weitere Modifikationen offenkundig sein werden.

Claims

Computersystem (150), umfassend: einen Netzwerk-Controller (168); einen Prozessor (154), der mit dem Netzwerk-Controller (168) gekoppelt ist; und einen Speicher (160), der mit dem Prozessor (154) gekoppelt ist, wobei der Speicher (160) Befehle beinhaltet, die, wenn sie von dem Prozessor (154) ausgeführt werden, das Computersystem (150) hierzu veranlassen: Anwenden (42) eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator (175), Kompilieren (44) einer Ausgabe des Hardwareebene-Simulators in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei, und Verifizieren (46), dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Computersystem (150) nach Anspruch 1, wobei die Ausgabe des Hardwareebene-Simulators (175) eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) hierzu veranlassen: Extrahieren (72) eines Opcode-Stroms aus der Befehlsstromdatei, Übersetzen (74) des Opcode-Stroms in Assemblercode und Generieren (76) eines oder mehrerer Flussgraphen basierend auf dem Assemblercode, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequentiellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Computersystem (150) nach Anspruch 2, wobei die Ausgabe des Hardwareebene-Simulators (175) ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Befehle, wenn sie ausgeführt werden, ferner das Computersystem (150) veranlassen, die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei zu generieren.
Computersystem (150) nach einem der Ansprüche 2 oder 3, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Computersystem (150) nach einem der Ansprüche 1-4, wobei die Ausgabe des Hardwareebene-Simulators (175) eine erweiterte Wertänderungs-Speicherauszugsdatei und eine Deckungsdatei beinhalten soll, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) hierzu veranlassen: Anwenden der erweiterten Wertänderungs-Speicherauszugsdatei und der STL-Datei auf einen Fehlersimulator, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und Vergleichen der Ausgabe des Fehlersimulators mit der Deckungsdatei.
Computersystem (150) nach Anspruch 5, wobei die Befehle, wenn sie ausgeführt werden, das Computersystem (150) veranlassen, die Ausgabe des Hardwareebene-Simulators (175) mit einer angepassten Kostenfunktion zu rekompilieren, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Halbleitervorrichtung (180), umfassend: ein oder mehrere Substrate (182); und Logik (184), die mit den ein oder mehreren Substraten (182) gekoppelt ist, wobei die Logik (184) wenigstens teilweise in einem oder mehreren von konfigurierbarer Logik oder Hardwarelogik mit fester Funktionalität implementiert ist, wobei die Logik (184), die mit den ein oder mehreren Substraten (182) gekoppelt ist, dies soll: Anwenden (42) eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator (175), Kompilieren (44) einer Ausgabe des Hardwareebene-Simulators (175) in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei und Verifizieren (46), dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Halbleitervorrichtung (180) nach Anspruch 7, wobei die Ausgabe des Hardwareebene-Simulators (175) eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Logik dies soll: Extrahieren (72) eines Opcode-Stroms aus der Befehlsstromdatei, Übersetzen (74) des Opcode-Stroms in Assemblercode und Generieren (76) eines oder mehrerer Flussgraphen basierend auf dem Assemblercode, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequentiellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Halbleitervorrichtung (180) nach Anspruch 8, wobei die Ausgabe des Hardwareebene-Simulators (175) ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Logik (184) die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei generieren soll.
Halbleitervorrichtung (180) nach einem der Ansprüche 8 oder 9, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren (72), die Befehle, wenn sie ausgeführt werden, das Computersystem (150) veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Halbleitervorrichtung (180) nach einem der Ansprüche 7-10, wobei die Ausgabe des Hardwareebene-Simulators (175) eine erweiterte Wertänderungs-Speicherauszugsdatei und eine Deckungsdatei beinhalten soll, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Logik dies soll: Anwenden der erweiterten Wertänderungs-Speicherauszugsdatei und der STL-Datei auf einen Fehlersimulator, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt, und Vergleichen der Ausgabe des Fehlersimulators mit der Deckungsdatei.
Halbleitervorrichtung (180) nach Anspruch 11, wobei die Logik (184) die Ausgabe des Hardwareebene-Simulators (175) mit einer angepassten Kostenfunktion rekompilieren soll, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Wenigstens ein computerlesbares Datenspeichermedium, das einen Satz von Befehlen umfasst, die, wenn sie von einem Computersystem (150) ausgeführt werden, das Computersystem (150) hierzu veranlassen: Anwenden (43) eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator; Kompilieren (44) einer Ausgabe des Hardwareebene-Simulators in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei und Verifizieren (46), dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Wenigstens ein computerlesbares Datenspeichermedium nach Anspruch 13, wobei die Ausgabe des Hardwareebene-Simulators eine Befehlsstromdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) hierzu veranlassen: Extrahieren (72) eines Opcode-Stroms aus der Befehlsstromdatei; Übersetzen (74) des Opcode-Stroms in Assemblercode; und Generieren (76) eines oder mehrerer Flussgraphen basierend auf dem Assemblercode, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequentiellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Wenigstens ein computerlesbares Datenspeichermedium nach Anspruch 14, wobei die Ausgabe des Hardwareebene-Simulators (175) ferner eine Speicherverfolgungsdatei beinhalten soll und wobei, um die Ausgabe des Hardwareebene-Simulators (175) zu kompilieren, die Befehle, wenn sie ausgeführt werden, ferner das Computersystem (150) veranlassen, die STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei zu generieren.
Wenigstens ein computerlesbares Datenspeichermedium nach einem der Ansprüche 14 oder 15, wobei, um den Opcode-Strom aus der Befehlsstromdatei zu extrahieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) veranlassen, einen abstrakten Syntaxbaum basierend auf der Befehlsstromdatei zu generieren.
Wenigstens ein computerlesbares Datenspeichermedium nach einem der Ansprüche 13-16, wobei die Ausgabe des Hardwareebene-Simulators (175) eine erweiterte Wertänderungs-Speicherauszugsdatei und eine Deckungsdatei beinhalten soll, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei, um die Diagnosedeckung der STL-Datei zu verifizieren, die Befehle, wenn sie ausgeführt werden, das Computersystem (150) hierzu veranlassen: Anwenden der erweiterten Wertänderungs-Speicherauszugsdatei und der STL-Datei auf einen Fehlersimulator, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt; und Vergleichen der Ausgabe des Fehlersimulators mit der Deckungsdatei.
Wenigstens ein computerlesbares Datenspeichermedium nach Anspruch 17, wobei die Befehle, wenn sie ausgeführt werden, das Computersystem (150) veranlassen, die Ausgabe des Hardwareebene-Simulators (175) mit einer angepassten Kostenfunktion zu rekompilieren, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Verfahren, umfassend: Anwenden (42) eines Funktionssicherheitstest-Stimulus auf einen Hardwareebene-Simulator (175); Kompilieren (44) einer Ausgabe des Hardwareebene-Simulators (175) in eine Software-Test-Bibliothek (Software Test Library, STL)-Datei; und Verifizieren (46), dass sich eine Diagnosedeckung der STL-Datei einer Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Verfahren nach Anspruch 19, wobei die Ausgabe des Hardwareebene-Simulators (175) eine Befehlsstromdatei beinhaltet und wobei das Kompilieren der Ausgabe des Hardwareebene-Simulators (175) beinhaltet: Extrahieren (72) eines Opcode-Stroms aus der Befehlsstromdatei; Übersetzen (74) des Opcode-Stroms in Assemblercode; und Generieren (76) eines oder mehrerer Flussgraphen basierend auf dem Assemblercode, wobei die ein oder mehreren Flussgraphen Funktionsblöcke von sequentiellem Code in dem Funktionssicherheitstest-Stimulus rekonstruieren.
Verfahren nach Anspruch 20, wobei die Ausgabe des Hardwareebene-Simulators (175) ferner eine Speicherverfolgungsdatei beinhaltet und wobei das Kompilieren der Ausgabe des Hardwareebene-Simulators (175) ferner das Generieren der STL-Datei basierend auf den ein oder mehreren Flussgraphen und der Speicherverfolgungsdatei beinhaltet.
Verfahren nach einem der Ansprüche 20 oder 21, wobei das Extrahieren des Opcode-Stroms aus der Befehlsstromdatei das Generieren eines abstrakten Syntaxbaums basierend auf der Befehlsstromdatei beinhaltet.
Verfahren nach einem der Ansprüche 19-22, wobei die Ausgabe des Hardwareebene-Simulators (175) eine erweiterte Wertänderungs-Speicherauszugsdatei und eine Deckungsdatei beinhaltet, welche die Diagnosedeckung des Funktionssicherheitstest-Stimulus angibt, und wobei das Verifizieren der Diagnosedeckung der STL-Datei beinhaltet: Anwenden der erweiterten Wertänderungs-Speicherauszugsdatei und der STL-Datei auf einen Fehlersimulator, wobei eine Ausgabe des Fehlersimulators die Diagnosedeckung der STL-Datei angibt; und Vergleichen der Ausgabe des Fehlersimulators mit der Deckungsdatei.
Verfahren nach Anspruch 23, ferner beinhaltend das Rekompilieren der Ausgabe des Hardwareebene-Simulators (175) mit einer angepassten Kostenfunktion, falls sich die Diagnosedeckung der STL-Datei nicht der Diagnosedeckung des Funktionssicherheitstest-Stimulus annähert.
Vorrichtung, die Mittel zum Durchführen des Verfahrens nach Anspruch 23 umfasst.