DE10353370A1 - Vorrichtung und Verfahren zum Verifizieren von HDL-Ereignissen für eine Beobachtbarkeit - Google Patents

Vorrichtung und Verfahren zum Verifizieren von HDL-Ereignissen für eine Beobachtbarkeit Download PDF

Info

Publication number
DE10353370A1
DE10353370A1 DE10353370A DE10353370A DE10353370A1 DE 10353370 A1 DE10353370 A1 DE 10353370A1 DE 10353370 A DE10353370 A DE 10353370A DE 10353370 A DE10353370 A DE 10353370A DE 10353370 A1 DE10353370 A1 DE 10353370A1
Authority
DE
Germany
Prior art keywords
signal
specified condition
occurrence
gate
observability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10353370A
Other languages
English (en)
Inventor
Tyler James Plano Johnson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE10353370A1 publication Critical patent/DE10353370A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

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 in einem zweiten Protokoll beobachtet werden; 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, von dem erwartet wird, daß es ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung beobachtet wird, in dem zweiten Protokoll protokolliert ist.

Description

  • 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.

Claims (29)

  1. Verfahren zum Verifizieren von Bedingungen, die während einer Simulation eines Hardwareentwurfs auftreten, wobei das Verfahren folgende Schritte aufweist: Protokollieren jedes Auftretens von zumindest einer spezifizierten Bedingung (602) in einem ersten Protokoll (404); Protokollieren von Signalen (604), die an einem Beobachtbarkeitstor (106) in einem zweiten Protokoll (406) beobachtet werden; und Vergleichen (608) des ersten und des zweiten Protokolls (404, 406), um zu bestimmen, ob für jedes Auftreten der zumindest einen spezifizierten Bedingung, die in dem ersten Protokoll (404) protokolliert ist, ein entsprechender Eintrag, der ein Signal identifiziert, von dem erwartet wird, daß es ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung beobachtet wird, in dem zweiten Protokoll (406) protokolliert ist.
  2. Verfahren gemäß Anspruch 1, bei dem das Vergleichen (608) auftritt, nachdem die Simulation beendet ist (606).
  3. Verfahren gemäß Anspruch 1 oder 2, bei dem das Protokollieren (602, 604) während der Simulation auftritt.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem die zumindest eine spezifizierte Bedingung ein Hardwaredefinitionssprachenereignis („HDL"-Ereignis) ist.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem die zumindest eine spezifizierte Bedingung Multiple xerauswahlbits (214) aufweist, die gleich einem vorbestimmten Wert sind.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem jeder Eintrag in dem ersten Protokoll (404) ein Signal identifiziert, von dem erwartet wird, daß es an dem Beobachtbarkeitstor (106) ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung beobachtet wird.
  7. Verfahren gemäß Anspruch 6, bei dem das Beobachtbarkeitstor (106) mit einem Programmfehlerbeseitigungsbus verbunden ist und Signale von demselben empfängt.
  8. Verfahren gemäß Anspruch 7, bei dem jeder Eintrag in dem ersten Protokoll (404) ferner eine Anzeige einer Position auf dem Programmfehlerbeseitigungsbus (100) des Signals umfaßt, das in dem Eintrag identifiziert ist.
  9. Verfahren gemäß Anspruch 8, bei dem der Programmfehlerbeseitigungsbus (100) logisch in eine Mehrzahl von Blöcken partitioniert ist und bei dem die Position des identifizierten Signals auf dem Programmfehlerbeseitigungsbus (100) eine Anzeige von zumindest einem Block aufweist, in den das identifizierte Signal geschrieben ist.
  10. Verfahren gemäß Anspruch 9, bei dem der Programmfehlerbeseitigungsbus (100) 80 Bits aufweist, wobei jeder Block 10 Bits umfaßt.
  11. Verfahren gemäß Anspruch 9 oder 10, bei dem die Position des identifizierten Signals auf dem Programmfehlerbeseitigungsbus (100) ferner eine Anzeige eines Versatzes von einer Grenze des zumindest einen Blocks aufweist, in den das identifizierte Signal geschrieben ist.
  12. Verfahren gemäß einem der Ansprüche 1 bis 11, bei dem das Vergleichen (608) manuell ausgeführt wird.
  13. Verfahren gemäß einem der Ansprüche 1 bis 11, bei dem das Vergleichen (608) unter Verwendung eines Computers ausgeführt wird, der einen spezialisierten Satz von Befehlen ausführt.
  14. System zum Verifizieren von Bedingungen, die während einer Simulation eines Hardwareentwurfs auftreten, wobei das System folgende Merkmale aufweist: eine erste Protokolleinrichtung, die eine Mehrzahl von Einträgen zum Protokollieren jedes Auftretens während der Simulation der zumindest einen spezifizierten Bedingung aufweist; eine zweite Protokolleinrichtung, die eine Mehrzahl von Einträgen zum Protokollieren von Signalen aufweist, die an einem Beobachtbarkeitstor (106) während der Simulation beobachtet werden; und eine Einrichtung zum Vergleichen von Einträgen, die die erste und die zweite Protokolleinrichtung aufweist, um zu bestimmen, ob für jeden Eintrag, der ein Auftreten der zumindest einen spezifizierten Bedingung bezeichnet, die in der ersten Protokolleinrichtung protokolliert ist, ein entsprechender Eintrag, der ein Signal identifiziert, von dem erwartet wird, daß es ansprechend auf ein Auftreten der zumindest einen spezifizierten Bedingung beobachtet wird, in der zweiten Protokolleinrichtung umfaßt ist.
  15. System gemäß Anspruch 14, bei dem die zumindest eine spezifizierte Bedingung ein Hardwaredefinitionssprachen-Ereignis („HDL"-Ereignis) ist.
  16. System gemäß Anspruch 14 oder 15, bei dem die zumindest eine spezifizierte Bedingung Multiplexerauswahlbits (214) aufweist, die gleich einem vorbestimmten Wert sind.
  17. System gemäß einem der Ansprüche 14 bis 16, bei dem jeder Eintrag in dem ersten Protokoll (404) ein Signal identifiziert, von dem erwartet wird, daß es an dem Beobachtbarkeitstor (106), ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung, beobachtet wird.
  18. System gemäß Anspruch 17, bei dem das Beobachtbarkeitstor (106) einem Programmfehlerbeseitigungsbus (100) zugeordnet ist und Signale von demselben empfängt.
  19. System gemäß Anspruch 18, beim dem jeder Eintrag in dem ersten Protokoll (404) ferner eine Anzeige einer Position des Signals, das in dem Eintrag identifiziert ist, auf dem Programmfehlerbeseitigungsbus (100), umfaßt.
  20. System gemäß Anspruch 19, bei dem der Programmfehlerbeseitigungsbus (100) logisch in eine Mehrzahl von Blöcken partitioniert ist und bei dem die Position des identifizierten Signals auf dem Programmfehlerbeseitigungsbus eine Anzeige von zumindest einem Block aufweist, in den das identifizierte Signal geschrieben ist.
  21. System gemäß Anspruch 20, bei dem der Programmfehlerbeseitigungsbus (100) 80 Bits aufweist, wobei jeder Block 10 Bit umfaßt.
  22. System gemäß Anspruch 20 oder 21, bei dem die Position des identifizierten Signals auf dem Programmfehlerbeseitigungsbus (100) ferner eine Anzeige eines Versat zes von einer Grenze des zumindest einen Blocks aufweist, in den das identifizierte Signal geschrieben ist.
  23. System gemäß einem der Ansprüche 14 bis 22, bei dem die Einrichtung zum Vergleichen einen Computer aufweist, der einen spezialisierten Satz von Befehlen ausführt.
  24. Vorrichtung zum Verifizieren des Auftretens von Bedingungen während einer Simulation eines Hardwareentwurfs, wobei die Vorrichtung folgende Merkmale aufweist: ein Ereignisprotokoll zum Protokollieren jedes Auftretens von zumindest einer spezifizierten Bedingung; ein Torprotokoll zum Protokollieren von Signalen, die an einem Beobachtbarkeitstor (106) beobachtet werden; und ein computerausführbares Computerprogramm zum Vergleichen des Ereignisprotokolls mit dem Torprotokoll, um zu bestimmen, ob für jedes Auftreten der zumindest einen spezifizierten Bedingung, die in dem Ereignisprotokoll protokolliert ist, ein entsprechender Eintrag, der ein Signal identifiziert, von dem erwartet wird, daß es ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung beobachtet wird, in dem Torprotokoll protokolliert ist.
  25. Vorrichtung gemäß Anspruch 24, bei der die zumindest eine spezifizierte Bedingung ein Hardwaredefinitionssprachen-Ereignis („HDL"-Ereignis) ist.
  26. Vorrichtung gemäß Anspruch 24 oder 25, bei der die zumindest eine spezifizierte Bedingung Multiplexeraus wahlbits (214) aufweist, die gleich einem vorbestimmten Wert sind.
  27. Vorrichtung gemäß einem der Ansprüche 24 bis 26, bei der jeder Eintrag in dem Ereignisprotokoll (404) ein Signal identifiziert, von dem erwartet wird, daß es an dem Beobachtbarkeitstor (106), ansprechend auf das Auftreten der zumindest einen spezifizierten Bedingung, beobachtet wird.
  28. Vorrichtung gemäß Anspruch 27, bei der jeder Eintrag in dem Ereignisprotokoll ferner eine Anzeige einer Position des Signals, das in dem Eintrag identifiziert ist auf einem Programmfehlerbeseitigungsbus (100), umfaßt.
  29. Vorrichtung gemäß Anspruch 28, bei der der Programmfehlerbeseitigungsbus (100) lokal in eine Mehrzahl von Blöcken partitioniert ist und bei der die Position des identifizierten Signals auf dem Programmfehlerbeseitigungsbus eine Anzeige von zumindest einem Block, in den das identifizierte Signal geschrieben ist, und eine Anzeige eines Versatzes von einer Grenze des zumindest einen Blocks aufweist, in den das identifizierte Signal geschrieben ist.
DE10353370A 2003-03-28 2003-11-14 Vorrichtung und Verfahren zum Verifizieren von HDL-Ereignissen für eine Beobachtbarkeit Withdrawn DE10353370A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/402,122 US7200778B2 (en) 2003-03-28 2003-03-28 System and method for verifying HDL events for observability
US10/402122 2003-03-28

Publications (1)

Publication Number Publication Date
DE10353370A1 true DE10353370A1 (de) 2004-10-21

Family

ID=32989617

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10353370A Withdrawn DE10353370A1 (de) 2003-03-28 2003-11-14 Vorrichtung und Verfahren zum Verifizieren von HDL-Ereignissen für eine Beobachtbarkeit

Country Status (2)

Country Link
US (1) US7200778B2 (de)
DE (1) DE10353370A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110087861A1 (en) * 2009-10-12 2011-04-14 The Regents Of The University Of Michigan System for High-Efficiency Post-Silicon Verification of a Processor
US8990622B2 (en) * 2012-07-29 2015-03-24 International Business Machines Corporation Post-silicon validation using a partial reference model
US11030370B2 (en) 2019-09-30 2021-06-08 International Business Machines Corporation Modular event-based performance monitoring in integrated circuit development

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4228537A (en) * 1978-08-29 1980-10-14 Genrad, Inc. Method of and apparatus for automatic fault diagnosis of electrical circuits employing on-line simulation of faults in such circuits during diagnosis
JPH0561931A (ja) * 1991-08-30 1993-03-12 Mitsubishi Electric Corp シミユレーシヨン装置
US5515384A (en) * 1994-03-01 1996-05-07 International Business Machines Corporation Method and system of fault diagnosis of application specific electronic circuits
US5546562A (en) * 1995-02-28 1996-08-13 Patel; Chandresh Method and apparatus to emulate VLSI circuits within a logic simulator
US5737517A (en) * 1995-12-21 1998-04-07 Ericsson, Inc. Testing tools in an intelligent network system
US6298286B1 (en) * 1999-12-17 2001-10-02 Rockwell Collins Method of preventing potentially hazardously misleading attitude data
US6865692B2 (en) * 2000-10-27 2005-03-08 Empirix Inc. Enterprise test system having program flow recording and playback
US6539341B1 (en) * 2000-11-06 2003-03-25 3Com Corporation Method and apparatus for log information management and reporting
US6629297B2 (en) * 2000-12-14 2003-09-30 Tharas Systems Inc. Tracing the change of state of a signal in a functional verification system
US6944796B2 (en) * 2002-06-27 2005-09-13 Intel Corporation Method and system to implement a system event log for system manageability
US7930490B2 (en) * 2002-12-23 2011-04-19 Siemens Industry, Inc. Method for utilizing a memory device for a programmable logic controller (PLC)

Also Published As

Publication number Publication date
US20040194041A1 (en) 2004-09-30
US7200778B2 (en) 2007-04-03

Similar Documents

Publication Publication Date Title
DE60100754T2 (de) System und verfahren zum testen von signalverbindungen unter verwendung einer eingebauten selbsttestfunktion
DE69019402T2 (de) Prüfverfahren und -gerät für integrierte Schaltungen.
DE112020000036T5 (de) Automatisierte prüfeinrichtung zum prüfen eines oder mehrerer prüfobjekte, verfahren zum automatisierten prüfen eines oder mehrerer prüfobjekte und computerprogramm unter verwendung eines pufferspeichers
DE112013000758B4 (de) Erzeugen von Taktsignalen für einen zyklusgenauen, zyklusreproduzierbaren FPGA-gestützten Hardware-Beschleuniger
DE10392497T5 (de) Herstellungsverfahren und Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs bei der ASIC/SOC-Herstellung
DE19937232B4 (de) Entwicklungs- und Bewertungssystem für integrierte Halbleiterschaltungen
DE3702408C2 (de)
DE112010006087T5 (de) Architektur zum Testen, zur Validierung und zur Fehlerbereinigung
DE19943941A1 (de) Programmierbare JTAG-Netzwerkarchitektur zum Unterstützen eines proprietären Debug-Protokolls
EP1720100A1 (de) Verfahren und Vorrichtung zur Emulation einer programmierbaren Einheit
DE102005025744A1 (de) Verfahren und Vorrichtung zum automatisierten Testaufbau
DE112012005320T5 (de) Multicore-Prozessor mit intern integriertem entscheidungsbasierten Selbsttest
DE112021006159T5 (de) Systeme, verfahren und vorrichtungen zum hochgeschwindigkeits-eingangs/ ausgangs-margin-test
DE19950821A1 (de) Bewertungssystem für integrierte Halbleiterschaltungen
DE1524175A1 (de) Pruefeinrichtung in elektronischen Datenverarbeitungsanlagen
DE69017169T2 (de) Testen integrierter Schaltungen unter Verwendung von Taktgeberstössen.
DE102010012904A1 (de) Systeme zum Testen von Verbindungen zwischen Chips
DE102004058753A1 (de) Verifizierung von Integrierte-Schaltung-Tests unter Verwendung einer Testsimulation und einer Integrierte-Schaltungs-Simulation mit einem simulierten Ausfall
DE69419269T2 (de) Verfahren zur automatischen Ermittlung von offenen Schaltkreisen
DE102021130630A1 (de) Testen von software-anwendungskomponenten
DE102006011706A1 (de) Halbleiter-Bauelement, sowie Halbleiter-Bauelement-Test-Verfahren
DE102020108216A1 (de) Verfahren und Vorrichtungen zum Durchführen von Design for Debug über eine Protokollschnittstelle
US6928629B2 (en) System and method for parsing HDL events for observability
EP1430320B1 (de) Elektronischer baustein und verfahren zu dessen qualifizierungsmessung
DE10353370A1 (de) Vorrichtung und Verfahren zum Verifizieren von HDL-Ereignissen für eine Beobachtbarkeit

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8130 Withdrawal