Hardwareunterstützte, zeittransparente Behandlung von Unterbrechungen in einem Echtzeitbetriebssystem auf dem TriCore TC1796

Transkript

1 Hardwareunterstützte, zeittransparente Behandlung von Unterbrechungen in einem Echtzeitbetriebssystem auf dem TriCore TC1796 Diplomarbeit im Fach Informatik vorgelegt von Rudi Pfister geb in Bamberg angefertigt am Department Informatik Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Betreuer: Prof. Dr. Wolfgang Schröder-Preikschat Dipl.-Inf. Fabian Scheler Dipl.-Inf. Daniel Lohmann Dipl.-Inf. Wanja Hofer Beginn der Arbeit: Abgabe der Arbeit:

2 2 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Erlangen, den,

3 Kurzfassung In vielen Echtzeitbetriebssystemen findet eine Zweiteilung des Prioritätenraums statt. Zum einen gibt es die Prioritäten der Programmfäden, die von der Software verwaltet werden. Zum anderen gibt es die Unterbrechungen, die von der Hardware verwaltet werden und deren Prioritäten grundsätzlich höher sind als die der Programmfäden. Das kann dazu führen, dass Programmfäden von Unterbrechungsbehandlungen verdrängt werden, deren zugeordnetes Ereignis eine niedrigere Priorität hat als der Programmfaden. Dieses Phänomen ist als Rate Monotonic Priority Inversion bekannt. Die Antwortzeit des Fadens verlängert sich und es kann passieren, dass der Faden seinen Termin nicht einhalten kann. In dieser Arbeit wird nun eine Art der Unterbrechungsbehandlung vorgestellt und evaluiert, die das Phänomen der Rate Monotonic Priority Inversion verhindert. Dies wird dadurch erreicht, dass die eintreffenden Unterbrechungen von einem Coprozessor entgegengenommen werden und somit die CPU nicht mehr unterbrochen wird. Der Coprozessor aktiviert den Faden der Ereignisbehandlung, der dann vom Ablaufplaner entsprechend seiner Priorität eingeplant und zur Ausführung gebracht wird. Abstract In many real-time operating systems priority space is separated. On one hand there are the priorities of the threads, which are scheduled by software. On the other hand there are interrupts which are managed by hardware and basically have a higher priority than threads. This may cause that threads could be displaced by interrupt handlings which are assigned to events with lower priority than the thread. This phenomenon is known as Rate Monotonic Priority Inversion. The response time of the thread is elongated and this may cause that the thread could not keep its deadline. This work presents and evaluates a way of handling interrupts which prevents Rate Monotonic Priority Inversion. To achieve this, incoming interrupts are handled by a coprocessor and therefore the CPU will no longer be interrupted. The coprocessor activates the thread for event handling. Then this thread will be scheduled and executed according its priority.

4 4

5 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Übersicht Problemanalyse Klassische Unterbrechungsbehandlung Verzögerte Ereignisbehandlung Zeittransparente Ereignisbehandlung Zusammenfassung Anforderungen Definition Zusammenfassung TriCore TC Allgemeines Speichermodell Unterbrechungsbehandlung Service Request Nodes Service Provider Peripheral Control Processor Allgemein Unterbrechungsbehandlung des PCP Instruktionssatz PCP-Programme Zusammenfassung CiAO Überblick Aufbau Konfiguration AUTOSAR-Implementierung Programmfäden und Ablaufplanung Unterbrechungsbehandlung Asynchronous System Trap (AST) Zusammenfassung

6 6 INHALTSVERZEICHNIS 6 Entwurf Erzeugen von Unterbrechungen Behandlung der Unterbrechungen Channel Restart und Channel Resume Unterbrechung von PCP-Programmen Ereignisbehandlung Fadenzustand Adressierung der Verwaltungsdatenstrukturen Aufbau der Verwaltungsdatenstrukturen Synchronisation Systemzustand Signalisierung Zusammenfassung Implementierung Einschränkungen Prinzip der losen Kopplung Datentypen Symbole Speicherzugriffe des PCP Aspekte und Templates Umsetzung Erzeugen von Unterbrechungen Behandlung der Unterbrechungen Ereignisbehandlung Fadenzustand Systemzustand Signalisierung Zusammenfassung Evaluation Testumgebung Erzeugen von Unterbrechungen Faden- und Funktionsaktivierungen Laufzeiten Test 1: Generelles Laufzeitverhalten Testszenario Ergebnisse Test 2: Antwortzeit und Jitter Testszenario Ergebnisse Test 3: Latenz Testszenario Ergebnisse Test 4: Geschachtelte Unterbrechungen Testszenario Ergebnisse Test 5: Überlast

