Hardware-Strukturen für eine schnelle, kosteneffektive Verarbeitung von DSP-Algorithmen mit geringer Verlustleistung Reconfigurable Algorithm Processing

Nach zehnjähriger Entwicklungsdauer und fünf Jahre nach der erfolgreichen Markteinführung ihrer patentierten, rekonfigurierbaren Hardware-Strukturen unter der Bezeichnung „Reconfigurable Algorithm Processing“ (RAP) hat die Firma Elixent eine Version 2.0 ihrer D-Fabrix-Architektur herausgebracht. In die neue Entwicklung sind insbesondere die Rückmeldungen aus den realen Anwendungen der Version 1.x eingeflossen.

Hardware-Strukturen für eine schnelle, kosteneffektive Verarbeitung von DSP-Algorithmen mit geringer Verlustleistung

Nach zehnjähriger Entwicklungsdauer und fünf Jahre nach der erfolgreichen Markteinführung ihrer patentierten, rekonfigurierbaren Hardware-Strukturen unter der Bezeichnung „Reconfigurable Algorithm Processing“ (RAP) hat die Firma Elixent eine Version 2.0 ihrer D-Fabrix-Architektur herausgebracht. In die neue Entwicklung sind insbesondere die Rückmeldungen aus den realen Anwendungen der Version 1.x eingeflossen.

Mehrere Trends prägen den Markt der Application Specific Standard Products (ASSP): Die Anforderungen und die Chipkomplexität steigen, ebenso die Zahl der auf einer Plattform integrierten Standards. Schließlich nehmen das Mindestproduktionsvolumen und die Zahl der Chips pro Wafer zu. Ein Zuviel an verschiedenen Anwendungen zieht jedoch bei einem ASIC einen übermäßigen Flächenbedarf nach sich, während eine Standard-CPU viel Leistung aufnimmt und dennoch möglicherweise nicht schnell genug ist. Weil aber der Markt weder einen Anstieg der Preise noch eine Vergrößerung der Verlustleistung hinnimmt, besteht das Problem darin, kostengünstige und leistungsfähige Systeme mit geringer Verlustleistung zu entwickeln.

Mit der Entwicklung der D-Fabrix-Architektur wurde bereits vor zehn Jahren begonnen; seit etwa fünf Jahren ist diese erfolgreich am Markt eingeführt. Sie vereint Elemente aus ASICs, FPGAs und Prozessoren und ermöglicht eine schnelle, kosteneffektive und effiziente Verarbeitung von DSP-Algorithmen mit geringer Verlustleistung. Die Architektur gestattet die vollständige Konfiguration eines Chips nach der Herstellung, sodass der Baustein an geänderte Umgebungsbedingungen angepasst werden kann. Dies eröffnet neue Möglichkeiten in der Anwendung, von der Fehlerbeseitigung und der Realisierung von „Upgrades“ im Feld bis hin einer vollständigen nachträglichen Modifikation der Funktionen. Ein und dieselbe konfigurierbare IC-Plattform lässt sich für eine ganze Reihe von Produkten nutzen, deren Funktion oder regionale Varianten erst durch die genaue Konfiguration des Prozessors im Feld festgelegt wird.

Die D-Fabrix-Architektur verwendet rekonfigurierbare Arrays, die sich an beliebige Algorithmen und Datenpfad-Breiten anpassen können. Damit lassen sich Systeme mit der Flexibilität eines Prozessors realisieren. Die Arrays bestehen aus einigen hundert oder tausend „Tiles“ (Kacheln), die aus 4-bit-ALUs, Registern und einer „Switchbox“ bestehen. Zusätzlich sind über das gesamte Array Baugruppen für spezielle Funktionen verteilt. Mit dieser Architektur entsteht so etwas wie ein virtueller Hardware-Beschleuniger bzw. ein Software-ähnliches Programm für jeden Algorithmus eines Systems. Solange die Hardware-Beschleuniger arbeiten, stellen sie eine effiziente Hardware dar. Werden sie nicht mehr benötigt, lassen sie sich genau so einfach ersetzen, wie eine CPU mit neuer Software versehen werden kann. Dank der dynamischen Programmierbarkeit des Systems kann der Chip bei laufendem Betrieb umkonfiguriert werden.

