Algorithmen testen Matlab-Prototypen für FPGA-Systeme

FPGA-Systeme auf Matlab-Basis
FPGA-Systeme auf Matlab-Basis

FPGAs bieten enorme Rechenleistung. Allerdings sind sie viel schwerer zugänglich sind als Prozessoren, die in C und C++ programmiert werden können. Mit Prototyping auf Matlab-Basis ist aber ein Ausweg aus diesem Dilemma möglich.

FPGAs werden für immer mehr Produkte eingesetzt, deren Vorgänger-Generation mit Mikroprozessoren oder DSPs realisiert wurde. Beispiele dafür sind etwa Motorsteuerungen, Messgeräte und Software-Defined-Radio- (SDR) Anwendungen. Der Einsatz der neuen Technologie bedeutet aber nicht nur die Verfügbarkeit von mehr Rechenleistung bei weniger Leistungsaufnahme, sondern auch, dass sich ganze Entwicklungsteams mit einer völlig neuen Technologie auseinandersetzen müssen. Zuletzt war das beim Umstieg von hauptsächlich analoger Elektronik zu mehrheitlich mikroprozessorgestützten Systemen der Fall. Genau wie damals sind auch heute bei einem anstehenden Technologie-Wechsel grundlegende Änderungen an den Entwicklungsprozessen nötig, um die neuen Möglichkeiten effizient zu nutzen. Matlab-basiertes Prototyping stellt hier zwar nicht die einzig richtige Patentlösung dar, sondern ist lediglich ein möglicher Ansatz, um FPGA-Systeme effizient und risikoarm zu entwickeln – doch dieser Ansatz hat sich bei der Enclustra GmbH in diversen Projekten bereits als erfolgreich erwiesen.

Übliche Prototyping-Probleme in FPGA-Projekten

Mikroprozessoren und DSPs arbeiten sequenziell und werden meistens mit C/C++ programmiert. FPGAs arbeiten dagegen von Haus aus hochgradig parallel. Die Designs werden meist in einer Hardware-Beschreibungssprache (VHDL oder Verilog) beschrieben und darüber hinaus ist der Entwicklungsablauf für FPGAs völlig anders als bei herkömmlicher Software. Diese Unterschiede führen zu erheblichen Problemen beim Prototyping/Debugging:

  • Zugänglichkeit: Während praktisch alle Applikationsspezialisten C/C++ genügend gut beherrschen, um Änderungen schnell und effizient direkt auf der Hardware zu testen, kennen sich nur die wenigsten von ihnen auch mit der Implementierung von FPGA-Designs aus. Deshalb muss normalerweise für jede Änderung ein Implementierungsspezialist hinzugezogen werden. Das kostet nicht nur wertvolle Zeit, sondern führt auch zum Risiko von Missverständnissen zwischen den beiden beteiligten Entwicklern.
  • Debugging: Um ein Problem im Programmcode eines Prozessors aufzuspüren, kann dieser an beliebigen Stellen (Breakpoints) angehalten und der Quellcode Schritt für Schritt ausgeführt werden (Single Stepping). Auch der Zustand beliebiger Variablen kann jederzeit ausgelesen werden. All diese Möglichkeiten bieten FPGAs nicht. Natürlich kann man Logik-Analysatoren ins FPGA-Design einbauen, um Daten aufzuzeichnen; allerdings sind diese in Bezug auf die Speichertiefe oft sehr eingeschränkt. Erschwerend kommt hinzu, dass die aufgezeichneten Daten oftmals nicht einfach zu interpretieren sind, da mehrere Kanäle parallel verarbeitet werden oder nicht der gesamte Zustand der Schaltung auf einmal erfasst werden kann.
  • Agile Entwicklung: Embedded-Software wird heute normalerweise agil entwickelt. Dafür sind schnell ausführbare, automatisierte Unit Tests sowie kurze Durchlaufzeiten von der Idee bis zum Test auf der Hardware unabdingbar. Der FPGA-Design-Flow ist diesen Ideen genau entgegengesetzt: Simulationen dauern eine lange Zeit, und selbst wenn eine Änderung schnell implementiert sein sollte, dauert das Compilieren eines neuen FPGA-Bitstream für Tests auf der Hardware oft mehrere Stunden.

Je nach Gegebenheiten lassen sich einige dieser Probleme zum Beispiel durch die Generierung von VHDL-Code aus C/C++ oder Matlab/Simulink umgehen. Erfahrungen aus realen Projekten haben allerdings gezeigt, dass die Code-Generierung nur einen Teil der Probleme löst – und das auch nur, wenn dieser Ansatz überhaupt eingesetzt werden kann.

Das Hauptziel von Matlab-Prototypen ist es, den Applikationsspezialisten so weit wie möglich von der FPGA-Implementierung abzuschirmen. Das wird einerseits dadurch erreicht, dass Änderungen schnell und einfach getestet werden können, bevor der Aufwand der tatsächlichen Implementerung in Angriff genommen wird. Andererseits sollen auch Messungen mit der tatsächlichen Hardware einfach und ohne spezielle FPGA-Kenntnisse möglich sein.