7 INHALTSVERZEICHNIS Testszenario Ergebnisse Bewertung Zusammenfassung Zusammenfassung 75

8 8 INHALTSVERZEICHNIS

9 Kapitel 1 Einleitung 1.1 Motivation In ereignisgesteuerten Systemen wird das Zusammenspiel der einzelnen Komponenten durch Ereignisse gesteuert. Ereignisse können sowohl von außen kommen als auch vom System selbst ausgelöst werden. Das Eintreffen von Ereignissen wird z.b. durch Unterbrechungen signalisiert. Die eintreffenden Ereignisse stoßen eine Ereignisbehandlung an. Die Behandlung der Ereignisse erfolgt in der Regel durch Programmfäden oder Unterbrechungsbehandlungsroutinen. In ereignisgesteuerten Systemen mit statischen Prioritäten wird jeder Ereignisbehandlung eine feste Priorität zugeordnet. In vielen Echtzeitbetriebssystemen gibt es aber eine Zweiteilung des Prioritätenraums. Zum einen die Prioritäten der Fäden, die von der Anwendung gesetzt werden, sie werden vom Betriebssystem verwaltet und der Ablaufplaner entscheidet darüber, welcher Faden als nächstes zur Ausführung gebracht wird. Zum anderen die Prioritäten der Unterbrechungen. Die Unterbrechungen werden von der Hardware verwaltet und haben grundsätzlich eine höhere Priorität als alle Fäden. Ziel der Trennung des Prioritätenraumes ist es, eine möglichst geringe Unterbrechungslatenz zu erreichen. Diese Trennung führt jedoch dazu, dass beim Eintreffen einer Unterbrechung der laufende Faden immer verdrängt wird, was in Echtzeitsystemen zu Problemen führen kann. So kann es vorkommen, dass eine Unterbrechungsbehandlung, die eigentlich einem niederprioren Ereignis zugeordnet ist, einen Faden verzögert, der eine hochpriore Aufgabe bearbeitet. Dieses Phänomen wird als Rate Monotonic Priority Inversion bezeichnet und kann dazu führen, dass zeitkritische Aufgaben ihre Termine nicht mehr einhalten können. Als Beispiel soll hier ein System betrachtet werden, dass einen beliebigen Regelungsprozess abarbeitet. Die Regelungsaufgabe muss von einem Echtzeitfaden erledigt werden, da für die Stellung der Prozessparameter zeitliche Vorgaben einzuhalten sind. Der Begriff Echtzeitfaden bezeichnet einen Faden an den Echtzeitanforderungen gestellt werden, d.h. er hat einen Termin einzuhalten. In diesem System sollen jetzt noch die Prozessgrößen über eine Kommunikationsschnittstelle an eine Leitstelle gemeldet werden. Die Übertragung der Daten hat keine hohe Priorität und ist auch nicht zeitkritisch, deshalb wird dies von weiteren, im System laufenden Fäden erledigt an die keine Echtzeitanforderungen gestellt werden. Die Übertragung der Datenpakete wird mit einer Acknowledge- oder Fehlermeldung quittiert. Das Eintreffen dieser Meldungen wird dem System in Form von Unter-

