Digitale Signalprozessoren Wege zu echter Multicore-Tauglichkeit

Autor / Redakteur: Tom Flanagan, Sanjay Bhal, John Warner * / Holger Heller

Welche Elemente muss eine SoC-Architektur mitbringen, um Kommunikations-Infrastruktur-Einrichtungen wie Media-Server und Wireless Baseband optimal zu unterstützen?

Firmen zum Thema

Multicore-DSP von Texas Instruments: Grundlage für System-on-Chip-Designs, die DSP- und RISC-Cores kombinieren
Multicore-DSP von Texas Instruments: Grundlage für System-on-Chip-Designs, die DSP- und RISC-Cores kombinieren
(Bild: Texas Instruments)

Der Grundgedanke eines System-on-Chip ist es, immer mehr Funktionen in einen Baustein zu integrieren, bis schließlich ein Punkt erreicht ist, an dem alle oder zumindest fast alle Funktionen, die eine Anwendung benötigt, in das SoC integriert sind. Das SoC selbst ist dabei als Halbleiterbaustein implementiert, und zur Gesamtlösung gehört häufig ein großer Umfang an Software.

Viele SoC-Designs kombinieren DSP-Cores mit RISC-Cores und sind auf die Verarbeitungsanforderungen bestimmter Applikationen ausgerichtet. Beispiele für solche Anwendungen sind die Sprachverarbeitung, Transcoding-Aufgaben in Media Gateways oder die Funkkanal- und Transportnetzwerk-Verarbeitung in drahtlosen Infrastrukturen.

Bildergalerie

Performance-Steigerungen wurden in der Vergangenheit stets durch Umsteigen auf eine kleinere Prozessgeometrie bzw. Anheben der Taktfrequenz erzielt. Bei den heutigen, bereits stark miniaturisierten Prozessgeometrien bringen beide Maßnahmen unweigerlich auch höhere Kosten und mehr System-Verlustleistung mit sich, sodass die Abwägung der Vor- und Nachteile etwas komplexer ist.

Paralleler Zugriff auf Verarbeitungsressourcen

Eine mögliche Alternative besteht darin, einen Baustein mit mehreren Prozessorkernen zu bestücken, um den angestrebten Performance-Schub mit niedrigeren Taktraten und geringerer Leistungsaufnahme zu erzielen, während dennoch alle gewünschten Systemparameter geboten werden. Dies hat sich für Embedded-Anwendungen auf der Basis von Multicore-SoCs als die bevorzugte Wahl herausgestellt. Zusätzlich werden applikationsspezifische Beschleuniger und Coprozessoren integriert, um die Verarbeitungskapazität weiter aufzustocken und die System-Verlustleistung zu verringern.

In diesem Szenario kommt es darauf an, den parallelen Zugriff auf die Verarbeitungsressourcen zu ermöglichen, sodass sich die Fähigkeiten des Bausteins in vollem Umfang ausreizen lassen. Entscheidend ist, dass die SoC-Architektur die entsprechenden Fähigkeiten innerhalb der Chip-Infrastruktur bietet, damit die Kapazität der internen Verbindungsressourcen alle Möglichkeiten der Multicore-Technik ins Spiel bringen kann.

Die unkomplizierteste Möglichkeit, diese Vorgabe umzusetzen, ist ein großes Koppelfeld (Crosspoint Matrix). Eine solche Lösung birgt aber Nachteile in Bezug auf die Leistungsaufnahme und die Kosten, da ein großer Teil eines solchen Koppelfelds zu jedem Zeitpunkt ungenutzt ist. Im Gegensatz dazu stellt ein ausgefeilteres On-Chip-Netzwerk lokale Übertragungskapazität für eng miteinander verflochtene Elemente zur Verfügung, während diese lokal gebündelten Funktionen untereinander durch einen gemeinsamen Kommunikations-Backbone miteinander verbunden sind.

Fortschreibung von Moore’s Law

Der Umstieg auf immer kleinere Prozessgeometrien hat stets entscheidend dazu beigetragen, dass Moore’s Law seine Gültigkeit behielt. Der Schritt zum 40-nm-Prozess ergab eine eindrucksvolle Performance-Steigerung. Mit der Umstellung auf 28 nm wird es genauso sein, doch die modernen Applikationen geben sich damit nicht zufrieden. Der größte Vorteil, den der Wechsel auf eine neue Prozessstufe mit sich bringt, besteht heute in der Möglichkeit, noch mehr Funktionen einer Applikation in einem einzigen Baustein zu integrieren.

