Eine Sache von Perspektive und Details
Flaschenhälse bei der Systementwicklung vermeiden
In der Embedded-Welt sind Entwickler oft mit Flaschenhälsen konfrontiert, sprich: mit einer Kette von Einschränkungen, die schon beim Prozessor beginnen. Allerdings lassen sich mit den richtigen Embedded-Modulen die meisten dieser Probleme elegant und kosteneffektiv umschiffen.
Die Entwicklung von Embedded-Projekten wird gerne mit Schalen-Modellen verglichen, um die zunehmende Funktionalität und Komplexität darzustellen. Dieses Bild erweckt allerdings den Eindruck, dass beim Wechsel von einer Schale zur nächsthöheren eine immer größere Übergangsoberfläche zur Verfügung steht und somit mehr Performance und Flexibilität möglich sind. In der Realität erweisen sich diese Übergänge jedoch oft als Flaschenhälse, sodass sich Entwickler und Projektleiter mit einer Reihe von Einschränkungen auseinandersetzen müssen. Mit den entsprechenden Kenntnissen und einer geschickten Wahl der Komponenten lassen sich etliche Problemstellen vermeiden und das Projekt somit beschleunigen.
Applikationsspezifische Prozessoren sind häufig das Herzstück eines Embedded-Projekts, weil sie zahlreiche Funktionen und Schnittstellen liefern, die recht passend für den Anwendungsfall sind. Man spart sich also, zusätzliche Schaltungen zu entwickeln und zu integrieren, sowie die damit verbundenen Themen wie Beschaffung, Zertifizierung und Obsolescence Management – ganz zu schweigen vom erhöhten Platzbedarf und Zeitaufwand. Aber die gebotene Funktionalität dieser Bausteine ist meist mit dem ersten aller Flaschenhälse versehen: Das Silizium kann mehr Signale zur Verfügung stellen, als es Pins im Chip-Gehäuse gibt, um sie auf eine Platine zu bringen. Als Lösung dieses Problems hat die Branche das Pin-Multiplexing (auch Pinmux genannt) etabliert.
Dieser Begriff kann aber einen falschen Eindruck vermitteln, denn es handelt sich in den seltensten Fällen um ein Multiplexing, wie es in der analogen und digitalen Kommunikationstechnik zum Einsatz kommt, also eine Selektionsschaltung, mit der zyklisch aus einer Anzahl von Eingangssignalen eines ausgewählt und an den Ausgang durchgeschaltet wird. Vielmehr ist Pinmux eine statische Zuweisung eines Signals mit einem spezifischen Pin – die erfolgt während der Initialisierungsphase, nach dem Anlegen der Betriebsspannung.
Je nach Prozessor und genutzter Funktion ist nicht jeder Pin für jedes Signal schaltbar, sondern nur für eine spezifische Auswahl. Dies betrifft häufig High-Speed-Signale, die besondere Ansprüche an die Signalgüte haben. Hinzu kommt, dass diese Signale meist von spezialisierten Untereinheiten des Prozessors generiert werden, die nur gewisse Kombinationen von Nutzungsmöglichkeiten erlauben, zum Beispiel 2 x Gbit-Ethernet oder 1 x Gbit-Ethernet plus 1 x USB 3.x - im Datenblatt steht dann die Formulierung »bis zu 2 x Gbit-Ethernet und 1 x USB 3.x«. Erschwerend hinzu kommen andere Signalpegel, weil die spezialisierten Untereinheiten meist nur eine spezifische Spannung (1,8 V, 3,3 V oder 5 V) liefern bzw. vertragen.
Spezialisierte Tools der Halbleiterhersteller helfen bei der Zusammenstellung der erlaubten Signalkombinationen und der Zuweisung zu den Pins. Sie verhindern zwar unmögliche Kombinationen, erzeugen aber nicht die bestmöglichen Kombinationen für höchste Signalqualität außerhalb des Chips, also auf der Leiterplatte und darüber hinaus. Damit haben die Entwickler beim Pinmuxing die Verantwortung, keinen (weiteren) Flaschenhals für das Routing auf der Leiterplatte zu generieren, der möglicherweise zusätzliche Layer der Platine (Modul und/oder Träger-Board) und somit Zusatzkosten verursacht. Die Entwickler kommerzieller Embedded-Module haben hier einen Erfahrungsvorsprung gegenüber Kollegen, die nicht so häufig Prozessoren konfigurieren und auf Leiterplatten integrieren müssen. Mit kommerziellen Embedded-Modulen kann man also dieses Know-how nutzen, unnötige Kosten vermeiden und schneller zum Ziel kommen.
Jobangebote+ passend zum Thema
Die Nutzer von Modulen können aber weiterhin die Pins mit den Pinmux-Tools ihren Erfordernissen anpassen. Dazu stehen primär GPIO-Pins (General Purpose I/O) zur Verfügung; oftmals lassen sich aber auch die vordefinierten (Highspeed-)Pins für andere Aufgaben umwidmen - falls sie wirklich nicht erforderlich sein sollten. Die von den Modulherstellern erstellten Pin-Belegungen sind eine Richtschnur für einen generischen Anwendungsfall, der sich auch in den Evaluations-Boards widerspiegelt. Diese »Best Practice« löst aber immer wieder die Diskussion »Standard oder proprietär« aus.
Diese ewige Diskussion wird nie eine endgültige Lösung finden, weil speziell die anwendungsspezifischen Prozessoren sich in ihren Funktionalitäten zu sehr unterscheiden und sich daher nicht unter einen Hut bringen lassen: Mal passt es, auf einen Standard zu gehen, und mal ist proprietär besser. Anwender sollten sich daher eher die Frage stellen, mit welchen Herausforderungen sie sich lieber auseinandersetzen wollen - beispielsweise die Second-Source-Situation bei proprietären Designs oder die Signaleinschränkungen und der Platzbedarf bei Standard-basierten Modulen.
Von einem gewissen Standpunkt aus kann man sagen, die x86-Welt hat es hier leichter, weil man mit Modulstandards und sehr einheitlichen Schnittstellen über mehrere Generationen hinweg eine Austauschbarkeit und Upgrade-Fähigkeit umsetzen kann. Allerdings will man dann meist gleich einen fertigen, industrietauglichen PC mit den PC-üblichen Schnittstellen und Betriebssystemen für die Anwendung. Und man fängt sich auch alle PC-üblichen Probleme ein: Von der Leistungsaufnahme und Abwärme bis hin zu eingeschränkter Langzeitverfügbarkeit von Systemen. Ganz zu schweigen davon, dass die PC-Plattform das bevorzugte Ziel für Cyberkriminelle ist und spezielle Interfaces nur mit Zusatzkomponenten umgesetzt werden können. Das Flaschenhals-Problem verlagert sich somit eher in Richtung Cyber-Security, eingeschränkte Miniaturisierung sowie Update- und Upgrade-Aufwand. Der Wunsch, schneller vom Proof of Concept zum fertigen Produkt zu kommen, kann hier eine entscheidende Rolle spielen und die Umsetzung durch modulare Konzepte die Probleme entschärfen.
Modul-Standards für die meist applikationsspezifischen Arm-Architekturen haben es aufgrund ihrer sehr unterschiedlichen Schnittstellen schwieriger, einen gemeinsamen Nenner zu finden. Entweder der Prozessor kann mehr, als es sich mit einem Standard-Modul-Pinout herausführen lässt, oder zu viele Pins sind nicht belegt und nehmen nur Platz weg. Als eine Antwort auf dieses Problem wurde das Open-Standard-Module-Konzept (OSM) entwickelt: Über vier Formfaktoren hinweg wird das Pinout vom kleineren zum nächstgrößeren Formfaktor »vererbt« und um weitere Pins ergänzt. Was jetzt nach mehr Freiheit und Flexibilität zum Skalieren aussieht, geht allerdings mit Design-Herausforderungen einher: Das Signal-Routing auf dem Modul und den Trägerplatinen kann deutlich anspruchsvoller werden und zusätzliche, Kosten steigernde Leiterplattenlagen erfordern. Proprietäre Module hingegen lassen sich für Themen wie Übersprechen oder Lauflängenkompensation besser optimieren und können auch Platz für Abblockkondensatoren an Spannungs-Rails bieten - letzteres verbessert die Langzeitstabilität und Lebensdauer eines Moduls. Ebenso lassen sich weitere Funktionalitäten wie einen Strom sparenden RTC, NOR-Flash, Temperatursensor oder Security Chip integrieren und als Bestückungsoption zur Verfügung stellen. Hier haben Standards, die nun mal für generische Anwendungen konzipiert sind, es schwerer, ein Modul für spezifische Applikationsanforderungen zu optimieren.
Auch bei der Einführung neuer Funktionen und Schnittstellen können Standards kaum mit proprietären Modulen Schritt halten: Sind bereits alle Pins des Standard-Moduls belegt, muss man für die nächste Revision einige, meist ältere Interfaces aufgeben – und damit endet auch die Kompatibilität zur Vorgängerversion. Zudem bedürfen diese Selektion und die allgemeine Gremiumsarbeit der Standardisierungsorganisation einiges an Zeit.
Proprietäre Module vermeiden viele dieser Probleme und setzen auch bei der Entwicklung des Träger-Boards auf Tempo. Anbieter wie TQ-Systems stellen mit ihren Starterkits (Evaluations-Board + Modul + Stromversorgung + Kabel) auch den Stromlaufplan der Eval-Boards zur Verfügung, um die Entwicklung der kundenspezifischen Applikations-Boards zu beschleunigen. Hinzu kommt der Software-Support, der alle Software-Sourcen, idealerweise in Github, zur Verfügung stellt. Der Entwicklungs- und langfristige Pflegeaufwand für die Software sind ein Kosten- und Zeitfaktor, der bei der Systementwicklung immer wieder unterschätzt wird.
Nicht nur die Schnittstellen der Prozessoren können entscheidend sein, wenn es um die Bildung von Flaschenhälsen geht, auch die Anwendung beziehungsweise das Systemkonzept wirken sich aus. Soll ein Produkt möglichst günstig zu fertigen sein, punkten einlötbare Module, die automatisch bestückbar sind. Soll auf-/umgerüstet werden oder die Reparaturfähigkeit ist ein entscheidender Faktor für ein System, dann empfehlen sich Steckmodule. Man hat also die Wahl zwischen einer Optimierung der Produktion oder des Service. Hier können Modulhersteller wie TQ den Kunden die Entscheidung nicht abnehmen, daher sind die neuesten Module meist in beiden Formaten – also löt- oder steckbar – erhältlich. Weil die Varianten softwarekompatibel sind, kann mit der Softwareentwicklung bereits begonnen werden, noch bevor die Entscheidung für Löt- oder Stecktechnik gefallen ist. Dies ist auch eines der Hauptargumente für Embedded-Module, da sie so den häufig unterschätzen Flaschenhals der Softwareentwicklung entschärfen.
Aber man darf hier nicht einem Trugschluss erliegen: Die Austauschbarkeit von Modul-Standards scheint indirekt das Versprechen der Skalierbarkeit zu geben - langsames Modul raus und ein performanteres rein, kann eine verlockende Option sein. Wenn da nicht die Anwendungssoftware wäre, die auf immer heterogenere Prozessoren trifft.
Auch wenn die Haupt-Cores die gleichen sind, so unterscheiden sich die Beschleunigereinheiten immer stärker voneinander: GPUs, KI-Beschleuniger oder integrierte DSPs verlangen eine entsprechende Anpassung der Software – ein weiterer Flaschenhals. Will man die Performance anwendungsspezifischer Prozessoren im einstelligen Watt-Bereich voll ausnutzen, muss man einfach auf die spezifische Hardware hin optimieren. Will man das nicht, muss man mit einem deutlich höheren Power-Budget und allen daraus resultierenden Konsequenzen leben.
So bedeutet eine erhöhte Leistungsaufnahme nicht nur mehr Aufwand in der Stromversorgung, wie größere Akkus, sondern auch mehr Abwärme, die aus dem System geführt werden muss. Dies ist meist mit einem erhöhten mechanischen Aufwand verbunden, der nicht nur häufig das äußere Geräte-Design beeinflusst (z.B. Lüftungsöffnungen und Staubfilter), sondern durchaus auch einen deutlichen Mehraufwand in der Geräteendmontage bedeutet.
Die Skalierungsmöglichkeiten anwendungsspezifischer Prozessoren beschränken sich damit praktisch auf die engsten Mitglieder einer Bausteinfamilie, um aufwändige (Software-)Anpassungen zu vermeiden. Es ist daher nicht verwunderlich, dass die Halbleiterhersteller eine recht hohe Granularität für »ein Modell« anbieten: So haben Kunden oftmals die Wahl, wie viele Haupt-Cores sie haben wollen, welche Beschleuniger on-chip sein sollen und ob eine Kryptographie-Engine die Verschlüsselung übernehmen kann. Modulhersteller nutzen diese Vielfalt und ermöglichen so den Modulen, über einen weiten Leistungsbereich zu skalieren, ohne dass es Veränderungen an den Träger-Boards bedarf. Selbst wenn man glaubt, mit der Performance eines speziellen Bausteins auszukommen, sollte man trotzdem nicht die Skalierbarkeit aus den Augen verlieren. So könnten beispielsweise gesetzliche Regularien einen Mehraufwand bedeuten, der sich mit dem ursprünglichen Baustein nicht mehr stemmen lässt – dann ist es gut, wenn man einfach die kompatible »Nummer größer« vom Modul nehmen kann.
Die Systementwicklung im Embedded-Umfeld kennt viele Fallstricke und Herausforderungen, die man mit Prozessor-Modulen elegant und kosteneffektiv vermeiden kann. Sie geben Planungssicherheit und beschleunigen den Entwicklungsprozess. Ob man dabei auf einen Standard oder eine proprietäre Lösung setzt, hängt stark von der Anwendung ab und sollte deshalb undogmatisch angegangen werden - will man die optimale Performance aus den für die Anwendung qualifiziertesten Prozessoren herausholen, darf man sich proprietären Modulen nicht verschließen. »Drum prüfe, wer sich ewig bindet ...«, empfahl schon Friedrich Schiller, » …der Wahn ist kurz, die Reu ist lang« - schöner wurde das Evaluieren nie beschrieben und dessen langfristige Bedeutung – auch für den Embedded-Bereich.
Der Autor:
Manne Kreuzer, Technischer Redakteur TQ Embedded
Lesen Sie mehr zum Thema
