Altera FPGAs in embedded Anwendungen

Bob Blake, Altera: »Bei Motor-Steuerungen kann ein Design auf Basis eines FPGAs einfach an die spezifische Anwendung wie Motorleistung, -typ oder Regel-Algorithmus angepasst werden.«
Bob Blake, Altera: »Bei Motor-Steuerungen kann ein Design auf Basis eines FPGAs einfach an die spezifische Anwendung wie Motorleistung, -typ oder Regel-Algorithmus angepasst werden.«

Der Erfolg der programmierbaren Logik macht auch nicht vor embedded Anwendungen halt. Wir sprachen mit Bob Blake, Product and Corporate Marketing Manager bei Altera Europe, über die Aktivitäten des Unternehmens im Embedded Bereich und welche Faktoren zum Erfolg beitragen beziehungsweise hier vielleicht noch als Hemmschuh wirken.

Markt&Technik: Altera setzt im Rahmen seiner Embedded Initiative auf drei Cores: ARM als Hard-Core-Variante, MIPS und NIOS II als Soft-Core. ARM ist in der Controller-Welt und damit in einer Vielzahl von embedded Anwendungen eine wichtige Prozessortechnologie, womit leicht zu erklären ist, warum Altera in seiner embedded Initiative auf ARM nicht verzichten wollte. Aber warum hat Altera auch MIPS als Option gewählt, zumal Altera mit Nios II selbst über einen eigenen Soft-Core verfügt?

Bob Blake: ARM, MIPS, PowerPC und x86, das sind alles führende Prozessorarchitekturen im embedded Bereich. Dass sich mittlerweile eine Konsolidierung auf diese vier Cores abzeichnet, liegt vor allem daran, dass die Software allgemein verfügbar ist und leicht wieder verwendet werden kann. Damit Altera in diesem Bereich also erfolgreich sein kann, ist es wichtig, dass wir unsere Kunden bei möglichst vielen dieser Cores unterstützen. Aber natürlich auch mit unserem NIOS II, denn auch dieser Core erfreut sich weiterhin zunehmender Beliebtheit.

Somit haben unsere Kunden die Möglichkeit, sich den für ihre Applikation besten Core auszusuchen und gleichzeitig eine allgemeingültige FPGA-Plattform und allgemeingültigen Tool-Flow zu nutzen.
Und mit Blick auf MIPS kann ich nur sagen: Mit dem MP32-Core können die Entwickler auf das gesamte MIPS-Ecosystem an Tools, Betriebssystemen und Legacy-Code zurückgreifen. Denn auch wenn unser NIOS II als Soft-Core viele Vorteile hat, kann er nicht alle Anforderungen unserer MIPS-Kunden erfüllen, das gilt besonders mit Blick auf die unterstützten Betriebssysteme.

In 50 Prozent aller embedded Anwendungen kommt neben einem DSP/Controller auch ein FPGA zum Einsatz. Ein FPGA kann mittlerweile dank kleinster Prozessstrukturen viele Funktionen ausführen, die typischerweise vom DSP/Controller ausgeführt wurden, manchmal sogar noch etwas effizienter. Inwieweit ist Legacy-Software dafür verantwortlich, dass das FPGA nicht die gesamte Funktion übernimmt und den Controller/DSP einfach komplett ersetzt?

Viele Kunden sind sich der Vorteile von FGPAs in DSP-Applikationen durchaus bewusst. Und natürlich können FPGAs gewöhnlich auch die komplette Applikation übernehmen - das gilt besonders für Anwendungen im Datenpfad. Die Herausforderung besteht aber darin, wie man diesen Vorteil nutzen kann. Legacy-Code oder zumindest die Kosten während der Entwicklungszeit und das Risiko, das die Übersetzung des Legacy-Codes in FPGA-Logik mit sich bringt, war bislang immer eine große Herausforderung.

DSP-Designer entwickeln auf unterschiedliche Art und Weise ihren Code - ein Teil nutzt Modell-basierende Flows, ein anderer Teil entwickelt C-Code. Hier gibt es aber mittlerweile EDA-Tools, mit denen sich die Kosten der Code-Portierung auf ein FPGA reduzieren lassen. In diesem Zusammenhang sei nur auf die vielen Tools verwiesen, die C in HDL-Code übersetzen und die qualitativ durchaus hervorragende Ergebnisse erzielen. Aber auch der Flow von Mathworks, um aus Simulink heraus Code für FPGAs zu generieren, wird sowohl von den FPGA-Herstellern als auch von den EDA-Partnern unterstützt.

Trotzdem was glauben Sie: Wie oft entscheiden sich die Entwickler, ein FPGA nur für I/O-Erweiterungen zu nutzen und damit nicht den DSP/Controller zu ersetzen, nur weil sie ihre bereits geschriebene Software weiterverwenden wollen?

Wenn der Entwickler kein überzeugendes Argument hat, warum er auf ein FPGA umsatteln soll, dann wird er sehr wahrscheinlich bei seinem DSP bleiben. Aber wir sehen immer mehr Kunden, die sich einen Wechsel überlegen. Denn sie erkennen die Vorteile der FPGAs mit Bezug auf Power, Leistung, Kosten und Integration. Hinzu kommen noch neue Märkte. Auch hier gilt: FPGAs werden in Betracht gezogen, wo früher DSPs die einzige Option war. Ein Beispiel dafür sind Motorsteuerungen. Noch einmal: Schlussendlich ist es wichtig, den Tool-Flow bereitzustellen, mit dem der Wechsel vernünftig machbar ist.

Und den gibt es ja schon, oder?

Allerdings! Hier gibt es mittlerweile eine ganze Reihe von Tools. Wenn ein Kunden sein System mit Matlab und Simulink auf Basis eines Block-basierenden Flows entwickelt hat, dann gibt es sowohl von den FPGA-Herstellern als auch von unseren Partnern wie Mathworks und Synopsys Tools, mit denen diese Blöcke in HDL umgesetzt werden können. Der DSP Builder von Altera erzeugt automatisch HDL-Code und zwar mit dem richtigen Maß an Pipelining und Time-Division-Multiplexing, um die auf Systemebene gesetzten Werte für die maximale Frequenz und Latenzzeiten zu erreichen.

Entwickelt ein Kunde in C, dann gibt es eine Vielzahl von Partnern, mit deren Tools die in C geschriebenen Algorithmen sehr gut in Code für FPGAs übersetzt werden kann. Damit werden wirklich gute Ergebnisse erzielt und das innerhalb sehr kurzer Entwicklungszeiten.