ARM-Prozessoren erreichen heute fast die Komplexität von x86-Prozessoren. Inzwischen sind die Prozessoren mit über 1GHz getaktet, schnelle Busse wie PCI Express sind die Regel und als Speicher kommt fast immer ein DDR3-Speicher zum Einsatz. Daneben verlangt die komplette Ansteuerung des Prozessors mit einer Vielzahl von Spannungen und einem umfangreichen Sequencing tiefe technologische Kenntnisse, sowohl im Schaltplanentwurf als auch im Layout. Die meisten Hersteller unterstützen den Schaltplanentwurf oft noch über entsprechende Referenzdesigns, beim Layout ist der Anwender jedoch auf sein eigenes Können angewiesen. Die Referenzdesigns sind meist „quick and dirty“ erstellt, funktionieren zwar in aller Regel, lassen jedoch viele Wünsche offen, wenn es um die Industrietauglichkeit geht. Auch die langfristige Verfügbarkeit aller Bauteile des Referenzdesigns sind nicht zwingend auf Obsolescence geprüft. Da der Prozessor in aller Regel nicht die Kernkompetenz des Anwenders ist, liegt es also nahe, gleich auf ein Modul zu setzen und damit schneller und sicherer mit seinem Produkt am Markt zu sein.
Da der Anwender also Know-how aus der Hand gibt, ist es umso wichtiger, den richtigen Modulanbieter zu wählen, um später vor bösen Überraschungen sicher zu sein. Es lohnt sich also bei der Entscheidung erst einmal umfangreich zu hinterfragen, was das angebotene Modul tatsächlich an Sicherheit für zukünftige Entwicklungen liefert. Nach der Vorstellung der ARM-Cortex-A9-Prozessoren, die in Anwendungsbereiche eines x86-Prozessors vordringen, bieten nahezu alle Modulanbieter entsprechende Module an.
Standard für ARM
Wie in der x86-Welt üblich, sind erste Standards für ARM-Module im Markt eingeführt worden. Doch der Begriff Standard wird hier teilweise sehr inflationär angewendet, weckt aber bei den Anwendern die Hoffnung, dass jetzt endlich ein Standard im ARM-Modulmarkt kommt. Die Erwartung der Anwender an einen Standard und auch die Argumentation der Anbieter von Standardmodulen ist die höhere Liefersicherheit durch Kompatibilität der Module verschiedener Hersteller und damit der entsprechenden „Second Source“ oder durch deren Austauschbarkeit. Die Idee ist, wenn der Lieferant aus welchen Gründen auch immer ausfällt, kann problemlos auf die Second Source gewechselt werden. Erstaunlicherweise prüfen die wenigsten Anwender aus Zeit- und Kostengründen durch entsprechende Kompatibilitätstests die tatsächliche Austauschbarkeit, sondern verlassen sich in aller Regel auf die Marketingaussagen der Anbieter. Wenn das bis jetzt in der x86-Welt meist auch problemlos oder mit wenigen Anpassungsschritten möglich war, kommt in der ARM-Welt schnell ein böses Erwachen.
Ein weiteres Argument aus der x86-Welt der Standards ist die Skalierbarkeit von Systemen. In der PC-Welt kennt jeder die mögliche Aufrüstung seines PCs mit der nächsten Generation an Prozessoren, soweit diese in den gleichen Sockel passen. Der COM-Express-Standard aus dem Embedded-Markt bietet hier scheinbar eine noch viel weitere Skalierbarkeit von Atom bis zu i7-Prozessoren. Treiber einspielen und läuft - meist zumindest. Auch hier ist schon auf die feinen Unterschiede zu achten. So sind bei der COM Express Spec. 2.0 für die Ausführung Version 2 beispielsweise 24 Express Lanes spezifiziert. Ein Modul bestückt mit einem Intel-Atom-Prozessor N2600/N2800/D2550 und Chipsatz NM10 liefert zweimal PCIe x1, ein anderes Modul bestückt mit einem Embedded-Intel-Core-i7/i5/i3-Prozessor und Chipsatz QM67 bietet fünfmal PCIe x1. Dies zeigt schon in diesem Bereich die Einschränkung von seit langer Zeit eingeführten Standards.
Erstaunlicherweise sehen die zwei führenden Gruppierungen im x86-Modulmarkt den Umstieg auf die ARM-Technologie völlig unterschiedlich: Die Qseven-Gruppe argumentiert einen nahtlosen Übergang von x86 nach ARM, also logischerweise den gleichen Standard für x86- und ARM-Module. Dagegen sieht die SMARC-Fraktion die Notwendigkeit von unabhängigen Standards für x86 und ARM, da die speziellen Funktionen eines ARM-Prozessors sich nicht vernünftig in einem x86-Standard abbilden lassen. Eigentlich würde man davon ausgehen, dass sich ein universeller Standard aufdrängt.
Viele Treiber bei ARM
Der Anwender, der von x86 nach ARM umsteigt, wird schnell feststellen, dass es einen weiteren gravierenden Unterschied und eine Schwierigkeit gibt. Bei der Installation eines x86-Systems wählt man einfach die entsprechenden Treiber aus vorhandenen Bibliotheken des Chipherstellers und schon läuft die Applikation. Damit ist der Umstieg von einem System, also die Skalierbarkeit oder der Einsatz der Second Source, mehr eine logistische Aufgabe und weniger eine technologische Herausforderung. Bei ARM-Modulen sieht die Welt völlig anders aus. Für jeden Prozessor und für jede Funktion gibt es einen individuellen Treiber, der ihn aller Regel nicht als frei verfügbare Bibliothek vorhanden ist, schon gar nicht vom Chiphersteller. Das zeigt deutlich die gestiegene Anforderung an die Modulhersteller, entsprechende Treiber zur Verfügung zu stellen. Auf dieser Seite fehlen noch jegliche Standards. Mit anderen Worten: Eine Austauschbarkeit zwischen verschiedenen Herstellern und unterschiedlichen Modulen auch eines Herstellers ist nicht ohne Weiteres möglich.
Ganz entscheidend ist auch ein Blick auf die Hardware. Ein detaillierter Vergleich hilft in jedem Fall, Entscheidungssicherheit zu erlangen. Die Frage ist, welche Funktionen in einem Modul von unterschiedlichen Anbietern, auch mit verschiedenen Prozessoren, realisiert sind. Also wo die tatsächliche Austauschmöglichkeit liegt. Und welche Prozessorfunktionen sind nicht verfügbar, weil die entsprechenden Signalpins nicht im Standard definiert sind und damit nicht auf dem Systemstecker zur Verfügung stehen? Wie viel Design-Freiheit hat der Anwender mit dem Modul? Je größer der Überlappungsbereich von Funktionen ist, die von jedem Modulanbieter und jedem Prozessor geliefert werden, umso höher ist die tatsächliche Austauschbarkeit. Was ist aber mit den Funktionen des Prozessors, die im Standard nicht abgebildet werden? Werden diese in zukünftigen Projekten benötigt, heißt das für den Anwender, dass er den Modulanbieter wechseln muss. Es lohnt sich auf jeden Fall, eine detaillierte Funktionsliste zu erstellen, um Klarheit darüber zu erhalten, welche Systeme für die eigene Anwendung passen, welche Austauschmöglichkeiten vorhanden sind und welche zukünftigen Bedürfnisse mit dem Modul auch abgebildet sind.
Ein mögliches Arbeitsmittel könnte die in Abbildung 1 gezeigte Tabelle sein. Betrachtet man die derzeit am Markt propagierten Standards für ARM-Module, wird schnell klar, dass es im Moment noch ein Traum ist, einen perfekten Standard zu haben. Durch die Einschränkungen und Kompromisse bezüglich kompletter Austauschbarkeit und dem eingeschränkten Zugriff auf alle Prozessorfunktionen sind die Angebote eigentlich proprietäre Systeme, ohne Second Source und ohne Skalierbarkeit. Es sei denn, die Anforderungen beschränken sich auf den kleinsten gemeinsamen Nenner an Funktionen.
TQ-Module sind dagegen generell auf den eingesetzten Prozessor optimiert. Dies ermöglicht in aller Regel eine deutlich kompaktere Bauform. Alle Prozessor-Funktionen stehen an dem robusten und industrietauglichen Systemstecker zur Verfügung. Es macht also für den Anwender keinen Unterschied, ob er den Prozessor in sein Applikationsboard integriert oder ein TQ-Modul nutzt, natürlich abgesehen vom generellen Nutzen eines Moduls. Unter dem Aspekt der möglichst langfristigen Nutzung einer Prozessorplattform bietet ein solches Modul die größtmöglichen Design-Freiheiten für den Anwender.
Welches System für den Anwender in Frage kommt, ist immer eine ganz individuelle Entscheidung. Spielt die Größe eine wesentliche Rolle und sind die Funktionen des spezifischen Prozessors wichtig, sind die proprietären Systeme im Vorteil. Sind die Anforderungen an Schock und Vibration entscheidend, spielt das eingesetzte Steckersystem eine wichtige Rolle. Ist bisher ein Q7- oder COM-Express-Modul im Einsatz und soll das neue System nur weniger Strom verbrauchen, kann ein Q7 oder SMARC die richtige Entscheidung sein.
In jedem Fall muss sich der Anwender darüber im Klaren sein, dass ein direkter Austausch zwischen existierenden x86-Lösungen und ARM-Lösungen ohne entsprechende Anpassungen nicht möglich ist. Und bei einem Wechsel wird in aller Regel das Applikationsboard gleich mitoptimiert. Es ist also nicht entscheidend, eine mechanische Austauschbarkeit zu haben. Wichtiger erscheint die Design-Freiheit zu haben, um sich optimal auf seine Anwendung anzupassen und zu optimieren.
