Parallel statt unterbrochen: XMOS xCORE im Vergleich zur klassischen MCU

In den meisten Embedded Projekten greifen wir zu dem, was die Standardwerkstatt hergibt: ein Cortex-M®, ein RTOS, ein paar Interrupts, fertig. Das funktioniert, bis es nicht mehr funktioniert. Sobald die Anforderungen an deterministisches Timing, echte Parallelität oder rechenstarkes DSP an der Edge wachsen, fängt der klassische Stack an zu ächzen. Genau hier kommen die XMOS® xCORE Bausteine ins Spiel.

Die klassische Welt: sequenziell mit Unterbrechungen

Ein typischer Mikrocontroller hat einen oder wenige Kerne und eine Sammlung fest verdrahteter Peripherien: UART, SPI, I²C, Timer, ADC. Echtzeitverhalten entsteht über Interrupts. Das Hauptprogramm läuft, wird unterbrochen, der ISR macht seine Arbeit, das Hauptprogramm läuft weiter. Wer mehrere “gleichzeitige” Aufgaben braucht, packt ein RTOS dazu und teilt die CPU in Zeitscheiben auf.

Das Modell funktioniert robust für Standardanwendungen, hat aber strukturelle Schwächen:

• Jitter: Interruptlatenzen, geschachtelte ISRs und Cache-Effekte machen Antwortzeiten unvorhersehbar, oft im Bereich mehrerer Mikrosekunden.
• Peripherie-Lock-in: Was nicht in Silizium gegossen ist (etwa ein exotischer serieller Bus), muss in Software gebitbangt werden, mit allen Timing-Risiken.
• RTOS-Komplexität: Mutexe, Prioritätsinversion, Race Conditions. Der Overhead steigt schneller als der Funktionsumfang.

Für Steuerungen, Sensorknoten oder einfache Aktoren reicht das in aller Regel. Für Audio-Pipelines mit 24 Bit bei 192 kHz, mehrkanaliges Beamforming oder gemischte AI/Realtime-Workloads wird die Architektur zur Bremse.

Die XMOS-Philosophie: echte Parallelität, vorhersagbar bis auf den Takt

XMOS dreht den Spiess um. Statt einem Kern mit Interrupts gibt es viele kleine Kerne, die wirklich gleichzeitig laufen. Beim aktuellen xcore.ai (XU316) stehen 16 sogenannte Logical Cores zur Verfügung, verteilt auf zwei Tiles à 8 Cores. Jeder Logical Core bekommt eine garantierte Scheibe der Tile-Rechenleistung, deterministisch, nicht via Scheduler-Heuristik.

Drei Konzepte machen den Unterschied:

1. Hardware-Ports mit eigener Timing-Engine. Ein XMOS-Chip hat keine “UART” im klassischen Sinn. Stattdessen gibt es konfigurierbare Hardware-Ports (1, 4, 8, 16 oder 32 Bit breit) mit eigenständiger Timing-Logik. Samples werden mit deterministischem Takt in oder aus dem Pin gestreamt, ohne dass die CPU im Datenpfad steht. Der Logical Core schaufelt nur noch Datenwörter, die Timing-Verantwortung liegt in der Hardware. Ein UART, I²S, S/PDIF oder ein proprietäres Protokoll ist damit keine ASIC-Festlegung mehr, sondern ein paar Zeilen Code, bei Sub-Nanosekunden-Genauigkeit.

2. Channels statt Interrupts. Logical Cores kommunizieren über typisierte, synchrone Channels, vergleichbar mit den Konzepten aus Occam oder Go. Das ersetzt Interrupts und Shared-Memory-Locks in den meisten Fällen vollständig. Keine ISRs, keine Mutexe, keine Prioritätsinversion.

3. Determinismus auf Hardware-Ebene. Weil jeder Logical Core garantierte Zyklen bekommt, lässt sich das Timing einer Routine bereits beim Kompilieren bestimmen. Der XMOS-Timing-Analyser kann eine Aussage wie “diese Schleife darf nie länger als 50 ns brauchen” als harte Constraint behandeln und beim Build verifizieren. Das ist kein “Best Effort” eines RTOS-Schedulers, sondern eine Garantie.

