Prototyping von Signalverarbeitungs- und Kommunikationsalgorithmen auf FPGAs unter Einsatz von Model-Based Design

FPGAs werden zunehmend in vielen Rüstungs- und Luftfahrtanwendungen eingesetzt, da sie Signale mit hoher Bandbreite und hoher Datenrate mit einem hohen Maß an Zuverlässigkeit und Flexibilität verarbeiten können. Radarsysteme, Satelliten und andere Signalverarbeitungssysteme verwenden beispielsweise FPGAs. Trotz ihrer Popularität ist die Entwicklung von FPGAs zeitaufwändig und erfordert Spezialkenntnisse in den Bereichen Entwicklung und Verifikation. Am aufwändigsten ist dabei die Verifikation des Designs.

Ingenieure, die in der Chipentwicklung und -verifikation tätig sind, schreiben oft 10 Zeilen Prüfstandcode für jede Zeile HDL-Code (Hardware Description Language), der in Siliziumchips implementiert wird. Der Entwicklungszyklus besteht zu mindestens 50 % aus Verifikationsaufgaben. Trotz dieses hohen Aufwands weisen fast 60 % der Chips beim ersten Durchlauf funktionale Mängel auf und erfordern einen weiteren Entwicklungszyklus [1].

Chipentwickler haben erkannt, dass die HDL-Simulation allein nicht ausreicht, um Fehler auf Systemebene zu erfassen. Aus diesem Grund setzen sie FPGAs zur Algorithmusbeschleunigung und Erstellung von Prototypen ein. Jedoch empfiehlt es sich nicht, voreilig FPGA-Prototypen eines Entwurfs im Labor zu erstellen ohne vorher Simulationen auf Systemebene und HDL-Simulationen durchgeführt zu haben. Studien zeigen, dass die Ermittlung der Ursache von funktionalen Fehlern im Labor bei einfachen Entwürfen mehr als 5 Stunden dauern kann, bei komplexen Entwürfen sogar mehr als 30 Stunden [2]. Es ist offensichtlich, dass es einer kosteneffizienten, optimierten, zuverlässigen und wiederholbaren Methode zur Erstellung von FPGA-Prototypen bedarf. Model-Based Design bietet eine solche Methode. Dabei kommen die in Abbildung 1 dargestellten vier empfohlenen Verfahren zur Anwendung. Diese sind:

1. Modellierung und Simulation zur Optimierung auf Systemebene
2. Automatische Erzeugung von lesbarem, rückverfolgbarem HDL-Code zur Erstellung von FPGA-Prototypen
3. Wiederverwendung von Testbenches auf Systemebene mit Kosimulation zur HDL-Verifikation
4. Regressionstests mit Nutzung von FPGA-in-the-Loop-Simulationen

Warum Prototyping auf FPGAs?

Mit dem Prototyping von Algorithmen auf FPGAs kann man sicherstellen, dass sich der Algorithmus in der Praxis erwartungsgemäß verhält. Zusätzlich zur Ausführung von Testvektoren und Simulationsszenarien mit hoher Geschwindigkeit können FPGA-Prototypen dazu genutzt werden, um das Zusammenspiel zwischen den im FPGA implementierten Algorithmen, Softwarefunktionalität und weiteren Komponenten auf Systemebene (z. B. RF und analoge Subsysteme) zu testen. Darüber hinaus ermöglicht die Berechnungsgeschwindigkeit von FPGAs, dass größere Datensätze verwendet werden können. Möglicherweise können auf diese Weise Fehler identifiziert werden, die von einem Simulationsmodell allein nicht entdeckt werden würden.

