Fünf gute Gründe für FPGA-Prototyping

Xilinx/Synopsys

Prototyping ist kein Prozess, der auf Knopfdruck funktioniert. Es erfordert vielmehr eine sorgfältige Betrachtung aller Umstände, um nutzbringend eingesetzt zu werden. Im Gespräch mit Entwicklern, die Prototypen schaffen und erfolgreich einsetzen, taucht daher immer wieder die Frage auf: „Warum macht ihr das?“. Darauf gibt es viele Antworten, die sich aber in fünf Nutzenkategorien gemäß Tabelle 1 zusammenfassen lassen. So kann beispielsweise „Test des Einflusses realer Daten aus der Einsatzumgebung“ auf ein Entwicklerteam zutreffen, das sich mit Hilfe eines Prototyps das Modell ihres künftigen Systems schaffen will, das mit anderen Systemen oder Peripheriegeräten zusammenarbeiten soll, um dessen Übereinstimmung mit einem speziellen neuen Schnittstellenstandard zu prüfen. Der Nutzen des Prototyping ist hier die „Echtzeit-Schnittstelle zur realen Einsatzumgebung“. In der Tat bietet Prototyping den schnellsten Weg dahin, bevor dafür einsatzfähiges Silizium überhaupt existiert.

Tabelle 1: Die fünf Gründe für FPGA-Prototyping.Xilinx/Synopsys

Ein strukturelles Verständnis der Projektziele und des möglichen Prototyping-Nutzens kann dabei helfen, sicher abzuschätzen, ob ein FPGA-Prototyping für das nächste Projekt vorteilhaft eingesetzt werden kann. Die nachfolgend beschriebenen Beispiele geben dazu Anregungen.

Starke Leistungsmerkmale und Genauigkeit

Nur FPGA-basierte Prototypen bieten die Geschwindigkeit und Genauigkeit, um viele Aspekte eines Designs zu testen. Deshalb steht dieser Grund an erster Stelle und betrifft beispielsweise die Validierung der eingebetteten Software eines Systems auf dem Chip (SoC), dessen Verhalten in realer Geschwindigkeit auf einer realen Hardware beobachtet wird. Die gleiche Aufgabe ließe sich auch mit einem virtuellen System lösen, allerdings mit geringerer Genauigkeit, weil der FPGA-Prototyp wesentlich zielführender mit der gleichen RTL (Register Transfer Logik) -Beschreibung des SoC läuft.

Die Funktionalität von SoCs ist nicht einfach zu verifizieren, weil ihr Zustand von vielen Variablen abhängt: vom vorherigen Zustand, der Eingangssequenz und den weiteren Systemeffekten, wie Rückkopplung, der SoC-Ausgänge. Der Betrieb eines SoC-Designs in der Zielgeschwindigkeit innerhalb des restlichen Systems erlaubt es aber, die unmittelbaren Auswirkungen von Echtzeitbedingungen, Eingängen und Systemrückkopplung bei ihrem Wechsel zu erkennen.

Bild 1: Blockschaltbild eines HDMI-Prototyps.Xilinx/Synopsys

Als sehr gutes Beispiel für einen Echtzeit-Datenfluss kann ein HDMI (High Definition Media Interface)  -Prototyp dienen, der von der IP-Gruppe von Synopsys in Porto, Portugal, entwickelt wurde (Bild 1). Ein breitbandiger Datenstrom aus Video- und Audio-Daten läuft in Echtzeit durch den Prototyp eines Verarbeitungs-Core über eine Echtzeit-HDMI-PHY-Schnittstelle zu einem hochauflösenden Monitor.

Durch den Einsatz dieses Präsilizium-Prototyps lassen sich die Effekte unterschiedlicher HD-Daten unmittelbar sehen und hören. Nur FPGA-basiertes Prototyping erlaubt den Echtzeit-Datenfluss, der nicht nur für Multimedia-Anwendungen, sondern auch für andere Applikationen vorteilhaft ist, in denen eine Echtzeit-Reaktion auf den breitbandigen Eingangsdatenstrom gefordert wird.

Bild 2: Software-Stack des Android-Betriebssystems.Xilinx/Synopsys

