Altera FPGA Konfiguration per SPI Flash im Active Serial-Modus

In meinem AmbiController-Projekt verwende ich einen Cyclone IV EP4CE6 FPGA von Altera. Da in diesem Chip kein persistenter Speicher enthalten ist benötigt dieser einen externen Speicherbaustein wie beispielsweise den EPCS16. Dieser ist jedoch recht teuer. Alternativ kann auch ein einfaches serielles SPI Flash mit z.B. 16MBit Speicher verwendet werden. Wie zum Beispiel ein MP25P16, den ich verwende. Dieser ist schaltungstechnisch identisch zum EPCS16 mit dem FPGA verbunden uns wird per SPI angesteuert. Die maximale Frequenz die bei der Kommunikation verwendet werden kann liegt bei 50 MHz.

Für die Konfiguration des FPGA/Flash habe ich bisher immer einen Altera USB-Blaster - China-Clon verwendet, dieser piept zwar hochfrequent wenn man ihn verwendet aber er tut seinen Zweck sonst einwandfrei. Als Software verwende ich Alteras Quartus II bzw. den "Programmer" welcher dort mitgeliefert wird.

Zum Ablauf: Das Flash wird über den FPGA, welcher per JTAG über den USB-Blaster - Clon beschreiben. Hierzu kommt ein "JIC"-File zum Einsatz damit das Design des FPGA persistent im Flash abgelegt wird. Das funktioniert einwandfrei.

Allerdings muss ich dazu sagen, dass ich damit nicht wirklich zufrieden bin. Das Problem ist, dass man in jedem Fall die doch recht unhandliche Quartus II - IDE benötigt. Und das auch in dem Fall um nur kurz ein neues Design auf den Flash übertragen zu können. Wirklich sehr umständlich!

Ich halte mein AmbiController - System jedoch gerne vollkommen frei von Entwicklungsumgebungen, also überdimensional großen Tools wie ein ATmel-Studio oder auch Altera Quartus II. Es ist daher schon immer mein Ziel gewesen die Firmware des Mikrocontrollers als auch das Design des FPGA per USB aktualisieren zu können. Da der Update-Vorgang eines Mikrocontrollers per USB bereits eher Standard ist, gehe ich hierauf nicht groß weiter ein.

Für das Update des FPGA-Flash-Inhaltes ist jedoch bei weitem mehr zutun als am Anfang gedacht...

Zum gewünschten Abauf:

Der Plan war zunächst den AVR XMega per SPI (parallel) zum FPGA anzuschließen und bei Bedarf auf den SPI Flash zuzugreifen. Per USB wird zum Mikrocontroller eine Verbindung aufgebaut, dieser darauf hin in einen Zustand gebracht in dem der Flash zugängig ist (schreibend und lesend) und das Update kann durchgeführt werden.

Leider steckt hier der Teufel im Detail. Prinzipiell ist SPI auf einem Mikrocontroller eine standardisierte Schnittstelle welche - simpel - mittels ATmel Application notes und kurzen Beispielen quasi direkt verwendet bzw. integriert werden kann.

Leider ist es bei SPI jedoch nicht vorgesehen ein MultiMaster-System aufzubauen - bei SPI kann es immer nur einen Master geben welcher mit allen Slaves selektiert kommuniziert. Aufgrund dieser Gegebenheit muss also der FPGA zunächst in einen Zustand gebracht werden in dem er alle SPI-Spezifischen Pins/Leitungen unberührt belässt. Im Aktiven Zustand würde dieser die Signale des AVR grundsätzlich verfälschen, was natürlich nicht erwünscht ist. Mit unberührt ist hier übrigens gemeint das alle Pins des FPGA als hochohmig konfiguriert sind, also keine messbaren Auswirkungen auf die SPI-Leitungen haben.

In meinem Fall habe ich hierzu die Chip-Enable-Leitung (nCE) des FPGA auf High gesetzt, und die nConfig-Leitung des FPGA auf Low. Damit verfällt der FPGA in einen unkonfigurierten Zustand - zum Glück gibt es bei derart schwer zu findenden Antworten auf derartige Probleme noch nette Leute in öffentlichen Foren - in dem alle Pins hochohmigen geschalten sind. Hochohmig bedeutet, dass hier keine Spannungen (durch den FPGA) anliegen und auch kein (messbarer) Strom in irgend eine Richtung an den betreffenden Pins fließt.

