Multithreading und Multicore für Echtzeit-Anwendungen

Xcore-XA-Prozessoren enthalten bis zu 32 Cores mit optionaler Analog- oder USB-Funktion.XMOS

Es gibt zwei Gründe für den Umstieg auf eine Multicore-Prozessorarchitektur: zum einen der Versuch, die Einschränkungen der fortwährenden Prozessskalierung und damit die Einschränkungen des Mooreschen Gesetzes zu umgehen; zum anderen, um bestimmte Probleme effizienter lösen zu können. In beiden Fällen müssen Systementwickler das gleiche Problem bewältigen, nämlich die Erstellung von Software, die gleichzeitig auf mehreren Cores laufen kann.

In der Realität werden Arbeitsabläufe nicht in linearer Weise ausgeführt. Selbst bei klassischen linearen Anwendungen wie in industriellen Fertigungsanlagen sind neben dem eigentlichen Produktionsablauf weitere Aufgaben zu erledigen: Subsysteme zusammenbauen, Reifen formen und auf Räder montieren und so weiter.

Aktuell wird Multicorechips erhöhte Aufmerksamkeit geschenkt. Solche Einzelbausteine mit zwei oder mehr Prozessoren sollten ursprünglich eine höhere Verarbeitungsleistung und Energieeffizienz erzielen. In bereits existierenden Anwendungen, die nicht für mehrere Prozessoren entwickelt sind, ergeben sich jedoch oftmals Probleme. Denn jede Anwendung wird auf einem einzelnen Core ausgeführt, während sich das Betriebssystem um die Zuordnung der Tasks zu den Cores kümmert.

Inzwischen gibt es neue Tools für die Entwicklung und das Debugging von Anwendungen, die auf Multicore-Bausteinen laufen. Insbesondere das Debugging erweist sich jedoch als nicht ganz einfach. Denn beim unabhängigen Ausführen von Software auf zwei oder mehr Prozessoren sind viele der Standard-Debugging-Techniken, die beim Auftreten eines Fehlers den exakten Systemzustand wiederherstellen, nicht mehr länger anwendbar.

Bei Echtzeit-Embedded-Anwendungen sind die Schwierigkeiten noch größer. Muss der Prozessor auf eine vordringliche Anforderung reagieren, erhält er normalerweise einen Interrupt-Request. Der Baustein muss dann die aktuell ausgeführte Operation unterbrechen, die Einstellungen speichern und auf den Interrupt reagieren. All dies benötigt Zeit. Erschwerend kommt hinzu, dass der dafür benötigte Zeitaufwand nicht immer vorhersagbar ist. Bei mehreren Prozessoren nimmt dieser Indeterminismus noch weiter zu, denn der Nachrichtenaustausch zwischen den Prozessoren, der üblicherweise über einen gemeinsamen Speicher erfolgt, ist nicht deterministisch.

Eine neuartige Architektur

Die Xcore-Architektur löst viele Probleme von Echtzeitanwendungen mittels einer proprietären Multicore-Architektur. Die meisten Xmos-Produkte haben ein bis vier CPU-Cores. Diese physikalische Untereinheit der Xcore-Architektur nennt die Firma „Tiles“, was wörtlich übersetzt Fliesen bedeutet. Diese Tiles basieren auf der proprietären 32-Bit-Xcore-Architektur von Xmos. Programme werden sequenziell mit einer garantierten minimalen Verarbeitungsgeschwindigkeit ausgeführt und die CPU unterstützt Hardware-Multithreading bis zu acht Threads pro Core. Die Threads nennt Xmos „logische Cores“.

Das Einstiegsmodell Xcore-XS1-L4-64 hat einen Tile mit vier Cores und eine Taktrate von 400 MHz. Ein hardwarebasierender Scheduler weist jedem Core Zeitschlitze für die Ausführung zu. Im Fall des Xcore-XS1-L4-64 weist folglich jeder Core eine Ausführungsrate von 100 MIPS auf, beziehungsweise hat jeder Zyklus 10 ns zum Ausführen eines Tasks zur Verfügung. Diese verlässliche Ausführungsrate macht Xcore so geeignet für Echtzeitanwendungen.

Die auf einem Core ausgeführten Tasks können Teile einer umfangreicheren Anwendung sein, es kann sich aber auch um verschiedene Anwendungen handeln, etwa bei Geräten, die mehrere Aufgaben ausführen.

