Zynq-SoC mit ARM-A9-Cores
Zweigleisige Kraftpakete
Fortsetzung des Artikels von Teil 1
Einfaches Onchip-Memory-Beispiel
Mit den von Xilinx vorgesehenen I/O-Funktionen kann man auf das OCM zum Lesen und Schreiben an der selektierten Speicheradresse zugreifen. Sie sind in „Xil_IO.h“ enthalten und erlauben Speichern und Zugriff auf 8-, 16- oder 32-bit char, short oder int im CPU-Adressraum. Die Funktionen benötigen nur die gewünschte Adresse und den dort zu speichernden Wert. Beim Schreiben gilt:
Xil_Out8(0xFFFF0000,0x55);
read_char = Xil_
In8(0xFFFF0000);
Ein besserer Weg zur Sicherstellung, dass beide Adressen auf denselben Speicherort im Onchip Memory zielen, ist eine gemeinsame Header-Datei mit Macro-Definition der gewünschten Adresse für einen spezifischen Transfer – besonders dann, wenn mehrere Personen an der Programmierung der Kerne arbeiten:
#define LED_PAT 0xFFFF0000
Alternativ können beide Programme auf den Speicherort mit einem Pointer zugreifen. Dieser wird so definiert, dass er auf eine konstante Adresse verweist; meist in C:
#define LED_OP (*(volatileunsigned int *)
(0xFFFF0000))
Interprocessor Interrupts nutzen
Das Zynq-SoC bietet für jeden Kern 16 Software-generierte Interrupts. Software Interrupts unterscheiden sich kaum von Hardware Interrupts – außer bei der Triggerung. Sie benötigen keine Abfrage eines erwarteten Speicherorts auf einen aktualisierten Wert. In beiden Kernen konfiguriert man den Generic Interrupt Controller wie beim Hardware Interrupt. Dann kann man einen Software Interrupt mit der Funktion XScuGic_SoftwareIntr in xscugic.h triggern:
XScuGic_SoftwareIntr(<GIC Instance Ptr>,
<SW Interrupt ID>,
<CPU Mask>)
Jobangebote+ passend zum Thema
Applikationsentwicklung als Nächstes
Der nächste Schritt ist die Generierung dreier wichtiger Elemente für AMP: First-Stage Boot Loader, Core-0-Applikation und Core-1-Applikation. Dazu benötigt man jeweils unterschiedliche Board Support Packages.
Als Erstes erstellt man im SDK einen neuen FSBL. Die Selektion »file new application project« führt zu einem FSBL-Projekt, das AMP unterstützt; dies ist insofern kein Unterschied zum normalen FSBL. Allerdings wählt man hier “Zynq FSBL for AMP”. Dann folgt die Applikation für den ersten Kern. Dazu selektiert man Core 0 und das gewünschte Betriebssystem für das passende BSP. Anschließend definiert man den DDR-Speicherort zu seiner Ausführung. Dazu editiert man das Linker-Script (Bild 2) zur Anzeige der DDR-Basisadresse. Das ist wichtig, denn bei inkorrekter Segmentierung des DDR-Speichers könnten die Core-0- und Core-1-Applikationen kollidieren.
Nach der Segmentierung schreibt man die gewünschte Applikation für Core 0, da dieser Kern im AMP-System die Führung übernimmt: Core 0 startet die Ausführung der Applikation in Core 1. Dazu muss man die Code-Sektion gemäß Listing 1 einfügen.
Sie deaktiviert den Cache im Onchip-Speicher und schreibt die Startadresse, auf die Core 1 zugreift. Nach der Ausführung des Set-Event-Befehls (SEV) durch Core 0 beginnt Core 1 mit der Ausführung seines Programms. Nun folgt die Erstellung eines Board Support Package für Core 1. Dabei sollte man das modifizierte Stand-alone OS (standalone_amp) gemäß Bild 3 verwenden, um das Re-Initialisieren der Snoop Control Unit zu verhindern.
Die automatisierte Erstellung des BSP – wie beim Core 0 – sollte man bei der Projektentwicklung nicht nutzen. In den CPU-Optionen wählt man Core 1. Bevor man an die Entwicklung der gewünschten Applikation für Core 1 geht, muss man die BSP-Einstellungen nochmals modifizieren. Das ist äußerst einfach und besteht im Hinzufügen eines Compiler Flag (DUSE_AMP=1) zur Konfiguration der Treiber-Sektion.
Nun kann man die Applikation für Core 1 entwickeln: Dazu selektiert man Core 1 und nutzt das eben geschaffene BSP. Wichtig ist dabei: Danach muss man nochmals die korrekten Speicherorte im DDR-Speicher definieren, auf die sich die Programmausführung bezieht. Dies geschieht durch Editieren des Linker-Script für Core 1, wie vorher geschehen. Wie beim Core 0 muss man auch hier den Cache im Onchip Memory deaktivieren, das zur Kommunikation zwischen beiden Prozessoren dient.
Abschluss der Entwicklung
Nach der Entwicklung der gewünschten Applikationen verfügt man über folgende Komponenten:
- AMP FSBL ELF
- Core 0 ELF
- Core 1 ELF
- BIT-Datei zur Konfiguration des Zynq-Bausteins und AMP-Implementierung
Zum Booten des Zynq SoC vom ausgewählten Konfigurationsspeicher benötigt man eine BIN-Datei. Das geht über eine BIF-Datei, welche die Dateien zur Erstellung dieser BIN-Datei und deren Anordnung definiert. Statt des “create Zynq” Boot Image im SDK verwendet man ein Prompt aus der ISE Design Suite und die BAT-Datei im Dokument XAPP1079 (directory\design\work\bootgen, siehe [1]). Dieses Directory enthält eine BIF-Datei und „cpu1_bootvec.bin“ – als Teil des modifizierten FSBL –, um die Suche nach weiteren Applikationen zu stoppen.
Zur Erzeugung der BIN-Datei kopiert man die drei generierten ELF-Dateien in das bootgen-Directory und editiert die BIF-Datei zur korrekten Übernahme der ELF-Namen. Festgehalten ist dies in Listing 2 auf Seite 26. Jetzt öffnet man ein ISE-Prompt und geht zum bootgen Directory. Dort führt man „createboot.bat“ aus, um die „boot.bin“-Datei gemäß Bild 4 zu erstellen.
Diese wird in den nichtflüchtigen Speicher des Zynq-SoC geladen. Nach dem Booten starten beide Kerne mit dem Ausführen ihrer Programme. Wie man sieht, gestaltet sich die Entwicklung asymmetrischer Multiprozessor-Applikationen auf dem Zynq-SoC mit den verfügbaren Tools recht einfach. Das Gleiche gilt für die Kommunikation zwischen den Kernen über den Onchip-Speicher oder einen segmentierten DDR-Speicherbereich.
Links
[1] www.wiki.xilinx.com/XAPP1079+Latest+Information
[2] www.xilinx.com/about/xcell-publications/xcell-journal.html
[3] forums.xilinx.com/t5/Xcell-Daily-Blog/Adam-Taylor-s-MicroZed-Chronicles-Part-46-Using-both-of-the-Zynq/ba-p/508697
Der Autor
| Adam P. Taylor |
|---|
| ist als Chief Engineer Electrical Systems bei e2v tätig. Davor war er Leiter der Designabteilung beim europäischen Raumfahrtunternehmen Astrium, wo er zudem auch für die Produktentwicklung verantwortlich war. Darüber hinaus ist er Fellow of the Institute of Engineering and Technology sowie Senior Member des IEEE. |
aptaylor@theiet.org
- Zweigleisige Kraftpakete
- Einfaches Onchip-Memory-Beispiel
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Xilinx: UltraScale+
Kintex, Virtex und Zynq mit 16-nm-Strukturen
Xilinx auf der Vision
Zynq-basierende Lösungen für die industrielle Bildverarbeitung
Quartalsergebnisse vorgestellt
Xilinx erhöht Profitabilität
Signifikant höhere System-Performance
Xilinx UltraScale Multi-Processing-Architektur
Video
Xilinx' aktuelle Zynq-Architektur