Ist der SPI Bus nun vom FPGA losgelöst kann im Mikrocontroller die SPI-Schnittstelle konfiguriert und verwendet werden. Ist hingegen der FPGA aktiv sollten alle SPI-Spezifischen Pins des Mikrocontroller hochohmig gesetzt worden sein, damit diese nicht die Kommunikation des FPGA mit dem Flash stören. Nachdem der Mikrocontroller die SPI-Schnittstelle nicht mehr benötigt sollte diese also wieder deaktivert werden, die Pins hochohmig geschalten und daraufhin der FPGA wieder in den "normalen" Betrieb geschalten werden. Der FPGA lädt sich daraufhin aus dem Flash das neue Design, sofern es aktualisiert wurde, und beginnt seine Arbeit.

Betrachtet man die einzelnen Aufgaben getrennt voneinander gestaltet sich das "Bild" nun deutlich einfacher, aber der Weg bis dahin kann sich ziehen wenn Informationen fehlen oder - wer hätte das gedacht - wenn die Hardware streikt.

Das interessante während der Entwicklung des Verfahrens war also das an meiner AmbiController - Hardware verwendete ATXMega192A3 den Betrieb der SPI-Schnittstelle verweigerte. Letztendlich habe ich drei (3) SPI-Implementierungen getestet, welche alle die interne SPI-Funktionalität verwenden. Und keine einzige hat auch nur ein einziges mal die Clock- oder MOSI-Leitung angesteuert.

Laut einschlägigen Foren ist natürlich dies absolut unmöglich... Vor allem da die Software, welche ich testen durfte von Personen stammte die sie ja erfolgreich seit Jahren auf anderen Controllern verwenden...

Leider hält sich mein Mikrocontroller aber nicht an deren Überzeugung und verweigert dennoch den Dienst. Auch mit gutem zureden war nichts zu bewege. Abhilfe hat mir dann eine Softwareseitige Implementierung einer Master-SPI-Schnittstelle gebracht. Diese ist vermutlich nicht ganz so performant und kompatibel bzw. generisch implementiert, jedoch fehlerfrei und funktionstüchtig.

Ich habe dann einige Zeit mit den Tests der SPI-Kommunikation verbracht, um einen Treiber zu implementieren welcher die Kommandos des SPI-Flashs beinhaltet, wie beispielsweise Pages zu schreiben oder lesen zu können.

Als Gegenstück dazu implementierte ich ein Kommandozeilen-Tool welches in der Lage ist per USB/Serielle Schnittstelle Daten aus dem Flash per Mikrocontroller auszulesen. Die ersten Tests verliefen zufriedenstellend, es kamen Daten aus dem Flash zurück. Der Sieg über Hard- und Software erschien mir sicher. Zumindest zunächst...

Auf den zweiten Blick hin wurden auch Muster, im Vergleich zu den von Quartus II erstellten Image-Dateien sichtbar. Jedoch mit einigen Unterschieden. Zu vielen Unterschieden...

Beispielsweise waren nur die Muster, also die Verteilung der Bytes in den Hexdumps der Dateien ähnlich/gleich. Nicht jedoch die einzelnen Byte. Dies lag daran das in den SOF- und JIC-Dateien - welche Quartus II einem erstellen kann - noch diverse weitere Header und Footer enthalten sind, und in den Flash-Daten selbst nicht mehr enthalten sind.

Weiterhin besteht der Grund für die Unterschieder ALLER Bytes im Flash zu den Quelldaten darin, dass alle Bytes einzeln nochmal bitweise umgekehrt werden (Bsp.: aus 0b0101_1000 wird 0b0001_1010). Mit einem Script, um Bytes in Dateien umzukehren, wurde der Vergleich des Flash-Inhaltes mit den Quelldateien einfacher.