10 Übersicht brechungen mitgeteilt. Obwohl diese Meldungen selbst nur sehr niederprior sind, haben die Unterbrechungen aufgrund der Zweiteilung des Prioritätenraums eine höhere Priorität als der Echtzeitfaden, der für die Regelung des Prozesses zuständig ist. Der Echtzeitfaden kann unterbrochen und verzögert werden und das Phänomen der Rate Monotonic Priority Inversion tritt auf. 1.2 Zielsetzung In [1] wird eine Möglichkeit vorgestellt, diese Verzögerungen zu minimieren. Dies wird dadurch erreicht, dass beim Eintreffen einer Unterbrechung keine Unterbrechungsbehandlung mehr gestartet wird, sondern nur noch ein Semaphor gesetzt wird, welcher anzeigt, dass eine Unterbrechung eingetroffen ist. Die Behandlung erfolgt erst dann, wenn der hochpriore Faden seine Aufgabe beendet hat. Diese Methode führt jedoch nach wie vor zu kleinen Verzögerungen von höherprioren Fäden (siehe Abschnitt 2.2). In dieser Arbeit wird eine Möglichkeit vorgestellt wie diese Verzögerungen komplett vermieden werden können. Dies wird dadurch erreicht, dass die Unterbrechungen von einem Coprozessor entgegengenommen werden. Der Hauptprozessor soll nur dann unterbrochen werden, wenn die Priorität der Ereignisbehandlung, die der eingetroffenen Unterbrechung zugeordnet ist, höher ist als die des aktuell laufenden Fadens. Ansonsten wird das Ereignis erst nach Beendigung des hochprioren Fadens bearbeitet. 1.3 Übersicht Diese Arbeit beschreibt die Entwicklung und Umsetzung einer Ereignisbehandlung ohne unnötige Unterbrechungen von höherprioren Fäden auf dem TC1796 auf Basis des CiAO- Betriebssystems. Sie gliedert sich in folgende Abschnitte: Kapitel 2 analysiert die Probleme, welche durch die Zweiteilung des Prioritätenraums auftreten können. Nach dieser Problemanalyse wird die Lösung aus [1] vorgestellt und die Grundidee der in dieser Arbeit umgesetzten Lösung dargelegt. Kapitel 3 definiert die an ein System gestellten Anforderungen, in dem eine Behandlung von Ereignissen möglich sein soll, ohne dass der gerade auf der CPU laufende Faden unnötigerweise unterbrochen wird. Kapitel 4 gibt eine Übersicht über die für diese Arbeit relevanten Architektureigenschaften und Hardwarekomponenten des TriCore TC1796. Kapitel 5 stellt das CiAO-Betriebssystem vor und geht besonders auf die in dieser Arbeit verwendete AUTOSAR-Implementierung ein. Kapitel 6 erstellt, basierend auf der Analyse des TC1796 und der Untersuchung von CiAO, einen konzeptionellen Entwurf für die Umsetzung der Behandlung von Ereignissen ohne unnötige Unterbrechungen des laufenden Fadens. Kapitel 7 beschreibt die Implementierung des fertigen Konzepts auf dem TC1796 im Rahmen des CiAO-Betriebssystems.

11 1.3 Übersicht 11 Kapitel 8 evaluiert die implementierte Lösung. Anhand dieser Evaluation werden die klassische Variante der Unterbrechungsbehandlung, die in [1] vorgestellte und die in dieser Arbeit entwickelte Variante miteinander verglichen. Kapitel 9 gibt einen abschließenden Überblick über die in dieser Arbeit durchgeführten Schritte und die gewonnen Ergebnisse.

12 Übersicht

13 Kapitel 2 Problemanalyse Viele Betriebssysteme nutzen das von der Hardware zur Verfügung gestellte Unterbrechungssystem. Unterbrechungen zeigen das Eintreffen von Ereignissen oder die Änderung von Zuständen an. Das Ermöglichen von Unterbrechungen bringt aber auch einige Probleme mit sich. Die Programmfäden können jederzeit unterbrochen werden, deshalb sind Schutz- und Synchronisationsmechanismen nötig. Auch die bereits erwähnte Zweiteilung des Prioritätenraumes sorgt für Probleme. Dieses Kapitel erläutert die Probleme, die in Echtzeitbetriebssystemen durch die Zweiteilung des Prioritätenraums bei der klassischen Unterbrechungsbehandlung auftreten können und stellt die in [1] diskutierte Lösung vor. Anschließend werden die Grundideen der in dieser Arbeit behandelten Lösung dargelegt. 2.1 Klassische Unterbrechungsbehandlung Läuft auf der CPU ein hochpriorer Faden mit Echtzeitanforderungen und trifft eine Unterbrechung ein, die einem niederprioren Ereignis zugeordnet ist, so wird der hochpriore Faden aufgrund der Trennung des Prioritätenraums unterbrochen und von der niederprioren Ereignisbehandlung verdrängt. Diese Rate Monotonic Priority Inversion führt dazu, dass die Ausführung des Echtzeitfadens verzögert wird und sich seine Antwortzeit verlängert. Die Verzögerungen können dazu führen, dass der Echtzeitfaden seine Termine nicht einhalten kann. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.1: Eintreffende Ereignisse unterbrechen den Echtzeitfaden und verzögern diesen

