Embedded Design

Windows-Echtzeit-Erweiterung oder DSPs – wer ist schneller?

16. Juli 2012, 10:16 Uhr | Von Bernhard Hartmann
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Software-Design

Fortschritte bei der Software-Entwicklung haben auch erhebliche Auswirkungen auf DSP-Systeme. Die Nachfrage nach standardisierten Werkzeugen anstelle proprietärer Tools ist eine neuerliche Veränderung für viele DSP-Entwickler. DSP-Programmierung erfordert meist spezialisierte Werkzeuge und Programmiersprachen wie C und Assembler. Viele Entwicklungs-Teams erkennen, dass proprietäre DSP-Werkzeuge und niedere Sprachen spezialisiertes Fachwissen erfordern, das oft schwer zu finden und teuer aufzubauen ist. Die Verwendung von standardisierten Entwicklungs-Werkzeugen wie Visual Studio und höheren Sprachen wie C++ erhöht nicht nur die Produktivität, sondern reduziert auch erheblich die Entwicklungskosten.

Echtzeit-Betriebssystem

DSPs verwenden proprietäre Echtzeit-Betriebssysteme vom Chiphersteller. DSP-Betriebssysteme sind zwar sehr leistungsfähig, haben aber mangels Kommunikation zwischen den verschiedenen DSP-Kernen beträchtliche Einschränkungen. Jeder DSP führt nur die eigene Anwendung aus und nutzt sehr wenig die Kommunikation zwischen Prozessoren.

passend zum Thema

RTX‘ SMP-fähiger Ablaufplaner.
Bild 3. RTX‘ SMP-fähiger Ablaufplaner.
© IntervalZero

Die RTX-Echtzeit-Plattform implementiert ein gemeinsames, symmetrisches Multiprocessing-Steuerprogramm für alle Kerne im Echtzeit-Subsystem (Bild 3). Anstelle separater Betriebssysteme und auf jedem Echtzeit-Kern getrennt ausgeführter Anwendungen verwendet RTX einen Scheduler, um Threads über eine Anzahl verschiedener Kerne zu verteilen. Das flexible SMP-Modell ermöglicht eine einfache Synchronisation und Kommunikation zwischen den verschiedenen Kernen/Threads. Lastenausgleich kann einfach von den APIs implementiert werden, die das RTX-Subsystem bereitstellt. Die RTX-APIs ermöglichen das Verschieben von Threads zwischen Prozessoren während der Laufzeit.

Diese Skalierbarkeit bewährt sich, wenn die Anwendung zwischen Systemen mit verschiedenen Kern-Konfigurationen portiert wird. Werden Kerne hinzugefügt oder aus einem System entfernt, kann der Nutzer mit der internen Logik der Anwendung Threads nach Bedarf verteilen.

Entwicklungs-Tools

DSP-Hersteller haben ihre eigenen Werkzeuge, wie z. B. Code Composer Studio von TI oder Softwarekit VisualDSP++ von ADI. Während diese Werkzeuge bei der Entwicklung von DSP-Anwendungen stark genutzt werden, sprechen Kostendruck und Marktnachfrage eher für standardisierte Werkzeuge. Außerdem werden durch die Low-Level-Werkzeuge für DSPs und proprietäre Programmierpraktiken die Wiederverwendung und Portierbarkeit des Codes erschwert. Viele Entwickler erkennen, dass Arbeiten mit proprietären DSP-Tools nicht nur hohe Ansprüche stellt, sondern auch kostspielig in der Pflege ist.

RTX verwendet Microsoft Visual Studio, das Industriestandard-Werkzeug für x86-/x64-Programmierung. Entwickler mit Microsoft-Know-how lassen sich einfacher finden als solche mit DSP-Erfahrung. Der Einsatz der Hilfe bei Visual Studio und des Microsoft Developer Networks (MSDN) sorgt für erhöhte Produktivität und reduzierte Kosten. Die meisten Entwicklungsteams bevorzugen aus diesen Gründen die Nutzung möglichst standardisierter Tools.

Code-Basis

Wird eine Portierung in Betracht gezogen, muss der Entwickler beachten, dass es bei einer RTX-Anwendung zwei Teile gibt: die Nicht-Echtzeit- und die Echtzeit-Verarbeitung. Der nicht zeitkritische Code wird direkt über ein Standard-Visual-Studio-Projekt portiert und auf dem Windows-Betriebssystem ausgeführt. Der Echtzeit-Code wird ebenfalls mit Visual Studio erstellt, läuft aber auf den von RTX gesteuerten Kernen (Echtzeit-Subsystem).

DSPs werden üblicherweise in C und Assembler programmiert. Während der Assembler-Code nicht übertragbar ist und neu geschrieben werden muss, kann der C-Code mit Visual Studio portiert werden. Die RTX-Plattform ermöglicht es Echtzeit-Nutzern, effizient in C++ zu codieren. Auch wenn DSPs durchaus Unterstützung für C++ anbieten, verlieren objektorientierte Sprachen beim Compilieren für DSP-Architekturen zu viel an Effizienz, um noch für einen Echtzeiteinsatz brauchbar zu sein. Die Unterstützung für C++ der RTX-Plattform ist somit ein deutlicher Vorteil. Eine Codebasis in höheren Sprachen wie C/C++ erhöht die Übertragbarkeit und Wiederverwendbarkeit des Codes, was wiederum Kosten und Risiken verringert.

DSP-Bibliotheken

Texas Instruments und Analog Devices bieten jeweils optimierte DSP-Bibliotheken an, um Entwickler bei der Programmierung zu unterstützen. An die Stelle dieser DSP-Bibliotheken stellt Intel die Integrated Performance Primitives (IPP). Die IPP-Bibliothek ist eine Sammlung von Funktionen (d. h. DSP, Imaging, Video, usw.), die für x86-Multicore-Prozessoren optimiert sind. Die IPP-Bibliothek erhöht Produktivität und Leistung, indem optimierte Routinen für die gängigsten DSP-basierten Funktionen zur Verfügung gestellt werden.

Benchmarks

Es gibt eine Reihe von Möglichkeiten, die Leistung zwischen den Prozessoren zu vergleichen. Da der Fokus auf DSPs liegt, wird in Tabelle 2 die Anzahl der Gleitkommazahl-Operationen pro Sekunde (GFLOPS) verwendet.

DSP Intel Multi-Core
max. Kerntakt: 1,25 GHz max. Kerntakt: 3,0 GHz
20 GFLOPS/Core Single precision 32 GFLOPS/Core Double precision

Tabelle 2. Vergleich zwischen dem Multi-Core-DSP C66xx von Texas Instruments und dem Intel Core-i7 „Sandy Bridge“.


Der TI-C66xx liefert bei 1,25 GHz 20 GFLOPS mit einfacher Genauigkeit pro Kern. Der Intel Core-i7 berechnet 32 GFLOPS mit doppelter Genauigkeit pro Kern. Obwohl also die GFLOPS-Leistung des TI-DSPs sehr hoch ist, entspricht sie nicht der Roh-Leistung und Geschwindigkeit der Intel-Prozessoren.


  1. Windows-Echtzeit-Erweiterung oder DSPs – wer ist schneller?
  2. Software-Design
  3. DSPs auch weiter sinnvoll

Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!