Programmierbare Logik FPGA-basierte Systeme mit Altium Designer und OpenCores verifizieren

Programmierbare Logik/Tools
Zu frühen Projektphasen ist oft noch keine Hardware vorhanden, deshalb bietet sich hierzu das NanoBoard 3000 von Altium an.

Der Design Flow zur Erstellung elektronischer Module und Systeme erfordert zu unterschiedlichen Projektphasen eine Verifikation von Teilkomponenten bis hin zur kompletten Leiterplatte. Hierzu wird eine flexible Testumgebung benötigt.

Als Teil des Gesamtkonzepts wird eine kostengünstig verfügbare Altium-Prototypen-Plattform der NanoBoard-3000-Serie eingesetzt. Die beschriebene Vorgehensweise ist hierbei 1:1 auf eine beliebige Ziel-Hardware übertragbar und eignet sich sowohl für deren Testphase als auch deren Inbetriebnahme.

Altium Designer ist eine integrierte Entwicklungsumgebung, die Schaltplanentwurf, Leiterplattenentflechtung inklusive Integritätsanalyse, plattformunabhängige FPGA-Entwicklung, VHDL/Verilog- und SPICE-Simulation, Entwurf von Embedded-Systemen und SoCs (System on Chip), Compiler, Debugger und viele andere nützliche Testwerkzeuge unter einer grafischen Oberfläche vereint. Die Besonderheit dieser Entwicklungsumgebung ist eine konsistente Projekt-Datenbasis für alle genannten Domänen. Änderungen in einer Domäne (z.B. Pin Swapping auf dem PCB unter Verwendung der FPGA-I/Os) können - per Knopfdruck - mit den damit verknüpften Domänen „Schaltplan“ und „Leiterplatte“ synchronisiert werden.

Dem Entwickler von Embedded-Systemen stellt die Entwicklungsumgebung eine Vielzahl von gebräuchlichen IPs zur Verfügung. Das Software-Haus setzt dabei - mit seinem OpenBus genannten Ansatz auf den Bus-Standard Wishbone. Da dieses Bus-System auch von der OpenCores-Gemeinde verwendet wird, steht dem Anwender zusätzlich die Modulvielfalt der OpenCores-Designs offen. Wie später vorgestellt wird, stellt Altium Designer für die in der Software enthaltenen IPs auch Treiber, Applikations-Software und sogar Services - z.B. POSIX für generische IO-Zugriffe, Speicherdienste für USB oder einen TCP/IP Stack für Ethernet - zur Verfügung. Virtuelle Messinstrumente zur Anzeige aller Signale sowie zum manuellen Beeinflussen von bestimmten Werten werden in dieser Methode spezifisch zu den Anforderungen der Testumgebung entworfen. Wie das zu generierende Embedded-System/SoC werden diese Messinstrumente zusätzlich zum zu testenden Design in das verwendete FPGA programmiert.

Die vorgestellte Methodik benötigt demnach zwingend ein FPGA mit der entsprechenden Umgebung. Zu frühen Projektphasen ist allerdings oft noch keine Hardware vorhanden. Deshalb bietet sich hierzu das NanoBoard 3000 von Altium an. Die bestückten FPGAs bieten ausreichend Platz und viele in einem Embedded-System benötigte Bausteine (z.B. Speicher), Darstellmöglichkeiten (z.B. TFT) und Schnittstellen (z.B. USB) sowie vielfältige Möglichkeiten zur Erweiterung sind, wie in Bild 1 gezeigt, bereits enthalten.

Demo-Beispiel als Einstiegshilfe

Ein einfaches Beispiel mit der hier vorgestellten Methodik vertraut machen. Hierzu wurde ein 8B10B-Encoder und -Decoder zur gleichspannungsfreien Signalübertragung von OpenCores ausgewählt. Diese beiden IPs werden sukzessive mit einem Embedded-System inklusive Soft-CPU sowie Speichern und Schnittstellen erweitert. Außerdem werden die gesamte benötigte Software generiert sowie maßgeschneiderte virtuelle Instrumente erstellt. Überdies werden alternative Lösungsansätze sowie deren Vor- und Nachteile angesprochen.

