Mikrocontroller XMOS - der Echtzeit-Prozessor

32-bit-Mikroprozessoren mit Betriebssystem erreichen harte Echtzeit nur bedingt. Hardware-Lösungen sind wiederum zu unflexibel und kombinierte Systeme mit FPGA sehr komplex. Einen neuen Ansatz bietet XMOS mit dem 32-bit-Prozessor XS1, der durch seine Einfachheit verblüffende Lösungsmöglichkeiten aufzeigt.

XMOS Ltd. mit Sitz in Bristol (www.xmos.com) bietet die Prozessor-Reihe XS1 an. Diese Prozessoren verfügen je nach Variante über ein bis vier Kerne, eine Taktrate von 400 bis 500 MHz pro Kern und 64 bis 256 KB RAM. Auf jedem Kern können bis zu acht Threads gleichzeitig laufen. Die Prozessoren können zusammengeschaltet und auf diese Weise transparent zu größeren Clustern skaliert werden. XMOS bietet zu diesen Prozessoren Entwicklungs-Boards an und sogar einige Referenz-Designs, wie z.B. eine Motor-Controller-Plattform oder ein universelles Quadcore-System mit Touchscreen (Bild 1). Die Entwicklungsboards gibt es mit unterschiedlicher Ausstattung, z.B. einem PHY und einem RJ45-Stecker zum Aufbau von Ethernet-Verbindungen. Für Forschungszwecke ist auch ein Entwicklungs-Kit mit 16 Prozessoren und insgesamt 64 Kernen erhältlich.

Durch das Hardware-Scheduling der Prozessoren eignen sich diese sehr gut für harte Echtzeitanwendungen, bei denen es auf garantierte maximale Latenzzeiten im Nanosekunden-Bereich ankommt. Das bereits erwähnte Referenz-Design einer Motorsteuerung ist ein Beispiel dafür. Zu den weiteren möglichen Einsatzbereichen gehören die Audio-Signalverarbeitung, die deshalb ebenfalls in der Liste der Referenz-Designs auftaucht, und Steuerungsaufgaben im Automotive-Bereich.

Erfolgsrezept Einfachheit

Die einzelnen Kerne einer CPU und benachbarter Prozessoren kommunizieren mittels schneller Datenkanäle, die so ein paketvermitteltes Netzwerk oder auch Data Streaming mit hohen Taktraten ermöglichen. Durch den Verzicht auf einen gemeinsamen Hauptspeicher (shared memory), bei dem der Zugriff sowohl Hardware-unterstützt als auch durch Software-Behandlung (locking) koordiniert werden muss, ist die Synchronisierung des Speicherzugriffs obsolet, so dass es nicht zu typischen Fehlern wie Race Conditions kommt. Wo andere Prozessoren Multitasking durch Time Slicing emulieren, bietet es sich beim XS1 an, jeder Aufgabe direkt einen Thread zuzuordnen und die -Threads über die dedizierten Datenkanäle miteinander kommunizieren zu lassen. Bei Peripherietreibern erübrigt sich dadurch das Konzept von Interrupts gänzlich. Die beim Interrupt-Handling üblicherweise notwendigen Kontextwechsel entfallen. Auch Applikationen können durch parallele -Threads umgesetzt werden - Time Slicing ist überflüssig.

Die GPIOs, Datenkanäle und Timer können so konfiguriert werden, dass der zugehörige Thread bis zum Eintreffen eines erwarteten Wertes schlafen gelegt wird. Die anderen aktiven -Threads werden davon nicht beeinträchtigt. Dies kann zur Erkennung von Pegel-Wechseln und anderen Ereignissen genutzt werden.

Peripherie direkt mit GPIOs realisiert

