Schritte zur erfolgreichen Multicore-Mikrocontroller-Auswahl:
Festlegung der Methodik/ Vorgehensweise
Anforderungsanalyse zur Ressourcen-Identifikation
Auswahlaspekte:
Art des Cores, Rechenleistung und Anzahl der Cores
Safety und Security
Datenspeicher/ Programmspeicher
Interrupt- und DMA-Controller
Peripherien und Ports
Bussystem(e)
Zunächst gilt es, eine Anforderungsanalyse für die Software und Hardware durchzuführen und die Ergebnisse zu dokumentieren. Im Anschluss sollte eine Bewertung der aufgenommenen Anforderungen nach der Wichtigkeit für das Projekt erfolgen:
Die Prioritätsklassen bestimmen, wie kritisch die Anforderung für das Projekt ist:
muss (verpflichtend; höchste Priorität)
sollte (wichtig für das Projekt; hohe Priorität)
wird (wäre gut, wenn es enthalten wäre; niedrige Priorität)
Bevor nun eine Marktanalyse erfolgen kann, gilt es, z.B. für die Komponente eines Mikrocontrollers in der Systemsteuerung die genaueren Anforderungen, die an den Steuerungsrechner gestellt werden, zu definieren. Diese Anforderungen bilden die Basis für die Mikrocontroller-Auswahl:
Mit 3 Schritten zum passenden Multicore-Mikrocontroller
Ähnlich wie beim Kauf von Schuhen beginnt die Auswahl des passenden Mikrocontrollers mit der Suche nach der richtigen Größe. Gleichzeitig sollten wir prüfen, ob die drei wichtigsten Kriterien für automobile oder industrielle Anwendungen erfüllt sind:
Schritt 1: Rechenleistung, Stromverbrauch und Coprozessoren
Steht genügend Rechenleistung zur Verfügung?
Hier gilt es zu untersuchen, welche Art der Arithmetik, welcher Software-Umfang (Speichergrößen) und welche Zeitvorgaben für die Ergebnisbereitstellung bestehen.
Schritt 2: Safety und Security
Sind Sicherheitsanforderungen (Safety bzw. Security) zu erfüllen?
Je nach Art der Anforderungen werden unter Umständen spezielle Hardware-Module bzw. Mikrocontroller-Architekturen benötigt.
Schritt 3: Peripherie und Pins
Reichen die vorhandenen Ressourcen in der Peripherie?
Hier wird untersucht, ob bei den vorhandenen Modulen die Auflösung und die Funktionalität für die Applikation passt und die Anzahl der Port-Pins ausreicht. Auch Betrachtungen hinsichtlich der erforderlichen gleichzeitigen Verfügbarkeit von Ressourcen sind vorzunehmen.
Schritt 1: Steht genügend Rechenleistung zur Verfügung?
Mehr MIPS pro Watt
Mit dem Erreichen einer theoretisch höheren Rechenleistung ist die Entwicklung nicht beendet. Vielmehr soll sie unter verschiedenen Bedingungen zur Verfügung stehen, z.B. bei einem bestimmten Strom-Budget. Dies trifft insbesondere bei batteriebetriebenen Geräten zu. In der Entwicklung von Mobiltelefonen ist sprichwörtlich das Ende der Fahnenstange erreicht. Die für den Betrieb benötigten Akkus können nicht immer mehr Strom liefern, ohne dass dies einen Einfluss auf Größe und Gewicht hat.
Bei Notebooks hat man eine Steigerung der Rechenleistung durch Multicore-CPUs bei moderater Taktung erreicht. Bei diesem Lösungsansatz steigt der Stromverbrauch durch die extrem hohe Taktung in Singlecore-Bausteinen nicht zu stark. Bei der Entwicklung der Mikrocontroller haben die Multicore-Architekturen mit ein paar Jahren Verzögerung Einzug gehalten. Hier gibt es die gleichen Forderungen: mehr Rechenleistung ohne signifikante Steigerung der Stromaufnahme.
Die Automobilindustrie als Vorreiter beim Einsatz der Multicore-Mikrocontroller
Bei der Entwicklung von Steuerungssystemen in der Automobiltechnik sind zwei ausschlaggebende Aspekte zu nennen:
Einhaltung gesetzlicher Forderungen bezüglich Verbrauch von Treibstoff bzw. Schadstoffausstoß
Forderung nach höherer Leistungsfähigkeit bezüglich der Kommunikations- und Entertainment-Systeme im Auto und ganz besonders beim autonomen Fahren
Die Bausteinhersteller von Mikrocontrollern bieten verschiedenste neue Multicore-Architekturen an:
Mehrere Rechenkerne vom gleichen CPU-Typ: homogene Multicore-µC
Verschiedene spezialisierte Rechenkerne: heterogene Multicore-µC
Mehrere gleichartige + spezialisierte Rechenkerne: heterogene Multicore-µC
Welche Arten von Cores werden benötigt, und welche Rechenleistung sollen diese bei einer festgelegten maximalen Stromaufnahme liefern können? Gibt es den benötigten Baustein innerhalb einer Bausteinfamilie mit unterschiedlichen Core-Implementierungen und verschiedenen Gehäusen (Port-Pin-Anzahl)? Diese entscheidenden Aspekte sind für künftig zu realisierende Projekte wichtig.
Software-Migration von Singlecore nach Multicore
Im ersten Schritt sieht die Aufgabe der Software-Migration von Singlecore nach Multicore ganz einfach aus: Lassen wir einfach die vorhandene Software auf mehreren Cores parallel arbeiten.
Stehen bei zwei Cores 200 Prozent Rechenleistung zur Verfügung?
Ein Core entspricht der Rechenleistung x, dann haben wir bei einem Dual-Core also zweimal x. Effektiv ergibt sich aber nur eine Leistungssteigerung von ca. 50 %, oder in einigen Fällen sogar noch weniger. Woran liegt das?
Die Architektur von Singlecore-Software ist in der Regel nicht für die erfolgreiche Ausführung auf einem Multicore-System geeignet. Folgende Herausforderungen lassen sich hier ausmachen:
Singlecore-Software wird sequenziell ausgeführt; Multicore-Software benötigt für das gleiche Resultat Synchronisationspunkte und Kommunikation.
Eine Ressource (z.B. einen Datenspeicher, ein Peripheriemodul, etc.) kann zu einem Zeitpunkt immer nur von einem einzigen Core bzw. Busmaster angesprochen werden; mehrere Cores können nur mit zusätzlicher Koordination gleichzeitig auf dieselbe Ressource zugreifen. Inkonsistente Datenzustände von Datenblöcken müssen bei Multicore-Zugriffen vermieden werden.
Ein Rechenkern benutzt ein Bussystem, mehrere parallel arbeitende Rechenkerne können sich bei Buszugriffen am selben Bus in die Quere kommen. Damit können hohe Zugriffsverzögerungen auf Ressourcen hervorgerufen werden.
Die größte Herausforderung liegt darin, die Verwendung gemeinsamer Ressourcen in der Software zu koordinieren und zu überwachen. Eine Lösung hierfür ist das Ressourcen-Management für die Entwicklung von Multicore-Softwarekomponenten. Ein erfolgreicher Umstieg von Singlecore- auf Multicore-Systeme basiert auf der richtigen Auswahl und Anwendung des einzusetzenden Multicore-Mikrocontrollers.
Ab einer bestimmten geforderten Rechenkapazität (in MIPS) in Kombination mit einer maximal tolerierbaren Stromaufnahme wird eine Multicore-Architektur sinnvoll. Viele der Mikrocontroller-Applikationen werden mit einer Batterie versorgt. Somit steht die Stromaufnahme des Systems ganz oben auf der Anforderungsliste.
Bei Laptops/Notebooks ist dieser Trend bereits Realität: Der Einsatz von Multicore-CPUs soll für eine möglichst lange Betriebsdauer bei einer spezifischen Batteriekapazität sorgen und wird mit dem Ausdruck „lange Akkulaufzeit“ beworben. Die Software hat hier ihren Beitrag für einen möglichst geringen Stromverbrauch zu leisten: Aspekte wie das Multicore-Multithreading stehen hier im Vordergrund. Die Software-Architektur ist hier die Basis für eine optimale Softwareverarbeitung. Geschwindigkeit vs. Strombedarf, mit dem Ziel einer hohen System-Effizienz: „Möglichst viele MIPS pro Watt“.
Für verschiedene Applikationen werden Arithmetik-Unterstützung wie Floating-Point oder DSP-Support gefordert. Hier benötigt man unter Umständen einen speziellen Arithmetik-Coprozessor. Einige CPU-Architekturen verfügen über einen erweiterten Befehlssatz (Floating Point Arithmetik, digitale Signal-Prozessor-Befehle DSP), der für die Abarbeitung dieser speziellen Arithmetik zur Verfügung steht.
Anwendungsbeispiele hierfür sind komplexe Motorsteuerungen, komplexe Auswertung von Sensorik, Bild- und Ton-Verarbeitung. In den meisten Fällen können nur spezifische Core-Architekturen die Forderungen erfüllen. Als Mikrocontroller kommen hier fast ausschließlich heterogene Rechenkerne zum Einsatz, die die Anforderungen der spezifischen Arithmetik erfüllen.
Fazit:
Die Erwartungen an die Rechenkapazität bei einem moderaten Stromverbrauch der Multicore-Mikrocontroller sind sehr hoch, können jedoch in der Realität nur erreicht werden, wenn eine stikt strukturierte Software-Architektur und ein klar definiertes Zeitprofil der Applikation zur Verfügung stehen.
Schritt 2: Safety und Security: Sind in der Applikation Sicherheitsanforderungen zu erfüllen?
Im ersten Schritt der Multicore-Auswahl ging es um die Bestimmung der Requirements hinsichtlich Rechenleistung und deren Bewertung für das Projekt. Als zweiten Schritt betrachten wir nun die Anforderungen bezüglich funktionaler Sicherheit und Datensicherheit.
Kommen bei einer Applikation Anforderungen zu Safety und Security ins Spiel, ist eine umfassende Anforderungsanalyse für diese Aspekte sehr wichtig. So wird z.B. zum Erreichen des ASIL-Levels C gefordert, dass die Ergebnisse des Main-Core-Programms mit den Ergebnissen des im Lockstep-/Checker-Core zeitversetzt bearbeiteten Programms verglichen werden.
Dies ist notwendig, um temporäre Fehler in der Ergebnisberechnung des Safety Cores zu erkennen. Als Antwort auf erkannte Fehler muss das System imstande sein, geeignete Fehlerantworten zu generieren.
So muss in speziellen Fällen eine Fehlerantwort ohne Beteiligung von Software das System in einen sicheren Zustand versetzen können. Hier wird ein Safety-Hardwaremodul (Safety Management Unit) benötigt, das für jeden erkannten Fehler automatisch eine vom Anwender gewählte bzw. voreingestellte Fehlerantwort generiert, z.B. Exception/ Trap Routine, Reset, CPU Idle State oder ein externes Fehlersignal.
Für die Ermittlung der Anforderungen, die bei Safety-relevanten Applikationen berücksichtigt werden müssen, ist zunächst eine Analyse der möglichen Gefahren sowie eine Bewertung der Risiken durchzuführen.
Der geforderte Safety-Level bestimmt dann z.B., welche Safety-Hardware in einem Mikrocontroller enthalten sein muss, damit das System den zu erreichenden Grad der Sicherheit sicherstellt.
Eine ähnliche Vorgehensweise gilt für die Security-Thematik:
Die Security-Ziele (Security Goals) und Angriffspotentiale, durch die ein System Ziel eines Angriffs werden kann, sind zu bestimmen und zu untersuchen. Ferner sollte man bewerten, ob diese möglichen Angriffe Auswirkungen auf die Systemsicherheit und Systemintegrität haben oder ob die Privatsphäre des Anwenders durch zusätzliche Maßnahmen geschützt werden muss.
Beispiele hierfür sind die folgenden Aspekte:
Muss das System Schutzmechanismen für die Software der Applikation gegen Daten- und Parameter-Manipulation enthalten?
• Gibt es die Möglichkeit, im Software-Bootprozess nicht-autorisierte Zugriffe über externe Interfaces zu erkennen und zu verhindern?
Gibt es einen Hardware-Support für passwortgeschützte/verschlüsselte Kommunikation und die Möglichkeit, Viren in der Kommunikation zu erkennen und unschädlich zu machen?
Das Ergebnis dieser Analyse bestimmt, welcher Security-Support im System benötigt wird. Für die Auswahl des Mikrocontrollers, der für die Erfüllung der Security-Ziele verantwortlich ist, gilt es zu untersuchen, ob die dazu notwendigen Hardware-Voraussetzungen erfüllt sind:
Secure Software Boot und Crypto Bootloader für sicheren Software-Start und Flash-Updates
Flash-Protection-Mechanismen
Zugriffsgeschützter Security Controller (von der Applikation getrennte (private) Flash- und SRAM-Bereiche)
Fazit:
Erweiterte Anforderungen an die Sicherheit im System bzw. Safety und Security erfordern spezifische Hardware-Module in den Mikrocontrollern.
Schritt 3: Sind die vorhandenen Ressourcen in der Peripherie ausreichend?
Nach der Untersuchung der Anforderungen des Projektes hinsichtlich funktionaler Sicherheit (Safety) und Datensicherheit (Security) befasst sich der letzte Schritt mit den Peripherie-Bausteinen.
Ein Pin, mehrere Peripherie-Funktionen
Die ausreichende Pin-Anzahl ist neben der zur Verfügung stehenden Rechenkapazität ein entscheidender Faktor für den Erfolg eines Projektes. Alle Mikrocontroller haben eine Einschränkung gemeinsam: Es gibt in der Regel immer mehr Peripherie-Funktionen als verfügbare Pins.
Einige Mikrocontroller werden bei gleichem internem Silizium mit unterschiedlichen Gehäuse-Typen angeboten. Gehäuse mit weniger Pins sind typischerweise kostengünstiger und benötigen obendrein weniger Platz auf der Baugruppe. Weniger Pins bedeuten aber gleichzeitig, dass weniger Peripherie-Funktionen von außen sichtbar oder von außen ansprechbar sind bzw. nach außen wirken können. Eine Kernaufgabe ist hier also die Untersuchung, ob die zwingend benötigten Peripherie-Module auch alle über die erforderlichen Ports-Pins verfügen.
Performance-Steigerung durch Core-private Speicher
Die Multicore-Mikrocontroller-Architekturen unterscheiden sich maßgeblich voneinander in der Speicher-Implementierung:
viel globaler Speicher und wenig Core-lokaler Speicher
wenig globaler Speicher und viel Core-lokaler Speicher
Wird sehr hohe Rechenperformance benötigt, kann dies durch viele Core-lokale Speicher und eine hohe Core-Taktung erreicht werden. Ferner können die Programme in lokalen Speichern besser vor unberechtigtem Zugriff anderer Cores gesichert werden.
Das On-chip-Bussystem - eine Performance-Bremse?
Bussysteme, die nur serielle Kommunikation erlauben, können sich schnell zu einem „Bottleneck“ in der Applikation entwickeln, wenn viele Daten kommuniziert werden müssen. So kann es z.B. bei der Anwendung von Ethernet-Modulen vorkommen, dass diese Einheiten in der Regel nicht über genug privaten Speicher verfügen. Besser sind die Implementierungen von Bus-Matrix-Systemen, wie z.B. einem Crossbar-Switch. Diese Implementierung wird heute als Bus-Interface für die Verbindung von Cores zu den globalen Ressourcen eingesetzt. Meist sind alle Peripherie-Module über ein gemeinsames oder zwei serielle Bussysteme angeschlossen.
Zur Verhinderung von unliebsamen Überraschungen lohnt sich eine Performance-Analyse an den verwendeten Bussystemen, damit es in der realen Anwendung nicht zu unerwarteten Kommunikationsverzögerungen kommen kann.
Fazit:
Für einen erfolgreichen Umstieg einer Hard-Realtime-Applikation mit Singlecore nach Multicore ist ein Ressourcen-Management bei der Mikrocontroller-Auswahl sehr ratsam.