Model-Based Design mit HDL-Codegenerierung ermöglicht Entwicklern die effiziente Erstellung von FPGA-Prototypen, wie in Abbildung 2 dargestellt. Abbildung 2 unten, „Manuelle HDL Codierung“, veranschaulicht die gängige Praxis der Entwickler, die Phase des detaillierten Entwurfs abzukürzen, um früher mit der Hardwareentwicklungsphase zu beginnen. Sie versprechen sich durch diese Vorgehensweise, dass sie dadurch die Projektzeitplanung einhalten zu können. In der Praxis bedeutet dies jedoch, dass die Entwickler während der HDL-Erstellung wieder zur Phase des detaillierten Entwurfs zurückkehren müssen, wenn sie feststellen, dass der Festkomma-Algorithmus die Systemanforderungen nicht erfüllt. Durch dieses iterative Vorgehen verlängert sich aber die Phase der HDL-Erstellung, wie durch das lange lila Balkensegment dargestellt. Diese führt möglicherweise zu Kompromissen in der Entwicklung (z. B. Glue Logic oder Entwurfs-Patches).

Da die automatische Erzeugung von HDL-Code nicht so viel Zeit in Anspruch nimmt wie die manuelle Codierung, hat man dadurch in der Phase des detaillierten Entwurfs mehr Zeit, um qualitativ hochwertige Festkomma-Algorithmen zu entwickeln. Wie in Abbildung 2 oben, „Model-basierter Entwurf“, dargestellt, können mit dieser Methode qualitativ hochwertige FPGA-Prototypen schneller erstellt werden als mit einem manuellen Arbeitsablauf [3].

Beispiel: Digitaler Abwärtsumsetzer (DDC)

Zur Darstellung der bevorzugten Verfahren für FPGA-Prototyping unter Verwendung von Model-Based Design wird ein digitaler Abwärtsumsetzer (DDC) als Beispiel verwendet. Ein digitaler Abwärtsumsetzer (DDC) ist ein gebräuchlicher Baustein in vielen Radarempfängern (Abbildung 3). Er wird dazu verwendet, die hohe Abtastfrequenz des Übertragungsbands auf eine niedrigere Abtasfrequenz des Basisbands umzusetzen, welche mit niedrigeren Taktfrequenzen verarbeitet werden kann. Folglich sind für die Hardwareimplementierung eine geringere Leistung und weniger Ressourcen erforderlich.

In Abbildung 4 sind die Hauptkomponenten eines DDC dargestellt:

• Numerisch kontrollierter Oszillator (NCO)
• Mischer
• Digitale Filterkette

Empfohlenes Verfahren 1: Modellierung und Simulation zur Optimierung auf Systemebene

Leistungsstärkere Systeme lassen sich erzielen, wenn Zeit für die Entwicklung von Algorithmen unter Verwendung der Modellierung und Simulation auf Systemebene vor Auswahl einer Architektur investiert wird. Die Arbeit auf einer hohen Abstraktionsebene ermöglicht es, mehrere Alternativen von Algorithmen und Architekturen hinsichtlich der spezifizierten Anforderungen an den Entwurf zu bewerten.

Die Ingenieure können beispielsweise die Auswirkungen einer Festkomma-Quantisierung in einem frühen Stadium des Entwicklungsverfahrens analysieren und die Wortlänge optimieren, um kleinere und energieeffizientere Implementierungen zu erzielen.

Normalerweise testen Ingenieure neue Ideen und entwickeln erste Algorithmen unter Verwendung von Gleitkomma-Datentypen. Eine Hardware-Implementierung in FPGAs und ASICs erfordert aber eine Umstellung auf Festkomma-Datentypen, die oft zu Quantisierungsfehlern führt. In einem manuellen Arbeitsablauf wird eine Festkomma-Quantisierung normalerweise während der HDL-Codierung durchgeführt. Dabei können die Effekte der Festkomma-Quantisierung nicht einfach durch den Vergleich einer Festkomma-Darstellung mit einer Gleitkomma-Referenz gemessen werden. Es ist ebenfalls nicht leicht, eine HDL-Implementierung hinsichtlich Überläufe zu analysieren.

Um intelligente Entscheidungen in Bezug auf die erforderliche Anzahl der Nachkommastellen zu treffen, muss ein Weg gefunden werden, Gleitkomma-Simulationsergebnisse mit Festkomma-Simulationsergebnissen zu vergleichen, bevor mit der HDL-Codierung begonnen wird.

