Performance-orientiertes Speichermanagement bei Embedded-Multicore-Mikrocontrollern

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

Auch in Kraftfahrzeugen kommen verstärkt Multicore-Mikrocontroller zum Einsatz. Diese verwenden eine umfangreiche Speicherhierarchie, um Speicherzugriffe zu beschleunigen und Echtzeitfähigkeit beeinflussende Konkurrenz zu vermeiden. Dies kann sich aber massiv auf die Leistungsfähigkeit der MCUs auswirken.

Um den gestiegenen Anforderungen an die Leistungsfähigkeit von echtzeitfähigen Steuergeräten gerecht zu werden, erfolgt in diesem Bereich verstärkt der Einsatz von embedded Multicore-Mikrocontrollern. Im Gegensatz zu den bisher verwendeten Singlecore-Lösungen erfordern Multicore-basierte Steuergeräte deutlich mehr Planung bei der Verteilung von Aufgaben auf die Prozessorkerne sowie die Koordinierung von Speicher- und Peripheriezugriffen, um eine optimale Zuverlässigkeit zu gewährleisten [5][9]. Durch konkurrierende Zugriffe auf geteilte Ressourcen können Wartezeiten entstehen, welche die Vorhersagbarkeit massiv beeinflussen und die Echtzeitfähigkeit gefährden.

Zur Reduzierung dieser Problemstellung nutzen viele Multicore-Mikrocontroller ein umfangreiches Speichermanagement, welches die potentiellen Wartezeiten beim Zugriff auf geteilte Speicher minimieren soll. Dabei kommen hauptsächlich dedizierte lokale RAM-Speicher für jeden Prozessorkern sowie Caches zum Einsatz. Zu berücksichtigen ist dabei, dass Caches bei korrekter Verwendung die Leistung eines Multicore-Prozessors zwar massiv steigern können, die Vorhersagbarkeit jedoch erschwert wird [7][18].

Um die Einflüsse von konkurrierenden Speicherzugriffen möglichst gering zu halten, ist es notwendig, das Speichermanagement des verwendeten Multicore-Mikrocontrollers als Ganzes zu betrachten. Eine separierte Untersuchung einzelner Speicher kann zwar deren Leistungsfähigkeit erhöhen, jedoch ist dies nicht zwingend der Fall für das Gesamtsystem.

Aus diesem Grund wird in diesem Artikel das Speichermanagement von drei embedded Multicore-Mikrocontrollern mit verschiedenen Konfigurationen auf seine Leistungsfähigkeit untersucht. Das Ziel ist dabei, einen Überblick über die verfügbaren Speicher und deren optimalen Einsatz zu geben. Folgende Punkte sollen im Rahmen dieses Artikels untersucht werden:

• Einfluss des Speichermanagements auf die Gesamtperformance des Systems,

• Einfluss von konkurrierenden Speicherzugriffen auf die Gesamtperformance des Systems,

• Einfluss der Strukturierung des Programmcodes in dem Speicher.

Der Aufbau dieses Artikels unterteilt sich in vier Bereiche. Nach der Einleitung werden die in den Versuchsreihen verwendeten Mikrocontroller vorgestellt und das zugrundeliegende Speichermanagement beschrieben. Als nächstes erfolgt die Vorstellung der ermittelten Resultate. Abschließend werden die gezeigten Ergebnisse diskutiert und Vorschläge zur Optimierung des Speichermanagements gegeben.

Beispiele 1&2: Infineon AURIX 1. Generation

Für die Messungen in diesem Artikel werden die beiden Derivate TC298 und TC277 aus der ersten AURIX-Generation verwendet, deren Aufbau aus Bild 1 entnommen werden kann.

Beide Derivate besitzen drei Prozessorkerne, wobei der TC298 drei identische Performance-Kerne und der TC277 zwei Performance-Kerne sowie einen leistungsschwächeren Efficency-Kern nutzt. Die Prozessorkerne sind über eine Crossbar mit den globalen Speichern des Mikrocontrollers verbunden. Als globale Speicher stehen die Program Memory Unit, welche den Flash bereitstellt und die Local Memory Unit, welche den globalen RAM Speicher beinhaltet, zur Verfügung. Bedingt durch die Verwendung einer Crossbar können parallele Verbindungen von unterschiedlichen Mastern zu unterschiedlichen Slaves aufgebaut werden. Dabei fungieren die Prozessorkerne als Master und die globalen Speicher als Slaves.

Wie Bild 1 zeigt, unterscheiden sich der Infineon AURIX TC298 und der TC277 bei der Anbindung der Program Memory Unit. Der TC298 bietet insgesamt vier Schnittstellen an die Crossbar, wodurch ein paralleler Zugriff der drei Prozessorkerne auf unterschiedliche Program Flashs möglich ist. Im Gegensatz dazu bietet der TC277 lediglich zwei Interfaces, weshalb ein paralleler Zugriff bei Nutzung aller drei Prozessorkerne verhindert wird [6].

Neben den globalen Speichern besitzt jeder Kern noch zwei lokale Speicherinterfaces. Bedingt durch die verwendete Harvard-Architektur ist ein Interface für den Zugriff auf den Programmcode (Program Memory Interface) und eines für den Zugriff auf die Daten (Data Memory Interface) zuständig. Jedes Interface besteht dabei aus zwei unterschiedlichen Speichern, wobei der Zwei-Wege-Assoziative-Cache durch den Mikrocontroller verwaltet wird und der lokale RAM vom Entwickler genutzt werden muss. Der Vorteil dieser lokalen Speicher liegt in ihrer geringen Zugriffszeit, wodurch die Ausführungsgeschwindigkeit signifikant gesteigert werden kann. Die jeweiligen Größen der vorhandenen Speicher können der Tabelle 1 entnommen werden.