Anders als andere CPUs und Mikrocon-troller enthalten die Prozessoren keine dedizierten Peripherie-Blöcke oder Schnittstellen wie z.B. USB oder Ethernet. Was zunächst wie ein Mangel erscheint, erweist sich bei näherer Betrachtung als äußerst flexibles Konzept: Durch die geringen Latenzzeiten lassen sich beliebige Peripherieeinheiten direkt auf GPIOs implementieren. Die frei programmierbaren GPIOs können je nach Bedarf mit oder ohne Schieberegistern zu Gruppen zusammengefasst und konfiguriert werden. Der Hardware-basierte Round-Robin Scheduler stellt dabei sicher, dass sich verschiedene Funktionseinheiten nicht in ihrer Leistung gegenseitig beeinträchtigen. So ist es ohne weiteres möglich, eine 100-Mbit/s-Ethernet-Schnittstelle zu implementieren, die den direkt an die GPIOs angeschlossenen PHY auf dem Entwicklungs-Board bedient. Weitere Peripherieeinheiten wie I2C, SPI, CAN, MMC, SD Card und auch USB lassen sich bei Bedarf ebenso implementieren. Dadurch werden die Schnittstellen geschaffen, die wirklich benötigt werden, ohne den Overhead unnötig brach liegender Ressourcen in Kauf nehmen zu müssen.

Ganz neu ist dieses Konzept übrigens nicht, auch verschiedene andere Prozessoren sind intern ähnlich konzipiert: Der beispielsweise beim IMX (Freescale) eingesetzte Ethernet-Con-troller FEC ist als eigenständiger Mikrocontroller aufgebaut, der die Übertragung der Rohdaten zum PHY übernimmt und mit der eigentlichen ARM-CPU per DMA verbunden ist. Auch hier kommt Microcode zum Einsatz. Der wesentliche Unterschied beim XS1 ist jedoch die frei zugängliche Programmierbarkeit und die Homogenität der Funktionseinheiten. Die Programmierung auf dieser Ebene ist nicht komplexer als die Programmierung eines Treibers für eine üblicherweise auf mehreren Dutzend Registern basierende Modulschnittstelle.

Echtzeit per Design

Die Prozessoren der XS1-Reihe verfügen über bis zu vier Kerne, von denen jeder bis zu acht Threads gleichzeitig abarbeiten kann. Diese Hardware-seitig implementierte Mehrprozessbearbeitung hat zwar gewisse Ähnlichkeit mit dem auf Intel-Prozessoren verwendeten Hyperthreading, weicht jedoch in entscheidenden Punkten ab: Durch die Zuteilung der Recheneinheit nach einem äußerst einfachen Round-Robin-Verfahren kann garantiert werden, dass jeder aktive Thread mindestens ein Achtel der verfügbaren Rechenleistung erhält. Dadurch ist z.B. sichergestellt, dass auf einem 400-MHz-Kern jeder Thread mit mindestens 50 MHz Opcodes bearbeitet. Solange nicht alle acht Threads eines Kerns aktiv sind, wird die verfügbare Rechenleistung unter den aktiven Threads aufgeteilt, die daher auch schneller als mit der garantierten Mindestrate laufen können.

Dadurch, dass hierfür keinerlei Interrupts notwendig sind, und in Verbindung mit der garantierten Mindestrate von 50 MHz ergeben sich direkt Latenzzeiten im niedrigen Nanosekundenbereich: Nach Eintreten eines externen Ereignisses benötigt der Hardware Scheduler höchstens einen Taktzyklus, um den Thread zu aktivieren; ein weiterer Taktzyklus ist für die Bearbeitung des Opcodes nötig, der den Thread deaktiviert hatte. Bei einer Mindestrate von 50 MHz ergibt sich daraus direkt eine maximale Latenz von 40 Nano-sekunden für eine Reaktion auf ein konfiguriertes Ereignis.

Ähnlich niedrige Werte können für Jitter beobachtet werden. Dadurch, dass Threads möglicherweise schneller bearbeitet werden, wenn mehrere andere Threads des gleichen Kerns schlafen, kann die Reaktionszeit etwas geringer ausfallen. Die Latenz von maximal 40 Nanosekunden kann dadurch jedoch nur verringert werden; harte Echtzeit im Nanosekundenbereich bleibt also per Design garantiert.