Zynq-SoC mit ARM-A9-Cores Zweigleisige Kraftpakete

Optimale Nutzung eines Xilinx-Zyng-SoC, steigt die System-Durchsatzrate.
Optimale Nutzung eines Xilinx-Zyng-SoC, steigert die System-Durchsatzrate.

Bei geschickter Nutzung beider ARM-A9-Kerne und Software-Interrupts kann der Schaltungsdesigner die System-Durchsatzraten eines Xilinx-Zynq-SoC signifikant steigern.

Jedes Xilinx-Zynq-7000-All-Programmable-SoC enthält jeweils zwei ARM-Cortex-A9-Prozessoren. Viele Applikationen und einfache Betriebssysteme nutzen aber nur einen von ihnen – zu Lasten des Datendurchsatzes. Wenn beide Prozessoren im sogenannten Bare-Metal-Modus oder mit unterschiedlichen Betriebssystemen laufen, dann kann einer der beiden kritische Berechnungen in einer Bare-Metal/RTOS-Applikation absolvieren und der andere übernimmt unter Linux HMI-Funktionen und alle Kommunikationsaufgaben.

Leistungssteigerndes Multiprocessing

Multiprozessor-Architekturen erlauben das simultane Ausführen mehrerer Befehle. Symmetrisches Multiprocessing verteilt konkurrierende Software Tasks auf mehrere Kerne, während asymmetrisches Multiprocessing (AMP) auf spezialisierte Prozessoren oder die Ausführung bestimmter Applikationen und Tasks auf identischen Prozessoren setzt. Der Einsatz der beiden Rechenkerne im Zynq-SoC in sogenannten Bare-Metal-Applikationen oder mit unterschiedlichen Betriebssystemen jedenfalls ist ein Beispiel für asymmetrisches Multiprocessing, und zwar in folgenden Kombinationen:

  • Unterschiedliche Betriebssysteme auf Core 0 und Core 1
  • Betriebssystem auf Core 0, Bare Metal auf Core 1 (oder umgekehrt)
  • Bare Metal auf beiden Kernen mit verschiedenen Programmen

Für AMP-Systeme bieten die Prozessorkerne getrennte und gemeinsame Ressourcen, die korrekt adressiert werden müssen. Beide Prozessoren haben getrennte L1-Caches, Timer, Watchdogs und Interrupt Controller.

Gemeinsame Ressourcen sind I/O Peripherals, Onchip Memory, Interrupt-Controller-Distributor, L2 Cache und DDR-Systemspeicher (Bild 1). Jeder Kern hat seinen eigenen Interrupt Controller, und einer oder beide Kerne nutzen Software Interrupts. Dazu dient der ARM Distributed Interrupt Controller, und die Programme verweilen im DDR-Speicher. Die Applikationen brauchen also eine sorgfältige Segmentierung.

AMP-Optimierung ist angesagt

Der wichtigste Aspekt für asymmetrisches Multiprocessing (AMP) mit Zynq-SoC ist der Boot Loader. Er hält nach dem Laden der ersten Applikation Ausschau nach einer weiteren auszuführenden Datei. Xilinx stellt dazu eine Application Note mit Quellcode [1] zur Verfügung. Von dieser Quelle aus abrufbar sind ein modifizierter First-Stage Boot Loader (FSBL) und ein modifiziertes Stand-alone-Betriebssystem (OS). Der erste Schritt besteht im Laden der Zip-Datei aus der Application Note und der FSBL- und OS-Extraktion in das gewünschte Directory. Dann wird der Ordner SRC in „design” umbenannt. Wichtig ist, dass das Software Development Kit (SDK) diese neuen Dateien mit dem modifizierten FSBL und Stand-alone OS erkennt.

Der nächste Schritt ist also die Aktualisierung des SDK Repository. Dies ist alles recht einfach: Im SDK selektiert man im Tools-Menü die Option “repositories”, gefolgt von “new” zum Navigieren durch die Directory Location <your working directory>\app1079\design\work\sdk_repo.

Kommunikation zwischen den ­Prozessoren

Vor der Entwicklung von Applikationen für das gewünschte AMP-System sollte man sich deren Kommunikationsfunktionen (falls vorhanden) näher ansehen. Sinnvollerweise bedient man sich des Onchip-Speichers, wobei das Zynq-SoC davon 256 KB vorweisen kann; und zwar mit folgenden Zugriffsmöglichkeiten:

  • Von jedem Kern aus über die Snoop Control Unit (SCU)
  • Von den programmierbaren Logikeinheiten aus über den AXI Accelerator Coherency Port (ACP) via SCU
  • Von den programmierbaren Logikeinheiten aus über den High-Performance AXI Port via Onchip Memory (OCM) Interconnect
  • Vom zentralen Interconnect aus, ebenfalls via OCM.

Bei der Nutzung dieser Quellen beim Lesen vom sowie Schreiben zum Onchip-Speicher ist es wichtig, die Betriebsweise des OCM im Detail zu verstehen.

Da mehrere Quellen auf das OCM zugreifen können, sollte man Arbitrations- und Prioritätsroutinen definieren. Die niedrigste Latenz wird von der Snoop Control Unit verlangt (Prozessorkern oder AXI-ACP Interface). SCU-Leseanforderungen haben die höchste Priorität, gefolgt vom SCU Write und OCM Interconnect Read and Write. Die Rangfolge zwischen SCU Write und OCM-Interconnect-Zugriff lässt sich umkehren, indem man SCU Write im Onchip-Memory-Control-Register niedriger ansetzt.

Der Onchip-Speicher arbeitet mit 128-bit-Worten und ist in vier Regionen mit 64 KB im Adressraum unterteilt. In der anfänglichen Konfiguration befinden sich die ersten drei 64-KB-Blöcke am Anfang des Adressraums, der letzte am Ende (Bild 2).