Ein weiteres Unterscheidungsmerkmal ist der Prozessortakt mit denen die beiden Derivate maximal spezifiziert sind. Der Infineon AURIX TC298 bietet 300 MHz während der TC277 höchstens mit 200 MHz betrieben werden kann. Zur besseren Vergleichbarkeit der architektonischen Besonderheiten der beiden Derivate werden diese in den folgenden Messreihen mit 200 MHz betrieben.

Beispiel 2: Infineon AURIX 2. Generation

Der TC397 A-Step entstammt der zweiten AURIX-Generation. Die TC397XX-Reihe verfügt über sechs Tricore-Kerne und ein geändertes Speicherlayout. Der grundlegende Aufbau kann dem Bild 2 entnommen werden.

Im Vergleich zu der ersten AURIX-Mikrocontrollergeneration hat Infineon beim TC397 die maximal verfügbare Anzahl an Prozessorkernen verdoppelt. Des Weiteren wurden Optimierungen bei dem Speicherlayout vorgenommen, wodurch jeder Kern einen separaten Zugriff auf einen Bereich der globalen Speicher erhält. Durch diese direkte Anbindung soll zum einen die Zugriffszeit auf die Program Memory Unit und die Local Memory Unit verringert und zum anderen die Crossbar entlastet werden. Trotzdem ist weiterhin ein Zugriff von jedem Prozessorkern auf jeden Speicher im System möglich, wobei die volle Zugriffsgeschwindigkeit nur über die direkte Anbindung erreicht werden sollte.

Eine weitere Unterscheidung der beiden Generationen besteht in der Aufteilung der Crossbar in zwei Domains. Diese Aufteilung ist der gestiegenen Anzahl an Teilnehmern an der Crossbar geschuldet. In der ersten Domain sind vier der sechs Kerne sowie die Program Memory Unit und ein Teil der Local Memory Unit untergebracht. Durch die zweite Crossbar werden die zwei restlichen Kerne sowie ein weiterer Bestandteil der Local Memory Unit angebunden. Über eine Bridge sind die beiden Domains miteinander verbunden.

Das Layout der lokalen Speicher entspricht der ersten AURIX-Generation, jedoch wurden die Speichergrößen angepasst. Eine detaillierte Gegenüberstellung kann der Tabelle 1 entnommen werden. Im Gegensatz zu den Derivaten der ersten AURIX-Generation verwendet Infineon bei der TC3xx-Serie ausschließlich die leistungsstärkeren Performance-Kerne, welche maximal einen Prozessortakt von 300 MHz bieten [1].

Speicherzugriff

Obwohl sich das Speicherlayout zwischen den beiden AURIX-Mikrocontrollergenerationen verändert hat, ist der Zugriff auf die vorhandenen Speicher ähnlich geblieben. Unterschiede gibt es lediglich bei den Zugriffsgeschwindigkeiten auf die globalen Speicher, da die zweite AURIX-Generation durch die direkte Anbindung einen Vorteil hat.

Wie auf Bild 3 zu sehen ist, besitzt der Prozessorkern für die Ausführung von Programmcode vier verschiedene Speicher, welche sich in ihrer Latenz unterscheiden. Der Zugriff auf diese Speicher erfolgt über die Instruction Fetch Unit, welche die nächsten sechs Befehle aus dem Programmspeicher lädt und für die Abarbeitung vorhält.

Dabei erfolgt der Zugriff auf die Program Memory Unit immer als 256 Bit langer Burst Read Befehl. Zur Beschleunigung dieser Anfragen auf den Program Flash verwendet die Program Memory Unit einen Prefetch Buffer, welcher die angefragten Daten bereitstellt. Bei jedem Lesezugriff auf die Prorgam Memory Unit wird in dem ersten Schritt geprüft, ob die benötigten Daten bereits in dem Prefetch Buffer vorliegen. Bei einer negativen Prüfung müssen die Daten aus dem Program Flash nachgeladen werden. Zu diesem Zweck lädt der Prefetch Buffer die angeforderte Flash Line sowie die zwei nachfolgenden Lines. Bei einem sequentiellen Programmablauf soll bei einem weiteren Lesebefehl die Zugriffsgeschwindigkeit durch den Prefetch Buffer verbessert werden. Falls jedoch mehrere Kerne abwechselnd auf denselben Program Flash, aber mit unterschiedlichen Adressen zugreifen, sollte dadurch die Funktionalität des Prefetch Buffers komplett aufgehoben werden.

Eine weitere Zugriffsbeschleunigung stellt der integrierte Program Cache des Program Memory Interface dar. Dieser Zwei-Wege-assoziative Cache puffert häufige Anfragen aus den globalen Speichern lokal vor, um die Zugriffszeiten signifikant zu verkürzen. Auch dieser Speicher ist für eine sequentielle Abarbeitung ausgelegt. Bei permanenten Adresssprüngen sollte die Funktion des Program Cache ebenfalls deutlich beeinträchtigt werden [8].

Der globale RAM in Form der Local Memory Unit wird ebenfalls über die Crossbar angesprochen und wird daher eine langsamere Zugriffszeit als der lokale RAM auf-weisen. Auch wiederholte Anfragen an diesen Speicher können durch den Program Cache beschleunigt werden.