Dieser Wechsel ist somit auch ein grundlegender Wegbereiter für SoCs. Die erste und einleuchtendste Option, das höhere Integrationspotenzial zum Steigern der Performance zu nutzen, besteht im Hinzufügen weiterer programmierbarer Cores. Man unterscheidet grundsätzlich zwischen homogenen und heterogenen Multicore-Bausteinen. Homogene Multicore-Chips enthalten mehrere gleichartige Cores, während in heterogenen Bausteinen unterschiedliche Core-Typen kombiniert sind.

Fakt ist, dass praktisch alle Anwendungen eine Kombination verschiedener Verarbeitungsfähigkeiten erfordern, darunter etwa die Signalverarbeitung oder die Ausführung von Steuerungscode. DSP-Cores und ARM RISC-Cores sind ideal für diesen Mix aus unterschiedlichen Verarbeitungsaufgaben geeignet.

Festkomma- und Gleitkomma-Operationen unterstützen

Die neuesten DSP-Cores von Texas Instruments unterstützen sowohl Festkomma- als auch Gleitkomma-Operationen und führen VSP-Operationen mit hohen Taktraten aus, was die Entwicklung und Einrichtung entsprechender Algorithmen erleichtert. Da verschiedene ARM-Cores zur Verfügung stehen, können SoC-Anbieter die Auswahl der RISC-Cores individuell auf die jeweiligen Verarbeitungsanforderungen, die gewünschte Leistungsaufnahme und die verwendete Prozessstufe abstimmen.

Hinsichtlich der Architektur kommt es darauf an, heterogene Core-Implementierungen zu unterstützen. Während es keine Problem bereitet, auf der Basis einer heterogenen Architektur homogene Lösungen, d.h. ausschließlich mit ARM- oder DSP-Cores bestückte Bausteine zu realisieren, ist das Umgekehrte meistens nicht der Fall, will man keine gravierenden Performance-Einschränkungen in Kauf nehmen.

Bild 1 zeigt die neue KeyStone-Multicore-Architektur von TI, die ein typisches Beispiel für heterogene Multicore-Architekturen ist.

Multicore-Navigator

Die Funktionselemente, aus denen sich die Architektur zusammensetzt, sind so miteinander kombiniert, dass beste Voraussetzungen für flexible und skalierbare Applikationen gegeben sind. Anwendungen wie etwa Mobilfunk-Basisstationen oder die Radar-Array-Verarbeitung haben hinsichtlich der Verarbeitungs- und I/O-Ressourcen einen sehr ähnlichen Bedarf, während die Beschleunigungs- und Coprozessor-Anforderungen völlig unterschiedlich sind.

Layer 1 PHY-Beschleuniger zum Beispiel sind für Mobilfunk-Basisstationen unverzichtbar, aber für die Radar-Verarbeitung werden sie nicht benötigt. Die Wahrscheinlichkeit, dass ein und dieselbe Organisation sowohl Radar- als auch Basisstations-Produkte entwickelt, ist zweifellos gering. Dennoch profitieren beide von den Kostenersparnissen und den großen Stückzahlen, die für den SoC-Entwickler relevant sind.

Wenn eine ganze Produktpalette abgedeckt werden soll, ist die Skalierbarkeit der SoC-Architektur von großer Bedeutung, um unterschiedliche Anforderungen zu berücksichtigen. Das Spektrum der Mobilfunk-Basisstationen etwa reicht heute von kleinen Femtozellen bis zu großen Basisstationen für mehrere Funkzellen. Ähnlich ist es auch bei den Radarsystemen: hier können die Hersteller ebenfalls vor der Aufgabe stehen, große und kleine Geräte zu unterstützen.

Vereinfachung des Software-Ecosystems

Ein Großteil der elementaren Software, deren Funktionalität sich von einem Endgerätehersteller zum anderen kaum unterscheidet, wird häufig von den Multicore-SoC-Entwicklern beigesteuert und bereits integriert. Es geht hier neben den Gerätetreibern auch um Portierungen von Echtzeit-Betriebssystemen (RTOS) und wichtige standardisierte Algorithmen für die jeweiligen Ziel-Applikationen.

Wird diese Software korrekt implementiert, macht sie den Chip für die Applikationsentwickler vollständig verfügbar und rüstet ihn für die Produktion. Auf der Basis dieses Multicore-SoC realisieren die Anbieter ein Entwicklungs-Ecosystem, um Hilfestellung bei der Applikationsentwicklung, dem Test und dem Leiterplattendesign zu leisten.

