-
TECHNISCHES GEBIET
-
Die vorliegende Offenbarung betrifft allgemein Systeme auf Chips (SoC) und insbesondere Debug-Umgebungen für SoC.
-
STAND DER TECHNIK
-
Debugger sind spezialisierte Software (und ihre zugeordnete Unterstützungshardware), die etwaige Fehler (Bugs) in einem Zielsystem, wie etwa einem System auf einem Chip, detektieren und korrigieren. Debugger bevorzugen es, eine saubere Debug-Sitzung bereitzustellen, indem das Zielsystem in einen bekannten Zustand gebracht wird. Man erreicht dies am besten durch Rücksetzen der Nicht-Debug-Domäne des Zielsystems auf einen bekannten Zustand vor dem Beginnen einer Debug-Sitzung, ohne Auswirkung auf die Debug-Domäne des Zielsystems. Obwohl existierende Nicht-Debug-Domänen-Systemrücksetzmechanismen im Allgemeinen für ihre beabsichtigten Zwecke ausreichend waren, sind sie nicht in jeder Hinsicht ganz zufriedenstellend gewesen.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die vorliegende Offenbarung wird am besten aus der folgenden ausführlichen Beschreibung in Verbindung mit den beigefügten Figuren verständlich. Es wird betont, dass gemäß der Standardpraxis in der Industrie verschiedene Merkmale nicht maßstabsgetreu gezeichnet sind und lediglich zur Veranschaulichung verwendet werden. Tatsächlich kann die Abmessung der verschiedenen Merkmale der Klarheit der Besprechung halber willkürlich vergrößert oder verkleinert sein.
-
1 ist eine schematische Blockdarstellung einer beispielhaften Debug-Umgebung gemäß verschiedenen Aspekten der vorliegenden Offenbarung.
-
2 ist eine schematische Blockdarstellung eines beispielhaften Debug-Trigger-Schnittstellen-Systemrücksetzmechanismus, der in der Debug-Umgebung von 1 implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung.
-
3 ist ein Flussdiagramm eines beispielhaften Verfahrens, das zur Bereitstellung eines Nicht-Debug-Domänen-Rücksetzens in einer Debug-Umgebung, wie etwa der Debug-Umgebung von 1, implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung.
-
4 ist ein Flussdiagramm eines beispielhaften Verfahrens, das zur Bereitstellung eines Nicht-Debug-Domänen-Systemrücksetzens in einer Debug-Umgebung, wie etwa der Debug-Umgebung von 1, implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung.
-
ÜBERSICHT ÜBER BEISPIELHAFTE AUSFÜHRUNGSFORMEN
-
Ein System, wie etwa ein System auf einem Chip, weist eine Nicht-Debug-Domäne und eine Debug-Domäne auf. Die Debug-Domäne weist einen Debug-Rahmen auf, der ein Debugger-gesteuertes Nicht-Debug-Domänen-Systemrücksetzen ermöglicht. Das System weist eine Rücksetzsteuereinheit und einen Debug-Triggermechanismus auf, der eine Debug-Trigger-Schnittstelle (DTI) aufweist, die mit der Rücksetzsteuereinheit verbunden ist. Die DTI ist zum Triggern der Rücksetzsteuereinheit zum Rücksetzen der Nicht-Debug-Domäne ausgebildet. Die DTI kann ferner ausgebildet sein zum Überwachen eines Status des Nicht-Debug-Domänen-Systemrücksetzens.
-
Bei einigen Implementierungen weist die DTI einen mit einer Nicht-Debug-Domänen-Systemrücksetzanforderung der Rücksetzsteuereinheit verbundenen Triggerausgang und einen mit einem Nicht-Debug-Domänen-Systemrücksetzstatus der Rücksetzsteuereinheit verbundenen Triggereingang auf. Der Triggerausgang kann über einen Inverter mit der Nicht-Debug-Domänen-Systemrücksetzanforderung verbunden sein und der Triggereingang kann über einen Inverter mit dem Nicht-Debug-Domänen-Systemrücksetzstatus verbunden sein. Die DTI kann ein Anwendungstriggerregister aufweisen, das dafür ausgebildet ist, zu bewirken, dass die DTI eine Nicht-Debug-Domänen-Systemrücksetzanforderung an die Rücksetzsteuereinheit ausgibt (setzt). Die DTI kann ferner einen Anwendungstrigger im Statusregister aufweisen, der dafür ausgebildet ist, einen Status des Nicht-Debug-Domänen-Systemrücksetzens anzugeben. Ein mit dem System verbundener Debugger verwendet das Anwendungstriggerregister und den Anwendungstrigger im Statusregister für Debugger-Nicht-Debug-System-Rücksetz-Setzungsoperationen. Zum Beispiel kann der Debugger das Anwendungstriggerregister auf einen Zustand programmieren, der bewirkt, dass die DTI die Nicht-Debug-Domänen-Systemrücksetzanforderung an die Rücksetzsteuereinheit ausgibt (setzt). Der Debugger kann auch den Anwendungstrigger im Statusregister überwachen, um den Status des Nicht-Debug-Domänen-Systemrücksetzens zu bestimmen.
-
AUSFÜHRLICHE BESCHREIBUNG VON BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
-
Debugger sind spezialisierte Software (und ihre zugeordnete Unterstützungshardware), die etwaige Fehler (Bugs) in einem Zielsystem detektieren und korrigieren. Debugger bevorzugen, eine saubere Debug-Sitzung bereitzustellen, indem alle Blöcke geistigen Eigentums (IP – Intellectual Property) des Zielsystems, wie etwa eines Systems auf einem Chip (Soc) auf einen bekannten Zustand gebracht werden. Man erreicht dies am besten durch Rücksetzen der Nicht-Debug-Domäne des Zielsystems (zum Beispiel aller Nicht-Debug-IP-Blöcke) auf einen bekannten Zustand vor dem Beginnen einer Debug-Sitzung ohne Auswirkung auf die Debug-Domäne des Zielsystems, wie etwa etwaige Debug-Logik, die bereits initialisiert wurde, um Debug-Operationen auszuführen.
-
Debugger treten in der Regel mit einem Debug-Rahmen, wie etwa dem Debug- und Trace-Rahmen ARM® CoreSightTM, der dem Zielsystem zugeordnet ist, in Interaktion, um gewünschte Debug-Operationen zu erreichen. Derzeit unterstützen SoC-Debug-Rahmen nicht, dass Debugger direkt ein Nicht-Debug-Domänen-Systemrücksetzen bereitstellen. Zum Beispiel kann ein SoC, das mit dem Debug- und Trace-Rahmen ARM® CoreSightTM konfiguriert ist, einen Debug-Zugangsport aufweisen, der direkte Steuer-/Statussignalisierungs- und Handshakemechanismen zur Ermöglichung von Debug-Domänen-Herauffahren, Nicht-Debug-Domänen-Herauffahren und Debug-Domänen-Rücksetzen, nicht aber Nicht-Debug-Domänen-Systemrücksetzen, aufweist. Bei einigen Konfigurationen erfordert ein Modell des Debug- und Trace-Systems ARM® CoreSightTM, dass ein Kernprozessor des SoC einen spezifischen Prozess ausführt, der es einem Debugger ermöglicht, indirekt ein Nicht-Debug-Domänen-Systemrücksetzen einzuleiten. Indirekte Nicht-Debug-Domänen-Systemrücksetzvorgänge können jedoch Probleme verursachen, da die den indirekten Systemrücksetzvorgängen zugeordneten Operationen typischerweise Komponenten aufweisen, die durch das Systemrücksetzen beeinflusst werden, so dass die Operationen nicht ohne Protokollverstöße und/oder -Fehler abgeschlossen werden können.
-
Um solche Probleme anzugehen, schlägt die folgende Offenbarung einen Zielsystem-Debug-Rahmen vor, der mit einem Nicht-Debug-Domänen-Systemrücksetzmechanismus konfiguriert ist, der es einem Debugger ermöglicht, eine Nicht-Debug-Domäne des Zielsystems auf einen bekannten Zustand zu bringen. Der Debug-Rahmen nutzt eine Debug-Triggerschnittstelle (wie etwa eine durch den Debug- und Trace-Rahmen ARM® CoreSightTM bereitgestellte Quer-Trigger-Schnittstelle) zur Erzeugung von Steuer-/Statussignalisierung und Handshakemechanismen zur Ermöglichung des Nicht-Debug-Domänen-Systemrücksetzens. Verschiedene Ausführungsformen können verschiedene Vorteile aufweisen und von jeglichen der hier beschriebenen Ausführungsformen wird nicht unbedingt ein konkreter Vorteil erfordert.
-
1 ist eine schematische Blockdarstellung einer beispielhaften Debug-Umgebung 10 zum Ausführen von Debugging- und Tracing-Operationen gemäß verschiedenen Aspekten der vorliegenden Offenbarung. Wie nachfolgend beschrieben wird, stellt die Debug-Umgebung 10 ein Debugger-gesteuertes Nicht-Debug-Domänen-Systemrücksetzen bereit. 1 wurde der Klarheit halber vereinfacht, um das Verständnis der erfindungsgemäßen Konzepte der vorliegenden Offenbarung zu erleichtern. Es können zusätzliche Merkmale in der Debug-Umgebung 10 hinzugefügt werden, und einige der beschriebenen Merkmale können in der Debug-Umgebung 10 ersetzt oder beseitigt sein.
-
In 1 weist ein Debug-Hostsystem 20 (das auch als Debug-Host oder externer Debugger bezeichnet wird) einen Prozessor 22 auf, der Software, wie etwa einen Debugger 24, zum Debugging und Tracing verschiedener Komponenten eines damit verbundenen Zielsystems ausführt. Der Debugger 24 kann mit einer Nicht-Debug-Domäne und einer Debug-Domäne, die dem Zielsystem zugeordnet ist, kommunizieren, um die Debugging- und Tracing-Operationen zu ermöglichen. Bei verschiedenen Implementierungen sendet das Debug-Hostsystem 20 verschiedene Debug- und Trace-Anforderungen zu einem dem Zielsystem zugeordneten Debug- und Trace-System, das diese Anforderungen ausführen und diese Anforderungen betreffende Informationen zu dem Debug-Hostsystem 20 senden kann.
-
Für die Zwecke der folgenden Besprechung wird das Zielsystem als ein System auf einem Chip (SoC) 30 abgebildet, wobei Komponenten des Zielsystems in einem einzigen Chip integriert sind. Das SoC 30 weist eine Systemzwischenverbindung 32 auf, die verschiedene Komponenten des SoC 30 miteinander verbindet. Zum Beispiel kann das SoC 30 einen Prozessor 34, einen Prozessor 36, einen Speicher 37 und verschiedene andere mit der Systemzwischenverbindung 32 verbundene Komponenten aufweisen, so dass der Prozessor 34, der Prozessor 36, der Speicher 37 und die verschiedenen anderen Komponenten über die Systemzwischenverbindung 32 miteinander kommunizieren können. Bei der abgebildeten Ausführungsform ist der Prozessor 36 ein digitaler Signalprozessor (DSP). Die verschiedenen Komponenten des SoC 30 können verschiedene Systeme bereitstellen, darunter, aber ohne Beschränkung darauf, Speichersysteme, Video-/Grafiksysteme, Audiosysteme, Power-Management-Systeme, Sicherheitssysteme, Eingabe-/Ausgabesysteme, verdrahtete/drahtlose Konnektivitätssysteme oder eine Kombination davon.
-
Eine RCU-Einheit (Rücksetzsteuereinheit) 38 ist ausgebildet zum Rücksetzen des SoC 30 und/oder verschiedener Komponenten des SoC 30, wie etwa des Prozessors 34 und/oder des Prozessors 36, bei einem hardwaregetriggerten Ereignis und/oder einem softwaregetriggerten Ereignis. Die Rücksetzsteuereinheit 38 kann steuern, wie das SoC 30 und seine verschiedenen Komponenten in das Rücksetzen eintreten und es verlassen, darunter ein Hardwarerücksetzen, ein Systemrücksetzen, ein Nur-Prozessor-Rücksetzen und/oder andere Arten von Rücksetzen. Rücksetzen bezieht sich im Allgemeinen auf einen bekannten Anfangszustand des SoC 30 und/oder verschiedener Komponenten des SoC 30, und Systemrücksetzen (das auch als ein Nicht-Debug-Domänen-Systemrücksetzen bezeichnet wird) bezieht sich im Allgemeinen auf das Setzen aller Komponenten des SoC 30, mit Ausnahme der Rücksetzsteuereinheit 38 und einer Debug-Domäne des SoC 30, auf ihren zugeordneten Vorgabezustand. Zur Einleitung eines Systemrücksetzens kann die Rücksetzsteuereinheit 38 Rücksetzsignalisierung über die Systemzwischenverbindung 32 zu dem Prozessor 34, dem Prozessor 36 und/oder anderen Komponenten des SoC 30 übermitteln. Bei verschiedenen Implementierungen weist die Rücksetzsteuereinheit 38 ein Rücksetzsteuerelement zum Triggern eines Nicht-Debug-Domänen-Systemrücksetzens auf. Das Rücksetzsteuerelement kann als ein Steuerregister implementiert werden, das ein Bit (oder mehrere Bit) aufweist, die die Setzung/Absetzung eines Nicht-Debug-Domänen-Systemrücksetzens steuern. Wie nachfolgend weiter beschrieben wird, ist die Debug-Umgebung 10 so ausgebildet, dass der Debugger 24 eine Nicht-Debug-Domänen-Systemrücksetzanforderung an die Rücksetzsteuereinheit 38 übermitteln kann und der Debugger 24 somit ein Nicht-Debug-Domänen-Systemrücksetzen des SoC 30 einleiten kann. Das Nicht-Debug-Domänen-Systemrücksetzen kann die gesamte Nicht-Debug-Domäne des SoC 30 (oder bei einigen Ausführungsformen Teile davon) ohne Beeinflussung der Debug-Domäne auf einen bekannten Vorgabezustand setzen.
-
Ein Debug- und Trace-System 40 des SoC 30 ermöglicht dem Debug-Hostsystem 20, auf verschiedene Komponenten des SoC 30 zuzugreifen und diese zu steuern, um Debugging und Tracing verschiedener Komponenten des SoC 30 zu erreichen. Bei verschiedenen Implementierungen kann das Debug- und Trace-System 40 auf dem Debug- und Trace-Rahmen ARM® CoreSightTM basieren, der wie hier beschrieben modifiziert wird, um ein Nicht-Debug-Domänen-Systemrücksetzen von einer Debug-Domäne des SoC 30 aus zu erzielen. Das Debug- und Trace-System 40 weist einen Debug-Zugangsport (DAP) 42 auf, der Zugang zum SoC 30 bereitstellt. Bei verschiedenen Implementierungen kann der Debug-Zugangsport 42 mit einem JTAG-Debug-Port (Joint Test Action Group), einem SWD-Port (Serial Wire Debug), einem anderen geeigneten Debug-Port oder einer Kombination davon implementiert werden. Das Debug-Hostsystem 20 (insbesondere der Debugger 24) kann sich mittels des Debug-Zugangsports 42 mit dem SoC 30 verbinden und mit ihm kommunizieren, um Debugging- und Tracing-Operationen an dem Soc 30 auszuführen, und das Debug- und Trace-System 40 kann Debug-Informationen, Trace-Informationen und/oder andere Informationen mittels des Debug-Zugangsports 42 zu dem Debug-Hostsystem 20 übermitteln. Zum Beispiel kann bei der abgebildeten Ausführungsform das Debug-Hostsystem 20 mittels des mit dem Debug-Zugangsport 42 verbundenen Systembusses 32 auf Systembetriebsmittel (wie etwa den Prozessor 34, den Prozessor 36 und/oder Systemspeicher 37) zugreifen; das Debug-Hostsystem 20 kann auf Debug-Komponenten und Trace-Komponenten des SoC 30 (woraus das Debug- und Trace-System 40 besteht) mittels eines mit dem Debug-Zugangsport 42 verbundenen Debug-Busses 43 zugreifen; und das Debug-Hostsystem 20 kann mittels eines mit dem Debug-Zugangsport 42 verbundenen Trace-Busses 44 auf Trace-Daten und Trace-Informationen zugreifen. Der Debug-Bus 43 ist ausgebildet zum Verbinden von Debug- und Trace-Komponenten des SoC 30, wodurch Transfer von Debug-Daten und Debug-Informationen über das SOC 30 ermöglicht wird. Der Trace-Bus 44 ist zum Verbinden verschiedener Trace-Komponenten des SoC 30 ausgebildet, wodurch Transfer von Trace-Daten und Trace-Informationen über das SoC 30 ermöglicht wird. Bei verschiedenen Implementierungen kann der Debug-Bus 43 ein APB (Advanced Peripheral Bus) oder ein anderer geeigneter Debug-Bus sein, und der Trace-Bus 44 kann ein ATB (Advanced Trace Bus) oder ein anderer geeigneter Trace-Bus sein. Bei verschiedenen Implementierungen kann das Debug- und Trace-System 40 einen Debug-Speicher 45 aufweisen, der Informationen über jede Debug-Komponente und/oder Trace-Komponente, die mit dem Debug-Bus 43 verbunden ist, speichert. Zum Beispiel kann eine Nurlesespeicher- bzw. ROM-Tabelle einen Ort jeder Debug-Komponente und/oder Trace-Komponente (wie etwa des Prozessors 34, des Prozessors 36, des Debug-Zugangsports 42 und anderer Debug- und/oder Trace-Komponenten), die mit dem Debug-Bus 43 verbunden ist, speichern.
-
Das Debug- und Trace-System 40 weist ferner einen Debug-Triggermechanismus auf (wie etwa einen eingebetteten Quer-Trigger, der durch den Debug- und Trace-Rahmen ARM® CoreSightTM bereitgestellt wird) zum Übermitteln von Debug-Ereignissen über das SoC 30 hinweg. Zum Beispiel können der Prozessor 34, der Prozessor 36 und verschiedene andere Komponenten des Debug- und Trace-Systems 40 Debug-Ereignisse über den Debug-Triggermechanismus zueinander übermitteln. Zu Debug-Ereignissen können Anweisungs-Breakpoints, Daten-Breakpoints, Watchpoints und andere dem Debugging zugeordnete Nachrichten gehören. Bei verschiedenen Implementierungen ermöglicht der Debug-Triggermechanismus das Übermitteln von Debug-Ereignissen zu verschiedenen Endpunkten des SoC 30 zum Anhalten von Prozessorkernen und/oder Triggern der Trace-Erfassung. Debug-Triggermechanismus weist verschiedene Debug-Triggerschnittstellen (DTI) 46 auf (wie etwa durch den Debug- und Trace-Rahmen ARM® CoreSightTM bereitgestellte Quer-Trigger-Schnittstellen) und eine Debug-Trigger-Schnittstellenzwischenverbindung 48 (wie etwa eine durch den Debug- und Trace-Rahmen ARM® CoreSightTM bereitgestellte Quer-Trigger-Matrix), die die verschiedenen DTI 46 miteinander verbindet. In 1 verbindet eine DTI 46a den Prozessor 34 mit der DTI-Zwischenverbindung 48, eine DTI 46b verbindet den Prozessor 36 mit der DTI-Zwischenverbindung 48 und eine DTI 46c verbindet verschiedene Trace-Komponenten des Debug- und Trace-Systems 40 mit der DTI-Zwischenverbindung 48. Jede DTI ermöglicht ihrer zugeordneten SoC-Komponente (wie etwa dem Prozessor 34, dem Prozessor 36, der Debug-Komponente oder Trace-Komponente), Debug-Ereignisse (Trigger) auf der DTI-Zwischenverbindung 48 rundzusenden und auf diese zu antworten, wobei die DTI 48 Debug-Ereignisse von einer DTI zu anderen DTI rundsendet. Zum Beispiel bildet jede DTI Triggerereigniseingaben, die von ihrem zugeordneten System (wie etwa dem Prozessor 34 für die DTI 46a) empfangen werden, auf der DTI-Zwischenverbindung 48 zugeordnete Kanäle ab und bildet Kanaleingaben, die von der DTI-Zwischenverbindung 48 empfangen werden, auf Triggerereignisausgaben für ihr zugeordnetes System ab. Jede DTI kann außerdem (nicht gezeigte) zugeordnete DTI-Register aufweisen, mit denen der Debugger 24 interne Triggerereigniseingaben für die DTI 46 erzeugen kann, um somit Software-getriggerte Ereignisse zu ermöglichen.
-
Typischerweise implementiert das Debug- und Trace-System 40 Debug-Triggerschnittstellen (wie etwa DTI 46a, DTI 46b und DTI 46c) und ihre zugeordneten Signalisierungsmechanismen zum Übermitteln von Debug-Ereignissen und Steuern von solchen Debug-Ereignissen entsprechenden Debug-Aktionen. Die vorliegende Offenbarung erkennt, dass, da eine Debug-Triggerschnittstelle nur mit einem Debug-Domänen-Rücksetzen verbunden ist und somit durch jedes Nicht-Debug-Domänen-Systemrücksetzen nicht beeinflusst wird, die Debug-Triggerschnittstelle und ihre zugeordneten Signalisierungsmechanismen dafür ausgebildet werden können, ein Nicht-Debug-Domänen-Systemrücksetzen bereitzustellen, das kein typisches Debug-Ereignis oder eine typische Debug-Aktion ist. Insbesondere kann die Debug-Umgebung 10 eine Debug-Triggerschnittstelle und ihre zugeordnete Signalisierung nutzen, um es dem Debugger 24 zu ermöglichen, ein Nicht-Debug-Domänen-Systemrücksetzen eines Zielsystems, wie etwa des SoC 30, anzufordern und zu überwachen. Zum Beispiel weist in 1 der Debug-Triggermechanismus ferner eine System-DTI 50 auf, die mit der Rücksetzsteuereinheit 38 verbunden ist, wobei die System-DTI 50 dafür ausgebildet ist, einen Status eines Nicht-Debug-Domänen-Systemrücksetzens anzufordern und zu überwachen, wie nachfolgend weiter beschrieben wird.
-
In vielerlei Hinsicht ist die System-DTI 50 den DTI 46 ähnlich. Die System-DTI 50 ermöglicht ihrem zugeordneten System (wie etwa der Rücksetzsteuereinheit 38 oder einer anderen Komponente des SoC 30 (zum Beispiel einer Triggerroutungseinheit 52)), Debug-Ereignisse auf der DTI-Zwischenverbindung 48 rundzusenden und auf sie zu antworten. Zum Beispiel kann die System-DTI 50 ähnlich wie die DTI 46 Triggerereigniseingaben, die von der Rücksetzsteuereinheit 38 und/oder der Triggerroutungseinheit 52 empfangen werden, auf der DTI-Zwischenverbindung 48 zugeordnete Kanäle abbilden und Kanaleingaben, die von der DTI-Zwischenverbindung 48 empfangen werden, auf Triggerereignisausgaben für die Rücksetzsteuereinheit 38 und/oder die Triggerroutungseinheit 52 abbilden. Die System-DTI 50 aufweist ferner zugeordnete System-DTI-Register (in 1 nicht gezeigt), die es dem Debugger 24 erlauben, interne Triggerereigniseingaben für die System-DTI 50 zu erzeugen. Bei verschiedenen Implementierungen kann der Debugger 24 über den Debug-Bus 43 System-DTI-Register konfigurieren, um ein softwaregetriggertes Nicht-Debug-Domänen-Systemrücksetzen bereitzustellen, wobei die System-DTI 50 benutzt wird, um anzufordern, dass die Rücksetzsteuereinheit 38 ein Systemrücksetzen durchführt, und danach einen Status des Nicht-Debug-Domänen-Systemrücksetzens auf der Basis von System-Rücksetzstatussignalisierung, die von der Rücksetzsteuereinheit 38 empfangen wird, zu überwachen.
-
Falls das SoC 30 ein (nicht gezeigtes) System-Master-Anhalt-/-Neustartsteuerelement zum Triggern eines Systemanhaltens/Systemneustartens für System-Master (wie etwa den Prozessor 34, den Prozessor 36, einen DMA-Controller usw.) und ein (nicht gezeigtes) Systemperipherie-Anhalt-/Neustartsteuerelement zum Triggern eines Systemanhaltens/Systemneustartens für Systemperipheriegeräte (wie etwa einen Vielzwecktimer, einen Watchdog-Timer, einen Impulsbreitenmodulator usw.) aufweist, kann die System-DTI 50 ferner mit dem System-Master-Anhalt-/-Neustartsteuerelement und dem System-Peripherie-Anhalt-/-Neustartsteuerelement verbunden sein, wodurch es der System-DTI 50 erlaubt wird, Systemmasteranhalten/-Neustarten und Systemperipheriegeräteanhalten-/Neustarten einzuleiten. Das System-Master-Anhalt-/-Neustartsteuerelement und das System-Peripherieanhalt-/-Neustartsteuerelement können als Steuerregister implementiert werden, die jeweils ein Bit (oder mehrere Bit) aufweisen, das Setzung/Absetzung eines System-Master-Anhaltens/-Neustartens bzw. ein Bit (oder mehrere Bit), das Setzung/Absetzung eines Systemperipheriegeräteanhaltens/-Neustartens steuert, aufweisen. Bei einigen Implementierungen kann der Debugger 24 System-DTI-Register so konfigurieren, dass die System-DTI 50 System-Master-Anhalten/-Neustarten und/oder System-Peripheriegeräte-Anhalten/-Neustarten triggern kann. Bei einigen Implementierungen kann der Debugger 24 System-DTI-Register bezüglich eines Status des System-Master-Anhaltens/-Neustartens und/oder eines Status des System-Peripheriegeräteanhaltens/-Neustartens überwachen.
-
Nunmehr mit Bezug auf 2 ist 2 eine schematische Blockdarstellung eines beispielhaften Debug-Triggerschnittstellensystem-Rücksetzmechanismus, der in der Debug-Umgebung 10 von 1 implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung. In 2 nutzt der Debug-Trigger-Schnittstellensystem-Rücksetzmechanismus die System-DTI 50 und ihre zugeordnete Signalisierung, um es dem Debugger 24 zu ermöglichen, ein Nicht-Debug-Domänen-Systemrücksetzen anzufordern und zu überwachen. Nutzung der Signalisierung von der System-DTI 50 stellt der Rücksetzsteuereinheit 38 eine nahtlose Lösung zum Einleiten eines Systemrücksetzens direkt von der Debug-Logik aus bereit. Bei einigen Implementierungen ist die System-DTI 50 eine Quer-Trigger-Schnittstelle (CTI) von ARM® CoreSightTM, wobei die Signalisierung der CTI von ARM® CoreSightTM (einschließlich CTI-Registern von ARM® CoreSightTM) genutzt wird, um Nicht-Debug-Domänen-Systemrücksetzen einzuleiten. 2 wurde der Klarheit halber vereinfacht, um das Verständnis der erfindungsgemäßen Konzepte der vorliegenden Offenbarung zu erleichtern. Es können in dem Debug-Triggerschittstellensystem-Rücksetzmechanismus zusätzliche Merkmale hinzugefügt werden, und einige der beschriebenen Merkmale können in anderen Ausführungsformen des Debug-Triggerschnittstellensystem-Rücksetzmechanismus ersetzt oder beseitigt sein.
-
Die System-DTI 50 weist eine Trigger-Eingangs-Schnittstelle auf, die zum Empfangen verschiedener Triggereingaben von der Rücksetzsteuereinheit 38 und/oder einem anderen zugeordneten System (wie etwa der Triggerroutungseinheit 52) ausgebildet ist, und eine Trigger-Ausgangs-Schnittstelle, die zum Senden verschiedener Triggerereignisausgaben an die Rücksetzsteuereinheit 38 und/oder einem anderen zugeordneten System ausgebildet ist. Zum Beispiel weist die System-DTI 50 m Triggereingänge und n Triggerausgänge auf, wobei m die Gesamtzahl der Triggereingänge ist, die der Trigger-Eingangs-Schnittstelle zugeordnet sind, und n die Gesamtzahl der Triggerausgänge ist, die der Trigger-Ausgangs-Schnittstelle zugeordnet sind. Bei verschiedenen Implementierungen weist die System-DTI 50 einen Triggereingang und einen Triggerausgang auf, der für Nicht-Domänen-Systemrücksetzsignalisierung ausgebildet ist. In 2 ist ein Triggereingang M (DTITRIGIN[M]) mit Systemrücksetzstatussignalisierung der Rücksetzsteuereinheit 38 verbunden (wobei M eine ganze Zahl von 1 bis m ist), so dass die System-DTI 50 einen Systemrücksetzstatus von der Rücksetzsteuereinheit 38 empfangen kann, und ein Triggerausgang N (DTITRIGOUT[N]) ist mit Systemrücksetzanforderungssignalisierung der Rücksetzsteuereinheit 38 verbunden (wobei N eine ganze Zahl von 1 bis n ist), so dass die System-DTI 50 anfordern kann, dass die Rücksetzsteuereinheit 38 ein Nicht-Debug-Domänen-Systemrücksetzen einleitet (setzt). Der Debugger 24 kann eine Nicht-Debug-Domänen-Systemrücksetzanforderung ausgeben, indem die DTI 50 dafür konfiguriert wird, eine Nicht-Debug-Domänen-Systemrücksetzanforderung über den Triggerausgang N (DTITRIGOUT[N]) an die Rücksetzsteuereinheit 38 auszugeben (zu setzen), und kann ferner einen Status des Nicht-Debug-Domänen-Systemrücksetzens beobachten, indem ein Nicht-Debug-Domänen-Systemrücksetzstatus überwacht wird, der durch die DTI 50 über den Triggereingang M (DTITRIGIN[M]) von der Rücksetzsteuereinheit 38 empfangen wird. Bei einigen Implementierungen ist der Triggereingang M (DTITRIGIN[M]) über einen Inverter 54 mit einem Systemrücksetzstatusausgang der Rücksetzsteuereinheit 38 verbunden, und der Triggerausgang N (DTITRIGOUT[N]) ist über einen Inverter 56 mit einem Systemrücksetzanforderungseingang verbunden. Invertierung einer Nicht-Debug-Domänen-Systemrücksetzsignalisierung kann zum Beispiel implementiert werden, wenn die Rücksetzsteuereinheit 38 für System-Rücksetzzwecke Aktiv-Niedrig-Eingänge verwendet, wie etwa die Systemrücksetzanforderungslogik.
-
Die System-DTI 50 weist ferner einen System-DTI-Registersatz 60 auf, den der Debugger 24 konfigurieren kann, um Systemrücksetzsignalisierung zu erzeugen und Systemrücksetzstatussignalisierung zu beobachten. Jedes System-DTI-Register kann ein 32-Bit-Register sein, obwohl die vorliegende Offenbarung System-DTI-Register beliebiger Größe in Betracht zieht. Bei der abgebildeten Ausführungsform weist ein System-DTI-Registersatz 60 ein DTI-Trigger-Kanal-zu-Freigaberegister (DTIINEN) 62a auf, ein DTI-zu-Kanal-Trigger-Freigaberegister (DTIOUTEN) 62b, ein DTI-Anwendungstriggersetszregister (DTIAPPSET) 62c, ein DTI-Anwendungs-Triggerlöschregister (DTIAPPCLEAR) 62d, ein DTI-Trigger-Eingangs-Statusregister (DTITRIGINSTATUS) 62e, ein DTI-Anwendungsimpulsregister (DTIAPPPULSE) 62f und/oder andere verschiedene System-DTI-Register. Bei einigen Implementierungen ist der System-DTI-Registersatz 60 ein Registersatz der Quer-Trigger-Schnittstelle (CTI) von ARM® CoreSightTM, der ein CTI-Trigger-zu-Kanal-Freigaberegister, ein CTI-Kanal-zu-Trigger-Freigaberegister, ein CTI-Anwendungstriggerlöschregister, ein CTI-Trigger-Eingangs-Statusregister, ein CTI-Anwendungs-Trigger-Setzregister, ein CTI-Anwendungsimpulsregister und/oder ein anderes CTI-Register aufweist. Wie nachfolgend beschrieben kann der Debugger 24 eine Nicht-Debug-Domänen-Systemrücksetzanforderung ausgeben, indem das DTI-Anwendungs-Trigger-Setzregister 62c konfiguriert (zum Beispiel beschrieben) wird. Ferner kann der Debugger 24 einen Status des Nicht-Debug-Domänen-Systemrücksetzens beobachten, indem das DTI-Trigger-Eingangs-Statusregister 62e überwacht (zum Beispiel gelesen) wird. Bei der abgebildeten Ausführungsform implementiert die Rücksetzsteuereinheit 38 Aktiv-Niedrig-Zustände für Nicht-Debug-Domänen-Systemrücksetzzwecke. Durch Invertieren eines Triggerausgangssignals vom Triggerausgang N und Verbinden des invertierten Triggerausgangssignals mit einer Systemrücksetzanforderung der Rücksetzsteuereinheit 38 kann dementsprechend der Debugger 24 eine Nicht-Debug-Domänen-Systemrücksetzanforderung ausgeben, indem das DTI-Anwendungstrigger-Setzregister 62c konfiguriert (z. B. beschrieben) wird. Ferner kann durch Invertieren eines Systemrücksetzsignals von der Rücksetzsteuereinheit 38 und Verbinden des invertierten Systemrücksetzsignals mit dem Triggereingang N der Debugger 24 einen Status des Nicht-Debug-Domänensystemrücksetzens beobachten, indem das DTI-Trigger-Eingangs-Statusregister 62e überwacht (z. B. gelesen) wird.
-
Das DTI-Trigger-zu-Kanal-Freigaberegister 62a ist ein Lese-/Schreibregister, das Signalisierung eines Ereignisses auf einem Kanal der DTI-Zwischenverbindung 48 ermöglicht, wenn die Rücksetzsteuereinheit 38 oder ein anderes zugeordnetes System (wie etwa die Triggerroutungseinheit 52) eine Triggerereigniseingabe an die System-DTI 50 ausgibt. Jede Triggereingabe der System-DTI 50 kann ein zugeordnetes DTI-Trigger-zu-Kanal-Freigaberegister 62a aufweisen. Zum Beispiel kann der System-DTI-Registersatz 60 m DTI-Trigger-zu-Kanal-Freigaberegister 62a aufweisen. Das DTI-Trigger-zu-Kanal-Freigaberegister 62a weist einen Freigabetrigger in Bit (oder mehreren Bit) auf, die jedem Kanal der DTI-Zwischenverbindung 48 zugeordnet sind, die auf einen ersten Zustand, wie etwa einen Niedrig-Zustand (zum Beispiel eine digitale 0) oder einen zweiten Zustand, wie etwa einen Hoch-Zustand (zum Beispiel eine digitale 1) gesetzt werden können. Für einen gegebenen Kanal hindert ein auf den ersten Zustand gesetztes Freigabetrigger-Eingangs-Bit eine Triggereingabe daran, ein Ereignis auf dem Kanal zu erzeugen; und das auf den zweiten Zustand gesetzte Freigabe-Trigger-Eingangs-Bit ermöglicht, dass die Triggereingabe ein Ereignis auf dem Kanal erzeugt. In dem vorliegenden Beispiel kann das DTI-Trigger-zu-Kanal-Freigaberegister 62a dem Triggereingang M (DTITRIGIN[M]) zugeordnet sein. Da der Triggereingang M für den Empfang einer Nicht-Debug-Domänen-Systemrücksetzstatussignalsierung von der Rücksetzsteuereinheit 38 gewidmet ist, kann jedes Freigabe-Trigger-Eingangs-Bit auf den ersten Zustand (zum Beispiel eine digitale 0) gesetzt werden, um sicherzustellen, dass kein Kanalereignis erzeugt wird, wenn die System-DTI 50 ein Systemrücksetzstatussignal auf dem Triggereingang M von der Rücksetzsteuereinheit 38 empfängt. Für Nicht-Debug-Domänen-Systemrücksetzzwecke weist dementsprechend die System-DTI 50 einen Triggereingang (hier Triggereingang M) auf, der auf keinen Kanal abgebildet wird.
-
Das DTI-Kanal-zu-Trigger-Freigaberegister (DTIOUTEN) 62b ist ein Lese-/Schreibregister, das definiert, welcher Kanal bzw. welche Kanäle der DTI-Zwischenverbindung 48 eine Triggerausgabe erzeugen können. Im Allgemeinen bildet das DTI-Kanal-zu-Trigger-Freigaberegister 62b Anwendungstrigger, wie etwa softwaregetriggerte Ereignisse von dem Debugger 24, auf Triggerausgaben der System-DTI 50 ab. Jeder Triggerausgang der System-DTI 50 kann ein zugeordnetes DTI-Kanal-zu-Trigger-Freigaberegister 62b aufweisen. Zum Beispiel kann der System-DTI-Registersatz 60 n DTI-Kanal-zu-Trigger-Freigaberegister 62b aufweisen. Das DTI-Kanal-zu-Trigger-Freigaberegister 62b weist ein Freigabetrigger-Ausgangs-Bit (oder mehrere Bit) auf, das jedem Kanal der DTI-Zwischenverbindung 48 zugeordnet ist und auf den ersten Zustand (Niedrig-Zustand) oder den zweiten Zustand (Hoch-Zustand) gesetzt werden kann. Für einen gegebenen Kanal hindert ein auf den ersten Zustand gesetztes Freigabe-Trigger-Ausgangs-Bit einen Kanaleingang daran, zum Triggerausgang geroutet zu werden; und das auf den zweiten Zustand gesetzte Freigabe-Trigger-Ausgangs-Bit ermöglicht Routen des Kanaleingangs zum Triggerausgang. Wechseln eines Freigabe-Trigger-Ausgangs-Bit von dem ersten Zustand zu dem zweiten Zustand ermöglicht, dass ein Kanalereignis für den Kanal ein Triggerereignis auf dem Triggerausgang erzeugt. In dem vorliegenden Beispiel kann das DTI-Kanal-zu-Trigger-Freigaberegister 62b dem Triggerausgang N (DTITRIGOUT[N]) zugeordnet sein, und das DTI-Kanal-zu-Trigger-Freigaberegister 62b kann ein Freigabe-Trigger-Ausgangs-Bit aufweisen, das einem Kanal X der DTI-Zwischenverbindung 48 zugeordnet ist, der als ein Systemrücksetz-Anforderungskanal zugewiesen ist. Da der Triggerausgang N dem Senden von Nicht-Debug-Domänen-System-Rücksetzanforderungssignalisierung an die Rücksetzsteuereinheit 38 gewidmet ist, kann ein Kanal X zugeordnetes Freigabe-Trigger-Ausgangs-Bit auf den zweiten Zustand (zum Beispiel eine digitale 1) gesetzt werden, um sicherzustellen, dass jedes auf Kanal X durch den Debugger 24 getriggertes Kanalereignis zum Triggern von Ausgang N zur Rücksetzsteuereinheit 38 geroutet wird. Für Nicht-Debug-Domänen-Systemrücksetzzwecke weist dementsprechend die System-DTI 50 einen Triggerausgang auf (hier Triggerausgang N), der auf einen Kanal (hier Kanal X) abgebildet wird, der durch den Debugger 24 zum Triggern des Nicht-Debug-Domänen-Systemrücksetzens verwendet wird.
-
Das DTI-Anwendungs-Triggersetzregister (DTIAPPSET) 62c ist ein Lese-/Schreibregister, das es einer Anwendung, wie etwa dem Debugger 24, ermöglicht, ein Kanalereignis zu generieren. Das DTI-Anwendungs-Triggersetzregister 62c weist ein jedem Kanal der DTI-Zwischenverbindung 48 zugeordnetes Anwendungstriggerbit (oder mehrere Bit), das auf den ersten Zustand (Niedrig-Zustand) oder den zweiten Zustand (Hoch-Zustand) gesetzt werden kann. Für einen gegebenen Kanal kann der Debugger 24 ein Anwendungstriggerbit auf den zweiten Zustand setzen, um ein Kanalereignis für den Kanal zu erzeugen. Andernfalls wird das Anwendungstriggerbit auf den ersten Zustand gesetzt, wodurch angegeben wird, dass der Anwendungstrigger für den Kanal inaktiv ist. In dem vorliegenden Beispiel kann das DTI-Anwendungstriggersetzregister 62c ein Anwendungstriggerbit aufweisen, das Kanal X der DTI-Zwischenverbindung 48 zugeordnet ist, der als der Systemrücksetzanforderungskanal zugewiesen wurde. Für Nicht-Debug-Domänen-Systemrücksetzzwecke kann dementsprechend der Debugger 24 ein Nicht-Debug-Domänen-Systemrücksetzen einleiten, indem das Kanal X zugeordnete Anwendungstriggerbit auf den zweiten Zustand (zum Beispiel eine digitale 1) gesetzt wird, was bewirkt, dass ein Systemrücksetzkanalereignis auf Kanal X generiert wird. Da ein Kanalereignis auf Kanal X zu dem Triggerausgang N geroutet wird, der mit dem Systemrücksetzanforderungseingang der Rücksetzsteuereinheit 38 verbunden ist (als Folge davon, wie der Debugger 24 das DTI-Kanal-zu-Trigger-Freigaberegister 62b konfiguriert hat), kann der Debugger 24 eine Nicht-Debug-Domänen-Systemanforderung ausgeben, indem in das DTI-Anwendungstriggersetzregister 62c geschrieben wird.
-
Das DTI-Anwendungstriggerlöschregister (DTIAPPCLEAR) 62d ist ein Lese-/Schreibregister, das es einer Anwendung, wie etwa dem Debugger 24, ermöglicht, ein Kanalereignis zu löschen. Das DTI-Anwendungstriggerlöschregister 62d weist ein jedem Kanal der DTI-Zwischenverbindung 48 zugeordnetes Anwendungstrigger-Löschbit auf (oder mehrere Bit), das auf den ersten Zustand (Niedrig-Zustand) oder den zweiten Zustand (Hoch-Zustand) gesetzt werden kann. Für einen gegebenen Kanal kann der Debugger 24 ein Anwendungstrigger-Löschbit auf den zweiten Zustand setzen, um ein Kanalereignis für den Kanal zu löschen. Andernfalls wird das Anwendungstrigger-Löschbit auf den ersten Zustand gesetzt. In dem vorliegenden Beispiel kann das DTI-Anwendungstriggerlöschregister 62d ein Kanal X zugeordnetes Anwendungstrigger-Löschbit aufweisen. Für Nicht-Debug-Domänen-Systemrücksetzzwecke kann dementsprechend der Debugger 24 das Nicht-Debug-Domänen-Systemrücksetzen löschen, indem das Kanal X zugeordnete Anwendungstrigger-Löschbit auf den zweiten Zustand (zum Beispiel eine digitale 1) gesetzt wird, was das Löschen des Systemrücksetzkanalereignisses auf Kanal X bewirkt.
-
Als Alternative kann das DTI-Anwendungsimpulsregister (DTIAPPPULSE) 62e zur Setzung und Absetzung von Nicht-Debug-Domänen-Systemrücksetzen verwendet werden. Das DTI-Anwendungsimpulsregister 62e ist ein Nur-Schreib-Register, das es einer Anwendung, wie etwa dem Debugger 24, ermöglicht, für eine bestimmte Taktperiode, wie etwa eine Taktperiode des Debug-Triggermechanismus, einen Kanalereignisimpuls zu generieren. Im Gegensatz zu dem DTI-Anwendungstriggersetzregister 62c löscht sich das DTI-Anwendungsimpulsregister 62e selbst, so dass die Anwendung, wie etwa der Debugger 24, nach der Generierung das Kanalereignis nicht löschen muss. Das DTI-Anwendungsimpulsregister 62e weist ein jedem Kanal der DTI-Zwischenverbindung 48 zugeordnetes Anwendungsimpulsbit (oder mehrere Bit), das auf den ersten Zustand (Niedrig-Zustand) oder den zweiten Zustand (Hoch-Zustand) gesetzt werden kann. Für einen gegebenen Kanal kann der Debugger 24 ein Anwendungsimpulsbit auf den zweiten Zustand setzen, um einige Zeit lang, wie etwa für eine Taktperiode des Debug-Triggermechanismus, einen Kanalereignisimpuls für den Kanal zu erzeugen. Andernfalls wird das Anwendungsimpulsbit auf den ersten Zustand gesetzt, wodurch angegeben wird, dass der Anwendungstrigger für den Kanal inaktiv ist. Im vorliegenden Beispiel kann das DTI-Anwendungsimpulsregister 62e ein Anwendungsimpulsbit umfassen, das dem Kanal X der DTI-Zwischenverbindung 48 zugeordnet ist. Für Nicht-Debug-Domänensystemrücksetzzwecke kann der Debugger 24 dementsprechend ein Nicht-Debug-Domänen-Systemrücksetzen einleiten, indem das Kanal X zugeordnete Anwendungsimpulsbit auf den zweiten Zustand (zum Beispiel eine digitale 1) gesetzt wird, was Generierung eines Systemrücksetzkanal-Ereignisimpulses auf Kanal X für eine definierte Zeit bewirkt. Da ein Kanalereignis auf Kanal X zu dem Triggerausgang N geroutet wird, der mit dem Systemrücksetzanforderungseingang der Rücksetzsteuereinheit 38 verbunden ist, kann der Debugger 24 eine Nicht-Debug-Domänen-Systemanforderung ausgeben, indem in das DTI-Anwendungsimpulsregister 62e geschrieben wird, das nach der definierten Zeit automatisch gelöscht wird.
-
Das DTI-Trigger-Eingangs-Statusregister 62f ist ein Nurleseregister, das Trigger-Eingangs-Statusbits aufweist, die einen Status von Triggereingängen der System-DTI 50 angeben. Das DTI-Trigger-Eingangs-Statusregister 62f kann ein jedem Triggereingang der System-DTI 50 zugeordnetes Trigger-Eingangs-Statusbit (oder mehrere Bit) aufweisen. Ein Trigger-Eingangs-Statusbit wird auf den ersten Zustand (Niedrig-Zustand) gesetzt, wenn sein zugeordneter Triggereingang inaktiv ist, und auf einen zweiten Zustand (Hoch-Zustand), wenn sein zugeordneter Triggereingang aktiv ist. Im vorliegenden Beispiel kann das DTI-Trigger-Eingangs-Statusregister 62f ein Trigger-Eingangs-Statusbit aufweisen, das mit dem Triggereingang M (DTITRIGIN[M]) korrespondiert. Da der Triggereingang M dem Empfang von Nicht-Debug-Domänen-Systemrücksetz-Statussignalisierung von der Rücksetzsteuereinheit 38 gewidmet ist, kann der Debugger 24 einen Nicht-Debug-Domänen-Systemrücksetzstatus überwachen, indem ein Zustand des mit dem Triggereingang M korrespondierenden Trigger-Eingangs-Statusbit ausgewertet (zum Beispiel gelesen) wird.
-
In einer beispielhaften Operation der Debug-Umgebung 10 kann, wenn sich der Debugger 24 mit dem SoC 30 verbindet (sich an dieses anschließt), der Debugger 24 eine Debug-Domäne des SoC 30 konfigurieren. Zum Beispiel kann der Debugger 24 Konfigurationseinstellungen für beliebige zugängliche Debug-Logik des SoC 30 initialisieren. Vor dem Durchführen einer Debug-Sitzung kann der Debugger 24 ein Nicht-Debug-Domänen-Systemrücksetzen einleiten, das das SoC 30 in einen bekannten Zustand bringt, ohne die Debug-Domäne des SoC 30 zu beeinflussen, wie etwa beliebige Debug-Logik, die bereits für das Ausführen von Debug-Operationen initialisiert wurde. Wie oben beschrieben, kann der Debugger 24 einen Kanal des Debug-Triggermechanismus des SoC für Nicht-Debug-Domänen-Systemrücksetzsignalisierung (wie etwa den Kanal X) zuweisen, einen Triggerausgang der System-DTI 50 (wie etwa den Triggerausgang N) auf den für Nicht-Debug-Domäne-Systemrücksetzsignalisierung zugewiesenen Kanal abbilden (zum Beispiel DTIOUTNEN[N]==”Kanal X freigegeben”) und sicherstellen, dass ein Triggereingang der System-DTI 50 (wie etwa der Triggereingang M) auf keinen Kanal abgebildet wird (zum Beispiel DTIINEN[M]==4'b0). Nach dem Pollen (Beobachten) des DTI-Trigger-Eingangs-Statusregisters 62f, insbesondere des mit dem Triggereingang M korrespondierenden Trigger-Eingangs-Statusbit, um zu bestätigen, dass kein Nicht-Debug-Domänen-Systemrücksetzen gesetzt wurde (zum Beispiel DTITRIGIN[M]==0), kann der Debugger 24 ein Nicht-Debug-Domänen-Systemrücksetzen setzen, indem in das DTI-Anwendungstriggersetzregister 62c geschrieben wird, insbesondere das Kanal X zugeordnete Anwendungstriggerbit (zum Beispiel DTIAPPSET[X]==1). Dies bewirkt die Generierung eines Systemrücksetzkanalereignisses auf Kanal X, wodurch Nicht-Debug-Domänen-Systemrücksetzanforderungssignalisierung für die Rücksetzsteuereinheit 38 bereitgestellt wird.
-
Die Rücksetzsteuereinheit 38 kann dann beim Empfang der Nicht-Debug-Domänen-Systemrücksetzanforderungssignalisierung ein Nicht-Debug-Domänen-Systemrücksetzen einleiten, wobei alle Endpunkte des SoC 30 mit Ausnahme der Rücksetzsteuereinheit 38 und der Debug-Domäne, einschließlich etwaiger Debug-Logik der Endpunkte, zurückgesetzt wird. Der Debugger 24 kann das DTI-Trigger-Eingangs-Statusregister 62f pollen (beobachten), insbesondere das mit dem Triggereingang M korrespondierende Trigger-Eingangs-Statusbit, bis es anzeigt, dass das Nicht-Debug-Domänen-Systemrücksetzen gesetzt wurde (zum Beispiel DTITRIGIN[M]==1). Nachdem der Debugger 24 bestätigt, dass das Nicht-Debug-Domänen-Systemrücksetzen gesetzt wurde, kann der Debugger 24 die Nicht-Debug-Domänen-Systemrücksetzanforderung löschen, indem in das DTI-Anwendungstriggersetzregister 62c, insbesondere das Kanal X zugeordnete Anwendungstriggerbit, geschrieben wird (zum Beispiel DTIAPPSET[X]==0). Als Alternative kann der Debugger 24 in das DTI-Anwendungstriggerlöschregister 62d, insbesondere das Kanal X zugeordnete Anwendungstriggerbit, schreiben (zum Beispiel DTIAPPCLEAR[X]==1), um das Systemrücksetzen abzusetzen. Der Debugger 24 kann dann das DTI-Trigger-Eingangs-Statusregister 62f wieder pollen (beobachten), insbesondere das mit dem Triggereingang M korrespondierende Trigger-Eingangs-Statusbit, um sicherzustellen, dass das Nicht-Debug-Domänen-Systemrücksetzen abgesetzt wurde (zum Beispiel DTITRIGIN[M]==1). Der Debugger 24 weiß dann, dass sich das SoC 30 in einem bekannten Zustand befindet, und der Debugger 24 kann die Debug-Sitzung durchführen.
-
Wieder mit Bezug auf 1 weist das SoC 30 ferner die Triggerroutungseinheit (TRU) 52 auf, wobei die System-DTI 50 mit der Triggerroutungseinheit 52 verbunden ist. Bei verschiedenen Implementierungen können verbleibende Triggereingänge und/oder Triggerausgänge von der System-DTI 50, wie etwa Triggereingänge und Triggerausgänge, die nicht mit der Rücksetzsteuereinheit 38 verbunden sind, mit der Triggerroutungseinheit 52 verbunden werden. Die Triggerroutungseinheit 52 kann Sequenzsteuerung auf Systemebene und Synchronisation auf Systemebene für das SoC 30 ohne Kernintervention zum Beispiel von Prozessor 34 und/oder Prozessor 36 bereitstellen. Bei verschiedenen Implementierungen bildet die Triggerroutungseinheit 52 Triggermaster (Trigger-Generatoren) auf Trigger-Slaves (Trigger-Empfänger) ab.
-
Das SoC 30 kann ferner eine System-Watchpoint-Einheit (SWU) 70 aufweisen, die für Transaktionsüberwachung ausgebildet ist, die Debug-Unterstützung bereitstellen kann. Die System-Watchpoint-Einheit 70 kann auf der Basis der Überwachung von Transaktionen in den System-Slaves Ereignisse (wie etwa eine Trace-Nachricht, einen Trigger oder ein Interrupt) erzeugen. Bei verschiedenen Implementierungen verwendet die System-Watchpoint-Einheit 70 verschiedene Watchpoint-Übereinstimmungsgruppen zur Transaktionsüberwachung.
-
Um nichtinvasive Echtzeit-Debugging-Techniken zu ermöglichen, kann das Debug- und Trace-System 40 dem Betrieb des SoC 30 zugeordnete Trace-Informationen erfassen, die durch den Debugger 24 analysiert werden können. Zu den Trace-Informationen können Anweisungsinformationen von verschiedenen Komponenten des SoC 30, Dateninformationen von verschiedenen Komponenten des SoC 30, Bustransaktionsinformationen und/oder andere dem Betrieb des SoC 30 zugeordnete Informationen gehören. Zum Beispiel kann das Debug- und Trace-System 40 bei verschiedenen Implementierungen auf dem Prozessor 34 und dem Prozessor 36 ausgeführte Software beobachten und der Softwareausführung zugeordnete Trace-Informationen sammeln. In 1 kann das Debug- und Trace-System 40 verschiedene Trace-Komponenten aufweisen, wie etwa einen Trace-Bus 44, ein Trace-Modul für jedes Verarbeitungselement (wie etwa ein Trace-Modul 72a, das dem Prozessor 34 zugeordnet ist, und ein Trace-Modul 72b, das dem Prozessor 36 zugeordnet ist), ein System-Trace-Modul 74, einen Trace-Puffer 76 zum Speichern von Trace-Daten, einen Trace-Port 78, um es dem Debug-Host 20 zu ermöglichen, Trace-Daten zu erfassen, und einen seriellen Leitungsausgang (SWO) 80. Jedes Trace-Modul (TM) kann Tracking und Speicherung des Echtzeit-Anweisungsflusses, Datenflusses und/oder Programmflusses ermöglichen. Jedes Trace-Modul kann als eine eingebettete Trace-Makrozelle (ETM), eine Programm-Trace-Makrozelle (PTM), eine Anweisung-Trace-Makrozelle (ITM) oder eine andere geeignete Trace-Makrozelle implementiert werden.
-
Nunmehr mit Bezug auf 3 ist 3 ein Flussdiagramm eines beispielhaften Verfahrens 100, das zur Bereitstellung eines Nicht-Debug-Domänen-Systemrücksetzens in einer Debug-Umgebung wie etwa das mit Bezug auf 1 und 2 beschriebene, implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung. Bei verschiedenen Implementierungen kann das Verfahren 100 durch ein System implementiert werden, das eine Debug-Triggerschnittstelle und eine Rücksetzsteuereinheit aufweist. In Block 102 wird die Debug-Triggerschnittstelle mit der Rücksetzsteuereinheit verbunden. Bei einigen Implementierungen kann ein Nicht-Debug-Domänen-Systemrücksetzanforderungskanal zwischen einer Debug-Triggerschnittstelle und einer Rücksetzsteuereinheit definiert werden. In Block 104 wird die Debug-Triggerschnittstelle dafür konfiguriert, die Rücksetzsteuereinheit zum Rücksetzen einer Nicht-Debug-Domäne zu triggern. Es können zusätzliche Schritte vor, während und nach dem Verfahren 100 bereitgestellt werden, und einige der beschriebenen Schritte können bei anderen Ausführungsformen des Verfahrens 100 ersetzt oder beseitigt werden.
-
Nunmehr mit Bezug auf 4 ist 4 ein Flussdiagramm eines beispielhaften Verfahrens 110, das zur Bereitstellung eines Nicht-Debug-Domänen-Systemrücksetzens in einer Debug-Umgebung, wie etwa der mit Bezug auf 1 und 2 beschriebenen, implementiert werden kann, gemäß verschiedenen Aspekten der vorliegenden Offenbarung. Bei verschiedenen Implementierungen kann das Verfahren 110 während des Betriebs der Debug-Umgebung 110 implementiert werden. Wenn sich zum Beispiel der Debugger 24 mit dem SoC 30 verbindet (sich an dieses anschließt), kann der Debugger 24 eine Debug-Domäne des SoC 30 konfigurieren (wie etwa Initialisierung von Konfigurationseinstellungen für etwaige zugängliche Debug-Logik des SoC 30) und dann das Verfahren 110 implementieren, um das SoC 30 vor dem Durchführen einer Debug-Sitzung in einen bekannten Zustand zu bringen, ohne die Debug-Domäne des SoC 30, wie etwa etwaige initialisierte Debug-Logik, zu beeinflussen. Es können zusätzliche Schritte vor, während und nach dem Verfahren 110 bereitgestellt werden, und einige der beschriebenen Schritte können bei anderen Ausführungsformen des Verfahrens 110 ersetzt oder beseitigt werden.
-
In Block 112 wird ein Nicht-Debug-Systemrücksetzanforderungskanal zwischen einer Debug-Triggerschnittstelle und einer Rücksetzsteuereinheit definiert. Zum Beispiel kann der Debugger 24 einen Kanal X des Debug-Triggermechanismus des SoC für Nicht-Debug-Domänen-Systemrücksetzsignalisierung zuweisen. In Block 114 wird ein Triggerausgang der Debug-Triggerschnittstelle auf den Nicht-Debug-Domänen-Systemanforderungskanal abgebildet. Zum Beispiel kann der Debugger 24 den Triggerausgang N der System-DTI 50 auf Kanal X abbilden, der für Nicht-Debug-Domänen-Systemrücksetzsignalisierung zugewiesen wurde (zum Beispiel DTIOUTNEN[N]=='Kanal X freigegeben'). Das Verfahren 110 kann ferner aufweisen, sicherzustellen, dass ein Triggereingang der Debug-Triggerschnittstelle, der zum Überwachen eines Status des Nicht-Debug-Domänen-Systemrücksetzens verwendet wird, auf keinen Kanal abgebildet wird. Zum Beispiel kann der Debugger 24 ferner sicherstellen, dass der Triggereingang M der System-DTI 50, der zum Überwachen von Nicht-Debug-Domänen-Systemrücksetzstatussignalisierung von der Rücksetzsteuereinheit 38 verwendet wird, auf keinen Kanal abgebildet wird.
-
In Block 116 wird ein Nicht-Debug-Domänen-Systemrücksetzen gesetzt. Zum Beispiel kann der Debugger 24 ein Nicht-Debug-Domänen-Systemrücksetzen setzen, indem in das DTI-Anwendungstriggersetzregister 62c geschrieben wird, insbesondere das Anwendungstriggerbit, das Kanal X zugeordnet ist (zum Beispiel DTIAPPSET[X]==1). Dies bewirkt die Generierung eines Systemrücksetzkanalereignisses auf Kanal X, wodurch der Rücksetzsteuereinheit 38 Nicht-Debug-Domänen-Systemrücksetzanforderungssignalisierung zugeführt wird. Die Rücksetzsteuereinheit 38 kann dann beim Empfang der Nicht-Debug-Domänen-Systemrücksetzanforderungssignalisierung ein Nicht-Debug-Domänen-Systemrücksetzen einleiten und die Nicht-Debug-Domäne des SoC 30 zurücksetzen, mit Ausnahme der Rücksetzssteuereinheit 38 und der Debug-Domäne des SoC 30, worin beliebige Debug-Logik eingeschlossen ist, die vor dem Einleiten des Nicht-Debug-Domänen-Systemrücksetzens initialisiert wurde. Bei verschiedenen Implementierungen kann das Verfahren 110 vor dem Setzen des Nicht-Debug-Domänensystemrücksetzens Prüfen eines Nicht-Debug-Domänen-Systemrücksetzstatus aufweisen, um sicherzustellen, dass nicht schon ein Nicht-Debug-Domänen-Systemrücksetzen eingeleitet wurde. Zum Beispiel kann der Debugger 24 das DTI-Trigger-Eingangs-Statusregister 62f lesen, insbesondere das mit dem Triggereingang M korrespondierende Trigger-Eingangs-Statusbit, um zu bestätigen, dass kein Nicht-Debug-Domänen-Systemrücksetzen gesetzt worden ist (zum Beispiel DTITRIGIN[M]==0).
-
In Block 118 kann ein Status des gesetzten Nicht-Debug-Domänen-Systemrücksetzens geprüft werden. Zum Beispiel kann der Debugger 24 das DTI-Trigger-Eingangs-Statusregister 62f lesen, insbesondere das mit dem Triggereingang M korrespondierende Trigger-Eingangs-Statusbit, bis es angibt, dass das Nicht-Debug-Domänen-Systemrücksetzen gesetzt worden ist (zum Beispiel DTITRIGIN[M]==1). In Block 120 wird das Nicht-Debug-Domänen-Systemrücksetzen abgesetzt. Nachdem zum Beispiel der Debugger 24 bestätigt, dass das Nicht-Debug-Domänen-Systemrücksetzen gesetzt wurde (Block 118), kann der Debugger 24 die Nicht-Debug-Domänen-Systemrücksetzanforderung löschen, indem in das DTI-Anwendungs-Trigger-Setzregister 62c geschrieben wird, insbesondere kann das dem Kanal X zugeordnete Anwendungstriggerbit auf einen niedrigen Zustand gesetzt werden (zum Beispiel DTIAPPSET[X]==0). Als Alternative kann der Debugger 24 in das DTI-Anwendungs-Triggerlöschregister 62d schreiben, insbesondere das Kanal X zugeordnete Anwendungstriggerbit (zum Beispiel DTIAPPCLEAR[X]==1), um das Systemrücksetzen abzusetzen. Bei verschiedenen Implementierungen kann das Verfahren 110 ferner Prüfen des Nicht-Debug-Domänen-Systemrücksetzstatus aufweisen, um sicherzustellen, dass das Nicht-Debug-Domänen-Systemrücksetzen nicht mehr gesetzt ist. Zum Beispiel kann der Debugger 24 das DTI-Trigger-Eingangs-Statusregister 62f nochmals lesen, insbesondere das mit dem Triggereingang M korrespondierende Trigger-Eingangs-Statusbit, um sicherzustellen, dass das Nicht-Debug-Domänen-Systemrücksetzen abgesetzt wurde (zum Beispiel DTITRIGIN[M]==0). Der Debugger 24 weiß dann, dass sich das SoC 30 in einem bekannten Zustand befindet, und der Debugger 24 kann die Debug-Sitzung durchführen.
-
Bei verschiedenen Implementierungen kann der Debugger 24 beim Implementieren des Verfahrens 110 das DTI-Anwendungsimpulsregister (DTIAPPPULSE) 62e zum Setzen und Absetzen des Nicht-Debug-Domänensystemrücksetzens verwenden. Zum Beispiel kann der Debugger 24 ein Nicht-Debug-Domänen-Systemrücksetzen setzen (Block 116), indem das Kanal X zugeordnete Anwendungsimpulsbit auf einen Zustand gesetzt wird, der die Generierung eines Systemrücksetzkanal-Ereignisimpulses auf Kanal X für eine definierte Zeit bewirkt. Da das DTI-Anwendungsimpulsregister 62e nach der definierten Zeit automatisch gelöscht wird, wird das Nicht-Debug-Domänen-Systemrücksetzen automatisch abgesetzt, ohne weitere Aktion des Debuggers 24. Bei solchen Implementierungen kann der Debugger 24 durch Pollen des DTI-Trigger-Eingangs-Statusregisters 62f, insbesondere des mit dem Triggereingang M korrespondierenden Trigger-Eingangs-Statusbit, immer noch einen Status des gesetzten Nicht-Debug-Domänen-Systemrücksetzens prüfen (Block 118), bis es angibt, dass das Nicht-Debug-Domänen-Systemrücksetzen gesetzt worden ist.
-
Bei verschiedenen Implementierungen werden Komponenten des Zielsystems in einer selben Vorrichtung implementiert. Als Alternative können Komponenten des Zielsystems in verschiedenen integrierten Schaltungen und/oder Vorrichtungen, die miteinander verbunden sind, verteilt werden, so dass Komponenten des Zielsystems integriert werden, um eine Debug-Umgebung bereitzustellen. Bei verschiedenen Implementierungen können die verschiedenen Schaltungen und/oder Komponenten der Figuren auf eine Platine einer zugeordneten elektronischen Vorrichtung implementiert werden. Die Platine kann eine allgemeine Leiterplatte sein, die verschiedene Komponenten eines internen elektronischen Systems der elektronischen Vorrichtung hält und ferner Verbinder für andere Peripheriegeräte bereitstellt. Die Platine kann die elektrischen Verbindungen bereitstellen, durch die die anderen Komponenten des Systems elektrisch kommunizieren können. Beliebige geeignete Prozessoren (darunter digitale Signalprozessoren, Mikroprozessoren, unterstützende Chipsätze usw.), Speicherelemente usw. können geeigneterweise auf der Basis von konkreten Konfigurationsbedürfnissen, Verarbeitungsanforderungen, Computerentwürfen und anderen Betrachtungen oder einer Kombination davon mit der Platine gekoppelt werden. Andere Komponenten, wie etwa externe Speicherung, Sensoren, Controller für Audio-/Videoanzeige und Peripherievorrichtungen können als Plug-In-Karten über Kabel angeschlossen oder in die Platine selbst integriert werden. Bei verschiedenen Implementierungen können die verschiedenen Schaltungen und/oder Komponenten der Figuren als selbstständige Module (zum Beispiel eine Vorrichtung mit zugeordneten Komponenten und Schaltkreisen, die zum Ausführen einer spezifischen Anwendung oder Funktion) ausgebildet sind, implementiert werden oder als Plug-In-Module für anwendungsspezifische Hardware elektronischer Vorrichtungen implementiert werden. Man beachte, dass konkrete Ausführungsformen der vorliegenden Offenbarung ohne Weiteres entweder teilweise oder ganz in eine Kapselung eines Systems auf einem Chip (SoC) aufgenommen werden können. Ein SoC repräsentiert eine integrierte Schaltung, die Komponenten eines Computers oder eines anderen elektronischen Systems in einen einzigen Chip integriert. Sie kann digitale, analoge, Mischsignal- und oft Hochfrequenzfunktionen enthalten; diese können alle auf einem einzigen Chipsubstrat bereitgestellt werden. Andere Ausführungsformen können ein Mehrchipmodul (MCM) aufweisen, wobei sich mehrere getrennte IC in einer einzigen elektronischen Kapselung befinden und dafür ausgebildet sind, mittels der elektronischen Kapselung eng miteinander in Interaktion zu treten. Bei verschiedenen anderen Ausführungsformen können die hier beschriebenen verschiedenen Funktionen in einem oder mehreren Halbleiterkernen (wie etwa Siliziumkernen) in anwendungsspezifischen integrierten Schaltungen (ASIC), am Einsatzort programmierbaren Gatearrays (FPGA), anderen Halbleiterchips oder Kombinationen davon implementiert werden.
-
Die verschiedenen hier skizzierten Funktionen können durch Logik implementiert werden, die in einem oder mehreren nichtflüchtigen und/oder greifbaren Medien codiert ist (zum Beispiel eingebettete Logik, die in einer anwendungsspezifischen integrierten Schaltung (ASIC) bereitgestellt wird, als Anweisungen für einen digitalen Signalprozessor (DSP), Software (potentiell einschließlich Objektcode und Quellcode) zur Ausführung durch einen Prozessor oder eine andere ähnliche Maschine usw.). In einigen dieser Fälle kann ein Speicherelement Daten speichern, die für die hier beschriebenen Operationen gebraucht werden. Dazu gehört, dass das Speicherelement in der Lage ist, Logik (zum Beispiel Software, Code, Prozessoranweisungen) zu speichern, die durch einen Prozessor ausgeführt wird, um die hier beschriebenen Aktivitäten auszuführen. Der Prozessor kann eine beliebige Art von den Daten zugeordneten Anweisungen ausführen, um die hier aufgeführten Operationen zu erreichen. Bei verschiedenen Implementierungen kann der Prozessor ein Element oder einen Artikel (wie etwa Daten) aus einem Zustand oder Ding in einen anderen Zustand oder ein anderes Ding transformieren. In einem anderen Beispiel können die hier skizzierten Aktivitäten mit fester Logik oder programmierbarer Logik (wie etwa durch den Prozessor ausgeführte Software-/Computeranweisungen) implementiert werden, und die hier identifizierten Elemente können eine gewisse Art von programmierbarem Prozessor (wie etwa ein DSP), programmierbare digitale Logik (z. B. ein FPGA, ein löschbarer programmierbarer Nurlesespeicher (EPROM), ein elektrisch löschbarer programmierbarer ROM (EEPROM)) oder ein ASIC sein, das digitale Logik, Software, Code, elektronische Anweisungen oder eine beliebige geeignete Kombination davon umfasst.
-
Man beachte, dass die oben mit Bezug auf die Figuren besprochenen Aktivitäten auf beliebige integrierte Schaltungen anwendbar sind, die Signalverarbeitung umfassen, insbesondere diejenigen, die spezialisierte Softwareprogramme oder Algorithmen ausführen können, von denen ein Teil der Verarbeitung von digitalisierten Echtzeitdaten zugeordnet sein kann. Bestimmte Ausführungsformen können Mehrfach-DSP-Signalverarbeitung, Fließverarbeitung, Signal-/Steuerverarbeitung, Festfunktionsverarbeitung, Mikrocontrolleranwendungen usw. betreffen. In bestimmten Kontexten können die hier besprochenen Merkmale auf medizinische Systeme, wissenschaftliche Instrumentation, drahtlose und verdrahtete Kommunikation, Radar, industrielle Prozesssteuerung, Audio- und Videogeräte, Strommessung, Instrumentation (die hochgenau sein kann) und andere auf digitaler Verarbeitung basierende Systeme anwendbar sein. Außerdem können bestimmte oben besprochene Ausführungsformen in digitalen Signalverarbeitungstechnologien für medizinische Bildgebung, Patientenüberwachung, medizinische Instrumentation und Haus-Gesundheitsversorgung bereitgestellt werden. Dies könnte Atmungsüberwachungsvorrichtungen, Beschleunigungsmesser, Herzfrequenzüberwachungsvorrichtungen, Schrittmacher usw. umfassen. Andere Anwendungen können Kraftfahrzeugtechnologien für Sicherheitssysteme umfassen (z. B. Stabilitätsregelsysteme, Fahrerassistenzsysteme, Bremssysteme, Infotainment- und Innenanwendungen beliebiger Art). Außerdem können Kraftübertragungssysteme (zum Beispiel in Hybrid- und Elektrofahrzeugen) hochgenaue Datenumsetzungsprodukte bei der Batterieüberwachung, in Steuersystemen, Meldesteuerelementen, Wartungsaktivitäten usw. verwenden. In weiteren beispielhaften Szenarien können die Lehren der vorliegenden Offenbarung in den industriellen Märkten anwendbar sein, die Prozesssteuersysteme umfassen, die dabei helfen, Produktivität, Energieverbrauch und Zuverlässigkeit zu verbessern. Bei Verbraucheranwendungen können die Lehren der Signalverarbeitungsschaltungen, die oben besprochen werden, für Bildverarbeitung, Autofokus und Bildstabilisierung (z. B. für digitale Standbildkameras, Camcorder usw.) verwendet werden. Andere Verbraucheranwendungen wären Audio- und Videoprozessoren für Heimkinosysteme, DVD-Rekorder und hochauflösende Fernsehgeräte. Noch andere Verbraucheranwendungen wären fortschrittliche Berührungsschirmsteuerungen (z. B. für eine beliebige Art von tragbarer Medienvorrichtung). Solche Technologien könnten daher ohne Weiteres Teil von Smartphones, Tablets, Sicherheitssystemen, PCs, Spieltechnologien, virtueller Realität, Simulationstraining usw. sein.
-
Die hier skizzierten Beschreibungen, Dimensionen und Beziehungen wurden lediglich zum Zwecke von Beispielen und der Lehre dargestellt. Sie können jeweils beträchtlich abgewandelt werden, ohne vom Schutzumfang der angefügten Ansprüche abzuweichen. Die Beschreibungen gelten nur für nichteinschränkende Beispiele und sollten dementsprechend als solche aufgefasst werden. In der obigen Beschreibung wurden beispielhafte Ausführungsformen mit Bezug auf konkrete Prozessor- und/oder Komponentenanordnungen beschrieben. An solchen Ausführungsformen können verschiedene Modifikationen und Änderungen vorgenommen werden, ohne vom Schutzumfang der angefügten Ansprüche abzuweichen. Die Beschreibung und die Zeichnungen sind dementsprechend nicht im einschränkenden, sondern im veranschaulichenden Sinne aufzufassen.
-
Man beachte, dass bei den zahlreichen hier angegebenen Beispielen Interaktion im Hinblick auf zwei, drei, vier oder mehr Verarbeitungskomponenten beschrieben werden kann. Dies geschieht jedoch lediglich für Zwecke der Klarheit und Beispiele. Es versteht sich, dass das System auf eine beliebige geeignete Weise konsolidiert werden kann. Neben ähnlichen Entwurfsalternativen können beliebige der dargestellten Komponenten, Module, Schaltungen und Elemente der Figuren in verschiedenen möglichen Konfigurationen kombiniert werden, die alle deutlich in dem allgemeinen Schutzumfang der vorliegenden Beschreibung liegen. In bestimmten Fällen kann es leichter sein, eine oder mehrere der Funktionalitäten einer gegebenen Menge von Flüssen zu beschreiben, indem nur eine begrenzte Anzahl von Verarbeitungskomponenten erwähnt wird. Es versteht sich, dass die Verarbeitungskomponenten der Figuren und ihre Lehren ohne Weiteres skalierbar sind und eine große Anzahl von Komponenten sowie kompliziertere/ausgereiftere Anordnungen und Konfigurationen berücksichtigen können. Die angegebenen Beispiele sollten den Schutzumfang dementsprechend nicht begrenzen oder die allgemeinen Lehren des Verarbeitungssystems und/oder der Komponenten, so wie sie potentiell auf unzählige andere Architekturen angewandt werden, behindern.
-
Ferner beachte man, dass Erwähnungen verschiedener Merkmale (z. B. Elemente, Strukturen, Module, Komponenten, Schritte, Operationen, Eigenschaften usw), die in „einer Ausführungsform”, einer „beispielhaften Ausführungsform”, „einer Ausführungsform”, „einer anderen Ausführungsform”, „einigen Ausführungsformen”, „verschiedenen Ausführungsformen”, „anderen Ausführungsformen”, einer „alternativen Ausführungsform” und dergleichen enthalten sind, bedeuten sollen, dass beliebige solche Merkmale in einer oder mehreren Ausführungsformen der vorliegenden Erfindung enthalten sind, aber in denselben Ausführungsformen kombiniert sein können oder auch nicht unbedingt. Ferner wird angemerkt, dass hier „gekoppelt an” und „gekoppelt mit” austauschbar verwendet werden und dass Erwähnungen eines Merkmals, das „an” ein anderes Merkmal gekoppelt oder „mit” diesem gekoppelt ist, beliebige kommunikative Kopplungsmittel, elektrische Kopplungsmittel, mechanische Kopplungsmittel, andere Kopplungsmittel oder eine Kombination davon umfassen, die die Merkmalfunktionalitäten und -operationen ermöglichen, wie etwa hier beschriebene Sicherheitsprüfmechanismen.
-
Fachleute können zahlreiche andere Änderungen, Ersetzungen, Varianten, Abänderungen und Modifikationen bestimmen und es ist beabsichtigt, dass die vorliegende Offenbarung alle solche Änderungen, Ersetzungen, Varianten, Abänderungen und Modifikationen einschließt, die in den Schutzumfang der angefügten Ansprüche fallen. Um dem Patentamt der Vereinigten Staaten (USPTO – United States Patent and Trademark Office) und zusätzlich etwaigen Lesern irgendeines auf dieser Anmeldung erteilten Patents bei der Deutung der hier angefügten Ansprüche zu helfen, möchte der Anmelder anmerken, dass der Anmelder (a) nicht beabsichtigt, dass irgendwelche der angefügten Ansprüche Paragraph (6) des 35 U.S.C., Abschnitt 112, geltend machen, so, wie er zum Zeitpunkt der vorliegenden Einreichung besteht, sofern nicht die Wörter „Mittel zum” oder „Schritte zum” spezifisch in den konkreten Ansprüchen verwendet werden; und (b) nicht beabsichtigt, durch irgendwelche Aussage in der Beschreibung die vorliegende Offenbarung auf irgendeine Weise zu begrenzen, die nicht anderweitig in den angefügten Ansprüchen widergespiegelt wird.
-
ANDERE ANMERKUNGEN, BEISPIELE UND IMPLEMENTIERUNGEN
-
Es wird ein System bereitgestellt, das Mittel zum Ausgeben einer Nicht-Debug-Domänen-Systemrücksetzanforderung von der Debug-Triggerschnittstelle an die Rücksetzsteuereinheit aufweist, dergestalt, dass die Debug-Triggerschnittstelle die Rücksetzsteuereinheit dazu triggert, eine Nicht-Debug-Domäne zurückzusetzen. Bei verschiedenen Implementierungen kann ein System Folgendes aufweisen: Mittel zum Definieren eines Nicht-Debug-Domänen-Systemrücksetzanforderungskanals zwischen einer Debug-Triggerschnittstelle und einer Rücksetzsteuereinheit, Mittel zum Konfigurieren der Debug-Triggerschnittstelle zum Triggern der Rücksetzsteuereinheit, die Nicht-Debug-Domäne zurückzusetzen, und/oder Mittel zum Überwachen eines Status des Nicht-Debug-Domänen-Systemrücksetzens. Die „Mittel zum” können in diesen Fällen (aber ohne Beschränkung darauf) Verwendung einer beliebigen hier besprochenen Komponente zusammen mit beliebiger geeigneter Software, Schaltkreisen, einem Hub, Computercode, Logik, Algorithmen, Hardware, Steuerung, Schnittstelle, Verbindung, Bus, Kommunikationspfad usw. umfassen. Bei verschiedenen Implementierungen weist das System einen Speicher auf, der Anweisungen aufweist, die, wenn sie ausgeführt werden, bewirken, dass das System beliebige der hier besprochenen Aktivitäten ausführt.