Die zu einem Tile gehörenden Cores teilen sich einen gemeinsamen Speicher. Führt ein Core eine Aufgabe aus, hat er vollen Zugriff auf den Speicher ohne Caching. Dies beseitigt eine weitere mögliche Quelle von Indeterminismus, denn Kommunikation und Synchronisation zwischen verschiedenen Tasks erfordern kein Software-RTOS (Real Time Operating System). Stattdessen enthält der Befehlssatz IN- und OUT-Anweisungen. IN liest ein Datenwort einer Ressource ein, während OUT ein Datenwort ausgibt. Kommunizieren zwei Tasks über einen Kanal, wird die IN-Instruktion solange gesperrt, bis OUT ausgeführt ist. Die Kommunikation ist schnell und Tasks lassen sich synchronisieren.

Softwarekonfigurierbare I/O-Pins

I/O-Pins sind vollständig konfigurierbar, da die Xcore-MCUs fest verdrahtete I/O-Schnittstellen durch softwarekonfigurierbare I/O-Pins ersetzen. Die Threads können je nach Bedarf dazu dienen, eine Vielzahl von Peripheriekomponenten zu erstellen. Ein umfangreiches Portfolio an Standard-Peripheriekomponenten stellt die Xsoftip-Bibliothek bereit. Dazu gehören UARTs, I²C-, SPI-, USB-, Ethernet-, CANbus-, LIN- sowie eine Vielzahl spezieller Audio-Interfaces. Außerdem können Anwender auch beliebige eigene Interfaces erstellen.

Ist mehr als ein Tile im selben oder auch in einem anderen Baustein im Einsatz, so erfolgt die Kommunikation über die dedizierte Highspeed-Architektur Xconnect. Nutzen Tasks, die auf Cores innerhalb eines Tiles laufen, einen Speicher zum Datenaustausch, können sie auch Daten über die Kanäle austauschen und synchronisieren. Xconnect erweitert die Kanäle auf Cores in anderen Tiles, ganz gleich, ob sich diese auf demselben oder auf anderen Chips, auf demselben oder einem anderen Board befinden.

Xconnect besteht aus einem Netzwerk von Switches, die über Xmos-Links verbunden sind. Aus Sicht eines Tasks wird eine Nachricht durch einen Kanal gesendet, so als würde er mit einem anderen Task im selben Tile kommunizieren. In diesem Fall öffnet die Nachricht Switches zum Schalten einer Route, die am Ende der Kommunikationssitzung entweder geschlossen werden kann, oder aber zum Übertragen eines Datenstroms geöffnet bleibt. Eine leere Nachricht erlaubt die Synchronisation zwischen Tasks. Die typische Latenzzeit beträgt 100 ns bei einer Bandbreite von bis zu 400 MBit/s pro Link.

So ergibt sich eine simple Methode zum Skalieren der für eine Anwendung verfügbaren Ressourcen. Man erhält mehr Rechenleistung, mehr Speicher und mehr I/O-Kapazität, ohne an Determinismus zu verlieren.

Zwar verwenden Xcore-Bausteine die Xmos-eigene, konfigurierbare Multicore-Mikrocontrollerarchitektur. Jedoch sind ARM-Cortex-Prozessoren in einem breiten Anwendungsbereich die führenden Cores und bieten auch ein umfangreiches Ecosystem an Tools, Partnern und Software. Dazu passend hat Xmos neue programmierbare SoC-Produkte mit geringer Leistungsaufnahme entwickelt, welche die Xcore-Technologie mit einem Ultra-Lowpower-Prozessor ARM-Cortex-M3 kombinieren. Die Xcore-Technologie erlaubt eine softwarebasierende Konfiguration der exakt benötigten Peripheriekomponenten und erfüllt harte Echtzeitbedingungen mit timing-präziser Ausführung. Da die Xcore-XA-Prozessoren den Zugang zum umangreichen ARM-Ecosystem einschließlich der Standard-Codebibliotheken eröffnen, lässt sich die Produktentwicklung drastisch beschleunigen.

Umfangreiche Entwicklungstools

Mit dem modularen Entwicklungssystem Slicekit lässt sich ein einfaches Prototyping von Embedded-Systemkonzepten konfigurieren.XMOS

Die Achillesferse vieler neuer Elektronikentwicklungen ist der Mangel an adäquaten Entwicklungstools. Xmos hat von Beginn an sehr viel Wert auf erstklassige Tools gelegt. Die umfangreiche Familie von Xcore-Entwicklungsboards (Slicekits) wird unterstützt durch Xsoftip-Softwareperipherie und der Software-Entwicklungsumgebung Xtimecomposer-Studio mit Compiler, Debugger, Simulator, Static-Code-Analyzer sowie dem softwarebasierenden Logic-Analyzer Xscope. Slicekits verbinden Entwicklungsboards und Referenzdesign und lassen sich zum Erstellen komplexerer Systeme kombinieren.