Der vierte Speicher wird durch den lokalen RAM des Program Memory Interface realisiert. Dieser Speicher ist an den Prozessorkern direkt angebunden und kann ohne Umweg über die Crossbar direkt angesprochen werden. Ähnlich wie der Program Cache kann dieser Speicher besonders schnell Daten zur Verfügung stellen und sollte die Ausführungsgeschwindigkeit signifikant steigern können [1].

Versuchsaufbau

Die durchgeführten Untersuchungen erfolgten mit drei Evaluierungsboards der Firma hitex, siehe Tabelle 2.

Für das Flashen und zur Überwachung der Programmausführung wird ein Debugger der Firma Lauterbach genutzt. Die Verifizierung der durchgeführten Zeitmessung erfolgt mit einem pico Technology USB-Oszilloskop. Eine Auflistung aller genutzten Geräte kann der Tabelle 3 entnommen werden.

Als Basissoftware wird das Infineon Software Framework mit der dazugehörigen Treiberbibliothek Infineon Low Level Driver verwendet. Für den Vergleich der Leistungsfähigkeit der unterschiedlichen AURIX-Derivate wurde der CoreMark von EEMBC als Benchmark genutzt. Das Erstellen der Testsoftware erfolgt mit einem Compiler und Linker der Firma Tasking. Die Tabelle 4 schlüsselt die Versionen der genutzten Software auf.

Für die gezielte Provokation der Engpässe der verwendeten Multicore-Mikrocontroller müssen die Prozessorkerne synchron mit der Ausführung des Benchmarks beginnen. Zur Synchronisierung werden die Broadcast-Interrupts der AURIX-Familie genutzt, wodurch eine parallele Ausführung auf allen Prozessorkernen realisiert wird. Außerdem werden alle weiteren Interrupt-Quellen deaktiviert, damit zwischenzeitliche Unterbrechungen ausgeschlossen sind. Die Bestimmung der benötigten Rechenzeit für die Ausführung des Benchmarks erfolgt mit den internen General Purpose Timern. Zur Validierung der Messergebnisse für jeden Prozessorkern werden zusätzlich einzelne Pins des Mikrocontrollers vor und nach dem Beenden des Benchmarks geschaltet und die Veränderung mit dem Oszilloskop erfasst.

Resultate

Infineon AURIX 1. Generation: Infineon AURIX TC298
n der ersten Messung wird untersucht, inwieweit sich die Positionierung des Benchmark-Codes in den globalen Speichern des Infineon AURIX TC298 auf die Ausführungsgeschwindigkeit auswirkt. Dazu wird in der ersten Messung der komplette Programmcode für die drei Prozessorkerne in dem Program Flash 0 der Program Memory Unit positioniert. Durch diese Verteilung sind die drei Prozessorkerne gezwungen, konkurrierend auf diesen Speicher zuzugreifen. Um den Einfluss des Prefetch Buffers in der Program Memory Unit auf die Messergebnisse gering zu halten, wird der Programmcode des Benchmarks für jeden Kern in einen separaten Sektor des Program Flash 0 abgelegt.

In Bild 4 ist zu sehen, dass die Leistung mit jedem weiteren Kern nicht linear steigt, obwohl die Bearbeitung des Benchmarks keine Abhängigkeiten in der Software zwischen den Prozessorkernen aufweist. Dies bedeutet, dass durch den konkurrierenden Zugriff auf den globalen Flash-Speicher die maximale Leistung begrenzt wird. In der zweiten Messreihe Program Flash X wird der Programmcode für jeden Prozessorkern in einem separaten Program Flash abgelegt. Dadurch können die Prozessorkerne unabhängig voneinander auf den globalen Speicher zugreifen. In diesem Szenario steigt die Leistung des Systems mit jedem weiteren Prozessorkern linear an und erreicht in der abschließenden Messung mit drei Kernen ca. 30% mehr Punkte in dem Benchmark als bei der Messung Program Flash 0.

Ähnlich wie die Program Memory Unit verhält sich die Local Memory Unit in der dritten Messreihe. Bedingt durch den konkurrierenden Zugriff der drei Prozessorkerne steigt die Leistung des Systems ebenfalls nicht linear an. In der vierten Messreihe wird die Messung mit aktiviertem Program Cache wiederholt. In Abbildung 4 ist zu sehen, dass die Leistung des Gesamtsystems signifikant und linear mit jedem weiteren Prozessorkern ansteigt. Dabei spielt es in den Messreihen keine Rolle, in welchem der globalen Speicher der Programmcode abgelegt wird. In jedem Szenario werden identische Messwerte er-reicht. Dieser Umstand ist darauf zurückzuführen, dass der Program Cache den gesamten Programmcode für den Benchmark in einer seiner beiden Pages vorhalten kann. Dadurch sind die Prozessorkerne nicht mehr gezwungen, auf den langsameren globalen Speicher konkurrierend zuzugreifen.

In Bild 5 wird die Leistungsfähigkeit der lokalen RAM Speicher untersucht. In der ersten Messreihe Program RAM 0 wird dazu der Programmcode des CoreMark in den lokalen RAM von dem ersten Prozessorkern allokiert. Sobald ein Prozessorkern aktiv ist, wird eine identische Geschwindigkeit wie bei der Verwendung des Program Cache erreicht. Sobald weitere Prozessorkerne ebenfalls auf den lokalen RAM von Core 0 zugreifen, steigt die Gesamtperformance nicht mehr linear mit jedem weiteren Prozessorkern, was eine Folge der konkurrierenden Zugriffe ist. Für die zweite Messreihe Program RAM X wird der Code des Benchmarks in den Program RAM der jeweiligen Prozessorkerne allokiert. Durch diese Aufteilung wird ein konkurrierender