In Abbildung 5 sind beispielsweise die Unterschiede zwischen den Ergebnissen einer Festkomma- und Gleitkomma-Simulation für die erste Stufe des Tiefpassfilters in der DDC-Filterkette dargestellt. Diese Unterschiede beruhen auf der Festkomma-Quantisierung. In der oberen Abbildung ist eine Überlagerung der Gleitkomma- und Festkomma-Simulationsergebnisse dargestellt. Die untere Abbildung zeigt den Quantisierungsfehler an jedem Punkt der graphischen Darstellung.

Je nach Designspezifikationen muss die Anzahl der Nachkommastellen gegebenenfalls erhöht werden, um die Quantisierungsfehler zu verringern. Der reduzierte Quantifizierungsfehler führt jedoch zu einer Erhöhung der Wortlänge. Dies hat negative Auswirkungen auf die Flächeneffizienz und den Energieverbrauch. In anderen Fällen kann möglicherweise die Anzahl der Nachkommastellen (und die gesamte Datenwortlänge) reduziert und damit die Flächeneffizienz und den Energieverbrauch optimiert werden. Folglich spielen die richtige Anzahl der Nachkommastellen und Datenwortlänge beim Erreichen der in den Systementwurfsspezifikationen definierten Zielen eine wichtige Rolle. Abbildung 6 veranschaulicht beispielsweise, dass die Wortlänge aufgrund der Festkomma-Optimierung um 6 Bit reduziert werden konnte.

Empfohlenes Verfahren 2: Automatische Erzeugung von lesbarem, rückverfolgbarem HDL-Code für die Erstellung von FPGA-Prototypen

Verilog und VHDL sind Standard-HDLs, die für die Entwicklung von FPGAs verwendet werden. Für den überwiegenden Teil der FPGA-Entwürfe wird handgeschriebener HDL-Code verwendet. Es stehen nun Mittel zur automatischen Generierung von HDL-Code aus Systemmodellen auf hoher Abstraktionsebene bereit. Die automatische Generierung von HDL-Code bietet einige wesentliche Vorteile, wie z.B.:

• Schnelle Beurteilung, ob der Algorithmus in der Hardware implementiert werden kann
• Schnelle Beurteilung verschiedener Implementierungen von Algorithmen und Auswahl der effizientesten Alternative
• Schnelles Prototyping der Algorithmen auf FPGAs

Bei High-Integrity und Mission-kritischen Anwendungen, z. B. solche, für die eine DO-254-Zertifizierung erforderlich ist, muss geprüft werden, ob die Hardwareimplementierung den Anforderungen auf Systemebene entspricht. Um dieses Verifikationsniveau zu erreichen, muss es möglich sein, den HDL-Code zum Modell auf Systemebene und zur ursprünglichen Spezifikation auf Systemebene, die das Modell repräsentiert, rückzuverfolgen. In unserer Fallstudie ist der generierte HDL-Code lesbar und rückverfolgbar auf das Quellmodell, das mit der textuellen Spezifikation auf Systemebene (Abbildung 7) verknüpft werden kann.

In dem DDC-Beispiel wurden innerhalb einer Minute fast 5800 HDL-Code-Zeilen mit Hyperlinks generiert, welche die Rückverfolgbarkeit zwischen Modell und Code ermöglichen. Die automatische Generierung von HDL-Code stellt mehr Zeit zur Verfügung, um schnell und iterativ das richtige Systemmodell zu entwickeln und um den für die Anwendung passenden FPGA-Prototypen zu erstellen.

Empfohlenes Verfahren 3: Wiederverwendung von Testbenches auf Systemebene mit Kosimulation zur HDL-Verifikation

HDL-Kosimulation erlaubt die Wiederverwendung von Systemmodellen, um Eingangsstimuli an den HDL-Simulatoren zu übergeben und interaktiv eine Analyse der Simulationsergebnisse auf Systemebene durchzuführen (Abbildung 8)

Während eine HDL-Simulation nur einen zeitlichen Verlauf der digitalen Signale des in HDL implementierten Algorithmus bereitstellt, bietet eine HDL-Kosimulation sowohl eine vollständige Einsicht in die jeweiligen Signale des HDL-Codes sowie den Zugang zu den Analysetools auf Systemebene. Mittels der Kosimulation kann beurteilt werden, welche Auswirkungen die Unterschiede zwischen erwarteten Ergebnissen und der HDL-Simulation auf den Entwurf auf Systemebene haben.