Leider waren diese noch immer nicht identisch. Das Problem war natrlich das Datenformat der im Flash enthaltenen Daten. Es werden für das Konfigurieren eines FPGAs verschiedene Formate verwendet, welche abhängig sind von der verwendeten "Übertragungsform" und dem Flash (jedenfalls sind das die Hauptaussagen aus diversen Foren). Bei mir ist die Übertragungsform "Active Serial" - und damit eine SPI-Schnittstelle zwischen FPGA und einem seriellen Flash, wobei der FPGA der Master ist und sich die Daten aus dem Flash lädt. Der FPGA unterstützt dabei zudem auch eine Kompression der Daten.

Das untersuchen des Flash-Inhaltes nahm also noch kein gutes Ende. Als nächstes verglich ich verschiedene komprimierte und unkomprimierte - von Quartus II erzeugte - Dateien im RBF-Format (Raw-Binary-File) mit dem Flash-Inhalt. Dort hatte ich im Kopf der Dateien größere Unterschiede als im Rest der Dateien, und jede Zweite Page - im Flash - enthielt im letzten der 256 Bytes einer Page den Wert 0x05. Das RB-File enthielt dort weniger einheitliche Werte. Mein Tool zum Zugriff vom PC aus auf den Flash war zu diesem Zeitpukt bereits weiter entwickelt und nun auch in der Lage Daten in den Flash schreiben zu können...

Warum die Daten unterschiedlich waren konnte mir zunächst niemand sagen - wie auch - es lag an meiner Implementierung. Das letzte Byte einer zu schreibenden Page wurde nie korrekt verarbeitet. Diesen Leichtsinnsfehler/Tippfehler korrigiert, und schon waren die Images nahezu identisch. Lediglich in der ersten Page sind aktuell noch Unterschiede enthalten.

Der Grund ist hierfür angeblich, dass RBF nur für parallele Konfgurations-Arten verwendet werden. Der Header der Datei ist also noch unterschiedlich und das Image damit auch nicht lauffähig.

Was ist aber dann die Alternative?

Eine nette Person wies mich darauf hin, dass man mit den beiden Tools "sof2image" und "objcopy" Images erzeugen kann, welche auch beim konfigurieren mit "Active Serial" verwendet werden können. Die Verwendung ist einfach - sofern man keine Scheu vor einer Kommandozeile hat - es wird die mit Quartus II mitgelieferte NIOS2-Kommandozeige benötigt. Dort laufen alle benötigten Tools einwandfrei (bei Quartus II 13.1 auf Win7 Prof. 64bit und mti 14.x auf Win8.1 und Linux) und man kann die Konvertierung einer SOF-Dateirepräsentation des FPGA-Designs in ein Image vornehmen das dem tatsächlich

benötigten Flash-Inhalt entsprechen soll. Die NIOS2-Kommandozeile ist übrigens unter Windows nur eine "DOS-Box" (cmd.exe) in der ein Cygwin läuft.

Hier ein Beispiel für die Konvertierung:

$ sof2flash --input=fpga_design.sof --output=fpga_design.srec --compress --epcs --verbose

$ objcopy -I sreg -O binary fpga_design.sreg fpga_design.epcs_img -v

Vergleicht man nun die erzeugte Datei mit dem tatsächlichen Flash-Inhalt sind aber auch hier weiterhin Unterschiede vorhanden. Um genau zu sein 3 Byte in der ersten Page. Warum ist unklar - zumindest mir - aber interessanterweise funktioniert das erzeugte Image problemlos.

Damit ist für meinen AmbiController eine größere aber umso spannendere Hürde gemeistert, das FPGA Design per USB aktualisieren ohne die vollkommen überladene Quartus II - Umgebung von Altera verwenden zu müssen.

Was die Übertragungs-Geschwindigkeit angeht, mit der die Daten in den SPI Flash geschrieben werden, möchte ich bei Gelegenheit noch Tests durchführen.

Ich jedoch bereits Übertragungsraten von bis zu 60 kByte/s (lesend) vermessen können. Beim schreiben sinkt diese jedoch auf etwa 5,4 kByte/s (Win8.1 + Cygwin) und ca. 18kByte/s unter Linux.

