Großrechner werden schon lange typischerweise als Vektorrechner ausgeführt. Komplexe Berechnungen (die auch in modernen Steuergeräten immer häufiger notwendig sind) arbeiten oft mit Vektoren oder Matrizen. Hier ist es von großem Vorteil, wenn der Controller nicht nur Einzelwerte, sondern Vektoren direkt verarbeiten kann. Der MPC5554 kann neben den „normalen“ Skalartypen auch mit Vektoren (bestehend aus zwei 32-bit-Werten) in einem Schritt rechnen (Bild 2). Das gilt für alle arithmetischen oder logischen Operationen, sogar für Gleitkomma-Berechnun-gen. Die Assemblerbefehle für die Vektoreinheit fangen typischerweise mit „ev“ an. So gibt es neben den normalen Befehlen (z.B. add, sub, and, comp, ...) auch die entsprechende Vektor-Form (z.B. evadd, evsub, evand, evcomp, ...).
Eine Operation, die in einem Takt ausgeführt wird, kann deshalb mit zwei Werten gleichzeitig rechnen. Für Algorithmen, die Vektoren oder Matrizen bearbeiten, verdoppelt sich dadurch sofort die Rechenleistung. Das ist vor allem für typische DSP-Operationen optimal nutzbar, denn hier werden immer Vektoren oder Matrizen benutzt. Die Vektor-Einheit ist nicht darauf beschränkt, sondern lässt sich ebenfalls für andere Aufgaben nutzen, denn der Vektor-Befehlssatz ist nicht nur auf DSP-Befehle (MAC-Operationen) beschränkt, sondern umfasst den kompletten Befehlssatz. Als Beispiel sei hier ein „evfscfsi“ (Vektor Convert Signed Integer to Floating Point) genannt.
Wichtig ist, dass der Anwender dafür sein Programm optimiert, denn im „normalen“ C-Code kommen keine Vektoren vor. Der Programmierer hat sich (notwendigerweise) die größte Mühe gegeben, den Algorithmus so zu formulieren, dass keine Information über die ursprünglichen Vektoren mehr im C-Code zu finden sind. Deshalb kann der Compiler diese Information nicht mehr aus dem Code herauslesen und damit die Vektor-Einheit auch nicht optimal nutzen.
Die einfachste Form, diese Vektor-Möglichkeiten in C zu nutzen, ist ein Satz von „intrinsischen Funktionen“, die in den Compilern für diese Familie bereits implementiert sind. Diese Funktionen sind in [1] beschrieben.
Direkter Zugriff auf den Speicher
Wie bereits erwähnt, kann die Vektor-Einheit viele Algorithmen (z.B. digitale Filter) beschleunigen. Das kann aber nur dann optimal ablaufen, wenn die Daten in einem schnellen Speicher (dem internen System-RAM) vorliegen; denn nur auf diesen Speicher kann mit voller Geschwindigkeit zugegriffen werden. Daten aus langsamen Peripheriemodulen werden deshalb per DMA in das RAM transportiert, so dass sie dann mit optimaler Geschwindigkeit ausgelesen werden können. Ein komplexer Controller verfügt über eine umfangreiche Peripherie, deshalb sind hier auch DMA-Kanäle in ausreichender Zahl erforderlich. Der MPC5554 ist mit seinen 64 DMA-Kanälen optimal gerüstet.
Unterstützung durch Coprozessoren
Schon die Vektor-Einheit erlaubt ein gewisses Maß an Parallelverarbeitung (dieselbe Operation wird gleichzeitig zweimal ausgeführt). Zusätzliche Coprozessoren bieten darüber hinaus eine weitere Ebene paralleler Aufgaben. Die beiden ETPUs (Enhanced Timing Processor Units) stellen jeweils einen eigenen, autarken Mikrocontroller dar. Sie umfassen neben den eigenen Peripheriemodulen (Timer und 32 doppelte Capture-/Compare-Kanäle) auch den Programm- und Datenspeicher und jeweils einen eigenen Rechenkern. Zusätzlich enthält jede ETPU ein eigenes, in Hardware implementiertes kooperatives Echtzeit-Multitasking-Betriebssystem. Damit ist keinerlei Software für die Taskverwaltung und für die Taskumschaltung erforderlich. Ein kompletter „Task-Switch“ in der ETPU dauert (mit allen Verwaltungsaufgaben) lediglich sechs Systemtakte. Bei einem Systemtakt von 132 MHz entsteht deshalb bei einer Million Task-Switches pro Sekunde ein Overhead von lediglich 4,5 %.
Aufbauend auf den TPUs in der MPC500-Familie wurde die Breite aller Register (incl. Capture-/Comapre Register) von 16 auf 24 bit erweitert. Daneben wurde der Befehlssatz vervollständigt; es gibt jetzt auch logische Befehle, echte Multiplikation und Division sowie MAC-Befehle (Multiply/Accumulate).
Per DMA können beliebige Daten aus anderen Modulen (z.B. A/D-Wandler) in die ETPUs geschrieben werden. Damit lassen sich z.B. autarke Stromregler für Magnetventile realisieren. Die Rechenleistung einer ETPU lässt sogar zu, z.B. eine komplette feldorientierte Regelung für Elektromotoren alleine mit einer ETPU zu implementieren.
Die ETPUs sind zwar (infolge der integrierten Capture-/Compare-Logik) für Timing-Aufgaben optimiert, aber auch viele andere Aufgaben lassen sich damit erledigen, beispielsweise sind Gateway-Funktionen zwischen den verschiedenen seriellen Schnittstellen (unter Zuhilfenahme des DMA) möglich.
Leistungsfähige Verbindungen dank Vermittlungstechnik
Die verschiedenen Arbeitseinheiten sollten möglichst wenig Berührungspunkte haben, damit sie sich nicht gegenseitig „ausbremsen“. Ein gemeinsamer, zentraler interner Bus wäre dafür eine schlechte Lösung, denn der würde zu häufigen Buskonflikten führen. Deshalb verwenden die neueren Controller von Freescale so genannte „Crossbars“. Ein Crossbar ist die zentrale Schaltstelle, die die Datenanforderungen der einzelnen Busmaster auf die verschiedenen Slaves verteilt.
Wie bei einer Telefonzentrale können dabei gleichzeitig mehrere Buszugriffe verschiedener Master erfolgen, solange sie nicht gleichzeitig mit demselben Slave kommunizieren wollen. Damit ergeben sich nur dann Verzögerungen, wenn zwei Master im selben Takt auf denselben Slave zugreifen wollen. Das ist aber um etwa eine Zehnerpotenz unwahrscheinlicher als es bei einem zentralen Bus der Fall wäre. Dieser große Unterschied ergibt sich vor allem in der Verteilung der Zugriffe: Die CPU greift ca. 80 % der Zeit auf den Flash-Speicher und ca. 20 % auf das RAM zu. Ein DMA braucht den Flash-Speicher eher selten, dafür greift er häufiger auf RAM und Peripheriemodule zu.
![]() | Dipl.-Inf. Josef Fuchs ist als Field Applikation Engineer bei Freescale Halbleiter Deutschland GmbH zuständig für Automotive Elektronik Applikationen. Er hat 18 Jahre Software- und Hardware-Erfahrung für verschiedene Mikrocontroller im Anwendungsbereich Industrie und Automotive. E-Mail: josef.fuchs@freescale.com |