14 Zeittransparente Ereignisbehandlung 2.2 Verzögerte Ereignisbehandlung Eine Möglichkeit die Verzögerungen des hochprioren Fadens zu reduzieren ist die Ereignisbehandlung nicht mehr sofort durchzuführen, sondern sich nur zu merken, dass eine Unterbrechung eingetroffen ist. Die Ereignisbehandlung wird dann erst nach Beendigung des hochprioren Fadens gestartet. Das Merken, dass eine Unterbrechung eingetroffen ist, könnte z.b. durch einen Semaphor geschehen, der gesetzt wird und auf den der Faden der Ereignisbehandlung wartet. Die Priorität der Ereignisbehandlung würde im Prioritätenraum der Anwendung liegen und der Faden würde entsprechend seiner Priorität vom Ablaufplaner zur Ausführung gebracht werden. Der Echtzeitfaden würde nur noch kurz von der Unterbrechungsbehandlungsroutine verdrängt werden, die den Semaphor setzt. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.2: Wenn die Ereignisbehandlung nicht mehr sofort durchgeführt wird, gibt es nur noch kurze Unterbrechungen des Echtzeitfadens 2.3 Zeittransparente Ereignisbehandlung Beim Einsatz von Systemen, welche es ermöglichen Fäden zu aktivieren ohne die CPU zu unterbrechen, lassen sich die Unterbrechungen des Echtzeitfadens komplett vermeiden. Dies wäre zum Beispiel der Fall, wenn das System über einen Coprozessor oder ein ähnliches Gerät verfügt, dass zur Behandlung von Unterbrechungen geeignet ist. In einem System mit einem Coprozessor nimmt dieser die eintreffende Unterbrechung entgegen und aktiviert den Faden der zur Unterbrechung gehörenden Ereignisbehandlung. Hat der gerade auf der CPU ausgeführte Faden eine niedrigere Priorität als die Ereignisbehandlung unterbricht der Coprozessor die CPU und stößt eine Neueinplanung der Fäden auf der CPU an. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.3: Wenn die Ereignisbehandlung ohne Unterbrechung der CPU aktiviert werden kann, gibt es keine Unterbrechungen des Echtzeitfadens mehr

15 2.4 Zusammenfassung Zusammenfassung In diesem Kapitel wurde festgestellt, dass die klassische Art der Unterbrechungsbehandlung in ereignisgesteuerten Echtzeitbetriebssystemen zu Verzögerungen bei der Ausführung von Programmfäden führen kann. Die Ursachen hierfür wurden erläutert und anschließend wurden zwei Lösungen aufgezeigt. Einerseits eine Möglichkeit welche die Unterbrechungen der Echtzeitfäden zwar nicht verhindern, aber doch deutlich reduzieren kann und andererseits die Möglichkeit, bei der es durch Hardwareunterstützung zu keinen Unterbrechungen des Echtzeitfadens mehr kommt.

16 Zusammenfassung