Dazu kommt eine 256-Bit-Vektoreinheit pro Tile, die DSP-Workloads und leichte ML-Inferenz in der gleichen MCU erledigt, ohne externen DSP, ohne Coprozessor.

Wie viel KI darf es sein?

Ein realistisches Wort dazu: xcore.ai wurde von XMOS als AIoT-Chip mit Schwerpunkt Audio und Voice positioniert. Die Vektoreinheiten liefern grob 3 GOPs INT8 pro Tile. Das reicht komfortabel für Keyword-Spotting, Wake-Word-Erkennung, Voice Activity Detection, Sprecher-Identifikation, Geräuschunterdrückung und akustische Event-Klassifikation mit wenigen Klassen. Quantisierte INT8-Modelle bis einige hundert Kilobyte laufen problemlos, das XMOS-eigene Toolchain (xformer) übersetzt TensorFlow Lite Micro Modelle direkt auf die Vektoreinheit.

Wo es eng wird: Vision-ML jenseits einfacher Klassifikatoren bei niedriger Auflösung, grosse Audio-Modelle, Transformer-Architekturen. Wer eine echte NPU braucht (Object Detection in Echtzeit, mehrere Frames pro Sekunde), schaut auf dedizierte Beschleuniger wie Coral Edge TPU, Hailo, oder neuere MCUs mit integrierter NPU (STM32N6®, NXP® MCX N94x). Im Kontext eines Audio-Devices oder Sensor-Edge-Knotens mit ein paar Klassen ist xcore.ai aber genau richtig dimensioniert.

Und der FPGA-Weg?

Für genau die Klasse von Anwendungen, an denen der klassische MCU scheitert, gibt es traditionell einen anderen Ausweg: ein FPGA mit eingebettetem Soft- oder Hardcore. Zynq® mit ARM+PL, ein MachXO mit RISC-V-Softcore, ein iCE40 mit PicoRV32. Das Konzept ist dem von XMOS verwandt: dedizierte Logik für die zeitkritischen Pfade, ein Prozessor für die Kontrollebene.

In der Praxis ist xCORE für die meisten Mixed-I/O-Anwendungen aber deutlich flexibler. Eine Protokolländerung ist ein Recompile in C, kein VHDL-Refactoring mit Synthese, Place and Route und Timing-Closure. Iterationszeiten in Sekunden statt Minuten, eine Toolchain, die zur Embedded Welt passt statt vendor-spezifischer FPGA-Suiten, und Software-Engineering-Praktiken (Unit-Tests, Versionskontrolle, CI) funktionieren ohne Kunstgriffe. Wer aus der Embedded Welt kommt, ist auf xCORE sofort produktiv, ohne Sprung in eine zweite Disziplin.

Besonders elegant ist das Streaming der I/O. Die Hardware-Ports übernehmen das Pin-Verhalten, das man sonst in HDL beschreiben würde. Samples laufen mit deterministischem Takt durch, der Logical Core liefert oder konsumiert nur die Daten. Man bekommt FPGA-artiges I/O-Verhalten, ohne je VHDL anzufassen.

Der Pferdefuss heisst Inter-Core-Kommunikation. Channels sind elegant und deterministisch, aber serialisiert. Wer zwei Cores mit hoher Bandbreite koppeln muss, etwa für eine Bildverarbeitungspipeline mit zweistelligen MB/s pro Strom, stösst auf das strukturelle Limit, das ein FPGA mit seinen beliebig breiten parallelen Bussen nicht kennt. Bei I/O-typischen Audio- und Sensor-Bandbreiten ist das kaum spürbar. Bei datenintensiven Pipelines muss die Architektur bewusst darauf zugeschnitten werden, oder die Daten gehören doch in eine FPGA-Fabric.

Ein konkretes Beispiel

Stellen wir uns ein industrielles Audio-Gateway vor: vier I²S-Mikrofone in, analoger Lautsprecher-Out, USB-Audio zum Host, Modbus RTU als Steuerkanal, dazu ein leichtes Keyword-Spotting für lokale Sprachsteuerung. Auf einem klassischen Cortex-M wäre das ein Albtraum aus DMA-Konfigurationen, ISR-Prioritäten und einem RTOS, das die Pipeline zwischen Inferenz und Audio sauber synchronisiert hält. Wenn es überhaupt geht.

