Startseite > Halbleiter > Programierbare Logik > FPGA-basierte Systeme mit Altium Designer und OpenCores verifizieren

Programmierbare Logik

FPGA-basierte Systeme mit Altium Designer und OpenCores verifizieren

26. März 2013, 14:56 Uhr | Von Jörg Kaleita

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Testsystem mit NanoBoard 3000

Für das verwendete Beispiel ist zuerst einmal - wie bei jedem FPGA-Projekt in Altium - ein Schaltbild (Schematic) als Top-Level von nöten. Zur Verdrahtung und grafischen Darstellung stehen hierbei alle Methoden zur Verfügung, die das Software-Haus in mehr als 25 Jahren Leiterplattendesign entwickelt hat.

Jobangebote+ passend zum Thema

Auszubildende zum Kaufmann für Groß- und Außenhandelsmanagement (m/w/d) FR Großhandel mit dem Schwerpunkt Vertrieb

GLYN GmbH & Co. KG, Idstein

Quereinsteiger im Vertriebsinnendienst (m/w/d) für das Vertriebsbüro bei Wien

GLYN GmbH & Co. KG, Brunn am Gebirge

Field Account Manager (m/w/d) für das Vertriebsbüro in Pforzheim

GLYN GmbH & Co. KG, Pforzheim

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Demnach kann jeder, der mit Altium schon einmal eine Leiterplatte entworfen hat, mit exakt denselben Methoden auch ein FPGA entwickeln. Als erstes wird das zu prüfende Design mitsamt notwendiger Constraints als Block instanziiert und schematisch verdrahtet. Bild 2 zeigt das gesamte Projekt und das Top-Level-Schematic mit den beiden IPs von OpenCores, einem Embedded-System mit TFT und Speicher sowie einem anpassbaren, virtuellen Messinstrument, an dem alle Ein- und Ausgänge angeschlossen sind. Anwender können Funktion und Form dieser virtuellen Messinstrumente beliebig gestalten, indem sie die angeschlossenen Ein- und Ausgänge messen, darstellen oder verändern, ohne das FPGA neu zu programmieren.

Neben den frei konfigurierbaren gibt es zusätzlich auch eine vorgefertigte Bibliothek mit virtuellen Messin-strumenten, die in der jeweiligen Ziel-Hardware eingesetzt werden können. Zu diesen gehören z.B. auch die Logikanalysatoren aus den Hersteller-Tools.

Um das Embedded-System inklusive Soft-CPU zu entwerfen, wird ebenfalls ein grafisches Top-Down-Dokument erstellt. Dieses sogenannte OpenBus-Dokument wird später im Gesamtprojekt als Quelle instanziiert. In diesem Beispiel (siehe Bild 3) wird eine 32-bit-Soft-CPU (TSK32) inklusive SDRAM, eine GPIO sowie eine konfigurierbare Wishbone-Schnittstelle, ein TFT und ein weiteres virtuelles Instrument verwendet.

Die verwendete Soft-CPU-Architektur TSK3000 ist herstellerunabhängig und ebenfalls Wishbone-basierend. Die einzelnen Blöcke können aus der OpenBus-Palette platziert und miteinander verbunden werden. Diese enthalten zunächst die für das NanoBoard 3000 passende Konfiguration inklusive Pin-Informationen. Bei Verwendung einer anderen Ziel-Hardware müssen diese gegebenenfalls angepasst werden. Das OpenBus genannte Konzept basiert auf dem Wishbone-Standard, so dass beliebige - von OpenCores stammende - IPs neben den eigenen und den in Altium Designer vorhandenen IPs ohne Buskonverter direkt verwendet werden können. Für alle anderen Fälle (im vorliegenden Beispiel einfach eine 8-bit-Schnittstelle mit Steuerpin) steht eine konfigurierbare Wishbone-Schnittstelle zur Verfügung. Ebenso wird in diesem Beispiel ein Arbiter verwendet, der dem Speicher eine höhere Priorität bei gemeinsamen Zugriffen auf den verwendeten externen SRAM gewährt.

Beim Konfigurieren des Arbiters wäre auch ein abwechselnder Zugriff (Daisy Chain) eine mögliche Alternative beim Konfigurieren des Blocks. Über das GPIO werden Werte in das Embedded-System zurückgelesen und auf Doppelklick kann die Soft-CPU modifiziert werden: Einstellbar sind zum Beispiel, wie viel Speicher intern benötigt wird oder welche Signale einen Interrupt bekommen. Ebenfalls wird das automatisch erfolgte Memory Mapping grafisch dargestellt. Bis auf einige für die Systeminitialisierung notwendige Funktionen kann die Speicher-Allokation in internen oder externen Speicher flexibel aufgeteilt werden.

