Die 32-bit-Multicore-TriCore-Mikrocontroller der AURIX-Familie verfolgen einen neuen Ansatz und wurden speziell für sicherheitsrelevante Embedded-Funktionen entwickelt.
Der erste vorgestellte Baustein TC275T der AURIX-Architektur enthält gleich drei TriCore-Kerne der Version 1.6. Zwei davon sind auf maximale Rechenleistung optimiert (High-Performance TriCore-CPU 1.6P) und können bis zu drei Befehle in einem Zyklus bei einer maximalen Taktfrequenz von 200 MHz abarbeiten.
Die TC29x-Typen lassen sich sogar mit bis zu bis zu 300 MHz takten. Beim dritten Core, einer sogenannten „High-Efficiency“-TriCore-CPU des Typs 1.6E, stehen ein möglichst geringer Energieverbrauch und ein effizienter Datenaustausch mit der Peripherie im Vordergrund. Er kann höchstens einen Befehl pro Zyklus abarbeiten und wird mit maximal 200 MHz getaktet. Verbunden sind die drei TriCore-Kerne über eine Schaltmatrix, die mit der hohen CPU-Geschwindigkeit arbeitet und Zugriffskonflikte in der Hardware verhindert (Bild 1).
Die insgesamt 4 MB Flash-Speicher für Programm-Code sind in zwei 2-MB-Bänken mit unabhängiger Lese-Schnittstelle ausgeführt, welche einen gleichzeitigen Flash-Zugriff von zwei CPUs ohne Geschwindigkeitseinschränkung erlaubt. Als weitere Speicher sind Boot-ROM, Daten-Flash mit EEPROM-Emulation sowie SRAM als Core-lokaler Speicher implementiert. Alle Speicher sind mit Fehlererkennung (EDC) und Fehlerkorrektur (ECC) ausgerüstet.
Die Aufgaben des General-Purpose-Timer-Array und Peripheral-Control-Prozessors aus den AUDO-Typen werden von einem neuen, leistungsfähigeren sogenannten Generic-Timer-Module (GTM) übernommen. Ebenfalls mit eigenem optimiertem Befehlssatz flexibel programmierbar, ermöglicht es eine Implementierung aller für die vorgesehenen Einsatzbereiche typischen Aufgabenklassen.
Neben einer langen Reihe bekannter und zumeist weiterentwickelter Peripherieeinheiten bieten die neuen Bausteine auch komplett neue A/D-Wandler, die nach dem Delta-Sigma-Verfahren arbeiten. Damit sind für Signale im unteren kHz-Bereich Messergebnisse mit sehr hohem Signal-Rausch-Abstand und damit sehr guter Genauigkeit erreichbar.
Die Controller verfügen über ein spezielles Speicher- und Zugriffschutzschutzsystem auf mehreren Ebenen. Auf der ersten Ebene unterstützen sie die konventionelle Task-Software-Kapselung. Darüber hinaus steht auf einer zweiten, verteilten Ebene die Ressourcen-Kapselung von Slave-Bausteinen und Peripherie zur Verfügung.
Diese zweite Schutzebene ist in jedem Slave innerhalb des Bussystems integriert, um das Schreiben von Daten in den Slave für eine spezifische Auswahl interner Master zu erlauben oder abzulehnen. Versucht ein nicht berechtigter Master auf den falschen Slave zu schreiben, stellt der Slave das fest und blockiert aktiv das Schreiben, damit keine Daten zerstört werden und der Fehler sich nicht fortsetzt.
Der Verstoß kann protokolliert und dekodiert werden, um festzustellen, welcher Master bzw. welcher Task fehlerhaft war. Das ist ein wesentlicher Vorteil: Damit können auf Cores Betriebssysteme und Tasks mit höchsten Sicherheitsanforderungen in Kombination mit Betriebssystemen und Tasks laufen, die bestehende Programme oder Code mit geringerem Sicherheits-Level ausführen, ohne dass der komplette Betriebssystem-Kapselungsmechanismus auf allen Cores laufen muss.
Ein ähnlicher Mechanismus ist auch für den Zugriff auf SRAM-Speicher implementiert. Damit können definierte Speicherbereiche einem speziellen Satz an Mastern zugeordnet werden, wobei Verstöße von den Slaves und nicht vom Master erfasst werden.
Teil-Virtualisierung des Betriebssystems
Diese Technologien stellen den ersten Schritt in Richtung einer Teil-Virtualisierung des Betriebssystems dar. Damit ist das Betriebssystem teilweise virtualisiert, während einige Teilbereiche immer noch direkten Hardware-Zugriff über ein definiertes API haben. So kann das Echtzeit-Verhalten beschleunigt werden. Diese Virtualisierungs-Technologie ermöglicht die Koexistenz von Systemen mit unterschiedlicher Sicherheitsanforderung auf einem Multicore-AURIX innerhalb gemeinsamer Back-bones und Infrastruktur, während auf einem Single-Core-AURIX mehrere Applikationen laufen können.
Die offene Konfiguration des Backbone-Busses beim Reset erlaubt jedem Master die direkte Adressierung jedes Slaves ohne zusätzliche Verzögerungen. Nach dem Reset können die Slaves so konfiguriert werden, dass sie den Zugriff nur für eine Auswahl an Mastern erlauben, um zu verhindern, dass fehlerhafte Software auf den Mastern auf sicherheitskritische Slaves und Peripherals zugreift. Eventuelle Verstöße gegen diese Zuordnung können verfolgt werden, indem eine Überwachungsfunktion genutzt wird, die entscheidet, ob einem Master Zugriff gewährt wird. Wenn dieser Zugriff gestattet ist, kann er von der Überwachungsfunktion im Namen des Masters ausgeführt werden.
Lockstep-Funktionen
Viele Derivate der AURIX-Mikrocontroller-Familie verfügen über Cores mit Lockstep-Funktion. Diese Technik nutzt zwei Cores in einer Selbsttest-Konfiguration. Auf beiden Cores läuft der gleiche Software-Thread. Der Ausgang der beiden Cores wird miteinander verglichen, um Fehler festzustellen. Gängige Fehler, die eine gewünschte Operation des Cores stören können, sind üblicherweise externe Einflüsse der Taktversorgung, der Stromversorgung, elektrostatischer Entladungen (ESD) oder EMV-Probleme.
Bei diesen sogenannten Transienten-Störungen wird das Silizium des Controllers nicht beschädigt, sondern nur einige der gespeicherten Daten zerstört. Nach einem Refresh kann das System daher in der Regel ohne Einschränkungen weiter laufen. Andererseits könne massivere Fehler wie eine Überlastung an den Anschlüssen oder Kurzschluss zu einer tatsächlichen Beschädigung führen. Dies wird oft als „harter Fehler“ bezeichnet, da die Hardware zerstört ist und einige Operationen nicht mehr ausgeführt werden können. Eine Unterscheidung zwischen Transienten-Störung und diesen harten Fehlern kann mit Hilfe v
on Testmustern erfolgen, die man auf den beiden Lockstep-Cores laufen lässt und prüft, ob wieder ein Fehler auftritt. Die TriCore-Architektur verfügt über eine spezielle SBST-Bibliothek (Software Based Self Test) an Testvektoren, die als regulärer Task innerhalb einer Applikation laufen, um zwischen den beiden Fehlerkategorien zu unterscheiden. Getriggert von der Lockstep-Funktion kann die Applikation sofort die SBST laufen lassen und die Cores prüfen. Ist der Test erfolgreich, dann führt die Applikation eine Refresh durch und setzt den Ablauf fort. Im anderen Fall ist ein permanenter Fehler oder Schaden wahrscheinlich und das System wird angehalten sowie ein Service-Hinweis angezeigt.
Das AURIX-Lockstep-System nutzt die übliche Zeitverzögerung von zwei Takten zwischen den beiden Cores und eine Layout-Diversität für den Schutz gegenüber Fehlern bedingt durch Stromversorgung, Taktversorgung oder Temperatur.
Mit Lockstep-Cores, ECC-geschützten Speichern, Bussen zum Schutz von Daten und Adressen sowie umfangreichen internen, in Hardware implementierten Monitoring-Mechanismen können sich Entwickler voll auf ihre jeweilige Applikation konzentrieren. Eine Software-Treiber-Bibliothek und ein Satz von Selbsttest-Funktionen (SBST) ermöglichen eine benutzerfreundliche Abstrahierung der Sicherheits-Mechanismen und gewährleisten die sichere Datenspeicherung, Programm-Ausführung und Ausgangs-Überwachung.
Dank der hohen Leistungsfähigkeit der AURIX-Multicore-Mikrocontroller kann der Code von bestehenden Applikationen oftmals auch für sicherheitskritische Systeme beibehalten werden, während die Funktionen, die bisher auf mehreren kleineren Controllern verteilt waren, in eine leistungsstarke und sichere Rechenplattform integriert werden können. Die Technologien für Multilevel-Ressourcen-Verkapselung reduzieren den Aufwand für die Inte-gration neuer und bestehender Software in einen Multicore-Controller.
Der Autor:
B.Sc. Simon Brewerton |
---|
ist Senior Principal für Mikrocontroller Functional Safety bei Infineon Technologies in Bristol, Großbritannien. |
simon.brewerton@infineon.com