Auf xcore.ai läuft jede dieser Aufgaben auf eigenen Logical Cores, kommuniziert über Channels und teilt sich Tile-Ressourcen ohne Race Conditions. Die I²S-Peripherie sind ein paar hundert Zeilen C, das Keyword-Spotting läuft auf der Vektoreinheit, USB-Audio kommt aus einer fertigen XMOS-Library. Statt Architekturkampf gibt es ein klares Datenflussdiagramm.

Aus unserer Praxis: Micro-HTTP-Server mit Echtzeit-Messdaten

In einem unserer Projekte haben wir auf xcore.ai einen Micro-HTTP-Server direkt auf einem Logical Core mitlaufen lassen. Die parallelen Acquisitions-Cores erfassen Messdaten mit deterministischem Sampling, schreiben über Channels in einen Ringpuffer, und der HTTP-Core liefert die Daten via Server-Sent Events live in den Browser. Kein separates Gateway, kein Polling, garantierte Latenzen im Sub-Millisekundenbereich.

Das Frontend ist ein schlankes JavaScript-UI, das die Streams direkt entgegennimmt und im Browser des Clients in Echtzeitdiagramme rendert. Die Aufgabenteilung ist sauber: der xcore.ai liefert nur die Rohdaten, das Rendering, Skalieren und alle UI-Berechnungen passieren auf der CPU/GPU des angeschlossenen PCs. Trotz des winzigen Geräts unter der Haube fühlt sich die Bedienoberfläche erstaunlich responsiv an. Skalieren, Cursoren, Trigger-Bedingungen reagieren ohne wahrnehmbare Verzögerung, weil die Daten direkt von der Quelle kommen und nicht durch eine Polling-Schicht müssen.

Das Charmante daran: derselbe Chip, der die zeitkritische Datenerfassung macht, hostet auch das Web-UI für Inbetriebnahme und Diagnose. Auf einem klassischen MCU müsste man entweder einen zweiten Controller für die HTTP-Seite vorsehen oder akzeptieren, dass das Webinterface die Mess-ISRs ausbremst. Auf xCORE läuft beides nebeneinander, und der Timing-Analyser bestätigt vor dem Flashen, dass das auch unter Last so bleibt.

Wann XMOS und wann nicht?

XMOS ersetzt nicht den Cortex-M0+ in einem batteriebetriebenen Sensor. Die Stärken zeigen sich dort, wo

• mehrere echtzeitkritische I/O-Streams parallel laufen müssen,
• Audio, Voice oder Audio-nahes ML on-device gefragt sind,
• ein klassisches Trio aus MCU, DSP und FPGA durch einen einzigen Chip ersetzt werden soll,
• Determinismus eine harte Anforderung ist, etwa für zertifizierungsrelevante Anwendungen.

Für reine Steuerungsaufgaben, simple Sensorik oder kostenoptimierte Konsumgüter bleibt der klassische MCU oft die bessere Wahl. Für Anwendungen mit massiv paralleler Rechenlast oder breitbandigen Daten-Pipelines bleibt das FPGA das richtige Werkzeug. XMOS ist kein Allzweckwerkzeug, sondern ein Spezialist, in seinem Feld aber konkurrenzlos elegant.

Unser Fazit

Bei swissEmbedded setzen wir XMOS dort ein, wo die klassische MCU-Welt an strukturelle Grenzen stösst. Das Modell aus Logical Cores, Channels und Hardware-Ports zwingt zu sauberer Architektur und belohnt sie mit deterministischem Verhalten. Wer einmal eine Audio- oder Voice-Pipeline auf xcore.ai gebaut hat, vermisst das ISR-Geflecht auf dem Cortex-M nur selten.

Schlüsselwörter: XMOS xCORE, xcore.ai, Cortex-M Alternative, Logical Cores, deterministisches Timing, Audio DSP MCU, Keyword Spotting Embedded, TensorFlow Lite Micro, FPGA vs MCU, Embedded Parallelität Beratung, Embedded Consulting Schweiz, swissEmbedded XMOS Entwicklung