Die vorliegende Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zur Fehleranalyse digitaler Logikschaltungen, und insbesondere auf solche Verfahren und Vorrichtungen, die eine Hardware-Fehlersuche (Hardware-Debugging) verwenden, um eine Fehler-Erfassung und -Analyse einer digitalen Logikschaltung in Echtzeit zu ermöglichen.
Auf dem Gebiet der Technik ist eine Reihe von Verfahren zum Hardware-Debugging, die auf unterschiedlichen Lösungsansätzen basieren, bekannt. Bei einem bekannten Verfahren wird das Hardware-Verhalten einer integrierten Schaltung unter Verwendung von Logikanalysatoren oder Oszilloskopen, die mit realen Anschlussstiften der integrierten Schaltung verbunden sind, beobachtet. Dabei sind die Anschlussstifte unbenutzte Anschlussstifte, die lediglich zu Fehleranalysezwecken mit internen Knoten der integrierten Schaltung verbunden sind. Aufgrund der begrenzten Anzahl von nicht als Nutzanschlussstifte verwendeten Anschlussstiften kann durch diese Technik nur ein kleiner Satz von Signalen, die von internen Knoten stammen, beobachtet werden.
Um die Anzahl von möglichen Sonden zu erhöhen, ist es bekannt, die Anschlussstifte zu multiplexen oder virtuelle Sonden zu verwenden, wobei dies jedoch üblicherweise eine Echtzeit-Fehlerdiagnose verhindert.
Andere Lösungsansätze verwenden eine Umgebung, die die Hardware mit einer Software statt des Logikanalysators oder des Oszilloskops verbindet, um das DUT (DUT = Device under Test = Element unter Prüfung) zu beobachten. Die Softwareumgebung, die auf einem Computer abläuft, ist über eine Computerschnittstelle mit dem DUT verbunden, wobei aufgrund der ziemlich langsamen Computerschnittstelle eine Echtzeit-Fehleranalyse üblicherweise nicht möglich ist.
Ein weiteres bekanntes Verfahren ist eine Fehleranalyse un ter Verwendung von speziellen Ein-/Ausgabezellen einer ASIC (Boundary Scan Cells), mit denen FPGAs (FPGA = Field programmable Gate Array = vom Benutzer programmierbare Logikschaltung) ausgestattet sein können. Auf diese Zellen kann üblicherweise mittels eines JTAG-Protokolls zugegriffen werden, wobei jedoch auf Signale an schaltungsinternen Knoten nicht zugegriffen werden kann.
Ein weiteres klassisches Testverfahren ist die Verwendung eines sogenannten Scan-Pfads (Scan Path), der ein Setzen und Auslesen aller Register, die schaltungsintern in einem seriellen Pfad zusammengeschaltet sind, ermöglicht. Auch hier kann das JTAG-Protokoll Anwendung finden, wobei durch den seriellen JTAG-Zugriff ein Abtasten dieser Register in Echtzeit nicht realisierbar ist, ohne dass dafür der Betrieb des DUT angehalten werden muss.
Ein neuartiger Lösungsansatz zum Hardware-Debugging ist aus dem US-Patent 5 764 079 bekannt, das ein PLD (PLD = Programmable Logic Device = Programmierbarer Logikbaustein) lehrt, das die Fähigkeit liefert, innere Knoten zu beobachten, indem interne Knoten mit Schattenelementen versehen sind, die ein Auslesen der Zustände der inneren Knoten bzw. ein Laden derselben mit bestimmten Zuständen ermöglichen. Beim Auslesen der inneren Knoten werden dieselben in die Schattenelemente gekoppelt und über Schieberegister an Eingangs/Ausgangs-Anschlüssen verfügbar gemacht.
Das US-Patent 5 870 410 lehrt ein Schnittstellensystem beispielsweise für PLDs, wie sie in dem US-Patent 5 764 079 beschrieben sind. Das Schnittstellensystem soll dazu dienen, nicht nur die Zustände innerer Knoten zu beobachten, sondern ferner zu ermöglichen, die inneren Knoten mit Testvektoren zur Fehlerbeobachtung zu beaufschlagen.
Die oben genannten US-Patente liefern zwar die Möglichkeit, die internen Schaltungszustände eines PLDs auszulesen und somit mögliche Fehlerzustände zu erfassen, erlauben jedoch bei Erfassen eines Fehlers nicht die Zurückverfolgung, um die Ursache des Fehlers zu ermitteln. Um eine solche Ermitt lung von Fehlerursachen zu ermöglichen, bestand die einzige Möglichkeit bisher darin, eine aufwendige Rechnersimulation ausgehend von einem Anfangszustand des Betriebs der Schaltung, d.h. sozusagen einem Zeitpunkt Null, durchzuführen. Bei solchen Simulationen liegt ein Modell der zu testenden integrierten Schaltung beispielsweise als Gatternetzliste vor, wobei das Verhalten der Schaltung dann softwaremässig simuliert wird, indem definierte Eingangssignale zur Simulation verwendet werden.
Eine Simulation ist jedoch extrem zeitaufwendig, insbesondere wenn über einen sehr langen Zeitraum simuliert werden soll.
Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren und eine Vorrichtung zu schaffen, die eine zeitsparende Möglichkeit liefern, bestimmte in einer digitalen Logikschaltung auftretende Schaltungszustände hinsichtlich ihrer Ursachen zu analysieren.
Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 sowie eine Vorrichtung nach Anspruch 9 gelöst.
Die vorliegende Erfindung schafft ein Verfahren zur Fehleranalyse digitaler Logikschaltungen, die eine Mehrzahl interner Schaltungsknoten mit zugeordneten Nutzregistern, in denen Schaltungszustände der internen Schaltungsknoten, die von Eingangssignalen abhängen, gespeichert sind, aufweisen, wobei jedem Nutzregister ein Schattenregister, über das der Schaltungszustand des Nutzregisters ausgelesen werden kann, zugeordnet ist. Die Logikschaltung wird unter Anlegen von Eingangssignalen an dieselbe betrieben, wobei die angelegten Eingangssignale protokolliert werden.
Während des Betriebs der Logikschaltung werden die Schaltungszustände der internen Schaltungsknoten über die Schattenregister zyklisch ausgelesen, wobei die Schaltungszustände der internen Schaltungsknoten der Logikschaltung für jeden Zyklus gespeichert werden, um eine Schaltungszustandshistorie zu erzeugen. Beim Auftreten eines vorbestimmten Ereignisses wird der Betrieb der Logikschaltung angehalten, woraufhin ein Rücksprung in der Schaltungszustandshistorie um eine vorbestimmte Anzahl von Zyklen stattfindet. Basierend auf den für den Zyklus, zu dem zurückgesprungen wurde, gespeicherten Schaltungszuständen sowie den protokollierten Eingangssignalen wird nachfolgend eine Softwaresimulation des Betriebs der Logikschaltung durchgeführt.
Die vorliegende Erfindung basiert somit auf der Erkenntnis, dass es möglich ist, eine zeitsparende Fehlerursachenforschung zu realisieren, indem zyklisch sämtliche Schaltungszustände interner Schaltungsknoten einer digitalen Logikschaltung ausgelesen werden. Tritt ein vorbestimmtes Ereignis, vorzugsweise ein Fehlerzustand der digitalen Logikschaltung auf, wird der Betrieb der Logikschaltung angehalten und in der Schaltungszustandshistorie vorzugsweise so weit zurückgesprungen, dass die für den Zyklus, zu dem zurückgesprungen wurde, gespeicherten Schaltungszustände einen korrekten Betrieb der digitalen Logikschaltung anzeigen.
Somit ist es möglich, eine Softwaresimulation unter Verwendung des für diesen Zyklus gespeicherten Schaltungsdiagramms, wobei der Ausdruck Schaltungsdiagramm die für einen Zyklus gespeicherten Schaltungszustände sämtlicher interner Schaltungsknoten bezeichnen soll, und der protokollierten Eingangssignale zu beginnen, so dass die Softwaresimulation nicht quasi zu einem Zeitpunkt Null, d.h., von einem Beginn eines Schaltungsbetriebs der Logikschaltung an, begonnen werden muss.
Die Softwaresimulation wird ab dem Zyklus, zu dem zurückgesprungen wurde, auf der Grundlage der für diesen Zustand gespeicherten internen Schaltungszustände und der nach diesem Zyklus angelegten protokollierten Eingangssignalen durchgeführt. Somit ist es erfindungsgemäss möglich, einen Hardware-Debugger mit einer Softwaresimulation zu verknüpfen, um zeitsparend eine Fehlerursachenforschung zu betreiben.
Eine Vorrichtung zum Durchführen des erfindungsgemässen Verfahrens umfasst ein Schattenregister für jeden einer Mehrzahl interner Schaltungsknoten einer digitalen Logikschaltung, wobei jeder interne Schaltungsknoten ein Nutzregister aufweist, dessen Schaltungszustand, der von Eingangssignalen abhängt, über das zugeordnete Schattenregister ausgelesen werden kann. Ein Speicher zum Speichern einer Mehrzahl von Schaltungszustandsdiagrammen sowie zum Speichern der angelegten Eingangssignale ist vorgesehen. Ferner umfasst die Vorrichtung eine Steuerung, die mit dem Schattenregister und dem Speicher verbunden ist, um zyklisch Schaltungszustandsdiagramme in dem Speicher zu speichern. Schliesslich ist eine Schnittstelle vorgesehen, um zumindest ein Schaltungszustandsdiagramm zu einem Softwaresimulationsrechner zu übertragen.
Die protokollierten Eingangssignale können über spezifisch dafür vorgesehene Hardwarestrukturen erfasst, ebenfalls in dem Speicher gespeichert und durch die Steuerung zu dem Softwaresimulationsrechner übertragen werden. Alternativ können die protokollierten Eingangssignale beispielsweise über einen Logikanalysator oder dergleichen erfasst und durch denselben direkt zu dem Softwaresimulationsrechner übertragen werden.
Erfindungsgemäss können die Schaltungszustände für jeden Zyklus vorzugsweise in einem Speicher (RAM) gespeichert werden, der wiederum bevorzugt als ein Ringspeicher ausgestaltet ist. Bei bevorzugten Ausführungsbeispielen der vorliegenden Erfindung sind die Schattenregister ferner durch FIFO-Speicher (FIFO = zuerst hinein, zuerst heraus) gebildet, so dass zu jedem Auslesetakt des Schattenregisters ein Wert aus den Nutzregistern der digitalen Logikschaltung ausgelesen und der Steuerung zur Verfügung gestellt werden kann, so dass eine lückenlose Beobachtung der Schaltung möglich ist.
Die vorliegende Erfindung schafft einen Hardware-Debugger, der zyklisch die Schaltungszustände sämtlicher interner Knoten einer digitalen Logikschaltung ausliest, um bei Erfassen eines Fehlers der digitalen Logikschaltung, bei der es sich um eine beliebige digitale Logikschaltung, beispielsweise ein PLD oder ein FPGA oder dergleichen handeln kann, einem Simulationsrechner geeignete Daten zur Verfügung stellen zu können, die die Bestimmung des Grunds für den Fehler bzw. den Ausfall ermöglichen. Der Hardware-Debugger erlaubt dabei eine Echtzeitverarbeitung, d.h., dass die Erfassung der Schaltungszustände der internen Schaltungsknoten sowie eine Unterbrechung durchgeführt werden kann, während die integrierte Schaltung, d.h. die digitale Logikschaltung, und die Systemumgebung derselben in Echtzeit arbeiten.
Um diese Echtzeitanforderungen zu erfüllen, ist es notwendig, dass ein Hardware-Debugger vorgesehen ist.
Der bei der vorliegenden Erfindung verwendete Hardware-Debugger ist vorzugsweise in der Lage, drei unterschiedliche Modi durchzuführen, einen Verfolgungsmodus, einen Unterbrechungsmodus und einen Aktualisierungsmodus. Der Verfolgungsmodus ermöglicht das vom Betrieb der digitalen Logikschaltung unabhängige Abtasten und Speichern aller Schaltungszustände der internen Schaltungsknoten sowie das kontinuierliche Verfolgen und Speichern aller Eingangs/Ausgangs-Signale. Die abgetasteten Schaltungszustände beschreiben das interne Verhalten eines DUT, beispielsweise während eines Prototyperstellungs-Prozesses oder während eines In-System-Tests. Die Eingangs/Ausgangs-Signale beschreiben die korrespondierenden Umgebungsdaten.
Die erfassten Schaltungszustands- und Eingangssignal-Daten dienen dann, wie oben erläutert wurde, der späteren Analyse der Schaltungsfunktionalität, insbesondere der Rekonstruktion von Hardware-internen Zuständen des DUT in einer Simulationsumgebung. Rekonstruktion heisst dabei, dass das Simulationsmodell des DUT mit dem abgetasteten Schaltungszustand eines ausgewählten Zeitpunkts initialisiert wird. Als Stimuli für die Simulation dienen dann die abgetasteten Eingangssignaldaten. Somit ist es, wie oben erläutert wurde, für einen Benutzer nicht notwendig, sein Simulationsmodell langwierig an den zu betrachtenden Zeitpunkt "heranzusimulieren". Lediglich die für die Analyse notwendigen Zeit-intervalle müssen detailliert simuliert werden. Der Effekt ist eine drastische Reduktion der benötigten Simulationszeit.
Der Unterbrechungsmodus wird bei Auftreten bestimmter Unterbrechungsbedingungen, die frei spezifizierbare Zustände des DUT sind, betreten. Dabei existieren zum einen interne Unterbrechungsbedingungen, die einen internen Schaltungszu stand darstellen, der eine korrespondierende Aktion auslöst, beispielsweise einen internen Arithmetiküberlauf, und somit einen Fehlerzustand darstellt. Daneben können externe Unterbrechungsbedingungen vorgegeben sein, bei denen ausserhalb des DUT ein Zustand erreicht wird, der eine korrespondierende Aktion auslöst, wobei dieser Zustand beispielsweise durch fehlerhafte Ausgangswerte bedingt sein kann. Interne und externe Unterbrechungsbedingungen werden im Allgemeinen durch eine Zusatzhardware generiert.
Daneben kann eine weitere Unterbrechung des Hardware-Debuggings durch eine Benutzerintervention bewirkt werden, beispielsweise eine Beendigung des Hardware-Debuggings. Die beim Auftreten einer Unterbrechung durchgeführten Aktionen hängen vom Typ der Unterbrechung ab, wobei im Allgemeinen das DUT gestoppt und der Schaltungszustand gespeichert wird. In Abhängigkeit von der Schwere der aufgetretenen Unterbrechung kann nachfolgend der Betrieb fortgesetzt oder ein Rücksetzen durchgeführt werden. Der Unterbrechungsmodus kann parallel zum Verfolgungsmodus aktiviert werden.
Der Aktualisierungsmodus schliesslich ermöglicht es einem Benutzer, definierte interne Schaltungszustände in dem DUT zu erzeugen. Somit können Betriebszustände der Hardware provoziert werden, ohne dass die Hardware durch Eingangssignale in diesen Zustand gebracht werden muss. Dieser Modus kann dazu dienen, Grenzfälle von Betriebszuständen effektiv zu testen oder um nicht wieder oder nur schwer rekonstruierbare Hardware-Zustände für Testzwecke einstellen zu können.
Ein Hardware-Debugger, der die obigen Betriebsmodi ermöglicht, besteht bei bevorzugten Ausführungsbeispielen der vorliegenden Erfindung aus einem Schattenregister für jeden internen Schaltungsknoten des DUT, aus einem Speicher zum Speichern einer Mehrzahl von Schaltungszustands- diagrammen, die jeweils bestimmten Zeitpunkten zugeordnet sind, sowie einer Steuerung, die das zyklische Speichern der Schaltungszustandsdiagramme und das Auslesen derselben zu einem Simulationsrechner ermöglicht. Ein solcher Hardware-Debugger ermöglicht eine Echtzeit-Verfolgung der internen Schaltungszustände ohne eine unbeabsichtigte Rückwirkung auf das DUT.
Ferner ist der Hardware-Debugger ohne Berücksichtigung technologiespezifischer Schaltungsvarianten auf alle üblichen Schaltkreistechnologien anwendbar. Der Hardware-Debugger ist vorzugsweise über einen Rechner steuerbar, wobei in dem Rechner die Aufbereitung der Verfolgungs- und Aktualisierungs-Daten sowie die Beschreibung der Unterbrechungsbedingungen erfolgt.
Die nach dem Auftreten einer Unterbrechungsbedingung auf der Grundlage der im Verfolgungsmodus erfassten Schaltungszustände und Eingangsdaten durchgeführte Simulation erfolgt vorzugsweise auf der Grundlage eines Schaltungsmodells, das als Gatternetzliste vorliegt. Somit entfällt die Notwendigkeit, die durch das Hardware-Debugging gewonnenen Daten aus der Gatterebene in die Register-Transfer-Ebene zu transformieren.
Die vorliegende Erfindung ermöglicht somit eine zeitsparende Fehleranalyse, um die Ursache von in digitalen Logikschaltungen auftretenden Fehlern herauszufinden. Die vorliegende Erfindung ermöglicht das Herausfinden von Fehlerursachen auch dann, wenn die Systemumgebung unterschiedliche Stimuli für jede Wiederholung eines Hardware-Fehleranalyseverfahrens liefert. Gemäss der vorliegenden Erfindung muss der Benutzer nämlich nicht inkremental eine Fehleranalyse wiederholen, um die Fehlerursache einzukreisen, sondern kann die Fehlerursachenforschung durch das zyklische Abtasten und Speichern aller relevanten Daten, während der ersten Ausführung, bei der der Fehler auftritt, mittels einer Softwaresimulation, die nicht vom Zeitpunkt Null aus erfolgen muss, realisieren.
Die Grenzen dieses Verfahrens des zyklischen Abtastens der relevanten Daten bestehen lediglich in der begrenzten Abtastrate, die technologieabhängig ist, sowie in einem möglicherweise nach oben begrenzten Speicherraum für die grosse Anzahl von Signalen bei grossen Logikschaltungsentwürfen bzw. langen Echtzeitläufen. In diesem Fall ermöglicht es die vorliegende Erfindung, die Ursache eines auch nur einmal auftretenden Fehlers herauszufinden, indem eine Softwaresimulation basierend auf einem gespeicherten Schaltungszustandsdiagramm, das zu einem Zeitpunkt aufgenommen wurde, der dem Auftreten des Fehlers unmittelbar zeitlich vorhergeht, durchgeführt wird. Somit muss der Benutzer nicht auf ein nochmaliges Auftreten des Fehlers hoffen, was in vielen Fällen aufgrund der fehlenden Reproduzierbarkeit der Fehler erfolglos ist.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend, bezugnehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen: Fig. 1 ein schematisches Diagramm zur Erläuterung der vorliegenden Erfindung; Fig. 2a bis 2d schematische Darstellungen unterschiedlicher Ausführungsbeispiele von Vorrichtungen zur Durchführung des erfindungsgemässen Verfahrens; Fig. 3 eine schematische Darstellung einer Nutzregisterzelle; Fig. 4 eine schematische Darstellung eines Schaltungsknotes aus einer mit einem Schattenregister versehenen Nutzregisterzelle gemäss der vorliegenden Erfindung; Fig. 5 eine Tabelle zur Veranschaulichung des Betriebs des in Fig. 4 gezeigten Schaltungsknotens; Fig. 6 eine schematische Darstellung zur Veranschaulichung von in einer Abtastkette oder einem Abtastweg verschalteten Schattenregistern;
Fig. 7 eine schematische Darstellung zur Veranschaulichung eines Ausführungsbeispiels eines Schaltungsabschnitts zur Erzeugung einer Unterbrechungsbedingung; Fig. 8 eine schematische Darstellung zur Veranschaulichung eines bevorzugten Ausführungsbeispiels zum Schieben und Auslesen einer Abtastkette; und Fig. 9 eine schematische Darstellung eines Schaltungskno tens, bei dem ein Nutzregister mit einem Schattenregister, das durch einen FIFO-Speicher realisiert ist, versehen ist.
Bezugnehmend auf Fig. 1 wird nun ein bevorzugtes Ausführungsbeispiel des erfindungsgemässen Verfahrens zur Fehleranalyse näher erläutert. Die obere in Fig. 1 dargestellte Achse ist eine Echtzeitachse, während die untere Achse eine virtuelle Simulationszeit darstellt. Erfindungsgemäss wird ein DUT 2 in Echtzeit unter Anlegen von Eingangssignalen 4, die den Einfluss einer Systemumgebung auf das DUT 2 darstellen können, betrieben. Während des Betriebs des DUT 2, das beispielsweise ein FPGA oder ein PLD sein kann, werden erfindungsgemäss die Schaltungszustände aller internen Schaltungsknoten des DUT 2 zyklisch durch einen Hardware-Debugger 6 ausgelesen, was durch einen Pfeil 8 in Fig. 1 angedeutet ist. Der Hardware-Debugger 6 ist über eine Debugger-Schnittstelle 9 mit dem DUT 2 verbunden.
Obwohl der Hardware-Debugger 6 und das DUT 2 in Fig. 1 als durch eine Schnittstelle 9 getrennt dargestellt sind, ist ein Teil des Hardware-Debuggers 6, nämlich zumindest jeweilige Schattenregister desselben, in der integrierten Schaltung, die das DUT 2 darstellt, enthalten. Das Betreiben der Logikschaltung, beispielsweise zum Durchführen eines Prototyp-Testens oder eines In-System-Testens wird während des Hardware-Debuggens fortgesetzt, bis zu einem Zeitpunkt t 1 ein Fehlerzustand 10 in dem DUT 2 auftritt. Dieser Fehlerzustand 10 stellt eine Unterbrechungsbedingung dar.
Beim Auftreten einer solchen Unterbrechungsbedingung 10 wird, basierend auf den durch den Hardware-Debugger 6 zyklisch ausgelesenen Schaltungszuständen sowie auf den, an das DUT 2 angelegten, Eingangssignalen 4 eine Softwaresimulation durchgeführt, um die dem Fehlerzustand 10 zugrundeliegende Ursache zu erforschen. Die Übergabe der oben genannten Daten ist in Fig. 1 schematisch durch einen Pfeil 12 dargestellt. An dieser Stelle sei angemerkt, dass die in Fig. 1 oberhalb des Pfeils 12 dargestellten Verfahrensabläufe als eine Echtzeitumgebung zu betrachten sind, während die unterhalb des Pfeils 12 dargestellte Zeitachse eine virtuelle Simulations zeit darstellt.
Wie in Fig. 1 zu erkennen ist, wird zur Simulation, um die Fehlerursache herauszufinden, von dem Zeitpunkt t 1 zu einem Zeitpunkt t 2 zurückgesprungen, um zu diesem Zeitpunkt t 2 die Simulation zu beginnen. Das Rücksprungintervall wird vorzugsweise derart gewählt, dass das zum Zeitpunkt t 2 gespeicherte Schaltungszustandsdiagramm einen ordnungsgemässen Betrieb des DUT anzeigt. Dadurch ergibt sich ein Softwaresimulationsintervall 14 zur Fehlerursachenanalyse, das zum Zeitpunkt t 2 beginnt. Somit kann erfindungsgemäss der Zeitverbrauch für das Fehlerursachenanalyseverfahren, das beginnt, nachdem ein Fehlerzustand 10 erfasst wurde, erheblich verkürzt werden.
Wie durch den Pfeil 12 schematisch dargestellt ist, werden die zyklisch ausgelesenen Daten für eine folgende Analyse des Schaltungsverhaltens verwendet, wobei die Hardware-internen Zustände das interne Verhalten des DUT 2 beschreiben, während die Eingangssignale 4 die entsprechenden Umgebungsdaten darstellen, die zu dem beobachteten Verhalten führen.
An dieser Stelle sei angemerkt, dass das Rücksprungintervall von dem Zeitpunkt t 1 zu dem Zeitpunkt t 2 vorzugsweise derart gewählt ist, dass mit Sicherheit davon ausgegangen werden kann, dass die Schaltung bis zum Zeitpunkt t 2 korrekt gearbeitet hat. Um dies zu verifizieren, kann eine Überprüfung durchgeführt werden. Sollte diese ergeben, dass zum Rücksprungzeitpunkt die Schaltung nicht mehr korrekt gearbeitet hat, kann nach dem Rücksprung auf den Zeitpunkt t 2 ein weiterer zeitlicher Rücksprung erfolgen, um sicherzustellen, dass zu Beginn der Softwaresimulation das DUT ordnungsgemäss gearbeitet hat.
Die Softwaresimulation, die die Fehlerursachenanalyse liefert, wird vorzugsweise unter Verwendung einer Simulationsumgebung für das Gatter-Modell erreicht, so dass das Simulationsmodell des DUT ohne weiteres mit einem Satz von Daten, die ein abgetastetes Schaltungszustandsdiagramm darstellen, initialisiert werden kann. Dieses abgetastete Schaltungszustandsdiagramm ist dem Zeitpunkt t 2 zugeordnet. Somit muss erfindungsgemäss die Simulation nicht zum Zeitpunkt 0 beginnen. Vielmehr beginnt die Simulation zum Zeitpunkt t 2 , indem das Simulationsmodell mit dem zu diesem Zeitpunkt ausgelesenen Schaltungszustandsdiagramm initialisiert wird, und indem die abgetasteten Eingangssignale als Stimuli für die Gatterebenen-Simulation verwendet werden.
Somit muss erfindungsgemäss nurmehr das Intervall zwischen dem Initialisierungszeitpunkt t 2 und dem Fehlerzeitpunkt t 1 simuliert werden, was eine drastische Zeiteinsparung gegenüber bekannten Simulationsverfahren liefert.
Überdies ist es erfindungsgemäss bevorzugt, dass der Zustand des DUT 2 über den Hardware-Debugger 6 voreingestellt werden kann, ohne hierzu eine Sequenz von externen Stimuli zu benötigen. Dies kann durch die gemäss der vorliegenden Erfindung verwendeten Schattenregister realisiert werden, insbesondere um extreme Betriebsbedingungen wirksam zu testen oder um DUT-Zustände zu Testzwecken einzustellen, die durch externe Stimuli schwer erreicht werden können, beispielsweise um die Fähigkeit von Zustandsmaschinen zu überprüfen, aus unerlaubten Zuständen heraus in endlicher Zeit erlaubte Zustände zu erreichen. PAR>Nachdem nunmehr allgemein das erfindungsgemässe Verfahren erläutert wurde, werden im Folgenden Ausführungsbeispiele für Vorrichtungen zum Durchführen des erfindungsgemässen Verfahrens beschrieben.
In Fig. 2 ist ein erstes Ausführungsbeispiel einer erfindungsgemässen Vorrichtung gezeigt, wobei ein DUT 2 dargestellt ist, das Komponenten 20 des Hardware-Debuggers der erfindungsgemässen Vorrichtung enthält. Die Komponenten 20 beziehen sich auf die Komponenten des Hardware-Debuggers, die in der integrierten Schaltung der DUT 2 angeordnet sind, nämlich Schattenregister und optional Einrichtungen zum Erfassen der Eingabesignale 4 von einer Systemumgebung 22 sowie Einrichtungen zum Erfassen der Ausgangssignale von dem DUT 2, beispielsweise um basierend darauf Unterbrechungsbedingungen zu bestimmen.
Die DUT-internen Elemente 20 des Hardware-Debuggers sind über eine Schnittstelle 24 mit einer Hardware-Debugger-Steuerung 26 verbunden, die den Betrieb des Hardware-Debuggers steuert und ausgelesene und erfasste Daten in einem Speicher 28, vorzugsweise einem RAM, speichert. Die Hardware-Debugger-Steuerung ist ferner über eine Schnittstelle 30 mit einem Computer 32 verbunden, auf dem die Softwaresimulation auf der Grundlage der von der Steuerung 26 gelieferten Daten durchgeführt wird, wobei diese Daten über die Schnittstelle 30 zu dem Computer 32 geliefert werden. Bei dem in Fig. 2a dargestellten Ausführungsbeispiel stellt die Verbindung zwischen DUT-internem Anteil 20 des Debuggers und der Steuerung 26, nämlich die Schnittstelle 24, die zeitkritische Verbindung dar.
Bei dem in Fig. 2b dargestellten Ausführungsbeispiel ist die Hardware-Debugger-Steuerung in zwei Teile unterteilt, ein in der integrierten Schaltung 34 des DUT 2 befindliches Kernelement 36 und ein ausserhalb befindliches Steuerelement 26'. Bei diesem Ausführungsbeispiel befindet sich der Kern 36 der Funktionalität der Debugger-Steuerung in der Schaltung 34, in der auch das DUT 2 realisiert ist, so dass die zeitkritische Verbindung, in Fig. 2b mit dem Bezugszeichen 38 bezeichnet, hier kürzer realisiert sein kann, so dass sich kürzere Signallaufzeiten ergeben, was höhere Abtastfrequenzen ermöglicht.
Das dargestellte Hardware-Debugger-Kernelement 36 ist eine DUT-unabhängige Zustandsmaschine, um die Kommunikation zwischen der Debugger-Steuerung 26' und den DUT-internen Debugger-Komponenten 20 zu steuern. Dabei muss das Debugger-Kernelement das Übertragen von Daten zu den Schattenelementen, die Unterbrechungserfassung und eine mögliche Benutzerintervention über die Debugger-Schnittstelle 24' zu der Debugger-Steuerung 26' steuern. Das Lesen der Schattenregister ist zeitkritisch, wobei das Kernelement 36 den Schiebetakt für als Schiebekette verschaltete Schattenelemente liefert und ein oder mehrere Schiebeketten auslesen muss. Die Zeit, die für diese Aktion benötigt wird, bestimmt im Wesentlichen die Abtastperiode.
Daher ist das Auslesen von Schattenregisterketten und das Beschreiben des RAM 28 vorzugsweise als eine Pipelinestruktur so parallel wie möglich organisiert. Im Gegensatz dazu ist das Beschreiben der Schattenregister während des Debugger-Aktualisierungsmodus weniger zeitkri tisch, da in diesem Modus das DUT üblicherweise in einem Wartezustand ist. Ein weiterer Vorteil dessen, das Kernelement 36 in der integrierten Schaltung des DUT anzuordnen, liegt darin, dass es ermöglicht, interne Unterbrechungen schnellstmöglich zu erfassen. Alternativ zu dem in Fig. 2a dargestellten Ausführungsbeispiel kann das Kernelement 36 der Debugger-Steuerung auch über eine direkte Schnittstelle mit dem externen RAM 28 verbunden sein.
Das in Fig. 2c gezeigte Ausführungsbeispiel unterscheidet sich von dem in Fig. 2b gezeigten dadurch, dass nunmehr die gesamte Debugger-Steuerung 26 zusammen mit dem RAM 28 in der integrierten Schaltung 34 des DUT 2 eingebettet ist. Dieses Ausführungsbeispiel stellt somit eine kompakte Lösung für einen In-System-Test mit maximaler Abtastfrequenz dar. Nachteilig ist jedoch der erhebliche zusätzliche Schaltungsaufwand und die für den RAM verbrauchte Chipfläche für das DUT. Ferner ist hierbei anzumerken, dass der On-Chip-RAM 28, wie er in Fig. 2c gezeigt ist, üblicherweise eine geringere Speicherkapazität besitzt als ein externer RAM.
In Fig. 2d ist schematisch eine Möglichkeit dargestellt, um den Eingabevektor zu dem DUT 2, d.h. die Eingangssignale 4 zu denselben, kontinuierlich zu überwachen, um diese Eingangssignale einem Rechner zur Verwendung als Stimuli für die Simulation zur Verfügung zu stellen. Zu veranschaulichenden Zwecken erfolgt gemäss Fig. 2d die Erfassung der Eingangssignale 4 über einen Logikanalysator 40, der mit den Eingangsanschlüssen des DUT 2 sowie dem Rechner 32 verbunden ist. Es sei jedoch angemerkt, dass die Eingangssignale zu dem DUT 2 auch auf andere Art und Weise erfasst werden können, beispielsweise durch entsprechende Hardwarekomponenten in der integrierten Schaltung des DUT, so dass die Eingangssignale durch die Debugger-Steuerung erfasst werden können.
Bezugnehmend auf die Fig. 3 bis 5 erfolgt nun eine Beschreibung bevorzugter Ausführungsbeispiele der Komponenten des Hardware-Debuggers, die in der integrierten Schaltung des DUT angeordnet sind.
In Fig. 3 ist ein Nutzregister 50 gezeigt, das in einer digitalen Logikschaltung dazu dient, einen Schaltungszustand eines internen Schaltungsknotens zu definieren. Das Nutzregister 50 ist bei dem dargestellten Ausführungsbeispiel ein D-Flip-Flop mit einem Dateneingang 1D, einem Aktivierungseingang 1E und einem Takteingang C1. An dem Dateneingang 1D liegt ein Datensignal d an, an dem Aktivierungseingang 1E liegt ein Aktivierungssignal en an, während an dem Takteingang C1 ein Nutztakt clk anliegt. Das Flip-Flop 50 besitzt einen Datenausgang q und einen invertierten Datenausgang qb.
Fig. 4 zeigt einen internen Systemknoten einer digitalen Logikschaltung, bei dem dem internen Nutzregister 50 ein Schattenregister 60, das vorzugsweise den gleichen Aufbau wie das Nutz- oder Daten-Register 50 aufweist, zugeordnet ist. Das Nutzregister 50 und das Schattenregister 60 sind über zwei Demultiplexer 62 und 64, ein UND-Gatter 66 und ein ODER-Gatter 68 derart verschaltet, dass eine normale Funktion des Nutzregisters 50, ein Abtasten des Schattenregisters 60, ein Aktualisieren des Inhalts des Nutzregisters 50 über das Schattenregister oder eine Übernahme des Inhalts des Nutzregisters 50 in das Schattenregister 60 möglich ist.
Zu diesem Zweck ist ein Steuersignal upd, das einen Aktualisierungsmodus anzeigt, mit einem Eingang des ODER-Gatters 68 und dem Steuereingang des Demultiplexers 62 verbunden. Der Ausgang des Demultiplexers 62 ist mit dem Dateneingang 1D des Nutzregisters verbunden. An einem Eingang des Demultiplexers 62 liegt das Dateneingangssignal d an, während der andere Eingang des Demultiplexers 62 mit dem Ausgang des Schattenregisters 60 verbunden ist. Der zweite Eingang des ODER-Gatters 68 ist mit dem Ausgang des UND-Gatters 66 verbunden, an dessen Eingängen das Datenregisteraktivierungssignal en und ein Datenregister-Chip-Aktivierungssignal ce anliegen. An dem Takteingang C1 des Nutzregisters 50 liegt der Nutztakt clk an.
Der Ausgang des Nutzregisters 50 ist mit einem Eingang des Demultiplexers 64 verbunden, während der andere Eingang des Demultiplexers 64 mit einem Schattenregister-Scan-Pfad-Eingang si verbunden ist. Der Demultiplexer 64 wird durch ein Auslesemodussignal cpt gesteuert, wobei der Ausgang des Demultiplexers 64 mit dem Dateneingang 1D des Schattenregisters 60 verbunden ist. Am Aktivierungseingang 1E des Schattenregisters 60 liegt ein Schattenregister-Aktivierungssignal se an, während an dem Takt- eingang C1 desselben ein Schattenregister-Taktsignal sclk anliegt. Der Ausgang des Schattenregisters 60 bildet den Schattenregisterabtastausgang, so dass das Schattenregister über den Eingang si und den Ausgang so in einen Scan-Pfad geschaltet werden kann.
Hinsichtlich der Betriebsweise der in Fig. 4 dargestellten Schaltung sei auf die in Fig. 5 gezeigte Tabelle verwiesen, in der die jeweilige Belegung der Eingänge und der Ausgänge in den jeweiligen Betriebsmodi dargelegt ist.
Lediglich erläuternd sei erwähnt, dass während des normalen Betriebs des Nutzregisters 50 das Aktualisierungssignal upd inaktiv, d.h. 0 ist, so dass über den Demultiplexer 62 das Datensignal d am Dateneingang 1D des Nutzregisters 50 anliegt. Während des Abtastmodus ist aus Auslesesignal cpt deaktiv, d.h. 0, so dass das Signal am Schattenregister-Scan-Pfadeingang si an den Dateneingang 1D des Schattenregisters 60 angelegt ist. Im Aktualisierungsmodus ist das Aktualisierungssignal upd aktiv, d.h. 1, so dass über den Demultiplexer 62 das Ausgangssignal des Schattenregisters 60 an den Dateneingang 1D des Nutzregisters 50 angelegt wird, so dass der Inhalt des Schattenregisters 60 in das Nutzregister 50 übernommen werden kann.
Im Auslesemodus ist das Auslesesignal cpt aktiv, d.h. 1, so dass über den Demultiplexer 64 der Inhalt des Nutzregisters 50 in das Schattenregister 60 übernommen werden kann.
Obwohl oben bezugnehmend auf Fig. 4 ein spezifisches Ausführungsbeispiel für die Verschaltung von Nutzregister und Schattenregister dargestellt ist, ist es klar, dass Nutz- und Schattenregister in einer unterschiedlichen Weise verrschaltet sein können, um die erläuterte Funktionalität zu liefern. In gleicher Weise muss das Schattenregister nicht durch ein zu dem Datenregister identisches Element gebildet sein, sondern kann ein in abweichender Weise ausgestaltetes Regi sterelement sein.
In Fig. 6 ist die Verschaltung einer Mehrzahl von in Fig. 4 gezeigten Schattenregistern in einen Abtastweg zum Bilden einer Schiebekette dargestellt. Die Bezugszeichen 100, 102, 104 und 106 bezeichnen dabei jeweils eine Schaltungsstruktur, die einen internen Schaltungsknoten einer digitalen Logikschaltung darstellt. Dabei sind in den Fig. 4 und 6 gleiche Signale gleich bezeichnet, wobei in Fig. 6 lediglich der äusserste linke Schaltungsknoten mit den Bezugszeichen von Fig. 4 bezeichnet ist. Wie in Fig. 6 zu erkennen ist, ist jeweils der Scan-Pfad-Eingang si eines jeweiligen Schattenregisters mit dem Scan-Pfad-Ausgang so eines vorhergehenden Schattenregisters verbunden, so dass die Schattenregister in Form einer Schiebekette ausgelesen werden können.
Die Signale clk, upd, ce, cpt, se und sclk sind in der dargestellten Weise über gemeinsame Leitungen anlegbar, um eine Abtastkette zu realisieren.
Wie oben bezugnehmend auf Fig. 1 erläutert wurde, findet erfindungsgemäss eine Softwaresimulation bei Auftreten einer Unterbrechungsbedingung statt. Unterbrechungen können dabei auf unterschiedliche Arten erfasst werden. Zum einen können komplexe Unterbrechungsbedingungen existieren, bei denen beispielsweise ein erfasstes Schaltungszustandsdiagramm mit einem erwarteten vorgegebenen Schaltungszustandsdiagramm verglichen wird, wobei bei fehlender Übereinstimmung beurteilt wird, dass eine Unterbrechungsbedingung vorliegt. Daneben können Unterbrechungsbedingungen auf Gatterebene vorgesehen sein, welche vorbestimmte Zellen sind, die automatisch in die DUT-Gatterebenenbeschreibung eingebracht werden. Hierbei werden nur einzelne Knoten oder Vektoren überwacht, wobei eine beispielhafte Unterbrechungszelle für eine solche Überwachung in Fig. 7 dargestellt ist.
Eine Leitung 80 stellt dabei einen zu überwachenden Knoten dar und ist mit einem Eingang eines Komparators 82 verbunden. Ein zweiter Eingang des Komparators 82 ist mit einer Einrichtung 84, die einen Vergleichswert liefert, verbunden. Der Referenz- oder Vergleichs-Wert für den Komparator 82 kann über einen getrennten Unterbrechungszellen-Scan-Pfad 86 eingestellt werden. Dabei ist ein Vergleichswert immer nur dann gültig, wenn ein einzelnes Freigabebit "enable" (Fig. 7) gesetzt ist. Somit kann der Benutzer die Funktionalität des Komparators ein- und ausschalten. Der Ausgang des Komparators 82 kann beispielsweise das Datenregister-Chip-Aktivierungssignal ce sein, so dass der Normalbetrieb des DUT eingestellt wird, falls der Vergleich in dem Komparator 82 keine Übereinstimmung ergibt und somit eine Unterbrechungsbedingung bestimmt wird.
Wie oben angeführt wurde, erfolgt die Speicherung der im Verfolgungsmodus aufgenommenen Daten, d.h. der Schaltungszustandsdiagramme oder optional zusätzlich der Eingangssignale, üblicherweise in externen oder internen RAM-Bereichen. Die Grösse der eingesetzten RAM-Bereiche bestimmt die Anzahl der speicherbaren Zustandsvektoren, d.h. die History-Tiefe der erzeugten Schaltungszustandshistorie. Bei praktisch relevanten Schaltungen, d.h. mehreren tausend Flip-Flops und einem Echtzeit-Debugging im Sekundenbereich, ist es technisch unmöglich, alle aufgetretenen Zustandsvektoren zwischen- zuspeichern. Bei bevorzugten Ausführungsbeispielen der vorliegenden Erfindung wird daher der RAM-Speicher als ein Ringpuffer organisiert, bei dem immer die letzten n Zustandsvektoren für eine Auswertung zur Verfügung stehen, so dass sich eine History-Tiefe von n ergibt.
Im Gegensatz zum Auslesen der Schattenregister ist das Initialisieren des DUT mit Aktualisierungsdaten nicht zeitkritisch, so dass die Aktualisierungsvektoren auf dem Host-Computer gehalten werden können. Der jeweils aktuelle Vektor kann dann beispielsweise über eine JTAG-Schnittstelle direkt in das DUT oder zweckmässigerweise in den RAM geladen werden, wobei nachfolgend in Umkehrung zu dem Verfolgungsmodus die RAM-Bereiche in die korrespondierenden Register kopiert werden. Die RAM- Grösse ist hierbei unkritisch, da jeweils nur ein Aktualisierungsvektor zwischengespeichert werden muss.
Bezüglich der Takte, mit denen die Nutzregister und die Schattenregister betrieben werden (siehe clk und sclk in Fig. 4) ist anzumerken, dass diese mit identischem oder un terschiedlichem Takt betrieben werden können. Werden die Schattenregister mit einem höherfrequenten Takt betrieben als die Datenregister, ist es notwendig, dass der Takt sclk der Schattenregister eine mindestens dreifach höhere Frequenz aufweist als der Takt clk der Datenregister. Die Verwendung eines solchen höheren Schattenregistertakts ist vorteilhaft, wenn lange Schiebeketten verwendet werden. Alternativ können sowohl Nutzregister als auch Schattenregister taktsynchron zueinander betrieben werden, was vorzugsweise bei hohen DUT-Frequenzen realisiert wird. Dabei ist anzumerken, dass geringe Schiebefrequenzen durch, eine Parallelisierung der Abtastwege kompensiert werden können.
Die Abtastfrequenz für die Zustandsvektoren im Verfolgungsmodus wird durch die Länge des Zustandsvektors und die Länge des Schreibzyklus für den Verfolgungs-RAM begrenzt. Für eine maximale Abtastfrequenz sollte das Schieben der Schattenregister im Sinne einer Pipelineverarbeitung im Schatten des Write-Zyklus erfolgen, wie es in Fig. 8 dargestellt ist, so dass jeweils während des Schiebens eines nachfolgenden Zyklus n+i die Daten für den vorhergehenden Zyklus n geschrieben werden. Somit entsteht kein weiterer Zeitverlust. Um ein genügend schnelles Schieben zu sichern, muss entweder die Schiebefrequenz entsprechend hoch sein oder die Schattenregister müssen in mehrere Abtastgruppen gruppiert werden. Alternativ ist es möglich, die Schattenregister durch FIFO-Speicher zu realisieren, so dass zwischen zwei Abtastpunkten jeweils nur ein Taktabstand vorliegen muss.
Mit anderen Worten heisst das, dass zu jedem Schattenregistertakt sclk ein Wert aus der Schaltung ausgelesen und der Hardware-Debugger-Steuerung zur Verfügung gestellt werden kann, so dass eine lückenlose Beobachtung der Schaltung möglich ist.
Ein Ausführungsbeispiel einer derartigen Realisierung ist in Fig. 9 gezeigt, in der gleiche Elemente wie in Fig. 4 mit gleichen Bezugszeichen versehen sind. Hier sind, um eine FIFO-Tiefe von drei zu realisieren, zwei FIFO-Register 200 und 202, die durch clk getaktet werden, zwischen den Datenausgang q des Nutzregisters 50 und den einen Eingang des Demultiplexers 64 geschaltet. Die FIFO-Register 200 und 202 werden über ein Signal FIFO-cpt gesteuert, d.h. aktiviert. Durch die FIFO-Register 200 und 202 ist es möglich, parallel zum Auslesen der Schiebekette bereits neue Abtastwerte aus dem Nutzregister zwischenzuspeichern. Diese Abtastwerte können auch zusammenhängend sein, wobei die maximale Anzahl zusammenhängender Abtastwerte die FIFO-Tiefe, im dargestellten Ausführungsbeispiel drei, nicht überschreiten darf.
Dies kann durch ein Steuerwerk im Hardware-Debugger, d.h. beispielsweise die Steuerung 26 in Fig. 2a, sichergestellt werden. Dadurch kann ein FIFO-Überlauf verhindert werden, der immer dann auftreten würde, wenn mehr Abtastwerte in die FIFO hineingeschrieben werden, als über die Schiebekette aus Schattenregistern herausgelesen werden können.
Wie bereits oben erwähnt wurde, ist für eine nachgelagerte Analyse des DUT-Verhaltens beim Hardware-Test die Aufzeichnung aller Eingangsdaten notwendig. Diese Eingangsdaten können beispielsweise durch herkömmliche Logikanalysatoren oder durch Spezialhardware aufgezeichnet werden, wobei die jeweilige Realisierung von solchen Faktoren, wie z.B. der benötigten Abtastrate, der Breite des Eingangssignalvektors und der History-Tiefe sowie der zur Verfügung stehenden kommerziellen Hardware abhängen wird.
The present invention relates to a method and apparatus for error analysis of digital logic circuits, and more particularly to such methods and apparatus that utilize hardware debugging to provide real-time error detection and analysis of a digital logic circuit enable.
A number of hardware debugging methods based on different approaches are known in the art. In one known method, the hardware behavior of an integrated circuit is monitored using logic analyzers or oscilloscopes connected to real integrated circuit pins. The pins are unused pins which are connected to internal nodes of the integrated circuit for error analysis purposes only. Due to the limited number of pins not used as payload pins, only a small set of signals originating from internal nodes can be observed by this technique.
In order to increase the number of probes possible, it is known to multiplex the pins or to use virtual probes, but this usually prevents real time fault diagnostics.
Other approaches use an environment that connects the hardware to software instead of the logic analyzer or oscilloscope to monitor the device under test (DUT). The software environment running on a computer is connected to the DUT via a computer interface, but due to the rather slow computer interface, real-time error analysis is usually not possible.
Another known method is error analysis using special input / output cells of an ASIC (Boundary Scan Cells), with which FPGAs (FPGA = Field Programmable Gate Array) can be equipped. These cells can usually be accessed by means of a JTAG protocol, but signals at in-circuit nodes can not be accessed.
Another classic test method is the use of a so-called scan path, which allows setting and reading out of all registers, which are interconnected in-circuit in a serial path. The JTAG protocol can also be used here, whereby the serial JTAG access makes it impossible to scan these registers in real time without the DUT having to be stopped for this purpose.
A novel approach to hardware debugging is known from US Patent 5,764,079, which teaches a PLD (Programmable Logic Device) that provides the ability to observe internal nodes by providing internal nodes with shadowing elements which read out the states of the inner nodes or allow loading them with certain states. When reading out the inner nodes, they are coupled into the shadow elements and made available via shift registers at input / output ports.
U.S. Patent 5,870,410 teaches an interface system, for example, for PLDs as described in U.S. Patent 5,764,079. The interface system is intended to not only observe the states of inner nodes, but also to allow the inner nodes to be fed test vectors for error observation.
While the above-referenced US patents provide the ability to read the internal circuit states of a PLD and thus detect possible fault conditions, they do not allow traceability to detect the cause of the fault when an error is detected. In order to enable such Ermitt ment of causes of error, the only option so far was a complex computer simulation starting from an initial state of the operation of the circuit, d. H. a time zero, so to speak. In such simulations, a model of the integrated circuit to be tested is present, for example, as a gate network list, wherein the behavior of the circuit is then simulated in software by using defined input signals for the simulation.
However, a simulation is extremely time consuming, especially if simulated over a very long period of time.
The object of the present invention is to provide a method and a device which provide a time-saving possibility to analyze with regard to their causes certain circuit states occurring in a digital logic circuit.
This object is achieved by a method according to claim 1 and an apparatus according to claim 9.
The present invention provides a method of error analysis of digital logic circuits having a plurality of internal circuit nodes with associated payload registers in which circuit states of the internal circuit nodes depending on input signals are stored, each register having a shadow register for reading out the circuit state of the payload register can be assigned. The logic circuit is operated by applying input signals to the same, with the applied input signals being logged.
During operation of the logic circuit, the circuit states of the internal circuit nodes are cyclically read out via the shadow registers, wherein the circuit states of the internal circuit nodes of the logic circuit are stored for each cycle to generate a circuit state history. Upon the occurrence of a predetermined event, the operation of the logic circuit is stopped, whereupon a return in the circuit state history occurs by a predetermined number of cycles. Based on the circuit states stored for the cycle that has been jumped back to and the logged input signals, a software simulation of the operation of the logic circuit is subsequently performed.
The present invention is thus based on the recognition that it is possible to realize a time-saving failure cause research by cyclically reading out all the circuit states of internal circuit nodes of a digital logic circuit. When a predetermined event, preferably an error condition, of the digital logic circuit occurs, the operation of the logic circuit is halted and preferably returned to the circuit state history such that the circuit states stored for the cycle to which it has returned indicate correct operation of the digital logic circuit.
Thus, it is possible to start a software simulation using the circuit diagram stored for this cycle, the term circuit diagram to designate the circuit states of all internal circuit nodes stored for one cycle, and the logged input signals, so that the software simulation is not quasi zero at a time, d. H. , from a beginning of a circuit operation of the logic circuit, must be started.
The software simulation is performed from the cycle that was returned to, based on the internal circuit states stored for that state and the logged input signals applied after that cycle. Thus, it is possible according to the invention to combine a hardware debugger with a software simulation in order to save time and to conduct a cause of fault research.
An apparatus for carrying out the method according to the invention comprises a shadow register for each of a plurality of internal circuit nodes of a digital logic circuit, each internal circuit node having a user register whose circuit state, which depends on input signals, can be read out via the associated shadow register. A memory for storing a plurality of circuit state diagrams and for storing the applied input signals is provided. Further, the apparatus includes a controller connected to the shadow register and the memory for cyclically storing circuit state diagrams in the memory. Finally, an interface is provided for transmitting at least one circuit state diagram to a software simulation computer.
The logged input signals can be detected via dedicated hardware structures, also stored in the memory and transferred by the controller to the software simulation computer. Alternatively, the logged input signals may be detected, for example, via a logic analyzer or the like, and transmitted by the same directly to the software simulation computer.
According to the invention, the circuit states for each cycle can preferably be stored in a memory (RAM), which in turn is preferably configured as a ring memory. In preferred embodiments of the present invention, the shadow registers are further formed by first in, first out (FIFO) memories so that for each read clock of the shadow register, a value may be read from the payload registers of the digital logic circuit and provided to the controller, so that a complete observation of the circuit is possible.
The present invention provides a hardware debugger that cyclically reads the circuit states of all internal nodes of a digital logic circuit to detect a failure of the digital logic circuit, which may be any digital logic circuit, such as a PLD or FPGA or the like be able to provide a simulation computer suitable data to provide the determination of the cause of the error or allow the failure. The hardware debugger allows real-time processing, ie. H. in that the detection of the circuit states of the internal circuit nodes and an interruption can be performed while the integrated circuit, i. H. the digital logic circuit, and the system environment of the same work in real time.
To meet these real-time requirements, it is necessary that a hardware debugger be provided.
The hardware debugger used in the present invention is preferably capable of performing three different modes, a tracking mode, an interrupt mode, and an update mode. The tracking mode enables the operation of the digital logic circuit to independently sample and store all the circuit states of the internal circuit nodes, as well as continuously track and store all the input / output signals. The sampled circuit states describe the internal behavior of a DUT, for example during a prototyping process or during an in-system test. The input / output signals describe the corresponding environmental data.
The acquired circuit state and input signal data then serve, as discussed above, for later analysis of the circuit functionality, in particular the reconstruction of hardware internal states of the DUT in a simulation environment. Reconstruction means that the simulation model of the DUT is initialized with the sampled circuit state of a selected time. The sampled input signal data serve as stimuli for the simulation. Thus, as explained above, it is not necessary for a user to "simulate" his simulation model for a long time at the time to be considered. Only the time intervals necessary for the analysis have to be simulated in detail. The effect is a drastic reduction of the required simulation time.
The interrupt mode is entered upon occurrence of certain interrupt conditions that are freely specifiable states of the DUT. In this case, on the one hand there are internal interruption conditions that represent an internal Schaltungszu stand, which triggers a corresponding action, such as an internal arithmetic overflow, and thus represents a fault condition. In addition, external interruption conditions can be predetermined, in which outside of the DUT a state is reached which triggers a corresponding action, wherein this state can be caused, for example, by erroneous output values. Internal and external interrupt conditions are generally generated by additional hardware.
In addition, further interruption of the hardware debugging may be effected by user intervention, such as termination of hardware debugging. The actions taken on the occurrence of a break depend on the type of break, generally stopping the DUT and storing the circuit state. Depending on the severity of the interruption which has occurred, the operation can subsequently be continued or a reset can be carried out. The interruption mode can be activated in parallel to the tracking mode.
Finally, the update mode allows a user to create defined internal circuit states in the DUT. Thus, operating states of the hardware can be provoked without the hardware having to be brought into this state by input signals. This mode can be used to effectively test extreme cases of operating conditions or to be able to set hard-to-reconstruct hardware states for test purposes.
A hardware debugger enabling the above modes of operation in preferred embodiments of the present invention consists of a shadow register for each internal circuit node of the DUT, a memory for storing a plurality of circuit state diagrams respectively associated with particular times, and a controller which enables the cyclic storage of the circuit state diagrams and the reading thereof to a simulation computer. Such a hardware debugger allows for real-time tracking of internal circuit states without inadvertently affecting the DUT.
Furthermore, the hardware debugger is applicable to all conventional circuit technologies without consideration of technology-specific circuit variants. The hardware debugger is preferably controllable via a computer, the processing of the tracking and updating data and the description of the interruption conditions taking place in the computer.
The simulation performed after the occurrence of an interrupt condition based on the circuit states and input data detected in the tracking mode is preferably performed on the basis of a circuit model existing as a gate net list. Thus, there is no need to transform the gate level data obtained by hardware debugging to the register transfer level.
The present invention thus enables time-saving error analysis to find the cause of errors occurring in digital logic circuits. The present invention also makes it possible to find fault causes, even if the system environment provides different stimuli for each repetition of a hardware fault analysis procedure. Namely, according to the present invention, the user does not need to incrementally repeat an error analysis to circling the cause of the error, but can do the cause of failure research by cyclically sampling and storing all the relevant data during the first execution in which the error occurs by means of a software simulation from time zero must be realized.
The limitations of this method of cyclic sampling of the relevant data are only the limited sampling rate, which is technology-dependent, as well as in a possibly limited upper memory space for the large number of signals in large logic circuit designs or long real-time runs. In this case, the present invention makes it possible to find the cause of a single-time failure by performing a software simulation based on a stored circuit state diagram taken at a time immediately preceding the occurrence of the error. Thus, the user does not have to hope for a recurrence of the error, which in many cases is unsuccessful due to the lack of reproducibility of the errors.
Preferred embodiments of the present invention will be explained below with reference to the accompanying drawings. Show: 1 is a schematic diagram for explaining the present invention; FIG. 2a to 2d are schematic illustrations of different embodiments of devices for carrying out the method according to the invention; FIG. 3 is a schematic representation of a Nutzregisterzelle; FIG. FIG. 4 shows a schematic representation of a circuit node from a useful register cell provided with a shadow register according to the present invention; FIG. FIG. 5 is a table for illustrating the operation of the device shown in FIG. 4 circuit node shown; FIG. Figure 6 is a schematic diagram illustrating shadow registers interconnected in a scan chain or scan path;
FIG. FIG. 7 is a schematic diagram illustrating an embodiment of a circuit section for generating an interrupt condition; FIG. FIG. 8 is a schematic diagram illustrating a preferred embodiment for shifting and reading a scan chain; and FIG. 9 is a schematic representation of a circuit node in which a user register is provided with a shadow register realized by a FIFO memory.
Referring to FIG. 1, a preferred embodiment of the inventive method for error analysis will now be explained in more detail. The upper in Fig. 1 axis is a real-time axis, while the bottom axis represents a virtual simulation time. According to the invention, a DUT 2 is operated in real time by applying input signals 4, which can represent the influence of a system environment on the DUT 2. During operation of the DUT 2, which may be, for example, an FPGA or a PLD, according to the invention, the circuit states of all internal circuit nodes of the DUT 2 are cyclically read by a hardware debugger 6, which is indicated by an arrow 8 in FIG. 1 is indicated. The hardware debugger 6 is connected to the DUT 2 via a debugger interface 9.
Although the hardware debugger 6 and the DUT 2 in FIG. 1 as being shown separated by an interface 9, part of the hardware debugger 6, namely at least respective shadow registers thereof, are included in the integrated circuit which constitutes the DUT 2. Operation of the logic circuitry, for example to perform prototype testing or in-system testing, continues during hardware debugging until an error condition 10 occurs in the DUT 2 until a time t 1. This error condition 10 represents an interruption condition.
Upon the occurrence of such an interrupt condition 10, based on the circuit states cyclically read by the hardware debugger 6 and the input signals 4 applied to the DUT 2, a software simulation is performed to investigate the cause underlying the error condition 10. The transfer of the above data is shown in FIG. 1 schematically represented by an arrow 12. At this point, it should be noted that the in Fig. 1 above the arrow 12 are to be regarded as a real-time environment, while the time axis shown below the arrow 12 represents a virtual simulation time.
As shown in FIG. 1, in order to find out the cause of the error, the simulation jumps back from the time t 1 to a time t 2 in order to start the simulation at this time t 2. The return interval is preferably selected such that the circuit state diagram stored at time t 2 indicates proper operation of the DUT. This results in a software simulation interval 14 for error cause analysis, which begins at time t 2. Thus, according to the present invention, the time consumption for the failure cause analysis process that starts after an error condition 10 is detected can be shortened considerably.
As shown schematically by the arrow 12, the cyclically read data are used for a following analysis of the circuit behavior, the hardware internal states describing the internal behavior of the DUT 2, while the input signals 4 represent the corresponding environmental data corresponding to the observed behavior to lead.
It should be noted at this point that the return interval from time t 1 to time t 2 is preferably chosen such that it can be safely assumed that the circuit has worked correctly until time t 2. To verify this, a check can be made. If this results in the circuit no longer having worked correctly at the return time, a further time jump can be made after the return to the time t 2 to ensure that the DUT has worked properly at the beginning of the software simulation.
The software simulation that provides the error cause analysis is preferably achieved using a simulation environment for the gate model, so that the simulation model of the DUT can be readily initialized with a set of data representing a sampled circuit state diagram. This sampled circuit state diagram is associated with the time t 2. Thus, according to the invention, the simulation does not have to start at time zero. Rather, the simulation begins at time t 2 by initializing the simulation model with the circuit state diagram read at that time, and using the sampled input signals as stimuli for the gate level simulation.
Thus, according to the invention, only the interval between the initialization time t 2 and the error time t 1 must be simulated, which provides a drastic time saving compared to known simulation methods.
Moreover, it is preferred according to the invention that the state of the DUT 2 can be preset via the hardware debugger 6, without requiring a sequence of external stimuli for this purpose. This can be realized by the shadow registers used in accordance with the present invention, in particular to effectively test extreme operating conditions or to set DUT states for testing purposes that can be difficult to achieve by external stimuli, for example to check the ability of state machines to go out of illicit states to reach out in finite time allowed states. Now that the method according to the invention has been explained in general terms, exemplary embodiments of apparatuses for carrying out the method according to the invention are described below.
In Fig. 2 shows a first exemplary embodiment of a device according to the invention, wherein a DUT 2 is shown which contains components 20 of the hardware debugger of the device according to the invention. The components 20 relate to the components of the hardware debugger located in the integrated circuit of the DUT 2, namely shadow registers and optionally means for detecting the input signals 4 from a system environment 22, as well as means for detecting the output signals from the DUT 2, for example to determine interrupt conditions based thereon.
The DUT internal elements 20 of the hardware debugger are connected via an interface 24 to a hardware debugger controller 26 which controls the operation of the hardware debugger and stores read and collected data in a memory 28, preferably a RAM. The hardware debugger control is further connected via an interface 30 to a computer 32 on which the software simulation is performed on the basis of the data provided by the controller 26, which data is supplied via the interface 30 to the computer 32. In the in Fig. 2a illustrated embodiment represents the connection between DUT internal portion 20 of the debugger and the controller 26, namely the interface 24, the time-critical connection.
In the in Fig. 2b, the hardware debugger control is divided into two parts, a core element 36 located in the integrated circuit 34 of the DUT 2, and an outboard control 26 '. In this embodiment, the core 36 is the functionality of the debugger control in the circuit 34, in which also the DUT 2 is realized, so that the time-critical connection, in FIG. 2b denoted by the reference numeral 38, may be realized here shorter, so that shorter signal propagation times result, allowing higher sampling frequencies.
The illustrated hardware debugger core element 36 is a DUT-independent state machine for controlling communication between the debugger controller 26 'and the DUT-internal debugger components 20. In doing so, the debugger core element must control the transfer of data to the shadow elements, interrupt detection, and possible user intervention via the debugger interface 24 'to the debugger controller 26'. Reading the shadow registers is time-critical, with the core element 36 providing the shift clock for shadow elements interconnected as a shift chain and having to read one or more shift chains. The time required for this action essentially determines the sampling period.
Therefore, the reading of shadow register chains and writing to the RAM 28 is preferably organized as a pipeline structure as parallel as possible. In contrast, writing the shadow registers during the debugger update mode is less timely because in this mode the DUT is usually in a wait state. Another advantage of placing the core element 36 in the integrated circuit of the DUT is that it makes it possible to detect internal interrupts as quickly as possible. Alternatively to the in Fig. 2a, the core element 36 of the debugger controller may also be connected to the external RAM 28 via a direct interface.
The in Fig. 2c differs from the embodiment shown in FIG. 2b show that now the entire debugger control 26 is embedded together with the RAM 28 in the integrated circuit 34 of the DUT 2. This embodiment thus represents a compact solution for an in-system test with maximum sampling frequency. The disadvantage, however, is the considerable additional circuit complexity and the chip area consumed for the RAM for the DUT. It should also be noted that the on-chip RAM 28, as shown in FIG. 2c, typically has a lower storage capacity than an external RAM.
In Fig. FIG. 2 d schematically illustrates a way to map the input vector to the DUT 2, i. H. continuously monitor the input signals 4 to provide these inputs to a computer for use as stimuli for the simulation. For illustrative purposes, as shown in FIG. 2d shows the detection of the input signals 4 via a logic analyzer 40, which is connected to the input terminals of the DUT 2 and the computer 32. It should be noted, however, that the input signals to the DUT 2 may also be detected in other ways, for example by corresponding hardware components in the DUT's integrated circuit, so that the input signals may be detected by the debugger controller.
Referring to FIG. 3-5, a description will now be given of preferred embodiments of the components of the hardware debugger located in the integrated circuit of the DUT.
In Fig. 3, a payload register 50 is shown which serves in a digital logic circuit to define a circuit state of an internal circuit node. In the exemplary embodiment illustrated, the useful register 50 is a D flip-flop having a data input 1D, an activation input 1E and a clock input C1. A data signal d is present at the data input 1D, an activation signal en is applied to the activation input 1E, while a useful clock clk is applied to the clock input C1. The flip-flop 50 has a data output q and an inverted data output qb.
FIG. 4 shows an internal system node of a digital logic circuit in which the internal user register 50 is assigned a shadow register 60, which preferably has the same structure as the user or data register 50. The user register 50 and shadow register 60 are interconnected via two demultiplexers 62 and 64, an AND gate 66 and an OR gate 68 such that a normal function of the payload register 50, a scanning of the shadow register 60, is to update the contents of the payload register 50 via the shadow register or a transfer of the contents of the user register 50 in the shadow register 60 is possible.
For this purpose, a control signal upd indicating an update mode is connected to an input of the OR gate 68 and the control input of the demultiplexer 62. The output of the demultiplexer 62 is connected to the data input 1D of the payload register. At one input of the demultiplexer 62, the data input signal d is present, while the other input of the demultiplexer 62 is connected to the output of the shadow register 60. The second input of the OR gate 68 is connected to the output of the AND gate 66, to the inputs of which the data register enable signal en and a data register chip enable signal ce are applied. At the clock input C1 of the useful register 50, the useful clock clk is applied.
The output of the payload register 50 is connected to one input of the demultiplexer 64, while the other input of the demultiplexer 64 is connected to a shadow register scan path input si. The demultiplexer 64 is controlled by a readout mode signal cpt, the output of the demultiplexer 64 being connected to the data input 1D of the shadow register 60. At the activation input 1E of the shadow register 60, a shadow register enable signal se is applied, while at the clock input C1 thereof a shadow register clock signal sclk is applied. The output of the shadow register 60 forms the shadow register sample output so that the shadow register can be switched into a scan path via the input si and the output.
With regard to the operation of the in Fig. 4, the circuit shown in FIG. 5, in which the respective assignments of the inputs and the outputs in the respective operating modes are set forth.
Merely illustratively, it should be noted that during normal operation of the payload register 50, the updating signal upd is inactive, d. H. 0, so that the data signal d is present at the data input 1D of the useful register 50 via the demultiplexer 62. During the scan mode, the read-out signal cpt is inactive, i. H. 0, so that the signal at the shadow register scan path input si is applied to the data input 1D of the shadow register 60. In update mode, the update signal upd is active, i. H. 1, so that via the demultiplexer 62, the output of the shadow register 60 is applied to the data input 1D of the user register 50, so that the contents of the shadow register 60 can be transferred to the user register 50.
In readout mode, the readout signal cpt is active, d. H. 1, so that the content of the useful register 50 can be transferred to the shadow register 60 via the demultiplexer 64.
Although above with reference to FIG. 4, a specific embodiment for the interconnection of payload registers and shadow registers is illustrated, it will be understood that payload and shadow registers may be switched in a different manner to provide the illustrated functionality. In the same way, the shadow register need not be formed by an element identical to the data register, but may be a differently configured register element.
In Fig. 6 is the interconnection of a plurality of in FIG. 4 in a scan path for forming a shift chain. Reference numerals 100, 102, 104 and 106 each designate a circuit structure that represents an internal circuit node of a digital logic circuit. In this case, in Figs. 4 and 6 denote the same signals, wherein in Fig. 6 only the outermost left circuit node with the reference numerals of FIG. 4 is designated. As shown in FIG. 6, in each case the scan path input si of a respective shadow register is connected to the scan path output of a previous shadow register, so that the shadow registers can be read in the form of a shift chain.
The signals clk, upd, ce, cpt, se and sclk can be applied via common lines in the manner shown in order to realize a scan chain.
As described above with reference to FIG. 1, according to the invention, a software simulation takes place when an interruption condition occurs. Interruptions can be detected in different ways. First, there may exist complex interruption conditions in which, for example, a detected circuit state diagram is compared with an expected predetermined circuit state diagram, where it is judged that an interruption condition exists in the event of a mismatch. In addition, gate-level interrupt conditions may be provided, which are predetermined cells that are automatically introduced into the DUT gate level description. Here, only individual nodes or vectors are monitored, with an exemplary interrupt cell for such monitoring in FIG. 7 is shown.
A line 80 represents a node to be monitored and is connected to an input of a comparator 82. A second input of comparator 82 is connected to means 84 which provides a comparison value. The reference or comparison value for the comparator 82 may be adjusted via a separate interrupt cell scan path 86. In this case, a comparison value is only valid if a single enable bit "enable" (FIG. 7) is set. Thus, the user can turn the functionality of the comparator on and off. The output of the comparator 82 may be, for example, the data register chip enable signal ce so that the normal operation of the DUT is adjusted if the comparison in the comparator 82 does not match and thus an interrupt condition is determined.
As noted above, the storage of the data acquired in tracking mode, i.e. H. the circuit state diagrams or optionally additionally the input signals, usually in external or internal RAM areas. The size of the RAM areas used determines the number of storable state vectors, i. H. the history depth of the generated circuit state history. In practically relevant circuits, d. H. several thousand flip-flops and a real-time debugging in the seconds range, it is technically impossible to temporarily store all state vectors that have occurred. Therefore, in preferred embodiments of the present invention, the RAM memory is organized as a ring buffer in which the last n state vectors are always available for evaluation so that a history depth of n results.
In contrast to reading the shadow registers, initializing the DUT with update data is not time critical so that the update vectors can be held on the host computer. The respective current vector can then be loaded, for example via a JTAG interface, directly into the DUT or, conveniently, into the RAM, with the RAM areas subsequently being copied into the corresponding registers in reversal to the tracking mode. The size of the RAM is uncritical since only one update vector has to be buffered at a time.
With regard to the clocks with which the useful registers and the shadow registers are operated (see clk and sclk in FIG. 4) it should be noted that these can be operated with identical or un ferent clock. If the shadow registers are operated with a higher-frequency clock than the data registers, it is necessary that the clock sclk of the shadow registers has an at least three times higher frequency than the clock clk of the data registers. The use of such a higher shadow register clock is advantageous when long shift chains are used. Alternatively, both the user register and the shadow register can be operated in isochronous mode, which is preferably realized at high DUT frequencies. It should be noted that low shift frequencies can be compensated by, a parallelization of the scan paths.
The sampling frequency for the state vectors in tracking mode is limited by the length of the state vector and the length of the tracking RAM write cycle. For a maximum sampling frequency, the shifting of the shadow registers should take place in the sense of pipeline processing in the shadow of the write cycle, as shown in FIG. 8, so that each time during the shift of a subsequent cycle n + i, the data for the previous cycle n is written. Thus, there is no further loss of time. In order to ensure a sufficiently fast shift, either the shift frequency must be correspondingly high or the shadow registers must be grouped into several scan groups. Alternatively, it is possible to realize the shadow registers by FIFO memory, so that between two sampling points in each case only one pitch must be present.
In other words, for each shadow register clock sclk, a value can be read out of the circuit and made available to the hardware debugger controller, so that complete monitoring of the circuit is possible.
An embodiment of such a realization is shown in FIG. 9, in the same elements as in FIG. 4 are provided with the same reference numerals. Here, to realize a FIFO depth of three, two FIFO registers 200 and 202 clocked by clk are connected between the data output q of the payload register 50 and the one input of the demultiplexer 64. The FIFO registers 200 and 202 are controlled via a signal FIFO-cpt, i. H. activated. By means of the FIFO registers 200 and 202, it is possible to buffer new samples from the user register in parallel with the readout of the shift chain. These samples may also be contiguous, with the maximum number of contiguous samples not exceeding the FIFO depth, in the illustrated embodiment, three.
This can be done by a controller in the hardware debugger, i. H. For example, the controller 26 in FIG. 2a, be ensured. This can prevent a FIFO overflow that would occur whenever more samples are written to the FIFO than can be read from shadow registers via the shift chain.
As already mentioned above, for a subsequent analysis of the DUT behavior in the hardware test the recording of all input data is necessary. This input data can be recorded, for example, by conventional logic analyzers or by special hardware, the respective realization of such factors, such. B. the required sampling rate, the width of the input signal vector and the history depth, as well as the available commercial hardware.