Die in Abbildung 9 beispielsweise dargestellte Spektralansicht erlaubt eine fundierte Entscheidung darüber, ob Unterschiede zwischen erwarteten Ergebnissen und Ergebnissen der HDL-Simulation verworfen werden können, weil sich die Differenzen z.B. im Sperrbereich befinden und deshalb keine Auswirkung auf die Leistungsfähigkeit des Systems haben. Beim Bit- und Zyklen-genauen Vergleich zwischen den zeitlichen Signalverläufen des zu erwartenden Ergebnisses und des Ergebnisses der HDL Kosimulation werden jegliche Unterschiede als Fehler markiert. Mit der HDL-Simulation allein mag der Ingenieur letztendlich zur gleichen Schlussfolgerung kommen, aber es würde mehr Zeit in Anspruch nehmen, die erforderliche Analyse abzuschließen.

Empfohlenes Verfahren 4: Regressionstests mit Nutzung von FPGA-in-the-Loop-Simulationen

Nachdem der DDC-Algorithmus mit Simulationen auf Systemebene und mittels HDL-Kosimulationen verifiziert wurde, kann er nun auf einer FPGA-Zielplattform implementiert werden. Eine FPGA-basierte Verifikation des Algorithmus, die auch als FPGA-in-the-Loop-Simulation bezeichnet wird, erhöht die Wahrscheinlichkeit, dass der Algorithmus in der Praxis funktionieren wird. Testszenarien können schneller durchspielt werden als mit der hostbasierten HDL-Simulation.

Für den DDC-Algorithmus wird das Systemmodell verwendet, um Eingangsstimuli an den FPGA zu übertragen und die durch den FPGA berechneten Ausgangssignale zu analysieren (Abbildung 10). Wie in der HDL-Kosimulation sind die Ergebnisse zur Analyse stets im Systemmodell verfügbar.

In Abbildung 11 werden die zwei Verifikationsmethoden verglichen, die für die DDC-Entwicklung verwendet werden: HDL-Kosimulation und FPGA-in-the-Loop-Simulation.

In diesem Fall war die FPGA-in-the-Loop-Simulation 23 mal schneller als die HDL-Kosimulation. Solche hohen Geschwindigkeiten ermöglichen es, umfassendere Testfälle durchzuspielen und die Entwürfe Regressionstests zu unterziehen. Folglich können sie potentielle Problemfelder identifizieren, die einer weiteren, genaueren Analyse bedürfen.

Die HDL-Kosimulation ist zwar langsamer als die FPGA-in-the-Loop-Simulation, bietet aber eine umfassendere Einsicht in den HDL-Code. Sie ist demnach besser für eine detailliertere Analyse von Problemfeldern geeignet, die während der FPGA-in-the-Loop-Simulation gefunden werden.

Zusammenfassung

Die Entwicklung kosteneffizienter, zuverlässiger und skalierbarer Systeme ist eine wesentliche Anforderung für Ingenieure, die in den Bereichen Luftfahrt und Rüstung tätig sind. Da FPGAs aktuell in vielen datenintensiven, funktionskritischen Anwendungen innerhalb dieser Systeme zum Einsatz kommen, können Ingenieure den in diesem Dokument beschriebenen Entwicklungsablauf für FPGA-basierte integrierte Algorithmen verwenden, um diese Ziele zu erreichen. Mit den vier empfohlenen Verfahren können Ingenieure FPGA-Prototypen viel schneller und zuverlässiger entwickeln. Durch die Automatisierung fehleranfälliger manueller Methoden können Ingenieure schneller Entwurfsiterationen ausführen und die Entwicklungskosten senken.

References

[1] "Hardware/Software Coverification," Dr. Jack Horgan, EDACafé Weekly, March 29, 2004
[2] FPGA Journal FPGA Design Best Practices Survey, 2010
[3] Semtech Speeds Development of Digital Receiver FPGAs and ASICs