Die von Enclustra entwickelte FPGA-Manager IP-Lösung implementiert die gesamte Kommunikation zwischen einem Host-PC und einem FPGA.

Die von Enclustra entwickelte FPGA-Manager IP-Lösung implementiert die gesamte Kommunikation zwischen einem Host-PC und einem FPGA. Enclustra

Eck-Daten

Bei der FPGA-Manager IP-Lösung wird im FPGA ein IP-Core eingebaut, der mit einer mitgelieferten Software-Bibliothek auf Host-PC-Seite kommuniziert. Dadurch kann aus der Host-PC-Software einfach auf Register im FPGA zugegriffen werden. Es lassen sich auch Datenströme in beide Richtungen übertragen, ohne dass der Benutzer sich zum Beispiel um Protokolle kümmern muss.

FPGAs werden für immer mehr Produkte eingesetzt, deren Vorgänger-Generation noch mit Mikroprozessoren oder DSPs realisiert wurde. Beispiele dafür sind etwa Motorensteuerungen, 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 Mikroprozessor gestü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 Firma Enclustra in diversen Projekten bereits als erfolgreich erwiesen.

Übliche Prototyping-Probleme in FPGA-Projekten

 Mikroprozessoren und DSPs arbeiten sequentiell und werden größtenteils in den meisten Applikationsspezialisten bekannten Programmiersprachen C/C++ programmiert. FPGAs arbeiten dagegen von Haus aus hochgradig parallel, die Designs werden meist in HDL (VHDL oder Verilog) beschrieben und darüber hinaus ist der Entwicklungs-Flow 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 Implementationsspezialist hinzugezogen werden. Das kostet nicht nur wertvolle Zeit, sondern führt auch zum Risiko von Missverständnissen zwischen den beiden beteiligten Entwicklern.

  • Debugging-Möglichkeiten. Um ein Problem im Programmcode eines Prozessors aufzuspüren, kann dieser an beliebigen Stellen (Breakpoints) angehalten und der Source-Code Schritt für Schritt ausgeführt werden (Single Stepping), und auch der Zustand beliebiger Variablen kann jederzeit ausgelesen werden. All diese Möglichkeiten bieten FPGAs nicht. Natürlich kann man einen Logikanalysator 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 Development. 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 Kompilieren eines neuen FPGA-Bitstreams 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.

Seite 1 von 212