Da die zu schreibenden Datenmengen jedoch sehr klein sind ist diese Geschwindigkeit noch nicht an bzw. über der Grenze zum unerträglichen.

Autonomous Light Controller - Hardware Synthese

Und dann war da noch die Sache mit dem FPGA. Bevor ich mit diesem Projekt angefangen habe wusste ich nichts darüber, außer das die Dinger schnell sein müssen. Schneller als ein CPLD zumindest, damit hatte ich schon einmal Kontakt als es darum ging Linux mittels einem PassMe auf einem Nintendo DS booten zu können. Das gute beim ersten Kontakt mit dieser Art Baustein war, dass man es mit JTAG ansprechen konnte. Und wenn man in ein Entwicklungs-Board wie das DE0-Nano investiert sogar komfortabel per USB damit arbeiten kann. Allerdings ist so ein FPGA (wiedererwarten) alles andere als ein besserer Mikrocontroller- so meine erste Annahme. Ein FPGA ist für mein Empfinden mittlerweile eine Spielwiese der nur die eigene Rechenkapazität im Gehirn eine Grenze setzt (ja ich weiß sehr hochgestochen).

Die erste Sache die man sich als Software-Entwickler aus dem Kopf schlagen muss, wenn man mit einem FPGA arbeiten möchte, ist das man da ein Programm für schreibt das darauf läuft. Zumindest wenn man VHDL (Very High Speed Integrated Circuit Hardware Description Language) sieht das dann sogar noch wie ein Programm aus. Es verhält sich aber in sehr vielen Punkten einfach so wie man es erwartet. Das fängt an bei parallelen Prozessen, dass Variablen einen bösen Beigeschmack haben können und endet bei der Synchronisierung von Signalen in verschiedenen Clock-Domains. Beißt man sich jedoch durch das Thema durch hat man jedoch ein wirklich sehr komfortables und mächtiges Werkzeug in der Hand um verschiedenste Probleme lösen zu können.

Wie ich bereits in einem früheren Post geschrieben habe, verwende ich für den analogen Teil einen DSP, der in der Lage ist analoge Videosignale in ITU-R BT.656 kodierte Daten zu transformieren. Diese Daten werden in meinem Fall mit 27MHz bitparallel aus dem DSP mit einer Farbtiefe von 10Bit heraus getaktet.

Für den von mir verwendeten XMega deutlich zu schnell wenn man bedenkt das dieser mit 32MHz läuft und ca. 1-2 Takte benötigt um einen einzelnen Pin auszulesen.

Mit der richtigen Hardware-Synthese im richtigen FPGA sind diese Laufzeiten jedoch kein Problem. Was also muss die Hardware-Synthese tun damit das Ergebnis für Ausgabe auf LED-Streifen als Hintergrundbeleuchtung für einen Bildschirm verwendet werden kann. Es ist recht simpel. Der FPGA muss die Pixeldaten taktgesteuert annehmen, puffern, herunter skalieren (von beispielsweise einer PAL-Auflösung) auf eine vom XMega verarbeitbare Pixel-Größe, und ausgeben des Ergebnisses an den XMega. Und all das so, dass mindestens 25 Bilder pro Sekunde verarbeitet werden können um unschönes Geflacker zu vermeiden.

Meine Logik auf dem FPGA realisiert genau das. Zur Laufzeit werden alle Pixeldaten (eines Halbbildes) eingelesen und in einen kleinen OnChip-RAM gepuffert. Gleichzeitig wird über einen Hardware-Algorithmus die Auflösung des Eingangs-Bildes auf 20x20 Pixel skaliert. Warum nur ein Halbbild verwendet wird liegt daran, dass es unnötig ist die volle Auflösung beim Eingangs-Bild zu verwenden wenn man es Bild danach auf ein gerade noch verwendbares Minimum zu skalieren.