Während der im HDMI-Prototyp integrierte Microblaze-Mikroprozessor lediglich die Verarbeitung des Datenstroms steuert, gibt es aber noch viele SoC-Anwendungen, in denen die Software den größten Entwicklungs- und Testaufwand erfordert. Überschaubare Applikationen, wie die Türelektronik eines Fahrzeugs, lassen sich noch einfach und umfassend testen. Schwieriger wird es bei Geräten, wie etwa Smartphones, die viele Applikationen und Prozesse in Echtzeit abarbeiten müssen. Ihre Software basiert auf einer hierarchischen Struktur, wie etwa dem Software-Stack des Betriebssystems Android für mobile Geräte (Bild 2). Zur Entwicklung eines BSP (board support package), wie das vom PC her bekannte BIOS von manchen Herstellern genannt wird, sind exakte Kenntnisse der darunter liegenden Hardware-Schicht bis auf Adress- und Taktzyklus-Genauigkeit unbedingt nötig, eine Genauigkeit, die mit einem FPGA-Prototypen erreichbar ist. Die Forderung nach ausreichender Genauigkeit gilt für jede Ebene des Modells: So benötigen Programmierer von Treibern im Linux-Kernel eine BSP-Schnittstelle mit hinreichender Transparenz, unabhängig davon, ob sie von einer Ziel-Hardware oder einem Prototyp angeboten wird. FPGA-Prototypen bieten den größten Nutzen, wenn es um die Modellierung des gesamten Stack oder die Verarbeitung von Daten aus der realen Einsatzumgebung geht.

Echtzeit-Schnittstellen zur realen Einsatzumgebung

Zur Verifizierung der Funktionalität von Soft- oder Hardware-Komponenten wird ein kompletter Satz von Eingangsdaten angelegt und die jeweilige Reaktion am Ausgang beobachtet. Für individuelle Gatter ist das trivial, für kleine RTL-Blöcke gerade noch machbar und für komplette Systeme wie ein SoC, statistisch gesehen kaum mehr möglich. Durch diese unvollständige Testabdeckung können unvorhergesehene Datenkombinationen unter Umständen sehr unerwünschte Effekte hervorrufen. Die bekannten Methoden der funktionellen Simulation eines Designs, mit denen sich eine gewisse Testabdeckung erreichen lässt, können durch den Ablauf des SoC-Entwurfs auf einem FPGA-Prototyp in realer Einsatzumgebung vorteilhaft ergänzt werden. Als Beispiel dafür soll der Entwurf eines WiFi-Reichweiten-Extenders dienen, der bei DS2 in Valencia in Spanien entstand.

Breitbandübertragung über das Stromnetz BPL (broadband-over-power line) mit sehr niedrigem Sendepegel wird gerne benutzt, um beispielsweise HD-Video in einem Haus zu verteilen. Die zugehörigen BPL-Schnittstellen-Komponenten von DS2 umfassen optimierte Hardware und eingebettete Software-Algorithmen, die breitbandige Signale codieren, über das Stromnetz aussenden und empfangen und schließlich wieder decodieren. Weil sich die Verkabelung wie ein sehr stark gestörter Übertragungskanal verhält, besteht ein entscheidender Teil der Entwicklung darin, diese Algorithmen in einer breiten Vielfalt realer Einsatzumgebungen zu verifizieren. Dazu dienen zunächst unterschiedliche Kanal- und Störmodelle. Mit FPGA-Prototypen, auf denen die eingebettete Software abläuft, können die Algorithmen umfassend ausgetestet werden. Außerdem lassen sich die Prototypen leicht transportieren und außerhalb des Labors in ihrer Zielumgebung testen. Dies ermöglicht Tests mit mehreren Prototypen in realem häuslichem Ambiente und an Arbeitsplätzen, die gelegentlich an extrem gestörten Netzen hängen. Herkömmliche Emulatoren lassen sich dafür nicht einsetzen, weil sie zu teuer und nicht transportabel sind.

Universelle Anwendung im Labor

