DE102022203611A1

DE102022203611A1 - Hochfrequente ereignisbasierte hardware-diagnosen

Info

Publication number: DE102022203611A1
Application number: DE102022203611.5A
Authority: DE
Inventors: Ran Koren; Shay Aisman; Itamar Rabenstein; Amir Ancel
Original assignee: Mellanox Technologies Ltd
Current assignee: Mellanox Technologies Ltd
Priority date: 2021-04-20
Filing date: 2022-04-11
Publication date: 2022-10-20
Also published as: US20230359537A1

Abstract

Ein Gerät umfassend einen Betriebsschaltkreis und einen Hardware-Diagnose-Schaltkreis (HDC). Der HDC ist so konfiguriert, dass er eine Definition mehrerer Triggerregeln empfängt, wobei jede Triggerregel ein jeweiliges Triggerereignis als eine Funktion von Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert, eine Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) eines jeweiligen Post-Trigger-Protokollierungssatz für jede Triggerregel, der einen Satz von einer oder mehreren der Diagnosedatenquellen enthält, empfängt, und während des Betriebs des Betriebsschaltkreises die Diagnosedatenquellen in dem Pre-Trigger-Protokollierungssatz protokolliert, die Triggerdatenquellen protokolliert und die Triggerregeln wiederholt protokolliert, und als Reaktion auf das Auslösen eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel mit der Protokollierung der Diagnosedatenquellen in dem Post-Trigger-Protokollierungssatz der bestimmten Triggerregel beginnt.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich allgemein auf elektronische Schaltungen und insbesondere auf die schaltungsinterne Fehlersuche bei Netzwerkgeräten und anderen elektronischen Schaltungen.
HINTERGRUND DER ERFINDUNG
Komplexe elektronische Systeme, wie z.B. netzgebundene Geräte, umfassen häufig Hardware und Software, die Online-Tests und -Diagnosen erleichtern.
Das US-Patent 7.730.458 beschreibt beispielsweise ein System und ein Verfahren, das die Diagnoseunterstützung erleichtert, einschließlich Anwendungen, die gemäß einem Rahmenwerk für eingebaute Diagnosen (BID) instrumentiert sind, und Trace-Komponenten. Die Trace-Komponenten können selektiv keine, einige und/oder im Wesentlichen alle mit der Anwendung verbundenen Trace-Punkte verwenden. Das System kann zum Beispiel die Instrumentierung eines verwalteten Datenzugriffsstapels erleichtern, um die Unterstützungsfähigkeit der Anwendung zu verbessern.
In einem anderen Beispiel beschreibt die US-Patentanmeldung 2008/0077835 ein automatisches Testgerät, das in der Lage ist, Diagnoseinformationen von einem zu testenden Gerät zu empfangen, das über ein eingebautes Selbsttestsystem (BIST) und einen Diagnoseinformationssammler verfügt, der die vom BIST ausgegebenen Diagnosemuster vorübergehend speichert und bei Erkennung eines Fehlers im zu testenden Gerät eine Fehleranzeige liefert. Der ATE umfasst eine Geräteschnittstelle, die mit dem zu prüfenden Gerät verbunden werden kann, ein Verarbeitungssystem und Verarbeitungskanäle. Die Verarbeitungskanäle sind jeweils mit der Geräteschnittstelle und dem Verarbeitungssystem verbunden und umfassen Testkanäle, einen Fehleranzeigekanal und einen Diagnoseinformationskanal. Die Testkanäle sind mit dem BIST interoperabel, um das zu prüfende Gerät einer Reihe von Tests zu unterziehen. Der Fehleranzeigekanal ist so angeschlossen, dass er die Fehleranzeige von der Geräteschnittstelle empfängt. Der Diagnoseinformationskanal kann als Reaktion auf die über den Fehleranzeigekanal empfangene Fehleranzeige von der Geräteschnittstelle zumindest einige der in dem zu prüfenden Gerät vorübergehend gespeicherten Diagnosemuster als Diagnoseinformationen empfangen.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung wird durch die Ansprüche definiert. Zur Veranschaulichung der Erfindung werden hier Aspekte und Ausführungsformen beschrieben, die in den Anwendungsbereich der Ansprüche fallen können oder auch nicht.
Eine hierin beschriebene Ausführungsform der vorliegenden Erfindung stellt eine Vorrichtung bereit, die einen Betriebsschaltkreis und einen Hardware-Diagnose-Schaltkreis (HDC) umfasst. Der HDC ist so konfiguriert, dass er eine Definition mehrerer Triggerregeln empfängt, wobei jede Triggerregel die Auslösung eines jeweiligen Triggerereignisses in Abhängigkeit von einer oder mehreren Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert, um eine Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) für jede Triggerregel einen jeweiligen Post-Trigger-Protokollierungssatz zu empfangen, der einen jeweiligen Satz von einer oder mehreren der Diagnosedatenquellen enthält, und während des Betriebs des Betriebsschaltkreises die Diagnosedatenquellen in dem Pre-Trigger-Protokollierungssatz wiederholt zu protokollieren, die Triggerdatenquellen wiederholt zu protokollieren und die Triggerregeln wiederholt auszuwerten, und als Reaktion auf das Auslösen eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel die Protokollierung der Diagnosedatenquellen in dem Post-Trigger-Protokollierungssatz der bestimmten Triggerregel zu beginnen.
In einigen Ausführungsformen unterscheidet sich mindestens ein Post-Trigger-Protokollierungssatz von dem Pre-Trigger-Protokollierungssatz. In einigen Ausführungsformen ist der HDC so konfiguriert, dass er die Diagnosedatenquellen im Post-Trigger-Protokollierungssatz über ein definiertes Zeitintervall oder bis zu einer definierten Datengröße protokolliert. In einem Ausführungsbeispiel wird das definierte Zeitintervall oder die definierte Datengröße pro Triggerregel festgelegt.
In einer offenbarten Ausführungsform ist der HDC so konfiguriert, dass er nur bis zu einer bestimmten Menge der aktuellsten Daten aus den Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz speichert. In einer anderen Ausführungsform ist der HDC so konfiguriert, dass er Bilder der Diagnosedatenquellen protokolliert, die relativ zueinander zeitkohärent sind. In einer weiteren Ausführungsform ist der HDC so konfiguriert, dass er die Diagnosedatenquellen in einem Speicher protokolliert und als Reaktion auf einen Dump-Befehl zumindest einen Teil der protokollierten Pre-Trigger- und Post-Trigger-Protokollierungssätze ausgibt.
In einer Ausführungsform spezifiziert mindestens eine der Auslöseregeln eine Bedingung, die von den Auslöserdatenquellen über ein bestimmtes Zeitintervall erfüllt werden muss. In einer anderen Ausführungsform legt mindestens eine der Auslöseregeln eine statistische Bedingung fest, die von den Auslöserdatenquellen erfüllt werden muss.
In einigen Ausführungsformen ist der Betriebsschaltkreis für die Verarbeitung von Kommunikationspaketen konfiguriert, und eine oder mehrere der Auslöseregeln beziehen sich auf die Durchführung der Paketverarbeitung durch den Betriebsschaltkreis. In einigen Ausführungsformen ist der Betriebsschaltkreis so konfiguriert, dass er über einen Bus kommuniziert, und eine oder mehrere der Auslöseregeln beziehen sich auf die Durchführung der Buskommunikation durch den Betriebsschaltkreis.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird zusätzlich ein Verfahren bereitgestellt, das den Empfang einer Definition mehrerer Triggerregeln in einem Hardware-Diagnose-Schaltkreis (HDC), der mit einem Betriebsschaltkreis gekoppelt ist, einschließt, wobei jede Triggerregel die Auslösung eines jeweiligen Triggerereignisses in Abhängigkeit von einer oder mehreren Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert, und ferner im HDC eine Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) für jede Triggerregel einen jeweiligen Post-Trigger-Protokollierungssatz, der einen jeweiligen Satz von einer oder mehreren der Diagnosedatenquellen enthält, zu empfangen. Während des Betriebs des Betriebsschaltkreises werden unter Verwendung des HDC die Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz wiederholt protokolliert, die Triggerdatenquellen werden wiederholt protokolliert, und die Triggerregeln werden wiederholt ausgewertet. Als Reaktion auf die Auslösung eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel wird die Protokollierung der Diagnosedatenquellen im Post-Trigger-Protokollierungssatz der bestimmten Triggerregel gestartet.
In einigen Ausführungsformen unterscheidet sich mindestens ein Post-Trigger-Protokollierungssatz von dem Pre-Trigger-Protokollierungssatz. In einigen Ausführungsformen erfolgt die Protokollierung der Diagnosedatenquellen im Post-Trigger-Protokollierungssatz über ein definiertes Zeitintervall oder bis zu einer definierten Datengröße. In einem Ausführungsbeispiel wird das definierte Zeitintervall oder die definierte Datengröße pro Triggerregel festgelegt.
In einer offenbarten Ausführungsform umfasst die Protokollierung der Diagnosedatenquellen die Aufbewahrung nur bis zu einer bestimmten Menge der jüngsten Daten aus den Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz. In einer anderen Ausführungsform umfasst die Protokollierung der Diagnosedatenquellen die Protokollierung von Bildern der Diagnosedatenquellen, die relativ zueinander zeitkohärent sind. In einer weiteren Ausführungsform umfasst die Protokollierung der Diagnosedatenquellen die Protokollierung der Diagnosedatenquellen in einem Speicher und, als Reaktion auf einen Dump-Befehl, die Ausgabe zumindest eines Teils der protokollierten Pre-Trigger- und Post-Trigger-Protokollierungssätze.
In einer Ausführungsform spezifiziert mindestens eine der Auslöseregeln eine Bedingung, die von den Auslöserdatenquellen über ein bestimmtes Zeitintervall erfüllt werden muss. In einer anderen Ausführungsform legt mindestens eine der Auslöseregeln eine statistische Bedingung fest, die von den Auslöserdatenquellen erfüllt werden muss.
In einigen Ausführungsformen beziehen sich eine oder mehrere der Auslöseregeln auf die Durchführung der Verarbeitung von Kommunikationspaketen durch den Betriebsschaltkreis. In einigen Ausführungsformen beziehen sich eine oder mehrere der Auslöseregeln auf die Durchführung der Kommunikation über einen Bus durch den Betriebsschaltkreis.
In einer Ausführungsform umfasst ein Gerät einen Betriebsschaltkreis und einen Hardware-Diagnose-Schaltkreis (HDC). Der HDC ist so konfiguriert, dass er eine Definition mehrerer Triggerregeln empfängt, wobei jede Triggerregel ein jeweiliges Triggerereignis als Funktion von Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert, eine Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) eines jeweiligen Post-Trigger-Protokollierungssatz für jede Triggerregel, der einen Satz von einer oder mehreren der Diagnosedatenquellen enthält, empfängt, und während des Betriebs des Betriebsschaltkreises die Diagnosedatenquellen in dem Pre-Trigger-Protokollierungssatz protokolliert, die Triggerdatenquellen protokolliert und die Triggerregeln wiederholt auswertet, und als Reaktion auf das Auslösen eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel mit der Protokollierung der Diagnosedatenquellen in dem Post-Trigger-Protokollierungssatz der bestimmten Triggerregel beginnt.
Jedes Merkmal eines Aspekts oder einer Ausführungsform kann auf andere Aspekte oder Ausführungsformen angewandt werden, und zwar in jeder geeigneten Kombination. Insbesondere kann jedes Merkmal eines Verfahrensaspekts oder einer Ausführungsform auf einen Geräteaspekt oder eine Ausführungsform angewandt werden und umgekehrt.
Die vorliegende Erfindung wird aus der folgenden detaillierten Beschreibung der Ausführungsformen in Verbindung mit den Zeichnungen, in denen sie dargestellt ist, besser verständlich:
Figurenliste