Die Übertragung zum Mikrocontroller erfolgt darauf hin direkt aus dem OnChip-RAM heraus. Der Mikrocontroller lädt die Pixel einzeln und komponentenweise, mittels einer Taktleitung und bitparallel über einen 12Bit-Bus aus dem FPGA. Wurden alle Daten übertragen beginnt dieser damit aus den Pixeldaten die Farben für die LEDs heraus zu rechnen. Parallel dazu verarbeitet der FPGA das nächste Halbbild. Der beschriebene Ablauf verarbeitet damit alle 25 empfangenen Halbbilder des Eingangssignals. Die Ausgabe der LED-Farben erfolgt ebenfalls mit 25 "Bildern" pro Sekunde.

Aufgrund der Performance des Gesamtsystems war es sogar notwendig einen Puffer in die Software einzufügen, damit die ausgegebenen Farben mit dem angezeigten Bild synchronisiert werden kann. Der AmbiController ist deutlich schneller in der Bildverarbeitung als mein TV-Gerät.

Autonomous Light Controller - Platine fertig aufgebaut

Wer mit auf Twitter (@KaiLauterbach) folgt, wird schon des öfteren von Neuigkeiten zu dem Projekt gelesen haben. Das Bild unten zeigt die vollständig aufgebaute Platine. Diese soll den Prototyp (oben) später vollständig ersetzen.

Die neue Platine Funktioniert bereits zu großen Teilen. Bis die Hardware jedoch komplett läuft, wird jedoch noch ein wenig Zeit vergehen. 

Autonomous Light Controller - Dizzying Signal Processing

Wie ich in meinem letzten Post geschrieben habe gibt es neben dem Mikrocontroller noch einen weiteren Prozessor, es handelt sich dabei um einen TVP5146M2, von Texas Instruments. Dieser ist ein Videoprozessor, der in der Lage ist analoge Videosignale zu digialisieren und über eine bitparallele Schnittstelle (10- oder 20Bit breit) taktsynchron weiterzuleiten. Er unterstützt alle gängigen analogen Videosignale, wie beispielsweise alle PAL- und NTSC-Varianten. Als Übertragungsmedium wird CVBS, Component RGB und Component YPbPr unterstützt. VGA oder ähnliches nicht.

Die von diesem Prozessor ausgegebenen Videodaten werden nach dem Videostandard ITU-R BT.656 kodiert. Hierbei werden volle Bilder in Halbbildern nacheinander übertragen. Dabei wird - eine im DSP einzustellende - Unterabtastung verwendet. Bei der Übertragung wird durch die Unterabtastung deutlich an Bandbreite eingespart, ohne das es zu erheblichen Qualitätseinbußen kommt.

Der Takt zur Datenübertragung beträgt bei PAL/NTSC, einem 10Bit breiten Datenbus (entspricht 10Bit Farbtiefe) 27MHz, was einem Datenstrom von 27MBit/s ergibt. Leider ist der ATXMega hierbei schon komplett überfordert, da die Datenworte, am Bu,s nur ca. 18,5ns (Nanosekunden) anliegen, und dies drastisch kürzer ist als der Mikrocontroller (selbst bei Übertaktung auf 54MHz, 32MHz ist die empfohlene Obergrenze) erkennen kann.

Die Idee das System mit einem AVR XMega und diesem DSP aufzubauen scheiterte also recht früh in der Entwicklung, da auch der DSP nicht weiter um konfiguriert werden kann um die Übertragungsgeschwindigkeit bzw. die Bildauflösung zu reduzieren.

Jetzt könnte man sagen, dass man einfach einen anderen Mikrocontroller verwendet oder einen anderen DSP. Aber nein - das wäre zu einfach.

Der Flaschenhals bei dem Thema ist der Mikrocontroller. Setzt man nun einen deutlich schnelleren ein, mit dem die ITU-R BT.656-Signale nun verarbeitet werden können, steht man kurz darauf vor dem nächsten Problem sobald man moderne (digitale und hochauflösende) Videosignale verarbeiten möchte. Bei der Bildübertragung eines FULL-HD-Signales mit knapp 1280x1080 Pixeln, selbst mit 10Bit Farbtiefe sind deutlich höhere Taktraten als 27MHz notwendig um die Bilddaten in akzeptabler Zeit zwischen den Prozessoren zu übertragen. Ein Datenblatt eines anderen Signalprozessors (auf den ich in einem Späteren Post eingehen werde) gibt hier Taktraten von etwa 250MHz an. Es wird schnell klar, dass ein bezahlbarer Mikrocontroller hierbei einfach nicht hinterher kommt, so einfach die Lösung auch sein mag. Daher hab ich mich dazu entschieden einen anderen Ansatz zu verfolgen und den einfachen Weg zu verlassen.