Altium Designer erstellt neben dem notwendigen Hardware-Mapping auch automatisch die benötigte Software für Treiber, Applikationen und sogar Services. Aus diesem Grund wird bestenfalls noch nicht einmal ein Betriebssystem benötigt, was das später vom integrierten Compiler generierte Executable schlank hält.

Der sogenannte Software Platform Builder (SPB) startet bei Verwendung eines TFTs zum Beispiel automatisch einen POSIX-Service. Im SPB wird das TFT jetzt als Standard-Output deklariert (siehe Bild 4). Anschließend reicht ein einfaches „printf“ im Quellcode, um einen Wert auf dem TFT darzustellen. Die notwendigen Header (zum Beispiel Schrift- und Displaygröße, Zeilenbreite sowie Font) sind im SPB bereits vordefiniert. Die Default-Werte stimmen hierbei mit den Bausteinen auf dem NanoBoard 3000 überein und müssen unter Umständen bei Verwendung einer anderen Ziel-Hardware angepasst werden. Deswegen generiert der SPB alle Quelltexte in C und stellt diese dem Entwickler zur weiteren Benutzung und Modifizierung kostenfrei zur Verfügung.

Die Prüfphase in dem erstellten Testsystem

Nachdem die Entwickler das Embedded-Verifikationssystem über die Hard-JTAG-Schnittstelle in das FPGA programmiert haben, erfolgt jetzt die eigentliche Interaktion zwischen dem FPGA und Altium Designer über eine zweite JTAG-Schnittstelle (Soft-JTAG). Das entworfene Embedded-System mit der Soft-CPU ermöglicht den Entwurf komplexer Test-Sequenzen in C und ist in der Lage, auf entsprechende Vorgaben zu reagieren. Bestimmte Triggerimpulse können zum Beispiel eine neue Aktion anstoßen.

Zum Entwickeln und Optimieren der Testsequenz steht ein auf Tasking- Technologie basierender, integrierter Debugger zur Verfügung. Oft finden sich die benötigten Sourcen (zum Beispiel Sinussignal oder benötigte Signalsequenz) im Internet. Eine in C geschriebene Testsequenz kann in dem gegebenen Beispiel von dem Slider-Wert aus der Script Engine überschrieben werden, indem dieser Wert mit einer Variablen verknüpft wird. Der Knopf „SW Override“ setzt eine weitere Variable, die zwischen der Sequenz und dem Slider-Wert entscheidet.

Auf diese Weise können per Drag&Drop beliebige Messinstrumente mit entsprechenden Funktionen grafisch in der gewünschten Form zusammengesetzt werden (siehe Bild 5).

Da die Script Engine parallel zur Hardware läuft, eröffnet dies flexible Möglichkeiten zur Datenerfassung von Signalen, ohne in den Signalpfad einzugreifen. Im Falle von Ethernet könnten zusätzlich ganze Pakete ausgelesen und ein Fehlerprotokoll auf den USB-Stick geschrieben werden, falls die Checksumme nicht stimmt. Mit ein paar einfachen C-Routinen sind die codierten Werte auf dem TFT-Display darstellbar. Analog zu dem Erstellen der Messinstrumente könnte übrigens auch alternativ (oder ergänzend) eine grafische Bedienoberfläche für das TFT als Schnittstelle zwischen Mensch und Maschine entwickelt werden.

Der Autor

Jörg Kaleita
studierte Fernsehtechnik an der Fachhochschule für Angewandte Wissenschaften in Wiesbaden und arbeitete anschließend als Hardware- und Software-Entwickler in der Industrie. Unter anderem war er als Field Application Engineer bei einem Hersteller für Programmierbare Logikbausteine tätig und wechselte 2008 zu seinem aktuellen Arbeitgeber, die Altium Europe GmbH, für die er als Technical Account Manager EMEA im Einsatz ist.

Jörg Kaleita

studierte Fernsehtechnik an der Fachhochschule für Angewandte Wissenschaften in Wiesbaden und arbeitete anschließend als Hardware- und Software-Entwickler in der Industrie. Unter anderem war er als Field Application Engineer bei einem Hersteller für Programmierbare Logikbausteine tätig und wechselte 2008 zu seinem aktuellen Arbeitgeber, die Altium Europe GmbH, für die er als Technical Account Manager EMEA im Einsatz ist.

joerg.kaleita@altium.com