Autoren: Philipp Jungkla\u00df, Ingenieurgesellschaft Auto und Verkehr GmbH,
\nProf. Dr.-Ing. Mladen Berekovic, Universit\u00e4t zu L\u00fcbeck, Institut f\u00fcr Technische Informatik<\/p>\n
Der Einsatz von embedded Multicore-Mikrocontrollern in modernen Steuerger\u00e4ten mit harter Echtzeitanforderung stellt Entwickler immer wieder vor gr\u00f6\u00dfere Herausforderungen, da die Separierung der Software h\u00e4ufig nicht in dem Ma\u00dfe m\u00f6glich ist, wie es die Anzahl der Prozessorkerne vorgibt. Dadurch ist es notwendig, dass zwischen den Prozessorkernen ein Datenaustausch stattfindet. Diese Intercore-Kommunikation erfolgt derzeit \u00fcber geteilte Speicher, auf welche die Prozessorkerne konkurrierend zugreifen. Bedingt durch diese parallelen Zugriffe entstehen Wartezyklen, welche f\u00fcr ein System mit harter Echtzeitanforderung aufwendig zu kalkulieren sind. Aus diesem Grund wird in diesem Artikel ein priorit\u00e4tsbasiertes Verfahren zur Intercore-Kommunikation vorgestellt, dass die Wartezyklen durch eine effektive Nutzung der vorhandenen Speicherhierarchie minimieren. Als Nachweis der Funktionsf\u00e4higkeit wird das Verfahren auf zwei embedded Multicore-Mikrocontroller der AURIX-Familie portiert und mit dem bisherigen Ansatz verglichen.<\/strong><\/p>\n Seit der Einf\u00fchrung der ersten Steuerger\u00e4te mit embedded Multicore-Mikrocontroller ist die Anzahl der verf\u00fcgbaren Prozessorkerne stetig gestiegen. Diese Entwicklung stellt besondere Anforderungen an die Software der Steuerger\u00e4te, welche auf die vorhandenen Prozessorkerne aufgeteilt werden muss. Dabei ist jedoch zu beachten, dass zwischen den Software-Komponenten auf den unterschiedlichen Kernen Abh\u00e4ngigkeiten bestehen, welche einen kern\u00fcbergreifenden Datenaustausch erfordern. Aktuell erfolgt der Datenaustausch zwischen den Prozessorkernen \u00fcber einen geteilten globalen Speicher, auf welchen die Kerne konkurrierend zugreifen. Die dadurch entstehenden Wartezeiten sind schwer vorhersagbar und k\u00f6nnen die Echtzeitf\u00e4higkeit des Systems gef\u00e4hrden. Daher wird in diesem Artikel ein Verfahren vorgestellt werden, welches durch eine intelligente Nutzung der vorhandenen Speicherhierarchie des embedded Multicore-Mikrocontrollers die Anzahl der Wartezyklen minimiert, wodurch die Vorhersagbarkeit erh\u00f6ht wird [10][11].<\/p>\n Der Aufbau dieses Artikels gliedert sich in sechs Bereiche. Nach der Einf\u00fchrung wird der aktuelle Stand der Technik pr\u00e4sentiert. Im Anschluss wird das entwickelte Konzept vorgestellt und detailliert beschrieben. Als n\u00e4chstes wird der genutzte Versuchsaufbau erl\u00e4utert, bevor im Anschluss die ermittelten Resultate der zwei Testplattformen pr\u00e4sentiert werden. Den Abschluss dieses Artikels bildet die Diskussion der erreichten Resultate.<\/p>\n Grundlegend besitzen die derzeit verf\u00fcgbaren Multicore-Mikrocontroller der verschiedenen Hersteller einen \u00e4hnlichen Aufbau. Dazu geh\u00f6rt, je nach Prozessorfamilie und Derivat, eine unterschiedliche Anzahl an Prozessorkernen, welche mittels einer Crossbar mit den globalen Speichern des Systems sowie untereinander verbunden sind. Der Vorteil einer Crossbar liegt in der Realisierung von parallelen Verbindungen zwischen verschiedenen Teilnehmern. Zus\u00e4tzlich bieten die Kerne jeweils einen lokalen Speicher, auf welchen diese ohne Wartezyklen direkt zugreifen k\u00f6nnen. Abbildung 1 (s.\u00a0PDF<\/a>) zeigt den schematischen Aufbau [1][2][3][7].<\/p>\n In modernen Steuerger\u00e4ten mit embedded Multicore-Mikrocontrollern erfolgt der Datenaustausch zwischen den Prozessorkernen \u00fcber einen globalen Speicher, auf welchen alle Kommunikationsteilnehmer Zugriff haben. Zur Vermeidung von inkonsistenten Daten, welche bei konkurrierenden Zugriffen mehrerer Kommunikationsteilnehmer entstehen k\u00f6nnen, werden drei grundlegende Mechanismen zur Absicherung genutzt [5][6].<\/p>\n Ein Mutex ist ein Verfahren, welches f\u00fcr einen wechselseitigen Ausschluss von verschiedenen Kommunikationspartnern genutzt wird. Wichtig ist hierbei, dass nur der Partner, welcher den exklusiven Zugriff auf die geteilten Ressourcen reserviert hat, diese auch wieder freigeben kann [6].<\/p>\n Mittels einer Semaphore wird ebenfalls der exklusive Zugriff auf geteilte Ressourcen geregelt. Im Gegensatz zu einem Mutex muss jedoch nicht zwingend der reservierende Kommunikationspartner auch der Freigebende sein [6].<\/p>\n Der Begriff Spinlock beschreibt gleicherma\u00dfen ein Verfahren, welches den exklusiven Zugriff auf eine geteilte Ressource regelt. Im Gegensatz zu einem Mutex oder einer Semaphore warten die Kommunikationspartner jedoch aktiv, falls die ben\u00f6tigte Ressource derzeit nicht exklusiv verf\u00fcgbar ist [6].<\/p>\n Alle drei Verfahren zur Regelung des Zugriffs auf geteilte Speicher w\u00fcrden von einer beschleunigten Intercore-Kommunikation profitieren. Dies ist darauf zur\u00fcckzuf\u00fchren, dass bei jedem exklusiven Zugriff ein kritischer Abschnitt im Programmcode des Steuerger\u00e4ts ausgef\u00fchrt wird, welcher nicht unterbrochen werden darf. Je l\u00e4nger solch ein Abschnitt dauert, desto schwieriger ist die Aufrechterhaltung der harten Echtzeitf\u00e4higkeit.<\/p>\n Wie bereits in Abschnitt 2 beschrieben, erfolgt der Zugriff der Prozessorkerne auf ihre lokalen Speicher deutlich schneller als auf die globalen Speicher, welche mittels einer Crossbar angebunden sind. Daher wird in dem hier vorgestellten Konzept die Intercore-Kommunikation mittels der lokalen Speicher realisiert. Hierbei ist zu beachten, dass der Zugriff eines Kerns auf den lokalen Speicher eines anderen Kerns deutlich langsamer als der Zugriff auf den eigenen lokalen Speicher erfolgt, jedoch immer noch schneller als auf den globalen Speicher. Im Gegensatz zu dem bisher genutzten Verfahren wird in dem hier vorgestellten Konzept die Priorit\u00e4t der Prozessorkerne in einem Steuerger\u00e4t ber\u00fccksichtigt. Die Vergabe der Priorit\u00e4t kann dabei anhand der zugewiesenen Aufgabe, zum Beispiel dem Sicherheitslevel, oder der Auslastung erfolgen.<\/p>\n Zur besseren Beschreibung des Konzepts wird das Beispiel in der Abbildung 2\u00a0(s.\u00a0PDF<\/a>) genutzt. In diesem System existieren drei Prozessorkerne, welche jeweils \u00fcber einen lokalen Speicher verf\u00fcgen und \u00fcber eine Crossbar mit den globalen Speichern und untereinander verbunden sind. Jeder der drei Kerne besitzt eine separate Priorit\u00e4t. Zur Darstellung der Intercore-Kommunikation in den sich anschlie\u00dfenden Beispielen wird die Farbe Rot f\u00fcr einen Schreibzugriff und Gr\u00fcn f\u00fcr einen Lesezugriff verwendet. Mit der Farbe Gelb wird eine Operation eines Kerns mit seinem lokalen Speicher aufgezeigt, welche nicht Teil einer Intercore-Kommunikation ist<\/p>\n In dem ersten Szenario, welches in Abbildung 3 (s.\u00a0PDF<\/a>) dargestellt ist, stellt Core 0 Informationen bereit, welche Core 1 und Core 2 ben\u00f6tigen. Da Core 0 die niedrigste Priorit\u00e4t in diesem System besitzt, schreibt er die Daten in die lokalen Speicher von Core 1 und Core 2. Dadurch k\u00f6nnen diese bei einem lesenden Zugriff auf die Daten deutlich schneller zugreifen, wodurch Wartezyklen bei den h\u00f6her priorisierten Kernen vermieden werden.<\/p>\n Bei dem zweiten Anwendungsfall in Abbildung 4 (s.\u00a0PDF<\/a>) stellt Core 1 Daten f\u00fcr die anderen beiden Kerne zur Verf\u00fcgung. Da Core 1 die h\u00f6chste Priorit\u00e4t in dem hier gezeigten System besitzt, schreibt dieser seine Werte in seinen eigenen lokalen Speicher. Durch diese Konfiguration ben\u00f6tigen Core 0 und Core 2 zwar mehr Zeit bei dem lesenden Zugriff, jedoch kann Core 1 entlastet werden.<\/p>\n In dem dritten Szenario, welches in Abbildung 5 (s.\u00a0PDF<\/a>) vorgestellt wird, werden Daten von Core 2 berechnet, welche Core 0 und Core 1 f\u00fcr die weitere Verarbeitung ben\u00f6tigen. Auf Grund der Tatsache, dass Core 2 die mittlere Priorit\u00e4t in diesem System besitzt, werden die Werte f\u00fcr Core 1 direkt in dessen Speicher geschrieben, da dieser eine h\u00f6here Priorit\u00e4t besitzt. Die Werte f\u00fcr Core 0 legt Core 2 in seinem eigenen lokalen Speicher ab. Durch diese Verteilung ben\u00f6tigt Core 0 zwar mehr Zeit f\u00fcr den lesenden Zugriff, jedoch wird Core 1 durch den schnelleren Zugriff auf seinen eigenen Speicher entlastet.<\/p>\n Wie in den aufgezeigten Anwendungsf\u00e4llen in Abbildung 3 bis 5 zu sehen ist, nutzen die Prozessorkerne ihre lokalen Speicher sowohl zur Intercore-Kommunikation als auch f\u00fcr Berechnungen, welche exklusiv auf einem Kern durchgef\u00fchrt werden. Durch diesen Umstand entsteht ein konkurrierender Zugriff, wodurch Wartezyklen entstehen, welche die Echtzeitf\u00e4higkeit beeinflussen k\u00f6nnen. Aus diesem Grund haben einige Prozessorhersteller begonnen, zwei lokale Speicher pro Kern zu integrieren, wodurch die Intercore-Kommunikation \u00fcber einen separaten Speicher erfolgen kann. Die Abbildung 6 (s.\u00a0PDF<\/a>) zeigt die schematische Darstellung der erweiterten Speicherhierarchie [4].<\/p>\n In dem folgenden Szenario, welches in Abbildung 7 (s.\u00a0PDF<\/a>) dargestellt wird, stellt Core 0 Werte zur Verf\u00fcgung, welche von Core 1 und Core 2 ben\u00f6tigt werden. Auch in dieser Konfiguration besitzt Core 0 die niedrigste Priorit\u00e4t und schreibt daher seine Werte in die Speicher von Core 1 und Core 2. Der Unterschied zu dem ersten Anwendungsfall besteht darin, dass die lokalen Speicher X-0 exklusiv von den Prozessorkernen und die Speicher X-1 f\u00fcr die Intercore-Kommunikation genutzt werden. Dadurch k\u00f6nnen konkurrierende Zugriffe bei der Bearbeitung der exklusiven Aufgaben effektiv verhindert werden.<\/p>\n Da Core 1 in dem Beispiel die h\u00f6chste Priorit\u00e4t besitzt, schreibt dieser seine Werte f\u00fcr Core 0 und Core 2 in den lokalen Speicher 1-1. Dies erh\u00f6ht zwar die Dauer des Lesezugriffs f\u00fcr Core 0 und Core 2, reduziert jedoch die Dauer des Schreibvorgangs f\u00fcr Core 1. Bedingt durch die zwei vorhandenen Speicher erfolgt auch hier eine Aufteilung f\u00fcr exklusive Berechnungen und Intercore-Kommunikation zur Reduzierung von konkurrierenden Zugriffen. Siehe Abbildung 8 (s.\u00a0PDF<\/a>).<\/p>\n In dem n\u00e4chsten Szenario aus Abbildung 9 (s.\u00a0PDF<\/a>) werden die Daten von Core 2 bereitgestellt. Da Core 2 die mittlere Priorit\u00e4t in diesem System besitzt, schreibt dieser die Werte f\u00fcr Core 1 in dessen lokalen Speicher auf Grund der h\u00f6heren Priorit\u00e4t. Die Werte f\u00fcr Core 0 schreibt Core 2 in seinen eigenen lokalen Speicher. Bedingt durch die erweiterte Speicherhierarchie kann auch hier eine Aufteilung der Speicher in exklusive und geteilte Variablen erfolgen, wodurch konkurrierende Zugriffe bedingt durch die Intercore-Kommunikation verringert werden k\u00f6nnen.<\/p>\n Eine Erweiterung dieses Systems kann durch den DMA-Controller erfolgen, welcher in den meisten modernen embedded Multicore-Mikrocontrollern integriert ist. Dadurch kann jeder Prozessorkern seinen eigenen lokalen Speicher nutzen und der DMA-Controller \u00fcbernimmt den Kopiervorgang in den lokalen Speicher eines anderen Kerns. Abbildung 10\u00a0(s.\u00a0PDF<\/a>)\u00a0 verdeutlicht die Separierung, wobei hier nur die Speicherbereiche f\u00fcr die Intercore-Kommunikation dargestellt sind.<\/p>\n In dem folgenden Anwendungsbeispiel stellt Core 1 Daten f\u00fcr Core 2 bereit. Core 1 schreibt die aktualisierten Werte in seinen lokalen Speicher mit der maximalen Geschwindigkeit. In Anschluss wird der DMA-Controller aktiviert, welcher die neuen Daten in den lokalen Speicher von Core 2 schreibt. Durch die Nutzung des DMA-Controllers kann auch Core 2 mit voller Geschwindigkeit auf seinen eigenen lokalen Speicher zugreifen. Siehe Abb. 11 (s.\u00a0PDF<\/a>).<\/p>\n Auch bei diesem Ansatz bieten sich embedded Multicore-Mikrocontroller mit zwei lokalen Speichern pro Prozessorkern an, da sonst auch in diesem Fall ein konkurrierender Zugriff durch den DMA-Controller und dem jeweiligen Prozessorkern bei einer Operation auf den lokalen Speicher erfolgen kann.<\/p>\n Die \u00dcberpr\u00fcfung des in diesem Artikel vorgestellten Konzepts erfolgt mit zwei Evaluierungsboards der Firma hitex. Eines nutzt den Infineon AURIX TC277 der ersten Generation und das andere ist mit dem AURIX TC397 der zweiten Generation best\u00fcckt. F\u00fcr das Flashen und Debuggen sowie zum Auslesen der Messwerte wird ein Debugger der Firma Lauterbach genutzt. Die genaue Bezeichnung aller Versuchswerkzeuge kann der Tabelle 1 entnommen werden.<\/p>\n Tabelle 1: Versuchswerkzeuge<\/em><\/p>\n In der folgenden Tabelle 2 wird die genutzte Software mit den dazugeh\u00f6rigen Versionsnummern sowie die Verwendung detailliert aufgeschl\u00fcsselt. Tabelle 2: Verwendete Versuchssoftware<\/em><\/p>\n Zur Validierung des oben beschriebenen Konzeptes wird in jeder Messung ein 4KB gro\u00dfes Array mit 32-Bit Werten zwischen den Prozessorkernen ausgetauscht. Die Zeitmessung erfolgt mit dem internen Performance-Countern der Prozessorkerne, welche taktgenau die ben\u00f6tigte Zeit sowie die ausgef\u00fchrten Instruktionen ermitteln. Weiterhin, zur gezielten Provokation von konkurrierenden Zugriffen, werden die Kopiervorg\u00e4nge synchron mittels eines Broadcast-Interrupts ausgel\u00f6st.<\/p>\n Um das Konzept zu \u00fcberpr\u00fcfen, wurde das Verfahren auf einen embedded Multicore-Mikrocontroller der ersten AURIX-Generation portiert. Das Derivat vom Typ TC277 nutzt drei Prozessorkerne, welche jeweils einen lokalen Speicher f\u00fcr besonders schnelle Zugriffe zur Verf\u00fcgung stellen. Zus\u00e4tzlich ist in dem TC277 ein globaler RAM Speicher integriert, auf welchen alle Kerne mit derselben Geschwindigkeit zugreifen k\u00f6nnen [13].<\/p>\n In der ersten Messreihe wird untersucht, inwieweit sich die Speichernutzung auf die Kopierdauer auswirkt. Dazu kopiert Core 1 in jeder Messung ein 4KB gro\u00dfes Array wechselseitig zwischen den unterschiedlichen Speichern des TC277. Um in dieser Messreihe konkurrierende Zugriff zu vermeiden, sind Core 0, Core 2 und der DMA-Controller deaktiviert.<\/p>\n Tabelle 3: Speicherperformance bei einem Kopiervorgang, Core 1 aktiv<\/em> F\u00fcr die zweite Messreihe wird ein konkurrierender Zugriff auf den lokalen Speicher von Core 1 simuliert. Zu diesem Zweck kopieren Core 0 und Core 2 ein 4KB gro\u00dfes Array aus dem lokalen Speicher von Core 1 in ihren eigenen. Diese Konfiguration entspricht dem Szenario aus Abbildung 8.<\/p>\n Tabelle 4: Speicherperformance Core 1 bei konkurrierendem Zugriff durch Core 0 \/ 2<\/em> In der dritten Messreihe, welche in der Tabelle 5 zu sehen ist und der Abbildung 11 entspricht, wird der DMA-Controller zur Intercore-Kommunikation genutzt. Hierbei zeigt sich ebenfalls, dass der Zugriff auf die globalen Speicher langsamer ist, jedoch ist die Differenz zu den lokalen Speichern deutlich geringer im Vergleich zur Verwendung der Prozessorkerne. Die Anzahl der Instruktionen ergeben sich aus dem Aktivieren des DMA-Transfers durch Core 1.<\/p>\n Tabelle 5: Speicherperformance DMA-Controller<\/em><\/p>\n Mit der zweiten Generation der AURIX Mikrocontrollerfamilie hat Infineon die Anzahl der Prozessorkerne sowie die Speicherhierarchie im Vergleich zur ersten Generation deutlich \u00fcberarbeitet. Dazu geh\u00f6rt, dass die maximale Anzahl an Prozessorkernen auf sechs verdoppelt wurde und das jedem Core jetzt zwei lokale Speicher zur Verf\u00fcgung stehen, wodurch konkurrierende Zugriffe bei der Intercore-Kommunikation minimiert werden k\u00f6nnen. F\u00fcr die Messung in diesem Artikel wird der Infineon AURIX TC397 genutzt, welcher sechs Kerne mit jeweils zwei lokalen Speichern bietet. Zus\u00e4tzlich hat Infineon die Anzahl der globalen RAM-Speicher insgesamt auf vier erh\u00f6ht. Da diese globalen Speicher jedoch eine untergeordnete Rolle in dem hier vorgestellten Konzept einnehmen, dienen diese lediglich als Referenz [12].<\/p>\n Die Messreihe in Tabelle 6 zeigt, dass der Zugriff auf den lokalen Speicher 1-0 identisch zur ersten AURIX-Generation ist. Auch der Zugriff auf den zweiten lokalen Speicher 1-1 verh\u00e4lt sich \u00e4quivalent zu den Messungen f\u00fcr den lokalen Speicher 1-0. Eine Ausnahme stellt ausschlie\u00dflich der Kopiervorgang dar, bei welchem sowohl die Quelle als auch das Ziel der lokale Speicher 1-1 ist. Dieser Speicher scheint lediglich eine Anbindung an den Core 1 zu besitzen, wodurch parallele Zugriffe deutlich ausgebremst werden. Beim Vergleich von Tabelle 3 und Tabelle 6 ist zu erkennen, dass der Kopiervorgang beim AURIX 2G in Bezug auf die globalen Speicher weniger Ticks ben\u00f6tigt. Die Erkl\u00e4rung steckt in der Verbesserung der Anbindung der globalen Speicher durch Infineon. Bei der zweiten AURIX Generation entspricht die Zugriffsgeschwindigkeit eines Kerns auf die globalen Speicher somit der Operationsgeschwindigkeit des Zugriffs auf die lokalen Speicher der anderen Kerne.<\/p>\n Tabelle 6: Speicherperformance Core 1<\/em><\/p>\n Seit der Einf\u00fchrung der ersten embedded Multicore-Mikrocontroller f\u00fcr Steuerger\u00e4te mit harter Echtzeitanforderung wurde eine Leistungssteigerung haupts\u00e4chlich \u00fcber die Erh\u00f6hung der vorhandenen Prozessorkerne realisiert. Leider k\u00f6nnen die bestehenden Algorithmen h\u00e4ufig nicht so separiert werden, dass diese v\u00f6llig autark auf verschiedenen Prozessorkernen gerechnet werden. Aus diesem Grund wird Intercore-Kommunikation in den n\u00e4chsten Jahren und bei steigender Anzahl von Prozessorkernen zunehmend zur Herausforderung werden. Dabei stellt sowohl die Zugriffsgeschwindigkeit auf die geteilten Speicher als auch die Effekte der konkurrierenden Zugriffe ein Problem dar.<\/p>\n Das in diesem Artikel pr\u00e4sentierte Konzept zur effektiven Nutzung der vorhandenen Speicherhierarchie stellt dabei einen ersten Schritt dar. Durch die Priorisierung der Prozessorkerne k\u00f6nnen die Wartezyklen bei der Intercore-Kommunikation so verteilt werden, dass h\u00f6her priorisierte Kerne gezielt entlastet werden. Des Weiteren werden durch die Verteilung der auszutauschenden Daten auf verschiedene Speicher die Effekte von konkurrierenden Zugriffen deutlich verringert.<\/p>\n Die zuk\u00fcnftige Entwicklung sieht vor, dass das Konzept in ein Framework \u00fcberf\u00fchrt wird, welches die Zuordnung der geteilten Daten auf die vorhandenen Speicher automatisch vornimmt. Zu diesem Zweck sollen die Trace-Daten von Steuerger\u00e4ten analysiert und die geteilten Werte sowie die dazugeh\u00f6rigen Kommunikationsteilnehmer selbstst\u00e4ndig extrahiert werden. Des Weiteren wird dem Framework eine allgemeine Beschreibung des embedded Multicore-Mikrocontrollers mit seiner Speicherhierarchie zur Verf\u00fcgung gestellt. Mit diesen Informationen kann dann eine optimale Verteilung errechnet werden. Ein weiteres Ziel ist die Integration des LET-Paradigmas f\u00fcr die jeweiligen Speicher. Dadurch k\u00f6nnen die Effekte von konkurrierenden Zugriffen besser geplant und ihre Auswirkungen auf die Echtzeitf\u00e4higkeit minimiert werden, wodurch die Worst-Case-Execution Time verringert wird [8][9][14][15].<\/p>\n [1]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Abbi Ashok and Jens Harnisch. 2017. AURIX – Programming close to hardware for best performance. In Embedded Multi-Core Conference. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [2]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Infineon Technologies AG 2014. AURIX TC27x C-Step User\u2019s Manual V2.2. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [3]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Infineon Technologies AG 2014. AURIX TC29x B-Step User\u2019s Manual V1.3. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [4]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Infineon Technologies AG 2016. AURIX TC3xx Target Specification V2.0.1. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [5]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Thomas Barth and Peter Fromm. 2016. Warp 3 zwischen allen Kernen – Entwicklung einer schnellen und sicheren Multicore-RTE. In Tagungsband Embedded Software Engineering Kongress 2016.<\/p>\n [6]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 G\u00fcnther 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<\/p>\n [7]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Hartmut Ernst, Jochen Schmidt, and Gerd Beneken. 2016. Grundkurs Informatik. Springer Fachmedien Wiesbaden. https:\/\/doi.org\/10.1007\/978-3-658-14634-4<\/p>\n [8]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Christoph M Kirsch and Ana Sokolova. 2012. The Logical Execution Time Paradigm. In Advances in Real-Time Systems. Springer, 103\u2013120.<\/p>\n [9]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Florian Kluge, Martin Schoeberl, and Theo Ungerer. 2016. Support for the Logical Execution Time Model on a Time-predictable Multicore Processor. SIGBED Rev. 13, 4 (Nov. 2016), 61\u201366. https:\/\/doi.org\/10.1145\/3015037.3015047<\/p>\n [10]\u00a0\u00a0\u00a0\u00a0 Philipp Jungklass and Mladen Berekovic. 2018. Effects of concurrent access to embedded multicore microcontrollers with hard real-time demands. 13th International Symposium on Industrial Embedded Systems (2018).<\/p>\n [11]\u00a0\u00a0\u00a0\u00a0 Philipp Jungklass and Mladen Berekovic. 2018. Performance-Oriented Memory Management for Embedded Multicore Microcontrollers. In 26th EUROMICRO International Conference on Parallel, Distributed and Network-Based Processing.<\/p>\n [12]\u00a0\u00a0\u00a0\u00a0 Infineon Technologies AG 2015. TriCore TC1.6.2 Core Architecture. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [13]\u00a0\u00a0\u00a0\u00a0 Infineon Technologies AG 2012. TriCore TC1.6P & TC1.6E Core Architecture. Infineon Technologies AG, 81726 Munich, Germany.<\/p>\n [14]\u00a0\u00a0\u00a0\u00a0 Florian Kluge, Mike Gerdes, and Theo Ungerer. 2014. An Operating System for Safety-Critical Applications on Manycore Processors. 2014 IEEE 17th International Symposium on Object\/Component\/Service-Oriented Real-Time Distributed Computing (2014), 238\u2013245.<\/p>\n [15]\u00a0\u00a0\u00a0\u00a0 Gang Yao, Rodolfo Pellizzoni, Stanley Bak, Emiliano Betti, and Marco Caccamo. 2012. Memory-centric Scheduling for Multicore Hard Real-time Systems. Real- Time Syst. 48, 6 (Nov. 2012), 681\u2013715. https:\/\/doi.org\/10.1007\/s11241-012-9158-9<\/p>\n M.Sc. Philipp Jungklass studierte an der Hochschule Stralsund Informatik und arbeitet seit vielen Jahren als Entwicklungsingenieur im automobilen Sektor. Seine berufliche T\u00e4tigkeit begann mit der Treiberprogrammierung f\u00fcr Kommunikationssysteme im Fahrzeug. Aktuell besch\u00e4ftigt er sich mit Multicore-Mikrocontrollern in sicherheitskritischen Anwendungen und ist f\u00fcr die ausbildungsrelevante Betreuung zust\u00e4ndig. Zudem berichtet er regelm\u00e4\u00dfig \u00fcber sein Arbeitsfeld bei Symposien im embedded Bereich.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Multicore \/Mikrocontroller.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Multicore \/Mikrocontroller steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n1. Einf\u00fchrung<\/h2>\n
2. Stand der Technik<\/h2>\n
Aufbau der embedded Multicore-Mikrocontroller<\/h3>\n
Intercore-Kommunikation<\/h3>\n
Mutex<\/h3>\n
Semaphore<\/h3>\n
Spinlock<\/strong><\/h3>\n
3. Konzept<\/h2>\n
4. Versuchsaufbau<\/h2>\n
\n\n
\n Mikrocontroller<\/strong><\/td>\n Evaluierungsboard<\/strong><\/td>\n Taktfrequenz<\/strong><\/td>\n<\/tr>\n \n SAK-TC277TF-64F200S CA ES<\/td>\n TriBoard TC2X7 V1.0<\/td>\n 200 MHz<\/td>\n<\/tr>\n \n SAK-TC397XE-256F300S AA EES<\/td>\n TriBoard TC3X7 TH V1.0<\/td>\n 300 MHz<\/td>\n<\/tr>\n \n Bezeichnung<\/strong><\/td>\n Verwendung<\/strong><\/td>\n<\/tr>\n \n Lauterbach Power Debug Interface \/ USB3; TRACE32 R2016<\/td>\n Flash-Adapter, Debugger<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n<\/em><\/p>\n\n\n
\n Bezeichnung<\/strong><\/td>\n Verwendung<\/strong><\/td>\n<\/tr>\n \n TASKING VX-toolset for TriCore v6r2<\/td>\n Compiler, Linker<\/td>\n<\/tr>\n \n Infineon Software Framework<\/td>\n Entwicklungs-Framework<\/td>\n<\/tr>\n \n Infineon Low Level Driver 1.0.0.12.0<\/td>\n Mikrocontrollertreiber<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 5. Resultate<\/h2>\n
Infineon AURIX TC277<\/h3>\n
\n\n
\n Quelle:<\/strong><\/td>\n Ziel:<\/strong><\/td>\n Ticks:<\/strong><\/td>\n Instruktionen:<\/strong><\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 1<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Globaler Speicher<\/td>\n 12281<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Lokaler Speicher 1<\/td>\n 11287<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Globaler Speicher<\/td>\n 22529<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 2<\/td>\n 8197<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 1<\/td>\n 719<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 2<\/td>\n 14345<\/td>\n 3082<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nTabelle 3 zeigt, dass der Zugriff von Core 1 auf seinen eigenen lokalen Speicher deutlich schneller ist als der Zugriff auf die globalen Speicher. Des Weiteren zeigt die Messung, dass der Zugriff auf die lokalen Speicher eines anderen Prozessorkerns ebenfalls deutlich schneller ist als eine Operation auf dem globalen Speicher. Die Anzahl der ben\u00f6tigten Instruktionen ist unabh\u00e4ngig von Quelle und Ziel des Kopiervorgangs. Die Dauer h\u00e4ngt von dem Speicher selbst und dessen Anbindung an den Prozessorkern ab.<\/p>\n\n\n
\n Quelle:<\/strong><\/td>\n Ziel:<\/strong><\/td>\n Ticks:<\/strong><\/td>\n Instruktionen:<\/strong><\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 1<\/td>\n 4121<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Globaler Speicher<\/td>\n 12283<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Lokaler Speicher 1<\/td>\n 11288<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Globaler Speicher<\/td>\n 22530<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 2<\/td>\n 8199<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 1<\/td>\n 7197<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 2<\/td>\n 14353<\/td>\n 3082<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nWie in der Messreihe in Tabelle 4 zu sehen ist, ist eine signifikante \u00c4nderung der Kopierdauer im Vergleich zur Tabelle 3 lediglich bei der ersten Messung von dem lokalen Speicher 1 in den lokalen Speicher 1 zu beobachten. Die anderen Messungen sind von dem konkurrierenden Zugriff nicht betroffen. Jedoch zeigt dies deutlich, dass durch die Intercore-Kommunikation auch Berechnungen betroffen sind, welche auf Core 1 exklusiv ausgef\u00fchrt werden. Dies sollte bei einer Bewertung der Echtzeitf\u00e4higkeit eines Systems zwingend ber\u00fccksichtigt werden.<\/p>\n\n\n
\n Quelle:<\/strong><\/td>\n Ziel:<\/strong><\/td>\n Ticks:<\/strong><\/td>\n Instruktionen:<\/strong><\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 1<\/td>\n 2971<\/td>\n 17<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Globaler Speicher<\/td>\n 3483<\/td>\n 17<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Lokaler Speicher 1<\/td>\n 3483<\/td>\n 17<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Globaler Speicher<\/td>\n 3995<\/td>\n 17<\/td>\n<\/tr>\n \n Lokaler Speicher 1<\/td>\n Lokaler Speicher 2<\/td>\n 2971<\/td>\n 17<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 1<\/td>\n 2971<\/td>\n 17<\/td>\n<\/tr>\n \n Lokaler Speicher 2<\/td>\n Lokaler Speicher 2<\/td>\n 2971<\/td>\n 17<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Infineon AURIX TC397<\/h3>\n
\n\n
\n Quelle:<\/strong><\/td>\n Ziel:<\/strong><\/td>\n Ticks:<\/strong><\/td>\n Instruktionen:<\/strong><\/td>\n<\/tr>\n \n Lokaler Speicher 1-0<\/td>\n Lokaler Speicher 1-0<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1-0<\/td>\n Lokaler Speicher 1-1<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1-1<\/td>\n Lokaler Speicher 1-0<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1-1<\/td>\n Lokaler Speicher 1-1<\/td>\n 4113<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1-0<\/td>\n Globaler Speicher<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Lokaler Speicher 1-0<\/td>\n 9260<\/td>\n 3082<\/td>\n<\/tr>\n \n Globaler Speicher<\/td>\n Globaler Speicher<\/td>\n 9239<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 1-0<\/td>\n Lokaler Speicher 2-0<\/td>\n 2076<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2-0<\/td>\n Lokaler Speicher 1-0<\/td>\n 9239<\/td>\n 3082<\/td>\n<\/tr>\n \n Lokaler Speicher 2-0<\/td>\n Lokaler Speicher 2-0<\/td>\n 9239<\/td>\n 3082<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 6 Diskussion<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
Autor<\/h2>\n
\nMulticore – unsere Trainings & Coachings<\/h2>\n
\nMulticore – Fachwissen<\/h2>\n