1 ist ein Blockdiagramm, das schematisch den Aufbau eines Netzwerkgerätes gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
2A ist ein Blockdiagramm, das schematisch die Pre-Trigger-Datenprotokollierung in der Netzwerkvorrichtung von 1 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
2B ist ein Blockdiagramm, das schematisch die Datenprotokollierung nach dem Trigger im Netzwerkgerät von 1 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
3 ist ein Blockdiagramm eines Hardware-Diagnose-Schaltkreises (HDC) im Netzwerkgerät von 1, gemäß einer Ausführungsform der vorliegenden Erfindung; und
4 ist ein Flussdiagramm, das schematisch ein Verfahren zur Hardware-Diagnose gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.

DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
ÜBERSICHT
Digitale Systeme im Allgemeinen und insbesondere Netzwerkgeräte wie Netzwerkprozessoren, Netzwerkschnittstellen-Controller (NICs), Host-Channel-Adapter (HCAs), Switches, Router, Gateways und Grafikprozessoren (GPUs) können aus zahlreichen digitalen Untereinheiten mit komplexen Abhängigkeiten untereinander bestehen. Wenn ein solches System ausfällt oder die Leistung eines solchen Systems nachlässt, kann es schwierig sein, die Ursache zu finden.
Ausführungsformen gemäß der vorliegenden Erfindung, die hier offenbart werden, stellen Verfahren und Vorrichtungen bereit, die eine effiziente Hochgeschwindigkeitsdiagnose von digitalen Systemen ermöglichen. In einer Ausführungsform ist ein Hardware-Diagnose-Schaltkreis (HDC) in das digitale System eingebettet (der Teil des digitalen Systems, mit dem der HDC gekoppelt ist, wird als Betriebsschaltkreis bezeichnet).
In einer Ausführungsform umfasst der HDC einen Datenprotokollpuffer, einen Protokollierungsmultiplexer und eine Triggerprotokollierungsschaltung; der HDC ist so konfiguriert, dass er i) Triggerprotokollierungsregeln, ii) Pre-Trigger-Protokollierungsregeln und iii) Post-Trigger-Protokollierungsregeln empfängt. Der HDC ist so konfiguriert, dass er in dem Datenprotokollpuffer Pre-Trigger-Daten von dem Betriebsschaltkreis gemäß den Pre-Trigger-Protokollierungsregeln speichert, Trigger-Datenquellen überwacht und eine Trigger-Bedingung gemäß den Triggerprotokollierungsregeln erkennt. Nach der Erkennung des Triggerereignisses speichert der HDC die Post-Trigger-Daten im Datenprotokollpuffer.
In einigen Ausführungsformen ist der HDC außerdem so konfiguriert, dass er eine Grenze für die Post-Trigger-Puffergröße erhält. Nachdem ein Triggerereignis erkannt wurde, protokolliert die HDC Post-Trigger-Daten bis zur Post-Trigger-Puffergröße und stoppt dann. In anderen Ausführungsformen erhält der HDC ein Zeitlimit für die Post-Trigger-Datenprotokollierung.
In einer Ausführungsform ist der HDC so konfiguriert, dass er die gespeicherten Protokolldaten aus dem Datenprotokollpuffer zur Analyse und Diagnose an einen Prozessor sendet.
Schließlich umfasst der HDC gemäß einer Ausführungsform einen kohärenten Datenabtaster, der so konfiguriert ist, dass er kohärente Bilder von Daten in den Betriebsschaltkreisen aufzeichnet.
Die offenbarten Techniken bieten ein leistungsfähiges und effektives Überwachungs- und Fehlersuchwerkzeug für Netzwerkgeräte und andere elektronische Schaltungen. In einigen Ausführungsformen unterstützt der HDC beispielsweise hochflexible Definitionen von Triggerregeln, z.B. Regeln, die Bedingungen festlegen, die von den Triggerdatenquellen über ein definiertes Zeitintervall erfüllt werden müssen, und/oder statistische Bedingungen, die von den Triggerdatenquellen erfüllt werden müssen.
In einer typischen Ausführungsform ist der Pre-Trigger-Protokollierungssatz für alle möglichen Trigger gleich, während der Post-Trigger-Protokollierungssatz triggerspezifisch ist, d.h. er kann sich von einer Triggerregel zur anderen unterscheiden. Der HDC ist somit in der Lage, vor dem Auftreten eines Triggerereignisses eine Vielzahl von Datenquellen zu protokollieren und auf diese Weise ein breites Spektrum von Datenquellen über den Betriebsschaltkreis abzudecken. Nach dem Auftreten eines Triggerereignisses ermöglicht die triggerspezifische Definition des Post-Trigger-Protokollierungssatzes dem HDC, die zu protokollierenden Datenquellen auf die spezifischen Eigenschaften jedes Triggers abzustimmen. Diese Funktion ermöglicht eine beträchtliche Flexibilität bei der Definition von Regeln und eine effiziente Nutzung der begrenzten Speichergröße des Datenprotokollpuffers.
BESCHREIBUNG DES SYSTEMS
Gemäß Ausführungsformen der vorliegenden Erfindung können Netzwerkgeräte Hardware-Diagnose-Schaltungen umfassen, die von einem Prozessor so programmiert werden, dass sie Diagnosedatenquellen in einem Betriebsschaltkreis kohärent überwachen, vorgetriggerte Diagnosedaten protokollieren, datenabhängige Triggerereignisse protokollieren und, wenn Triggerereignisse auftreten, Daten entsprechend dem erkannten Triggerereignis protokollieren. Der HDC kann dann die protokollierten Daten zur Analyse an den Prozessor senden.
1 ist ein Blockdiagramm, das schematisch den Aufbau eines Netzwerkgeräts 100 gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. In verschiedenen Ausführungsformen kann das Netzwerkgerät 100 beispielsweise einen Netzwerkadapter wie einen Network Interface Controller (NIC), Host-Channel Adapter (HCA) oder Data Processing Unit (DPU - auch als „Smart-NIC“ bezeichnet), einen Netzwerkprozessor, einen Switch, einen Router, ein Gateway, eine netzwerkfähige Graphics Processing Unit (GPU) oder jede andere geeignete Art von Netzwerkgerät umfassen.
Das Netzgerät umfasst einen Betriebsschaltkreis 102, der mit einem Netz gekoppelt und so konfiguriert ist, dass er netzbezogene Operationen ausführt. Ein Benutzer (z.B. ein Servicetechniker) möchte möglicherweise den Betrieb des Netzwerkgeräts diagnostizieren, indem er Knoten innerhalb des Betriebsschaltkreises 102 beobachtet (z.B. Füllstand verschiedener Warteschlangen, Anzahl der Paketausfälle, Anzahl der gleichzeitigen Datenflüsse, um nur einige nicht begrenzte Möglichkeiten zu nennen). Der Benutzer kommuniziert mit dem Netzgerät über einen Prozessor 104 (in einigen Ausführungsformen ist der Prozessor 104 ein auf die Diagnose ausgerichteter Prozessor; in anderen Ausführungsformen ist der Prozessor 104 ein gemeinsam genutzter Prozessor, z.B. ein Prozessor, der den Betriebsschaltkreis steuert); in wieder anderen Ausführungsformen kann der Prozessor 104 aus mehreren Prozessoren bestehen.
Zur Durchführung von Diagnosen ist der Prozessor 104 so konfiguriert, dass er einen Satz von Triggerprotokollierungsregeln (hier auch als „Triggerregeln“ bezeichnet) in eine Triggerprotokollierungsschaltung 108 und einen Satz von Datenprotokollierungsregeln in ein Datenprotokollierungsregelregister 110 schreibt. Jede Triggerprotokollierungsregel spezifiziert die Auslösung eines entsprechenden Triggerereignisses in Abhängigkeit von einer oder mehreren Triggerdatenquellen in dem Betriebsschaltkreis 102.
In einer Ausführungsform können die Trigger-Protokollierungsregeln eine Bedingung oder Bedingungen festlegen, die von den Trigger-Datenquellen über ein bestimmtes Zeitintervall erfüllt werden müssen. In einer Ausführungsform können die Triggerprotokollierungsregeln komplexe Protokollierungen umfassen, z.B. kann ein Triggerereignis ausgelöst werden, wenn der Wert einer ersten überwachten Datenquelle größer als ein voreingestelltes Minimum ist und der Wert einer zweiten Quelle zwischen zwei voreingestellten Grenzwerten liegt (andere Beispiele für komplexe Triggerprotokollierungsregeln werden weiter unten offenbart). In den folgenden Beschreibungen werden die Begriffe „Erkennen eines Triggerereignisses“, „Bestimmen eines Triggerereignisses“ und „Auslösen eines Triggerereignisses“ synonym verwendet.
In einigen Ausführungsformen ist der Betriebsschaltkreis so konfiguriert, dass er über einen Bus kommuniziert (ein nicht einschränkendes Beispiel ist ein Peripheral Component Interconnect Express oder PCIe; andere geeignete Busse können in alternativen Ausführungsformen verwendet werden), und die Auslöseregeln beziehen sich auf die Durchführung der Buskommunikation durch den Betriebsschaltkreis.
In einigen Ausführungsformen kann die Triggerprotokollierungsschaltung 108 einen oder mehrere Prozessoren umfassen. Die Triggerprotokollierungsschaltung ist so konfiguriert, dass sie die Triggerprotokollierungsregeln vom Prozessor 104 empfängt, die jeweiligen Triggerprotokollierungsdatenquellen von dem Betriebsschaltkreis überwacht und Triggerereignisse erkennt.
In einer Ausführungsform können die Datenprotokollierungsregeln einen Pre-Trigger-Protokollierungssatz umfassen, der Datenquellen innerhalb des Betriebsschaltkreises definiert, die den HDC protokollieren sollte, bis ein Triggerereignis erkannt wird, und einen Post-Trigger-Protokollierungssatz, der Datenquellen definiert, die den HDC protokollieren sollte, nachdem das Triggerereignis festgestellt wurde. In einigen Ausführungsformen kann es mehrere Post-Trigger-Datenquellen geben, und die Datenprotokollierungsregeln definieren, welche Datenquelle nach der Erkennung eines Triggerereignisses bzw. des Triggerereignisses protokolliert werden soll. Der Pre-Trigger-Protokollierungssatz ist in der Regel nicht triggerspezifisch.
HDC 106 umfasst ferner einen Datenprotokollierungsmultiplexer 112, der so konfiguriert ist, dass er eine Teilmenge von Datenprotokollierungsquellen in dem Betriebsschaltkreis in Reaktion auf die Datenprotokollierungsregeln auswählt, und einen Datenprotokollpuffer 114, der so konfiguriert ist, dass er die Daten speichert, die der Protokollierungsmultiplexer auswählt. In einer Ausführungsform ist der Datenprotokollpuffer 114 ein First-In-First-Out-Speicher, der so konfiguriert ist, dass die ältesten Daten gelöscht werden, wenn neue Daten gespeichert werden (falls der Puffer voll ist). In Ausführungsformen ist die Post-Trigger-Datenprotokollierung begrenzt (z.B. zeitlich); wenn die Post-Trigger-Datenprotokollierung abgeschlossen ist, kann der Prozessor einen Dump-Befehl ausgeben, um den Datenprotokollpuffer 114 zu lesen und die aufgezeichneten Daten an den Benutzer zu senden (z.B. mit einem Wellenanzeigeprogramm).
Zusammenfassend lässt sich sagen, dass gemäß dem in 1 dargestellten Ausführungsbeispiel ein Benutzer den HDC mit einem Satz von Triggerprotokollierungsregeln, einem Satz von Pre-Trigger-Datenquellen („Pre-Trigger-Protokollierungssatz‟) und einem oder mehreren Sätzen von Post-Trigger-Datenquellen („Post-Trigger-Protokollierungssatz‟) programmiert. Der HDC speichert kontinuierlich die neuesten Pre-Trigger-Datenquellen und überwacht gleichzeitig die Trigger-Datenquellen und sucht nach einem Trigger-Ereignis (gemäß den Triggerprotokollierungsregeln). Sobald der HDC einen Trigger erkennt, beginnt er mit der Post-Trigger-Datenprotokollierung, die entsprechend dem erkannten Trigger-Ereignis bestimmt werden können. Der Puffer, einschließlich der Pre-Trigger- und Post-Trigger-Daten, kann vom Prozessor (und vom Benutzer) gelesen und analysiert werden.
Die in 1 dargestellte und oben beschriebene Struktur des Netzwerkgeräts 100, einschließlich des HDC 106, ist natürlich nur beispielhaft genannt. In alternativen Ausführungsformen können verschiedene geeignete Strukturen verwendet werden. In einigen Ausführungsformen kann der Benutzer beispielsweise mit dem HDC über das Netzwerk und den Betriebsschaltkreis kommunizieren und nicht über den Prozessor 104. In einer Ausführungsform gibt es keinen Datenprotokollpuffer 114; stattdessen werden die Daten über einen Hochgeschwindigkeitsbus an den Prozessor gesendet.
KONTROLLIEREN DER VOR- UND NACHPUFFERGRÖßEN
In einigen Ausführungsformen sendet der Prozessor außerdem einen Parameter für die Post-Trigger-Protokollierungsdauer an den HDC. Sobald ein Triggerereignis erkannt wird, füllt der HDC den Data-Log-Puffer 114 mit Post-Trigger-Datenproben für einen Zeitraum, der dem Parameter für die Protokollierungsdauer entspricht (auch als Protokollierungszeitintervall bezeichnet), und hält dann an. Der Prozessor liest dann den Datenprotokollpuffer 114 und empfängt Pre-Trigger- und Post-Trigger-Datenprotokolle. In einigen Ausführungsformen kann die Post-Trigger-Dauer durch eine Pufferfüllgröße ersetzt werden; in anderen Ausführungsformen kann der HDC so konfiguriert werden, dass die Post-Trigger-Datenprotokollierung gestoppt wird, wenn die Post-Trigger-Daten einen bestimmten Prozentsatz der Puffergröße des Datenprotokolls ausfüllen.
2A ist ein Blockdiagramm, das schematisch die Pre-Trigger-Datenprotokollierung gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Gemäß dem in 2A dargestellten Ausführungsbeispiel umfasst der Datenerfassungsmultiplexer 112 (der unter Bezugnahme auf 1 beschrieben wurde) einen Pre-Trigger-Selektor204, der so konfiguriert ist, dass er Datenquellen aus einer Gruppe von Pre-Trigger-Datenquellen (dem Betriebsschaltkreis 102, 1) entsprechend den Pre-Trigger-Datenerfassungsregeln auswählt, und einen Post-Trigger-Selektor 206, der so konfiguriert ist, dass er Datenquellen entsprechend den Post-Trigger-Datenerfassungsregeln und dem ausgewählten Triggerereignis auswählt.
Der Datenerfassungsmultiplexer 112 umfasst ferner einen Schalter 208, der so konfiguriert ist, dass er Pre-Trigger-Datenquellen vom Pre-Trigger-Selector 204 oder Post-Trigger-Datenquellen vom Post-Trigger-Selector 206 ausgibt. 2A zeigt schematisch die Datenprotokollierung zu einem Zeitpunkt, zu dem die Triggerprotokollierungsschaltung 108 (1) noch kein Triggerereignis erkannt hat und der Schalter 208 Pre-Trigger-Datenquellen ausgibt, die vom Pre-Trigger Selector 204 ausgewählt wurden.
Die vom Datenerfassungsmultiplexer 112 ausgegebenen Daten werden an den Datenerfassungspuffer 114 ausgegeben. In einigen Ausführungsformen umfasst der Data-Log-Puffer 114 einen FIFO-Speicher (First-In-First-Out); wenn die Speicherkapazität des Puffers erschöpft ist, werden die ältesten Daten gelöscht und stattdessen neue Daten geschrieben (in der Praxis überschreiben die neuen Daten die ältesten Daten). In einigen Ausführungsformen, z.B. wenn der Datenprotokollpuffer ein Segment eines gemeinsam genutzten Speichers ist, ist der Datenprotokollpuffer so konfiguriert, dass er eine bestimmte Menge der aktuellsten Daten speichert.
2B ist ein Blockdiagramm, das schematisch die Post-Trigger-Datenprotokollierung gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. 2B entspricht 2A, mit dem Unterschied, dass, nachdem die Triggerprotokollierungsschaltung 108 (1) ein Triggerereignis erkannt hat, der Schalter 208 die Post-Trigger-Ereignisse ausgibt, die von dem Post-Trigger-Selector 206 ausgewählt werden, und zwar entsprechend den Post-Trigger-Datenprotokollierungsregeln und dem erkannten Triggerereignis.
Der Datenprotokollpuffer 114 speichert nun Post-Trigger-Daten, die die ältesten Pre-Trigger-Daten ersetzen (zusätzlich zu einigen Pre-Trigger-Daten). In einigen Ausführungsformen wird die Post-Trigger-Datenprotokollierung nach einem vordefinierten Zeitintervall beendet; in einer Ausführungsform können für verschiedene Triggerereignisse unterschiedliche Zeitintervalle vordefiniert werden. In anderen Ausführungsformen wird die Post-Trigger-Datenprotokollierung gestoppt, wenn die Post-Trigger-Daten einen vorgegebenen Prozentsatz der Puffergröße ausmachen (z.B. 75 %).
Wenn die Datenprotokollierung nach dem Trigger abgeschlossen ist, kann der Prozessor 104 (1) den gesamten oder einen Teil des Inhalts des Datenprotokollpuffers 114 lesen.
Die in den 2A und 2B dargestellte und hierin beschriebene Struktur der Datenprotokollierung vor und nach dem Trigger wird hier nur beispielhaft genannt. In alternativen Ausführungsformen können verschiedene geeignete Strukturen verwendet werden. In einigen Ausführungsformen ist beispielsweise der Datenprotokollpuffer 114 in den Prozessor 104 eingebettet (1); in einer Ausführungsform kann der Prozessor 104 einen dedizierten Speicher zur Speicherung der protokollierten Daten umfassen; in einer anderen Ausführungsform speichert der Prozessor 104 die Protokolldaten in einem gemeinsam genutzten Speicher, z.B. im Primärspeicher des Prozessors. In einer weiteren Ausführungsform ist der Datenprotokollpuffer 114 zwischen dem HDC 106 und dem Prozessor 104 verteilt.
KOHÄRENTE DATENERFASSUNG
In bestimmten Fällen kann der Betriebsschaltkreis komplex sein und zahlreiche voneinander abhängige Datenerfassungsquellen umfassen. Um eine kohärente Analyse zu ermöglichen, muss die Datenprotokollierung für alle Datenquellen synchron erfolgen, damit die Datenquellen relativ zueinander kohärent sind. Im vorliegenden Zusammenhang bedeutet der Begriff „kohärent“, dass jeder Eintrag im Datenprotokollpuffer zu einem Bild des Betriebsschaltkreises gehört, bei dem die verschiedenen Protokollierungsquellen im selben Taktzyklus abgetastet wurden.
In einigen Ausführungsformen ist der HDC so konfiguriert, dass er Verzögerungen von voneinander abhängigen Protokollierungsquellen innerhalb des Betriebsschaltkreises korrigiert. Der HDC kann so konfiguriert werden, dass er die Protokollierung von Dateneinträgen, die in den Puffer geschrieben werden, um einen Taktzyklus verzögert, so dass sie mit der Protokollierung der Pufferstatus-(einschließlich Puffer-voll-) Signale zusammenfallen.
3 ist ein Blockdiagramm eines HDC 106A, gemäß einer Ausführungsform der vorliegenden Erfindung. HDC 106A ist ähnlich wie HDC 106 (1), umfasst aber zusätzlich einen kohärenter Sammler 302, der so konfiguriert ist, dass er kohärente Bilder des Betriebsschaltkreises 102 (1) abtastet. Der kohärente Sammler 302 kann sowohl Verzögerungsstufen als auch Synchronisatoren zwischen den Taktdomänen umfassen.
Der HDC 102A ist mit einem Prozessor 104A gekoppelt, der wie der Prozessor 104 (1) aufgebaut ist; gemäß dem in 3 dargestellten Ausführungsbeispiel umfasst der Prozessor 104A jedoch einen externen Datenprotokollpuffer 304. In Ausführungsformen ist der externe Datenprotokollpuffer 304 so konfiguriert, dass er überschüssige Daten protokolliert, die der Datenprotokollpuffer im HDC nicht speichern kann. Zum Beispiel kann in einer Ausführungsform der HDC-Datenprotokollpuffer 114 16 MB umfassen, während der externe Datenprotokollpuffer 304 256 MB umfassen kann.
4 ist ein Flussdiagramm, das schematisch ein Verfahren 400 zur Hardware-Diagnose gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Das Flussdiagramm wird von der Hardware-Diagnose-Schaltung 106 (1) ausgeführt, die mit dem Prozessor 104 (und typischerweise mit einem Benutzer über den Prozessor) kommuniziert.
Das Flussdiagramm beginnt mit dem Schritt 402 „Triggerprotokollierungsregeln abrufen“, in dem der HDC Triggerprotokollierungsregeln von einem Prozessor (z. B. Prozessor 104, 1) empfängt. Wie oben (unter Bezugnahme auf 1) beschrieben, können die Triggerprotokollierungsregeln komplexe Protokollierungen umfassen, einschließlich Beziehungen zwischen verschiedenen Datenpunkten und Berechnungen, die mit den Daten durchgeführt werden.
Als nächstes empfängt der HDC in einem Schritt 404 (Pre-Trigger-Protokollierungssatz Abrufen) vom Prozessor eine Liste von Datenquellen in dem Betriebsschaltkreis (z.B. Betriebsschaltkreis 102, 1), die der HDC vor einem Triggerereignis protokollieren sollte; und dann empfängt der HDC in einem Schritt 406 (Get Post-Trigger-Protokollierungsregeln) vom Prozessor Protokollierungsregeln für Daten, die nach der Erkennung eines Triggerereignisses protokolliert werden sollen. In Ausführungsformen können die Post-Trigger-Regeln Listen von Datenquellen umfassen, die nach dem erkannten Triggerereignis protokolliert werden sollen.
Nach Schritt 406 tritt der HDC in einen Get-Start-Indication-Schritt 408 ein und wartet auf eine Anzeige (typischerweise von einem Benutzer über einen Prozessor), dass die Diagnose beginnen soll. Nach dem Empfang einer Startanzeige tritt der HDC in einen Continuous-Pre-Trigger-Schritt 410 ein, in dem der HDC wiederholt die Pre-Trigger-Daten gemäß den Pre-Trigger-Datenprotokollierungsregeln protokolliert und gleichzeitig wiederholt die Trigger-Datenquellen protokolliert, um ein Triggerereignis zu erkennen.
Wenn der HDC in Schritt 410 ein Triggerereignis erkennt, tritt sie in einen Continuous-Post-Trigger-Schritt 412 ein, in dem der HDC Post-Trigger-Daten protokolliert, die gemäß den Post-Trigger-Protokollierungsregeln und dem erkannten Triggerereignis ausgewählt wurden. Wenn eine voreingestellte Post-Trigger-Protokollgröße erreicht wurde (z. B. 75 % des Datenprotokollpuffers 114 (1) speichert Post-Trigger-Daten), tritt der HDC in einen Send-Done-Schritt 414 ein und sendet eine Done-Anzeige an den Prozessor (typischerweise an den Benutzer, über den Prozessor). Der HDC tritt dann in einen Send-Buffer-Schritt 416 ein, in dem der HDC nach Erhalt eines Dump-Befehls vom Prozessor den Inhalt des Datenprotokollpuffers (oder Teile davon) an den Prozessor sendet. Nach Schritt 416 endet das Flussdiagramm.
Das in 4 dargestellte und oben beschriebene Flussdiagramm der Methode 400 wird hier nur als Beispiel angeführt. Andere geeignete Flussdiagramme können in alternativen Ausführungsformen verwendet werden. In einigen Ausführungsformen entfällt beispielsweise der Schritt 408, und der HDC beginnt unmittelbar nach Erhalt der Regeln mit der Datenprotokollierung. In einer Ausführungsform sendet der HDC alle Daten zusammen mit der Meldung „Fertig“ an den Prozessor. In einer Ausführungsform empfängt der HDC einen neuen Satz von Regeln und sendet gleichzeitig die protokollierten Daten, die einem früheren Satz von Regeln entsprechen, in einer Pipeline.
BEISPIELE FÜR ANWENDUNGSFÄLLE (NIC)
In einigen Ausführungsformen bezieht sich die Diagnose auf die Paketverarbeitungsleistung des Netzgeräts, und die Auslöseregeln beziehen sich auf die Leistung der Paketverarbeitung durch den Betriebsschaltkreis.
In diesem Abschnitt werden typische Anwendungsfälle bei der Leistungsdiagnose eines Network-Interface-Controllers (NIC) gemäß den Ausführungsformen der vorliegenden Erfindung beschrieben.
In einem ersten Beispiel wird eine ungewöhnlich hohe Packet-Drop-Rate festgestellt und eine Diagnosesitzung eingeleitet. Die Regeln für die Triggerprotokollierung können z.B. festgelegt werden:

1. Bestimmung eines Auslöseereignisses, wenn die Anzahl der verworfenen Pakete an einem bestimmten Anschluss und/oder in einem bestimmten Empfangspuffer während eines vorgegebenen Zeitraums einen vorgegebenen Schwellenwert überschreitet.
2. Bestimmung eines Trigger-Ereignisses, wenn die Anzahl der verworfenen Pakete an einem bestimmten Anschluss und/oder in einem bestimmten Empfangspuffer während eines vorgegebenen Zeitraums einen vorgegebenen Prozentsatz der Paketrate des Eingangsanschlusses überschreitet.
3. Bestimmung eines Trigger-Ereignisses, wenn die Anzahl der verworfenen Pakete in einem bestimmten Port und/oder in einem bestimmten Empfangspuffer während einer voreingestellten Zeitspanne die Anzahl der verworfenen Pakete in einer vorhergehenden voreingestellten Zeitspanne um mehr als einen voreingestellten Schwellenwert übersteigt, jedoch nur, wenn die Paketrate des Eingangsports über einem voreingestellten Minimum liegt.

In einem zweiten Beispiel wird ein Gegendruck von einem Host oder eine hohe Latenz von Host-NIC-Zugriffen (unter der Annahme, dass der Host mit dem NIC über einen Peripheral-Component Interconnect Express (PCIe) Bus kommuniziert) beobachtet. Die Datenquellen für die Triggerprotokollierung können so eingestellt werden, dass sie Folgendes umfassen:

1. Flow Control (FC) Gutschriften aus einem Root-Komplex (RC) von gebuchten Datenanfragen.
2. FC-Gutschriften aus RC von nicht gebuchten Datenanfragen.
3. FC-Gutschriften aus dem RC von nicht gebuchten Antragsheadern.
4. PCIe-Tags.

Die Regeln für die Triggerprotokollierung können z.B. festgelegt werden:

1. um ein Auslöseereignis zu bestimmen, wenn eine oder alle Auslösedatenquellen (siehe oben) während eines voreingestellten Zeitraums kein Guthaben aufweisen.
2. um ein Trigger-Ereignis zu bestimmen, wenn die Anzahl der Zero-Credit-Ereignisse in einer oder allen Trigger-Datenquellen während eines bestimmten Zeitraums die Anzahl der Zero-Credit-Ereignisse in einem vorhergehenden, voreingestellten Zeitraum um einen voreingestellten Betrag (oder Prozentsatz) übersteigt.

Die oben beschriebene Struktur des Netzwerkgeräts 100 und des HDC 106 sowie die Methode des Flussdiagramms 400 sind nur als Beispiel zu verstehen. Netzwerkgeräte, HDCs und Verfahren gemäß den offenbarten Techniken sind nicht auf die obige Beschreibung beschränkt. In alternativen Ausführungsformen kann z.B. der HDC in dem Betriebsschaltkreis verteilt sein; der HDC-Daten-Log-Puffer 114 kann z.B. in der Nähe der Log-Datenquellen verteilt sein. In einigen Ausführungsformen können Triggerereignisse verkettet sein, z.B. kann der HDC so konfiguriert sein, dass er ein erstes Triggerereignis und dann ein zweites Triggerereignis (und manchmal mehr) erkennt; die vor dem ersten Triggerereignis, zwischen dem ersten und dem zweiten Triggerereignis und nach dem zweiten Triggerereignis zu protokollierenden Daten können voreingestellt sein.
Der Prozessor 104 besteht in der Regel aus einem Mehrzweckprozessor, der in Software programmiert ist, um die hier beschriebenen Funktionen auszuführen. Die Software kann in elektronischer Form, z.B. über ein Netzwerk, auf den Prozessor heruntergeladen werden, oder sie kann alternativ oder zusätzlich auf nicht übertragbaren materiellen Medien, z.B. einem magnetischen, optischen oder elektronischen Speicher, bereitgestellt und/oder gespeichert werden.
Die Konfiguration des Netzgeräts 100, einschließlich des HDC 106, und die Methode des Flussdiagramms 400 sind Beispielkonfigurationen und -methoden, die nur aus Gründen der konzeptionellen Klarheit dargestellt sind. In alternativen Ausführungsformen können andere geeignete Konfigurationen und Flussdiagramme verwendet werden.
Die Elemente des HDC 106 können mit geeigneter Hardware, z.B. in einem oder mehreren anwendungsspezifischen integrierten Schaltkreisen (ASICs) oder feldprogrammierbaren Gate-Arrays (FPGAs), mit Software, mit Hardware oder mit einer Kombination aus Hardware- und Softwareelementen implementiert werden.
Obwohl sich die hier beschriebenen Ausführungsformen hauptsächlich mit der Diagnose von Netzwerkgeräten befassen, können die hier beschriebenen Verfahren und Vorrichtungen auch in anderen Anwendungen wie der Fehlersuche und Diagnose beliebiger digitaler Geräte eingesetzt werden. In einer Ausführungsform ist ein HDC in einen Netzwerk-Switch mit mehreren Eingangs- und Ausgangsports eingebettet, und die Auswahl eines Ports für die Fehlersuche (aus den Eingangs- und Ausgangsports) basiert auf einem Auslöser und auf Datenquellen von den verschiedenen Ports.
Es wird daher deutlich, dass die oben beschriebenen Ausführungsformen als Beispiele angeführt werden und dass die vorliegende Erfindung nicht auf das beschränkt ist, was hierin besonders gezeigt und beschrieben wurde. Vielmehr umfasst der Umfang der vorliegenden Erfindung sowohl Kombinationen und Unterkombinationen der verschiedenen hierin beschriebenen Merkmale als auch Variationen und Modifikationen davon, die dem Fachmann beim Lesen der vorstehenden Beschreibung einfallen würden und die im Stand der Technik nicht offenbart sind. Dokumente, die durch Verweis in die vorliegende Patentanmeldung aufgenommen wurden, sind als integraler Bestandteil der Anmeldung zu betrachten, mit der Ausnahme, dass in dem Maße, in dem Begriffe in diesen aufgenommenen Dokumenten in einer Weise definiert werden, die im Widerspruch zu den in der vorliegenden Beschreibung explizit oder implizit gemachten Definitionen steht, nur die Definitionen in der vorliegenden Beschreibung berücksichtigt werden sollten.
Es versteht sich, dass die oben beschriebenen Aspekte und Ausführungsformen nur beispielhaft sind und dass im Rahmen der Ansprüche Änderungen im Detail vorgenommen werden können.
Jedes Gerät, Verfahren und Merkmal, das in der Beschreibung und (gegebenenfalls) in den Ansprüchen und Zeichnungen offenbart wird, kann unabhängig oder in jeder geeigneten Kombination bereitgestellt werden.
Die in den Ansprüchen enthaltenen Bezugszahlen dienen nur der Veranschaulichung und haben keine einschränkende Wirkung auf den Umfang der Ansprüche.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 7730458 [0003]
US 2008/0077835 [0004]

