Quo vadis, Multicore?

Seite: 2/3

Firmen zum Thema

Einsatzgebiete

Betrachtet man sich eine Zusammenstellung von generell wichtigen Innovationstreibern für die Entwicklung neuer eingebetteter Systeme, so finden sich auch zahlreiche darunter, die eine Forderung nach Multicore-Lösungen nach sich ziehen. Gerade auch im Automotive-Umfeld finden sich gesteigerte Anforderungen in Applikationsbereichen wie Drive-by-Wire (Lenkung, Bremse, etc.) oder Fahrerassistenzsysteme, zunehmend gepaart mit Frage nach funktionaler Sicherheit gemäß ISO26262. Hersteller versuchen, eine Vielzahl an herausfordernden Funktionen in kleinere Einheiten und weniger Systeme zu integrieren, die traditionell über viele Steuereinheiten aufgeteilt waren. Dadurch sollen Kosten gespart, die Komplexität verringert und der Strombedarf reduziert werden.

Innovationstreiber:

  • Höhere Rechenleistung
  • Senkung des Stromverbrauchs
  • Niedrigere Kosten (BOM (Bill of Material), NRE (Non-Recurring Engineering))
  • Gesteigerte Sicherheit
  • Höherer Grad an Integration
  • Schnellere Produkteinführung
  • SWaP (Size, Weight and Power)
  • Etc.

Lessons Learned

Welche Lehren lassen sich nun aus den ersten Jahren Erfahrung mit Multicore-Ansätzen bei Mikrocontrollern ziehen? Zunächst sei anzumerken, dass sich bereits im Vorfeld einige neue Herausforderungen herauskristallisiert hatten, die sich schlussendlich auch als wirkliche Herausforderung manifestiert haben. Gerade die Weisheit, dass eine Vervielfachung der Anzahl der Rechenkerne nicht eine ebensolche Vervielfachung der Rechenleistung nach sich ziehen wird, stellt sich als Tatsache heraus.

In diesem Zusammenhang ist die Architektur des Gesamtsystems sowohl auf Hardware- als auch auf Softwareebene ausschlaggebend und nicht die rein rechnerische Leistung. Auch der Aufwand einer Migration von einem bestehenden Singlecore-System auf ein Multicore-Derivat wird tendenziell zu optimistisch gesehen. Gerne wird zusätzlicher Aufwand hinsichtlich neuer notwendiger Optimierungen sowie einhergehender Tests falsch eingeschätzt. Bei genauerer Betrachtung der Aufgaben stellt sich häufig auch die Einsicht ein, dass eine neue Software-Architektur unausweichlich ist, um tatsächlich in den Genuss der Vorteile von Multicore zu kommen.

Damit einher geht auch die Erkenntnis, dass zum Erreichen der Integrations- und Leistungsziele das Ausschöpfen von Hardware-spezifischen Features notwendig ist. Dies geht meistens wieder zu Lasten der Portabilität, was den Software-Umfang weiter steigen lässt. Um den Leistungsabfall bei Verwendung von geteilten Ressourcen (z.B. globaler Speicher) abzufedern, werden vielerorts Cache-Speicher eingesetzt.

Hier hat sich allerdings gezeigt, dass die entsprechenden Cache-Controller wichtige Features wie Cache-Flush nicht eingebaut haben, was gerade im Bereich von Datenspeichern zu Kohärenz-Problemen führen kann. Auch die Messgröße der Stromaufnahme wird durch Multicore-Ansätze nur teilweise adressiert. Dies gilt auch weil bei Mikrocontrollern die Integrationsdichte noch nicht so weit fortgeschritten ist (auch der Integration von analogen Komponenten geschuldet), als dass sich großer Leakage bei neuen Prozesstechnologien als Treiber für Multicore-Ansätze aufführen ließe.

Hinsichtlich Debug-Unterstützung hat sich das große Datenaufkommen als schwierig zu handhaben herausgestellt. Dies gilt insbesondere auch in Zusammenhang mit Trace, wo unter Umständen sogar Einschränkungen in Kauf genommen werden müssen, wonach sich nur eine Untergruppe von Kernen tatsächlich aufzeichnen lässt.

(ID:44202360)