Das auf formalen Methoden basierende Tool Xmos-Timing-Analyser (XTA) stellt sicher, dass der entwickelte Code die Timing-Anforderungen der jeweiligen Anwendung erfüllt, was für Echtzeitsysteme unerlässlich ist. XTA ermöglicht die Analyse des Binärcodes und die Erzeugung einer grafischen Darstellung von Timing-Pfaden mit Best- und Worst-Case-Timing. Alternativ lässt sich eine Timing-Assertion, abgeleitet aus der Systemspezifikation, in den Code integrieren und XTA zeigt an, ob diese eingehalten wurden.

Xtimecomposer-Studio basiert auf der Open-Source-IDE Eclipse. Das Xscope-Interface bietet Highlevel-Information mit sehr hoher Performanz.XMOS

Xtimecomposer-Studio wird ergänzt durch den vollausgestatteten Simulator Xsim und dem Xscope-Interface, welches In-circuit-Debugging bietet. Xscope ähnelt dem Interface eines herkömmlichen Oszilloskops, bietet aber Highlevel-Information mit sehr hoher Performanz. Die Verbindung zum Zielsystem wird mittels USB 2.0 über einen Xcore-betriebenen XTAG-Debugadapter hergestellt, der Datenraten bis zu 1 MSPS ermöglicht. Für eine spätere Analyse lassen sich Daten auch in Dateien abspeichern.

Die Programmierung von Xcore erfolgt in Assembler, C oder C++. Im Falle von C und C++ stellt ein einfaches Set von Spracherweiterungen die Mechanismen zum Beschreiben von Parallelität und Gleichzeitigkeit bereit. Diese definieren auch Datenfluss und Ereignisse und können für Highlevel-Scripting zum Einsatz kommen. Der Compiler basiert auf dem Open-Source-Compiler des LLVM-Projekts.

Xsoftip-Blöcke werden für Ein-/Ausgaben, Signalverarbeitung und Protokolle genutzt. Die in C geschriebenen Blöcke werden auf Xcores ausgeführt und sind äußerst flexibel einsetzbar. Der Xsoftip-Explorer ist ein grafisches Interface, das Zugriff auf die Bibliothek und die Konfiguration von Blöcken ermöglicht, um eine bestimmte Spezifikation zu erfüllen. Das Tool versteht die Ressourcen-Anforderungen wie die Anzahl der Prozessorcores, I/O-Pins, Speicher und Takt eines bestimmten Blocks und schätzt ab, welcher Baustein für eine Implementierung am besten geeignet ist.

Der für das Debugging erweiterte Open-Source-GNU-Debugger unterstützt mehrere Cores und Kanalressourcen. Das Xtimecomposer-Studio basiert auf der Open-Source-IDE Eclipse und steht auf der Xmos-Webseite kostenlos zum Download zur Verfügung.

Mit einer innovativen Architektur, die Anwendungsflexibilität mit Timing-Determinismus und einer leistungsfähigen Entwicklungsumgebung kombiniert sowie bereits in vielen Anwendungen erfolgreich zum Einsatz kommt, ermöglicht Xmos ereignisgesteuertes Interagieren in Echtzeitanwendungen.

Anwendungsbeispiele

Sony setzt die Xcore-Technologie im Verstärker des drahtlosen Kopfhörers PHA-2 ein.XMOS

Sony setzt die Xcore-Technologie im Verstärker des drahtlosen Kopfhörers PHA-2 ein. Das winzige, tragbare Produkt kombiniert mehrere Audio-USB-Interfaces, einen hochauflösenden DAC sowie einem hochwertigen Kopfhörerverstärker und ist kompatibel mit USB-Audio-Class-2 und der DSD (Direct Stream Digital)-Technologie. Der Kopfhörer basiert auf der USB-Audiolösung von Xmos und verwendet den 8-Core-Mikrocontroller Xcore-XS1-U8-64. Unterstützt werden Musikdateien mit Abtastraten bis zu 192 kHz und voller 24-Bit-Auflösung, was digitales Audio in Studioqualität ermöglicht.

Die in Stuttgart ansässige Synapticon liefert eingebettete Computer- und Steuerungssysteme für Robotikanwendungen. Ein Roboterarm besitzt mehrere Motoren, von denen normalerweise jeder einen eigenen Controller hat. Entwickler müssen also sowohl die Motoren steuern als auch die Kommunikation zwischen ihnen regeln. Um dieses Problem zu lösen, hat Synapticon auf Basis zweier Xcore-L16-Chips das Core-Prozessorboard C22 entwickelt, das zu einem 32-Core-Prozessor äquivalent ist, jedoch lediglich ein Lowpower-Board mit einer Fläche von 30 x 30 mm² erfordert. Dieses Board verringert die Anzahl an Komponenten und bietet einfache und deterministische Steuerung und Kommunikation. Ferner verlagert sich dadurch die Systementwicklung auf eine höhere Abstraktionebene.

(ah)