ESE Kongress 2015 „Wir brauchen eine neue Multicore-Architektur“

Der Umstieg von Single- auf Multicore-basierte Designs in Embedded Systemen verspricht neue Chancen, bringt aber auch Herausforderungen und Probleme. Die Experten der Podiumsdiskussion auf dem ESE Kongreess 2015 sind sich in einem Punkt einig: Multicore steht erst am Anfang - und erfordert neue Herangehensweisen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

RTI Real-Time Innovations

Green Hills Software GmbH

ARM Germany GmbH

mehr weniger

HighTec EDV-Systeme

PLS Programmierbare Logik & Systeme GmbH

Infineon Technologies AG

weniger

„Ich habe noch nie eine Architektur gesehen, die so viel Support erfordert“: Mit diesen Worten von Microconsult-Geschäftsführer Ingo Pohle begann die Podiumsdiskussion des diesjährigen ESE Kongresses in Sindelfingen. Sieben Industrieexperten stellten sich vor dem versammelten Publikum der Frage: Stellt Multicore in der Embedded-System Segen oder Fluch dar - oder bedeutet es letztendlich beides?

Bildergalerie

Bildergalerie mit 7 Bildern

Eine Grundfrage, zu der auch das versammelte Publikum gespalten war. Tendenziell möchten wohl viele Entwickler Multicore als Segen begreifen. Doch wie Marcus Gößler, Trainer und Coach bei Microconsult, als Moderator der Runde bereits zu Beginn feststellte: Der Einsatz von Multicore in einem Embedded System verspricht viele neue Möglichkeiten, stellt aber Entwickler vor neue Herausforderungen.

Software muss besser vorbereitet werden

Ein grundlegendes Problem ist, dass die bis dato entwickelte Systemsoftware auf Singlecore-Systemen läuft, aber nicht auf den Einsatz auf mehreren Kernen vorbereitet ist. Speziell beim Umschalten oder zuordnen von Tasks auf einzelne Cores entstehen hierdurch oft Probleme. Die versammelten Experten waren sich einig: Während man beim Singlecore bisweilen noch mit „unsauberem“ Spaghetticode durchkommen mag, erfordert die Programmierung für Multicore ein viel höheres Maß an Präzision.

Dr. Karsten Schmidt, Projektleiter der Audi Electronics Venture, sprach dann auch gleich die Forderung aus: Raus mit dem Alten, rein mit dem Neuen. Seine Erfahrung habe gezeigt, dass es beim Umstieg auf Multicore manchmal besser sei, den alten Singlecore-Code wegzuschmeißen und noch einmal neu anzufangen, als zu versuchen, die bestehende Singlecore-Software auf eine Multicore-Architektur zu portieren. Die Einführung von Multicore in ein Design sei gewissermaßen der Lackmus-Test des bestehenden Designs, der bestätigt: Habe ich eine ordentliche Systemarchitektur, habe ich eine ordentliche Software-Architektur?

Als Vertreter von Debugging-Seite hakte Heiko Rießland, Produktmarketing-Manager des Toolherstellers PLS, ein, dass Multicore weniger neue Probleme schaffe, als vielmehr ein Katalysator für bereits bestehende Probleme sei: Die Schwierigkeiten, die bei der Entwicklung auftreten, seien meist nicht neu, sie treten allerdings stärker zu Tage.

„Harte“ Embedded-Multicores vs. „weichgespülte“ PC-MCs

Ein generelles Problem, vor dem Entwickler bei Multicore-Systemen stehen, ist der Punkt funktionale Sicherheit. Dr. Albrecht Mayer, System Architect der 3. Generation an AURIX-Chips von Infineon, bestätigte diese Ansicht: Im Mikrocontroller-Bereich könne Multicore noch nicht die „harte“, unmittelbare Echtzeit bereitstellen, die für funktionale Sicherheit unverzichtbar ist. Um das zu beheben, brauche es eine neue, viel transparentere Architektur. Er unterscheide demnach Multicore generell in zwei Klassen: Die „harten“ Embedded-Multicores und die „weichgespülten“ PC-Multicores, bei denen es nicht auf so unmittelbare Echtzeitanforderungen ankäme und die daher kein Problem damit hätten, sich viele Probleme vom Betriebssystem bereits abnehmen und softwareseitig die Tasks auf den einzelnen Cores zuweisen zu lassen.