Für die Entwickler wird die Multicore-Lösung zu einer Herausforderung, sobald es an das Schreiben des Codes für die Multicore-Umgebung geht. Dies gilt insbesondere dann, wenn der Applikations-Code skalierbar, d.h. für große und kleine Geräte geeignet sein soll. Die Hardware muss dann ebenso wie die Software über ein ganzes Spektrum von Bausteinen skaliert werden können, deren Core-Anzahl und Beschleuniger-Bestückung stark variieren kann.

Multicore-Software für Multicore-Bausteine

Angesichts der Komplexität der Software und der wechselnden Verarbeitungselemente der Multicore-SoCs ist es ein Glücksfall, dass es inzwischen „Hardware Facilitated Software“ gibt. Neue und für ein einfacheres Design von Multicore-Software ausgelegte Hardware ist mittlerweile in die neueste Generation von Multicore-Bausteinen eingebettet. Diese Hardware ermöglicht das automatische Skalieren der Software für den Einsatz auf einer ganzen Palette von Bausteinen, die aus einer gemeinsamen Architektur hergeleitet sind.

Die Nutzung hardwaregestützter Software ist möglich, wenn die Software nicht als ein großer monolithischer Block angelegt ist, sondern sich vielmehr aus einer Vielzahl kleiner Tasks zusammensetzt, und wenn die Hardware für ein autonomes Management dieser Tasks konzipiert ist. Ein innovatives Konzept, diese Herausforderung zu bewältigen, bedient sich groß angelegter Hardware-Warteschlangen. Diese sind mit Funktions-Deskriptoren verknüpft, die die benötigten Verarbeitungsressourcen in allgemeiner Form identifizieren.

Es wird also nur generell formuliert, dass beispielsweise DSP- oder FFT-Funktionalität benötigt wird, anstatt speziell den DSP-Core 2 zu referenzieren. Eine Task und ihre Daten werden also in die Warteschlange gelegt, von wo aus die Hardware die Verarbeitung autonom koordiniert. Der Wechsel von einem 2-Core-SoC auf ein 8-Core-SoC erfordert somit keine Änderungen an der Software, denn das Queuing- und Deskriptor-System koordiniert diesen Wechsel automatisch.

Umfangreich und flexibel: Das Softwarekonzept

Bestehende und neue Applikationen werden nach einer unterschiedlichen Nutzung der Verarbeitungselemente und Cores verlangen. Während einige Anwendungen die einzelnen Cores jeweils für sich nutzen werden, können andere Applikationen ein Verarbeitungselement als Master definieren, dem die anderen Elemente als Slave untergeordnet sind. Als dritte Variante können alle Verarbeitungselemente als gleichrangige Instanzen behandelt werden, denen die Tasks dynamisch zugewiesen werden. Einige Applikationen werden den Baustein außerdem möglicherweise – mithilfe von Standards wie OpenCL oder OpenMP – als High-Performance-Computer-Engine (HPC) nutzen wollen.

Um diesen vielfältigen Applikationsanforderungen zu entsprechen, benötigen die Designer ein Entwicklungs-Toolkit, das die grundlegende Software, die Entwicklungswerkzeuge und ein Betriebssystem für die verschiedensten Anwendungen umfasst. Die Entwicklung dieses Toolkits sollte mit den Fortschritten bei den Halbleiterbausteinen verzahnt werden, um einen optimierten Zugriff auf die Verarbeitungs-Cores, die Beschleuniger und die mehreren Konnektivitäts-Ebenen zu gewährleisten, die von den Applikationsentwicklern genutzt werden.

Fortschrittlichere SoC-Entwickler setzen ohnehin bereits auf Eclipse-basierte Tools, die es den einzelnen Entwicklern der Kunden erlauben, sich ihre Entwicklungsumgebung auf eigene persönliche Vorlieben zuzuschneiden. Eclipse-basierte Tools verbinden die besten Merkmale einer offenen Entwicklungsplattform mit den Optimierungen, die im Idealfall vom Halbleiterentwickler geboten werden.

* * Tom Flanagan ist Director Technical Strategy bei der Multicore and Wireless Base Station Infrastructure Business Unit; Sanjay Bhal ist Strategic Marketing Manager in der Multicore and Media Infrastructure Business Unit; John Warner ist Director Multicore and Media Infrastructure Business Unit, Texas Instruments.

(ID:30587080)