Lesezugriff verhindert und die Leistung des Gesamtsystems steigt mit jedem weiteren Kern linear an. Durch die optimale Verteilung kann ein Leistungsgewinn von 80% gegenüber der Messung Program RAM 0 erzielt werden. In der dritten Messreihe wird der Programmcode des Benchmarks in den lokalen RAM von Core 0 allokiert und zusätzlich werden die Program Caches der Prozessorkerne aktiviert. Da die Program Caches Lesezugriffe aus dem lokalen RAM Speicher nicht zwischenspeichern, gibt es keine Verbesserung bei der Gesamtperformance. Wie in der Messreihe Program RAM 0 mit Program Cache aufgezeigt wird, beeinflussen konkurrierende Zugriffe in diesem Fall die Leistungsfähigkeit des Gesamtsystems erheblich. Des Weiteren ermöglichen die Program Caches keine Entlastung der Crossbar bei konkurrierenden Zugriffen auf die lokalen RAM Speicher. Es ist daher festzuhalten, dass häufig genutzte Funktionen in dem lokalen RAM Speicher des Prozessorkerns allokiert werden sollten, welcher diese nutzt.

Bild 6 zeigt den Einfluss des Data Memory Interface auf die Ausführungsgeschwindigkeit des CoreMark auf. Wie in dem Diagramm zu sehen ist, hat das Data Memory Interface in keiner Konfiguration einen Einfluss auf die Performance des Gesamtsystems. Dieses Verhalten ist darauf zurückzuführen, dass der Core-Mark wenige lokale Variablen in den Berechnungen nutzt. Diese werden durch den Compiler als Register- und Stack-Variablen realisiert. Bei Applikationen, welche viele Variablen im RAM vorhalten, sollte das Data Memory Interface die Ausführung ebenso wie das Program Memory Interface beschleunigen, da die Funktionsweise identisch ist. Da die Messergebnisse des Data Memory Interface, bedingt durch den CoreMark, wenig Rückschlüsse auf die eigentliche Leistungsfähigkeit dieses Interfaces ermöglichen, wird bei den weiteren AURIX-Derivaten auf die Ermittlung dieser Messwerte verzichtet.

In Bild 7 wird die Ausführungsgeschwindigkeit auf einem Kern bei der Verwendung von unterschiedlichen Speichern ermittelt. Wie die Messung belegt, steigt die Performance eines Prozessorkerns bei der Verwendung der lokalen Speicher erheblich an. Interessant ist dabei die Tatsache, dass nur die lokalen Speicher, welche dem Kern zugeordnet sind, die Leistung fast um den Faktor 3 steigern können. Der Zugriff auf das Program Memory Interface der anderen Prozessorkerne ist dabei 27% schneller als der Zugriff auf die globalen Speicher, aber deutlich langsamer als die direkte Anbindung an die eigenen Speicher. Es gilt bei dieser Messreihe zu beachten, dass ein Prozessorkern exklusiven Zugriff auf die gesamte Anzahl der Speicher hat. Abhängigkeiten, wie konkurrierende Zugriffe, spielen in diesem theoretischen Szenario keine Rolle.

Infineon AURIX TC277

Äquivalent zur Messreihe für den Infineon AURIX TC298 wird in Bild 8 die Gesamtleistung des Infineon AURIX TC277 bei dem Zugriff auf die globalen Speicher ermittelt. In der ersten Messreihe wird der Programmcode für die drei Kerne in den Program Flash 0 allokiert. Analog zu dem TC298 steigt die Leistung mit jedem weiteren Kern nicht linear an, bedingt durch die konkurrierenden Zugriffe. In der zweiten und dritten Messreihe wird der Programmcode für die drei Prozessorkerne auf die beiden vorhandenen Flash-Speicher aufgeteilt. In der Messreihe Program Flash X – Variante 1 nutzt der Prozessorkern 0 den Program Flash 0 exklusiv und die Kerne 1 und 2 teilen sich den Program Flash 1. Im Gegensatz dazu verwenden in der Messreihe Program Flash X – Variante 2 die Prozessorkerne 0 und 1 den Program Flash 0 und der Kern 2 hat exklusiven Zugriff auf den Program Flash 1.

Wie in beiden Messreihen zu erkennen ist, steigt die Leistung nicht linear mit jedem weiteren Prozessorkern an, was dem internen Aufbau des Infineon AURIX TC277 geschuldet ist. Bedingt durch die Anbindung der Program Memory Unit mit zwei Crossbar-Schnittstellen erfolgt immer ein konkurrierender Zugriff bei Verwendung der drei Prozessorkerne. Jedoch kann dieser Flaschenhals unterschiedlich starke Auswirkungen auf die Gesamtperformance haben. Wie die Messreihe Program Flash X - Variante 1 und - Variante 2 zeigen, variiert die Leistung bei der Verwendung von zwei Prozessorkernen um 15%. Dabei hat die Variante 1 den Vorteil, dass in diesem Szenario die beiden Kerne unterschiedliche Flash-Speicher ansprechen und dadurch besser skalieren. Bei der Verwendung von drei Prozessorkernen hat die Variante 1 ebenfalls einen Vorteil, welcher 1% beträgt. Der Zugriff auf die Local Memory Unit verhält sich äquivalent zu dem Infineon AURIX TC298.

