-
Gebiet der vorliegenden Offenbarung
-
Die
vorliegende Offenbarung betrifft allgemein Systeme und Techniken
zum Testen von Halbleiterbauelementen in Form von Hardware- und/oder
Softwarerepräsentanten
und betrifft insbesondere Systeme und Techniken zum Testen komplexer
integrierter Schaltungen, die eine zentrale Recheneinheit (CPU) und
eingebettete periphere Einrichtungen aufweisen, die mit der CPU
durch interne Bussysteme zum Definieren eines Systems auf einem
Chip (SoC) verbunden sind.
-
Beschreibung des Stands der
Technik
-
Bei
der Herstellung von Halbleiterbauelementen mit relativ komplexer
Schaltung stellt das Testen des Bauelements einen Teil des Fertigungsprozesses
dar, der lange Zeit im Hinblick auf Kosten und Aufwand unterschätzt wurden,
die zum Erhalten zuverlässiger
Daten im Hinblick auf die korrekte Funktion und Zuverlässigkeit
des Bauelements erforderlich sind. In dieser Hinsicht ist die Herstellung komplexer
Halbleiterbauelemente so zu verstehen, dass diese die Gestaltung
des Bauelements auf der Grundlage einer Funktionsbeschreibung des
gewünschten
Funktionsverhaltens des Bauelements, die diversen Stufen des Vorsehens
einer vorläufigen Implementierung
des Bauelements in Form eines Softwaremodells oder eines Hardwareprototyps
und entsprechende neu gestaltete Versionen davon nach dem Erkennen
von Fehlern während
der Verifizierung, sowie die eigentliche Implementierung der letztlich
ermittelten Gestaltung in Form des Halbleitermaterials umfasst.
Ein Grund für
das Nichterfüllen von
Spezifikationen der integrierten Schaltung in Bezug auf ihr Funktionsverhalten
kann in Entwurfsfehlern liegen, die durch Schaltungsverifizierung
auf Grundlage von Softwaresimulation und/oder Prototypenprüfung vor
der Massenproduktion der betrachteten integrierten Schaltungen erkannt
und korrigiert werden können.
Eine nicht korrekte Funktion der integrierten Schaltung kann ferner
durch den Fertigungsprozess selbst hervorgerufen werden, wenn das
fertiggestellte Leiterelement nicht den verifizierten Schaltungsentwurf
auf Grund von Prozessschwankungen in einem oder mehreren der großen Anzahl
an Prozessschritten, die zur Bearbeitung erforderlich sind, entspricht.
Obwohl Mess- und Testverfahren an vielen Punkten des Fertigungsablaufs enthalten
sind, ist es dennoch äußerst wichtig,
die korrekte Funktion des endgültigen
Halbleiterbauelements sicherzustellen, da gemäß einer groben Regel die Kosten,
die durch fehlerhafte Chips hervorgerufen werden, mit jeder Installationsphase
um ungefähr eine
Größenordnung
ansteigen. Beispielsweise sind die durch eine defekte Platine mit
einem fehlerhaften Chip hervorgerufenen Kosten typischerweise deutlich
höher als
das Erkennen eines fehlerhaften Chips vor dem Verkaufen und Montieren
der Platine. Das selbe gilt für
ein System, wenn dessen Fehler durch ein oder mehrere Defekte Platinen
hervorgerufen wird, da die nicht produktive Zeit eines industriellen Systems
zu mittleren Kosten von ungefähr
einigen 100 Dollar pro Minute im Vergleich zum Preis von einigen
Dollar für
einen integrierten Schaltungschip führen, der den Defekt hervorgerufen
hat.
-
Somit
gibt es ein großes
Interesse für
das Entwickeln von Testverfahren, um möglichst viele Defekte in fertiggestellten
integrierten Schaltungen zu erkennen, ohne jedoch die Gesamtfertigungskosten
unnötig
zu erhöhen.
Insbesondere mit der Forderung nach mehr Leistungsmerkmalen und
geringeren Kosten von Schaltungen gibt es eine Tendenz, eine Vielzahl
unterschiedlicher Schaltungsbereiche in einen einzelnen Chip zu
integrieren, um damit ein vollständiges
System auf einem Chip (SoC) bereitzustellen. Ein Halbleiterbauelement
mit diversen Funktionsblöcken
enthält
typischerweise zusätzlich
zu einem oder mehreren Logikblöcken
einen oder mehrere eingebettete Speicherbereiche, wie sie beispielsweise
für chipinterne
Zwischenspeicher für
CPU's oder Puffer
für Datenpakete
eingesetzt werden, die zwischen unterschiedlichen Taktsignalbereichen ausgetauscht
werden, sowie weitere periphere Komponenten, etwa komplexe I/O-Einrichtungen,
spezielle Funktionsblöcke
für eine
effiziente Datenverarbeitung einer speziellen Art und dergleichen,
wobei diese peripheren Blöcke
funktionsmäßig mit
der CPU des Systems über
geeignete Bussysteme verbunden sind.
-
Wie
zuvor erläutert
ist, zwingen ökonomische
Rahmenbedingungen die Halbleiterhersteller nicht nur dazu, die Defektrate
des gesamten Fertigungsprozesses zu minimieren, sondern auch im
Zusammenhang mit einer gewissen Defektwahrscheinlichkeit eine hohe
Abdeckung in der Fehlererkennung zu erhalten, um damit die Auslieferung
fehlerhafter Chips bei vernünftigen
Preisen für
geeignete Testverfahren und Techniken zu reduzieren. Für moderat komplexe
integrierte Schaltungen ist es inzwischen Standard, den grundlegenden
Entwurf der Schaltung zu entwickeln, wobei mehrere Rahmenbedingungen, die
durch effektive Testverfahren auferlegt werden, berücksichtigt
werden. Typischerweise werden zusätzliche Hardwareressourcen
in dem Chip vorgesehen, die das Erkennen fehlerhafter Chipkomponenten
für eine
breite Klasse an Betriebsbedingungen ermöglichen, wobei die zusätzlichen
Hardwareressourcen in Kombination mit Entwurfseigenheiten der grundlegenden
Schaltung und anspruchsvollen Testverfahren und Testmustern im Wesentlichen
die Fehlerabdeckung des Prüfverfahrens
bestimmen.
-
In
vielen Schaltungsgestaltungen wird der funktionale Logikblock durch
sogenannte Abtastketten geprüft,
die eine Kette aus Flipflops repräsentieren, die mit einem speziellen
Bereich des Funktionsblocks so verbunden sind, dass der Funktionsblock oder
ein spezieller Bereich davon mit einem gewünschten Zustand initialisiert
werden kann, der zuvor in die Abtastkette eingespeist wurde. In
diesem Falle kann der Zustand des Logikblockes auf Grundlage des
Zustands einzelner Logikgatter verifiziert werden, was als eine
Verifizierung des Funktionsverhaltens des Logikblocks auf Registertransferebene bezeichnet
werden kann. Mit dem Fortschreiten der Halbleitertechnologie, die
nunmehr über
Transistorabmessungen von ungefähr
40 nm oder weniger angekommen ist, sind jedoch äußerst komplexe CPU-Gestaltungsformen
verfügbar,
die Millionen von Logikgattern enthalten, wodurch es zunehmend schwierig
ist, die korrekte Funktion der CPU auf Registertransferebene zu
verifizieren. Auf Grund des Einbaus komplexer peripher Blöcke, wie
dies zuvor erläutert
ist, sind weitere Anstrengungen erforderlich, um Entwurfsfehler
in einer frühen
Fertigungsphase vor dem eigentlichen Implementieren der Massenproduktionstechnik
zu erkennen.
-
Somit
trägt eine
Verschiebung des Brennpunkts der Elektronikindustrie von einer Steigerung der
Frequenz zur Vergrößerung der
Funktionsvielfalt deutlich zu der Gesamtkomplexität der entsprechenden
Verifizierung von Halbleiterbauelementen bei, wodurch einzunehmender
Bedarf für
Verifizierungsverfahren entsteht, die das Prüfen der Schaltungsentwürfe auf
höherer
Ebene an Abstraktion im Vergleich zur Registertransferebene, die
zuvor erläutert ist,
ermöglichen.
Beispielsweise nimmt die Komplexität für das Verifizieren von registerbasierten
Logikschaltungen mit dem Quadrat des Anstiegs der Anzahl an Registern
zu und somit wird bei Verdoppelung der Komplexität der Schaltungsausführung beispielsweise
durch Fortschreiten zu einem künftigen Technologiestandard,
eine vierfache Auswirkung auf die Verifizierung erwartet. Um eine
effiziente Modellierung sehr komplexer Schaltungsentwürfe von
eingebetteten Hardware/Software-Systemen zum Abschätzen der
Funktionseigenschaften und des Leistungsverhaltens vor der tatsächlichen
Implementierung dieser Systeme zu ermöglichen, wurden eine Reihe
unterschiedlicher Systembeschreibungssprachen, etwa SystemC, SpecC,
System Verilog und dergleichen entwickelt. Zusätzlich zu dem Bereitstellen
geeigneter und leistungsfähiger
Beschreibungssprachen für
das Modellieren komplexer Schaltungsentwürfe kann das Verifizieren auf
unterschiedlichen Abstraktionsebenen so ausgeführt werden, dass die Möglichkeit
geschaffen wird, die Verifizierungskosten zu senken und das Erkennen
von Fehlern in der Gestaltung zu ermöglichen und diese entweder
den Unzulänglichkeiten
in den architekturspezifischen Aspekten oder den implementationsspezifischen
Aspekten zuzuordnen. Das Modellieren komplexer Schaltungsentwürfe auf
höherer
Abstraktionsebene im Vergleich zur Registertransferebene kann beispielsweise
durch eine transaktionsbasierte Modellierungstechnik erreicht werden,
die auf Grundlage des Kombinierens diverser Kommunikationsereignisse
zu sogenannten Transaktionen abläuft,
wodurch ein deutlich höheres
Maß an
Abstraktion im Vergleich zur Registertransferebene gewöhnlicher
Signale erreicht wird. D. h., eine Transaktion kann als ein vollständiges Kommunikationsereignis
verstanden werden, beispielsweise das Übertragen eines Datenpunkts
oder eines vollständigen
Blockes aus Daten, wobei ein entsprechendes Kommunikationsereignis idealerweise
durch den Austausch einer einzelnen Nachricht innerhalb des transaktionsbasierten
Simulationsmodells repräsentiert
wird. Auf diese Weise kann eine verbesserte Simulationsleistung
im Vergleich zu ereignisgesteuerten Simulationen von signalbasierten
Kommunikationsprotokollen erreicht werden. Die durch transaktionsbasierte
Modellierungstechnik erreichte Abstraktion kann mit einer geringeren
Genauigkeit im Hinblick auf das Zeitverhalten innerhalb der simulierten
Schaltung einhergehen, da die diversen unterschiedlichen Protokollphasen, die
während
einer entsprechenden Transaktion erforderlich sein können, nicht
aufgelöst
werden, wobei selbst für
gemeinsam genutzte Kommunikationsmedien, etwa Schnittstellenbusse,
ein reduziertes Maß an
Genauigkeit auftreten kann. D. h., der Zeitablauf für vollständige Transaktionen
kann ggf. mit einem unterschiedlichen Maß an Genauigkeit in Abhängigkeit
von der angewendeten Modellierungsstrategie überwacht werden. Zum Beispiel
werden in taktsignalangenäherten
Modellen typischerweise entsprechende Transaktionen derart eingerichtet,
dass das simulierte Zeitintervall der Aktivität eng mit der entsprechenden
Zeit verknüpft
ist, die in einer tatsächlichen
Hardwareimplementierung erforderlich ist. Ein genaues Auflösen des
Ablaufs unterschiedlicher Transaktionen kann jedoch nicht beobachtet
werden und auch die gesamte Zeitdauer einer einzelnen Transaktion,
d. h. von aktiven Phasen plus Unterbrechungen, kann aus dem Modell
nicht bestimmt werden.
-
Andererseits
kann der gesamte Kommunikationsverkehr auf einem entsprechenden
Bus mit ausreichender Genauigkeit bestimmt werden. Somit kann unter
Anwendung einer transaktionsbasierten Verifizierung die Abschätzung und
das Prüfen
gewisser Schaltungskomponenten auf einer höheren Ebene im Vergleich zur
Ebene von Bussignaländerungen bewerkstelligt
werden, wodurch die Gesamtverifizierungseffizienz ansteigt. Beispielsweise
können Transaktionen
typischerweise zufällig
erzeugt werden, um damit die Testabdeckung zu erhöhen, wobei auch
die Möglichkeit
des Einführens
entsprechender gegebener Bedingungen geschaffen wird, um nutzlose
Betriebsszenarien in der getesteten Schaltungskomponente auszuschließen.
-
Konventionelle
Verifizierungslösungen
für komplexe
Systeme mit einer zentralen Recheneinheit (CPU) teilen für gewöhnlich die
Verifizierung in eine Verifizierung des CPU-Kerns und eine Verifizierung der eingebetteten
peripheren Funktionskomponenten auf. Nach der Verifizierung dieser
Komponenten wird ein zusätzlicher
Schritt zur Systemverifizierung ausgeführt, um damit das Funktionsverhalten des
Systems als Ganzes abzuschätzen
und zu verifizieren.
-
Mit
Bezug zu den 1a bis 1c wird
ein typischer konventioneller Ansatz zum Ausführen eines Verifizierungsprozesses
für ein
System auf einem Chip erläutert,
wobei unterschiedliche Ebenen der Abstraktion eingesetzt werden.
-
1a zeigt
schematisch ein System 100, das ein komplexes Halbleiterbauelement
in einem entsprechenden Zustand des Gesamtfertigungsablaufes repräsentiert.
D. h., das System 100 repräsentiert ein Halbleiterbauelement
während
einer Entwurfsphase, das aus diversen Funktionsmodulen aufgebaut
ist, wobei auch eine oder mehrere der Komponenten des Systems 100 in
Form von in Hardware eingerichteten Prototypen vorgesehen sein können, wenn
dies als geeignet erachtet wird. Beispielsweise kann das System 100 eine
zentrale Recheneinheit (CPU) 101, einen peripheren Funktionsblock 102 und
eine Speichersteuerung 103 aufweisen, wobei diese Komponenten
miteinander über
einen entsprechenden Bus oder ein Schnittstellensystem 104 kommunizieren,
das auch als Querverbindungsschalter (xbar) 105 bezeichnet
wird. Wie zuvor angegeben ist, kann die Verifizierung der CPU 101 im Wesentlichen
auf Grundlage von Assemblercodierungsgeneratoren erfolgen, die einen
Assemblercode in einer mehr oder weniger zufälligen Weise bereitstellen,
wobei auch spezielle Bedingungen enthalten sind, um damit ineffiziente
Phasen während
des Verifizierens der CPU 101 zu vermeiden. Die Assemblercodierung
kann dann in eine Maschinencodierung übersetzt werden, die der CPU 101 und
auch einem Referenzmodell zugeführt
wird, um die von der Assemblercodierung in der CPU 101 und
dem Referenzmodell erzeugten Ergebnisse zu vergleichen.
-
1b zeigt
schematisch eine Testumgebung 150, die auch als eine „Testbank" bezeichnet wird,
die ausgebildet ist, die zuvor beschriebene Verifizierungssequenz
auszuführen.
D. h., die Testumgebung 150 umfasst eine Testszenarien-Einheit
oder eine Teststeuerung 151, die mit einem Assemblergenerator 152 zur
Bereitstellung einer zufälligen
Sequenz an Assemblerstrukturen verbunden ist, die optional von der
Teststeuerung 151 gesteuert wird. Ferner ist ein Modul 153,
das entsprechende Verifizierungsbedingungen repräsentiert, mit dem Assemblergenerator 152 verbunden,
um spezielle Beschränkungen
im Hinblick auf die Zufälligkeit
der Assemblercodierung, die von dem Generator 152 bereitgestellt
wird, einzufügen.
Ein Maschinencodierungskonverter 154 ist mit dem Assemblergenerator 152 verbunden,
um damit eine Maschinencodierung auf der Grundlage der eingespeisten
Assemblercodierung zu erzeugen. Wie gezeigt, ist die Teststeuerung 151 auch
mit dem Maschinencodierungskonverter 154 verbunden, wenn
vorbestimmte Testszenarien in Form geeignet vorgewählter Assemblerbefehlssequenzen
während
der Verifizierung der CPU 101 zu verwenden sind. Die von
dem Maschinencodierungskonverter 151 ausgegebene Maschinencodierung ausgegebene
Maschinencodierung wird in einem geeigneten Speicherbauelement oder
einem Speichermodell 155 gespeichert, aus der die CPU 101 und
ein geeignetes Referenzmodell 156 Maschinencodierungsbefehle,
die von der CPU 101 und dem Referenzmodell 156 ausgeführt werden,
abrufen. Die von der CPU 101 und dem Referenzmodell 156 erhaltenen
Ergebnisse werden einem Prüfmodul 157 zugeführt, das
im Grund entsprechende Ergebnisse vergleicht und eine Abweichung
angibt, um damit Fehler in der CPU 101 zu erkennen.
-
1c zeigt
schematisch eine Testumgebung 160 in Form einer transaktionsbasierten
Umgebung, die für
die Verifizierung des peripheren Funktionsblocks 102 verwendet
werden kann, der tatsächlich
eine Vielzahl eingebetteter peripherer Komponenten enthalten kann,
wie dies zuvor erläutert
ist. Somit ist die Testumgebung 160 ausgebildet, den peripheren
Funktionsblock auf einer höheren
Abstraktionsebene zu stimulieren, wie dies zuvor erläutert ist, wobei
entsprechende Transaktionen für
gewöhnlich mehrere
Protokolleinheiten der diversen Busschnittstellen in dem System 104 repräsentieren,
die für
den Betrieb des peripheren Funktionsblocks 102 in dem System 100 erforderlich
sind. Zu diesem Zweck umfasst die Testumgebung 160 eine
Teststeuerung 161, die ausgebildet ist, einen Transaktionsgenerator 162 zu
steuern, um damit eine Sequenz aus Transaktionen bereitzustellen,
so dass ein gewünschtes
Maß an
Prüfungsabdeckung
erreicht wird. Beispielsweise steuert die Teststeuerung 161 den
Transaktionsgenerator 162 so, dass ein mehr oder minder
zufälliger Strom
an Transaktionen bereitgestellt wird, wobei auch spezielle Beschränkungen
oder Bedingungen dem Transaktionsgenerator 162 auferlegt
werden, um damit ineffiziente Testszenarien zu vermeiden. Die von
dem Generator 162 erzeugten Transaktionen werden in geeignete
Signalformen für
einen Bus, etwa einen Bus A, der mit dem peripheren Funktionsblock 102 verbunden
ist, übersetzt.
Das Umwandeln von Transaktionen in geeignete Bussignale kann mittels
eines Busfunktionsmodells (BFM) 163 erreicht werden, wobei
jedoch, wie zuvor erläutert
ist, jedoch die zeitliche Koordination der Transaktionen und der jeweiligen
Bussignalformen von der zu Grunde liegenden Modellierungsstrategie
abhängt.
Der periphere Funktionsblock 102 reagiert auf Transaktionen durch
entsprechende Signalformen, die auf einer jeweiligen Busschnittstelle
B bereitgestellt werden, die wiederum mit einem Monitor 165 verbunden
ist, der ausgebildet ist, die Bussignale in Transaktionen umzuwandeln.
In ähnlicher
Weise werden die Bussignale des Busses A einem Monitor 165 zugeführt, der
die Bussignale in Transaktionen umwandelt, die dann einem Referenzmodell 166,
das das daraus erwartete Verhalten des peripheren Blocks 102 repräsentiert, zugeführt werden.
-
In
anderen Fällen
wird der Monitor 165 weggelassen und das Referenzmodell 166 kann
direkt mit dem Transaktionsgenerator 162 verbunden sein. Die
Transaktionen, die von dem Monitor 164, der die Antwort
des peripheren Funktionsblockes in Bezug auf die anfänglichen
Transaktionen, die von dem Generator 162 erhalten wurden,
repräsentiert,
bereitgestellt werden, werden einem Prüfmodul 167 zugeführt, das
ebenfalls die anfänglichen
Transaktionen über
dem Monitor 165 oder den Transaktionsgenerator 162 erhält. Somit
kann eine entsprechende Abweichung von Ergebnissen aus dem Referenzmodell 166 in
Bezug zu dem peripheren Funktionsblock 102 auf Transaktionsebene
abgeschätzt
werden, um damit das Funktionsverhalten des Blocks 102 zu
verifizieren. Es kann eine Rückkopplung
zwischen dem Monitor 164 und der Teststeuerung 161 vorgesehen sein,
beispielsweise über
ein geeignetes Testabdeckungsmodul 168 oder ein anderes
geeignetes Funktionsmodul, das dann die Teststeuerung 161 in
die Lage versetzt, den Strom der von dem Generator 162 erzeugten
Transaktionen in Reaktion auf die Transaktionen anzupassen, die
von dem Monitor 164 erhalten werden. Somit können die
stimulierenden Transaktionen, die von dem Generator 162 erhalten werden,
nach Bedarf in Bezug auf die Antwort des peripheren Funktionsblocks 102 angepasst
werden. Es sollte beachtet werden, dass abhängig von der Konfiguration
des peripheren Blocks 102 eine Vielzahl entsprechender
Monitore bzw. Überwachungseinheiten
und Prüfmodule
vorgesehen sein können, um
damit die Bewertung mehrerer einzelner Komponenten innerhalb des
peripheren Funktionsblocks 102 zu ermöglichen. Somit wird ein hohes
Maß an Testabdeckung
erreicht, beispielsweise auf der Grundlage zufälliger aber dennoch mit Randbedingungen
versehenen Transaktionsströmen,
wobei eine deutliche reduzierte Verifizierungszeit im Vergleich
zu einem Szenario erforderlich ist, das auf einer weniger abstrakten
Ebene operiert.
-
Wie
zuvor angegeben ist, kann das System 100 als Ganzes getestet
werden, was bewerkstelligt werden kann, indem eine Menge aus speziellen
Testszenarien innerhalb der simulierten CPU 101 abgearbeitet
wird, um den eingebetteten peripheren Funktionsblock 102 zu
adressieren, was zu einer beeinträchtigten Funktionsabdeckung
oder einer reduzierten Implementierung von Ressourcen auf Grund
der sehr beschränkten
speziellen Testszenarien führen kann.
In anderen Fällen
wird das System 100 im Vergleich zu der in 1a gezeigten
Konfiguration modifiziert, um eine Schnittstelle für ein Busfunktionsmodul
vorzusehen, um damit Transaktionen in das System 100 einzuprägen, wobei
in diesem Falle die CPU 101 jedoch nicht bei der Verifizierung
auf Systemebene beteiligt ist.
-
Angesichts
der zuvor beschriebenen Situation betrifft der hierin offenbarte
Gegenstand ein System und Verfahren zum Verbessern der Effizienz
des Prüfens
integrierter Bauelemente mit einer zentralen Recheneinheit und eingebetteten
peripheren Komponenten, wobei eines oder mehrere der oben erkannten
Probleme vermieden oder zumindest reduziert wird.
-
Überblick über die Offenbarung
-
Im
Allgemeinen betrifft der hierin offenbarte Gegenstand Techniken
und Systeme zur Verbesserung der Effizienz des Verifizierungsprozesses
für Halbleiterbauelemente
in einer Entwurfsphase, wobei das Bauelement eine zentrale Recheneinheit (CPU)
möglicherweise
in Verbindung mit eingebetteten peripheren Komponenten aufweist.
Zu diesem Zweck wird eine transaktionsbasierte Testumgebung vorgesehen,
in der Transaktionen in Maschinencodierung übersetzt werden, die von der
zentralen Recheneinheit lesbar sind. Somit wird die CPU während der
Verifizierung in ihrem natürlichen
Modus betrieben, wobei auf die Maschinencodierung zugegriffen wird,
die von der in der Testumgebung erzeugten Transaktionen erhalten
wird, so dass eine transaktionsbasierte zufällige jedoch mit Rahmenbedingungen
versehene Prüfsituation
während
der Verifizierungsphase möglich
ist. Somit kann durch das Vorsehen des Übersetzens von Transaktion
in Maschinencodierung eine hohe Ebene der Abstraktion der transaktionsbasierten
Umgebung in geeigneter Weise „verringert" werden, um damit
in effizienter Weise die Verifizierung der CPU-Umgebung zu ermöglichen,
wobei auch die Möglichkeit
beibehalten wird, die Testumgebung für das Verifizieren eingebetteter peripher
Komponenten unter Anwendung einer transaktionsbasierten Teststrategie
wieder zu verwenden. Somit wird eine verbesserte Testabdeckung und
damit Verifizierungseffizienz für
die zentrale Recheneinheit erreicht, während gleichzeitig die Möglichkeit
geschaffen ist, die transaktionsbasierte Testumgebung für die Verifizierung
eines komplexen Systems erneut zu verwenden, indem bei Bedarf die Übersetzung
von Transaktionen in Maschinencodierung umgangen wird. In anderen
Aspekten nimmt die CPU an der transaktionsbasierten Funktionsverifizierung
der eingebetteten Peripherie teil, wodurch die gesamte Abdeckung
der Entwurfsprüfung
verbessert wird, indem ebenfalls die CPU und die CPU-Schnittstellen
sowie mögliche
Engstellen verifiziert werden.
-
Eine
anschauliche Testumgebung, die hierin offenbart ist, ist für die Verifizierung
eines Entwurfs eines Halbleiterbauelements mit einer zentralen Recheneinheit
und einem Schnittstellensystem, das funktionsmäßig mit der zentralen Recheneinheit
verbunden ist, ausgelegt. Die Testumgebung umfasst einen Transaktionsgenerator,
der ausgebildet ist, einen Strom aus Transaktionen zu erzeugen,
und eine Übersetzereinheit,
die funktionsmäßig mit
dem Transaktionsgenerator verbunden ist, um den Strom der Transaktionen
zu empfangen. Die Übersetzereinheit
ist ausgebildet, eine Maschinencodierungsdarstellung für jede der
Transaktionen bereitzustellen, um damit ausführbare Befehle für die zentrale
Recheneinheit bereitzustellen. Die Testumgebung umfasst ferner eine
Maschinencodierungsschnittstelle, die ausgebildet ist, die Maschinencodierungsrepräsentationen
zu empfangen und Zugriff zu zumindest einigen der Maschinencodierungsrepräsentationen durch
die zentrale Recheneinheit zu ermöglichen. Des weiteren umfasst
die Testumgebung eine Transaktionsprüfeinheit, eine Antworttransaktion,
die eine Antwort der zentralen Recheneinheit repräsentiert, zu
empfangen und zu verifizieren.
-
Ein
anschauliches hierin offenbartes Verfahren betrifft das Ausführen einer
transaktionsbasierten Verifizierung eines Halbleiterbauelements
in einer Entwurfsphase. Das Verfahren umfasst das Erzeugen mehrerer
erster Transaktionen, die Kommunikationsereignisse zwischen einer
zentralen Recheneinheit und einem peripheren Funktionsblock des
Halbleiterbauelements repräsentieren.
Das Verfahren umfasst ferner das Erzeugen von Maschinencodierungsbefehlen
aus den mehreren ersten Transaktionen, wobei die Maschinencodierungsbefehle
zumindest einige Befehle enthalten, die von der zentralen Recheneinheit
ausführbar
sind. Des weiteren umfasst das Verfahren das Ermöglichen eines Zugriffs auf
die mindestens einige ausführbaren
Befehle durch die zentrale Recheneinheit und das Prüfen einer
Antwort des peripheren Funktionsblocks und/oder der zentralen Recheneinheit,
um Verifizierungsinformation zu erhalten, wobei die Antwort auf das
Ausführen
der mindestens einigen Befehle durch die zentrale Recheneinheit
hervorgerufen wird.
-
Ein
weiteres hierin offenbartes anschauliches Verfahren umfasst das
Konfigurieren einer transaktionsbasierten Testumgebung, um eine
Sequenz aus Transaktionen zu erzeugen, die zur Verwendung in einem
zu prüfenden
Halbleiterbauelement geeignet ist, wobei das Halbleiterbauelement sich
in einer Entwurfsphase befindet und mindestens eine zentrale Recheneinheit
aufweist. Das Verfahren umfasst ferner das Umwandeln der Sequenz
aus Transaktionen in Maschinencodierungsdarstellungen und Betreiben
der zentralen Recheneinheit auf der Grundlage der Maschinencodierungsrepräsentationen,
um ein Funktionsverhalten des Halbleiterbauelements zu verifizieren.
-
Kurze Beschreibung der Zeichnungen
-
Weitere
Ausführungsformen
der vorliegenden Offenbarung sind in den angefügten Patentansprüchen definiert
und gehen deutlicher aus der folgenden detaillierten Beschreibung
hervor, wenn diese mit Bezug zu den begleitenden Zeichnungen studiert
wird, in denen:
-
1a schematisch
ein Halbleiterbauelement in einer Entwurfsphase zeigt, das eine
zentrale Recheneinheit, einen peripheren Funktionsblock und ein
Schnittstellensystem aufweist;
-
1b schematisch
eine Testumgebung darstellt, die für die Verifizierung der zentralen
Recheneinheit gemäß konventioneller
Strategien ausgestaltet ist;
-
1c schematisch
eine transaktionsbasierte Testumgebung zeigt, die ausgebildet ist,
den peripheren Funktionsblock auf Transaktionsebene gemäß konventioneller
Verifizierungstechniken zu verifizieren;
-
2a schematisch
eine transaktionsbasierte Testumgebung mit einer Übersetzungseinheit von
Transaktionen in Maschinencodierung gemäß anschaulicher Ausführungsformen
zeigt;
-
2b schematisch
die Umwandlung eines Stroms aus Transaktionen in Maschinencodierungsbefehle,
die von einer zu prüfenden
CPU ausführbar sind,
gemäß anschaulicher
Ausführungsformen zeigt;
-
2c schematisch
eine transaktionsbasierte Testumgebung mit einer Übersetzungseinheit von
Transaktionen in Maschinencodierungen und einer Rückkopplungsschleife
zur Anpassung des Transaktionsstromes an die Antwort des zu testenden
Bauelements gemäß weiterer
anschaulicher Ausführungsformen
zeigt;
-
2d bis 2g schematisch
entsprechende Bereiche der transaktionsbasierten Testumgebung gemäß diverser
Alternativen zeigen, um Zugriff auf die übersetzte Maschinencodierungsbefehle durch
die zu testende CPU gemäß anschaulicher Ausführungsformen
zu ermöglichen;
und
-
2h schematisch
eine transaktionsbasierte Testumgebung mit einer Konfiguration für eine Wiederbenutzung
darstellt, um beispielsweise ein System als ganze und separate periphere
Komponenten gemäß noch weiteren
anschaulichen Ausführungsformen
zu prüfen.
-
Detaillierte Beschreibung
-
Obwohl
die vorliegende Offenbarung mit Bezug zu den Ausführungsformen
beschrieben ist, wie sie in der folgenden detaillierten Beschreibung
sowie in den Zeichnungen dargestellt sind, sollte beachtet werden,
dass die detaillierte Beschreibung sowie die Zeichnungen nicht beabsichtigen,
die vorliegende Offenbarung auf spezielle offenbarte Ausführungsformen
einzuschränken,
sondern die beschriebenen anschaulichen Ausführungsformen stellen lediglich
beispielhaft die diversen Aspekte des hierin offenbarten Gegenstands
dar, dessen Schutzbereich durch die angefügten Patentansprüche definiert
ist.
-
Im
Allgemeinen betrifft der hierin offenbarte Gegenstand Testplattformen
oder Testumgebungen, die auf Transaktionsebene arbeiten, wodurch
eine verbesserte Verifizierungseffizienz im Hinblick auf Zeit und
Fehlerabdeckung im Vergleich zu Verifizierungstechniken auf tieferer
Ebene erreicht wird, wobei zusätzlich
die Möglichkeit
geschaffen wird, die Abstraktionsebene abzusenken, um damit das
Testen oder Verifizieren einer zentralen Recheneinheit (CPU) zu
ermöglichen.
Zu diesem Zweck wird der höhere
Abstraktionsgrad der transaktionsbasierten Testumgebung eingesetzt,
um geeignete Testszenarien zu erzeugen, etwa Transaktionsströme unter vorgegebenen
Randbedingungen, wobei entsprechende Antworten auf der Ebene der
Transaktionen abgeschätzt
werden, wobei diese Ressource auf höherer Ebene für die Mikroprozessorverifizierung
verfügbar
gemacht wird, indem eine Übersetzungseinheit
von Transaktionen in Maschinencodierung vorgesehen wird. Folglich
können
die Testplattformen und die Teststrategien, die hierin offenbart
sind, eine Verifizierung der zentralen Recheneinheiten mit hoher
Testabdeckung und hoher Effizienz ermöglichen, wobei auch eine effiziente
Wiederverwendung der transaktionsbasierten Testumgebung möglich ist,
wodurch der Gesamtaufwand für
die Verifizierung komplexer Halbleiterbauelemente mit CPU's und eingebetteten
peripheren Funktionskomponenten deutlich verringert wird. D. h.,
Komponenten auf CPU-Basis können
mit hoher Testabdeckung verifiziert werden, während auch andere eingebettete
Komponenten auf Transaktionsebene geprüft werden, und diese Testumgebungen
werden in einem Testszenario im Hinblick auf das System als Ganzes
wieder verwendet.
-
Mit
Bezug zu den 2a bis 2h werden nunmehr
weitere anschauliche Ausführungsformen detaillierter
beschrieben.
-
2a zeigt
schematisch ein Halbleiterbauelement 200 in einer Entwurfsphase,
d. h., das Halbleiterbauelement 200 wird in Form von simulierten Schaltungsmodellen
und/oder als Hardwarekomponenten zumindest teilweise in Abhängigkeit
von der Gesamtstrategie zum Entwickeln und Einrichten des Halbleiterbauelements 200 vorgesehen.
Das Halbleiterbauelement 200 umfasst eine zentrale Recheneinheit
(CPU) 201, die eine beliebige Art einer mikroprozessorbasierten
Schaltungsanordnung repräsentiert, die
auf Grundlage eines speziellen Satzes an Maschinencodierungsbefehlen
betrieben werden kann. Wie zuvor erläutert ist, umfasst die CPU 201 eine große Anzahl
an Logikgattern entsprechend dem speziellen Aufbau, wobei in modernen
Bauelementen die Anzahl der Logikgatter einige Millionen Gatter oder
noch mehr für
modernste CPU-Kerne in Abhängigkeit
von der Technologie enthalten kann. Das Bauelement 200 umfasst
typischerweise ein Schnittstellensystem 205, d. h. entsprechende
Schnittstellenbusse und dergleichen, um die CPU 201 mit
anderen Funktionseinheiten, etwa Speichereinrichtungen, speziellen
I/O-Schnittstellen, entsprechenden Wischsignalschaltungsbereichen
und dergleichen zu verbinden. Der Einfachheit halber sind derartige
eingebettete Komponenten als eingebetteter peripherer Funktionsblock 202 bezeichnet.
-
Wie
zuvor erläutert
ist, wird das Halbleiterbauelement 200, d. h. die entsprechende
Repräsentation
davon in Form von Software und/oder Hardware, typischerweise im
Hinblick auf sein Funktionsverhalten vor der eigentlichen Implementierung
der Schaltungskonfiguration als Hardware auf der Grundlage von Massenherstellungsverfahren
geprüft.
Zu diesem Zweck wird das Halbleiterbauelement 200 mit einer
Testumgebung 250 verbunden, die auch als Testblattform
bezeichnet wird, wobei dies während
einer beliebigen geeigneten Phase des Entwurfs des Halbleiterbauelements 200 erfolgt.
Die Testumgebung 250 wird in Form einer transaktionsbasierten
Umgebung bereitgestellt, die, wie zuvor beschrieben ist, auf einer
abstrakten Ebene für
die Kommunikation mit dem Bauelement 200 betrieben wird,
um damit geeignete Stimulatoren einzuprägen, die wiederum zu einer
Antwort des Bauelements 200 oder gewisser Komponenten davon
führen,
die bewertet werden können,
um das Funktionsverhalten des Bauelements 200 oder einzelner
Komponenten davon zu verifizieren. Die Testumgebung 250 umfasst
einen Transaktionsgenerator 252, der ausgebildet ist, eine
Sequenz oder einen Strom aus Transaktionen bereitzustellen, wovon
jede ein Kommunikationsereignis zwischen der CPU 201 und
einer dazu über
das Schnittstellensystem 205 verbundenen peripheren Komponente
repräsentieren
kann. Des weiteren umfasst die Umgebung 250 ein Modul 260,
das ausgebildet ist, Transaktionen von dem Generator 262 zu
empfangen, die Transaktionen in Maschinencodierungsbefehle, die
von der CPU 201 lesbar sind, zu übersetzen und einen Zugriff
auf die übersetzte Maschinencodierungsbefehle
durch die CPU 201 zu ermöglichen. Zu diesem Zweck kann
das Modul 269 eine Übersetzungseinheit
von Transaktion in Maschinencodierungen 269a in Verbindung
mit einer Maschinencodierungsschnittstelle 269b aufweisen,
die ausgebildet ist, einen Zugriff auf die Maschinencodierungsbefehle
durch die CPU 201 zu ermöglichen. Die Übersetzungseinheit 269a umfasst
beispielsweise eine geeignete Konversationsfunktion, beispielsweise
in Form einer Tabelle oder anderer geeigneter Mittel, in der eine
Transaktion mit einer entsprechenden Darstellung an Maschinencodierungsbefehlen
korreliert wird, wobei typischerweise mehrere Maschinencodierungsbefehle
einer einzelnen Transaktion zugeordnet sind, wie dies zuvor erläutert ist.
In einigen anschaulichen Ausführungsformen
umfasst die Übersetzungseinheit 269a ferner
einen Zufallsgenerator, der eine spezielle Maschinencodierungsrepräsentation
einer eintreffenden Transaktion zuordnet, wenn mehr als eine Maschinencodierungsrepräsentation mit
der eintreffenden Transaktion verknüpft ist. In anderen Fällen wird
eine Transaktion, die mit zwei oder mehr Maschinencodierungsrepräsentationen
verknüpft
ist, d. h. mit zwei oder mehreren Sequenzen aus Maschinencodierungsbefehlen,
in eine entsprechende Sequenz aus Maschinencodierungsbefehlen umgewandelt,
die Elemente mehrerer unterschiedlicher Maschinencodierungssequenzen
dieser Repräsentationen
enthalten, oder die alle einzelnen Maschinencodierungsbefehle, die
mit der betrachteten Transaktion verknüpft sind, enthalten. Es sollte
beachtet werden, dass ein beliebiger anderer Übersetzungsmechanismus für die Übersetzungseinheit 269a verwendet
werden kann.
-
Die
Testumgebung 260 umfasst ferner ein Prüfmodul 267, das mit
einem Monitor- bzw. Überwachungsmodul 264 verbunden
ist, das wiederum mit dem Schnittstellensystem verbindbar ist, um
damit Signalformen zu empfangen und die Signale in Transaktionen
umzuwandeln, die dann in dem Prüfmodul 267 bewertet
werden. Beispielsweise wird der Transaktionsgenerator 262 und/oder
das Modul 269, d. h. Schnittstelle 296b mit einem
Referenzmodell verbunden, wie dies zuvor mit Bezug zu 1c erläutert ist,
das dann ebenfalls auf die von dem Generator 262 oder die
an der Schnittstelle 269b gelieferten Maschinencodierungsbefehle
reagiert, um damit einen Vergleich zwischen den Antworten, die von dem
Monitor 264 und dem jeweiligen Referenzmodul geliefert
werden, mittels des Prüfmoduls 267 auszuführen.
-
Während des
Betriebs der transaktionsbasierten Testumgebung 260 wird
das Bauelement 200 mit dem Modul 269 verbunden,
in der gezeigten Ausführungsform über die
Schnittstelle 269b, und über dem Monitor 264 und
dem Transaktionsgenerator 262 wird eine geeignete Sequenz
aus Transaktionen bereitgestellt, wobei das Erzeugen der Transaktionen von
einem übergeordneten
Steuerungsmodul gesteuert werden kann, wie dies nachfolgend detaillierter
beschrieben ist. Beim Empfang des Stromes aus Transaktionen stellt
die Übersetzungseinheit 269a entsprechende
Maschinencodierungsbefehle bereit, die dann der CPU über die
Schnittstelle 269b zugeführt werden, wobei die CPU 201 in
ihrem natürlichen Modus
arbeitet, wodurch ausführbare
Befehle, die von der Übersetzungseinheit 269a erzeugt
werden, ausgeführt
werden. Auf der Grundlage der Maschinencodierungsbefehle adressiert
die CPU 201 periphere Komponenten, etwa den Funktionsblock 202, der
von dem Monitor 264 abgetastet wird, wodurch entsprechende übersetzte
Antworttransaktionen dem Prüfmodul 267 zugeleitet
werden.
-
2b zeigt
schematisch die gegenseitige Wechselwirkung zwischen dem Generator 262 und der Übersetzungseinheit 269a gemäß einer
anschaulichen Ausführungsform.
Ein Strom aus Transaktionen 270a, ..., 270n, die
gemeinsam als Transaktionen 270 bezeichnet werden, werden
von dem Generator 262 erzeugt und der Übersetzungseinheit 269 zugeleitet,
die entsprechende Maschinencodierungsbefehle, die mit jeder der
Transaktionen 270 verknüpft
sind, erzeugt. Die Maschinencodierungsrepräsentationen 271a,
..., 271, die gemeinsam auch als Maschinencodierungsrepräsentationen 271 bezeichnet
werden, werden in einer geeigneten Speichereinrichtung gespeichert,
die beispielsweise in der Schnittstelle 269b eingerichtet
sein kann, wie in 2a gezeigt ist, oder in einem
anderen geeigneten Speicherbereich, der einen Zugriff durch die
CPU 201 während
des Betriebs der Umgebung 260 ermöglicht. Jede der Maschinencodierungsrepräsentationen 271a umfasst
einen oder mehrere Maschinencodierungsbefehle, abhängig von
der jeweiligen zugeordneten Transaktion 270. Wie beispielsweise
in 2b gezeigt ist, entspricht die Transaktion 270b einem
Kommunikationsereignis für
das Speichern eines speziellen Inhalts eines Speicherregisters,
beispielsweise des Registers 35h, das mit dem Wert 4h geladen
ist. Ferner kann die Maschinencodierungsrepräsentation 271c entsprechende
Maschinencodierungsbefehle enthalten, um in die Register EAX und
EDX der CPU 201 zu schreiben, wenn beispielsweise der x86
Befehlssatz angewendet wird. Somit kann beim Betrieb die CPU 201 auf
einen entsprechenden Speicherbereich, der die Maschinencodierungsrepräsentationen 271 enthält, zugreifen
und kann diese Befehle ausführen,
wodurch eine entsprechende Antwort für das Adressieren peripherer Komponenten
erhalten wird, wobei die Antwort durch den Monitor 264 in
Transaktionen umgewandelt wird.
-
2c zeigt
schematisch das Halbleiterbauelement 200, wenn es mit der
transaktionsbasierten Testumgebung 260 gemäß einer
weiteren anschaulichen Ausführungsform
verbunden ist. In der gezeigten Ausführungsform umfasst die Umgebung 260 eine
Teststeuerung oder eine Testplattform 261, die ausgebildet
ist, den Transaktionsgenerator 262 beispielsweise im Hinblick
auf Testbedingungen, wie dies zuvor erläutert ist, zu steuern. In einer
anschaulichen Ausführungsform
ist das Prüfmodul 267 und/oder
der Monitor 264 mit der Teststeuerung 261 verbunden,
wodurch eine Rückkopplungsschleife
gebildet wird, die eine Anpassung des jeweiligen Stromes aus Transaktionen 270 gemäß Bedarf
in Abhängigkeit
der Antwort des Bauelements 200 ermöglicht.
-
Mit
Bezug zu den 2d bis 2g werden nunmehr
weitere anschauliche Ausführungsformen detaillierter
beschrieben, in denen die Wechselwirkung des Moduls 269 mit
dem Bauelements 200 auf Grundlage eines Speicherbereichs
bewerkstelligt wird, der in Abhängigkeit
der Verfügbarkeit
von Speichermodellen und Erfordernissen im Hinblick auf die Simulationsgeschwindigkeit
beim Betreiben der Umgebung 260 eingerichtet wird.
-
2d zeigt
schematisch die Schnittstelle 269b mit einem Speichermodul
auf tieferer Ebene 269c, auf das von der CPU 201 vollständig zugegriffen
werden kann, beispielsweise über
einer Speichersteuerung 203, die mit dem Schnittstellensystem 205 verbunden
ist, das beispielsweise in Form eines „Kreuzschalters" vorgesehen ist.
Somit können
in diesem Falle die Maschinencodierungsrepräsentationen 271 direkt
von der Übersetzungseinheit 269a erhalten
und in dem Speichermodul 269c abgelegt werden, aus welchem
entsprechende Befehle von der CPU abgerufen werden, wenn dieser
in ihrem natürlichen
Funktionsmodus arbeitet.
-
2e zeigt
schematisch die Schnittstelle 269b gemäß einer weiteren anschaulichen
Ausführungsform,
in der das Bauelement 200 keine explizite Speichersteuerung
aufweist, etwa die in 2d gezeigte Steuerung 203.
In diesem Falle umfasst die Schnittstelle 269b zusätzlich zu
dem Speichermodul tieferer Ebene 269c ein Busfunktionsmodell
(BFM) 269d, das geeignet ist, eine Verbindung mit dem System 205 herzustellen,
um damit einen vollständigen Zugriff
auf das Modell 269c durch die CPU 201 zu ermöglichen.
Auch in diesem Falle können
die Maschinencodierungsrepräsentationen 271 direkt
in dem Speichermodell 269c gespeichert werden, wohingegen
anders als in der Ausführungsform
aus 2d die dazwischenliegende Schnittstelle 269 für die gewünschte volle
Zugriffsmöglichkeit
sorgt. Es sollte beachtet werden, dass die Ausführungsform aus 2e auch
in Verbindung mit einer Speichersteuerung 203, beispielsweise
wie sie in 2d gezeigt ist, verwendet werden
kann, wenn ein vollständiger Zugriff
auf das Speichermodell 269c über die Speichersteuerung 203 nicht
gewährleistet
ist.
-
2f zeigt
schematisch das Modul 269 (siehe 2a, 2b)
gemäß weiterer
anschaulicher Ausführungsformen,
in denen ein natürliches Speichermodell
oder Speichermodell tieferer Ebene für das Bauelement 200 nicht
verfügbar
ist. In diesem Falle wird ein Speichermodell der höheren Ebene 269e vorgesehen,
das mit dem Transaktionsgenerator 262 so verbunden ist,
dass von diesem die Transaktionen 270 empfangen werden.
Ferner ist die Übersetzungseinheit 269a funktionsmäßig mit
dem Speichermodell höherer
Ebene 269e verbunden, um damit die gespeicherten Transaktionen 270 abzurufen und
diese in die jeweiligen Maschinencodierungsrepräsentationen 271 umzuwandeln.
Die Maschinencodierungsbefehle werden von der CPU 201 über die Speichersteuerung 203 abgerufen,
wobei die Übertragungsgeschwindigkeit
durch die Übersetzungseinheit 269a bestimmt
ist.
-
2g zeigt
schematisch das Modul 269 gemäß weiterer anschaulicher Ausführungsformen,
in denen der Transaktionsgenerator 262 Zugriff auf das Speichermodell
tieferer Ebene 269d besitzt. In diesem Falle wird die Schnittstelle 269 in
Form eines Busfunktionsmodells vorgesehen, das mit dem Schnittstellensystem 205 verbunden
ist, um die Maschinencodierungsrepräsentationen, die von der Übersetzungseinheit 269a erhalten
werden, in die Maschinenschnittstelle 205 einzuprägen. Zu
diesem Zweck wird eine spezielle Übergabeprozedur, d. h. Speichersemaphoren, FIFO's, Lese/Schreib-Zeiger etc.
eingesetzt, um der CPU 201 mitzuteilen, welche speziellen
Befehle auszuführen
sind und um der Schnittstelle 269b mitzuteilen, wenn weitere übersetzte
Transaktionen dem Schnittstellensystem 205 und somit dem
Speichermodell tieferer Ebene 269d zuzuführen sind.
Andererseits kann die CPU 201, die in ihrem normalen Modus
arbeitet, das Speichermodell 269d im Hinblick auf ausführbare Befehle
abfragen.
-
2h zeigt
schematisch das Halbleiterbauelement in Verbindung mit der transaktionsbasierten Testumgebung 260 gemäß weiterer
anschaulicher Ausführungsformen,
in denen die Testumgebung ausgebildet ist, eine Prüfung des
Bauelements 200 auf Blockebene und ebenfalls auf Systemebene
zu ermöglichen.
Zu diesem Zweck umfasst die Testumgebung 260 ein Modul 260a,
das eine Teststeuerung, einen Transaktionsgenerator und ein Prüfmodul aufweist,
wie es beispielsweise zuvor mit 2a in Form
der Module 261, 262 und 267 beschrieben
ist. Des weiteren ist das Modul 269 mit dem Modul 260a verbunden,
um damit einen Stimulus in Form von Maschinencodierungsbefehlen
im Bauelement 200 zuzuführen.
Zu diesem Zweck können
die Strukturen, wie sie zuvor mit Bezug zu den 2d bis 2f beschrieben
sind, für
das Modul 269 in Verbindung mit einem Speichermodell 269d eingerichtet
werden. Alternativ kann das Modul 269 so ausgebildet sein,
wie dies mit Bezug zu 2g beschrieben ist, d. h. die Übersetzungseinheit
für Maschinencodierungen 269a ist
in dem Modul 269 vorgesehen, wie in 2h gezeigt
ist, und mit der Schnittstelle 269b verbunden, die ein
Busfunktionsmodell repräsentieren
kann, um damit Maschinencodierungsbefehle in das System 205 und
schließlich
in das Speichermodell 269d einzuprägen, wie dies zuvor erläutert ist.
Somit ist in dieser Konfiguration die Testumgebung 260 ausgebildet,
eine Verifizierung der CPU 201 auf Transaktionsebene auszuführen, wie
dies zuvor beschrieben ist. Zusätzlich
umfasst die Testumgebung 260 eine Schnittstelle 263,
beispielsweise eines Busfunktionsmodells, das zum Übersetzen
von Transaktionen in Bussignale ausgebildet ist, um damit die periphere Einrichtung 202 abzusondieren,
wie dies zuvor mit Bezug zu 1c beschrieben
ist.
-
In
anderen anschaulichen Ausführungsformen
ist die Schnittstelle 263 ferner ausgebildet, um die Übersetzung
von Bussignalen in Transaktionen zu ermöglichen, die zu dem Modul 260 für eine weitere
Bewertung auf Transaktionsebene weitergeleitet werden. Des weiteren
kann die Umgebung 260 einen Monitor 265 aufweisen,
der ausgebildet ist, Bussignale in Transaktionen umzuwandeln, die
ebenfalls dem Modul 260a für eine weitere Bewertung zugeführt werden.
Somit kann mittels des Moduls 260a, der Schnittstelle 263 und
dem Monitor 265 eine transaktionsbasierte Verifizierung
des peripheren Blocks 202 in ähnlicher Weise erreicht werden,
wie dies mit Bezug zu 1c beschrieben ist, wenn auf
die transaktionsbasierte Umgebung 160 zum Verifizieren
des Funktionsblockes 102 Bezug genommen wird. Daher kann
die Testumgebung 260, wie sie in 2h gezeigt
ist, effizient verwendet oder wiederverwendet werden für eine transaktionsbasierte
Verifizierung auf Blockebene, wobei dennoch die Möglichkeit
besteht, das Bauelement 200 auf Systemebene mit der CPU 201 zu
prüfen,
wie dies zuvor beschrieben ist.
-
Obwohl
dies in den Figuren nicht explizit gezeigt ist, sollte beachtet
werden, dass die Transaktionsprüfeinheit
ausgebildet sein kann, Transaktionen zur und/oder von der CPU zu
prüfen.
Die Transaktionsprüfeinheit
kann ferner mit Schnittstellen innerhalb von peripheren Blöcken oder
mit Schnittstellen verbunden sein, die nicht direkt mit der CPU
verbunden sind. Diese Daten können
ebenfalls zur Bestimmung des Transaktionsstroms verwendet werden, der
von dem Transaktionsgenerator erzeugt wird.
-
In
anderen Aspekten wird ein Selbsttestmechanismus in das Prüfszenario
und schließlich
in die Zielplattform integriert. Beispielsweise kann ein Ablauf
zum Erkennen von geeigneten Transaktionen und zum Verwenden der
Testumgebung zur Bereitstellung von Transaktionen über den
Transaktionsgenerator und den Maschinenkodierungsübersetzer
ermittelt werden. Somit kann eine Selbstprüfungskodierung in die erzeugte
Maschinenkodierung möglicherweise
auf der Grundlage eines Referenzmodells eingebettet werden. Diese
Kodierung ist so gestaltet, dass Fehler im Aufbau, die möglicherweise
auf Fertigungsfehlern beruhen, erkannt werden. Die Selbstprüfungsmaschinenbefehle
können
in einem Speichermodell der unteren Ebene in der Testumgebung behandelt
und gespeichert werden, die auch eine Testeinheit für das Simulieren
des Verhaltens der Zielplattform des betrachteten Entwurfs, etwa
eine Computerhauptplatine, enthalten kann. Die gespeicherte Selbstprüfungskodierung
kann im realen Speicher (RAM, ROM, etc.) der Zielplattform hinterlegt
werden, um einen internen Produktfunktionstest durchzuführen.
-
Es
gilt also: Die vorliegende Erfindung stellt effiziente Verifizierungstechniken
und jeweilige Testplattformen zum Ausführen einer transaktionsbasierten
Verifizierung einzelner Blöcke
eines Systems bereit, wobei auch eine transaktionsbasierte Verifizierung
auf Systemebene möglich
ist. Zu diesem Zweck umfasst eine transaktionsbasierte Testumgebung eine Übersetzungseinheit
von Transaktionen in Maschinencodierung, die entsprechende Maschinencodierungsbefehle
in einem Speicherbereich bereitstellt, auf den die zu prüfende CPU
zugreifen kann. Somit können
vollständig
durch Randbedingungen vorgegebene Teststrategien auf Blockebene
und Systemebene angewendet werden, während zusätzlicher Aufwand zum Modifizieren
der transaktionsbasierten Umgebung auf einem geringen Niveau gehalten
werden.
-
Weitere
Modifizierungen und Variationen der vorliegenden Offenbarung werden
für den
Fachmann angesichts dieser Beschreibung offenkundig. Daher ist diese
Beschreibung als lediglich anschaulich und für die Zwecke gedacht, dem Fachmann
die allgemeine Art und Weise des Ausführens der hierin offenbarten
Prinzipien zu vermitteln. Selbstverständlich sind die hierin gezeigten
und beschriebenen Formen als die gegenwärtig bevorzugten Ausführungsformen zu
betrachten.