Allerdings ist dieser Ansatz bei weitem komplexer und aufwendiger als einfach mehr Rechenleistung zu kaufen. Es geht dabei darum eigene eigene Hardware zu entwerfen, welche die vom DSP übertragenen Daten in Realtime empfangen kann, in der Lage ist diese zeitnah zu verarbeiten, und dem Mikrocontroller vor verarbeitet und in kleinen Portionen zur Verfügung zu stellen. Dazu gibt es aber mehr in einem der nächsten Posts...

Wie jedes mal habe ich in das Git-Repository die dazugehörigen Schaltpäne übertragen.

Autonomous Light Controller - The FPGA Ambilight clone?

Wie angekündigt möchte ich hier nach und nach mehr Details über mein Projekt verraten. Dem aufmerksamen Leser ist sicher bereits schon aufgefallen, dass die Verlinkungen (Tags) zu den Posts in Kategorien fallen, in denen sich bereits kleine andere Projekte befinden.

Beispielsweise verwende ich als Mikrocontroller-Basis mein XMega-Evaluation-Board.

Genauer gesagt wurde dieses genau für diesen Zweck erstellt...

Letztendlich handelt es sich um eine Grundschaltung für den XMega und diversen Schnittstellen um das Board mit der anderen Peripherie anzubinden. Der Schaltplan ist im Bild rechts zu sehen. Ein Layout gibt es hierfür nicht, da das ganze auf Lochraster aufgebaut ist (Bilder unten).

Den Schaltplan (Eagle) zu dem Board ist auf GitHub Verfügbar...

Die Aufgaben dieses Boards sind die folgenden:

1. Steuerung aller weiteren Komponenten wie dem FPGA-Board und dem Signalprozessor.
2. Kommunikation und Steuerung der Beleuchtungsanlage (Fnordlichter oder LED-Stripes).
3. Kommunikation per USB/Bluetooth mit externen Komponenten oder dem Anwender (TTY)
4. Power- und Videosignal-Management.
5. Empfang und Aufbereitung der bereits durch den FPGA vorbereiteten Bilddaten.
6. Übertragung der vom FPGA empfangenen Bilddaten per USB oder Bluetooth.

Die Software auf dem Chip besteht aus einer in C geschriebenen Firmware welche alle Aufgaben aus der Liste oben. Der größte Teil der Implementierung entspricht einer TTY-Emulation für die Interaktion mit dem System.

Per TTY können verschiedene Konfigurationseinstellungen vorgenommen und Systemtests durchgeführt werden.

Das folgende Video zeigt den Zugriff auf das System bzw. auf verschiedene Register des Signalprozessors per I²C. Das Terminal enthält eine ausführliche Online-Hilfe und erlaubt, neben dem vollem Systemzugriff, zudem die Steuerung der Beleuchtung. Der Controller kann damit auch anderweitig verwendet werden.

Eine wesentlich maschinenlesbare Variante der Kommunikation ist in Arbeit.

Das Video soll schlicht demonstrieren, dass so eine Schnittstelle existiert und verwendet werden kann. Als einfacher Anwender kommt man damit nicht in Berührung. Damit wäre die Usability sonst komplett unmöglich...