Ähnlich wie bei dem TC298 verhält es sich mit den Program Caches, welche die Leistung des Gesamtsystems im selben Maße steigern. Die Leistungsdifferenz zwischen den beiden Derivaten ist dem heterogenen Aufbau des TC277 geschuldet. Durch dessen effizienteren, aber langsameren, Efficiency-Kern ist die Gesamtperformance des Systems bei Verwendung von den drei Kernen 11% geringer als die des TC298. Im direkten Vergleich von einem Performance- mit einem Efficiency-Kern rechnet der Performance-Kern bei gleichem Takt ca. 30% schneller. Dieser Vor-teil wird aber nur bei der Verwendung der kerneigenen lokalen Speicher erreicht. Bei der Verwendung der lokalen Program RAMs zeigen der Infineon AURIX TC277 und TC298 ein identisches Verhalten. Der minimale Unterschied bei der Messung Program RAM X, welche im Gegensatz zu dem TC298 nicht linear ansteigt, ist durch die geringere Leistungsfähigkeit des Efficiency-Kerns begründet.

Das letzte Bild 10 für den Infineon AURIX TC277 stellt die Ausführungsgeschwindigkeit unter Verwendung verschiedener Speicher bei Nutzung des Efficiency-Kerns dar. Von einer separaten Ermittlung der Messwerte für den Performance-Kern wird in dieser Messung abgesehen, da die Werte denen des TC298 entsprechen. Ähnlich wie bei dem Performance-Kern profitiert auch der Efficiency-Kern von der Verwendung der kerneigenen lokalen Speicher durch eine Leistungssteigerung um den Faktor 2.1, allerdings nicht so stark wie der Performance-Kern.

Infineon AURIX 2. Generation: Infineon AURIX TC397
Bei der Verwendung der globalen Speicher verhält sich die zweite AURIX-Generation, in Form des TC397, äquivalent zu den Derivaten aus der ersten Generation. Deutlich wird jedoch, dass die gesteigerte Anzahl an Prozessorkernen die Herausforderung mit den konkurrierenden Zugriffen erhöht. Die Messreihe Program Flash 0 in Bild 11, bei welcher die sechs Kerne den Programmcode des Benchmarks aus dem Program Flash 0 beziehen, zeigt dies deutlich. Die Leistung des Gesamtsystems bei Verwendung von sechs Kernen liegt 77% über der Leistung von einem Prozessorkern. Dieser massive Leistungsverlust ist durch die interne Struktur der zweiten AURIX-Generation begründet. Jeder Prozessorkern hat zwar einen direkten Zugriff auf seinen separaten Flash Speicher, jedoch teilen sich die sechs Kerne lediglich ein Crossbar Interface für die Program Memory Unit. Dies bedeutet, dass bei Zugriffen außerhalb des eigenen Flash Speichers, die Kerne über lediglich ein Interface zugreifen müssen, welches eingehende Anfragen nur sequentiell bearbeiten kann. Daher ist es bei der zweiten AURIX-Generation noch entscheidender, den Programmcode in den entsprechenden Program Flash zu allokieren.

Bei optimaler Nutzung der vorhandenen Struktur hat Infineon den oben beschriebenen Flaschenhals der AURIX-Mikrocontroller aus der ersten Generation behoben, indem jedem Derivat der zweiten AURIX-Generation ein eigener Bereich der Program Memory Unit direkt zur Verfügung steht. Durch diese Optimierung können Engpässe bei dem Zugriff auf den globalen Flash-Speicher, wie beim TC277, vermieden werden. Des Weiteren konnte durch die direkte Anbindung der separaten Flash Speicher Segmente an den Prozessorkern die Zugriffsgeschwindigkeit bei gleichem Takt um 9% im Vergleich zu dem TC298 gesteigert werden. Ähnlich wie bei den Derivaten der ersten Generation kann bei dem TC397 die Leistung durch die Verwendung der Program Caches massiv gesteigert werden. Aus den Messungen ergibt sich, dass die Prozessorkerne der zweiten AURIX-Generation bei gleichem Takt eine identische Leistung wie die Derivate aus der ersten Generation aufweisen.

Äquivalent zur ersten AURIX-Generation bietet der TC397 ein Program Memory Interface, welches einen lokalen Program RAM und einen Program Cache beinhaltet. Dieses Speicher-Interface ist in seiner Verhaltensweise identisch zur bisherigen AURIX-Generation, was die aufgenommenen Messwerte bestätigen. Eine Neuerung gegenüber der ersten AURIX-Familie stellt die kerneigene Local Memory Unit dar, welche im Bild 12 untersucht wird. Wie die Messungen belegen, ist die Local Memory Unit schneller als der separate Program Flash, welcher dem Prozessorkern zugeordnet ist.

Trotzdem erreicht dieser Speicher nicht die Leistungsfähigkeit des Program RAM, jedoch können die Zugriffe auf die kerneigene Local Memory Unit durch den Program Cache beschleunigt werden. Dadurch steigt die Performance auf das Niveau des Program RAMs. Sobald jeder Prozessorkern seine eigene Local Memory Unit nutzt und dadurch konkurrierende Zugriffe effektiv verhindert werden, steigt die Leistungsfähigkeit des Gesamtsystems linear an. Dies wird durch die Messreihe Local Memory Unit X in Abbildung 11 aufgezeigt.

