-
Die
sich erhöhende
Komplexität
von Systementwürfen,
erhöhte
Investitionen, die aufgrund dieser Komplexität erforderlich sind und verkürzte Herstellungszyklen
stellten bedeutende Herausforderungen für die Nach-Silizium-Entwurfsverifizierung
von Chipsätzen
dar. Dies gilt im wesentlichen im Hinblick auf High-End-Cache-kohärente nichteinheitliche Speicherzugriffschipsätze („ccNUMA"-Chipsätze; ccNUMA
= cache coherent non-uniform memory access), wo Systeme äußerst groß und komplex
sein können.
Eine Prozessor-Nach-Silizium-Verifizierung ist üblicherweise
auf eine elektrische Verifizierung fokussiert, zumindest im Hinblick
auf eine funktionale Verifizierung aufgrund des großen Betrags
eines vollständig
kundenspezifischen Entwurfs. Chipsätze stellen aufgrund der großen Anzahl
von Zellen, aus denen dieselben bestehen, eine unterschiedliche
Herausforderung dar. Zusätzlich
verbraucht aufgrund der bloßen
Anzahl von Bussen, interner Buszuteilung, Cache-Kohärenzsteuerung,
Warteschlangenzuteilung etc. in einem großen ccNUMA-Server eine Nach-Silizium-Funktionsverifizierung
eines solchen Chipsatzes einen größeren Betrag von Ressourcen im
Hinblick auf eine elektrische Verifizierung als Prozessoren üblicherweise
verbrauchen. Eine interne Beobachtbarkeit, während dieselbe bei einer Vor-Silizium-Verifizierung
relativ einfach ist, stellt eine große Hürde bei der Fehlerbeseitigung
und Funktionstestabdeckung dar.
-
Das
Bestimmen, wann eine Systemverifizierung vollständig ist, ist eine zweite große Hürde beim Fertigstellen
einer Nach-Silizium-Verifizierung auf zeiteffektive Weise. Während ein
Vor-Silizium-, simulationsbasiertes Testen im wesentlichen von einem arbeitsintensiv
angewiesenen und Pseudozufalls-Testen abhängt, hing das Nach-Silizium-Testen historisch
von dem Beobachten von Systemoperationen ab, die ein korrektes Verhalten
anzeigen.
-
Das
Ausführen
einer Nach-Silizium-Entwurfsverifizierung ist eine Industriestandardpraxis, die
das Freilegen von Programmfehlern ermöglicht, die üblicherweise
nicht bei der Vor-Silizium-Verifizierung entdeckt werden. Üblicherweise
umfassen entdeckte Nach-Silizium-Fehler jene, die nach einer langen
oder Geschwindigkeits-Operation des Systems manifestiert werden,
jene, die aufgrund einer inkorrekten Modellierung von Hardware-
und Firmwareschnittstellen resultieren, jene, die aus Registerübertragungssprache-Fehlern („RTL-Fehlern;
RTL = Register Transfer Language) resultieren, die bei der Vor-Silizium-Erfassung
entkommen sind, und jene, die aus einer inkorrekten Abbildung von
RTL-auf-Silizium entstehen (Synthese-/physische Fehler). Anerkannte
Verfahren zum Ausführen
von Systemen, um Nach-Silizium-Programmfehler
freizulegen, umfassen das Abspielen von Betriebssystemen und Softwareanwendungen,
die für
das abschließende
System gedacht sind, das Erzeugen von spezifischen zweckgebundenen
Softwaretests, die unterschiedliche Abschnitte des Systems belasten,
und das Durchführen
von Softwaretests, die zufällige
Systemoperationen erzeugen.
-
Eine
Echtzeit-Beobachtbarkeit („RTO"; RTO = real-time
observability) bezieht sich auf die Fähigkeit, interne Signale in
Echtzeit entweder auf dem oder entfernt von dem Chip zu überwachen
und zu erfassen. Während
interne Signalbeobachtbarkeitsmerkmale bei einigen feldprogrammierbaren
Gatearray-Architekturen („FPGA"; FPGA = field programmable
gate array) und anwendungsspezifischen integrierten Schaltungen
(„ASICs"; ASIC = application specific
integrated circuit) verfügbar
waren, hatten sie üblicherweise
einen eingeschränkten
Umfang. Einschränkende
Faktoren waren Siliziumbereich, Verdrahtungseinschränkungen
und I/O-Beschränkungen.
Zusätzlich
dazu wurden Beobachtbarkeitsmerkmale üblicherweise zum Programmfehlerbeseitigen
und nicht für
eine Funktionstestabdeckung verwendet.
-
Sobald
eine IC entworfen ist, mit oder ohne internen Signalbeobachtbarkeitsfähigkeiten,
verbleibt ein Bedarf zum Testen des Entwurfs. Verilog HDL ist eine
Hardwarebeschreibungssprache („HDL"; HDL = Hardware
Description Language). Eine HDL ist eine Sprache, die zum Beschreiben
eines digitalen Systems verwendet wird, z. B. eines Computers oder
einer Komponente eines Computers. Ein digitales System kann auf
verschiedenen Ebenen beschrieben werden. Zum Beispiel könnte eine
HDL das Layout von Drähten,
Widerständen
und Transistoren auf einem IC-Chip beschreiben; d. h. auf der Schalterebene.
Im Gegensatz dazu könnten die
Logikgatter und Flip-Flops in einem digitalen System beschrieben
werden, d. h. die Gate-Ebene. Eine sogar noch höhere Ebene beschreibt die Register und Übertragungen
von Informationsvektoren zwischen Registern. Dies wird die Registerübertragungsebene
(„RTL"; RTL = Register
Transfer Level) genannt. Verilog HDL unterstützt alle diese Ebenen.
-
Verilog
ist ein diskreter Ereigniszeitsimulator. Wie Fachleute auf dem Gebiet
erkennen werden, kann bei Verilog HDL die Ausführung einer Verfahrensanmerkung
beim Auftreten eines genannten Ereignisses ausgelöst werden.
Eine Aufzeichnung des Auftretens von Ereignissen während einer
Simulation wird als ein „Ereignisprotokoll" in einer „Ereignisprotokolldatei" beibehalten. Eine
primäre
Verwendung von HDLs ist die Simulation eines Entwurfs, bevor der
Entwurf an die Herstellung übergeben
wird. Während
verschiedene HDLs existieren, ist keine bekannt, die HDL-Ereignisse in dem
Kontext einer Echtzeitbeobachtbarkeit eines digitalen Systems unterstützt.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein
System zum Verifizieren von Bedingungen und eine Vorrichtung zum
Verifizieren des Auftretens von Bedingungen mit verbesserten Charakteristika
zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein System gemäß Anspruch
14 und eine Vorrichtung gemäß Anspruch
24 gelöst.
-
Bei
einem Ausführungsbeispiel
richtet sich die Erfindung auf ein Verfahren zum Verifizieren von Bedingungen,
die während
einer Simulation eines Hardwareentwurfs auftreten. Das Verfahren
weist das Protokollieren jedes Auftretens von zumindest einer spezifizierten
Bedingung in einem ersten Protokoll; das Protokollieren von Signalen,
die an einem Beobachtbarkeitstor beobachtet werden, in einem zweiten
Protokoll; und das Vergleichen des ersten und des zweiten Protokolls
auf, um zu bestimmen, ob für
jedes Auftreten der zumindest einen spezifizierten Bedingung, der
in dem ersten Protokoll protokolliert ist, ein entsprechender Eintrag,
der ein Signal identifiziert, das ansprechend auf das Auftreten
der zumindest einen spezifizierten Bedingung beobachtet werden soll,
in dem zweiten Protokoll protokolliert ist.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein Blockdiagramm eines
Programmfehlerbeseitigungsbusses eines Ausführungsbeispiels;
-
2 ein Blockdiagramm eines
Bussegments des Programmfehlerbeseitigungsbusses aus 1;
-
3 ein Blockdiagramm eines
Standardlogikblocks, der verwendet wird, um das Bussegment aus 2 zu implementieren;
-
4 einen Simulationsdurchlauf,
der gemäß einem
Ausführungsbeispiel
ausgeführt
wird;
-
5 die Beziehung zwischen
einem exemplarischen Ereignisprotokoll und einem exemplarischen
Beobachtbarkeitstorprotokoll, das gemäß einem Ausführungsbeispiel
erzeugt wird; und
-
6 ein Flußdiagramm
der Operation eines Ausführungsbeispiels.
-
In
den Zeichnungen sind gleiche oder ähnliche Elemente mit identischen
Bezugszeichen in den unterschiedlichen Ansichten derselben bezeichnet und
die verschiedenen gezeigten Elemente sind nicht notwendigerweise
maßstabsgetreu.
-
Wie
in 1 dargestellt ist,
weist gemäß einem
Ausführungsbeispiel
ein Programmfehlerbeseitigungsbus 100 eine Mehrzahl von
Bussegmenten 102(0) – 102(4) auf,
die in einem seriellen Ring miteinander verbunden sind, und läuft bei
der Kerntaktgeschwindigkeit einer IC, z. B. einer ASIC, in der der Bus
implementiert ist. Bei einer Implementierung ist der Programmfehlerbeseitigungsbus
100 80 Bit breit; im allgemeinen entspricht die Breite des Programmfehlerbeseitigungsbusses
Bauelementstifteinschränkungen.
Ferner, obwohl das dargestellte Ausführungsbeispiel nur fünf Bussegmente 102(0) – 102(4) verwendet,
wird darauf hingewiesen, daß je
nach Bedarf mehr oder weniger als fünf Bussegmente implementiert
sein können,
zum Liefern einer geeigneten logischen und physischen Partitionierung.
-
Jedes
Bussegment 102(0) – 102(4) weist mehrere
Zugriffspunkte 104 auf, an denen Daten aus der umliegenden
Logik auf den Programmfehlerbeseitigungsbus 100 gemultiplext
werden. Wie nachfolgend Bezug nehmend auf 3 und 4 detaillierter beschrieben
wird, weist jeder Zugriffspunkt 104 einen Standardlogikblock
mit einer proprietären MUX-Struktur auf, die
Programmfehlerbeseitigungsdaten in den Zugriffspunkt treibt, der
nachfolgend die Daten auf den Fehlerbeseitigungsbus 100 treibt.
-
Wie
in 1 dargestellt ist,
sind zwei Beobachtbarkeitstore 106, 108 definiert.
Bei einem Ausführungsbeispiel
ist eines der Tore, d. h. Tor 106, ein zweckgebundenes
Programmfehlerbeseitigungstor. Das andere Tor, d. h. Tor 108,
ist mit Funktionssignalen beladen. Der Programmfehlerbeseitigungsbus 100 enthält Programmfehlerbeseitigungsdaten,
die beide diese Tore 106, 108 treiben. Bei einem
Ausführungsbeispiel
weist das Fehlerbeseitigungstor 106 80 Datenstifte auf,
plus vier Übernahmesignalstifte,
die einfach gepumpt werden, mit der Absicht, daß das Tor 106 direkt
mit einem Logikanalysator (nicht gezeigt) verbunden wird.
-
Wie
vorangehend angezeigt wurde, wird das Programmfehlerbeseitigungstor 106 direkt
von dem Programmfehlerbeseitigungsbus 100 gespeist, der bei
einer Kerntaktgeschwindigkeit läuft
und die Bussegmente 106 in einem seriellen Ring verbindet.
Der Programmfehlerbeseitigungsbus 100 ist so segmentiert,
daß für einen
einer Mehrzahl von Funktionsbereichen einer IC, in der der Bus implementiert
ist, Pakete zu und von dem Bereich zusätzlich zu 80 Bits interner
Bedingungsdaten beobachtet werden können. Zusätzlich dazu werden Details
im Hinblick auf die Implementierung und die Operation des Programmfehlerbeseitigungsbusses 100 und
der Tore 102, 104 in der gemeinsam zugewiesenen,
mitanhängigen U.S.-Patentanmeldung
Anwaltsaktenzeichen 200209004-1 mit dem Titel „AN INTEGRATED CIRCUIT" bereitgestellt,
die in ihrer Gesamtheit hierin vorangehend durch Bezugnahme aufgenommen
wurde.
-
2 ist ein detaillierteres
Blockdiagramm des Bussegments 102(0) des Programmfehlerbeseitigungsbusses 100,
der in 1 dargestellt
ist. Wie in 2 dargestellt
ist, umfaßt
das Bussegment 102(0) eine Mehrzahl von Zugriffspunkten 104.
Es sollte darauf hingewiesen werden, daß, obwohl nur vier Zugriffspunkte 104 gezeigt
sind, jedes Bussegment 102(0) – 102(4) mehr oder
weniger Zugriffspunkte aufweisen kann, wie es durch die Anzahl von
Signalen erfor derlich ist, die durch das Bussegment gehandhabt werden
müssen.
-
Wie
in 2 gezeigt ist, umfaßt jeder
Zugriffspunkt 104 einen Lokaldateneintrittsabschnitt 202 und
einen entsprechenden Programmfehlerbeseitigungsbus-Schnittstellenblock
(„DBIB"; DBIB = debug bus
interface block) oder ein Busschnittstellenmodul 204, das
mit demselben verbunden ist. An jedem Zugriffspunkt 104 werden
bis zu 80 Datenbits von einer umliegenden Logik („dbug_read_bus") zu dem DBIB 204 derselben über einen
MUX 206 entlang eines Busses 207 geliefert. Ein
Steuerungs- und Statusregister („CSR") 208 liefert ein 32-Bit-MUX-Auswahlsignal
(„*_dbg_link_ctl") zu den MUX 210, 212 des
entsprechenden DBIB 204 zu Zwecken, die nachfolgend über einen
Bus 214 detaillierter beschrieben werden.
-
3 ist ein detaillierteres
Blockdiagramm von einem der DBIBs 204 aus 2. Bei einem Ausführungsbeispiel ist der Programmfehlerbeseitigungsbus 100 logisch
in acht 10-Bit-Blöcke unterteilt. Jeder
DBIB 204 kann eingehende Programmfehlerbeseitigungsbusdaten
(„dbg_chain_in") von dem vorangehenden
DBIB in der Kette in diesen 10-Bit-Blöcken bewegen und/oder replizieren,
um Raum für eingehende
Daten („dbg
read bus") aus dem
entsprechenden Lokaldateneintrittsabschnitt 202 zu schaffen,
falls nötig,
und die neu konfigurierten Daten („dbg_chain_out") zu dem nächsten DBIB 204 in
der Kette weiterleiten. Allgemein führt jeder DBIB 204 die nachfolgenden
drei Funktionen aus: (1) er leitet die Daten von dem vorangehenden
Zugriffspunkt weiter, (2) er bewegt 10-Bit-Datenblöcke von
dem vorangehenden Zugriffspunkt zu anderen Bereichen des Programmfehlerbeseitigungsbusses,
wodurch eine effizientere Bandbreitenverwendung ermöglicht wird; und
(3) er multiplext Daten aus einer umgebenden Logik in 10-Bit-Teilen
herein.
-
Wie
vorangehend angezeigt wurde, um das Multiplexen von Daten möglich zu
machen, wird der Programmfehlerbeseiti gungsbus 100 logisch
in acht 10-Bit-Blöcke
unterteilt, wobei jeder derselben individuell gehandhabt werden
kann. Ferner registriert jeder Zugriffspunkt 104 Daten
aus dem vorangehenden Zugriffspunkt, ordnet die Daten aus dem vorangehenden
Zugriffspunkt in 10-Bit-Blöcken
an, wie durch das entsprechende CSR-Steuerungssignal („*_dbg_link_ctl") spezifiziert ist,
und multiplext lokale Daten herein, die zu dem nächsten Zugriffspunkt weitergeleitet
werden sollen. Entsprechend funktioniert das *_dbg_link_control-Signal
als ein MUX-Auswahlsignal.
-
Gemäß Merkmalen
eines Ausführungsbeispiels
wird ein HDL-Ereignis
definiert, das einen Funktionssignalnamen enthält, wobei eine MUX-Auswahlkonfiguration
erforderlich ist, um das Funktionssignal an dem Beobachtbarkeitstor 106 (1) und die Bitposition des
Funktionssignals an dem Beobachtbarkeitstor zu sehen. Ein beispielhaftes
Ereignismakro zum Definieren eines solchen Ereignisses, bezeichnet
durch „EVENT_DBG_C", wird nachfolgend ausgeführt:
EVENT_DBG_C(<ck>, <mux_sel>, <constant>, <signal_name>, <offset>, <slot>, <event_ID>);
<ck> Der Kerntakt.
<mux_sel> Die Bits in *_dbg_link_ctl,
die erforderlich sind, um das Signal freizugeben, das durch <signal_name> identifiziert ist.
Dieses Feld kann 1 bis 64 Bits aufweisen. Dies ist eine Variable.
<constant> Wenn <mux_sel> = <constant>, dann wird das Ereignis ausgelöst. Dieses
Feld weist ebenfalls 1 bis 64 Bits auf. Dies ist eine Konstante.
Es ist alles umfaßt,
das nicht „egal" ist, einschließlich Nullen.
<signal_name> Das Signal (Variable),
das zu dem Programmfehlerbeseitigungsbus geht.
Bitte nicht
Null einfüllen.
Das
Feld des Signals, das durch <signal_name> identifiziert ist,
muß mit
einer Blockgrenze ausgerichtet sein (außer ein <Versatz> ungleich Null ist spezifiziert).
Signale,
die mehrere Blöcke
umspannen, sind OK, aber der Block muß zusammenhängend sein und durch dieselben
MUX-Auswahlbits freigegeben werden.
<offset> Der Versatz von einer 10-Bit-Blockgrenze (Hex-Wert
0 bis 9) des Signals identifiziert durch <signal_name>. Die meisten Signale sollten auf einer 10-Bit-Blockgrenze
ausgerichtet sein und daher eine Null in diesem Feld aufweisen.
<slot> Eine 8-Bit-Maske,
die anzeigt, welcher Block oder welche Blöcke beschrieben werden für das Signal,
das durch <signal_name> identifiziert ist
(Konstante). Blöcke
müssen
zusammenhängend
sein.
<event_ID> Die Ereignis-ID. Diese
MUSS absolut eindeutig sein. Die Verwendung eines Blocks als eine Vorsilbe
(z. B. pin dbg block0) wird vorgeschlagen.
-
EREIGNISMAKRO
-
4 stellt einen Simulationsdurchlauf 400 dar,
der gemäß einem
Ausführungsbeispiel
ausgeführt
wird. Wie in 4 gezeigt
ist, wird während
des Simulationsdurchlaufs 400 eine Verilog-HDL-Simulation 402 des
Programmfehlerbeseitigungsbusses 100 (1) durchgeführt. Während der Simulation 402,
jedesmal wenn die Zustände
derart sind, daß ein
Signal auf dem Programmfehlerbeseitigungsbus aktiv sein sollte (d.
h., wenn <mux_sel> = <constant>), feuert das EVENT_DBG_C ab und Auftreten des
Ereignisses, einschließlich
des Signalnamens, der Plazierung (d. h. Versatz und Schlitz), und
des Werts des MUX-Auswahlsignals, wird in einem Ereignisprotokoll 404 aufgezeichnet.
Gleichzeitig wird der Wert des Signals in einem Beobachtbarkeitstorprotokoll 406 aufgezeichnet.
-
Sobald
die Simulation abgeschlossen ist, werden die zwei Protokolle 404, 406 verglichen,
entweder manuell oder unter Verwendung eines Computerprogramms oder
Skripts 408, das zu diesem Zweck entworfen ist, um zu bestimmen,
ob die Daten aus den Funktionssignalen auf dem Beobachtbarkeitstor
in der richtigen Position mit allen richtigen Werten auftreten,
wie durch das Ereignisprotokoll 404 angezeigt ist. Anders
ausgedrückt
zeigen die Einträge
in dem Ereignisprotokoll 404 an, daß die Zustände für das genannte Signal ordnungsgemäß waren,
das an dem Beobachtbarkeitstor an der spezifizierten Position aufgetreten
ist; daher sollte das Signal an der entsprechenden Position in dem
Beobachtbarkeitstorprotokoll 406 erscheinen. Wenn dies nicht
der Fall ist, d. h. wenn das erwartete Signal nicht an dem Beobachtbarkeitstor
auftritt, wie in dem Beobachtbarkeitstorprotokoll 406 angezeigt
ist, kann ein Konnektivitätsproblem
angezeigt werden.
-
5 stellt die Beziehung zwischen
einem exemplarischen Ereignisprotokoll 500 und einem exemplarischen
Beobachtbarkeitstorprotokoll 502 dar, das unter Verwendung
der hierin beschriebenen Ausführungsbeispiele
erzeugt wurde. Das Ereignisprotokoll 500 weist drei Informationsspalten
auf, einschließlich
einer Spalte 504(a), die Indizes enthält, einer Spalte 504(b),
die Ereignis-IDs enthält,
und einer Spalte 504(c), die Ereignisdaten enthält. Jede
Zeile des Ereignisprotokolls 500 stellt einen Eintrag dar;
jeder Eintrag wird durch einen Zeitindex in der Spalte 504(a) bezeichnet.
Verschiedene Einträge,
z. B. jene Einträge,
die durch das Bezugszeichen 506 bezeichnet werden, sind
andere Ereignisse als Programmfehlerbeseitigungsereignisse und sind
daher für
die hierin beschriebenen Ausführungsbeispiele
nicht relevant. Verbleibende Einträge, d. h. jene Einträge, die durch
die Bezugszeichen 508(0) – 508(6) bezeichnet werden,
sind Programmfehlerbeseitigungsereignisse, wie durch die Anmerkungen
angezeigt ist, die in der Ereignis-ID-Spalte 504(b) derselben
gemacht werden und daher von Interesse sind.
-
Auf ähnliche
Weise weist das Beobachtbarkeitstorprotokoll 502 zwei Informationsspalten
auf, einschließlich
einer Spalte 510(a), die Zeitindexinformationen aufweist,
und einer Spalte 510(b), die die tatsächlichen Daten aufweist, die
protokolliert werden, wenn sie während
der Simulation an dem Beobachtbarkeitstor beobachtet werden.
-
Wie
vorangehend erwähnt
wurde, tritt eine Verifizierung von HDL-Ereignissen auf, wenn für jedes
Programmfehlerbeseitigungsereignis, das in dem Ereignisprotokoll 500 (Einträge 508(0) – 508(6)) angemerkt
wird, entsprechende Daten auf dem Beobachtbarkeitstor angemerkt
werden, wie durch das Beobachtbarkeitstorprotokoll 502 angezeigt
ist. Dies ist bei dem Beispiel der Fall, das in 5 dargestellt ist. Zum Beispiel, im Hinblick
auf den Eintrag 508(1), werden entsprechende Daten („DATA0") an dem Beobachtbarkeitstor
ausgegeben, wie durch einen Eintrag 512(0) in dem Beobachtbarkeitstorprotokoll 502 angezeigt
ist. Auf ähnliche
Weise werden Daten, die den Einträgen 508(2) – 508(6) entsprechen
(d. h. „DATA1", „DATA2", „DATA3", „DATA4", „DATA5" bzw. „DATA6"), an dem Beobachtbarkeitstor
ausgegeben, wie durch die Einträge 512(1) – 512(6) in
dem Beobachtbarkeitstorprotokoll 502 angezeigt ist. Entsprechend
ist es durch Vergleichen der zwei Protokolle 500, 502 möglich, nicht
nur zu bestimmen, daß ein Ereignis
aufgetreten ist, sondern daß das
erwartete Signal an der erwarteten Position beobachtet wurde (in
diesem Fall dem Beobachtbarkeitstor).
-
6 ist ein Flußdiagramm
der Operation eines Ausführungsbeispiels.
Bei Block 600 wird eine HDL-Simulation (z. B. eine Verilog-Simulation)
an dem Entwurf durchgeführt,
z. B. an dem Entwurf für den
Programmfehlerbeseitigungsbus aus 1.
Bei Block 602 werden während
der Simulation Ereignisse in ein Ereignisprotokoll protokolliert,
wie z. B. das Ereignisprotokoll 500. Wie vorangehend Bezug
nehmend auf 5 dargestellt
wurde, umfaßt
jeder Ereignisprotokolleintrag eine Ereignis-ID, die den Typ des
Ereignisses (z. B. Programmfehlerbeseitigungsereignis) und die Ereignisdaten
identifiziert, wie z. B. den Namen des Signals, MUX-Auswahlsignale,
Position des Signals usw. Bei Block 604, der im wesentlichen
gleichzeitig mit Block 602 arbeitet, werden Signale, die
an dem Beobachtbarkeitstor beobachtet werden, in ein Beobachtbarkeitstorprotokoll
protokolliert, wie z. B. das Protokoll 502 (5). Nach der Fertigstellung
der Simulation bei Block 606 werden bei Block 608 die
Einträge
in das Ereignisprotokoll und das Beobachtbarkeitstorprotokoll verglichen,
um die HDL-Ereignisse
zu verifizieren, die in dem Ereignisprotokoll protokolliert sind.
Wie vorangehend erwähnt
wurde, kann dieser Prozeß manuell
oder durch ein speziell geschriebenes Computerprogramm oder ein
Skript ausgeführt
werden, das zu diesem Zweck entworfen wurde und das auf einem Computer
ausgeführt
wird.
-
Eine
Implementierung der Erfindung, die hierin beschrieben ist, schafft
somit ein System und ein Verfahren zum Verifizieren von HDL-Ereignissen zum
Aktivieren einer Echtzeitbeobachtbarkeit in einer IC. Die Ausführungsbeispiele,
die gezeigt und beschrieben wurden, wurden als ausschließlich darstellend
charakterisiert; es sollte daher offensichtlich sein, daß verschiedene Änderungen
und Modifikationen an denselben ausgeführt werden können, ohne von
dem Schutzbe reich der vorliegenden Erfindung abzuweichen, wie er
in den nachfolgenden Ansprüchen
ausgeführt
ist. Zum Beispiel, während
die Ausführungsbeispiele
Bezug nehmend auf eine ASIC beschrieben wurden, wird darauf hingewiesen,
daß die Ausführungsbeispiele
in anderen Typen von ICs implementiert sein können, wie z. B. kundenspezifischen Chipsätzen, feldprogrammierbaren
Gatearrays („FPGAs"), programmierbaren
Logikvorrichtungen („PLDs"), generischen Logikarraymodulen („GAL-Modulen"; GAL = generic array
logic), und ähnlichem.
Zusätzlich
dazu können
die hierin beschriebenen Ausführungsbeispiele
mit anderen HDLs als der Verilog-HDL implementiert sein. Ferner, obwohl
die Ausführungsbeispiele
Bezug nehmend auf Programmfehlerbeseitigungsdaten beschrieben wurden,
wird darauf hingewiesen, daß dieselben
zum Verifizieren anderer Typen von HDL-Ereignissen und entsprechender
Daten ebenfalls anwendbar sind.