Wie in der Auflistung oben bereits erwähnt (Punkt 6) ist das System zudem in der Lage die Bild-Rohdaten, welche vom FPGA erzeugt werden, per USB oder Bluetooth auszugeben. Hierzu ist das Tool "FrameView" entstanden. FrameView verwendet unter anderem SDL, ist plattformunabhängig und als Linux-Binary gerade mal 14kb groß.
Das folgende Video zeigt die Applikation in Aktion. Das Bild des Desktops wird dabei per VGA->CVBS-Adapter in den AmbiController geleitet, automatisch ausgewertet, und das Ergebnis per USB an die FrameView-Anwendung weitergeleitet, welche das aktuell ermittelte Bild in dem kleinen Fenster links darfstellt. Das Größere Fenster ist Video mit einem ein einfachen Farbtest. Das Ganze stammt aus den Anfängen der Entwicklung. Daher ist das Ergebnis noch sehr sehr pixelig.
Das Protokoll an dieser Stelle ist recht proprietär und nur zu Debug-Zwecken gedacht, da diese Ausgabe zudem die Framerate drückt. Um Bandbreite bei der Datenübertragung zu sparen werden hier immer nur Änderungen übertragen. 

Damit erstmal genug für heute und viel Spaß beim Video schauen...

Altera Quartus 11.0 Tools, Ubuntu 11.4, USB-Blaster

Wer mit Ubuntu 11.4 (x86) und der Software Quartus II Version 11.0 Build 157 04/27/2011 SJ Web Edition von Altera arbeitet, um z.B. sein DE0-Nano Board mit "Leben" zu befüllen wird schnell feststellen, dass diese Kombination leider ohne manuellen Eingriff, direkt nach der Installation der Altera Software, nicht funktioniert. Quartus II stürzt direkt nach dem Start mit einem Segfault (zumindest bei mir) ab. Und weder mit dem grafischen Programmer noch mit den Tools auf der Kommandozeile kann auf das DE0-Nano, welches sich am System als USB-Blaster ausgibt, zugegriffen werden. Da ich persönlich lieber auf der Konsole und mit Quartus II (aus vielerlei gründen) nur ungern arbeite, gehe ich hier nur auf die Konfiguration der Kommandozeilen Tools ein, um diese zur korrekten Arbeit zu bringen. Meine Altera Software habe ich mittels dem Altera-Installer unter ~/bin/altera/11.0 installiert.

1. Die ~/.bashrc anpassen

Als erstes muss selbstverständlich der Pfad zu den Binaries der PATH-Variable hinzugefügt werden. Weiterhin benötigen diverse Quartus Tools die Umgebungsvariable QUARTUS_ROOTDIR um korrekt arbeiten zu können, daher habe ich auch diese in meine .bashrc eingefügt.

export PATH=$PATH":~/bin/altera/11.0/quartus/bin:~/bin/altera/11.0/nios2eds/bin:~/bin/altera/11.0/quartus/sopc_builder/bin"

export QUARTUS_ROOTDIR="~/bin/altera/11.0/quartus ~/bin/altera/11.0/nios2eds/sdk_shell"

2. UDEV Zugriffsrecht auf den USB-Blaster einrichten

Ich habe die Datei "/etc/udev/rules.d/40-altera-usbblaster.rules" mit dem folgenden Inhalt angelegt:

BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6001", MODE="0666", SYMLINK+="usbblaster", GROUP="plugdev"

Startet man danach das System neu oder führt einen Reload von UDEV durch, kann auf den USB-Blaster zugegriffen werden. Die Voraussetzung dafür ist natürlich, dass dieser in der Liste der USB-Geräte auch angezeigt wird.

user@host:~$ lsusb -d 09fb:6001
Bus 002 Device 013: ID 09fb:6001 Altera

UDEV kann mit den entsprechenden Rechten mittels service udev reload dazu angewiesen werden die Konfiguration neu zu laden.

3. JTAG Daemon

Dieser Daemon muss laufen, um korrekt auf die JTAG-Chain per USB-Blaster zugreifen zu können. Gestartet wird dieser mit jtagd. Natürlich kann man diesen Daemon auch permanent laufen lassen.

4. Testen der JTAG-Verbindung

Beim Aufruf von jtagconfig wird als Standard die Option --enum ausgeführt. Es werden alle diejenigen Devices angezeigt, die an der JTAG-Chain hinter dem USB-Blaster hängen.

user@host:~$ jtagconfig
1) USB-Blaster [2-1.2.2]
  020F30DD

5. Quartus Programmer testen