Bedingt durch den frühen Entwicklungsstand des TC397 sind die Local Memory Unit für die Kerne 4 und 5 derzeit nicht vorhanden. Aus diesem Grund endet diese Messkurve bereits nach vier Messwerten. Bei konkurrierenden Zugriffen auf die separate Local Memory Unit sinkt die Leistungsfähigkeit des Gesamtsystems deutlich ab. Wie in der Messkurve Local Memory Unit 0 aufgezeigt wird, steigt die Leistungsfähigkeit des Gesamtsystems bei Nutzung von sechs Kernen in Bezug zur Verwendung von einem Prozessorkern um den Faktor 3. Bei einer Versechsfachung der genutzten Rechenkerne ist dies kein optimales Ergebnis.

In Bild 13 für den Infineon AURIX TC397 wird äquivalent zu den Messungen für den TC298 und TC277 die Leistungsfähigkeit der einzelnen Speicher bei der Verwendung von einem Prozessorkern untersucht. Dabei ist besonders die Aufteilung der Speicher auf die beiden Crossbars von besonderem Interesse. Die ersten vier Säulen zeigen die Ausführungsgeschwindigkeit des CoreMarks bei Verwendung der globalen Speicher ohne den lokalen Program Cache.

Wie die Messungen belegen, ist die Zugriffsgeschwindigkeit bei Verwendung des separaten Program Flash schneller als bei den anderen Flash-Speichern. Die Ausführungsgeschwindigkeit bei Zugriffen auf Flash-Speicher, welche an derselben Crossbar angebunden sind wie der ausführende Prozessorkern, sind im Schnitt 14% schneller als bei Speichern, welche über die Crossbar einer anderen Domain angebunden sind. Zusätzlich konnte Infineon die Ausführungsgeschwindigkeit aus dem globalen RAM bei der zweiten AURIX-Generation steigern.

Während bei dem TC298 die Ausführung aus dem globalen RAM im Schnitt 5% schneller als aus dem Program Flash ist, kann der TC397 die Geschwindigkeit bei Nutzung des globalen RAMs um 25% steigern. Die Beschleunigung der wiederholten Zugriffe auf die globalen Speicher kann der TC397 ebenfalls durch seine Caches massiv beschleunigen. Dieses Verhalten ist identisch mit der ersten AURIX-Generation.

Bei der Verwendung der lokalen Program RAMs zeigt sich ein ähnliches Bild wie bereits bei dem Flash-Speicher. Bei Nutzung des eigenen lokalen RAMs erreicht der Prozessorkern die optimale Performance. Wird auf einen lokalen Program RAM eines anderen Kerns zugegriffen, welcher über dieselbe Crossbar angebunden ist, wird die Ausführungsgeschwindigkeit des CoreMarks halbiert, wie die Messreihe Program RAM 1 aufzeigt. Wird stattdessen auf den lokalen RAM eines Kerns zugegriffen, welcher über eine andere Crossbar angebunden ist, sinkt die Leistung auf 39% der Ursprungsleistung.

Die große Neuerung der zweiten AURIX-Generation stellt die kerneigene Local Memory Unit dar. Diese war bei den bisherigen Derivaten der ersten AURIX-Familie nicht vorhanden und verhält sich anders als der Program RAM. Bei der Ausführungsgeschwindigkeit spielt es keine Rolle, ob die kerneigene oder eine Local Memory Unit eines anderen Prozessorkerns verwendet wird, die Performance ist in beiden Fällen identisch. Das genutzte Derivat von dem TC397 besitzt auf Grund des frühen Entwicklungsstadiums noch keine Local Memory Units an der zweiten Crossbar.

Speicherverwaltung

Program Memory Unit - Prefetch Buffer
Wie bereits in der Vorbetrachtung beschrieben, nutzten die Infineon AURIX-Derivate einen Prefetch Buffer innerhalb der Program Memory Unit für die Beschleunigung von Zugriffen auf den Program Flash. Durch ungünstige Allokierung von Programmcode kann die Funktionsweise dieses Buffers deutlich behindert werden. Auf Grund von Einschränkungen des CoreMark hinsichtlich der Funktionssprünge werden 16 Funktionen erstellt, welche lediglich Sprünge in die jeweils nächste Funktion enthalten. Durch Deaktivierung der Optimierungsstufen des Compilers werden diese Funktionen ausgeführt. Diese 16 Funktionen werden in einer Schleife 10 Millionen Mal aufgerufen.

In der ersten Versuchsreihe werden die 16 Funktionen hintereinander in dem Program Flash 0 allokiert, um die Funktion des Prefetch Buffers maximal zu unterstützen. In der zweiten Messreihe werden die Funktionen in dem Flash Speicher 0 so ungünstig positioniert, dass der Prefetch Buffer seinen Inhalt permanent verwerfen und die geforderten Informationen neu laden muss. Um konkurrierende Zugriffe auf den Prefetch Buffer zu verhindern, welche die Ergebnisse verfälschen würden, wird lediglich Prozessorkern 0 aktiviert.

Wie in der Abbildung 14 zu sehen ist, sinkt die Bearbeitungszeit bei optimaler Positionierung in dem Program Flash 0 auf 44% der Zeit im Vergleich zur suboptimalen Verteilung. Aus diesem Grund sollten Funktionen, welche sequentiell bearbeitet werden, hintereinander in dem Speicher allokiert werden, um die maximale Ausführungsgeschwindigkeit zu erreichen. Des Weiteren zeigt diese Messung, welche Auswirkungen konkurrierende Zugriffe mehrerer Prozessorkerne auf denselben Flash Speicher haben können. Durch wird der Prefetch Buffer zu einem permanenten Umladen gezwungen.

Program Memory Interface - Program Cache