Die Programmierung des Arrays erfolgt ähnlich wie bei ASICs oder FPGAs. Die Erfahrung zeigt, dass der Aufwand für die Programmierung des Chips nur etwa halb so groß ist wie der für die Erstellung eines vergleichbaren ASIC. Durch den RTL-Support (Register Transfer Level) muss der Designer zudem nicht den Gebrauch neuer Programmierwerkzeuge (Tools) erlernen. Die D-Fabrix-Architektur ist oft deutlich schneller als von der Anwendung gefordert. Sie kann daher nach dem „Timesharing“-Prinzip von mehreren Funktionen umschichtig genutzt werden. Anstatt die gesamte benötigte Hardware zu implementieren, lassen sich die gestellten Anforderungen mit einem kleineren RAP-Baustein erfüllen. Jede der Timesharing-Funktionen wird in Form einer Konfiguration vorgehalten. Allerdings mussten in der Version 1.0 mehr Konfigurationen eingesetzt werden, als dies wünschenswert gewesen wäre (Tabelle). Das war der Anlass für die Entwicklung einer neuen Architektur, bei der diese Zahl reduziert werden konnte.

Praxiserfahrungen eingeflossen

Die Version 2.0 wurde unter Berücksichtigung der Anregungen entwickelt, die von den Anwendungs-Designern aus der Praxis kamen. Hinzu kam das Know-how, das sich Elixent während der Entwicklung und Integration der RAP angeeignet hatte. Für die fortlaufende Verbesserung der Architektur ist bei dem Unternehmen ein Entwicklungsteam zuständig: die Advanced Development Group (ADG). Dieses Team von Ingenieuren – unter ihnen auch die Firmengründer – hat in die RAP-Architektur seit Anbeginn entworfen. Die Beziehungen zwischen dem Entwicklungsteam, den Partnern in der Anwendung und den Anwendungsentwicklern sind von entscheidender Bedeutung für den Entwicklungsprozess der Architektur (Bild 1).

Die Anwendungs-Entwicklung
Um die die Array-Effizienz in einer nachfolgenden Version 2.0 weiter zu steigern, wurden folgende Schwerpunkte identifiziert:

  • bessere Unterstützung für bereits entwickelten Code,
  • Realisierung von Steuerungs-Knoten mit hohem Ausgangsstrom (Fan out),
  • Einführung asymmetrischer Verschiebe-Operationen (Shifts), weil Verschiebe-Operationen nach links und rechts einen sehr unterschiedlichen Aufwand nach sich ziehen.

Die Architektur wurde zudem hinsichtlich Geschwindigkeit, Fläche und Verlustleistung optimiert. Zu den wichtigsten Gründen für die Entwicklung der Version 2.0 gehörte, dass die entscheidenden Einschränkungen für die Realisierung einer bestimmten Systemleistung und Integrationsdichte damit zu tun hatten, wie die Strukturen des Chips realisiert wurden. Zwar ist D-Fabrix eine Architektur für die Abarbeitung von Algorithmen, doch es stellte sich heraus, dass nahezu die Hälfte der ALUs für Multiplexing und Bit-Manipulation genutzt wurden (Bild 2).

Die Verteilung der ALU-Nutzung unterscheidet sich von einer Anwendung zur anderen. Bei einem JPEG-Encoder etwa werden weniger Multiplexer genutzt, aber die Zahl der Schieberegister-Operationen liegt über dem Durchschnitt. Umgekehrt verwendet eine DES-Funktion (Data Encryption Standard) mehr Multiplexer, wogegen keine Subtraktionen vorkommen. Hier werden die Daten mit zahlreichen Multiplexern und Seriell-/Parallel-Umsetzer-Blöcken verarbeitet. Um für alle Anwendungen Verbesserungen zu erzielen, waren Veränderungen der Architektur erforderlich. Das Multiplexer-Problem ist auf das Routing zurückzuführen: Die Routing-Ressourcen werden knapp, wenn in jeder „Switchbox“ zwei Multiplexer verwendet werden. Das Routing ist häufig einfacher, wenn stattdessen ein Multiplexer und eine ALU genutzt werden.

Das Problem im Zusammenhang mit der Bit-Extraktion und der Bit-orientierten Logik hat mit den Einschränkungen bei den Bit-Breiten der ALUs in der Version 1.x zu tun. Obwohl mit den Befehlen für die Bit-Extraktion die Breite eines Wortes um mehrere Bits reduziert werden kann, zeigte sich in der Praxis, dass mehr als die Hälfte dieser Befehle nur ein einziges Bit aus einem „Nibble“ extrahierten. Häufig schließen sich daran Bit-orientierte Logik-Operationen, die die Bits in geänderter Abfolge wieder zusammensetzen. Ein wichtiges Ziel bei der Entwicklung der Version 2.0 bestand nun darin, die Zahl der so genutzten ALUs zu verringern; dies führt zu kleineren und schnelleren Systemen, die zudem weniger Leistung benötigen.