Der Quartus Programmer muss selbstverständlich auch auf den USB-Blaster zugreifen können. Das kann mit dem folgenden Aufruf getestet werden.

user@host:~$ quartus_pgm --list

Info: *******************************************************************
Info: Running Quartus II Programmer
    Info: Version 11.0 Build 157 04/27/2011 SJ Web Edition
    Info: Copyright (C) 1991-2011 Altera Corporation. All rights reserved.
    Info: Your use of Altera Corporation's design tools, logic functions
    Info: and other software and tools, and its AMPP partner logic
    Info: functions, and any output files from any of the foregoing
    Info: (including device programming or simulation files), and any
    Info: associated documentation or information are expressly subject
    Info: to the terms and conditions of the Altera Program License
    Info: Subscription Agreement, Altera MegaCore Function License
    Info: Agreement, or other applicable license agreement, including,
    Info: without limitation, that your use is for the sole purpose of
    Info: programming logic devices manufactured by Altera and sold by
    Info: Altera or its authorized distributors.  Please refer to the
    Info: applicable agreement for further details.
    Info: Processing started: Sat Oct  8 18:10:02 2011
Info: Command: quartus_pgm --list

1) USB-Blaster [2-1.2.2]

Info: Quartus II Programmer was successful. 0 errors, 0 warnings
    Info: Peak virtual memory: 82 megabytes
    Info: Processing ended: Sat Oct  8 18:10:02 2011
    Info: Elapsed time: 00:00:00
    Info: Total CPU time (on all processors): 00:00:00

Die Tools quartus_pgm und quartus_pgmw (die grafische Version) sollten nun den USB-Blaster korrekt erkennen und ansteuern können.

Da aber nun das übertragen der synthetisierten Logik nicht genug ist und ich den Build-Vorgang mit einem kurzen Makefile automatisiert habe, möchte ich dass natürlich nicht vorenthalten. Voraussetzung für den korrekten Betrieb sind die oben genannten Einstellungen, dass man sich beim Start im Verzeichnis des Quartus-Projektes befindet und das die Haupt-Datei des Projektes identisch mit dem Projektnamen ist (alles natürlich Case-Sensitive).

#
# Makefile to build FPGA/CPLD synthesis with altera tools.
#
# Licensed under GPL v3.0 (15.10.2011)
# by Kai Lauterbach (klaute at gmail dot com)
#

TARGET=test

MAPPER=quartus_map
MAP_OPTIONS=--read_settings_files=on --write_settings_files=off $(TARGET) -c $(TARGET)

FITTER=quartus_fit
FIT_OPTIONS=--read_settings_files=off --write_settings_files=off $(TARGET) -c $(TARGET)

ASSEMBLER=quartus_asm
ASM_OPTIONS=--read_settings_files=off --write_settings_files=off $(TARGET) -c $(TARGET)

STA=quartus_sta
STA_OPTIONS=$(TARGET) -c $(TARGET)

PROGRAMMER=quartus_pgm
PGM_OPTIONS=-m jtag -c USB-Blaster -o "p;$(TARGET).sof"

compile: clean map fit asm sta

map:
    $(MAPPER) $(MAP_OPTIONS)

fit:
    $(FITTER) $(FIT_OPTIONS)

asm:
    $(ASSEMBLER) $(ASM_OPTIONS)

sta:
    $(STA) $(STA_OPTIONS)

program:
    $(PROGRAMMER) $(PGM_OPTIONS)

clean:
    rm -rf db/ dse/ incremental_db/ sim.do $(TARGET)ig.archive.rpt $(TARGET).asm.rpt $(TARGET).bsf $(TARGET).cdf $(TARGET).done $(TARGET).dse.rpt $(TARGET).fit.rpt $(TARGET).fit.summary $(TARGET).flow.rpt $(TARGET).inc $(TARGET).map.rpt $(TARGET).map.smsg $(TARGET).map.summary $(TARGET).mif_update.rpt $(TARGET).pin $(TARGET).sof $(TARGET).sta.rpt $(TARGET).sta.summary $(TARGET).tis_db_list.ddb $(TARGET)_assignment_defaults.qdf wave.do $(TARGET).archive.rpt