Claims

Ein Gerät, umfassend: Betriebsschaltkreis; und Hardware-Diagnose-Schaltkreis (HDC), konfiguriert für: das Empfangen einer Definition mehrerer Triggerregeln, wobei jede Triggerregel die Auslösung eines jeweiligen Triggerereignisses in Abhängigkeit von einer oder mehreren Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert; das Empfangen einer Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) eines jeweiligen Post-Trigger-Protokollierungssatzes für jede Triggerregel, der einen jeweiligen Satz von einer oder mehreren der Diagnosedatenquellen umfasst; und während des Betriebs des Betriebsschaltkreises, das wiederholte Protokollieren der Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz , das wiederholte Protokollieren der Triggerdatenquellen und das wiederholte Protokollieren der Triggerregeln und das Beginnen der Protokollierung der Diagnosedatenquellen im Post-Trigger-Protokollierungssatz der bestimmten Triggerregel als Reaktion auf das Auslösen eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel.
Die Vorrichtung nach Anspruch 1, wobei mindestens ein Post-Trigger-Protokollierungssatz von dem Pre-Trigger-Protokollierungssatz verschieden ist.
Die Vorrichtung nach Anspruch 1 oder 2, wobei der HDC so konfiguriert ist, dass er die Diagnosedatenquellen im Post-Trigger-Protokollierungssatz über ein definiertes Zeitintervall oder bis zu einer definierten Datengröße protokolliert.
Die Vorrichtung nach Anspruch 3, wobei das definierte Zeitintervall oder die definierte Datengröße pro Triggerregel festgelegt wird.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der HDC so konfiguriert ist, dass er nur bis zu einer definierten Menge der jüngsten Daten aus den Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz speichert.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der HDC so konfiguriert ist, dass er Bilder der Diagnosedatenquellen protokolliert, die relativ zueinander zeitkohärent sind.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der HDC so konfiguriert ist, dass er die Diagnosedatenquellen in einem Speicher protokolliert und als Reaktion auf einen Dump-Befehl zumindest einen Teil der protokollierten Pre-Trigger- und Post-Trigger-Protokollierungssätze ausgibt.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei mindestens eine der Auslöseregeln eine Bedingung angibt, die von den Auslöserdatenquellen über ein definiertes Zeitintervall erfüllt werden muss.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei mindestens eine der Auslöseregeln eine statistische Bedingung angibt, die von den Auslöserdatenquellen erfüllt werden muss.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der Betriebsschaltkreis so konfiguriert ist, dass er Kommunikationspakete verarbeitet, und wobei eine oder mehrere der Auslöseregeln sich auf die Durchführung der Paketverarbeitung durch den Betriebsschaltkreis beziehen.
Die Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der Betriebsschaltkreis so konfiguriert ist, dass sie über einen Bus kommuniziert, und wobei sich eine oder mehrere der Auslöseregeln auf die Durchführung der Buskommunikation durch den Betriebsschaltkreis beziehen.
Ein Verfahren, das Folgendes umfasst: Empfangen einer Definition mehrerer Triggerregeln in einer Hardware-Diagnose-Schaltung (HDC), die mit einem Betriebsschaltkreis gekoppelt ist, wobei jede Triggerregel die Auslösung eines jeweiligen Triggerereignisses in Abhängigkeit von einer oder mehreren Triggerdatenquellen in dem Betriebsschaltkreis spezifiziert; Empfangen einer Definition (i) eines Pre-Trigger-Protokollierungssatzes, der aus einer Vielzahl von Diagnosedatenquellen in dem Betriebsschaltkreis ausgewählt wird, und (ii) eines jeweiligen Post-Trigger-Protokollierungssatzes für jede Triggerregel im HDC, der einen jeweiligen Satz von einer oder mehreren Diagnosedatenquellen umfasst,; und während des Betriebs des Betriebsschaltkreises, unter Verwendung des HDC, wiederholt Protokollieren der Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz, wiederholt Protokollieren der Triggerdatenquellen und wiederholt Protokollieren der Triggerregeln, und Beginnen der Protokollierung der Diagnosedatenquellen im Post-Trigger-Protokollierungssatz der bestimmten Triggerregel als Reaktion auf das Auslösen eines bestimmten Triggerereignisses durch eine bestimmte Triggerregel.
Das Verfahren nach Anspruch 12, wobei sich mindestens ein Post-Trigger-Protokollierungssatz von dem Pre-Trigger-Protokollierungssatz unterscheidet.
Das Verfahren nach Anspruch 12 oder 13, wobei die Protokollierung der Diagnosedatenquellen im Post-Trigger-Protokollierungssatz über ein definiertes Zeitintervall oder bis zu einer definierten Datengröße erfolgt.
Das Verfahren nach Anspruch 14, wobei das definierte Zeitintervall oder die definierte Datengröße pro Triggerregel festgelegt wird.
Das Verfahren nach einem der Ansprüche 12 bis 15, wobei die Protokollierung der Diagnosedatenquellen darin besteht, dass nur bis zu einer bestimmten Menge der jüngsten Daten aus den Diagnosedatenquellen im Pre-Trigger-Protokollierungssatz gespeichert werden.
Das Verfahren nach einem der Ansprüche 12 bis 16, wobei das Aufzeichnen der Diagnosedatenquellen das Aufzeichnen von Bildern der Diagnosedatenquellen umfasst, die relativ zueinander zeitkohärent sind.
Das Verfahren nach einem der Ansprüche 12 bis 17, wobei das Protokollieren der Diagnosedatenquellen das Protokollieren der Diagnosedatenquellen in einem Speicher und als Reaktion auf einen Dump-Befehl das Ausgeben mindestens eines Teils der protokollierten Pre-Trigger- und Post-Trigger-Protokollierungssätze umfasst.
Das Verfahren nach einem der Ansprüche 12 bis 18, wobei mindestens eine der Auslöseregeln eine Bedingung angibt, die von den Auslöserdatenquellen über ein definiertes Zeitintervall erfüllt werden muss.
Das Verfahren nach einem der Ansprüche 12 bis 19, wobei mindestens eine der Auslöseregeln eine statistische Bedingung angibt, die von den Auslöserdatenquellen erfüllt werden muss.
Das Verfahren nach einem der Ansprüche 12 bis 20, wobei sich eine oder mehrere der Auslöseregeln auf die Durchführung der Verarbeitung von Kommunikationspaketen durch den Betriebsschaltkreis beziehen.
Das Verfahren nach einem der Ansprüche 12 bis 21, wobei sich eine oder mehrere der Auslöseregeln auf die Durchführung der Kommunikation über einen Bus durch den Betriebsschaltkreis beziehen.