Startseite > Halbleiter > Programierbare Logik > Bildverarbeitung in programmierbarer Logik mit C/C++

Xilinx

Bildverarbeitung in programmierbarer Logik mit C/C++

25. Februar 2016, 11:34 Uhr | Von Olivier Tremois, DSP-Spezialist FAE bei Xilinx

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

SDSoC-Compiler

Das SDSoC ist kein einfacher System-Compiler. Es führt eine umfangreiche Codeanalyse durch, um zu entscheiden, welche Art der Datenbewegung die in Hardware angelegten Funktionen am besten unterstützt, und welcher Port den Datentransfer übernimmt. Für jeden Funktionsparameter müssen wir festlegen, ob ein ARM AMBA AXI4-Lite, AXI4¬Full Memory-Mapped oder AXI4-Stream Data Mover am besten geeignet ist. Wir müssen außerdem eine geeignete Verbindung wählen: AXI4 High-Performance (HP), General Purpose (GP) oder Accelerator Coherency Port (ACP), oder Ports anderer Acceleratoren innerhalb des SDSoC-Environments oder im Board Support Package (BSP).
Die SDSoC-Umgebung erstellt daraufhin ein Design einschließlich der notwendigen IPs für ein voll funktionales System, etwa mit Direct Memory Access (DMA) für AXI4-Stream-Datentransfer, und modifiziert den C-Quellcode (anstelle des ursprünglichen C++-Codes) für den Hardware-Call. In unserem Beispiel ist das Interface recht einfach: Auf zwei Eingangs-Arrays und drei Ausgangs-Arrays wird über AXI4-Stream und DMAs zugegriffen, und einige Skalare werden über AXI4-Lite gesetzt. Der Entwickler muss über die DMAs oder
Adressen der Skalar-Register nicht nachdenken, die SDSoC-Umgebung verwaltet alles automatisch.
Vor dem Aufbau des Systems empfiehlt es sich zu verifizieren, ob der Quellcode zum Vivado HLS passt, und dann erst die VHLS-Direktiven hinzuzufügen. Mit spezifischen SDSoC-Direktiven legt man fest, dass die Daten im physikalischen Speicher zusammenhängend abgelegt werden (mit sds_alloc) und dass ein DMA-Zugriff gewünscht ist. Dann wird die Konfiguration auf SDEstimate geschaltet zur ersten Abschätzung der erzielbaren Beschleunigung.
Die SDSoC-Umgebung schätzt die Beschleunigung anhand der Prozessor-Runtime (mit dem Hardware-adaptierten Code, der langsamer ist als der originale Prozessor-adaptierte Code, wobei die Compiler-Optimierung auf –O0 gesetzt ist) und aus der Anzahl der Taktzyklen (berechnet per VHLS als Latenz des Hardware-Accelerators). Diese Latenz ist der Maximalwert – also nur eine grobe Schätzung. Die Beschleunigung für den Hardware-Accelerator erreicht beinahe den Faktor 700. Die zahlreichen Dateizugriffe beanspruchen natürlich viel Zeit. Deshalb kommt die gesamte Beschleunigung »nur« auf den Faktor 5.
Den Abschluss bildet der Aufbau des Systems, einschließlich der Acceleratoren und deren Verbindung mit dem Prozessor. Dann wird der C++-Quellcode modifiziert, um diese Acceleratoren zu starten und zu steuern (statt die ursprüngliche C-Funktion aufzurufen). Auf dieser Stufe erhalten wir auch einen exakten Wert für die Beschleunigung, mit allen Datentransfers vom und zum DDR und der Leerung des Caches. Die Hardware-Beschleunigung ist abhängig von der Bildgröße, nicht von der Größe des strukturierenden Elements. Je höher die Zahl der aktiven Pixel im strukturierenden Element, desto größer das Beschleunigungsverhältnis. Die Latenz nach Bild 7 bezieht sich auf die gesamte Pipeline mit allen Software- und Hardware-Elementen.
Die im SDSoC-Environment integrierten Tools für System-Profiling, Software-Beschleunigung in programmierbarer Logik und Kompilierung zur Systemoptimierung sowie Generierung der passenden Konnektivität zur Vermeidung von Engpässen beim Speicherzugriff ermöglichen den Abschluss des Projekts in weniger als einer Woche. Mit einem Standard RTL-Flow für Accelerator und Treiber zur Modifizierung des C-Code wäre dies kaum möglich.