17 Kapitel 3 Anforderungen Im vorherigen Kapitel wurde gezeigt, dass die klassische Unterbrechungsbehandlung in ereignisgesteuerten Echtzeitsystemen zu Problemen führen kann. Zur Lösung dieser Probleme wurde eine Variante der Unterbrechungsbehandlung vorgestellt, bei der die eintreffenden Ereignisse den gerade laufenden Faden nicht mehr unnötig unterbrechen können. Ihre Umsetzung stellt jedoch gewisse Anforderungen an die Hardware und Software des Systems. In diesem Kapitel werden nun diese Anforderungen definiert und erläutert. 3.1 Definition Die folgenden Anforderungen muss ein System erfüllen, um die vorgestellte Art der Unterbrechungsbehandlung umzusetzen, bei der die auf der CPU laufenden Fäden nicht unnötigerweise unterbrochen werden. (A1) Hardware Das System muss einen Coprozessor oder ein ähnliches Gerät besitzen. (A2) Erzeugen von Unterbrechungen Die Geräte, welche Unterbrechungen erzeugen können, müssen in der Lage sein, die von ihnen generierten Unterbrechungen an den Coprozessor zu leiten. (A3) Behandlung der Unterbrechungen Der Coprozessor muss die eintreffenden Unterbrechungen entgegen nehmen und quittieren können. Dabei ist auch der Fall zu berücksichtigen, dass der Coprozessor verschachtelte Unterbrechungen bearbeiten muss. (A4) Ereignisbehandlung Die Anwendung muss eine Möglichkeit besitzen, einem eintreffenden Ereignis einen Faden zuzuordnen, der dessen Behandlung übernehmen soll. (A5) Fadenzustand Um den Faden der Ereignisbehandlung zu aktivieren, muss der Coprozessor in der Lage sein, die Verwaltungsdatenstrukturen des Fadens und des Ablaufplaners im Betriebssystemkern zu manipulieren. Deswegen ist es nötig, dass (A5a) bekannt ist, wo sich diese Strukturen im Speicher befinden, (A5b) bekannt ist, wie diese aufgebaut sind und (A5c) der Zugriff von CPU und Coprozessor auf diese Verwaltungsdatenstrukturen synchronisiert ist.

18 Zusammenfassung (A6) Systemzustand Der Coprozessor muss entscheiden können, ob der gerade aktivierte Faden sofort eingelastet werden muss. Dazu muss er die Priorität des momentan auf der CPU laufenden Fadens kennen, um diese mit der Priorität des gerade aktivierten Fadens zu vergleichen. So kann er entscheiden, ob eine Neueinplanung der Programmfäden auf der CPU nötig ist. (A7) Signalisierung Für denn Fall, dass der gerade aktivierte Faden sofort eingelastet werden soll muss der Coprozessor eine Möglichkeit besitzen die CPU zu unterbrechen, um eine Neueinplanung der laufbereiten Programmfäden anzustoßen. 3.2 Zusammenfassung In diesem Kapitel wurden die Anforderungen für die Ereignisbehandlung ohne unnötige Unterbrechungen des auf der CPU laufenden Fadens definiert. In den beiden folgenden Kapiteln werden jetzt der TC1796 und CiAO darauf hin untersucht, ob sie geeignet sind diese Anforderungen zu erfüllen.