Zu Beginn eines Projekts müssen grundsätzliche Entscheidungen über Chip-Topologie, Leistungsmerkmale, Strombedarf und Kommunikationsstrukturen auf dem Chip getroffen werden. Einige davon werden am besten durch algorithmische oder Modellierungs-Tools auf Systemebene geklärt, aber für manche dürften Experimente mit FPGAs sinnvoll sein. Dabei dient die RTL-Beschreibung durch eines der Modellierungs-Tools als Grundlage der FPGA-Struktur. Damit lassen sich dann frühzeitig Informationen über eine Optimierung der Algorithmen und die vorgesehene SoC-Architektur gewinnen, weil auf diese Weise genauere Modelle entstehen, die schnell genug sind, um mit Echtzeit-Eingangssignalen umgehen zu können.

Schnelle Demos außerhalb des Labors

Chip-Architekten und andere Produktspezialisten haben oft mit Leitkunden zu tun, denen sie entscheidende Leistungsmerkmale ihrer Produkte und Algorithmen schon in einem sehr frühen Entwicklungsstadium demonstrieren müssen. Dazu gehören auch Messemodelle, anhand derer sich potenzielle Kunden einen Eindruck vom künftigen Produkt machen können. Ein sehr gutes Beispiel ist die Einführung des terrestrischen HD-Fernsehens DVB-T2 in Großbritannien durch die britische BBC. Wie die meisten internationalen Standards brauchte die technische Spezifikation von DVB-T2 Jahre bis zu ihrer Verabschiedung. Neben ihrer Mitarbeit an der Spezifikation nutzten die BBC-Forscher und Entwickler FPGA-Prototypen für die Modulatoren und Demodulatoren der neuen Fernsehnorm, die auf einer Synopsys-Platine HAPS-51 mit einem Virtex-5-FPGA von Xilinx liefen. Nur mit FPGAs war es möglich, diese Systemkomponenten zügig an den jeweiligen Status der Normung anzupassen. Dies führte dazu, dass bereits an dem Tag der Veröffentlichung der endgültigen Fassung, auch schon die ersten HD-Fernsehsendungen ausgestrahlt und empfangen werden konnten. Schneller ging es wirklich nicht.

Was FPGA-Prototyping nicht kann

Zur objektiven Sicht des FPGA-Prototyping gehört auch, die Grenzen des Verfahrens aufzuzeigen. In erster Linie ist dazu festzustellen, dass ein FPGA-Prototyp kein RTL-Simulator ist. Wenn ein Entwickler vorhat, eine Komponente in RTL zu beschreiben und sobald wie möglich in ein FPGA zu laden, um zu sehen, wie sie läuft, sollte er sein Vorgehen noch einmal überdenken, denn ihm geht dabei einiges verloren. Schließlich besteht ein Simulator aus zwei Komponenten, die sich als Motor und als Bedienkonsole beschreiben lassen: Der Motor regt das Modell an und zeichnet die Ergebnisse auf. Mit der Konsole können die Ergebnisse betrachtet und ausgewertet werden. Der Simulator lässt sich in kleinen Inkrementen betreiben und über die Konsole fein abstimmen oder mit sehr ausgeklügelten Stimuli anregen. Ein FPGA-Prototyp ist dafür weniger geeignet.

Es trifft zu, dass ein FPGA ein wesentlich schnelleres Medium für den Ablauf eines RTL-„Modells“ ist. Wird aber der Aufwand für das Einrichten dieses Modells mit betrachtet, dann ist der Geschwindigkeitsvorteil schnell dahin. Schließlich bietet die Konsole volle Kontrolle über Anregung und Darstellung der Ergebnisse. Der Versuch, ein FPGA auf dessen Funktionalität hochzurüsten, endet immer in einer sehr eingeschränkten Version dessen, was ein RTL-Simulator von Hause aus mitbringt. Der Simulator bietet damit eine wesentlich bessere Umgebung für das wiederholte Schreiben und Evaluieren von RTL-Code. Aus diesem Grunde sollte die RTL-Beschreibung einer Komponente erst dann einem FPGA-Prototyp übergeben werden, wenn die Simulation erfolgreich zu einer reifen RTL-Version geführt hat.

(jj)