André Schmitz, FAE Green Hills Software, verwehrte sich gegen den Begriff „weichgespült“. Softwareseitig ließe sich auch auf PC-Multicores eine harte Echtzeit produzieren. Die Vertreter des Hardware-Lagers konnte er damit aber nicht überzeugen: Software-Lösungen, so Dr. Albracht Mayer, bräuchten einfach zu lang, um die etwa für funktionale Sicherheit nötige Echtzeit bereitzustellen.

Speziell an ARM gerichtet kam daher die Frage, wieso das Thema Multicore auf PC-Ebene schon so lange etabliert sei, im Mikrocontroller-Bereich derzeit aber noch immer kaum zur Geltung komme. Christopher Seidl, Technical Marketing Manager ARM/Keil, räumte ein, dass man speziell die ARMv7-Architektur hier noch etwas hinterherhinke. Man sitze aber gerade daran dass zu beheben. Erst vor kurzem habe man eine neue Architektur vorgestellt, die chipseitig dem Entwickler neue Handreichungen bietet, um ihm die Entwicklung auf Mikrocontroller-Ebene weiter zu erleichtern.

Ingo Pohle, Geschäftsführer von Microconsult, ging in seiner Forderung allerdings einen Schritt weiter: Das Thema Multicore an sich ist noch lange nicht abgehakt, man stehe noch am Anfang. Man müsse sich ein neues Konzept überlegen, wie etwa mit Interrupt-Technik umzugehen sei oder wie man sinnvoll mit Timings handhabt. Sein Fazit: Alte Zöpfe müssen abgeschnitten werden, neue Ansätze müssen her: „Wir brauchen eine neue Architektur, die sinnvoll und effektiv mit einem solchen Multicore umgeht“.

Erleichterungen und Wege für die Zukunft

Mehrheitlich kam die Runde zu dem Ergebnis, dass die weitere Evolution von Multicores hardwareseitig, bei den Architektur-Entwicklern und Halbleiterherstellern, erfolgen muss. Die Zukunft führe nicht an Multicore vorbei: In vielen Entwicklungen, gerade auch im Automotive-Bereich, müsse mehr Rechenleisung her, die nur noch durch Multicore darstellbar sei, so Dr. Karsten Schmidt.

Bildergalerie

Bildergalerie mit 7 Bildern

Es sei aber schwierig, bei vielen Entwicklern das Verständnis für die Unterschiede zu Singlecore zu vermitteln: dass es hierbei parallele Prozesse gibt, dass Abhängigkeiten bestehen und Datenaustausch wichtig ist. Firmen müssen hier bei ihren Mitarbeitern auf eine Weiterbildung setzen, und Tools wie Compiler müssen sich dahingehend weiterentwickeln, anders komme man nicht weiter.

Dem schloss sich Mario Cupelli vom Tool-Hersteller Hightec an, fügte aber hinzu, dass hier bereits eine Menge passiert sei. So verwies er etwa auf die bereits auf dem Chip integrierten Trace-Funktionen der Aurix-Mikrocontroller von Infineon. Hardware, sagte Cupelli, bringt immer mehr neue Features mit, die beim Design die Arbeit erleichtere, insbesondere beim Tracing und Debugging.

Was sich als Tenor aus der Diskussion heraushören ließ, so André Schmitz, sei, dass es wichtig ist, ein durchgängig schlüssiges System zu besitzen, mit dem ein Entwickler arbeiten kann. Das finge beim Betriebssystem an um die Multicores vernünftig zu bedienen und die Tasks zu verarbeiten, bis hin zu Debug-Lösungen, die in der Lage sein müssen, ein sinnvolles Bild des Systems auf der Hardware darzustellen um zu sehen, was wirklich auf den einzelnen Kernen läuft.

Zum Abschluss gab Moderator Gößler den Teilnehmern der Podiumsdiskussion noch eine kleine Denkaufgabe: Mit dem würden die einzelnen Vertreter unter den Anwesenden am ehesten ein Startup gründen, um die Vereinfachung von Multicore-Entwicklern voranzutreiben. Das Ergebnis: Am meisten vertrauen die Experten hier auf die Halbleiterhersteller oder Architekturentwickler: Infineon und ARM fanden die häufigste Erwähnung für diesen Weg in die Zukunft.

(ID:43761388)