19 Kapitel 4 TriCore TC1796 Der TC1796 [2] ist ein Derivat des TriCore-Prozessorkerns [4] von Infineon. Bei ihm handelt es sich um einen 32-Bit-RISC-Prozessor, der auch DSP-Funktionalität zur Verfügung stellt. Die Architektur des TriCore ist umfangreich und der TC1796 bietet ein breites Spektrum an Peripheriegeräten. Aus diesem Grund wird in diesem Kapitel nur auf die Architektureigenschaften bzw. Peripheriegeräte eingegangen, die für diese Arbeit relevant sind. Es wird ein allgemeiner Überblick über den TC1796 und seine Unterbrechungsbehandlung gegeben und dann der für diese Arbeit zentrale Peripheral Control Processor (PCP) des TriCore beschrieben. 4.1 Allgemeines Der Registersatz des TriCore besteht aus 32 Allgemeinzweckregistern und einigen Registern mit speziellen Funktionen, zum Beispiel dem Programmzähler und dem Statusregister. Die Breite der Register beträgt 32-Bit. Beim TriCore handelt es sich um eine Load/Store-Architektur, weswegen die meisten Befehle nur mit Registern arbeiten, sowie spezielle Befehle zum Laden und Speichern von Daten bzw. Adressen vorhanden sind. Ein Großteil der Maschinenbefehle arbeitet nur mit speziellen Datentypen von denen die TriCore-Architektur eine Vielzahl unterstützt, z.b. Boolean, Byte, Integer und Fest- und Fließkommazahlen. Der TriCore hat einen extra Datentyp für Adressen, so dass zwischen Adress- und Datenoperationen unterschieden werden muss. Die Maschinenbefehle des TriCore sind 32-Bit lang, es gibt jedoch auch eine Vielzahl von 16-Bit-Befehlen, um die Länge des Programmcodes zu minimieren. 16- und 32-Bit-Befehle können beliebig gemischt werden. Eine weitere Besonderheit der TriCore-Architektur ist die hardwareunterstützte Sicherung des Programmkontextes bei Funktionsaufrufen, sowie bei Unterbrechungs- und Ausnahmebehandlungen, welche zur Implementierung von Programmfäden verwendet werden kann. Dabei wird ein Teil der Register des TriCore automatisch von der Hardware gesichert. Die Sicherung der restlichen Register kann durch einen Maschinenbefehl erfolgen. Die Sicherung der Register geschieht in so genannten Context Save Areas (CSAs). Bei den CSAs handelt es sich 64 Byte große Bereiche im Speicher des TC1796. Sie werden von der

20 Unterbrechungsbehandlung Hardware in Form von verketteten Listen verwaltet. Ihre Initialisierung muss jedoch von der Anwendung beim Systemstart noch vor dem ersten Funktionsaufruf durchgeführt werden. 4.2 Speichermodell Die Architektur des TriCore unterstützt, aufgrund der Adressbreite von 32 Bit, einen Adressraum von bis zu 4 GByte. Der Adressraum ist flach und die Register der Ein- und Ausgabe-Geräte werden in den Speicher eingeblendet. Der interne Speicher des TC1796 ist in Programm- und Datenspeicher unterteilt und besteht sowohl aus SRAM-, wie auch aus Flash-Speichern. Außerdem verfügen Systeme in welchen der TC1796 eingesetzt wird, meist noch über externe Programm- und Datenspeicher, auf welche der TC1796 über die External Bus Unit (EBU) zugreift. So verfügt z.b. das TriBoard von Infineon [8] über 2 MByte externes SRAM. 4.3 Unterbrechungsbehandlung Das Unterbrechungsbehandlungssystem des TriCore gliedert sich in zwei Teile (s. Abbildung 4.1). Zum einen gibt es die Service Request Nodes (SRNs). Sie sind Geräten zugeordnet und können Unterbrechungen erzeugen. Zum anderen die Service Provider, die Unterbrechungen entgegennehmen und behandeln können Service Request Nodes Beim TriCore sind die Prioritäten der von den Geräten erzeugten Unterbrechungen nicht fest vorgegeben, sondern können frei konfiguriert werden. Jedes Gerät, das Unterbrechungen erzeugen kann, besitzt mindestens eine Service Request Node. In ihr wird die Priorität der vom Gerät erzeugten Unterbrechung festgelegt. Auch kann eingestellt werden, an welchen Service Provider die Unterbrechung geleitet wird (A2) Service Provider Service Provider können Unterbrechungen entgegennehmen und diese bearbeiten. Als Service Provider kann die CPU oder der Peripheral Control Processor fungieren. Die Service Provider besitzen jeweils eine Interrupt Control Unit (ICU), die über das Interrupt Control Register (ICR) konfiguriert wird. Ein Flag in diesem Register aktiviert oder deaktiviert die Unterbrechungsbehandlung für diesen Provider. Im ICR ist zusätzlich die höchste Priorität der noch zu bearbeitenden Unterbrechungen und die Prioritätsebene auf der sich der Provider gerade befindet hinterlegt. Es werden nur Unterbrechungen bearbeitet, die eine höhere Priorität als die aktuelle Prioritätsebene des Providers haben. Abbildung 4.2 zeigt den schematischen Ablauf der Unterbrechungsbehandlung des Tri- Core. Die Entscheidung, welche der aufgetretenen Unterbrechungen die höchste Priorität besitzt, trifft die Hardware in der so genannten Arbitrierungsrunde. Diese Arbitrierungsrunde besteht aus mehreren Zyklen. Wie viele Zyklen bei der Arbitrierung durchlaufen