Für die Untersuchung des Program Caches wird derselbe Softwarestand wie bei der Untersuchung des Prefetch Buffers in der Program Memory Unit verwendet. Die dabei ermittelten Resultate können der Abbildung 15 entnommen werden.

Bei häufigen Sprüngen innerhalb des Speichers wird die Funktionalität des Cache fast komplett aufgehoben. Durch den Zwei-Wege-Assoziativen Aufbau können einzelne adressweite Sprünge in Subroutinen zwar kompensiert werden, jedoch muss bei einem dritten Sprung bereits die erste Cache Page nachgeladen werden. Infineon hat zwar diverse Optimierungen vorgenommen, um die Auswirkungen der Cache Misses möglichst gering zu halten, jedoch können diese in der gezeigten Extremsituation nur bedingt helfen. Daher gilt bei Nutzung des Program Caches die Allokierung des Programmcodes in den globalen Speichern möglichst nach sequentieller Abarbeitung zu separieren und asynchrone Zugriffe zu vermeiden oder diese ungecacht auszuführen [16][7]. Abschließend muss darauf hingewiesen werden, dass durch Optimierung des Speicherlayouts zur optimalen Program Cache Performance die Leistung des Prefetch Buffers ebenfalls steigt.

Diskussion

Wie die ermittelten Resultate am Beispiel der AURIX-Mikrocontrollerfamilie aufzeigen, ist der Einfluss des Speichermanagements auf die Gesamtperformance eines Multicore-Mikrocontrollers signifikant. Dabei ist zu beachten, dass die hier ermittelten Messwerte, bedingt durch den synchronen Zugriff auf die vorhandenen Speicher, eine Extremsituation darstellen, welche vorhandene Engpässe aufzeigt. Durch eine optimale Verteilung des Programmcodes auf die vorhandenen Speicher kann die Leistung um den Faktor 3.7 bei der ersten AURIX-Generation und um den Faktor 8.9 bei der zweiten Generation gesteigert werden.

Dies zeigt, dass sich der Einfluss des Speichermanagements bei zunehmender Kernanzahl verstärkt. Hierbei eröffnen sich die Stärken der zweiten AURIX-Generation. Durch die konsequente Aufteilung der vorhandenen Speicher auf die Prozessorkerne können konkurrierende Zugriffe minimiert und damit die Vorhersagbarkeit gesteigert werden. Durch die gesteigerte Vorhersagbarkeit kann die WCET (Worst Case Execution Time) besser abgeschätzt werden und dadurch die Auslastung des Gesamtsystems realistischer beurteilt werden.

Anhand der Messungen wird deutlich, dass die AURIX-Architektur auf die Nutzung der lokalen Speicher für eine optimale Auslastung angewiesen ist. Werden diese nicht verwendet, verringert sich die Leistungsfähigkeit der einzelnen Kerne massiv. Dabei ist zu beachten, dass der Performance-Kern in dem Infineon AURIX TC277 prozentual stärker Rechengeschwindigkeit verliert als der Efficiency-Kern bei Verzicht auf die lokalen Speicher. Für die optimale Auslastung der Recheneinheiten des Infineon AURIX sollten daher Funktionen, welche in einem schnellen Zeitraster gerechnet wer-den, in die lokalen Speicher des ausführenden Prozessorkerns allokiert werden.

Wenn die lokalen Speicher für den auszuführenden Programmcode nicht ausreichen, sollte der weitere Programmcode so auf die globalen Speicher verteilt werden, dass konkurrierende Zugriffe minimiert werden. Dies erhöht nicht nur die Ausführungsgeschwindigkeit sondern verbessert die Vorhersagbarkeit. In dem hier gezeigten Szenario traten die konkurrierenden Zugriffe permanent auf. In der Seriensoftware eines Steuergeräts ist dies nicht zwingend der Fall. Hier können sich solch konkurrierende Zugriffe erst nach einer längeren Laufzeit oder durch ungünstige Eingangsgrößen ergeben. Das Ermitteln solcher Szenarien ist dabei aufwendig und kann durch eine optimale Separierung des Programmcodes auf die vorhandenen Speicher minimiert werden [13].

Des Weiteren hat sich gezeigt, dass die vorhandenen Techniken zur Beschleunigung von Speicherzugriffen, wie der Prefetch Buffer und der Program Cache, zwingend einen sequentiellen Programmablauf für eine optimale Leistungsentfaltung benötigen. Um dies zu gewährleisten, sollten Funktionen, welche häufig im Rahmen eines Kontextes gerechnet werden, so in den Program Flash allokiert werden, dass diese die Funktionalität dieser Speicher unterstützen. Dies erfordert, dass konkurrierende Zugriffe auf den Program Flash vermieden werden, da diese ebenfalls ein Umladen des Prefetch Buffers erzwingen können.

Abschließend ergibt sich, dass die maximale Ausführungsgeschwindigkeit nur dann erreicht werden kann, wenn die Funktionalität des vorhandenen Speichermanagements optimal genutzt wird [16][17].

Als Fortsetzung dieser Arbeit soll in den folgenden Untersuchungen die Vorhersagbarkeit durch den Einsatz des LET-Paradigmas weiter erhöht werden [10][12]. Dabei ist das Ziel, besonders zeitkritische oder häufig genutzte Funktionen in die lokalen Speicher des jeweiligen Prozessorkerns zu allokieren und den Zugriff auf die globalen Speicher über feste Zeitschlitze zu definieren. Betriebssysteme auf dieser Basis haben das Potential dieses Ansatzes bei ARM-basierten Prozessoren bereits unter Beweis gestellt [11].