Die Erzeugung der Signalstimuli wird im Beispiel mittels eines Embedded-Systems mit Soft-CPU realisiert. Dies mag im gewählten Beispiel auf den ersten Blick wie das sprichwörtliche „mit Kanonen auf Spatzen schießen“ erscheinen, doch liegen die Vorteile klar auf der Hand:

  • Die Anpassung und Änderung der Testmuster geschieht durch Software. Es ist dafür nicht erforderlich, das FPGA jeweils neu zu generieren. Der Vergleich zwischen Soll-Werten aus dem Datenblatt (oder Pflichtenheft) und gemessenen Ist-Werten im FPGA kann somit weitestgehend automatisiert werden.
  • Der Ansatz ist sehr flexibel, was Kommunikation und Protokollierung mit externen Komponenten betrifft. Es ist zum Beispiel denkbar, Testmuster von einem USB-Stick zu lesen oder Testresultate über Ethernet auf den PC zu übertragen. Denkbar sind auch die Ansteuerung, Messung oder Triggerung externer ICs, ganzer Schaltungen oder Geräte.
  • Oft müssen besonders selten auftretende Fehler identifiziert und beseitigt werden. Hierzu können Fehlermuster definiert werden, bei Bedarf Triggerimpulse ausgelöst und dann möglichst in Echtzeit in einen Zwischenspeicher geschrieben werden.
  • Vorgefertigte sowie frei konfigurierbare virtuelle Messinstrumente dienen als Schnittstelle zwischen Mensch und Maschinen. Wenn Zwischenspeicher verwendet wird, leistet zum Beispiel das virtuelle Speicher-Messinstrument hilfreiche DiensteSinnvoll ist es, sich das zu testende Design als eine zu verifizierende Black Box vorzustellen. Die Eingänge werden mit beliebigen Signalgeneratoren und Testsequenzen gespeist, die Ausgänge können entsprechend gemessen und mit dem erwarteten Ergebnis verglichen werden

Nachteil dieser Software-Lösung ist, dass die Geschwindigkeit der Testmuster durch die Prozessorgeschwindigkeit begrenzt wird. Ein vollständig in HDL entwickelter Stimuli-Generator würde dies vermeiden - allerdings auf Kosten eines sehr viel höheren Entwicklungsaufwandes. Dieser Ansatz ist außerdem weniger flexibel, da bei jeder Änderung das FPGA neu generiert werden muss. Altium Designer bietet in diesen Fällen einen guten Kompromiss zur Hardware-Beschleunigung: Ein integrierter C-to-Hardware-Compiler erlaubt C- sowie C++-Quelltext als Eingabe und übersetzt die sequenziellen Strukturen in die parallelen Möglichkeiten eines FPGAs. Aus Platzgründen sei hierzu auf weiterführende Dokumentation in AltiumLive verwiesen (www.live.altium.com-/?lng-=de#home).

Die Entwicklungs-Software arbeitet mit den am Markt gebräuchlichen Synthese- und Simulations-Tools zusammen. Die auch in kostenfreien Versionen vorhandenen  Place&Route-Funktionen des jeweiligen FPGA-Herstellers nehmen eine Sonderstellung ein: Altium Designer verwendet für das Platzieren und Routen der synthetisierten Logik in der jeweiligen FPGA-Zielarchitektur grundsätzlich die jeweiligen Tools des FPGA-Herstellers im Batch Mode. Diese müssen zusätzlich installiert werden. Hingegen ist eine eigene sowie herstellerunabhängige Synthese fest eingebaut. Zusätzlich ist der HDL-Simulator von Aldec zur Verhaltenssimulation im Gesamtsystem integriert. Optional können die Synthese- und Simulations-Tools der Hersteller eingesetzt werden. Zur Post-Place&Route-Timing-Simulation können Volllizenzen etablierter Simulations-Tools verwendet werden. Die TCL-Skripte, mit denen die Hersteller-Tools eingebunden werden, können modifiziert werden.

Für die beschriebene Methodik sollte man ferner davon ausgehen, dass der Entwickler mit den üblichen, streng synchronen Designregeln und Entwurfsverfahren vertraut ist und externe Signale ebenfalls konsequent synchronisiert worden sind. In diesem Fall kann man der statischen Timing-Analyse vertrauen, die - wie bereits beschrieben - das Hersteller-Tool ermittelt. Andernfalls sind oft nicht leicht zu findende Probleme, zum Beispiel durch unterschiedliche Taktdomänen oder Setup- und Hold-Zeitverletzungen, zu erwarten.

Altium erweitert den vorhandenen Funktionsumfang der Hersteller-Tools um eine grafische Top-down-Methodik: Ein Systemdesign fängt bei Altium immer auf Blockebene an, nicht auf Zeilenebene. Diese Blöcke können die von Altium, die von OpenCores oder beliebige andere sein.