21 4.3 Unterbrechungsbehandlung 21 Abbildung 4.1: Blockdiagramm des Unterbrechungssystems (vgl. [4, Kapitel 5.1]) werden sollen ist konfigurierbar. Eine Reduzierung der Zyklenzahl sorgt für eine schnellere Ermittlung der höchsten anstehenden Unterbrechung, jedoch wird dadurch die Anzahl der Prioritätsebenen eingeschränkt. Die Priorität der höchstprioren Unterbrechung wird im ICR hinterlegt. Wenn deren Priorität höher ist, als die des Providers, beginnt dieser mit der Bearbeitung der Unterbrechung. Hierzu sperrt er Unterbrechungen generell und hebt seine Prioritätsebene auf die der zu bearbeitenden Unterbrechung an. Der vom Provider ausgeführte Programmfaden wird unterbrochen und die Ausführung der Unterbrechungsbehandlungsroutine beginnt im entsprechenden Eintrag der Interrupt Vector Table. Nach der Bearbeitung der Unterbrechung wird die Unterbrechungsbehandlung des Providers wieder aktiviert und die Prioritätsebene wieder auf den vorherigen Wert zurückgesetzt. Die Unterbrechungsbehandlung des Providers kann auch vor Beendigung der gerade laufenden Unterbrechungsbehandlung wieder aktiviert werden, um zu ermöglichen, dass niederpriore Unterbrechungen von höherprioren Unterbrechungen unterbrochen werden können.

22 Peripheral Control Processor Eintreffende Unterbrechungen Arbitrierungsrunde zur Auswahl der höchstprioren Unterbrechung Prüfung der aktuellen Priorität des Providers Weiterleiten der höchstprioren Unterbrechung zum Provider Hardware Unterbrechung des aktuellen Programmfadens Wenn Priorität des Providers kleiner als Priorität der Unterbrechung Fortsetzen des unterbrochenen Programmfadens Auslösen der Unterbrechung: Sperren der Unterbrechungen Anheben des Prioritätslevels Freigeben der Unterbrechungen Rücksetzen des Prioritätslevels Sprung zur Interrupt Vector Table Ausführen der Unterbrechungsbehandlungsroutine Beendigung der Unterbrechungsbehandlung Software Abbildung 4.2: Schematischer Ablauf der Unterbrechungsbehandlung des TriCore 4.4 Peripheral Control Processor Allgemein Der Peripheral Control Processor (PCP) des TriCore (A1) ist für die Behandlung von Unterbrechungen und für das Abwickeln von DMA-Operationen ausgelegt. Er hat einen eigenen Instruktionssatz, eigenen Programm- und Datenspeicher und vollen Zugriff auf die Geräte des Systems. Eine seiner Besonderheiten ist, dass er sich normalerweise im Ruhemodus befindet. Trifft eine Unterbrechung ein, führt er das ihr zugeordnete Programm aus und geht nach dem Beenden seiner Operationen wieder in den Ruhemodus. Er muss nicht wie andere Prozessoren eine Leerlaufschleife ausführen oder per Maschinenbefehl in den Ruhemodus geschickt werden. Abbildung 4.3 zeigt ein Blockdiagramm des PCP. Es stellt den Prozessorkern, den Speicher (s. Abschnitt ) und das Unterbrechungssystem (s. Abschnitt 4.4.2) dar Registersatz Der PCP hat acht 32-Bit Register. Abgesehen von einem können sie alle als Allgemeinzweckregister (GPR) verwendet werden, aber auch die restlichen Register haben für manche Operationen fest vorgegebene Aufgaben (SPR). Tabelle 4.1 zeigt die Register des PCP und ihre besonderen Aufgaben Speicher Der PCP hat einen getrennten Programm- und Datenspeicher.