Literatur- und Quellenverzeichnis

[1] Abbi Ashok and Jens Harnisch. 2017. AURIX - Programming close to hard-ware for best performance. In Embedded Multi-Core Conference. Infineon Technologies AG, 81726 Munich, Germany.

[2] Infineon Technologies AG 2014. AURIX TC27x C-Step User’s Manual V2.2. Infineon Technologies AG, 81726 Munich, Germany.

[3] Infineon Technologies AG 2014. AURIX TC29x B-Step User’s Manual V1.3. Infineon Technologies AG, 81726 Munich, Germany.

[4] Infineon Technologies AG 2016. AURIX TC3xx Target Specification V2.0.1. Infineon Technologies AG, 81726 Munich, Germany.

[5] Thomas Barth and Peter Fromm. 2016. Warp 3 zwischen allen Kernen - Ent-wicklung einer schnellen und sicheren Multicore-RTE. In Tagungsband Em-bedded Software Engineering Kongress 2016.

[6] Günther Bengel, Christian Baun, Marcel Kunze, and Karl-Uwe Stucky. 2015. Masterkurs Parallele und Verteilte Systeme. Springer Fachmedien Wiesbaden. https://doi.org/10.1007/978-3-8348-2151-5

[7] Marco Caccamo, Marco Cesati, Rodolfo Pellizzoni, Emiliano Betti, Roman Dudko, and Renato Mancuso. 2013. Real-time Cache Management Framework for Multicore Architectures. In Proceedings of the 2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS) (RTAS ’13). IEEE Computer Society, Washington, DC, USA, 45–54. https://doi.org/10.1109/RTAS.2013.6531078

[8] Hartmut Ernst, Jochen Schmidt, and Gerd Beneken. 2016. Grundkurs Informa-tik. Springer Fachmedien Wiesbaden. https://doi.org/10.1007/978-3-658-14634-4

[9] J. Henkel, L. Bauer, J. Becker, O. Bringmann, U. Brinkschulte, S. Chakraborty, M. Engel, R. Ernst, H. Härtig, L. Hedrich, A. Herkersdorf, R. Kapitza, D. Loh-mann, P. Marwedel, M. Platzner, W. Rosenstiel, U. Schlichtmann, O. Spinczyk, M. Tahoori, J. Teich, N. When, and H. J. Wunderlich. 2011. Design and architectures for dependable embedded systems. In 2011 Proceedings of the Ninth IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS). 69–78. https://doi.org/10.1145/2039370.2039384

[10] Christoph M Kirsch and Ana Sokolova. 2012. The Logical Execution Time Paradigm. In Advances in Real-Time Systems. Springer, 103–120.

[11] Florian Kluge, Mike Gerdes, and Theo Ungerer. 2014. An Operating System for Safety-Critical Applications on Manycore Processors. 2014 IEEE 17th In-ternational Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing (2014), 238–245.

[12] Florian Kluge, Martin Schoeberl, and Theo Ungerer. 2016. Support for the Lo-gical Execution Time Model on a Time-predictable Multicore Processor. SIG-BED Rev. 13, 4 (Nov. 2016), 61–66. https://doi.org/10.1145/3015037.3015047

[13] Edward A. Lee. 2008. Cyber Physical Systems: Design Challenges. Technical Report UCB/EECS-2008-8. EECS Department, University of California, Ber-keley. http://www2.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-8.html

[14] Infineon Technologies AG 2015. TriCore TC1.6.2 Core Architecture. Infineon Technologies AG, 81726 Munich, Germany.

[15] Infineon Technologies AG 2012. TriCore TC1.6P & TC1.6E Core Architec-ture. Infineon Technologies AG, 81726 Munich, Germany.

[16] Philipp Jungklass and Mladen Berekovic. 2018. Effects of concurrent access to embedded multicore microcontrollers with hard real-time demands. 13th Inter-national Symposium on Industrial Embedded Systems (2018).

[17] Philipp Jungklass and Mladen Berekovic. 2018. Performance-Oriented Me-mory Management for Embedded Multicore Microcontrollers. In 26th EURO-MICRO International Conference on Parallel, Distributed and Network-Based Processing.

[18] Gang Yao, Rodolfo Pellizzoni, Stanley Bak, Emiliano Betti, and Marco Cac-camo. 2012. Memory-centric Scheduling for Multicore Hard Real-time Sys-tems. Real- Time Syst. 48, 6 (Nov. 2012), 681–715. https://doi.org/10.1007/s11241-012-9158-9

(Der Beitrag wurde mit freundlicher Genehmigung der Autoren dem Embedded Software Engineering Kongress Tagungsband 2018 entnommen.)

Software-Parallelisierung für Multicore-Prozessoren, Teil 1: Race Conditions

Multicore-Determinismus für sicherheitskritische Anwendungen

Der Autor

* M.Sc. Philipp Jungklass studierte an der Hochschule Stralsund Informatik und arbeitet seit vielen Jahren als Entwicklungsingenieur im automobilen Sektor. Seine berufliche Tätigkeit begann mit der Treiberprogrammierung für Kommunikationssysteme im Fahrzeug. Aktuell beschäftigt er sich mit Multicore-Mikrocontrollern in sicherheitskritischen Anwendungen und ist für die ausbildungsrelevante Betreuung zuständig.

* Prof. Dr.-Ing. Mladen Berekovic ist Institutsdirektor für Technische Infomatik an der Universität Lübeck

(ID:46401209)