23 4.4 Peripheral Control Processor 23 Abbildung 4.3: Blockdiagramm des PCP (vgl. [2, Kapitel 11.2]) Register Typ Beschreibung R0 GPR/SPR Ziel für einige arithmetische und logische Operationen R1 GPR - R2 GPR/SPR Rücksprungadresse R3 GPR - R4 GPR/SPR Quelladresse für COPY-Operation R5 GPR/SPR Zieladresse für COPY-Operation R6 GPR/SPR CNT1: Transfer-Zähler für COPY TOS: Type-of-Service SRPN: Unterbrechungspriorität bei EXIT CPPN: Aktuelle Priorität R7 SPR PRAM-Datenzeiger (DPTR) und Statusflags Tabelle 4.1: Register des PCP Programmspeicher Im Programmspeicher (CMEM) des PCP liegen die einzelnen PCP-Programme (s. Abschnitt ). Der PCP adressiert den Programmspeicher halbwortweise, da die meisten Maschinenbefehle des PCP 16-Bit breit sind. Der Zugriff auf den Programmspeicher des PCP über das Flexible Peripheral Interface (FPI), wie er z.b. durch die CPU geschieht, erfolgt hingegen wortweise.

24 Peripheral Control Processor Datenspeicher Der Datenspeicher (PMEM) des PCP dient zum Ablegen der Kontexte (s. Abschnitt ) der einzelnen PCP-Programme und zum Speichern von globalen Daten. Der PCP greift über den 8-Bit Datenzeiger (DPTR) in Register R7 und einen 6-Bit Offset auf den globalen Datenspeicher zu. Sowohl der Zugriff durch den PCP, als auch Zugriffe über den FPI-Bus erfolgen wortweise. Allerdings ist zu beachten, dass die Adressierung über den FPI-Bus byteweise, die Adressierung durch den PCP jedoch wortweise erfolgt. Speicher des Systems Der PCP hat auch Zugriff auf den Speicher des Hauptprozessors und anderer Geräte (A5). Dieser Zugriff erfolgt über den FPI-Bus. Die Adressen, mit denen der PCP auf diese Speicher zugreift, unterscheiden sich im Allgemeinen von denen, die für Zugriffe durch die CPU verwendet werden Unterbrechungsbehandlung des PCP Wie auch das Unterbrechungssystem des TriCore besteht das Unterbrechungssystem des PCP im Wesentlichen aus zwei Teilen. Zum einen aus der Interrupt Control Unit (PI- CU) und zum anderen aus den Service Request Nodes (PSRN). Abbildung 4.4 zeigt die Verschaltung der Interrupt Control Unit und der Service Request Nodes mit dem Prozessorkern und die Busse, die zum Zustellen der Unterbrechungen dienen PCP Interrupt Control Unit Die PICU verwaltet die Unterbrechungen, die an den PCP geschickt wurden. Die PICU wählt in einer so genannten Arbitrierungsrunde die momentan höchstpriore Unterbrechung aus und leitet diese an den PCP weiter. Die Dauer einer Arbitrierungsrunde kann konfiguriert werden, allerdings hat eine kürzere Arbitrierungsrunde zur Folge, dass weniger nutzbare Prioritätsstufen zur Verfügung stehen. Die Unterbrechungsanfrage wird von der Hardware automatisch zurückgesetzt, wenn die Unterbrechungsbehandlung beginnt (A3) Service Request Nodes des PCP Der PCP hat zwölf PSRNs mit denen er Unterbrechungen an die CPU (A7) oder sich selbst schicken kann. Von diesen zwölf PSRNs können zwei ihre Unterbrechungen nur an die CPU leiten und fünf nur an den PCP, bei den restlichen kann der PCP ihr Ziel konfigurieren. Die PSRNs unterliegen der Kontrolle durch den PCP, d.h. sie können, im Gegensatz zu den SRNs anderer Geräte, nicht durch die Anwendung gesteuert werden. Die PCP-Programme können nur beim Ausführen einer Exit-Instruktion eine Unterbrechung erzeugen. Welche Priorität die dabei erzeugte Unterbrechung hat und ob diese für die CPU oder für den PCP bestimmt ist, kann im Register R6 konfiguriert werden.